Claude Code 法人 セキュリティ審査の承認条件と証跡

法人利用の承認可否は条件と証跡で判断する

稟議資料のセキュリティ欄で手が止まる場面があります。利用部門は試したい機能と対象 repo を持ってきますが、情報システム部門の確認はそこで終わりません。コードやプロンプトの扱い、外部通信、ログ、退職者停止まで論点が広がり、法務からは契約条件とデータ処理の確認先を聞かれます。ここでは、便利そうかどうかの説明より、承認条件と証跡の表が先に効きます。

法人審査でつまずく根は、Claude Code を「機能が安全かどうか」という軸だけで見てしまうところにあります。審査会議で実際に問われるのは、誰がどのコマンドを実行できるか、どの外部接続を会社が許可するか、退職者をどの経路で止めるか、問題が起きたとき誰がログを追うか、という運用の責任です。だからこの記事は「誰が何を確認し、どこに証跡を残すか」を表の軸に置きます。Claude Code を業務判断を進めるためのインフラとして扱うと、審査は導入の可否判定から運用設計のレビューへ自然に移ります。

Claude Code は、ターミナル、ローカルファイル、リポジトリ、外部ツールに近い場所で動きます。公式の Security docs は、操作ごとに許可を取る設計である permission-based architecture、悪意ある指示の混入を指す prompt injection、外部ツールやデータ源をつなぐ仕組みである MCP、クラウド側で処理を走らせる利用形態である cloud execution の境界を説明しています。これらは用語の理解で終わらせず、そのまま社内の確認項目に直結させます。permission-based architecture は「誰がどのコマンドを実行できるか」、MCP は「どの外部ツール接続を許可するか」、prompt injection は「外部から来た指示で credential 読み取りや外部送信が起きないか」、cloud execution は「どこで処理が走り、何が外部へ出るか」を確認する入口です。法人審査では、この仕様から「誰が、何を、どこまで許可するか」という質問に答える必要があります。

最初の判定は 5 段階に分けると、稟議とレビューの会話が揃います。表は結論を急ぐ道具というより、保留と禁止を早めに見つけるための入口です。

審査順序は 5 つに絞ります。利用範囲、契約とデータ保持、権限初期方針、MCP と外部通信、ログ責任者と再審査日です。途中で禁止条件が出た時点で、会議の議題は導入可否から不足証跡の回収へ移ります。

検索面では Claude Security や Automated Security Reviews も混ざります。これらはコード脆弱性レビューの補完統制です。これらを導入しても、契約、データ保持、権限、監査ログ、MCP 審査は残ります。

公式根拠を審査項目へ変える

稟議に公式ページの URL だけを貼ると、確認した人、確認日、証跡の保存先が残りません。レビュー会議では「そのページのどこを見て、社内のどの規程に照らしたのか」を聞かれます。

審査票で確認順序と責任者を同じ行に固定するのには理由があります。情シスと法務が別々のタイミングで同じ URL を見ると、見た範囲と判断がずれ、会議で「結局この項目は誰が確認したのか」が宙に浮きます。データ利用、契約条件、操作権限、組織配布、監査ログ、ZDR、Trust Center を別行にし、各行へ URL、確認内容、証跡例、担当部門を置くと、確認の順序と担当が一意に定まります。あとで公式ページが更新された時も、差分を追う場所が一目で分かります。審査会議で「この項目は誰の確認か」と聞かれたら、該当行の担当部門の欄をそのまま示せます。

特に「コードやプロンプトが学習利用されるか」という質問は、Data usage だけで閉じると粗くなります。契約ルート、provider、feedback、telemetry、社内 AI 利用規程まで同じ欄で確認します。

法務確認欄では、Commercial Terms と Consumer Terms、DPA、Usage Policy、Privacy Policy を確認先として並べます。契約本文を本文中で要約しすぎるより、確認すべき一次情報、確認日、社内の確認者を抜けなく残すほうが審査で使いやすくなります。

提供経路は必要な統制で比べる

審査会議で詰まりやすいのは、料金表を見ながら「Team で足りますか、Enterprise が必要ですか」と聞かれる場面です。ここで金額だけを見ても、退職者の停止、ログの取得、契約責任、データ保持の確認が抜けます。

先に見るのは、ログイン、アカウント作成、退職者の停止を会社側で制御できるかです。SSO は会社の認証基盤でログインさせる仕組み、JIT や SCIM は利用者の作成と停止を管理する仕組み、domain verification は自社ドメインを会社管理に結びつける確認です。

Claude Code の enterprise deployment overview と admin setup は、Claude for Teams / Enterprise、Claude API、Amazon Bedrock、Vertex AI、Microsoft Foundry などの経路を比較する入口になります。provider 別の retention、logging、IAM 詳細は、各 provider の公式 docs を台帳に追加してから別ページで扱う範囲です。

ここでの分岐は、必須統制を先に固定してから提供経路を当てる順番で考えます。契約、保持、監査、ZDR、managed settings、既存 IAM / logging、請求責任のどれが承認条件かを先に置くと、経路ごとの確認点は次に絞れます。

• Claude for Teams：小規模に早く始める候補。契約、利用者管理、managed settings の可否、データ扱い、管理画面と利用者一覧を確認する。
• Claude for Enterprise：SSO、SCIM、監査ログ、Compliance API、ZDR、managed settings を承認条件に入れる場合の候補。対象範囲、提供条件、audit export、契約確認メモを確認する。
• Claude API：既存アプリや社内ツール側で統制する候補。Commercial Terms、API key 管理、ログ、データ保持、API key 管理台帳を確認する。
• Amazon Bedrock：AWS 側の IAM、logging、retention、請求、責任分界へ寄せたい場合の候補。AWS 側の設定証跡を確認する。
• Vertex AI：Google Cloud 側の IAM、logging、retention、請求、責任分界へ寄せたい場合の候補。Google Cloud 側の設定証跡を確認する。
• Microsoft Foundry：Microsoft 側の RBAC、logging、retention、請求、責任分界へ寄せたい場合の候補。Microsoft 側の設定証跡を確認する。

ここで先読みしておきたいのは、最初に選んだ経路が後の全社展開で足かせになるケースです。PoC を Team で素早く始めると検証は進みますが、承認条件の一部は経路で変わります。たとえば Compliance API は Claude Enterprise と Claude Platform が対象で Teams は対象外と記載されている一方、server-managed settings は Claude for Teams と Claude for Enterprise の両方で使えると記載されています。承認条件が経路で分かれる場合、全社展開の段階で経路の切り替えが必要になり、利用者の作り直しや契約の再確認が発生します。だから PoC 開始時点で、全社展開で何が承認条件になるかを先に台帳へ書き、その条件を満たす経路を最初から見据えておきます。各経路で監査ログ、SSO / SCIM、Compliance API、ZDR が使える提供条件と最低バージョンは volatile な項目なので、結論を本文で断定せず、提供経路ごとに「○○の提供条件を公開前確認」という欄を審査票に残します。

provider 別の retention / logging / IAM / RBAC は各 provider の公式 docs を台帳に入れた別ページで確認します。この章では、Enterprise を主要候補に決め打ちせず、必要統制と証跡が一致する経路を選ぶところまでを扱います。

IAM の欄で見るのは、会社の認証でログインを揃えられるかです。そのうえで、利用者の作成、席の割り当て、グループ同期、退職者の停止が会社側の手順で閉じるかを見ます。承認前の会議では、設定手順の細かさより、誰が停止権限を持ち、退職時にどの経路で止まるかが問われます。

権限設定は禁止・確認・許可で初期方針を作る

承認後の事故は、曖昧な権限から起きます。Read、Edit、Bash、WebFetch、MCP は、禁止、確認、許可に分けた初期方針として配布します。

公式の permissions は、deny、ask、allow の 3 つを deny → ask → allow の順に評価する仕組みを説明しています。最初に一致したルールがその操作の扱いを決めます。設定はローカルのお願いごとに留めず、settings と server-managed settings による組織配布、sandbox、ログ確認を組み合わせます。ここで審査が見るのは、ローカル設定が「お願い」のまま残らず、組織側の設定がユーザー側の設定より上位で効くかどうかです。公式の server-managed settings docs は、server-managed settings が設定階層の最上位で、コマンドライン引数を含めてユーザーや project の設定では上書きできないと明記しています。ネットワーク障害時の挙動は、リモート取得に失敗した起動直後は管理設定なしで動く fail-open がデフォルトで、forceRemoteSettingsRefresh: true を入れると取得完了まで起動を止める fail-closed に切り替えられます。提供条件（対象プランや最低バージョン）と各設定キーの実値は、組織配布の前に公式 settings / server-managed settings docs の本文で確認してから埋めます。

この初期方針を「文章のお願い」で終わらせないために、設定としてどう書くかの骨格を 1 つ持っておくと配布が早くなります。公式の permissions docs は、設定の形を permissions の下に allow / deny / ask の 3 つを置き、それぞれへ Tool または Tool(specifier) 形式のルール文字列を配列で並べると説明しています。deny の効き方は 2 通りで、Bash のように素のツール名を deny に入れるとそのツール自体が Claude の文脈から外れ、Bash(rm *) のように範囲を絞ると、ツールは使える状態のまま一致した呼び出しが実行前にブロックされます。下は禁止・確認・許可を組織側の設定に落とす時の骨格です。実際に書くルール文字列と specifier は、組織配布の前に公式 permissions / settings docs の本文で確認してから埋めます。

// 組織配布する権限初期方針の骨格（実際のルール文字列・specifier は
// 公式 permissions / settings docs で確認してから確定する）
{
  "permissions": {
    "deny": [
      "Bash(curl *)",       // 外部取得スクリプトを実行前に止める
      "Bash(rm *)",         // 破壊的コマンドを実行前に止める
      "Read(./.env)"        // 秘密ファイルの読み取りを止める
    ],
    "ask": [
      "Bash",               // 残りの Bash は実行前に確認を挟む
      "WebFetch",           // 許可ドメイン外は確認を挟む
      "Edit"                // 反映先を repo / branch / PR に閉じる
    ],
    "allow": [
      "Read(./src/**)"      // 範囲を絞った読み取りだけ許可
    ]
  }
}

次の表は、権限初期方針を実務で止めるための禁止操作リストです。社内ルールの文章だけに頼らず、permission rules、managed settings、sandbox、ログで確認できる形に寄せます。

MCP と外部通信は追加の信頼境界として審査する

利用部門から「この MCP server も入れたい」と追加依頼が来た時、審査は機能名だけでは進みません。server ごとに、提供元、権限、外部通信、認証情報、ログ、撤回手順が変わります。審査では Claude Code 本体とは別枠で扱います。

managed MCP の公式 docs は、disable、fixed deployment、approved catalog、allowlist、denylist といった組織統制の考え方を示しています。Security docs でも MCP は、通常のファイル編集やコマンド実行とは異なる確認境界として説明されています。MCP を別枠で審査する根拠は ZDR の対象範囲にも現れます。公式の ZDR docs は、third-party integrations や MCP server で扱うデータは ZDR の対象外で、各サービスのデータ取り扱いを個別に確認する必要があると明記しています。つまり ZDR を有効にしても、MCP 経由のデータ保持は server 側のポリシー次第で、本体とは別に確認が要ります。

社内審査では、この表を 1 行 1 server で埋めます。空欄が残る server は、便利そうに見えても承認候補へ進めず、owner に確認を戻します。

WebFetch と外部通信も同じ考え方です。未審査の送信先を自動許可すると、悪意ある README、設定ファイル、外部ページ、MCP server 経由で credential 読み取りや外部送信の圧力が生まれます。prompt injection は抽象論で終わらせず、禁止操作表と通信先審査表へ接続します。

監査ログは責任者と保存先まで決める

セキュリティ審査で「ログは取れます」と回答しても、その後に「誰が見ますか」「どこに保存しますか」「インシデント時に何分で追えますか」と続きます。ここを空欄にしたまま導入すると、問題発生時にログの所在確認から始まります。

監査ログの確認が会議で必須になるのは、ログを「誰が、いつ、どこで、何のために見るか」が決まって初めて、インシデント時の初動がログ探しで止まらないからです。取得者がいなければ誰も export せず、保存先が決まっていなければ SIEM 連携も組めず、レビュー担当がいなければ異常が見過ごされます。だから審査表では取得対象ごとに owner を分け、取得者、頻度、保管場所、レビュー担当、インシデント時の確認手順を同じ行に並べます。

Help Center は Enterprise の audit logs と Compliance API の情報を示しています。審査表では、この「取れる」を出発点にして、監査会議で実際に聞かれる問いへ広げます。ここで一つ確認の粒度を上げておきたいのが Compliance API の取得範囲です。公式の Compliance API docs は、activity feed events に加えて chat data と file content そのものを programmatically に取り出せると説明しています。メタデータの索引に留まらず本文まで取れるため、初回取得の設計と保存量はこの前提で組みます。利用できるプランは Claude Enterprise と Claude Platform（API）顧客で、Teams は対象外と記載されているので、自社の契約がどれに当たるかは公開前に Compliance API のページ本文で確認します。

初回運用でつまずきやすい点も先に置いておきます。Compliance API は chat data や file content の本文まで取れるので、どこまで取得するかを事前に決めないと、初回の取得量が想定を大きく超え、保管とレビューが回らなくなります。取得対象ごとに owner を分けても、保存先のアクセス権が決まっていないと export を誰も開けず、レビュー頻度を「月次」と書いても初回レビュー日を予定に入れていないと最初の 1 回が流れます。この 3 つは導入直後に起きやすいので、取得範囲、保存先のアクセス権、初回レビュー日を承認前に同じ台帳へ書きます。

自由記述の承認ログは、あとで復元しようとした時に崩れます。承認時点の設定ファイル、対象 repo、承認者、展開先が別々の場所に残ると、問題発生時に「何を承認したのか」を追えません。監査で聞かれるのは、結局この 6 つです。自社の運用設計レビューでは、その弱さを artifact ID、version、requester、approver、recipient、approval comment の欄に分解しました。この記事では固有案件を出さず、必要な欄だけを公開用テンプレートに残します。

• artifact ID：どの審査票や設定を承認したかを固定します。例は security-review-2026-06 です。
• version：差し替え後の混同を防ぎます。例は v1.2 です。
• path snapshot または hash：承認時点の中身を追えるようにします。例は審査票の保存 path です。
• requested by / approved by：依頼者と承認者を分けます。例は利用部門責任者と情シス責任者です。
• recipient：誰へ展開したかを残します。例は対象部署と対象ユーザーです。
• approval comment：条件付き承認の条件を残します。例は期限、対象 repo、禁止操作です。

artifact ID と version を起点にすると、承認時点の設定、保存 path、展開先を後から照合できます。ログの有無だけで承認せず、誰がいつ何を見直すかまで審査票に残すと、インシデント時の初動が記録探しで止まりにくくなります。

承認前に止める条件を明確にする

審査で迷う項目は、先に止める条件へ落としておくと判断が早くなります。保留と禁止を分けるだけで、利用部門は次に何を確認すればよいか分かります。

ZDR は強い確認項目ですが、「ZDR がある」で結論にすると審査は粗くなります。確認するのは、対象範囲、対象外機能の具体、provider retention、policy violation retention の 4 つです。対象外機能は「何が対象外か」を名前で押さえないと、後段の確認が循環します。公式の ZDR docs は、third-party integrations や MCP server で扱うデータは ZDR の対象外で、各サービスのデータ取り扱いを個別に確認する必要があると明記しています。Desktop アプリからの cloud session も、prompt と completion を含む永続セッションデータを必要とするため、ZDR 下では無効化される機能として挙げられています。WebFetch のような first-party 寄りの外部取得が ZDR に含まれるかは公式ページに個別の記載がないため、本文では断定せず、ZDR ページ本文の対象外機能一覧と照らして審査表に書き出します。policy violation retention は、セッションがポリシー違反としてフラグされた場合に最大 2 年保持されるモードで、何がそのモードを起動するかが compliance 判断に直結するため、起動条件をページ本文で確認してから埋めます。契約面では Commercial Terms、Consumer Terms、DPA、BAA、credential use の確認が残ります。

例外承認テンプレートには、承認者、対象 repo、対象コマンド、期限、ログ確認、設定戻し、再審査日を入れます。例外を口頭承認にすると、あとで誰も説明できない状態になります。

埋めた状態の一例を、匿名化した値で示します。対象 repo は payments-sdk、対象 branch は develop、対象コマンドは npm install、承認者は基盤チーム責任者、実行者は推進担当、ログ確認者はセキュリティ運用、期限は 2026-07-31、戻し手順は期限到来時に情シスが Bash の deny を戻して再審査、という形です。固有案件は出さず、どの欄に何を書くかだけを写し取れる粒度に揃えています。

完了判定は審査票と次の打ち手に残す

審査が終わった状態は、社内で配れる粒度に分けて残します。審査票が埋まり、禁止事項と禁止・確認・許可の初期方針が関係者に共有され、ログ保存先と責任者、例外承認フロー、再審査日まで同じ台帳に入っている状態です。ここまで揃うと、会議では「使ってよいか」から「どの経路で、どの範囲から始めるか」へ話題を進められます。

AI 生成コードについては、PR、test、人間レビュー、必要に応じた security review を補完統制に含めます。コード脆弱性レビューは有用ですが、利用審査の P0 である契約、データ保持、権限、監査ログ、MCP 統制とは別の証跡として残します。

完了判定は、表で眺めるよりも担当者がそのまま潰せるチェック欄にしておくと運用に乗ります。各条件は、証跡と次の打ち手を同じ行に置いて確認します。

• 審査票が埋まっている状態です。公式根拠 URL、確認日、担当者、未確認欄を確認し、残った未確認欄は owner へ戻します。

• 禁止事項は合意済みです。禁止操作表、server 単位の MCP 台帳、外部通信確認欄を見直し、PoC 対象者へ配布します。

• 初期方針は配布済みです。permission policy、managed settings、確認ログが同じ版を指しているかを確認し、例外承認の受付を始めます。

• ログ責任者が決まっています。ログ責任分界表、保存先、レビュー頻度を見て、初回レビュー日を予定に入れます。

• 例外承認フローが使える状態です。承認者、対象 repo、期限、戻し手順、再審査日を確認し、期限切れ例外を棚卸しします。

• 次回確認日が残っています。source_verified_at（2026-06-02 JST）と公開前確認（公開直前確認）を分け、volatile claim の確認欄を見て、公式 docs の差分を再確認します。

承認後に見る欄を残すと、PoC から全社展開へ進む時の引き継ぎが軽くなります。

次に埋めるのは、提供経路、対象 repo、利用者、禁止操作、MCP 承認期限、ログ保存先、再審査日の 7 つです。会議に持ち込む前に、この 7 つをそのままチェック欄として潰します。

• 提供経路を決定（必要統制から逆算し、Team / Enterprise / API / Bedrock / Vertex / Foundry のどれかを選ぶ）
• 対象 repo を記録（PoC 範囲と対象 branch を固定）
• 利用者を記録（対象ユーザーと退職時の停止経路を確認）
• 禁止操作を配布（禁止操作表を PoC 対象者へ共有）
• MCP 承認期限を設定（approved catalog と再審査日を記入）
• ログ保存先を決定（取得者、保存先、レビュー担当、初回レビュー日を確定）
• 再審査日を記録（volatile claim の公開前確認欄と再審査日を残す）

公式情報を社内証跡へ写し替え、各欄に確認者と確認日を入れると、承認前レビューから導入経路選定へ進めます。