結論：Claude Codeは2026年8月に入り、v2.1.224（8月7日）のsandbox認証情報マスキング、v2.1.233〜234（8月14日・17日）のWindows NT名前空間パス拒否によるNTLM漏洩対策、v2.1.236（8月19日）のワイルドカード読み取り拒否強化と、資格情報まわりのセキュリティ機能を立て続けに追加しました。Windows／Active Directory環境の端末が中心になる自治体・公共機関の情報システム部門にとっては、「ネイティブWindowsではBash sandbox自体が非対応」という制約と正面から向き合いながら設定を組む必要があります。
- 要点1：Windows NT名前空間パス（
\??\）を使ったNTLM認証情報の漏洩経路は、v2.1.233〜234でリモートファイル読み込み・セッション復元・CLAUDE.md include・ワークフロースクリプト・ファイルアップロードの各機能から遮断された。これはネイティブWindows版のClaude Codeでもそのまま効く保護。 - 要点2：一方でBash sandbox自体（
credentials.files・credentials.envVarsによるマスキングを含む）は、公式ドキュメント上「ネイティブWindows非対応」と明記されている。Windows端末で使うにはWSL2、またはコンテナ内でClaude Codeを動かす構成が必要になる。 - 要点3：
mask・awsPairs・sigv4・network.tlsTerminateは、user設定・managed設定・--settingsフラグからしか有効にならない。プロジェクトの.claude/settings.jsonに書いても無視されるため、組織で一律適用するなら最初からmanaged settingsで配布する設計にしておく。
対象読者：Windows／Active Directory環境の端末を配布している自治体・公共機関の情報システム部門、および受託でその環境向けにClaude Code導入を支援するエンジニア・PM。この記事は公式ドキュメントと公式changelogを一次情報源に、機能の整理・設定手順・段階導入ロードマップ・つまずきやすい失敗パターンまでを解説します。
今日やること：手元のclaude --versionで2.1.224以上になっているか確認し、配布端末がネイティブWindowsかWSL2かを棚卸しする。
とある県庁の情報システム課で、外部委託のシステム開発を担当しているPMから、少し前にこんな相談を受けたことがあります。「Claude Codeを現場のエンジニアが使いたいと言っているが、うちの端末は全部Windowsで、Active Directoryドメインに参加している。資格情報が漏れたら洒落にならない。しかも公式ドキュメントを読むと、Bash sandboxはネイティブWindowsでは動かないと書いてある。どう考えればいいのか」というものです。
自治体・公共機関のIT環境は、SaaSスタートアップとは前提が大きく異なります。職員・委託先エンジニアの端末はほぼ例外なくWindowsで、ActiveDirectoryによる一元管理下にあります。監査証跡・情報セキュリティポリシーの遵守が前提になっており、「開発者が個人設定で自由にセキュリティ挙動を変えられる」構成は原則として避けたい。加えて、住民向けクラウドポータルの認証にJWTを使い、文書保管にAWS S3を使う、といった構成も珍しくなくなっています。つまりAIエージェントに実装作業を任せる場合、Windows資格情報の漏洩対策とクラウド側の認証情報保護、その両方を組織として統制する必要が出てきます。
自治体・公共機関でのClaude Code活用自体は、住民問い合わせ対応や例規改正の差分チェックなど、業務システムの領域ではすでに複数の実装パターンが積み上がっています（自治体Claude Code実装5事例｜住民対応から議会まで、自治体の条例改正差分チェックをClaude Codeで効率化）。本記事はそれらの前提となる、開発環境そのもののセキュリティ設定に焦点を当てます。
2026年8月に入ってからのClaude Codeのアップデートを一次ソース（公式changelog）で追っていくと、この課題に直接効く変更が短期間に集中して入っています。8月7日のv2.1.224でsandboxの資格情報マスキング機能が拡張され、8月14日〜17日のv2.1.233〜234でWindowsのNTLM漏洩経路が段階的に塞がれ、8月19日のv2.1.236でワイルドカード読み取り拒否の優先順位が強化されました。本記事では、これらの公式ドキュメント・changelogの内容を整理したうえで、Windows／AD環境が中心の自治体・公共機関の情報システム部門を想定した実装パターンとして組み立てます。
本記事の位置づけ：本記事は公式ドキュメント・公式changelogの内容整理と、それに基づく一般化された実装パターン解説（想定シナリオ）です。固有の自治体名・実在の導入事例・実測の削減率は含みません。バージョン番号・機能の挙動・設定キー名はすべて公式ドキュメント／changelog記載の仕様であり、シナリオ部分（登場する部署構成や課題感）は「想定シナリオ」であることを明記します。実際の情報セキュリティポリシー・監査要件を満たすかどうかは、貴団体の情報セキュリティ担当・監査部門と個別に確認してください。
2026年8月のセキュリティアップデートを時系列で整理する
まず、今回扱う変更が実際にどのバージョン・どの日付で入ったのかを一次ソース（公式changelog）に基づいて整理します。バージョン番号は「バグ修正込みの高頻度リリース」であり、機能ごとに数日ずれて段階的に入っている点に注意してください。
| バージョン | 公開日 | 変更内容（公式changelog原文の要約） |
|---|---|---|
| v2.1.224 | 2026年8月7日 | sandboxの資格情報マスキングにextract・onExtractNoMatch・decode:"jwt"＋maskClaims・awsPairs／sigv4を追加。構造を持つ値（DB接続文字列・JWT・AWS SigV4署名）を個別にマスクできるように |
| v2.1.233 | 2026年8月14日 | Windows NT名前空間パス（\??\）を利用したNTLM認証情報漏洩の経路を一部遮断。GitLab MR対応、Linux向けメモリcgroup上限（CLAUDE_CODE_TOOL_MEMORY_LIMIT）も同時に追加 |
| v2.1.234 | 2026年8月17日 | NT名前空間パス拒否を、リモートファイル読み込み・セッション復元・CLAUDE.md include・ワークフロースクリプト・ファイルアップロードの全経路に拡張。「事前承認前のファイルアクセスに残っていたNTLM漏洩経路を強化」と公式changelogに明記 |
| v2.1.236 | 2026年8月19日 | macOSで、ワイルドカード読み取り拒否ルール（例：**/.env）が許可領域内でも優先され、対象ディレクトリの中身も対象になり、ファイル名変更による回避もできなくなった |
本記事で中心的に扱うのは、v2.1.224のsandbox資格情報マスキングと、v2.1.233〜234のWindows NTLM漏洩対策の2つです。Bash sandboxの基本的な使い方そのものは、別記事のClaude Codeサンドボックスで安全に自動実行で扱っているので、まだsandboxを有効化していない方はあわせて参照してください。また、環境変数・シークレット管理の基本原則はClaude Codeのシークレット管理｜秘密情報を守る7原則で解説しているため、本記事ではsandbox固有の資格情報マスキングに絞って深掘りします。
なぜWindows／AD環境の自治体情シス課で重要なのか
ここからは、想定シナリオとして、住民向けクラウドポータル（JWT認証）と文書保管用のAWS S3を使い、開発端末は原則としてActive Directoryドメイン参加のWindows PC、という構成を持つ自治体の情報システム課を例に考えます。この構成には、macOS・Linuxを自由に選べるスタートアップとは異なる、2つの制約があります。
- 制約1：端末がActive Directoryドメインに参加したWindowsで統一されている — 資格情報の管理はNTLM／Kerberosを含むWindows標準の認証基盤に乗っており、開発者が個人の判断でOSを変える余地がない。ファイルパスの扱い一つで認証ハッシュが漏れる経路（NT名前空間パス）があること自体、多くの現場担当者には知られていない。
- 制約2：Bash sandboxがネイティブWindowsで動かない — 公式ドキュメントに「sandboxはmacOS・Linux・WSL2で動作し、ネイティブWindowsは非対応。Windowsホストではこの設定をmacOS・Linuxに絞るか、対象ユーザーにWSL2かコンテナ内でClaude Codeを動かしてもらうこと」と明記されている。つまり資格情報マスキングを含むsandbox機能一式を使うには、WSL2化がほぼ前提になる。
この2つの制約は、単体では目新しいものではありません。しかし「AIエージェントにコード実装の一部を任せたい」という話になった瞬間、両方が一気に効いてきます。AIエージェントはファイル読み込み・環境変数参照を人間より高頻度に行うため、意図せず資格情報に触れる経路が広がりやすいからです。2026年8月の一連の変更は、この2つの制約それぞれに直接対応する機能が同じ月に立て続けに入った、という巡り合わせになっています。
NTLM認証情報漏洩を防ぐ — NT名前空間パス拒否の仕組み
Windowsには、通常のドライブレターパス（C:\Users\...）とは別に、\??\で始まる「NT名前空間パス」という低レベルの表記法があります。細工したこの形式のパスを使うと、アプリケーションによってはUNCパス（ネットワーク共有パス）のバリデーションをすり抜け、意図しないネットワークホストへの認証リクエストを発生させてしまうことがあります。これがトリガーになると、Windowsは自動的にNTLM認証ハッシュを相手ホストへ送ってしまう場合があり、悪意あるホストがこれを中継・解析することでパスワードハッシュを窃取できてしまう、という経路（NTLM credential-leak vector）です。
公式changelogでは、v2.1.234の変更点として次のように記載されています。
“remote file reads, session restore, CLAUDE.md includes, workflow scripts and file uploads now reject Windows NT-namespace (
\??\) paths, hardening the remaining pre-approval file accesses against the NTLM credential-leak vector”（リモートファイル読み込み・セッション復元・CLAUDE.md include・ワークフロースクリプト・ファイルアップロードが、Windows NT名前空間パスを拒否するようになった。事前承認前に残っていたファイルアクセス経路を、NTLM認証情報漏洩の経路に対して強化するもの）
ここで重要なのは、この保護がv2.1.233での初期対応をv2.1.234でさらに広い経路へ拡張する形で段階的に強化されている点、そしてBash sandboxの有無に関係なく、ネイティブWindows版のClaude Codeでもそのまま効く保護だという点です。次に説明するsandbox資格情報マスキングがWSL2前提になるのに対して、この保護は追加設定なしで自治体の一般的なWindows端末に恩恵があります。情シス課が最初に確認すべきは、まず全端末のclaude --versionがこの保護を含むバージョン（v2.1.234以降）になっているかどうかです。
ある自治体案件の相談で「そもそもClaude CodeがWindowsのファイルシステム挙動にどこまで詳しいのか不安」という声を聞いたことがありますが、この種の低レベルなパス処理の脆弱性対応は、公式側が継続的にリリースで塞いでいる領域です。逆に言えば、古いバージョンのまま運用を続けること自体がリスクになります。
Sandbox資格情報マスキングを設定する — extract／decode:jwt／awsPairs
住民向けポータルの認証にJWT、文書保管にAWS S3を使う構成では、Claude Codeのsandbox内で動くBashコマンドがこれらの認証情報に触れる場面が出てきます。sandbox.credentials設定は、ファイルパスまたは環境変数ごとにmode: "deny"（完全遮断）またはmode: "mask"（プレースホルダーに置換しつつ、許可ホストへの通信時だけ実値に戻す）を指定できます。公式ドキュメントに掲載されている設定例は次の通りです。
まず、GitHubトークンのように構造化されたファイル（YAML）の中の特定の値だけをマスクする例です。extractで正規表現のキャプチャグループ1に一致した部分だけを置換し、それ以外の設定内容は読める状態を保ちます。
{
"sandbox": {
"enabled": true,
"network": {
"tlsTerminate": {},
"allowedDomains": ["*.github.com"]
},
"credentials": {
"files": [
{
"path": "~/.config/gh/hosts.yml",
"mode": "mask",
"extract": "oauth_token:\\s*(\\S+)",
"injectHosts": ["api.github.com"]
}
]
}
}
}JWT形式の値にはextractの代わりにdecode: "jwt"を指定します。Claude Codeが値をJWTとして検証し、構造的に正しい偽トークンへ置き換えるため、sandbox内でトークンをデコードするコード自体は動き続けます。maskClaimsを追加すれば、ペイロード内の特定クレームだけをマスクし、それ以外のクレームは読める状態を保つことも可能です。
AWS認証情報の場合は少し注意が必要です。AWSリクエストはSigV4署名を持つため、シークレットキーだけをマスクすると署名が壊れてサーバー側で拒否されます。アクセスキーIDとシークレットキーは必ずペアでマスクし、変数名が標準的でない場合はawsPairsで明示的に紐付けます。
{
"sandbox": {
"credentials": {
"awsPairs": [
{
"accessKeyIdVar": "MY_KEY_ID",
"secretAccessKeyVar": "MY_SECRET_KEY",
"sessionTokenVar": "MY_SESSION_TOKEN"
}
]
}
}
}プリサインドURLやaws-chunkedストリーミングアップロードのように、プロキシ側で再署名できないリクエスト形式もあります。これらはcredentials.sigv4で該当フォームのキーを"passthrough"に設定すると、プレースホルダー由来の署名のままリクエストを転送し、AWS側の本来のエラーレスポンスをツールに返せます（プロキシ内部でのエラーではなく）。
ここで最も見落としやすいのが、mask・awsPairs・sigv4・network.tlsTerminateは、user設定・managed設定・--settingsフラグからしか有効にならないという制約です。リポジトリの.claude/settings.jsonや.claude/settings.local.jsonに書いても無視されます。個々の開発者に「自分でmask設定を書いてください」と依頼する運用は成立せず、組織として配布するmanaged settingsに最初から含めておく必要があります。
自治体特有の壁 — Bash sandboxはネイティブWindows非対応
ここが、Windows／AD環境が中心の自治体・公共機関がまず突き当たる壁です。公式ドキュメントには次のように明記されています。
“The sandbox does not run on native Windows, so if your fleet includes Windows hosts, scope this configuration to macOS and Linux or have those users run Claude Code inside WSL2 or a container.”（sandboxはネイティブWindowsでは動作しない。配布端末群にWindowsホストが含まれる場合は、この設定をmacOS・Linux向けに絞るか、該当ユーザーにはWSL2またはコンテナ内でClaude Codeを動かしてもらうこと）
つまり、前段で紹介した資格情報マスキング（credentials.files／credentials.envVars／awsPairs）は、Windows端末単体では動きません。sandboxが提供するOSレベルのファイルシステム分離・ネットワーク分離の恩恵を受けるには、対象の端末でWSL2を有効化し、その中でClaude Codeを起動する構成に切り替える必要があります。全庁的にネイティブWindowsのまま運用したい場合、sandbox関連の保護は事実上使えないという前提で、前段のNT名前空間パス拒否（ネイティブWindowsでも効く）を主軸に据える設計になります。
| 保護機能 | ネイティブWindows | WSL2 / Linux / macOS |
|---|---|---|
| NT名前空間パス拒否（NTLM漏洩対策） | ○ そのまま有効 | ○ そのまま有効 |
| Bash sandbox本体（ファイルシステム／ネットワーク分離） | × 非対応 | ○ 有効（WSL2はbubblewrapを使用） |
資格情報マスキング（credentials.files／envVars） |
× sandbox非対応のため実質使えない | ○ 有効（macOSはファイル遮断のみ、Linux/WSL2はセンチネル置換） |
この事実は、委託先エンジニアがMacBookでローカル開発し、成果物をWindows/AD環境の本番運用チームへ引き渡す、という自治体案件でよくある体制にとって重要な意味を持ちます。開発側のMacでは資格情報マスキングが有効に働いていても、運用側のWindows端末で同じ設定を期待すると空振りに終わります。情シス課としては「どの端末群にどの保護が実際に効いているか」をプラットフォーム別に棚卸しし、Windows端末についてはWSL2化のロードマップを別途持つ必要があります。
managed settingsで組織全体に強制する
個々の職員・委託先エンジニアの善意に頼らず、情シス課側で一律のポリシーを配布したい場合は、MDM経由のmanaged settingsファイル、またはclaude.aiのserver-managed settingsを使います。公式ドキュメントに掲載されている、sandboxを全開発者に強制する最小構成は次の通りです。
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false
}
}failIfUnavailableはbubblewrap等の依存パッケージが欠けている場合にClaude Code自体の起動を止め（警告表示だけで素通りさせない）、allowUnsandboxedCommands: falseは「sandbox内で失敗したコマンドをsandbox外で再試行する」というエスケープハッチ自体を無効化します。この2つを組み合わせることで、「sandboxが使えない環境ではそもそも動かない」という強い制約を作れます。
さらに、開発者側の設定でポリシーを緩められないようにするにはallowManagedReadPathsOnly・allowManagedDomainsOnlyを使います。前者はmanaged settings以外のallowReadエントリをすべて無視し、後者はネットワーク許可ドメインをmanaged settingsの値のみに固定します。配列型の設定（excludedCommandsやallowRead）はスコープ間でマージされる仕様のため、これらのロックを設定しないと、開発者がプロジェクト側の設定でポリシーを広げられてしまう点に注意してください。
managed settingsのファイル配置場所はOSごとに異なります。macOSは/Library/Application Support/ClaudeCode/、Linux／WSL2は/etc/claude-code/、WindowsはC:\Program Files\ClaudeCode\です。自治体のMDM（Microsoft Intune等）で配布する場合は、Windows向けにはこのパスへの配置タスクを組み込み、WSL2側は別途Linux向けパスへの配置が必要になる点を見落とさないようにしてください。ユーザー設定（~/.claude/settings.json、Windowsは%USERPROFILE%\.claude\settings.json）はあくまで個人の補助設定であり、監査要件の担保にはmanaged settings側での強制が前提になります。
ガバナンス設計の全体像（gatewayの支出上限・利用者属性の転送等、他の統制軸との組み合わせ方）はClaude Code支出上限｜gatewayで開発者別に設定やClaude Codeの組織ガバナンス｜managed settingsでモデル・スキルを統制で個別に扱っているため、あわせて参照してください。
段階導入ロードマップ（想定モデル）
ある自治体案件の相談を受ける際によく提示している、Windows／AD環境での段階導入の考え方を整理します。あくまで一般化されたモデルであり、貴団体の情報セキュリティポリシーに沿って読み替えてください。
- フェーズ1（現状把握）：配布端末のClaude Codeバージョンを棚卸しし、v2.1.234未満の端末をリストアップする。あわせて、どの部署がWSL2を有効化できる端末構成かを確認する。
- フェーズ2（ネイティブWindows向けの最低限対策）：全端末をv2.1.234以上へ更新し、NT名前空間パス拒否を有効にする。この時点ではsandboxは未導入でも、NTLM漏洩対策のベースラインは確保できる。
- フェーズ3（試験導入）：クラウドAPI（住民ポータル・S3等）に触れる少数のエンジニア端末をWSL2化し、
sandbox.credentialsによるマスキング設定を試験運用する。/doctorコマンドでinjectHostsの設定ミスがないか確認する。 - フェーズ4（managed settingsによる全庁展開）：試験運用で固まった設定をmanaged settingsに落とし込み、
allowManagedReadPathsOnly・allowManagedDomainsOnlyで開発者側の緩和を防いだうえで、MDM経由で全庁配布する。
【要注意】よくある失敗パターンと回避策
- ❌ macOS向けの設定例をそのままWindows端末の設定として配布してしまう
⭕ sandbox本体はWSL2前提と明記したうえで、ネイティブWindows端末にはNT名前空間パス拒否（バージョン更新のみで有効）を主軸にした別のロードマップを用意する - ❌ AWS認証情報のシークレットキーだけを
maskし、アクセスキーIDは平文のまま残す
⭕ SigV4署名はアクセスキーIDとシークレットキーの両方から導出されるため、両方をmaskし、標準的でない変数名の場合はawsPairsで明示的にペアを指定する - ❌ プロジェクトの
.claude/settings.jsonにmask設定を書いて「これで全開発者に適用された」と思い込む
⭕mask・awsPairs・sigv4・network.tlsTerminateはuser設定・managed設定・--settingsフラグからしか有効にならない。組織一律で適用するならmanaged settingsに書く - ❌
network.tlsTerminateを設定せずにmaskだけ設定し、「マスキングされているから安全」と誤認する
⭕tlsTerminateがないとプロキシがリクエスト内容を書き換えられず、マスキングは失敗する（コマンド側はセンチネル値しか見えないが、そのまま相手サーバーへ送られて認証エラーになる）。Claude Codeは起動時にこの設定ミスを警告するため、/doctorの出力を必ず確認する
よくある質問
Q1. WSL2化しなくても、Windows端末でできるセキュリティ対策はありますか？
あります。NT名前空間パス拒否（v2.1.234以降）はネイティブWindowsでもそのまま有効なので、まず全端末をこのバージョン以上へ更新することが最低限の対策になります。Bash sandboxが提供するファイルシステム分離・資格情報マスキングはWSL2またはコンテナが前提ですが、パス拒否によるNTLM漏洩対策はバージョン更新のみで恩恵を受けられます。
Q2. sandboxの資格情報マスキングを設定すれば、住民情報を扱うシステムの監査要件を満たせますか？
本記事で扱った機能は、資格情報の可視性を減らす技術的な仕組みを提供するものであり、特定の監査基準・情報セキュリティ基準への適合を保証するものではありません。自団体に適用される監査要件・情報セキュリティポリシーを満たすかどうかは、貴団体の情報セキュリティ担当・監査部門に個別に確認してください。
Q3. WSL2とDockerコンテナ、どちらでsandboxを使うべきですか？
公式ドキュメントは「WSL2またはコンテナ内でClaude Codeを動かす」と両方を選択肢として挙げており、どちらが優れているかの明確な推奨は記載されていません。既存のWindows端末を活かしたいならWSL2、開発環境自体を標準化・使い捨て化したいならコンテナ、という選び方が一般的です。自団体の既存インフラ標準に合わせて選定してください。
Q4. managed settingsとuser settingsが競合した場合、どちらが優先されますか？
enabledやfailIfUnavailableのようなbool型のキーはmanaged settingsの値が優先され、開発者側のローカル設定は無視されます。一方excludedCommandsやallowReadのような配列型のキーは、既定では全スコープの値がマージされます。開発者側での拡張を防ぎたい場合は、前述のallowManagedReadPathsOnly・allowManagedDomainsOnlyを明示的に設定する必要があります。
Q5. AWS以外のクラウド（Azure・GCP）の認証情報にも同じマスキングは使えますか？
公式ドキュメントで具体的な再署名の仕組みが説明されているのはAWSのSigV4のみです。Azure・GCPの認証トークンについては、単純な値のmask（extractやdecode:"jwt"を含む）は同様に使える一方、AWSのawsPairs／sigv4に相当する署名の自動再計算機能は本記事執筆時点（2026年8月）の公式ドキュメントには記載がありません。導入前に該当クラウドの認証方式と組み合わせて検証してください。
まとめ：今日からできる3つのアクション
2026年8月のアップデートは、単体で見ると地味なセキュリティ強化の積み重ねです。しかし、Windows／AD環境の端末が中心になる自治体・公共機関の情報システム部門から見ると、「ネイティブWindowsでも効くNTLM対策」と「WSL2前提のsandbox資格情報マスキング」という2階建ての防御を、同じ月のリリースで一気に組める組み合わせになっています。
- 今日やること：
claude --versionで全端末がv2.1.234以上か確認し、未更新の端末を洗い出す - 今週中：クラウドAPIに触れる開発端末のうち、WSL2化が可能なものを選定し、
sandbox.credentialsの試験設定を組む - 今月中：試験運用で固まった設定をmanaged settingsに落とし込み、MDM経由での全庁配布計画を情報セキュリティ担当と作成する
次回は、住民問い合わせ対応やAI活用の別の切り口から、自治体・公共機関でのClaude Code実装パターンを整理する予定です。
自治体・公共機関でのClaude Code導入・セキュリティ設計を検討中の方へ
Uravationでは、Claude Codeの導入支援・個別指導を提供しています。Windows／AD環境での資格情報保護設計、WSL2移行を含む段階導入ロードマップ、managed settingsによる全庁統制の設計まで、100社以上の支援実績に基づいて伴走します。「うちの環境でどこまで設定すればいいか」といった個別相談からお気軽にどうぞ。
