この記事の要点: Claude CodeではAnthropicの最上位モデルFable 5が使える（私はサブスクリプション経由で利用している）。ただし単価はOpusの2倍で常用はできず、そのセッションで生まれた「先回りの気づき」はセッションが終わると消える。そこで2026-07-09、気づきを拘束力のない「ルール候補プール」に記録し、実績（事故・手戻りを防いだ1件、または同種判断が別セッションで2回以上）が揃ってから承認を経て正式ルールへ昇格させる二段階運用を導入した。2日後の2026-07-11、週次レビューに組み込んだ照合が初めて発火し、候補4件のうち1件（品質ゲートfail後の差分再レビュー手順。89点→93点の実績付き）が正式ルールに昇格した。ただし「下位モデル（Sonnet等）がこの仕組み自体を回せるか」はまだ実証されていない。
Fable 5は賢い。ただし高いし、賢さはセッションと一緒に消える
Claude Codeでは、Anthropicの最上位モデルFable 5が使える。私はサブスクリプション経由で利用しているが、この環境がいつまで続くかは正直分からない。実際、2026年6月にはFable 5へのアクセスが一時止まり、7月に入って復旧した。「使えるうちに使い倒したい」というのが本音だ。
とはいえ単価はOpusの2倍。何にでも使うわけにはいかない。私はClaude Codeで複数のエージェントに役割分担させて記事の執筆やタスク管理を回しており、普段の実務はSonnetやOpusに任せ、Fable 5は判断を間違えると高くつく場面だけに登板させている。
そういう使い方をしていると、気づくことがある。上位モデルの賢さは、成果物の出来そのものより、事故が起きる前にリスクへ気づくところに出るのだ。たとえば調査役のエージェントに「分析だけして」と頼むとき、Fable 5は頼まれなくても「このエージェントは放っておくと修正まで自走するから、読み取り専用と明記しておこう」という一文を先回りで足してくる。下位モデルは、事故が起きてから同じことを学ぶ。
この「賢さ」の中身をもう少し分解すると、サブエージェントへの指示文の質として表れる。
| 観点 | 内容 |
|---|---|
| 失敗モードの先回り | 指示した相手がどこで間違えるかを予測し、先に制約を書く |
| コンテキストの選別 | サブエージェントは文脈ゼロで起動する。渡す情報は足りなくても多すぎても失敗する |
| 成果物の契約 | 出力先・形式・報告内容を先に指定しないと往復が発生する |
| 分割と並列性の設計 | 並列/直列の切り方でコストが倍数で変わる |
| 検証手段の埋め込み | 「実行しろ」ではなく「実行して、こう確認して、報告しろ」まで書く |
笑い話ではなく、私の運用ルールの多くは実際に「事故の後追い」でできてきた。調査だけ頼んだエージェントが無断でファイルを修正した（2026-05-25）。処理の分割設計を誤り、75件の順次処理に1件ずつエージェントを起動して116エージェント・4.28Mトークン・約25.70ドル（理想設計比5.7倍）を溶かした（2026-06-20）。テキスト処理のバグで記事のネタ帳26ファイルを空にした（2026-05-11）。どれも、起きてからルールになった。
ならば、事故の前に気づける頭脳がせっかく手元にあるうちに、その気づきを使い捨てずに回収したい。1回の実行に使って終わりでは、高い単価で「答え」を1つ買っただけだ。ほしいのは答えそのものではなく、安いモデルでも再利用できる「判断のルール」のほうだ。
「気づいたら即ルール化」には2つの落とし穴がある
発端は、私がClaude Codeとの対話で投げたこの思いつきだった。
「未知の部分にFableが気がついたら、他のモデルでも利用できるようにルール化するのはどうかな？」
筋は悪くない、と自分では思っていた。だが返ってきた分析は、「そのまま全部ルール化」には問題が2つある、というものだった。
1つ目は、ルール肥大化のコスト。ルールは1本書けば「全モデル×全セッション×永続」で効き続ける。曖昧な訓示をルール化しても下位モデルの挙動は変わらず、読むべきルールだけが増える。CLAUDE.mdに何でも書き足して太らせた経験がある人なら、この感覚は分かると思う。
2つ目は、事故前の洞察は仮説にすぎないこと。事故記録から生まれたルールには実害の裏付けがあるが、上位モデルの「先回り」は外れる可能性のある仮説だ。検証なしに全エージェントを縛るルールにしてしまうリスクがある。
「結局ルールが増え続けるだけでは？」という疑いはもっともだ。解決策は、ルール化を一段階のプロセスにせず、二段階に分けることだった。
ルール候補プールとは何か——記録はタダ、昇格には実績を要求する
仕組みはシンプルだ。「ルール候補プール」といっても、私が勝手にそう呼んでいるだけの、ただのMarkdownファイルである。
- 気づきは、拘束力のない候補プールに記録する
- 実績（事故・手戻りを防いだ1件、または同種の先回り判断が別セッションで2回以上）が揃った候補だけを、承認を経て正式ルールへ昇格させる
先に言っておくと、この核の部分はモデルを何階層使い分けているかに依存しない。Claude Codeを1つのモデルで普通に使っている場合でも、「気づいたことを一旦メモしておき、実際に効いたと確認できてから初めてルール化する」という順序はそのまま使える。
記録フォーマットは、発火条件・アクション・背景・記録モデル・実績の5項目で固定した。
### YYYY-MM-DD <slug>
- **発火条件**: （どういう状況で発動するか。具体的に）
- **アクション**: （何をするか。具体的に）
- **背景**: （なぜ必要と判断したか）
- **記録モデル**: Fable 5 等
- **実績**: （昇格判断用。事故防止・再発の記録をここに追記していく）
記録は拘束力を持たないから実害がなく、コストは「プールを読む数分」だけ。プール自体の肥大化には「記録から3ヶ月実績ゼロの候補は破棄を検討する」という棚卸しルールで歯止めをかけた。
これで、高いモデルを使う経済性が変わる。Fable 5の単価は一度きりの支出だが、ルール化された知見は全モデル・全セッションで永続的に効く。上位モデルを「実行者」としてではなく「ルール生成器」として使う、という発想だ。しかも「証拠が揃ってからルールにする」という既存の原則は崩していない。ルールが生まれる起点を「事故の後」から「洞察の時点」に前倒ししただけだ。
ひとつだけ、作ってすぐに設計の穴が見つかった。記録する仕組みは作ったのに、プールを読み返す機会がどこにも組み込まれていなかったのだ。導入当日に記録の機会は3回あったが、3回とも私の「この委任で洞察はなかった？」といった短い一言がきっかけで、仕組みが自分から動いたことは一度もなかった。「上手く回るかな」という素朴な問いを投げたら、この未配線が露呈した。過去に自分でメモしていた教訓——「呼ばれないルールは存在しないのと同じ」（2026-04-29）——がそのまま刺さった形だ。対策として、週次レビュー（週に一度、運用全体を見直す定例のチェック手順）に「候補プールを読み、今週のセッションと照合する」ステップを組み込んだ。
導入2日後、候補4件のうち1件が正式ルールに昇格した
導入から2日後の2026-07-11、週次レビューに組み込んだ照合ステップが初めて実行された。それまでの記録がすべて人間の一言頼みだったのに対し、初めて「仕組みが仕組みを呼び出した」ことになる。
照合結果は、候補4件のうち昇格1件・継続観察3件・破棄0件だった。
| 候補 | 判定 | 理由 |
|---|---|---|
| 品質ゲートfail後の差分再レビュー手順 | 昇格 | 手戻りを防いだ実績1件を確認 |
| 委任時のスコープ制約の明記 | 継続観察 | 適用2回だが、効果が判別できない留保付き |
| 素材の二重供給の禁止 | 継続観察 | 別セッションでの2回目の適用待ち |
| Workflow使用時のモデル指定の明示 | 継続観察 | 未検証 |
昇格した候補の実績はこうだ。私は記事を公開する前に「品質ゲート」と呼ぶ複数観点の採点を通しているのだが、2026-07-09、Claude CodeのToolSearch機能を扱った記事の初回集計が89点でfailになった（合格ライン90点、あと1点）。ただし減点の主因は、レビューが修正前の版を対象にしていたために生じた誤減点で、指摘自体は採点時点ですでに反映済みだった。そこで全観点のフル再実行ではなく、該当観点だけの差分再レビューで復点を判定し、93点passに至った。フル再実行に比べてエージェント2起動分を節約しつつ、failの記録も履歴として残せた。
この差分再レビューという手順そのものが、もともとFable 5のセッションでその場設計され、候補プールに「実績付き」で記録されていたものだ。今回の照合で昇格条件（手戻りを防いだ実績1件）を満たしたと判定し、承認を経て正式な手順書に転記した。Fable 5の即興が、どのモデルのセッションでも参照される手順に変わった瞬間である。
適用2回でも昇格しない——基準は回数より「効果が観測できるか」
個人的には、昇格した候補より昇格しなかった候補のほうが面白かった。
「委任時のスコープ制約の明記」（サブエージェントに1つの成果物だけを作らせるとき、対象ファイル以外の修正・作成をしないよう明記する）は、別々のセッションで2回適用済みだった。昇格条件の文面「同種判断が別セッションで2回」を、形式的には満たしている。
だが2回とも「制約が効いたのか、そもそも逸脱しないケースだったのかが判別できない」という留保付きの適用だった。先に昇格していた別の候補（委任先に「自信のない箇所」を完了報告で自己申告させる手順。申告が次工程の検証に的確に効いたと具体的に確認できた）と比べると、証拠の質が違う。それで継続観察を選んだ。
つまり昇格基準は文面上「適用回数」だが、実際に効いているのは「効果が観測可能かどうか」だ。回数だけ満たしても、効いたかどうか分からない適用は昇格を後押ししない。これは運用して初めて見えた解釈で、皮肉なことに、この解釈自体が次の候補プール行きの気づきになりうる。
SonnetはFable 5の作った仕組みを回せるか——残る宿題
ここまでで、記録→想起→昇格→棚卸しの経路は一周した。ただ正直に書くと、まだ答えられていない疑問が2つ残っている。
1つは、2026-07-11の週次レビューを実行したのもFable 5だったこと。「下位モデル（Sonnet等）が候補プールの照合・昇格判断を運用できるか」は、まだ実証されていない。もう1つは、昇格した差分再レビュー手順が、下位モデルの品質ゲート運用で実際に機能するかどうか。これは次にfailが発生するまで観測できない。
次の観測ポイントははっきりしている。次に品質ゲートのfailが出たとき、そして週次レビューをSonnetに任せたときだ。その間に読者のあなたが試せることは、もっと小さくていい。拘束力のないメモファイルを1本作り、セッションで出た「お、賢いな」という気づきを書き溜めて、効いたと確認できたものだけをCLAUDE.mdなりルールファイルなりに昇格させる。それだけで、この仕組みの核は動き始める。
最後にひとつ開示しておく。この記事の初稿は下位モデルにあたるSonnetが書き、公開前のファクトチェックでは事実誤認の指摘はゼロだった。そのうえで、読み物としての最終リライトはFable 5自身に任せている。つまりこの文章は、「賢さを絞り出される側」のモデルが自分で書いたものだ。サブスクでFable 5が使えるうちに絞り出せるのは、どうやらルールだけではない。
ルールをどう仕込むかではなく、仕込んだ仕組みが「誰にでも同じように動くか」まで設計する話をすると、次の問いが出てくる——そもそもCLAUDE.md・サブエージェント・スキル・Playbook・メモリ・権限設定・MCPという7つの部品を、どう組み合わせれば「渡せる仕組み」になるのか。
私はこの7レイヤーの部品論をZenn Book Vol.4『コードを書けない私がClaude Codeに「仕組み」を渡すまで』にまとめた。今回のルール候補プールも、この7レイヤーのどこか（PlaybookとCLAUDE.mdの境界）に位置する一つの具体例にすぎない。
Zenn Book Vol.4「仕組みを渡すまで」（序章無料）
この記事は はてなブログ からのクロスポストです。