モデルからエージェントへ：Responses API にコンピュータ環境を装備する

公開日: 2026-03-11
著: Bo Xu、Danny Zhang、Rohit Arunachalam

現在、特定のタスクに優れる「モデル」から、複雑なワークフローを扱える「エージェント」へと移行が進んでいます。モデルへのプロンプトだけでは学習済みの知性にアクセスするにとどまりますが、モデルにコンピュータ環境を与えることで、サービスの実行、外部APIからのデータ取得、スプレッドシートやレポートのようなより有用な成果物の生成など、はるかに広いユースケースが実現できます。

実際にエージェントを構築しようとすると、いくつか現実的な課題が出てきます。中間ファイルをどこに置くか、大きな表をプロンプトに貼り付けるのをどう避けるか、ネットワークアクセスを与えつつセキュリティ上の問題を起こさないにはどうするか、タイムアウトやリトライをワークフローシステムを自前で作らずにどう扱うか、などです。

これらを開発者に丸投げする代わりに、Responses API を信頼できる実行環境につなげるために必要なコンポーネントを構築しました。OpenAI の Responses API は、シェルツールとホストされたコンテナワークスペースと組み合わせることで、これらの現実的な問題に対処するよう設計されています。モデルはステップとコマンドを提案し、プラットフォームはそれらをファイルシステム（入出力用）やオプションの構造化ストレージ（例: SQLite）、および制限されたネットワークアクセスを備えた分離環境で実行します。

以下では、エージェント用のコンピュータ環境をどのように構築したかを分解し、より速く、再現性が高く、安全な本番ワークフローにするための初期の教訓を共有します。

シェルツール

良いエージェントワークフローはタイトな実行ループから始まります。モデルがファイル読み取りやAPIでのデータ取得のようなアクションを提案し、プラットフォームがそれを実行し、その結果が次のステップにフィードバックされます。

まずはシェルツール—このループを実際に見るための最も単純な方法—から話を始め、次にコンテナワークスペース、ネットワーキング、再利用可能なスキル、コンテキスト圧縮（compaction）について触れます。

ツールの利用一般について理解するとシェルツールがどう効くかが分かりやすくなります。モデルは学習中にツールの使い方とその結果をステップ単位で示され、いつツールを使うか、どのように使うかを学びます。ここで「ツールを使う」と言うとき、モデルは実際にはツール呼び出しを提案しているにすぎず、自分で実行はできません。

シェルツールはモデルの能力を劇的に強化します。コマンドラインを通じてコンピュータとやり取りし、テキスト検索からローカルでのAPIリクエスト送信まで幅広いタスクを実行できます。Unix に馴染みのあるユーティリティをベースとし、grep、curl、awk といったツールがそのまま利用可能です。既存の code interpreter（Python のみを実行）と比べて、シェルツールは Go や Java のプログラムを実行したり、NodeJS サーバーを起動したりできるなど、はるかに幅広いユースケースを可能にします。この柔軟性がモデルに複雑なエージェンティックなタスクを遂行させます。

エージェントループのオーケストレーション

モデル単体ではシェルコマンドを提案するだけですが、それらのコマンドはどのように実行されるのでしょうか。モデル出力を取得し、ツールを呼び出し、ツールのレスポンスをモデルに返すオーケストレータが必要です。これを繰り返してタスク完了まで進めます。

Responses API は開発者が OpenAI モデルとやり取りするためのインターフェースです。カスタムツールと組み合わせた場合、Responses API はクライアントに制御を戻しますが、クライアントは自前のランタイムを必要とします。一方、Responses API はホストされたツールとの間でのオーケストレーションをそのままサポートすることもできます。

Responses API がプロンプトを受け取ると、ユーザープロンプト、過去の会話状態、ツールの指示を組み合わせてモデルコンテキストを組成します。シェル実行を動作させるには、プロンプトがシェルツールの利用を明示し、選択されたモデルがシェルコマンドを提案するよう訓練されている必要があります。モデル GPT‑5.2 以降はシェルコマンドを提案するよう訓練されています。

このようなコンテキストが整うと、モデルは次のアクションを決定します。シェル実行を選ぶと、モデルは1つ以上のシェルコマンドを Responses API サービスへ返します。API サービスはそれらのコマンドをコンテナランタイムに転送し、シェル出力をストリーミングで受け取り、それを次のリクエストのコンテキストとしてモデルに渡します。モデルは結果を検査し、追従コマンドを出すか、最終回答を生成します。Responses API は、モデルが追加のシェルコマンドを返さずに完了を返すまでこのループを繰り返します。

Responses API がシェルコマンドを実行する際には、コンテナサービスとのストリーミング接続を維持します。出力が生成されるとほぼリアルタイムでそれをモデルへ中継するため、モデルは追加出力を待つか、別のコマンドを実行するか、最終レスポンスへ移るかを判断できます。

並列実行と出力の上限

モデルは1ステップで複数のシェルコマンドを提案でき、Responses API はそれらを別々のコンテナセッションで並列実行できます。各セッションは独立に出力をストリームし、API はそれらのストリームを構造化されたツール出力としてコンテキストに多重化します。つまり、ファイル検索、データ取得、中間結果の検証などを並列化できます。

ファイル操作やデータ処理が絡むとシェル出力が非常に大きくなり、コンテキスト予算を消費して有用な信号が埋もれることがあります。これを制御するために、モデルはコマンドごとの出力上限（output cap）を指定します。Responses API はその上限を強制し、先頭と末尾を保持しつつ省略された箇所を明示する形で結果を返します。例えば、出力を1,000文字に制限した場合は次のようになります:

text at the beginning ... 1000 chars truncated ... text at the end

並列実行と出力の上限を組み合わせることで、エージェントループは高速かつコンテキスト効率が良くなり、生の端末ログに圧倒されずに関連結果に基づいて推論を続けられます。

コンテキストウィンドウが一杯になったとき：コンパクション（compaction）

エージェントループの問題の一つは、タスクが長時間にわたることです。長時間のタスクはコンテキストウィンドウを埋めますが、ウィンドウはターン間・エージェント間で文脈を渡すために重要です。エージェントがスキルを呼び、レスポンスを得て、ツール呼び出しや推論の要約を追加していくと、限られたウィンドウはすぐに満杯になります。

重要なコンテキストを失わないようにするには、重要な詳細を保持し、冗長な部分を削る仕組みが必要です。開発者にカスタムの要約や状態保持システムを設計・維持させる代わりに、Responses API にネイティブなコンパクション機能を追加しました。これはモデルの振る舞いと訓練に合わせて設計されています。

最新のモデルは、過去の会話状態を分析して、重要な過去の状態を暗号化されたトークン効率の良い表現で保持するコンパクションアイテムを生成するよう訓練されています。コンパクション後の次のコンテキストウィンドウは、このコンパクションアイテムと、以前のウィンドウの高価値部分で構成されます。これにより、長期のマルチステップやツール駆動セッションでも、ウィンドウ境界を跨いでワークフローを一貫して続けられます。

Codex は長時間のコーディングタスクや反復的なツール実行を品質を落とさずに維持するためにこの仕組みを活用しています。コンパクションはサーバー側組み込みか、独立した /compact エンドポイント経由で利用できます。サーバー側コンパクションでは閾値を設定でき、システムが自動でコンパクションのタイミングを管理するため、複雑なクライアント側ロジックは不要になります。また、コンパクション直前の小さなオーバーエイジ（入力が限界近くなること）を許容するため、限界近くのリクエストも拒否されるのではなく処理されてコンパクト化されます。

モデル訓練が進化するにつれて、ネイティブなコンパクションソリューションも各 OpenAI モデルリリースに合わせて進化します。Codex はコンパクションシステムの構築に関わり、同時にその早期ユーザーでもありました。ある Codex インスタンスがコンパクションエラーを起こした際、別のインスタンスを立ち上げて調査し、結果的に Codex はネイティブで実効的なコンパクションシステムを得ました。Codex が自分を検査して改善していける能力は、OpenAI 内での作業の中でも特に興味深い点です。ほとんどのツールは使い方をユーザーが学ぶ必要がありますが、Codex は我々と共に学びます。

コンテナコンテキスト（Container context）

次に状態とリソースについて説明します。コンテナはコマンドを実行する場所であるだけでなく、モデルの作業コンテキストでもあります。コンテナ内ではモデルがファイルを読み、データベースをクエリし、ネットワークポリシー制御下で外部システムにアクセスできます。

ファイルシステム

コンテナコンテキストの第一はファイルシステムです。リソースのアップロード、整理、管理のためにコンテナおよびファイル APIs を構築し、モデルが利用可能なデータの地図を得て、広範でノイジーなスキャンではなくターゲットを絞ったファイル操作を選べるようにしました。

よくあるアンチパターンは、すべての入力を直接プロンプトに詰め込むことです。入力が増えるとプロンプトのオーバーフィルはコストがかかり、モデルがナビゲートしづらくなります。より良いパターンは、リソースをコンテナのファイルシステムにステージングし、モデルに必要なときに開いたり解析したり変換したりさせることです。人間と同様に、モデルも整理された情報の方が扱いやすいです。

データベース

コンテナコンテキストの第二はデータベースです。多くの場合、構造化データは SQLite のようなデータベースに格納し、クエリさせることを推奨します。例えばスプレッドシート全体をプロンプトにコピーする代わりに、テーブルの説明（どの列があり何を意味するか）を与え、モデルに必要な行だけを引かせることができます。たとえば「どの製品が今四半期に売上が減少したか？」と問うと、モデルは関連する行だけをクエリしてスキャンせずに済みます。これにより高速で低コスト、大規模データセットへのスケーラビリティが向上します。

ネットワークアクセス

コンテナコンテキストの第三はネットワークアクセスで、エージェントワークロードに不可欠です。エージェントはライブデータの取得、外部APIの呼び出し、パッケージのインストールを必要とすることがあります。一方で、コンテナに無制限のインターネットアクセスを与えるとリスクが高まります。外部サイトへの情報露出、内部／サードパーティシステムへの意図しないアクセス、資格情報の漏えいやデータ持ち出しのリスクが増大します。

利便性を損なわずにこれらの懸念に対応するため、ホストされたコンテナはサイドカー型の egress proxy を使います。すべてのアウトバウンドネットワークリクエストは中央のポリシーレイヤーを通り、allowlist やアクセス制御を強制しつつトラフィックの可観測性を確保します。資格情報については、egress 側でドメインスコープのシークレット注入を使います。モデルとコンテナはプレースホルダしか見ず、生のシークレット値はモデル可視コンテキストの外に留まり、承認済みの送信先にのみ適用されます。これにより漏えいリスクを下げつつ、認証付きの外部呼び出しを可能にします。

コンテナセットアップとスキル

シェルコマンドは強力ですが、多くのタスクは同じマルチステップのパターンを繰り返します。エージェントは毎回ワークフローを再発見し、再計画し、コマンドを再発行し、慣習を再学習する必要があるため、一貫性に欠け実行の無駄が生じます。

エージェントスキル（Agent skills）はそのようなパターンを再利用可能で組み合わせ可能な部品としてパッケージ化します。具体的には、スキルは SKILL.md（メタデータと指示を含む）と、API仕様やUI資産などのサポートリソースを含むフォルダバンドルです。この構造は前述のランタイムアーキテクチャと自然に対応します。コンテナは永続的なファイルと実行コンテキストを提供し、シェルツールは実行インターフェースを提供します。

モデルは必要に応じてシェルコマンド（ls, cat など）でスキルファイルを発見し、指示を解釈し、スキルスクリプトを同じエージェントループ内で実行できます。OpenAI プラットフォーム上でスキルを管理するための APIs を提供しており、開発者はスキルフォルダをアップロードして保存できます。

（注）本稿は Responses API、シェルツール、ホストされたコンテナワークスペース、スキルの設計と運用に関する概要を示すものであり、実装の細部や最新の仕様は公式ドキュメントと API リファレンスを参照してください。