モンスターストライクで、障害の⼀次調査を New Relic Autopilot に任せてみた

本資料は、2026年9月16日に開催された「New Relic AI機能やってみたLT＆事例共有ナイト by NRUG Vol.19」における発表資料です。
https://nrug.connpass.com/event/399917/

Transcript

1. モンスターストライクで、障害の⼀次調査を New Relic Autopilot に任せてみた 株式会社MIXI ⼭⽥ 隼⼈ ©MIXI
2. 登壇者紹介 名前 ⼭⽥ 隼⼈ 所属: デジタルエンターテインメントオペレーションズ本部 モンスト開発部 モンストサーバ1グループ 担当業務: アプリケーションの機能開発‧運⽤、AI 活⽤の推進 ©MIXI 2
3. MIXI について ©MIXI
4. 豊かなコミュニケーションを広げ、 世界を幸せな驚きで包む。 「⼼もつながる」場と機会の創造。 ユーザーサプライズファースト 発明 / 夢中 / 誠実
5. About BUSINESS DIGITAL ENTERTAINMENT デジタルエンターテインメント 事業 LIFESTYLE SPORTS ライフスタイル事業 スポーツ事業 and more...
6. ひっぱりハンティングRPG モンスターストライク 6 誰でも簡単に楽しめる爽快アクションRPG。⼀緒にいる友だちと最⼤4⼈ まで同時に遊べる協⼒プレイ（マルチプレイ）が特徴です。 2013年10⽉の提供開始より多くのユーザーの皆さまにご利⽤いただき、 2026年8⽉末時点では世界累計利⽤者数が6,600万⼈を突破しました。
7. モンストのサーバーサイドアーキテクチャ ©MIXI
8. モンストを⽀える技術 13 周年を迎えるモンストの技術スタック • アプリケーション: Ruby の⼤規模なモノリス • データベース: MariaDB を利⽤し、垂直分割‧⽔平分割で負荷分散 • キャッシュ: Memcached で読み込み性能を向上 • インフラ: 主要コンポーネントをオンプレミスで運⽤ ©MIXI 8
9. サーバーサイドの主要コンポーネント The Ruby logo is Copyright © 2006, Yukihiro Matsumoto. MariaDB® and the MariaDB sea lion logo are trademarks of MariaDB plc. ©MIXI 9
10. ⼤規模トラフィックを捌くオンプレミス環境 SNS 「mixi」 で培ったインフラの知⾒を活⽤ • App / DB / Cache / Worker などがオンプレミス上で稼働 • イベント時の⾼負荷に耐えられるサーバーリソースを確保 • ワークロードに応じてマシン構成を調整 • ハードウェアから OS / ミドルウェアまでを管理 • 管理‧運⽤ツールはクラウドを利⽤ ©MIXI 10
11. アプリケーションの構成‧保守 サービス開始時からの構成を⼟台に、Ruby / Gem を継続的に更新 • 2026 年 7 ⽉現在、Ruby は 3.4 系 • Web フレームワーク: Padrino / ORM: ActiveRecord • 2025 年 11 ⽉から RBS‧Steep による型検査を導⼊ ©MIXI 11
12. モンストの開発スタイル ©MIXI
13. モンストのサーバーサイド開発の組織構成 モンスト(⽇本版) 怪物彈珠（繁体字版） 開発(モンストサーバ１グループ) 運⽤（旧モンストサーバ２グループ ）※現在は開発本部内に異動 ©MIXI 13
14. モンストサーバーサイドの開発スタイル 約1.5ヶ⽉で1バージョンを開発 サーバー対応がある施策はこのうち10~20個程度 企画 UI設計 実装 次バージョンへ ©MIXI QA リリース 14
15. モンストサーバグループの開発スタイル ©MIXI リリース頻度 1〜1.5ヶ⽉ 次期バージョンに関係しないも のは順次リリース リリースタイミング アップデートメンテナンス 15
16. エラーとの付き合い⽅ ©MIXI
17. モンストのエラーへの向き合い⽅ エラーは⽇々出続けている ex: ユーザーのいたずらによる不正リクエストなど エラーは「出たら即障害」ではない。 ⾒るべきものと、そうでないものが混ざって届く ©MIXI 17
18. ⽇々のエラー対象への修正の流れ エラー発⽣ ⼈の⼿で⼀次調査 原因の切り分け ©MIXI New Relicの Errors Inboxで確認 対処、反映 18
19. 今回の話について 今⽇の話 対象 エラー 範囲 検知されたエラーの原因の当たりをつけると ころまで 範囲外 障害対応そのもの ※現在はPoC中です。 ©MIXI 19
20. ⽇々の軽微なエラー対象への修正の流れ エラー発⽣ New Relicの Errors Inboxで確認 この部分を改善したい ⼈の⼿で⼀次調査 原因の切り分け ©MIXI 対処、反映 20
21. ⼀次調査の、何がつらいか 13年分の実装があり、原因の候補が広い 全部を⼈が⾒て判断するのは、現実的でない ここを AI に任せたい！ ©MIXI 21
22. New Relic Autopilotに任せてみた ©MIXI
23. 前提 今回の発表で使⽤したNew Relic Autopilotでは ‧GitHub接続を試していません。 ※弊社のポリシーとして、GitHubパーソナルアクセストークンの 払い出しを⾏えないため、GitHub接続を⾏っておりません。 ©MIXI 23
24. New Relic Autopilot とは 2026年6⽉発表 ∕ 旧称 SRE Agent オンコール担当の隣に座る、調査担当の AI エージェント • アラートが発⽕した瞬間から、⾃動で調査を始める • New Relic が持っているテレメトリを横断して、根本原因の候補を出す • ⼈は、出てきた結論とその根拠を読んで判断する ©MIXI 24
25. 試しに使ってみた Slackで実際にメンションをして聞いてみた New Relic [15:45] Working on your request! New Relic [15:48] Incident Investigation: Encoding::CompatibilityError 今回は、約3分で調査結果が返ってきました。 ©MIXI 25
26. どのような調査結果が来たか？(要約) Encoding::CompatibilityError について聞いた調査結果 • 分析対象: monsterstrike / 分析ウィンドウ 約8時間 • レスポンスタイムの劣化: 平均157ms（通常100ms未満）、ピーク1,828ms • 推奨アクション4点: i. アラートの発信元が本当にこのアカウントか確認してください ii. Sidekiq / 別の Rails 環境 / APM 未計装のサービスを探してください iii. ActiveRecord::ValueTooLong（raw_data カラム）を調査してください iv. force_encoding('UTF-8') で境界に防御を⼊れましょう ©MIXI 26
27. 実際どうだった Autopilot が出したもの 実際は レスポンスタイムの劣化 聞いていない。別の観測事実 ActiveRecord::ValueTooLong 別のエラー 「発信元を確認してください」 ⾒つけられなかった、の⾔い換え 「Sidekiq / 別の Rails 環境を探して」 ⾃分で計装の外を指している force_encoding('UTF-8') ⼀般的な Ruby 論。 このコードを⾒ていない Encoding::CompatibilityError が、どこで何をして起きたのか。 現状のモンストでは、読み取れなさそう ©MIXI 27
28. 今後、本利⽤を⽬指すには 今後、本利⽤にあたり精度を上げるには GitHubと連携し、実際のコードから読み取れるようにする 与えるクエリの説明の内容の精度を上げる があげられます。 ©MIXI 28
29. まとめ 今回、モンストにおいてNew Relic Autopilotを使⽤して、 実際のエラーで検証をしてみました。 結果、現状だとエラーの原因について 正しく発⾒することができませんでした。 今後、PAT以外の⽅法でもGitHub連携ができるようになると うれしいです。 ©MIXI 29
30. 参考 New Relic Autopilot overview — https://docs.newrelic.com/docs/agentic-ai/autopilot/overview/ New Relic Autopilot — https://newrelic.com/platform/newrelic-autopilot ©MIXI 30
31. ©MIXI
32. それ以外に、今後試してみたいこと 今後、 Workflow Automation New Relic AI Knowledge MCP Server といったツールも試していきたいと考えています。 ©MIXI 32