Codexに画像を読み込ませるには、ChatGPTデスクトップアプリとIDE拡張ではShiftを押しながらドラッグし、CLIでは貼り付けるかcodex -i 画像 "依頼文"と指定します。ただし、画像だけでは直す場所が伝わりません。依頼文に、画像の中の対象、期待する状態、変えない範囲を書きます。この記事では、入口ごとの読み込み方、依頼文の書き方、画像に写らない条件の補い方、直した結果の確かめ方を、編集部の教材画面で説明します。

この記事は、OpenAIの公式資料に基づく解説です。参照したのはImage inputs、Prompting、Browser、Appshots、Image generationで、いずれも2026年11月3日に確認しました。教材の画面は説明のために編集部が作ったもので、製品の画面ではありません。教材の画面はWebKitで開いて要素の位置を比べましたが、依頼文をCodexへ渡す実測はしていません。修正後の教材も編集部が用意したもので、Codexが直した結果ではありません。

Codexに画像を読み込ませる方法は入口ごとにどう違うか

公式資料のImage inputsによると、読み込み方は入口ごとに少し違います。アプリとIDE拡張のShiftは見落としやすい点です。

入口読み込み方補足
デスクトップアプリShiftを押しながら入力欄へドラッグ手元の画像を調べるよう頼むことや、別のアプリでの作業をスクリーンショットのツールで確かめるよう頼むこともできる
Web版添付、貼り付け、ドラッグ何を調べて、どんな結果がほしいかを依頼文に書く
CLI入力欄へ貼り付け、または-iか--imageで指定複数の時はカンマで区切るか、--imageを繰り返す。PNGやJPEGなどに対応
IDE拡張Shiftを押しながら入力欄へドラッグShiftを押さないと、ドロップがエディター側に渡る

CLIで起動時に渡す形は次のとおりです。公式資料の例をそのまま示します。

codex -i screenshot.png "Explain this error and suggest the smallest fix"
codex --image before.png,after.png "Compare these states and list the regressions"

公式資料のPromptingには、CLIの入力欄へ画像ファイルをドラッグする手順と、IDE拡張のチャットにドラッグか貼り付けで添付する手順もあります。添付されない時は、別の方法を試してください(編集部の案内です)。

送る前に、入力欄に画像が添付されたかを見て確かめます。スクリーンショットには、メールアドレス、顧客の名前、社内のURLなどが写り込みがちです。添付の前に写っている情報を確かめ、依頼に不要な部分は切り取るか隠します(ここまで編集部の注意点です)。IDE拡張の設定全般はVS Code拡張の解説にまとめています。

この記事で扱うのは、見せたい画像をCodexに渡す方法です。画像を新しく作ったり編集したりする時はImage generationの機能を使います。Image inputsの資料も、この2つを使い分けるよう案内しています。

画像と一緒に送る依頼文には何を書くか

Image inputsの資料は、画像だけに頼らず、何を調べて何を結果としてほしいかを説明するよう案内しています。具体的には、画像に何が写っているかを言い、重要な場所を指し、出力と制約を書きます。編集部は、これを修正の依頼で使う3項目に置き換えて整理しました。

項目書くこと次の例では
対象画像の中のどの部品か。分かるなら、コードのどのファイルか赤枠の保存ボタン
期待する状態どうなれば直ったと言えるか509px以下でカードの内側に収まる
変えない範囲触ってほしくないもの510px以上の配置、文字、押した時の動作

たとえば次の左の画面では、保存ボタンがカードの右端で切れています。赤枠は、添付の前に編集部が画面に描いたものです。右の修正後は、説明のために編集部が用意しました。

教材の通知設定の画面。左は修正前で、赤枠の中の保存ボタンがカードの右端で切れている。右は修正後で、保存ボタンがキャンセルの下に移り、カードの内側に収まっている。
図:教材の通知設定の画面。左は修正前で、赤枠の中の保存ボタンがカードの右端で切れている。右は修正後で、保存ボタンがキャンセルの下に移り、カードの内側に収まっている。編集部が作った教材の画面で、製品の画面ではありません。修正後の版も編集部が用意したもので、Codexが直した結果ではありません。画像を開くと拡大できます。

この画面を直してもらう依頼文は、次のように書けます。ファイル名は説明用の例です。

添付の画像は、幅390pxで開いた通知設定の画面です。
赤枠の中の「変更内容を保存する」ボタンが、カードの右端で切れています。

対象:src/settings/notifications.css の .actions と #save
期待:幅509px以下では、保存ボタンをキャンセルの下へ置き、カードの内容の幅いっぱいにする。
変えない:幅510px以上の配置、ボタンの文字、押した時の動作、他の要素。
確認:幅390px、509px、510px、1000pxで画面を撮り直し、変更前と比べて、位置が変わった要素を報告する。
報告には、確かめた方法も書く。
対象のファイルが見当たらない時は、推測で別の場所を直さず、探した結果を報告する。

公式資料は重要な場所を指すよう案内していますが、指し方は指定していません。編集部はこの教材で赤枠を使いました。赤枠がCodexの理解にどう効くかは確かめていないので、この例でも文字で対象を書いています。509pxという境界は、2つのボタンが内容の幅に収まらなくなる幅を、教材を開いて確かめて決めました。「スマホの時」のような言い方より、数字で書くと確認の幅も決まります。

画像と一緒に書く3つの項目。対象は画像の中の部品と分かればファイル。期待する状態はどうなれば直ったと言えるか。変えない範囲は他の幅、文字、押した時の動作。
図:画像と一緒に書く3つの項目。対象は画像の中の部品と分かればファイル。期待する状態はどうなれば直ったと言えるか。変えない範囲は他の幅、文字、押した時の動作。編集部の説明図です。製品の画面ではありません。画像を開くと拡大できます。

画像に写らない条件はどう補うか

画像が伝えるのは、撮った時の見た目だけです。Promptingの資料の「スクリーンショットから試作する」節も、画像は見た目の要件を示すだけで、実装の制約は別に指定する必要があると説明しています。ホバーの状態、入力チェックの規則、キーボード操作など、画像に写らない動きは文字で書くよう案内しています。Browserの資料も、読み込み中、空、エラー、成功のどの状態の話かを名指しするよう勧めています。

教材の画面で、この差を確かめました。幅の条件を書かなかった場合に考えられる修正(保存ボタンをいつも内容の幅いっぱいにする)と、依頼文のとおりの修正を、編集部が両方作り、同じ条件で開いて位置を比べた結果です。

開いた幅幅の条件を書かない修正の例依頼文のとおりの修正
390px内容の幅に収まる内容の幅に収まる
509px内容の幅に収まる内容の幅に収まる
510px2段に変わる修正前から変わった要素なし
1000px保存ボタンが幅280pxから522pxになり、2段に変わる修正前から変わった要素なし

390pxの画像を見るだけでは、どちらの修正も正解に見えます。Codexがどちらの修正をするかを示す結果ではありません。画像に写っていない幅の見た目を、文字で決めておく必要があるという例です。比較の記録はこの教材の範囲に限ります。

依頼の前に、次の3つを分けておきます(編集部の整理です)。

区分例扱い
画像で分かるボタンが切れている、文字が重なる場所を指せば足りる
画像から推測する原因のCSS、使っているフォント、余白の正確な値コードを読んで確かめるよう頼む
画像に写らない他の画面幅、ホバー、エラー時、押した時の動作依頼文に書く

「画像から推測する」の行が特に大事です。報告に「原因はこのCSSです」と書いてあっても、コードや実際の画面を確かめた結果なのか、画像からの推測なのかを尋ねてください。先ほどの依頼文に「確かめた方法も書く」と入れたのはこのためです。

複数の画像を読み込ませる時はどう区別するか

Image inputsの資料は、画像が2枚以上ある時は、それぞれが何かを示し、どう比べるかを説明するよう案内しています。次の例はこの資料にあるものです。

Compare this checkout screen with the design. Fix spacing and typography only;
do not change behavior. Verify the result with a new screenshot.

この例には、比べる相手、直す範囲、変えないもの、確かめ方がすべて入っています。日本語で頼む時も同じ形で書けます。CLIの場合は、確かめ方を次のように変えます。理由は次の節で説明します。

codex --image design.png,current.png "1枚目はデザイン、2枚目は今の画面です。
2枚目を1枚目に合わせて、余白と文字の設定だけを直してください。動作は変えません。
直したら、確認のために開くURLと、まだ違う場所を書いてください。"

役割を文字で書くほか、ファイル名をdesign.pngのように役割が分かる名前にしておくと、報告を読む時に区別しやすくなります(編集部の整理です)。

画像で頼んだ修正の結果はどう確かめるか

直った報告を読むだけで終えず、最初の画像と同じ条件の画面を撮り直して比べます。同じ条件とは、同じ画面の幅、同じデータ、同じ操作の後のことです(編集部の整理です)。

  1. 最初の画像と同じ幅と状態で画面を開く
  2. 対象が期待する状態になったかを見る
  3. 変えない範囲に書いた幅でも開いて、配置が変わっていないかを見る
  4. 差分を読み、頼んでいないファイルが変わっていないかを見る

確認をCodexに頼めるかは、入口で変わります。公式資料のBrowserによると、デスクトップアプリではComputer Useで内蔵ブラウザーを操作し、ページを開いて、描画された状態を調べ、スクリーンショットを撮って作業の結果を確かめられます。この場合も、撮り直した画像を自分で開いて見ます。設定はComputer Useの解説と公式資料を見てください。

一方、同じ資料はBrowserをCodex CLIとIDE拡張では使えないと書いています。CLIとIDE拡張では、先ほどの依頼文の確認の行を「開発サーバーを起動して、見るURLを書く」に置き換え、自分で撮り直して比べます。Promptingの資料にも、CLIの例として同じ頼み方があります。別の撮影の手段を用意している環境なら、それを使うよう依頼文に書きます。差分の点検はコードレビューの解説を参考にしてください。

撮り直さなくて済む方法もあります。開発中のページをデスクトップアプリの内蔵ブラウザーで開けるなら、BrowserのAnnotateで要素を選んでコメントを残せます。資料は、描画した画面にだけ現れる不具合に向くとしています。別のアプリの画面を渡すなら、macOSとWindowsのデスクトップアプリで使えるAppshotsが、前面のウィンドウの画像と文字を添付の形で送ります。画面の外の文字が含まれることもあり、資料は機密の内容では避けるよう案内しています。CLIでは新しいAppshotsを作れません。

渡し方向く場面(編集部の整理)
画像の添付デザインとの比較、エラーの画面、今は開けない状態の共有
Annotate開発中のページをデスクトップアプリの内蔵ブラウザーで開けて、部品を直接指したい時
Appshots別のアプリの画面やエラーを、そのまま渡したい時

画像の依頼で起こり得る誤解と防ぎ方

次の表は編集部が想定した例で、Codexで観測した事例ではありません。原典があるのは、Shiftの行(Image inputs)だけです。

起こり得ること考えられる理由防ぎ方
エディターで画像が開いたShiftを押さずにドロップしたShiftを押しながらドラッグする
別の部品まで直った変えない範囲を書いていない変えない範囲を足して、差分を戻してもらう
別のファイルを直した画面とコードの対応を推測した対象のファイルを示す。分からなければ、探した結果を先に報告してもらう
2枚の役割を取り違えたどちらが目標かを書いていない「1枚目は目標、2枚目は今の画面」と書く
直ったと言うが直っていない画面を撮り直していない確かめた方法を報告するよう頼み、自分でも同じ幅で開く

まとめ:画像を読み込ませたら、対象と期待と変えない範囲を書く

Codexに画像を読み込ませる方法は、アプリとIDE拡張がShift+ドラッグ、CLIが貼り付けか-iです。依頼文には、画像の中の対象、期待する状態、変えない範囲を書きます。他の画面幅や押した時の動きのように画像に写らない条件は、文字で補います。直ったかどうかは、同じ条件で撮り直して確かめてください。内蔵ブラウザーで確かめられるのはデスクトップアプリで、CLIとIDE拡張では自分で撮り直します。

Codexの全体像から確かめたい場合は、Codexとは?使い方と仕事でできることを読んでください。チームでの依頼の型や確認の決まりを整理したい場合は、法人向けのご相談も受け付けています。