AI導入は、なぜ「報告書」では進まないのか — 既存型コンサルティングの限界

「立派な報告書はもらった。ロードマップも描いてもらった。で — これ、誰が作るんですか？」

AI導入に取り組む企業から、こうした声を聞くことが増えました。決して珍しい話ではありません。数ヶ月かけた調査と提言のあとに、実装の担い手がいないまま計画だけが残る。既存型のコンサルティングを否定したいわけではありませんが、AI導入という仕事の性質と、「分析→提言→納品」という型の間には、構造的なミスマッチがあります。

従来型コンサルが得意なこと

前提として、従来型コンサルティングには明確な価値があります。経営課題の構造化、市場や競合の分析、組織を動かすための計画づくり。「何が問題か」を経営の言葉で整理する仕事は、社外の視点だからこそできる部分があります。

問題は、AI導入がその型に収まらないことです。

AI導入で「報告書型」が機能しにくい3つの理由

理由1: 作って試すまで、要件が確定しない

生成AI・LLMは、従来のシステムと違い、仕様書の上で挙動を確定できません。自社のデータでどこまでの精度が出るか、どの業務なら任せられるか、どこで人の確認が要るか — これらは実際に作って、実データで試して、初めて分かります。

「要件を固めてから作る」前提の提言は、この順序と逆向きです。AI導入では「小さく作って測る」往復が先にあり、要件はその往復の中で固まっていきます。分析に時間をかけるほど正解に近づく、という種類の仕事ではないのです。

理由2: 提言と実装が分断され、伝言ゲームが起きる

報告書の提言は、その後「RFP作成 → ベンダー選定 → 要件定義 → 実装」という長いリレーに渡されます。リレーのたびに意図は少しずつ削れ、実装の現実（既存システムの制約、データの状態、ネットワークやセキュリティの事情）とのすり合わせは後回しになります。

そして提言の段階では、実現可能性が実物で検証されていないことが少なくありません。「技術的には可能」と書かれた一行の裏に、実装側から見れば数ヶ月分の難所が潜んでいる — このギャップは、絵を描く人が自分で作らない構造からきています。

理由3: 「業務が変わったか」に責任を持つ人がいない

コンサルティングの成果物は、多くの場合ドキュメントです。納品をもって契約は完了し、その提言で実際に業務が改善したかどうかは、契約上は誰の責任でもなくなります。実装ベンダーは「仕様どおり作ったか」に責任を持ちますが、「効果が出たか」には持ちません。

つまり分業の隙間に、いちばん大事な問い — 業務は本当に変わったのか — が落ちてしまうのです。

構造への答え: 提言する人と作る人を分けない

この3つはどれも、個々のコンサルタントの能力の問題ではなく、分業の構造の問題です。だから答えも構造で出す必要があります。

FDE（Forward Deployed Engineer）という働き方は、まさにこのために生まれました。お客様のシステムと業務を一緒に理解し、課題を要件に翻訳する人間が、そのまま自分の手で実装し、効果測定まで伴走する。提言と実装の間に伝言ゲームが存在しないので、実現可能性のない提案は最初から生まれず、「効果が出たか」から逃げられません。

守りも、報告書だけでは効かない

AIの利用基準やセキュリティの方針も同じです。基準を文書にしても、守られているかを確かめる仕組みがなければ、現場では使いやすい方へ流れます。基準を書く人が、それを守らせる設定と記録の仕組みまで組むことで、方針は実際に効きます。

フォースネットのセキュリティFDEでは、AIの利用基準づくりと、それを守らせるネットワークの制御・記録の仕組みを、同じエンジニアが担当します。

報告書が積み上がっているのに業務が変わっていない、という状況に心当たりがあれば、一度初回の見立て（無料・30分）でお話を聞かせてください。どこで止まっているかが分かれば、次の一手も見えてきます。