建築イメージに使う画像生成AIはどう選ぶ？

建築イメージで画像生成AIを使うときは、写真のような見栄えだけでなく、元の構図・建物形状・リファレンスをどこまで維持できるかで選ぶ必要があります。

コンセプト提案、外観variation、内装mood、既存写真の改変では必要な機能が違います。

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

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

比較ポイント	要点
まず用途を「発想」と「再現」に分ける	初期conceptを広げたいならtext-to-画像中心でも使えます。
FireflyはComposition Referenceを見る	Adobe Fireflyではリファレンス画像のcompositionを使い、outlineやdepthを参考にしながら画像 variationを生成できます。
MidjourneyはImage PromptとEditを見る	Midjourneyの画像 プロンプトは、リファレンス画像からcontent、composition、colorsなどの影響を与えられます。
FLUX系は独自Pipelineへ組み込む用途を見る	FLUX.2の公式inference repositoryではtext-to-画像と画像 editingのlocal実行が案内されています。

候補・条件ごとの違い

まず用途を「発想」と「再現」に分ける

初期conceptを広げたいならtext-to-画像中心でも使えます。

一方、既存プランやrenderの形を保ってmaterial・lighting・スタイルだけ変えたい場合は、composition / リファレンス controlが重要です。

FireflyはComposition Referenceを見る

Adobe Fireflyではリファレンス画像のcompositionを使い、outlineやdepthを参考にしながら画像 variationを生成できます。

Strengthでリファレンスへの追従度も調整できるため、元構図を残したvariation制作に使えます。

MidjourneyはImage PromptとEditを見る

Midjourneyの画像 プロンプトは、リファレンス画像からcontent、composition、colorsなどの影響を与えられます。

2026年10月10日時点で、Midjourney公式DocsはEdit ModelをV8.1 / V8.2で利用可能とし、最大4枚の参照画像、領域編集、canvas拡張を案内しています。建築の寸法・形状維持を保証する機能ではありません。

FLUX系は独自Pipelineへ組み込む用途を見る

FLUX.2の公式inference repositoryではtext-to-画像と画像 editingのlocal実行が案内されています。

自前のワークフローで複数リファレンスやbatch処理を組みたい場合は候補になりますが、cloud serviceより環境構築の負荷が高くなります。

選ぶときに見る条件

建築では「形が正しい」と思い込まない

AI画像はconcept 画像としては便利ですが、寸法、構造、設備、法規適合を保証するものではありません。

完成予想図として外部へ出す場合は、実際の設計dataと矛盾していないか確認します。

同じ建物でVariationを作れるか試す

昼夜、季節、外装材、植栽、家具、lightingなど1要素ずつ変えて確認します。

毎回建物そのものが変わるツールでは、デザイン comparisonに使いにくくなります。

Image Editの粒度を見る

窓だけ、壁材だけ、家具だけを変えたい場合は部分編集のしやすさが重要です。

全体再生成より、既存画像を維持して必要箇所を修正できるワークフローを重視します。

Client提出前にAI表現を整理する

AIで生成したconceptなのか、設計dataに基づくvisualizationなのかを混同させないようにします。

発想案と設計再現で受入条件を分ける

建築ビジュアルでは「元の建物を保ったまま雰囲気だけ変える」ほど制御が必要です。最初に図面や参照画像へ固定項目と変更項目を書き込みます。固定候補は建物外形、窓位置、階数、道路との関係、カメラ位置。変更候補は外壁材、植栽、時間帯、家具、照明です。「外観をおしゃれに」のように複数を同時に変えると、何が守られたか評価できません。

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

用途	固定するもの	変えるもの	出力の使い方
初期コンセプト	敷地条件、用途、必要室	素材感、配色、光	方向性の異なる案を検討
外観variation	外形、階数、窓、視点	外装材、季節、植栽	同じ構図の差分を比較
内装mood	部屋の輪郭、開口、動線	仕上げ、家具、照明	素材や雰囲気の検討
既存画像の部分修正	対象外の領域、カメラ	窓一つ、壁面一つ	局所編集を評価

Adobe FireflyのComposition Referenceは、参照画像のoutlineやdepthをもとに構図のvariationを作り、Strengthで追従度を調整する機能として案内されています。これは寸法や構造を拘束するCAD機能ではありません。Midjourney Edit Modelは参照画像を使った変更や領域編集に対応しますが、意図しない箇所が変わらないとは限りません。FLUX.2にも複数の参照画像編集があります。いずれも建築精度や図面適合を保証しないため、目的別の受入テストを行います。

比較用の基準セットを三つ用意します。Aは同じ箱形建物を昼と夕方で描く。Bは同じ輪郭から外壁材だけ変える。Cは窓一か所だけを編集する。各ケースで固定項目に「維持」「許容できる差」「破綻」を付け、破綻した条件と修正手順を記録します。Aだけ通る候補はコンセプト案向きで、B・Cまで通らなければ設計意図を保つvariation用途には適さない可能性があります。これは候補比較の手順であり、本文で実測した順位ではありません。

入力シートには、①参照画像と使用許諾、②固定する建築条件、③変える要素、④変更禁止要素、⑤利用modelとreference設定、⑥設計担当が照合する資料、⑦「コンセプト案」と表示する範囲を書きます。顧客名、住所、現場写真、未公開設計を含む素材は、クラウドへ送ってよいと分かるまで使いません。検証には寸法や顧客情報を含まない簡略図を使います。ローカル実行でも、pluginやAPI、telemetryがネットワークへ出る可能性を構成ごとに確認します。

最終チェックで窓数・階数などが破綻したら、その画像を設計事実の根拠に使いません。コンセプト提案なら注記を付けて見せるかを判断し、設計説明ならCAD/BIMの正しい形状を使って作り直します。寸法、構造、設備、避難経路、法令適合、施工可能性は元の図面や担当者が確認し、画像と仕様書を別管理します。画像だけを見て設計変更として扱わないよう、納品物には「イメージ案」等の表示を付けます。

発想を広げる段階では、固定条件を必要最低限にして複数案を出します。顧客へのvariation説明では、固定条件、許容差、レビュー担当を増やします。完全な形状維持が必要ならAI画像を図面の代わりにせず、CAD/BIMから書き出した正確な形へAIの素材案を重ねる方法を検討します。目的が決まった後で、参照・部分編集・ローカル実行のどの機能が必要か選ぶと、見栄えだけで契約する失敗を避けられます。

比較後の判定記録は、候補ごとに「固定項目」「変えた項目」「破綻した項目」「修正可能か」「利用目的」を並べます。たとえば、初期案では窓位置の変化を許容しても、顧客向けの外装比較では窓位置を固定する、と使い分けます。同じ出力を用途の異なる会議で使い回すと、誰が見ても設計承認済みの画像と誤解するおそれがあります。

実物件の写真を参照に使う場合は、画像内の看板・住所・人物を削るだけでなく、写真そのものの利用許諾と顧客契約を確認します。画像を外部へ送れないときは、形状を簡略化した匿名素材へ置き換えるか、AIを使わない案へ切り替えます。納品前に「AI生成」「設計担当が照合済み」「未検証の要素」を分けて表示すると、見栄えと設計上の正確さを混同させずに説明できます。

提案用の画像は、図面・仕様書と同じファイル名やフォルダに置かず、「concept」「要照合」など状態が分かるラベルを付けて保管します。

発注者へ見せる資料には、生成した要素と設計資料から転記した要素を凡例で分けます。レビュー時は各固定条件を画像上で指し示せるようにし、目視だけで判断できない寸法や法規は専門資料へ戻ります。

実務では「形状の正確さ」「色や素材の方向性」「説明資料としての分かりやすさ」を別々に確認します。一つの画像をこの三つすべての根拠にしないことで、提案用の見せ方が設計承認と誤解されるのを防ぎます。

同一条件での比較を続ける場合は、参照画像、prompt、生成設定、model version、日時を保存します。後日modelやUIが変わった場合、古い画像を最新機能の結果として扱わず、新旧の比較時期を記録して判断を更新します。

AIものさしの判断

建築向け画像AIは、リアルさだけでなく「元の空間構造をどこまで固定しながらvariationを作れるか」で見ると選びやすくなります。

concept→リファレンス/composition→variation→partial edit→デザイン verificationという順にすると、AIを設計そのものではなくvisual explorationとして使えます。

AIものさしでは、リアルな建築画像が生成できたことではなく、リファレンスとの関係を把握し、設計事実とconcept表現を分けて使える状態をこのワークフローの完了条件にします。