評価AIエージェントが「情報ないから判断できません」と返したとき、それは単に登録データが足りないという意味なのでしょうか。
株式会社GFLOPSは、AskDona「Batch Assessment」を提供する中で、情報不足には複数の原因があり、必要な改善もそれぞれ異なると考えるようになりました。
本稿では、評価AIエージェントを利用する前に大規模なデータ整備を完了させるのではなく、まず既存の情報で評価を実行し、その結果から整えるべき情報を具体化するという進め方を整理します。
本稿について
本稿は、株式会社GFLOPSがAskDona「Batch Assessment」を提供する中で得た実務上の示唆を、知見共有を目的として整理したものです。特定の顧客、企業、システム、外部サービス、評価結果または運用構成を示すものではありません。本文中の例は、脆弱性評価やセキュリティ対策の実施状況確認を起点に、RAGを用いた評価AIエージェントで情報不足が生じた場合の考え方を一般化したものです。 また、本稿でいう「脆弱性評価」は、技術的なスキャンだけを指すものではありません。設計書、仕様書、規程、設定情報、運用記録などをもとに、セキュリティ上の弱点や対策状況を確認し、改善につなげる評価業務を広く含めています。
Batch Assessmentとは何か
評価、監査、審査、チェックシート対応などの業務では、多数の確認項目について、規程、設計書、仕様書、台帳、契約書、実施記録などを探し、評価基準と照らし合わせる必要があります。
AskDonaのBatch Assessmentは、この一連の確認業務において、AIエージェントが評価項目ごとに関連資料を探し、一次評価、判断理由、引用箇所、参照元、不足情報を整理する機能です。
既存のExcel評価表を利用し、AskDonaのRAGナレッジに登録された文書や証跡を参照できます。AIが整理した結果を人がレビューし、必要な補足や修正を行ったうえで、最終判断を確定することを前提としています。
Batch Assessmentの対象は、特定の評価業務に限られません。たとえば、次のような業務に利用できます。
- システムリスクアセスメント
- 情報セキュリティ評価
- 委託先・ベンダー評価
- 内部統制や監査項目の確認
- 品質監査や仕様適合の確認
- 契約書や申請書の確認
- 顧客質問票や各種チェックシートへの回答
いずれも、複数の資料を確認し、評価基準に照らして、根拠を伴う一次判断を作るという共通の構造を持っています。
本稿では、システムリスクアセスメントを例に考える
本稿では、幅広い評価業務の中から、システムリスクアセスメントにおけるセキュリティ対策の確認を例に、情報不足が発生する理由と、そこからデータ改善の糸口を見つける考え方を整理します。
ここでいう「脆弱性評価」は、ツールによる技術的なスキャンだけを指すものではありません。設計書、規程、仕様書、構成資料、設定情報、台帳、ログ、テスト結果などをもとに、対象システムの弱点や対策状況を確認し、評価項目に沿って判断する業務を広く含めています。
この例を取り上げるのは、システムリスクアセスメントだけが特別に難しいからではありません。評価業務で起こる次のような論点が、一つの事例の中に現れやすいためです。
- 一つの設問に複数の確認条件が含まれる
- 「適切」「公的」「同等」「管理している」など、言葉の範囲が一意ではない
- 主語、対象範囲、評価時点が文章上では省略される
- 方針が定められていることと、実際に対策が行われていることを区別する必要がある
- 規程、設計書、設定資料、台帳、ログなど、異なる種類の証拠を確認する必要がある
- 内部で実装した機能と、外部サービスや共通基盤が提供する機能を分ける必要がある
- 情報不足、未対応、対象外を区別する必要がある
- 複数の確認結果を、一つの評価結果へ集約する必要がある
日本語による要求事項の解釈、評価対象の切り分け、証拠の確認、技術的な理解、組織固有の判断が重なるため、AIが何を必要とし、どこで前提を誤り、何が不足情報として残るのかを具体的に考える例として適しています。
ここで見えてくる構造は、委託先評価、品質評価、契約確認、顧客質問票、法令・規格への適合確認など、文書や証跡をもとに判断する業務にも共通します。
評価AIエージェントは、どのように一次評価を行うのか
Batch Assessmentでは、まず既存の評価表から確認項目を取り込みます。
次に、各項目について、設定された判定定義と実行プロンプトに従い、RAGナレッジから関連する文書・証跡を検索します。取得した情報と評価項目を照合し、確認できた事実をもとに一次評価を作成します。
評価項目を確認する
↓
必要な条件や要求事項を整理する
↓
RAGから関連する文書・証跡を検索する
↓
評価項目と取得した情報を照合する
↓
判定案・判断理由・引用・参照元・不足情報を整理する
↓
人が根拠をレビューし、最終判断を行うBatch Assessmentでは、判定区分の名称、数、定義をアセスメントごとに設定できます。「対応済」「未対応」「対象外」「判断不可」に限らず、業務に応じて「情報なし」「証跡不足」「要追加確認」「条件付き対応」などを設けることもできます。
また、何を確認できた場合に各判定とするか、どの証拠を必要とするか、複数条件をどう集約するか、情報不足をどう扱うかを定義できます。資料を確認する順序や、規程と実施証跡の区別、対象範囲・評価時点の確認、禁止する推論も、アセスメント全体のプロンプトとして柔軟に設定できます。
必要な記載が見つかり、設定された判定条件を満たすことを確認できれば、AIは根拠を示した一次評価を作成できます。
一方、判定に必要な情報を確認できなかった場合には、設定された定義に応じて、「情報なし」「証跡不足」「判断不可」などの結果になります。
AIが確認できないことと、情報が存在しないことは違う
ここで注意すべきなのは、AIが情報を確認できなかったことと、組織にその情報が存在しないことは同じではないという点です。
AskDonaは、RAGへ登録されたデータから関連情報を検索し、根拠に基づく回答を生成する精度を重視して設計されています。一方で、どれだけ検索性能が高くても、今回のアセスメントで指定された情報源の外にある情報や、評価対象との関係を確定する前提が存在しない情報を、判定根拠として作り出すことはできません。
AIが厳密に言えるのは、次の範囲です。
指定されたRAGデータベース、固定参照文書、参照範囲、検索条件の中では、評価項目を裏付ける情報を確認できなかった。
その背景には、たとえば次の状態があります。
- 必要な情報はRAGに登録されているが、今回のアセスメントで選択したデータベース、固定参照文書、絞り込み条件に含まれていない
- 文書内の対象名、版、環境、主語が曖昧で、評価対象に関する証拠として確定できない
- 組織内には資料があるが、RAGへ登録されていない
- 対策は行われているが、実施記録が作成・保存されていない
- 対策そのものがまだ実施されていない
- そもそも評価対象ではなく、該当する証跡を作る必要がない
- 内部資料ではなく、外部の公式情報を確認すべき項目である
- 外部情報と内部での利用・実装状況を結び付ける前提情報が不足している
- 何を確認すれば判定できるのかという評価定義自体が不足している
- 対象固有の構成や変更経緯が、担当者の中にしか残っていない
表面上はいずれも「必要な情報を確認できなかった」という同じ結果に見えます。しかし、必要な改善は異なります。
「情報なし」は評価の終点ではありません。どこに不足があり、誰が何を見直すべきかを切り分ける起点です。
情報不足を、四つの改善領域に分ける
情報が確認できないときは、原因を一つに決めつけず、次の四つに分けると、改善先を整理しやすくなります。
| 改善領域 | 起きていること | 主な改善 |
|---|---|---|
| 1. 評価設計の不足 | 何を確認すれば判定できるかが曖昧 | 用語、適用条件、証拠要件、判定ルールを定める |
| 2. 検索・登録の不足 | 情報は存在するが、今回の評価で利用できない | 参照範囲、固定参照、登録状況、文書構造、対象との対応を見直す |
| 3. 証跡・対策の不足 | 記録がない、または対策自体が実施されていない | 証跡を残す運用、実際の設定・対策を改善する |
| 4. 情報源・責任範囲の不足 | 内部と外部のどちらを確認すべきか、誰が対策を担うかが不明 | 評価対象の前提、外部依存、適用関係、責任分界を整理する |
1. 評価設計の不足
そもそも、何を確認すれば判定できるのかが定まっていない状態です。
- 用語の意味や範囲が曖昧
- 評価対象となる条件が明確でない
- 対応済とするために必要な証拠が定義されていない
- 複数条件の集約方法が決まっていない
- 情報不足時にどの判定を選ぶかが定まっていない
この場合、資料を追加しても判定は安定しません。最初に見直すべきなのは、判定定義、評価項目の書き方、アセスメント全体のプロンプトです。
たとえば、「証明書を使用している」という記載だけで「公的証明書を使用している」と判定してよいのか、規程に実施方針があれば対応済とするのか、設定や実施記録まで必要なのかを明確にします。
2. 検索・登録の不足
必要な情報は存在するものの、今回のアセスメントで利用できる状態になっていないケースです。
ここでいう検索・登録の不足は、単純にRAGの検索性能が低いという意味ではありません。AskDonaの検索性能を生かすためにも、今回の評価へ、どの情報を、どのまとまりで、どの範囲から渡すかを適切に設定する必要があります。
たとえば、次のような原因があります。
- アセスメントで選択したRAGデータベースが適切でない
- 毎回確認すべき資料が固定参照文書に設定されていない
- 対象、部署、カテゴリなどの絞り込み条件が実態と一致していない
- 正式名称、通称、旧称の関係が分からず、対象との同一性を確認できない
- 現行版ではなく、旧版や別環境の文書が登録されている
- 組織内には資料があるが、RAGへ登録されていない
- 一覧データが細かく分かれすぎ、同じ対象の前提条件を一緒に取得できない
CSVの一行が一つの情報ブロックとして登録される場合、システムAの提供形態、保有情報、重要性区分、外部接続、ID管理主体など、評価の入口で同時に必要になる主要条件は、同じ行で理解できる形にまとめる方が有効です。
システムID,システム名,提供形態,個人情報,重要性区分,外部接続,ID管理主体,評価基準日
SYS-A,システムA,外部サービスを一部利用した内部開発,あり,A,あり,共通認証基盤,2026-07-01一方、複数拠点、複数の外部サービス、複数の通信経路など、一対多になる情報は別の一覧へ分け、各行にシステムIDとシステム名を持たせます。一行だけを取得しても、何についての情報かを理解できる状態にすることが重要です。
3. 証跡・対策の不足
登録するべき資料が、そもそも存在しないケースです。ただし、ここでも状態を分ける必要があります。
対策は実施しているが、証跡がない
定期確認や承認は行われていても、実施記録や承認履歴が保存されていない状態です。
この場合に必要なのは、RAGへの追加登録ではなく、業務の実施時に証跡を作成・保存する仕組みです。
対策そのものが実施されていない
要求される設定、承認、確認、点検などが行われていないため、証跡も存在しない状態です。
この場合は、データではなく、実際の対策や運用を改善する必要があります。
評価対象ではない
評価項目の適用条件に該当しないため、対応する証跡を作成する必要がないケースです。
この場合は、「情報がない」ことを対象外の根拠にするのではなく、対象外であることを示す前提情報を整理します。
4. 情報源・責任範囲の不足
外部サービス、製品、規格、業界共通の仕組みが関係する場合、必要な情報が内部資料だけにあるとは限りません。
この領域で確認すべきなのは、外部情報を追加すること自体ではなく、何を外部の公式情報から確認し、何を内部の設計・設定・運用から確認するのか、その対策を誰が担うのかを明らかにすることです。
- 外部サービスの公式要件や機能を確認する必要があるか
- 評価対象が実際に利用する機能、バージョン、設定を内部資料から確認できるか
- 外部側と内部側の責任分界が明確か
- 外部の要件や機能が、評価対象へ適用されることを確認できるか
- 自社、外部事業者、共同のどこが対策を担うか
外部の公式資料は、外部サービスの要件や機能を示せます。しかし、その機能が内部の評価対象で利用・設定・運用されていることまでは示しません。反対に、内部資料だけでは、外部規格や製品の正式な要求内容を確定できない場合があります。
そのため、情報源と責任範囲を整理し、外部情報と内部の利用状況を接続できない場合は、その前提を不足情報として扱います。
四つの改善領域に分けることで、情報を追加する前に、評価仕様、参照範囲、証跡、実際の対策のどこを見直すべきかが明確になります。
まず評価を回す。そこから、整えるべき情報が見えてくる
データ活用には、次のような鶏卵の問題があります。
情報が整っていなければ、安定した評価ができない
↕
評価を実行しなければ、何を整えるべきか分からないこの問題を解消するために、最初から全社的な情報整備の方針を議論することは、必ずしも得策ではありません。
実際の評価結果という具体的な材料がないままでは、何を、どの粒度で、どこまで整えるべきかという議論が抽象化し、整備対象だけが広がりやすいためです。
まずは、現在の評価表と既存資料を使って評価を実行します。その結果から、次を確認します。
- どの情報が正しく利用されたか
- どの項目で前提を誤ったか
- どの証拠では判定に足りなかったか
- どの項目で担当者への確認が必要になったか
- どの不足が複数の評価対象で繰り返されているか
そのうえで、判定への影響が大きく、複数の評価対象で共通して必要になる情報から優先的に整えます。
同じ不足が一つの対象だけで発生したのであれば、対象固有の資料や証跡を補います。複数の対象で繰り返すのであれば、評価対象マスターの項目追加、共通テンプレート、標準用語、証跡保存の業務フローなど、組織共通の仕組みへ引き上げます。
データ改善は、評価AIエージェントを使う前に終える準備作業ではありません。評価を実行し、何が判定を妨げたかを確認しながら、必要な改善を絞り込む継続的なプロセスです。
Batch Assessmentで、情報不足を改善につなげる
Batch Assessmentでは、参照するRAGデータベース、常に確認する固定参照文書、メタデータによる参照範囲を、アセスメントごとに設定できます。
また、判定区分の名称、数、定義を自由に設定し、アセスメント全体の実行プロンプトも業務に合わせて柔軟に設計できます。
AIは、その設定に基づいて、項目ごとの一次評価、判断理由、引用、参照元、不足情報を整理します。人は、結果だけでなく根拠を確認し、必要に応じて補足・修正したうえで最終判断を行います。
ここで目指しているのは、不足する情報をAIが推測で埋めることではありません。
- 何を確認できたか
- 何を確認できなかったか
- どの情報源を参照したか
- どの前提が不足しているか
- どこから人の判断が必要か
を追える状態にすることです。
評価結果を単なるAIの正誤確認で終わらせず、評価設計、検索・登録、証跡・対策、情報源・責任範囲のどこを見直すべきかへ戻すことで、評価と情報改善を継続的につなげられます。
おわりに
評価AIエージェントに必要なのは、最初から完璧に整理されたデータではありません。
まず既存の評価表と資料で評価を実行し、どの情報が使われ、どこで前提を誤り、何を確認できず、どの証拠が不足したかを追えることが重要です。
その結果を手掛かりに、評価仕様、参照範囲、登録データ、証跡の残し方、実際の対策のうち、判定を妨げている箇所から改善します。個別の不足が複数の評価対象で繰り返される場合に、共通の入力項目、文書テンプレート、証跡保存ルールなどへ引き上げます。
最初から大規模な情報整備を目指すのではなく、実際の評価で見えてきた不足から、必要性の高い改善を無理のない範囲で進めることが、継続可能なデータ改善につながると私たちは考えています。