AIと新時代を切り拓く。これからのSREとメルカリIBISの挑戦

SRE Kaigi 2026 で登壇したスライドです。
SREのAI Agentの活用と失敗・改善策をテーマにし、マルチエージェントによるAI駆動開発やLLMを活用した大量データに対する分散処理の工夫なども紹介しています。

Transcript

1. 1 AIと新時代を切り拓く。これからの SREとメルカリ IBISの挑戦 SRE Kaigi 2026 / Oguma (@ktykogm)
2. 2 • oguma (@ktykogm) • メルペイ SREチーム • Fintech領域のシステム信頼性向上に従事 • AI Agent「IBIS」メイン開発者 • AI-Native Incident Managementプロジェクト推進中 自己紹介
3. 3 私たちのAI Agentは、 最初ほとんど利用されていませんでした。 正直に言います
4. 4 • IBIS: インシデント対応の相棒となるAI Agent • 失敗と学び: 利用されない問題、属人化、リソース不足 • AI駆動開発で乗り越えた方法 • バルク分析ツールキット: 4倍高速化の技術的工夫 • まとめと今後の展望 今日お話しすること
5. 5 Playbooks/Runbooksの限界 • すべての状況に対応できない • メンテナンスに労力がかかる 過去事例の活用が非効率 • 関連情報の検索・分析に時間がかかる • 知識が属人化し、引き継ぎが困難 人間の介入が多すぎる • 本来の機能開発から時間を奪う • 信頼性、モチベーション、健康に悪影響 インシデント対応の課題 → これらを解決するためにIBISを開発
6. 6 背景: 前述の課題を解決し、AI-Native SREを実現するために開発 • Incident Buddy and Insight System = IBIS • インシデント対応を支援するAI Agent • 2024年7月 PoC開始 → 2024年10月 本格開発 → 2024年12月 初期リリース • 目的: 過去のインシデント知見を活用した迅速な対応支援 IBIS: インシデント対応の相棒とは
7. 7 IBISのアーキテクチャ概要
8. 8 • 問い合わせ対応 : Slack botへの質問に類似事例と提案を回答 • Suggestion Bot: インシデント発生時にプロアクティブに情報提供 • Retrospective Review: ポストモーテムの品質チェックとステータス管理支 援 ※ 大量インシデントの傾向分析には、IBISの一部機能を活用したツールキットを開 発 IBISのコア機能（ 2026年1月時点）
9. 9 シナリオ例（※説明用の架空の例です） : 深夜23:45、DBコネクションタイムアウトのアラートが発生。 オンコール対応者がAI に「DBタイムアウト」で類似事例を検索: 根本原因: 従来RAGは「意味的類似性」で検索 — 類似性 ≠ 関連性 従来RAGの限界: IBISが直面した課題
10. 10 現状: Vector Search + LangGraph ReAct • 類似ケース発見には効果的 — 従来RAGも適材適所で有用 • データクレンジング（PIIマスキング、言語統一、要約）で品質確保 課題: 意味的類似性では構造的関連性を検出できない • Playbook/Runbookの関連ページ（警告・注意事項）が見落とされるリスク 今後: SSRAG、PageIndexなど次世代RAG技術の調査・検討中 • 現時点ではPoCの計画には至っていない • 各技術の特性を踏まえた適材適所の検討が重要 IBISのRAG戦略と今後の展望
11. 11 従来RAG（左）: 意味的類似性に依存、チャンキングが文脈を破壊 推論ベース RAG（右）: ツリー構造で文書を理解、人間のように思考して検索 次世代RAG技術: 推論ベース RAGの台頭 補足: 右図にある「ツリーインデックス」の 説明部分については次のスライドで説明 するPageindexです。他の推論ベース RAGには従来RAGと同様にベクトルデー タベース等は必要です。
12. 12 特徴: ベクトル検索を使わない全く新 しいアプローチ 仕組み: 目次のようなツリー構造で文 書を理解し、推論で検索 精度: 金融ベンチマークで 98.7%の 最高精度を達成 https://pageindex.ai/blog/Mafin 2.5 PageIndex: Vectorless RAGの革新
13. 13 • Cloud Run functions + Cloud Run jobs で構成 • PIIマスキング、言語統一、重複排除を自動化 • Terraform IaCで管理、再現性を確保 LLMOps Pipeline: データ品質へのこだわり (IBISの従来RAG) 効果: RAG検索精度の向上、ノイズ削減により回答品質が改善
14. 14 • リリース直後、利用率は想定よりかなり低かった • 原因: ユーザーが能動的に使うことを期待していた • 学び: AI Agentは自律性を持たせる必要がある • 対策: Suggestion Botでプロアクティブに提案 失敗と学び : 最初の失敗
15. 15 • インシデント発生 → 自動で類似事例検索 → Slackに提案投稿 • 効果: 対応者の初動を支援、過去知見の活用率向上 Suggestion Bot: 受動から能動へ Before After ユーザーが 質問 IBISが自動 検知 回答を待つ 類似事例を 即座に提案 使われないと 価値なし 常に価値を 提供
16. 16 • インシデント管理SaaSとMCP連携（内製MCP Server） • 2つのユースケース: ◦ ケース1: 管理情報のレビュー : ポストモーテムの品質チェック ◦ ケース2: 管理状態の改善: 遅延チケットの検出と提案 Retrospective Review機能
17. 17 • IBISがMCP経由でチケット状態を確認 • 振り返り/ポストモーテム完了チケットの内容をレビュー • 問題があれば具体的に指摘 • 人間の管理者が差し戻すか判断できるように ケース1: 管理情報をレビューする
18. 18 • 対応が遅滞したチケットを自動検出 • 現状を確認し、ステータス変更忘れを検知 • 変更提案をSlackで通知 • 放置されがちなチケットの健全性を維持 ケース2: 管理状態を改善する
19. 19 • 利用中サービスの変更に伴う予定外の改修対応 • AI-Nativeインシデント対応の重要性が社内で急激に高まる • 特にFintech分野（Merpay & Mercoin）でリスク管理チームとの連携増加 • IBISへの期待とスコープ外要望が急増 • AI駆動開発の強化が急務に 需要増 vs リソース減 : 開発必要性の急増
20. 20 • 他に優先度が高いプロジェクトが複数重なる • メンバーがIBIS開発にほとんど参加できない状態 • AI Agent開発、Pythonのキャッチアップも遅延 • 属人化: 設計・メイン開発・コア部分が1人に集中 開発リソースの減少
21. 21 AI駆動開発で乗り越える
22. 22 • 一貫した開発工程をAIでサポート ◦ 計画 → 設計 → 実装 → レビュー → テスト → PR → レビュー → レビューコメントの分析と対応案の 提示 • Claude Code + Cursor + Codex + GitHub Copilot のマルチAI環境を構 築 ◦ 利用者に合わせた最適な AIツールを選択可能に • 属人レベルをいつでも下げやすくする戦略 ◦ Context Engineeringの活用が鍵 AI駆動開発の目標と戦略
23. 23 1. 自然言語で要件を記述 2. task-plannerがタスクを分解 3. leader-designが設計方針を決定 4. coding agentが実装 5. hooks（python-linter-check）が自動でLint実行 6. security-check / review-code skillがレビュー 7. test-creator agentがテスト作成・実行 8. GitHub PRを作成 → GitHub Copilot自動検査 • 一発で完璧は作れないが、 HITLで品質と安全性を確保 実例: 機能開発のワークフロー
24. 24 • 各フェーズの承認ポイントで人間がレビュー • AIの出力を鵜呑みにしない仕組み ◦ 設計方針の承認 ◦ コードレビュー結果の確認 ◦ セキュリティチェック結果の判断 ◦ PR作成前の最終確認 • AIに自由にやらせつつ、品質と安全性は人間が担保 HITL（Human-in-the-Loop）の設計
25. 25 • 15種のエージェント定義 ◦ Leader系: 計画・設計・調整 ◦ Worker系: 実装・テスト実行 ◦ QA系: レビュー・検証 • 21種のSkills（再利用可能なワークフローモ ジュール） ◦ 設計 / 実装 / テスト / レビュー / セキュリティ / コンテキ スト管理 マルチエージェントアーキテクチャ
26. 26 問題: 4エージェント並列起動 → 3つ失敗（75%） • 各エージェントに独立した$50 budget制限（会話全体とは別） • 失敗原因: プロンプト長すぎ、責務多すぎ（1エージェント3役割） 解決: 単一責任原則をAIエージェントに適用 • Leader分割: 1→3、Test Executor分割: 1→2 • プロンプト: 5,000+ → <2,000 tokens（60%削減） 結果: 順次実行で全エージェント成功（100%） AI Agent最適化: 失敗から成功へ
27. 27 3つの原則: 1. 単一責任: 1エージェント = 1責務 a. 調査・設計・実装は分離する 2. 簡潔さ: プロンプト <2,000 tokens a. タスクは具体的に、探索より実行を 3. 順次実行: 並列は慣れてから a. 一見遅いが、やり直しがなく安定 b. 総実行時間: 2-3時間（予測可能） AI Agent設計の教訓
28. 28 • Serena MCP: コード解析とメモリ管理機能を提供するMCPサーバー • 開発に関わる知識・設計判断・ADRを構造的に蓄積 • メモリのレイヤー構造 ◦ project/: チーム共有ガイド（Gitで管理） ◦ local/: 個人タスクメモ（ローカルのみ） • Claude Skills（manage-context / search-memory / update-memory）で管理 • Serena indexも適切なタイミングで更新 Context Engineering: 知識の構造化
29. 29 • Serenaのデフォルトはレイヤー構造を完全にはサポートしない ◦ そのままではSerenaが検出や管理に失敗する恐れ • 対策: project/ディレクトリを作成し、チーム管理したいメモリのみGitで共有 • .gitignoreで制御: project/のみcommit対象 • 独自Claude Skillsでメモリ操作を標準化し、問題を回避 ◦ /manage-context: コンテキスト収集・合成 ◦ /search-memory: 階層的メモリ検索 ◦ /update-memory: 会話から情報を更新 • Serena index更新ポリシー: 5日ごとまたはコード大規模変更時 Context Engineering: 工夫したポイント
30. 30 • hooks: コード変更時に自動でPython Linter実行 • rules: セキュリティ（認証情報漏洩防止、権限制御）/ ワークフロー制約 • settings.json: allow/denyリストで操作を制限 • SECURITY.md: チーム全体のセキュリティポリシー • AIに自由にやらせつつ、危険な操作は確実に防ぐ セキュリティと品質のガードレール
31. 31 • Context Engineeringにより知識が構造化・外部化 ◦ オンボーディングやADRに流用可能なレベル • 属人レベルをいつでも下げやすくしている戦略 • ゆくゆくは社内開発者が参画しやすい土壌を整備 戦略的な付加価値 : 属人化の緩和
32. 32 バルク分析ツールキット
33. 33 • 四半期インシデントレビュー : SEV1-SEV4の傾向分析を定期報告 • 課題: 複数件のインシデントを人手で定期的に分析するのは非現実的 • 要求: 大量データの一括処理と傾向の自動抽出 • リアルタイム対応（IBIS）とは異なるワークロード特性 バルク分析の背景
34. 34 • IBIS: リアルタイムのインシデント対応支援 • バルク分析: 大量の過去インシデントの傾向分析 • 用途が異なる → アーキテクチャも分離 • 分析結果をIBISの学習データとして活用 なぜIBISと分離したか
35. 35 • 目的: 四半期インシデント傾向の一括分析（リスク管理報告用） • 問題: ◦ 大量データによるコンテキストウィンドウ超過 ◦ トークンリミットによる出力制約 ◦ 逐次処理では実用的な時間内に完了しない ◦ LLM API呼び出しコストの増大 • 制約: 単純な並列化では429 Rate Limitで失敗 技術的課題 : 一括分析のスケーラビリティ
36. 36 • ThreadPoolExecutor: 最大10ワーカーで並列実行 • AdaptiveThrottler: 適応的スロットリングで動的制御 • フィードバックループ : 200 OK / 429エラーに応じて自動調整 解決策: 適応的並列処理
37. 37 攻めの削減、守りの復旧 — 安定性と速度の両立 適応的スロットリング : 閾値設計 パラメータ 値 説明 デフォルト並列数 5 初期値 最大並列数 10 上限 最小並列数 1 フォールバック Rate Limit閾値 2 429が2連続で並列数を半減 復旧閾値 10 成功10連続で並列数を +1
38. 38 • 大量インシデント情報でも最後まで処理完結 • Token Limitを気にせず利用可能 成果: 4倍高速化 指標 Before After 改善 処理時間 120秒 30秒 4倍（75% 削減） 並列数 1 5（最大 10） 5倍 Rate Limit 対応 なし 自動調整 安定性向 上
39. 39 • 当初: Phase2でIBISのマルチAgent化を予定 • 変更: 社内重要PJ「AI-Native Incident Management」が発足 ◦ IBISがその中核コンポーネントに • 現在: リスク管理チームと連携し社内全体向けAIツール開発 • 計画は変わる。優先度に応じて柔軟に対応することが重要 今後の展望 : 計画の変更
40. 40 失敗から学んだこと : • AI Agentは「使わせる」より「提案させる」 • エージェント設計は単一責任、プロンプトは簡潔に 乗り越えた方法: • AI駆動開発で属人化・リソース不足に対応 • Context Engineeringで知識を構造化 • 並列処理 + 適応的スロットリングで4倍高速化 SREの変化: • 従来: 属人化した知識、手動での情報検索 • AI-Native: 知識の構造化、AIが過去事例を即座に提示 • AIは「相棒」— 人間の判断が必要な領域を見極める目が重要 まとめ: 今日お伝えしたこと
41. 41 • 失敗を恐れず、でも賢く、小さく始めよう ◦ まずは1つのユースケースで AI Agentを試す • 計画は変わる。柔軟に対応しよう • AIに任せること、人間が判断すること、見極めよう ◦ HITLの設計から始める • Context Engineeringで知識を資産化し、チームに還元しよう • 一緒にAI-Native SREの時代を切り拓いていきましょう 最後に
42. 42 oguma (@ktykogm) ご質問はお気軽にどうぞ ありがとうございました
43. 43 AI駆動開発ツール • Claude Code: https://code.claude.com/docs • Serena MCP: https://github.com/oraios/serena 次世代RAG技術 - 研究論文 • SSRAG (Structured-Semantic RAG): https://arxiv.org/html/2601.12658v1 • Agentic RAG Survey: https://www.alphaxiv.org/abs/2507.09477 • GraphRAG Survey: https://www.alphaxiv.org/abs/2408.08921 • Google Research - Sufficient Context in RAG: https://research.google/blog/deeper-insights-into-retrieval-augmented-ge neration-the-role-of-sufficient-context/ Further Reading / 参考資料
44. 44 PageIndex • Introduction: https://pageindex.ai/blog/pageindex-intro • Documentation: https://docs.pageindex.ai/ 日本語解説 • https://note.com/wayne_chang/n/n125845555f45 • https://blog.elcamy.com/posts/9d4e922c/ Further Reading / 参考資料