ゲームバランス調整の進め方｜AIゲーム開発の難易度・数値・自動計測

2026年10月4日

「敵が強すぎる」「お金が余る」「後半がだれる」。こうした問題を、数値とルールの細部で直していくのがゲームバランスの調整です。工程では、最初から最後まで通して遊べる αROM（アルファ版）ができたころから本格的になり、プレイテストやローカライズと並行して進みます。βROM（ベータ版）の後は、仕組みを変えずに数値だけを動かす段階に入ります（全体の流れは「ゲーム開発の全工程マップ」）。

本記事では、調整の対象、「ちょうどいい」の決め方と難易度曲線、数値を表で管理する方法、1度に1つ変えて記録する進め方、記録とプレイテストの使い分け、自動対戦などのシミュレーション、「強すぎる・弱すぎる」の見つけ方、調整の締め切りまでを扱います。後半では、AI エージェントに大量の自動対戦をさせて案を比べる進め方と落とし穴を、筆者の実例とともにまとめます。

夕宮たいだ

ふぁ……みんな〜、今日はバランス調整の話だよぉ。「なんとなく強そうだから少し下げる」をくり返すと、いつまでも終わらないんだぁ。数字と人の感想、両方を使う進め方を見ていこ〜。

バランス調整とは

ひとことで：狙った遊びの体験になるように、ゲームの数値とルールの細部を直していく作業です。

バランス調整は「全部を同じ強さにすること」ではありません。目指すのは、企画で決めた体験です。「ぎりぎりで勝てる緊張感」が狙いなら少し苦しいくらいが、「爽快に敵をなぎ倒す」が狙いなら強すぎるくらいが、ちょうどいいこともあります。

調整の対象は、大きく次の6つに分けられます。

対象	例	主に見るもの
難しさ	敵の体力・攻撃力・数、制限時間、パズルの手数	クリア率、やられた回数、やり直しの回数
成長と経済	経験値、お金、報酬、値段	その時点の所持金・レベル、余りと不足
テンポ	移動の速さ、演出の長さ、1戦の時間	所要時間、飛ばされた演出の数
確率	ドロップ率、会心の率、カードの引き	平均と、外れが続く長さ
CPU の強さ	読みの深さ、ミスの率、反応の速さ	勝率、遊んだ人の感想
選択肢どうしの釣り合い	武器・キャラクター・カードの強さ	選ばれる割合、勝率

対象どうしはつながっています。敵を強くすると回復薬の購入が増え、経済が変わります。1か所を直したら、つながった所も見ます。

「ちょうどいい」を先に決める

ひとことで：調整を始める前に、何を「ちょうどいい」とするかを、数字と体験の言葉で決めておきます。

目標が無いまま調整すると、作り手の気分で数値が行ったり来たりします。先に目標を書きます。

数字の目標（例）：1面は初見の人の8割がクリアする／3面のボスは平均3回の挑戦で倒せる／1章は30分前後で終わる／一番使われる武器でも、選ばれる割合は全体の3割まで
体験の言葉（例）：ボスには最後に体力が少し残るくらいで勝つ／お金は「欲しい物の半分くらいしか買えない」状態が続く

数字は作品ごとに自分で決めるもので、業界の決まった値ではありません。体験の言葉を確かめるための物差しとして使います。

難易度曲線

ゲームの難しさを時間の順に並べた線を、難易度曲線と呼びます。一直線に上げ続けると、遊ぶ人が途中で息切れします。新しい要素を覚える所は易しく、それを使いこなす所で難しく、区切り（ボスや章の終わり）の後で一度下げる、という山と谷をくり返すと、緊張と息抜きのリズムが生まれます。

ただし「ちょうどいい難しさ」は人によって違います。ゲームデザイナーのジェノバ・チェン氏は「Flow in Games (and Everything Else)」（Communications of the ACM、2007年4月号）で、挑戦が能力を上回ると不安に、下回ると退屈になり、その間の帯（フローゾーン）に遊ぶ人をとどめることが大事だと述べています。帯の位置は初心者と上級者で違うので、遊びの中に自分で難しさを選べる余地（寄り道して強くなれる道、危険だが近い道など）を組み込むよう勧めています。

左は山と谷をくり返して上がる難易度曲線（新しい要素・使いこなす・ボス・一息）。右は能力と挑戦の間のフローゾーンで、上に不安、下に退屈、帯の中に初心者と上級者 — 図1：難しさは山と谷で上げ、挑戦と能力がつり合う帯に遊ぶ人をとどめる

数値を表で管理する

ひとことで：調整する数値をコードから出し、表（スプレッドシートやデータファイル）にまとめて、1か所で直せるようにします。

調整する数値がコードのあちこちに直接書かれていると、探すのに時間がかかり、同じ値が2か所にあって片方だけ直す事故も起きます。数値は表に集め、ゲームはそれを読み込むようにします。

表計算で作り、CSV や JSON に書き出して読み込む：一覧で比べやすく、計算式も使えます
エンジンのデータ用の仕組みを使う：Unity の ScriptableObject、Godot の独自のリソース（テキスト形式の .tres で保存でき、インスペクターで編集できる）など

表には値だけでなく、単位と意味も書きます（数値は例）。

ID	名前	体力	攻撃	移動（マス/秒）	出る所	メモ
enemy_slime	スライム	30	5	2.0	1-1〜1-3	最初の敵。3回で倒せる
enemy_bat	コウモリ	20	8	3.5	1-2〜	ジャンプ攻撃を覚えさせる役
boss_golem	ゴーレム	600	25	1.0	1-4	狙い：3回目の挑戦で倒せる

レベルアップに必要な経験値のように規則のある数値は、1つずつ手で書かずに式で作り、式の係数を表に置きます。係数を1つ変えるだけで、全体の曲線が変わるようにするためです。

もう1つ大事なのは、説明文に数値を直接書かないことです。「攻撃力が20%上がる」と文章に書くと、調整のたびに文章も、翻訳した各言語も直すことになります。数値は表から差し込む形にします（翻訳の準備は「ゲームのローカライズ」）。表のファイルもコードと同じくバージョン管理に入れ、いつ何を変えたかを追えるようにします（「ゲームエンジンの選び方と開発環境」）。

夕宮たいだ

数字を1つの表にまとめておけば、「あの値どこだっけ」って探さなくていいんだぁ。便利でしょ？

1度に1つ変えて、記録を残す

ひとことで：1回の調整で変える数値は1つ（1組）にし、変える前の値・理由・結果を記録します。

2つの数値を同時に変えると、良くなっても悪くなっても、どちらが効いたのかわかりません。「敵の攻撃を下げる」と「回復薬を安くする」を同時に行うと、クリア率が上がった理由を説明できなくなります。変えるのは1回に1つ、攻撃と防御の比のようにどうしても組で動かす値は1組と決めます。

最初は少しずつではなく、大きく動かして効く範囲をつかみます。ゲームデザイナーのソーレン・ジョンソン氏は、Game Developer 誌（2009年1月号）のコラム「Sid’s Rules」で、シド・マイヤー氏の「倍にするか、半分にするか」という考え方を紹介しています。ユニットが弱いと感じたら、費用を5%下げるのではなく強さを倍にしてみる、という例です。行き過ぎたら戻せばよく、倍でも足りなければ、5%ずつ何度も試す時間を省けたことになります。範囲がつかめてから細かく詰めます。

変更は、次のような記録に残します（数値は例）。

日付	変えたもの	前 → 後	理由	結果	次の判断
10/02	ゴーレムの体力	600 → 450	初見の5人中4人が5回以上やられる	平均3.2回で撃破	このまま。攻撃の予兆を見やすくするか検討
10/04	回復薬の値段	50 → 80	お金が余り、1章で20個以上買える	1章の終わりの所持数が平均6個	2章の値段も同じ考えで見直す

記録があれば、同じ所を行ったり来たりしていることに気づけますし、後で「なぜこの値なのか」を聞かれたときに答えられます。

夕宮たいだ

ほえ〜、5%ずつじゃなくて、いきなり倍とか半分なんだぁ。思い切って動かした方が、早く答えが見えるんだねぇ。

記録とプレイテストの両方で見る

ひとことで：数字（記録・統計）で何が起きているかを、人のテストでどう感じたかを見ます。

材料	わかること	わからないこと
記録・統計（ゲームが残す記録、自動対戦の結果）	クリア率、やられた場所、所要時間、資源の推移、選ばれた割合	なぜそうなったか、どう感じたか
プレイテスト（人の観察と感想）	理不尽さ、爽快感、手触り、どこで飽きたか	多くの人でも同じか、どれくらいの割合か

Valve の Mike Ambinder 氏は GDC 2009 の講演資料「Valve’s Approach to Playtesting」で、プレイテストの目的は面白さであってバランス調整ではないと整理し、記録の集計については、平均が極端な例を隠すことや、文脈が欠けることを短所に挙げています。数字で「どこで何が起きているか」をつかみ、人のテストで「それがどう感じられているか」を確かめる、と役割を分けると混乱しません（人のテストの進め方は「プレイテストのやり方」）。

2つが食い違う所に、いちばん学びがあります。たとえば勝率は狙いどおりなのに、遊んだ人が「理不尽」と言うなら、数値ではなく伝え方の問題かもしれません。何でやられたのかが見えない、攻撃の前触れが短い、といった原因なら、敵の強さは変えずに、予兆の演出を足す方が効きます。

シミュレーションで大量に試す

ひとことで：人の手では足りない回数を、プログラム同士の自動対戦や大量の試行で確かめます。

カードの組み合わせ、確率で決まる報酬、CPU 同士の対戦などは、人が遊べる回数では答えが出ません。プログラムに大量に遊ばせて数字を集めます。

自動対戦：CPU 同士や、決まった方針で動くプログラムを対戦させ、勝率や試合の長さを集める
大量の試行：確率で決まるものを何万回も引いて、分布を見る
経済の模擬：決まった遊び方で進めたときの、時間ごとの所持金や経験値を計算する

確率は平均だけでなく、外れが続く長さを見ます。出る確率1%のアイテムは平均すれば100回に1回ですが、100回引いても1回も出ない人が約37%（0.99の100乗）、300回でも約5%います。数字の上では正しくても、その人たちにとっては「出ないゲーム」です。

シミュレーションの結果を比べられるものにするには、次の約束を守ります。

乱数の種（シード）と条件（相手・ルール・回数）を記録し、同じ条件で再現できるようにする
案どうしで同じ種の組を使う。運の差がそろうので、少ない回数でも案の差が見えやすくなる
同じ案を2回測り、その差（揺れ）を知る。揺れより小さい差は「差がない」と読む
結果は1回ごとに1行で記録し、途中で止まっても続きから再開できるようにする

調整のループ。数値の表を1つだけ変えてビルドし、同じ種の組で自動対戦し、比較の表で差と揺れを見て、人のプレイテストを経て判断する — 図2：数字で候補を絞り、人のテストで決める。変えるのは1回に1つ

ただし、自動対戦で強い案が、人にとって面白い案とは限りません。プログラムは理不尽さに腹を立てず、人がしない操作で勝ち続けることもあります。シミュレーションは候補を絞る道具で、最後の判断は人のテストで行います。

夕宮たいだ

1%のアイテム、100回引いても3人に1人くらいは出ないんだぁ……確率ってむずかしいねぇ。平均だけ見てると、気づけないんだよぉ。

「強すぎる・弱すぎる」を見つける

ひとことで：使われ方・勝ち方・資源の余り方の偏りを数字で探し、人のテストで理由を確かめます。

問題のある所には、記録に偏りが出ます。

使われ方の偏り：みんなが同じ武器・同じカードを選ぶ。逆に、誰も使わない選択肢がある
勝ち方の偏り：特定のキャラクターや戦い方だけ勝率が高い。特定の組み合わせだけが極端に強い
資源の余りと不足：お金が使い切れない／欲しい物がずっと買えない。経験値が余って敵が弱く感じる
時間の偏り：1つの面だけ極端に長い、または一瞬で終わる

組み合わせの多いゲーム（カード・スキル・装備）は、人の手ですべてを試せません。組み合わせを自動で総当たりし、勝率や与えるダメージが飛び抜けるものを一覧にします。

直し方は1つではありません。強すぎるものを弱める（ナーフ）、弱いものを強める、使う条件や費用を変える、役割をずらす、などがあります。強いものを弱めると、それを気に入っていた人の楽しみも減るので、「他が弱すぎないか」もあわせて見ます。

お金と報酬は「入る量」と「出る量」で見る

経済の調整では、お金や経験値が入る所（敵の報酬・宝箱・依頼）と出る所（買い物・修理・強化）を表にし、章ごとの差し引きを見ます。入る量が出る量を上回り続けるとお金が余って買い物の楽しみが消え、下回り続けると欲しい物が買えずに行き詰まります。決まった遊び方で進めたときの章の終わりの所持金を計算し、「欲しい物がどれくらい買えるか」と並べて確かめます。寄り道の量で差が出るので、最短で進む人と、宝箱を全部開ける人の2通りを計算しておくと、幅がわかります。

CPU の強さは、外の物差しと人の感想で決める

CPU の強さは、読む深さ、考える時間、わざと入れるミスの割合などで変えます。段どうしを対戦させて差を確かめるだけでなく、外の物差し（すでにある市販のゲームの CPU や、腕前のわかっている人）と対戦させ、どの段が人のどのくらいの腕前に当たるかを決めます。弱い段は不自然になりやすい所です。明らかに損な手ばかり指す相手には、勝っても嬉しくありません。人が遊んで、負け方が自然かどうかを確かめます。

調整の締め切り

ひとことで：工程が進むほど動かしてよい範囲を狭め、βROM の後は数値だけ、最後は致命的なものだけにします。

調整に終わりはありませんが、締め切りは要ります。後半に仕組みごと変えると、不具合と作り直しが増えるからです。動かしてよい範囲を工程ごとに決めておきます。

時期	動かしてよいもの	止めるもの（多くの場合）
プロトタイプ〜バーティカルスライス	ルール・仕組みごと	—
αROM まで	仕組みと数値	αROM の後は大きな新機能（フィーチャーフリーズ）
βROM の後	表の数値	仕組み・新しい素材・文言
マスターアップの直前	進行不能など致命的な問題につながる値だけ	それ以外の調整

ここでのフリーズは「その種類の追加・変更を止める取り決め」です。αROM（アルファ版）は「主な機能がそろい、最初から最後まで通して遊べる段階」、βROM（ベータ版）は「機能と素材がそろい、不具合の修正と調整が中心になる段階」を指すことが多いのですが、基準は会社やパブリッシャーとの契約で違います。『Transistor』の開発元 Supergiant Games は、仮素材がなくなった後の「コンテンツロック」の段階で、調整・ボイスのタイミング・実行性能まで固めていくと説明しています（From Alpha to Content Lock）。

1つの項目の調整を終えてよい目安は、次の3つがそろったときです。

記録の数字が、先に決めた目標の範囲に入った
人のテストで、重い違和感（理不尽・退屈・行き詰まり）が出なくなった
それ以上直すには、その時期に動かしてよい範囲を越える変更が要る

発売後も、記録とレビューをもとに調整を続けることがあります。その場合は、変えた数値と理由を更新の告知で伝えます（「発売後のゲーム運用」）。

AIゲーム開発でのバランス調整

ひとことで：大量の自動対戦と集計は AI に任せ、「何をちょうどいいとするか」と手触りの判断は人が持ちます。

試す回数は増やせる。選ぶ責任が重くなる

AI エージェントを使うと、散らばった数値を表に集める作業、自動対戦の仕組み、案ごとの計測、結果の表づくりまでを短い時間で用意できます。これまでは数案を試して勘で決めることが多かった所でも、案を並べて各数百回ずつ測って決める、という進め方が個人で取れるようになります。

その分、重心は「試す」から「決める」へ移ります。何を目標の数字にするか、どの数字を見るか、残った案からどれを選ぶか。計測が速く安くなるほど、ここを曖昧にしたまま進めると、数字だけがきれいにそろった、遊んで面白くないゲームに近づきかねません。

任せやすいこと

数値の棚卸し：コードに直接書かれた数値を探して表やデータファイルに移し、各列の意味と単位を書く
案の比較：調整案を A〜F のように並べ、同じ条件・同じ回数の自動対戦で計測して表にまとめる
計測の仕組み：乱数の種・条件・結果を1行ずつ記録し、途中から再開できるようにする
揺れの見積もり：同じ案を2回測った差を出し、案の差がそれより大きいかを示す
変更の影響の計測：1つの数値を変える前と後を同じ乱数の種で走らせ、クリア率や所持金の推移の差を出す
影響範囲の調査：その数値をどこが使っているかを洗い出す

人が決めること

目標（クリア率・所要時間・勝率の帯）と、そのために見る数字
計測で残った案のどれを選ぶか。数字に出ない手触りや理不尽さの判断
計測の基準（相手・回数・条件）を変えるかどうか

筆者の実例

筆者が作っている、動画サイト内で遊べるミニゲーム版の麻雀では、相手 CPU の「手の作り方」（どんな形を目指し、いつ鳴くか）の案を6つ用意し、各案300回の自動対局で計測して1つに決めました。比べたのは、鳴く回数、上がったときの点数、最初に聴牌（あと1枚で上がれる形）になるまでの巡目です。

開発中の将棋ゲームでは、緊迫した曲へ切り替える条件を計測で決めました。最初の案「最初の王手で切り替える」は、計測すると1局の7〜9割が緊迫曲になってしまうので却下し、玉の周りの危険度（玉とその周りのマスに、相手の駒がどれだけ利いているか）で切り替える形にしました（曲の作り方は「ゲームのBGM・効果音の作り方」）。

計測で失敗もしています。計測を32本並列で走らせたところ、PC がブルースクリーンで止まりました。それ以降は同時に16本までにし、途中から再開できる計測にしています。また、強い CPU は1手に10秒かかることがあり、自動の計測が2時間たっても終わらないため、テストや計測はふだん弱い CPU で行っています。

落とし穴

「自動対戦で強い・勝率が高い」を「面白い」と取り違える：数字は候補を絞る材料で、決めるのは人のテスト
計測の基準を途中で変える：相手の CPU・回数・ルールを変えると、それまでの結果と比べられない。変えるなら全案を測り直す
並列の計測で PC に負荷をかけすぎる：同時に動かす数に上限を決め、止まっても続きから再開できるようにする
数字だけを満たす近道：「勝率を5割に」とだけ頼むと、相手がわざと明らかな悪手を指すような、数字は合うが不自然な形になることがある。見た目の確認も条件に入れる
揺れの範囲の差を改善と読む：同じ案を測り直して、差の大きさを確かめる
表に移すときの書き換え：コードから表へ移す作業で、値が丸められたり単位が変わったりすることがある。移す前と後でゲームの動きが同じかを、同じ種の自動対戦で照合する

依頼文の例

並列作業の分け方は「Claude Code サブエージェント・並列作業ガイド」、依頼文の書き方は「Claude Code プロンプト設計」で解説しています。

Goal: 相手 CPU の調整案 A〜D を、同じ条件の自動対戦で比べる表を作る
Context: 案の数値は data/cpu_params.json。相手・ルール・乱数の種の一覧は tools/sim_config.json に固定する。
  CPU の強さは計測用に「よわい」だけを使う
Done when: 各案300回の勝率・平均の試合時間・ばらつきが表になり、同じ案を2回測った差も書いてある
Constraints: 同時に動かすのは8本まで。止まっても続きから再開できる。ゲーム本体の数値は書き換えない

夕宮たいだ

「勝率5割になったからOK」って、数字だけで決めるのはダメだよぉ。最後は人が遊んで、ちゃんと楽しいか確かめてねぇ。

よくある失敗と対処

ひとことで：多くは「目標が無い」「一度に変えすぎる」「数字か感想の片方だけで決める」から起きます。

失敗	起きること	対処
目標を決めずに調整を始める	数値が行ったり来たりして終わらない	数字の目標と体験の言葉を先に書く
数値がコードのあちこちにある	直し漏れ、同じ値が2か所	表に集め、ゲームは表を読み込む
一度に何個も変える	どれが効いたかわからない	1回に1つ（1組）変え、記録する
少しずつしか動かさない	効く範囲がつかめず、時間がかかる	最初は倍か半分で範囲をつかむ
作った本人の腕前で決める	作り手は上手いので、難しすぎる	初見の人のテストと記録で決める
自動対戦の数字だけで決める	手触りが悪く、理不尽に感じる	人のテストで確かめる
終盤まで仕組みを変え続ける	不具合と作り直しが増える	βROM の後は数値だけにする
説明文に数値を直接書く	調整のたびに文章と翻訳を直す	表から差し込む