更新日：2026年8月17日
FDE、AIコンサル、SIer、受託開発、SESは、実際の案件ではよく重なります。顧客と会話し、要件を整理し、システムを作る。担当者の経歴だけを見ても、違いが分からないことは珍しくありません。
それでも、同じ事業ではありません。
違いが表れるのは「誰が顧客先へ行くか」ではなく、何を成果として引き受け、案件で得た学びをどこへ戻すかです。既存サービスをFDEと呼び替える前に、顧客成果、実装責任、契約、共通資産の流れを確認する必要があります。
結論から言えば、FDEは他の業態を置き換える名称ではありません。AIコンサル、SI、受託開発、SESの能力を組み合わせながら、顧客現場での実装と、自社プロダクト・共通基盤の改善を一つの循環にする事業モデルです。
FDEの定義と海外・日本の用法は「FDEとは？本来の定義と日本型FDEの違い」、プロダクトを持たずに始める場合の境界は「FDEに自社プロダクトは必要か」で詳しく整理しています。
FDEと4つの業態を5つの軸で比較する
肩書きではなく、事業構造を並べると違いが見えます。以下は各業態の典型的な傾向を整理したもので、すべての企業や契約を一律に分類するものではありません。
比較軸 | FDE・FDE型支援 | AIコンサル | SIer | 受託開発 | SES |
|---|---|---|---|---|---|
出発点 | 顧客成果と自社プロダクト・基盤の適用 | 経営・業務課題と意思決定 | 複数システムを含む全体要件 | 合意した開発課題・仕様 | 必要な技術役務・体制 |
主な価値 | 課題発見から本番利用、改善までつなぐ | 調査、構想、提言、導入支援 | 設計、調達、統合、導入、運用 | 個別システムや機能の設計・開発 | 技術者の専門性と一定期間の役務 |
実装責任 | 原則として深く持つ | 会社・案件により異なる | 持つことが多い | 合意範囲で持つ | 契約と役割により異なる |
案件知の還流先 | 製品、共通部品、標準工程、ロードマップ | 方法論、提案知、業界知見 | 標準構成、導入知見、製品・サービス | 開発標準、技術部品 | 人材の経験、スキル、組織知 |
成功の判断 | 本番利用、顧客成果、再利用性、採算 | 意思決定や変革の前進 | 品質、納期、予算、稼働 | 検収、品質、納期 | 契約役務の遂行、体制の継続 |
最も大きな差は、実装の有無だけではありません。FDEには二つの戻り先があります。顧客には本番で使われる成果を残し、提供企業には次の顧客でも使える能力を残す。この二重の成果がなければ、FDEという名称を使っても既存業態との違いは薄いままです。
FDEとAIコンサルの違い
AIコンサルティングの範囲には、AI戦略、業務分析、ユースケース選定、技術調査、ロードマップ、ベンダー選定、導入・定着支援まで含まれ得ます。実装チームを持つ会社もあれば、提言やプロジェクト管理を中心にする会社もあります。「AIコンサル」という名称だけでは、実装責任の深さは決まりません。
FDEとの境界は、提言のあとにあります。
OpenAIのFDE職は、顧客の問題整理に加え、試作から安定した本番環境までの技術デリバリーを持ち、案件で機能した方法をツール、プレイブック、共通部品へ残す役割とされています。現場の評価結果を研究・製品側へ返すことも職務に含まれます。
AIコンサルが要件整理をして開発チームへ渡すなら、主な価値は意思決定と設計です。課題整理からコード、本番展開、利用定着まで同じチームが担い、さらに知見を共通基盤へ戻すなら、実態はFDE型支援に近づきます。
境界は職種名ではなく、提言が実装と製品改善まで閉じているかです。
出典：OpenAI「Forward Deployed Engineer - UAE」（2026年8月17日確認）
FDEとSIerの違い
SIerは、顧客の業務要件に合わせ、複数のソフトウェア、クラウド、データ、ネットワーク、既存システムを組み合わせて導入します。上流工程から開発、移行、保守まで担うSIerであれば、FDEと実務が重なる部分は大きくなります。
違いは、プロジェクトの外側に何が残るかです。
一般的なSI案件では、顧客固有のシステムを計画どおり稼働させることが中心になります。FDEでは、それに加えて現場で得た要求や評価を、自社のプロダクト、共通コネクタ、標準構成、ロードマップへ返します。PalantirはForward Deployed Engineeringを、顧客課題に近いチームとコア開発チームが連携し、フィードバックからプラットフォームを継続的に進化させる方法論として説明しています。
ただし、SIerだからFDEになれないわけではありません。自社製品や共通基盤を持ち、個別案件の知見を複数顧客へ還流できるSIerは、本来のFDEに近い構造を作れます。製品がない場合も、標準工程や共通部品を蓄積する日本型FDE・FDE型支援から始められます。
出典：Palantir「Architecture Center Overview」（2026年8月17日確認）
FDEと受託開発の違い
受託開発でも、顧客へのヒアリング、要件定義、試作、開発、保守は行います。優れた受託会社ほど、仕様書どおりに作るだけでなく、顧客の目的へ踏み込んで提案します。そのため「上流から関わる」「伴走する」だけでは、FDEとの差になりません。
差が出るのは、案件の前後です。
- 受注前に、既存の自社基盤や標準工程をどこまで適用するか
- 進行中に、利用結果から要件と実装をどう更新するか
- 終了後に、顧客固有の成果と共通化可能な知見をどう分けるか
- 次の案件へ、どの部品、評価方法、運用手順を持ち越すか
受託開発は顧客固有の完成物を作るだけ、と決めつけるべきではありません。反対に、FDEなら納期や品質の責任が不要になるわけでもありません。FDE型へ移行する会社は、受託開発の実装力を捨てるのではなく、案件ごとの成果を共通資産へ変える工程を追加します。
一件目を納品できたかではなく、二件目で何を再利用できるか。ここが境界になります。
FDEとSESの違い
SESは日本のIT業界で広く使われる事業上の呼称です。実際の取引では準委任などが用いられますが、「SES」と書いてあれば契約上の責任や指揮命令関係が自動的に決まるわけではありません。契約書と業務の実態を確認する必要があります。
厚生労働省は、請負・委任・準委任では受託側が自ら業務遂行の指示を行い、発注者が受託側の労働者へ直接指揮命令する場合は、契約名にかかわらず労働者派遣に該当し得ると説明しています。公正取引委員会のソフトウェア業調査でも「エンジニアの準委任契約（SES）」という市場での用法が確認できます。
FDEとの違いを「常駐かリモートか」で判断してはいけません。FDEが顧客現場へ深く入ることはあっても、目的は要員を配置することではなく、顧客成果を実装し、その学びを製品・共通基盤へ戻すことです。
SES事業者がFDE型支援へ移行するなら、肩書きを変える前に次の変化が必要です。
- 人月や要員条件だけでなく、対象業務と成果を定義する
- 個人の経験に閉じず、チームで設計・レビューする
- Discoveryから本番化、運用移管までの標準工程を持つ
- 顧客との責任分界と指示系統を契約・実態の両方で整える
- 案件知を教育、テンプレート、共通部品へ戻す
顧客先にいるエンジニアをFDEへ改称しただけでは、名ばかりFDEになります。
出典：厚生労働省「労働者派遣事業と請負により行われる事業との区分に関するQ&A（第2集）」、公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書」（2026年8月17日確認）
契約名だけではFDEかどうか決まらない
FDEは法律上の契約類型ではありません。案件に応じて準委任、請負、ライセンス、利用契約、保守契約などを組み合わせることがあります。
準委任ならFDE、請負なら受託開発、という分け方もできません。技術的な不確実性が高いDiscoveryは準委任、本番システムの特定範囲は請負、共通基盤は利用契約といった設計も考えられます。重要なのは、各段階の成果、責任、変更方法、知的財産、再利用範囲が一致していることです。
契約を確認するときは、少なくとも次の5点を分けます。
- 顧客が購入するのは成果物、役務、利用権のどれか
- 業務の進め方を誰が指示し、誰が管理するか
- 仕様変更と追加費用をどう決めるか
- 個別開発物と共通部品の権利をどう扱うか
- 本番運用、障害、AI出力の最終判断を誰が担うか
FDEという名称は、この設計の代わりになりません。
自社のサービスがFDE型かを確認する7つの質問
既存事業とFDEの距離は、次の質問で確認できます。
- 顧客の業務成果を定義し、利用状況まで追っているか
- 課題整理をしたチームが、実装・本番化にも責任を持つか
- 現場ユーザーの評価を継続的に実装へ戻せるか
- 顧客固有の要望と、複数顧客で使う共通機能を分けているか
- 案件知見を製品、共通部品、標準工程へ戻す担当者がいるか
- 二件目以降で時間、品質、リスクが改善する仕組みがあるか
- 顧客成果と自社採算を同じ案件レビューで確認しているか
1〜3だけなら、実装に強いAIコンサルや伴走型受託でも実現できます。FDE型として差が生まれるのは4〜7です。顧客へ深く入ることと、提供企業の能力が複利で増えることを両立させます。
既存事業からFDE型へ移行する道筋
移行時に、現在の事業を否定する必要はありません。出発点ごとに追加すべきものが異なります。
現在の事業 | すでに持つ強み | FDE型へ向けて追加するもの |
|---|---|---|
AIコンサル | 経営・業務課題の整理、意思決定支援 | 実装・運用責任、技術基盤、製品への還流 |
SIer | 大規模導入、統合、品質・運用管理 | 対象業務の絞り込み、短い評価サイクル、共通基盤への還流 |
受託開発 | 設計・実装力、顧客別の柔軟な対応 | Discovery、成果指標、再利用判断、プロダクト責任 |
SES | 顧客接点、人材、現場業務への理解 | チームデリバリー、成果定義、標準工程、共通資産化 |
移行の起点は採用ページではありません。初号案件を一つ選び、対象業務、責任範囲、評価方法、共通化する資産を決めることです。全案件を一度にFDE化すると、従来契約との責任差が曖昧になります。
具体的な立ち上げ手順は「FDE事業の立ち上げ方｜初号案件から共通基盤まで」で整理しています。
FDEの違いは、案件後に残ったものに表れる
FDEとAIコンサル、SIer、受託開発、SESは、業務の一部だけを切り取れば似ています。顧客と話すこと、現場へ入ること、コードを書くことのどれか一つでは区別できません。
案件が終わった場面まで見ると、違いが現れます。
顧客には、本番で使われる成果と運用可能な仕組みが残ったか。提供企業には、次の案件で使える製品機能、共通部品、評価方法、標準工程が残ったか。この二つへ具体的に答えられるなら、既存業態の強みを土台にFDE型事業へ進めます。
反対に、変わったのが肩書きだけなら、事業は変わっていません。FDEの比較で最後に見るべきなのは名刺ではなく、二件目へ持っていけるものです。