O11yCon 2026で語られたすべて

O11yCon 2026が終了しました。今年の議論はこれまでとは明らかに違いました。エージェントベースのソフトウェア開発は今、まさにここにあります。もはや選択の余地はなく、誰もが自らのエージェントが何をしているのか、どのようにコストを削減し、パフォーマンスを向上させるかを理解しようと苦心しています。2日間にわたり、ソフトウェアを「誰が（あるいは何が）書くのか」という従来の前提が根本から覆されたことが明らかになりました。

以下にハイライトをまとめます。ビデオは近日中に公開予定です。

セッションの振り返り

Scale Brilliance, Not Bottlenecks: Building Platforms for the AI-First World (Nathen Harvey, DORA/Google)

Nathen Harveyは、誰もが立ち止まって考えるべきDORAの調査結果を紹介して講演を始めました。AIの採用はほぼ普遍的ですが、成果は大きく異なるということです。すでにスムーズにリリースできているチームはさらに良くなり、苦戦しているチームは摩擦をより強く感じる傾向にあります。

また注目すべき点として、エンジニアたちはAIの使用について恥ずかしさを感じており、学んだことをため込んでいるため、チームメイトを助けられる知識が閉じ込められているという指摘がありました。コードレビューももう一つのボトルネックです。PRの量は増加し、レビューの時間も長くなっており、AIはボトルネックを解消していません。Nathenの推奨は、レビュー自体の改革ではなく、テストや可観測性といったフィードバックメカニズムへの投資です。

What's next at Honeycomb: Canvas and Agent Timelines (Jamie Danielson, Martin Holman, and Purvi Kanal, Honeycomb)

HoneycombのJamie Danielson、Martin Holman、Purvi Kanalが同社の新機能「Canvas」をデモしました。Honeycombの元社員であるNathan LeClaireはLinkedInで「Figma、Honeycomb、ChatGPTの赤ちゃんのようなもの」と表現しています。

Canvasの優れた機能のひとつは、タブを開く前からエージェントが多くの作業を行える点です。たとえばSLOのバーンアラートが発生すると、自動調査が即座に開始され、ユーザーがアクセスした時点で仮説と可視化がすでに用意されています。

CanvasはOpenTelemetryのGenAIセマンティック規約を理解し、エージェントの呼び出し、LLMコール、ツールコールを1つのトレースビューにまとめて表示できます。人間とエージェントが同じ場所で作業でき、Kubernetesの閾値設定などの専門知識をスキルとしてエンコードすれば、エージェントも同僚も活用可能です。マルチプレイヤー対応により、チームメイトのカーソルを確認したりチャートを共有したりでき、調査記録としてのSlackスレッドからの大きな進化です。

Canvasの更新と同様に重要なのが、新機能のAgent Timelineです。誰もがエージェントベースのアプリケーションに取り組んでいる現在、単一のトレースビューでは不十分になりました。Honeycombはこの課題を認識し、エージェント間のやり取りを会話ベースで表示するビューを開発し、Canvasまたはトレースと並行して利用できるようにしました。

Honeycombは行き止まりを作らない設計として、Canvas、タイムライン、トレース間の移動を容易にしています。この2つの機能は参加者を魅了し、カンファレンスの話題の中心となりました。

Hangar DX Live: How Long Until We Stop Reading Code? (Ankit Jain, Aviator and Sridhar Ramakrishna, Slack)

ディベート形式で行われたこのトークは、業界の実際の状況について異例の率直さで語られました。PRの量は90〜98%増加し、レビューの時間は91%増加しており、多くの人がすでに正式なレビューをやめて独自のLLMツールを使うようになっています。

LLMをレビュアーとして使う際の核心的な問題は、フラグが立った箇所しか見えず、見逃した箇所がわからない点です。今後の方向性はレビューの廃止ではなく、分業の見直しです。決定論的な検証は決定論的なチェックに任せ、人間は判断を担うべきです。また、LLMが同じ指摘を繰り返す場合は、それを実際のチェックとしてコード化するシグナルと捉えるべきです。

Be Brilliant at the Basics: What AI-Era Software Delivery Demands of Engineering Leaders (Thomas Squeo, Thoughtworks)

Thomasのメッセージは、歩く前に走ろうとする企業に向けられたものです。堅固なCI/CD、可観測性、開発者プラットフォームなしにエージェント中心のデリバリーに移行しようとする組織は苦戦するでしょう。インシデント発生後のフォレンジック作業としてしか機能しない可観測性は、エージェントのガードレールにはなりません。プラットフォームエンジニアリングがなければ、モデル、評価、トークン管理、ポリシーアズコードを一貫して管理する場所がありません。

文化は、最悪の振る舞いを許容するようになると、それが標準になります。

Building an AI Observability Agent: Lessons from the Trenches (Rob Miles and Michael Cowgill, Stripe)

Stripeはインシデント調査エージェントを構築し、その経験を共有しました。最初の驚きは、サービス名の不一致が原因で、エージェントが単純なインシデントに対して誤った経路をたどったことでした。

もう一つの問題は、ログのサイズがLLMのコンテキストウィンドウを超えてしまうことでした。これは、ログをサブエージェントに移動させて構造化されたサマリーを返させることで解決しました。生のログデータがメインのプロンプトを埋め尽くすことを防いだのです。

Stripeはまた、評価を正しく行うことが本当に難しい問題であることも共有しました。エージェントは日付の扱いが苦手で、スナップショットは古くなり、最後の5%は依然として人間のレビューが必要です。

インシデント調査エージェントの取り組みから得られた重要な知見は、「何かを作り上げるのは簡単だが、本当にうまく作るのは非常に難しい」ということです。エージェントが最初から90%の確率で根本原因を見つけられるわけではありません。それはデータの品質に依存します。

Stripeは、エージェント経由の自然言語インターフェースを使い、HoneycombのMCPのようなMCPを指し示すことで、迅速な成果が得られると強調しました。これにより、オンコールエンジニアにより良いデータを迅速に提供し、彼らの負担を軽減できます。

Agentic Software Development at Salesforce with Honeycomb Intelligence (Nishi Bhonsie and Maksym Bogdanov, Salesforce)

Salesforceは、テレメトリーを持っている状態から実際に可観測性を持った状態への移行事例を発表しました。彼らが繰り返し強調した区別は、「意味のないスパン」でした。難しい作業は、シグナルのカタログ化、実際のビジネス価値へのマッピング、そして反復的な計装でした。

特に印象的だった3つの事例：

• 2,500人以上の開発者に影響するBazel同期問題を、よりリッチなスパンを追加することで診断したこと
• ClaudeとHoneycomb MCPサーバーを用いて、単一の自然言語プロンプトから7パネルのダッシュボードを構築したこと
• Canvas上のライブテレメトリーを使って、誰も考えていなかった根本原因を浮き彫りにしたこと

Salesforceでは、ソフトウェアエンジニアとSREの境界が曖昧になりつつあり、計装は後回しではなくファーストクラスの機能として扱われています。

Signal vs. Spend: Building Cost-Aware Observability at Slack (Emma Montross and Steven Richards, Slack)

きっかけは、1つのログ行が大量のボリュームを占めていたことでした。1時間あたり5億件の出力です。この糸をたどったEmmaとStevenは、Slackのより広範なログパイプラインに踏み込みました。1日3110億件、ピーク時440万件/秒のログが、ボリューム制限もなく、サービスごとの帰属もなく、ノイズを生成しているチームへのフィードバックもない状態でした。

彼らはログ用MCPサーバーとClaudeスキルを作成し、最悪の原因（サンプリングされていないホットパス、全体オブジェクトのダンプ、タイマーベースのチャタリング、メトリクスと重複するログ）を特定しました。そしてClaudeにソースコードへのアクセスを与え、データを添付した状態でPRを開けるようにしました。問題の再発を防ぐため、すべてのPRにログレビューエージェントを追加し、エンジニアが出荷前にログ変更のコスト影響を確認できるようにしました。

その結果、Slack全体で30%以上のコスト削減（一部のサービスでは50%）を実現し、保持期間を5日から7日に延長し、年間7桁の節約を達成しました。AI分析自体のコストは500ドル未満でした。

Martin Thwaitesはこう評しました。「経営陣は事前にトークを確認しておらず、観客席にいました。幸い、EmmaとStevenはまだ職を失っていません。30%のコスト削減が助けになったと思います。」

Beyond Documentation: Why Knowledge Trust Scoring Is the Next Frontier of Engineering Observability (Jody Bailey, Stack Overflow)

Baileyは、業界がまだ十分に取り組めていない問題を提起しました。モデルがどれだけ優れていても、基盤となる知識が信頼できなければ意味がないという点です。

ほとんどの組織では、Confluence、Jira、Notion、Google Docsなどのツールに知識が断片化しており、中には何年も更新されていないものもあります。検索できることと正確であることは別です。エージェントの知識にとって重要な信頼シグナルには、出典、最終検証日、著者の専門性、矛盾する情報、下流の結果が含まれます。

エージェントが本番環境で動作するなら、その判断を形成する知識も本番グレードでなければなりません。

Defining the Relationship: You're Not Married to Your SRE Engagement (Will Hegedus, Akamai)

WillはSREと開発を「関係性」として位置づけました。

信頼がなければ、シャドーワークやデプロイの遅延を招き、悪いSRE/開発のダイナミクスは実際の信頼性を悪化させます。最良の関係性は境界が曖昧です。優れたSREは開発者のように振る舞え、その逆もまた然りです。彼の実践的なアドバイスは、SREチームを立ち上げる前に、関係性を正式に定義することでした。スプレッドシートやナプキンに描いたベン図でも構いません。重要なのは、文書化され、定期的に見直されることです。

「脆弱性は脆弱性を生む。先に動く者が雪だるま効果を生み出す。」

Has AI Killed the SDLC As We Know It? (Boris Tane, David Poll, and Charity Majors, moderated by Jessica Kerr)

このパネルを組んだ時点で、強い意見が出ることは予想していましたが、3人の賢い人々が1時間にわたって生産的に意見を交わし、むしろ入室時より多くの疑問を抱えて退室するとは予想していませんでした。あるいは、当然の結果だったのかもしれません。いずれにせよ、素晴らしい議論でした。

論点：Jessicaがモデレートしたパネルは合意に至らず、それが有用でした。BorisはSDLCは死んだと主張しました。彼のエージェントは前のトーク中に5,000行のコードを書き、人々はもうコードを読まず、PRは化石と化していると述べました。Davidは反論しました。コードが安価になったからこそPRはより重要であり、残るのは判断、センス、そして「このプロダクトに本当に欲しいか？」という問いだと指摘しました。Charityは両者に異を唱えました。すべてを本番にYOLOで投入することはできず、ロールバックできないものもあり、摩擦は負荷を支える役割を果たすと主張しました。

合意した点：SDLCの順序は崩壊し、本番は開発の後の段階ではなく、開発の一段階となったことです。Charityの的確な診断は、PRに過剰な負担がかかっているというものでした。品質、センス、セキュリティ、プロダクト判断、感情的なしこりという複数の会話を1つのPRに詰め込んでいるのです。最も速く動いているチームは、レビュー時ではなく生成時に判断をエンコードしています。

本当の論点：コードはこれまで多すぎる役割を担ってきました。コードは仕様、契約、意図の唯一の記録であり、エージェントが数千行単位で生成するようになった今、破綻しています。Charityの処方箋は、strangler figパターンに倣ったものです。意図とコードを分離し、アーキテクチャを一度定義し、実装をそれに対して再生成できるようにする、というものです。Davidは、契約が人間とエージェントの協業の副産物になりつつあることに同意しましたが、システムオブレコードがどこに存在し、本番から乖離せずに済むのかは未解決の問いだと述べました。

Jessicaは、これまで誰も発言していなかった言葉「evals」で締めくくり、生成されたコードの上位に安定したバージョン管理可能なレイヤーとして、より高次の成果物（サービスマップ、アーキテクチャ図）を位置づけました。下位には有界な非決定性、上位には決定論的な仕様を置く。答えは得られませんでしたが、少なくとも正しい問いを立てられたのです！

Prove It: The New Bar for Observability Value (Colin Burke, Honeycomb and James Lovell, Improving)

コストの集約やエンジニアリング効率の話では、もはや新しい予算を引き出せません。予算を獲得できる会話は、収益に基づくものです。

Colinのアドバイスは、相手を知ることでした。エンジニアはアップタイムやエラーレートで話しますが、予算を決めるのは成果に基づきます。彼は、組織がすでに解決しようとしているビジネス上の課題から話を始めるよう勧めました。Jamesは、自動車金融会社がより良い計装を活用して与信審査を数日から数分に短縮した事例を挙げてこの点を説明しました。競争優位性は、そのストーリーであり、可観測性そのものではありませんでした。

Making Metrics LLM-Ready: Structured Observability Data for AI-Assisted Analysis (Stephanie Wang, MongoDB)

Stephanieのトークは、可観測性データを持っていることと、LLMから有用な回答を得られることの間にあるギャップは、モデルではなくデータの課題であると主張しました。

彼女は3つのギャップを指摘しました。システム間の断片化、収集向きに作られた生データ、そして意味の欠如（モデルは数値が良いのか悪いのかを知らない）です。

彼女の3つの解決策は、統一されたアクセス層の提供、ベースラインと差分を含む標準的な変換テンプレート、そして方向性や閾値をエンコードしたセマンティックレイヤーの構築です。

副次的な効果として、これらのツールやアプローチを提供することでLLMのコストも削減されます。彼女はこう述べました。「Sonnetで十分対応できます。Opusは必要ありません。」

Trust, Risk, and AI: A CISO's View from the Front Lines (Giles Douglas, Superhuman)

Gilesはインフラとセキュリティを兼任する異色の役割を担っており、両者の再定義を試みています。彼は、セキュリティの仕事は「何かが起こるのを防ぐこと」ではなく、「何かを安全にできるようにすること」だと主張しました。セキュリティは門ではなくガードレールを提供すべきであり、ポリシーは生きている文書でなければなりません。

彼が最もよく耳にする4つの企業AIの懸念（非決定性、エージェント間の信頼境界、データ流出、シャドーIT/ウォレット追跡/アイデンティティのすり替え）は、どれも新しいものではありません。AIがそれを加速させているだけです。

彼は、プロンプトのキャプチャはそれほど難しくないが、エージェントのツールコールのキャプチャはより困難だと指摘しました。

この文脈におけるOpenTelemetryの価値は、関係性と横方向の移動をモデル化することにあります。

ベロシティは過小評価されている課題です。Anthropicはほとんどの水曜日（Wednesday）に新しいものをリリースしています。

Socratic AI: Integrating Observability through Interactive Dialogue (Bryan Mills, Duolingo)

Bryanは、AI支援による本番調査における3つの失敗モードを指摘しました。コンテキストの欠如、記憶の不確かさ（忘却と幻覚）、厳密さの欠如（決定的証拠への固執、おべっか）です。これらは人間にも共通する失敗モードだと彼は述べました。

対策は馴染みのあるものですが、適応されています。コンテキストのためのチェックリスト、記憶のための構造化ノート、幻覚のための引用と出典、厳密さのためのピアレビューです。

エージェントが間違えたときの具体的なアドバイスは、答えを教えないことです。質問をすること。より多くの証拠を集め、自分自身を納得させるように仕向ける。「確認」と「反証」を同等に有用な入力として扱うことです。

Survivable by Humans, Uninhabitable by Machines: Is Your Production Environment Ready for AI? (Rick Clark, UST)

Rickは、現代の企業運用モデルが3つの前提に基づいていると主張しました。

• 振る舞いはコードによって決定される
• バグは既知の仕様に対する欠陥である
• テストした成果物がデプロイされる成果物である

これらは、AIが崩す前提です。

エージェントAIでは、振る舞いはモデル重み、プロンプト、ツールグラフ、検索コンテキストから実行時に創発します。エージェントは誤ったことをしながらも、素早くHTTP「200 OK」を返すことができます。

Clarkは「行動的可観測性（behavioral observability）」という用語を導入しました。これは、システムが通常のパターンから外れた振る舞いをしていないかを測定するものです。私たちの運用スタックには、まだこれを表現する語彙がほとんどありません。

The Three Pillars of Observability: Traces, and Two Things My Agents Never Look At (Corey Quinn, closing keynote)

「Runbookは負けた。トレースが今やドキュメントだ。」

Coreyは、Anthropicへの請求に関する質問から講演を始めました。技術的には正しいが「自分で調べてくれ」という内容の回答が返ってきたというものです。

トークの核心の問い：主な読み手が人間ではない場合、可観測性はどのようなものになるのか？メトリクスはエージェントにとって行き止まりです（集計によって経路が失われる）。ログは構造化を諦めたときに書くものです。トレースが玄関口です。実践的な含意：スパン名と属性名はAPIです。それらを消費するエージェントは、質問をすることができません。公開スキーマのように扱い、バージョン管理し、何かをリネームするときは変更履歴を書き、最後に触れた人がuser_idをuseridに変えるようなことをやめましょう。

トークを聞きに来て、アイデアを持ち帰ろう

15のトークすべてに通底するテーマは一貫していました。私たちがプラクティスを構築してきた前提が、現実の場面で今まさにストレステストを受けているということ。そして、うまくいっているチームは、本番環境で実際に起こっていることに細心の注意を払っているチームだということです。

もしこの内容が何かを刺激したなら、あるいはすべての基盤となる理論を知りたいなら、Observability Engineeringを手にとってみてください。