FDEって、なに？ ――「E」が及ぼす影響の考察

AI界隈で「FDE（Forward Deployed Engineer）」という言葉を最近よく見かけます。

要するにFDEとは何か。
直訳すると「前線展開エンジニア」。

これに対して、複数の解説や説明があるものの、明確な定義として理解できる情報ソースに私はまだ出会えたことがありません。

その範囲となりますが、自社オフィスのデスクで開発に専念するソフトウェアエンジニアとは異なり、顧客企業のオフィスや業務現場に深く入り込み、課題解決のためのAI・システム実装を一気通貫で行う役割といった位置づけと、私はひとまず整理しています。

しかし、これもよくよく考えると、どういう職種・職業なのかが曖昧です。

というより、そもそも職種や職業と捉えることも間違っていて、職能と捉えるべきなのかも分かりません。

このような状況下、私自身なんとなく「分からなくもない」と分かったフリをしているのですが、それは私だけではなく、他の方も同じような状況なのかなと思っています。

私の目の届く範囲では、Palantir発祥の「現場常駐型のシステムエンジニア」と表現されることが主流で、「ビジネスサイドと自社プロダクトを結び付けて結果を出すエンジニア」と、実際にPalantirで働いていた方がインタビュー動画※1で説明されているところも観たのですが、その他様々な人との会話の中では、生成AIを使いこなすITコンサルや、AI知見のあるビジネスコンサルなどの文脈で、FDEが語られているところに何度も遭遇してきました。

なにか違うような・・・

おそらくこれは、いくら調べても根源的な定義が曖昧ということもあって、人の"解釈"に依存したまま言葉だけが独り歩きして、多様な表現が散らばってしまっている実情を示すものなのだろうと思っています。

ここにモヤっとした違和感があるのです。

そして、その表現の曖昧さが、技術スタックや自身のポジションなどのマウントの取り合い合戦を誘発し、非建設的な方向に人のエネルギーを向かわせているような気がしてならないのです。

本記事では、そこに迫ってまいります。

「E（Engineer）」が混乱させている

先に紹介した通り、FDEの「E」は、Engineerです。

このエンジニアという言葉の印象を加えて、FDE全体を認知するとどうなるか。

「プログラミング言語は何が使えるか？」
「フロントエンド・バックエンドをどの程度触ったことがあるか？」
「開発インフラとして、どのクラウドを何年間使ってきたか？」

これに限らず、およそ「エンジニア」＊ の技術スタックが問われると思いませんか？

要するに、「非エンジニア」との間に明確な区分線が引かれてしまうのです。

＊ 語弊がないように注釈しますが、メカニカルエンジニアではなく、ソフトウェアエンジニアやシステムエンジニアを前提としています

実はこれ、「エンジニア」という職業に、ITの技術スタックが必要だという認知バイアスがあるからです。

既に技術スタックを持つ人にとって、
「非エンジニアごときがエンジニアを語るな」とか

持たない人にとっては
「非エンジニアとしてはエンジニアには適わないから競合したくない」とか

こういった非協力的な発想が生まれることは、エンジニアという言葉の概念で線引きしてしまう以上、必然なのです。

しかし、ここで本質に迫ります。

AI時代に、その対立構図に意味ありますか？

生成AIの登場で、何が変わったか。

コードを書く技術障壁が、実質的に消えたと言われています。

2026年現在、現場のドメイン知識を持つ非エンジニアが、PoC（概念実証）となる試作システムを作り、業務フローを自動化し、データを分析して、経営判断を支える素材を準備する・・・ものの数日あれば作ることができるようになりました。

それも、エンジニアとしての技術的な習熟ほぼなしで、です。
（ITに対する興味関心や、それを活用する論理的思考などの素養は必要です）

そもそも、エンジニアも生成AIにコードを書かせるぐらいですから、技術スタックの希少性が低下している、ということは公然の事実となっています。

「生成AIを使いこなすITコンサル」、「AI知見のあるビジネスコンサル」といったニュアンスでFDEが表現されるのも、ここに背景があるのかもしれません。

要するに、FDEの「E」を、エンジニアと読むから、エンジニアへの認知バイアスが生まれ、非エンジニアの業界参入に嫌悪感を持つのです。

実はこれ、既に別のところで議論されています。

スタートアップ界隈（Y Combinator周辺）で、こうした言い方がされ始めているようです。

ここで言う「ビルダー」とは、「コードを書く技術（How）」に執着せず、AIを道具として徹底的に使いこなし、「プロダクトや価値を生み出すこと（What/Why）」にフォーカスする人を指すそうです。

AIコーディングエージェント（CursorやGitHub Copilotなど）の進化により、Y CombinatorのCEOギャリー・タン氏は「2025年冬のYC参加スタートアップのうち25%で、コードの行数の95%をAIが書いている」と述べています。

これにより、「コードを書くスピード」や「言語の文法に詳しいこと」の価値は相対的に下がりますが、代わりに重要になるのが、「AIを操って、実際に動く価値（プロダクトやサービス）を爆速で組み立てる（Buildする）能力」であり、これが「ビルダー」なのであると。

なるほど。

私のFDEに対する違和感が少しだけ晴れたような気がします。

ようするに——

非エンジニアのFDE

↓

FDE"的な”職業（ビルダーという表現もある）

とすると、しっくり来るかもしれません。

※エンジニアの方から、「いや、ビルダーはエンジニアの役割の一部だけどな」という手厳しいツッコミを受けるかもしれませんが、これはY Combinator周辺での議論を私が素直にピックアップしただけなので、そこは寛大にご容赦ください

技術障壁が消えた、ということの意味

以前「ドメイン知識で開くAIの扉」で書いた通り、ジェンスン・フアン氏の「誰もがプログラマになれる」といった主旨の発言があったとお伝えしました。

要するに技術スタックを習得するコストが劇的に下がったという事実を指しています。

ただ私が考察したいことは、その先です。

AI時代に技術スタックの障壁が消えることで、「現場を知っている人間」の価値が相対的に上がる、そういった人間の価値はどう活かされるかということです。

今までは、「これが出来れば、業務が改善するはずなのに」という仮説思考を持っていたけれど、技術障壁によって放置されることに、歯痒い想いをする——この感覚は、現場に長くいた人間にしか持てません。

ところが、生成AIによってコードを量産できる能力が民主化され、その技術障壁が突破されるのです。

「FDE」（実質的には「FDE"的な”職業」）が注目され始めた理由は、ここにあるのではないでしょうか。

ここには、技術スタックの習熟度の高低は全く関係がありません。

むしろ、現場知見とAI技術のスキルセットを手にして、これまでに乗り越えられなかった課題をいとも簡単に解決してしまう・・・かもしれない。

「エンジニア」と「非エンジニア」の隔たりを超えたところにある、まだ見ぬ新時代——

この期待感の象徴が「FDE」（実質的には「FDE"的な”職業」）、といったところなのではないでしょうか。

なぜ動けないか ——「今の優位を失いたくない」という引力

それでも「まだ動けない」の理由は、以前の記事でも書きました。

経路依存性については「副業AI層の俯瞰——組織がAI人材を活かせていないことの考察」で書きました。

「ずっとこのExcelでやってきた」という慣性の話です。

損失回避バイアスと自縄自縛については「生成AIで情報流出？ 因果関係の誤認が生む自縄自縛（上/下）」で書きました。

起きてもいないリスクへの恐怖が、自身の行動を封じる構造です。

本記事で新たに考察したいのは、「マウント合戦の正体」についてです。

「技術スタックを持つ側」が「持たない側」に相対的優位を示したがる現象——先ほど「非エンジニアごときがエンジニアを語るな」という話をしましたが、実はこれ、心理的に言うと、ごく自然な損失回避の表れなのです。

人は同じ大きさでも、損失を利益より2倍前後（おおむね2〜2.25倍）強く感じるとされています。

Samuelson & Zeckhauser（1988）が示したように、人は現状を変えないことを選びやすい。

エンジニアが「コードが書けることの価値」に固執するのも、この構造と重なります。

でも、

「私たちの努力も知らずにドメインにやすやすと入ってくるな。」と。

それならば、非エンジニアも「何を偉そうに。生成AIで存在価値を失っているじゃないか。」と思ってしまっても無理はありません。

悲しきかな、非生産的な対立構図になってしまうのです。

・・・本質は、そこなのでしょうか？

「一緒に発展しましょうよ！」というのが、私のスタンスです。

FDE "的に" 動く、4つのステップ

私は非エンジニア風情の「FDE"的な"仕事」をしている者ですが、技術スタックを持つエンジニアの方々と協力関係にありたいと考えています。

では、そのためには、具体的にどう動くか。

私が有効だと考えている業務ステップを紹介します。

ステップ 01：PoCで見せる

最初の一手は、頭に思い浮かんでいる仕組み（コンセプト）を「実際にシステムで動かして見せる」ことです。

言葉で説明するより、現場のデータを使って走る試作を短期間で作って見せて、コンセプトを証明（PoC）する。

これで「なるほど、こういうことができるのか」というアイデアをエンジニアと共有しつつ、実現に向けた具体的な方法を話すことができます。

ステップ 02：伴走する

PoCが通ったあと、そのまま「じゃ、あとは頑張ってください」ではエンジニアも協力してくれませんし、現場でも定着が進みません。

エンジニアの協力のもと、現場の担当者が自律的に回せるようになるまで、改善サイクルに横に入り続けます。

たとえば、計画重視の周回型のPDCA、現場の観察から決断を繰り返す型のOODA。

業務内容次第ですが、何がフィットするのか考えて、定着率の高い方法を選択する。

McKinseyの調査（The State of AI, 2025）によると、AIで高い成果を上げている企業は、そうでない企業に比べて“業務フローそのものを抜本的に作り替えている”割合が2.8倍に上ると報告されています。ツールを入れるだけでなく、プロセスに入り込むこと自体が成果を分けているそうです。

ステップ 03：自律化させる

そして、伴走の目的は、伴走し続けることに重きを置かないこと。
ステップ 02でも言及していますが、現場が自分で判断できる状態を作ることです。

「こういうときはこう動く」という判断軸を現場から吸い上げ、構造的に言語化しつつ、それをエンジニアに分かる形で翻訳して、改善案を協議し、それをまた現場が分かる言語に翻訳して、現場に戻す。現場が自力で回せるようになるまで課題をつぶしていく。

ステップ 04：形式知化する

最後のステップが、私が最も重視するものです。

現場で回し切れるよう、課題を潰し切った運用ノウハウを、誰でも参照できる形に落とし込む。
属人化する必要のない知見がなくなり、次の担当者が一から学び直さなくていい状態を作る。

「自分がいないと回らない」→「自分が抜けても回る」という持続可能な仕事を創り出す。

コンサルにもエンジニアにない、第三の職能

ここで私が長い時間を過ごしてきたコンサルの話をします。

コンサルとはその性質上、現場とは異なるポジションで客観的な分析・提言を行い、気づいていなかった示唆を提供する、というのが提供価値とされています。

しかし、突き詰めれば、現場担当者として実務を回すわけではありませんし、多くの場合で、プロジェクトで現場の方の隣で働くという関与はしません。

確かに現場に貼り付いて、直接関与する常駐案件もなくはないのですが、ベースの労務コストが高く、また上振れも読めないという採算の問題もあって、なかなかコンサル側も提案しづらいですし、提案しても見積が莫大になるのでクライアント側も採用しづらいのです。

一方、エンジニア（この文脈ではSIerの方が正しいかもしれません）は、技術的な実装を担います。

もちろん、「この組織の業務の何を変えると何が変わるか」というドメイン側の文脈からプロジェクトにアサインされるわけですが、かと言って、ビジネスデベロップメントのリードをエンジニアに任せるには知見の限界もあります。

また、ITコンサルというポジションもありますが、プロダクトアウト型のIT企業所属だったり、そのプロダクトのカスタマーサクセスを担う業務委託だったりして、プロダクトありきで、ミッションが純粋なビジネスデベロップメントとは言い難いというのも事実です。

「FDE"的な”職業」が担うべきだと思うポジションは、その隙間ではないでしょうか。

「現場知見 × 実装 × 詳細技術設計へのブリッジ」の三位一体——コンサルにも、エンジニアにも、担えない第三の職能。

おそらく、ほぼ全ての現場に必要になってくるはずです。

需要が爆発的に伸びる――
のではないかと思っています。

いや、実は既に大きく伸びている産業なのですが、想像も付かないところまで、果てしなく伸びていくのではないかと思っています。

個人の意識改革だけでは変わらない ——組織がAIを前提にする

「組織がAI人材を活かせていない（副業AI層の俯瞰）」
「導入が止まっている（情報流出・自縄自縛）」

これは以前に書いた記事における問題提起です。

そして、その１つの問題解決アプローチがFDE"的な"仕事だという話をしてきました。

しかし、個人の意識を変えるだけでは限界があるとも思っています。

たとえば、AIスクールの広告。

ビジネスマーケティングとして、
「今、学べば自分を差別化できる！」

これは、人の目を惹くには非常に効果的だと思います。

実際、そういった広告を多く見かけるようになったというのは、今AIスクールに通う人が急増していることの証左でもあると思います。

一方で、そんなもの学ぶ時間があったら今苦労していないだとか、学んだところで結局自分の会社では使えないから学ぶ意味がないと仰っている方々が、私の周りに大勢いるというのも事実です。

他のクリエイターさんも「まだ動かない」世界観とそれへの施策の記事を書いていらっしゃったので紹介します。

（なお、ご本人からご了承もいただいています）

私とは異なる切り口ですが、現場の臨場感を感じ取れる記事です。

一連の観察による結論は、

組織として、AI活用するか否かを個人の意思に依存し、組織が従業員を放置しておいた場合、AI活用を「始める人」と「静観する人」の二極化が進む

ということです。

しかし、本来、技術というのは、個人がお金を払って、資格化・権威化されるべきものではなく、誰でも触りながら覚えて使えるようになる、そういった民主化が図られるべきものではないでしょうか。

そこから技術が広まり、誰もが諦めて放置されていた課題が解決していく、といった革新が生まれてくるのではないでしょうか。

なお、日本企業のAI活用成熟度は、導入を推進する企業とそうでない企業とで格差が拡大していると、複数の民間調査（JIPDEC「企業IT利活用動向調査2026」ほか）が指摘しており、2026年版の中小企業白書でも「現状維持は最大のリスク」と示しています。

多くのAIスクールの広告が発信しているメッセージにも通じるところがありますが、要するに、組織がAI活用を個人の意思に一任して「始める人」と「静観する人」の二極化が進めば、組織の生産性格差も拡大するということです。

私が付け加えたいのは、「だからこそ、個人の自発的な意識改革に依存する現状では不十分なのでは？」ということです。

生産性を上げることを目的にするのであれば、組織がAI利用を前提にした働き方に変革していくという、組織側の意識変革が求められるのです。

まずそこが先に来ることで、個人単位で考えたときに、非エンジニアだとかエンジニアだとかの線引きで、技術的な相対的優位性を争う意識がなくなるのではないでしょうか。

むしろAI時代に必要なことは、

のはずです。

「FDE"的な”職業」の再定義

「エンジニア」と「非エンジニア」の垣根を超えた協力関係は、社内の"職種”だけの話ではありません。

むしろ、外部の”職能”を借りるべきところです。

FDE（Forward Deployed Engineer）"的な"職能を、改めて再定義したいと思います。

もはや「FDE"的な”職能」に「エンジニア」の技術スタックは必要ないという話はしました。

業界ドメインの知識があり、AIをツールとしてバリバリと使い、現場に入って定着まで見届ける——それが「FDE"的な”職能」として、あるべき姿です。

現場担当者と同じレベルかそれ以上のドメインの知識を持ち、それを解決するためのデジタルソリューションを考えて、コンセプトを形にして（PoC）、実用最小限のプロダクト（MVP）に向けて、専門エンジニアと話し合い、現場でプロジェクトを回し切り、現場での自走化にコミットする。

これは、エンジニアに押し付けるものでもなければ、コンサルの職能でないと出来ないってわけでもありません。

（ビルダー・・・も、なんだかしっくり来ないのですが、なにか他にいい表現があったら、是非コメントで教えてください）

ともあれ。

技術スタックや現場ドメインの有無といったマウント合戦に費やすエネルギーを、もっと前向きなことに使いませんか。

「技術や知見を持つか持たないか」ではなく、「現場の課題を解決できるかどうか」、これを考えていきませんか。

その先に、より良い持続可能＊な未来が見えてくるはずなのです。

＊ AIの電力消費と絡めて持続可能がないという指摘は甘んじて受けますが、組織の生産性の未来という文脈で受け取ってくださると幸いです

このあたりの格言はたくさんあるのですが、一旦ここまでとします。

（参考）

出典・脚注

※1 「ビジネスサイドと自社プロダクトを結び付けて結果を出すエンジニア」：LayerX「FDEの本質とは？元Palantir社員と語るFDEモデル」（YouTube、https://www.youtube.com/watch?v=GM-OyMCnqtc）内「PalantirにおけるFDEの定義」での、元Palantir社員の発言より。

※2 ビルダー概念：Y Combinator周辺で“builders”を重視する発信が見られる（Garry Tan ほか）。ただし「エンジニアではなくビルダー」という断定的フレーズの公式一次ソースは未特定のため、本文では「語られ始めている」程度に留めている。

※3 損失回避の倍率：プロスペクト理論（Tversky & Kahneman 1992。原典は Kahneman & Tversky 1979）。損失回避係数λの代表値は約2.25（λの数値化は1992年論文による）。

※4 現状維持バイアスの基礎研究：Samuelson, W. & Zeckhauser, R. (1988). "Status Quo Bias in Decision Making." 『Journal of Risk and Uncertainty』, 1(1), 7–59.

※5 業務プロセス再設計で2.8倍：McKinsey "The State of AI: How organizations are rewiring to capture value"（2025年3月公表）より。AIで高い成果を上げている企業がワークフローを抜本的に再設計している割合は、そうでない企業の約2.8倍（55% vs 20%）。倍率は「成果の大きさ」ではなく「再設計を行う割合」を指す。

※6 「現状維持は最大のリスク」：2026年版中小企業白書（中小企業庁、2026年4月24日閣議決定）の核心メッセージより。白書原文の表現は「現状維持は最大のリスクといえるだろう」（第2部）。