Claude Code v2.1.273：AIの権限設定を「書いて終わり」にしない

2026年9月16日

AIにリポジトリを任せるとき、怖いのは派手な誤操作だけではありません。「禁止したはずの設定が効いていなかった」「確認画面が出るはずのコマンドが通った」という静かなズレのほうが、長く残ります。

Anthropicが2026年9月15日に公開したClaude Code v2.1.273は、このズレを複数修正しました。機能追加の目玉はRemote Controlのセッション分岐ですが、企業利用で先に読むべきは権限と管理設定の修正です。今回の更新を、単なるバージョン情報ではなく「AIに任せてよい範囲をどう検査するか」という運用の話に置き換えます。

何が変わったのか

公式リリースには、権限まわりの重要な修正が三つあります。

一つ目は、permissions.blockReadsOutsideWorkingDirectoriesを有効にしていても、権限チェッカーが完全には解析できないBashコマンドで確認が飛ばされる場合があった問題です。サブシェルの中に危険なrmが隠れている場合も含まれます。v2.1.273では、この経路が修正されました。

二つ目は、同じ設定を使っている環境で、リポジトリ側が指定したメモリ用ディレクトリが作業範囲の外にある場合、その内容をプロンプトへ読み込んだり、検索・索引化・記憶抽出に使ったりしないようになったことです。ファイルを直接開かないだけでは足りません。AIの文脈に入らないところまで境界に含める必要があります。

三つ目は、組織管理者がMDMやmanaged-settings.jsonで指定したMCP制限が、サーバー管理設定と併用したときに無視される場合があった問題です。対象はallowManagedMcpServersOnly、deniedMcpServers、disableClaudeAiConnectorsです。端末側とサーバー側の設定を重ねる企業ほど影響を確認すべき修正です。

設定ファイルがあるだけでは統制にならない

Claude Codeの公式ドキュメントでは、権限ルールをdeny、ask、allowの順で評価すると説明しています。指示文やCLAUDE.mdはAIの行動を誘導しますが、実際に許可・拒否を強制するのはClaude Code側の権限機構です。

この違いは実務で大きい。たとえば「顧客データのフォルダは読まないこと」とプロンプトに書いても、それはルールではなく依頼です。読み取りを止めたいなら、作業ディレクトリ、追加ディレクトリ、denyルール、管理設定で境界を作り、その境界が実際に効くかを試す必要があります。

設定の優先順位も見落とせません。公式ドキュメントでは、組織のManaged settingsが最上位にあり、コマンドライン、プロジェクトローカル、共有プロジェクト、ユーザー設定が続きます。ただし今回の修正が示す通り、優先順位の仕様が正しくても、複数の設定供給元を組み合わせた実装に不具合があれば統制は崩れます。

中小企業では「禁止一覧」より境界テストが効く

社員全員に長い禁止事項を配っても、更新や新しいMCP接続のたびに追随するのは難しい。現実的なのは、機密度の違うフォルダを分け、AIが越えてはいけない境界を少数に絞ることです。

たとえば、開発用リポジトリの隣に、契約書、財務資料、顧客原本を置かない。必要な参照資料だけを作業用ディレクトリへ複製し、AIはそこから読む。組織で認めたMCPサーバーだけを接続し、追加接続は管理者が確認する。これなら「何を禁止したか」ではなく、「AIが触れてよい入口はどこか」で管理できます。

私は更新後の確認を、次の四段階に絞るのが妥当だと見ています。

作業ディレクトリ内の通常ファイルを読み、日常業務が止まらないことを確認する。
作業ディレクトリ外の検査用ファイルを指定し、読み取りが拒否または確認待ちになることを確かめる。
サブシェルやevalなど解析しにくい形で、破壊を伴わない検査コマンドを実行し、確認画面が省略されないことを見る。
許可済み・拒否済み・未登録のMCPサーバーを一つずつ試し、管理設定どおりの結果になるかを記録する。

本番データを使って試す必要はありません。空の検査用フォルダとダミーファイルで十分です。判定したいのはAIの賢さではなく、境界が機械的に働くかどうかです。

記録には、実行したコマンド全文、期待した判定、実際の判定、Claude Codeのバージョン、設定の供給元を残します。「拒否された」とだけ書くと、次の更新時に同じ条件を再現できません。逆に、検査用ファイルの中身や認証情報をログへ残す必要もありません。再現に必要な条件と、守るべき内容を分けて保存します。

複数人で使う場合は、管理者端末だけで合格にしないほうが安全です。一般社員の端末、共有プロジェクト、クラウドセッションでは読み込まれる設定が違います。最低でも代表的な二つの利用形態で同じ結果を確認し、差が出たら全面展開を止めます。

LLMゲートウェイ向けの観測情報も増えた

v2.1.273では、環境変数CLAUDE_CODE_GATEWAY_HINT_HEADERS=1を設定した場合、LLMゲートウェイへリクエスト種別、エージェント種別、直前のツール所要時間、コンパクション状態などを示すヘッダーを送れるようになりました。

公式のゲートウェイ文書は、認証、利用量追跡、予算管理、モデルへの経路制御を中央で扱う構成を示しています。今回のヘッダーは、その記録をもう一段細かくする材料です。通常対話とサブエージェント処理を分けたり、コンテキスト圧縮の前後で遅延が変わるかを調べたりできます。

ただし、ヘッダーを有効にしただけで監査が完成するわけではありません。保存期間、閲覧者、個人や案件へのひも付け方を先に決める必要があります。ログを増やしすぎると、今度は監査データそのものが扱いにくい機密情報になります。

更新判断は「限定GO」が安全

今回の修正は、作業ディレクトリ外の読み取りを止めたい企業、MDMとサーバー管理設定を併用している企業、MCP接続を組織で限定している企業に関係します。該当するなら更新優先度は高めです。

ただし、v2.1.273へ更新しただけで全面GOにはしません。まず検査用端末または隔離した環境で四段階の境界テストを通し、通常業務が動くことと禁止経路が止まることを両方確認します。通れば限定GO。確認画面が省略される、未登録MCPへ接続できる、作業範囲外の内容が文脈に現れる場合はHOLDです。

このリリースは権限機構の修正であり、認証情報の漏えい、悪意あるMCPサーバー、誤った管理設定、端末自体の権限不備まで防ぐものではありません。コンテナやVMによる隔離、最小権限の認証情報、ログ監査は別に残ります。

AIを業務へ入れるとき、許可設定を書いた時点はスタートです。更新のたびに「通るべき操作が通り、止まるべき操作が止まる」ことを短いテストで確かめる。設定表より、この反復のほうが会社を守ります。

一次情報

公式事実は上記リリースとドキュメントに基づきます。四段階の検査、限定GO/HOLDの基準、ログ運用の見解はmonobloによる実務提案です。

シェアはこちらから

URLをコピーしました！