Codex ＋ ある秘密のツールが、私たちのエージェンシーで実際に回しているデザインワークフローです…そしてその出力は、本当に別次元です。
何ヶ月も言い続けてきましたが、アプリが AI の粗製濫造に見えるなら、それは Codex の問題ではありません。ワークフローの問題です。
多くのビルダーは同じループにハマっています。AI で機能をリリースする。バックエンドは動く。ロジックはしっかりしている。でもインターフェースは、他のどのバイブコーデッドアプリとも同じに見える。ユーザーは 2 秒で、それが本物かどうかを判断します。
昔の修正方法は、デザイナーを雇うことでした。Figma ファイルを何週間も待つ。そして、開発者がそのデザインを解釈してコードに再構築するのを見守る。デザインが公開される頃には勢いは失せ、必要のないお金を燃やしていた。
そのプロセス全体が、今やオプションになりました。
このウォークスルーでは、不動産モバイルアプリのコンセプト「Haven」を構築しました。完全なデザインシステムを 20 分で。すべての画面を 1 時間以内でデザイン。CSS を一行も書き換えることなく、Codex を通じてプロダクションコードをリリース。
これが私が今回しているワークフローです。そして、AI で製品をリリースするすべてのビルダーは、これがどのように機能するかを理解する必要があります。
Moonchild の正体
秘密のツールは Moonchild です。
この 1 年でローンチされたほとんどすべての AI デザインツールをテストしてきました。最初の画面は見栄えがするものがほとんどですが、2 ページ目を構築した瞬間に崩壊します。一貫性が問題です。Moonchild は、他の何も解決できなかった方法でそれを解決します。
これは、あなたのデザインシステムから始まるチャット駆動型のデザインキャンバスです。白紙のプロンプトからではありません。スクリーンショットからでもありません。実際のシステムからです。システムは 3 つの方法で持ち込めます：
→ Figma、GitHub、またはライブ URL からインポート
→ Agentic Design System Builder にブランドを説明
→ Dribbble などからデザインインスピレーションを取り込む
そのシステムが導入されると、古い方法でデザインをプロンプトすることはありません。PRD を貼り付けます。システムに基づいて完全な画面が生成されます。そこからアートディレクションを行います。
そして、エクスポートパスがループを閉じます。Moonchild は MCP コネクタを提供し、デザインを Codex に構造化出力として直接渡します。Codex が解釈するためのスクリーンショットではありません。実際のデザインデータです。コンポーネント、トークン、レイアウト、すべて。
それがワークフローです。では、実際の使い方を説明します。
ほとんどのビルダーがデザインに AI を使う際の問題点
ほとんどのビルダーがやっていることはこれです。
Codex に新しい機能を構築するようプロンプトする。リリースされる。見た目はまあまあ。次に、次の機能をプロンプトする。少し見た目が異なる。5 つ目の機能までには、アプリは 5 つの異なる製品を継ぎ接ぎしたように見えます。
これが、人々が AI デザインはひどいと言うときの意味するところです。
モデルが悪いのではありません。ワークフローが悪いのです。
Codex はあなたのデザイン言語をまったく知りません。すべてのプロンプトは新しいコンテキストです。すべての画面は推測です。すべてのコンポーネントは前回のものからずれていきます。色がずれる。タイポグラフィがずれる。すべてが累積します。
修正方法は簡単です。Codex に従うべきシステムを与える。そして、実際のデザインを構築するためにそれを与える。
ほとんどのワークフローはどちらか一方しか与えません。Moonchild と MCP 接続は、両方を同時に与えます。
ステップ 1：まずデザインシステムを構築する。常に。
これは誰もがスキップするステップです。そして最も重要なステップでもあります。
私たちは @ignytlabs で、画面に触れる前に、すべてのクライアントにデザインシステムを構築しています。以前はデザイナーが 2 日かかっていました。Moonchild なら約 20 分です。
このウォークスルーでは、不動産モバイルアプリのコンセプト「Haven」を構築しました。Moonchild にデザインシステムを取り込む方法はいくつかあります。Figma、GitHub、またはライブ URL からインポートできます。Agentic Design System Builder にブランドを説明することもできます。Haven では、私がバイブから始めるときにいつもやることをやりました。Dribbble からのデザインインスピレーション。私が目指していた雰囲気を完璧に捉えた不動産モバイルアプリのスクリーンショット 3 枚と、Haven が何で、誰のためのものかという短い説明をドロップしました。ツールはデザイン言語を抽出し、システムをゼロから構築しました。
驚いたのは、すべてがプレビュー可能であることです。前回の記事で書いた Google Stitch ワークフローを含むほとんどの AI ツールは、フラットなトークンファイルを提供します。色。フォント。間隔くらい。これは違います。完全なコンポーネントライブラリとギャラリーを構築します。すべてのバッジ、ボタン、カード、チップが、アプリ内で実際に表示されるようにレンダリングされます。任意のコンポーネントをクリックすると、ライブで表示され、バリアントやサイズをテストするためのコントロールが表示されます。プレビューのすぐ下には、そのコンポーネントの実際の JavaScript、CSS、例、依存関係が表示されます。コードベースにすぐに取り込めます。
ギャラリーは、デザインの方法を本当に変える部分です。「ブランドバッジ」や「評価バッジ」がコンテキスト内でどのように見えるべきかを推測する代わりに、それらをすべて並べて見ることができます。売り出し中。賃貸中。注目。すべてのファミリーが一度に見えます。画面が 1 つも生成される前に、情報に基づいたデザイン決定を行えます。
スタイルシートと本物のシステムの違いです。
ステップ 2：PRD から UI へ
デザインシステムが導入されたら、古い方法でデザインをプロンプトすることはありません。
PRD を貼り付けます。
1 ページの機能概要。製品仕様書。目標ステートメント。何でも構いません。
Haven では、製品紹介、目的、ターゲットユーザーと役割、主要機能と MVP スコープ、完全なユーザージャーニー、テクニカルスタック、デザインの方向性をカバーする構造化された PRD を貼り付けました。約 1 ページ。ツールに実際のコンテキストを与えるのに十分具体的。詳細を正しい画面に引き出すのに十分構造化されています。
それから、ほとんどの人がスキップすることをしました。
画面を 1 つも生成する前に、それを使ってブレインストーミングしました。
これがほとんどのビルダーが見逃している鍵です。チャットモードは完全な PRD コンテキストを保持します。PRD をダンプして生成ボタンを押す代わりに、まず製品について話し合います。画面リストを確認します。ナビゲーションパターンを確定します。ピクセルが存在する前に、主要画面の階層を事前に定義します。
Haven では次のように質問しました：
→ 「この PRD に基づいて、最初にどの画面を構築することをお勧めしますか？ 不動産アプリとして見落としているものはありますか？」
→ 「プライマリーナビゲーションは、Home、Search、Favorites、Profile のボトムタブにするべきですか？ それとも別のものですか？」
→ 「生成する前に、Property Detail 画面の優先順位を説明してください。最初に写真、次に名前と価格、次に仕様、次にアメニティ、次にエージェント。確認するか、改善してください。」
→ 「では、現在添付しているデザインシステムに従って、これらの画面をライトモードとダークモードの両方で生成してください。完全なユーザージャーニーを完了し、すべての画面を作成してください。」
生成ボタンを押す頃には、ツールはほとんどのデザイナーが最初のクライアント電話の後よりも製品をよく理解していました。
ここで、バリアントについて簡単に注意してください。注意深く読んでください。
1 つの便利な機能：画面のさまざまなバリアントを作成できます。Moonchild に明示的に言及するだけで、あとは自動で処理してくれます。Haven では、1 つに決める前に、アプリ全体の 3 つの異なる美的方向性を試したいと思いました。使用した正確なプロンプトは次のとおりです：
「Haven のモバイル UI デザインコンセプトを 3 つ完全に生成してください：
コンセプト 1 - 温かみのあるエディトリアル：クリーム色の背景、ゆったりとした間隔、物件名にセリフ見出し、ソフトなシャドウ、雑誌スタイルの画像処理。
コンセプト 2 - 大胆なモダン：ダークモード、ハイコントラスト、全体にサンセリフ、鋭い角、写真主体で画像が端まで。
コンセプト 3 - プレミアムミニマル：ニュートラルなパレット（オフホワイト、チャコール、1 つのアクセント）、洗練されたタイポグラフィ、余白をたっぷり、さりげないマイクロインタラクション。
接続されたデザインシステムを基盤として使用しますが、各コンセプトでシステムを異なる美的方向性に引っ張ってください。セクションだけでなく、完全な画面を生成してください。どうしますか？」
最後の「どうしますか？」に注目してください。これが機能させる小さなディテールです。すべてを盲目的に生成する代わりに、ツールは計画を提示しました。
コンセプトごとに代表的な画面を 5 つ最初に作成すると言いました。私は 3 つの方向性を並べてレビューします。希望のものを選んだら、その方向性でアプリ全体をデザインします。
これにより、コスト構造が完全に変わります。3 つの完全なビルドに対して支払うのではありません。3 つのクイックサンプラーに対して支払い、実際に選んだ方向性での 1 つの完全なビルドに対してのみ支払います。
私は温かみのあるエディトリアルを選びました。画面の完全なセットが次に返ってきました。
ここで、本当に驚いた部分です。
Moonchild が生成するすべての画面は、プレビューモードでインタラクティブです。静的なモックアップではありません。実際にインタラクティブです。
入力フィールドをクリックできます。ボタンをタップできます。実際のユーザーがコードが書かれる前にプロトタイプをテストするように、画面間を移動できます。Haven では、プレビューで 2 つのフローの問題に気づきました。それらはそのまま Codex にリリースされていたでしょう。物件詳細画面には、閲覧に戻る明確な方法がありませんでした。エージェント連絡 CTA がファクトの下にありすぎました。どちらも、最初にクリックして確認せずにデザインを Codex に渡していたらリリースされていたでしょう。
これが鍵です。コードが書かれる前に製品をテストします。
洗練のループが最後のピースです。
画面に手直しが必要な場合、ゼロからプロンプトし直す必要はありません。画面を選択し、ツールに何を変更するかを伝えると、その場で v2 が生成されます。もっと映画的なヒーローが欲しい？ v2。カードレイアウトをリストビューに変更したい？ v3。バリアントが積み重なるので、比較して最も強いものを選べます。
Haven の物件詳細画面では、3 回の反復を経ました。v1 はエージェントブロックが高すぎました。v2 は階層を修正しましたが、フォトギャラリーが小さく感じられました。v3 は両方を完璧にしました。約 8 分のやりとりでした。
白紙の状態からキュレーションしているのではありません。実際の方向性を洗練しているのです。これが、シニアデザイナーと一緒に仕事をしているのに最も近い感覚です。
ステップ 3：MCP 経由で Moonchild を Codex に接続する
ここでワークフローがブッ壊れます。
デザインシステムは Codex にルールを与えます。MCP 接続は Codex にさらに強力なものを与えます。実際のデザイン出力への直接アクセス。スクリーンショットではありません。デザインのテキスト説明ではありません。Codex が読み取って再構築できる構造化されたデザインデータです。
セットアップは次のとおりです：
→ Moonchild の Settings、次に MCP に移動
→ あなたのセットアップ用のインストールコマンドをコピー
→ Codex CLI を開く
→ インストールコマンドを貼り付け
→ Moonchild アカウントで認証
→ 完了
接続されると、Codex はあなたのデザインシステムと、あなたがデザインした特定の Haven 画面の両方を認識します。
ステップ 4：Codex がコードをリリースする
では、次のように Codex にプロンプトします：
Moonchild MCP を使用して、Haven Real Estate Mobile App プロジェクトをフェッチし、内部にどの画面があるか教えてください。
この最初のプロンプトは 2 つの仕事をします。MCP が正しく配線されていることを確認します。そして、Codex にあなたがデザインしたすべての画面への完全な可視性を与えます。
Codex にそれ以上重いことをさせる前に、簡単なヒントです。プランモードのままにしてください。Codex は実行前に何をしようとしているかを表示します。毎回計画を読んでください。どの画面を、どの順序で、どの忠実度で必要としているかを Codex が理解していることを確認してください。これが、Codex が実際に必要なものをコーディングするのと、Codex が必要だと思うものをコーディングするのとの違いです。
計画を確認し、目的の画面に向けたら、Codex は Moonchild からデザインデータを直接プルし、デザインシステムを参照し、コードを記述します。プロンプトから推測する代わりに実際のデザインデータから作業するため、ホバーステート、トランジション、エッジケースの処理も追加します。
結果は次のとおりです。実際のコードベースで、デザインと完全に一致するプロダクショングレードの UI が、数分で完成します。
私たちは @ignytlabs で、クライアントの MVP ごとにデザインに 2 週間の予算を組んでいました。デザイナーが Figma ファイルを構築する。開発者がそれを解釈する。解釈がずれる。修正する。サイクル。このワークフローでは、ループ全体が 1 回の午後の作業に縮小します。同じ品質。より高いマージン。はるかに少ないコンテキストスイッチ。
このワークフローを使用するタイミング
これはすべてのチームにとって正しいワークフローではありません。いつ適合するかについて正直になりましょう。
次の場合は使用します：
→ ソロビルダーまたは小規模チームとして MVP をリリースしている
→ 画面間でデザインの一貫性が頻繁に崩れる
→ 別の Figma からデザイナー、開発者へのパイプラインを維持したくない
→ すでにデザインシステムがあり、それをどこでも適用したい
次の場合はスキップします：
→ 大規模で、完全な社内デザインチームと成熟した Figma ライブラリがある
→ すべてのシャドウが重要なマーケティングサイトやブランドワークのために、ピクセルパーフェクトなハンドオフが必要
→ コードベースに、特注のデザイン作業を必要とする高度にカスタムな UI パターンがある
MVP や SaaS 製品をリリースする 80% のビルダーにとって、このワークフローは必要なものをすべてカバーします。
注意すべき点
これを実行する前に、いくつか正直なフラグを挙げます。
デザインシステムの品質が出力品質を決定します。ゴミを入れればゴミが出ます。3 つのカラートークンしかない半端な Figma ファイルは、平凡な画面を生成します。システムに最初に時間を費やしてください。すべての画面で報われます。
PRD の品質は重要です。曖昧な概要は、一般的な画面を生み出します。ユーザーフロー、エッジケース、明確な階層を含む具体的な PRD は、有用なデザインを生み出します。これはツールの制限ではありません。思考の制限です。
それでもセンスは必要です。ツールは生成します。あなたが方向性を決めます。適切なバリアントを選び、それを洗練することが、あなたの判断力が生きる場所です。キュレーションのステップをスキップすると、バイブデザインに戻ってしまいます。
一部のコンポーネントは手動での調整が必要です。複雑なアニメーション状態、カスタムインタラクションパターン、デザインシステム外のものはすべて、Codex での手動パスが必要です。MCP は 90% まで到達させます。最後の 10% はあなたのセンスです。
これが実際に意味すること
これが私の正直な見解です。
AI で構築された製品をリリースする際のボトルネックは、コードではありませんでした。AI はコードを書けます。ボトルネックは常にデザインレイヤーでした。一貫性、センス、すべてを結びつけるシステム。
そのボトルネックはちょうど崩壊しました。
私たちのエージェンシーでは、クライアントの MVP ごとにデザインに 2 週間の予算を組んでいました。デザイナーを雇う。Figma ファイルを待つ。開発者がそれを解釈するのを見守る。サイクル。以前は 2 週間かかっていたことが、今では 2 日でできるようになりました。同じ品質。より速い納品。より高いマージン。
これが、資金のあるチームが Figma とデザイナーと開発者のパイプラインですでに持っていたワークフローです。違いは、ソロビルダー、インディーエージェンシー、小規模スタジオが、人員を増やさずに同じレバレッジを得られるようになったことです。
2026 年は、これを最初に理解したエージェンシーやビルダーにとって、アンフェアになるでしょう。
TLDR
→ 悪い UI のせいで Codex を責めるのはやめましょう。Codex が問題ではありません。あなたのワークフローが問題です。
→ ステップ 1：Moonchild 内でデザインシステムを構築します。Figma、GitHub、またはライブ URL からインポートします。またはブランドを説明します。または、Haven で行ったように Dribbble のインスピレーションを取り込みます。
→ ステップ 2：PRD を貼り付けます。生成する前にチャットモードでブレインストーミングします。まず画面リストとナビゲーションパターンを確定します。
→ デフォルトでは 1 つのバリアントが生成されます。ヒーロー画面では、異なる雰囲気を指定して複数のバリアントを明示的に要求します。
→ インタラクティブプレビューを使用して、コードが書かれる前にフローをテストします。v2、v3 の反復でその場で画面を洗練します。
→ ステップ 3：MCP 経由で Moonchild を Codex に接続します。これにより、Codex にスクリーンショットではなく実際のデザインデータが提供されます。
→ ステップ 4：MCP を使用して各画面を構築するよう Codex にプロンプトします。プロダクショングレードの UI が数分でリリースされます。
→ デザインシステムの品質が出力品質を決定します。そこに投資してください。
→ Figma からハンドオフ、開発者へのサイクルは終わりました。1 つのワークフローがデザインとコードを一緒に実行します。
LFG.
