フォワードデプロイドエンジニア完全ガイド
この記事を読み終える頃には、Anthropic、OpenAI、Google などの AI 企業がなぜ FDE を求めているのか、そしてどのようにこの需要を活かせるのかが理解できるはずです。
私自身この仕事を経験し、Varick で FDE 部門を構築するために世界最高クラスの人材を何人か採用してきました。そして今、テック業界で最も注目されるこの役職についての決定的なガイドが存在しないことに気づきました。これがそのガイドです。
なぜ AI 企業は FDE を必要としているのか
FDE になるための第一歩は、なぜ AI 企業が切実に FDE を必要としているのかを理解することです。
もし知能がコモディティ化していると信じるなら、唯一の競争優位はそれをどのように、どこで使用するかにあるということになります。実際、私は知能だけでは競争優位にならないと断言します。したがって、企業がそれをどのように、どこで使用するかを決定することが最も重要な役割となり、それがフォワードデプロイドエンジニアの役割なのです。
企業は、FDE を配置する Applied AI 企業（Varick など）を雇い、テクノロジーを最大限に活用できるよう支援してもらいます。これにより、大規模な AI 変革をすでに経験しているチームにアクセスでき、クライアントは競合他社よりもはるかに速く動くことができ、その結果、莫大な効率向上がもたらされます。
FDE は、顧客の問題を非常に深く理解でき、これまで見たことのないコードベースにコードを書き込み、ビジネスへの影響を非技術系の意思決定者に伝えて契約を成立させることができる、高度なスキルを持つエンジニアです。これは100万ドル単位の採用です。
この役割に求められるもの
FDE であることは、顧客と現場にいることを要求します。Palantir の CTO は、環境そのものの中にいなければ、その環境のためのプロダクトを構築できないと述べています。社内でも同じことを目の当たりにしてきました。
FDE という用語は実際に Palantir に由来し、彼らは現場にいることを非常に重視していました。2010年、彼らはアフガニスタンの特殊部隊と協働していました。特殊部隊は日中に任務に出かけ、フィードバックを得て、それを夜間にコードを出荷する FDE に送りました。
環境の中にいることは、軍事用ソフトウェアの展開と同様に、AI の展開にも必要です。真の効率向上を実現するには、企業はゼロから AI を中心に再構築される必要があります。そしてそれは、顧客と共に現場に座り、企業固有のデータと企業固有のコンテキストで設計されたカスタムエージェントを構築することでのみ可能になります。
役割について
私たちの見解では、Applied AI の FDE の仕事には3つの主要な部分があります。監査、評価、展開です。それぞれを詳しく見ていきましょう。
監査: あなたはクライアントの現場にいて、企業内のさまざまなチームのプロセスやワークフローをマッピングします。例えば、レブオプスに2週間、購買に1週間、財務に丸1ヶ月という具合です。
あなたが一緒に仕事をする各チームから学ぶことはいくつかあります。彼らの仕事内容、ボトルネックの場所、そして価値を提供するエージェントをどこに作れるかです。
企業内の各チームのワークフローを理解することに加えて、監査フェーズの重要な部分は、何を自動化すべきか、何をすべきでないかを判断することです。エージェントが解決する問題よりも多くの問題を生み出すポイントが存在します。
判断に役立つ3つの一般的な原則を以下に示します。
ワークフローがルールに還元できるが入力が異なる場合（ある入力はメール、次は PDF、その次はスキャン画像）、そしてその作業にツールの呼び出しが含まれる場合は、エージェントを配置します。ルールと入力の両方が予測可能な場合は、コードの方が速くて安価です。判断にパターン認識とドメイン専門知識が必要な場合は、手動のままにします。
エージェントが月に5回しか実行しないのであれば、クライアントは良い ROI を得られません。長期間にわたる、大量の自動化を探してください。影響を与えるのに十分なボリュームが必要です。
エージェントを構築する際に AI を使いすぎないでください。ほとんどの自動化タスクは、一連のツール呼び出しと、オーケストレーション層としての LLM への1回の呼び出しで実行できます。AI が多すぎると、不要なトークンコストが発生し（規模が大きくなると累積します）、多くの場合、出力の品質が低下します。
監査フェーズの最後の部分は、プロトタイピングです。エージェントの構築方法については Agents 101、デモから本番環境への移行については Agents 102 を参照してください。
評価: 顧客が AI の展開に数百万ドルを費やしているなら、それが機能していることを知る必要があります。そのために、FDE は詳細な評価を構築します。
良い評価は、エージェントが最終的に与える答えが正しいかどうかをチェックするだけでなく、AI が人間と同じように考えているかどうかも検証します。そのためには、2つのことを行います。
人間の手順をトレースし、それぞれの手順で AI を評価する。人間は一つの動きで問題を解決するわけではありません。それは複数ステップのプロセスです。それらのステップをマッピングし、AI が途中で同じチェックポイントに到達しているかどうかを確認します。
意図した結果の優れた例から小さく始め、それらに対してすべてを測定する。カスタマーサポートエージェントを構築する場合、人間と一緒に座り、ユーザーのクエリに対する可能な限り最良の答えを見つけ出します。いくつかのタスクにわたってそれを数回繰り返します。そうすれば、「優れた」状態がどのようなものかがわかり、エージェントをその基準に保つことができます。
評価は顧客に価値を証明します。誰もが自社に AI を導入したいと言っていますが、それが機能するかどうかに懐疑的な人はまだ多くいます。エグゼクティブがエージェントが ROI を提供すると信頼するために必要なのは、適切なエージェント評価です。
展開: 大規模なデータ移行は避けてください。代わりに、既存のデータ層（SharePoint やデータベース）の上に API を構築し、その上にオーケストレーターとしてモデルを配置してクエリを実行します。これにより、時間と費用が節約でき、さらに重要なことに、既存のシステムを根こそぎにするという過酷な悪夢から解放されます。当社のクライアントは、最新の ERP への移行に数百万ドルと複数年の歳月を費やしてきました。彼らが最も望まないのは、それを再び交換することです。
上記のすべてが完了したら、エージェントを安全にテストするための実行環境を作成します。これは、会社のインフラ内に直接配置されたサンドボックスであり、本番環境に移行する前にエージェントを実行、テスト、デバッグできます。
本番環境に移行する際は、ゆっくりと始めてください。小さなワークフローから始め、動作することを確認してから、追加機能を重ねていきます。例えば、バグをキャッチし、調査し、何が問題だったと思うかを要約したチケットを書くエージェントから始めます。それが機能すれば、その後にコードを書いて PR をプッシュする機能を与えます。
最小単位の自律性から始め、その後でのみ行動を起こす能力を与えてください。
これが、FDE として監査から展開に至る方法です。これらのステップを学ぶこと自体が仕事そのものです。
30日で FDE になる方法
FDE として最も成功する傾向にあるのは、典型的には3つのバックグラウンドです。コンサルタント、プロダクトマネージャー、ソフトウェアエンジニアです。これらに該当しない場合でも、このセクションの最後にある30日間のロードマップに従えば、この役割を得る可能性が飛躍的に高まります。応募や面接と並行してこれらを行ってください。
コンサルタント / PM
コンサルタントや PM として、あなたはすでにデータを ROI に変換する能力を持っているはずです。それは仕事の半分です。しかし、このバックグラウンドの人にとって最大の障壁は、エンジニアリング経験の不足です。
質の高いポートフォリオがこれを緩和できます。次のサイドプロジェクトから2つを選び、全力を注いでください。
- 以前の仕事で手動で行っていたプロセス全体を実行できる、本番稼働可能な AI エージェント。API を呼び出し、自律的に思考をログに記録し、障害対策用ハーネスを備えている必要があります。
- データセット上に構築された RAG パイプライン（参入しようとしている業界に応じてカスタムデータセットを選択：法務文書、医療記録、財務書類など）。
- 自ら構築した評価フレームワーク。さまざまなビジネスプロセス（調達、買掛金管理など）に対して、複数の次元（正確性、フォーマット、コスト、レイテンシ）でエージェントの出力をスコアリングします。
- LLM を、現在 AI 統合をサポートしていないレガシーソフトウェアに接続できる MCP。
自分の理解を AI に外部委託しないでください。ステップバイステップで進めれば、これらの概念は十分に理解できるはずです。これが30日間であって30分間ではないのには理由があります。
ソフトウェアエンジニア
間違いなく FDE の最も重要な部分はコミュニケーションです。AI にできることとできないことを、非技術系の VP にも理解できるように翻訳する必要があります。それができなければ、FDE にはなれません。
SWE は、コンサルタント / PM のセクションで述べたものと同様のプロジェクトを構築する必要がありますが、構築したすべてのコンポーネントを説明してください。テクノロジースタック、結果、行った反復、ビジネス成果。最も重要なのは、そもそもなぜそれらのエージェントを構築したのかという理由です。解決しようとしていた課題は何か、実際のクライアントとのやり取りでどのように進むのか。
役割に関係なく30日間の概要
より具体的なものとして、ほぼすべての準備ができるこの30日間の計画に従ってください。
チェックポイント 1（7日目）:
- エージェントとは何か、エージェントループの仕組みを理解する。Anthropic の Building Effective Agents を読み、ループを実行するスクリプトを書く（プロンプト → モデル → 応答 → 次のステップ）。
- エージェントにツールを呼び出させる方法を学ぶ。Anthropic / OpenAI のツール使用チュートリアルを使用して、2つのツール呼び出し（API 呼び出しとウェブ検索）を追加する。
- 適切なガードレールの構築方法を学ぶ。入力検証、最大ステップ制限、出力フィルタリングをユーザーに届く前に追加する。
- コンテキストウィンドウと外部メモリの使い分け。状態が実行よりも長く持続する必要がない限り、デフォルトでコンテキストを使用する。
- 監査証跡とは何か、その構築方法を学ぶ。すべてのプロンプト、ツール呼び出し、応答をタイムスタンプ付きでログに記録する。これによりエージェントのエラーを発見してフラグ付けできる。
チェックポイント 2（14日目）:
- 構造化出力を強制する方法を学ぶ。常に JSON を返す。OpenAI のデベロッパーページを読む。
- デモを本番環境に移行する方法と、通常何が壊れるかを学ぶ。Agents 102 を読む。
- チェックポイントの設定方法を学ぶ。エージェントの状態を n ステップごとにファイルに保存し、最後のチェックポイントから再開できるようにする。
チェックポイント 3（21日目）:
- リトライロジックと指数バックオフの仕組みを学ぶ。すべての外部呼び出しにはリトライが必要。失敗した場合、1秒、2秒、4秒、8秒待ち、最大16秒で打ち切る。
- エージェント展開時のコスト最適化方法を学ぶ。3つのこと。安価なサブタスクには安価なモデルを使用する（Opus は推論のみに使用）、共通プロンプトをキャッシュする、最大トークンを制限する。クエリごとのコストを追跡する。
- 評価用のゴールデンデータセットの構築方法を学ぶ。20の実際のクエリから始め、自分で完璧な出力にラベル付けする。Anthropic の「Demystifying evals for AI agents」がすべてをカバーしている。
- マルチエージェントパイプラインと並列アーキテクチャの仕組みを学ぶ。1つのエージェントで処理できない場合にジョブを分割する。1つが計画し、他が実行し、1つが統合する。
チェックポイント 4（最終週）:
上記すべてを復習し、声に出して説明できるようにする。可能な限りすべてをビジネス指標に結び付ける。
TLDR
FDE は現在、テック業界で最も需要のある役割です。すべての企業が AI を必要としていますが、それを展開する方法を知っている人はいません。
仕事には3つのフェーズがあります（監査、評価、展開）。あなたの仕事は、各フェーズとその目的を理解することです。
あなたのポートフォリオとそれについて話す能力が決定的な要素です。エージェント、RAG パイプライン、評価フレームワーク、MCP などを構築し、そして最も重要なことに、構築しているすべてのものの背後にあるビジネスユースケースを自信を持って明確に説明できるようにしてください。
コミュニケーション能力の欠如は、FDE の役割にとって致命的です。AI にできることとできないことを非技術系の意思決定者に説明できなければ、展開はありません。
AI が答えではない場合を認識すること。これによりクライアントとの信頼が構築され、さらに重要なことに、本番環境のエージェントに対する ROI が向上します。
これらのステップを実行すれば、参入の可能性は飛躍的に高まります。
もし SF で最も急成長している Applied AI 企業に飛躍したいのであれば、Varick は採用を行っています。私たちは、Citadel Securities の元 COO が率いる、シリコンバレーで最も精鋭の FDE チームを構築しています。直接応募する場合はこちらから: https://www.varickagents.com/careers。
