全世界公開になっていた共有ドライブ資料を、業務を止めずに締める

社内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. まず「本当に公開されているか」を証拠で確定する

権限一覧は間接証拠でしかない。未認証で実際に落とせるかどうかが答え。

curl -sL -o /tmp/anon.txt \
  -w "HTTP %{http_code}  size=%{size_download}\n" \
  "https://docs.google.com/document/d/<FILE_ID>/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件なら「公開なし」と明示して正常終了する（沈黙しない）

// 中核部分。フィルタを緩めないこと。
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. 実行と検証

# 1) ドメイン共有を先に付与
share-domain <FOLDER_ID> reader
# 2) read-back
perms <FOLDER_ID>

# 3) まず dry-run。対象が想定どおり1件かを目で見る
unshare-anyone <FOLDER_ID>
#    → [dry-run] would delete: {"id":"anyoneWithLink","type":"anyone","role":"reader"}

# 4) 適用
unshare-anyone <FOLDER_ID> --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. 締めたあとに残る宿題

権限を全件見ると、たいてい想定外の権限保持者が出てくる。 個人用フリーメール、退職者、用途不明のサービスアカウント。

これらは勝手に消さない。業務が止まる可能性があるし、誰の何用かは環境の外の情報。 一覧にして人に判断を仰ぐところまでが作業範囲。