10月2日、Shift Magが「OpenAI FDE: "Code is very cheap to produce"」と題した記事を公開した。AIエージェントが「デモで動く」段階から「本番で使える」段階へと移行しつつある今、エンジニアに求められるスキルセットは何か——この問いに現場の最前線から答えるインタビューだ。大規模言語モデルの推論コストが急落し、コード生成が日常的になりつつある2024年だからこそ、「エンジニアの主要アウトプットとは何か」という問いの答えは根本から問い直されている。OpenAIのForward Deployed EngineerであるLuis Velascoが、AIエージェントを本番環境で機能させるために何が必要かを詳細に語っている。

「コードは安い」——エンジニアの主要アウトプットが変わる

Luis Velascoは現在、OpenAIでForward Deployed Engineer（FDE）を務めている。FDEとは、企業がAIを実際のビジネス環境に導入する際に技術面で伴走する役割だ。この職種はPalantirが大規模に採用・定義したことで広く知られるようになり、近年はAI企業を中心に普及している。顧客の現場に深く入り込み、プロダクトとビジネス課題の両方を理解した上でソリューションを実装する点で、従来のソリューションエンジニアやコンサルタントとは異なる。Googleでの勤務経験も持つLuisが、インタビューの締めくくりに残した一言が核心をついている。

コードを生み出すことは今やとても安価だ。重要なのは、モデルの周囲のシステムを構築すること——意図のシステム、ガードレール、エージェントが確実に動くための制約だ。

つまり、エンジニアの主要な成果物は「コードそのもの」から「モデルを取り巻くハーネス（枠組み）」へと移行しつつある、というのが彼の見立てだ。そしてインタビューを通じて彼が繰り返し強調したのが、Eval（評価）駆動開発とシステム設計のセンスという2つのキーワードだった。

Evalなしに本番はない

Luisは「デモは動いても、本番は別物」という点から話を始めた。デモは制御された条件下で成立するが、本番環境では何が機能して、何が失敗し、なぜ壊れるのかを正確に把握しなければならない。

そこで重要になるのがEval駆動開発（Evaluation-driven development）だ。ソフトウェア開発における「テスト駆動開発（TDD）」がテストを先に書いてからコードを実装するアプローチであるのと同様に、Eval駆動開発では評価基準（Eval）を先に定義し、それをパスすることを本番リリースの条件とする。OpenAIはクライアント企業との取り組みの中でこのアプローチを広く活用しているという。

ベンチマーク、つまりEvalをクリアできれば、安全かつ確実な形で本番リリースに進める。

彼はEvalに関する重要な用途をもう一つ挙げた。モデルをアップグレードした際のリグレッションテストだ。新しいモデルに切り替えたとき、既存のワークフローが壊れないかを確認する手段として機能する。

Evalセットの構成については具体的な指針も示している。「簡単なケース、中程度のケース、そしてエッジケースを揃えた代表的なEvalセット」を組めれば、デプロイ時に何も壊れないという保証を得られると言う。

エージェントのタスク時間：6分から16時間へ

AIエージェントの能力進化の速さを示すデータとして、LuisはMETRの長期タスクベンチマークの結果に言及した。METR（Model Evaluation & Threat Research）は、AIエージェントの自律的なタスク処理能力を測定することに特化した非営利の評価機関で、特に「人間が実際に行う長時間の作業をエージェントがどこまで代替できるか」を継続的に計測している。その結果によれば、3年余りの間に、エージェントが扱えるタスクの規模が「人間なら6分かかる作業」から「人間なら16時間かかる作業」へと拡大したという。

この進歩の背景には2つの要因がある。モデル自体の長期的な一貫性と持続性の向上、そしてハーネス（実行基盤）の改善だ。

以前は開発者がコンテキスト管理やメモリ管理をすべて自分で面倒を見る必要があった。今はCodexのようなハーネスがあれば、それらは不要になった。

ここで言及される「Codex」は、2021年ごろに広く知られたGPT系のコード補完モデル（旧Codex）ではなく、OpenAIが2025年に発表したコーディングエージェント製品としてのCodexを指している。タスクの計画・実行・検証を自律的にこなすエージェント基盤として位置づけられており、コンテキスト管理やツール呼び出しを抽象化するハーネスとしての役割を担う。

エージェントへのアクセス権は「社員と同じルール」で

AIエージェントを社内データに接続する際のセキュリティについて、Luisは職場のオンボーディングに例えて説明した。財務部門に入社した社員には財務データへのアクセスだけを与え、HRデータへのアクセスは与えない——その原則をそのままエージェントに適用すればよい、という考え方だ。

従業員に適用しているのと同じACL（アクセス制御リスト）を、AIエージェントにも適用できる。

エージェントにはタスクを完了するために必要なデータだけを見せるという設計原則で、既存の権限管理の仕組みを流用できる点は実用的な示唆として評価できる。新たなセキュリティレイヤーをゼロから設計するのではなく、組織がすでに運用しているアクセス制御の延長線上でエージェントを扱えるという観点は、導入の現実的な障壁を下げる上でも重要な視点だ。

システム設計のセンスは消えない

Luisはインタビューをこの一言で締めた。

「システム設計のセンスは絶対になくならない」

コード生成がAIに委ねられる時代に入っても、どんなシステムを設計するかの判断、ガードレールの設計、エージェントへの制約の組み方——そうした上位レイヤーの判断力こそが、エンジニアに求められるスキルとなると彼は見ている。コードが「安く」なればなるほど、「何を作るか」「どう制約するか」という問いの比重は増す。FDEとして多くの企業導入を見てきた彼の言葉だけに、説得力がある。

詳細はOpenAI FDE: "Code is very cheap to produce"を参照していただきたい。