構造化プロンプトの書き方:jsonプロンプトのフィールド設計
短文のプロンプトは1行のインラインコードを書くようなもので、動くことは動くが、要求が複雑になった途端すべてが1行に詰め込まれて誰にも読めなくなる。構造化プロンプトはむしろインターフェースを定義するのに近い――主体、場面、光といった情報をフィールドごとに分割し、それぞれに値を与えることで、モデルは読み取りやすくなり、自分で修正するときもどのフィールドがどの効果に対応しているかがはっきりする。この記事はオカルト話ではなく、フィールド設計の考え方に沿ってこの書き方を分解して解説する。
いつ構造化するべきで、いつ必要ないか
判断基準はシンプルだ。要求の中に独立した変数が3つを超えたら、フィールドに分割するべきタイミングだ。シンプルなスタイル変換の画像で「この人物+このタッチ」という2つの変数しかないなら、一文で十分で、無理やり10個のフィールドに分けるのはむしろ過剰設計であり、自分の時間を浪費するだけだ。しかし複数画像の参照、画面内の文字、複数の情報ブロック(商品画像の9分割グリッドや複数アングルの設定図など)が絡む場合、変数の数が増えた時点で短文プロンプトの情報密度では足りなくなる。このときこそ構造化した書き方を使うべきだ。
この境界線を判断する方法は単純だ。要求を声に出して読み、その中に「かつ」がいくつあるか数える。「かつ」が3つを超えたら、フィールドに分割するべきだ。
よく使うフィールド設計、6つの基本フィールドでほとんどの場面をカバーできる
- style:全体のスタイルの指定。一文でトーンを決める。たとえば「シネマティックな写実写真」
- subject:主体は誰で、どんな状態か。これは一番曖昧に書かれがちなフィールドで、動作と表情まで具体的にする必要がある
- scene:場面と小道具、空間の関係性を伝える。主体と環境の相対的な位置関係を書き漏らさないこと
- lighting:光源の方向、硬さ・柔らかさ、色温度。このフィールドを単独で切り出しているのは、仕上がりの質感への影響が一番大きいからだ
- camera:構図の比率、レンズのアングル、フォーカスの位置。純粋に技術的なパラメータで、内容層とは分けて書く
- negative(モデルが対応していれば):明確に出したくない要素。たとえば「余分な指を出さない、背景に雑物を出さない」
フィールドの並び順にも考え方がある。インターフェースのパラメータと同じで、核となるパラメータを先に、任意のパラメータを後に置く。subjectを先に、次にscene、次にlighting、最後にcamera。ネガティブ項目は構造の一番最後に単独で置き、肯定的な描写と混ぜないこと。
テンプレート1:人物写真系、完全なフィールドの例
style:フィルムの質感を持つ写実写真、粒状感はわずか
subject:ワークジャケットを着た女性が一人、リラックスした座り姿で、視線はカメラの外側を見ている
scene:古びた工房の内部、背景には雑然とした工具や歯車のインスタレーションがあり、機械的な雰囲気を作り出す
lighting:片側からの窓の光、硬い光でエッジがはっきりしている、色温度は中間からやや寒色寄り
camera:バストアップ構図、浅い被写界深度、縦位置4:5
この工房の肖像写真の実例は、まさにこのフィールド分割で作られている。場面の小道具と光は別々のフィールドとして伝えられ、混ぜて書かれていない。この種の人物写真の要求は、フィールドをきちんと分けたあとやり直しの発生率が明らかに下がる。
テンプレート2:EC静物系、完全なフィールドの例
style:ドラマチックな光と影を使ったフード写真、高コントラスト
subject:ブラウニーとバニラアイスクリーム、チョコレートソースが今まさに注がれている瞬間
scene:濃い色の木製の台、背景はぼかし、余計な小道具はなし
lighting:サイド逆光、チョコレートソースの流れる質感とツヤを際立たせる
camera:クローズアップ構図、正方形1:1、ソースを注ぐ瞬間にフォーカス
このフード静物の実例は「動作の瞬間」をsubjectフィールドの一部として単独ではっきり伝えていて、そのおかげでソースの流れる感じが静止したドロっとした塊に写ってしまうことがなかった。EC商品カテゴリーの静物の要求にはこのフィールド構造がそのまま応用できる。
テンプレート3:複数アングルとフィギュア系、完全なフィールドの例
style:3Dレンダリングの質感、コレクター向けの精緻なディテール
subject:石片を組み上げた人型シルエットの彫刻、層状に組み立てた痕跡がはっきり見える
scene:ミニマルな展示台、余計なものがないグレーの背景
lighting:トップライトに両サイドから補助光、素材の質感を際立たせる
camera:正面構図、正方形1:1、中央対称
このシルエット彫刻の実例の層状に組み立てたディテールは、subjectフィールドに「層状の痕跡がはっきり見える」という要求を明記したことで保たれている。この一文を書かないと、モデルは高い確率で継ぎ目を滑らかに丸めて消してしまう。
複数アングルや2人物の対比のように「同じキャラクターの複数の状態」が必要な要求では、フィールド設計にもう一項目加えるとよい――各区画それぞれの差異点を明確に伝えることだ。どこを変えてどこを変えないべきかをモデル自身の判断に任せないこと。
この実写・漫画風対比の実例では、プロンプトに「左側は写実的な質感を保ち、右側は漫画風のレンダリングに変える。服のデザインは一致させる」という一文を単独で書いている。この差異の説明こそ、構造化した書き方の中で単独で切り出すべきフィールドだ。クリエイティブなアイデアカテゴリーにはこの種の2枚組対比の要求が少なくない。
どのモデルがこの書き方に向いていて、どのモデルは向いていないか
このフィールド化した書き方はすべてのモデルに万能というわけではない。Nano Banana Proは構造化された長いプロンプトの解析が明らかに完成度が高く、フィールドを細かく分けるほど実行が正確になる。前述のいくつかのテンプレートの実例は基本的にこのモデルによるものだ。GPT Image 2は別の路線をとっていて、構造化された長い描写を対話形式の連続的な修正に「翻訳」することのほうが得意だ。無理やりフィールド一式を詰め込んでも、素直に人間の言葉で伝えるより効果が良いとは限らない。具体的な違いはGPT Image 2対Nano Banana Proの実測比較を見てほしい。速度がより速いNano Bananaは両者の中間で、フィールドを細かく分けすぎず、大枠を押さえて細部を捨てるほうが安定する。
このデザイナーズトイのグリッドの実例はGPT Image 2で実行した構造化グリッドレイアウトの要求だ。フィールド化した書き方はこのモデルでも使えるが、的中率は前述のNano Bananaケースほど安定していない。これは「構造化した書き方の効果はモデルによって異なる」という結論を裏付けるもので、どのモデルに当てはめても同じように効くわけではない。
フィールド設計の考え方が身についてきたら、あらためて短文プロンプトの万能構成公式を見返すと、本質的には同じことだと気づくだろう。ただ構造化した書き方は、その公式の中に暗黙的に含まれていた順序を、フィールドとして明示的に分解しているにすぎない。要求がある程度複雑になったら、文章を積み上げるよりフィールドに分けるほうが保守しやすい。具体的な重み制御をフィールドとどう組み合わせるかについてはプロンプトの重みの記事を、対話形式の画像編集についての完全な解説はGPT Image 2プロンプトガイドを参照してほしい。トップページimage.faxianai.comには完全な実例集があり、モデル百科には各モデルのフィールドへの適応状況がまとまっているので、そのまま参考にして書き換えられる。