ISMSの適用宣言書(SoA)をClaudeで下書きする — 社内規程との対応表

適用宣言書(SoA)は、附属書Aの管理策を一つずつ「適用するか」「なぜか」「どの規程で担保しているか」に落とした表です。この表の下書きは、Claudeに社内規程を読ませて埋めさせるのに向いています。ただし、規程番号や条文を取り違えたまま通ってしまうのが最大の落とし穴です。この記事では、Projectsに規程を置いて下書きを作る手順と、取り違えを見抜く検証の型を示します。

適用宣言書に何を書くか — Claudeに任せる範囲を決める

ISMSの認定機関であるISMS-ACは、適用宣言書を次のように説明しています。ISMSに関連して組織が適用する管理策を記述した、文書化された情報です。適用した結果とその理由、適用しない場合の理由を明記します。附属書Aに無い管理策を独自に追加したときは、その内容と理由も書きます。

つまり、1行に必要な情報は次の4つです。

• 管理策(附属書Aの項目)
• 適用か除外か
• その理由
• 追加管理策なら、内容と理由

実務ではここに「根拠となる社内規程」と「未整備かどうか」の列を足します。審査で聞かれるのは、たいていこの2列だからです。

Claudeに任せてよいのは、規程の条文を管理策に当てはめる一次案までです。適用か除外かの判断は、組織のリスクアセスメントの結果で決まります。ISMS-ACは、安易な適用除外や理由の不明確な適用がマネジメントシステムの一貫性に影響すると述べています。判断の主体は人に残し、Claudeには「候補と根拠の提示」を担当させます。

除外の理由づけには、ISMS-ACが例示する「除外の原則」が使えます。次の3条件がすべて満たされるときだけ除外する、という考え方です。

この3条件はプロンプトに組み込めます。除外案が出たら、3条件それぞれへの回答を必ず付けさせると、理由欄が「該当なし」の一言で済まされにくくなります。

入力を2種類に分ける — 管理策一覧と規程一式

下書きの精度は、入力の整え方でほぼ決まります。用意するのは2種類です。

1. 管理策の一覧:ISO/IEC 27001:2022の附属書Aの表。管理策番号・名称・要求の趣旨を、自社で購入・閲覧している規格から転記してCSVかMarkdown表にします。
2. 社内規程の一式:情報セキュリティ基本方針から個別の運用規程、手順書まで。規程番号と版が分かる形にします。

管理策の一覧を規格本体からではなく、Claudeの記憶から出させるのは避けます。番号と名称がずれた表は、以降のすべての行を狂わせるからです。件数も、Claudeが言う数字ではなく、手元の規格の表を数えた値を基準にします。

なお、移行の状況も押さえておくと一覧の版を迷いません。ISMS-ACの案内では、ISO/IEC 27001:2022は2022年10月25日に発行され、旧規格(2013年版)からの認証の移行期限は2025年10月31日でした。国内規格の側でもJIS Q 27001:2025(ISO/IEC 27001:2022+Amd 1:2024)の発行がISMS-ACのニュースに載っています。どの版の一覧を使うかは、自社の認証範囲に合わせて決めてください。

規程側は、Claudeが条文を引けるよう、章・条の番号が残った状態で渡します。PDFを画像として貼るより、テキストを抽出したものか、Wordのファイルをそのまま置くほうが引用が安定します。

Projectsに規程を置いて指示を書く

規程は、Claudeのプロジェクト(Projects)の知識ベースに置きます。Projectsは、チャット履歴と知識ベースをもつ独立した作業場です。ここにアップロードした文書は、プロジェクト内のすべてのチャットで使われます。有料プランでは、知識ベースがコンテキストの上限に近づくと、RAGモードが自動で有効になり、容量を最大約10倍に広げます。

規程が多い組織でも、有料プランなら容量の拡張が働きます。一方でRAGは、関連しそうな箇所を検索して取り出す仕組みです。条文の取りこぼしが起きうることは、後の検証で扱います。

プロジェクトの指示(instructions)には、出力の形と禁じ手を書きます。次のような形が一例です。

あなたは情報セキュリティ担当の補助者です。
知識ベースの社内規程だけを根拠に、ISO/IEC 27001 附属書Aの管理策ごとに
適用宣言書(SoA)の下書き行を作ります。
 
出力は次の列のMarkdown表にしてください。
管理策番号 | 管理策名 | 適用案(適用/除外/要判断) | 理由案 | 根拠規程(規程番号・条) | 引用 | 整備状況(整備済/一部/未整備)
 
守ること:
- 根拠規程は、知識ベースに存在する規程番号と条だけを書く。
- 「引用」列には、その条の本文をそのまま抜き出す。要約しない。
- 該当する条が見つからないときは、根拠規程を空欄にして「未整備」と書く。推測で埋めない。
- 除外案には、除外の原則(ISMSへの影響・目的との相反・法規制)の3条件への回答を付ける。
- 適用か除外かの最終判断は担当者が行う。迷う行は「要判断」にする。

肝は「引用」列と「推測で埋めない」の2行です。引用を求めると、あとで人が原文と照合できます。空欄を許すと、根拠のない行を無理に作らなくなります。

管理策を小分けにして表を出させる

一覧を一度に全部渡して全行を出させると、後半の行ほど雑になりがちです。管理策を区切りのよい単位に分け、1回のやり取りで1ブロックずつ作らせます。規格の表に分類の区切りがあれば、その単位に合わせるのが自然です。

依頼文は短くて構いません。

附属書Aのうち、人的管理策に当たる管理策を対象に、SoAの下書き表を作ってください。
管理策の一覧ファイルの該当行を、上から順に漏れなく扱ってください。
最後に、入力した管理策の件数と、表の行数を並べて書いてください。

最後の1行が検証の入り口になります。入力件数と行数が食い違えば、抜けか重複があります。

根拠の取り違えを見抜く5つの検証

この作業で起きやすいのは、もっともらしいのに根拠が違う行です。次の5つを、表を取り込む前に毎回行います。

1. 引用を原文と突き合わせる。引用列の文を、規程の原文で検索します。一語一句ヒットしない行は、要約や創作が混ざっています。

2. 規程番号と条の実在を確かめる。手順2で作った規程の目次と照合します。目次にない規程番号が根拠に出ていたら、その行は差し戻します。

3. 管理策の趣旨と条文の対応を読む。引用が実在しても、管理策の趣旨に合うとは限りません。たとえば、アクセス権の見直しを求める管理策に、入退室の記録の条が当てられることがあります。語が似ていても、対象が違うわけです。

4. 逆引きさせる。規程ごとに「この規程が根拠になっている管理策の一覧」を出させ、元の表と突き合わせます。表から見て正しい行でも、逆から見ると、同じ条がやたら多くの管理策に使われていることがあります。使われすぎの条は、取り違えの疑いが強い箇所です。

5. 件数を数える。規格の表の件数、入力ファイルの行数、出力表の行数が一致するかを確認します。件数はClaudeの申告ではなく、手元の表で数えます。

3の検証は、Claudeに任せず人が読む部分です。ここを飛ばすと、表の見た目は整っているのに、審査で説明できない行が残ります。

未整備と除外を取り違えない

下書きで最も混ざりやすいのが、「未整備」と「除外」です。この2つは意味が逆です。

• 未整備:自社に必要な管理策だが、規程や運用がまだ無い。適用する管理策として残り、整備の計画が要る。
• 除外:事業の特性により適用しない。ISMS-ACの言う除外の原則を満たし、理由を宣言書に書く。

規程が見つからない行を、Claudeが「該当なし」として除外案にしてしまうことがあります。規程が無いのは、その管理策が不要という意味ではありません。指示に「規程が見つからない場合は除外ではなく未整備と書く」と足しておくと、この混同を減らせます。

未整備の行は、そのままギャップ一覧になります。行を抜き出して担当部署と期限の列を足せば、是正計画の下書きに使えます。

規程を直したら、表も直す

会話の中で規程の解釈を直しても、その内容は同じプロジェクトの別チャットには引き継がれません。Claudeのヘルプセンターには、情報を知識ベースに追加しない限り、コンテキストはプロジェクト内のチャットをまたいで共有されないとあります。

運用では、確定した結果を知識ベースに戻します。たとえば、確認済みのSoA台帳を1ファイルにして置き、規程を改定するたびに差し替えます。次の下書きは、その台帳との差分として出させるとよいでしょう。

知識ベースの「SoA台帳(確認済み)」と、更新した「情報資産管理規程 第3版」を比べてください。
規程の変更で根拠が変わる行だけを、変更前後の引用つきで一覧にしてください。

TeamまたはEnterpriseプランでは、プロジェクトを組織内の特定のメンバーと共有できます。権限は、閲覧のみの「Can view」と、指示や知識を編集できる「Can edit」の2段階です。台帳を直せる人は、レビュー担当に絞っておくと管理しやすくなります。共有の設定は、組織のオーナーがオフにできます。

社内規程を預ける前に確かめること

規程には、機密区分が付いているのが普通です。Claudeに渡す前に、自社の情報の取扱いルールで、外部サービスへの提供が認められる区分かを確認します。契約や設定の側は、利用しているプランの管理者設定とデータの取扱いの説明で確かめられます。信頼性の確認資料の取り方は、Trust CenterでSOC2・ISO27001の監査報告書を取得する手順にまとめています。

なお、Projectsには新しい版(ベータ)が段階的に展開されています。現行のProjectsの説明と画面が異なる場合があります。既存のプロジェクトは従来どおり動きます。

同じ型で他の台帳づくりにも使える

この手順の骨格は、「管理策や項目の一覧」と「根拠となる社内文書」を突き合わせ、引用つきの表で下書きを出させ、人が検証して確定する、というものです。業務影響度分析で復旧優先度の表を作る手順はBCPの業務影響度分析をClaudeで進めるにあります。判断表を知識ベースに置く構成は保有個人データの開示請求対応にもあります。

下書きの速さは得られますが、適用宣言書は審査で説明責任を負う文書です。Claudeの表は、人が根拠を確かめた行だけが宣言書の一部になる、という位置づけで使うのが安全です。