社内AIの設計で、最も後戻りが大きいのが権限です。ここを決めずに連携を進めると、動くものはできるのに公開直前に情シスか法務で止まります。そして止まった時点で、設計からやり直しになります。
方式は実質2つしかありません。どちらを選ぶかで、実装コストも運用負荷も変わります。
前提：純正のAIを使うなら、選べない
先に線を引いておきます。この2択が発生するのは、自前で構築する場合だけです。Microsoft 365 Copilot や Google Workspace の Gemini をそのまま使う場合、方式は製品側で固定されています。
Microsoft Copilot は、個々のユーザーが少なくとも表示アクセス許可を持っている組織データのみを表示します。
— Microsoft Learn
Gemini has the same access to Workspace data as you do.
（Geminiは、あなたと同じ範囲のWorkspaceデータにアクセスする）
— Google Workspace ヘルプ
どちらも後述の方式B（権限引き継ぎ型）に相当し、方式Aは選択肢に入りません。「AIが参照する範囲を、こちらで絞りたい」という要望は、純正では実現できません。
この違いが、見積もりの桁を変える
純正で足りるなら、権限設計の工数はゼロです。既存の権限がそのまま効きます。逆に「共通アカウントで全社に同じ範囲を見せたい」と決めた時点で、自前構築が確定します。要件定義でここを曖昧にしたまま各社に見積もりを投げると、前提が違うので比較になりません。
先に確認すべきは「純正で足りるか」です。足りるなら、以下の議論は不要になります。
方式A：共通アカウント型
AIが1つの固定アカウントで動き、そのアカウントが見られる範囲だけを参照します。
- 実装が単純で、連携の設定も1回で済む
- インデックスを全社で共有できるため、応答が速い
- ただし「誰が聞いても同じ範囲」になる
この方式が成立するのは、対象データがもともと全社公開のときです。社内規程、マニュアル、製品情報、公開済みの議事録。ここに限れば、共通アカウント型で困りません。
成立しなくなる瞬間
1件でも見せてはいけないデータが入ると、この方式は選べなくなる
「営業部の商談メモも入れたい」と言われた時点で崩れます。商談メモには他部署に見せない情報が混ざり、共通アカウントはそれを区別できません。後から足すのではなく、最初に「入れたくなるデータ」まで想定してください。
方式B：権限引き継ぎ型
利用者の権限をAIに引き継ぎ、その人が本来アクセスできる範囲だけを検索対象にします。
| 共通アカウント型 | 権限引き継ぎ型 | |
|---|---|---|
| 実装コスト | 低い | 高い |
| 応答速度 | 速い（共有インデックス） | 遅くなりやすい |
| 扱えるデータ | 全社公開のものだけ | 機密を含められる |
| 権限変更への追従 | 不要 | 必要（異動・退職） |
| 監査への説明 | 「範囲を限定した」 | 「既存の権限に従う」 |
監査への説明は、Bのほうが圧倒的に楽
「既存の権限設計をそのまま使っている」と言えるからです。Aの場合は「なぜその範囲に限定したのか」を毎回説明することになります。取引先からの照会でも同じことが起きます。
追従の設計を忘れると事故になる
Bで見落とされがちなのが、権限が変わったときの追従です。異動でアクセス権を外された人が、AI側のインデックスからは引き続き読めてしまう——これは実際に起きます。
異動した人が、AI側からは読めたままになる
これは想定ではなく、実際に起きます。権限の同期頻度は、人事異動の頻度から逆算して決めてください。四半期に一度しか異動がない会社と、毎月動く会社では要件が違います。
同期の設計で決めること
| 決めること | 目安 |
|---|---|
| 同期の頻度 | 異動の頻度に合わせる。月次異動があるなら日次 |
| 退職者の即時反映 | ここは頻度ではなく即時にする |
| インデックスの再構築 | 権限変更時に該当分だけ作り直せるか |
| 同期失敗時の挙動 | 止めるのか、前回の権限で動き続けるのか |
4行目を決めていない構成が多いです。同期が失敗したまま前回の権限で動き続けると、退職者の権限が残ります。迷ったら「止める」に倒してください。
選び方は「データの種類」で決まる
方式の優劣ではなく、扱うデータで自動的に決まります。判断はこの順です。
- 対象データに、部署や役職で見え方が変わるものが含まれるか → 含まれなければA
- 含まれる場合、そのデータを外して成立するか → 成立するならAで始めて、後でBに移行
- 外せないならB
実務でよく採るのは2番
全社公開データだけでAを作り、成果を出してからBに拡張する。最初からBを組むと、公開までが長くなり、その間に社内の熱が冷めます。
Aで始めてBに移るときの注意
移行を前提にするなら、Aの時点で決めておくことがあります。
- インデックスを作り直せる構成にしておく——Bでは権限単位で分ける必要が出る
- データの出所を記録しておく——どのフォルダの何番目のファイルか。後で権限を突き合わせるときに要る
- 「いまは全社公開データのみ」を利用者に伝えておく——期待値がずれると「使えない」評価になる
3つ目が地味に効きます。「商談メモも聞けるはず」と思って使った人は、答えが出ないと「精度が低い」と受け取ります。範囲を先に伝えておけば、その誤解は起きません。
ハイブリッドという選択
1つのAIに両方を持たせることもできます。全社公開データは共有インデックスで速く返し、機密データだけ権限チェックを挟む構成です。応答速度と安全性のバランスは良くなりますが、構成が複雑になるぶん、障害時の切り分けが難しくなります。運用体制と相談してください。
設計前に確認する3つ
- いま権限はどこで管理されているか——Google Workspace、Active Directory、各SaaS個別、のどれか。分散していると引き継ぎ実装が跳ね上がる
- 権限の粒度——部署単位か、プロジェクト単位か、個人単位か。細かいほどBの実装が重い
- 棚卸しされているか——長く運用された権限設定は、退職者や終了プロジェクトが残っていることが多い。AIに引き継ぐ前に棚卸しすると、それ自体が価値になる
棚卸しそれ自体が価値になる
AI導入をきっかけに権限の棚卸しが進み、「そもそも見えてはいけない人が見えていた」が発覚することがあります。これはAIの問題ではなく、もともとあった穴です。AIは検索しやすくしただけで、穴を作ったわけではありません。
権限を棚卸ししたあと、契約条件の側も確認が要ります
誰が会話を見うるか、ログはどこに残るか、いつ消えるか。ChatGPT は Business と Enterprise で、会話を閲覧しうる主体が変わります。主要4サービスを同じ項目で並べた表です。出典と確認日つき。
AとBのどちらから始めるべきか、3分で分かります
扱いたいデータの種類と、いまの権限管理の状況から診断します。設計を始める前に見ておくと、後戻りが減ります。費用はかかりません。
この記事について：純正AIの権限モデルは Microsoft Learn 「Microsoft Copilot のデータ、プライバシー、セキュリティ」および Google Workspace ヘルプ 「What controls Gemini’s access to Workspace data」の記載に基づいています。方式A・方式Bの分類は自前構築を前提とした整理で、製品名を持つ枠組みではありません。同期頻度の目安や「実務でよく採る」といった記述は、公開された統計ではなく設計上の判断です。
