機密を外に出さないISMSの適合状況評価 ― 業務PCのローカルLLMに、どこまで任せられるかを測った記録
規格の条文を、そのままLLMに渡しても、あてになる合否は返ってきません。一つの文に複数の要求が混じり、「どこまでできていれば合格か」も、条文を読むだけでは決まらないからです。では、評価者は普段、その曖昧さをどう捌いているのか。本稿は、その判断を「部品」の側に作り込み、LLMに評価を支援させる話です。
ISMSの適合状況評価を、顧客の機密を外に出さないまま、業務PCの中のLLMで支援する。そういうツールを個人で作った記録を、この連載で書いています。前回は、ヒアリングから報告書の確定までの仕事の流れと、人・プログラム・LLMの分担を工程表で示しました。本稿は、その流れを支える部品の話です。
このツールへの入力は、はい/いいえ/わからないを中心とした、ヒアリングの答えです。そこから、規格(JIS Q 27001/27002)の要求を最小単位に分解した全200件について、ISMSの適合状況の合否判定(以下、合否判定)と、改善案の下書きまでたどり着きます。それを可能にしているのは、LLMの賢さではありません。条文と合否判定の間を埋める、評価者の判断を作り込んだ部品の一式です。本稿では、その部品の中身と、そこに作り込んだ判断を説明します。
本連載は、次の順で進みます。本稿は第3回にあたります。
- 第1回 機密の境界で、工程を制作と運用に分ける ― クラウドに出せる作業と、業務PCで閉じる作業
- 第2回 ヒアリングから報告書まで5日間 ― 人とLLMの分担を、工程表で全部見せる
- 第3回 規格(JIS Q 27001/27002)の条文は、そのままではLLMに判定させられない ― 評価者の判断を「部品」に作り込む話(本稿)
- 第4回 LLMは何を根拠に「合格」と言うのか ― 判定の仕組みには、割り切りがある
- 第5回 ローカルLLMに答え方を教え込む、ファインチューニングの実際
- 第6回 採点基準は、測る前に決めておいた ― ISMS規格の全要求で、採点者を置かずに採点する
- 第7回 学習で消えた誤りと、残った誤り
- 第8回 支援ツールとしては使える ― ただし、評価が自動になったとは言わない
はじめにお断りを二つ。ここで扱うのはISMS-AC認定の認証審査ではなく、コンサルティングとしての適合状況評価の支援です。また、これは個人プロジェクトであり、特定の企業・案件とは関係がありません。
部品の全体図 ― ヒアリングの答えだけから、なぜ合否判定までたどり着けるのか
このツールが顧客から受け取るのは、資料ではなく、ヒアリングの答えです。答えは二系統あります。管理策の実施状況(規格が求めることを、実際にしているかどうか)と、組織の事実(その企業の情報システムの構成・特性・ポリシー)です。この二系統の平易な答えだけから、規格(JIS Q 27001/27002)の要求について合否を判定し、達していない要求には改善案の下書きを作ります。なぜ、それだけの入力でそこまでたどり着けるのか。
仕掛けはこうです。業務PCの中のローカルLLMに合否判定のたびゼロから考えさせるのではなく、評価者の判断をあらかじめ部品の側に作り込んでおく。合否判定のときローカルLLMは、作り込まれた判断の上で動くだけにする。このツールの仕事は、一度だけ作ってすべての顧客で使い回す部品一式の制作と、準備した部品一式を使用して顧客ごとに毎回行う運用に分かれます。運用は顧客の機密を扱うため、合否判定はそのローカルLLMとプログラムだけで完結させます。部品はすべて、この制作の側で作り込みます。制作は機密を含まないので、クラウドのLLMの力も借りられます。
部品は、大きく四つです。
| 部品 | 中身 |
|---|---|
| 達成基準データベース | 規格の条文を最小単位の要求に分解し、要求ごとに達成の基準と想定エビデンス(実施を裏づける証拠の例)を書き起こした表。全部品の出発点。 |
| 設問の一式と、要求と設問の対応表 | 要求それぞれを確かめる内部用の詳細設問と、それを顧客向けに、はい/いいえで回答する形式に整理した設問、そして、どの設問がどの要求の合否判定に効くかの対応表。 |
| 組織の事実を集めるヒアリングシートと、適用範囲ルール | 企業の情報システムの構成・特性・ポリシーを集める質問群と、その企業に当てはまらない管理策を候補として外す規則。 |
| メタタグ | 要求・設問・組織の事実の三者を同じ言葉で結ぶ、共通の語彙(キーワード)。 |
以下、順に見ていきます。判断の密度が最も高いのは、規格の分解と達成の段階、そして設問の作りです。
一つの文に、要求はいくつ入っているか ― 規格(JIS Q 27001/27002)を最小単位に分解する
分解の元にした規格は、JIS Q 27001:2023とJIS Q 27002:2024です。JIS Q 27001:2023には、2025年に追補1(気候変動の考慮)が公示されており、このツールの要求の分解は、この追補1の内容を含んでいます。
規格の条文には、一つの文に複数の「〜しなければならない」を含むものがあります。そのまま問えば、返ってきた答えがどの要求に対するものかが曖昧になり、合否を言い切れません。そこで、条文を逐語で写すのではなく、一つの義務だけを表す最小単位の文に分解し、規格の言い回しをそのまま使わず、自前の言葉で書き起こしました。この最小単位の一行を、本連載では「原子要求」と呼びます。原子要求の一件一件が、合否判定の対象そのものになります。こうして分解した結果、原子要求は全200件になりました。
分解には原則があります。一つの行に複数の動詞があっても、それが同じ対象の成熟の段階(文書にする→運用する→測る→改善する)を表しているだけなら、分割しません。成熟の段階は、次の節で定める6段階が受け持つからです。分割するのは、対象の異なる別個の管理活動が一つの行に混じっている場合に限ります。この原則を先に決めたうえで、全件を通して点検しました。1行に対象の異なる管理活動が混じっていた3件は、管理活動の数に分割しました。
達成の段階は6つ ― 「規則を決めただけ」の会社と「日々回している」会社の間に、合格の境目を定める
分解した原子要求の一件ごとに、どの状態からを「達している」と見なすかを、あらかじめ決めておく必要があります。ここを評価する人の感覚に委ねると、同じ会社でも、評価する人によって結論が変わりえます。そこで、達成の段階を、全要求に共通の6つ(L0〜L5)で先に定めました。
| 段階 | 基準 |
|---|---|
| L0(未着手) | 該当する取組みが存在しない。 |
| L1(場当たり) | 個人の判断で散発的に行われ、決められておらず、再現性がない。 |
| L2(文書化) | 方針・手順・基準として決められ、文書になっているが、組織的な運用は定着していない。 |
| L3(運用) | 決められた内容が継続的に運用され、実施の証跡(実施を裏づける記録)が残っている。 |
| L4(測定・記録) | 運用の結果を測定・レビューし、記録に基づいて有効性を確認している。 |
| L5(改善) | 測定や変化に応じて、継続的に改善・見直しをしている。 |
合格ラインをL3としました。規則を決めて文書にしただけの会社はL2で、合格ラインに届きません。決めたことが日々の仕事の中で運用され、証跡が残っている会社はL3で、要求に達していると合否判定します。合格の境目は、この二つの間に定めました。合否判定は「L3以上=達している/L3未満=未達」の二つに帰着します。
合否判定が二値に帰着するのに、なぜ6段階を保つのか。L2・L4・L5の基準が、改善案の材料になるからです。現状が文書化まで(L2)なら、次に目指すのは運用と証跡(L3)であり、その先に測定(L4)と改善(L5)があります。段階を保っておけば、達していない要求に、現状から合格ラインまでの道筋を示せます。この段階が実際の合否判定と改善案の中でどう働くかは、次回に説明します。
そのうえで、この6段階が各要求で具体的に何を意味するかを、原子要求の全200件の一件ごとに、想定エビデンスとあわせて自前の言葉で書き起こしました。書き起こしの際は、各段階の基準と想定エビデンスの具体性を高めるために、米国のセキュリティ管理策集NIST SP 800-53を参考にしています。ただし、NISTを参考にするのは制作でこの表を書き起こすときまでで、運用の改善案の生成では、NISTを直接使いません。業務PCの中のローカルLLMに英語圏の専門規格の個別のIDだけを渡しても中身を正確に思い出せず、説明文まで渡せば入力が長く複雑になり、処理が粗くなるからです。NISTの知見はこの表に自前の言葉で溶かし込む形で一度だけ反映し、以降は表を経由して効かせます。
こうしてできた表が、達成基準データベースです。誰が評価しても――人が評価しても、LLMが評価しても――同じ判断ができるようにするための土台で、後続のすべての部品は、ここから派生します。
「わからない」は「いいえ」と数える ― 曖昧さを入口で消す
ヒアリングの答えは、はい/いいえ/わからないで受け取ります。設計で避けて通れないのが、「わからない」をどちらに数えるかです。このツールでは、「わからない」は「いいえ(実施を確認できていない)」として、未達の側に数えます。
合格ラインL3は、決めた内容が継続的に運用され、証跡が残っている状態です。ヒアリングは専門家が行い、各設問には、それに答えるべき立場の担当者(想定回答者)を決めてあります。専門家がその担当者に確認してなお実施状況を把握できないなら、組織として運用や記録が共有され、統制されているとは言えません。つまり、L3を満たしません。だから、未達の側に数えます。この「わからない=いいえ」は、LLMがその場で決めているのではなく、評価者が設計の段階で下し、部品に固定した判断です。
この扱いが成り立つのは、専門家が適切な担当者に確認することが前提です。見当違いの相手に尋ねて出た「わからない」は人選の問題であり、想定回答者の指定と、後段の専門家レビューで吸収します。
入口をさらに厳密にするため、各設問には「はい/いいえの判断基準」を添えます。決めたことが実際に運用され、記録が残っていれば「はい」。一部でもできていない・決めていない・わからない場合は「いいえ」。中途半端な実施を、正直に「いいえ」へ倒してもらうための基準です。
こうして受け取った答えは、合否判定に渡す前に、決まったルールで短い断定文に直します。「はい」は「〜している」、「いいえ」は「〜していない」、「わからない」は「〜は確認できていない(未達側として扱う)」。合否判定するLLMに答えが渡る時点で、曖昧さは入口で消えています。
設問は約半分に統合 ― 足りない所は補足設問で補う
設問づくりは、二段で行いました。まず、200件の原子要求それぞれに1対1で対応する詳細な設問(確認設問)を用意します。これは合否の判定基準を内部で定義するためのもので、そのまま顧客には尋ねません。200問をぶつければ、答える側の負担が大きすぎるからです。そこで、同じテーマの設問をまとめ、はい/いいえで答えられる平易な統合設問86問に整理し、はい/いいえだけでは固有の義務を判別しにくいところを、補足設問19問で補いました。あわせて105問。もとの200問から約48%の削減です。これを1回のヒアリングで聞き切ります。設問の表現も、合格ラインL3に合わせ、「導入していますか」ではなく「ウイルス対策を常に最新に保ち、動いている状態を維持していますか」のように、ふだんの運用と記録を問う形にしています。統合の結果、設問と要求の対応は多対多になり人が作業して整理するのはとても難しい関係となっています。合否判定の対象は原子要求の全200件です。
組織の事実を先に押さえ、当てはまらない管理策は候補として外す
管理策の実施状況だけでは、その管理策が十分か不十分かは判断できません。たとえば同じ「バックアップを取っている」でも、止められない基幹システムを持つ企業と、停止が許容される企業とでは、十分と言える水準が異なります。判断には、その企業の情報システムの構成・特性やポリシー、すなわち組織の事実が要ります。
組織の事実は、専用のヒアリングシートで集めます。答えに応じて当てはまらない質問は自動で飛ばし、資料を見ずに即答できる基本的な事実だけを、1回で聞き切る作りです。専門用語には言い換えを添え、「わからない」も正規の回答として受けます。集めた回答は、決まったひな型で短い事実文に直します。ここでも、わからない・未回答は「いいえ」の側で扱います。
この事実は、もう一つの部品にも使います。適用範囲ルールです。その企業に存在しない管理策――たとえば自社開発をしていない企業にとっての開発関連の管理策――を、合否判定の対象から外すための規則です。除外の候補を出すのはプログラムで、外すことの最終承認は専門家に残します。
ここで、「わからない」の向きに注目してください。組織の事実への変換では、「わからない」は「いいえ」、つまり未達の側に倒します。適用範囲の判定では、「わからない」は対象に残す側に倒します。向きは逆に見えますが、どちらもリスクを見逃さない安全側です。前者は、確認できていない実施を達成と数えないため。後者は、合否判定の範囲を不当に狭めないため。「わからない」の倒し先を場面ごとに先に決めておくことも、部品に作り込んだ判断の一つです。
同じ言葉で結ぶ ― あいまい検索に頼らないための共通語彙
合否判定は要求の単位で行うので、要求の一件ごとに、その合否判定に関係する組織の事実を引き当てる必要があります。文の意味の近さで探すあいまいな検索だけに頼ると、引き当ての結果が揺れます。そこで、要求・設問・組織の事実の三者すべてに、運用の機能を表す共通の語彙(メタタグ)を付けてあります。「ガバナンス」「資産管理」「物理的セキュリティ」といった15種類の区分の言葉で、一件が複数を持つこともあります。プログラムはこのタグを突き合わせ、一つでも共通していれば候補として広めに拾います。そこから先は、LLMがその要求の合否判定に本当に必要な組織の事実だけへ削り込みます。まず網を広げて取りこぼしを防ぎ、そのうえでLLMが選り分ける、という二段構えです。要求・設問・組織の事実が同じ語彙を持っているから、あいまいな検索に頼らず、確実に結び付けられます。
メタタグの役割は、結び付けの鍵までです。LLMが事実を選び終えたら、合否判定に渡す文面にメタタグは含めません。合否判定そのものには不要で、ノイズになるからです。
なぜ、入力の形を毎回そろえるのか
要求の一件を合否判定するとき、LLMに渡す材料の種類と形は決まっています。対象の要求(分解した一行と、その要求の合格ラインの基準)、実施状況(答えから直した短い断定文)、組織の事実(前の節の手順で削り込んだもの)、そして出力の指示(全200件に共通の固定文)です。実行のたびに検索し直して材料を組み替えるのではなく、この四点を全200件分あらかじめ組み上げて固定しておきます。入力の形が毎回そろっているほど、合否判定の結果は安定するからです。
LLMの配役 ― 働くのはローカルLLMだけ。クラウドのLLMは制作までで、現場には居ない
ここで、このツールに登場するLLMを、役割で整理しておきます。運用の現場で働くのは、業務PCの中で動くローカルLLM(Llama 3.1-8B)、一つだけです。担う工程は三つで、組織の事実の紐づけの補正(広めに拾った候補からの削り込み)、合否の判定、そして改善案の下書きの生成です。三つの工程は、同じローカルLLMに、工程ごとに別々に学習させた差し替えの部品(アダプタ)を差し替えて担わせます。
クラウドのLLMは、制作の段階で二つの役割を担いました。
一つは、達成基準データベースと設問の一式を書き起こす作業です。方針と型は私が決め、200件の記入をClaude Opus 4.8(以下、Opus)が担い、私が通しで整えました。
もう一つは、ローカルLLMに答え方を教えるための教材づくりです。架空の会社を題材にLlama 4 Maverick(以下、Maverick)に先に問題を解かせ、その答えを教材として、ローカルLLMに三つの工程の答え方を学習(ファインチューニング)させました。なぜ二つで別のモデルを使ったのか、そしてMaverickをどう選んだのかは、第5回で書きます。
そしてOpusとMaverickは、運用の現場には居ません。運用は顧客の機密を扱うため、この二つを機密の境界の内側に入れないと決めているからです。OpusとMaverickの仕事は、機密を含まない制作までです。
このほか、組織の事実の検索を補助する部品として、日本語向けのモデルを二つ(埋め込みと並べ替え)、学習させず素のまま使っています。ただし、候補を拾うのはメタタグの突き合わせ、削り込むのはローカルLLMという構成のため、この補助の部品が最終的な事実の選択にどれだけ寄与しているかは、測れていません。
この部品一式は、一度作れば次の顧客にもそのまま使える ― 次回・『LLMは何を根拠に「合格」と言うのか ― 判定の仕組みには、割り切りがある』では、LLMが担う三つの工程の中身について記述します。
ここまでに説明してきた部品は、すべて制作の段階で一度だけ作る成果物です。最小単位に分解した要求と達成の段階(L0〜L5)。はい/いいえで答えられる105問。組織の事実を集めるヒアリングシートと適用範囲ルール。そしてメタタグ。メタタグの付与も、ひな型の整備も、適用範囲ルールの作成も、開発時の一回限りの作業で、運用で顧客ごとに作り直すことはありません。次の顧客にも、この一式をそのまま使います。
本稿で見てきたのは、部品の目録というより、部品に作り込んだ判断の集積です。規格をどの単位で切るか。どこからを「達している」と数えるか。「わからない」をどちらに倒すか。何を顧客に尋ね、何を尋ねずに済ませるか。合否判定のたびにLLMが賢く立ち回っているのではなく、こうした判断があらかじめ部品の側に固定されているから、この流れは回ります。
冒頭で、評価者は普段この曖昧さをどう捌いているのか、と問いました。答えは、判断を部品の側に固定しておく、です。そこで最後に、この問いを裏返してお渡しします。皆さんが自分の現場で同じツールを作るとしたら、どの判断を、LLMに委ねずに部品の側へ固定するでしょうか。
次回は、この部品がLLMの手元でどう使われるかです。LLMが担う三つの工程、すなわち紐づけの補正、合否の判定、改善案の生成が、何を入力され、何を根拠に合否を言うのか。判定の仕組みの中身に入ります。
次回予告: 第4回 LLMは何を根拠に「合格」と言うのか ― 判定の仕組みには、割り切りがある