Claude Code の monitoring-usage を扱った公開記事が、2026-10-07 から 2026-10-10 までに4本たまった。1本目はツール詳細のログ設定、2本目はメトリクス値の型、3本目は何を送るかの選択（selective export）、4本目は別のフィールドの型。個別に読むと、どれも「設定の説明」に見える。
だが4本を並べ直すと、別々の時点で書かれた事実が一つの軸に揃う。テレメトリの設計は、送る側（何を出力に含めるか）と受ける側（受けた値をどう扱うか）という二つの面を持ち、公式はこの二面を別々の節で説明している。横断して初めて言えるのは、この二面が同じ一つの運用規律の裏表だということ、そして実務では両者に順序の依存があるということである。
中心主張：送る側で中身を選び、受ける側で型を疑う
この4記事を突き合わせて出る中心主張は一つ。Claude Code のテレメトリは「送る側は既定で中身を出さない。受ける側は既定で型が揃わない」という非対称を前提に組まれている。だから運用は、出力に何を含めるかを先に決め、受けた値は信号ごとに型を正す、という二段構えになる。どの1記事もこの両面を同時には書いていない。
送る側：中身は既定で出ない。出すなら明示的に選ぶ
3本目（OTEL selective export の記事、https://note.com/docsfirst/n/naed8e0ff981b ）が示すのは、既定が中身を出さない側に倒れていることである。
User prompt content is not collected by default. Only prompt length is recorded
ユーザープロンプトの中身は既定では収集されず、記録されるのは長さだけである（出典 [1]）。同じ方向の既定が複数ある。ツールの入力引数とパラメータは既定で記録されない。Anthropic Messages API の生のリクエストとレスポンス本文も既定では記録されない。
1本目（2026-10-07、https://note.com/docsfirst/n/n27be75e41ba2 ）が扱ったのは、この既定を開ける側のスイッチである。
OTEL_LOG_TOOL_DETAILS Enable logging of tool parameters and input arguments in tool events
ツールイベントにパラメータと入力引数のログを有効化する設定で（出典 [1]）、MCP と Bash の監査を目的に明示的に有効化する対象である。つまり「中身を出す」のは目的（監査）があるときの能動的な選択であり、既定の放置ではない。
送る側にはもう一つ、順序の依存がある。3本目はメトリクスとログを別のエンドポイントに送る構成を扱うが、同じ記事に次の挙動が記されている。
Claude Code removes every developer-set per-signal endpoint
開発者が設定した per-signal エンドポイントを Claude Code 側がすべて除去する条件が存在する（出典 [1]）。さらにこの種の構成には最低バージョン v2.1.269 以降という前提がある（出典 [1]）。したがって送る側の作業順序は、バージョン確認 → 信号ごとの出力選択 → エンドポイント分割、であって、逆から組むと設定が黙って効かない。
受ける側：受けた値の型は信号ごとに違う
2本目（2026-10-08、https://note.com/docsfirst/n/n3425176b0dc5 ）が扱ったのは、受けた値の型である。
period_days and the counters are strings, so cast them to numbers before you compare them
period_days とカウンタは文字列なので、比較の前に数値へキャストせよ（出典 [1]）。ここが受ける側の最初の罠で、文字列のまま大小比較すると辞書順になる。
4本目（2026-10-10、https://note.com/docsfirst/n/nd66901be08f1 ）は、別のフィールドが逆方向であることを示す。
Emitted as a Boolean, not a string
あるフィールドは文字列ではなく Boolean として出力される（出典 [1]）。2本目と4本目を単独で読むと、それぞれ「ここは文字列」「ここは Boolean」という個別の注意に見える。並べると意味が変わる。信号によって型が揃っていないので、ある信号で書いたパース処理を別の信号に流用すると壊れる。受ける側は信号ごとに型を確かめ、横展開しないのが前提になる。
二面はなぜ同じ規律か
送る側の「既定で中身を出さない」も、受ける側の「既定で型が揃わない」も、どちらも「既定を信用して横着するな」という一つの姿勢に帰着する。中身は能動的に選んで出す。型は信号ごとに確かめて正す。公式は privacy の節と metrics の節に分けて書くが、運用の構えとしては一つである。
明日から取る行動
送る側（出力の選択、順序あり）:
- バージョンを v2.1.269 以降に揃えてから selective export を組む。
- 中身を出すのは監査など目的があるときだけにする。プロンプト本文・ツール引数・API 本文は既定の非収集を保ち、必要な信号だけ有効化する。
- エンドポイントを信号ごとに分けるなら、per-signal エンドポイントが除去される条件を先に確認する。
受ける側（型を疑う）:
4. カウンタ系の値は比較・集計の前に必ず数値へキャストする。文字列のまま閾値判定しない。
5. ある信号で書いたパースを別フィールドへ流用しない。Boolean で出るフィールドを文字列前提で扱わない。
やめること:
6. 「とりあえず全部送る」をやめる。中身の収集は既定で閉じているので、開けたぶんだけ責任が増える。
7. 「一度書いたパースは使い回せる」という前提をやめる。型は信号ごとに違う。