なぜAI予算は承認されるのに、現場で機能しないのか（CEOブログ）
taneda.com取締役会でAI投資の議案が通った数ヶ月後に、現場を見に行ったことがあります。
ツールは入っていました。ただ、スタッフは使っていなかった。理由を聞くと「操作が面倒で、前のやり方の方が早い」と言う。もう少し聞くと、入力データのフォーマットが現場の実データと合っていない。接続しているシステムのバージョンが古くて、想定した動きをしていない。
この種の問題は、デモ環境では出てきません。
承認前のプレゼンは毎回きれいです。クリーンなデータで動かしたデモ、理想的な使われ方を前提にしたROI試算。問題が出るのは、常に本番に入ってからです。
「誰が現場で動かすのか」という問いが抜けている
見てきて気づいたことがあります。
AI関連の予算は、たいてい、次のどちらかのカテゴリーで処理されています。SaaSツールのライセンス料か、エンジニアの採用・人件費としてのR&D予算か。どちらも間違いではないのですが、どちらにも入らない第三の重要な仕事があるのです。
「そのAIを、自社のぐちゃぐちゃのデータと古いシステムの中で、実際に動くようにする」という仕事です。
現場のデータは整理されていません。部門ごとにフォーマットが違う。マニュアルに載っていない例外処理が山ほどある。十年単位で使ってきたシステムとの接続は、一つとして同じではない。これらをコードレベルで解決していく人間がいなければ、どんなAIも使われないまま終わります。
MIT NANDAの2025年レポートが企業の生成AIパイロットの95%が成果を出せずに終わると報告しているのは、技術が弱いからではなく、この仕事を誰もやっていないからだと私は見ています。
FDEという役割
この仕事を担う人間を「FDE（Forward Deployed Engineer）」と呼びます。
具体的業務は、社内ドキュメントや暗黙知をAIに参照させるRAGのチューニング、複数のAIエージェントが既存のCRMやERPと連携できるよう整備するMCPサーバーの開発、AIが現場で誤動作していないかを監視する評価パイプラインの構築などです。設定画面でできる仕事ではありません。現場の実データに直接触れながら、コードを書いて解決する。
2026年5月、わずか10日の間にOpenAI、Google、Anthropic、そしてAccentureとMicrosoftの共同体制が、ほぼ同時に「実装」への大規模投資を発表しました。OpenAIだけで40億ドルです。おそらく、この動きを「新職種の流行」と読むのは浅くて、彼らは「モデルの性能差では競争できなくなった。現場で動かせるかどうかが差になる」と判断したということでしょう。
米国でのFDEの年収は4,000万円規模、日本のトップポジションでも9,000万円を超える事例が出ています。Intercomはこの体制を導入して18ヶ月で顧客数を5社から7,000社に伸ばし、EYとMicrosoftの共同FDE体制はリードタイムを95%短縮しました。一人のFDEが現場で生み出すROIの規模を見れば、この報酬水準は妥当でしょう。
どう手に入れるか
外部のFDE部隊を使う選択肢は立ち上がりが速い半面、毎回コストがかかり続け、知見が社内に蓄積しません。短期の実証には向きますが、それを前提に計画する必要があります。
内製チームを作る選択肢は時間がかかりますが、その3〜5年で蓄積した知見は競争力になります。ソフトバンクは自社でAI利用率70%超を達成してから、その経験をそのまま法人向けサービスとして展開しています。採用と同時に「現場で主体的に動ける権限」を整えることが前提で、権限のないFDEは高いコストがかかるだけで機能しません。
見落とされがちなのが、社内にすでにいる人間を使う選択肢です。どの組織にも、FDEとして雇用されていないがFDE的な動きをしている人間が必ずいます。現場の課題を自分でコードを書いて解決している担当者、システムと現場の間に立って問題を潰している社員。この人を発見して正当に評価し、権限と予算を与える方が外部採用より速く、コストも低い。ただし、正当な評価と昇給がなければ数ヶ月で燃え尽きるので、そこは忘れてはなりません。
取締役会での通し方
「FDEに年収9,000万円」を取締役会に持っていくとき、職種の説明から始めると通しにくいかもしれません。
現在失敗しているプロジェクトの総コストを積み上げることから始めます。ツール代、コンサル費、社員の工数。これが成果ゼロで消えていることを数字で示す。次に実装能力を持った場合の成功確率と成功時のROIを試算する。差分が投資の根拠になります。
もう一つ、予算承認と同時に「何をもって成功とするか」を決めておくことを強くすすめます。半年後に誰がどの数字で評価するかを承認時点で決めておかないと、「現場の反応がよくなった気がします」という定性報告だけが積み上がります。
最後に、日本市場固有の問題
日本のIT産業の多重下請け構造の中では、「現場に入ってその場で判断してコードを書く」という動き方が契約上どこに位置するのかが曖昧になります。変更のたびに承認フローが動き、スピードが失われる。
外部と組む場合は変更対応の権限を契約に明記する。内製の場合は現場で動ける権限を組織として与える。技術より先に、ここを整えておかないと機能しません。
単純な技術の問題ではなく、組織と契約の問題も、とても重要です。
