メルカリIBISの紹介

2025年9月17日にメルカリで行った「メルカリでのAI Agentの現在地を大公開っ」（https://mercari.connpass.com/event/366804/）というイベントで発表した内容です。

Transcript

1. 1 メルカリIBISの紹介 AI Agentによるインシデント対応の実践と学び
2. 2 自己紹介 oguma (@ktykogm) | 株式会社メルカリ • 現在: Platform Group Autonomous Cloud FinOpsチーム所属 • 過去: メルカリJP SREチーム（～2024年10月） • 専門領域: 信頼性・FinOps × AI/LLM活用 • 担当プロジェクト : IBIS（Incident Buddy and Insight System）のPM・開発 リード 今日お話しすること : AIエージェント開発の「リアルな学び」
3. 3 今日のアジェンダ 1. なぜIBISを作ったのか - 背景と課題 2. 何を学んだのか - 失敗と成功の両方 3. どう作ったのか - 技術選択と実装 4. どこに向かうのか - 今後の展望 テーマ: PoCから運用まで、リアルな試行錯誤の過程
4. 4 Part 1: なぜIBISを作ったのか メルカリのインシデント対応における 3つの課題 1. 属人化の深刻化 a. 特定メンバーへの依存 b. 知識の継承が困難 2. 効率性の問題 a. 過去事例の検索に時間がかかる b. 類似ケースの発見が困難 3. 精神的負荷 a. オンコール対応のストレス b. 「また同じような問題か...」という疲労感
5. 5 マイクロサービス化による課題の増大 数字で見る現状 • サービス数の継続的増加 • インシデント発生頻度の上昇 • 対応時間の長期化傾向 根本的な問題 • スケールに対してオンコール対応者数が不足 • 過去の知見が散在し、活用されていない • 「また車輪の再発明をしている」感覚 目指したい姿 • 過去の学びを組織として蓄積・活用 • 対応者の負担軽減と品質向上の両立
6. 6 「AIで解決できるのでは？」という仮説 それまでの取り組み • 2022年：AIOps調査開始 • 2023年：LLM活用ケースの探索 ChatGPT体験での気づき • 「これは今までと違う」 • 自然言語での複雑な推論が可能 • 文脈理解による柔軟な対応 仮説 • 過去のインシデント情報をLLM が理解できれば... • 類似ケースの発見と提案が自 動化できるのでは？
7. 7 Part 2: 何を学んだのか（失敗編） 2024年12月：初期リリース時の課題 1. 「使われない」問題 • IBISの存在を忘れられる ◦ 問い合わせベースのみだった • インシデント時に思い出してもらえない • 学び: 受動的なシステムでは定着しない 2. 「品質のばらつき」問題 • 問い合わせ内容次第で精度が大きく変動 • 適切な質問ができないと有用な情報が得ら れない • 学び: ユーザーに負荷をかけるデザインは NG
8. 8 Part 2: 何を学んだのか（成功編 1） 課題解決への転機 • 2025年初頭: Suggestion Bot開発開始 • コンセプト: "人間の問い合わせを待たない" 成功要因1: プロアクティブ性 • インシデントチャンネル作成をトリガーに自動参加 • メッセージを収集して自動で類似事例を検索 • 結果: 存在を忘れられることがなくなった
9. 9 Suggestion botの実行例 類似ケースを見つけて情報提供。 類似ケースを元に提案、アドバイスも提供。 ユーザーは過去事例の詳細情報も確認できる。
10. 10 Part 2: 何を学んだのか（成功編 2） 成功要因2: コンテキスト理解 • チャンネル内の会話から状況を自動判断 • 適切なタイミングで情報提供 • 結果: ユーザーが質問を考える負荷が軽減 成功要因3: 継続的改善 • ユーザーフィードバックを積極的に収集 • 結果: UI/UX改善と精度向上
11. 11 最も重要な学び：「相棒」という概念 当初の誤解 • 積極的に利用されることを期待 • 人間の介入を最小化することが目標 現在の理解 • AIは「相棒」として機能すべき • 人間の判断を支援し、知識を補完する存在 • 完全な自動化ではなく、人間との協調が重要
12. 12 最も重要な学び：「相棒」という概念 「Buddy」の由来 Incident Buddy and Insight System = IBIS 頼れる相棒として、一緒にインシデントに立ち向かう
13. 13 Part 3: どう作ったのか なぜLangGraphを選択したか LangChain（従来手法）の限界 • （基本的に）直列・線形的な処理フロー • 動的な判断が困難 • 自律性に限界 LangGraph（選択した理由） • ReActフレームワーク（推論→行動 のループ） • 状況に応じた動的な判断 • ツール利用による機能拡張
14. 14 アーキテクチャの核心： Vector Search インシデント情報の特性 • 類似した過去事例が豊富 • 文脈と詳細が重要 • リアルタイム性より正確性が重要 Vector Searchの利点 1. 意味的類似検索 : キーワード以外の関連性発見 2. 最新情報統合 : ベクターDBの継続更新
15. 15 Vector Store BigQuery Vector Search採用理由 • 既存インフラ活用 : 追加コスト最小化 • スケーラビリティ : メルカリ規模に対応 • コサイン類似度 : 効率的な近似最近傍検索
16. 16 データ前処理：品質向上の要 前処理パイプライン 1. PII保護（spaCy NER使用）※NER = Named Entity Recognition 2. 言語統一 • 日英混在 → 英語統一（注: Embedding用） • トークン効率向上 • ベクトル品質改善
17. 17 実装結果：どのような成果が出たか 利用状況 • 複数Slackチャンネルでの稼働 • Suggestion Botによる自動提案実装
18. 18 現在の課題と改善点 課題1: 効果測定の難しさ • インシデントが発生しないと利用機会がない • MTTRへの定量的貢献度が測定困難 • ユーザーフィードバックに頼る評価方法 ◦ いくつか評価基盤を検証中 課題2: 精度のばらつき • 情報の品質に依存する回答精度 • まれなケースでの対応力不足 • 継続的なモデル調整が必要 課題3: スケーラビリティ • 多言語対応（ユーザーとの会話、情報 提供側） • リアルタイム情報統合の遅れ 学び: 完璧を目指さず、継続的改善が重 要
19. 19 Part 4: これからのチャレンジ MCP連携（WIP） • Model Context Protocol導入 • 最新システム状態の自動取得 • 過去と現在の情報を統合した提案
20. 20 MCP = Model Context Protocol https://modelcontextprotocol.io/docs/getting-started/intro https://www.anthropic.com/news/model-context-protocol
21. 21 まとめ：AIエージェント開発で学んだこと 1. LangGraphの威力: 自律性にはエージェント型アーキテクチャが必須 2. 前処理の重要性 : データ品質がAIの性能を大きく左右 3. RAG・Vector searchの適性: インシデント対応履歴・管理情報のような特性には RAGによるVector searchが最適
22. 22 メッセージ： AIエージェントの未来 IBISの経験から言えること ✅ 使える場面 • 過去の知見が豊富に蓄積されている領域 • 人間の判断支援が価値を生む業務 • 繰り返し発生する課題への対応
23. 23 メッセージ： AIエージェントの未来 IBISの経験から言えること ⚠ 注意が必要な場面 • 完全自動化を期待する業務 • データが少ない・品質が低い領域 • クリティカルな判断を完全にAIに委ねる場合
24. 24 メッセージ： AIエージェントの未来 IBISの経験から言えること 🚀 成功を積み重ねていくには 1. 明確な課題設定: 何を解決したいかを具体的に 2. 段階的アプローチ: 小さく始めて徐々に拡張 3. 継続的改善: まずはユーザーフィードバックを重視 4. 人間中心設計: AIは人間の相棒として位置づけ
25. 25 今日お話ししたこと • IBISの開発過程で得た失敗と成功の学び • AIエージェント開発の現実的な課題と解決策 • LangGraph、RAG、Vector Searchの実践的活用
26. 26 Thank You! さらに詳しく知りたい方は • メルカリIBIS：AIが拓く次世代インシデント対応 : https://speakerdeck.com/0gm/merukariibis-aigatuo-kuci-shi-dai-insi dentodui-ying • Platform Engineering Kaigi 2025にて、さらに深掘り予定 • X: @ktykogm でも情報発信中
27. 27 最後に AIエージェントは万能ではないが、適切に設計すれば価値を生み出せる。 重要なのは「相棒」として人間と協調すること。 ご清聴ありがとうございました！