Claude Codeで秘密を見せずに使う

結論：sandbox内はmaskし、許可した通信時だけ必要値を使う

読者の具体的な困りごとは、buildやcloud確認にはtokenが必要なのに、環境変数やcredential fileをClaude、subprocess、tool outputへ露出させずに実行する方法を決められないことです。この記事を読むと、単純mask、pattern抽出、JWT、AWS SigV4を形式と通信から選べます。

次の行動：対象credentialを一つだけ選び、「保存形式」「利用command」「送信domain」「必要な権限」「有効時間」を一行ずつ書いてください。対象が複数のまま設定を始めると、どのmaskが効いたか検証できません。

credential maskingの提供条件と責任境界

2026年8月7日公開のClaude Code v2.1.224では、sandbox credential maskingへextract、onExtractNoMatch、JWTを扱うdecode: "jwt"とmaskClaims、AWS向けのawsPairsとsigv4が追加されました。構造化された環境変数や署名付きrequestを、単純な全文置換だけでなく形式に応じて扱う更新です。

この機能はsandboxのnetwork TLS terminationを前提にし、user settings、managed settings、または明示した--settings由来の設定だけが尊重されます。repositoryが配布するproject settingsだけで秘密値の復元規則を勝手に増やせないよう、信頼境界が絞られています。導入担当者は「どのscopeが値を管理するか」を先に決めます。

credential maskingはsecret managerではなく、実行時の露出面を減らす制御です。tokenの発行、rotation、失効、権限、保持は既存のIAMやvaultで管理します。またsandboxを外れて実行するcommand、別processが直接読むfile、許可外network、application自身のdebug logまで自動的に安全にするものではありません。

Claude CodeのsandboxはmacOS、Linux、WSL2で利用でき、Native Windowsは対象外です。LinuxとWSL2ではbubblewrapとsocatが必要で、環境によってoptionalなseccomp filterを加えます。依存がない時にunsandboxedへ落ちる既定挙動を許容できない組織は、failIfUnavailableとstrict sandboxを検討します。

単純mask・extract・JWT・AWS SigV4を6軸で比較する

1. 値の構造：一つのopaque tokenなら単純mask、JSONや複合文字列から一部を扱うならextractを候補にします。
2. 一致しない時：pattern不一致で生値へfallbackさせず、onExtractNoMatchを停止側へ設計します。未知形式を通しません。
3. JWT：header・payloadのclaimを把握する必要がある場合はJWT-aware decodeを使い、maskClaimsで見せるclaimを限定します。signatureやtoken全体を表示しません。
4. AWS：access keyとsecret keyのpairを扱う場合はawsPairsで対応を固定し、proxy側のsigv4再署名が必要なrequestだけに限定します。
5. 通信先：TLS terminationを有効にするdomainを最小化し、wildcardを避けます。credentialとdomainの対応を一対一に近づけます。
6. 失敗時：mask、抽出、署名、proxyのどこかが失敗したら、未maskの値で継続せずrequestを止める設計を選びます。

JWTのpayloadは暗号化ではなくencodingである場合が一般的で、decodeできることと公開してよいことは別です。tenant、email、roleなどのclaimも機密になり得ます。必要なclaimがないならすべてmaskし、debugのために一時的に見せる運用を本番へ残しません。

小さく導入する8手順

1. Claude Codeをv2.1.224以降へ揃え、claude --version、OS、起動surface、sandbox dependencyを台帳へ記録します。
2. /sandboxでMode、Overrides、Configを確認し、filesystemとnetwork isolationが実際に有効かを確認します。
3. 対象credentialを一つへ絞り、長期tokenではなくread-only・短命・対象resource限定の検証用credentialを発行します。
4. 保存形式を確認し、opaque、pattern抽出、JWT、AWS pairのどれで扱うか決めます。推測で正規表現を作りません。
5. user、managed、--settingsのどこから設定を配るか決め、repository側のproject settingsへ秘密値や復元規則を置きません。
6. 許可domainとmethodを一つへ絞り、TLS termination、mask、復元・再署名の順序を構成します。redirect先も同じ信頼条件か確認します。
7. 正常requestに加え、pattern不一致、期限切れ、別domain、別method、unsandboxed retry、stdout出力を試し、生値が表示・送信されないことを確認します。
8. log、rotation、失効手順、owner、停止条件を記録し、最初は一部署・一workflowだけで監視してから範囲を広げます。

negative testではcredential文字列をそのまま検索結果へ残さないよう、検証専用のdummy値を使います。dummy値をfile、environment、command line、HTTP headerへ置き、Claudeのtranscript、terminal output、process list、proxy log、接続先logに生値がないことを確認します。本番tokenで漏えいtestをしません。

公開・展開前のチェックリスト

• v2.1.224以降へ揃えた
• sandbox対応OSである
• Linux・WSL2のdependencyを確認した
• failIfUnavailableの方針を決めた
• allowUnsandboxedCommandsを判断した
• 対象credentialを一つへ絞った
• 短命・最小権限の検証用tokenを使った
• 形式とextract ruleを実値から確認した
• onExtractNoMatchを停止側にした
• JWT claimの必要性を確認した
• AWS pairと対象roleを固定した
• 許可domainを限定した
• dummy値で四経路をnegative testした
• 失効とrollbackを確認した

最も危険なのは「mask表示だったから安全」と画面だけで判断することです。maskingが効く経路、sandboxを外れる経路、proxyが復元する条件を図にし、観測点ごとにdummy値を確認します。shell historyやCI logなどClaude Code外の記録も同じtestへ含めます。

費用面ではcredential masking自体の個別料金ではなく、利用するClaude Code契約、model利用、cloud service、gatewayや運用基盤の費用を確認します。feature名から追加料金を推測せず、Team・Enterpriseの契約条件と自社基盤の通信・監視費を分けて見積もります。

よくある質問と次の行動

sandboxの対応OS、依存、network・filesystem境界はAnthropic公式Sandboxing guide、credential maskingの追加項目とversionはClaude Code公式Changelog、設定scopeとmanaged deliveryは公式Settings guideで公開直前にも確認してください。

操作許可はClaude Codeの権限設定、秘密情報の分類は入力禁止情報の決め方、組織展開は企業導入checklistへつなげます。Miraigentの無料診断では、credential、sandbox、domain、復元条件、negative testを一枚の秘密情報flowへ整理します。