導入は済んだのに効果が出ない、という段階の方へ
社内で生成AIの利用が始まり、ツールの契約も済んだ。それなのに「で、結局どこが良くなったのか」と聞かれると答えに詰まる。この記事は、その段階にいる方に向けて書いています。
PwC Japanグループの調査では、日本企業の生成AI活用・推進度は2026年春時点で**87%に達しました。前回調査から11ポイント増えています。一方で、期待を大きく上回る効果を創出できた企業は9%**にとどまり、6カ国で最も低い水準でした。米国は38%、英国は32%です（PwC Japanグループ 生成AIに関する実態調査2026 春 6カ国比較・2026年2月調査・有効回答932件）。
別の調査でも同じ構造が出ています。企業のAI・データ活用に関わる373人への調査で、AI活用で「明確な成果が得られている」と回答した企業は**16.4%**でした（primeNumber AI・データ活用実態調査 2026・2026年6月調査）。
導入率では、もう差がつきません。差がつくのは、その先です。
AIネイティブ開発は、AIを主役にする話ではありません
AIネイティブ開発は、AIに全部任せることではありません。要件整理、実装、テスト、レビュー、運用改善の流れにAIを組み込み、人が判断と責任を担う開発体制です。
ここを取り違えると、「AIが書いたコードなので誰も中身を説明できない」という状態が生まれます。動いているうちは問題になりません。困るのは障害が起きた日で、直せる人も説明できる人もいないことに気づきます。
重要なのは、AIが作る量とスピードを活かしながら、仕様・品質・リスクを確認する仕組みを同時に作ることです。AIの利用範囲だけを決めても、受入基準や運用判断が曖昧なままでは、開発の成果を判断できません。
最初に決めるのは、ツールではなく分担です
最初に、対象業務、作る範囲、AIに任せる作業、人が確認する作業を分けます。この切り分けがないまま実装を始めると、成果物の品質を判断できなくなります。
相談段階では、機能一覧よりも、誰が何を判断できれば前に進めるのかを確認します。初期開発では、作る範囲と同じくらい、作らない範囲を明確にすることが大切です。
AI開発を始める前に埋める分担表
| 工程 | AIに任せる | 人が確認する | 確認する人 |
|---|---|---|---|
| 要件整理 | 論点の洗い出し・たたき台 | 業務前提との整合・優先順位 | 業務側の責任者 |
| 設計 | 設計案・比較表 | 既存構成との整合・非機能要件 | 技術責任者 |
| 実装 | コードの下書き | 仕様との一致・影響範囲 | レビュー担当 |
| テスト | テストケース案 | 観点の抜け・例外系 | レビュー担当 |
| 公開判断 | なし | 公開可否・責任の所在 | 技術責任者 |
キックオフ資料にそのまま貼って使えます。「確認する人」の欄が空のまま残る工程が、後で事故になります
埋めてみると、たいてい右端の列で手が止まります。そこが本当の課題です。
相談を成果物に変換する
AI活用の相談は、話して終わりにしないことが大切です。課題整理メモ、実装ロードマップ、レビュー記録のように、後から見返せる成果物を残します。
成果物が残ると、次に何を作るか、何を保留するか、誰が確認するかを判断しやすくなります。AIを使う開発では変更量が増えやすいため、記録を残すこと自体が品質管理になります。
- 課題整理メモ
- AIに任せる範囲と人が確認する範囲の表
- 初期スコープと保留スコープ
- レビュー結果、テスト結果、運用判断メモ
AIを使う場所と、使わない場所
AIは、調査、設計案、実装、テストケース案、ドキュメント更新などで効果を出しやすい道具です。一方で、顧客への説明、法務や契約に関わる表現、権限変更、公開判断などは、人の確認を前提にします。
経済産業省・総務省のAI事業者ガイドライン（第1.2版）も、自動化バイアスのようにAIへ過度に依存するリスクへの対策を求めています。AIの評価や判断を人が承認するときは、承認する理由や根拠を人が自ら考えてから承認する進め方を挙げています。
判断の基準は「速くなるか」ではありません。間違えたときに誰が検知できるか、戻せるか、説明できるか。この3つで決めます。
小さく試して、本実装へ進める
最初から大きなシステムを作るのではなく、業務単位で小さく試し、効果とリスクを確認します。問い合わせ対応、社内検索、帳票作成、既存システムの一部移行などは、初期検証の単位にしやすい領域です。
試作で確認するのは、見た目の完成度だけではありません。入力の揺れ、例外処理、運用担当者の確認時間、既存業務への戻し方まで見ます。ここを省くと、PoCは動くのに本番へ進めない状態で止まります。試作から本番へ進める判断の設計はPoCを本番に進める判断で扱っています。
変更量が増えるほど、下流の弱点が表に出ます
AIを使うほど、コードや文書の変更は増えます。だからこそ、レビュー、テスト、受入、変更記録を軽く扱わないことが重要です。
Google Cloudの2025年DORAレポートの公表記事も、AIによる開発の加速は下流の弱点を表面化させるとしています。自動テスト、成熟したバージョン管理、速いフィードバックといった制御の仕組みがないまま変更量が増えると、リリースが不安定になると述べています。
同レポートはAIを増幅器と位置づけています。うまくいっている組織の強みを増幅し、うまくいっていない組織の機能不全も同じように増幅する、という整理です。効果が出ない原因をツール選定に求めているうちは、この増幅の向きは変わりません。
AIで速く作ったものを、事業で使える状態にする
AIネイティブ開発は、AIで作ることそのものではなく、AIで速く作ったものを事業で使える状態に整えることです。開発体制、確認の分担、運用後の改善まで含めて設計する必要があります。
生産性の数字をどう読むかはAI開発の生産性200倍は何を測った数字か、AIの出力を人が確認する具体的な観点はAIが作ったコードを人がレビューする理由、外部チームと組む場合の体制設計はAI時代のオフショア開発で日本側PMが担う役割で扱っています。
導入は済んだが効果を説明できない、という段階でしたら、お問い合わせからご相談ください。分担表を一緒に埋めるところから始めます。