OpenAI の開発者ブログに掲載されたこの記事は、Responses API で長期にわたる作業を行うための、記事がエージェント向けプリミティブと呼ぶ一連の機能を紹介したうえで、OpenAI 社内と、初期のスキル顧客とされる Glean の本番環境の双方でこれまで最もうまく機能してきたという、自明ではないパターンに焦点を当てている。3 つのプリミティブとは、コンテナにマウントできる再利用可能でバージョン管理された指示であり Agent Skills のオープン標準に沿ったスキル、インターネットアクセスを制御した OpenAI ホスト型コンテナ上で動く強化版のシェルツール、そして長い実行がコンテキストの上限に達しないよう会話履歴を自動的に圧縮するサーバー側の コンパクション である。
記事は、この 3 つを互いに補完し合うものとして位置づけている。スキルは安定した手順や例をシステムプロンプトから再利用可能なバンドルへ移し、シェルはコードのインストール、スクリプトの実行、出力の書き込みのための完全な実行環境を提供し、コンパクションは長い実行にわたって連続性を保つ。記事による役割分担のまとめは、スキルが「どうやるか」を記述し、シェルが「実行」を担い、コンパクションが長い実行の一貫性を保つ、というものである。
要点
- スキルは、ファイル群と
SKILL.mdマニフェストからなるバンドルとして説明されている。プラットフォームは各スキルのname、description、pathをモデルに提示し、モデルはそのメタデータを使ってスキルを呼び出すかどうかを判断し、その後SKILL.mdを読んでワークフローの全体を把握する。 - コンパクションは 2 つの形で提供される。コンテキストがしきい値を超えるとストリーム内で自動的に実行されるサーバー側のコンパクションと、コンパクションを行うタイミングを明示的に制御するための独立した
/responses/compactエンドポイントである。 - スキルの説明文は、宣伝文句ではなくルーティングロジックのように書くべきだとされる。いつ使うか、いつ使わないか、出力と成功基準は何かを述べるということである。
- スキルを利用可能にすると、当初は正しく呼び出される割合がかえって下がることがある。記事は、説明文に「このような場合はこのスキルを呼び出さない」という明示的な否定例とエッジケースの記述を入れることを推奨している。その根拠は Glean の報告で、スキルベースのルーティングにより対象を絞った評価で呼び出し率が当初約 20% 低下し、それらを追加した後に回復したという。
- テンプレートや実例はシステムプロンプトではなくスキルの中に置くべきだとされる。スキルが呼び出されたときにだけ読み込まれ、無関係なクエリでトークンを膨らませないからである。Glean は、本番環境における品質とレイテンシの最大級の改善の一部をこれによるものとしていると報告されている。
- 長い実行については、ステップをまたいで同じコンテナを再利用すること、
previous_response_idを渡して同じスレッドで継続すること、そしてコンパクションを緊急時の手段ではなく長時間実行のデフォルトのプリミティブとして扱うことを推奨している。 - デフォルトではスキルをいつ使うかはモデルが判断する。本番のワークフローで決定性が必要な場合、記事は特定のスキルを使うようモデルに明示的に指示することを勧めている。
- スキルとオープンなネットワークアクセスの組み合わせは、データ流出の危険性が高い経路だと説明されている。推奨されるデフォルトの姿勢は、スキルとシェルは許可しつつ、ネットワークは範囲の狭いタスクに対してリクエストごとの最小限の許可リストがある場合にのみ有効にし、ツールの出力を信頼できないものとして扱うことである（ガードレール を参照）。
- ネットワークの許可リストは 2 層構造になっている。管理者が設定する組織レベルの許可リストが宛先の上限を定め、リクエストレベルの
network_policyはその部分集合でなければならず、組織の許可リストにないドメインを指定したリクエストはエラーを返す。認証付きの呼び出しでは、domain_secretsによってモデルにはプレースホルダーだけが見え、承認された宛先に対してはサイドカーが実際の認証情報を注入する。 - ホスト型シェルのワークフローでは、成果物の受け渡し境界として
/mnt/dataを使うことが推奨されている。記事の言い回しでは、ツールはディスクに書き、モデルはディスクの内容をもとに推論し、開発者はディスクから取り出す。 - スキルはホスト型シェルと、開発者が
shell_callを実行してshell_call_outputを返すローカルシェルモードの両方で動作する。そのため記事は、ローカルで試行錯誤してから再現性と隔離のためにホスト型コンテナへ移行し、その間スキルは両方で同じものを使い続けることを提案している。 - 3 つの構築パターンが示されている。依存関係をインストールし、データを取得し、成果物を書き出すパターン。ワークフローをスキルに記述してシェルにマウントし、エージェントが決定的に成果物を生成するパターン。そして発展的なパターンとして、スキルを企業のワークフローの運び手として使うパターンである。最後のパターンについて記事は、Salesforce 向けのスキルによって評価の正解率が 73% から 85% に向上し、最初のトークンまでの時間が 18.1% 短縮されたという Glean の報告を引いている。
背景
この記事はベンダーが自社プラットフォームについて示したガイダンスであり、定量的な根拠は単一の顧客である Glean によるとされる数値に限られ、評価方法は説明されていない。締めくくりのイメージ ── スキルが、組織の変化に合わせて更新され、エージェントによって一貫して実行される「生きた標準作業手順書」になる ── は、測定された成果ではなく、このアプローチが向かう先として示されている。本 wiki 内では、スキルとコンテキスト管理によって 長時間稼働エージェント を強化する他の記述、たとえば 段階的開示（Progressive Disclosure） の項で説明されている読み込みの振る舞いなどと並ぶ位置にある。