AIに社内データを読ませる前に、企業が設計すべきこと——AI基盤の権限・データ・運用設計

フロンティアモデルは「高性能な道具」であると同時に「強い権限」でもある

AWSの記事で特に重要なのは、最新のフロンティアモデルには、サイバーセキュリティ領域で強力な能力があると指摘している点です。防御側にとっては、脆弱性調査やセキュリティ強化に役立つ可能性があります。一方で、攻撃者にとっても高度な能力を得る手段になり得ます。

これは、企業のAI活用にもそのまま当てはまります。

AIは単なる検索ツールではありません。AIは、情報を読むだけでなく、要約し、抽出し、組み合わせ、推論し、場合によっては操作まで実行できます。つまり、AIに社内データを渡すということは、単に「閲覧権限を与える」というよりも、情報を再構成する能力を与えることに近いです。

たとえば、人間がDrive上で複数の文書を見られるとしても、普通は全部を横断的に読んで、関係性を整理し、要点をまとめることは簡単ではありません。しかしAIはそれができます。ここに、AIならではのリスクがあります。

AI導入でまず考えるべきこと

企業AI基盤を設計するとき、最初に考えるべきことは「どのモデルを使うか」ではありません。先に決めるべきなのは、次のような設計です。

• どのデータをAI利用対象にするか／対象外にするか
• 誰の権限でAIがデータを見るのか
• 個人情報や機密情報はどう扱うのか
• 危険な依頼や操作をどう止めるのか
• AIが出した結果を誰が確認するのか
• ログや監査をどう残すのか

つまり、AI基盤に必要なのは、LLMを呼び出す処理だけではありません。必要なのは、AIに渡す前後の制御設計です。イメージとしては、次のような構成です。

ユーザー
    ↓
  認証・権限確認
    ↓
  データ分類
    ↓
  リクエスト分類
    ↓
  ポリシー判定
    ↓
  モデル選択・ツール制御
    ↓
  LLM実行
    ↓
  出力チェック
    ↓
  ログ・監査・人間レビュー

LLMを直接呼ぶのではなく、その前に「AI Gateway」や「Policy Layer」のような層を置くことが重要です。

Driveの権限をAIに委譲する設計はわかりやすい

社内AIでよく出てくるのが、Google DriveやSharePointなどのストレージにある文書をAIに参照させる設計です。このとき、最もわかりやすい考え方は、

人間が見られるものだけを、AIも見られる

という設計です。たとえば、営業部の人は営業部のフォルダだけ見られる。人事フォルダは見られない。その場合、AIも営業部の人に対しては営業部の情報だけを参照し、人事情報は参照しない。

これは非常に説明しやすいです。「AIは、あなたのDrive権限を超えて情報を見ません」と言い切れる。この設計は、企業AI基盤の初期方針としてかなり自然です。

GoogleのGemini Enterpriseでも、企業データに対する検索やアシスタント機能について、権限を考慮したアクセス、つまり permission-aware access を提供すると説明されています。Gemini Enterpriseは、Google WorkspaceやSharePoint、ServiceNowなどのデータソースに接続し、ユーザーがアクセスできる範囲に応じて企業情報を検索・活用するためのプラットフォームです。

つまり、既存のストレージ権限をAIの参照範囲に使うという考え方は、かなり自然な方向性です。ただし、これだけでは不十分です。

「Driveで見られる」ことと「AIに読ませてよい」ことは違う

ここが一番重要です。Drive上で閲覧権限があることと、AIに処理させてよいことは同じではありません。

たとえば、社長や人事担当者は、給与情報、履歴書、評価情報、労務情報をDriveで見られるかもしれません。しかし、それをAIに自由に読ませてよいかというと、別問題です。人間が必要に応じて見ることと、AIが横断的に検索・要約・抽出できることには大きな差があります。

そのため、実務上は次のような二層構造で考えるのが安全です。

つまり、AIが参照できる条件はこうです。

ユーザーがDrive上で閲覧権限を持っている

かつ、そのファイルやフォルダがAI利用OKである

Drive権限は必要条件ですが、それだけで十分条件にしない方がよいです。

AI利用区分を設計する

企業AI基盤では、データをざっくり次のように分類するとわかりやすいです。

たとえば、以下のようなイメージです。

10_AI-USE_社内マニュアル
  20_AI-USE_会議議事録
  30_AI-USE_営業ナレッジ

  70_AI-LIMITED_顧客別資料
  80_AI-LIMITED_契約関連

  90_AI-NO_人事労務
  91_AI-NO_個人情報
  99_AI-NO_認証情報

初期運用では、フォルダ名にAI利用区分を入れるだけでも、社内の意識づけとしては有効です。ただし注意点があります。

Gemini標準機能では、フォルダ名だけでAI権限管理はできない

Google WorkspaceのGeminiのように、既存のWorkspaceデータへ標準機能としてアクセスするAIを使う場合、フォルダ名だけでAI権限を制御することは基本的にできません。フォルダ名に AI-NO と書いても、Geminiがそれを自動的に「AI利用禁止」と解釈してくれるわけではありません。

Gemini Enterpriseでは、データソースのアクセス制御や、文書レベルのアクセス制御を設定できる仕組みがあります。カスタムコネクタでもACLやIDマッピングにより、ユーザーが見られるコンテンツを制限する設計が説明されています。ただし、ここでいうアクセス制御は基本的に「そのユーザーが、その文書にアクセスできるか」の話です。

一方で、私たちが企業AI基盤で考えたいのは、

そのユーザーは、人間として文書を見てよい

でも、AIに処理させてよいかは別

という制御です。これは通常の閲覧権限とは別の問題です。たとえば、

• 人事担当者は履歴書を見られる。でもAIに履歴書を自由に要約させたくない
• 社長は給与情報を見られる。でもAIに全社員の給与傾向をまとめさせたくない

というケースです。このような制御をしたい場合、Gemini標準機能だけでは限界があります。

自作AI基盤なら、より細かく制御できる

一方で、自作RAGや自作AIアプリを作る場合は、フォルダ名やメタ情報をもとにAI利用可否を判定できます。たとえば、「ユーザーがDriveで閲覧可能、かつフォルダがAI-USE」のときだけAIに渡す、という制御ができます。さらに、次のようなルールも実装できます。

• AI-LIMITEDの場合は、マスキング後のみ利用可能
• AI-NOの場合は、検索対象から除外
• 個人情報を検出した場合は、人間承認が必要

この違いはかなり重要です。

つまり、通常の社内ナレッジ検索であればGemini標準機能でも十分な場合があります。一方で、個人情報、契約、顧客情報、人事労務、セキュリティ情報などを扱うなら、自作AI基盤やAI Gatewayのような制御層を用意した方が安全です。

Gemini Enterprise Agent Platformはどこで効いてくるか

ここで、Gemini Enterprise Agent Platformのような基盤が選択肢になります。

Gemini Enterprise Agent Platformは、企業向けにAIエージェントを構築・運用するためのプラットフォームです。Googleの説明では、エージェントの開発・デプロイ・管理に加えて、セキュリティやガバナンスの仕組みを持ち、Agent Identityによってエージェントに細かな権限を付与できるとされています。Agent Identityでは、エージェントがMCPサーバー、クラウドリソース、エンドポイント、他のエージェントに対して、自分自身の資格情報、またはエンドユーザーの代理として安全に認証できると説明されています。

これは、自作AI基盤を作るうえではかなり重要です。なぜなら、企業AIエージェントでやりたいことは、単に「AIに質問する」ことではなく、ユーザーの権限を前提に、必要な社内データを参照し、必要な業務ツールを呼び出し、必要に応じて下書きや操作案を作ることだからです。

たとえば、営業担当向けエージェントなら、

• 自分が見られる営業資料だけ検索する
• 担当顧客の過去議事録を要約する
• メール返信案を作る
• 送信は人間が承認する

という動きが必要になります。管理部向けエージェントなら、

• 契約資料を検索する
• 更新期限を抽出する
• 気になる条項をリストアップする
• 最終判断は人間が行う

という設計になります。このように、ユーザーの代理としてエージェントが動くための土台として、Gemini Enterprise Agent Platformのような仕組みは相性が良いです。

ただし、ここでも注意が必要です。Gemini Enterprise Agent Platformを使えば、エージェントのID、認証、接続、運用、監査の土台は作りやすくなります。Agent PlatformにはIAMによるアクセス制御や、Agent Gateway、Model Armorなどによる実行時のポリシー適用・脅威対策の考え方も示されています。しかし、「このファイルはAI-USEか」「この依頼は個人情報処理か」「この出力は外部送信してよいか」「この操作には人間承認が必要か」といった業務ポリシーは、自社側で設計する必要があります。

つまり、次のように考えるのがよいと思います。

リクエスト自体も分類する必要がある

AIに渡すデータだけでなく、ユーザーの依頼内容も分類する必要があります。同じファイルを扱う場合でも、依頼内容によってリスクは変わります。

たとえば、顧客資料に対して「この資料を3行で要約して」は比較的低リスクです。一方で「この契約で相手に不利な点を洗い出して」は、法務判断に近い内容になります。さらに「この内容で顧客にメール送って」となると、外部送信を伴うためリスクが上がります。

そのため、AI基盤ではリクエストを次のように分類するのがよいです。

この分類に応じて、使うモデル、渡すデータ、許可する操作、人間承認の有無を変えます。

AWSの記事でも、高度なモデルを安全に提供するうえで、ガードレールやフォールバックの考え方が示されています。これは企業AI基盤でも応用できます。重要なのは、危険な依頼を単純に「許可する／拒否する」だけでなく、より安全な経路へルーティングすることです。

モデルは用途ごとに使い分ける

高性能なモデルを、すべての用途に使う必要はありません。むしろ、強いモデルほど、できることも増えるため、リスクも上がります。そのため、用途ごとにモデルを分ける設計が現実的です。

大事なのは、「一番強いモデルを全員に使わせる」ことではありません。タスクのリスクに応じて、モデルと権限を切り替えることです。

Human in the loopは必須になる

AIエージェント化が進むと、AIは単に回答するだけでなく、メール送信、カレンダー登録、ファイル整理、CRM更新、権限変更などの操作を行うようになります。このとき、すべてをAIに直接実行させるのは危険です。

特に以下の操作は、人間承認を挟むべきです。

• メール送信・顧客への回答
• 契約書の修正
• Drive共有権限の変更
• ファイル削除
• 人事・労務判断
• セキュリティ対応
• 外部公開

エージェントのツールは、次の3段階に分けると整理しやすいです。

最初からAction toolを全面開放するのではなく、まずはRead toolとDraft toolから始めるのが安全です。AIは「実行者」ではなく、最初は「補助者」「下書き作成者」「整理役」として設計する方が現実的です。

ログと監査も設計に含める

AI基盤では、ログも重要です。最低限、以下のような情報を残す必要があります。

• 誰が、いつ使ったか
• どのデータを参照したか
• どのモデルを使ったか
• どのようなリクエスト種別だったか
• ガードレールが発動したか
• 出力は外部送信されたか
• 人間承認があったか

ただし、ログに本文や個人情報をそのまま残しすぎると、ログ自体がリスクになります。そのため、ログは「全文保存」ではなく、

誰が、どの文書を、どの目的で、どのAI処理に使ったか

を追跡できる形にするのがよいです。

Gemini Enterprise Agent Platformのような基盤を使う場合でも、Cloud Loggingや監視の仕組みは活用できますが、何を監査対象にするか、どのログを残すか、どの操作を承認制にするかは、業務側の設計として決める必要があります。

設計思想として大事なこと

AWSの記事から学べることは、単に「ガードレールを入れよう」という話ではありません。より本質的には、高性能AIは、公開・利用・運用の設計とセットで考える必要があるということです。企業AI基盤でも同じです。

AIを便利に使うためには、AIに何でも読ませるのではなく、AIに読ませてよいものだけを流す設計が必要です。AIに何でも実行させるのではなく、AIは提案し、人間が承認する設計から始めるべきです。高性能モデルを一律に使うのではなく、データの機密度、ユーザー権限、リクエスト種別に応じて、モデルや操作権限を切り替える必要があります。

整理すると、企業AI基盤に必要な設計思想は次の3つです。

• 1. 人間の権限を超えてAIに見せない
• 2. 人間が見られる情報でも、AI利用してよいかは別に判定する
• 3. AIが出す回答や実行する操作は、リスクに応じて制限・承認・監査する

まとめ

生成AIの導入は、単にChatGPTやGeminiを社内で使えるようにすることではありません。本当に重要なのは、AIを業務に組み込む前に、データ・権限・操作・ログ・承認の設計をすることです。

特に、社内DriveやGoogle WorkspaceとAIを連携させる場合は、次の考え方が重要になります。

AIは、ユーザー本人が見られる文書のうち、AI利用が許可された文書だけを参照できる。

そして、Gemini標準機能のようにWorkspace権限をそのまま継承する仕組みを使う場合は、「Driveで見えるものは、AIにも見える可能性がある」という前提でフォルダ設計や共有権限を考える必要があります。一方で、「人間は見られるが、AIには読ませたくない」という要件があるなら、自作RAGやAI Gatewayのような制御層が必要になります。

Gemini Enterprise Agent Platformのような基盤は、ユーザーの代理として動くエージェントを作るうえで有力な選択肢です。エージェントのID、認証、接続、管理、監査の土台を用意しやすくなります。ただし、それだけで企業ごとのAI利用ルールが完成するわけではありません。必要なのは、プラットフォームの権限管理に加えて、自社の業務ルールを反映したPolicy Layerです。

AIの安全性は、モデル単体では完結しません。モデル、ストレージ権限、データ分類、ガードレール、ログ、Human in the loopを含めて設計すること。これが、これからの企業AI基盤に必要な考え方だと思います。