機密を外に出さないISMSの適合状況評価 ― 業務PCのローカルLLMに、どこまで任せられるかを測った記録
LLMが自動で「規格(JIS Q 27001/27002)が求めるレベルに達している」と返してくる。けれど、その判定の根拠が見えなければ、結果をそのまま顧客への報告書に書くわけにはいきません。だから私は、LLMが何を根拠に合否を判定したのかを、あとから確かめられる形に設計しました。
しかもこの仕組みには、あえて選んだ一つの割り切りがあります。なぜその割り切りを選び、どう受け止めているのか。そこも隠さず、最後に明らかにします。
ISMSの適合状況評価を、顧客の機密を外に出さないまま、業務PCの中のLLMで支援する。そういうツールを個人で作った記録を、この連載で書いています。前回は、その判定を支える部品の一式を説明しました。規格の要求を最小単位に分解した表、達成の段階(L0〜L5)、はい/いいえで答えられる設問、そして組織の事実を結ぶメタタグです。本稿では、それらの部品がLLMの手元でどう使われ、ISMSの適合状況の合否判定(以下、合否判定)にたどり着くのかを説明します。
本連載は、次の順で進みます。本稿は第4回にあたります。
- 第1回 機密の境界で、工程を制作と運用に分ける ― クラウドに出せる作業と、業務PCで閉じる作業
- 第2回 ヒアリングから報告書まで5日間 ― 人とLLMの分担を、工程表で全部見せる
- 第3回 規格(JIS Q 27001/27002)の条文は、そのままではLLMに判定させられない ― 評価者の判断を「部品」に作り込む話
- 第4回 LLMは何を根拠に「合格」と言うのか ― 判定の仕組みには、割り切りがある(本稿)
- 第5回 ローカルLLMに答え方を教え込む、ファインチューニングの実際
- 第6回 採点基準は、測る前に決めておいた ― ISMS規格の全要求で、採点者を置かずに採点する
- 第7回 学習で消えた誤りと、残った誤り
- 第8回 支援ツールとしては使える ― ただし、評価が自動になったとは言わない
はじめにお断りを二つ。ここで扱うのはISMS-AC認定の認証審査ではなく、コンサルティングとしての適合状況評価の支援です。また、これは個人プロジェクトであり、特定の企業・案件とは関係がありません。
判定の中身は5つの工程 ― プログラムが受け持つ2つと、LLMに渡した3つ
業務PCの中のローカルLLMが、規格(JIS Q 27001/27002)の要求を最小単位に分解した一件ごとに、合否を判定し、達していなければ改善案の下書きまで作ります。ただし、この処理のすべてをLLMがこなすわけではありません。処理は5つの工程に分かれ、担い手はプログラムとLLMの二種類です。
| 工程 | 中身 |
|---|---|
| 工程1 設問と要求の対応づけ(プログラム) | どの設問の答えがどの要求の判定に効くかは、部品づくりの段階で対応表に確定してあります。実行時は、その表を参照するだけです。 |
| 工程2 組織の事実の紐づけ補正(LLM) | その要求の判定に関係する組織の事実を選び、過不足を整えます。 |
| 工程3 合否判定(LLM) | 顧客の会社がその要求に達しているか、L3未満かを判定します。 |
| 工程4 ギャップ抽出(プログラム) | 「L3未満」と判定された要求を、達していない管理策のリストに確定します。決められた規則どおりの仕分けです。 |
| 工程5 改善案の生成(LLM) | 達していない要求について、改善案の下書きを作ります。 |
プログラムで実施するか、LLMで実施するかの基準は、単純です。決まった表を参照する、決まった規則で仕分ける、といった手順が固定できる処理はプログラムに、材料を見て判断が要る処理はLLMに渡しました。
LLMの3工程はひとつながり ― 事実を選び、合否を判定し、改善案を下書きする
LLMが担う三つの工程は、別々に動くのではなく、一本の流れとしてつながっています。前の工程の出力が、次の工程の入力になるからです。順に見ていきます。
まず、事実選び(紐づけ補正)です。要求ごとに、その判定に関係する組織の事実(その企業の情報システムの構成や特性、ポリシーといった事実)を選びます。ここには一つ、意図した設計があります。必要な事実を取りこぼすと後から戻せないため、要求と事実を結ぶ共通のキーワード(メタタグ)を手がかりにいったん広めに拾い、そこからLLMが不要な分を削る、という順にしています。取りこぼしは避け、拾いすぎは後で削る、という段取りです。
次に、合否判定です。選んだ事実と、顧客が答えた実施状況(規格が求めることを実際にしているかどうか)をもとに、顧客の会社がその要求に達しているかを判定します。達成の段階は6つ(L0〜L5)。運用され記録が残っている状態(L3)以上を「達している」、そこに届かなければ「L3未満」とする、二値の判定です。顧客回答の「わからない」は、判定に渡る前に入口で「いいえ」に倒してあります(この段階の詳細は前回に書きました)。
最後に、改善案の生成です。未達と確定した要求についてだけ、改善案の下書きを作ります。合否判定と改善案の間ではプログラムが未達を確定するので(工程4)、改善案は達していない要求だけに作られます。
三つを一本につなぐ以上、前の工程の誤りは後ろへ伝わります。関係する事実の選び方を外せば、その材料で下す合否判定も、判定に基づく改善案も、つられてずれます。だからこのツールは、三工程を別々に動かさず、実際の運用と同じ一気通貫で動かします。
指示文の形式は毎回同じ ― 答えの形も、根拠の示し方も、あらかじめ決めて渡す
合否判定でLLMに入力する指示文は、決まった形式、決まった文章構成としています。この形式と構成は、すべての合否判定で維持され、答えの形と、根拠の示し方も規定しています。
LLMに出させる答えは、「達している」「L3未満」「棄権」のいずれか一つと、その根拠です。しかも、決まった項目の形で返させます。実行のたびに答えの形がぶれないので、後から人が、LLMがどの材料を根拠に、どう結論したのかをたどれます。判定の中身を、あとから確かめて疑えるようにする、という設計は、この形式と構成の固定に支えられています。
三つ目のラベル「棄権」は、根拠が足りず断定できないときに、LLMが「追加確認が必要」と返すためのものです。これは、顧客回答の「わからない」とは別物です。顧客の「わからない」は、入口で「いいえ」に倒して未達側として扱う、という前回の話でした。こちらの「棄権」は、LLMが出す判定ラベルの一つで、主に、その要求がその企業に該当するかどうかが不明なときに使います。棄権がどんな役割を果たすかは、次の節でもう一度出てきます。
途中で測り方を変えた ― 数字が実態より良く見えうる代償と、それを受け止める構え
合否判定の方式は、開発の途中で変えました。当初は、ヒアリングの答えだけでなく、その裏にある運用や証跡の有無まで、LLMに確認させる設計でした。ところが試してみると、「示された情報だけでは断定できない」という判定の保留が多発しました。これでは実用に耐えないと判断しました。保留の原因を切り分けて手を入れてもなお構造的に残りました。そこで私は、測り方そのものを変えると決めました。
変更後の判定方式は、こうです。ヒアリングの「はい/いいえ」をそのまま信頼し、運用や記録の証跡の細部を、判定の段階で問い直さない。肯定的な答えで要求の核心を満たしていれば「達している」、否定的なら「L3未満」、その企業に該当するかが不明なときだけ「棄権」とします。
この割り切りには、代償があります。「はい」と答えられた要求は、運用の実態が完全には伴っていなくても「達している」と判定されうる、という点です。たとえば、ウイルス対策の運用はしているが、その記録までは残していない会社で、担当者が「はい」と答え、ヒアリングしている専門家がこれを見逃せば、記録の不足を判定の段階で問い直さず、達成側へ倒します。つまり、数字が実態より良く見えることがあります。この代償は、承知のうえで、あえて引き受けました。数字を良く見せるためではなく、次の構えで受け止められると判断したからです。
- 入口を厳密にする: 各設問には「はい/いいえの判断基準」を添えてあります。決めたことが実際に運用され、記録が残っていれば「はい」。一部でもできていない・決めていない・わからない場合は「いいえ」。中途半端な実施を、回答者自身が正直に「いいえ」へ倒すよう促します。
- 出口は信頼する: 入口で厳密に選ばれた「はい/いいえ」を、判定はそのまま信頼します。証跡の細部を問い直して棄権することはしません。
- 残る棄権は安全弁にする: それでも該当性が不明なものは、断定せずに棄権とし、専門家が引き取って確定します。
入口を厳しくするからこそ、出口で信頼してよい。そうすることで、判定の保留を実用的な水準に抑えつつ、評価としての妥当性を保っています。そして最終的な品質は、入口の厳密さと、このあとの専門家レビューが担保します。
専門家が気づける誤りと、気づけない誤り
もう一つ、割り切りを支えるうえで欠かせない区別があります。LLMが間違えたとき、その間違いに専門家が気づけるかどうかは、間違いの型によって違います。
達しているのに「達していない」と判定して不要な改善案を出した場合、専門家は実施状況を読めば、達成側であることが分かります。改善案の中身が要求からずれている場合も、その記述を読めば分かります。どちらも、成果物を読めば気づける型です。手間は増えますが、顧客が適合状況を誤認することはありません。
これに対し、読んでも気づけない型があります。達していないのに「達している」と判定した場合、その要求には改善案が生成されません。読むものが無いので、専門家は不足があること自体に気づけません。
この二つは、性質がまったく違います。前者は工数の問題ですが、後者は、顧客が受け取る報告書から不足が抜け落ちる問題です。だから、この二つを同じ数字の中で合算しないことにしました。どう分けて測ったかは、第6回で書きます。
次回 ― 『ローカルLLMに答え方を教え込む、ファインチューニングの実際』では、このローカルLLMが、なぜこの仕事をこなせるのかについて記述します。
本稿では、判定の中身を説明してきました。処理は5つの工程に分かれ、LLMが担うのは、事実を選び、合否を判定し、改善案を下書きする、という三つです。三つは一本につながっていて、実際の運用と同じ一気通貫で動きます。そして測り方には、「はい/いいえを信頼する」という割り切りがあり、その代償を、入口の厳密さ・出口の信頼・残る棄権の安全弁という構えで受け止めています。
判定の仕組みを見渡してみると、賢さで押し切っている場所は、ほとんどありません。どこまでを信頼し、どこから先を疑うか。その境目を、賢さではなく仕組みの側に、あらかじめ決めてあるだけです。皆さんの現場でこのツールを使うとしたら、「はい/いいえを信頼する」というこの割り切りを、どこまで受け入れ、どこから自分の目で疑うでしょうか。
ここまで、業務PCの中のローカルLLM(Llama 3.1-8B)が、事実選び・合否判定・改善案の三つをこなす前提で話してきました。けれど、ローカルLLMが、なぜこの仕事をこなせるのか。その答え方は、どこから来たのか。そこには、まだ触れていません。次回は、そこを説明します。
次回予告: 第5回 ローカルLLMに答え方を教え込む、ファインチューニングの実際