結論

AI開発で権限設計を後回しにすると、PoCでは便利に見えても本番で止まります。社内検索AI、問い合わせAI、AIエージェントは、文書やシステムを横断して情報を扱います。利用者が見てよい情報、操作してよい機能、ログを見られる人、管理者ができることを決めないまま進めると、情報漏えいリスク、検収不合格、設計の作り直しが起こります。

権限設計は、開発後に追加する装飾ではありません。対象データ、利用者、部門、役職、顧客、プロジェクト、委託先、退職者の扱いを、RFPと要件定義の段階で確認します。AIが正しく答えることより先に、見てはいけない情報を出さないことを設計する必要があります。

よくある失敗の流れ

最初の失敗は、PoC用に集めた文書を全員が見られる前提で取り込むことです。少人数の検証では問題が見えませんが、本番では部門限定資料、顧客別資料、人事情報、契約条件、未公開情報が混ざります。AIが文書を検索できても、利用者ごとの権限を再現できなければ本番に出せません。

次の失敗は、AIエージェントの操作権限を曖昧にすることです。チケットを作るだけなのか、ステータスを変更するのか、メールを送るのか、外部システムへ登録するのかで、必要な承認とログが変わります。操作できる範囲を後から制限しようとすると、設計変更が大きくなります。

発注前に確認する権限

権限は、既存システムに合わせるのか、AI側で別に管理するのかを決めます。既存権限を引き継ぐ場合は、同期方法、同期頻度、失敗時の扱いを確認します。別管理にする場合は、運用負荷と漏れのリスクを見積もります。

RFPに入れるべき項目

RFPには、権限の一覧だけでなく、検証方法を書きます。権限あり利用者、権限なし利用者、異動直後の利用者、外部委託先、管理者などのテストケースを用意します。検収では、権限外文書が回答に混ざらないこと、根拠リンクも権限外へ飛ばないこと、ログに適切に残ることを確認します。

AIエージェントの場合は、操作の前に人間承認を挟むかどうかを書きます。外部送信、顧客データ更新、契約関連の変更、支払い関連の処理は、PoC段階では下書きや通知にとどめる方が安全です。

作り直しを防ぐ進め方

権限設計は、最初から完璧に作るより、対象範囲を絞って検証します。部門を1つに限定し、文書種別を絞り、操作を下書きまでにすると、権限の穴を見つけやすくなります。PoCで全社横断を目指すより、権限モデルを確認する方が本番移行に役立ちます。

また、権限と評価を分けないことが重要です。AIの回答品質テストに、権限外の質問、古い文書、部門限定資料、ログ確認を入れます。権限テストを別扱いにすると、回答品質だけ合格して本番で止まることがあります。

図解で確認するポイント

この記事の画像は、利用者、文書、操作、権限同期、ログ、レビューを確認する流れを示す図解です。画像内にタイトルや売り文句を入れず、AI開発で権限設計漏れを防ぐ観点を把握できるようにしています。

AllAI内での次の行動

標準SaaSで権限管理できるか確認する場合はAI/SaaS比較を見ます。独自権限や複雑な社内文書連携が必要な場合はAI開発会社一覧で候補を探し、権限テストをRFPへ入れます。

FAQ

Q. 権限設計はPoC後に考えてもよいですか? A. 本番利用を想定するならPoC前に考えるべきです。後回しにすると検収や本番移行で作り直しが起きやすくなります。

Q. 権限設計で最初に確認することは何ですか? A. 利用者、文書、操作、管理者、ログ、委託先アクセス、異動・退職時の反映です。

Q. 検収では何をテストしますか? A. 権限あり/なし利用者、異動後利用者、部門限定資料、根拠リンク、操作ログ、外部送信の制御を確認します。

出典:

• OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/ (確認日: 2026-07-08)
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework (確認日: 2026-07-08)
• 個人情報保護委員会: https://www.ppc.go.jp/ (確認日: 2026-07-08)

次に見る

• AI開発会社一覧
• 社内ナレッジ検索AI開発RFPの書き方
• 内部監査・AIリスク担当向け学習ロードマップ