『ストリートファイター6』から『モンスターハンターワイルズ』へと続く、再現可能なサーバー設計思想と基盤化のプロセス [RE:2026 2026年10月2日登壇]

『ストリートファイター6』から 『モンスターハンターワイルズ』へと続く、 再現可能なサーバー設計思想と 基盤化のプロセス 西谷 宜記

『ストリートファイター6』から 『モンスターハンターワイルズ』へと続く、 再現可能なサーバー設計思想と 基盤化のプロセス 西谷 宜記 皆さん、こんにちは。 本日は「『ストリートファイター6』から『モンスターハンターワイルズ』へと続く、再現可能なサーバー設計思想と基盤化のプロセス」 というテーマでお話しします。 1

モバイルで気づき、『ストリートファイター6』で形にし、 『モンスターハンターワイルズ』で磨き上げ、ace.Networkへ昇華した話 モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network 2 今日の物語は、この一枚に詰まっていて、少し過去のモバイルの話もありますが、 そのモバイルで気付き、『ストリートファイター6』で形にし、『モンスターハンターワイルズ』で磨き上げ、ace.Networkへ昇華させた。 この流れをたどっていきます。 なお、最初に補足しておくと、ace.NetworkというものはRE ENGINEそのものの機能というより、 RE ENGINEをベースとしたタイトル開発の中で、オンライン機能やサーバー設計、運用知見を再利用しやすくするための考え方・基盤です。 RE ENGINEがゲーム開発全体を支えるエンジンだとすると、 ace.Networkはその上でオンライン体験をどう設計し、どう運用し、どう次のタイトルへ知見を残すかに焦点を当てたものです。 具体的には、後ほどお話ししたいと思います。 2

この講演は「技術紹介」だけではありません 今日 話さないこと 今日 伝えたいこと 「◯◯ではこの技術を使った」 技術そのものではなく、 個別の実装テクニックの自慢 そして、失敗や試行錯誤を、 という、採用技術のカタログ的な紹介 手段そのものを主役にする話 技術の裏にあった“考え方” どう再利用可能な形へ変えたか 3 最初にお伝えしたいのは、今日の主題は「こんな技術を使った」というプロジェクト毎の技術解説だけではありません。 お伝えしたいのは、画面右側にある、その裏にあった“考え方”。 そして十数年の試行錯誤を、どうやって『再利用できる形』に変えていったのか、です。 3

本日の流れ 1. モバイル時代の学び 運用と品質そして「リリース前にはわからない」 2. SF6での経験 クロスプレイとコミュニティ体験を実現する 3. モンハンワイルズでの挑戦 体験を守るための、大規模・統合設計 4. モンハンワイルズで得た知見 同じ課題の再発見と、知識の属人化 5. ace.Networkへの昇華 知見を組織の資産にする基盤へ 6. 組織への知識共有 経験を資産化する“文化”をつくる 4 本日の流れです。全部で六つの章があります。 第一章はモバイル時代の学び。 第二章は『ストリートファイター6』での経験。 第三章は『モンスターハンターワイルズ』での挑戦です。 第四章はそこで得た知見。 第五章がace.Networkへの昇華。 そして第六章で組織への知識共有とまとめに入ります。 4

本日の流れ 1. モバイル時代の学び 運用と品質そして「リリース前にはわからない」 2. SF6での経験 クロスプレイとコミュニティ体験を実現する 3. モンハンワイルズでの挑戦 体験を守るための、大規模・統合設計 4. モンハンワイルズで得た知見 同じ課題の再発見と、知識の属人化 5. ace.Networkへの昇華 知見を組織の資産にする基盤へ 6. 組織への知識共有 経験を資産化する“文化”をつくる 5 今回注目してほしいのは、私たちが毎回“同じような問題”にぶつかってきた、という点です。 タイトルも規模も違うのに、立ちはだかる壁は驚くほど似ていました。 その繰り返しをどうやって資産に変えていったのか。 技術の解説というより、一つの物語としてお聞きください。 それでは、始めていきましょう。 5

1 CHAPTER モバイル時代の学び タイトルごとに作る文化のなかで 本当に難しいのは何かを知った o モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network 6 第一章、モバイル時代の学びです。 サーバー運用と品質の難しさ、そして『リリース前にはわからない事も多い』という学びについてお話しします。 6

１．モバイル時代の学び タイトルごとにサーバを作っていた 当時の文化 = １タイトル１サーバ 毎回つくり直していた機能たち 新しいタイトルのたびに、 ゼロから組み上げていた ログイン フレンド ランキング 通知 ガチャ イベント 毎回同じ機能を実装する もちろん最適化もする その都度作り込み、 個別にチューニングしていた IPもゲームも違う。 けれど、作るものは似たものだった 7 まず、当時のモバイル開発は、『タイトルごとにサーバーを作る』という事が多かったです。 新しいタイトルが立ち上がるたびに、ログイン、フレンド、ランキング、通知といった機能を一から実装し、その都度きちんと最適化もする。 右側に並べたこれらの機能を、実は毎回似たようなものを作っていたんですね。 ゲーム性もIPもユーザー体験も違うのに、サーバー側で用意するものは似ているものが多い、という印象でした。 7

１．モバイル時代の学び ゲームは違う。でも起きる問題は似ている タイトルは違っても、サーバー側で直面する問題は、意外なほど共通していた。 負荷予測 同時接続 障害対応 データ不整合 運用負荷 同じ問題に毎回ぶつかっていた 8 また、作る機能もそうですが、本番リリース時のサーバー運用で起きる問題も、意外なほど似ていました。 負荷予測、同時接続、障害対応、データの不整合、運用負荷。 新しい技術に挑戦し続けた結果という面もありますが、これらはタイトルが変わっても毎回立ちはだかってきました。 私たちは毎回“新しいゲーム”を作りながら、“似た問題”と戦っていたわけです。 8

１．モバイル時代の学び 作ることより運用の方がずっと難しい リリースはゴールではなくスタート 本当の勝負は、動き続けるサーバーを支え続けること 負荷・障害・不整合は“運用”で顕在化する 机上でどれだけ設計しても、初めて見える問題がある モバイル時代に最初にぶつかった壁 では、なぜ運用は読みきれないのか 9 モバイル時代の最初の、そして最大の学びがこれです。『サーバーは、作ることよりも運用することの方が、はるかに難しい』。 リリースはゴールではなく、スタートです。負荷も障害もデータの不整合も、実際に動かし始めてから顕在化します。 机の上でどれだけ美しく設計しても、運用を軽視すればどこかで破綻する。それを学んだ時代でした。 9

１．モバイル時代の学び 「リリース前にはわからない」 どれだけ負荷試験をしても どれだけ設計を練っても 本番では必ず “想定外”が起きる 現実のユーザーの動きは 予測を超えてくる そして “想定外” はユーザーだけが理由ではない 「施策」ひとつでも、負荷は大きく動いていく 設計の本質とは “正解を当てること” ではなく変化に耐えること 10 もう一つの大切な学びが、『リリース前には、わからない』ということです。 どれだけ入念に負荷試験をしても、どれだけ設計を考え抜いても、本番では必ずと言っていいほど“想定外”が起きます。 現実のユーザーの動きは、いつも予測を超えてくるからです。 この経験から私たちは、設計に対する考え方を、 「正解を当てること」ではなく「変化に耐えること」だと考えるようになりました。この視点が、このあとの章で効いてきます。 10

１．モバイル時代の学び たとえば、施策ひとつでトラフィックは変わる ガチャによって負荷は変わる 目玉ユニット の強さ 人気キャラか 新キャラか アクセスの集中の仕方も、 その後の継続の仕方も変わる システム要件ではない要素がトラフィックを決める 動かしながら機能が増える 一般的な BtoB サービスと違い、運営中の機能追加が 頻繁に起きる 運用を続ける 運用開始 新機能を開発する 止めずに同時に進める難しさ サーバーは技術だけで完結しない。 ゲームというサービスの内容に寄り添って運用する 11 ここで、運用の難しさの具体例を一つ挙げさせてください。 たとえば、ゲームの施策ひとつでトラフィックの傾向がガラッと変わってしまう事があります。 モバイルゲームで新しいガチャを開催するとした場合、同じ“ガチャ”という機能でも、 排出される目玉ユニットが強いのか弱いのか、人気キャラなのか、新キャラなのか。 そうしたシステム要件ではない要素によって、アクセスの集中の仕方も、その後の継続の仕方も変わってしまいます。 これは、システム設計をどれだけ頑張っても予測できることではありません。 だからこそサーバーは、技術だけで完結させるのではなく、ゲームというサービスの内容に寄り添いながら運用していく必要があります。 もう一つ、ゲームは一般的なBtoBのサービスと違って、運営中に機能が追加されることが頻繁にあります。 動かし続けながら、新機能の開発も並行して進める。これは単純に難易度が高い。 この二つが運用の難しさの事例でした。 11

2 CHAPTER 『ストリートファイター6』 での経験 モバイルで得た学びを土台に 「つながる体験」を本格的に実現した モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network 12 第二章は、『ストリートファイター6』での経験です。 モバイル時代に得た「運用まで見据えないと品質は守れない」という学びを土台に、 『SF6』では、サーバーとクライアントの間で何をやり取りするのか、その入出力を明示的に整理することに踏み込みました。 目的は、実装者ごとの解釈の揺れを減らし、サーバー側・クライアント側が同じ前提で機能を作れるようにすることでした。 この章では、クロスプレイやCapcomFightersNetwork、Battle Hubといった“つながる体験”を支えながら、 その裏側でサーバーとクライアントのIO定義をどう整えたのかをお話しします。 12

２．『ストリートファイター６』での経験 IO定義が、人に依存していた 担当者ごとに 違う 暗黙知に なりやすい 運用で 表面化する 構造体の切り方も 命名も 仕様が個人の 頭の中に残る 障害調査と 引き継ぎの負担に 契約として 揃える 文章ではなく使える形へ 仕様を文章ではなく、 後から実装と確認に使える “契約” として揃える 13 ここからは、『SF6』で見えてきた具体的な課題を少し分けてお話しします。 最初の課題は、過去のモバイルからの経験で、サーバーとクライアントの間のIO定義が、担当者や機能ごとの暗黙知になりやすかったことです。 似たような機能でも、担当者が違うと構造体の切り方や命名、エラー時の扱いが少しずつ違ってしまいます。 小さな違いに見えても、リリース後の運用や障害調査の段階では、原因調査や引き継ぎの負担として表面化します。 そこで『SF6』では、インプットとアウトプットの形、サーバー担当とクライアント担当の責務、エラー時に何を返し、どう扱うのかを、 できるだけ明示的な定義として揃えることを意識しました。 ここで重要なのは“仕様を文章で共有する”だけでなく、後から実装や確認に使える“契約”として扱うことを重視した、という点になります。 結論としてこの契約はコードベースでスキーマ定義を行う事にしたのですが、 13

２．『ストリートファイター６』での経験 なぜ定義をコードに寄せたのか これから これまで 型定義 Aさんの実装 Bさんの実装 資料 Cさんの実装 確認観点もばらばらになる スキーマ 定義 処理コード SQL 確認観点 単一の定義から、すべてが揃う 目的は自動生成ではなく、解釈の違いをなくすこと 14 次に、なぜそれをコードベースに寄せたのか、についてお話しします。 YAMLのようなスキーマで定義し、そこからクライアント側の型や呼び出し口、サーバー側の受け口や 処理のひな形、SQL、確認観点へ展開できるようにすると、設計思想を資料ではなく実体のあるものとして残せます。 利点は、定義と実装のズレが減ること、差分レビューがしやすいこと、 設計変更が入っても起点となる定義から関連する成果物へ反映できることです。 実際に定義を起点にクライアントとサーバーの処理をコードとして自動出力する運用を行い、 開発効率と品質の両面で大きな効果がありました。 目的は自動生成そのものではなく、設計、実装、レビュー、運用確認の起点をそろえ、人による解釈の違いを減らすことにありました。 14

２．『ストリートファイター６』での経験 別チームでも同じ前提で扱える サーバー実装:同じ定義から自動生成 唯一の正 スキーマ定義（YAML） クライアント実装:ズレが起きない エラーコード:定義と扱い方を一元化 開発 同じ定義を参照する 運営・カスタマーサポート エラーの扱いを 同じ定義で判断 同じ定義を同じように参照する。会話の前提がそろう 15 この考え方は、プロジェクト外の人に説明する時にも効果がありました。 たとえばゲームセンター向けのアーケード展開のように家庭用とは別の開発を行う場合、API一覧やスキーマ情報を機械的に出力できること自体が大きな助けになりま す。 どのAPIが存在し、どの入力を受け取り、どの出力を返すのかを、担当者の記憶や個別説明に頼らず確認できる。というように、毎回サーバー担当者が口頭で説明した り、別チーム向けに資料を作り直したりするのではなく、同じ定義から同じ形式の情報を出せることで、関係者が同じ前提で会話しやすくなりました。 この経験は、後のace.Networkで設計思想や判断の型を再利用できる形にしていく際の、最初の手応えにもなりました。 もう一つ重要だったのが、エラーコードの扱いです。 エラーは開発中だけのものではなく、リリース後の運営、カスタマーサポート、障害調査にも関わります。 たとえば同じ通信失敗でも、リトライすべきなのか、ユーザーに案内すべきなのか、運営側で調査すべきなのかで、必要な情報は変わります。 そのため、エラーコードも単に一覧で共有するだけではなく、開発、運営、カスタマーサポートが同じ定義を見て判断できる形を意識しました。 ここで得た「定義を運用につなげる」感覚を、より組織的な仕組みとして扱うようになりました。 15

２．『ストリートファイター６』での経験 『ストリートファイター6』で整備した “つながる体験” クロスプレイを実現する 異なるプラットフォームでも、同じ体験を届ける CFN(Capcom Fighters Network)で 関係性を支える フレンド・クラブ・リプレイ・オンライン状態など Battle Hub(ゲーム内ロビー)で場をつくる プレイヤーが集まり、対戦し、観戦する場を支える サーバーは機能を返すだけではない プレイヤー同士の関係性を支える基盤である 16 ここからは少し話を変えて、『SF6』でどのようなオンライン体験を整備してきたのかを見ていきます。大きかったのは、クロスプレイです。 PC、PlayStation、Xbox、Nintendo Switchの間で、対戦やコミュニケーションを成立させる必要がありました。 ユーザーから見れば友達と遊べるのは当たり前ですが、 裏側ではプラットフォームごとの違いや制約を吸収して、同じ体験として届ける必要があります。 更にCapcomFightersNetworkでは、フレンド、クラブ、リプレイ、オンライン状態といった、 プレイヤー同士の関係性を支える機能を整備しました。 そしてBattle Hubでは、対戦するだけでなく、集まり、観戦し、交流する場所を作りました。 ここで強く感じたのは、サーバーは機能を返すだけのものではない、ということです。 サーバーは、プレイヤー同士の関係性やコミュニティそのものを支える基盤になっていく。これが『SF6』での大きな経験でした。 16

２．『ストリートファイター６』での経験 『ストリートファイター6』サーバー構成 “つながる体験”を成立させるための土台 世界規模で提供する 複数リージョンに展開し、 地域をまたいだ体験を支える 役割ごとに分ける API、Battle Hub等 各種サービスを分けて設計する 体験に応じて通信方式を変える 対戦、ロビー、DB操作を 同じ作り方で扱わない 関連講演 Street Fighter 6 アーキテクチャー大解剖 https://www.youtube.com/watch?v=HRcHnBhhF-k 17 このスライドは、その土台となるサーバーアーキテクチャの全体像です。 読み解きポイントは三つあり、左の図と右のポイントが対応しています。 ここでは、単にどんなサーバーを置いたかではなく、体験ごとに責務を分け、その責務を、どう整理したかを見ていただければと思います。 一つ目、世界規模で提供するため、アジアやアメリカ、ヨーロッパ等複数リージョンへ展開していること。 二つ目、検索やフレンド、ランキングを扱うAPI、プレイヤーが集まるBattle Hubというように、役割ごとにサービスを分けていること。 三つ目、ロビー・対戦・DB操作を一律に扱わず、ロビーは常時つながるリアルタイム通信で行い、対戦は更に低遅延を優先するP2P通信、DB操作はリクエストとレスポ ンスで、というように体験に応じて通信方式を変えていること。です。 これは単純に機能を並べたのではなく、“つながる体験”から逆算して構造を決めた。というのが重要なポイントです。 また、今回アーキテクチャの詳細についてはお話ししないのですが、 当時のサーバーリードの関連講演リンクを貼りますのでよければご参照ください。 17

• https://www.youtube.com/watch?v=HRcHnBhhF-k

２．『ストリートファイター６』での経験 設計上の気付き クロスプレイ・CFN・Battle Hub・サーバー構成に共通していた判断 クロスプレイ CFNから Battle Hubから アーキテクチャから プラットフォームではなく プレイヤー体験を 起点に考える 機能ではなく プレイヤー同士の 関係性を支える ロビーではなく プレイヤーが集まる場所 を作る 技術を並べるのではなく 体験に応じて 役割を分ける から得た気付き 得た気付き 得た気付き 得た気付き “つながる体験” を起点に設計する プレイヤーが求めているのは “つながる体験” 18 ここまで見てきた『SF6』の構成やオンライン体験から、設計上の気付きを四つに整理します。 クロスプレイからは、プラットフォームではなくプレイヤー体験を起点に考えること。CFNからは、機能ではなくユーザーの関係性を支えること。 Battle Hubからは、単なるロビーではなくユーザーが集まりコミュニケーションする場所を作ること。 そしてアーキテクチャからは、技術を並べず、体験に応じて役割を分けること。 共通しているのは、プレイヤーが求めているのはサーバーそのものではなく“つながる体験”だ、ということです。 18

２．『ストリートファイター６』での経験 成功体験 モバイル SF6 ゲームを コミュニティを ひとつのゲームを安定して動かす プレイヤーが集い、つながる場を作る 成立させた 成立させた 運用を見据えたIO・エラー定義 毎回決め直すのではなく、構造化して再利用できる領域がある 19 第二章の締めくくりです。 モバイル時代に向き合っていたのは、ひとつのゲームを成立させること。 『SF6』ではそこから一段進み、クロスプレイで世界中のプレイヤーをつなぎ、CFNで関係性を支え、Battle Hubで集まる場所を作りました。 成立させたのはゲームだけではなく、コミュニティです。 サーバーの役割が、ゲームを動かす裏方から、人と人のつながりを支える基盤へと変わりました。 同時に、リリース後の運営を見据えて、入出力やエラー時の扱い、確認すべき情報をあらかじめ揃えておく重要性にも気付きました。 まだ組織的な共通基盤ではありませんが、毎回必要になる基礎設計には、構造化できる領域がある。 この気付きが次へとつながっていきます。 ここで作った“つながる体験”を、桁違いの規模と、高いリアルタイム性の中でどう守るのか。それが次の章のテーマです。 19

3 CHAPTER 『モンスターハンターワイルズ』 での挑戦 これまでとは比較にならない規模 モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network 20 第三章、『モンスターハンターワイルズ』での挑戦です。ここが今日の中心、一番時間をかけるパートです。 『ストリートファイター6』の整えた体験を、もっと大規模に実現する必要がありました。それをどう磨き上げたのかをお話しします。 20

３．『モンスターハンターワイルズ』での挑戦 『モンスターハンターワイルズ』で直面した課題 SF6で実現した“つながる体験”を、世界規模で守る必要があった 同時接続想定 100万人規模 API RPS （Requests Per Sec） 100万超 サーバー稼働規模 最大30万台 21 まず、『モンハンワイルズ』で直面した課題の大きさからお話しします。 リリース前の想定規模は、同時接続100万人以上、APIリクエスト100万RPS以上、最大30万台規模のサーバー稼働です。 もちろん実際にどれだけアクセスされるかは、リリースするまで分かりません。 だからこそ「どう作るか」より、「どう変化に耐え、どう拡張できるか」が重要でした。 21

３．『モンスターハンターワイルズ』での挑戦 『モンスターハンターワイルズ』サーバー構成図 体験を守るために、責務を分離する API 検索、フレンド、救難信号など、Web API として扱う領域 Real Time ロビー等、リアルタイム性が求められる領域 P2P クエストなど、低遅延の体験を優先する領域 22 この規模を一つの仕組みで扱うことはできません。 重要だったのは、すべてを同じ作り方で解決しないことでした。これは『ストリートファイター6』からの流れです。 APIでよいものはAPIで、リアルタイム性が必要なものは専用のリアルタイムサーバーで、さらに低遅延が重要なものはP2Pで。 サーバー構成を技術起点で決めるのではなく、プレイヤー体験ごとに責務を分けています。 22

３．『モンスターハンターワイルズ』での挑戦 スケールを越えて体験を守る 関連講演 どうスケールさせるか どう体験を守るか 100万同時接続・30万台規模 まず越えるべき大きな難題 規模を満たすだけでは足りない 体験の質まで守り抜く モンスターハンターワイルズ ～同時接続約100万人以上を支える、絶対落とさないための技術選定～ https://findy-code.io/events/sGVJDufuyTQnM 23 そして、どうスケールさせるかという大きな問題もありましたが、 このアプローチについては、別途『ワイルズ』のサーバーリードが講演したものがあるので、そちらのリンクを貼っておきます。 よければご参照ください。 その上で重要なのは『どう体験を守るか』でした。 大規模な運用は目的ではありません。 ユーザーが評価するのはサーバーの性能ではなく、あくまで“体験”です。 そこを守ることが、設計思想すべての出発点になっています。 23

• https://findy-code.io/events/sGVJDufuyTQnM

３．『モンスターハンターワイルズ』での挑戦 たとえば100人ロビー問題 100人が同じ空間にいる。聞くだけなら簡単。でも、全員の位置を全員へ送ると―― 全員に送る 関心のある範囲だけに送る 人数が2倍になると通信量は4倍 “どう送るか” ではなく “何を送らないか” を考える 24 ここからは具体例です。『ワイルズ』を象徴する課題として、100人ロビーの話をします。 100人が同じ空間にいる。聞くだけなら簡単に思えますが、実装の視点で見ると話は変わります。 左の図の〇一つが1人のプレイヤーだと思ってください。 全員が全員の位置を知る必要がある、これを素直に考えると、通信は100人が自身を除く99人に対して通信を行うので、100×99の組み合わせに膨れ上がります。 しかも位置情報は一度きりではなく、毎秒何度も更新され続けます。 人数が二倍になれば通信量は四倍。これは足し算ではなく掛け算で効いてくる問題です。 そしてこれは、通信量だけの話でもありません。 送る側のサーバーCPU、受け取る側のクライアントの処理、その両方に同時に負荷がかかります。 回線を太くすれば解決する、という種類の問題ではないわけです。 そこで私たちは、問いそのものを置き換えました。 『何を送るか』ではなく、『何を送らないか』。ここから考え直しました。 次のページで詳しく話しますが、例えば、関心のある範囲に絞って送る。というような事です。 同じ空間にいても、遠く離れたプレイヤーの細かい動きは、プレイ体験にほとんど影響しません。 こうする事で100×99だった組み合わせが一気に現実的な数にする事ができます。 24

３．『モンスターハンターワイルズ』での挑戦 「送らない」ための 四つの判断 近い人だけ送る 送信回数を減らす まとめて送る 圧縮する 関心のある範囲に絞る 更新の頻度を最適化 バッチ化して効率化 データ量そのものを削る 通信量も CPU負荷も 大きく削減できた 25 『何を送らないか』を、四つの判断に落とし込みました。 一つ目、近い人にだけ送る。先ほどの例のようにプレイ体験に影響がないユーザーのデータを除外する事で現実的な数に落とし込みます。 二つ目、送信の回数を減らす。位置情報を最高頻度で送り続ける必要は必ずしもありません。状況に応じて更新頻度を変える、という考え方です。 三つ目、まとめて送る。細かいパケットを大量に送るより、バッチ化した方がオーバーヘッドが減ります。ここはサーバーのCPU負荷にも効いてきます。 四つ目、圧縮する。データ量そのものを削ります。 どれも派手な技術ではありません。教科書に載っているような手法です。 ただ、この四つを掛け合わせると、効果は積み上がります。結果として通信量もCPU負荷も大きく削減できました。 ここで強調したいのは、効いたのは魔法のような新技術ではなく、“何を送らないか”という判断の積み重ねだった、ということです。 25

品質はサーバーだけでは守れない IO負荷を下げる判断が、見た目の違和感を生む。だからクライアント側でも体験を補完する 1. 同期頻度を下げる サーバー負荷を抑えるため、 位置同期の頻度を削減 2. ワープが目立つ 更新頻度が下がると、他プ レイヤーの移動が不自然に 見える 3. モーションで補完する 受信座標をモーションの目 標地点にし、自然な移動に 見せる 26 ただし、ここに落とし穴があります。サーバー最適化だけでは、体験は守れません。 いま話した「同期頻度を下げる」という判断は、サーバーから見れば完全に正しい。負荷も通信量も確実に下がります。 ところがプレイヤーから見ると、他のプレイヤーがカクカクとワープしているように見えてしまう。 数値上は改善しているのに、体験は悪化している。この状態が一番やっかいです。 そこでクライアント側で補完処理を行いました。 受信した座標を、そのまま反映するのではなく、現在のモーションの目標地点として扱います。 キャラクターは自分の歩き・走りのモーションでそこへ向かうので、更新が飛び飛びでも、移動は自然に見えます。 つまり、サーバーが情報を削り、クライアントがその隙間を埋める。この二つはセットで設計して初めて成立します。 この動画では、他プレイヤーの視点で、補完によって移動が自然に見える様子をご覧ください。 26

想像ではなく観測して改善する 100人相当で動かして初めて分かる GPU付き クラウドインスタンス オートプレイ実行 ログ、ダンプ、 画面キャプチャを収集 大規模チェックを自動化 27 次は、その品質をどう確かめたかという話です。 100人ロビーは、100人相当で動かして初めて分かることばかりでした。 負荷の形も、見え方の破綻も、机上の計算とは違うところに出ます。 かといって、100人分の実機と人員を毎回集めるのは現実的ではありません。 そこでクラウド上にGPU付きインスタンスを用意し、オートプレイで多人数環境を再現しました。 仕組みの詳細は、このあとのスライドでお話しします。 想像で議論するのではなく、観測して改善する。規模が大きくなるほど、この差が効いてきます。 27

３．『モンスターハンターワイルズ』での挑戦 実測で見えた体験品質の問題 原因 結果 発生 関心範囲の判定 がずれる 更新の過不足が 起きる 表示の不具合・ 通信エラー 「近い人にだけ送る」判 定が、想定した範囲から 外れる 必要な更新が届かない／ 不要なデータを受け取る 実際に人数を集めて動か すまで見つからない不具 合 通信量だけでなく “自然に見えるか” まで確かめる 28 実際に100人相当を動かして気が付いた具体例を挙げると、 クライアント側の体験品質の問題です。 特に分かりやすかったのが、『近い人にだけ送る』際の内容で、 実際に動かすと、どこまでを関心範囲と判定するかが想定通りにいかない場面がありました。 判定が少しずれるだけで、見えるべきプレイヤーの動きが更新されなかったり、逆に不要な情報を受け取ってしまう。 その結果、表示の不具合や、特定条件でのみ起きる通信エラーも見つかりました。 仮想的な負荷をかけるだけでは見つけにくい問題です。 実ユーザーとして存在させたからこそ、体験として確認すべきポイントが見えてきました。 28

３．『モンスターハンターワイルズ』での挑戦 大規模チェックを繰り返せる仕組みに 起動するサーバの設定（CPUやメモリの性能…） 29 では、その大規模チェックを支える仕組みです。 クラウド上でGPU付きインスタンスを必要数だけ起動し、 専用のWebツールから台数とROMを指定してオートプレイを実行できるようにしました。 100人相当の確認を、人手や実機だけに頼らず回せます。 実行中にクラッシュや例外が発生した場合は通知を行い、ダンプを社内ストレージに保存します。 ログや画面キャプチャも取得することで、落ちたかどうかだけではなく、どの状態で、どのように壊れたのかまで追えるようにしました。 この仕組みの価値は、大規模な動作確認を“イベント”ではなく“繰り返し実行できる検証フロー”にしたことです。 品質を継続的に確認しやすくなりました。 29

３．『モンスターハンターワイルズ』での挑戦 重要なのは技術ではなく「判断」 捨てるもの なくても体験が守れる 過剰な情報 残すもの 体験に直結する 本当に必要な情報 設計とは、選択の連続である 30 話を戻して、100人ロビーの話を通じて、改めてお伝えしたいことがあります。 技術はもちろん重要ですが、本当に重要だったのは“判断”です。 何を送らないかの話で出ていた手法は、どれも特別なものではありませんでした。 差がついたのは、何を残し、何を捨てるかを決めたところです。 体験に直結する情報は、負荷がかかっても残す。なくても体験が守れる過剰な情報は、思い切って捨てる。 そしてこの取捨選択は、サーバーの都合だけでは決められません。 ゲームとして何が大事かが分かっていて、初めて捨てる判断ができます。 設計とは選択の連続であり、その選択の基準を持てるかどうかが核心でした。 30

３．『モンスターハンターワイルズ』での挑戦 クライアントとサーバーを別々に考えない 境界線で分けると、守れないものがある。 サーバーだけでは 解決できない クライアントだけ でも解決できない 通信を減らす判断は クライアント側の協力が要る 整合性や公平性は サーバーが担保するしかない 体験を守るには両方を同時に設計する 境界ではなく体験を単位に考える 31 もう一つの大きな学びが、クライアントとサーバーを別々に考えない、ということです。 通信量を減らす判断ひとつ取っても、サーバーだけでは実現できず、クライアントの協力が要ります。 一方で整合性や公平性は、サーバーが担保するしかありません。 境界線で分けるのではなく、“体験”そのものを単位にして設計する。当たり前のようでいて、改めて大きな学びでした。 31

４ CHAPTER 『モンスターハンターワイルズ』 で得た知見 開発が進むほど また同じ問題が顔を出した モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network 32 第四章、『モンスターハンターワイルズ』で得た知見です。 開発が進むにつれて再発見する『似た課題』と、知識の属人化についてお話しします。 32

４．『モンスターハンターワイルズ』で得た知見 また同じ問題が出てくる タイトルが違っても、毎回必要になるものがある 認証 ロビー マッチング 通知 フレンド モバイルで見た “繰り返し” が、規模を変えてまたここにいた 33 結論から言うと、私たちはまた同じ問題に出会うことになりました。 認証、ロビー、マッチング、通知、フレンド。開発が進むにつれて、これらを一つずつ作っている自分たちに気付きます。 これらはタイトルが違っても、毎回必要になります。 覚えているでしょうか。第一章で、モバイル時代に“毎回似たものを作っていた”という話をしました。 あの繰り返しが、規模を大きく変えて、また目の前に現れたわけです。 しかも、規模が変わった分だけ、繰り返しのコストも跳ね上がっています。 同時接続100万人を支える認証やロビーは、モバイル時代と同じ作り方では通用しません。 つまり私たちは、同じ課題に、毎回より高い難度で挑み直していた。この構造そのものを、どうにかしないといけない。 そう考え始めたのがこの時期でした。 33

４．『モンスターハンターワイルズ』で得た知見 技術より厄介だったのは「知識の属人化」 ある人は知っていて、ある人は知らない 属人化 重要な知見が、特定の個人に紐づいてしまう チームやプロジェクトが変わると 積み上げたはずの知識が、引き継がれず途切れる 結果 再発 引き継げない 同じ失敗 同じ失敗を繰り返す これでは、組織として成⾧できない 34 しかし、技術的な繰り返しよりも厄介な問題がありました。『知識の属人化』です。 ある人は知っていて、別のある人は知らない。重要な知見が個人に紐づき、チームやプロジェクトが変わると、ぷつりと途切れてしまう。 結果、また同じ失敗を繰り返す。右の図のような悪循環です。 技術の問題以上に私たちを悩ませたのは、この“知識が残らない”という構造でした。 34

４．『モンスターハンターワイルズ』で得た知見 本当に必要だったのは「機能」ではない Q A 本当に必要なのは 必要だったのは “機能”なのか? 経験を残す仕組み 35 ここが、今日の話の転換点になります。 同じ機能を何度も作り、似た課題を繰り返し、そのたびに解き直している。では、本当に必要なものは何だったのか。 共通の“機能”をあらかじめ用意しておけば、この問題は解決するのだろうか。私たちも最初はそう考えました。 しかし、答えはノーでした。仮に機能を共通化しても、なぜその作りにしたのか、どこで失敗したのか、運用で何に苦しんだのか。 その理由が一緒に残らなければ、次のチームはまた同じ判断を一から繰り返してしまうのです。 本当に必要だったのは『経験を残す仕組み』でした。 失敗も、成功も、運用で得た知識も、個人ではなく組織に残っていく仕組み。ここから次の章に入ります。 35

５ CHAPTER ace.Network への昇華 経験を残す仕組みとして ace.Network は生まれた モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network 36 第五章、ace.Networkへの昇華です。タイムラインは、ついに一番右に到達しました。 第四章では、『経験を残す仕組みが必要』というところまでをお話ししました。 その一つの答えとして生まれたのが ace.Network です。 ここからは、それが何なのか、そして何を解決しようとしたのかをお話しします。 36

５．ace.Network への昇華 プロジェクト毎に最適なものを選んでいくというコンセプト AWS Google Cloud タイトルごとに、最適なクラウドと技術を選んできた 37 まず背景として、カプコンではプロジェクトごとに最適なクラウドや技術を選んできました。 例えば『モンスターハンターワイルズ』はAWS、『ストリートファイター6』はGoogle Cloud（GCP）です。 この考え方自体は、これからも大事にするのですが、 ただ、その自由度の高さは、新しいプロジェクトのたびに手探りで設計を進める状況を生むという事もあります。 前提がそろわないため、設計上の判断や運用で得た知見も、次のタイトルへ渡りきりませんでした。 37

５．ace.Network への昇華 毎回つくっていた土台を、一つの共通基盤へ タイトルA タイトルB タイトルC タイトルZ ace.Network 38 そこでace.Networkでは、毎回必要になる土台を共通基盤として整えました。 図のように、各タイトルはace.Networkを通じてAWSやGCPのサービスを利用します。 クラウドを選ぶ自由度は残したまま、その間に共通の土台を一枚挟む形です。 ここで土台を挟む狙いは、作業を減らすことではありません。 クラウドを構成するパーツは多く、タイトルに最適な形を組み上げるには毎回多くの判断が必要になります。 その判断をゼロからやり直していると、考える時間がゲームの面白さではなく土台づくりに吸われてしまう。 その状態を変えたい、というのが出発点でした。 38

５．ace.Network への昇華 土台には何を入れているのか ゲームは違っても繰り返し現れる部分を、共通の形で用意する ace.Network API 設計 タイトル間で 共通の考え方に スキーマ定義 定義からコードを 生成する形に エラーコード 定義と扱い方を 一元化 運用フロー 運用・サポートまで 同じ手順で 毎回つくり直していたものを、共通の形で 通信ライブラリではなく「知見の共有基盤」 39 では、その土台には何を入れているのか。 作品ごとにゲームは違っても、API設計、スキーマ、エラーコード、運用フローといった部分は、どのタイトルでも繰り返し現れます。 ここに『SF6』や『ワイルズ』で得たノウハウを反映し、どのタイトルからも同じ考え方で使える形にしました。 残しているのは、動く仕組みだけではありません。 なぜその設計にしたのか、どこで失敗し、運用で何に苦労したのか。その判断の理由まで含めて残す。 つまりace.Networkは、共通の基盤であると同時に『知見の共有基盤』です。 では、具体的に何を資産化しようとしているのかを例をみていきます。 39

５．ace.Network への昇華 コードではなく「知見」を資産化する 過去の失敗 過去の成功 運用の知識 繰り返さないための記録 再現するためのパターン 動かし続ける現場の知恵 品質の考え方 負荷試験のやり方 セキュリティの知見 守るべき基準の共有 検証手順そのものを資産に 守りの経験を組織知へ 40 例として六つ挙げます。 過去の失敗。二度と繰り返さないための記録です。 過去の成功。再現できるようパターンとして残すべきもの。 運用で得た知識。動かし続けた現場でしか得られない知恵です。 品質に関する考え方。どこまで守るべきかの基準を揃えます。 負荷試験のやり方。検証の手順そのものを資産にします。 そしてセキュリティの知見。守りの経験を組織の知見に変えていきます。 見ていただくと分かる通り、コードそのものは中心ではありません。含まれているのは“やり方”と“考え方”です。 ここからの具体例は、障害点、ガイドライン、セキュリティ、監視運用の四つに分けてお話しします。 40

５．ace.Network への昇華 具体例① 障害点を分ける リリース直後 ログインとマッチングにアクセスが集中する 分けない 分ける 一枚岩をまるごとスケール 負荷がかかったサービス のみをスケール モノリス （ログイン＋マッチング＋ゲーム） ×3 スケール単位は全体。使わない機能まで一緒に増える ログイン ×3 マッチング ×3 ゲーム ×1 スケール単位はサービス。 増やすのは負荷の高い2つだけ 分けてあれば、その2サービスだけをスケールすれば足りる どの責務を、どの単位で分けるか。その判断の型を残す 41 一つ目は、障害点をどう分けるか。です。 ace.Networkでは、マイクロサービスを採用しています。 採用理由は、単に今風だからではなく、障害が起きた時に影響範囲を切り離しやすくするためと、 負荷の高いサービスだけ個別にスケールできるようにするため、と整理しています。 たとえばリリース直後は、ログインやマッチングにアクセスが集中します。 その時、サーバー全体を一枚岩でスケールしていくのではなく、 必要なサービスだけリソースを増やせると、コストと安定性の両面で効果があります。 一般に、サービスを分けると、障害を局所化でき、性能要件に合わせた最適化や変更、リリースの単位を小さくできます。 一方で、サービス間通信や監視、障害調査は複雑になる。 だからこそ、どの責務をどの単位で分けるのか、その判断の型を残すことが重要です。 41

５．ace.Network への昇華 具体例② ガイドラインを標準化する 複数プロジェクト間で知見を横展開し、設計手法をドキュメント化して共有 サーバ運用 グループ PC版開発 グループ セキュリティ グループ 一貫した設計哲学を浸透 42 二つ目は、設計知見をガイドラインとして整え、標準化することです。 もともとは、口伝えや経験則でノウハウ共有することも多くありました。 ただそれだけでは、あるタイトルには伝わったが別のタイトルには伝わっていない、ということが起きます。 情報に時間差があり、誰が知っているかに依存してしまう。 そこで社内横断のワーキンググループを作り、有識者が定期的に集まって、 共通課題や新しい技術、過去タイトルの教訓を共有・議論する場を作りました。 最終的にそこから、設計手法や判断基準としてドキュメント化し、ガイドラインとして、参照できるようにしています。 42

５．ace.Network への昇華 いつまでに決める 必要があるか 必須で対応が必要か 43 ガイドラインには、対応が必須なのか、推奨なのか、いつまでに判断すべきか、といった情報も含めます。 単に『気を付けましょう』ではなく、開発フェーズの中で具体的な判断につながる形にする。 属人的な経験を、チームやプロジェクトを越えて使える判断材料に変えるのが目的です。 43

５．ace.Network への昇華 具体例③ セキュリティを開発フローへ 設計 実装 リリース 運用 セキュリティ要件を 静的解析と 依存ライブラリの確認 を仕組みに組み込む クラウドの検査を 活用する （AWS Security Hub・GCP SCC） 継続的に 見続ける体制へ （次ページへ） 最初に決める 全フェーズを通じて:判断を記録する ― なぜ更新し、なぜ見送ったか あとから頑張るのではなく、日常の開発と運用に組み込む 44 三つ目は、セキュリティ対応です。 パッチを当てる、当てないという判断は、各担当者の経験だけに任せるとばらつきます。 そこで、担当者が見るべき範囲を明確にし、静的解析や依存ライブラリのバージョン確認を仕組みに組み込み、 古いバージョンを使い続けないようにする。 セキュリティ対応を個人の注意力だけに頼らず、開発フローの中で自然に気付ける状態に近づけます。 44

５．ace.Network への昇華 日々の脆弱性監視への取り組み 日常的にタイトル間でも セキュリティ事象を 共有・対処する体制を構築 45 さらに、日々の脆弱性監視も習慣化しています。 よく使うパッケージの一覧を作り、脆弱性が出ていないかを継続的に確認する。 AWSのSecurity HubやGCPのSecurity Command Centerのようなクラウドのサービスも活用しますが、 それだけに任せず、社内で情報を共有し、タイトルごとにどう判断したかを残します。 たとえば、ある脆弱性にすぐ更新したのか、影響範囲を確認して見送ったのか、その理由を残しておく。 別タイトルで同じ判断に直面した時に参考にできます。 セキュリティを『あとから頑張るもの』ではなく、日常の開発・運用に組み込むことを目指して日々アップデートしていく形です。 45

５．ace.Network への昇華 具体例④ 監視運用を標準化していく これから進める取り組み 現在 タイトルごとに ばらばら ログ・メトリクス・トレー スの取り方がタイトルごと に違う 標準化 効果 OpenTelemetry で 計測を統一 どのタイトルでも 同じ手順 観測データの表示方法/アラート の共通化 同じ手順で調査でき、障害 時の初動が早くなる 観測の出し方を揃え、運用負荷を下げていきたい 46 四つ目は、監視運用のコストを下げる取り組みです。 ここは、すでに完成しているものというより、これからさらに進めていきたい領域です。 OpenTelemetryを使ってメトリクスやトレースを共通の形で送れるようにし、 将来的には監視項目、ダッシュボード、アラート閾値の設定手法まで、 タイトルごとにばらばらになりすぎないよう整理していきたいと考えています。 クラウドの発展や処理性能の向上で、かつてはタイトルごとに個別最適していた監視も、共通化できる余地が広がっています。 観測データの出し方を揃えると、障害調査の初動が早くなり、担当者が変わっても同じダッシュボード、同じ指標で状況を確認できる。 アラートの考え方を揃えれば、過剰な通知や見落としも減らせます。 46

５．ace.Network への昇華 知見の上に「ガイドライン」と「設計思想」を重ねる ガイドラインも基盤の一部になった 「どう作るべきか」の指針を、共有資産として残す 設計思想そのものを再利用する 個別の実装ではなく、判断の“型”を受け渡す 便利だからではなく、 繰り返さないため 設計思想 高 ガイドライン 運用・品質の知見 コード / SDK 目的は効率化ではなく、失敗の再発防止 低 再利用価値 47 ここまでの具体例に共通しているのは、機能や手順だけでなく、判断基準まで残そうとしている点です。 その判断基準を使いやすい形にしたものがガイドラインであり、そのさらに上にあるのが設計思想です。 ace.Networkで再利用したいのは、コードだけではなく、「どう作るべきか」という考え方そのものです。 右の図は、その関係を表しています。下の層は実装を助け、上の層は判断を助ける。 上に行くほど、タイトルや技術が変わっても再利用しやすい価値になります。 つまり、知見を読むだけのものにせず、設計やレビューの中で自然に使われる状態にする。 ここまでの取り組みは、そのための土台作りです。 47

６ CHAPTER 組織への知識共有 モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network 48 第六章、組織への知識共有です。経験を組織の資産にする『文化』づくりと、今日のまとめについてお話しします。 48

６．組織への知識共有 今日の主役は、タイトルではない 個人の経験を、組織の言葉にする 暗黙知を、共有できる形へ翻訳する 主役は 「経験を資産化する文化」 タイトルは、その文化を 育てるための舞台だった 次のチームが、失敗からではなく 知見から始める ゼロからではなく、蓄積の続きから走り出せる 文化になれば、人が変わっても残る 属人化の逆――経験が組織に根づく 49 今日一番お伝えしたいメッセージです。 この物語の主役は、特定のタイトルではありません。『経験を資産化する文化』そのものです。 それぞれのタイトルは、その文化を育てるための舞台でした。 個人の経験を組織の言葉に翻訳し、次のチームがゼロからではなく、蓄積の続きから始められるようにする。 文化として根づけば、人が入れ替わっても、技術が変わっても、経験は組織の力として残り続けます。 49

６．組織への知識共有 一言でいうと、こういう物語 モバイル SF6 モンハンワイルズ ace.Network 気付いた 実現した 磨き上げた 資産化した この一本の流れこそが、私たちが今日たどってきた道のりです 50 そろそろ、この講演のまとめに入ります。 今日の話を改めて一言で表すと、こうです。 モバイルで、課題に気付いた。 そして、『ストリートファイター6』で、つながる体験を実現した。さらに、『モンスターハンターワイルズ』で、それを磨き上げた。 その上で ace.Network で、資産化した。 冒頭のタイムラインが、ここで一つの物語として完成しました。 50

６．組織への知識共有 まとめ 私たちが本当に作ってきたもの 作ってきたのは サーバーではない 共通基盤そのものが目的ではない 本当に作ってきたのは 経験を再利用する 仕組み 51 そして、伝えたい結論です。 私たちが本当に作ってきたのは、サーバーではありません。 『経験を再利用する仕組み』です。 51

６．組織への知識共有 まとめ 私たちが本当に作ってきたもの 作ってきたのは サーバーではない 共通基盤そのものが目的ではない 本当に作ってきたのは 経験を再利用する 仕組み 技術は変わる。クラウドも、タイトルも変わる 手段は、時代とともに移り変わっていく けれど、経験は残せる 残す仕組みさえあれば、経験は消えない 52 技術は変わります。クラウドの構成も、使う言語やタイトルも、数年経てば別のものになっているでしょう。 今日お話しした手法も、いずれ古くなるはずです。 ただし私たちは、共通基盤を作りたかったのではありません。 52

６．組織への知識共有 まとめ 私たちが本当に作ってきたもの 作ってきたのは 何のために ― サーバーではない 本当に作ってきたのは 経験を再利用する 仕組み 各チームが、自分たちのゲームを 面白くすることに時間を使えるように 技術は変わる。クラウドも、タイトルも変わる 共通基盤そのものが目的ではない 手段は、時代とともに移り変わっていく けれど、経験は残せる 残す仕組みさえあれば、経験は消えない 53 ゲームごとの面白さに集中するために、毎回繰り返していた基盤の悩みを減らしたかった。 そのために、機能だけでなく、判断の理由、失敗の記録、運用の知見まで残す必要がありました。 あのとき何に困り、何を捨てる判断をし、その結果どうなったのか。それは技術が変わっても価値を失いません。 モバイルで得た運用の苦労、『SF6』で整えた契約、『ワイルズ』で磨いた大規模オンライン設計、ace.Networkで仕組みにした知見。 これらは別々の話ではなく、経験を次に渡すための連続した取り組みでした。 この十数年でたどり着いたのが、この考え方でした。だからこそ私たちは、今日も基盤を作り続けています。 53

経験を残せる組織は、強くなる モバイル 『ストリートファイター6』 『モンスターハンターワイルズ』 ace.Network ご清聴 ありがとうございました 54 最後のメッセージです。 「経験は、残せる。そして経験を残せる組織は強くなる。」 今日はRE ENGINEと共存する、サーバーの設計思想と基盤化のプロセスについてお話ししました。ご清聴、ありがとうございました。 54