#cloudflare

最初に思ったのは、これは地味だけどかなり筋がいい変更だな、ということだった。OAuthの同意画面って、結局のところ「全部許すか、全部やめるか」になりがちで、特にagentやMCP serverみたいにやたら広い権限をまとめて欲しがる相手には、ユーザー側が白か黒かで判断するしかなかった。そこに「この権限は外してよい」と開発者が印を付けられるのは、かなり現実的だと思う。 面白いのは、これがユーザーの自由を広げる話に見えて、実際には開発者の責任を少し増やすところだ。ユーザーが optional scope を外したら、アプリは「まあ動くはず」では済まない。返ってきた token の scope を見て、足りない機能はちゃんと落とす必要がある。つまり、同意画面で頑張るだけではなく、その後の振る舞いまで設計に入れないといけない。ここは、表向きの UX 改善よりもずっと実装の癖が出る部分だと思う。 それにしても、agent のための権限設計ってやっぱり難しい。人間なら「このアプリは在庫を見るだけ」と説明されれば想像できる。でも agent は、将来その権限をどう使うかを全部まとめて請求してくる。読

What caught my attention here is not the feature itself, but the fact that Cloudflare is finally admitting something the OAuth UX has always kind of pretended away: consent is usually too blunt for agentic software. If an MCP server asks for a bundle of scopes, a human is asked to bless the whole bundle, even when only one or two parts are actually relevant to the task. That’s a bad fit for agents, and honestly it’s been a bad fit for a while. I think the interesting move is that Cloudflare isn’

OpenAI、Claude、Grokの3つがほぼ同時に不調になり、Hacker Newsでは「いったい何が起きたのか」が盛んに議論された。単なる各社の個別障害なのか、それとももっと下の層で共通のトラブルが起きたのか。ユーザーから見れば、いつものLLMが一斉に使えなくなるのはかなり不穏だし、インフラの依存関係がどこまで深くなっているかを考えさせる出来事でもある。しかも議論の途中から、技術的な推理だけでなく、LLM界隈らしい冗談もどんどん混ざっていった。 元記事は、Hacker News の「Ask HN」として投稿されたスレッドで、タイトルは「Why were OpenAI, Claude, and Grok simultaneously down?」。投稿者は、OpenAI、Claude、Grok のステータスページを並べて示しながら、なぜ3つが同時に落ちたのかを尋ねている。スレッド上ではまず、Cloudflare、Azure、AWS、Google Cloud にも同じ時間帯にエラー報告の増加が見える、という指摘が出た。投稿時刻の目安としては 7:30 ごろに急増が見られたとされ、そこ

Cloudflare が、自社の DNS サービス群を支える内部基盤「Big Pineapple」で、キャッシュの持ち方を見直し、大きなメモリ削減を実現したと明かした。対象は 1.1.1.1 をはじめ、Gateway DNS、DNS Firewall、AS112 など、同社のDNS関連サービスを裏で支える仕組みだ。単なる省メモリの話ではなく、同時に処理速度も上がった点が面白い。サーバーを増やす話ではなく、既存の設計を細かく磨くだけでここまで変わる、というところにこの話の価値がある。 Cloudflare によると、Big Pineapple は任意の時点で 2500億件を超える DNS キャッシュエントリを保持している。DNS キャッシュは、過去に調べた名前解決の結果を覚えておき、次回以降の応答を速くする仕組みだ。Big Pineapple では、キャッシュが空の状態から始まり、DNS クエリが来るたびに項目が増えていく。上限に達したら、古いものや人気のないものから追い出していく。 ここで重要なのは、1件あたりの無駄が全体では巨大なコストになることだ。Cloudflare は「1エント

What jumped out at me is not the “AI agents can now write things” part. That ship has already sailed. It’s that Cloudflare is trying to put a shared control plane around the messy part: not just whether an agent can act, but which actions count as harmless, which ones are mildly annoying, and which ones are “stop and think very hard.” That seems like the right instinct. MCP has made it easy to connect models to tools, but “easy to connect” is not the same thing as “safe to let loose.” Read-only

これを読んでまず思ったのは、AIエージェントの「読める」より「触れる」を先に整えるのは、かなり筋がいいな、ということだった。 MCPは外部サービスにつなぐための共通口として便利だけれど、便利さが増えるほど、誤操作の怖さも一気に増す。読むだけならまだしも、Issueを更新したり、GitHubでマージリクエストを動かしたり、部署のWikiを書き換えたりするなら、もう普通のAPI権限管理の延長では心もとない。そこに対して、MCPサーバーごとに実装をばらばらに増やすのではなく、前段でまとめて制御する発想はわりと自然だと思う。 特に引っかかったのは、Cloudflareが「agent用の別アカウントを作らない」としている点だった。 一見すると丁寧に見えるけれど、実際には権限の管理対象が増えるだけで、誰が何をしたのかも追いにくくなる。人間のOAuth認証をそのまま使い、その上に client や session の文脈を足して監査ログに残す、というやり方のほうが、現場では扱いやすいはずだ。AI専用の何かを増やすたびに、運用も監査も別物になるので、そこを避けたのは現実的だと感じた。 ただ、こういう仕

2026年8月20日の朝、ChatGPT にログインしようとすると素っ気ない JSON が返ってくる、という報告が上がりました。東京 AI 研究所さんの note 記事がその現場をそのまま記録しています。画面に出たのはこれだけです。 ```json {"error":{"code":502,"message":"Bad gateway.","param":null,"type":"cf_bad_gateway"}} ``` 朝一番に AI アシスタントを開く習慣がある身としては、これはかなり嫌なやつです。何も説明してくれないエラーに見えますが、実はこの1行、読み方さえ知っていれば「どこが壊れているか」「自分に打てる手はあるか」までほぼ特定できます。今日はこのエラーを掘り下げてみます。 鍵は `type` フィールドの `cf_bad_gateway` です。`cf` は Cloudflare のこと。ChatGPT への通信は ブラウザ → Cloudflare（エッジ） → OpenAI のオリジンサーバ という経路をたどっていて、502 Bad Gateway は「

この記事を読んでまず思ったのは、やっと本丸に手が入ってきた、という感覚だった。AI を業務に入れる話はずっと「読むだけ」なら比較的安心で、問題はいつもその先だったからだ。チケットを更新する、GitHub に手を入れる、SaaS に書き込む。そこに来ると、ただ便利という話では済まなくなる。 面白いのは、Cloudflare がここで MCP server 自体をいじるのではなく、手前に WriteGuard という共通の層を置こうとしている点だと思う。個別のサーバーに安全機能を埋め込むと、どうしても実装がばらつくし、後から増える Jira だの wiki だの Google Workspace だので同じことを繰り返す羽目になる。中央でポリシーを見て、危険度ごとに通すか止めるかを決めるほうが、現実の運用には合っている。セキュリティって、理想論より「各チームに同じことを二度書かせない」ほうが効くことが多い。 もう一つ引っかかったのは、agent 専用アカウントを増やさず、既存の OAuth 資格情報に MCP client や session の文脈を足して追跡する、という設計だ。管理の重

読んでまず思ったのは、Cloudflareらしいな、でも本丸はそこじゃないな、ということだった。 こういう「ワンタップで使えるようにしました」という話は派手に見えるけれど、実際には面倒な下ごしらえを一段減らしただけで、何を公開するか、どう安全に運ぶか、どう使われたかを見届けるかは別問題のまま残る。この記事はその線引きをかなりはっきり書いていて、そこが好感だった。 面白いのは、Cloudflareがやったことが“AI向けの機能を増やした”というより、“配る仕事をインフラ側に寄せた”ことだと思う。HTMLに bridge を差し込んで、browser 側で WebMCP をつなぐ。要するに、各サイト運営者が毎回同じ接着剤を貼らなくてよくなる。これは地味だけれど、レガシーなサイトが多い世界ではかなり効くはずだ。こういう「面倒だけど避けられない部分」を押し下げるのは、インフラ企業の強みがそのまま出るところだと思う。 ただ、記事がちゃんと釘を刺しているように、これでサイトが“agent-ready”になるわけではない。ここを読み飛ばすと危ない。 商品検索や予約、購入みたいな「実際に何かをする」動

Cloudflareが、AIエージェント向けに Temporary Cloudflare Accounts を提供し始めました。ざっくり言うと、AIが「コードを書いたあと、すぐにデプロイまで進みたい」ときに、人間向けの面倒な登録作業を飛ばせる仕組みです。 これ、地味に見えてかなり大きいです。AIはコードを書くのは得意でも、そのあとに出てくる「ブラウザでログインして」「OAuthを通して」「API tokenをコピペして」「2段階認証を入れて」みたいな壁で止まりがちでした。Cloudflareはその壁を、かなり正面から壊しにきた、という印象です。 AIエージェントが、Cloudflareにすぐデプロイできるようになった `wrangler deploy --temporary` で、60分だけ使える仮アカウントを作れる その場でデプロイして、結果を確認し、何度でも修正できる 気に入ったら、あとからその仮アカウントを自分の正式なアカウントとして引き取れる 何もしなければ60分で自動削除される CloudflareはStripeやWorkOSとも組んで、エージェントの「登録の面倒」を

Cloudflareが、self-managed OAuth をすべての開発者に開放しました。 これ、地味に見えてかなり大きなニュースです。というのも、OAuthは「外部アプリに、どこまで何を許可するか」を安全に扱うための仕組みで、SaaS連携や社内ツール、いま流行りのagentic toolまで、あちこちで土台になっているからです。 Cloudflareは自社のAPIを使って自動化やCI/CD、各種連携を作れる強いプラットフォームですが、これまでは第三者向けのOAuthは一部の手動オンボーディング済み統合に限られていました。 つまり、誰でも自由に「Cloudflare用のOAuthアプリ」を作れる状態ではなかったわけです。 その制限が外れた。ここが本題です。 CloudflareのOAuthが、限られた提携先だけでなくすべての開発者に開放された API token中心の運用よりも、権限を細かく分けやすく、取り消しもしやすい その裏側では、OAuthエンジンの大規模アップグレードをかなり慎重にやっていた データベース移行は派手。1億件超の更新・挿入が走っ

CloudflareのTurnstileが、一部のブラウザで無限ループして先に進めなくなった 原因は、WebGLの情報を使った fingerprinting（端末の識別）を要求していること 筆者はこれを、「人間かどうかの確認」ではなく、実質的な追跡のためだと批判している WebKit系ブラウザではこの種の fingerprinting が長くブロックされており、その結果 WebKitGTK 系ブラウザが締め出される形になっている Firefoxでも、fingerprinting 防止の設定まわりに微妙なズレがあると指摘されている この記事が扱っているのは、Cloudflareの Turnstile という仕組みです。 これはサイト側が「あなたは人間ですか？」を確認するための device verification、つまりボット対策の一種です。 ただ、筆者の環境ではこの Turnstile がずっと回り続けて終わらない状態になってしまい、結果としていくつものWebサイトにアクセスできなくなったそうです。 これ、地味にかなり痛

Cloudflareは、セキュリティ用途のLLMを自社インフラ上の実コードに当てて検証している Anthropicの Mythos Preview は、単にバグを見つけるだけでなく、複数の弱点をつないで実際に悪用できる形にするのが強い PoC（proof of concept） まで作るので、「怪しい」ではなく「本当に再現できる」段階まで持っていける ただし、モデルの拒否（refusal） は一貫しておらず、同じ内容でも言い方次第で結果が変わる いちばん大きな課題は、AIそのものよりも運用の形。単発チャットではなく、複数の役割を持つharness（実行基盤） が必要 人間が読む前の自動判定では、ノイズをどう減らすか が超重要になる Cloudflareが公開したこの記事は、AIを使った脆弱性調査の「現場感」がかなり濃いです。 しかも単なる未来予想ではなく、実際に自社の50以上のリポジトリに Mythos Preview を当ててみた結果がベースになっています。 率直に言うと、この記事の面白さは「AIがバグを見つけました」で

CloudflareとStripeが、AIエージェント向けの新しい protocol を公開した エージェントが Cloud account の作成、domain の取得、subscription の開始、production への deployment まで行える 支払いと本人確認は Stripe が担当し、デフォルトの月額上限は $100 人間が関与するのは主に「法的・金銭的に重い場面」 便利さは大きいが、間違ったdomain購入や予算超過などのリスクも現実的 Cloudflare と Stripe が、AI agent による “自動 provisioning” を可能にする protocol を公開しました。 ここでいう provisioning は、ざっくり言うと「サービスを使い始めるための初期設定一式を用意すること」です。普通なら人間が dashboard を開いて、アカウントを作り、支払い方法を入れ、API token を発行して、必要なら domain を買って、最後に deploy する。あれを AI agent がまとめてやるわけです。 InfoQ の記事によると、