メルカリIBIS：AIが拓く次世代インシデント対応

「生成 AIは “Incident Buddy” になり得るのか？」というテーマでTopotalさんのイベントにて発表させていただいたスライドです。

Transcript

1. 1 メルカリIBIS：AIが拓く次世代インシデント対応 Oguma
2. 2 Oguma (X: @ktykogm) • ex-SRE で現在はPlatform Autonomous Cloud グループのFinOpsチー ムに所属 • インシデント対応とFinOpsそれぞれの領域でAI/LLMの活用と開発を行なって いる ◦ AI-Nativeなインシデント対応システム「 IBIS」のプロジェクトマネジメントと開発リード 自己紹介
3. 3 1. インシデント対応の課題 2. AIによる解決アプローチ 3. IBIS の紹介と技術構成 4. 実装結果と成果 5. 今後の展望 アジェンダ
4. 4 現状の問題点 • 属人化: 特定の人に依存したインシデント対応 • 効率性: 対応時間の長期化とMTTR増大 • 負荷: オンコールメンバーへの過度な負担 • 知識活用: 過去のインシデント履歴の未活用 メルカリのインシデント対応における課題
5. 5 背景 • サービス数の増加に伴うオンコール対応の複雑化 • 対応者数の不足と属人化の深刻化 • お客様への価値提供よりインシデント対応に時間を割く問題 解決の必要性 • 自律性・回復性のあるシステム構築への投資 • オンコール対応の効率化と自動化 注意: マイクロサービス自体を否定するものではなく、他のアーキテクチャでも同様の課題が発生する可能 性があります。ここではサービスの数の増加に伴う課題を示唆しています。 マイクロサービス化による課題の増大
6. 6 • 2022年: AIOpsの調査開始 • 2022年11月: ChatGPT公開でパラダイムシフトを確信 • 2023年: LLMを活用したインシデント対応の可能性を探索 • 2024年7月: PoCとアーキテクチャー選定を開始 • 2024年10月ごろ: AIによるインシデント対応サービスとして、IBISの開発を本 格的に開始 • 2024年12月: IBISの初期リリースを実現 • 2025年現在: AI-Nativeの社内推進が開始。先行していたAI-Nativeプロジェ クトであるIBISを軸に Incident Management領域全体で AI-Native化プロ ジェクトを始動 これまでの流れ
7. 7 SaaSが実装しやすい領域（ IBISのスコープから外した領域） • ログとアラート管理 ◦ 原因分析、アラートの集約 • インシデントレポート自動生成 • ポストモーテム作成 内製を選択した領域 • 過去のインシデント履歴の活用 • 類似ケースの特定と情報提供 • インシデント対応者への提案生成 内製 vs SaaS の判断基準
8. 8 • 選択理由1：メルカリ固有のニーズへの対応 ◦ 社内システムとの緊密な統合 ◦ 過去のインシデント履歴という特殊なデータソースの活用 • 選択理由2： 譲れないセキュリティ要件の遵守 ◦ インシデント情報には機密情報が含まれる可能性があり、社内の厳格なセキュリティポリシー への準拠が必須 ◦ データのマスキングやアクセス制御を柔軟に実装するため • 選択理由3： 将来の拡張性と柔軟性の確保 ◦ 特定のSaaSやクラウドベンダのAIサービスやLLMプロバイダーに縛られず、最適な LLMやク ラウドサービスを組み合わせ可能 なぜインシデント履歴を取り扱う AI Agentの内製を選択した か
9. 9 Incident Buddy and Insight System 目的: インシデント対応の相棒として機能するAIエージェント コアコンセプト : • 過去のインシデント履歴からの学習 • 意味的類似性による情報検索 • 自律的な情報提供と提案生成 IBIS とは
10. 10 • LangGraph: AIエージェントのフレームワーク • ReAct: Reasoning and Acting（推論と行動）を組み合わせたフレームワー ク ◦ ReAct論文: "ReAct: Synergizing Reasoning and Acting in Language Models" ◦ LangGraphのprebuild で利用可能 (https://langchain-ai.github.io/langgraph/agents/agents/) • BigQuery: ベクターデータの格納とコサインシミラリティ（コサイン類似度, Cosine Similarity）による検索実装 ◦ RAG(Retrieval-Augmented Generation（検索拡張生成）)で使用 • Slack Bot: Bolt for Python（非同期実装） IBISの技術構成
11. 11 アーキテクチャー図
12. 12 Vector Searchの技術的利点 • 意味的検索 : キーワードではなく意味での類似性 • Data Cleansing: 不要なデータやPIIを事前にマスキング・削除 • 多言語対応 : 英語に統一してベクトル化し、トークン効率と精度を向上 • 事前要約: トークン節約と効率化 コサインシミラリティでベクトルの「意味的な近さ」を定量化 RAG・Vector SearchがIBISに最適な理由
13. 13 インシデント管理情報の特徴 • 類似した過去事例が豊富に存在する • リアルタイム性より、確定した信頼性の高い情報が重要 • 機密性の高い情報を含むケースがある • ノイズとなる無関係な情報も多い RAGが最適な理由 • 上記の特徴を持つデータソースの検索と相性が良い RAGとインシデント管理情報の相性
14. 14 LLMOpsの重要な管理ポイント • データ品質 : PII削除・ノイズ除去による高品質なベクトル生成 • コスト最適化 : トークン数管理と効率的な検索アルゴリズム • 運用監視: レスポンス時間・検索精度・ユーザー満足度の継続的測定 Vector search の重要なLLMOpsの部分
15. 15 • 既存インフラの活用 • スケーラビリティの確保 • コサインシミラリティによるANN(Approximate Nearest Neighbor, 近似最 近傍)検索 ◦ 膨大なベクトル集合からコサイン類似度の高いものを探すために ANNが利用されており、高速 でスケーラブルな類似検索が実現 ◦ BigQueryはANNの一種であるScaNNというアルゴリズムを使用 • IBISの場合、BigQuery で将来性も含めて要件が満たせると判断 ◦ 初期のPoCでは pgvector（PostgreSQLのベクター拡張機能）を試した ◦ BigQuery Vector Searchの制約については参考情報のページにある BigQueryのドキュメ ントを参照 (ref) BigQueryをVector DBとして活用
16. 16 問題点 1. 品質のばらつき : 問い合わせ内容による情報精度の変動 2. 受動性: 問い合わせがないと情報提供できない 3. 認知度: IBISの存在が忘れられる 解決策 • 自律性の向上 : Suggestion Botによる自動起動とプロアクティブな情報提供 • 継続的改善 : ユーザーフィードバックによる仕様変更や機能追加と性能向上 IBISの初期リリースで直面した課題
17. 17 コア機能 1. Vector Search: インシデント履歴の意味的検索 2. 情報提供: 類似ケースの特定と詳細情報 3. 提案生成: 対応策の自動生成 4. 自律動作: プロアクティブな情報提供 Suggestion Bot（自律的な情報提供） • インシデントチャンネル(Slack)作成時の自動起動 • メッセージ収集後の関連情報提供 • 人間の問い合わせを待たない自律性 • プロアクティブな調査と分析 IBISの現在の機能
18. 18 技術的成果 • 短期間・低工数での初期リリースを実現 • LangGraphによる自律的エージェントの構築 • RAGベースの効率的な情報検索 定量的成果 • 複数Slackチャンネルでの実用化 • MTTRへの影響は現在監視中 • ユーザーフィードバックによる継続的な改善 実装結果と成果
19. 19 今後の機能拡張 • MCP連携: リアルタイム情報の取得 ◦ MCP: Model Context Protocol (https://modelcontextprotocol.io/docs/getting-started/intro) • Deep Research: より詳細な分析機能 • 多言語サポート : 日本語・英語での対応 効果測定の難しさ • インシデントが発生しないと利用機会がない • 貢献度の判断はユーザーフィードバックに依存 今後の機能拡張と課題
20. 20 結論: なり得ると考えています 相棒として「自律性」も求める必要があると思います • 現在の到達点 : ◦ 人間の同僚や後輩のように、対応業務を補助 ◦ Suggestion Botによる自律的な情報提供を実現 • 次なるステップ : MAS (Multi Agent System) ◦ LLMベースMAS研究: "Large Language Model based Multi-Agents: A Survey of Progress and Challenges" ◦ 複数のAIエージェントが連携し、より高度なタスクを遂行 ◦ IBISも他の社内AIエージェントと連携し、包括的な自動化を目指す 今後の展望 : AIはIncident Buddyになり得るか？
21. 21 LangChain vs LangGraph • LangChain: 一方向の処理（Chain）に適している • LangGraph: 状態を持つ自律的な処理（Agent）に適している なぜLangGraphを選択したか • 自律性: ReActフレームワークと思考プロセスに基づき、自律的に判断・行動す る必要があったため • 状態管理: 長い対話の文脈を維持し、状態を変えながらループ処理を行うIBIS の要件に合致 • 拡張性: ツール利用による柔軟な機能拡張が可能 技術選択の学び
22. 22 データ管理 • 機密情報のマスキング処理やアクセス制御、事前削除 • PIIのマスキングや事前削除 • 社内セキュリティポリシーへの準拠 セキュリティとプライバシーへの配慮
23. 23 インシデント対応の未来 • AI/LLMによる対応の標準化 • SaaSとの適切な使い分け 提言 • 内製による差別化や特定ニーズに応えることの重要性 • 既存システムとの統合を考慮した設計 • セキュリティ要件を満たすカスタマイズの必要性 業界への示唆
24. 24 IBISの成果 1. 短期間での実用的システム構築 2. 自律的なAIエージェントの実現 3. 過去のインシデント履歴の効果的活用 4. インシデント対応の効率化 今後の方向性 • MASによるさらなる拡張 • リアルタイム情報との統合 まとめ
25. 25 • BigQuery quotas - Vector indexes • BigQuery vector search ◦ Release note ◦ BigQuery のベクトル検索のご紹介 • 大規模なクエリバッチに利用できる BigQuery ベクトル検索の ScaNN のご紹 介 ◦ SOAR: New algorithms for even faster vector search with ScaNN • メルカリ公式ブログ: LLM x SRE: メルカリの次世代インシデント対応 • Anthropic: Multi-Agent Research System 参考情報
26. 26 ご清聴ありがとうございました メルカリIBIS：AIが拓く次世代インシデント対応 AI-Native Incident Response for the Future 「AIは私たち人間の "相棒"になる」 Thank You!