Claude 7構成でテトリス実装——設計役（planner）も検証役（advisor）も崩れ、単体が勝った

こんにちは。外で遊べない日が続くと、部屋でブロックでも積みたくなりますね。今回は、同じテトリスを Claude に 7 通りの組み合わせで作らせて、出来とコストを比べた話です。

前回の LP 記事では、軍師（設計図だけを高いモデルに作らせ、実装は安いモデルに任せるやり方）が安く勝ちました。ところが、テトリスのような難しい課題のゲーム実装では、話がきれいに反転しました。軍師は万能ではなく、参謀（完成物を高いモデルにレビューさせて直させるやり方）も、難課題では結局コストが膨らみやすい。複雑なものを一発で作らせるなら、最上位モデル単体の信頼性プレミアムが割に合う場面があります。生成 AI でゲームや複雑な UI を作らせ、最終的な安定性まで見たい人には効く結論です。逆に、多少壊れても自分で直せる前提で、とにかく最安を取りたい人には過剰です。

前回と真逆に見えますが、言いたいのは「どちらが常に正しいか」ではなく、課題の難易度で最適な戦略が変わるということです。軍師は Claude Code の Plan モードに、参謀はレビュー依頼に近い使い方なので、前回を読んでいない方も手元の使い方に置き換えて読んでください。ここでの高いモデルは Fable です。

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

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

最初にお断りしておくと、これは何にでも当てはまる話ではありません。ブラウザゲーム（テトリス）を near 一発出しで作らせた、複雑課題1件の実測です。簡単なバグ修正ひとつで順位は入れ替わり得るので、「絶対の答え」ではなく判断の軸として読んでいただくのがちょうどいいと思います。

検証日は 2026-06-11 で、モデルは記事公開時点で使えた Claude 系、料金は 2026-06-11 時点の公開料金ページを参照しています。

条件は次の通りです。

• 同じテトリスを 7 構成で生成
• うち 2 構成は同じ設計図を共有（設計図は Fable が 1 回作成）。つまり、この2つの差は実装役のモデルの力だけ
• コストは出力単価ベースの上限概算。「出力トークン数 × 出力単価」で、設計図・実装・レビューの各出力を上限寄りに見積もったもので、厳密なトークン計測ではありません
• スコアは、客観チェックリスト 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点以上まとまって出ているなら、レビューを続けるより一発で作り直した方が安い可能性が高いです。

今回は、LLMLLM（大規模言語モデル）大量の文章で学習し、人のように文章を読み書きできる大きな AI のモデル。詳しく → が書くテトリスの「あるある」がはっきり出ました。複数ラインを同時に消すと盤面が壊れるバグです。

原因はシンプルで、消す行を降順に 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 タスクが並んでいるので、前回との差も手元で確かめられますし、各構成の生成物・差分・エラーログ・採点チェックリストもここからたどれます。こういう検証は、文章を読むより触った方が早いです。

前回の LP と今回を並べると、見え方はかなりはっきりします。易しい課題では軍師が安く勝ち、難しい課題では軍師が崩れて参謀も割高に寄る。課題の難易度で、最適なモデル戦略は反転する。この一点を持ち帰っていただければ十分です。

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