公式手順はApple Silicon向けに4項目で整理されています。 それでも画面が開くだけでは受け入れず、ComfyUI リモートMacの検収は「基礎環境、PyTorch、起動、モデル、追加ノード、固定ワークフロー、再起動とアクセス管理」の順に実行してください。Apple Silicon向けの公式案内でも、PyTorchの導入、手動セットアップ、依存関係の導入、python main.pyによる起動が分けて示されています。 ComfyUI公式のApple Silicon導入案内
症状:ComfyUIの画面は表示されるのに、共有ワークフローや追加ノードが動かない。
最速解決:交付時に固定ワークフローを実行し、再起動後のモデル読込と出力保存まで証拠を残します。
この記事は、ComfyUIをリモートMacで使い始める際に、交付直後の不具合を見つけたい人向けです。共有ワークフローを管理する担当者や、環境を何度も移行するクリエイターにも使えるよう、各工程を「合格条件、残す証拠、失敗時の対応」で整理します。
最終更新:2026年8月10日。ComfyUI本体、公式フロントエンド、PyTorch、macOSの公式資料を再確認しています。バージョンを固定する場合は、実際に交付された環境の出力を優先してください。
1. ログイン前に交付資料をそろえる
最初に確認するのは、Macの製品名やチップ名を推測した構成ではなく、実機で取得した情報です。macOSのバージョン、CPUアーキテクチャ、利用可能なストレージ、ログインアカウント、管理者権限の有無、ComfyUIの配置場所、モデルの保管場所を一覧にしてください。
確認項目は次の4つです。
- Apple SiliconとしてPythonとPyTorchが動く実機情報
- ComfyUI本体、フロントエンド、Pythonのバージョン
- モデル、出力、ログ、追加ノードの保存場所
- SSH、画面共有、ブラウザ接続など、実際に使う接続方法
macOSではリモートログインを有効にするとSSHまたはSFTPで接続できますが、許可するユーザーを限定できます。交付時には「誰が接続できるか」と「どのサービスを公開するか」を別々に確認してください。 Apple公式のリモートログイン設定
注意: 「Apple Silicon対応」と書かれていても、すべての追加ノードが同じ条件で動くとは限りません。ComfyUI公式も、Python、PyTorch、追加ノードの組み合わせには互換性の境界があるため、ノード単位で確認する必要があります。
2. 初回ログインで基礎環境を記録する
ターミナルへログインしたら、まずバージョン出力を保存します。確認の目的は、後でエラーが出たときに「どの環境で動かしたか」を再現できる状態にすることです。
sw_vers
uname -m
python3 --version
python3 -m pip --version
git --version
続いて、プロジェクト専用の仮想環境を確認します。Pythonのvenvは、プロジェクトごとにパッケージを分離するための標準機能です。既存の環境へ上書きインストールすると、別の画像生成環境や追加ノードの依存関係を壊す可能性があるため、共有環境では分離を優先します。 Python公式のvenv説明
python3 -m venv .venv
source .venv/bin/activate
python --version
python -m pip list
PyTorchについては、単にインストール済みかを見るのでは不十分です。MPSバックエンドが利用可能か、テンソル演算が実際に通るかを確認します。MPSはAppleのGPU機能を利用するPyTorchのバックエンドですが、利用可否はmacOS、PyTorch、実行コードの組み合わせに左右されます。 PyTorch公式のMPSバックエンド資料
python - <<'PY'
import torch
print("torch:", torch.__version__)
print("mps_available:", torch.backends.mps.is_available())
print("mps_built:", torch.backends.mps.is_built())
PY
合格条件は、使用する仮想環境からtorchを読み込めること、MPSの状態が記録されていること、ComfyUI起動時に依存関係エラーが出ないことです。出力はテキストファイルに保存し、交付資料へ添付します。
3. ComfyUIの起動ログを基準にする
ComfyUIを起動し、ブラウザで画面が表示されたら、そこで止めないでください。起動コマンド、起動日時、ComfyUI本体のコミット、フロントエンドのバージョン、警告とエラーを記録します。
ComfyUIは本体、デスクトップ版、フロントエンドが連動して更新されます。公式リポジトリは、安定版以外のコミットが追加ノードを壊す可能性にも触れているため、共有環境では「最新版」ではなく、動作確認済みのコミットを記録する運用が安全です。 ComfyUI公式のリリース方針
git rev-parse HEAD
python main.py 2>&1 | tee comfyui-start.log
フロントエンドも別管理される場合があります。公式フロントエンドでは安定版とNightly版が分けられているため、検収時に画面の見た目だけで判断せず、起動ログや設定値を残してください。 ComfyUI公式フロントエンド資料
4. モデルパスと保存権限を検証する
モデル関連では、一覧に表示されることと、実際に読み込めることを分けて確認します。少なくともcheckpoint、VAE、LoRAの3種類について、配置場所、読み込み、出力保存を確認してください。
外部ストレージや共有フォルダーを使う場合は、ComfyUI公式のextra_model_paths.yaml方式に合わせてパスを定義します。公式サンプルにはcheckpoint、VAE、LoRAなどのディレクトリーを追加指定する例があり、既存のモデル保管場所を再利用する構成にも対応しています。 公式の追加モデルパス設定例
| 検収対象 | 合格条件 | 残す証拠 | 失敗時の対応 |
|---|---|---|---|
| checkpoint | 一覧表示後、固定ワークフローで読込可能 | モデル名と起動ログ | パス、権限、ファイル名を確認 |
| VAE | 指定ノードで選択でき、画像生成が完走 | ワークフロー実行結果 | 配置先と拡張子を確認 |
| LoRA | 強度を指定して出力へ反映できる | 入力値と出力画像 | モデルパスと対応モデルを確認 |
| 出力先 | 生成物を書き込める | 保存ファイルと日時 | 所有者、権限、空き容量を確認 |
再起動後に一覧から消えるなら、設定ファイルが読み込まれていない、パスが一時領域になっている、マウントが完了する前にComfyUIが起動している、といった問題が考えられます。設定ファイルの位置と起動順を記録してから修正してください。
5. ComfyUI Nodesは依存関係ごとに追加する
自動インストール機能だけに任せて、ComfyUI Nodesを一括導入する方法は避けてください。共有ワークフローで必要なノードを先に洗い出し、関連するものから小さなグループ単位で追加します。
各グループで次を記録します。
- 配布元のリポジトリとコミット
- インストールしたPythonパッケージ
- 起動時に出た警告
- そのノードだけを使う最小ワークフロー
- 追加前後のComfyUI本体とフロントエンド
追加ノードの導入後は、画面へ表示されること、入力欄が開くこと、実行キューへ投入できること、画像を保存できることの順で確認します。ノードが表示されても実行時にModuleNotFoundErrorが出る場合は、Python依存関係が不足しています。逆に起動時からエラーが出る場合は、別ノードとの依存関係衝突を疑います。
6. 固定ワークフローで交付を判定する
検収用のComfyUIワークフローは、単純なサンプルではなく、実際にチームが使う構成から作ります。最低限、モデルのロード、サンプリング、画像保存を含め、必要であればVAE、LoRA、条件付け、アップスケールなども含めます。
ここで重要なのは、同じ入力を使って同じ処理経路を通せることです。完全に同じ画像が出ることを求めるのではなく、ノード欠落、モデル未読込、保存失敗、依存関係エラーがないことを確認します。実行ログ、ワークフローJSON、入力画像、出力画像を同じフォルダーへ保存してください。
そのまま使える検収チェックリスト
- [ ] macOS、Apple Silicon、Python、Gitの情報を保存した
- [ ] ComfyUI本体のコミットとフロントエンドのバージョンを記録した
- [ ] PyTorchのMPS利用可否と実行結果を保存した
- [ ] ComfyUIの起動ログに致命的なエラーがない
- [ ] checkpoint、VAE、LoRAをそれぞれ読み込めた
- [ ] モデルディレクトリーへアクセスでき、出力を書き込めた
- [ ] 追加ノードをグループ単位で導入し、コミットを記録した
- [ ] 固定ワークフローでロード、生成、保存が完了した
- [ ] ワークフローJSON、ログ、出力画像を共有フォルダーへ保存した
- [ ] ComfyUIを再起動し、同じワークフローをもう一度実行した
- [ ] SSH、画面共有、ブラウザ接続の許可範囲を確認した
- [ ] 共有アカウント、認証情報、モデルフォルダーの権限を確認した
運用上の経験則: 初回実行だけ成功しても、検収完了にはしないでください。再起動後にモデルパスや追加ノードが戻らない問題は、交付直後よりもチーム運用開始後に発見されやすいためです。
受け入れ前に比較するべき3つの運用方式
手元のMacへ構築する方式は、物理アクセスとデータ管理を自分で持てる反面、環境構築、保守、共有アカウントの管理も自分で担当します。汎用クラウドはすぐ試せる場合がありますが、Apple Silicon前提のPython、PyTorch、ノード互換性を自分で調整する必要があります。
一方、遠隔Macをレンタルする場合は、交付時に環境情報と検収記録がそろっているかが判断材料です。長期の固定負荷や物理インターフェースが必要な制作には自前機が向きますが、短期の検証、チーム共有、移行前の動作確認では、検収項目を契約前に明文化できる環境のほうが切り分けやすくなります。
ComfyUI リモートMacを選ぶときは、モデルの保管場所、追加ノードの固定方法、再起動後の復旧、接続ユーザーの範囲を確認してから申し込んでください。Macstripeの注文前に確認すべき設定項目やヘルプセンターも、必要な環境条件を整理する際の確認先になります。
既存のWindows/Linux環境や汎用クラウドをそのまま使うと、Apple Silicon向け依存関係の差、モデルパスの再設定、共有ノードのバージョンずれが起きやすく、交付後の原因調査に時間がかかります。短期のComfyUI検証やチーム用ワークフローの移行なら、モデル一覧、ノードリスト、固定ワークフロー、利用期間を先にまとめ、Macstripeのレンタル候補と照合するほうが、受け入れ後の手戻りを抑えやすいです。
よくある質問
ComfyUIをリモートMacへ導入した後、最初に何を確認すべきですか?
最初に確認するのは画面表示ではなく、macOSの情報、Apple Siliconの認識、PythonとPyTorchの実行環境、ComfyUIの起動ログです。続けてモデルの読み込み、保存先への書き込み、固定ワークフローの完走まで確認してください。最後に再起動し、同じワークフローが復旧するかを見てから受け入れます。
自作ノードや追加ノードを導入した後は、何を検証すればよいですか?
追加ノードは一度に全部入れず、使用するワークフロー単位で分けて導入します。各グループごとにリポジトリのコミット、Python依存関係、起動ログ、最小ワークフローの結果を記録してください。画面にノードが表示されても、実行時の依存関係エラーや保存処理まで通らなければ検収完了とは扱いません。
ComfyUIのワークフローでノードが見つからない場合はどう直しますか?
まずワークフロー内のノード名と、実際に導入されたノードの登録名を照合します。次に不足ノードの配布元、指定されたブランチやコミット、必要なPythonパッケージを確認し、単独で読み込みテストを行います。代替ノードへ置き換える場合は、画像サイズ、入力形式、出力形式が変わらないかも確認してください。
再起動後もComfyUIのモデルパスを維持するにはどうすればよいですか?
モデルをComfyUI本体の一時的な場所へ置くだけでなく、公式の追加モデルパス設定を使い、checkpoints、VAE、LoRAなどの実体パスを明示します。設定ファイルの場所、権限、マウント状態を記録し、ComfyUIを再起動した後に各モデルが一覧へ戻るか、固定ワークフローで再読込できるかを確認してください。