👋
Figma MCPを使った静的Webサイト作成の自動化を検証する
まとめ
- 作業ログを全載せしていて、とても長い記事なので、最初に結論だけ書く
- 結論
- 簡易なデザインは、適切なFigmaファイルを用意すれば、ほぼ自動化できる
- 複雑なデザインもCode Connectと開発用のアノテーションを活用することで実現できそう(未検証)
- Figma(デザイン)について
- デザイナーが丁寧にFigmaファイルを作るほど、Codingの精度が上がる
- コンポーネント化 / 再利用設計を徹底する
- デザイントークン(変数)の利用を徹底する
- レイヤー命名をセマンティックなものにする
- オートレイアウトを用いて、デザイン時点でレスポンシブにする
- Code Connectの活用（適切にコードを置き換えてくれる）
- アノテーション(各アニメーション/デザイン意図)をデザインファイルに記載する（コメント・説明レイヤー）
- https://help.figma.com/hc/ja/articles/32132100833559-Dev-Mode-MCPサーバー利用ガイド
- https://developers.figma.com/docs/figma-mcp-server/structure-figma-file/
- デザイナーが丁寧にFigmaファイルを作るほど、Codingの精度が上がる
- Codex or Claude Code(実装)について
- アーキテクチャ、命名規則等はプロンプトで指定する
- Context Windowが埋まらないワークフローになるよう、タスク分割に気をつける
- デザイン情報の取得にはFigma Dev Mode MCPを使う
- MCPの使い方について、プロンプトで制御すると更に品質があがる
- 各セクションURLをまとめたファイルがあると、効率的にコンテキストを拾ってくれる
- 実装したコードの視覚レビューにもMCPを使う、(puppeteer MCP|chrome-devtools MCP|playwright MCP)
- 今回のケースでは、chrome-devtools MCP + Claude Code(Sonnet-4.5)の組み合わせが安定していた
- 総括
- 基本的にはどんなプロジェクトでも、Figma MCPの利用で実装の効率化は約束される
- ただし、求めるUI・UXが複雑度が上がるほど、多くのコンテキストを伝える必要がある
- 多くのコンテキストを置く場所はFigma側(Figma Code Connect,アノテーション)でも、Codex,Claude Code側(AGENTS.md,CLAUDE.md)でもどっちでもいいので、メンバーのスキルに合わせて最適化すればいい
今回使ったAGENTS.mdやプロンプトは下記に置いた
きっかけ
- Figma MCPはリリース当初に触ったが、GPT-5(Codex)・Sonnet-4.5(Claude Code)が発表されてから、試していなかったので、品質を調べたい
- Next.js + TailwindのようなすぐにVercelにデプロイ可能な構成ではなく、SSRなどの機能は使わず、どこのWebサーバーでも静的ファイルとしてデプロイできる構成でVibe Codingしたい
- コーダー自身がエージェントに任せるタスク粒度をきめるのではなく、なるべくCodex or Claude Codeが自走するワークフローを考えてみたい
仮説
- モデルのContext Window Sizeやモデルの性能が高くなっているので、ある程度大きなSetion単位で実装させても精度が出るのではないか？
- FigmaのMCP Serverの性能が上がっているので、以前より精度高く実装できるのではないか
- Figma側のデザイントークンやコンポーネントが設定されていなくとも、LLM側でよしなに設計して精度の高いWebサイトを作ってくれるのではないか
前提条件
- Figmaファイルを最適化しすぎない（完璧なコンポーネント化、命名規則の徹底、デザイントークンの徹底、Code Connectの活用等はやらない）
- 静的Webサイト構築の実案件では、Figmaファイルを最適化するコストが高くては割に合わないため
- コーディングをする人間のプロンプトエンジニアリング力に頼らない
- 様々な案件に適用できる汎用的なtask.mdを作成し、案件毎にプロンプトを考えなくていいようにする
- 具体的または複雑なプロンプトは利用しない
- CodexやClaude Codeの高度な設定を要求しない
- 基本的にAGENTS.mdやCLAUDE.mdの最適化のみで対応する
- サブエージェントやカスタムコマンドは利用しない
前提知識
- Dev Mode MCPサーバー利用ガイド
- Code Connect
- Codex Doc
- Claude Code Doc
- Chrome DevTools(mcp)
はじめる前に
まずは、実際のデザインデータに基づいて、Codexがどれだけやれるか試してみる。
Claude CodeはMax Planの月額が高いので、なるべくCodexをChatGPTのPlusプランで定額利用で使うのが最もコスパがよさそう。
CursorまたはVS Codeの拡張機能からCodexを呼び出して、実際の出力を見ながら、プレビューをすぐ確認できる状況で作業する
まだ試してないが、HTML+CSSで構築させるより、なるべく技術スタックをReact + Tailwindに寄せたほうがLLMがやりやすいと思うので、Coding AgentがReactを使える環境を整える方針でいく。
まずは、AGENTS.mdのみを整えて環境構築からCodexにやってもらう。
基本的な設計は下記にする。
Astro（Viteベース）＋TypeScript＋Tailwind CSS
※ 性能が担保できるようなら、HTML+CSS+Vanilla JSのよりピュアな構成に近づけていく
検証開始(作業ログ)
1.AGENTS.mdの作成
上記の条件と、Figma MCPのドキュメントに書かれているプロンプトを考慮して、下記を最初のバージョンとしてみる
あなたは熟練したコーダーです。
Astro（Vite ベース）＋ TypeScript ＋ Tailwind CSS（PostCSS 経由）を使った静的 Web サイトを作成してください。
目的は、生成された HTML/CSS/JS を FTP で日本の共用サーバーにそのままアップロードできる安定的なコードベースを作成することです。
SSR や複雑な設定は回避し、なるべく認知負荷の低いコードベースを保ってください。
# AGENTS.md ― 長期メンテナンス運用ガイド
このドキュメントは、**人間/AI エージェントが長期にわたって本リポジトリを保守**するための運用基準です。
目的は「**シンプルさ・安定性・再現性**」を最優先に、**静的サイト**としての品質を継続的に担保することです。
タスクに関する情報は、coding_tasks.md に記載し、ユーザーに指定された範囲の作業を実行してください。
あなたが今後のために必要情報をまとめておきたい場合は、docsディレクトリを自由に使ってください。
作業フローが変更される場合や、追加で必要なタスクが生まれた場合は、AGENTS.mdや/tasks/coding_tasks.mdを適宜変更してください。
---
## 0. 基本方針（Non-Negotiables）
- **完全静的**：SSR/サーバーレス依存を避け、`dist/` をそのまま配布できる状態を維持。
- **少依存**：Astro + TS + Tailwind + PostCSS（autoprefixer）の最小構成を基本線にする。
- **可読性＞技巧**：過度な抽象化やメタ設定を避け、**合意された場所に、合意された書き方で**置く。
- **生産性の足枷を作らない**：Lint/Format/CI は必要最小限（導入時は別合意）。
---
## 1. 想定ディレクトリと運用
/tasks # ユーザーがエージェントにタスクを指示するためのドキュメント置き場 ※原則エージェントは編集不要
/docs # ユーザーとエージェントが参照するドキュメント置き場 ※原則エージェントは編集不要
/src
/src/components # 共通コンポーネント
/src/layouts #汎用レイアウト
/src/pages # ルーティングの単位（.astro / .mdx）
/src/styles # Tailwind のエントリ CSS、共通トークン
/src/assets # 静的アセット（直配布）
/layouts # BaseLayout などのレイアウト
astro.config.mjs
tailwind.config.ts
postcss.config.cjs
tsconfig.json
README.md
AGENTS.md # ← 本ドキュメント
- **ページは `/src/pages` に直置き**（入れ子ディレクトリで URL を表現）。
- 特定のページなどで頻繁に使われる共通 UI は `/src/layouts`・頻繁に使われる要素、スタイルは `/src/components` に追加（後方互換を壊さない）。
- ***
## 2. コーディング規約（要点）
### 2.1 TypeScript
- `strict: true` を維持。型穴埋めのための `any` は使わない。
- ESM 基準。相対インポートは**浅く保つ**（2 階層以内）。
### 2.2 Astro/テンプレート
- ページは `.astro` を基本。**軽量な島（island）**指向：クライアント JS は最小限。
- `<head>` はレイアウトで集中管理（タイトルはスロット/props で注入）。
### 2.3 Tailwind
- 原則**ユーティリティ直書き**。繰り返しが増えたら `@apply` で共通化。
- デザイントークン（色/余白/フォント）は `tailwind.config.ts` の `theme.extend` で管理。
- **コンポーネント命名**：意味ベース（例: `btn`, `card`, `section-hero`）。
### 2.4 アセット
- 画像は `/public` 直下。**SVG はできるだけインライン**（アクセシビリティ属性付与）。
- 画像最適化は**ビルド前**に外部ツールで行う（Sharp/手動）。ランタイム最適化は原則不使用。
---
## 3. 品質ゲート（軽量）
- **手動動作確認**（ローカル `npm run dev` / `npm run preview`）
- ナビゲーション、外部リンク、フォーム（使う場合）
- スマホ幅（375px）/ タブレット / デスクトップでのレイアウト崩れ無し
- **パフォーマンス予算（目安）**
- 初期配信 JS **≤ 60KB gz**、CSS **≤ 60KB gz**
- 画像は適切なフォーマット/寸法
- **アクセシビリティ**
- `alt`・`aria-*`・見出しレベル順守、コントラスト比 WCAG AA 目安
- **基本 SEO**
- `<title>`/`<meta name="description">`/OGP 最低限
- `lang="ja"` を維持
---
## 4. デプロイ運用（FTP/静的配布）
1. `npm run build` → `dist/` 生成
2. 先に**バックアップ**：サーバーの現行公開物を日付付きで退避
3. `dist/` を丸ごとアップロード（上書き）
4. **確認**：トップ/代表的下層/外部リンク/404
5. ロールバック手順：バックアップをそのまま復元
> メモ：**ベースパス**が必要なサーバーでは `<base href="/">` 追加や相対パス確認を行う。
---
## 5. デザイン参照に関するルール
本プロジェクトの Figma MCP サーバー利用: 有効
ユーザーから指定があった場合または、デザインを参照したほうが効率がいい場合は必ず MCP 経由でデザインを確認してください。
全体のデザインに関する情報や、各セクション URL は docs/figma/guideline.md に記載しています。
Figma MCP に接続する前には必ずこのドキュメントを参照し、どの Section URL を調べればよりデザインに忠実なコーディングできるかを考えた上で、MCP に繋いでください。
- Figma Dev Mode MCP サーバーは、画像や SVG アセットを提供するアセットエンドポイントを提供します。
- 重要: Figma Dev Mode MCP サーバーが画像または SVG のローカルホストソースを返す場合、その画像または SVG ソースを直接使用してください。
- 重要: 新しいアイコンパッケージをインポート/追加しないでください。すべてのアセットは Figma ペイロードに含まれている必要があります。
- 重要: ローカルホストソースが提供されている場合、プレースホルダーを使用または作成しないでください。
- 重要: `/src/components`のコンポーネントを可能な限り毎回使用してください。
- デザインを正確に一致させるために、Figma の忠実度を優先してください。
- ハードコードされた値を避け、Figma のデザイントークンが利用可能な場合はそれを使用してください。
- アクセシビリティに関する WCAG 要件に従ってください。
- コンポーネントのドキュメントを追加してください。
- UI コンポーネントを`/src/components`に配置し、本当に必要な場合を除き、インラインスタイルは使用しないでください。
---
## 6. テンプレート追加と **MDX** 拡張（オプション）
デフォルトは `.astro` ページ。**テンプレート的な静的ページを複数追加**する場合は、**MDX**での運用を許容します。
### 6.1 導入手順（必要時のみ）
1. `npm i -D @astrojs/mdx`
2. `astro.config.mjs`
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
export default defineConfig({
srcDir: './src',
outDir: './dist',
integrations: [mdx()], // ← 追加（既存最小構成に干渉しない範囲で）
server: { port: 4321 }
});
3. `tailwind.config.ts` の `content` に `mdx` を追加
`./src/**/*.{astro,html,js,ts,mdx}`
### 6.2 運用ルール
- 単体ページは `src/pages/*.mdx` に配置。**フロントマター**で `title/description` を明示。
- コンポーネント化が必要な繰り返し UI は `.astro` 側に切り出し、MDX から参照。
- MDX 導入は**最小限**に留め、依存増に見合う保守性メリットがある場合のみ。
- MDX を導入する際は、勝手に作業を進めず一度ユーザーに承認を取るようにしてください
---
## 7. 追加ページ/コンポーネントの作り方（チェックリスト）
- [ ] どの URL で提供するか（`/company`, `/policy` など）
- [ ] レイアウトは `BaseLayout.astro` を使用
- [ ] 見出し階層（`h1` は 1 ページ 1 つ）
- [ ] 画像は `/public` へ。寸法/alt 記載
- [ ] ボタン/リンクは既存スタイルを再利用（Tailwind ユーティリティ）
- [ ] メタ（title/description/OGP）反映
- [ ] スマホ/PC で崩れなし
- [ ] `npm run build` → `npm run preview` で最終確認(この操作はユーザーが行うので、エージェントが行う必要はありません。)
---
## 8. 国際化・将来拡張（任意）
- 既定言語は `ja`。多言語は `/en/...` のディレクトリ構造で段階導入。
- 将来的なアプリ化（Next.js 等）を検討する場合も、**まず静的で要件充足**を基準に判断。
---
## 9. 役割分担モデル（人/AI エージェント）
- **Build エージェント**：実装・構成変更・バンドルサイズ管理
- **Review エージェント**：可読性/静的性/A11y/SEO チェック
- **Docs エージェント**：README/CHANGELOG/デプロイ手順の更新
- **Release エージェント**：ビルド・FTP 配布・動作確認・ロールバック準備
> 特に指定がない限り、1 名（または 1 つの LLM）で兼務。ただし**レビュー視点の分離**は意識する。
---
## 10. 既知のつまづきと回避策
- **相対パス問題**：共用サーバー配下にサブディレクトリ公開する場合、リンクやアセット参照を相対化（`/` 起点を避ける）。
- **キャッシュ更新**：静的配布後に旧キャッシュが残る場合、アセット名にハッシュ付与（Astro 既定）を確認。
- **日本語ファイル名**：一部サーバで問題化。**半角英数/ハイフン**で統一。
---
## 付録：リグレッション最小化のための軽量スモークテスト
- トップ/下層 2 ページのレンダリング
- ナビゲーション/フッターのリンク遷移
- OGP タグの有無（主要ページ）
- モバイル幅の折返し・ボタン可視性
---
2.task_00.md (環境構築) の作成
必要なディレクトリを準備するタスク。各々の環境に合わせて、0から構築。あえてディレクトリ構造やフレームワークを管理せず、毎回0からCodexが作成することによって、modelの進化に合わせて精度の高いコーディングをさせる狙い。
task_00.md
下記のタスクを実行してください
- AGENTS.mdに書かれているディレクトリ構成を作成する
ここまでできたら、ディレクトリを作成し、ローカル開発環境に下記を作成してCodexに実行させる。
- AGENTS.md
- tasks/task_00.md
gpt-5-codex (medium)
[task_00.md](tasks/task_00.md) に従って、作業を開始してください。
3.Figma MCPとの疎通確認
Figma MCPでデザインファイルが見れるか確認。
~/.codex/config.tomlに下記を追加。
[mcp_servers.figma]
command = "npx"
args = ["-y", "mcp-remote", "http://127.0.0.1:3845/mcp"]
gpt-5-codex (medium)
Figma MCPから下記セクションのキーカラーを取得してください。
https://www.figma.com/design/xxx
想定どおりの答えが得られた。
キーカラー
#2BC16B — セクション全体でCTAボタン、プランラベル、ライン装飾に一貫して使われるブランドグリーン。
サポート色として #333333（本文文字色）、#FFFFFF（背景・文字）、#FDFAF2（セクション背景）が併用されています。
この配色は node-id xxxxx のFigmaデザイン（添付スクリーンショット参照）から取得しました。次のステップが必要であれば教えてください。
これで特定のディレクトリと、Figma MCPの接続が完了。
4.task_01.md
次は開発環境の最小環境を整えるための、task_01.mdを作成する。
task_01.md
AGENTS.mdを読み込み、最低限必要なnode packageをインストールしてください。
パッケージ管理には"pnpm"を用いてください。
開発環境の立ち上げがうまくいくかどうかは、ユーザー自身でテストするので、その直前までの作業でいいです。
package.jsonの追加が必要な場合は、適宜追加してください。
gpt-5-codex (medium)
[task_01.md](tasks/task_01.md) に従って、作業を開始してください。
無事完了。
5.task_02.md
ここからは手順によって、コーディングの精度が大きく変わるので、日々改良する必要がある。
一旦暫定的な対応として、Figma DesignをMCP経由で分析し、コーディングの雛形を作るための情報を切り取れるか実験してみる。
というのも、最近Figma Dev modeでEstimated tokensが確認できるようになっており、デザインのコンテキスト量に応じて、手法を最適化できそうだったから。
今回サンプルで使っているFigmaデザインがPC版・SP版どちらも15k前後だったので、PC・SPをまとめて分析できる可能性がある。
# 指示
Figma MCPを利用して、下記の要素をdocs/figma/guide-line.mdにまとめてください。
# 前提情報
SP版 section url
https://www.figma.com/design/pp8umj6fc2xgMpiyJx3jpw/%E3%82%B9%E3%82%B0%E3%83%8B%E3%83%BC-%E3%83%86%E3%82%A3%E3%82%B6%E3%83%BC%E3%82%B5%E3%82%A4%E3%83%88?node-id=153-7979&m=dev
PC版 section url
https://www.figma.com/design/pp8umj6fc2xgMpiyJx3jpw/%E3%82%B9%E3%82%B0%E3%83%8B%E3%83%BC-%E3%83%86%E3%82%A3%E3%82%B6%E3%83%BC%E3%82%B5%E3%82%A4%E3%83%88?node-id=153-7813&m=dev
# 最低限必要な要素
- このサイトの概要
- このサイトの構成要素
- header,section(適宜名前をつけてください),footer等
- コンポーネントにすべき要素
- レスポンシブデザインにするために注意すること
- PC版とSP版で変更になる要素
※その他、AGENTS.mdを確認して、あなたが有益だと思う情報を追記したい場合は、どんどん追記してください。
gpt-5-codex (medium)
[task_02.md](tasks/task_02.md) に従って、作業を開始してください。
めちゃくちゃ良さそうなアウトプットが出てきた。
各セクション分けも行ってくれるので、追加情報として、下記のようなセクションURLを手動で追加する。
ヘッダー(PC)
https://www.figma.com/design/xxx
ヘッダー(SP)
https://www.figma.com/design/xxx
フッター(PC)
https://www.figma.com/design/xxx
フッター(SP)
https://www.figma.com/design/xxx
MV(PC)
https://www.figma.com/design/xxx
MV(SP)
https://www.figma.com/design/xxx
Feature セクション(PC)
https://www.figma.com/design/xxx
Feature セクション(SP)
https://www.figma.com/design/xxx
カスタマイズ例(PC)
https://www.figma.com/design/xxx
カスタマイズ例(SP)
https://www.figma.com/design/xxx
事例紹介(PC)
https://www.figma.com/design/xxx
事例紹介(SP)
https://www.figma.com/design/xxx
料金プラン(PC)
https://www.figma.com/design/xxx
料金プラン(SP)
https://www.figma.com/design/xxx
大型 CTA(PC)
https://www.figma.com/design/xxx
大型 CTA(SP)
https://www.figma.com/design/xxx
AGENTS.mdに加筆
あまりに出来がよかったので、AGENTS.mdのFigma MCPの箇所に加筆する。
## 5. デザイン参照に関するルール
本プロジェクトの Figma MCP サーバー利用: 有効
ユーザーから指定があった場合または、デザインを参照したほうが効率がいい場合は必ず MCP 経由でデザインを確認してください。
全体のデザインに関する情報や、各セクションURLはdocs/figma/guideline.mdに記載しています。
Figma MCPに接続する前には必ずこのドキュメントを参照し、どのSection URLを調べればよりデザインに忠実なコーディングできるかを考えた上で、MCPに繋いでください。
coding_tasks.md を追加
必要なコンテキストが揃ったので、どのようにタスクを進めればいいかをCodexに考えてもらう。
個人的にはまずベースとなるレイアウトを作成してから、細かいセクションを実装していくスタイルが良いと思うが、ここもCodexに任せる。
gpt-5-codex (medium)
# 指示
tasks/coding_tasks.mdにFigmaデザインに忠実なWebサイトを制作するためのタスクをコンテキストが圧迫されない程度の粒度で作成してください。
# 参考ドキュメント
- AGENTS.md 基本的な開発の設計方針
- docs/figma/guideline.md デザインデータに関しての参考情報
# 注意事項
- デザインを参照する際はfigma mcpを必ず利用してください
- デザインの全体像を掴みたいときは、PC・SPの全体のsecrion urlを確認してください
- デザインの詳細部分を参照するするときは、各セクションのsecrion urlを確認してください
- 各タスクに必要なコンテキストのみを取得するように心がけてください
- 全タスク共通で気をつけることとして、下記をドキュメントに加えてください
実装がデザインが忠実に沿っているかを調べる際に、chrome-devtools MCPで実装の確認すること、Figma MCPでデザインの確認することを怠らない
いい感じのタスク分割に見える。
# coding_tasks: Figma 忠実実装のための分割タスク
## 01. デザイン参照準備
- Figma MCP に接続し、`docs/figma/guideline.md`で示された PC/SP の全体セクション URL をもとに、画面全体のレイアウトとデザイントークンを確認する。
- 取得が必要なアセット（ロゴ・背景装飾など）があれば MCP のアセットエンドポイントからダウンロードし、`/public` 配下に保存計画を立てる（このタスクではダウンロードせず必要な一覧のみ整理）。
## 02. グローバル設定の整備
- `tailwind.config.ts` と `src/styles` 配下を見直し、Figma のカラー / タイポグラフィ / シャドウ / ブレークポイントが再現できるよう theme.extend を更新する。
- ベースレイアウト (`src/layouts/BaseLayout.astro`) を確認または作成し、`<html lang="ja">`、共通 `<head>`、フォント読み込み、共通余白などを定義。必要に応じて `src/components` にタイポやボタンなどの共通スタイル用 CSS コンポーネントを追加。
## 03. ヘッダー実装
- Figma MCP からヘッダー（PC/SP）を取得してレイアウトを精査し、`src/components/Header.astro` とグローバルナビゲーション用のデータ構造を実装。
- PC/SP 両方のレイアウト差分（ナビ表示有無、CTA ボタン幅など）を Tailwind で調整し、Chrome DevTools のレスポンシブモードでデザインとの差異をチェック。
## 04. ヒーローセクション（MV）
- ヒーローのテキスト、装飾画像、ロゴ群の配置を Figma MCP で確認し、`src/components/HeroSection.astro`（または該当ページ内）を実装。
- アセット配置（装飾円の absolute 位置やロゴグリッド）を Tailwind と必要最小限のカスタム CSS で再現し、PC/SP 両方での表示をチェック。
## 05. Feature セクション群
- 各 Feature のテキスト / 画像を MCP で取得し、`FeatureCard` コンポーネントを `src/components` に実装。
- 3 つの Feature を交互 2 カラム（PC）→ 縦積み（SP）で構成するセクションを `src/components/FeatureSection.astro`（もしくはページ内）で構築し、余白・画像サイズをデザインどおりに調整。
## 06. カスタマイズ活用例セクション
- Figma MCP からカードのスタイル・ボーダー装飾・アイコン配置を確認し、`CustomUseCaseCard` コンポーネントを作成。
- PC で 3 カード横並び、SP で縦積みになるグリッドを実装し、テキスト量・背景色・アクセントラインが一致するか検証。
## 07. 導入事例セクション
- Case 01 / Case 02 のレイアウト（左右交互）とタイポ設定を MCP 参照で取得し、`CaseStudy` コンポーネントを実装。
- 画像サイズ・角丸・シャドウ・行間などを調整し、SP 表示時の縦積み順序がデザインと一致するか確認。
## 08. 料金プランセクション
- `PricingCard` コンポーネントを実装し、プラン名・料金・特徴リスト・CTA ボタンを配列データから描画する仕組みを構築。
- PC 並列 / SP 縦積み時のカード幅、シャドウ、角丸、CTA 配置を Figma と突き合わせて調整。
## 09. 大型 CTA & フッター
- MCP で大型 CTA とフッターを確認し、それぞれ `CTASection`、`FooterInfo` コンポーネントを作成。
- 背景色、余白、テキスト階層、リンク先などをデザインに合わせ、アクセシビリティ属性（`aria-label` 等）が必要かどうかもチェック。
## 10. ページ組み立て & 内部リンク
- `src/pages/index.astro`（想定）に各セクションコンポーネントを順序どおりに配置し、セクション `id` を付与してヘッダーのアンカーと連動させる。
- Figma MCP の文言や CTA ラベルを再確認し、ヒューマンエラーがないかクロスチェック。
## 11. レスポンシブ・アクセシビリティ最終確認
- Chrome DevTools で PC（1440px）、タブレット、中断幅（768px 付近）、SP（375px）を切り替えてデザインと比較、ズレがあれば修正。
- キーボードフォーカス、`alt` テキスト、heading レベル、meta 情報（title/description/OGP）を確認し、必要なドキュメント更新（README など）がある場合は記録。
## 12. ビルド動作と配布準備
- `npm run build` を実行して静的出力を確認し（ユーザーが preview 実行予定）、`dist/` 内に不要ファイルがないか検査。
- FTP 配布手順に沿って必要な作業ログを AGENTS.md もしくは関連ドキュメントに追記（必要な場合のみ）。
注意事項に対する記述がなかったので、下記を追記。
## 共通方針・Tips
- デザイン参照は必ず Figma MCP 経由で行い、取得したペイロードをもとに実装する。
- 画面全体を把握したいときは PC/SP 両方の全体セクション URL を確認してから作業に入る。
- 細部の調整や要素単位の実装時は、対象セクションの URL を個別に開いて寸法・余白・タイポを取得する。
- 各タスクで必要なコンテキストのみを取得し、不要なデータ取得で負荷や混乱を招かない。
- 実装をデザインと突き合わせる際はローカル開発サーバーを立ち上げ、Chrome DevTools のレスポンシブモードで比較・検証する。
作業開始
今までは新しいスレッドで実行してきたが、ここからは同じスレッドでコンテキストを維持しながら、作業してみる。
gpt-5-codex (medium)
[coding_tasks.md](tasks/coding_tasks.md) の01を始めてください。
docs/figma/task01_design_reference.mdを勝手に作った。
gpt-5-codex (medium)
[task01_design_reference.md](docs/figma/task01_design_reference.md) の利用方法を、 [AGENTS.md](AGENTS.md) や [coding_tasks.md](tasks/coding_tasks.md) に加えて、
[coding_tasks.md](tasks/coding_tasks.md) の02を始めてください。
AGENTS.mdの更新は無視されたが、ベースとなるファイルの更新は完了。
考えてみれば、AGENTS.mdを更新しなくても、設定ファイルを見ればわかることなので、そのまま次のタスクに進んでもらう。
gpt-5-codex (medium)
[coding_tasks.md](tasks/coding_tasks.md) の03を始めてください。
基本の設定ファイル、残りのタスクも続けて一気に自走してもらう。
gpt-5-codex (medium)
[coding_tasks.md](tasks/coding_tasks.md) の04~12まで行い、作業を完了させてください。
一気に600行ガシガシ書いてくれた。
エラーが出ていたので、修復してもらう。
gpt-5-codex (medium)
開発サーバーを確認したところ、エラーが発生しています。chrome-devtoolsのmcp経由でエラー内容を確認し、修正してください。
20分ぐらい格闘していたようだが、無事完了。
評価
70点ぐらいの出来
- いいところ
- 使ってる文字色や背景色はほぼ完璧
- 大枠のレイアウトとしてもほぼ完璧
- できていないところ
- 画像の読み込み、配置ができていない
- 文字が間違えている
- デザインにない要素を生成している
エージェント自身に足りないところを考えさせる
# 指示
コーディングしたプレビューをデザイン案に極限まで近づけるためのタスクをtasks/improvement_tasks.mdに書いてください。コンテキストが圧迫されない程度にタスクは分割してください。
# タスクの作成までの調査
- figma mpc経由でfigmaデザインを確認し、chrome-devtools mcp経由で実際の実装と見比べて、何が違うかをレビューしてください。
- レビューはPCとSPの両方行ってください。
- まずはPC全体とSP全体のデザインと、PC全体とSP全体の実装を比べてください。
- 次は各セクション毎に詳細な実装を比べてください。
- 差分を理解し、それを埋めるためのタスクをtasks/improvement_tasks.mdに記載してください。
さすがにcontext windowがいっぱいで動かない。
Codex ran out of room in the model's context window. Start a new conversation or clear earlier history before retrying.
gpt-5-codex (medium)
#指示
コーディングしたプレビューをデザイン案に極限まで近づけるためのタスクをtasks/improvement_tasks.mdに書いてください。コンテキストが圧迫されない程度にタスクは分割してください。
まずはfigma mpc経由でPC全体を確認し、次にchrome-devtools mcp経由で実際のPCの実装を確認して、何が不足しているかを検証してください。（すでにhttp://localhost:4321/に開発サーバーを立ち上げておきました）
次は同じ手順でSPをチェックしてください。
細かいセクション毎のテキストやデザインはのちほどでいいです。
全体を見比べるのは、コンテキストウィンドウ的に難しそう。
Codex ran out of room in the model's context window. Start a new conversation or clear earlier history before retrying.
Sonnet-4.5
#指示
コーディングしたプレビューをデザイン案に極限まで近づけるためのタスクをtasks/improvement_tasks.mdに書いてください。コンテキストが圧迫されない程度にタスクは分割してください。
まずはfigma mpc経由でPC全体を確認し、次にchrome-devtools mcp経由で実際のPCの実装を確認して、何が不足しているかを検証してください。（すでにhttp://localhost:4321/に開発サーバーを立ち上げておきました）
次は同じ手順でSPをチェックしてください。
細かいセクション毎のテキストやデザインはのちほどでいいです。
一発でtasks/improvement_tasks.mdを作成。
やはり、膨大になったコンテキスト管理や、toolCallingはClaudeのほうが精度が高い。chrome-devtools mcpがエラーで動作しないときにも、puppeteer MCPで代替し、難なくクリア。
修正作業を開始する
以後のタスクは、Sonnet-4.5(Claude Code)で行う。
Sonnet-4.5
では、このドキュメントに沿って、作業を開始してください。
適宜Figma MCPやchrome-devtools MCPを使用して、精度を確認してください。
ソースコードを確認すると、AGENTS.mdの下記の指示が効いていなく、ローカルのホストソース(アセットエンドポイント)を利用していたので、修正依頼を出す。ここはプロンプトの書き方で改善できそう。
AGENTS.md(CLAUDE.md)のよくない箇所
- 重要: Figma Dev Mode MCP サーバーが画像またはSVGのローカルホストソースを返す場合、その画像またはSVGソースを直接使用してください。
Sonnet-4.5
LP全体を確認しました。全ての画像の読み込みが、Figma MCPが返すファイルローカルのアセットポイントを指して実行されています。
全ての画像読み込みを見直して、SVGファイルをsrc/assetsに格納して、そこから読み込む設計に変更してください。
品質管理
Webサイトのデザインや、Figmaデザインの最適化具合によっては、おそらく、ここまででほぼ完璧なWebサイトを完成できる。
だが、もっとCodexやClaude側で品質を上げたい場合のプロンプト例を下記においておく。
特定課題の課題解決用
"ヘッダー"と"MVセクション"の画像処理がうまくいっていません。Figma MPC(デザイン)とchrome-devtools MCP(実装)を比較しながら修正してください。
特定のセクションの改善用。
# 指示
Figma MPC(デザイン)とchrome-devtools MCP(実装)を比較して、"ヘッダー"のデザインと実装の一致度を高めてください。
# 注意事項
- PCとSPのどちらもチェックしてください
- 下記チェック項目は必ずチェックしてください
- 配置している要素は一致しているか
- 文字列は全て一致しているか
- マージン・空白は一致しているか
- 背景色やボタン色は一致しているか
- ボーダーやシャドウのデザインが一致しているか
- あなたが一致度が90%になったと判断するまで、この作業はやめないでください
Discussion