ツール比較と意思決定ガイドのウェブサイトを作る方法

読者と目標を明確にする

ツール比較サイトを作る前に、誰を助けるのか、そして「成功」をどう定義するかを明確にしてください。あらゆる人に向けようとする意思決定ガイドは、結局誰の役にも立たなくなることが多いです。

読者を定義する（役割、予算、ユースケース）

まず一人の明確な主要読者を想定します。職種、制約、実際の状況を与えてください：

• 役割: 創業者、マーケター、オペレーションマネージャー、IT管理者、フリーランス
• 予算感: 無料のみ、月額50ドル未満、チームプラン、エンタープライズ
• ユースケース: 「スプレッドシートを置き換える」「クライアントプロジェクトを追跡する」「メールキャンペーンを運用する」「会議を録音して記録する」など

この明確さが、製品比較表で何を強調すべきかを決めます。フリーランスは価格とシンプルさを重視するかもしれませんし、IT管理者はセキュリティ、SSO、管理機能を優先するかもしれません。あなたの機能マトリクスは、読者の意思決定基準を反映すべきであって、ツールが持つすべての機能を列挙する必要はありません。

範囲と成果を選ぶ

最初は狭いツールカテゴリを選んでください（例：「会議文字起こしツール」）。ニッチが狭いほど、権威あるレビューを書きやすく、比較ページのSEOも集中できます。

次に、望む成果を定義します：

• ベンダーサイトへのアフィリエイトクリック
• 更新やテンプレートのためのメール登録
• デモリクエストや自社サービスのリード獲得

ここで正直になると、コンテンツのスタイル、CTA、アフィリエイト開示の配置に影響します。

シンプルな成功指標を設定する

目標に直結する少数の指標を追跡します：

• 「ベスト」や比較ページへのオーガニックトラフィック
• 比較ページから個別ツールページへのCTR
• コンバージョン率：アフィリエイトクリック、登録、デモリクエストなど

読者と測定可能な目標があれば、以降のサイト構造、UX、ツールのデータ収集方針が一貫して決めやすくなります。

ニッチ選びとコンテンツ構造の設計

ツール比較サイトは、狭く有用であるほど成功します。「あらゆる業務ソフト」は広すぎて維持できず、順位もつきにくいです。比較を行う習慣があり、乗り換えの痛みがあるニッチを選び、彼らがどうやって決めるかに合わせた構造を作ってください。

明確な購買意図があるニッチを選ぶ

定義された読者と意思決定の瞬間から始めます。良いニッチは次の特徴があります：

• 定期的な需要（チームは年に一度ツールを見直す）
• 類似製品が多い（機能マトリクスが役立つ）
• 「〜に最適」意図が強い（人々が決定ガイドを検索する）

例：「Shopify店舗向けのメールマーケティングツール」「代理店向けのプロジェクト管理ツール」「フリーランス向け会計ツール」。具体的なほど意味ある比較と信頼できるレビューを作りやすいです。

実際に使われる意思決定基準をリストアップする

ページを計画する前に、読者が気にする基準を書き出してください。ベンダーが宣伝するものではなく、実際の意思決定要素です。典型的な基準には価格、使いやすさ、連携、サポート、セットアップ時間があります。医療向けなら「HIPAA準拠」、ECなら「マルチストア対応」などのニッチ固有基準も加えます。

このリストがサイト全体で一貫した製品比較表と機能マトリクスになります。ユーザーは素早くスキャンして自信を持てます。

ツールをサブカテゴリとユースケースに分ける

ほとんどのニッチには構造が必要です。明確なサブカテゴリと「〜に最適」ユースケースを作ります。例：

• ワークフロー別：「請求書作成」対「経費管理」
• チームタイプ別：「個人」対「小チーム」
• 要件別：「X連携があるもの」

これらがカテゴリハブと将来の比較ページのSEOになります。

ページ命名の一貫性を作る

一貫性はユーザーと検索エンジンに有利です。パターンを決めて守ってください：

• カテゴリ：「Best <カテゴリ> ツール」
• ユースケース：「<ツール> の中で <対象/ニーズ> に最適」
• 比較：「<ツールA> vs <ツールB>」

ナビゲーション設計：ハブ、ツールページ、比較ページ

シンプルでスケーラブルな構造例：

• カテゴリハブページ（概要＋フィルター）
• 個別ツールページ（対象、長所/短所、価格、連携）
• 比較ページ（横並びテーブル＋推奨）

このアーキテクチャは意思決定の流れを明確にします：発見 → 候補作成 → 比較 → 選択。

比較フレームワークを設計する

比較サイトは一貫性で生き残ります。レビューやテーブルを書く前に、「サイト上でツールとは何か」を決め、読者が信頼できる比較方法を定義してください。

標準的なツールプロフィールテンプレートを作成する

どこでも使える単一のツールプロフィール構造から始めます。フィルタやテーブルを動かせる程度に詳細で、更新が面倒にならない範囲に抑えてください。実用的なベースラインは：

• 基本: 名前、カテゴリ、短い要約、公式URL
• プラットフォーム: Web、iOS/Android、Windows/macOS、ブラウザ拡張、API
• ターゲットユーザー: 個人、SMB、エンタープライズ；主要ユースケース
• 価格のスナップショット: 無料プラン（有/無）、開始価格、トライアル（有/無）
• サポートと信頼: サポートチャネル、SLA（該当なら）、セキュリティ/コンプライアンス注記
• 証拠: 情報源/最終確認日、変更履歴メモ

比較フィールド（「機能マトリクス」）を定義する

人々がどう決めるかに合わせたフィールドを選びます。次のような混合が理想です：

• 機能: 必須（コア）、あると良い（上級）、連携
• 制限: シート数、プロジェクト数、ストレージ、使用上限、レート制限
• 価格プラン: プラン名、主要差分、アドオン、割引
• サポート: メール/チャット/電話、コミュニティ、オンボーディング、応答時間の主張
• プラットフォーム: どこで動くか、各プラットフォームで何が欠けているか

ヒント：すべてのツールで小さな「共通」フィールドセットを維持し、カテゴリ固有のフィールドを追加する方法が良い（例：ヘルプデスクなら「チーム受信箱」、執筆ツールなら「バージョン履歴」など）。

不明なデータの扱いを決める

不明な点は起きます—ベンダーが公開していない、機能が静かに出る、価格が月中に変わるなど。ルールを定めてください：

• 「不明」（空欄ではなく）を使い、編集ワークフロー内で注記：「公開情報なし；最終確認 YYYY-MM-DD」。
• 推測はしない。重要なら**「ベンダーへ確認」や「ユーザー報告」**とラベル付けする。

ラベルの一貫性を保つレビューガイドラインを設定する

スコアやバッジ（「チーム向け」「予算重視」）を使うなら、その基準を文書化してください。何が合格基準で何が失格か、どんな証拠が必要かを簡潔に書きます。一貫したルールは、ツールを追加しても「スコアの偏り」を防ぎ、公平に見える推薦を作ります。

データモデルを構築する（更新が楽になるように）

サイトが成功すると、最大の手間はページを書くことではなく、価格変更やプラン名変更、機能追加に伴う更新です。シンプルなデータモデルは「20ページ編集」ではなく「1レコード変更で全体更新」を可能にします。

シンプルに始める：まずはスプレッドシート

アイデア検証の段階ではスプレッドシート（またはAirtable/Notion）が早くて協働しやすく、必要なフィールドを絞り込めます。

ツール数やカテゴリ、編集者が増えたら、同じ構造をCMSやデータベースに移行して比較ページを自動生成できるようにします。

コアの関係性を設計する

すべてを自由文で保存すると比較サイトは崩壊します。再利用可能なエンティティとその接続を定義してください：

• Tool（ツール）: 製品自体（名前、サイト、短い要約）
• Category（カテゴリ）: 属する分野（例：「メールマーケティング」「プロジェクト管理」）
• Pricing plan（価格プラン）: ツールの下にあるプラン（Free/Starter/Pro）、価格、課金周期、主要制限
• Feature（機能）: 標準化されたリスト（「SSO」「APIアクセス」「エクスポート」）
• Feature value（機能値）: ツール（またはプラン）と機能の結合（Yes/No/Partial + 注記）

このtool ↔ category ↔ feature ↔ pricing planのセットアップにより、多くのツールで同じ機能定義を使い回せ、言い回しの不一致を避けられます。

SEOと信頼メタデータを早めに追加する

比較ページのSEO以前に、各ページに欲しいフィールドを捕らえてください：

• 短い要約（イントロとメタディスクリプション用）
• 長所/短所（構造化して段落に埋めない）
• ユースケースタグ（「〜に最適」ページ用）
• 最終更新日とデータソース（ベンダーサイト、ドキュメント、実機テスト）

これらはページの可読性を高め、読者の信頼を築きます。

バージョン管理と変更履歴ルール

何が「重大な変更」に当たるか（価格、主要機能、制限）と表示方法を決めてください。

最低限、保存する項目：

• ツールやプランごとの updated_at タイムスタンプ
• 簡単な changelog note（例：「10月12日に価格帯を更新」）

透明性はサポート問い合わせを減らし、成長するサイトでの信頼感を維持します。

ページタイプとテンプレートを作る

データモデルが固まってきたら、公開するページタイプを確定します。一貫したテンプレートはサイトの整合性を保ち、更新を速くし、読者が「閲覧から決定」へ進みやすくします。

最初に作るべきコアページタイプ

1) カテゴリハブページ

閲覧と絞り込みのエントリーポイントです（例：メールマーケティングツール、会計ソフト）。良いハブは短い概要、いくつかの推奨、フィルタ可能な製品比較表を含みます。より深く調べるための明確な経路：「トップツールを比較」「クイズを受ける」など。

2) ツール詳細ページ

ツールページは次に答えるべきです：それは何か、誰向けか、費用はどうか、どこが得意でどこが苦手か。構成を繰り返し使えるように：要約、主要機能、価格、連携、長所/短所、FAQ。ここで「サイトへ移動」や「料金を見る」のような明確なCTAがあることを読者は期待します。

3) 比較ページ

ツールA vs ツールB vs ツールCのページは簡潔な結論で始め、標準化された機能マトリクスを入れて読者が素早く比較できるようにします。価格帯、主要機能、サポート、オンボーディング、制限などを含め、最後に次のステップ（「比較する」「候補に追加」「デモを依頼」）を提示します。

4) 意思決定ガイドページ

「状況に応じた最適なツールを選ぶ」ためのガイドです。「フリーランス向けCRMベスト」や「小チーム向けパスワード管理の選び方」など。スペックの網羅よりも、ニーズとオプションのマッチングに重点を置きます。

テンプレートに組み込む信頼要素

すべてのページタイプに再利用可能なブロックを組み込みます：簡単な「評価方法」スニペット、目に見える最終更新日、/methodology、/editorial-policy などのソースへのリンク。アフィリエイトリンクを使うなら、明確な開示（/affiliate-disclosure）を入れてください。

標準化する再利用コンポーネント

どこにでも使えるコンポーネントを作ります：比較テーブルモジュール、機能リストカード、FAQブロック、一貫したCTAバー（例：「候補に追加」「代替を見る」「サイトへ移動」）。再利用が、繰り返し感を抑えつつスケーラブルに保つ鍵です。

テックスタック選びと基盤構築

チームの働き方に合うスタックを選んでください。目標は派手な技術よりも、信頼できる比較を素早く公開し、更新を簡単にし、ツールを追加しても壊れないことです。

チームに合った構築アプローチを選ぶ

小規模チームや個人なら、CMS かノーコード は早く公開できます：

• ノーコードサイトビルダー はディレクトリ型サイトの立ち上げに適しているが、複雑なフィルタや大量データでは苦戦する。
• CMS（WordPressやヘッドレスCMS） は慣れた編集フロー、役割、リビジョン履歴を提供し、コンテンツが差別化要素なら有利。
• カスタム構築 は高度なフィルタやログイン機能、大量のツールを扱うときに適する。

単純なルール：比較が主に編集的でテーブルが少ないならCMS、検索可能なデータベースが主目的ならカスタム（またはCMS＋カスタムフロントエンド）を検討。

もし長い開発期間を避けつつ柔軟性が欲しいなら、チャットベースのワークフローでプロトタイプを出せるvibe-codingプラットフォーム（例：Koder.ai）のような選択肢もあります—通常はReactフロントエンドとGo + PostgreSQLのバックエンドで、準備ができたらソースコードをエクスポートできます。

初日からのパフォーマンスとモバイル対応

テーブル、アイコン、スクリプトが積み重なって速度が落ちやすいので、基盤は軽く保ちます：

• 重いテーブルウィジェットを制限し、サーバーサイドレンダリングされたテーブルを優先する
• 画像を圧縮し、遅延読み込み（特にロゴ）を行う
• 早めにモバイルでテスト：フィルターは片手で使えること、テーブルはスクロールしてもレイアウトが壊れないこと

高速表示は単に良い体験ではなく、SEOとコンバージョンに直結します。

意思決定を支えるナビゲーション

訪問者が今どこにいるか、次にどこへ行くか分かるようにします：

• パンくずリスト を追加（例：カテゴリ → サブカテゴリ → ツール）
• 「関連ツール」や「代替を比較」ブロックを含め、深掘りを促す
• URLはクリーンで一貫性を持たせ、共有や再訪がしやすくする

分析とイベントトラッキングを前倒しで計画する

後で計測するのではなく、最初から重要イベントを定義しておきます：

• フィルター使用、ソート変更、詳細表示のクリック
• ベンダーサイトやアフィリエイトへの外部クリック
• CTA（ニュースレター登録、「推奨を依頼」）の操作

これを早くセットすると、推測ではなく実データに基づいてページ改善ができます。詳しくは /blog/analytics-and-conversion-improvements を参照してください。

テーブル、フィルター、意思決定フローのUX

比較サイトは明瞭さで勝ち負けが決まります。訪問者は「自分の予算とチームに合うものを選ぶ」目的で来るので、あなたのUXは素早く絞り込み、十分な詳細で選択を確信させる必要があります。

比較テーブルを本当に読みやすくする

テーブルはデスクトップとモバイル両方で視認しやすくする必要があります。

固定ヘッダー を使い、スクロール中もツール名や主要列が見えるようにします。ホバー/タップ時に列ハイライト（およびキーボードフォーカス時）を入れて、グリッド内で迷わない工夫をします。

行は意味あるセクションに分けます（例：基本、連携、セキュリティ、サポート）。各ラベルは短く一貫させてください（"SSO" と "Single sign-on" と "SAML" を混在させない）。

思考に合わせたフィルター

データベース風のフィルターではなく、人々の考え方に合わせたフィルターを提供します。高意図フィルター例：予算、プラットフォーム、チームサイズ、そして少数の「必須」条件（例：「Google Workspaceに対応」）。

フィルターは寛容に：残りツール数を示し、ワンクリックのリセットを用意し、性能が理由でない限り結果表示を“適用”ボタンで隠さないでください。

シンプルな意思決定フローを作る

多くの訪問者は20選を比較したくありません。短い“ピッカー”経路を用意します：質問3～5問でランク付きショートリストを返す。

ツールカードやツールページには明確な**「おすすめ対象」（2～4箇条）と「向かない人」**を載せて期待値を設定します。これが後悔を減らし信頼を高めます。

アクセシビリティはチェック項目ではなくUXの一部

フィルターやテーブルのキーボード操作をサポートし、十分なコントラストを保ち、分かりやすいラベルを使い（アイコンだけに意味を持たせない）ます。色で「良い/より良い/最高」を表す場合は、テキストの代替とARIAラベルを提供して、誰でも比較できるようにしてください。

信頼性の高い比較コンテンツを書く

コンテンツが製品です。読者がベンダーのマーケティングを要約しているだけ、または無理に「勝者」を決めていると感じたら離脱します。文脈のある高信頼の比較記事は、答えが「場合による」でも読者が選べるように助けます。

判断を助けるカテゴリ導入文を書く

ツールを列挙する前に、読者が自分の基準を選べるように短い導入文を書きます。このカテゴリで通常何が重要か（予算、チームサイズ、連携、学習コスト、セキュリティ、サポート、導入時間）と一般的なトレードオフを説明します。

良いパターン："Xを最重視するならYを優先。Zが必要ならコストや導入工数が増えることを覚悟。" こうした導入文がページを単なるカタログではなく意思決定ガイドに変えます。

一貫したレビューの口調を使い、同じ質問を繰り返す

各ツールで同じ構成を保つと読者は素早く比較できます：

• 誰向けか（誰がスキップすべきか）
• 強み（特に得意な点）
• トレードオフ（制限、欠落機能、コストの落とし穴）
• 導入の手間（時間、スキル、移行の難易度）

一貫性は好みがあっても公平に見せます。

絶対的な主張を避け、文脈とソースを示す

「最高」「最速」といった表現は避け、具体性を持たせます："〜に最適"、"単純なワークフローでは高速だが〜の場合は遅くなる"。性能、価格、機能の参照はどこから得たか（ベンダー文書、公開価格ページ、自社テスト、ユーザーフィードバック）を説明します。

新鮮さを見せる：更新頻度とタイムスタンプ

すべての比較とレビューに「最終確認」タイムスタンプを追加します。編集の更新頻度（価格は月次、機能は四半期、重大な変更は即時など）を公開してください。ツールが重要に変化した場合は何がいつ変わったかを記録します。

比較ページと「ベスト」ページのSEO戦略

比較サイトのSEOは主に購買意図の検索にマッチすることと、読者と検索エンジンの両方に構造を理解させることです。

適切な意図キーワードをターゲットに（ページタイプに合わせる）

評価を示すクエリを中心にキーワードを作ります：

• 「best X for Y」 → キュレーションされた「ベスト」ページ（例：「EC向けメールマーケティングツールのベスト」）
• 「X vs Y」 → 明確な結論を示す比較ページ
• 「X alternatives」 → 乗り換え時の判断を説明する代替案ページ

各ページは意図に素早く答えること：誰に向いているか、何を比較しているか、推奨は何か（簡潔な理由付き）。

意思決定を支える内部リンク体系を作る

内部リンクで評価プロセスを導きます：

ハブ → ツールページ → 比較 → 意思決定ガイド

例：/email-marketing のカテゴリハブは /tools/mailchimp などのツールページへリンクし、そこから /compare/mailchimp-vs-klaviyo や /alternatives/mailchimp、そして /guides/choose-email-tool のような意思決定フローへつながります。

この構造は検索エンジンにトピックの関係を理解させ、ユーザーを選択へ導きます。

スキーマは有効な箇所だけに使う

FAQスキーマは本当にQ&Aを含むページに追加します。Product schemaは正確で具体的な製品データを提供できる場合に限定して検討してください。まずは可読性を優先し、スキーマはページの内容を反映するものにしてください。

マネーページを支える/blog コンテンツ計画

情報クエリを狙ったサポート記事を /blog に計画し、比較ページへ誘導します。例：「フリーランス向けCRMの選び方」「機能マトリクスとは」「ツール乗り換えでよくあるミス」。各記事は関連ハブ（/crm）、比較、意思決定ガイドへリンクしますが、アンカーテキストを過剰に繰り返さないよう注意してください。

マネタイズと開示

収益化は必須です—比較サイトの利用者はそれを理解しますが、騙されたと感じると戻ってきません。収益を得る一方で、金銭関係があることを明確にし、推薦の独立性を守ってください。

収益モデルを選び（明確にする）

収益化の代表的モデル：アフィリエイト（購入に対するコミッション）、スポンサー（有料掲載や広告）、リードジェネレーション（有償の紹介）。

ヘッダー/フッターに一言と、主要CTA近くに短い開示文を入れるのが効果的です："一部のリンクはアフィリエイトリンクです。購入が発生した場合、当サイトは手数料を得ることがあります（追加費用はありません）。" 曖昧な表現で関係を隠さないでください。

意思決定が行われる場所に開示を置く

開示ページは必要ですがそれだけでは不十分です。

• 専用の /disclosure（およびオプションで /advertising-policy）ページを作り、アフィリエイト関係、スポンサー方針、ランキングの公正性を説明する。
• 「サイトへ移動」「料金を見る」「トライアルを開始」などの外部CTA近くにリンクを置く。
• 特定ベンダーがスポンサーの場合は、カードや行に「スポンサー」などと明示する（細字だけで隠さない）。

推薦の独立性を保つ

信頼性が差別化要因です。守るための方針：

• 広告とランキングを視覚的・構造的に分離する（別ブロック、別ラベル）
• 比較フレームワーク内で順位付け基準を明示する（何が重要か、重みづけ、データソース）
• スポンサーペイメントがスコアを変えない仕組みにする。もし有料掲載があるならランキング外に置き、その意味を説明する（例：「フィーチャードパートナー」）

収益を正直に追跡する

ページごと・クリックごとの収益を計測できますが、ユーザーを誤解させないようにしてください。ラベル付きのアウトバウンドイベント（例："affiliate_outbound_click"）を用い、ページテンプレート（ベストページ vs 個別レビュー）にマッピングして改善に役立てます。

CTA文言やボタン配置のテストでは、根拠のない推薦（"保証された1位" など）を避けてください。信頼は短期のクリックより早く積み上がります。

分析とコンバージョン改善

分析は単なるトラフィックレポートではなく、表や意思決定フローが本当に選択を助けているかを学ぶ手段です。

意図を示すアクションを追跡する

重要なイベントを設定します：

• フィルター使用（どのフィルターが、どの順で、どれくらい使われているか）
• テーブル操作（列並べ替え、横スクロール、行展開、差分表示）
• ベンダー/アフィリエイトへの外部クリック（テーブル、ショートリスト、レビューどこからか）

これらのイベントで「ユーザーは機能マトリクスを使っているか、それとも価格に直行しているか？」や「どのフィルター組合せが外部クリックにつながるか？」などに答えられます。

離脱ポイントを見つける（特にモバイル）

簡単なファネルを構築します：

1. 「ベストツール」ページに着地 → 2) フィルター適用 → 3) ツール詳細を開く → 4) 外部クリック

デバイス別にセグメントし、モバイルでの大きな離脱箇所（テーブルスクロール、固定ヘッダー、長いフィルタパネル）を特定します。テーブル表示の後に大きく落ちるなら、タップ目標を明確にしたり、初期表示列を減らしたり、より明確な「ショートリスト」アクションを検討します。

決定に影響する部分をA/Bテストする

理解と自信に影響する要素を優先してテストします：

• テーブルレイアウト（コンパクト vs ゆったり、デフォルト列、最左列の固定）
• CTAラベル（"料金を見る" vs "無料トライアルを始める" vs "ショートリストで比較"）
• ショートリストフロー（ワンステップ vs ガイド付き）

主要指標は「質の高い外部クリック」、ガードレールは直帰率や最初の操作までの時間にします。

ダッシュボードと週次レビュー

軽量ダッシュボードを作り、上位ページ、アウトバウンドクリック（ソース別）、フィルター使用、デバイス分布、ファネルコンバージョンを表示します。週次で見直し、1つ改善を決めて実施し、次週にトレンドを再確認します。

メンテナンス、更新、スケール

比較サイトは新鮮さが命です。テーブルや「ベスト」ページが古くなると信頼は急速に落ちます。特に価格や機能は四半期ごとに変わることが多いです。

シンプルな更新ワークフローを設定する

更新は緊急対応ではなく定期編集作業と考えます：

• 月次チェック（軽微）: 価格、プラン名、主要制限（シート数、ストレージ、自動化数）を確認
• 四半期の深堀り: コアワークフローの再テスト、オンボーディング、重要機能（SSO、API、エクスポート）を再評価
• イベントベース更新: ベンダーのリリース、買収、大きな価格変更、ユーザー報告があった場合

ツールページごとの短いチェックリストを用意して更新の一貫性を保つ："価格確認済み"、"スクリーンショット確認"、"機能再確認"、"長所/短所更新"、"最終更新日"。

「更新を提案する」経路を作る

比較テーブルやツールページの近くに小さなリンクを置きます：「更新を提案する」。フォームで以下を取れるようにします：

• 何が間違っているか（価格、機能、制限、壊れたリンク）
• ソース（URLまたはスクリーンショット）
• 任意の連絡先メール

簡潔な修正方針を公開します（"X営業日以内に確認・更新"）。修正したらページの軽い変更履歴に記載して説明すると説明責任が果たせます。

維持可能な範囲でカテゴリを拡大する

新しいカテゴリをすぐに増やすのは魅力的ですが、カテゴリごとにメンテナンス量が掛かります。

良いルール：トップツールを定期的に更新できる見込みが立つまでカテゴリを公開しない。15～30ツールをスケジュール通りに維持できないなら、まずは少数で始めて質を保ってください。

リンクされやすい資産で権威を築く

オリジナル調査や小さなユーティリティは、アフィリエイト以上の価値を生みます。例：

• 価格計算機（例：「10/25/50ユーザーの席当たりコスト」）
• 購入者向け要件チェックリストのダウンロード
• コピー可能な機能マトリクステンプレート

これらは他サイトからの参照を引き、ベンダーのマーケティング主張が変わってもページを有用に保ちます。