# 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 前提 | 要確認 | ### ⚠️ いちばん危ないパターン: 「無ければ作る」名前検索 ```js 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` を直接叩く。** ```js 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. 移動の実行と検証 ```js // 親を差し替える = 移動。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` を指定しない作成。 ```js // これはマイドライブ直下に作られ続ける 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 する ---