共有ドライブには、議事録も見積書も仕様書も揃っている。それなのに Gemini に「この案件の経緯をまとめて」と聞くと、関係のないファイルを引っ張ってきたり、肝心の資料に触れないまま一般論を返してきたりする。
ドライブの整理が甘いからだ、と考えてフォルダ構成を作り直した会社を何社か見てきましたが、たいていそれでは解決しません。問題はファイルの置き場所ではなく、「この質問のときに読むべき資料はこれとこれ」という範囲を誰も指定していないことにあります。
Google ドライブの左メニューに増えた「プロジェクト」は、まさにその範囲を作るための機能です。フォルダの新しい呼び名ではありません。整理の道具ではなく、AI に読ませる対象を束ねる道具として設計されています。
フォルダは「置き場所」、プロジェクトは「読ませる範囲」
従来のフォルダは、ファイルをどこに保管するかを決めるものでした。1つのファイルは基本的に1つの場所にあり、階層をたどれば見つかる。この構造は、人間が探すためには十分です。
プロジェクトは目的が違います。特定の案件やテーマに関係する資料を、保管場所を問わず集めてくる。マイドライブにある提案書、共有ドライブにある議事録、Gmail に埋もれている顧客とのやり取り、カレンダーに入っている打ち合わせの予定を、ひとつの「ソース」の集合として指定できます。
そのうえで「Gemini に相談」を押すと、集めたソースの範囲だけを踏まえて要約や質問への回答が返ってきます。ドライブ全体を検索させるのでもなく、ファイルを1つずつ開いて貼り付けるのでもない、中間の粒度です。
| 何のためのもの | ファイルの実体 | |
|---|---|---|
| フォルダ / 共有ドライブ | 保管と権限管理 | ここに存在する |
| プロジェクト | AI に読ませる範囲の指定 | ソースとして参照されるだけ |
この表の右列が重要です。プロジェクトにソースを追加しても、ファイルが移動したりコピーされたりするわけではありません。「この案件ではこの資料群を見る」という参照のセットが増えるだけなので、既存のフォルダ構成を壊す心配は要りません。
権限はプロジェクトではなくソース側に残る
ここが実務でいちばん誤解される部分です。
プロジェクト自体は共有できます。チームのメンバーを共同編集者として招待すれば、同じソース集合に対して全員が Gemini に質問できる。ここまでを聞くと、「プロジェクトに入れた資料は、招待した人全員が読めるようになる」と受け取ってしまいがちです。
実際は逆で、共同編集者がソースファイルそのものを見る権限を持っていない場合、そのファイルについては Gemini との会話でも内容を参照できません。プロジェクトに追加する行為は、権限を配る行為ではないからです。
この仕様は、情報管理の観点では安全側に倒れています。人事のフォルダを誤ってプロジェクトに追加しても、権限のない人には中身が漏れない。一方で、運用としては別の症状を生みます。
- 招待したのに、相手の画面では回答の精度が明らかに低い
- 自分の環境では正しく答えるのに、他のメンバーからは「そんな資料は無いと言われる」と報告される
- どのファイルで権限が足りていないのかが、会話の画面からは判別しづらい
つまりプロジェクトを共有する前に、ソースの共有設定を揃えておく必要があるということです。この作業は結局のところ、リンク共有と権限の棚卸しそのものになります。ドライブ全体の共有状態を確認する手順はGoogleドライブのリンク共有を棚卸しするにまとめています。プロジェクトを本格的に使い始めるなら、その前に一度通しておくと後の混乱が減ります。
共有ドライブの設計を作り直す必要はない
「プロジェクトが来たので、共有ドライブの構成を見直したい」という相談を受けることがありますが、結論から言えば作り直す必要はありません。
保管と権限管理の役割は、これまでどおり共有ドライブが担います。部署単位・案件単位でドライブを切り、参加者を管理する。この設計はプロジェクトが登場しても変わりません。プロジェクトは、そこから必要なものを一時的に集めてくる層として上に乗ります。
むしろ気をつけるべきは逆方向で、プロジェクトを増やしすぎると、今度は「どのプロジェクトを見ればいいか分からない」状態が生まれます。フォルダの乱立と同じ現象が、一段上の層で再発するだけです。
そうならないように、作る単位をあらかじめ決めておくと安定します。案件が終われば役目を終える、という前提で運用するのが素直です。長期に維持したい社内ナレッジは、プロジェクトではなく共有ドライブ側に整理しておく。この使い分けを最初に言語化しておかないと、半年後には両方が散らかります。
社内の知識をどこに集約するかという論点は、NotebookLM と Workspace の組み合わせでも扱いました。プロジェクトは案件ごとの短期的な文脈、NotebookLM 側は繰り返し参照するナレッジ、と役割を分けて考えると整理しやすくなります。
情シスが先に決めておくと楽なこと
全社に案内する前に、決めておくと後戻りが減る項目があります。どれも設定というより運用の取り決めです。
機密度の高い資料をソースにしてよいか。 人事・給与・法務・未公開の経営情報について、プロジェクトのソースに追加してよいかを決めておきます。権限のない人には見えない仕様とはいえ、招待の操作は各メンバーが自分でできます。「追加してよい情報の種類」を先に線引きしておくほうが、事故が起きてから禁止するより穏当です。
プロジェクトの持ち主が退職したらどうするか。 ここは共有ドライブとの差が出る部分です。共有ドライブに置いたファイルは組織の資産として残りますが、個人が作ったプロジェクトは、その人のアカウントに紐づいて存在します。退職者アカウントの取り扱いを決めるとき、ドライブのファイルだけでなくプロジェクトも対象に含めておく必要があります。
利用できる端末の制限を確認する。 プロジェクトの作成や Gemini との対話は Web 版が中心で、モバイルアプリからは共有設定や名前の変更といった操作に限られる、という状態が続いています。外回りの多い部署に案内するときは、この点を先に伝えておかないと「使えない」という問い合わせが増えます。
権限設計そのものの考え方は、Googleサイトで社内ポータルを作るときの権限設計と共通しています。誰に何を見せるかを先に決め、ツールの機能はその後で当てはめる順序です。
次にやること
いま進行中の案件をひとつ選び、その案件に関係する資料が何個あって、どこに散らばっているかを数えてみてください。ドライブ、Gmail、カレンダーをまたいで5個も10個も出てくるはずです。その散らばりこそが、これまで AI に業務を任せられなかった理由です。
プロジェクトは、その散らばりを解消せずに束ねられる点が実務的です。整理してから使うのではなく、散らかったまま使い始められる。ただし前の章のとおり、共有した相手の権限が揃っていなければ効果が出ないため、試すなら権限の確認とセットで進めてください。
Google Workspace の権限設計や、生成 AI に社内データをどこまで読ませるかの整理については、グリームハブの IT・Google Workspace 無料相談で承っています。組織の規模や既存のドライブ構成によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- ドライブのプロジェクトを使用して Gemini のソースを共有する — Google ドライブ ヘルプ
- Google が Workspace Intelligence を発表。Google ドライブの「プロジェクト」や Google Meet の対面メモ機能など — HelenTech
- Google ドライブ新機能「プロジェクト」の使い方｜Gemini 連携で情報を一元化するメリットを解説 — rakumo
- Google ドライブの「プロジェクト」って何？ 使い方・使いどころ・NotebookLM との違いを解説 — DSK Cloud
- 10分でわかる Google ドライブのプロジェクト機能の使い方 — 吉積情報
