Google Drive のフォルダ整理を、自動化を壊さず権限事故も出さずにやる

散らかったマイドライブを片付けたい。でも自動化が動いていて、フォルダを動かすと壊れるかもしれない——そういう状況で、何を確認してから動かすかを順に決めるための指示書。

結論を先に書く。フォルダ移動そのものはほぼ安全（Drive のフォルダ ID は移動しても変わらない）。危ないのは権限のほうで、共有フォルダへ移すと公開範囲が黙って広がる。多くの人がこれを逆に捉えて、安全な移動を怖がりつつ危険な権限変更を無自覚にやる。

---

0. 前提

• Google Workspace + Google Drive
• Drive API v3 を叩ける手段（サービスアカウント + ドメイン全体の委任、または OAuth）
• 自動化のソースコードがローカルにある（GAS / Node / Python 問わず）

---

1. まずコードを調べる — 「ID 参照」か「名前検索」か

フォルダ ID は移動しても不変。だから ID 直書きの参照は移動しても壊れない。 壊れるのは名前や場所で探している実装だけ。

次のパターンを全プロジェクトから grep する。

探す文字列	参照方式	移動の影響
getFolderById( / folderId / FOLDER_ID / parents:	ID 直書き	壊れない
DriveApp.getFoldersByName( / DriveApp.searchFiles(（スコープ指定なし＝Drive 全体検索）	全体検索	壊れない（場所非依存）。ただし同名衝突には注意
<親フォルダ>.getFoldersByName( / files.list({q: "'ID' in parents and name = ..."})	親フォルダ直下限定の名前検索	⚠️ 要注意（下記）
getRootFolder() / parentId: 'root'	root 前提	要確認

⚠️ いちばん危ないパターン: 「無ければ作る」名前検索

const it = parent.getFoldersByName('案件');
const target = it.hasNext() ? it.next() : parent.createFolder('案件');

これは子フォルダだけを別の場所へ動かすと、見つからず同名フォルダを新規作成して二重化する。しかも 例外が飛ばないので誰も気づかない。数週間後に「データが消えた」「半分しか出ない」として発覚する。

対策は単純: フォルダは丸ごと動かす。中身をバラして別々の場所に置かない。 親フォルダごと移動する限り、親は ID で解決されるので子の直下検索も従来どおり当たる。

---

2. 権限の実態を「API で」確認する — UI と MCP を信用しない

ここが本番。共有フォルダへ移動すると、そのフォルダの権限を継承する。

落とし穴 1: 簡易 API は権限を過少報告する

ラッパー系のツール（各種 MCP コネクタ等）の「権限を取得」は直接権限しか返さないことがある。実測で 13 件付いているフォルダが 2 件しか返らなかった。これを見て「共有されていない」と判断すると事故る。

Drive API の permissions.list を直接叩く。

import { google } from "googleapis";

const auth = new google.auth.JWT({
  email: creds.client_email,
  key: creds.private_key,
  scopes: ["https://www.googleapis.com/auth/drive"],
  subject: "<代理実行するユーザーのメールアドレス>", // ドメイン全体の委任
});
const drive = google.drive({ version: "v3", auth });

const perms = await drive.permissions.list({
  fileId: "<フォルダID>",
  fields: "permissions(id,type,role,emailAddress,domain,displayName,permissionDetails(inherited,inheritedFrom,role))",
  supportsAllDrives: true,
  pageSize: 100,
});

落とし穴 2: permissionDetails.inherited はマイドライブでは埋まらない

permissionDetails は共有ドライブ専用フィールド。マイドライブのファイルでは継承元が取れない。つまり 「誰がアクセスできるか」は分かるが「どこで付与されたか」は分からない。 ここを誤解して「DIRECT と出たから外せる」と判断しない。

継承かどうかを実地で確かめる方法: 対象フォルダの中に空のテスト用フォルダを 1 つ作り、その権限を見る。新規作成物は親の権限をそのまま継承するので、これがその場所の実効的な権限になる。

---

3. 移動先の権限を、移動前に必ず見る

整理前に、移動元と移動先の両方で permissions.list を実行し、差分を見る。

実例（実際にあったケース）:

場所	権限
マイドライブ直下	所有者 + ドメイン全体が 閲覧者（2 件）
「作業用」共有フォルダ	上記 + 部門グループ 7 件が 編集者、個人 3 名が 編集者、社外の個人アカウント 1 件が編集者（13 件）

つまり「散らかっているから作業用フォルダにまとめよう」は、全社員に編集・削除権を配り、社外アカウントにも見せる操作だった。整理のつもりが権限緩和になる。

判断基準: 移動先の権限一覧に、移動するデータを見せたくない相手が 1 人でもいたら、そこへ移動しない。

---

4. 「機密用フォルダ」を作るときの鉄則

継承権限は子フォルダ側から削除できない

共有フォルダの中に「機密」サブフォルダを作って権限を剥がそうとすると、Drive API はこう返す。

The authenticated user cannot delete the permission.
If the permission is inherited, limited access must be leveraged.

つまり共有された場所の下に隠し場所は作れない。 名前だけ「機密」にして中身は丸見え、という最悪の状態になる。

正しい作り方: 共有された親の「外」に作る

1. 共有 subtree の外（マイドライブ直下など、権限の薄い場所）にフォルダを作る
2. そこに残る直接権限（ドメイン共有など）は削除できる
3. permissions.list で read-back verify し、所有者 1 件だけになったことを確認する

すでに共有配下に作ってしまった場合は、そのフォルダを共有 subtree の外へ移動すると継承が切れて直接権限だけが残る。実際にこれで 13 件 → 1 件にできた。

---

5. 権限削除スクリプトに必ず入れる安全機構

権限の一括削除は不可逆で、外部にも影響する。最低限これらを実装する。

• 既定は dry-run。 --apply を明示しない限り permissions.delete を呼ばない
• 対象 ID は 1 個だけ受け付ける（複数渡されたらエラー。取り違え防止）
• role === 'owner' は絶対に削除しない
• 対象が空フォルダであることを確認し、子が 1 件でもあれば --apply 付きでも中断する。--force は作らない
• 1 件ずつ削除し、何を消したかをログに出す。失敗しても次へ進み、最後に成功数／失敗数を集計
• 実行後に permissions.list で read-back verify。所有者以外が残っていたら非ゼロ終了

---

6. 移動の実行と検証

// 親を差し替える = 移動。ID は変わらない
await drive.files.update({
  fileId: "<動かすフォルダID>",
  addParents: "<新しい親のID>",
  removeParents: "<今の親のID>",
  fields: "id, name, parents",
});

• コピーで代用しない。 files.copy は新しい ID の複製を作るので、ID 参照している自動化が古い方を見続ける
• マイドライブ ⇔ 共有ドライブをまたぐ移動はしない（権限体系が変わり、サービスアカウントのアクセスが落ちる）
• 移動後は必ず files.list({q: "'<新しい親のID>' in parents"}) で read-back verify

---

7. 稼働中の自動化フォルダは「据え置き」でよい

技術的に移動可能でも、動かす利得が「見た目が片付く」だけなら動かさない。次は据え置き推奨。

• ジョブキュー・コマンドキューの実体フォルダ
• 定期バッチが ID 参照している入出力フォルダ
• コンテナバインドのスクリプトが紐づくファイル
• キャッシュフォルダ

事故時の影響が整理の利得を上回る。「動かせる」と「動かすべき」は別。

---

8. 散らかりの「再発源」を止める

片付ける前に、そもそも誰が散らかしているかを突き止める。よくあるのは parents を指定しない作成。

// これはマイドライブ直下に作られ続ける
await drive.files.create({
  requestBody: { name: `PJ ${customer}`, mimeType: "application/vnd.google-apps.folder" },
});

parents: ["<置き場所のID>"] を足すだけで止まる。再発源を潰さずに片付けると、同じ作業を毎月やることになる。

なお「root に作ってから所定フォルダへ移動する」実装（GAS の createFolder は必ず root に作るのでこの形になる）は、移動まで完了していれば root に残らないので問題ない。root に溜まっているものだけが再発源。

---

実行順チェックリスト

1. 自動化コードを grep し、ID 参照 / 全体検索 / 直下限定の名前検索 に分類する
2. 移動元と移動先の権限を permissions.list で取得して差分を見る（簡易 API は信用しない）
3. 移動先に見せたくない相手がいないか確認する
4. 機密用の置き場が要るなら共有 subtree の外に作り、権限を剥がして read-back verify
5. フォルダは丸ごと移動する（addParents/removeParents）
6. 稼働中の自動化フォルダは据え置く
7. 再発源（parents 未指定の files.create）を修正する
8. 移動後に files.list で read-back verify する