ローカルLLMにISMSの適合状況評価を支援させる ― 第7回ファインチューニングで消えた誤りと、残った誤り

Last updated at 2026-09-20Posted at 2026-09-12

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

顧客の機密を外に出さずに、ISMSの適合状況評価を支援するツールを、個人で作りました。前回は、そのツールの成績を出しました。あらかじめ決めておいた達成目標80%に対して、改善案の正答率は87.8%。目標は超えました。ただし、それとは別に置いた実運用に供する条件のほうは、満たしていません。

ただ、87.8%という数字だけでは、ファインチューニングが効いたのかどうかは言えません。もともとそのくらい出るモデルだったのかもしれないからです。だから、学習を実施する前にも、同じ会社・同じ入力で一度測ってあります。本稿は、その前と後を並べるところから始めます。

結果を先に書きます。正答率は47.3%から87.8%へ上がりました。そして、学習前に10件出ていた、実在しない出典を書く誤りは、学習後は0件です。消えた誤りのほうは、はっきりしています。

残ったものもあります。改善案の採点で正答にならなかった14件と、実際は達していないのに「達している」と判定してしまった見逃しが、評価用の会社3社を通算して1件です。14件がどういう型に分かれるのか、それは前の工程から伝わってきた誤りなのか、そして見逃し1件の原因を、本稿で示します。

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

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

このツールでは、業務PCの中だけで動くローカルLLM(社内に閉じたローカルの言語モデル。Llama 3.1-8B)が働きます。本稿では、ファインチューニングを実施していないLlama 3.1-8B(ベースモデル)で測ったものを「学習前」、ファインチューニングを1回実施したモデルで測ったものを「学習後」と呼びます。同じ200件の要求、同じ入力、同じ採点の規則で、学習前と学習後の二回を測り、更に学習後に追加で架空企業2社を評価しました。採点は、規格の要求ごとに何を直し、どの行動を軸にし、どんな証跡を残すのかを書き出しておいた表(達成基準データベース)と突き合わせて、機械的に行います。点をつける側には、人もLLMも入りません。

学習の前と後を、同じ条件で測った

学習の前と後で、こう変わりました。

	学習前	第1回学習後
母数	150件	115件
正答	71件	101件
正答率	47.3%	87.8%

正答率は47.3%から87.8%へ上がりました。ただし、母数が150件から115件へ減っているので、この二つは同じ分母の上に並んだ数字ではありません。分母が減少した理由を説明します。

採点の母数は、実際に達していない要求と、ローカルLLMが「達していない」と判定した要求を合わせたものです。実際は達しているのに「達していない」と誤って判定した要求では、不要な改善案が作られます。これも母数に入れ、不正答として数えます。

学習前の母数150件は、採点した109件に、不要な改善案40件と、見逃し1件を足したものです。学習後の115件は、採点した110件に、不要な改善案5件を足したもので、見逃しは0件でした。

つまり、母数が減少したのは、実際は達しているのに「達していない」と判定した空振りが、40件から5件へ減ったからです。分母が小さくなったこと自体が、判定が良くなった結果です。そのうえで、正答の件数は71件から101件へ増えています。分母が減って、分子が増えました。

消えた誤り ― 存在しない出典は、10件から0件になった

本ツールは、ISMS規格の要求に対して達している/達していないを判定する際に、その企業の事情である組織の事実を要求に紐づけて判定し、達していないと判定した要求について改善案を生成します。

改善案を正解と判定する条件として、以下の8項目を設定しています。

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

このうち、学習の前と後で最も重い差が出たのが、条件8です。

要求によっては、紐づく組織の事実が1件も無いことがあります。このときは、出典欄を空で返すのが正しい答えになります。学習前のモデルは、そこに実在しない出典を書いていました。

	学習前	第1回学習後
紐づく組織の事実が1件も無かった要求	15件	47件
上記のうち、改善案の工程まで進んだ要求	10件	37件
実在しない出典(組織の事実)を書いた件数	10件	0件

紐づく組織の事実が無いにもかかわらず、あるかのように示していたことになります。学習後は0件になりました。

紐づく組織の事実が無い場合には、出典を空で返す。ファインチューニングで最も確実に効いたのは、この点でした。理由ははっきりしています。教師モデルに作らせた、入力と正解の組が、その形になっていたからです。決まった形どおりに返させることは、ファインチューニングがよく効きます。

残った誤り14件には、型がある

学習後、母数115件のうち14件が正答になりませんでした。どこで外したのかを並べます。

件数	外した箇所	外した内容
5	合否判定	実際は達しているのに「達していない」と判定し、不要な改善案を作った
4	改善案「現状の不足」	達成基準データベースの文言をそのまま写していた
1	改善案「現状の不足」	会社の実施状況にも組織の事実にも基づかず、未達の理由とも合っていなかった
2	改善案「着手の手順」	L2の確認事項に触れていなかった
2	改善案「着手の手順」	先頭に、要求そのものの語がなかった

合否判定を外した5件

改善案の書き方の問題ではありません。実際は達している要求に、要らない改善案を作りました。改善案そのものの出来にかかわらず、不正答として数えます。

何を根拠にそう判定したのかを見ると、二つに分かれました。

3件は、実施状況の肯定的な回答を引用したうえで、「要求の核心を満たしていると判断できない」と結んでいます。このツールの判定方針は、ヒアリングの「はい」をそのまま信頼し、運用や記録の細部を判定の段階で問い直さない、というものです。肯定的な回答を引きながら核心を満たさないと結ぶのは、この方針に反する読み方です。

残る2件は、「実施状況に記述がない」と結んでいました。入力には記述があります。読み落としです。

「現状の不足」を外した5件

この欄には、その会社が何を満たせていないのかを書かせています。

4件は、達成基準データベースの文言をそのまま写していました。表の文言を写せば、どの会社にも当てはまる一般論になり、その会社を評価したことになりません。

残る1件は、会社の実施状況にも組織の事実にも基づかず、その要求を未達にした設問の記述とも合っていませんでした。

「着手の手順」を外した4件

この欄には、L2とL3の両方を軸にした行動を書かせています。L2は決めて文書にした段階、L3は運用して証跡が残っている段階です。

2件は、L2の確認事項に触れていませんでした。文書化の話が抜けて、運用の話だけになっていた形です。

残る2件は、手順の先頭に、その要求そのものの語がありませんでした。最初の一手が、要求の核心から外れていたことになります。

どちらの工程が良くなったのか

ここまでの数字は、実際に達していない要求を正しく見つける工程と、見つけた要求に改善案を書く工程の二つの工程の結果が合わさったものです。学習でどちらが良くなったのかを、分けて見ます。

	学習前	第1回学習後
母数	150件	115件
判定を誤った件数	41件	5件
改善案の中身で外した件数	38件	9件
正答	71件	101件

判定の側

200件の要求について、達している/達していないの判定が正解と一致した割合は、79.5%から97.5%になりました。

学習前は、実際は達している90件のうち、40件を「達していない」と判定していました。未達の側へ大きく偏っていたことになります。学習後、この空振りは5件です。

改善案の側

判定を誤らなかった要求について、改善案が8つの条件をすべて満たした割合は、65.1%から91.8%になりました。

学習前に落としていた場所は、前の節で見た型と変わりません。「着手の手順」がL2の確認事項に触れていないものが15件、手順の先頭に要求そのものの語がないものが15件です。学習後は、それぞれ2件になっています。同じ場所で落ちていますが、件数が大きく減りました。

会社を3社に増やして測った

学習後、同じ手順で架空企業2社を追加で評価しました。会社が変われば結果がどう変わるのかを見るためです。

	基準の1社	2社目	3社目
母数	115件	150件	86件
正答	101件	135件	71件
正答率	87.8%	90.0%	82.6%

母数が会社によって違うのは、実際に達していない要求の件数が違うからです。

正答率は82.6%から90.0%の間に収まり、3社とも達成目標の80%は超えました。

ただし、3社では、正答率の差が会社の違いによるものなのか、測定そのもののばらつきなのかを区別できません。会社が変わっても同じ結果が出ると、この測定から言うことはできません。

なお、実際は達していないのに「達している」と判定した見逃しは、3社を通じて1件で、3社目に出ています。この1件を、次の節で扱います。

見逃し1件 ― 決めた規則を、実装していなかった

3社を通じて、実際は達していない要求を「達している」と判定した見逃しが、1件出ました。実際に達していない要求は3社合わせて334件ですから、そのうちの1件です。

見逃しが、他の誤りより重い理由

達していない要求を「達している」と判定すると、その要求には改善案が作られません。成果物には何も現れないので、専門家が読んでも、そこに不足があること自体に気づけません。

逆向きの誤り、つまり達しているのに「達していない」と判定した場合は、要らない改善案が出てきます。読めば分かるので、専門家のレビューで取り除けます。

同じ判定の誤りでも、この二つは重さが違います。だから正答率とは別に、見逃しが0件であることを、実運用に供する条件として置いてありました。

何が起きたか

ヒアリングでは、規格の要求ごとに、はい/いいえで答えられる設問を用意しています。その回答をまとめたものを、判定の材料としてローカルLLMに渡します。

要求のうちには、設問が複数紐づくものがあります。この場合、1問でも「いいえ」があれば、その要求は達していないものとして扱う。そう決めてありました。

見逃しが出た要求には、設問が2つ紐づいていて、一方が「はい」、もう一方が「いいえ」でした。規則にしたがえば「達していない」です。判定は「達している」でした。この規則を、判定の工程を動かすプログラムに実装していなかったためです。

なぜ実装から漏れたのか

ここからは推定です。

この規則は、採点の側にはプログラムとして実装してあります。正解は、実施状況から規則どおりに決まっていました。片側には入っていたわけです。入っている以上、規則は働いていると思っていました。

漏れたのは判定の側です。判定はローカルLLMに任せる工程で、私の意識は指示文に何を書くかへ向いていました。この工程にもプログラムで確定させるべき規則がある、という発想と結びつかなかったのだと考えています。

対策

紐づく設問に1問でも「いいえ」があれば未達を確定させる処理を、判定の工程に置きます。どの設問がどの要求に紐づくかも、各設問が「いいえ」だったかどうかも、手元の材料から分かります。LLMを呼ぶ必要はなく、判定の指示文を変える必要もありません。この修正で、見逃しは0件になります。

実運用に供する条件は二つあり、もう一つは「存在しない出典を挙げた改善案が0件であること」です。こちらは3社を通じて、改善案が挙げた延べ374件の出典がすべて実在し、すでに0件を満たしています。

今回の設計では、この実装は行っていません。AND条件を一つ置けば済むものなので、実運用に用いるプログラムを整理するときに入れます。修正を終えれば、実運用に供する条件は満たされます。

測れていないもの

ヒアリングの回答を、そのまま信頼している

このツールの判定は、ヒアリングの「はい」をそのまま信頼し、運用や記録の細部を判定の段階で問い直さない方針で作ってあります。

この方針には代償があります。たとえば、ウイルス対策の運用はしているが記録までは残していない会社で、担当者が「はい」と答え、ヒアリングした専門家がこれを見逃せば、記録の不足は判定の段階で問い直されず、達成側へ倒れます。

本稿に出した正答率は、実施状況の回答が実態に合っているという前提の上のものです。正解も判定も、同じ回答から決まるからです。回答と実態がずれていれば、正解の側もずれます。

3社では、他社でも同じ結果が出るとは言えない

3社では、正答率の差が会社の違いによるものか、測定のばらつきによるものかを区別できません。

何社あればよいかは試算してあり、10社を目安としています。ただし1社あたり7.5時間から9.0時間を要し、その間は業務PCを占有して他の業務と並行できません。時間の制約から、今回は3社にとどめました。

また、達成目標80%を超えたかどうかの判定は、基準にした1社の結果で行う設計です。追加の2社は、会社が変わると結果がどう動くかを見るための観察として扱っています。

事実選びの工程は、個別に診断していない

本稿では、判定の工程と改善案の工程に分けて見ました。その手前には、要求ごとに使う組織の事実を選び出す工程があります。

この工程については、個別の診断を実施していません。事実選びの誤りが後ろの工程にどれだけ影響したのかは、今回の検討では詳細には分析していません。

次回

本稿では、学習で何が消えて、何が残ったのかを見ました。残った14件には型があり、見逃し1件の原因も、直せば済むものでした。

では、このツールは仕事に使えるのか。次回は、そこを書きます。何を任せられて、何を任せられないのか。実運用へ移す前に済ませておく修正は何か。事実選びの工程をはじめ、これから手を入れる先はどこか。そして、ここまでにかかった費用と、使った環境の全部を出します。

次回予告: - 第8回支援ツールとしては使える ― ただし、評価が自動になったとは言わない

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

ローカルLLMにISMSの適合状況評価を支援させる ― 第7回 ファインチューニングで消えた誤りと、残った誤り