PalantirのFDE・DS・GTMとは：コンサル・常駐SEとの違い
この記事で学べること
- PalantirのFDE・DS・GTMの役割と連携方法
- コンサルティング・常駐SE・受託開発とFDE型チームの違い
- 2026年8月時点の、世界と日本におけるAI導入の職種・サービス
- 個別開発の増加、権限不足、特定の人への依存と、その対策
- 自社や外部パートナーの体制を確認するための判断表
FDE・DS・GTMの役割分担と連携
PalantirのFDE・DS・GTMは、顧客の業務課題を見つけ、実際に使えるシステムを作り、その経験を製品改善や次の導入に生かすための役割・活動です。担当する仕事は、次のように整理できます。[1][2][3][4]
- **FDE（Forward Deployed Engineer）**は、顧客の現場で課題を把握し、システムを設計・実装するエンジニアです。技術面を主に担当します。
- **DS（Deployment Strategist）**は、解くべき業務課題を定め、導入と利用定着を進める担当者です。業務と利用者の側から導入を支えます。
- **GTM（Go-to-Market）**は、製品をどの顧客に、どのように届けて利用を広げるかを決める活動です。販売、パートナーとの協業、導入方法を扱います。FDEやDSと並ぶ一つの職種名ではありません。
こうした仕事は、コンサルタントや常駐SE（顧客先で開発・保守・運用などを支援するシステムエンジニア）とも重なります。そのため、職種名だけでは、どこまで任せられるのかを判断できません。
公開資料に基づく役割比較であり、著者が顧客の現場で観察した事例や導入効果の実測は含みません。この記事では、責任範囲や成果物を比較し、FDE型が向く条件と導入時の確認事項を整理します。最後まで読むと、自社や外部パートナーの体制にFDE型を取り入れるべきか、具体的な仕事の分担から判断できます。
PalantirのFDE：顧客支援と製品開発の両立
PalantirはFDEを、顧客先で働く職種であると同時に、製品を改善するための方法として説明しています。システム構成や設計の考え方をまとめた公式Architecture Centerでは、エンジニアが現場の課題を理解し、基盤となる製品の開発チームと連携することを重視しています。現場で得た意見や気づきを、複数の顧客が使える製品機能に反映するためです。[1]
採用情報での職種名は、Forward Deployed Software Engineer（FDSE）です。FDE型の働き方でソフトウェア開発を担います。顧客の重要な課題を理解し、データを使った解決策を設計・実装します。システム構成の検討、大規模データの整備、業務アプリの開発に加え、経営層との対話やチーム方針の策定も担当範囲に含まれます。[2]
少人数のチームで、試作から実際の業務でシステムを使う本番運用まで責任を持ちます。必要に応じて、自らコードを書くことも前提です。コードは、ソフトウェアの動作を記述したプログラムです。[2]
以降では、人を指すときは「FDE」、この働き方や体制を指すときは「FDE型」と表記します。顧客先に常駐しているかどうかだけでは、FDE型かを判断できません。
Palantirの業務システムを理解するうえでは、Ontology（注文や在庫などの業務データ、それらの関係、実行できる操作と権限をまとめて扱う仕組み）の考え方も参考になります。詳しい考え方は、シリーズ第1回のPalantir Ontologyの記事で整理しています。
DS：業務課題の特定と利用定着
DSは、データを使ってどの業務をどう変えるべきかを考える役割です。Palantirの採用情報では、現場の利用者が何を判断する必要があるのかを確かめ、その判断に必要なデータを見つける仕事が挙げられています。FDEと協力して安定したデータ処理を作り、利用者の業務手順を設計し、研修や経営層への説明まで担当します。[3]
FDEとDSの違いは、主に責任を持つ仕事の範囲です。DSにもプログラミングやデータ分析ツールの使用経験が求められるため、「FDEは技術職、DSは非技術職」とは分けられません。[3]
FDEは、本番で動くシステムの構成やコードに重点を置きます。DSが重点的に考えるのは、次のような問いです。
- どの業務判断を変えると、成果につながるのか
- 誰がどの場面で使うのか。今の業務手順は、どこで止まっているのか
- 利用状況、業務の数値、利用者の行動のうち、何を見て成功を判断するのか
- 現場から出た要望を、製品改善や次の導入にどう生かすのか
DSを進捗や日程の管理だけに限定すると、利用者の行動を観察し、解くべき課題を見直す役割が抜けてしまいます。かといって、業務の理解や関係者との合意形成をFDEだけに任せると、開発にも利用定着の支援にも十分な時間を割けなくなります。
GTM：短期検証から販売・利用拡大まで
GTMは、対象となる顧客の課題を選び、短期間で効果を示し、契約や利用拡大につなげる活動です。Palantirの2025年の年次報告書では、その方法としてAIP Bootcamp（PalantirのAI基盤を使い、顧客と短期間で業務の仕組みを作る共同作業）、開発者が利用を始めるための入口、顧客に直接対応するチーム、業界パートナーが挙げられています。[4]
AIP Bootcampでは、実際の顧客データを使い、数日以内に業務手順を作ります。[4] AIPはArtificial Intelligence Platformの略で、AIを業務に組み込むためのPalantirの製品です。
公開資料によると、顧客とPalantirのエンジニアが同じ場で作業し、重要な業務へのAIの適用、最初のユースケース（AIを使う具体的な業務や場面）、利用者の研修まで扱います。[5] 製品の動作を見せるだけでなく、技術的に実現できるかと、利用者の仕事に合うかを同時に確かめます。
ここでは、これらの公開資料をもとに、次のような役割分担と連携を提案します。GTMでは「どの顧客に、どのような効果を届けるか」を考え、DSが現場の課題と導入に必要な条件を具体化します。FDEは、それを実際に使えるシステムとして実装します。
導入後の利用結果は、DSとFDEから製品開発・研究・GTMの担当者へ共有されます。その結果をもとに、製品機能、評価方法、導入手順、対象市場を見直します。営業から開発へ案件を引き渡して終わるのではなく、次の製品改善と導入まで続く関係です。
図の「価値仮説」は、顧客に届けたい効果の見込みを指します。「評価・監視」は期待どおり動くかの確認と稼働状態の見守り、「再利用機能」は他の顧客にも使える処理や画面、「導入手順」は作業を進める順序です。
コンサル・常駐SEとの違い：成果物・責任範囲・経験の生かし方
コンサルタントや常駐SEの仕事は、会社や契約、案件によって大きく異なります。職種名だけで優劣を決めることはできません。比較するときは、何を成果物とし、実装や運用のどこまで責任を持ち、現場で得た経験を何に生かすかを確認します。
次の表は、その違いを確認するための整理です。
| 体制 | 主な責任範囲 | 代表的な成果物 | 実装・運用との関係 | 現場の経験を生かす先 |
|---|---|---|---|---|
| 戦略・業務コンサル | 課題整理、選択肢の提示、変革計画、合意形成 | 分析、提言、業務設計、実行計画 | 実装を別チームへ引き渡す場合も、実行まで伴走する場合もある | 顧客の変革計画と自社の方法論 |
| 常駐SE・契約範囲に沿う開発支援 | 契約で定めた開発、保守、運用、問い合わせ対応 | 設計、コード、設定、運用記録 | 顧客の指示系統や担当範囲に沿って継続対応することが多い | 顧客のシステムと所属会社の知見 |
| FDE型チーム | 業務成果につながるシステムの本番運用と導入の完了 | 業務で使えるシステムと手順、コード、評価、監視、別の顧客にも使える処理や画面 | 小チームで課題発見から本番運用、利用定着まで改善を繰り返す | 顧客の業務に加え、自社製品、評価方法、導入手順 |
FDE型の特徴は、次の三つを短い間隔で繰り返す点にあります。
- 現場で解くべき課題と、成功とみなす条件を見直す
- 実際の業務で使えるシステムを作り、利用結果を測る
- 案件で得た経験を製品改善や、別の導入でも使える機能に変える
コンサルとエンジニアの仕事を一人に集めれば成立するわけではありません。特に三つ目がなければ、優れた顧客対応ができても、FDEと名乗るだけで製品事業を拡大するのは難しいでしょう。
反対に、常駐していなくても、顧客と密にやり取りしながら改善を繰り返し、その経験を製品に反映できれば、FDE型の働き方は成立します。
世界のAI企業におけるFDE採用と役割の変化
2026年8月の調査では、Palantir以外のAI企業でも、試行から本番運用までを担う職種の募集が見られました。OpenAIの東京FDEは、課題発見、技術的な対応範囲の決定、システム設計、実装、本番展開まで一貫して担当します。利用状況や評価結果を、製品やAIモデル（学習した内容をもとに予測や文章作成などを行うAIの中核）の開発計画に反映することも役割に含まれます。[6]
Anthropicも米国・欧州でFDEを募集しています。東京では、Applied AI EngineerやApplied AI Architect（顧客の業務に合わせてAIの実装やシステム設計を担う職種）など、異なる名称でAI導入に関わる人材を募集しています。[7]
PalantirのForward Deployed AI Engineer（生成AIの戦略と実装を担うFDE）は、顧客の生成AI導入に責任を持つ役割です。LLM（大規模言語モデル：大量の文章を学習し、文章の生成や処理を行うAI）を使う業務の仕組みを本番運用へ進め、その経験をAIPの改善に生かします。[8] これらの役割を踏まえると、従来のデータ統合や業務アプリ開発に加え、AIモデルの評価、失敗時の制御、生成AIの使いやすさも検討すべき項目と考えられます。
実装作業の一部を、AIが担う動きもあります。Palantirは2026年3月、製品機能「AI FDE」を一般提供しました。日常的な言葉で指示すると、データ処理、Ontologyの編集、Function（計算やデータ加工などの処理をまとめ、再利用できるようにしたもの）の作成などを行います。[9]
ここからは、仕事の重点が移るという見方ができます。定型的な構築作業をAIへ移せる場合、人のFDEには、解くべき課題の選定や、動作確認に使う具体例と期待する結果の設計がより重要になります。権限の設定、想定外の動作への対応、利用者との合意、再利用の判断も対象です。これは公開された機能からの推論であり、担当者の工数配分が実際に変わったことを測定した結果ではありません。
こうした人材への需要の背景には、AIを試す段階と全社に広げる段階の隔たりがあります。McKinseyの2025年調査では、回答企業のほぼすべてがAIを利用する一方、約3分の2は全社規模での拡大を始めていませんでした。[10] FDE型チームには、既存データ、業務手順、セキュリティ、利用者の行動を踏まえ、実際の業務で使える状態まで導入を進める役割があります。
日本でのFDE採用・サービス展開と社内体制の課題
2026年8月30日の調査では、Palantirの東京の募集に、政府向けFDSEと商用・政府向けDSが含まれていました。[11] OpenAIの東京FDEも、日本語と英語の両方に加え、顧客対応を含む技術導入、本番用のコード、生成AIシステムの経験を要件としています。[6]
日本企業でもサービスの展開が始まっています。LTSは2026年7月、コンサルタントとAI・ソフトウェアエンジニアが一つのチームとなり、戦略から本番運用まで担うFDEサービスを発表しました。[12] Hmcommも2026年5月にFDE事業の開始を公表しています。[13]
ただし、外部の専門人材を活用するだけで、社内の体制が整うわけではありません。IPA（情報処理推進機構）の「DX動向2025」は、日本ではAI関連人材が種類を問わず不足していると報告しています。一方、AIを使うソフトウェアやシステムを実装できる開発者について、40.7%の企業が「自社には必要ない」と回答しています。[14]
同調査では、試用や検討を含め、生成AIに前向きに取り組む日本企業は5割弱で、部署の業務手順に組み込む利用も米国・ドイツより低い状況でした。[14] この状況でFDE型を取り入れる際には、二つの課題があります。
一つは、外部FDEへの依存です。AI開発者を社内に置く必要がないと考えたまま外部人材を呼んでも、利用部門が効果の判断基準や運用責任を引き取る体制は整いません。
もう一つは、従来の常駐支援の名称を変えるだけになることです。「FDE」という名称にしても、現場の要望を製品に反映する仕事や、再利用できる機能の整備、支援終了後に顧客が運用するための準備が、自動的に加わるわけではありません。
契約や導入計画には、顧客側の業務責任者と社内エンジニアが何を習得し、いつ運用を引き取るのかまで含める必要があります。
FDE型チームの五つの課題と対策
顧客の現場に深く関わるFDE型には、個別の要望に対応しすぎたり、少数の人へ仕事が集中したりする課題があります。体制を作る段階で、次の点を確認します。
- 個別開発の増加： 顧客ごとの要求をすべて実装すると、人数や作業期間を増やさなければ売上を伸ばしにくい受託開発になります。要求ごとに「共通の製品機能へ反映する」「顧客専用の機能として分ける」「採用しない」を判断します。
- 成果責任と変更権限の不一致： FDEが成果を求められても、データ、業務手順、承認方法、利用者の配置を変える権限は顧客側にあります。双方の責任者と、作業を止める条件を先に決めます。
- 販売・導入の速さと本番品質の両立： 短期のBootcampで効果を示せても、本番運用には追加の準備が必要です。セキュリティ審査、動作確認の具体例と期待する結果、稼働状況の監視、障害対応、利用者教育まで含めて導入を完了させます。
- 属人化（知識や判断が特定の人に集中する状態）： 顧客の理解、設計、実装、説明を一人に任せると、その人が離れたときに判断の理由まで分からなくなります。FDEとDSが組み、業務責任者、製品担当、セキュリティ担当も参照できる記録を残します。
- 役割分担と評価基準の曖昧さ： 売上、納期、コード量、利用率をどう評価するかが決まっていないと、販売・利用拡大と本番運用のどちらを優先するかが案件ごとに変わります。職種ごとの責任と評価基準を明確にする必要があります。
Palantirの導入ガイドも、成熟した段階では、顧客の社内チームが日々の運用や新しい業務の仕組みづくりを管理する状態を示しています。Palantirのエンジニアは、必要な場面で支援します。[15]
そのため、導入の完了条件には、顧客が自走（外部の担当者に頼り続けず、自社で運用・改善すること）できる状態を含める必要があります。
FDE型の体制を確認する五つの判断項目
FDE型の体制が自社に合うかは、職種名よりも責任と権限のつながりで判断できます。次の表は、ここまでの比較から、体制を検討する際の観点を整理したものです。
| 確認項目 | FDE型として必要な答え | 名称変更だけになっている兆候 |
|---|---|---|
| 業務成果 | 変える業務判断、利用者、変更前の数値、効果を確認する期間 | 「AIを導入する」「デモを作る」で止まる |
| 本番運用までの責任 | 試作、本番導入、評価、監視、障害対応のそれぞれの担当 | 実装後、説明せずに別チームへ引き渡す |
| 顧客側の権限 | データ利用、手順変更、承認、利用者教育を決める責任者 | 外部FDEだけが成果責任を負う |
| 製品改善への反映 | 製品機能、共通のコード、動作確認の具体例と期待する結果、導入手順に反映する担当と会議 | 顧客専用のコードが案件内に残る |
| 自走の条件 | 社内チームが運用・改善を引き取れることの確認方法と時期 | 常駐する人数と期間だけで、継続支援の価値を測る |
責任や権限が曖昧な場合は、コンサル、受託開発、常駐SE、カスタマーサクセス（顧客が製品を使って成果を得られるよう支援する役割）の担当範囲を明確にする方が、期待を合わせやすいでしょう。
GTM、DS、FDEの役割だけでなく、顧客側の変更権限と製品担当による機能改善までを一緒に見る必要があります。責任のつながりが曖昧なら、FDEという職種を加えても、現場への定着や製品改善を一人に依存する構造は変わりません。
ただし、現場の経験を製品改善に生かせない事業、顧客側に変更の責任者がいない案件、個別開発を継続収益の中心とする会社では、既存職種の責任を明確にする方が適しています。
役割ごとのスキルと育成を支える環境については、シリーズ第3回のPalantir型AI人材を育てる：FDE・DS・GTMの実践設計で扱います。
まとめ：FDE型の判断基準は本番運用・製品改善・顧客の自走
FDE型を取り入れる意味は、顧客の業務で成果を出すことと、その経験を製品改善に生かすことを、一つのチームの仕事として続けられる点にあります。導入後に顧客が自社で運用・改善できるところまで含めて、責任と成果物を決める必要があります。
自社への適用では、現場の経験を製品へ反映できる事業構造と、顧客側の変更権限があるかが判断を分けます。その前提が弱い場合は、既存職種の責任を明確にする方が、期待のずれを減らせます。
参考文献
- Palantir, Overview — Architecture Center
- Palantir, Forward Deployed Software Engineer — Japan Government
- Palantir, Deployment Strategist
- Palantir Technologies Inc., 2025 Annual Report, 2026年2月
- Palantir, Q4 2023 Business Update — AIP Bootcamps, 2024年2月
- OpenAI, Forward Deployed Engineer — Tokyo
- Anthropic, Jobs
- Palantir, Forward Deployed AI Engineer
- Palantir, March 2026 Announcements — AI FDE is now generally available, 2026年3月12日
- McKinsey & Company, The state of AI in 2025: Agents, innovation, and transformation, 2025年11月5日
- Palantir, Open positions in Tokyo, Japan
- LTS, コンタクトセンター／BPO領域でFDEサービスを本格展開, 2026年7月27日
- Hmcomm, 次世代AI実装事業「FDE」開始に関するお知らせ, 2026年5月15日
- IPA, DX動向2025, 2025年6月
- Palantir, Foundry adoption — Phase 4: Hypergrowth
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。