Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

CloudflareがOHTTP Gatewayを閉鎖型ベータで公開、Privacy GatewayはOHTTP Relayへ改称

Cloudflareが、OHTTPを使った新しいゲートウェイ機能を閉鎖型ベータとして始めると発表した。あわせて、これまでの「Privacy Gateway」は「Cloudflare OHTTP Relay」に名前を変える。単なる名称変更ではなく、OHTTPの仕組みを前面に出して、RelayとGatewayの役割分担を分かりやすくする狙いがある。プライバシー保護をアプリの外側ではなく、通信の土台に組み込もうとしている点がこの発表の核心だと思う。

Cloudflareが出すOHTTP Gatewayと、名前を変えるPrivacy Gateway

元記事が伝えているのは、Cloudflareが「Cloudflare OHTTP Gateway」を新しく閉鎖型ベータで提供し始める、という案内だ。これはCloudflareのZoneに対する有料の追加機能として使えるようになり、利用者は少ない手順でOHTTPトラフィックを受け取れるようになる。記事では、利用希望者向けに waitlist への登録フォームも案内している。公開範囲をいきなり広げるのではなく、まずは招待制に近い形で顧客を受け入れる流れだ。

背景にあるのは、オンラインプライバシーの負担が利用者側に偏っている、というCloudflareの見方だ。第三者トラッカーを避けるにはVPNを使う、cookieを切る、adblockerを入れる、といった対処をユーザーに求めがちだが、それでもアプリ開発者は、IPアドレスやTLS fingerprintのような情報を通じてユーザーのことを知りすぎる場合がある。Cloudflareは、そうした状況を緩和するために、開発者がアプリの仕組みそのものにプライバシーを埋め込める基盤を作りたいとしている。

そこで出てくるのが OHTTP、正式には Oblivious HTTP だ。これは IETF の標準で、アプリのバックエンドがHTTPリクエストを受け取りつつ、ユーザーのIPアドレスを見なくて済むようにする仕組みと説明されている。OHTTPでは通信が2つの独立した経路を通る。1つは relay で、暗号化されたリクエストを内容を見ずに転送する役目を担う。もう1つは gateway で、暗号化されたリクエストを復号し、レスポンスを再び包み直す。アプリサーバー側は、OHTTPのリクエストをほぼ普通のHTTPのように扱える。重要なのは、この2者が信頼の分離を作っている点で、どちらか一方だけでは利用者の識別情報とリクエスト内容の両方を見られないようになっている。

Cloudflareは2022年に OHTTP relay 製品として Privacy Gateway を出している。記事では、その利用例として Flo Health の Anonymous Mode や、Apple の Private Cloud Compute が挙げられている。どちらも、利用者の身元とリクエストの内容を切り離すためにOHTTPを使っている。今回の発表では、Cloudflareが新たにOHTTP Gatewayを出す一方で、従来の Privacy Gateway は Cloudflare OHTTP Relay に改名する。理由は、2つの製品を区別しやすくするためだとしている。

記事の途中は、Cloudflareの保護下にあるサーバーを使っている顧客が、Cloudflare運用の relay と gateway を同時には使えない、という制約の説明に続いている。つまり今回の Gateway は、その制約を埋めるための追加ピースでもある。CloudflareがPrivacyを個別機能として売る段階から、OHTTPという標準に沿った製品群として整理し直しているのが、今回の発表の実態だと読める。

使いやすさの話に見えて、実はCloudflareの立ち位置を広げる発表だと思う

まず気になったのは、Cloudflareがこの発表を「プライバシー機能の追加」としてではなく、「プライバシーを守るためのインフラの拡張」として描いていることだ。これは表現の問題ではない。OHTTPは、利用者が自分で設定を頑張る道具というより、サービス運営者が組み込む前提の仕組みだからだ。VPNやアドブロックのような“利用者の努力”で守る世界から、通信経路そのものに役割分担を埋め込む世界へ寄せている。Cloudflareはそこに、自社の得意な「裏方のインフラ会社」としての居場所を見ているのだと思う。

一方で、こうした設計は便利さと引き換えに、インフラ事業者への依存も増やす。OHTTPは relay と gateway の分離で信頼を分けるが、現実の運用では、その両方を誰が担うのかが重要になる。Cloudflareはそこに自社製品を差し込み、しかも顧客のZoneに対する有料アドオンとして提供する。これは、プライバシー保護を標準化する動きであると同時に、Cloudflareにとって新しい課金面を増やす動きでもある。悪いとは言わないが、理想論だけで読んではいけない。

「IPを見せない」だけで終わらないのがOHTTPの面白さ

記事が触れているのはIPアドレスだけだが、実際にはもっと広い話に見える。現代のWebやモバイルのトラフィックは、IPだけでなくTLS fingerprintや各種メタデータからもかなりのことが分かってしまう。Cloudflareが「典型的な client-server exchange creates a trail of user data」と書いているのは、その不快さをよく表している。OHTTPは少なくとも、アプリ側がユーザー識別の起点を直接持ちにくくする。その意味で、これは広告ブロッカーの代替ではないが、追跡の起点を減らす土台にはなる。

ただし、ここで誤解してはいけないのは、OHTTPが万能の匿名化ではないことだ。記事の説明でも、relay と gateway の信頼分離が肝だとされている。つまり、ユーザーの匿名性はプロトコルの数学だけで成立するのではなく、運用上「同じ主体が両方を支配しない」ことに強く依存する。Cloudflare自身もその点を前提にしているはずで、だからこそ relay と gateway の名称を分け、役割を明確にしているのだろう。技術の巧妙さより、運用の設計が価値を左右するタイプの製品だと思う。

Flo Health と Apple の例が示すのは、プライバシーがもはや周辺機能ではないこと

Cloudflareが例として挙げた Flo Health と Apple は、かなり意味深だ。Flo Health はヘルスケア系で、利用履歴や関心が非常にセンシティブになりやすい。Apple の Private Cloud Compute は、AI inference のリクエストをユーザー個人から切り離すためにOHTTPを使っている。どちらも、ただ「個人情報を守る」ではなく、サービスの信頼性そのものを支えるためにOHTTPが使われている。

ここに、プライバシーの位置づけの変化があると思う。以前は、プライバシーは法務やコンプライアンスの話として扱われがちだった。今は違う。AI処理、ヘルスケア、メッセージングのような領域では、誰のデータか分からないことが機能要件そのものになる。CloudflareがOHTTP Gatewayを出すのは、その変化に合わせて「この種の通信を標準で支える場所」が必要になったからだろう。単に便利だからではなく、利用の前提条件が変わりつつある。そこを押さえた発表だと受け止めている。

既存のCloudflare顧客にとっては、ようやく選択肢が揃う

記事の最後の方で示唆されている制約は地味だが重要だ。Cloudflareでサーバーを守っている顧客は、Cloudflare運用の relay をそのまま gateway と組み合わせにくかった。つまり、OHTTPを使いたくても、既存のCloudflare利用との整合で止まっていた可能性がある。今回のOHTTP Gatewayは、その穴を埋める役割を持つ。だからこの発表は、新機能の追加というより「既存顧客がやっと同じ会社の中で完結できる」ことの意味が大きい。

ただ、閉鎖型ベータである以上、すぐに広く使える話ではない。実運用に必要な設定の細かさや、既存サービスとの相性はこれから詰められる部分が多いはずだ。とはいえ、CloudflareがOHTTPを単発の実験ではなく、RelayとGatewayの両輪として整理したのは大きい。プライバシーを“追加の工夫”ではなく“配管の一部”にする流れは、今後もっと増えるのではないかと思う。

参考: Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure

同じ著者の記事

英国で起きた「二段階の暗号化」――同じiPhoneなのに、守られ方が違う

英国でAppleのiCloud暗号化をめぐる話が、かなり変な形で落ち着きました。端的に言えば、同じ英国在住のiPhoneユーザーでも、ある人はAppleの最強の保護機能を使い続けられ、別の人はもう使えない、という状態になったのです。しかも差が生まれた理由は、端末や契約の違いではなく、ある時点より前に設定を有効にしていたかどうかでした。暗号化を弱めるよう政府が迫り、Appleがそれを拒み、最終的に「新規利用を止める」という逃げ道のような対応にたどり着いた――この経緯が、いま読むとむしろ英国の監視制度そのものを映しています。 元記事が追っているのは、AppleのiCloud向け最強保護機能「Advanced Data Protection（ADP）」が、英国で事実上ふたりのユーザーを別扱いにしてしまった経緯です。登場するのは、仮に同じiPhoneを持ち、同じiCloudを使い、同じ料金を払っているAliceとBill。Aliceは2024年にADPを有効化していたので、iCloudの多くのデータがエンドツーエンド暗号化で守られています。Billは有効化していなかった、あるいはAppleが新

papoo.work

CloudflareがClefを出した理由は「決定」をAIに任せるためだった

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

papoo.work

Cloudflareが見た「安全なAIモデル」の実力：Mythos Previewは何がすごくて、何がまだ足りないのか

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

papoo.work

EUがまた持ち出した「暗号化への入口」構想、ProtectEUの中身

EUが、エンドツーエンド暗号化にもう一度手を伸ばしてきました。きっかけは、欧州委員会が公表した内部安全保障戦略「ProtectEU」です。表向きは治安やサイバー犯罪対策の計画ですが、記事を読む限り、その中には法執行機関が暗号化されたデータにアクセスするための道筋がかなりはっきり含まれています。通信の安全を守るはずの暗号化に、政府側がどう入り込もうとしているのか。今のうちに見ておく価値があります。 元記事によると、EUは新しい内部安全保障戦略「ProtectEU」を通じて、再び暗号化バックドアの導入を狙っているとされます。今回は露骨な法案提案ではなく、あくまで今後数年にわたる「vision and workplan」として示されました。つまり、すぐに法律で縛るというより、まずは土台を作る段階だということです。 欧州委員会の説明では、背景にあるのは「growing」な脅威です。敵対的な国家、オンラインで活動を強める犯罪組織やテロリスト、さらに増え続けるサイバー犯罪と重要インフラへの攻撃が挙げられています。こうした状況を踏まえ、ProtectEUは6つの重点分野を掲げ、その一つに「more

papoo.work

CloudflareとStripeが、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 の記事によると、

papoo.work

DraftKingsがAIで“負けやすい客”を狙うことの重さ

オンライン賭けを扱うDraftKingsが、AIを使って「負ける可能性が高い客」を見つけ、その人たちに再び賭けを促す広告を送っている――EFFはそう批判しています。単なる広告の効率化ではなく、弱みのある人を見分けて狙い撃ちにする仕組みだからです。しかもこれは、ネット広告の世界で長く続いてきた行動追跡を、AIでさらに強化した例としても読めます。今回の話は、ギャンブル企業の話にとどまらず、私たちの閲覧や購入、利用履歴がどう収益化されるかという、もっと広い問題を突きつけています。 EFFの記事が扱っているのは、オンラインスポーツベッティング企業DraftKingsの広告手法です。ニューヨーク・タイムズの報道として紹介されている内容によれば、DraftKingsは顧客の賭け履歴を使って機械学習モデルを訓練し、負けやすい利用者を見つけているとされます。見つかった相手には、サイトに戻ってきてさらに賭けをするよう促すターゲット広告が送られる。しかもDraftKingsは、その人たちがまた負ける賭けをするだろうと見込んでいる、というのが記事の骨子です。 EFFはこれを、オンライン行動広告の一種だと位置

papoo.work

Ollayaが持ち込む「判断モデルを手元で走らせる」世界

ChatGPTのように文章を長く生成するのではなく、入力に対して「invoice か refund か」「危険か安全か」といった判断を素早く返すモデルがある。Ollayaは、その種の decision model を自分のPCやサーバー上で動かすための仕組みを前面に出してきた。クラウドAPIに投げるのではなく、ローカルで、しかも数ミリ秒単位の応答を狙うのが売りだ。特に、個人情報や社内データを外に出しづらい用途では、かなり現実的な選択肢に見える。 Ollayaは、open decision models を自分のマシンでダウンロードして提供するサイト兼ツールだ。トップページでは「typed questions about any text or JSON」に答え、しかも calibrated answers を milliseconds で返すと説明している。ここでいう decision model は、長文を生成するLLMとは少し違う。選択肢の中から答えを一つ返したり、yes/no を出したり、スコアを付けたりする用途に向いたモデルで、文章を1トークンずつ出すのではなく、1回の for

papoo.work

1つのファイルで動くアプリ、Capsuleが目指すもの

アプリを「インストールして使うもの」から、「ファイルとして渡して、そのまま開くもの」に変えようとしているサービスがあります。Capsuleは、その考え方をかなり正面から押し出したツールです。元記事では、アプリの見た目やデータ、実行に必要な要素を1つの `.capsule` ファイルにまとめ、メールやWhatsApp、AirDropで送れると説明しています。単なるデモではなく、AIでアプリを作り、あとから中身を直接更新できる点まで含めて、かなり野心的です。 いまこの記事を取り上げるのは、ローカル実行やプライバシー重視の流れに、AIによるアプリ生成が重なってきたからです。クラウドに預ける前提のSaaSとは違う、新しい「配布」の形を模索しているとも読めます。 Capsuleのサイトは、冒頭からかなり挑発的です。見出しは「Documents that run like apps」。説明文には「One file, entire app. Share like a document, open like an app.」とあり、1つのファイルでアプリ全体を持ち運べることを前面に出しています。`.c

papoo.work

Mistralが入力データの学習利用をやめられるようにした理由

AIチャットやAPIを使うとき、送った文章や添付した文書が学習に回るのかどうかは、かなり気になるところです。Mistralのヘルプページは、その不安に対して「使い方ごとにオプトアウトの方法がある」と整理して説明しています。しかも、Vibe、モバイルアプリ、Mistral StudioとAPIでは設定場所が分かれていて、ひとつ止めたからといって全部止まるわけではありません。企業利用を含め、データの扱いを細かく確認したい人には重要な案内です。 Mistralのヘルプセンターでは、入力データや出力データが、場合によっては同社のモデル学習プログラムに含まれることがあると説明しています。入力や出力には、会話だけでなく、文書やユーザーが提供したその他のコンテンツも含まれます。ここでいう「学習」は、AIモデルを改善するための利用を指しており、利用者はその処理を自分で管理でき、いつでもオプトアウトできるとしています。 案内はサービスごとに分かれています。まずVibeでは、ユーザーはデフォルトでオプトアウトされておらず、設定からいつでも外せます。Vibe Enterpriseでは少し逆で、顧客はデフォル

papoo.work

Claudeをやめても困らない？ オープンモデルへ移るコストは思ったより小さい、という話

以前のLinuxみたいに、「オープンなものを使う＝仕事で大きく損する」という時代はかなり薄れてきた LLMの世界では、今もClaudeやGPTのような proprietary model（企業が提供する閉じたモデル）が性能面で先行している ただし open models もかなり追いついてきていて、差は「数か月遅れ」くらいだと著者は見る いちばん大きい問題は性能差より、プライバシーと運用の面倒さ ClaudeのID verification（本人確認）導入をきっかけに、「もうオープンモデルへ寄せてもいいのでは」という空気が強まっている 著者は、仕事で使うとしても生産性の落ち込みは短期的で、致命傷ではないと考えている この記事は、タイトルだけ見ると少し過激です。`cancel_claude` という名前だと、Claudeを全面否定する話に見えますが、実際はもっと現実的で、かなり実務寄りの話でした。要するに、「トップの閉じたAIモデルを使わなくても、今なら仕事は回るのでは？」という問題提起です。しかもその根拠が、意外と地に足がついている。ここが面白いところです。 著者はまず、昔のLinux

papoo.work