世界を動かす技術を、日本語で。

私たちが知っている可観測性の終わり(そして私は大丈夫です)

概要

  • オブザーバビリティツール の歴史と進化の流れ
  • AIとLLM の登場によるパラダイムシフト
  • Honeycomb のデモ事例とAIによる自動分析
  • 今後求められるツール要件 と業界への影響
  • AI主導の将来像 と人間の役割の変化

オブザーバビリティツールの歴史とAIによる変革

  • 過去20年 のオブザーバビリティツールの進化は「膨大な異種テレメトリデータを人間が理解できる形にする」ことが本質
  • New Relic はRails革命、 Datadog はAWSの普及、 Honeycomb はOpenTelemetry時代を牽引
  • 新たな開発・デプロイ手法の普及→複雑性の増大→新たなモニタリング・計測手法の必要性
  • ダッシュボード、アラート、動的サンプリング などで情報圧縮し人間が理解可能に
  • AIの登場でこのパラダイムが終焉しつつあり、 システム設計・運用の考え方が根本的に変化

HoneycombデモとAI分析エージェントの実例

  • Honeycombのデモでは ヒートマップ でスパイク(遅延リクエスト)を可視化し、 BubbleUp で異常検知・根本原因特定を実演
  • 社内デモで Claude Sonnet 4 を使ったAIエージェントに「4時間ごとに発生するフロントエンドの遅延スパイクの原因調査」を依頼
  • Model Context Protocol (MCP)サーバー 経由でAIがツールを駆使し、人間と同様の調査フローを80秒・8回のツールコールで自動実行
  • 追加プロンプトや訓練なし で現実的なシナリオをゼロショット解決、コストは約60セント
  • 最適化余地 も大きく、今後さらにコスト・効率両面で進化が期待

AI時代におけるオブザーバビリティツールの価値再考

  • LLMが分析をコモディティ化OpenTelemetryが計測をコモディティ化 し、従来の「グラフ」「簡単なインスツルメンテーション」だけの価値は消失
  • 人間の役割消滅ではなく、 クラウド時代のITやRails時代のサーバープログラマ同様、役割の拡大・多様化
  • コード・リファクタ・分析の低コスト化 により、より多様なソフトウェア・運用が可能

これから求められるオブザーバビリティの要件

  • 最重要なのは高速なフィードバックループ
    • AIは 圧倒的な速度 で仮説検証を繰り返し、遅い分析エンジンは時代遅れ
    • サブ秒クエリ性能、統合データストレージ、人間とAIの協調ワークフロー が必須
  • Honeycombは 高速なフィードバック、コラボレーション、実験的アプローチ を重視し、AI時代の基盤を提供

AI主導の運用・開発の未来像

  • AIエージェント がコード作成・デプロイ時にリアルタイムで修正提案
  • システム挙動の異常検知・調査・レポート作成 をAIが自動実行し、人間は承認や微調整を担当
  • 完全自律型のSWE/SREロール も一部で実現可能
  • スピード重視 が全ての前提となり、従来型ツール(ダッシュボード・定型アラート・マジック統合)は競争力喪失

AIによるフロントエンド遅延スパイク調査の詳細

  • 主因:Checkoutサービスのパフォーマンス問題
    • 遅延スパイクは周期的ではなく、 負荷テストや合成トラフィック のパターン
    • /cart/checkoutエンドポイント のP95遅延:3.7秒(通常500ms)、最大7.6秒
    • 他エンドポイントは安定、スパイクはチェックアウト処理に集中
  • トレース分析の証拠
    • python-requests/2.28.2と2.31.0のUser Agent
    • 一貫したクライアントIP、テストデータと思しき高額カート値
    • 同一ユーザーIDによる複数リクエスト
  • 技術的根本原因
    • 高負荷時のCheckoutサービスのボトルネック
    • 割引計算や外部APIの遅延、DB競合の可能性
  • 推奨アクション
    • 負荷テスト実施の有無確認、スパイク期間中のリソース監視
    • 割引計算の最適化、配送計算のキャッシュ導入、外部APIのサーキットブレーカー実装
    • 合成・実ユーザーのアラート分離、依存サービスの監視強化

まとめ

  • AIによるオブザーバビリティ分析 は現実化し、業界の前提を覆す
  • 高速なフィードバックループとAI協調 が未来の必須要件
  • Honeycombはその未来に対応するプラットフォーム提供
  • 今こそ新しい価値創造に挑戦する時代

Hackerたちの意見

「AIにちょっとした作業と専門家がいればできることをやらせる。」なんて素晴らしいビジネス戦略なんだ!残念ながら、今日のAIアプリケーション会社の80%にこのコメントを投稿できそう。

これがダメ出しだと思ってるかもしれないけど、「この分野の専門家」はめっちゃ高いんだよね。もし本当にできるなら、そんなにふわふわしたAI企業が多いのも納得。

RCAが得意な私としては、恥ずかしい思いをしている同僚たちが、10%の確率で自信満々に間違えるツールをそのまま受け入れちゃうんじゃないかと心配してる。そうなると、余計に問題が起きちゃうし、みんなが公に知らないことを認めるのが嫌で。もしツールが結論を出してから、その解釈を否定するデータを探して、もっと信頼性のある議論をしたり、不確実性を認めたりするなら、もう少しマシになるんだけどね。

システムプロンプトを使えば、かなりのことができるよ。実際、LLMを使って効果的なシステムプロンプトやカスタム指示を作ることで、デフォルトでより厳密でよく調査された回答を得ることに成功してる。今ChatGPTで使ってるのはこんな感じ:> 「内容、明確さ、深さを優先する。私の提案、デザイン、結論をテストすべき仮説として挑戦する。精度を高めるためのフォローアップ質問を鋭くし、隠れた前提やトレードオフ、失敗モードを早めに浮き彫りにする。詳細な探求が必要でない限り、簡潔で論理的に構成された情報密度の高い回答をデフォルトにする。証拠に基づかない無駄な称賛は避ける。適用可能な場合は不確実性を明示的に認める。少なくとも一つの代替の枠組みを提案する。批判的な議論を普通で好ましいものとして受け入れる。引用や明確な正当化がない限り、すべての事実の主張を仮のものとして扱う。適切な場合は引用する。主張が推論や不完全な情報に依存している場合は認める。確実に聞こえるよりも正確さを重視する。」

タイトルがちょっと大げさだね。今ある観測ツールは全部必要だから、何も終わりじゃないよ。ただ、グラフを作ったり眺めたりする時間が少し減るかもしれない。LLMが全てに与えている影響はそんな感じみたい。すでに知ってることを早くやる手助けをしてくれるし(新しいことを学ぶ手助けも!)、特定のスキルを完全に置き換えるわけではなさそう。

  1. すでに知っていることを早くやる手助けをする 2. 何か新しいことを学ぶ手助けをする!これ、今日2回目に聞いた結論だわ。推論を使って2.をやって、1.をこなすスーパーパワーを得る、これが進むべき正しい道かも。

タイトルはちょっと大げさだね。「チャリティ・メイジャーズ効果」って呼んでるよ。

もう一度言うけど、営業トークは置いといて、これは貴重なLLMアプリケーションの一つだと思う。モニタリングと可観測性は、大規模な組織のSREチームの専売特許だったけど、小規模な組織には手が届かないものだった(ITの観点から話してるよ、開発じゃなくて)。価値のある指標を特定して、ハートビートやベースラインを分けるのは、時間がかかるし、専門的なツールや変更を検証するための広範な開発環境、そして生産環境を燃やさないための変更管理が必要なんだ。人気のあるツールで訓練されたLLMがあれば、資金や専門知識が不足しているITチームでも、よりオープンなフレームワークやツールに基づいた「本格的な」可観測性やモニタリングの導入ができるようになる。使えるダッシュボードやシンプルな可観測性の設定に関しては、トラブルシューティングやドキュメントを読むことができるITの人たちにとって、LLMは神のような存在だよ。CIOが押し付けてくる製品スイートについて、すべてを「深く掘り下げる」時間がないからね。PagerDutyアラートを送るときに少なくとも提案された原因を示す能力があれば、中小企業や中堅企業にとって可観測性の革命が起こるよ。

同意!小規模なSREチームにも大きな利点があると思う。私のチームは2人で、管理しているベアメタルマシンが何百台もあるんだけど、問題が発生すると、犯人を特定するのがストレスになることがある。これを助けるためにMCPを書くことを考えてるんだ。未来はこの点で明るいと思う。エラーが出る前に問題がしばらく続いていることも多いしね。LLMがまたこれに役立つと思う。

みんなで、決定論の価値と非決定論のコストを大きく過小評価してると思う。私は同じ営業トークの別の製品を試してるんだけど、それはグラフを相関させてインシデントをRCEしようとするんだ。結果的にこんなページみたいに見えるけど[1]、言葉で説明するのはちょっと難しいけど、自分で見ると明らかで面白いよ。 [1]: https://tylervigen.com/spurious-correlations

楽しいけど、ポイントはよく知られてるべきだよね(実際には知られてないけど)。時系列データはスプリアスな相関に非常に敏感だから、r²は役に立たない。グラフを目視で見るだけでもさらに悪化するよ。何かが時間とともに変わるなら、適切な指標を使わないと。

最近、AIツールに頼りすぎてる人が多い気がする。誰かに給料を払うなら、その人はちゃんと答えを理解してる必要があるよね。もし間違った答えを出したら、その人も責任を取らなきゃいけない。それが給料をもらう意味だと思う。仕事をするだけじゃなくて、結果に対して責任を持つことが大事なんだ。AIは、Y Combinatorで見かける多くのケースでこれを壊してる。もしAIツールが人間の意思決定に必要な役割を超えてしまったら、そのAIツールの有用性はあまり高くないと思う。

彼らはちゃんと答えを理解してる必要があるよね。もし間違った答えを出したら、その人も責任を取らなきゃいけない。問題が見えないんだけど。

これは単なるマーケティングだと思う。「AI」は最終的には自然言語計算機として使われるだろうね。個人的には、計算機のデザインやプラン、レビュー、解釈を作ろうとするのをやめることになると思う。あまりにも良すぎるものは、バブルが弾けた後は学術的なものとして残るだけだろうね。

何に対してお金を払ってるかによるね。ロンドンで£50kのフルスタック開発者?最近はAIの雑な結果が出てくるよ、特に組織内で使うことを奨励した瞬間にね。LLMは、給料が安い人たちが自分の仕事をちゃんとやる手助けをするだろう。すでに「フルスタック」として2人か3人分の仕事をやらせてるのに、AIを使わない人に£20kも多く払うつもり?

AIの助けがなくても、実際には理解していない答えや解決策を出すことに抵抗がない人もいるよ。

残念ながら、答えをしっかり考えてくれる人たちって、ポジションの価値が高すぎて代わりがきかないから、昇進しにくいんだよね。企業の階段を上がる一番の方法は、実際に早くてそれっぽい答えを出して、リスクを取る前にさっさと動くことなんだ。こういうインセンティブ構造が、平凡な口先だけの人たちに道具を与えて、彼らがごまかしながら進むのを助長してる気がする。

これは重要じゃないよ。人間に責任を持たせればいいんだ。理解できないツールを使いたいなら、ミスをして解雇されるのはその人の責任。次の人は同じミスをしないから、問題は自然に解決する。これはAIがあろうとなかろうと、ずっとそうだった。

最近、IBMの有名な言葉をよく考えるようになった - 「コンピュータは責任を持てないから、コンピュータが経営判断を下してはいけない。」これって、今のAIソリューションにも当てはまると思うし、だからこそ、AIを使いこなし、自分の責任をかけることができるのが一番の労働者になるんじゃないかな。

AIに対する期待は確かにあるけど、価値もあるよね。うまく機能する組織の現実的なシナリオは、DevOpsチーム全体をAIエージェントに置き換えて、技術インフラが燃え上がっている現実に気づくことじゃなくて、むしろこれをツールとして使って、最高のDevOps担当者をもっと効率的にし、リソースをスリムにすることなんだ。これで同じコストで生産性が上がる。未来の仕事が暗いように聞こえるかもしれないけど、私はこれが起こると思ってる。

これはHNの雇用の仕組みや雇用主が従業員をどう扱うべきかについての平均的な見解を反映してるのかな?雇用主として、この投稿はほとんど混乱を招くもので、実際の従業員の役割とはほとんど関係がないように感じる。

この返信が好きなのは、雇用のパラダイムが変わってきているのがわかるから。数年前は、ソフトウェアエンジニアはコーディングの才能だけで雇われて、傲慢だったり衛生面が悪くても許されてたんだよね。でも、時が経つにつれて、私たちは問題解決者として再ブランド化されて、今では良いコードを書くことに加えて、コミュニケーション能力やチームプレイヤーであることも求められるようになった。次の進化は、特定の領域に責任を持つようになり、どうやってそれを達成するかは抽象化されるってことだね。

これは作り話じゃないよ。デモで君に聞くのと同じ質問をエージェントにしたら、追加のプロンプトやトレーニングなしで解決したんだ。実際のシナリオでゼロショットでやったって感じ。これが彼らが既に使ってるデモで、解決策も手に入るみたい。もし解決策がトレーニングデータにそのまま含まれていないか確認するために、作り話にしておくべきだったかもね。LLMがやったことが役に立たないわけじゃないけど、観測可能性の死を宣言するなら、そのツールが一般化できることを示さないと。

New RelicはRails革命のために、DatadogはAWSの台頭のために、HoneycombはOpenTelemetryの道を切り開いた。OTelの歴史をこう読むのは偏ってると思う。OpenTelemetryは、Googleが始めたOpenCensusとLightStepが始めたOpenTracingの統合として生まれたんだよね。 > シードガバナンス委員会は、Google、Lightstep、Microsoft、Uberの代表者で構成されていて、毎日新しい組織が参加してる。Honeycombは確かに価値あるコードやコミュニティの貢献をして、技術の普及を推進してきたけど、「道を切り開いた」とは言えないほど遠いと思う。

最近ハニカムを導入した者として、ほんとに素晴らしいツールだと思う。特にotelの自動計測機能を使うと、数時間でインサイトが得られるんだ。ダッシュボードやクエリ機能もめちゃくちゃ強力で、明らかに観測性に関する深い哲学的理解から来てる。私のチームはこのツールの良さに驚いてたよ。対照的に、Datadogはマーケティングに引っ張られている感じで、「観測性」のチェックボックスを埋めるために使われてる気がする。

ちょっと関連するけど、gcloud CLIでClaudeコードを使って、読み取り専用のコマンドだけを許可して(もちろんsshはなし)、監視のもとで使うのは、すごいスーパーパワーだよね。手動でインフラをデバッグするのには戻れないと思う。Claudeコードの使い方は、放っておいて終わりじゃなくて、導いて修正する必要があるけど、それでもGCPのAPIの混乱に直接対処するよりずっと早くて楽だよ。

不満:エンシティフィケーションはパフォーマンスの懸念とは別の話。単にソフトウェアが悪くなるってだけじゃなくて、技術的には優れているけど、ユーザーにとって悪いことをして、投資家のためにROIを生み出すことを目的にしているソフトウェアのことを指してるんだよね。