Google ドライブで配布していた共有リンクが、ある日を境に一斉に開けなくなることがあります。原因の多くは「フォルダの中身を入れ替えたい」という目的に対して、削除してから同じ名前で作り直すという操作を選んでしまうことです。本記事は、2026-07-10にWEBMARKS社内で実際に起きたこの事故を、症状・誤診・真因・恒久対策の順で追います。根拠はGoogle Drive API公式ドキュメント3件と、自社の対応記録です。
01Google ドライブの共有リンクが切れた｜最初に見えた症状
2026-07-10、WEBMARKS社内でDriveマウント（PC上でクラウドのフォルダをローカルディスクのように操作できる仕組み）経由の整理作業をしていました。あるフォルダの中身を入れ替える目的で、フォルダごと削除してから同じ名前で作り直す操作を実行しました。
作業の直後、それまで配布していた共有リンクを開くと、以前とは違う挙動になりました。フォルダの名前も置き場所も変えていないのに、リンク先が空に見えたり、アクセス権エラーになったりします。名前だけを見比べても異常は分からないため、最初はリンクの不具合か同期の遅延を疑いました。
| 確認した項目 | 削除・作り直し前 | 削除・作り直し後 |
|---|---|---|
| フォルダ名 | 変更なし | 変更なし |
| 置き場所（親フォルダ） | 変更なし | 変更なし |
| 配布していた共有リンクのURL | そのまま使用 | 同じURLを使用 |
| リンクを開いた結果 | 正常に開く | 開けない・中身が違う |
02最初に疑ったこと｜共有リンクの権限設定ミスという誤診
共有リンクが開けないという相談では、リンクの権限設定（「リンクを知っている全員が閲覧可」など）が途中で外れているケースが実務では圧倒的に多く、トラブルシューティングの定石としてまずここを疑うのが自然です。実際、共有設定タブを開き直し、共有範囲が「制限付き」に変わっていないか、招待した相手のメールアドレスが間違っていないかを確認するだけで解決する相談が大半を占めます。
権限設定を疑うこと自体は自然な初動です。「リンクが開けない」という相談の多くは、実際に共有範囲の設定ミスが原因だからです。ただし、この経路には見落としやすい落とし穴があります。フォルダが削除されて作り直されていた場合でも、共有設定タブを開けば、そこには常に「正しい」権限が表示されます。なぜなら画面に出ているのは新しく作られたフォルダ自身の権限であって、配布済みリンクが指している旧フォルダの権限ではないからです（仕組みの詳細は次の章で扱います）。「設定を見ても間違っていない」という表示そのものが、真因から目をそらさせる材料になります。原因切り分けで見立てが外れたときの動き方は『AI運用の障害切り分け｜更新時刻を犯人にしない4段の手順』でも扱っています。
03本当の原因｜共有リンクが切れたのはGoogle ドライブのフォルダIDが変わったから
Google ドライブでは、フォルダやファイルそれぞれに固有のID（file ID）が割り当てられます。共有リンクのURLには、名前ではなくこのIDが直接埋め込まれています。公式ドキュメントは、ファイルIDがそのファイルの存在期間を通じて固定される値だと説明しています。名前を変更しても、このIDは変わりません（出典: Google Drive API公式「About files」ガイド）。
裏を返すと、IDが固定されるのは「そのファイルが存在している間」だけです。フォルダを削除すると、そのIDに紐づく実体はなくなります。公式の削除ガイドは、完全に削除したファイルには共有していた相手もアクセスできなくなると明記しています（出典: 同「Delete files and folders」ガイド）。
そのあとで同じ名前のフォルダを新規作成すると、Google ドライブ側から見ればそれは別の新しいオブジェクトです。作成時にIDを事前予約していない限り、Driveが自動で新しいIDを割り当てます（出典: 同「Create files」ガイド）。名前が同じでも、実体としては別物のフォルダです。
配布済みの共有リンクは、削除される前の古いIDを指したままです。新しく作ったフォルダは別のIDを持つため、古いリンクはそのフォルダ配下に二度と届きません。権限設定を見直しても症状が直らなかった理由は、ここにあります。
この違いは、読者自身の手元でも今すぐ確認できます。配布しているリンクを1つ開き、URLの/folders/の直後にある文字列（ファイルID）を控えます。次に、Google ドライブの「マイドライブ」から対象フォルダを名前で探して開き、そのときのURLのファイルIDと見比べます。2つのIDが一致していれば、そのフォルダは一度も削除・再作成されていません。一致していなければ、名前は同じでも実体が入れ替わっている証拠です。共有設定タブの表示だけでは、この入れ替わりに気づけません。
04どう直したか｜共有リンクのリンク切れを止めた3つの手順
真因が分かった時点でも、フォルダの作り直しそのものを取り消すことはできませんでした。新しいフォルダには新しいIDが振られていて、旧IDに戻す操作は存在しません。実際に行った対応は次の3つです。
- 影響を受けた共有リンクを洗い出し、新しいフォルダ・新しいファイルのURLを取得し直す
- 配布先（社内外の関係者）へ、取得し直したリンクを再配布する
- 今後同じ操作を繰り返さないよう、フォルダの中身を入れ替える手順そのものを変える
3つ目が本質的な対策です。1つ目と2つ目は起きてしまった事故の後始末にすぎません。次に誰かが同じ操作をすれば、同じ事故が繰り返されます。
05二度と起こさないための仕組み｜フォルダの作り直しを禁じ共有リンクを守る運用に変える
WEBMARKSはこの事故のあと、フォルダの中身を入れ替える作業手順を次の3点に変えました。
| 対策 | 具体的にやること | 効く理由 |
|---|---|---|
| ①作り直さない | rmtree（フォルダごと削除）で消して新規作成せず、既存フォルダへ上書きコピーする | フォルダの実体（＝ID）を維持したまま中身だけを差し替えられる |
| ②配布直前に取り直す | リンクを配布する直前に、対象フォルダ・ファイルのURLを毎回取得し直す | 古いリンクを使い回さないため、IDのずれに早く気づける |
| ③全数照合する | クラウド側の親フォルダID（parentId）を列挙し、配布リストと突き合わせる | 目視では気づけない一部フォルダの取りこぼしを検出できる |
①がもっとも効果の大きい対策です。フォルダを削除しない限り、Google ドライブ側のIDは変わりません。中身だけを入れ替えたいときは、削除・再作成ではなく上書きコピーを使います。
ここで見落としやすいのは、IDが割り当てられる単位はフォルダだけではないという点です。フォルダの中の個々のファイルにも、それぞれ独立したIDが割り当てられています（出典: 前掲「About files」ガイド）。フォルダ自体を残していても、中の1ファイルだけを削除して同じ名前で再アップロードすれば、そのファイル単体の共有リンクは同じように切れます。①の対策は「フォルダを消さない」だけでは不十分で、「フォルダの中のファイルも個別に削除せず、既存ファイルへ上書きする」まで徹底してはじめて機能します。
②と③は、①を徹底しても残るずれを検出する仕組みです。人が「今回は削除しない」と気をつけるだけでは、繰り返し作業のどこかで元に戻ります。配布直前のリンク再取得とクラウド側の全数照合を手順に組み込むことで、気をつける対象を人の注意力ではなく手順そのものに置き換えました。機密や配布物を置くフォルダの構成そのものについては『機密をAIエージェントに渡さない｜gitignoreとフォルダ構成』も参考になります。
06同じ失敗を避けるためのチェックリスト
- フォルダの中身を入れ替えるとき、削除してから作り直していないか（上書きコピーで済むか先に確認したか）
- 共有リンクが開けなくなったとき、権限設定だけを疑って終わっていないか（フォルダIDの変化を確認したか）
- 配布の直前に、対象フォルダ・ファイルのリンクを取得し直したか
- クラウド側の親フォルダID（parentId）を列挙し、配布リストと突き合わせたか
- フォルダを削除する操作は、送信・公開と同じように人の承認を通しているか（『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』参照）
