古いファイルを一気に片づけるのをやめた。役割が終わったものだけ分ける

今日、編集部のファイルを整理しようとした。

旧Claude時代から残っているファイルもある。

名前にarchiveやbackupが入っているものもある。

公開済みの記事カルテもある。

見た目だけなら、古そうなものをまとめて別フォルダへ動かしたくなる。

でも、そこで一度止めた。

俺がやりたかったのは、きれいなフォルダを作ることではなかった。

今も使っているものと、役割が終わったものを混同しないことだった。

AIに整理を任せるなら、なおさら最初に線を引く必要がある。

古い名前だから動かす。

archiveに入っているから現役ではない。

backupと書いてあるから全部バックアップ置き場へ移す。

そういう判断を許すと、動いている仕組みまで壊す。

だから今日は、ファイルを一気に片づけるのをやめた。

代わりに、役割と参照を見て、動かしてよいものだけを1件ずつ分けることにした。

そのために、まず編集部のファイルを5つに分けた。

今も使うもの。

作業の記録。

役割を終えた成果物。

旧方式として残す資料。

問題があったときに戻すためのコピー。

名前ではなく、この5つの役割から見ることにした。

ファイル名だけを見ると、全部片づけたくなった

編集部の中には、いろいろな時期のファイルが混ざっている。

記事制作のカルテ。

公開後施工のログ。

移行が終わった記録。

旧Claude時代の調査メモ。

DBのバックアップ。

WordPress変更前のHTML。

ファイル名だけを見ると、古そうなものをまとめてarchiveフォルダへ移したくなる。

フォルダ名も同じだった。

archive、backup、old、published。

こういう名前が並ぶと、もう終わったものに見える。

でも、編集部では保存場所そのものが運用の一部になっていた。

AGENTSという全体ルールが参照している。

今の記事制作手順が読んでいる。

記事ごとに企画から公開までの判断を残しているカルテに、過去の判断として残っている。

元に戻すための記録が、移動前の場所を前提にしている。

見た目だけで動かすと、整理ではなく事故になる。

俺の場合、きれいに揃えようとするほど、動かさなくていいものまで動かしそうになった。

でも「古そう」は、動かしてよい理由ではなかった

最初に捨てた判断基準は、「古そう」である。

古い日付。

Claude時代の名前。

archiveというディレクトリ。

backupというファイル名。

それだけでは、動かしてよい理由にならなかった。

たとえば、記事ごとに企画から公開までの判断を残しているカルテは、公開済みになると古い記録に見える。

でも、関連記事を見るときや、過去に何を採用し、何を不採用にしたかを確認するとき、今も使う。

これは「役割を終えた成果物」ではなく、今も確認に使う資料である。

公開後に何を変更したかを作業ごとに残している記録フォルダも同じだった。

中には、変更の計画、実施結果、変更前後の状態、差分、データベースの控え、元に戻す手順までがまとまっている。

意味としては作業記録であり、一部には復旧用のコピーも含まれる。

だからといって、中のデータベースの控えだけを別の場所へ抜くと、その作業の経緯が追いにくくなる。

古そうかどうかではなく、今の運用で何の役割を持っているか。

そこから見ないといけなかった。

名前はヒントであって、判定ではない。

まず5種類に意味だけを分けた

そこで、最初にやったのは移動ではなかった。

意味を分けることだった。

ここで、さっき日本語で分けた5つに名前をつけた。

• active：今も制作や確認に使うもの
• logs：何を変更・確認したかの記録
• completed：今の仕組みの中で役割を終えた成果物
• archive：旧方式や、今は使わないが残しておきたい資料
• backups：問題があったとき元に戻すためのコピー

この分類で大事だったのは、名前ではなく役割で見ることだった。

公開済みだから、役割を終えた成果物とは限らない。

archiveという名前の場所に入っているから、今は使わない資料とも限らない。

backupと書いてあるから、全部同じ場所へ集約するわけでもない。

分類名は、ファイルを動かす命令ではない。

まず、そのファイルが今何者なのかを言えるようにするための言葉だった。

これだけで、整理の見え方が変わった。

「古いものをどう片づけるか」ではなく、「今も使うものをどう守るか」になった。

整理の主語が、ファイル名から役割へ移った。

物理パスは、すぐには変えなかった

分類を決めても、すぐにフォルダを動かしたわけではない。

ここが今日の一番大きな判断だった。

作業記録に分類したものでも、すぐには動かさなかった。

公開後の変更記録フォルダには、変更の計画、実施結果、変更前後の状態、差分、元に戻す手順までが、作業ごとにひとまとまりで残っている。

中のファイルだけを別の場所へ移すと、その作業の経緯が追いにくくなる。

だから、意味としては「作業記録」と決めても、保存場所はそのままにした。

役割を終えた成果物に分類したものでも、`archive/drafts/published/`は今の場所に置いた。

公開後施工が終わったdraftの現行保存場所として、今も使われているからだ。

データベースのバックアップも、戻すためのコピーに分類しながら、今の保存場所に置いたままにした。

参照が残っているうちは、きれいな場所へ集めることより、戻せることを優先した。

過去のレビューや記事記憶を置いているknowledgeの中身も、今のルールが参照しているなら動かさない。

古い由来でも、今の運用で読まれているなら、今も使うものとして扱う。

意味と物理パスは、必ずしも一致しない。

これを認めたことで、大きなリファクタをしなくてよくなった。

きれいに並べるより、壊さずに分かること。

そのほうが、今の編集部には合っていた。

安全なものだけ、1件ずつ動かした

意味を分けたあとも、一括移動はしなかった。

試したのは、参照が0件で、役割終了がはっきりしていて、戻し方が単純なものだけである。

最初に動かしたのは、旧ChatGPT貼り付け前提のSEOレビュー手順だった。

現行のSEOレビューは、同じCodexセッション内で第三者視点に切り替えて行う。

だから、その旧手順は今の記事制作手順では使わない。

これは、旧方式として残す資料の中でも、引退した手順だった。

次に見たのは、Claude時代の調査資料だった。

これは実行手順ではない。

でも、当時の設計思想を理解するための歴史資料として残す価値がある。

だから、旧方式として残す資料の中でも、歴史資料として分けた。

さらに、Codex移行完了記録も見た。

これは旧方式そのものではなく、正常に終わった移行の成果物だった。

だから旧方式の資料ではなく、役割を終えた成果物として分けた。

同じ「古そうなファイル」でも、行き先は違った。

旧手順。

歴史資料。

完了済み成果物。

一つずつ中身と参照を見たから、この違いが見えた。

AIに任せたのは、片づけではない。

判断の証拠をそろえることだった。

動かさない対象を決めたら、整理が静かになった

動かしたものより、動かさないと決めたもののほうが大事だった。

記事カルテは公開済みでも動かさない。

公開後の変更記録フォルダは、作業記録に分類しても分解しない。

データベースのバックアップは、戻すためのコピーに分類しても、参照が残る間は現在位置を維持する。

過去のレビューや記事記憶は、Claude時代由来でも、今の参照があれば現役の資料として扱う。

名前にarchiveが入っている手順ファイルも、今の記事制作手順から参照されているなら動かさない。

この判断があると、整理中に毎回迷わなくなる。

これは動かしてよいのか。

名前は古いけれど、今も使っていないか。

きれいな場所へ移したほうがよいのか。

その問いに、いったん答えを置ける。

前に「終わったファイルは消さずにarchiveへ移す」として整理したとき、俺は現役のdraftと公開済みのdraftを分けたかった。

今回は、その考え方を編集部全体へ広げた。

ただし、広げた結果、全部を動かすのではなかった。

動かさない対象を決める。

それも整理だった。

大きなリファクタをしない判断も、運用の一部だった

最後に残ったのは、大きなリファクタをしない判断だった。

整理という言葉を使うと、どうしても構造をきれいにしたくなる。

active、logs、completed、archive、backups。

この5分類に合わせて、フォルダも全部そろえたくなる。

でも、今の編集部では、物理パスがそのまま記録や参照になっている。

だから、分類だけを正し、物理移動は別案件にした。

実例と施工手順は、`docs/asset_classification_guide.md`に残した。

原則はAGENTSに置いた。

AGENTSからguideへ辿れるようにもした。

前に「仕組みを増やしたのに、最後は前より静かになった」として整理した静かさは、ここにもあった。

これで、次にファイル整理をするとき、AIは同じ判断を最初からやり直さなくてよい。

「一度に全部直さない。1か所ずつGOを出す」で扱った考え方も、そのまま効いた。

GOは、全部を任せる合図ではない。

次の確認地点まで進めてよい、という許可である。

今日の整理も同じだった。

調査する。

設計する。

GOを出す。

1件だけ動かす。

再grepする。

ファイルの中身が変わっていないかをハッシュで確認し、サイズや更新日時も見る。

非対象が変わっていないことを確認する。

この手順を繰り返した結果、編集部は全部きれいなフォルダへ移ったわけではない。

むしろ、多くのものは動かさないまま残った。

でも、それでよかった。

今は動かさない。

そう判断できる状態になったからである。

整理とは、全部をきれいな場所へ動かすことではなかった。

今も使うものを守り、役割が終わったものだけを分けることだった。

だから、大きなリファクタをしない判断も、運用の一部である。