社内AIの監視設定をプロジェクトフォルダへ入れておけば、担当者が変わっても同じログが残る。そう考えるのは自然です。ただし、監視先や会話内容の取得をプロジェクト側から自由に変えられると、別の問題が起きます。リポジトリを開いただけで、意図しない外部送信が有効になるかもしれません。
Claude Code v2.1.282は、プロジェクト設定とローカル設定に書かれたOpenTelemetry変数の一部を無視するようになりました。起動時、/status、claude doctorでは、無視された変数や監視を停止した変数を表示します。地味な変更ですが、社内AIの監査を「各案件の設定」から「会社が管理する設定」へ分ける材料になります。
今回変わったこと
Anthropicの公式リリースで確認できる変更は、大きく二つです。
- プロジェクト設定やローカル設定にある、OpenTelemetryの送信を有効にする変数、送信先を決める変数、内容取得を有効にする変数を無視する
- 無視された監視変数と、監視を無効にした変数を起動時、
/status、claude doctorに表示する
リリースノートでは、CLAUDE_CODE_ENABLE_TELEMETRYやOTEL_LOG_*が例として挙げられています。Telemetryの公式ドキュメントによれば、OpenTelemetryは初期状態では無効です。有効化にはCLAUDE_CODE_ENABLE_TELEMETRY=1が必要で、メトリクスやログの送信先はOTLPのエンドポイントなどで設定します。会話の内容を記録する項目は、標準では無効と説明されています。
つまりv2.1.282は、監視機能そのものを消したわけではありません。誰が、どの階層で、送信を有効にできるかを狭めています。案件のリポジトリに置かれた設定より、利用者や管理者が管理する設定を優先する考え方です。
なぜ案件ごとの監視設定が危ないのか
プロジェクト設定は共有しやすい反面、信頼境界が曖昧です。外部から取得したリポジトリ、取引先と共有する開発環境、検証用に複製したフォルダにも設定ファイルが入ります。そこから監視先や内容取得を変更できると、利用者が確認していない送信経路が増えます。
特に注意したいのは、監査ログと会話本文を同じものとして扱う運用です。実行回数、エラー、処理時間のような運用メトリクスは改善に使えます。一方、プロンプトやツールの入出力には、顧客名、ファイルの断片、社内URLが混ざることがあります。障害調査に便利だからと内容取得を常時有効にすると、守る対象が一つ増えます。
逆に、監視を全部切れば安全という話でもありません。誰がどのAIを使い、どの処理で失敗が増え、費用がどこに偏っているか分からなくなります。必要なのはログを減らすことではなく、用途ごとに記録項目、保存先、閲覧者、保存期間を決めることです。
設定の正本を三つに分ける
中小企業で運用するなら、設定の置き場所を次の三層に分けると整理しやすくなります。
- 会社管理： 監視の有効化、送信先、内容取得の可否、保存期間。管理者だけが変更できる場所を正本にします。
- 案件共有： コーディング規約、テスト方法、利用可能なコマンド。リポジトリで共有してよい業務ルールに絞ります。
- 個人ローカル： 表示や操作の好み。会社の監視方針や権限境界を上書きさせません。
この分離ができると、案件を複製しても監視先は変わりません。外部リポジトリを開いても、会社の送信方針を持ち込めます。担当者の判断に依存せず、「会社としてどこへ何を残すか」を一つの正本から管理できます。
更新後に確認する手順
- 版を確認する。
claude --versionでv2.1.282以降か記録します。 - 状態を読む。 対象プロジェクトで
/statusまたはclaude doctorを実行し、無視された監視変数と無効化された変数を確認します。 - 設定階層を特定する。 表示された変数が、会社管理、案件共有、個人ローカルのどこにあるか調べます。
- 送信内容を分ける。 メトリクス、イベント、ログ、会話内容を一括で許可せず、必要な項目だけ残します。
- 受信側で確かめる。 テスト操作を一回行い、想定した監視先に必要な記録だけが届くか確認します。設定画面の表示だけで完了にしません。
複数の部署や取引先で同じ端末を使う場合は、送信先の混在も見ます。A社の作業ログがB社用の監視基盤へ入る構成なら、設定の階層が間違っています。AI側の表示と受信側の記録を突き合わせてください。
限定GOとHOLD
限定GO： 実行回数、処理時間、エラー種別、費用など、内容を含まない運用指標。送信先と閲覧者が会社管理で固定され、保存期間も決まっている範囲から始めます。
HOLD： プロンプトやツール入出力の常時取得、案件リポジトリからの送信先変更、外部提供された設定の無検査利用。顧客情報を扱う仕事では、取得目的と閲覧権限を説明できるまで有効にしません。
v2.1.282へ更新しても、すべての監視設定が自動で安全になるわけではありません。今回の修正は、プロジェクト側から監視を勝手に有効化しにくくする境界です。管理者設定の誤り、受信側の過剰な保存、閲覧権限の広さは別に点検する必要があります。
よくある失敗を先に潰す
一つ目は、警告が出た変数をその場で削除し、記録を残さないことです。なぜ無視されたのか分からないまま消すと、別の担当者が同じ設定を戻します。変数名、置かれていた階層、削除または移動した理由を変更履歴へ残します。
二つ目は、監視データを受け取れることだけ確認し、内容を見ないことです。テスト用の顧客名や架空の秘密文字列を入力し、どの項目に現れるかを調べます。本文が不要なのに記録されていたら、内容取得を止めるか、受信側でマスキングします。実在する顧客情報やAPIキーを試験に使う必要はありません。
三つ目は、エラー調査のたびに内容取得を恒久的に有効化することです。調査期間、対象端末、閲覧者、終了時刻を決め、終わったら元に戻します。短期の調査設定を会社標準へ昇格させないためです。
四つ目は、送信先を変えた後に古い受信先を放置することです。新旧の両方へ同じログが届けば、削除依頼やアクセス権の管理対象が増えます。切り替え時は旧送信先への到着停止まで確認します。
最後に、警告を消すことを作業目標にしないでください。警告がなくても、会社管理の設定が誤っていれば不要な情報は送られます。目標は、設定の出所と実際の送信結果が一致している状態です。
まず一つ変えるなら
claude doctorの結果を一度保存し、監視に関する警告だけを確認してください。表示された変数について、管理者、送信先、記録内容の三つが答えられなければHOLDです。三つが分かり、受信側でも確認できた項目だけを残します。
監査ログは多いほど安心、ではありません。必要な記録を、会社が決めた場所へ、説明できる形で残す。その状態を先に作ると、AIへ任せる業務を増やしても調査と復旧が楽になります。