何が起きたか
AnthropicのClaude Code v2.1.161が公開されました。公式リリースでは、OTEL_RESOURCE_ATTRIBUTESの値をmetric datapointのlabelとして扱える更新、claude agentsの表示改善、/mcp画面で未サインインのclaude.ai connectorsを折りたたむ変更、並列tool callでBashが失敗した時の挙動修正などが説明されています。
大きな新機能というより、AIコーディングを「個人が便利に使う道具」から「チームで管理する作業レーン」に近づける更新です。v2.1.160が設定ファイルへの書き込み確認を強めた流れの続きとして見ると分かりやすいです。
何が変わったか
まず見たいのは利用計測です。OTEL_RESOURCE_ATTRIBUTESの値がmetric labelに入ると、teamやrepoのような軸で利用状況を切り分けやすくなります。AIツールは「便利だった」で終わると、費用対効果も事故の原因も追えません。どのチーム、どのリポジトリ、どの作業で使われたかを見られる状態に寄せる意味があります。
claude agentsの表示改善も地味ですが実務向きです。作業を分岐させた時にdone/totalが見え、peekで一番長く動いている項目を確認できると、AI作業員が複数走っている状態を人間が把握しやすくなります。
/mcpの表示変更は、接続先が増えた時の混乱を減らします。使っていないconnectorまで同じ画面に並ぶと、現場では「何が有効で、何が未設定か」が見えにくくなります。未使用のものを折りたたむだけでも、運用画面としては助かります。
小さな会社・開発会社・EC運用ではどこに効くか
少人数の会社でAIコーディングを使う時、最初に困るのは性能ではなく管理です。誰がどの案件で使ったのか。AIが触ってよい範囲はどこまでか。外部ツール接続は何が有効か。失敗した作業をどこで止めるか。このあたりが曖昧なまま進むと、便利さより不安が勝ちます。
今回の更新は、その管理側に効きます。たとえばEC運用会社なら、商品データの変換スクリプト、Shopifyまわりの調査、WordPressの小修正、問い合わせ分類の下書きなどをAIに任せる場面があります。その時に、teamやrepo単位で利用状況を見られれば、どの仕事でAIが役に立ったかを後から検証できます。
並列tool callの修正も、現場では意外に大事です。1つのBash実行が失敗しただけで同じbatch内の他の呼び出しまで巻き込まれると、作業ログの読み直しが面倒になります。AIに複数の確認作業を任せるほど、失敗時の挙動は細かく見ておいた方がいいです。
そのまま真似ると危ない点
計測できるようになったからといって、すぐに全作業へ広げるのは危ないです。metric labelに入れる情報は、便利な反面、扱いを間違えると社内情報がログ側に寄ります。案件名、顧客名、リポジトリ名、担当者名をどこまで入れるかは先に決めるべきです。
MCP connectorも同じです。接続先が見やすくなるほど、つい増やしたくなります。ただ、ファイル、ブラウザ、データベース、SaaSをAIから触れるようにするなら、読み取り専用、下書きまで、本番書き込みありを分けないと事故が起きます。
最初にやるなら何か
最初は、Claude Codeの利用を1つの検証リポジトリに絞り、計測軸を小さく決めます。おすすめはteamとrepo程度です。個人名や顧客名まで入れる必要はありません。
- team：開発、運用、検証などの大きな区分
- repo：検証用、社内ツール、公開サイトなどの作業単位
- MCP：本当に使う接続だけ有効にし、未使用のものは触らない
そのうえで、AIに任せる作業を「読むだけ」「下書きまで」「検証ブランチで変更あり」に分けます。いきなり本番サイトや商品価格に触らせる必要はありません。
monoblo実務メモ
私ならv2.1.161は、Claude Codeをチーム運用に入れる前の土台づくりとして見ます。AIの回答が賢いかどうかより、作業の見える化、接続先の整理、失敗時の扱いを決める方が、会社の仕事には残ります。
関連して読むなら、Claude Code v2.1.160の設定ファイル書き込み確認と、Dynamic workflowsの記事が近いテーマです。