Claude 7構成にLPを作らせて比較：軍師（設計）が参謀（レビュー）に半額で勝った

生成AIで成果物を作らせるなら、高いモデルは「完成物のレビュー役」より「作る前の設計役」で使った方が得でした。今回の比較では、同じLPを7構成で作らせたところ、軍師＝事前設計のほうが、参謀＝事後レビューより半額以下で同等以上の結果**になりました。

ここでいう「軍師」「参謀」は、私の中だけの呼び分けです。読者の手元ではこう置き換えると分かりやすいです。

• 軍師＝作らせる前に高モデルに設計図だけ作らせる使い方。Claude Code の Planモード（plan-first） に近いです。
• 参謀＝完成物を高モデルにレビューさせて直させる使い方。advisor 的な事後レビューに近いです。

つまり、これは「高モデルをどこで使うと効くか」の話です。高モデルを使うな、ではありません。使う場所を間違えると高くつく、という検証です。

• 今回の検証条件
• 7構成のコスト比較
• 参謀が高くついた理由
• 軍師が効いた理由
• 人間の目で見た総合評価
• この結果が効く場面
• 向いている人・向いていない人
  • 向いている人
  • 向いていない人
• 限界と、次に見るべきこと
• 関連記事
• この記事を書いた人

今回作らせたのは、架空SaaS「FocusFlow」の集中タイマーLPです。しかも、一発出しです。ここは足元を見ておきます。難しい実案件ではなく、まずは易課題1件として見てください。

検証の見方は3つです。

1. コスト
2. 客観スコア
3. 人間の実機評価

コストは、出力単価ベースの上限概算です。厳密なトークン実測は取れていません。単価の正本は lib/creation-cost.ts の PRICING_PER_MTOK を使っています。

客観スコアは、7構成すべてで renders OK・console_errors 0・チェックリスト10/10。つまり、機械的な合否では差がつきませんでした。差が出たのは、見た目の完成度・タイポ・情報量という主観領域です。

人間評価は、私が7本のLP実物を見比べて判断しました。机上の理屈だけではなく、実際に触ってどうだったかを優先しています。

まず数字です。

この表だけ見ると、まず違和感が出ます。高モデルをレビュー役に回した構成が、単体より高いのです。

特に分かりやすいのがこれです。

• fable単体 $4.76
• haiku参謀 $5.13

参謀版は、高モデルを完成物の批評に使うぶん、生成と同等の推論コストが乗るので、単体より割高になりました。期待したくなる気持ちは分かりますが、ここは直感が外れました。

一方で軍師は逆です。

• haiku軍師 $2.41
• sonnet軍師 $2.99

参謀版の半額以下です。しかも、後述しますが、品質が大きく落ちたわけでもありません。

参謀は、完成物を見てから直す役です。言い換えると、**高モデルに「作品を読ませて、評価させて、修正方針まで考えさせる」**わけです。

これ、軽そうに見えて重いです。

なぜなら、レビューはただ眺めるだけでは終わらないからです。LPなら、少なくとも次を見ます。

• 情報の抜け
• 文章の順序
• 導線の破綻
• 余白や視線誘導
• コピーの弱さ
• タイポや違和感

つまり、生成したものをもう一度、頭から組み直すのに近い。そりゃ高くなります。

今回の結果で面白いのは、高いモデルをレビュー役に置いたら品質が上がるはずという直感を、コスト面で裏切ったことです。しかも品質も、少なくともこのタスクでは、そこまで伸びませんでした。

軍師は、完成物ではなく設計図を作ります。

ここが大きいです。設計図は、実装より軽い。だから高モデルを使っても、使うトークンの総量が少なくて済む。

今回の構成では、Fableが1回作った設計図を haiku軍師 と sonnet軍師 が共有しています。つまり、差は設計図ではなく、executor の実装力だけです。かなり綺麗な対照実験になりました。

結果として、軍師構成はこうなりました。

• haiku軍師 $2.41
• sonnet軍師 $2.99

しかも、客観スコアは他と同じく満点です。ここで一度、足元を見ておきます。機械評価が全部満点なら、最後に効いてくるのは、見た目と情報量の差です。今回のタスクでは、設計が良いほどその差が詰まりやすいことが見えました。

特に、sonnet軍師は総合最良でした。運営者としての実機評価では、sonnet-planner が一番バランスが良い。実際に回してみると、この組み合わせがいちばん扱いやすく感じました。高モデルで先に設計させ、その設計を安定した実装側に流すと、変な迷いが減る。LPのような構成物では、この効き方がかなり素直でした。

私の見た目評価では、こうです。

• Fable単体：見た目・タイポ・ボリュームで最良。ただし僅差
• Sonnet 4.6単体以上：どれも実用十分
• 軍師2構成：どちらも良いが、sonnet-planner が総合最良

最高峰モデルの出力は、たしかに強いです。ただ、最高峰だから最後まで単体で走らせるべき、とは限らないのが今回の結論です。

現場目線でいうと、LPのような成果物は「全部を高モデルにやらせる」より、

1. 高モデルで設計を固める
2. 実装は安定した安いモデルに任せる
3. 必要なら軽いレビューだけ足す

この流れのほうが扱いやすいです。

実際に触ると、この差は地味に効きます。完成物の質が劇的に跳ねるというより、迷いと手戻りが減る。その減り方が、実務では意外と大きいです。

今回の結果がそのまま効くのは、次のようなケースです。

• LP、紹介ページ、簡易な営業資料のように、構成が先に決まる成果物
• まず1本作って、そこから微修正するより、最初の骨格が大事なケース
• 生成AIに「とりあえず1本作って」と頼みがちな人
• 高モデルを使いたいが、どこに置くと費用対効果が出るか迷っている人

逆に、全部をこの結果で一般化するのは危険です。難しい仕様、長い反復改善、複雑な依存関係がある仕事では、参謀の価値が出る可能性があります。

今回の結論は、あくまでFocusFlow の集中タイマーLPを一発出しさせた易課題1件に限ります。

向いている人

• Claude / Codex / Gemini を日常的に使っていて、モデル費用のムダを減らしたい人
• vibe coding で成果物を作るとき、高モデルの置きどころを探している人
• 「レビューに高モデルを使えば安心」と思っているが、本当に得か疑っている人
• 実務で、まずは設計を固めてから実装する癖がある人

向いていない人

• 1回で完璧な答えを求める人
• すべてのタスクに同じ最適解があると思っている人
• CLIや生成AIの工程分割に興味がない人

非エンジニアでCLI操作に抵抗がある人向け、というより、今回は生成AIの役割分担をどう切るかを考える人向けです。CLIに慣れている人には、むしろ説明不要な部分もあるでしょう。

この検証には限界があります。

• 易課題1件だけです
• 一発出しです
• LPという、比較的構成が見えやすい成果物です
• 厳密なトークン実測ではなく、出力単価ベースの上限概算です

なので、結論はこう置くのが安全です。

高いモデルは、完成物レビューより事前設計で使え。少なくとも LP の一発出しでは、軍師が参謀に半額以下で勝った。

ただし、これをそのまま全タスクに広げないでください。次にやるべきことは単純で、反復改善が必要な仕事、仕様が曖昧な仕事、コード依存が強い仕事で同じ比較をやることです。

その続編として、より難しい「ブラウザで動くテトリスを作らせる」課題で同じ7構成を比較しました。結論は今回と反転し、難課題では軍師も参謀も崩れて、最上位モデル単体（Fable）の信頼性が割に合うという対照的な結果になっています。

BlogClaudeの軍師（設計）は万能じゃない——難課題のゲームでは参謀も崩れ、単体の信頼性が勝った（7構成コスト比較）難しいテトリス実装で7構成を比較。軍師が崩れ、参謀も割高に収束。最上位モデル単体の信頼性が効く条件を実測で整理します。→

最後に、読者が自分の現場へ持ち帰るなら判断軸はこれです。

• 高モデルは設計に使うか、レビューに使うか
• その工程は本当に高モデルが必要か
• レビューで増えるコストに見合うだけ、品質差があるか

私なら、まずはこうします。

• 設計が大事な仕事 → 高モデルを軍師に回す
• 実装が定型的な仕事 → 安いモデルに任せる
• 最後の確認だけ欲しい仕事 → 軽いレビューを足す

今回の検証では、少なくともこの順番がいちばん筋が通っていました。

LP実物は、/llm-test/creations の比較ページで7本すべて見られます。数字だけではなく、実際の見た目も見てから判断した方がいいです。こういう比較は、表だけ見て分かった気になると外します。

• BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→
• BlogClaude Code の /effort 完全ガイド｜low〜maxの使い分けと『コストが増える本当の理由』Claude Code の /effort（low〜max・ultracode・auto）は「賢さ」ではなく「トークンの気前よさ」のレバー。モデル別の推奨スタートと、Opus 4.8 でコストが増えた気がする原因を『トークナイザ』と『effort』の2軸に切り分ける考え方を、公式一次情報と v2.1.156 の実機確認で解説します。→
• BlogClaude Opus 4.8 は何が変わった？ベンチより「正直さ」と並列エージェントが本命だったClaude Opus 4.8 で本当に変わったのは、ベンチの数ポイントではなく『正直さ』と並列サブエージェントでした。公式ベンチ、4つの新機能、OpenRouter の実トラフィックを重ねて、価格据え置きの今回のアップデートを乗り換え目線で整理します。→

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！