ユースケースページ：構造と例

SEO投稿タイプシステムにおいて、ユースケースページとは、読者が完了する必要のあるひとつのジョブを中心に構築された商用ページです。その目的は、読者が自分の状況を認識し、その正確なジョブを実行するプロダクトを確認し、セットアップと想定される結果を理解し、行動に移すかどうかを決定できるようにすることです。

読者の質問：「このプロダクトは私の特定の状況に対応できるのか？実際にこれを使って作業を行うと、具体的にどのようになるのか？」

このページは「翻訳ステップ」を排除します。購入者に機能を自社のプロセスにマッピングするよう求めるのではなく、彼らの言葉で始まり、ワークフローを実演し、その道筋が存在することを証明します。

回答する質問

ユースケースの意図は、プロダクトの機能一覧の要求ではなく、実用的な不確実性として表現されます。ページは以下のような質問に答える必要があります。

• 「競合が出現しているが自社ブランドが出現していないプロンプトを見つけられますか？」
• 「現在使用しているスプレッドシートや繰り返しの手動チェックを置き換えるにはどうすればよいですか？」
• 「このワークフローを機能させるために、何を接続する必要がありますか？」
• 「どの部分が自動化され、どの意思決定にまだ人が必要ですか？」
• 「プロセスが成功したとき、何が見えるようになりますか？」

まずは狭いジョブに答えてください。引用ギャップのモニタリングを解決しようとしている訪問者には、すべての分析機能のツアーではなく、インプット、順序、アウトプット、意思決定が必要です。広がりは後で隣接するユースケースを通じて示します。

この投稿タイプを使用するタイミング

機能、オーディエンス、ジョブ、証拠はそれぞれ異なる整理概念であるため、タクソノミーが重要です。これらを混在させると、重複するページが同じクエリを競合しながら、どれも完全には答えられなくなります。

AmICitedはすでに 機能と、 SaaSソリューションなどのオーディエンス主導のページを分離しています。そのアーキテクチャを維持してください。機能は機能名詞で命名し、ソリューションはオーディエンスまたはモデル向けに、ユースケースは動詞と目的語で命名します。/features/と/solutions/は既存の意味のために予約し、ユースケースは別途承認されたコレクションに配置します。

ユースケースは、そのワークフローを可能にする少数の機能にリンクします。機能は複数のジョブにリンクし、ソリューションはそのオーディエンス向けにジョブをキュレーションします。3つすべてで同じヒーロー、ワークフロー、CTAを再利用することは、タクソノミーではなく重複です。

最適なビジネスタイプ

ランキングは、プロダクトまたはサービスが機能と実際のジョブの間の目に見えるギャップをどの程度頻繁に埋める必要があるかを反映しています。これは優先順位付けのガイドであり、ランクの低いモデルが利益を得られないという主張ではありません。

1. SaaS。 購入者は、どの機能が繰り返し発生するジョブを完了するのか、何を最初に接続するのか、どのアウトプットが自社のプロセスに入るのかを確認する必要があります。インターフェースの証拠が、利用可能なパスと機能の主張を区別します。
2. B2Bサービス。 デリバリーは通常、クライアントのインプット、専門家の判断、レビュー、引き継ぎを組み合わせます。このページは、作業が自動化されているふりをすることなく、抽象的な約束を範囲限定のエンゲージメントに変換します。
3. Eコマース。 ユースケースは、小さなワークスペースの装備など、カテゴリをまたぐことができます。カテゴリのブラウジングとは区別し、互換性、制約、購入経路を示します。
4. マーケットプレイス。 供給と需要のニーズを混在させずに、ある参加者のジョブ（資格のあるサプライヤーの発見、直前のキャパシティの補充など）を明確にします。
5. ローカルサービス。 ジョブに明確なトリガー、評価、準備、予約経路がある場合に公開します。「ボイラー故障後の暖房復旧」は該当しますが「ブリストルの配管工」はサービス＆ロケーションページです。
6. メディアパブリッシャーとアフィリエイト。 ファーストパーティのオーディエンスセグメントからキャンペーンを構築するなど、実在のプラットフォームや広告主のワークフローを実演できる場合にのみ公開します。

検索インテント

主要なインテントは商業調査です。読者は問題を理解し、解決方法をテストしています。検索結果には通常、ベンダーのユースケース、ジョブに基づく機能、ワークフローガイド、顧客事例が混在しています。AI回答はこれらを方法、ツール、注意事項に圧縮します。ページをジャーニーとして、また抽出可能な単位（状況、ワークフロー、前提条件、アウトプット、制限、証拠）として一貫性のあるものにします。

認知を第一に、仕組みを第二に、証拠を第三にします：

1. トリガーと失敗した現在のアプローチを用いて状況を述べます。
2. 直接的な回答を示します：プロダクトが何を変え、誰にとって変えるのか。
3. 人間とプロダクトの責任を分離した、改善前と改善後のワークフローを示します。
4. 実際のインターフェースを実演し、アウトプットを明示します。
5. セットアップ、期待される最初の価値、制限、証拠を説明します。
6. 実演したワークフローを再現する次のアクションを提供します。

クエリ、日付、ロケール、サインイン状態を記録します。キャプチャはレビュー時点での回答の形状を文書化するものであり、ランキングを固定するものではありません。

ページ構造

語数範囲は割合をコントロールするものであり、埋め草ではありません。状況は短く、証拠は信頼できる十分な長さにします。

通常の総語数は1,800〜3,000語です。3,500語を超える場合は複数のジョブがないか確認し、1,200語未満の場合はワークフロー、証拠、期待値の欠落がないか確認します。

必須要素

要素がユースケース固有のコンテンツを含む場合でも、確立された要素コントラクトを使用します。これによりページの移植性が保たれ、一回限りのブロックがサイトの制作ルールから逸脱するのを防ぎます。

状況ブロック、結果バンド、顧客の声はこの構造内でのコンテンツロールであり、未登録のショートコードを作成するための許可ではありません。再利用可能な要素が承認されるまでは、既存のページプリミティブでレンダリングします。

フロントマター

entity は use-case-<動詞-目的語> に設定します。動詞と目的語は、プロダクトの機能やオーディエンスではなく、ジョブを説明するものにします。例としては use-case-monitor-competitor-citations や use-case-prioritize-content-refreshes などがあります。見出しが変更されても値は安定している必要があります。

必須フィールドは、title、seoTitle、entity、url、description、keywords、type、date、playbookPillar、playbookFamily、journeyStage、elements、businessTypes、playbookWave、および本文で使用されるリンクレコードです。規定のキャプチャがコメントのままである間は screenshotsPending = true を追加します。プロダクト領域、ワークフロー所有者、証拠所有者、証拠確認日、主要なコンバージョンイベントを、実装で使用されるコンテンツモデルに記録します（これらのガバナンスフィールドが表示されない場合でも）。

商用ページの安全なスキーマタイプとして WebPage を使用します。表示テキストが必要なプロダクトIDを提供し、実装が正しくマッピングする場合にのみ Product または SoftwareApplication を追加します。表示されている質問と回答が構造化データと正確に一致し、現在の検索エンジンポリシーが許可する場合にのみ FAQPage を使用します。セットアップ手順が表示されているという理由だけで HowTo を使用しないでください。ワークフローのデモンストレーションは完全な指示手順ではありません。実際の資格質問から抽出した5〜7個のFAQを使用し、デフォルトは6個とします。

完全な例

このコピー準備済みのスケルトンは「競合が引用されていて自社ブランドが存在しないプロンプトを見つける」をカバーしています。見出しは公開可能です。括弧内のテキストは範囲指定された置換指示を示します。

# 競合が引用され、自社ブランドが存在しないAIプロンプトを見つける

どの購買質問が競合ドメインを引用し、自社を引用していないかを確認し、最も明確なギャップを優先順位付けされたコンテンツワークフローに移します。

## 自社ブランドが欠落している場所で競合が引用されていますか？

[手動の週次レビュー、その断片化された証拠、および意思決定を所有する人物について説明します。]

## 手動の引用ギャップチェックが機能しなくなる理由

[回答のばらつき、メンションと引用の違い、失われた証拠、弱い優先順位付けについて説明します。]

## 直接的な回答

[40〜60語で、プロダクトの変更とアウトプットを述べ、エンジンと追跡頻度によるカバレッジを条件付けます。]

## AmICited導入前と導入後

| 意思決定ポイント | 導入前 | AmICited導入後 |
|---|---|---|
| 回答を収集 | プロンプトを手動で実行し、出力を貼り付け | スケジュールされた追跡回答をひとつのレポートで確認 |
| ギャップを特定 | 各回答でブランド名と競合名を検索 | ブランド、競合、引用状態でプロンプトをフィルタリング |
| 証拠を検証 | プロンプトを再実行し、回答が一致することを期待 | 保存された回答と引用ソースを開く |
| アクションを選択 | どの見落としが最も重要かを議論 | ジョブの関連性、再発性、ソースの機会で優先順位付け |

## 引用ギャップワークフローの仕組み

1. ひとつの購入者ジョブを表すプロンプトグループを選択します。
2. 名前付き競合が出現し、自社ブランドが出現しない回答にフィルタリングします。
3. 各回答を開き、ブランドメンションとリンク付き引用を区別します。
4. 引用ソースを調査し、その回答を自分が所有する最適な関連ページと比較します。
5. コンテンツ更新、新規ページ、デジタルPRアクション、または理由付きのアクションなしの意思決定を割り当てます。

## ワークフローを設定する

[前提条件を明記します。各ステップにアクション、可視化可能な成功状態、復旧パスを提供します。]

## 期待できること

[最初の有用なアウトプット、回答の変動性、依存関係、および人間の判断が依然として必要な箇所を定義します。]

## 実際のワークフローからの証拠

[ここに、altテキスト、キャプチャ日付、画面識別子、説明用凡例を含む焦点を絞ったワークフロースクリーンショットを配置します。]

## 結果と制限

[ベースライン、期間、単位、ソースを含む検証済みの結果を提示します。利用可能な場合は、承認済みの正確なジョブの顧客証拠と制限を追加します。]

## 関連ユースケース

[トリガーまたはアウトプットが異なる2〜3の公開済みジョブにリンクし、それぞれの違いを説明します。]

## FAQ
[ワークフローを繰り返さずに、カバレッジ、セットアップ、証拠、測定に関する実際の質問に答えます。]

## 最初の引用ギャップを見つける

[関連するプロンプトセットを開くまたは作成するひとつのプロダクトアクションと、ひとつの結果リンクを提供します。]

デザイン例

すべてのバリアントは同じジョブと証拠を示す必要があり、レビューアーが階層を判断できるようにし、異なる主張に気を取られないようにします。汎用的なダッシュボード、ストックイラスト、無関係なプロダクト領域からのキャプチャは使用しないでください。

品質チェックリスト

ユースケースページは、以下のすべての基準を満たした場合にのみ公開可能です：

• 見出しに、オーディエンスラベルや機能名ではなく、動詞と目的語で表現されたジョブが含まれている。
• 冒頭で、認識可能なトリガー、現在の方法、インプット、摩擦、望ましいアウトプットが示されている。
• 名詞のみを変更した後で、同じコピーが2つの隣接するジョブを説明できない。これが具体性テストです。
• 改善前後の比較で、実際のステップ、担当者、ツール、待機時間、アウトプットが明示されており、「より速く」「より簡単に」だけに依存していない。
• 散文で示されたワークフローが、少なくとも1つの現在のプロダクトスクリーンショットに示されたインターフェースと一致している。
• 自動化と人間の判断が明確に分離されている。
• セットアップに、前提条件、アクション、成功シグナル、安全な復旧パスが含まれている。
• 期待値は、証拠やCTAの前に依存関係と制限を述べている。
• すべての結果に単位、範囲、期間、ソース、確認日がある。すべての顧客引用に承認がある。
• 隣接するユースケースは、単なる異なるキーワード表現ではなく、異なるトリガーまたはアウトプットを持っている。
• CTAは、実演されたジョブまたはその信頼できる評価を開始する。
• 機能、ソリューション、ユースケース、顧客事例の各ページが、それぞれ明確な主要インテントと正規の所有者を保持している。

具体性テストでは、見出しのジョブを2つの関連ジョブに置き換えます。ほとんどの段落がまだ機能する場合、そのドラフトはプロダクトカテゴリを説明しています。固有のトリガー、インプット、順序、画面、アウトプット、障害モードを追加します。

よくある間違い

プロダクトで始める。「当社のプラットフォームがデータを統合します」はほとんどすべてのワークフローに当てはまります。トリガーと不足している証拠から始めてください。

機能をジョブとして扱う。「ダッシュボードを使う」はユースケースではありません。「プロダクト発売後にどの競合が引用を獲得したかを確認する」にはトリガー、アクション、意思決定があります。

**オーディエンスの形容詞を変えるだけ。**SaaS、代理店、Eコマースで同一のステップは、オーディエンスメモ付きのひとつのユースケースを説明しています。ワークフローが変わる場合のみ分割してください。

**汎用的なダッシュボードを表示する。**ジョブを証明するフィルター、回答、ソース、またはアクションをキャプチャしてください。

**ワークフローがコントロールできない成果を約束する。**引用ギャップを監視しても将来の引用は保証されません。コントロール可能なアウトプット（検証済みの優先順位付けされた機会）を述べ、後で可視性を個別に測定します。

汎用的な賞賛を使用する。「素晴らしいサポート」では引用ギャップ分析を証明できません。引用はジョブ、ワークフロー、または範囲限定の結果を検証する必要があります。

**現在形で架空のケーススタディを書く。**複合シナリオは例であり、そのようにラベル付けする必要があります。顧客事例には、名前と承認を得た顧客と追跡可能な証拠が必要です。

**すべての読者を「デモを予約」に送る。**ページがセルフサービスのワークフローを実演している場合、主要なアクションはそれを開始するものにします。セットアップ、セキュリティ、移行、調達に本当に必要な場合にのみ、営業での会話を使用します。

内部リンク

ユースケースページは、ワークフローに必要な最小限の機能、ひとつの関連するオーディエンスソリューション、正確なジョブの証拠、2〜3の明確に異なる隣接ユースケースにリンクします。機能リンクはそのステップの隣に、証拠はその主張の隣に、関連ユースケースは主要ジョブの後に配置します。

機能ページは有効になるジョブにリンクし、ソリューションページはそのオーディエンス向けにジョブをキュレーションします。ガイドは、読者が理解からプロダクト評価に移行するときにリンクします。顧客事例は、その証拠がジョブを検証する場合にのみリンクを戻します。

同じ主要クエリを機能ページとユースケースページでターゲットにしないでください。ソリューションページで完全なワークフローを繰り返さないでください。ユースケースページを、ひとりの顧客の時系列を中心にした過去形の ケーススタディにしないでください。コンテンツマップで正規の所有者を明示的にします：機能は機能ページに、オーディエンスはソリューションページに、ジョブはユースケースページに、過去の証拠は顧客事例に属します。

結果の測定方法

ページが生み出すように設計されたチェーンを測定します：ジョブ形式のプロンプトに対する可視性、正確なブランドの包含、意図したURLの引用、ワークフロー証明を通じたエンゲージメントのある移動、ページの主要アクションの完了。公開前に、プロンプトセット、ベースライン、主要URL、コンバージョンイベント、レビュー期間を確立します。

プロンプトトラッキングを使用して、正確なクエリではなく、ジョブの表現、制約、類義語を監視します。 ソース・引用インテリジェンスを使用して、回答がこのページを引用し、その制限を維持しているかを検査します。 AmICited Cockpitを開いて、AI可視性、引用URL、オーガニックパフォーマンス、選択したコンバージョンイベントを比較します。 結果の測定方法を適用して、先行指標とビジネス成果を区別します。

成功とは、あらゆるコンテキストでのメンションではありません。ページが意図したジョブに対して表示され、抽出された回答が正しいワークフローを説明し、引用URLがユースケースページまたは意図的に精度の高いサポートページであり、資格のある読者が次のアクションを取るとき、ページは機能しています。機能ページとユースケースページが明確な意図の違いなしに同じクエリで交互に表示される場合は、カニバリゼーションを調査します。

FAQ

ユースケースページとは何ですか？

ユースケースページは、読者が完了する必要のあるひとつのジョブを中心に構成された商用ページです。状況を反映し、現在の困難を説明し、プロダクトのワークフローを示し、期待値を設定し、証拠を提供し、次に取るべき適切なアクションを提示します。

ユースケースページと機能ページの違いは何ですか？

機能ページは、ある機能が何をするかを説明します。ユースケースページは、ひとつのジョブを完了するために必要な機能を組み合わせ、読者の文脈でワークフローを説明します。ひとつの機能が複数のユースケースをサポートすることも、ひとつのユースケースが複数の機能を必要とすることもあります。

ユースケースページとソリューションページの違いは何ですか？

ソリューションページは、オーディエンス、業界、ビジネスモデルを中心に構成され、複数のジョブをカバーすることがあります。ユースケースページは、ひとつのジョブを中心に構成され、状況とワークフローが本質的に同じであれば、複数のオーディエンスにサービスを提供することもあります。

すべてのユースケースページに顧客の声が必要ですか？

いいえ。ただし、すべてのページにプロダクトの証拠が必要です。実際のワークフローのスクリーンショットが最低限必要です。名前と承認を得た顧客の声は、この特定のジョブを検証する場合にのみ追加してください。そうでない場合は、透明性のあるプロダクトデモと範囲を限定した成果の期待値を提示します。

ユースケースはどの程度具体的であるべきですか？

読者が隣接するジョブとは異なるトリガー、インプット、ワークフロー、完了状態を認識できる程度に具体的であるべきです。ジョブ名を他の二つの名前に置き換えても同じコピーが機能する場合、そのページは汎用的すぎます。

ユースケースページはどのスキーマを使用すべきですか？

安全なデフォルトとして WebPage を使用し、表示されるページが必要なプロダクトプロパティをサポートする場合のみ Product または SoftwareApplication を追加し、実装と現在の検索エンジンポリシーが許可する場合のみ FAQPage を追加します。プロダクトワークフローをデモンストレーションするのではなく、完全なタスクを教える場合を除き、ページを HowTo としてマークしないでください。