オブザーバビリティとは｜監視との違いとAI活用で見る4つの要素

「AIをやろう」という号令のもとで準備を進めていくと、「Observability（オブザーバビリティ）」「可観測性」「監視システム」といった言葉に次々ぶつかります。

ところが調べてみると、出てくる解説はメトリクスだ、トレースだ、分散システムだと専門用語が並び、「結局これは何なのか」「今までの監視と何が違うのか」「なぜAIだと必要になるのか」が掴めないまま手が止まってしまいます。

本記事では、オブザーバビリティの定義と監視との違い、その基盤になるデータや、AI活用では具体的に何を見ればよいのかをわかりやすく解説します。

オブザーバビリティ（可観測性）とは

オブザーバビリティの定義

オブザーバビリティ（可観測性）とは、システムから出力された情報から、システム内部で何が起きているのかを把握できる状態を指します。

オブザーバビリティプラットフォームを提供すNew Relicは、「システム上で何らかの異常が起こった際に、それを通知するだけでなく、どこで何が起こったのか、なぜ起こったのかを把握する能力」と定義しています（出典: オブザーバビリティとは？監視との違い、必要性について解説 — New Relic（2023年9月29日））。

オブザーバビリティという言葉が指しているのは、システムの異常を通知するだけでなく、なぜ起こったのかを把握できるという部分です。

オブザーバビリティの仕組み

オブザーバビリティは、システムに記録を出させ、それを集め、後から辿れる形にしておくことで成り立ちます。

まず、システム側に「今こうなっている」「今これをした」とシステム外に向かってデータを出させます。
次に、出てきたデータを1箇所に集めます。
そして集めたデータに対して、あとから「あのとき何が起きていたのか」と問いを立てられる形にしておきます。

オブザーバビリティと監視の違い

監視は、あらかじめ決めた項目が基準を超えたときに知らせる仕組みです。

New Relicは監視を「システム全体や一部のコンポーネントの動き、出力を観察し続けること」と定義し、決めておいたしきい値を超えるとアラートが上がる仕組みだと整理しています（出典: New Relic）。

両者の違いは、答えられる問いの種類にあります。
監視が答えるのは「何が起きたか」で、例えば、CPU使用率（システムが処理できるキャパシティのようなもの）が90%を超えた、といった事実を知らせます。

オブザーバビリティが答えるのは「なぜ起きたか」です。
通知を受けたあとに、その原因まで辿れる状態を指します。

この差が最も表れるのは、想定していなかった問題が起きたときです。
監視は、あらかじめ想定できた問題を捉えるための仕組みです。
基準を決めるためには、何が異常なのかを先に分かっていなければなりません。

オブザーバビリティは、その想定の外で起きた問題にも対応できます。

【例】社内の問い合わせ対応に置き換えた場合

• 監視にあたるもの：未対応の問い合わせが10件を超えたら、担当者に通知が飛ぶ

• オブザーバビリティにあたるもの：1件の問い合わせが、いつ誰に渡り、どこで止まり、なぜ返答が遅れたのかを、あとから1件ずつ辿れる

後者であれば、件数が増えた原因が特定の担当者への集中なのか、確認に時間のかかる種類の問い合わせが増えたのかまで辿れます。

監視とオブザーバビリティは併存します。
基準を決めて知らせる監視は引き続き必要で、その通知を受けたあとに原因を辿れるようにするのがオブザーバビリティです。

では、あとから辿れる状態にするために、何を記録しておけばよいのでしょうか。
その材料を4つに分類したものが、MELTデータと呼ばれています。

オブザーバビリティの基盤となるMELTデータ

MELTとは、メトリクス（Metrics）、イベント（Events）、ログ（Logs）、トレース（Traces）の頭文字を並べた呼び方で、オブザーバビリティを成り立たせるために集めるデータの4分類です。

この4分類はNew Relicが提唱した整理で、MELTという呼び方は業界でも使われています。

システムの状態を数字で把握する（メトリクス）

メトリクスとは、システムの状態を数値で測り、決まったタイミングで記録したものです。

業務のデータに置き換えると、毎日の受注件数や月末の在庫数のように、決まったタイミングで数えて並べていく数字にあたります。

時間の経過に沿って並べると、増えているのか減っているのか、いつから傾向が変わったのかが分かります。
ここで分かるのは数字の動きまでで、なぜその時点で動いたのかはメトリクスだけでは分かりません。

起きた出来事を1件ずつ記録する（イベント）

イベントとは、システムの中で起きた個別の出来事を、1件ずつ記録したものです。

業務のデータに置き換えると、「7月20日14時、システムを更新した」「14時32分、決済が失敗した」のように、起きたことを1行ずつ書き足していく記録にあたります。

メトリクスで数字が動いたことが分かったとき、その時刻に何が起きていたのかをイベントで突き合わせると、きっかけを特定できます。

処理の過程を記録する（ログ）

ログとは、システムが動いている最中に出力する、時刻つきのメッセージです。

イベントとの違いは、記録される情報の性質です。
イベントが「何が起きたか」を1件として記録するのに対し、ログは「そのとき中で何をしていたか」を文章として書き出します。

業務のデータに置き換えると、「14時32分、注文番号1234の在庫確認を実行、在庫なしと判定」のように、処理の内容と結果がそのまま残っている記録にあたります。
想定と違う結果になったときに、どの処理を経てその結果になったのかを読み取れるのは、ログが残っているからです。

1件の流れを最初から最後まで追う（トレース）

トレースとは、1つの要求が複数の処理を通っていく経路を、最初から最後まで繋げて記録したものです。

1件の注文が受注、在庫確認、決済、出荷指示の順に処理されていくとき、各段階に何秒かかり、どんな結果になったのかを1本に繋げた記録にあたります。

ログでは1つの処理の中身が分かる一方で、複数の処理をまたいだ全体の流れは追えません。
トレースは、どの段階で止まったのか、どこで時間がかかったのかを、1本の流れとして示します。

なぜAI活用でオブザーバビリティが必要になるのか

AIを業務で使い始めると、あらかじめ決めた項目を監視するだけでは、動いている中身が把握できなくなります。
従来のシステムなら監視だけで足りていた場面でも、AIでは記録を残して辿れる状態が必要になります。

AIは同じことを聞いても同じ答えを返さない

従来のシステムの多くは、同じ入力に対して同じ出力を返します。
だから、決めた項目が基準を超えたかどうかを見ていれば、異常は検知できました。

AIは違います。
生成AIのオブザーバビリティを解説しているElasticは、従来のシステムとの違いとして「同じプロンプトで異なる出力が生成される可能性があります」と述べています。
プロンプトとは、AIに渡す指示文のことです（出典: LLMオブザーバビリティとは？包括的なガイド — Elastic）。

同じ質問をしても、返ってくる答えは毎回少しずつ違います。
そのため「エラーが出ていないから正常」とは言えません。エラーなく動いていて、返ってきた答えが間違っている、という状態が起こります。

これは、あらかじめ基準を決めておく監視では捉えられない種類の問題です。
何が返ってきたのかを記録して、あとから中身を確かめられる状態が必要になります。

コストとリスクが見えないと、プロジェクトが止まる

AIエージェントとは、1つの指示を受けると、自分で手順を組み立て、社内システムの検索や外部ツールの呼び出しといった処理を順に実行するAIです。

Gartnerは2025年6月25日、2027年末までにAIエージェントを使ったプロジェクトの40%以上が、コストの高騰、ビジネス価値の不明確さ、不十分なリスク・コントロールを理由に中止されるとの予測を公表しました（出典: Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 — Gartner（2025年6月25日））。

上予測で挙げられた3つの理由のうち、コストの高騰と不十分なリスク・コントロールは、どちらもAIが動いている中身が見えていないところから生じます。

AIは使った分だけ費用がかかります。
しかも、1つの指示に対してAIが何回呼び出されるかは、指示の内容によって変わります。

どこで何回呼ばれ、どれだけ費用が発生したのかを記録していなければ、請求が届いてから初めてコスト高騰に気づくことになります。

リスクの側も同じです。
どんな入力に対してどんな出力を返したのかが残っていなければ、問題が起きたときに何が原因だったのかを説明できません。原因が説明できない状態では、対策を打つことも、社内に安全性を示すこともできません。

記録を残して辿れる状態にすることは、国内の共通指針にも示されている

総務省と経済産業省が2025年3月28日に公表した「AI事業者ガイドライン（第1.1版）」は、AIに関わるすべての主体に共通する指針として、透明性の項で次の内容を挙げています。

AIの判断にかかわる検証可能性を確保するため、データ量又はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利用時の入出力等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存する

（出典: AI事業者ガイドライン（第1.1版）— 総務省・経済産業省、2025年3月28日、第2部の共通の指針「6) 透明性 ①検証可能性の確保」）

同ガイドラインは、記録の残し方を決めるにあたって、事故が起きたときの原因究明、再発防止策の検討、そして損害賠償責任を立証する場面での重要性を踏まえるよう求めています。

このガイドラインは法的な義務ではなく推奨として示されているものですが、AIを扱う企業に共通して期待される考え方として、記録を残して辿れる状態にすることが明示されています。

AI活用で見るべきオブザーバビリティの4要素

AI活用においてオブザーバビリティが必要になることがわかりました。
では、AI活用で見るべき要素は何があるでしょうか？

オブザーバビリティの基盤となるMELTの4分類は、AI活用でもそのまま使えます。
変わるのは、それぞれで何を記録するかです。

トークンの使用状況（メトリクス）

トークンとは、AIが文章を読み書きするときの処理の単位で、料金の計算根拠になるものです。
1トークンが何文字にあたるかは、言語やモデルによって変わります。

AIに渡した文章（入力）と、AIが返した文章（出力）の両方でトークンを消費し、単価は入力と出力で異なります。そのため、合計だけでなく入力と出力を分けて数えます。

オブザーバビリティの標準規格を策定しているOpenTelemetryの記録規約でも、入力トークン数と出力トークン数はそれぞれ別の項目として定められています（出典: Semantic Conventions for Generative AI — OpenTelemetry）。

これが記録されていると、どの業務で、どの機能で、どれだけ消費しているのかが分かります。
費用が想定を超えたときに、どこが増えたのかを特定できます。
記録がなければ、手元に残るのは月ごとの合計金額だけです。

発生したエラーの内容（イベント）

AI活用で記録すべきイベントは、呼び出しが失敗したという事実だけでなく、何が起きて失敗したのかの中身です。

AIの呼び出しは、いくつかの理由で失敗をします。
回答が最後まで出る前に長さの上限に達して打ち切られる、外部のツールを呼び出す指示を返して止まる、利用回数の上限に達して受け付けられない、といったケースです。

OpenTelemetryの記録規約では、AIがなぜ生成を止めたのかを示す終了理由が記録項目として定められています。
正常に終わったのか、ツール呼び出しの途中なのか、途中で打ち切られたのかが、この記録で判別できます（出典: Inside the LLM Call: GenAI Observability with OpenTelemetry — OpenTelemetry（2026年5月14日））。

エラーが起きた事実だけを数えていると、対処が「もう一度試す」で終わります。
中身が残っていれば、上限の設定を変えるのか、指示の出し方を変えるのか、参照させるデータを増やすのかという判断ができます。

アウトプットの品質（ログ）

AI活用で残すべきログは、AIが何を受けて何を返したかというやりとりの記録そのものです。

品質は、その記録の中身を確かめることで判断します。

Elasticは、生成AIのオブザーバビリティで見る品質の観点として、ハルシネーション（事実に基づかない内容を生成すること）の発生率、質問との関連性、有害な内容が含まれていないかを挙げています（出典: Elastic）。

この観点が国内でも最大の課題になっていることは、調査にも表れています。
帝国データバンクが2026年3月に実施した調査（有効回答10,312社）では、生成AI活用に関する懸念・課題として最も多く挙げられたのが「情報の正確性」で、50.4%でした（出典: 生成AIに関する企業の動向調査（2026年3月）— 帝国データバンク）。

出力が正しいかどうかを確かめるには、何を返したのかの記録が必要です。
記録がなければ、正確性への不安は感覚のまま残り、業務に載せる判断ができません。

AIエージェントの行動（トレース）

タスクを自律実行するAIエージェントに指示を出すと、その一連の行動が複数の処理に分かれます。
トレースは、それを1本に繋げて記録したものです。

OpenTelemetryの公式ブログは、この状況を次のように述べています。

「アプリケーションがAIモデルを呼び出すたびに、モデルの呼び出し、ツールの実行、トークンのやりとりの連なりが裏側で起きている。オブザーバビリティがなければ、推測するしかない」（出典: OpenTelemetry（2026年5月14日））。

同ブログでは、AIエージェントの記録が階層構造になることが示されています。
指示全体を表す記録の下に、AIモデルの呼び出しと、ツールの実行が、実行された順に並びます。この形で残っていると、モデルが答えを作る処理、ツールの実行、うまくいかずにやり直した処理のどれに時間がかかっていたのかを判別できます（出典: OpenTelemetry（2026年5月14日））。

これが見えていないと、AIエージェントが期待と違う動きをしたときに、指示の出し方が悪かったのか、参照したデータが足りなかったのか、ツールの側で失敗していたのかを切り分けられません。「うまく動かない」で終わってしまい、次に何を直せばよいのかが決まりません。

4つが可視化されると、AI活用の判断の仕方が変わる

この4つが記録されている状態になると、AI活用について判断できることが変わります。

費用は、どの業務でどれだけ消費しているかが分かるため、使う範囲を広げるときに、いくら増えるのかを数字で示して起案できます。

品質は、正しく答えられた割合を測って改善の前後で比較できるため、社内から「AIは信頼できるのか」と問われたときに、記録を根拠として答えられます。

そして、AIに任せる範囲を広げる判断ができるようになります。
動いている中身が見えていない状態で任せる範囲を広げることは、見えないリスクを増やすことと同じです。
記録が残っていれば、うまく動いている範囲と、まだ人が確認すべき範囲を切り分けられます。

AI活用を試す段階から、業務に載せて広げる段階へ進むために必要なのが、この4つが見えている状態だと言えます。

オブザーバビリティに取り組む方法

自前で作らず、既にある枠組みを活用する

オブザーバビリティに取り組むときの出発点は、既にある業界共通の枠組み（フレームワーク）を活用することです。

どんな項目をどんな形で記録するかは、すでにこの枠組みの中で決まっています。
その形式に沿って記録を出す設定にしておけば、対応している監視サービスや分析ツールに、そのまま繋がります。

枠組みを活用する利点は、あとからツールを変えても記録の作り直しが要らないことです。
特定のサービスの独自形式で記録を出していると、乗り換えるときに記録の出し方から作り直しになります。どのサービスにも依存しない形式で出しておけば、この手間は発生しません。

代表例｜OpenTelemetry

ここからは少し技術寄りの話になります。
既にある業界共通の枠組みとして、現在の標準になっているのがOpenTelemetry（オープンテレメトリー）です。

クラウド関連のオープンソースソフトウェアを運営する団体、CNCF（Cloud Native Computing Foundation）は、OpenTelemetryを次のように説明しています。

"a vendor-neutral, open source observability framework designed to standardize the collection, processing and exporting of telemetry data—specifically metrics, logs and traces."

日本語にすると「特定のベンダーに依存しない、オープンソースのオブザーバビリティのフレームワークで、テレメトリーデータ（システムが外に出す観測用のデータ）、具体的にはメトリクス、ログ、トレースの収集・処理・出力を標準化するために設計されたもの」となります（出典: Cloud Native Computing Foundation Announces OpenTelemetry's Graduation — CNCF（2026年5月21日））。

ここで挙がっているメトリクス・ログ・トレースは、MELTのうちイベントを除いた3本柱の呼び方です。

AIモデルの呼び出し、エージェントへの指示、ツールの実行が、それぞれ決まった名前で記録されるよう定められており、トークンの使用状況、エラーの内容、やりとりの記録、エージェントの行動は、この規約に沿えば記録の対象になります（出典: Semantic Conventions for Generative AI — OpenTelemetry）。

担当者に求められるのは、導入するツールの提供元や開発の委託先に対して、OpenTelemetryの形式で記録が出る状態になっているかを確認することです。
規約の中身を自分で読み解く必要はありません。

対応していないと分かった場合は、そのツールがどんな形式でどこに記録を出しているのかを確認します。
記録が一切残らない設定であれば、業務に載せる範囲を広げる前に、提供元に出力の追加を依頼するか、記録が出る別のツールを候補に入れます。

まとめ

オブザーバビリティ（可観測性）とは、システムが出力しているデータから、システム内部で何が起きているのかを把握できる状態を指します。

あらかじめ決めた項目が基準を超えたら知らせる監視が「何が起きたか」に答えるのに対し、オブザーバビリティは「なぜ起きたか」に答えます。
想定していなかった問題に対応できるかどうかが、両者の違いです。

その基盤になるのがメトリクス、イベント、ログ、トレースの4分類で、AI活用では要素が、トークンの使用状況、発生したエラーの内容、アウトプットの品質、エージェントの行動に変わります。

取り組むときは、記録の仕組みを自社で作らず、業界共通の枠組みを活用します。
特定のサービスに依存しない形式で記録を出しておけば、あとからツールを変えても作り直しは発生しません。

AI活用を試す段階から次に進むために、まずは自社で使っているAIが何をどう記録しているのかを確認するところから始めていただけると幸いです。