ソフトウェア開発ライフサイクルが崩壊している。何十年にもわたってソフトウェアの構築とリリースの方法を定義してきた多段階パイプラインは、インテントとバリデーションの迅速なループへと圧縮され、エージェントが構築・運用チームの一員となっている。イノベーションウィークのDay 1では、この変化がソフトウェアの検証方法、オブザーバビリティの位置づけ、そして以前から困難だった問題が今や本当に緊急性を帯びていることについて取り上げた。
本番環境は開発の最も重要なステージ
従来のソフトウェアライフサイクルでは、本番環境は最終状態であり、すべての本当の作業が終わった後にデプロイする場所とみなされていた。ステージングでバグを捕捉し、QAが承認し、本番環境はソフトウェアが生きる場所であって、理解される場所ではなかった。
このモデルは、AIが完全に崩壊させる前からすでにひずみが生じていた。AI生成コードは、以前にも増して本番前レビューが少なくリリースされている。本番環境で動作するエージェントは本質的に非決定的であり、同じ入力でも同じ出力が得られず、障害は再現性がなく、今日壊れたものは昨日は障害モードとして存在していなかった。デプロイ前にテストで自信を得ることはできない。バリデーションは実際のトラフィックに対して、実際の振る舞いに対して、ライブで行わなければならない。
本番環境は常に開発の最も重要なステージだった。私たちは今、それをそのように扱う必要に迫られているだけだ。
構築と運用のギャップは価値が死ぬ場所
多くのエンジニアリングチームは、開発（ビルド、テスト、マージ）と運用（アラート、観測、修正）の2つの別々のループで運用してきた。これらのループは何十年も並行して実行され、ほとんどコミュニケーションを取らず、互いに教訓を共有することもほとんどなかった。プロダクションでリグレッションが発生し、オンコールエンジニアが調査する。インシデント対応で得られた知見は、書き留めない限り頭の中に留まり、書き留めたとしても活用されにくい。同じ問題に遭遇する次のエンジニアは、ゼロから始めることになる。
これらのループの間のギャップは、数百万ドルの失われた価値が存在する場所だ。同じバグが再導入され、同じインシデントが繰り返され、チームの蓄積された運用知見が問題を引き起こしたソフトウェアに還元されることはない。
AIはこの問題を両端から拡大している。より少ないレビューでより多くのコードが出荷され、運用側にすり抜けたものを捕捉するプレッシャーが高まっている。同時に、AIはチームに新しい能力を与える。最善の考え方をシステム自体にエンコードする能力だ。以前は3人のシニアエンジニアの頭の中にしか存在しなかった知識を、一貫して、スケールして、すべての調査に適用できるようになった。
従来のオブザーバビリティは異なる形状のソフトウェアのために構築された
チームが本番環境でエージェントを運用し始めると、特定のギャップに気づく。カバレッジがあると思っていた。APMがあり、サービスに計装していた。作業はしていた。ところがエージェントが出荷されると、これまで構築してきたものがすべて、決定的な世界のために設計されていたことが判明する。重要事項を事前に決め、データを事前に集計し、ダッシュボードを事前に作成し、既知の障害モードをモデル化する。
このモデルは障害が予測可能な場合には機能する。エージェントは予測不能だ。エージェントがたどるパスは、その瞬間にモデルが判断したものによって形作られる。今日壊れるものは昨日は可能性として存在していなかった。チームは考古学モードに陥り、部分的なログを寄せ集め、手動でタイムスタンプを相関させ、断片からエージェントが実際に何をしていたかを再構築しようとする。
切断されたツールでエージェントをデバッグすることは、チェス盤の各駒を個別に眺めてチェスゲームを理解しようとするようなものだ。盤面は見えるが、ゲームは見えない。欠けているのは接続されたビューだ。すべてのモデル呼び出し、すべてのツール呼び出し、すべてのハンドオフとシーケンスを、実際の平均値ではなく、リアルタイムでクエリ可能にすることだ。
AIの出力品質は、アクセスできるデータの品質によって制限される。3つのツールに断片化されたデータは断片を返す。短い保持期間はパターンなしを意味する。抑制されたカーディナリティは相関関係が見つからないことを意味する。これが、接続されたデータストアにおける高カーディナリティのイベントベーストレーシングが常に正しい基盤だった理由だ。
私たちはそれがオブザーバビリティの正しい方法だと信じていた。実はそれは、エージェントに対しても正しい方法だった。
AIのためのオブザーバビリティ
Honeycombがエージェント時代に対する回答の最初の部分は、観測可能な範囲の拡大だ。エージェントが本番システムの一部となった場合、他のすべての実行中のものと同様にオブザーバブルである必要がある。
- プロンプト、トークン数、モデル識別子、レイテンシ、品質スコアは、OpenTelemetry GenAIセマンティック規約に準拠したファーストクラスのテレメトリとなる。
- LLMメッセージは、別個の評価ツールに分離されるのではなく、トレースウォーターフォールに直接レンダリングされる。
- エージェントワークフロー全体を単一のビジュアルシーケンスとしてレンダリングする会話レベルのビューが利用可能になる。すべてのエージェント呼び出し、ツール呼び出し、ハンドオフを、会話IDで結びつけ、下流サービスの完全なトレースウォーターフォールを同じビューに表示する。
外から見えるのは断片だけだ。何かが壊れたとき、障害はモデル内、下流のAPI、データベース、またはその間のどのレイヤーにおける壊れたツール呼び出しのいずれかにある可能性がある。これが、早期アクセス中のAgent Timelineが埋めるギャップだ。
回答の第2の部分は、AIを調査自体に組み込むことで、チームが以前よりも難しい問題をより速く解決できるようにすることだ。エンジニアがノートPCを開く前から始まる。
トリガーが発火したりSLOが燃えたりすると、Canvasは即座に自動調査を開始し、何が起きているかの構造化された図を構築する。順位付けされた仮説、関連クエリ、過去の調査からのコンテキスト。誰かがタブを開く頃には、作業はすでに始まっている。そしてCanvasはマルチプレイヤーなので、人間とエージェントが同じ調査を同時に行うことができ、各エージェントは他者がすでに発見した内容を読み、それを基に構築できる。
Skillsは、チームの最善の考え方を将来のすべての調査に組み込む方法だ。すべてのエンジニアリング組織には、何かが壊れたときにどこを見ればよいかを常に正確に知っている人が何人かいる。この知識をパッケージ化してスケールすることは、常に不可能だった。Skillsはそれを調査エージェントに直接エンコードし、インシデント発生初日からすべてのインシデントにランブックと組織のコンテキストが適用されるようにする。
オブザーバビリティは前提条件
この状況をうまく乗り切っている組織は、他の組織と一線を画す決断を1つ下している。それは、オブザーバビリティをエージェントシステムが出荷される前の要件として扱い、最初のインシデントの後に後付けするものではないということだ。
ある設計パートナーである大規模銀行がマルチエージェントシステムを構築する際に直接述べたように、「エージェントシステムはオブザーバビリティが整っていないと開発に入らない。どこで壊れるかわからないから」。
この考え方は、最も速く動いている企業の実践に表れている。Mixpanelは2025年7月にClaude Codeをエンジニアリング組織全体に展開し、エージェントへの支出額の信頼できる情報源の1つとして、Honeycombのボードテンプレートを使ってエージェントコストの追跡を即座に開始した。エージェントが本番環境に入るコードを書いている場合（UI作業から高度にステートフルなストレージシステムまで）、他の本番システムに適用するのと同じオブザーバビリティプリミティブが必要になる。この教訓は業界全体に当てはまる。IntercomのFinチャットボットは、数千の組織にまたがる数百万の顧客会話を処理している。解決率が低下し、最初のトークンまでの時間が上昇し始めたとき、彼らは何が起きているかを知っており、Honeycombがその理由を理解するのを助けた。解決率は現在、最高水準にある。
私たちが構築してきたものがここを指している
ここ数ヶ月で出荷してきた機能群は、AIへの方向転換ではない。同じ信念が、より可視化されたものだ。
MCPは3月に読み書き可能になった。エージェントは問題を調査し、次に同じ問題を捉えるアラートを設定することが、同じフローの中で、人間に引き渡すことなく行えるようになった。準拠したMCPクライアント（Claude Code、Cursor、Copilot）は事前登録なしで接続できる。フィードバックループ内の摩擦は、フィードバックループの敵だからだ。
Canvasの自動調査は2月にリリースされた。4日間で、91チームにわたって279件の調査が実行された。調査はアラートが発火した時点で始まる。BubbleUpは現在Canvas調査内で利用可能であり、Canvas Slackアプリは2025年4月にHoneycomb Intelligenceのお客様全員に開放され、チームがすでに使っているツールの中に調査を持ち込んだ。
これらのそれぞれは異なる形で同じアイデアを表している。本番環境で起こったこととチームがそこから学ぶことの間のフィードバックループは、可能な限り速く、正確で、完全であるべきだ。エージェント時代はこの必要性をさらに高めている。
Day 2にご参加ください
可視性が少なく、より速く動作する多数のエージェントは進歩ではない。良いデータに接続され、チームがその発見に基づいて行動するほど信頼された、1つのよく観測されたエージェントは、盲目的に動作する群れよりも価値がある。
Day 2にご参加ください。そこでは、Agent Timeline、より深いLLMインサイト、そしてエージェント時代が要求する調査に特化した再設計されたCanvasを発表した。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.