先に結論です。この本で置いた仕組みは 31 個あり、AI に依存するものとしないものに分かれています。依存するのは 12 個で、芯は 2 文と指示ファイル 1 枚です。 モデルを変えて壊れるのはそちらだけで、壊れた場所は hook と自動テストが指します。だから新しいモデルが出るたびに全部を確かめ直す必要はなく、壊れた 1 箇所に仕組みを 1 つ置けば足ります。
もう 1 つの結論は、記録の側です。5 か月で hook と自動テストを足した・直したコミットは 93 件あり、理由がモデルや Claude Code のバージョンの変化だったものは 0 件でした。 同じ期間に、手元のモデルは 3 つ、Claude Code のバージョンは 24 回変わっています。
Z.1 私が読まなくなったもの
私は、新しい技術記事を探して読むことをやめました。どのモデルがバイブコーディングに向いているか、このモデルでなければ開発できない、新しい開発手法が出て少し前の手法が古くなった。そういう記事です。
先に線を引いておきます。モデルの選び方の記事は、指示の側が大きい人には正しく効きます。 指示ファイルが 60 行を超えて薄まっている人が、指示をよく読むモデルに変えれば、たしかに改善します。記事が間違っているのではなく、効く場所がある人に効いています。
私に効かなくなったのは、効く場所が無くなったからです。3 作 37 本でやったのは、ルールから仕組みへ移すことでした。移した先は AI が読まなくても動く場所なので、モデルを変えても、挙動が少し変わっても、そこは変わりません。変わるのは残った指示の側だけで、そこは小さい。どのモデルが良いかは、指示の側が小さくなるほど、答えの要らない問いになります。
同じ理由で、私は AI の進歩に振り回されることもやめました。進歩は、指示の側に届きます。仕組みの側には届きません。
Z.2 依存先は 4 つ
置いたものを、何に依存しているかで 4 つに分けます。付録 A〜I がばらばらに書いてきたことを、1 枚にまとめた表です。
| 依存先 | 何に依存するか | 置いたもの | 変わったとき |
|---|---|---|---|
| 機械だけ | Ruby と git だけ。AI を含まない | 自動テスト・ラチェット・pre-commit hook・テストのラッパー・スモークテスト・不具合フォーム | 何も起きない |
| 製品の契約 | Claude Code の契約（hook のイベント・exit code・JSON、settings、Agent ツールの tool_input）。モデルには依存しない | 入口の hook・宣言の hook・memory の hook・用途カタログの hook | 製品のバージョンが契約を変えたときだけ追随する（付録 C・E） |
| 指示 | モデルが読むこと（事前分布・注意の予算・指示の階層。付録 D・I） | 2 文・指示ファイル 102 行・却下の一覧・計画書・完了の形・書式・用途カタログの model の列 | 効き方が変わる。壊れたかは「機械だけ」と「製品の契約」が指す |
| 私 | 私 | 口を挟まない・話を聞かない・質問に答えない | 私が変われば変わる |
「機械だけ」は AI を含みません。付録 F の 8 つの型も、付録 G の git hook も、付録 H のスモークとフォームも、AI が居なくても同じ入力に同じ答えを返します。モデルを変えて壊れることは、原理的にありません。
「製品の契約」は AI を含みますが、モデルは含みません。hook は exit code と JSON で製品と話していて（付録 C.2〜C.4）、どのモデルが動いていても契約は同じです。変わるのは製品のバージョンが契約を変えたときで、これは追随が要ります。付録 E.3 に書いた model の解決順は 2 か月で 3 回変わり、付録 D.10 の宿題 3 件（.claude/agents/*.json・スキルの置き場所・SessionStart の matcher）は、バージョンが形式を変えたのに手元が追随していないものです。「製品の契約」の依存先は製品であって、モデルではない。 ここを分けないと、「Claude Code が変わった」と「モデルが変わった」が同じ不安に見えます。
「指示」だけが、モデルに依存します。指示は user メッセージとして届き（付録 A.4）、モデルが読んで初めて効きます。第 3 部 第 6 回が「ここまでの技術は、測ったモデルの上でだけ成り立つ」と書いたのは「指示」の話で、付録 I が記録したモデル別の指針のずれ（自己検証の「指示は要らない」は Opus 5 のページにだけある。他の現行モデルには「頼め」と書いてある）も、「指示」で起きます。Anthropic の但し書きどおり、特定のモデルで測った技術は、他のモデルへ当てる前に自分で確かめる必要があります。
ただし、確かめる範囲は「指示」だけです。用途カタログの model の列のように、モデル名を書いた設定もここに入ります。モデルが変われば書き換えるものは、モデルに依存しています。
Z.3 31 個を、依存先で振り分ける
最終回に並べた「しなくなったこと」を、置いたものの依存先で色分けします。置いたものは各回の「仕組み」の節の見出しです。
| 第 1 部 | 置いたもの | 依存先 |
|---|---|---|
| テスト結果を読まない | 出力の入口を 1 本にするラッパー | 機械だけ |
| メモリを読まない | 書き込み口を 1 つにする hook | 製品の契約 |
| 単体テストを読まない | 変異注入の方針ファイル | 指示 |
| スキルを使わない | 入口で読ませる hook | 製品の契約 |
| ルールを読まない | ルールを 1 条ずつ翻訳した自動テスト | 機械だけ |
| 共有メモリを整理しない | 保存の後に方針を突きつける hook | 製品の契約 |
| 修正履歴を読まない | 方針ファイルと、瞬間に差し込む hook | 製品の契約 |
| 引き継ぎを読まない | 報告の隣に機械の数字を並べるスクリプト | 機械だけ |
| 口を挟まない | 置くものは無い | 私 |
| 作業結果を読まない | 定型文 2 つ | 指示 |
| 一度読んだら、サブエージェントのログを読まない | 用途カタログを見る hook | 製品の契約 |
| 第 2 部 | 置いたもの | 依存先 |
|---|---|---|
| 提案を検討しない | 却下を 1 枚に集めた一覧 | 指示 |
| 禁止を書かない | 禁止の「理由」の見出し | 指示 |
| 禁止ルールを作らない | 適用範囲を「判定軸」で書いた行 | 指示 |
| 自動テストを書かない | 禁止の「機械検証」の見出し | 指示 |
| AI の確認依頼を断る | 合否を DB で決めるスモークテスト | 機械だけ |
| AI の話を聞かない | 置くものは無い | 私 |
| ルールを整理しない | 「置かなかったもの」の一覧 | 指示 |
| 選択肢を選ばない | 再検討の条件を書いた 1 行 | 指示 |
| 一度確かめたら、サブエージェントの入力を確かめない | 用途カタログの契約を見る hook | 製品の契約 |
| 第 3 部 | 置いたもの | 依存先 |
|---|---|---|
| 検証を指示しない | 実行の依頼に機構の裏打ちを要求する自動テスト | 機械だけ |
| 具体的な指示を出さない | 渡すものの実在を見る hook | 製品の契約 |
| 不具合詳細を書かない | 症状の一文だけを人が打つフォーム | 機械だけ |
| 計画を書けと言わない | 置くものは無い（計画書が読まれる） | 指示 |
| 念を押さない | 強調の件数のラチェット | 機械だけ |
| AI を問い詰めない | 締めの一文を疑問形で固定した定型 | 指示 |
| AI にダメ出ししない | 置き換え先のない禁止を保存の直後に突きつける hook | 製品の契約 |
| AI に考えさせない | 名指しした先に目印を書かせる書式 | 指示 |
| 質問に答えない | 置くものは無い | 私 |
| AI にレビューをさせない | 空回りしている自動テストを外から数える自動テスト | 機械だけ |
| 一度書いたら、サブエージェントに細かく指示しない | 完了の形を書き切った 1 枚 | 指示 |
数えると、「機械だけ」が 8、「製品の契約」が 8、「指示」が 12、「私」が 3 です。⚠️ 最終回の表は 31 行です。初稿では「34 個」と数えていて、第 3 部に第 3 回を新設して改番した後、数を直していませんでした。この結びを書くために表を機械で数え直して、見つけました（そのときは 35 行でした）。⚠️ その後、実行と検証にまつわる 4 本が別の連載へ移り、いまは 31 行です。同じ数を 2 か所で書くと、片方は必ず古くなります。
読み方を 2 つ。モデルに依存する「指示」は 12 個で、3 分の 1 あまりです。 そして「指示」の 12 個は、第 2 部に 6 個集まっています。第 2 部は判断の連載で、判断はモデルが読んで初めて効く。第 1 部と第 3 部が出力と入力を機構へ移したのに対し、第 2 部が移したのは判断を書く場所であって、読むのは今もモデルです。これが、第 2 部の仕組みだけがモデルを変えたときに確かめ直す対象になる理由です。
もう 1 つ。「指示」のものは全部、「機械だけ」か「製品の契約」に見張られています。 却下の一覧は第 2 部 第 5 回の「機械検証」の見出しで自動テストと対応づけられ、書式は名指しと目印の自動テスト（付録 F.7）が見ていて、定型文 2 つの 2 文目は「報告の隣の機械の数字」（第 1 部 第 9 回）と並びます。モデルが読まなくなれば、読まなかった結果が「機械だけ」と「製品の契約」で失敗になります。「指示」が壊れたことを、「指示」に聞く必要はありません。
Z.4 5 か月の記録 —— 仕組みを足した理由
「振り回されなかった」を、自分の記憶ではなく git log で確かめます。hook・pre-commit・自動テスト・ラッパーの置き場所に触れたコミットを 2026-02-10 から 2026-09-06 まで数えると、93 件でした。
| 月 | 件数 |
|---|---|
| 2 月 | 7 |
| 3 月 | 1 |
| 4 月 | 7 |
| 5 月 | 13 |
| 6・7 月 | 0 |
| 8 月 | 37 |
| 9 月（6 日まで） | 28 |
93 件の件名を、足した理由で分けました。手作業の分類なので、分け方も書きます。
| 理由 | 件数 | 判定の仕方 |
|---|---|---|
| 踏んだ不具合・事故を塞いだ | 33 | 件名が「効いていなかった」「漏れ」「穴」「壊れていた」「本番」で、直したのが仕組みの側 |
| 読まれない指示を機構へ移した | 25 | 件名が「検査へ移した」「ラチェットを置いた」「hook を足した」「機械検証」で、元がルールか方針 |
| 新しい機能の器に自動テストを付けた | 19 | 件名の主語が機能（記事のサイト内公開・本の生成・単語帳）で、自動テストはその一部 |
| 初期構築と運用の整備 | 12 | 2 月の基盤・hook の設置・CI から pre-commit への移行・memory の整理 |
| merge | 4 | — |
| モデルや Claude Code のバージョンが変わったから | 0 | 件名と本文に「モデルを変えた」「バージョンが変わった」に当たる語が無い |
最後の行は機械でも見ました。93 件の件名と本文から署名の行を除いて、モデル名・v2.1.・「バージョン」・「モデルを変え」を探すと、当たるのは 1 件で、それは 13 体を opus で起動して 173 万トークンを無駄にした日の記録です（第 1 部 第 5 回）。モデルの名前は出てきますが、理由は事故で、モデルの変化ではありません。
同じ期間に何が変わっていたかも、手元の transcript で数えました。残っている 321 本（2026-07 以降）の assistant メッセージの model を月ごとに数えると、8 月は Opus 5 が 90%・Fable 5 が 9%、9 月は Opus 5 が 70%・Fable 5.1 が 18%・Fable 5 が 10% です。サブエージェントは付録 E.3 のとおり Opus 70・Sonnet 16・それより上の階層 13・Haiku 1。Claude Code のバージョンは、同じ transcript の version で 8 月に 19 種類、9 月の 6 日までに 5 種類、合わせて 2.1.220 から 2.1.261 まで 24 回変わっています。
モデルが 3 つ、バージョンが 24 回変わるあいだに、仕組みを足した理由にモデルもバージョンも 1 度も出てこない。 これが「振り回されなかった」の実測です。⚠️ 追随が要る宿題は 3 件あって（Z.2 の「製品の契約」）、それはバージョンが変えた契約に手元が追いついていないものです。理由に出てこないのは、まだ直していないからでもあります。
Z.5 なぜ膨大な検証が要らないか
モデルを変えるとき、私がやることは 3 つです。
- 「機械だけ」と「製品の契約」は、確かめない。 AI を含まないか、製品の契約で話しているので、モデルで変わりません。各回の検証手順が「止まるべきものが止まり、通るべきものが通る」の形なのは、機構を測っていてモデルを測っていないからで、この形の検証はモデルを変えても結果が同じです。
- 「指示」は、2 文だけで 1 日回す。 「次の作業を進めてください」と「ここまで不足点はないですか？確認して不足点がなければ次のセッションに引き継いでください」。1 日の終わりに、hook が止めた回数・自動テストの失敗・自己申告と機械の数字のずれを数えます。第 3 部 第 6 回の probe と同じ形で、1 課題を 2 通りで投げれば手数の差も出ます（付録 E.10）。
- 壊れた 1 箇所に、仕組みを 1 つ置く。 「指示」で壊れたものは、壊れ方が分かった時点で「機械だけ」か「製品の契約」に移せます。移した分だけ、次のモデルで確かめる範囲が減ります。
膨大なパターンの検証が要らないのは、確かめる対象が「指示」の 12 個で、そのどれもが「機械だけ」と「製品の契約」に見張られているからです。全部のプロンプトを全部のモデルで試す必要はなく、壊れたら分かる形にしてあるものは、壊れてから直せばいい。 第 1 部の序論に書いた「失敗してから置く仕組みは、なぜ要るかを目撃した直後なので、よく馴染みます」は、モデルを変えるときにも、そのまま当てはまります。
Z.6 本編との対応
- 第 1 部 序論・第 6 回（足すほど薄まる / 文脈であって強制ではない）—— 「指示」が薄まる話。「機械だけ」と「製品の契約」は薄まらない
- 第 2 部 第 4 回・第 3 部 第 6 回（契約 / 測ったモデルの上でだけ成り立つ）—— 「製品の契約」の契約と、「指示」の但し書き。この結びは 2 つを分けた
- 第 3 部 第 1 回（指示ファイルは 2 回、自分で減った）—— 減った 2 日は、どちらも「指示」から「機械だけ」と「製品の契約」へ移した日
- 3 作の最終回（2 文 / 8 つ / 31 個）—— 2 文は「指示」の全部で、31 個のうち 16 個は「機械だけ」と「製品の契約」
Z.7 本編が言っていない注意
- 実測は Claude だけです。 Opus 5・Fable 5・Fable 5.1・Sonnet・Haiku で測り、他社のモデルでは測っていません。「機械だけ」は原理的にモデルを選びませんが、「製品の契約」は Claude Code の契約なので、別の製品では hook の契約から置き直しになります。
- 「製品の契約」の追随は、モデルではなくバージョンで起きます。 付録 D.10 の宿題 3 件と付録 E.3 の解決順の変更は、全部これです。「モデルが変わって壊れた」と感じたとき、まずバージョンの変更履歴を見てください。
- 用途カタログの
modelの列は「指示」です。 モデル名を書いた設定は、モデルが変われば書き換えるものです。手元はsonnet/haiku/opusの family で書いていて、付録 E.3 のとおり family alias は許される最新のバージョンに解決されるので、同じ family の新しいバージョンには書き換えなしで追随します。family が増えたら書き換えます。 - 「指示」の「壊れた」は、遅れて分かります。 hook と自動テストが指すのは、読まれなかった結果が形になった後です。読まれた瞬間には分かりません。付録 I.12 の自己報告の不忠実は、ここでも同じです。
- git log の分類は手作業です。 件名で分けたので、本文に別の理由が書かれていれば漏れます。検証手順 1 に、機械で数えられる部分だけを書きます。
Z.8 検証手順
本編と同じ型です。止まるべきものが止まり、通るべきものが通ることを、両方向で見ます。
1. 5 か月の記録を、あなたの手元で数える。 hook と自動テストの置き場所を列挙して、コミットの件名と本文から署名の行を除き、モデル名とバージョンの語を探します。
# 置き場所は自分の環境に読み替える
git log --format='%h %s%n%b%n@@END@@' -- .claude/hooks .git-hooks test/reference \
| grep -v -E '^Co-Authored-By' \
| awk 'BEGIN{RS="@@END@@\n"} /[Oo]pus|[Ss]onnet|[Hh]aiku|モデルを変え|バージョンアップ/{n++; split($0,l,"\n"); print l[1]} END{print "該当", n+0, "件"}'0 件なら、仕組みを足した理由にモデルは出ていません。当たった行は、理由がモデルの変化なのか、事故の記録にモデル名が出ただけなのかを読んで分けます。陽性対照として、直近のコミットに「モデルを変えたので hook を直した」と書いた空コミットを 1 つ作り、1 件になることを見てから消します。
2. モデルの変遷を数える。 transcript の assistant メッセージの model を月ごとに数えます。付録 A.9 の 5 と同じ読み方で、type が assistant の行の message.model を集計するだけです。モデルが 2 つ以上出ていれば、手順 1 の 0 件は「変わっていないから 0」ではなく「変わったのに 0」です。1 つしか出ていなければ、この結びの主張はあなたの手元ではまだ測れていません。
3. モデルを 1 つ変えて、2 文だけで 1 日回す。 起動時のモデルを変え、その日の入力を 2 文に限ります。終わりに 3 つを数えます。hook が止めた回数（「製品の契約」）、自動テストの失敗（「機械だけ」）、自己申告と機械の数字のずれ（第 1 部 第 9 回の観測点）。前日と比べて増えたものが、「指示」で壊れた場所です。⚠️ 3 つとも 0 で、AI の応答が「完了」だけなら、それは壊れていないのではなく、「機械だけ」と「製品の契約」が見ていない場所で壊れている可能性があります。付録 F.2 の空虚な真と同じで、手順 4 を先にやってください。
4. 陽性対照。 「指示」の 1 つを意図的に壊します。却下の一覧から 1 件を消して、同じ提案が来ることを見る（第 2 部 第 1 回）。指示ファイルの「コミット前に必ず実行」を消して、自動テストが「機構の裏打ちが無い」で落ちることを見る（第 3 部 第 1 回）。壊したものが「機械だけ」と「製品の契約」で失敗になれば、手順 3 の 0 は信じてよい数です。戻します。
5. 壊れた 1 箇所に、仕組みを 1 つ置く。 手順 3 で増えたものの中から 1 つ選び、「機械だけ」か「製品の契約」に移します。移した後にもう 1 日、手順 3 を繰り返します。増えたものが 1 つ減っていれば、確かめる範囲がその分だけ小さくなっています。
Z.9 出典（2026-09-06 確認）
- 手元の実測 —— hook・pre-commit・自動テスト・ラッパーの置き場所に触れたコミット 93 件（2026-02-10 〜 2026-09-06）の件名と本文 / transcript 321 本（2026-07 以降）の
modelとversionの月別集計 / 3 作の最終回の一覧 35 行と各回の「仕組み」の見出し - Prompting best practices —— 特定のモデルで測った技術を他のモデルへ当てる前に確かめる但し書き（第 3 部 第 6 回が引いたもの。付録 I.6 の突き合わせ表）
- 付録 A.4（指示は user メッセージとして届く）/ C.2〜C.4（hook の契約）/ D.10（バージョンへの追随の宿題）/ E.3（model の解決順と family alias・サブエージェントのモデルの内訳）/ E.10（probe の型）/ F.2（空虚な真）/ F.7（名指しと目印）/ I.6・I.7・I.12（モデル別の指針・自己検証・自己報告）
本編で終わったはずの文章を、また書いています。
書く必要は、もうなくなりました。
私はこれから、何もしません。