◆ 【ツール配布】散らかったフォルダを仕分けて、間違えたらそのまま丸ごと戻す｜「怖くて自動化できない」を無くす整理ツール(Python標準ライブラリのみ・全コード)

ダウンロードフォルダを開いたら、スクリーンショットとPDFと請求書と名前も忘れた謎のファイルが1,000件近く積み重なっていた、という経験がある人は多いと思う。整理しなければと分かっていても、いざ「拡張子ごとにフォルダへ振り分けるスクリプトを書いて一括で動かそう」と思うと、実行ボタンの手前で指が止まる。理由ははっきりしていて、もし条件を間違えていたら、どのファイルがどこから来たのか分からなくなり、二度と元の並びには戻せないからだ。

実際に手を動かしてみると、この不安は的外れではない。移動先に同名のファイルが既にあると、環境やアプリによっては警告なく上書きされて片方が消える。1,000件のうち999件目まで動いたところで操作ミスや電源断で止まると、残りの1件だけでなく、すでに動いた999件がどこへ行ったのかを自分で覚えていない限り、手作業での復元はほぼ不可能になる。だから多くの人は「危ないから手でやる」を選び、結局は数百件を目視で1件ずつドラッグする羽目になる。整理が必要なほど散らかったフォルダほど、整理する余力がない、という悪循環である。

この記事で配布するのは、この「怖いから自動化できない」を構造的に解消するためのフォルダ仕分けツールである。日付・拡張子・ファイル名のいずれかを基準にファイルをサブフォルダへ移動するだけの単機能のツールだが、動かす前に必ず内容を確認でき、動かした後も必ず全部を元の位置へ戻せることだけに、設計の力点を置いている。Python標準ライブラリだけで書いた1ファイルのツールで、外部ライブラリのインストールは要らない。

■ この無料部分だけでできること

- 手作業のフォルダ整理が、なぜ・どこで事故るのかが構造として分かる

- 「動かす前に確認できる(dry-run)」と「動かした後に全部戻せる(undo)」が、なぜセットでなければ意味がないかが分かる

- 「全部成功か、全部やらないか」という設計判断の中身と、その理由が分かる

- このツールが削除機能をあえて実装しなかった理由が分かる

- 別ドライブ・別ファイルシステムをまたぐ移動を、なぜ検出して中止するのかが分かる

- ツールが無くても、同じ考え方で手作業を安全に進める方法が分かる

無料部分だけで、安全設計の考え方はすべて説明している。読んだうえで「これなら自分でスクリプトを書ける」と判断できた人は、購入せずにそのまま自分の手で作ってもらって構わない。

■ こんなところで止まっていませんか

- ダウンロードフォルダやデスクトップに数百〜数千件のファイルが溜まっていて、整理する気力より先に「間違えたら怖い」が来る

- 一括で移動するスクリプトを自分で書いてみたものの、同名ファイルがあったときの挙動に自信が持てず、実行せずに放置している

- 過去に「上書きされて消えた」経験があり、それ以来ファイルの一括操作そのものを避けている

- スキャンした書類を年月ごとに振り分けたいが、途中で止まった場合の復旧手順を考えると手が出ない

- Finderやエクスプローラーで1件ずつドラッグして整理しているが、数百件を超えたあたりで心が折れる

■ なぜ手作業だと事故るのか

「一括で自動化するのは危ないから、手でやる方が安全」という感覚は、半分正しくて半分間違っている。手作業には手作業なりの事故のパターンがあり、件数が増えるほどそちらの方が起きやすくなる。

まず、数百〜数千件を目視で振り分けると、名前の似たファイルを取り違える。日本語ファイル名は特に、全角と半角の違いや末尾の連番の違いなど、似た表記が並びやすく、疲れてくるほど見落とす。次に、「移動」という操作自体が上書きに弱い。移動先に同名ファイルがあると、OSやアプリによっては警告なく上書きされ、片方が消える。これを手作業で1件ずつ確認するのは、件数が少ないうちはできても、件数が増えると非現実的になる。さらに、途中でやめると中途半端な状態になる。半分だけ移動した状態から、どれをどこから動かしたかを覚えていない限り、手作業での復元はほぼ不可能である。そして最後に、一度消すと戻せない。ゴミ箱を経由しない移動や削除の組み合わせは、特に危険度が高い。

これらは特殊なケースではなく、件数が増えれば増えるほど確率的に必ず起きる種類の事故である。だからこそ、対策は「気をつける」ではなく、機械的な仕組みとして持たせる必要がある。

■ dry-runとundo ― 「戻せる」がなければ自動化する資格がない

このツールの一番の特徴は、移動する前に必ず内容を確認でき(dry-run)、移動した後も必ず全部を元の位置へ戻せる(undo)ことにある。この2つは、どちらか片方だけでは意味が薄い。

dry-runは、実行前に「何がどこへ移動する予定か」を一覧で見せるだけの機能で、このツールでは既定の動作になっている。--execute を付けない限り、ファイルシステムには一切触れない。移動予定の一覧とフォルダごとの件数が画面に表示されるので、意図した通りの仕分けになっているかを、実際に動かす前に自分の目で確認できる。ここまでは、多くの整理ツールにも付いている機能だと思う。

問題は「確認して実行したが、結果が想定と違っていた」ときである。仕分けの基準を間違えていた、フォルダの粒度が細かすぎた、といったことは、dry-runの一覧を見ただけでは気づけないことがある。実際に移動してみて、フォルダ構成が思っていたのと違うことに初めて気づく、というのはよくある話である。このときに「元に戻す手段が無い」状態だと、結局その場でまた1件ずつ手作業に戻ることになり、自動化した意味が消える。

このツールは、移動を実行するたびに、対象フォルダの直下に移動元と移動先の対応を記録したCSVを必ず出力する。ファイル名は実行日時を含む形式になっていて、このCSVを指定して--undoを実行すると、記録どおりに全部を元の位置へ戻せる。しかも undo 自体も dry-run が既定になっていて、何が・どこへ戻る予定なのかを確認してからでないと実行できない。「戻すつもりが、間違えてさらに状況を悪化させた」という二次事故を防ぐためである。

戻す前には、移動先のファイルが実際に存在しているか、復元先に別のファイルが既にできていないかを全件チェックする。1件でも問題があれば、1件も戻さずに中止する。これは後述する「全部成功か、全部やらないか」という設計方針を、undoの側にもそのまま適用している形である。

もうひとつ、地味だが重要な設計判断がある。移動記録のCSVが空、つまり1件も記録が無い状態でundoを実行すると、このツールはエラーで停止する。一見、空なら何もせず正常終了すればよさそうに思えるが、それでは「戻したつもりで、実は1件も戻っていない」ことに気づけない。undoは取り返しをつけるための最後の手段なので、「静かに何もしていない」を成功として扱ってはいけない、という判断でこうなっている。逆に、戻す件数が1件以上あって実際に戻し終えたときは、「12件を元の位置へ戻しました」のように、必ず件数を画面に出す。件数が出ることで、想定していた件数と一致しているかを自分で照合できる。

「間違えたときに戻せない」という不安こそが、人がファイル整理の自動化に踏み切れない最大の理由だと思う。dry-runは「間違いに気づく前段階」を、undoは「気づいた後の復旧」を担っていて、この2つが揃って初めて、知らないフォルダに対して安心して一括処理を任せられるようになる。

■ 全部成功か、全部やらないか ― 衝突は1件でも見つかった時点で止める

このツールのもうひとつの柱が、「途中まで動いた状態を絶対に作らない」という設計である。

移動を始める前に、対象になっているすべてのファイルについて、移動先を計算して検査する。検査するのは次の3つである。移動先に既に同名のファイルがあるかどうか、この実行の中で複数のファイルが同じ移動先に集まってしまう(重複)かどうか、そして移動先として使うフォルダの名前と同じ名前の「ファイル」が既に存在していないかどうか。この3つのうち1件でも当てはまれば、実際の移動処理には一切入らず、衝突の一覧と理由を表示して終了する。1件も動かさずに、である。

この設計にしているのは、「途中まで動いた状態」がいちばん収拾がつかないからである。1,000件のうち800件が新しい場所へ移動し、残り200件が衝突で止まったとする。この状態から手作業で元に戻そうとすると、「どのファイルが動いた後で、どのファイルがまだ元の場所にあるのか」を、フォルダを1つずつ開いて自分の目で確認しなければならない。仕分け先が日付や拡張子で分かれていればなおさら、全部のフォルダを見て回る必要がある。これに比べれば、「1件も動かず、衝突の一覧だけが表示される」方が、はるかに次にやることが分かりやすい。表示された衝突の一覧を見て、該当するファイルの名前を変えるなり、移動先を調整するなりしてから、もう一度dry-runからやり直せばよい。

「全部成功か、全部やらないか」は、データベースの世界でいうトランザクションの考え方に近い。中途半端な状態を許さないことで、失敗したときの対処を「今どこまで進んだかを調べる」から「最初からやり直す」に単純化できる。件数が多くなるほど、この単純さの価値は上がる。

■ 削除機能を作らなかった理由

整理ツールを作るとなると、「移動」だけでなく「不要なファイルを消す」機能まで欲しくなるかもしれない。このツールには、削除に相当する機能を一切実装していない。--deleteのようなオプションも存在しないし、コードの中にos.removeやos.unlink、shutil.rmtreeの呼び出しも一つも無い(実際にgrepで数えると0件になる)。

理由は単純で、削除は移動と違って、undoで元に戻せる性質の操作ではないからである。移動であれば、移動元と移動先の対応をCSVに記録しておけば、後から逆方向にos.renameするだけで完全に復元できる。ところが削除は、ファイルの中身そのものを失う操作であり、記録として残せるのは「何を消したか」という事実だけで、消した中身は戻せない。undoを前提にした設計の中に、undoできない操作を1つでも混ぜてしまうと、「このツールはundoで戻せる」という前提そのものが崩れる。使う側からすると、どの操作が戻せて、どの操作が戻せないのかを毎回覚えておく必要が出てきて、結局「怖いから使わない」に逆戻りしてしまう。

もう一つの理由は、そもそも「消してよいかどうか」の判断は、機械的な基準だけでは決められないことが多いという点である。拡張子や更新日時だけを見て「これは不要」と判定するのは、仕分け(どこに置くか)よりもずっとリスクが高い判断で、業務知識や記憶に依存する。このツールが担当するのは、あくまで「どこに置くか」までであって、「要るか要らないか」を決めるのは使う人自身の役目にしている。移動して空になった元のフォルダも、このツールは消さない。空フォルダが残ること自体は無害だが、「勝手に何かが消える」という体験を一つでも作らないことを優先した。

■ 別ファイルシステムをまたぐ移動を、なぜ検出して中止するのか

このツールはファイルの移動にos.renameだけを使っていて、コピーは一切行わない。同じファイルシステム(同じドライブ・同じボリューム)の中であれば、os.renameは名前の付け替えに近い軽い処理で、処理の途中で中断されても、ファイルの中身が壊れたり消えたりすることはない。

ところが、別のドライブや別のファイルシステムをまたぐ移動になると事情が変わる。OSの内部では、実質的に「新しい場所へコピーしてから、元のファイルを消す」という2段階の処理に置き換わる。ファイルサイズが大きい場合や、対象件数が多い場合、この2段階の処理が全部終わる前に中断される可能性が、同一ファイルシステム内での移動よりも明確に高くなる。もし「コピーは完了したが、元の削除はまだ」という状態で中断されると、同じ内容のファイルが両方の場所に残ってしまう。逆に「削除は済んだが、コピー先の書き込みが中途半端」という状態で中断されると、最悪の場合はファイルの中身そのものを失う。どちらのパターンも、移動記録のCSVをもとにした通常のundo(単純な逆方向のos.rename)では正しく復元できない。

そのためこのツールは、実際にファイルを1件でも動かし始める前に、対象になっているすべてのファイルの所属ファイルシステムを調べる。対象フォルダと異なるファイルシステム上にあるファイルが1件でも見つかった時点で、フォルダの作成や移動を一切始めずに中止する。これも「全部成功か、全部やらないか」と同じ考え方の延長で、リスクの高い操作を機械的に検出して、そもそも手を付けないという判断をしている。undoを実行するときも同様に、戻し先のファイルシステムが揃っているかどうかを事前に確認してから処理を始める。

実務上は、外付けドライブに保存したファイルを、別の外付けドライブや内蔵ストレージへまとめて仕分けたい、という場面で引っかかることがある。その場合は、いったん同じドライブの中で仕分けてから、必要な単位でコピーする、という2段階に分けて対応するのが安全である。

■ なぜ日付・拡張子・名前の3方式だけなのか

このツールは仕分けの基準として、更新日時・拡張子・ファイル名の先頭の共通部分という3つしか用意していない。「もっと賢く、内容を見て分類してほしい」と思う人もいるかもしれないが、これは意図的にそうしている。

理由は、この3つが「機械的に決まり、かつ人によって解釈がぶれない」基準だからである。更新日時はファイルシステムが持っている値をそのまま使うだけで、判定に迷う余地が無い。拡張子も同様に、ファイル名の末尾から一意に決まる。ファイル名の先頭の共通部分についても、区切り文字という明確なルールで切り出しているので、同じファイル名を入力すれば誰がやっても同じフォルダ名になる。これに対して、「ファイルの中身を読んで意味を判定する」ような分類は、境界を判断する基準が曖昧になりやすく、判定を間違えたときに「なぜそう分類されたのか」を後から追いにくい。安全設計を重視するツールほど、判定の根拠が誰の目にも明らかな基準だけを使うべきだと考えている。

もう一つの理由は、拡張子のグループ分け(EXT_GROUPS)やファイル名の区切り文字(NAME_DELIMS)を、コードの冒頭にある定数として1箇所にまとめている点に表れている。判定のロジックを複雑にする代わりに、判定の材料になる対応表を使う人が自分の業務に合わせて書き換えられるようにしておくほうが、結果的に自由度が高くなる。複雑な自動判定を1つ作り込むより、単純な基準を複数用意して、必要なら自分で対応表を調整できるようにするほうが、長く使えるツールになると考えている。

■ 手作業で同じ安全性を再現する方法

ツールを使わなくても、ここまで説明してきた考え方は、表計算ソフトと自分の注意力があれば手作業でも再現できる。手順は次のようになる。

まず、ファイルを動かす前に、「どのファイルを・どこへ動かすか」の一覧を、表計算ソフトに全部書き出す。この時点ではまだ1件も動かさない。これがdry-runに相当する。一覧ができたら、移動先の列を並べ替えて、同じ移動先が2回以上出てきていないかを目で確認する。加えて、移動先に指定したフォルダ名と同じ名前のファイルが、対象フォルダの中に既に存在していないかも、Finderやエクスプローラーの検索で確認しておく。この2つのチェックで問題が1件でも見つかったら、その時点では1件も動かさず、一覧を直してから最初からやり直す。これが「全部成功か、全部やらないか」を手作業で再現する部分にあたる。

チェックが済んだら、実際にファイルを動かす。このとき、1件動かすごとに、その表計算ソフトの一覧に「動かし終えた」の印を付けていく。全部を一度に動かそうとせず、印を付けながら進めることで、途中で中断しても「どこまで終わったか」が一目で分かる状態を保てる。この一覧そのものが、このツールでいう移動記録CSVの役割を果たす。もし後で戻したくなったら、この一覧を逆向きに読み、移動先から移動元へ、印を付けた順とは逆順にファイルを戻していけばよい。

手作業でここまでやるのは、正直なところかなり手間がかかる。だからこそ、件数が数十件を超えたあたりからは、機械的にミスなくこなせるツールに置き換えたほうが、時間の面でも正確さの面でも見合うようになる。逆に言えば、数件〜十数件程度であれば、無理にツールを使わず、この手順で手作業のまま安全に進めても十分だと思う。

■ ここから先に入っているもの

無料部分で、手作業のフォルダ整理が事故る理由、dry-runとundoの設計、全部成功か全部やらないかという方針、削除機能を作らなかった理由、別ファイルシステムをまたぐ移動を中止する理由、そして手作業での再現方法まで、すべて説明した。ここまでの内容だけで、自分の環境に合わせて同じ考え方のスクリプトを書ける人は、この先を購入する必要はない。

ここから先には、実際に手を動かしてすぐに試すための完成品を置いている。

- folder_sort.pyの全文(省略なし。標準ライブラリのみで動く、1ファイルで完結するツール)

- 動作確認用に、あえて散らかったテストフォルダを作るスクリプト(make_testdata.sh)の全文。そのまま実行すればすぐに試せる

- 3つの仕分け方式(日付・拡張子・名前)の使い方と、自分の環境に合わせて調整する具体的な手順

- 利用条件と免責事項

■ ツール本体(folder_sort.py・全文)