AIエージェントで加速する開発と意思決定：ナレッジ蓄積型AIエージェントと対話型KPI分析の最前線

"━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  　　MIXI MEETUP！AI DAY 2026 - SESSION ARCHIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

AIエージェントで加速する開発と意思決定：ナレッジ蓄積型AIエージェントと対話型KPI分析の最前線
　
AIエージェントによって開発と意思決定を加速する実践事例を紹介。Claude Codeを活用した調査・レビュー・PR作成の伴走では、組織ナレッジを蓄積し成長するAIエージェントの設計と現時点の到達点を共有します。さらに、Geminiを用いたSlack上での対話型KPI分析により、データに基づく迅速な意思決定を実現する組織的アプローチを解説します。
　
モンスト開発部/クライアント2グループ/クライアント1チーム
川端 恭広

モンスト運営部/解析グループ/解析チーム
北島 祥伍

────────────────────────────
□セッション情報
https://mixi.connpass.com/event/380889/
□イベントハッシュタグ
#miximeetup2026
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　
◇◆◇ Information ◇◆◇
◎ エンジニアSNS/メディア
X（旧Twitter）
https://x.com/mixi_engineers
MIXI Developers Blog (medium)
https://mixi-developers.mixi.co.jp/
Slide (SpeakerDeck)
https://speakerdeck.com/mixi_engineers/
　
◎デザイン職メディア
MIXI DESIGN note
https://note.com/mixi_design/
MIXI DESIGN Cocoda
https://cocoda.design/teams/mixi-design
Slide (SpeakerDeck)
https://speakerdeck.com/mixi_design/

◎採用情報
https://mixigroup-recruit.mixi.co.jp/

HP
https://mixi.co.jp/
X
https://x.com/mixi_PR
connpass
https://mixi.connpass.com/"

Transcript

1. ©MIXI ©MIXI AIエージェントで加速する開発と 意思決定 ナレッジ蓄積型AIエージェントと対話型KPI分析の最前線 モンスト開発部 川端 恭広 / モンスト運営部 北島 祥伍 デジタルエンターテインメントオペレーションズ本部
2. ©MIXI ©MIXI レガシーC++コードベースで AI開発に取り組んだ話 〜 3つの壁と、その乗り越え方 〜
3. ©MIXI ©MIXI ①背景 モンスターストライクのコード C++11 / Cocos2d-x v2.x レガシーゲームエンジン 約1,200ファイル 10年超の歴史 手動メモリ管理 retain / release パターン クロスプラットフォーム iOS / Android / Windows → 独自の設計パターン・命名規則・メモリ管理の流儀がある
4. ©MIXI ©MIXI ①背景 AIをそのまま使うと起きること AI 「分かりました。実装しますね」 ▼ コードに落とすと… モンストの法則に従っていない 原因: AIの一般知識 と プロジェクト固有情報 の乖離
5. ©MIXI ©MIXI 壁 ① AIの常識 ≠ モンスターストライクの法則 AIの知識 • モダンC++ • 一般的な設計パターン • 標準ライブラリ GAP モンストの法則 • 独自命名規則 • 独自設計パターン • 手動メモリ管理 → 会話では合意できるが、コードに反映されない
6. ©MIXI ©MIXI 解決 ① 対話→リサーチの反復ループ よくあるイメージ: リサーチ → 設計 → コーディング 実際に効果があった方式: ( 対話 → リサーチ ) を繰り返す ← ギャップを埋める ▼ 十分縮まったら リサーチ → 設計 → コーディング ポイント 1回の調査ではAIはモンスト の法則を十分に理解できない 何回かループを回してギャップ を縮めてから設計に進む
7. ©MIXI ©MIXI 壁 ② 設計が収束しない A方式で実装 → うまくいかない ↓ B方式に変更 → うまくいかない ↓ C方式に変更 → うまくいかない ↓ A方式に戻る ← 堂々巡り！ 毎回、AIは 「新しい案」を出すが、 正解の判断基準を持っていない
8. ©MIXI ©MIXI 解決 ② 大原則の導入 各AIエージェントに「タスク固有の絶対ルール」を毎回注入 大原則（プロンプト） 【大原則】 タスク固有の絶対ルール 【過去の失敗】 前回の失敗パターンと原因 【ユーザー指摘】 重要な指摘 【重要度】 温度感 ▼ 全エージェントに毎回注入 結果 AIが 「自由に考える」 ↓ 「ルールの中で考える」 ようになった
9. ©MIXI ©MIXI 壁 ③ 同じ失敗を繰り返す タスクA: ◦◦で失敗した ↓ セッション終了 ＜記憶リセット＞ ↓ タスクB: また同じ◦◦で失敗 人間なら 覚えているが、 AIには「記憶」がない
10. ©MIXI ©MIXI 解決 ③ 教訓（lessons_learned）の循環 タスクA完了 ↓ 記録 教訓ファイル 問題: ◦◦で失敗 原因: △△だったため 解決策: □□すべき タグ: #UI #スクロール ↓ 自動参照 タスクB開始 → 過去の教訓を検索 → 同じ失敗を回避 ポイント AIの「忘れる」 という弱点を 仕組みで補う タスクを重ねるほど 教訓が蓄積され 精度が上がっていく
11. ©MIXI ©MIXI ②プロセス この仕組み自体も試行錯誤だった ① ↓ 方向転換 自前チーム実験 設定が複雑。 本筋に戻る決断 ② ↓ 方向転換 claude --print 方式 3ヶ月運用、手応えを掴む → 2月: バージョンアップで動作不能に ③ エージェントチーム方式 標準機能で再構築。 現在も運用中 「反復・大原則・教訓」の本質は ツールが変わっても残った
12. ©MIXI ©MIXI ③成果 チームで使ってみた結果 ― フェーズ別有用性 10名が1〜4件以上の案件で使用、5段階で評価（N=10） 実装 3.7 ← 最も高い レビュー 3.3 設計 3.2 リサーチ 2.9 ← 評価が二極化 コミット/PR 2.8 リサーチの二極化: 5点と1点が混在 → 使い方次第で大きく効果が変わるフェーズ
13. ©MIXI ©MIXI ③成果 AIが有効だった案件 vs 向かなかった案件 ◎ 有効 • 既存案件の一部変更 • ひな型・テンプレ制作 • 小規模・定型案件 • 調査・バグの初動 △ 向かない • ゼロベースの新規実装 • インゲーム案件 • ネイティブ固有処理 ユーザーの声 「ガチャの共通部分を組んでもらったら、 自分で書くより早くてミスが少なかった」 「1つのバグを修正している間に、 別バグの調査をAIに任せられた」
14. ©MIXI ©MIXI ③成果 工数の実態（N=10） 工数の実感 40% 短縮 20% 変わらない 40% 判断できない コード修正度合い 40% 小規模修正 30% 案件による 30% 大幅書き直し 使用件数と工数の相関 使用件数 「短縮」割合 傾向 4件以上 75% 見極めた 3件 約35% 差が大きい 1〜2件 0% 手探り かかわり年数と工数の相関 年数 「短縮」割合 傾向 1年 100% 調査で恩恵大 4〜5年 約25% 人による 10年以上 約35% 自力が早い場面も 使い込むほど効果が上がる / 経験が浅い人ほどAI調査の恩恵が大きい
15. ©MIXI ©MIXI ③成果 見えてきた課題 課題（アンケート上位） 応答が遅い 約70% 的外れな調査結果 約50% 確認ステップが多い 約50% 教訓の不適切な適用 別案件の教訓を誤って適用 課題はあるが、仕組みの方向性は正しい → では、次に何をするか？
16. ©MIXI ©MIXI ③成果 次の一手: 教訓 → ナレッジベースへ進化 教訓17件 → 計80件のAIミス 既存パターン理解不足 18件 実装漏れ 14件 設計の方向性ミス 12件 → ドメイン別ナレッジベース 共通ルール（常時読み込み） 「既存の同種処理を3件以上調査」「独自実装禁止」 マスタデータ編 追加は必ず4箇所変更 インゲーム編 ステート初期化は3箇所必要 UI編 / ネットワーク編 / ... タスク開始 → 案件タイプ判定 → ナレッジ自動読込 ※ 構想段階。教訓分析で傾向は見えている → これから構築
17. ©MIXI ©MIXI まとめ: 3つの壁と解決策 壁 解決策 ① AIの常識 ≠モンスターストライク 対話→リサーチの反復 ② 堂々巡り 大原則の導入 ③ 同じ失敗の繰返し 教訓の循環 チームで使って分かったこと: 得意な案件を見極めて使い分けるのが現実解 使い込むほど効果が上がる 仕組みの方向性は正しい。精度を上げるフェーズへ AIは賢いが「知らないこと」と「忘れること」がある → そこを仕組みで補うのが鍵
18. ©MIXI ©MIXI 対話型KPI分析の最前線
19. ©MIXI ©MIXI 自己紹介 • 北島 祥伍（きたじま しょうご） • モンスト運営部 解析グループ ◦ モンストのデータ基盤を管理するエンジニアと、モンスト のデータ分析を行うアナリストで構成する部署 • 2019年よりモンストなどのデータ基盤の開発・運用に従事
20. ©MIXI ©MIXI Slack上でKPI分析ができるBotを開発しました 「@bot 昨日のDAUと売上は目標比でどう？」 「昨日のDAUはxx人で売上はxx円、目標を達成してるよ！　 ◯◯ガチャの売れ行きは好調だね！」 この問い合わせは、実際に毎日 KPIのモニタリングとして投稿して います。（実際のプロンプトはもう少し複雑です） NOTE
21. ©MIXI ©MIXI どうしてSlackなのか • 社内で最も日常的に使われているツールで、導入ハードルが低い • 専用のSlackチャンネルに招待すればすぐに使える • スレッドを活用して追加の質問ができるため、会話が続く • 会話がオープンに残るため、「自分も気になってた質問」が確認 できると同時に、活用の事例も参考にできる。
22. ©MIXI ©MIXI 利用者像 • 社内のモンスト事業に関わる人が使える • 約190人がbotと会話できるSlackチャンネルに参加中 • 直近30日で問いかけたのは31人、168回 • 雑談やお礼を除く111回のうち、 ◦ 新しいスレッドの開始は42回 ◦ スレッド内での追加質問は計69回 ◦ 単発の問い合わせで終わらず、追加の質問をする人が多い ただの問い合わせ窓口ではなく、しっかり深掘りをしている POINT
23. ©MIXI ©MIXI 開発のきっかけ • データの民主化（誰もが気軽にデータを活用できること） は、第四次AIブーム以前から、データを扱うものにとっては 継続的なテーマである。 • AIの思考力は飛躍的に向上している一方で、事業データを渡 せなければ活かしきれない。 • データの民主化を掲げるものとして、「AIを活かしたデータ 活用インターフェイス」を提供しよう • アナリストが行うような高度な分析をいきなり目指すのでは なく、一旦「日常的に確認するKPIを手軽に扱う」ことを目標 にする。簡単なところからまずはやってみよう精神
24. ©MIXI ©MIXI AIにデータを与えるとは AIは自分でデータを取得でき ないので、人間がデータを集 めて貼りつける。 Function Calling 以前 ツールの仕様をAIに渡してお く。AIは自分で必要に応じて 呼び出す。 Function Calling(2023) 今回のAIエージェントに用意したツールを紹介します NEXT
25. ©MIXI ©MIXI AIに渡しているツール KPIの値を返すツール • 「売上、DAU、MAUなどの主要なKPIの実績値と目標値」をはじ めとする厳選した7ツールを実装 • 概要を集計したJSONと日次の細かい値を収めたTSVがまとめて 入手できる • 取得したい期間を入れるだけで簡単に使える
26. ©MIXI ©MIXI なぜ全テーブルをAIに見せないのか Q: わざわざツールを丁寧に実装しなくとも、BigQueryのテーブル一 覧を見せてしまえばいいのでは？ • 何でも聞けるようにすると、不適切な集計がほとんど。 • BigQueryのテーブルメタデータはまだ人間向け、初見のAIには 難しい。そのためのコンテキスト付与も大変。 • それよりも、手が届く範囲で応答を確認しながらツールを追加 • 実務で安心して使えることを優先した結果
27. ©MIXI ©MIXI AIに渡しているツール 検索ツール • お知らせ検索ツール 　 モンストの公式サイトに載せている「お 知らせ」を検索できるツール。日付範囲を指定したり、検索ワー ドをあいまい検索できる。 • Lookerダッシュボード検索ツール 　 BIツール Looker にある ダッシュボードを検索できるツール。KPIツールで答えられない 質問に対してはダッシュボードを紹介する。
28. ©MIXI ©MIXI これらのツールを組み合わせて分析を行う 「@bot ◯月のDAUが盛り上がっていたときは、ゲーム内　 では何をやっていた？」 ｡o(◯月のDAUを取得⋯a日とb日を中心に盛り上がり） ｡o(お知らせを取得⋯a日からコラボ、b日に別のコラボ⋯） 「前半と後半に2つの山があります。a日から◯◯コラボ、 　b日から△△コラボを実施していました。」 数字だけでなく、施策情報を組み合わせた解釈つきで応答 POINT
29. ©MIXI ©MIXI 既存のダッシュボード(Looker)との違い • 単にKPIを見るだけならダッシュボードでもできる • 「その時何をやっていたか」は数値の推移からはわからない • 施策情報を検索して施策の文脈を付与し、数値の解釈が可能
30. ©MIXI ©MIXI アーキテクチャ メン シ ョン 問い合わせ function calling function calling Gemini KPI集計(BigQuery) 検索 (Vertex AI Search) 応答 転送 配 信 Cloud Functions Slack Cloud Functions Pub/Sub
31. ©MIXI ©MIXI 現在生まれている価値と今後 • 利用者はLooker上で目的のデータを探し回らず、チャットで気 軽に確認できる ◦ KPIツールで分かれば、すぐに応答。施策情報も一緒に参照でき る。 ◦ KPIツールになければ、近い目的のダッシュボードを返す ◦ ダッシュボードがなければ、アナリストに依頼 • 「みんなが何を知りたがっているか」がSlack上で可視化され、潜 在的な分析ニーズを拾いやすい • KPIツールを増やすのは限界があるのは事実。長年整備した LookerのExploreという資産を活用できるように検証中
32. ©MIXI ©MIXI