自然言語でインターネットデータを問い合わせる時代へ
Cloudflare Radarが2020年にローンチして以来、グローバルなインターネットトラフィックデータをオープンAPIとして提供してきたことは多くの方がご存じでしょう。人権活動家、ジャーナリスト、研究者、ネットワークオペレーターが実務でこのデータを活用しています。
しかし問題がありました。データはオープンでも、アクセス障壁が高すぎたのです。答えを得るには適切なページを探し、フィルターを選び、APIドキュメントを読んでクエリを書く必要がありました。締切に追われる記者が「イランのインターネット遮断」を取材する場面を想像してみてください。ページを巡回してグラフを探す時間などあるはずがありません。
そこでCloudflareがAgents Weekに合わせてベータ公開したのが Radar Researcher です。自然言語で質問するだけで、実際のインタラクティブチャート付きの回答が返ってきます。本記事では、このツールが単なる「AIチャットボットの貼り付け」と何が違うのかを、アーキテクチャの観点から掘り下げます。
本記事はCloudflare公式ブログの根拠資料を基に再構成したものです。
核心は「3つのツール」で数百APIを扱う設計
最も興味深いのは、Radar ResearcherがRadarの数百エンドポイントごとにツールを手書きしていない点です。代わりにCloudflare MCPサーバーへ Code Mode で接続しています。モデルに渡すツールはたった3つです。
search: OpenAPIスペックから適切なエンドポイントを検索execute: 実データを取得するコードスニペットを実行docs: APIドキュメントを参照
つまりLLMが 自らコードを書いて Radar APIを直接呼び出します。Radarに新しいデータセットが追加されても、プロンプトやツール定義を変更する必要がありません。APIスペック全体がMCPサーバー上に存在するからです。
チャートを「数値」ではなく「スペック」としてレンダリングする工夫
ここに本当に学ぶ価値のあるディテールがあります。LLMは基本的にMarkdownで回答します。しかしモデルがデータを直接文章に書き込むと、四捨五入し、要約し、切り捨てる癖があります。データツールとしては致命的です。
Cloudflareの解決策は、データをモデルの散文から 完全に分離 することです。モデルは数値を貼り付ける代わりに、APIパスのみを参照する軽量なチャートスペックをemitします。
{ "type": "speedFlower", "title": "Internet speed quality — Portugal", "dataFrom": "/radar/quality/speed/summary?location=PT" }
フロントエンドはこの dataFrom を実際のfetch結果とマッチングし、サイト全体で使用しているものと同一の可視化コンポーネントでレンダリングします。結果として チャートは常にAPI原本に忠実 であり、時系列・ドーナツ・地図・ヒストグラムなどRadarの可視化語彙全体をそのまま再利用できます。
インフラスタック: すべてCloudflare
- コンピュート: Cloudflare Worker上でAgents SDKを稼働
- 状態: 会話ごとにDurable Object + SQLite DB(ストリーミング応答中にページ離脱してもサーバー側で生成継続)
- 推論: Workers AIでKimi K2.7などのオープンモデルを実行。単一モデルに賭けず 3モデルファミリーのフォールバックチェーン を回し、特定プロバイダ障害に耐える設計
- ゲートウェイ: AI Gatewayでロギング・コスト追跡・キャッシュ・セーフティガードレール
- ストレージ: 共有会話はR2、フロントエンドは別Worker + service binding
なお、こうしたマルチエージェントアーキテクチャを実務でどう運用するかは、Spotifyが広告プラットフォームをマルチエージェントアーキテクチャで再構築した理由の記事でより深く扱っています。フォールバックチェーンとエージェントオーケストレーションの観点から併せて読むと理解が深まります。
WebMCP: 「他人のエージェント」のための準備
Cloudflareが今回打った本当の勝負手はここです。自社エージェントだけでなく、ブラウザ上で動作する汎用エージェントがRadarを直接操作できるよう WebMCP標準を先行実装しました。
従来、エージェントがウェブサイトを利用するにはページをスクレイピングしDOMを逆解析する必要がありました。遅く、壊れやすく、エラーだらけです。WebMCPはページが よく定義されたツールセットを登録 すれば、ブラウザエージェントがそれを発見して直接呼び出せるようにします。
| 区分 | 従来のスクレイピング方式 | WebMCP方式 |
|---|---|---|
| アプローチ | DOM解析・推測 | 登録済みツールを直接呼び出し |
| 安定性 | ページ変更で破損 | 仕様ベースで安定的 |
| 速度 | 遅い(レンダリング待ち) | 速い(直接実行) |
| 実装コスト | エージェントごとに再作業 | ページが一度登録 |
| 標準化 | なし | W3Cで議論中の標準 |
Cloudflareは両方式をサポートしています。
- Imperative API: JSでツールを登録し、UIを駆動するコードを直接呼び出し。国・地域・大陸・ASNのフィルタリング、日付範囲変更、エンティティ検索など
- Declarative API: 既存HTMLフォームに属性を数個付与するだけでツール化。URLスキャナー、ドメインレポート照会、ポスト量子TLSサポートテストなど
興味深いのは 自社が売るものを自社で先に適用した 点です。RadarのURL Scannerには「エージェント準備度」チェックがあり、ここにWebMCP統合の有無を検査する項目があります。Cloudflareが自ら実装したことで、Radarは自身のチェックを通過するようになりました。
注意点: まだベータであり、限界も明確です
- ベータ段階: データセットのカバレッジはまだ全体ではなく、分析精度もチューニング中です。
- LLMハルシネーションリスク: チャートはAPI原本を参照するため安全ですが、説明テキストは依然としてモデルが生成 します。数値解釈部分は必ず原本チャートと照合して読む必要があります。
- WebMCPはまだ標準化進行中: ブラウザサポートが本格化するまではアーリーアダプター領域です。
- 共有リンクは30日で失効: 会話共有リンクは自動失効するため、長期保管が必要な場合は別途保存してください。
次のステップ学習方向
このアーキテクチャを自身で追いかけたい場合、以下の順序を推奨します。
- Cloudflare Agents SDK + Durable Object で状態を保持する対話型エージェントの骨組みを作る
- MCPサーバー + Code Mode パターンでツール爆発問題を解決する(ツールN個 → ツール3個)
- AI Gatewayフォールバックチェーン でプロバイダ障害に耐える推論レイヤーを構成
- WebMCP で自サービスにエージェントフレンドリーなインターフェースを載せる
特に2番は近年のエージェント開発の核心トレンドですので、関連してKimi Code CLIにVercelプラグイン登場! エージェンティック開発時代の新しい標準の記事も併せて読むと流れが掴めるでしょう。
まとめ: 「ツールを作るツール」へ移行している
Radar Researcherを一文で要約するとこうです。「エージェントにツールを大量に握らせるな、コードを書くペンを一本だけ握らせよ。」
数百エンドポイントをツールとして公開すれば、プロンプトは膨張し保守は地獄になります。代わりにOpenAPIスペックをMCPサーバーに置き、モデルにsearch→execute→docsの3動作だけでコードを書かせる。これが現在のエージェントアーキテクチャの実践的解答です。
日本の開発現場の観点で見ると、このパターンは 社内APIが数十〜数百個あるエンタープライズ環境 で特に有効です。毎回ツールを手でラッピングする代わりに、OpenAPIスペックさえ整備しておけばエージェントが自動で探して使います。ただし社内ネットワークや権限体系が絡む場合、MCPサーバー側で認可レイヤーを必ず設計すべきであり、LLMが生成したコードが実際にどのクエリを発行したか 監査ログ(trace) を残すことが必須です。Cloudflareが「Audit the reasoning」機能を入れた理由がまさにそれです。
結局この事例が投げかけるメッセージは明確です。ウェブはもう人間だけが読む文書ではなく、エージェントが呼び出すインターフェースになるべき だということ。WebMCPがその狼煙です。残りの2026年、自サービスがエージェントフレンドリーかどうか、一度自問してみる価値があります。
Radar Researcherは現在Cloudflare Radarでベータ利用可能です。興味のある方は直接質問を投げて、どんなtraceが残るか確認してみてください。それがこのアーキテクチャを理解する最短ルートです。