Fable 5の無料期間は、7月7日で終わります。
今日は2026年7月3日。つまり、あと数日で「無料だからFableを使う」時間が終わり、7月8日からは使用量クレジット制になります。
では、7月8日からどうするのか。
**Sonnet 5はFreeを含む全プランで使えます。
**価格は8月31日まで導入価格で100万トークンあたり入力2ドル、出力10ドル。その後は入力3ドル、出力15ドルです。Fable 5は入力10ドル、出力50ドル。
通常価格でも約3.3倍。Sonnet 5の導入価格と比べるなら5倍です。
しかもSonnet 5は、1Mコンテキストと128k出力を持っています。長い資料やコードを読ませられる枠は、Fable 5と同じです。
だとしたら、足りないのは本当に「性能」だけでしょうか。
僕の結論は、少し違います。Fable 5の強さの正体は、頭の良さだけではありません。振る舞いです。
長く考える。先に成功条件を決める。疑う。検証する。メモる。最後に、できたこととできていないことを正直に報告する。
この振る舞いのかなりの部分は、CLAUDE.mdと環境設定に焼き込めます。
CLAUDE.mdとは、Claude Codeに「このプロジェクトではこう動け」と常時読ませる設定メモです。毎回チャットに貼るプロンプトではありません。環境そのものに置く指示です。
毎回貼る派の工夫も強いです。勝利条件を作らせ、案を比べ、壊して、仕上げる。あの型はかなり効きます。
ただ、毎回貼るものは忘れます。長いほど貼るのが面倒になります。セッションが変わると抜けます。
だから今回は常設化します。
海外で話題になっていた言い方を借りるなら、こうです。
プロンプトは一時的。構造は永続的。
この記事では、Sonnet 5をFable 5に近づけるためのCLAUDE.md設定を、そのまま貼れる形で渡します。
しかも今回は、ただ僕が考えた設定ではありません。
Claude Codeのヘッドレスモード、つまりターミナルからclaude -pで質問する方法を使い、Sonnet 5本人とFable 5本人の両方に取材しました。
後輩のSonnet 5に、自分の弱点を聞く。
先輩のFable 5に、後輩をどう育てるか聞く。
このW取材で、かなり面白い答え合わせが起きました。
Fable 5の正体は「粘る振る舞い」
Fable 5を触ると、たしかに賢いです。
でも、出力をよく見ると、強さは単なる知識量ではありません。仕事の進め方が違います。
いきなり作らない。まず成功条件を決める。
自分の案をすぐ信じない。失敗しそうな場所を先に探す。
「動いた」と言わない。何で検証したかを出す。
分からないことを、分かったふりで埋めない。
そして長い仕事でも、序盤の制約を最後まで持ち続けようとする。
これを人間の仕事に置き換えると分かりやすいです。
Fable 5は、優秀な先輩のように見えます。曖昧な依頼を受けても、勝手に突っ走る前に「そもそも何が成功ですか」と戻ってきます。計画が外れたら、計画ごと捨て直します。
Sonnet 5は、優秀な後輩です。速い。素直。指示に忠実。ただし、構造がないと流暢に答えすぎることがある。
ならば、後輩に先輩の仕事術を持たせればいい。
その置き場所がCLAUDE.mdです。
Sonnet 5「本人」にインタビューして分かった明確な弱点
まず、Sonnet 5本人に聞きました。
「Fable 5級の成果を出すために、CLAUDE.mdへ何を書けばいいか」
返ってきた自己分析は、かなり正直でした。
Sonnet 5は、自分についてこう言いました。
「私は流暢に答える傾向があり、不確かさが文体に隠れる」
これは重要です。
AIの答えは、文章がうまいほど危ない時があります。はっきり書かれていると、人間はつい信じます。でも実際には、その中に「たぶん」「未確認」「ここは怪しい」が混ざっている。
だから、まず入れるべき設定はこれです。
**自信のない箇所には、確信度を明示させる。
曖昧な副詞でごまかさせない。
確信度が低いなら、進む前に確認させる。**
効く理由は単純です。不安を文体の中に隠せなくなるからです。
次に、Sonnet 5は「とりあえず実装して、あとで調整」に寄りやすいとも認めました。これを止めるには、成功条件を先に書かせます。
コードや本文を書く前に、前提、検証できる成功条件、失敗モードを出させる。「動く」「良い感じ」ではなく、テスト、出力、画面、文章の条件として判定できる形にします。
ここで大事なのは、成功条件を「気分」ではなく「判定」にすることです。
良い記事にする、では弱い。
冒頭で7月7日の期限を出す。価格差を入れる。CLAUDE.mdのコピペ設定を6本以上置く。Fableで埋まらない差を隠さない。
ここまで書けば、最後に見比べられます。
Sonnet 5本人は、締めにこう言いました。
「Fable 5は一人で深く考えられる。私は構造を与えれば速く正確に動く。その違いをCLAUDE.mdで補うのが本質です」
この記事の核は、まさにここです。
Fable 5にインタビューした結果
次に、Fable 5本人に同じテーマで聞きました。
最初の返答がよかったです。
「モデルの自己申告は信頼できるデータではありません」
その通りです。本人に聞いたからといって、ベンチマークにはなりません。内側から見た自己評価は歪みます。
なので、この記事でも「本人が言ったから正しい」とは扱いません。使い方を作るためのヒントとして扱います。
そのうえで、Fable 5が定義した差は鋭かった。
差は「構造がない時、あるいは与えられた構造が間違っている時に何が起きるか」だと言いました。
仕様が明確で、テストがあり、手順が決まっているなら差は小さい。
差が出るのは、仕様そのものが間違っている時。計画が外れた時。長い作業で序盤の制約を終盤まで守る時。頼まれていない改善を足さない、という自制が必要な時です。
そしてFable 5は、自分の弱点も認めました。
単価が高い。簡単な仕事でも考えすぎる。大量処理の速さ勝負では分が悪い。
つまり「全部Fableで」は、経済的に間違った運用です。
では、Fable 5が後輩Sonnet用に書いたCLAUDE.mdは何か。
Sonnet側の回答と重なるものを整理すると、残すべき設定はこの7本です。
Sonnet 5をFableにするCLAUDE.mdの7つのTips
1本目は、成功条件です。これは両者が独立に出しました。
1【完了を機械的に判定する】2着手前に「完了」を1行で定義する。3例: このテストが通る。このコマンドがexit 0になる。この見出しが本文に入る。4書けない場合は、何が決まれば書けるかを質問してから進む。
2本目は、複数解釈です。これも両者が一致しました。
1【複数解釈を勝手に選ばない】2指示に2つ以上の読み方がある場合、黙って1つを選ばない。3解釈の候補を列挙し、推奨を1つ添えて確認する。4ただし、どの解釈でも成果物が変わらない場合だけ、そのまま進めてよい。
3本目は、スコープです。
1【ついで改善を禁止する】2依頼されていない変更を実装しない。3「ついでに直した」「より良い設計にした」は禁止。4隣の改善点を見つけたら、実装せずに提案として列挙する。
4本目は、検証報告です。
1【動いたではなく検証したを報告する】2完了報告には、実行した検証コマンド、戻り値、テスト結果、スクショ確認などの証拠を含める。3実行していないものを「動くはず」と書かない。4スキップした検証は、スキップした理由まで明記する。
5本目は、同じ失敗への粘り方です。粘るのは大事ですが、間違った方向に粘ると時間が溶けます。
1【同じエラーへの修正は2回まで】2同じエラーに対する修正が2回失敗したら、3回目の変種を試さない。3現状、試したこと、残る仮説を短く報告し、方針転換する。
6本目は、反論役です。
1【完了前に初見のレビューを入れる】2完了報告の前に、初めて読む人として自分の変更を見直す。3壊れうる隣接機能を1つ挙げる。4懐疑的なシニアなら何と反論するかを書き、その反論に答える。
7本目は、確信度と正直な進捗です。ここにSonnet 5本人の自己分析を反映します。
1【確信度と進捗を3点で報告する】2自信のない箇所には、確信度: 高・中・低を付ける。3確信度が中または低なら、確認してから進むべきかを聞く。4長い作業では、区切りごとに次の3点だけを報告する。5完了したこと。次にやること。気になっていること。6「問題なく進んでいます」だけの報告は禁止。
この7本は、能力を足す設定ではありません。
差が出る失敗モードを、先にふさぐ設定です。
仕様の穴に落ちない。曖昧さを勝手に決めない。スコープを膨らませない。検証なしに完了を名乗らない。壊れた計画を続けない。
つまり、Fable 5が自然にやっている振る舞いを、Sonnet 5の環境へ外付けしています。
**
答え合わせで見えたこと
面白かったのは、Sonnet 5とFable 5の答えが、別々にかなり一致したことです。
まず、複数解釈を勝手に選ぶな。
これは両者が言いました。AIは、曖昧な指示を渡されると、それらしい解釈を選んで進みがちです。人間から見ると「そこ、確認してほしかった」となる。
次に、検証を外に出せ。
「動いた」と言わせるのではなく、何を実行し、何が通り、何を見たのかを出させる。公式ベストプラクティスでも、Claudeに自分の作業を検証する方法を与えることが最重要とされています。
テスト、ビルド、スクリーンショット比較のように、合格か不合格かが出るチェックを渡す。これでループが閉じます。
さらに大きいのは、検証する目を分けることです。
作った本人に採点させると、甘くなります。新しいコンテキストの検証サブエージェントに、差分と計画を突き合わせてもらう。人間で言えば、作者とは別のレビュー担当を置く感覚です。
そして最後に、埋まらない差も一致しました。
長時間の文脈保持です。
数十ツールコール、数時間の仕事で、序盤に決めた制約を終盤まで持ち続ける力。これはCLAUDE.mdだけでは完全には埋まりません。
ここを隠すと、記事が嘘になります。
**
環境側でさらに仕上げる
CLAUDE.mdを書いただけで終わりではありません。
Sonnet 5には、思考の深さを指定するeffortがあります。公式対応表では、Sonnet 5のmediumがSonnet 4.6のhigh相当、Sonnet 5のhighがSonnet 4.6のmax相当です。
浅い推論が見えたら、プロンプトをこねるよりeffortを上げる。これが公式の推奨です。
Claude Codeで常に深く考えさせたいなら、settings.jsonに次を入れます。
"effortLevel": "high"
これで、Sonnet 5を最初から「少し粘る」側に寄せられます。
ただし、CLAUDE.mdは長ければいいわけではありません。
理想は60行未満。多くても200から300行まで。各行に対して「これを消したらClaudeは間違えるか？」と問い、答えがNoなら消します。
コードから分かることは書かない。標準的な作法も書かない。リンターに任せられることはリンターに任せる。
書くべきなのは、推測できないコマンド、独自の作法、テストの回し方、落とし穴、アーキテクチャ上の判断です。
重要な指示は冒頭に置きます。「推奨」ではなく「必ず」「禁止」のように強い言葉で書きます。
CLAUDE.mdは、AIへのお願い文ではありません。チームの作業ルールです。
**
それでもFable 5を使うべき場面
ここまで読んで、「ではFable 5はいらないのか」と思うかもしれません。
違います。
Fable 5は必要です。ただし、使う場所を絞るべきです。
埋まる差は、正解を機械的に判定できる仕事です。
テストで判定できる実装修正。大量の分類、抽出、要約。人間レビューがどうせ最後に入る小さな変更。こういう仕事はSonnet 5と良いCLAUDE.mdでかなり戦えます。
埋まらない差は、主に3つです。
1つ目は、チェッカーが書けない仕事です。
この設計でいいのか。この移行計画に穴はないか。そもそも何を作るべきか。受け入れ条件を書くこと自体が仕事の核心なら、検証ループを先に回せません。
2つ目は、ルールの適用判断です。
「シンプルに保て」と書いても、何がシンプルかはモデルが判断します。「勝手に抽象化するな」と書いても、どこからが抽象化かは状況で変わります。
3つ目は、長時間の文脈保持です。
これは地力の差です。プロンプトで改善はできても、完全には消えません。
Fable 5本人が出した判断基準が、いちばん実務的でした。
受け入れテストを先に書けるならSonnet。受け入れテストを書くこと自体が難しいならFable。迷ったらSonnetで始めて、手戻りが2回続いた仕事だけFableに切り替える。
これでいいと思います。
最初から全部Fableに投げる必要はありません。逆に、何でもSonnetで済むと言うのも雑です。
安いSonnetで始める。構造で失敗を減らす。2回戻ったらFableに替える。
これが、7月8日以降の現実的な使い分けです。
**
今日やること
まず、プロジェクトのCLAUDE.mdに、この記事の7本を貼ってください。
次に、settings.jsonでeffortLevelをhighにします。
そのうえで、次の作業から「完了条件」「複数解釈」「検証報告」を必ず出させます。
長い仕事では、実装担当と検証担当を分けます。作った本人に採点させず、別コンテキストのClaudeに見せる。
そして、手戻りが2回続いた仕事だけFable 5へ切り替えます。
Fable 5の無料期間が終わっても、終わるのは無料の試食期間だけです。
本当に残すべきなのは、Fable 5の振る舞いです。
Sonnet 5をFable 5にする。
その第一歩は、長い魔法のプロンプトを毎回貼ることではありません。
CLAUDE.mdに、仕事の型を置くことです。
でも、ここまで読んで、こう思ったはずです。
「設定は分かった。でも、この格上げしたAIで結局、何を作って何で稼げばいいのか分からない」
逆です。安く賢くなったAIは、まず集客と発信の量産に回すべきです。Fable級の粘りをSonnetに焼き込めるなら、毎日の投稿、記事、導線、商品案、改善ループまで、低コストで回せます。
その具体的な中身は、固定ポストにまとめてあります。本気で「AIを安く賢く使って、集客と収益化までつなげたい」人は、ここからどうぞ↓
