FDE（フォワード・デプロイド・エンジニア）とは：人月契約を超える日本のAI開発の新潮流

FDE（Forward Deployed Engineer：フォワード・デプロイド・エンジニア）とは、顧客の現場に深く入り込み、実際の業務課題を見極め、ソフトウェアやAIによる解決策を実装し、現場の利用者からのフィードバックをもとに改善し続けるエンジニアを指します。あらかじめ決められた仕様の実装を中心とする開発モデルとは異なり、FDEは業務の理解、実データによる検証、そして測定可能な業務改善への適応を重視します。

この記事の要点

• FDEは契約形態ではなく、開発・デリバリーの進め方：フォワード・デプロイド・エンジニアは、実際の利用者と一緒に課題の定義から実装、測定可能な改善までを担います。
• 国内大手IT企業が投資を拡大：NTTデータグループ（フォーティエンス コンサルティング）、日立、富士通が2026年にそれぞれ異なる形でFDE関連の取り組みを広げました。
• 人月契約が自動的になくなるわけではない：FDEは時間ベース、請負、従量課金、成果報酬のいずれの契約でも成り立ちます。
• パートナーは6つの基準で評価：課題定義、動く解決策での検証、システム連携、セキュリティ、成果の測定、導入後の責任です。
• 小さく始める：本物のユーザー、本物の課題、本物のデータで範囲を絞って検証してから拡大します。

2026年11月10日、日経クロステックは、NTTデータや日立製作所がFDEを通じて人月契約からの脱却を進めていると報じました。

この動きは、日本のIT業界が直面している、より大きな問いを映し出しています。生成AIやAIエージェントによってソフトウェア開発の一部が加速する中で、エンジニアリングサービスを「何人のエンジニアが何カ月働くか」で評価し続けるべきなのか。それとも、業務課題の特定、解決策の素早い検証、そして生み出された価値の測定をより重視すべきなのか、という問いです。

ただし、ここで一つ重要な区別があります。FDEを導入しても、従来の人月契約が自動的になくなるわけではありません。FDEは主にエンジニアリングとデリバリーの進め方を指す言葉です。一方、人月、請負（固定価格）、サブスクリプション、成果報酬は、それぞれ異なる契約・課金のモデルです。

日本企業にとって最も重要なのは、ITベンダーが「FDE」という言葉を使っているかどうかではありません。そのベンダーが業務を理解し、実用的な解決策をつくり、導入後に測定可能な改善を示せるかどうかです。

FDEとは何か：従来のSE（システムエンジニア）との違い

FDEは、顧客の現場チームと密に連携しながら、課題の特定、要件の定義、解決策の開発、そして継続的な改善までを担います。違いの本質は、エンジニアが客先に常駐するかどうかではありません。業務課題の理解から実装、測定可能な改善まで、責任の範囲が一貫してつながっているかどうかです。

日本企業は以前から、顧客のそばで働くSEに支えられてきました。そのため、FDEを従来の客先常駐型のSEに取って代わるまったく新しい概念として扱うべきではありません。両者には重なる部分も多くあります。違いがはっきりするのは、プロジェクトの始め方、評価の仕方、改善の進め方を比べたときです。

従来型のソフトウェア開発

一般的な受託開発では、顧客が業務要件を定義してから開発チームに発注します。ベンダーは合意した仕様に沿ってソフトウェアを設計・実装します。

この進め方は、要件が安定していて、期待する成果物が明確で、業務プロセスもすでに理解されている場合にはうまく機能します。しかし、当初の要件が従業員の実際の働き方を正確に反映していないと問題が起きます。システムを変えるには、追加の承認、仕様の見直し、さらなる開発が必要になるかもしれません。

複雑なAIプロジェクトでは、この課題が特に大きくなります。実データや業務フローを確認するまで、最適な技術的解決策が見えないことが多いからです。

FDE型のAI開発

FDE型の取り組みは、実際の業務課題を調べるところから始まります。エンジニアは利用者と一緒に、業務がどう行われているのか、どんな情報が必要なのか、既存のプロセスのどこに無駄な手間があるのかを把握します。

例えば、営業部門が「週報を自動で作成するAIシステムがほしい」と依頼したとします。一見すると、LLMをレポート画面につなぐだけの簡単な話に思えるかもしれません。しかし業務フローを調べてみると、エンジニアは本当の問題が「レポートを書くこと」ではないと気付きます。営業情報がCRM、メールのやり取り、社内資料に分散していて、従業員はレポートを書く前の情報集めに大半の時間を使っていたのです。

この場合、効果的な解決策には、既存アプリケーションの連携、業務情報の整理、管理されたレポート作成フローの構築が必要になるかもしれません。AIモデルは、その構成要素の一つにすぎません。

FDEの価値は、最初に依頼された機能をそのまま実装することではなく、本当に何をつくるべきかを見極めることにあります。

とはいえ、FDEという肩書きがエンジニアリングの質を保証するわけではありません。経験豊富なアジャイル開発チームや従来のSIerも、利用者と密に連携し、改善を重ねることはできます。企業は肩書きではなく、実際のデリバリーの進め方で評価すべきです。

なぜNTTデータ、日立、富士通は2026年にFDEへ投資しているのか

日本の大手IT企業がFDE関連の体制を強化しているのは、企業のAIプロジェクトで、エンジニアリングチームと業務現場との緊密な連携がますます求められているからです。課題はAIを導入することそのものではなく、技術的な能力を、従業員が実際に使いこなせるシステムへと変えることにあります。

NTTデータグループ：FDE型コンサルティング

2026年6月16日、NTTデータグループのフォーティエンス コンサルティングは、FDE型のコンサルティングサービスの提供開始を発表しました。業界知見とエンジニアリング力を組み合わせ、短いサイクルで実装と改善を繰り返しながら事業変革を支援する取り組みです。戦略コンサルティングと技術的な実行を切り離すのではなく、課題の特定、実装、業務改善をひとつながりにすることを目指しています。

出典：フォーティエンス コンサルティング（2026年6月16日発表）

同社は2026年9月17日、消費財業界向けに、AIを活用した需要予測のFDEサービスも発表しました。このサービスは、顧客の需要特性と、利用できるデータの状態を確認するところから始まります。そのうえで、限られた商品群で予測モデルを検証してから、導入範囲を広げていきます。

同社によると、初期検証は約10SKU（在庫管理単位）から始められるとしています。ただし、これはこのサービス固有の特徴であり、あらゆるFDEプロジェクトに当てはまる標準的な範囲ではありません。

重要なのは開発の進め方です。業務担当者が自らの知見を提供し、エンジニアが実際の運用状況をもとに予測システムを改善していきます。

出典：フォーティエンス コンサルティング（2026年9月17日発表）

根底にあるのは、AIモデルの開発を最終成果物とみなす考え方から、日々の業務への定着までを取り組みの欠かせない一部とみなす考え方への転換です。

日立：ITとOT（制御・運用技術）をつなぐ

日立は、フィジカルAI、Google Cloud、NVIDIAとの取り組みなどを通じて、FDEの体制を強化しています。このアプローチは、製造業、社会インフラなど、デジタルシステムが物理的な設備とつながる業界で特に意味を持ちます。

こうした現場では、ソフトウェアの知識だけでは足りません。エンジニアは、設備の制約、運用手順、安全要件、データの入手可能性、既存インフラの制約も理解しておく必要があります。

2026年11月2日、日立は、産業機器やユーティリティに関わる4つの事業の間でデータをつなぐ取り組みの事例を公開しました。FDEが事業部門と協力してIT・OTの課題を洗い出し、3カ月以内に動作するプロトタイプを開発したと報告しています。

出典：日立製作所（2026年11月2日公開の事例）

意義があるのは開発期間の短さだけではありません。複数の事業にまたがって、業務知識、エンジニアリング、現場での検証を統合した点にあります。ただし、3カ月という期間は日立が紹介した個別のプロジェクトのものです。企業向けAIシステムの一般的な導入期間として受け取るべきではありません。

富士通：エンジニアリングと収益モデルの見直し

2026年9月16日、富士通は「Fujitsu Uvance」のビジネスモデルを進化させる計画を発表しました。提案されているデリバリー体制は、次の3つの領域で構成されています。

• コンサルティングとフォワード・デプロイド・エンジニアリング
• アプリケーションとAIエージェント
• AIプラットフォーム

同社は、顧客ごとの業務知識や意思決定のプロセスを、AIによる事業変革に組み込むことを目指しています。また、成果連動型や従量課金型の収益モデルへの戦略的な移行についても説明しています。

出典：富士通（2026年9月16日発表）

この発表が興味深いのは、2つの変化を結び付けている点です。一つは、AIソリューションをどう設計・実装するか。もう一つは、ITベンダーが将来、ソリューションが生み出す価値に対してどう対価を受け取るか、です。

ただし、この2つは同じ変化ではありません。富士通の発表は戦略的な方向性を示したものであり、同社のすべての契約がすでに時間ベースやプロジェクトベースの課金から移行したことを意味するものではありません。

NTTデータ、日立、富士通の取り組みは、共通の課題に対するそれぞれ異なるアプローチを示しています。それは、エンジニアリングの提供者が、ソフトウェアの機能を納品するだけでなく、業務課題の解決にどこまで深く関わっていけるかという課題です。

FDEは人月契約に取って代わるのか：AI開発のコストはどう変わるか

FDEが人月契約に自動的に取って代わるわけではありません。FDEはエンジニアリングと顧客との関わり方のアプローチであり、時間ベース、請負、サブスクリプション、従量課金、成果連動型のいずれの契約の下でも成り立ちます。企業が評価すべきは、契約がコスト、リスク、成果物、測定可能な事業成果をどう結び付けているかです。

従来の人月契約は、主にエンジニアの人数と関与する期間でプロジェクト費用を計算します。この仕組みには利点もあります。要件が変わり続ける場合に柔軟に対応でき、すべての成果物を事前に細かく決めなくてもエンジニアリングの力を確保できます。

しかし、プロジェクトが業務上の価値ではなく、開発作業の量を中心に管理されるようになると問題が生じます。AIプロジェクトでは、エンジニアが企業のデータを調べ始めてから、最適な技術的アプローチが変わることがあります。当初は「AIエージェント開発」とされていた案件が、実際には大規模なデータ連携や既存アプリケーションのモダナイゼーションを必要とすることもあります。そのため、実装の途中で仮説を検証し、優先順位を調整できる契約の方が、企業にとって有益な場合があります。

代表的な4つの契約モデル

1. 時間ベース・人月契約

顧客は、提供されたエンジニアリングの工数やリソースに応じて支払います。柔軟な開発を支えられる一方、明確な優先順位と進捗の監視が必要です。適切な管理がなければ、事業の改善ではなく作業量が進捗の主な指標になってしまうおそれがあります。

2. 請負・成果物ベースの契約

顧客とベンダーが、定められた範囲と価格に合意します。要件が十分に安定していれば、予算管理がしやすくなります。ただし、要件が変わると契約の見直しが必要になる場合があります。

3. 従量課金・サブスクリプション型

顧客は、サービスの利用量、容量、継続的な利用に応じて支払います。初期費用の一部を抑えられる一方、長期的なコスト、利用量の増加、サービス提供者への依存度を評価する必要があります。

4. 成果報酬型の契約

報酬が、業務指標の改善など合意した成果に連動します。双方が測定可能な価値に集中しやすくなります。ただし、成果を定義し、その改善を特定の技術導入によるものと切り分けるのは難しい場合があります。

例えば、カスタマーサポートの対応時間を短縮したい企業を考えてみましょう。AIシステムによって、従業員が回答を準備する時間は短くなるかもしれません。しかしサポートの成果は、問い合わせ件数、顧客の行動、問題の複雑さ、人員体制の変化にも左右されます。単純に導入前後を比較するだけでは、AIが生み出した価値を判断するには不十分な場合があります。

契約前に確認すべきこと

どの契約モデルであっても、企業は次の点を明確にしておくべきです。

• どの事業成果を測定するのか
• 成果の測定に必要なデータを、誰が所有し、誰が提供するのか
• 要件の変更をどう扱うのか
• クラウド基盤、AIモデルの利用料、監視、保守は含まれているか
• 期待した成果が出なかった場合はどうなるのか
• 初期導入後、誰がシステムの改善に責任を持つのか

人月契約から離れること自体が改善というわけではありません。本当の目的は、エンジニアリングへの投資と事業価値との関係を透明にすることです。

社内でFDEの力を育てるには何が必要か

社内でFDEの力を育てるには、プログラミングの知識やAIツールへの慣れだけでは足りません。業務課題を見つけ、実際の利用者に話を聞き、実データで解決策を検証し、導入によって業務プロセスが改善したかどうかを説明できる経験が必要です。

日経クロステックは2026年11月10日、SOMPOホールディングスとミスミグループ本社が社内でFDEの育成を進めていると報じました。記事では、FDEの取り組みを成功させるための実践的な条件として、次の3つを挙げています。

本物のユーザー、本物の課題、本物のデータ。

出典：日経クロステック（FDE人材の社内育成に関する記事）

これらは役に立つ実践的な原則として理解すべきもので、成功を保証する統計的に検証された公式ではありません。

本物のユーザー

開発中は正しく動くシステムでも、従業員の本当のニーズに応えられないことがあります。だからこそ、実際に業務を担う人が検証に参加するべきです。現場の人が関わることで、エンジニアは例外的なケース、明文化されていない手順、正式な資料には出てこない要件を理解できます。

本物の課題

「AIを使いたい」という指示から始まるプロジェクトには、明確な業務上の目的がありません。より効果的なのは、具体的な課題から始めることです。例えば、次のような課題です。

• 顧客からの注文内容の確認に、従業員が時間をかけすぎている
• 保守チームが設備の点検記録の突き合わせに苦労している
• 情報が複数の部署に分散している
• 従業員が同じ情報を探すために、何度も複数のシステムを検索している

こうした課題は、技術を選ぶ前に調べることができます。

本物のデータ

デモでは、きれいに整理されたサンプルデータが使われがちです。しかし実際の企業の情報が、そこまで整っていることはまれです。記録が欠けていたり、形式がばらばらだったり、重複していたり、アクセス制限がかかっていたりします。そのため、適切なプライバシーとセキュリティの管理のもとで、代表的な業務データを使って検証する必要があります。

社内にFDEチームをつくる日本企業にとって、目的は必ずしもすべての外部ベンダーを置き換えることではありません。自社の業務プロセスを理解し、データを管理し、技術的な提案を評価し、導入の成果を測定する組織の力を高めることです。こうした力は、ソフトウェア開発を外部に委託する場合でも価値を持ち続けます。

FDE型のAI開発パートナーはどう選ぶべきか

FDE型のAI開発パートナーは、業務理解、現場での実装力、システム連携、セキュリティ管理、測定可能な成果、導入後の責任という観点で評価すべきです。FDEという呼び方だけでは、ベンダーが企業向けプロジェクトを成功させられるかどうかは分かりません。

日本の情報システム部門、DX推進担当、調達担当にとって、次の6つの基準が実践的な評価の枠組みになります。

1. 業務課題を定義する力

ベンダーは、最初の機能要望の背後にある課題まで掘り下げられるでしょうか。優れたパートナーであれば、業務フローについて議論し、利用者にヒアリングし、制約を洗い出し、適切な業務指標を設定できるはずです。

例えばAIレポートエージェントを提案する前に、ボトルネックがレポートの作成にあるのか、それとも作成に必要な情報集めにあるのかを見極めるべきです。この違いによって、プロジェクトの範囲は大きく変わる可能性があります。

2. 動く解決策で検証する力

プレゼンテーションや画面のモックアップだけでは、業務上の価値は示せません。エンジニアリングチームは、範囲を限定した動く実装をつくり、実際の利用者とテストし、フィードバックをもとに改善できる必要があります。

ただし、素早いプロトタイピングと本番運用への備えは別の能力です。ベンダーは、成功したプロトタイプをどうテストし、どう安全性を確保し、どう本番運用へ移すのかも説明できなければなりません。

3. 既存の業務システムとの連携

日本企業の多くは、ERP、CRM、在庫管理、販売管理、独自開発のレガシーシステムに依存しています。AIソリューションは、こうした環境から適切な情報にアクセスできてこそ役に立ちます。ベンダーは次の点を理解している必要があります。

• 利用できるAPIと連携の仕組み
• 認証・認可の要件
• データの品質と形式の制約
• 既存データの更新に関する制限
• 連携の長期的な保守

これらの課題は、AIモデルだけでは解決できません。

4. セキュリティと権限の管理

AIエージェントが企業のデータにアクセスしたり業務操作を行ったりする場合、明確な管理策が必要です。例えば次のようなものです。

• 役割に応じたアクセス権限
• 機微な操作に対する人の承認
• 実行ログと監査証跡
• テスト環境と本番環境の分離
• 緊急停止の手順
• 想定外の挙動を調査する手順

ベンダーは、これらの管理策を実装にどう組み込むのかを示せるべきです。詳しくはAIエージェント導入とガバナンスの記事でも解説しています。

5. 成果を測定する力

企業は、技術的な完成と業務上の成功を区別すべきです。例えば、文書を自動処理するAIシステムによって、一次確認にかかる時間は短くなるかもしれません。しかし、従業員が誤りの修正に余計な時間を使うなら、全体としての効果は限られます。そのため、成功の指標には次のような要素を含めるべきです。

• 処理時間
• エラー率
• 手作業による修正
• 従業員の確認作業の負担
• 運用の安定性
• 導入後の実際の利用状況

これらの指標は、可能な限り導入前に合意しておくべきです。

6. 責任範囲とコストの透明性

企業向けのAIシステムは、導入後も継続的な手入れが必要です。業務プロセスは変わり、元データは変化し、モデルの能力は更新され、既存のアプリケーションも改修されます。契約前に、顧客は次の点を理解しておくべきです。

• 誰がシステムを監視するのか
• 誰が運用上のインシデントを調査するのか
• 誰が更新や改善を行うのか
• 継続サポートにどのサービスが含まれるのか
• 導入後に継続的に発生する費用は何か
• 当初のエンジニアリングチームが外れた後はどうなるのか

信頼できるAI開発パートナーであれば、何をつくるかだけでなく、その解決策をどう検証し、運用し、改善し、支えていくのかまで説明できるはずです。

AI開発を外部に委託する前に企業がすべきこと

AI開発プロジェクトを発注する前に、企業は業務フロー、想定する利用者、利用できるデータ、期待する成果、運用上の制約を定義しておくべきです。範囲を絞った導入から始めれば、大規模な展開に踏み切る前に前提を検証できます。

例えば、社内の従業員サポートを改善したい製造業の企業を考えてみましょう。情報システム部門は、最初に「AIチャットボットがほしい」と考えるかもしれません。しかし最初にすべきなのは、従業員がなぜ今、情報を見つけられずに困っているのかを理解することです。次のような問いが役立ちます。

• 最も多くの問い合わせを生んでいるのはどの部署か
• 答えは今どこに保存されているのか
• 従業員は情報を見つけられずに困っているのか、それとも解釈に助けが必要なのか
• 従業員によって閲覧できる文書が異なるか
• どの質問なら自動で回答できるか
• どの場面で人の判断が必要か

これらの問いに答えることで、組織に必要なのがナレッジ検索のアプリケーションなのか、業務の自動化なのか、システム連携なのか、既存ソフトウェアのモダナイゼーションなのかが見えてきます。

例えば、従業員が権限のある社内文書を検索する必要があるなら、RAG（検索拡張生成）のシステムが適しているかもしれません。しかし、主な問題がアプリケーション間で情報が食い違っていることなら、システム連携のプロジェクトの方が大きな価値を生む可能性があります。

そのうえで、限られた利用者グループで範囲を絞った解決策をテストします。評価の基準は、AIがもっともらしい回答を出すかどうかではなく、業務上の成果です。十分な価値と信頼性が確認できれば、範囲を広げていけばよいのです。

Renesis Tech JapanのAIエンジニアリング支援

Renesis Tech Japanは、業務要件の整理、データ連携、AIアプリケーション、既存システムとの接続、検証、運用改善までをカバーするAIエンジニアリングとソフトウェア開発の力を提供しています。

AIエージェント開発サービスでは、LangGraph、CrewAI、AutoGenなどの技術を使った業務向けAIシステムの開発を行っています。また、既存の業務システムを持つ企業に向けて、アプリケーションのモダナイゼーションやカスタムソフトウェアの連携も支援しています。

これらの力は、多くのFDE型の取り組みに関係するものです。ただし、Renesis Tech Japanのすべての案件が、客先常駐型のFDEサービスや成果報酬型の契約として正式に提供されているわけではありません。具体的なデリバリーの形、責任範囲、契約条件は、プロジェクトごとに決める必要があります。優先すべきは、あくまで業務課題と、それに最も適したエンジニアリングの進め方です。

よくある質問

1. FDEと従来の客先常駐SEの主な違いは何ですか？

客先常駐のSEという言葉は、一般にエンジニアの働き方や、顧客の環境への配置を指します。一方、FDEは、利用者と直接関わりながら顧客の課題を見つけ、解決策を実装し、改善していくエンジニアリングの役割を指します。両者は相反するものではなく、客先常駐のエンジニアがFDE型の役割を担うこともあります。

2. FDEを採用すればAI開発のコストは下がりますか？

必ずしもそうではありません。検証のサイクルが短くなることで、プロジェクトによっては不要な開発を減らせるかもしれません。しかしコストは、業務要件、実装の範囲、連携の複雑さ、運用上の管理策、契約の形によって変わります。比較すべきは、測定可能な事業価値に対する、プロジェクトと運用の総コストです。

3. AIエージェントの開発にFDEは必要ですか？

必須ではありません。要件、インターフェース、運用上の制約が明確に定義されていれば、従来型のエンジニアリングチームでもAIエージェントを十分に開発できます。FDE型のアプローチが特に役立つのは、業務課題そのものの調査や、実際の利用者・業務データによる検証の繰り返しが必要な場合です。

4. FDE型の開発会社を選ぶうえで最も重要な要素は何ですか？

ベンダーが業務課題を理解し、利用者と一緒に解決策を検証できることです。技術力は欠かせませんが、システム連携、セキュリティ、本番運用への備え、保守、成果への責任もあわせて評価すべきです。

5. 社内にAIエンジニアがいなくてもFDE型の開発は取り入れられますか？

はい、外部のエンジニアリングパートナーと組むことで可能です。ただし、社内の業務担当者、データの持ち主、意思決定者は、要件の定義と成果の評価に参加し続ける必要があります。エンジニアリングを外部に委託しても、事業上の判断とガバナンスに対する顧客の責任がなくなるわけではありません。

まとめ

2026年に日本でFDEへの注目が高まっているのは、企業向けAIソリューションをどう開発し、どう届けるべきかを見直す、より大きな動きの表れです。

NTTデータグループは、業界知見と実践的な実装を結び付けるコンサルティングサービスを広げています。日立は、複雑な産業現場でITとOTをつなぐエンジニアリングの形を示しています。富士通は、FDE、AIアプリケーション、プラットフォームを組み合わせたデリバリー体制と、成果連動型・従量課金型の収益モデルへの戦略的な転換を模索しています。

これらの取り組みには重要な違いがあります。大手ITベンダーがすべて同じデリバリー体制や価格モデルを採用した証拠として受け取るべきではありません。

AI開発サービスを購入する企業にとって、より重要な変化は、エンジニアリングの成果をどう定義するかにあります。「このプロジェクトに何人のエンジニアが何カ月関わるのか」だけでなく、「どの業務課題を解決し、その解決策が機能していることをどう確かめるのか」を問うべきです。

AI開発プロジェクトを発注する前に、意思決定者は次の点を確認してください。

• 業務課題：解決すべき業務上の問題を明確にし、影響を受ける人を特定できているか。
• データとシステム：解決策が使うべき情報や既存アプリケーションを把握しているか。
• 検証の進め方：範囲を絞った導入から始め、根拠に基づいて改善していけるか。
• 成功の基準：技術的な性能と、意味のある事業成果を区別できているか。
• 責任範囲：開発費用、保守、セキュリティ、導入後の義務が明確に定められているか。

目的は、大手IT企業が話題にしているからという理由でFDEモデルを取り入れることではありません。実際の業務課題を、実践的な実装と継続的な改善につなげるエンジニアリングの進め方を選ぶことです。

AIがどこで価値を生み出せるのか、既存システムを新しいアプリケーションにどう生かせるのかを検討している企業に向けて、Renesis Tech JapanではAI業務診断を提供しています。活用の可能性や導入時の検討事項を整理するためにご活用ください。

編集上の注記：本記事は、2026年11月10日時点で公開されている情報に基づいています。各社の取り組み、数値、期間は、記載した発表資料および日経クロステックの報道に基づくものであり、すべてのFDEプロジェクトに当てはまる一般的な基準として受け取るべきではありません。