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

Platform Engineering Kaigi 2025 (PEK2025)で発表した資料です。

Transcript

1. 1 ハイブリッド AIOps・AI Agent戦略 SaaS AI時代のプラットフォームエンジニアリング生存戦略 oguma
2. 2 oguma (X: @ktykogm) | 株式会社メルカリ メルカリ のプラットフォームグループ Autonomous Cloudで 現在FinOpsチーム に所属。 去年までメルカリのSREチームに所属。現在は信頼性とFinOpsそれぞれ の領域でAIの活用、AI/LLMアプリケーション、AI Agentの開発・運用を担当。 イン シデント対応に特化したAI-Nativeなシステム「IBIS」のプロジェクトマネジメントと開 発リードを担当。 自己紹介
3. 3 1. プラットフォームエンジニアリングの課題 2. 内製 vs SaaS選択の判断基準と社内合意までの道のり 3. IBIS: メルカリの内製AI Agent事例 4. ハイブリッドAIOps戦略 5. 今後の展望 SaaS AIと内製AI Agentを組み合わせた実践的アプローチ 発表タイトルは「生存戦略」としましたが、「 SaaS AI時代のプラットフォームエンジニアリング実装戦略」の方 が近いかもしれません。 今日お話しすること
4. 4 「内製すべきか SaaSに任せるべきか」 • コスト • セキュリティ • カスタマイズ性 • 運用負荷 • 開発リソース 単純な答えは存在しない プラットフォームエンジニアリング共通の課題
5. 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. 6 答え：仕事を奪うのではなく、仕事の質を変える 繰り返し作業から解放され、より創造的で戦略的 な業務に集中できるようになります。 「自らの仕事を AIに奪わせようとしているのか」
7. 7 SREの考え方に基づく答え • 信頼性向上 : サービス増加・システム複雑化でも品質維持 • 効率化と自動化 : 繰り返しタスクの最適化 • 価値創出: より高価値な仕事へのリソース集中 • リスク管理 : インシデント対応の迅速化と精度向上 • イノベーション推進 : 新技術の積極的な活用 • 事業の成長に貢献 : ビジネス価値の最大化 • 複雑化していくシステムへの対応 : 人間の限界を補う AI/LLM = 仕事を奪うものではなく、効率化するパートナー 「自らの仕事を AIに奪わせようとしているのか」
8. 8 SaaS AI vs 内製AI Agent比較 評価項目 重要度 SaaS AI 内製AI Agent カスタマイズ性・社内連携 ★★★ 制限あり 高い柔軟性 セキュリティ ★★★ 外部依存 要件に応じた対応が可能 コスト・開発リソース ★★ 低初期コスト・継続課金 高初期コスト・人件費
9. 9 • 高重要度項目 : 内製AIが有利（★★★項目） • 中重要度項目 : SaaS AIが有利（★★項目） 結論：ハイブリッドアプローチが最適 内製とSaaSの使い分けで最大効果を実現 評価結果
10. 10 時間効率を考慮した戦略的分析 1. 課題の洗い出し : 17件のAI/LLM活用候補をリストアップ 2. 要件定義: 各課題の詳細分析と期待効果の評価 3. 議論と評価 : AI/LLMに明るいメンバーとの議論を重ねる 4. 絞り込み: 3つの最優先課題に集約 次に「じぶんたちで内製するもの vs 他に任せるもの（ SaaS or 他者作成）」 の判 断基準を設ける 判断基準の設定：体系的アプローチ
11. 11 • SaaSで作りやすい領域 : 汎用性が効く処理 • 他開発者・ SRE利用の可能性 : 市場での需要が高い • プロバイダーの優位性 : 大量データを保有する領域 • 標準化が進んでいる : 業界標準のプロセス・ツール 内製候補から外す基準（ SaaSに任せる）
12. 12 • 個人情報・機密情報 : セキュリティ要件が厳格 • 複雑な社内連携 : 既存システムとの深い統合が必要 • 特化・カスタマイズ : 自社固有のビジネスロジック • 将来の拡張性 : 独自の発展方向性を持つ 結果：　3つに絞った候補のうち、重要性と緊急性の高いインシデント対応領域に 集中することで決定。 そこからさらに細分化し、どこから内製するか絞り込んでいきました。 内製すべき領域
13. 13 解決すべき 3つの課題 1. インシデント対応の属人化 2. 効率化と迅速化の重要性 3. 過去のインシデント履歴の活用不足 事業成長とマイクロサービス化で対応者の負担増加 → 本来すべき価値創出への投 資へシフト インシデント対応の課題
14. 14 インシデント対応段階 SaaS/クラウドベンダー 内製AI Agent 備考 1. インシデント予防・予測による警告 ⭐ - 大量データ保有による優位性 2. インシデントの検知 ⭐ - 汎用的な検知技術の優位性 3. インシデントの初動対応 ⭐⭐ ⭐ 両方に適性、用途により使い分け 4. インシデントの調査と分析 ⭐ ⭐⭐ 社内情報活用で内製が優位 5. インシデントの解決と復旧 - - 現状では人間主導 6. インシデントの報告と振り返り ⭐⭐ ⭐⭐ 両方に適性、要件により選択 7. 再発防止策の実施 - ⭐※ ※ものによる、社内連携重要 ※あくまでメルカリ内での状況に基づく評価 記号説明： • ⭐：適性あり（数が多いほど優位性が高い） • ※：条件付きで適性あり インシデント対応段階別 AI適性比較
15. 15 既存アプローチの問題点 • プレイブック /ランブックの制限 : 静的で網羅性に限界 • 過去事例活用の非効率性 : 検索・分析に時間がかかる • 属人化: 経験者への依存度が高い • 人間の介入の必要性 : 継続的な負荷とストレス 解決すべき根本課題 : 事業成長とマイクロサービス化により複雑化するシステムに対し、従来の手法では 状況は悪化しやすい 。 オンコール対応も辛くなってくる。 インシデントの調査と分析 : 従来手法の限界と課題
16. 16 Incident Buddy and Insight System 過去のインシデント情報を活用し、インシデント対応を支援する AIエージェント "Buddy" = 相棒 人間と協調して動作するシステム IBIS誕生：解決策としての AI Agent
17. 17 • 過去事例を活用 : ベクターDBで高品質に管理した過去の事例を有効活用 ◦ インシデント管理するモチベーションも上がる • 柔軟なコンプライアンス : 外部SaaSでは対応困難な要件への対応 • 学習機能: 継続的な改善と知見蓄積 • 最新社内情報統合 : リアルタイムな状況に基づく提案 ◦ インシデント対応のやりとりを収集し、分析に利用 ◦ MCP Serverとの連携は現在実装中 MCP: Model Context Protocol (https://modelcontextprotocol.io/docs/getting-started/intro) IBISによる根本的解決
18. 18 組織レベルでの改善 • スキルの平準化 : 経験の浅いメンバーが過去の知見に即座にアクセス • 心理的安全性向上 : 過去事例に基づく客観的な判断支援 • 24/7可用性: いつでもアクセス可能な相談相手としての機能 IBIS導入による早期効果
19. 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. 20 データフロー インシデント管理サービス（SaaS） → データ収集 → 前処理 → BigQuery AI処理フロー ユーザークエリ → RAG検索 → LLM回答 → Slack シンプルなパイプラインで高品質な AI支援を実現 IBISアーキテクチャ
21. 21 赤枠: Data Cleansing & PII Masking オレンジ枠 : Translation, Summarization, and Embedding IBISアーキテクチャ図
22. 22 フロー
23. 23 LLMOpsデータ前処理戦略 データ収集 → クレンジング → 言語統一 → 圧縮 → ベクトル化 前処理が重要な理由 : • 品質・セキュリティ ◦ データ品質 : クリーンデータでAI性能向上 ◦ セキュリティ : 個人情報保護・コンプライアンス対応 • コスト・精度 ◦ コスト効率 : 不要情報削除でトークン数削減 ◦ 検索精度 : 適切な前処理で意味検索精度向上
24. 24 重要な3つの処理 1. 個人情報マスキング a. spaCy NER(Named Entity Recognition)で自動検出・マスキング 2. 言語統一 a. 日英混在テキスト→英語統一 3. 要約処理 a. Map-Reduce並列でコスト最適化 性能最適化の成果 • 高速化: 各所で大幅な処理時間短縮 • コスト効果 : トークン数削減でコスト最適化 主要な前処理と性能最適化
25. 25 spaCy NERでの個人情報マスキング 主要機能 • 国際化対応 : 日本語・英語・中国語等 ◦ 各国の人名パターンに対応 • 表記ゆれ対応 : "山田太郎" / "Taro Yamada" 等 • マスキング : [PERSON NAME REDACTED]等で置き換え 技術的ポイント • モデルキャッシュ : ロード時間を大幅短縮 • パフォーマンス : 106s → 13s（87%高速化） ◦ ローカル環境（MBP）での測定結果: 長文も含めたテストケース 15件の処理時間比較 PII保護の実装戦略
26. 26 シンプルな実装例 （実際のコードとは異なります） 実際にはNERの誤判定によるマスキング漏れを防ぐため、ルールベースの補 完も実装しています。 PII保護のコード例
27. 27 次にVector storeの説明に移ります。 Vector store
28. 28 通常のレキシカル検索(キーワードマッチング)に対し、ベクター検索は近似最近傍探 索を実現します。 ベクター検索における近似最近傍探索の簡 潔な説明： 近似最近傍探索：高次元ベクター空間で、クエリベクターに最も近い（類似する）ベク ターを効率的に見つける手法。完全に正確ではないが、計算速度を大幅に向上させ ることで、大規模データセットでもリアルタイム検索を可能にする。 ベクター検索の基本
29. 29 技術的優位性 • 2024年後半に一般提供（ GA）開始: ベクトル検索機能正式リリース • 高次元対応 : OpenAIのtext-embedding-3-smallは最大1536次元のベクトルを生成 • コサイン類似度 : 効率的な類似性計算 • スケーラビリティ : 大規模データ対応 経済的合理性 • 既存契約活用 : 旧Flat-rate(BigQuery Edition)枠内で追加コストなし ◦ LangChainのBigQueryVectorStoreはBATCHクエリーを優先 ◦ BATCH優先度: 実行優先度（後回し）指定。料金は価格モデルに依存（オンデマンド /予約）。コ スト削減というよりスロット圧の平準化に寄与。 ◦ 注: Standard Editionではベクターインデックスが利用不可。 Edition/予約構成に依存。 • 予測可能コスト : 従量課金からの解放 BigQuery vector search採用の理由
30. 30 主要機能 1. Vector Search • インシデント履歴の意味的検索 • セマンティック検索で関連性発見 2. 情報提供 • 類似ケースの特定と詳細情報 • 対応手順・原因分析・解決策の提示 IBISの4つのコア機能 3. 提案生成 • LLMによる状況に応じた対応策推 論 4. 自律動作 • プロアクティブな情報提供
31. 31 • 自律性: 人間の介入を最小化し、独立してタスクを遂行 • 積極性: 必要な情報を能動的に収集・提供 • 協調性: 人間や他のシステムと効果的に連携 • 統合性: 既存システムやツールとシームレスに連携 • 適応性: 変化する環境や要件に柔軟に対応 • 信頼性: 高い可用性と正確性を維持 • 学習能力: 過去の経験から学び、継続的に改善 • 拡張性: 新しい機能やツールを容易に追加可能 プラットフォーム運用の自律化に必要な要素
32. 32 初期リリース時の課題 • 受動的システム : ユーザーの問い合わせ待ち • 問い合わせ内容に依存 : 適切な質問が必要 • 限定的な自律性 : 自動化の範囲が狭い 自律性と積極性の強化が必要と判断 そこでSuggestion Botを開発 初期リリース時にうまくいかなかった点
33. 33 自動動作フロー • 1. 検知 → インシデントチャンネル作成をトリガーにチャンネルに参加 • 2. 収集 → チャンネル内メッセージを自動収集 • 3. 圧縮 → 収集情報を要約 • 4. 検索 → Vector Searchで類似事例を検索 • 5. 分析 → 収集したコンテキストから状況を理解 • 6. 生成 → LLMで対応提案を作成 • 7. 提供 → 適切なタイミングで情報投稿 特徴: 人間の問い合わせを待たない能動的システム Suggestion Bot：自律的AI Agent
34. 34 Suggestion Bot実行例 類似ケースを見つけて情報提供。 類似ケースを元に提案、アドバイスも提供。 ユーザーは過去事例の詳細情報も確認できる。
35. 35 測定可能な成果 • 定量効果: まだ目に見える効果は限定的、継続的な改善が必要 • 定性効果: 満足度の向上 今後の技術的優先事項 • 精度向上: 現在はユーザーフィードバックに基づくチューニングが基本。評価基 盤の強化と提案の正確性向上は必要不可欠 • インシデント管理データ更新の補助 : 自動化による効率化 ◦ 例: 更新の提案 （あえて人間の介入を残すデザイン） • リアルタイム性 : MCP導入による最新情報統合 現在の課題と継続改善
36. 36 役割分担の明確化 • IBIS: 社内情報活用・セキュリティ/ガバナンス要件準拠・カスタマイズ • SaaS AI: 汎用的な機能・標準的な処理 柔軟性の確保 • 要件変更時のIBIS機能拡張 • SaaSサービスとの連携・置き換え • 他のAI Agentとの連携 利用者から見ると 1つのAIエージェント ハイブリッド戦略のポイント
37. 37 現在できつつあるのは左上の部分 システム間連系図 （案）
38. 38 Vector Search + MCPのハイブリッド構成 • Vector Search: 過去情報の効率検索・コスト効率 • MCP: 最新情報のリアルタイムアクセス・即時性 • 運用管理の効率化 : インシデント管理の一部自動化 ◦ 人間が責任を持ち続けるために人間が介入する部分は残す ◦ 自動化できる部分は積極的に自動化し、更新遅延と負担を減少させる 組み合わせで統一レスポンスを実現 今後の技術戦略： Phase 1: MCP連携で情報統合強化
39. 39 特化型エージェントの役割分担 (例) Supervisor Agent: • Coordinator Agent: 全体調整・意思決定支援 SubAgents: • Analysis Agent: 根本原因分析・影響範囲特定 • Search Agent: 類似事例検索・関連情報収集 • Action Agent: 対応策提案・自動復旧実行 Supervisor オーケストレーション : Supervisor AgentがSubAgentsを管理・調整し、全体の効率化と精 度向上を図る 今後の技術戦略： Phase 2: Multi-Agent System (MAS) 協調
40. 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. 41 まとめ
42. 42 1. 明確な判断基準の設定 • 課題の体系的分析 : 17項目→3項目への絞り込みプロセス • 評価軸の明確化 : コスト・セキュリティ・カスタマイズ性 • 時間効率の重視 : 完璧な分析より早期の意思決定 2. 段階的導入によるリスク最小化 • MVP(Minimum Viable Product): 小規模での検証開始 • フィードバックループ : ユーザー評価による継続改善 • スケーラビリティ : 成功パターンの段階的拡張 ハイブリッド AIOps戦略の成功要因の整理 1
43. 43 3. 継続的改善による価値最大化 • 定量評価: 明確な成果指標の設定と測定 • 技術革新への対応 : 新技術の積極的な検証・導入 • 組織学習: 失敗も含めた知見の蓄積・共有 ハイブリッド AIOps戦略の成功要因の整理 2
44. 44 技術選択の指針 • 既存エコシステムとの親和性 : BigQuery選択の決定要因 • コスト最適化 : 既存契約の活用、運用負荷の考慮 • 将来拡張性 : Multi modal対応、MCP導入への布石 組織・プロセスの重要性 • ステークホルダーとの合意形成 : 明確な価値提示 • 段階的な信頼構築 : 小さな成功の積み重ね • 継続的なコミュニケーション : 期待値の調整と成果共有 開発リソースを集中 × SaaS活用 = 効率と効果の最大化 プロジェクト進行のポイント
45. 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. 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. 47 「作る/任せる」の判断基準を明確にしたハイブリッド AIOps戦略で、プラット フォームエンジニアリングの未来を切り拓く。 ご清聴ありがとうございました！ Platform Engineering Kaigi 2025 Thank you!