ブログの記事のネタが無くて困ることはよくあるでしょうが、今回のこのテーマは、全く逆で、ネタが多過ぎて、どこから話していいか見当もつかない様な面白いテーマです。まあ超マニアックですが。。いいえ核心かも。では話を始めます。
〜Mac miniによるDAS操作、Mac miniは今こそ本領発揮の時代に入った〜
SynologyNASとMac miniを組み合わせたファイル管理システムを使い始めた頃から、「NAS自体がPCの機能を持っているので、Mac miniと機能が重複している。Mac miniの頭脳(OS)を使って、複数のHDDを、NASのRAIDのようにガチガチではなく、もっと自由に扱うことができないか」と問題意識を持っていました。その解決策を提案している１つのYouTube動画が気になっていました。👉「NASじゃなくてもいいかも！Mac miniでデータ管理してみた(ギズモード網藤さん)」(※この動画ではTailscaleによる外部アクセスに視点を向けていますが、私は、その外部アクセスができたあとのデバイスの有効活用に興味を移しています。)
棚田式を思いついたのは、ギズモードの網藤さんが「一年に１回、写真や動画を移動させるルールを実行している」と語っていたことがヒントになり、「棚田は許容量を超えたら水が溢れ出る→だが、ここで→古い水から下段へ移動できたら面白い」とイメージしたことです。
まずは動画をご覧ください。
ポイント解説
（１）脱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）のみを愚直に実行し、計画にないファイルには一切触れないため、手作業のファイル整理で起こりがちな「誤って消去した」「どこへ行ったか分からない」という事故を原理的に防ぎます。 |
（２）脱RAIDのデメリット
| 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需要がそれを爆増させているわけなので、あとあと、とてつもない廃棄物が出る。バブルの崩壊が起きそうですね。。ああ怖い。有効活用のことを本気で考えるべき時がやってきそうな気がします。
棚段の基本構成は、作業段(T0)、保管段(T1)、長期保管段(T2)の３構成ですが、流出流入の関係を規定すれば、もっと増やすこともできますし、逆に、２構成にするのもいいと思います。実際、私は、高齢者ですので、これからは減らす方向でいきたいと思っています。
（４）実装
青ボタンを押してtxtファイルをダウンロードして、AI(Gemini/ChatGPTなど)に理解させ、ご自身の環境に合わせた実装手順をお進みください。
（５）まとめ
残りの、廃棄処理、FreeFileSyncによるミラー同期処理、シャドウ・ディレクトリの作成、に関するコードは、完成し次第掲載していきます。ただし、他の処理への影響はありませんので、上の内容をそのまま使っても動きます。
