サイバーセキュリティ経営ガイドラインにClaude導入を当てはめる — 重要10項目の対応表

サイバーセキュリティ経営ガイドラインは、経済産業省がIPAとともに策定した、経営者向けのサイバー対策の指針です。経営者が認識する「3原則」と、担当幹部(CISO等)に指示する「重要10項目」で構成されます。Claudeの導入をこの10項目に当てはめると、管理画面の設定が直接効くのは指示2・5・6・7です。保持期間の設定と契約書類で裏づけるのは指示4・8、契約書類で裏づけるのは指示9。指示1・3・10は、Claudeの設定では埋まりません。

ガイドラインは経営者に何を求めているのか

経済産業省の案内ページによると、対象は大企業と、中小企業(小規模事業者を除く)のうちITのシステムやサービスを供給する企業、および経営戦略上ITの利活用が不可欠な企業の経営者です。現行の版は2023年3月24日公開のVer3.0で、付録として、インシデントに備えるための参考情報(付録C)と、体制構築・人材確保の手引き(付録F)が付きます。

背景として挙げられているのは、IT投資とセキュリティ投資をどこまで行うかという判断が、企業戦略として経営者に求められていることです。技術担当者の仕事ではなく、経営判断の問題として扱う点が出発点になります。

IPAは、この10項目を実践する際の参考として「実践のためのプラクティス集」と、実践状況をセルフチェックで可視化する「サイバーセキュリティ経営可視化ツール」を公開しています。プラクティス集の見出しには、他社被害事例の報告(1-1)、アクセスログの取得(5-6)、インシデント発生時の優先度に応じた顧客への通知・連絡・公表手順(7-6)のように、実務に近い単位の名前が付いています。

ガイドライン自体は、特定の製品やクラウドサービスを名指ししません。したがってClaudeを導入する側が、自社の運用の中で「この指示に対する自社の答えは何か」を組み立てることになります。以降は、10項目の見出しごとに、Claudeの設定と契約書類のどれが答えの材料になるかを見ていきます。

重要10項目とClaudeの対応表

10項目の名称はIPAのプラクティス集の目次にある表記です。右の列は、Claude側で材料になるものと、必要なプランを示します。

「必要なプラン」は、各機能のヘルプ記事に書かれた提供条件を並べたものです。契約形態(直販か、クラウド経由か)や公共部門向けの扱いで変わる場合があるため、導入前に営業窓口で提供条件を確認してください。

指示2・5:体制と多層防御をClaudeの管理設定に置き換える

指示2は体制づくり、指示5は仕組みづくりです。Claudeでは、この2つが管理設定として最も具体的に現れます。

誰が何を設定できるかを先に決める

TeamとEnterpriseの組織には、Primary Owner、Owner、Admin、Userの4つの役割があります。Primary Ownerは組織に1人しか置けず、課金席を1つ使います。ヘルプ記事には、Primary Ownerを個人に紐づかないサービスアカウントにできるとも書かれています。

役割の差は、そのまま責任分界の材料になります。たとえばCompliance APIを有効にできるのはPrimary Ownerだけで、Ownerには画面は見えてもトグルは見えません。監査ログのエクスポートはOwnerとPrimary Ownerです。「誰がログを取り出せる状態にしておくか」を、役職ではなく役割名で決めておくと、異動のたびに体制図を引き直さずに済みます。

Enterpriseでは、機能の使用可否をグループ単位で絞るカスタムロールを使えます。カスタムロールを割り当てたメンバーは既定の権限を持たず、グループに付けたロールだけで権限が決まります。経営層が「部門ごとに触れる範囲を分ける」と指示したとき、設定の受け皿になるのはこの仕組みです。

入口はSSOとプロビジョニングで固める

SSOはTeam・Enterprise・Consoleの組織で使えます。設定には、会社ドメインのDNSにTXTレコードを追加するドメイン検証と、IdPの設定が要ります。設定できるのはOwnerかPrimary Ownerです。ドメイン検証とSSO設定の過程には、ドメイン検証とSSOを担うサービスとしてWorkOSが挟まります。再委託先の把握(指示9)にも関わるため、サブプロセッサー一覧に載っているかを合わせて確認すると筋が通ります。

ユーザーの自動追加(JIT)はTeam・Enterprise・Consoleで使えますが、SCIMによる自動のプロビジョニングと削除はEnterpriseとConsoleに限られます。退職者のアカウントを人手で閉じる運用では、閉じ忘れが指示5の穴になります。SCIMの有無は、プラン選択の判断材料になります。

IdPごとの手順は別の記事に詳しいので、ここでは対応づけだけを書きます。選ぶIdPの違いはClaudeのSSO設定、IdPはOkta・Google Workspace・Entra IDのどれかにまとめています。

経路とセッションを絞る

Enterpriseでは、IPアドレスの許可リストで接続元を絞れます。CIDR範囲で指定でき、許可リストにない接続元からのリクエストは拒否されます。有効化はセルフサービスではなく、CIDR範囲の一覧をAnthropicの担当窓口かサポートに渡して依頼する形です。

セッションの長さも絞れます。Enterpriseの管理者は、最大セッション長を1日・7日・14日・28日から選べます。有効にすると、利用中でも期間が過ぎれば再ログインが必要になります。侵害されたセッションが有効なままでいる期間を制限する設定です。多層防御の層として数えられますが、期間を短くするほど業務側の再ログイン頻度は上がります。

指示6・7:監査ログとCompliance APIを役割で分ける

指示6はPDCAによる継続的改善、指示7はインシデント発生時の緊急対応体制です。どちらも「何が起きたかを後から追える」ことが前提で、Claudeにはログの取り出し口が2つあります。

数字

ログ周りの数字

• 監査ログの対象期間

  直近180日

  エクスポート時に集計されます(Enterprise)

• エクスポートのリンク期限

  24時間

  メールで届くダウンロードリンクの有効期間

• DPAの侵害通知

  48時間以内

  侵害を把握してから書面で通知(G.1)

監査ログは「手元で見る」ための出口

監査ログはEnterpriseだけが使えます。OwnerかPrimary Ownerが、Organization settingsのData and Privacyから「Export logs」を押すと、直近180日分が集計され、依頼したOwnerにダウンロードリンクがメールで届きます。リンクの有効期間は24時間です。集計に時間がかかるため、押した直後にメールが届くとは限りません。

記録される列には、日時、実行者、イベントの種類、対象、IPアドレス、デバイスID、ユーザーエージェントがあります。SSOでのサインインは専用のイベントとして記録されます。一方、チャットとプロジェクトのタイトルや内容は監査ログに出ず、出力されるのは識別子だけです。チャットの入出力は、Primary Ownerによるデータエクスポートの対象になります。

Compliance APIは「継続的に流す」ための出口

Compliance APIは、アクティビティフィードのイベント、チャットデータ、ファイルの内容を、自社のツールへプログラムから取り込む仕組みです。Enterpriseの組織が対象で、公共部門の組織は除かれます。有効にできるのはPrimary Ownerだけです。

対象範囲は広く、Cowork、Claude Code(CLIとDesktop経由)も含まれます。ただし、Claude Codeのクラウドセッション、Claude Platform経由のClaude Code、一部のMicrosoft 365アプリ、Amazon BedrockやGoogle Vertex AI上のセッションは対象外です。監査ログのイベントもCompliance APIから取れます。顧客管理の暗号鍵(CMEK)を使うEnterpriseでは「Export logs」ボタンが使えず、監査ログはCompliance API経由になります。

この2つの使い分けは、指示6と7で意味が変わります。

• 指示6の定期点検や四半期のレビューでは、監査ログのエクスポートで足ります。180日分を取り出して、ロールの変更やSSOの状況を点検できます。
• 指示7の初動では、手作業のエクスポートは待ち時間が長く、SIEMなどの監視基盤に常時流しておくCompliance APIのほうが合います。
• 一部の利用形態が対象外であることは、インシデント時の調査範囲を狭めます。台帳に「Compliance APIの対象外」を書いておくと、初動の漏れを防げます。

Compliance APIの設計や、内部統制の記録保存義務との関係は、Compliance APIは内部統制の記録保存義務にどこまで応えるかで扱っています。

顧客への通知は契約条項に頼る

指示7のプラクティスには、顧客への通知・連絡・公表手順があります。Claude側の事故が自社の顧客データに及ぶ場合、通知の起点はAnthropicからの連絡です。DPAのG.1には、侵害を把握してから不当な遅滞なく、遅くとも48時間以内に書面で通知するという定めがあります。自社の通知手順は、この48時間を受け取る側の連絡先から逆算して組みます。

指示4・8:保持期間の既定値がリスクの前提になる

指示4は、リスクの把握と対応計画の策定です。Claudeの場合、把握すべきリスクの前提として、データ保持の既定値があります。

Enterpriseの保持期間は、カスタム設定をしない限り無期限です。最短は30日で、1か月を30日として数えます。期間の起点は最後の活動で、チャットなら最後のメッセージ、プロジェクトならチャットの追加や知識ファイルの編集などがリセットの契機になります。プロジェクトの保持期間は、中のチャットよりも優先されます。

削除は、予定日の午前0時(UTC)に行われ、復元できません。保持期間を短くして保存すると、新しい期間の外にあるデータは保存した時点で完全削除の対象になり、日次の処理で消えていきます。この遅れを、設定を戻す猶予として使うことはできません。

商用プランの標準の扱いも、リスク評価の材料です。商用製品の入力と出力は、既定ではモデルの学習に使われません。ただしフィードバック(親指のボタンなど)を送ると、会話全体が最大5年保存され、学習に使われる場合があります。利用規約違反と判定された場合は、入出力が最大2年、分類スコアが最大7年保持されます。ユーザーが会話を削除した場合は、画面からは即時に消え、バックエンドからは30日以内に削除されます。

設定の手順そのものはClaude Enterpriseのデータ保持期間を管理者がカスタム設定する手順にあります。

指示8は「復旧」より「消えたものは戻らない」を前提にする

指示8は事業継続と復旧の体制です。Claudeは外部のSaaSなので、自社の事業継続計画の中では「使えない日」の代替手段として扱います。DPAのセキュリティ別表A.4には、Anthropic側の事業継続・復旧計画を年1回試験するとあります。Claude側の計画が自社の許容停止時間に合うかは、この条項と、SOC 2報告書の統制記述を突き合わせて判断します。

一方で、Claudeに置いた会話を自社の唯一の記録にしないことも、指示8の論点です。保持期間を過ぎたデータは完全に削除され、復元できません。必要な成果物は、保持期間の前に自社の保管場所へ移します。

指示9:委託先としてのAnthropicを書類で確認する

指示9は、ビジネスパートナーや委託先を含むサプライチェーン全体の把握と対策です。IPAのプラクティスには、委託先の特定と対策状況の確認(9-1)があり、指示5の中にも、ITサービスの委託におけるセキュリティ対策を契約と第三者検証で担保する(5-3)という項目があります。Claudeを委託先として見るときの確認先は、次の3つです。

1. DPA(データ処理補遺):監査、侵害通知、削除と返却、委託先の追加の手続きが書かれています。
2. サブプロセッサー一覧:Anthropicが再委託している事業者の一覧です。
3. Trust Center:第三者認証や監査報告書を置いています。

DPAには、外部の監査人による年次監査があり、顧客の書面による請求があれば報告書を提供するという定めがあります(F.1)。ペネトレーションテストは毎年外部の評価者が実施し、直近の報告書の要約を請求すれば提供されます(セキュリティ別表G.2)。契約終了後は30日以内にデータの返却または削除を行います(H.1)。新しい再委託先の追加には、通知から15日以内に異議を述べられ、述べなければ同意したものとみなされます。

最後の15日は見落としやすい点です。サブプロセッサーの追加通知を誰が受け取るかを決めておかないと、期限内に異議を出す機会を失います。通知の宛先を、指示9の担当者の共有アドレスにしておく運用が現実的です。

審査票の項目と書類の対応はClaudeの情シス導入審査チェック項目をTrust Centerの資料で埋めるに、サブプロセッサー一覧の見方はAnthropicのサブプロセッサー一覧を確認する方法にあります。

指示1・3・10:Claudeの設定では埋まらない項目

3つの項目は、Claudeの管理画面にも契約条項にも対応する機能がありません。ここを無理に埋めようとすると、設定の話に見せかけた作文になります。

• 指示1(方針の策定):Claudeを使って良い情報の区分と、禁止する入力を決めるのは自社の仕事です。材料になるのは、学習利用の既定値と保持期間の説明までです。方針の条文案は中小企業の情報セキュリティ対策ガイドラインに生成AIの項を足すに例があります。
• 指示3(資源の確保):予算と人材の確保は、導入の判断そのものに属します。Claudeの設定が関われる部分はなく、人材育成の代わりにもなりません。
• 指示10(情報の共有・開示):業界団体や情報共有活動への参加は、Claudeの機能で代替できません。Claude側の情報は、DPAの侵害通知と、Trust Centerの資料を受け取る形で入ってくるだけです。

この3つを台帳で「対応なし」と書くことは、手抜きではありません。経営者が見たい資料は「どこまでがClaudeで裏づけられ、どこから先が自社の仕事か」の線引きだからです。

プランで見ると、どの項目まで言えるのか

分かれ目は、ログを取り出せるかどうかです。取り出せるプランでなければ、指示6・7は説明できません。

くらべる

TeamとEnterpriseで、10項目の裏づけが変わる点

入口と契約まで

Teamプランで言える範囲

SSOとJIT、4つの役割による分担、DPA・サブプロセッサー・Trust Centerによる委託先確認。指示2・5・9の一部と、指示1の材料になります。

ログと保持まで

Enterpriseで加わる範囲

監査ログ、Compliance API、IP許可リスト、セッション期限、SCIM、カスタムロール、保持期間の設定。指示5・6・7・4の裏づけが具体的になります。

つまり、経営者が「指示6・7まで説明できる状態にしたい」なら、プラン選びの時点でEnterpriseが前提になります。ログを取り出せないプランでは、指示7のインシデント調査を「Anthropicに問い合わせる」以外の手段で組めません。

証跡台帳の雛形

経営者への報告は、設定画面のスクリーンショットではなく、10項目ごとの証跡の所在で行うと更新しやすくなります。次の雛形は、1行が1つの指示に対する証跡です。

「次回点検」の列を埋めることが、指示6のPDCAに直接つながります。点検の際は、前回の台帳と比べて、役割の変更やサブプロセッサーの追加が起きていないかを見ます。ここで挙げた入力例は書き方の見本で、Claudeの標準の画面や出力ではありません。

まとめ

重要10項目のうち、Claudeの設定が直接効くのは体制と仕組みの2・5、ログの6・7です。4・8は保持期間の設定と契約書類、9は契約書類で裏づけ、1・3・10は自社の仕事として残ります。経営者に報告するときは、「Claudeで埋まる項目」と「埋まらない項目」を分けて示すと、判断が早くなります。

そして指示6・7を説明できる状態にするには、監査ログとCompliance APIを使えるEnterpriseが前提です。導入するプランを決める前に、10項目のうち自社がどこまで説明したいかを経営者と合わせておくと、後からプランを上げ直す手戻りを避けられます。政府調達向けのクラウド評価制度との関係は、官公庁がClaudeを使うにはISMAP登録がどう関わるかで扱っています。