棚田式非破壊型(シミュレーション型)ファイル管理はNASを超えるぞ！

ブログの記事のネタが無くて困ることはよくあるでしょうが、今回のこのテーマは、全く逆で、ネタが多過ぎて、どこから話していいか見当もつかない様な面白いテーマです。まあ超マニアックですが。。いいえ核心かも。では話を始めます。

〜Mac miniによるDAS操作、Mac miniは今こそ本領発揮の時代に入った〜

SynologyNASとMac miniを組み合わせたファイル管理システムを使い始めた頃から、「NAS自体がPCの機能を持っているので、Mac miniと機能が重複している。Mac miniの頭脳(OS)を使って、複数のHDDを、RAIDのようにガチガチではなく、もっと自由に扱うことができないか」と問題意識を持っていました。その解決策を提案しているYouTube動画が気になっていました。👉「NASじゃなくてもいいかも！Mac miniでデータ管理してみた(ギズモード網藤さん)」「【NAS＆RAIDより安全】２０２５年版　個人限定　データを守る方法を紹介　HDDケース」

棚田式を思いついたのは、ギズモードの網藤さんが「一年に１回、写真や動画を移動させるルールを実行している」と語っていたことがヒントになり、「棚田は許容量を超えたら水が溢れ出る→だが、ここで→古い水から下段へ移動できたら面白い」とイメージしたことです。
まずは動画をご覧ください。

👉(スマホ宅外向き) 低画質・枠外字幕はこちら

字幕一覧(クリック)

(00:00:18) それでは始めます。
(00:00:20) この画像ですけれども、
(00:00:22) これはあの、日本の山村によく見かける棚田の風景です。
(00:00:28) ええ、コンピューターのデータの管理をですね、
(00:00:32) この棚田を流れる水のように行いたいと。
(00:00:36) そう思って、
(00:00:38) 今回この「棚田式ファイル管理システム」を作ってみました。
(00:00:44) まだ最後まで完成していませんが、
(00:00:47) 重要な仕組みは大体出来上がりましたので、
(00:00:51) 紹介したいと思います。
(00:00:54) この動画は、
(00:00:56) Google Vids
(00:00:58) Google V-I-D-S という新しい機能をですね、
(00:01:03) 使って作ってみました。
(00:01:05) それではご覧ください。
(00:01:21) 本日は、私が個人で開発・運用している「DAS棚田式ファイル管理システム」についてお話しします。
(00:01:29) これは市販のNASやRAIDに依存せず、
(00:01:31) Mac miniの計算能力とGoogle Sheetsを活用して、
(00:01:36) 大量のファイルを安全かつ低コストに管理するための仕組みです。
(00:01:40) デジタルデータの断捨離とハードウェアの有効活用をどう両立させたか、その全貌をご紹介します。
(00:01:49) まず、開発のきっかけとなった動機についてお話しします。
(00:01:54) 私は長年、SynologyのNASとMac miniを併用してファイル管理を行ってきました。
(00:02:00) しかし、ある時、ふと疑問を抱きました。
(00:02:03) 「NASも結局は小型のコンピュータであり、Mac miniと機能が重複しているのではないか？」と。
(00:02:08) 手元には強力なプロセッサを持つMac miniがあるのに、データの管理はNASの非力なCPU任せになっている。
(00:02:14) しかも、RAIDを組んでしまうとHDDの組み合わせに制約が生まれ、自由が利きません。
(00:02:22) Mac miniの頭脳(OS)を使って、複数のHDDをもっと自由に、
(00:02:26) まるでレゴブロックのように扱えないか？
(00:02:30) これが最初の着想でした。
(00:02:33) もう一つの、そしてより切実な動機が、私自身の年齢と環境の変化です。
(00:02:39) 高齢になるにつれ、身の回りのものを整理し、「断捨離」を進めたいという思いが強くなりました。
(00:02:44) デジタルデータも同様です。
(00:02:46) ただ溜め込むのではなく、必要なものを選別し、不要なものは手放すサイクルを作りたい。
(00:02:51) また、昨今のHDD価格の高騰も無視できません。
(00:02:57) RAIDのために高価な同容量のHDDを買い揃えるのではなく、
(00:03:02) 手元にある古い500GBや1TBのHDDも捨てずに、
(00:03:07) 資産として有効活用したい。
(00:03:10) この「整理したい欲求」と「もったいない精神」を技術で解決するために構築したのが、このシステムです。
(00:03:19) そこで考案したのが、「棚田」というデータ管理モデルです。
(00:03:23) 水が上流から下流へ流れるように、データも鮮度に応じて、
(00:03:28) 段々畑を下りていくイメージです。
(00:03:30) システムでは、大きく3つの段位を定義しています。
(00:03:34) 一番上が「T0：作業段」。
(00:03:37) これはDropboxなど、人間やアプリが日々読み書きする、最も動きの激しい領域です。
(00:03:43) その下が「T1：保管段」。
(00:03:46) ここからはシステムが管理する領域で、準アクティブなデータを置きます。
(00:03:51) 一番下が「T2：長期保管段」。
(00:03:54) ここはアーカイブ領域です。
(00:03:56) 重要なのは、それぞれの段位に、サイズもメーカーも異なるバラバラのHDDを割り当てられる点です。
(00:04:02) これをソフトウェアで一つの巨大な階層構造として管理します。
(00:04:09) このシステムの核心にある設計思想、それが「判断と実行の分離」です。
(00:04:14) 通常のファイル操作では、人間が「移動」と思った瞬間にファイルが動きます。
(00:04:20) しかし、それでは「あ、間違えた！」という事故を防げません。
(00:04:25) このシステムでは、「考える工程（シミュレーション）」と「動かす工程（アプライ）」を完全に分離しました。
(00:04:32) まず、システムは全ファイルをスキャンし、「もしルール通りに動かしたらどうなるか？」を計算し、
(00:04:38) データベースに記録します。
(00:04:40) これを我々は「メタデータ更新」と呼びます。
(00:04:44) 実体ファイルには指一本触れず、
(00:04:47) メタデータ上で完璧な計画を立てる。
(00:04:50) これが第一段階です。
(00:04:53) このアプローチでは、実体ファイルは「従属物」とみなします。
(00:04:57) そこにファイルがあるから残すのではなく、
(00:05:01) 「メタデータという設計図にあるべきと書かれているから、そこに置く」のです。
(00:05:05) システムは、設定されたパス配下の全ファイルを「棚卸し」します。
(00:05:10) これにより、管理者の知らない「野良ファイル」が存在することを許しません。
(00:05:16) 全てのファイルにIDと行き先が振られ、データベース上で管理される。
(00:05:20) これが「メタデータ至上主義」です。
(00:05:25) システムの全体像をご覧ください。
(00:05:28) ユーザーインターフェースには、なんとGoogle Sheetsを使います。
(00:05:32) 専用のアプリは作りません。
(00:05:35) スプレッドシート上の「tanada.csv」という設定シートに行き先を書き、セル上のボタンを押す。
(00:05:41) すると、Mac mini内で待機しているPythonのデーモン（常駐プログラム）がそれを検知し、
(00:05:47) 裏側でスクリプト群が走り出します。
(00:05:51) 非常にシンプルな構成ですが、Googleの認証基盤を使うため、セキュリティも堅牢です。
(00:05:59) さて、ここからは少し技術的な「柔軟性」の話をします。
(00:06:04) 基本設計では、データはT0からT2へ、重力に従って落ちていく一方でした。
(00:06:10) しかし運用していると、「T2のHDDを別のPCで使いたいから、空にしたい」という場面が出てきます。
(00:06:17) そこで、プログラム上の「重力ルール」を緩和し、T2からT1への「逆流」を許可するようにしました。
(00:06:24) これにより、データは一方通行ではなく、必要に応じてHDD間を行き来できる「リバランス」が可能になりました。
(00:06:31) RAIDのリビルドのような危険な作業なしに、データの引っ越しができるのです。
(00:06:37) この逆流を活用した強力な機能が、「限度0TB設定」です。
(00:06:43) 例えば、T2にある古いHDDを引退させたいとします。
(00:06:47) やることは一つ。
(00:06:49) Google Sheetsでその段位の容量限度を「0TB」に書き換えるだけです。
(00:06:53) シミュレーションを実行すると、システムは
(00:06:56) 「おっと、T2の容量がゼロになった。ここにあるファイルは溢れてしまう」と判断します。
(00:07:02) そして自動的に、空き容量のある上位のT1へ、全てのファイルを移動させる計画を立案してくれます。
(00:07:09) 除外ファイルがあってもエラーにならないよう調整済みですので、ボタン一つで安全にHDDを空っぽにできます。
(00:07:19) しかし、自動化には恐怖も伴います。
(00:07:22) もしシステムが暴走して、作業中のDropbox(T0)を古いデータで上書きしてしまったら？
(00:07:28) これだけは絶対に避けなければなりません。
(00:07:31) そのため、プログラムの最深部に「T0戻り禁止」という安全装置をハードコードしています。
(00:07:36) いかなる設定、いかなるバグがあろうとも、「現在の場所がT0以外で、移動先がT0となる操作」は、
(00:07:43) シミュレーション段階と実行直前の2段階でブロックされ、強制停止します。
(00:07:48) T0は聖域（サンクチュアリ）であり、システムはそこへ書き込む権限を持ちません。
(00:07:52) この制約があるからこそ、安心して自動化を任せられるのです。
(00:08:02) 実際の運用では、いきなりファイルを動かすことはしません。
(00:08:06) まず、「ドライラン（予行演習）」が行われます。
(00:08:10) 処理結果はメールで通知され、何個のファイルが動き、どの程度のリスクがあるかが5段階評価で届きます。
(00:08:16) 「問題なし」という評価を確認してから、初めて人間が「APPLY（適用）」ボタンを押す。
(00:08:22) 寝ている間に、Mac miniが数テラバイトのデータを整理整頓してくれる。
(00:08:28) そんな運用が実現しています。
(00:08:33) 次に、これからの機能である「廃棄（断捨離）の自動化」についてです。
(00:08:38) データは溜まる一方ですが、手動で消すのは勇気が要ります。
(00:08:44) そこで、「廃棄処理の規定」というルールを設けます。
(00:08:47) 例えば、「拡張子が.tmpで、かつ2年以上更新がないファイル」といった条件を定義します。
(00:08:53) これに合致したファイルは、即座に削除されるのではなく、
(00:08:57) 「pending_delete」という専用のゴミ箱領域へ移動されます。
(00:09:02) そこで半年間眠らせて、誰も困らなければ完全に消去する。
(00:09:07) システムが背中を押してくれることで、デジタル断捨離がスムーズに進みます。
(00:09:13) 日々の運用は非常にシンプルです。
(00:09:16) 新しいHDDを買ってきたら、Mac miniに繋ぎ、Google Sheetsの設定行を1行追加するだけ。
(00:09:22) あとはボタンを押せば、システムが自動的にそのHDDをT1やT2として認識し、
(00:09:28) データの保存先として組み込みます。
(00:09:31) 逆にHDDを外す時も、設定を消すだけで、データは他のHDDへ自動的に退避されます。
(00:09:38) RAIDの再構築のような、胃が痛くなる待ち時間はもうありません。
(00:09:44) このシステムを導入して、私は「RAID」という呪縛から解放されました。
(00:09:50) メーカーも容量も違うHDDを自由に組み合わせ、古くなったら交換し、余ったら再利用する。
(00:09:56) DAS（ダイレクト・アタッチド・ストレージ）として各ディスクが独立しているため、万が一システムが壊れても、
(00:10:04) HDDを抜いて別のPCに繋げば、そのまま中のデータを読み出せます。
(00:10:09) 「資産の流動性」と「データの安全性」、この二つを、
(00:10:14) Mac miniという既存のリソースだけで手に入れることができました。
(00:10:20) 最後になります。
(00:10:22) 「DAS棚田式ファイル管理システム」は単なるバックアップツールではありません。
(00:10:25) 「判断と実行を分離する」という哲学に基づき、
(00:10:30) 私たちシニア世代が直面する「デジタル遺産の整理」と「資産の有効活用」を解決するためのソリューションです。
(00:10:37) NASのブラックボックス化に不安を感じている方、
(00:10:40) 手元のHDDをもっと自由に使いこなしたい方。
(00:10:44) 是非、ご自身のMac miniに「棚田」を作ってみてはいかがでしょうか。
(00:10:49) ご静聴、ありがとうございました。

ポイント解説

（１）脱RAID(DAS)のメリット・デメリット

メリット

1. 異種混合ドライブの柔軟な活用（ハードウェア制約の撤廃）

サイズ違いの混在が可能:
手元にある4TBのHDD、8TBのHDD、1TBのSSDといった、容量や規格がバラバラのドライブを自由に組み合わせることができます。これらを「T1（保管段）」「T2（長期保管段）」といった論理的な階層（棚田）に割り当てることで、一つの大きなストレージプールとして扱えます。

コスト効率の最大化:
高騰する大容量HDDを新たにペアで購入する必要がなく、余っているドライブや安価に入手できた単体のドライブを即座に戦力として投入できるため、経済的です。

「処理ID」による独立したエコシステムの形成:
tanada.csvにおける「処理ID（例：T0001）」は、それぞれが独立したエコシステムを定義します。このシステムは常設する必要はありません。展示会の仮設システム用にHDDをかき集めたい、などという時にも使えます。

2. 「資産の流動性」と安全な転用（HDDのレゴブロック化）

設定ひとつでHDDを空にする:
例えば、T2（長期保管段）で使用している8TBのHDDを別のPCへ転用したい場合、Google Sheetsの設定（tanada.csv）でT2の容量制限を「0.0TB」に変更するだけです。

自動かつ安全な退避:
容量を0に設定してシミュレーションを実行すると、システムは「T2にはファイルを置けない」と判断し、T2内の全データを自動的に上位のT1（または他の空き領域）へ移動（逆流）させる「完璧な計画書」を作成します。

物理作業の簡素化:
承認ボタンを押して自動移動（Apply）が完了すれば、HDDは空っぽになるため、安心して取り外して転用できます。

単体での可読性(プラグアンドプレイが出来る):
NASやRAIDのアレイ（RAID 5など）に組み込まれたHDDは、1本だけ引き抜いて他のPCにUSB接続してもデータを読み出せません。しかし、このシステムのDAS構成では各HDDが独立した標準フォーマット（APFSやexFAT等）でフォーマットされているため、USBケーブルを抜いて別のPCに挿す（プラグアンドプレイ）だけで、即座に普通のHDDとしてデータを読み書きできます。

3. 復旧プロセスの単純化（ボリュームリネームによる復旧）

シンプルなミラーリング:
各段位（T0, T1…）に対して「main」と「mirror」というボリュームを用意し、FreeFileSyncなどの一般的なアプリで毎日コピーを作成できます。

ボリューム名の変更で復旧:
もし「T0_main」のディスクが故障した場合、バックアップである「T0_mirror」のボリューム名を「T0_main」に変更するだけで、システムは何事もなかったかのように稼働を再開できます。これはRAIDのリビルド待ち時間や専門知識を必要としない、極めて直感的な復旧方法です。

4. 検索・閲覧の単純化:

巨大なフォルダ（例：「写真」）が、容量の都合で物理的にはT1とT2の2つのディスクに分断されて保存されていたとしても、ファイルパス（ディレクトリ構造）が完全に維持されているため、それらを重ね合わせて「一つの巨大な写真フォルダ」として閲覧することが容易です。

5. 事故を防ぐ「判断」と「実行」の分離:

非破壊シミュレーション:
実際のファイルを動かす前に、メタデータ上で移動計画を立てます。もし容量不足や設定ミスがあっても、実データは一切変更されていないため、何度でも設定をやり直すことができます。

意図せぬ消失の防止:
システムは承認された計画（Apply Plan DB）にある移動（MOVE）のみを愚直に実行し、計画にないファイルには一切触れないため、手作業のファイル整理で起こりがちな「誤って消去した」「どこへ行ったか分からない」という事故を原理的に防ぎます。

デメリット

1. 「可用性」の低下（ダウンタイムの発生）

復旧には手動介入が必要:
本システムでは、各段位（T0, T1…）に対して「main」と「mirror」という独立したボリュームを作成し、同期アプリでコピーを取る運用が想定されています。もし「main」が故障した場合、RAIDのように自動で切り替わるのではなく、ユーザーが「mirror」のボリューム名を「main」に書き換える（リネームする）という復旧作業を行うまで、システムは停止します。

リアルタイム同期ではない:
常時同期するRAIDと異なり、FreeFileSyncなどで「毎日1回コピー」する運用の場合、故障したタイミングによっては、前回バックアップ以降のデータ（最大1日分）が失われる可能性があります。これを防ぐために**「作業は原則T0（Dropbox等）で行う」**というシステムの運用ルールを設定して、ハードウェア障害時のリスクを最小限に抑える「防波堤」としています。

2. システム構築・維持の複雑さ（属人化のリスク）

環境依存:
Pythonスクリプト、Google Cloud Platformの認証設定（JSONキー）、Macのフォルダ構造（/Users/xxxxxxm1/...）、LaunchAgentによるデーモン管理など、多くの依存関係の上に成り立っています。

トラブルシューティングの難易度:
もし「ボタンを押しても動かない」という事態になった場合、原因がGoogle APIの仕様変更なのか、ローカルのPython環境なのか、デーモンの停止なのかを切り分けるスキルが求められます。そんな理由もあって、ブログで中身を公開するとともに、AI(Gemeni/ChatGPTなど)の支援が受けやすいように考えています。

（２）自宅のどんな場所で使っているのか。

棚田システムは非常に柔軟で、M1Mac miniで十分だし、その外付けドライブであれば（というかM1Macが認識できるドライブであれば)どれでも選定できます。現状、下の図の赤丸T0T1T2に棚田システムを設定しています。調べてみて自分で驚いたのですが、外付けドライブを11個も使っていました。まだあと外してあるものも数個あります。別に壊れているわけではないのに。資源やお金を無駄にしてきたと思います。
世界全体が巨大なRAIDで動いているために、実際どれくらい冗長に重複所有になっているか。AI需要がそれを爆増させているわけなので、あとあと、とてつもない廃棄物が出る。バブルの崩壊が起きそうですね。。ああ怖い。有効活用のことを本気で考えるべき時がやってきそうな気がします。