認証情報マスキングは情報漏洩対策になるか(credential masking)

Claude Codeの認証情報マスキング(credential masking)は、サンドボックス化されたコマンドに認証情報の実値を見せず、許可済みの通信先へ出る瞬間だけ実値へ差し替える機能です。設定の書き方自体は認証情報マスキングの設定ガイドに譲り、この記事では日本企業がこの機能をなぜ導入するのかを、個人情報保護法が定める委託先の監督義務と、内部不正対策の観点から検証します。技術的な仕組みが、実務上どの脅威をどこまで塞ぐのかを具体的に見ていきます。

認証情報マスキング(credential masking)が遮断する情報の範囲

Claude Codeのサンドボックスは既定で読み取りにかなり寛容です。~/.aws/credentialsや~/.ssh/を含め、コンピューター全体がほぼそのまま読める状態が既定動作になっています。書き込みは作業ディレクトリに絞られますが、読み取りはそうではありません。

sandbox.credentialsのmode: "mask"は、この既定動作の上にもう1層を足します。サンドボックス内のコマンドが見るのは実際の値ではなく、セッションごとのセンチネル(偽の値)です。通信が許可済みホストへ出るときだけ、サンドボックスのプロキシが実値に差し替えます。コマンドの出力にもログにも、実際の認証情報は一度も現れません。

ここが重要な点です。denyのように読み取りごと拒否する設定は、ghやnpmのように認証情報で実際に通信するツールを壊します。maskはツールを動かしたまま、実値がエージェントのコンテキストに乗る経路だけを断ちます。Claude Codeのセキュリティ全体像(権限・サンドボックス・データ扱いの3層)は企業向けセキュリティガイドで整理しています。

個人情報保護法が委託先に求める監督義務との関係

個人情報保護法23条は、個人データを扱う事業者に安全管理措置を講じる義務を課しています。25条はこれを一歩進め、委託元は委託先を監督する義務を負うと定めています。監督義務の内容は、①適切な委託先の選定、②委託契約の締結、③委託先における個人データ取扱状況の把握、の3点です。

医療情報分野向けに総務省・経済産業省が公表しているガイドラインは、この25条の解釈として興味深い整理を示しています。委託先がクラウドサービス事業者であり、契約条項によって個人データを取り扱わないことになっていて、かつ適切なアクセス制御を行っている場合を想定します。この場合、委託元は個人データを「提供」したことにならず、25条に基づく監督義務そのものが生じない、という考え方です。

この論点は医療分野に限りません。開発を委託する先がClaude Codeを使い、その先で自社の認証情報にアクセスできる状態になっているなら、話は同じ構造です。credential maskingで実値がエージェントのコンテキストに一度も渡らないことを技術的に示せれば、「適切なアクセス制御を行っている」という主張の裏づけになります。委託先管理をシステム面から補強する材料として機能する、という位置づけです。

Claude製品全体のデータレジデンシーが個人情報保護法の要求にどう対応するかは、Claude Data Residencyと外的環境の把握で扱っています。credential maskingは「どこにデータを置くか」ではなく「認証情報をどう遮蔽するか」を扱う機能なので、両者は別の論点として使い分けます。

内部不正のリスクと認証情報マスキング(credential masking)が効く場面

内部不正は「組織の外の攻撃者」だけの話ではありません。前述の医療情報ガイドラインが挙げる代表的な脅威にも、「正当な権限を持たない者(組織の内外を問わない)が認証情報等を盗み見る」という項目があります。委託先の開発者や、委託先内の別プロジェクト担当者がAIエージェントのセッションから認証情報を覗き見る経路は、実際に起こり得る内部不正の型です。

credential maskingが防げる範囲と防げない範囲を、シナリオ別に示します。

一番下の行が実務上つまずきやすい点です。credential maskingは「エージェントに実値を渡さない」仕組みであって、「出力される文章の中身を検査する」仕組みではありません。委託先の運用でこの境界を誤解していないか、確認しておく価値があります。

委託先にAI利用を許可する条件をどう決めるか

委託先の適格性を確認する材料として、プライバシーマーク認定やISMS認証(JIS Q 27001)の取得を求める運用は広く定着しています。ただしISMS認証は情報システム管理の体制を認証するものであり、安全対策そのものの有効性までは証明しません。認証を取っているかと、実際に効く対策を入れているかは別の話です。同ガイドラインは、ISMAP等のクラウドセキュリティ認証で代替することも認めていますが、いずれの認証も安全管理水準そのものを満たす保証にはならないと注記しています。credential maskingの設定内容は、この「実際に効く対策」を具体的に示す材料として使えます。

委託先にClaude Codeの利用を許可する前に、次の3点を契約や運用ルールに落とし込んでおくと、監督義務への対応として説明しやすくなります。

• バージョン要件: sandbox.credentialsのファイルmaskはv2.1.221以降、環境変数maskはv2.1.199以降で使えます。古いバージョンでは同じ保護が効きません。
• 設定の提出: sandbox.credentialsのenvVarsとfilesの設定一式、およびnetwork.allowedDomainsの一覧を委託先から提出させます。injectHostsが広すぎないかはここで確認します。
• 管理設定での固定: maskエントリはユーザー設定・管理設定・--settingsフラグからのみ有効になり、リポジトリの.claude/settings.jsonでは無視されます。委託先の開発者個人が勝手に緩められない形にするなら、管理設定側で配布する運用が前提になります。

社内展開時によく出る懸念(データがどこに残るか、誰が見られるかなど)はClaude Code社内展開の懸念集で一次情報ベースに整理しています。委託先向けの説明資料を作るときにも、同じ論点の多くがそのまま使えます。

監督義務③「取扱状況の把握」を運用ログで裏づける

委託先が実際にcredential maskingを有効にしたまま運用しているかは、設定ファイルを一度提出させただけでは確認しきれません。設定はいつでも変更できるからです。継続的に状況を把握するには、運用ログが要ります。

Claude CodeはBashツールの実行ごとにOTELイベントを出しています。tool_resultイベントのdangerouslyDisableSandbox属性を見れば、そのコマンドがサンドボックスを経由せずに実行されたかどうかが分かります。trueが記録されているセッションは、サンドボックスもcredential maskingも効かないまま動いた区間です。委託先のログにこの属性が頻出していないかは、監督義務の③「委託先における個人データ取扱状況の把握」に直接対応する確認項目になります。

セキュリティ監査でよく出る設問とイベント・属性の対応はClaude Codeセキュリティ監査とOTELイベントの対応表にまとめてあります。委託先にログの定期提出を求める運用にするなら、この対応表をそのままチェックリストとして流用できます。

情報漏洩対策として説明するときの注意点

credential maskingを情報漏洩対策の柱として説明するときは、範囲を正確に区切ることが欠かせません。この機能が塞ぐのは「AIエージェントの実行環境から認証情報が漏れる経路」だけです。業務データそのものをどこまでClaudeに入力してよいかは、別の論点です。

業務データの共有可否を判断する基準は業務データ漏洩対策チェックリストにまとめてあります。credential maskingは「認証情報を守る」機能、あのチェックリストは「入力していいデータを選ぶ」ための基準で、役割が異なります。委託先管理の文脈でセキュリティ体制を説明するときは、この2つを合わせて提示すると、監督義務の「委託先における取扱状況の把握」に対する説明として厚みが出ます。

まとめ

credential maskingは、AIエージェントの実行環境から認証情報の実値を隠す技術的な仕組みです。個人情報保護法25条が委託先に求める監督義務のうち、「適切なアクセス制御」を裏づける材料として使え、内部不正の代表的な経路(盗み見・なりすまし)のうち認証情報の直接窃取を遮断します。一方で、出力内容そのものの検査や、業務データの入力可否までは扱いません。委託先にAI利用を許可する際は、バージョン要件と設定の提出を契約・運用ルールに組み込み、業務データの扱い方針とあわせて説明する形が実務的です。