AIはSDLCを同時に2つの方向で変革しています。AI生成コードはこれまで以上に高速で、人間の監督も少なく出荷されており、一方、エージェントやLLMは本番環境で直接実行され、従来のソフトウェアとは全く異なる振る舞い（非決定論的、単一の関数やコンポーネントよりも広い影響範囲、エラーが発生した際にキャッチするスタックトレースがない）をしています。
これらの変化により、従来は複数段階に分かれていたソフトウェア開発ライフサイクルが、意図と検証の迅速なループに圧縮され、以前はプレプロダクションに存在していた作業のほとんどが本番環境でリアルタイムに行われるようになりました。Honeycombの回答は2つに分かれます。AIのためのObservability（observability for AI）は、エージェントやLLMの本番環境での実行を含む可視性を拡大し、AIによるObservability（observability with AI）は、新しいツールを使って以前より難しい問題をより速く解決します。
AIのためのObservability: エージェントワークフローは不透明だが、Agent Timelineで可視化可能
エージェントを本番環境に投入しているチームからよく聞く声は、「実際に何が起こっているのかが見えない」というものです。エージェントワークフローは分岐したり、リトライしたり、ツールを呼び出したり、他のエージェントにハンドオフしたりしますが、外から見えるのは断片だけです。何かが壊れたとき、障害はどこにでもあり得ます。
既存のツールはこの問題に対応していませんでした。LLM評価プラットフォームはモデル動作を理解しますが、データベースやAPIコールは見えません。従来のAPMツールはHTTPリクエストは見えますが、エージェント全体のインタラクションの概念はありません。エンジニアは手作業でトレースを繋ぎ合わせ、ツール間を行き来する羽目になります。
本日早期アクセスを開始するAgent Timelineは、それを変えます。会話レベルのビューを提供し、エージェントワークフロー全体を単一の視覚的なシーケンスとして描画します。すべてのエージェント呼び出し、LLMコール、ツールコール、下流のトレースを会話IDで結びつけます。
Shashankのデモでは、サポートが単一の会話IDを渡すだけで十分でした。Agent Timelineは即座に読み込まれ、所要時間、ツールコール、失敗、消費トークンのサマリーを表示しました。そこからShashankは、数秒で壊れたツールコールを特定できました。shippingサービスをオフラインにしたcheck_shippingの接続エラーです。タイムラインの下では、エージェントが呼び出していた非GenAIサービスのトレースウォーターフォールが表示され、スタック全体が1つのビューに収まりました。
AIのためのObservability: プロンプト、トークン、品質スコアがファーストクラスのテレメトリに
エージェントを本番環境に投入するということは、モデルへの入力と出力がデータベースクエリやAPIレスポンスタイムと同じくらい重要であることを受け入れることです。それらは同じシステムの一部です。本日提供開始のDeeper LLM insightsにより、プロンプト、トークン数、モデル識別子、レイテンシ分布、品質スコアがHoneycombのファーストクラスのスパン属性として扱われるようになり、OpenTelemetry GenAI semantic conventionsに準拠します。
これはトレース上のGen AIタブを基盤としています。このタブは、トレースウォーターフォールのサイドバーでLLMメッセージをMarkdown形式で直接表示し、評価やその他のAI固有のフィールドと並べて表示します。エージェントが行うすべてのことは、本番システムの残りの部分と同じ場所で見えるようになりました。何を指示されたか、何を返したか、どれだけ時間がかかったか、回答の品質はどうだったか。
AIによるObservability: Canvas調査はアラート発報時に開始される
SDLCの圧縮は、Observabilityという実践の前提自体に挑戦しています。障害は本番環境で最初に現れることが多く、常に明示的なエラーを投げるわけではありません。プロンプトのドリフトはエージェントを劣化させ、サポートエージェントが返金ポリシーをでっち上げても例外は発生しません。また、状況を把握するまで安全にロールバックできるとは限りません。時には前進するしかない場合もあります。
Observabilityは、飛行機を操縦しながら本番環境で難しい問題を素早く解決する助けになる必要があります。再設計されたCanvasはまさにそのために作られており、マルチプレイヤーコラボレーション、チームの学習に合わせて更新される生きた成果物、そしてタブを開く前にすでに作業が始まっているauto-investigationを備えています。
Taylorのデモでは、夜間に発生したチェックアウトレイテンシのトリガーがすでにauto-investigationを発動し、ランク付けされた仮説を含む構造化された計画を朝までに生成していました。Taylorはゼロから始める必要はありませんでした。ヒートマップ上の遅いリクエストのグループを丸で囲むことで、Canvasエージェントにその選択範囲でBubbleUpを実行するよう指示し、問題のあるポッドと遅いリクエストを支配している特定のユーザーを特定しました。2人目の調査者が同じCanvasに参加すると、そのエージェントはTaylorのエージェントがすでに実行した内容を読み取り、最初のエージェントがまだ見つけていなかったコンテキストを追加しました。チームのチェックアウトフローのランブックをエンコードしたカスタムスキルがアクションプランを再順序付けし、問題をP3からP2に引き上げました。
AIによるObservability: Skillsがチームの知識を将来のすべての調査に反映させる
Canvas skillsは、チームのランブックや暗黙知が調査の積極的な一部となり、誰かが覚えて開く必要のあるドキュメントではなくなります。事前構築されたスキルは、最も一般的な調査パターンをすぐにカバーします。カスタムスキルを使えば、チームが蓄積してきた特定のコンテキスト、閾値、判断ロジックをエンコードでき、すべてのauto-investigationがすでに最適な思考を適用した状態で開始されます。
Kenのデモでは、カスタマーサービスチャットエージェントのトークン使用量でtriggerが発火し、カスタムスキルを使ったauto-investigationが開始されました。Canvasは数分で全体像を組み立てました。トリガーウィンドウ内で88件の会話が80,000トークンを超え、order status agentが全トークンの79%を消費しており、check_shippingツールの暴走ループが原因でした。KenはAgent Timelineに飛び込んで確認し、エージェントが毎ターン145Kの注文データを取得してはモデルに送り返していることを発見しました。一方、同じCanvasで別のスレッドを担当していた同僚が、1週間前に追加されたシステムプロンプトのオーバーライドを発見しました。KenはそれをCanvasに引き込み、エージェントに日付を付けさせ、回帰タイムラインが自動的に組み立てられました。
ここに至るまでに提供してきたもの
MCPが読み書き可能に
MCPがローンチされた当初は読み取り専用でした。データについて質問して回答を得ることはできましたが、真にエージェント的ではありませんでした。今ではMCPは、エージェントが見つけた内容に基づいてSLOやトリガーを作成でき、人間へのハンドオフなしにAgent Skills for AI Coding Assistantsを使用できます。エージェントは問題を調査し、次に同じ問題を捉えるアラートを設定できるようになりました。
また、Claude以外との接続を煩雑にしていたOAuthの摩擦も解消しました。準拠したMCPクライアント（Claude Code、Cursor、Copilot）は事前登録なしで接続可能になりました。さらにAIエージェントは、Refineryやsamplingの設定に関する質問に正確に答えられるようになり、リファレンスドキュメントはMCPサーバー経由で直接提供されます。また、OpenTelemetry semantic conventionsをMCPサーバーに追加したため、AI生成のクエリは実際のスパン属性の意味に基づいたものになります。
Canvasの着実な拡張
Canvasは現在、triggerおよびSLO burnアラートからのauto-investigationsを実行できます。Prompt Intelligenceにより、チャートURLをCanvasに貼り付けてコンポーネントとして読み込め、既存のクエリを調査に取り込むより高速な方法を提供します。Canvas Slack appは4月から利用可能で、エンジニアリングチームがすでに使っているツールに調査機能をもたらします。コンテキスト対応のCanvasチャット（Ask Canvas）は製品全体で利用可能になり、クエリ結果、トレース、ボード、SLOをカバーし、周囲のコンテキストが自動的にモデルと共有されます。
アラート機能のスマート化
Query Math for Triggersにより、生の列値ではなく数式や数学的表現を使ってアラート条件を記述できます。BubbleUpのソートアルゴリズムは4月に改善され、ベースラインが外れ値より大きいフィールドを surfaced するようになりました。Anomaly Detection（早期アクセス）では、UIで直接異常検知器の感度を調整でき、保存前に変更の効果をプレビューグラフで確認できます。また、指標が実際に観測されているかどうかを追跡するpresence signalタイプも追加しました。サービスがデータの送信を停止した場合、それを検知したいと考えます。Anomaly profilesにはauto_investigateブール値が追加されました。異常が発火し、このフラグがオンになっている場合、Canvasのauto-investigationが開始されます。
ダークモードの提供
これは開発者コミュニティから最もリクエストの多かった機能であり、正直に言って、必要としながらも優先度が低く後回しにされがちだった地味な基盤整備のひとつでした。本日提供を開始します。UIにアクセスして試してみてください！
今後の予定
Day 3では、Honeycombがより広いツールエコシステムにどのように位置づけられるかについて俯瞰します。既存のHoneycombパートナーとの深い議論、Amazon Bedrock AgentCoreとの統合、そしてEmbraceとの新しいパートナーシップ発表を予定しています。
Day 1を見逃した方は、包括的な振り返りをお読みください。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.