【ビジネスブログ】人とAIの境界を引き直す ー FDEという仕事

01. はじめに

こんにちは。GienTech Consulting Japan（以下 GCJ）で新規事業の検討、最近は AI ネイティブな事業づくりに重心を置いている岩佐です。

前回記事では生成 AI にどのようなツールがあり、何ができるのか、また何に気をつけるべきなのかなど、実際にツールを活用しながら確かめていく過程を「生成 AI で法令対応の自動化システムを作る」というテーマを設定し、連載形式でお伝えしました。

※前回記事は以下

Wantedly（ウォンテッドリー）はたらくを面白くするビジネスSNS

Wantedlyは、運命のチームや仕事に出会えたり、人脈を広げ、ビジネスの情報収集に使えるビジネスSNSです。

https://www.wantedly.com/companies/gientech-consulting/post_articles/1062089/preview?token=0f02247c47c31b3b85ef4e552eafd1a5

今回はここ 1 年ほどで目にする機会が増えた FDE という仕事について 1 話完結でお伝えしていきます。

海外の AI 企業の求人ページに 「Forward Deployed Engineer」 という見慣れない職種が並び始めました。Anthropic、OpenAI、Cursor、そして Google Cloud までもが、この役職の採用を急ピッチで増やしています。2025 年の 1 年間で需要は 800% 以上伸びたと報じられ※6、Anthropic は Applied AI チームを「年内に 5 倍に拡大する」と明言しています※6。
日本でもIT企業を中心に同様のポジションの採用が活性化しています。

聞き慣れない名前ですが、やっていることは要するに 「お客様の業務の中まで入っていって、そこに AI を埋め込み直す仕事」 です。コードを書いてプロダクトをつくる仕事でもなければ、コンサルとして提案書を書く仕事でもありません。両者の中間にある、新しいかたちの業務変革職です。

長年お客様の業務改革を支援してきた立場から眺めると、これは突然出てきた職種ではなく、「業務を変える」という仕事の歴史のなかで、はっきり次のステージとして位置付けられるものとして見えてきます。

本稿では、なぜ今 FDE という仕事が注目を集めているのか、それが過去の業務改革とどう連続していて、どこから不連続なのか、そしてこの新しい段階にどう関わっていくつもりかを整理します。

02. そもそも、企業は何のために業務を変えてきたのか

企業が業務のやり方を変えてきた理由は、それほど多くありません。

• 売上を伸ばすため — 新規顧客の獲得、客単価の向上、新規事業の立ち上げ
• コストを下げるため — 人件費、物理コスト、ムダの削減
• リスクを抑えるため — 属人化の解消、コンプライアンス、事業継続性
• 競争力を保つため — スピード、差別化、参入障壁

このゴールは、おそらく数十年単位で本質的には変わっていません。変わってきたのは、そのために使える手段のほうです。そして手段は、はっきりと段階を踏んで進化してきました。

03. 手段は段階を踏んで進化してきた

経済産業省は 2020 年の「DX レポート 2」で、企業のデジタル化を 3 つの段階に整理しています。

デジタイゼーション — アナログ・物理データのデジタルデータ化

デジタライゼーション — 個別の業務・製造プロセスのデジタル化

デジタルトランスフォーメーション（DX） — 組織横断/全体の業務・製造プロセスのデジタル化、"顧客起点の価値創出"のための事業やビジネスモデルの変革

（※1）

この整理に沿うと、企業が業務を変えてきた手段は、おおむね次のような階段を上ってきたと言えます。

Stage 1: とりあえずデジタルにする

紙の帳票を電子化し、対面の打ち合わせをオンラインに移し、押印を電子サインに置き換える。検索可能・保管容易・遠隔協働を取りに行く段階です。

ここでの主役は OA ソフトと電子化ツールでした。業務のやり方そのものはほとんど変わりません。アナログをデジタルに置き換えただけ、と言ってもよい段階です。

Stage 2: デジタル起点で業務を組み直す

次に来たのが、デジタルを前提に業務プロセスそのものを設計し直す段階です。RPA で定型業務を自動化し、SaaS でワークフローを統一し、データ基盤に情報を集めてダッシュボードで見えるようにする。

ここで初めて、**「もう紙に戻る前提では作らない」**という発想が標準になりました。業務スピードは上がり、データは溜まり、人が手で集計していたレポートの大半は不要になりました。それでも、最終的な意思決定は人が行う前提のままです。

Stage 3: 業務そのものを変革する（DX）

そして DX です。Stage 1 と Stage 2 を踏まえたうえで、組織横断で業務を再設計し、顧客体験そのものを作り直し、必要なら事業モデルまで変える。データドリブン経営、アジャイル、新規事業創出、サブスクリプション化。ここ 5〜7 年、多くの企業がここに挑戦してきました。

Stage 3 は全社的に完了した段階ではなく、2025 年時点でも多くの企業がまだ途上にあります※2,※3,※4。それでも、業務改革の地平としては、ここまでがこれまで語られてきた段階でした。

Stage 4: 判断と思考まで分解して AI に渡す（今ここ）

ところがこの 1 年ほどで、まったく違うタイプの段階が見えてきました。

それは、業務の入出力をデジタル化することではなく、業務の中身（人が頭の中でやっていた判断や思考）まで分解して AI に渡す段階です。

Stage 1〜3 で、企業は業務の "外側" を変えてきました。紙をデジタルに、プロセスをデジタル起点に、組織を顧客起点に。けれども 業務の "中身" — 何をどう判断し、どう考えて結論を出すか — のレイヤーには、本質的にはまだ触れていませんでした。データを見て決めるのも、現場の感覚で判断するのも、最後は人がやってきたのです。技術的に踏み込めなかったから、というより正確には、踏み込むには判断材料をすべて人が翻訳して入力し直す必要があり、コストに見合わなかったからです。

生成 AI がここを変えました。雑然とした記録、口頭のニュアンス、断片的な観察 — これまで構造化できなかった人間の判断材料が、そのままモデルへの入力になります。判断プロセスを段階に分解し、それぞれに AI を割り当て、最終ジャッジだけ人に残す、という構成が現実的になりました。これが Stage 4 の核心です。

しかもこれは、もう一部の先進企業だけの話ではありません。McKinsey の "State of AI 2025" によれば、23% の企業がエージェント型 AI システムをすでに本番運用に展開しはじめており、39% が実験段階に入っていると報告されています※8。BCG はさらに踏み込んで、大企業の 40% 以上が agentic AI の本格展開フェーズに入っていると推計し、2026 年は分散したパイロットからエンタープライズ全社展開へのシフトの年になるとしています※9。Stage 1〜3 の進捗が頭打ちになる一方で、Stage 4 だけは今この瞬間も急速に立ち上がっている、というのが世界の現状です。

重要なのは、Stage 4 は前段の完了を待ってから進む段階ではないということです。Stage 1〜3 を未完で抱える組織でも、並走で着手することは可能です。ただし、業務側の作り変えと組み合わせなければ効果は限定的で、McKinsey の調査では業務フローを根本から再設計した企業は 21% にとどまります※8。

04. 生成 AI は "判断・思考" レイヤーまで分解できる

生成 AI が単なる文書生成ツールではないことは、もう多くの方が体感されていると思います。重要な変化は、「人が頭の中でやっていた意思決定プロセスを、段階に分解して AI に任せる」ことが現実的になったことです。

たとえばあるベテラン担当者の判断プロセスは、こう分解できます。

1. 関連する過去事例を思い出す
2. 今回のケースと比較して類似度を見積もる
3. 業界の定石に照らす
4. 自社固有の事情で補正する
5. 結論を出す

これまではこの 1〜5 が「ベテランの頭の中」というブラックボックスでした。今は、1 は検索エージェント、2 は類似度評価モデル、3 はドメイン LLM、4 は社内データを参照する RAG、5 は最終 LLM、という形に 分解して AI に渡すことができます。

ただし、ここで決定的に重要なことがあります。

AI に渡すには、業務側を作り変える必要があるということです。

ベテラン担当者の頭の中にしかなかった情報を AI に渡すには、判断材料が読み取れる形で残っていなければいけません。会議の議論、現場の観察、雑談の中での示唆 — それらが文字や映像として記録されていなければ、AI は学習も推論もできません。つまり、業務プロセスの上流側を「AI に渡せる形」に作り変える側に重心を置き、その作り変えと AI の導入を並走させて反復させていくことで、AI が活きてきます。

これは McKinsey が 2025 年の "State of AI" レポートで強調している論点と一致します。

「エンタープライズレベルで AI のインパクトを生めるかどうかの最強の予測因子は、AI を導入する際にワークフローを根本的に再設計したかどうかである」

（※8）

効果を出すには、業務側を AI に合わせて作り変える。この「作り変え」を現場で実装する仕事こそが、Forward Deployed Engineer です。

05. 具体例: 業務変革像はこう描ける

ここまで整理した Stage 4 の業務変革像を、2 つの業界に落とし込んで具体的に描いてみます。

例 1: 製造業の現場

熟練工の判断を AI に乗せたいとき、多くの企業は「OJT 動画を撮りましょう」から入りがちです。しかし熟練工が判断するときに見ている細部 — 工具の刃先、製品の色味、機械の異音 — は、首からぶら下げたカメラでは捉えられません。

ここで FDE はこう提案します。全員の目元にウェアラブルカメラを設置し、視線データと一緒に作業を記録する。会議は全文文字起こし、判断の根拠になった会話は意思決定ログとして残す。これらが揃って初めて、AI は熟練工の判断ロジックを学習できる素材を手にします。

録画に加えて、「熟練工が見ているもの・聞いているもの・口にしていること」を構造化して保存できる業務プロセスへ作り変えることがセットになります。

例 2: バックオフィスの意思決定

経理や法務、購買のような領域では、ベテランが「これは通していい」「これは差し戻し」を判断するシーンが大量にあります。判断の根拠は、過去の類似案件、社内ルール、暗黙のリスク許容度の組み合わせです。

FDE はここで、過去の判断ログを構造化し、判断根拠を毎回明示するワークフローに作り変えます。最初は AI に "判断のドラフト" を作らせて人がレビューする、次に類似度の高いケースは AI が承認まで進める、徐々に判断の境界を AI 側に寄せていく。業務プロセスを変えずに AI を入れても何も起きません。

そして、現に手を動かしている試み

足元でも、手の届く範囲で「業務を AI に渡せる形に作り変える」実験を既に進めています。

社内ツールを実運用品質に持ち上げる試行錯誤 — 短時間でラフに組んだ社内ツールのプロト版を、ユーザーシナリオの言語化 → シナリオ駆動の改修 → AI コードレビューによるロジックの粗潰し → 自動テストでの網羅検証 → 群体エージェントによる探索テスト、という順で実運用に耐える品質まで持ち上げています。実運用の規模で言えば、週あたり 20 件超の PR マージと、25 名分のペルソナで動かす Playwright の自動テスト 11 サイクル。これを 人手だけで回そうとすると、PR レビューに約 0.5 人月、ペルソナテストに約 1.5 人月、合わせて月 2 人月相当の品質保証工数が必要になる規模です。それを AI コードレビューと自動テスト、群体エージェントが担う形に作り変えたことで、人の関与はシナリオ設計と最終ジャッジに絞り込まれ、実工数は約 10 分の 1にまで圧縮できています。これは「人がやっていた品質保証の判断」を AI に渡せる形に作り変える、Stage 4 の小さな実例です。

AI ネイティブな事業のかたちを探る実験 — 「事業運営そのものを、最初から AI エージェントの組織に分担させたらどうなるか」を試しています。Growth / Data / Product Delivery / User Advocate / Cost Controller / Org Infra の 6 責任者体制を組み、意思決定の分担と集約を回す。人間側はあえて一人だけで、AI エージェントの組織がどこまで事業運営を担えるかを試しているトライアルです。やってみて分かるのは、エージェントを並べただけでは動かないということ。判断材料の渡し方、責任範囲の線引き、最終ジャッジの吸い上げ方といった「事業運営の仕組みそのもの」を AI に渡せる形で設計してはじめて、エージェント組織が機能します。既存業務を作り変えるのとは逆向きに、AI ネイティブな事業の輪郭を実装側から逆引きする試行錯誤です。

共通しているのは、業務／事業の仕組みそのものを作り変える側に重心を置き、その作り変えと AI の導入を並走させて反復していくということです。

これらはすべて「単に AI を導入する」のとは違う仕事です。業務／事業の仕組みを AI に合わせて作り変える。これこそが Stage 4 の本丸です。

06. これを担う仕事 = Forward Deployed Engineer

FDE = Forward Deployed Engineer。職種としての起源は 2010 年代の Palantir ※5,※6 ですが、生成 AI の登場で、いま急激に評価され直しています。

• 2025 年に求人数が 800% 以上増加※7
• Anthropic は Applied AI チームを 年内に 5 倍に拡大する方針※7
• OpenAI、Cursor、Google Cloud、Microsoft、AWS が同じ人材を取り合う構図※6
• コンサルファーム側も動き出しており、Deloitte は独自に FDE 部門を立ち上げ※14、OpenAI は大手 4 社と FDE 連携を発表※15

理由はシンプルで、汎用の LLM をお客様の業務に "馴染ませる" 翻訳役が圧倒的に足りていないからです。モデル単体は強力ですが、それを Stage 4 のレベルで業務に落とし込むには、お客様の業務の手触りを掴み、業務側を作り変え、AI を埋め込み、運用に乗るまで責任を持つ人が必要になります。

Forward Deployed という言葉のとおり、これは 現場に "前進配備" されたエンジニアです。

07. FDE に必要なスキルセット

このロールに必要なものは、過去の業務改革コンサルタントと、現代のソフトウェアエンジニアの 両方の素養を半分ずつ持っていることだと整理できます。

これは思いつきの整理ではなく、Anthropic / OpenAI / Google Cloud / Databricks / Deloitte といった主要企業の FDE 公式求人で共通して要求されている職能です。たとえば Anthropic の Applied AI（FDE）求人では、同じ職務記述書の中に次の 2 つが並んでいます※10。

顧客との発見対話（discovery）を進め、技術概念を翻訳できる強いコミュニケーション能力

LLM の本番運用経験（高度なプロンプト設計、エージェント開発、評価フレームワーク）

Google Cloud の FDE 求人はさらに踏み込んだ言い方をしていて、この役割を 「現場に組み込まれたビルダー」 と呼びます。先端 AI と本番品質のあいだの隔たりを埋め、コードを書き、デバッグし、顧客環境で一緒に作りきる役割、という定義です※12。

両側で求められる職能を表に並べると、次のように対応します。

真ん中の 「+」 は、「両方を等しく持つ」という意味です。どちらか片側に偏った人材ではなく、左右両側の経験と素養が同居していることが要件になります。これらの項目は、Anthropic / OpenAI / Google Cloud / Databricks / Deloitte の FDE 公式求人で繰り返し挙げられているものです※10,※11,※12,※13,※14。

両側それぞれに、想像より深い

この組み合わせは、表だけ見ると「業務改革とエンジニアリングを両方やる」だけに読めます。実際には、それぞれの側で求められる水準がかなり高い領域です。

業務改革側で求められるのは、改革を主導する立場で「何を残し、何を外すか」を判断してきた経験です。今ある業務の複雑さは、ほとんどの場合「歴史の産物」になっています。「以前こういうミスがあったから、ここに確認を足した」「あの案件で問題が出たから、この承認を増やした」— そうやって長年積み上がった分岐や確認が、業務の中に大量に埋め込まれている。冷静に並べれば、AI 起点で組み直したときに不要になるものは少なくありません。それでも「不要だ」と言い切るのは現場にとって重い判断で、外したあとに同じ問題が再発すれば、外した人の判断責任が問われます。この力学があるので、薄々「もう要らないのでは」と思われている確認項目が、誰も触らないまま残り続けやすい状況になります。ここを 業務の目的に立ち返って解きほぐし、波及と歴史を関係者と一緒に整理し、決着までつけていく推進力が要ります。

エンジニアリング側で求められるのは、AI を機能として後付けで載せるのではなく、AI を前提に業務や事業の設計を考え直す構えです。AI を呼び出す部分だけを書いても、その手前で人がやっていた判断材料の整理、構造化、責任範囲の引き直しがなければ、AI が扱える素材にはなりません。どこを AI に渡し、どこを人に残し、どう接続するか — それを設計図の段階から組み直す感覚が必要になります。

表面的なスキル表の裏側で、この両側それぞれの深さが、実は最も差が出やすい部分です。

これまで業務改革・DX に従事してきた方にとっては、自分の経験が大きく活きる新しいキャリアです。逆に、AI ネイティブのエンジニアにとっては、「コードを書く存在」から「現場を変える存在」へと役割を広げる機会でもあります。

興味深いのは、この職種が これまで分断されてきた「コンサル」と「エンジニア」を、業務変革の文脈でひとつに溶かしつつあることです。お客様の課題に深く入り込み、業務を作り変え、AI を埋め込み、運用に乗るまで責任を持つ。これは伝統的にどちらかひとつの職種では完結できなかったタイプの仕事で、生成 AI の登場ではじめて「ひとりの人が責任を持つ」やり方が現実味を帯びてきました。

08. まとめ — 人と AI の境界を引き直す仕事

FDE という仕事は、突然降って湧いた流行職種ではなく、ずっと続いてきた業務改革の系譜が、生成 AI の登場でやっと次の段階に到達した姿だと考えています。

生成 AI の登場で、これまで人の頭の中にあった 判断と思考のレイヤー に、初めて手が届くようになりました。

これを「単に AI を入れる」ではなく、業務側の作り変えに重心を置きながら、AI の導入と並走・反復させていく仕事 — それが Forward Deployed Engineer です。「FDE」という呼び名が日本で定着するかどうかは分かりませんが、この種の仕事はもう確実に必要とされていて、これから増えていきます。

自社の業務改革プログラムに FDE 的役割をどう組み込むか — 社外パートナーと組むのか、社内に育てるのか。どの構えを取るにせよ、最初の一手は 「業務側を作り変えれば AI に手渡せる」判断プロセスを 1 つ書き出してみる ことです。同時に、それを現場で担える人材を社内に持つ準備も、並行で始めることになります。

参考文献

• ※1 経済産業省「DX レポート 2（中間取りまとめ）」本文 PDF（2020/12/28）
• ※2 経済産業省「DX レポート 〜IT システム『2025 年の崖』克服と DX の本格的な展開〜」本文 PDF（2018/9/7）
• ※3 日経クロステック「実現してしまった『2025 年の崖』、2026 年は本物の DX のさらなる推進を」
• ※4 Palantir Blog "A Day in the Life of a Palantir Forward Deployed Software Engineer"
• ※5 The Pragmatic Engineer Newsletter "What are Forward Deployed Engineers, and why are they so in demand?"
• ※6 eWeek "Why Forward-Deployed Engineers Are in High Demand"（OpenAI / Anthropic / Cohere の動向）
• ※7 McKinsey "The state of AI in 2025: Agents, innovation, and transformation"
• ※8 BCG "The $200 Billion Agentic AI Opportunity for Tech Service Providers"（2026）
• ※9 Anthropic "Forward Deployed Engineer, Applied AI" 求人ページ
• ※10 OpenAI "Forward Deployed Engineer (FDE) - NYC" 求人ページ
• ※11 Google Cloud "Forward Deployed Engineer, GenAI, Google Cloud" 求人ページ
• ※12 Deloitte US "Forward Deployed Engineering" サービスページ
• ※13 OpenAI "Introducing Frontier Alliances" 公式アナウンス（2026/02/23、BCG / McKinsey / Accenture / Capgemini との多年連携）

最後に｜一緒に働く仲間を募集しています

GCJでは、現在コンサルタントを積極的に採用しています。
「仕事に本気で向き合いながらも、自分らしい働き方を選べる環境で働きたい」
「フラットな環境で、自分らしく成長したい」
そんな想いを持っている方は、ぜひ一度お話ししませんか？
少しでも気になった方は、気軽にお問い合わせください。