FDE（Forward Deployed Engineer）とは？AI導入を定着させる伴走型エンジニアと受託・SESとの違い

名前の由来と「FDE型の支援」という使われ方

Forward Deployedは「前線に配置された」という意味です。開発拠点にとどまらず、顧客の現場という前線に配置されて働くことから、この名前が付いています。

もともとは、自社の製品を持つ企業が、その製品を顧客の業務に定着させるために配置する職種です。現在は職種名としてだけでなく、開発支援会社が顧客のチームに入り込んで実装から定着までを担う支援の進め方を「FDE型」と呼ぶ使われ方も広がっています。

Palantirで生まれた「Dev」と「Delta」

FDEの起源は、データ分析基盤を提供するPalantirが2000年代後半から2010年代初頭にかけて確立した役割です。社内ではNATOのフォネティックコードにちなんで「Delta」と呼ばれ、製品を開発する「Dev」と対になっています。Devが1つの機能を多くの顧客に届けるのに対し、Deltaは1つの顧客の現場に入り、自社のプラットフォームを実際の業務に合わせて実装し、定着させます。現場で得た学びは製品の開発チームに還流され、製品そのものの改善につながります。

この「現場で実装し、学びを製品に戻す」仕組みが、現在のAI企業のFDEの原型です。生成AIの普及とともに、FDEは職種名から業界の共通語へと広がりました。その背景を次に見ていきます。

導入は進んだが、成果が出ている企業は少ない

AIを使い始めた企業の割合と、成果を出せている企業の割合の差が、2025年から2026年にかけて各調査で繰り返し示されています。

Gartnerは2025年6月に、AIエージェントのプロジェクトの40%超が2027年末までに中止されると予測し、理由としてコストの増大、価値の不明確さ、リスク管理の不備を挙げています。導入そのものではなく、本番に載せて使い続ける工程に壁があることが、これらの数字の共通点です。

AI導入が止まりやすい4つの場面

調査が示す「導入と成果の差」は、現場では次のような場面として現れます。

• AIツールを契約したものの、現場の業務に組み込まれず使われない。MITの調査は、モデルの性能ではなく、AIが業務の流れを学習・適応できないことを主因に挙げています
• 試作品（PoC）では動いたが、本番のデータや権限の制約に対応できず本番に載らない。Deloitteは本番運用11%に対し試行中38%という差を報告しています
• 既存システムや業務ツールとつながらず、手作業の転記が残る。国内調査でも定着を阻む要因の1位は「社内データと未接続」でした
• 作った人がいなくなると、誰も運用や改善を続けられない。中堅企業には最先端のAIを社内で構築・運用し続ける人材がいないことが、AI企業が長期支援の専業組織を作る理由にもなっています

いずれも技術単体の問題ではなく、業務・データ・運用体制にまたがる問題です。この溝を現場で埋める役割として、FDEが求められています。

AI企業がFDEの専業組織と育成に投資している

2026年に入り、FDEは「AI企業が採用する職種」から「専業組織・パートナー網・育成プログラム」へと段階が上がりました。主な動きは次のとおりです。

注目したいのは、FDEをAI企業の社内に抱えるだけでなく、パートナー企業に担わせ、育成する動きが公式になった点です。モデルを提供する企業自身が「導入して定着させる人材」を最大のボトルネックと見ており、その担い手が外部の支援会社にも広がっています。

型1：AIベンダー・プラットフォーム企業のFDE

自社の製品を顧客の業務に定着させるために配置される、Palantir以来の原型です。2026年6月にはSalesforceがFDE Partner Networkの日本展開を発表し、NTTデータ・富士通・アクセンチュア・デロイト トーマツ・PwCコンサルティングなど9社が初期パートナーとして参加しました。AI企業が日本拠点でFDEを募集する例も出ています。製品の活用が目的のため、支援の範囲はその製品が中心になります。

型2：大手SIer・コンサルティング会社のFDE組織

日経クロステックは2026年8月、日立製作所・富士通・NEC・NTTデータの4社がFDEの拡充に意欲を示していると報じました。日立製作所は2026年度内に国内で1,000人のFDE体制を目指すとしています。背景にあるのは「脱・人月」、つまり作業時間で対価を受け取るSIの構造から、成果で価値を出す形への転換です。大規模な基幹システムを含む案件に向きますが、体制も大きくなります。

型3：開発支援会社のFDE型支援

2026年6月から9月にかけて、中小のAI開発支援会社が「FDE型AI内製化支援」「現場FDE支援」といった名称でサービスを相次いで始めました。特定の製品に縛られず、エンジニアが発注企業の開発チームに入り、業務整理から実装、社内への展開までを伴走する形です。GinTrickの伴走型開発支援もこの型に当たります。少人数で機動的に動ける一方、会社ごとに支援範囲の定義が異なるため、後述する選び方の観点で見極めることが大切です。

日本の客先常駐（SES）との共通点と違い

日本では、エンジニアが発注企業の現場で働く形として客先常駐（SES）が長く定着しており、FDEとの共通点と違いが議論になっています。共通するのは、発注企業の現場に入り、その企業の環境と業務に合わせて働く点です。

違いは3つあります。第一に、SESは発注側が決めた作業を時間単位で担うのに対し、FDEは何を作るべきかの課題設定から参加します。第二に、SESの評価は稼働時間ですが、FDEの評価は本番稼働や利用の定着という成果です。第三に、FDEは現場で得た知見を手順書や環境としてチームに残し、支援後も使われる資産に変えます。現場に入るという形は似ていても、責任の終点と残るものが違います。

FDEの仕事の中身

FDEがコードを書くのは、仕事の時間の半分ほどです。残りは、業務プロセスの把握、関係者との調整、開発や運用の環境整備にあてられます。

仕様が曖昧な段階から現場で仮説を立て、動くものを見せながら検証します。短いサイクルで改善版を出し、現場の反応を次の改善に反映させます。この繰り返しで、使われる仕組みに近づけていきます。

FDEの仕事の流れ

2026年のFDEが扱う仕組み：接続・指示ファイル・ガードレール

生成AIを業務に組み込む工程では、2025年末から2026年にかけて共通の仕組みが標準として定まりつつあります。FDEはこれらを顧客の環境に合わせて組み上げます。

• 既存システムとの接続：AIエージェントが社内のデータやツールにつながるための共通規格としてMCP（Model Context Protocol）が広がり、2025年12月にはLinux Foundation傘下の財団に寄贈されました。「社内データと未接続」という定着の壁を越える土台です
• エージェントへの指示ファイル：AIコーディングエージェントにプロジェクトの前提や規約を伝えるファイル（CLAUDE.md・AGENTS.md）をリポジトリに置き、チームで共有する運用が定着しました。AGENTS.mdは6万を超えるプロジェクトで採用されています。再利用できる手順はskills、必ず実行させたい検査はhooksとして分けて持たせます
• ガードレールと権限：AIエージェントに与える権限と自律性を必要最小限にする考え方（OWASPが2026年版の指針で「Least Agency」と呼ぶ原則）と、高リスクな操作の前に人が確認する設計（Human in the loop）が、Anthropic・OpenAIの公式ガイドでも推奨されています

これらは「作った人がいなくなっても回る」状態をつくるための仕組みでもあります。指示ファイルと手順書がリポジトリに残り、ガードレールが誤操作を防ぐことで、支援後もチームが安全に使い続けられます。

FDEに求められる3つのスキル

1. 本番で動かせる技術力

フロントエンドからバックエンド、クラウドまでを横断して実装できる力です。生成AIを扱う現場では、LLMやAIエージェントを業務システムに組み込む力と、アクセス権限や監視など本番運用に必要な設計の知識も欠かせません。

2. 業務を理解し課題を設定する力

顧客自身も何を作るべきか言語化できていない段階から、業務の流れを分解し、どこに手を入れれば成果が出るかを見極める力です。技術の選択は、この課題設定の質に左右されます。

3. 現場を巻き込む合意形成の力

作った仕組みが使われるかどうかは、現場の担当者や意思決定者の納得にかかっています。優先度やリリース日を顧客と直接すり合わせ、変化を受け入れてもらうためのコミュニケーションもFDEの重要な仕事です。

比較表で見るFDEと受託開発・SES・コンサルティングの違い

「責任の終点」で比べる

戦略コンサルティング：提言まで

課題の分析と、あるべき姿や施策の提言までを担います。提言を実装し、現場で動かす工程は別の担い手に引き継がれます。

受託開発：納品まで

合意した仕様どおりのシステムを完成させ、納品するまでを担います。仕様が明確であるほど、品質と納期を管理しやすい方式です。

SES：労働の提供まで

エンジニアの技術力を時間単位で提供します。何を作るか、成果をどう出すかの判断は発注側が持ちます。

FDE：成果と定着まで

本番で動き、現場が使い続ける状態までを担います。作って終わりではなく、業務の中で使われていることが完了の条件です。

SE・プロジェクトマネージャー・ソリューションアーキテクト・AIエンジニアとの違い

近い職種との違いも整理しておきます。どの職種も担当の一部はFDEと重なりますが、FDEは設計・実装・調整をまたいで、顧客の現場で成果が出るまでを一人で通して担う点が違います。

Palantirの「Devは1つの機能を多くの顧客に、Deltaは1つの顧客に多くの機能を」という対比が、この違いをよく表しています。製品やモデルを作る職種が「多くの顧客に届く1つの機能」を磨くのに対し、FDEは「1つの顧客の現場で動く多くの機能」に責任を持ちます。

時間ではなく成果で評価する

FDEの評価軸は、稼働時間ではなく成果です。本番で稼働しているか、現場で利用が定着しているか、業務の指標が変わったかで判断します。そのため、仕組みを作ることと同じくらい、使われるための工夫に時間をかけます。

曖昧な段階から現場で一緒に決める

FDEは、確定した仕様を受け取って作る働き方ではありません。現場に入り、まだ曖昧な要件をお客様と一緒に決めていきます。エンジニアが直接話を聞いて判断するため、営業と開発の間で起きがちな伝言ゲームがありません。

FDEが向くケースと受託開発が適するケース

FDEが向くのは、何を作るべきかを現場と探りながら決める必要がある案件です。AIをどの業務にどう組み込むか、社内データをどう活かすかといったテーマが代表例です。導入後の運用や定着までを見据えたい場合にも適しています。

• AIを導入したいが、どの業務から手を付けるべきか決まっていない
• 試作品やPoCまでは進んだが、本番運用に載せられていない
• 開発チームはあるが、AI活用が個人任せで組織に定着していない
• 外部パートナーが離れた後も、自社のチームで運用を続けたい

一方、要件が固まっていて、納品で完結する案件は受託開発が適します。目的と進め方の相性で方式を選ぶことが、外部パートナー活用の成功につながります。

FDE型支援の難しさと、うまくいく条件

FDE型の支援には難しさもあります。要件が曖昧な段階から始めるため、発注側にも判断を下す担当者と時間が必要です。業務の進め方を変える局面では、現場の抵抗や関係者の調整に労力がかかります。

業界でも、FDEを増やしすぎると個別対応が積み上がって実態がコンサルティング業に近づき、利益率が下がるという指摘があります。うまくいく条件として挙げられているのは、現場で得た知見を再利用できる資産に戻す規律です。開発支援会社の場合は、個別の対応を手順書・開発環境・テストという形でリポジトリに残し、次の現場でも使える型にすることがこれに当たります。

自社でFDEを採用するか、外部の支援会社に頼むか

FDEの価値が知られるにつれ、自社でFDEを採用しようとする企業も増えています。ただし採用には難しさがあります。本番で動かす技術力、業務理解、合意形成の力を一人に求めるため候補者が少なく、採用市場ではAI企業や大手SIerと競合します。一人だけ採用できても、その人が離れると仕組みも止まる属人化のリスクが残ります。

そのため、まず外部のFDE型支援でAI活用を本番に載せ、手順書と環境を社内に残したうえで、自社の採用や育成を進める順番が現実的です。発注側向けの手引きでも「動くデモではなく、本番で稼働している実装を確認する」ことが依頼先選びの判断軸として示されています。次の4つの観点も、この判断軸を具体化したものです。

支援会社を選ぶ4つの観点

1. 責任の終点が本番運用・定着まで契約に入っているか

提言や試作品の納品で終わる契約では、FDE本来の価値は得られません。本番で動かし、現場で使われる状態までが支援範囲に含まれているかを確認します。

2. 実際のデータと制約のもとで構築するか

デモ環境でうまく動いても、本番で同じ成果が出るとは限りません。お客様の実データ、既存システム、セキュリティ上の制約のもとで構築する進め方かどうかが重要です。

3. 運用体制・ガバナンス・手順書などの定着設計があるか

仕組みを使い続けるには、誰がどう運用するかの設計が欠かせません。権限管理や手順書の整備まで支援に含まれているかを見極めます。

4. 支援終了後もチームが自走できる能力継承があるか

支援会社がいなくなった途端に止まる仕組みでは、投資が活きません。ノウハウや環境がお客様の手元に残り、チームが自走できる状態をつくる支援かどうかを確認します。

依頼する前に社内で決めておきたいこと

FDE型の支援は、お客様と一緒に決めながら進めるため、社内側の準備で成果が大きく変わります。依頼の前に、次の点を決めておくと立ち上がりが早くなります。

• 社内の責任者：AIに何を任せるか、優先度をどうするかを判断できる担当者を置く
• 対象の業務とデータ：最初に取り組む業務と、実データ・既存システムに触れる範囲、データの取り扱いルールを決める
• 完了の状態：支援が終わる時点で、何が動いていて、誰が運用しているかを言葉にしておく

GinTrickのAI内製化支援の進め方

GinTrickは、お客様の情報（課題・優先度・リリース日）を日々キャッチアップし、お客様と直接すり合わせながら開発を進めます。お客様のリポジトリには、CLAUDE.md・skills・hooks・運用手順書といったAI開発環境をチームで共有できる形で整備して残します。

要件管理シートや議事録などの業務ツールと、開発タスクの管理はAIエージェントを介してつなぎます。リリースフロー、ロールバック手順、クラウド権限の最小化、AIエージェントのガードレールは手順書として文書化します。引き継ぎ書やテストから仕様書を起こす仕組みまで整え、チームが自走できる状態にします。

進め方は次の4ステップです。

ステップ1：現状診断

開発の進め方、ツール、権限、AI活用の状況を把握し、定着を妨げている要因を整理します。

ステップ2：環境・権限設計

AI開発環境の構成と、AIエージェントやクラウドに与える権限の範囲を設計します。

ステップ3：整備と並走開発

環境を整備しながら、お客様のチームと一緒に実際の開発を進めます。使いながら手順や設定を磨き込みます。

ステップ4：運用引き継ぎ

手順書と環境をお客様に引き継ぎ、チームだけで運用を回せる状態にします。

支援終了後にお客様の手元に残るもの

GinTrickのFDE型の支援では、次のものをお客様のリポジトリと業務の中に残すことを完了の条件にしています。

• チームで共有できるAI開発環境（CLAUDE.md・skills・hooks）
• リリースフロー・ロールバック手順・クラウド権限の設計をまとめた運用手順書
• 保護ブランチへの誤操作を防ぐAIエージェントのガードレールと回帰テスト
• 要件管理シートや議事録と開発タスクをつなぐ、AIエージェント経由の連携
• 引き継ぎ書と、テストから仕様書を起こす仕組み

開発はClaude CodeやCodexなどの生成AIを活用したAI駆動開発で進めます。AIが生成したコードはサイバーエージェント・ドワンゴ出身のエンジニアが必ずレビューし、自動テストで品質を担保します。

GinTrickの開発支援の全体像はシステム開発のページで紹介しています。エンジニア一人ひとりのAI活用スキルを高めたい場合は、AI駆動エンジニア講座もあわせてご覧ください。