OpenAI、Responses APIにシェルとコンテナ環境を追加：エージェント向け実行基盤を強化

AIエージェントに実用的なタスクを任せようとすると、これまでは開発者自身が安全なサンドボックスを用意し、ファイルの受け渡しやタイムアウトの再試行処理を一から作り込む必要がありました。

OpenAIは3月11日、Responses API向けにホスト型のコンピューター環境を導入したと発表しました。GPT-5.2以降のモデルを対象に、コマンドラインを直接操作できるシェルツールと、隔離されたコンテナワークスペースが提供されます。

Python限定から脱却した本格シェル環境

これまで提供されていたCode InterpreterはPythonの実行に限定されていましたが、新しいシェルツールはUnix環境をベースにしています。grepやcurl、awkといった標準ツールを標準で利用できます。

これにより、Go言語やJavaで書かれたプログラムの実行や、NodeJSサーバーの起動など、幅広い処理をモデル自身が指示して動かせるようになりました。Responses APIはモデルから提案されたコマンドをバックエンドのコンテナで実行し、結果をストリーミングでモデルに返します。

ターミナルのログが長すぎて文脈を圧迫するのを防ぐため、出力の上限を設定できる機能も備わっています。指定した文字数を超えた場合は、ログの先頭と末尾を残し、中間を省略してモデルに渡す仕組みです。

SQLiteの活用と自己修復するCodex

データ処理のアプローチも変わります。従来は巨大な表データをプロンプトに直接貼り付けるケースが多く見られましたが、新環境ではコンテナ内のファイルシステムやSQLiteデータベースを活用することが推奨されています。モデルは必要な行だけをSQLで取得できるため、コストと処理速度を大幅に改善できます。

また、長時間のタスクでコンテキスト長が上限に達する課題に対しては、ネイティブのコンテキスト圧縮機能が用意されました。過去の実行履歴を安全で効率的な内部表現に要約し、セッションを途切れさせずに継続できます。OpenAIによると、この圧縮機能の開発ではCodex自身が初期ユーザーとなり、発生したバグを別のCodexインスタンスで調査・修正しながら作り上げたといいます。

なぜ重要か

自社でエージェントサービスを開発しているエンジニアにとって、Dockerの管理や実行制御のパイプラインを自作する手間が省けるメリットは非常に大きいです。データ分析や外部APIとの連携を、APIの呼び出しだけで安全な環境に委ねられるようになります。

業界全体で見れば、単にプロンプトに対してテキストを返すモデルの販売から、モデルが自律して動く実行基盤そのものを囲い込む競争へとフェーズが移ったことを示しています。GUIを操作させるアプローチをとる競合に対し、OpenAIはサーバーサイドのコマンドラインという堅牢な領域を確実に固めに来ています。

一方で、コンテナ環境やデータベース、状態圧縮までOpenAIの仕様に依存することになるため、他社プラットフォームへの乗り換えは一段と難しくなります。ネットワークアクセスにはポリシー制御が用意されているとはいえ、機密データを扱う現場ではセキュリティ要件を満たせるか慎重な検証が求められます。