FDE型AI導入支援とは？Forward Deployed Engineer型の定義と、向いている会社・向かない会社

2026年8月28日

執筆・監修：株式会社Walkers 代表取締役渡辺敦司

FDE型AI導入支援とは、FDE＝Forward Deployed Engineerが顧客企業の業務に入り込み、業務の分解から実装、運用の定着までを同じ少人数チームで担当する支援形態です。分析する人と作る人を分けない点が構造上の特徴で、呼び名はPalantir Technologiesの職種名に由来します。

私は株式会社Walkersの代表として、この形態でAI導入支援を提供しています。ただ正直なところ、商談で「FDE型です」と言うたびに、相手の頭にあるものと私の言っているものが少しずつずれている感触がありました。無理もありません。FDEという言葉が日本で目立ち始めたのはごく最近で、名乗る会社ごとに守備範囲が違います。だからこの記事では、この言葉がどこから来たのかまで遡って、FDE型とは何か、どんな会社に向いていて、どんな会社には向かないのかを定義し直します。

クリックできる目次

「Delta」と呼ばれていた職種とは？

FDEという職種名を最初に置いたのはPalantir Technologiesです。同社は2019年4月に公開したブログで、社内の二大エンジニア職をDevとDeltaという通称で紹介しています。Devはソフトウェアエンジニア。DeltaがForward Deployed Software Engineer（FDSE）、つまりFDEの原型です。

Deltaという名前に技術的な意味はありません。初期のPalantirがBusiness Developmentの各チームをNATOフォネティックコードで呼んでいた、その名残だといいます。ただし所属には意味があります。DevはProduct Developmentに属し、FoundryやGothamのコンポーネントを設計から運用まで所有します。DeltaはBusiness Developmentに属し、任務は顧客の技術的な成果を出すこと。持ち場からして違います。

両者の違いを、同記事は一行で言い切っています。Devの焦点は “one capability, many customers”、Deltaの焦点は “one customer, many capabilities” です¹。一つの機能を多数の顧客に届けるのがDevで、一人の顧客に多数の機能を届けるのがDelta。だから成功の測り方も違います。Deltaの成績は、顧客の目標をどれだけ動かせたかで決まります。

よくある誤解として、同記事は「Deltaはコンサルタントでは？」という問いを挙げています。ニューヨーク拠点の社員の答えがわかりやすいです。コンサルタントは一度きりの分析や提言を作ります。Deltaは顧客と一緒に、顧客が自分で改善し続けられる長期の仕組みを作ります。サンパウロ拠点の社員は、コンサルタントよりはるかに多くのエンジニアリングと技術作業をやる、とも答えています。

では、Deltaに一番必要な技術は何でしょうか。業務課題の分解です。高いレベルの業務課題から、それを解くために書く一行のコードまでを、同じ人が理解できること。同記事が最初に挙げる条件はこれです。

この職種は今も現役で、公開中のFDSE募集要項には、この職種は自社が生み出したものであり、エンジニアを顧客の中に直接埋め込む形をとってきた、と書かれています。担当範囲は、設計判断、大規模データの取り回し、顧客に合わせた個別アプリケーションの開発、技術者から経営層までの関係者との直接のやりとり、着想から展開までのプロジェクト推進。チーム名の欄には今もDeltaと記載され、顧客先への出張は業務時間の25%までと明示されています。

25%という数字は、「常駐」という言葉のイメージよりだいぶ小さいです。つまり、この職種を成り立たせているのは顧客先にいる時間の長さではありません。担当範囲が端から端までつながっていること。そちらのほうです。

日本に輸入された時点で、なぜ定義は揺れていたのか？

住友商事グループのInsight Edgeは、2026年5月にFDEのポジションを新設し、7月3日にその背景を公開しています。同社のChief Innovation Officerの整理はこうです。PalantirのFDEは「顧客の現場に常駐し、事業課題の特定からシステムの運用・定着までを一貫して担うエンジニア」であり、強力な自社プラットフォームを前提に、コンサルティングとエンジニアリングを高いレベルで両立させる専門職種。これがもともとのFDE像です。

そのうえで同記事は、今の状況を率直に書いています。多くの企業がFDEを掲げているが、役割と定義は各社各様で、元の像から離れてきています。FDEという語はすでに一般名詞化しつつあり、Palantir発の定義を超えて使われ始めています。同記事はこれを「カオスな状況」とまで呼んでいます。

同記事の分類では、FDEはすでに5種類あります。自社プロダクトを顧客環境に合わせて実装するプラットフォーム型。商談段階で技術提案やPoC設計を担うプリセールス型。導入後の定着と利用拡大を支援するカスタマーサクセス型。顧客ごとの要件で個別開発と運用まで担うSIer型。戦略策定からAI実装と成果創出までを一気通貫で担う価値創出型。本来のFDEは巨大なプラットフォーム事業を原資にしている、という指摘も添えられています。

冒頭に書いた「ずれ」の正体はこれです。相手が「FDE」と聞いて思い浮かべるものが、5つのうちどれなのか決まっていません。プリセールス型のFDEに運用の定着まで期待すれば外れるし、プラットフォーム型のFDEに既製品の外側の業務を頼んでも、製品の範囲に引き戻されます。だから、職種名としてのFDEと支援形態としてのFDE型は、範囲を分けて定義しておかないと会話が噛み合いません。

AI導入支援に当てはめたときのFDE型とは？

FDE型AI導入支援とは、FDE＝Forward Deployed Engineerが顧客側の業務に入り込み、業務の分解から実装、運用の定着までを、同じ少人数のチームが継続して担当する支援形態です。分析する人と作る人を分けないことが、ほかの支援形態との構造上の違いになります。

この定義には、外したら別物になる条件が3つ入っています。

分解と実装の担い手が同じ：業務を分解した本人が実装します。間に仕様書という中間成果物を挟みません。
成果を顧客側の業務で測る：納品物が揃ったかどうかではなく、対象の作業が実際に軽くなったかどうかで測ります。
実装が顧客ごとに異なる：汎用の製品を設定で寄せるのではなく、その会社の手順に合わせて作ります。他社への転用を前提にしません。

3つのうち、要になっているのは1つめです。分解する人と実装する人が分かれると、間に必ず仕様書が挟まります。仕様書に翻訳した瞬間、現場の人が口頭でしか説明しなかった例外処理や、資料のどこにも書かれていない判断基準が落ちます。そして落ちた分だけ、できあがったものは使われません。

Palantirの記事がDeltaの技術の筆頭に分解を挙げていたのは、ここに対応しています。裏を返せば、分解だけできる人と実装だけできる人を2人並べても、FDE型にはなりません。

誰が分解し、誰が実装し、誰が定着まで見るか？

従来の支援形態との違いは、工程の数ではなく、担い手が入れ替わる位置に出ます。

支援形態	業務を分解するのは	実装するのは	運用の定着を見るのは
コンサル型	支援側	顧客側、または別の発注先	顧客側
受託開発型	顧客側（仕様書として渡す）	支援側	顧客側
ツール導入型	製品の想定手順に合わせて顧客側	製品ベンダー（設定と接続）	顧客側、または製品側の担当者
FDE型	支援側のFDE	同じFDE	同じFDE

表を縦に読むと、3列とも同じ担い手で埋まるのはFDE型だけです。横に読むと、ほかの3つは必ずどこかで担い手が入れ替わります。担い手が入れ替わる場所が引き継ぎ点で、情報はそこで落ちます。念のため書いておくと、これはどの型が優れているかという話ではありません。引き継ぎ点をいくつ許容できるか、という話です。

型ごとの課金の形や、自社の状況からどの型を選ぶかの分岐は、AI導入支援会社は5類型＋FDE型で選ぶに整理してあります。

FDE型が向いている会社の条件とは？

身も蓋もないことを書くと、FDE型が成立するかどうかは、支援側の力量より、発注側が何を差し出せるかで決まる部分が大きいです。差し出すものは予算ではありません。次の4つです。

業務を見せられること：実際の作業を横で観察させてもらえます。資料の提出ではなく、作業そのものへの立ち入りを指します。
判断を出せる人が関与できること：業務の切り方を変える場面が必ず来ます。人には判断が必要な場面だけを残す設計になるので、その判断を出せる立場の人が議論に入れる状態が要ります。
標準から外れた業務が残っていること：既製品の想定手順からはみ出した部分を、誰かが手作業で埋めています。そこが対象になります。
手順のほうを変える余地があること：実装に合わせて業務手順を少し変えたほうが早い場面があります。手順が固定されているほど実装は複雑になり、費用に跳ね返ります。

特に上の2つは、時間の問題ではなく体制の問題です。観察の時間をいくら確保しても、判断を出せる人がいなければ、分解の結果は「ご提案」の形で止まります。

FDE型が向かない会社の条件

正直に書くと、FDE型を選ばないほうがいい会社のほうが、数としては多いです。

業務が既製品の想定どおりに回っている：勤怠や経費のように標準手順で回る業務は、既製品を入れるほうが安くて早いです。作り込んでも保守費が乗るだけになります。
仕様がすでに確定している：要件が固まっているなら、分解の工程にお金を払う理由がありません。実装だけを発注して相見積で比較したほうが安くなります。
現場に外部を入れられない：規制や守秘の要件で作業の観察ができない業務は、FDE型の前提が成り立ちません。
成果物を他社にも売れる製品として求めている：FDE型の実装は顧客固有になるため、そのまま転用できる形では残りにくいです。
業務を見せる時間を誰も出せない：担当者を1人も出せない状態では、支援側は資料からしか業務を知れません。結果として、名前だけFDE型の受託開発になります。

これらに当てはまる会社が遅れている、という話ではまったくありません。FDE型はほかの形態の上位互換ではなく、既存の形態が誰も担当しない谷間に特化した形。それだけの話です。

WalkersがFDE型で提供しているFDE-NOAH

当社が提供しているFDE-NOAHは、この形態をそのままサービスの形にしたものです。共通のSaaSにアカウントを発行するのではなく、1顧客につき1デプロイの専用環境を構築し、担当のFDEが顧客の業務に入って伴走します。

公開している機能は12項目あります。Gmailの未返信チェックと返信下書きの生成、商談ジャーニーの自動化、営業パイプラインの自動前進、マーケティングパイプラインの集計、SNS投稿の承認キュー、検索順位の監視と記事のリライト提案、議事録の全自動化、経理と財務のダッシュボード、請求書の自動下書き、契約金額の自動同期、自動化ジョブの監視、自動化候補リストの提案。人が向き合うのは、このうち判断が必要な場面だけ。そうなるように設計しています。

進め方は、無料のAI効率化診断から始まり、ヒアリング、2週間のPhase 0アセスメント（0円）、専用環境の構築、FDEによる伴走運用と続きます。アセスメントの段階で「これは既製品で足りる」と判断すれば、そのとおりに伝えます。当社のAI導入支援（FDE型伴走支援）は完全月額制で、概算月額50万円から100万円（税別・初期構築費0円）。料金一覧に掲載しています。この金額に見合う業務が見つからないなら、FDE型を選ぶ理由はありません。

最後に、商談で起きるずれの話に戻ります。相手がFDEという語で思い浮かべるものが、常駐の形なのか、商談に同席する技術者なのか、実装と定着まで担う担い手なのか。ここが揃わないと、話は噛み合いません。だから当社は、名乗りより先に範囲を置きます。業務を見て、分けて、作って、使われるまで見ます。この4つを同じ担い手が続けることだけがFDE型の条件で、それ以外は案件ごとに違います。

よくある質問

FDEとFDSEは同じ意味ですか？

起点は同じで、範囲が違います。Palantirが社内で使っているのはForward Deployed Software Engineer（FDSE）で、通称はDelta。日本で広まっているForward Deployed Engineer（FDE）は、そこからSoftwareを外した一般名詞で、Insight Edgeの記事が指摘するとおり、各社が自社の役割定義を載せて使っています。だから相手がFDEと名乗ったら、商談段階の技術支援に近いのか、実装と定着まで担うのかを先に確認したほうが早いです。

FDE型と客先常駐型のSESは何が違いますか？

指揮命令と成果の測り方が違います。SESは技術者の稼働時間を提供する契約で、何を作るかは発注側が決め、成果は稼働で測られます。FDE型は業務の分解から支援側が担い、成果は対象の作業が実際に軽くなったかどうかで測ります。物理的に顧客先にいるかどうかは軸になりません。実際、PalantirのFDSE募集要項でも、顧客先への出張は業務時間の25%までとされています。

社内にエンジニアがいなくてもFDE型は成立しますか？

成立します。というより、社内に実装できる人がいない状態こそ、FDE型が想定している前提です。必要なのはエンジニアではなく、業務を説明できる担当者と、業務の切り方を変える判断を出せる人。運用開始後に社内で手を入れたい場合は、その範囲を契約時に決めておけばいいでしょう。

FDE型で作ったものは自社の資産として残りますか？

残る形にできます。ただし契約で決めておく必要があります。FDE型の実装は顧客固有になるため、コードと環境の権利、運用の引き継ぎ範囲、支援終了後の保守を着手前に取り決めておきます。一方で、他社にそのまま転用できる汎用の製品にはなりにくいです。

FDE型を依頼する前に、社内で決めておくべきことはありますか？

3つあります。対象業務を見せられる担当者を誰にするか。業務手順の変更を判断する人を誰にするか。運用が始まったあと、誰が使い続けるか。経験上、3つめが空欄のまま着手した案件は、動くものができても使われずに止まります。結果を分けるのは技術ではなく、この3つの空欄が埋まるかどうかです。

最終更新日：2026年8月28日

出典

Palantir Blog “Dev versus Delta: Demystifying engineering roles at Palantir”（2019年4月8日公開）。 ↩