AI可観測性とは？本番AIチームのための実践ガイド

ダッシュボードは良好なパフォーマンスを示しており、すべてのパフォーマンス指標（レイテンシー：200ms、エラー率：0.01%、リソース使用率：制限内）が、AIシステムが正常に機能していることを示しています。

しかし、問題はまだあります。

• チャットボットが、顧客はメールに「STOP」と返信するだけで住宅ローンを解約できると回答しました。
• RAGパイプラインが、廃止された製品仕様書（2年前のもの）からテキストを抽出しました。
• 要約エージェントが請求書から3つの明細項目を削除し、経理が2週間後に数字を確認するまで、誰もそれに気づきませんでした。

技術的な観点から見れば、何もクラッシュしたりタイムアウトしたりしていません。システムは200を返しました。しかし、単にデータを供給するだけでなく意思決定を行うAIアプリケーションにとって、正しく機能するだけでは十分ではありません。

AIオブザーバビリティは、このギャップに対処するために構築されました。従来の監視がAIモデルを適切に処理できないという問題に対処するものです。本書では、AIオブザーバビリティとは何かを定義し、AIに対する従来の監視ツールの不十分さを説明し、必要な主要コンポーネントを概説し、企業チームがAIアプリケーションを信頼性高く効率的に展開するために必要な可視性をどのように開発しているかの例を提供します。

AIオブザーバビリティとは？定義と意味

AIオブザーバビリティ とは、 人工知能 システムを AIデプロイメントにおいて透明化し、測定可能にする実践です。 AIオブザーバビリティとは何か という問いに対する完全な答えは、ダッシュボードやレイテンシーチャートの域を超えています。エンジニアリングチームに、AIシステムが何をしているのか、どのようにして出力に至ったのか、そしてその出力が品質、安全性、費用対効果の点でどうあるべきかについての洞察を提供します。AIオブザーバビリティの意味を理解することは、本番環境でAIモデルを運用するあらゆる企業にとって不可欠です。

AIオブザーバビリティとは何かを完全に理解するためには、収集・分析できる3つのシグナル次元に分解すると役立ちます。

• インフラレベルのシグナル: レイテンシー、スループット、エラー率、リソース使用率などが含まれます。この種の情報は、従来の監視でカバーされます。
• モデルレベルのシグナル: トークン使用量、プロンプトと完了のペア、モデルバージョン、温度設定、検索元などが含まれます。これらは、AIモデルが消費し生成したものの基本的な可観測性データを構成します。
• 出力品質シグナル: 忠実性、関連性、ハルシネーション率、安全性違反、および生成された出力が正確で有用であるかを評価するユーザーエクスペリエンス指標などが含まれます。これらは、応答品質を決定する品質指標です。

ほとんどのチームは最初のレイヤーしか達成していません。2番目のレイヤーに到達するチームもあります。3つのレベルすべてでモデルのパフォーマンスを同時に追跡しているチームはごくわずかです。本番環境で3番目のレイヤーを実行しているチームはさらに少ないです。AI障害の大部分は、「プロンプトと完了をログに記録する」ことと「生成された出力が必要な品質指標を満たしているかを判断できる」ことの間のギャップで発生します。

AIシステムで従来の監視が機能しない理由

AI可観測性とは何かを理解することは、このギャップを理解することから始まります。従来の監視とAI可観測性の間のギャップは、AIシステムが失敗する根本的な違いに帰着します。

従来のソフトウェアは決定論的に動作します。同じ入力からは常に同じ出力が得られます。従来のソフトウェアで問題が発生した場合、メトリックの急上昇、例外のスロー、またはコードのどこで問題が発生したかを特定するスタックトレースが見られます。

機械学習を搭載したAIモデルは確率的です。同じプロンプトでも、モデルの温度、取得されたドキュメント、実行されているモデルバージョンによって異なる出力を生成する可能性があります。AIシステムは、監視スタックにエラーがゼロと報告されながらも、ユーザーに不正確、無関係、または危険な情報を提供する可能性があります。

「ハルシネーション検出」というエラータイプはありません。モデルが存在しないポリシー定義を捏造しても、監視スタックはエラーの急増ではなく、クリーンな200を認識します。検索ステップから返されたコンテキストが古いドキュメントセットで実行されても、エラーの急増は発生しません。モデル更新後にプロンプトの回帰により応答品質が25%低下したとしても、アラートメカニズムはその兆候を示しません。

従来の監視ダッシュボードは、意味的な障害を検出できません。返されたコンテキストが不正確であること、モデルが提供されたコンテキストを考慮しなかったこと、プロンプトインジェクションが取得されたテキストチャンク内に隠されていること、または実際のユーザー入力分布がテスト中に使用されたものと乖離するにつれて出力品質が低下していることを示すことはありません。 

AIシステムは、いくつかの具体的な方法でこの前提を破ります。

AI可観測性の4つの柱

従来の監視には、メトリクス、ログ、トレースという3つの柱があります。AI可観測性とは何かを答えるには、その4つの柱を理解することが不可欠です。AI可観測性は、これら3つの情報源を保持し、それらがどのように実装されるべきかを再定義します。4番目の情報源である「評価」は、インフラ監視領域のいかなる同等物にもマッピングできません。

トレース：AIシステムが行うすべてのステップに対するエンドツーエンドの可視性

トレースは、個々のリクエストのライフサイクル全体で発生するすべての事柄、すなわちユーザー入力、すべての中間ステップ、および最終応答を説明します。従来のソフトウェアでは、これは1つか2つのホップしか含まれません。AIエージェントシステムでは、単一のユーザーリクエストが多数のLLM呼び出し、ツール実行、検索アクション、サブエージェントタスクをトリガーする可能性があり、それぞれが対応する時間、入力データ、出力を持つ独自のスパンを作成します。

これは重要です。なぜなら、最終応答が間違っている場合、バグの原因はそのチェーンのどこにでも存在する可能性があるからです。検索が間違ったドキュメントを返したり、リランカーが正しいチャンクの優先順位を下げたり、モデルが必要なコンテキストを省略したり、AIエージェントが間違ったツールを呼び出したりした可能性があります。すべてのステップを表すトレースがなければ、間違った回答のデバッグは推測になってしまいます。トレースがあれば、エラーが発生した特定のスパンを特定できます。

トレースは、「何が、いつ、どのような順序で発生し、各ステップが全体の応答時間のどの部分に貢献したか」という基本的なデバッグの質問に答えます。トレースは、他のすべてのAI可観測性機能が構築される基盤となります。

メトリクス：パフォーマンス、コスト、品質に関する定量的なシグナル

AIモデルのメトリクスには3つの階層があります。その中で、ほとんどのチームが実装できていない階層こそが、ビジネス成果にとって最も重要なものです。

第1階層（パフォーマンスメトリクス） P50、P90、P99レイテンシー、time-to-first-token、プロバイダーやAIモデル間のスループットといった、おなじみの測定項目をカバーしています。どのチームもこの階層でのパフォーマンス監視は行っています。

第2階層（コストメトリクス） リクエスト、ユーザー、チーム、アプリケーションごとのトークン使用量を追跡します。トークンに費やされた総額を知るだけでは、コスト管理には不十分です。どのワークフローが消費の原因となっているかを理解する必要があります。これらはAIデプロイメントの費用を管理するための重要なメトリクスです。

ほとんどのチームは、 第3階層（品質メトリクス）にギャップがあります。 これらの主要業績評価指標は、AIシステムが時間の経過とともにどの程度良好に機能したかを測定します。具体的には、ハルシネーション発生率、取得されたコンテキストの関連性、AIが正確な回答を生成せずにリクエストを完了する割合などです。これらをテストセットではなくリアルタイムの運用トラフィックに対して実行することが、真のAIオブザーバビリティを基本的なパフォーマンス監視から区別する点です。

ログ：プロンプト、応答、エージェントアクションの構造化された記録

AIログは すべての送信されたプロンプトと受信された応答の結果として生成された実際のコンテンツを表示します。単に呼び出しが行われたかどうかのメタデータ情報を表示するだけではありません。これら2種類の情報の区別は、2つの理由から重要です。

デバッグモードでは、全体像を把握する必要があります。システムプロンプトに何が含まれていたか、どのドキュメントが取得・注入されたか、モデルが何を返したか、AIエージェントがどのツールをどのような順序で呼び出したか、などです。システムメタデータのみがログに記録されている場合、何かがうまくいかなかったことは特定できますが、具体的に何が失敗したのかを判断する方法がないかもしれません。これは、従来の監視ツールと比較したAIオブザーバビリティの特有の課題の1つです。

コンプライアンスの観点から、ログは監査証跡として機能します。規制対象の業界では、どの機密データがどのモデルに、いつ、誰によって渡されたかを証明する必要があります。これには、タイムスタンプや成功/失敗コードだけでなく、ユーザーID、チーム、モデルバージョン、環境に紐付けられた詳細な監査証跡が必要です。 

評価：既知の標準に対する継続的な品質評価 

従来の監視ツールには、これに相当する柱がありません。評価とは、継続的な人間の検査を必要とせずに、モデルの出力が確立された品質メトリクスを満たしているかどうかを測定するために、モデルの出力に適用される自動スコアリング機能です。

一般的な評価タイプには、忠実性（応答は取得されたソースドキュメントに基づいているか？）、回答の関連性（回答はユーザー入力に対応しているか？）、ハルシネーション検出（根拠のない主張が含まれていないか？）、安全性チェック（確立されたコンテンツポリシーに準拠しているか？）などがあります。

本番環境での評価がデプロイ前のベンチマークと異なるのは、継続性です。テストセットで良好なパフォーマンスを示したモデルでも、特に新しいモデルをデプロイした後では、実際のユーザー入力の分布がテストに使用された分布と一致しないため、本番環境ではパフォーマンスが低下する可能性があります。

このパフォーマンス低下はエラー率チャートには現れず、従来の監視ダッシュボードでは見過ごされてしまいます。評価スコアが定義されたしきい値を下回ると、アラートがトリガーされます。これにより、四半期ごとのレビューサイクルではなく、運用品質メトリクスに対するクローズドループシステムが構築されます。このアプローチは、大規模な責任あるAI開発の基盤であり、構造化されたフィードバックループを通じて継続的な改善と実用的な洞察を提供するというAIオブザーバビリティの約束を果たす上で中心的な役割を果たします。

AIオブザーバビリティがカバーし、監視がカバーしないものとは？

従来の監視と比較して、AIオブザーバビリティとは何でしょうか？その答えは、両方を同じシステムに適用した場合に最も明確になります。AIオブザーバビリティと従来の監視は、同じAIシステムを分析しても、まったく異なる結果をもたらす可能性があります。

監視では、リクエストの完了に2.1秒かかったことがわかるかもしれません。AIオブザーバビリティは、そのリクエストが遅い検索ステップのために遅延した理由、どのようなコンテキストが取得されたか、そしてそのコンテキストが実際にユーザーのクエリへの回答に役立ったかどうかを教えてくれます。報告されたレイテンシは数値を示します。しかし、その回答が時間遅延に見合うものだったか、つまりユーザーエクスペリエンスの主要なパフォーマンス指標であるかについては教えてくれません。

監視ではモデルレベルでエラーがゼロと報告されるかもしれませんが、AIオブザーバビリティは、同じモデルのハルシネーション率、取得されたドキュメント内のプロンプトインジェクション試行の有無、そしてそれらのインジェクション試行の結果として特定のAIエージェントワークフロー内で平均コストの3倍が発生したことなどを提供します。これらのどれもインフラストラクチャエラーとしては現れません。そのため、AIオブザーバビリティは真の根本原因分析と、ユーザーに影響が及ぶ前に根本原因を特定するために不可欠です。

監視では、モデルが呼び出されたことを確認するログがあるかもしれません。AIオブザーバビリティは、モデルに関する情報だけでなく、どのAIエージェントがツールを呼び出したか、呼び出し時に何が期待されていたか、そして最終的にエージェントに何が返されたかに関する詳細も提供します。このレベルのオブザーバビリティデータは、AIアプリケーションにおけるパフォーマンス問題の診断の基礎となります。

監視はシステムが存在することを確認します。AIオブザーバビリティは、そのシステムがまだ稼働しているべきかどうかを確認します。それがなければ、すべてのAIモデルは、その出力に責任を持つチームにとって事実上ブラックボックスとなります。これこそが、AIオブザーバビリティが対処するために設計されたものです。

ほとんどのAIオブザーバビリティツールがエンタープライズチームにとって不十分な点

AIオブザーバビリティとは何かを問うチームは、そのギャップに直面することで答えを見つけることがよくあります。AIオブザーバビリティ分野のポイントツールは、特定のユースケースにはうまく対応しますが、単独で導入されると孤立して機能します。プロンプトトレーシングは、送受信されたものの記録を提供します。評価用に構築されたオブザーバビリティプラットフォームは、事後にアウトプットを採点します。コスト追跡プロキシはトークン使用量をログに記録します。これらすべては、1つのLLM機能をリリースする組織内の特定のユースケースにはうまく適用されます。

AIアプリケーションがより複雑になるにつれて、ポイントツールの限界がより明らかになります。共有インフラストラクチャ上のマルチモデル、マルチAIエージェント、またはワークフローシステムは、可視性以上のものを必要とします。効果的に運用するためには、同じオブザーバビリティソリューション内でコスト管理、アクセス制御、およびコンプライアンス対応が必要です。

ビジネス全体でスケールする際に、以下のギャップが生じます。

1. コストの帰属が限定的: 一部のレポートツールは、モデルごとにグループ化された総トークン使用量を提供します。しかし、チーム、ワークフロー、またはユーザーセッションごとの内訳を提供するものはごくわずかです。これがなければ、ビジネス運営全体でのコスト管理は不可能です。

2. コンプライアンスは後回しにされがち: 不変の詳細な監査証跡、PII（個人識別情報）の匿名化、データレジデンシー制御がありません。機密データであっても同様です。その結果、チームはコンプライアンス目的のためだけに並行システムを構築し、本来組み込まれるべきオブザーバビリティのプラクティスに反しています。

3. エージェントおよびMCPのカバー範囲が不十分: ほとんどのAIオブザーバビリティツールは、単一ターンのプロンプトと完了のペアのために構築されています。マルチステップのAIエージェントトレース、ツール選択の決定、複数のMCPサーバーにわたる可視性は、利用できないか、または不安定です。

4. アクセス制御がスケールしない: ほとんどのオブザーバビリティツールには、ロールベースアクセス、プロジェクトレベルの分離、またはSSO機能がありません。概念実証（PoC）は、セキュリティアクセスやコンプライアンス要件のレビューなしに通過し、下流でパフォーマンスの問題を引き起こしています。

その結果、チームはコンプライアンス、コスト配分、カスタム評価方法を追跡するために、追加のソフトウェアでギャップを埋めています。これらのソリューションは構築と維持に時間とリソースを要し、組織が使用する人工知能アプリケーション全体におけるAIイニシアチブへの単一の可視性ポイントを確立できていません。

TrueFoundryはプロダクションチーム向けにAIオブザーバビリティをどのように実装しているか？

実践におけるAIオブザーバビリティとは何かについて完全な答えを必要とするチームのために、TrueFoundryはそれをプロダクションを通じて実証します。2026年においてエンタープライズプロダクションシステム向けの最も完全なAIオブザーバビリティツールの1つとして、TrueFoundryの AI Gateway 個別のSDKや手動での計測を必要とせずに、すべてのLLMリクエスト、ツール実行、AIエージェント実行を追跡するための組み込みの可観測性サポートを提供します。 

すべての可観測性データ（プロンプト、応答、エージェントトレース）は、お客様が完全に管理できるプライベートクラウド環境に保持されます。

• すべてのリクエストをトレース： 実行パス全体にわたるすべてのLLM呼び出し、ツール実行、AIエージェント実行について、完全なスパンメタデータ（レイテンシー、トークン使用量、モデル、ユーザー、出力）が記録されます。CrewAI、LangGraph、OpenAI SDK Agents、またはカスタムオーケストレーションを使用するエージェントワークフローの場合、TrueFoundryは各エージェントが何を行い、どのような順序であったかを正確に示すために、完全な実行ツリーを記録します。これは、生成AIデプロイメントにおけるAIエージェントのコアな可観測性です。
• チームとアプリケーションごとのコスト配分： すべてのトランザクションにおいて、トークン使用量がユーザー、チーム、モデル、環境ごとにリアルタイムで追跡・割り当てられます。過剰な使用を防ぐために、厳格な予算制限を設定できます。今月AIに8万ドル費やしたことを知っているのと、その総額の70%が3つの特定のワークフローによるものであることを知っていることの違いこそが、AI可観測性によるコスト管理がもたらすものです。
• クラウドベースの構造化監査ログ： すべてのリクエストは、完全なプロンプト内容、完了内容、ブロック決定、ユーザーID、モデルバージョン、環境データを含む、コンプライアンス対応の詳細な監査証跡として記録されます。すべての生ログおよび集計ログは、既存のSIEMパイプラインにエクスポートでき、SOC 2およびHIPAAコンプライアンスに対応します。これには、欧州連合のデータレジデンシー要件と米国の規制基準の両方が含まれます。
• エージェントおよびMCPツールの可観測性： TrueFoundryは、同じコントロールプレーンを通じてマルチエージェントワークフローとMCPツール実行のトレースをキャプチャし、LLM呼び出し、ツール呼び出し、サブエージェントへの引き渡し、クロスMCPサーバーインタラクションを含む、エージェントスタック全体にわたるAIエージェントの可観測性を提供します。テレメトリーデータはあらゆるレベルでキャプチャされます。

P50、P90、P99のパフォーマンスダッシュボード：レイテンシー、エラー率、スループットの各メトリクスは、モデルごと、プロバイダーごとに追跡され、チームまたは事業単位でグループ化されます。これにより、チームはパフォーマンスの低下を特定し、モデルドリフトを追跡し、GPU使用率を監視し、ユーザーに影響が及ぶ前にパフォーマンスの問題に対処できます。メモリ使用量とシステムヘルスは、同じ監視ダッシュボードに表示されます。