FDE CAREER ARTICLE
FDEとソリューションエンジニア・SAの違い【2026年版】公式求人で比較
FDE、ソリューションエンジニア、ソリューションアーキテクト、Applied AI Architectは、いずれも顧客の課題と技術をつなぐ仕事です。違いは肩書きそのものではなく、商談前の技術検証、本番システムの実装、導入後の成果を誰がどこまで所有するかに表れます。
たとえばOpenAIの東京求人では、Solutions Engineerはプリセールスを担い、FDEは課題発見から本番展開までを所有します。一方、AnthropicのApplied AI Architectはプリセールスと明記されながら、技術発見から導入まで顧客を支援します。つまり「この職名なら必ずこの仕事」と一律には決められません。
この記事では、OpenAI、Google Cloud、AWS、Microsoft、Anthropic、Palantirの公式求人・公式文書を同じ物差しで比較します。FDEの基本的な仕事内容から確認したい方は「FDEの仕事内容・業務フロー」をご覧ください。
この記事の要点
- 今回確認した求人では、ソリューションエンジニアは商談前の技術評価・デモ・PoCに重心がある
- ソリューションアーキテクトは、要件と制約をアーキテクチャへ変換し、技術判断を支える比重が高い
- FDEは、自らコードを書き、顧客固有の仕組みを本番へ届ける責任を明記する求人を複数確認できる
- 本記事で確認したAnthropic東京求人では、Applied AI Architectはプリセールスの技術アドバイザーである
- 応募時は職名より、商談・設計・実装・本番運用・成果指標の5領域を確認する
目次
結論:FDEとの違いは「本番実装と成果を誰が担うか」
4職種には、顧客の業務を理解し、技術的な解決策を考え、社内外の関係者を動かすという共通点があります。そのうえで、今回確認した公式情報から見える重心は次のとおりです。
| 職種 | 公式求人で見える主な重心 | 実装との関わり | 成果の置き方 |
|---|---|---|---|
| FDE/FDSE | 顧客課題の発見から設計、構築、本番展開、改善 | 自ら本番コードを書く、または共同で本番へ出すことを明記する例がある | 本番採用、業務への影響、顧客のミッション達成 |
| ソリューションエンジニア | 商談前の技術評価、デモ、PoC、技術的な意思決定の支援 | デモやPoCは作るが、本番デリバリーを別チームやパートナーへ渡す例もある | 技術的な納得、案件成立、製品採用への前進 |
| ソリューションアーキテクト | 要件整理、アーキテクチャ設計、技術判断、導入計画 | PoCやプロトタイプへ関わる一方、実装主体か支援役かは求人ごとに異なる | 安全で拡張可能な設計、採用促進、長期的な技術成功 |
| Applied AI Architect | Anthropic東京求人では、Claude導入のプリセールス技術助言、設計、eval支援 | PythonやLLM実装知識を求めるが、本番コードの直接所有は明記していない | 顧客が価値を理解し、安全に統合・導入できる状態 |
最も分かりやすい差は、本番実装の所有です。OpenAIの東京FDE求人は、プロトタイプから安定した本番環境までの技術デリバリーと、必要な場面で直接コードへ貢献することを挙げています。対して同社の東京Solutions Engineer求人は、職名に「Pre-Sales」を掲げ、技術要件の整理、デモ、ユースケース選定、PoC、購買過程の顧客関係を中心にしています。
ただし、すべての企業がこの線で分業しているわけではありません。ソリューションアーキテクトが実装へ深く入る求人も、FDEがチームでデリバリーを分担する求人もあります。応募先を判断する際は、次の5段階を求人票で追う必要があります。
PROJECT STAGES顧客プロジェクトの5段階で重心を読む
- 商談・発見課題、価値、技術要件を整理する
- デモ・PoC技術的な実現性と価値を確かめる
- 設計要件、制約、運用を構成へ落とす
- 本番実装コード、データ、既存環境を接続する
- 展開・改善利用定着と成果を測り製品へ返す
FDEの比較軸:顧客環境で作って届ける
FDE(Forward Deployed Engineer)またはFDSE(Forward Deployed Software Engineer)は、顧客の近くで課題を理解し、解決策を設計し、自ら実装して本番へ届けるエンジニアです。ただしFDEという名称自体に、全企業共通の職務定義はありません。
OpenAIは課題発見から本番展開までを一気通貫で所有
OpenAIの東京FDE求人は、顧客へのデリバリーと中核プラットフォーム開発の交点にチームを置いています。担当範囲として、課題発見、技術スコープ、システム設計、構築、本番展開を挙げ、成功を本番採用、測定できる業務への影響、製品・モデル改善へつながるフィードバックで捉えています。
Google Cloudは「高レベル設計を越えて」コードと共同出荷を担う
Google Cloudの東京向けGenAI FDE求人は、FDEを顧客環境に入るビルダーと位置づけています。高レベルのアーキテクチャだけでなく、コードを書き、デバッグし、顧客と共同で個別のAIソリューションを本番へ出すことを明記しています。
Palantirは顧客の成果に向けた実装を最初から最後まで担う
Palantirの東京FDSE求人では、顧客の重大な課題を理解し、データを使った解決策を設計・実装します。小さなチームで、高い重要度を持つ案件の実行を最初から最後まで所有し、アーキテクチャ、データ処理、Webアプリ開発、経営層との会話、チーム戦略まで横断します。
ここまでFDEの業務範囲を整理しました。以降は、ソリューションエンジニア、ソリューションアーキテクト、Applied AI Architectとの境界に論点を限定します。
ソリューションエンジニアとは:技術で購買前の意思決定を進める
「ソリューションエンジニア」は、一般に顧客向け技術職として使われる名称ですが、営業支援、本番導入、カスタマーサクセスの配分は会社ごとに違います。今回確認したOpenAIとMicrosoftの東京求人は、いずれもプリセールスまたはテクニカルセールスを明示しています。
OpenAIはデモ・ユースケース選定・PoCを通じて購入判断を支える
OpenAIの東京Solutions Engineerは、顧客のプリセールス上のニーズを理解し、AI戦略、高価値ユースケース、アーキテクチャパターンを提案します。職務には、製品価値の説明、技術要件への回答、デモ、ユースケースのスコープ、PoC、セキュリティ・コンプライアンス質問への一次対応が含まれます。
FDEと共通するのは、顧客課題を理解し、技術を使って価値を示す点です。一方、この求人では顧客との関係を「評価・購買プロセス」で育てることが明記されており、FDE求人のような安定した本番システムまでの直接所有は中心に置かれていません。
Microsoftには実装をSIパートナーへ引き継ぐ求人例がある
Microsoftの東京向けDynamics 365 Sales & Service Solution Engineer求人は、顧客構想、デモ、PoC、Proof of Value、RFP/RFI対応、アカウント計画を担当します。同求人は、技術的に検証した商談をSIパートナーへ引き継ぎ、自らデリバリーを主導しないことも明記しています。
これはソリューションエンジニアとFDEの差が明確な一例です。ただしMicrosoft内にも製品・業界別の複数職種があり、この一求人をすべてのSolution Engineerへ一般化はできません。
ソリューションアーキテクトとは:要件と制約を技術判断へ変える
ソリューションアーキテクトは、顧客の事業要件、既存環境、セキュリティ、信頼性、コストなどを踏まえ、システム全体の構成と技術判断を導く役割です。FDEと比べたときの典型的な差は、コード量ではなく、設計判断と技術助言の責任が職務の中心に明示されるかです。
AWSは顧客・営業と連携し、設計と技術支援で導入を進める
AWSの日本向けSolutions Architect求人では、顧客の経営層や技術責任者へAWSの価値を伝え、ユースケースの定義、マイルストーン策定、アーキテクチャ策定、パートナー連携を担います。デモ実装やプロトタイピング支援も含まれるため、手を動かさない仕事ではありません。
一方、同求人の主語は、顧客のワークロード実現を「技術面から支援する」ことです。顧客固有の本番アプリケーションを自ら最後まで保有するかは記載されていません。FDEとの差は、ハンズオンの有無ではなく、本番デリバリーの最終責任にあります。
アーキテクトは実装チームから離れる職種とは限らない
Microsoft Azure Well-Architected Frameworkは、アーキテクトの成果物として、要件との整合、設計仕様、図、Architecture Decision Record、PoCによる仮説検証、実装チームとの協働、運用後の最適化を挙げています。設計だけを渡して終わるのではなく、実装・運用の現実を踏まえた役割です。
したがって「ソリューションアーキテクトはコードを書かず、FDEだけが書く」という二分は正確ではありません。求人票では、PoCを自ら作るのか、実装チームへ助言するのか、本番コードを保有するのかを分けて読みます。
Applied AI Architectとは:Anthropicではプリセールスの技術アドバイザー
Applied AI Architectは、少なくとも本記事で扱う文脈ではAnthropicが使用する職名です。AI業界全体で統一された資格名や標準職種ではありません。
Anthropicの東京Applied AI Architect求人は、この役割をプリセールスのアーキテクトと明記しています。大企業がClaudeの価値を理解し、安全かつ信頼できる形で技術基盤へ統合できるよう、信頼される技術アドバイザーとして支援します。
具体的には、営業担当と顧客要件を理解し、技術解決策へ変換すること、技術発見から初期評価・導入まで支援すること、Claude APIとClaude for Workの活用、アーキテクチャ判断、eval設計、共通の統合パターンを製品・エンジニアリングへ戻すことが含まれます。Pythonへの習熟も求めています。
FDEとの重なりは大きいものの、同求人は「自ら本番コードを所有する」とは書いていません。求人票から読み取れる重心は、顧客の技術判断、アーキテクチャ、評価、安全な導入を前へ進めることです。名称に「Applied AI」が入っていても、Applied AI EngineerやFDEと同じ職務とは限りません。
JOB TITLE vs. OWNERSHIP肩書きではなく責任範囲を読む
FDE、Solutions Engineer、Solutions Architect、Applied AI Architectだけでは、実装範囲を確定できない。
本文で検証
何を所有し、何を自ら作り、何を支援するのか。対象と到達点まで読んで判断する。
公式求人を同じ4軸で比べる
企業別の違いを見落とさないよう、6社の求人を同じ軸へ整理します。「強い・弱い」の評価ではなく、求人本文がどこを明確に責任としているかの比較です。
| 企業・職種 | 商談・課題発見 | 設計・PoC | 本番実装 | 導入後・製品還元 |
|---|---|---|---|---|
| OpenAI FDE | 顧客と発見・技術スコープ | システム設計・試作 | 本番コードと安定展開を所有 | 採用・業務影響を測り、研究・製品へ還元 |
| OpenAI Solutions Engineer | プリセールス要件・高価値ユースケース | デモ・PoC・推奨アーキテクチャ | 求人では本番所有を明記せず | 顧客の声を製品計画へ共有 |
| Google Cloud GenAI FDE | technical discovery | AIシステム設計 | コード・デバッグ・顧客との共同出荷 | 現場知見を製品ロードマップへ還元 |
| AWS Solutions Architect | 事業・IT課題から提案 | アーキテクチャ、デモ、試作支援 | 求人では技術支援が主語 | 長期計画・サービス改善・知見発信 |
| Microsoft Solution Engineer | プリセールス、RFP/RFI、価値訴求 | デモ・PoC・Proof of Value | 確認求人ではSIへ引き継ぎ | 競合・顧客情報を製品チームへ共有 |
| Anthropic Applied AI Architect | プリセールス技術発見 | LLM設計、統合、eval支援 | 求人では直接所有を明記せず | 導入支援・統合パターンを製品へ還元 |
| Palantir FDSE | 顧客の重大課題を直接理解 | 設計・データ・アプリ構築 | 高重要度案件を最初から最後まで実行 | 利用者と反復し、顧客の現実の成果を追う |
求人票を読むチェックリスト
職名だけで応募先を選ぶと、入社後に「想像より営業寄りだった」「設計中心で実装時間が少なかった」「顧客対応と出張が多かった」といったずれが起きます。次の順番で求人票と面接を確認してください。
- プロジェクトの開始点を確認する:商談前の案件評価から入るのか、契約後のデリバリーから入るのか、既存顧客の改善を担うのかを読みます。
- 実装を表す動詞と目的語を探す:「build」「code」「implement」「jointly ship」が、デモ、PoC、本番アプリ、データ基盤のどれを指すか確認します。
- 所有と支援を分ける:「own」「lead」と、「guide」「support」「advise」では責任の置き方が違います。何を最後まで所有するかを確認します。
- 本番後の到達点を見る:契約、技術的な意思決定、導入、利用定着、業務KPIのどこを成功とするかを読みます。
- 社内外の分業を確認する:営業、Professional Services、SIパートナー、Customer Success、製品チームの誰へ何を引き継ぐかを面接で尋ねます。
- 働き方を責任範囲と一緒に見る:顧客訪問、出張、常駐、出社日数、複数案件の同時担当は、仕事内容と負荷を大きく変えます。
面接で確認したい8つの質問
- 案件は契約前と契約後のどちらから担当しますか?
- 1週間のうち、実装、顧客会議、社内調整に使う時間の目安はどの程度ですか?
- PoCのコードを本番へ育てるのは誰ですか?
- 本番障害や品質問題の最終責任はどのチームが持ちますか?
- 個別顧客向けコードは誰が長期保守しますか?
- この職種の評価指標は、売上、導入、利用率、業務成果のどれですか?
- 顧客で得た知見を製品ロードマップへ戻す仕組みはありますか?
- 直近の案件で、この職種が実際に作った成果物を差し支えない範囲で教えてください。
現在公開されているFDE求人そのものを比べたい場合は「FDE求人一覧【2026年7月版】」を、応募準備全体を進めたい場合は「FDE転職ガイド【2026年版】」を参照してください。
自分に合う職種を判断する
FDEが合いやすい人
- 顧客との会話だけでなく、自分で本番コードを書きたい
- 要件が固まる前から入り、課題そのものを定義したい
- フロントエンド、バックエンド、データ、AI、運用を横断したい
- 完成した機能より、現場で起きた変化を成果として追いたい
ソリューションエンジニアが合いやすい人
- 複雑な技術を意思決定者へ分かりやすく伝えることが得意
- 短期間で複数の業界・顧客・ユースケースへ向き合いたい
- デモやPoCで技術的な可能性を証明し、商談を前へ進めたい
- 営業、セキュリティ、製品、パートナーをつなぐ役割に関心がある
ソリューションアーキテクトが合いやすい人
- 要件、制約、リスク、運用を全体設計へ落とすことが得意
- 複数の選択肢を比較し、技術判断の理由を説明したい
- 実装チーム、経営層、セキュリティ、パートナーを横断したい
- 一つの機能より、長期的に変化できるシステム全体を考えたい
Applied AI Architectが合いやすい人
- LLMの能力・限界・evalを理解し、企業導入の判断を支えたい
- 技術と経営の双方へAIの価値とリスクを説明したい
- エンタープライズ統合、クラウド設計、安全性に関心がある
- プリセールスから初期導入まで、顧客の技術アドバイザーを担いたい
これは適性検査ではありません。同じ人が、企業やキャリア段階によって複数の役割へ適合することもあります。転職時は肩書きの一致より、自分が作りたい成果物と、求人が任せる責任範囲の一致を優先してください。
FDEと類似職についてよくある質問
FDEとソリューションエンジニアの一番大きな違いは何ですか?
Q
FDEとソリューションエンジニアの一番大きな違いは何ですか?
A
今回確認した公式求人では、ソリューションエンジニアは商談前の技術評価、デモ、PoC、購入判断に重心があり、FDEは顧客課題の発見から本番実装・展開までを所有する例が目立ちます。ただし会社ごとに異なるため、職名だけでなく求人本文の責任範囲を確認してください。
ソリューションアーキテクトはコードを書かないのですか?
Q
ソリューションアーキテクトはコードを書かないのですか?
A
一律には言えません。AWSの求人にはデモ実装やプロトタイピング支援があり、Microsoftの公式アーキテクト文書もPoCで仮説を検証することを挙げています。確認すべきなのはコードを書くか否かだけでなく、デモ・PoC・本番のどのコードを誰が長期保有するかです。
Applied AI ArchitectはFDEの別名ですか?
Q
Applied AI ArchitectはFDEの別名ですか?
A
別名とは断定できません。Anthropicの東京求人ではApplied AI Architectをプリセールスのアーキテクトと明記し、技術発見、アーキテクチャ、eval、初期導入を支援します。FDEと重なる領域はありますが、本番コードの直接所有は同求人で明記されていません。
FDEはプリセールスを担当しないのですか?
Q
FDEはプリセールスを担当しないのですか?
A
企業やチームによっては、契約前の技術発見や試作へ関わる可能性があります。FDEの特徴はプリセールスをしないことではなく、確認した複数求人で、本番実装や導入成果まで責任範囲が続いていることです。
ソリューションエンジニアやSAからFDEへ転職できますか?
Q
ソリューションエンジニアやSAからFDEへ転職できますか?
A
顧客課題の整理、アーキテクチャ、PoC、導入推進はFDEと重なる経験です。差分になりやすいのは、自分で本番品質のコードを書き、運用・利用定着まで改善した証拠です。転職準備は「FDE転職ガイド」で確認できます。
求人票で職種名と仕事内容が一致しない場合はどう判断しますか?
Q
求人票で職種名と仕事内容が一致しない場合はどう判断しますか?
A
名称より、案件の開始点、実装対象、所有する成果、引き継ぎ先、評価指標を優先します。不明な点は、面接で直近案件の成果物、時間配分、本番コードの所有者を具体的に確認してください。
まとめ:職種名ではなく、責任の終点で選ぶ
FDE、ソリューションエンジニア、ソリューションアーキテクト、Applied AI Architectは、顧客と技術の間に立つ点でよく似ています。違いを見分けるには、商談前の技術評価で終わるのか、設計判断を担うのか、自ら本番コードを作るのか、導入後の業務成果まで追うのかを確認します。
特にFDE求人では「顧客対応があるエンジニア」という説明だけで判断せず、課題発見、設計、実装、本番展開、運用、製品への還元のどこまでを所有するかを読みましょう。応募候補を探す際は「公式FDE求人一覧」、給与条件を比較する際は「FDEの年収・給与相場」も活用してください。
企業側でFDEと類似職の責任分界を決める場合は「FDE採用ガイド【企業向け】」に、求人票・選考・組織配置の設計方法をまとめています。
参考にした公式情報
- OpenAI「Forward Deployed Engineer – Tokyo」
- OpenAI「Solutions Engineer, Pre-Sales – Tokyo」
- Google Cloud「Forward Deployed Engineer, GenAI」
- AWS「Solutions Architect, Telco & Media」
- Microsoft Careers「Tokyo」掲載のSolution Engineer求人
- Microsoft Azure Well-Architected Framework「Solution Architect’s Responsibilities」
- Anthropic「Applied AI Architect – Tokyo」
- Palantir「Forward Deployed Software Engineer – Japan Government」