お問い合わせ

クラウドインフラの選定において、AI検索が新たな情報収集手段になっています。 「国内リージョンがあるクラウド」「SLA 99.99%のIaaS」「AWS代替 国産クラウド」といったクエリに対して、ChatGPTやPerplexityが生成する回答に自社が含まれるかどうかは、見込み顧客の検討リストに入るかどうかを左右します。

クラウドインフラ事業者のサイトには、AIが情報を正確に取得しにくい構造が存在します。 SLAの詳細が利用規約のPDFにしかない、リージョン情報がステータスページにだけ記載されている、料金が計算ツールでしか確認できないといった状態です。

この記事では、クラウドインフラ事業者が取り組むべきGEO対策を、SLA情報の構造化からリージョン情報の公開、料金体系の設計まで解説します。

クラウドインフラサイトがAI検索で不利になる要因

クラウドインフラ事業者のサイトが抱える課題は大きく3つあります。

情報の分散。 サービス概要はマーケティングサイト、SLAは利用規約ページ、料金は料金計算ツール、技術仕様はドキュメントサイトと、情報が複数のサブドメインやページに分散しています。 AIがサービスの全体像を把握するには、これらが一貫した形で統合されている必要があります。

動的コンテンツへの依存。 料金計算ツールやリージョンマップなど、JavaScriptで動的に生成されるコンテンツは、AIクローラーが取得できない場合があります。

定量情報の埋没。 SLAの稼働率保証値、リージョン数、提供サービス数といった定量情報が、マーケティングコピーの中に埋もれているか、利用規約の法的文書の中にしかないケースが多いです。

サービス情報のJSON-LD設計

クラウドインフラサービスの基本情報は、Service schemaとOrganization schemaで構造化します。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "企業名",
  "description": "国内3リージョンでIaaS・PaaS・マネージドサービスを提供するクラウドインフラ事業者。SLA 99.99%保証。",
  "knowsAbout": [
    "IaaS", "PaaS", "仮想サーバー", "オブジェクトストレージ",
    "マネージドKubernetes", "CDN", "ロードバランサー"
  ],
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "クラウドサービス一覧",
    "itemListElement": [
      {
        "@type": "Service",
        "name": "仮想サーバー（コンピュート）",
        "description": "1vCPU/1GBメモリから128vCPU/512GBメモリまでのインスタンスを提供。月額880円〜。",
        "serviceType": "CloudCompute",
        "offers": {
          "@type": "Offer",
          "lowPrice": "880",
          "priceCurrency": "JPY",
          "description": "月額。1vCPU/1GBメモリの最小構成。"
        }
      },
      {
        "@type": "Service",
        "name": "オブジェクトストレージ",
        "description": "S3互換API。1GBあたり月額3円。東京・大阪リージョンで提供。",
        "serviceType": "CloudStorage"
      }
    ]
  }
}

hasOfferCatalogでサービスラインナップを一覧化し、各サービスにoffersで料金の目安を記載します。 クラウドサービスは従量課金のため正確な月額を示しにくいですが、最小構成の月額を基準値として記載することで、AIは料金比較クエリに対応できます。

SLA情報の構造化

「SLA 99.99%」「稼働率保証 クラウド」といったクエリは、クラウドインフラ選定で頻出します。 SLA情報が利用規約PDFにしかない状態では、AIに引用される機会を逃します。

SLA情報のための専用ページを作成し、以下の情報をHTMLで公開してください。

<table>
  <thead>
    <tr><th>サービス</th><th>SLA（月間稼働率）</th><th>返金基準</th></tr>
  </thead>
  <tbody>
    <tr><td>仮想サーバー</td><td>99.99%</td><td>99.99%未満：月額10%返金、99.9%未満：月額30%返金</td></tr>
    <tr><td>オブジェクトストレージ</td><td>99.99%</td><td>99.99%未満：月額10%返金</td></tr>
    <tr><td>マネージドDB</td><td>99.95%</td><td>99.95%未満：月額10%返金</td></tr>
    <tr><td>CDN</td><td>99.9%</td><td>99.9%未満：月額10%返金</td></tr>
  </tbody>
</table>

SLAの計算方法（月間稼働率の定義、メンテナンス時間の扱い、計測方法）もHTML本文で明記します。 「月間稼働率 = (月間総分数 - ダウンタイム分数) / 月間総分数 × 100。計画メンテナンスは除外」のような記述は、AIが正確に引用するために必要です。

過去の稼働実績も公開すると信頼性が向上します。 「2024年度の仮想サーバー実績稼働率：99.997%」のような実績値は、保証値よりもAIに引用されやすいデータです。

リージョン情報の公開設計

「国内リージョン クラウド」「大阪リージョン IaaS」といったリージョン関連のクエリに対応するために、リージョン情報を構造化して公開します。

各リージョンについて以下の情報を明記してください。

リージョン名と所在地（国・都市レベル）。 提供サービスの一覧（すべてのサービスが全リージョンで提供されているとは限らないため）。 リージョン間のレイテンシ目安。 データ主権・準拠法の情報。

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "東京リージョン",
  "description": "東京都内に設置。仮想サーバー・オブジェクトストレージ・マネージドDB・CDN等の全サービスを提供。大阪リージョンとの間でレイテンシ5ms以下。",
  "areaServed": {
    "@type": "Place",
    "name": "東京",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "東京都",
      "addressCountry": "JP"
    }
  },
  "serviceType": "CloudRegion"
}

リージョンマップをJavaScriptで動的に表示している場合は、同じ情報をHTMLの<table>やリストでも記述してください。 AIクローラーはインタラクティブな地図からリージョン情報を取得できません。

料金体系の情報設計

クラウドの料金は従量課金が基本であるため、「料金は使い方次第」として情報公開を避けるベンダーが多いです。 しかし、「クラウド 料金 比較」「IaaS 月額 目安」といったクエリにAIが回答するには、何らかの基準値が必要です。

公開すべき料金情報は以下です。

主要サービスの単価表。 仮想サーバーのスペック別月額、ストレージの容量単価、データ転送料の単価をHTMLテーブルで公開します。

代表的な構成例と月額試算。 「Webサーバー2台 + DBサーバー1台 + 100GBストレージの構成で月額約35,000円」のような試算例を3〜5パターン記載します。

他社との料金比較の基準。 「AWS東京リージョンの同等スペックと比較して約30%低コスト（2025年6月時点）」のような比較情報は、AIが料金関連クエリに回答する際に引用されやすいデータです。

<table>
  <thead>
    <tr><th>スペック</th><th>月額</th><th>時間単価</th></tr>
  </thead>
  <tbody>
    <tr><td>1vCPU / 1GB</td><td>880円</td><td>1.3円</td></tr>
    <tr><td>2vCPU / 4GB</td><td>3,520円</td><td>5.1円</td></tr>
    <tr><td>4vCPU / 8GB</td><td>7,040円</td><td>10.2円</td></tr>
    <tr><td>8vCPU / 16GB</td><td>14,080円</td><td>20.4円</td></tr>
  </tbody>
</table>

セキュリティ・コンプライアンス情報の構造化

クラウドインフラ選定では、セキュリティ認証とコンプライアンス対応が重要な判断基準です。 「ISMAP対応クラウド」「SOC 2取得 IaaS」といったクエリに対応するために、認証情報を一元的に公開します。

取得済み認証・準拠基準を一覧ページにまとめ、各認証の取得日・有効期限・対象範囲を明記します。

{
  "@type": "Organization",
  "name": "企業名",
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "name": "ISMAP（政府情報システムのためのセキュリティ評価制度）"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "name": "ISO/IEC 27001 (ISMS)"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "name": "SOC 2 Type II"
    },
    {
      "@type": "EducationalOccupationalCredential",
      "name": "ISO/IEC 27017（クラウドセキュリティ）"
    }
  ]
}

総務省（2024）のクラウドサービス情報開示指針に沿った形で情報を公開することは、AIが信頼性を判断する材料にもなります。

robots.txtとドキュメントのクロール許可

クラウドインフラ事業者は、APIドキュメントや技術ドキュメントを大量に持っています。 これらはGEOにおいて強力な資産です。 GPTBotやGoogle-Extendedに対して、/services/・/pricing/・/sla/・/regions/・/docs/・/blog/・/security/をAllowし、/console/・/api/v1/のみDisallowする設計が適切です。

管理コンソールやAPIエンドポイントは制限しつつ、ドキュメント・料金・SLA・リージョン情報はすべてクロールを許可します。

実装ロードマップ

フェーズ1：基盤整備（1〜2週間）。 Organization schemaとService schemaの実装、SLA専用ページの作成、料金テーブルのHTML化、robots.txtの見直し。

フェーズ2：コンテンツ整備（2〜4週間）。 リージョン情報ページの作成、代表的な構成例と料金試算の公開、セキュリティ認証一覧の整備。

フェーズ3：継続運用（月次〜四半期）。 料金改定の反映、新サービス・新リージョンの情報追加、稼働実績の定期公開、ドキュメントの更新。

まとめ

クラウドインフラ事業のGEO対策は、SLA・リージョン・料金・認証という選定の4大基準を機械可読な形で公開することが核心です。 Service schemaでのサービス情報構造化、SLA専用ページのHTML化、料金の基準値公開、リージョン情報の構造化が主要な施策になります。

クラウドインフラ選定は技術者と経営者の両方が関わる意思決定であるため、技術ドキュメントの整備とビジネス情報の構造化を並行して進める必要があります。 PDFや計算ツールに閉じた情報をHTMLに展開し、AIが比較・引用できる情報源を構築してください。

参考文献