B2B SaaS のための AI エージェント対応ガイド

「プロジェクト管理ツールを比較したい」「ヘルプデスクの SaaS でおすすめは?」 — 法人の意思決定者やエンジニアが AI に投げる質問のほとんどは、比較検討フェーズの問いだ。ここで AI がどのサービスの名前を出すか、つまりどのサービスが「業界で標準的な選択肢」として認識されているか、が今後の獲得チャネルを大きく左右する。

B2B の購買プロセスは「質問 → 比較 → 評価 → 試用 → 契約」と長期型なので、最初の「質問 → 比較」の局面で AI が出してくれるかがリードファネルの入口に直結する。B2C なら「買うかどうか」の判断が短くて AI の影響は限定的だが、B2B では「何を選ぶか」の比較に時間がかかるぶん、AI 経由の情報接触の機会が最大化される、という構造的な違いがある。

本記事では B2B SaaS プロダクトを運営する企業が AI エージェントから正しく認識・推奨されるための実装を、ページの種類ごとに整理していく。海外の好例として Stripe、Linear、Resend、Anthropic、Notion あたりを適宜引きながら。

トップページ

AI に「このサービスは何のサービスか」を 1〜2 文で伝えるのがゴール。<meta name="description"> を 80〜120 字で具体的に書く (「YomuScore は AI エージェント対応度を 47 項目で診断する SaaS。WordPress / Shopify など国内主要 CMS の改善ガイド付き。月額 980 円から」のような形)。Hero の h1 も 1 文で具体的な benefit を書く。AI は h1 を最優先で参照するので、装飾的なキャッチコピーよりも内容がはっきりした方が拾われやすい。

JSON-LD の SoftwareApplication を入れると、「これは SaaS だ」「カテゴリは Business Application だ」「価格は無料プランあり」を一発で AI に理解させられる。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "YomuScore",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Any",
  "description": "AI エージェント対応度を 47 項目で診断する SaaS",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "JPY",
    "category": "Free"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "ratingCount": "42"
  }
}
</script>

Organization の JSON-LD と組み合わせて、sameAs に SNS、GitHub、採用ページの URL を最低 3 つ並べておくと、会社のアイデンティティが多角的に裏付けられる。

料金ページ

AI が「いくらかかるの?」「どのプランから始めるべき?」に正確に答えられるようにするのが目的。各プランに Offer の JSON-LD を入れる (price / priceCurrency / billingDuration / includedBenefit が揃っていることが重要だ)。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "YomuScore Pro",
  "offers": [
    {
      "@type": "Offer",
      "name": "Monthly",
      "price": "980",
      "priceCurrency": "JPY",
      "priceSpecification": {
        "@type": "UnitPriceSpecification",
        "price": "980",
        "priceCurrency": "JPY",
        "billingDuration": "P1M"
      }
    }
  ]
}
</script>

加えて、プラン比較表は HTML テーブルで書くこと。スクリーンショット画像にしてしまうと AI がパースできない。「30 日間返金保証」「無料トライアル 14 日間」のような細かい条件もテキストで本文に入れておかないと、AI に聞かれた時に答えられない。

ドキュメント / ヘルプ

AI に実装例を引用してもらうのが目的のページ群。設計の鉄則は 1 ページ 1 トピック。「Webhooks の検証方法」「Stripe 連携のセットアップ」のように、URL とユーザーの質問と答えが三位一体になっている構成が AI 的に最も拾われやすい。

コードブロックには必ず言語タグ (bash / typescript / python 等) を付ける (P21 の対象でもある)。コード例の前後には文脈を 1〜2 文で添えて、何をするコードか、結果として何が起きるかを明示する。そして主要ページの Markdown ミラーは必須 — /docs/webhooks と /docs/webhooks.md の両方で配信する。詳細は Astro / Next.js Markdown ミラー実装を参照。

ロールモデルとして見るべきは Stripe Docs。各ページが「タイトル + 1 段落説明 + コード例 (複数言語タブ) + 関連リンク」というクリーンな構造で、AI が引用しやすい設計の教科書みたいな存在になっている。

API リファレンス

AI に「API を実際に叩ける状態」にしてもらうのが目的。OpenAPI 仕様の公開が前提で、/openapi.json への link rel と WebAPI の JSON-LD でドキュメントページから OpenAPI への導線を確保しておく (実装の詳細は OpenAPI を自動生成して AI エージェントに API を理解させる)。

各エンドポイントには Stoplight / Redoc / Swagger UI などで「Try it」UI を用意しておくと、AI 向けというより人間の検討者が即試せるので CV に効く。コード例は Python / TypeScript / cURL の 3 言語で書いておくと、AI が言語を問わずどれかを引用できる。

AGENTS.md

API や SDK を提供している SaaS では必須のファイル。最小例はこんな構成。

# YomuScore API

YomuScore は AI エージェント対応度スコアの REST API を提供します。

## Installation

\`\`\`bash
npm install @yomuscore/sdk
\`\`\`

## Configuration

\`\`\`
YOMUSCORE_API_KEY=sk_live_...
\`\`\`

## Usage

\`\`\`typescript
import { YomuScore } from '@yomuscore/sdk'

const client = new YomuScore({ apiKey: process.env.YOMUSCORE_API_KEY })
const result = await client.scan({ url: 'https://example.com' })
console.log(result.totalScore)
\`\`\`

## API Reference

See [openapi.json](/openapi.json) for the full spec.

雛形は YomuScore の AGENTS.md ジェネレーターで作れる。詳細は AGENTS.md とはを参照。

導入事例

AI が「〇〇社が使っている」「△△業界向け」と引用できるようにするのが目的。1 事例 1 ページの粒度で、業界・規模・導入前の課題・選定理由・効果数値を 1 ページに集約する。CaseStudy または Article の JSON-LD を入れて、about で導入企業の Organization を参照する。

数字は必ず本文テキストで書く。「導入後 6 ヶ月で問い合わせ対応工数が 40% 削減」のような数値を画像にしてしまうと AI からは読めない。フッターから「製造業の事例」「SaaS の事例」のような分類ページに飛べる構造にしておくと、AI が業界別に絞り込みやすい。

比較ページ

賛否分かれるが、自社で正確な比較ページを置くのは合理的だと思う。AI が誤情報で比較されるのを防げるし、検討フェーズのユーザーが Google で「YomuScore vs XYZ」と検索した時の受け皿にもなる。

公平な比較表を書くのが鉄則で、自社が劣る項目もちゃんと書く (このほうが信頼性は上がる)。比較対象は実在する競合のみに限定する — 仮想競合や勝手に作った比較は AI が誤って引用するリスクが高い。dateModified を JSON-LD で出力して更新日を明示しておくこと。

海外 B2B SaaS のロールモデル

各社のサイトを実際に見ると、AI エージェント対応の参考になるパターンが見つかる。

企業	学ぶべきポイント
Stripe	API ドキュメントの構造、コード例の多言語サポート、Markdown ミラー (`/docs/api.md` 等)
Linear	プロダクトページの 1 文ヒーロー、JSON-LD の網羅性、changelog の構造化
Resend	DX 重視のドキュメント構造、AGENTS.md (resend/resend-node) の充実度
Anthropic	API ドキュメントの「AI が叩く前提」設計、prompt caching の説明粒度
Notion	ヘルプセンターの 1 ページ 1 トピック設計、検索結果からの直リンク

筆者の主観だが、Stripe Docs は AI エージェント対応の教科書として 1 度全体を見る価値がある。

日本市場特有の事情

国内市場ならではの考慮点もいくつかある。1 つ目は「資料請求 → 商談」の文化で、海外より資料 PDF の重要度が高いこと。ただし AI は PDF を効率的に読めないので、PDF の内容を HTML や Markdown でも公開しておくのが現代的な対応になる。

2 つ目は特商法・個人情報保護法・電子帳簿保存法などの法令明記。フッターからの導線が必須で、AI に「特商法表記はある?」と聞かれた時に答えられないと信頼性が落ちる。

3 つ目は多言語対応。日本語をファーストにしつつ、海外展開しているなら EN 版を同じ構造で揃える (hreflang を全ページで出すこと)。

4 つ目は問い合わせ手段。電話番号とメールアドレスの両方を載せておくと、AI に問い合わせ先を聞かれた時に答えられる。

YomuScore のチェック項目との対応

B2B SaaS で特に重要なチェック項目を整理しておく。

YomuScore check	B2B SaaS での重要度
S1 (llms.txt)	サイトの主要ページ + ドキュメント目次として必須
S12 / S13 (AGENTS.md)	SDK / API を提供しているなら必須
S15 (OpenAPI)	API 提供サービスは必須
P10 / P11 (JSON-LD)	SoftwareApplication / Organization / Offer の組み合わせで
P15-P20 (Markdown ミラー)	ドキュメントから優先実装
P22 (API schema link)	リファレンスページから OpenAPI へのリンク

関連リンク