はじめに
2026年3月19日、株式会社サーキュレーション主催の「Flexy Meetup」にて、PKSHA Technology 執行役員VPoEの森下 賢志氏が登壇されました。テーマは「客先常駐なしでFDEを？実装・利用浸透まで担うPKSHAの『AI社会実装エンジニア』とは」。
「PoCは何度も経験したが、結局お蔵入りになることが多く、自分の技術が社会を変えた実感を持てない」——そんな悩みを抱えたことのあるエンジニアに刺さる内容でした。
このイベントを視聴して、FDEという概念とPKSHAのアプローチについて自分なりに整理したくなったので記事にします。
AIを”使われ続ける状態”にすることの難しさ
「AIを使った新機能を実装しました」——その言葉の裏で、どれだけのAIが現場で使われないまま眠っているか、考えたことがあるでしょうか。
精度は十分。デモも成功した。しかし半年後、現場のオペレーションは元に戻っていた。エンタープライズのAI導入に関わるエンジニアなら、こういう話を一度は耳にしたことがあるはずです。
技術を「作る」ことと、技術を「使わせ続ける」ことの間には、埋めにくい深い溝があります。その溝を埋めることを、正面から職種として定義した存在が FDE（Forward Deployed Engineer） です。
FDEとは何か
FDEはPalantir Technologiesが2003年の創業時から採用してきた職種です。「Forward Deployed」は軍事用語で「前線配備」を意味します。本社ではなく、顧客という「前線」に配備されるエンジニア——それがFDEの出発点です。
重要なのは、FDEが「客先常駐エンジニア」とは根本的に異なるという点です。客先常駐が「顧客の要件に従い開発する」のに対し、FDEは顧客の業務課題を自ら発見し、解決策を設計・実装し、現場に定着させるまで責任を持ちます。
「FDEは、スタートアップのCTOのように動く。小さなチームで、リスクの高いプロジェクトをエンドツーエンドで担う存在だ」
— Gergely Orosz（元Microsoft・Uber技術リーダー）
評価軸が根本から違います。FDEは「コードを書いた量」でも「精度の高さ」でもなく、「顧客が今もそのシステムを使っているか」 で評価されます。納品がゴールではなく、利用継続がゴールです。
なぜ今、FDEが注目されているのか
背景にあるのはAIプロダクト特有の「導入の難しさ」です。
従来のSaaSは、導入すればすぐに使い始められることが価値でした。しかしAIは違います。
- 出力が確率的で不確実：正解が保証されない
- 既存の業務フローへの組み込みが必要：単体では使えない
- 継続的なチューニングが必要：プロンプト調整・データ整備・モデル更新が導入後も続く
- 組織の働き方そのものを変える必要がある：技術だけでは解決しない
汎用的なプロダクトを売りつけて終わりというモデルでは、どうしても「使われないAI」が量産されます。そこにFDE的な役割の必然性があります。
PKSHAが定義する「AI社会実装」
PKSHA TechnologyのVPoE・森下氏は、自社エンジニアの役割をこう定義しています。
「社会実装とは、AIがオペレーションに組み込まれ、使うのが当たり前になっている状態のこと。精度100%ではないAIの特性を理解した上で、人間も含めた全体のサイクルを設計することが私たちのエンジニアリングだ」
「作るのが目的ではなく、使ってもらうことが責任範囲」——この一言がPKSHAのエンジニア像を端的に表しています。
PKSHAはクレジットカード不正検知、チャットボット・ボイスボット、駐車場のカメラによる車両認識・決済など、複数の領域でAIの社会実装に取り組んできました。2025年以降はフィジカルAI（ロボット・現実世界への展開）や、AIエージェントを使いこなす人材とセットでの提供も視野に入れているとのことです。
森下氏が「我々のエンジニアの評価KPIはFDEと非常に近い」と言い切る根拠はここにあります。
「客先常駐なし」でFDEを実現する逆転の発想
FDE的な役割を期待されると、通常は「常駐してほしい」という話になります。しかしPKSHAはそれをしません。では、どうやって顧客の信頼を得ているのでしょうか。
森下氏の答えはシンプルです。「常駐するより自社で開発する方が速くて高品質なアウトプットが出せる」という事実を示すこと。
PKSHAでは社内にコード生成AIの使い放題環境をはじめとする最先端の開発インフラを整備しています。顧客先では使えない最新ツールが自社では使える。ドメイン知識の深さと技術力の掛け合わせで、常駐以上の価値を非常駐で出せることを実績で証明してきました。
PKSHAが常駐なしで信頼を得る3つの要素
- 成果へのコミット 利用継続率を評価軸に置き、結果で語る
- ドメイン理解の深さ 業界・業務への知見を蓄積し、顧客と対等に話せる
- 開発環境の優位性 最先端ツールを自社環境で使い倒し、速度と品質で上回る
AI社会実装エンジニアとして活躍する人の特徴
森下氏が挙げた「活躍するエンジニアの特徴」は3つです。そこに、AI時代のFDEにとって欠かせないと私が感じたもう1つの視点を加えて、4つで整理します。
1. 自己理解の深さ（取説の共有）
自分の強み・弱み・働き方の癖を言語化し、チームや顧客と共有できること。不確実な現場で動くには、自分という変数を把握していることが前提になります。
2. 領域を越境するマインド（マルチスペシャリティ）
エンジニアリングに閉じず、ビジネス・ドメイン・オペレーション設計まで関与できること。「自分はエンジニアだから」という線引きをしない姿勢が、AI社会実装を可能にします。
3. 不確実なAIを届けることへの「執着心」
精度が完全でないAIを、それでも現場で機能させるためにやり切る力。これは技術力というより、姿勢の問題です。「動いた」で終わらず、「使われ続けている」まで追いかけること。
4. AI時代に問われる「国語力」
AIが「作る力」を代替しつつある今、FDE的なエンジニアに問われるのは「言語化する力」ではないかと感じました。
顧客が「何となく困っている」状態から、「真の課題」を引き出して定義すること。そして、その曖昧な要求をAIやシステムが扱えるクリアな仕様へと変換すること。これはコードを書く力とはまったく別のスキルです。
AIは与えられた仕様を実装するのは得意ですが、「そもそも何を作るべきか」を顧客と一緒に言語化するプロセスは苦手です。PKSHAが大切にする「人とソフトウェアの共進化」を支えるのは、まさにこの人間側の言語化力だと思います。
社会実装の成否は、技術の精度よりも、この「課題を言葉にする力」で決まる場面が多い。FDEに興味を持つエンジニアにとって、国語力は意外と軽視できないスキルです。
FDE的エンジニアへのキャリアを考えるなら
FDEというポジションへの転職を検討しているエンジニアが気にすべきは、「どの企業のFDEか」です。
外資系（OpenAI・Palantir・Cohereなど）のFDEは「完成されたプロダクトを顧客環境にデプロイ・カスタマイズする」仕事が中心です。プロダクトが先にあります。一方、日系企業のFDEは「顧客の課題から始まり、自社技術を使って個社ごとにソリューションを構築する」スタイルが多く、スコープが広くなります。
PKSHAのモデルはその中間〜日系寄りに位置します。プロダクトを持ちながら、顧客の業務深くまで入り込み、利用浸透まで責任を持つ。このモデルは、ドメイン知識と技術力を両方持つエンジニアに大きな裁量を与えてくれます。
「技術で実際のビジネス課題を解決することに情熱を持てるか。顧客と直接話すことを楽しめるか。不確実な環境で自律的に判断し、動き続けられるか」
FDE的な働き方への適性は、スキルセット以上に、このマインドセットで決まります。コードを書く力は前提に過ぎません。
おわりに
AIが「作れる時代」になった今、差がつくのは「使わせ続けられるか」です。その問いに正面から向き合う職種がFDEであり、PKSHAが「AI社会実装エンジニア」と呼ぶ存在です。
自分はこれまで、技術を届けていたか。それとも作っていただけか——このイベントを通じて、改めてそう問い直すきっかけになりました。
FDEという働き方に興味のあるエンジニアに、ぜひ一度アーカイブ動画を見てみることをおすすめします。
参考イベント