Observabilityの終わりが近づいている（そして私はそれで構わない）

 (honeycomb.io)
22 ポイント 投稿者 GN⁺ 2025-06-13 | 4件のコメント | WhatsAppで共有
  • ここ数十年にわたり、Observabilityツールの中核的な目標は、大規模で異種なTelemetryデータを人間が理解できるようにすることだった
  • AIとLLMの登場により、従来の「ダッシュボード＋アラート＋サンプリング」中心のパラダイムが変化し、分析プロセスが自動化に置き換えられる現象が起きている
  • 実際に、AIエージェントが80秒で8回のツール呼び出しを行い、遅延スパイクの原因を分析し、従来デモで行っていた作業を自動化し、コストもわずか60セントで済ませた
  • 従来の美しいダッシュボードや便利な計測はもはや特別な価値ではなく、LLMが分析を、OpenTelemetryが計測をコモディティ化している
  • 未来のObservabilityは「高速なフィードバックループ」とAI＋人間の協働ワークフローが成功の鍵であり、より多くのソフトウェアと自動化の時代を導く

Observabilityツールの歴史とAIの登場

  • 何十年もの間、Observabilityツールの中心的な目的は、膨大で異種なデータ（テレメトリ）を人間が理解可能な水準に圧縮・要約することだった
  • 新しいソフトウェア抽象化（例: Rails、AWS、Kubernetes、OpenTelemetryなど）が登場するたびに、
    その複雑さを覆い隠すために、監視・計測・ダッシュボード・適応型アラート・動的サンプリングなど、さまざまなツールが開発されてきた。そしてデータの複雑さを人間の認知レベルに合わせて圧縮して提供してきた

LLM = 汎用関数近似器、そして本当に役立つようになった

  • LLMは数学的には**汎用関数近似器(universal function approximator)**にすぎないが、実際にはObservabilityの問題を解決するうえで非常に有用である
  • 例として、Honeycombのデモではヒートマップ上の遅延スパイクについてAIエージェントに自然言語で分析を依頼した
    • 「フロントエンドサービスで4時間間隔で発生する遅延スパイクの原因を分析してほしい」
    • 既製のLLM（Claude Sonnet 4）とHoneycombのModel Context Protocol(MCP)を連携
    • 80秒、8回のツール呼び出し、60セントのコストで原因を自動分析
  • 追加プロンプト、個別の訓練、ガイドなしで、実際のシナリオをゼロショットで解決する水準に達している
  • 分析のコモディティ化:
    • LLMが分析作業を自動化すると、従来のObservability製品の差別化要素（美しいグラフ、容易な計測など）は意味を失う
    • OpenTelemetryが計測を、LLMが分析をコモディティ化する
    • 今後は「高速なフィードバックループ」がObservabilityツールの中核的価値に取って代わる

人間の役割、そして未来の変化

  • 人間の役割が完全になくなるわけではない
    • クラウドの登場もITそのものの存在を消し去らなかったのと同じように、AIも開発者や運用担当者を置き換えるわけではない
    • 生産性の向上は全体の地形を拡張し、より多くのソフトウェアを生み出す
  • 核心的な問いは、
    コード作成・リファクタ・分析コストが大幅に下がり、分析が定数化される世界で、
    Observabilityの本質はどこへ向かうのか？

本当に重要なのは「高速なフィードバック」

  • 最も重要なのは、開発と運用のあらゆる段階で「高速で密なフィードバックループ」を備えること
    • AIは速度において常に人間を上回る
    • LLMは何十回もの仮説を素早く立て、失敗し、最終的に正しい結果を見つけ出す
      （そのコストも非常に安い）
  • Honeycombの哲学:
    • 高速なフィードバックループ、協働的な知識共有、実験的な開発／運用
    • 今後はAI支援がソフトウェア開発と運用の全ライフサイクルに導入される
      • 例
        • コード作成やデプロイ時にAIエージェントがリアルタイムでフィードバックし、バグや品質改善を提案
        • 運用中のemergent behaviorを検知・分析・自動レポートし、承認後に自動改善
        • 最先端の組織ではSRE/SWEの役割をAI＋ツールで自動化し、ビジネス目標まで直接達成する
  • 成功のためのObservabilityの未来の条件
    • 超低遅延のクエリ性能
    • データ統合ストア
    • 人間とAIの間の円滑な協働ワークフロー
  • 結論:
    • 従来のダッシュボード、アラート、可視化中心のObservabilityツールは
      AI時代には中核ではなく、
      「高速なフィードバックループ」とAIと人間の協働プラットフォームだけが生き残る

関連記事

4件のコメント

 
redlasha 2025-06-14

Observabilityがモニタリングの終わりではなかったように、LLMもObservabilityの終わりではないでしょう。
高度化されたモニタリングを土台にObservabilityが発展したように、高度化されたObservabilityを土台にLLM分析も発展していくでしょう
 
ethanhur 2025-06-13

LLMによってObservability分野が急速に革新されそうで期待していますが、タイトルはちょっと釣りっぽいですね（笑）
 
crawler 2025-06-13

自社サービスを「終焉が近づいている」と言いながら宣伝するのは、ちょっと気恥ずかしいですね...

個人的には、Vision LLM が発展してモニタリング作業に使われることを期待しています。 最近、VLM を子どもが寝ている間に異常がないかチェックする用途で使った親の投稿を見たことがあるのですが、それがとても面白かったです。
 
GN⁺ 2025-06-13
Hacker Newsのコメント
  • 私たちは集団として、決定論の価値をかなり過小評価していて、その一方で非決定論がもたらすコストも過小評価している気がする。最近、似たような売り文句の別製品を試したが、これは私のイベント群をグラフで関連付けてRCEしようとしていた。結果として Spurious Correlations のページのようになってしまい、実際に見ると明らかで笑ってしまうようなものだった
    • 時系列データは本当に疑似相関(spurious correlations)に弱い、ということはもっと知られるべきだ。r²の値も意味がない。さらに悪いのはグラフを目視で解釈するときで、時間とともに変化するデータなら、それに合った適切な測定基準を使う必要がある
    • もしかすると私が要点を取り違えているのかもしれないが、LLMベースのアプリでも設計さえうまくやれば、本当に重要な瞬間には決定論的なUXを実装できる。必要なときにLLMが何かを実行するための決定論的な仕様を生成し、そのタスクやアクションを記録できる。ユーザーがいつでも再実行できる仕様を会話内容とともに保存するようにし、仕様が失敗したときにはAIが修正方法を提案できるように構成する、という形だ。AIをコーディングに使う体験に近い流れだと思う。ただし、仕様ドメインをもっと狭めることと、失敗した仕様をどう回復するかについてはさらに考える必要がある。ユーザーに仕様言語を別途学ばせなくても実現可能な構成だ
  • RCAが得意な人間として、気まずさを感じている同僚たちが、10%は間違っている結果を非常に自信満々に出してくるツールをそのまま信じて、さらにひどいことにならないか心配だ。本当は分かっていないのに、公の場で「分からない」と言わなくて済むので、ツール依存が進むのではないかと懸念している。もしツールが結論を出したあと、その解釈に反するデータを探し、より信頼できる根拠や不確実性を明確に示してくれるなら、まだましだと思う
    • システムプロンプトをうまく設計すれば、この部分はかなり補える。実際、LLMからより厳密で調査された回答をデフォルトで引き出すカスタムプロンプト/指示を作ってみたことがあるが、かなり良い体験だった。ChatGPTで私が使っているプロンプトは次のようなものだ: "実体、明確さ、深さを優先。すべての提案、設計、結論を仮説として扱い、鋭く問い直す。隠れた前提、トレードオフ、失敗ケースを早い段階で露出させる。不要な称賛は根拠がなければ省く。不確実なら明確に言及する。常に代替的な観点を提案する。事実に関する主張は引用または確かな根拠があるときだけ断言する。推論や不完全な情報に依拠する場合は明確に告知する。確信より正確さを重視する。" こうした構成で、実際に回答の品質や深さが大幅に改善された
  • 「New RelicはRails革命で、DatadogはAWSの台頭で、HoneycombはOpenTelemetryを主導した」というような歴史は偏った解釈だ。OpenTelemetry(OTel)は、Googleが始めたOpenCensusとLightStepが始めたOpenTracingが公式に統合されて生まれたものだ。Google、LightStep、Microsoft、Uberなどさまざまな組織が初期ガバナンスに参加している。Honeycombがコード、コミュニティ、技術導入を大きく牽引したのは事実だが、「主導した」というのは誇張だ
    • 最近Honeycombを導入した者として読んでいるが、本当に驚くべきツールだ。特にotel自動計装のおかげで、数時間でインサイトを得る体験ができる。ダッシュボード/クエリ機能も、深いObservabilityの哲学から出てきたものだと感じる。うちのチーム全員がツールの完成度に衝撃を受けた。Datadogはマーケティングと「Observability」のチェックリストにより重きを置いているように見える
  • 「売り文句」を脇に置いて見れば、これはLLMが本当に価値を発揮するアプリケーションの一つだ。これまでモニタリングとObservabilityは大企業のSREの領域であり、小規模組織にとってはハードルが高かった（ITの観点に限れば）。意味のあるメトリクスの選定、heartbeatやbaselineの設定そのものに、時間、専門ツール、大規模な開発環境、変更検証の仕組みまで必要で、一般的なITチームには手が出しにくかった。今では、最も一般的なツール群で訓練されたLLMのおかげで、予算や能力が不足しているITチームでも、オープンなフレームワーク/ツールベースの「本物の」Observabilityシステムを実装できるようになってきた。もう派手なサブスクリプション型ソリューションは不要だ。ダッシュボード構築や実用的なモニタリング設定が必要なとき、LLMは本当に福音のような存在だ。CIOが推してくる数多くの製品群を一つひとつ深掘りする余裕がなくても、ドキュメントを読んでトラブルシュートできるIT担当者なら活用価値は非常に高い。PagerDutyのアラートに最低限の原因候補の提案まで付くなら、SMB/SMEにとってはObservabilityの革命だ
    • 意味のあるメトリクスの発見はLLMの不得意分野だが、heartbeatやbaselineなど残りの部分は、かなり前からConvNet(畳み込みニューラルネットワーク)で十分自動化できた領域だ。変更検証や安定性コントロールのようなデプロイに関する懸念は、Observabilityツールの範囲を超えた問題だ
    • 小規模なSREチームにも大きなインパクトがあると期待している。うちのチームは2人で数百台のベアメタルサーバーを管理しているが、障害が起きたときに原因を絞り込んでいく過程は非常にストレスが大きい。MCP(Master Control Program)のようなツールを自作しようかと考えるほどだ。長時間潜伏していた問題が何度もエラーとして表面化することがあったが、こういうケースではLLMがかなり役立つはずだ
  • タイトルがあまりにも扇情的に感じる。既存のObservabilityツールが無用になるわけではない。ただ、グラフを作って見続ける時間は減るかもしれない。これはLLMがあらゆる領域に及ぼす効果と似ている。すでにできる仕事をより速くこなせるようにしたり、そのやり方を学ぶ助けになったりはするが、特定の技術そのものを完全に置き換えるわけではない
    • 「すでにできる仕事の速度を上げる」「新しいことを学ぶ助けになる」という結論は、今日だけでもこれで2回目だ。2による推論(inference)と、1の効率を極端に高めることこそ、今後もっとも生産的な方向性だ
    • タイトルは扇情的だが、メッセージは明確だ —— 参入障壁(モート)が徐々に下がっている
    • この現象を「Charity Majors効果」と呼ぶ
  • デモでは「これは作為的な例ではない。私たちがデモでユーザーに投げる質問を、そのままLLMエージェントにも投げたところ、追加プロンプト、学習、ガイダンスなしで即座に正解を見つけた」と言っているが、実際にはこのシナリオ自体がすでにデモに含まれており、解決策も既知のケースだ。むしろ作為的な例を使って、モデルが学習データにそのまま存在しない新しい状況にも一般化できることを示すべきだったと思う。LLMの実際の機能が有用なのは確かだが、「Observabilityの終焉」のような極端な宣言をするなら、ツールが一般化能力を示す必要がある
  • 「Observabilityの終焉」ではないと思う。ただ、記事が提示しているポイントも完全に的外れではない。確かにSRE（特にRCAを含む）において、さまざまな役割を果たせる新しいAIエージェント層が台頭する可能性は高い。ただし、それが現実になったとしても、既存のObservabilityスタックの大部分（あるいは全部）が依然として必要だろう。加えて、LLMの幻覚/信頼性/安定性の問題が根本的に解決されない限り、深い問題把握には依然として人間が必要だ
  • 「AIで少し頑張れば、専門家がやっていた仕事は全部できる」という事業戦略、本当に魅力的な事業戦略だ。悲しいことだが、今どきのAIスタートアップの80%にこの文句をコピペしても違和感がない
    • 皮肉に聞こえるだろうが、その「そこそこ仕事のできる専門家」たちは<i>とてつもなく</i>高価なリソースなんだ。実際にこの自動化が実現するなら、粗いAIスタートアップがあふれている理由も理解できる
  • この記事、AIが丸ごと書いたように感じる。「AIがこのパラダイムを終わらせる、すでにそうなっている、システム設計と運用のやり方まで根本的に変わる」—— データの一部を解釈することがどうして「Observabilityの終焉」になるのか疑問だ
  • 「もうグラフやUIでデータを見る必要はない」というロジックには、現実的な限界がある。LLMがうまくいくときは本当に素晴らしいが、失敗したときには人間が介入して、グラフなどの可視化を直接見なければならない。グラフや可視化も難しいが、実際のデータ収集や複雑なクエリ、保存方式の設計にはさらに難しさがある。本当の人工知能がほぼ完璧にすべてを判断できるようになって初めて、Observabilityは「消える」のだろう。結局そのときには、社会全体の構造が完全に変わるような文化的変化（消滅ではなくとも痛みを伴う移行）が訪れるはずだ。AIがObservabilityの世界を変えつつあるのは本当だ。今この瞬間にも進行中だが、まだ道半ばだ