自社サイトのエージェント対応度を上げてみた——zench-aine.io を Level 1 から Level 2 へ（実践編）

ZenChAIne·2026年6月16日

AI AgentCloudflareWeb Standards

はじめに

前回（第1回）は、Cloudflare の Agent Readiness Score（＝「AI エージェント版の Lighthouse」）が何をチェックするツールなのかを解説しました。今回はその実践編として、実際に私たちのサイト zench-aine.io をスキャンし、出てきた不合格項目を直して Level を1つ上げるまでを、コードと Before/After のスコアつきで公開します。

机上の解説と違い、実際にやってみると「どの項目が自分のサイトに本当に関係するのか」を選ぶ判断が一番のポイントだと分かります。この記事は、その判断と実装の生の記録です。

なお zench-aine.io は、Next.js 15（App Router） に、MDX ベースのコンテンツ管理ライブラリ Velite を組み合わせて構築しています。この記事に出てくるコードはこの構成を前提にしていますが、考え方自体はどのフレームワークにも応用できます。

この記事のポイント

zench-aine.io の初回スキャンは Level 1「Basic Web Presence」（スコア 29） だった
コンテンツサイトに本当に効く2項目——Content Signals（robots.txt） と llms.txt——だけに絞って実装した
再スキャンで Level 2「Bot-Aware」（スコア 36） に昇格。次の Level 3 への条件も判明した

スキャン結果はどうだったか？

初回スキャンの結果は Level 1「Basic Web Presence」、スコアは 29 でした。isitagentready.com に https://zench-aine.io を入力した結果が以下です。

カテゴリ別に見ると、できている項目と空白の項目がはっきり分かれていました。

カテゴリ	結果
Discoverability	robots.txt ✅ / sitemap ✅ / Link ヘッダー ✅ / DNS-AID ❌
Content Accessibility	Markdown ネゴシエーション ❌
Bot Access Control	AI ボットルール ✅ / Content Signals ❌ / Web Bot Auth ⚪
Protocol Discovery	API カタログ・OAuth・MCP・Agent Skills など 0/7（すべて ❌）
Commerce	全項目 ⚪（非該当）

robots.txt と sitemap は元々あったので Discoverability は良好。一方で Protocol Discovery は総崩れ、Commerce は非該当（中立）でした。

どの項目を直すべきか？

ここが実践で一番大事な判断です。結論から言えば、全項目を埋めにいかず、コンテンツサイトに本当に効く項目だけを選びました。

第1回で書いたとおり、Protocol Discovery（MCP・OAuth・API カタログ）は エージェントに API やサービスを提供する側のシステム向けの項目で、記事を読ませるメディアサイトには基本的に不要です。Commerce は EC サイト向けなので、物販のない私たちには非該当。これらを無理に埋めるのは、サイトの実態に合わない「スコアのための工作」になってしまいます。

そこで、診断ツールが示す「次のレベルの条件」を確認しました。isitagentready.com のスキャン結果には nextLevel（次のレベルに必要な項目）が含まれており、Level 2「Bot-Aware」になる条件は Content Signals ただ1つでした。これは確実に届く改善です。あわせて、メディアサイトとして純粋に価値が高い llms.txt も用意することにしました。

robots.txt に Content Signals を追加する

最初の改善は Content Signals です。Content Signals とは、robots.txt の中でコンテンツの利用許諾を機械可読に宣言する仕組みで、search（検索利用）/ ai-input（AI の回答生成での利用）/ ai-train（モデル学習での利用）の3つを宣言できます。

私たちはオウンドメディアとして「検索・AI 回答での引用は歓迎するが、モデル学習への利用は許可しない」という方針にしました。Next.js のメタデータ API（app/robots.ts）では Content-Signal: 行を出力できないため、Route Handler で robots.txt を直接生成します。

typescript

// app/robots.txt/route.ts
const ROBOTS_TXT = `# robots.txt for zench-aine.io
User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /
Disallow: /api/
Disallow: /admin/
Disallow: /private/
 
User-Agent: GPTBot
Allow: /
 
User-Agent: Google-Extended
Allow: /
 
User-Agent: PerplexityBot
Allow: /
 
Sitemap: https://zench-aine.io/sitemap.xml
`
 
export const dynamic = 'force-static'
 
export function GET() {
  return new Response(ROBOTS_TXT, {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' },
  })
}

既存の app/robots.ts（メタデータ版）と app/robots.txt/route.ts（Route Handler 版）は共存できません。Content Signals のように標準の robots メタデータにない行を出したい場合は、Route Handler に一本化します。

llms.txt でAI向け目次を用意する

次に llms.txt です。llms.txt とは、サイトのルートに置く Markdown 形式の「AI 向け目次」です。 LLM がサイト全体を読み込めない制約を補い、記事の発見・引用をしやすくします。前述の Velite が生成する記事メタデータから動的に組み立てれば、記事を追加するたびに自動で反映できます。

typescript

// app/llms.txt/route.ts
import { posts } from '#site/content'
 
const BASE_URL = 'https://zench-aine.io'
export const dynamic = 'force-static'
 
export function GET() {
  const jaPosts = posts
    .filter((p) => p.published && p.locale === 'ja')
    .sort((a, b) => (a.date < b.date ? 1 : -1))
 
  const lines = jaPosts
    .map((p) => `- [${p.title}](${BASE_URL}/media/${p.slug}): ${p.description}`)
    .join('\n')
 
  const body = `# ZenChAIne\n\n> AI とブロックチェーンの最前線を扱うオウンドメディア。\n\n## メディア記事\n\n${lines}\n`
  return new Response(body, {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' },
  })
}

なお llms.txt は Agent Readiness Score の21項目には含まれていません（スコアには直接効きません）。それでも実装したのは、AI 検索や AI エージェントに記事を見つけてもらいやすくする効果が期待できるからです。スコアと実利は必ずしも一致しない、という良い例でもあります。