例ベース学習ツールのためのウェブサイト構築ガイド

対象と成果、サイトの目的を明確にする

ページを設計したりコピーを書く前に、サイトが誰のためで、訪問者が何を達成したいか、あなたが次に何をさせたいかを決めてください。これが曖昧だと、例ベースのツールは「デモの寄せ集め」に見えて学習プロダクトとして伝わりません。

主な対象を1つ選び（次点も明記する）

サイトを最適化するために一つの主要ターゲットを決めます：

• 学生： “これで課題を終わらせたり概念を理解できますか？”
• プロフェッショナル： “職場でスキルを応用しミスを避けられますか？”
• 教育者： “カリキュラムに合い、準備時間を節約できますか？”

その後、次点の対象と彼らが含まれていると感じるために必要な情報を短く書き出します（通常は短いセクション）。その対象のトップ5の質問を彼らの言葉で書き出しましょう。これらの質問はナビラベル、セクション見出し、FAQのプロンプトになります。

コアのやるべき仕事（jobs-to-be-done）を定義する

例ベース学習は、訪問者が自分の持っている仕事にすぐ結びつけられると効果的です。よくあるジョブ：

• 速く学ぶ：正しい答えとその理由を見て学ぶ
• 練習する：バリエーションでパターンを定着させる
• 比較する：「良い vs より良い」を比べてトレードオフを理解する
• 詰まりを解消する：次のステップがわからないときの支援

それぞれを平易な成果文にします（例：「10分で効果的なクライアント向けメールを書く」は「コミュニケーションを改善する」よりも具体的で好ましい）。

1〜2の主要コンバージョンを選ぶ

バイヤーと販売サイクルに合うアクションを選びます：

• Start free（セルフサーブツール向け）
• Book a demo（チーム、学校、高価格帯）
• Join waitlist（プレローンチや限定アクセス）

すべてのページはその主要アクションをサポートするように設計し、二次的な選択肢は摩擦を減らす場合のみ用意します。

成功指標と「10秒での証明」を設定する

最初から追う3–5の指標を定義します：サインアップ率、アクティベーション（最初の意味のある例の完了）、トライアル→有料、必要ならデモ→成約など。

最後に、「例を通じて教える」ことが10秒以内に何を証明すべきかを決めます。良いテストは、ホームページを一瞥して次の3点に即答できるかです：

1. ここで何が学べるか？

2. 例はどんな見た目か？

3. 次に何をすべきか？

ポジショニング：ツールが何をして、なぜ効くか

ポジショニングはツールが「何であるか」ではなく、使った後に訪問者が「何を得られるか」を伝えるべきです。マーケティング臭が強くならない、同僚にそのまま言える一文を目指しましょう。

1文のバリュープロポジション（成果優先）

「実例を学ぶことで速く学び、次のタスクで自信を持ってスキルを応用できるようにする。」

名詞（「より良いメールを書く」「代数を解く」「プロンプトを設計する」）は調整できますが、構造は維持してください：学ぶ（速さ）→ 実例を通して → 自信を持って応用 → 実際の状況で使える。

なぜ“例”は説明より強いのか（対象別）

説明は既に文脈がある人には有効ですが、多くの学習者は文脈を持ちません。例は推測を減らし次を示します：

• 「良い」とは何かが分かる（抽象的ルールではなく具体的な目標）
• 決定がどう行われるか（結果の背後のパターン）
• どう適応するか（一つの正解ではなく変化の仕方）

忙しい学習者（学生、新入社員、プロ）は、理論から行動に翻訳する時間を短縮したいので、例は特に有効です。

サイト全体で繰り返す3つの主要メッセージ

ヒーロー、サブヘッド、コールアウト、FAQで一貫して使える3つのメッセージを用意します。各メッセージには示すべき証拠タイプを用意してください。

1. 速さ（Speed）: 「数分で使える答えにたどり着く。」
   証拠：初回結果までの時間指標、オンボーディングのスクリーンショット、短いデモ動画。

2. 明瞭さ（Clarity）: 「ルールだけでなくパターンが見える。」
   証拠：ビフォー/アフターの例ペア、注釈付き例、サンプルレッスンページ。

3. 自信（Confidence）: 「単にコピーするのではなく、新しいケースに対応できる。」
   証拠：学習者の引用、小さなケーススタディ、完了率／リターン率の傾向。

主要な反論と最も簡潔な反論メッセージ

反論: 「例ベースだと人はただコピーするだけでは？」

反論への応答: 「転移を教える、コピーさせない—各例には短いテイクアウェイと“試してみる”バリエーションをつけ、学習者が適応して練習する設計です。」

「なぜ今なのか」をさりげなく示す

仕事や教育は実用的なアウトプット（メッセージ、解決策、プロジェクト）を求める傾向が強まり、深い学習に割ける時間は減っています。実例で示してパターンを理解させるサイトは、短時間で成果を出す学習スタイルに合致します。

情報設計（IA）とページマップ

明確なIAは訪問者にツールを数分で理解させ、戻ってきた学習者が練習にすぐ戻れるようにします。例ベースのツールでは「何ができるか」「どう動くか」「例の所在」を強調する構造が望ましいです。

初期に用意すべきコアページ

最初のバージョンはシンプルに：

• Home: 価値の簡潔な声明、代表的な例、主要CTAは /signup
• How it Works: メソッドをステップで説明し、「try one」への短いCTAで /examples に誘導
• Examples: メインの学習先（ライブラリ、テンプレ、レッスン）
• Pricing: パッケージ、制限、各プランが誰向けか（/pricing）
• FAQ: よくある疑問への回答（難易度、所要時間、学習アウトプット）
• Contact: サポートや営業問合せ（軽量なフォーム）

コンテンツを公開する場合は Blog/Learning Hub を後から追加し、最初のナビゲーションには入れない方が良い場合が多いです。

「Examples」が意味するものを定義する

「Examples」は次の3つの一般的なモデルで構成できます：

1. 検索可能なライブラリ（トピック、レベル、形式で閲覧）
2. テンプレート（コピペして埋めて適応）
3. ガイド付きレッスン（チェックポイント付きのパス）

1つを主要モデルに選び、必要なら他をフィルターやビューでサポートしてください。三つを同等に混ぜると混乱します。

ナビゲーションのラベルはユーザー意図に合わせる

人がすでに理解しているラベルを使いましょう。Examples, Templates, Lessons, Pricing, FAQ は内部の専門用語（「Workbench」や「Engine」）より明快です。ブランド用語を使う場合は、必ず説明を添えてください（例：「Examples（Library）」）。

ペルソナごとのユーザーパスをマップする

主に2つのパスを作ります：

• 新規訪問者: Home → How it Works → Example preview → /pricing または /signup
• 再来訪学習者: Home（または直接）→ /examples（フィルタ済み）→ 続きを学習

ページマップは両者を分かりやすくし、一貫したCTAで /examples、/pricing、/signup に誘導するべきです。

ホームページ設計（例を強調する）

ホームページの役割は一つ：訪問者が得られる成果を理解させ、それを実例で短時間に証明すること。例を教えるツールなら、最初のスクリーンで例ページのような感触を与えるべきです。

ヒーロー：成果を先に、手段は後で

学習結果に紐づく明確な約束をヘッドラインに置き、続けて仕組みを一行で説明します。

例の構成：

• Headline: “実例で学ぶプロダクトメールの書き方” のように成果を提示
• One-liner: 「例を選び、似た課題を練習し、何が変わったか指摘される」
• Primary CTA: 「Browse examples」（/examples へ）
• 任意の副次CTA: 「See pricing」（/pricing へ）

クイックプレビュー：実際の例カード（抽象的なスクショではない）

ヒーロー直下にクリック可能な2–3枚のカードを置き、実際に使う見た目を見せます。各カードに：

• タイトル + スキルタグ（例：「顧客への謝罪 — トーン修正」）
• 1–2行のプレビュー
• 「What you’ll learn」の短いヒント（一言）

これで訪問者は数秒で適合性を判断できます。

「How it works in 3 steps」（具体的にする）

学習ループに合わせた短いブロック：

1. See example — 良い例を注釈付きで見る

2. Practice — テンプレートやプロンプトで類似課題を試す

3. Feedback — 具体的な指摘と改善版を比較する

各ステップは1–2行で一目で読めるようにします。

比較：ツール vs ランダムな検索

シンプルな比較セクションを入れ、結果に焦点を当てます：構造化された進行、一貫した品質、練習→フィードバックの短さ。

最後は焦点を絞ったCTAで閉じる

一つの明確な次のステップで締め、二つのリンクを置きます：「Start with examples」（/examples）と「View plans」（/pricing）。学習から注意をそらす余計なオファーは避けます。

How-It-Worksページ：メソッドを明快なステップにする

強いHow-It-Worksページは学習の仕組みを予測可能に感じさせます：ユーザーは何が起きるか、何をするか、最後に何が得られるかがわかるべきです。ステップベースで、具体的なウォークスルーを中心に据えます。

単純なフロー（全体を4–5ステップで）

短いステッパー（アイコンや番号）で学習ループを示します：

1. スキルやトピックを選ぶ

2. 作業済みの例を学ぶ

3. 近接バリエーションを試す

4. ヒントとチェックを受ける

5. 結果に応じて次のステップをロック解除

各ステップは一文で、下に「なぜそれが有効か」を平易に説明する行を付けます。

具体的なウォークスルー（現実味を持たせる）

フローを端から端まで示すミニケーススタディを入れます。例の構成：

• Goal: 「1変数の方程式を解く」
• Example: 注釈付きの完全な作業例（単に答えだけでなく手順を示す）
• Variations: 3–5問の類似問題で一度に一部を変える
• Hints: 段階的に開示可能なプロンプト
• Checks: 誤りを説明するクイックセルフチェックや自動チェック
• Next steps: 「正解ならXに挑戦、違えばYを復習」

このセクションはプロダクトのプレビューのように見せるべきで、ただのマーケティング文ではありません。

ユーザーに与えるもの（成果物を明記）

含まれるものを明確に書きます：厳選された例セット、バリエーション、ヒント、正誤チェック、推奨される次の例など。トラッキングがあるなら何を追うか（進捗、連続記録、習得スコア）と何を追わないかを明示します。

トピック、レベル、今後の予定

サポートしている科目／レベルを一つの凝縮したブロックで示し、確信がある場合のみ「Coming soon」欄を小さく付けます。日時の約束はしないでください。

最初の勝利までの時間 + CTA

「Time to first win」 のコールアウトを追加：「約3分で学習開始：トピックを選ぶ → 最初の例を開く → 1つのバリエーションを試す」。

主CTA（「Start learning」）と二次CTA：See the examples を置きます。

プロトタイプを素早く回すなら、Koder.ai のようなツールでReactベースのマーケティングサイトと動く例ライブラリをチャット駆動で立ち上げられます。IAやCTAを検証するプロトタイプ作成に有用です。

ブラウズ・検索可能な例ライブラリを構築する

訪問者が「自分に近い例」を数秒で見つけられると、例ベースのツールは劇的に有用になります。例ライブラリをブログカテゴリではなくプロダクト機能として扱ってください。

実際の意図に合うカテゴリとフィルターから始める

ユーザーが自然に求める3–6のトップレベルカテゴリを選び、結果を適切に絞る小さなフィルター群を用意します。

有効な一般的フィルター：

• Skill/topic（例：「メールライティング」「代数」「カスタマー発見」）
• Difficulty（Beginner / Intermediate / Advanced）
• Format（Worked example, annotated sample, checklist, prompt）
• Use case（宿題サポート、転職活動、営業アプローチ、試験対策）

デスクトップではフィルターを目立たせ、モバイルではコンパクトに（「Filter」ボタンでパネルを開く）します。

標準的な例ページテンプレートを使う

一貫性があれば人は速くスキャンできます。公開をスケールする時もテンプレートが役立ちます。

単純な構成：

1. Problem：学習者がやろうとしていること（制約と状況）

2. Example：モデルとなる答え／出力（明確にフォーマット）

3. Variation：結果に影響する一つの変更（違いを示す）

4. Practice：短いプロンプト／演習と「セルフチェック」的なヒント

深い学びのための「比較」UIを追加する

パターンが明確になるのは比較のときです。低コストで実装できる選択肢：

• サイドバイサイドのカードで2つの例を比較
• タブ（Example A / Example B）
• 差分をハイライトするトグル（変更箇所を強調）

学習パスを作る内部リンク（SEOにも寄与）

各例の下に「関連例」と「次のステップ」（例：「同じスキルの上級」や「同じユースケースの別形式」）を置きます。ページはスキャンしやすく保ちつつ、インデックス可能なテキスト（短いイントロ、明確な見出し、簡潔な説明）を含めて、検索エンジンと学習者の両方に内容を伝えます。

コンテンツ戦略：トピック、テンプレート、編集ワークフロー

例ライブラリが増えても“教える”感が保たれるように、何を公開するか、どのように見せるか、どう保守するかを決めるコンテンツ戦略が必要です。

コーナーストーンとなるトピックを選び、それを軸にクラスターを作る

まず3–5のコーナーストーントピックを選びます。各コーナーストーンはハブになり、単純から複雑へ進む例群でクラスタリングします。

各コーナーストーンごとに計画するもの：

• スターター例（速い勝利と共通パターン）
• バリエーション（同じ考えの異なる制約）
• ミスと修正（やってはいけないこととその理由）
• 実世界のシナリオ（業界や役割特化の例）

この構造はブラウジングを容易にし、無作為なキーワード追求に走らないSEOの階層を与えます。

どの例も教えられるように品質ルールを決める

チームが従える実行可能な基準を書き出します。強いルールは通常：

• 一貫した構造（読者がどこを見ればよいかすぐ分かる）
• 実世界の文脈（誰のための何の状況か）
• 明確なテイクアウェイ（何をコピーすべきか、何を変えるべきか、なぜ）

エディタの上部にシンプルなチェックリストを置くだけでも大きな効果があります。

軽量のテンプレート（速さを担保しつつ均質化を避ける）

テンプレートは白紙恐怖を減らしますが、ニュアンスの余地は残すべきです。実用的な例テンプレート：

1. タイトル + ユースケース

2. その例本体（学ぶべき“もの”）

3. なぜ有効か（2–4箇条）

4. バリエーションを試す（一つのガイド付き変更）

5. よくある落とし穴

6. 次のステップ（関連例へのリンク）

コンテンツ内にCTAを入れるのが理想です。例としてバリエーションの直後に “Try this variation” を置き /signup にリンクします。

編集ワークフロー：公開頻度、責任、更新

執筆、レビュー、保守の各ステップの責任者を決めます。小さいチームでも明確な頻度（週次または隔週）と軽量の更新ルール（例：「上位ページは四半期ごとに見直す」）があると良いです。例が変わったら、何がいつ変わったかを記録しておきます。

拡大する場合は、新規公開よりもまず既存の読まれているページを更新する優先度を高くしてください。

例ベース学習の料金とパッケージング

価格設定は学習設計の一部です：どのように始め、どこまで進め、各レベルで「成功」がどう見えるかを示します。例ベースのツールでは、例へのアクセス、学習パス、共有機能を軸にパッケージ化します。プランの説明は購入者が初日に何を得るか予測できるほど具体的にします。

モデルを選び、含まれる内容を定義する

例ベース製品の多くはサブスクリプションが合います（更新と新規例は継続的な利点）。チーム向けには共有ライブラリのオプションが必要です。

プランの箇条書きには具体的な包含項目名を使います：例コレクション数、保存フォルダ、エクスポート、テンプレート、新規例の含有有無など。

各プランは誰向けかを示す

ラベルは平易で成果重視にします：

• Starter（初心者）: メソッドを試す向け、厳選された例セット
• Pro（個人プロ）: 定常利用向け—フルライブラリ、高度な検索／フィルター、保存ワークフロー
• Team / Education: 共有ワークスペース、シート、管理者権限、クラス共有機能

無料トライアルがある場合は、トライアルで何が解放されるかと終了時に何が起こるかを明確にしてください。

料金ページ下のFAQで摩擦を減らす

表の下に短いFAQを置き、よくあるブロッカーに答えます：

• 請求サイクル、解約、請求書発行
• 解約後のアクセス（読み取り専用か完全に失うか）
• 更新と新規例の取り扱い
• チームの席数変更

購入・トライアル後に何が起きるか

初回の流れを明確に：確認メール → アカウント作成 → 短いオンボーディング → 「最初の例セットで始める」。

「最初の勝利までの時間」（例：「3分で最初の保存例を得る」）を明記します。ヘッダーや主要ページ（ホーム、例ライブラリ、How it Works）から**/pricing**へリンクを張り、税や追加料金、席の制限などはプラン詳細に明示して驚きがないようにします。

信頼、証拠、過大な約束を避けたFAQ

教育ツールは、安心感、信頼性、時間対効果が短時間で判断されます。完璧な結果を約束するのではなく、真実で具体的、再現可能なことを示してください。

実際に支えられる信頼要素

誇張した表現を避け、リスク低減に役立つ軽量な信頼要素を追加します：プライバシーの簡潔な説明、基本的なセキュリティ対策（転送中の暗号化、アカウント保護）、サポートオプション。もし稼働状況ページがあればリンク（/status、/changelog）、なければ作らないでください。

列挙例：

• データ取り扱いの基本（保存するものとしないもの）
• サポートチャネル（メール、チャット、コミュニティ）
• 請求の明確さ（いつでもキャンセル、必要なら返金）
• ステータス／変更履歴ページ（例：/status、/changelog）

実感のある推薦文とミニケーススタディ

成果と具体的な「例の瞬間（example moment）」を含む推薦文を求めます。曖昧な「学びが速くなった」ではなく、「Xの作業済み例でパターンが腑に落ち、Yのミスが減った」のような具体性を狙います。

ベストストーリーはミニケーススタディに変換：

• Before: 学習者が詰まっていた点
• What changed: どの例やパスを使ったか
• After: 測れる進展（時間短縮、テストの改善、試行回数の減少）

主張は控えめに：「助けになった」等の表現を使います。

限界を含めたFAQ

ツールがしないこともはっきり書く（例：教師の代替にはならない、開放的な作文を採点しない、すべてのカリキュラムを網羅しない）。価格やデータ、例の出所についての実務的な質問も含めます。

最後に明確な連絡経路（/contact）と、可能なら返信期待値（例：「2営業日以内に返信」）を提示します。

例を学びやすくするデザインとUXパターン

例ベース学習の良いUXは派手なビジュアルよりも、パターンを気付きやすく、比較しやすく、記憶しやすくすることにあります。

コンテンツと喧嘩しないタイポグラフィを選ぶ

明確な階層（H1/H2/H3、本文、キャプション）を持つクリーンなタイポセットを選びます。コード、数式、図が含まれる場合は早めにテスト：等幅フォントのコードブロックは読みやすく、インライン数式は行間を崩さないように、図は十分な余白を持たせます。行長は快適にし、長文説明には段落間隔を広めにとります。

再利用可能な「学習コンポーネント」を作る

例が一貫していればスキャンが容易になります。繰り返し使える小さなコンポーネント群を設計します：

• Example cards：タイトル、難易度、所要時間、タグ、一行のテイクアウェイ
• Callouts：「よくある間違い」「なぜこれが有効か」「自分で試す」
• Step blocks：番号付きステップで一つの行動ごとに分ける
• Practice blocks：プロンプト＋開示式の解答

一貫性は認知負荷を減らし、ブラウジングを予測可能にします。

アクセシビリティは学習の一部

強いカラ―コントラスト、フォーカス状態の可視化、フィルター／検索のキーボード操作、論理的な見出し構造を確保します。教育図像には代替テキストを必ず付け、図が伝える学習ポイントを書くようにしてください。

モバイルファースト：読みやすさと比較を最適化

モバイルでは比較が難しくなります。粘着（sticky）な「主要なテイクアウェイ」要約、折りたたみセクション、クイックジャンプ（「Problem → Example → Explanation → Practice」）を使ってください。サイドバイサイドはモバイルでは避けるべきです。

CTAは一貫して低摩擦に

主要CTAラベルを一つ決め（例：「Try an example」）同じボタンスタイルと遷移先を使い回します。ガイド付きパスがあるなら常に同じオンボーディングフロー（例：/start）にリンクして、ユーザーがボタンの先で迷わないようにします。

例ページと学習ハブのためのSEOプラン

SEOは人々が具体的な例や手順を探す検索行動に合わせると効果的です。ユーザーのクエリが有益なページに着地するようサイトを構築し、製品へ誘導します。

キーワード戦略：「…の例」や「〜のやり方」を狙う

トピッククラスタ（ライティング、数学、プロンプト、メール、授業案など）を作り、各クラスタで主に2つの検索タイプを優先します：

• 「…の例」（比較・参照の意図が強い）
• 「〜のやり方」（方法を学びたい意図）

各クラスタにハブページ（learning hub）と、狭めのフレーズを狙う複数の例ページを用意します。

URL、カテゴリ、パンくずリスト

ユーザーと検索エンジンに分かりやすい構造にします：

• ハブ: /examples/<topic>
• 例ページ: /examples/<topic>/<example-name>
• ガイド: /guides/<topic>/<how-to>

ハブと例ページにはパンくずを入れてナビゲーションと検索スニペットを改善します。

構造化データ（schema）は正しく使う

ページ内容と合う場合のみschemaを追加：

• 実際にFAQがあるページには FAQPage
• ガイドページには Article（または BlogPosting）

すべてをFAQでマークアップしすぎないように。検索エンジンは冗長なマークアップを無視する傾向があります。

教えつつコンバートさせる内部リンク

各例ページは必ず：

• そのトピックのハブページへリンク
• メソッドを説明するhow toガイドへリンク
• 関連するプロダクトページやCTA（例：/how-it-works）へリンク（“Generate your own examples” のような語り口で）

横方向のリンク（「次の例」）も貼って探索を促します。

パフォーマンス基本：ページを速く保つ

例ライブラリは重くなりがちです。高速化の基本：

• 適切なサイズの画像を出す（可能ならモダンフォーマット）
• 折りたたみより下のメディアは遅延読み込み
• カテゴリページが何百件もロードしないようテンプレートを軽量化（ページネーションや「Load more」を使う）

高速な例ページは離脱を減らし、時間をかけてランキング向上にも寄与します。

ローンチ後の分析、フィードバック、反復

サイトを出すのは学習の始まりです。目的は人々が意図した通りに例を使っているか、どこで離脱しているかを見つけることです。

追うべきイベントは厳選する

学習の意図とプロダクト興味を表すコアイベントを少数定義します：

• View example（例ページが読み込まれ、例が表示された）
• Start practice（演習やプロンプトに着手）
• Compare examples（比較ビューやフィルターを開いた）
• Signup（アカウント作成）
• Upgrade（有料開始）

これらで「人は例を閲覧するが練習しないのか？」や「どのカテゴリが最もサインアップを生むか？」といった実務的な問いに答えられます。

週次で確認できるシンプルなファネルを作る

一つの主要なファネルを作り、チーム全員が見られるようにします：

Landing page → example → signup → activation milestone

活性化マイルストーンは「ダッシュボードを訪れた」ではなく、具体的な学習行動（例：「1つの練習セットを完了」）にしてください。

各例にフィードバックループを入れる

各例の終わりに軽いプロンプトを置きます：

「この例は役に立ちましたか？」（Yes/No）＋任意のテキスト欄：「もっと分かりやすくするには？」

これをプロダクト入力として扱い、月次でテーマを集計してライブラリを改善します。

小さく安全なA/Bテストで反復する

体験を壊さないシンプルなテストを回します：

• ホームのヘッドライン文言
• 最初に表示する「ヒーロー例」
• CTA文言（例：「Try an example」対「Start practicing」）

これらを速く回すには、Koder.aiのようなチャットファーストのビルドワークフローが、UIの小変更を素早く出してロールバックできるので便利です。

チェックリスト：ローンチと月次メンテナンス

ローンチチェックリスト（イベントが飛んでいるか、ファネルが見えるか、フィードバックが有効か）を作り、その後は月次チェックリストで（長文ガイドなら約3,000語）スクリーンショット更新、リンク検証、例の更新、SEOハブの検索クエリ見直し（参照：/blog/seo-plan）を回します。