FDEに自社プロダクトは必要か？受託開発との違いと境界

更新日：2026年8月17日

FDEを名乗るなら、自社プロダクトが必要なのでしょうか。

本来のForward Deployed Engineerは、自社のプロダクトやプラットフォームを顧客現場へ展開する役割です。この意味では、答えは原則として「必要」です。しかし、日本で広がっているFDE型支援まで同じ条件で判断すると、AIコンサルやSIer、受託開発会社がFDE事業へ移行する入口を閉ざしてしまいます。

結論は、開始時点で完成したSaaSを持つ必要はないが、案件知見を再利用可能な共通資産へ変える仕組みは必要です。何も共通化せず、顧客ごとにゼロから作り続けるなら、実態はFDEというより個別受託に近づきます。

問題は「プロダクトを持っているか」という一問では終わりません。最初の案件から、何を顧客固有として残し、何を次の顧客でも使える形にするのか。その境界を設計できるかが問われます。

FDEの基本的な定義は「FDEとは？本来の定義と日本型FDEの違い」、事業全体の設計手順は「FDE事業の立ち上げ方」で解説しています。

AIコンサル、SIer、受託開発、SESとの役割・契約・成果の違いは「FDEとAIコンサル・SIer・受託開発・SESの違い」をご覧ください。

本来のFDEは、プロダクトと顧客現場の間にいる

OpenAIはFDEチームを、顧客へのデリバリーと中核プラットフォーム開発の交点に位置づけています。FDEはDiscoveryから本番展開までを担うだけでなく、案件で機能した方法をツール、プレイブック、共通部品として残し、現場から得た評価結果を製品やモデルのロードマップへ返します。

OpenAIのFDE職でも、案件で機能した方法をツール、プレイブック、共通部品として残し、現場の評価結果を製品・モデルのロードマップへ戻すことが明記されています。個別案件の完遂と共通化が、同じ役割の中に置かれています。

PalantirもForward Deployed Engineeringを、現場へ近づいたエンジニアがコア開発チームと連携し、顧客からのフィードバックを新機能へ変える方法論として説明しています。AIP、Foundry、Apolloという共通プラットフォームがあり、顧客固有の実装と基盤の進化を往復させる構造です。

したがって、本来のFDEは「顧客先で開発するエンジニア」ではありません。顧客固有の価値と、提供企業のプロダクト進化を同じ案件で成立させる役割です。

出典：OpenAI「Forward Deployed Engineer (FDE) - NYC」、Palantir「Architecture Center Overview」（2026年8月17日確認）

日本型FDEは、完成したプロダクトがなくても始められる

では、AIコンサルやSIer、受託開発会社はFDE事業を始められないのでしょうか。日本で使われる広い意味のFDE、すなわち日本型FDE・FDE型支援としてなら、開始は可能です。

実際、日本企業の公開資料では、自社AIプロダクトだけで完結するのではなく、既存の顧客基盤、開発・運用体制、SI・SESの知見、他社AIサービスを組み合わせてFDE事業を構成する例があります。Hmcommは、自社AI技術とシステム開発・運用体制を統合し、FDE事業から将来的なAI導入実装プラットフォームへの発展を示しています。セラクは「日本型FDEモデル」として、自社AIプラットフォームと他社AIの両方を扱う方針を示しています。

この二社だけで市場全体を一般化することはできません。それでも、完成した単一製品を起点にする方法だけでなく、既存事業の資産を束ね、案件を通じて共通基盤を育てる方法が日本で構想されていることは確認できます。

出典：Hmcomm「次世代AI実装事業『FDE』開始に関するお知らせ」、セラク「2026年8月期 第2四半期 決算説明資料」（2026年8月17日確認）

ただし、「今はプロダクトがない」で話を止めることはできません。個別案件から共通資産を増やす意思と工程がなければ、FDE型支援を名乗っても受託開発との構造的な違いは生まれないためです。

プロダクトはSaaSだけではない

「自社プロダクトがない」と考える会社でも、案件で繰り返し使えるものをすでに持っている場合があります。プロダクトを顧客が契約する完成品だけに限定せず、再利用可能な実行基盤として段階的に捉えると、立ち上げの現在地が見えます。

段階1や2は、一般には「プロダクト」と呼ばれないかもしれません。しかし、案件を重ねるほど速さと品質が上がるなら、事業上は重要な資産です。inovieでは、この段階的な共通資産をFDE事業の「最小実行基盤」と捉えています。これはinovieの整理であり、業界共通の定義ではありません。

完成品を先に作る必要はありません。必要なのは、同じ課題が二度現れたとき、同じ作業を二度繰り返さない仕組みです。

FDEと受託開発の境界はどこにあるか

受託開発とFDEは対立するものではありません。FDEの案件でも顧客固有の開発は発生し、契約形態として準委任や請負が使われることもあり得ます。境界は契約名ではなく、案件の目的と知見の流れにあります。

この表は、すべての受託開発会社とFDE事業者を一律に分類するものではありません。優れた受託開発会社がDiscoveryや継続改善、共通部品化まで行う場合もあります。そのとき両者の実務は重なります。

違いを一つに絞るなら、案件の学びを誰の資産として、どこへ戻す設計になっているかです。顧客だけに成果物を残して終わるのか、契約上許される範囲で抽象化し、自社の次のデリバリーやプロダクトも改善するのか。ここで事業構造が分かれます。

顧客固有のものと共通化するものを分ける

すべてを共通化しようとすると、顧客業務の違いを無視した使いにくい製品になります。反対に、すべてを個別対応すると事業が拡張しません。案件の設計時点で、三つに分けます。

顧客固有として残すもの

• 顧客独自の業務ルール、組織、承認経路
• 顧客のデータ、権限、機密情報
• 既存システム固有の設定や例外
• 競争優位に直結するロジック
• 顧客向けに作成した画面や帳票の一部

これらを無理に一般化すると、情報管理や権利の問題が生じるだけでなく、他社では使えない抽象化になります。

共通部品へ戻しやすいもの

• 認証、権限、監査ログ、エラー処理
• データ接続やモデル接続のインターフェース
• AI出力の評価方法、テストケースの構造
• プロンプトやモデル変更の管理方法
• 監視、障害対応、運用移管の手順

顧客データや固有ロジックを含めず、複数案件で同じ役割を果たすものが候補です。

標準工程として残すもの

• ヒアリング項目と業務フローの記録方法
• ユースケースの優先順位付け
• PoCから本番へ進む判定基準
• セキュリティ、法務、運用の確認項目
• 提案、見積、SOW、責任分界の型

コードにならない知見も資産です。技術部品より先に、判断方法の標準化から始めた方が再利用しやすい場合もあります。

共通化すべきかを判断する5つの質問

一度使った機能をすぐ製品へ入れると、特定顧客の都合が基盤へ混ざります。共通化の候補が出たら、次の質問で確認します。

1. 同じ問題が複数の顧客や案件で発生しているか
2. 顧客固有のデータや業務ルールを外しても価値が残るか
3. 設定の違いで対応でき、コードの分岐を増やさずに済むか
4. 共通化後の保守、セキュリティ、互換性に責任を持てるか
5. 次の案件で実際に時間、品質、リスクの改善につながるか

一件目だけで答えが出ない項目もあります。その場合は製品機能にせず、共通化候補として記録し、二件目で再検証します。作ることより、戻せる判断を保つことが重要です。

自社プロダクトなしで始める会社の現実的な順序

完成したSaaSを先に作り、顧客を探す必要はありません。既存顧客の案件から始める場合は、次の順序が現実的です。

1. 同じ課題を持つ対象顧客と業務を絞る
2. Discovery、本番化、運用移管の標準工程を作る
3. 初号案件で評価方法と責任分界を検証する
4. 二度使った部品と判断方法を共通資産へ移す
5. 三件目以降で設定可能な内部基盤にまとめる
6. 顧客が共通機能へ継続的に対価を払うなら外部製品化を検討する

ここで重要なのは、案件数そのものではありません。同じ課題が繰り返し現れ、共通機能への支払意思と運用責任を確認できたかです。三件あれば必ず製品化できる、といった基準ではありません。

最初の完成品は、SaaSではなくても構いません。評価セット、共通コネクタ、セキュリティ基準、Runbookが揃い、二件目を安全に速く進められるなら、FDE事業の基盤として機能しています。

「プロダクトを作ること」自体を目的にしない

FDE事業には共通資産が必要です。しかし、何でもSaaSにすればよいわけではありません。顧客ごとの運用差が大きく、設定で吸収できず、利用頻度も低い機能を製品化すると、保守対象だけが増えます。

製品化を急がない方がよいのは、次のような場合です。

• 一社だけの法務・業務要件に強く依存する
• 顧客ごとに成果の定義が異なる
• 共通機能より個別データ整備の割合が大きい
• 継続利用ではなく一度きりの移行・構築で価値が完結する
• 共通化後の保守責任と収益が釣り合わない

この場合も、案件を捨てる必要はありません。個別受託として扱い、FDE事業の共通基盤へ無理に混ぜない判断ができます。個別対応をゼロにするのではなく、個別対応と共通資産の境界を管理することが目的です。

FDEに必要なのは、製品の有無よりフィードバックループ

冒頭の問いに戻ります。FDEに自社プロダクトは必要か。

本来のFDEを名乗るなら、顧客へ展開する自社プロダクトやプラットフォームが事業の中心にあります。一方、日本型FDE・FDE型支援として始める段階では、完成した製品は必須ではありません。

ただし、案件を重ねても共通資産が増えず、同じ設計と実装を繰り返す状態は完成形ではありません。必要なのは、現場の課題を解き、そこで得た知見を標準工程、共通部品、内部基盤、最終的にはプロダクトへ戻すフィードバックループです。

判断すべきなのは「何を作ったか」だけではありません。次の顧客に、何を持っていけるようになったか。そこに具体的な答えがあれば、自社プロダクトを持たない段階からでもFDE事業は前へ進められます。