For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme
Feb 11, 2026 API

シェル、スキル、コンパクション:実務を担う長時間稼働エージェントの設計のヒント

Responses API のスキル、ホスト型シェル、サーバー側コンパクションを活用した実践的な開発パターンを紹介します。

著者: Charlie Guo

シェル、スキル、コンパクション:実務を担う長時間稼働エージェントの設計のヒント

アシスタントとのやり取りが 1 ターンで完結する段階から、エージェントが長時間にわたって実際の知識労働を担う段階へと移りつつあります。大規模なデータセットを読み込み、ファイルを更新し、アプリを開発するといった仕事です。

開発者の皆さまからのフィードバックと、OpenAI が 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 によると、スキルが呼び出されたときだけ例が読み込まれるこの設計は、本番環境で品質向上とレイテンシ削減に最も大きく貢献した施策の一つでした。

4)コンテナの再利用とコンパクションを前提とした長時間実行の設計

長時間にわたる作業を担うエージェントが、ワンショットのプロンプトだけでうまく動くことはまれです。最初から作業を継続できるように設計しましょう。

  • 依存関係を一定に保ち、キャッシュしたファイルや中間出力を引き継ぎたい場合は、複数のステップで同じコンテナを再利用します。
  • previous_response_id を渡し、モデルが同じスレッドで作業を続けられるようにします。
  • コンパクションは緊急時の対処に限らず、長時間実行で標準的に使う機能として組み込みます。

この組み合わせにより、作業を最初からやり直すことが減り、スレッドが長くなっても複数ステップにわたるジョブの一貫性を保てます。

5)毎回同じ手順で実行するためのスキルの明示

デフォルトでは、スキルをいつ使うかはモデルが判断します。多くの場合はそれで十分です。

一方、実行すべき手順が明確な本番ワークフローで、柔軟な判断よりも毎回同じ動作を優先したい場合は、次のように指示します。

「<skill name> スキルを使ってください。」

これは信頼性を高める最も簡単な方法です。どのスキルを選ぶかを曖昧な判断に委ねず、実行要件として明示できます。

6)スキルとネットワークの併用に伴うリスクと、その封じ込め

設計時には見落としやすく、後から直すのが難しいセキュリティ上の注意点です。

スキルと制限のないネットワークアクセスを組み合わせると、データを外部に持ち出されるリスクが高まります。 ネットワークを使う場合は、許可リストを厳しく絞り、ツールの出力は信頼できないものとして扱ってください。重要な操作には確実な確認が入るとユーザーが期待する一般消費者向けのフローでは、制限のないインターネットアクセスと強力な操作手順の併用を避けます。

安全性を重視する場合の基本設定は次のとおりです。

  • スキル:許可
  • シェル:許可
  • ネットワーク:対象を限定したタスクについて、リクエストごとに必要最小限の許可リストを設定した場合のみ有効

7)成果物の受け渡し場所は /mnt/data に統一

ホスト型シェルを使うワークフローでは、後で取得してレビューする成果物や、後続のステップに渡す成果物の標準の保存先を /mnt/data にします。レポート、クリーニング済みのデータセット、完成したスプレッドシートなどが該当します。

ツールはディスクに書き込み、モデルはディスク上のデータをもとに推論し、開発者はディスクから成果物を取得する、と考えると役割が明確になります。

8)組織とリクエストの 2 段階の許可リスト

ネットワークアクセスは次の 2 か所で制御します。

  • 管理者が設定する組織レベルの許可リスト。許可できる接続先の範囲を定めます。
  • リクエストレベルの network_policy。指定できる接続先は組織の許可リストの範囲内に限られます。

運用では次の 2 点が重要です。

  1. 組織の許可リストは「信頼できる承認済みの接続先」に絞り、頻繁に変更しないようにします。
  2. リクエストの許可リストはさらに絞り、「今回のジョブに必要な接続先」だけを含めます。

組織の許可リストにないドメインがリクエストに含まれていると、エラーになります。

9)認証付き呼び出しでの domain_secrets の利用(認証情報の漏えい防止)

許可したドメインで認証ヘッダーが必要な場合は、domain_secrets を使います。これにより、認証情報の実際の値がモデルに見えることはありません。

実行時にモデルに見えるのはプレースホルダー(例:$API_KEY)です。サイドカーが、承認済みの接続先に対してのみ実際の値を挿入します。エージェントがコンテナ内から認証の必要な API を呼び出すときは、この方法を標準にすると安全です。

10)クラウドとローカルで共通の API

すべてをホスト環境で動かすと決めなくても、スキルとシェルの両方を利用できます。

  • スキルはホスト型シェルとローカルシェルモードの両方で使えます。
  • シェルにはローカル実行モードがあります。開発者が shell_call を実行し、shell_call_output をモデルに返します。
  • Agents SDK を使っている場合は、独自のシェル実行機構も組み込めます。

実際の開発は次の流れで進められます。

  1. ローカルで始めます。変更をすばやく試せるうえ、社内ツールを利用でき、デバッグも容易です。
  2. 再現性、実行環境の分離、デプロイ環境の一貫性が必要になったら、ホスト型コンテナに移します。
  3. 両方のモードで同じスキルを使います。実行場所が変わってもワークフローを維持できます。

3 つの実装パターン

これらの新しい基本機能は自由に組み合わせて試せます。ここでは、実用的なアプリを開発するための組み合わせを 3 つ紹介します。

パターン A:インストール → データ取得 → 成果物の書き出し

ホスト型シェルを活用する最もシンプルな方法です。エージェントが依存パッケージをインストールし、外部データを取得して、具体的な成果物を作成します。

たとえば、次のように進めます。

  • 必要なライブラリを 2 つインストールします。
  • スクレイピングを行うか、API を呼び出します。
  • レポートを /mnt/data/report.md に書き出します。

このパターンは実務を担うエージェントの基礎になります。成果物を書き出すことで、何をレビューすればよいかが明確になります。アプリはその成果物をユーザーに表示したり、ログに記録したり、差分を確認したり、後続のステップに渡したりできます。

パターン B:スキルとシェルによる再現性のあるワークフロー

シェルを使ったワークフローを 1 つか 2 つ作ってうまく動かせるようになると、次の課題が見えてきます。今は動いていても、プロンプトの内容が少しずつ変わると、動作の信頼性が落ちていきます。

そこでスキルが役立ちます。次のように構成すると、安定した運用を続けられます。

  1. ワークフローの手順、ガードレール、テンプレートをスキルにまとめます。
  2. スキルをシェル環境にマウントします。
  3. エージェントにスキルの手順に従って成果物を生成させ、毎回の動作を一定に保ちます。

この方法は、特に次のようなワークフローに効果的です。

  • スプレッドシートの分析や編集
  • データセットのクリーニングと要約の生成
  • 定期的に行う業務での定型レポートの生成

パターン C(応用):企業の業務手順をスキルに集約

導入初期には、単一のツールを呼び出す場合に比べ、複数のツールを連携させると精度が落ちる傾向が見られました。スキルを使うと、システムプロンプトを肥大化させずに、モデルがツールの使い方を判断する過程を手順として整理し、この精度差を縮められます。

Glean では次のような成果が得られました。

  • Salesforce 向けのスキルにより、評価での正答率が 73% から 85% に向上し、最初のトークンが返るまでの時間が 18.1% 短縮されました。
  • 具体的には、スキルを選ぶ条件を入念に設計し、反例を用意し、テンプレートや例をスキルに組み込みました。
  • Glean は、企業のワークフローで繰り返すタスクの手順もスキルにまとめています。顧客別の営業計画の策定、エスカレーション案件のトリアージ、ブランドに合ったコンテンツの生成などがその例です。

こうした使い方で、スキルの真価が発揮されます。スキルは、組織の変化に合わせて更新でき、エージェントが一貫して実行できる標準作業手順書(SOP)になります。

一度の実装で、どの環境でも実行可能に

長時間稼働するエージェントは、手順に従うだけでなく、コンピューター上で実際に作業できるようになると、実用性が飛躍的に高まります。その基盤となるのがスキル、ホスト型シェル、コンパクションです。要点を振り返ります。

  • スキルには作業の進め方をまとめます。手順、テンプレート、ガードレールを含めます。
  • シェルで実際の作業を行います。依存パッケージをインストールし、スクリプトを実行し、成果物を書き出します。
  • コンパクションを使い、コンテキストを手作業で管理せずに、長時間実行でも作業の一貫性を保ちます。
  • 短いサイクルで試行錯誤するときは、ローカルで始めます。
  • 分離された環境で同じ作業を繰り返し実行したい場合は、ホスト型コンテナに移します。
  • 組織レベルとリクエストレベルの許可リストでネットワークアクセスを厳しく制限し、認証付きの呼び出しにはドメインシークレットを使います。

ぜひ、ご自身のアプリで試してみてください。導入方法は、スキルのドキュメント、シェルのドキュメント、コンパクションのドキュメントで確認できます。