FDE CAREER ARTICLE
FDE学習ロードマップ【2026年版】学ぶ順番・実務成果物・90日プラン
FDE（Forward Deployed Engineer）を目指して「Python、RAG、AIエージェント、クラウドを順番に勉強しよう」と考えても、技術項目だけでは仕事の全体像につながりません。FDEの公式求人を見ると、求められているのはコードを書くことに加え、顧客の課題を見つけ、システムを本番へ届け、評価し、利用定着と再利用まで進める力です。
そこで本記事は、学ぶ内容を課題発見→実装→評価→本番運用→利用定着→再利用の順に並べます。各段階で「何を読んだか」ではなく、「何を成果物として残すか」を決めます。
後半の90日プランは、PythonまたはTypeScript、Git、API、データベース、基本的なテストに触れたことがある人が、一つの実務型プロジェクトを作るための例です。90日でFDEになれる、転職できる、年収が上がるという意味ではありません。開発未経験の場合は、基礎学習と第三者が使う開発経験に、より長い期間を確保してください。
この記事の要点
- FDE学習は技術名の一覧ではなく、顧客課題から本番成果までの流れで組み立てる
- 一つのプロジェクトで課題整理シート、コード、構成図、評価、運用手順書、利用者の声、事例資料を作る
- AIやAIエージェントは目的にせず、単純な基準案より価値があると測れた場合に複雑化する
- セキュリティ、評価、可観測性、フォールバックは試作品完成後の飾りではなく、設計初期から扱う
- 90日例は基礎経験者向けの成果物制作プランで、実務経験や採用要件を代替しない
目次
結論：FDE学習は「学ぶ・作る・証明する」で設計する
OpenAI東京のFDE求人は、課題発見、技術範囲の決定、システム設計、構築、本番展開を一気通貫で担当し、利用定着、業務への影響、評価に基づくフィードバックで成功を見ると説明しています。Google Cloud東京のFDE求人も、コード・デバッグ・顧客との共同実装に加え、評価、可観測性、セキュリティ連携、利用定着を挙げています。
したがって、チュートリアルを終えるだけではなく、次の3層を一つのプロジェクトで往復します。
LEARN · BUILD · PROVEFDE学習を成果へ変える3層
HTTP、データ、セキュリティ、LLM、評価など判断に必要な基礎を得る
実在する業務フローを選び、第三者が使える仕組みへ組み込む
テスト、評価、ログ、利用者の声、事例資料で判断と変化を残す
FDEの役割自体を先に理解したい人は「FDEの仕事内容・業務フロー・類似職との違い」を参照してください。本記事は、そこに必要な能力を成果物へ変える順番に集中します。
公式求人から整理するFDE学習の6領域
企業によってFDEの技術・顧客・業界は異なります。次の6領域は全社共通要件ではなく、OpenAI、Google Cloud、Anthropic、Palantirの公開情報に繰り返し現れる責任を、学習成果物へ変換したものです。
| 領域 | 公式情報の要点 | 作る成果物 | 完了条件の例 |
|---|---|---|---|
| 1. 課題発見 | 顧客課題、技術調査、対象範囲、正解が一つではない問題 | 課題整理シート、現行業務フロー、現在値 | 利用者・責任者・制約・成功条件を説明できる |
| 2. ソフトウェア開発 | フルスタック、API、データ、本番コード、デバッグ | アプリ、API、データモデル、テスト、README | 第三者が準備し、主要フローを再現できる |
| 3. AI・データ連携 | RAG、AIエージェント、ツール、構造化／非構造化データ、既存システム接続 | 基準案との比較、検索／ツールの流れ、スキーマ | AIを使う理由と使わない案を比較できる |
| 4. 評価 | 精度、安全性、応答時間、評価、フィードバックの循環 | 評価データ、採点方法、失敗分類、実行記録 | 変更前後を同じ条件で比較できる |
| 5. セキュリティ・運用 | セキュリティ境界、ガバナンス、可観測性、本番展開 | 脅威モデル、権限、ログ、通知、フォールバック、運用手順書 | 失敗を検知し、止め、戻す手順がある |
| 6. 利用定着・再利用 | 顧客との共同開発、利用定着、現場フィードバック、再利用部品 | 利用テスト、研修、事例資料、再利用部品 | 利用結果と次の改善を説明できる |
END-TO-END EVIDENCE一つのプロジェクトで6段階をつなぐ
- DISCOVER利用者、現行業務、現在値、成功条件を定義する
- BUILD小さな業務フローをコードとデータで動かす
- EVALUATE典型・境界・失敗ケースを同じ条件で測る
- OPERATE権限、ログ、通知、フォールバック、ロールバックを備える
- ADOPT第三者に使ってもらい、業務の変化を確認する
- REUSE知見を文書、部品、手順書へ戻す
現在地別：最初に進む3つのルート
同じ90日プランを全員へ当てはめることはできません。すでに持っている証拠によって、最初の重点を変えます。
| 現在地 | すでにある強み | 最初に補うもの | 90日例の扱い |
|---|---|---|---|
| SWE・データ・AIエンジニア | コード、テスト、本番運用、アーキテクチャ | 顧客への聞き取り、業務フロー、現在値、利用定着 | そのまま使いやすい。業務担当者との検証を厚くする |
| SIer・ITコンサルタント・SA・PdM | 顧客理解、要件、推進、業界知識 | 自ら書いたコード、API、テスト、展開、運用 | 実装期間を延ばし、一つの技術構成を深くする |
| プログラミング未経験 | 業務知識や顧客経験がある場合がある | Git、HTTP、プログラミング言語、データベース、テスト、クラウドの基礎 | 90日後の応募を目的にせず、基礎＋隣接実務の中長期プランへ変更 |
FROM TUTORIAL TO EVIDENCE学習完了とFDEの証拠は違う
サンプルデータ、既知の要件、成功する基本経路で技術を学ぶ。
現実の制約を足す
実際の利用者、例外、権限、失敗、運用、フィードバックまで記録する。
Step 0：目標求人と一つの業務課題を選ぶ
先にフレームワークを決めず、興味のあるFDE求人を3件選びます。各求人から「誰の課題」「自分で実装する範囲」「データ」「AI／業界領域」「本番責任」「言語・働き方」を抜き出し、共通部分と企業固有部分を分けます。
次に、自分が利用者へアクセスできる小さな業務課題を一つ選びます。たとえば、問い合わせ分類、文書確認、見積情報の転記、営業会議のフォロー、社内申請の不備確認などです。個人情報や高リスクな判断を含む場合は、匿名化した合成データと人による最終確認を使います。
課題整理シートのテンプレート
- 利用者：誰が実際に使い、誰が結果へ責任を持つか
- 現行業務：今は何を、どの順番で、何分かけているか
- 現在値：件数、時間、エラー、費用、品質の現在値
- 制約：期限、データ、セキュリティ、法務、既存システム、体制
- 成功条件：何がどこまで変われば次段階へ進めるか
- 対象外：今回解かないこと、自動化しない判断
成果物は1〜2ページで十分です。利用者に見せ、間違っている前提を先に直してください。
Step 1：full-stackとdata integrationの基礎を作る
FDE求人は企業により技術構成が違いますが、複数の公開求人でPython、JavaScript／TypeScript、API、クラウド、データ連携、本番品質のコードが挙げられています。すべての言語を触るより、まず一つの技術構成で画面・API・データベースをつなぎます。
- Gitリポジトリ、README、ローカル環境、環境変数を整える
- 入力検証、データベースのスキーマ、API仕様を作る
- 認証と役割ごとの認可を追加する
- 単体／結合テスト、エラー処理、構造化ログを追加する
- 検証環境へ展開し、第三者が主要フローを実行する
OpenAIの本番運用に関するベストプラクティスは、APIキーをコードや公開リポジトリへ置かず、秘密情報の管理機能を使うこと、検証環境と本番環境を分けること、利用上限・費用・応答時間を考えることを説明しています。使用するベンダーにかかわらず、秘密情報をコミットしない習慣を先に作ります。
Step 2：AI・RAG・agentを必要な分だけ加える
AIは成果物の主役ではなく、業務フローを改善する一つの部品です。まずルール、検索、フォーム、通常のプログラムで作る単純な基準案を用意します。そのうえで、LLMを使う案が品質、時間、対応範囲などで改善するか比較します。
Anthropicの「Building effective agents」は、最も単純な解から始め、必要なときだけ複雑性を増やすことを勧めています。手順を固定したワークフローと自律的なAIエージェントを区別し、AIエージェントが費用・応答時間・エラー伝播のトレードオフを持つことも理解します。
成果物に含めるもの
- AIなしの基準案と、AIありの結果を同じデータで比較
- プロンプト、ツールのスキーマ、検索元、モデル設定のバージョン
- 出力スキーマと検証、再試行、時間切れ、手動フォールバック
- ツールごとの認証、最小権限、実行前の人による承認
- 1リクエストあたりのトークン数、費用、応答時間の記録
AIエージェントのフレームワークを使うこと自体を成果とせず、なぜ固定ワークフローでは不足したかを説明できるようにします。
Step 3：evaluationを実装と同時に作る
OpenAIの評価に関するベストプラクティスは、評価を早く・継続的に行い、業務固有のテスト、ログ、自動化、人の判断との調整を勧めています。特定画面の操作ではなく、目的、データセット、指標、比較結果を自分のリポジトリへ残します。
AnthropicのAIエージェント評価に関する解説は、最終回答だけでなく、業務、試行、採点方法、実行記録、環境上の結果を分けています。ツールを使うAIエージェントなら、「完了しました」という発話ではなく、実際にデータベースや外部システムが望む状態になったかを確かめます。
評価シートのテンプレート
- 目的：何ができれば利用者の業務は成功か
- データセット：典型、境界、悪意ある入力、拒否すべきケース
- 指標：正確性、根拠、業務完了率、応答時間、費用、安全性
- 失敗分類：検索、推論、ツール、権限、形式、運用
- 人による確認：誰が何件を確認し、自動採点とどう調整するか
- しきい値：試験導入の開始、停止、ロールバックの条件
成功例だけを集めず、誤入力、情報不足、古い文書、プロンプトインジェクション、権限外の要求、ツール障害を含めます。
Step 4：securityとproduction operationを入れる
Google CloudのAI／MLセキュリティガイドは、事業目標とセキュリティ要件を初期に定義し、入力を信頼できないものとして扱い、展開前後に評価・監視することを推奨しています。セキュリティを最後のチェックリストにせず、課題整理シートの制約へ入れます。
本番準備のテンプレート
- アクセス：利用者、サービス、管理者の認証・権限を分けたか
- データ：保存、暗号化、保存期間、削除、マスキングを決めたか
- 入力：検証、利用上限、プロンプトインジェクション対策があるか
- 可観測性：リクエスト、ツール、品質、応答時間、費用を追えるか
- 障害：時間切れ、モデル／API停止、誤回答時のフォールバックがあるか
- 復旧：ロールバック、障害対応責任者、連絡、再発防止の手順があるか
Google Cloudの生成AIアプリケーション運用ガイドは、プロンプト、処理の連鎖、検索データ等のバージョン管理、CI/CD、監視、継続的な評価を説明しています。モデルだけでなく、システム全体の変更を追跡します。
Step 5：第三者利用とadoptionを検証する
自分だけのデモで終わらせず、想定利用者に使ってもらいます。操作説明をしすぎず、どこで迷うか、どの入力で失敗するか、結果を信頼できるか、元の業務へ戻る場面は何かを観察します。
- 事前に現在の所要時間・error・手戻りを確認する
- 3〜5人など小さな範囲で、実dataを匿名化してpilotする
- 利用ログ、業務完了率、フィードバックを同じ形式で記録する
- 機能追加より、失敗原因と業務フローの不一致を先に直す
- 続行、修正、停止の判断と理由を判断記録へ残す
公式求人でいう利用定着や業務への影響を学習成果へ置き換える段階です。数値が出なかった場合も作らず、「利用者4人中2人が途中で手動処理へ戻った」「入力項目を8から5へ減らした」のような確認事実を記録します。
Step 6：事例資料と再利用できる資産へまとめる
最後に、コードだけでは見えない判断を事例資料へまとめます。OpenAI東京FDEは有効な進め方をツール、手順書、共通部品へ体系化する責任を、Google Cloud FDEは現場の知見を再利用部品や製品フィードバックへ変える責任を挙げています。
事例資料のテンプレート
- 課題：利用者、現行フロー、現在値
- 制約：データ、セキュリティ、時間、システム、体制
- 判断：比較した選択肢と採用理由
- 実装：アーキテクチャ、自分の実装範囲、テスト
- 評価：データセット、指標、失敗、変更前後
- 運用：アクセス、監視、フォールバック、運用手順書
- 成果：利用結果、確認できた変化、限界
- 学び・再利用：次に変えること、共通部品、手順書
顧客名、個人情報、内部コード、秘密のデータは公開しません。公開版と面接用の非公開説明を分け、どちらにも持ち出してはいけない情報を含めないでください。
FDE学習の90日ロードマップ例
次は週8〜12時間程度、基礎開発経験がある人を想定した学習プロジェクトの90日例です。期間より次へ進む条件を優先し、前段階の成果物が成立しなければ延長します。応募候補の選定、経験の棚卸し、求人別の書類調整を進める「転職活動の90日」とは目的が異なります。応募準備の全体像は「FDE転職の判断・応募準備」で確認してください。
| 期間 | 重点 | 主な作業 | 成果物 | 次へ進む条件 |
|---|---|---|---|---|
| 1〜14日 | 対象・課題発見 | 求人3件比較、利用者への聞き取り、現行フロー、現在値、成功条件の定義 | 求人比較表、課題整理シート | 利用者と解く課題・対象外を合意 |
| 15〜35日 | 構築 | UI、API、データベース、認証、テスト、検証環境への展開 | 動くアプリ、README、構成図 | 第三者が主要フローを再現 |
| 36〜50日 | AI・評価 | 基準案との比較、検索／ツール、評価データ、失敗分類 | 評価プログラム、採点結果、実行記録 | 採用案が基準案より改善、または不採用判断を説明 |
| 51〜70日 | 本番準備 | 権限、秘密情報、ログ、監視、通知、フォールバック、ロールバック | 脅威モデル、監視画面、運用手順書 | 主要な障害を検知・復旧できる |
| 71〜83日 | 利用者による試験導入 | 小規模利用、フィードバック、業務フロー修正、利用定着の測定 | 試験導入記録、判断記録 | 続行・修正・停止の判断を事実で説明 |
| 84〜90日 | 事例・再利用 | 結果、限界、学び、再利用部品を整理 | 事例資料、デモ、手順書 | 15分で課題から結果まで説明できる |
1〜14日：作る前に課題を狭める
利用者への聞き取りができない場合は、家族や知人の秘密情報を集めるのではなく、自社で公開できる業務、オープンデータ、架空企業の合成データを使います。技術的に面白いことより、90日で観察できる業務変化を優先します。
15〜35日：LLMなしでも動く骨格を先に作る
画面、API、データベース、権限、テストを作り、AI部品が停止しても最低限の業務が続く構成を考えます。ここでフルスタック開発が難しい場合は機能を減らし、品質を維持します。
36〜50日：AIを足し、同じdataで比較する
正答率だけでなく、業務完了率、根拠、応答時間、費用、人による確認量を測ります。改善しなければAIエージェントを複雑にせず、プロンプト、検索、データ品質、またはAIを使わないフローへ戻します。
51〜70日：失敗を設計へ入れる
API停止、利用上限、ツール障害、権限外の要求、古い文書、誤回答を意図的に起こし、ログ、通知、フォールバック、ロールバックを確認します。公開リポジトリへAPIキーや実データを置かないことも機械的に確認します。
71〜83日：userの利用から改善する
使われない機能を増やさず、迷った画面、誤解した言葉、手動へ戻った理由を直します。モデルの指標と業務指標を分け、利用者が速く・安全に業務を完了できたかを見ます。
84〜90日：結果と限界を公開可能な形へする
成功を誇張せず、失敗と未解決リスクを含めます。公開できるデモ、構成図、評価例、運用手順書の抜粋、事例資料をそろえ、応募先の要件に合わせて説明順を変えます。
最終成果物チェックリスト
| 成果物 | 最低限含める内容 | 公開時の注意 |
|---|---|---|
| 課題整理シート | 利用者、現行フロー、現在値、制約、成功条件、対象外 | 顧客・社員・取引情報を匿名化 |
| リポジトリ・README | 準備方法、構成、テスト、環境、ライセンス、既知の課題 | 秘密情報、内部コード、実データを含めない |
| 構成図・データフロー | 部品、正本、アクセス、外部API、障害時の経路 | 実環境のホスト・ネットワーク詳細を出さない |
| 評価一式 | 目的、データセット、指標、失敗分類、結果 | 個人情報・著作権・機密を確認 |
| 脅威モデル・運用手順書 | リスク、権限、監視、通知、フォールバック、ロールバック、責任者 | 攻撃可能な内部構成を必要以上に公開しない |
| 利用者による試験導入記録 | 対象、手順、フィードバック、変更、続行・停止判断 | 同意なく発言・画面・属性を公開しない |
| 事例資料 | 課題、判断、実装、評価、運用、成果、学び | 自分とチームの担当範囲を分ける |
FREE WORKSHEET
90日工程表を、そのまま使う
記事で解説した6段階を、期間・作業・成果物・次へ進む条件まで記入済みのMarkdown形式で用意しました。期間だけを追わず、各段階の完了条件を確認しながら使えます。
FDE学習 90日工程表Markdown形式・無料↓FDE学習についてよくある質問
FDEになるには何から勉強すればよいですか？
Q
FDEになるには何から勉強すればよいですか？
A
まず応募候補の公式求人を3件選び、自分に不足する証拠を確認します。基礎開発経験がある人は、技術講座を増やす前に一つの業務課題を選び、課題整理シートから実装・評価・運用・利用者による検証まで進めてください。
プログラミング未経験でも90日でFDEを目指せますか？
Q
プログラミング未経験でも90日でFDEを目指せますか？
A
本記事の90日例は基礎開発経験者向けで、未経験からの転職プランではありません。Git、HTTP、プログラミング言語、データベース、テスト、クラウドの基礎を学び、第三者が使うアプリを継続的に改善する経験を先に作る方が、公式求人の実装要件へ近づきます。
PythonとTypeScriptは両方必要ですか？
Q
PythonとTypeScriptは両方必要ですか？
A
求人によります。両方を浅く触るより、まず一つの言語でUI、API、データベース、テスト、展開を最後まで進めます。その後、応募先が求める技術構成と、自分の成果物に必要な範囲で追加してください。
FDEならRAGやAIエージェントは必須ですか？
Q
FDEならRAGやAIエージェントは必須ですか？
A
すべてのFDE求人で必須とは言えません。生成AI系求人では重視されますが、データ、数理最適化、SaaS連携など重心が違う企業もあります。AIエージェントを目的にせず、単純な解決策より業務成果を改善するか評価してください。
個人開発だけでFDEの実務経験になりますか？
Q
個人開発だけでFDEの実務経験になりますか？
A
個人開発は能力の証拠になりますが、採用企業が求める顧客対応や本番実務をそのまま代替しません。第三者の利用、現行業務フロー、セキュリティ、運用、フィードバックを含めると、単独デモより仕事に近い判断を示せます。
成果物に実在顧客の情報を使ってよいですか？
Q
成果物に実在顧客の情報を使ってよいですか？
A
顧客の許可なく社名、コード、データ、画面、契約条件、個人情報を使ってはいけません。匿名化や合成データへ置き換え、公開版にはアーキテクチャの考え方、自分の判断、確認できる結果だけを残してください。
まとめ：一つの課題を、本番と利用まで進める
FDE学習では、Python、RAG、AIエージェント、クラウドと技術を横に増やすだけでなく、一つの顧客課題を課題発見から構築、評価、運用、利用定着、再利用まで進めます。コード、文書、テスト、ログ、利用者の声を一組にすると、技術力と顧客成果を同じ事例で説明できます。
ただし、企業ごとにFDEの要件は異なり、90日の個人プロジェクトが実務経験や採用要件を代替するわけではありません。完成した成果物は「FDEポートフォリオの題材・READMEテンプレート」でケーススタディに変え、応募判断は「FDE転職ガイド」、公開求人は「FDE求人一覧」で確認してください。
参考にした公式情報
- OpenAI「Forward Deployed Engineer – Tokyo」
- OpenAI「Evaluation best practices」
- OpenAI「Production best practices」
- Google Cloud「Forward Deployed Engineer, GenAI（東京）」
- Google Cloud「Deploy and operate generative AI applications」
- Google Cloud「AI and ML perspective: Security」
- Anthropic「Applied AI Engineer, Beneficial Deployments」
- Anthropic「Building effective agents」
- Anthropic「Demystifying evals for AI agents」
- Palantir「Forward Deployed Software Engineer – Japan Government」
この記事をシェアする
