13年運用タイトルのサーバーサイドが辿り着いた現在地 ― モンスターストライクにおける技術・組織・AI活用から得た知見

本資料は、7/22から開催された #CEDEC2026 1日目 11:10からのレギュラーセッションにて登壇した、山田、水木、中森の発表資料です。
　
13年運用タイトルのサーバーサイドが辿り着いた現在地 ― モンスターストライクにおける技術・組織・AI活用から得た知見
https://cedec.cesa.or.jp/2026/timetable/detail/s6985bf5f48ea3/

Transcript

1. 13年運⽤タイトルのサーバーサイドが辿り着いた現在地 ― モンスターストライクにおける技術‧組織‧AI活⽤から 得た知⾒ 株式会社MIXI ⼭⽥ 隼⼈/⽔⽊健太郎/中森 亮介 ©MIXI
2. アジェンダ １. 登壇者紹介 ２. MIXI について ３.【技術の現在地】モンストのサーバーサイドアーキテクチャ ４.【組織と開発の現在地】歴史的経緯を持つ実装との共存戦略 ５.【AI活⽤の現在地】開発におけるAI活⽤の多⾓的な取り組み ６. ⻑寿タイトルの現在地と未来への視点 ©MIXI 2
3. 登壇者紹介 ©MIXI
4. 登壇者紹介 ⽔⽊ 健太郎 ⼭⽥ 隼⼈ 中森 亮介 所属: 開発本部 たんぽぽ室 モンストグループ 所属: デジタルエンターテインメントオペレーションズ本部 モンスト開発部 モンストサーバ1グループ 所属: デジタルエンターテインメントオペレーションズ本部 モンスト開発部 モンストサーバ1グループ 担当業務: アプリケーションの機能開発‧運⽤ AI 活⽤の推進 担当業務: アプリケーションの機能開発‧運⽤ AI 活⽤の推進 担当業務: インフラの構築‧運⽤ アプリケーションの機能開発‧運⽤ ©MIXI 4
5. MIXI について ©MIXI
6. 豊かなコミュニケーションを広げ、 世界を幸せな驚きで包む。 「⼼もつながる」場と機会の創造。 ユーザーサプライズファースト 発明 / 夢中 / 誠実
7. About BUSINESS DIGITAL ENTERTAINMENT デジタルエンターテインメント 事業 LIFESTYLE SPORTS ライフスタイル事業 スポーツ事業 and more...
8. 株式会社MIXIのセッション⼀覧 7/22（⽔）第1会場 11:10-12:10 7/23（⽊）第8会場 09:30-09:55 ⼿動テストケースをそのまま実⾏するVLMテスト実⾏ エージェント：モンストでの適⽤と検証結果 13年運⽤タイトルのサーバーサイドが 辿り着いた現在地 ― モンスターストライクに おける技術‧組織‧AI活⽤から得た知⾒ ⼭⽥ 隼⼈/⽔⽊ 健太郎/中森 亮介 7/22（⽔）第1会場 12:30-12:35 ©MIXI 松⾕ 峰⽣ 7/24（⾦）第1会場 12:42-12:47 7/23（⽊）第2会場 12:22-12:27 『モンスターストライク』の運営に伴⾛する！ データ⺠主化への 解析グループの3つのアプローチ 実践が先⽣だった— 新卒サーバーエンジニア1年⽬のリアル 脱Jenkins、インターン⽣が挑んだCIツール GitHubActions移⾏ 永沼 瑞穂 ⼭⽥ 隼⼈ 尾崎真央 8
9. ひっぱりハンティングRPG モンスターストライク 9 誰でも簡単に楽しめる爽快アクションRPG。⼀緒にいる友だちと最⼤4⼈ まで同時に遊べる協⼒プレイ（マルチプレイ）が特徴です。 2013年10⽉の提供開始より多くのユーザーの皆さまにご利⽤いただき、 2025年12⽉末時点では世界累計利⽤者数が6,500万⼈を突破しました。
10. 【技術の現在地】 モンストのサーバーサイドアーキテクチャ ©MIXI
11. モンストを⽀える技術の現在地 13 周年を迎えるモンストの技術スタック • アプリケーション: Ruby の⼤規模なモノリス • データベース: MariaDB を利⽤し、垂直分割‧⽔平分割で負荷分散 • キャッシュ: Memcached で読み込み性能を向上 • インフラ: 主要コンポーネントをオンプレミスで運⽤ ©MIXI 11
12. サーバーサイドの主要コンポーネント The Ruby logo is Copyright © 2006, Yukihiro Matsumoto. MariaDB® and the MariaDB sea lion logo are trademarks of MariaDB plc. ©MIXI 12
13. ⼤規模トラフィックを捌くオンプレミス環境 SNS 「mixi」 で培ったインフラの知⾒を活⽤ • App / DB / Cache / Worker などがオンプレミス上で稼働 • イベント時の⾼負荷に耐えられるサーバーリソースを確保 • ワークロードに応じてマシン構成を調整 • ハードウェアから OS / ミドルウェアまでを管理 • 管理‧運⽤ツールはクラウドを利⽤ ©MIXI 13
14. データベースの構成 MariaDB を複数 DB 構成で運⽤ • 垂直分割: テーブルを列単位で分割 • ⽔平分割: テーブルを⾏単位で分割 • ⼀部の DB は Read Replica で負荷を分散 • Primary 1 台 + Standby 2 台の冗⻑構成 ©MIXI 14
15. 読み込み性能を⽀える Memcached Cache-Aside パターンで DB 負荷を軽減 • TTL が 1 週間のユーザーデータも存在 • マクロでキャッシュ付きの検索メソッドと更新時の失効処理を⾃動⽣成 ©MIXI 15
16. Memcached のキャッシュプール 2 系統の Memcached プールを運⽤ • double-write で常に Standby プールのキャッシュを温める • Primary プールの障害時はプールごと⼊れ替える ©MIXI 16
17. アプリケーションの構成‧保守 サービス開始時からの構成を⼟台に、Ruby / Gem を継続的に更新 • 2026 年 7 ⽉現在、Ruby は 3.4 系 • Web フレームワーク: Padrino / ORM: ActiveRecord • 2025 年 11 ⽉から RBS‧Steep による型検査を導⼊ ©MIXI 17
18. オンプレからクラウドへ 20 周年を⾒据えて、フルクラウド化を推進 • オンプレミスの全サーバーを AWS へ移⾏ • 基本⽅針は リフト & シフト (⼀部のコンポーネントは先⾏して シフト) • データベースは MariaDB から Aurora へ移⾏ ©MIXI 18
19. まとめ: モンストを⽀え続ける技術基盤 モンストは素朴な構成を⼟台に運⽤‧改善を積み重ねている • Ruby の⼤規模モノリスを保守し続けている • DB の分割とキャッシュの組み合わせで⼤量のリクエストを捌いている • クラウドへの移⾏によってサービスの継続性を⾼めていく ©MIXI 19
20. 【組織と開発の現在地】 歴史的実装との共存戦略 ©MIXI
21. 私たちは誰で、どう開発をしているか ©MIXI
22. モンストのサーバーサイド開発の組織構成 モンスト(⽇本版) モンスト(繁体字版) 開発(モンストサーバ１グループ) ⼭⽥ 中森 運⽤（旧モンストサーバ２グループ ）※現在は開発本部内に異動 ⽔⽊ ©MIXI 22
23. モンストのサーバーサイド開発の組織構成 モンスト(⽇本版) モンスト(繁体字版) 開発(モンストサーバ１グループ) ⼭⽥ 中森 運⽤（旧モンストサーバ２グループ ）※現在は開発本部内に異動 ⽔⽊ ©MIXI 23
24. モンストサーバーサイドの開発スタイル 約1.5ヶ⽉で1バージョンを開発 サーバー対応がある施策はこのうち10~20個程度 企画 UI設計 実装 次バージョンへ ©MIXI QA リリース 24
25. モンストサーバグループの開発スタイル 基本的に1案件1サーバメンバーが担当します。 ©MIXI 25
26. モンストサーバグループの開発スタイル 例： 真獣神化 「モンスト10周年における真獣神化実装担当者が 10年分の形態変化の設計をイチから作り直した話」 と題し過去に、MIXI TECH DESIGN CONFERENCE 2024で発表されています。 ©MIXI 26
27. モンストサーバグループの開発スタイル リリース頻度 1〜1.5ヶ⽉ 次期バージョンに関係しないものは 順次リリース リリースタイミング アップデートメンテナンス 1バージョンあたりの 機能開発Pull Request数 50〜100 程度 ひと⽉にマージされるPull Request量 100〜200 程度 ©MIXI 27
28. 現在地を数字で「掴む」 ©MIXI
29. 現在地を数字で「掴む」(2026年6⽉時点) モノレポ構成 Rubyコード⾏数(app/限定) 1 リポジトリ 138,083 ⾏ テストコード⾏数(Rspec) APIエンドポイント数 414,628 ⾏ 352 本 モデルファイル数 テーブル数 1,658 件 1,214 テーブル マイグレーションファイル数 Rakeタスク数 3,039 本 253 ⾏ テストコードはプロダクションコードの約3倍の量 ©MIXI 29
30. 歴史的経緯の現状 ©MIXI
31. なぜ「歴史的経緯」が⽣まれるのか • 13年分の仕様‧施策‧コラボの堆積 • 新機能開発と既存機能の仕様変更が同時並⾏ で⾛り続ける • 当時の最適解は、今の⽂脈では負債に⾒える ©MIXI 31
32. 実例：ストライカー招待のリニューアル 友達をゲームに招待し、招待が成⽴すると 招待者‧被招待者の双⽅に報酬が贈られる機能。 招待する⼈ 招待される⼈ 友達を招待 新規登録 or 復帰ログイン 招待成⽴ 双⽅に報酬を付与 ©MIXI 32
33. 実例：ストライカー招待のリニューアル この機能に2026年3⽉アップデートが⼊りました。 成⽴状態の招待をリセットする 同様の招待成⽴キャンペーンを実施したい。 前回成⽴済みユーザーも不公平が ないよう、今回の報酬対象に含めたい。 ©MIXI 33
34. 実例：ストライカー招待のリニューアル 成⽴状態の招待をリセットする →従来のままでは、できない 招待する⼈ 招待される⼈ 友達を招待 新規登録 or 復帰ログイン 招待成⽴ 双⽅に報酬を付与 ©MIXI 34
35. 実例：ストライカー招待リニューアル データをユーザーごとから毎年の招待施策ごとへの 管理へと改善 →複数開催も可能にする 旧ロジック全てを毎年の招待施策ごとの実装に → 今回の変更だけで数百⾏規模の変更 ©MIXI 35
36. 実例：ストライカー招待リニューアル 作り直しで「世代」がデータ構造に残る └ テーブル名に世代番号（2, 3…）が積もる └ コード上のモデルの名前と実データとの名前が ずれることも ◎ 実績ある仕組みが流⽤できる → 再稼働を短期‧低リスクでできる ✖ 世代番号の氾濫と名前のズレ → 可読性‧新⼈の学習コストの悪化 ©MIXI 36
37. 歴史的経緯をどう扱うべきか • 過去の経緯を辿ることは必要 過去の経緯に「⼿を⼊れない理由」にはならない • 継ぎ⾜しで逃げない → 作り直しを常に選択肢に⼊れる （⼿を⼊れる覚悟と、並⾛を畳み切る覚悟はセット） • 変更リスクの正体は「触ると別の所が動く」こと まず「どこが危ないか」の可視化が先決 ©MIXI 37
38. 改善が裏⽬に出たケースと教訓 ©MIXI
39. 改善が裏⽬に出たケース 1. 「あとで直す」前提の対応が、そのまま常設化した 2. 後付けの構造変更が、その後の実装にも影響を及ぼした 3. 改善のつもりの変更が不整合を⽣み、仕切り直しになった ©MIXI 39
40. ここからの教訓 戻せる形で出す → 変更は常に巻き戻せる設計にする 完了を急がない → 期限より影響範囲の⾒極めを優先する なぜを残す → 判断の理由をコード‧PR‧ドキュメントに明⽂化。 後から追えるようにする ©MIXI 40
41. 段階的な改善戦略の実践例 ©MIXI
42. 前提 我々にサービスを⽌める選択肢はない → 原則「⽌めずに、少しずつ作り変える」 全⾯リライトではなく、部分的な改善を積み重ねる →ただし、新規の開発や、既存実装への追加は常時ある ©MIXI 42
43. テストという安全網 本体の約3倍(41.4万⾏)、網羅率(カバレッジ)90.37%の テストが、これらの改変を可能に(2026年7⽉現在) だからこそ 動かしながらの⼤規模な改変にも踏み出せます。 ©MIXI 43
44. QA, 企画, クライアントと共⽤している開発⽤サーバーへの⼀定期間の反映 Ruby 3.4のバージョンアップ作業の運⽤ 本番リリース前に、QA, 企画, クライアントと共⽤して いる開発⽤サーバーに⼊れて、1.5ヶ⽉間運⽤ →テストによる品質確認だけでなく、開発環境での 実利⽤を通じて影響範囲を確認 ⇒Ruby 3.4化成功 ©MIXI 44
45. 「リファクタリングを⾏う」ということ ‧定義 プログラムの外部から⾒た振る舞いは変えず、 ソースコードの構造だけを整える作業のこと 既存機能に⼿を加える前には、 最初に「リファクタリング」から作業を始める ⇒ 常に「変化」に強くする ©MIXI 45
46. 組織としての取り組み ©MIXI
47. 品質保証とナレッジ化 ‧品質保証：レビュー観点を明⽂化＋機械チェック （静的解析‧型チェック等）を⾃動化 →Rubocop、RBS等は品質を⼀定に保つ ‧ナレッジ化：「なぜそうなっているか」を ⽂書‧コメント‧AI向けガイドとして残す →issueやコード本⽂、テストがそのまま「仕様」に ©MIXI 47
48. 暗黙知を「正式⽂書」にする 現状の問題点を隠さず「既知問題」として、 コード内部のドキュメントに明記。 ⇒ 根本原因∕暫定回避策∕触ると危ない範囲 を セットで記す 例：データの重複 環境ごとの構造のズレ 処理のまとまり⽅の弱さ ©MIXI 48
49. なぜそうするか 13年分の実装判断の多くは、当時の担当者の頭の中にしかない → 書かなければ、異動‧退職とともに知識は失われる 「ここは危ない」と分かっていれば、次に触る⼈が同じ 「暗黙知」に起因する問題にぶつからなくて済む → 事故を未然に防げる 原因が記録されていないと、誰かが触るたびに同じ調査から やり直しになる → 記録があれば、その時間を丸ごと節約できる ©MIXI 49
50. 撤去を「恒常業務」にする：背景 ⼀時的な施策は、恒常的に発⽣している →コラボは、毎回実装仕様が異なるので、 施策実施後は撤去される前提 「追加 → 撤去」のサイクルは、年間を通じて何度も回る →撤去を後回しにすると⼀時コードが積み上がり、コードベース が肥⼤化‧複雑化 撤去は「都度対応」ではなく、最初から「恒常業務」として設計 ©MIXI 50
51. 撤去を「恒常業務」にする：解決法 バージョンアップ開発に撤去作業も含めるようにした ⾃動化スクリプトで撤去対象の差分を検出‧削除 • ⼿順書で、誰が撤去しても同じ品質になるようにする • コミット規約で、撤去⽤の差分と分かるようにする 最近はAgent Skills化も進⾏中 DBの変更履歴は消さず、無効化して残す →過去の経緯を追跡可能にしたまま、運⽤からは切り離す ©MIXI 51
52. まとめ: 歴史的実装と共存するための組織的アプローチ • 少⼈数体制で⾼頻度リリースを回しながら、 13年分の歴史的経緯と向き合い続けている • 「戻せる形で‧急がず‧なぜ残す」を原則に、 テストという安全網を使いながら段階的に改善している • 暗黙知の⽂書化や撤去の恒常業務化など、 負債と付き合うための仕組みを組織的に整備している ©MIXI 52
53. 【AI活⽤の現在地】 開発におけるAI活⽤の多⾓的な取り組み ©MIXI
54. ⻑寿プロダクトが20周年を迎えるために、AIをどう使うか 課題：13年分の膨⼤な仕様とコードベースによる負担 • 過去の実装や仕様を全て捨て去ることは不可能 • ソースコード規模の増⼤は必然 • 歴史的経緯を持つ実装や仕様と向き合い続けるための レビュー‧調査‧定型作業の負担が年々増加 ©MIXI 54
55. ⻑寿プロダクトが20周年を迎えるために、AIをどう使うか ⼈間を直接的に置き換えるのではなく ⼈間が本質的な判断に集中するためにAIを使⽤ • AIによるレビュー⽀援 • AIによるトイルの削減 • サーバー開発を他職種と繋ぐAI活⽤ ©MIXI 55
56. AIによるレビュー⽀援 ©MIXI
57. GitHub PRタイトル‧descriptionのレビュー 背景が不⾜しているコード 時間が経つと、コード変更の意図が分かりにくくなる • ⻑期運⽤を前提としたプロダクトでは無視できない • 当時の状態 2024年の機能開発では約半数で説明が不⾜ • 「コードの意図を書かなくてもよい」という空気が存在 ◦ 新⼈が何気なく説明を書かないPRを作成してしまう • 説明不⾜を指摘することへの抵抗感 • ©MIXI 57
58. GitHub PRタイトル‧descriptionのレビュー 必要な情報が記載されているか をAIがチェック • テンプレートをベースに判定 • 結果は点数化し、⼀定点数を下回 るとPRにコメントを投稿して改善 を促す • AIによる注意を⾏い、⼈間による 注意は⾏わない ©MIXI 58
59. カスタムレビュアーによるAIコードレビュー Codex Cloudで提供される標準のコード レビュー機能には、⻑い歴史と複雑な仕 様に合わない部分が存在 • • ©MIXI パラメータ変更不可 ◦ 当時最新のGPT-5.5を使えない ◦ effortレベル変更不可 ◦ 情報量（model_verbosity）変更 不可 挙動の⼤幅なカスタマイズ不可 ◦ Agent Skills使⽤不可 ◦ ドメイン知識の注⼊がAGENTS.md くらいでしかできない 59
60. カスタムレビュアーによるAIコードレビュー 最新⾼性能モデルによる、モンスト特有の観点 が考慮されたAIレビュー codex-actionsベースのカスタムレビュアー作成 • コード規模に合わせてGPT-5.5 xhighを使⽤ ◦ 直近のGPT-5.6登場にも即座に適応 • モンスト特有の事情を考慮 ◦ 独⾃レビューAgent Skillsが動作 ◦ 重点的な確認が必要な項⽬について、AI向け の指⽰を追加可能 事前に主要な論点が整理されたAIによるコメン トが追加され、⼈間レビュアーの負担が軽減 ©MIXI 60
61. AIによるトイルの削減 ©MIXI
62. コーディング規約違反のAIによる⾃動修正 当時の状態 • コーディング規約に従っていない部分が1万件近く存在 • 新しく違反が増えているのではなく、古いものが年単位で放置 • 変更時の影響範囲が広く、機械的に修正できない違反も多い 放置するべきではないが、修正が⾯倒かつ直接的には価値 を⽣まないため、積極的には修正されない ©MIXI 62
63. コーディング規約違反のAIによる⾃動修正 AIによる半⾃動修正で規約違反ゼロへ 1. 2. 3. GitHub Actions上でCodexが規約違反コード を修正 Codexが⾃動でPRを作成 ◦ ⼈間がレビューする前提で、適度な差 分量のPRを作成 ⼈間がレビューし、問題なければマージ ◦ AIの修正が良くない場合、⼈間が修正 定期実⾏によって、コードが急速に改善 1万件→500件程度まで減少し、規約違反ゼロが現 実的に ©MIXI 63
64. Flaky test の判定とテスト再実⾏ 不安定なテスト発⽣時の流れ 実装には問題がないのに、特定のテストが稀に落ちる • ⼈間がログを⾒て、本当にFlaky testかどうか判断 • Flakyと判断した場合、⼈間がテストを再実⾏ • 必要に応じて、後から⼈間が修正対象として調査 • 直接的には価値を⽣まない仕事に⼈間の労⼒が使われる ©MIXI 64
65. Flaky test の判定とテスト再実⾏ 作業をAIによって⾃動化し、⼈間の労⼒を減少 Flaky test ⾃動判定‧再実⾏ ©MIXI 修正対象の調査Issue⾃動作成 65
66. サーバー開発を他職種とつなぐAI活⽤ ©MIXI
67. おすすめツールの提案 要望から適切なツールをAIが提案 • 「Gimlet」と呼ばれる開発⽤の 検証ツール群には、企画‧QA向 けツールが⼤量に存在（約200 個） ◦ 本番環境以外でのみ使⽤可 • ⼈間がツールを探すための時間 を削減し、効率化 ©MIXI 67
68. AI Agentから使⽤しやすいOpenAPIを整備 既存の⼈間向け検証ツールを、AI Agentか らも扱いたい • • • サーバーエンジニア以外も、AIを使って開発 効率化を進⾏中 MIXIには、エンジニア以外の職種でもAIを 使って⾃分たちの作業を⾃動化しようとする 「DIY⽂化」がある ⼈間向けUIだけでなく、AIから扱いやすいAPI に対する需要 既存の⼈間向けツール実装からOpenAPI Specを⾃動⽣成できる仕組みを、⼀部ツー ルにて導⼊ ©MIXI 68
69. 企画職が持つ情報を、エンジニア向け情報へ変換 • 企画職が持つスプレッドシートには有⽤な情 報があるが、⼈間が読むための構造であり監 視‧分析基盤と繋げにくい • AI登場以前は⼈間がスプレッドシートを読 み、⼿⼊⼒でエンジニア向けデータを作成 • ⼈間が読むことを前提とした構造 現在はAIがスプレッドシートを読み エンジニア向けに扱いやすい形式へ⾃動変換 • GrafanaやNew Relicと連携し、負荷予測や 負荷分析に活⽤ マシンリーダブルな構造 ©MIXI 69
70. ⻑寿タイトルの現在地と未来への視点 ©MIXI
71. 3つの視点から⾒えてきたこと 技術的な積み重ねと、それを⽀える組織⽂化 過去の選択を活かしながら新しい技術にも投資する姿勢 運⽤の現場から⾒た、ゲーム開発の未来 ©MIXI 71
72. 3つの視点から⾒えてきたこと 技術的な積み重ね 「巨⼤なテスト資産」が、安⼼ して変更できる⽂化を⽀える 素朴な構成と 実装の3倍の テスト資産 「浮いた⼈的リソース」を、 品質投資へ還元 改善は、改善を呼ぶ 歴史と向き合う開発⽂化 戻せる‧急がない‧なぜ を残す ©MIXI 「なぜ」を明⽂化する⽂化が、 AIの読めるコンテキストになる AIによるトイル削減 ⼈間は本質的な判断に 集中する 72
73. 改善を⽌めないことが、 「⼼もつながる」場と機会 を創り出す「原動⼒」になる 13年分の歴史も、これからも。より⾼い熱量で、続いていく... ©MIXI 73
74. ©MIXI