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

2026年3月11日 エンジニアリング Bo Xu、Danny Zhang、Rohit Arunachalam著

現在、特定のタスクに優れたモデルの使用から、複雑なワークフローを処理できるエージェントの使用へとシフトしています。モデルにプロンプトを与えることで、訓練された知能にのみアクセスできます。しかし、モデルにコンピュータ環境を与えることで、サービスの実行、APIからのデータ要求、スプレッドシートやレポートなどのより有用なアーティファクトの生成など、はるかに幅広いユースケースを実現できます。

エージェントを構築しようとすると、いくつかの実用的な問題が浮上します：中間ファイルをどこに置くか、大きなテーブルをプロンプトに貼り付けることを避ける方法、セキュリティの問題を作らずにワークフローにネットワークアクセスを与える方法、そして独自のワークフローシステムを構築せずにタイムアウトと再試行を処理する方法です。

開発者が独自の実行環境を構築することに任せる代わりに、Responses APIに現実世界のタスクを確実に実行するためのコンピュータ環境を装備するために必要なコンポーネントを構築しました。

OpenAIのResponses APIは、shellツールとホストされたコンテナワークスペースと組み合わせて、これらの実用的な問題に対処するよう設計されています。モデルがステップとコマンドを提案し、プラットフォームがそれらを入出力用のファイルシステム、オプションの構造化ストレージ（SQLiteなど）、制限されたネットワークアクセスを持つ分離された環境で実行します。

この投稿では、エージェント用のコンピュータ環境をどのように構築したかを詳しく説明し、より高速で、より再現可能で、より安全な本番ワークフローでそれを使用する方法についての初期の教訓を共有します。

shellツール

優れたエージェントワークフローは、厳密な実行ループから始まります：モデルがファイルの読み取りやAPIでのデータ取得などのアクションを提案し、プラットフォームがそれを実行し、結果が次のステップに供給されます。最初にshellツール（このループを実際に見る最も簡単な方法）について説明し、その後コンテナワークスペース、ネットワーキング、再利用可能なスキル、コンテキスト圧縮について説明します。

shellツールを理解するには、まず言語モデルが一般的にツールをどのように使用するかを理解することが有用です：関数を呼び出したり、コンピュータと対話したりするためです。訓練中、モデルはツールがどのように使用され、その結果どのような効果が生じるかの例を段階的に示されます。これにより、モデルはいつツールを使用するか、どのように使用するかを決定することを学習します。

「ツールを使用する」と言うとき、実際にはモデルはツール呼び出しを提案するだけです。それ自体では呼び出しを実行できません。

shellツールはモデルを劇的により強力にします：テキストの検索からコンピュータでのAPI要求の送信まで、幅広いタスクを実行するためにコマンドラインを通じてコンピュータと対話します。馴染みのあるUnixツールに基づいて構築された私たちのshellツールは、grep、curl、awkなどのユーティリティがすぐに利用できる状態で、期待されるあらゆることを実行できます。

Pythonのみを実行する既存のコードインタープリターと比較して、shellツールはGoやJavaプログラムの実行やNodeJSサーバーの起動など、はるかに幅広いユースケースを可能にします。この柔軟性により、モデルは複雑なエージェントタスクを実行できます。

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

モデル単体ではshellコマンドを提案することしかできませんが、これらのコマンドはどのように実行されるのでしょうか？モデル出力を取得し、ツールを呼び出し、タスクが完了するまでツールレスポンスをループでモデルに戻すオーケストレーターが必要です。

Responses APIは、開発者がOpenAIモデルと対話する方法です。カスタムツールと一緒に使用される場合、Responses APIは制御をクライアントに戻し、クライアントはツールを実行するための独自のハーネスを必要とします。しかし、このAPIは、モデルとホストされたツールの間をすぐにオーケストレートすることもできます。

Responses APIがプロンプトを受信すると、モデルコンテキストを組み立てます：ユーザープロンプト、以前の会話状態、ツール指示。shell実行が機能するには、プロンプトでshellツールの使用について言及し、選択されたモデルがshellコマンドを提案するよう訓練されている必要があります—GPT-5.2以降のモデルがこのために訓練されています。

このすべてのコンテキストで、モデルは次のアクションを決定します。shell実行を選択した場合、1つ以上のshellコマンドをResponses APIサービスに返します。APIサービスはそれらのコマンドをコンテナランタイムに転送し、shell出力をストリームバックし、次のリクエストのコンテキストでモデルに供給します。モデルは結果を検査し、フォローアップコマンドを発行するか、最終回答を生成できます。

Responses APIは、モデルが追加のshellコマンドなしで完了を返すまで、このループを繰り返します。

Responses APIがshellコマンドを実行するとき、コンテナサービスへのストリーミング接続を維持します。出力が生成されると、APIはそれをほぼリアルタイムでモデルに中継し、モデルがより多くの出力を待つか、別のコマンドを実行するか、最終応答に移るかを決定できます。

Responses APIはshellコマンド出力をストリーミング

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

コマンドがファイル操作やデータ処理を含む場合、shell出力は非常に大きくなり、有用な信号を追加せずにコンテキスト予算を消費する可能性があります。これを制御するために、モデルはコマンドごとに出力上限を指定します。Responses APIはその上限を強制し、省略されたコンテンツをマークしながら、出力の開始と終了の両方を保持する境界のある結果を返します。

例えば、出力を1,000文字に制限し、開始と終了を保持することができます：

開始のテキスト ... 1000文字が切り捨てられました ... 終了のテキスト

同時実行と境界のある出力により、エージェントループは高速でコンテキスト効率的になり、モデルは生のターミナルログに圧倒されることなく、関連する結果について推論を続けることができます。

コンテキストウィンドウが満杯になったとき：圧縮

エージェントループの潜在的な問題の1つは、タスクが長時間実行される可能性があることです。長時間実行されるタスクはコンテキストウィンドウを満たし、これはターン間およびエージェント間でコンテキストを提供するために重要です。

エージェントがスキルを呼び出し、応答を取得し、ツール呼び出しと推論要約を追加する様子を想像してください—限られたコンテキストウィンドウはすぐに満杯になります。

エージェントが実行を続ける際に重要なコンテキストを失うことを避けるために、重要な詳細を保持し、余分なものを削除する方法が必要です。

開発者がカスタムの要約や状態保持システムを設計・維持することを要求する代わりに、モデルの動作とその訓練方法に合わせて設計されたResponses APIにネイティブ圧縮を追加しました。

私たちの最新モデルは、以前の会話状態を分析し、暗号化されたトークン効率的な表現で重要な以前の状態を保持する圧縮アイテムを生成するよう訓練されています。圧縮後、次のコンテキストウィンドウは、この圧縮アイテムと以前のウィンドウの高価値部分で構成されます。

これにより、拡張されたマルチステップおよびツール駆動セッションでも、品質を低下させることなく、ワークフローがウィンドウ境界を越えて一貫して継続できます。Codexは、長時間実行されるコーディングタスクと反復的なツール実行を品質を低下させることなく維持するために、このメカニズムに依存しています。

圧縮は、サーバー内蔵またはスタンドアロンの/compactエンドポイントを通じて利用できます。サーバーサイド圧縮では閾値を設定でき、システムが圧縮タイミングを自動的に処理し、複雑なクライアントサイドロジックの必要性を排除します。これにより、圧縮直前の小さな超過を許容するわずかに大きな有効入力コンテキストウィンドウが可能になり、制限近くのリクエストも拒否されるのではなく処理・圧縮されます。

モデル訓練が進化するにつれて、ネイティブ圧縮ソリューションもすべてのOpenAIモデルリリースでそれと共に進化します。

Codexは、それの初期ユーザーとして機能しながら、圧縮システムの構築を支援しました。1つのCodexインスタンスが圧縮エラーに遭遇したとき、調査のために2番目のインスタンスを起動しました。結果として、Codexは問題に取り組むだけでネイティブで効果的な圧縮システムを得ました。

Codexが自分自身を検査し改良するこの能力は、OpenAIで働く特に興味深い部分になっています。ほとんどのツールはユーザーがそれらの使用方法を学ぶことのみを要求しますが、Codexは私たちと一緒に学習します。

コンテナコンテキスト

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

ファイルシステム

コンテナコンテキストの最初の部分は、リソースのアップロード、整理、管理のためのファイルシステムです。モデルに利用可能なデータのマップを提供し、広範囲でノイズの多いスキャンを実行する代わりに、対象を絞ったファイル操作を選択するのを支援するために、コンテナとファイルAPIを構築しました。

一般的なアンチパターンは、すべての入力を直接プロンプトコンテキストに詰め込むことです。入力が増加すると、プロンプトの過充填は高価になり、モデルがナビゲートするのが困難になります。より良いパターンは、リソースをコンテナファイルシステムにステージングし、モデルがshellコマンドで何を開き、解析し、変換するかを決定させることです。

人間と同様に、モデルは整理された情報でより良く機能します。

データベース

コンテナコンテキストの2番目の部分はデータベースです。多くの場合、開発者が構造化データをSQLiteなどのデータベースに保存し、それらをクエリすることを提案します。例えば、スプレッドシート全体をプロンプトにコピーする代わりに、モデルにテーブルの説明（どの列が存在し、それらが何を意味するか）を与え、必要な行を取得させることができます。

例えば、「今四半期に売上が減少した製品はどれですか？」と尋ねた場合、モデルはスプレッドシート全体をスキャンする代わりに、関連する行のみをクエリできます。これはより高速で、より安価で、より大きなデータセットにスケーラブルです。

ネットワークアクセス

コンテナコンテキストの3番目の部分は、エージェントワークロードの重要な部分であるネットワークアクセスです。エージェントワークフローは、ライブデータの取得、外部APIの呼び出し、パッケージのインストールが必要な場合があります。

同時に、コンテナに無制限のインターネットアクセスを与えることはリスクがあります：外部ウェブサイトに情報を露出させたり、意図せずに機密の内部またはサードパーティシステムに触れたり、認証情報の漏洩やデータ流出を防ぐことを困難にする可能性があります。

エージェントの有用性を制限することなくこれらの懸念に対処するために、サイドカーエグレスプロキシを使用するホストされたコンテナを構築しました。すべてのアウトバウンドネットワーク要求は、トラフィックを観察可能に保ちながら許可リストとアクセス制御を強制する集中化されたポリシー層を通過します。

認証情報については、エグレスでドメインスコープの秘密注入を使用します。モデルとコンテナはプレースホルダーのみを見て、生の秘密値はモデルに見えるコンテキストの外に留まり、承認された宛先に対してのみ適用されます。これにより、認証された外部呼び出しを可能にしながら漏洩のリスクを軽減します。

エージェントスキル

shellコマンドは強力ですが、多くのタスクは同じマルチステップパターンを繰り返します。エージェントは各実行で同じワークフローを再発見する必要があり—再計画、再発行コマンド、再学習規約—一貫性のない結果と実行の無駄につながります。

エージェントスキルは、これらのパターンを再利用可能で構成可能な構築ブロックにパッケージ化します。

具体的には、スキルは、メタデータと指示を含む「SKILL.md」と、API仕様やUIアセットなどのサポートリソースを含むフォルダバンドルです。この構造は、前述したランタイムアーキテクチャに自然にマップされます。

コンテナは永続ファイルと実行コンテキストを提供し、shellツールは実行インターフェースを提供します。両方が整っていれば、モデルは必要に応じてshellコマンド（ls、catなど）を使用してスキルファイルを発見し、指示を解釈し、同じエージェントループでスキルスクリプトを実行できます。

OpenAIプラットフォームでスキルを管理するためのAPIを提供しています。開発者はスキルフォルダをアップロードして保存します。