2026年にオブザーバビリティのコストにどう向き合うか

はじめに

こんにちは、Grafana Labsでデベロッパーアドボケイトをしているものです。

この記事は、オブザーバビリティ関連の請求額が気になっている方向けに、なぜいま私がテレメトリーサンプリングに関する知見を集中的に発信しているかを説明するものです。開発や運用をAIに任せる度合いが上がるにつれて、本番環境で何が起きているかを確認する手段としてのテレメトリーはこれまで以上に重要になっていると感じています。当然、テレメトリーの量が増えればコストも増えるので、どこかの時点で全量保存の設定を見直す必要が出てきます。全量保存を続けられるならそれに越したことはないのですが、続けられなくなったときに「予算を超過して全量保存する」か「取るのを諦めて見えなくなる」かの二択に囚われないよう、サンプリングという選択肢を知っておいてほしい、というのがこの記事で伝えたいことです。

AIの導入で何が起きているか

いくつか公開されているデータを紹介します。

DORAが2025年9月に公開したレポートでは、90%が業務でAIを使い、80%以上が生産性の向上を実感していると回答しています。その一方で、30%はAIが生成したコードをほとんど信頼していないと答えており、AIの導入とソフトウェアデリバリーの安定性には引き続き負の関係がある、とも報告されています。

個社の例では、Honeycomb.ioの Liz Fong-Jones が2026年7月に公開した記事に、同社の開発状況が具体的な数字とともに書かれています。ピーク時の平日マージ数は2025年前半の約30件から2026年4月には約74件になり、コードベースは16.5か月で97万行から194万行に倍増しました。2026年6月に追加された行のうち82.6%がAIによるもので、これでも同社では最も割合が低い月だったそうです。同時にインシデントの件数も変更量におおむね比例して増えていて、2026年Q1は平常時の1.7倍、Q2は2.9倍と報告されています。

Datadogが2026年4月に公開した State of AI Engineering 2026 は、1,000社を超える顧客の本番テレメトリーを集計したレポートです。リクエストあたりのトークン数は中央値の顧客で前年比2倍、上位10%の顧客では4倍になっています。LLM呼び出しのスパンのうち5%がエラーを報告していて、その約6割がレートリミットによるものでした。エージェントフレームワークを使うサービスの割合も、2025年初頭の約9%から2026年初頭には約18%に増えています。

ここからは私の意見になりますが*1、変更の速度が上がり、書いた本人がコードの全体を把握しているとは限らない状況では、正しく動作しているかの確認を本番の挙動に依存する割合が増えていく思います。事前にレビューやテストで担保できる範囲が相対的に狭くなる分、動いているものを観測して確かめる比重が上がるわけです。Honeycomb.ioのインシデントの増え方は、それが実際に起きたときの記録として読めるように思います。

また、調査そのものをAIエージェントに任せる場合には、エージェントが読むための入力としてテレメトリーが必要となります。人間が目で追う量は変わらなくても機械が読む量は増えますし、エージェントは人間なら「たぶん関係ない」と読み飛ばすような範囲まで確認しにいくこともめずらしくありません。

オブザーバビリティのコストはどうなっているか

コストについては、予算側の当事者に聞いた調査がいくつかあります。

私が勤めているGrafana Labsが2026年3月に公開した第4回オブザーバビリティ調査では、回答者の50%が来年の支出増を見込んでいます。理由の内訳を見ると、適用範囲の拡大を挙げたのが63%で、ベンダーの値上げを挙げたのは25%でした。コストがツール選定の最重要基準だという回答は65%で、3年連続の首位です。前年の第3回調査には、オブザーバビリティ支出がコンピュート基盤の支出に占める割合は平均17%、中央値10%という数字もあります。

Elasticが Dimensional Research に委託して2025年12月に公開した調査でも、97%がコストの想定外を経験し、67%はそれが恒常的に起きていると回答しています。54%は経営層から支出の正当化を求められる頻度が増えたと答えていて、96%が何らかのコスト抑制策を実施中です（ツールの統合が51%、より安いツールへの移行が41%、データの変換が37%）。

これらはいずれもベンダーが実施または委託した調査なので（私の勤務先のものも含めて）、多少割り引いて読む必要はあります。それでもなお、コスト増の理由として値上げよりも適用範囲の拡大のほうが2倍以上多く挙げられている点には注目したいところです。コストが増えているのは、ベンダーに値上げされたこともあるかもしれませんが、主な理由は自分たちが計装を広げたからです。オブザーバビリティの導入がうまくいった結果としてコストの問題が起きる、という順序はあまり語られない気がしますが、私が相談を受けるケースの多くはこの形です。

計装のハードルは下がり続けている

適用範囲が広がる背景には、計装を始めるのが年々簡単になっていることもあると考えています。

OpenTelemetryは2026年5月にCNCFをGraduateしました。2,800社超から12,000人超のコントリビューターが参加していて、240を超えるCNCFプロジェクトの中でKubernetesに次いで活発なプロジェクトです。2026年2月には、設定を宣言的に記述するためのスキーマがv1.0.0に到達し、計装の設定をコードとして管理する方法にも標準ができました。

ベンダー側の動きも同じ方向です。Grafana Cloudは独自の計装ライブラリを提供しておらず、アプリケーションの計装にはOpenTelemetryをそのまま使います。テレメトリーの受け口としてもOTLPをネイティブに受け付けていて、OpenTelemetry SDKやCollectorから直接データを送れます。

AWSは、X-RayのSDKとDaemonを2026年2月25日にメンテナンスモードへ移行させ、移行ドキュメントでOpenTelemetryの採用を推奨しています（サポート終了は2027年2月25日）。

Google Cloudもかねてより公式ドキュメントでOpenTelemetryによる計装を推奨してきました。トレースの収集にはOpenTelemetryを、メトリクスの収集にはOpenTelemetryまたはPrometheusを推奨する、と明記されています。ベンダー固有のSDKからOpenTelemetryへ、という流れはハイパースケーラーの公式な推奨になっています。

このほかの多くのオブザーバビリティSaaSでも、OpenTelemetryは第1級の計装ライブラリおよびプロトコルとして扱われるようになりました*2。

標準化とは別に、生成AIの存在も計装を容易にしています。OpenTelemetryは仕様もセマンティック規約も公開されていて、各言語の計装例が大量に世の中に出回っているので、コーディングエージェントに任せやすい部類の作業だと感じています。私自身、既存のアプリケーションへの計装の追加やCollector設定の下書きをエージェントに任せることが増えました。計装は以前なら「余裕ができたらやる」タスクになりがちでしたが、着手のコストが下がった分、計装される範囲はこれからも広がっていくのだろうと思います。

計装しない理由が減っていくこと自体は喜ばしいのですが、コストの観点から見ると、そのまま増加の圧力にもなります。ちなみに先ほどのAWSの移行ドキュメントには、100%未満のトレースをサンプリングすることで、アプリケーションのパフォーマンスに関する有用な知見を保ちながらコストを削減できる、という趣旨の記述もあります。移行を促すページでサンプリングも勧められているのは面白いところです。

サンプリングという選択肢

2026年現在、コスト目標から逆算するタイプのサンプリング機能が各社の製品に揃っています。Grafana CloudのAdaptive Tracesもこれにあたります。他社の製品においても、コスト目標やライセンス上のボリュームを設定すると、それに収まるようにサンプリング率が自動調整されるものが多いです。コスト削減の規模感としては、Adaptive Tracesの解説記事（2025年12月）に、顧客の取り込みトレース量が典型的には75〜90%減少すると書かれています。

この機能に関して、AuditBoardの Geoff Schultz のコメントが紹介されています（2025年10月、拙訳）。「Adaptive Tracingの前は、2つの悪い選択肢しかなかった。全部送って予算を吹き飛ばすか、少なく送りすぎて有用な知見が得られないかだ」。この「2つの悪い選択肢」は特定の製品に限った話ではなく、テレメトリーの量が予算を超えた組織の多くが直面する状況だろうと思います。

とはいえ、私はサンプリングを積極的に勧めたいわけではありません。サンプリングはどう設計しても何かを捨てる行為なので、全量保存が可能ならそれが最良です。月間数百GB程度のデータ量であれば全量保存のままでも困らないことが多いはずですし、リテンションの短縮や、ヘルスチェックのエンドポイントやDEBUGログといった不要なデータの除外で予算内に収まるなら、そのほうがよいと思っています。サンプリングは、そうした対策を検討してもなお足りないときの、やむを得ない手段です。

ただ、選択肢として知らないままだと、先ほどの二択に囚われたままになってしまいます。知っていれば、何をどれだけ捨てるかを設計の問題として扱えますし、設計の問題にできれば、なぜその率なのかを根拠とともに説明できます。予算を承認する側から見ると、削減額そのものよりも、この説明のしやすさのほうが大事な場面も多いのではないでしょうか。