AI SDK Telemetry は「全部ログに残す雑さ」をやめろと言っている

要点

要点まとめ

AI の挙動を見えるようにしたいなら、prompt と出力を何でもかんでも保存する前に、本当に必要な観測項目と残してはいけない内容を分ける必要がある。
この docs の価値は、AI observability を callback の寄せ集めではなく OpenTelemetry ベースの trace 設計として扱っている点にある。
`recordInputs` と `recordOutputs` は初期状態では有効だが、必要なら切れる。つまり『見える化のために全部保存』が前提ではない。
`functionId` と `metadata` を span に乗せる設計により、どの機能の失敗かを追いつつ、記録範囲を狭める中間設計ができる。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 作る前に確認したい

API や設定を試す前に、先に落とし穴を知りたい人向け。

同じテーマで読む 評価・Evals

品質劣化、回帰テスト、ベンチマーク、運用監視。

次の記事 agentic coding benchmark の 2点差は、モデル差ではなく RAM の差かもしれない

Anthropic は、AI coding benchmark の点差が『モデルの賢さ』だけでなく、マシン設定の違いでもかなり動くと示している。

読解

何が変わったのか

この docs は Telemetry を experimental feature としたうえで、OpenTelemetry に載せる形を示しています。`experimental_telemetry: { isEnabled: true }` で function call ごとに有効化でき、Next.js 側では先に OpenTelemetry を有効にする流れです。重要なのは、入力値と出力値の記録が調整できることです。docs では telemetry を有効にした時、`recordInputs` と `recordOutputs` は初期状態で有効ですが、どちらも `false` にできると書かれています。つまり trace は残すが中身は減らす、という中間設計が可能です。

日本の文脈

なぜ重要か

日本語圏では AI observability が『prompt と output を全部保存して後で見る』方向へ寄りやすいです。しかしそれでは privacy、転送先、保存期間、閲覧権限の問題がすぐ出ます。この docs は、観測項目を細かく選ぶ前提を与えています。また eval との切り分けにも意味があります。observability は本番の挙動を追うためのもので、品質採点の全てを肩代わりするものではありません。trace に何を残すかを決めずに eval と監視を同じ箱に押し込むと、情報量は増えても判断は雑になります。

技術ポイント

技術的ポイント

AI SDK Telemetry は OpenTelemetry を使って trace を集める設計で、experimental feature と明記されている。
`experimental_telemetry` で function call ごとに有効化できる。
`recordInputs` と `recordOutputs` は初期状態では有効だが、必要に応じて `false` にできる。
`functionId` はどの機能の trace かを識別するために使え、`metadata` は追加の文脈情報を span 属性として持たせるために使える。
docs には `ai.model.id`、`ai.model.provider`、`ai.usage.*`、`ai.telemetry.metadata.*` のような span 属性例もあり、何が trace に乗るかを想像しやすい。

用語

英日キーワード

英語	日本語	補足
telemetry	テレメトリー / 観測データ	実行中の挙動を追うための計測情報。AI では prompt や出力を残しすぎない設計が特に重要になる。
OpenTelemetry	OpenTelemetry	trace や span を標準化して扱う observability 基盤。AI の遅延や失敗を追えるが、中身の記録範囲は別途設計が要る。
recordInputs	入力記録	prompt や引数の中身を trace に残す設定。便利でも、個人情報や社内文書を無差別保存しやすい。
recordOutputs	出力記録	応答や生成物の中身を trace に残す設定。品質確認に役立つ一方、誤情報や機密も観測基盤へ流しうる。
functionId	機能識別子	どの機能の trace かを見分ける ID。遅さや失敗を feature 単位で追うための足場になる。
span metadata	スパン付加情報	trace に補足文脈を載せる属性群。tenant や feature flag を追えるが、載せる情報の機密性に注意が要る。

試す

試すなら

まず『遅さ調査』『失敗率把握』『品質確認』のどれが目的かを分ける。
その上で、prompt 全文や出力全文を本当に残す必要があるかを確認し、不要なら `recordInputs` や `recordOutputs` を切る。
`functionId` を機能単位で付け、どの UI や workflow の問題かを trace から辿れるようにする。
trace の保存先、閲覧者、保持期間を決めずに本番へ入れない。

注意

注意点

この docs は計測の仕組みを示すが、個人情報や社内機密をどこまで記録してよいかは別途の運用判断が必要である。
telemetry を入れても、評価用 dataset や人手レビューの代わりにはならない。
experimental feature なので、将来の API や属性名が変わる可能性がある。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。