個人開発をしていると、README、OGP、LP、リリース告知など、画像が必要になる場面は意外と多い。
画像生成AIを使えば、それらしい一枚を作ること自体は難しくなくなった。一方で、実際に困るのはその先だ。
- 文字を置く余白がない
- ロゴやUIに見覚えのない要素が混ざる
- 16:9で作ったはずなのに、OGPにすると主役が切れる
- 修正のたびに全体の雰囲気まで変わる
要するに、「きれいな画像」と「プロダクトで使える画像」は別物だった。
この記事では、ブラウザ向けに公開されている Image3 のページを例に、生成画像をREADMEやOGPへ持っていくまでの手順を整理する。特定の“魔法の単語”を集めるのではなく、用途の定義、プロンプトの分割、失敗時の直し方、最後のリサイズまでを一つの流れとして扱う。
本稿には Image3 の紹介が含まれます。価格や機能は変更される可能性があるため、利用前に公式ページを確認してください。
先に結論
安定させるための考え方は、次の4つに絞れる。
- 「何を描くか」より先に「どこで使うか」を決める
- プロンプトを、主役・構図・背景・文字・禁止事項に分ける
- 一度に全部直さず、修正点を一つだけ指定する
- 最後はコードでサイズとファイル形式を固定する
生成モデルに完成品を丸投げするのではなく、画像生成を素材制作工程の一部として扱うのがポイントだ。
1. まず画像の仕様を決める
最初にプロンプトを書くと、つい「cinematic」「highly detailed」のような雰囲気の言葉から始めたくなる。しかし、先に決めたいのは用途だ。
今回は、個人開発したWebツールのOGP画像を想定する。
| 項目 | 仕様 |
|---|---|
| 用途 | OGP、README冒頭、リリース告知 |
| 最終サイズ | 1200 × 630 px |
| 主役 | ノートPCに表示したWebアプリ |
| 文字 | 画像生成時には入れない |
| 余白 | 左側にタイトル用の空間を残す |
| 避けたいもの | 架空ロゴ、読めない文字、過剰な小物 |
文字を後からHTMLや画像編集ツールで載せるなら、生成段階では無理に書かせないほうが扱いやすい。特にサービス名やバージョン番号は後で変わるので、背景と文字を分けておくと再利用もしやすい。
2. プロンプトを「制作指示書」として書く
短いプロンプトでも画像は出るが、用途が決まっている場合は項目を分けたほうが修正しやすい。
Create a clean hero image for a developer tool's Open Graph card.
Main subject:
A slim laptop showing a simple dark-mode web application dashboard.
The laptop must be fully visible and placed on the right half of the frame.
Composition:
Wide landscape composition.
Leave generous empty space on the left for a title added later.
Keep the main subject inside the center safe area so it will not be cropped.
Scene and lighting:
Minimal desk, soft daylight, neutral gray and deep blue color palette.
Use only one notebook and one small plant as props.
Style:
Realistic product photography, restrained contrast, natural shadows.
Text:
Add no text, letters, numbers, logos, signatures, or watermarks.
Do not:
Do not add extra screens, floating UI panels, hands, cables, or decorative icons.
ここで重要なのは、形容詞の多さではない。
- 主役をどこに置くか
- どこを空けるか
- 何を入れないか
- 何を後工程に回すか
この4点が明示されていることのほうが、実用品としては効いてくる。
Image3 には用途別のプロンプトギャラリーもある。完成したプロンプトをそのまま使うより、レイアウトの分け方や制約の書き方を拾い、自分の用途に合わせて削る使い方が向いている。
3. うまくいかないときは一か所だけ直す
生成結果が惜しいと、プロンプトを最初から書き直したくなる。しかし、全体を書き換えると、良かった部分まで変わってしまう。
例えば、構図は良いのに余計な文字だけが入った場合は、次のように修正範囲を限定する。
Keep the laptop, camera angle, lighting, background, and composition unchanged.
Remove all text-like marks and symbols from the screen and background.
Do not change anything else.
背景だけが騒がしい場合も同じだ。
Keep the laptop and its position unchanged.
Replace only the background with a plain light-gray studio wall.
Keep the empty space on the left.
「全体をもっと良くして」では、何を残すべきかが伝わらない。Keep、Replace only、Do not change の3つを使い分けると、修正の意図を分離しやすい。
参考画像を使う編集でも、順番は同じになる。
Preserve:
The product shape, color, logo position, camera angle, and proportions.
Change:
Only the background.
Improve:
Lighting and the natural contact shadow below the product.
Do not change:
The product design, labels, materials, or colors.
4. 採用基準を先に作る
画像生成は、候補を眺めているうちに判断が曖昧になりやすい。そこで、生成前に最低限のチェック項目を決めておく。
| 確認項目 | 合格条件 |
|---|---|
| 主役 | 形や色が崩れていない |
| 構図 | 1200×630に切っても主役が残る |
| 余白 | タイトルを置く場所がある |
| 文字 | 意図しない文字やロゴがない |
| 背景 | READMEやLP上で本文より目立ちすぎない |
| 権利・安全性 | 他社ロゴ、人物、誤解を招く要素がない |
全部を一度に満たそうとして大量生成するより、まず一枚だけ出して、どの項目で落ちたかを見るほうが修正しやすい。失敗の原因が分からないまま候補だけ増やすと、時間もクレジットも消費しやすい。
5. 最後のサイズ調整はコードに任せる
生成画像は、そのままリポジトリへ入れず、最終サイズと形式を固定する。Node.jsを使っているなら sharp で十分だ。
npm install --save-dev sharp
// scripts/build-og-image.mjs
import sharp from "sharp";
const input = "assets/og-source.png";
const output = "public/og-image.webp";
await sharp(input)
.resize(1200, 630, {
fit: "cover",
position: "centre",
})
.webp({ quality: 86 })
.toFile(output);
console.log(`Created: ${output}`);
node scripts/build-og-image.mjs
Next.jsなら、出力した画像をMetadata APIから指定できる。
// app/layout.tsx
import type { Metadata } from "next";
export const metadata: Metadata = {
openGraph: {
images: [
{
url: "/og-image.webp",
width: 1200,
height: 630,
alt: "Developer tool preview",
},
],
},
};
この工程をスクリプト化しておけば、元画像を差し替えてもOGPの寸法と圧縮率は変わらない。生成モデル側でピクセル単位の完成形を狙うより、役割を分けたほうが再現しやすい。
6. UIモックを作る場合の注意点
UIモックでは「おしゃれなダッシュボード」だけでは情報が足りない。画面の役割と情報量まで指定する。
Create a desktop SaaS dashboard mockup for a small deployment monitoring tool.
Layout:
- Left navigation with four items
- Top summary row with three metric cards
- Main area with one deployment table
- Right side panel with the selected deployment details
Content rules:
- Use short, realistic labels
- Keep spacing consistent
- Show only one primary action
- Do not use real company logos
- Do not add decorative charts without a clear purpose
Visual direction:
Dark mode, restrained blue accent, accessible contrast, 1440px desktop layout.
ただし、生成されたUIは実装仕様書ではない。コントラスト、キーボード操作、レスポンシブ対応、実データでの文字量は別途確認が必要だ。アイデア出しには便利でも、そのままフロントエンドへ写すと破綻することがある。
Image3を使う位置づけ
Image3 の公開ページでは、テキストからの生成、参照画像を使った編集、UIモック、商品画像、ストーリーボードなどの入口が整理されている。APIを組み込む前にプロンプトの方向性を確認したい場合や、用途別の例から制約の書き方を探したい場合に参照できる構成だ。
一方で、再現性の高いバッチ処理、独自UIへの組み込み、詳細なログやリトライ制御が必要なら、最初からAPIを使うほうがよい。OpenAIの公式ドキュメントでは、GPT Image 2は画像生成と画像編集に対応しており、Image APIとResponses APIの使い分けも案内されている。
ブラウザの生成ツールとAPIは競合するものではなく、用途が違う。
- プロンプトや構図を小さく試す: ブラウザの生成ツール
- 会話形式で何度も編集する: Responses API
- 自社サービスやバッチへ組み込む: Image API
まとめ
画像生成AIをプロダクト制作に使うとき、モデル名より先に決めるべきなのは「この画像をどこで、どう使うか」だった。
今回の流れは次の通り。
- 最終用途とサイズを決める
- 主役、構図、背景、文字、禁止事項を分けて書く
- 一枚だけ生成して採用基準で確認する
- 修正点を一つに絞る
- 最後にコードでサイズと形式を固定する
派手な一枚を偶然引くより、修正可能な工程を作るほうが、READMEやLPでは役に立つ。まずは小さな画像一枚で流れを固め、使える条件が分かってから枚数を増やすのが無理のない進め方だと思う。