「FDE（Forward Deployed Engineer／フォワード・デプロイド・エンジニア）に必要なスキルは何か」。技術力だけなのか、顧客対応も要るのか、AIやRAGは必須なのか——情報がばらばらで、自分に何が足りないのかを判断しづらい。そう感じていませんか。
この記事では、FDEに必要なスキルを、各社の公式採用ページなど一次情報から逆算して3つの軸に整理します。技術実装力・顧客ビジネス理解力・デリバリー適応力それぞれの中身、出身職種別に補うべき力、自己診断、資格や未経験の扱い、評価されるポートフォリオの作り方までを、断定を避けつつ現在地別に示します。読み終えるころには、「自分の強み」「不足スキル」「次に作るべき実績」「確認すべき求人」を判断する材料がそろうはずです。
結論として、FDEに共通して必要なのは、単にコードを書く力ではなく、顧客の課題を定義し、技術的な解決策を本番環境へ実装し、使われる状態まで進めきる力です。AI・生成AI系FDEでは、これにRAG・AIエージェント・Eval（評価）などが加わります。すべてを同じレベルで備える必要はなく、いま持っている強みを土台に、応募先の要件と照らしながら、不足領域に優先順位を付けて補うのが基本です。情報は変化が速いため、本記事の求人に関する要件は2026年7月20日時点で各社公式ページを確認したものです。
この記事でわかること
・FDEに共通して必要な3つのスキル軸
・求人要件を「必須・歓迎・役割依存」で読み分ける方法
・技術実装力／顧客・ビジネス理解力／デリバリー・適応力の中身
・出身職種別に見る「持っている強み」と「補うべき力」
・自己診断と、その後にやるべきこと
・資格の要否・未経験の可否・評価されるポートフォリオの作り方
この記事の編集者
FDE Journal編集部
FDE Journalは、Forward Deployed Engineer（FDE）に特化した専門メディアです。FDEの仕事内容や年収、必要なスキル、キャリア、求人・採用企業、国内外の最新動向などを発信しています。編集部では、企業の公式情報や求人情報、公開資料などを確認しながら、FDEについて知りたい方に信頼できる情報をわかりやすくお届けします。
FDEそのものの定義や仕事内容をまだ押さえていない方は、FDEの仕事内容・役割・他職種との違いをまとめた基礎記事もあわせてご覧ください。
FDEに必要なスキルの全体像｜求人要件から見る3つの軸
FDEに共通して必要なのは、単にコードを書く力ではありません。顧客の課題を自ら定義し、技術的な解決策を本番環境へ実装し、実際に使われる状態まで進めきる力です。求人要件を横断すると、その力は「技術実装力」「顧客・ビジネス理解力」「デリバリー・適応力」の3つの軸に整理できます。
FDEの定義は企業によって異なるが中核業務は共通する
FDEは、企業によって「FDE」「FDSE（Forward Deployed Software Engineer）」など呼称が分かれ、担当する技術領域も一様ではありません。Palantirのように大規模なデータ連携やデータ基盤を主戦場とするソフトウェア・データ系のFDEもあれば、OpenAIやGoogle Cloud、国内スタートアップのように生成AI（LLM）活用を中核に据えるAI系のFDEもあります。企業ごとに顧客接点の深さや担当範囲も変わります。
FDE／FDSEを広めたPalantirでの具体的な仕事内容や採用要件、日本から目指す際の考え方は、パランティアのFDE（FDSE）の仕事内容・必要スキルで詳しく解説しています。
ただし、呼称や領域が違っても業務の芯は近いところにあります。今回確認した主要求人・公式記事では、顧客に近い立場で課題定義から実装・定着まで関与する傾向が共通して見られます。本記事では、この共通の基礎スキルと、生成AI系FDEで特に重要度が高いスキル、そして企業・案件によって変わるスキルを区別しながら解説します（＝AI系FDEだけの説明にはしません）。
課題発見から本番定着まで担うため3つの力が必要になる
FDEが3つの力を必要とするのは、課題発見から本番定着までの工程を横断し、各工程の橋渡しまで担うからです。課題発見 → 要件・優先順位の整理 → 設計・プロトタイプ開発 → 本番展開 → 利用定着・改善 → プロダクト側へのフィードバック。実際には複数の職種やチームと協働しますが、工程間で判断や情報が途切れないよう、複数領域を理解して前へ進める力が必要です。3つの軸と業務フローの対応は次のとおりです。
| 3つの軸 | 主に効いてくる業務フロー | ひとことで言うと |
|---|---|---|
| ①技術実装力 | 設計・プロトタイプ〜本番展開・運用 | 動く仕組みを本番品質で作りきる |
| ②顧客・ビジネス理解力 | 課題発見〜要件整理／利用定着 | 解くべき課題を定義し価値に変える |
| ③デリバリー・適応力 | 全工程（不確実性への対応） | 曖昧な状況を前に進めて完遂する |
どれか一つが突出していても、他が欠ければ「PoCは作れたが本番で使われない」という形で成果が止まります。3軸はトレードオフではなく、相互に補完する関係だと捉えるのが実態に近いといえます。
3つの軸は、一つの案件の中で連動します。ここでは実在企業の事例ではなく、関係を説明するための架空のケースとして「社内向けAIチャットボットを作りたい」という相談を考えてみます。
- 顧客・ビジネス理解力：「チャットボットが欲しい」をそのまま受けず、問い合わせ工数・情報探索時間・回答品質など、本当に改善したい課題を確認する
- 技術実装力：権限管理・社内データ連携・RAG・評価環境・ログ・監視まで含めて設計・実装する
- デリバリー・適応力：対象部署を限定して試行し、回答精度・利用率・削減時間を確認しながら改善する
求人要件を「必須・歓迎・役割依存」で整理する
今回確認した公開求人を横断すると、複数の求人で重視されるスキルと、AI系や特定企業でのみ重視されるスキルに分かれます。下表は調査した範囲（2026年7月時点）の傾向で、企業横断の共通条件を断定するものではありません。
| スキル領域 | 主なスキル | 重要度の傾向 | 評価される経験・成果物 |
|---|---|---|---|
| 技術実装 | コーディング（1言語以上）、API、DB、クラウド | 複数求人の必須要件で確認 | 本番システム・個人開発 |
| 顧客理解 | ヒアリング、課題定義、要件整理 | 複数求人の必須要件・仕事内容で確認 | 顧客折衝・業務改善 |
| デリバリー | プロジェクト推進、優先順位付け、反復改善 | 仕事内容として広く確認 | 導入完遂・改善実績 |
| AI・LLM | RAG、AIエージェント、Eval（評価） | AI系求人で重要（必須/歓迎は求人による） | AIアプリの構築・評価 |
| 英語 | 海外チーム・グローバル顧客との協働 | 一部企業・ポジションで必要 | 英語での実務経験 |
たとえばOpenAIの東京拠点のFDEでは日英バイリンガルが要件に含まれる一方、国内スタートアップでは英語が必須でないケースもあります。「求人に登場すること」と「応募時の必須要件」は別物であり、重要度は企業横断で一律に断定できません。応募先ごとの確認が前提になります。
企業ごとの必須要件・歓迎要件・年収・勤務地を実際の求人で比較したい方は、FDEを採用している企業一覧をご覧ください。
スキルの土台にある「実装完遂力」
3軸すべての土台になるのが「実装完遂力」です。これは「最後の1メートルを埋める力」と表現されますが、その中身は、動くプロトタイプを作る → 顧客環境へ接続する → 本番品質へ引き上げる → 利用者に使ってもらう → 効果を検証する → 改善を継続する → 得られた知見を再利用可能な形にする、という一連の状態まで到達させる力です。
PalantirのFDSE求人でも、曖昧な顧客課題を理解し、システム設計・プロトタイピング・アプリケーション開発・データ統合を通じてエンドツーエンドの解決策を構築する役割が示されています（2026年7月20日確認）。設計や構想を語るだけでなく、現場で使われ、成果が検証され、改善が回る状態まで仕上げられるか——ここは、FDEの役割を理解するうえで重要なポイントです。
FDE Jounral 編集部気になる公式求人を3件ほど開き、「必須要件」と「歓迎要件」に線を引いて分けてみてください。自分に足りないのが実装側か顧客側か、それだけでも次の一手がはっきりします。
FDEに必要なスキル①技術実装力｜本番で動くシステムを作る力
1つ目の軸は、本番で使われるシステムを自分の手で作りきる技術実装力です。ここでは「一人称で作る力」「本番運用へ移す力」「AI系で問われる力」「未知を学ぶ力」の4点に分けて解説します。
本番品質のシステムを一人称で設計・実装する力
FDEの技術力は、特定言語の専門性より「全体を見て自分で作り切れること」に重心があります。Pythonは多くのAI系求人で登場しますが、全求人共通の絶対条件ではありません。PalantirはPython・Java・C++・TypeScript/JavaScriptなどのうち1つ以上に高い習熟を求めています。OpenAIの東京向けFDE求人では、Python、JavaScriptまたは同等のスタックを用い、フロントエンドとバックエンドにまたがる本番品質のコードを記述・レビューできることが求められています（2026年7月20日確認）。
ここで言うフルスタックは「すべての技術を専門家レベルで扱うこと」ではありません。求められるのは次のような水準です。
- バックエンド／フロントエンド／API／データベースの関係を理解している
- 既存コードを読み・修正し・デバッグできる
- 技術選定の理由やトレードオフを説明できる
- 全体を見て、自分で実装・判断できる
PoCを本番運用へ移す設計・品質・セキュリティのスキル
FDEの技術力を「短期間でデモを作る力」だけに矮小化してはいけません。デモと本番システムの間には大きな差があり、そこを埋める設計・品質・セキュリティのスキルが問われます。具体的には次の領域です。
- API・既存システムとの連携、データベース・SQL・データ設計
- クラウド環境での設計・デプロイ、認証・権限管理
- セキュリティ・プライバシー・ガバナンスへの対応
- テスト・ログ・監視・障害対応の仕組み化
- 保守性・コスト・性能を踏まえた設計判断
Google CloudのGenAI系FDEでも、統合の複雑さ・データ整備・状態管理といった「本番到達を妨げる障害」を解くことが役割として明記されています。PoCと本番の違いを理解し、運用に耐える形へ引き上げられるかが評価されます。
ありがちな失敗：RAGやエージェントのデモを作った時点で満足し、認証・監視・運用体制を考えないまま「動くもの」を本番と取り違えてしまう。
AI系FDEで求められるRAG・エージェント・評価スキル
生成AI系FDEでは、LLMを前提とした実装スキルの重要度が高まります。ただしこれは「すべてのFDEがRAGを構築できなければならない」という意味ではなく、AI系FDEにおいて重要度が高いスキル、という位置づけです。求人で頻出するのは次の領域です。
- LLM APIを利用したアプリケーション設計、RAGとデータ連携
- AIエージェント・ツール連携・ワークフロー設計、プロンプト設計
- Eval（品質評価）と改善サイクルの構築
- コスト・速度・精度・安全性のトレードオフ判断、LLMOps・監視
Google Cloudの東京向け生成AI系FDE求人では、RAG等を含む応用AI経験が最低要件として示されています。LangGraph、CrewAI、Google ADK等によるマルチエージェント実装は歓迎要件で、評価パイプラインやオブザーバビリティの構築は主な仕事内容に含まれます（2026年7月20日確認）。つまり「マルチエージェント経験がなければ応募できない」わけではありません。
国内でも同様の傾向が見られます。Sakana AIのFDE求人では、曖昧なビジネス課題の構造化、KPIの設計と合意形成、プロンプト設計、RAG構築、AIエージェント設計、出力品質の評価と改善、顧客システムとの連携が挙げられています（2026年7月20日確認）。
ありがちな失敗：AI生成コードやLLMの出力を検証せずそのまま採用し、精度・安全性の問題を本番で顕在化させてしまう。
未知の技術を短期間で学び、必要な深さまで到達する力
「深さより幅と速度が重要」と単純化するのは誤りです。FDEにも本番導入に関わる部分では深い技術判断が求められます。実態に近いのは、領域ごとに必要な深さを見極めて到達するという考え方です。
- すべての領域を同じ深さで極める必要はない
- 顧客課題に応じて、深掘りすべき領域を特定する
- 短期間で検証可能な水準まで素早く学ぶ
- 本番導入に関わる部分は十分な深さまで掘る
- 専門家へ相談すべき境界も判断する
顧客の技術スタックや業務ドメインは案件ごとに異なります。未知の環境へ短期間で適応し、実用的なソリューションへ落とし込む学習の速さと深さの使い分けが、現場での機動力を支えます。
FDEに必要なスキル②顧客・ビジネス理解力｜解くべき課題を定義する力
2つ目の軸は、顧客の課題を定義し、技術を業務価値へ変える顧客・ビジネス理解力です。ここでは課題定義・翻訳・意思決定・定着の4つの力を扱います。
顧客の要望ではなく解決すべき課題を定義する力
FDEは「要件を受ける」のではなく「課題を定義する」側に立ちます。顧客が口にする要望と、本当に解くべき課題はしばしばずれるためです。この力は、次のような具体行動として現れます。
- 要望と課題を切り分ける（例：「チャットボットが欲しい」の裏にある工数削減の目的を確認する）
- 現場・管理職・経営層で異なる目的を整理する
- 業務フロー・制約・例外処理を把握する
- あえて技術を導入しない選択肢も検討する
- 仮説を小さなプロトタイプで検証する
LayerXが公式エンジニアブログで説明するFDEの役割でも、業務フローを表面的にトレースするのではなく、前後の業務プロセスや業界特有の規制・慣習まで理解し、顧客の暗黙知を形式知に変えてAIワークフローやAIエージェントへ落とし込み、導入後の継続改善まで関与することが挙げられています（求人票そのものではなく企業公式記事での役割説明です。2026年7月20日確認）。
技術と業務を双方向につなぐ翻訳力
FDEの翻訳力は、単なる会話の得手不得手ではなく、合意形成につながる説明力を指します。方向は2つあります。
- 顧客の業務課題を、システム要件・データ要件へ変換する
- 技術的な制約・リスク・コストを、非技術者にも分かる言葉で説明する
経営層にはROIやKPIの観点でビジネスインパクトを、現場担当者には導入後の業務変化を平易な言葉で伝える必要があります。OpenAIやPalantirの求人でも、複雑な技術概念を技術・非技術双方の相手へ翻訳できるコミュニケーション力が共通して挙げられています。
ありがちな失敗：「コミュニケーション力」を雑談の得意さと捉え、意思決定に必要な情報の翻訳・合意形成を軽視してしまう。
ROI・優先順位・実現可能性から解決策を選ぶ力
技術的に面白い解決策が、事業として正しいとは限りません。FDEは効果・コスト・実現可能性を天秤にかけて解決策を選びます。
- 効果だけでなく開発・運用コストも見積もる
- 重要度と実現可能性で優先順位を決める
- KPIと評価方法を導入前に定義する
- 業界固有の規制・商習慣・業務制約を踏まえる
- PoCの実施そのものを目的化しない
ありがちな失敗：技術的な新しさを優先し、ROIや利用定着を後回しにした結果、成果の説明ができないプロジェクトになる。
現場への定着とプロダクト改善までつなげる力
作って納めて終わりではなく、使われ続ける状態まで運ぶのがFDEです。さらに現場で得た知見をプロダクトへ還元する役割も担います。
- 利用者からのフィードバック収集と、利用率・業務成果の確認
- マニュアル・ドキュメント整備と、顧客側の運用体制構築
- 個別案件の知見をプロダクトチームへ還元する
- 再利用可能なテンプレート・ナレッジへ変換する
この「現場 → プロダクト」のフィードバックループは、Palantir・OpenAI・Google Cloudのいずれの求人でも共通して重視されており、FDEを「顧客と製品をつなぐ存在」たらしめる要素です。
FDEに必要なスキル③デリバリー・適応力｜曖昧な状況から導入まで進める力
3つ目の軸は、不確実な状況を前に進めて完遂するデリバリー・適応力です。仕様が固まらない前提で、仮説検証・オーナーシップ・協働の3つの力が問われます。
曖昧な要件を仮説へ変え、反復的に検証する力
「曖昧さを歓迎する」を精神論で終わらせず、実務行動へ落とすと次のようになります。
- 不明点を洗い出し、仮説と前提条件を言語化する
- 小さな検証単位へ分解する
- 顧客と短いサイクルで確認する
- 検証結果に応じて仕様を変更する
- 完璧な要件定義を待たずに前進する
JAPAN AI（運営：株式会社ジーニー）のFDE求人でも、受託開発ではなく、顧客現場で課題を発見し、軽量なPoCを高速実装して本番導入まで伴走し、その過程で得た知見をプロダクトへ還元する進め方が示されています（求人票の記載に基づく要約。2026年7月20日確認）。「決まったら作る」ではなく「動かしながら決める」スタンスが土台になります。
課題解決から本番定着まで引き取るオーナーシップ
オーナーシップは「何でも一人で抱えること」ではありません。成果に責任を持ちつつ、リスクを適切に共有する姿勢を指します。
- スコープ・期限・品質・リスクを管理する
- 技術以外の障害も放置しない
- できないことやリスクを正直に、早めに伝える
- 必要に応じて専門家やプロダクトチームを巻き込む
ありがちな失敗：一人で抱え込み、リスクや遅延の共有が遅れて、手戻りが大きくなってから発覚する。
技術者・非技術者と協働し、知見を残す力
FDEは多様な関係者と協働し、得た知見を再利用可能な形で残します。
- エンジニア・営業・CS・法務・セキュリティ部門と連携する
- 顧客の経営層と現場担当者の合意形成を図る
- 設計判断・検証結果・運用方法をドキュメント化する
- 他案件でも使えるナレッジ・テンプレートへ変換する
海外チームとの協働や英語力の重要度は企業・拠点によって異なります。OpenAIの東京拠点のように日英バイリンガルが要件のケースもあれば、国内向け案件中心で英語必須でない場合もあります。
次の表は適性を確かめる目安です。該当したからFDEに向いていないと断定するものではなく、今後補うべき経験の手がかりとして使ってください。「一点集中の深掘り志向だからSWE向き」といった単純化は避けます（FDEにも深い専門性を要するポジションがあります）。
| 向いている傾向 | 負担を感じやすい傾向 |
|---|---|
| 顧客との対話と実装の両方を楽しめる | 顧客折衝を完全に避けたい |
| 未確定な状況でも仮説を立てて進められる | 要件が完全に固まるまで着手したくない |
| 技術より利用者の成果を重視できる | 本番運用や利用定着には関わりたくない |
| 必要な領域を素早く学べる | 技術選定や優先順位を常に他者に委ねたい |
FDEに必要なスキルの出身職種別の身につけ方
ここからは、現在地の確認から不足スキルの特定、経験の作り方、ポートフォリオ化までを順に解説します。自己診断 → 出身職種別 → 経験づくり → 実績化 → 求人での再診断、という流れで進めます。
まず求人要件と自己診断で現在地を確認する
不足を埋める前に、まず現在地を4段階で把握します。判断基準は単純なYes／Noではなく「実績として説明できるか」です。
| 診断項目 | 1：未経験 | 2：学習・個人開発 | 3：実務で一部担当 | 4：顧客案件で自律完遂 |
|---|---|---|---|---|
| 本番品質のコードを書ける | □ | □ | □ | □ |
| API・DB・クラウドを組み合わせて実装できる | □ | □ | □ | □ |
| 顧客の要望から課題を整理できる | □ | □ | □ | □ |
| 技術選定の理由を説明できる | □ | □ | □ | □ |
| 小さく検証し改善できる | □ | □ | □ | □ |
| 複数の関係者を巻き込める | □ | □ | □ | □ |
| 導入後の効果まで確認した経験がある | □ | □ | □ | □ |
| （AI系志望なら）RAGやEvalを実装できる | □ | □ | □ | □ |
診断後は、現在地に応じて次の行動へ進みます。
| 現在地 | 次に行うこと |
|---|---|
| 1：未経験 | 基礎学習を行い、小さな成果物を作る |
| 2：学習・個人開発 | 実際の利用者に使ってもらい、フィードバックを基に改善する |
| 3：実務で一部担当 | 課題設定から本番導入まで担当範囲を広げる |
| 4：顧客案件で自律完遂 | 求人要件に合わせて職務経歴書・ポートフォリオへ整理する |
合計点だけで応募可否が決まるわけではありません。企業・ポジションごとに必須要件が異なるため、応募先の求人票と照合してください。
SWE・SE・SIer・データ／インフラエンジニアが補うべき力
技術をベースに持つ職種は、既にある強みと補うべきスキルをセットで捉えると移行しやすくなります。
| 出身職種 | 既に持つ強み | 補うべき力 |
|---|---|---|
| SWE | 実装力・技術判断 | 顧客折衝・課題定義・導入推進 |
| SE・SIer | 顧客現場での開発経験 | プロダクト視点・高速プロトタイピング・反復開発 |
| データエンジニア | データ設計・パイプライン | フロントエンド・業務設計・ユーザー接点 |
| インフラエンジニア | クラウド・運用・信頼性 | アプリ実装・データ活用・顧客課題との接続 |
いずれも技術的な下地があるぶん、不足しがちな「顧客・ビジネス理解」と「本番まで運ぶデリバリー」を実績で示せるかが鍵になります。
SES・客先常駐で培った現場対応力や実装力を、FDE向けの経験としてどう整理するかは、SES経験をFDEで活かす方法で詳しく解説しています。
コンサル・PM・PdMが補うべき実装力
課題定義やステークホルダー調整に強い一方、資料作成や要件整理だけでは実装力を示せません。補強すべきは次の点です。
- ゼロから全部書くより、既存コードを理解・修正・検証できること
- API・DB・認証・クラウドを組み合わせた小規模アプリを作る
- AIツールで生成したコードも、自分でテスト・デバッグする
- Git・GitHub・issue・PRなどの開発フローを経験する
- 技術的な制約と実現可能性を自分で判断できる水準を目指す
コンサル経験で活かせる課題設定力・顧客折衝力と、補うべき技術実装力、転職時のポートフォリオの考え方は、コンサルタントからFDEへ移るためのキャリアパスで詳しく解説しています。
現職・個人開発・副業でFDEに近い経験を作る
資格取得だけをロードマップにしないことが重要です。FDEに近い経験は、日常業務や小さなプロジェクトの中で作れます。
- 現職で、要件定義前の顧客ヒアリングへ参加する
- 業務課題を解決する社内ツールを作り、利用者へのヒアリングと改善を繰り返す
- 既存システムやSaaSとAPI連携する
- 小さなAI・自動化プロジェクトを本番運用する
- 導入効果・失敗・改善内容を記録に残す
FDE選考で評価される実績・ポートフォリオの作り方
選考で効くのは「何を作ったか」だけでなく「なぜその課題を選び、どの成果につながったか」です。次の流れを説明できる成果物にしましょう。
- 課題設定 → 要件・制約整理 → 技術選定 → 実装 → テスト・評価 → 利用者のフィードバック → 改善 → 成果と残課題
- GitHubリポジトリだけでなく、設計判断・検証結果・改善履歴を残す
- 顧客・利用者のフィードバックを反映した経験を示す
- AI生成コードを使った場合も、検証・修正・品質担保を自分で行ったことを示す
実際に、AIネイティブ開発を掲げる企業のFDE求人では、応募時にGitHubとポートフォリオの提出や、AI開発ツールを用いた成果物が求められる例があります。単なるチャットボットのデモではなく、上記の一連の流れが確認できる成果物にすることで、求人要件との差を具体的に埋められます。
この時点で、改めて求人票を確認し、自分の不足スキルを再診断すると、次に作るべき実績が明確になります。
本番導入・顧客折衝・生成AIの実装経験が年収にどう影響するか、求人票の報酬をどう読み分けるかは、FDEの年収相場と年収を左右するスキル・実績で詳しく解説しています。
FDE Jounral 編集部自己診断は「勉強した」「知っている」で止めず、応募先の必須要件に関係するスキルを、具体的な成果や担当範囲とともに説明できるかで判断してください。
まとめ：現在地から不足スキルを一つずつ補おう
FDEに必要なのは、技術実装力・顧客ビジネス理解力・デリバリー適応力の3つの軸です。すべてを最初から同じレベルで備える必要はなく、出身職種によって既にある強みは異なります。不足領域は、学習に加えて、成果物の作成や顧客・利用者との接点を通じて補うことが重要です。また、FDEの定義や要件は企業ごとに異なるため、応募先の公式採用ページを必ず確認しましょう。まずは自己診断表で不足スキルを確認し、次にFDEを採用している企業一覧で実際の求人要件を比較してください。現在地を起点に不足スキルを補い、応募先の要件との差を縮めていきましょう。
FDE Jounral 編集部まずは気になる公式求人を1つ選び、「必須要件」「自分で本番コードを書く範囲」「不足しているのは実装側か顧客側か」を確認してみてください。現在地がはっきりすると、次の一歩を選びやすくなります。
関連記事
- FDE（Forward Deployed Engineer）とは？仕事内容・年収・必要スキル・SESとの違いを解説
- パランティアのFDE（FDSE）とは？仕事内容・必要スキル・年収・日本での目指し方
- FDEの年収相場【2026年版】国内求人・外資・海外の水準と上げ方
主な参照先（一次情報）（すべて2026年7月20日確認。求人は改定・募集終了・非公開化の可能性があります）
- OpenAI｜Forward Deployed Engineer – Tokyo 公式採用ページ
- Google Cloud｜Forward Deployed Engineer, Generative AI (Japanese, English) 公式採用ページ
- Palantir Technologies｜Forward Deployed Software Engineer 公式採用ページ（現在公開中の「Japan Forward Deployed」は米国政府関連業務を支援する特殊求人でActive Top Secret Clearance必須。国内の一般的なFDE求人を代表するものではありません）
- 株式会社ジーニー｜【JAPAN AI】Forward Deployed Engineer (FDE) 公式採用ページ
- Sakana AI｜Forward Deployed Engineer 公式採用ページ
- AI Native｜Associate Forward Deployed Engineer 公式採用ページ
- LayerX｜Forward Deployed Engineerの募集を開始しました（公式エンジニアリングブログ）
