こんにちは、株式会社TIMEWELLの濱本です。
「Claude Codeを全社で使わせたい。ただし、SOC2 Type IIとISO/IEC 27001:2022の認証は絶対に落とせない」。このところ、CSIRTや情報システム部門の方からこの相談を受ける頻度が一気に増えました。経営側は生産性に飛びつき、現場のエンジニアは既に個人契約で使い始めている。一方で、認証維持の責任を背負う情シスやセキュリティ担当は、SOC2のCC6.1とISO27001のA.5.23を見ながら頭を抱える、というのが2026年春の典型的な構図です。
本シリーズの第1弾では、Claude Codeを法人で受け入れるための導入設計を扱いました。今回はその次の段階、「すでにある認証を壊さずに、Claude Codeを統制下に置く」ための具体的な実装ガイドです。AnthropicのTrust Centerの読み解き方、責任分界の引き直し、SOC2 Trust Service CriteriaとISO/IEC 27001:2022 ANNEX Aへのマッピング、監査エビデンスの集め方まで、現場で実際に使えるレベルで踏み込みます。
AnthropicのSOC2 / ISO27001取得状況とAUPの読み方
最初に、利用者側が誤解しやすいAnthropicの取得状況を整理しておきます。AnthropicのTrust Centerで公開されている情報を2026年4月時点で確認すると、SOC 2 Type II、ISO/IEC 27001:2022、ISO/IEC 42001:2023を取得済み。HIPAAについても、BAA（事業提携契約）を結べる構成を提供しています。SOC2 Type IIは12ヶ月の観測期間で、Security、Availability、Processing Integrity、Confidentiality、Privacyの5領域を評価。対象範囲にはClaude API、ウェブアプリケーション、監査ログ基盤、そしてZDR（Zero Data Retention）エンドポイントが含まれます。
ISO/IEC 42001:2023はAIマネジメントシステムの新しい国際規格です。SOC2やISO27001がいわゆる「情報セキュリティの管理」を見るのに対し、42001はAIに固有のリスク、つまり透明性、説明責任、バイアス、モデルライフサイクルの管理を見ます。Augment Codeが公開した分析によれば、SOC2と42001を別々のプログラムとして並列運用した企業の60%が認証準備に失敗しており、統合フレームワークで設計した場合に40〜50%のオーバーヘッド削減が見込めるとされています[^1]。Anthropic側で42001まで取れていることは、利用者にとって地味ですが大きな安心材料です。
データの取扱いに関する条項も2025年9月に大きく動きました。AUPは「Usage Policy」へ名称変更され、B2Bと消費者向けで適用範囲が明確に区分されました。同じ9月14日には、APIの標準ログ保持期間が30日から7日へ短縮されています[^2]。学習目的の利用は標準で行われず、ZDR契約を結べばAnthropic側にデータが残らない設計です。監査用途で30日に戻したい場合は、DPAを更新してオプトインする形になります。
ここで担当者が読み違えやすいのは、「Anthropicが認証を取っているから、当社のSOC2 / ISO27001はそのまま通る」という早合点です。Anthropic側の認証は提供基盤の評価であり、利用者の社内統制を肩代わりはしません。次節で扱うShared Responsibility Modelを正しく理解しないと、ここで認証監査の現場は確実に詰まります。
法人がClaude Codeを使う際の責任分界（Shared Responsibility Model）
クラウドの責任分界モデル自体は新しい概念ではありません。AWSやMicrosoft Azureが整理してきたIaaS / PaaS / SaaSの責任分界に、AI特有の論点を追加するイメージで考えると整理しやすいと思っています。MicrosoftのAI責任分界に関するドキュメントでは、ベンダー側が基盤・モデルホスティング・プラットフォーム保護を担い、顧客側は入力データの保護、プロンプトインジェクション対策、組織・規制要件の遵守を担うと明記されています[^3]。
Claude Codeに当てはめると、責任の分かれ目はおおよそ次のように引けます。Anthropic側の責任は、データセンターと物理ネットワークの保護、モデルそのものの安全性、API・管理コンソールの脆弱性対応、TLSなど通信路の暗号化、AUP違反検知のための最低限のスキャン、SOC2やISO27001の認証維持。利用者側の責任は、アクセス権限の付与と剥奪、機密データを入力させない教育とフィルタリング、/sandbox設定やConfigChangeフックといった統制機能の運用、監査ログの長期保管、SOC2やISO27001の自社統制の整備、そして従業員教育です。
特にSaaS型のAIで見落とされがちなのが、「攻撃面が広がっている」という観点です。Claude Codeはユーザーのローカル環境でファイルを読み書きし、必要に応じてbashを叩きます。Anthropic公式ドキュメントが強調しているとおり、デフォルトでは読み取り専用、書き込みやコマンド実行は明示承認が必要、書き込みはCLAUDE.mdが置かれた作業ディレクトリ配下のみ、といった既定値が用意されています[^4]。とはいえ、これらをどう構成するかは利用者の責任です。SOC2の監査人は「設定したかどうか」ではなく「設定が組織標準として強制されているか」を見ます。
私が支援に入った金融系の事業会社では、最初の整理で「Anthropicが守ってくれる範囲」と「自社が守らねばならない範囲」を1枚のシートにし、それぞれの責任を所管部門に振り直しました。CISO配下のセキュリティ運用、IT部門のID管理、開発本部の利用ガイドライン、人事部門の研修、法務部門の契約レビュー、と分担を明示しただけで、その後の監査対応の段取りが半分以下の工数になりました。地味ですが、ここを飛ばすとあとから何度も戻ることになります。
SOC2 Trust Service Criteria 5領域でのClaude Code評価
ここからが本題です。AICPAが公開している2017 Trust Services Criteria（2022年に「Points of Focus」が改訂）では、Common Criteria CC1〜CC9と、その上に乗る追加カテゴリで構成されます[^5]。Claude Code導入で特に踏ん張る必要があるのは、CC1、CC2、CC6、CC7、CC8の5領域です。順番に見ていきます。
CC1（Control Environment）とCC2（Communication and Information）は、要するに「組織として方針があるか、社内に伝わっているか」を見る部分です。Claude Codeに関しては、利用範囲、禁止用途、機密データの取扱い、違反時の対応をまとめたAI利用ポリシーをまず1本に固めます。私の意見としては、Claude Code、Cursor、ChatGPT、Geminiなどを横並びで規定する「コーディングAI利用標準」を作り、その配下にツールごとの細則を置くやり方が一番運用しやすいです。ツールごとに別ポリシーを作ると、AUP改定のたびに全部書き直す羽目になります。
CC6（Logical and Physical Access Controls）は8基準を持つ最大のクラスタで、SOC2監査の中心と言ってよい領域です。Claude Code関連でいうと、SAML 2.0またはOIDCのSSOで個人を特定可能なIDを持たせること、Okta・Azure AD・Ping IdentityなどのIdPを介してJITまたはSCIMでプロビジョニング・デプロビジョニングを自動化すること、最小権限の原則に沿って役割ベースで権限を付与することが軸になります[^6]。Tigeraが指摘しているように、CC6.1は「権限ある特定の個人だけがシステムに入れること」を求めます。50人で1本のAPIキーを共有していると、それだけで「特定可能性」が崩れて指摘対象になる、というのは押さえておきたいポイントです。
CC7（System Operations）は、検知と対応の領域です。Claude Codeの監査ログはAdmin Consoleで標準30日保持、JSON / CSVでのエクスポートに対応し、SplunkやDatadog、Elasticといった主要SIEMへ転送できる設計になっています[^7]。SOC2の慣習的なログ保持期間は90日以上なので、ここは「Claude側は30日、SIEM側で1年以上」と二段構えにするのが現実解です。CC7.2の継続的監視を満たすには、APIエラー率、失敗bashコマンドのトップ、レイテンシ分位値の閾値を社内のオンコール監視に組み込み、異常時のチケット起票まで自動化しておきたいところ。
CC8（Change Management）は、Claude Codeが書いたコードや設定を本番に出すまでのプロセスを問う領域です。RazaShariff氏が「SOC2はAIエージェントが入った瞬間に失敗する」と挑発的に書いている通り[^8]、Claude Codeが直接コミットを行う運用にすると、変更承認の追跡が崩れます。私はこの数ヶ月、現場では「AIが書いてもPRレビューは人間。承認者は主担当の上級エンジニア。マージ権限はCODEOWNERSで強制」のセットを推奨しています。Claude Code側のフックでpre-commitを組めば、レビュー前の自動チェックも仕込めます。
ISO/IEC 27001:2022 ANNEX Aで押さえる統制（A.5〜A.8）
ISO/IEC 27001:2022は、旧2013年版から大きく刷新され、ANNEX Aは93統制になりました。組織的管理策A.5（37統制）、人的管理策A.6（8統制）、物理的管理策A.7（14統制）、技術的管理策A.8（34統制）の4分類です[^9]。Claude Codeに直結するのは、A.5とA.8の一部に集中します。
組織的管理策の中では、まずA.5.1「情報セキュリティのための方針群」が起点になります。経営承認のうえ、AI利用ポリシーを正式文書として公開・周知し、従業員の同意取得まで終えること。A.5.10「情報および関連資産の利用の許容範囲」では、機密情報のコピー・貼り付けの可否、社内秘・外秘・公開のラベル付け運用、ソースコードの取扱いを明記します。ISMS.onlineの解説が指摘するように、5.10は5.1の方針群を具体的な日常業務へ落とし込む役割を担います[^10]。クラウドサービス利用時の情報セキュリティを定めるA.5.23も外せません。Claude Codeはまさにクラウドサービスなので、選定基準・契約レビュー・終了時のデータ取扱いを文書化しないとここで詰まります。
技術的管理策では、A.8.15「ログ取得」とA.8.16「監視活動」が双璧です。8.15は「ログを取って改ざんから守ること」、8.16は「ログを分析して異常を検知すること」を求めます[^11]。Claude Codeの監査ログをただ取るだけではA.8.15止まりで、SOC2のCC7と同様にSIEMへ流して相関分析しないとA.8.16には届きません。同じく重要なのが、A.8.15が定める10種のイベント、つまり認証成功・失敗、特権アカウントの行為、管理者操作、システムエラー、設定変更、重要ファイルの改変です。Claude CodeのConfigChangeフックやpre-tool / post-toolフックは、まさにこの10種のうちの「設定変更」「特権操作」を自動でログ化する手段として優秀です。詳しい使い方はClaude Codeで使える45のSkillsを実戦投入するで扱っています。
A.8.28「セキュアコーディング」は、Claude Codeが生成するコードの品質保証に直結します。SAST / DASTツール、依存ライブラリの脆弱性スキャン、シークレット検出を、Claude Codeが書いたコードにも例外なく適用すること。私の経験では、ここを「AIが書いたコードだから簡易チェックでOK」にした瞬間に、監査人に最も厳しく突かれます。むしろAIが書いたコードのほうが厳しめにレビューする姿勢を、CTOから明確に示すのが安全策です。
監査エビデンス収集の実務（ログ、ポリシー、契約書）
統制を作っただけでは認証は通りません。SOC2 Type II もISO27001も、運用が一定期間にわたって機能していたことを示す「証拠」が必要です。私が現場で使っているエビデンス・パッケージを、Claude Code文脈で整理します。
最初に揃えるのが、契約・ポリシー系のドキュメントです。AnthropicのCommercial Terms、DPA、ZDRアドendum、AUP（Usage Policy）の最新版を案件IDつきで保管します。法務レビューの履歴も併せて残しておくと、監査人から契約レビュープロセスを問われたときに即答できます。Trust Centerからダウンロードできるレポートは、SOC2 Type IIの全文、ISO27001の認証書、ISO42001の認証書、ペネトレーションテストのサマリー。これらは年1回以上の頻度で更新されるので、社内のGRCツールに「自動リマインダ＋差分レビュー」のジョブを仕込むのが定石です。
次に運用ログ系です。Admin Consoleからエクスポートする監査ログを、SIEMに毎日連携し、最低13ヶ月分を保持します。SOC2 Type IIは12ヶ月の観測期間を取るのが一般的なので、13ヶ月あれば年次更新時にも余裕があります。実務的に効果が高いのは、Claude Codeのフックで生成される機械可読のJSONです。Amit Kothari氏が指摘しているように、pre-tool / post-tool / pre-commitフックを組み合わせると、誰がどのプロンプトでどのツールを呼び、どのコードに変更を入れたかを、後から再現可能な粒度で残せます[^12]。これはSOC2のCC7、CC8、ISO27001のA.8.15、A.8.16、A.8.32（変更管理）の4つを一度に賄える、コスパの良いエビデンスです。
最後が人的管理策（A.6）まわりです。AI利用研修の出席記録、誓約書、退職時のID剥奪ログ、内部監査の報告書を揃えます。私の主観ですが、AI研修は「年1回オンラインで30分」では足りません。新ツール導入時、AUP改定時、四半期の振り返りの3タイミングで実施するのが、認証維持と現場の事故防止の両面でちょうどいい頻度だと感じています。
このエビデンス収集を一気通貫で設計するのは、片手間でやれる仕事ではありません。私たちが提供しているWARPは、AIコンサルティングの中で統制設計と監査エビデンス整備までを支援するサービスで、SOC2 / ISO27001 / ISO42001の三本立てに耐える設計を一緒に作るときに頼っていただくケースが増えました。データレジデンシーや国内サーバー要件が厳しい案件では、Claude CodeとあわせてZEROCKをAWS国内リージョンに置き、機密領域のナレッジはZEROCK側に閉じる、という棲み分けも有効です。Claude Codeを社外秘までは扱わせず、機密はZEROCKで扱う、という線引きは、認証監査の場で説明しやすい構図でもあります。
まとめ
Anthropicが取得しているSOC2 Type IIとISO/IEC 27001:2022は、Claude Codeを使う上での前提を整えてくれます。が、それだけで自社の認証が通るわけではありません。利用者側が背負うのは、責任分界の整理、CC1〜CC9の自社統制、ANNEX A.5〜A.8のマッピング、そして1年以上にわたって運用が機能していたことを示すエビデンスです。
最初の一歩としておすすめするのは、責任分界の1枚シートを社内で合意するところです。誰が何を守るのかを部門単位で割り当てるだけで、その後のCC6やA.5.23の議論が一気に進みます。次に、Claude CodeのフックとSIEM連携で、人手のかからないエビデンス収集を仕込む。最後に、ZDR契約とDPAを締結し、ポリシードキュメントを更新する。この順番で進めれば、半年から1年で認証維持を崩さずにClaude Codeを全社運用へ持っていけます。
Claude Code導入の前段については、Claude Codeを法人で受け入れる導入設計、Skillsやプラグイン活用の実戦例はSuperpowers Claude Codeプラグインの使い所を参考にしてください。法人での運用を本気で乗り切りたい方は、お気軽にご相談ください。
[^1]: Augment Code「AI Governance Framework for SOC 2 & ISO 42001 Compliance」 https://www.augmentcode.com/guides/ai-governance-framework-for-soc-2-and-iso-42001-compliance [^2]: Anthropic「Updates to our Usage Policy」 https://www.anthropic.com/news/usage-policy-update / Anthropic Privacy Center「How long do you store my organization's data?」 https://privacy.claude.com/en/articles/7996866 [^3]: Microsoft Learn「Shared responsibility in the cloud」 https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility [^4]: Claude Code Docs「Security」 https://code.claude.com/docs/en/security [^5]: AICPA & CIMA「2017 Trust Services Criteria (With Revised Points of Focus – 2022)」 https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022 [^6]: Claude Help Center「Set up single sign-on (SSO)」 https://support.claude.com/en/articles/13132885-set-up-single-sign-on-sso [^7]: Datadog「Monitor Claude Code adoption with AI Agents Console」 https://www.datadoghq.com/blog/claude-code-monitoring/ [^8]: Raza Shariff「Your SOC 2 Audit Will Fail When AI Agents Arrive」 https://dev.to/razashariff/your-soc-2-audit-will-fail-when-ai-agents-arrive-heres-the-14-control-fix-58fp [^9]: ISMS.online「ISO 27001:2022 Annex A Explained & Simplified」 https://www.isms.online/iso-27001/annex-a-2022/ [^10]: ISMS.online「ISO 27001:2022 Annex A 5.1 – Information Security Policies」 https://www.isms.online/iso-27001/annex-a-2022/5-1-information-security-policies-2022/ [^11]: ISMS.online「ISO 27001:2022 Annex A 8.15 – Logging」 https://www.isms.online/iso-27001/annex-a-2022/8-15-logging-2022/ [^12]: Amit Kothari「Claude Code SOC 2 compliance — what your auditor needs to know」 https://amitkoth.com/claude-code-soc2-compliance-auditor-guide/