Claude CodeのrequiredMinimumVersionで古いバージョンの起動を止める
requiredMinimumVersionは、管理設定で下限を決め、古いClaude Codeを起動時に終了させるキーです。minimumVersionとの違い、反映のタイミング、実行中セッションが止まらない点、値の決め方を扱います。
requiredMinimumVersionは、組織が許可するClaude Codeの最古バージョンを管理設定で決めるキーです。実行しているバージョンがこの値より古いと、Claude Codeは起動時に終了し、組織が定めた更新手段で上げるよう利用者に案内します。v2.1.163以降で使えます。
検査は起動のときに1回だけです。すでに動いているセッションは止まりません。この一点が、運用で最初につまずく場所になります。
requiredMinimumVersionは何をするキーか
公式の設定リファレンスでは、このキーは「組織が起動を許可する最古のバージョン」を決めるものと説明されています。仕様を表にすると次のとおりです。
| 項目 | 内容 |
|---|---|
| 置ける場所 | 内容管理設定(Managed)のみ |
| 型 | 内容"2.1.150" のようなバージョン文字列 |
| 既定値 | 内容未設定(下限なし) |
| 必要なバージョン | 内容v2.1.163以降 |
| 検査のタイミング | 内容起動時のみ |
設定例は1行です。
{
"requiredMinimumVersion": "2.1.150"
}管理設定以外のファイル、つまりユーザー設定やプロジェクト設定にこのキーを書いても、Claude Codeは警告を出さずに無視します。「書いたのに効かない」ときは、まず置き場所を疑います。
minimumVersionとの違い
名前のよく似たキーが3つあり、効き方が違います。
| キー | 置ける場所 | 止めるもの |
|---|---|---|
minimumVersion | 置ける場所どの設定ファイルでも可 | 止めるもの自動更新とclaude updateが、下限より古い版を入れること |
requiredMinimumVersion | 置ける場所管理設定のみ | 止めるもの下限より古いバージョンの起動 |
requiredMaximumVersion | 置ける場所管理設定のみ | 止めるもの上限より新しいバージョンの起動 |
minimumVersionは、更新が古い方向へ動くのを防ぐ安全弁です。公式のセットアップ手順では、/configで更新チャンネルを"stable"に切り替えても、すでに入っている新しい"latest"のビルドがダウングレードされないようにする用途が挙げられています。すでに古いバージョンに乗っている端末の起動は止めません。
起動そのものを拒否したいときに使うのがrequiredMinimumVersionです。範囲で縛りたいならrequiredMaximumVersionと組み合わせます。両方を設定すれば、許可するバージョンの幅を管理設定側で決められます。
バージョンの固定や戻し方を個人の手元で扱う手順は、Claude Codeバージョンの確認・固定・ダウングレード手順にまとめています。ここでは組織側の強制に絞ります。
実行中のセッションは止まらない
公式の管理設定のページには、長く開きっぱなしのセッションについて次の趣旨の記述があります。requiredMinimumVersionは古いバイナリの起動を防ぐが、すでに動いているセッションは終了させない、というものです。
運用に引き直すと、次のようになります。
- 下限を引き上げた日に、古いバージョンで開いたままのセッションは動き続ける
- そのセッションを閉じて、もう一度起動した時点で初めて拒否される
- 数週間つけっぱなしの端末では、強制が効くまで時間差が出る
「配ったのに古い版が動いている」という報告のうち、再起動を挟んでいない端末は、この時差で説明がつくことがあります。強制の完了を確かめたいときは、利用者に再起動を依頼するのが確実です。
反映のタイミングは配信経路によっても違います。公式のページでは、requiredMinimumVersionの変更は次のセッション開始時に反映される、と書かれています。サーバー管理設定の場合、クライアントは次の起動か1時間ごとの取得でポリシーを受け取ります。ただし、このキー自体の効力が出るのは起動時の検査なので、取得が済んでいても、再起動までは古いままのセッションが残ります。
範囲外になった端末から抜け出す方法
古いバージョンで起動が拒否されると、利用者は何もできなくなるように見えます。実際には復旧用の経路が残されています。
claude update、claude install、claude doctorの3つは、下限を下回っていても動きます。利用者はclaude updateで承認済みのバージョンへ上げるか、claude doctorで状態を確認できます。
claude --version
claude update
claude doctor拒否メッセージが指す「組織が定めた更新手段」は、組織ごとに違います。MDMやパッケージ管理で配っている環境では、利用者がclaude updateを打っても通らないことがあります。そうした環境では、拒否時の案内先(社内のIT窓口など)を、companyAnnouncementsや社内ドキュメントで先に伝えておくと問い合わせが減ります。
値を間違えたらどうなるか
requiredMinimumVersionは、不正な値を入れても組織全体の起動不能にはならない設計になっています。公式のページには、このキーとrequiredMaximumVersionは「フェイルオープン」、つまり不正な値は強制されずに捨てられる、とあります。バージョンとして読めない文字列は無視され、下限なしのまま起動します。
この性質には、見落としやすい裏面があります。
"v2.1.150"のように接頭辞をつけた書き方が有効な値として扱われるかは、公式の記載がない。手元のテスト機で、意図した端末が拒否されるか確かめる- タイプミスは起動を止める側ではなく、強制がかからない側に倒れる。止めるつもりが止まっていない、という形で気づくことになる
- 捨てられた値は、
claude doctorが無効なエントリとして列挙する
セキュリティ系のキーの多くは、不正な値を「厳しい側」に倒す扱いです。このキーはその逆で、起動を妨げないことを優先しています。「設定したから強制されている」と思い込まず、実際に効いているかを端末で確認する運用が要ります。
効いているかを端末で確認する
管理設定が効いているかは、/statusとclaude doctorで切り分けます。
/status/statusのSetting sources行にEnterprise managed settingsが出ていれば、管理設定のどれかが採用されています。括弧の中が配信元を表します。(remote)はサーバー管理設定、(plist)と(HKLM)はMDMやOSのポリシー、(file)はmanaged-settings.jsonです。
行そのものが出ないときは、管理設定のファイルが置かれていないか、ポリシーのキーを含んでいません。別の配信元が採用されているときは、Skipped sources行に、採用されなかった側の配信元が出ます。複数の経路で管理設定を配っている組織では、ファイル側に書いたrequiredMinimumVersionが、優先度の高い別の配信元に隠れて効いていないことがあります。
値が捨てられていないかはclaude doctorで見ます。対話セッションでは、起動時に無効なエントリを列挙するダイアログも出ます。-pによる非対話実行では、同じ内容が標準エラーに出力されます。
上限と組み合わせて範囲にする
下限だけでなく上限も決めたいときは、requiredMaximumVersionを同じ管理設定に並べます。
{
"requiredMinimumVersion": "2.1.150",
"requiredMaximumVersion": "2.1.200"
}上限には下限にない働きがあります。公式の説明では、自動更新とclaude updateは上限を超えるバージョンを入れません。範囲の内側にいる端末は、更新によって範囲の外へ出ません。下限側は更新を止めるキーではないので、範囲内の端末が自動更新で新しい版に乗ること自体は妨げられません。
上限を使うかどうかは、検証の体制次第です。新しいバージョンを社内で確かめてから配る組織なら、上限が「確かめていない版を使わせない」柵になります。逆に、新機能をすぐ使いたい組織が上限を厳しく置くと、検証が追いつくまで全員の更新が止まります。下限だけで運用を始め、必要になってから上限を足す進め方もあります。
配信面ごとに届く範囲が違う
管理設定の経路によって、届く先が異なります。
- サーバー管理設定: 管理コンソールから配る。Coworkのセッションには届かない
- MDMとファイルベース: 端末に置く。Anthropicがホストするクラウドのセッションには届かない
- Cowork: 端末上で動く場合は、その端末のMDMやファイルのポリシーを読む。完全なVMサンドボックスで動く場合は、端末のポリシーが存在しない
「バージョンを揃えたい」という目的がバイナリを持つ端末を対象にしているなら、端末に置く経路(MDMかファイル)が基本になります。サーバー管理設定だけに頼ると、Coworkの端末は対象外です。配信経路の選び方はClaude Code組織管理ガイドで、設定の優先順位は管理者向けの判断マップで扱っています。
下限の値は何にするか
公式は値の決め方を示していません。運用上の考え方だけを挙げます。
起動を止める設定なので、現在の最新版をそのまま下限にすると、更新の追いついていない端末が一斉に拒否されます。範囲を絞るほど、利用者への影響は大きくなります。
- 現場のバージョン分布を先に調べる。
claude --versionの出力を、既存の端末管理ツールから集める - 既知の不具合や脆弱性が直ったバージョンを、下限の候補にする
- 候補の版を、テスト機の管理設定に入れて、拒否の挙動と案内文を確かめる
- 全体への配信は、拒否された利用者が自力で上げられることを確かめてから行う
下限を上げる前に、更新の手段を整えておくのが順序です。Claude Codeの更新手段はインストール方法で異なるため、Claude Codeの更新ガイドで方法ごとのコマンドを確認できます。
自動更新に任せている端末は、下限を現行の少し前に置けば拒否されにくい傾向があります。逆に、バージョンを固定している環境や更新を遅らせている環境では、下限の引き上げがそのまま作業の停止につながります。
リリースの経緯と、導入前の注意
このキーは、v2.1.163でrequiredMaximumVersionとともに加わりました。経緯はリリースノートのClaude Code v2.1.163に載っています。
導入前に押さえておく点は2つです。
- v2.1.163より前のバージョンでは、このキーを使えない。公式は「v2.1.163以降が必要」と明記しており、それより古いバージョンが管理設定のこのキーに従うとは書かれていない。古い端末は、キー以外の手段(端末管理側の更新)で上げておく
- 反映は次のセッション開始から。変更を入れた直後に全員が対象になるわけではない
まとめ
requiredMinimumVersionは、更新を縛るminimumVersionと違い、古いバージョンの起動そのものを止められます。ただし効くのは起動の瞬間だけで、不正な値は黙って捨てられます。値を配ったら、/statusとclaude doctorで実際に効いているかを端末で確かめるところまでが設定の仕事です。