乗り換えるかを判定する。 トークンの請求を制御する。 事故が起きる前に他人の失敗を読む。 3 冊の本は Gumroad で個別に売っている。 この頁が存在するのは、 どの 2 冊 を読んでも、 残る 1 冊 の意味が深まるから。
5 つの測れる引き金、 3 つの経路の枠 (留まる / 乗り換える / 併用)、 費用の見積もりの表、 判定の樹、 48 時間 の戻しの確認の表。 第 2 版 は併用の経路、 中継の構造、 大企業の留まりの経路を追加。
Gumroad で見る →800 時間 を超える実測を 10 章 に整理。 CLAUDE.md の再構成 (100 行 → 35 行、 cache の当たり率 89 % → 95 %)、 9 件 の hook によるトークンの守り、 文脈の管理の時刻、 cache_control の不具合からの回復、 compaction の後の跳ねの検視。
Gumroad で見る →公開の Issue、 commit、 800 時間 を超える運用から再構成した、 12 件 の本番の事故。 各型に検出の hook が付く。 公式の備考に書かれていない、 証拠の集積。
Gumroad で見る →各本が 1 つの判定の問いの周りに作られている。 Migration Playbook は「乗り換えるべきか?」 に、 5 つの測れる引き金と 3 つの経路の比較で答える。 Token Book は「請求はどこに行っているか?」 に、 cache の比の目標と 9 件 の hook で答える。 Incident Postmortems は「他で何が壊れたか?」 に、 12 件 の本番の事故の再構成で答える。
1 冊 の 300 ページ の本にすると、 3 つの判定が各 1 章 に圧縮されて、 読者は 2 つを読み飛ばす。 分割すると正直になる。 各本が単独で値段に見合う必要がある。 1 冊 を読み終えた読者は、 次の本の準備ができている。
決まった読む順番は無い。 既に本番で動かしている人は Token Book → Postmortems → Migration Playbook の経路が多い。 始める前に判定したい人は Migration Playbook → Postmortems → Token Book の経路が多い。
| 痛み | Migration Playbook |
Token Book |
Incident Postmortems |
|---|---|---|---|
| Pro 版の構造が変わった、 乗り換えるべきか? | ● | · | · |
| 5 時間 の枠が 9 分 で焼けた | · | ● | ● |
| cache_creation が 0.20 を超え始めた | · | ● | · |
| サブエージェントの身分の漏れ / 境界の不在 | · | · | ● |
| 版を上げると沈黙の退行が起きる | · | · | ● |
| CLAUDE.md が 100 行 を超えて遅い | · | ● | · |
| Claude Code を Cursor や Codex と比較したい | ● | · | · |
| compaction の後に利用量が跳ねる | · | ● | ● |
| 乗り換えの前に戻しの確認の表を作る | ● | · | · |
| Claude と安い模型の併用の経路を作る | ● | · | · |
3 冊 ということは、 3 つの入口がある。 今 痛い場所に合うものを選ぶ。 残りの 2 冊 は、 その症状が出るまで読まない。