Google Workspaceの共有ドライブには、規程、マニュアル、議事録、提案書、契約書など、企業活動を支える膨大な情報が蓄積されています。
しかし、共有ドライブを生成AIやRAG（検索拡張生成）へ接続するだけでは、安全で信頼できる社内ナレッジ基盤にはなりません。
更新された文書がAIへ反映されない、削除済みの情報が検索結果に残る、閲覧権限のない文書をAIが回答してしまう、文書の分割方法が悪く回答精度が低下するといった問題が発生するためです。
共有ドライブをAI向け社内ナレッジ基盤へ変えるには、同期・アクセス制御・メタデータ・文書構造の4つを一体として設計する必要があります。
本記事では、Google Drive API、Drive Labels、Sensitive Data Protection、Agent Searchなどを活用し、共有ドライブを安全で検索精度の高いAIナレッジ基盤へ変える実務手法を解説します。
共有ドライブをAIへ接続するだけでは不十分な理由
共有ドライブは、人がフォルダを開き、文書名や作成者を確認しながら情報を探すことを前提とした仕組みです。
一方、AIは文書から抽出されたテキストを分割し、検索インデックスへ登録して利用します。
そのため、人には理解できるフォルダ構成でも、AIには次のような情報が判別できない場合があります。
- どの文書が最新版なのか
- 下書きと承認済み文書のどちらを使うべきか
- 誰が閲覧できる文書なのか
- どの部署に関係する情報なのか
- 廃止された規程なのか、現在も有効なのか
- 同じ内容の重複ファイルが存在しないか
共有ドライブをAIへ接続するプロジェクトでは、ファイルを大量に取り込むことよりも、AIが使ってよい情報を判別できる状態をつくることが重要です。
AI向け社内ナレッジ基盤に必要な5つの層
共有ドライブを基盤としたAI検索システムは、次の5層に分けて考えると整理しやすくなります。
1．原本管理層
共有ドライブを文書の原本、すなわち唯一の正しい情報源として管理します。
AI検索用に文書を複製したとしても、文書の修正や承認は共有ドライブ側で行います。AI検索インデックスを原本として扱ってはいけません。
2．同期・取り込み層
Google Drive APIを使って、文書の追加、更新、削除、移動、権限変更などを検知します。
変更されたファイルだけを差分取得し、検索インデックスへ反映することで、処理時間とAPI利用量を抑えられます。
3．セキュリティ・権限管理層
共有ドライブに設定されたユーザー、グループ、部署、ファイル単位のアクセス権限を検索システムへ継承します。
検索結果を表示する前に、質問者がその文書を閲覧できるかを確認しなければなりません。
4．検索・生成層
文書を適切な単位に分割し、メタデータとともに検索インデックスへ登録します。
質問に関連する情報を検索し、その情報だけを生成AIへ渡して回答を作成します。
5．利用・監査層
社内チャットボットや検索画面を通じて情報を提供します。
回答には参照元文書、更新日、文書の状態などを表示し、質問履歴や参照文書も監査ログとして記録します。
同期設計では「即時通知」と「定期照合」を組み合わせる
共有ドライブとAI検索インデックスの同期方法には、大きく分けてイベント通知型と定期取得型があります。
イベント通知型では、ファイルの変更を検知すると、Webhookなどを通じて同期処理を開始します。反映が速い一方で、通知チャンネルの有効期限切れ、通信障害、通知の取りこぼしなどを考慮しなければなりません。
Google Drive APIの通知チャンネルには有効期限があり、継続利用には更新処理が必要です。また、通知は「変更があったこと」を知らせるものであり、必ずしも変更内容そのものを完全に含むわけではありません。
そのため、企業向けシステムでは次の仕組みを組み合わせます。
- イベント通知による迅速な更新検知
changes.listによる差分取得- 開始ページトークンの永続的な保存
- 定期的な全体照合
- 通知チャンネルの期限監視と自動更新
- 失敗時の再試行とエラー通知
即時通知だけに依存せず、一定時間ごとに共有ドライブと検索インデックスの状態を照合することで、通知漏れが発生しても修復できる設計にします。
更新だけでなく削除と権限変更も反映する
同期処理で見落とされやすいのが、文書の削除とアクセス権限の変更です。
共有ドライブから削除された文書が検索インデックスに残っていると、廃止された規程や古い価格情報をAIが回答する可能性があります。
また、異動や退職によって共有ドライブの閲覧権限を失ったユーザーが、AIを経由すると以前の文書を検索できる状態も避けなければなりません。
同期対象には、少なくとも次の変更を含めます。
- ファイルの新規作成
- 本文の更新
- ファイル名の変更
- フォルダ間の移動
- ラベルの変更
- 閲覧権限の追加と削除
- ファイルの削除
- 共有ドライブからの除外
「文書を登録する処理」だけでなく、検索対象から外す処理まで含めて同期設計を完成させる必要があります。
AI検索でも共有ドライブの閲覧権限を引き継ぐ
AI向け社内ナレッジ基盤における最大のリスクは、権限のない情報が回答へ混入することです。
例えば、全社共通のサービスアカウントを使って共有ドライブの文書を取り込み、そのサービスアカウントの権限で検索を実行すると、利用者本人には閲覧権限のない人事、給与、契約、経営会議などの文書まで検索対象になる可能性があります。
守るべき原則は明確です。
共有ドライブで閲覧できない文書は、AIを経由しても閲覧できない。
この原則を実現するには、ログインしたユーザーのIDを検索要求まで引き継ぎ、検索前または検索時にアクセス制御を適用します。
GoogleのAgent Searchでは、Googleドライブを含むデータソースに対するアクセス制御機能が提供されています。利用には、Google IdentityなどのIDプロバイダをGoogle Cloud側で適切に構成する必要があります。
実装時には、次の点を検証します。
- ユーザー本人のOAuth認証が検索APIまで伝わっているか
- Googleグループによる権限が正しく反映されるか
- 異動や退職による権限削除が検索側にも反映されるか
- リンク共有された文書の扱いが社内ルールと一致しているか
- 管理者権限のサービスアカウントが検索ユーザーとして使われていないか
- 権限のない文書が回答文や引用部分へ混入しないか
アクセス制御は、検索結果の画面表示だけで実施してはいけません。
生成AIへ文書を送信する前の検索段階で、権限のない情報を除外することが重要です。
Drive LabelsでAIが理解できるメタデータを付ける
AI検索では、本文の意味が近い文書を探すベクトル検索が利用されます。
しかし、本文だけでは「法務部が作成した承認済みの契約書」「2026年度に有効な就業規則」といった組織上の条件を正確に判別できません。
そこで活用したいのがDrive Labelsです。
Drive Labelsは、Googleドライブ内のファイルに組織独自のメタデータを付与する機能です。ラベルは、ファイルの整理、検索、ポリシー適用などに使用できます。
AI向けには、次のような項目を設定します。
- 主管部署
- 文書種別
- 機密区分
- 承認状態
- 適用開始日
- 有効期限
- 文書責任者
- 対象製品・サービス
- 対象顧客
- 正式版・参考資料の区分
- AI検索への登録可否
例えば、「営業部が作成した承認済みの提案書だけを検索する」「現在有効な規程だけを回答に使用する」といった絞り込みが可能になります。
メタデータは、ファイルを取り込んだ後で追加するのではなく、本文と同時に検索インデックスへ登録します。
検索時にメタデータで事前に絞り込み、その後に意味検索を行うことで、検索ノイズを減らせます。
機密情報や個人情報はインデックス登録前に検査する
共有ドライブには、電話番号、メールアドレス、顧客名、従業員情報、クレジットカード番号などが含まれている可能性があります。
これらを無条件に外部の埋め込みモデルや生成AIへ送信する設計は、安全とはいえません。
取り込み処理の途中にSensitive Data Protectionによる検査を組み込み、機密情報を検出したうえで、必要に応じて次の処理を行います。
- 検索対象から除外する
- 一部の文字をマスキングする
- 固定の代替文字列へ置換する
- トークン化する
- 暗号化する
- 管理者の確認対象にする
Sensitive Data Protectionでは、個人識別情報の検出に加え、マスキング、削除、置換、トークン化などの非識別化処理が提供されています。
ただし、すべての個人情報を自動的に削除すればよいわけではありません。業務上必要な情報まで消すと、AI回答の実用性が低下します。
文書種別、利用目的、閲覧者、生成AIへ送信する範囲を整理し、情報ごとに処理方法を定める必要があります。
文書構造を整えなければRAGの精度は上がらない
RAGでは、長い文書を複数の小さな単位に分割して検索インデックスへ登録します。この処理をチャンキングと呼びます。
ところが、文書を一定の文字数だけで機械的に分割すると、次の問題が発生します。
- 見出しと説明文が別々になる
- 条件と例外規定が切り離される
- 表の見出しと数値の対応が失われる
- 質問に必要な前後関係が欠落する
- 異なる章の文章が同じ単位へ混入する
これを防ぐためには、文字数だけで分割するのではなく、見出し構造を利用した構造認識型チャンキングを採用します。
Googleドキュメントの見出し1、見出し2、見出し3を章の境界として解析し、意味のまとまりごとに分割します。
各分割データには、次の情報を持たせます。
- 文書タイトル
- 見出しの階層
- 主管部署
- 文書種別
- 承認状態
- 更新日時
- ファイルID
- 原本文書へのリンク
- アクセス制御情報
- 文書の版番号
1チャンク400～600トークン、前後10～20％程度の重複は初期設定の目安になりますが、すべての文書に共通する正解ではありません。
規程、FAQ、議事録、契約書、技術仕様書では、適切な分割単位が異なります。実際の質問を使って検索精度を評価し、文書種別ごとに調整する必要があります。
表を途中で分割しない
料金表、製品仕様、役割分担表、承認条件などは、AIが誤読しやすい情報です。
表の途中でチャンクが分割されると、列見出しと数値の関係が失われ、別製品の価格や条件を回答する可能性があります。
表については、次の処理が必要です。
- 原則として表全体を一つの意味単位として扱う
- 分割する場合は各チャンクへ列見出しを再付与する
- 表のタイトルと対象期間を含める
- セルの結合関係をテキスト上でも明示する
- 単位、税込・税抜、適用条件を省略しない
表の見た目を保存するだけでなく、AIが列と数値の関係を理解できる形に変換することが重要です。
AIへ登録する前に文書作成ルールを標準化する
検索技術だけを改善しても、元の文書が整理されていなければ回答精度は安定しません。
社内文書には、次の共通ルールを設定します。
- タイトルだけで文書の目的が分かるようにする
- 見出し機能を使用する
- 作成日と最終更新日を記載する
- 文書責任者を明示する
- 承認済みと下書きを区別する
- 廃止文書には廃止日を設定する
- 略語は最初に正式名称を記載する
- 画像内の文字だけで重要事項を伝えない
- 一つのファイルに複数の異なるテーマを詰め込まない
- 正式な原本がどれかを明確にする
AIナレッジ基盤づくりは、システム開発だけでは完結しません。
文書を作る人、承認する人、管理する人の運用ルールまで含めて設計する必要があります。
90日で進める段階的な導入ロードマップ
第1段階：文書を棚卸しする
最初から共有ドライブ全体をAIへ取り込まず、対象業務を一つに限定します。
問い合わせ対応、社内規程、製品マニュアルなど、質問内容と正解文書を特定しやすい領域が適しています。
重複文書、古い文書、所有者不明の文書、過剰共有されている文書を洗い出します。
第2段階：メタデータと文書ルールを設計する
主管部署、文書種別、承認状態、機密区分、有効期限などのラベルを決めます。
同時に、見出し、更新日、責任者、正式版の表示方法を標準化します。
第3段階：小規模な検索実証を行う
30～100件程度の文書を使い、実際に社員が尋ねる質問で検索精度を検証します。
この段階では、回答の流暢さよりも、正しい文書が検索できているかを確認します。
第4段階：同期とアクセス制御を実装する
差分同期、削除反映、権限継承、個人情報検査、監査ログを実装します。
権限の異なる複数のテストユーザーを作り、閲覧できる回答と閲覧できない回答が正しく分かれるかを確認します。
第5段階：対象部門を拡大する
評価結果を確認しながら、対象文書と利用部署を段階的に広げます。
利用者から寄せられた「答えられなかった質問」を、文書不足、検索失敗、権限不足、質問表現の問題に分類し、改善へつなげます。
AIナレッジ基盤の評価指標
導入効果は、利用回数だけで判断してはいけません。
少なくとも、次の指標を継続的に確認します。
- 正しい文書が上位に検索された割合
- 回答に参照元が表示された割合
- 更新文書が検索へ反映されるまでの時間
- 削除文書が検索結果から消えるまでの時間
- 権限外文書が表示された件数
- 回答不能と判断した割合
- 利用者が回答を有用と評価した割合
- 問い合わせ対応時間の削減量
- 文書を探す時間の削減量
- 古い情報を参照した誤回答件数
特に、権限外文書の表示件数はゼロを維持すべき指標です。
AIが回答できなかった場合に、無理に文章を生成せず、「該当する承認済み文書を確認できませんでした」と回答する設計も欠かせません。
共有ドライブのAI化で起こりやすい失敗
共有ドライブ全体を一括登録する
不要な文書、重複文書、下書き、廃止文書まで登録され、検索精度が低下します。
フォルダ名だけで分類する
ファイルの移動やショートカットによって分類が変わるため、明示的なラベルを併用する必要があります。
更新処理だけを作る
削除や権限変更が反映されず、古い情報や閲覧禁止情報が残ります。
サービスアカウントの権限で検索する
利用者本人の権限が適用されず、情報漏洩につながる危険があります。
文字数だけで文書を分割する
見出し、条件、例外、表構造が壊れ、検索精度と回答精度が低下します。
回答の自然さだけを評価する
生成AIは、誤った文書を使っても自然な文章を作れます。
回答文だけでなく、検索された根拠文書を評価しなければなりません。
まとめ
Google Workspace共有ドライブをAI向け社内ナレッジ基盤へ変えるには、ファイルを生成AIへ接続するだけでは不十分です。
重要なのは、次の4点です。
- 変更、削除、権限変更を確実に反映する同期設計
- 利用者本人の権限を検索時に適用するアクセス制御
- Drive Labelsと機密情報検査によるデータガバナンス
- 見出しや表構造を守る文書前処理とチャンキング
AIナレッジ基盤の品質は、生成AIモデルの性能だけで決まりません。
「どの情報を、誰が、どの状態で、どのように検索できるか」を設計することが重要です。
この仕組みが整って初めて、共有ドライブに蓄積された文書は、安全で再利用可能な組織の知的資産になります。
JAICでは、Google Workspaceの共有ドライブ整理、権限設計、生成AI・RAG活用、社内文書の標準化、運用ガイドライン策定まで、企業の状況に応じた導入支援を行っています。
コメント