「FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア）って、セールスエンジニアやカスタマーサクセスエンジニアと何が違うの？」「ソリューションアーキテクトとは別の職種なのか」——FDE という言葉が広がるにつれ、似た職種との違いを聞かれる機会が増えています。
結論から言うと、FDE が似た職種と最も異なるのは、導入前の支援や設計・助言で終わらず、顧客の現場で実際に動く仕組みを作り、運用・定着・成果の確認まで責任を持つ点です。 セールスエンジニアは「導入前」、カスタマーサクセスエンジニアは「導入した自社製品の活用」、ソリューションアーキテクトは「構成の設計」に重心があります。FDE はその間の「業務を実際に変えて、成果を出す」までを一人（または一つの体制）で担います。
この記事では、FDE サービスを提供している株式会社 DeploAI が、似た職種との違いを責任範囲・関わる時期・成果物で整理し、SaaS 営業部門の AI 化を例に各役割の担当範囲を比べ、自社に必要な役割を見分ける問いを示します。FDE の定義そのものはFDEとは？で解説しています。本記事は似た職種との違いに絞ります。
なお、これらの職種名の定義は企業ごとに異なります。以下は一般的な傾向としての整理で、個々の企業の職務内容とは一致しない場合があります。
FDEと似た職種は、何がどう違うのか？
FDE と似た職種の違いは、「いつ関わるか」「どこまで責任を持つか」「何を残すか」の 3 点で整理できます。 一覧にすると次のとおりです。
| 職種 | 主に関わる時期 | 主な役割 | 責任の範囲 |
|---|---|---|---|
| セールスエンジニア | 導入前（商談中） | 技術的な説明・デモ・質問への回答で受注を支援する | 受注まで |
| ソリューションアーキテクト | 導入前〜構築 | 顧客の課題に合わせて、製品や技術の構成を設計する | 設計・助言まで（実装は別の担当が多い） |
| カスタマーサクセスエンジニア | 導入後 | 導入済みの自社製品を、顧客が使いこなせるよう技術面から支える | 自社製品の活用・定着 |
| 導入コンサルタント（プロフェッショナルサービス） | 導入時 | 製品の初期設定・導入作業・移行を支援する | 導入の完了まで |
| FDE | 課題の発見から定着・成果まで | 顧客の現場で、業務に合わせた仕組みを実装し、成果が出るまで伴走する | 成果が出て、自走できるまで |
それぞれの役割は、具体的に何をするのか？
セールスエンジニア：導入前の「技術的な不安」を解く
セールスエンジニアは、営業担当と一緒に商談に入り、顧客が持つ技術面の疑問に答える役割です。デモの実施や、セキュリティ・連携についての質問への回答が中心です。目的は受注の支援であり、導入後の運用や成果は主な責任範囲に含まれないのが一般的です。
ソリューションアーキテクト：課題に合わせて「構成を設計する」
ソリューションアーキテクトは、顧客の課題を聞き、どの製品や技術をどう組み合わせれば解けるかを設計します。設計と助言が中心で、実際に作って動かす作業や、現場に定着させる作業は、別の担当や顧客側が担うことが多い職種です。
カスタマーサクセスエンジニア：導入した自社製品を「使いこなさせる」
カスタマーサクセスエンジニアは、導入済みの顧客が、自社製品で期待する成果を出せるように技術面から支えます。設定の相談、活用方法の提案、連携のサポートなどが中心です。対象は基本的に自社製品の範囲で、顧客の業務全体を作り変える役割ではありません。
導入コンサルタント：製品の「導入作業」を終わらせる
導入コンサルタント（プロフェッショナルサービス）は、製品の初期設定、データ移行、既存システムとの接続といった導入作業を担います。ゴールは導入の完了で、その後に現場で使われ続けるか、業務の数字が変わるかは、顧客側の取り組みに委ねられやすい領域です。
FDE：業務の中に入り、成果が出るまで「伴走する」
FDE は、顧客の業務現場に入り込み、課題の発見、実装、定着・運用、知見の還流を、ひとつのロールとして担います。他の職種が「導入前」「設計」「自社製品の範囲」「導入作業」といった一部の局面を担うのに対し、FDE は局面をまたいで、業務の成果が出るまで責任を持つのが特徴です。
局面ごとに役割が分かれる一般的な体制。FDE は、これらの局面をまたいで業務の成果まで担う。
具体例：SaaS営業部門の「商談メモのSFA自動入力」を、各役割はどこまで担うか？
違いは、具体例で見ると分かりやすくなります。状況は説明用の仮の例です。 営業 40 名の SaaS 企業が、「商談後のメモを、SFA に自動で入力する仕組みを作りたい」と考えたとします。
| 工程 | セールスエンジニア | ソリューションアーキテクト | CSE・導入コンサル | FDE |
|---|---|---|---|---|
| 検討段階の技術質問に答える | ○ | ○ | – | ○ |
| 自社のSFA項目に合う構成を設計する | – | ○ | – | ○ |
| 自社の商談フローに合わせて実際に作る | – | △（設計まで） | △（製品の設定まで） | ○ |
| 現場で使われているか確認し、直す | – | – | △（自社製品の範囲） | ○ |
| 入力率・工数などの数字の変化を見る | – | – | △ | ○ |
| 得た型を次の業務に使える形で残す | – | – | – | ○ |
（○＝主な担当、△＝一部、–＝通常は範囲外。会社や契約によって異なります）
この仮の例で見るべきは、「実際に作る」から「数字の変化を見る」までの行が、他の役割では途切れやすい点です。構成を設計し、製品を設定しても、「営業が実際にメモを入力しなくなったか」「SFA の入力率が上がったか」を現場で確かめて直す役割がいなければ、仕組みは作られたのに使われないまま止まります。これはAI導入がPoC止まりになる典型的な理由でもあります。
営業 AI の具体的な進め方は営業のAI活用は何から始める？で、SFA 入力の自動化はSFA・CRMの入力をAIで自動化するには？で解説しています。
「FDE」と名乗っていれば、FDEの役割を担っているのか？
職種名や商品名に「FDE」とあっても、実態が同じとは限りません。 名前が先に広がった分、技術支援や導入作業を FDE と呼んでいる場合もあります。見分けるときは、名前ではなく次の 3 点を確認します。
- 本番運用と成果への責任があるか：作って終わりではなく、業務の数字が動くところまで見るか
- 顧客の環境の中で実装するか：顧客のデータ・権限・業務フローの中で、実際に動く仕組みを作るか
- 得た知見を還流するか：テンプレートや評価の仕組みなど、再現できる形で資産として残すか
外部の支援を選ぶ場合の確認項目は、FDEとは？の選定チェックリストと生成AI導入支援の選び方にまとめています。
自社に必要な役割は、どう見分ければよいのか？
自社に必要な役割は、「いま解決したい課題がどの局面にあるか」で見分けます。 次の 5 つの問いに答えると絞り込めます。
- 導入するかどうかを決める前か：技術面の不安を解く、セールスエンジニア的な支援が合う
- どの製品・技術を組み合わせるか決まっていないか：構成を設計する、ソリューションアーキテクト的な支援が合う
- すでに導入した製品を使いこなせていないか：製品の範囲なら、カスタマーサクセス的な支援が合う
- 業務そのものを変えて、数字を動かしたいか：業務に入り込んで伴走する、FDE 的な支援が合う
- 作ったあと、自社で更新・運用できる状態にしたいか：型や評価の仕組みを残す前提の、FDE 的な伴走が合う
複数の問いに当てはまる場合は、役割を組み合わせます。 たとえば、構成の設計は社内の担当者が行い、実装から定着までを外部の FDE が伴走する、といった形です。FDE を自社に取り入れる方法（採用・社内育成・外部サービス）はFDEを自社に取り入れるには？で比較しています。
FDEが適さないのは、どんなケースか？
既製の SaaS を設定するだけで課題が解ける場合や、助言・設計図だけが必要な場合は、FDE は過剰です。 製品の設定ならカスタマーサクセスや導入コンサルタント、構成の助言ならソリューションアーキテクト、要件が固まった大規模開発の発注なら SIer のほうが適します。「どの役割が自社に合うのか」の判断自体を迷うときは、現状の整理から始めるのが近道です（自社は生成AIをどこまで活用できる状態？）。
DeploAI の FDE は、どの役割を担うのか
弊社（株式会社 DeploAI）の FDE は、営業・マーケティング・カスタマーサクセスなどのフロント部門の AI 化を、現状診断から内製化までの 10 の工程に分け、必要な範囲をプランで選べる形で提供しています。課題の発見、実装、定着、成果の確認、知見の還流までを、顧客の現場に入って伴走します。
伴走で築いた型は、テンプレート・評価の仕組み・知識基盤として御社の資産になります。外部の FDE が担うのは、成果を先に作ることと、型を社内に移すことです。費用の考え方や範囲は料金とサービス内容に、具体的な適用業務はユースケースにまとめています。
まとめ
- FDE と似た職種の違いは、いつ関わるか・どこまで責任を持つか・何を残すかで整理できる
- セールスエンジニアは導入前、ソリューションアーキテクトは設計、カスタマーサクセスエンジニアは自社製品の活用、導入コンサルタントは導入作業が中心
- FDE は局面をまたいで、実装から定着・成果の確認、知見の還流までを担う
- 職種名だけで判断せず、本番運用と成果への責任・顧客環境での実装・知見の還流の 3 点で見分ける
- 自社に必要な役割は、課題がどの局面にあるかで決め、必要なら組み合わせる
「うちの課題にはどの役割が合うのか」という段階のご相談も歓迎です。お気軽にお問い合わせください。
