共有ドライブにファイルを移動できない原因と確実な移し方

マイドライブに溜まった案件のフォルダを、そのまま共有ドライブへドラッグした。けれど「移動できません」と出る。あるいはエラーも出ないのに、画面を更新したらファイルは元の場所に残っている。Google Workspace で共有ドライブへの移行を始めた会社が、ほぼ必ず一度は踏む場所です。

この記事は、Mihata が 2026 年に自社の案件書類をマイドライブから共有ドライブへ移したときの実測と、Google の公式ヘルプで裏が取れた仕様だけを突き合わせてまとめたものです。手元で確かめていない手順は書いていません。

結論：原因は4つしかない

共有ドライブにファイルを移動できない理由は、実質的に「権限」「フォルダ単位の制約」「オーナー」「管理者設定」の4つに絞れます。この4つのどれかを潰せば、ほぼすべてのケースで移動できるようになります。

そして最初に知っておくべき仕様がひとつあります。フォルダを階層ごと共有ドライブへ移すのは、ふつうのメンバーにはできません。Google ドライブの公式ヘルプは「フォルダを共有ドライブに移動できるのは、その共有ドライブの管理者のみです」と明記しています。さらに Drive API 経由では、フォルダの親を共有ドライブへ付け替えようとすると 403 の teamDrivesFolderMoveInNotSupported（Moving folders into shared drives is not supported）が返ります。つまり「フォルダが動かない」のは不具合ではなく、そういう作りです。

いちばん短い道は、移行先に受け皿のフォルダを手で作り直し、ファイルだけを移すこと。Mihata が結局そうしましたし、Google 自身も API のエラー解説で「フォルダの中のアイテムを個別に移す」ことを回避策として挙げています。

症状 → 原因 → 最初に見る場所

自分がどれに当たっているかを先に決めてしまったほうが早いので、表にしました。「エラー文がそのまま出ているか」で枝が分かれます。

そもそもどの書類を共有ドライブに置き、どれをマイドライブに残すかで迷っているなら、先に共有ドライブとマイドライブの使い分けを整理してから移したほうが、移動のやり直しが減ります。

原因1：移動先での権限が足りていない

いちばん多い原因です。共有ドライブは「メンバー全員が全ファイルを見られる」仕組みなので、見えていることと動かせることが一致しません。見えるのに移せない、はふつうに起きます。

Google Workspace ラーニング センターの権限表では、操作ごとに必要な役割がこう決まっています。

「投稿者」は編集とアップロードはできても、移動と削除ができない役割です。ここが落とし穴で、ファイルをアップロードできるから権限は足りているはずだと思ってしまう。確かめる手順はこうです。

1. ブラウザで drive.google.com を開き、左の「共有ドライブ」から移動先の共有ドライブを開く。
2. 上部の共有ドライブ名をクリックし、「メンバーを管理」を開く。
3. 自分のアカウントの横に出ている役割を読む。閲覧者・コメント投稿者ならファイル1個も移せません。投稿者ならマイドライブからのファイル移動はできますが、共有ドライブ内の移動はできません。
4. 足りないなら、その共有ドライブの管理者に役割の引き上げを頼む。移行作業をする人は、作業中だけ管理者にしてもらうのがいちばん揉めません。
5. 役割を変えた直後は反映に数分かかります。公式のトラブルシューティングでも「新規作成直後の場合は数分待機」と案内されています。すぐ再試行して失敗しても、慌てないこと。

なお、移動元（マイドライブ側）にも条件があります。公式ヘルプは「デフォルトでは、自分がオーナーであるファイルとフォルダのみを移動できます」と書いています。人から共有してもらっただけのファイルは、設定次第で移せません。これは原因3と原因4の話につながります。

原因2：フォルダは階層ごと移せない（Mihata の実測）

ここが、この記事でいちばん伝えたいところです。

Mihata は 2026 年に、マイドライブに積み上げていた案件書類を共有ドライブ「Mihata 案件」へ移しました。案件ごとにフォルダが切られていたので、当然フォルダ単位でまとめて移そうとしました。結果はこうです。

Drive API では 403 が返る

自動化のために Drive API でフォルダの親（parents）を共有ドライブへ付け替えようとしたところ、403 が返って一歩も進みませんでした。Google の API エラー解説に載っているとおりの挙動で、エラーコードは teamDrivesFolderMoveInNotSupported、メッセージは「Moving folders into shared drives is not supported.」です。回避策として公式が挙げているのも、やはりフォルダの中のアイテムを個別に移すか、管理者としてドライブの画面から操作するかの2つだけでした。

つまり、スクリプトでフォルダ構造ごと一気に引っ越す、という設計自体が成立しません。移行ツールを自作するつもりなら、最初から「受け皿のフォルダを作る処理」と「ファイルを移す処理」に分けて組む必要があります。

パソコン版ドライブの mv は、黙って元に戻る

いちばん危ないのはこちらでした。Drive for desktop（Finder やエクスプローラに出てくる Google ドライブ）で案件フォルダを共有ドライブ側へ移動したところ、その場では何のエラーも出ず、見た目には移動が完了しました。ところが時間を置いて見ると、ファイルは元の場所に戻っています。警告も通知もありません。

これは Google 公式のトラブルシューティングにも書かれていて、「フォルダをマイドライブから共有ドライブに移動できない」の対処として「パソコン版ドライブでは移動非対応（ウェブ版を使用）」と案内されています。対応していない操作なので、同期の側で元の状態に巻き戻されるわけです。

怖いのは、作業した本人が「移した」と思い込むことです。Mihata では台帳の案件行に「共有ドライブへ移行済み」と書いた直後に、実体はマイドライブに残っていました。移行作業は必ずブラウザ版（drive.google.com）で行い、終わったらブラウザ側で移動先を開いて実体を目視する。これを手順に入れておかないと、移行したつもりの書類が静かに取り残されます。

管理者でも、フォルダ移動には条件がつく

共有ドライブの管理者であればブラウザ版からフォルダを移動できます。ただし公式の管理者向けヘルプによると、フォルダの中に移せないアイテムが「25 個以上」または「移動するアイテム数の 10% 以上」のいずれか小さい方を超えると、フォルダ移動そのものが拒否されます。移せないアイテムとは、たいていオーナーが組織外・退職者・別アカウントのファイルです。

また一度に 100,000 個を超えるアイテムを移そうとする場合は、分割するよう案内されています。案件フォルダ数十個ぶんであれば件数は問題になりませんが、「25 個の壁」は現実的に効きます。古いフォルダほど、過去に人から共有されたファイルが混ざっているからです。

原因3：オーナーが共有ドライブのメンバーではない

共有ドライブはファイルのオーナーが個人ではなくチーム（組織）になる場所です。公式ヘルプも「作成したファイルを共有ドライブに移動すると、共有ドライブがそのファイルのオーナーになります」と明記しています。だからこそ、移す前のオーナーが誰かが効いてきます。

Drive API のエラー一覧には fileOwnerNotMemberOfTeamDrive という 403 があり、対処として「移動する前に、ファイルのオーナーを共有ドライブに追加する」と書かれています。ブラウザ版でも実質は同じで、公式のトラブルシューティングは「ファイルを共有ドライブに移動できない」の確認項目として「ファイルのオーナーが組織内にいるか確認」を挙げています。

Mihata でもここで止まりました。以前使っていた個人アカウントが所有者のままになっている書類は、どうやっても移せず、保留にするしかありませんでした。オーナーが組織外、あるいは解約済みのアカウントだと、その場での打ち手がありません。手順としては次の順で詰めます。

1. 移せないファイルを選び、右クリック →「詳細を表示」でオーナーを確認する。マイドライブで「オーナー」列を出しておくと一覧で見えます。
2. オーナーが在籍中の社内メンバーなら、その人を移動先の共有ドライブのメンバー（投稿者以上）に追加してから、もう一度移す。
3. オーナーが社内だが本人に作業を頼めない場合は、管理コンソールからそのファイルのオーナー権限を移管してもらってから移す。
4. オーナーが組織外・退職済み・別アカウントなら、移動は諦めて、必要な書類だけコピーを作る。コピーを作った人が新しいオーナーになるので共有ドライブへ移せますが、コメントと版履歴は引き継がれません（後述）。代わりに、元ファイルは消さずに残し、台帳に「原本は旧アカウント所有」と書き添えておきます。
5. 退職者のファイルがまとまって残っているなら、1件ずつではなく退職者のファイルを引き継ぐ手順として先に処理したほうが早いです。

ちなみに、オーナーが組織内のユーザーで共有ドライブのメンバーではない場合、移動は通りますが「ファイルのオーナー権限は失われますが、引き続きアクセスできます」と公式は書いています。オーナーが消えることそのものは仕様です。

原因4：管理コンソールの移行設定で止まっている

役割は足りている。オーナーも社内。それでも社内の誰も移動できない。この場合は管理者側の設定を見ます。

Google Workspace の管理者ヘルプには、ドライブとドキュメントの移行設定として「共有ドライブへのファイルの移行をユーザーに許可する」というチェックボックスがあり、これがオンかどうかで、ファイルのオーナーおよび編集者が共有ドライブへ移動できるかが決まると書かれています。オフになっていれば、どれだけ権限を積んでも移せません。

確認と切り替えは特権管理者の作業です。

1. 管理コンソール（admin.google.com）にログインする。
2. 「アプリ」→「Google Workspace」→「ドライブとドキュメント」を開く。
3. 移行に関する設定を開き、「共有ドライブへのファイルの移行をユーザーに許可する」がオンになっているかを確認する。
4. 設定は組織部門（OU）ごとに持てるので、移行作業をする人が属している OUで見る。全社はオンでも、特定の部署だけオフ、ということが起きます。
5. 変更後は反映に時間がかかります。すぐ試して失敗しても設定ミスとは限らないので、少し待ってから再試行する。

同じ画面には、共有ドライブのメンバー以外と共有してよいか、組織外のユーザーと共有してよいかといった共有の設定も並んでいます。移行そのものは通るのに「移した瞬間、社外の協力会社から書類が見えなくなった」という形で問題が出るのは、たいていこちらです。マイドライブでフォルダごと共有していたものが、共有ドライブではメンバー制に変わるからです。

Mihata の場合、外部パートナーに渡していた案件フォルダは、共有ドライブ配下ではフォルダをまるごと渡すのをやめ、必要なアイテムだけを個別に共有する形に切り替えました。共有ドライブは「メンバーなら全部見える」が既定なので、パートナーをメンバーに入れると見せたくないものまで見えてしまいます。アイテム単位の共有は手間ですが、事故が起きません。

こうした移行のつまずきは、権限の設計と作業手順をいっしょに決めてしまえば一度で片付くものが多いです。私たちは Google Workspace の整理や社内の運用づくりのお手伝いもしています。記事の途中で恐縮ですが、よろしければ合わせてご覧いただけたら嬉しいです。

確実に移すための段取り

Mihata が最後に落ち着いたやり方です。フォルダを動かそうとするのをやめた時点で、急に素直に進みました。

1. 移行先に受け皿のフォルダを手で作り直す

共有ドライブを開き、移したいフォルダと同じ名前・同じ階層のフォルダを先に作ります。フォルダは移せないので、構造だけ先に用意するわけです。案件フォルダのように型が決まっているなら、この時点で命名規則を揃えてしまうと後が楽になります。移行はフォルダ名を整理できる唯一の機会でもあります。

2. ブラウザ版で、ファイルだけを選んで移す

1. drive.google.com をブラウザで開く（パソコン版ドライブの Finder／エクスプローラでは行わない）。
2. マイドライブ側で元のフォルダを開き、中のファイルだけを選ぶ。フォルダが混ざっているとそこで弾かれるので、サブフォルダは選択から外す。
3. 右クリック →「整理」→「移動」で、1 で作った受け皿フォルダを指定する。
4. 「オーナーが変わります」といった確認が出たら内容を読んで進める。共有ドライブに入れた以上、オーナーは組織になります。
5. サブフォルダは、受け皿側に同じ名前のフォルダを作ってから、同じ手順を繰り返す。階層が深いなら上から順に。
6. 移し終わったらブラウザで移動先を開き、件数と中身を目で見て確認する。パソコン版ドライブの表示では確認にならない。

3. 貼ってある URL を貼り替える

ここを忘れると、移行の翌日に「リンクが開かない」と言われます。

ファイル自体の ID は移動しても変わらないので、個々のファイルへのリンクは生きたままです。危ないのはフォルダの URLのほうで、受け皿を作り直した以上、新しいフォルダは別物＝別の URL です。案件台帳や進行管理表、提案書、過去のメールで「この案件のフォルダはこちら」とフォルダ URL で案内していた箇所は、ぜんぶ切れます。

1. 移行した案件ごとに、新しいフォルダの URL を控える。
2. 案件台帳・管理シートのフォルダ URL 列を、新しい URL で上書きする。
3. 社内の Doc・スプレッドシート・チャットの固定メッセージに貼られたフォルダ URL を検索して差し替える。
4. 社外に案内していた共有リンクは、アイテム単位の共有に切り替えたうえで、新しいリンクを渡し直す。渡し直す前に、相手のアカウントで開けるかを必ず確認する。
5. 権限が理由でリンクが開けないときの切り分けは共有リンクが開けないときの確認順が使えます。

4. 元のフォルダはすぐ消さない

中身が空になった元フォルダは、しばらく残しておきます。移せずに残ったファイル（オーナーが組織外のもの）がそこに居るはずで、それが「保留リスト」そのものになります。空だと確認できてから消す。削除は最後です。

やってはいけない手当て

ダウンロードして再アップロードする

いちばんやりたくなる手ですが、いちばん失うものが多いです。ダウンロードして上げ直すと、それは別のファイルになります。版履歴もコメントも、元のファイルに紐づいているので付いてきません。Google ドライブの版履歴は「版を管理」から辿れますが、これはそのファイルに蓄積されているもので、新しく作ったファイルには最初から何もありません。公式も版について「30 日後、または 100 個の新しい版が作成された場合に、完全に削除される可能性があります」と書いており、元ファイルを消してしまえば取り戻す手段はなくなります。

どうしてもコピーで逃げるしかない場合（オーナーが組織外のとき）は、元ファイルを削除しない、コピーであることを台帳に残す、この2つを必ずセットにしてください。

パソコン版ドライブで移動して、できたことにする

前述のとおり、エラーを出さずに元へ戻ります。移行の記録だけが先に進んでしまうのが最悪で、半年後に「あの契約書どこ」になります。移行はブラウザ版で、確認もブラウザ版で。

とりあえずフォルダごとドラッグして、エラーの意味を読まない

「移動できないファイルが多すぎます」は権限の話ではなくオーナーの話です。ここで役割を上げても直りません。読み替えると「この中に、オーナーが組織外のファイルが混ざっています」という意味なので、やることはフォルダの権限いじりではなく、中身のオーナー確認です。

保存できない・同期しないまま移行を続ける

移行中にブラウザ側で「変更を保存できませんでした」が出ているなら、移動の前にそれを片付けます。変更を保存できませんでしたの直し方で挙げている原因（別タブ・別アカウント・オフライン）が残っていると、移動の成否そのものが判定できなくなります。

まとめ：今日やる順番

長く書きましたが、やることは少ないです。上から順に。

1. ブラウザ版を開く。パソコン版ドライブでの移動はそもそも対応していないので、ここを間違えていると以降が全部無駄になります。
2. 移動先の共有ドライブでの自分の役割を見る。ファイルを入れるだけなら投稿者以上、共有ドライブ内で動かすならコンテンツ管理者以上、フォルダを動かすなら管理者。
3. フォルダごと移すのを諦め、受け皿フォルダを手で作る。フォルダ移動は管理者限定で、API では 403 になります。構造は作り直すほうが速い。
4. ファイルだけを移す。弾かれたファイルはオーナーを見る。社内なら共有ドライブのメンバーに入れてから再試行、組織外なら保留にする。
5. 社内の誰も移せないなら管理コンソールを見る。「共有ドライブへのファイルの移行をユーザーに許可する」がオフになっていないか。
6. 台帳と資料のフォルダ URL を貼り替える。ファイルのリンクは生きていますが、フォルダのリンクは切れます。
7. 元フォルダが空になったことを確認してから消す。残っているものが保留リストです。

移行は一度やれば終わる作業ですが、途中で「移したつもり」が混ざると、あとから効いてきます。手間なのは移動そのものではなく、移せなかったものを把握しておくことです。