# FDEとは？Forward Deployed Engineerの役割と他職種との違いを解説

- URL: https://www.waltsu.co.jp/magazine/ai/forward-deployed-engineer/
- カテゴリ: AI活用 > AI人材・FDE
- 執筆: 藤井 俊輔（代表取締役） / 監修: 小洞 映（システムエンジニア）
- 公開日: 2026-09-17 / 最終更新日: 2026-10-29
- 発行: waltsu株式会社（waltsu MAGAZINE）

## こんな人におすすめ

- FDEという肩書きを見たが、何の職種か説明できない
- SES・コンサル・SEとの違いをはっきりさせたい
- 自社のAI導入を誰にどう頼めばいいか決めたい

AIを入れたのに使われていない、という話が減りません。ツールは契約したのに誰も開かない、試したが本番の業務には載らない。原因はモデルの性能よりも、自社の業務へ組み込む工程が誰の担当でもなかったことにあります。その工程を引き受ける職種が、FDE（Forward Deployed Engineer）です。 FDEとは、自社のプロダクトを持って顧客の現場に入り、課題の定義から実装、実際に使われる状態になるまでを一続きで担うエンジニアを指します。この職種を分けているのは常駐しているかどうかではなく、責任の終点がどこにあるかです。本記事では、定義と成り立ち、似た職種との違い、発注側が確かめる4点、FDEを置けない会社の代わりの手までを整理します。

**この記事のゴール（読了目安 約10分）**：FDEを一言で説明でき、コンサル・SE・SESとの違いを責任の終点で言い分けられる。自社のAI導入を外部へ頼むときに何を確かめればよいかを決められるようになる。

## この記事の結論

- FDEは、自社プロダクトを持って顧客の現場に入り、使われる状態までを担うエンジニア
- 分けているのは常駐の有無ではなく、責任の終点がどこにあるか
- 発注側が確かめるのは提案書の厚さではなく、最初に動くものが出るまでの日数
- 雇えなくても、要件を後から固める順番だけは自社でも真似できる

## FDEとは

FDEは、自社のプロダクトを持って顧客の現場に入り、業務で使われるまでを一続きで担うエンジニアです。一般的なエンジニアとの向きの違いも示します。

### 名前が示す役割

Forward Deployed Engineer の略で、直訳すると「前線に配置されたエンジニア」です。日本語ではフォワードデプロイドエンジニアと表記されます。自社のプロダクトを持って顧客の現場へ入り、課題を定義し、実装し、**業務で使われる状態になるまでを一続きで担います**。開発と導入支援が別の担当に分かれていないことが、この職種の特徴です。

### 顧客ごとに機能を組む

一般的なソフトウェアエンジニアは多くの顧客が使う1つの機能を作り、FDEは**1社のために多くの機能を組む**役割です。向きが違うため、Palantirは前者を製品開発、後者を事業開発の部門に置くと[同社の公式ブログ「DevとDelta」](https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87)で説明しています。

![自社プロダクトと顧客の現場の間にFDEが立ち、課題定義から本番運用・製品への還元までを一続きで担うことを示す横フロー図](https://www.waltsu.co.jp/wp-content/uploads/2026/09/forward-deployed-engineer01.png)

## Palantirが生んだ職種

この職種名が知られるきっかけになったのは、データ分析基盤を手がけるPalantirだとされています。いまも同社の製品ドキュメントに掲載されているのが、この役割名を冠した機能です。

背景にあるのは、要件定義の常識が通用しない領域です。**要件が固まるのを待っていると、いつまでも着手できない**。そういう場では、先にエンジニアを顧客側へ置きます。次の3つが重なる領域です。

- **言語化されていない**: 顧客自身が、何に困っているかを言葉にできない
- **データが外に出せない**: 現場のデータを持ち出せず、行かなければ触れない
- **使われて価値になる**: 納品しても、業務に載らなければ成果がゼロ

## なぜAI企業が置くのか

AI領域でこの職種が増えている理由は、モデルの性能ではなく、その先の工程が進まないからです。精度の高いモデルがあっても、どの業務のどの判断に差し込むか、既存のシステムとどうつなぐかは会社ごとに違います。ここは製品の機能追加では補えません。

国内でも、法人向けソフトウェアを手がけるLayerXが、顧客の最前線に立って実装と導入を進める役割として、[公式エンジニアブログ「FDEの募集を開始しました」](https://tech.layerx.co.jp/entry/ai-llm-fde)を公開しています。ソフトウェアが操作する道具から業務を進めるものへ寄るほど、**顧客の業務に合わせる工程そのものが売り物になります**。この変化は、業務を支援・実行するソフトウェアの広がりとして別記事で解説しています。

【関連記事】[AI SaaSとは？従来のSaaSとの違い・活用例・選び方をわかりやすく解説](https://www.waltsu.co.jp/magazine/ai/ai-saas/)

## 似た職種との違い

まず、**常駐しているかどうかでは分けられません**。FDEも顧客先へ通いますが、分けているのはどこまでを自分の責任とするかです。

### コンサル・SEとの違い

コンサルティングは提言までが成果物で、受託開発は納品までが契約の終わりです。FDEは自分で手を動かし、業務で使われる状態まで持っていきます。

### SES・受託との違い

SESは技術者の稼働時間を提供する契約です。決定的な違いは**自社プロダクトを持っているかどうか**で、1社で解いた知見が製品に載り、次の顧客へ引き継がれていきます。

| 形態 | 主な成果物 | 責任の終点 | 自社プロダクト |
|---|---|---|---|
| コンサルティング | 提案書・計画 | 提言まで | 持たない |
| 受託開発 | 納品物 | 納品まで | 持たない |
| SES・技術者常駐 | 稼働時間 | 労働の提供まで | 持たない |
| FDE | 動くシステム | 使われる状態まで | 持つ |

## FDEの仕事は5つの工程

仕事の流れは、課題の定義、試作の提示、要件の確定、本番への移行、使われ方を見た改善の5つに分かれます。大きくまとめると、次の3つです。

### 課題を定義する

顧客が言葉にできていない困りごとを、現場で聞き取って形にします。依頼された内容をそのまま作るのではなく、何を解けば業務が変わるかを先に決める工程です。

### 動くものを先に出す

要件書ではなく試作を出し、触ってもらって要件を確定させます。**紙の上の合意より、動くものへの指摘のほうが速くて正確**だからです。

### 運用に載せて改善する

本番の業務に載せ、使われ方を見て直します。ここで見つけた型をプロダクト側へ返すところまで進んで、1社の仕事が製品の資産に変わります。

## 求められる3つの力

自分で実装しきる力、業務を読む力、決まっていない前提をその場で決めきる力の3つです。

### 実装しきる力

提案で終われないため、自分で書いて動かせることが前提です。設計だけ、調整だけを担当する立て付けでは成立しません。

### 業務を読む力

業界の規制、承認の流れ、現場の慣習まで含めて業務を読む力です。システムの正しさより、現場が受け入れられる形かどうかが優先される場面があります。

### 前提を決めきる力

決まっていないことを、その場で決めて前に進める力です。持ち帰って会議にかけるほど、現場の意欲は下がります。**決めた前提を言葉にして残す**ところまでが仕事で、この設計力については別記事で解説しています。

【関連記事】[AI時代のDDDスキルとは?AIコーディングで重要になる設計力を解説](https://www.waltsu.co.jp/magazine/ai/ai-ddd-skills/)

## 報酬が高いのはなぜか

金額は企業と時点で幅が大きいため、ここでは理由の構造だけを見ます。**報酬を押し上げているのは、担える人の少なさと責任範囲の広さ**です。

- **3つを1人で持つ**: 実装力・業務理解・折衝を分業せずに担う
- **終点が遠い**: 責任が納品ではなく、使われる状態まで伸びている
- **成果が二重に残る**: 顧客の現場と自社プロダクトの両方に残る

裏返すと、どれか1つでも欠けている求人は、名前がFDEでも中身は別の職種です。

## 発注側が見る4つの点

自社にFDEを置かない会社には、頼む相手がFDE型かを見分ける目が要ります。見積もりと提案の場で、次の4点を質問に変えて確かめます。

### 契約の終点はどこか

納品物を渡した時点で終わるのか、業務で使われる状態までが範囲なのか。**完了の定義を先に言葉で合わせておく**と、後から揉める余地が減ります。

### 誰のデータで作るか

見本用のデモ環境で作るのか、自社の実データと制約の中で作るのか。実データに触れる時期が遅い提案ほど、後になって作り直しが発生します。

| 見る点 | 確かめ方 | 危ない答え |
|---|---|---|
| 責任の終点 | 何をもって完了とするか聞く | 「納品物の一覧でご確認ください」 |
| 使うデータ | 実データを触るのはいつか聞く | 「まずサンプルで作ります」 |
| 最初の1つ | 動くものが出るまでの日数を聞く | 「要件が固まり次第、着手します」 |
| 終わった後 | 誰が直し続けるか聞く | 「保守は別途お見積もりです」 |

![AI導入を外部へ頼むときに確かめる4点と、その質問・危ない答えを2行2列のカードで整理した図](https://www.waltsu.co.jp/wp-content/uploads/2026/09/forward-deployed-engineer02.png)

## FDEを置けない会社の代わり

代わりの手は2つあります。業務をよく知る社内の1人に役を集めるか、支援会社との契約の終点を使われる状態にずらすかです。

### 社内の1人に集める

業務をよく知っている人に、実装や設定まで見る役を寄せます。ツールの選定で手を離さず、**使われるところまでを1人の持ち場にする**のが要点です。

### 支援会社に終点を持たせる

外部に頼む場合は、契約の終点を納品から使われる状態へずらします。検収の条件は、成果物の一覧ではなく、業務で動いた事実です。社内の推進体制をどう組むかは、AI活用を組織として進める話として別記事で解説しています。

【関連記事】[AX推進とは？企業がAI変革を成功させる進め方・体制・7つのステップを解説](https://www.waltsu.co.jp/magazine/ai/ax-promotion/)

## うまくいかない3つの型

失敗の型は、要件を書けるのにFDE型を選ぶ、知見が1社専用で終わる、実データと担当者が出てこない、の3つです。

### 要件が書けるのに頼む

仕様を先に書き切れる案件でFDE型を選ぶと、費用と時間だけが増えます。**要件が固まっているなら、普通の受託のほうが安くて速い**のは変わりません。

### 1社専用で終わる

解いた知見がプロダクトへ返らないと、単価の高い受託と変わりません。

### 現場に入れない

実データも現場の担当者も出てこない案件では、誰が入っても結果は同じです。受け入れる側が現場を開けるかどうかが先に問われます。

## FDEはAIに置き換わるか

[Palantir 公式ドキュメント「AI FDE 概要」](https://www.palantir.com/docs/foundry/ai-fde/overview)では、AI FDEという機能が公開されています。会話による指示でFoundryを操作する対話型のエージェントで、実行した操作や使ったツールの記録が残る仕組みです（2026年9月時点。導入時は公式の最新の仕様を確認してください）。

- **機械へ寄る**: 設定、実装、データの変換といった手続きの工程
- **人に残る**: 言語化されていない課題を、現場で聞き取って形にする工程

仕事を預けて結果を受け取る形のAIについては、別記事で解説しています。

【関連記事】[Devinとは？できること・料金・Claude Codeとの違いを解説](https://www.waltsu.co.jp/magazine/ai/devin/)

## 【プロの視点】見るのは提案書より初速

FDEの解説は、たいてい「顧客の現場に入るから成功する」「希少な超人材だ」というところで終わります。読む側からすると、うちには来ない人の話として読み流してしまう。ですが発注する側に要るのは、その人をどう雇うかではなく、**自社の案件がFDE型を必要とするのかを見分ける目**です。

FDEが解いているのは、技術の難しさではありません。**顧客が要件を先に書けない**という問題です。何に困っているかを言葉にできないから、要件定義から順に進める手順が機能しません。

この見方に立つと、見るべきものが変わります。提案書の厚さでも、事例の数でもありません。**最初に動くものが出るまでの日数と、そこから何回作り直したか**です。厚い提案書は、要件が書ける領域では精度の証明になりますが、書けない領域では不安を埋めるための厚さになりがちです。

裏返せば、要件を紙に書き切れる案件なら、FDE型で頼む必要はありません。**FDEが要るかどうかは、AIの難易度ではなく、要件を先に書けるかどうかで決まります**。

明日できる一歩は簡単です。次の見積もりの場で「最初に動くものが出るのは何日後ですか」と1行だけ聞いてみてください。日数そのものより、答え方に相手の進め方が出ます。

![提案書を厚くする進め方と、最初に動くものを出してから要件を固める進め方を上下で比べた図](https://www.waltsu.co.jp/wp-content/uploads/2026/09/forward-deployed-engineer03.png)

## 【waltsu視点】動くものを先に出す

提案の場に持っていくものを、スライドから実機で動くプレビューサイトに変えました。画面共有でトップから問い合わせまでの導線を実際にたどり、言語の切り替えもその場で動かします。静止画の資料では、完成した画面がどう動くかまでは伝わりません。初回に返ってきた反応を受けて作り直し、次の打ち合わせでアップデート版を見せる。この往復を、契約の前から始める形にしています。

**狙いは説明の時間を減らすことではなく、顧客が「違う」と言える場を契約より前に作ること**です。資料の上では、相手は完成形を想像して評価するしかありません。

FDEの核にあるのは肩書きではなく**順番**です。要件を固めてから作るのではなく、作ってから要件を固める。AI企業でなければできない進め方ではありません。最初の1つを出す速度がAIで上がったぶん、この順番は以前より現実的になりました。

社内でAIに任せる範囲を広げる話とは、向きが逆です。社内の仕事は、指示を言葉にできた分だけ機械へ渡せます。一方、顧客の要望は先に言葉にしてもらえません。**言語化できないものは、動くものを見せて引き出すしかない**のです。

明日の一歩は、次の提案で資料を1ページ減らし、1画面だけ動くものを持って行くことです。相手が指を差せるものが、その場に1つあるかどうかです。

![動くものを先に出して顧客の反応から要件を固め直す循環と、その中心にある試行回数を示す循環図](https://www.waltsu.co.jp/wp-content/uploads/2026/09/forward-deployed-engineer04.png)

## まとめ

FDEは、自社のプロダクトを持って顧客の現場に入り、課題の定義から実装、実際に使われる状態になるまでを担うエンジニアです。コンサルティングは提言まで、受託開発は納品まで、SESは稼働時間の提供まで。並べてみると、違いは働く場所ではなく責任の終点にあることがはっきりします。

発注する側が確かめるのは、提案書の厚さや事例の数ではありません。何をもって完了とするのか、実データにいつ触れるのか、最初に動くものが出るまで何日かかるのか、終わった後は誰が直し続けるのか。この4つで、納品で終わる契約かどうかを見分けられます。

FDEを職種として置ける会社は多くありません。それでも、要件を後から固めるという順番だけなら、明日の提案からでも取り入れられます。開発の仕事そのものが決める・確かめる側へ移っていく流れは別記事で解説しています。

【関連記事】[AI駆動開発とは？従来の開発との違い・工程別の変化・始め方を解説](https://www.waltsu.co.jp/magazine/ai/ai-driven-development/)

どこまでを依頼の終点に置くかで迷う場面が出てきたら、waltsuが要件の整理から実装・運用の設計までご支援します。

## よくある質問

**Q. FDEは何の略ですか？**  
A. Forward Deployed Engineer の略で、日本語ではフォワードデプロイドエンジニアと呼ばれます。なお情報セキュリティの分野では Full Disk Encryption（フルディスク暗号化）の略として使われることもあるため、文脈で見分けてください。

**Q. 客先常駐と同じですか？**  
A. 違います。常駐の有無は働き方の形で、出社の頻度もリモートの比率も企業ごとに異なります。分けているのは責任の終点で、稼働時間を提供して終わるのか、業務で使われる状態まで持っていくのかが境目です。顧客先に通っていても、完了の定義が納品であればFDEとは呼べません。

**Q. 未経験からなれますか？**  
A. 公開されている求人の多くは開発経験を前提にしています。未経験者の入口というより、実装力と業務理解の両方を持つ人の受け皿と考えるほうが実態に近いでしょう。顧客と直接やり取りする場面が多いため、技術力に加えて話を引き出す力も見られます。

**Q. 年収はどれくらいですか？**  
A. 企業が公表している一次情報は少なく、媒体ごとに提示されるレンジの幅も大きいのが現状です。金額を一般論で語る意味は薄いため、個別の求人票で確認してください。その際は、実装まで担うのか、どこまでが責任範囲かを金額と合わせて見てください。

**Q. 中小企業にも必要ですか？**  
A. 職種として新しく置く必要はありません。要件を先に書けない案件に限って、動くものを先に出す進め方を取り入れれば足ります。要件を書き切れる案件は、従来どおりの受託で頼むほうが安く済みます。

## 執筆者

**藤井 俊輔**（代表取締役）ベンチャー企業の外部CMOや水族館のマーケティング担当などに従事。オンライン/オフライン問わず集客を中心としたマーケティング施策に強み。

プロフィール: https://www.waltsu.co.jp/magazine/supervisor/shunsuke-fujii/

この記事は waltsu 公式ブログの記事（https://www.waltsu.co.jp/blog/forward-deployed-engineer/）をもとに再編集したものです。