はじめに
Claude Codeの2026年4月は、落ち着かない1ヶ月だった。v2.1.69からv2.1.101まで、約3週間で32のバージョンが出た。そのうち少なくとも2件は、既存の権限設定が想定通りに機能していなかったバグの修正だ。「ブロックしているはずのコマンドが、実は通っていた可能性がある」という類の話である。
2026年1月からTeamプランにClaude Codeが同梱され、組織導入が加速している。追加料金なしで使えるのは魅力だが、ファイル書き換え・シェルコマンド実行・外部HTTP通信が可能なツールを「各自の設定に任せている」状態のチームにとって、このリリース密度は見過ごせない。
本記事は既存記事（権限設計完全ガイド・プロンプトインジェクション対策・シークレット管理）の続きにあたる。組織管理者・EMの視点から、4月の変更で何を見直すべきかを書く。
まずバージョンを確認する
以下を実行してほしい。
claude --versionv2.1.101未満なら、今すぐアップデートを検討してほしい。
npm update -g @anthropic-ai/claude-codeなぜv2.1.101が重要なのか。4月に修正されたバグのうち、組織展開に直接影響するものを確認しておきたい。
PreToolUse hookがdenyルールを無視していたバグ（v2.1.78修正）
v2.1.78より前のバージョンでは、PreToolUse hookがallowを返すと、Managed Settingsで定義したdenyルールさえも無視される状態だった。hookを使ったカスタム権限管理を行っている組織では、意図したブロックが機能していなかった可能性がある。
v2.1.78以降は修正済みで、hookのallow判断とdenyルールは独立して評価される。denyルールは常に最優先になった。
バックスラッシュエスケープによるBash権限バイパス（v2.1.98修正）
バックスラッシュでエスケープされたフラグ（例：\-rf）を使うと、read-onlyとして自動承認された上で任意コードが実行できた。v2.1.98でコマンドのエスケープ処理が強化され、複合コマンドでの安全チェック迂回も同時修正されている。
これらは「古いバージョンを使い続けることがリスクになる」実例だ。
サンドボックスは何を守り、何を守らないか
/sandboxコマンドで有効化するOS級の隔離機能について、実際の動作を確認しておきたい。macOSではSeatbelt（TrustedBSD MAC）、LinuxではBubblewrapを使用する（公式ドキュメント）。
サンドボックスはBashコマンドとそのサブプロセスを隔離する。kubectl、terraform、npmのようなサブプロセスにも同じ制限が継承されるため、悪意あるスクリプトや意図しないコマンドがホストシステムに触れることを防ぐ。
ただし、設定なしでは思った通りに機能しない落とし穴が複数ある。
denyReadの設定漏れ
デフォルトでは読み取り範囲がファイルシステム全体に及ぶ。~/.awsや~/.sshをsandbox.denyReadで明示的にブロックしない限り、/etc/passwdやホームディレクトリ全体が読み取れる状態になる。
また、sandbox.denyReadはBashコマンドのサブプロセスには適用されるが、Claude自身のReadツールには効かない。同じパスに対してpermissions.deny Read(...)を別途設定する必要がある。この「2重設定」を知らずにdenyReadだけ設定して安心しているケースが多い。
escape hatchをデフォルトで塞ぐ
サンドボックス内でコマンドが失敗すると、ClaudeはdangerouslyDisableSandbox: trueで自動的に再試行しようとする。この動作は"allowUnsandboxedCommands": falseで無効化できる。社内展開では必ず塞いでおきたい。
Docker環境での弱体化
Docker内で実行する場合、enableWeakerNestedSandboxモードに切り替わり、ファイルシステム分離が大幅に弱くなる。CI/CDパイプラインでDockerを使う場合は別途対策が必要だ。
社内展開向けの設定例はこうなる。
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"allowUnsandboxedCommands": false,
"failIfUnavailable": true,
"filesystem": {
"allowWrite": ["/tmp/build"],
"denyRead": ["~/.aws", "~/.ssh", "~/.gnupg"],
"allowRead": ["."]
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"],
"allowLocalBinding": true
}
}
}failIfUnavailable: trueを設定すると、サンドボックスが使えない環境ではClaude Codeが起動しない。セキュリティゲートとして機能させたい場合に有効だ。
Credential Scrubbing と PID 分離（v2.1.83/v2.1.98）
環境変数経由での認証情報漏洩は、Claude Codeの利用シーンで見落とされやすいリスクだ。通常、プロセスの環境変数は子プロセスに継承される。ANTHROPIC_API_KEYやAWS_ACCESS_KEY_IDが設定された状態でBashコマンドを実行すると、その子プロセスがAPIキーを読み取れる状態になる。悪意あるnpmパッケージやMakefileコマンドがそれを取得できる。
これを防ぐのがCredential Scrubbingだ。CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1を環境変数に設定すると、サブプロセス起動前にAnthropicおよびクラウドプロバイダのAPIキー（AWS、GCP、Azure）を環境変数から除去する。
# .zshrc / .bashrc に追加
export CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1組織展開では、全メンバーの~/.zshrcに追加するか、社内の開発環境セットアップスクリプトに組み込んでほしい。
Linux環境ではv2.1.98からPIDネームスペース分離も有効化された。同じCLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1で有効になり、サブプロセスが/proc経由で他のプロセス情報を読み取れなくなる。
Hookで権限を縛る
Hookはシステムプロンプトが「お願い」なのに対し、「約束」として機能する。PreToolUse Hookはツール実行前に発火し、exit code 2でツール呼び出しをブロックできる（公式ドキュメント）。
v2.1.78以降は前述のバグが修正され、hookがallowを返してもdenyルールは上書きされない。denyルールは常に最優先で評価される。
危険コマンドをブロックするHook設定
settings.jsonにPreToolUse Hookを設定し、実際の判定ロジックをシェルスクリプトに分離するパターンが組織では扱いやすい。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": ".claude/hooks/security-check.sh",
"timeout": 5
}
]
}
]
}
}.claude/hooks/security-check.sh の例：
#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command')
# 危険なコマンドパターンをブロック
if echo "$CMD" | grep -qE '(rm -rf /|curl.*\|.*bash|wget.*\|.*sh)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "危険なコマンドパターンが検出されました"
}
}'
exit 0
fi
# 認証情報ファイルへのアクセスをブロック
if echo "$CMD" | grep -qE '(cat|head|tail).*(\.env|credentials|\.aws)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "認証情報ファイルへのアクセスはブロックされています"
}
}'
exit 0
fi
exit 0全ファイル編集操作を監査ログに記録したい場合はPostToolUse Hookを使う。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "/usr/local/bin/audit-edit.sh"
}
]
}
]
}
}Managed Settingsで組織全体を統制する
個人のsettings.jsonに頼った権限設定は、メンバーが自分で上書きできてしまうため組織統制として機能しない。これを解決するのがManaged Settings（公式ドキュメント）だ。
方式は組織規模と管理体制によって変わる。
MDMがない環境ならServer-Managed Settingsを使う。AnthropicサーバーからClaude Codeが設定を受け取る仕組みで、管理コンソールから全メンバーに一括配信できる。
MDM/エンドポイント管理がある環境ならEndpoint-Managed Settingsが適している。管理ファイルをデバイスに直接配置するため、セキュリティ保証が強くオフライン環境でも機能する。
どちらも「管理設定専用キー」を使うことで、ユーザーやプロジェクトの設定ファイルから上書きできない制約を設けられる。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(git add *)",
"Bash(git commit *)",
"Read",
"Edit",
"Write"
],
"deny": [
"Bash(curl *)",
"Bash(wget *)",
"Bash(rm -rf *)",
"Bash(git push --force *)",
"Bash(npm publish *)",
"Read(./.env)",
"Read(~/.aws/**)",
"Read(~/.ssh/**)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true,
"allowManagedHooksOnly": true,
"allowManagedMcpServersOnly": true
}allowManagedPermissionRulesOnly: trueを設定すると、ユーザーやプロジェクトレベルの権限ルールは無効化され、管理設定のみが有効になる。allowManagedHooksOnlyとallowManagedMcpServersOnlyも同様に、管理者が許可したHookとMCPサーバーのみを使用可能にする。
forceRemoteSettingsRefreshで設定を確実に受け取らせる
Server-Managed Settingsには注意点がある。デバイス管理者権限を持つユーザーはキャッシュファイルを改ざんできる（次回フェッチ時に復元されるが、一時的に設定が無効化できてしまう）。またANTHROPIC_BASE_URLを上書きするとServer-Managed Settingsが機能しなくなる（BedrockやVertexを使う場合も同様）。
forceRemoteSettingsRefresh: trueを設定すると、設定取得に失敗した場合にCLIが起動しなくなる（fail-closed）。高いセキュリティ要件の組織では有効にしておきたい。
/team-onboarding：v2.1.101の新コマンドと注意点
v2.1.101で追加された/team-onboardingコマンドは、過去30日間のセッション履歴・コマンド使用・MCPサーバー利用状況を分析し、新チームメンバー向けのセットアップガイドをMarkdown形式で生成する。熟練ユーザーの作業習慣を再利用可能なドキュメントに圧縮できる便利な機能だ。
ただし、生成物をそのまま共有するのは危険だ。共有前に必ず目を通してほしい点が3つある。
共有前のチェックリスト
ローカルマシン固有の設定が混入していないか
絶対パス（/Users/username/...）、個人用エイリアス、一時ディレクトリなどが含まれていると、他のメンバーの環境では機能しないどころか、混乱を招く。
個人の実験的MCPが組織推奨として昇格していないか
個人が試していたMCPサーバーがデフォルト設定として記載されていることがある。組織として許可されたMCPのみに絞り込む。
リスキーな権限が組織デフォルトに昇格していないか
個人が作業の便宜上allowしていた危険なコマンドが、組織の推奨設定として広まるリスクがある。生成されたガイドの権限設定は必ず管理者がレビューしてほしい。
/team-onboardingはあくまでドラフト生成ツールだ。永続的なルールはCLAUDE.md（アーキテクチャルール・禁止事項）、.claude/settings.json（権限設定）、.claude/skills/（再利用可能なワークフロー）に分けて管理する。
なお、v2.1.101からはOSのCA証明書ストアをデフォルトで信頼するようになった。Zscaler・Palo Altoなど企業TLSプロキシを使っている環境で発生していた証明書エラーが解消され、追加設定なしでClaude Codeが使えるようになっている。企業ネットワーク内での展開ハードルが一つ下がった。
まとめ
4月の32バージョンの中で最も組織への影響が大きかったのは、「設定したつもりが機能していなかった」という2件のバグ修正だ。PreToolUse hookのdenyバイパスとバックスラッシュエスケープBypassは、v2.1.78とv2.1.98でそれぞれ修正済みだが、これらは「旧バージョンを使い続けることがリスクになる」という現実を示している。
今日やることは一つだ。claude --versionを打って、v2.1.101未満なら更新してほしい。バージョンが揃えば、この記事で紹介した設定の話が始められる。
チームの誰かがcurl * | bashを実行しようとしたとき、あなたのClaude Codeはそれを止められますか。
コメント