まず結論：通る設計は「機能」より「説明できる境界」
社内RAG（社内資料を探してから答える仕組み）の稟議で止まりやすいのは、モデルや画面の話が先に来て、資料の境界・権限・ログ・試用範囲が後回しになるケースです。情シスや経営が聞きたいのは「漏れないか」「誰が責任を持つか」「小さく始められるか」です。
本記事は、発注側が稟議前に揃える説明の型に絞ります。投入前のチェック項目そのものは、関連のセキュリティコラムとあわせて使ってください。
止まりやすい
通りやすい
情シスが聞きやすい4観点
中堅でも、委託調査やセキュリティ確認で繰り返し出る観点は次の4つです。認証ロゴの有無より、運用の事実が書けるかが聞かれます。
資料の境界
公開OK / 社内 / 機密の区分と、最初に入れる範囲
権限の一致
使える人と、裏で検索される資料の範囲がズレないこと
ログと責任
質問・回答の保存期間、誰が見るか、インシデント時の連絡
社外送信の境界
クラウドLLM等へ送ってよい抜粋と、送らないもの
- 入れる資料を区分し、最初の対象外を一文で書けるか
- 想定ユーザーと資料範囲の対応表があるか
- ログの保存期間と閲覧権限の方針があるか
- 社外APIに送る／送らないの例が共有できるか
稟議用1枚の型
厚い仕様書より、1枚で「何を・誰に・どこまで・どう測るか」が分かると通りやすいです。補助金や他の業務システム稟議と同じく、成功条件と対象外を先に置くのがコツです。
- 01
目的と成功条件
例：FAQの一次回答が出典つきでできる
- 02
試用の範囲
部署・資料セット・期間を限定
- 03
境界と権限
入れない資料／見られる人の表
- 04
ログと拡大条件
保存方針と、次に広げる判断基準
外注に聞くべきこと（機能一覧の前に）
見積比較で機能表だけ並べると、どれも「できます」になりがちです。情シスが通す前提なら、境界・権限・ログ・出典表示・再学習やデータ所在の説明ができるかを先に聞いてください。
後回しにしやすい
- 画面の見た目だけ
- モデル名の新旧
- 全部入りの機能表
先に確認する
- 権限と資料範囲の設計
- 出典表示と更新運用
- ログ・社外送信の方針
次の一歩
いま社内RAGを検討中なら、成功条件・試用範囲・資料区分・権限の対応表を1枚に落とすところから始めてください。投入前の5項目チェックと、権限・ログの運用設計もあわせて揃えると、稟議と実装の会話が同じ地図になります。
よくある質問
RAG投入前チェックリストとの違いは？
チェックリストは資料投入前の安全確認が中心です。本記事は、情シス・経営への説明と稟議で「通る」設計の書き方（境界・権限・ログ・試用範囲）に焦点を当てます。両方揃えると社内合意が早いです。
情シスがいない中堅でも使えますか？
使えます。総務や経営企画がセキュリティ確認を兼ねる会社でも、同じ項目（資料の区分・誰が聞けるか・ログ・社外送信）を1枚にすると、外注比較と社内説明が楽になります。
いきなり全社展開の稟議は避けた方がよいですか？
おすすめしません。FAQや公開マニュアルなど安全な資料と、限定ユーザーから効果を見て、権限が固まってから範囲を広げる方が手戻りが少ないです。
ベンダー選定の前に何を揃えればよいですか？
入れる資料の区分、想定ユーザー、成功条件（例：出典つきで一次回答できる）、対象外、ログの保存方針の下書きがあれば十分です。見積比較は、その型に沿って聞けるようになります。