結論：2026年8月11日〜13日にリリースされたClaude Code v2.1.228〜v2.1.231で、権限・安全まわりの変更が集中的に入りました。8月14日のAuto Mode標準化（Pro/Max/Teamプランの新規セッションでデフォルト化）とセットで読むべきアップデートです。
- 自動承認の線引きが変わった：
/commit-push-prコマンドで--force・--amend・--no-verifyなどの危険フラグ付きgit/ghコマンドが自動承認されなくなった - 持ち込みコンテンツの無害化：claude.aiから同期されたスキルはローカルコマンドを上書きできず、本文中の
!コマンド実行・@ファイル展開が無効化された - fail-closed化：サンドボックスのネットワーク許可リストで曖昧な表記が「許可しない」側に倒され、
/doctorが検出するようになった
対象読者：Claude Codeを日常運用している開発者・チームリード、そして8月14日以降のAuto Mode標準化を前に「権限まわりの挙動がどう変わるのか」を正確に押さえたいセキュリティ・情報システム担当。この記事では5つの変更点の中身と、開発チームが今週やるべき確認手順まで一気に解説します。
正直、リリースノートの1行1行だけを見ると地味なアップデートです。ただ、8月14日にAuto Mode（権限プロンプトを分類器の自動判定に置き換えるモード）がPro・Max・Teamプランの新規セッションでデフォルトになるタイミングと重ねて読むと、見え方が変わります。「人間が毎回承認する」前提が外れる直前の週に、自動承認してよい操作の線引きを狭め、外部から持ち込まれるコンテンツの実行経路を塞ぎ、曖昧な設定を安全側に倒す変更がまとめて入った。偶然ではなく、標準化に向けた地ならしとして読むのが自然です。
本記事では、公式チェンジログ（code.claude.com）と権限モードの公式ドキュメントを一次ソースに、v2.1.228〜v2.1.231の安全側変更を5つに整理して解説します。
何が起きたのか：8月11日〜13日の3リリースに安全側の変更が集中
まず時系列を整理します。公式チェンジログによると、直近3日間のリリースは以下の通りです。
| バージョン | リリース日 | 安全・権限まわりの主な変更 |
|---|---|---|
| v2.1.228 | 2026年8月11日 | claude.ai同期スキルのハードニング／Writeツールの上書きルール変更／Auto Mode初回通知から「コスト増」注記を削除 |
| v2.1.229 | 2026年8月12日 | /commit-push-prの危険フラグ自動承認廃止／サンドボックスのネットワーク指定fail-closed化／Auto Mode不具合修正／/loginの警告強化 |
| v2.1.231 | 2026年8月13日 | MCP OAuthサインインのredirect URI不一致修正（Slack等の事前登録型OAuthクライアント） |
機能追加も多数含まれますが（Remote Controlの--continueドキュメント化、プラグインマーケットプレイスのcommandソース対応など）、この記事では安全側の変更に絞ります。Remote Control自体の使い方はClaude Codeスマホ操作｜Remote Controlガイドで解説済みです。
変更点1：/commit-push-prが危険フラグを自動承認しなくなった
v2.1.229で最も実務インパクトが大きいのがこれです。公式チェンジログの記載は次の通りです。
Changed /commit-push-pr so git/gh commands with dangerous flags (–force, –amend, –no-verify, etc.) are no longer auto-approved.
（/commit-push-prを変更し、危険なフラグ（--force、--amend、--no-verifyなど）を持つgit/ghコマンドが自動承認されないようにした）
/commit-push-prは「コミット→プッシュ→PR作成」を一気に流すビルトインのスラッシュコマンドで、ワークフローとして実行されるgit/ghコマンドは通常のBash権限チェックより緩く自動承認されていました。今回の変更で、履歴を書き換える--force・--amendや、フック検証をスキップする--no-verifyのような「取り返しがつかない・ガードを外す」系のフラグが付いた場合は自動承認の対象から外れ、承認プロンプト側に倒れます。
これはAuto Modeの分類器が持っている思想と同じ方向です。権限モードの公式ドキュメントによると、Auto Modeの分類器はデフォルトで以下のようなgit操作をブロックします。
- force push（強制プッシュ）
- そのセッションで作成していないHEADコミットへの
git commit --amend、およびプッシュ済みコミットへの--amend（v2.1.198以降） git reset --hard・git checkout -- .・git clean -fd・git stash dropなど、未コミット変更を破棄すると推定される操作
つまり「分類器が守っている線」と「ワークフローコマンドの自動承認の線」がズレていた部分を、厳しい側に揃えたアップデートと言えます。普段/commit-push-prで高速に回しているチームは、force push系の操作だけプロンプトが増えますが、これは受け入れるべきコストです。
変更点2：claude.aiから同期したスキルの「無害化」
v2.1.228のこの項目は、見落とされがちですが構造的に重要です。
Hardened skills synced from claude.ai: they no longer shadow local commands or MCP prompts, their descriptions are sanitized and labeled, and on your machine their bodies don’t run ! commands or expand @ files.
（claude.aiから同期されたスキルをハードニング：ローカルコマンドやMCPプロンプトを上書き（shadow）できなくなり、説明文はサニタイズ・ラベル付けされ、ローカルマシン上ではスキル本文の!コマンド実行と@ファイル展開が行われなくなった）
Claude Codeのスキルは、Markdownファイルの中に!`command`形式でシェルコマンドの実行、@ファイルパス形式でファイル内容の展開を書ける仕組みです。ローカルで自分が書いたスキルなら便利な機能ですが、claude.ai経由で同期されてくるスキルにも同じ実行能力があると、「Web側で注入されたスキルがローカルマシンでコマンドを実行する」という攻撃経路になり得ます。
今回の変更は、この経路を3段階で塞ぎました。
- 名前の乗っ取り防止：同期スキルが既存のローカルコマンドやMCPプロンプトと同名でも、ローカル側が優先される（shadowing禁止）
- 説明文のサニタイズ：スキル一覧に表示される説明文が無害化され、同期由来であることがラベル表示される
- 実行能力の剥奪：同期スキルの本文では
!コマンドも@展開も動かない
組織でClaude Codeを展開している場合、「メンバーがclaude.ai側で追加したスキルが、会社の開発マシンで何を実行できるか」という監査観点の答えが「シェル実行はできない」に変わったことになります。セッションの操作ログを組織側で追う仕組みはClaude Code監査ログAPI対応の解説記事で扱っています。
変更点3：サンドボックスのネットワーク指定がfail-closed化
v2.1.229のサンドボックス改善はこう記載されています。
Improved sandbox: IPv6 literals in network domain lists are now bracketed ([::1]:443), and ambiguous spellings are enforced fail-closed and flagged by /doctor.
（サンドボックス改善：ネットワークドメインリストのIPv6リテラルはブラケット表記（[::1]:443）になり、曖昧な表記はfail-closedで強制され、/doctorが検出するようになった）
問題になっていたのは、IPv6アドレスをポート付きで書いたときの曖昧さです。たとえば::1:443という表記は「::1の443番ポート」とも「::1:443というアドレス全体」とも読めます。許可リストの解釈が曖昧なまま「広い方」に倒れると、意図しない宛先への通信を許可してしまう。今回の変更で、ブラケットなしの曖昧な表記はfail-closed（許可しない側に倒す）で扱われ、/doctorコマンドを実行すると設定ミスとして警告されるようになりました。
「機能が動かなくなる方向の変更」を安全のためにあえて入れるのは、設定ファイルを配布している組織には地味に効きます。サンドボックス機能の全体像と設定方法はClaude Codeサンドボックスで安全に自動実行する解説記事にまとめているので、ネットワーク許可リストを書いている方はIPv6表記の見直しとあわせて確認してください。
変更点4：Auto Mode関連の修正と「コスト注記」の削除
Auto Mode本体にも2つの変更が入りました。1つ目はv2.1.229のバグ修正です。
Fixed auto mode failing on every tool call for users who disable the attribution header via CLAUDE_CODE_ATTRIBUTION_HEADER (direct Anthropic API connections).
（環境変数CLAUDE_CODE_ATTRIBUTION_HEADERでアトリビューションヘッダーを無効化しているユーザー（Anthropic API直接続）で、Auto Modeが全ツールコールで失敗する問題を修正）
API直で接続しつつヘッダーをカスタマイズしている環境では、Auto Modeの分類器リクエストが全滅する状態だったわけで、8月14日の標準化前に潰しておくべき不具合でした。
2つ目はv2.1.228の小さな削除です。Pro・Max・TeamプランでAuto Modeを初めて使うときの通知から、「Auto Modeセッションはやや高コストになる」という注記が「古くなった記述」として削除されました。Auto Modeは各ツールコールを別の分類器モデル（デフォルトはClaude Sonnet 5）が審査する仕組みで、当初はその分のトークンが上乗せされていましたが、9to5Macの報道によればAnthropicは分類器が消費する追加トークンの課金を停止しています。権限モードの公式ドキュメントでも、分類器の呼び出しがトークン使用量にカウントされるのはEnterpriseプランおよびAPI・クラウドプロバイダー経由のアカウントに限定されると明記されており、Pro・Max・Teamのサブスクリプション利用では分類器コストを気にする必要がなくなったことになります。
変更点5：Writeツールの緩和と/loginの警告強化
安全「強化」一色ではなく、緩和方向の変更も1つ入っています。v2.1.228のWriteツールの変更です。
Changed the Write tool so newer models can overwrite an existing file they haven’t read this session, matching the Edit tool’s rules; older models still require the read first.
（Writeツールを変更し、新しいモデルはそのセッションで読んでいない既存ファイルも上書きできるようにした（Editツールのルールに合わせた変更）。古いモデルは従来通り事前の読み取りが必要）
従来は「一度Readしていないファイルは上書きできない」という一律ガードがありましたが、新しいモデルではこの制約が外れました。ファイル操作の自由度が上がる一方で、「読まずに上書きする」事故の防止をモデルの判断力に委ねる方向の変更です。重要な設定ファイルを扱うリポジトリでは、permissions.denyルールや保護パス（protected paths）側でガードする設計に寄せるのが安全です。
もう1つ、v2.1.229では/loginコマンドが、ログイン成功後にも環境変数CLAUDE_CODE_OAUTH_TOKENによる上書きが効いている旨の警告を繰り返し表示するようになりました。「ログインし直したのに別アカウントのトークンが効き続けていた」という取り違えを防ぐ変更で、CI環境と手元環境を行き来する人には地味にありがたい修正です。
なぜ今なのか：8月14日のAuto Mode標準化とセットで読む
ここまでの5変更を貫く文脈が、8月14日のAuto Mode標準化です。TechCrunchと9to5Macの報道によると、2026年8月14日以降、Pro・Max・Teamプランの新規セッションは、ユーザーまたは管理者が別のモードを固定していない限りAuto Modeで開始されます。
Anthropicが公開した根拠データが興味深いところです。TechCrunchによれば、ユーザーはClaude Codeの権限プロンプトの97%を承認しており、実質的にレビューとして機能していない。さらに1,053名の有料テスターによる調査では、偽装された有害アクションを人間のレビューが検出できたのは13.6%だったのに対し、Auto Modeの分類器は89%を検出したとされています。「人間の毎回承認」より「分類器の常時審査」の方が安全側に働く、というのがAnthropicの主張です。
権限モードの公式ドキュメントを読むと、Auto Modeは単なる「全部許可」ではないことがわかります。
- デフォルトでブロックされる操作：
curl | bashのようなダウンロード実行、本番デプロイやマイグレーション、force push、シークレットを外部に送る変更のコミット・プッシュ、IAM権限の付与など - 広すぎる許可ルールの無効化：Auto Modeに入ると
Bash(*)やBash(python*)のような包括的なallowルールは一時的に落とされ、Bash(npm test)のような狭いルールだけが引き継がれる - 会話中の境界の尊重：「プッシュしないで」「レビューまでデプロイ待って」と伝えた境界は、デフォルトで許可される操作でもブロック信号として扱われる
- フォールバック：分類器が3回連続または累計20回ブロックすると、Auto Modeは一時停止して従来の承認プロンプトに戻る
この前提を踏まえると、今回の5変更は「分類器に判断を委ねる範囲が広がる直前に、分類器の外側にある自動承認経路（ワークフローコマンド・同期スキル・サンドボックス設定）の線引きを揃えた」と整理できます。なお、監査ログの取得やDLP的な制御を組織側で行いたい場合は、推論フックの実装ガイドも参照してください。
開発チームが今週やるべき3つのアクション
ニュースの整理だけで終わらせず、具体的な確認手順に落とします。
アクション1：バージョンと権限モードの現状確認
# 現在のバージョン確認（v2.1.229以上か）
claude --version
# 設定・環境の健全性チェック（サンドボックス表記の警告もここに出る）
/doctor
Claude Codeは自動更新が基本ですが、固定バージョンで運用しているチームはv2.1.229未満だと今回の安全側変更が効いていません。/doctorはサンドボックスのネットワーク指定の曖昧表記を検出してくれるので、設定ファイルを配布している場合は必ず一度回してください。
アクション2：Auto Modeの扱いをチームで決める
# Auto Modeの分類器がブロック/許可するルール一覧をJSONで出力
claude auto-mode defaults
8月14日以降にデフォルトで有効になるのを受け入れるのか、~/.claude/settings.jsonのpermissions.defaultModeで"manual"や"acceptEdits"を固定するのか、組織としてはmanaged settingsのpermissions.disableAutoModeを"disable"にして無効化するのか。選択肢は用意されているので、「気づいたら変わっていた」ではなく決めた上で迎えるべきです。
アクション3：ブロックされた操作の確認フローを共有する
Auto Modeで操作がブロックされると通知が出て、/permissionsの「Recently denied」タブに記録されます。ここでrキーを押すと手動承認でリトライできます。この動線をチームに共有しておかないと、「Auto Modeにしたら作業が止まった」という問い合わせが増えるだけになります。ブロックが頻発する場合は、管理者がautoMode.environment設定で信頼するリポジトリ・サービスを登録するのが正攻法です。
賛否両論：この方向性をどう評価するか
肯定側の見方：97%承認という数字が示す通り、毎回の承認プロンプトは形骸化していました。形だけの人間レビューを、実際に検出率の高い分類器に置き換え、同時に自動承認の抜け道（危険フラグ・同期スキル・曖昧設定)を塞ぐのは、全体として安全性を上げる合理的な設計変更です。Claude Code責任者のBoris Cherny氏も「チームは何ヶ月も前からAuto Mode専用で使っている」と公言しています。
懐疑側の見方：13.6%対89%という比較はAnthropic自身の調査であり、第三者検証はこれからです。また分類器は会話とツールコールを見て判断する仕組みである以上、誤検出（過剰ブロック）と見逃しの両方が原理的に残ります。公式ドキュメント自身が「Auto Modeは安全を保証しない。センシティブな操作のレビューの代替として使うな」と警告している点は、導入判断の前提として重く見るべきです。Writeツールの緩和のように、モデルの判断力を信頼する方向の変更が同時に入っていることへの評価も分かれるでしょう。
私自身の見立てとしては、個人開発では受け入れて生産性を取り、組織導入では「deny/askルール＋信頼インフラの明示設定」を整備してから有効化する、という二段構えが現実的だと考えています。
FAQ
Q1. v2.1.229へはどうやって更新すればいいですか？
Claude Codeは起動時の自動更新が基本です。claude --versionで現在のバージョンを確認し、古い場合は再起動するか、インストール方法に応じて更新してください（npmインストールならnpm update -g @anthropic-ai/claude-codeなど）。組織でバージョンを固定配布している場合は、8月14日のAuto Mode標準化前にv2.1.229以上へ揃えることを推奨します。
Q2. Auto Modeを使いたくない場合はどうすればいいですか？
設定ファイル（~/.claude/settings.json）で"permissions": {"defaultMode": "manual"}のように別のモードを固定すれば、デフォルト化の影響を受けません。セッション中はShift+Tabでモードを切り替えられます。組織全体で無効化する場合は、managed settingsでpermissions.disableAutoModeを"disable"に設定すると、Shift+Tabのサイクルからも--permission-mode autoからも使えなくなります。
Q3. 8月14日のデフォルト化はEnterpriseやAPI利用にも適用されますか？
報道で確認できているのはPro・Max・Teamプランの新規セッションが対象という点です。Enterprise・API・Bedrock等のクラウドプロバイダー経由については、Auto Mode自体は選択可能なものの、デフォルト開始モードの変更時期は2026年8月14日時点のTier 1ソースでは確認できていません。組織のポリシーはmanaged settingsで明示的に固定しておくのが確実です。
Q4. 分類器の追加トークンは課金されますか？
Pro・Max・Teamプランでは課金されません（9to5Macの報道および、v2.1.228で初回通知からコスト増注記が削除されたことと整合）。一方、公式ドキュメントによると、EnterpriseプランとAPI・AWS・Bedrock・Google Cloud・Microsoft Foundry経由のアカウントでは分類器の呼び出しがトークン使用量にカウントされます。
まとめ：「承認する人間」から「線引きを設計する人間」へ
v2.1.228〜v2.1.231の安全側変更は、単体で見れば地味です。しかし8月14日のAuto Mode標準化と並べると、Claude Codeの権限モデルが「操作ごとに人間が承認する」から「事前に設計した線引きの中でAIが動き、分類器が監視する」へ本格的に移行する転換点だとわかります。開発者の仕事は毎回のYes/No入力から、deny/askルール・信頼インフラ・サンドボックス設定という「線引きの設計」に移ります。今週/doctorとclaude auto-mode defaultsを一度回して、自分のチームの線がどこに引かれているかを確認するところから始めてください。
今日からできる3アクション：
claude --versionでv2.1.229以上であることを確認し、/doctorでサンドボックス設定の警告を潰すclaude auto-mode defaultsの出力をチームで共有し、Auto Modeを受け入れるか固定モードにするかを決める/commit-push-prを使うワークフローがある場合、危険フラグ付き操作が承認プロンプトに変わることを周知する
次回は、プラグインマーケットプレイスに追加されたcommandソース（ローカルコマンドがプラグインディレクトリを動的に解決する新方式）など、v2.1.229の拡張系アップデートを整理する予定です。
Claude Codeの権限設計・組織導入を検討中の方へ
Uravationでは、Claude Codeの導入支援・個別指導を提供しています。Auto Mode時代の権限設計（deny/askルール・サンドボックス・監査ログ）からチーム展開まで、100社以上の支援実績に基づいて伴走します。「うちの環境でAuto Modeを許可していいのか」といった個別相談からお気軽にどうぞ。
出典
- Claude Code changelog（公式・v2.1.228〜v2.1.231）
- Choose a permission mode（Claude Code公式ドキュメント）
- Claude Code auto mode engineering deep dive（Anthropic公式）
- Anthropic is turning Claude Code’s auto mode on by default（TechCrunch・2026年8月9日）
- PSA: Claude Code enabling auto mode as default next week（9to5Mac・2026年8月7日）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載執筆。
