Codex がインターフェースを書くのに失敗したあと、ChatGPT に UI を描かせる

Codex を使ってコードを改善するのは、今回が初めてではありません。バックエンドのロジック、API 連携、テスト修正、レポート生成といったタスクは、ふだんからそのままゴールだけ放り込んで、ファイルを読ませ、コードを修正させ、検証を走らせ、コミットさせています。問題になったのはフロントエンドのリファクタリングです。今回は UI のデザイン案を先に作らず、しかも事前に業務の土台を先に組み上げてしまいました。一度でも旧 UI が存在すると、モデルに見えるのは要件だけではありません。既存のコンポーネント、既存のルーティング、既存のスタイル、そしていくつかの歴史的な慣性までもが見える状態になります。

私の最初の反応もとても普通でした：プロンプトを追加し続ける。破壊的な再構成を許可し、UIとインタラクションのロジックを再設計し、要素を詰め込みすぎず、24インチと32インチのモニターに対応し、コア機能に焦点を絞り、保守的にならない。一つ一つの文は単体で見ればどれも正しいのですが、全部合わせてもまだ何かが足りません：最終的に一体どうあるべきか、ということです。

つまずくのはボタンの色ではない

strategy_studio はボタンが 2、3 個しかない小さなツールではありません。README では、すでに中国語を優先した戦略研究プラットフォームとして位置付けられています。Next.js のフロントエンド、FastAPI の API、PostgreSQL、Worker、Scheduler、Yahoo 同期パイプラインが一緒に動作します。さらにフロントエンドの README は、ページを 1 つのリサーチワークベンチへと集約しています。サンプル準備、実験構成、タスク追跡、結果レビュー、テンプレート管理、そしてレポート詳細と運用・保守のエントリポイントです。

このプロジェクトにおけるフロントエンドの問題は、表面上は「十分に美しくない」というものですが、実際には情報の秩序が定まっていないことにあります。ユーザーはまず相場を見るのか、それともまずバックテストのタスクを見るのか。レポートの詳細画面では、曲線、指標、入力パラメータ、再実行ボタンのうちどれがより重要なのか。トップページはナビゲーションのページなのか、それともワークスペースなのか。大画面では要素を隙間なく敷き詰めるのか、それとも余白を持たせるのか。

これらの判断は文章だけで説明されているため、Codex は「既存ページの中で少し最適化する」という解釈を容易にしてしまいます。コンポーネントの変更、余白の調整、色の変更などを行いますが、それでも古い構造に沿って作業を進めます。破壊的なリファクタリングを許可するだけでは不十分です。なぜなら、破壊的なリファクタリングが解決するのは「コードを大幅に変更できるかどうか」という問題であり、「検証可能なビジュアル目標が存在するかどうか」という問題ではないからです。

日中に一度出かけたのですが、夜になって急に思いつきました。Codex に UI を推測させるのはやめよう。まずは ChatGPT の Web 上で UI デザイン案を描き出して、その画像を Codex に渡して再現させよう。

当時使っていたプロンプトはとても直接的でした：

https://github.com/ttf248/strategy_studio 現在のプロジェクトのフロントエンドコードを分析し、業務ロジックを理解した上で、プロのUIデザイナー・インタラクションデザイナーとして、フロントエンドページを設計し直してください。各ページごとに個別に画像を作成し、24インチ・32インチのディスプレイに対応させ、要素を必要以上に詰め込みすぎず、ユーザーが中核機能に集中して使いやすいようにしてください。

このステップで出た効果は、Codex で形容詞を積み重ね続けるよりもずっと安定している。Codex にはまず可視的な目標が与えられる。ページをどう並べるか、モジュール比率をどう分けるか、ビジュアルセンターの配置、余白のおおよその目安といったものだ。その後の Codex が取り組むタスクは、「審美眼を頼りに再設計する」ことから「図に基づいて業務を理解しコードを復元する」へと変わる。

配色も先に素材にしよう

初稿の図でレイアウトの問題は解決しましたが、デフォルトの配色が依然として通常のバックエンドシステムらしい青と白であり、私の美的感覚にはあまり合っていません。ここで「青と白が好きじゃない、もっと落ち着いた配色にして」とそのまま Codex に投げてしまうと、本質的にはまた推測させることになります。

これが最初の青と白のカラーリングバージョンです。ページ構造を示すことはできていますが、まだ普通の管理画面の雰囲気です。

その後、私はやり方を変えました。まず ChatGPT のウェブ版で配色の方向性について話し合い、ベースカラー、アクセントカラー、カードの階層、そして研究ツールらしい雰囲気について明確に伝えました。その上で、画像モデルにその方向性に従って意図を示してもらいました。これは正式な Figma ではなく、完全なデザインシステムでもありませんが、フロントエンドの再構築で最もずれやすい要素を固定するには十分です。

最終的に手にしたのは「大きく網羅した1枚のホームページ」ではなく、ページごとに分かれたデザイン原稿です。ホームページ、行情研究、バックテスト実験、レポートセンター、レポート詳細、ストラテジーテンプレート、運行保守。 この分割方法が非常に重要 です。strategy_studio のフロントエンドはマーケティングページではなく研究ツールです。ホームページ、行情ページ、レポート詳細ページが担う閲覧タスクはそれぞれ異なるため、すべてを同じカードグリッドに詰め込むことはできません。

図が描けたことで、Codexの役割が明確になります。CodexはゼロからUIデザイナーを務めるのではなく、既存のビジネスロジックを読み、コンポーネントを分解し、レイアウトを調整し、インタラクション状態を揃え、lint/buildを実行し、そして旧フロントエンドを設計稿に近い目標状態にリファクタリングします。

単なる「ウェブ版の方が賢い」ではない

その後、公式資料をもう少し調べてみたが、この件を「異なるチャネルの ChatGPT の知能レベルが異なる」や「Codex を直接使用すると機能が制限される」と解釈できるかどうかを確認したかった。この説明はあまりにも粗い。

OpenAI による Codex CLI の説明は、ローカルのターミナルで動作する coding agent に関するものです。現在のディレクトリにあるコードを読んだり、変更したり、コマンドを実行したりできます。Codex web は、クラウド環境でコードタスクを処理します。OpenAI が Codex agent loop について語るとき、重視しているのは「モデルがすべてを凭空に生み出す」ことではなく、モデルの推論、文脈管理、ツール呼び出し、ファイルの読み書き、コマンド実行が一体となってソフトウェアタスクを構成するという点です。

ChatGPT Images は別のエントリーポイントです。OpenAI Help における Images in ChatGPT の説明によると、ユーザーは会話内で画像を作成および編集したり、モックアップやクリエイティブなビジュアルを作成したりできます。この製品の形態は、納品物がコードではなく画像であるため、ビジュアル目標をまず探索するのに本質的により適しています。

したがって、今回の違いは「どちらがより賢いか」ではなく、タスクの形態が異なるという点にあります。「UIの再設計」を直接 Codex に任せると、コードリポジトリの視点で考えます。どのファイルを修正すべきか、どのコンポーネントを壊してはいけないか、どうすればビルドを通すことができるかを考えます。同じビジネスコンテキストをまず ChatGPT Images に渡すと、抽象的な美的感覚と情報の階層をまず見える目標画像に圧縮します。

これはまた、後になって Codex がむしろ使いやすくなる理由を説明している。設計ドキュメントが Codex を回避したのではなく、設計ドキュメントが Codex にコンテキストと受け入れ基準を補完したのである。公式の Codex prompting ドキュメントも、Codex に関連ファイル、画像、明確な完了基準を提供することを強調している。図がない場合、「要素を密集させすぎないでください」は単なる形容詞に過ぎないが、図があって初めて、それは再現可能なレイアウト制約となる。

よりスムーズなリンク

これ以降は、この種フロントエンドのリファクタリングを3つのパートに分割することにします。

第一段階は、まずビジュアル探索から始めます。ChatGPT の Web 版にリポジトリを読ませ、業務を理解させ、ページごとに画像を生成させ、色使い、密度、大画面対応、ビジュアル階層といった点を中心に繰り返し調整します。この段階で生み出される成果物はコードではなく、目標となる画像です。

第二段階では、目標画像とエンジニアリング上の制約を Codex に渡します。プロンプトは「UI を再設計してください」で止めてはいけません。代わりに、どの画像を目標とするか、どのビジネスロジックを壊してはならないか、どのページが破壊的な再構築を許可されているか、どのテストとビルドが通らなければならないかを明確に記述する必要があります。

第三段落ではエンジニアリングによる復元に入ります。ここで初めて Codex にゴールモードや連続タスクモードを使わせるのに適しています。まずフロントエンドの構造を読み取り、次にページごとに分割して実装します。各ページが完了したら検証を実行し、最後にインタラクションとレスポンシブ対応を一括して確認します。

以前は「プロンプトをもっと強く書くこと」を解決策だと考えがちでした。今振り返ると、フロントエンドのリファクタリングにおいて本当に有効なのは強引さではなく、不足している中間成果物を補うことだと分かります。UI デザインがない場合、破壊的なリファクタリングは単に分解を広げるだけに過ぎません。UI デザインがあって初めて、破壊的なリファクタリングには正しい方向性が生まれます。

このフローは strategy_studio にしか使えないわけではない。すでにビジネスロジックはあるものの、フロントエンドをずっと後付けで継ぎ足してきたような個人プロジェクトなら、どれでも同じ要領で進められる。まず画像モデルに UI のゴールを描かせ、次に Codex にそのゴールをコードに変換させる。各モデルが互いに代替し合うのではなく、それぞれ得意な工程を担当するという形だ。

参考資料

• ttf248/strategy_studio GitHub リポジトリ
• Strategy Studio README
• Strategy Studio Frontend README
• Strategy Studio UI デザイン原稿ディレクトリ
• OpenAI Help：Images in ChatGPT
• OpenAI Help：ChatGPT Capabilities Overview
• OpenAI Developers：Codex CLI
• OpenAI Developers：Codex web
• OpenAI Developers：Codex prompting
• OpenAI：Unrolling the Codex agent loop