機能ページ

SEO投稿タイプシステムにおいて、機能ページは1つの製品能力に特化した商業ページです。能力 → メカニズム → 成果 → 証明という厳密な論理で展開します。読者は、その能力が何をするのか、どのように出力を生成するのか、どこに位置づけられるのか、何ができないのか、そして製品が評価に値するのかを知って離脱します。

読者の質問：「この能力は正確に何をするのか、どのように機能するのか、そして必要な成果を生み出すと信頼できるのか？」

機能ページは装飾された機能リストではありません。能力が主題、メカニズムが説明、成果が関連性、証明が信じる理由です。

答えを提供する質問

機能ページの訪問者は通常、少数候補を比較しているか、主張を検証しています。彼らの資格評価の質問に直接答えましょう。

• この能力は正確に一文で何をするのか？
• どのような入力を使用し、どのような出力を生成するのか？
• どのステップが自動、設定可能、または手動か？
• どのような権限、プラン、連携、データソースが必要か？
• 出力の鮮度はどの程度か、何がそれを変化させるのか？
• どのような判断や成果を可能にするのか？
• 最も近いアプローチとどのように異なり、その限界は何か？
• 実際のインターフェースと信頼できるエビデンスを確認できるか？
• この能力が適合する場合、次に何をすべきか？

「強力」などの形容詞をテスト可能なメカニズムに置き換えましょう：「レポートは保存されたプロンプトセットを毎日実行し、各回答を保存し、ブランドの言及とリンク付き引用を区別します。」

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

能力、ジョブ、オーディエンス、オファー、接続、顧客成果のそれぞれに、明確な正規ページと検索プロミスが必要です。

能力が「AI引用追跡」のような持続可能な名詞句を所有でき、明確なメカニズムを持つ場合にのみ機能ページを作成します。小さなオプション、フィルター、エクスポート形式、権限状態は親ページ内に保持します。同じインターフェース、出力、証明、CTAを共有する提案ページは、その意図と購入者の判断が異なる場合を除き統合します。

AmICitedはすでに 機能一覧を維持しています。新しい能力ページはそのアーキテクチャに属し、この仕様に接続するものであり、競合するコレクションを作成するものではありません。プレイブックは制作ルールを定義し、/features/には顧客向けの実装が含まれます。

最適なビジネスタイプ

ランキングは各モデルが個別の実証可能な能力をどの程度自然に販売するかを反映しています。

1. SaaS企業。ソフトウェアは可視的なコントロール、入力、状態、出力を持ち、購入者がアプリに入る前に主張をメカニズムにマッピングできるようにします。
2. エージェンシー。製品化された監査、ポータル、反復可能なリサーチシステムは機能しますが、カスタムデリバリーは関与する人間の専門性を依然として示す必要があります。
3. B2Bサービス。シナリオモデリングのような具体的なサービスコンポーネントに使用し、方法がクライアントごとに変わるエンゲージメントには使用しません。
4. Eコマース。マーケットプレイスや小売業者は、バーチャルフィッティング、補充、下取り、配送枠選択など、購入者向けの機能を説明できます。製品属性は依然として製品ページに属します。
5. マーケットプレイス。信頼チェック、マッチング、アラート、エスクロー、サプライヤーツールは、参加者の役割とサポートされる状態が明示されている場合に該当します。
6. メディアパブリッシャーおよびアフィリエイト。計算機、比較ツール、ウォッチリスト、メンバーリサーチ製品は該当します。編集トピックは引き続き記事またはガイドとします。

検索インテント

支配的なインテントは商業調査です。実装を比較し、カバレッジを確認し、ベンダーの主張がワークフローに一致するかをテストします。クエリは多くの場合、能力とブランド、代替案、連携、オーディエンス、または修飾語を組み合わせます：「AI引用追跡ソフトウェア」や「[製品]はソースを追跡するか」など。

強力な結果は能力と成果を約束し、メカニズムを要約し、ホームページではなく機能ページに着地します。検索結果はベンダーページ、ドキュメント、リスト記事、比較を混在させる可能性があるため、ページは評価と検証を満たす必要があります。

AI回答はカテゴリを定義、ツール、評価基準、注意事項に圧縮します。修飾語を保持した抽出可能な文を書きましょう。

1. 能力を40～60語で定義する。
2. 入力、処理、出力、頻度を明記する。
3. 1つの成果を、保証された結果ではなく、可能になる判断として述べる。
4. プラン、アクセス、データ、カバレッジの制限を関連する主張の横に示す。
5. 一貫した次元で比較をサポートする。
6. インターフェースの証明を最新に保ち、各キャプチャが何を示すかをラベル付けする。

クエリ、ロケール、デバイス、日付、サインイン状態を記録します。キャプチャは恒久的なランキングではなく、その時点の回答の形状を記録します。

ページ構造

約束から定義、メカニズム、エビデンス、制限、判断へと進みます。語数帯は比率を制御するものであり、埋め草ではありません。

ほとんどの機能ページは1,500～2,500語が必要です。3,000語を超えるページは複数の能力または補足ドキュメントを含む可能性があります。

必須要素

各要素は特定の評価リスクを解決します。そのリスクが現れる位置に適用します。

お客様の声、トラストバッジ、動画は条件付きです。これらがメカニズムを隠さずにこの能力を証明できる場合にのみ追加します。

フロントマター

entityをfeature-<能力名>に設定し、キャンペーンフレーズではなく安定した製品能力を使用します。例はfeature-ai-citation-trackingやfeature-content-freshness-monitoringです。見出しが「すべてのソースを知る」から「AI引用を追跡する」に変わっても、エンティティは安定したままです。

必須フィールドはtitle、seoTitle、entity、url、description、keywords、type、date、プレイブック分類、elements、businessTypes、schemaTypes、すべての本文リンクレコード、および5つ以上のFAQレコードです。必須キャプチャがコメントとして残っている間はscreenshotsPending = trueを追加します。また、製品とエビデンスの所有者、スクリーンショット日付、ステータス、プラン可用性、コンバージョンイベント、レビュー頻度を記録します。

安全なスキーマタイプとしてWebPageを使用します。 スキーママークアップは可視エンティティとプロパティを識別しますが、不足しているコンテンツを修復することはできません。表示される事実がマッピングされたプロパティをサポートする場合にのみSoftwareApplicationまたはProductを追加します。可視回答がデータと一致し、現在のポリシーが許可する場合にのみFAQPageを追加します。短いセットアップシーケンスは自動的にHowToにはなりません。

完全な例

このコピペ可能なスケルトンは、AmICitedの能力である AI可視性を使用して、正しい境界を示しています。括弧内の指示は公開前に置き換えが必要なエビデンスを特定します。これらは制作指示であり、公開可能な主張ではありません。

+++
title = "AI可視性追跡"
seoTitle = "主要な回答エンジン全体でのAI可視性追跡"
entity = "feature-ai-visibility-tracking"
url = "/features/ai-visibility-tracking/"
description = "[150～160文字：能力、メカニズム、成果、および1つの意味のある修飾語]"
type = "feature-landing"
date = "2026-08-27 10:00:00"
keywords = [ "AI可視性追跡", "AIブランド可視性", "AI検索モニタリング", "回答エンジン追跡", "AI引用", "AIシェア・オブ・ボイス" ]
schemaTypes = [ "WebPage", "SoftwareApplication", "FAQPage" ]
+++

# AI回答がどこでブランドに言及し引用しているかを追跡する

[35～70語で、能力、対象とする判断、対象ユーザー、正確な製品アクションを明記する。]

## AI回答が自社を選ぶか競合他社を選ぶかを知る

[不確実性を明記する：チームはクリック後のトラフィックを見ることはできるが、回答エンジンがブランドに言及、引用、ランク付け、説明する頻度を推測することはできない。]

## AI可視性追跡の機能

[40～60語で、入力、スケジュール収集メカニズム、出力、エンジンカバレッジ、頻度を定義する。]

## 追跡プロンプトから可視性レポートへ

1. [プロンプトセットを選択または作成し、有効なセットの条件を記載する。]
2. [サポート対象エンジンでプロンプトを実行し、頻度とカバレッジ制限を記載する。]
3. [回答を保存し、言及とリンク付き引用を区別する。]
4. [可視性、順位、シェア・オブ・ボイス、センチメントを集約し、各指標を定義する。]
5. [回答とソースを開き、次に取るべきアクションを判断する。]

## すべての指標の背後にあるエビデンスを見る

[ここにレポートの最新の注釈付きスクリーンショットを配置する。プロンプトセット、日付範囲、エンジンフィルター、指標定義、回答のドリルダウン、引用ソースにマークする。画面がサポートする判断を説明する。]

## 出力を判断に変える

[3つの限定された応用例を示す：不足しているプロンプトを見つける、競合ソースを検査する、コンテンツ公開後の変化を確認する。製品が制御できないランキングや引用を約束しない。]

## ランク追跡単独との違い

| 次元 | AI可視性追跡 | オーガニックランク追跡 |
|---|---|---|
| 主要単位 | [正確に定義] | [正確に定義] |
| 保存されるエビデンス | [回答、言及、引用、ソース] | [結果の位置とURL] |
| 最適な判断 | [可能になる判断] | [可能になる判断] |
| 重要な制限 | [1つ記載] | [1つ記載] |

## セットアップと要件

[ドメイン、ブランド、競合他社、プロンプト、エンジン、アクセス、プラン、処理要件を記載する。各セットアップステップの可視的な成功状態と回復パスを示す。]

## カバレッジ、鮮度、制限事項

[サポート対象エンジン、地理または言語の動作、回答の変動性、収集頻度、履歴の可用性、言及が必ずしも引用ではない理由を記載する。]

## 証明と方法論

[実際のインターフェースと保存された回答を示す。成果の主張については、ベースライン、期間、単位、出典、方法、確認日、制限を提供する。]

## 関連ワークフロー

[この能力を必要とする2～3のユースケース、1つのオーディエンスソリューション、および1つの正確なサポートガイドにリンクする。それぞれが次のステップである理由を説明する。]

## FAQ

[カバレッジ、計算、セットアップ、プラン、プライバシー、解釈、評価に関する5～8の残存質問に答える。]

## AI可視性を測定する

[正確なレポートを開くか、資格のある評価を開始する1つのアクションを提供する。]

カバレッジとプランの主張は、公開時点での最新の製品情報源からのものでなければなりません。

デザインギャラリー

すべてのバリエーションで同じ能力、主張、エビデンス、CTAを使用して、レビュー担当者が階層を判断できるようにします。一般的なダッシュボードのモンタージュ、ストックイラスト、ラベルなしのUI断片は証明になりません。

馴染みのない能力にはメカニズム主導のデザインをデフォルトとします。関連性が不明確な場合は成果主導の階層を使用し、実際に混同しやすい代替案がある場合のみ比較主導の階層を使用します。

品質チェックリスト

以下の該当するすべての項目が合格した場合のみ、機能ページは準備完了です。

• H1は製品カテゴリ、オーディエンス、ジョブ、またはスローガンではなく、1つの持続可能な能力を明記している。
• ヒーローはその能力と1つの限定された成果および1つの関連する修飾語をペアにしている。
• 直接回答は入力、メカニズム、出力、範囲、頻度を平易な言葉で特定している。
• メカニズムが現在の製品動作と一致し、自動化、設定、人間の判断を区別している。
• 少なくとも1つの最新キャプチャが中核メカニズムを証明し、すべてのキャプチャに目的、代替テキスト、凡例、確認日がある。
• 指標は該当する場合に分子、分母、単位、方向、範囲、欠損データの扱いを定義している。
• 要件はアクセス、データ、処理時間、成功状態、回復パスを記載している。
• 制限事項はCTAの後の細かい活字ではなく、該当する主張の横に配置されている。
• 成果は、より大きな結果を検証済みのエビデンスがサポートする場合を除き、判断または制御可能な出力として枠組みされている。
• 比較は一貫した次元を使用し、関連する弱点を開示している。
• 証明は出典、方法、範囲、期間、所有者、承認、確認日を特定している。
• ページはジョブとオーディエンスへの外部リンクを提供するが、それらの主要な意図を吸収しない。
• FAQ回答は独立して抽出された場合も有用であり、フロントマターと正確に一致している。
• 主要なCTAはこの能力を開くか評価するものであり、そのイベントは測定可能である。

名詞テストを実行します：能力名を隣接する機能に置き換えます。メカニズム、スクリーンショット、制限、証明がまだ適合する場合、実際のデータフロー、コントロール、出力、障害モードに基づいて書き直します。

よくある間違い

メカニズムなしで成果を売る。「どこでも可視性を向上」は信じる理由を与えません。システムが何を観察、計算、保存、公開するかを説明します。

ページを製品ツアーに変えてしまう。引用追跡に、生成、アップタイム、収益の均等なセクションは必要ありません。主要な能力を完了した後で隣接する機能にリンクします。

機能URLの下にユースケースを書く。「競合他社の引用ギャップを見つける」はジョブです。能力ページは引用追跡を説明し、ユースケースページはそのジョブに沿ってフィルター、ソース検査、コンテンツ判断、割り当てを組み合わせます。

オーディエンスで分割する。製品の動作が同一の場合、SaaSとエージェンシー向けに別々の機能ページを作成しないでください。異なるオーディエンスの制約はソリューションページに配置します。

説明のないダッシュボードを表示する。判断に焦点を当ててクロップし、コントロールに注釈を付け、指標を定義し、何が重要なのかを伝えます。

可用性と制限を隠す。サポートされていないエンジン、国、エクスポート、ロール、履歴は、サインアップ後ではなく、約束の横に配置します。

製品レポートから因果関係を主張する。コンテンツ変更後の可視性の向上は、その変更が原因であることを証明しません。タイムラインと他の合理的な要因を記録し、観察結果を正確に記述します。

比較できないものを比較する。1つの機能とプラットフォーム全体を比較するのではなく、メカニズム、カバレッジ、出力、アプローチを比較します。

内部リンク

機能ページは正規に能力を所有します。製品概要、ガイド、ユースケース、ソリューション、比較、証明から説明的なアンカーテキストで内部リンクを受け取ります。

読者の評価順に外部リンクを提供します。

1. メカニズム用語を、説明の横にあるドキュメントまたは正確なガイドにリンクする。
2. 読者が出力を理解した後、能力が可能にするジョブにリンクする。
3. 明確な制約や購入コンテキストを追加する場合のみ、1つのオーディエンスソリューションにリンクする。
4. それがサポートする正確な主張の横に顧客ストーリーにリンクする。
5. 出力が自然にその入力になるか、読者が両方を比較する必要がある場合のみ、隣接する機能にリンクする。

兄弟間で重複しないようにします。機能ページは能力とメカニズム、ユースケースページはジョブとワークフロー、ソリューションページはオーディエンスのニーズ、製品ページはオファーと購入、連携ページは接続とデータフロー、顧客ストーリーは検証済みの過去の結果を所有します。

公開前に主要なクエリをマッピングします。フレーズが能力またはジョブのいずれかを示す可能性がある場合、1つの正規所有者を割り当て、もう一方のページをリターゲットします。

結果の測定方法

能力に関するクエリの発見、メカニズムと制限の正確な抽出、意図されたURLの引用、証明へのエンゲージメント、関連ジョブへの移動、機能固有のアクション完了を測定します。

公開前に、クエリとプロンプトセット、主要URL、ベースライン、公開アノテーション、コンバージョンイベントを確立します。能力言語と比較質問には プロンプト追跡を、引用されたページと保持された制限の確認には ソース・引用インテリジェンスを使用します。 AmICited CockpitはAI可視性、引用URL、オーガニックパフォーマンス、選択されたコンバージョンを組み合わせます。 結果の測定方法に従って、先行シグナルと成果を分離します。

以下の指標を報告します。

• 能力クラスターのインプレッションとクリック（ブランドのみの需要から分離）
• 追跡プロンプトのカバレッジ、ブランド言及、引用出現、引用されたURL
• AI回答がメカニズムと制限事項を正確に説明しているか
• 証明と関連ジョブへのエンゲージメント（イベントが利用可能な場合）
• 機能固有のCTA開始数と完了数
• 合意されたアトリビューションモデルに基づく資格のあるパイプラインまたはアクティベーション
• ユースケース、ソリューション、連携、製品、ドキュメントのURLとのカニバリゼーション

正確な製品理解を伴わないランキングは不完全であり、機能ページが最適なソースである場合にホームページが引用されるのも同様です。保存された回答、引用URL、コンバージョンパスを一緒にレビューします。

FAQ

機能ページとは何ですか？

機能ページは1つの製品能力のための商業ページです。メカニズム、可能になる成果、エビデンス、制限、次の評価ステップを説明します。

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

機能ページは引用追跡などの1つの能力を所有します。ユースケースページは、競合他社が引用されているが自社ブランドがないプロンプトを見つけるなど、1つのジョブを所有します。1つの能力が複数のジョブを可能にすることがあります。

機能ページとソリューションページの違いは何ですか？

機能ページは1つの能力を説明します。ソリューションページは1つのオーディエンスまたはビジネスモデルに対して複数の能力、ジョブ、制約、証明ポイントをキュレーションします。

機能ページの長さはどのくらいにすべきですか？

ほとんどは1,500～2,500語が必要です。単純なコントロールはより少なく済む場合があり、セットアップ、複数の状態、制限、エビデンスを伴う能力はより多く必要です。

すべての機能ページにスクリーンショットは必要ですか？

可視的なインターフェースの場合ははい。1つの最新スクリーンショットで中核メカニズムを証明する必要があります。明確な状態、入力、出力、または判断がある場合にのみ追加します。

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

デフォルトではWebPageを使用します。サポートされている可視プロパティがある場合のみSoftwareApplicationまたはProductを追加し、可視および構造化された回答が一致し、現在のポリシーが許可する場合のみFAQPageを追加します。