Infrastructure — キャッシュ、エラー、リダイレクト

「Infrastructure」とは?

Infrastructure グループは、エージェントがオリジンと確実にやり取りできるかどうかを左右する低レベルの HTTP の振る舞いを扱います。どれも特定のプロトコルに依存しません — MCP エンドポイント、OpenAPI スペック、静的コンテンツのみ、いずれを提供するサイトにも適用されます。

HTTPS リダイレクト

エージェントはリンクを辿ります。http://yourdomain.com が https://yourdomain.com にリダイレクトされない場合、HTTP URL にたどり着いたエージェントはダウングレードするか、そのまま失敗します。現代の AI クライアントは平文 HTTP を完全に拒否することが多いです。

修正: http://yourdomain.com/* から HTTPS の同じパスへ 301 または 308 を返してください。ほとんどのプラットフォーム(Cloudflare、Vercel、Heroku、build.io)では自動で行われます。自前ホスティングなら、ポート 80 でリッスンしてリダイレクトを発行する nginx の server ブロックを追加します。

Sitemap.xml

エージェントは /sitemap.xml から URL の一覧を発見します。これがないと、エージェントが到達できるのはトップページからリンクされたパスや llms.txt で宣言されたパスだけ — 実コンテンツのごく一部に限られます。

修正: /sitemap.xml で XML サイトマップを配信します。Next.js、Hugo、Jekyll、Wordpress などのフレームワークは自動生成します。手書きする場合:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://yourdomain.com/</loc></url>
  <url><loc>https://yourdomain.com/docs</loc></url>
</urlset>

キャッシュヘッダー

適切に構成されたサーバーは、レスポンスに Cache-Control、ETag、Last-Modified のうち少なくとも 1 つを必ず付与します。これらが無いと、エージェントは再取得すべきかキャッシュを使うべきか判断できず、毎回ダウンロードする(遅く高コスト)か、古いキャッシュを使い続ける(誤ったデータ)ことになります。

修正: ほとんどの Web フレームワークは静的ファイルに対しては既定で設定します。動的レスポンスでは明示的に Cache-Control を設定してください:

// Express — たまに変わるコンテンツ向け
res.set('Cache-Control', 'public, max-age=3600');

// 絶対にキャッシュしない場合(これでもチェックは満たします):
res.set('Cache-Control', 'no-store');

no-store も有効なキャッシュヘッダーと見なされます — 「キャッシュしないでほしい」という有用な情報そのものだからです。チェックが失敗するのは、キャッシュヘッダーが *まったく* 無いときです。

構造化エラー (JSON 404)

エージェントが誤った URL にアクセスしたとき、(ナビゲーション、フッター、検索ボックスなどを含む)HTML の 404 ページはトークンを浪費し、混乱したエージェントには本物のコンテンツに見えてしまうことすらあります。JSON の 404 は、小さくパース可能なエラーを返します:

{ "error": "not_found", "path": "/wrong-url" }

修正: 404 ハンドラでコンテンツネゴシエーションを使用します。クライアントが Accept: application/json を送ってきたら JSON を返し、それ以外は HTML を返します。Express の例:

app.use((req, res) => {
  res.status(404);
  res.format({
    'application/json': () => res.json({ error: 'not_found', path: req.path }),
    'text/html': () => res.send('<h1>404 Not Found</h1>'),
    default: () => res.json({ error: 'not_found', path: req.path }),
  });
});

この変更は人間からは見えません(ブラウザは Accept: text/html を送って HTML を受け取ります)が、エージェントにとっては劇的です(Accept: application/json を送ってパース可能な JSON を受け取れるようになります)。

レートリミットヘッダー (オプション)

サービスがレートリミットを行う場合は、X-RateLimit-Remaining、X-RateLimit-Reset、Retry-After のいずれかで状態を公開してください。リミットに達したエージェントは、適切な時間だけ待ってから再試行できるようになり、いきなり失敗することがなくなります。

このチェックがオプションなのは、ほとんどのサイトではそもそもレートリミットを行わないためです — API プロバイダや SaaS アプリのみが行います。静的サイトには公開すべきものがありません。

なぜ必須なのか

キャッシュヘッダー、構造化エラー、サイトマップ、HTTPS リダイレクトは、多くのサイトで今日「無害に」失敗しています — そしてそれが論点です。それぞれが、人間には気付かれないがエージェントには実害となる摩擦点を表しています。これらをオプションから必須に格上げすることは、「エージェント対応」サイトはプロトコル固有のチェック(MCP、OpenAPI、x402 など)だけでなく、これらにも対処すべきという立場の表明です。

agentgrade