👦🏻 作者: Henry（DeerFlow チーム）[1]
最近1か月、筆者は前端、ソリューションアーキテクト、プロダクトマネージャー、従来のアルゴリズムエンジニアという4人の転職を検討している友人に出会った。背景、年齢、都市はそれぞれ異なるが、皆同じ英語の略語、FDEを尋ねてきた。[2]行く価値はありますか？
FDEは、Forward Deployed Engineerの略です。[2]それは2年前までPalantirの業界スラングに過ぎなかったが、今日ではヘッドハンターの挨拶言葉や求人広告の頻出職種、そしてSNS上で「AI時代で最も価値のある職種」の候補の1つにまでなっている。OpenAIは2026年5月にこの名前で直接Deployment Companyを設立した。[3]初期投資40億ドルで、エンジニアを顧客の現場に派遣し、顧客のワークフローに組み込むことを明言した。AnthropicのApplied AIチームも4つの時区でFDEを同時に採用中だ。このことは、業界内のスラングから明示的な語彙になるまで、1年ちょっとしかかからなかった。
筆者の前回の記事《致超级个体》[4]では、「人間のエンジン」である好奇心、自己学習、自己駆動力、実践能力が、完全なClosed-loop内でどのように引き出されるかを議論しました。しかし、人間は浮遊しているわけではなく、具体的な職務の座標系に受け止められる必要があります。もしスーパーアイデンティティがAI時代の生産関係の「原料」であるならば、FDEは今年の市場で最も顕著に現れた「職務の形態」です。
筆者の見解では、FDEはコンサルティングの枠にも、アウトソーシングの枠にも当てはまらない。FDEは、スーパーアイソレーションに最も近いが、違いはFDEが「モデル企業×顧客」の狭間で組織化されたスーパーアイソレーションである点にある。
ご存知でしたか——「Forward Deployed」という言葉の由来は？もともとは米軍の用語「Forward Deployed Forces」で、海外や前線に配置され、近距離で対応できる部隊を指し、本土の基地に留まる後方部隊と対比されます。Palantirは2000年代後半にこの言葉をソフトウェア業界に持ち込み、「エンジニアを本社から離し、顧客の現場に滞在させる」働き方を表すために使用しました。内部チームさえも軍用音標にちなんで「Delta」と「Echo」と名付けました。今回、OpenAIとAnthropicがこの言葉を再び採用したのは偶然ではありません——エンジニアを前線に派遣するという本質は、これまで一切変わっていないのです。
本文では、筆者が最近この4人の友人から質問された3つの具体的な疑問に答えます。
FDEはAIの外衣をまとったコンサルティング会社なのか？それと従来のコンサルティングの境界はどこにあるのか？
FDEは、より高度なソフトウェアアウトソーシングですか？これと私が現在行っている受託開発との違いは何ですか？
私はFDEに向いているでしょうか？どのようなタイプの人がこの職務で伸ばされ、どのようなタイプが消耗するでしょうか？
筆者の態度は慎重な楽観です：FDEは確かに育ってきていますが、すべての人にとっての転換点とは言えません。それを盛り上げるよりも、はっきりと説明することが重要です。
OpenAIのDeploymentチームから始めましょう
FDE このラウンドの再ブレイクの瞬間を1つの出来事で示すとすれば、筆者は2026年5月11日を選ぶだろう——その日、OpenAIがDeployment Companyの設立を発表した。[5]COOのブラッド・ライトキャップは元のビジネス部門を離れ、特別プロジェクトに専念し、サム・アルトマンに直接報告するようになり、この件にフルタイムで取り組むことになった。同じ週、OpenAIは英国のAIコンサルティング企業Tomoroを買収し、150名のForward Deployed EngineerおよびDeployment Specialistを新会社に迎え入れた。
注目すべきは、OpenAIの採用ページで、サンフランシスコ、ニューヨーク、ワシントンに加え、Life Sciences、Semiconductor、Govなどの業界別垂直分野において、十数のFDEポジションが同時に掲載されていることであり、FDE採用担当者まで[6]このポジション自体が常に募集されています。アナリストは、このチームが3年以内に2000～4000人まで拡大すると推定しています。これは研究グループの規模ではなく、正規軍です。
Anthropic側ではほぼ鏡像の動きです。Applied AIチーム内のForward Deployed Engineerポジション[7]ボストン、ニューヨーク、シアトル、サンフランシスコ、ワシントン、ロンドンの6か所で同時に実施され、顧客の25％～50％が現地出張を要請される。最近繰り返し引用されている例として、フィンテック企業FISがある。同社の公告には、「AnthropicのApplied AIチームとforward-deployed engineersがFISに組み込まれ、Financial Crimes AI Agentの設計を共同で行い、知識をFISに移転して、今後より多くのAgentを独立して拡張できるようにする」と明記されている。
この言葉には、FDEという仕事の真実が隠されている。これはセールスプリソリューションアーキテクトでも、SDRでも、顧客にトレーニングを行うエバンジェリストでもない。モデルを携えて顧客のコードベースに住み込むエンジニアである。ブラッド・ライトキャップはさらに率直にこう語っている。「我们的客户告诉我们，他们需要的是从 pilot 走到 production 的能力。Deployment Company 就是把我们的工程师塞进他们的团队，给足资源去交付。」
この出来事を図にすると、3者間の関係が非常に明確になります：
この図で最も情報量の多い2本の線は、FDEが両方向に送るフィードバックです。クライアント側には、FDEはモデルをSaaSとして販売するのではなく、クライアントのデータ、権限、コンプライアンス、内部システムをモデルを実行できる1本のパイプに統合します。モデル企業側には、FDEはクライアントのリアルな課題と失敗サンプルをProductとResearchに持ち帰り、ロードマップに影響を与えます——繰り返しエラーが発生するtool callingパターンが、SDKの次世代の組み込み抽象化になる可能性があります。
これが、FDEがこのラウンドで2つのトップモデル企業によって同時に再採用された理由であり、単に「我々もPalantirのようにコンサルティングを始める」という単純な話ではない。それはモデル企業が信号収集装置として機能しており、最前線の最も密集した顧客の課題は、自社の人が現場にいなければ捉えられない。パートナーを通じて伝えられる要件は、常に一歩遅れる。Anthropicはハイブリッドなアプローチを取っている：FDEを自社で運営しながら、コンサルティング企業やPE業界の巨匠と共同で展開ネットワークを構築している。一方は自社主導、もう一方はエコシステム重視だが、その核は同じだ。モデル企業はもはや単なるAPIサプライヤーではなく、自社のエンジニアを顧客の製品に直接派遣するようになっている。
次に答えるのは、FDEと従来のコンサルティング（マッキンゼー、エーコンシルなど）の境界はどこにあるか、そして私たちがよく知るソフトウェアアウトソーシングとは同じことなのか、という2つの最も一般的な比較質問です。
FDEはマッキンゼーではありません：モデルの境界 vs プロセスの境界
多くの人が初めてFDEの業務内容を聞いたとき、最初の反応は「これは新版のマッキンゼー、エーコンセントではないか？」です。
筆者はこのような連想を理解する。スーツを着て、顧客の現場に出張し、顧客の会議室でホワイトボードを描き、Cレベル経営陣と方向性を合わせる——その光景を見ると、FDEとコンサルタントは確かに似ている。しかし、もう一歩深く見ると、両者の仕事の本質はまったく異なる。コンサルタントはプロセスの境界を売っており、FDEはモデルの境界を売っている。
これらを表に並べると、差異がすぐに明らかになります。
この表で最も注目すべきは、「資産減価」の行です。
従来のコンサルティングの最も利益を上げるロジックは、資産の再利用——ある銀行向けの提案を、次の顧客には少し修正して再販する。小売業界のデジタル化プレイブックを30社の顧客に繰り返し適用する。これは過去30年間、Accenture、Deloitte、McKinsey Digitalが成長し続けてきた基盤となる経済モデルである。
FDEにはこのような資産は存在しません。モデルの能力は急速に進化しており、今日では丁寧に設計されたプロンプトチェーンが必要ですが、次のバージョンのモデルでは一文で済むようになるかもしれません。こうした速度の中で、「方法論の蓄積」は急速に価値を失います。したがって、FDEは資産の再利用モデルでは対応できず、毎回クローズドループを再実行する必要があります——モデルの境界を再評価し、ツールスタックを再選択し、製品形态を再構築します。一見非効率に見えますが、これがモデルの進化速度に追いつく唯一の方法です。
ご存知ですか——Product Overhangとは何でしょうか？筆者は前回の《致超级个体》で[4]以前この言葉を説明しました：モデルの能力は既存の製品形態を超えていますが、それを実現するための製品入口、権限、コンテキストがありません。FDEという役割の価値は、顧客のシナリオに浮遊しているOverhangを、実際に動作する製品に変換することです。顧客が購入しているのは、モデルAPIの呼び出しクォータではなく、「このOverhangの束を自社のビジネスに実際に実装してくれる人」の能力です。
これにより、「プロジェクト構成」の行の差異も説明できます。コンサルティングプロジェクトの標準的な構成は、SOW（Statement of Work）＋WBS（Work Breakdown Structure）＋フェーズごとの受入です。契約書には、何を、いつ、どの基準で納品するかを明確に記載します。この構成は、契約締結前に目標がすでに明確に定義されていることを前提としています。
FDEのプロジェクトはこのアプローチではうまくいかない。顧客が最もよく言うのは、「AIが何らかの手助けをしてくれるとは知っているが、具体的に何をしてくれるのか分からない」ということだ。目標そのものがプロジェクトの一部である。そのため、FDEはSOWを受けず、むしろミッション——やや曖昧な方向性——を受け入れ、イテレーションを繰り返してその方向性を徐々に明確にしていく。そして、あるイテレーションの段階で、これまで蓄積されたモデルの理解を製品形態として実現する。
「納品物」の行も展開する価値がある。FDEが去った後、顧客のシステムに残るのは、動作する機能——小さく、醜く、ユーザーインターフェースがほとんどなくても、毎日実際に呼び出され、変更され、批判されるものだ。コンサルティングの納品物はPPTと変革管理レポートであり、プロジェクトでコードを書いたりERPを設定したりしても、最終的に顧客の経営陣の手に残るのは依然として方法論ドキュメントである。
「護城河」という行は最も繊細である。FDEの護城河は、モデル能力の境界に対するリアルタイムの感覚である——今月どれだけ多くの実際の顧客シナリオを実行したかによって、Claude 4.7が何ができるか、何をClaude 5を待たなければならないかを、他の人よりもよく理解できる。この感覚はPPTに書き込むことも、知識ベースに保存することもできず、直近90日間実際に作業したエンジニアの脳みそにしか育たない。
だから、次に誰かが「FDEって新版のアクセンチュアだよね」と言ったら、こう返してみてください：アクセンチュアのエンジニアは顧客のプロセスを再設計しにいくのに対し、FDEはモデルの境界を再探求しにいきます。前者の資産は10年間蓄積されますが、後者の資産は90日後にまた一から育て直さなければなりません。
FDEはソフトウェアアウトソーシングではありません：共通の探求 vs 要件の実現
「FDEは新バージョンのアクセンチュアである」というのは第一層の誤解であり、「FDEは高価なソフトウェアアウトソーシングである」というのは第二層である。この第二層は、表面的な証拠が非常に豊富であるため、より誤解を招きやすい：FDEは実際に顧客の現場でコードを書き、顧客のビジネスに合わせて機能をカスタマイズし、顧客の勤務時間に応じて作業を行う。一見すると、アウトソーシングエンジニアと何ら変わらないように見える。
しかし、フィードバックループという事実を一見するだけで、違いは隠せない。
この図で最も重要な違いは、上半分がどれほどシンプルであるかではなく、下半分にモデル企業へと伸びるフィードバックの連鎖が追加されていることです。この連鎖は装飾ではなく、FDEという役職が存在する真の理由です。この差異を分解すると、少なくとも四組の対比が見られます。
接するものが異なる。外部委託ではSOW——契約締結前に明確に定義された要件リスト：どの機能を実装するか、どの技術スタックを使用するか、どの基準で検収するか、違反した場合の賠償方法。FDEはミッションを受ける——クライアント自身も何を求めるか明確にしておらず、「AIが何らかの手助けをしてくれればいい」とだけわかっている。SOWは確定性を前提とし、ミッションは探求を前提とする。両者はまったく異なるプロジェクト開始の姿勢である。
範囲が異なります。外部委託は部分的な納品です——モジュール、ウェブサイト、データパイプラインなどを作成し、完了次第引き渡して次の案件へ移ります。FDEはエンドツーエンドです——ビジネスの課題から始まり、モデル選定、プロダクト設計、そしてリリース後のユーザーの継続率と離脱率までをカバーします。
課金方法が異なる。これが最も直感に反する点である。あるモデル企業がFDEを顧客現場に派遣する際、最終的に気にするのは今回のプロジェクトでどれだけコンサルティング料を徴収するかではなく、この顧客が今後どれだけのトークンを消費するか、リテンション顧客になるか、さらに多くのビジネスラインに拡大するかである。FDEの真のKPIは、プロジェクト受入書上の数字ではなく、モデルトークンの長期的な消費曲線である。
フィードバックの行き先が異なる。これは4つのグループの中で最も深いレベルである。外部委託プロジェクトでは、クライアントのフィードバックは外部委託会社までしか届かず、同社が今後他の顧客に販売する製品に影響を与えることはない。一方、FDEのフィードバックはモデル企業のロードマップに還流する。顧客が実際のシナリオで遭遇するあらゆる課題、あらゆるPromptの失敗、あらゆるツール呼び出しのバグは、次のバージョンのトレーニングデータ、次のバージョンのツール設計、次のバージョンの製品機能への入力となる。つまり、FDEにデプロイされた各顧客は、モデル企業にとって天然のデザインパートナーである。
これがモデル企業が高給でFDEを採用する真の理由である。彼らは単にサービスを販売しているだけでなく、顧客の現場で現実世界の製品形態のシグナルを収集している。これらのシグナルは、購入できず、捕捉できず、アンケート調査でも得られない——それは、特定のエンジニアが特定の顧客のワークフローの中で、数回壁にぶつかってようやく持ち帰れるものである。
ご存知ですか——OpenAI と Anthropic の FDE の総報酬はどれくらいですか？ Levels.fyi に公開されている Anthropic のソフトウェアエンジニアのデータに基づく[8]资深SDEの総報酬中央値はすでに710,000ドルに達しています。FDEというポジションはリスクがより高い——モデル能力の不確実性、顧客ビジネスの不確実性、そして製品形態の不確実性に直面しなければならず、そのため業界全体で整理が進んでいます。[9]文中提到，前沿AI实验室FDE中高级别的总包薪酬基本落在350K - 550K之间，Staff级以上可达到630K+。这笔薪酬并非为“外包工时”付费，而是为承担“产品 + 客户 + 模型”三重风险的综合者付费。> 回想2006年，笔者刚参加工作，就职于某央企，当时正进行信息化转型，那时我们集团邀请的埃森哲顾问驻场，集团每天需向埃森哲支付3500元的咨询费，一待就是数年，被当时的媒体称为“金领”。笔者后来加入德国SAP公司，SAP更定义了咨询行业的一个名称，SAP咨询顾问更是“金领”的象征。由此可见，FDE的薪酬在未来24至36个月内将持续上涨，需求量也稳步上升。
アウトソーシングは労働力アービトラージであり、FDEはフロントラインセンサーである。この二つを混同すると、クライアントはFDEをSOWの方式で採用できると誤解し、候補者はFDEをアウトソーシングの姿勢で対応してしまう。両者ともすぐに壁にぶつかるだろう。
海外FDEの二つの根：Palantirと新世代モデル企業
多くの人が、FDEという用語はOpenAIが発明したと誤解していますが、実際にはそうではありません。FDEには二つの歴史的ルーツがあり、一つはPalantirに由来し、もう一つは2023年以降の新世代モデル企業に由来します。この二つのルーツを並べて見ることで、FDEという職務が実際に何をしているのかをより明確に理解できます。
まずタイムラインをご覧ください。
最初のルートはPalantirです。
Palantirは2003年、Peter Thiel、Alex Karp、Joe Lonsdaleらによって設立され、最初の顧客は米国諜報機関だった。Karp自身はCSのバックグラウンドを持っておらず、フランクフルトで哲学者Jürgen Habermasの下で博士課程を修了した後、Thielに招かれてCEOとなった。FDEという役職は、まさにこのような「非典型的なCEO＋高度に機密性の高い顧客」という組み合わせから生み出された。36Krの振り返り[10]書かれているように、Palantirは初期段階で諜報機関から激しく批判され、エンジニアが実際のビジネスシナリオにアクセスできず、要件が複数の段階を経て伝達されるうちに歪んでしまったことが理由だった。その後、Palantirは自社のエンジニアを顧客の現場に直接派遣し、諜報アナリストと共に作業させるというプロジェクトを実現した。このモデルは後にShyam Sankarによって体系化され、FDEの原型となった。
2009年までに、FDEは商業分野へ拡大した。JPMorganがPalantirのMetropolisプラットフォームを導入した際、120人のFDEが内部脅威監視のために配置された。この時点から、FDEは「エンジニアを出張させる」にとどまらず、体系的な顧客埋め込み戦略となった。Foundry/Gothamを顧客のビジネスフローに本格的に組み込み、ライセンスを渡して終わりにするのではなく。
PalantirのFDE採用には、CSの学歴を要求しないという直感に反する基準があります。これは「知っていますか」に含められます。
ご存知でしたか——Palantir FDEはCSの学歴を要求しません？SkillScouterが整理したPalantirの採用基準に基づく[11]Palantir 公式キャリアページと[12]PalantirはCS以外の専門分野の候補者を明確に歓迎しており、最近のFDE採用者は機械工学、経済学、哲学などの分野出身です。本当に重視されるのは二つだけです：不完全な情報の中でも行動できる能力、そしてCレベルのクライアントと直接対話できる能力です。CSの学位はプラスアルファですが、エントリーチケットではありません。Karp自身がこの基準の最初の例であり、哲学を専攻したCEOが、物理、数学、哲学を学んだFDEたちを率いています。
第二条根は2023年以降の新世代モデル企業です。
ChatGPTが2022年末にリリースされた後、OpenAIはすぐに一つの事実に気づいた。モデルAPIをドキュメントに掲載して、顧客が自力で接続する方式では、全く対応しきれないということだった。顧客が使いたくないわけではなく、使い方がわからないのである——彼らにはビジネス上の課題はあるが、製品の形態がない。そこでOpenAI、Anthropic、Cohere、Scale、Glean、Sierra、Hebbia、Decagonといった一連の企業は、次々とFDEを大規模に採用し始めた。
この一連のFDEは、Palantirのプレイブックを学んでいる——エンジニアを顧客の現場に派遣し、エンドツーエンドでワークフローを実行する。しかし、製品の媒体はまったく異なるものになった：Palantir時代のFDEはデータ統合とUIカスタマイズを手がけていたが、新世代のFDEはPrompt設計、Agent編成、ツール呼び出し、ワークフロー埋め込みを担当している。
Pragmatic EngineerによるFDEに関する専門記事[13]彼はこの新しいバージョンを「エンタープライズと統合して、Claudeが現実的で具体的な高価値の課題を解決する」ものと呼んでいる——これはPalantir当時の表現とほぼ同じで、ただ「データ」を「モデル」に置き換えただけである。
この二つの根を一緒に見ると、明確な共通点と差異が見られます。
共通点：顧客が購入しているのはソフトウェアではない。顧客が購入しているのは「私の問題を解決してくれるエンジニア＋ツールの組み合わせ」である。これは過去30年間の企業ソフトウェアの歴史において異常なことだった。SAP、Oracle、Salesforceはソフトウェアそのものを販売しており、エンジニアは「顧客がこのソフトウェアを使えるようにする」ための補助リソースであった。一方、Palantirは逆である：ツールは「FDEが顧客の現場で問題を解決できるようにするためのレバー」である。新世代のモデル企業はこの逆転関係を継承している——OpenAIはGPT-4のライセンスを売っているのではなく、「私たちのFDEがGPT-4を使ってあなたのカスタマーサポートを自動化するのを支援する」ことを売っている。
違い：Palantir時代はOPS統合に焦点——主な重点はデータ統合、オントロジーモデリング、権限ガバナンス。新世代はモデル能力の実装に焦点——主な重点はPrompt設計、Agent編成、リテンション最適化。前者はシステムインテグレーターの進化版、後者は製品エンジニアの拡張版。
最後にもう一つ興味深い事実：Palantirの早期FDEの多くは起業家となり、あるいは新世代のモデル企業に直接参加しました。Anthropic、OpenAI、Sierra、Hebbiaの初期チームには、数えきれないほど多くの元Palantir社員がいます。これは偶然ではありません——FDEという役割自体が、製品リスク、顧客リスク、エンジニアリングリスクを同時に担うことを強いるため、まさに起業家の訓練課程です。筆者はPalantirを隠れた起業家育成プログラムと見なしたいと思います。そこでは単なるエンジニアではなく、不完全な情報の中で物事をゼロからイチへ推し進める方法を知る人々が育まれました。この二つの根は、2023年以降にようやく合流しました。
国内FDE：ソリューションアーキテクトからAI実装エンジニアへ
二つの根の合流は主に海外で発生している。国内では、FDEという言葉の登場はそれほど長くないが、それに該当する業務内容がいきなり生まれたわけではない。国内のFDEを理解するには、まずその二つの地元の前身を把握し、次にアメリカ版FDEとの三つの環境的差異を明らかにすることが必要である。
二つのローカル元々の前身
最初的职业背景是云服务商的解决方案架构师。在过去十年中，阿里云、腾讯云、华为云培养出了一整支解决方案架构师（SA）团队，负责向客户讲解架构、编写POC、制定迁移方案，并配合完成交付上线。华为内部还有专门的“交付工程师”序列，负责将项目落地至客户机房。这套体系已承担了FDE工作的80%，但重心仍集中在售前和部署阶段——端到端的产品迭代责任并不在SA手中，需求变更需走变更流程，模型更换需等待总部排期。
二番目の前身は、AIスタートアップで新たに生まれたシーケンスである。MiniMaxはBOSS直聘に「AIプリセールスソリューションスペシャリスト」を掲載しており、月の裏側、智譜、通義、混元などのモデル企業も同様の職種を掲載している。名前は若干異なるが、JDの内容は非常に類似している：顧客のシナリオを理解し、デモを作成し、Promptを調整し、RAGを実行し、納品方案を記述し、顧客のエンジニアリングチームと連携してリリースまで対応する。この一連の職種が真正意义上的「国内FDE」である。
三つの水土の違い
プライベート化部署とデータコンプライアンスが、純粋なモデル呼び出しモデルを圧迫している。国内B2B顧客は、データの域外流出なし、モデル重みの制御可能、監査の追跡可能性という要件を、米国市場よりもはるかに厳しく求めている。FDEプロジェクトにおいて、APIを呼び出してプロンプトを実行する作業量は全体の3割に過ぎず、残りの7割はモデルを顧客のデータセンターに移設し、認証を実装し、データプラットフォームと連携し、コンプライアンス登録を行うことである。
モデルの能力はまだSOTAに追いついておらず、競争の余地はエンジニアリング層に圧縮されている。米国のOpenAIやAnthropicは、モデルの能力そのもので顧客を魅了できるが、国内の通義、豆包、Kimi、GLM、DeepSeekはモデルの差別化がそれほど大きくなく、顧客の判断基準はAgentの編成、RAG検索の品質、ツール統合、ワークフロー設計といったエンジニアリング能力に集中している。国内のFDEは「自社のモデルがどれほど強いか」ではなく、「このビジネスを実際に実行できるか」で勝負している。
B端の支払い意欲と価格設定のペースは米国とは一致していない。Palantirのような「まずFDEを導入し、その後高単価のサブスクリプションを課金する」モデルは、そのまま適用するのは難しい。国内の顧客は年間予算に沿って支払いを行い、プロジェクト単位での支払いが中心であるため、FDEのビジネスモデルは通常、サブスクリプション＋プライベートライセンス＋プロジェクト納品のハイブリッド形態となる。
独自のポジショニング：内部FDE
大手企業の多くのAIチームが、FDEモデルを用いて「内部顧客」にサービスを提供し始めている。阿里雲PAIはエンジニアを淘宝に派遣し、腾讯混元も微信や広告業務部門と同様のメカニズムを導入している。JDには「業界実装エンジニア」「AIアプリケーションエンジニア」「スマート化業務エキスパート」と記載されているが、これらは本質的に内部FDEであり、モデルチームの能力をエンドツーエンドで業務側に展開している。これは大手企業のリーダーに新たなアイデアを提供している：数名の内部FDEを業務側に配置し、最初のデモを実行してROIデータを業務責任者に渡すことで、10回の調整会議よりも早く部門間の壁を解消できる。
FDEに向いている人、向いていない人
筆者は前回の『スーパーインディビジュアルへ』[4]以前曾提到過超個體的五個引擎：強烈的好奇心、強烈的探索與創新精神、強大的自學能力、強大的內驅力、強大的動手能力。這五點是FDE的入場券，但並非全部。除了這五個引擎之外，FDE這一職位還需要一組非常具體的額外特質，同時也有幾類人格特質明顯不適合。筆者見過太多優秀工程師轉向FDE後出現水土不服的情況，問題大多不在能力，而在性格與工作偏好。
FDEに適した5つの特性
販売やコミュニケーションを避けない。FDEの日常は、閉じこもってコードを書くことではなく、顧客のCTO、ビジネス責任者、調達担当、コンプライアンス担当、IT担当と直接やり取りすることだ。典型的な流れはこうだ：顧客のCTOがデモ中に中断してきて、FDEの反応は「帰って修正して来週また来ます」ではなく、その場でIDEを開いてPromptを変更し、再実行して見せることだ。「顧客がいる中で、私が修正している」——これがFDEの日常である。
曖昧な領域を楽しもう。FDEが受け取るのは明確なPRDではなく、「AIを使って何かやりたい」という一言だ。クライアント自身も何が欲しいのか明確に言えないため、FDEはその曖昧な期待を具体的な形に育てるためにそばにいる必要がある。明確な要件がないと動けないなら、FDEの日々はあなたを不安にさせるだろう。
エンジニアリング力はしっかりしているが、10xを求めない。FDEには、会社で最もコードが綺麗で、アルゴリズムが最も深い人間である必要はない。必要なのは、エンドツーエンドで動かせることだ：フロントエンドはクリック可能なページを適当に作ればよく、バックエンドは動くサービスを構築できればよく、モデルはビジネスデータソースに接続できればよい。FDEの世界では、「だいたいできれば十分」は欠点ではなく、美徳である。
フィードバックに磨かれるのが好き。FDEの仕事には、クライアントから「これじゃない！」と叱られてやり直す場面がたくさんある：今日のデモが明日、事業部門から「これは私が求めているものじゃない」と言われる。先週合意した方案が、今週クライアントの経営陣が変わったことでまた一から作り直しになる。FDEに適している人は、こうしたフィードバックを燃料と捉え、エンドツーエンドの責任を負い、「要件を明確に伝えなかったのは需求側のせい」と責任を転嫁しない。
モデルの境界に敏感である。これは最も技術的で、最も隠蔽されたルールである。FDEは、どのタスクがLLMに適しているか、どのタスクが不適切か、またどのようにフォールバックすべきかを判断できる必要がある。このような敏感さは論文からは読み取れず、失敗事例に打ち勝つことでしか身につかない。失敗事例が蓄積することで、FDEはモデルの境界に対する筋肉記憶を獲得するようになる：どのシナリオではRAGを使用すべきか、どのシナリオではルールを適用すべきか、どのシナリオでは人間へのフォールバック入口を必ず設けるべきか。
FDEに適さない4つのタイプ
コードの中に隠れて純粋に技術に没頭したい人。FDEは約50％の時間をコードを書くのではなく、顧客ミーティング、内部調整、製品ディスカッション、契約の推進に費やしている。もしあなたの喜びが、4時間連続で誰にも邪魔されずにコードを書くことなら、FDEは長期的に精神的疲弊を招くだろう。
OKRがないと動けない人。FDEの目標は顧客にあり、あなたの評価表にはない。作業の進捗は、顧客のプロジェクトの節目、モデルの能力の変化、そして自分自身のシナリオに対する判断によって決まる。「まずOKRがあって、それから何をすべきかわかる」という習慣の人たちは、锚を見つけることができない。
「昇進」を「作品」より重視する人。FDEは大手企業の昇進システムでは有利ではない——顧客満足度、プロジェクト獲得、再利用率といった指標は、コード量やリリース頻度と比べて、職級審査で力を持たない。もしあなたの仕事の動機が昇進を最優先するなら、FDEは適していない。
ビジネスの文脈に抵抗のある人。FDEは、顧客のP&L、ROI、調達プロセス、コンプライアンス要件を理解しなければならない。もし金銭や契約、ビジネスロジックの話に自然と抵抗を感じるなら、FDEの仕事は、技術的理想を売っているように感じさせるだろう。
セルフチェックリスト
FDEの実際の業務シナリオに対応する7つの質問。5つ以上「はい」と答えた場合、FDEを真剣に検討してください。3つ以下の場合、慎重に検討することをお勧めします。
1. 毎日50％の時間をコードから顧客ミーティング、メッセージの返信、電話に移すことに賛成ですか？
2. お客様が「これではダメです、なぜかはうまく説明できません」と言うとき、あなたの最初の反応は好奇心ですか、それともイライラですか？
3. 誰もPRDを書いてくれないが、クラウドコードと協力して、顧客に見せられるプロトタイプを1週間以内に実現できるか？
4. 同じ納品物について、クライアントに8回修正を依頼されても、機械的に実行するのではなく、判断力を保てますか？
5. モデルが誤った回答を出した場合、最初の反応はフォールバックを設計することですか、それともモデルができないと文句を言うことですか？
6. 契約に署名し、報告書を作成し、顧客の受入作業を進め、法務部門とコンプライアンス条項を調整できますか？
7. プロトタイプを素早く作成し、素早く失敗することを受け入れられますか？
五つの特性、四つの逆像、七つの自己診断質問——最終的には同じ問いにたどり着きます：あなたの製品感、エンジニアリング力、ビジネス判断の三つを、同じワークフローの中で同時に磨き上げる覚悟がありますか？
まとめ：スーパーアイディビジュアルからスーパーポジションへ
前回の記事では、「人間のエンジン」——好奇心、探求心、自己学習能力、自発性、実践力——が大手企業内でどのようにして完全なサイクルで刺激されるかを議論しました。今回は別のテーマ、すなわち職務の形態について考察します。FDEは、AI産業革命の中で、名前を持ち、給与帯が設定され、求人票が存在し、顧客の支払いによって検証された最初の新しい職務形態です。これは「スーパー個人」という概念の同義語ではなく、この再構築の波の中で、初めて虚から実へと具体化された座標です。
FDEは終わりではない。筆者の見解では、FDEは新しい分業の中で最初に名前が付いた形態に過ぎず、その先にはForward Deployed PM、Forward Deployed Designer、Forward Deployed Researcherなどが登場するだろう。クライアントのシナリオと密接に連動し、曖昧な領域で製品を育て出す必要がある職種は、すべて「前置部署」バージョンを備えることになる。職種の名前は変わるが、基盤となるロジックは同じだ：モデルの能力が先行し、製品の形態がその後に追いつき、職務構造はワークフローに合わせて再編される。
三つの読者層にそれぞれ一文ずつ残してください。
技術者へ：FDEは、あなたが会社で最もコードが得意な人であることを求めませんが、コードの時間を半分まで顧客向けにシフトする意欲を求めます。もし答えが「はい」なら、市場の窓が開きました。国内のトップAIモデル企業、クラウドベンダー、大手企業の内部AIチームの採用が加速しています。もし答えが「いいえ」なら、問題ありません。新しい分工の中で、あなたに合った新たなポジションが生まれます。
HRおよびODへ：「名実の乖離」に注意してください。あなたの会社には、すでにFDEが存在し、職務コードには「ソリューションエキスパート」「業界アーキテクト」「AIアプリケーションエンジニア」と記載されている可能性があります。彼らを特定し、再分類し、実際の業務内容に合ったキャリアパスを提供することは、新規採用よりもはるかに効率的です。
管理者へ：FDEモードは外部だけでなく、内部にも適用できます。社内に数人の「内部FDE」を業務現場に配置し、モデルチームの能力をエンドツーエンドで業務フローに組み込む方が、新しいAI部門を設立して十回も跨チーム調整会議を開くよりもはるかに効率的です。部門間の壁は組織設計によって解消されるのではなく、実行可能なデモによって解消されます。
AI時代の職業転換がすでに始まっている。FDEはその最初の合図であり、モデルの能力の変化の速さが、新たな職種を生み出すまでに至っていることを示している。筆者は読者に具体的な問いを残したい：三年後、あなたの会社の組織図に新しい職位が三つ追加されたとしたら、それはどれだと思うか？この問いをしっかり考えることが、この記事を読むことよりもはるかに役立つ。