この記事は、Claude CodeでFable 5.1を本格的に使い込みたいエンジニア・個人開発者に向けた内容です。読み終える頃には、Fable 5.1を使う上での実践的な工夫(プロンプトの書き方、ハーネス設計での注意点、トークン節約術、よく使う作業のSkills化)がひととおりわかります。
この記事の結論は、「Fable 5.1は『そのまま前のモデルと同じように使う』と本来の実力もコストメリットも引き出しきれない。会話を『追記のみ』で扱うハーネス設計と、Fable 5.1を『判断役』に徹させる使い分けが、実践での差を分ける」ということです。
いま何が起きているか ― 「強くなった」より「使いやすくなった」という現場の声
2026年9月1日の発表直後から、実際に使い倒したユーザーの声がXなどで多数上がっています。あるユーザーは5時間の利用枠を9アカウント分並列で使い切るほど検証した結果、「めちゃくちゃ強くなった、ではなく、めちゃくちゃ使いやすくなったFable」という感想を残しています。特にxhighのeffortで自律ループを回すと、途中で人に聞き返すまでに以前よりずっと遠くまで作業を進められるようになったといいます(X上の検証投稿)。
素の性能向上だけでなく、「長時間の粘り強さ」「作業を続ける力」「クレジット消費効率」が改善されたことが、実践面での評判の良さにつながっているようです。
具体例① ― プロンプトとハーネス設計を「追記のみ」に変える
Fable 5.1をコーディングエージェントとして使う際、いくつか押さえておきたい仕様変更があります。
ツール呼び出しの挙動が変わった: Fable 5では複数のツール呼び出しをまとめて実行していた場面で、Fable 5.1はターンごとに1つずつしか呼び出さないことがあります。独立したツール呼び出しをまとめて実行させたい場合は、プロンプトに「独立した操作は1つのターンでまとめて呼び出してください」のような1行のバッチ化指示を追加するのがおすすめです(Claude公式ドキュメント)。
進捗更新の表示: ツール呼び出しの合間にFable 5.1が書くテキストは、進捗更新用のthinkingブロックとして返されます。作業の様子をユーザーに見せたい場合は、display: "updates" を設定することでテキストとして受け取れます。
ハーネスは「追記のみ」が鉄則: Fable 5.1には、思考内容を保存して悪用(蒸留など)から守る「preserved thinking(思考の保存)」という仕組みがあります。この仕組みの都合上、会話履歴を後から書き換えると、次のリクエストで「thinkingブロックが別の会話に紐づいている」というエラーが発生します。指示を追加したい場合はシステムプロンプトを直接編集せず、会話の途中に挿入する「mid-conversation system message」を使う、ツールを変更したい場合も同様に途中挿入で対応する、というのが基本ルールです(Claude公式ドキュメント)。
会話を圧縮(コンパクション)したい場合も、一番シンプルなのは「履歴全体を1つの要約メッセージ+新しいユーザーターンに置き換え、他は何もリプレイしない」という方法です。thinkingブロックが一切残らないためエラーにならず、圧縮後の会話に対してモデルが新たに考え直してくれます。
この「追記のみ」を徹底すると、実は思考の保存だけでなくコスト面でも二重の恩恵があります。会話のプレフィックス(共通部分)をキャッシュ経由で読む場合は百万トークンあたり$0.25で済みますが、履歴を書き換えてキャッシュが効かなくなると、同じ内容を百万トークンあたり$12.50で読み直すことになります。
具体例② ― トークン節約術「Fable 5.1はオーケストレーターに徹させる」
実務でよく紹介されているのが、Fable 5.1を「すべての作業」ではなく「上位の判断」だけに使う運用です。設計・レビュー・品質保証といった上流の判断はFable 5.1に任せ、実際のコード記述はSonnetなど軽量なモデルに委任する、という役割分担です(Zennの解説記事)。Fable 5.1を計画役(オーケストレーター)に徹させることで、長時間セッションでの判断の一貫性を保ちながら、トークン消費を抑えられます。
これに加えて、前の見出しで触れた「追記のみのハーネス設計」によるキャッシュ活用と、状況に応じたeffort(処理強度)の調整を組み合わせることで、Fable 5.1本来の実力を保ちながらコストを大きく抑えることができます。
具体例③ ― よく使う作業をSkills化して他モデルにも還元する
Fable 5.1の強力な理解力を、一度きりの作業で終わらせず「資産」として残す方法がSkills化です。やり方はシンプルで、週に3回以上頼んでいるような定型作業を選び、その手順を箇条書きにしたメモがあれば、それがほぼそのままSkillになります。実際にFable 5.1へ「毎週やっている〇〇の手順を聞き取ってスキル化して。次から/〇〇で呼べるように作って、テストまでして」と頼むだけで、スキル化から動作確認まで任せられます(note記事)。
実務でのおすすめの運用は、公式ドキュメントをベースにした「Fable 5.1向けにプロンプトを書くためのスキル」をまず作っておき、日々の細かいプロンプト生成はOpusやSonnetなど別のモデルに、そのスキル経由でやらせる形です。Fable 5.1の強力な能力を使ってSkillsの中身を磨いておけば、普段は軽量モデルに戻していても、Claude Codeがこれまでより高い精度で作業してくれるようになります。
スキルの改善には2つの視点が必要とされています。1つは「守り」で、どのモデル・どのタイミングで実行しても同じ品質で動くように、解釈の余地や古い情報を減らしていくこと。もう1つは「攻め」で、実際にうまくいった成果物からパターンを拾い上げ、スキルに反映して再現性を高めていくことです。
だからあなたに関係がある ― 「使い方」次第でコストも成果も変わる
ここまでの工夫は、どれもFable 5.1自体の性能を変えるものではなく、「同じモデルをどう使うか」の話です。裏を返せば、モデルの実力は同じでも使い方次第でコストにも成果にも大きな差が出るということでもあります。特に個人でClaude Codeを日常的に使っている場合、ハーネスの追記のみルールを守るだけでキャッシュ効率が大きく変わり、結果として前回の記事で触れた「週間枠の減りが早い」問題への対策にもつながります。
未来予測 ― 1年後、3年後の「使いこなし方」はどう変わるか
1年後(2027年9月頃)について、私は、オーケストレーターパターンやSkills化のような「モデルの使い分け」のノウハウが、個人開発者の間でも当たり前の設計パターンとして定着していくと見ています。根拠は、モデルの性能そのものよりも「運用の工夫」で成果とコストに差がつく事例が、すでにコミュニティで数多く共有され始めていることです。
3年後(2029年頃)については、こうしたハーネス設計やSkills構築のノウハウ自体が、ツール側に組み込まれて自動化され、利用者が意識しなくても最適な役割分担が行われるようになっているのではないかと私は予想しています。ただしこれはあくまで現時点の情報からの個人的な見立てであり、各社の設計思想やツールの進化スピード次第で状況は変わる可能性があります。
まずはここから試してみてください
まずは、普段Claude Codeで頼んでいる作業の中から「週に何度も繰り返している定型作業」を1つ選んで、Fable 5.1に「これをスキル化して」と頼んでみることから始めてみてください。会話履歴を書き換えない「追記のみ」の使い方を意識するだけでも、体感のコストと安定感がかなり変わってくるはずです。
