結論: FDEは顧客現場に入り、業務理解と技術実装を橋渡ししてAI導入を本番運用までつなぐエンジニア職です。
FDE（Forward Deployed Engineer）の由来
この職種名を広めたのは、米国のソフトウェア企業Palantir Technologiesです。同社出身のエンジニアが公表したブログ記事などを通じて、FDE（Forward Deployed Engineer） という呼称が業界に広まりました。“forward deployed”（前線配備）という言葉自体の由来は軍事用語とする解説が複数見られますが、Palantir自身が明確に出典を示しているわけではなく、この点は伝聞情報として留保が必要です。確からしいのは、本社や後方から指示を出す立場ではなく、顧客の現場に直接入り込んで実装まで担う役割として位置付けられている、という点です。
近年、このFDEという呼称が日本でもIT系のニュースレターや採用ページで散見されるようになってきました。背景には、生成AIの登場で「動くデモ」と「本番運用に乗ったシステム」の距離が広がったという事情があります。デモは誰でも触れますが、業務に組み込んで成果を出すまでの工程は、従来のソフトウェアエンジニアリングともコンサルティングとも別物の設計を必要とします。この空白を埋める役割として、FDEが再注目されている形です。
本稿は士業事務所の文脈で、このFDEが何者で、AI導入にどう関係するのかを概念として整理することを目的としています。
FDEの定義 — 「1顧客に多数の機能を提供する」エンジニア
Palantirの公式ブログでは、FDEを「ソフトウェアエンジニアリング・顧客との協働・プラットフォーム開発の3つを混ぜ合わせる職種」と整理しています。その核心は、従来エンジニアとの対比にあります。
従来のソフトウェアエンジニアは「1つの機能を多数の顧客に届ける（one capability, many customers）」設計に最適化されてきました。プロダクトを汎用化し、スケールさせる方向を志向する職種です。これに対しFDEは「1つの顧客に対し多数の機能を提供する（one customer, many capabilities）」と表現されます。この対比表現はPalantirの公式ブログ記事「Dev versus Delta」が原典です。特定の顧客の業務文脈を深く理解し、その顧客固有の課題に技術を当てていく方向を志向しています。
コンサルタントとの違いも明示されています。コンサルタントが「単発の提言（one-off recommendations）」で終わるのに対し、FDEは顧客と長期に組んで実装まで担う、と整理されています。
日本での認知度はまだ高いとは言いがたい状況です。「客先常駐と何が違うのか」と混同されることもあります。客先常駐は工数・労働力の提供を主とするモデルである一方、FDEはビジネス成果の創出をスコープとし、課題発見から実装・改善までを一気通貫で担う設計になっている、というのが大きな違いです。
PoCが本番運用に乗らない理由
生成AIのデモは、ここ数年で誰でも触れるようになりました。しかしデモを業務に組み込んで成果を出すまでには距離があります。PoC（試験導入）が本番運用に乗らない理由として、次のようなパターンがよく挙げられます。
- 業務フロー側の前提が固まっていない: 誰が、いつ、どの書類で、何を判断しているか——「業務の前提」が暗黙知のままAIに置き換えようとすると、抜け漏れが起きやすくなります
- データが揃っていない: 過去案件・顧問先データ・帳票が、AIが扱える形に整っていません
- 権限と監査ログが設計されていない: 誰がどのデータをAIに投げたか、生成結果を誰が承認したか、という運用ルールが後回しになりがちです
- 責任の所在が曖昧: ベンダーは納品まで、コンサルは提言まで、AI企業はモデルまでとなりやすく、「成果が出るまでコミットする」役を誰も持っていない状況になりがちです
この「最後の1マイル」を埋める役割が、FDE的なポジションだと整理しておきたい場面です。
FDEが見る3領域 — 業務・技術・運用設計
FDEが横断する領域は、Business（業務）・Technology（技術）・Creativity（運用設計）の3要素として整理されることがあります（この3分類は複数の解説記事で共通して使われている整理であり、特定の一次情報が定めた正式名称というより、FDEというロールを説明する際に広く使われている枠組みです）。これを士業事務所の文脈に翻訳すると次のようになります。
業務（Business）。事務所の業務フロー（受任 → ヒアリング → 申請書類作成 → 提出 → 顧問先報告）のどこに時間がかかっているかを観察します。顧問契約・スポット案件・補助金申請といった収益構造から、AI化で実際に効くのはどこかを切り分けていきます。所長・スタッフ・顧問先それぞれの「何を変えてはいけないか」をヒアリングしていきます。
技術（Technology）。RAG（Retrieval-Augmented Generation）で過去案件・通達・判例・社内マニュアルを参照させる設計、会計SaaS / 法務SaaS / 行政手続きAPIとの連携、LLMの確率的な振る舞いを前提とした、レビュー・差し戻し・ログ取得の組み込みを担います。
運用設計（Creativity）。「自動化すべきこと」と「人間が判断すべきこと」の境界をどこに引くか、守秘義務・個人情報・利益相反チェックの運用ルール、スタッフが安心して触れるようにするためのオンボーディング設計を扱います。
3領域のうち1つでも欠けると、本番運用に乗りにくくなる、というのがFDEという役割設計の基本的な考え方です。
FDEとITベンダー・コンサル・SESの違い
似た役割と混同されやすいので、整理しておきます。
| 区分 | 主たる成果物 | コミット範囲 | AI／LLM適性 |
|---|---|---|---|
| ITベンダー | システム納品 | 要件定義に書かれた範囲 | 決定論的システムが主 |
| コンサルティングファーム | 提言書・戦略書 | 実装前まで | 戦略レイヤー |
| 情シス（社内IT） | 社内システム運用 | 自社のみ | リソースが限られがち |
| SES（客先常駐） | 工数提供 | 指示された作業 | 案件次第 |
| FDE | 業務成果（KPI改善・本番運用） | 課題発見〜実装〜定着 | LLMの確率的動作を前提に設計 |
重要なのは、どれが正しい・優れているという話ではないという点です。基幹システムの更改ならITベンダーが向きます。経営戦略の整理ならコンサルティングファームが向きます。FDEは、「AIを含む不確実なシステムを、現場業務に溶け込ませる」というフェーズで特に役に立つ、というポジショニングになります。
士業事務所でFDE的役割が必要になる具体場面
抽象論だけだとイメージしづらいので、士業事務所の文脈でFDE的支援が効きやすい具体場面を整理しておきます。
- 顧問先データのRAG化: 過去の決算書・議事録・契約書をAIに参照させたいが、データの置き場所・権限設計・個人情報の扱いが固まっていない場面です
- 会計 / 法務SaaSとのAPI連携: 仕訳・チェック・異常検知を自動化したいが、APIスキーマ理解・例外処理・人によるレビューフローを誰が設計するか定まっていない場面です
- 監査ログ・操作ログの整備: AIを使った業務が増えてきたものの、誰が・どのプロンプトで・どんな出力を承認したかを追跡できる仕組みがない場面です
- 個人情報・守秘義務の取り扱いルール策定: 公的機関からは、生成AI利用にあたって入力する個人情報の必要性・適法性を事前に確認すべきだとする注意喚起が出ています。詳細は公式情報を確認のこと
- PoCで止まっているプロジェクトの本番移行: 精度は出ているものの、現場のワークフローに統合できていない場面です
これらは、ツール選定だけでは解決しないテーマです。業務・技術・運用設計を横断する判断が必要になる、という共通項を持っています。
AI導入で守秘義務・監査ログを最初から設計するには
士業事務所がAIを導入する場面では、便利さの裏側で意識しておきたい論点があります。これらを後付けでなく初期設計から組み込めるかどうかが、FDE的アプローチと従来型ベンダー納品の分岐点になります。
- 守秘義務: 弁護士法・税理士法・社労士法・行政書士法等は、それぞれ守秘義務を課しています。生成AIに顧問先の固有情報を投げる前に、入力する情報の範囲・保存期間・第三者提供の有無を確認しておきたいところです
- 個人情報の入力: 公的機関は、生成AIサービスへの個人情報入力にあたっては、利用目的の達成に必要な範囲かを事前に確認するよう求めています。詳細は公式情報を確認のこと
- 権限設計: 誰がどの顧問先のデータにアクセスできるか、AI経由でもアクセス制御が効くようになっているかを確認しておきたい論点です
- 監査ログ: AIへの入力プロンプト・生成結果・承認者の記録が後から追えるかを確認しておきたい論点です
- モデル提供事業者の契約: API経由のデータが学習に使われない契約（オプトアウト・エンタープライズプラン等）になっているかを確認しておきたい論点です
- 生成結果の最終チェック責任: AIの出力をそのまま顧問先に渡さず、誰がレビューするかをワークフローに組み込んでいるかを確認しておきたい論点です
AIで完全自動化できる業務というよりは、「専門家の判断をAIが支援する」前提でワークフローを組む、というスタンスが現実的な落とし所になります。
日本でFDEという職種は定着するか
FDEという呼称は、現時点では実態に対して語が先行している側面もあります。海外発の文脈と、日本の士業事務所の文脈では、抱える顧客の規模・取り扱う情報の機微度・予算スケールが大きく異なります。「FDE的役割」を担う人材が、日本の士業向け市場で十分な供給を持つかどうかは、まだ観察途中の論点だと考えています。
それでも、業務・技術・運用設計の3軸を横断して「最後の1マイル」を走り切る役割が必要だ、という構造的な認識は、士業事務所のAI導入文脈で確実に立ち上がってきています。役割の呼称が定着するかどうかとは別に、PoC止まりや、責任の所在の曖昧さに悩む段階で「3軸横断の担い手がいるか」を点検することは、導入判断の有効なチェックポイントとして機能すると見ています。
この概念を、ShigyoAIが実際に税理士法人・弁護士法人でどう実装しているかは、士業事務所のためのFDEモデルで具体的な設計パターンとして扱っています。
参考
- Palantir Technologies「Dev versus Delta: Demystifying engineering roles at Palantir」（“one capability, many customers” 対 “one customer, many capabilities” の対比表現の原典）: https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-de7f6dea6eb2
- The Pragmatic Engineer「Forward Deployed Engineers」（2025-08-12）: https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日発出）: https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/