なぜ Codex は「Codex Design」のような製品をまだ推出していないのか？

なぜ Codex はまだ Codex Design のような製品を推出さないのか？

Anthropic 社は最近、Claude Design をリリースしました。これはプログラミング以外で私が最も頻繁に利用するエージェントであり、何度も推奨しています。その効果は本当に素晴らしく、一言で欲しいアプリの要望を伝えるだけで、即座に対話可能なプロトタイプを生成してくれます。どこをクリックしても反応があり、よく見ないと本物のアプリを操作しているのかと錯覚してしまうほどです。

あるネットユーザーが質問しました。「なぜ Codex はまだ Codex Design のような製品を推出さないのですか？」

簡単に言えば、GPT-5.5 のモデル能力はまだこのタスクを完璧にこなすには至っていないからです。しかし、その理由を明確に説明するためには、まず重要な区別を理解する必要があります。

【1】エージェントの二層構造：モデルとハーネス

多くの人々が Codex、Claude Design と GPT-5.5、Claude Opus 4.8 を混同して語っていますが、実はこれらは全く異なる二つの層に属します。

Claude Design と Codex は「製品層」であり、業界ではハーネス（Harness）と呼ばれます。ここにはプロンプト、ツールチェーン、UI 交互フローといったエンジニアリング的な要素が含まれています。一方、Claude Opus 4.8 と GPT-5.5 は「モデル層」に属し、実際に作業を行う脳そのものです。

例えてみましょう：ハーネスは台所のようなもので、そこには鍋やフライパン（ツール）とレシピ（スキル）が揃っています。そしてモデルはその料理人です。同じ台所でも、料理人が変われば出来上がる料理は全く異なります。

この区別を理解すれば、その後の話もスムーズになります。

【2】ハーネスは参入障壁ではない

Claude Design のハーネス層における技術的難易度は高くありません。少し時間をかけて逆解析を行えば、プロンプトやツールコードのほとんどを入手可能です。実際に私も試しており、その成果物は baoyu-design（https://github.com/JimLiu/baoyu-design）で公開されています。これを利用すれば、Claude Design を他のモデル上でも実行することが可能になります。エンジニアリング面において秘密はありません。

真に差をつけるのは、その背後にあるモデルです。

【3】高精度な対話型プロトタイプ作成の難しさはモデルにある

「Claude Design」という名称は誤解を招きやすく、Figma や Photoshop のような静的なデザイン図が納品されると思われがちです。しかし実際には、Figma をさらに一歩進めた、デザイン稿とプロトタイプを融合させた高精度な対話型プロトタイプが提供されます。単にデザインを見るだけでなく、実際に操作もできるのです。

これはモデルに対して非常に高い要求を課します。

具体例を挙げましょう。X（旧 Twitter）や微博のようなクライアントアプリを作りたい場合を考えます。美しい静的なインターフェースを描画させることなら、多くのモデルで可能です。しかし、そのインターフェースを対話可能にするとなると話は複雑になります。異なるタイムラインへの切り替え、テキスト・画像・動画など様々な種類の投稿の表示、いいねボタンがハートマークに変わる動作、投稿削除時にリストから消える挙動、リストから詳細ページへ遷移して戻る操作、そしてこれらの状態を維持することまで含めなければなりません。

これらを実現するためには、モデルは UI を描画する前に、まずデータ構造とステータス管理の全体像を明確に把握している必要があります。投稿（tweet）はどのような形状か、タイムラインにはどのような種類があるか、各ボタンが現在どの状態にあるか、そしてそれらの状態間がどのように連動するかです。これはシステムアーキテクチャ設計の業務であり、単に UI を描画する作業ではありません。

Claude Design がモデルに求めるのは、優れた UI/UX デザイン能力とシステムアーキテクチャ設計能力の両方です。どちらかが欠けても効果が大幅に低下します。そのため私は以前、純粋な HTML でのデザイン稿作成に反対しました。あれは静的な UI デザインに過ぎず、UX（ユーザーエクスペリエンス）のインタラクションが融合されていないからです。

可能であれば自分でテストして体感してみてください。例えば以下のプロンプトを使います：

Design a X Client for Mac, similar to Tweetbot for Mac from Tapbots

同じプロンプトを Codex に実行させても、ある程度の成果物は得られます。見られ、簡単なインタラクションも可能です。しかし比較すれば明確な差がわかります：リストはスクロールできますが、サイドバー（sidebar）はクリックできません；いいねボタンには反応がありません。数回の反復を経てようやく、まあまあのレベルに達するのです。

Claude Design が作り出すものは全く異なります。タイムラインから通知ページへ切り替えたり、リストから詳細画面へ進んで戻ったりしても、全体が滑らかで状態も維持されます。よく見なければ、完成度の高いアプリを操作しているかと思うほどです（データはすべて模擬のものですが）。

Claude Opus 4.8 は明らかに、デザインやアーキテクチャといったシナリオにおいて大量のトレーニングと最適化を行なっています。

【4】産出品がそのままコード

Claude Design の産出品を見てみましょう。特に data.jsx ファイルに注目してください。ここでは全体のデータ構造定義が非常に明確に行われており、この構造に基づいて一連の完全な模擬データを構築し、React を用いてそのデータ上で UI を構築しています。

設計の成果物自体がコード（React、CSS、JSON）であり、Figma や PSD ではありません。どんな開発者でも手に取れば、ボタンの角丸、メインカラー、間隔などを即座に把握でき、自らの技術スタックに合わせて実装できます。後からデザイン変更があった場合も、git diff を見れば何が変わったか一目でわかります。設計と開発の間のコミュニケーションコストは最小限まで抑えられています。

厳密に言えば、設計用エージェントと開発用エージェントの間のコミュニケーションコストが低減した、というべきでしょう。現在は人がエージェントを指揮してデザインを行い、人がエージェントを指揮してコードを書くのです。

【5】Claude Design をどう活用するか

多くの人は Claude Design の活用法がわかりません。実はこれは Vibe コーディングに似ています：基本的なアイデアを持ち、まずバージョン 1 を作らせ、その後チャットでエージェントに指示を出して修正させます。数回のバージョン調整を行ううちに、自分の考えが明確になっていきます。

この調整プロセスは非常に不思議で、「言わば即座に実現される」という感覚があります。どのように変更してほしいか伝えれば、必ず実現してくれます。だからこそ私は現在、Claude Design を熱心に使い込んでいます。フィードバックの速さと爽快感がたまりません。

もう一つのコツ：あまり具体的な要求をせず、自分が目指す目標だけを伝えて、自由に任せることです。そうすると往々にしてより良い結果が得られます。なぜなら、あらゆる一般的な UI デザインについてトレーニング済みだからです。

最初の質問に戻りましょう。Codex が類似のデザイン製品を出さないのは、GPT-5.5 がまだこのタスクを担いきれていないからです。美しいインターフェースを描くことは多くのモデルで可能ですが、難易度が高いのは、実際に手を動かす前にデータ構造や状態管理、インタラクションロジックをすべて明確に整理し、一度きりで完全な対話型プロトタイプを納品することです。

現在これを達成できているのは Claude のモデルだけです。どれほど先行できるかは、OpenAI や他社が今後どのような進化速度でモデルを進化させるかにかかっています。