AI に『クラッシュ・ロワイヤル』のデッキを1つ推薦させることは難しくありません。本当に価値のある問題は、なぜこの8枚のカードを選ぶのか?それらはどのように連携するのか?攻撃時と防衛時にはどのようにカードを出すべきか?そして推薦結果はどのように検証すべきか?
本稿では、平均エリクサーコストが 3.5のジャイアント防衛反撃デッキを例に、自然言語による要望を構造化された戦略分析へ変換し、さらにコードによる検証と画像生成を通じて、理解・練習・反復改善が可能な教育プランを得る方法を紹介します。
プロセス全体は、モデルに「最強デッキ」をその場で提示させるものではなく、作業を4つの部分に分けるものです。
制約を明確にする → デッキを分析する → 結果を検証する → ビジュアル教材を作成する。
¶ 1. まず明確にする:AI に何を解決してほしいのか?
「勝ちやすいデッキを組んで」と言うと一見明確に見えますが、実際には多くの必要条件が欠けています。プレイヤーはどのアリーナにいるのか?どのカードをすでにアンロックしているのか?カードレベルは近いのか?進化カード、チャンピオン能力、または特殊なタワーユニットを使用するのか?プレイヤーは高速サイクルと防衛反撃のどちらにより慣れているのか?いわゆる「簡単」とは、操作が簡単という意味なのか、それとも特定の相手に対して明確に有利という意味なのか?
これらの情報が提供されていない場合、モデルは理論上は妥当でも、実際にはプレイヤーのアカウントに適していないデッキを提示しやすくなります。そのため、本ケースではまず以下の境界条件を設定します。
| 観点 | 今回の制約 |
|---|---|
| カード選択 | 基本的で一般的なノーマルおよびレアカードを優先 |
| カード形態 | 通常形態。進化またはチャンピオン能力に依存しない |
| タワーユニット条件 | 通常のプリンセスタワー |
| レベル条件 | 原則として双方のカードレベルは近い |
| 操作目標 | 役割分担が明確で、学習に適している |
| 戦術方向 | 防衛成功後に反撃を組み立てる |
| 評価の境界 | リアルタイムの現バージョン最強とは主張せず、勝率を捏造しない |
これらの制約が、その後の分析の方向性を決めます。私たちが探すのは、理解しやすく、役割が相互補完的な基本プランであり、実戦で検証されていない「必勝公式」ではありません。
¶ 2. GPT-6 Astra に分析を任せ、プログラムに検証を任せる
本ケースでは、AceDataCloud の Chat Completions インターフェースを通じて GPT-6 Astra を呼び出し、リクエスト内のモデル識別子には gpt-6-astra を使用します。インターフェースのURL、認証方法、メッセージ構造はプラットフォーム接続ドキュメントに従います。モデルの利用可能性およびパラメータは、呼び出し時のプラットフォーム設定を基準とする必要があります。ここで使用しているのはプラットフォームが提供するモデル識別子であり、これによって他のサービス入口の利用可能性を推測するものではありません。
| ツール | 担当する作業 | 担当すべきではない作業 |
|---|---|---|
| GPT-6 Astra | カードの役割を説明し、連携を分析し、攻防手順を整理する | 実際の対戦データに代わって勝率を証明する |
| Python | カード数、重複項目、コスト、組み合わせコストを検証する | 加算だけで実戦上の強さを判断する |
| GPT Image 2 | 戦術プランを教育用ポスターに変換する | ゲームメカニクスの権威的な情報源となる |
さらに、履歴上のプロセスと再現方法を区別する必要があります。本ケースの8枚のデッキは、前段階の分析で形成され、その後に GPT-6 Astra を実際に呼び出して構造化された再検証を行いました。Astra に完全なカードプールからグローバル最適解を探索させたわけではありません。教育用ポスターは Image 2.0 によって生成されました。
このようにプロセスを記録することで、再現しやすくなるだけでなく、「モデルが分析に参加した」ことを「モデルが最適性を証明した」と誇張することも避けられます。
¶ 3. プロンプト設計:「デッキを推薦する」から「制約下で推論する」へ
¶ 1. オープン形式のデッキ構築プロンプト
自分のカードプールから始める場合は、以下のテンプレートを使用できます。
你是一名严谨的《皇室战争》教学分析助手。
目标:
从我提供的可用卡牌中,选择一套适合基础玩家的八张卡组。
条件:
1. 只使用我已解锁的卡牌。
2. 不依赖进化或英雄技能。
3. 默认普通公主塔,卡牌等级接近。
4. 优先职责互补、操作简单、方便学习的体系。
5. 必须说明主要拆塔手段、对空、清群和防守方式。
输入:
- 我的竞技场与杯数:……
- 可用卡牌及等级:……
- 常见对手:……
- 我的操作偏好:……
输出:
- 八张卡牌及职责
- 总费用与平均费用
- 选择理由
- 进攻与防守步骤
- 明确的弱点和替换代价
不得编造胜率。
若没有实时资料,不得声称这是当前版本最强卡组。
重要なのはプロンプトの長さではなく、選択を許可する範囲、最適化目標、そして認めなければならない制限が提供されているかどうかです。
¶ 2. 本ケースで使用した再検証プロンプト
既存プランを検証するため、今回はさらにタスクを絞り込みます。以下は、実際の再検証要件を整理した版です。
请复核以下卡组,而不是重新寻找全卡池最优解:
巨人5、迷你皮卡4、火枪手4、炸弹兵2、
亡灵3、加农炮3、万箭齐发3、火球4。
默认:
卡等接近、普通公主塔、普通形态,
无进化、无英雄技能。
请返回一个有效的 json 对象,包含:
deck、total_elixir、average_elixir、
advantages、attack_steps、defense_cases、
limitations、validation_note。
要求:
- 说明每张卡的职责。
- 区分“利用防守残兵”和“免费获得单位”。
- 不得把11费组合说成满10费即可立即全部部署。
- 不承诺无伤防守。
- 不提供没有来源的精确伤害或胜率。
今回の実際の呼び出しで得られた核心的な結論は:デッキの役割分担が明確で、防衛からのカウンターを練習するのに適しているが、飛行ユニットには保護が必要であり、押し込みの段階でも反対側からの攻撃に対処するためのリソースを残しておく必要がある。これは与えられたメカニズムに基づく理論分析であり、シミュレーターテストやトロフィー帯の統計を意味するものではない。
¶ 四、API を通じて構造化分析を取得する
Chat Completions インターフェースは Bearer Token 認証を使用し、生成されたテキストは choices[0].message.content から読み取ることができる。
以下は簡潔な Python の再現例である。実行前に requests をインストールし、自身の実行環境で ACEDATACLOUD_API_KEY を設定する。キーをコードリポジトリやブラウザのフロントエンドに書き込んではならない。実際のケースでは MCP ツール呼び出しを通じている。以下のコードは対応する HTTP 接続方法を示すものであり、このスクリプトが読者の環境でテスト済みであると主張するものではない。
import json
import os
import requests
URL = "https://api.acedata.cloud/openai/chat/completions"
# 本ケースで照合済みの入力スナップショット。
# 実際のプロジェクトではバージョン管理されたカード資料を維持し、モデルによるコストの推測に依存しないこと。
cards = [
{"name": "巨人", "elixir": 5, "role": "只攻击建筑的高血量前排"},
{"name": "迷你皮卡", "elixir": 4, "role": "地面单体高伤"},
{"name": "火枪手", "elixir": 4, "role": "远程对地对空"},
{"name": "炸弹兵", "elixir": 2, "role": "地面范围伤害"},
{"name": "亡灵", "elixir": 3, "role": "空中部队,可对地对空"},
{"name": "加农炮", "elixir": 3, "role": "仅对地的防守建筑"},
{"name": "万箭齐发", "elixir": 3, "role": "清理脆皮群"},
{"name": "火球", "elixir": 4, "role": "范围伤害与补伤害"},
]
task = """
请复核输入卡组,返回有效的 json 对象。
输出字段:
deck(每项包含 name、elixir、role)、
total_elixir、average_elixir、advantages、
attack_steps、defense_cases、limitations、validation_note。
默认卡等接近、普通公主塔、普通形态,无进化无英雄。
这是已有卡组复核,不是全卡池最优搜索。
没有实时对战数据,不得编造胜率、无伤承诺或精确伤害。
"""
response = requests.post(
URL,
headers={
"Authorization": f"Bearer {os.environ['ACEDATACLOUD_API_KEY']}",
"Content-Type": "application/json",
},
json={
"model": "gpt-6-astra",
"messages": [
{
"role": "system",
"content": (
"Return a valid json object. "
"你是严谨的游戏教学助手,只基于给定事实分析。"
),
},
{
"role": "user",
"content": task + "\n输入卡组:\n"
+ json.dumps(cards, ensure_ascii=False),
},
],
"response_format": {"type": "json_object"},
"max_tokens": 2200,
},
timeout=(10, 180),
)
response.raise_for_status()
body = response.json()
if body.get("error"):
raise RuntimeError(body["error"])
choice = body["choices"][0]
if choice.get("finish_reason") != "stop":
raise RuntimeError("输出未正常结束,请检查返回状态或调整输出预算")
content = choice["message"].get("content")
if not content:
raise RuntimeError("没有获得可解析的分析内容")
result = json.loads(content)
print(json.dumps(result, ensure_ascii=False, indent=2))
¶ 実際に遭遇したインターフェースの詳細
今回の呼び出しでは、最初の JSON モードのリクエストがサーバー側に拒否され、入力メッセージに json を含めるよう求めるエラーが表示された。英語の指示 Return a valid json object. を明確にメッセージへ追加した後、リクエストは成功した。
ここで、失敗が必ず大文字・小文字やその他の要因によるものだと推測する必要はない。エンジニアリング上より堅実な処理は:JSON の出力を明確に要求し、同時に返却形式を設定し、終了状態を確認し、解析後もフィールドと数値の検証を続けることである。
JSON として解析できることは、構文が成立していることを示すだけであり、ゲーム分析が正しいことを意味しない。
¶ 五、最終デッキ:3.5 コストの巨人カウンター
今回の構成は以下のとおりである。コストは対応するカード資料に基づき、役割と連携はこのデッキ構成の設計を説明するためのものである。
| カード | エリクサー | 主な役割 | 使用上の注意 |
|---|---|---|---|
| 巨人 | 5 | 被ダメージ受け、押し込み、建物攻撃 | 敵ユニットの排除は担当しない |
| ミニ P.E.K.K.A | 4 | 高体力の地上目標を処理 | 小型ユニットに囲まれたり引き離されたりしやすい |
| マスケット銃士 | 4 | 遠距離火力、主力の対空 | 保護が必要で、他の後衛と密集させない |
| ボンバー | 2 | 地上の集団を処理 | 対空できない |
| ガーゴイル | 3 | 第二の対空、火力補充 | アローレインと範囲ダメージに弱い |
| 大砲 | 3 | 中央への誘導、補助防衛 | 飛行ユニットを攻撃できない |
| 矢の雨 | 3 | 低耐久の集団を除去 | 実際の目標に応じて使用すべき |
| ファイアボール | 4 | 集中した後衛を攻撃、ダメージ補完 | 同レベルのマスケット銃士を確実に一撃で倒せるわけではない |
このデッキの価値は単体カードのレアリティではなく、役割の相互補完にある。巨人が主なタワー破壊の圧力を提供し、ミニ P.E.K.K.A が地上の脅威を処理し、ボンバーが単体火力を妨害する小型ユニットを処理し、マスケット銃士とガーゴイルが二つの継続的な対空手段を提供し、大砲が火力を出す時間を稼ぎ、二枚の呪文が障害排除とダメージ補完を担う。
¶ コードでコストを検証する
モデルが返した average_elixir だけを読み取ってはならない。より信頼できる方法は:照合済みの入力資料を用いて再計算し、モデル出力とクロスチェックすること。
前の例の後に、以下のコードを追加します:
trusted_costs = {card["name"]: card["elixir"] for card in cards}
deck = result["deck"]
names = [card["name"] for card in deck]
if len(names) != 8 or len(set(names)) != 8:
raise ValueError("卡组必须恰好包含8张不同卡牌")
if set(names) != set(trusted_costs):
raise ValueError("模型更改了本次要求复核的卡组")
for card in deck:
if card["elixir"] != trusted_costs[card["name"]]:
raise ValueError(f"费用不一致:{card['name']}")
total = sum(trusted_costs[name] for name in names)
average = total / len(names)
if result["total_elixir"] != total:
raise ValueError("模型返回的总费用不一致")
if abs(float(result["average_elixir"]) - average) > 1e-9:
raise ValueError("模型返回的平均费用不一致")
print(f"总费用:{total},平均费用:{average}")
本例の独立したコスト確認結果は以下のとおりです:
総コスト:5 + 4 + 4 + 2 + 3 + 3 + 3 + 4 = 28
平均コスト:28 ÷ 8 = 3.5
よく使われる組み合わせも引き続き確認できます:
| 組み合わせ | 総コスト | 用途 |
|---|---|---|
| ジャイアント+ボンバー | 7 | 地上の小型ユニットに対応する軽い攻め |
| ジャイアント+マスケット銃士 | 9 | 対空能力を持つ通常の攻め |
| ミニP.E.K.K.A+ボンバー | 6 | それぞれタンクと地上の小型ユニットを処理 |
| 大砲+マスケット銃士 | 7 | 引き寄せと遠距離火力 |
| ジャイアント+マスケット銃士+ボンバー | 11 | 残存ユニットまたはエリクサー回復を利用して、段階的に完全な攻めを形成する |
最後の項目は特に注意が必要です:11コストの組み合わせは、エリクサーが10しかない時点で即座にすべて配置することはできません。これは、防衛で生き残ったマスケット銃士やボンバーに、新しく配置したジャイアントを組み合わせて作るほうが適しており、3枚を一度に重ねて出すものではありません。組み合わせのコストは投入コストにすぎず、安定してエリクサー得をできることを証明するものではありません。
¶ 六、分析を実行可能な攻防プランに変換する
¶ 攻撃:まず守り、残存ユニットをプレッシャーに変える
このデッキの主軸は、開始直後にジャイアントを投入することではなく、以下のとおりです:
- 大砲またはユニットで敵の攻撃を処理する。
- 生存ユニットの体力、位置、現在のコストを確認する。
- 条件が整ったとき、残存ユニットの前方にジャイアントを追加する。
- 相手の対処札を確認してから、ユニットを追加するか呪文を使うかを決める。
- もう一方のレーンへの攻撃に対処する能力を残す。
例えば、マスケット銃士が防衛後も生き残っている場合、彼女が橋を渡る前にジャイアントを配置し、ジャイアントに先にダメージを受けさせ、マスケット銃士には引き続き攻撃させます。ここでのリソース上の利益は、すでにコストを支払った1体のユニットが防衛と反撃の両方に参加することから生まれるのであり、無料のマスケット銃士を突然得ることではありません。
¶ 防衛:脅威に応じて構成要素を選ぶ
| 相手の脅威 | 優先する対処方針 |
|---|---|
| ホグライダーなどの建物ターゲットユニット | 速やかに大砲を中央に置いて引き寄せ、支援状況に応じてカードを追加する |
| 高体力の地上ターゲット | ミニP.E.K.K.Aをタワー火力と組み合わせ、必要であれば先に建物で経路を変える |
| 地上の小型ユニット群 | ボンバーで処理する、または適切なタイミングで矢の雨を使う |
| 空中攻撃 | マスケット銃士とガーゴイルを分散配置し、同時に範囲ダメージで除去されるのを避ける |
| 密集した後衛支援 | ファイアボールでダメージを追加し、その後ユニットに引き継がせる |
これらのプランはいずれも位置、レベル、タイミング、敵の支援に依存しており、固定されたノーダメージの公式として理解すべきではありません。大砲は建物のみを攻撃する空中ユニットを引きつけることはできますが、自身は対空攻撃できません。
¶ 必ず残すべき弱点の説明
適格な AI 戦略出力は、プレイヤーにどのような時に苦しくなるかを明確に伝えるべきです:
- マスケット銃士とガーゴイルが処理された後は、対空のプレッシャーが明らかに増加します。
- このデッキにはリセット系の呪文がないため、インフェルノ系の防衛に対してむやみにユニットを重ねることはできません。
- ジャイアントを投入した後、もう一方のレーンが相手のプレッシャー対象になる可能性があります。
- 3.5コストは極限の高速回転を意味するわけではなく、重要な防衛カードが交互に使われた場合、必ずしもすぐに手札へ戻るとは限りません。
したがって、モデルが提供するものは練習の出発点であり、その後も自分のカードレベル、よく遭遇する相手、対戦記録に合わせて調整すべきです。
¶ 七、戦術プランを4Kの教学ポスターにする
文章は理由の説明に適しており、画像は配置の関係やカードを出す順序を示すのにより適しています。本ケースでは、8枚の大きなカードを機械的に並べる方式を採用せず、画面をつながった3つの教学段階として設計しました:
低コスト防衛 → ジャイアントを前に出し、残存ユニットが追従 → 対処札を見極め、支援を追加する。
下図は、今回 Image 2.0 によって生成された教学ポスターです。画像ファイルのサイズは確認の結果、3840×2160、16:9です。

図:AI が生成した戦術教学イメージであり、ゲームの実戦スクリーンショットではなく、正確な射程やマス単位の配置を表すものでもありません。
¶ プロンプトには「教学上の関係」を書き、「画面スタイル」だけにしない
「4K、細部が豊富、映画風」は視覚的な方向性しか説明できず、生成結果に教学的価値があることを保証できません。したがって、プロンプトには同時に以下を含めるべきです:
- 役割関係:巨人が前、マスケット銃士とボンバーが後ろ。
- フェーズ関係:左側で防衛、右側で反撃し、矢印でつなぐ。
- メカニズム制約:巨人は建物のみを攻撃する;大砲とボンバーは対空できない。
- 情報階層:タイトル、3ステップのチュートリアル、デッキ一覧、コスト、注意事項。
- 境界説明:通常形態の解説であり、効果はカードレベルと操作に影響される。
以下は考え方を再現するのに適した簡潔なプロンプトであり、元の長いプロンプトの逐語的な記録ではない:
制作一张16:9横版、3840×2160的中文战术教学海报。
主题:皇室战争“3.5费巨人防守反击”。
画面不是卡牌网格,而是生动的3D卡通竞技场教学场景。
左侧:加农炮中场拉扯,迷你皮卡处理地面肉盾,
火枪手对空,炸弹兵清理地面小兵。
右侧:巨人在最前方向敌方建筑推进,
防守存活的火枪手和炸弹兵在后方分散跟进,
亡灵提供空中支援。
用清晰箭头表达:
低费防守 → 补巨人反击 → 看清解牌再补支援。
底部展示八张卡及费用:
巨人5、迷你皮卡4、火枪手4、炸弹兵2、
亡灵3、加农炮3、万箭齐发3、火球4。
标注:
平均圣水3.5;
巨人+炸弹兵=7费;
巨人+火枪手=9费。
提醒:
保留防守圣水、后排分散站位、先看解牌再交法术。
确保中文清晰、战术指向准确。
不要画巨人攻击部队,不要画加农炮或炸弹兵攻击空中。
¶ 画像インターフェース設定
画像生成インターフェースのドキュメントでは、size を通じてピクセル寸法を指定でき、16:9の4K仕様は 3840x2160 である;プロンプト内に「4K」と書くだけでは、サイズパラメータの代わりにはならない。
リクエストボディの主要な設定は以下のとおりであり、prompt は完全なポスター説明に置き換える必要がある:
{
"model": "gpt-image-2",
"prompt": "此处填写完整的战术教学海报提示词",
"size": "3840x2160",
"quality": "high",
"n": 1,
"output_format": "png",
"response_format": "url"
}
対応するインターフェースは以下である:
POST https://api.acedata.cloud/openai/images/generations
¶ 実際の生成過程における失敗と切り替え
今回は当初 Image 2.5 を使用したが、タスクは明確な上流サービスエラーで終了し、画像は生成されなかった。その後、切り替えを確認したうえで gpt-image-2 に変更し、4Kおよび16:9の仕様を維持して、最終的に生成に成功した。
ここには重要なエンジニアリング原則がある:
タスクがまだ実行中である場合は、同じタスクを照会する;タスクが明確に失敗した後で、再試行またはモデル切り替えを行うか決める。
今回使用した MCP 画像ツールは非同期タスク方式で実行される:送信後にタスク ID を取得し、成功または失敗するまで照会する。HTTP インターフェースを直接呼び出す場合は、対応するドキュメントに従って同期レスポンスまたは非同期コールバックを処理し、異なる呼び出し方法のレスポンス構造を混用してはならない。
¶ 八、さらに持続的に反復できるツールへ発展させるには?
このケースを本格的なデッキアシスタントへ拡張するには、3層の機能を追加できる。
¶ 1. バージョン管理された資料
カード名、コスト、攻撃対象、レベル、資料の更新日時を記録する。ダメージ、HP、射程など変化しやすいデータについては、モデルの記憶に頼るのではなく、出典のある資料を使用する。
¶ 2. ユーザーのカードプール制約
ユーザーが解放済みのカードとレベルを入力として扱う。レベル差が大きい場合、理論上の組み合わせが妥当であっても、実際のパフォーマンスがより良いとは限らない。
¶ 3. 対戦フィードバック
相手の主な攻撃手段、自分がどのフェーズでエリクサー優位を失ったか、重要な対空カードがすれ違っていないか、そして問題がデッキ構成にあるのか配置とタイミングにあるのかを継続的に記録する。
そのうえで、モデルにこれらの記録に基づき、一度に変更する変数を一つか二つだけにする調整提案をさせ、1戦負けるたびにデッキ全体を入れ替えることはしない。
ポスターについても独立した受け入れ検証を行うべきである:8枚のカードが完全に揃っているか、中国語が正しいか、コストが一致しているか、矢印が正しい対象を指しているかを確認する。生成に成功したことは内容の受け入れ検証に合格したことを意味せず、解像度が正しいことも戦術図解が完全に正確であることを意味しない。
¶ 結び
このケースが示しているのは「AI が自動的に最強のデッキを算出する」ことではなく、より信頼性の高い利用方法である:
制約でタスクを限定し、GPT-6 Astra で組み合わせを説明し、コードで数値を検証し、Image 2.0 で戦術を示し、さらに実戦フィードバックでプランを修正する。
最終的に得られた巨人デッキの中核となる考え方は、一文に凝縮できる:
大砲で引きつけ、ミニP.E.K.K.Aでタンクを処理し、マスケット銃士で対空し、ボンバーで群れを処理する;守り切った後、巨人を前に立たせる。
単に8枚のカード名を得ることと比べ、この方法がより価値を持つのは、プレイヤーが「何を入れるか」だけでなく、「なぜこのように入れるのか、そしていつこのように戦うべきか」も理解できる点にある。
¶ 参考資料
- Chat Completions API 統合ガイド
- Chat Completions API パラメータドキュメント
- GPT Image 画像生成統合ガイド
- 画像生成 API パラメータドキュメント
- カードコストの参考はデッキ表内の各カード資料リンクを参照;実戦数値と利用可能な機能は、現在のゲーム内情報を基準とする。
本稿は AI 支援による戦略および開発実践のケースであり、Supercell 公式の攻略ではない。表紙およびチュートリアルポスターは AI 生成のイメージ図である;『クラッシュ・ロワイヤル』に関連するキャラクターおよび商標は、各権利者に帰属する。

