【ITニュース解説】Progressive Disclosure: What, Where, When, and Why

AIコーディングエージェントは、ソフトウェア開発の現場で私たちの作業を助ける強力なツールである。しかし、そのエージェントにどのように指示を与えるかは、その性能を最大限に引き出す上で非常に重要になる。

初期のAIエージェントとの協業では、「AGENTS.md」のようなファイルにプロジェクトやフォルダのルールを記述する方法が使われていた。これは、指示をその作業が行われる場所に限定し、必要な時にだけ読み込むという点で、画期的な試みであった。例えば、あるフォルダ内の作業をする際、そのフォルダに書かれた指示だけがエージェントに適用されるため、開発者はその指示がその場所にのみ有効であると信頼できた。しかし、この方法にはすぐに課題が見つかった。バックエンドの作業中にフロントエンドの調整も必要になるなど、エージェントが複数の領域にまたがって作業しなければならない場合、それぞれの場所の指示が競合し、エージェントが混乱するという問題が発生した。これは「コンテキストの腐敗」と呼ばれる問題である。

この問題を解決しようと、多くの開発者は全ての指示を一つの大きなファイル（例えば「CLAUDE.md」）に集約するようになった。数百行にもわたるこのファイルは、エージェントがいつでも全てのルールにアクセスできるため、一見すると丁寧で安全な選択肢に思われた。しかし、これはさらに大きな問題を引き起こした。AIモデルは人間がチェックリストを一つずつ確認するように指示を処理するわけではないからだ。モデルは与えられた全ての情報に対して固定された「注意の量」を分散させる。そのため、指示の行数が増えれば増えるほど、個々の指示に割かれる注意は薄まり、本当に重要な指示が多くの無関係な情報の中に埋もれてしまう。例えば、100個のルールがある場合、その時必要な1つのルールは、99個のノイズの中で叫ぶ声のようになり、ほとんど聞き取られなくなる。これは、前述のフロントエンドとバックエンドの指示競合問題が、エージェントに対して恒常的に適用されるようになったようなものである。

実際の調査データもこの問題を裏付けている。約2万9千ものリポジトリを分析した結果、多くの命令ファイルには平均で約50項目が含まれていたが、そのうち実際にエージェントに何かを指示しているのはわずか12個程度であった。残りのほとんどは、モデルが毎回読み飛ばすだけの「足場」となる情報であり、これらも限られた注意の予算を奪い合っていたのである。したがって、「全てを読み込む」というアプローチは、問題を解決するどころか、問題そのものを最大化していたと言える。

この状況を打開するために、「Progressive Disclosure（プログレッシブ・ディスクロージャー）」という考え方が重要になる。これは、コーディングエージェントに対して、関連する指示や文脈を「段階的に導入する」手順を意味する。常に全ての指示を読み込ませるのではなく、エージェントがまさにその指示を必要とする瞬間にだけ提供し、それ以外の時間は邪魔にならないようにするというのが基本的な考え方である。このアプローチは、「何を」「どこで」「いつ」という三つの要素に分解して考えることができる。

まず「何を読み込むか（What loads）」について。ルールを単にファイルの一行として記述するのではなく、「スキル」としてパッケージ化することが推奨される。スキルとは、自己完結型の指示の塊であり、エージェントは特定のタスクを実行する際にそのスキルを呼び出し、それ以外の時には目にすることがない。例えば、コードのコミットに関する規約は、レイアウトのバグを修正している時には全く不要であり、Gitの操作をする際にだけ呼び出されれば良い。このように、タスクに直接関連しないスキルは、必要な時まで非表示にしておくことで、エージェントの注意を散漫にさせない。

次に「どこで読み込むか（Where it loads）」について。これは、初期のAGENTS.mdの考え方をより洗練させたものである。例えば、決済処理に関するルールは、決済関連のコードが存在するフォルダやファイルの近くに配置する。エージェントがそのコード領域で作業している時にだけそのルールが読み込まれ、他の領域で作業している時には読み込まれないようにする。これにより、指示の適用範囲が明確になり、ルール自体が弱くなるのではなく、そのターゲットが明確になる。これはフォルダレベルだけでなく、ファイルレベルでの詳細な設定も可能である。

そして「いつ読み込むか（When it loads）」について。一部のルールは特定の「場所」ではなく、特定の「瞬間」にのみ意味を持つ場合がある。そのようなルールは、そのタイミングに合わせて読み込むように設定する。例えば、セッションの開始時や、特定の種類の作業が始まる時にだけルールを有効にし、それ以外の時間は非表示にしておく。これは、ルールそのものを書き換えるのではなく、エージェントの作業フェーズに応じてそのルールが「舞台に上がるタイミング」を決定するという考え方である。

これらの「何を」「どこで」「いつ」という変更は、ルールが「何を言っているか」を一切変えない。変えるのは、エージェントがそのルールを「いつ、どれだけの期間持ち続けるか」である。私たちが不足しているのはディスク容量でもトークンでもなく、エージェントが重要なタスクに集中するための「注意」なのである。「What」「Where」「When」は、その限られた注意を、その瞬間に本当に重要なルールに集中させ、不要な情報に奪われないようにするための効果的な方法である。このアプローチを適切に実装すれば、数百行あった「常にオン」の指示ファイルは、ごくシンプルな基本設定と、必要な時に適切なタイミングで呼び出される一連のルール群に分解される。これにより、混雑した情報空間は整理され、エージェントは目の前のタスクに最も関連性の高い数個のルールだけに集中できるようになる。これが、AIエージェントの「指示読み込み問題」に対する最も洗練された解決策であり、エージェントが適切な指示を、邪魔されずに、まさに適用されるべき瞬間に得られるようになることを意味する。

この変革は、単にファイルを整理するという以上の意味を持つ。私たちは、エージェントとの協業のあり方全体を「システム」として再構築しているのである。そこには、スリムな基本設定と、パスやタイミングに紐付けられて呼び出されるルール群が存在する。この新しいシステムでは、「このルールはまだ意図した通りに読み込まれているか」「このルールは適用範囲が狭すぎないか」「複数のルールが同じタイミングで読み込まれて競合していないか」といった、これまでとは異なる視点での問いが生まれる。もはや「ファイルにあるか」が唯一の問いではなく、「実際に何が、どこで、いつ読み込まれるのか」という新しい視点が、この新しいシステムを理解し、管理するために不可欠となるのだ。この進化した理解が、AIエージェントをより効果的に活用するための基盤となるだろう。