つぶやく
さらに，2025年発売の「Pokémon LEGENDS Z-A」（以下，Z-A）で採用されたリアルタイム制バトルは，従来のターン制とどのように基盤を共有しているのか。その答えが示されたのが，CEDEC 2026で7月22日に行われた講演「ポケモン勝負の進化を支える、バトルシステムの基盤設計と運用事例」だ。
登壇したのは，ゲームフリーク 研究開発部「ポケモン・バトルシステムチーム」の宗像 快氏と小幡敏宏氏だ。
 |
同じ技を撃っても，同じことは起きない
まず宗像氏は，ポケモンバトルの特徴を3つ挙げた。1つめは，バトルシステムが扱う設定データの多さだ。総数は2400種類を超え，新作のたびにポケモンや技などが合計200種類以上追加される。この膨大なデータがバトルの多様性を生む一方，品質の維持を難しくしている。
 |
 |
2つめはパッシブスキルだ。プレイヤーが操作して発動させるのではなく，条件を満たした際に自動で効果を発揮する。例として挙げられた特性「いかく」は，バトル場に出たとき，相手の攻撃ランクを1段階下げるものだ。
この種の処理は単純な割り込みでは済まず，場合によっては再帰的な計算が発生するため，複雑な処理順序の制御が必要になる。
3つめは，バトル中にパラメータが動的に変化する点だ。宗像氏は，ゲッコウガの特性「へんげんじざい」を例に挙げた。通常はみずタイプとあくタイプだが，技を出す直前に特性が発動し，その技と同じタイプへ変わる。ひこうタイプの技を選べば，ゲッコウガ自身もひこうタイプになるわけだ。
 |
これら3要素が相互に影響し合うことで，ポケモンのバトルシステムは複雑さを増していく。各プロジェクトが個別に開発すれば，膨大な組み合わせを考慮しながら品質を保つのは難しい。そのため，宗像氏らのポケモン・バトルシステムチームが全ポケモンプロジェクトに参加し，実装を支援している。
ここで登壇者が小幡氏に代わり，講演は基盤設計の説明へ移った。最初に示されたのは，本セッションにおける「バトルシステム」の定義である。例に使われたのは「ほのおのパンチ」で，10％の確率で相手を「やけど」状態にする，ほのおタイプの攻撃技だ。会場で流された動画では，リザードンの攻撃を受けたピカチュウが「やけど」になった。
では，リザードンに道具「クラボのみ」を持たせ，ピカチュウに特性「せいでんき」を付与し，さらに天気を「晴れ」にすると，結果はどう変わるのか。
 |
結果は大きく変わった。「晴れ」の効果でほのおタイプの技によるダメージが増え，ピカチュウの特性「せいでんき」が発動すると，攻撃したリザードンが「まひ」状態に陥る。続いて，持たせていた「クラボのみ」が発動し，その「まひ」を回復。同じ「ほのおのパンチ」でも，状況次第で複数の事象が連鎖していく。
小幡氏は，バトルシステムを，「だれが，何をする」という行動データを受け取り，特性や道具，天気などの状況を加味して，「なにが起こるか」を決める仕組みと定義した。
 |
実際のバトルでは，相手の行動やバフ・デバフも介入し，事象はさらに複雑になる。技・特性・道具はシリーズを重ねるごとに増えるうえ，過去に登場した仕様は後続タイトルでも同じ挙動を担保しなければならない。ポケモンシリーズのバトルロジックには，作品をまたいで品質と整合性を保つことが求められる。
「Section」と「Event」――
ゲームロジックと個別仕様を切り離す
小幡氏は設計思想に先立ち，バトルシステムを再構築した背景を説明した。初代の「ポケットモンスター 赤・緑」は，特性も持ち物もないシンプルなバトルだったが，「金・銀」で新たなタイプと天気が加わり，「ルビー・サファイア」では特性とダブルバトルが登場した。以降もトリプルバトルやメガシンカなどが導入されたものの，実装面では既存システムの拡張に収まっていたという。
大きな転機となったのが，2016年の「ポケットモンスター サン・ムーン」だ。バトルロイヤルの登場を皮切りに，従来の枠組みでは対応しきれない多様なバトルルールの実装が求められるようになった。
 |
バトルの進化に合わせてプログラムも拡張を重ね，ファイルの肥大化，クラスの責務過多，密結合，関数の巨大化といった問題が生じていた。これらが絡み合った結果，新しい仕様を安全に追加しにくくなり，バトルシステムの保守性と拡張性が損なわれていた。
 |
「サン・ムーン」の開発終了時，このままでは今後のバトルの進化に対応できない――そう判断したチーム（宗像氏らのバトルシステムチーム）は，現行システムを明快で柔軟な構造に作り替えることを決めた。こうしてポケモン・バトルシステムチームが結成され，「ポケットモンスター ソード・シールド」の開発時にシステムの再構築が進められた。
新たなバトルシステムには，だれが実装しても同じ構造になる「構造化」，既存コードを変えずに技や特性を追加できる「拡張性」，少ない修正で仕様変更に対応する「柔軟性」，理解や修正，デバッグがしやすい「保守性」という4つの要件が設けられた。柔軟性と保守性は，構造化と拡張性を実現した結果として得られる場合が多いため，講演では前者の2点に焦点が当てられた。
 |
最初に着手したのはゲームロジックの構造化だ。ここで導入されたのが「Section」（セクション）という機構である。再び「ほのおのパンチ」を例に取ると，処理は攻撃力の決定，防御力の決定，ダメージの算出，HPの減少という順に進み，攻撃力には天気「晴れ」の補正も加わる。
流れ自体は単純だが，大量の技・特性・道具をそのまま組み込めば，ゲームロジックは複雑化していく。そこで，「何をどの順番で計算するか」を定義する部分を「ゲームロジック」，技・特性・道具ごとの処理を「個別仕様」として切り分けた。この例では，天気「晴れ」の効果が個別仕様に当たる。
 |
ゲームロジックの最小単位には，「Section」という名称が与えられた。攻撃力決定Sectionや防御力決定Sectionをつなぎ，処理の流れを表現する仕組みだ。
小幡氏が強調したのは，攻撃力決定Sectionに「天気を加味して1.5倍」といった個別仕様を含めない点である。Sectionはゲームロジックの進行だけを定義し，個別の効果は切り離す。この役割分担により，構造の複雑化と実装方法のばらつきを抑えられる。
Sectionは階層構造にも対応する。攻撃力決定・防御力決定・ダメージ算出を「ダメージ計算」Sectionとしてまとめ，そこにHP減少を加えた単位を「ダメージ付与」Sectionとする。さらに上位の「技効果」Sectionが一連の処理を束ね，「ほのおのパンチ」のように追加効果を持つ技では，「状態異常付与」Sectionも組み込まれる。
 |
続いて説明されたのが拡張性だ。ポケモンのバトルシステムでは，既存コードを変えずに技や特性を追加できること，さらに不要な仕様をビルドから除外できることを拡張性と定義している。
攻撃力決定Sectionを例にすると，天気「晴れ」のほか，特性「もうか」「ちからもち」「こんじょう」，道具「こだわりハチマキ」「でんきだま」「ふといほね」など，多数の補正要因が存在する。これらをSectionへ直接積み上げれば，保守性は低下してしまう。
 |
拡張性を担うのが「Event」と「EventHandler」である。SectionがEventを発火すると，対応するEventHandlerが反応し，計算結果に補正を加える。Eventは，個別仕様がSectionの処理へ介入するための接点であり，ゲームロジック本体を変えずに新たな効果を追加できる。
 |
攻撃力決定Sectionが攻撃力補正Eventを発火すると，天気「晴れ」のEventHandlerが反応し，攻撃力に1.5倍の補正をかける。特性「もうか」や道具「こだわりハチマキ」のEventHandlerも条件に応じて介入し，複数の効果を重ねたうえで最終的な攻撃力を算出する。
 |
1つのEventHandlerが複数のEventに反応することもある。天気「晴れ」は，ほのおタイプの技の威力を1.5倍にする一方，みずタイプの技から受けるダメージを0.5倍にするため，晴れのEventHandlerは攻撃力補正Eventと防御力補正Eventの両方に対応する。
同じ処理をSection側へ組み込めば，晴れに関するコードが複数箇所に分散してしまう。EventHandlerへ集約することで，仕様の把握や修正がしやすくなるわけだ。
小幡氏は，Event/EventHandlerの利点を3つにまとめた。メインロジックを変えずに個別仕様を追加できること，不要な仕様をビルドから除外できること，そしてメガシンカやテラスタルのようにシリーズを通して登場するわけではない大型仕様を，ゲームロジック本体から切り離せることだ。タイトルに登場しない技や特性，道具については，対応するEventHandlerを登録しなければビルドから除外できる。
この仕組みが担うもう一つの役割が，ポケモンバトル特有の「割り込みと連鎖」だ。冒頭の例では，「ほのおのパンチ」にピカチュウの「せいでんき」が割り込み，続けてリザードンの「クラボのみ」が作動した。
これをゲームフローへ直接組み込む方法では，技・特性・道具が増えるたびにSectionの呼び出しも追加され，構造の複雑化に歯止めがかからない。そこでEventHandlerに任意のSectionを呼び出す機能を持たせ，計算結果への介入だけでなく，新たな事象も発生させられるようにした。
技効果Sectionの最後に技効果後処理Sectionを置き，そこからリアクションEventを発火する。反応した「せいでんき」のEventHandlerが状態異常付与Sectionを呼ぶと，リザードンは「まひ」状態になる。さらに，状態異常Eventを受けた「クラボのみ」のEventHandlerが状態異常回復Sectionを呼び，所有者の「まひ」を治す。
 |
SectionがEventを発火し，EventHandlerが別のSectionを呼び出す。この再帰構造により，複雑な割り込みと連鎖を共通の仕組みで処理できる。
状態異常付与Sectionは，「ほのおのパンチ」でピカチュウが「やけど」になる場合にも，「せいでんき」でリザードンが「まひ」になる場合にも使われる。ただし，最初の状態異常Eventでは「クラボのみ」の発動条件を満たさない。リザードンがまだ状態異常になっていないためだ。
このように，EventHandlerは条件を満たしたときだけ次のSectionを呼び出す。共通の処理を再帰的につなぐ構造が，パッシブスキルによる割り込みと連鎖を支えている。
ゲームロジックをSectionに分割し，個別仕様をEvent/EventHandlerで切り離す。この構造により，再利用性と拡張性を確保しながら，シリーズを通したバトルの品質と整合性を維持できる。
 |
ターン制とリアルタイム制が，同じ基盤の上で動く
ここから宗像氏が，Z-Aでの運用事例を解説した。Z-Aでは，技の届く距離や範囲，繰り出すタイミング，ポケモンの位置取りが勝敗を左右する。トレーナーとポケモンが共に移動し，攻撃の回避や交代を挟みながら技を仕掛ける，シリーズ初のリアルタイム制バトルだ。
 |
「結論から先に言いますと，異なるバトル形式でも同じバトルシステムを使っています」と宗像氏は説明した。それを可能にした要素の一つが，ゲームロジックの構造化である。
「ソード・シールド」や「スカーレット・バイオレット」のターン制バトルでは，1ターン分の行動をまとめて受け取り，その間に起きる事象を出力する「行動実行」Sectionが使われていた。
技を選択すると，技効果Sectionから発動判定Section，命中判定Section，ダメージ付与Sectionへと処理が進む。発動判定では「こおり」状態などで行動できるかを確認し，命中判定では技の命中率と対象の回避率などから成否を算出する。最後にダメージ付与Sectionが，タイプ相性を踏まえてダメージを決定する。
リアルタイム制では状況が刻々と変わるため，1ターン単位で処理する行動実行Sectionと技効果Sectionは使われない。命中判定もコリジョン同士の衝突，いわゆる当たり判定に置き換えられた一方，発動判定Sectionとダメージ付与Sectionは，仕様を変えずに再利用できた。
 |
 |
「セクション視点で見ると，ターン制バトルで使っていたセクションの中にも再利用可能なものがたくさんあり，まったく異なるバトルとは言えませんでした」と宗像氏は語る。仕様に合わせてSectionの呼び出し順や内部処理を変え，必要なものだけを選べるのは，基盤設計が構造化されているからだ。
Z-Aでは，技のボタンを押すと発動判定Sectionが呼ばれ，使用可能ならポケモンが技を繰り出す。その後，コリジョン同士の衝突によって命中を判定し，当たった場合はダメージ付与Sectionへ処理を渡す。ターン制で使っていたSectionの一部を切り出し，リアルタイム制に組み込んだ形だ。
拡張性の例として，「まもる」の実装も紹介された。ターン制では，そのターン中に相手の技を受けないよう，EventHandlerが技の発動を失敗させる。一方，ターン処理のないZ-Aでは，一定時間「まもる」状態となり，受けるダメージを防ぐ仕組みに変更された。
この違いに対応するため，ターン制用のEventHandlerを削除し，ダメージ付与SectionのEventに反応してダメージを0にする処理を新たに作成した。技の効果を変える際は，不要なEventHandlerを外し，必要に応じて新しいものへ差し替えればよい。既存のEventHandlerを再利用できる点も利点である。
 |
構造化と拡張性を軸にした設計により，共通のバトルシステムでターン制とリアルタイム制の双方に対応できた。コードの再利用性を高めたことが，開発効率の改善と品質の安定化に結びついたと宗像氏はまとめる。
講演の要点は，ゲームロジックを「再利用可能な単位」に分割し，個別仕様を「メインロジックから分離」することだ。「本セッションで紹介したSectionとEvent/EventHandlerの設計は，ポケモンに限らず，複雑化し続けるゲームロジック全般に適用できる考え方です」と宗像氏は述べ，講演を締めくくった。
講演資料は，「CEDEC Digital Library」（CEDiL）で公開される予定だ。
