シリコンバレーでは「FDE」という肩書きが乱発されている。セールスエンジニアも、コンサルタントも、みな自分をFDEと名乗り始めた。だがPalantirで250人のFDEを育てた張本人は、「その多くは、まだ何も終わらせていない」と言う。
何が起きているか
2026年9月12日、AI開発者向けメディアLatent Spaceに、Kepler CEOのVinoo Ganesh氏による寄稿「The Rise of the Forward Deployed Engineer」が掲載された（Latent Space、2026年9月12日 https://www.latent.space/p/forward-deployed-engineer-best-practices）。Ganesh氏はPalantirで検索・インデックス基盤やSpark/YARN基盤を担当した後、同社のFDE組織を拡大する社内プログラム「Project Frontline」を設計・主導し、250人以上のソフトウェアエンジニアをFDEとして育成した。その卒業生の一部は現在、OpenAI・Anthropic・xAI・Andurilの各社でFDEチームを率いているという。その後Citadelでビジネスエンジニアリングを率い、現在はAI向け決定論的インフラを提供するKeplerのCEOを務めている。
寄稿の中でGanesh氏はこう言い切る。（“An FDE engagement that ends with one delighted account and nothing changed upstream has failed.”）——「一社の顧客が満足し、その上流で何も変わらなかったなら、そのFDEエンゲージメントは失敗している」。
背景と構造
Ganesh氏の主張の核は、FDEが本当に「買われている」ものは何か、という定義のずれにある。
多くの企業は、FDEを「顧客対応がうまいエンジニア」だと考えている。しかし氏の実務では、FDEの仕事は顧客の言葉にならない業務のルール——氏はこれを「名詞と動詞」と呼ぶ——を拾い集めることにある。ある会社が「ポジション」と呼ぶものと、別の会社が同じ言葉で呼ぶものは違う。ある部署が当然だと思っている手順が、別の部署ではまったく違う手順で回っている。これは文書化されていない。「生きられている」文化としてしか存在しない、と氏は書く。
氏が挙げる例が象徴的だ。ある金融データ基盤の本番投入で、タイムスタンプが未入力の場合に1970年（エポック起点）へ自動的にフォールバックする仕様があった。テスト環境では問題にならなかったこの仕様は、本番の実データにぶつかった瞬間、230万通りの意図しないキー空間を生成し、必要なメモリ量が現実的でない規模に膨れ上がった。テストデータでは絶対に再現できない、本番特有の壊れ方だった。
もう一つの例は、より地味だが本質的だ。あるデータ品質担当者が、フォーマット変更（CSVからParquetへの移行）を頑なに拒み続けていた。理由を尋ねる代わりに、FDEが彼女の隣に座って手元を見ると、彼女はWindowsノートPC上でCSVファイルを一行ずつ目視確認していただけだった。求められていたのはフォーマットの説明ではなく、Parquetの中身をそのまま見られるビューアだった。それを作った瞬間、17時間かかっていた作業は2時間に縮んだ。
Ganesh氏は、この「名詞と動詞」の収集そのものは、FDEの仕事の半分に過ぎないと言う。残り半分は、それを「プラットフォームの資産」に変換することだ。個別の現場対応で終わり、翌週には誰も参照しない知見は、コンサルティングであってプロダクトではない。逆に、3つの顧客が同じ「証跡管理の限界」にぶつかったなら、それはプラットフォーム側が解決すべき本物のギャップのサインになる。
氏はさらに、FDEの報告ラインが営業ではなく製品組織に属すべきだと説く。営業に紐づいたFDEは「今月のこの案件を閉じる」ために動く。製品に紐づいたFDEは「次の10社に効く何か」を探すために動く。同じ肩書きでも、評価される指標が違えば、行動はまったく別物になるという指摘だ。
日本の中小企業にとっての意味
この話は、シリコンバレーの大手ベンダーの内部事情に見えて、実は日本の中小企業のAI導入にそのまま当てはまる。
現場に入り込んで課題を直すこと自体は、悪いことではない。むしろ入口としては正しい。以前の記事で「会社がまず作るべきものは、売るためのAIではない。自社にしかない『答えの土台』である」と書いたが（『秘伝のタレ』こそ、次の商品になる）、直すことと型にすることは、そこで終わってしまうと同じにはならない。次にまた別の会社で同じ課題が出てきたとき、ゼロから作り直すことになるからだ。
経営者がここで意識したいのは、たとえば地方のある会計事務所で、紙の帳票を目視で突き合わせる作業に月に何時間も溶けているとして、それを直すだけで終わらせず、同じ業種の別の会社でも再現できる型にまで持ち上げて初めて、投資に見合う仕組みになるという順番だ。自社の実績をそのまま次の事業に育てた例は自社で鍛えた「3倍」を、そのままFDE事業にした会社があったでも書いたが、あれも「直して終わり」にしなかったからこそ、次の商品になった。
逆に言えば、経営者が外部のAI人材やベンダーを評価するときに見るべきなのは、「うちの会社の問題を直してくれたか」だけではない。「そこで得た知見が、次にどう活きる形で残るか」まで問うことだ。1回きりの改修で終わる契約と、型として積み上がっていく契約とでは、同じ金額でも意味がまったく違う。
最初の一歩
自社のAI導入が「その場しのぎの改修」で止まっているのか、「次に活きる型」に育っているのか。まずは今動いている業務を一つ選び、その解決策が他の業務にも転用できる形になっているかを確かめるところから始めてみたい。自社のAI活用の現在地を、無料の診断で確かめてみてほしい。
参考記事
- Vinoo Ganesh「The Rise of the Forward Deployed Engineer — and How To Do the Job Right」Latent Space（2026年9月12日） https://www.latent.space/p/forward-deployed-engineer-best-practices
