画像をJSONプロンプト化する方法：編集と再現チェックの実践手順

画像からJSONプロンプトを作る目的は、元の「秘密のプロンプト」を復元することではありません。参照画像を、項目ごとに編集でき、生成後に検証できる視覚仕様へ変換することです。実務では、見えている事実だけを記録し、維持する要素と変更する要素を分け、複数の候補を生成し、同じチェック表で参照画像と比較します。

JSONにすると、被写体、構図、照明、色、素材、文字を別々に扱えます。しかし完成画像のピクセルだけから、正確なカメラ機種、画面外の照明方式、厳密なフォント名、seed、作者が最初に書いた文を特定することはできません。目標はピクセル単位の複製ではなく、変更可能で評価可能な視覚的近似です。

以下では、そのまま使える分析用メタプロンプト、JSON構造、生成への受け渡し、合否判定までをまとめます。

このワークフローでできること

次の用途に向いています。

• 参照画像の視覚的な骨格を維持し、一部だけを変更する
• 同じ仕様を複数の画像モデルで比較する
• 「雰囲気は近いが、なぜ似ていないのか」を特定する
• 写真、広告、ポスター、UI、イラストを同じ基準でレビューする

JSONを「復元した元プロンプト」と呼ばないでください。最終画像には、生成履歴、非公開の参照画像、無視された指示、編集工程、後処理がすべて残っているわけではありません。

有用なJSONには三つの条件があります。

1. 観察可能：すべての事実が画像内の証拠で裏付けられる
2. 編集可能：重要な視覚要素が別フィールドになっている
3. 検証可能：各フィールドを出力画像で確認できる

始める前に用意するもの

必要なのは次のものです。

• 利用権を確認した、できるだけ高解像度の参照画像
• 画像を読み取れるvisionモデル
• 画像生成または画像編集ツール
• JSON、モデルの版、設定、出力を保存する場所
• 「絶対に維持するもの」と「変更してよいもの」の短い定義

ブラウザの枠、コメント欄、デザインに含まれない余白は切り取ります。縦横比の変更が目的でない限り、最初は元の比率を維持します。

OpenAIの画像・vision公式文書とGoogleの画像理解公式文書では、画像入力の分析方法が案内されています。各社の生成ツールには参照画像や反復編集を使う方法もあります。ただしリクエスト形式は異なるため、ここでは特定モデルに依存しない手順にします。

手順1：参照画像から観察JSONを作る

画像と一緒に次のプロンプトを送ります。見えない情報を事実として補わず、判断できない値を null にするための指示です。

あなたは視覚的証拠を扱う分析者です。添付した参照画像を分析し、
有効なJSONオブジェクトを1個だけ返してください。

ルール:
1. 画像内で直接確認できる証拠だけを記述する。
2. 隠れた原因、元プロンプト、正確なカメラ機材、正確な日付、
   見えない照明技術、読めない文字を推測しない。
3. 画像から判断できない値は null にする。
4. 異なる視覚要素は別フィールドに分ける。
5. 明確に読める文字は一字ずつ正確に転記し、欠けた文字を補わない。
6. 左右、上下、前景・背景、中央・偏り、相対サイズ、重なりを明記する。
7. 出力前にフィールド間の矛盾を確認する。
8. 曖昧な形容詞の羅列ではなく、具体的な文を値にする。

次の構造を返す:
{
  "image_type": null,
  "subject": null,
  "action": null,
  "location": null,
  "composition": {
    "orientation_and_aspect_ratio": null,
    "framing_and_crop": null,
    "subject_placement": null,
    "spatial_relationships": null,
    "negative_space": null
  },
  "lighting": {
    "visible_direction": null,
    "apparent_temperature": null,
    "softness_and_contrast": null,
    "highlights_reflections_shadows": null,
    "unknown_causes": null
  },
  "color_palette": null,
  "materials_and_textures": null,
  "camera_and_focus": {
    "viewpoint": null,
    "perspective": null,
    "depth_of_field": null,
    "sharp_and_blurred_regions": null
  },
  "text_and_typography": {
    "verbatim_text": [],
    "placement_and_alignment": null,
    "size_hierarchy": null,
    "visible_lettering_style": null,
    "unreadable_text": null
  },
  "style": null,
  "mood_and_vibe": null,
  "uncertainties": [],
  "exclusions": null
}

生成前にJSONを検証する

詳細な出力でも、そのまま正しいとは限りません。次を確認します。

• コメント、末尾カンマ、追加説明がなく、JSONとしてparseできる
• 必要なフィールドがそろっている
• 不明な内容は null または uncertainties に入っている
• フィールド同士が矛盾していない

この方法のきっかけになったユーザー事例には、典型的な二つの誤りがありました。冷蔵庫内の猫の写真では、冷蔵庫内が冷たい色の光、外側が暖かい光であることは見えます。しかし、その光源がLEDであるとは写真から確認できません。またWebサイトのスクリーンショットでは、見出しが左揃えだと正しく認識しながら、heroを「中央配置」と「左揃え」の両方で記述していました。前者は未確認の推測、後者は内部矛盾です。どちらも生成前に不合格にします。

手順2：固定・変更・不明を分ける

観察JSON全体をすぐ書き換えず、三つの状態に分類します。

状態	意味	例
locked	必ず維持する	被写体位置、視覚階層、縦横比
editable	意図的に変更する	商品色、背景、見出し
unknown	画像では確認できない	レンズ、照明方式、正確なフォント

観察JSONの横に制御用オブジェクトを置きます。

{
  "locked": [
    "主被写体は左下三分割付近",
    "右側に大きな余白",
    "柔らかな側面光と低めの全体コントラスト",
    "見出しは補助文の上"
  ],
  "editable": {
    "subject": "陶器のマグを透明なガラスボトルに置き換える",
    "accent_color": "くすんだ赤をコバルトブルーに変更する",
    "verbatim_text": ["NORTH", "STILL WATER"]
  },
  "unknown": [
    "カメラ機種",
    "正確な焦点距離",
    "正確なフォントファミリー",
    "画面外光源の物理方式"
  ],
  "hard_constraints": [
    "追加の文字を入れない",
    "視点を変えない",
    "参照レイアウト外に物を追加しない"
  ]
}

これにより、生成器に「維持する」「変える」「推測しない」という三つの異なる命令が伝わります。

矛盾を解消する

仕様を普通の文章として読み直します。

• 被写体は同時に中央配置と左揃えにはできない
• cropの説明は縦横比と一致しているか
• 柔らかな拡散光なのに、根拠なく硬い影を要求していないか
• 「文字なし」と「必須見出し」が共存していないか
• 同じ物体が排他的な二つの場所に書かれていないか

モデルが矛盾を適切に直してくれるとは限りません。一方をランダムに選ぶ、混ぜる、両方無視する可能性があります。

手順3：管理された最初の候補を作る

観察JSONと制御オブジェクトを生成器へ渡します。参照画像入力に対応している場合は画像も添付します。OpenAIの画像生成公式文書とGoogleの画像生成公式文書には画像入力や反復編集の方法がありますが、正確な機能は利用モデルごとに確認してください。

受け渡し用プロンプトは次のようにします。

添付した参照画像とJSON仕様を使って新しい画像を作成してください。

優先順位:
1. hard_constraintsを守る。
2. lockedのすべてを維持する。
3. editableに明記された変更だけを適用する。
4. unknownは不明のまま扱い、技術的詳細を創作しない。
5. 細部の質感より先に、構図と空間関係を合わせる。
6. 引用符内の文字は正確に1回だけ表示し、他の文字を追加しない。
7. ウォーターマーク、署名、保護されたロゴを複製しない。

画像を1枚だけ返し、プロンプトの説明はしない。

生のJSONが無視される場合は、同じ情報をラベル付き文章に変換します。

被写体:
構図:
照明:
色:
素材:
文字:
スタイル:
維持:
変更:
追加禁止:

JSONは編集用の原本であり、すべての画像モデルが共通で解釈するプロトコルではありません。

最初のbatchでは:

1. 参照画像と同じ縦横比を使う
2. seedがあれば記録するが、別モデルでも同じになるとは考えない
3. 1枚ではなく3〜4枚を生成する
4. JSON、モデル名と版、設定、参照画像、出力を保存する
5. v01-a、v01-b、v01-c のようなrun IDを付ける

成功の合図は「きれいに見える」ではありません。少なくとも1案がすべてのhard gateを通過し、最優先フィールドに重大な失敗がないことです。

手順4：参照画像と同じ基準で採点する

参照画像と出力を同じ表示サイズにし、各項目を次のように採点します。

• 0：誤り、または欠落
• 1：一部一致
• 2：用途に対して許容できる一致

項目	比較する内容
被写体	数、識別特徴、輪郭、相対サイズ
構図	位置、crop、バランス、余白、重なり
空間関係	左右、上下、前後
照明	見える方向、色温度、柔らかさ、コントラスト、影
色	主色、補助色、アクセント色と配置
素材	光沢、透明感、布、木目、毛、金属、紙
文字	正確な文、回数、綴り、揃え、階層
スタイルと雰囲気	媒体、仕上げ、処理、空気感

hard gateは次の通りです。

• 見えない事実や根拠のない主張がない
• 仕様内に矛盾がない
• 必須文字が正しい
• 重要な空間関係が維持されている
• 未指定のロゴ、ウォーターマーク、物体、文字がない

合計点は候補の並び替えに使えますが、hard gateの失敗を相殺できません。魅力的でも、見出しが間違っている、左右が反転している場合は不合格です。

大きな構造から細部へ確認する

順番は次です。

1. canvasと構図
2. 被写体の数、位置、scale
3. 照明と大きな色面
4. 素材と質感
5. 文字と細部

被写体が反対側にあるのに、毛並みだけを改善しても意味がありません。

手順5：1回に1グループだけ修正する

最良の候補を新しいbaselineにします。最大の失敗に関係するフィールドだけを変更します。

失敗	変更するもの	明示的に維持するもの
被写体が大きすぎる	compositionの位置とscale	視点、光、palette
layoutがずれる	空間関係と余白	被写体の外見、素材
暖色が強すぎる	色温度とpalette	geometryと文字
商品がプラスチックに見える	素材、highlight、反射	形、位置、label
文字が間違う	正確な文字、回数、位置	編集対応なら非文字部分
スタイルは合うが同一性が崩れる	被写体特徴または参照強度	構図と背景

「見出しだけを変更し、crop、視点、物体形状、照明、色、その他の文字を維持する」のように書きます。

公式のpromptingガイドも、変更点と維持条件を分け、1回に一つずつ調整する方法を推奨しています。これなら、どの指示が結果を変えたか判断できます。

よくある失敗と対処

有効なJSONにならない

画像を再分析させず、既存の回答だけを修復させます。

以下の内容を有効なJSONに修復してください。
画像で裏付けられた内容は維持し、新しい視覚的主張を加えないでください。
JSONだけを返してください。

JSON Schemaやstructured outputは構文エラーを減らしますが、内容の正しさまでは保証しません。

生成器がJSONを無視する

ラベル付き文章へ変換し、最後に 維持、変更、追加禁止 を置きます。重要な制約が埋もれている場合は、低優先の説明を削ります。

構図が毎回ずれる

抽象的な形容詞より、具体的な関係を加えます。

• 「被写体中心はcanvas幅のおよそ30%」
• 「見出し左端は画像の左ガイドに揃える」
• 「商品は下三分の一を占める」
• 「右半分はほぼ空ける」

座標は誘導であり保証ではないため、実際の出力を確認します。

正確な文字が崩れる

文字列を引用符で囲み、表示回数と位置を指定し、追加文字を禁止します。providerがtext-firstを推奨する場合は、先に文言を確定してから画像を生成します。法務・商品用途で完全一致が必要なら、最終的にデザインツールで組版する案も用意します。OpenAIの現行文書は文字の正確な配置と明瞭さに制約が残ると説明し、Googleも画像内文字では先にテキストを作る方法を勧めています。

同じ人物や商品が変わる

毎回ゼロから生成せず、最良の出力を次の編集入力にします。同一性、形状、labelを短く繰り返し、複数runを比較します。繰り返す人物、ブランド要素、厳密なレイアウトには変動が残ります。

画像が返る前にエラーになる

エラー内容とrequest IDを保存します。認証、quota、入力形式、moderationを先に修正してください。一時的なrate-limitまたはserver errorだけをbackoffで再試行し、ユーザー側で直せる入力エラーは内容を変えてから再送します。

合否記録を保存する

{
  "run_id": "v03-b",
  "reference_file": "reference.png",
  "analysis_json": "reference.v01.json",
  "generator_and_version": "実際の値を記録",
  "settings": {
    "aspect_ratio": "実際の値を記録",
    "quality": "実際の値を記録",
    "seed": null
  },
  "scores": {
    "subject": 2,
    "composition": 2,
    "spatial_relations": 2,
    "lighting": 1,
    "color": 2,
    "materials": 1,
    "text": 2,
    "style_and_mood": 2
  },
  "hard_gates": {
    "unsupported_claims": false,
    "contradictions": false,
    "required_text_wrong": false,
    "critical_layout_wrong": false,
    "unrequested_elements": false
  },
  "decision": "accept",
  "next_change": null
}

これにより「B案が好き」という感想を追跡可能な判断に変えられます。モデル変更が品質向上だったのか、単なるスタイル変化だったのかも見分けやすくなります。

よくある質問

元のプロンプトを正確に復元できますか

できません。見える証拠から有用な説明は作れますが、元の工程には非公開参照、seed、設定、無視された指示、複数回の編集、後処理が含まれる可能性があります。

カメラと照明には何を書きますか

見える効果を書きます。視点、透視、被写界深度、影の柔らかさ、見かけの光方向、色温度です。別の確認済み情報がない限り、正確な機材や見えない技術は断定しません。

すべての画像生成器がJSONを受け取れますか

いいえ。JSONを基準となる仕様として保存し、対象ツールが従いやすい形式へ変換します。

何回試すべきですか

まず3〜4案を作り、最良のbaselineを選び、1回に1フィールドグループを直します。すべてのhard gateを通過し、追加変更が用途を改善しなくなった時点で止めます。

類似度スコアが高ければ十分ですか

十分ではありません。誤字、左右反転、余計な物体、架空のロゴが隠れることがあります。項目別の確認が必要です。

情報源と証拠の扱い

• VoxのXスレッド：フィールド分解の発想を示したユーザー報告であり、独立したbenchmarkではありません。
• OpenAI Images and vision、image generation、image prompting：画像入力、反復編集、構造、評価、既知の制約に関する公式資料です。
• Google image understandingとimage generation：画像分析、structured JSON、参照画像生成、反復、制約に関する公式資料です。

重要なのはモデル名ではありません。観察可能な事実を一つの構造に保存し、変更を明確にし、出力を参照画像に照らして判断することです。