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

ISMS評価の業務では、情報システムの構成や、企業の情報セキュリティポリシー(社内の規則)といった、外に出せない機密情報を扱います。

ISMSの適合状況評価は、地道な作業です。JIS Q 27001/27002(国際規格ISO/IEC 27001/27002に対応する日本産業規格)が求める一つひとつの項目に、企業の現状を突き合わせ、達しているかどうかを判断し、足りないところには改善案を示す。項目の数は多く、判断は評価者の経験に左右されがちです。

ここに、LLM(大規模言語モデル)を使えないか、と考えました。でも、判定に使う情報――管理策の実施状況、情報システムの構成、企業のポリシー――は、どれも顧客の機密です。インターネットにつながるクラウドのLLMには渡せません。「機密だからLLMは使えない」で止まってしまうのか。それとも、別の道があるのか。ここが本連載の出発点です。

この連載は、顧客の機密を外に出さずに、LLMを評価実務のどこまで任せられるかを自分で見極め、ツールを作り、精度を測り、崩れた場所まで確かめた記録です。

本連載は、次の順で進みます。本稿は、その出発点である第1回にあたります。

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

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

悩みは三つ ― 属人化、工数、再現性

ISMSの適合状況評価の作業には、三つの悩みがつきまといます。

一つは、評価できる人が限られ、特定の担当者に作業が集中してしまうこと(属人化)。

二つ目は、一件ごとに多くの手間と時間がかかること(工数)。

三つ目は、同じ会社でも評価する人が違えば結論が変わりうること(再現性)。

この種の作業をしたことがある方なら、心当たりがあるのではないでしょうか。

さらに現場では、顧客から評価に必要な資料が十分に出てこないことも珍しくありません。そうなると、担当者への聞き取り(ヒアリング)を軸に進めることになります。この聞き取りの設問を作り、返ってきた答えを整理する作業が、これまた大きな手間になります。

なぜクラウドの便利なLLMをそのまま使わないのか。理由はシンプルで、冒頭に挙げた機密情報を、インターネットにつながるクラウドのLLMには渡せないからです。

「使えない」で終わらせず、任せられる範囲を自分で決める

三つの悩みを解決するためにたどり着いた答えの骨格はシンプルで、作業の工程を「機密の境界」で二つに分けることでした。

制作(一度だけ作り、全顧客で使い回す部分): 規格の分解、設問づくり、そして架空企業を使った学習データの生成。ここには顧客の機密が一切含まれないので、クラウドのLLMが使えます。
運用(顧客ごとに毎回行う部分): ヒアリング結果という機密を扱う判定。ここは、GPUのない業務PCの中のローカルLLMだけで完結させ、機密を外に出しません。

機密をクラウドに出すのでもなく、LLMを諦めるのでもない。機密を扱わざるを得ない作業を特定して、そこだけをローカルに閉じる。この境界をどこに置くかが、設計全体の核です。

これを一人で組み上げてみることにしました。動機は二つです。一つは、LLMを学んだからには、自分の手で何か形にしてみたかったこと。もう一つは、題材に自分の専門であるISMS評価を選べば、勝手が分かっているぶん、どこまで通せるかを正面から試せると考えたことです。

先に一つだけ。目指したのは評価の自動化ではありません。LLMの出力はあくまで下書きで、最終の判断は専門家が行う。この前提は、連載の最後まで変わりません。

動かすのは、GPUなしの普通の業務PC

機密の使用をローカルに限定すると決めた以上、機密を使う判定を担うLLMは手元の機材で動かすことになります。これは個人のプロジェクトであり、手元にあるのは、専用のサーバーでもGPUを積んだ開発機でもなく、ごく普通の事務用の業務PC一台です。つまり、機密の境界を定めた時点で、確かめることは決まっていました。GPUなしの普通の業務PCで動くローカルLLMに、判定という仕事をどこまで任せられるか、です。

目指すのは、このローカルLLMが、クラウドのLLMと同等の答えを出せるようになることです。そのために、クラウドのLLMに先に問題を解かせ、その答えを教材としてローカルLLMを学習させる方法(ファインチューニング)を用いました。何をどう教え、なぜそれで足りるのかは、第5回、第6回で詳しく書きます。

「LLMは使えるか」を検討した先人はいたが、実務で使える形まで作った記録は見つからなかった

公開に先立って、同じ問題意識の先行の検討を調べました。存在します。三つ挙げます。

国内では、JNSA日本ISMSユーザグループの発表「生成AIで進化する、次世代のISMS運用の形」(井崎友博氏、2025年12月)が、ChatGPT(GPT-4o)を使い、リスク特定とリスク分析の支援を探索的に検討しています。発表自身が、ファインチューニングは実施しておらず今後の課題であること、探索的な研究であり統計的な有意性を担保していないことを明記しており、結論は、補助的なツールにとどまり人間の作業を代替できる水準ではない、というものでした。

海外では、Salmanらの研究「Evaluating LLMs in ISO/IEC 27001 Planning Phase Tasks」(IEEE EuroS&P Workshops、2025年)が、ISO/IEC 27001の計画段階のタスク(適用宣言書の作成・監査計画・チェックリスト生成)について、クラウドのLLM 3種を定量的に比較評価しています。最も精度の高いモデルでも網羅しきれない部分やハルシネーション(事実と異なる、もっともらしい誤り)の課題が残り、現時点では人間の監督を前提とした補助的な利用が望ましい、と結論づけています。

さかのぼると、RiasatとBrachtenによる検討(ユトレヒト大学、2023年、プレプリント)が、ISO 27001の監査・コンサルティングへのLLM導入の可能性を、専門家6名へのインタビューで調べています。報告書作成の効率化に有望としつつ、精度、機密性、人の判断の欠如を課題に挙げました。また2025年半ばには、仮想企業を題材に、クラウドのLLM 3種でISO 27001の監査計画のタスクを試したパイロット研究も報告されています。

並べてみると、方向は揃っています。いずれも「LLMは補助として有望、ただし人間の監督が前提」という慎重な結論で、検討の中心は、探索的な試行や、監査の計画段階のタスクの評価にあります。一方、私が作ったのは、機密を外に出さないローカルLLMに学習で答え方を教え込み、規格の要求の全件について判定から改善案までを一気通貫で動かし、学習の前後で精度を測り、外した箇所の型まで分析する、という組み合わせです。これを実務で使える形まで作った記録は、私が調べた範囲では見つかりませんでした。先人がいなかった、という話ではありません。先人の検討と私の試みは、立っている場所が違う、ということです。

では、何を作ったのか

次回は、このツールを使う仕事の全体像です。顧客案件の始まりから報告書の確定まで、仕事がどう流れ、どこを人が受け持ち、どこをプログラムとLLMに任せたのか。工程の全体を、一枚の流れとしてお見せします。

次回 ― 『ヒアリングから報告書まで5日間 ― 人とLLMの分担を、工程表で全部見せる』では、このツールを使う仕事の全体像について記述します。

次回予告: 第2回ヒアリングから報告書まで5日間 ― 人とLLMの分担を、工程表で全部見せる