AIエージェント
AIエージェント導入を支える新職種【FDE】とは
公開日 ：
FDE（Forward Deployed Engineer）は、顧客の現場に入りAIを実装・定着まで担う職種です。2026年に国内でも求人が急増しています。その仕事の中身と、権限設計が避けて通れない理由を解説します。
リード
FDE（Forward Deployed Engineer）は、2026年に入って国内でも求人が急増している職種です。顧客の現場に入り、AIを実際の業務に組み込むところまでを担う。その仕事の中身を見ていくと、権限の設計という領域に必ず突き当たります。
FDEとは何か
FDEは Forward Deployed Engineer の略です。顧客企業の現場に入り込み、業務に合わせてシステムを設計・実装し、実際に使われる状態まで持っていくエンジニアを指します。米国のPalantirが確立した職種として知られ、2025年以降、OpenAIやAnthropicといったAI企業、そして大手コンサルティングファームが相次いで採用を始めました。日本でも2026年に入って求人が急増しており、国内のAI企業やSaaS企業がFDE職を設置しています。
従来の職種との違いは、担当範囲にあります。提案して終わるコンサルタントでもなく、仕様どおりに作るだけのエンジニアでもない。課題の定義から実装、定着までを一気通貫で引き受けるところが特徴です。
なぜ、この職種が急に必要とされたのか
モデルの性能が上がった一方で、それを実際の業務に組み込む工程がボトルネックになったからです。
AIの導入がうまくいかない理由の多くは、モデルの精度ではありません。既存システムとの接続、業務フローとの整合、現場の運用に耐えるかどうか。こうした泥臭い部分で止まります。ここを埋められる人材が足りない。それがFDEという職種が立ち上がった背景です。
どのモデルが賢いかではなく、誰が顧客の現場でAIを本番稼働させられるかに、競争の焦点が移ったと言われています。
求められるのは、プログラミング能力だけではない
FDEに必要とされるスキルを見ていくと、開発力と同じくらい、それ以外の要素が並びます。
顧客の業務を聞き取って課題を定義できること。何をシステムにして何を人が担うかを切り分けられること。現場の担当者が無理なく使えるように、画面や手順を組み立てられること。そして、権限や記録の扱いに関わる法務・ガバナンスの知識を持っていること。開発ができるだけでは、現場で使われる状態までは持っていけません。
文系・理系を問わず担い手になれる職種だと言われるのは、このためです。国内でFDE人材の育成が語られるときにも、この点が論点になっています。
FDEの仕事は、権限を扱う仕事でもある
AIエージェントを顧客の業務に組み込むということは、顧客のシステムに対する実行権限をAIに渡すということです。社内の基幹システムを参照させ、ファイルを読み書きさせ、データを登録させ、場合によっては社外への連絡まで任せる。
FDEの仕事は、必然的に権限設計を含みます。そして実際の現場では、ここで詰まります。
試しに動かしてみる段階（PoC）では、話は簡単です。テスト環境で、担当者のアカウントを借りて、とりあえず動かす。ところが本番に移そうとした瞬間に、情報システム部門から質問が来ます。
- このAIは、どのアカウントで動くのか
- 誰の承認に基づいて、その権限を持っているのか
- 権限の範囲はどこまでか。上限は設定されているのか
- 担当者が異動したら、この権限はどうなるのか
- 事故が起きたとき、実行の根拠をどう説明するのか
- ベンダーが撤退したあと、この権限は誰が管理するのか
これに答えられないと、試験導入から本番には上がりません。AIの精度は問題ないのに稟議が通らない、という状況のかなりの部分がここです。
現場で実際に起きていること
権限設計を後回しにすると、いくつかの典型的な状態が生まれます。
担当者の個人アカウントでAIが動いている。手っ取り早いので最初はそうなりますが、これではAIの実行と人の実行がログ上で区別できません。担当者が異動すればAIも止まります。
システムに接続するための鍵が、担当者のあいだで共有されている。誰がどこにコピーしたかを追えなくなり、無効にしたときにどこへ影響が出るかも分かりません。
権限が広すぎる。動作確認のために管理者権限を渡し、そのままになっている。誤作動が起きたときに、被害の範囲を限定できません。
期限がない。プロジェクトが終わっても権限だけが残り続け、数年後に誰も把握していない権限が動いている、という状態になります。
どれも悪意があって起きることではありません。動かすことを優先すると、こうなるというだけです。そしてFDEは、まさに動かすことを求められる立場にいます。
ガードレールをどこまで作り込むか
権限の問題を意識しているFDEは、たいていガードレールを設計します。呼び出せるツールを制限し、扱える件数や実行回数に上限を設け、削除や社外送信のように取り消せない操作には人の承認を挟む。実行環境そのものを隔離することもあります。
これは必要な作業です。ただ、ガードレールだけで納品を終えると、顧客の情報システム部門から見たときに困る点が残ります。
ガードレールは、実装した側の環境の内部に置かれます。正しく設定されているかどうかは、設定した本人か、その環境にアクセスできる人にしか分かりません。監査の場面で「社外への送信はできない設定にしていました」と説明しても、それを裏づけるのは管理画面の記録だけ、ということになります。あとから設定を変えた履歴が残るとも限りません。
もうひとつ、ガードレールは環境の外には出ていきません。AIが別のAIに作業を渡す構成や、外部のサービス上で処理が続く構成では、こちらの意図した制限が引き継がれる保証がありません。
そして、そのAIが誰の代理で動いているのかは、ガードレールでは表現できません。事故が起きたときに残るのは「このAIがこの操作をした」という実行の記録であって、「誰の委任に基づく権限だったのか」は別途どこかに残しておかないと追えません。
VCを扱えると、何が変わるか
VC（Verifiable Credentials／検証可能なデジタル証明）は、そのAIが誰の委任を受け、何を、どこまで、いつまで実行してよいのかを、改ざん検知が可能な形で持たせる技術です。ガードレールと競合するものではなく、権限の根拠を外に示せる形にして、ガードレールの判定材料にするものだと考えるとつかみやすいと思います。
FDEの実務に引きつけると、いくつかの効果があります。
まず、納品物に権限設計を含められます。動くAIではなく、権限が定義され、期限が切られ、失効させられるAIとして引き渡せる。先に挙げた6つの質問にも、設計として答えられる状態になります。
撤退時に権限を確実に切れるのも大きい。プロジェクト終了時に発行した証明を失効させれば権限は消えます。どこかに残っているかもしれない、という状態を残さずに済みます。
顧客の監査にも耐えます。誰が何を委任し、どの根拠で実行されたのかを、自社の管理画面ではなく署名付きの記録として示せるからです。
そして、誤作動の被害をあらかじめ区切っておけます。AIエージェントの意図しない動作を完全に防ぐことはできません。だからこそ、実行してよい操作の範囲と期限を証明の中に埋め込んでおく意味があります。最悪でもここまで、という線を実装の中に持たせられます。
FDEに求められる、VC周辺の実務知識
必要なのは仕様の暗記ではなく、設計判断ができることです。
証明の発行主体を顧客の管理部門に置くのか、部門長に置くのか、システムに持たせるのか。有効期限を業務単位で切るのか期間単位で切るのか。短くするほど安全ですが、更新の手間は増えます。失効を人事異動や契約終了と連動させられるか。既存のID管理で足りる部分と足りない部分をどう切り分けるか。実行ログと委任の記録を、後から突き合わせられるか。
いずれも技術というより、業務と組織の理解が要る領域です。FDEが顧客の現場に入り込む職種であることを考えると、相性は良いはずです。
権限設計は、FDEの作法になる
FDEは、AIを現場で動かすことを求められる職種です。そして動かすためには、権限を渡さなければなりません。ここを場当たりで処理すると、本番に上がらないか、上がったあとに事故ります。
AIエージェントの誤作動を根絶することはできない。この前提に立つなら、権限の範囲と期限を最初から設計に織り込むことは、FDEの標準的な作法になっていくはずです。
当社の取り組み
キャンパスクリエイトは、FDE人材の育成に取り組んでいます。2026年、経済産業省「未来の教室」実証事業に採択され、地域の中小企業の実課題を題材に、学生がAIの実装までを担うFDE型人材の育成モデルの実証を進めています。
［リンク：FDE普及に向けた当社の取組］
