AIの"記憶"を、外から検証できるか――AgentOpsとOpenTelemetry GenAI Semantic Conventionsという標準
»
―― Memoryは、AIに"経験"を持たせる最後のピースだった。でも、経験を持ったAIは、同時にブラックボックスにもなる。それを外から検証する方法の話。
## 第1章｜「なぜそう判断したのか」に答えられないAI
前回、[Memoryという最後のピース](https://blogs.itmedia.co.jp/osonoi/2026/09/500ai4memory.html)について書きました。ランブックに載っていない"苦労して突き止めた"原因を、AIが自分の経験として書き戻していく仕組みです。
昨日までの苦闘が、今日のエージェントにとっては洗練された「勘」に変わる ―― そう書きました。
ですが、ここで新しい問題が立ち上がります。
「そのエージェント、なぜその判断をしたんですか？」
規制業界の監査担当者に聞かれて、答えられますか。Memoryを持ったエージェントは、過去の経験を踏まえて動きます。でもその"経験"がどこから来たのか、どのツールを何回呼んだのか、なぜそのランブックではなくあのMemoryを選んだのか ―― これが外から見えなければ、Memoryは資産どころか説明不能なリスクになります。
RAG・MCP・Skills・Memoryで賢くなったAIを、今度は**外から検証できる状態にする**。これが今回のテーマです。
## 第2章｜AgentOps：DevOps・MLOpsの次に来た運用の考え方
まず言葉の整理から始めます。**AgentOps**とは、AIエージェントを本番環境で安全かつ安定的に運用するための管理手法です。
ソフトウェア開発と運用をつなぐDevOps、機械学習モデルの運用を扱うMLOpsに続く系譜として位置づけられています。AIエージェントが自律的に判断・実行を繰り返す以上、その推論プロセスを可視化する仕組みが実務運用の成否を分ける ―― という考え方です。
AgentOpsが扱うのは、大きく3つです。
- **観測性（Observability）**：エージェントが何を見て、何を判断し、どのツールを使い、どのデータにアクセスしたかを可視化する
- **評価（Evaluation）**：その判断や結果が「正しかったか」を継続的に測る
- **介入（Intervention）**：問題があれば止め、改善し、次の運用に生かす
前回の5ピース記事で「課題2」として予告していたテーマが、まさにこれです。Policy as Codeが「越えてはいけない線」を引くピースだとすれば、AgentOpsは「実際に線の内側を歩いたかどうかを、後から確認できるようにする」ピースだと言えます。
## 第3章｜個別ベンダーに賭けるのが危険な理由
このAgentOpsを実現するツールは、この1年で急速に増えました。Datadog、Langfuse、Arize、Galileoといった名前は、このブログでも何度か取り上げています。
- [Datadogに見る「AI観測」という新しい戦場](https://blogs.itmedia.co.jp/osonoi/2026/09/datadogai_ai.html)
- [ガードレール新時代 ―― Fiddler・Arize・Galileoに見る2026年の潮流](https://blogs.itmedia.co.jp/osonoi/2026/08/_fiddlerarizegalileo2026.html)
ただ、この分野には無視できない動きがあります。2026年1月にClickHouseがLangfuseを買収し、4月にはCiscoがGalileoの買収を発表しました。半年足らずの間に、可視性の高いLLM観測ブランドが2つ、それぞれ別の大手に飲み込まれた形です。
ここから得られる教訓はシンプルです。**計装（instrumentation）のレイヤーを、特定ベンダーに結びつけてはいけない**。ベンダーは買収され、統合され、プロダクト名が変わります。でも「標準」に沿って計装しておけば、バックエンドを後から差し替えられます。
その標準が、次に説明するOpenTelemetry GenAI Semantic Conventionsです。
## 第4章｜OpenTelemetry GenAI Semantic Conventionsという共通語彙
OpenTelemetryは、もともと分散トレーシングやメトリクスの標準規格として知られていますが、2024年にGenAI領域を扱う専門のワーキンググループ（GenAI SIG）が発足し、LLM呼び出しのトレーシングから始まって、エージェントのオーケストレーション、MCPのツール呼び出し、コンテンツの記録、品質評価まで、カバー範囲を広げてきました。
2026年6月には、GenAI・プロバイダー固有・MCPの各セマンティック・コンベンションが専用リポジトリに切り出され、独立してバージョン管理されるようになっています。
現時点でこの標準が定義しているのは、主に次の内容です。
| 対象 | 定義される内容 |
| --- | --- |
| モデル呼び出し | 操作の種類、入出力トークン数、処理時間、応答結果 |
| エージェント操作 | 作成・呼び出し・計画・ツール実行といった操作の型 |
| MCP | クライアント／サーバーのスパン、コンテキスト伝搬、メトリクス |
| コンテンツ記録 | プロンプトや応答の中身（オプトインで、PII配慮が必要） |
| 評価結果 | 評価者のスコアや説明を運ぶための標準的な入れ物 |
ここで一つ、正直に書いておかなければならないことがあります。**この標準は、まだ「完成」していません。** 2026年8月時点で、GenAIのセマンティック・コンベンションはDevelopmentステータスのままで、正式リリースはまだ出ていません。属性名の揺れ（`gen_ai.request.model`か`llm.model_name`か、といったレベルの不一致）も実際に起きています。
つまり、今取るべき態度は「標準がもう固まった」という前提ではなく、**「バージョンを意識しながら、今のうちから採用する」**という態度です。仕様が変わる可能性を織り込みつつ、自社の計装をこの語彙に寄せておく。これが、特定ベンダーへのロックインを避ける一番現実的な方法です。
## 第5章｜4つのピースは、外からどう見えるようになるか
前回までに整理した4つのピース ―― Skills・MCP・RAG・Memory ―― が、OpenTelemetryのレンズを通すとどう見えるようになるかを整理します。
- **Skills**：どの手順（スキル）が、いつ呼び出されたかがエージェント操作のスパンとして記録される
- **MCP**：どのMCPサーバーに、何回、どんなパラメータで接続したかが、MCP専用のスパンとメトリクスとして残る
- **RAG**：検索クエリと取得結果が、モデル呼び出しの前後のイベントとして記録される（内容の記録はオプトイン）
- **Memory**：過去の経験をどう参照し、どう書き戻したかが、エージェント操作の一部としてトレースに含まれる
第1章で挙げた「なぜその判断をしたのか」という問いに対して、これらのトレースを時系列でつなげば、少なくとも「何を見て、何を呼び、何を根拠に答えたか」までは再構成できます。完全な説明責任には届かないかもしれませんが、「ブラックボックスのまま運用する」状態からは確実に一歩前進します。
## 第6章｜明日からできる、2つのアクション
**(1) 計装を始めるなら、まず`gen_ai.*`の名前空間に寄せる**
独自のログ形式やベンダー固有のSDKだけに頼るのではなく、OpenTelemetryのGenAI規約に沿った属性名を意識して計装する。バックエンドを後から変えられる保険になります。
**(2) 「観測性」「評価」「介入」の3つのうち、今どこが空白かを洗い出す**
多くの現場は「観測性」だけ（ログとトレースを取っているだけ）で止まっています。取ったデータをどう評価し、問題が起きたときにどう介入するか ―― ここまで含めて設計されているか、一度棚卸ししてみてください。
## 結び｜"賢いAI"の次に来るのは、"説明できるAI"
Skills・MCP・RAG・Memoryで、AIエージェントは賢くなりました。でも、賢さだけでは足りません。**なぜそう動いたかを、後から人間が確認できること** ―― これが、規制業界に限らず、すべての本番運用で問われる次の基準になっていくはずです。
派手な機能拡張ではありません。地味に計装し、地味にトレースを残す作業です。でも、PoCで終わるAIエージェントと、本番で長く運用され続けるAIエージェントの差は、案外こういうところで決まります。
前回、あなたのAIエージェントが"前回と同じ失敗"を覚えているかを聞きました。今回はもう一つ。**そのエージェントが下した判断を、あなたは後から人に説明できますか？**
SpecialPR