product-showcase

製品ショーケースジェネレーター

Web アプリの機能を実際に理解してもらえるマーケティングサイトを生成します。ヒーローセクションと機能グリッドだけではありません。実際のスクリーンショット、ワークフローを紹介するアニメーション GIF、機能の詳細解説を備え、「これは何？」から「具体的にどう動くの？」まで段階的に理解を深められるマルチページサイトを作成します。

複雑なアプリ、エージェント型 AI ツール、静止画のスクリーンショットだけでは価値が伝わらないあらゆる製品で特に役立ちます。

詳細レベル

詳細度	出力	所要時間
quick	1 ページ — ヒーロー、機能、CTA。以前と同じです。	15〜20 分
standard	マルチページサイト — ホーム、機能ページ、スクリーンショット付きの使い方ページ。	1〜2 時間
thorough	包括的なサイト — ホーム、機能ごとのページ、アニメーション GIF による操作手順、ユースケース、比較ページ、ドキュメント形式のデモ。	3〜6 時間

デフォルト：standard

ブラウザツールの検出

開始する前に、利用可能なブラウザツールを検出します。

1. Chrome MCP (mcp__claude-in-chrome__*) — 認証が必要なアプリに推奨
2. Playwright MCP (mcp__plugin_playwright_playwright__*) — 公開アプリ向け
3. playwright-cli — スクリプトによるフロー向け

ワークフロー

1. 入力情報の収集

項目	必須	例
アプリの URL	はい	https://app.example.com または http://localhost:5173
アプリ名	はい	「Acme CRM」
タグライン	いいえ	「邪魔にならない CRM」
ターゲットユーザー	いいえ	「小規模事業のオーナー」
料金情報	いいえ	無料プラン、プロプランは月額 $29
CTA のテキストと URL	いいえ	「無料トライアルを開始」→ 登録ページ
お客様の声	いいえ	ユーザーが提供するか、セクションを省略

2. スクリーンショットの撮影

bin/ に含まれる capture-screenshots を使ってアプリを撮影します。毎回 Playwright スクリプトを生成するよりも高速で、一貫した結果が得られます。

クイック撮影（主要なページを一度に撮影）：

capture-screenshots http://localhost:5173 \
  --pages /,/dashboard,/contacts,/settings \
  --output showcase/screenshots \
  --prefix screen \
  --mobile --dark

1 回の実行で、各ページのデスクトップ版（1280x720）、モバイル版（375px）、ダークモード版が生成されます。

認証が必要なアプリの場合：

capture-screenshots https://app.example.com \
  --pages /,/dashboard,/settings \
  --auth user:password \
  --output showcase/screenshots \
  --mobile --dark

撮影するもの：

a. 第一印象 — メインページ／ダッシュボードをヒーロー画像にします。すぐに伝わる価値提案を確認します。

b. 機能 — 主なセクションをそれぞれ撮影します。--pages にすべてのナビゲーションパスを指定します。製品の魅力が伝わる主要な画面を 6〜10 枚撮影します。

c. 「使い方」の流れ — 主要なワークフローを順番に撮影します。フローの各ステップを進めながら、--prefix workflow-step を指定して capture-screenshots を複数回実行します。

d. 詳細画像 — 特定の UI 要素を拡大して撮影します。スクロール可能なコンテンツには --full-page を使います。

e. 両方のモード — --dark フラグを指定すると、ライトモード版とダークモード版が自動的に撮影されます。ヒーローには、最も見栄えのするモードを使います。

撮影後の最適化：

img-process batch showcase/screenshots --action optimise --max-width 1920 -o showcase/screenshots-opt

f. 価値提案を抽出する

機能を並べるだけにしないでください。それぞれについて、**ユーザーにとってのメリットは何か？**に答えます。

• 悪い例：「連絡先管理ページ」
• 良い例：「すべてのクライアント、その履歴、対応が必要な項目を一目で確認」
• 悪い例：「検索機能」
• 良い例：「数秒で何でも見つかる — 意味検索が入力した単語だけでなく、意図まで理解」

3. サイトの生成

クイックモード：1 ページ（以前と同じ）

HTML ファイル 1 つ：ヒーロー＋機能グリッド＋CTA。MVP や手早いマーケティングに使います。

スタンダードモード：マルチページサイト

showcase/
├── index.html              # Home — hero, overview, feature highlights, CTA
├── features.html           # All features with screenshots and descriptions
├── how-it-works.html       # Step-by-step workflow walkthrough with screenshots
├── screenshots/            # All captured images
│   ├── hero.png
│   ├── feature-*.png
│   ├── workflow-step-*.png
│   └── *.gif               # Animated walkthroughs
└── styles.css              # Shared styles (or inline Tailwind CDN)

ホームページ：アニメーション GIF または主要なスクリーンショットを使ったヒーロー、3〜4 個の機能のハイライト（すべてではなく、特に優れた機能のみ）、「使い方」の概要（3 ステップ）、CTA。

機能ページ：各機能について、実際のスクリーンショットとメリットを重視した説明を掲載します。機能が 6 つ以上ある場合は、カテゴリごとにまとめます。それぞれの機能をきちんと説明できるだけのスペースを確保します。

使い方ページ：主要なワークフローを、手順に沿ったビジュアルガイドとして紹介します。各ステップにはスクリーンショット（またはアニメーション GIF）、見出し、2〜3 文の説明を付けます。このページでは、「なるほど。でも、実際に使うとどんな感じ？」という疑問に答えます。

徹底モード：包括的なサイト

showcase/
├── index.html              # Home — hero, overview, value proposition
├── features/
│   ├── index.html          # Feature overview grid
│   ├── [feature-1].html    # Deep-dive: one page per major feature
│   ├── [feature-2].html    # Each with screenshots, GIFs, use cases
│   └── [feature-n].html
├── how-it-works.html       # Full workflow walkthrough
├── use-cases/
│   ├── [use-case-1].html   # Scenario: "A day in the life of..."
│   └── [use-case-2].html   # Scenario: "When a new client calls..."
├── compare.html            # "Why [app] vs alternatives" (optional)
├── screenshots/
│   ├── hero.png
│   ├── feature-*/           # Per-feature screenshot sets
│   └── workflows/           # Animated GIFs
└── styles.css

機能ごとの詳細ページ：主要な機能ごとに、次の内容を含む専用ページを用意します。

• 機能の使用中の様子を示すヒーロースクリーンショット
• 「機能の説明」— 価値を説明する1～2段落
• 「仕組み」— スクリーンショットやGIFを使った手順
• 「重要な理由」— 解決できる課題
• 例外的なケースや上級ユーザー向けのヒント
• 次の機能へのリンク（ページ間の流れ）

ユースケースページ：実際のシナリオでアプリを紹介する、ストーリー仕立てのページです。

• 「月曜の朝です。ダッシュボードを開くと、こんな画面が表示されます……」
• 各ステップのスクリーンショットを使って、現実的なワークフローを説明します
• アプリを使ったことで何が変わったのか、結果を示します
• 説明が難しいアプリでは、最も説得力のあるページになります

比較ページ（任意）：「[app]と［代替案］、どちらを選ぶべきか」— マーケティング用の美辞麗句ではなく、率直に比較します。機能表、主な差別化要素、最適なユーザー層を掲載します。

4. アニメーションGIFによるウォークスルー

静止スクリーンショットではワークフローが伝わりません。主要な機能について、実際の操作を示すアニメーションGIFを撮影します。

撮影方法（PlaywrightまたはChrome MCPを使用）：

1. 開始状態に移動します
2. 約2fpsでスクリーンショットの記録を開始します
3. ワークフローを実行します（クリック、入力、移動）
4. 記録を停止します
5. フレームを結合してGIFを作成します

GIFの生成 — スクリーンショットを連続して撮影し、結合します。

# Capture each step with a sequential prefix
capture-screenshots http://localhost:5173/clients \
  --prefix workflow-01 --output .jez/screenshots
# ... navigate to next state ...
capture-screenshots http://localhost:5173/clients/new \
  --prefix workflow-02 --output .jez/screenshots

# Combine frames into GIF (Python one-liner using Pillow)
python3 -c "
from PIL import Image; import glob
frames = [Image.open(f) for f in sorted(glob.glob('.jez/screenshots/workflow-*.png'))]
frames[0].save('showcase/screenshots/workflows/create-client.gif',
    save_all=True, append_images=frames[1:], duration=500, loop=0)
"

アニメーションにする内容：

• 主な「何かを作成する」フロー（2～4秒）
• 検索／フィルター操作（結果が表示される様子）
• ドラッグ＆ドロップや並べ替え操作
• ダークモードの切り替え（見た目に変化があるもの）
• アプリが印象的な動作をする「魔法の瞬間」（AIによる分類、即時検索、リアルタイム更新など）

GIFのガイドライン：

• 最大10秒／20フレーム。短いほど効果的です
• 1280x720で撮影し、640x360で表示します（ファイルサイズを半分にします）
• 最終状態で短い一時停止（3フレーム）を入れ、結果が見えるようにします
• 連続してループ再生します。「クリックして再生」は不要です
• GIFが5MBを超える場合は、フレーム数を減らすか、関連する範囲にトリミングします

HTMLでの表示：

<div class="browser-frame">
  <div class="browser-frame-bar">
    <span class="browser-frame-dot"></span>
    <span class="browser-frame-dot"></span>
    <span class="browser-frame-dot"></span>
  </div>
  <img src="screenshots/workflows/create-client.gif"
       alt="Creating a new client in 3 clicks"
       loading="lazy" width="640" height="360">
</div>

5. エージェント型／AIアプリの説明

エージェント型アプリは、価値が見えにくく、AIがユーザーの目に触れない作業を行うため、特にマーケティングが困難です。一般的なスクリーンショットではチャット画面が表示されますが、それでは魅力が伝わりません。

エージェント型アプリで効果的なパターン：

パターン	表示する内容	例
ビフォー／アフター	ユーザーが以前手作業で行っていたことと、エージェントが行うこと	「以前：3つのシステムからコピー＆ペースト。現在：エージェントがバックグラウンドで処理。」
タイムライン	時間の経過とともに起こること。エージェントが数時間／数日にわたって作業する様子	「午前8時：エージェントが受信トレイを確認。午前9時：47件のメールを分類。午前10時：緊急の3件にフラグを設定。」
結果の紹介	プロセスを省き、出力を見せる	「エージェントが1,200件のメールを分析 → 89社の顧客、340件の連絡先、2,100件のナレッジ情報を抽出」
並べて比較	エージェントの作業を、人が行った場合の作業と並べて見せる	画面を分割し、左に元のメール、右に抽出した構造化データを表示
魔法の瞬間のGIF	最も印象的な動作を1つのアニメーションで見せる	ユーザーが質問 → エージェントがナレッジを検索 → 出典付きで回答

エージェント型アプリのコピーのヒント：

• 技術ではなく、結果を前面に出します（「AI搭載CRM」ではなく「すべての顧客の履歴を把握」）
• 処理量を示します（「1,200件のメールを処理」は「メールを処理します」より印象的です）
• 所要時間を比較します（「2時間かかっていた作業が、今では30秒で完了」）
• 専門用語を避けます（「RAGを用いたセマンティックベクトル検索」ではなく「データ内のつながりを見つける」）

5. スクリーンショットの表示

スクリーンショットはCSSを使ったブラウザーフレームのモックアップ内に表示します。

.browser-frame {
  border-radius: 8px;
  box-shadow: 0 25px 50px -12px rgba(0,0,0,0.25);
  overflow: hidden;
  border: 1px solid rgba(0,0,0,0.1);
}
.browser-frame-bar {
  background: #f1f5f9;
  padding: 8px 12px;
  display: flex;
  gap: 6px;
}
.browser-frame-dot {
  width: 10px;
  height: 10px;
  border-radius: 50%;
  background: #e2e8f0;
}

画像を編集しなくても、スクリーンショットを洗練された「ブラウザー内のアプリ」のように見せることができます。

6. サイトのナビゲーション（複数ページ）

複数ページのサイトでは、一貫性のあるナビゲーションが必要です。

<nav>
  <a href="/">Home</a>
  <a href="/features/">Features</a>
  <a href="/how-it-works.html">How It Works</a>
  <a href="/use-cases/">Use Cases</a>  
  <a href="#pricing">Pricing</a>
  <button>Get Started</button>
</nav>

• すべてのページに固定ナビゲーションを配置
• 現在のページを強調表示
• モバイル向けのハンバーガーメニュー
• CTAボタンを常にナビゲーション内に表示

7. 出力

生成後、ユーザーに次の内容を伝えます。

• プレビュー：python3 -m http.server -d showcase を実行し、http://localhost:8000 を開きます
• デプロイ：showcase/ フォルダーを Cloudflare Pages、Netlify、または任意の静的ホストにドラッグします
• 差し替えが必要なプレースホルダーコンテンツを一覧表示します
• 生成した GIF とそのファイルサイズを記載します

デザインパターン

カラー：アプリに明確なブランドカラーがある場合は、それを抽出してプライマリカラーとして使用します。そうでない場合は、ニュートラルなパレット（スレート／ブルー）をデフォルトで使用します。

タイポグラフィ：システムフォントスタックを使用します（外部へのリクエストなし）。landing-page と同じ方法です。

レスポンシブ：モバイルファーストとし、スクリーンショットは自然に縮小されるようにします。モバイルでは、スクリーンショットをグリッドではなく縦に並べます。

ダークモード：CSS カスタムプロパティを使用した、ライト／ダーク／システムの 3 状態切り替えにします。

パフォーマンス：スクリーンショット画像を遅延読み込みします。スタイル設定には Tailwind CDN を使用します。ビルド工程は不要です。

洗練された見た目にする

スクリーンショットの改善

• データを整える：スクリーンショットを撮る前に、アプリに「Test Client」や「[email protected]」ではなく、現実的なデータが入っていることを確認します
• ウィンドウサイズを統一する：すべてのスクリーンショットを同じビューポート幅（1280x720）で撮影します
• スクリーンショットにブラウザーの枠を含めない：実際の Chrome ツールバーを撮影する代わりに、CSS のブラウザーフレームのモックアップを使用します
• 操作を強調する：スクリーンショットで機能を紹介する場合は、その機能を有効にした状態にします（モーダルを開く、フィルターを適用する、アイテムを選択するなど）

視覚的なストーリーテリング

• ダッシュボードから始める：ヒーローのスクリーンショットには、データが入力され、生き生きとして便利に見えるアプリを表示します
• アプリが動作している様子を見せる：空のフォームより、結果を表示したスクリーンショットのほうが効果的です
• 段階的に見せる：ヒーローで全体像を示し、「使い方」で流れを説明し、機能紹介で詳細を伝えます
• 成果を見せて締めくくる：CTA の直前の最後のセクションでは、レポートが生成された、タスクが完了した、クライアントを管理できた、といった成果を示します

スクリーンショットとモックアップを組み合わせる

実際のスクリーンショットは、製品が実在することを伝えます。モックアップは、製品が洗練されていることを伝えます。両方を使用します。

• ヒーロー：ブラウザーフレームのモックアップに実際のスクリーンショットを配置し、アプリの存在と優れた見た目を示します
• 使い方：手順の流れには簡略化したモックアップのイラスト（CSS の図形、アイコン、矢印）を使用し、詳細には実際のスクリーンショットを使用できます
• 機能グリッド：実際のスクリーンショットを使用します。ユーザーは実際の UI を見たいと考えています
• モバイルショーケース：CSS のデバイスフレームのモックアップ（スマートフォンの外枠）で、モバイルのスクリーンショットを囲みます
• ダッシュボード／概要：実際のスクリーンショットを使用します。ここが見せ場です

スマートフォンのモックアップフレーム（CSS）：

.phone-frame {
  border: 8px solid #1f2937;
  border-radius: 32px;
  overflow: hidden;
  max-width: 280px;
  box-shadow: 0 25px 50px -12px rgba(0,0,0,0.3);
}
.phone-frame-notch {
  background: #1f2937;
  height: 24px;
  border-radius: 0 0 16px 16px;
  width: 120px;
  margin: 0 auto;
}

アニメーション（CSS のみ、JS 不要）

/* Fade in sections as user scrolls (intersection observer via CSS) */
@keyframes fadeInUp {
  from { opacity: 0; transform: translateY(20px); }
  to { opacity: 1; transform: translateY(0); }
}
.section { animation: fadeInUp 0.6s ease-out both; }

/* Subtle float on hero screenshot */
@keyframes float {
  0%, 100% { transform: translateY(0); }
  50% { transform: translateY(-8px); }
}
.hero-screenshot { animation: float 6s ease-in-out infinite; }

グラデーションのアクセント

アプリのプライマリカラーを抽出し、セクションの背景に控えめなグラデーションとして使用します。

.hero { background: linear-gradient(135deg, var(--primary) 0%, transparent 60%); }
.cta-banner { background: linear-gradient(135deg, var(--primary), var(--primary-dark)); color: white; }

デプロイ

ショーケースサイトは、ファイルから開くだけでなく、実際の場所でホストする必要があります。利用できる環境に応じて選択します。

オプション 1：静的アセットを使用した Cloudflare Workers（推奨）

紹介するアプリがすでに Cloudflare 上にある場合は、ショーケースも Worker としてデプロイします。

# In the showcase/ directory, create a minimal wrangler.jsonc:
{
  "name": "myapp-showcase",
  "main": "src/index.ts",  // or use static-only pattern
  "compatibility_date": "2026-03-01",
  "assets": { "directory": "./" }
}

npx wrangler deploy

または、カスタムドメインを割り当てます：showcase.myapp.com または myapp.com（アプリ自体が app.myapp.com にある場合）。

オプション 2：Cloudflare Pages（ドラッグ＆ドロップ）

ダッシュボード → Pages → Create → Upload assets → showcase/ フォルダーをドラッグします。.pages.dev の URL をすぐに取得できます。

オプション 3：静的ホスト（Netlify、Vercel、GitHub Pages）

HTML、CSS、画像だけなので、どの静的ホストでも利用できます。サーバーサイドコードは不要です。

カスタムドメイン

プロフェッショナルなショーケースでは、必ずカスタムドメインを使用します。

• myapp.com — ショーケースをメインサイトにし、アプリを app.myapp.com に配置します
• www.myapp.com → ショーケース、app.myapp.com → 実際のアプリ

お問い合わせフォーム

ショーケースにはすべて、関心を持った人が連絡できる手段が必要です。「メールでお問い合わせください」と書くだけでなく、実際のフォームを追加します。

パターン 1：Formspree / Formsubmit（バックエンド不要）

<form action="https://formspree.io/f/YOUR_FORM_ID" method="POST">
  <input type="text" name="name" placeholder="Your name" required>
  <input type="email" name="email" placeholder="Your email" required>
  <textarea name="message" placeholder="Tell us about your needs"></textarea>
  <button type="submit">Get in Touch</button>
</form>

無料プランで、ほとんどのショーケースの問い合わせ件数に対応できます。送信内容はメールに届きます。

パターン 2：Cloudflare Worker エンドポイント

ショーケースが Workers 上にある場合は、/api/enquiry ルートを追加します。

app.post('/api/enquiry', async (c) => {
  const { name, email, message } = await c.req.json();
  // Send via SMTP2Go, Resend, or store in D1
  await sendEmail({ to: '[email protected]', subject: `Enquiry from ${name}`, body: message });
  return c.json({ success: true });
});

パターン 3：Turnstile + メール（スパム対策）

ボットによる送信を防ぐため、Cloudflare Turnstile を追加します。

<div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY"></div>

送信を処理する前に、サーバー側でトークンを検証してください。

フォームに含める項目

項目	必須	理由
名前	はい	個別にフォローアップするため
メールアドレス	はい	返信先
会社名／役職	いいえ。ただしあると便利です	見込み客の条件を確認するため
メッセージ／「お探しのものは何ですか？」	いいえ。ただしあると便利です	返信時の参考情報
電話番号	いいえ	電話での連絡を希望する方もいます

送信後：サンクスページにリダイレクトするか、フォーム内に確認メッセージを表示します。何も通知せずにフォームをリセットするだけにしないでください。

追加で生成を検討したいページ

ページ	含める場合	内容
料金	料金が決まっている場合	プランカード、機能比較、請求に関する FAQ
概要	製品にストーリーがある場合	開発者、開発の理由、これまでの歩み（jez-voice と組み合わせます）
変更履歴	リリース済みの製品の場合	最近の更新情報を掲載し、製品が継続的に開発されていることを示します
ドキュメントへのリンク	app-docs がある場合	/app-docs で生成されたユーザーガイドへのリンク
ブログ／記事	コンテンツがある場合	ニュースレターのアーカイブや製品に関するブログ記事へのリンク
プライバシー／利用規約	常に	プレースホルダーでも、信頼性を示します
ステータスページ	SaaS の場合	稼働状況のモニタリングへのリンク（Cloudflare のヘルスチェック）

SEO の基本

すべての紹介ページに次の要素を含めます。

<title>[App Name] — [Tagline]</title>
<meta name="description" content="[One sentence value proposition]">
<meta property="og:title" content="[App Name]">
<meta property="og:description" content="[Value proposition]">
<meta property="og:image" content="screenshots/hero.png">
<link rel="canonical" href="https://myapp.com/">

複数ページの場合、各ページにそれぞれのタイトルと説明を設定します。すべてのページで同じメタデータを使わないでください。

特定の地域を対象とする製品の JSON-LD には、seo-local-business スキルを使用します。

品質ルール

1. 実際にある機能だけをスクリーンショットにする — アプリにない機能を作り上げないでください
2. 最適なスクリーンショットを選ぶ — すべてのページが紹介にふさわしいとは限りません。製品のストーリーが伝わるものを選んでください
3. メリットを中心に文章を書く — 「連絡先一覧ページ」ではなく、「すべての連絡先を一か所で確認できます」
4. 架空の推薦コメントを載せない — 提供されていない場合は、そのセクションを省略してください
5. 統計を作り上げない — 実データがない場合は、統計ブロックを空欄にしてください
6. 実際の URL にデプロイする — ローカルファイルのままにしないでください。紹介ページは共有できる必要があります