9,800円の古いMac miniに、もう一度仕事を。 ― 30,407枚の生成AIイラストを預かる、自分専用ライブラリ〈第1回／全5回〉

はじめに

机の隅に置かれた、小さな銀色の箱 - Mac mini。
新しい Macと比べれば、性能は控えめです。最新の用途を快適にこなすには、少し心もとないところもあります。

今回、中古品の Mac mini を、9,800円で購入しました。

古いというだけで、その機械にできることがなくなったわけではありません。画面をつながず、必要な仕事を静かに続けるサーバーとして考えれば、まだ十分に役目があります。

小さく、動作音も目立たず、置き場所にも困りません。自宅で使うサーバーとして、この Mac mini には似合う仕事があるように思いました。

今回から全5回で、この9,800円の Mac mini を、創作活動で作り込んだ画像を保存し、記録し、必要なときに探し出せる「生成AIイラスト用ファイルライブラリ」へ作り替えた過程をご紹介します。

現在、約85.4GB、30,407件のファイルを登録しました。
完成した仕組みでは、次のことができます。

• メインで使っている MacBookPro から共有フォルダへ画像を送る

• Mac mini が新しいファイルを自動的に検知する

• ファイル名、容量、画像サイズ、更新日時を記録する

• SHA-256 を使って同一内容のファイルを判定する

• ブラウザから画像を一覧表示する

• ファイル名、タグ、メモ、AI生成情報を横断して検索する

• 表示順やファイル形式を指定して絞り込む

• 画像ごとにタグとメモを保存する

• AI画像のプロンプト、モデル、Seed、Sampler、LoRAなどを抽出する

• データベースを定期的にバックアップする

• サービスの状態やMac miniの負荷をブラウザから確認する

当初から、ここまでのものを作ろうとしていたわけではありません。
最初に考えていたのは、もっとささやかなことでした。

「創作活動で増えていく画像を、別の場所へ置いておきたい」

ただ、それだけでした。

古いMacを使うという選択

今回使ったのは、大手中古PCサイトで販売されていた 2012年モデル Intel世代の Mac mini です。

サーバーはまともに構成を考えると安価でも数十万円の規模になりますが、とりあえず始めるためには、必ずしも高価な機材が必要なわけではありません。
この Mac mini は華やかな性能を備えたものではありませんが、ファイル共有や軽量なWebアプリ、データベース、監視サービスを動かす用途であれば、十分に働くことができます。

とは言え、大切なデータを預ける以上、古い機械であることを忘れてはいけません。ストレージ（ハードディスクなどのデータ保存先）はいつか故障します。設定を誤れば、サービスが起動しないこともあります。

バックアップがあるだけでは不十分で、実際に読み出せることまで確認する必要があります。

それでも、個人用途の小さなサーバーを構築する入口として、中古の Mac miniはよい教材になりました。

ネットワーク、Linux、アクセス権限、データベース、Webアプリ、常駐サービス、監視、バックアップ。

個別に組めば離れて見える技術が、一台の機械の中で少しずつつながっていきます。性能的には現れにくい価値ですが、私にとっては、その過程そのものが値段以上のものでした。

最終的な構成

この連載では、最初に完成した姿を示し、その後の記事で一つずつ詳しく見ていきます。

全体の流れは、次のようになっています。

MacBookPro・外付けストレージ
          │
          │ Samba / rsync
          ▼
Mac mini の共有フォルダ
/home/User/share/inbox
          │
          │ Python + watchdog
          ▼
ファイル情報の取得
・ファイル名
・容量
・更新日時
・画像サイズ
・SHA-256
・AI生成情報
          │
          ▼
SQLite データベース
          │
          ├── Flask / Waitress
          │        └── File Library
          │
          ├── 重複判定
          ├── タグ・メモ
          └── 定期バックアップ

私が日常的に行う操作は、画像を共有フォルダへ入れることだけです。

Mac mini 側では、Python で作った監視プログラムが新しいファイルを検知し、コピーが完了したことを確認してから、ファイルの情報を取得、SQLiteデータベースへ保存します。

保存された情報は、ブラウザで開く File Library から参照できます。

内部にはいくつもの処理がありますが、使う側から見れば、「入れる」「待つ」「探す」という簡潔な流れです。仕組みが複雑になっても、日常の操作まで複雑にしないことを大切にしました。

macOS ではなく Debian 13を選んだ理由

この Mac mini の OSは 、LinuxOS である Debian 13を導入しました。

インストール済みの macOS のまま利用する方法もありました。しかし今回は、長時間の常時稼働を前提として、必要な機能だけを組み合わせ、Linux の標準的な仕組みで管理したいと考えました。

Debian を選んだ理由は、目新しさではありません。
長く使われてきたこと、情報が豊富であること、構成を比較的簡潔に保てること、そして systemd（サーバー用のプログラムを自動的に起動し、動作を管理する仕組み） や Docker（必要なソフトウェアと設定をひとまとめにして、環境を汚さず手軽に動かす仕組み） など、今回必要になる仕組みを扱いやすいことです。

自宅サーバーは、一度起動すれば完成というものではありません。

・再起動後にサービスが戻る
・異常が起きたとき、記録が残る
・数週間後に設定を見返した自分が、何をしたのか理解できる

実際の使いやすさを支えるのは、そのような目立たない部分です。
新しさよりも、後から無理なく面倒を見られることを優先しました。

最初に整えた三つの入口

Debian を導入した後、まず用意したのは SSH、RDP、Samba の三つです。

1．SSH （Secure Shell）

SSH は、現在所有している MacBookPro のターミナルから Mac mini を操作するための入口です。

購入した Mac mini には、普段ディスプレイやキーボードを接続していません。設定変更、サービスの再起動、ログの確認などは、基本的に SSH 経由で行います。

手元の MacBookPro から接続すれば、そのターミナルが Mac mini の操作画面になります。

今回の構築では、最も多く使った管理手段です。

2．RDP （Remote Desktop Protocol）

すべての作業をコマンドだけで行う必要はありません。
ときには、GUI（Graphical User Interface：文字の命令だけでなく、画面上のアイコンやボタンを使って直感的に操作する仕組み）で画面を確認したほうが分かりやすい場面もあります。そのため、遠隔デスクトップ接続も用意しました。

日常の管理には SSH を使い、必要なときだけ RDP から GUI を開きます。
この二つの方法を用意しておくことで、状況に応じて無理のない操作ができます。

3．Samba

MacBookPro から普段のフォルダと同じ感覚でファイルを置くため、Sambaによる共有フォルダを作りました。

中心となる場所は、共有領域の中に設けたフォルダ「 inbox」 です。

MacBookPro からこのフォルダへ画像を入れると、Mac mini 側の監視プログラムが新しいファイルを検知します。

この inbox が、ファイルライブラリの玄関になります。
大量の画像を一括して移すときには、Finder だけに頼らず、途中経過を確認しやすい rsync（remote sync：ファイルの差分を確認しながら、コピーや同期を効率よく行うための仕組み） も利用しました。

約85.4GB、30,407件という規模になると、転送は短時間では終わりません。速さだけでなく、処理がどこまで進んだのか、途中で止まっても再開できるのかという点が大切になります。

「見えること」を優先する

サーバーを作っていると、つい機能を増やしたくなります。
しかし、追加した機能がきちんと動いているかどうか分からない状態で、安心して使うことはできません。

そこで、Docker を導入した後、Uptime Kuma と Glances を動かしました。

Uptime Kumaでは、SSH、Samba、RDP、File Libraryなどの応答を確認します。サービスが正常に応答しているか、いつ停止したかをブラウザから把握できます。

Glancesでは、CPU、メモリ、ディスク使用量など、Mac mini 全体の状態を確認できます。

監視画面があることで、サーバーは「どこかで動いている箱」ではなくなりました。

いま何が動いているのか、どの機能が止まっているのか、負荷は高くなっていないか。など、その状態を、自分の目で確かめられるようになります。

監視は、問題を起こさないための仕組みというより、問題が起きたときに落ち着いて状況を知るための仕組みです。

完成したFile Library

この連載で作った File Library は、MacBookPro のブラウザから利用します。

一覧画面には、登録された画像がサムネイルとして並びます。カードには、ファイル名、形式、画像サイズ、容量、重複状態などが表示されます。

30,407件を一度に表示すると扱いにくいため、画面には一定数ずつ表示し、ページを切り替えて閲覧できるようにしました。

表示順も変更できます。

• 新しい順

• 古い順

• ファイル名順

• 容量が大きい順

• 容量が小さい順

検索欄では、次の情報を横断して検索できます。

• ファイル名

• タグ

• メモ

• AI画像のプロンプト

• ネガティブプロンプト

• モデル名

• Seed

• Sampler

• 生成ツール

• LoRA名

たとえば、モデル名で検索すれば、そのモデルを使った画像をまとめて確認できます。Seed を入力すれば、同じ生成条件を持つ画像を探せます。後から付けたタグやメモも、同じ検索欄から見つけられます。

検索対象が増えたことで、画像の長いファイル名を覚えておく必要はなくなりました。

画像の中に残された生成情報

生成AIによるイラストでは、Draw Things が書き込んだ情報が含まれています。

• プロンプト

• ネガティブプロンプト

• モデル

• Seed

• Sampler

• Steps

• Guidance scale

• 生成サイズ

• 生成ツール

• LoRAと適用強度

これらをファイルの詳細画面へ表示し、検索にも利用できるようにしました。

画像だけが残っていても、どのような条件で生成したのか分からなくなることがあります。ファイル名に一部の情報が含まれていても、長くなりすぎれば読み取りにくく、すべての条件を記録することもできません。

画像に埋め込まれた情報を読み取り、データベースに整理しておけば、後から制作過程をたどりやすくなります。

・同じモデルをもう一度使いたいとき。
・以前のプロンプトを手掛かりに、新しい画像を作りたいとき。
・LoRAの組み合わせや強度を確認したいとき。

File Libraryは、単なる保管場所ではなく、制作の記録を読み返す場所にもなりました。

重複を「消す」のではなく「知る」

同じ画像を別の場所からコピーすると、内容が同一のファイルが複数保存されることがあります。

そこで、各ファイルから SHA-256（ファイルの内容から固有の値を計算し、同じ内容かどうかを確認するための仕組み）を計算し、同じ値を持つファイルがすでに登録されているか確認するようにしました。

ここで重視したのは、重複を見つけたからといって、自動的に削除しないことです。

同じ内容であっても、意図して別の名前で保存した可能性があります。機械の判断だけでファイルを消すと、後から取り戻せない場合があります。

そのため、この仕組みでは重複元の情報を記録し、画面上で確認できるようにしました。

削除するかどうかは、私が状況を見て判断します。

自動化する範囲と、人の判断を残す範囲を分けることは、小さな個人用サーバーでも大切だと感じました。

タグとメモを残す

画像の内容を、ファイル名だけで表すことには限界があります。

そこで、詳細画面からタグとメモを保存できるようにしました。
保存したタグは一覧画面にも表示され、クリックすると同じタグを持つ画像を検索できます。

メモの文章も検索対象になります。

画像そのものには手を加えず、整理のための情報をデータベース側に持たせています。元のファイルを保ちながら、自分に必要な意味を後から添えられるようになりました。

30,407件を扱って分かったこと

テスト段階で少数の画像で動いていた仕組みも、いざ本番の30,407件を扱うと別の課題が現れました。

特に大きかったのは、一つのフォルダへ大量の画像を置いたときの表示速度です。Mac mini 側ではファイルを読み取れていても、MacBookPro の Finder から開くと、内容の読み込みに長い時間がかかることがありました。

これは Samba へ接続できないという問題ではありません。フォルダそのものは開けても、その中にある大量の項目や画像情報を Finder が読み込むために時間が必要でした。

また、30,000件を超えるファイルを一度にデータベースへ登録すると、画像サイズの取得、ハッシュ計算、生成情報の解析にも相応の時間がかかります。

小規模な試験では見えなかった負荷が、実際のデータ量によって現れました。そのため、ファイルを複数のサブフォルダへ分ける方法、一覧画面のページ分割、データベースの検索方法、登録処理の進捗確認などを適宜整えました。

動作することと、実際の量を無理なく扱えることは別です。
この違いは、30,407件を一括登録して初めて、はっきりと理解できました。

何事も始めは小さく

今回の構築で意識したのは、一度に完成させようとしないことです。
最初の目標は、次の一つだけでした。

その時点では、データベースもWeb画面もAI生成情報の解析もありませんでした。最初にできたのは、新しいファイルの名前をログへ一行記録するだけの、ごく小さなプログラムです。

その動作を確かめた後で、ファイルサイズを取得し、画像の縦横寸法を調べ、ハッシュ値を計算し、SQLite へ保存するようにしました。

その後に重複判定を加え、Web 画面を作り、タグとメモを保存できるようにし、最後にAI生成情報の解析へ進みました。

機能を一段ずつ追加すると、問題が起きた場所を見つけやすくなります。

実際の作業では、仮想環境が作れない、同じファイルイベントが複数届く、サービスの再起動直後だけ接続できない、ページ移動が正しく動かない、検索結果の件数が合わない、CSS に全角空白が混ざるといった問題がありました。

大量登録では、処理が止まっているように見えながら、少しずつ進んでいたこともあります。そのたびに、ログ、データベース、サービスの状態を一つずつ確認しました。

小さく区切っていたからこそ、問題を曖昧なまま先へ進めずに済みました。

安価な機械だからこそ、丁寧に扱う

9,800円の Mac miniという題材は、少し軽く見えるかもしれません。
しかし、安価な機械を使うことと、雑に作ることは別です。

・サービスを自動起動させること。
・異常が起きたときのログを残すこと。
・データベースの整合性を確認すること。
・バックアップを定期的に作ること。

そして、そのバックアップを実際に開き、復元できることを確かめること。こうした部分は、機械の価格にかかわらず必要です。

今回、データベースのバックアップは systemd（Linux上でプログラムを自動起動し、動作や停止、再起動などを管理する仕組み） のタイマーで定期実行するようにしました。古いバックアップを一定数だけ残し、保存先を無制限に使わない仕組みも加えています。

バックアップ処理が一度失敗したこともありました。

そのときは、空き容量、アクセス権限、保存先、途中ファイルを確認し、再実行して正常に作成できることを確かめました。

最終的なデータベースのバックアップは約183MBになりました。
成功という表示だけを見るのではなく、実際にファイルが作られているか、十分な大きさがあるか、整合性検査を通るかまで確認します。

古い機械だから不安なのではありません。
故障しないことを前提にしてしまうことが、不安につながります。

故障する可能性を受け入れたうえで、失って困るものを守る仕組みを用意します。そのように考えると、古い機械とも落ち着いて付き合えるようになります。

この連載で伝えたいこと

この仕組みは、特別に大きなシステムではありません。
使っている技術も、Python、SQLite、Flask、Samba、systemdなど、広く利用されているものです。

けれど、それらを自分の暮らしの中に置き、実際の30,407件のファイルを預けるところまで進めると、技術は単なる知識ではなくなります。

ファイルを置く場所→ 置かれたことに気づく仕組み → 内容を記録する台帳 → 必要なものを探す画面 → 動いているか確認する方法 → 壊れたときに備える記録・・・

一つひとつは小さな機能です。
それでも、それらが静かにつながることで、古い Mac mini は、日々の制作を支える一台になりました。

9,800円で購入したことは、この機械の価値そのものではありません。
大切なのは、手元にあるものを見直し、無理のない役目を与え、長く使えるよう丁寧に整えることでした。

古い機械に必要だったのは、最新の仕事ではありません。
毎日、同じ仕事を確実に続けるための、ささやかな居場所だったのかもしれません。

次回

次回は、Samba 共有の中に設けた inbox を、Python の watchdogで監視します。画像が届いたことを検知し、コピーが終わるまで待ち、systemd のサービスとして常時動作させるところまで進めます。

ただファイルを置くだけだった共有フォルダが、そこで初めて、自ら反応する場所になります。

古いMac miniに与えた最初の仕事は、派手なものではありません。
誰かがファイルを置いたことに気づき、それを静かに記録することです。
すべては、その小さな一行から始まりました。

最後までご覧いただきましてありがとうございました。