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

皆さんこんにちは
プラットフォームエンジニアリング会議2025にお越しいただきありがとうございます
私は株式会社メルカリのオグマと申します
本日はハイブリッドAIオプス AIエージェント戦略というテーマで
SaaS AI時代におけるプラットフォームエンジニアリングの生存戦略
実装戦略についてお話しさせていただきます
まずは簡単に自己紹介させていただくと
メルカリのプラットフォームグループで
オートノーマスクラウドというところで
現在フィンオプスチームに所属しています
去年までSREチームに所属していて
現在は信頼性とフィンオプスそれぞれの領域で
AIの活用を行っています
あとAIエージェントの開発を行っています
本日紹介するインシデント対応AI
IBISのプロジェクトマネジメントと開発リードを担当しています
今日お話しすることとして
本日は5つのポイントでお話しします
まずプラットフォームエンジニアリングの共通の課題
そして内製とSaaSの判断基準と社内合意
次に内製AIエージェントIBISの事例
そしてハイブリッドAIオプス戦略
最後に今後の展望のお話をします
キーワードはSaaS AIと内製AIエージェントを
組み合わせた実践的アプローチです
プラットフォームエンジニアリングの共通の課題として
内製すべきかSaaSに任せるべきかというのがあります
コスト セキュリティ カスタマイズ性
運用負荷 開発リソース
これらを統合的に考慮する必要があります
重要なのは単純な答えは存在しないということです
組織の状況により最適解は変わります
ここでメルカリの取り組み時系列を紹介します
2023年にLLMの業務改善の探索を開始しました
去年ですね
インジデント対応にそこから絞り込んで
内製とSaaSの比較を行って
判断基準の策定まで行いました
去年7月
POCとアーキテクチャ選定を開始して
大体1クォーターぐらいやって
10月から本格的に
Ibisの開発を開始しました
2ヶ月ちょいぐらいで
Ibisの初期版ですね
リリースしました
2025年今年
AIネイティブの社内推進が開始されています
当時ですね
兼務2名で初期リリースプラスアルファで
短期達成しました
短期でリリースですね
この辺は技術構成と工夫が寄与しています
後ほど紹介します
自ら自分の仕事をAIに奪わせようとしているのかというのは結構話題になると思うんですけど
多くの方が感じる疑問として
その答えですね
私の答えとしては仕事を奪うのではなく
仕事の質を変えるものだと思っています
具体的に言うと繰り返し作業から解放されて
より創造的で戦略的な業務に集中できるようになります
価値の高いシフトに我々人間が変えていけるということになります
あとここでSREの考え方も結構私は入っていて
信頼性向上
システムの複雑化でも品質の維持とか
効率化と自動化
そしてリスク管理
イノベーション推進
人間の減価を補うパートナーとして
AIを活用ということを考えています
SaaS AI
AIと内製AIエージェントの比較表になっています
3つの評価軸を設定しました
まずカスタマイズ性
社内連携ですね
この辺は非常に重要視していて
例えばSaaS AIの場合はある程度できるんですけど
柔軟性にちょっと厳しいというところがあり
制限があります
一方内製AIエージェントでしたら
自由度が高く柔軟性を持てるので
この辺はポイントが高いです
次にセキュリティですね
これはもうSaaS AIのセキュリティ仕様によるものなので
完全に外部依存になります
内製すればこれは要件に応じた対応が可能となります
もちろんここは社内の開発リソースとかも関係します
そして最後にコスト開発リソースですね
これは重要度が他に比べるとちょっと低いんですけど
SaaSの場合は低初期コスト
そして継続課金のスタイルになります
内製の場合は初期コストがすごい高まります
そして人件費がかかるというところがポイントです
比較結果から興味深い傾向が見えました
高重要度項目では内製AI
中重要度項目ではSaaS AIが有利という結果です
結論としてはハイブリッドアプローチが最適なんじゃないかというのを思いました
そこで内製とSaaSの使い分けで最大効果を実現しようとなりました
判断基準設定と体系的アプローチとして
時間効率を考慮した戦略的分析を4段階で実施しました
まず最初に課題の洗い出しですね
当時17件ぐらいAI使ってこんなことはやりたいねみたいな候補をリストアップしました
次にそこから要件定義ですね
各課題の詳細分析と期待効果の評価を行いました
次に議論と評価
AI LLMに明るいチームメンバーと議論して
こんなこともっとこうした方がいいじゃないみたいな議論をしてきました
最後にそこから絞り込んで3つですね
17件から3つ最優先候補課題を集約しました
次に内政VSaaSの判断基準を設定しました
内政候補から外す基準ですね
SaaSに任せようとか他に任せようという領域を決めたのが
まずはSaaSで作りやすい領域で絶対あると思っているんですね
そこは汎用性が効く処理だったりとか
あとはSaaSによっては結構データがもうすでに持っていて
データをこのデータを使うものだったらSaaSは得意っていうのもあります
あとはですね他開発者
他の開発者ですね
あとはSREの利用の可能性として
市場での需要が高い機能
これはもう結構SaaSはもう当たり前のように実装してくるので
そういうところも考えました
あとはプロバイダーの優位性ですね
さっき言った大量データの保有する領域と
あとは最後に標準化が進んでいる領域
業界標準のプロセスとかツールがもう出ているものとかだと
やっぱり強みがあります
次に逆に内製すべき領域っていうのを提起しました
まず個人情報とか機密情報ですね
これは社内とかでもセキュリティ要件が厳格なので
さっきの表に示した通り
こちらがコントロールできる方がいいんですよね
であとは次に複雑な社内連携
これも柔軟性が必要です
そして特化カスタマイズ
社内固有のビジネスロジックに合わせたり
あとそのフィードバックとかで要望に合わせて
UIを変えたりとか
そういうカスタマイズ性を表しています
将来の拡張性
独自の発展方向性を持つというのが大事です
この3つの候補から重要性と緊急性の高い
インシデント対応領域に集中を決定しました
次に解決するべき3つの課題を特定しました
まずインシデント対応の俗人化
次に効率化と迅速性化の重要性
そして過去のインシデント履歴の活用不足というのが課題でした
事業成長とマイクロサービス化で対応者の負担増加があり
本来すべき価値創出への投資にシフトが必要でした
インシデント対応を7分段階に分けて適正を比較しました
まず予防予測検知段階
SaaSクラウドメンダーが有利な部分は大量データ保有の部分です
次に調査分析段階
内製AIエージェントが有利になります
これは社内情報を活用できるからですね
その次が初動対応
報告振り返り
これはSaaSでも内製でも両方に適正があると思っています
これはあくまでメルカリ内での評価です
既存アプローチの4つの問題点として説明します
プレイブックランブックの制限があると思っていて
必ずあったほうがいいんですけど
これはもう性的で網羅性に限界があるなと思っています
次に過去事例の活用の非効率性検索分析に時間がかかるという問題があります
あと俗人化ですね
そして最後に人間の介入の必要性ですね
継続的なインシデント対応の負荷とかストレスとかですね
これは根本的課題として
事業成長とマイクロサービス化による複雑化するシステムに対して
従来手法では状況が悪化しやすいと思っています
そこで解決策としてAIエージェント
アイビスが誕生しました
アイビスはインシデントバディ&インサイトシステムの略です
過去のインシデント情報を活用し
インシデント対応を支援するAIエージェントです
バディとですね相棒として人間と協調して動作するシステムを作っています
アイビスによる根本的解決としては過去事例を活用します
まずベクターDBで高品質に管理した過去事例を有効活用します
次に柔軟なコンプライアンス対応ですね
外部サービスでは困難な要件にも対応しています
次に学習機能
継続的な改善と知見を蓄積しています
そして最後に最新社内情報等を知っています
リアルタイムな状況に基づく提案というのは
今考えていて
まだちょっと実装できてないんですけど
リリースできてないんですけど
今準備中でMCPサーバーとの連携もやっています
次にアイビス導入による早期効果を説明します
組織レベルでの改善効果として
まずスキルの平準化ですね
経験の浅いメンバーが
過去の知見に即座にアクセスできるようになりました
次に心理的安全性の向上です
過去事例に基づく客観的な判断支援ができるようになりました
最後にいつでもですね
可用性ですね
いつでもアクセス可能な相談相手ができました
インシデント対応の質と効率が向上しています
技術量構成を説明します
アイビスはランググラフで作っています
これはAIエージェントフレームワークです
次にビッグクエリをベクターストアとして使っています
これはコサイン類似度検索のために使っています
スラックボットとして立てていて
ボルト4パイソンで非同期実装をしています
LLMはオープンAIのGPTモデルを使っていて
それに合わせてエンベディティングモデルが
テキストエンベディティング3スモールを使っています
注意点としてベクター検索の意味的類似性はエンベディティングモデルに依存するというところです
そしてIbisのアイキテクチャをちょっとシンプルに説明すると
まずデータフローとしてはインシデント管理サービスからデータを収集して
次に前処理を行ってビッグクエリにエンベディティングで送ってます
AI処理フローに関してはユーザークエリですね
ラグ検索に行ってLLMに回答させてスラックに投げるというシンプルな構成になってます
こちらがIbisのアーキテクチャ図です
重要なポイントだけ説明すると赤枠の部分がデータクレイジングとPIIマスキングですね
これが前処理といった部分です
次にオレンジ枠の部分なんですけど
ここも一部前処理になってるんですけど
ここで何やってるかというとトランスレーションですね
インシデントレポートってメルカリ内だと英語だったり日本語だったり
または混在してるケースがあるんですね
これを全部英語に統一するっていうことをやってます
次にサマライゼーションようやくですね
ようやく最後にベクター化エンベディティングを行ってます
こういう形でフローがあります
ちょっと時間的に活躍します
処理フローとしてはさっき言ったデータ収集、クレイジング、言語統一、圧縮、ベクター化ってやっていまして
前処理はもうめちゃくちゃ重要です
これ重要な理由としては品質、セキュリティを保つためです
クリーンデータでAIの性能を向上させて個人情報を保護させてコンプライエンス対応ができるようになります
そしてコストと精度ですね
不要な情報を削除でトークン数の削除と意味検索精度向上ができます
これラングチェーンとかのツールとかでテキストスプリッターとかあるんですよ
これランググラフとか使ってなくても一部でそのツール使えるんですけど
それで簡単に不要なマークダウンの記号とかそういうのもバーって消したりとか
そういうのもやっています
主要のマイル処理と性能最適化として
3つの重要な処理として個人情報マスキングですね
これはPythonのスパーシーのNERですね
Named Entity Recognitionでモデルを使っていて
自動検出とマスキングを行っています
言語統一がさっき言った日英の混在のやつを英語に統一しています
最後に要約処理としてマップリデュースですね
並列処理でコスト最適化を行っています
成果としては処理時間の短縮とトークン数削減でコスト最適化
そして実用的なレスポンス時間での運用を実現できました
Pi保護の実装戦略
もう少し深掘りします
スパーシーNERでの個人情報マスキング収容機能なんですけど
国際化対応しています
メルカリ内だといろんな国の人たちがいるんで
各国の人命パターンにも対応しなきゃいけないんですよ
なのでその辺の対応をしています
次に表記売例ですって
山田太郎太郎山田とかあとはその配分を入れたりするケースもあるんですよね
名前の間とかにあとはミドルネームが特殊にあったりとか
そういうケースに対応しています
それをマスキングしていて
技術ポイントとしては
モデルをキャッシュでロード時間短縮を行いました
パフォーマンスとしては
ローカルのMacで計測したところ
106秒から13秒に下がって
87%高速化できたので
この辺CIとかCDとかも早くなりました
これコード例ですね
PIFOのコード例としては
これ実際のコードとはちょっと違うんで
シンプルに見せるために書いてるやつなんですけど
マスクパーソナルネームズ関数で
指定言語のスパーシーモデルを取得して
テキストから固有表現を抽出して
パーソンですね
パーラベル
これなんで2つあるかというと
モデルによって違うんですよ
なのでどっちかっていうラベルを引っ掛けて
それをマスキングするっていう実装です
実際の実装はもうちょっと凝ったことをやっていて
NERのやっぱり誤判定っていうのは発生するので
そのマスキング漏れ防止のために
ルールベースでも保管の実装を入れてます
それを組み合わせて個人情報保護をしています
ちなみにこの個人情報っていうのは
インシデントレポートの対応者の個人名ですね
なので社員の名前です
次にベクターストアの説明に移ります
ここの部分ですね
前処理が終わってベクターストアの
通常の歴史から検索
いわゆるキーワードマッチングに対して
ベクター検索は
近似細菌棒探索を実現します
これは何なのかっていうと
高次元ベクター空間で
クエリーベクターに対して
最も近いベクターを効率的に発見できます
完全に正確ではないんですけど
その分計算速度を大幅向上させていて
大規模データセットでもリアルタイム検索を可能にしています
なのでキーワードだけでは見つからない
意味的に関連するドキュメントを発見できるようになります
ビッグクエリーベクターサーチの採用理由なんですけど
技術的優位性がまずあって
去年の後半に一般提供を開始されました
あとは高次元対応ですね
オープンAIテキストエメディティング3モデルを
使用しているんですけど
これは最大で1536次元に対応しています
これもサポートできています
あとはコサイン類似度による
効果的類似性計算ができることと
大規模データ対応のスケーラビリティを
もともと持っています
あとは経済的合理性がありまして
社内で契約で
ビッグクエリってフラットレートとか
今ビッグクエリエディションって
名前に変わったと思うんですけど
その枠内で契約の枠内で使えば
追加コスト発生しないというのがあるんですね
ラングチェーンの使っている
ビッグクエリベクターストアっていう関数は
バッチクエリ優先で動いています
なのでこの追加コストを発生しないようにできます
その枠内に入っている
注意点としては
スタンダードエディションでは
ベクターインデックスが利用不可となっています
この辺はパフォーマンスに影響する話ですね
最後の
ちょっと巻きでいきますね
ベクターサーチ
情報提供
提案生成
自立動作の4つの機能で
包括的なインシデント対応支援を実現しています
自立化に必要な8つの要素としては
自立性
積極性
協調性
統合性
適応性
信頼性
学習能力
拡張性
これらをバランスよく実装することが成功の鍵です
初期リリース時の3つの課題としては
自動システム
要するに問い合わせ内容の依存とか
限定的な自立性がありました
この問題を解決するために
サジェッションボットというのを開発しました
これが自立AIエージェントになってまして
7段階の自動動作フローを行います
まず検知の次に収集
そして圧縮
検索
分析
生成
提供
という形で
人間の問い合わせを持たない
能動的システムになっています
こういう形ですね
左側が類似ケースを見つけて情報提供します
こういうケースが似てるよって形で出してます
それをもとに提案アドバイスを提供しています
ちょっとマスキングしちゃってるんで見づらいかもしれないですけど
結構具体的に提供してくれます
これでユーザーは気になった過去事例の詳細情報とかも確認できるようになっています
定量効果は限定的ですけど
訂正効果として満足度向上は確認されています
技術的優先事項として
精度向上
インシデント管理データの更新補助
MCP導入によるリアルタイム性向上を願っています
ハイブリッド戦略のポイントとしては
役割分担の明確化
柔軟性の確保
利用者から見た統一インターフェース
これらがハイブリッド戦略の絡めです
従来の包括的インシデント管理エコシステムの構想図です
これを今やっていこうとしています
現在アイビスはこの左上の部分をやっています
今後の技術戦略としては
MCP連携をしていきます
ちょっとここは駆け足でいきます
マルチエージェントシステム化しようとしていて
今アイビスはシングルエージェントなんですね
これはあえてそうしています
今後スーパーバイザー型オーケストレーションという形にして
一つルートエージェントを立てて
サブエージェントで連携させます
そして社内AIエコシステムと統合していて
フロントマンみたいなそういうAIを作って
もうみんな困ったらそこに問い合わせれば
一元管理できるよみたいなシステムを作っていきます
まとめです
ハイブリッドAI戦略は適材適所での使い上げが重要です
継続的改善でより効果的なシステムを構築します
成功要因としては明確な判断基準の設定
そして段階的導入によるリスク最小化ですね
継続的改善による価値最大化
定量評価
技術革新対応
組織化学習
これらでハイブリッド戦略を成功に導きます
技術選択と組織プロセスで成功を実現していきます
メリカリエンジニアリングブログとかですね
この辺は参考にとして載せています
最後にですね
作る任せるの判断基準を明確にした
ハイブリッドAI戦略で
プラットフォームエンジニアリングの未来を切り開く
ご清聴ありがとうございました
はい発表ありがとうございました
それでは質疑応答の方に移らせていただこうと思います
はい最初の質問ですね
アイビスを触ってみたいのですが
外部公開する予定はないですか
とのことです
じゃあよろしくお願いします
これは結構いいリクエストだと思っていて
今のところ正直予定はないんですけど
ぜひ社内に持って帰って検討したいと思います
ありがとうございます
はいありがとうございます
ごめんなさいマイク使ってないです
はいごめんなさい
今のところ予定はないんですが
ぜひ社内に持ち帰って検討したいと思います
ありがとうございます
はいありがとうございます
続いての質問ですね
インシデント対応した社員の個人情報
こちらを保護することの趣旨を知りたいです
とのことです
はいえっとですね
社員であろうと個人情報は個人情報なんですね
なのでまずLLMに投げるのに
必要な個人情報がそうじゃないかって考えると
不要だったんですよ
なのでインシデント対応者の名前は別にいらなくて
どのチームが対応したかとか
そういう情報だけが必要だったんで
もう全部マスキングすることにしました
はい
ありがとうございます
名前は必要ではなくてチームの名前が必要
そうですね
個人名はもう全然いらないんで
はい
はいありがとうございます
続きまして個人情報の企画対応などで
処理結果の品質が求められるというところに
ルールベース処理を入れているとのことで
ルールベース処理とAI処理の使い分けが気になりました
テキストデータという性質上
費用効率や速度を意識すると
ルールベース処理に軍配が上がりそうな気がして
質問しましたとのことです
まずルールベースは限界があって
各国の名前を全部カバーって
難しいので
NERモデルでもすでに学習済みで
マイケルさんとかいろんな人がいるじゃないですか
それを自動で判定させています
そこだけだと取りこぼしもあるので
それを一部JSONファイルで管理していて
この人のこういう名前は人名だよとか
あとはこのケースの場合は
人名判定させないでスキップさせてねとか
そういう感じにコントロールしています
あとはもうEメールのアドレスとか
そういう型にはまったやつとかだったら
普通に正規表現とかで引っ掛けられるんで
そういうのはルールベースになっています
はいありがとうございます
続いての質問ですね
まだ時間があるのでやろうと思います
個人情報のマスキングについて
100%外に出したくないという要件が本音だと思いますが
SRE的に100%無理なのがセオリーだと認識しています
何かエラーバジェット的な運用をしているのでしょうか
個人情報のリスクについて
経営層向けにどう説得したかも気になります
まずこのセキュリティ要件のレベルとしては
めちゃくちゃ高いわけではないんですね
というのもさっき言った通り
LLMに必要じゃない情報だから
もう個人情報としてマスキングしましょうというのと
あとお客様の個人情報とかそういうのではないので
どうやっているかというと
計測は今していなくて
生成された
さっき言ったPIIプロテクションモジュールというのを作っていて
その結果を見て
これ外れているなというのを調整しているというのを繰り返していました
今結構精度は出ていて
あんまり外してはないかなと思っています
あと1個補足なんですけど
PIIモジュールとか自作するのもいいんですけど
クラウドベンダーとかでも
DLPですね
データロスプロテクションとかそういったのもあるので
そういうのを使うというのもいいのかなと思っています
ありがとうございます
時間的に次の質問最後にしようと思っております
Ibisの導入により人間のオンコール人数削減などの効果はありましたか
どのことです
今のところないです
ここら辺はもう組織の問題とかで人数調整とかもいろいろあると思うんで
すぐには難しいと思います
あとはですね
今MTTRを計測しているんですけど
限定的な効果だなとまだ思っています
なので今後改善が必要だと思っています
結構評価が難しくて
例えばMTTRが短くなりましたって測ろうとしても
他の施策とかもやっぱりいろいろあるんですよね
Ibis以外の
どこで効果が出たかっていうのは
結構測定難しいところでもあります
はいありがとうございます
それでは改めまして東田さん発表をありがとうございました
会場 拍手