ローカルで動かせる画像生成AIはどう選ぶ？

ローカル画像生成AIを選ぶときは、「無料で無制限に作れるか」だけでなく、モデル license、必要hardware、更新、UI、custom ワークフローまで含めて考える必要があります。

cloud型と違い、自分のPCでモデルを動かせる一方、導入と保守も自分で担当します。

先に結論：最初に比較する4点

表は横にスクロールできます

比較ポイント	要点
Open-weightかどうかを確認する	Black Forest LabsはFLUX.1 / FLUX.2の公式inference repositoryを公開しており、対応モデルのlocal inference codeを提供しています。
FLUX.1はModelごとにLicenseが違う	公式FLUX.1 repositoryでは、FLUX.1 schnellはApache 2.0、FLUX.1 devや一部dev系モデルは別licenseで提供されています。
FLUX.2は最新のLocal実行環境も確認する	FLUX.2公式repositoryにはlocal installationとCLI実行方法が公開されています。
Hardware要件を先に見る	local生成はGPU memory、system memory、storage、モデル sizeなどの影響を受けます。

候補・条件ごとの違い

Open-weightかどうかを確認する

Black Forest LabsはFLUX.1 / FLUX.2の公式inference repositoryを公開しており、対応モデルのlocal inference codeを提供しています。

ただし「weightsをdownloadできる」ことと「どんな用途でも自由に使える」ことは同じではありません。

モデルごとのlicenseを確認します。

FLUX.1はModelごとにLicenseが違う

公式FLUX.1 repositoryでは、FLUX.1 schnellはApache 2.0、FLUX.1 devや一部dev系モデルは別licenseで提供されています。

商用利用する場合は、使うモデル名とlicenseを対応させます。

FLUX.2は最新のLocal実行環境も確認する

FLUX.2公式repositoryにはlocal installationとCLI実行方法が公開されています。

公式exampleは高性能GPU環境でtestされているため、手元のPCで快適に動くかは別途確認が必要です。

Hardware要件を先に見る

local生成はGPU memory、system memory、storage、モデル sizeなどの影響を受けます。

「動く」と「実用速度で回せる」を分け、自分のhardwareとruntimeに合うモデルを選びます。

選ぶときに見る条件

UIかCodeかを決める

GUIでプロンプト中心に使いたいのか、Python、node-based ワークフロー、APIとして組み込みたいのかで構成が変わります。

大量生成や独自pipelineなら、モデル単体だけでなくruntime / ワークフロー ツールまで含めて選びます。

Dataを外へ出したくない用途を整理する

local実行では生成処理を自分のmachine内へ置けます。

ただしモデル download、plugin、外部API、telemetryなどを併用すれば完全offlineとは限らないため、構成単位で確認します。

Updateと再現性を管理する

モデル、VAE、LoRA、ワークフロー、seed、プロンプトなどを記録します。

local環境では自由度が高い分、versionを固定しないと同じワークフローを再現しにくくなります。

Cloudとの併用も候補にする

試作はcloud、本番batchはlocalなど、どちらか一方に限定する必要はありません。

setup負荷とusage costを比較して分けます。

モデル名・license・PC条件をセットで見る

ローカル実行を選ぶ前に、候補modelの名前と用途を一行ずつ記録します。「FLUXを使う」とまとめると、同じfamilyにある異なるlicenseや必要環境を取り違えます。2026年10月10日にBlack Forest Labs公式repositoryで確認した例では、FLUX.1 schnellはApache 2.0、FLUX.1 devや一部派生modelはNon-Commercial Licenseです。FLUX.2もKlein 4BはApache 2.0、Klein 9B系とdevはNon-Commercial Licenseです。inference code、重み、LoRA、追加データ、UIの利用条件も別々に確認してください。

表は横にスクロールできます

model例	公式repositoryのlicense表示	用途判断で確認すること
FLUX.1 schnell	Apache 2.0	取得する重みと追加物の個別表示
FLUX.1 dev	Non-Commercial License	業務利用なら別licenseの要否
FLUX.2 Klein 4B / Base 4B	Apache 2.0	使う4B variantと推奨環境
FLUX.2 Klein 9B / 9B KV / dev	Non-Commercial License	名前の近い4B条件を流用しない

これはFLUX候補の例で、全ローカルmodelの一覧ではありません。ミラー配布、量子化版、追加学習weightsのlicenseが自動的に同じになるとは限りません。商用案件では取得元・ファイル名・version・licenseを保存し、曖昧な場合は利用前に権利担当へ確認します。Apache 2.0と表示されるmodelでも、生成物に写る第三者の著作権・商標などの権利まで保証されるわけではありません。APIサービスの条件はモデルweightsとは別に読みます。

次にPCの条件を照合します。OS、GPU型番とVRAM、RAM、空きstorage、runtime、driver、利用UIを記録し、公式の最低・推奨要件と比べます。Black Forest LabsはFLUX.2 Klein 4Bの参考としてconsumer GPUを挙げていますが、各PCでの速度や安定性の保証ではありません。FLUX.2 devの公式例は大容量VRAMを要求し、量子化やremote text encoderを使う別構成もあります。「起動できる」と「業務で許容できる時間で反復できる」は別の合格条件です。

本格利用前に、権利が明確な架空の題材で①標準画像を生成、②既存画像を編集、③再起動後も同じworkflowを再実行、④複数枚を連続処理、⑤更新後に再実行します。所要時間、失敗回数、VRAM不足、必要容量、調整の手数を記録します。記事では読者向けの検証手順を示し、特定GPUの実測結果は主張しません。処理が長い場合は平均だけでなく、最大待ち時間とクラッシュ後の再開方法も見ます。

セットアップは公式repositoryの手順を読み、仮想環境を分離して依存関係・model version・重みの配布元・license・起動引数を記録する順です。最初は最小構成で一枚生成し、その後に編集やbatch処理を追加します。起動できない場合はGPU driver、Python / library version、runtime、空き容量を順番に切り分けます。重みを再取得する前に、配布元とfile hashも確認します。model、VAE、LoRA、workflow、seed、promptを記録しないと、更新後に同じ画像を再現できません。

「ローカルだから完全オフライン」とは限りません。初回の重み取得後に通信を遮断して起動できるか、UIの更新確認、extensions、外部API、telemetry、保存先を調べます。外部text encoderやupscalerを使えばpromptや画像が端末外へ送信される場合があります。機密データを扱う場合は、社内のネットワーク条件、ログと一時ファイルの保管場所も先に合意します。

商用利用が必要でモデル条件を満たせないなら、そのmodelは候補から外し、利用許諾や別API契約を確認します。PCが要件に届かない、保守時間が取れないなら、機密でない題材をcloudで試し、月額・生成数・作業時間を比べます。オフライン性と反復量が重要で、license・hardware・担当者を確保できる場合にローカルへ進みます。ライセンス、環境、保守のどれか一つでも未確認なら、インストールより先にその条件を解決してください。

さらに、更新担当と停止条件も決めておきます。modelのlicenseが改訂された、依存ライブラリに脆弱性が見つかった、ドライバ更新後に再現できない場合は、新規生成を一時停止し、既存環境・重み・workflowのversionを保全します。月額がないことだけで経済性を判断せず、PC購入・電気代・保守工数・待ち時間を、同じ期間のAPIやcloud費用と並べます。

AIものさしの判断

ローカル画像生成AIは「月額がないから得」と単純化せず、hardware・license・maintenanceを含めて判断する必要があります。

モデル license→hardware→runtime→ワークフロー→data boundary→maintenanceの順に確認すると、自分の制作環境に合う構成を選びやすくなります。

AIものさしでは、モデルを起動できたことではなく、licenseを守り、実用速度で再現可能なワークフローとして運用できる状態をこのワークフローの完了条件にします。