Nano BananaとCodexの使い方｜画像から画面を作る手順
Nano Bananaで画面の見本を作り、Codexに実装を頼みたいときは、画像と文章の両方で完成条件を渡すことが大切です。Googleは2026年10月の更新としてNano Banana 2.1を案内し、文字や配置の表現改善を説明しています。画面案を試しやすくなった今、本記事では生成画像をCodexへ渡す方法と、動く画面へ仕上げる際の確認手順を整理します。
Nano BananaはGoogleの画像生成・編集モデル群、Codexはコードを扱う開発支援のためのエージェントです。両者を組み合わせる基本は、画像を生成して保存し、Codexへ参考資料として渡すことです。本記事で紹介するのはファイルを受け渡す実践方法であり、専用の接続機能を前提としません。
Codexの公式資料では、PNGやJPEGの画像入力と、画像のどこを確認してほしいかを文章で説明する方法が案内されています。画面の見本に加えて、掲載する文言、利用する技術、変更してよい範囲を渡すと、見た目の相談を実装の依頼へ変えやすくなります。
画像は色や余白を相談するのに便利ですが、クリック時の動作やスマホでの並び方までは確定しません。実装後の画面を撮影して見本と比較することを完成条件に含め、読みやすさ、入力操作、画面幅の違いを人が確認します。画像に近づける作業と、利用者が操作できる状態にする作業を両方進めることが重要です。
目次 (12)
Nano BananaとCodexは何を担当するのか
Nano Bananaで作った画像は、完成させたい画面の方向を相談するための資料として使えます。背景色、見出しの大きさ、カードの並び方、写真の位置など、文章だけでは共有しにくい要素を一枚で伝えられるのが利点です。一方、Codexへ頼むのは、既存のプロジェクトを読み、画面の構造やスタイルを変更し、ブラウザで操作できる形へ組み立てる作業です。画像を渡しただけで、ボタンの行き先や入力欄の条件が決まるわけではありません。
GoogleのNano Banana 2.1の公式モデル資料は、画像生成と会話による編集を説明し、最新の更新を2026年10月としています。文字表現や配置の精度改善が案内されているため、画面の見本を検討する材料になります。ただし、画像の品質が高くても、その画像がそのままHTMLやCSSになることを保証する資料ではありません。
OpenAIの画像入力の公式説明では、画面設計や既存素材などの画像をプロンプトに添付し、確認対象と求める結果を説明する方法が示されています。ここから、生成した画面案をCodexに渡して実装の参考にする進め方が考えられます。以下の依頼例や確認項目は、この仕様を土台にした編集部の実践提案です。
2026年10月に画像からの画面作りを試す理由
Nano Banana 2.1の公式資料では、テキストの描画や図の配置が改善点として挙げられています。画面案に見出しやカードを入れて試すとき、文字と周辺要素の関係を考える助けになります。更新を機に、文章だけでデザインを説明していた人が、画像を使った相談方法を試す価値はあります。ただし、生成画像内の日本語が必ず正しいことや、細部まで意図どおりに出ることは前提にしないでください。
また、OpenAIの公式更新履歴には、2026年10月8日のGPT-6.1 Sol Ultrafastの案内など、Codex側の更新も掲載されています。本記事の手順は、その速度設定を利用することを条件にしていません。手元で利用できる、画像入力に対応した環境を確認して進めます。新しいモデル名を選ぶことより、画像に足りない情報を補い、結果を確かめることが画面実装の質につながります。
比較の対象を固定することも大切です。途中で画像を差し替えるたびに、どの案を再現しているのかが曖昧になると、完成の判断が難しくなります。候補を複数作っても、実装へ入る段階では採用する一枚と、それに対応する文言を決めましょう。修正した案を使う場合は、変更点も文章で添えます。
画像を渡す前に完成条件を決める
依頼前に、画面の目的と掲載内容を短い文章にまとめます。たとえばイベントの案内ページなら、日時、会場、参加費、申込先を正しいテキストとして用意します。Nano Bananaが画像内へ描いた仮の文字を、そのまま正式な内容として採用する必要はありません。画像は配置の参考、文章は内容の正解として役割を分けると、Codexへ説明しやすくなります。
既存サイトを変更する場合は、対象ページ、利用中の画面部品、維持すべき動作も伝えます。見本の雰囲気だけを渡すと、既存の部品を置き換えたり、別の技術を持ち込んだりする提案になる可能性があります。「今ある構成を使う」「申込先は現在のものを維持する」「今回変更するのは案内ページの見た目」という範囲を定めれば、レビューする対象を絞れます。
スマホで何を優先するかも、画像とは別に指定します。横長の一枚には、狭い画面でカードを何列にするか、メニューをどう開くか、文章が増えたとき高さをどう変えるかが写っていません。画面幅ごとの見本が用意できなくても、「スマホでは一列」「申込ボタンを読み進めた先にも置く」などの希望を書けば、設計の判断材料になります。
画像から画面を実装する五つの手順
ここでは、既存のWebプロジェクトをCodexが参照できる状態で、画面案を一枚渡す例を紹介します。利用環境によって画像の添付位置や操作画面は異なるため、公式資料と手元の表示を確認してください。コマンドの例は読者が自分の端末で利用するための記述です。画像入力の手段と実装対象の準備を分けて考えると、画像を読めない問題と、プロジェクトを見つけられない問題を切り分けやすくなります。各段階の結果を確認してから、次の作業へ進めましょう。
Step 1: Nano Bananaで参考画像を作る
画面の用途、色、構成、参考にしたい雰囲気を伝え、一枚の画面案を作ります。最初から細かな装飾を詰め込むより、見出し、説明、カード、主要ボタンの関係が分かる画像を目指しましょう。文字が乱れていても、配置の参考として使える場合があります。採用する案を決めたら画像を保存し、表示する正式な文言を別の文章にまとめます。
Step 2: Codexへ画像を添付する
OpenAIの公式説明では、対話画面へ画像を貼り付ける方法のほか、CLIで画像ファイルを渡す方法が案内されています。PNGやJPEGなどの一般的な形式に対応し、複数の画像も指定できます。最初は一枚に絞り、ファイル名を依頼文と一致させましょう。保存したファイルを実際に開き、空の画像や別の候補になっていないことも確認します。
codex -i design.png "この画像を参考に、既存の案内ページの余白と文字サイズを調整してください"
この例のdesign.pngは、読者が保存した画像の名前に置き換えます。実装対象のプロジェクトで使用し、対象ファイルや守る条件を続けて説明してください。画像を渡せたことと、実装対象を正しく参照できていることは別の確認です。
Step 3: 文章で依頼の範囲を補う
Codexへ、参考画像のどこを再現したいか、何を維持するか、完成をどう確認するかを伝えます。「この通りに作って」だけでは、写真、文言、配置、装飾の優先順位が分かりません。既存の動作を維持したい場合は明記し、足りない情報があれば編集前に確認してもらう条件を加えます。画像内の仮の文章を使わないことも依頼文に含めます。
添付画像は案内ページの配置見本です。既存の画面部品を使い、背景色、カードの余白、見出しの大きさを近づけてください。掲載文言はこのメッセージの内容を使います。申込ボタンの行き先と入力処理は維持してください。スマホではカードを一列にし、文字の重なりがない状態を目指してください。編集後に変更点と確認結果を報告してください。
Step 4: 実装した画面を見本と比べる
変更後の画面をブラウザで開き、スクリーンショットを撮って参考画像と比べます。まず見出し、主要ボタン、カードの順序など、大きな構成を見ます。その後に文字サイズや余白を調整すると、細部の修正を繰り返しすぎずに済みます。Codexへ比較を頼む場合は、どちらが見本でどちらが実装後か、名前を付けて明確に伝えます。
codex --image design.png,result.png "design.pngは見本、result.pngは実装後です。余白と文字サイズの差を挙げ、修正案を説明してください"
公式資料では、複数画像のパスをカンマで区切る方法と、--imageを繰り返す方法が案内されています。比較結果は提案として読み、意図した変更を満たしているかを確認してから修正を進めます。
Step 5: 操作とスマホ表示を確認する
画像に似ていても、実際に使いやすいとは限りません。スマホ幅で文字が切れないか、長い見出しが折り返せるか、ボタンを押すと正しい場所へ移動するかを確認します。キーボードで入力欄やボタンへ移れることも確かめましょう。問題があれば、その画面と再現条件を渡し、見た目の修正で起きた不具合なのかをCodexに調べてもらいます。
画像に近づけるときに起きやすい問題
よくあるのは、見本の比率を優先して文字を小さくしすぎることです。画像では整って見えても、実際のスマホでは読むのが難しくなる場合があります。文字量や画面幅が変わったときに崩れないことを優先し、画像に含まれる改行位置を無理に固定しないよう依頼します。文章の読みやすさを理由に見本から調整する箇所は、変更理由も説明してもらうと判断しやすくなります。
別の問題は、素材と画面全体の見本を混同することです。生成した一枚をページの背景として置くだけでは、見出しやボタンが画像の一部になり、文字の選択や操作が難しくなります。装飾画像として使う部分と、HTMLのテキストや操作部品として作る部分を決めましょう。商品写真などの素材を使う場合も、何の画像か、代替テキストが必要かを文章で伝えます。
Codexが画像の細部を読み違えることも想定します。重要な色や間隔があるなら値を指定し、写真の位置だけを参考にしてほしいならそのように書きます。一回の依頼で全体を変えるより、「カードの間隔」「見出しと説明文の距離」のように対象を絞って再依頼すると、変更と結果の関係が追いやすくなります。数値が決まっていない箇所は、提案を見て選ぶ形でも構いません。
料金やモデル名は別々に確認する
Nano Bananaで画像を作る利用と、Codexでコードを変更する利用は、別のサービスの操作です。一方の契約で両方を使えるとは考えず、それぞれの利用画面や公式案内を確認します。Nano Bananaという呼び名だけで、選択中のモデルや提供条件を判断しないことも大切です。Googleのモデル資料はモデルコードを掲載しているため、利用画面に表示された名前と照合できます。
Codex側も、選べるモデルや画像を渡せる入口を手元で確認します。更新履歴に新しい機能が載っていても、すべての契約や利用環境で同じ条件になるとは限りません。本記事では価格や利用回数を固定値として案内せず、画像を受け渡して実装する考え方に絞っています。APIから画像生成を呼び出す構成を作る場合は、今回の手動の受け渡しとは別に、提供仕様と費用を確認する必要があります。
完成の基準は画像の一致と操作の両方に置く
Nano BananaとCodexを組み合わせると、見た目の候補を画像で相談し、その意図をコードの変更へつなげる進め方が取れます。成功の鍵は、画像だけに完成条件を任せず、正しい文言、守る動作、スマホでの構成を文章で渡すことです。生成画像が魅力的でも、実装後の画面を確認する時間は省けません。見本との比較と、実際の操作を同じ完成条件に含めましょう。
最初の題材は、既存ページの一部分や小さな案内画面が扱いやすいでしょう。採用画像を一枚に決め、変更範囲を絞り、結果の画像を見て修正する流れを試します。これにより、どの情報を文章で補うべきかが分かります。画面案、掲載文言、実装後の確認結果をそろえて残せば、次の修正でも意図を伝えやすくなり、画像を使った開発相談を継続できます。
