Claude Code × HTML/CSS/JavaScript でWebアプリケーションのモック画面を作る ── 16個のモック画面を1週間で作成した話
2026-03-02
azblob://2026/03/02/eyecatch/2026-03-02-make-mockScreen-with-ClaudeCode-000.jpg

はじめに

「動く画面が見てみたい」── レビューの場で、こんなリクエストを受けたことはありませんか?


従来のやり方だと、動く画面を見せるまでの道のりはなかなか長いものでした。

デザインチームが画面を作成
       ↓
コンポーネントに分解
       ↓
フロントエンドで組み上げ
       ↓
必要に応じてバックエンドも用意
       ↓
ようやく見せられる状態に


このように、実際に動く画面を見せるまでにはいくつもの工程が必要です。


「ではFigmaでモック画面を作成して並べれば?」と思うかもしれませんが、それでもデザインチームへの負担は大きいですし、静止画では動きが伝わりづらいという問題は残ります。


そこで試したのが、Claude Codeを使ったモック画面の作成です。


本記事では、チームで実際にWebアプリケーションのモック画面を16画面以上作成した経験をもとに、その進め方や得られた気づきについて紹介します。


※本記事の文章は、一部生成AIを用いて作成しています。

対象読者

  • 「動く画面」をレビューやクライアント提案に使いたいが、デザインチームや開発工数が足りないと感じている方
  • Claude Codeをモック画面の作成に活用してみたい方
  • AIを使った開発フローに興味がある方

本記事で解説しないこと

  • Claude Codeのインストール方法や初期設定
  • Figma MCP Serverの構築手順
  • 具体的なプロンプトの全文
  • 本番環境を想定したフロントエンド実装のベストプラクティス

なぜClaude Codeでモック画面を作ろうと思ったのか

モック画面をClaude Codeで作ろうと考えた背景には、主に3つの理由がありました。

  • デザインチームの負担を減らしたかった
    • モックの段階で複数パターンのUI作成をデザインチームに何度も依頼するのは、工数的にも心理的にも負担が大きくなってしまいます。初期段階でのUIパターン出しを開発チーム側が担うことで、デザインチームの負担軽減を目指しました。
  • 開発側の設計思想を伝えたかった
    • テキストの設計書だけでは意図が正確に伝わらないことがあります。動く画面を見せることで、「こういう動きをイメージしている」という認識をチーム内で素早く共有できます。
  • レビューしやすくしたかった
    • テキストベースの設計書を読み解くよりも、実際に動く画面を触ってもらったほうが、レビューは圧倒的に早くて正確です。
      もちろん、最終的なデザインはデザイナーの方に仕上げてもらうのが理想ですが、認識合わせやレビューの段階では、Claude Codeで素早く作ったモックが十分に役立ってくれました。

使った技術スタック

今回のモック画面では、フレームワークを使わないシンプルな構成にしました。

  • HTML/CSS/JavaScript
  • Tailwind CSS(スタイリングの一部に活用)


モック画面の目的はあくまで「見た目と動きの確認」なので、ReactやNext.jsのようなフレームワークは使っていません。

素のHTML/CSS/JavaScriptで十分でしたし、Claude Codeとの相性も良かったと感じています。

Tailwind CSSはスタイリングを効率よく適用するために一部で取り入れました。

モック画面の作り方

モック画面の作成は、一度にすべてを作るのではなく画面単位で段階的に進めました。

指示の出し方

Claude Codeにモック画面を作ってもらうとき、短いテキストだけの指示ではレイアウトが意図と大きくずれたり、要素の抜け漏れが発生したりする場面がありました。

そのため、Claude Codeに指示を出す際に以下の3点を意識しました。

  • テキストで詳細に説明する
    • 画面の目的、含める要素、動作の流れなどをテキストで具体的に伝えます。「ログイン画面を作って」のような曖昧な指示ではなく、構成要素を明示するようにしていました。例えば「メールアドレスとパスワードの入力フィールド、ログインボタン、パスワードリセットリンク、新規登録リンク、ソーシャルログインボタンを含むログイン画面」といった形です。
  • 参考画像を渡す
    • イメージに近いデザインの参考画像があれば、それをClaude Codeに直接渡します。テキストだけでは伝えきれないレイアウトや雰囲気を補完できるので、これはかなり効果的でした。
  • Figma MCP Serverで業務フローを共有する
    • FigJamで整理した業務フロー図から、作成する画面に関連する部分をノード単位で抽出し、MCP Server経由でClaude Codeのコンテキスト(AIが参照する情報)に渡しました。必要に応じてテキストで補足説明も加えます。こうすることで、Claude Codeが「この画面は業務フローのどの部分を担っているのか」を正確に理解した状態でモック画面を生成してくれます。単に見た目を作るだけでなく、業務要件を反映した画面になるのが大きなメリットです。

作業時の進め方

1画面ごとの進め方は以下の通りです。
  1. 1つの画面に必要な要素と動作を整理する
  2. 上記の3つの方法を組み合わせてClaude Codeに指示を出す
  3. 出力された画面を確認し、修正点があればフィードバックする
  4. 画面が完成したら、次の画面に進む

このアプローチを取った理由は、各画面の品質を確認しながら着実に進められるからです。
一度に大量の画面を作ろうとすると、Claude Codeに渡す情報量が多くなり、一貫性が保ちにくくなります。
そのため、1画面ずつ完成させていくことで、その問題を避けられました。

実際に作ってみた

ここからは、前のセクションで紹介した進め方を使って実際にダッシュボード画面を作った流れを紹介します。

手順としては、「ダッシュボード付きTodoリストアプリ」を題材に仮想の要件定義書を作成しました。

その要件定義書から以下の機能詳細とデザインガイドラインをClaude Codeに渡し、HTML/CSSでモック画面を作成するよう指示しています。

 

## ダッシュボード画面
**概要**: タスク状況を俯瞰できるメイン画面

**構成要素**:
- サイドナビゲーション
- ヘッダー(ユーザーアイコン、通知)
- KPIカード(全タスク数、完了数、未完了数、期限切れ数)
- 週間進捗グラフ(棒グラフ)
- 優先度分布グラフ(円グラフ)
- 直近の期限タスクリスト
- クイックタスク追加ボタン

## デザインガイドライン

### 1 カラーパレット
| 用途 | ライトモード | ダークモード |
|------|--------------|--------------|
| プライマリ | #3B82F6 (Blue) | #60A5FA |
| セカンダリ | #10B981 (Green) | #34D399 |
| 警告 | #F59E0B (Amber) | #FBBF24 |
| エラー | #EF4444 (Red) | #F87171 |
| 背景 | #F9FAFB | #111827 |
| テキスト | #111827 | #F9FAFB |

### 2 優先度カラー
| 優先度 | カラー |
|--------|--------|
|| #6B7280 (Gray) |
|| #3B82F6 (Blue) |
|| #F59E0B (Amber) |
| 緊急 | #EF4444 (Red) |

### 3 タイポグラフィ
- 見出し: Inter または Noto Sans JP
- 本文: Inter または Noto Sans JP
- 等幅: JetBrains Mono

最初の指示から動作確認・修正をして、最終的に5分ほどで以下のモック画面を作成できました。

ダッシュボードのモック画面


ダッシュボードの画面として、細かなUI修正やカラーの調整は必要ですが「確認のためのたたき台」としては十分すぎるクオリティだと考えています。

このように、要件とデザインガイドラインを事前に整理しておけば、1画面あたり数分で形になります。

良かった点

Claude Codeでモック画面を作って良かったと感じた点は、大きく3つあります。

  • スピードが圧倒的に速い
    • 指示を出せば短時間で画面を生成してくれます。ちょっとした修正や別バリエーションの作成も、デザインチームに都度依頼することなく、その場で試すことができました。
  • 設計のアイデアをもらえる
    • Claude Codeに画面を作ってもらう過程で、自分では思いつかなかったUIの構成案やレイアウトの提案をもらえることがありました。単なる作業ツールではなく、設計のパートナーとしても機能してくれます。
  • 作成したコードがそのまま再利用できる
    • モック画面として生成されたHTML/CSS/JavaScriptのコードは、「使い捨てのモック」ではなく、実際の開発でも土台として再利用できます。

課題と対策

一方で、課題もありました。特にチームで並行して作業する際に顕著だった点を紹介します。

  • コンテキスト管理の難しさ
    • 16画面以上になると、画面間の一貫性を保つのが難しくなります。ある画面で決めたデザインルールが、別の画面の作成時にClaude Codeのコンテキストから抜け落ちてしまうことがありました。
  •  チーム作業時のコンフリクト
    • 複数人で並行して作業すると、同じような箇所を編集してしまいコンフリクトが頻発しました。これはClaude Code特有の問題というよりも、チーム開発全般に共通する課題です。モック作成のスピードが速い分、コンフリクトの発生頻度も上がる印象でした。

上記の課題に対しては、デザインルールやメンバーの作業分担を事前に明確にし、進捗状況をこまめに共有するようにしました。

これにより、画面間の一貫性を保ちつつ、コンフリクトも抑えられました。

これからClaude Codeでモック画面を作る方へ

実際にやってみて感じたアドバイスを4つにまとめました。

1. 要件を明確にする
Claude Codeへの指示は具体的であればあるほど、精度の高い出力が返ってきます。「いい感じのダッシュボードを作って」ではなく、KPIカードの内容やグラフの種類まで指定するのがおすすめです。

2. 参考資料を準備する
デザインの参考画像や業務フロー図があると、出力の質が大きく変わります。Figma MCP Serverのようなツール連携を活用すると、さらに効果的です。

3. 段階的に作る
一度にすべてを作ろうとせず、画面単位で段階的に構築します。1画面ずつ完成させることで、品質を確認しながら進められます。

4. チーム連携を意識する
複数人で作業する場合は、作業分担を事前に明確にしておくことが大切です。モック作成のスピードが速い分、コンフリクトが発生しやすいので、こまめな情報共有を心がけてください。

そして何よりも大事な最初の一歩は、業務フローの整理とチーム内の認識合わせです。モック画面を作り始める前に、「何のために」「どんな画面を」「誰に見せるのか」を整理しておくことが、成功の鍵になります。

まとめ

今回は、Claude Codeを使ってWebアプリケーションのモック画面を16画面以上作成した経験について紹介しました。

ポイントを整理すると、以下の通りです。

  • テキスト説明・参考画像・Figma MCP Server連携を組み合わせて、Claude Codeに正確な要件を伝えることが重要になる
  • 画面単位で段階的に構築することで、品質を保ちながら効率よく進められる
  • スピード・アイデア出し・コード再利用の3つが大きなメリットとなる
  • チーム開発では、作業分担の明確化とコミュニケーション強化がコンフリクト対策になる

Claude Codeを使ったモック画面作成は、単なる効率化にとどまりません。

AI時代における新しいチーム内の認識合わせの方法の一つだと感じています。

「動く画面を見せたいけど、そこまで手が回らない」と感じている方は、ぜひ一度試してみてください。

最後まで読んでいただき、ありがとうございました。