Claude Opus・Sonnet・Haikuの使い分け：ゲーム制作の工程ごとに

三つのモデルが異なる理由を工程に結びつける

Opus・Sonnet・Haiku の差は「賢さ」の一語では語れません。より正確には、長い文脈を保ちながら複数の制約を同時に考慮する能力の差です。

ゲーム制作に置き換えると、「ステージ設計の難易度カーブ全体を見渡しながらプレイヤー心理も考慮する」という問いは複数制約を扱う典型例です。一方、「このスプライトが画面端で止まらない原因を見つける」という問いは文脈が限定されており、高度な推論よりも速い応答回数のほうが役立ちます。

判断の基本軸は次の二点です。

• 判断の重さ：この出力がゲームの方向性や構造に影響するか
• 繰り返し回数：同種の問いを一度の制作で何十回も投げるか

重くて一度きりの問いには Opus を、軽くて繰り返す問いには Haiku を、その中間には Sonnet を当てるというのが出発点になります。

企画・設計フェーズ：Opus が最も効く場面

ゲームの根幹を決める工程、たとえばコアループの設計・世界観の整合性確認・難易度曲線の設計・プレイヤーが離脱しやすい構造の洗い出しには、Opus が向いています。

理由は一つです。これらの問いは「矛盾のない全体像を保ちながら、多くの仮定を同時に検討する」作業だからです。「プレイヤーが3分以内に達成感を得られるチュートリアルを、操作説明を最小限にしながら設計したい。ただしモバイルタップ操作を前提にする」という複合制約を持つ問いは、Sonnet や Haiku だと条件の一部を取りこぼした回答が返ることがあります。

Opus を使うときの具体的な投げ方のコツとして、「前提条件・制約・期待するアウトプットの形式」を一度のプロンプトにまとめることをおすすめします。何度も往復して補足する時間コストが、モデルのコストより高くつくことが多いためです。

設計フェーズで Opus を使うもう一つの場面は、既存のゲームデザインの批評を依頼するときです。「このゲームの難易度曲線に問題はないか」という問いに対して、Haiku は表面的な指摘にとどまりやすく、Sonnet も制約が多い設計では見落としが生じます。Opus は矛盾の発見や、プレイヤー体験として読み解く観点の質が上がります。

コーディングフェーズ：Sonnet を中心に、役割で切り替える

HTML と JavaScript でブラウザゲームを書く工程では、Sonnet がコストと品質のバランスが取れた選択肢になることが多いです。

Sonnet が向く作業の例を挙げます。

• ゲームループ・衝突判定・スコア計算などのロジックの初稿生成
• Canvas API や Web Audio API を使った中程度の複雑さの実装
• 自分が書いたコードのリファクタリング提案
• バグ報告を伴う「このコードが動かない理由を教えて」という問い

一方、コードの断片を大量に繰り返し生成する場面では Haiku が速度と費用の両面で優ります。具体的には、「敵キャラクター20種類のパラメータオブジェクトをこの形式で書いて」「メニュー画面の HTML テンプレートを3パターン作って」といった、フォーマットが固定されていて量をこなす作業です。Haiku は一回の応答品質よりも「すぐ返ってくる・多く試せる」という点で使います。

Opus をコーディングに使う必要があるのは、アーキテクチャ全体の設計レビューや、複数ファイルにまたがる設計上の問題を洗い出す場面に限定するとよいでしょう。1関数・1機能の問いに Opus を使うのは、性能の過剰投入になりがちです。

失敗しやすいパターン

「Haiku に複雑なロジックを書かせて、うまくいかないので Opus に同じ問いを投げ直す」という使い方は、最初から Sonnet を使う場合より時間もコストもかかります。問いの複雑さを先に見積もってモデルを選ぶほうが、往復のロスが少なくなります。

ゲームデータ・テキスト生成：Haiku が本領を発揮する

ゲームに登場するテキストデータ—アイテム名、NPC のセリフ、ステージの説明文、チュートリアルのヒントメッセージ—は、量が多くなるほど Haiku の強みが出ます。

一つひとつの文章に高度な創造性は必要なく、「このゲームの世界観に合う短い文章を素早く大量に出してほしい」という需要です。Haiku は応答が速いため、「少し違う」と感じたらすぐ再生成する試行錯誤のサイクルを回しやすいです。

Haiku に渡すときは世界観・トーン・文字数制限を簡潔に書いたシステムプロンプトを用意しておくと、出力のブレが小さくなります。例として、「和風ファンタジーの世界。敵キャラクターの説明文。20字以内。武器・弱点・出現場所を含める」という指示をシステムプロンプトに入れると、毎回の個別プロンプトを短くできます。

効果音や BGM のパラメータ案出し、カラーパレット候補のリストアップなど、「ひな形に沿って選択肢を多く出す」場面も Haiku に向いています。

デバッグ・仕上げフェーズ：問いの性質で都度判断する

デバッグはバグの複雑さによってモデルを選びます。

Haiku で十分な問いの例：構文エラー、タイポ、変数名の誤り、単純な条件分岐の確認。これらはエラーメッセージとコードを貼るだけで正確な回答が返ります。

Sonnet が向く問いの例：ゲームループ内で特定条件のときだけ起きるバグ、イベントリスナーの重複など、複数の状態を追う必要があるもの。

Opus を使う価値がある問いの例：「このゲーム全体のパフォーマンスがモバイルで低い原因を、設計レベルから見直してほしい」という構造的な診断。一つのバグではなく、複数の問題が絡み合っている可能性があると感じるときです。

リリース直前の最終確認として、Opus にゲームの仕様書とコードの概要を渡し「見落としやすい品質問題・アクセシビリティの課題・プレイヤーが詰まりやすい箇所の仮説を挙げてほしい」と依頼するのも有効な使い方です。一回の問いで価値のある指摘が返ってきやすい場面のため、Opus のコストに見合います。

工程別モデル選択のまとめ表

• コアループ・難易度設計、推奨モデル：Opus、理由：複合制約の同時処理が必要
• 世界観・設計のレビュー、推奨モデル：Opus、理由：矛盾発見・多角的な批評
• ロジック・機能の実装、推奨モデル：Sonnet、理由：コストと品質のバランス
• リファクタリング・バグ特定、推奨モデル：Sonnet、理由：中程度の文脈、繰り返し多め
• テキスト・データの大量生成、推奨モデル：Haiku、理由：速度と試行回数が優先
• 構文エラー・単純確認、推奨モデル：Haiku、理由：文脈が短く応答速度が効く
• 全体的な構造診断、推奨モデル：Opus、理由：広い文脈を一度に処理する場面

この表はあくまで出発点です。同じ「バグ修正」でも自分のプロジェクトの規模や状況によって最適解は変わるため、数回試して体感をつかんでおくことをおすすめします。

次の行動

まず手元の制作プロジェクトの工程を書き出し、「今日使った問いが重い判断か繰り返し作業か」を仕分けてみてください。その仕分けをもとに、次のセッションから一つの工程だけモデルを変えて試してみると、違いが実感しやすくなります。ブラウザゲームが完成したら、アソバースへの投稿も検討してみてください。

参考資料

• Anthropic 公式ドキュメント（モデル比較・料金・API 仕様）