FDEとは何か──AI導入を「成功」させる新しいパートナーの選び方

「結局、誰も使ってないんですよね」

先日、ある中堅メーカーの社長と話していたときのことです。大手コンサルに依頼してAI導入の戦略を作り、システム会社に開発を委託し、半年かけて完成した需要予測システム。ところが、現場の担当者は相変わらず Excel で予測を立てています。「画面は立派なんだけど、結局信頼できなくて」と現場は言います。

これは珍しい話ではありません。私たちが相談を受ける企業の7割以上が、似たような経験をお持ちです。

コンサルが作った戦略書は正しい。システム会社が納品したシステムも、仕様通りに動いている。なのに現場は使わない。この「PoCの死の谷」と呼ばれる現象は、AI導入において最も深刻な課題の一つです。

なぜこうなるのか。正直に申し上げると、技術の問題ではありません。AIの精度が低いわけでもない。問題は「作った人」と「使う人」の間に、誰もいなかったことにあります。

戦略を立てる人、システムを作る人、そして現場で使う人。この3者をつなぐ「橋」がいなかったのです。

Palantir が見つけた答え

この問題に、15年以上前から取り組んできた会社があります。米国の Palantir（パランティア）です。

彼らは政府機関向けにデータ分析システムを作っていました。ただ、相手は CIA や国防総省です。「業務内容を教えてください」と聞いても、機密だから教えてもらえません。仕様書なんて存在しない。要件定義書を書いてもらうことすらできません。

そこで Palantir がやったのは、エンジニアを現場に送り込むことでした。顧客のオフィスに常駐し、隣の席で一緒に働きながら、何に困っているかを自分の目で見る。見つけた課題をその場でコードに落とし、翌日にはプロトタイプ（試作品）を見せる。使いにくければ、また直す。この繰り返しです。

彼らはこの役割を FDE（Forward Deployed Engineer：フォワードデプロイドエンジニア）と名づけました。直訳すれば「前線に配備されたエンジニア」。軍事用語です。

ここで重要なのは、FDE は単なる「客先常駐エンジニア」ではないということです。日本には SES（システムエンジニアリングサービス）という仕組みがありますが、FDE はこれとは根本的に異なります。SES は顧客が用意した仕様に従って手を動かす人材ですが、FDE は自ら課題を発見し、解決策を設計し、実装し、定着まで責任を持ちます。

Goodpatch の記事は、FDE に必要な3つの能力を「戦略的思考（コンサルの領域）」「アジャイル開発力（SIerの領域）」「現場理解と共感（自社現場の領域）」と整理しています。この3つを1人、あるいは1チームで兼ね備えているのが FDE の最大の特徴です。

コンサルでもSIerでもない、第三の選択肢

ここで整理しておきます。AI導入を外部に相談するとき、選択肢は大きく3つあります。

それぞれの強みと限界を、私たちが現場で見てきた実態に基づいてお伝えします。

コンサルティング会社の場合

計画を作るプロです。どの部署にAIを入れるべきか、投資対効果はどれくらいか。経営判断の材料を揃えてくれます。私たちのお客様の中にも、「まずコンサルに戦略を作ってもらった」という企業は多くいらっしゃいます。

ただし、計画書を渡した後は去っていきます。「実際に作って現場に定着させる」は守備範囲外です。

ある化粧品メーカーのDX推進室長がこう言っていました。「コンサルが作ったロードマップは正しかった。でも、それを現場に持って行ったとき、『で、具体的に何をすればいいの？』と聞かれて、誰も答えられなかった」。

これは、コンサルが悪いのではありません。コンサルの仕事は「何をすべきか」を示すことであり、「どうやるか」を現場で実行することではないのです。

システム開発会社（SIer）の場合

システムを作るプロです。仕様が固まっていれば、堅牢なシステムを着実に納品してくれます。会計システムや勤怠管理のような、決まったルールで動くシステムを作る力は、SIer に勝るものはありません。

ただ、AIには厄介な特性があります。同じ入力をしても出力が毎回少し違うのです。「仕様通りに動く」を保証しにくい領域では、従来の受託開発モデルはどうしても苦しくなります。

私たちがよく聞くのは、「納品後に問題が見つかっても、修正するたびに追加見積もりが必要で、結局そのまま放置してしまった」という声です。AIは継続的な調整が前提ですから、「納品して終わり」のモデルとは相性が悪いのです。

FDE の場合

FDE は、ここの隙間を埋めます。計画も立てるし、コードも書く。何より、現場で一緒に使いながら調整し続けます。報告書ではなく「動いて使われているシステム」が成果物です。

コンサルが見つけた課題を、SIer が作るのではなく、FDE が現場で一緒に解決する——と考えていただくと分かりやすいかもしれません。

	コンサル	SIer	FDE
渡すもの	計画書	完成したシステム	動くシステム + 定着支援
関わる期間	計画完了まで	納品まで	使われるようになるまで
現場に入るか	入らない	必要時のみ	常にいる
AI の微調整	対象外	追加費用	日常的にやる
成果の測り方	報告書の品質	システムの完成度	現場の行動変化

誤解のないように申し上げると、コンサルやSIerが「悪い」わけではありません。役割が違うだけです。戦略フェーズにはコンサル、安定したシステムの開発にはSIer、AIを現場に定着させるにはFDE。この使い分けが大事になります。

実際、私たちの案件でも、コンサルが作った戦略を引き継いで FDE として実装に入るケースは少なくありません。戦略→実装→定着のリレーが理想形だと考えています。

なぜ今、急に注目されているのか

理由はシンプルです。AIが「デモでは動くけど現場では動かない」という壁にぶつかる企業が増えたからです。

従来のITシステムは決定論的でした。ボタンを押せば、毎回同じ結果が返ります。だからウォーターフォール型の開発——要件を決め、設計し、コードを書き、テストして納品する——で問題なく回っていました。仕様書さえ正確なら、期待通りのものが出来上がります。

ところがAIは確率的に動きます。同じ質問に対する回答が、毎回微妙に違う。「昨日は正しく答えたのに、今日は的外れなことを言っている」ということが普通に起きます。この「揺れ」に現場が戸惑い、結局 Excel に戻る——というのが、冒頭で紹介したパターンです。

この構造的な問題に、世界のAI企業が一斉に動き始めています。MarkTechPost の報道によれば、OpenAI は2026年5月にFDE専門のデプロイメント会社を設立し40億ドル以上を調達、Anthropic も Blackstone や Goldman Sachs と15億ドルの合弁事業を発表しています。「AIを作る会社」が、こぞって「AIを現場に届ける部隊」への投資を始めたのです。

日本でも動きは加速しています。LayerX は2025年7月にFDE ポジションの募集を開始し、SHIFT は「アドバンスドFDE」サービスを2026年1月にリリースしました。大手コンサルファームでさえ、自社内にFDE組織を新設し始めています。

Goodpatch の記事が興味深い指摘をしています。FDE がコンサルと決定的に違うのは、「得た知見をプロダクトにフィードバックし、再利用可能な資産として蓄積する」点だといいます。コンサルの知見は報告書に閉じますが、FDE の知見はシステムの中に残ります。これは私たちの実感とも完全に一致しています。

正直なところ、一番難しいのは技術ではありません

私たちは AI-Path の創業以来、FDE モデルで製造業を中心に数十社の現場に入ってきました。その中で痛感していることがあります。

一番時間がかかるのは、技術ではなく「責任の線引き」です。

壁その1：「誰が判断するのか」問題

たとえば、ある工場で不良品検知のAIを導入した時の話です。AIが「この部品、不良です」と判定しました。さて、ラインを止めるのは誰でしょうか。AIの判定を信じて止めるのか、それともベテランの目視確認を待つのか。

ここの答えは、技術では出ません。工場長と品質管理の責任者と、私たちとで何度も話し合って決めました。最終的に採用したのは「AIの判定は全数記録するが、ラインを止める判断は当面ベテラン検査員が行う。AIの精度が一定水準を超えた段階で、AI単独判定に移行する」というルールです。

このルール作りに、技術の実装よりも多くの時間がかかりました。でも、これがなければ現場はAIを信頼してくれません。

壁その2：「データはあるけど使えない」問題

もう一つ、データの問題があります。「うちはデータならたくさんありますよ」と言ってくださる企業は多いのですが、実際に見ると厳しい状況がほとんどです。

部署ごとにExcelのフォーマットが違う。同じ「不良品」でも、品質管理課と製造課で定義が違う。「正常」の基準が課長と係長で異なっている。こうした状況を整理するところから始めるケースが大半です。

あるお客様では、過去5年分の品質データを「使えるデータ」に変換するのに3週間かかりました。しかし、この3週間があったからこそ、その後のAI構築が2週間で済んだのです。

壁その3：「全社導入」の罠

3つ目の壁は、意外にも経営層の側にあります。「やるなら全社で」「投資するなら大きく」と考えがちですが、AI導入においてこのアプローチは私たちの経験上、ほとんどうまくいきません。

全社導入計画を立てると、要件定義に半年、開発に1年、全部署への展開にさらに半年。その間にAI技術は世代交代し、当初の前提が崩れます。

私たちが推奨しているのは「1つの部署の、1つの業務に絞って、2週間で動くプロトタイプを作る」アプローチです。小さな成功体験が現場の「やってみよう」を引き出し、そこから自然に広がっていきます。

だからこそ、現場にいないと分からないのです。外からシステムを作って納品する方式では、この「泥臭い調整」ができません。

AI-Path の FDE はどのように動くのか

ここで、私たちの具体的な動き方をお伝えします。「FDE って実際には何をしてくれるの？」という疑問にお答えするためです。

フェーズ1：無償の業務プロセス診断

まず、お客様の現場課題をヒアリングし、業務プロセスの中で「AIが効きそうな箇所」を特定する業務プロセス診断（BPR：Business Process Re-engineering）を無料で実施します。

この診断では、現場の業務フローを整理し、AIによる効率化が見込める工程とその優先順位をレポートとしてお渡しします。「何から始めればいいか分からない」という段階でも、この診断で具体的な次のステップが見えてきます。

フェーズ2：NDA締結→本格開発（1〜3ヶ月）

技術検証の結果を踏まえて、NDA（秘密保持契約）を締結し、実データを使った本格的な開発に入ります。

この段階では、週次で現場の方とミーティングを行い、「作る→試す→直す」のサイクルを回し続けます。仕様書を最初に固めるのではなく、現場の反応を見ながら育てていくアジャイル型の開発です。

フェーズ3：技術顧問契約→自走化

システムが現場に定着し始めたら、月額の技術顧問契約に移行します。月次の定例会で課題を拾い、必要な改善を継続的に行います。

最終的なゴールは「私たちがいなくても回る状態」を作ることです。お客様のチームにノウハウを移転し、自社で運用・改善できる体制を構築します。これを私たちは「自走化」と呼んでいます。

正直に申し上げると、「ずっと依存してもらったほうが売上は立つ」のですが、それは私たちの哲学に反します。お客様が自走できるようになることが、最も大きな成果だと考えています。

FDE 型のパートナーが合うかどうか、3つの質問

経営者の方から「うちに FDE は必要ですか」と聞かれたとき、私たちはこの3つを確認しています。

① AIの試作品を作ったが、現場で使われていない案件がありますか？

あるなら、まさに FDE の出番です。技術の問題ではなく「定着」の問題です。現場に入る人間がいれば解決できる可能性が高いと考えています。コンサルに追加で戦略を作ってもらっても、この問題は解決しません。必要なのは、現場で一緒に汗をかく人間です。

② 現場の業務を、外部の人間に説明しきれますか？

「説明しきれない暗黙知がある」なら、報告書ベースのアプローチには限界があります。隣に座って一緒に見ないと分からない業務は、FDE 向きです。

逆に、業務フローが明確にマニュアル化されていて、仕様書に落とし込めるなら、SIer に発注するほうが合理的かもしれません。FDE は「仕様が書けない仕事」にこそ価値を発揮します。

③ 「小さく始める」ことに抵抗はありませんか？

FDE は全社導入計画を立てる仕事ではありません。1つの部署の1つの業務で成功体験を作り、そこから広げていくアプローチです。

最初から取締役会で承認が必要な規模の投資を想定されているなら、コンサルに戦略を作ってもらうほうが先かもしれません。ただし——これは私たちの経験から率直に申し上げますが——AI導入で「最初から大きく」は、ほぼうまくいきません。

よくある質問

「FDE を入れると、いくらかかるの？」

費用体系は案件によりますが、AI-Path の場合、まず無償の業務プロセス診断（BPR）で「どこにAIが効くか」を特定するところから始めます。その後の本格開発は、規模にもよりますがMVP（最小限の動くシステム）までを一括で、その後は月額の準委任契約で対応するケースが多いです。

大手コンサルの戦略策定費用（数千万円）と比較すると、「動くもの」が成果物になる分、費用対効果は実感しやすいと思います。

「うちは製造業じゃないんだけど、FDE は使えるの？」

使えます。私たちは製造業での実績が最も多いですが、建設業のDX推進、食品メーカーの提案資料自動化、卸売業の基幹システム刷新など、業種を問わず対応しています。

FDE が効果を発揮する条件は業種ではなく、「現場に暗黙知がある」「AIの出力を業務に組み込みたい」「既存のシステムが合っていない」といった課題の性質です。

「社内にエンジニアがいないんだけど大丈夫？」

大丈夫です。むしろ、社内にエンジニアがいない企業こそ FDE の価値が高いと言えます。FDE は「お客様のためのエンジニア」ですから、お客様側にエンジニアは不要です。

ただし、「自走化」のフェーズでは、お客様側にもシステムを理解するメンバーが必要になります。私たちはその育成もサポートしています。IT の専門家でなくても構いません。現場の業務を一番よく知っている方が、AIの使い方を覚えるほうが、外部のエンジニアを雇うよりはるかに効果的です。

「どんな業務がFDEに向いているの？」

私たちの経験では、以下のような業務でFDEの効果が特に高いと感じています。

• 判断のばらつきがある業務。 担当者によって判断が異なる品質検査、見積作成、レポート作成など。AIが「基準」を提供し、FDEが現場への落とし込みを支援します
• 暗黙知が属人化している業務。 ベテラン社員の頭の中にしかないノウハウ。退職や異動で失われるリスクがある知識を、AIで形式知化します
• 繰り返しの手作業が多い業務。 毎月の報告書作成、データ入力、メールの定型返信など。ただし「完全自動化」ではなく「人間の判断を補助する形」で導入するのがポイントです
• 既存のSaaSが合っていない業務。 「システムに業務を合わせている」状態であれば、FDEによるオーダーメイド開発で業務効率を大幅に改善できる可能性があります

まず試すなら

1. 社内で「AI入れたけど使われていない」案件を1つ挙げてみてください。 その案件が FDE に最も向いています
2. 現場の担当者に「何が面倒か」を聞いてみてください。 AI 導入は経営課題ではなく、現場の困りごとから始めたほうがうまくいきます
3. 「まず業務プロセスを診てもらえますか」と聞いてみてください。 いきなり開発に入るのではなく、業務フローの整理から始めてくれるパートナーを探しましょう

AI-Path では、無償の業務プロセス診断（BPR）を実施しています。「自社のどの業務にAIが効くのか」を、現場のヒアリングと業務フロー分析を通じて明らかにします。お気軽にお問い合わせください。

FDE が変える「AI投資」の考え方

最後に、FDE の導入が経営にもたらすインパクトについて触れておきます。

従来のAI投資は「プロジェクト型」でした。数千万円の予算を確保し、半年〜1年かけて開発し、完成品を現場に導入する。うまくいけば大きなリターンが得られますが、失敗した場合の損失も大きい。しかもAI領域では、先ほど述べた通り「使われない」リスクが極めて高いのです。

FDE モデルは、この投資構造を根本的に変えます。

初期投資が小さい。 無償の業務プロセス診断から始まるため、「どこにAIが効くか」を見極めてから投資判断ができます。数千万円のプロジェクトを承認する前に、まず現場の業務フローを整理するところから始められます。

投資が段階的。 MVPまでの一括費用の後は、月額の準委任契約です。効果が出なければ止められますし、効果が出れば範囲を広げられます。年間契約で縛られることはありません。

成果が早く見える。 報告書を待つ必要がありません。2週間でプロトタイプが動き、1〜3ヶ月で現場が使い始めます。投資判断のサイクルが格段に速くなります。

知見が社内に残る。 コンサルの知見は報告書に閉じ、SIer のコードは「ブラックボックス」になりがちです。FDE は最初から「お客様のチームが自分で運用できる状態」をゴールに設計します。FDE が去った後も、システムとノウハウは社内に残ります。

ある建設会社の役員がこう表現してくださいました。「FDE は、AI投資のリスクを分割してくれる存在だ。一発勝負のプロジェクトではなく、小さな実験を積み重ねて、確信を得てから大きく投資できる」。

これは私たちが目指しているまさにその形です。

AI時代の「パートナー選び」は変わる

ここまで読んで、「うちにもFDEが必要かもしれない」と思った方もいれば、「うちはまだコンサルの段階だな」と思った方もいるかもしれません。どちらも正しい判断です。

大事なのは、AI導入には「作る」だけでなく「定着させる」フェーズがあると認識することです。そして、そのフェーズにはそのフェーズに適したパートナーがいるということです。

戦略を立てる段階ならコンサル。安定したシステムを作る段階ならSIer。AIを現場で使えるようにする段階ならFDE。この3つの選択肢を知っていること自体が、AI投資の成功確率を上げます。

私たちAI-Pathは、FDEモデルでお客様の現場に入り続けます。「報告書より動くもの」「計画より成功体験」「完璧より早さ」。この姿勢で、AIが現場で本当に使われる世界を作っていきたいと考えています。

参考リンク

• FDE（フォワードデプロイドエンジニア）とは何か - Goodpatch Blog
• AI導入成功のカギを握る次世代エンジニア"FDE"とは？ - ソフトバンク