1 ハイブリッド AIOps・AI Agent戦略 SaaS AI時代のプラットフォームエンジニアリング生存戦略 oguma 

2 oguma (X: @ktykogm) | 株式会社メルカリ メルカリ のプラットフォームグループ Autonomous Cloudで 現在FinOpsチーム に所属。 去年までメルカリのSREチームに所属。現在は信頼性とFinOpsそれぞれ の領域でAIの活用、AI/LLMアプリケーション、AI Agentの開発・運用を担当。 イン シデント対応に特化したAI-Nativeなシステム「IBIS」のプロジェクトマネジメントと開 発リードを担当。 自己紹介 

3 1. プラットフォームエンジニアリングの課題 2. 内製 vs SaaS選択の判断基準と社内合意までの道のり 3. IBIS: メルカリの内製AI Agent事例 4. ハイブリッドAIOps戦略 5. 今後の展望 SaaS AIと内製AI Agentを組み合わせた実践的アプローチ 発表タイトルは「生存戦略」としましたが、「 SaaS AI時代のプラットフォームエンジニアリング実装戦略」の方 が近いかもしれません。 今日お話しすること 

4 「内製すべきか SaaSに任せるべきか」 ● コスト ● セキュリティ ● カスタマイズ性 ● 運用負荷 ● 開発リソース 単純な答えは存在しない プラットフォームエンジニアリング共通の課題 

5 ● 2023年: LLMによる業務改善の可能性を探索開始 ● 2024年: スコープをインシデント対応に絞り込み、SaaS AIと内製AI Agentの 比較を実施。何を内製するかの判断基準を策定 ● 2024年7月: PoCとアーキテクチャー選定開始 ● 2024年10月: AIによるインシデント対応サービス「IBIS」開発本格始動 ● 2024年12月: IBIS初期リリース ● 2025年: AI-Nativeの社内推進開始。IBISを軸にIncident Management 領域全体でAI-Native化プロジェクト始動 わずか兼務2名で初期リリース + α　まで短期で達成。このあと紹介する技術構成と 工夫が大きく寄与。 AI/LLM時代の到来によるメルカリ内での取り組み開始 

6 答え：仕事を奪うのではなく、仕事の質を変える 繰り返し作業から解放され、より創造的で戦略的 な業務に集中できるようになります。 「自らの仕事を AIに奪わせようとしているのか」 

7 SREの考え方に基づく答え ● 信頼性向上 : サービス増加・システム複雑化でも品質維持 ● 効率化と自動化 : 繰り返しタスクの最適化 ● 価値創出: より高価値な仕事へのリソース集中 ● リスク管理 : インシデント対応の迅速化と精度向上 ● イノベーション推進 : 新技術の積極的な活用 ● 事業の成長に貢献 : ビジネス価値の最大化 ● 複雑化していくシステムへの対応 : 人間の限界を補う AI/LLM = 仕事を奪うものではなく、効率化するパートナー 「自らの仕事を AIに奪わせようとしているのか」 

8 SaaS AI vs 内製AI Agent比較 評価項目 重要度 SaaS AI 内製AI Agent カスタマイズ性・社内連携 ★★★ 制限あり 高い柔軟性 セキュリティ ★★★ 外部依存 要件に応じた対応が可能 コスト・開発リソース ★★ 低初期コスト・継続課金 高初期コスト・人件費 

9 ● 高重要度項目 : 内製AIが有利（★★★項目） ● 中重要度項目 : SaaS AIが有利（★★項目） 結論：ハイブリッドアプローチが最適 内製とSaaSの使い分けで最大効果を実現 評価結果 

10 時間効率を考慮した戦略的分析 1. 課題の洗い出し : 17件のAI/LLM活用候補をリストアップ 2. 要件定義: 各課題の詳細分析と期待効果の評価 3. 議論と評価 : AI/LLMに明るいメンバーとの議論を重ねる 4. 絞り込み: 3つの最優先課題に集約 次に「じぶんたちで内製するもの vs 他に任せるもの（ SaaS or 他者作成）」 の判 断基準を設ける 判断基準の設定：体系的アプローチ 

11 ● SaaSで作りやすい領域 : 汎用性が効く処理 ● 他開発者・ SRE利用の可能性 : 市場での需要が高い ● プロバイダーの優位性 : 大量データを保有する領域 ● 標準化が進んでいる : 業界標準のプロセス・ツール 内製候補から外す基準（ SaaSに任せる） 

12 ● 個人情報・機密情報 : セキュリティ要件が厳格 ● 複雑な社内連携 : 既存システムとの深い統合が必要 ● 特化・カスタマイズ : 自社固有のビジネスロジック ● 将来の拡張性 : 独自の発展方向性を持つ 結果：　3つに絞った候補のうち、重要性と緊急性の高いインシデント対応領域に 集中することで決定。 そこからさらに細分化し、どこから内製するか絞り込んでいきました。 内製すべき領域 

13 解決すべき 3つの課題 1. インシデント対応の属人化 2. 効率化と迅速化の重要性 3. 過去のインシデント履歴の活用不足 事業成長とマイクロサービス化で対応者の負担増加 → 本来すべき価値創出への投 資へシフト インシデント対応の課題 

14 インシデント対応段階 SaaS/クラウドベンダー 内製AI Agent 備考 1. インシデント予防・予測による警告 ⭐ - 大量データ保有による優位性 2. インシデントの検知 ⭐ - 汎用的な検知技術の優位性 3. インシデントの初動対応 ⭐⭐ ⭐ 両方に適性、用途により使い分け 4. インシデントの調査と分析 ⭐ ⭐⭐ 社内情報活用で内製が優位 5. インシデントの解決と復旧 - - 現状では人間主導 6. インシデントの報告と振り返り ⭐⭐ ⭐⭐ 両方に適性、要件により選択 7. 再発防止策の実施 - ⭐※ ※ものによる、社内連携重要 ※あくまでメルカリ内での状況に基づく評価 記号説明： ● ⭐：適性あり（数が多いほど優位性が高い） ● ※：条件付きで適性あり インシデント対応段階別 AI適性比較 

15 既存アプローチの問題点 ● プレイブック /ランブックの制限 : 静的で網羅性に限界 ● 過去事例活用の非効率性 : 検索・分析に時間がかかる ● 属人化: 経験者への依存度が高い ● 人間の介入の必要性 : 継続的な負荷とストレス 解決すべき根本課題 : 事業成長とマイクロサービス化により複雑化するシステムに対し、従来の手法では 状況は悪化しやすい 。 オンコール対応も辛くなってくる。 インシデントの調査と分析 : 従来手法の限界と課題 

16 Incident Buddy and Insight System 過去のインシデント情報を活用し、インシデント対応を支援する AIエージェント "Buddy" = 相棒 人間と協調して動作するシステム IBIS誕生：解決策としての AI Agent 

17 ● 過去事例を活用 : ベクターDBで高品質に管理した過去の事例を有効活用 ○ インシデント管理するモチベーションも上がる ● 柔軟なコンプライアンス : 外部SaaSでは対応困難な要件への対応 ● 学習機能: 継続的な改善と知見蓄積 ● 最新社内情報統合 : リアルタイムな状況に基づく提案 ○ インシデント対応のやりとりを収集し、分析に利用 ○ MCP Serverとの連携は現在実装中 MCP: Model Context Protocol (https://modelcontextprotocol.io/docs/getting-started/intro) IBISによる根本的解決 

18 組織レベルでの改善 ● スキルの平準化 : 経験の浅いメンバーが過去の知見に即座にアクセス ● 心理的安全性向上 : 過去事例に基づく客観的な判断支援 ● 24/7可用性: いつでもアクセス可能な相談相手としての機能 IBIS導入による早期効果 

19 ● LangGraph: AIエージェントフレームワーク ● BigQuery: ベクターデータ格納・コサイン類似度検索で利用 ● Slack Bot: Bolt for Python（非同期実装） ● LLM: OpenAI GPT model ● Embedding: text-embedding-3-small LLMの補足： ● 内部でmodelを使い分けている ● OpenAIのmodel以外も利用できるようにする予定 ○ 注意: ベクター検索の意味的類似性は Embedding modelに依存 IBISの技術スタック 

20 データフロー インシデント管理サービス（SaaS） → データ収集 → 前処理 → BigQuery AI処理フロー ユーザークエリ → RAG検索 → LLM回答 → Slack シンプルなパイプラインで高品質な AI支援を実現 IBISアーキテクチャ 

21 赤枠: Data Cleansing & PII Masking オレンジ枠 : Translation, Summarization, and Embedding IBISアーキテクチャ図 

22 フロー 

23 LLMOpsデータ前処理戦略 データ収集 → クレンジング → 言語統一 → 圧縮 → ベクトル化 前処理が重要な理由 : ● 品質・セキュリティ ○ データ品質 : クリーンデータでAI性能向上 ○ セキュリティ : 個人情報保護・コンプライアンス対応 ● コスト・精度 ○ コスト効率 : 不要情報削除でトークン数削減 ○ 検索精度 : 適切な前処理で意味検索精度向上 

24 重要な3つの処理 1. 個人情報マスキング a. spaCy NER(Named Entity Recognition)で自動検出・マスキング 2. 言語統一 a. 日英混在テキスト→英語統一 3. 要約処理 a. Map-Reduce並列でコスト最適化 性能最適化の成果 ● 高速化: 各所で大幅な処理時間短縮 ● コスト効果 : トークン数削減でコスト最適化 主要な前処理と性能最適化 

25 spaCy NERでの個人情報マスキング 主要機能 ● 国際化対応 : 日本語・英語・中国語等 ○ 各国の人名パターンに対応 ● 表記ゆれ対応 : "山田太郎" / "Taro Yamada" 等 ● マスキング : [PERSON NAME REDACTED]等で置き換え 技術的ポイント ● モデルキャッシュ : ロード時間を大幅短縮 ● パフォーマンス : 106s → 13s（87%高速化） ○ ローカル環境（MBP）での測定結果: 長文も含めたテストケース 15件の処理時間比較 PII保護の実装戦略 

26 シンプルな実装例 （実際のコードとは異なります） 実際にはNERの誤判定によるマスキング漏れを防ぐため、ルールベースの補 完も実装しています。 PII保護のコード例 

27 次にVector storeの説明に移ります。 Vector store 

28 通常のレキシカル検索(キーワードマッチング)に対し、ベクター検索は近似最近傍探 索を実現します。 ベクター検索における近似最近傍探索の簡 潔な説明： 近似最近傍探索：高次元ベクター空間で、クエリベクターに最も近い（類似する）ベク ターを効率的に見つける手法。完全に正確ではないが、計算速度を大幅に向上させ ることで、大規模データセットでもリアルタイム検索を可能にする。 ベクター検索の基本 

29 技術的優位性 ● 2024年後半に一般提供（ GA）開始: ベクトル検索機能正式リリース ● 高次元対応 : OpenAIのtext-embedding-3-smallは最大1536次元のベクトルを生成 ● コサイン類似度 : 効率的な類似性計算 ● スケーラビリティ : 大規模データ対応 経済的合理性 ● 既存契約活用 : 旧Flat-rate(BigQuery Edition)枠内で追加コストなし ○ LangChainのBigQueryVectorStoreはBATCHクエリーを優先 ○ BATCH優先度: 実行優先度（後回し）指定。料金は価格モデルに依存（オンデマンド /予約）。コ スト削減というよりスロット圧の平準化に寄与。 ○ 注: Standard Editionではベクターインデックスが利用不可。 Edition/予約構成に依存。 ● 予測可能コスト : 従量課金からの解放 BigQuery vector search採用の理由 

30 主要機能 1. Vector Search ● インシデント履歴の意味的検索 ● セマンティック検索で関連性発見 2. 情報提供 ● 類似ケースの特定と詳細情報 ● 対応手順・原因分析・解決策の提示 IBISの4つのコア機能 3. 提案生成 ● LLMによる状況に応じた対応策推 論 4. 自律動作 ● プロアクティブな情報提供 

31 ● 自律性: 人間の介入を最小化し、独立してタスクを遂行 ● 積極性: 必要な情報を能動的に収集・提供 ● 協調性: 人間や他のシステムと効果的に連携 ● 統合性: 既存システムやツールとシームレスに連携 ● 適応性: 変化する環境や要件に柔軟に対応 ● 信頼性: 高い可用性と正確性を維持 ● 学習能力: 過去の経験から学び、継続的に改善 ● 拡張性: 新しい機能やツールを容易に追加可能 プラットフォーム運用の自律化に必要な要素 

32 初期リリース時の課題 ● 受動的システム : ユーザーの問い合わせ待ち ● 問い合わせ内容に依存 : 適切な質問が必要 ● 限定的な自律性 : 自動化の範囲が狭い 自律性と積極性の強化が必要と判断 そこでSuggestion Botを開発 初期リリース時にうまくいかなかった点 

33 自動動作フロー ● 1. 検知 → インシデントチャンネル作成をトリガーにチャンネルに参加 ● 2. 収集 → チャンネル内メッセージを自動収集 ● 3. 圧縮 → 収集情報を要約 ● 4. 検索 → Vector Searchで類似事例を検索 ● 5. 分析 → 収集したコンテキストから状況を理解 ● 6. 生成 → LLMで対応提案を作成 ● 7. 提供 → 適切なタイミングで情報投稿 特徴: 人間の問い合わせを待たない能動的システム Suggestion Bot：自律的AI Agent 

34 Suggestion Bot実行例 類似ケースを見つけて情報提供。 類似ケースを元に提案、アドバイスも提供。 ユーザーは過去事例の詳細情報も確認できる。 

35 測定可能な成果 ● 定量効果: まだ目に見える効果は限定的、継続的な改善が必要 ● 定性効果: 満足度の向上 今後の技術的優先事項 ● 精度向上: 現在はユーザーフィードバックに基づくチューニングが基本。評価基 盤の強化と提案の正確性向上は必要不可欠 ● インシデント管理データ更新の補助 : 自動化による効率化 ○ 例: 更新の提案 （あえて人間の介入を残すデザイン） ● リアルタイム性 : MCP導入による最新情報統合 現在の課題と継続改善 

36 役割分担の明確化 ● IBIS: 社内情報活用・セキュリティ/ガバナンス要件準拠・カスタマイズ ● SaaS AI: 汎用的な機能・標準的な処理 柔軟性の確保 ● 要件変更時のIBIS機能拡張 ● SaaSサービスとの連携・置き換え ● 他のAI Agentとの連携 利用者から見ると 1つのAIエージェント ハイブリッド戦略のポイント 

37 現在できつつあるのは左上の部分 システム間連系図 （案） 

38 Vector Search + MCPのハイブリッド構成 ● Vector Search: 過去情報の効率検索・コスト効率 ● MCP: 最新情報のリアルタイムアクセス・即時性 ● 運用管理の効率化 : インシデント管理の一部自動化 ○ 人間が責任を持ち続けるために人間が介入する部分は残す ○ 自動化できる部分は積極的に自動化し、更新遅延と負担を減少させる 組み合わせで統一レスポンスを実現 今後の技術戦略： Phase 1: MCP連携で情報統合強化 

39 特化型エージェントの役割分担 (例) Supervisor Agent: ● Coordinator Agent: 全体調整・意思決定支援 SubAgents: ● Analysis Agent: 根本原因分析・影響範囲特定 ● Search Agent: 類似事例検索・関連情報収集 ● Action Agent: 対応策提案・自動復旧実行 Supervisor オーケストレーション : Supervisor AgentがSubAgentsを管理・調整し、全体の効率化と精 度向上を図る 今後の技術戦略： Phase 2: Multi-Agent System (MAS) 協調 

40 ● Frontman/Conductor (Gateway) AIの確立: 複数のMAS・Agentや toolの一元管理と受付窓口を担う ● Knowledge Base AIとの連携: 社内ドキュメント・ナレッジベース統合 ● 開発アシスタント AIとの連携: IDEとの統合 目標: インシデント管理全体のAI-Native化実現 たとえば、インシデント発生時、エンジニアはFrontman/Conductor AI からの報告と解決策の提案 を待てばよくなり、お客様に価値を届けるための開発時間が増えます。AI Agentが自律的に活躍し て人間をサポート、業務効率化で信頼性も向上させる、というイメージ 頼れるAIエージェント群にしていく 今後の技術戦略： Phase 3: 社内AI エコシステム統合 

41 まとめ 

42 1. 明確な判断基準の設定 ● 課題の体系的分析 : 17項目→3項目への絞り込みプロセス ● 評価軸の明確化 : コスト・セキュリティ・カスタマイズ性 ● 時間効率の重視 : 完璧な分析より早期の意思決定 2. 段階的導入によるリスク最小化 ● MVP(Minimum Viable Product): 小規模での検証開始 ● フィードバックループ : ユーザー評価による継続改善 ● スケーラビリティ : 成功パターンの段階的拡張 ハイブリッド AIOps戦略の成功要因の整理 1 

43 3. 継続的改善による価値最大化 ● 定量評価: 明確な成果指標の設定と測定 ● 技術革新への対応 : 新技術の積極的な検証・導入 ● 組織学習: 失敗も含めた知見の蓄積・共有 ハイブリッド AIOps戦略の成功要因の整理 2 

44 技術選択の指針 ● 既存エコシステムとの親和性 : BigQuery選択の決定要因 ● コスト最適化 : 既存契約の活用、運用負荷の考慮 ● 将来拡張性 : Multi modal対応、MCP導入への布石 組織・プロセスの重要性 ● ステークホルダーとの合意形成 : 明確な価値提示 ● 段階的な信頼構築 : 小さな成功の積み重ね ● 継続的なコミュニケーション : 期待値の調整と成果共有 開発リソースを集中 × SaaS活用 = 効率と効果の最大化 プロジェクト進行のポイント 

45 ● メルカリエンジニアリングブログ（ IBIS/次世代インシデント対応） ○ https://engineering.mercari.com/blog/entry/20250206-llm-sre-incident-handling-bud dy/ ● メルカリIBIS：AIが拓く次世代インシデント対応 ○ https://speakerdeck.com/0gm/merukariibis-aigatuo-kuci-shi-dai-insidentodui-ying ● BigQuery Vector Search ○ https://cloud.google.com/bigquery/docs/vector-search ● LangChain Google BigQuery Vector Search ○ https://python.langchain.com/docs/integrations/vectorstores/google_bigquery_vector _search/ ● LangChain Google BigQuery Vector Search Implementation ○ https://github.com/langchain-ai/langchain-google/blob/354b54aabf35f1fa670adc773e 58aa1af559f7aa/libs/community/langchain_google_community/bigquery_vector_searc h.py#L505 出典、参考、 補足資料1 

46 ● BigQuery Queries（BATCH優先度） ○ https://cloud.google.com/bigquery/docs/queries#batch ● BigQuery Quotas ○ https://cloud.google.com/bigquery/quotas#vector_index_limits ● BigQuery Pricing ○ https://cloud.google.com/bigquery/pricing ● Embedding models ○ https://research.aimultiple.com/embedding-models/ ● spaCy ○ https://spacy.io/ ● LangGraph ○ https://www.langchain.com/langgraph ● Slack Bolt for Python ○ https://docs.slack.dev/tools/bolt-python/ 出典、参考、 補足資料2 

47 「作る/任せる」の判断基準を明確にしたハイブリッド AIOps戦略で、プラット フォームエンジニアリングの未来を切り拓く。 ご清聴ありがとうございました！ Platform Engineering Kaigi 2025 Thank you!