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

顧客の機密を外に出さずに、ISMSの適合状況評価を支援するツールを、個人で作りました。この連載でその中身を書いてきて、今回は、そのツールがどこまでの成績を出せたのかを示します。

ただ、自分で作ったツールの成績を人に見せるとき、評価する側の読者がまず疑うのは、数字そのものより「どう測ったか」のほうです。分母は適切に取られているか、採点は甘くないか、そもそも誰が点をつけたのか――成績表は、たいていそこから崩されます。だから私は、答え合わせを始める前に、採点の基準のほうを先に固定しました。都合のいい数字が出てから、基準を選び直せないようにするためです。

本稿で出すのは、その固定した基準で、ISMS規格の全要求についてローカルLLMの出力を審査した結果です。先に言うと、学習の達成目標には届きました。ただし、それとは別に置いてある、実運用に供してよいかを見る条件のほうは、満たしていません。この二つは別の基準であり、片方を満たせばもう片方も満たす、という関係にはありません。その数字が何を意味し、何を意味しないのか――どこまでを信用してよく、どこからは信用してはいけないのか――まで含めて示します。

前回は、そのツールに答え方を教え込む、ファインチューニングの話でした。教材はクラウドの教師モデルに作らせましたが、採点はそれとは別です。本稿で答えを突き合わせるのは、モデルの出した答えではなく、測る前に作っておいた表です。

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

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

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

このツールでは、業務PCの中だけで動くローカルLLM(社内に閉じたローカルの言語モデル。Llama 3.1-8B)が、顧客の会社が規格の要求に達しているかどうかを、一件ずつ合否で判定します。そして、達していないと判定した要求には、改善案の下書きを付けます。審査では、この改善案を、第3回で作った達成基準データベース――要求ごとに、何を直し、どの行動を軸にし、どんな証跡を残すのかを書き出しておいた表――と突き合わせて、正答か不正答かを数えました。

採点するのは、最後の改善案だけ ― 途中の誤りも、そこに全部現れるから

このツールの出力は二つあります。「どの要求に達していないか」という合否の判定(以下、ISMSの適合状況の合否判定を「合否判定」と呼びます)と、「ではどう改善すべきか」という改善案です。判定だけを渡されても、何をすればよいかは分かりません。顧客が実際に行動に移せるのは改善案のほうです。ですから、このツールが顧客に届ける価値の中心は改善案にあり、採点の対象も、改善案だけにしました。ローカルLLMが生成した改善案が、達成基準データベースに定められた内容を、その会社の管理策の実施状況と組織の事実を踏まえて、どこまで満たしているか。これを正答率と呼びます。

改善案だけを見れば足りる、と判断したのには理由があります。判定に至るまでの工程は、三つが直列につながっているからです。まず、要求ごとに関係する組織の事実を選ぶ工程。次に、その材料で合否を判定する工程。最後に、その判定で「達していない」となった要求について改善案を下書きする工程。前の工程が誤った材料を選べば、それを使う判定も誤り、誤った判定に基づく改善案も誤ります。逆に言えば、最後の改善案が正しく出ているということは、その前提として、事実選びと合否判定も実質的に正しく働いていた、ということです。

そこで審査では、事実選び・合否判定・改善案の下書きという三つの工程を、実運用とまったく同じ流れで、一気に通して解かせました。前の工程が出した答えを、人が直さずにそのまま次へ渡すことは、前回書いたとおりです。途中で起きた誤りは、実運用と同じように後の工程へ伝わり、最後の改善案に現れます。最終工程の正答率を測れば、三つの工程を通した全体の実用性を、一つの数字で見られる。それが、改善案だけを採点対象にした理由です。

正解は、達成基準データベースに置いた

採点をするには、まず正解が要ります。この設計では、正解を達成基準データベースに置きました。そう置けるように、作ってあるからです。

達成基準データベースでは、ISMS規格の要求を最小単位に分解した「原子要求」として整理し、これに対する設問と、作成する記録類まで整理しています。設問に対する回答と組織の事実を正確に把握し、要求と回答の多対多の関係を適切に整理できるのであれば、正解は達成基準データベースの中に整理されている。そういう設計です。

第3回で紹介した達成基準データベースに、その答えが書いてあります。改善の対象はその要求そのもの、軸にする行動は達成の段階ごとに定めた確認事項、整備する証跡は想定した証跡。要求の番号が決まれば、正解も決まります。

この方法には、はっきりした利点があります。固定した表なので、正解が動きません。正解が測定より先に存在します。都合のいい数字が出てから基準を選び直すことが、構造上できません。さらに、設計と実装の食い違いが測定に現れます。表に書いてあるのは自分たちで決めた規則なので、そのとおりにモデルが動いているかを、直に確かめられるからです。

副次的な効果もありました。成績を測る段階が、業務PCの中だけで完結します。教師モデルの役目は教材を作ることだけで、正解を担いません。ですから、評価用の会社には、クラウドのモデルを一度も走らせていません。

ただし、この表そのものが正しいという保証はありません。本稿の数字は、この表を正しいとしたうえでの数字です。

何をもって正答とするか ― 八つの条件を全部満たしたときだけ

合否の判定は「達している／達していない」の二つに一つなので、正解と機械的に突き合わせられます。一方、改善案は文章です。一字一句が同じかどうかでは測れません。

そこで、改善案は初めから欄に分けて出力させています。現状の不足・その出典・改善の対象・着手の手順・整備する証跡。文章全体をひとまとまりで検索すると、たとえば「現状の不足」の欄に出てきた語を証跡として数えてしまう、といった取り違えが起きます。欄を分けておけば、どこに何が書かれたかを取り違えずに採点できます。

そのうえで、次の八つの条件をすべて満たしたときだけを正答としました。一つでも外せば不正答です。

#	条件	一致(正答)と数える内容
1	形式を守っている	四つの欄(現状の不足・改善の対象・着手の手順・整備する証跡)が欠けていない
2	改善の対象	「改善の対象」に書いた語が、その要求そのものの語と重なる
3	軸にする行動	「着手の手順」に書いた語が、L2とL3の確認事項の両方と重なる
4	整備する証跡	表に挙げた想定証跡を項目に分け、そのすべてが「整備する証跡」に現れる
5	現状の不足	(a)表の文言の写しでない (b)その会社の実施状況か組織の事実の語と重なる (c)その要求を未達にした設問の、何が足りていないかの記述と重なる。三つとも満たす
6	最初の一手が核心	着手の手順の先頭の一手順が、その要求そのものの語と重なる
7	日本語	キリル文字・ハングル・全角数字を含まない
8	出典が実在する	挙げた出典が、その要求で選ばれた事実の中に実在する。事実に該当記載がなければ出典欄が空である

条件2から条件4までは、表に答えがあります。要求の番号が決まれば正解が定まるので、突き合わせは決まりきった手続きで行えます。条件5だけは違います。現状の不足は、その会社の実施状況と組織の事実から書くほかない、唯一の欄だからです。表に答えがありません。そこで、用意された答えとの一致ではなく、書くべき材料から書かれていることを、三つの条件で確かめます。

採点は、改善案に書かれた言葉が、突き合わせる内容の言葉と重なっているかで決めます。

条件2から条件4までは、言葉が完全に同じであることを求めました。突き合わせる内容が達成基準データベースの記述で、ある程度の長さがあるからです。

条件5だけは、言葉の一部が重なっていれば足りることにしました。この条件が突き合わせる内容には、要求を未達にした設問に添えてある「何が足りていないのか」という短い記述が含まれます。改善案は顧客に渡す文書ですから、丁寧な文で書きます。短い記述の言い回しを、そのまま使うことはありません。ここに完全に同じであることを求めると、同じことを述べていても外れてしまいます。たとえば、突き合わせる内容に「資源」とだけ書いてあり、改善案が「必要な資源が確保されていない」と書いている。「資源」は「必要な資源」の中にありますから、重なったと数えます。

この扱いは、条件5だけに限りました。ほかの条件にも広げると、短い言葉が一つ入っているだけで通ることになり、その要求のために書かれたのではない一般的な記述まで、正答に数えてしまうからです。

条件6を、条件3とは別に置いた理由も書いておきます。条件3は、手順の並び全体を見て、必要な行動が入っているかを見ます。どこから着手するかは見ていません。改善事項の一覧を受け取った顧客は、手順の先頭から着手します。先頭に、体制の確認や現状の棚卸しといった、どの要求にも当てはまる前段の作業が置かれていると、必要な行動が全部入っていても、最初に手を動かす作業がその要求の充足に向かいません。その一点だけを見るのが条件6です。実際、四つの要素をすべて満たしながら、この条件だけで不正答になった改善案があります。

逆に、文章の言い回しの違い、着手手順の順序の差、記述の細かさの差は、不一致としません。

採点者は置かない ― 点をつける側に、人もLLMも入れない

八つの条件は、どれも決まった言葉が現れているかどうか、あるいは決まった文字種が混じっていないかどうかを見るだけで決まります。判断の要る箇所がありません。ですから、採点はプログラムが行います。人もLLMも、点をつける側には入れていません。

人が採点しない理由は、第1回で挙げた三つの悩みの一つと同じです。件数が多くなれば、採点する人の基準は動きます。同じ改善案でも、いつ誰が採点したかで結果が変わります。それでは、学習の前と後を比べても、その差が学習によるものなのか、採点の揺れなのか分かりません。

LLMにも採点させません。どのモデルに採点させるかという判断が新たに入り、その判断が正しかったかどうかを確かめる手立てが、こちらにはないからです。正解を固定した表に置いたことの意味は、採点から判断する者を除けることにあります。

同じ出力を同じ手続きで採点すれば、誰がいつ実行しても同じ結果になります。この記事に出す数字は、そういう性質のものです。

もう一つ、条件の厳しさをどう決めたかについても書いておきます。条件3は「L2とL3の確認事項の両方」を、条件4は「想定した証跡をすべて」を求めています。この「両方」「すべて」は、私が採点のときに選んだものではありません。改善案を書かせるときにモデルへ課した義務の言い回しを、そのまま判定の条件にしています。都合の悪い結果が出てから「片方でよいことにする」と緩めることが、構造上できません。

達成目標も、測る前に決めた ― 教師モデルの水準から逆算した80%

達成目標をどこに置くか。これも、測る前に決めました。

第5回で、教師モデルを性能ではなくライセンスで絞った中から選んだ、と書きました。そのうえで、選定した教師モデルが求める出力を実際に作れるかどうかは確かめてあります。学習用の架空の会社5社、985件の要求について、教師モデルに事実選び・合否判定・改善案を通しで解かせ、達成基準データベースに突き合わせて採点しました。正答率は86.1%です。

あわせて、達成基準データベースと設問の記入を担ったOpusにも、同じ入力と同じ指示で同じ処理をさせています。こちらは85.2%でした。信頼区間が重なり、この件数では両者を区別できません。ただし、これで両者の判断力が同等だと言えるわけではありません。判定を誤らなかった要求だけに限って見ると、教師モデルが91.2%、Opusが96.5%で、こちらは区間が重なりません。改善案を書く力は、Opusのほうが明確に上です。正答率で差が出なかったのは、この業務が求める出力の大半が、達成基準データベースを正しく引くことで満たされる形になっているからです。文章を書く力を比べたわけではありませんし、比べてもいません。

この86.1%から、達成目標を逆算しました。

はじめに、前提を一つ置きます。達成基準データベースの完成度を100%と仮定します。この表そのものが正しいことを、私は証明できません。ですから、この表を正しいとしたうえで、そこへどこまで届いたかを示す、という形をとります。

その100%に対して、教師モデルが実際に届いたのは86.1%でした。

そのうえで、ローカルLLMがファインチューニングで向上できる上限を、教師モデルの90%と置きました。ローカルLLMが、教師モデルの届いたところを上回ることを、設計として求めていません。

90%×86.1%＝77.5%。これが、ローカルLLMに求める到達点です。

この77.5%を、厳しい側へ丸めて、達成目標を80%としました。低いほうへ丸めれば目標は甘くなります。そうせず、高いほうへ寄せています。

この達成目標は、下回れば無価値という失格の基準ではありません。下回った分は、最後に専門家のレビューが引き取れれば問題ありません。

数え方は自分に不利な側へ ― 判定を誤った要求も、不正答に数える

採点の分母を、どう取ったか。ここは読者が真っ先に突く点なので、規則と内訳を示します。

対象は、第3回で作った200件の要求です。規格の要求を、合否を言い切れる最小単位まで分けたものです。

まず、それぞれの要求が実際に達しているかどうかは、顧客の回答から機械的に決まります。要求に紐づく設問のうち一つでも「いいえ」があれば、その要求は達していない側です。ここにモデルの判断は入りません。

そのうえで、実際にどうであるかと、ローカルLLMがどう判定したかの組み合わせで、扱いを先に決めておきました。評価に使った会社の200件を当てはめた件数も、あわせて示します。

組み合わせ	件数	扱い
実際も判定も「達していない」	110	八つの条件で採点する
実際は「達していない」／判定は「達している」	0	改善案が無いので、不正答とする
実際は「達している」／判定は「達していない」	5	不要な改善案なので、不正答とする
実際も判定も「達している」	85	改善案が作られないので、母数から外す

母数は、上の三つを足した115件です。いちばん下は、改善案そのものが作られないため、採点のしようがありません。

つまり、判定を誤った要求は、すべて不正答の側に数えています。出すべきものを出さない見逃しも、出さなくてよいものを出す空振りも、どちらも不正答です。分母から都合よく外して数字を良く見せる、ということはしていません。

結果 ― 達成目標は超えた

ファインチューニングを1回実施したローカルLLMで、基準にした架空の会社1社について、200件の要求を通しで解かせました。事実選び・合否判定・改善案の下書きまで、実運用と同じ流れです。その改善案を、八つの条件で採点しました。

前の節の表のとおり、母数は115件です。このうち正答が101件でした。

改善案の正答率＝ 101件 ÷ 115件＝ 87.8%

95%信頼区間は80.6%〜92.6%です。達成目標に置いた80%は、上回りました。この幅は、1社の中で要求ごとのばらつきを見たときのものです。会社が変われば結果がどう動くかは、含んでいません。

判定の側も見ておきます。合否そのものの一致は200件中195件で、97.5%でした。誤った5件はすべて、実際は達しているのに「達していない」と判定した側です。逆向きの誤り、つまり見逃しは0件でした。

一点、置いた前提と実測がずれています。達成目標は、教師モデルの86.1%の90%として導きました。実測の87.8%は、教師モデルの86.1%を上回っています。測った会社も件数も違うので同じ土俵の数字ではありませんが、置いた前提のとおりにはなりませんでした。

最後に、この87.8%がどういう作りの上で出た数字かを書いておきます。判定のとき、顧客の回答を「はい/いいえ」で受け取り、その裏で運用が本当に続いているか、記録が残っているかまでは問い直していません。そのため、顧客が「はい」と答えていれば、実態が伴っていなくても「達している」側に数えられることがあります。これは設計として許容しています。入口のヒアリングで判断基準を示し、中途半端な実施は回答者自身が「いいえ」を選ぶようにしてあるからです。入口を厳しくするから、出口で信頼できる。87.8%は、この作りのうえで測った数字です。

正答率とは別に、もう一つ条件を置いていた

達成目標を超えたので実運用に使ってよい、とはしていません。正答率とは別に、実運用に供してよいかを見る条件を、測る前から置いてあります。

理由は、正答率が性質の違う誤りを足し合わせた数字だからです。母数に入る誤りは四つの型に分かれ、専門家がレビューで気づけるかどうかで、二つに割れます。

誤りの型	内容	レビューで気づけるか
未達の見逃し	実際は達していないのに「達している」と判定した	気づけない
存在しない出典	選ばれていない出典を、不足の根拠に挙げた	気づきにくい
不要な改善案	実際は達しているのに「達していない」と判定した	気づける
改善案の不備	判定は正しいが、八つの条件のどれかを外した	気づける

見逃しは、その要求に改善案が作られません。読むものが無いので、専門家は不足があること自体に気づけません。存在しない出典は、中間の記録と突き合わせなければ判別できません。この二つだけが、専門家のレビューで吸収できない誤りです。顧客が適合状況を誤って受け取る誤りは、ここから出ます。

残る二つは、成果物を読めば分かります。不要な改善案は、実施状況が肯定的であることが読み取れます。改善案の不備は、不足の欄や手順の欄の記述から判別できます。どちらも専門家の手間の問題であって、顧客が現状を誤認する誤りではありません。

そこで、実運用に供する条件を、次の二つとしました。

未達の見逃しが0件であること
存在しない出典を挙げた改善案が0件であること

どちらも、達成基準データベースと中間の記録に突き合わせて機械的に数えられます。ここにも人の判断は入りません。

結果を書きます。基準にした1社では、どちらも0件でした。ただし評価用の会社は3社あり、3社を通算すると、見逃しが1件出ています。したがって、実運用に供する条件は満たしていません。原因は特定してあり、次回に書きます。

次回 ― 『学習で消えた誤りと、残った誤り』では、ファインチューニングで何がどう変わったかについて記述します。

本稿では、採点の基準を測る前に固めたこと、正解を達成基準データベースに置いたこと、採点に人もLLMも入れなかったこと、達成目標を逆算で決めたこと、そして達成目標は超えたが実運用に供する条件は満たしていないことを書いてきました。

採点の基準を先に決めて、後から動かせないようにしておく。手間はかかりますし、都合の悪い数字もそのまま出ることになります。この決め方を、皆さんはどう見るでしょうか。

残るのは、外した14件と、3社で1件出た見逃しです。どこで、なぜ外れたのか。間違いには型があるのか。原因は前の工程から伝わってきたものなのか、それとも改善案を作る工程そのものでつまずいたのか。

そして、ファインチューニングをする前にも、同じ会社を測ってあります。次回は、その前と後を並べます。何が消えて、何が残ったのか。見逃し1件の原因も、そこで明らかにします。

次回予告: 第7回学習で消えた誤りと、残った誤り