#cloudflare

Cloudflareが、OHTTPを使った新しいゲートウェイ機能を閉鎖型ベータとして始めると発表した。あわせて、これまでの「Privacy Gateway」は「Cloudflare OHTTP Relay」に名前を変える。単なる名称変更ではなく、OHTTPの仕組みを前面に出して、RelayとGatewayの役割分担を分かりやすくする狙いがある。プライバシー保護をアプリの外側ではなく、通信の土台に組み込もうとしている点がこの発表の核心だと思う。 元記事が伝えているのは、Cloudflareが「Cloudflare OHTTP Gateway」を新しく閉鎖型ベータで提供し始める、という案内だ。これはCloudflareのZoneに対する有料の追加機能として使えるようになり、利用者は少ない手順でOHTTPトラフィックを受け取れるようになる。記事では、利用希望者向けに waitlist への登録フォームも案内している。公開範囲をいきなり広げるのではなく、まずは招待制に近い形で顧客を受け入れる流れだ。 背景にあるのは、オンラインプライバシーの負担が利用者側に偏っている、というCloudflare

最初に引っかかったのは、「便利になった」で済ませるには少し重い話だな、という点だった。MCP tools や API を AI agent が使うとき、アクセス権だけでなく「お金をどう使うか」まで設計対象に入ってきた。これ、技術的には自然な流れなのに、運用の感覚としてはかなり新しい。 特に気になったのは、誰がその支出を握るのかという問題だ。人間が都度承認するのか、予算上限だけ決めて agent に委ねるのか、あるいは用途ごとに細かいルールを置くのか。ここを曖昧にしたまま agent に決済能力を持たせると、便利さより先に「勝手に使われる不安」が来ると思う。API キーを守る話はもう慣れたけれど、今度は“財布”そのものをどう守るかになるわけで、これはかなり質の違う話だ。 一方で、こういう仕組みがないと agent は本当に使える道具になりにくいのも分かる。無料で触れる範囲だけでは、実務で必要な tool や data source に届かないことが多い。だから課金を通す gateway を作る発想自体はかなり筋がいいと思う。ただ、その筋の良さと引き換えに、監査ログ、上限設定、用途制限、責

Cloudflareが、サーバーレスの event streaming サービス「K2」を public beta として公開した。Kafka のような仕組みを連想すると分かりやすいが、K2 はクラスタ運用を前提にした製品ではなく、Cloudflare の Developer Platform 上で動く“耐久性のあるログ”として設計されている。記事の中心にあるのは、送信側と受信側の速度や稼働状況をそろえなくても、イベントを失わずに受け渡しできるようにする、という発想だ。Cloudflare はこれを自社の Pipelines 向けに必要になった機能として説明していて、単なる新製品紹介というより、同社のストレージや処理基盤の組み合わせ方を示す話でもある。 元記事がまず問題にしているのは、従来の RPC 型の構成では、送信側と受信側が同じ速度で動いていないとイベントを失いやすい、という点だ。たとえば送信元が大量のデータを吐き出したのに、受け手や下流サービスが追いつかなければ、処理しきれない分が落ちる。しかも受信側が複数あると、analytics 系と fraud detection 系のよ

Cloudflareが、少し変わった位置づけのAIモデルを公開した。名前はClefとClef-flash。大規模言語モデルのように文章を長々と生成するのではなく、入力を見て「この案件は急ぎか」「どのチームに回すべきか」といった判断を、速く安定して返すための decision model だ。しかも今回は、単にモデルを出しただけではない。自社で学習したモデルを Workers AI で提供しつつ、開発者が自分のデータでその判断モデルを強化できる新しい reinforcement learning（RL）基盤まで同時に打ち出している。AIが「言葉を作る」段階から「業務の分岐を決める」段階へ少し進んだ、という話として読むと分かりやすい。 元記事は、まず最近注目が集まっている decision model という考え方を説明している。Cloudflareが例に挙げているのは Typesafe AI の Jev System One で、これは従来の classifier model を少し発展させたものだという。こうしたモデルは、曖昧な会話を続けるためではなく、決められた形式の出力を、安く、速

What jumps out to me is the timing. Anthropic buys Stainless and shuts down its SDK generator; Cloudflare then turns around and open-sources Forge. That is not a coincidence you can shrug off. It reads like a public vote of no confidence in the idea that SDK generation should be locked up inside a company, especially after customers have already built around it. I’m a little skeptical of the clean story people will want to tell here, though: “open source good, acquisition bad.” It’s not that sim

まず、CloudflareがForgeをオープンソースで出した、という部分に少しほっとした。AnthropicがStainlessを買って自前のSDK generatorをしまった、という流れの直後だからなおさらだ。こういう基盤ツールは、便利なだけに“ある日突然使えなくなる”不安がつきまとう。だから、少なくともCloudflareは外に出したままにしたのか、というのが最初に引っかかった点だった。 ただ、記事を読んでいて面白かったのは、これは単なる「オープンソースの勝ち」みたいな話ではないことだと思う。SDK generatorって、APIを使う側から見ると地味だけど、実際には開発体験をかなり左右する。各言語向けのSDKを毎回きれいに揃えるのは面倒だし、そこを自動化できるとエコシステム全体が楽になる。逆に言うと、そこを自社の都合で閉じると、使う側は急に依存先の機嫌をうかがう形になる。Anthropicの買収と停止、Cloudflareの公開は、その対比がかなり露骨だった。 もう一つ思ったのは、こういうツールの価値って「生成できること」そのものより、「誰が維持し、どれだけ信頼できる形で続く

Cloudflare が、Workers 上で Python を本格運用できる「Python Workers」を一般提供に切り替えました。これまでも試せはしたものの、今回は「実験」から「正式な選択肢」へ格上げされた形です。TypeScript だけでなく Python でも、Cloudflare のエッジ実行基盤にそのまま乗せられるようになったのが大きい。しかも D1、R2、Workers AI など周辺サービスとも JavaScript の接着コードなしでつなげる、と Cloudflare は強く打ち出しています。 元記事が伝えているのは、Cloudflare が Python Workers を generally available、つまり一般提供にしたという発表だ。Python Workers は、Cloudflare Workers の実行環境の中で Python アプリを動かす仕組みで、Cloudflare によれば、これで Python は Developer Platform の「first-class」、つまり最初からきちんと支える言語になった。単に Python が

Cloudflareがまた、大規模インフラでは「小さな無駄」がどれほど高くつくかを示す話を出してきた。今回はPingoraを使う社内の負荷分散サービスで、あるアルゴリズムのメモリ使用量を見直し、全世界で100TBを超えるRAMを取り戻したという。派手な新機能の話ではないが、こういう改善こそクラウド事業者の現場では効く。しかも今回は、Rustと少しの数学が主役だ。 元記事が扱っているのは、Cloudflareの内部負荷分散サービス「Pingora Backend Router」、略してPBRだ。PBRは、キャッシュ可能なリクエストをどのサーバーに送るかを決める役割を持っていて、その判断には consistent hashing を使っている。consistent hashing は、サーバーの増減があっても割り当てが大きく崩れにくい方法で、分散システムではよく使われる。Cloudflareではこの仕組みを open-source の `pingora-ketama` ライブラリで実装していた。 話の発端は、Cloudflare内部のIvanが出したチケットだった。内容は「Pingora

ローカルで動かしている Web サービスを、すぐ外部に見せたい場面は意外と多い。社内レビューでも、Webhook の受け口を試すときでも、AI エージェントに実際の URL を渡したいときでも、いちいち本番環境を用意するのは重い。Cloudflare が公開した Quick Tunnels は、その面倒をかなり雑に、しかも短時間で片づけるための仕組みだ。この記事では、ローカルの localhost をどうやって公開 URL に変えるのかを整理したうえで、これが開発の現場に何を持ち込むのかを見ていきたい。 Cloudflare の Quick Tunnels は、ローカルで動くサーバーを、Cloudflare の edge 上にある公開 URL に変換するサービスだ。ページの説明では「Localhost, meet the Internet.」という言い方で、手元のサーバーをそのままインターネットに接続する道具だと位置づけている。使い方はかなり単純で、`cloudflared tunnel --url http://localhost:8000` を実行するだけで、手元の Web サーバ

この症状は、少なくとも GitHub issue では 2 件とも同じ形で報告されています。どちらも Claude Code の実行中に `Error: 502` と Cloudflare の `502 Bad Gateway` HTML が返っており、スタックトレースには `generate` と `makeRequest` が出ています。該当 issue は [#67734](https://github.com/anthropics/claude-code/issues/67734) と [#66186](https://github.com/anthropics/claude-code/issues/66186) です。 まず切り分けたいのは、手元の失敗が「Claude Code からのリクエストが途中で 502 に落ちている」ケースかどうかです。提示された 2 件はいずれも、アプリ固有のメッセージではなく Cloudflare の HTML がそのまま返っています。報告内容からは、少なくとも Claude Code 側の処理が HTTP 502 を受け取って失敗していることは

最初に思ったのは、これは地味だけどかなり筋がいい変更だな、ということだった。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 の記事によると、