10月1日は、日々の運用を「人が確認して次へ進める」形から、自動化の流れに載せる更新が目立ちました。
AWSはクラウド構成を継続的に点検するWell-Architected Agentをプレビュー（Preview）で公開しました。Cloudflare AI Searchは画像やスキャンPDFを扱える検索基盤として一般提供になり、GitHubはプルリクエストのマージを非同期で処理するAPIを正式提供しています。
今日何が重要か
- AWS Well-Architected Agentは、クラウド構成を週次で分析し、優先順位付きの改善案を提示します。
- Cloudflare AI Searchは、画像の見た目を直接検索する仕組みと、スキャンPDFのOCRに対応しました。
- GitHubのasync merge APIは、重いマージ処理の完了を1回のAPI呼び出しで待たず、後から状態を確認できます。stacked PRにも対応します。
3件とも、個々の機能追加より「運用の待ち時間や手作業を減らす」という流れで見ると理解しやすい更新です。
1. AWS Well-Architected Agentはクラウド改善を週次で回す
複数のAWSアカウントを運用していると、改善点を集め、何から直すか決めるだけでも作業になります。AWS Well-Architected Agentは、この整理と優先順位付けを継続的に行うための新しいサービスです。
10月1日にプレビューとして公開されました。コスト、セキュリティ、レジリエンス、性能の4つの観点でAWS環境を分析し、リソース、アプリケーション、アーキテクチャの各レベルで改善案を出します。定期的な推奨は週次で更新されます。
AWSアカウント群 ↓ 定期分析Well-Architected Agent ↓コスト / セキュリティ / レジリエンス / 性能 ↓優先順位付きの推奨 + SSM Runbook / IaC修正案 ↓人が内容を確認して適用従来のWell-Architected Toolは、質問に答えながら構成をレビューする仕組みが中心でした。Agentは実際の環境やIaCを継続的に分析し、ビジネス目標に合わせて推奨の優先順位を付けます。1つのAgent Profileで最大100 AWSアカウントを対象にでき、すべての商用AWSリージョンをスキャンできます。
現時点ではプレビューで、アプリケーション単位の推奨もベータ扱いです。AWSはAIが生成した内容を実行前に十分レビューするよう案内しています。
利用できるAWS Supportプランも限られます。対象はBusiness+、Enterprise On-Ramp、Enterprise Support、Unified Operationsで、DeveloperとBusinessプランでは利用できません。リリースノートと利用条件を確認してから試すのが安全です。
2. Cloudflare AI Searchが画像とスキャンPDFを直接検索しやすくなった
社内マニュアルに画面キャプチャが多い、紙資料をスキャンしたPDFを検索したい、商品画像から似た見た目を探したい。こうした用途では、文章だけをベクトル化する検索では情報を取りこぼします。
Cloudflare AI Searchが10月1日に一般提供となり、画像のピクセルを直接埋め込みへ変換するnative image embeddings（画像そのものを使う埋め込み）と、スキャンPDF向けのOCRが追加されました。テキストファイルとPDFは、1ファイルあたり4 MiBから10 MiBまで扱えるようになっています。
従来画像 → 説明文を生成 → テキスト埋め込み → 検索
現在画像 → 画像そのものを埋め込み ┐説明文 → テキストとして理解 ├→ 検索結果を統合 → 必要なら再ランキングスキャンPDF → OCR ┘CloudflareはQwen3-VL-Embeddingでnative multimodal retrievalを提供しています。テキスト専用の埋め込みモデルを選んだ場合でも、画像クエリをToMarkdownで説明文へ変換して検索できます。
検索時にはベクトル検索とキーワード検索を並行して実行し、結果を統合したうえで必要に応じて再ランキングします。RAGで「意味が近い資料」と「用語が一致する資料」の両方を拾いたい場合に使いやすい構成です。
課金開始は2026年11月1日です。無料枠は残るため、既にAI Searchを試している場合は、11月以降のインデックス容量、取り込み量、検索回数を確認しておく必要があります。
3. GitHubのasync merge APIでマージ処理を待ち続けなくてよくなった
自動化ツールからプルリクエストをマージするとき、処理が重いリポジトリでは「マージが終わるまで1回のAPI呼び出しを待つ」設計が扱いにくくなります。
GitHub async merge APIが一般提供となり、マージ要求の受付と実際の処理を分離できるようになりました。
自動化ツール → PUTでマージ要求 ← request ID ↓ GitHubが非同期処理 ↓自動化ツール → GETで状態確認 ← 完了 / 失敗など個別のプルリクエストだけでなく、merge queueへの追加、直接マージ、stacked PRのマージにも対応します。GitHubによると、stacked PRを扱えるマージAPIはこのasync merge APIだけです。
GitHubはプログラムからマージする場合の推奨手段として、従来の同期REST APIやGraphQL mutationよりasync merge APIを案内しています。既存の自動化を移行する場合は、1回のレスポンスで完了を期待する処理を、request IDを保存して状態を確認する設計へ変える必要があります。
4. Workers KV Instantは小さな設定値の高速読み取りに特化している
CloudflareはWorkers KV InstantをPrivate Betaで公開しました。既存のWorkers KVとほぼ同じAPIを使いつつ、内部ではCloudflareのQuicksilver v2を利用します。
用途として分かりやすいのは、機能フラグや全世界で共有する設定値です。リクエストごとに読みたい一方、更新はたまにしか起きないデータに向いています。
Cloudflareの計測では、Instantモードの全読み取りのp99は1.62 ms、書き込みの全拠点反映はp99で256 msでした。Classicモードはそれぞれ287 msと4.38秒です。
ただし、一般的なKVの置き換えではありません。1 namespaceの合計容量は1 MBまで、最大10,000個のキー・値ペア、書き込みはnamespaceごとに1秒1回までです。保存料金は月額100ドル/MB、put・delete・listは1操作0.10ドルなので、大容量データや高頻度更新には向きません。
メタデータも未対応で、getWithMetadataはnullを返します。読み取りレイテンシが重要な小さな設定データに用途を絞る必要があります。
5. Cloudflare K2は生成側と受信側を切り離すイベントストリーム
注文完了イベントを分析システムと別の処理システムの両方で扱う場合、生成側と受信側を直接つなぐと、受信側の停止や処理遅延が生成側に影響します。
Cloudflare K2は、その間に耐久性のあるordered log（順序付きログ）を置くサーバーレスなイベントストリーミングサービスです。
Producer ↓Cloudflare K2 ├→ Consumer A（分析） └→ Consumer B（別処理）K2はR2上にpartitioned durable log（分割された永続ログ）を構築し、Consumerごとに自分の速度で読み進められるようにします。現在はWorkers Paidアカウント向けPublic Betaで、1 streamあたり最大10 GBの保存容量と30 MB/sのproduce（書き込み）が上限です。
Beta中は課金されません。Apache Kafkaクライアントのdrop-in対応はロードマップに含まれていますが、現時点の機能ではありません。
分野別の更新解説
Cloudflare Data PlatformはCloudflare Basinへ改称され、一般提供になりました。Apache IcebergとR2を基盤に、Basin Pipelinesで取り込み、Basin CatalogでIcebergのメタデータを管理し、Basin SQLで分析します。既存のCloudflare Pipelines、R2 Data Catalog、R2 SQLの設定はそのまま動作します。
AI分野では、CloudflareがClefとClef-flashをWorkers AIで公開しました。自由な文章生成より、決められた選択肢と確率を型付きで返すdecision modelです。「この問い合わせは緊急か」「どの担当へ渡すか」といった判断を、文章生成用の大規模言語モデルとは別のモデルへ分担させる設計に使えます。
GitHub Code Qualityのcode coverage uploadは、まだPull Requestがない新規ブランチへのpushではアップロードをスキップするようになりました。Pull Requestを作成した時点ですぐCoverageを送りたいワークフローは、pull_requestトリガーも追加する必要があります。
Scheduled code scanningは、初回の検証だけで休眠中のリポジトリが長期間アクティブ扱いになる挙動を見直しました。週次スキャンはpushまたはPull Requestによる解析が起きてから始まります。
GitHub Actionsのretention設定は、ArtifactとLogだけでなく、Check、Workflow Run、Statusにも適用されるようになりました。保存期間を超えた情報は自動削除され、後から保存期間を延ばしても削除済みデータは戻りません。
小さな変更まとめ
今回確認した24時間では、React、Vue 3、Vite、Node.js、Bun、PHP、Docker Engine、Kubernetes、Terraformについて、上記より優先して取り上げる新しいStableリリースは確認できませんでした。
一方、CloudflareはBirthday Weekの更新が集中しており、検索、データ基盤、イベントストリーミング、KV、AI Agent向けモデルまでDeveloper Platformの範囲を広げています。
実務で今日確認すること
AWSを複数アカウントで運用している組織は、AWS SupportプランがWell-Architected Agentの対象かを確認します。対象であってもプレビューなので、生成された修正案は人がレビューする前提で試すのが適切です。
RAGや社内検索を作っている場合は、テキスト以外に画像やスキャンPDFがどれだけ含まれているかを確認します。Cloudflare AI Searchを利用中なら、2026年11月1日からの課金開始も見積もりに入れます。
GitHubのマージをBotや社内ツールから実行している場合は、同期REST APIやGraphQL mutationに依存していないか確認し、async merge APIへ移せるかを検討できます。
Workers KV Instantは、既存KVの全面移行先ではなく、機能フラグやルーティング設定など、1 MB以内で更新頻度が低く、読み取り遅延を抑えたいデータだけを候補にします。
参照情報
- AWS Well-Architected Agent release notes
- What is AWS Well-Architected Agent?
- Cloudflare AI Search is now generally available
- GitHub async merge API generally available
- Introducing Workers KV Instant
- Announcing Cloudflare K2
- Introducing Cloudflare Basin
- Introducing Clef
- Code coverage uploads no longer fail CI for new branches
- Scheduled code scanning skips inactive repositories
- Actions retention now covers checks, runs, and statuses