最初から完璧にデータを整えなくていい

評価AIエージェントを運用しながら、整えるべき情報を見極める

本稿について
本稿は、株式会社GFLOPSがAskDona「Batch Assessment」を提供する中で得た実務上の示唆を、知見共有を目的として整理したものです。特定の顧客、企業、システム、外部サービス、評価結果または運用構成を示すものではありません。記事中の脆弱性評価・システムリスクアセスメントの例は、一般的に起こり得る論点をもとに抽象化した架空のケースです。また、本稿でいう脆弱性評価は、脆弱性スキャンやペネトレーションテストだけではなく、設計書、規程、設定情報、台帳、運用記録などをもとに、弱点や対策状況を確認する評価業務を含みます。

評価AIエージェントの導入を検討すると、早い段階で「データを整備しなければならない」という話が出てきます。

古い資料を整理する。重複文書をなくす。用語を統一する。台帳を作る。メタデータを付ける。証跡を残す。確かに、いずれも重要です。

しかし、導入前からすべてを整えようとすると、別の大規模なデータ整備プロジェクトが始まってしまいます。既存資料を活用するためにAIを導入したはずなのに、「AIを使う前に、まず情報を作り直してください」と言われれば、現場が疲弊するのは当然です。

私たちがBatch Assessmentを提供する中で感じているのは、順序を逆にした方がよいということです。

完璧なデータを待たず、まず現在ある評価表と資料で評価を回す。そこで生じた誤判定、判断不可、不足情報を手掛かりに、必要な情報だけを優先して整える。

データ改善は、評価AIエージェントを利用するために事前に完了させる準備作業ではありません。実際の評価結果から改善対象を絞り込む、継続的なプロセスです。

AskDonaのBatch Assessmentは、既存のExcel評価表とRAGナレッジに登録された規程、設計書、仕様書、台帳、証跡、過去回答などを照合し、項目ごとの一次評価、判断理由、引用箇所、参照元、不足情報を整理します。人は、その結果と根拠を確認し、必要な補足・修正・最終判断を行います。

この「判定結果だけでなく、不足情報まで出す」という構造が、次に整えるべき情報を見つける起点になります。

データ整備には、鶏と卵の問題がある

評価AIエージェントには、判定の根拠となる情報が必要です。一方で、実際に評価を実行しなければ、どの情報が足りないのか、どの表現が誤解を招くのか、どの資料が繰り返し参照されるのかは分かりません。

情報が整っていなければ、安定した評価ができない
                    ↕
評価を実行しなければ、何を整えるべきか分からない

この問題を解消するために、最初から全社的な情報整備の方針を議論することは、必ずしも得策ではありません。実際の評価を通じて不足している情報を具体化しないままでは、何を、どの粒度で、どこまで整えるべきかという議論が抽象化し、整備対象だけが広がりやすいためです。

まずは、現在の評価表と既存資料を使って評価を実行する。その結果から、誤判定が生じた項目、判断できなかった項目、繰り返し不足する前提情報や証跡を特定する。そのうえで、判定への影響が大きく、複数の評価対象で共通して必要になる情報から優先的に整備する方が、現実的かつ効率的です。

実際に使っている評価表を選ぶ
現在存在する関連資料を登録する
代表的な評価対象で一次評価を実行する
誤判定と不足情報の原因を分類する
繰り返し発生し、判定への影響が大きい情報から整える
同じ評価を再実行し、改善を確認する

この順序で進めると、情報整備の範囲を実務上必要なものへ絞れます。

AIが間違えたら、すぐに文書を追加しない

AIの回答が期待と異なると、「RAGのデータが足りない」と考えがちです。しかし、原因がデータ不足とは限りません。

起きていること	最初に確認するもの
判定区分の境界が曖昧	評価選択肢・判定定義
一つの設問に複数条件が混在している	評価項目の書き方
関連情報はあるが違う意味で解釈された	指示プロンプト・用語定義
登録済みの資料が取得されない	RAGの検索範囲・絞り込み
評価対象の前提を誤った	共通の対象情報
文書は存在するが未登録	登録対象・更新運用
対策は実施しているが記録がない	証跡生成・保存プロセス
対策そのものがない	実際の改善対策

AskDonaの活用ガイドでも、まず指示プロンプトと評価定義、次に質問文、最後にデータそのものを見直す順序を推奨しています。

文書を追加する前に、AIが何を誤解したのかを特定することが重要です。そうしなければ、同じ意味の資料が増えるだけで、かえって判断が不安定になることがあります。

最初に整える価値が高いのは、評価対象の共通前提

システムリスクアセスメントを例にすると、AIが頻繁に間違えるのは、対策の詳細より前にある「そもそも何を評価しているか」という前提です。

たとえば、次のような情報です。

内部開発システムか、パッケージ製品か、SaaSか
外部サービスの一部を利用した内部開発システムか
個人情報、顧客情報、機密情報を扱うか
インターネットや外部ネットワークへ接続するか
システム間通信があるか
一般ユーザIDや特権IDをどの仕組みが管理するか
重要性ランクは何か
どの拠点、クラウド、環境に設置されているか
どの外部製品や共通基盤へ依存しているか
対策の責任主体が自社、外部事業者、共同のいずれか

これらを各設計書の断片から毎回推測させると、評価の入口で誤りが起きます。

外部プラットフォームの名称が設計書に多く登場するため、AIが評価対象自体を外部サービスだと捉える。共通規程に個人情報の管理方法が書かれているため、対象システムも個人情報を保有していると捉える。ファイルサーバーであるため、独自にIDを管理していると捉える。

こうした誤りを減らすには、情報システム統括、セキュリティ統括、ITガバナンスなど、全体を俯瞰できる部門が、各評価対象に共通する属性を同じ形式で管理することが有効です。

評価対象マスターの例

項目	内容
評価対象ID	組織内で一意の識別子
正式名称	正式なシステム・サービス名
通称・旧称	現場で使われる名称
所管部門	業務上の責任部門
技術管理部門	開発・運用を担う部門
提供形態	内部開発、SaaS、パッケージ、ハイブリッド
保有情報	個人情報、顧客情報、機密情報等
外部接続	インターネット、閉域網、外部API等
外部依存	外部サービス、業界共通基盤、共通認証基盤
ID管理主体	対象自身、共通基盤、外部サービス
設置環境	本番、開発、検証、災害対策環境
重要性区分	組織の定義に基づくランク
責任分界	自社、外部事業者、共同責任
評価基準日	どの時点の状態を示すか
確認責任者	内容を確認した責任者
最終確認日	情報を確認・更新した日

これは、対策の実施を証明する証跡ではありません。評価項目の適用条件や検索対象を誤らないための、共通の前提情報です。

CSVは「一つの対象を、一つのブロックで理解できる」形にする

AskDonaでCSVを登録する場合、基本的に一行が一つの情報ブロックとして扱われます。そのため、評価対象の共通属性をCSVで管理する際は、同じ対象の主要な条件を横方向にまとめる方が、AIが前提を一度に取得しやすくなります。

分断されやすい例

システム名,項目,値
システムA,提供形態,外部サービスを一部利用した内部開発
システムA,個人情報,あり
システムA,重要性ランク,A
システムA,外部接続,あり
システムA,ID管理主体,共通認証基盤

この形では、それぞれが別の情報ブロックになります。検索結果に「個人情報：あり」の行だけが取得され、提供形態やID管理主体が同時に取得されない可能性があります。

共通前提を一行で取得しやすい例

システムID,システム名,通称,提供形態,個人情報,顧客情報,重要性ランク,外部接続,システム間通信,ID管理主体,外部依存,責任分界,基準日,確認責任者
SYS-A,システムA,Aツール,外部サービスを一部利用した内部開発,あり,なし,A,あり,あり,共通認証基盤,外部サービスX,アプリ設定は自社・基盤運用は事業者,2026-07-01,情報システム部

一行が取得されれば、AIはシステムAの主要な前提条件を同じ文脈で確認できます。

ただし、すべてを一行へ詰め込む必要はありません。一つのシステムが複数の外部サービス、拠点、通信経路、例外を持つ場合は、別のCSVに分け、各行へシステムIDと名称を繰り返し持たせます。

system_master.csv
一つのシステムにつき一行

system_external_services.csv
一つの「システム × 外部サービス」につき一行

system_locations.csv
一つの「システム × 拠点・環境」につき一行

system_interfaces.csv
一つの「システム × 通信経路」につき一行

原則は、一行だけを読んでも、何についての情報か分かることです。

また、空欄は避けます。空欄では「なし」「不明」「未確認」「未入力」「該当なし」を区別できません。

あり
なし
不明
未確認
該当なし

のように、状態を明示しておく方が評価に使いやすくなります。

現場にしか分からない情報は、現場に託す

全体を俯瞰する部門が、すべてのシステムの詳細な設計や変更経緯まで管理することは現実的ではありません。

次のような情報は、開発・運用の現場にしか分からないことがあります。

実際にどのような構成で動いているか
外部サービスのどの機能だけを使っているか
標準設定から何を変更しているか
どの通信経路で、どの情報を送受信しているか
顧客との協議によって何が変わったか
なぜ現在の設計を採用したか
どの制約によって代替方式を採用したか
設計書と現在の設定に差異があるか
一時的な例外や暫定対応が残っているか

これらは現場が記録すべき対象固有の情報です。

ただし、統括部門は何も関与しないのではなく、最低限の記録形式を定めます。

現場で分けて残したい情報

情報	主な内容
現行構成書	現在の構成、接続先、データフロー、利用機能、設定
設計判断記録	検討した選択肢、採用方式、採用理由、前提条件
変更記録	変更前後、変更理由、影響範囲、追加対策
責任分界表	自社、外部事業者、共通基盤の担当範囲
例外記録	例外理由、代替統制、承認者、期限
実施証跡	テスト結果、承認記録、ログ、点検記録、台帳

たとえば顧客との対話によって接続方法を変更した場合、最終的な構成だけでなく、「どの要件を受け、何を変更し、どのリスクに対して何を追加したか」を残します。

後から評価する人やAIが必要とするのは、現在の状態だけではありません。なぜその状態になったかという設計上の文脈も、例外や代替統制を判断する上で重要です。

用語集を無限に増やすより、今後作る情報の言葉をそろえる

同じ意味のものを部門ごとに異なる名称で記録していると、AIはその関係を推測しなければなりません。

たとえば証明書について、組織内で次のような名称が混在しているとします。

公的証明書
外部CA証明書
第三者証明書
商用証明書
正規証明書
部門独自の名称

すべてを用語集へ追加し続けても、新しい表現が生まれるたびに追随が必要です。

現実的には、次の二段階で対応します。

既存文書の別名は、標準用語への対応表で吸収する
新しく作る設計書、台帳、申請書、証跡では、標準用語を使う

たとえば、組織として次の三分類を採用すると決めます。

第三者認証局発行証明書
内部認証局発行証明書
自己署名証明書

既存文書の「公的証明書」「外部CA証明書」「商用証明書」は、どの標準分類へ対応するかを整理します。

重要なのは、用語集を厚くすることだけではありません。今後生成される情報の表現を、少しずつ収束させることです。

担当者しか知らない情報は、評価項目をそのまま聞かない

資料に残っておらず、担当者にしか分からない事実は、最終的には聞き出す必要があります。

ただし、複雑な評価項目をそのまま提示して、

この項目に対応していますか。

と聞いても、安定した回答は得られません。現場担当者は、評価基準の用語や、証拠として必要な粒度まで把握しているとは限らないためです。

たとえば、評価項目が次の内容だとします。

対象通信では、第三者認証局が発行した証明書による所定の改ざん防止対策を実施しているか。

現場への質問は、判定ではなく事実へ分解します。

対象となる通信経路はどれですか
その通信で証明書を使用していますか
証明書はどの機器またはアプリケーションに設定されていますか
発行元はどこですか
第三者認証局、内部認証局、自己署名のどれですか
証明書は何の目的で利用していますか
実際の設定を確認できる資料はありますか
本番、開発、災害対策環境で違いはありますか
例外となる通信経路はありますか
誰が設定・更新を管理していますか

現場には対象固有の事実を回答してもらい、その事実が評価要件に該当するか、証拠として十分かは評価担当者が判断します。

ヒアリング結果も、長い議事録だけに残すのではなく、次のように構造化します。

評価対象：
対象通信：
使用技術：
発行元・提供元：
利用目的：
対象環境：
例外：
確認できる証拠：
情報提供者：
確認者：
確認日：
評価上の取扱い：

ここでは、現場が答えた事実と、評価担当者が行った解釈を分けて記録します。

外部情報の調査はAIに任せられる。ただし適用は人が決める

外部サービス、製品、規格、業界共通基盤に関する情報は、AIによる調査と相性がよい領域です。

AIは、次のような作業を支援できます。

公式仕様や規格の検索
対応バージョンの確認
セキュリティ要件の抽出
バージョン間の変更点の比較
外部サービスが提供する一般機能の整理
内部資料との対応候補の提示

ただし、外部の公式情報だけでは、内部の評価対象がその機能を実際に利用・設定・運用していることまでは証明できません。

人が確認すべきことは次のとおりです。

実際にどの製品・サービスを利用しているか
利用バージョンは何か
どの機能を有効化しているか
標準設定から変更しているか
外部仕様のどの部分が内部の評価対象へ適用されるか
外部側の統制を自社が継承できるか
自社側に追加対策が必要か
自社、外部事業者、共同のどの責任モデルか

役割分担は、次の形が現実的です。

AI
外部の公式仕様・要求事項を調査し、候補を整理する

現場
内部の評価対象が、どの機能をどの設定で利用しているかを確認する

統括・評価部門
外部情報の適用範囲、責任分界、評価上の取扱いを確定する

実施証跡は、評価時ではなく業務の実施時に残す

「実施している」と担当者が説明できても、記録がなければ、第三者は確認できません。

パッチ適用前にテストした
権限を定期的に棚卸しした
責任者の承認を得た
端末を台帳へ登録した
証明書の期限を確認した
例外運用に追加対策を講じた

こうした内容を評価のたびにヒアリングで再構成するのではなく、業務の完了条件へ証跡の保存を組み込みます。

業務	実施時に残す情報
端末導入	端末ID、用途、接続先、申請者、承認者、承認日
パッチ検証	対象バージョン、検証環境、試験結果、承認者
ID棚卸し	対象ID、確認日、確認者、変更・削除結果
証明書更新	発行元、対象、用途、有効期限、更新記録
例外運用	対象、理由、代替統制、承認者、期限
定期点検	対象、点検内容、結果、是正事項、完了日

これはAI向けの文書を増やすことではありません。人による監査、引き継ぎ、顧客説明にも利用できる、業務上必要な記録を適切な時点で残すことです。

「情報なし」を、具体的な改善タスクへ変える

Batch Assessmentで不足情報が示されたら、次のように改善先を分けます。

不足情報の種類	主な対応主体	改善先
共通の前提属性が不足	統括部門	評価対象マスター
設計情報が不足	開発・技術部門	現行構成書
設計理由が不足	開発・業務部門	設計判断記録
変更経緯が不足	開発・案件責任者	変更記録
運用証跡が不足	運用部門	ログ、台帳、承認記録
外部仕様が不足	AI調査＋管理部門	外部公式情報
責任分界が不足	統括・契約・技術部門	責任分界表
用語が不統一	基準所管部門	標準用語・対応表
判定条件が不明	評価基準所管部門	評価仕様
担当者の記憶にしかない	評価担当＋現場	分解ヒアリング
対策そのものがない	業務・技術責任者	改善計画・リスク対応

同じ不足が一つの評価対象で一度だけ起きたなら、個別に対応すればよい場合もあります。

しかし、複数の評価対象で同じ不足が繰り返されるなら、評価対象マスターの項目追加、文書テンプレートの改訂、標準用語の採用、証跡保存の必須化など、組織共通の改善へ引き上げます。

大規模なデータ整備ではなく、小さな改善の循環をつくる

評価AIエージェント導入の進め方は、次のように整理できます。

Phase 1｜現在ある情報で評価を始める

既存の評価表と関連資料を使い、代表的な対象で一次評価を実行します。

Phase 2｜誤判定と不足情報を分類する

指示、評価定義、質問文、検索、共通前提、登録漏れ、証跡、実際の対策を分けます。

Phase 3｜繰り返し不足する前提を整える

提供形態、保有情報、外部接続、重要性区分、外部依存、責任主体など、判定への影響が大きい共通属性を優先します。

Phase 4｜現場の記録テンプレートを整える

現行構成、設計判断、変更、例外、責任分界について、最低限の記録項目を定めます。

Phase 5｜業務の実施時に証跡を残す

評価時に探し直すのではなく、承認、点検、変更、テストなどの完了時に必要な記録が残るようにします。

Phase 6｜再評価し、横展開する

同じ評価を再実行し、改善効果を確認します。複数対象に共通する課題だけを、組織ルールへ反映します。

この進め方であれば、AI導入前に全社データを作り直す必要はありません。

まず評価を回す。そこから、整えるべき情報が見えてくる

評価AIエージェントに必要なのは、最初から完璧に整理されたデータではありません。

必要なのは、実際の評価でどの情報が使われ、どこで前提を誤り、何を確認できず、どの証拠が不足したかを追えることです。

AskDonaのBatch Assessmentは、既存の評価表とRAGナレッジを使って一次評価を実行し、判定結果だけでなく、判断理由、引用、参照元、不足情報を整理します。人はその結果をレビューし、最終判断を行います。

この結果を、単なるAIの正誤確認で終わらせず、次の改善へ戻します。

共通の前提情報は、全体を俯瞰する部門が管理する
対象固有の設計と変更理由は、現場が残す
運用の実施事実は、業務の完了時に証跡として保存する
外部公式情報はAIで調査し、内部への適用は人が確定する
担当者にしかない情報は、評価項目を分解した質問で聞き出す
CSVは、一つの対象の主要条件を同じ行で理解できる形にする
同じ不足が繰り返されたときだけ、組織共通の仕組みへ引き上げる

データ改善は、評価AIエージェントを使う前に終える作業ではありません。評価を実行し、何が判定を妨げたかを確認しながら、必要な情報だけを整えていくプロセスです。

目指すのは、AIのために文書を増やすことではありません。

人にもAIにも、何が事実で、どの対象・範囲・時点についての情報であり、誰が責任を持ち、何を根拠に判断したかを確認できる状態を、無理のない範囲からつくっていくことです。

AskDona Batch Assessmentの詳細は、公式ソリューションページをご覧ください。