Canvas が AI Agent 開発のフィードバックループをどう駆動するか

AI agent を開発するチームにとって、フィードバックループはすでに馴染みのある概念だろう。agent の挙動を観察し、改善すべき点を見つけ、変更をリリースし、結果を測る。理論上は、この各サイクルが前のサイクルの上に積み重なり、やがてループはフライホイールとなって、agent は回るたびに効率を上げていく。

現実には、多くのチームが後手に回っている。ユーザーが異常を報告し、コストが跳ね上がり、あるいは eval スコアが下がる。誰かがログを開き、grep と祈りで何が起きたのかを再現しようとする。目の前の問題は片付いても、次の調査はまたゼロから始まる。本当のフィードバックループは、障害ではなく問いから始まる。agent はタスクでどう振る舞っているか。どこで苦戦しているか。コストとレイテンシを駆動しているものは何か。前回の変更は効いたのか。これらの答えが反復的な改善を導くはずだ。より良い計装、より精度の高い eval とテストケース、優先順位づけされた修正、そしてその修正が効いた証拠。厄介なのは、ループの各段階がたいてい別々の場所に散らばっていることだ。テレメトリは Honeycomb、ソースコードとデプロイ履歴は GitHub、作業は Linear で追跡し、意思決定とコンテキストは Slack のスレッドに消えていく。Honeycomb の Canvas は、こうしたコンテキストを一つの調査に集約する。ここで、あなたは自分のパーソナル Honeycomb agent と一緒に本番データを見る。agent はテレメトリをクエリし、仮説を検証し、何千回もの実行からパターンを見つけ出し、証拠と発見を共有の無限キャンバスに整理する。GitHub、Linear、Slack などの連携が増えるにつれ、発見をそれを生んだコードと結びつけ、チケットや変更提案に変換し、データに戻って変更が効いたかを測れる。ループを閉じるのであって、診断結果と ToDo リストを渡して終わりではない。Canvas はフィードバックループのどこか一工程を助けるだけではない。ループ全体を編成する。計装、調査、優先順位づけ、改善、検証。そう言い切れるのは、私たちが Canvas を使って Canvas を作ったからだ。その調査 agent を開発するとき、私たちは Canvas をそれ自身のテレメトリに向け、agent が振る舞いを崩している箇所を洗い出し、深刻度と発生頻度で問題を並べ、Linear チケットと prompt の変更に落とし込み、変更前後の結果を比較した。何より大きかったのは、ユーザーより先に問題を見つけられたことだ。ここから先は、このループの各段階を順にたどる。ほかのすべてを可能にするテレメトリから始める。

可用性に関する注記： Canvas のコネクタ（GitHub と Linear を含む）は現在 Beta 段階にあり、2026 年秋の正式提供を見込んでいる。これが何を意味するかはbeta プログラムの詳細を参照。

フェーズ 1：agent に計装する（見るものがなければ始まらない）

デバッグするには、まず agent が痕跡を残す必要がある。テレメトリがその痕跡だ。モデル呼び出し、ツール呼び出し、ハンドオフのたびに、所要時間、token、エラー情報が付いてくる。各ステップは span、1 回のリクエストが生む span の集まりが trace、1 回の agent 実行が生む trace は同じ conversation を共有する。だからプロセス全体を一つの物語として読める。テレメトリがなければ調査はできない。ここだけは飛ばせない段階だ。

共通言語：OpenTelemetry GenAI 規約

ツールは、どの span がモデル呼び出しでどれがツール呼び出しなのかをどう知るのか。もちろん命名規約だ。OpenTelemetry（OTel）はベンダー中立なテレメトリ送信の仕組みで、その GenAI セマンティック規約は AI 関連の部分（conversation、agent、tool、token、prompt）を gen_ai.* プレフィックスの下に統一的に命名する。この標準に沿って計装すれば、Honeycomb はカスタムのグルーコードなしにあなたのデータを読み取れる。将来バックエンドを追加したり乗り換えたりしても、縛られない。

Agent Timeline を機能させる 3 つの属性

Honeycomb の Agent Timeline は、1 回の agent 会話を読みやすい物語として描画する。span に 3 つの属性が付いていれば動き出す。設定の全体は Agent Timeline 計装ドキュメントを参照：

• gen_ai.conversation.id: 同一実行内のすべての span に付与される共有 ID。
• gen_ai.agent.name: その span を生成した agent。マルチ agent 構成では、これがあることでタイムラインが agent ごとの独立したレーンに分かれ、混ざり合わずに済む。各 agent と subagent にはそれぞれ別の名前を付けること。名前のないものはすべて “Unknown” と表示される。
• gen_ai.operation.name: そのステップがどの 種類 に属するか：モデル呼び出し（chat）、ツール実行（execute_tool）、ある agent から別の agent への呼び出し（invoke_agent）、検索ステップ（retrieval）など。

この 3 つが揃えば、Agent Timeline は動く。残りはあれば嬉しい程度のものだ。

次に、情報を充実させる

この 3 つだけでもタイムラインは動くが、いくつか加えると格段に役立つ：token 数（コストとコンテキスト膨張のシグナル）、応答したモデル名とバージョン、終了理由、そして各ツールの名前・引数・結果。「モデルが壊れた」と思われたバグの多くは、実は「ツールがゴミを返していた」だけだったりする。実際のプロンプトとレスポンスを記録しておけば、モデルがそのとき見ていた通りの会話を読み返せる。ただしサイズが大きかったり個人データを含んでいたりする可能性があるので、完全に記録する、メタデータだけにする、Collector 側で先にマスキングする、といった選択ができる。出力の品質を採点しているなら、評価スコアを span イベントとして付ければ、品質はクエリできて傾向を追えるものになる。詳しい手順は Agent Instrumentation Guide にまとめてある。OpenTelemetry で agent に計装を入れる方法を最初から最後まで解説している。

Canvas にギャップを見つけさせる

Canvas には、agent のテレメトリを 3 つの観点から能動的に監査する skill が備わっている。

1. OpenTelemetry GenAI のセマンティック規約への準拠状況を評価し、ギャップや逸脱を洗い出す
2. テレメトリが Agent Timeline、GenAI パネル、コスト計算など Honeycomb の機能の要件を満たしているか検証する
3. 運用とビジネスに関するよくある問いを並べ、そのテレメトリで答えられるか確認する

こうして設計されたテレメトリは、デバッグだけでなく、振る舞いの分析、改善の指針、実験の測定、ビジネス価値の提示にも使える。Canvas を開き、自分の agent 名でこの skill を呼び出せばいい：

“/agent-instrumentation-audit audit the investigator agent”

最高の結果を得るには GitHub 連携を有効にしておくこと。Canvas が修正まで自動でやってくれる。

フェーズ 2：agent が何をしたのかを突き止める

テレメトリがあれば、ログでは決してできなかったこと、つまり 1 回の実行がどう進んだかを最初から最後まで観察できる。たいていの調査はここから始まる。Agent Timeline を開くと、物語のように上から下へ読める。任意のステップをクリックすると、GenAI パネルがそのとき起きたことを表示する。これがモデルから見た会話であり、問題はたいていここに隠れている。しかもこれらの AI span は通常のバックエンド span と同じ trace 上にあるので、タイムラインはモデルを越えて、ツールが裏で発行したデータベースクエリや API 呼び出しにまで伸びていく。タイムラインを手で 1 ステップずつたどる必要はない。Canvas には agent のセッションをクエリして理解するための skill とツールが揃っている。Canvas にこの会話を指し示して、こう尋ねる：

“/conversation-investigation debug checkout agent conversation 7f3abde”

skill を手動で呼び出してもいいし、あるセッションについて何を知りたいかを自然言語で Canvas に伝えてもいい。

“checkout agent のセッション 7f3abde のコストとレイテンシを、操作と subagent ごとに分けて要約して。レイテンシのボトルネックと、token 使用量が過大になっている原因を特定して。”

Canvas はそのセッションを深く調査し、テレメトリデータで仮説を検証したうえで、答えとそれを裏づけるクエリへのリンクを返す。Agent Timeline をキャンバス上に置くこともでき、深リンク付きなので、いつでもその会話の完全なタイムラインを開いて、特定のステップを間近で確認できる。すべてがチャットスレッドではなくキャンバス上にあるため、人も agent も同じ共有ワークスペースで協力できる。

これで任意の実行を読み解き、説明できるようになった。だが、おかしな会話が1件あったところで、それは個別の事例にすぎない。次は視点を引いてみよう。これは偶発的な出来事なのか、それとも数千件の会話を貫く何らかのパターンの氷山の一角なのか。

フェーズ3：直す価値のある問題を見つける

視点を引くというのは、問いを変えるということだ。「この実行で何が起きたのか？」ではなく、「自分の agent が今週やったこと全体のうち、何が繰り返し失敗していて、そのどれに時間をかける価値があるのか？」。数千件の会話を1件ずつ読むことはできないし、そうすべきでもない。まずは会話に関するシグナルを集めるところから始める。すでに出力しているシグナルもあるだろう。出力の評価スコア、トピック・複雑度・意図といった分類ラベル、いいね・よくないねのようなユーザーフィードバックなどだ。これらを Canvas に渡せば、誰かが1件ずつ読まなくても、数千回の実行からパターンを見つけ出せる。ほとんどの場合、こう尋ねるだけでいい。

「評価スコアを要約して、低スコアの会話に共通するパターンを見つけて。」

「ネガティブなフィードバックが付いた会話を抽出して、トピックごとにクラスタリングして。」

「失敗を問題のトピックと複雑度でグループ分けして、件数の多い順に並べて。」

本番環境で動く agent なら、もう2つ尋ねる価値がある。コストはいくらかかっているのか、なぜ遅いのか。Canvas に agent と操作ごとに最も高コストな会話を並べさせ、prompt caching が本当に得になっているか確認したり、token を空焼きするだけで進まない混乱したループを洗い出したりできる。速度に焦点を当てることもでき、レイテンシの分布、agent ごとの初回 token 時間、どのツール呼び出しがクリティカルパス上にあるかを見られる。

「今週の最も高コストな会話を token の総使用量順に並べて、agent と操作ごとに分解して。上位のコストが主にどこで発生しているか教えて。」

「agent ごとの初回 token 時間の分布を見せて、最も遅いパスを指摘して。遅い会話を1つ選んで trace を引き出し、どこに時間がかかっているか見て。」

どう答えるかは Canvas 自身が決める。クエリを走らせ、代表的な実行をサンプリングし、ある数値属性が決め手になるなら BubbleUp を使う。探したいパターンを書けばよく、背後の仕組みを知る必要はない。内部的には、大きな問題を並列の調査に分解し、最も可能性の高い原因を比較検討して順位づけする。十数の症状はたいてい2、3の根本原因に収束し、そのうち1つが大半を占めることが多い。この順位づけが、次にどこを直すべきかを教えてくれる。

「デバッグしている」状態から「自分の agent の失敗の分類を理解している」状態へと変わる。この分類が、次にどこへ投資すべきかを教えてくれる。あとは洞察を行動に変える番だ。

フェーズ4：修正を出荷する

洞察を行動に変えるこの段階を、ほとんどの可観測性ツールは自分でやれと放り出す。問題を提示したら、あとは別のタブでチケットを書き、コードを直せと丸投げする。Canvas はその流れの中にとどまる。実際に手を動かして直す場所とつながっているからだ。agent の修正が1行のコードパッチであることはほとんどない。よくあるのは、言い回しを変える必要のある prompt、モデルを誤った方向に導くツールの説明、間違ったコンテキストを引いてくる検索ステップ、欠けているガードレール、あるいはより強力なモデルや専用ワークフローにルーティングすべき難問だ。先ほど優先順位をつけた失敗パターンは、たいていそのどれかを指している。GitHub と Linear のコネクタを有効にすれば、Canvas は調査の途中で直接動ける。

• pull request を開く。
• 失敗パターンを証拠とともに記録した Linear のチケットを作る。
• リグレッションと最近出荷されたコード変更を関連づける。

書き込み操作は常に承認を経由する。Canvas はまず変更を下書きし、何が起きるかを完全に示す。承認するまで、マージもリリースもアーカイブも起こらない。

「観測された失敗パターンを深刻度と発生頻度で並べ、Checkout Agent プロジェクトの Linear チケットにすること。優先度を設定し、ステータスは To do にする。」

「honeycomb/checkout に対して PR を起草し、返品ポリシーのプロンプトを書き直して、いま見つけた失敗パターンを修正する。同時に Linear チケットを開き、最悪の 5 件の会話を証拠としてリンクすること。」

チケットも PR も調査の途中で生まれる。だから文脈が最初から付いてくる。レビューする側は失敗した会話を確認でき、たったいま出した変更が次の検証対象になる。効いているのか？　このループの最後の環は、効いていることを証明することだ。

フェーズ 5：効いていることを証明する

決定論的なソフトウェアなら、バグを直せば直ったで終わりだが、agent はそんな決着を与えてくれない。同じ変更が、ある種のリクエストには効いても別の種には害になることがある。しかも実行ごとに出力は変わるので、「試したら良くなった気がする」は証拠にならない。必要なのは、同じシグナルで実トラフィックの前後を比較することだ。ここで効いてくるのが、インストルメンテーションの時点で付けておいたバージョンタグである。span に gen_ai.agent.version（または service.version）が付いていれば、Canvas は旧バージョンと新バージョンの失敗パターン率、eval スコア、コスト、レイテンシを突き合わせられる。実験のバリアント同士を比べることもできる。デプロイのタイムスタンプから推測する必要はない。

「investigation agent の v2.5 前後で、URL ハルシネーションの失敗率と平均 accuracy スコアを比較して。この修正は失敗を減らしつつ、ほかを劣化させていないか？」

Canvas は両方のデータを取り出し、並べてグラフに描き、目的の指標が動いたかどうか——そして他の指標がつられて動いていないか——を教えてくれる。

いちばん危ない変更は、いま見ている問題は直ったのに、見ていない場所を壊している変更だ。だからメトリクスは、アラートを一度も鳴らさない緩やかな劣化を捉えられなければならない。eval スコアを時系列でグラフにし、どこかの線が折れたら、GitHub コネクタを通じて Canvas がその時点の前後にマージされた PR を読み、最も怪しい diff を指し示す。どちらの結果であれ、期待ではなく証拠でループを一周閉じることになる。修正が効いたのか効かなかったのか、次に何を調べるべきかがはっきりする。しかも比較もスコアもメモも canvas 上に残るので、次の人は白紙ではなく、より整理された地点から始められる。修正が一度効くのと、効き続けるのは別の話だ。この一度きりの確認を継続的な監視に変えるアクションが 2 つある。

• 比較結果を board として保存する。 Canvas に before/after ビューを Honeycomb board へ昇格させれば、スナップショットは一時的なキャンバス上の使い捨てではなく、チームが眺め続けるライブダッシュボードになる（board の作成は書き込み操作なので、PR と同じく承認フローを通る）。
• トリガーを設定して、自分で調べさせる。 本当に重要な指標にトリガーを付けておけば、リグレッションが出た瞬間に通知が届く。自動調査を有効にすると、Canvas が仮説、裏付けるクエリ、原因についての最初の推測をそのまま開き、すべて board 上に並べてくれる。

回り続けるように設計する

Canvas はこのループ全体をひと続きの動作のように感じさせる。各周回が次の周回の入力を生む。調査の過程で溜まっていく skills、boards、triggers によって、チームは「誰かが文句を言ってからデバッグする」から「自分を観察するシステムを走らせ、発見と優先順位付けされたアクションを受け取る」へと移行できる。しかも周回ごとに賢く、速くなる。私たち自身の agent も、このループで Canvas を作っている。ひとつ開いて、回し始めてほしい。

Canvas を最大限に使う

Canvas での調査がうまくいく習慣がいくつかある。

• キャンバスに描く。 図形を選び、ヒートマップの領域を丸で囲み、クラスタをハイライトする。言葉で説明するより速く、正確だ。特定の時間帯にレイテンシのスパイクが見えたなら、タイムスタンプを打ち込むのではなく、それをそのまま選ぶ。agent はキャンバスの内容と現在の選択を認識する。

• ツール呼び出しを展開して、推論を確認する。 Canvas は実行したすべてのクエリと、得たすべての結果を表示する。参照したデータセット、時間範囲、フィルタ条件が正しいか確かめる。agent が意外な結論を出したときは、たいていここにある誤った前提が原因だ。

• 途中で介入する。 agent の完了を待つ必要も、いったん止めてから方向を変える必要もない。新しいメッセージを送れば、その場で軌道を修正する。調査が 3 手目で道を外れたと気づいたら、そう言えばいい。

• チームの知見を Skills に書く。 チームは Canvas が知らないことを知っている。どのサービスが最も重要か、リリースのリズムはどんなものか、あなたの agent はどんな能力を持つべきか、agent の動きに影響しうる新機能やプロジェクトは何か、あなたの agent にとって何が「正常」か。こうした文脈を skill として書く。Canvas はそれらを自動で参照し、調査のたびに、チームメンバーの間で積み上がっていく。早めに作る価値があるのは 2 つ。進行中のプロジェクトと機能を追うものと、リリース用のものだ。ある変更の Linear プロジェクトと GitHub リポジトリを渡し、ローンチ後に何を見張るべきか尋ね、その質問に答えるのに必要なインストルメンテーションが揃っているかをリリース前に確認させる。

• GitHub、Linear、その他のコネクタを接続する。 GitHub はソースコードとデプロイ履歴を agent に渡すので、リグレッションをそれを出した PR に結び付け、実際のコードと照らしてインストルメンテーションを検証し、具体的な diff を提案できる。Linear はプロジェクトと issue の文脈を渡すので、あなたが何に取り組んでいるかを把握し、調査からそのままスコープの明確なチケットを開ける。接続したデータソースはそれぞれ、agent に渡る文脈が増えるということだ。このリストは急速に伸びており、さらに多くの連携が控えている。

• トリガーには明確な説明を書く。 自動調査が発火したとき、トリガーの説明が Canvas agent の文脈になる。指標名だけを書かないこと。デバッグ手順を書き込むか、agent が呼ぶべき skill を指定する。「routing agent のエラー率 > 5%。まずデプロイとの関連を確認し、次にツール障害を種別ごとに調べる」のほうが、「エラー率が高い」より Canvas はずっと早く動き出せる。

• Canvas に発見の整理方法を指示する。 デフォルトのレイアウトで事足りることも多いが、エグゼクティブサマリーを先頭に置きたい、特定のグルーピングにしたい、視覚的な重点を変えたい、といった要望も出てくるはず。そのまま伝えればいい。「サマリー部分と詳細部分に再構成して」「コストチャートを並べて比較しやすくして」といった具合に。キャンバス上の領域を選択して、その部分だけ並べ替えさせることもできる。

• Pages を使う。 Canvas では 1 回の調査で複数のページを作成できる。読者や関心ごとに内容を整理したいときに便利だ。詳細な調査とは別に「Summary and Actionable Takeaways」ページを追加するよう頼んでもいいし、仮説ごとに 1 ページ、あるいはステークホルダーごとにページを分けることもできる。

• Canvas で eval とデータセットを構築する。 Canvas に eval の下書きを作らせ、実際の本番会話をサンプリングして検証し、妥当かどうかを確かめられる。会話を選んで回帰テストや eval データセットにすることもできる。見つかった失敗事例はテストケースになり、同じ問題の再発を防げる。

• リアルタイムで共同作業する。 Canvas は複数人が同時に使える。インシデント対応中にキャンバスをチームメイトと共有すれば、全員が同じ発見を、同じ文脈で、リアルタイムに同期して見られる。自分の観察を agent の発見にピン留めすることも可能だ。

• MCP 経由で自分のワークフローに Canvas を持ち込む。 必ずしも Honeycomb UI の中にいる必要はない。Honeycomb MCP server を有効にすれば、Canvas のツールが普段使っている環境に現れ、開いているタブからそのまま調査を開始したり、発見を取得したり、Canvas を操作したりできる。

• フィードバックの仕組みを使う。 Canvas の回答が特に優れている、あるいはひどいと感じたときは、親指を上げる／下げるアイコンをクリックし、フィードバックのアンケートに答えてほしい。内容は私たちのチームに直接届き、すべての人の Canvas 改善に役立てている。agent に頼んでフィードバックを送ってもらうこともできる。