Breadcrumb

Breadcrumbはコードの依存関係としてインストールする。つまりトレースデータのための外部アカウントもネットワークの往復もない。インスタンスを1つ作り、自分のデータベースに向ければ、自分のプロセス内で動く。自分で決めない限り、何もインフラの外に出ない。予想外のことはない。データ規則が厳しいチームでは、これが決め手になることが多い。

スパンはbreadcrumb_spansという単一のテーブルに正規化され、アプリがすでに書き込んでいるデータベース内に存在する。エクスポートでも、Webhookでも、他人のスキーマ越しの読み取り専用APIでもない。分析は使っているORMによる普通のクエリになり、トレースをユーザー、注文、その他保存しているあらゆるものと結合できる。たとえばPrismaのユーザーはこのテーブルを取り込み、他のモデルと同じように扱える。

モデル呼び出しは自動で計装される。Vercel AI SDKがexperimental_telemetryを期待する箇所にbc.telemetry()を渡すと、BreadcrumbはSDKがすでに出力している属性から、モデル、プロバイダー、トークン数、コスト、ペイロードを読む。呼び出しごとに手作業でスパンを組み立てる必要はない。設定は小さく保たれ、既存プロジェクトに書き直しなしでトレースを足しやすくなる。

モデル呼び出しの周辺処理は自動では計装されないので、bc.trace()で包む。検索、ツール呼び出し、最後のDB書き込みは、モデルのスパンと同じタイムラインに載る。リクエストが遅く感じるとき、遅延が検索にあるのか、ツールにあるのか、モデル自体にあるのかを推測ではなく確認できる。

BreadcrumbはMCP経由でトレースを公開するので、エージェントは開発者と同じようにクエリできる。コーディングエージェントにキーを渡して本番のトレースを掘らせてもいいし、自分でダッシュボードを読んでもいい。hidePayloadsオプションは生のプロンプトをエージェントが見る範囲から外す。トレースに機微なユーザー入力が含まれる場合に効く。

ダッシュボードはコンポーネントであり、固定のSaaS画面ではない。ホスト型ツールは全員のアプリに提供するため汎用的に留まらざるを得ないが、自分のものは自分のアプリにだけ応えればいい。自分の認証の背後に組み込み、追加のパネルをその中のページとして出せる。ダッシュボードのUIが他人のドメイン上にあり、全顧客のアプリに対応しなければならない場合、この柔軟さは得にくい。

保持は環境ごとに設定する期間で、トレースが届くたびに掃き出される。イベント単位の課金はないので、請求額を抑えるためにペイロードをサンプリングしたり捨てたりする必要はない。データをどれだけ残すかは自分で決め、その間は完全なトレースを保持できる。