社内規程を検索しても判断できないとき、先に回答生成を追加すべきでしょうか。今回の架空演習では、検索だけを基本にして、根拠の取り逃しと読解の負担を分けて調べる設計を選びました。
2026年10月18日に行った、全12回の設計演習の第6回をもとにしています。Python 3.14.3と標準ライブラリだけのローカル教材です。検索CLIと10件のテストはCodexが準備し、私は条件を変えた実行、同義語の1語追加、再実行・テスト・説明を行いました。実データ、実認証、実LLMを使った検証ではありません。
「判断できない」の原因を先に分ける
比較するのは、候補段落・文書名・版・有効期間を表示する検索と、その検索結果を根拠にAIが説明を作るRAGです。同じ根拠を渡すなら、回答生成だけを足しても検索の取り逃しは解消しません。
| 調べた状態 | 先に確かめること | 次の手 |
|---|---|---|
| 有効で閲覧可能な根拠があるのに候補に出ない | 言い換え、検索対象、絞り込み条件 | 検索を直す |
| 規程に答えがない、曖昧、矛盾が残る | 文書管理者への確認、適用条件 | 根拠不足として保留する |
| 根拠は取れるが読んで判断する負担が大きい | 読解・照合・修正を含む総時間 | RAGを比較検証する |
検索0件は、根拠が存在しない証明にはなりません。 人が正解の根拠を特定し、その文書が閲覧範囲と有効期間を満たすか、検索候補に入ったかを照合する必要があります。
同義語で広げるのは候補の範囲
教材は本文の部分文字列を照合します。exactは入力語をそのまま使う方式で、文全体の完全一致ではありません。synonymsでは次の辞書で検索語を展開します。
SYNONYM_GROUPS = (("資料", "文書"), ("修正", "改訂"))
実コードの照合部分は次の1行です。textは文書本文、term_groupsは展開した検索語の組です。タイトルは表示用で、検索対象に含めていません。
all(any(term in text for term in group) for group in term_groups)
組の中はOR、組どうしはANDです。「資料 修正」なら、本文に「資料または文書」と「修正または改訂」の両方が必要です。Pythonのanyとallの働きはPython 3.14公式ドキュメントに対応します。
以下は私が実行した結果です。全て架空の利用者・文書で、A3は文書Aの第3版、B1は経理限定の文書Bの第1版を表します。
| 方式 | 利用者の模擬範囲 | 基準日 | 検索語 | 候補 |
|---|---|---|---|---|
| exact | 全社員向け U-101 | 10月18日 | 資料 修正 | 0件 |
| synonyms | 全社員向け U-101 | 10月18日 | 資料 修正 | A3 |
| synonyms | 全社員向け＋経理 U-302 | 10月18日 | 資料 修正 | A3・B1 |
| synonyms | 全社員向け＋経理 U-302 | 11月1日 | 資料 修正 | A4・B1 |
本文にある「文書」「改訂」を入力の「資料」「修正」から取得できました。ただし、同義語登録は業務上の意味が同じだという保証ではありません。たとえば「更新」には契約更新などの別の意味もあります。取得漏れだけでなく、無関係な候補が増えないかも評価対象です。
私は次に、U-101・10月18日・synonymsで「資料 更新」を検索し、0件を確認しました。その後、辞書の第2組だけを次のように変更しました。
# 変更前
("修正", "改訂")
# 変更後
("修正", "改訂", "更新")
同じ条件で再実行するとA3の1件になりました。既存10テストも全件OKでした。テスト表示の0.001秒はテスト一式の実行時間で、検索速度の測定ではありません。既存テストは権限・有効日・不正入力などを確認しますが、辞書追加による誤取得全般や回答品質まで保証しません。
この変更と結果は当日の変更版に対する記録です。その後、私はファイルを追加前に戻したと申告しており、記事作成時の現行辞書にも「更新」はありません。変更後の観測を、現行コードで同じ結果になるという説明には使いません。
権限と有効版は、本文照合の前に絞る
今回の処理順は「模擬権限の確認 → 基準日の有効期間確認 → 本文の語句照合 → 候補表示」です。利用者に見せられない文書を、候補から除く境界を先に置きました。
権限の負例には、Bにだけ存在する架空の目印FIN-FICTION-001を使いました。同じ語・11月1日・synonymsで検索し、U-101は0件、U-302はB1だけになりました。後者を対にすることで、「存在するが、この範囲では返さない」を確認できます。
ただし、--actorは任意に選べる模擬権限です。本人認証でも本番の認可でもありません。実システムでは、認証した利用者と文書のアクセス権を結び付け、権限外の本文をLLMへの入力からも除く設計が必要です。このLLM入力の制御は今回未実装です。
一般的な参考として、Microsoftの文書レベルアクセス制御では、クエリ時の利用者情報と文書側の権限情報による結果の絞り込みが説明されています。今回の教材でAzureや実ACL連携を検証したわけではありません。
版も、番号が最大という理由では選びません。今回の業務条件は「申請日時点で有効な版を使う」です。10月18日の申請には、10月15〜31日が有効期間のA3を使い、11月1日開始のA4は使いません。どの日を基準にするかは業務規則で決めます。検索実行日が常に正しいとは限りません。
候補があっても、答えがあるとは限らない
A3の本文は「社内文書の改訂には、所属部門長の承認が必要です。」です。これは承認者の根拠ですが、「承認に何日かかるか」の根拠はありません。
紙上では、模擬AI出力が「承認は3営業日」と補った場合も検討しました。その日数は採用できません。これは実LLMの出力を観測した結果ではなく、根拠のない補足を見抜くための例です。
検索CLIは回答を生成せず、候補本文と出典情報を返します。RAGを足す場合も、候補の存在と回答に必要な根拠の充足を別に判定し、足りなければ「候補には日数の記載がない」として確認へ回す方針です。
RAGを追加するなら、最終判断まで比較する
今回選んだ基本案は検索のみです。根拠は取得できているのに読解が重い問いを対象に、RAGを足す価値を検証します。
比較するのは、同じ問い・同じ根拠・同じ正確さの条件での検索開始から最終判断までの総作業時間です。AIの生成時間に、根拠照合、誤りの修正、判断不能への対応も加えます。成功分の平均だけでなく、誤判断・判断不能の件数も残します。正確さを保って総時間が減るか、費用と運用負担に見合うかを確認してから追加を判断します。
今回確認したのは、架空データでの候補取得、模擬権限・有効日の分岐、1語追加前後の挙動と既存テストです。実LLM、実認証・ACL、ベクトル／ハイブリッド検索、実データでの精度・総時間・費用・負荷、後日の独力再現は未確認です。
次に行うなら、まず「正解の根拠」「適用する版・閲覧範囲」「根拠不足の問い」を付けた評価用の組を作ります。そのうえで検索の取り逃しと誤取得を測り、読解が負担になる問いだけで回答生成を比較する、という順序にします。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表。AI × Web × 業務自動化の開発・検証に取り組んでいます。
技術選定・品質・運用の判断材料を、検証範囲と制約を示して発信しています。
AI導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。