# 全世界公開になっていた共有ドライブ資料を、業務を止めずに締める 社内Wikiの書き出し、マニュアル、議事録アーカイブ。 **「AIツールに読ませるため」に共有設定を緩めたフォルダが、そのまま “リンクを知っている全員” で放置されている**—— これは珍しい事故ではなく、非常によくある。 この指示書は、それを **業務を止めずに・証拠を取りながら** 締めるまでの型。 AI エージェントにそのまま実行させられる粒度で書いてある。 対象: Google Drive（Google Workspace）。考え方は他のクラウドストレージでも同じ。 --- ## 0. 前提となる勘違いを先に潰す 締める作業に入る前に、次の3つを疑うこと。**ここを飛ばすと必ず事故る。** ### 勘違い1「認証が必要なはずだ」 元データが認証必須のシステム（社内Wiki等）から書き出されていても、 **書き出し先の共有設定はまったく別物**。元が認証必須でも、コピーは公開されうる。 「元は認証必須だから安全」は根拠にならない。**実際に落とせるか試す**しかない。 ### 勘違い2「権限一覧を見れば誰が読めるか分かる」 **MCP コネクタや簡易APIが返す権限一覧は、しばしば不完全。** 実測: あるフォルダで、MCP 経由では **3件**（anyone / domain / owner）しか返らなかったが、 Drive API を直接叩くと **8件**あった。返ってこなかった中に、 **個人用フリーメールアドレスの writer 権限**が含まれていた。 権限を根拠に判断するなら、**必ず生の API を叩く**こと。 ``` GET https://www.googleapis.com/drive/v3/files/{id}/permissions ?fields=permissions(id,type,role,domain,emailAddress,allowFileDiscovery,permissionDetails) &supportsAllDrives=true ``` 簡易ツールが落としがちなのは `allowFileDiscovery`（検索に載るか／リンク限定か）と `permissionDetails.inherited`（フォルダ継承か直付けか）。**この2つが無いと締め方を間違える。** ### 勘違い3「自分は権限を持っているから操作できる」 **読めることと、権限を変更できることは別。** owner でないと権限の付与/削除は通らないことが多い。 サービスアカウント＋ドメイン全体の委任を使っているなら、**impersonate 先を owner に切り替える**必要がある。 実装では impersonate 先を環境変数で上書きできるようにしておくと、都度書き換えずに済む。 --- ## 1. まず「本当に公開されているか」を証拠で確定する 権限一覧は**間接証拠**でしかない。**未認証で実際に落とせるかどうか**が答え。 ```bash curl -sL -o /tmp/anon.txt \ -w "HTTP %{http_code} size=%{size_download}\n" \ "https://docs.google.com/document/d//export?format=txt" --max-time 60 head -c 300 /tmp/anon.txt ``` - **`HTTP 200` + 実サイズ（数百KB〜MB）+ 本文が見える → 公開されている。** - `HTTP 401` + 数KB の HTML → ログイン画面。公開されていない。 `-L`（リダイレクト追従）を忘れないこと。初回は `307` が返るので、 付け忘れると `size=0` になり「落とせない＝安全」と誤読する。 > **この curl の結果をログに残す。** 締めたあとの比較対象になる。 --- ## 2. 順番を絶対に間違えない **いきなり公開を外すと全員が締め出される。** 今そのフォルダに触れている人・ツールの多くが、 公開リンク経由でアクセスしている可能性がある（権限一覧に個別に載っていないなら、まさにそれ）。 正しい順番: ``` 1. 正規の共有（ドメイン共有 / グループ共有）を先に「付与」する 2. 付与できたことを read-back で確認する 3. そのうえで公開（anyone）を「削除」する 4. 未認証 curl が塞がったことを確認する 5. 正規経路がまだ生きていることを確認する ← ここまでやって完了 ``` **5 を省略しない。** 「公開を外せた」は成果の半分でしかなく、 残り半分は「業務を止めていない」ことの証明。 ### 事前に確認しておくこと 締める前に、その資料を使っている**AIツール・自動化がどのアカウントで動いているか**を確認する。 - 社内ドメインのアカウント → ドメイン共有でそのまま動く - 社外アカウント（個人用フリーメール等） → **そのアカウントを個別に追加してから**でないと壊れる これは環境の外を見ないと分からないので、**人に聞く**。ここは省略してよい手間ではない。 --- ## 3. 削除ツールは「安全側」に作る 権限削除は取り返しがつきにくい。使い捨てスクリプトを手で叩くのではなく、 **次の4条件を満たすサブコマンドとして実装**し、再利用できるようにする。 1. **`type: anyone` だけを対象にする。** owner / user / domain / group は絶対に触らない 2. **既定は dry-run。** `--apply` を明示しない限り DELETE を呼ばない 3. **実行後に必ず権限を取り直して `after:` を出す**（read-back を強制する。「消したつもり」を残さない） 4. 対象0件なら「公開なし」と明示して正常終了する（沈黙しない） ```js // 中核部分。フィルタを緩めないこと。 const perms = (await listPermissions(id)).filter((p) => p.type === 'anyone'); if (perms.length === 0) console.log(`anyone 公開なし: ${id}`); for (const p of perms) { if (!apply) { console.log(`[dry-run] would delete: ${JSON.stringify(p)}`); continue; } await deletePermission(id, p.id); console.log(`deleted: ${JSON.stringify(p)}`); } // 必ず取り直す console.log(`after: ${JSON.stringify(await listPermissions(id))}`); ``` `p.type === 'anyone'` を `p.role === 'reader'` などに広げてはいけない。 role で絞ると **正規のドメイン共有（reader）まで巻き込む**。 --- ## 4. 実行と検証 ```bash # 1) ドメイン共有を先に付与 share-domain reader # 2) read-back perms # 3) まず dry-run。対象が想定どおり1件かを目で見る unshare-anyone # → [dry-run] would delete: {"id":"anyoneWithLink","type":"anyone","role":"reader"} # 4) 適用 unshare-anyone --apply # → deleted: {...} # → after: [ ...anyone が消え、他は全部残っている... ] ``` ### 検証チェックリスト | 見るもの | 期待 | |---|---| | 未認証 curl | 実行前 `200`+実サイズ → 実行後 **`401`** | | 落ちてきた中身 | 本文の特徴語が **grep で0件** | | 配下のファイル | 抜き取り数件で「公開なし」（継承で伝播する） | | 他の権限 | **1件も減っていない**（`after:` を実行前と数で突き合わせる） | | 正規経路 | 実際に**取得処理を1回通す**（一覧が見えるだけでは不十分） | **「フォルダを締めたから配下も安全」と推定しない。** 直付けの公開権限が個別に付いている場合がある。 必ず配下も抜き取りで確認する。 --- ## 5. AI エージェントに任せるときの指示のしかた 権限変更は外向きの不可逆操作なので、**判断と実行を分ける**。 - エージェントに任せてよい: 現状調査 / dry-run / 実行後の検証 / ツール実装 - **人が決めること**: そもそも締めてよいか、社外アカウントを残すか 指示の型: ``` 1. <対象> の権限を生API で全件出して。MCP の出力は不完全なので使わないこと 2. 未認証 curl で実際に落とせるか試して、結果（HTTPコードとサイズ）を報告して 3. 締める場合の手順と、それで壊れる可能性があるものを挙げて。実行はまだしないで ``` **エージェント側は、締めたあとに必ず「未認証で落とせないこと」と 「正規経路がまだ動くこと」の両方を実測して報告する。** 権限一覧の見た目で完了報告をしない。 --- ## 6. よくある失敗 | 失敗 | 何が起きるか | |---|---| | いきなり anyone を削除 | 公開リンク経由で使っていた全員とツールが即死 | | MCP の権限一覧だけで判断 | 見えていない権限保持者を見落とす | | `curl` に `-L` を付け忘れ | `307`/`size=0` を「落とせない＝安全」と誤読 | | role で絞って削除 | 正規のドメイン共有まで消える | | 権限一覧を見て完了報告 | 実際には塞がっていない／正規経路が壊れている | | 配下ファイルを確認しない | 直付けの公開権限が残る | | owner でない権限で操作 | 403。impersonate 先の切り替えが要る | --- ## 7. 締めたあとに残る宿題 権限を全件見ると、たいてい**想定外の権限保持者**が出てくる。 個人用フリーメール、退職者、用途不明のサービスアカウント。 これらは**勝手に消さない**。業務が止まる可能性があるし、誰の何用かは環境の外の情報。 **一覧にして人に判断を仰ぐ**ところまでが作業範囲。 ---