Claude Code をチーム導入|バージョン統制とプラグイン棚卸し

Claude Code をチーム導入|バージョン統制とプラグイン棚卸し

「チームの全員が同じ Claude Code を使っているはずなのに、人によって動きが違う」と頭を抱えたことのある取りまとめ役は少なくないはずです。2026 年 6 月 4 日公開の v2.1.163 で、管理者が許可するバージョン範囲を指定する設定と、導入済み拡張を一覧する /plugin list が加わりました。本記事は、この更新を「チームで足並みを揃える」運用にどう効かせるかを、実務目線でまとめます。

結論powered by Claude

今回の起点は 2026 年 6 月 4 日公開の v2.1.163 です。管理者が許可するバージョン範囲を決める requiredMinimumVersion / requiredMaximumVersion が加わり、範囲外のバージョンでは起動を拒否して承認済みバージョンへ利用者を誘導します。チーム全員を一定バージョン以上に揃える土台が、設定ひとつで用意できるようになりました。

拡張の見直しには /plugin list が効きます。導入済みプラグインを一覧でき、--enabled / --disabled で状態を絞り込めます。同じ時期に「7 Claude Plugins」「Top 5 Skills」といった“拡張の棚卸し”系の解説が上位化しており、「全部入れる」から「チームで合意した最小セットに揃える」へという流れが読み取れます。

v2.1.163 は 組織管理の権限ルールやホームディレクトリ配下の拒否ルールが効かない不具合も修正しました。つまり最新版へ揃えること自体が安全策になります。揃った状態は、レビューのやり直しや原因不明の不具合を減らし、継続案件・単価維持・引き継ぎコストの削減という形で稼ぎに効いてきます。

目次 (14)

なぜ今「チームでバージョンを揃える」必要があるのか

個人で Claude Code を使う分には、バージョンや拡張の違いはさほど問題になりません。ところがチーム(数人〜数十人)で使い始めた途端、「同じツールのはずなのに、A さんでは通る操作が B さんでは挙動が違う」という“あるある事故”が起こります。原因の多くは、各自のバージョンや導入済み拡張がバラバラなまま運用されていることにあります。2026 年 6 月 4 日の v2.1.163(リリースノート)は、まさにこの「足並みのズレ」を運用設定で抑えるための更新でした。本記事のスコープは、個人最適から一歩進んだ「チームで揃える」運用に置きます。

「同じはずなのに人によって動きが違う」事故の正体

挙動のズレは、たいてい次のどれかに行き着きます。バージョンが古い人だけ新機能が無い、各自が好みで入れた拡張が干渉する、配ったはずのルールが一部の環境で効いていない——いずれも「環境が揃っていない」ことの表れです。やっかいなのは、こうしたズレが派手なエラーではなく「なんとなく結果が違う」という形で出ること。再現性が静かに失われ、レビューのやり直しや原因不明の不具合となって、チーム全体の時間をじわじわ削っていきます。まず「揃っていないこと自体がコストだ」と認識するところが出発点です。

v2.1.163 が運用設定を強化した背景

v2.1.163 では、後述するバージョン範囲の指定と /plugin list、そして権限ルール周りの不具合修正がまとめて入りました(リリースノート)。続く v2.1.165 も「バグ修正・信頼性改善」が中心で(リリースノート)、個人向けの派手な新機能というより、複数人で安定して使うための土台づくりが続いています。動画解説でも“拡張の棚卸し”がテーマ化しており、ツール側の整備と現場のニーズがちょうど噛み合ったタイミングだと言えます。

バージョン範囲の統制設定 — 全員を一定バージョン以上に揃える

チームで最初に効くのが、許可するバージョン範囲を管理者側で決められる設定です。これにより「気づけば自分だけ古いまま使い続けていた」という状態を、運用ルールの貼り紙ではなく仕組みで減らせます。口頭で「最新にしてね」と頼むだけでは必ず取りこぼしが出ますが、起動の段階で線引きできれば取りこぼしようがありません。チーム規模が大きいほど、この差は効いてきます。

requiredMinimumVersion / requiredMaximumVersion の役割

v2.1.163 で加わった requiredMinimumVersionrequiredMaximumVersion は、管理者が許可するバージョンの下限・上限を指定するための設定です。公式リリースノートの記載によれば、自身のバージョンが許可範囲の外にある場合、Claude Code は起動を拒否し、利用者を承認済みのバージョンへ誘導します(リリースノート)。「最低ラインを満たさない環境では、そもそも動かさない」という強制力をチームに持たせられるのが要点です。お願いベースの運用から、設定ベースの統制へ一段引き上がります。

「最低を揃える」と「新挙動を待つ」の使い分け

使い分けはシンプルです。全員を一定以上に底上げしたいなら下限を、特定の新挙動を検証してから展開したいなら上限を活用します。下限で「古すぎる環境」を、上限で「検証前の最新」を、それぞれ締め出すイメージで捉えると分かりやすいでしょう。なお、設定値の具体的な記述方法はバージョンによって変わり得るため、実際のキー名・書式は必ず公式リリースノート(v2.1.163)の記載どおりに確認してください。手元で推測のコマンド列を組み立てて配ると、かえって環境差を生みます。一次情報をそのまま使うのが、結局いちばん事故が少ない進め方です。

プラグインとスキルの棚卸し — /plugin list で「本当に使う拡張」だけ残す

バージョンを揃えたら、次は拡張の整理です。便利そうな拡張を各自が思い思いに足していくと、いつの間にか「誰が何を入れているのか分からない」状態になります。乱立した拡張は、人によって挙動が変わる原因になり、レビューする側の負荷も静かに押し上げます。ここでも「足す」発想から「棚卸しして揃える」発想への切り替えが効きます。

/plugin list で現状を可視化する

v2.1.163 で追加された /plugin list は、導入済みのプラグインを一覧表示するコマンドです。--enabled / --disabled のフィルタが用意されており、有効・無効を切り分けて確認できます(リリースノート)。まずは各自の環境で何が入っているかを書き出し、チームで突き合わせるだけでも、「なぜか自分だけ挙動が違う」の多くは説明がつきます。可視化は、揃える作業の前提であり、いちばん安く効く第一歩です。

「全部入れる」より「最小セットに合意」する

同じ時期に「7 Claude Plugins Every AI Engineer」(動画, 2026-06-03)や「The Top 5 Claude Code Skills」(動画, 2026-06-03)といった“拡張の棚卸し”系の解説が上位化しています。現場が拡張を見直し始めている証跡です。さらに「MCP をやめて CLI を選ぶ」という論点の解説(動画, 2026-06-02)も出ており、「何を足すか」より「何を残すか」が問われ始めています。チームの答えは「全部入れる」ではなく「合意した最小セットに揃える」です。一覧で現状を見て、使っていない拡張を外し、残すものだけを全員で共有する。これだけで挙動差とレビュー負荷の両方が下がります。

権限・拒否ルールの落とし穴 — 配布で「ルールが効かない」を防ぐ

バージョンと拡張を揃えても、肝心の権限ルールが効かなければ意味がありません。「このパスは触らせない」「この操作は止める」といったルールこそ、チーム配布で最も外せない部分です。ところが v2.1.163 のリリースノートには、まさにそのルールが意図どおり効かない不具合の修正が含まれていました。

v2.1.163 が直した 2 つの不具合

ひとつは、組織管理の権限ルールに関する修正です。設定の取得が起動の途中で完了したケースで、そのセッション全体にわたってルールが適用されないことがありました。もうひとつは、ホームディレクトリ配下のパスに対する拒否ルール(例: Read(~/Desktop/**))が、$HOME を経由して同じパスを参照する操作を止められなかった問題です。いずれも v2.1.163 で修正されています(リリースノート)。どちらも「ルールは書いたのに守られない」という、配布側にとって最も怖いタイプの不具合です。

最新版へ揃えること自体が安全策になる

チームにルールを配るとき、配布物そのものが正しくても、受け手の環境が古ければ「効くはずのルールが効かない」状態が起こり得ます。上記の修正はその典型で、最新へ揃えることがそのまま安全策になります。不具合の内部実装に踏み込む必要はありません。「最新版で直っている。だから揃える価値がある」と実務結論に落とすだけで十分です。前節のバージョン統制の設定は、この安全策を仕組みとして担保する手段でもあります。下限を引き上げておけば、修正済みバージョン未満の環境を起動段階で締め出せるからです。

受託・チーム開発で“稼ぎ”に変える導入チェックリスト

最後に、ここまでを現場の手順に落とします。順番に進めれば、ばらつきを根性論ではなく仕組みで抑えられます。

  1. チームの最低バージョンを決め、許可範囲の設定で底上げする。古すぎる環境を起動段階で締め出す。
  2. 各自の環境で /plugin list を実行して拡張を書き出し、チームで合意した最小セットに揃える。
  3. 権限・拒否ルールを配布し、最新版で実際に効くことを確認する(v2.1.163 の修正が前提になる)。
  4. Claude Code の入門・セットアップ勉強会を、社内オンボーディングの叩き台に転用する。

4 番目は、外部の学びを取り込む手です。当社のイベント情報(2026-06-06 時点)では、6 月 6 日だけでも「Claude Code セットアップ決定版」(オンライン)や「ClaudeCode スタートアップ勉強会 #1」(大阪)が開催されるなど、入門・セットアップ系の勉強会が地方を含めて継続的に立っています(当社イベント intel, 2026-06-06)。こうした場の構成を社内オンボーディングの下敷きにすれば、立ち上げの手間を抑えつつ、新メンバーの足並みも最初から揃えられます。

「揃っている」状態は、レビューのやり直しや原因不明の不具合を減らし、引き継ぎを軽くします。それは継続案件の獲得・単価の維持・新メンバーの早期戦力化という形で、チームの稼ぎに直結します。新機能を追いかけることと同じくらい、全員の足並みを揃える運用に投資する価値がある——v2.1.163 は、その投資を設定とコマンドで現実的にしてくれる更新だと言えます。

出典

参考になったら ♡
Clauder Navi 編集部
@clauder_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。 運営方針 は メディアについて をご覧ください。