Claude Code監査ラベル追加、AIエージェント運用の要点

Claude Code 2.1.161 は、大きな新モデル発表ではない。しかし、日本の開発組織が Claude Code を個人利用からチーム運用へ広げるなら、見落としにくい更新だ。

Anthropic の Claude Code changelog では、2026年6月2日の 2.1.161 として、OTEL_RESOURCE_ATTRIBUTES をメトリクスのラベルに含める変更、claude agents の表示改善、parallel tool calls の失敗分離、MCPコマンドでの秘密情報 redaction、background sessions や Windows hooks の修正などが示された。

これは「Claude Codeが少し安定した」というだけの話ではない。Claude Code Auto modeのクラウド経由運用 で整理したように、Claude Code は Bedrock、Vertex、Foundry、社内 gateway を通じて企業の開発基盤に入り始めている。今回の更新は、その基盤を監査、費用配賦、秘密情報、並列実行の失敗時運用に近づけるものとして読むべきだ。

事実: 2.1.161は監査と運用の細部を直した

まず事実を分けて見る。

Claude Code 2.1.161 の changelog では、OTEL_RESOURCE_ATTRIBUTES の値を metric datapoints のラベルに含めるようになったと説明されている。これにより、利用メトリクスを team や repo のような独自ディメンションで切りやすくなる。

同じ更新では、claude agents の行表示で fan out された作業の done/total を見せる改善も入った。peek では最も長く走っている項目を見せる。background agents を複数走らせる運用では、どの作業が滞留しているかを早く見つけるための地味だが重要な変更だ。

parallel tool calls については、Bash command の失敗が同じ batch 内の他の tool calls をキャンセルしないようになり、それぞれの tool が独立して結果を返すようになった。AIエージェントが複数の読み取り、確認、実行を並列に進めるとき、一つの失敗で全体が巻き戻ると原因分析が難しくなる。失敗を分離する変更は、レビューや再実行の判断をしやすくする。

また、claude mcp list、get、add が terminal に secrets を表示していた問題も修正された。${VAR} references は展開されず、credential headers と URL secrets は redacted される。MCP を使うチームでは、設定確認コマンドの出力がログ、画面共有、チケット、CI出力に残る可能性があるため、この修正は実務上の意味が大きい。

事実: Monitoring docsはチーム利用の前提を示している

Anthropic の Monitoring docs は、Claude Code の利用量、費用、tool activity を OpenTelemetry で export できると説明している。metrics、logs/events、必要に応じた traces を backend に送る構成で、管理者は managed settings を通じて OpenTelemetry settings をユーザーへ配布できる。

この docs では、metrics cardinality control も説明されている。OTEL_METRICS_INCLUDE_SESSION_ID、OTEL_METRICS_INCLUDE_VERSION、OTEL_METRICS_INCLUDE_ACCOUNT_UUID、OTEL_METRICS_INCLUDE_ENTRYPOINT のような変数で、metrics に含める属性を調整できる。つまり、Claude Code はすでに「個人のCLI」ではなく「組織で観測する開発ツール」としての面を持っている。

今回 OTEL_RESOURCE_ATTRIBUTES が metric labels に入ることは、この流れと整合する。日本企業でよく必要になるのは、個人別の利用量だけではない。部門、リポジトリ、プロダクト、委託先、開発環境、本番影響度のような単位で、費用と利用実態を分けて見たい。標準属性だけでは足りない場合、custom attributes を運用設計に使えるかが重要になる。

Claude Opus 4.8と動的ワークフロー では、長時間タスクや dynamic workflows が Claude Code の作業範囲を広げることを見た。作業範囲が広がるほど、観測の粒度も上げる必要がある。今回の監査ラベル追加は、そのための小さな部品である。

事実: MCPとbackground agentsは運用事故の入口になりやすい

Claude Code の MCP docs は、外部ツールやサービスを接続する方法を説明している。stdio server、HTTP server、OAuth credentials、server管理コマンドなどがあり、Claude Code が開発環境の外側へ接続する経路になる。

MCP は便利だが、企業ではリスクもある。GitHub、Slack、チケット管理、DB、社内API、検索基盤へつながると、Claude Code はコードだけでなく業務データにも触れる。だからこそ、claude mcp の設定表示で秘密情報が露出しないことは基本要件になる。今回の redaction 修正は、MCP 接続を前提にしたチーム運用で無視できない。

Agent view docs は、claude agents が複数の background sessions を管理する画面であり、各 session は supervisor process の下で動き、状態は disk に保存されると説明している。完了後に一定時間 unattached になると process は止まり、次に attach、peek、reply したときに再開される。

この仕組みは便利だが、開発組織では「誰が、どの作業を、いつ、どのモデルと権限で走らせたか」を追える必要がある。Claude Code 2.1.149/2.1.150のPowerShellとMCP修正 でも見たように、Claude Code の企業価値はモデルの強さだけでは決まらない。shell、worktree、MCP、background daemon、clipboard、IME、terminal rendering のような周辺機構が運用品質を左右する。

分析: 日本企業はteam/repoラベルを先に設計する

ここからは分析だ。

OTEL_RESOURCE_ATTRIBUTES が metric labels に入るなら、日本企業が最初に決めるべきことは「どのラベルで見るか」だ。あとから各チームが自由に team=dev、Team=Platform、repo=my-app、repository=foo のように付け始めると、費用配賦や監査で使いにくい。

最低限、team、repo、environment、cost_center、risk_class のような軸を定義したい。team は組織表の表記に合わせる。repo はGitHubやGitLabの正式名に合わせる。environment は local、sandbox、ci などに絞る。risk_class は、低リスク探索、通常修正、高リスク変更のように作業分類を示す。

この設計は経理だけのためではない。セキュリティレビューでも使う。たとえば、特定の risk_class=high の作業で MCP tool calls が増えている、特定 repo で background agents の長時間実行が増えている、委託先チームの usage が急増している、といった兆候を見られるようになる。

一方で、ラベルを増やしすぎると metrics cardinality が上がり、監視 backend の費用やクエリ性能に影響する。Monitoring docs が cardinality control を説明しているのは、この問題が実務で起きるからだ。Claude Code の観測は「何でも出す」ではなく「少ない軸で説明できる」ことを目標にしたほうがよい。

分析: MCP secrets redactionはログ運用とセットで見る

MCP秘密情報の redaction は、単独では十分ではない。

日本企業では、開発者が terminal 出力をスクリーンショットで共有したり、CI logs に貼ったり、障害チケットに残したりすることがある。claude mcp get のような確認コマンドが秘密情報を出さないことは重要だが、それでも MCP server 名、URL、tool 名、接続先の存在自体が機微情報になる場合がある。

したがって、次に決めるべきことは、Claude Code と MCP の出力をどこまでログに残すかだ。OpenTelemetry では tool details や prompt content の logging は追加設定が必要な項目として扱われる。監査のために詳細を出したい場合でも、顧客名、アクセストークン、社内URL、個人情報が混ざらないように、保存先、閲覧権限、保存期間を決める必要がある。

実務上は、MCP server の棚卸しを先に行うとよい。誰が追加できるか、どの scope で設定するか、OAuth credentials をどこに保存するか、CIや共有端末で使ってよいか、ログに何が出るかを確認する。Claude Code の redaction 修正は重要だが、MCP governance の代わりにはならない。

分析: parallel tool callsの失敗分離はレビューを変える

parallel tool calls の失敗分離は、開発者体験だけでなくレビュー方法にも影響する。

従来、並列実行の一部が失敗して全体が中断すると、人間は「どこまで実行済みか」を確認し直す必要があった。ファイルを読んだのか、テストを走らせたのか、別のツール結果は有効なのかが曖昧になると、AIエージェントの出力を信用しにくい。

今回のように各 tool が独立して結果を返すなら、レビュー担当者は「失敗した tool」と「成功した tool」を分けて見られる。これは、再実行の範囲を狭め、不要なやり直しを減らす可能性がある。特に長時間の background agents では、一つの Bash 失敗で全体の観測が失われないことが大きい。

ただし、これは自動的に安全になるという意味ではない。失敗した Bash command が重要な確認だった場合、他の tool が成功していても作業を進めてはいけない。チームは、どの tool failure をブロッカー扱いにするかを決める必要がある。テスト、型チェック、lint、security scan、migration dry-run の失敗は、AIの判断ではなく運用ルールとして止めるべきだ。

日本チーム向けチェックリスト

今回の更新を受けて、日本の開発組織が確認すべきことは五つある。

第一に、Claude Code telemetry のラベル設計を作る。team、repo、environment、risk_class のような軸を決め、表記ゆれを避ける。

第二に、MCP server の設定確認コマンドを実際に走らせ、秘密情報が出ないことを検証する。あわせて、MCP server 名やURL自体をログに残してよいかも決める。

第三に、background agents の棚卸し方法を決める。誰が動かした session か、どの repo か、どの worktree か、長時間実行をどう止めるかを明文化する。

第四に、parallel tool calls の失敗時ルールを作る。成功した tool 結果を使ってよい場合と、全体を止める場合を分ける。

第五に、Claude Code の更新を「新機能」だけでなく「運用修正」としてレビューする。Project Glasswing拡大 のような防御側の文脈でも、AIエージェントを使う組織は自分たちの運用ログと権限設計を説明できる必要がある。

まとめ

Claude Code 2.1.161 は派手な発表ではない。しかし、チームや repo 単位のメトリクス、MCP秘密情報の redaction、background agents の見通し、parallel tool calls の失敗分離は、AIコーディングエージェントを本番運用へ近づけるための部品だ。

日本企業にとって重要なのは、この更新を「修正済みだから安心」と受け取らないことだ。監査ラベルをどう設計するか、MCP を誰が管理するか、background agents を誰が止められるか、tool failure をどう扱うかを決める必要がある。

Claude Code の能力が上がるほど、運用の焦点はモデル比較から、ログ、権限、費用、失敗時の説明へ移る。今回の changelog は、その移行を進める小さなサインとして扱いたい。

出典

• Claude Code Changelog - Anthropic, 2026-06-02
• Monitoring - Claude Code Docs
• Manage multiple agents with agent view - Claude Code Docs
• Connect Claude Code to tools via MCP - Claude Code Docs