DevOps/MLOpsに学ぶエージェントの可観測性

はじめにターゲット • DevOpsやMLOpsを実践してきた人 • 生成AIやエージェントのオブザーバビリティについて知りたい人今日伝えたいこと • エージェントのオブザーバビリティにDevOps/MLOpsの知見を活かせる 2

About US 会社名株式会社スリーシェイク設立日 2015/1/15 Mission: インフラをシンプルにしてイノベーションが起こりやすい世界を作る Vision:
労苦〈Toil〉を無くすサービスを適正な価格で提供し続ける Value: エンジニアリングレイヤーに横たわる人、手法、ツールがサイロ化されて労苦が発生しているプロセスをシンプルにしサービス機能開発に集中できるソリューション（SRE、DevSecOps、DataOps、HROps）を提供する 2015 2016 2017 2018 2019 2020 2021 2022 0 50 100 従業員: 200名over Engineer 60% 所在地東京都中央区銀座8丁目21番1号住友不動産汐留浜離宮ビル7F 代表者代表取締役社長　吉田拓真沿革 2021年1月 JAFCOから総額5億円の資金調達 2022年8月自動脆弱性診断ツール「Securify Scan」をリリース。JAFCO、MUCAPから総額8.48億円の資金調達 2024年11月 NTTデータ、SCSKから10億円の資金調達及び資本業務提携を締結 Google Cloud・AWSの両方のエンジニアリングに強みを持つ（2025年9月にGoogleCloudのAppDevスペシャライゼーションを取得） 3

SREを主軸にクラウドネイティブ化/エンジニアリング内製化を支援 SRE/DevOps SecOps BizOps HR ・SRE総合支援からセキュリティ対策を全方位支援・Geminiを用いた生成AIの活用支援・ワンストップで脆弱性診断を行うセキュリティ対策SaaS
・クラウド型ETL/データパイプラインSaaSの決定版・あらゆるSaaSをノーコードで連携・ハイスキルフリーランスエンジニア紹介エージェント IT内製化 / 高度化クラウドネイティブ化モダナイゼーション ITアジリティ向上 4

目次 1. DevOpsとオブザーバビリティ 2. MLOpsとオブザーバビリティ 3. AIエージェントのオブザーバビリティ 5

DevOpsとオブザーバビリティ DevOpsについて統一的な定義は存在しないが • DevとOpsの融合であること • 文化、プラクティス、ツールなどで構成されることという性質を持つ思想であることは概ね一致[1][2][3] 一方で「制御理論では、オブザーバビリティとは、外部出力の知識からシステムの内部状態をどれだけうまく推測できるかの尺度として定義」[4]されており、本来DevOpsとは独立した概念 7

DevOpsとオブザーバビリティただし現在は両者は密接に結びついている • 「オブザーバビリティは、孤立して存在するのではなく、DevOps、SRE、およびクラウドネイティブの動きの結果であり、不可欠な要素」[4] • 『The DevOpsハンドブック理論・原則・実践のすべて』では、フィードバックの技術的実践としてテレメトリデータの作成と分析が紹介
• DORAのFour Keysの1つである「デプロイ失敗時の復旧までの時間」を短縮するためにオブザーバビリティが必要[5] 8

DevOpsとオブザーバビリティ最も重要なのは「ビジネス課題を解決しているか」そしてそのために • 正常に動作しているか（機能要件を満たしているか） • 素早く動作しているか（非機能要件を満たしているか） • 上記に反した時には問題の詳細を知る必要がある。
具体的な手段としてはログ、トレース、メトリクスがある。 9

MLOps MLOpsについてもDevOpsと同様に統一的な定義は存在しないが • DevOpsをMLに適用したものである • 技術だけでなく文化、プラクティスなどを含むということは概ね一致[6][7][8] 11

MLOpsとオブザーバビリティ「ビジネス課題を解決しているか」が重要であることは変わらない大きな違いはモデルがブラックボックスであること。これに対してMLOpsではドリフト検知がある。 12

モデルのドリフト 2種類ある • コンセプトドリフト：入力と出力の関係が変わる ◦ 例：不動産価格予測モデルを作ったがパンデミックで市場環境が変わってしまった • データドリフト：入力、もしくは出力の分布が変わる ◦
例：スパム判定モデルを作ったが新しい手口が登場したドリフト検知は構造化データに対して様々なアルゴリズムが存在非構造化データの場合はベクトル化などで構造化データに帰着させる 13

AIエージェントとは • AIエージェントについての明確かつ広く受け入れられた定義は存在しない ◦ 特にどの程度自律的に振る舞うべきかどうかについて • 本セッションでは以下の条件を満たすシステムをAIエージェントと呼びます ◦ 生成AIをベースとする（いわゆるLLM-based Agents）
◦ 人間の指示に対してプランニングと実行を行う 15

AIエージェントとオブザーバビリティ重要なことは変わっていない • ビジネス課題を解決しているか • 機能要件、非機能要件を満たしているか • 問題が起きた場合の詳細収集するための形式はすでに持っている •
DevOpsにおけるログ、トレース、メトリクス唯一異なるのは生成AIという新しいブラックボックス • しかしブラックボックスにオブザーバビリティを与えるプラクティスもすでに持っている ◦ MLOpsにおけるドリフト検知 16

AIエージェントとオブザーバビリティ • 直接的な情報 ◦ ビジネスKPI：メトリクス • 間接的な情報 ◦ エージェント全体の入出力が妥当か ▪
ドリフト検知（後述） ◦ エージェント内部の動きが妥当か ▪ ツール実行やワークフローの経路：トレース ◦ エージェントからの生成AI呼び出しが妥当か ▪ 次ページ 17

生成AI呼び出しが妥当かモデルの非決定性に対して • 推論の入出力 • 生成時間 • 生成のパラメータ • 使用トークン数
• 課金額を収集する必要がある複数のベンダー、モデルを使う場合は合わせて • ベンダー • モデルID も必要 18 これらは全て生成AI固有の情報だが、ログかスパン属性として収集可能

AIエージェントのドリフト検知 AIエージェントの入出力は多くの場合、非構造化データ（テキスト、音声、画像、動画）以下の手法でモニタリング可能な形式にできる • 入力に対して ◦ 対応可能な入力かを生成AIにチェックさせる ◦ ベクトル化などを行なってから従来手法 •
出力に対して ◦ LLM as a Judgeでの妥当性チェック ◦ ユーザによるグッド/バッド評価 19

どう収集するか • モニタリングツールに依存したくない場合 ◦ OpenLLMetryやOpenLITなどのOpenTelemetry系OSSで計装 • LangChain、LangGraphを使っている場合 ◦ LangSmith、LangfuseなどのGenAIOps系サービスを導入 •
監視SaaSを使っている場合 ◦ そのSaaSの機能を使う • クラウドで監視をしている場合 ◦ Strands Agentsで作ってAmazon Bedrock AgentCoreにデプロイ ◦ Microsoft Agent Frameworkで作ってAzure AI Foundryにデプロイ ◦ Agent Development Kitで作ってVertex AI Agent Engineにデプロイ 20

まとめ • AIエージェントでも重要なことは「ビジネス課題を解決しているか」 • ログ、トレース、メトリクス、ドリフト検知などの既存の知見は AIエージェントのオブザーバビリティでも引き続き有用 • 生成AIやAIエージェントといったゲームチェンジャーによって具体的な手段は変わったが抽象の部分は変わっていない 21

参考 [1]: https://aws.amazon.com/jp/devops/what-is-devops/ [2]: https://azure.microsoft.com/ja-jp/resources/cloud-computing-dictionary/what-is-devops/ [3]: https://www.atlassian.com/ja/devops [4]: 『オブザーバビリティ・エンジニアリング』 [5]:
https://newrelic.com/blog/best-practices/dora-metrics [6]: https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning?hl=ja [7]: https://aws.amazon.com/jp/what-is/mlops/ [8]: 『事例でわかるMLOps 機械学習の成果をスケールさせる処方箋』 22

DevOps/MLOpsに学ぶエージェントの可観測性

DevOps/MLOpsに学ぶエージェントの可観測性

Yunosuke Yamada

Transcript