AIシステムを運用する上でObservability（可観測性）は欠かせない要素です。アプリケーション、インフラ、CI/CDパイプライン、LLMという4つの層を統合的に監視することで、問題の早期発見と安定した運用が可能になります。
📑目次
Observabilityの基本概念とAI時代における必要性
Observabilityとは、システムの内部状態を外部から推測できるようにする能力を指します。従来のモニタリングが既知のメトリクスを追うのに対し、Observabilityは未知の問題にも対応できる点が異なります。AI時代ではLLMの呼び出しやエージェントの動作が加わり、従来のツールだけでは不十分です。
OpenTelemetryはこうした多層監視を統一的に扱うための標準として注目されています。公式ドキュメントでは、GenAI向けのセマンティック規約が実験段階から実用化へ進んでいます。これにより、トークン使用量やレイテンシを他の層の指標と合わせて分析できます。
読者としては、まず自社システムのどの層でObservabilityが不足しているかを確認することをおすすめします。公式のOpenTelemetryドキュメント（https://opentelemetry.io/docs/specs/semconv/gen-ai/）を参照して、現在のセットアップと照らし合わせてみてください。
アプリケーション層の監視設計ポイント
アプリケーション層ではHTTPやgRPCの呼び出しに加え、LLM APIの呼び出しスパンを計測します。OpenTelemetryのインストルメンテーションを導入すると、入力・出力トークン数やツール呼び出しの有無を自動的に記録できます。
具体例として、PythonのOpenTelemetry SDKを使う場合、GenAIセマンティック規約に従った属性を付与するだけで、LLM呼び出しのトレースが収集可能になります。これにより、特定のプロンプトでレイテンシが跳ね上がる原因を特定しやすくなります。
導入のポイントは、既存のアプリケーションフレームワークに最小限のコード変更で済むライブラリを選ぶことです。ベンダーロックインを避けるため、OpenTelemetry Collector経由でデータを集約する設計が推奨されます。
インフラ監視とKubernetes/OpenTelemetryの統合
インフラ層ではKubernetesクラスタのメトリクスやログをOpenTelemetry Collectorで収集します。ノードやPodの状態に加え、LLM推論コンテナのリソース使用量も同じパイプラインで扱えます。
公式ブログ（https://opentelemetry.io/blog/2025/ai-agent-observability/）によると、KubernetesとOTelの組み合わせにより、AIエージェントの動作をインフラ指標と紐づけて分析できるとされています。これにより、GPUメモリ不足がLLMのエラー率上昇を引き起こしているケースを素早く特定できます。
読者が実践する際は、OTel Collectorの設定ファイルにGenAI関連のレシーバーを追加するところから始めると良いでしょう。既存のPrometheusエクスポーターと並行運用も可能です。
CI/CDパイプラインへのObservability適用
CI/CDパイプラインではビルドやデプロイの各ステップにトレースを伝播させます。OpenTelemetryのコンテキスト伝播により、コード変更がLLMの応答品質に与える影響をパイプライン全体で追跡できます。
例えば、テストステージでLLMのトークン消費量を計測し、閾値を超えた場合にビルドを失敗させるルールを設けられます。これにより、本番環境での予期せぬコスト増を防げます。
設計上の注意点は、パイプラインの各ジョブでトレースIDを確実に引き継ぐことです。GitHub ActionsやJenkinsなどのツールとOTelのインテグレーション例を公式リソースで確認してください。
LLM特有の監視メトリクスと設計パターン
LLM特有の監視では、モデル呼び出し回数、入力/出力トークン数、ツール使用回数、エラー率が主要なメトリクスになります。OpenTelemetryのGenAIセマンティック規約により、これらの値を標準化された属性として記録できます。
設計パターンとして、Vector DB操作やエージェントのワークフローを別々のスパンで表現する方法があります。これにより、RAG（Retrieval-Augmented Generation）の検索遅延と生成遅延を分けて分析可能です。
公式のsemantic-conventionsリポジトリ（https://github.com/open-telemetry/semantic-conventions/issues/1732参照）では、こうした実験的規約が活発に議論されており、2026年現在も更新が続いています。読者はまず自前のLLM呼び出しログにこれらの属性をマッピングしてみることを推奨します。
従来ObservabilityとAI拡張版の比較表
| 項目 | 従来Observability | AI拡張版Observability |
|---|---|---|
| 主な対象 | アプリ・インフラのメトリクス | アプリ・インフラ＋LLM呼び出し・トークン使用 |
| ツール例 | Prometheus, Grafana | OpenTelemetry + GenAI semantic conventions |
| 得られる洞察 | CPU/メモリ使用率、エラー率 | トークン消費傾向、RAG遅延、エージェント動作 |
| 統合の容易さ | 既存スタックで十分 | Collector設定の追加が必要 |
| コスト影響 | 比較的低め | トークン量次第で変動大 |
この表からわかるように、AI拡張版ではLLM特有の信号を追加で扱う必要がありますが、OpenTelemetryを基盤にすることで既存の可視化ツールをそのまま活用できます。
導入時の注意点・制限・読者向け次のアクション
導入にあたっては、まず既存の監視スタックとの互換性を確認してください。OpenTelemetryはベンダーニュートラルですが、LLMプロバイダー側のAPIがセマンティック規約に対応しているかは事前検証が必要です。
制限として、実験的規約は将来的に変更される可能性があります。トークン使用量の計測はコスト管理に有効ですが、プライバシー要件の厳しい環境ではログのマスキングを併用する必要があります。
読者向け次のアクションとして、以下の手順を試してみてください： 1. OpenTelemetry CollectorをKubernetesにデプロイする 2. GenAIセマンティック規約の属性をLLM呼び出しコードに追加する 3. Grafanaダッシュボードでトークン使用量とインフラメトリクスを並べて表示する 4. 1週間の運用データをもとに、コスト閾値アラートを設定する
これらのステップを踏むことで、AIシステム全体のObservabilityを段階的に強化できます。
よくある質問（FAQ）
関連記事:
- AI Agentjacking攻撃：Sentry MCP経由でClaude Code・Cursor・Codexが乗っ取り被害
- NVIDIA、AgentPerfベンチマーク発表 — Blackwellがagentic workloadで20倍性能
- AI生成コードの本番運用半年レビュー：成功パターンと失敗パターンから学ぶ実践的分析
まとめ
AIシステムのObservability設計では、OpenTelemetryを軸にアプリケーションからLLMまでを一貫して監視することが有効です。独立した公式ソースに基づく設計により、ベンダーロックインを避けつつ実践的な監視が可能になります。
読者の次のアクションとして、まずは自社LLM呼び出しの1つにOpenTelemetryインストルメンテーションを適用し、トークン使用量の可視化から始めてみてください。公式ドキュメントを活用しながら、徐々にCI/CDやインフラ層へ拡張していくことをおすすめします。
関連する新しい記事:
- サーバー代0円は本当か？『めっちゃカメレオン』Qiita記事の技術検証 – This published update adds current operational context for AIシステムのObservability設計 | アプリ・インフラ・CI・LLM統合監視ガイド.
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す