製品を作るのは2つの場所で最も簡単です：
設計せず、半完成品のように作られます。開発せず、設計は永遠にFigmaの中にあります。
CodexとFigmaをリンクするプロセスは次のようになります。
アイデア→要件の整理→デザインの作成·変更→実際のページの作成→ブラウザの検証→ Figmaに戻って調整を続ける
Figma MCPはすでに双方向のコラボレーションをサポートしています。CodexはFigma内のコンポーネント、変数、レイアウト、フッテージを読み取り、実行中のウェブページを編集可能なFigmaレイヤーにキャプチャし、適切な権限があればネイティブFigmaコンテンツを直接作成または変更することができます。
1年前のこと CodexとFigmaの違いは何ですか？
多くの人が考える
Codexがコードを担当Figmaがペイントを担当
実際には、彼らの分業はこのようです。
Codex：要件分析+開発実行
これはあなたを助ける：
-
曖昧な考えを整理する
-
PRDとプロジェクトコードの読み取り
-
ページ構造の分析
-
フロントエンドコードの記述と変更
-
ビルドとテストの実行
-
設計のフィードバックに基づいて調整を続ける
-
最終変更点の確認
Figma：設計とレビューワークスペース
主に以下の通り。
-
ページの構造
-
コンポーネントとバリアント
-
色、フォント、間隔の変数
-
自動レイアウト
-
インタラクションの説明
-
製品レビューとレビュー
-
複数の設計計画
両者をつなぐのは Figma MCP。
選択されたFigmaフレーム、コンポーネント、変数、レイアウト、フッテージを構造化されたコンテキストに変換し、Codexが理解して実装します。MCP自体は最終的なコードを生成するものではありません。コードリポジトリの適応、コンポーネントの再利用、開発の完了を担当するのはCodexです。
2年前のこと 始める前に、アカウントと権限を確認してください。
準備が必要です。
① ChatGPTデスクトップ上のCodexワークスペース、またはCodex CLI、Figmaアカウント、簡単なハンズオンプロジェクト、コードを保存してバックするGit、明確な要件、PRD、またはリファレンス
リモートFigma MCPは現在、異なるパッケージと座席で利用できますが、通話量が異なります。Starterユーザーや有料チームのView、Collabシートでは、読み取りツールは通常、毎月の呼び出し数が少なく、FullシートとDevシートの方が多いです。
2つの重要な機能を区別します。
-
設計情報の読み取り：Dev、Fullなどの座席は権限に応じて使用できます。
-
Canvasに書き込み、Figmaキャンバスを直接変更：フルシートが必要で、ターゲットファイルの編集権限があります。
Write to Canvasはまだベータ版で、Figmaは現在追加料金はないが、将来的には使用量に応じて課金する予定だと述べた。
3ヶ月間。 最初のステップ：Codexのインストール
インストール済みのユーザーは直接スキップできます。
macOSまたはLinux
Windows
npmも使えます：
npm install-g
macOSはHomebrew経由でもインストールできます。
brew install cask codex
インストール後の確認：
codex version
CLIを起動します。
Codex
これらのコマンドはOpen AIの現在の公式Codexリポジトリから来ています。
2026 年 7 月現在、オリジナルのCodexデスクトップエクスペリエンスはChatGPTデスクトップアプリケーションに統合されているが、Codexプロジェクト、設定、ワークフローはそのまま残っている。
4ヶ月間。 ステップ2：FigmaをCodexに接続する
ChatGPTデスクトップの最新バージョンでは、一般的にアクセスできます：
Settings → Plugins → Figma →インストール
Figmaのログインと認証が完了すると、Codexワークスペースから呼び出すことができます。
一部のバージョンまたはFigmaヘルプページには以下のエントリが表示されます。
左上のPlugins → Figmaの横の+ → Install Figma → Allow Access
これは、Codexが7 月にChatGPTデスクトップに統合された後、プラグインの管理場所が変更され、実際のインターフェイスがバージョンによって異なる可能性があるためです。
接続が成功したかどうかの確認
アクセス権のあるFigmaファイルを開きます。
フレームを選択→右クリック→選択へのリンクをコピー → Codexにリンクを送信
その後、入力：
markdownの意味
请通过 Figma MCP 读取这个设计节点。
暂时不要写代码，请告诉我：
1. 页面包含哪些模块
2. 使用了哪些颜色、字体和间距
3. 有哪些组件和变量
4. 哪些内容适合复用项目已有组件
5. 是否提供了移动端设计
无法确认的内容请明确标记，不要自行猜测。リモートFigma MCPは、ファイル全体のフロントページアドレスを提供するのではなく、できるだけ正確なフレーム、コンポーネント、バリアントを指すリンクベースで動作します。
5年ぶり。 ヒント1：アイデアからウェブサイトを構築する
入力できます。
ペット用品のウェブサイトを作ってください。
しかし、これは議論を始めるためにのみ使用でき、開発に直接入らない。
より安定したアプローチは、まずCodexにプロダクトマネージャーのように質問させることです。
この単語を直接コピーします。
markdownの意味
我想制作一个宠物用品品牌官网，但需求还不完整。
先不要设计，也不要写代码。
请向我提问，帮助我明确：
1. 目标用户是谁
2. 核心产品是什么
3. 用户进入网站后的主要目标
4. 首页需要哪些模块
5. 是否需要商品详情、购物车或支付
6. 品牌风格与参考方向
7. 手机端有哪些重点
8. 第一版必须完成什么
9. 第一版暂时不做什么
10. 最终验收标准是什么
每轮最多问5个问题。
信息不足时继续提问，不要自行编造。
确认完成后，输出：
- 产品定位
- 页面结构
- 用户流程
- 内容清单
- 设计需求
- 开发计划一言でプロジェクトを始めることができますが、方向性を決めるのは質問、確認、トレードオフです。
6ヶ月間。 CodexがFigmaで最初のデザインを作成する
最初の投稿で直接要求：
新しいFigmaファイルにフロントページを作成します。
安定性がない。
ホワイトに最適な方法は：
-
Figmaに空のデザインファイルを作成します。
-
編集権限を持つこと。
-
文書へのリンクのコピー
-
Codexをキャンバスに書き込みます。
markdownの意味
请使用 Figma MCP，在下面这个空白文件中创建首页设计：
【粘贴Figma文件链接】
要求：
1. 使用Figma原生图层
2. 使用Auto Layout
3. 建立清晰的页面层级
4. 建立颜色、字体和间距变量
5. 包含桌面端与手机端页面
6. 图片位置先使用占位区域
7. 不编造Logo和品牌素材
8. 不增加尚未确认的功能Write to Canvasでは、フレーム、コンポーネント、変数、自動レイアウトを作成できますが、フルシートとファイル編集権限が必要です。AI出力を最終設計として直接見るのではなく、Figmaで手動で確認する必要があります。
フルシートがない場合は、Codexから最初に出力できます。
-
ページの構造
-
構成部品表
-
設計基準は
-
Wireの
その後、Figmaで手動で構築するか、既存の設計を読み込んで開発します。
7年前。 ステップ2：Figmaデザインを実際のWebページに変換する
デザインが確認されたら、開発するフレームを選択し、Codexにリンクを渡します。
markdownの意味
请根据这个Figma Frame实现当前项目中的首页。
【设计要求】
1. 遵循布局、间距、颜色和字体层级
2. 优先复用项目已有组件和变量
3. 不创建重复的组件系统
4. 使用Figma提供的真实图片和图标
5. 同时适配桌面端与手机端
【工程要求】
1. 先检查项目技术栈
2. 先输出实现计划
3. 不安装没有必要的依赖
4. 不修改无关文件
5. 不添加设计稿中没有的业务功能
【验证要求】
1. 运行已有构建和测试
2. 检查文字溢出与横向滚动
3. 检查按钮、链接和交互
4. 对比页面与Figma参考
5. 输出修改文件及验证结果
无法实际验证的项目必须标记为“未验证”。Codexは、MCPが返すサンプル構造を直接コピーするのではなく、正確なノードの設計コンテキストとスクリーンショットを取得し、コードストアの既存のコンポーネント、トークン、ルーティング、データスキーマを再利用することを推奨します。
Figmaファイルが正規化されているほど、最初に生成される効果は通常安定します。
-
自動レイアウトを使用する
-
コンポーネントを全部分解しないでください
-
画層名は明瞭
-
変数またはDesign Tokenの使用
-
本物の写真とアイコンを保持
-
デスクトップとモバイルの状態を明確にする
8年ぶり。 ステップ3：スクリーンショットをオリジナル製品に変える
お気に入りのページを見つけたら、Codex分析のためにスクリーンショットをアップロードできますが、直接コピーさせないでください。
スクリーンショットに表示されないビジネスロジックやインタラクションルールは、まず私に質問してください。
markdownの意味
请分析我提供的网页截图。
不要逐像素复刻，也不要复制原网站的：
- Logo
- 品牌名称
- 文案
- 插画
- 产品图片
- 具有明显识别度的视觉资产
请只提取：
1. 信息层级
2. 页面模块
3. 配色逻辑
4. 字体层级
5. 卡片和按钮风格
6. 留白与间距
7. 图片使用方式
再结合我的产品需求，生成一套原创设计。スクリーンショットは視覚的な情報しか提供できず、AIには伝えられません。
-
ボタンをクリックするとどうなる？
-
フォームの検証方法
-
データの入手先
-
ログイン権限の制御方法
-
携帯電話メニューの展開方法
-
失敗と空の状態の表示方法
9年ぶり。 実践4：PRDを検証可能なプロトタイプに変える
PRDをCodexに渡した後、すぐにページを生成するように要求しないでください。
まず、ニーズのギャップを特定しましょう。
markdownの意味
请读取这份产品需求文档。
第一阶段只做需求分析，不要生成设计和代码。
请整理：
1. 用户角色
2. 每个角色能够执行的操作
3. 所需页面
4. 页面核心任务
5. 正常流程
6. 异常流程
7. 空状态和错误状态
8. 权限边界
9. 矛盾或模糊描述
10. 必须由我补充的问题
等待我确认后，再制作产品原型。要求を確認したら，CodexにFigma MCPでページまたはFigJamフローチャートを作成させる.
Write to Canvasを使用する場合は、フルシートと編集権限が引き続き必要です。開発シートは、キャンバスを直接変更するよりも、デザインコンテキストを読み取るのに適しています。
CLARiX 実行中のページをFigmaに戻す
これはCodex + Figmaの最も貴重な機能の1つです。
伝統的なプロセスは
Figmaの設計→開発→設計が徐々に期限切れ
これで閉ループできます。
Figmaの設計→ Codexの開発→ブラウザの実行→ Figmaをキャプチャする→レビューと調整→ Codexの再実装
コーデックスについては：
のプロジェクトのローカル开発サーバをFigma MCPのCode to Canvas機能を使用して、現在のホームページを新しいFigma Designファイルにキャプチャします。オリジナルのデザインを上書きしないでください。最初のキャプチャが完了したら、他のページステータスをキャプチャする方法を教えてください。
Code to Canvasはブラウザで実行中のページを編集可能なFigmaフレームに変換します。現在の状態は、ブラウザを初めて開くと自動的にキャプチャされます。他のページ、ポップアップ、またはエラー状態は、通常、ツールバーの“Entire screen”または“Select element”を使用してページを操作する必要があります。
独自のドラフトでキャプチャファイルを作成または編集するには、異なるシートを使用できます。ドラフト外の既存のファイルに書き込むには、フルシートと編集権限が必要です。
1万ドルです1万ドルです アプリとデータカンバンを作るには境界が必要です
Codex + Figmaは以下に最適です。
-
To Doツール
-
カードに慣れて
-
簡単な会計。
-
データカンバン
-
製品ランディングページ
-
運用バックグラウンドプロトタイプ
-
軽量ウェブアプリ
しかし、“ページを作る”ことは“成熟したアプリを作る”ことではない。
モバイルアプリには以下が必要です。
-
XcodeとAndroid SDK
-
署名と証明書
-
バックエンドサービス
-
ログインとアクセス許可
-
プッシュ通知
-
プライバシーポリシー
-
App Storeレビュー
-
長期メンテナンス
データは人の確認も必要です。
-
データインタフェース
-
インジケータ口径
-
ユーザー権限
-
データ分離
-
ページングとパフォーマンス
-
機密データの処理
1万ドルです2万ドルです 完了後は直接展開しない。
最後に、以下の段落をコーデックスに渡します。
markdownの意味
请对当前项目执行发布前检查。
先列出项目中真实存在的：
- build
- lint
- test
- 浏览器测试
- 部署脚本
然后执行可以安全运行的检查。
检查内容：
1. 构建是否成功
2. 是否存在终端或控制台错误
3. 是否存在横向滚动
4. 图片是否加载失败
5. 按钮和链接是否有效
6. 表单是否提供错误提示
7. 是否存在测试文案和占位数据
8. 是否泄露API Key或敏感信息
9. 页面是否符合Figma设计
10. 是否存在明显无障碍问题
不能实际验证的项目标记为“未验证”，
不要写成“已通过”。
不要执行正式部署、购买域名或创建付费资源。公式のレコメンデーションプロセスでは、コードを読んで完了を宣言するのではなく、実際のブラウザを使用してデザインを照合し、Playwrightのようなツールを使用してページの外観やインタラクションをチェックする必要があります。
コードの生成は、プロジェクトが最初のバージョンを持っていることを示します。検証は、製品に近づいていることを示します。
最終的な結論
Codex + Figmaを開く正しい方法は以下のとおりです。
一言→自動設計→自動開発→自動稼働
しかしながら：
① Codexの質問と明確な要件② Figmaは編集可能なデザインをホスト③ページとプロセスを手動で確認④ Codexは実際のコードを実装③ブラウザとテストツールで検証④実装結果をFigmaに送り返すレビュー ③確認後、展開
デザインできない人はFigmaに、プログラミングできない人はコードにとらわれています。
Codex + Figmaは、アイデアからプロトタイプ、実行可能なページへの障壁を本当に下げました。
しかしそれは思考コストではなく実現コストを削減します
製品の価値を決めるのは次のとおりです。
-
どんな問題を解決しましたか？
-
誰が使いたい？
-
ニーズの明確さ
-
データの信頼性
-
コードは検証済みです。
-
反復を続けたいですか？