同じ雰囲気で作りたいのに、毎回ちがう絵が出てくる。
サムネを3枚並べたら、3枚とも別の人が作ったように見える。前と同じ人物を出したいのに、顔が変わる。「前回と同じ感じで」と打っても、まるで通じない。
AIの画像生成を仕事で使い始めた人が、だいたい最初にぶつかる壁がこれです。
でも、これは指示文が下手だから起きているんじゃない。原因はもっと単純で、毎回ゼロから書いているからなんですよね。
しかもこの問題、OpenAI が公式に答えを出しています。画像の指示文を14の項目に分解したひな形が、そのまま公開されている。しかも用途別に11種類、編集用に8種類、記入済みの実例つきで。
渡すのはこの4つです。
・公式のひな形14項目の全文と、各項目に何を書くか
・用途を1語で指定する11種類と、編集用の8種類の一覧
・「同じ顔」「同じ絵柄」で出し続けるための公式のやり方
・そのひな形を、毎回貼らずに済ませる方法（僕が実際に動かした記録つき）
後半は実測です。参考画像を1枚渡してテンプレートを作り、そこから10ページの資料づくりまで通しました。かかった時間も、7回やり直したことも、資料づくりでImageGenを直接使ってはいけないと分かった経緯も、そのまま書きます。
先に実物を出します。これが公式の骨組みです。
公式原文（OpenAI imagegen スキルの Shared Prompt Scaffolding より）
1Use case: <taxonomy slug>2Asset type: <where the asset will be used>3Primary request: <user's main prompt>4Input images: <Image 1: role; Image 2: role> (optional)5Scene/backdrop: <environment>6Subject: <main subject>7Style/medium: <photo/illustration/3D/etc>8Composition/framing: <wide/close/top-down; placement>9Lighting/mood: <lighting + mood>10Color palette: <palette notes>11Materials/textures: <surface details>12Text (verbatim): "<exact text>"13Constraints: <must keep/must avoid>14Avoid: <negative constraints>
出典：https://github.com/openai/skills/blob/main/skills/.system/imagegen/SKILL.md
これだけ見ても「英語じゃん」で終わると思うので、ここから先で1項目ずつ日本語にして、埋め方まで落とします。最後に、そのままコピーして使える日本語版のひな形も置きます。
毎回ぶれるのは、指示文が下手だからではありません
原因は、指示の中身ではなく指示の構造にあります。
自由文で「おしゃれなブログのヘッダー画像を作って」と打つ。次の日は「シンプルでかっこいいヘッダー画像」と打つ。人間の頭のなかでは同じ注文のつもりでも、この2つは別の指示です。
前者には「おしゃれ」しか手がかりがない。後者には「シンプル」と「かっこいい」がある。指定していない部分は、AIがそのつど埋めます。埋め方が毎回ちがうから、絵が毎回ちがう。
⚡ ぶれているのはAIではなく、こちらの指示のほうなんです。
ここで効いてくるのが、さっきの14項目です。項目が決まっていれば、埋め忘れた場所が目で見てわかる。前回のファイルを開いて、変えたい行だけ書き換えれば、それ以外は前回と同じになる。
指示文を毎回「書く」のをやめて、「埋める」に変える。これが今回の話の全部です。
公式が「勝手に膨らませない」と決めている
もうひとつ、知っておくと納得が早い設計思想があります。
公式のスキル定義には、こう書かれています。
1If the prompt is already specific and detailed, preserve that specificity and only normalize/structure it. If the prompt is generic, you may add tasteful augmentation when it will materially improve the result.
出典：https://github.com/openai/skills/blob/main/skills/.system/imagegen/SKILL.md
指示が具体的なら、その具体性を保って、構造を整えるだけにする。指示がざっくりしているときだけ、結果が良くなる範囲で足していい。そう決められている。
つまり、こちらが細かく書けば書くほど、AIの裁量は減る。裁量が減れば、ぶれも減る。
逆に言うと、ふわっとした指示に対しては「気を利かせて足す」動きが公式に許可されている。良かれと思って足された部分が、毎回ちがう。ここがぶれの発生源です。
📌 だから14項目は、AIに情報を与えるためのものであると同時に、AIの自由を奪うための道具でもある。そう捉えると使い方を間違えません。
その前に：この道具、たぶんもう入っています
インストールは要りません。
imagegen は Codex に最初から入っている「システムスキル」です。ユーザーが後から追加するものではなく、起動した時点で使える状態になっている。追加の契約もAPIキーも不要です。
公式の記述では、既定の動作は組み込みの image_gen ツールを使うモードで、こうなっています。
Built-in tool (default): Does not require OPENAI_API_KEY.
APIキーが要るのは、明示的に頼んだときだけ動く CLI フォールバック（scripts/image_gen.py）のほうです。ふつうに使う分には関係ありません。
⚠️ ここで9割がつまずきます：呼び出す記号が、場所によって違う
これは知らないと最初の1行で詰まります。
公式ドキュメントの記述はこうです。
1In Codex CLI or the IDE extension, run /skills or type $ to mention a skill.
1In ChatGPT Work, use @skill-creator format.
出典：https://learn.chatgpt.com/docs/build-skills
Codex CLI とIDE拡張では $。ChatGPT Work では @。
同じ機能なのに、呼び出す記号が違う。ネットで見つけた手順が動かないときは、たいてい自分がいる画面と記事の画面が違うだけです。文法が間違っているわけじゃない。
使える場所についても公式が書いています。
1Standalone skills are available in the ChatGPT desktop app, Codex CLI, and IDE extension. Skills bundled in plugins are also available in Chat and Work across ChatGPT on the web, desktop, and mobile.
出典：https://learn.chatgpt.com/docs/build-skills
デスクトップアプリ、Codex CLI、IDE拡張。この3つが単体スキルの土俵です。
🎯 スキルが使えない人も、ひな形だけは今日から使えます
ここは大事なところで、はっきり書いておきます。
Codex もデスクトップアプリも使っていない人にとって、imagegen そのものは関係ない話です。ブラウザで ChatGPT を開いているだけなら、$ と打っても何も出てきません。
ただ、14項目のひな形のほうは、ただの文章の型です。
ブラウザの ChatGPT でも、Gemini でも、Claude でも、画像生成の入力欄にそのまま貼れる。スキルは「この型で書くのを代わりにやってくれる仕組み」であって、型そのものは誰でも使えます。
だからこの記事は、スキルが使えるかどうかで価値が変わりません。使える人は自動化として、使えない人はコピペのひな形として持ち帰ってください。
指示文のひな形、全14項目
ここからが本体です。上から順に、何を書く欄なのかを見ていきます。
項目は14個ありますが、全部埋める必要はない。埋めなかった場所はAIが補完する、という関係になっているだけです。ぶれて困っている項目だけ埋めれば足ります。
- Use case（用途）
その画像が何のジャンルなのかを、決まった1語で指定する欄です。
自由な言葉ではなく、公式が用意した語（taxonomy slug）から選びます。product-mockup、ui-mockup、logo-brand のような形式で、全部で11種類。一覧は後の章にまとめました。
ここを最初に決めると、以降の項目の埋め方が自動的に決まります。商品写真なら光の当て方が要る。図解なら文字が要る。用途が決まれば、必要な欄も決まる。
- Asset type（どこで使うか）
その画像が最終的に置かれる場所を書きます。
「ブログのヘッダー画像」「ランディングページのヒーロー背景」「ゲームのUIアイコン」。用途（1番）が大分類なら、こちらは実際の設置場所です。
同じ写真風の画像でも、ヘッダーに置くのかアイコンに置くのかで、必要な余白も縦横比も変わる。それを伝える欄です。
- Primary request（いちばん言いたいこと）
ふだん自由文で打っている「あれを作って」を、そのまま入れる欄です。
公式の説明では <user's main prompt>。つまり、この14項目は自由文を捨てるための仕組みではありません。自由文を3番の欄に置いて、その周りに条件を並べていく構造です。
ここが空だと何も始まらない。逆にここだけ埋めても、それは今までと同じ状態です。
- Input images（参照する画像）
手元の画像を渡すとき、それぞれが何の役割なのかを書く欄です。
公式の書式は <Image 1: role; Image 2: role>。「1枚目は人物写真、2枚目は服の参考」のように、番号と役割をセットで宣言します。
任意項目なので、ゼロから作るときは空のままで構いません。ただし、同じ人物を出し続けたいときはこの欄が主役になります。詳しくは編集の章で。
- Scene/backdrop（背景）
その絵が置かれる環境です。
「木目のテーブルの上」「工業用の格納庫の内部」「うっすらテクスチャの入った薄いグレー」。実在の場所でも、抽象的な背景でも構いません。
背景を書かないと、ここが毎回変わります。サムネの雰囲気がそろわない原因は、だいたいここが空欄です。
- Subject（主役）
画面の中心に何を置くかです。
「中央に1本置かれたボトル、うっすら映り込みあり」のように、物そのものだけでなく置かれ方まで書けます。
背景（5番）と主役（6番）を分けて書くのがポイントで、まとめて1文にすると、AIがどちらを優先するか判断できなくなります。
- Style/medium（画風）
写真なのか、イラストなのか、3Dなのか。
公式の記入例では「マットなイラスト」「シネマティックなコンセプトアート」「ベクター風の図解」といった粒度で書かれています。
「おしゃれ」「かっこいい」はここに入れる言葉ではありません。手法の名前を書く欄だと思ってください。
- Composition/framing（構図）
引きか寄りか、真上からか、主役をどこに置くか。
公式例には wide composition with usable negative space for page copy という書き方があります。「文字を載せるための余白を左右に残した横長構図」という意味です。
サムネやヘッダーのように、あとから文字を載せる画像では、この欄が効きます。余白を先に予約しておかないと、主役が画面いっぱいに来て文字が載らない。
- Lighting/mood（光と空気感）
朝の柔らかい光なのか、スタジオのライティングなのか、霧の中の光線なのか。
公式例では soft morning light、softbox lighting, clean highlights, controlled shadows、volumetric light rays cutting through fog といった書き方をしています。
写真っぽさを安定させたいなら、ここは毎回同じ文言を固定するのがいちばん早い。
- Color palette（配色）
使う色の方針です。
「ブランドカラー」「抑えた中間色」「深い緑とオフホワイト」。具体的な色名でも、方向性でも構いません。
ブランドの一貫性を出したい人は、ここに自分の色を書いて固定してください。これだけでも、並べたときの印象がそろいます。
- Materials/textures（素材の質感）
表面の質感です。
「マットなプラスチック、くっきり印刷されたラベル」のように、光の跳ね方に関わる情報を書きます。商品写真で効く欄で、風景やイラストでは省いて問題ありません。
- Text（画像に入れる文字）
画像の中に入れる文字を、一字一句そのまま書く欄です。
公式の書式が Text (verbatim): "<exact text>" となっているのがポイントで、verbatim は「原文のまま」という意味。要約した内容ではなく、出したい文字列そのものを引用符で囲んで渡します。
図解の公式例では、こう書かれています。
1Text (verbatim): "Bean Hopper", "Grinder", "Brew Group", "Boiler", "Water Tank", "Drip Tray"
AI画像の文字が崩れるという話はよく聞きますが、そもそも入れたい文字を正確に渡していないケースも多い。ここを埋めるだけで結果が変わることがあります。
- Constraints（守らせる条件）
「これは守れ」と「これはするな」を並べる欄です。
公式例でいちばんよく出てくるのが no text; no logos; no watermark の3点セット。文字を入れるな、ロゴを入れるな、透かしを入れるな。
あとから文字を載せる前提の画像では、この3つを毎回入れておくと事故が減ります。AIが気を利かせて英語のキャッチコピーを勝手に載せてくる、あれが止まります。
- Avoid（避けるもの）
13番が条件全般なのに対して、こちらは「出したくないもの」に絞った欄です。
グラデーション、3D、モックアップの中に置かれた状態。ロゴの公式例では no gradients; no mockups; no 3D; no watermark と書かれています。
13番と役割が重なるので、実際の公式テンプレートでは片方だけ使われていることも多い。厳密に使い分けるより、「やめてほしいことを書く場所が2つある」くらいの理解で足ります。
用途を1語で指定する。公式が用意した11種類
1番の Use case に入れる語の一覧です。公式のサンプル集には、生成用として11種類が並んでいます。
・photorealistic-natural（写実的な写真・自然な情景）
・product-mockup（商品写真・パッケージ）
・ui-mockup（画面デザインのモックアップ）
・infographic-diagram（図解・インフォグラフィック）
・scientific-educational（科学・教育向けの図）
・logo-brand（ロゴ・ブランドマーク）
・illustration-story（物語向けのイラスト）
・stylized-concept（様式化されたコンセプトアート）
・ads-marketing（広告・マーケティング素材）
・productivity-visual（資料・業務系のビジュアル）
・historical-scene（歴史的な場面）
このほかに、設置場所別のテンプレートも用意されています。Webサイト用（ヒーロー画像・セクション挿絵・ブログヘッダー）、ゲーム用（背景コンセプト・キャラクター・UIアイコン・テクスチャ）、ワイヤーフレーム（PC・価格ページ・スマホのオンボーディング）、ロゴ（抽象マーク・モノグラム・ワードマーク）。
ブログのヘッダー画像は、公式の記入例がそのまま置いてあります。
公式原文（Website assets example: blog header image）
1Use case: photorealistic-natural2Asset type: blog header image3Primary request: overhead desk scene with notebook, pen, and coffee cup4Scene/backdrop: warm wooden tabletop5Style/medium: photorealistic photo6Composition/framing: wide crop with clean room for page copy7Lighting/mood: soft morning light8Constraints: no text; no logos; no watermark
14項目のうち8項目しか埋まっていない点に注目してください。公式自身が、全部は埋めていない。必要な欄だけ埋めればいい、という実例になっています。
同じ顔、同じ絵柄で出し続ける。編集用の8種類
ここが「毎回ぶれる」への直接の答えです。
公式のサンプル集には、既存の画像を編集するための use case が8種類あります。
・text-localization（文字だけ差し替える。翻訳など）
・identity-preserve（人物の同一性を保ったまま変える）
・precise-object-edit（一部の物だけ置き換える）
・lighting-weather（光と天候だけ変える）
・style-transfer（参照画像の画風を移す）
・compositing（別の画像の被写体を合成する）
・character consistency workflow（同じキャラクターを別の場面で出す）
・sketch-to-render（下書きを本番の絵にする）
顔が変わる問題に効くのが、identity-preserve です。公式の記入例はこうなっています。
公式原文（Edit: identity-preserve）
1Use case: identity-preserve2Input images: Image 1: person photo; Image 2..N: clothing references3Primary request: replace only the clothing with the provided garments4Constraints: preserve face, body shape, pose, hair, expression, and identity; match lighting and shadows; keep the background unchanged; no accessories or text
読みどころは Constraints の行です。顔、体型、ポーズ、髪、表情、同一性を保て。光と影を合わせろ。背景は変えるな。
つまり「同じ人にして」ではなく、同じであってほしいものを名指しで列挙している。この書き方が公式の答えです。
🔥 キャラクターを何枚も出すなら、こちらの型
シリーズもののサムネや、同じ人物を何枚も出す用途なら、もう一段くわしい型があります。
公式原文（Edit: character consistency workflow）
1Use case: identity-preserve2Input images: Image 1: previous character anchor illustration3Primary request: continue the story with the same character in a new scene and action4Scene/backdrop: snowy forest after a winter storm5Subject: same young forest hero gently helping a frightened squirrel out of a fallen tree6Style/medium: same children's book watercolor illustration style as Image 17Constraints: do not redesign the character; preserve facial features, proportions, outfit, color palette, and personality; no text; no watermark
ここで使われている character anchor という言葉が肝です。基準になる1枚を「アンカー（錨）」として指定して、以降はそこからの差分だけを指示する。
Style/medium の欄が same children's book watercolor illustration style as Image 1 になっているのもポイントで、画風を言葉で説明していない。「1枚目と同じ」と参照で指定しています。
言葉で画風を再現しようとすると必ずズレる。参照で指すほうが正確です。
絵柄だけそろえたいなら style-transfer
人物ではなく、全体のトーンをそろえたい場合はこちらです。
公式原文（Edit: style-transfer）
1Use case: style-transfer2Input images: Image 1: style reference3Primary request: apply Image 1's visual style to a man riding a motorcycle on a plain white backdrop4Constraints: preserve palette, texture, and brushwork; no extra elements
配色、質感、筆致を保て。余計な要素を足すな。
気に入った1枚が手元にあるなら、それを Image 1 に置いて、あとは中身を差し替えていく。ブランドのトンマナは、この形でいちばん安定します。
そのまま使える日本語版のひな形
ここから下の2つは、公式が配布しているプロンプトそのものではありません。上で引用した公式の項目構成をもとに、日本語で埋められる形に組み直したものです。項目名は公式の英語ラベルを残してあります。
★応用（公式の項目構成をもとに作成。公式配布のプロンプトではありません）
1Use case:2Asset type:3Primary request:4Input images:5Scene/backdrop:6Subject:7Style/medium:8Composition/framing:9Lighting/mood:10Color palette:11Materials/textures:12Text (verbatim):13Constraints: no text; no logos; no watermark14Avoid:
これをテキストファイルに1枚だけ作って、置いておく。次からは、これを開いて変えたい行だけ書き換えます。
サムネ用に埋めるなら、こんな形になります。
★応用（公式の Website assets / blog header の記入例を土台に、日本語で組み直したもの）
1Use case: photorealistic-natural2Asset type: ブログ記事のヘッダー画像（横長）3Primary request: 机の上を斜め上から見た構図。ノートとペンとマグカップ4Scene/backdrop: 温かみのある木目のデスク5Subject: 中央やや左にノート、右手前にマグカップ6Style/medium: 写実的な写真7Composition/framing: 横長。右側にタイトルを載せる余白を残す8Lighting/mood: 朝の柔らかい自然光9Color palette: 木の茶色とオフホワイト中心の落ち着いた配色10Constraints: no text; no logos; no watermark
2回目からは、Primary request と Subject の2行だけ書き換える。それ以外は前回のままにする。これで「前と同じ雰囲気」がそろいます。
固定する行と、変える行を最初に決めておくのがコツです。背景・画風・光・配色の4行を固定にして、主役と構図だけ動かす。この配分がいちばん扱いやすいと思います。
ひな形を毎回貼るのが面倒なら、テンプレートごと作れます
ここから先は、僕が実際に動かした記録です。
14項目を毎回コピペするのは、正直だるい。それを解決する仕組みが Codex 側に用意されていました。入力欄に Image Gen を追加すると、テンプレートギャラリーという入れ物が出てきます。ここに自分専用のテンプレートを置いておける。
作るときは Template Creator に、こう頼みました。
★応用（実際に僕が投げた指示。公式配布のプロンプトではありません）
1Template Creator を使って、ImageGen 用の新しい画像テンプレートを作成してください。まず、テンプレートの仕組みと使い方を説明してください。次に、PNG の参考画像のアップロードを依頼し、必要ならテンプレートをいつどのように使うか私に質問してください。
投げてから27秒で返ってきました。作業をいきなり始めずに、まず2つ聞いてきたのが良かった。
1つめが「テンプレートはスライド全体のデザインに寄せたいのか、それとも挿絵や図解の生成に使いたいのか」。2つめが「主な用途は、調査レポート、セミナー資料、営業資料、SNS用カルーセルのどれに近いか」。
この2問は、そのまま設計の分岐点です。同じ「デザインを揃えたい」でも、全面ビジュアルを作るのか、余白に文字を載せる前提の絵を作るのかで、出来上がるテンプレートが変わる。ここを先に決めさせるのは理にかなっています。
⚠️ 正体は「テンプレート登録」ではなく、スキルの保存でした
ここ、僕も途中まで勘違いしていたので、はっきり書いておきます。
ImageGen の中に Canva のようなテンプレート登録の仕組みがある、わけではありません。Codex に確認したところ、実際には参考画像・配色・表現・レイアウトのルールを Codex の「スキル」として保存し、それを ImageGen から呼び出している、という仕組みでした。
スキルというのは、指示・参考素材・スクリプトなどをまとめた再利用可能なワークフローのことです。公式の説明はここにあります。
出典：https://developers.openai.com/plugins/concepts/skills.md
だから、テンプレートを作るという行為は、実質的には自分専用のスキルを1つ生やすことです。この理解に切り替えると、次の話が通ります。
作ったテンプレートの呼び出し方
完成すると、テンプレートに名前が付いてギャラリーに入ります。次からは2通りで呼べます。
・入力欄に Image Gen を追加して、ギャラリーから選ぶ
・$artifact-template- から始まるIDを直接指定する
名前でも呼べます。「（テンプレート名）のデザインで作って」と書けば通りました。
📌 つまり、14項目は「手で書く型」、テンプレートは「その型をスキルとして保存したもの」。順番としては、まず手で書いて型を掴んでから、テンプレート化するのが安全です。いきなりテンプレートを作っても、何を固定したのか自分で説明できなくなる。
資料を作るなら、ImageGenを直接使ってはいけません
ここが今回いちばん重要な発見でした。
テンプレートができたので、次は10ページの資料を作らせてみました。結果としては作れたのですが、そのあと Codex 本人に「今後はどう頼むのが正解か」を聞いたら、想定と違う答えが返ってきました。
ImageGen を直接使うのは、単発の画像制作に向いている。具体的には、挿絵を1枚作りたいとき、表紙画像だけ作りたいとき、既存画像の色や構図を直したいとき、デザイン案を試しに1枚出したいとき。
逆に、資料全体の制作には向かない。理由も明快でした。リサーチ、10ページの構成設計、ページ間の統一、PowerPointとPDF化までを一括で管理しにくいからです。
🎯 ImageGen は1枚に特化した道具。資料はスキルに任せる。この線引きを知らないまま資料を作らせると、遠回りになります。
正しい頼み方は「スキルで全体を指示して、その中でImageGenを使わせる」
役割分担はこうなっていました。
・デザインのテンプレート（自分で作ったもの）：配色、装飾、世界観を再現する
・スライド生成用のスキル：リサーチ、構成、画像生成、検証、PPTXとPDF化を担当する
・ImageGen：各ページの完成画像を実際に生成する
上の2つを指定して投げると、内部で ImageGen が呼ばれます。実際に案内された書き方がこれです。
★応用（Codex から案内された指定の形。テーマ部分は伏せて汎用化しています）
1$imagegen-slide-deck と $artifact-template-（自分のテンプレート名）を使って、「〇〇」をテーマに10ページの資料を作ってください。今回と同じデザインで、PowerPointとPDFを正式タイトルのファイル名で保存してください。
デザインの再現だけでよければ、テンプレート側だけでも足ります。
★応用（同上）
1$artifact-template-（自分のテンプレート名）を使って、「〇〇」をテーマに10ページのスライドを作ってください。内容をリサーチし、PowerPointとPDFで保存してください。
⚡ 出てくるPPTXは、文字を編集できません
これは知らないと確実に事故ります。
この方式で出てくる PowerPoint は、各ページが完成した画像になっています。つまり PowerPoint を開いても、文字を直接打ち替えることができない。
回避策はあって、依頼するときに「文字編集可能なPowerPointで」と明記すればいいとのことでした。配る前に自分で微修正したい資料なら、最初からこれを付けてください。
ファイル名にも注意が要ります。放っておくと deck.pptx のような汎用名で保存されました。「正式タイトルのファイル名で保存して」と毎回書くようにしています。
出典を発表者ノートに入れさせる
これは地味に効いたので書いておきます。
調べた出典のURLを、PowerPointの発表者ノートに入れてもらえました。後から「この記述どこから持ってきたっけ」を追えるので、人に配る資料では必須の作法だと思っています。
ファクトチェックを別途頼んだときも、根拠のURLを並べたうえで、証明されているわけではない部分と、流派や立場で解釈が分かれる部分を分けて返してきました。ここは素直に助かった部分です。
かかった時間
実測です。全部で7ラウンド回りました。
最初のテンプレート設計の相談が27秒。参考画像を渡してテンプレート本体と10ページの初版を作るまでが23分9秒。構成を組み直した2回目が13分13秒。1ページだけ直したのが11分34秒。ファクトチェックと修正で14分18秒。文言をもう一度変えて6分52秒。保存とテンプレートの確認で3分11秒。ファイル名の整理で1分10秒。
合計で1時間半くらい。ただしこれは僕が画面の前に張り付いていた時間ではなくて、投げて待っていた時間です。その間に別の作業をしていました。
7回やり直して分かった、つまずきどころ
いちばん伝えたいのはここかもしれません。1回では完成しませんでした。
7ラウンド回しています。初版が出て、構成を根本から組み直して、1ページだけ直して、ファクトチェックして、文言を変えて、保存して、ファイル名を整えた。この「1ページだけ直す」ができるのが大きくて、全部作り直しにならない。
つまずき1：初版は「並べただけ」で返ってくる
最初に出てきた10ページは、情報としては合っているのに、資料として弱かった。項目が並んでいるだけで、読んだ人が納得する流れになっていない。
そこで2回目は、注文の仕方を変えました。「こういう順番で作って」と指定するのではなく、こう投げています。
★応用（実際に僕が投げた指示の趣旨。公式配布のプロンプトではありません）
1スライドで失敗しないために、どういう構成や流れで進めていくかはお任せするので、ベストなやり方で作成をお願いします。
構成を指定せず、構成の設計そのものを任せる。これで返ってきた2回目は、各ページのフォーマットが統一され、途中に仕組みの説明が入り、後半に逆引きの早見表が足されていました。自分では思いつかなかった構成です。
細かく指示するほど良くなる、とは限らない。中身の要件は細かく、構成は任せる。この配分が良かったと思っています。
つまずき2：文字が絵の上に乗って読めなくなる
いちばん分かりやすい失敗がこれでした。ページの下に入れた注釈が、背景のイラストと重なって完全に読めない。
直し方はシンプルで、注釈をイラストの上ではなく、白いパネルの内側の最下部に移動させました。これで背景との干渉が消えます。
これ、14項目の Composition/framing で「文字を載せる余白を残せ」と指定するのと同じ話です。絵と文字が同じ場所を取り合っているという構造は、1枚の画像でも10ページの資料でも変わらない。
つまずき3：最後の1枚が弱い
資料の最終ページは、たいてい問い合わせにつなげる場所になります。ここが初版では一言だけで、あっさりしすぎていました。
直したのは、1文を3段階に分けたことです。今こういう機会があると伝える。相手の状況や困っていることを聞かせてほしいと促す。そのうえで連絡の方法を示す。
「連絡してください」だけだと、読んだ人が動く理由がない。理由と、話していい雰囲気と、方法。この3つを分けて置くだけで、最終ページの見え方が変わりました。
つまずき4：断定してはいけないことを断定してくる
これは分野を問わず効く話なので、最後に書いておきます。
初版には、言い切ってはいけない範囲まで言い切っている記述が混ざっていました。伝統的にそう言われていることと、客観的に確認できることは別なのに、同じ調子で書かれている。
なので、事実として確認できることと、そう解釈されているだけのことを、書き分けさせました。断定を避けて、その資料がどういう性質のものなのかを明記させています。
🔥 ここは人間が見るしかない部分です。AIは資料としての体裁を整えるのは得意ですが、どこまで言い切っていいかの線引きは判断してくれない。配る資料であればあるほど、ここだけは自分で読み返してください。
逆引き：困っていることから項目を探す
最後に、症状から引ける形にまとめます。
・毎回まったく違う絵になる → Scene/backdrop、Style/medium、Lighting/mood、Color palette の4行を固定する
・人の顔が毎回変わる → Use case を identity-preserve にして、Input images に基準の1枚を置く
・同じキャラを別の場面で出したい → character consistency workflow の型を使い、Style/medium を「Image 1 と同じ」で指定する
・絵柄だけそろえたい → style-transfer で、気に入った1枚を style reference に置く
・文字を載せる余白がなくなる → Composition/framing に余白の指定を書く
・頼んでいない英語の文字が入る → Constraints に no text を入れる
・画像内の文字が崩れる → Text (verbatim) に、出したい文字列をそのまま引用符で囲んで渡す
・商品写真の質感が安定しない → Materials/textures を埋める
・手順どおりに打っても反応がない → いる画面を確認する。Codex CLI とIDE拡張は $、ChatGPT Work は @
・毎回ひな形を貼るのが面倒 → Template Creator でテンプレート化して、ギャラリーから呼ぶ
・複数ページの資料を作りたい → ImageGenを直接使わず、スライド生成用のスキルとテンプレートを両方指定する
・PowerPointで文字を打ち替えられない → 依頼時に「文字編集可能なPowerPointで」と明記する
・ファイル名が deck.pptx のような汎用名になる → 「正式タイトルのファイル名で保存して」と毎回書く
・スライドのレイアウトごと揃えたい → 参考PNGだけでなく、元のPPTXも一緒に渡す
・資料の文字が絵に重なる → 文字を絵の上ではなく、白いパネルの内側に置かせる
・出てきた資料が「並べただけ」で弱い → 構成を指定せず、構成の設計そのものを任せ直す
今日やる1つ
全部を一度にやろうとすると、たぶん続きません。
まず、いちばんよく作る画像を1種類だけ決めてください。ブログのヘッダーでも、サムネでも、資料の挿絵でもいい。その1種類ぶんのひな形を、上の空欄テンプレに埋めて保存する。それだけです。
埋めるのは全14項目じゃなくていい。背景、画風、光、配色。この4行が入っていれば、次に作るときの絵はもう前回に寄ります。
テンプレート化やスライドまで進むのは、そのあとで構いません。順番を逆にすると、何を固定したのか自分で分からないまま自動化することになる。まず手で1枚埋める。使い回して、足りない行に気づく。それからテンプレートにする。
指示文を書く仕事から、指示文を埋める仕事に変える。ここが変わると、画像づくりにかかっていた時間の中身が入れ替わります。考える時間が減って、選ぶ時間が増える。
作った1枚を、来週もう一度開いてみてください。行が足りないと感じた場所が、あなたの仕事にとって必要な項目です。
参考・出典
・OpenAI 公式 imagegen スキル定義（Shared Prompt Scaffolding／既定モードとAPIキーの要否／指示の補完方針）
https://github.com/openai/skills/blob/main/skills/.system/imagegen/SKILL.md
・OpenAI 公式 imagegen サンプルプロンプト集（生成11種／編集8種／設置場所別テンプレートと記入例）
・OpenAI 公式ドキュメント「スキルの呼び出し方と利用できる場所」（$ と @ の違い／システムスキル）
https://learn.chatgpt.com/docs/build-skills
・OpenAI 公式ドキュメント「Skills」（テンプレートの実体がスキルとして保存される仕組み）
https://developers.openai.com/plugins/concepts/skills.md
・テンプレートギャラリー、Template Creator、リサーチから資料生成までの流れ、所要時間、つまずきどころは、筆者が2026年8月に実際に操作した記録です。画面の構成や名称は今後変わる可能性があります。
