技術 約16分で読めます

Cloudflare Agent MemoryとAgent Readinessスコア

Cloudflare AIエージェント Durable Objects Vectorize Workers AI MCP LLM
いけさん目次

Cloudflareが2026-04-17のAgents Weekで Agent Memory と isitagentready.com をほぼ同時にリリースした。
前者はエージェントの記憶をプラットフォーム側で管理するマネージドサービス、後者はWebサイトがどれだけエージェントに使いやすい状態になっているかを点数化するLighthouse的なツールだ。
片方は「エージェントの中身」（長期記憶）、もう片方は「エージェントが読みに行く先」（サイト側の対応度）で、同じ週の中で両端を同時に埋めに来ている。

同時発表の他のリリースは Sandboxes GA・Durable Object Facets・統合CLI、Mesh・エンタープライズMCP参照アーキテクチャ、Project Think・Browser Run刷新・Workflows v2 を参照。

Agent Memory

Agent MemoryはAIエージェントの会話履歴から重要な情報を取り出し、後で必要になったときに呼び戻すためのマネージドサービスとしてprivate betaで公開された。

従来のエージェントは会話がコンテキストウィンドウを超えると過去を忘れるか、全履歴を毎回プロンプトに詰め込んで精度が劣化する（context rot）のどちらかだった。
Chroma Context-1 や Compresr Context Gateway はこの問題をエージェント側・プロキシ側で解決しようとしたが、Cloudflareはプラットフォーム側でマネージドサービスとして提供する方向に舵を切った。

4つの操作と4つの記憶タイプ

Agent Memoryが提供するAPIは意図的に絞り込まれている。

操作役割
ingest会話履歴を一括で読み込み、記憶を抽出して格納する
rememberモデルが実行中に「これは覚えておく」と明示的に書き込む
recall質問を投げて合成済みの答えを返す
forget / list記憶の削除と一覧

格納される記憶は4種類に分類される。

タイプ性質例
Facts不変に近い事実このプロジェクトはGraphQLを使っている
Events時刻付きの出来事2026年4月15日に本番デプロイした
Instructions手順や規約デプロイ前にlintを必ず回す
Tasks作業中のエフェメラルな項目PR #123のレビュー待ち

FactsとInstructionsには正規化されたトピックキーが付く。
同じキーで新しい記憶が入ると古いものを置き換える（supersession）仕組みで、重複ではなくバージョンチェーンとして管理される。
Eventsは時刻で区別されるので累積していく。Tasksは完了すれば捨てられる前提の短命な記憶だ。

この分類が効いているのは、取り出すときの戦略を変えられる点だ。
「GraphQLを使っているか」はFactsのキールックアップで即答できるが、「先月何をデプロイしたか」はEventsの時系列検索になる。
全部を同じベクトル検索に流し込むよりも効率的だ。

取り込みパイプライン

Agent Memoryの取り込みは多段の処理になっている。

flowchart TD
    A[会話メッセージ] --> B[SHA-256ハッシュでID生成<br/>128ビット切り詰め]
    B --> C{既に存在?}
    C -->|Yes| Z[スキップ<br/>INSERT OR IGNORE]
    C -->|No| D[抽出パス]
    D --> E[Fullパス<br/>10K文字チャンク<br/>2メッセージ重複]
    D --> F[Detailパス<br/>9メッセージ以上で発動<br/>名前・価格・バージョン狙い]
    E --> G[検証 8項目]
    F --> G
    G --> H[分類<br/>Facts/Events/Instructions/Tasks]
    H --> I[Durable Object書き込み]
    I --> J[非同期ベクトル化<br/>3-5クエリ変換を追加]
    J --> K[Vectorizeに格納]

ポイントがいくつかある。

1本目はID生成の決定性。SHA-256で内容アドレスを作るので、同じ発言を何度ingestしてもDBには1回しか入らない。エージェントが再起動して履歴を丸ごと再投入しても冪等に動く。

2本目は抽出の二段構え。
Fullパスは10,000文字ごとにメッセージをチャンクして全体の要約寄りの記憶を取る。最大4チャンクまで並列で処理する。
Detailパスは9メッセージ以上の会話でのみ動き、具体的な数値や名前を狙い撃ちする。
要約だけだと「バージョン2.3.1で動かした」のような具体情報が落ちやすいので、細部専用のパスを分けているわけだ。

3本目はベクトル化の工夫。
Facts/Instructionsは宣言文として保存されるが、ユーザーが投げてくるクエリは疑問文だ。「ダークモードが好き」と「どのテーマが良い?」はベクトル空間で必ずしも近くない。
Agent Memoryは保存時に3〜5個のクエリ変換（「どのテーマ?」のような疑問文への書き換え）を追加してから埋め込むことで、この宣言と疑問のギャップを埋めている。

取り出しは5チャネル並列＋RRF

recallの内部では5本の検索チャネルが並列で走る。

チャネル何が得意か
全文検索Porterステミングでキーワード精度を稼ぐ
Fact-keyルックアップ正規化キーの直接マッチ
生メッセージ検索逐語的な断片を取りこぼさない最後の砦
直接ベクトル検索クエリ埋め込みで意味的に近いものを拾う
HyDEベクトル検索仮想的な回答ドキュメントを生成して埋め込む

HyDE（Hypothetical Document Embedding）は抽象的な質問やマルチホップな質問に効く古典的な手法だ。
「ユーザーの好みは?」のような曖昧なクエリから、仮の回答文を一度LLMに書かせ、その回答の埋め込みで検索する。
質問より回答のほうが検索対象の文書と似ている傾向を利用したテクニックだ。

5本の結果はReciprocal Rank Fusion（RRF）で統合される。
各チャネルが返したランキングを重み付きで合算する古くからある手法で、Fact-keyマッチが最も重く、同点は新しいものを優先する。
最後に合成段階で自然言語の回答を作るが、時刻計算はLLMに任せず正規表現と算術で決定的に処理する。
「2週間前のあの件」のような相対時刻はLLMに聞くとぶれるので、別経路で正確に計算する設計だ。

モデル選定

役割ごとに別モデルを使い分けている。

タスクモデル備考
抽出・検証・分類・クエリ解析Llama 4 Scout17B MoE・16エキスパート
合成・回答生成Nemotron 3120B MoE・アクティブ12B

構造化タスクは軽いモデルで捌き、推論が必要な合成だけ大型モデルを使う。
推論コストの節約と品質のバランスを取った構成だ。
どちらもWorkers AIで動くので、外部API呼び出しのレイテンシやレート制限から解放される。

Cloudflareプリミティブだけで組まれている

Agent Memoryの中身はCloudflare既存プリミティブの組み合わせだ。

コンポーネント役割
Durable ObjectsSQLiteバックドの生メッセージ・分類済み記憶の保管
Vectorize埋め込みとセマンティック検索
Workers AI抽出・分類・合成のLLM推論

各メモリプロファイルがそれぞれ専用のDurable Objectインスタンスとベクトルインデックスを持つ。
テナント間の隔離が構造的に保証され、書き込みもトランザクショナルだ。

Workerからの利用はバインディング経由でシンプルだ。

const profile = await env.MEMORY.getProfile("profile-name");

await profile.ingest(messages, { sessionId });
await profile.remember({ content, sessionId });

const results = await profile.recall("query");

Cloudflare外のエージェントからはREST APIで叩ける。
セッションアフィニティヘッダで同じバックエンドにルーティングされるので、プロンプトキャッシュの恩恵を受けやすい設計になっている。

用途と社内ドッグフーディング

Cloudflareが挙げているユースケースは4種類ある。

  • 単一エージェントがセッションをまたいで状態を保つ
  • チーム共有のナレッジ（アーキテクチャ決定、設計パターン、暗黙知）
  • ツール間の協調（コードレビューボットがコーディングエージェントに情報を渡す）
  • バックグラウンドで自律動作するエージェントの永続状態

社内では OpenCode プラグインの開発ワークフロー統合、アジェンティックなコードレビュー（過去の判断を覚えて同じ指摘を繰り返さない）、永続的な会話履歴を持つチャットボットなどに投入済みだという。

開発プロセス自体がエージェント駆動で、ベンチマーク実行→ギャップ分析→解決策の提案→人間の検証→エージェントによる実装、というループを回している。
評価にはLoCoMo、LongMemEval、BEAMといった複数のメモリベンチマークを併用し、単一指標へのオーバーフィットを避けている。

データ所有権

記憶は全てエクスポート可能だ。Cloudflareはベンダーロックインを避ける方針を明示している。
プラットフォーム側がエージェントの記憶を握るのは便利だが、それが囲い込みの道具になると困る。
エクスポートAPIが最初から存在するのはその懸念への回答になっている。

エージェント記憶層としての位置付け

エージェントの記憶問題はこれまで Chroma Context-1 のような推論時のコンテキスト管理、Compresr Context Gateway のようなプロキシ層、Claudeの1Mコンテキスト のようなウィンドウ拡大、と複数の方向から攻められてきた。
Agent Memoryはそれを「エージェントの外に置かれた共有ストア」として切り出した点が特徴的だ。
Fact-keyのsupersessionで宣言的知識を整合させ、HyDE+RRFで検索品質を担保する作りは、RAGで蓄積されてきた知見をエージェント向けに仕立て直したものと見ることもできる。

private beta段階でウェイトリストが開いている。
Cloudflareエコシステムでエージェントを動かしているなら、自前で記憶管理を書く前に試す価値がある。

Agent Readinessスコアとisitagentready.com

同じAgents Weekで isitagentready.com が公開された。
自分のサイトのURLを入れると、AIエージェントがどれだけ使いやすい状態になっているかを点数化してくれる。
LighthouseがWebパフォーマンスとアクセシビリティに対してやってきたことを、エージェント時代のWeb標準に対してやろうというわけだ。
同時に、Cloudflare Radarが全世界の主要20万ドメインをスキャンして「AIエージェント標準の採用率」を公開した。
結論だけ言うと、Webはまだほとんどエージェント対応になっていない。

いま測られているエージェント標準

isitagentready.comは4つのカテゴリを独立して採点する。

カテゴリチェック項目
Discoverability（発見容易性）robots.txt、sitemap.xml、Link Headers（RFC 8288）
Content（コンテンツ到達性）Markdown content negotiation
Bot Access Control（ボット制御）Content Signals、robots.txtのAI bot rule、Web Bot Auth
Capabilities（能力公開）Agent Skills、API Catalog（RFC 9727）、OAuth discovery（RFC 8414/9728）、MCP Server Card、WebMCP

別枠で x402、Universal Commerce Protocol、Agentic Commerce Protocolといった「エージェントが支払いを行う」ための標準もチェックされるが、現時点ではスコアには含まれない。

馴染みがない読者のために簡単に補足する。

  • Markdown content negotiation。エージェントが Accept: text/markdown を送ってきたら、サーバはHTMLの代わりにMarkdown版を返す。HTMLに比べてトークン消費を最大80%削減できる、とCloudflareは測定している。
  • Content Signals。robots.txtに Content-Signal: ai-train=no, search=yes, ai-input=yes のように書くことで、「AI学習には使わせない」「検索インデックスは許す」「推論時のgrounding用には許す」を別々に宣言できる。ただの allow/deny より細かく制御できる。
  • Web Bot Auth。IETFドラフトの「bot自身がHTTPリクエストに署名し、受け手は公開鍵で検証する」仕組み。公開鍵は /.well-known/http-message-signatures-directory に置く。
  • MCP Server Card。/.well-known/mcp/server-card.json に「このサーバはどのツールを公開していて、どこに繋げばよいか、認証はどうするか」をJSONで書いておけば、エージェントは接続前に能力を知ることができる。
  • API Catalog（RFC 9727）。/.well-known/api-catalog でサイトが提供する公開APIのカタログをエージェントに渡す。開発者ポータルをスクレイプさせる必要がなくなる。
  • OAuth discovery（RFC 9728）。ログインが必要なサイトで、エージェントに認可サーバの場所を伝える。ユーザが明示的にOAuthフローで許可を出せるため、「ブラウザのログインセッションをエージェントに共有する」というあまり安全でない回避策を使わずに済む。Agents Week 2026ではCloudflare Accessもこのフローに完全対応したと発表された。

世界のエージェント対応度は「ほぼゼロ」

Cloudflare Radarが200,000ドメインをスキャンした結果を新しい「Adoption of AI agent standards」チャートで公開している。強い数字だけ抜き出すとこうなる。

項目採用率
robots.txtが存在する78%
robots.txtでContent Signalsを宣言4%
Accept: text/markdown に正しくMarkdownを返す3.9%
MCP Server Card + API Catalog（RFC 9727）の両方全20万ドメイン中15件未満

robots.txtはほぼ普及しているが、そのほとんどは伝統的な検索クローラ向けで、AIエージェント向けに書かれているものはまだ少数派。
MCP Server CardやAPI Catalogに至っては、「全世界の人気サイト20万件のうち15件に満たない」という状態だ。
ここはそのまま「早期に採用すれば目立てる余地が大きい」という裏返しでもある。

チャートはWeekly更新で、Radarの「AI Insights」ページからカテゴリ別に見られる。
Data ExplorerやRadar APIからも取れる。

isitagentready.com自体が参照実装

この採点サイト自体がエージェント対応の参照実装になっている点は押さえておきたい。

  • https://isitagentready.com/.well-known/mcp.json にStreamable HTTPの stateless MCPサーバ を公開。scan_site ツールを呼び出せば、Web UIを使わずMCP経由でスキャンを実行できる。
  • https://isitagentready.com/.well-known/agent-skills/index.json にAgent Skillsのインデックスを公開。チェック対象の各標準について「何をすればパスするか」まで書いた実装ガイドを提供している。

さらに各失敗チェックには「この失敗をコーディングエージェントに渡すと直してくれるプロンプト」が付いてくる。
点数を見て終わりではなく、そのまま自分のエージェントに直させられる設計になっている。

Cloudflare URL Scannerとの統合

Cloudflareがもともと提供している URL Scanner にAgent Readinessタブが追加された。
既存のHTTPヘッダ・TLS・DNS・技術スタック・セキュリティシグナル分析と並んで、同じチェック一式がそのまま走る。
APIから叩く場合は agentReadiness: true をオプションで付ける。

curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -d '{
    "url": "https://www.example.com",
    "options": {"agentReadiness": true}
  }'

Lighthouse的スコアを自分のCIや監視に組み込めるようになるので、エージェント対応を継続的に回したい組織にとっては使いやすい。

Cloudflare Docsを世界で最もエージェントフレンドリーに作り替えた話

個人的に今回の記事で一番価値があると思ったのはここ。
Cloudflareは自社のDeveloper Docsを徹底的にエージェント向けに作り直し、実際に他のドキュメントサイトと比較したベンチマーク数値まで出している。

URLフォールバック /index.md

2026-02時点でテストしたエージェント7本のうち、デフォルトで Accept: text/markdown ヘッダを送るのはClaude Code、OpenCode、Cursorの3つだけだった。
残りのエージェントのために、URLベースのフォールバックを用意している。

具体的には、任意のページのURLに /index.md を付けるとMarkdown版が返る。

https://developers.cloudflare.com/r2/get-started/index.md

ポイントは、静的ファイルを二重に置いて同期させるのではなく、Cloudflareのルール2本でダイナミックに実装していること。

  1. URL Rewrite Ruleで /index.md で終わるリクエストをマッチさせ、regex_replace で /index.md を剥がしたベースパスに書き換える。
  2. Request Header Transform Ruleが書き換え前のパス（raw.http.request.uri.path）に対してマッチし、Accept: text/markdown ヘッダを自動で付与する。

これで /index.md パスにアクセスすれば、クライアントが何のヘッダを送っていようがMarkdownが返る。
ビルド処理もコンテンツの二重管理もいらない。

flowchart LR
  A[エージェントが<br/>/r2/get-started/index.md にGET] --> B[Header Transform Rule<br/>raw.uri.path に /index.md<br/>→ Accept: text/markdown を付与]
  B --> C[URL Rewrite Rule<br/>/index.md を regex_replace で剥がす]
  C --> D[本来のページが<br/>Markdownで返る]

大規模サイトでのllms.txtのたたみ方

llms.txtは2024年9月に提案された仕様で、「このサイトが何で、どんなコンテンツがどこにあるか」をLLMが読める形で書いた、サイトルート直下のプレーンテキストファイル。
検索クローラ向けのsitemapに相当するものをLLM向けに用意したものだ。

ただ5,000ページを超えるドキュメントを1枚のllms.txtに押し込むと、どのモデルでもコンテキストウィンドウを食い潰す。
Cloudflareはトップレベルディレクトリ単位でllms.txtを分割し、ルートのllms.txtからそれらを参照する構造にした。

https://developers.cloudflare.com/llms.txt          ← 親。各プロダクトへのインデックス
https://developers.cloudflare.com/r2/llms.txt
https://developers.cloudflare.com/workers/llms.txt

加えて、LLMにとって意味が薄いディレクトリ一覧ページを大胆に削った。
たとえば https://developers.cloudflare.com/workers/databases/ のような「ローカライズされた単なる目次ページ」約450ページをllms.txtから除外。
子ページはすでにllms.txtに個別に列挙されているので、目次ページを残すと「本物のコンテンツに辿り着くためにもう一往復エージェントに取りに行かせる」ムダになる、という判断だ。

エントリそのものの品質も上げている。
各リンクにセマンティックな名前、正確なURL、価値の高いdescriptionが付いていて、LLM側に「どのページを読みに行けば目的の情報があるか」を一発で判断させる。
Product Content Experience（PCX）チームがページタイトル・description・URL構造をエージェント目線で書き直したとのこと。

隠しディレクティブと、古いドキュメントの扱い

すべてのHTMLページにLLM向けの「見えない注意書き」が埋め込まれている。
エージェントがHTML版を取得したときに「HTMLはコンテキストを浪費する。この末尾に /index.md を足すか、Accept: text/markdown で取り直せ。全ドキュメントは https://developers.cloudflare.com/llms-full.txt に単一ファイルで置いてある」という内容を教える。
ただしこのディレクティブはMarkdown版からは取り除かれている。
Markdownの中にも同じ注意書きが残っていると、エージェントが「Markdownのなかに書いてあるMarkdown版を探しに行く」再帰ループに陥るからだ。

もうひとつ目を引いたのが Redirects for AI Training（2026-04-17に発表された新機能）との組み合わせ方。
Wrangler v1のような旧版ドキュメントは人間向けには履歴として残したいが、LLMクローラにそのまま食わせると「現役の助言」として再生産されてしまう。
Cloudflareは、AI学習用クローラと判定したアクセスだけを現行ドキュメントにリダイレクトする。
人間には履歴アーカイブをそのまま見せつつ、LLMには最新版だけを学習させる、という非対称運用だ。

ベンチマーク結果

OpenCode + Kimi-k2.5を使って、他の主要な技術ドキュメントサイトと比較したそうだ。

指標Cloudflare Docs平均的な他サイト
同じ質問に答えるまでのトークン消費基準+31%多い
正答までの時間基準+66%遅い

「1つのプロダクトディレクトリが単一コンテキストに収まる」設計が効いていて、エージェントは該当ページを1発で特定して取りに行ける。
Cloudflareはこの差の原因を「grepループ」と呼んでいる。
llms.txtが巨大すぎてコンテキストに入らないサイトでは、エージェントはファイル全体を読めずキーワードgrepで探し始める。
1回目のgrepが外すと、思考トークンを生成し、検索クエリを練り直し、もう一度叩く。これを繰り返すので遅く・高く・精度も下がる。

ドキュメントの構造そのものがエージェントの振る舞いとコストを決める、という話で、llms.txtを置くだけではダメで、粒度設計まで込みで面倒を見る必要がある、というのは良い警告だと思う。

実務への影響

「サイトをエージェント対応にする」作業は、2026年の時点ではまだオプション扱いだが、Radarの数字を見る限り、数か月で「やっていないと発見されない」フェーズに入ってもおかしくない。
特にSaaSやAPIを提供している側は、MCP Server Card・API Catalog・OAuth discoveryあたりを早めに置いておくと、エージェントから選ばれる確率が上がる。

個人サイト・小規模サイトの場合は、いきなりMCPサーバを立てるより、まず Accept: text/markdown への対応とContent Signalsの宣言を進めるのが費用対効果が高い。
Markdownコンテンツ交渉は実装もほぼタダで、トークン消費を大幅に下げてエージェントに選ばれやすくする。

コードを書くエージェントを回している側からすると、isitagentready.comが返すプロンプトをそのまま自分のClaude CodeやCodexに渡して修正させる、というワークフローが今日から使える。
Lighthouseのときと違って、点数を上げる実装作業自体をエージェントに外注できるのが面白い。