Claude に Google Drive を繋ぐと、AIは"全ファイル"を読める — drive.readonly という権限の実際
「特定のファイルだけ」という文言を、私たちは信じすぎている
Claude の設定画面で Google Drive コネクタを有効にすると、Google の同意画面に進む。そこに並ぶ説明文のひとつが、「このアプリで使用する特定の Google Drive ファイルのみを表示、編集、作成、削除します」だ。いかにも安全そうな一文である。あなたが選んだファイルだけ、アプリが触れるファイルだけ——そう読める。だからこそ多くの人が、ここで深く考えずに「許可」を押す。
私は企業の生成AI導入とガバナンス設計を支援しているが、この「Connect ボタンを押す瞬間」ほど、便利さとリスクの非対称が凝縮された場面はないと感じている。押せば数分後には、Claude が社内ドキュメントを読んで要約を返してくれる。その体験は鮮烈だ。一方で、その一押しがアカウントに何を与えたのかを、あとから確かめる人はほとんどいない。
この連載の前々回で、私は「AIが構造的に脆くなる三つの条件」——致命的三要素（Lethal Trifecta）——を取り上げた。その第一の条件が「①プライベートデータへのアクセス」だった。本稿は、その①を、Claude の Google Drive コネクタという具体的な設定の上で検証する回である。結論を先に言えば、同意画面が前面に出す「特定のファイル」という印象と、実際にアカウントへ刻まれる権限の範囲のあいだには、見過ごせない開きがある。
同意画面は「特定のファイル」、実際の付与は「全Drive参照」
ここで起きていることを正確に追う。
Claude の Drive 連携は、単一の OAuth クライアントを通じて認可される。Drive コネクタを有効にしたときに発行されるトークンのスコープ（権限の範囲）を、認証後のコールバックで見ると、そこには drive.file と並んで drive.readonly が含まれている。実際にコネクタを使った開発者が GitHub の不具合報告でこの挙動を記録しており、認証後に myaccount.google.com/permissions を開くと、Anthropic に「Drive の全ファイルへのアクセス」が付与されていることが確認できる、と報告している。
二つのスコープの意味はまるで違う。drive.file は、同意画面に出ていた「特定のファイルのみ」という文言そのままのスコープだ。ユーザーがファイル選択画面で明示的に選んだファイルか、アプリが作成したファイルにしか触れられない。一方の drive.readonly は、Google の説明では「あなたの Google Drive のすべてのファイルを表示してダウンロードする」。前者は限定的、後者は全面的だ。そして二つが同時に付与されているとき、実際のアクセス範囲は当然、広いほうに従う。
つまり、ユーザーが目に留めやすい「特定のファイルだけ」という説明は、付与された権限の一部しか映していない。前面に出る文言は限定的なのに、実際に手渡されるのは Drive 全体を読める権限だ——印象と実態のあいだに、これだけのズレがある。なお、これは Claude だけの問題ではなく、AIコネクタ全般に通じる設計上の論点でもある。本稿では、挙動の証拠が明確に取れている Claude を軸に話を進める。
Google 自身が「広すぎる」と分類した権限
drive.readonly がどれほど広い権限なのかは、私の主観ではなく Google 自身の分類が物語っている。
Google は OAuth スコープを、機微度に応じて三段階に分けている。最も狭いのが Non-sensitive（非機微）で、先ほどの drive.file がここに入る。中間が Sensitive（機微）。そして最上位が Restricted（制限付き）で、drive.readonly や、読み書き両対応の drive がこの最も厳しい区分に置かれている。
Restricted の何が特別かというと、このスコープを一般向けの本番アプリで使うには、Google による検証に加えて、CASA と呼ばれる第三者のセキュリティ監査を通すのが原則になる。これは有償で、相応の手間と時間がかかる。Google がここまで重い手続きを課しているのは、「ユーザーの Drive を丸ごと読める」という権限が、それだけ大きなリスクを伴うと判断しているからにほかならない。Google の開発者向けドキュメントも、繰り返し「アプリに必要な最小限のスコープを選べ」「可能なら Non-sensitive を使え」と勧めている。
要するに、drive.file で済むなら drive.file を使うのが Google 公認の作法だ。にもかかわらず広い drive.readonly が要求されているという事実は、技術的に重い意味を持つ。そして厄介なのは、このスコープが Anthropic 側の OAuth クライアント設定として決まっている点だ。ユーザーが「私は drive.file だけでいい」と望んでも、コネクタを使う側からそれを狭める手段は用意されていない。許可するか、しないか——選べるのはその二択だけである。
「過去にうっかり共有したファイル」が、AI検索で蘇る
Drive 全体を読めるという権限が与える本当の怖さは、いま自分が管理しているファイルではなく、もう忘れている共有設定のほうにある。
drive.readonly でコネクタが見えるのは、「そのユーザーが見られるすべて」だ。自分が作ったファイルだけではない。何年も前に取引先と「いったん共有」したきり放置している見積書。退職した同僚から引き継いだフォルダ。「リンクを知っている全員が閲覧可」のまま社外に渡ってしまったドキュメント。組織で長く Drive を使っていれば、誰しもこの種の堆積に心当たりがあるはずだ。普段は誰も掘り返さないから、実害なく眠っている。
AIコネクタは、その眠りを一瞬で覚ます。「あの件の資料を探して」と頼むだけで、AIは過去の共有設定が許す範囲を端から検索し、忘却の底にあったファイルを的確に拾い上げてくる。ここで起きているのは、AIが新たに何かを"共有"したわけではない、という点が重要だ。AIはただ、これまで放置されてきた過剰な共有設定を、検索可能な形で可視化しているにすぎない。設定ミスは前からそこにあった。AIは、それを使える状態にしただけだ。業界ではこれを Permission Sprawl（権限の野放図な拡散）と呼ぶ。コネクタを繋ぐとは、この堆積の上に強力な検索エンジンを据えることでもある。
これは、前回の三角形そのものだ
ここまでを致命的三要素の枠組みに当てはめると、Drive コネクタがいかに危うい器かが見えてくる。
①プライベートデータへのアクセスは、drive.readonly によって全Drive規模で成立している。②信頼できない入力への曝露は、第三者から共有された——時には攻撃者が仕込んだ——ドキュメントを AI に読ませた時点で成立する。Drive には外から共有されたファイルがいくらでも流れ込む。③外部送信の経路は、前々回に解剖したとおり、応答に埋め込まれた画像URLのレンダリングなどで成立する。三つの辺が、Drive を繋いだだけで、ひとつのエージェントの上に揃ってしまう。
だからこそ、対策の発想も前回と同じところに帰着する。三つ揃うと危険なのだから、どこか一辺を意図的に断つ。そして①の辺——プライベートデータへのアクセス範囲——は、スコープと共有設定という、設定レベルで手をつけられる場所にある。
明日からできること — 権限の棚卸しと、見せる範囲の分離
派手なツールを入れる前に、まず確かめるべきことがある。
第一に、誰が何に権限を渡したかの棚卸しだ。個人レベルなら myaccount.google.com/permissions を開けば、自分の Google アカウントにアクセスできるサードパーティアプリが一覧で出てくる。そこに並ぶ各AIサービスが Drive に対してどこまでの権限を持っているかを確認し、使っていないもの・覚えのないものは取り消す。組織レベルなら、Google Workspace 管理コンソールのサードパーティアプリ管理（API コントロール）で、社員が「誰が」「どのAIに」「どのスコープで」Drive を繋いでいるかを監査できる。多くの組織は、この一覧を一度も見たことがないはずだ。
第二に、AIに見せる範囲そのものを物理的に分ける。drive.readonly を狭められない以上、効くのは「コネクタを繋ぐアカウントには、もともと広いものを見せておかない」という設計だ。AI連携専用の共有ドライブ（Shared Drive）を立て、AIに読ませてよい資料だけをそこへ集約する。業務の本丸が詰まった個人 Drive と、AIが触れる Drive を初めから分けておけば、drive.readonly が全Drive参照であっても、その"全Drive"の中身を限定できる。スコープを絞れないなら、スコープが見る対象のほうを絞る、という発想だ。
第三に、繋ぐかどうかを個人任せにしない。コネクタの有効化を承認制にし、どのデータソースをAIに開くかを組織として決める。禁止ではなく、統制された経路だけを残すための運用だ。
禁止ではなく、見せる範囲を設計する
Google Drive コネクタは、便利さの裏で「全Drive参照」という広い権限を要求する。同意画面の「特定のファイルだけ」という文言は、その全体像を語ってはくれない。だが、だからといってコネクタを禁止すれば、便利さごと失い、管理外の Shadow AI を増やすだけに終わる。
やるべきは、スコープを絞れない現実を受け入れたうえで、AIに見せる範囲を自分たちで設計することだ。専用ドライブへの分離、権限の定期的な棚卸し、承認制の運用。最小権限・分離・監査という古典的な三原則を、「AIに何を見せるか」という問いに翻訳し直すこと——それが、この①の辺を断つということである。
次回は、もうひとつの「①プライベートデータへのアクセス」が問われる現場、Slack を扱う。Slack を AI に繋ぐとき、xoxp- で始まる User Token と xoxb- で始まる Bot Token のどちらを選ぶかで、AIに見える範囲は——すべてのDMを含むか否かというレベルで——一変する。Drive のスコープと同じ問いが、別の顔で待っている。
主な参考資料
Google for Developers "Choose Google Drive API scopes"（スコープの三段階分類と各スコープの一覧）
Google Cloud "Requesting Minimum Scopes" / Google "Sensitive scope verification"（Restricted スコープと CASA セキュリティ監査）
Anthropic "Use Google Workspace connectors"（コネクタの仕様）
anthropics/claude-code Issue #51326・#39422（OAuth コールバックが返すスコープ、myaccount.google.com/permissions での全Drive参照の確認）
