はじめに
Claude Code には Fable 5 / Opus / Sonnet / Haiku と複数のモデルがあり、/model コマンドでいつでも切り替えられます。しかし実際の開発では、
- なんとなく感覚で Fable と Sonnet を行き来している
- 最新モデル Fable 5 は高性能だがトークン消費が激しすぎて、5時間ウィンドウをあっという間に溶かす
-
/clearや/compactを乱発すると文脈を喪失し、前提を無視した実装をされる
という状態に陥りがちです。本記事では、新規アプリ開発と既存リポジトリのリファクタリングの2つのシナリオについて、フェーズごとのモデル使い分けとコンテキスト操作の指針を整理します。
前提環境
- Windows 11 + WSL2 (Ubuntu 24.04)
- Claude Code(サブスクリプション Max 5x プラン)
- 利用モデル: Fable 5 / Opus 4.8 / Sonnet 5 / Haiku 4.5
- 個人開発を想定(チーム開発でも大枠は流用可能)
1. まず前提を正す: よくある3つの誤解
戦略を立てる前に、公式ドキュメント・コミュニティ情報を調べて分かった「前提の誤り」を共有します。ここを間違えると戦略設計そのものがズレます。
誤解① 「Fable からSonnet/Opus に切り替えるとコンテキストウィンドウを超過する」
→ Sonnet 5 を使っている限り、ほぼ成立しません。
Pro/Max プランの Claude Code では、Sonnet 5・Fable 5・Opus 4.8/4.7/4.6 はいずれも 1M トークンのコンテキストウィンドウをサポートしています。200k なのは Sonnet 4.5 以前や Haiku などです。
つまり「ウィンドウ超過を回避するための /clear・/compact」という動機は不要で、コンテキスト操作の目的は次の2つに純化できます。
- 品質維持: コンテキスト汚染(無関係な履歴・失敗した試行錯誤)による出力劣化の防止
- コスト削減: 毎ターン全履歴が再送されるため、長いコンテキスト = 高い消費
誤解② 「モデル切り替えはタダ」
→ セッション途中のモデルスイッチはそれ自体が高コストです。
モデルを切り替えると、次の応答ではキャッシュなしで会話履歴全体を新モデルが再読み込みします。履歴が長いほど切り替え1回のコストが跳ね上がります。モデルピッカーが「事前出力がある場合に確認を求めてくる」のはこのためです。
したがって基本方針は:
モデルを跨ぐときは原則ファイル経由(handoff.md 確定 → /clear → 新モデル)。同一セッション内スイッチは例外。
誤解③ 「/compact は自動でやってくれるから気にしなくていい」
→ 自動圧縮を待つと手遅れです。
コンテキスト使用率が 60〜70% を超えると性能が目に見えて劣化する、いわゆる "dumb zone" の存在がコミュニティで広く報告されています。自動圧縮の発火はそれより後です。使用率 50% で手動 /compact、80% 超なら handoff 化して /clear が推奨ラインです(/context で確認できます)。
2. モデル特性の整理
| モデル | API価格 (入力/出力, per 1M tok) | 得意領域 | 使いどころ |
|---|---|---|---|
| Fable 5 | $10 / $50 | 長期エージェント作業、全体最適の判断、深い監査 | 要件・設計の監査、不可逆変更の最終チェック |
| Opus 4.8 | $5 / $25 | 複雑な設計、高精度レビュー | アーキテクチャ判断、完成レビュー、難所の設計 |
| Sonnet 5 | $3 / $15 | 日常のコーディング全般 | 実装のデフォルト、通常設計、ドキュメント整理 |
| Haiku 4.5 | $1 / $5 | 軽量・高頻度・機械的タスク | grep・列挙・依存関係収集などの探索サブエージェント |
役割を一言でまとめると:
Fable = 判断・監査・全体最適(要所限定。常用しない)
Opus = 複雑設計・高精度レビュー
Sonnet = 実装・通常設計・整理(デフォルト)
Haiku = 探索・列挙・grep(サブエージェントで)
Fable 5 は Opus 4.8 のちょうど 2 倍の単価で、Max プランの 5 時間ウィンドウを劇的に速く消費します(重いエージェントセッション1本でウィンドウを使い切った報告も複数あります)。Fable を「監査官」として要所に限定投入するのが費用対効果の要です。
3. 大原則: 会話文脈ではなく「成果物ファイル」を継承する
本記事の戦略の中核はこれです。
セッションの会話履歴を正本にしない。
handoff.mdなどの成果物ファイルを正本にする。
フェーズの区切りで「そのフェーズの結論・前提・残タスク」をファイルに書き出して確定させれば、/clear しても文脈喪失のリスクは最小化されます。モデル切り替えもこのファイルを介して行うため、誤解②の「履歴再読み込みコスト」も発生しません。
handoff.md に最低限含めるもの:
- 確定した要件・設計判断とその理由
- 採用しなかった案と却下理由(蒸し返し防止)
- 制約・前提条件(「〜は変更禁止」など)
- 残タスクと次フェーズの入口
4. 新規開発の推奨フロー
フロー全体像
工程別の詳細
| 工程 | モデル | セッション/コンテキスト操作 | ポイント |
|---|---|---|---|
| 要件の粗整理・ユーザーストーリー草案 | Sonnet 5 | 維持 | 発散フェーズは安いモデルで十分 |
requirements.md 草案作成 |
Sonnet 5 | 草案確定後 /clear | 同一セッションで草案まで書き切る |
| 抜け漏れ・技術選定・リスク監査 | Fable 5 | 新セッションでファイルを読ませる | 会話履歴ではなくファイルを監査させる |
| 監査指摘の反映・仕様確定 | Fable 5(同セッション) |
handoff.md 確定後 /clear
|
Fable使用後は必ず handoff 化 |
| 具体設計 | opusplan(Plan Mode = Opus) | 維持 | 組み込みエイリアスで自動ハイブリッド |
| 実装 | opusplan(実行 = Sonnet 5) | Phase ごとに phase-log.md 更新 → /compact
|
使用率50%超でもPhase途中で/compact |
| テスト・修正 | Sonnet 5 | 維持 | 2回修正して直らなければ /clear して仕切り直し |
| 完成レビュー | Opus | 新セッション推奨 | 実装履歴の汚染なしでレビューさせる |
| 重大リスク・仕様逸脱の最終監査 | 必要時のみ Fable 5 | 終了 or handoff 化 | 不可逆変更・セキュリティ関連時のみ |
元案からの主な変更点
- 要件フェーズ内の Sonnet⇄Fable 往復を廃止。「Sonnet で草案 → ファイル化 → 新セッションの Fable で監査」に一本化(セッション内スイッチのコスト回避 + 文脈汚染防止)。
-
設計〜実装は
opusplanエイリアスに委譲。Plan Mode 中は Opus、実行モードに移ると自動で Sonnet に切り替わる組み込み機能で、手動スイッチが不要になります(/model opusplan)。 -
/compactは「Phase 完了時」に加えて「使用率 50% 超」の閾値を追加。
5. 既存リポジトリのリファクタリング推奨フロー
フロー全体像
工程別の詳細
| 工程 | モデル | セッション/コンテキスト操作 | ポイント |
|---|---|---|---|
| 構造調査・grep・依存関係収集 | Haiku 4.5(サブエージェント) | 結論のみ親に返す | 親コンテキストを汚染しない |
調査結果の一覧化(survey.md) |
Sonnet 5(親) | 確定後 /clear | ファイル読み込み20回分を親に持ち込まない |
| 構造矛盾・設計負債・優先順位監査 | Fable 5 |
新セッションで survey.md を監査 |
下位モデルの調査結果を疑わせる |
| Issue 分類・実装単位化・品質レビュー | Fable 5(同セッション) |
refactor-handoff.md 確定 → /clear
|
監査と計画は連続タスクなので同セッションで完結 |
| 各 Issue の具体設計・実装 | Sonnet 5(難所は opusplan) | Issue 完了ごとに /compact、別 Issue へ移るときは /clear | 無関係な Issue の履歴は持ち越さない |
| レビュー | Opus | 維持 | |
| 大規模・不可逆変更の最終監査 | 必要時のみ Fable 5 | 新セッション | 全 Issue で使うのは過剰 |
元案からの主な変更点
-
探索は Haiku 4.5 のサブエージェントに委譲。サブエージェントの YAML フロントマターで
model: haikuを指定でき、親(Sonnet や Fable)のコンテキストを汚さずに並列調査できます。「Fable オーケストレータ + 安価なワーカー」構成の応用です。 - 元案では「Issue 分類 = Sonnet/Opus」「Issue 品質レビュー = Fable/Opus」と分かれていましたが、Fable の監査セッション内で分類まで完結させました。監査→計画は文脈が連続しており、ここで分断してモデルスイッチするほうが高くつくためです。
- 「別 Issue へ移るときは /clear」を明文化。Issue 間の履歴持ち越しは典型的なコンテキスト汚染源です。
6. コンテキスト操作の最終ルール(改訂版)
【使用率ベースの閾値】(/context で確認)
〜50% : そのまま継続
50% 超 : Phase途中でも /compact "◯◯に注力して要約" を実行
80% 超 : handoff.md 化して /clear(要約より仕切り直しが有効)
【イベントベース】
同一Issue・同一Phase継続:
/clear しない(深い問題に取り組み中の履歴は価値がある)
Phase / Issue 完了:
phase-log.md / handoff.md 更新 → /compact
設計フェーズ → 実装フェーズ:
handoff.md 確定 → /clear
別Issue・別機能・会話が迷走:
handoff.md だけ残す → /clear
※ 2回修正して直らなければ、修正を重ねず /clear して
学びを反映した初期プロンプトで仕切り直す
モデルを跨ぐとき:
原則: handoff.md 確定 → /clear → 新セッションで新モデル
例外: opusplan の自動切替(これは設計上許容)
Fable 使用後:
そのまま引きずらず、必ず handoff 化して終了 or /clear
/compact には保持指示を付けられます(/compact API変更点と修正ファイル一覧に注力)。CLAUDE.md に「圧縮時は修正ファイル一覧・現在のテスト状況・制約条件を必ず保持すること」と常設しておくと、自動圧縮時の文脈喪失も緩和できます。
7. Fable 5 運用の注意点(ハマりどころ)
7-1. effort 設定がコストの主犯になりうる
Fable 5 は思考(thinking)をオフにできず、/effort レベル(デフォルト high、上に max / ultracode)に応じて思考量が変わります。max / ultracode は使用枠を最速で溶かす設定として悪名高く、「並列2スレッド × ultracode で30分放置したら Max 5x の5時間枠が消滅した」系の報告の主因はモデルではなく effort です。監査用途なら high のままで十分です。
7-2. 安全分類器によるサイレントフォールバック
Fable 5 はサイバーセキュリティ・生物学系の安全分類器を持ち、フラグされたリクエストは Opus で再実行され、以降セッションは Opus のまま継続します(トランスクリプトに通知は出ます)。CLAUDE.md や git status を含む初回リクエストで発火することもあるため、「Fable に監査させたつもりが Opus だった」を避けるには、Fable 工程の開始時と終了時に実行モデルを確認する癖をつけてください。戻すには /model fable です。
7-3. Claude Code / claude.ai は同じ使用枠を消費する
Claude Code のセッションと claude.ai での会話は同一の5時間ローリングウィンドウ・週次上限を消費します。Claude Code 用の別枠はありません。重いリファクタ監査の前に claude.ai で長文分析をしていると、枠が既に減った状態でスタートすることになります。
8. まとめ
| 原則 | 内容 |
|---|---|
| 正本はファイル | 会話履歴ではなく handoff.md / phase-log.md を継承する |
| スイッチはファイル経由 | セッション内モデル切り替えは履歴再読み込みで高コスト。/clear + 新セッションが基本 |
| Fable は監査官 | 常用せず、要件監査・計画監査・不可逆変更の最終チェックに限定 |
| 実装は opusplan / Sonnet 5 | 計画 = Opus、実行 = Sonnet の自動ハイブリッドを活用 |
| 探索は Haiku サブエージェント | grep・列挙は親コンテキストの外でやらせ、結論だけ受け取る |
| /compact は 50% で手動 | dumb zone(60〜70%)に入る前に。80% 超なら /clear |
| effort に注意 | Fable の max / ultracode はウィンドウ即死級 |
「なんとなく感覚で切り替える」状態からの脱却ポイントは、突き詰めると**「モデルの切り替え判断」を「フェーズの区切り(=ファイル確定のタイミング)」に固定してしまう**ことでした。切り替えタイミングを毎回考えるのではなく、handoff.md を書いた瞬間が切り替えポイント、というルールにすれば迷いがなくなります。
参考リンク
- Best practices - Claude Code Docs
- Model configuration - Claude Code Docs
- Models, usage, and limits in Claude Code - Claude Help Center
- How large is the context window on paid Claude plans? - Claude Help Center
- Context windows - Claude Platform Docs
※ 価格・仕様は 2026年7月時点の情報です。頻繁に変わるため、最新は公式ドキュメントを確認してください。