簡素なハーネスとコード実行型エージェントは、過度に厳格なオーケストレーションがモデルの性能を制限しかねない、自由度の高いタスクに適しています。
これに伴い、コード実行とサンドボックス化は、エージェントシステムのアーキテクチャにおける中核的な課題となっています。
Agents SDK を使うと、コード実行型エージェントの構築に必要な複雑さとコード量を削減できます。私たちのテストでは最大 6 分の 1 になりました。
長年にわたり、エージェントシステムの進歩を支えてきたのは、プロンプト、ツールインターフェース、コンテキスト管理、制御フローの改善など、オーケストレーションの強化でした。しかし、コーディングエージェントの能力が高まるにつれ、そのバランスは変わり始めています。
自由度の高い多くのワークフローでは、ボトルネックはもはやエージェントループ自体ではなく、モデルがコードを書き、コマンドを実行し、出力を確認して反復するサンドボックス、つまり実行レイヤーにあります。タスクレベルの推論がこの環境へ移るにつれ、モデルの能力を最大限に引き出すため、周辺のオーケストレーションはよりシンプルである必要があります。
この転換を可能にするのが、まさに 新しいバージョンの Agents SDK です。早期アクセス期間中のテストでは、フレームワークロジックをさらに重ねるのではなく、実行レイヤーをよりモジュール化し、組み合わせやすくすることで、システムの他の部分を簡素に保てることが分かりました。
ハーネスエンジニアリングでは、ハーネスを実効性のある最小構成まで簡素化する考え方が主流になっています。大まかに言えば、ハーネスとはモデルを取り巻くソフトウェアです。モデルが確実に作業できるよう、コンテキスト、ツール、制御フロー、フィードバックループを管理するレイヤーを指します。
ここ数年、エージェントの性能向上の多くは、このレイヤーの強化によって実現されてきました。ツール、メモリと検索、明示的なタスク分解、緊密なオーケストレーションを改善することで、多くの場合、システムの信頼性と能力が高まりました。この枠組みでは、進歩とは主に、モデルを取り巻くソフトウェアへより多くのタスクロジックを組み込むことを意味していました。
しかし少なくとも一部の自由度の高いタスクでは、この傾向が弱まりつつあります。ハーネスが細かく指示するほど性能が向上するとは限らないことを示すプロジェクトや論文が増えています。コーディング支援、長時間実行タスク、ブラウザ操作、長いコンテキストを扱うタスクでは、同じ傾向が繰り返し見られます。モデルが十分に賢くなると、周辺ソフトウェアに過剰なタスク構造を押し込むことは、強みではなく制約になり得ます。
このように、ハーネスの役割は変化しています。ハーネスは、厳格なオーケストレーションによってタスクを事前に想定するのではなく、明快な実行基盤を提供する役割を担いつつあります。つまり、システムのインターフェースと安全対策の範囲内で、モデルが状態を確認し、コードを実行し、エラーから復旧し、アプローチを自ら調整できるサンドボックスです。これは、Andrej Karpathy 氏が Software Engineer 3.0 で述べた転換に近いものです。従来ソフトウェア内にあったロジックの一部が、より上位の「プロンプト」へ移ります。
ここから得られる教訓は、エージェントシステムのあらゆる構造を取り除くべきだということではありません。対象が限定的で処理量が多い場合や、明確な成功基準がある場合を中心に、明示的なワークフロー、ヒューリスティクス、決定論的なガードレールが有効なタスクは今も数多くあります。以前の記事「エージェントシステム設計のヒューリスティクス」で述べたように、信頼できるロジックフローが実現可能で望ましい場合、強力なオーケストレーションは依然として重要です。
自由度の高いタスクでは、重点が移りつつあります。課題は、さらに精巧なオーケストレーションレイヤーを設計することではありません。モデルが内部で効果的に作業できるよう、シンプルで観測可能かつ十分にモジュール化された実行環境を構築することです。
エージェントがファイルを読み、コードを書き、シェルコマンドを実行し、長時間実行タスクを起動できるようになると、エンジニアリング上の課題も変わります。難しいのは、もはやプロンプトの最適化やツールのルーティングだけではありません。エージェントが実際のシステム上で動作することで、その能力は大幅に高まります。一方、安全性とセキュリティの対象領域が広がるため、扱いには一層の注意が必要になります。たとえば、コードを実行できるエージェントは、環境の分離が不十分だと有害な操作を行う可能性があります（AISI の Sandbox Bench を参照）。
そのため、サンドボックス化はエージェントフレームワークにおける重大な課題になりつつあります。初期のシステムでは、実行機能はハーネスに後付けするツールとして扱われることが一般的でした。しかし、実行がステートフル、長時間、またはリモートになると、この手法は機能しなくなり始めます。サンドボックス自体に加え、そのライフサイクル、状態、インターフェース、エージェントループとの連携を管理することは、すぐに独立したシステム設計上の課題となります。そのため、OpenAI の Container API とシェルツールをはじめ、Modal、Cloudflare、Daytona、E2B など、コード実行用のマネージド環境を提供するプロバイダーが増えています。
この境界が重要なのは、コード実行にはハーネスの他の部分よりも強固な分離と厳密なランタイム制御が必要だからです。実装が不十分なコード実行型エージェントは、制御不能なコンピューティング費用、社内システムへの破壊的操作、機密情報の漏えいという、事業上重大な 3 つのリスクをもたらす可能性があります。コンテナ化、分離、ランタイムの安全対策を適切に施せば、こうしたリスクを実環境への導入で許容できる水準に抑えられます。
これは、オフィス全体の鍵を渡すのではなく、エージェント専用の密閉されたワークスペースを用意することだと考えられます。エージェントはその空間内で有用な作業を行えますが、明確に定められた境界を越えることはできません。使用できるコンピューティング量に上限を設け、アクセス可能なシステムやファイルを制限し、そもそも利用できる情報を管理できます。
リスクを完全になくすことはできませんが、問題を「インフラ内で自由に動き回るエージェント」から「管理された環境内で動作するエージェント」へ変えられます。このレイヤーがエージェントシステムの標準要素になるのであれば、フレームワーク自体による本格的なサポートが必要です。これにより、サンドボックスは移植可能な基本機能を備えたモジュール式の実行レイヤーになります。開発者はすぐに導入し、プロバイダー間で切り替え、エージェントロジックを絶えず作り直すことなく拡張できます。
エージェントがコードを実行するようになると、サンドボックス自体にもオーケストレーションが必要になります。ローカルの概念実証から、リモート実行、複数のバックエンド、長時間セッションへ移行すると、運用負荷は飛躍的に増大します。環境の作成と停止、一時停止と再開、状態のスナップショット、後からの再接続を、複数のプロバイダーにまたがって一貫して管理する方法が必要です。
概念として華やかな要素ではありませんが、実用上は重要です。特にエージェントフレームワークに統合されていない場合、各チームがエージェントパイプラインをゼロから構築するたびに、まさにこの種のインフラが大きな負担となります…
ここで、フレームワークによるサポートの強化が重要になります。私たちは、新しい OpenAI Agents SDK の早期アクセスを利用し、サンドボックス化されたエージェントを実際に構築しました。特に印象的だったのは、アーキテクチャ上の重点の変化です。この SDK は、実行を周辺的なツールではなく、中核レイヤーとして扱います。実際には、より少ないコードでサンドボックス化されたエージェントの起動、サンドボックスのスナップショット、実行の再開が可能になります。一部のテストではコード量が約 6 分の 1 になり、周辺のエージェントロジックを書き直さずにバックエンドを切り替えられました。
この明確な責務分離により、ハーネスは推論、コンテキスト、ワークフローに集中できます。実行レイヤーは、分離、移植性、ランタイム状態に集中できます。この抽象化により、能力が高く発展させやすいコーディングエージェントを構築しやすくなります。ローカル実行とリモート実行を切り替え、長時間タスクに対応し、システム全体を再設計することなく実行バックエンドを変更できます。
タスクレベルのロジックがハーネスからモデルへ移るにつれ、システムの複雑さの一部も、より下層の実行レイヤーへ移ります。コード実行とサンドボックス化は、特にコーディング中心の自由度が高いタスクにおいて、エージェントシステムのアーキテクチャ上の中核的な課題となっています。エージェントパイプラインの設計だけでなく、エージェントが長期にわたって安全かつ確実に行動できる環境の設計も、同じように重要になっています。
だからこそ、サンドボックス化された実行を扱う高水準の抽象化が重要です。新しい OpenAI Agents SDK は、実行をシステムのモジュール式レイヤーとして扱うことで、この方向へ進んでいます。バックエンド間で移植でき、長時間タスクでも状態を維持し、新しい構成ごとに同じインフラを作り直すことなく簡単に利用できます。
より広い視点で見ると、次世代のエージェントフレームワークを決めるのは、追加するオーケストレーションロジックの量ではなく、エージェントがますます依存する実行環境をどれだけ適切に構成できるかでしょう。