Midjourneyのプロンプトはなぜこんなに短くて済むのか：キーワード列と仕様書のあいだの境界線

サイトがこの2年で集めてきたプロンプトは、長さの分布がはっきり二つに分かれている。一方は英語で三、四十語ほどで終わる短い文、もう一方は三百から五百字、入れ子構造を持つJSON。中間はほとんどない。これは書き手の腕の差ではなく、モデルの性格の差だ。Midjourney向けに書くものと、GPT ImageやNano Banana Pro向けに書くものは、もともと別物なのだ。

短い側：一文とタグの羅列

この白黒リノカット版画のケースの本文はたった一行。白黒のリノカット版画、抽象幾何学図形、粗い彫り跡、純白の背景、ミニマルなフラットデザイン。三十数語で、画面はもう決まっている。

これだけ短くて済むのは、Midjourneyがカンマで区切られた各セグメントを独立した重み項として扱うからだ。語順が前にあるほど重みが大きくなる。だから最初の語は`abstract shapes`ではなく`Black-and-white linocut print`と書く。そうして初めて、版画フィルターをかけたイラストではなく版画そのものになる。同じ語の並びでも順番を変えれば、画面の主従関係も入れ替わる。

Midjourneyのプロンプトにほとんど完全な文が出てこないのも同じ理由だ。主語・述語・目的語をつなぐ言葉はMidjourneyにとって何の得にもならず、むしろ各キーワードの取り分を薄めてしまう。本当に効いてくるのはもう半分――パラメータの方だ。

パラメータはプロンプトの後半部分

白い砂丘に立つ漢服モデルは極端な例だ。描写部分は二文で終わり、そのあとに長い列が続く。`--ar 2:3 --quality 2 --style raw --sref ... --personalize ... --stylize 1000 --v 6.1`。

これらは飾りではない。`--style raw`はMidjourney標準の美化レイヤーを切り、`--stylize 1000`はスタイライズ強度を逆に大きく引き上げる――一見矛盾する二つのパラメータを重ねることで、「甘くないのに味のある」フィルム調が生まれる。`--sref`は4つのスタイル参照シードを紐づけていて、色調を同じファミリーに固定する役目を持つ。パラメータだけ削って描写だけ残すと、同じ文でも別の画像になる。

各パラメータが実際にどこまで効いているかを詳しく知りたい場合は、サイトに別途Midjourneyパラメータ早見表があるのでここでは繰り返さない。要点は一つ――Midjourneyではパラメータと描写は同じプロンプトの前半と後半であり、前半だけコピーしても意味がない。

短いことと雑であることは違う

肌のクローズアップのケースが持つ情報はたった三つ。肌質感の極端なクローズアップ、メイクブラシが表面をかすめる、ピンクの背景。あとは`--ar 2:3`を足せば終わりだ。

これが成立するのは、どの語も決定的な役割を担っているからだ。「extreme close-up」が距離を決め、「grazing」がブラシと肌の関係を決める（押し付けるのではなくかすめる）。ピンクの背景が全体のトーンを決める。三つの語がそれぞれ距離・動作・色調を担当していて、無駄な形容詞は一つもない。

対照的に月がシフォンのひまわりのように咲くケースを見てみると、核となるのは一つの比喩だけ――月がひまわりのように開き、花びらは光を透かすシフォン生地でできている。短文流のプロンプトが最も恐れるのは形容詞の積み重ねだ。「夢のような」「美しい」「雰囲気のある」といった言葉は、Midjourneyではほとんど画面を生み出さないのに、重みの枠だけはしっかり食ってしまう。

長い側：プロンプトを仕様書として書く

GPT Image 2やNano Banana Proに移ると、書き方はまったく変わる。浮遊するプリズムの製品写真は構造化されたJSONで、`negative_constraints`の一項目だけでも三種類が並ぶ。文字・透かし・UIボタンの排除、製品がフレームで切れたり中心からずれたりしないこと、展示台や台座を表示しないこと。

この書き方はMidjourneyではほとんど使えない――入れ子構造を読むのが得意ではなく、否定的な制約は`--no`パラメータで個別に渡すしかない。しかし新世代のモデルにとっては、階層化されたキー名そのものが指示になる。モデルは`lighting`の下にある一文が照明だけを担当していると理解し、`composition`と混同することはない。この書き方を体系的に学びたい場合は構造化プロンプトの書き方を参照してほしい。

注意すべきは、長いプロンプトのリスクもここにあるということだ。細かく書けば書くほど、自己矛盾を起こす確率も上がる。サイトで実際に安定して使えている長いプロンプトは、基本的に一つのキーの中では一つのことしか言っていない。

同じ画面を別モデルに移すとき、プロンプトはどう変えるか

これはサイトで最もよく聞かれる質問で、実践としては三つのステップがある。

長から短へ（JSON → Midjourney）：まずJSONをカンマ区切りの列に平坦化し、「主体 → シーン → 質感 → レンズ → 光 → スタイル」の順に並べ、最も重要なものを先頭に置く。否定的な制約は文に直訳せず、まとめられるものは`--no`に押し込み、まとめられないものは削る――Midjourneyは「〜しないでほしい」への従順さが昔から高くない。比率は`aspect_ratio`フィールドから`--ar`に移す。

短から長へ（Midjourney → GPT Image / Nano Banana Pro）：逆に今度は補っていく必要がある。パラメータは人間の言葉に訳す――`--ar 2:3`は「縦長、比率2:3」、`--style raw`は「過度に美化せず、リアルな肌質感を保つ」、`--stylize`のその段階のスタイル強度は具体的なスタイル描写に書き換える。前半の描写だけを貼り付けても、新世代モデルはたいてい情報量不足で構図もランダムな画像を返してくる。

両方で動かす必要があるもの：語順だ。Midjourneyは位置で重みを割り振り、新世代モデルは構造で重みを割り振る。前者はキーワードを前に出し、後者は正しいキーに入れる。そうして初めて効果が噛み合う。

最後にもう一つ。モデル名をスタイルタグとしてプロンプトに書き込むのはやめておいたほうがいい。`in the style of Midjourney`と書いても、どのモデルに対しても効果はなく、重みの枠を一つ無駄にするだけだ。

ついでに見ておきたいもの

同じキーワード列タイプのケースとしては、サイトにはほかにも横一列に並んだ5匹の動物のEC素材がある――単色背景と「全員カメラの方を向く」という一文だけで、そのまま使える理由になっている。中国語と英語どちらでプロンプトを書くべきかについては、別記事中国語か英語かでプロンプトを書くで対照して読める。