なぜ今FDEなのか：AI実装を成功させるのは「現場の力」

多くの企業はいまだに、AIモデル、特にLLMを導入さえすれば、あらゆる課題が解決すると期待しています。しかし、現実はそう甘くありません。最近のMITのレポートによれば、世界中の企業の95％が生成AI（GenAI）を導入しているにもかかわらず、具体的な成果を何一つ生み出せていないとされています。総額400億ドルにも及ぶ莫大な投資が行われたにもかかわらず、AI導入に成功している企業がわずか5％にとどまるのはなぜでしょうか。その理由は、AIは「導入して終わり」のソフトウェアではなく、現場で継続的に磨き上げていくべき技術だからです。近年注目を集めているフォワード・デプロイド・エンジニア（Forward Deployed Engineer、以下FDE）は、まさにこの課題意識から生まれた存在です。

FDE（Forward Deployed Engineer／前方配置エンジニア）とは？

今年11月、Financial Times により2025年1月から9月にかけて、フォワード・デプロイド・エンジニア（FDE）の求人件数は800％以上増加したという報道がなされ、世界的にFDEが本格的に注目され始めました。当該記事では、OpenAI、Anthropic、Cohereといった主要AI企業が、研究中心の組織から商用化（プロダクション）中心の人員構成へとシフトしていることが伝えられています。

FDEは、顧客の現場に直接入り込み、AIが実際の業務フローの中で機能するところまでを最後まで責任を持って担う役割です。一般的なエンジニアがオフィスでソフトウェアやプロダクトを開発するのに対し、FDEはその名の通り、「前線（Forward）」、すなわち顧客企業の現場に「配置（Deploy）」されます。単にコードを納品するだけではなく、顧客の現場における複雑なビジネス文脈を理解し、その場で技術的な解決策を設計・実装する点が特徴です。

現場配置エンジニア、あるいは企業派遣エンジニアとも呼ばれるFDEは、データ構造やシステムだけでなく、組織の働き方そのものまでを含めて調整し、AI導入を完成させる役割を担います。OpenAI や Palantir といったグローバルAI企業が、FDEを戦略的な職務として位置づけ、積極的な採用に踏み切っているのも、そのためです。いまやAIの成否は、モデルの性能ではなく、「現場で実装し、機能させる力」によって分かれ始めています。では、シリコンバレーで生まれたこれらの企業は、なぜエンジニアを「現場」へ送り出すようになったのでしょうか。

 

汎用AIの代表格・OpenAIは、なぜ今FDEに注目しているのか？

本稿を執筆している現在（2025年12月22日）時点でOpenAI の採用ページを確認すると、ニューヨーク、サンフランシスコをはじめとする米国主要都市に加え、パリ、ミュンヘン、ダブリン、ロンドンといった欧州、さらに東京、シンガポールまで、世界各地で合計28件のFDEポジションが募集されています。特に注目すべき点は、採用要項においてOpenAIがFDEの役割を「研究成果を実際の運用システム（production system）として実装すること」と明確に定義していることです。汎用AIを代表するOpenAIが、FDEを単なる「モデルの引き渡し役」ではなく、「現場でプロダクションを完成させる存在」として位置づけている事実は、AIの勝負どころがどこへ移りつつあるのかを端的に示しています。

こうした変化が単なる採用トレンドではないことは、OpenAI のグローバルFDE責任者である コリン・ジャービス のインタビューから、より鮮明に読み取れます。彼は Altimeter Capital Podcast に出演し、「FDEの使命はコンサルティング（service）ではなく、顧客の課題を解決する“再利用可能な製品（product）”を生み出すことだ」と強調しました。また、ChatGPTのリリース以降、期待は大きく高まった一方で、汎用化を優先する従来のアプローチでは、複雑な課題を抱える企業を実際のプロダクション段階まで導くには限界があったとも振り返っています。OpenAIがこうした限界を現場で痛感したことこそが、FDE組織誕生の出発点となりました。

コリン・ジャービスはさらに、「FDEは短期的で安易なコンサルティングの誘惑を警戒すべきだ」と述べ、重要なのはサービス提供ではなく、“製品化可能な解法”を作り出すことだと明確にしています。その文脈で彼は、Palantir の有名な言葉、「私たちは複雑さという痛みを飲み込み、現場で本当に機能する製品を世に送り出す（We ingest the pain of complexity to ship products that actually work in the field）」を引用しました。

では、なぜOpenAIのグローバルFDE責任者は、Palantirの言葉を引用したのでしょうか。答えはシンプルです。FDEという職務概念をいち早く体系化し、核心的な組織として発展させてきた企業こそがPalantirだからです。Palantirは、政府・防衛・製造といった極めて複雑な産業現場でAIとソフトウェアを実際に機能させるため、早くからFDEを戦略組織として位置づけ、事業を拡大してきました。

Palantirは、なぜFDEを生み出したのか？

Palantir の Foundry、Gotham、AIP といった製品は、「インストールすればすぐに動く汎用ソフトウェア」とは性質を異にします。政府・防衛・製造といった、データ構造が極めて複雑で、かつ高いセキュリティ制約が課される環境において、実際に稼働し続けなければならない運用システムに近い存在だからです。問題はここから始まります。シリコンバレーのオフィスで作られた「優れた製品」だけでは、顧客固有のワークフローやデータの地形を、最後まで掌握することは難しい。その結果、Palantirは一つの結論にたどり着きます。

「人が現場に入り、そのための役割を設けなければならない」

Palantirはすでに2019年の公式ブログ「Dev versus Delta: Demystifying engineering roles at Palantir」において、この役割をForward Deployed Software Engineer（以下、FDSE）として定義しました。社内ではこの職能を「Delta」と呼んでいます。同じエンジニアであっても、DevとDeltaでは、そもそも重視する視点が異なります。Devが「一つの機能を多くの顧客へと横展開する人」だとすれば、Deltaはその逆で、「一人の顧客に対して複数の機能を組み合わせ、成果を出す人」です。 Devがプラットフォームそのものを作る役割だとすれば、Deltaはそのプラットフォームを顧客環境に配備・構成し、現場の問題を解決する役割に近い、とPalantirは説明しています。

ここでもう一つ、重要なポイントがあります。Deltaはコンサルタントではない、という点です。この誤解があまりに根強いため、Palantirは2019年以降、公式ブログを通じて繰り返しこの点を明確にしてきました。コンサルティングがしばしば「分析・提言・単発の解決策」にとどまるのに対し、Deltaは、Palantirの製品に限らず、複数のプログラミング言語、オープンソースツール、ビルドツール、さらには個人の創造性までも総動員して解決策を作り上げる存在だと説明されています。そしてこの考え方は、今日OpenAIが語るFDEの定義とも、驚くほど正確に重なっています。

だからこそ、「現場」が中核になります。Palantir のFDSEへのインタビューを収録した「A Day in the Life of a Palantir Forward Deployed Software Engineer」（2020年公開）では、この点がより直接的に示されています。 同記事によれば、FDSEは顧客の最も深い現場に密着し、Palantirの既存ソフトウェア・プラットフォームを構成（configure）することで、最難関の課題を解決する役割を担います。Devが「一つの機能」を作るのに対し、FDSEは「特定の顧客の一つの現場」で複数の機能を組み合わせ、即座に動く解法を作り上げるのです。 言い換えれば、Palantirが言う前方配置とは「出張」ではなく、製品を現実に適合させて機能させるための“最後の1km（ラストマイル）”だと言えます。

さらに、Palantir共同創業者が設立したシリコンバレーのベンチャーキャピタル 8VC による「The AI Services Wave」 を読むと、Palantirがこのモデルを組織戦略として採用した理由がより鮮明になります。Palantirが重視する核心概念は「ビジネス・オントロジー（ontology）」です。複雑な組織では、データが多様な形式やシステムに分散しており、オントロジーはそれらの複雑なワークフローをデータ―ロジック―アクションへとマッピングし、何を優先して研究開発（R&D）すべきかまでを決定します。そして、この一連のプロセスの前提となるのが、現場に深く入り込み、課題を共に定義する顧客との高密度な協業です。

まとめると、PalantirがFDSEを生み出した理由は次の一点に集約されます。それは製品が弱かったからではなく、製品が「現場で完成する性質」を持っていたからです。現場に入り込み、複雑さを飲み込み、その複雑さを再び製品へと吸収する――そうすることで、次の顧客に対しては、より速く、より少ない労力で同じ価値を提供できるようになります。PalantirのFDSEはまさにその役割を担う組織であり、これは単なる一つの「職務」ではなく、プロダクト拡張のためのスケール戦略として理解することができます。

 

なぜ今、企業のAI導入にFDEが重要になっているのか

AI技術は3.4か月ごとに2倍の速度で進化していると言われていますが、それを実際の業務成果につなげている企業はごくわずかです。MITが発表した The GenAI Divide: State of AI in Business 2025 レポートによると、「生成AI導入には数十億ドルが投資されたにもかかわらず、95％の企業が測定可能な成果を得られていない」と指摘されており、このギャップは GenAI Divide と呼ばれています。実際、多くの企業はChatGPTのような汎用LLMを業務で「試してみる」段階には進んだものの、その多くはパイロット段階にとどまりました。**統合型AIパイロット（Integrated AI pilots）のうち、本番運用に移行し実際の成果を生み出した企業はわずか5％に過ぎません。**この状況から「AIバブルではないか」という議論も生まれましたが、実際にはAIを本番環境まで展開できていない組織が多いことを意味しています。

**MITレポートが投げかける本質的な問いは、「なぜ失敗するのか」ではなく、「どのような選択をすればこのギャップを乗り越えられるのか」という点です。**その答えは意外なほど明確です。インタビュー調査によると、自社開発（Build）で実際の運用まで到達した割合は約33％にとどまったのに対し、外部パートナーシップ（Buy）は約67％と、成功率が2倍に達しました。これは単に「外部の方が優れている」という意味ではありません。重要なのは、AIを実際の運用まで届けるための体制を最初から組んでいるかどうかです。パートナーシップ型のプロジェクトは、パイロットから本番運用への移行率が高く、実際の利用率（usage）も高い傾向にありました。また、Time-to-Value、総コスト、既存の業務ワークフローとの整合性といった面でも有利であると報告されています。

つまり、成功する企業と失敗する企業の差を生み出している本質は、現場への適応と運用への定着にあります。失敗の原因は技術不足ではなく、AIが組織のワークフロー・データ・人の文脈に合わせて学習し続け、適応していく仕組みを持てなかったことにあります。どれほど優れたモデルであっても、それだけで企業の実務システムの中に自然に組み込まれて機能するわけではありません。そのためMITは、「完璧なツールを待つのではなく、内部プロセスに合わせて深くカスタマイズし、現場導入まで伴走できるパートナーシップ」を重視すべきだと指摘しています。

この現実は、国内企業にもそのまま当てはまります。日本の大企業はこれまで、大手SI（System Integrator）の力を活用しながら、基幹システムを自社で構築・運用することで安定性と統制力を確保してきました。しかし、AI時代の技術内製化には、これまでとはまったく異なるパラダイムが求められます。技術スタックは急速に細分化され、新しい技術や標準が次々と登場します。従来のSI型プロセス（要件定義 → 設計 → 開発 → 展開）は、このスピードと不確実性を構造的に吸収することができません。要件に合わせて作ったものをようやくデプロイする頃には、現場のニーズや技術標準はすでに進化しており、「完成した時点で古いもの」になってしまうことも少なくありません。さらに、多くの産業現場で蓄積されたAI導入の実践知（Field Experience）は短期間で再現できるものではありません。 現場からのフィードバックループがないまま「自社だけでできる」と考えることは、むしろ導入スピードを遅らせ、最先端のAI技術から組織を孤立させてしまうリスクさえあります。

だからこそ、このレポートの結論は「BuildかBuyか」という単純な選択ではなく、AIを最後までデプロイし運用まで到達させる実行組織が存在するかどうかに集約されます。ベンダーのデモやPoCは短期間で終わりますが、実際の現場ではデータ権限、セキュリティ、レガシーシステム連携、業務プロセス、責任分担といった現実の複雑さが立ちはだかります。その瞬間、多くのプロジェクトが止まってしまうのです。FDE（Forward Deployed Engineer）は、まさにこの地点で重要な役割を果たします。Buy戦略を単なる「導入」で終わらせず、「定着」と「運用」へと変える、デプロイ実行の戦略レイヤーとなる存在です。つまり、Buyは意思決定であり、FDEはその意思決定を現場に着地させる方法です。パートナーシップが成功確率を2倍に高めるというMITの結論も、突き詰めれば現場でデプロイを完遂できる組織（FDE）が存在する場合にのみ現実になると言えるでしょう。

MakinaRocks のFDE―「産業特化AI」を現場で完成させる

MakinaRocks は、2017年の創業以来、製造・防衛といったミッションクリティカルな産業現場を中心にAIプロジェクトを手がけてきた、産業特化AI（Vertical AI）の第一世代企業です。こうした現場では、データの相関関係が必ずしも明確ではなく、システムは複雑で、セキュリティや責任の所在も極めて厳格に管理されます。そのため、産業現場におけるAIは、「良いモデル」だけでは決して完成しません。最終的な勝敗を分けるのは、現場で課題を定義し、データを整備し、運用システムに組み込んで“最後まで回し切る”実行力です。MakinaRocksがFDEを「選択肢」ではなく「中核組織」として再編した理由も、まさにここにあります。この方針のもと、MakinaRocksは、これまで顧客現場で担ってきた導入・運用中心の業務を高度化するため、2024年初頭にRunway開発本部の下にDeltaチームを新設しました。その後、この組織を戦略的に拡張し、現在はFDE本部体制として運営しています。現在、AIエンジニア、プロジェクトマネージャー、ソフトウェアエンジニアなど約50名のメンバーがFDE本部に所属し、顧客企業の現場の最深部に入り込み、最も複雑な課題に伴走して取り組んでいます。ここで言う「現場」とは、データへのアクセス権限やセキュリティ制約、レガシーシステムとの連携、現業プロセス、責任の所在といった要素が複雑に絡み合う環境の中で、プロダクションを完成させる場所を指します。

成果は数字にも明確に表れています。MakinaRocks のFDEは、2025年の1年間だけで、半導体・エネルギー・バッテリー・防衛といったミッションクリティカルな産業現場において、123件のプロジェクト（課題）を遂行しました。その中には、すでに実際のプロダクション環境に到達している案件もあれば、商用化を目前に控えた案件、さらには数年単位で進行する先行プロジェクトも含まれています。重要なのは、プロジェクトの「数」そのものではなく、その過程で蓄積された現場起点の実行ノウハウ（Field Experience）です。こうしたノウハウは、報告書やマニュアルによって容易に複製できるものではありません。実際に現場へ入り、課題を再定義し、繰り返しフィードバックを受けながら、運用システムが耐えうる形へと磨き上げていく――そのプロセスを通じてのみ、初めて蓄積されるものです。

もう一つ注目すべき変化は、今年、MakinaRocksがAIエージェントの実運用環境への商用展開を本格化している点です。2025年の1年間で「現場」に実装・商用化されたAIエージェントは20件超にのぼり、これらは一般的な対話型AIではなく、予知保全・需要予測・工程最適化などの複合タスクを担うマルチエージェントです。そして、こうした実行を支える基盤となっているのが、MakinaRocksの中核製品である Runway です。Runwayは単なるモデル導入ツールにとどまらず、「現場」に必要なデータフローや運用構造を標準化することで、解決策をより迅速に構築し、再利用可能な形で展開できるプラットフォームへと進化しています。

生成AIは、すでに十分に強力な段階へと到達しました。いま企業に突きつけられている課題は、「良いモデルを選ぶこと」ではありません。GenAI Divideを乗り越え、モデルを配備・運用し、現場に“着陸”させて実際の成果へと結びつけることです。その成否を分けるのは、現場で最後までプロダクションを完成させきる実行組織を持っているかどうかに他なりません。

だからこそ今、企業のAI導入においてFDEの重要性は極めて高いのです。FDEは「コンサルティング」ではなく、顧客の複雑性を飲み込み、その複雑性を再び“製品”と“運用システム”の中へと吸収し、次の配備をより速くするための戦略組織だからです。AIが本当に「仕事になる」瞬間は、プレゼン資料の中ではなく、現場で生まれます。いまや競争力の源泉は、モデルではなく“現場実装力”です。そして MakinaRocks は、その競争力を、FDE組織を通じて、最もAIネイティブな企業として、そして最も産業現場に密着したかたちで証明していこうとしています。