今回の環境では、M1 Max MacBook ProとM4 Pro Mac miniの2台をローカルAIワーカーとして使用します。

ただし、2台を常に同時稼働させるわけではありません。

その時間に普段の仕事で使用していない方のMacへ、記事生成や画像生成を担当させます。

運用方針

確定している運用は次のとおりです。

自宅で仕事をしている時間

  • 普段の仕事はMac miniで行う
  • MacBook ProをローカルAIワーカーとして使う

夜間や外出中

  • MacBook Proは停止するか持ち出す
  • Mac miniをローカルAIワーカーとして使う

Mac miniは普段の仕事中に多くのアプリを起動しているため、AIワーカーとして使う時間帯には、必要に応じて重いアプリを終了します。

64GBでもアプリを閉じる必要があるか

Mac miniは64GBのメモリを搭載していますが、普段の仕事中には45GB程度を使用しています。

この状態でも、必ずすべてのアプリを終了する必要はありません。

macOSでは、空いているメモリをキャッシュとして使用するため、単純な使用量だけでは不足しているか判断できません。

確認すべきなのは次の項目です。

  • メモリプレッシャー
  • スワップ使用量
  • モデル読み込み後の状態
  • 生成速度
  • アプリの応答
  • 異常終了の有無

生成中もメモリプレッシャーが緑で、スワップが大きく増えなければ、そのまま利用できる可能性があります。

黄色や赤になる場合は、次のような重いアプリを終了します。

  • 大量のタブを開いたブラウザ
  • Docker Desktop
  • 不要なDockerコンテナ
  • IDE
  • 複数のAIコーディングセッション
  • 仮想マシン
  • 画像編集アプリ
  • 使用していないローカルサーバー

両方のMacに同じ環境を用意する

どちらのMacでも同じジョブを処理できるように、基本的な環境を揃えます。

両方へ用意するものは次のとおりです。

  • Pythonワーカー
  • OllamaまたはMLX
  • ComfyUI
  • 使用するLLM
  • 使用する画像生成モデル
  • ComfyUIのワークフロー
  • 必要なLoRAや追加ファイル
  • 共通の設定ファイル
  • launchdの設定

ワーカーのプログラムはGitで管理します。

一方、容量の大きいモデルファイルはGitへ含めず、それぞれのMacへ個別にダウンロードします。

モデルのバージョンやファイル名は設定ファイルで管理し、2台の差異が分かるようにします。

最初は手動で切り替える

初期段階では、複雑な自動判定を実装しません。

自宅で仕事を始めるときは次の状態にします。

```text
MacBook Pro：ワーカー有効
Mac mini：ワーカー無効
```

外出前や就寝前は次の状態へ切り替えます。

```text
MacBook Pro：ワーカー無効
Mac mini：ワーカー有効
```

手動切り替えの方法としては、次の候補があります。

  • メニューバーアプリ
  • macOSのショートカット
  • シェルスクリプト
  • launchctlを使った開始と停止
  • ローカルの管理画面

初期実装では、シェルスクリプトやショートカットで十分です。

運用が固まってから、専用のメニューバーアプリを作る方法もあります。

同時に起動しても問題が起きない構成

切り替え忘れによって、両方のワーカーが同時に動く可能性があります。

そのため、同時稼働しても同じジョブを二重取得しないよう、VPS側でロックします。

どちらか一方だけを必ず動かすことに依存しない設計にします。

これにより、次のような使い方も可能になります。

  • Mac miniが記事生成
  • MacBook Proが画像生成
  • 2台で別々のジョブを並列処理
  • 一方が停止したらもう一方が引き継ぐ

初期運用は手動切り替えですが、基盤としては複数ワーカーへ対応させます。

スリープ対策

Macがスリープすると、ロングポーリングや生成処理も停止します。

AIワーカーとして使用している間は、システム全体が自動スリープしないようにします。

ただし、ディスプレイを常時点灯させる必要はありません。

次の状態が理想です。

  • ディスプレイは消灯可能
  • システムは稼働を継続
  • ネットワーク接続を維持
  • ワーカーを自動再起動
  • 再起動後も自動ログインに依存しすぎない

macOSのlaunchdを利用し、ワーカーが停止した場合やMacが再起動した場合に自動起動できるようにします。

MacBook Proのバッテリー対策

MacBook ProをローカルAIワーカーとして使う場合、バッテリーと発熱への配慮が必要です。

記事生成や画像生成は、CPU、GPU、メモリを継続的に使用します。

対策として次の運用を行います。

  • 充電上限を低めに設定する
  • 通気性のよいスタンドを使う
  • 高温の場所で長時間処理しない
  • 吸排気を塞がない
  • 不要なモデルを常駐させない
  • 夜間の長時間処理はMac miniへ任せる
  • バッテリー状態を定期的に確認する

MacBook Proは自宅で仕事をしている時間のワーカーとして使用し、常時稼働や夜間処理はバッテリーのないMac miniへ担当させます。

将来の自動切り替え

手動切り替えが安定した後は、自動化を検討できます。

例えば、ワーカーはVPSへ次の情報を送ります。

  • 稼働状態
  • 現在のメモリプレッシャー
  • 空きメモリ
  • CPU使用率
  • GPU負荷
  • 電源接続状態
  • バッテリー残量
  • 現在処理中のジョブ数
  • 対応できるモデル

VPSはこの情報をもとに、適切なワーカーへジョブを渡します。

例えば次のルールが考えられます。

  • MacBook Proがオンラインなら文章生成を優先
  • 夜間はMac miniを優先
  • Mac miniのメモリプレッシャーが高ければジョブを渡さない
  • 画像生成は速い方のMacへ渡す
  • バッテリー駆動中のMacBook Proには重いジョブを渡さない

ただし、自動切り替えは初期段階では追加しません。

まずは実際の使い方と性能を確認し、必要な条件だけを追加します。

まとめ

M1 Max MacBook ProとM4 Pro Mac miniを使い分ければ、普段の仕事を邪魔せずローカル生成AIを運用できます。

自宅で仕事中はMacBook Pro、夜間や外出中はMac miniをワーカーとして使います。

最初は手動で切り替えますが、VPS側では複数ワーカーに対応し、切り替え忘れや同時稼働があっても二重処理しない設計にします。

次回は、ローカルで生成した記事と画像をVPSへ返し、Payload CMSへ下書きとして登録するところまでを構築します。