FDE事業の立ち上げ方｜サービス設計から初号案件まで

更新日：2026年8月17日

FDE事業を立ち上げようとすると、最初にサービス名や採用する人材を決めたくなります。しかし、既存のAIコンサルや受託開発を「FDE」と呼び替えただけでは、顧客が買う理由も、案件を重ねるほど強くなる仕組みも生まれません。

先に設計すべきなのは、誰のどの業務に入り、どこまで責任を持ち、案件で得た知見を何に戻すかです。FDE事業の立ち上げは、職種を新設する話というより、顧客現場と自社の共通資産をつなぐ事業構造を作ることだと考えた方が実態に合います。

判断基準は一つです。初号案件が終わったとき、二件目は何が速くなるのか。AIコンサル、SIer、受託開発、SES、AIプロダクト企業がFDE事業へ参入するときは、この問いからサービス設計と初号案件を組み立てます。FDEそのものの定義は、先に「FDEとは？本来の定義と日本型FDEの違い」をご覧ください。

現在の業態ごとに何を残し、何を追加すべきかは「FDEとAIコンサル・SIer・受託開発・SESの違い」で比較しています。

FDE事業は「顧客に深く入る」だけでは成立しない

OpenAIはFDEを、顧客へのデリバリーと中核プラットフォーム開発の交点で活動し、Discovery、技術的なスコープ設定、設計、構築、本番展開までを担う役割と説明しています。成功の尺度には、本番での利用、業務への影響、製品やモデルの改善につながる評価結果も含まれます。

Palantirも、顧客の課題へ近づいたエンジニアがコア開発チームと連携し、現場のフィードバックから新機能を継続的に出す方法論としてForward Deployed Engineeringを位置づけています。

ここには二つの仕事があります。

1. 顧客固有の課題を解き、本番で使われる状態まで進める
2. そこで得た知見を、製品、共通部品、評価方法、標準工程へ戻す

一つ目だけなら、優れたAIコンサルや受託開発でも実現できます。FDE事業として差が生まれるのは二つ目です。案件が終わるたびに知見が担当者の中へ消えるのではなく、次の案件を速く、正確に進める資産として会社側へ残ります。

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

日本で立ち上げるなら、FDEの型を先に決める

自社プラットフォームがなければFDE事業を始められないのでしょうか。厳密な意味では、プロダクトやプラットフォームを顧客へ展開し、その学びを製品へ戻す構造が本来のFDEです。

一方、日本では、AI導入の課題整理から実装・運用までを横断するサービスもFDEと呼ばれています。たとえばHmcommは、AI技術、開発・運用体制、SI・SES領域、顧客基盤を組み合わせたFDE事業を発表し、自社AIプロダクトとの連携や将来的なプラットフォーム化を示しています。セラクは「日本型FDEモデル」として、人材、顧客先での実行経験、自社AIプラットフォームと他社AIの活用を組み合わせています。

これは、日本型FDEが単なる職種名ではなく、既存事業の資産をどう組み替えるかという問題であることを示しています。ただし、各社の発表は各社自身の事業計画であり、FDE市場全体の需要や成功を保証するものではありません。

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

立ち上げ時には、少なくとも次のどちらを目指すか明確にします。

日本型FDEから始めることはできます。ただし、案件を重ねても再利用できるものが増えないなら、従来の受託開発やSESとの違いは薄いままです。最初から巨大なプラットフォームは不要でも、どの資産を育てるかは最初から決める必要があります。

完成した製品がない段階で何を共通資産にすべきかは、「FDEに自社プロダクトは必要か？受託開発との違いと境界」で詳しく整理しています。

FDE事業の立ち上げで決める7つの項目

以下の7項目は、市場全体で確立された唯一の正解ではなく、inovieがFDE事業を設計するときの整理です。順番には意味があります。人材採用やツール選定から始めると、対象顧客と成果が曖昧なまま固定費だけが増えやすいためです。

1. 自社がすでに持つ資産を棚卸しする

FDE事業はゼロから作るより、既存事業の中にある資産を組み替えて始める方が現実的です。次の四つを確認します。

• 顧客資産：継続取引のある業界、部門、決裁者、相談される業務
• 技術資産：AI、データ、クラウド、業務システム、セキュリティの実装力
• 人材資産：顧客折衝、業務分析、設計、開発、運用を担える人
• 再利用資産：自社製品、コネクタ、テンプレート、評価セット、運用手順

すべてを持つ必要はありません。むしろ、何が欠けているかを特定できることが重要です。顧客はいるがAI実装が弱い会社と、技術はあるが顧客業務を知らない会社では、最初に組む体制が変わります。

2. 対象顧客と対象業務を一つに絞る

「あらゆる企業のAI導入を支援する」という定義では、提案も採用も標準化できません。最初は業界、部門、業務、技術のうち、少なくとも二つを固定します。

たとえば「製造業向け」だけでは広すぎます。「中堅製造業の品質保証部門に対し、不具合記録と手順書を横断して調査・報告を支援する」のように、誰のどの判断を変えるかまで置きます。

絞る目的は市場を小さくすることではありません。同じ業務課題を複数顧客で解き、共通資産が本当に再利用できるかを早く確かめるためです。

3. 提供範囲と責任分界を決める

FDE型支援は、課題整理から実装・定着までを横断するため、責任範囲が曖昧になりやすい事業です。「伴走します」だけでは、顧客も提供側も終了条件を判断できません。

最低限、次を明文化します。

• 課題発見、要件整理、試作、本番化、運用のどこまでを担うか
• 顧客が提供するデータ、環境、担当者、意思決定
• AIの出力を誰が確認し、最終判断するか
• 既存システムとの接続、権限、セキュリティ審査の責任者
• 個別開発物と、提供側が再利用できる共通部品の権利
• 本番移行、運用移管、契約終了の条件

営業段階で決め切れない項目は、Discoveryの成果物として合意します。曖昧さを残すことと、曖昧なまま契約することは別です。

4. Discoveryから運用移管までを標準工程にする

FDE事業では、優秀な担当者の勘だけに依存すると再現性が出ません。工程ごとに成果物と判断基準を置きます。

標準化するのは答えではなく、判断の仕方です。顧客ごとに課題が違っても、確認する順序と残す記録を揃えることはできます。

5. 初号案件を「売上」と「学習」の両方で設計する

初号案件は、最初の売上を作るだけの案件ではありません。FDE事業の仮説を検証し、二件目に持ち越す資産を作る案件です。

選びやすいのは、既存顧客との信頼関係があり、対象業務の責任者へアクセスでき、一定量の実データで評価できる案件です。反対に、短納期の一括請負で要件変更が認められず、現場ユーザーへ接触できない案件は、FDE型の進め方と相性がよくありません。

初号案件の終了時には、少なくとも次を残します。

• 顧客成果：対象KPIの変化、利用状況、未解決課題
• 技術成果：コード、コネクタ、評価セット、監視・復旧方法
• 事業成果：提案、見積、SOW、原価、役割分担、リスク記録
• 再利用判断：何がそのまま使え、何を抽象化し、何を捨てるか

初号案件の成功を「納品できた」で終わらせると、二件目でも同じ苦労を繰り返します。二件目が速くなるものを残せたか。ここが立ち上げの判定になります。

6. FDEチームを一人の万能人材に依存させない

FDEには顧客理解と実装力の両方が必要ですが、すべてを一人で担わせる必要はありません。初期チームでは、少なくとも次の責任を割り当てます。

• 事業責任：対象市場、価格、採算、継続判断
• 顧客責任：課題整理、意思決定者との合意、利用定着
• 技術責任：設計、実装、品質、セキュリティ、運用
• プロダクト責任：個別要望と共通機能の切り分け、資産化

一人が複数の責任を持つことはあります。しかし、責任そのものを消してはいけません。「全員で見る」は、実際には誰も最終判断しない状態になりやすいためです。

7. 売上だけでなく、再現性と採算を測る

売上が増えても、案件ごとの個別対応が増え、優秀な人材の稼働が埋まるだけなら、FDE事業としての拡張性は高まりません。立ち上げ期には、次の指標を分けて追います。

数値目標は自社の単価、体制、案件特性によって異なります。根拠のない業界標準を置くより、初号案件を基準値として二件目、三件目で改善したかを比較します。

FDE事業の初号案件に向いているかを確認する

候補案件が来たとき、受注可能かどうかだけで判断すると、既存の受託案件をFDEと呼び替える方向へ戻りやすくなります。次の条件を確認します。

• 解決する業務課題と責任者が特定されている
• 現場ユーザーへ継続的にヒアリングできる
• 評価に必要なデータへ、適切な権限でアクセスできる
• 試作だけでなく、本番利用と運用まで検討できる
• 顧客と提供側の責任分界を合意できる
• 案件で得た知見のうち、再利用できる範囲を契約上整理できる
• 成果と採算の両方を振り返る時間を確保できる

すべてが最初から揃うとは限りません。ただし、満たせない条件が多い場合、その案件は「FDEの初号案件」ではなく、通常のコンサルティングや受託開発として扱った方が誠実です。名称より、契約と実態を合わせます。

立ち上げ時に起きやすい4つの失敗

既存サービスの名称だけをFDEへ変える

提供工程、責任範囲、資産化の仕組みが変わらなければ、顧客から見た価値も変わりません。営業資料より先に、案件後に何が残るかを決めます。

最初から対象市場を広げすぎる

業界も業務も技術も異なる案件を同時に受けると、共通部品を作れません。初期は、同じ判断基準と部品を再利用できる範囲に絞ります。

PoCの完成を成果にする

AIは試作品が動いてから、本番の権限、例外、評価、監視、費用、利用定着で止まりやすくなります。初号案件の計画に本番移行と運用責任を含めます。

FDEを万能な個人として採用する

顧客折衝、業務分析、開発、運用、製品判断を一人へ集中させると、その人がボトルネックになります。役割は横断させても、レビューと意思決定はチームで支えます。

立ち上げの順序は「名前」ではなく「循環」から決める

FDE事業の立ち上げで最初に作るべきものは、立派なサービスページではありません。対象顧客と課題を絞り、初号案件の工程と責任を決め、案件後に共通資産を残す循環です。

その循環があれば、自社プラットフォームを持たない会社でも、日本型FDE・FDE型支援として始め、案件から標準工程や共通部品を育てられます。循環がなければ、自社プロダクトがあっても個別対応に引きずられ、FDEの強みは薄れていきます。

初号案件が終わったとき、二件目は何が速くなるのか。この問いに具体的に答えられる状態が、FDE事業立ち上げの最初の到達点です。