このサイトの新シリーズ「生成AI実験室」を始めます。Botの話から離れて、生成AI——当面は動画生成——を手元の環境でどこまで扱えるかを検証していく連載です。方針はBot開発記と同じで、感想ではなく実測を書きます。
1本目の題材は、2026年8月にオープンウェイト公開された動画生成AI「MiniMax-H3（Hailuo 3.0）」。これを手元のMacBook Pro（M5・ユニファイドメモリ32GB）で動かせるか、という検証です。結論を先に言うと、「動かないと結論し、その後に量子化版で一応動き、動いた結果として別の壁が実測できた」——この行ったり来たりの全部が、たぶん読む価値のある部分です。
MiniMax-H3とは何か
まず対象の整理から。H3は、テキスト・画像・動画・音声を単一のモデルで扱う33Bパラメータの「omni-modal」モデルで、音声付きの動画（ローカル版は768p・24fps・4〜15秒）を一発で生成します。2026年7月末に発表され、8月3日に重みが公開されました。ComfyUI（画像・動画生成の定番ツール）がネイティブ対応しており、公式のワークフローテンプレートも用意されています。
ライセンス面では、米国・EU・英国・韓国はローカル配備権の対象外ですが、日本は除外リストに入っておらず、年商規模の条件を満たせば自己ホストが認められています（原文の確認は各自で。ここは法務助言ではありません）。つまり日本の個人にとって、障害は法律ではなくハードウェアです。
前提知識：Macの「ユニファイドメモリ」とは
本題の前に、この検証を理解する鍵になる予備知識をひとつ。Macの「メモリ32GB」と、ゲーミングPCの「VRAM 32GB」は、同じ32GBでも意味がまったく違います。
一般的なWindows PCやワークステーションでは、メモリは2種類に分かれています。CPUが使うメインメモリ（RAM）と、グラフィックボードに載っているGPU専用のメモリ（VRAM）です。「VRAM 32GBのGPU＋システムRAM 64GB」という構成なら、合計96GBの置き場所があり、GPUは自分専用の32GBを誰にも邪魔されずに使えます。AIモデルの「必要VRAM」という表記は、この専用メモリを前提にしています。
一方、Apple Silicon搭載のMacは「ユニファイドメモリ」という方式です。CPUとGPUが1枚のチップに統合され、1つのメモリプールをCPU・GPU・OS・全アプリで共有します。CPUとGPUの間でデータをコピーして往復させる必要がないため、多くの用途ではむしろ効率的で、これ自体は優れた設計です。
ただしAIモデルを載せる話になると、意味が変わります。「32GB」はGPU専用の32GBではなく、macOS本体もブラウザも全部が同居する32GBです。さらにmacOSは、システムを守るためにユニファイドメモリの全量をGPUに割り当てず、実効ではおおむね3/4程度が上限になります。つまり「必要VRAM 32GB」のモデルを「ユニファイドメモリ32GB」のMacで受け止めることは、数字が同じでも土俵が違うのです。
そして、収まらなかった分はSSD上の「スワップ」領域に退避されます。SSDはメモリより桁違いに遅いため、スワップとの出入りが始まった瞬間に処理速度は大きく落ちます。この記事の後半で実測するのは、まさにこの現象です。
第一の結論：この構成では動かない
検証を始めてすぐ、3つの独立した壁に当たりました。
壁1・メモリ。H3を1本生成するには、拡散モデル本体（BF16で61.7GB）、テキストエンコーダ（48GB）、映像・音声VAEが要ります。コミュニティの実測では、専用VRAM 32GBのGPUと64GBのシステムRAMを積んだマシンでピークVRAM約31.8GB。当方のMacは、CPU・GPU・OSがすべて共有する32GBが全部です。比較になりません。
壁2・量子化カーネル。サイズを落とす量子化（INT8等）の実装はNVIDIA CUDA前提で、Apple SiliconのMetalには等価な実装がない。公式のGGUF（Apple環境の定番形式）も当時未提供でした。
壁3・演算量。仮にメモリが足りても、33Bのモデルで768pの動画を生成する演算量は、10コアの統合GPUには桁違いに重い。
3つは独立していて、1つ解いても残り2つが立ち塞がる。よって「このMacでの実行は不可」——これが8月中旬の第一の結論でした。
第二幕：コミュニティ量子化で「一応」動いた
ところがその後、コミュニティ製のGGUF量子化版（Q4）が使える状態になり、話が変わります。拡散モデルが約19.4GBまで縮み、ComfyUI経由でMac上でも生成が通るようになりました。低解像度・少ステップの設定なら、1本の試し焼きが現実的な時間で終わります。
「不可能」の結論は、正確には「BF16では不可能」だったわけです。ここは素直に認識を更新しました。
第三幕：動いたからこそ、本当の壁が実測できた
ただし快適に動いたわけではありません。解像度を上げると、生成時間が急激に伸びる。当初は「参照画像を3枚も入れているからだ」と考えていましたが、実測でこれは誤りと判明します。参照を3枚から1枚に減らしても速度はほぼ変わらず、時間は画素数にきれいに比例していました。犯人は参照枚数ではなく解像度です。
では解像度を上げると何が起きているのか。メモリの実測に踏み込むと、状況は明快でした。量子化してもなお、拡散モデル約19.4GB＋テキストエンコーダ約15.4GB＋VAE類で合計約40GBが、32GBのマシンに載っている。スワップ（あふれた分をSSDに退避する仕組み）は埋まっているだけでなく毎分数GBの規模で出入りし続け、同一設定の生成でも所要時間が4割近くぶれる。つまり低解像度では演算が律速、高解像度ではメモリが律速——この切り替わりが、体感の「急に遅くなる」の正体でした。
検証として面白いのは、この過程で自分たちの過去の結論を2つ訂正していることです。「参照枚数が時間に直結する」も「律速はメモリではなく演算」も、特定条件でだけ正しい観測を一般化した誤りでした。Bot開発記で書いた「好成績を疑う」と同じで、生成AIの検証でも、結論には測定条件を必ず添える必要があります。
現在の運用：役割分担に落ち着いた
最終的な運用はこうなりました。Macは設計の拠点——プロンプトの設計、ワークフローの組み立て、低解像度での試し焼き、素材の前処理までを担当する。本番の生成（高解像度・長尺）はクラウドGPUを短時間借りて焼く。48GBクラスのGPUなら時間貸しで安価に借りられ、量子化版がそのまま載ります。常時契約は不要で、焼くときだけ立てて、終わったら消す。
「ローカルで完結させたい」という当初の目論見からすると敗北に見えますが、実測を経た今は、これが費用対効果の最適点だと考えています。ローカルの価値は本番生成ではなく、試行錯誤の回転数にありました。
まとめ
オープンウェイトの大型動画モデルを手元で扱う際の要点を3つにまとめます。第一に、公称の必要スペックは「専用VRAM＋システムRAM」の構成が前提で、ユニファイドメモリ機はその合算と同列に比較できない。第二に、量子化で「載る」ことと「快適に動く」ことは別で、律速は解像度によって演算からメモリへ移る。第三に、結論には測定条件を添える。条件を離れた一般化は、後で自分を騙します。
このシリーズでは今後、クラウドGPUでの運用手順やコスト比較、Blenderと組み合わせた動きの制御などを扱っていく予定です。
本記事の数値は2026年8月時点の検証記録に基づきます。モデル・ツールの仕様やライセンスは変わり得るため、実施の際は最新の一次情報を確認してください。
コメント