AI業界で今いちばんホットな「FDE」を深掘りしたら、影もくっきり見えて、それが僕にも刺さった話

開発# FDE # Forward Deployed Engineer # AI開発 # Claude Code # Codex # 受託開発 # SES # 技術的負債 # Palantir

冨田希望

公開日:2026/06/03

読了目安:約18分

最近、エンジニア界隈で「FDE」という言葉をやたら見かけるようになりました。Forward Deployed Engineer、日本語だとフォワードデプロイドエンジニア。OpenAIもAnthropicもPalantirも、こぞって募集している職種です。

僕らは普段、Claude CodeやCodexを相棒にしながら、フロントもバックも書くエンジニアです。画面まわりもサーバーサイドも触るし、DBやインフラもいじる。React/Next.jsとか特定の言語・フレームワークに縛られず、案件に合わせていろんな言語・いろんなアプリを触っています。働き方も雑食で、SESで客先の現場に入ることもあれば、自社サービスを開発することもあるし、自分たちで考えて作る個人開発みたいなこともやっている。そんなエンジニア集団です。

そういう立場から見ると、この「FDE」という職種、正直けっこう刺さるものがありました。「あれ、これって僕らがやってる（あるいはやりたい）ことの延長線上にあるのでは？」と。

一方で、調べていくと「いや、これ手放しで持ち上げると危ないやつだぞ」という影の部分もはっきり見えてきました。しかもこの影——あとで「システムが腐る」という話で詳しく書きます——は、よく読むとFDEだけの問題じゃないんですよね。SESで入った現場でも、自社サービスの開発でも、AIを使って一人でガリガリ作っているときでも、まったく同じことが起きうる。むしろ今は、誰にとっても起きやすくなっている。だからこの記事は、FDEという職種の紹介であると同時に、AIで開発している僕ら全員に刺さる話でもあるな、と思いながら書きました。

なのでこの記事では、

そもそもFDEって何なのか、何が特徴なのか
コンサルとは何が違うのか
SESとは何が違うのか
受託開発とは何が違うのか
FDEの強みと、気をつけたほうがいい危険性

このあたりを、できるだけ出典を示しながら、僕ら開発者の目線で整理してみます。ちょっと長いですが、保存版のつもりで書きました。

まず数字から：求人が「5,230%増」という異常事態

最初に、なぜこんなに騒がれているのかを数字で見ておきます。

Business Insiderが求人サイトIndeedのデータとして報じたところによると、FDEの求人数は2025年1月比で、2026年4月時点で 5,230%増 になっているそうです。実数で言うと、2025年4月の643件から、2026年4月には5,300件超。前年同月比でも約729%という伸びです。採用しているのはAnthropic、OpenAI、Palantir、Stripeといった、いわゆる最前線の企業たち。

FDE求人が2025年4月の643件から2026年4月の5,300件超へ伸びたことを示す図解

ベンチャーキャピタルのa16z（Andreessen Horowitz）も、FDEを「スタートアップでいま最もホットな職種」と評していて、2025年に求人が前年比800%伸びたと表現しています。SalesforceにいたってはFDEを1,000人規模で採用するとコミットしているという話まである。

数字を見ているだけだと「ふーん、バブルっぽいな」で終わりそうですが、増えている理由がちゃんとあるので、そこを掘っていきます。

そもそもFDEって何？

ざっくり一言で言うと、FDEは

顧客の現場に入り込んで、AIプロダクトを「実際の業務で動くシステム」になるところまで持っていくエンジニア

です。

名前を分解すると分かりやすいです。Forward（前方＝顧客の最前線）にDeployed（配置された）Engineer。つまり「自社の開発部屋にこもるんじゃなくて、顧客の現場に前のめりで配置されるエンジニア」という意味になります。

仕事の範囲がとにかく広い。単なる実装担当ではなくて、業務理解 → 要件整理 → プロトタイプ → API連携 → LLMの評価 → 本番導入 → 運用改善 → そして自社プロダクトへのフィードバックまで、ぜんぶ見る。OpenAIのFDE求人でも、discovery（発見）、technical scoping（技術的な範囲決め）、system design、build、production rollout（本番展開）まで担う職種だと明記されています。「相談に乗って終わり」ではなく、「作って本番に出すところまで」が仕事なんですね。

発祥はPalantir

この職種、もともとはデータ解析企業のPalantirで有名になりました。

時代は2000年代初頭。Palantirは、CIAやFBI、軍といった政府機関にソフトウェアを納めようとしていました。ところがこの手の顧客は、データの形式が部署ごとにバラバラで、アクセス権限が複雑に絡み合っていて、しかも現場の要件が日々変わる。「本社で汎用ダッシュボードを1個作って全機関に一斉に売る」という普通のSaaSモデルでは、まったく歯が立たなかったわけです。

そこでPalantirは発想を逆転させました。「多くの顧客のために1つの機能を作る」のではなく、「1人の顧客のために無数の機能を作る」。そのために、セキュリティクリアランスを事前に通したフルスタックエンジニアを顧客の現場に直接送り込んで、横に座ってコードを書かせた。これがFDEの原型です。

Palantirの元幹部Bob McGrewは、この役割を道路建設にたとえています。

FDEは顧客先で泥にまみれながら、製品がどこへ向かうべきかを示す「砂利道」を切り拓く。本社のコアエンジニアはその砂利道を受け取って、次の10社以上が快適に使えるよう「舗装された高速道路」に変える。

この「砂利道と高速道路」の比喩、あとでめちゃくちゃ効いてくるので覚えておいてください。FDEが腐るか腐らないかは、ほぼここに集約されます。

比喩でイメージすると

FDEを説明するとき、僕が一番しっくりきたのは「シェフ」のたとえでした。

普通の料理人は、自分の店の厨房で料理を作って待っています。でもFDEは違う。顧客の家の、散らかったキッチンに直接乗り込んでいって、冷蔵庫の残り物でその場で三ツ星のフルコースを作り上げる。しかも料理を出すだけじゃなくて、ついでにそのキッチンの動線を作り直して、次に誰が入っても効率よく料理できるようにシステム化までやってのける。

ちょっと大げさですが、要するに「現場の混沌に飛び込んで、AIを実際に使えるものにする人」という感じです。

なぜ今こんなに騒がれてるの？

理由はシンプルで、 AIはPoC（試作）までは天国、本番導入は地獄 だからです。

ChatGPTのAPIを叩いて社内文書を読ませる賢いチャットボットのデモを作るのは、今や週末で終わります。僕らもそうですが、Claude CodeやCodexを使えば、デモレベルなら本当にあっという間。PoCのハードルは劇的に下がりました。

ところが、その「おもちゃみたいなデモ」を、セキュリティが厳重で何千人も使う企業の本番環境に乗せようとした瞬間、地獄が始まります。

社内データがあちこちに散らばっている
文書の権限管理がやたら複雑
AIが間違えたときに誰が責任を持つのか曖昧
ログをどう残すか誰も決めていない
既存の基幹システムとつなぐ必要がある
現場が本当に使うUIになっていない
評価データ（eval）がそもそも無い
経営層は効果を数字で見せろと言ってくる

この「最後の1マイル」を歩ける人が、決定的に足りていない。ここがFDE急増の正体です。

PoCから本番導入へ進む途中に権限、ログ、評価、既存システム、責任の壁が立つ図解

「統合の壁」と、AIには越えられない壁

この本番導入の難しさは「統合の壁（Integration Wall）」と呼ばれたりします。F1の超高性能エンジンを買ったはいいけど、20年前のボロいミニバンに載せようとしている、しかもそのミニバンは時速100キロで高速を走っていて車内では子どもが泣いている——みたいな状態です。業務は止められないですからね。

で、ここで「じゃあAIにシステム統合のコードも書かせればいいじゃん」と思うわけですが、ここが面白いところで、AI導入を阻む最大の壁は技術じゃないんですよ。 現場の非合理なローカルルールと、人間模様 なんです。

僕が一番ゾッとした具体例を紹介します。社内の文書やデータを検索して、その中身をもとにAIが答えてくれるしくみ（RAGと呼ばれます）を作ったとします。ユーザーがそのAIに「今月の売上いくら？」と聞いた。

営業部のExcelの「売上」には、まだ確定していない見込み客の数字が含まれている
経理部のシステムの「売上」は、銀行に着金した金額だけ

同じ「売上」という単語なのに、部署によって定義がまったく違う。そして「なぜ部署ごとに数字の持ち方が違うのか」という社内政治と歴史的経緯は、AIには絶対に理解できない。AIは論理的すぎて、人間の非論理的な矛盾を扱えないんです。

だからFDEが要る。営業部長と経理部長の両方とコーヒーでも飲みながら話を聞いて、「営業部から質問されたらAのDBを参照、経理部からならBを参照」というルーティングのコードを、その場で泥臭く書く。FDEはAIの通訳じゃなくて、現場の混沌をアーキテクチャに落とし込む意思決定者なんですね。

これ、僕らも身に覚えがあります。技術的には一瞬で書けるルーティングなのに、「そもそも何が正解なのか」を現場で聞き出さないと書けない。コードを書く力より、聞き出す力のほうがボトルネックになる、という構造です。

コンサル・SES・受託と並べると、FDEの輪郭が見えてくる

FDEは「顧客先に行くエンジニア」なので、コンサルやSESや受託開発と、見た目はけっこう似ています。なので「FDEって結局どういう存在なの？」というのは、隣にいる馴染みのある職種と並べてみると一番イメージしやすい。違いをあげつらうというより、輪郭をはっきりさせるために並べてみます。

ざっくり言うと、FDEは「本番導入とプロダクトへの知見還流」まで背負う役割です。コンサルは提案や意思決定支援、SESは工数とタスク消化、受託は仕様通りに納品することが中心になりやすい。ここを分けて見ると、FDEの輪郭がかなりはっきりします。

ひとつずつ補足します。

コンサルとの違い：手を動かして本番に出す

一番大きいのは、 FDEは自分でコードを書いて本番導入まで持っていく という点です。

コンサルの最終成果物は、課題整理・戦略・ロードマップ・提案書になりがちです。もちろん技術に強いコンサルもいますが、それでも「AI活用ロードマップを作りました」で終わることが多い。

FDEはそこが違って、「社内データを参照するAIエージェントを作って、権限管理を入れて、本番で営業50人が使い始めました」という世界まで持っていく。Google CloudのFDE求人でも、従来の助言役（advisory role）とは違って、コードを書き、デバッグし、顧客環境で一緒に出荷する役割だと明記されています。会話力や業務理解力はコンサル的なんだけど、最後は手を動かして価値を証明する。そこがコンサルとの分かれ目です。

SESとの違い：工数を売るか、成果にコミットするか

これは日本だと特にややこしい。「顧客先に常駐するエンジニア」という見た目がSESとそっくりだからです。

でも本質は逆です。SESは多くの場合、顧客や元請けが決めた要件・設計・工程の中で、アサインされた作業を担当します。責任範囲は契約とタスクに紐づく。評価されるのは基本的に稼働時間です。

FDEは、もっと上流から入って「そもそも何を作るべきか」を自分で探索します。そして自社のAIプロダクトを使って、顧客の業務成果に直結するものを作る。OpenAIの求人でも、FDEの成功指標は「production adoption（本番利用）」「measurable workflow impact（測定可能な業務インパクト）」「プロダクトとモデルのロードマップを変えるeval駆動のフィードバック」だとされていて、稼働時間やタスク消化では測られていません。

一言で言うなら、

SESは「顧客の開発リソースとして入る」。FDEは「自社プロダクトを顧客現場で成功させる責任者として入る」。

ここはあとで触れる「危険性」とも直結します。FDEは、運用を間違えると簡単に「高単価なSES」に堕ちる。見た目が似ているからこそ、本質を取り違えると一瞬でそうなります。

受託開発との違い：1社に納品か、100社に効く知見を掘るか

受託開発は、顧客に依頼されたシステムを作って納品するモデルです。要件定義→設計→実装→テスト→納品→保守、という流れ。

FDEも作る点は似ているんですが、決定的に違うのは 自社プロダクトの導入・進化とセットになっている ことです。OpenAIやAnthropicのFDEは、顧客ごとにAIシステムを作るだけじゃなくて、そこで得た知見をモデル・API・評価基盤・セキュリティ設計に戻す役割を持っています。Anthropicの求人にも「反復可能な導入パターンを特定・体系化して、Product/Engineeringチームに還元する」とはっきり書いてある。

つまりFDEは、

「1社専用に作って終わり」ではなく、「1社の現場から、100社に展開できるプロダクト知見を掘り出す」

という動き方をする。さっきの「砂利道→高速道路」がこれです。受託は砂利道を1本作って終わり。FDEはその砂利道を高速道路に昇華させる前提で動く。逆に言うと、この還流をサボった瞬間、FDEはただの受託開発と区別がつかなくなります。

FDEの強み

ここまでで特徴は見えてきたので、改めて強みを整理します。

ビジネス×技術の「二刀流」

FDEに求められるのは「AIに詳しい」だけじゃ全然足りません。むしろ大事なのは、

業務を聞く力
業務をデータ構造に変換する力
小さく作って試す力
本番運用を壊さない設計力
現場の反応を見て改善する力
自社プロダクトに戻せる抽象化力

このあたり。Business（ビジネス）・Technology（技術）・Creativity（体験設計）を高いレベルで掛け算する「BTCスキルセット」と呼ばれたりします。デザインファームのGoodpatchは、特にCreativity——「困っていますか？」と聞くだけでは出てこない本質的な課題を、観察やリサーチで掘り当てる力——がAI時代のFDEの差別化要因になると分析しています。

AIで弱点を補完して、一人で何人分も働く

「そんなのスーパーマンじゃん、数ヶ月で燃え尽きるだろ」と思いますよね。僕も思いました。

ここで効いてくるのが、まさに僕らがやっている「AIを相棒にする」働き方です。FDEは自分の弱点をAIで補完する。顧客とのヒアリングは得意だけどバックエンドの実装が遅い人は、現場で話を聞きながら裏でAIにコードの8割を書かせる。逆にゴリゴリのプログラマーだけどドキュメントや会議が苦手な人は、議事録やクライアント向けメールをAIに書かせる。

つまりAIを「もう一人の自分」として使い倒して、疑似的にスーパーマンを作り出している。一人で何十人分もの価値を出すからこそ、後で出てくるような高い報酬が成立するわけです。

正直、ここは僕らの実感ともよく合います。Claude CodeとCodexがいる前提だと、一人のエンジニアがカバーできる範囲は明らかに広がった。FDEという職種が今このタイミングで爆発しているのは、AIコーディングが「広く浅く全部やる」を現実的にしたから、という側面が確実にあると思います。

現場で価値を即証明できる

経営層は標準的なデモでは動きません。「実際のうちのデータで、本当に効果が出るのか」を見たい。FDEは現場の本物のデータで動くプロトタイプを数日で作って見せられるので、意思決定が速い。FDEモデルを入れたプロジェクトでは、価値提供までの時間（Time-to-Value）が数ヶ月から数週間に縮んだ、という報告もあります。本社との伝言ゲームを挟まず、その場で直すからです。

でも、ここは気をつけたい（危険性・落とし穴）

ここからが、僕が一番ちゃんと書きたかったところです。FDEは華やかですが、影もはっきりある。手放しで「最高の職種！」と煽るのは誠実じゃないと思うので、踏み込みます。

トップエンジニアからの辛辣な批判

まず、元Snowflake CROのChris Degnanの批判。彼は20VCというポッドキャストで、FDEを

「glorified professional services person（持ち上げられただけのプロフェッショナルサービス要員）」

と言い切りました。さらにこう続けます。

「もし本当に優秀なエンジニアなら、FDEになんてなりたくない。コアプロダクトで働きたいはずだ」

そして、FDEが顧客ごとに作る一時的な解決策には「大量の技術的負債とリスクが残る」と警告しています。

これ、けっこう刺さる指摘です。FDEが失敗すると、ただの「高単価SES」や「AI導入なんでも屋」になる。顧客ごとにバラバラな実装を量産して、保守不能なAIツールを撒き散らす危険があるわけです。

システムが「腐る」とはどういうことか

この危険を一言で表すのが「腐る」という言葉です。 最初は速く動くのに、あとから変更・保守・拡張・説明・引き継ぎができなくなる状態 のこと。

イメージしやすい流れで言うと、まず最初はこうです。

「すごい、もう動いた」「問い合わせメールにAIが下書きを返してくれる」「担当者にちゃんと振り分けてくれる」「来週の役員会で見せられる」——ここまでは最高です。ドーパミンどばどばですよね。

でも3ヶ月後にこうなる。

「部署が増えたら権限が壊れた」「プロンプトを変えたら昔の出力と形式が合わなくなった」「このAIの判断、誰が信じていいの？」「ログがなくて、なぜこの回答になったか追えない」「作った人が別案件に行って、もう誰も直せない」「A社用の例外処理が多すぎてB社に展開できない」。

これが腐るです。具体的な腐り方を、よく言われるパターンで並べるとこうなります。

AIシステムがプロンプト肥大化、RAG陳腐化、エージェント暴走、顧客別パッチで腐っていく図解

顧客ごとの特注コードが増える ：「うちだけこのCSV形式に」「この部署だけ承認フロー変えて」を全部素直に実装すると、if (customerId === "A社") みたいな分岐がどんどん増えて、プロダクトじゃなく「顧客別パッチ置き場」になる。
プロトタイプがそのまま本番化する ：「来週役員に見せたい」の圧力で、ログも雑、テストもない、権限も後付け、プロンプトはコードにベタ書き、のまま本番に乗る。
AIの振る舞いがブラックボックス化する ：AIの回答の良し悪しを自動で判定する評価のしくみ（eval。テストのAI版みたいなものです）が無いまま、「なんとなく良さそう」で本番投入。10件うまくいったからって、1000件うまくいくとは限らないのに。
顧客側が保守できない ：作ったFDE本人がいなくなった瞬間、「このプロンプト変えていいの？」「APIキーどこ？」と顧客が詰む。便利な黒箱は、壊れた瞬間に棺桶になる。
大口顧客にロードマップを乗っ取られる ：「この機能作ってくれたら契約する」に応え続けると、自社プロダクトが大口顧客の専用システムに変質していく。
再利用できない実装が量産される ：A社用RAG、B社用RAG、C社用RAG……全部似てるのに全部違う、という地獄。

AIシステムは、普通のシステムより腐りやすい

しかもAIが絡むと、腐り方がさらに複雑になります。

プロンプトが腐る 。最初は数行だったのに、「もっと丁寧に」「いや短く」「ネガティブはやわらかく」「でも問題点は明確に」「JSONで」「日本語で、でも項目名は英語で」と足していくと、誰も全体を読めない500行のスパゲッティになる。どの一文が効いているか分からないし、少し変えると壊れる。

RAGが腐る 。さっき出てきた「社内文書を検索してAIに答えさせるしくみ」ですね。これは作るのは簡単でも、運用し続けるのが難しい。古い文書が混ざる、最新版と旧版が両方ヒットする、権限のない文書が参照される、更新バッチが失敗しても誰も気づかない。

エージェントが暴走する 。間違ったツールを呼ぶ、同じ処理を二重実行する、途中で止まって再開できない、人間の承認が必要なところを勝手に進める。

このへんは僕らも本当に他人事じゃないです。そもそも「システムが腐る」「スパゲッティコード化する」って、FDEだから起きる特別な現象じゃないんですよね。個人開発でも、いわゆるバイブコーディングでAIに任せて勢いで作っているときでも、普通に起きる。むしろClaude CodeやCodexで爆速に作れる今は、誰がやっても起きやすくなっている。「動いたから本番でいいや」の誘惑が、前より圧倒的に強いからです。FDEで怖いのは、それが自分の手元じゃなく、顧客の本番環境で、しかも大規模に起きるという点。速く作れる時代は、裏を返すと 腐るスピードも速い 時代なんですよね。

研究データもひとつ。2026年のarXivの大規模調査「Debt Behind the AI Boom」では、6,299リポジトリ・30万件超のAI作成コミットを調べた結果、AI由来の問題のうち 22.7%が最新版になっても残り続けていた と報告されています（コードスメルが89.3%を占め、どのAIコーディングアシスタントでもコミットの15%超が少なくとも1つ問題を入れていた、とも）。FDEそのものの研究ではないですが、「AIで速く作る現場では保守負債が残りやすい」ことを示す材料にはなります。

（余談：フォルダ内の元資料では「24.2%」と書いてあったんですが、実際に原典を当たったら22.7%でした。こういう孫引きのズレ、AI時代はますます増えると思うので、数字は一次ソースで確認するのが大事です。）

会社ごと「高級受託開発会社」になるリスク

個々のシステムだけじゃなく、会社全体が腐るパターンもあります。FDEが大口顧客の要望に応え続けて、その維持に本社の開発ロードマップが飲み込まれていくと、SaaS企業のはずだったのにいつの間にか「高級受託開発会社」になっている。投資家のF-Prime Capitalも「FDEはエンタープライズ案件を速く取るのに有効だが、大口顧客にロードマップを乗っ取られないようにする必要がある」と指摘しています。スケールしてこそのソフトウェアビジネスなのに、スケールしない方向に引っ張られるわけです。

じゃあ、どうやって腐らせないか

批判ばかりだとフェアじゃないので、「腐らせないFDE」が何をしているかも書いておきます。要は、Degnanの批判をどう回避するか、です。

顧客固有の部分と共通の部分を分ける ：認証・権限・ログ・監査・LLM実行基盤・RAG基盤・評価基盤・通知・ジョブキュー・UI部品は共通化する。CSVの項目マッピングや業務用語、承認ルールだけを顧客固有として切り出す。この線引きができると、FDEの仕事がプロダクトの栄養になる。できないと、ただの顧客別パッチになる。
PoCコードと本番コードを分ける ：PoCは雑でいい。でも本番に入れる前に、ログ・テスト・権限・再実行・エラー処理・運用手順を入れる。ここを飛ばすと腐る。
評価のしくみ（eval）を作る ：「良い出力／悪い出力とは何か」を判定するテストデータを用意しておく。これがないと、プロンプトを変えてもモデルを変えても、品質が上がったのか下がったのか分からず、「祈り」になる。
人間の確認ポイントを設計する ：全部自動化するより、「どこで人間が確認するか」を決めたほうが強いことが多い。AIが下書き→人間が確認→修正を保存→次の改善に使う、という流れにしておけば、AIが間違えても業務事故になりにくい。
上流に還流する（Upstream Integration） ：A社で苦労したルーティングがB社でも出てきたら、「これはどのエンタープライズでも共通の構造的課題だ」と見抜いて、汎用化できる部分を本社に持ち帰り、コアプロダクトの標準機能として作り直す。これこそがFDEモデルを崩壊させない唯一の安全装置だと言われています。

まとめると、成功するFDEは 現場の泥を触りながら、そこから共通部品を掘り出す 。失敗するFDEは 泥をそのまま本体に塗り込む 。差はここだけ、と言ってもいいくらいです。

給与とキャリアの実態

気になる人も多いと思うので、お金とキャリアの話も。

グローバル

FDEは「技術力 × 顧客折衝力」という、市場で最も調達しづらい掛け算スキルを要求されるので、報酬はかなり高めです。2026年時点のレンジはだいたいこんな感じ。USDのままだとピンと来づらいので、円換算の目安も付けておきます（2026年5月時点でだいたい1ドル＝155〜160円なので、ここではざっくり155円で計算しています）。

グローバルではジュニアでも$140K台から、スタッフ級では$630K超まで見えてきます。日本でも日系で700万〜2,500万円、外資系オフィスでは2,000万〜5,000万円クラスが出てきていて、普通の国内ソフトウェアエンジニア職よりかなり強いレンジです。

Palantirの平均総報酬がおよそ$238K（約3,700万円。レンジは$205K〜$486K、スタッフ級は$630K超）、市場全体だと$180K〜$700K（約2,800万〜1億800万円）あたりに収まる、という複数のデータがあります。ただし、OpenAIやAnthropicのオファーは株式（equity）の比重が大きく、しかも非公開の企業評価額に連動して6〜9ヶ月ごとに見直されるので、「$550K」という額面が半年後に大きく増減することもある、という注意点付きです。

日本

日本でもFDE求人は確実に増えています。2026年春時点で、公開されている求人は日系で約26件、外資系で約9件、合わせて35件前後。提示年収の上限の中央値はおよそ1,500万円で、これは国内のソフトウェアエンジニア平均（約700万円）の2倍超です。

レンジで言うと、日系がだいたい700万〜2,500万円、外資系オフィス（Palantir Japan、Sierra、Cohereなど）になると2,000万〜5,000万円クラスも出てくる。採用しているのはLayerX、ソフトバンク系（SB OAI Japan）、ギブリー、AI Shiftなど、AIスタートアップから大手まで広がっています。LayerXはエンジニアブログでFDEポジションの立ち上げを発信していて、国内でも職種としての認知が一気に進んだ印象です。

ひとつ大きな壁として、外資のFDE求人はほぼ全部が日英バイリンガル必須なのに対し、日系は12%程度しか求めていない、というデータがあります。この語学要件が、外資との3倍近い年収差を生む障壁になっている、という見方もあります。

日本特有の難しさ

ついでに、日本でFDEをやる／頼むときの落とし穴も。

SES・常駐と混同されやすい ：「エンジニアが顧客先に来る」=「言うとおりに安く書いてくれる常駐リソース」と受け取られがち。成果にコミットする自律的なプロフェッショナル、という前提がずれると、お互い不幸になる。
現場のデータが標準化されていない ：紙、Excel、部署ごとのローカルルール。AIを入れる前段階のデータ整理に時間を食われる。
意思決定スピードの衝突 ：FDEは「翌日プロトタイプ検証」の即時性で動くのに、顧客側が「持ち帰って何度か会議して承認」だと、せっかくのスピードが死ぬ。

このへんは、日本でAI導入の現場に立ったことがある人なら、うんうんと頷くところだと思います。

まとめ：FDEは「職種」というより「動き方」かもしれない

長くなったので、最後に僕なりの考えを書いて締めます。

FDEを調べていて一番面白かったのは、これが「まったく新しい何か」というより、 今のエンジニアに求められている動き方に名前がついただけ なんじゃないか、と思えたところです。

コンサルみたいに業務を理解して、
でも提案で終わらず自分でコードを書いて、
SESみたいに工数を売るんじゃなく成果にコミットして、
受託みたいに1社で終わらせず、知見をプロダクトに還元する。

これって、AIを相棒にして広い範囲を一人で見られるようになった僕らにとって、けっこう地続きの話なんですよね。Claude CodeやCodexで「広く浅く全部やる」が現実になったからこそ、FDE的な働き方が成立するようになった。実際、ある対談では「数年後にはFDEという役職名自体が消えて、生き残るビジネスパーソン全員が、現場の課題を見つけてAIで解決するFDE的な動き方を当たり前に求められるようになるのでは」という話も出ていて、僕もわりとそうなる気がしています。

ただ、忘れちゃいけないのが影の部分。速く作れるということは、速く腐るということでもある。Degnanの「技術的負債とリスクを残す」という批判は、煽りでもなんでもなく、僕らが日々AIでコードを生成している現場にそのまま刺さる警告です。「砂利道を切り拓く」のは楽しいけど、「高速道路に舗装し直す」までやらないと、ただ泥道を増やしているだけになる。

だから僕は、FDEというバズワードに乗るかどうかより、「速く作ったものを、長く使える形に戻す仕組みを自分が持っているか」のほうがずっと大事だと思っています。それがある人は、肩書きがFDEだろうがなんだろうが強い。無い人は、AIで加速した分だけ速く詰む。

——というあたりで、今回はおしまいです。FDEという言葉をきっかけに、自分たちの普段の作り方を見直すいいネタになりました。長い記事を最後まで読んでいただいて、ありがとうございました。

参考にしたソース

#FDE #ForwardDeployedEngineer #AI開発 #ClaudeCode #Codex #UHD