NEW! ITニュース
今、日本でキャズムを迎えようとしているAI時代の新職種「FDE（Forward Deployed Engineer）」。国内の有力スタートアップもこぞって採用を強化しているが、本場・米国トップ企業におけるFDEの実態は、私たちの想像を遥かに超えるスケールとスピードで動いている。
今回その最前線を教えてくれるのが、米マイクロソフトで『Microsoft Copilot』のFDEチームを率いる吉田大貴さんだ。吉田さんは2021年にアメリカへ移住し、現在は米国市場のエンタープライズを相手に、製品導入から機能開発を牽引するプレイングマネジャーとして活躍している。
「本場のFDE」は、顧客の現場にどこまで深く入り込み、いかにして開発サイクルを回しているのだろうか。吉田さんに話を聞いた。
Microsoft Corporation
FDE Principal PM Manager
吉田大貴さん（@TaikiYoshidaJP）
大阪府出身。2018年にマイクロソフト入社後、日本でPower Platformビジネスを立ち上げ、21年に渡米。米国本社の製品開発チームで世界中の大規模導入支援と成長戦略を牽引。25年新設の生成AI Agent FDEチームの管理職としてPrincipal PM Managerに就任。経営層向け登壇では全世界で最上位の賞を受賞し、殿堂入りを果たす。三児の父として育児にもPower Platformを活用中
目次
ーー吉田さんは現在、FDEチームのマネジャーとして活躍されているとか。
マイクロソフトのFDEチームは、担当するクライアントの地域ごとに分かれており、私はアメリカチームのプレイングマネジャーを務めています。主な顧客は、あらゆる業種におけるトップクラスの規模・売上を持つエンタープライズ企業です。
FDE（Forward Deployed Engineer）は、直訳すると「前線に展開するエンジニア」。その名の通り、お客さまが「どのAIプラットフォームを採用するか」を検討している初期段階から現場に入り込みます。
クライアント先の社員と見分けがつかないほど深く入り込み、要件定義から実装、運用まで伴走しながら、最終的には「明日から実業務で使えるエージェント」を一緒に作り上げていく。それが私たちの役割です。
チームメンバーとランチを楽しむ吉田さん（写真左端）
ーー現場に入り込んでシステムを導入するという点では、従来のITコンサルタントや客先常駐のSEと似ていますね。
一見すると似ているかもしれません。ただ、FDEの特徴は「お客さまの成功」と「プロダクト全体の進化」を同時に担う点にあります。
もちろん、目の前のお客さまへの導入を成功させることは大前提です。現場の課題に向き合い、実際に使われる形でエージェントを設計し、価値を出す。そこに本気で入り込むからこそ、FDEの仕事は成り立ちます。
一方で、FDEはそこで得た経験を、その1社だけの個別解に閉じ込めません。お客さまの現場で見えてきた「どの業務にエージェントが適しているのか」「どのような設計なら現場に定着するのか」「どこでつまずきやすいのか」といった実践知を、より多くのお客さまに再利用できる形へと抽象化していきます。
例えば、具体的なユースケースをテンプレート化したり、実装パターンとして整理したり、ベストプラクティスとしてドキュメント化したりする。場合によっては、そこで得られた学びが、プロダクト改善のフィードバックとして製品開発チームに還元されることもあります。
つまりFDEは、目の前のお客さまに深く伴走しながら、その経験を次のお客さま、さらにその先にいる何千・何万社のお客さまの成功につなげていく役割だと考えています。
ーー最終的に見据えているゴールがそもそも違うと。
ええ。FDEの職種名に「エンジニア」とついていて、所属もカスタマーサクセス部門ではなく製品開発部門である理由は、まさにそこにあります。単に導入を支援するだけではなく、現場で得た学びをプロダクトや仕組みに還元し、スケールする価値へと変えていくことが期待されているのです。
ですから、私がマネジャーとしてメンバーを評価する際も、単に「導入を成功させたか」だけでは見ません。もちろんお客さま先での成功は大前提ですが、それに加えて、現場で得た知見をどのように抽出し、再現性のある形にし、他のお客さまにも貢献できる資産へと変えられたのかを重視しています。
FDEの面白さは、まさにこの両方にあります。目の前のお客さまの現場に深く入り込み、リアルな課題を解決する。同時に、その経験をプロダクトや方法論に昇華させ、より多くのお客さまに届く価値へと広げていく。そこに、このロールならではの難しさとやりがいがあると思います。
ーーなぜ、こうした知見を横展開することを重要視しているのでしょうか。
背景にあるのは、AIエージェント市場の爆発的な拡大です。外部の調査機関であるIDCの予測では、2028年までに世界で約13億個のAIエージェントが作られると言われています。逆算すると、1社につき数百から数千個のエージェントが社内で立ち上がる世界です。
これまでは、ITエンジニアが主軸となってAIを開発してきました。しかし、1社で数千個ものエージェントが必要になる時代には、エンジニアだけで作っていては到底人手が足りません。必ず、現場のビジネスユーザー自身がCopilotのようなローコードプラットフォームを使って開発するようになります。
膨大な数のエージェントが現場主導で作られる時代に向けて、「どう作ればうまくいくのか」という確かなベストプラクティスを、今のうちに最前線の現場で集め、確立しておく必要があるのです。
ーーですが、もはやAIを使えば、プロンプト一つで簡単にシステムが作れる時代になりつつあります。こうした中で、わざわざFDEが現場に入り込む意義は何ですか？
最近はバイブコーディングが話題になりがちですが、エンタープライズの業務においては、必ずしも適しているとは言えません。企業が求めているのは、「同じ見た目、同じ仕様で、常に同じ品質・同じ結果が出る」反復性のあるシステムです。
「全く同じ見た目で、全く同じ仕様で、同じ結果にしてください」と求めた時点で、それはもはやバイブコーディングの範疇ではなくなります。常に同じプロセスで動き、結果を再現できるシステムとして設計する必要があるのです。
だからこそ、どのAIモデルを使うか以上に、「どういう構成にするか」というアーキテクチャ設計が重要になります。AIの非決定的な出力を許容する部分と、API連携や従来のシステムで確実性を担保する部分の境界線をどう引くか。その見極めこそが問われるのです。
ーーその「アーキテクチャ設計から実装まで」を、現場ではどのように進めているのでしょうか。
基本的には2〜3人の最小人数でチームを組み、4週間のサイクルで実稼働するエージェントを作り上げていきます。もちろん、複数の案件を同時並行で進めているケースがほとんどです。優秀なエンジニアだと、最大で5〜6個のプロジェクトを並行していることもありますね。
具体的には、まずお客さまにヒアリングを行い、どのような課題があり、何を効率化したいのかを整理します。エージェントのおおよその構成が決まったら、最初の1週間でベースとなるプロトタイプを完成させます。
その後は、実際にお客さまの環境でエージェントを動かしながら、「これも欲しい、あれも欲しい」と出てくる追加要件に合わせて、2週目、3週目と超アジャイルに改善を回していきます。
そして、4週間以内に完成させてお客さまにお渡しする。このスタンスで進めています。
ーーもし期限内にまとめられなかった部分は、どうなるのでしょうか？
お客さまにもよりますが、まずは4週間で実現できる内容を体感いただくことも目的としているため、基本的にはスコープから外す形になります。
一方で、今後他社にもスケールさせる観点で面白そうなシナリオや、より多くのお客さまが恩恵を受けられそうな機能であれば、各エンジニアの裁量でフェーズ2として継続できるようにしています。
こうした働き方ができるのは、FDE自身も生成AIを使って自分たちの能力を拡張できているからだと感じます。例えば、要件のヒアリングから要件定義書の作成、テスト用のサンプルデータ生成まで、あらゆる場面でMicrosoft 365 CopilotやGitHub Copilot CLIを使って作業を自動化しています。
ちなみに私自身も、管理職として1日に20件ほどの会議が同時並行で入ることがあります。その際、自分がメインスピーカーでない会議はCopilotのファシリテーターに出席させ、後で要約を読んだり、Copilotに確認したりしています。気になった部分だけ録画を2倍速で見直す、といった使い方もしています。
常にいくつかのタスクが重なっている状態ですが、業務の7〜8割はCopilotを使って処理していますね。
ーー実際に吉田さんが担当された実装事例も教えてください。
アメリカ国内で1万店舗以上を展開している、とある飲食チェーンのお客さまの事例をご紹介します。
そのお客さまの一番の課題は、店舗運営のガイドラインやマニュアルのドキュメント管理でした。必要な情報を探すのに時間がかかり、各店舗の店長やマネジャーから本部への問い合わせが殺到していたのです。対応用の専用電話番号も用意されていましたが、非常にコストのかかる状態になっていました。
そこで私たちのチームが入り、この課題に対応するAIエージェントを4週間で開発することになりました。
ただ、決してきれいに一直線で進んだわけではありません。最初の1週間でプロトタイプを作り、現場の店長さんたちに触ってもらったところ、当初は「これでは現場で使えない」と厳しいフィードバックを受けました。
ーー何が問題だったのですか？
生成AI特有の「揺らぎ」の問題です。毎回少し違うニュアンスの回答が返ってくるため、現場からすると「どの情報を信じていいか分からない」状態になってしまったんです。
また、「AIが答えられなかったとき、結局どうすればいいか分からず、本部に電話するしかない」というプロセス上の欠陥も指摘されました。これでは結局、本部の電話対応コストは下がりません。
そこで、重要な手順や規約の案内については、生成AIの自由な文章生成に頼るのをやめました。Copilot Studioを用いて、反復的な作業に特化した「トピック」や「フロー」を徹底的に盛り込み、エージェントの挙動を制御したのです。
さらに、「AIで解決しない場合」の導線もエージェント内に統合しました。具体的には、お客さまが利用していた問い合わせ管理システム『ServiceNow』をエージェントと連携。これにより、AIが回答できない複雑なイレギュラー対応については、エージェントのチャット画面から直接ServiceNowのチケットを発行し、本部にエスカレーションできる仕組みを構築しました。
ーー泥臭い作業が多いわけですね。導入後は、どのような成果が出たのでしょうか。
これまで、場合によっては解決まで数十分かかっていた店舗からの問い合わせを、瞬時に解決できるようになりました。すでに200店舗でのテスト運用を完了しており、2026年5月からは500店舗に展開する計画が進んでいます。
最終的には全店舗への展開を目指していますが、展開が広がるほどコストメリットも大きくなり、数千万円から数億円規模の金額的効果を見込んでいます。
ーーこうした現場での知見が、「次の1万社へのサンプル」になっていくと。
そうですね。現場の各担当から上がってきた製品の課題やギャップは、必ず集約する仕組みになっています。そのうえで、高頻度で寄せられる要望から優先的に対応しています。
AIエージェントを利用するシナリオ、例えばヘルプデスク対応や経費精算、ドキュメント検索などは、業種が違っても似通ってくる部分が多いんです。実際に先日、4月16日に、これまで現場で実装した200のエージェントの中から特にリクエストの多かった業務シナリオを抽出し、その最初の五つを「エージェントテンプレート」として一般公開しました。
フィードバックの方法はさまざまですが、例えばベストプラクティスや導入手法などのドキュメントについては、FDEチームが直接「Microsoft Learn（マイクロソフトの公式技術ドキュメント）」に執筆することもあります。現場で得た知見をまとめ、およそ2週間ほどで公式ドキュメントとして発行するイメージです。
ーー新たな機能追加に関しても、同様のスピード感でしょうか？
開発難易度によって実装にかかる期間は変わりますが、現場の生の声をもとに仕様を固め、数週間から数カ月で製品化まで持っていくケースが多いです。
直近の例が「評価（Evals）機能」です。簡単に言うと、構築したAIエージェントの回答の品質や正確性をテストし、定量的に測定するための機能です。
私がマネジメントしているメンバーが、25年10月頃から数社のお客さまでこの評価機能の導入を先行して進め、そこで得たフィードバックをもとに、本社開発チームのPMと密に連携しました。そして同年12月には新機能の拡張仕様を確定させ、実装まで実現しています。
ーーここまで、FDEの役割やスピード感について伺ってきました。しかし、この働き方を日本に当てはめようとすると、高い壁があるように感じます。
日本の商習慣を考えると、アメリカのやり方をそのまま持ち込んでうまくいくほど簡単ではないでしょうね。便利な「外注エンジニア」として使い倒されて終わる可能性もあると思います。
そもそも、日米では「失敗」に対する許容度がまったく違います。
アメリカでは、マイクロソフトの本社があるような町でも、雪が降ったり強風だったりといった理由で、年に何度も数時間にわたって停電することがあります。公共インフラですらそうなので、新しい技術の不具合に対しても「一旦やってみて、後で直そう」という寛容さがあるんです。
FDEとしてお客さまの現場に入っているときも、感覚としては毎日ハッカソンをやっているようなものです。「このやり方でうまくいかなかったから、すぐ次のアプローチを試す」というFail Fast、つまり早く失敗して学ぶ精神が求められます。アメリカには、こうした考え方が浸透しやすい土壌があります。
一方、日本は品質に非常にシビアで、「完璧に動く保証」がないと前に進まないケースも多い。この土壌の違いを無視してFDEを導入しても、日本特有の「PoC止まり」の罠にはまってしまうだけだと思います。
ーーPoC自体は悪くないはずですが、何が問題なんでしょう。
私が日本にいたときにも痛感しましたが、日本企業では、テスト環境でPoCを繰り返すこと自体が目的化してしまい、本番環境につながらないケースが多いんです。経営層も現場も、PoCという「安全な遊び場」から出ようとしない。
でも、FDEが4週間サイクルで動くのは、本番で動かして初めて見えるエッジケースを拾うためです。テスト環境で100回試すより、1回本番に出す方がはるかに価値がある。この「実稼働」への執着が、日米で決定的に違う部分だと思います。
ーー日本のエンタープライズでも4週間で本番稼働まで持っていくには、何をどう変えれば良いのでしょうか。
まず、全部を1回のサイクルで実現しようとしないことだと思います。従来の開発と違い、より素早くサイクルを回せるので、最初から全てを盛り込む必要はありません。
また、開発の途中で、より効率のよい業務の進め方が見えてきたり、エージェントの特性を理解することで、それまで考えつかなかった使い方をお客さま自身が見つけたりすることも多々あります。特に、従来のプロセスをそのまま代替しようとする傾向があるため、BPR（※）の一環としても、まずはスモールスタートで始めることが重要だと思います。
よくある失敗の一つが、「生成AIを活用すること」自体を目的にしてしまうことです。本来のゴールは、あくまで実際に使われ、業務がよくなることにあります。
FDE側では、最初から大きなスコープにすることは推奨していません。まずは2週間程度で実現できそうな最重要要件から取りかかり、その後にNice-to-have、つまり「あればよい」機能に着手していくようにしています。
（※）BPR（Business Process Re-engineering｜ビジネスプロセス・リエンジニアリング）とは｜企業の目的達成のために、既存の組織や業務フロー、情報システムを根本から見直し、再構築する「業務改革」のこと
ーー進め方の面では、どのような点に注意すべきでしょうか。
よくあるのが、IT主導で進めてしまうパターンです。これでは、事業部門側に主体性やアカウンタビリティーが生まれず、「導入させられている」と感じてしまいます。
だからこそ、要件定義や設計の段階からお客さまにも入ってもらい、「自分のプロセスを自分で変革する」というチェンジマネジメントの意識を持ってもらうことが必要です。
アメリカでは、自社内でITを導入・運用してきた企業も多い一方で、日本ではまだSIerへの依存度が高い。その中でFDEのような動きを実現するには、事業側を巻き込み、主体性を持ってもらうことが特に重要になっていきます。
ーー本番環境に近い形で進めるには、セキュリティーやガバナンスの壁もありそうです。
そうですね。最初から本番環境へアクセスできないことも多々あります。そのため、セキュリティーガバナンスの確認はFDEの動きとは別枠で捉え、並行して進める必要があります。
具体的には、サンドボックス環境を用意し、限られたユーザーと一緒にパイロット導入を進められる状態を作っておくことが重要です。そうした環境がないと、生成AIの検証に入る前に、いつまでもセキュリティーガバナンスの評価で停滞してしまいます。
しかも、評価が終わる頃には次のモデルが出ていたり、よりよい進め方が見えていたりすることもあります。その後にROIやビジネスバリューの検討を始めるとなると、半年かかってしまってもおかしくありません。
だからこそ、セキュリティーガバナンスの確認と、業務価値の検証は並行して進めるべきです。両面を同時に見ていくことで、実稼働に向けた判断をより早く、より現実的に行えるようになります。
ーー吉田さんはマネジャーとしてメンバーの採用やマネジメントもされています。具体的にどのような素質を持った人がFDEに向いていると思いますか？
顧客ファーストなマインドセットは、当然必須です。ただ、言われたことを鵜呑みにしてそのまま実装しようとするだけでは、真の意味でFDEは務まりません。
今の生成AI領域では、お客さま自身も「ぼんやりとした課題はあるが、それがどのようなソリューションになればエージェントで解決できるのか」を分かっていないケースが非常に多いんです。時には、「それならAIではなく従来のRPAでもいいよね」という依頼が出てくることもあります。
そこを包括的に捉え、「どうやって業務プロセスをエージェント化するか」を考える。システムアーキテクトとコンサルタントを組み合わせたような思考が求められます。
ーー実際の採用面接では、どのように人材を見極めているのですか？
25年7月からの8カ月間で、700枚ほどの履歴書を見て、実際に約70人の方と面接しました。その中で私が明確に優先して見ているのは、「自ら手を動かしているか」の一点に尽きます。
よく「こういう座学をしています」「AI関連の資格を取りました」とアピールされる方がいるのですが、そういった要素はまったく重視していません。この領域は進化が早すぎるので、資格自体が設計された時点で、すでに情報が1年ほど前のものになっているケースもありますからね。
私が面接で必ず聞くのは、「直近でどんなエージェントを作りましたか？」という質問です。座学や資格よりも、「自分の業務を効率化するために、先週こんなエージェントを自分で組んでみました」と語る人の話を、より深く聞きたくなります。
自分の興味の赴くままに、呼吸をするような感覚で生成AIを使い倒していること。それがFDEにとっての必須条件だと思います。
ーーAI自体が進化し、自律的にエージェントを構築できるようになれば、FDEという職種自体が不要になる未来もあるのでしょうか。
その可能性は十分にあります。というより、常に隣り合わせの危機感を持っています。
実は、このインタビューを受ける直前に行っていたチームミーティングでも、メンバーから「自分たちでエージェントの自動化を進めることによって、自分たちの首を絞めているのではないか？」という懸念が出たばかりです。
ツールと生成AIの組み合わせが完全に自動化されれば、FDEというポジション自体が、組織ごとなくなる日は来るでしょうね。
ですが、エージェントを作る作業自体は代替されても、FDEの本質的な価値はむしろ高まると私は考えています。
お客さま自身が何をしたいのか分かっていない状況で、その曖昧な課題を引き出し、「どうやってエージェントに落とし込むか」を設計する思考力。これは、AIが進化すればするほど人間側に求められるようになります。ロボットが正解を出せるようになっても、結局は「人間がどう納得して動くか」がビジネスの鍵になるからです。
かつて固定電話の交換手が自動システムに置き換わっていったのと同じように、テクノロジーの形が変わっても、最前線でビジネスと技術を橋渡しする役割はなくならないと思います。
世界中のエグゼクティブに向けてプレゼンを行う「エグゼクティブブリーフィング」にて、世界3,000人の中のトップスピーカー賞（Distinguished Speaker Award）を受賞した際の様子
ーー職種名が変わっても、その経験は生き続けると。
仮にFDEという職種がなくなったとしても、この環境で培った「凄まじいスピードでAIを現場実装し、スケールさせる」という経験を持つ人材は、市場から引く手あまただと思います。最近では「GTM（Go-To-Market）エンジニア」といった新しい職種も出てきていますが、FDEの経験はそうした領域にも直結します。
AIが社会に浸透していくこれからの時代において、FDEが担っている「現場実装力」の重要性は、形を変えながらさらに広がっていくのではないでしょうか。
取材・文／今中康達（編集部）
タグ
