1 AIと新時代を切り拓く。これからの SREとメルカリ IBISの挑戦 SRE Kaigi 2026 / Oguma (@ktykogm) 

2 ● oguma (@ktykogm) ● メルペイ SREチーム ● Fintech領域のシステム信頼性向上に従事 ● AI Agent「IBIS」メイン開発者 ● AI-Native Incident Managementプロジェクト推進中 自己紹介 

3 私たちのAI Agentは、 最初ほとんど利用されていませんでした。 正直に言います 

4 ● IBIS: インシデント対応の相棒となるAI Agent ● 失敗と学び: 利用されない問題、属人化、リソース不足 ● AI駆動開発で乗り越えた方法 ● バルク分析ツールキット: 4倍高速化の技術的工夫 ● まとめと今後の展望 今日お話しすること 

5 Playbooks/Runbooksの限界 ● すべての状況に対応できない ● メンテナンスに労力がかかる 過去事例の活用が非効率 ● 関連情報の検索・分析に時間がかかる ● 知識が属人化し、引き継ぎが困難 人間の介入が多すぎる ● 本来の機能開発から時間を奪う ● 信頼性、モチベーション、健康に悪影響 インシデント対応の課題 → これらを解決するためにIBISを開発 

6 背景: 前述の課題を解決し、AI-Native SREを実現するために開発 ● Incident Buddy and Insight System = IBIS ● インシデント対応を支援するAI Agent ● 2024年7月 PoC開始 → 2024年10月 本格開発 → 2024年12月 初期リリース ● 目的: 過去のインシデント知見を活用した迅速な対応支援 IBIS: インシデント対応の相棒とは 

7 IBISのアーキテクチャ概要 

8 ● 問い合わせ対応 : Slack botへの質問に類似事例と提案を回答 ● Suggestion Bot: インシデント発生時にプロアクティブに情報提供 ● Retrospective Review: ポストモーテムの品質チェックとステータス管理支 援 ※ 大量インシデントの傾向分析には、IBISの一部機能を活用したツールキットを開 発 IBISのコア機能（ 2026年1月時点） 

9 シナリオ例（※説明用の架空の例です） : 深夜23:45、DBコネクションタイムアウトのアラートが発生。 オンコール対応者がAI に「DBタイムアウト」で類似事例を検索: 根本原因: 従来RAGは「意味的類似性」で検索 — 類似性 ≠ 関連性 従来RAGの限界: IBISが直面した課題 

10 現状: Vector Search + LangGraph ReAct ● 類似ケース発見には効果的 — 従来RAGも適材適所で有用 ● データクレンジング（PIIマスキング、言語統一、要約）で品質確保 課題: 意味的類似性では構造的関連性を検出できない ● Playbook/Runbookの関連ページ（警告・注意事項）が見落とされるリスク 今後: SSRAG、PageIndexなど次世代RAG技術の調査・検討中 ● 現時点ではPoCの計画には至っていない ● 各技術の特性を踏まえた適材適所の検討が重要 IBISのRAG戦略と今後の展望 

11 従来RAG（左）: 意味的類似性に依存、チャンキングが文脈を破壊 推論ベース RAG（右）: ツリー構造で文書を理解、人間のように思考して検索 次世代RAG技術: 推論ベース RAGの台頭 補足: 右図にある「ツリーインデックス」の 説明部分については次のスライドで説明 するPageindexです。他の推論ベース RAGには従来RAGと同様にベクトルデー タベース等は必要です。 

12 特徴: ベクトル検索を使わない全く新 しいアプローチ 仕組み: 目次のようなツリー構造で文 書を理解し、推論で検索 精度: 金融ベンチマークで 98.7%の 最高精度を達成 https://pageindex.ai/blog/Mafin 2.5 PageIndex: Vectorless RAGの革新 

13 ● Cloud Run functions + Cloud Run jobs で構成 ● PIIマスキング、言語統一、重複排除を自動化 ● Terraform IaCで管理、再現性を確保 LLMOps Pipeline: データ品質へのこだわり (IBISの従来RAG) 効果: RAG検索精度の向上、ノイズ削減により回答品質が改善 

14 ● リリース直後、利用率は想定よりかなり低かった ● 原因: ユーザーが能動的に使うことを期待していた ● 学び: AI Agentは自律性を持たせる必要がある ● 対策: Suggestion Botでプロアクティブに提案 失敗と学び : 最初の失敗 

15 ● インシデント発生 → 自動で類似事例検索 → Slackに提案投稿 ● 効果: 対応者の初動を支援、過去知見の活用率向上 Suggestion Bot: 受動から能動へ Before After ユーザーが 質問 IBISが自動 検知 回答を待つ 類似事例を 即座に提案 使われないと 価値なし 常に価値を 提供 

16 ● インシデント管理SaaSとMCP連携（内製MCP Server） ● 2つのユースケース: ○ ケース1: 管理情報のレビュー : ポストモーテムの品質チェック ○ ケース2: 管理状態の改善: 遅延チケットの検出と提案 Retrospective Review機能 

17 ● IBISがMCP経由でチケット状態を確認 ● 振り返り/ポストモーテム完了チケットの内容をレビュー ● 問題があれば具体的に指摘 ● 人間の管理者が差し戻すか判断できるように ケース1: 管理情報をレビューする 

18 ● 対応が遅滞したチケットを自動検出 ● 現状を確認し、ステータス変更忘れを検知 ● 変更提案をSlackで通知 ● 放置されがちなチケットの健全性を維持 ケース2: 管理状態を改善する 

19 ● 利用中サービスの変更に伴う予定外の改修対応 ● AI-Nativeインシデント対応の重要性が社内で急激に高まる ● 特にFintech分野（Merpay & Mercoin）でリスク管理チームとの連携増加 ● IBISへの期待とスコープ外要望が急増 ● AI駆動開発の強化が急務に 需要増 vs リソース減 : 開発必要性の急増 

20 ● 他に優先度が高いプロジェクトが複数重なる ● メンバーがIBIS開発にほとんど参加できない状態 ● AI Agent開発、Pythonのキャッチアップも遅延 ● 属人化: 設計・メイン開発・コア部分が1人に集中 開発リソースの減少 

21 AI駆動開発で乗り越える 

22 ● 一貫した開発工程をAIでサポート ○ 計画 → 設計 → 実装 → レビュー → テスト → PR → レビュー → レビューコメントの分析と対応案の 提示 ● Claude Code + Cursor + Codex + GitHub Copilot のマルチAI環境を構 築 ○ 利用者に合わせた最適な AIツールを選択可能に ● 属人レベルをいつでも下げやすくする戦略 ○ Context Engineeringの活用が鍵 AI駆動開発の目標と戦略 

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 ● 各フェーズの承認ポイントで人間がレビュー ● AIの出力を鵜呑みにしない仕組み ○ 設計方針の承認 ○ コードレビュー結果の確認 ○ セキュリティチェック結果の判断 ○ PR作成前の最終確認 ● AIに自由にやらせつつ、品質と安全性は人間が担保 HITL（Human-in-the-Loop）の設計 

25 ● 15種のエージェント定義 ○ Leader系: 計画・設計・調整 ○ Worker系: 実装・テスト実行 ○ QA系: レビュー・検証 ● 21種のSkills（再利用可能なワークフローモ ジュール） ○ 設計 / 実装 / テスト / レビュー / セキュリティ / コンテキ スト管理 マルチエージェントアーキテクチャ 

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 3つの原則: 1. 単一責任: 1エージェント = 1責務 a. 調査・設計・実装は分離する 2. 簡潔さ: プロンプト <2,000 tokens a. タスクは具体的に、探索より実行を 3. 順次実行: 並列は慣れてから a. 一見遅いが、やり直しがなく安定 b. 総実行時間: 2-3時間（予測可能） AI Agent設計の教訓 

28 ● Serena MCP: コード解析とメモリ管理機能を提供するMCPサーバー ● 開発に関わる知識・設計判断・ADRを構造的に蓄積 ● メモリのレイヤー構造 ○ project/: チーム共有ガイド（Gitで管理） ○ local/: 個人タスクメモ（ローカルのみ） ● Claude Skills（manage-context / search-memory / update-memory）で管理 ● Serena indexも適切なタイミングで更新 Context Engineering: 知識の構造化 

29 ● Serenaのデフォルトはレイヤー構造を完全にはサポートしない ○ そのままではSerenaが検出や管理に失敗する恐れ ● 対策: project/ディレクトリを作成し、チーム管理したいメモリのみGitで共有 ● .gitignoreで制御: project/のみcommit対象 ● 独自Claude Skillsでメモリ操作を標準化し、問題を回避 ○ /manage-context: コンテキスト収集・合成 ○ /search-memory: 階層的メモリ検索 ○ /update-memory: 会話から情報を更新 ● Serena index更新ポリシー: 5日ごとまたはコード大規模変更時 Context Engineering: 工夫したポイント 

30 ● hooks: コード変更時に自動でPython Linter実行 ● rules: セキュリティ（認証情報漏洩防止、権限制御）/ ワークフロー制約 ● settings.json: allow/denyリストで操作を制限 ● SECURITY.md: チーム全体のセキュリティポリシー ● AIに自由にやらせつつ、危険な操作は確実に防ぐ セキュリティと品質のガードレール 

31 ● Context Engineeringにより知識が構造化・外部化 ○ オンボーディングやADRに流用可能なレベル ● 属人レベルをいつでも下げやすくしている戦略 ● ゆくゆくは社内開発者が参画しやすい土壌を整備 戦略的な付加価値 : 属人化の緩和 

32 バルク分析ツールキット 

33 ● 四半期インシデントレビュー : SEV1-SEV4の傾向分析を定期報告 ● 課題: 複数件のインシデントを人手で定期的に分析するのは非現実的 ● 要求: 大量データの一括処理と傾向の自動抽出 ● リアルタイム対応（IBIS）とは異なるワークロード特性 バルク分析の背景 

34 ● IBIS: リアルタイムのインシデント対応支援 ● バルク分析: 大量の過去インシデントの傾向分析 ● 用途が異なる → アーキテクチャも分離 ● 分析結果をIBISの学習データとして活用 なぜIBISと分離したか 

35 ● 目的: 四半期インシデント傾向の一括分析（リスク管理報告用） ● 問題: ○ 大量データによるコンテキストウィンドウ超過 ○ トークンリミットによる出力制約 ○ 逐次処理では実用的な時間内に完了しない ○ LLM API呼び出しコストの増大 ● 制約: 単純な並列化では429 Rate Limitで失敗 技術的課題 : 一括分析のスケーラビリティ 

36 ● ThreadPoolExecutor: 最大10ワーカーで並列実行 ● AdaptiveThrottler: 適応的スロットリングで動的制御 ● フィードバックループ : 200 OK / 429エラーに応じて自動調整 解決策: 適応的並列処理 

37 攻めの削減、守りの復旧 — 安定性と速度の両立 適応的スロットリング : 閾値設計 パラメータ 値 説明 デフォルト並列数 5 初期値 最大並列数 10 上限 最小並列数 1 フォールバック Rate Limit閾値 2 429が2連続で並列数を半減 復旧閾値 10 成功10連続で並列数を +1 

38 ● 大量インシデント情報でも最後まで処理完結 ● Token Limitを気にせず利用可能 成果: 4倍高速化 指標 Before After 改善 処理時間 120秒 30秒 4倍（75% 削減） 並列数 1 5（最大 10） 5倍 Rate Limit 対応 なし 自動調整 安定性向 上 

39 ● 当初: Phase2でIBISのマルチAgent化を予定 ● 変更: 社内重要PJ「AI-Native Incident Management」が発足 ○ IBISがその中核コンポーネントに ● 現在: リスク管理チームと連携し社内全体向けAIツール開発 ● 計画は変わる。優先度に応じて柔軟に対応することが重要 今後の展望 : 計画の変更 

40 失敗から学んだこと : ● AI Agentは「使わせる」より「提案させる」 ● エージェント設計は単一責任、プロンプトは簡潔に 乗り越えた方法: ● AI駆動開発で属人化・リソース不足に対応 ● Context Engineeringで知識を構造化 ● 並列処理 + 適応的スロットリングで4倍高速化 SREの変化: ● 従来: 属人化した知識、手動での情報検索 ● AI-Native: 知識の構造化、AIが過去事例を即座に提示 ● AIは「相棒」— 人間の判断が必要な領域を見極める目が重要 まとめ: 今日お伝えしたこと 

41 ● 失敗を恐れず、でも賢く、小さく始めよう ○ まずは1つのユースケースで AI Agentを試す ● 計画は変わる。柔軟に対応しよう ● AIに任せること、人間が判断すること、見極めよう ○ HITLの設計から始める ● Context Engineeringで知識を資産化し、チームに還元しよう ● 一緒にAI-Native SREの時代を切り拓いていきましょう 最後に 

42 oguma (@ktykogm) ご質問はお気軽にどうぞ ありがとうございました 

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 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 / 参考資料