Claudeの軍師（設計）は万能じゃない——難課題のゲームでは参謀も崩れ、単体の信頼性が勝った（7構成コスト比較）

関連記事としては BlogAnthropicリーク2連発：Claude MythosとClaude Code流出で見えたKAIROS、BUDDY、Undercover Modeの正体Anthropicの2週間で2回のリークを整理。Claude Mythosの位置づけ、Claude Code流出の中身、KAIROS/BUDDY/Undercover Modeの意味を分けて読む。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

前回のLP記事では、軍師（設計図を高モデルに作らせて実装は安いモデル）が安く勝ちました。ところが今回のような難しい課題のゲーム実装では、話がきれいに反転します。

verdict

• 効く人: 生成AIでゲームや複雑なUIを作らせ、最終的な安定性まで見たい人
• 過剰な人: 多少壊れても自分で直せる前提で、とにかく最安を取りたい人

結論はこうです。

• 軍師は万能ではありません
• 参謀（完成物の事後レビュー）も、難課題では結局コストが膨らみやすいです
• 複雑なものを一発で作らせるなら、最上位モデル単体の信頼性プレミアムが割に合う場面があります

はい、これは前回と真逆に見えます。ただし、ここで大事なのは「どっちが常に正しいか」ではなく、課題の難易度で最適戦略が変わることです。

まず用語を置き換えます。ここでいう軍師は、Claude Code の Plan モードに近い使い方です。つまり、高モデル（ここでは Fable）に作る前の設計図だけ作らせ、実装は安いモデルに任せるやり方です。参謀は逆で、完成物を高モデルにレビューさせて直させる事後レビュー型です。前回記事を読んでいない方でも、手元の Plan モード／レビュー依頼にそのまま置き換えて読めるようにしています。

今回の比較対象は、同じテトリスを 7 構成で作らせた実測です。読者が知りたいのは「どっちが上か」より、自分の用途ならどの組み合わせが割に合うかだと思います。そこに絞って書きます。

BlogClaude 7構成にLPを作らせて比較：軍師（設計）が参謀（レビュー）に半額で勝ったClaudeの高モデルは完成物レビューより事前設計に回した方が安く強い。7構成で同一LPを比較し、実コストと使用感から判断材料を整理しました。→

• 今回の比較条件
• 7構成のコストとスコア
• 軍師は難課題で崩れた
  • ⚠️危険ポイントと戻し方
• 参謀は直すが、安くはならなかった
  • ⚠️危険ポイントと戻し方
• 技術的な山場は同型バグでした
  • ⚠️危険ポイントと戻し方
• 最上位モデル単体が勝った理由
  • ⚠️危険ポイントと戻し方
• この結果をどう使うか
  • こういうときは軍師が向きます
  • こういうときは参謀が向きます
  • こういうときは最上位モデル単体が向きます
• 誰に向くか、誰には不要か
  • 向く人
  • 不要な人
• まとめ
• この記事を書いた人
• 関連記事

ここで一度、足元を見ておきます。今回の結果は、何でもかんでも一般化できる話ではありません。ブラウザゲーム（テトリス）を near 一発出しで作らせた、複雑課題1件の実測です。

検証時点

• 検証日: 2026-06-11
• 利用モデルの時点: 記事公開時点で利用可能だった Claude 系モデル
• 料金表の参照時点: 2026-06-11 時点の公開料金ページ

比較条件は次の通りです。

• 同じテトリスを 7 構成で生成

• うち 2 構成は同じ設計図を共有

  • その設計図は Fable が 1 回作成
  • つまり、軍師側の差は「実装役のモデル力」の違いだけ

• コストは出力単価ベースの上限概算

  • 概算式は「出力トークン数 × 出力単価」で算出
  • 実測の厳密トークン計測ではなく、設計図・実装・レビューの各出力を上限寄りで見積もったものです

• 客観スコアは次で評価

  • 客観チェックリスト 10 項目
  • renders（描画成功）
  • console_errors（JS エラー数）

• チェックリストは 7 構成の静的ソーストレースと、運営者のプレイ判定で確定

• 各構成の生成物、差分、エラーログ、採点チェックリストは本文末の /llm-test/creations から追えるようにしてあります

補足すると、今回の設計図はかなり丁寧でした。canvas を 2 枚に分け、盤面と現在ピースを分離し、回転は純粋関数で仮判定し、壁蹴りは [0,+1,-1,+2,-2]、行消去は抜き式で、という指示まで入っています。ところが、それでも崩れる構成は崩れました。ここが今回の肝です。

まず数字です。今回の 7 構成は、上限概算ではこうなりました。

この表だけ見ると、少し混乱するかもしれません。安い構成がそのまま悪い、という話ではありません。実際、Haiku 単体は最安ですし、Haiku 軍師は遊べる水準でした。

ただ、難しい課題では「あと少し」が地味に重いです。遊べるかどうか、再起動できるかどうか、盤面が描画されるかどうか。こうした基本動作の有無が、コスト差よりはるかに強く効く場面があります。

前回のLPでは、軍師は強かったです。設計図を上位モデルに作らせて、実装は安いモデルに流す。簡単な課題では、これがかなり効きました。

でも今回のテトリスでは、「軍師なら安泰」という前提が崩れました。

特に対照的だったのは、同じ設計図を共有した 2 つの軍師構成です。

• Haiku 軍師：遊べるところまでは行った
• Sonnet 軍師：盤面が一切描画されない破綻に落ちた

これは驚きの結果でした。しかも、設計図はどちらも同じです。つまり、設計の良し悪しだけでは守り切れないということです。

Sonnet 軍師の破綻は、かなり厄介でした。requestAnimationFrame を読込直後に呼んでしまい、空配列の board を前提に drawBoard が例外を連発します。見た目は「何か動いている」ように見えて、実際は盤面が描画されず、スコアだけ増える。こういうのは現場で触ると、じわじわ嫌です。

ここで言いたいのは、設計図を渡したからといって、実装が安定するとは限らないことです。難課題では、実装役のモデルのクセや破綻耐性がそのまま出ます。

⚠️危険ポイントと戻し方

• 危険ポイント: 設計図を共有しても、実装モデルが違えば破綻の仕方は変わる
• 戻し方: 盤面が描画されない、スコアだけ進む、初手で固まる場合は、まず requestAnimationFrame の起動位置と drawBoard の前提配列を疑う。board が空のタイミングで描画ループが回っていないかをログで確認し、起動を初期化完了後に戻す

参謀はどうだったか。結論だけ言うと、直せます。ただし、安くはなりません。

Sonnet 参謀は、完成物をレビューさせて複数の致命点を直しました。

• 複数同時消しの盤面破損
• リスタートまわりの不具合
• そのほか致命3点を含む修正

結果として、かなり「正しく直った」仕上がりにはなりました。ですが、コストは $3.77 で、Fable 単体の $3.69 とほぼ同等です。

ここは重要です。

• 安いモデル＋高い参謀 は、難課題では結局高くつきやすい
• 「後で直せばいい」は、ゲームのような状態遷移が多い課題では甘くなりやすい
• 直せることと、安く済むことは別問題です

つまり、参謀は役に立ちます。ですが、「最後に高モデルで締めるなら、そのまま高モデル単体で作らせてもよくないか？」という問いが残ります。今回、その問いにかなり強く YES が出ました。

⚠️危険ポイントと戻し方

• 危険ポイント: 参謀は「直す」ことに強いが、修正回数が増えると単体利用より高くつく
• 戻し方: 盤面破損や再スタート不具合が出たら、差分を積み増す前に「修正対象が何個あるか」を数える。3点以上の致命バグがまとまって出ているなら、レビュー継続より一発作り直しの方が安い可能性が高い

今回、LLM が書くテトリスの“あるある”がはっきり出ました。複数ライン同時消しで盤面が壊れるバグです。

正体はシンプルで、消去行を降順に splice してインデックスがずれることです。これを、Haiku 単体・Haiku 軍師・Sonnet 単体の初期版が共通して踏みました。

見た目は完成しているのに、2 行以上同時に消すと露見します。しかも、ゲームとして遊んでいるだけだと気づきにくい。ここが厄介です。

修正は、降順 splice をやめて、消えない行だけを残す filter 方式にすることです。要するに、

• 消す行を無理に配列から抜く
• ではなく、生き残る行を上から詰め直す

この方が安全です。

なお、運営者が「回転すると別ブロックに化ける」と体感した点については、ここで誤解を避けておきます。真の型化けではありません。正体は、

• 複数同時消しによる盤面破損
• I ピース回転時の位置ズレ
• ライン消去フラッシュの描画タイミングずれ

この副作用でした。回転ロジック自体は、7 構成すべてで型と色を保持していました。なので、「回転で型が化けた」と断定するのは誤りです。

こういう細部は、見た目だけ追うと簡単に取り違えます。実際に触って、ログと画面の両方を見るのが大事です。

⚠️危険ポイントと戻し方

• 危険ポイント: 2 行以上同時消去で、配列インデックスのずれが出やすい
• 戻し方: splice で順に抜く実装をやめ、filter で生存行だけを再構成する。戻すときは、2 行・3 行同時消去のケースを手動で再実行して、盤面下端の形が崩れていないかを確認する

全 7 構成で、重大バグが一つも無かったのは Fable 単体だけでした。

内容も、ただ無難だったわけではありません。

• SRS 壁蹴り
• ホールド
• NEXT 3 個
• ゴースト
• WebAudio の効果音
• 画面シェイク

このあたりまで含めて、運営者の評価では文句なしの最良でした。私は 40 代の現役エンジニアですが、こういう時は変に持ち上げず、まず「本当に壊れていないか」を見ます。その目線で見ても、Fable 単体が一番安定していました。

なぜこうなるのか。今回の答えはわりと素直です。

• 複雑な課題では、実装の段数が増えるほど壊れやすい
• 軍師は実装役を安くできるが、品質保証まではしてくれない
• 参謀は直せるが、直すコストが積み上がる
• ならば、最初から最上位モデルに一発で作らせる方が、信頼性プレミアム込みで割に合う場面がある

これは前回のLPとは対照的です。前回は「簡単な課題なら軍師が勝つ」でした。今回は「難しい課題ほど、軍師が崩れて最上位単体が勝つ」です。

⚠️危険ポイントと戻し方

• 危険ポイント: 「高いモデルなら全部解ける」と決めつけると、検証対象の難易度を見誤る
• 戻し方: 画面・ログ・再起動・同時消去の 4 点が通ったら初めて合格とする。1 つでも不安が残るなら、モデル戦略ではなく仕様の切り分けからやり直す

ここが一番大事です。読者が次にどう判断すべきかです。

こういうときは軍師が向きます

• 課題が比較的単純
• 多少の修正が前提
• 実装の失敗コストが低い
• 設計と実装を分けたい

この場合、Plan モード型の軍師はかなり強いです。前回のLPはまさにこちらでした。

こういうときは参謀が向きます

• まず動くものを作り、その後で締めたい
• バグの洗い出しを高モデルに任せたい
• 「直す」フェーズに価値がある

ただし、今回のように状態遷移が多くて壊れ方が複雑な課題だと、参謀コストは思ったほど下がりません。

こういうときは最上位モデル単体が向きます

• 一発で壊れてほしくない
• ゲームや UI など、見た目と状態管理の両方が重要
• 手戻りより、最初の信頼性を取りたい

ここで一度、足元を見ておきます。**「高いから無理」ではなく、「高いけど、壊れない確率に払うか」**です。複雑課題では、その差が後から効きます。

向く人

• 生成 AI で動くゲームや複雑なコードを作らせたいエンジニア
• Claude Code の Plan モードやレビュー依頼を、用途に応じて使い分けたい人
• 「安く作る」より「結局いくらで安定するか」を見たい人
• 実際に触って、壊れ方まで判断材料にしたい人

不要な人

• そもそも複雑な実装を AI に任せない人
• 多少壊れても自分で全部手直しする前提の人
• コスト比較より、単純な面白さだけを求める人

最後に、今回の実物は /llm-test/creations で遊べます。LP とテトリスの 2 タスクが並んでいるので、今回の記事だけでなく、前回との差も手元で確かめられます。各構成の生成物、差分、エラーログ、採点チェックリストへの導線もここから追えます。こういう検証は、文章だけ読むより、実際に触った方が早いです。

今回の比較で見えたのは、軍師は万能ではないという当たり前だけど大事な事実でした。

• 易課題では、軍師が安く勝つ
• 難課題では、軍師が崩れ、参謀も割高に寄る
• 複雑なゲーム実装では、最上位モデル単体の信頼性が割に合う場面がある

ただし、これはブラウザゲーム 1 件の near 一発出しです。簡単なバグ修正で順位は入れ替わり得ます。だからこそ、今回の結果は「絶対論」ではなく、判断軸として使うのがちょうどいいです。

前回のLPと今回を並べて読むと、見え方はかなりはっきりします。課題の難易度で、最適なモデル戦略は反転する。この一点を持ち帰ってもらえれば十分です。

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

• BlogAnthropicリーク2連発：Claude MythosとClaude Code流出で見えたKAIROS、BUDDY、Undercover Modeの正体Anthropicの2週間で2回のリークを整理。Claude Mythosの位置づけ、Claude Code流出の中身、KAIROS/BUDDY/Undercover Modeの意味を分けて読む。→
• 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 の実機確認で解説します。→