直近24時間では、AIエージェントに最新のWeb情報を渡す仕組み、障害調査をログからトレースまで一続きで追う仕組み、脆弱性対応の会話をAPIから扱う仕組みが前に進みました。
特に押さえたいのは、Cloudflare AI GatewayからWeb検索を呼べるようになったこと、CloudflareのObservabilityがログ・トレース・SQL・アラートをまとめる方向へ進んだこと、GitHubのRepository Security Advisoryで機密コメントとコメントAPIが使えるようになったことです。
今日何が重要か
- Cloudflare AI GatewayにWeb Search APIが追加され、AIエージェントへ最新のWeb情報を渡しやすくなりました。
- Cloudflare Observabilityは、ログ、トレース、SQL API、アラート、ダッシュボード、データ出力を1つの基盤へ寄せています。
- GitHubのRepository Security Advisoryでは、保守担当だけに見える機密コメントと、コメントを扱うREST APIが追加されました。
3件とも、「人が画面を見て判断するだけ」だった作業を、エージェントや自動化から安全に扱いやすくする更新です。
1. Cloudflare AI GatewayからWeb検索を呼べるようになった
AIエージェントが最新情報を調べるとき、URLを推測して直接アクセスするだけでは、存在しないページや古い情報に当たりやすくなります。検索を1つのツールとして明示的に持たせる方が、現在の情報へ安定して辿り着けます。
CloudflareはWeb Search API via AI Gatewayを公開しました。開始時点ではCeramic.ai、Exa、Linkupと連携し、AI Gateway経由でWeb検索結果を取得できます。
ユーザーの質問 ↓AIエージェント ↓ 検索が必要と判断AI Gateway ↓Web Search API ↓Ceramic.ai / Exa / Linkup ↓最新の検索結果をモデルへ渡す検索リクエストもAI GatewayのObservabilityログに記録され、利用分はAI Gatewayのクレジット残高から消費されます。既存契約の検索プロバイダーを使うBYOK(Bring Your Own Key)にも対応しています。
バックエンドからはREST API、Cloudflare Workersからはbindingで呼べます。Workersでは、たとえば次のように検索できます。
const response = await env.AI.websearch({ gatewayId: "default", query: "latest Node.js release", provider: "exa", limit: 5,})ここで変わるのはモデルの知識そのものではありません。必要なときに検索し、その結果を新しいコンテキストとしてモデルへ渡せるようになります。
社内向けAIや技術調査エージェントを作っているなら、「モデルに全部知っていてもらう」のではなく、「必要なときだけ検索して一次情報へ寄せる」構成を取りやすくなります。
2. Cloudflare Observabilityがログ・トレース・SQLを1つの流れで扱えるようになった
障害調査では、Workerのログ、HTTPリクエスト、セキュリティイベント、オリジンの遅延などを別々の画面で追うと、原因へ辿り着くまでに時間がかかります。
CloudflareはObservabilityの8つの大型アップデートを発表しました。ログの横断表示、エンドツーエンドのトレース、統一SQL API、カスタムアラート、ダッシュボード、データ出力などを1つのObservability基盤へ寄せています。
特に分かりやすいのが、open betaで公開されたCloudflare Tracesです。
ブラウザ ↓Cloudflare Security Rules ↓Transform / Cache / Routing ↓Workers ↓Origin ↓自社サービスのOpenTelemetry Trace1つのリクエストがCloudflare内部でどの処理を通ったかを、リクエスト単位のタイムラインとして確認できます。W3C Trace Contextのtraceparentを後段へ引き継ぎ、OpenTelemetry対応の基盤へトレースを出力することもできます。
もう1つの変更が、betaの統一SQL APIです。Workers logs、Containersのセキュリティイベント、HTTP request logs、analyticsなどを、同じSQL方言・認証・APIで問い合わせられる方向へ進んでいます。人だけでなく、エージェントがログやトレースを調査することも想定されています。
料金体系も変わります。2026年12月1日から、ログとトレースはイベント数ではなく、取り込み量と保存量を軸にした統一Observability料金へ移行します。CloudflareでWorkersやAI Gatewayのログを多く保存している場合は、12月までに現在のデータ量を確認しておく必要があります。
3. GitHub Security Advisoryの内部相談と自動化がやりやすくなった
脆弱性報告を受けたあと、「報告者にはまだ見せたくない調査メモ」と「報告者と共有するコメント」を同じ画面で管理できないと、Slackや別Issueへ情報が分散しやすくなります。
GitHubはRepository Security Advisoryのconfidential commentsを追加しました。Confidentialを選んだコメントは、そのRepositoryへのwrite権限を持つ人だけが閲覧できます。報告者やwrite権限を持たない招待Collaboratorには表示されず、通知も送られません。
Private Vulnerability Report ↓Repository Security Advisory ├─ 通常コメント → 報告者と共有 └─ Confidential → 保守担当だけ一度投稿したコメントは、通常コメントとconfidential commentの間で切り替えられません。confidential commentの閲覧はAudit Logへ記録されます。
同時に、Repository Security Advisory comments REST APIもPublic Previewになりました。コメントの一覧取得、1件取得、追加、編集ができ、監査用の出力や自動トリアージへ組み込みやすくなっています。
ただしREST APIではconfidential commentは返りません。confidential commentはGraphQL APIから利用できます。
さらにSecurityAdvisory GraphQL APIには、CVE ID、影響コードへのリンク、GitHubのレビュー日時、NVDの公開日時、Repository Advisory URLなどのfieldが追加されました。severityやwithdraw済みかどうかでもサーバー側で絞り込めます。
脆弱性管理を自社ツールへ集約している場合は、GitHubのAdvisory情報を取得するためにRESTとGraphQLを何度も行き来する必要が減ります。
4. Protected Quick Tunnelsでローカル開発環境をメール認証付きで共有できる
AIコーディングエージェントが作った画面をスマートフォンで確認したいとき、Quick Tunnelは1コマンドでlocalhostを一時公開できます。ただし従来は、URLを知っていればアクセスできるため、開発途中の画面を共有するときは公開範囲に注意が必要でした。
Protected Quick Tunnelsでは、cloudflared 2026.9.3以降で —allowed-mail を付けると、指定したメールアドレスやドメインだけにアクセスを絞れます。
cloudflared tunnel --url http://localhost:5173 --allowed-mail you@example.com訪問者はCloudflare Accessから届くワンタイムPINでメールアドレスを確認します。Tunnelを作る側も見る側もCloudflareアカウントは不要です。
Authenticationは「そのメールアドレスを持っているか」をCloudflareが確認し、Authorizationはローカルのcloudflaredが —allowed-mail のルールと照合します。
コーディングエージェントへQuick Tunnelを作らせている場合は、公開URLを無条件で作るのではなく、—allowed-mail を標準にする運用が取りやすくなりました。
5. Cloudflare OHTTP Gatewayはバックエンドから利用者IPを切り離す
通常のHTTP通信では、アプリのバックエンドから利用者のIPアドレスが見えます。サービスによっては、この情報をそもそも受け取りたくないケースがあります。
CloudflareはOHTTP GatewayのClosed Betaを発表しました。
OHTTPはOblivious HTTPの略で、IETF標準として設計されたプライバシー保護の仕組みです。RelayとGatewayを分けることで、バックエンドへ「誰が送ったか」と「何を送ったか」を同時に見せない構成を作ります。
Client ↓ 暗号化済みRequestOHTTP Relay ↓ ClientのIPはここで見えるOHTTP Gateway ↓ Request内容を復号OriginVPNのように利用者が自分で対策するのではなく、アプリ側の設計としてIP情報を分離できるのがポイントです。Cloudflare OHTTP GatewayはClosed Betaで、今秋に有料アドオンとして提供する計画です。
分野別の更新解説
AWSでは、前日のAWS Well-Architected Agent公開が引き続き大きな更新です。複数AWSアカウントを週次で分析し、コスト、セキュリティ、レジリエンス、性能の改善案を優先順位付きで提示します。現時点ではPreviewなので、自動生成された修正案は人が確認してから適用する前提です。
GitHubでは、前日のasync merge APIも自動化に直結する更新です。マージ要求を投げたあと、1回のAPI呼び出しで完了を待ち続けるのではなく、request IDを使って後から状態を確認できます。stacked PRにも対応しています。
小さな変更まとめ
今回確認した範囲では、React、Vue 3、Vite、Node.js、Bun、PHP、Docker Engine、Kubernetes、Terraformについて、今日の上記更新より優先して取り上げる新しいStableリリースは確認できませんでした。
一方でCloudflareはBirthday Weekの更新が続いており、AI検索、Observability、Tracing、Tunnel、プライバシー基盤までDeveloper Platformの範囲を広げています。
実務で今日確認すること
AIエージェントから最新情報を調べる処理を作っている場合は、URLを直接推測させるだけでなく、検索ツールを明示的に持たせる設計になっているかを確認します。
Cloudflareを本番運用している場合は、障害調査が複数のログ画面へ分散していないかを確認します。Tracesと統一SQL APIはbetaを含むため、まずは検証環境でデータの見え方を確認するのが安全です。
GitHubでprivate vulnerability reportを受けている場合は、保守担当だけの調査メモをconfidential commentへ集約できるか確認します。API連携を持っている場合は、REST APIで取得できないconfidential commentがある点も設計に入れておきます。
Quick Tunnelを開発プレビューに使っている場合は、—allowed-mail を標準化できるか確認します。AIエージェントがTunnelを自動作成する運用では、公開範囲を明示した方が安全です。
参照情報
- Introducing Web Search API via AI Gateway
- 8 major updates to Cloudflare Observability
- Introducing Cloudflare Traces
- Confidential comments on repository security advisories
- Repository security advisory comments API in public preview
- New fields for SecurityAdvisory GraphQL API
- Protected Quick Tunnels
- Announcing Cloudflare OHTTP Gateway
- What is AWS Well-Architected Agent?
- GitHub async merge API generally available