機密を外に出さないISMSの適合状況評価 ― 業務PCのローカルLLMに、どこまで任せられるかを測った記録

夕刻に処理を始めれば、翌朝には、ISMS規格の全要求の合否判定が終わり、改善案の下書きまでそろっている。そのあいだ、顧客の機密は一度も業務PCの外に出ていない。そういう流れになるように、このツールは設計してあります。

ISMS適合状況評価の判定に使う情報――管理策の実施状況、情報システムの構成、企業のポリシー――は、どれも顧客の機密です。クラウドのLLMには渡せません(この制約から出発した経緯は、前回に書きました)。本稿では、このツールを使う仕事の流れを、顧客案件の始まりから報告書の確定まで、一枚の工程表として全部見せます。どこを人が受け持ち、どこをプログラムとLLMに任せたのか。

本連載は、次の順で進みます。本稿は第2回にあたります。

第1回機密の境界で、工程を制作と運用に分ける ― クラウドに出せる作業と、業務PCで閉じる作業
第2回ヒアリングから報告書まで5日間 ― 人とLLMの分担を、工程表で全部見せる(本稿)
第3回規格(JIS Q 27001/27002)の条文は、そのままではLLMに判定させられない ― 評価者の判断を「部品」に作り込む話
第4回 LLMは何を根拠に「合格」と言うのか ― 判定の仕組みには、割り切りがある
第5回ローカルLLMに答え方を教え込む、ファインチューニングの実際
第6回採点基準は、測る前に決めておいた ― ISMS規格の全要求で、採点者を置かずに採点する
第7回学習で消えた誤りと、残った誤り
第8回支援ツールとしては使える ― ただし、評価が自動になったとは言わない

はじめにお断りを二つ。ここで扱うのはISMS-AC認定の認証審査ではなく、コンサルティングとしての適合状況評価の支援です。また、これは個人プロジェクトであり、特定の企業・案件とは関係がありません。

全体像 ― 5日間の工程表と、三種類の担い手

まず工程表です。1案件を5営業日で回すことを、利用シーンとして想定した目標に置きました。実績ではなく、設計上の目標値です。なお、この工程は設計として組んだもので、実際の顧客案件にはまだ投入していません。

日程	工程	担い手
1日目	ヒアリング	人
2日目の朝	適用範囲の承認(プログラムが除外候補を出し、人が承認)	プログラム・人
2日目の夕刻から3日目の朝	自動判定の一気通貫処理	プログラム・LLM
3日目	予備(再実行のバッファ)
4日目	結果の点検・確定	人
5日目	改善案の精緻化・清書・納品	人

担い手は三種類です。人(専門家)、プログラム、そしてLLMです。どの工程をどの担い手に任せるか、その分担は自分で決めました。ここからは、この流れを初日から順に歩きながら、そう分けた理由をあわせて示します。

初日は人の仕事 ― 実施状況と、組織の事実。二つを分けて聞く

初日は丸ごとヒアリングです。聞くことは二つに分かれます。

一つ目は、管理策の「実施状況」です。規格(JIS Q 27001/27002)の条文には、一つの文に複数の義務が含まれているものがあります。そのままLLMに問えば、どこを見て判定したのかが曖昧になります。そこでこのツールでは、条文を「1義務=1行」の最小単位まで分解してあります。その数は合計200件です。分解のさらに細かな話は、次回で書きます。

ヒアリングでは、この200件の判定の材料を集めるために、ISMSに詳しくない顧客でも答えられる平易な設問で「実際に〜していますか」と行為を尋ね、はい/いいえで答えてもらい、1回のヒアリングで確実に集めます。このとき、各設問に「はい/いいえの判断基準」を添えます。決めたことが実際に運用され、記録が残っていれば「はい」。一部でもできていない・決めていない・わからない場合は「いいえ」。

判断基準を添えるのは、回答者に自社の実態を正確に認識してもらい、中途半端な実施を正直に「いいえ」へ倒してもらうためです。こうして入口を厳密にするから、後の工程で判定が「はい/いいえ」を信頼できます。

二つ目は、「組織の事実」です。管理策の実施状況だけでは、その管理策が十分か不十分かは判断できません。たとえば同じ「バックアップを取っている」でも、止められない基幹システムを持つ企業と、停止が許容される企業とでは、十分性の水準が異なります。判断には、その企業の情報システムの構成・特性や企業ポリシーを踏まえる必要があります。この各企業の特性を、組織の事実として集めます。設問は、はい/いいえ/わからないを中心とした平易な形です。

この二つを分けて聞き、記入済みの二つのシートがそろえば、初日の仕事は終わりです。ここから先の作業は、プログラムとLLMに渡します。

ヒアリングの答えは、プログラムが用意済みのひな型で短い事実文に整える

ヒアリングの答えを、そのままの言葉で使用するとLLM内での解釈に揺れが出ます。そのため、ヒアリングの答えは、プログラムが用意済みのひな型で短い事実文に整えます。

組織の事実の側は、設問ごとに、ひな型の文章を用意してあります。「はい」なら「当社は〜する」、「いいえ」なら「当社は〜しない」という形です。プログラムは、回答に応じてひな型を選び、回答内容を差し込んで、短い事実文に整え、業務PCの中に保持します。

実施状況の側も、「はい」は「〜している」、「いいえ」は「〜していない」という決まったルールで短い断定文に直し、規格の要求ごとの判定の材料として直接使います。

プログラムが関係しそうな事実を広めに拾い、LLMが判定に要るものだけへ削り込む

ISMS適合状況評価の判定は、要求の一件ごとに行います。その一件一件に、組織の事実のうちどれが関係するのかを結びつける工程が要ります。

ここは2段階の処理で結びつけます。規格の要求と組織の事実の双方には、同じ語彙のタグ(メタタグ)が付けてあります。まずプログラムがこのタグを突き合わせ、関係しそうな組織の事実を候補として広めに拾います。次にLLMが、その候補の中から、その要求の判定に本当に必要な組織の事実だけを選び、拾いすぎた分を削ります。

なぜ、広めに拾ってから削るのか。紐づけの失敗には2種類あって、重みが違うからです。

取りこぼし: 判定に必要な事実が候補から漏れること。一度漏れた事実は後の工程で復活できず、致命的です。
拾いすぎ: 判定に不要な事実が候補に混じること。後からLLMが削るので、軽い失敗です。

そこで、前段のプログラムは、取りこぼしを避けることを最優先にして広めに拾います。後段のLLMが、そこから精密に削ります。削った結果は確定して固定し、同じ要求にはいつも同じ組織の事実を紐づけます。

タグの語彙の中身や、規格の要求・設問・シートの作り込みは、次回でさらに詳しく扱います。

LLMの判定を、勘で終わらせない ― 「達している」と言える基準を先に作った

ISMS適合状況評価の判定とは、規格の要求の一件ごとに、その企業が要求に達しているかどうかを決めることです。これを、評価する人の判断だけに委ねると、人によって結論が変わりえます。そこで、達成の度合いを測る基準を、あらかじめ作ってあります。基準は、全要求に共通の6段階(L0〜L5)です。

L0(未着手): 該当する取組みが存在しない。
L1(場当たり): 個人の判断で散発的に行われ、決められておらず、再現性がない。
L2(文書化): 方針・手順・基準として決められ、文書になっているが、組織的な運用は定着していない。
L3(運用): 決められた内容が継続的に運用され、実施の証跡(実施を裏づける記録)が残っている。
L4(測定・記録): 運用の結果を測定・レビューし、記録に基づいて有効性を確認している。
L5(改善): 測定や変化に応じて、継続的に改善・見直しをしている。

合格ラインはL3です。規則を決めて文書にしただけ(L2)では合格ラインに届かず、決めたことが実際に運用され、証跡が残っている(L3)なら、要求に達していると判定します。判定は「L3以上=達している/L3未満=未達」の二つに帰着します。さらに、この6段階が各要求で具体的に何を意味するかを、要求の一件ごとに、あらかじめ文章で書き起こしてあります。誰が評価しても同じ判断ができるようにするための土台で、これが全工程の出発点です。

判定の一件では、次の材料を決まった順番で並べて、LLMに渡します。

対象要求: 「1義務=1行」に分解した規格の要求と、その要求の合格ライン(L3)の基準。
実施状況: その管理策を顧客が実際にどうしているか(ヒアリングの回答から直した短い断定文)。
組織の事実: 前の節で削り込んだ、その要求の判定に必要な組織の事実。
出力の指示: 上の情報だけを根拠に、判定の結果と根拠を決まった形式で出させる指示。全200件に共通の固定文。

達しているかどうかを、どう決めるのか。その方針は、この出力の指示に明記してあります。実施状況に肯定的な事実(「〜している」など)が示されていれば、その回答を信頼して達成度を判定する。肯定的で、要求の核心を満たしていれば「達している」。否定的(「〜していない」「不足している」)であれば「L3未満」。その要求がその企業に該当するかどうか自体が分からない場合に限り「棄権(要追加確認)」。この三つが、判定の出力です。

評価をする側の方なら、ここで一度立ち止まるはずです。「はい」という回答を信頼して判定するだけなら、判定が甘くならないか。

そのとおりで、この方針には、正直に書いておくべき性質があります。「はい」と回答された要求は、運用の実態が完全には伴っていなくても、「達している」と判定されえます。これは設計上、許容しました。その代わり、入口のヒアリングでは判断基準を示して厳密に答えてもらい(初日の節)、出口の最終報告は専門家がレビューして確定します(4日目・5日目の節)。

改善案の下書きは、「L3未満」と判定された要求の一件ごとに作ります。材料は、達成基準データベース(先ほどの6段階の基準を要求ごとに書き起こした一覧)と、そこにあわせて用意してある想定エビデンス(実施を裏づける証拠の例)です。これらを使って、何を・どの順で・どんな証跡で整えるかの骨格を示す下書きを作ります。

夜のあいだに、LLMがISMS規格の全要求の合否判定と改善案の下書きを一気に済ませる

2日目の朝、記入済みの二つのシートを入れて一気通貫の処理を起動します。処理はまず適用範囲を判定し、その企業に当てはまらない管理策を除外候補の一覧にして止まります。軽い処理で、短時間に済みます。除外候補は提示にとどめ、専門家が承認・修正します。管理策を外す最終承認は、人に残しました。

承認を受けて、2日目の夕刻に処理を再開します。ここから翌朝までが、プログラムとLLMの時間です。前の節で示した判定用の材料を、規格の要求の一件ごとに組み立てます(広めに拾って削る紐づけは、この組み立ての中で走ります)。LLMは、全200件の要求について、一件ごとに「達している/L3未満/棄権(要追加確認)」の合否を判定します。そのうちL3未満と判定された要求を、プログラムが達していない管理策のリストに確定し、そのリストの一件ごとに、LLMが改善案の下書きを作ります。この一連の処理を、途中で人が手を入れずに一気に通し、判定の結果をまとめた評価結果一覧と、改善案の下書きをまとめた改善事項一覧まで出力します。

処理時間は、実測で7.5時間から9.0時間でした。夕刻に始めれば、翌朝には出力がそろう計算です。ただし、達していない要求が多い企業ほど長くなります。1件あたりの処理時間はほぼ一定で、合計の差は改善案を作る件数の違いでほぼ説明できます。

正直に書いておくと、この自動判定の処理中は、その業務PCで他の業務を行えません。処理を高速化するため、プログラムが実行PCのCPUをほぼ全コア使い切る設計にしているからです。そのため、夜間などPCを占有してよい時間帯に処理を走らせる前提で日程を組んでいます。担当者は処理を始めたらそのPCから離れてよく、翌朝に出力を確認します。処理中は進捗とエラーが表示され、中断しても途中から再開でき、失敗した箇所だけを再実行できます。3日目を丸ごと予備(再実行のバッファ)に充てているのはこのためで、3日目の間に再実行を二回程度見込めます。やり直しが起きても、日程が崩れないようにしています。

出てくるのは答えではなく、下書き

ここまで読むと、評価が自動で終わるように見えるかもしれません。

翌朝そろう出力は、評価結果一覧と改善事項一覧です。形の上では、規格の要求ごとの達成/未達の判定結果と、達していない項目への改善案がそろった、報告書の材料一式です。それでも、このツールでは、これを評価の「答え」とは扱いません。LLMの出力にはハルシネーション(事実と異なる、もっともらしい誤り)があり、これを根絶することはできないからです。このツールでプログラムとLLMが担うのは、規格の要求の分解、現状との突き合わせ、達しているかどうかの一次的な整理、改善案の素案づくり、までです。そこまでを済ませ、最終的な判断と報告書の確定は専門家が行う。評価を自動化したのではなく、専門家が吟味と最終判断に集中できるように下書きを用意する、支援ツールです。

「判定できない」をどう扱うか ― 最後の二日は専門家が吟味して確定する

4日目は点検です。専門家が、評価結果一覧と改善事項一覧に目を通し、LLMの判定と改善案の下書きが妥当かを確かめていきます。

このうち、専門家が引き取って確定するのが「棄権(要追加確認)」です。棄権とは、与えられた情報だけではLLMが合否を判定できなかった場合の判定です。誤りではなく、無理に断定せず人へ渡すための安全弁です。専門家は棄権の根拠(どの情報が不足して断定できなかったか)を確認し、既存のヒアリング内容で判断できるものはその場で確定し、情報が足りないものは追加ヒアリングで補ってから確定します。棄権を放置して、未判定のまま残すことはしません。なお、この出力ラベルの「棄権」と、ヒアリング回答の「わからない」は別物です。「わからない」は入力段階で「いいえ=未実施」に倒す回答であり、「棄権」は判定段階でLLMが断定を避けた出力ラベルです。

5日目は仕上げです。専門家が改善案を確定して優先度を付けます。改善案はLLMの下書きであり、その企業の情報システムの特性・企業ポリシーを踏まえた具体策への落とし込みと、技術的詳細の補完は、専門家が担います。この企業固有性の作り込みは、人の側に残す設計です。報告書を清書して、納品します。

機密が通る道は、社外に出ない

最後に、この5日間を機密の通り道として見直します。

このツールの仕事は、一度だけ作り全顧客で使い回す「制作」と、顧客ごとに毎回行う「運用」の二つに分かれます。制作には顧客の機密が一切含まれないため、クラウドのLLMを使いました。運用はヒアリング結果という機密を扱うため、業務PCの中だけで完結させ、機密を外に出しません。この境界をどこに置くかが設計全体の核であることは、前回に書きました。

本稿で歩いた5日間は、すべてこの境界の内側、運用の話です。ヒアリングで預かった二つのシートの回答も、組織の事実も、判定も、改善案の下書きも、業務PCの外には出ません。

皆さんの現場で同じ工程を組むとしたら、この5日間の分担を、どこまでLLMに任せ、どこから先は人の手に残すでしょうか。

次回 ― 『規格(JIS Q 27001/27002)の条文は、そのままではLLMに判定させられない ― 評価者の判断を「部品」に作り込む話』では、この流れを支える部品の中身について記述します。

本稿では、5日間の流れと、人・プログラム・LLMの分担を見てきました。ただ、ここまで読んで、こう思われたかもしれません。規格の条文は、そのままではLLMに判定できる形をしていない。それなら、判定できる形の200件の要求や、はい/いいえで答えられる設問は、誰がどう作ったのか、と。この流れが回るのは、LLMが賢いからではなく、流れの手前の制作で、部品を作り込んであるからです。規格の分解と達成基準、設問づくり、組織の事実を集めるシート、そしてそれらを結ぶタグ。次回は、この部品の中身と、部品に埋め込んだ判断の話をします。

次回予告: 第3回規格(JIS Q 27001/27002)の条文は、そのままではLLMに判定させられない ― 評価者の判断を「部品」に作り込む話