FDE（Forward Deployed Engineer）の求人は、調査時点で日本の勤務地を含む形で複数社が公開中です。
ただし同じ職種名でも、顧客が外部企業か社内の事業部か、担当範囲がPoCまでか本番運用までかは求人ごとに違います。
年収表示や企業の知名度だけで応募先を決めると、顧客訪問や出張、作業場所の制限が想定と食い違うため、先に担当範囲を確かめてください。
この記事では公式求人から読み取れる条件を並べ、応募先を2〜3社へ絞る手順と、書類・面接の準備までを扱います。
FDE求人の比較
FDEの求人は日本にもあります。ただし企業名だけで応募先を決めると、PoCまでなのか、本番運用まで担当するのかを見誤ります。
まず、2026年7月23日に各社の公式採用ページで確認できた内容だけを並べた下の表を見てください。
推定年収や口コミは含めていません。顧客が誰か、どこまで担当するかの2列だけでも、候補は絞れます。
| 企業・職種 | 誰の課題を扱うか | どこまで担当するか | 主な必須経験 | 年収表示 | 働き方・制約 |
|---|---|---|---|---|---|
| OpenAI Tokyo FDE | 外部の戦略顧客 | 安定した本番展開・利用・評価フィードバック | 5年以上、顧客対応、フルスタック、LLM | 記載なし | 週3日出社、国内出張、日英両言語 |
| SB OAI Japan FDE（ソフトバンクからの出向） | 日本企業の外部顧客 | 本番定着・評価・アセット化 | 5年以上、本番コード、クラウド、LLM | 812.3万〜2,034.62万円 | リモート可、顧客訪問・出張あり |
| JDSC FDE | 外部顧客の業務現場 | 本番実装・導入後改善 | 開発2年以上、曖昧な要件から実装 | 500万〜2,500万円 | リモート可、フレックス |
| LayerX FDE | Ai Workforce導入企業 | AIオンボーディング・継続改善 | 公開直前に求人票で確認 | 公開直前に確認 | 常駐等を含むと公式ブログで説明 |
| マネーフォワード Internal FDE | 社内事業部 | PoC・本番化判断まで。実装・運用は別チーム | LLM・RAG等の開発、課題発見から実装、クラウド | 給与例790.8万〜1,500万円 | 原則週2日出社必須 |
| ギブリー FDE | 外部顧客 | 本番運用・監視・改善 | Python 3年以上、開発ライフサイクル、顧客折衝 | 数値レンジ記載なし | リモート可、顧客セキュリティ制約 |
| UPWARD Lead FDE | 自社SaaS導入顧客 | 運用・改善・知見の汎用化 | Python、JS/TS、LLM API、RAG、顧客実装 | 800万〜1,200万円 | ハイブリッド、関東圏は月6日出社奨励 |
外部顧客の本番導入まで担う求人はOpenAI・SB OAI Japan・JDSC・ギブリー
この4社の求人票には、顧客課題の発見や要件整理だけでなく、コードを書いて本番へ出し、その後の改善までが書かれています。
顧客と向き合う職種でありながら、実装責任が明記されている点が共通します。
各社で異なるのは、FDEがどこまで責任を負うかです。
OpenAI Tokyoは、安定した本番利用、業務への測定可能な影響、そして評価にもとづく製品・モデルへのフィードバックを成功の条件に置いています。
ギブリーは本番展開後の監視とデータドリフト対策まで、JDSCは導入後の運用改善までを職務に入れます。
SB OAI Japanはさらに、案件で作った仕組みを別の案件でも使えるテンプレートや部品として整理する業務まで含みます。
顧客先でコードを書き、導入後の利用率や業務改善効果まで確認したい人には、この4社が候補になります。
マネーフォワードのInternal FDEは社内事業部のPoCへ集中する
FDEの顧客は社外の企業だけとは限りません。
マネーフォワードのInternal FDEは社内の事業部を顧客とし、ヒアリング、要件定義、技術選定、PoC、本番化を判断するための評価までを担当します。
プロトタイプのあとの本番実装と運用保守は、別チームが担当します。
この求人でFDEが時間を使うのは、0→1の価値検証です。本番実装を担当しないからFDEではない、という評価にはあたりません。
会社が決めた分担の違いとして読むほうが、求人の比較には役立ちます。
人事・知財・法務のような社内部門の課題を、ヒアリングからPoC、評価指標、引き継ぎまで短い周期で回す仕事と考えると、外部顧客型との違いがはっきりします。
年収が未掲載の求人へ他国・他職種の給与を当てはめない
OpenAI Tokyoとギブリーの求人には、確認時点で比較できる年収レンジの表示がありません。
勤務地や職位の異なる米国求人の給与や、求人媒体の推定額を当てはめると、正確に比較できません。
表では記載なしのまま残すのが正確です。
- 公開ページで確認できないこと：OpenAI Tokyo求人の年収、ギブリーの数値レンジ
- 応募前に確認すること：自分の職位での基本報酬、賞与や手当の扱い、金額が提示される時期
OpenAIの米国求人の金額を為替換算して日本の相場に読み替える例を見かけますが、勤務地も職位も違うため、Tokyo求人の判断には使えません。
空欄は低年収を意味せず、公開ページ上で確認できないという事実を示すだけです。
FDE求人の種類
違いは顧客先へ行くかどうかだけではありません。
求人票の顧客、成果物の引き継ぎ先、共通プロダクトへの反映という3点で読むと、FDEは外部顧客型、社内型、プロダクト導入型に分かれます。
同じ肩書きでも、経歴に残るものが顧客環境で動いたシステムなのか、社内事業の評価結果なのか、製品の標準機能なのかが変わります。
1社の中に複数の型が混ざる場合もあるため、業界や企業規模ではなく求人票の記述で判定してください。
| タイプ | 顧客と成果物 | 知見の反映先 |
|---|---|---|
| 外部顧客型 | 外部企業。顧客環境で動き、業務で使われるシステム | 案件チームと次の顧客案件 |
| 社内型（Internal FDE） | 自社の事業部。PoCと本番化を判断するための評価 | 本番開発を担う別チーム |
| プロダクト導入型 | 自社SaaS・AI基盤の導入企業。接続と利用開始 | 標準機能、接続テンプレート、評価の仕組み |
外部顧客型は技術導入と顧客調整を同じ人が前へ進める
外部顧客型で任されるのは、顧客の業務、データ、セキュリティ制約を理解したうえで、対象範囲を決め、実装し、展開し、業務で使われる状態まで持っていく仕事です。
コードを書くだけでも、提案するだけでも終わりません。
顧客側の利用部門は処理速度、情報システム部門はアカウント権限と接続方式、法務はデータの利用範囲を気にするため、決める相手は案件の途中で増えていくでしょう。
技術デモだけを先に作り、対象業務と評価者を決めないまま進めると、動くものはあるのに利用部門が使い始めないという結果になります。
顧客オフィスへ常に常駐するとは限らず、作業場所は案件とセキュリティ要件で変わります。
採用選考では、会話の量ではなく、誰と何を決めて実装へ反映したかという記録が確認されます。
社内型は事業部を顧客として課題発見と価値検証を高速に回す
社内型のFDEが向き合うのは、自社の業務部門です。
社内で生成AIの活用を推進する部門から相談が集まるため、業務データや担当者へアクセスしやすく、複数のテーマを並行して探索できます。
一方で担当範囲がPoCの評価までに限られ、成果物が本番稼働ではなく本番化を判断するための評価になる場合があります。
マネーフォワードのInternal FDEは、評価が終わった段階で本番チームへ引き継ぐ分担です。
Internalという名称だけで担当範囲を推測せず、引き継ぎの条件と時期を求人票と面接で確認します。
短い周期で多くの0→1を回したい人は社内型、1つの案件を運用まで持ちたい人は外部顧客型が適しています。
プロダクト導入型は顧客固有の実装を共通機能へ戻せるかを見る
プロダクト導入型は、自社SaaSやAI基盤と顧客のデータ・既存システムをつなぎ、業務で使える状態まで仕上げる型です。
UPWARDのLead FDEでは、自社SaaSと顧客システムの統合、AI・データ・運用の設計、導入後の改善に加えて、知見のテンプレート化も職務に含まれます。
LayerXはAi Workforceの導入企業に対し、ユーザーインタビューとログ解析から現場の暗黙知を形にして、AIワークフローやAIエージェントへ実装する動き方を公式ブログで説明しており、外部顧客型の性質も持ちます。
この型で確認したいのは、個別案件で得た知見をテンプレートや標準機能に反映し、次の案件で再利用する仕組みが職務に入っているかどうかです。
反映先が書かれていない求人では、顧客ごとの受託開発が積み上がるだけの働き方になる場合があります。
すべての顧客要望が標準機能へ入るわけではないため、個別対応と共通化を誰が判断するのかは面接で確認します。
個別導入とプロダクト改善の両方を経験したい人に向いています。
FDEの仕事内容
現在のFDE求人に共通する流れは、発見、実装、定着の3段階です。
FDEは、曖昧な業務課題を扱える形まで狭め、AIとソフトウェアで実装し、導入後の利用状況と業務への影響を測るところまで一貫して担当します。
求人ごとに違うのは、この3段階のどこまでを自分が持つかです。
求人票では、3段階のうちどこまでを担当し、その後をどのチームへ引き継ぐのかを確認してください。
発見では業務フロー・利用者・データ・完了条件を決める
FDEは「AIを使いたい」という要望をそのまま実装しません。
先に決めるのは、誰のどの判断を変えるのかという範囲です。
たとえば問い合わせ対応をAI化したいという依頼なら、次の4点まで分解します。
- 利用者：問い合わせを受ける担当者か、全社員か、社外の顧客か
- 業務：どの手順を置き換え、どの判断を人に残すのか
- データ：対象文書の範囲、閲覧権限、更新頻度、持ち出しの可否
- 完了条件：回答できない質問の扱いと、品質を誰がどう評価するか
この4点が決まらないまま実装へ進むと、対象業務が広がり続け、完成したかどうかも測れません。
事業の優先順位はFDEが1人で決めるものではなく、業務責任者やPdM、コンサルタントと一緒に条件を固めます。
ここで決めた利用者、データ、完了条件が、そのまま実装の仕様になります。
実装ではPython・TypeScript・クラウド・LLMを組み合わせる
求人票の必須要件に並ぶのは、PythonやJavaScript・TypeScript、フロントとバックエンド、クラウド、LLM API、RAGやAIエージェントといった技術名です。
ただし採用側は、使用できる技術の多さより、その技術を本番環境へ導入した経験を確認します。
本番で必要になる役割で分けると、業務画面と外部連携を作るアプリ層、検索と生成の品質を決めるデータ・AI層、権限や監視を含む基盤・運用層の3つに分けて考えられます。
ギブリーはPython実装3年以上と要件定義から本番運用までの主体経験、UPWARDはAPI・データ・バックエンドの実装力とLLM API、RAGの実務能力を必須にしています。
AIエージェントの仕組みと生成AIとの違いを押さえたうえで、認証、データ連携、デプロイ、監視までを自分で通した案件があるか職歴を見直してください。
RAGのデモは動いたのに、権限管理とログ、回答の評価がないまま本番へ進めなかった、という止まり方が実務では起こります。
全言語と全クラウドの経験は求められていません。求人ごとの必須と歓迎を分けて読むと、応募できる求人は増えるでしょう。
定着では利用・品質・業務効果を測り、改善か引き渡しかを決める
FDEの担当範囲は、デモの完成で終わるとは限りません。
比較した求人は、継続改善、プロダクトへの反映、別チームへの引き継ぎの3つに分かれます。
OpenAI Tokyoは、本番利用、業務への測定可能な影響、評価にもとづく製品・モデルへのフィードバックを成功の条件に置いています。
ギブリーは監視とデータドリフト対策まで、LayerXは導入後の利用率とデータドリフト、追加要件への継続対応まで扱います。
マネーフォワードは評価までを担当範囲とし、そこから先は本番チームが引き継ぎます。
指標名は案件ごとに変わるため、利用率だけを成功の基準に固定すると判断を誤ります。
回答品質は高いのに使われない場合は、対象業務の選び方、入力画面、業務フロー上の導線、社内への周知まで戻って直す作業が発生する場合があります。
応募先を絞るときは、求人票にproduction、運用、adoption、evaluation、引き継ぎという語がどう書かれているかを確認してください。
FDE求人で求められるスキル
採用側がFDEへ任せたい責任は、大きく3つです。
求人票の必須要件は、この3領域のどこに実績があるかで読み分けられます。
実績がない領域が1つあるだけで応募先は狭まるため、先に自分の職歴を3つへ振り分けてください。
土台は要件定義からデプロイ・運用までのソフトウェア開発経験
FDEで重視されるのは、生成AIツールの利用歴より、本番システムを開発・運用した経験です。
OpenAIとSB OAI Japanは5年以上のエンジニアリングまたは技術導入経験、ギブリーは要件定義から本番運用までを主体的に進めた経験を必須にしています。
確認されるのは、次の5工程のうちどこを自分で担当したかです。
- 要件：曖昧な依頼を、対象業務と完了条件まで落とした
- 設計：データの持ち方、権限、外部連携の方式を決めた
- 実装：自分でコードを書き、レビューと修正まで回した
- 展開：リリース判断、データ移行、利用者への切り替えを担当した
- 監視・改善：障害対応やログ分析を経て、次の修正まで実施した
個人開発も技術力を示せますが、利用者、権限、障害、保守を扱っていない場合は本番経験と同じ扱いになりません。
職務経歴書にAPIを実装と書くより、認証方式の選定、データ移行、監視、リリース判断のどこを担当したかまで書くと、求人の必須要件と対応づけられます。
AI職全体の中でのFDEの位置は、AIエンジニアの仕事内容と必要スキルと読み比べると分かります。
LLM・RAG・エージェントは評価と運用まで説明できることが重要
LLM APIやRAGを使った経験だけでは、本番運用や品質評価に関する要件を満たしにくいでしょう。
採用側が聞くのは、業務で使える条件をどう設計したかです。
扱うデータの範囲と権限、品質を測る指標、誤答したときに返す内容、コストと応答時間の上限、運用開始後に監視する項目を説明できるかどうかで評価が変わります。
検索の精度だけを示し、回答できない質問の扱いや利用者からの評価を説明できない場合、採用側はその内容だけで本番運用まで任せられると判断しにくくなります。
求人によっては、RAGやAIエージェントの実装が歓迎要件にとどまる場合もあります。
実務経験がない場合は職歴を作らず、自分で開発した成果物に評価と運用の記録を足します。
モデルを使ったという説明を、業務で使える条件を決めたという説明へ書き換えられるかどうかが、選考での差になります。
顧客対応力は会話量ではなく、曖昧な要望を技術判断へ変えた実績で示す
求人が求める顧客対応は、説明のうまさではありません。
利害の違う関係者から条件を集め、範囲、優先順位、品質、期限の取捨選択を合意し、実装へ反映した経験が確認されます。
社内文書を検索するAIを作る場面では、利用部門は応答の速さ、情報システム部門はアカウント権限と接続方式、法務は学習や外部送信の可否を優先します。
FDEはこの3者の懸念を、対象文書の範囲、権限の設計、ログの保存期間といった技術条件へ翻訳し、初期リリースの範囲を決めます。
顧客折衝の経験があっても実装から数年離れている場合は、実装力を示せるコードや設計資料を別途用意してください。
開発経験が長く、要件を決める場に出た回数が少ない人は、社内の業務部門を相手にした案件でこの経験を積めるでしょう。
SIerやITコンサル、プリセールスからの移行では、誰の懸念をどの技術条件へ変えたかを1件でも説明できるかが評価に影響します。
未経験からFDEを目指す方法
JDSCの求人は、FDEやAIプロジェクトの経験を不問としながら、開発経験2年以上を必須にしています。
OpenAIとSB OAI Japanは5年以上の経験を求めるため、比較した求人の中心は中途の実務経験者です。
FDE経験不問という記載を、開発実務も不問と読み替えないでください。
職業経験がない状態からの直接応募を一般的な経路として勧める根拠は、確認した求人の中にありません。隣接する職種で1〜2段階の経験を積む道筋から考えます。
FDE経験がなくても、開発と曖昧な要件を実装へ変えた経験は必要
JDSCは、FDEやAIプロジェクトの経験、学歴、特定の資格を不問としています。
求めているのは、開発経験2年以上と、要件が固まっていない状態から関係者と課題を決めて実装した経験です。
確認されるのは、FDEと担当範囲が近い案件を経験しているかどうかです。
たとえば受託のWeb開発で、顧客の要望を仕様へ落とし、リリース後の問い合わせを見て直した案件があれば、応募時に示せる実績になります。
社内システムの担当者でも、利用部門へヒアリングして範囲を決めた案件は同じ扱いで書けます。
ただし応募資格を満たすことと採用されることは別で、選考基準は企業ごとに違います。
まず職歴から、要件が曖昧だった案件を2件書き出してください。
Web・SIer・コンサル・プリセールス出身者は不足する1領域を補う
出身職種によって、持ち込める経験と不足しやすい経験は変わります。
下の表は求人の共通要件から作った自己点検用の仮説で、出身別の適否を決めるものではありません。
| 出身 | 持ち込みやすい経験 | 次に用意したい実績 |
|---|---|---|
| Webエンジニア | 本番運用、リリース、障害対応 | 業務部門や顧客と範囲を決めた案件、AIの品質評価 |
| SIer | 要件定義、関係者調整、既存システム連携 | 自分でコードを書いた短期の検証、LLM実装 |
| ITコンサルタント | 課題の分解、業務設計、意思決定の支援 | 本番のコードとデプロイ、監視の担当実績 |
| プリセールス・ソリューションアーキテクト | 技術提案、顧客の制約理解 | 導入後の実装と運用まで持った案件 |
同じ職種名でも担当範囲は違うため、すでに経験がある欄は埋める必要がありません。
次の案件、社内の異動希望、個人開発のうちどれで補うかをまず1つに絞ると、次の案件で何を経験すべきか決めやすくなります。
不足を1領域に絞れた人は、その領域を求める求人から逆算して応募時期を決められるでしょう。
資格やスクールはAI実装の不足を補えても、顧客導入の実務を代替しない
JDSCは特定の資格を不問としており、比較した求人からFDEに共通して求められる資格は確認できません。
資格の取得より、求人要件に対応する成果物を作るほうが選考では効きます。
学習サービスが埋めやすいのはPython、LLM、AIアプリの実装で、顧客との合意形成や本番運用の実績は受講だけでは残りません。
ソフトウェア開発の経験があり、AI実装の成果物だけが足りない人には、AIカレッジのようにPythonやLLM、AIチャットボット、Claude Codeを扱う学習サービスで成果物を作る進め方が向いています。複数社を比べたい場合は生成AIスクールの学習内容を比較すると、扱う技術の範囲が分かります。
開発の実務そのものがない場合は、FDEへ直接応募する前に本番開発を担当できる職種から入るほうが確実です。
受講した場合も、成果物には想定利用者、扱うデータ、評価の方法、うまくいかなかった条件を添えます。
FDE求人の年収と働き方
金額を公開している求人は4件です。
4件は職位や報酬構成、責任範囲が異なるため、単純平均を出しても参考になりません。
下の表では、金額と同じ行にある条件まで一緒に確認してください。
| 企業・職種 | 公開されている金額 | 金額に付く条件 |
|---|---|---|
| JDSC FDE | 年収500万〜2,500万円 | 正社員、リモート可、フレックス。幅が広く、経験別の内訳は非公開 |
| SB OAI Japan FDE | 月給52万3,750〜99万9,000円／想定理論年収812万3,000〜2,034万6,200円 | 年収は賞与と特別加算賞与を含む。月給は勤務実績に応じた時間外手当を含む前提 |
| マネーフォワード Internal FDE | 給与例 年額790万8,000〜1,500万円 | 固定手当の内訳を併記した給与例。全員に適用される確定レンジではない |
| UPWARD Lead FDE | 年収800万〜1,200万円 | 月45時間分のみなし残業を含む |
OpenAI Tokyoとギブリーは、確認時点で比較できる数値レンジを載せていません。空欄をゼロや低年収と読まず、面談で確認する項目として扱います。
年収レンジの幅は職位・賞与・固定手当を分けて比べる
同じ年収という言葉でも、基本報酬、給与例、賞与を含む想定理論年収、固定残業込みのレンジは同じ尺度ではありません。
たとえば1,200万円という上限が2社に並んでいても、片方は固定残業45時間分を含み、もう片方は賞与を前提にしている場合、同じ働き方で同じ額にはなりません。
上限額より、自分の職位で提示される部分を分けて確認します。
- 基本報酬：毎月固定で受け取る額と、そこに含まれる手当
- 変動報酬：賞与の算定方法、支給回数、評価との関係
- 時間外手当：固定分の有無と時間数、超過分の扱い
- 評価時期：入社後いつ見直され、レンジ内でどう動くか
上限額へ到達する経験条件は公開されていない場合が多く、求人票から職位表を推測すると判断を誤ります。
オファー面談では、この4項目をそのまま質問項目として使えます。
「リモート可」でも出社・出張・作業場所・端末の制約は残る
FDEは顧客のデータと環境を扱うため、リモート可という記載があっても働く場所が完全に自由になるとは限りません。
OpenAI Tokyoは週3日出社のハイブリッドで、主に国内の出張があります。
マネーフォワードは原則週2日の出社を必須とし、週3日以上を推奨しています。
SB OAI Japanはリモート可としながら、顧客訪問と主に国内の出張、そして米国出張の可能性を挙げています。
ギブリーの求人では、顧客のセキュリティ要件によって作業する地域、ネットワーク、端末の扱いが制限されます。
海外からのリモート勤務を希望する場合は、案件ごとの作業地域や端末の制限を確認する必要があります。
面接では、週の出社日数、顧客訪問の頻度、出張の範囲、作業できる地域、貸与端末とネットワークの5点を、担当予定の案件を前提に質問します。案件ごとの例外がどれくらいあるかまで聞けると、入社後の生活の見通しが立てやすくなるでしょう。
FDE求人の選び方
企業名や提示年収より先に確認するのは、次の5点です。
譲れない条件に合わない求人は、この段階で候補から除外します。
求人票に書かれていない項目は0点にせず、面接確認として残してください。記載がないことは、条件がないという意味ではありません。
- 顧客は外部企業か、社内の事業部か
- 担当範囲はPoCと評価までか、本番展開と利用定着、継続改善までか
- コード、アーキテクチャ、デプロイ、監視のどこまでを自分が持つか
- 顧客訪問、出張、出社日、作業場所と端末の制約は何か
- 案件で得た知見を、共通プロダクト、テンプレート、別チームのどこへ引き継ぐか
PoC型・本番型・プロダクト型のどこへ責任を持ちたいか決める
5点のうち、答えが最も分かれるのは担当範囲と知見の引き継ぎ先です。
短い周期で複数の0→1を回し、社内の複数部門の課題に触れたい人にはPoC型が適しています。
1つの案件を利用定着まで持ち、稼働後の数字で判断したい人は本番型で、求人票のproductionやadoptionという記載を確認します。
個別の導入と共通機能の両方に関わりたい人はプロダクト型で、テンプレート化や標準機能への反映が職務に書かれているかを確認します。
PoCが浅く、運用が上位という関係ではありません。触れる案件数と、1件に対する責任の深さのどちらを取るかという違いです。
企業内の分業で担当範囲は変わるため、職種名だけで決めず、前半の3タイプへ戻って候補企業を絞ってください。
FDE以外にFDSE・Forward Deployed AI・AI Deploymentも検索する
職種名は企業ごとに違います。
PalantirはForward Deployed Software Engineerという名称を使っており、FDEの完全一致だけで検索すると、担当範囲が近い求人を取りこぼします。
検索語は、Forward Deployed Engineer Japan、FDSE Japan、Forward Deployed AI Engineer、AI Deployment Engineer、生成AI 導入 エンジニア 本番の5つから試すと範囲が広がります。
名称が似ていても、実態が営業やプリセールス中心のポジションもあります。
最終的な判定は、公式採用ページに書かれた顧客と担当範囲で行います。
面接では求人票にない引き渡し先と案件制約を質問する
求人票を読んでも分からない項目は、面接で確認します。
次の4問は、入社後の仕事量とキャリアに直接影響します。
1つ目は引き継ぎについて、「PoCが本番化される場合、FDEはどの時点まで責任を持ち、誰へ渡しますか」と質問します。
2つ目は顧客接点で、「直近の案件では、顧客訪問と社内作業の比率はどれくらいでしたか」と聞きます。
3つ目は勤務制約について、「顧客のセキュリティ要件で作業場所や端末が限られる案件は、全体のどの程度ありますか」と確認します。
4つ目は共通化で、「個別に作った機能を標準機能へ入れるかどうかは、誰がどの基準で決めますか」と質問します。
機密案件の詳細を求める必要はなく、標準的な分担と直近の匿名の例を聞ければ十分です。
FDE求人への応募準備
Python、RAG、AWSを並べても、FDEの担当範囲は伝わりません。
評価されやすいのは、課題、制約、実装内容、導入結果、改善点を一貫して説明できる案件です。
担当していない工程は隠さず、誰へどの条件で引き継いだかまで書きます。
顧客名や内部構成に守秘義務がある場合は匿名化し、チームの成果と自分が決めたことを分けて書いてください。
ポートフォリオは課題・利用者・データ・実装・評価・改善を1枚にする
成果物は、動くデモだけでは足りません。
なぜその課題を選び、誰が使い、どのデータと制約を扱い、失敗をどう測り、次に何を直したかまでを1枚にまとめます。
社内規程を検索するAIを題材にすると、6項目は次のように埋まります。
- 課題：規程の該当箇所を探すのに時間がかかり、担当者へ同じ質問が集まる
- 利用者：総務の担当者と、規程を確認する一般社員（実ユーザーがいない場合は想定利用者と明記）
- 制約・データ：対象は公開規程のみ、閲覧権限のある文書と、権限のない文書を分ける
- 自分の判断と実装：検索方式の選定理由、回答できない質問の返し方、ログの取り方
- 評価：自分が用意した質問セットでの正誤と、誤答の分類
- 改善・引き継ぎ：直した点と、次に手を付ける候補、他者へ渡すときの前提
数字は自分で測ったものだけを載せ、利用者数や削減時間は作りません。
数人でも許可を得て使ってもらい、実際の利用者の反応を記録できれば、ポートフォリオの説得力が増します。
職務経歴書は担当作業より「自分が決めたこと」と結果を書く
要件定義を担当という書き方では、判断の中身が伝わりません。
代表案件は、曖昧だった条件、比べた案、自分が決めた範囲、実装、結果の順に3〜5行で書き直します。
たとえばRAG開発を担当という1行は、規程文書の権限制約を要件へ落とし、検索と回答の評価を実装し、本番化の判断に必要な誤答分類を提出した、という形まで具体化できます。
ここまで書いてあれば、面接で判断の理由を掘り下げられても答えられます。
定量的な結果がない場合は作らず、リリースした範囲、使い始めた部門、評価が完了した状態、引き継いだ相手といった確認できる事実を書きます。
チームで出した成果と、自分が決めたことは行を分けると誤解が起きにくくなるでしょう。
面接はシステム設計・ケース・日英対応を企業別に準備する
選考で確認される形式は企業ごとに違うため、推測の質問集を集める必要はありません。
公式求人に書かれている形式だけを見ると、準備の方向は次のように分かれます。
| 企業 | 公式に確認できる選考 | 準備する内容 |
|---|---|---|
| SB OAI Japan FDE | 面接内のシステムデザイン、ケーススタディ | 代表案件の構成図、技術選択の理由と採用しなかった案 |
| OpenAI Tokyo FDE | 英文履歴書、日本語と英語の両方での面接 | 同じ案件を英語で2分説明する原稿 |
| マネーフォワード Internal FDE | 技術課題が含まれる可能性 | PoCから本番化判断までの評価設計の説明 |
準備する案件は増やさず、1件を技術設計、顧客との範囲決め、英語説明の3つの形へ言い換えます。
選考内容は変わる場合があるため、応募時に各社の求人ページで最新の記載を確認してください。
FDE求人に関するよくある質問
ここでは語学、雇用形態、客先常駐の3点だけを短く扱います。
未経験可否、年収、リモートの条件は本文で回答済みのため、繰り返しません。
- FDEに英語は必須ですか？
-
全求人で必須ではありません。OpenAI Tokyoは日本語と英語のバイリンガルを必須とし、英文履歴書と両言語での面接を求めます。SB OAI Japanは日本語が必須で英語は歓迎、マネーフォワードのInternal FDEは入社時の英語力を不問としています。英語不問の求人でも技術文書が英語である場合は多く、読める状態にしておくと応募できる求人が増えます。
- FDEの業務委託求人もありますか？
-
検索では業務委託の需要が見られますが、この記事で公式確認した代表求人はいずれも正社員です。業務委託の案件を探す場合も、契約名ではなく、課題発見、実装、本番運用のどこまでが契約上の責任かを確認します。月単価だけで決めると、本番障害の対応や顧客先での稼働が含まれていた場合に想定と合わなくなります。稼働時間、期間、成果物の定義、端末と作業場所を先に質問してください。
- FDEはSESや客先常駐と同じですか？
-
顧客先で働くという点が重なる案件はあります。ただし現行のFDE求人には、課題の特定、技術範囲の決定、実装、導入後の成果までを責任として書いている例があります。同じ顧客オフィスでの勤務でも、受け取った仕様を実装する役割と、範囲の決定と評価まで担当する役割は別です。勤務場所ではなく、成果責任とプロダクトへの反映の有無で見分けます。
まとめ｜FDE求人を選ぶポイント
1つの案件を本番と定着まで持ちたい人は外部顧客型、短い周期で複数の0→1に集中したい人はInternal型、個別の導入を共通製品へ反映したい人はプロダクト導入型が適しています。
どの型でも、求人票から読み取るのは顧客、担当範囲、コードの範囲、勤務制約、知見の引き継ぎ先の5点です。
金額の上限が高い求人でも、譲れない条件に合わなければ候補から外します。
開発の実務がない場合は、まず本番開発の経験を積むほうが、FDEに必要な実績を身につけやすくなります。
応募準備は、求人の比較、不足経験の特定、代表案件の整理の順で進めます。
- 公開中の求人を5点で採点し、応募候補と面接で確認する候補に分ける
- 本番開発、AI実装と評価、顧客との条件決めのうち、不足している1領域を決める
- 代表案件を1件選び、課題から評価までを1枚のケースシートにまとめる
3つが終わった時点で、応募先ごとに書類を書き分ける作業へ入れます。
