Cloudflare Ask AI：Agent Leeは本当にどれほど優秀なのか？

Cloudflare Ask AIは、ダッシュボード右上にあるボタンです。その背後にはAgent Leeがあり、アカウントを読み取り、平易な言葉で質問に答え、2026年4月以降は、変更を承認すると設定も変更します。

これは単なる別のdocs chatbotではありません。インターネットの大部分を前面で支えるcontrol plane内で認証情報を保持するagentです。ローンチ記事以上に詳しく検討する価値があります。

以下の内容はすべて、Cloudflare自身のdocumentationとblog、および実際に問題に遭遇した人々による公開されたincident reportsに基づいています。私はproduction accountを対象に試しておらず、それらの報告を読んだ後は、急いで試すつもりもありません。その判断自体が、この記事の主題です。

Cloudflare Ask AIボタンの背後にあるもの

Agent LeeはCloudflare独自のstack上に構築されています。Agents SDK、推論用のWorkers AI、ユーザーごとの会話保存とwrite-approval gateのためのDurable Objects、そしてAPI tool definitions用のCloudflareのMCP serverです。

興味深いのは、toolの呼び出し方です。modelはtool callを一度に1つずつ出力するのではなく、生成されたAPIに対するTypeScriptを書き、そのcodeを、認証情報を持つproxyとして機能するDurable Object経由でsandbox実行します。CloudflareはこれをCodemodeと呼んでいます。API keysが生成されたcodeに現れることはなく、server sideで注入されます。Read operationsは直接実行されます。Write operationsは、Cloudflareがelicitation gateと呼ぶ仕組みで停止します。Cloudflareのlaunch postでは、confirmation promptは単なるUX上の配慮ではなく、それ自体がgateであると明確に説明されています。

Cloudflareによると、Agent LeeはDNS、Workers、SSL/TLS、R2、Registrar、Cache、Tunnel、API Shield全体で、1日あたりおよそ250,000件のtool callsを処理しています。

アーキテクチャとして、これは本格的な設計であり、私が見てきたほとんどのvendor copilotよりも慎重です。問題はアーキテクチャにあるのではありません。

Cloudflare Ask AIが正しくできていること

狭い範囲では、この売り文句は成立しています。設定の場所を尋ねれば、8つのtabをクリックして探すより速く見つかります。DNS lookupやcertificate checkを実行させれば、ページを離れずに回答を得られます。traffic chartを求めれば、generative UIを通じてanalyticsからグラフを描画します。

本当の進歩は、docs searchを超えたaccount awarenessです。documentationにある仮想的なzoneではなく、あなたのzoneについて回答します。Cloudflare dashboardを年に2回しか触らず、ruleがRules、Caching、Configurationのどこにあるか思い出せない人にとって、それだけでも便利です。

Cloudflare Ask AIがうまくいかないところ

公開されている失敗は3つあり、それぞれ種類が異なります。

誰も求めていなかったtoken

2026年2月下旬、Cloudflare usersは、自分で作成した覚えのない「Agent Lee (auto-generated)」という名前のAPI tokenがアカウント内にあることに気づき始めました。削除しても解決しませんでした。refreshすると再び現れました。community threadで原因が判明しました。Ask AI panel内の小さなcontrolの奥に隠された「Let AI view your account」というsettingが、enabledの状態で提供されていたのです。これをoffにすると、tokenは完全に削除されました。

そのthreadのあるuserは、自分でenabledにしたことはなく、通知も受け取っていないと述べています。同じthreadで返信した元Cloudflare stafferも、通知なしでfeatureが公開されたことを認め、さらに重要な点を指摘しました。agent自身が自分のtokenを認識していなかったのです。その後、teamはbeta documentationとtokenの修正を公開しました。

そして5月、あるdeveloperがcredentialsを監査したところ、同様のtokenがアカウントに存在していることを発見しました。tokenは4月28日に作成され、3週間後に見つかりました。その記事、Cloudflare's Ask AI created an API token with read access to my entire accountでは、すべてのaccounts、すべてのzones、すべてのusersに及ぶread access、160を超えるpermissions、そしてexpiry dateがないことが説明されています。主張はもっともです。「質問に答えるassistantには、その質問に限定したread accessが必要です。」

現在のCloudflareのdocumentationでは、API tokensはAgent Leeがaccessできないものとして記載されています。agent用にprovisionされたcredentialが、agentの想定用途より広い権限を持っているなら、この2つは同時に成立します。永続的で、scopeが広く、期限のないtokenの問題は、まさにそこにあります。

確認してみてください：dash.cloudflare.com/profile/api-tokens

何も返さない沈黙

5月、あるuserがCloudflare community forumで、複数のtraffic analysisの質問に対してAsk AIが「thinking about it」のままになり、その後何も返さなかったと報告しました。errorも、部分的な回答も、何かが失敗したことを示すsignalもありませんでした。Cloudflare側のresponderが再現し、non-answersを止めるための変更をteamが進めていると述べました。

これはbeta bugであり、修正されるでしょう。ここで触れるのは、interfaceについて明らかになることがあるからです。system feedbackのないchat panelでは、難しい質問なのか、pipelineが壊れているのかを判断する方法がありません。

承認されたwriteによって壊れたcache rule

7月の報告は、あなたが注意すべきものです。あるuserがcaching issueをAsk AIと一緒に調査し、正常にsaveされたことを確認しました。しかし翌朝、問題が再発していました。詳しく調べると、agentがRulesets APIを通じてoverride_originとともにbrowser_ttlを0に設定していたことが判明しました。APIはその値を受け入れました。後でdashboardをedit modeで開くと、invalidとして表示されました。ruleはすでに壊れた状態でdeployされており、cache bypassは黙って機能していませんでした。

この流れをもう一度読んでください。guardrailは設計どおりに機能していたのに、結果としてproduction ruleは壊れました。

approval gateがカバーしないギャップ

elicitation gateが答えるのは、1つの質問だけです。このwriteを承認しますか？しかし、実際にそのuserを困らせた問いには答えられません。その値は正しいのでしょうか？

「このcache ruleのbrowser TTLを設定する」ことを承認するのは、override_originと組み合わせた0が、APIには受け入れられる一方でdashboardには拒否されるruleを生成することを理解するのとは別です。approval promptの段階でそれを検出するには、すでにそのconstraintを知っていなければなりません。そしてconstraintを知っているなら、agentに尋ねる必要はありません。

これはinfrastructureにおけるconfirm-before-writeの構造的な限界です。Authorizationはvalidationではありません。評価できない変更を人間が承認するのは、手順が増えたrubber stampにすぎません。そして、失敗モードは拒否よりも悪いものです。なぜなら、静かなmisconfigurationは、trafficが別の結果を示すまで成功に見えるからです。

agent systemsを構築するなら、これが応用可能な教訓です。私もagent-driven publishingやCMS workflowsを構築する中で、同じ壁にぶつかりました。approval stepがあなたを守るのは、gateにいる人間がpayloadを実際に判断できる場合だけです。そうでなければ、UI上のconsentではなく、tool内のvalidationが必要です。

Free planのパラドックス

Agent Leeはまだbetaであり、2026年9月時点でもFree plan accountsに限定されています。

このtest groupが誰になるか考えてみてください。複雑な構成、複数のzones、Enterprise WAF rules、そしてcache behaviourに収益がかかっているaccountsは利用できません。利用できるのは、browser_ttlが0であることが問題だと、損失が発生する前に気づく可能性が最も低いaccountsです。

blast radiusの論理は理解できます。しかしそれは、feedback loopがまさに不適切なpopulationで動いていることも意味します。7月のcache incidentは、その実例です。

現在、Cloudflare Ask AIをどう使うか

Read-only reconnaissanceなら、使います。設定の場所、zoneの現在の構成、certificateが有効かどうか、またはtrafficの簡単なchartを尋ねる用途です。riskは低く、時間は実際に節約できます。

Writesは使いません。自分が気にかけているtrafficを処理するものには、なおさらです。何を変更するつもりなのかをagentに説明させ、その後、dashboardが入力をvalidationする場所で自分で変更します。

使うかどうかにかかわらず、今週やっておく価値のあることが3つあります。

これはCloudflareに反対する話ではありません。私はWorkersやproduction waitlists向けのD1を含め、彼らのstack上で構築しています。重要なのは、control plane内のagentには、editor内のagentとは異なるレベルの精査が必要だということです。

結論

Agent Leeは、私が内部構造を読んだvendor copilotの中で、最もアーキテクチャ面で本格的なものです。Codemode、credentialed proxy、実際のapproval gate、それらすべてが独自のprimitives上に構築されています。Cloudflareは難しい部分を正しく実装しました。

2026年9月時点での評価は次のとおりです。

アーキテクチャとrolloutのギャップこそが、この話の本質です。Cloudflareはcredential pathを慎重に設計しましたが、誰にも知らせずdefaultでenabledにしたことで、その慎重さの多くを一度の変更で台無しにしました。

質問には便利です。変更については、まだ信頼できません。

Sources

2026年9月18日に確認。