単一ターンで応答するアシスタントから、大規模なデータセットの読み込み、ファイルの更新、アプリの作成といった実際の知識労働を担う、長時間実行エージェントへの移行が進んでいます。
開発者からのフィードバックと、Codex や社内エージェントを開発してきた経験を踏まえ、長時間にわたる作業をより実用的にする、エージェント向けの新たな基本機能を公開します。
- スキル（オープン標準の Agent Skills に準拠）：コンテナにマウントできる、再利用可能でバージョン管理された指示です。エージェントによるタスク実行の信頼性を高めます。
- 強化されたシェルツール：インターネットアクセスを制御できる、OpenAI がホストするコンテナです。エージェントが依存関係をインストールし、スクリプトを実行して、レポートや成果物などの出力を書き込めます。
- サーバー側コンパクション：エージェントの長時間実行中にコンテキストを自動で圧縮し、コンテキストの上限に達するのを防ぐ簡単な方法
上記の各機能は、ドキュメントと API リファレンスで個別に解説しています。本記事では、OpenAI での取り組みと、スキルの初期導入企業である Glean の本番環境で、これまで特に効果があった、見落としがちなヒントやパターンを紹介します。
基本的な考え方
スキル：モデルが必要に応じて読み込める「手順」
スキルは、一連のファイルと、フロントマターや指示を記載した SKILL.md マニフェストで構成されます。モデルが実際の作業に取りかかるときに参照できる、バージョン管理された手順書と考えてください。
スキルが利用可能な場合、プラットフォームは各スキルの name、description、path をモデルに提示します。モデルはこのメタデータを使い、スキルを呼び出すかどうかを判断します。呼び出す場合は、SKILL.md を読んでワークフロー全体を確認します。
シェルツール：エージェントのための「実行」機能
シェルツールを使うと、モデルは次のいずれかの実際のターミナル環境で作業できます。
- OpenAI が管理するホスト型コンテナ
- 開発者自身が実行するローカルシェルのランタイム（ツールの動作仕様は同じですが、マシンは開発者が管理します）
ホスト型シェルは Responses API を通じて動作するため、リクエストでは状態を保持した作業、ツール呼び出し、複数ターンにわたる作業の継続、成果物を扱えます。
コンパクション：長時間実行の継続
ワークフローが長くなると、コンテキストウィンドウの上限に達します。サーバー側コンパクションは、コンテキストウィンドウを管理し、会話履歴を自動で圧縮することで、長時間の実行を継続できるようにします。
Responses API のコンパクションには、そのための方法が 2 つあります。
- サーバー側コンパクション（新機能）： コンテキストがしきい値を超えると、ストリーム内でコンパクションが自動実行されるため、コンパクションを別途呼び出す必要がありません。
- 独立したコンパクション用エンドポイント： コンパクションの実行タイミングを明示的に制御したい場合は、
/responses/compactを使用します。
組み合わせるメリット
- スキルは、定型的な手順や例を再利用可能なパッケージにまとめることで、プロンプトの複雑化を抑えます。
- シェルは、コードのインストール、スクリプトの実行、出力の書き込みができる、完全な実行環境を提供します。
- コンパクションは長時間実行の連続性を保つため、コンテキストを手作業で整理しなくても、同じワークフローを実行し続けられます。
- これらを組み合わせると、システムプロンプトを巨大で壊れやすい文書にすることなく、実際の処理を伴う再現可能なワークフローを構築できます。
活用のヒントとコツ
1) 宣伝文句ではなく、振り分けの判断基準となるスキルの説明
スキルの説明は、実質的にモデルの判断基準になります。次の問いに答える内容にしてください。
- どのような場合にこのスキルを使うべきですか？
- どのような場合にこのスキルを使うべきではありませんか？
- 出力と成功基準は何ですか？
実用的な方法は、「使う場合・使わない場合」を短くまとめた項目を説明に直接含め、入力、使用するツール、期待される成果物などを具体的に記載することです。
2) 誤った呼び出しを減らすための、使用対象外の例とエッジケースの追加
意外な失敗パターンとして、スキルを利用可能にすると、導入当初は正しく呼び出される割合が下がることがあります。対策として効果があったのは、使用対象外の例を追加し、エッジケースも扱うことです。
具体的には、「このような場合は、このスキルを呼び出さない」というケースをいくつか明記し、代わりに何をすべきかも記載します。これにより、モデルはより的確に振り分けられます。特に、一見似ているスキルが複数ある場合に役立ちます。
Glean でも、まさにこの現象が見られました。スキルに基づく振り分けを導入した当初、対象を絞った評価では呼び出し率が約 20% 低下しましたが、説明に使用対象外の例とエッジケースを追加したところ、回復しました。
3) テンプレートと例はスキル内に配置（未使用時のコストはほぼゼロ）
システムプロンプトにテンプレートを詰め込んでいるなら、やめましょう。
テンプレートと具体的な実施例をスキル内に置くと、2 つのメリットがあります。
- 必要なとき、つまりスキルが呼び出されたときに利用できます。
- 無関係なクエリでトークン数が増えることはありません。
これは、次のような知識労働の成果物で特に効果的です。
- 構造化されたレポート
- エスカレーション案件のトリアージ結果の要約
- 顧客別の営業計画
- データ分析の報告書
Glean によると、このパターンは本番環境での品質向上とレイテンシ短縮において、特に大きな効果をもたらした取り組みの 1 つでした。例が読み込まれるのは、スキルが呼び出されたときだけだからです。
4) コンテナの再利用とコンパクションを取り入れた、初期段階からの長時間実行の設計
長時間にわたって作業するエージェントは、ワンショットのプロンプトだけでうまくいくことはほとんどありません。最初から作業の継続を前提に計画してください。
- 依存関係を一定に保ち、キャッシュされたファイルや中間出力を維持したい場合は、ステップをまたいで同じコンテナを再利用します。
- モデルが同じスレッドで作業を続けられるよう、
previous_response_idを渡します。 - コンパクションは緊急時の代替策ではなく、長時間実行における標準の基本機能として使います。
この組み合わせにより、最初からやり直す動作が減り、スレッドが長くなっても、複数ステップのジョブの一貫性を保てます。
5) 決められた動作が必要な場合の、スキル使用の明示的な指示
デフォルトでは、スキルをいつ使うかはモデルが判断します。多くの場合、それが望ましい動作です。
ただし、本番環境で明確な取り決めに従うワークフローを実行し、柔軟な判断よりも決められた動作を優先したい場合は、次のように伝えるだけです。
「<skill name> スキルを使ってください。」
これは、信頼性を高めるための最も簡単な手段です。曖昧な振り分けを、明示的な取り決めに変えられます。
6) スキルとネットワークの併用は高リスク（影響の封じ込めを前提とした設計）
これは、今は見過ごしがちでも、後からの修正が難しいセキュリティ上のポイントです。
スキルと制限のないネットワークアクセスを組み合わせると、データが外部に流出するリスクの高い経路が生まれます。 ネットワークを使用する場合は、ネットワークの許可リストを厳しく制限し、ツールの出力は信頼できないものとして扱ってください。また、ユーザーが厳格な確認の仕組みを期待する一般消費者向けのフローでは、制限のないインターネットアクセスと強力な手順の併用を避けてください。
安全性を重視したデフォルト設定は次のとおりです。
- スキル： 許可
- シェル： 許可
- ネットワーク：範囲を絞ったタスクについて、リクエストごとに 最小限の許可リストを設定した場合のみ有効化
7) 成果物の受け渡し場所としての /mnt/data
ホスト型シェルのワークフローでは、後で取得、レビュー、または後続のステップへの入力に使う出力の標準的な保存先を /mnt/data とします。レポート、クリーニング済みのデータセット、完成したスプレッドシートなどが該当します。
ツールがディスクに書き込み、モデルがディスク上の内容をもとに推論し、開発者がディスクから取得する、と考えるとわかりやすいでしょう。
8) 許可リストの 2 層構造（組織レベルとリクエストレベル）
ネットワークアクセスは、次の 2 か所で制御します。
- 許可できる接続先の範囲を定める、組織レベルの許可リスト（管理者が設定）
- 組織の許可リストの範囲内で設定する必要がある、リクエストレベルの
network_policy
運用上のポイントは次の 2 つです。
- 組織の許可リストは小さく保ち、頻繁に変更しないようにします（信頼できる承認済みの接続先に限定します）。
- リクエストの許可リストはさらに絞り込みます（そのジョブに必要な接続先だけに限定します）。
組織の許可リストにないドメインがリクエストに含まれていると、エラーになります。
9) 認証が必要な呼び出しでの domain_secrets の使用（認証情報の漏えい防止）
許可されたドメインで認証ヘッダーが必要な場合は、domain_secrets を使い、認証情報そのものがモデルに一切渡らないようにします。
実行時にモデルに見えるのはプレースホルダー（$API_KEY など）で、サイドカーが承認済みの接続先に対してのみ実際の値を挿入します。エージェントがコンテナ内から保護された API を呼び出す必要がある場合は、この方法を基本とすることをお勧めします。
10) クラウドとローカルで共通の API を使用
すべてをホスト環境で実行すると決めなくても、両方の基本機能を利用できます。
- スキルは、ホスト型シェルとローカルシェルモードの両方で動作します。
- シェルには、
shell_callを自分で実行し、shell_call_outputをモデルに返すローカル実行モードがあります。 - Agents SDK を使っている場合は、独自のシェル実行機構を組み込むこともできます。
実用的な開発サイクルは次のとおりです。
- まずはローカルで始めます（素早く試行錯誤でき、社内ツールにアクセスでき、デバッグも容易です）。
- 再現性、分離性、デプロイの一貫性が必要になったら、ホスト型コンテナに移行します。
- 両方のモードで同じスキルを使い続けます（実行環境が変わってもワークフローを安定させられます）。
3 つの構築パターン
これらの新しいエージェント向け基本機能は、ぜひ自由に試してみてください。ここでは、組み合わせて役立つアプリケーションを構築する例を 3 つ紹介します。
パターン A：インストール -> 取得 -> 成果物の書き出し
ホスト型シェルを活用する最もシンプルな方法です。エージェントが依存関係をインストールし、外部データを取得して、具体的な成果物を作成します。
たとえば、次のような流れです。
- いくつかのライブラリをインストールします。
- スクレイピングを行うか、API を呼び出します。
- レポートを
/mnt/data/report.mdに書き出します。
このパターンではレビューの区切りが明確になるため、実務を担うエージェントの基盤となります。アプリで成果物をユーザーに表示したり、ログに記録したり、差分を確認したり、後続のステップへの入力に使ったりできます。
パターン B：スキルとシェルによる再現可能なワークフロー
シェルを使ったワークフローを 1 つか 2 つうまく構築できると、次の問題に気づくはずです。ワークフローは動くものの、プロンプトが変わっていくと信頼性が低下します。
そこでスキルの出番です。長く使える構成にするには、次の手順に従います。
- ワークフロー（手順、ガードレール、テンプレート）をスキルに記述します。
- スキルをシェル環境にマウントします。
- エージェントにスキルを遵守させ、決められたとおりに成果物を生成させます。
これは特に、次のようなワークフローで効果的です。
- スプレッドシートの分析や編集
- データセットのクリーニングと要約の生成
- 定期的な業務プロセス向けの標準化されたレポートの生成
パターン C（上級）：企業のワークフローをスキルに集約
初期に見られた傾向の 1 つは、単一のツール呼び出しから複数ツールのオーケストレーションへと進む際に、精度が落ちることです。スキルを使えば、システムプロンプトを肥大化させずに、ツールを使う際の推論をより手順に沿ったものにして、この差を埋められます。
Glean の具体例を紹介します。
- Salesforce 向けのスキルにより、評価での正答率が 73% -> 85% に向上し、 最初のトークンが出力されるまでの時間 が 18.1% 短縮されました。
- 具体的な工夫として、慎重なルーティング設計、使うべきでない例の提示、スキル内へのテンプレートや例の組み込みなどを行いました。
- Glean はまた、顧客別の営業計画、エスカレーション案件のトリアージ、ブランドに沿ったコンテンツ生成など、企業のワークフローで繰り返し発生するタスクをスキルに記述しています。
こうした使い方で、スキルは大きな力を発揮します。組織の変化に応じて更新され、エージェントによって一貫して実行される、生きた SOP（標準作業手順書）になるのです。
一度構築すれば、どこでも実行可能
長時間実行するエージェントは、手順に従うだけでなく、コンピューター上で実際の業務もこなせると、格段に役立つようになります。スキル、ホスト型シェル、コンパクションが、その基盤を作ります。要点を振り返ります。
- スキルに「どう進めるか」（手順、テンプレート、ガードレール）を記述します。
- シェルで実際の作業（インストール、実行、成果物の書き出し）を行います。
- コンパクションを使い、コンテキストを手動で管理せずに、長時間の実行でも一貫性を保ちます。
- 素早く試行錯誤したいときは、ローカルから始めます。
- 再現可能で分離された実行環境が必要になったら、ホスト型コンテナに移行します。
- 組織レベルとリクエストレベルの許可リストでネットワークアクセスを厳しく制限し、認証が必要な呼び出しにはドメインシークレットを使います。
ご自身のアプリケーションで試してみてください。具体的な方法は、スキルのドキュメント、シェルのドキュメント、コンパクションのドキュメントをご覧ください。