GPT-5.5 × Codexで画像生成しながらWebサイトを作ってみた｜Claude Codeとの違いを構造から読み解く

2026年5月28日 22:03

こんにちは、AI-Bridge LabのYOです！

OpenAIから新フラッグシップモデル「GPT-5.5」が2026年4月23日にリリースされました。本体の性能向上ももちろん注目ですが、個人的に「これは開発体験そのものを変えるかもしれない」と感じたのは、同時に大きく強化されたCodexのほうです。

なかでも、画像生成しながらコーディングができるという新しい体験は、Claude Codeを日常的に使っている自分にとってかなり衝撃的でした。

本記事ではまずGPT-5.5本体の概要を整理した上で、その中で最も実用的な進化と言えるCodexの「画像生成×コーディング統合」を、実際に動的サイトを作って実機検証します。Claude Codeとの比較は、両者のアーキテクチャとワークフローの構造的な違いに焦点を当てる形で進めます。

GPT-5.5とは何か

GPT-5.5は2026年4月23日に発表されたOpenAIの最新フラッグシップモデルで、前世代のGPT-5.4から約1ヶ月半での更新です。OpenAIはこのモデルを「コーディング、コンピュータ操作、ナレッジワーク、初期段階の科学研究で大幅に進化した」と位置づけています。

主な強化ポイントは以下の通りです。

そしてこの本体側の進化以上に、開発者の体験を変えるのが Codex側の機能拡張 です。GPT-5.5の登場と前後して、Codexには「コンピュータ操作」「アプリ内ブラウザ」「画像生成（gpt-image-2）」「メモリ」「90以上のプラグイン」といった機能が追加されました。

ではなぜCodexがClaude Codeとは異なる新しい価値を持つのか。先に結論からお伝えします。

Codex最大の価値は"画像とコードの作成がわずか一往復になること"

実機検証した結論を先にお伝えします。

Codexの「画像生成×コーディング統合」は、想像以上に実用レベルでした。動的サイト1本が単一プロンプトでほぼ完成しました。
Claude Codeで同じことをやろうとすると、外部ツールやMCP経由が必須になるため、ワークフロー上のステップ数が構造的に増えます（※本記事ではClaude Code側の実機検証は行わず、構造比較にとどめます）。
ただし、すべてのプロジェクトでCodexが優位というわけではありません。題材・規模によって使い分けが必要です。

特に、画像アセットを必要とする小〜中規模のフロントエンド開発ではCodexの優位性が際立ちました。一方で、純粋にコードロジックだけを扱うバックエンドや既存コードベースの大規模リファクタリングでは、Claude Codeを使い続ける理由は十分にあります。

それでは、なぜこの差が生まれるのか。Codexの「画像生成×コーディング統合」が具体的に何をもたらすのかを見ていきましょう。

画像生成×コーディングが変える開発の流れ

まずClaude Codeでフロントエンド開発をするときのフローを思い出してください。

LPやWebサービスを作る際、ヒーロー画像、商品画像、アイコンといった画像アセットが必要になります。Claude CodeはSVG・HTML・Mermaidなどコードベースの図表描画は得意ですが、ラスター画像（PNG・JPEG等の写真形式）の生成はネイティブには対応していません（2026年5月時点）。LPで使うようなフォトリアルなビジュアルや商品写真は、別経路で用意する必要があります。そのため実務では、

Midjourney / Stable Diffusion / ChatGPT などで画像を生成
ダウンロードしてプロジェクトのassetsフォルダに配置
Claude Codeに「この画像を使って」と指示
微調整が必要なら別ツールに戻って再生成

という外部ツール往復が発生します。MCPサーバー経由（ReplicateやHugging Face Spaces等）で擬似的に統合する方法もありますが、別途セットアップが必要でハードルが高めです。

※Claude Codeでも、SVG・HTML・Mermaidによるコードベースの図表描画は内製可能です。表中の「画像生成」はPNG/JPEG等のラスター画像を指します。

一方、GPT-5.5以降のCodexでは、同一セッション内でgpt-image-2を呼び出して画像を生成し、そのまま実装に流し込むことができます。Codexの「Skills」という仕組みに画像生成スキルが組み込まれており、コード生成の流れの中で必要な画像を自然に作成できる設計です。

この差を表で整理すると次のようになります。

なお、補足として触れておきたいのが、最近広まっているClaude CodeからMCP経由でCodex CLIをサブエージェントとして呼び出す運用です。画像生成が必要な場面だけCodexに委譲し、それ以外はClaude Codeで進めるという折衷的なワークフローもすでに実用段階にあります。本記事は「単体ツールとして使った場合」の体験差を主軸に置きますが、両者は二者択一ではなく、組み合わせる前提で考えるのが現実的です。

つまりCodexの強みは「画像を生成できること」そのものではありません。画像とコードを行き来する往復コストがほぼゼロになることです。これが開発体験を質的に変える要素になっています。

実践検証：Codexで動的サイトを作ってみた

ここからが本題です。実際にCodexで動的Webサイトを1本作ってみた結果を共有します。

検証の目的と前提

「Codexの画像生成×コーディング統合」が単発の話題機能ではなく、実用に耐える開発体験かを1プロジェクトで確認することが目的です。

題材：架空のクラフトコーヒー専門店「[ブランド名]」のランディングページ ※検証時に確定
ページ構成：ヒーロー／商品紹介／ストーリー／お問い合わせの4セクション
使用環境：Codexアプリ [バージョン] / モデル設定 [reasoning effort等] ※検証時に記入
制限：1セッションで完結させる

使用したプロンプト

初期投下したプロンプトはこちらです。

架空のクラフトコーヒー専門店「[ブランド名]」のランディングページを作成してください。

【ブランドコンセプト】
- 浅煎り中心のスペシャルティコーヒー専門店
- ターゲット：30〜40代のコーヒー愛好家
- トーン：ミニマル、温かみ、上質感
- カラーパレット：オフホワイト基調、アクセントに濃いブラウン(#3D2817)

【ページ構成】
1. ヒーローセクション（フルスクリーン背景画像、キャッチコピー、CTAボタン）
2. 商品紹介セクション（3種のシグネチャーブレンド、商品画像、風味プロフィール、ホバーで詳細表示）
3. ストーリーセクション（焙煎風景の画像、創業ストーリー）
4. お問い合わせセクション（フォーム、送信時アニメーション）

【技術要件】
- HTML / CSS / Vanilla JavaScript（フレームワーク不要）
- レスポンシブ対応（ブレークポイント：768px, 1024px）
- スムーズスクロール、Intersection Observerによるフェードイン
- 必要な画像はgpt-image-2で生成
- 画像のアスペクト比とスタイルはブランドトーンに合わせて統一

【生成順序】
全体のHTML/CSS/JS構造を生成 → 各セクション用の画像を順次生成 → 画像をHTMLに組み込み。

ポイントは「全体構造を先に作らせる → その後でセクションごとに画像を生成 → 最後に組み込み」という順序を明示したことです。これによって画像とコードの整合性が崩れにくくなります。

このような出力結果になりました。

まず画像生成スキルの手順を確認してから、静的サイトの骨組みを作ります。ブランド名は指定がプレースホルダーなので、今回は架空店名として「NAGI COFFEE」を採用して進めます。


1個のファイルを調査しました、1 件のコマンドを実行
画像生成は組み込みの image_gen を使い、生成後にワークスペース内の assets/ に移してHTMLへ参照させます。先にプレースホルダー参照つきでHTML/CSS/JSを組み、最後に実画像へ差し替える流れで進めます。

実行済みコマンド：mkdir -p assets
ここからファイルを作ります。構成は単一の index.html、styles.css、script.js に分けて、フォーム送信アニメーションとカードのホバー詳細を素直に動く形にします。

3個のファイルを作成しました
骨組みが入りました。次に、ブランドトーンを合わせた5点の画像を順番に生成して、サイト内の assets/ へ配置します。

画像はすべて生成できました。これから生成先を確認して、サイトが参照しているファイル名に合わせて assets/ へコピーします。


1件の検索を調査しました、6 件のコマンドを実行
画像を assets/ にコピーしました。次はHTMLの参照拡張子を .png に揃えて、軽く静的チェックをかけます。

1個のファイルを編集しました
ローカル確認のため、軽量なHTTPサーバーを起動してブラウザで見ます。画像読み込み、レスポンシブ、フォームアニメーションまでざっと実動確認します。

$ python3 -m http.server 4173

Traceback (most recent call last):
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 1297, in <module>
    test(
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 1252, in test
    with ServerClass(addr, HandlerClass) as httpd:
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/socketserver.py", line 452, in __init__
    self.server_bind()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 1295, in server_bind
    return super().server_bind()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 138, in server_bind
    socketserver.TCPServer.server_bind(self)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/socketserver.py", line 466, in server_bind
    self.socket.bind(self.server_address)
PermissionError: [Errno 1] Operation not permitted
Traceback (most recent call last):
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 1297, in <module>
    test(
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 1252, in test
    with ServerClass(addr, HandlerClass) as httpd:
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/socketserver.py", line 452, in __init__
    self.server_bind()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 1295, in server_bind
    return super().server_bind()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/http/server.py", line 138, in server_bind
    socketserver.TCPServer.server_bind(self)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/socketserver.py", line 466, in server_bind
    self.socket.bind(self.server_address)
PermissionError: [Errno 1] Operation not permitted

$ python3 -m http.server 4173

ここでは「1。はい」をクリックします。

「はい」を選択するとCodexはサーバー起動に進み、その直後に「Browser Use」と呼ばれるアプリ内ブラウザ機能でlocalhostへのアクセス許可を求めてきました。これは生成したページを実際にブラウザでレンダリングし、意図通り表示されているかをCodex自身が確認するための仕組みです。素材生成・コード実装に続き、動作確認までを同一エージェントで完結させようとしている動きが、ここに明確に表れています。

「許可」を選ぶと、Codexはアプリ内ブラウザでlocalhost:4173を開き、ページの動作確認を開始しました。そのまま完了かと思いきや、続けて次のような追加設定の確認が表示されました。

これは「以後はすべてのWebサイトに対するブラウザ操作を、確認なしで許可するか」を尋ねる設定確認です。プロンプト下部に「この設定はデータに対するリスクが高くなります」と警告が出ている通り、常に許可を選ぶとCodexが任意のサイトを操作できる状態になります。検証目的の今回は、安全側に倒して「毎回確認」のまま運用しました。実務でCodexを導入する際は、信頼できるドメインに限定するか、毎回確認を維持するかをチームでルール化しておくのが無難です。

単一プロンプトの投入から、index.html・styles.css・script.jsの3ファイル合計で約600行のコードが生成され、その後の調整で数行を差し戻す微修正が自動で入っています。HTML構造・全セクションのスタイリング・JavaScriptによるインタラクション（スムーズスクロール、Intersection Observerによるフェードイン、フォーム送信アニメーション）まで、一連の実装が同一セッション内で完結している点に注目してください。利用者側は途中でファイルを開いて編集する必要が一度もありませんでした。

生成結果はこちら

以上が、単一プロンプトの投入から完成までの一連の流れです。ヒーロー・商品紹介・ストーリー・お問い合わせの4セクションが、トーンの揺れなく仕上がっていることが確認できます。

特に「果実味の余韻まで、静かに澄んだ一杯を。」「焙煎は、産地の声を小さく翻訳する仕事。」といったコピーは、こちら側からは「ミニマル、温かみ、上質感」というブランドトーンしか指定していません。それに対しブランド名（NAGI COFFEE）から具体的なコピー、ブレンド名（Citrus Line / Floral Quiet / Amber Nut）まで、Codexが文脈を汲んで埋めてきています。

ソースコードはこちら

検証結果からわかったこと

今回の検証で明確になった点を、良かった点・想定外だった点・限界の3つに分けて整理します。

良かった点として最も大きかったのは「画像生成→コード実装→ローカルサーバー起動→ブラウザ確認」のループが、利用者側でツールを切り替えることなく1セッションで閉じたことです。ブランド名・コピー・ビジュアルトーンの整合性も、こちらから都度指示することなく自然に揃いました。これは「画像とコードの往復コストがゼロに近づく」という事前仮説を、ほぼそのまま実感できた結果です。

想定外だった点は、ローカルサーバー起動時にPermissionErrorが発生し、それをCodexが自分で判断して再試行・リカバリしたことです。エラーが出ても止まらず、原因を絞り込んで次の手を打つ動きは、エージェントとしての完成度の高さを感じさせる場面でした。記事の見映えだけ追うなら隠してもいい一場面ですが、実運用での信頼性に関わるポイントなのであえて残しています。

一方で限界も見えました。Browser Useや各種コマンド実行のたびに権限確認が挟まるため、純粋な作業時間に比べると体感のスピードはやや落ちます。また、生成画像のスタイル統一は今回はうまくいきましたが、ターンを跨ぐと微妙にトーンがずれる傾向もあり、長尺プロジェクトでは初期プロンプトでの統制設計が重要になりそうです。

GPT-5.5における現時点での限界・注意点

Codexの画像生成×コーディング統合は強力ですが、執筆時点（2026年5月）で押さえておくべき限界もあります。

1. セッション消費が決して軽くない
画像生成は文字通りトークンを消費します。動的サイト1本程度なら問題ありませんが、「何個も並行して作る」という使い方ではすぐに上限に到達します。今回の検証でも、画像差し戻しの回数が増えると消費が一気に進む感覚がありました。

2. 画像のスタイル統一には依然として工夫が必要
複数の画像を統一トーンで揃えるには、初期プロンプトでブランドカラー・ライティング・構図を明確に指定する必要があります。それでも完璧には揃わない場合があり、人手での再生成指示が現実的な運用になります。

3. 日本語テキスト含み画像は不安定
gpt-image-2は英語テキストの描画精度は向上していますが、日本語テキストが含まれる画像は依然として崩れやすい印象です。日本語が入る画像はCanvaやFigmaで後処理する従来のワークフローが現状ベターです。

4. 商用利用・ライセンスの確認
gpt-image-2で生成した画像の商用利用については、OpenAIの利用規約を確認した上での運用が必要です。クライアントワークで使う場合は特に事前確認を推奨します。

GPT-5.5とClaude Codeは結局どっちがおすすめ？

検証を踏まえた率直な答えは、「プロジェクトの性質によって完全に分かれる」というものです。両者は競合関係というより、得意領域が異なるツールだと考えるのが現実的だと感じました。

ユースケース別の判断軸を整理します。

画像アセットを必要とするフロントエンド開発 → Codex（GPT-5.5）

LP、ポートフォリオサイト、プロトタイプゲームなど、画像生成と実装の往復が頻発するプロジェクトでは、Codexの統合体験が圧倒的に効率的です。今回の検証でも、Claude Codeで同じことをやろうとすると外部ツールでの画像生成が必須になり、作業ステップが明らかに増えます。

バックエンド・大規模リファクタリング・既存コードベースの保守 → Claude Code

ロジック中心の開発、特に長期的に保守する大規模プロジェクトでは、Claude Codeの安定性と既存ワークフローの蓄積が活きます。画像が不要な開発で無理にCodexに移行する必要はありません。

プロトタイピング段階のスタートアップ／個人開発 → 両方を併用

アイデアを高速で形にする段階ではCodexが強く、本番運用に向けたリファクタリング段階ではClaude Codeが向きます。プロジェクトのフェーズで使い分けるのが現実的です。

さらに踏み込んだ運用としては、Claude CodeからMCP経由でCodexをサブエージェントとして呼び出す構成もあり、メインはClaude Code・画像生成が必要な場面だけCodexへ委譲するという形も実用域に入っています。

既にClaude Codeのワークフローが確立しているチーム → 当面はClaude Code継続＋必要な場面でCodex併用

チームのスキル・MCP設定・ドキュメントが整っている場合、Codexへの全面移行コストは軽くありません。画像生成が必要な特定プロジェクトでだけCodexを試してみる、というアプローチが安全です。

個人的な結論としては、Codexは「Claude Codeの代替」ではなく「Claude Codeとは別カテゴリの開発体験」です。両方を使える環境を整えておくのが、現時点での最適解だと思います。

まとめ

GPT-5.5の本体性能向上は確かに重要ですが、開発者にとっての本当の進化はCodex側の機能拡張、特に「画像とコードの一往復」を可能にした統合体験にあると感じています。Codex側のこの方向性は、今後のフロントエンド開発の標準になる可能性があります。

Claude Code派の方も、まずはこの「画像とコードの一往復」体験を一度試してみることをおすすめします。実際に手を動かして比較すると、自分のプロジェクトにとっての価値が見えてきます。

最後まで読んで頂きありがとうございました！
気に入って頂けましたら「スキ」や「フォロー」をしていただけると幸いです！ 😄
Xアカウントのフォローもぜひお願いします！

いいなと思ったら応援しよう！

皆さまの温かいサポートのおかげで、活動を続けることができています。もしよろしければ、引き続き支援をお願いできますと幸いです。より質の高い記事投稿に励みます！