Dify × Google Drive セキュリティRAGガイド

Dify（LLMアプリ開発プラットフォーム）のナレッジパイプライン機能を使うと、Google Drive上のセキュリティポリシーPDFをRAG（Retrieval-Augmented Generation：検索拡張型生成）のデータソースとして活用し、社内チャットボットを構築できます。この記事では、「Dify Google Drive セキュリティポリシー RAG」の構築を検討する情シス担当者向けに、インデックス設計・アクセス制御・運用設計の判断軸を整理します。

この記事を読んだほうが良い人

• Google Workspaceで100名規模の社内ITを管理しており、セキュリティポリシーや社内規定への問い合わせ対応を自動化したい情シス担当者
• Dify × Google DriveのRAGチャットボット構築を検討しているが、インデックス設計やアクセス制御の判断軸がわからない方
• 社内PDF規定文書をAIが参照できる形にする際の落とし穴を事前に把握したい方

Dify Google Drive セキュリティポリシー RAGの全体構成

RAG（Retrieval-Augmented Generation）は、LLM（大規模言語モデル）が回答を生成する前に社内文書から関連情報を検索し、その内容を参照しながら回答を返すアーキテクチャです。セキュリティポリシーや社内規定は自社固有のルールブックであり、汎用LLMの学習データには含まれません。自社文書をそのままナレッジソースとして使えるRAGとの親和性が高い用途の一つです。

Dify × Google Drive構成での情報の流れを整理すると、以下のようになります。

[Google Drive（ポリシーPDF / Docs）]
       ↓ OAuth 認証で取得
[Dify ナレッジパイプライン]
  ・テキスト抽出
  ・チャンク分割 + ベクトル化
       ↓
[ベクトルDB]
       ↑ 関連チャンク取得
[社員の質問 → Dify チャットBot]
  ・ベクトル検索
  ・LLM への参照チャンク + 質問送信
       ↓
[LLM が回答 + 参照元チャンク表示]

Dify公式ドキュメントによると、Google DriveデータソースはOAuth認証のみをサポートしており、サービスアカウント認証には対応していません。つまり「誰のOAuthトークンでDriveにアクセスするか」が最初の設計上の問いになります。取り込み対象の主なファイル形式はテキスト層のあるPDF、Google Docs、テキストファイルです。

OAuth認証を行ったアカウントがDrive上でアクセス権を持つファイルのみがインデックス化されます。担当者の異動やアカウント削除でOAuthトークンが無効化された場合、DifyのナレッジパイプラインはDriveとの同期でエラーを返します。このため、「誰のアカウントでOAuth認証を行ったか」を構成情報として記録しておくことが、後続の運用担当者への引き継ぎに欠かせません。専用の管理者アカウントを1つ定めてOAuth認証を行い、そのアカウント情報をBot運用ドキュメントに明記しておく運用が現実的です。

Google Drive PDF文書のインデックス設計をどう判断するか

Driveのフォルダ構成をBot参照単位で再設計する

情シスがまず決めるべきは「Difyにどのフォルダを参照させるか」です。既存の文書管理フォルダをそのまま使うと、Bot参照範囲が広がりすぎて回答精度が落ちます。

セキュリティポリシーBotに特化させるなら、Bot専用フォルダを作成し、関連規定PDFのみをそこに集約します。「ここに入っているファイルだけがBotに参照される」というルールを明確にしておくことが、回答精度の管理と文書ガバナンスの両面で重要です。フォルダ構成のイメージは以下の通りです。

[共有ドライブ] セキュリティBot用/
  ├── 情報セキュリティ基本方針_v3.pdf       ← 最新版のみ格納
  ├── BYOD利用規定_2025年版.pdf
  ├── メール・SNS利用規定_2025年版.pdf
  └── クラウドサービス利用規定_2026年版.pdf

旧版のPDFはフォルダ外の「アーカイブ」フォルダに移動します。同名ファイルの新旧版が同一フォルダに混在していると、BotがDriveから両バージョンを取得して矛盾した回答を返す原因になります。「Bot用フォルダには最新版のみを置く」というルールを情シス内で徹底することが、回答品質の維持に直接つながります。

チャンクモードの選択基準

DifyのナレッジパイプラインはGeneral / Parent-child / Q&Aなど複数のチャンキングモードを備えています。セキュリティポリシー文書に合わせた選択基準は以下の通りです。

モード	特徴	適したケース
General Mode	自動チャンキング、設定コストが低い	汎用的な説明文書・ガイドライン
Parent-child Mode	小チャンク（精密検索）+ 大チャンク（文脈保持）の二層構造	条文形式のポリシー規定
Q&A Mode	質問ベースでインデックス化	FAQをCSV/Excelで蓄積している場合

セキュリティポリシーは「第3条（情報資産の分類）」のような条文型の文書が多いため、Parent-child Modeが有効なケースが多いです。条項を子チャンクとして精密にヒットさせつつ、関連する章の文脈を親チャンクとして保持できます。General Modeから始めて精度に不満が出たらParent-childへ移行するのが、試行コストを抑えた現実的な順序です。

日本語のポリシー文書を扱う場合、チャンクサイズの単位が英語と異なる点にも注意が必要です。日本語は1文あたりの情報密度が高く、同じトークン数でも表現できる内容量が変わります。デフォルト設定で一度試した後、「質問への回答が短すぎる（チャンクが小さすぎる）」または「関係のない条文まで混入する（チャンクが大きすぎる）」という症状ごとにサイズを調整していく方針が現実的です。

画像スキャンPDFの扱い

スキャナーで取り込んだ画像PDFはテキスト層がなく、Difyのナレッジパイプラインでは文字情報を抽出できません。過去の紙文書をスキャンしたポリシー文書が混在している場合、テキストPDFに変換する前処理が必要になります。

Google Workspaceを利用している環境では、スキャンPDFをGoogle DriveにアップロードしてGoogle Docs形式で開き、そのまま保存する操作でOCRを行えます。追加コストなく実行できますが、複雑なレイアウト（表組み・多段組み）のPDFでは変換精度が下がるケースがあります。変換後の文書は目視確認を省略しないことを推奨します。

取り込み対象の文書に画像PDFが含まれていないかを構築前に棚卸ししておくと、後工程での想定外の工数を防げます。「ファイルをGoogle Docsで開いて文字が選択できるか」という簡易チェックで、テキスト層の有無を確認できます。

アクセス制御の設計：誰がBotに質問できるか

DifyのチャットアプリへのアクセスはDify側の設定で制御します。主なパターンとDifyの導入形態・認証方式の関係を整理すると以下の通りです。

パターン	Dify導入形態	認証方式	導入コスト	セキュリティ強度
URLを知っている全員がアクセスできる	SaaS版（Sandbox / Professional / Team ※）	なし	低〜中	低（URL漏洩リスクあり）
SSO（シングルサインオン）認証	Enterprise版	SAML / OIDC / OAuth2	中〜高	高（組織アカウントのみ）
セルフホスト + ネットワーク制限	セルフホスト版	VPN必須	高	高（NW層での制御）

※ Team プラン（$159/月）のSSO認証対応状況は公式サイトで明示されていません。SSO連携が要件になる場合は、Dify公式サポートで事前確認することを推奨します。

100名規模の情シスが判断すべき軸は「対象ポリシー文書の機密度」と「Difyの導入形態・コスト許容度」の組み合わせです。全社員が参照できる一般的なセキュリティポリシーであれば、URLベースのアクセスでも許容できるケースがあります。役員向け規定や個人情報取り扱い手順など機密度の高いポリシーが混在するなら、SSO連携またはネットワーク制限が必要です。

URLベースのアクセスを採用する場合でも、社内Slackチャンネルや社内Wikiにのみリンクを掲載し、Botの存在を社外から見えにくくする運用で実用上の閾値をカバーできるケースがあります。ただし、URLの拡散経路が制御しきれないことは前提として理解しておく必要があります。機密度の高い文書をナレッジに含める構成であれば、SSO認証またはネットワーク制限を採用する判断が妥当です。

設計上の重要な注意として、DifyのアクセスコントロールはDifyアプリ自体の認証であり、Google Drive上の共有権限とは独立しています。インデックス化の対象フォルダと、OAuthトークンを持つアカウントのDrive権限を一致させる設計が基本です。意図しないファイルのインデックス混入を防ぐためのポイントとして、この権限の整合性を構築時に確認することを運用チェックリストに加えておきます。

ドキュメント更新時の再インデックス化をどう運用するか

セキュリティポリシーは年1〜2回の定期改定が一般的ですが、インシデント対応や法令改正に伴う随時更新が発生することもあります。改定後もDify側のインデックスが古いまま残ると、Botが旧版の規定に基づいて回答するリスクが生じます。

更新頻度に応じた運用設計の目安は以下の通りです。

更新頻度	推奨する運用アプローチ
年1〜2回	改定のたびに担当者がDifyナレッジベースを手動更新するルールを文書化する
月次	Driveへのファイルアップロード後にDify側の同期操作を行うフローを定義する
週次以上	DifyのAPI経由でインデックス更新を自動化することを検討する

いずれの場合も、改定後にテスト質問で新しい内容が正しく回答されているかを確認するステップを運用手順に組み込みます。テスト質問は「ポリシーに明示されている事実を問う質問」と「条文をまたいで解釈が必要な質問」の2種類を用意すると、回答精度の変化を検出しやすくなります。事前に用意しておくテスト質問の例は以下の通りです。

• 「情報資産の管理責任者は誰ですか？」（単一条項の事実確認）
• 「業務用PCにソフトウェアをインストールする際の承認手順を教えてください」（手順フローの読み取り）
• 「個人端末で業務メールにアクセスすることはポリシー上認められていますか？」（条件付き判断）

この3種類のテスト質問が改定後の内容に基づいて正しく回答されれば、インデックス更新が機能していると判断できます。

ナレッジベースの更新は新ファイルの追加だけでなく、旧ファイルのインデックス削除も必要です。同名ファイルの上書きが自動でインデックス更新されるかは設定と構成によって異なります。「インデックスを更新したはずが、古い内容が参照されていた」は実際に発生しやすい失敗パターンのため、更新後の動作確認は省略できません。確認用テスト質問セットを文書化しておくことで、更新のたびに質問を考え直す手間も省けます。

できること・できないこと

実際の構築前に、このアーキテクチャで達成できることと難しいことを整理します。

できること

• テキスト層のあるPDF・Google Docsへの自然言語での質問応答（日本語対応）
• 複数ドキュメントにまたがる関連情報の統合回答（「第3条と第7条を照らし合わせると…」のような参照）
• 回答の根拠となった参照チャンクの提示（透明性の確保）
• 特定ドキュメントだけを参照させるナレッジソースの絞り込み設定

できないこと

• 画像スキャンのみのPDF内容参照（テキスト抽出不可、OCR前処理が必要）
• ポリシー改定のリアルタイム反映（インデックスの手動または定期更新が必要）
• 回答の法的正確性の保証（LLMのハルシネーションリスクがあるため、重要判断は人間確認が必要）
• Google Drive上のユーザーごとのアクセス権限を動的に引き継ぐ動作（BotはDriveのパーミッションをユーザー単位で制御しない）
• テーブル・図・グラフなど複雑なレイアウト要素の正確な解釈（承認マトリクスや条件分岐表は回答精度が下がる場合がある）
• 例外的なケースや新規解釈の最終判断（Botはポリシーの説明役であり、個別判断は情シスが担う）

最後の点が運用上の境界線です。「この操作はOKですか？」という問いにBotが返せるのは「ポリシー文書にはこう書いてある」という読み取りまでです。例外処理や個別解釈が必要な問い合わせは、引き続き情シスが受け付けるフローを維持することが、ガバナンス上の安全弁になります。システムプロンプトに「判断に迷う場合は情シスに確認してください」という注記を必ず含める設計にしておくことで、Botへの過度な依存を防ぐ構造を作れます。

情シスが先に決めておくべき3つの設計判断

ここまでの内容を踏まえ、構築前に明確にしておくべき判断を3点に絞ります。

1. ドキュメントの棚卸しと品質チェック

Difyに取り込む前に、「テキスト層があるPDFか」「最新版がDriveに格納されているか」を確認します。スキャンPDFが混在している場合はOCR変換の工数を見積もっておきます。文書品質がBotの回答精度に直結するため、ここを後回しにすると構築後のやり直しコストが大きくなります。

2. アクセス制御の方針決定

「全社員に公開」か「認証が必要」かを先に決めます。Difyの導入形態（SaaS版 / Enterpriseプラン / セルフホスト版）によって実現できる認証方式が変わるため、アクセス制御の要件を先に固めてから導入形態を選ぶ順序が効率的です。

3. 更新運用ルールの明文化

ポリシー改定時に「誰が」「どのタイミングで」Difyのインデックスを更新するかを決め、情シス内の運用手順として文書化します。担当者の異動があっても引き継げる形にしておくことが、長期運用の安定性につながります。OAuthトークンの発行アカウント名と、Dify上のナレッジベース管理者を明記した「Bot運用シート」を1枚用意しておくと、引き継ぎ時の漏れを防げます。

この3点を構築前に固めることで、「使われないBot」「古い情報を回答するBot」を作って終わるリスクを減らせます。PoCとして最初のBotを立ち上げるまでの実作業は、Drive専用フォルダの作成と文書配置、DifyでのOAuth認証とインデックス化、チャットアプリとしての限定公開、テスト質問での回答確認という4ステップで構成されます。小さく始めれば1〜2日で動作確認まで達成できる構成です。本格運用に必要なアクセス制御やチャンク設計の調整は、PoC後の知見を踏まえて判断する方が、机上の設計だけで進めるより確度が上がります。まずは情報セキュリティ基本方針1本だけをナレッジに取り込んだBotで実際の回答品質を確認してから、取り込む文書を広げていく段階的なアプローチを推奨します。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。