社内規程AIの公開前テストは何問必要か――件数より先に決める質問台帳

休暇、経費精算、各種申請のような規程質問では、「まず100問試せばよいのか」と件数を決めたくなります。しかし、質問数だけでは公開可否を判断しにくいものです。規程が短くても、雇用区分、勤続期間、申請期限、上長承認、例外措置などの条件が多ければ、回答の分岐も増えます。反対に、質問を大量に集めても、同じ条件の言い換えばかりでは、危ない分岐を確認できません。

公開前テストの目的は、AIの正答率を見栄えよく示すことではなく、社員に一次回答してよい範囲と、人へ渡すべき範囲を担当者間で合意することです。そのため、最初に決めるべきなのは目標件数ではなく、対象にする規程、想定利用者、回答させない例外です。

例：育児休業の制度説明を対象にする場合でも、「制度の概要」「取得要件」「申請期限」「個別事情を含む例外相談」は同じ扱いにしません。概要は回答候補、要件は根拠箇所つきで回答、例外相談は人事窓口へ案内、といった公開範囲を先に定めます。

まず規程主管者が原本を読み、回答に影響する条件を一枚の分岐表にします。休暇なら、雇用区分、勤続期間、休暇種別、申請予定日、残日数、例外規定の有無などです。経費なら、費目、金額、事前承認、領収書、精算期限、海外利用などを列に置きます。AI運用担当だけで条件を推測せず、規程の解釈責任を持つ人事・総務・経理の担当者が条件を確認します。

質問は、分岐ごとに少なくとも一件作る方法から始めると実務的です。通常条件だけでなく、境界値、複数条件の組み合わせ、必要情報が欠けた質問、規程外の依頼を含めます。これは「20問なら十分」といった固定数ではありません。分岐が12個なら、まず12件に加え、誤答時の影響が大きい条件を重ねた質問を優先して増やす、という考え方です。

例：経費精算では、「出張交通費を精算したい」は通常質問です。「領収書がない」「精算期限を過ぎた」「取引先との会食を含む」「事前承認の有無が書かれていない」は、確認質問または窓口案内が期待されるテスト質問になります。

テスト質問台帳には、質問文と期待回答を並べるだけでなく、「AIが何をしてよいか」を書き分けます。判定は少なくとも、①根拠つきで回答できる、②不足情報を確認する、③規程主管者または担当窓口へ渡す、の三つに分けることを提案します。これにより、答えないことを失敗として扱わず、危険な断定を止められます。

特に必ず含めたいのは、質問者が前提を省いたケースです。テストでは、雇用区分や日付、承認状況など、判断に必要な条件がそろわない質問を意図的に用意します。不足した条件で結論を出すのではなく、何を確認すべきかを返せるかを確認します。質問の意図と違う制度を案内していないかも、規程主管者が見ます。

例：「私は休暇を取れますか」という質問に、AIが制度名を決め打ちして日数まで断定したら不合格候補です。「どの休暇制度についてか、雇用区分と希望日を教えてください」と確認し、必要に応じて人事窓口を示す回答であれば、確認質問として判定できます。

各テストには、期待回答の文章を一字一句固定するより、「含むべき要点」「参照してよい根拠箇所」「断定してはいけない事項」「人へ渡す条件」を記入します。回答文の言い回しではなく、公開可否に必要な判断条件を評価するためです。規程主管者は制度解釈と根拠の対応を、AI運用担当は参照資料の版・回答設定・ログを確認する、という役割分担にすると確認漏れを減らせます。

AWSの自動推論チェックに関する説明では、ソース文書からのルール抽出後に、生成内容をレビューし、実際の利用者の質問を想定したテストを作成・実行する流れが示されています。ただし、これは特定の機能と形式論理による検証を説明したもので、一般的な生成AIが同じ保証を提供するという意味ではありません。通常の社内AIでも、公開前に根拠と想定質問を人が確認するという運用上の考え方は参考になります。 [1]

例：合格基準を「規程第3条の対象者条件と第5条の申請期限を取り違えず、出典箇所を示す。雇用区分が不明なら確認する。個別の適用可否は人事担当へ渡す」と記します。回答が流暢でも、根拠のない例外を約束した場合は要修正です。

全分岐を一度に網羅できない場合は、誤答の影響が大きい順にテストします。給与・休暇残日数・給付・懲戒・個人情報・法令対応のように、誤案内が不利益やトラブルにつながりうる内容は、公開対象から外すか、窓口案内を原則にします。一方、提出先、必要書類、受付時間など、原本に明記され変更頻度も低い案内から限定公開する方法があります。

公開可否は、AI運用担当だけで決めないことを提案します。規程主管者が「制度説明として答えてよい範囲」を承認し、情報システムまたはAI運用担当が「参照資料の版とアクセス権」を確認し、利用部門の代表者が「質問文が現場の言い方になっているか」を見る三者確認にします。未解決の要修正が残る質問は、公開後の課題ではなく、公開範囲を狭める判断材料です。

公開はテストの終了ではありません。問い合わせ窓口へ転送された質問、利用者が回答を訂正した質問、規程改定があった質問を、月次または規程改定時に台帳へ追加します。その際は質問文だけでなく、AIが参照していた規程の版、発見日、修正担当、再テスト日を残します。これにより、同じ誤案内を別の言い回しで繰り返す事態を追いやすくなります。

例：社員から「立替ではなく法人カードの場合はどうなるか」と質問が来て、既存の台帳にカード利用の分岐がなかったとします。規程主管者が根拠と例外を確認し、AI運用担当が資料・設定を修正します。その後、「法人カード」「領収書なし」「期限超過」など関連する複数質問を再テストし、結果を台帳に記録します。

最初の目安としては、通常質問、条件の境界、不足情報、例外・対象外という四種類が、対象業務の主要分岐を覆っているかを確認してください。件数を増やすことより、どの分岐を未確認のまま公開するのかを明示することが、担当者が説明できる公開判断につながります。

以下の項目を一つの台帳にまとめ、規程主管者とAI運用担当が同じ記録を確認できる状態にします。

公開前テスト質問台帳（記入用）

• 対象規程：規程名／版数／施行日／原本の保管場所
• 利用範囲：想定質問者／対象業務／AIが回答してよい範囲／回答しない範囲
• テスト質問：質問文／含まれる前提情報／意図的に欠かした情報
• 期待動作：回答の要点／確認すべき追加情報／窓口へ渡す条件
• 根拠確認：参照条項・手順書箇所／規程主管者名／確認日
• 判定：合格・要修正・対象外／修正理由／修正担当／再テスト日
• 公開後の追加：発見経路／追加質問／規程改定の有無／次回見直し日

出典・参考資料

1. AWS（確認日：2026-10-11）
2. AWS（確認日：2026-10-11）