Fable 5が使えなくなる前に、その「働き方」をOpus/Sonnetに引き継がせた

📝 記事の概要

Claude Codeの最上位モデル「Fable 5」が2026年7月7日でサブスク終了となる中、そのオーケストレーション能力をOpus/Sonnetに引き継ぐための実践的なアプローチを解説した記事です。著者は ccteams というClaude Code用チーム構築CLIをメンテナンスしており、実際のプロダクションで検証した知見を共有しています。

🔑 重要ポイント

1. Fable 5とOpus/Sonnetの差は「知能」ではなく「規律」

Fable 5が暗黙的に行っていたチェック（入力検証、キャッシュ指定、実行確認など）は、知識の欠落ではなく「正しい手順の欠如」が原因。これを明文化すれば再現可能。

• ボタン1個にonClickが必要なだけでページ全体に "use client" を貼る
• fetchにキャッシュ指定を書かない → 本番でキャッシュにハマる
• Server Actionの入力検証を省く → 誰でも任意の引数で叩ける公開エンドポイントに
• 落ちたテストを直すためにアサーションの方を書き換える
• 何も実行せずに「これで動くはずです」と言う

→ 知識はあるが、正しい手順が欠けている。これらはスキルとして書くことが可能。

2. 「注意深く」というプロンプトは効かない

「注意深く」「ベストプラクティスに従え」「よく考えて」といった表現は、モデルの「次の一手」を変えないため挙動が変わらない。すべてのプロンプトは実行可能または検証可能である必要がある。

3. 5つの軸でFable 5の働き方を明文化

① 作業ルーティンを固定する

• 言語機能を使う前に go.mod のバージョンを読む
• ライブラリのドキュメントを信じる前に、ロックファイルで実際のバージョンを確認
• ヘルパーを書く前に grep する（別名で既に存在していることが多い）
• 「記憶で判断するな、リポジトリを読んで判断しろ」

② 失敗パターンと解決策を定義

各チームごとに「症状 → ありがちな間違い → 正しい一手」を10〜15件定義。意思決定ポイントにパッチを当てる仕組み。

③ 意思決定の分岐を定義

goroutine起動前の3つの質問（誰がキャンセルする？誰が待つ？エラーはどこへ行く？）や、デバッグ時の因果関係の強制（「XがYを引き起こす、なぜならZ」を言えなければ修正フェーズに進めない）。

④ 検証方法を定義

• 「テストしてね」ではなく、どのコマンドをどの順で、各失敗が何を意味するかまで明記
• すべての主張に VERIFIED（実行した）/ REASONED（コードを読んだ）/ ASSUMED（未確認）のラベルを義務付け
• 無断の昇格（ASSUMED→VERIFIED等）を禁止

⑤ 学習ループで失敗を吸収

予測外のミスに出くわしたら「症状→間違い→正しい一手」としてカタログ化し、人間の承認後にルール追加。使えば使うほどプロジェクト固有に最適化されていく。

4. サブエージェントへの確実な伝達

• 全エージェントのシステムプロンプトを「FIRST ACTION: playbookを読み従え」で開始
• フォールバックとして最重要ルール5〜6行をプロンプト自体にも埋め込む
• オーケストレーターの委譲プロンプトにworking-methodの圧縮版を逐語コピー
• 名前付きゲートで差し戻し：「buildの出力が引用されていない？差し戻し」

5. チーム内でのモデル配分

判断が必要な席（スコープ切り・設計・レビュー）はOpus、決まった手続きに従う実装・シッピングはSonnet。オーケストレーターと作業者を分けたのと同じ原理をもう一段繰り返している。

💡 著者の結論

定型作業に関しては、この設定でFable 5とその他モデルの差はほぼなくなった。ただし、Fable独自の強みである「予期できない場合の対応」「チェックリストにない違和感の検知」「全く新しい問題の構造把握」は、スキル書き程度では埋まらない。その差分を学習ループが少しずつ削っていく仕組み。

🛠️ ツール情報