段階的開示とは、すべてを最初からコンテキストウィンドウに置くのではなく、エージェントに情報を必要になるにつれて段階的に読み込ませる手法である。Anthropic のドキュメントはこれを、ファイルシステムベースの Agent Skills アーキテクチャが可能にする特性として示しており、その目的を率直に述べている。常に関連する内容だけがコンテキストウィンドウを占めるようにすることである。同じベンダーによるこのフォーマットについてのエンジニアリング記事（Agent Skills でエージェントを現実世界に対応させる）はさらに踏み込み、これをフォーマットを柔軟かつスケーラブルにする中核的な設計原則と呼んで、まず目次があり、次に特定の章があり、最後に詳細な付録があるよく整理されたマニュアルにたとえている。
用法
このフォーマットについて文書化されているとおり、この戦略は 3 つのレベルで実現される。メタデータ — Skill の YAML フロントマターにある name と description — は常に読み込まれ、起動時にシステムプロンプトに含まれる。そのコストは Skill 1 つあたりおよそ 100 トークンとされている。この 2 つのフィールドのうち、Skill を起動するかどうかを決める際にリクエストと照合されるのは description だとドキュメントは述べている。指示 — SKILL.md の本文 — は、リクエストが一致した時点で初めてファイルシステムから読み込まれ、その予算は 5,000 トークン未満とされている。リソース — 追加の Markdown ファイル、参考資料、実行可能なスクリプト — はアクセスされるまでコストがかからず、参照ファイルは読まれた時点でコンテキストに入り、スクリプトはその出力だけを寄与する。
エンジニアリング記事は、同じ 3 つのレベルを 1 つのリクエストを通してたどっている。コンテキストウィンドウは、中核となるシステムプロンプト、インストール済みのすべてのスキルのメタデータ、そしてユーザーのメッセージから始まる。次にエージェントは Bash ツールを呼び出して該当するスキルの SKILL.md を読むことでそのスキルを起動し、さらに同梱されている別のファイル — 記事の例では、PDF スキルと一緒に提供されている forms.md — を読むことを選び、そうして初めてタスクに取りかかる。第 3 レベルのファイルを読むという判断はエージェント自身のものであり、直前に読み込んだ指示がそのファイルに言及しているためになされると説明されている。
文書化されている帰結は、この段階化から導かれる。起動されていない Skill が占めるのは名前と説明だけなので、多くの Skill をコンテキスト上のペナルティなしにインストールできる。Skill は数十の参照ファイルを同梱できるが、あるタスクが読み込むのは必要な 1 つだけで、残りはコストゼロのままディスク上にとどまる。そして、コード自体がコンテキストウィンドウに入ることがないため、スクリプトはモデルに同等のコードを生成させるよりも効率的である。ドキュメントの例は、寄与のすべてが短い合格メッセージまたはエラーメッセージだけの検証スクリプトであり、エンジニアリング記事の例は、スクリプトも PDF も読み込まれることなく PDF を読んでそのフォームフィールドを抽出するスクリプトである。ファイルシステムとコード実行を備えたエージェントはスキルを全部読む必要がないため、1 つのスキルに同梱できる内容は事実上無制限だと同記事は述べている。
適用される場面
この戦略が当てはまるのは、大量の指針や参考資料が存在するものの、あるタスクに関連するのはそのごく一部だけという場合である。これは 2 つのことを前提としている。1 つは、常に読み込まれる安価な要約だけで高コストの部分が必要かどうかを判断できるように資料を分割できること、もう 1 つは、エージェントが残りをオンデマンドで取得できること — 文書化されている事例では、シェルコマンドで読めるファイルシステム — である。
その失敗モードは 1 つ目の前提にある。残りを読み込むかどうかを判断する根拠は常に読み込まれる説明だけなので、資料が何をするのかと、いつ使うのかの両方を述べていない説明では、より深いレベルに実際には到達できなくなる。同じドキュメントは、まさにこの理由から、その両方を記述することをこのフィールドの要件としている。エンジニアリング記事も作成者の側から同じ点に達しており、エージェントがスキルを起動するかどうかを判断する際に使うのはスキルの name と description であるため、それらに特に注意を払うよう助言している。
この戦略が求める作成者の判断は、どこで分割するかである。同記事の指針は長さを分割のきっかけとしており — SKILL.md が扱いにくくなったら、参照される別々のファイルに分割する — 、コンテキストが互いに排他的であるか、一緒に使われることがまれな場合には、それらの経路を分けておくことでトークン使用量が減るとも付け加えている。分割を促すのはサイズであり、どこで分けるかを導くのは、どの資料が一緒に必要とされるかである。
どの程度確立しているかについて言えば、ここでは独立した 2 つの説明が得られるが、その種類は異なる。一方は、あるベンダーが自社のフォーマットについて書いたドキュメントとエンジニアリング記事であり、3 つのレベルの構成と、そこで述べられたトークン予算を提供するが、戦略の効果についての測定は報告していない。もう一方の OpenDev の報告は、測定を提供するがそのような段階化されたフォーマットは提供せず、それ自体も統制された比較ではなく、単一のシステムについてその作成者が書いた設計報告である。いずれの説明も、この戦略の一般的な評価ではない。
もう 1 つの実現形態
この戦略はドキュメントのフォーマットに縛られていない。ターミナル向けの効果的な AI コーディングエージェントの構築：スキャフォールディング、ハーネス、コンテキストエンジニアリング、そして得られた教訓 は、同じ段階化をエージェントの ツール に適用しており、それについての数値を報告している。この報告は問題をトークンの観点から捉えている。スキーマが平均 200 トークンの外部ツールを 100 個持つシステムは、ツール定義だけで 2 万トークンを費やすため、すべてのスキーマを含めるのは無駄が多く、一方で外部ツールを除外すればエージェントにできることが限られる。OpenDev の答えは遅延発見である。コンテキストは外部ツールのスキーマを 1 つも含まない状態で始まり、エージェントは search_tools ツールを呼び出す。このツールは登録済みのツール名と説明をキーワードクエリに照らしてスコアリングし、一致したものを返す。そのスキーマは以降の呼び出しに入る。3 段階の詳細レベルによって、エージェントはその回答にどれだけのコンテキストを費やすかを選べ、修飾名でツールを呼び出せば、事前の検索なしにそのツールが発見される。報告によれば、すべての外部スキーマを先行して含めていたときには、最初のユーザーメッセージの前にコンテキストの最大 40% を消費しており、遅延発見によってそのベースラインは 5% 未満になり、実際に機能が使われるにつれてのみ増えるようになった。
同報告は、自身のスキルにも同じ 2 段階の扱いを適用している — 起動時には名前、説明、起動条件からなるメタデータのインデックスを置き、完全な内容は呼び出し時にのみ読み込む — そして、このパターンを教訓として一般化している。先行読み込みは規模が大きくなると破綻し、どちらの場合も答えは、起動時にメタデータのインデックスを読み込み、完全な内容の読み込みを使用時点まで遅らせることだ、というのである。報告が挙げるトレードオフは、文書化されたフォーマットにも暗に含まれているものである。発見には追加の往復が 1 回かかり、それは利用可能な項目のうち少数しか使わないワークフローでは元が取れるが、多数を使うワークフローでは、上限はあるにせよ積み重なっていく。
関連用語
- Agent Skills — この戦略が支えるものとして文書化されているフォーマット
- コンテキストエンジニアリング — コンテキストウィンドウを何が占めるかを管理する、より広い実践
- ジャストインタイムのコンテキスト取得 — 取得を遅らせる、密接に関連したアプローチ
- コンパクション — 同じ制約に対する別の対応で、すでに蓄積したコンテキストを削減するもの