こんにちは、みのり（@minori_aimama）です。本業・育児の合間にAI×ブログ副業に挑戦中です。
今日は、Claude Codeで記事を書くときのモデルの使い分けを、A/Bテストで確かめた話を書きます。設計（構成やルール）は完全に固定して、本文を書くモデルだけをOpus 4.8とSonnet 5で入れ替える、という実験です。
結論から先に言うと、Opusが作った設計をSonnetに書かせる、という分担は成立しました。ただ、そこからOpus品質まで引き上げようとすると、執筆か清書にもOpus代を払うことになる。今回はそういうオチです🫠
きっかけは「記事が薄い」と言われたこと
始まりはAdSense対策でした。審査に向けてFable 5に相談したら、ブログ①の記事に「内容が薄い」と指摘されたんです。
思い返せば当時は、全記事をSonnet（当時のSonnet 4）に任せていました。しかも設計もせず、WEB検索だけでいきなり書かせていた。ラクではあったんですが、その分だけ中身も軽かったわけです。
ここで気になったのが、薄さの原因はどっちなんだ、ということ。「安いモデルだから」なのか、「設計せずに書かせているから」なのか。感覚では分けられないので、実際に切り分けてみることにしました。
ブログ①がAdSenseで苦戦している話は、このブログを始めた経緯の記事にも書いています。
薄さを「モデルのせい」で片づける前に、まず疑うべきは自分の渡し方だったのかもしれません。
試したかったのは「Opus品質を、Sonnetで再現できるか」
先に言っておくと、これはリライト術の話ではありません。Opusで出せる品質を、安いSonnetの作業でどこまで再現できるか、というモデル使い分けの話です。
なぜそこが知りたかったかというと、量産に直結するからです。もし品質差が小さいなら、コストの安いSonnetに任せて記事を数多く出せる。逆に差が大きいなら、大事な記事はOpusで書くしかない。
たまたま今回の作業対象が「薄い記事の見直し」だっただけで、本題は「どの作業に、どのモデルを当てるか」でした。
やり方｜設計は固定して、書くモデルだけ入れ替えた
比較の肝は、条件をそろえることです。
そこで記事の設計を1パッケージにまとめて、完全に固定しました。具体的にはこんな中身です。
- 構成（見出しと各セクションで書くこと）
- 狙うキーワード
- 使ってよい公式データ
- 元記事の「残す/直す」の指示
この設計は、判断役のメイン（Opus）が1つ作って動かさない。そのうえで、本文を書くモデルだけをOpus 4.8とSonnet 5に差し替える。こうすれば、出てくる品質の差を「執筆モデルの差」として比べやすくなります。
私はふだんClaude CodeとObsidianで記事を作っていて、この「設計する人」と「書く人」を分ける発想も、その環境があってこそでした。
比べたいのは「モデルの地力」なので、入力条件はできるだけそろえる。これだけで結果がぐっと読みやすくなりました。
ラウンド1｜Sonnet 5は、想像よりずっと優秀だった
まずは直書き対決から。同じ設計を渡して、Sonnet 5とOpus 4.8に2本のドラフトを並列で書かせました。
驚いたのはSonnet 5です。構成もルール遵守も、想像よりずっと安定していました。とくに感心したのが、内部リンク先が本当に存在するかを自分で調べに行く勤勉さ。「そこまでやるんだ」と思いました。
コストはこんな感じです。ここでの「コスト」は、消費トークン量と、それが定額プランの枠をどれだけ食うかで見ています。とくにPro契約だと枠を使い切るのが早いので、ここは切実です。
| 執筆モデル | 消費トークン | 枠の減りやすさ |
|---|---|---|
| Sonnet 5 | 63.5k | 軽い |
| Opus 4.8 | 51.7k | 重い |
おもしろいのは、トークン数だけ見るとOpusの方が少ないのに、私の環境では利用枠の減りがOpusの方が早かったこと。同じくらいの作業を任せても、SonnetよりOpusの方が枠を重く消費します。
「安いモデルだから薄い」という思い込みは、ここで一回崩れました。
でも、Opus品質まで求めると差が出た
じゃあ全部Sonnetでいいかというと、そうはならなかった。
本文の深さと声だけは、Opus 4.8が明確に一段上でした。反証を添えた整理や、独自の言い回し。「わかってる人が書いた文章」の質感は、Opusのドラフトにしかありませんでした。
同じ設計を渡しても、ここは埋まらない。つまり評価は、どの品質ラインを求めるかで変わるということです。実用ラインならSonnet、Opus品質を狙うならOpus。線をどこに引くかで、答えが変わりました。
「優秀かどうか」ではなく「どこまでを求めるか」。モデル比較は、その一言に尽きるのかもしれません。
「Sonnet下書き→Opus清書」は、品質は上がるけど節約じゃなかった
ここからが今回の本題です。
こう考える人は多いはずです。「安いSonnetで下書きして、高いOpusで清書すれば、いいとこ取りで安く済むんじゃないの？」。私もそう思って、ラウンド2で検証しました。
品質は、たしかに2段方式の勝ちでした。清書役のOpusは、指示した4作業（根拠の掘り下げ・声の付与・誤字修正・AI臭除去）だけを正確にやって、構成も数値も崩さない。仕上がりは文句なしです。
問題はコストでした。
| 方式 | 消費トークン | 内訳 |
|---|---|---|
| Opus直書き | 50k | Opusのみ |
| Sonnet下書き→Opus清書 | 113k | Sonnet 65k＋Opus清書 48k |
直書き50kに対して、2段方式は113k。倍以上です。しかも決定打は、Opusの清書（48k）が、Opusの直書き（50k）とほぼ同じだけ食っていたこと。
節約になっていない、どころか丸ごと高くついていました。
清書は「軽い直し」じゃなく、もう一度判断し直す工程だった
なぜ清書がこんなに重いのか。理由はやってみて腑に落ちました。
清書というと、誤字を直して整える軽作業のイメージがあります。でも実際は違った。根拠は足りているか、声は乗っているか、AI臭は残っていないか、構成は崩れていないか——ぜんぶをもう一度判断し直す工程だったんです。
そのためには、Opusに下書きをほぼ全文読ませることになる。だから直書きと同じくらいトークンを食う。品質が上がったのは、記事に二工程かけて後段のOpusに全文を判断し直させた対価であって、安上がりの裏技ではなかったわけです。
「下書きは安いモデル」という直感は、清書の重さを見落としていたわけです。
運用事故｜AIが勝手にAIを呼んで、利用枠を溶かした
このラウンド2では、想定外の事故も起きました。
下書き担当のSonnetが、勝手に自分のコピーを起動して、その完了を待ちに入ったんです。委任した相手が、さらに別の自分へ委任する。そんなモードがあるとは思っていませんでした。
しかも待ちに入ったまま空応答で69k、起動された「孫」の方は完走して63k。本来は不要だった処理に合わせて130k以上を使い、採用できる成果は残りませんでした🫠
対処はシンプルで、エージェントの定義に「追加のサブエージェントを起動しない」と明記しただけ。ただ、定額プランの枠で動かしている人ほど、この手の空費は地味に痛いはずです。暴走の芽を塞ぐのも運用のうちなんだなと痛感しました。
AIに任せるほど、任せた先が何をするかまで見張る必要が出てくる。エラーも事故も、こうして記事の資産になります。
そもそもの「薄さ」は、設計を入れたSonnet 5ではほぼ消えた
ここで最初の問いに戻ります。薄さの原因は、モデルだったのか設計だったのか。
答えは、設計の影響がかなり大きい、でした。設計を固定しただけで、当初の「薄い」はほぼ解消されて、Fable 5からも「深さが出ている」と評価が変わったんです。
薄さの主因は、使っていたモデルではなく「設計もせずWEB検索でいきなり書かせていたこと」だった。モデル選び（Opus 4.8かSonnet 5か）は、その土台の上での“最後の一押し”という位置づけに変わりました。
まず土台。モデルの良し悪しは、その次の話だったんだなと思います。
結論｜使い分けは「安さ」でなく「求める品質ライン」で決める
2ラウンド回して、運用はこう固まりました。どれも設計を作るのはOpusで、変えるのは「本文を誰に書かせるか」だけです。
- 最重要の記事（審査・上位表示を狙う）＝Opus設計→Opus執筆
- 量産・ロングテール＝Opus設計→Sonnet執筆→人が最終確認
- 2段方式（Sonnet下書き→Opus清書）＝ここぞの1本だけ
いまはまだAdSense未通過なので、本命の記事をOpus執筆で厚めに書くフェーズです。無事に通過して量産に入ったら、軽い作業から執筆をSonnetへ広げていく予定です。
順番はいつも同じです。まず設計で実用ラインまで引き上げる。そのうえで、最後の深さや文章の声をどこまで求めるかで、執筆モデルを選ぶ。安さだけで選ぶと、今回みたいに後工程でかえって高くつきます。
まとめ
今回わかったことを一言でまとめると、こうです。
安いモデルに「作業」は任せられます。Opusに設計させてSonnetに書かせても、実用ラインには届きました。でも、Opusらしい深さや文章の声まで求めるなら、執筆か清書にもOpusを置くことになる。しかも、後から清書させるより、最初からOpusに書かせた方が安く済みました。
そしてもうひとつ。モデルの優劣は、一般論で比べても答えが出ません。自分の作業で、条件をそろえて、数字で測る。そうして初めて「清書は節約にならない」「AIが勝手にAIを呼ぶ」みたいな、直感に反する発見に出会えました。
もちろん今回は同じ設計を使った小規模な比較なので、すべての記事で同じ結果になるとは限りません。それでも、自分の用途で1回試すだけで、思い込みはだいぶ整理できます。
気になっている使い分けがあれば、まず自分の用途で1回A/Bしてみるのがおすすめです。引き続き、いろいろ実測していきます🫠
