Opus 5.5 は Progressive Disclosure を使いこなせるか：パス指定のルールとスキル、届くのはどちらか
前回の記事では、「設計の前に過去の決定を確認する」という一文を常設ルールに入れると、却下済みの提案をエージェントが黙って蒸し返さなくなることを実験で示しました。 その記事の終わりで、同じ一文をスキルに書く選択肢にも触れています。 スキルは必要なときにだけ読み込まれるので、常時読み込まれるルールよりコンテキストを節約できます。 ただしスキルの遵守率は「今回の実験では測っていない」と書きました。
Progressive Disclosure は、コンテキストを最初から全部載せず、必要になった時点で段階的に読み込ませる設計のことです。
Claude Code には、この仕組みが 2 つあります。
paths: を指定したルール（該当するファイルを開くと読み込まれる）と、スキル（エージェントが呼ぶと本文が読み込まれる）です。
どちらも、モデルが適切なタイミングで適切なものを読み込んでくれることを前提にしています。
前回の実験から 2 か月で、モデルは Claude Opus 4.8 から 5.5 に上がりました。 私自身も、権限の確認を分類器に任せる auto mode で作業することが増えています。 そこで、前回の実験を現在の環境で再試験し、Opus 5.5 は Progressive Disclosure を使いこなせるのかを確かめました。 前回と同じリポジトリに対して、のべ 105 回の試行です。
サマリ
- パス指定のルールは、Opus 5.5 ではほとんど発火しない。 ルールを読み込むきっかけは Read ツールだけである。Opus 5.5 はファイルの 95% を Bash の
catやsedで読み、auto mode を外してもこれは変わらない。 - スキルに書いた確認手順は、Opus 5.5 には届く。 設計を頼むと Opus 5.5 はほぼ毎回 design doc のスキルを呼んだ（63 回中 61 回）。却下済みの ADR には 6/6 で到達した。7月の Opus 4.8 が同じ依頼でこのスキルを呼んだのは 9 回中 2 回である。
- 常設ルールとスキルは、衝突を見つけたあとの振る舞いが違う。 常設ルールは確認を求めて止まり、スキルは衝突を文書に記録したうえで設計を書き切る。両方を置くと常設ルールの振る舞いになる。
前回の実験と、2 か月で変わったこと
前回の実験は、過去に却下した提案をもう一度エージェントに依頼し、却下の記録（ADR）に気づくかを調べるものでした。
素材は、私が開発しているアーキテクチャ図ツール karasu のリポジトリです。
たとえば「.krs 記法のブレースをやめて YAML のようなインデント構文にしたい」という依頼は、karasu ではすでに検討して見送った案です。
エージェントがその却下記録に気づいて確認を求めれば良い振る舞い、気づかずに移行の設計を書き始めれば、決着した議論を黙って蒸し返したことになります。
今回は、この実験を現在の環境でそのまま繰り返しました。 2 か月のあいだに変わったのは、モデルと権限モードだけではありません。
- モデル：Claude Opus 4.8 から Claude Opus 5.5 へ
- 権限モード：確認を省く bypassPermissions から、分類器に任せる auto mode へ
- リポジトリ：ADR が 263 本から 391 本に増え、ID の付け方も日付から Issue 番号に変わった
- スキル：前回の実験の直後に、確認手順を design doc のスキルに書き込んだ
最後の項目は、実験を始めてから気づきました。
karasu の開発では、私が別に開発しているスキル集 hane の design-doc スキルを使っています。
前回の記事を書いた翌日、私はこのスキルの必須手順として「設計の前に docs/adr/ を grep し、却下された決定を狙って探すこと」を追加していました。
実験の処方を、実運用のスキルに入れていたわけです。
このままでは、ルールを入れない条件でもスキル経由で確認手順が効いてしまい、7月と比べられません。 そこで hane の版を固定し、7月当時の版と現在の版を条件として切り替えられるようにしました。 結果として、今回の再試験は次の 3 つの問いを同時に測る設計になっています1。
- 7月の結論は、モデルと権限モードが変わっても持つか
- 常設ルールとスキルは、それぞれ Opus 5.5 に届くか
- 差が出たとき、それはモデル、権限モード、リポジトリのどれによるものか
パス指定のルールはなぜ発火しないのか
先に、パス指定のルールについて片付けます。
auto mode では .claude/rules の paths 指定が効かないという報告が出ています。
その記事によれば、パス指定のルールは Read ツールの実行をきっかけに読み込まれる設計です。
一方、auto mode のシステムプロンプトは「Bash でできる作業は Bash でやる」ように指示しています。
その結果、ファイルを cat で読むとルールが迂回される、という説明です。
これを小さな対照実験で確かめました。
notes/** にパスを指定したルールを 1 つ置き、中身を「このルールが読み込まれていたら、最終回答の末尾に合言葉を書く」にします。
そのうえで、ファイルを Read で読ませる場合と Bash の cat で読ませる場合を、auto mode と bypassPermissions の両方で 3 回ずつ試しました。
| Read で読む | Bash の cat で読む |
|
|---|---|---|
| auto mode | 3/3 | 0/3 |
| bypassPermissions | 3/3 | 0/3 |
発火を決めていたのは権限モードではなく、読み方でした。 Read で読めば auto mode でも発火し、Bash で読めば bypassPermissions でも発火しません。
では、実際のタスクでモデルはどちらで読んでいるのでしょうか。 再試験の全試行について、ファイルを読んだ操作のうち Bash 経由だったものの割合を数えました。
| 構成 | Bash で読んだ割合 |
|---|---|
| Opus 4.8、bypassPermissions（7月） | 33% |
| Opus 4.8、bypassPermissions（今回） | 18% |
| Opus 5.5、bypassPermissions | 95% |
| Opus 5.5、auto mode | 94% |
Opus 5.5 は、auto mode でなくてもファイルのほとんどを Bash で読みます。
報告の記事は auto mode のシステムプロンプトを原因に挙げていますが、少なくとも今回の環境では、auto mode を外しても Opus 5.5 の読み方はほぼ変わりませんでした。
パス指定のルールを使った Progressive Disclosure は、Opus 5.5 ではほとんど機能していませんでした。
karasu の ADR 執筆ルールも docs/adr/ にパスを指定しているので、エージェントが ADR を読んだ場面でも、このルールは読み込まれていない可能性が高いと考えられます。
パス指定のルールが読み込まれなかった分を、Opus 5.5 が自分で補っていたわけでもありません。
auto mode の 81 回の試行のうち 46 回は docs/design に設計文書を書いています。
この場所には設計文書の書き方を定めたパス指定のルールが当てはまりますが、46 回のうちそのルールを自分で開いて読んだのは 14 回でした（Opus 4.8 は 12 回中 7 回）。
Bash で読んでも却下の ADR に届くのはなぜか
ここで疑問が残ります。 Opus 5.5 がファイルを Bash で読むなら、ADR も Bash で読んでいるはずです。 それでも、以降で示す試行の多くが却下の ADR に届いていたのはなぜでしょうか。
理由は、パス指定のルールと ADR が別の仕組みで読まれているからです。
パス指定のルールは、Claude Code がエージェントの操作を見て、コンテキストに差し込むものです。
差し込むきっかけが Read ツールに限られているので、読み方が変わると差し込まれません。
一方、ADR はエージェントが自分で探して開くデータです。
cat と Read のどちらで開いても、エージェントが受け取る本文は変わりません。
では、エージェントはどうやって ADR を探しているのでしょうか。
却下の ADR に届いた 55 回の試行について、そのファイル名が最初に現れた操作を調べました。
50 回は Bash の grep で docs/adr の本文を検索した結果で、残りの 5 回は索引を読んだ結果です。
典型的な検索はこうです。
grep -ril -E "indent|インデント|brace|ブレース|YAML" docs/adr依頼に出てきた言葉を、日本語と英語の言い換えごと 1 回の検索に並べています。 Read ツールは 1 ファイルずつしか開けませんが、grep なら 391 本の本文を一度に当たれます。
この検索に当たる ADR は、YAML の依頼で中央値 30 本、セッション名の依頼で 15 本ほどでした。
その中から却下の ADR を選べたのは、ファイル名が内容と結論を表しているからです。
7-yaml-style-syntax-cancelled.md や 45-bun-not-adopted.md のように、何についての決定で、採用されなかったのかがファイル名から読めます。
検索が当たるのは、ADR の背景が依頼と同じ言葉で書かれているからです。
YAML 構文の ADR は「深いネスト（4〜5段）でブレース構文の閉じブレースが連続し読みにくいという問題から」と始まり、今回の依頼文とほぼ同じ不満を記録しています。
前回の記事で、却下の理由を書いた本文は検索の手がかりになると書きました。
Bash の grep は、その手がかりをそのまま使っています。
反対に、届かなかった試行では、却下の ADR のファイル名が一度も出力に現れていませんでした。
検索結果に見えていたのに開かなかった試行はありません。
原因の 1 つは、検索結果の切り詰めです。
Bun の依頼で届かなかった試行の 1 つは、pnpm|vitest|bun|runtime のような広い語で ADR を検索し、結果を | head -60 で先頭 60 件に切っていました。
この検索に当たる ADR は 160 本あり、却下の ADR は 112 番目に並びます。
ADR が増えるほど広い検索の当たりも増え、出力を切り詰める習慣と組み合わさると、目当ての ADR がこぼれます。
もう 1 つは、そもそも docs/adr を探さなかった場合です。
セッション名の依頼で届かなかった試行の多くは、スキル集や Claude Code 本体の調査に向かっていました。
要するに、Bash で読むことで失われるのはルールの自動の差し込みであり、ADR の探索ではありません。 探すきっかけ（スキルやルールの確認手順）さえあれば、Bash の grep で多くの ADR を一度に当たれます。 次節で示すスキルの効果も、この探索がスキルの指示で起動された結果です。
スキルに書いた確認手順は届くか
次に、本題のスキルです。 却下済みの提案（エージェントのセッション名を機能名に付け替える機能）を依頼し、確認手順をどこに置くかで 4 通りに分けました。 モデルはすべて Opus 5.5、権限モードは auto mode です。
| スキル旧版（確認手順なし） | スキル新版（確認手順あり） | |
|---|---|---|
| 常設ルールなし | 1/6 | 6/6 |
| 常設ルールあり | 3/3 | 3/3 |
表の数字は、却下の ADR を実際に開いた試行の割合です。 スキルに確認手順を書いただけで、常設ルールがなくても 6/6 で到達しました。 常設ルールを置いた場合は、スキルの版によらず 3/3 です。
スキル経由で届いた理由は単純で、Opus 5.5 が design doc のスキルをほぼ毎回呼んだからです。 今回の依頼はどれも「design doc としてまとめてほしい」という形です。 確認手順を置かない条件で、Opus 5.5 は 63 回中 61 回この種の依頼でスキルを呼びました。 セッション名の依頼に限ると、7月の Opus 4.8 は 9 回中 2 回、現在のリポジトリの Opus 4.8 は 6 回中 3 回しか呼んでいません。 スキルの本文がどれだけ正しくても、呼ばれなければ読み込まれません。 Opus 4.8 の時点でスキルに書く案が不確かだったのはこのためで、Opus 5.5 ではその前提が満たされるようになりました。
ただし、届いたあとの振る舞いは常設ルールとスキルで異なりました。
| 衝突を見つけたあと | 設計文書 | 時間と費用 | |
|---|---|---|---|
| 常設ルール | 確認を求めて止まる | 書かない（0/3） | 約 30 秒、0.28 ドル |
| スキル新版 | 衝突を文書に書き込み、設計を続ける | 書く（6/6） | 約 4.5 分、1.28 ドル |
常設ルールの文面は「覆す提案になる場合は、黙って進めず確認を取る」なので、エージェントは衝突に気づいた時点で止まります。 スキルの手順は「衝突する過去決定が見つかったら、ドキュメントの背景と制約に明記する」なので、エージェントは衝突を書き込んだうえで設計を最後まで書きます。 どちらも、書かれた手順のとおりに動いた結果です。 両方を置いた場合は、常設ルールの振る舞い（早く止まる）になりました。
衝突のない依頼（ドキュメントに FAQ ページを追加する）に課されるコストも測りました。
前回、Opus 4.8 では常設ルールを入れると費用が倍になりました。
Opus 5.5 では、確認手順がない場合 0.96 ドル、常設ルールで 1.01 ドル、スキル新版で 1.04 ドルと、ほとんど差がありません。
Opus 5.5 は確認手順がなくても docs/adr/ を数回探すので、手順による上乗せが小さくなったものと考えられます。
衝突がないのに止まってしまった試行は、どの条件でもありませんでした。
モデルが変わって何が変わったか
ここからは、確認手順を置かない素の状態での変化です。 7月との比較で最も大きかったのは、却下済みの提案を黙って進める振る舞いが消えたことでした。
セッション名の依頼を、確認手順なしで出した結果です（A は衝突を示して確認を取った、B は過去の決定に触れないまま設計を進めた、の分類）。
| 構成 | B（黙って進めた） | 却下の ADR を開いた |
|---|---|---|
| Opus 4.8、7月のリポジトリ | 7/9 | 1/9 |
| Opus 4.8、現在のリポジトリ | 3/6 | 3/6 |
| Opus 5.5、bypassPermissions | 0/6 | 5/6 |
| Opus 5.5、auto mode | 0/6 | 1/6 |
同じリポジトリ、同じ権限モードで Opus 4.8 と 5.5 を比べると、B は 3/6 から 0/6 に減っています。 ADR を丸ごと削除した条件でも、Opus 5.5 が黙って進めたのは 12 回中 1 回で、残りは自力で理由を挙げて慎重な姿勢を取りました。
ただし、却下の ADR を思い出す力が上がったわけではありません。 YAML とツールチェーン（Bun への移行）の却下を的にした依頼では、7月の Opus 4.8 は 6 回すべてで却下の ADR を開いていました。 今回の Opus 5.5（auto mode）は 6 回中 3 回です。 ADR が 391 本に増えて広い検索の当たりが増え、先に述べた出力の切り詰めで目当ての ADR がこぼれやすくなっています。 Opus 5.5 が慎重だったのは、ADR を見つけたからではなく、ほかの手がかりから判断したからです。
手がかりの 1 つは、スキル集の側にありました。 セッション名の依頼で、Opus 5.5 は hane の変更履歴を読み、「以前セッション名を変える手順を入れたが、モデルから実行できず削除した」という記録を見つけています。 karasu で却下した経緯が、スキル集の変更履歴にも残っていたわけです。 さらに Claude Code 本体を調べて、現在のバージョンにはフックからセッション名を変える方法があることまで突き止めました。 ADR に書かれた却下理由（名前を変える公開 API がない）は、2 か月のあいだに成り立たなくなっていたことになります。
auto mode と bypassPermissions の違いは、この依頼で却下の ADR を開いた割合（1/6 と 5/6）にだけ現れました。 黙って進めた試行はどちらもゼロで、ほかの依頼では差がありません。 6 回ずつの比較なので偶然の範囲を出ず、auto mode が想起を下げるとまでは言えません。 なお、auto mode の 81 回の試行で、権限の確認によって操作が止められたことは一度もありませんでした。
限界
今回も個人開発の 1 リポジトリで、各条件 3〜6 回の小さな規模です。 効果量ではなく、条件間の方向の違いを確かめたものと読んでください。
いくつか統制しきれていない要素があります。 セッション名の依頼は、上で書いたとおり却下理由が古くなっており、7月と同じ意味の「閉じた決定」ではなくなっていました。 挙動の分類は7月と同じ基準で別モデルに判定させましたが、この基準の「衝突の顕在化」は的の ADR 以外の記録への言及も含むため、的の ADR を思い出したかどうかはツールの実行記録から判定しています。 スキル集の版は固定しましたが、ほかのプラグインは固定していません。 パス指定のルールの発火は、stream の出力からは観測できなかったため、小さな対照実験で代わりに確かめています。
まとめ
Opus 5.5 は、Progressive Disclosure のうちスキルは使いこなし、パス指定のルールは使いこなせませんでした。 違いを生んだのは理解力ではなく、ファイルの読み方です。 スキルはモデルが自分で呼ぶので、呼ぶ判断さえ確かなら届きます。 パス指定のルールは Read ツールという特定の読み方にだけ結び付いているので、モデルが別の読み方を選ぶと届きません。
もう 1 つ見えたのは、モデルが賢くなると記録の役割が変わることです。 Opus 5.5 は ADR を思い出せなくても、ほかの手がかりから慎重になりました。 それでも「この提案はすでに検討して見送った」という決着は、ADR を読まなければ分かりません。 その決着を読ませるために、確認手順は今も要ります。 確認手順をどう届けるか（エージェントにコンテキストを渡す仕組みをどう設計するか）は、追加の実験とあわせて別の記事で扱う予定です。
実験の条件、全セルの結果表、再試験で見つかった落とし穴は資料編にまとめました。