現在は、特定のタスクに優れたモデルを使う段階から、複雑なワークフローを扱えるエージェントを使う段階へと移行しています。モデルにプロンプトを与えるだけでは、学習済みの知識にしかアクセスできません。しかし、モデルにコンピュータ環境を用意することで、サービスの実行や API からのデータ取得、スプレッドシートやレポートといった有用な成果物の生成など、はるかに幅広いユースケースに対応できます。
エージェントを構築しようとすると、いくつかの実務的な課題が生じます。中間ファイルをどこに置くか、大きな表をプロンプトに貼り付けずに済ませるにはどうするか、セキュリティ上のリスクを抑えつつワークフローにネットワークアクセスを与えるにはどうするか、そしてワークフローシステムを自作せずにタイムアウトやリトライをどう扱うか、といった点です。
開発者に独自の実行環境の構築を任せるのではなく、実際のタスクを確実に実行できるよう、Responses API（新しいウィンドウで開く） にコンピュータ環境を備えるための必要なコンポーネントを構築しました。
OpenAI の Responses API は、シェルツールおよびホスト型コンテナのワークスペースと組み合わせることで、これらの実務的な課題に対処できるよう設計されています。モデルが手順とコマンドを提案し、プラットフォームがそれらを隔離された環境で実行します。この環境には、入出力用のファイルシステム、（SQLite のような）任意の構造化ストレージ、制限付きのネットワークアクセスが備わっています。
本記事では、エージェント向けのコンピュータ環境をどのように構築したかを詳しく解説し、より高速で再現性が高く、安全な本番ワークフローに活用するための初期段階の知見を共有します。
優れたエージェントのワークフローは、密に連携した実行ループから始まります。モデルがファイルの読み取りや API を使ったデータ取得といったアクションを提案し、プラットフォームがそれを実行し、その結果が次のステップへと引き継がれます。まずはシェルツールから説明します。これは、このループの動きを確認するための最もシンプルな方法です。その後、コンテナのワークスペース、ネットワーキング、再利用可能なスキル、コンテキスト圧縮について説明します。
シェルツールを理解するには、まず言語モデルが一般にどのようにツールを使うのかを理解しておくと役立ちます。たとえば、関数を呼び出したり、コンピュータとやり取りしたりする場合です。学習中、モデルにはツールの使い方とその結果の例が、ステップごとに示されます。これにより、モデルはツールをいつ使うべきか、またどのように使うべきかを判断できるようになります。ここでいう「ツールを使う」とは、実際にはモデルがツール呼び出しを提案することを指します。モデル自身がその呼び出しを実行することはできません。
シェルツールにより、モデルの能力は大きく広がります。コマンドラインを通じてコンピュータとやり取りし、テキストの検索から API リクエストの送信まで、幅広いタスクを実行できます。当社のシェルツールは、なじみのある Unix ツール群を基盤としており、grep、curl、awk などのユーティリティを最初から利用できます。一般的な操作は一通り実行できます。
Python のみを実行する既存の Code Interpreter と比べ、シェルツールでは、Go や Java のプログラムを実行したり、Node.js サーバーを起動したりといった、より幅広いユースケースに対応できます。この柔軟性により、モデルはエージェントによる複雑なタスクにも対応できます。
モデル単体ではシェルコマンドを提案することしかできませんが、これらのコマンドはどのように実行されるのでしょうか？タスクが完了するまで、モデルの出力を受け取り、ツールを実行し、その結果をモデルに反映する処理を繰り返すオーケストレーターが必要です。
Responses API は、開発者が OpenAI のモデルとやり取りするためのインターフェースです。カスタムツールと併用する場合、Responses API は制御をクライアント側に戻すため、クライアントはツールを実行するための独自の実行基盤を用意する必要があります。一方で、この API には、モデルとホスト型ツールの間の処理を最初から連携できる仕組みも備わっています。
Responses API はプロンプトを受け取ると、ユーザーの入力、これまでの会話の状態、ツールの指示といった情報をもとに、モデルのコンテキストを構成します。シェル実行を機能させるには、プロンプトでシェルツールの使用に言及する必要があり、さらに、選択したモデルがシェルコマンドを提案できるよう学習されている必要があります。GPT‑5.2 以降のモデルはこの用途に対応しています。これらのコンテキストを踏まえて、モデルは次に取るべきアクションを判断します。シェル実行を選択した場合、1つ以上のシェルコマンドを Responses API サービスに返します。API サービスはそれらのコマンドをコンテナランタイムに転送し、シェルの出力をストリーミングで取得し、次のリクエストのコンテキストとしてモデルに渡します。モデルはその結果を確認し、追加のコマンドを実行するか、最終的な回答を生成します。モデルが追加のシェルコマンドを伴わない完了結果を返すまで、Responses API はこのループを繰り返します。
Responses API はシェルコマンドの実行中、コンテナサービスとのストリーミング接続を維持します。出力が生成されると、API はそれをほぼリアルタイムでモデルに中継し、モデルがさらに出力を待つか、別のコマンドを実行するか、最終的な応答に進むかを判断できるようにします。
Responses API はシェルコマンドの出力をストリーミングで返します
モデルは1つのステップで複数のシェルコマンドを提案でき、Responses API はそれらを別々のコンテナセッションで同時に実行できます。各セッションは独立して出力をストリーミングし、API はそれらのストリームをまとめて、構造化されたツール出力としてコンテキストに組み込みます。つまり、エージェントループは、ファイルの検索、データの取得、中間結果の検証といった処理を並列に実行できます。
コマンドにファイル操作やデータ処理が含まれる場合、シェル出力が非常に大きくなり、有用な情報を増やさないままコンテキストの上限を消費してしまうことがあります。これを制御するために、モデルはコマンドごとに出力の上限を指定します。Responses API はその上限を適用し、省略された部分を示しつつ、出力の先頭と末尾を保持した結果を返します。たとえば、出力を1,000文字に制限し、先頭と末尾を保持することができます。
冒頭のテキスト ...（中略：1000文字分）... 末尾のテキスト
並行実行と出力制限を組み合わせることで、エージェントループは高速かつコンテキスト効率の高いものになります。モデルは生のターミナルログに圧倒されることなく、関連する結果に基づいて推論を続けられます。
エージェントループの課題のひとつは、タスクが長時間にわたって実行される可能性があることです。長時間実行されるタスクはコンテキストウィンドウを埋めてしまいますが、このウィンドウはターン間やエージェント間でコンテキストを維持するうえで重要です。エージェントがスキルを呼び出し、応答を受け取り、ツール呼び出しや推論の要約を追加していくと、限られたコンテキストウィンドウはすぐに埋まってしまいます。エージェントの実行が続く中で重要なコンテキストを失わないようにするには、重要な情報を保持し、不要な部分を取り除く仕組みが必要です。開発者がカスタムの要約や状態保持の仕組みを設計・運用する必要がないように、モデルの挙動や学習方法に合わせて設計されたネイティブのコンテキスト圧縮を Responses API に組み込みました。
最新のモデルは、これまでの会話状態を分析し、重要な情報を保持する圧縮データを生成できるように学習されています。このデータは、暗号化され、トークン効率の高い形式で保持されます。 圧縮後のコンテキストウィンドウは、この圧縮データと、以前のウィンドウから選ばれた重要な部分で構成されます。これにより、長時間にわたる複数ステップのツール主導セッションでも、ウィンドウの境界をまたいで一貫性を保ったままワークフローを継続できます。Codex はこの仕組みにより、品質を損なうことなく、長時間にわたるコーディングタスクや反復的なツール実行を継続できます。
コンテキスト圧縮は、サーバーに組み込みで利用するか、またはスタンドアロンの /compact エンドポイントから利用できます。サーバー側のコンテキスト圧縮ではしきい値を設定でき、圧縮のタイミングはシステムが自動的に処理するため、複雑なクライアント側のロジックは不要になります。また、圧縮直前のわずかな超過を許容できるよう、有効な入力コンテキストウィンドウがわずかに拡張されます。これにより、上限に近いリクエストでも拒否されるのではなく、処理されたうえで圧縮されます。モデルの学習が進化するのに合わせて、ネイティブのコンテキスト圧縮も、OpenAI の各モデルリリースごとに進化します。
Codex はこの仕組みの初期ユーザーとして活用されながら、その構築にも貢献しました。ある Codex インスタンスで圧縮エラーが発生した場合には、調査のために別のインスタンスを立ち上げていました。その結果、Codex は問題に取り組む過程で、ネイティブで効果的なコンテキスト圧縮の仕組みを備えるようになりました。Codex が自らの動作を検証し、改善していくこの能力は、OpenAI における取り組みの中でも特に興味深い点のひとつです。多くのツールはユーザーが使い方を学ぶだけですが、Codex は私たちとともに学び続けます。
それでは、状態とリソースについて説明します。コンテナはコマンドを実行する場所であるだけでなく、モデルの作業コンテキストでもあります。コンテナ内では、モデルはファイルを読み取り、データベースをクエリし、ネットワークポリシーの制御下で外部システムにもアクセスできます。
コンテナコンテキストの1つ目の要素は、リソースをアップロード、整理、管理するためのファイルシステムです。モデルに利用可能なデータの一覧を提供し、広範囲にわたるノイズの多いスキャンではなく、対象を絞ったファイル操作を選べるようにするために、コンテナとファイル（新しいウィンドウで開く） API を構築しました。
よくあるアンチパターンは、すべての入力を直接プロンプトのコンテキストに詰め込むことです。入力が増えるにつれて、プロンプトを過剰に詰め込むことはコストがかかり、モデルにとって把握しにくくなります。より良い方法は、コンテナのファイルシステムにリソースをステージングし、シェルコマンドを使って何を開き、解析し、変換するかをモデルに判断させることです。人間と同様に、モデルも情報が整理されているほど、より効果的に機能します。
コンテナのコンテキストの2つ目の要素はデータベースです。多くの場合、構造化データは SQLite などのデータベースに保存し、クエリで取得することを開発者に推奨しています。たとえば、スプレッドシート全体をプロンプトにコピーする代わりに、どの列があり、それぞれが何を意味するかといったテーブルの説明をモデルに与え、必要な行だけを取得させることができます。
たとえば「今四半期に売上が減少した製品はどれですか？」と尋ねると、モデルはスプレッドシート全体をスキャンするのではなく、関連する行だけをクエリできます。これにより、処理はより高速かつ低コストになり、大規模なデータセットにもスケールしやすくなります。
コンテナコンテキストの3つ目の要素はネットワークアクセスです。これは、エージェントのワークロードに不可欠な要素です。エージェントのワークフローでは、ライブデータの取得や外部 API の呼び出し、パッケージのインストールが必要になる場合があります。一方で、コンテナに無制限のインターネットアクセスを許可することにはリスクがあります。外部サイトへの情報露出や、意図しない社内システム・サードパーティシステムへのアクセス、さらには認証情報の漏えいやデータ流出のリスクが高まる可能性があります。
これらの課題に対処しつつエージェントの有用性を損なわないよう、サイドカー構成としてエグレスプロキシを備えたホスト型コンテナを構築しました。すべての外向きのネットワークリクエストは、許可リストとアクセス制御を適用する集中型のポリシーレイヤーを経由し、トラフィックの可観測性も維持されます。認証情報については、エグレス時にドメイン単位でシークレットを注入する仕組みを採用しています。モデルとコンテナが参照するのはプレースホルダーのみで、実際のシークレット値はモデルから見えないコンテキストの外に保持され、許可された宛先に対してのみ適用されます。これにより、認証付きの外部通信を可能にしつつ、情報漏えいのリスクを低減できます。
シェルコマンドは強力ですが、多くのタスクでは同じような複数ステップの処理が繰り返されます。エージェントは実行のたびにワークフローを再構築する必要があり、再計画やコマンドの再発行、慣習の再学習が発生します。その結果、出力の一貫性が損なわれ、無駄な実行が増えます。エージェントスキル（新しいウィンドウで開く）は、こうしたパターンを再利用可能かつ組み合わせ可能なビルディングブロックとして提供します。具体的には、スキルは「SKILL.md（新しいウィンドウで開く）」を含むフォルダー形式のバンドルです。このファイルにはメタデータと手順が含まれ、加えて API 仕様や UI アセットなどの補助リソースも含まれます。
この構造は、先に説明したランタイムアーキテクチャに自然に対応しています。コンテナは永続的なファイルと実行コンテキストを提供し、シェルツールは実行インターフェースを担います。これらが揃うことで、モデルは必要に応じてシェルコマンド（ls、cat など）でスキルファイルを探索し、指示を解釈し、同一のエージェントループ内でスクリプトを実行できます。
OpenAI プラットフォームでは、スキルを管理するための API（新しいウィンドウで開く） を提供しています。開発者はスキルフォルダーをバージョン管理されたバンドルとしてアップロード・保存し、後からスキル ID を使って取得できます。プロンプトをモデルに送信する前に、Responses API がスキルを読み込み、モデルのコンテキストに組み込みます。この処理は決定論的に実行されます。
- スキルのメタデータ（名前や説明）を取得します。
- スキルバンドルを取得し、コンテナにコピーして展開します。
- スキルのメタデータとコンテナのパスをもとに、モデルのコンテキストを更新します。
スキルの関連性を判断する際、モデルはその指示を段階的に確認し、コンテナ内でシェルコマンドを使ってスクリプトを実行します。
これらをまとめると、Responses API は全体の制御を担い、シェルツールは実行アクションを提供します。ホスト型コンテナは永続的な実行環境を提供し、スキルは再利用可能なワークフローのロジックを担います。さらにコンテキスト圧縮により、必要な情報を保ったまま長時間の処理が可能になります。
これらのプリミティブにより、単一のプロンプトからエンドツーエンドのワークフローを実行できます。適切なスキルの特定、データ取得、ローカルな構造化データへの変換、効率的なクエリ、そして永続的な成果物の生成までを一貫して行えます。
以下の図は、ライブデータからスプレッドシートを生成する際の処理の流れを示しています。
Responses API はエージェントによるタスク実行を制御します
シェルツールとコンピュータ環境を組み合わせてエンドツーエンドのワークフローを実現する詳細な例については、開発者向けブログ記事（新しいウィンドウで開く）と Cookbook（新しいウィンドウで開く） をご参照ください。スキルのパッケージ化から Responses API による実行までを解説しています。
この仕組みをもとに開発者の皆さまがどのようなものを構築するのか、楽しみにしています。言語モデルは、テキスト・画像・音声の生成にとどまらず、より複雑な実際のタスクを大規模に処理するための基盤へと進化していきます。当社は今後もその実現に向けてプラットフォームを発展させていきます。
