複数チームでAI活用の温度差が生まれ、全社展開が進まないと感じている技術リーダー、あるいはプラットフォームチームの責任者に向けた内容です。
同じ会社の中でも、あるチームはAIを前提に業務フローを組み替え、別のチームはガイドライン配布すら形骸化している、という状況は珍しくありません。この差は個人のスキル差というより、チームごとの意思決定構造やツール選定基準が異なる「組織アーキテクチャの断層」として捉えると見通しが良くなります。本記事では、この断層に対する処方箋として語られているForward-Deployed Engineer（FDE、顧客先に常駐して製品を現場の課題に適応させる技術者）という役割モデルを、非機能要件と技術的負債の管理という観点から検証します。
トップダウン導入が機能しない理由を構造で説明する
「全チームでAIを導入せよ」という号令だけでは浸透しないという現象は、経営層の意志が弱いからではありません。
これはアーキテクチャの世界でよく見る「単一の標準を全体に強制すると、局所最適が崩れる」問題と同じ構造です。マイクロサービスの文脈で言えば、各サービスチームがそれぞれ異なる非機能要件（レイテンシ許容度、可用性目標、コスト制約）を持っているのに、共通の技術スタックを一律に押し付けると、どこかのチームで無理が生じるのと同じ図式です。
組織を単一の「部族」として扱うマンデート（強制力を伴う方針）は、実際には複数の部族の集合体である会社に対して、暗黙のうちに「全員が同じ優先順位・同じリスク許容度を持っている」という前提を置いています。この前提が崩れているチームでは、方針は形式的に受理されるだけで、実際の開発フローには反映されません。
FDEモデルの技術的特徴を分解する
FDEという概念は、データ分析企業Palantirが広めた役割で、社内では「Delta」とも呼ばれています。ここでの整理が重要なのは、通常のエンジニア（Dev）とDeltaの違いを「最適化対象の違い」として定義している点です。
Devは「1つの機能を多くの顧客に届ける」ことを最適化します。これは再利用性を重視するアーキテクチャ、つまり共通ライブラリやプラットフォームチームの発想に近いものです。
一方Deltaは「1つの顧客に多くの機能を届ける」ことを最適化します。顧客ごとにカスタマイズし、その顧客の成果（アウトカム）に責任を持つという点で、汎用化とは逆方向のベクトルを持っています。
この違いを非機能要件の言葉に翻訳すると分かりやすくなります。Devの仕事は「保守性」「再利用性」「一貫性」を非機能要件の中心に置きます。Deltaの仕事は「その現場での可用性」「その現場でのレイテンシ」「その現場での運用コスト」を中心に置きます。同じエンジニアリングでも、最適化する非機能要件の軸そのものが違うということです。
Deltaの実務上の特徴として挙げられているのは次の3点です。
- 技術ではなく課題への共感を優先する（デモが成功しても現場の運用が変わらなければ失敗とみなす）
- 成果物の引き渡しで終わらせず、アウトカムまで責任を持つ（「作った人」と「使わせる人」を分離しない）
- 未知のドメインに投入され、短期間でその領域の実務知識を身につける
フィードバックループが「四半期単位」ではなく「日単位」で回るという点も強調されています。これはアジャイル開発における短いイテレーションの発想と重なりますが、対象が「プロダクトのバックログ」ではなく「特定チームの業務プロセスそのもの」である点が異なります。
社内適用としてのFDEを、技術的負債の観点から評価する
この役割モデルを社内のAI浸透に転用する発想自体は、技術的負債の管理という視点から見ても筋が通っています。
各チームが独自にAIツールを試し、独自のプロンプト運用や独自の評価基準を積み上げていくと、後から統合しようとしたときに「暗黙知の負債」が発生します。ドキュメント化されていない判断基準、属人化した運用ノウハウは、通常のコード上の技術的負債と同じく、後から返済コストが跳ね上がる性質を持っています。
FDE型の人材を各チームに一時的に送り込むアプローチは、この負債が固定化する前に、各チームの実情に合わせた形で標準化の芽を作る動きだと解釈できます。プラットフォームチームが一方的にAPIやガイドラインを整備するトップダウン型の標準化と比べて、現場の制約（レガシーシステムとの接続、既存のCI/CDパイプラインとの整合性、セキュリティポリシー上の制約）を先に理解してから解決策を作る点が異なります。
比較として、SRE（Site Reliability Engineering）の文脈で語られる「エンベデッドSRE」モデルを思い浮かべると理解しやすくなります。エンベデッドSREは、中央のSREチームから一時的に特定プロダクトチームに常駐し、その場の運用課題（オンコール体制、SLO設計、インシデント対応フロー）を一緒に構築してから離れるという動き方をします。FDE型のAI浸透も、期間限定で常駐し、そのチーム固有の制約に合わせて解決策を作り、自走できる状態にしてから離れるという点で構造が似ています。
今日から確認できること
このモデルを検討する際、いきなり「AI版FDE」というポジションを新設する必要はありません。まず自社の状況を次の観点で棚卸しすることから始められます。
- 現状のAI活用が「共通ツールの配布」止まりか、「各チームの業務フローへの統合」まで進んでいるかを区別する
- AI活用が進んでいるチームのエンジニアに、他チームへの一時的な常駐（2〜4週間程度）を打診できる余力があるか確認する
- 送り込む側のチームで、評価基準・コスト管理・失敗パターンがドキュメント化されているか（属人化していないか）を確認する
- 受け入れ側のチームで、既存のCI/CDパイプラインやセキュリティポリシーとAIツールの接続点を洗い出しておく
特に3点目は見落とされがちです。常駐者自身が暗黙知でしか判断基準を持っていない場合、常駐しても「その人がいる間だけ機能する」状態で終わり、離任後にまた元に戻るリスクがあります。常駐前に判断基準を言語化する作業自体が、実は最初の投資対象になります。
まとめ
AI活用の社内格差は、マンデートやスライド資料では解消しにくいという構造は、単一標準を多様なチームに強制するアーキテクチャ上の失敗パターンと同じ形をしています。
FDE、社内で言えばDeltaという役割は、汎用化ではなく特定チームのアウトカムに最適化する働き方であり、非機能要件の優先順位そのものを現場に合わせて組み替える動きです。
導入を検討するなら、まず自社のAI先行チームの知見が言語化されているかを確認し、そのうえで短期常駐という形で他チームに一時的に送り込めるか検討することから始められます。
負債を残さないためには、常駐者個人の勘に頼らず、判断基準を明文化してから現場に入ることが欠かせません。