League of Legends Preparation Room[MCPネイティブ競技情報意味生成システム]

Transcript

1. eスポーツ対戦準備室 eSports Preparation Room MCPネイティブ競技情報意味生成システム 発明レポート v1.0 2026年3月 Higurashi AI × API による競技データの意味生成
2. eスポーツ対戦準備室 — 発明レポート 1. エグゼクティブサマリー 本レポートは、eスポーツ領域における「対戦準備室 / 相手分析室」の発明構想から実証までの全過 程を記録するものである。 この発明の核心は、「競技データを“見る場所”から“判断を返す場所”に変える、文脈接続型の戦略 生成装置」にある。既存のトラッカー（OP.GG等）が統計の「気象観測所」であるのに対し、本発明は 「天気予報」を返す。観測データを見せるのではなく、データから導かれる判断と行動指針を返す。 技術的には、Riot Games APIとパッチノートをそれぞれ独立したMCPサーバーとして実装し、LLM がこれらを束ねて「コーチレベルの対戦準備ブリーフィング」を自動生成する。Phase 0（モックデータ 検証）からPhase 2（パッチノート自動取得）まで段階的に構築し、JPサーバーのマスター帯アマチュ アプレイヤー5名の実データで、Phase 0のモックデータと遜色ない品質のブリーフィング生成に成功 した。 2. 中心思想 2.1 AI × API 思想 本発明の根底にある思想は以下の3点である。第一に、APIはインターネットにおける最も偉大な発 明であり、世界の機能やデータを「接続可能な部品」にした。第二に、AIはその部品群に意味を与 え、選び、束ね、優先順位をつけ、実行に変える頭脳である。第三に、AI時代の勝者は高性能モデ ルを持つ者ではなく、多様な外部システムに接続し、それらを知的に束ねて価値に変えられる者であ る。 2.2 MCPの位置づけ MCP（Model Context Protocol）は「AI時代のソケット」として、LLMが外部データソースに接続するた めの共通規格である。ただし、MCPそのものが発明なのではなく、MCPを土台にして何を接続し、ど う束ね、どんな知的装置を作るかが発明の本体である。 2.3 統計と文脈の接続 「統計こそが最強の学問である」という言説を、eスポーツ領域においてAI × APIでさらに強化する。 ただし単なる数字信仰ではなく、統計と文脈の接続、パッチとプレイ傾向の接続、選手の履歴と今の 選択の接続、競技データと配信・観戦体験の接続が本質的な価値を生む。つまりこの発明は「スタッ ツ可視化」ではなく「競技情報の意味生成機」である。 3. 課題定義 本発明が解く課題は5つある。第一に、データが多すぎて人間が咀嚼しきれない。第二に、既存トラッ カーは「見る場所」であって「判断を返す場所」ではない。第三に、コーチや配信者は統計と文脈をつ なぐのに時間がかかる。第四に、相手分析や対戦準備は数字だけではなく最近の変化や癖の解釈 が必要。第五に、観戦者や解説者も「何が重要か」を絞ってほしい。 4. ターゲットユーザーの検証 2
3. eスポーツ対戦準備室 — 発明レポート 開発過程で2つのユーザー層を実データでテストし、ターゲットの妥当性を検証した。 評価軸 プロ選手（T1テスト） アマチュア（JPテスト） 判定 チャンピオンプールの偏 り 10試合で7〜9体（分散） 最頻3試合以上が5/5名 アマチュア優位 ロール外ピック 多数混入 8/50試合（許容範囲） アマチュア優位 ソロキュー≒対戦傾向 不一致（練習用途） 一致 アマチュア優位 ブリーフィング品質 大幅低下 Phase 0と同等 アマチュア優位 結論として、セミプロ/アマチュアチームの対戦準備がMVPの最適ターゲットであることが実データで 裏付けられた。プロ選手のソロキューデータは公式戦の傾向を反映しないため、プロ向けの分析に は別のデータソース（スクリムデータ等）が必要である。 5. システムアーキテクチャ 5.1 全体構成 システムは3つの独立したコンポーネントで構成される。「riot-match-analyzer」MCPサーバーがRiot APIから選手データを取得・前処理し、「patch-context」MCPサーバーがパッチノートを自動取得・構 造化する。LLM（MCPクライアント）がこれら2つのデータソースを統合し、ドメイン知識ルールとワー クフローに従ってブリーフィングを生成する。 5.2 MCPサーバー: riot-match-analyzer Riot Games APIをラップし、LLMが消費しやすい形にデータを前処理（剪定）して返すサーバー。 Match-v5の1試合30〜50KBの巨大レスポンスを、対象プレイヤー1名分の2〜5KBの要約データに 圧縮する。Data Dragonからチャンピオン名・アイテム名の変換を行い、コアアイテム抽出ロジック （靴・ワード・ポーション除外）を内蔵する。 ツール名 入力 出力 get_player_profile Riot ID + routingCluster 直近10試合のプロファイル（チャン ピオンプール、勝率、KDA、ビル ド、visionScore） get_team_profile 5名分のRiot ID 5名のプロファイル + チームサマ リー（試合時間帯別勝率） 5.3 MCPサーバー: patch-context Riot公式パッチノートページ（HTML）からチャンピオン/アイテムの変更情報を自動抽出し、構造化 JSONとして返すサーバー。cheerioによるセマンティックHTMLパース（CSSクラス名非依存）を採用 し、changeTypeの簡易判定（矢印前後の数値比較＋フィールド種別判定）を内蔵する。パース品質 をparseStatusフィールド（full/partial/fallback）で通知するフォールバック設計を持つ。 パッチ26.5での検証結果：parseStatus=full、14チャンピオン全抽出、changeType一致率87.5%、 JSONサイズ11.8KB。 5.4 推論レイヤー: ドメイン知識ルールとワークフロー 3
4. eスポーツ対戦準備室 — 発明レポート LLMの推論品質を担保する2つのファイルがシステムの知的基盤を形成する。「 lol_analyst_rules.md」はパッチ解釈の規則、選手傾向の読み方、BAN/PICK仮説の立て方、チーム 編成の傾向推定、出力の品質規則を定義する。「opponent_analysis.md」は推論のステップ順序と 出力フォーマットを定義する。これらは「LLMの頭の良さ」を決定する最も重要な資産であり、MCP サーバー（手足）とは独立して反復改善が可能である。 6. 開発プロセスと検証結果 6.1 Phase 0: モックデータ検証 目的：LLMがコーチレベルの分析を返せるかを、API接続なしで検証する。架空のアマチュアチーム5 名分のモックデータ（意図的に特徴を仕込んだJSON）とパッチデータを作成し、ドメイン知識ルール とワークフローに従ってブリーフィングを生成させた。 結果：5つの成功基準をすべてクリア。特にBAN推奨の「サイオンBANでマルファイトを誘導し、バフ されたサイラスをカウンターとしてぶつける」という戦略的提案は、統計の羅列からは出てこない発明 の核心が機能している証拠となった。 6.2 Phase 1: Riot API MCPサーバー構築と実データ検証 riot-match-analyzerを構築し、2段階のテストを実施した。T1テスト（プロ選手5名）では、ロール外 ピックのノイズが多すぎて有用なブリーフィングを生成できなかった。しかしLLMの推論品質自体は 落ちておらず、原因はデータの性質にあることが判明した。JPアマチュアテスト（マスター帯5名）で は、Phase 0と同等の品質のブリーフィングが生成され、本発明のターゲット層での実用性が証明さ れた。 6.3 Phase 2: パッチコンテキスト自動化 patch-contextサーバーを構築し、手動で行っていたパッチJSONの作成を自動化した。パッチ26.5で 14チャンピオン全抽出、changeType一致率87.5%を達成。これにより「Riot ID 5つ入力→ブリーフィ ング出力」のパイプラインから手動ステップがほぼ排除された。 7. 主要な発見と知見 7.1 出力品質の決定要因 ブリーフィングの品質を決定する最大の要因はLLMの性能でもMCPの設計でもなく、「誰のデータを 分析するか」であった。同一のルール・ワークフロー・LLMを使用しても、入力データの性質によって 出力品質は劇的に変わる。この知見は、ターゲットユーザーの選定がプロダクト設計において最も重 要な判断であることを示している。 7.2 MCPネイティブ設計の価値 2つのMCPサーバーを独立して構築・テスト・改善できるモジュラー設計は、開発効率と保守性の両 面で有効だった。riot-match-analyzerの構築中にpatch-contextに一切触れる必要がなく、逆も同様 であった。将来のデータソース追加（Twitch配信情報、Discord連携等）も「MCPサーバーの追加」と して実装できる拡張性が確保されている。 4
5. eスポーツ対戦準備室 — 発明レポート 7.3 前処理（剪定）の重要性 Riot APIの生データをそのままLLMに渡すのではなく、MCPサーバー内で前処理（剪定/Pruning）を 行い、1試合30〜50KBのデータを2〜5KBの要約データに圧縮する設計が出力品質の安定に直結 した。LLMのコンテキストウィンドウは有限資源であり、その効率的な利用がシステム全体の性能を 決定する。 8. 既存サービスとの差別化 比較軸 OP.GG / U.GG Mobalytics Oracle's Elixir 本発明 主な出力 統計値・ビルド 個人パフォ指標 プロシーン統計 判断と仮説 パッチ連動 勝率推移表示 一部連動 パッチ間比較 パッチ×相手×戦術 の三点接続 対戦準備 なし なし 手動で可能 自動ブリーフィング 生成 ユーザーの作業 自分で読み解く 自分で読み解く 自分で読み解く AIが解釈を返す 9. リスクと課題 第一に、差別化の持続性。OP.GGやMobalyticsがAI機能を追加するのは時間の問題であり、「AIで 分析する」というだけでは差別化が持続しない。持続的な差別化は「MCPによる拡張性」と「ユー ザーがプライベートデータを接続できること」にある。第二に、API利用規約。Riot APIの再配布制限 とMCPサーバーの関係はグレーゾーンであり、プロダクションキー取得時にRiotの審査を通す必要 がある。第三に、パッチごとのHTML構造変化。patch-contextのパーサーはセマンティックタグに依 存しているが、Riotがサイト構造を大幅に変更した場合はメンテナンスが必要になる（ただしfallback 設計により完全な機能停止は防がれる）。 10. 今後の展開 統合テスト: 2つのMCPサーバーをCline/Claude Desktopに接続し、「Riot ID 5つ入力→ブリーフィン グ出力」を1回のプロンプトで実現する。パッチJSONの手動作成が不要になったことを実証する。 プライベートデータ統合（Phase 3）: 自チームのNotionメモ、Discordチャット、Markdownファイルを MCPサーバーとして接続し、「公開データ＋プライベートデータ」の統合分析を実現する。これがWeb トラッカーとの決定的な差別化要因になる。 配信者向け出力モード: 対戦準備ブリーフィングに加え、「試合プレビュー」「メタ変動レポート」「配信 用注目ポイント」など、Tier 2ターゲット（配信者・解説者）向けの出力モードを追加する。 11. 結論 本発明は「プロダクト」としては筋が良く、「発明」としての核心である「AIがeスポーツの統計を人間の コーチレベルで読み解き、行動可能な判断を返す」機能がJPアマチュアプレイヤーの実データで実 証された。 5
6. eスポーツ対戦準備室 — 発明レポート 品質の序列は Phase 0（モック）≒ JPアマチュア（実データ）>> T1（プロ・実データ） であり、これは 本発明がターゲット層（アマチュア〜セミプロ）において実用レベルの価値を提供できることを意味す る。 MCPネイティブなモジュラー設計により、データソースの追加・入れ替えが容易であり、LoL以外のタ イトル（Dota 2等）への展開や、プライベートデータ統合による差別化強化が設計上の変更なく実現 可能である。 この発明は「AI × APIの知的束ね」という思想を、eスポーツの対戦準備という具体的なドメインで実 証する作品である。 6