--- title: "削れと言われたのは、道しるべではなかった" description: "「規定的な作り込みを削れ」という助言は、禁止形や思考手順のことを指しています。ヒントやフックやワークフローまで削れと読むと、裁量を渡したのに黙るエージェントが残ります。制約と整備を分けた上で、依存していた挙動を数え直した記録です。" category: "AI" tags: ["AI Agent","Claude Code"] publishedAt: "2026-09-03" lastmod: "2026-09-03" --- エージェントの成果は、モデルの世代よりワークフローの側で決まります。ただしそのワークフローは足元の挙動に暗黙に依存していて、依存先を一覧にしていなかったせいで、規約の記述が黙って事実でなくなっていました。数え直したら3つ見つかっています。 この記事が扱うのは、監査せよという助言の手前までです。実際に公式の監査ツールを当てた記録は別に書きました。 ::card[/posts/prompt-audit-on-our-own-skills] ## モデルを固定してハーネスだけ変えるとスコアが変わる ワークフローが結果を左右する、というのは実験で切り分けられています。 2026年7月の [Don't Blame the Large Language Model](https://arxiv.org/abs/2607.03691) は、モデルを固定してエージェントハーネスだけを35リリース分変化させ、有効性と効率への影響を測っています。刺さるのは測定結果より実務家の反応のほうで、品質の変動を「ハーネス自体ではなく、下層のモデルのせいだと一貫して考えてしまう」と書いています。 別の[対照実験](https://arxiv.org/abs/2606.08529)では、同じモデルのまま、スキャフォールドを変えるだけで測定精度が最大 **28ポイント** 動いています。 ## 公式が削れと言っているのは制約のほう 一方で、モデルを提供している側の助言は作り込みを削る方向を向いています。 [Prompting Claude Opus 5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5) は、明示的な検証指示があるなら削除せよと書き、別個の検証ステップを足すレガシーなハーネスのスキャフォールディングにも同じことが言える、と続けます。[Fable 5 側](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5)はもっと直接的です（訳は筆者）。 > 以前のモデル向けに作られたスキルは Claude Fable 5 には規定的すぎることが多く、出力品質を劣化させうる ここには同意します。「〇〇しないでください」を思いつくたびに足していくやり方は効きません。どう考えるかを人間が先回りして指図するのも同じで、[Corti の整理](https://corti.com/your-prompts-are-technical-debt-why-scaffolding-built-for-older-models-hinders-newer-ones/)がその末路を短く言い当てています。 > 指示は残るが、失敗モードは残らない。下層のモデルが改善すると、補正は補正であることをやめ、歪みになる 厄介なのは、この種の変化が通知される経路に乗らないことです。[Migration guide](https://platform.claude.com/docs/en/about-claude/models/migration-guide) が明示しています。 > API の破壊的変更ではないが、プロンプトの更新やスキャフォールディングの削除が必要になりうる ## 「制約」という一語が2つのものを混ぜている 読み違えが起きるのはここからです。削れと言われているものと、足すべきものが、同じ「規定的な作り込み」という一語でひとくくりにされてしまいます。 | 削るべき制約 | 足すべき整備 | |---|---| | 「〇〇しないでください」という禁止形 | こういう時はこのツールを使うといい、というヒント | | どう考えるかを指図する思考手順 | メモリ | | 旧モデルの失敗モードを補正する指示 | フック | | 別個の検証ステップの強制 | 段の順序とゲート、どこに何があるかの道しるべ | 右の列は制約ではありません。行動を狭めるものではなく、行動する前に何が手元にあるかを知らせるものです。 フックが分かりやすい実物になります。[個人の設定](https://github.com/corrupt952/dotfiles)に、検索クエリへ2020年から2024年の年号が混ざっていたら呼び出しを止めるものを置いてあります。 ```bash jq -re '.tool_input.query | select(test("202[0-4]"))' > /dev/null \ && { echo "Query contains outdated year. Current year is $(date +%Y). Fix it." >&2; exit 2; } \ || exit 0 ``` 「古い年号で検索しないでください」と規約に書いても、守られたかどうかは分からないまま通ります。フックは呼び出しの時点で止めて、現在の年を使えという理由を返します。同じ失敗モードに、指示ではなく仕組みで答えているという違いです。 同じ切り分けは公式側にもあります。[Skill authoring best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices) は観察すべき項目として「辿られなかった参照」を挙げ、Claude が重要なファイルへの参照を辿り損ねていないか、リンクをもっと明示的に目立つようにする必要はないか、と書いています。道しるべは明示しろ、と言っています。 右の列にも反論はあります。Richard Sutton の The Bitter Lesson（2019）は、人間の知識を組み込む方向は計算を活かす汎用手法にいずれ追い越されると述べたもので、逐語は Michael Nielsen の[検討](https://cognitivemedium.com/bitter-lesson)に引かれています。この立場からは、道しるべもフックも、モデルが強くなれば要らなくなる一時的な足場に見えます。 その通りです。要らなくなったなら消します。`paths` は実際に消しました。ただし消す判断は、要らなくなったことを測ってから出すものです。先回りして足場を置かない理由にはなりません。 争点は削るか足すかではなく、何を制約と呼ぶかにあります。 ## 右の列を欠いたまま裁量を渡すと、知らないことについて黙る 整備した上で裁量を渡すのは正しいやり方です。成り立たないのは、右の列を欠いたまま裁量だけ渡す場合のほうでした。 そのとき起きるのは、間違った答えが返ってくることではありません。知らない領域について何も言わなくなります。話せないので黙ります。読む側には、そこに何も無かったように届きます。 同じ壊れ方は公式ドキュメントにも書かれていました。入れ子になった参照ファイルの扱いです。 > 入れ子の参照に出会うと、Claude はファイル全体を読む代わりに `head -100` のようなコマンドで内容を先読みし、結果として情報が欠ける 欠けたことのほうは報告されません。 ::card[/posts/silence-is-not-a-pass] デグレについても書いておきます。更新のたびに、以前は起きなかった種類の壊れ方が入ります。裁量を渡すほど良くなるという話が右の列抜きで成り立つなら、起きないはずのものです。 ただし「モデルが劣化した」とは書きません。それを言うと、通常のばらつきとの区別を自分でしていないことになります。区別が難しいことは、変更した側の記録に残っていました。[4月のポストモーテム](https://www.anthropic.com/engineering/april-23-postmortem)です。 > 3月初旬から報告の調査を始めたが、当初はユーザーフィードバックの通常のばらつきと区別するのが難しく、社内利用でも評価でも、指摘された問題を最初は再現できなかった 変更した本人が、社内利用でも評価でも最初は再現できていません。手元の観測が印象と区別しづらいのは、こちらの怠慢というより問題の形のほうです。 ## 依存していた挙動を3つ数えた 社内の標準は公開しているので、以下は履歴から追えます。 ::card[https://github.com/LabeeHive/standards] 1つ目が `paths` です。スキルの自動読み込みを対象ファイルのグロブで絞るフィールドでした。2026年6月10日に仕様の説明を書き直し、同時に注記を足しています。`paths` を付けると `description` があってもスキルが発見できなくなり、`/名前` で呼んでも Unknown skill が返るという報告がありました（[#49835](https://github.com/anthropics/claude-code/issues/49835)）。肝心の自動読み込みのトリガーも発火せず、こちらは Claude Code 2.1.150 で API レベルの確認まで付いています。`description` を欠く場合は、一覧にそもそも出てこなくなります（[#62049](https://github.com/anthropics/claude-code/issues/62049)）。結論は「前方互換のメタデータとして扱え」「依存する前に再確認しろ」でした。翌6月11日に、全スキルから削除しています。 2つ目が `context: fork` です。スキルを分離したプロセスで走らせる指定で、呼び出し側には起動通知しか届きません。指示も進捗もエラーも、完了通知すら来ないことがあります。承認を待つ段がそこにあると、無限に止まったまま動いているように見えます。モデルと effort のピン留めは主にその fork 実行を設定するために存在していたので、4つのフィールドをまとめて落としました。 3つ目が、いちばん静かに壊れました。スキルの参照ファイルは、SKILL.md 側に「このファイルを読むこと」と明示的に書いて読ませています。それでもモデルの更新後、その指示はほぼ通らなくなりました。 ::card[/posts/standards-that-stopped-being-true] 指示は残っているのに、指示が指示として機能しなくなります。エラーは出ません。読まれなかったことは、読まれなかったという形でしか現れません。参照を辿らなかったエージェントは、辿らなかったことを申告しないまま作業を続けます。 公式が観察項目に「辿られなかった参照」を挙げていたのは、この失敗モードのことでした。観察せよと書かれているものが、実際に起きています。この3つ目については、そのあと読めと書く形をやめて本文に注入する形へ変えました。 ::card[/posts/skill-references-injected-not-read] ## 一覧が無いと監査は実行できない 監査せよという助言は、対象の一覧がないと実行できません。 Fable 5 のページは移行時に既存のスキルを監査せよと書き、Skill authoring best practices は使う予定のあるすべてのモデルでテストせよと書いています。どちらも正しい助言です。ただし、どの記述がどの挙動に依存しているかが分かっていなければ、監査は「全部を最初から読み直す」と同じ意味になります。 同じ形の一文が、swift-workflow のレビューゲートで見る対象を変えたときのコミットに残っていました（訳は筆者）。 > Swift、SwiftUI、Xcode の知識はどんな学習カットオフよりも速く古くなるので、自信を持って思い出した API は、その API が存在する証拠でも、デプロイターゲットでその挙動をする証拠でもない 思い出した内容は証拠ではない、という判断はコードの側に入れてありました。同じ判断を、規約が自分について書いている記述には当てていません。`paths` は注記を書いた翌日に消せましたが、それは疑って調べたからです。疑わなかったものが何本あるかを、こちらは知りません。 ![規約の記述はどれも書いた当時のまま変えていない。その下で依存している挙動のうち、paths の自動起動と、参照ファイルを読ませる明示的な指示については、疑って測ったので実際の挙動が分かっている。疑わなかった記述については測っておらず、依存の一覧も持っていないため、実際の挙動が分からないまま残っている](/images/posts/workflow-depends-on-behavior/dependency-layer-swap.svg) ::card[/posts/autonomous-loop-built-measured-removed] ## 一覧を作る走査は、既存の運用に乗せられる 研究の側では、自動での検出が試されています。2026年6月の [Context Rot in AI-Assisted Software Development](https://arxiv.org/abs/2606.09090) は、`CLAUDE.md` や `AGENTS.md` が古びる現象に名前を付け、既存の README 整合性チェッカーを当てただけで、統計的な代表性を持つ356件のリポジトリのうち 23.0% に陳腐化したコード要素参照を見つけました。[CASCADE](https://arxiv.org/abs/2604.19400) はドキュメントから単体テストを生成し、落ちたことをもって食い違いの証拠とします。 どちらも参照先がコードにある場合の手法です。こちらが困っているのは参照先がツールやモデルの挙動にある場合なので、そのままは使えません。 使えたのは研究の側ではなく、手元で回している運用のほうでした。コードベースを週次で走査するだけのサブエージェントを立てて、役割を検知と報告に限り、修正はさせないという形です。 ::card[/posts/weekly-code-grooming-agent] 依存の一覧づくりは、規約の中で挙動を前提にしている記述を拾う作業です。走査であって修正ではないので、同じ運用にそのまま乗せられます。 - 定期の繰り返しタスクとして走らせる - 走査するエージェントに書き込み権限を与えない - 報告はチケットにして、直すかどうかは別で判断する - 報告に載っている grep はレビュー側で打ち直す - 同じタスクにコメントを積んで増減を追う いちばん効くのは、「0件」と「未走査」を必ず書き分けさせる規則のほうです。 これは前の節の最後に書いたことへの、そのままの回答になります。疑わなかったものが何本あるかを知らない、という状態は、走査しなかった観点を未走査として明記させれば解けます。疑わなかった記述が、空欄ではなく件数として残ります。図の3列目に名前が付きます。 決まっていないのは観点の側です。コードの規約違反と違って、「挙動を前提にしている記述」は機械的に切り出せません。「自動で」「読み込まれる」のような語で引っかけるのか、フィールド名やツール名の出現で拾うのか、まだ決めていません。1行に何を書くかも同じで、記述と依存先の対応だけで足りるのか、どう呼び出せば確かめられるかという測り方まで書かないと再確認に使えないのか、やってみないと分かりません。 何をきっかけにするかも変わります。コードの劣化は時間で溜まりますが、規約が事実でなくなる引き金はモデルとツールの更新です。時間ではなく更新に紐づけるほうが形として合っています。ただし更新に気づく手段を今は持っていないので、そこは当面あの運用と同じ週次で代用することになります。