.ALドメインのDNSSEC障害、CloudflareがEDE 33で透明性を向上
2026年7月3日、アルバニアの国別コードトップレベルドメイン「.AL」でDNSSECの鍵ロールオーバーに失敗する障害が発生した。この影響で、.ALドメインを使用する政府機関や銀行、メディアサイトが一時的にアクセス不能となった。
Cloudflareが運用するパブリックDNSリゾルバ「1.1.1.1」は、この障害に対してネガティブトラストアンカー（NTA）を適用して暫定対応を実施。同時に、新しい拡張DNSエラー（EDE）コード「EDE 33」を初めて導入し、NTAが適用されていることをクライアントに明示した。
この記事では、.AL障害の経緯と、DNS運用におけるNTAの透明性を高めるEDE 33の技術的意義を解説する。TLDレベルのDNSSEC障害がもたらす影響と、再発防止に向けた課題を考察する。
.ALドメインで何が起きたのか
2026年7月3日14時15分（UTC）ごろ、アルバニアの通信規制当局AKEPが.AL TLDのDNSSEC鍵を更新しようとした際に設定ミスが発生した。新しいDNSKEYを公開したが、ルートゾーンに登録されていたDSレコードは古い鍵のままであり、DNSSECの信頼チェーンが切断された。
その結果、1.1.1.1を含む世界中の検証対応DNSリゾルバは、.ALドメインのDNS応答を検証エラー（SERVFAIL）として拒否するようになった。障害発生から約3時間後の17時15分、Cloudflareは1.1.1.1に.AL向けのNTAを適用し、検証を一時的にバイパスして名前解決を回復させた。
AKEPはその後、新しいDNSKEYも削除してしまい、ゾーンからDNSKEYが存在しない状態に陥った。最終的に19時15分ごろ、ルートゾーンからDSレコードが削除され、.AL全体がDNSSEC未署名の状態で名前解決が再開された。記事公開現在も、.ALは未署名のままである。
.DEに続くTLD障害の連鎖
この障害は、わずか2ヶ月前にドイツの.DE TLDで発生した同様のDNSSEC障害を想起させる。.DEの事例でも、1.1.1.1はNTAを適用して暫定対処を行い、事業者の対応を待つ形となった。
TLDレベルのDNSSEC障害は頻発するものではないが、一度発生すると配下の全ドメインに影響が波及する。.ALはCloudflare RadarのTLDランキングで191位に位置し、アルバニアの政府サービスや金融機関、報道機関などが集まる重要なドメイン空間だ。
この比較からわかるように、DNSSECの信頼チェーンはルートゾーンのDSレコードとTLDゾーンのDNSKEYが一致して初めて成立する。ロールオーバーの手順を誤ると、連鎖的に全下位ドメインの検証が失敗する仕組みだ。
NTA適用の判断基準
CloudflareはNTAを適用する前に、AKEPへの直接連絡とDNS-OARC Mattermostへの投稿を通じてコミュニティに注意喚起を行った。しかし、AKEPの連絡先アドレス自体が.ALドメインだったため、障害発生中は連絡が取れないという悪循環に陥った。
NTAの適用は、DNSSEC検証を停止するという強い措置だ。Cloudflareの著者によれば、.DEの事例と同様に「障害が公共に確認されており、すべての検証リゾルバに等しく影響する」という点を重視して判断したという。検証を停止しても名前解決を維持する方を優先した格好だ。
NTAの抱える透明性の課題
NTAはDNSSECの緊急回避手段として有効だが、一つ大きな欠点がある。それは、クライアント側からNTAの適用を検知できないことだ。NTA配下で返されたDNS応答は、通常の検証済み応答と見分けがつかない。
RFC 7646でもこの問題は認識されており、NTAの適用状況を運用者が公開することが推奨されている。Cloudflareは.DEや.ALの際にステータスページで情報を公開したが、それでも利用者が自発的に確認しなければ気づけない。監視ツールやアプリケーションがDNS応答だけで状況を把握する手段がなかった。
ANSWER: google.al → 142.251.142.196
EDE: 9 (DNSKEY Missing)
EDE: 33 (Negative Trust Anchor)
ANSWER: google.al → 142.251.142.196
● EDE 9で根本的なDNSSECエラーも同時に通知
この「見えないNTA」は、なりすましDNS応答と正当な応答を区別するDNSSECの根幹を揺るがす。NTAが適用されている間、利用者は保護されていない状態で通信していることになるが、それを知る術がなかったのだ。
EDE 33がもたらす透明性
拡張DNSエラー（EDE）コードはRFC 8914で定義されており、DNSリゾルバがエラー時だけでなく成功応答にも追加のコンテキスト情報を付加できる仕組みだ。Quad9のBabak Farrokhi氏が提案し、Cloudflareも共同執筆者として参加したインターネットドラフトで、NTAの適用を示す新しいEDEコード「EDE 33」が定義された。
1.1.1.1は.AL障害において、このEDE 33を初めて実運用に投入した。NTAが適用されている間、.ALドメインへのすべてのDNSクエリに対して、EDE 33が付加された応答が返されている。これにより、クライアントや監視ツールはDNS応答だけで「この応答はDNSSEC未検証である」と判断できるようになった。
EDE 33の実装と応答例
以下は、1.1.1.1にgoogle.alの名前解決を問い合わせた際の応答だ。ステータスはNOERRORで正しい回答が返されているが、2つのEDEコードが付加されている。
$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196EDE 9（DNSKEY Missing）は、DNSSECの信頼チェーンが切断された根本原因を示している。EDE 33（Negative Trust Anchor）は、1.1.1.1がNTAを適用して応答を返したことを示す。この2つの情報が揃うことで、運用者は「本来は検証エラーになる状況だが、NTAによって暫定的に解決された」という全体像を把握できる。
このフローは、1.1.1.1内部でNTAがどのように処理されるかを示している。EDE 33は、NTAが有効な間、DNSSECを使っていないドメインへのクエリにも付加される。NTAはゾーン全体に適用されるため、透明性もゾーン全体に対して一律に提供される設計だ。
.DE障害で生じた問題も解決
.DE障害の際、1.1.1.1はDNSSECの根本エラーではなく「EDE 22（No Reachable Authority）」を誤って返していた。これは、NTA配下で権威サーバーに到達できない場合に発生するエラーであり、真の原因を隠蔽してしまう問題があった。
.AL障害ではこの点が改善され、EDE 9（DNSKEY Missing）が正しく返されている。EDE 33と組み合わせることで、「なぜ検証に失敗したのか」と「なぜ応答が返されたのか」の両方をクライアントが把握できるようになった。
今後の標準化と運用への影響
EDE 33はIANA（Internet Assigned Numbers Authority）によって正式に割り当てられており、Knot DNSプロジェクトのkdigツールはすでにEDE 33を名前で認識するようになっている。また、Unbound向けのプルリクエストもレビュー段階にある。他のDNSリゾルバ実装も追随することが期待される。
このインターネットドラフトはIETFのDNSOPワーキンググループに提出済みで、2026年7月18日から24日にウィーンで開催されるIETF会合で議論される予定だ。標準化が進めば、EDE 33はすべての主要DNSリゾルバで実装される可能性が高い。
国内DNS運用者への示唆
国内のISPや企業が運用するDNSリゾルバでも、DNSSEC検証を有効にしているケースが増えている。.ALのようなTLDレベルの障害は稀だが、.JPや他のccTLDで発生しないとは限らない。EDE 33に対応したリゾルバ実装を採用することで、障害時の透明性を確保できる。
また、NTAの運用には慎重さが求められる。Cloudflareは.DEと.ALの両方で、コミュニティへの通知後にNTAを適用し、問題解決後に速やかに解除している。このバランス感覚は、他のDNS運用者にとっても参考になる対応だ。
残された課題
記事公開現在、.ALはDNSSEC未署名のままだ。DSレコードがルートゾーンに再登録されない限り、.AL配下のすべてのドメインはDNSSECの保護を受けられない。AKEPがいつ復旧作業を完了させるかは不透明である。
より根本的な問題として、TLD事業者のDNSSEC運用スキル不足が浮き彫りになった。鍵ロールオーバーは手順を誤ると広範囲に影響を及ぼす重要なオペレーションだ。ICANNやレジストリコミュニティによるガイドラインの整備や訓練の機会提供が求められる。
この記事のポイント
- .AL TLDのDNSSEC鍵ロールオーバー失敗により、2026年7月3日に全.ALドメインが一時的に解決不能となった
- Cloudflareの1.1.1.1はNTAを適用して暫定対処を行い、同時に新しいEDEコード「EDE 33」を初めて実運用に投入した
- EDE 33はNTAの適用をDNS応答内で明示し、従来の「見えないNTA」問題を解決する
- .DEに続くTLDレベルのDNSSEC障害は、TLD事業者の運用スキル向上とNTAの標準化の必要性を浮き彫りにした
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
83%の組織がエージェントAI対応にインフラ刷新が必要と回答、Google Cloud調査
Google Cloudが2026年7月に公開した「State of AI Infrastructure」レポートによると、実に83%の組織が「本番レベルのエージェントAIを支えるにはインフラの刷新が不可欠だ」と回答した。この数字はもはや一部の先進企業だけの課題ではなく、業種を問わず広がる構造的な問題を浮き彫りにしている。
本記事では、Google Cloud Blogの調査概要をもとに、エージェントAIが既存のクラウド基盤に与える負荷と、企業が次に打つべきインフラ戦略を解説する。推論コストの急増やエージェントの統制不能、データの断片化、エネルギー制約といったテーマを具体的なデータとともに取り上げる。
推論コストの急増と流動的コンピューティング
推論税の正体
エージェントAIは1回の指示で数百の後続アクションを連鎖的に引き起こす。チャット型AIのように単発で完結する処理とは根本的に負荷の性質が異なる。Google Cloud BlogのDrew Bradstock氏によれば、この連続推論ループがレガシーアーキテクチャに加わる経済的負担を「推論税」と呼んでいる。
調査では62%のリーダーが「データエグレス料金やストレージ肥大化、アイドル状態の専用ハードウェアによって深刻な推論税が発生している」と回答した。81%は運用の複雑さをAIスケーリングの隠れたコストとして挙げている。
上図が示すのは、エージェントAIの負荷特性と基盤の適合性がコストを左右する構図だ。ストレージ肥大化を放置すれば推論税は雪だるま式に膨らみ、競争力を大きく損なう。
TPU 8tとTPU 8iが示す選択肢
規模の大きいトレーニングにはTPU 8t、低レイテンシ推論にはTPU 8iといった具合に、用途に合わせた計算リソースを動的に組み合わせる発想が鍵になる。Google Cloud Blogの記事では、重いトレーニング、リアルタイム推論、オーケストレーションの3層に分けた「流動的コンピュート」が提案されている。
- 大規模学習向け：TPU 8t（第8世代）は第7世代比で約3倍の性能と最大2倍の電力効率を達成。超大規模モデルの学習時間を大幅に短縮する
- 低レイテンシ推論向け：TPU 8iはオンチップメモリを最大化し、リアルタイム応答が求められるエージェントの思考と反応を高速化する
- 制御プレーン向け：ArmベースのGoogle Axion CPUが強化学習シミュレーションやエージェントのオーケストレーションをコスト効率よく実行する
こうした選択肢を使い分けることで、ピーク負荷時だけ専用チップを割り当て、普段は汎用プロセッサに戻すといった柔軟なリソース管理が可能になる。
急拡大するエージェントの統制
エージェントスプロールの現実
エージェントはメールの読み取りからデータベース照会、業務ワークフロー実行まで自律的に動く。組織内で数十、数百のエージェントが稼働し始めると、個別管理が極めて難しくなる。これを業界では「エージェントスプロール（agent sprawl）」と呼び始めており、調査でも79%のリーダーがセキュリティ・ガバナンス・MLOpsを推論スケーリングの最大の課題に挙げている。
上図のように、統制プレーンを導入することで、これまで管理者が人力で追いかけていた権限設定や操作ログが集約され、監査や緊急停止も一元的に実施できる。調査では78%の組織が生成AIソリューションをメインのクラウドパートナーから直接調達しており、この集中傾向は2025年から30ポイント上昇している。
Agent Gatewayが担う役割
Google Cloud Blogで紹介されているAgent Gatewayは、企業向けに設計されたエージェント統制のハブだ。エージェント同士のデータ共有を可視化し、読み取りと書き込みのスコープを細かく設定できる。重要なアクションの前には人間の承認を挟むヒューマンインザループ機能も提供する。
- 全エージェントの認証を統一し、分散ツールをつなぎ合わせる必要がない
- データ共有のログと監査証跡を完全に管理できる
- エージェント単独では実行できない重要操作に対して、人による承認フローを組み込める
スケールする自律エージェント群を安全に運用するうえで、こうした統制基盤はもはやオプションではなく必須のレイヤーになりつつある。
データ基盤の統一
自律型エージェントは推論のたびに組織全体へ重いクエリを発行する。Drew Bradstock氏の指摘では、データがサイロ化して断片化していると「エージェントは事実上、目隠しをされたまま飛んでいる」状態になるという。このため、断片化したデータを単一の文脈で扱える統合データ層の整備が急務とされている。
統合データ層が整うと、エージェントはデータの置き場所を意識せずに検索・推論できる。非構造化データを自動的に構造化するSmart Storageと、マルチクラウド環境を横断するCross-Cloud Lakehouseが、この層を現実のものにしている。
ハイブリッドマルチクラウドとデジタル主権
パブリッククラウドかオンプレミスかという二者択一はすでに終わっている。調査では52%の組織がハイブリッドマルチクラウド構成を採用していた。これは単なるコスト分散ではなく、デジタル主権とデータの重力が強い推進力になっているからだ。
- データ所在地規制への対応：調査参加者の48%が厳格なデータレジデンシー管理を優先事項に挙げている。各国の法改正に即応できる柔軟な配置が求められる
- 完全隔離環境の需要：Google Distributed Cloudのようにパブリッククラウド技術をオフラインで利用できるサービスが、政府機関や金融機関を中心に拡大している
- データ重力の現実：巨大なデータセットは動かすより「その場で処理する」方が現実的で、エッジやオンプレとの組み合わせが不可欠になる
つまり、単一のクラウドに依存する時代は終わり、データの物理的な位置と主権に合わせてAIを走らせる場所を選べるアーキテクチャが標準になりつつある。
エッジでのAI実行が必然になる理由
調査結果の中で特に目を引くのが、90%の組織が「エッジへのAI配置が重要」と回答し、72%は「極めて重要」または「非常に重要」と位置づけた点だ。エージェントAIのリアルタイム性を追求するほど、集中型クラウドだけでは限界が露呈する。
エッジに推論機能を分散させると、クラウド往復のレイテンシが不要になるだけでなく、通信断でも業務が停止しない耐障害性と、トークンあたりの変動費削減を同時に実現できる。製造現場や病院、小売店舗など「止まらない自律処理」が求められる現場にとって、これが決定的な価値になる。
エネルギー壁を突破する設計
91%のリーダーがハードウェア選定時に消費電力を考慮し、61%はそれを「主要または極めて重要な要素」と位置づけている。かつて年次報告書のサステナビリティ指標でしかなかった電力消費が、今ではデータセンターの立地や事業継続そのものを左右する制約に変わっている。
- 電力網の逼迫：一部地域では追加電力の調達が不可能で、新規の計算インフラをプロビジョニングできない
- 規制圧力の強化：ドイツでは新設データセンターにPUE 1.2以下が義務化。アイルランドは大規模データセンターに100％のオンサイト発電能力を要求
- TCOへの影響：高消費電力のハードウェアは冷却設備やラック設計の大規模投資を強いり、総保有コストを押し上げる
Google Cloud Blogによれば、ワットあたりの性能向上が「戦略的資産」として位置づけられている。TPU 8tは第7世代比で最大2倍の電力効率を達成しており、規制基準を満たしながら高性能を維持する設計思想がエネルギー壁を突破するカギだとされている。
まとめ
本レポートの核心は「エージェントAI時代のインフラは、計算・セキュリティ・データ・エッジ・電力のすべてを統合的に設計しなければならない」という一点に集約される。AI Hypercomputerのような各レイヤーを共同設計するアーキテクチャが、高コストで機能不全に陥る従来モデルからの脱却策として注目されている。
物理世界とデジタルを結ぶフィジカルAIの波も現実化しつつあり、ロボットのトレーニングにデジタルツインを使う取り組みがGoogle Cloud上で始まっている。インフラ戦略を抜本的に見直すタイミングが、いま訪れていると言える。
この記事のポイント
- 83%の組織がエージェントAI本番運用にインフラ刷新が必要と回答
- 62%が推論税、81%が運用の複雑さをスケーリングの隠れコストと認識
- 79%がセキュリティ・ガバナンス・MLOpsを最大の課題に挙げている
- 90%がエッジAIを重要視し、72%は「極めて重要」と回答
- 91%がハードウェア選定で消費電力を考慮し、ワットあたり性能が新たな指標に
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
VercelがBetter Authを買収、TypeScript認証ライブラリとエージェントIDの未来
VercelがBetter Authを買収。TypeScript認証ライブラリとエージェントアイデンティティの取り込み
2026年7月7日、VercelはオープンソースのTypeScript認証ライブラリ「Better Auth」を買収したと発表した。ライブラリの週間npmダウンロード数は470万を超え、すでに850人以上のコントリビューターが開発に参加している。創設者のBereket Engida氏とコアチームはVercelに加わり、Better Authそのものと、関連プロジェクトであるエージェント認証プロトコル「Agent Auth」の開発を続ける。
今回の買収は、認証の仕組みをフレームワークやプラットフォームに依存しない形で提供する動きであり、なかでも「エージェントに独自のアイデンティティを与える」という構想が注目を集めている。背景と具体的な影響を順に整理していく。
Better Authとは何か。週間470万DLの認証ライブラリ
Better Authは、TypeScriptで書かれたオープンソースの認証ライブラリだ。従来の認証ライブラリに比べて設定がシンプルで、Next.jsやNuxtなど特定のフレームワークに依存しない。データベースやセッション管理の選択肢も広く、開発者が自前で認証周りをコントロールできる点が特徴である。
フレームワーク非依存の設計思想
多くの認証ライブラリは特定のフレームワークと密結合だったり、プラットフォームの管理画面を通さなければ設定が完了しなかったりする。Better Authは「どこでも動き、開発者が認証を所有する」という原則で作られている。これにより、プロジェクトの要件が変わっても認証部分の移行が容易になる。
コミュニティ主導の成長
470万ダウンロードと850人以上のコントリビューターという数字は、単なるGitHubスターの数ではない。実際に本番環境で使われ、機能追加やバグ修正が活発に行われている証拠である。Vercelは買収後もMITライセンスを維持し、コミュニティガバナンスを継続すると明言している。
買収の背景。Vercelが描く「オープンウェブ」と認証の位置づけ
Vercelは2025年に公開した「オープンSDK戦略」のなかで、ソフトウェアはデフォルトでオープンであり、疎結合で、どのプラットフォームにも移植可能であるべきだと述べている。Next.jsやAI SDK、Nuxtにもこの方針が適用されており、今回のBetter Auth買収もその延長線上にある。
認証を「所有する」という考え方
クラウドサービスが認証を代行する形は便利だが、ロックインのリスクがある。Better Authのようにライブラリ単位で認証を導入できれば、インフラを移行しても同じ仕組みを使い続けられる。Vercelはこの「所有可能な認証」をエコシステムに取り込むことで、開発者にとっての自由度を高めようとしている。
エージェントアイデンティティが切り開く、新しい認証の形
買収発表のなかで特に強調されたのが、エージェント（自律的に動作するソフトウェア）に「自分自身のID」を持たせるという構想だ。Better Authチームが開発している「Agent Auth」プロトコルは、まさにこれを実現するためのものである。
この概念図で示すように、Agent AuthではエージェントごとにIDを発行し、スコープを絞った権限と失効可能な認証情報を持たせることができる。ユーザーが単一のコントロールポイントから、個々のエージェントの権限を管理できる点が革新的だ。
なぜエージェントに独自IDが必要なのか
現在、AIエージェントがユーザーに代わって予約や購入を行う場合、エージェントはユーザー自身の認証情報を使ってサービスにアクセスする。この方式では、エージェントに渡す権限を細かく制御できない。また、不正が疑われた場合に特定のエージェントだけを停止することが難しく、結局すべての連携を遮断する必要があった。
Agent Authは、エージェントひとつひとつに「ペルソナ」のようなIDを割り当てる。たとえば「カレンダー参照専用エージェント」「メール送信専用エージェント」といった具合に役割を分け、不要になればそのIDだけを無効化できる。これはエージェントが当然のように動く世界において、セキュリティと管理性を両立する基盤技術といえる。
Vercel Connect と eve への統合
Better AuthチームはVercelに加わり、このエージェントアイデンティティをVercel Connectとeveに組み込むと発表されている。Vercel Connectは開発者がさまざまなサービスやAPIを安全に連携させるための仕組みであり、eveはVercelが提供するAIエージェントプラットフォームである。認証レイヤーが標準装備されることで、エージェントを使った機能をより安全かつ手軽に実装できるようになるだろう。
開発者コミュニティとライブラリの今後
買収によってBetter Authのライセンスや開発体制が変わるのではないかと懸念する声もある。しかしVercelは、ライブラリはMITライセンスのまま無料で提供され、名称も変更されず、同じコミュニティガバナンスモデルで開発が続くと明確に述べている。
オープンソースとしての継続
Better AuthのGitHubリポジトリは引き続き公開され、プルリクエストやIssueを通じたコミュニティ参加も歓迎される。Vercelのリソースが投入されることで、ロードマップの進行速度が上がったり、ドキュメントの整備が進んだりするメリットが期待できる。
フレームワークサポートの拡大
Better AuthはすでにNext.js以外にもNuxt、SvelteKit、Remixなど多様なフレームワークで利用できる。Vercelは特定のフレームワークに偏らないサポートを続ける方針を示しており、エコシステム全体への貢献が加速する可能性がある。
Vercelの戦略から見る、認証とエージェントの未来
今回の買収は、単に認証ライブラリを手に入れる以上の意味を持つ。Vercelはすでにホスティング、サーバーレス関数、エッジネットワーク、AI SDKと積み上げてきた。そこに「認証」と「エージェントアイデンティティ」というピースが加わることで、開発者がアプリケーションを作り、デプロイし、AIエージェントを安全に動かすための一気通貫のプラットフォームが姿を現しつつある。
「エージェントインフラ」の基盤として
Vercelは以前から「エージェントインフラストラクチャ（agentic infrastructure）」という概念を掲げている。これは、AIエージェントが動くための実行環境だけでなく、ストレージ、キュー、認証といったバックエンドの一式を提供する考え方だ。Better Authの買収によって、その認証レイヤーが大きく強化されることになる。
競合との差別化要因
他社のクラウドプラットフォームも認証機能を提供しているが、多くはプロプライエタリなサービスである。Better AuthのようにオープンソースでMITライセンスの認証ライブラリを中核に据えるアプローチは、ベンダーロックインを嫌う開発者層に強く支持されるだろう。とくにエージェントの台頭により認証の複雑さが増すなかで、「所有できる認証」の価値はますます高まっていく。
この記事のポイント
- VercelがオープンソースのTypeScript認証ライブラリ「Better Auth」を買収。創設者とコアチームがVercelに参加する。
- Better Authは週間470万ダウンロード、850人以上のコントリビューターを持つ。MITライセンスとコミュニティガバナンスは維持される。
- エージェントに独自のIDと制限付き権限を与える「Agent Auth」プロトコルの開発が加速し、Vercel Connectやeveに統合される予定。
- 従来のエージェント実行における権限制御の課題を解決し、エージェントごとの失効やスコープ管理が可能になる。
- Vercelは「オープンSDK戦略」に沿って認証レイヤーを強化し、エージェントインフラの基盤を固める動きを加速させている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloud Run Sandboxesがパブリックプレビュー、AI生成コードを安全に隔離実行
Cloud Run Sandboxesがパブリックプレビューに。AI生成コードを隔離実行
Google Cloudは2026年7月9日、Cloud Run上で信頼できないコードを安全に実行するサンドボックス機能をパブリックプレビューとして公開した。AIが生成したプログラムや、エンドユーザーがアップロードしたスクリプトを、ホスト環境やクラウドの認証情報から完全に分離した状態で動かせる。
起動はミリ秒単位で、既存のCloud RunインスタンスのCPUやメモリを共有する。追加のVMや専用のサンドボックスホスティングプラットフォームを使う必要はなく、追加料金も発生しない。この発表はベルリンで開催中のWeAreDevelopers World Congressで行われた。
これまで開発者は、AIが動的に生成したコードを安全に実行するために、コンテナクラスタを組んだり、サードパーティのmicroVMランタイムを契約したりする必要があった。Cloud Run Sandboxesは、その複雑さを取り除くサーバーレスネイティブの仕組みだ。
サンドボックスとは何か、なぜ必要なのか
サンドボックスとは、プログラムを隔離された領域で実行する仕組みのことだ。子供が砂場（サンドボックス）の中で自由に遊んでも、砂が外に散らばらないのと同じで、中で何が起きても外側のシステムには影響を与えない。
AIエージェントやLLM（大規模言語モデル）がコードを生成する時代では、この隔離が極めて重要になる。モデルが書いたPythonスクリプトに意図しないファイル削除やネットワーク経由のデータ流出が含まれていたとしても、サンドボックス内で止められるからだ。
Cloud Run Sandboxesは、既存のCloud Runサービスインスタンス内でほぼ瞬時に生成できる軽量な隔離実行境界だ。専用のVMを立ち上げる必要がなく、サーバーレス環境を離れずにすべてが完結する。
サンドボックスの仕組みとセキュリティ設計
シンプルな有効化とネイティブな呼び出し
利用開始は驚くほど簡単だ。Cloud Runサービスをデプロイする際に、gcloudコマンドまたはYAML設定でサンドボックスランチャーを有効にするフラグを1つ追加するだけでよい。有効化すると、軽量なサンドボックスCLIバイナリが実行環境に自動でマウントされ、標準的なサブプロセス呼び出しでプログラムからサンドボックスを生成できる。
実際の動作例として、LLMが動的に生成したPythonコードを安全に実行するデモが公開されている。1000個のサンドボックスを起動し、それぞれの処理を実行して停止するまでの平均レイテンシは500ミリ秒だ。
ゼロトラストを前提とした3層のセキュリティ境界
Cloud Run Sandboxesは、悪意あるコードや誤ったコードからホストアプリケーションとクラウドリソースを守るために、3つの重要なセキュリティ境界を強制する。
この3層構造によって、AIが生成したコードがどれほど予測不能な動作をしても、ホスト側への影響は生じない。セキュリティを理由にAIコード実行を諦めていた開発者にとって、大きな転換点になる。
3つの主要ユースケース
Cloud Run Sandboxesは特に以下の3つの用途で力を発揮する。いずれも「信頼できないコードを隔離実行する」という共通の要件を持つシナリオだ。
ADKとComputeSDKとの統合
Cloud Run Sandboxesは、Googleのエージェント開発キットであるADK（Agent Development Kit）の次期バージョンでネイティブサポートされる。新しいCloudRunSandboxCodeExecutorを使うと、ADKエージェントがわずか1行のコードでサンドボックス内のコード実行を指示できる。
また、ベンダーに依存しないサンドボックス実行用SDKであるComputeSDKにも対応が追加された。このSDKを使えば、Cloud Runサービスの外部からリモートでサンドボックスを呼び出すことも、サービス上のローカルツールとして直接使うこともできる。既存のツールチェーンにスムーズに組み込める設計だ。
コスト面の利点と実運用への影響
Cloud Run Sandboxesの大きな特長は、追加コストが一切かからないことだ。オンデマンドのVMに対して高いプレミアムを課金する専用サンドボックスホスティングプラットフォームとは異なり、既存のCloud Runインスタンスに割り当てられたCPUとメモリを直接共有する。
起動時間がミリ秒単位であることも実運用上の利点だ。従来のVMベースの隔離環境では、新しいVMを立ち上げるたびに数秒から数十秒の待ち時間が発生していた。Cloud Run Sandboxesなら、ユーザーからのリクエストに対してほぼ待ち時間なく応答できる。
Google Cloud Blogの記事で紹介されたデモでは、1000個のサンドボックスを起動してコードを実行し、終了するまでの平均レイテンシが500ミリ秒だった。これは「AIが生成したコードをリアルタイムで安全に実行する」という要件に対して十分実用的な数値だ。
この記事のポイント
- Cloud Run SandboxesはAI生成コードや信頼できないバイナリを安全に実行する隔離環境で、パブリックプレビューとして公開された
- 起動はミリ秒単位で、既存のCloud Runインスタンスのリソースを共有するため追加コストは発生しない
- 環境変数の隔離、ネットワーク通信のデフォルト遮断、安全なファイルシステムオーバーレイの3層でセキュリティを確保
- LLMコードインタプリタ、ヘッドレスブラウザ、ユーザー提出コードの実行が主要ユースケース
- ADKとComputeSDKに組み込み対応し、開発者は1行のコードでサンドボックス実行を指示できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GPT 5.6 Sol、Terra、LunaがAI Gatewayで利用可能に
GPT 5.6の3モデルがAI Gatewayで利用可能に
OpenAIの最新モデルシリーズ「GPT 5.6」が、VercelのAI Gatewayで限定的なプレビュー提供を開始した。Sol・Terra・Lunaの3モデルが揃い、いずれもコーディングや生物学、サイバーセキュリティといったエージェント的なタスクで従来世代より強化されている。トークン効率も向上しており、同等の処理をより少ないコストで実行できるのが特徴だ。
AI Gatewayは複数のAIプロバイダに統一APIでアクセスできるサービスで、利用状況の追跡やコスト管理、リトライやフェイルオーバー、パフォーマンス最適化を一手に引き受ける。今回の追加により、開発者はコードを変更せずに最新のGPTモデルへ移行できるルーティング機能も利用可能になった。
GPT 5.6 Sol・Terra・Lunaの違い
モデル指定はAI SDKでopenai/gpt-5.6-solのようにスラッグを渡すだけだ。用途や予算に応じて切り替えやすい設計になっている。
コードを触らずにモデルを切り替えるルーティングルール
AI Gatewayのルーティングルール機能を使うと、既存のコードを一切変更せずにモデルを差し替えられる。たとえばopenai/gpt-5.5で動いているアプリケーションを、コマンド1行でopenai/gpt-5.6-solへ振り向けることが可能だ。
rewriteルールを設定するだけで、アプリコードに手を入れず最新モデルへ移行できる。ルーティングルールはモデルのA/Bテストや段階的なロールアウトにも活用できる。本番環境でいきなり全トラフィックを新モデルに向けるのではなく、一部だけ振り分けて様子を見る運用も現実的だ。
AI Gatewayの料金体系とその他の機能
AI Gatewayはプロバイダの利用料金に上乗せせず、推論に対するプラットフォーム手数料も請求しない。BYOK（Bring Your Own Key）で自身のAPIキーを持ち込んだ場合でも同様に手数料は発生しないため、コストを厳密に管理したいチームにとっては安心できる設計だ。
利用状況の可視化と制御に役立つ機能も充実している。主なものは以下のとおりだ。
- カスタムレポートでチームやプロジェクト単位の利用状況を把握できる
- ゼロデータ保持（ZDR）に対応し、機密性の高いプロンプトの取り扱いも安心
- APIキー単位で予算上限を設定し、予期せぬコスト超過を防ぐ
- ルーティングルールでモデル切り替えやフェイルオーバーを自動化する
実際の開発フローに組み込む際の注意点
GPT 5.6シリーズは限定的なプレビュー提供の段階にある。本番環境で全面的に切り替える前に、モデルプレイグラウンドで動作を検証し、期待する出力品質やレイテンシが得られるか確認することを推奨する。特にエージェント的な使い方をする場合、従来モデルとはプロンプトの最適な書き方が変わる可能性もある。
また、Terraは「前世代と同等性能・半額」というコストメリットが明確だが、SolとLunaはユースケースによって費用対効果が大きく変わる。まずは低コストのLunaでプロトタイプを作り、本格的なタスクではSolに切り替えるといった段階的な活用が現実的な戦略になるだろう。
この記事のポイント
- GPT 5.6のSol・Terra・LunaがAI Gatewayで限定プレビュー提供を開始
- Terraは前世代と同等の性能を半額で提供するコストパフォーマンスが最大の魅力
- ルーティングルールによりコード変更なしでモデルを切り替え可能
- AI Gatewayはプロバイダ料金に上乗せせず、BYOKでも手数料なし
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Vercel Agentが本番環境に進出、プラン即許可で安全なAI運用を実現
Vercelが2026年7月8日、自社のAIエージェント「Vercel Agent」の大幅な機能拡張を発表した。従来はアラートのトリアージやプルリクエストのレビューが中心だったが、今回のアップデートでダッシュボード上に常設され、本番環境の調査やプロジェクトへの質問応答、承認後のアクション実行まで可能になった。
Vercel Agentの最大の特徴は「プラン即許可（Plan-to-Permission）」という新しい権限モデルだ。デフォルトで読み取り専用として動作し、デプロイのロールバックや設定変更といった操作は、具体的な作業計画を提案して承認を得たうえで、そのタスクに限定された一時的な権限のみを使って実行する。
本番稼働中のアプリケーションにAIを介入させるには、安全性の担保が不可欠である。Vercel Agentは独立したIDで動作し、生成したコードは隔離されたサンドボックスで検証する。この設計により「自律的でありながら制御された状態」を実現しており、AIエージェントの運用にまつわる信頼の課題に対して、具体的な解決策を示した製品といえる。
Vercel Agentの全体像と導入背景
Vercel Agentは、Vercelプラットフォーム上で動作するAIエージェントだ。アプリケーションのデプロイと実行を支えるインフラに組み込まれているため、本番環境で問題が発生した際に、最初に対応を開始できるポジションにある。アラートを受けてから自律的にログやメトリクス、デプロイ履歴を調査し、根本原因を特定して修正案を提示する。
Vercel社内では数ヶ月前から本番運用に組み込まれており、すでに具体的な成果が出ている。典型的な事例として、深夜23時に不良デプロイが行われ、チェックアウト用のエンドポイントが500エラーを返し始めたケースでは、オンコールエンジニアがログインする前にAgentがエラーを4分前のデプロイまでトレースし、即時ロールバックを推奨した。エンジニアが計画を承認すると、Agentが前の正常なビルドにロールバックし、エンドポイント修正用のプルリクエスト作成まで自動で進めた。アラート発生から問題緩和までの時間は3分未満だったという。
このデモは、同じインシデントに対する従来の対応とVercel Agent導入後の対応を比較した概念図である。Agentが自律的に調査と提案を行い、人間は最終判断に集中できる点が最大の違いだ。
本番環境にAIを近づけるための新セキュリティモデル
アプリケーションの修正や設定変更が可能なAIエージェントを本番環境に導入する場合、最も重要な問いは「どう安全にデプロイや設定変更を任せられるか」である。多くのAIエージェントはユーザーの全権限を引き継いで動作するため、誤った指示や混乱したサブエージェントの被害がそのまま本番に及ぶという構造的な課題を抱えている。
Vercel Agentはこの問題に対して、3つの要素からなる新しい権限モデルを実装した。エージェント自身の固有ID（Principal）、タスクごとの一時的な権限付与（Plan-to-Permission）、そして生成コードの隔離実行環境（Sandbox）である。これらはプラットフォームレベルで強制されるため、AIモデルの挙動にかかわらず安全策が機能する。
エージェント固有のIDによる帰属と権限の分離
一般的なAIエージェントは、操作する人間のIDと権限をそのまま使って動作する。その場合、エージェントが行った操作と人間が行った操作を区別できず、誰が何を指示し実行したのか追跡不可能になる。
Vercel Agentは「vercel-agent」という固有のプリンシパル（主体）として動作する。すべての変更操作には「誰が依頼したか」「誰が承認したか」「Vercel Agentが実行した」という記録が必ず残る。さらに、Agentに付与される権限は、操作を指示した人間がもつ権限の範囲を超えることはない。この設計により、説明責任（アトリビューション）と権限の透明性を両立している。
⚠️ 誤指示や誤動作の影響範囲がユーザーと同等
✅ 付与される権限は承認された計画の範囲に限定
この図は、従来型エージェントとVercel Agentの権限構造の違いを表している。Vercel Agentでは、常に「依頼者」「承認者」「実行者」の3者が記録され、権限も計画単位で一時的に付与されるため、誤動作の被害範囲が極めて狭い。
プラン即許可（Plan-to-Permission）の仕組み
多くの組織がAIエージェントを開発フローに統合する際、最初に直面するのが「事前に広範な権限を付与してしまう」という課題だ。これはエージェントに必要以上の権限を、必要以上の期間与えることになる。そのエージェントにプロンプトを送れる人なら誰でも、付与された権限の範囲にアクセスできてしまうため、権限の広さがそのままセキュリティリスクの大きさに直結する。
Vercel Agentはデフォルトで読み取り専用である。デプロイのロールバック、設定変更、キャッシュのクリアといった操作が必要な場合、Agentはまず実行計画を提案し、その計画に限定されたアクセス権限を要求する。ユーザーが計画を承認すると、Agentはそのタスクに必要な能力を一時的に取得し、作業完了後は自動的に読み取り専用状態に戻る。
Agentが行うすべてのAPI呼び出しは、3つのチェックを通過する必要がある。承認された計画で付与された能力（Capability）、トークンのスコープ、そしてチームの既存権限だ。これら3つすべてが許可する場合にのみ操作が実行され、このチェックはプラットフォーム側で強制されるため、AIモデルがどのような挙動をとっても安全策が破られることはない。Vercelはこの仕組みを「プラン即許可（Plan-to-Permission）」モデルと呼び、最小権限の原則を設計レベルで組み込んでいる。
この一連の流れでは、Agentが自律的に調査と提案を行う一方で、実際の操作権限は人間の承認を経て初めて発行される。人間の判断を挟むことで安全性を確保しつつ、Agentの自律性を最大限に活かせる設計だ。
サンドボックスによる生成コードの安全な検証
コードを生成するAIエージェントにはもうひとつ重大な課題がある。それは「生成されたコードが実際に動くかどうかは、実行してみるまでわからない」という点だ。動作確認されていない修正を本番環境に適用することは、さらなる障害を引き起こすリスクを伴う。
Vercel Agentが生成したコードは、Vercel Sandbox（FirecrackerマイクロVMによる短寿命の隔離環境）内で実行される。このサンドボックスは実際のプロジェクトのコピーを持っており、Agentは生成したコードを本物のビルドプロセス、テスト、リンターに対して実行し、問題なくパスしたものだけをPRとして提示する。たとえば壊れた設定ファイルを修正する場合、Agentが変更を加えてサンドボックス内でビルドテストを通過させ、その結果をPRにまとめるという流れになる。
この仕組みにより、Agentは自由にコードを生成して実行できるが、検証に失敗したコードや壊れた修正が人間の前に提示されたり、本番環境に直接届いたりすることはない。コードレベルの安全性をインフラ側で担保している点が重要だ。
現場の開発フローがどう変わるか
Vercel Agentはインシデント対応だけでなく、開発者が日常的に直面するさまざまなタスクを支援する。具体的なユースケースを4つ紹介する。
プルリクエストのレビュー
AgentにPRの確認を依頼すると、CIがパスしているだけでは検出できないパフォーマンスの低下やリスクの高い変更を指摘する。たとえば、ある変更によってページが毎回サーバーサイドレンダリングされるようになり、キャッシュが効かなくなっていないかといった観点までチェックできる。
コスト増加の原因追及
「なぜ今月の請求額が跳ね上がったのか」という問いに対して、Agentはコード変更履歴を調査し、コスト急増の原因となった特定のコミットを特定する。たとえば、あるページがキャッシュされずに毎回サーバーサイドレンダリングされるようになったコード変更を検出し、承認を得たうえで修正PRを作成する。
ビルド失敗の修正
失敗したデプロイをAgentに調査させると、ログを読み取り、問題のある設定ファイルを特定し、修正の許可を求めてくる。ユーザーが承認すれば、Agentが設定を修正し、サンドボックス内でビルドをテストしてからPRとして提出する。
本番リリースの安全性確認
フィーチャーフラグに関する質問に対して、Agentはコードと本番のライブメトリクスの両方を分析し、その機能をロールアウトしても安全かどうかを判断する。データに基づいた客観的な判断が得られるため、リリース判断の品質が向上する。
この比較図は、日常的な開発タスクにおける負荷の変化を表している。Agentが調査と提案を担うことで、開発者はコードの質やビジネス判断といったより本質的な業務に集中できる。
反脆弱性インフラがもたらす意味
Vercel Agentの発表で最も重要なポイントは、単にAIエージェントの機能が追加されたという話ではない。AIエージェントを「本番環境に近づけても安全に運用できる」という状態を、プラットフォームの設計で実現したことだ。
AIエージェントの時代において、真の限界は2つの天井で決まる。ひとつはモデルが「何をできるか」、もうひとつはユーザーが「何を許可するか」だ。モデル性能が向上し続けるなかで、実際の運用において重要になるのは後者、すなわち信頼の設計である。どれほど高性能なモデルでも非決定論的であり、非決定論的なシステムは非決定論的に失敗する。安全性は「エージェントが毎回正しい判断をすること」に依存してはならず、システムそのものに組み込まれていなければならない。
Vercelは長年にわたり、イミュータブルデプロイメント（デプロイが書き換え不可で、不良デプロイは1回のロールバックで元に戻せる仕組み）をはじめとする安全策を積み上げてきた。これらはもともとAIエージェントのために設計されたものではないが、自律システムが必要とするガードレールそのものとして機能する。Vercelはこの考え方を「反脆弱性インフラ（Anti-fragile Infrastructure）」と呼んでいる。
反脆弱性インフラの本質は、エージェントに誤りがあっても被害を局所化でき、人間のミスさえもコストを抑えられる点にある。安全性がインフラ層に組み込まれているため、エージェントが正しいことを前提にせずとも、実用的な権限を委譲できる。Vercel Agentのケースでは、自律的に調査と提案を行い、人間が承認した範囲内でのみ操作を実行し、何か問題があれば即座にロールバックできる。
このモデルは、AIエージェントの実運用における「自律性 vs 安全性」というトレードオフに対して、明快な解を示している。エージェントが仕事をし、人間が最終判断を保持し、インフラがフェイルセーフとして機能する。この3層構造が揃って初めて、本番環境にAIを近づける信頼の土台が成立する。
Vercel Agentの将来展望と利用開始方法
現時点でのVercel Agentは、異常の調査、プルリクエストの作成、プロジェクトや本番アプリに関する質問への回答が可能だ。今後のロードマップとして、特定分野の専門家エージェントへの委任機能が予定されている。たとえば、コードベース全体に対する詳細なセキュリティレビューや、フロントエンドのデザイン・UXレビューを、オンデマンドで専門家AIに依頼できるようになる見込みだ。
Vercel Agentは、ProプランおよびEnterpriseプランのチームに対して段階的にロールアウトされている。利用を希望する場合は、Vercelのアーリーアクセスページから申請するか、ダッシュボードのサイドバーにある「Agent」セクションから有効化できる。
この記事のポイント
- Vercel Agentは本番環境の異常を自律的に調査し、人間の承認を得て修正を実行するAIエージェントである
- 「プラン即許可」モデルにより、Agentの権限はタスク単位で一時的に付与され、完了後は読み取り専用に戻る
- 生成されたコードは隔離されたサンドボックスで検証され、本番環境に直接影響を与えない設計になっている
- イミュータブルデプロイメントなどのインフラ安全策と組み合わせることで、エージェントの誤動作コストを最小化する
- AIエージェントの実運用における信頼の課題に対して、プラットフォーム設計で安全性を担保するアプローチを具体化した製品といえる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Workers Cache登場、Worker専用キャッシュでコスト削減
Workers Cache の登場でCloudflare Workersが「オリジン」から「静的配信」へ進化
CloudflareがWorkers Cacheを正式にリリースした。これは単なるキャッシュ機能の追加ではない。Workersのアーキテクチャを根本から覆し、コストとパフォーマンスのトレードオフを解消する大きな転換点だ。一言で表せば「あなたのWorkerの前に、そのWorker専用のキャッシュを置ける機能」である。
1行の設定を追加するだけで、Workerが生成したレスポンスはCloudflareのエッジネットワークにキャッシュされる。キャッシュが有効な間はWorkerそのものが実行されず、CPU時間の課金もゼロになる。これは特に、サーバーサイドレンダリング（SSR）を行うアプリケーションにとって、待望のソリューションだ。
本記事では、なぜこの機能が必要とされていたのか、具体的に何が変わるのか、そして開発者がどのように活用できるのかを詳しく解説する。
問題: Workerがオリジンの場合、処理のたびにコードが実行され、キャッシュの恩恵を受けにくい。
効果: レスポンスが高速化し、WorkerのCPU実行コストが削減される。
この図が示すように、Workers Cacheはリクエストの最前線に立つ。これにより、Workerが事実上のオリジンサーバーとして振る舞う現代的なアプリケーションのパフォーマンスとコスト構造が劇的に改善される。
なぜサーバーサイドアプリに「Workerの前のキャッシュ」が必要だったのか
Workerが「経由点」から「オリジン」へ変わった世界
2017年のリリース当初、Cloudflare Workersはオリジンサーバーの手前でリクエストを書き換える「中間処理層」として設計された。A/Bテストの振り分けやヘッダーの追加といった、軽量な処理をエッジで実行するユースケースが中心だったのだ。当時、Workerはキャッシュよりもさらにオリジンに近い位置にあった。
しかし状況は一変した。AstroやNext.js、SvelteKitといった主要フレームワークが、ビルド成果物をCloudflare Workersで直接動かすアダプターを提供し始めたのである。これにより、Workerはもはや単なる中継点ではない。アプリケーションそのものがWorker上で動作する「サーバー」になった。裏側に別のオリジンサーバーは存在しなくなり、Worker自体がリクエストを処理するようになったのだ。
この変化は大きな問題を生んだ。従来のアーキテクチャでは、Workerがオリジンになると、すべてのリクエストがコードの実行を必要とするようになる。たとえ1秒前と全く同じHTMLを返す場合でも、だ。これはパフォーマンス上のレイテンシと、無視できないCPU実行コストを常に発生させることを意味していた。
静的生成と動的レンダリングのジレンマを解決する第三の道
この問題に対し、開発者はこれまで2つの選択肢から選ぶしかなかった。
- 静的サイト生成（SSG）：すべてのページをビルド時に事前生成する。表示は高速だが、コンテンツを更新するたびに全ページを再ビルドする必要がある。数千ページのサイトでは、このビルド時間が大きなボトルネックになる。
- サーバーサイドレンダリング（SSR）：リクエストのたびにページを動的に生成する。コンテンツは常に最新だが、全てのアクセスでレンダリングコストとレイテンシが発生する。
Workers Cacheはここに第三の選択肢、つまり「オンデマンドでサーバーレンダリングし、結果をキャッシュし、指定したTTL（生存期間）で更新する」という新しい手法を提供する。最初のリクエストだけがレンダリングコストを支払い、後続のリクエストはキャッシュから静的ファイルのように配信されるのだ。これはフレームワーク独自の複雑な仕組み（ISRなど）に依存しない、HTTP標準に則った解決策である。
パフォーマンスを極める主要機能「SWR」と「Vary」の内部動作
stale-while-revalidate が「待ち時間ゼロ」を実現する仕組み
Workers Cacheの真価を引き出すのが、stale-while-revalidate（SWR）ディレクティブだ。これはキャッシュされたレスポンスがTTLを超過した「古い（Stale）」状態でも、とりあえずその古いデータをユーザーに返しつつ、バックグラウンドで最新のデータを取得し直すHTTPの仕組みである。
SWRがない場合、キャッシュの有効期限が切れた後の最初のリクエストは、必ずWorkerが一からページをレンダリングするまで待たされる。しかしSWRがあれば、この最初のリクエストに対しても古いキャッシュが即座に返され、ユーザーは待ち時間を感じない。Workers CacheはこのSWRを完全にサポートしており、これによって「動的なサイトなのに、まるで静的サイトのように感じる」という体験を実現している。
この図の通り、SWRはTTLが切れた後の「最初の一人」が被る待ち時間を帳消しにする。Cloudflare Blogの記事によれば、Cloudflareは今年の早期にこのSWR機能をフルサポートしており、Workers Cacheはその上に構築されていることがわかる。
Vary ヘッダーが複数の表現をキャッシュする
現実のアプリケーションは、同じURLでもクライアントに応じて異なるレスポンスを返す必要がある。例えばブラウザにはHTMLを、APIクライアントにはJSONを返す場合や、対応状況に応じてWebPとJPEGを出し分ける場合だ。Workers Cacheは、このコンテンツネゴシエーションをHTTP標準のVaryヘッダーで解決する。
WorkerがVary: Acceptというヘッダーを付けてレスポンスを返すと、Cloudflareは「Acceptリクエストヘッダーの値」ごとに別々のキャッシュエントリを自動で作成・管理する。これにより、WebPに対応したブラウザにはWebP画像のキャッシュが、そうでない環境にはJPEG画像のキャッシュが返るようになる。開発者は複雑なキャッシュキーの設定を意識する必要はなく、標準的なHTTPのルールに従うだけで、安全かつ効率的に複数表現をキャッシュできるのだ。
開発者が知っておくべき設計思想「ゾーンではなくWorkerのキャッシュ」
エントリーポイント単位の柔軟なキャッシュ制御
Workers Cacheの最も革新的な部分は、それが「ゾーン（ドメイン）」ではなく「Worker」に紐づくという設計思想にある。この思想が、従来のCDNでは実現できなかったいくつもの高度なユースケースを可能にしている。
特に重要なのが、Workerのエントリーポイントごとにキャッシュの有効・無効を設定できる点だ。設定ファイルでエクスポート名（"default"や"CachedBackend"）を指定するだけで、認証処理を行うゲートウェイWorkerはキャッシュを無効化し（常にコードを実行するため）、その背後で重い処理を行うバックエンドWorkerだけにキャッシュを有効化する、といった構成が可能になる。
このエントリーポイント単位の制御により、キャッシュはアプリケーションアーキテクチャの一部として自然に組み込めるようになる。単一のWorkerの中に、キャッシュするレイヤーとしないレイヤーを共存させ、それらをコードで自在に結合できるのだ。これは、CDNキャッシュを単一のオリジンの前に置くという従来の考え方とは一線を画す。
マルチテナントを安全にする ctx.props の仕組み
ユーザーごとに異なる情報を返すAPIのキャッシュは、セキュリティ上の大きな課題を伴う。ユーザーAのキャッシュがユーザーBに見えてしまうような事故は、絶対に避けなければならない。Workers Cacheはこの問題を、ctx.propsの一部を自動的にキャッシュキーに含めることで根本的に解決している。
例えば、ゲートウェイWorkerで認証したユーザーIDをctx.propsにセットし、キャッシュが有効なバックエンドWorkerを呼び出すとする。Workers Cacheはこの「ユーザーID」の違いを認識し、ユーザーごとに完全に独立したキャッシュ空間を作り出す。これにより、「認証済みAPIはキャッシュできない」という固定観念を覆し、ユーザー単位で安全にレスポンスをキャッシュできるようになる。Cloudflare Blogによれば、これは他の主要CDNでは提供されていない、Workers Cache独自の強力な利点だという。
Workers Cacheがもたらすプラットフォームとしての進化
パフォーマンスとデータの近接性を両立するアーキテクチャ
Webパフォーマンスにおいては、コードを「ユーザーの近く」で実行するのと「データの近く」で実行するのは、しばしばトレードオフの関係になる。Workers Cacheはこのジレンマに対して、キャッシュを「糊（にかわ）」として利用する解決策を提示する。
具体的には、次のような構成が現実的になる。ユーザーの近くで動き、認証やルーティングといった軽量な処理を担当するWorker Aを配置する。一方、データベースへの重いクエリやレンダリングを実行するWorker Bを、Smart Placement機能でデータの近くに配置する。Workers Cacheは、このWorker Bの手前にのみ配置する。
リクエストが来ると、Worker Aが処理した後、サービスバインディングを通じてWorker Bを呼び出す。この時、Worker Bのキャッシュがヒットすれば、データの近くにあるWorker Bは実行されることなく、ユーザーの近くにあるキャッシュからレスポンスが返る。キャッシュミス時のみ、実際のデータへのアクセスが発生する。これにより、「ユーザー近接性」と「データ近接性」の良いとこ取りが可能になるのだ。
フレームワークとの統合とコストの透明性
Workers CacheはすでにAstroフレームワークのアダプターでネイティブサポートされている。設定ファイルに数行追加するだけで、ページ単位のTTLやタグベースのキャッシュパージが利用できる。TanStack StartやNext.js（Vinext経由）など他のフレームワークへの統合も現在進行中だ。
コスト面も明快だ。Workers Cacheのキャッシュヒット時は、通常のリクエスト課金は発生するが、WorkerのCPU実行時間に対する課金はゼロになる。キャッシュストレージに対する追加のGB単位の課金もないため、コスト削減効果を予測しやすい。ダッシュボードでは、キャッシュヒット率やヒット/ミス/バイパスの内訳が確認でき、パフォーマンスチューニングに必要なデータが一元管理されている。
この記事のポイント
- Workers Cacheは、Workerの手前に専用の階層型キャッシュを配置する新機能である。
- これにより、サーバーサイドアプリが静的サイトのような速度を実現しつつ、CPU実行コストを削減できる。
stale-while-revalidateの完全サポートにより、キャッシュ更新中もユーザーを待たせない。- ゾーンではなくWorkerに紐づく設計により、エントリーポイント単位で柔軟なキャッシュ戦略をコードで記述できる。
ctx.propsをキャッシュキーに含めることで、マルチテナント環境でも安全なキャッシュが実現する。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AWS Certificate ManagerがACME対応、TLS証明書の自動更新を実現
AWS Certificate Manager が ACME プロトコルに対応
2026年6月30日、AWS Certificate Manager（ACM）が ACME（Automatic Certificate Management Environment）プロトコルに対応した。この機能追加により、AWS 上で稼働するアプリケーションの公開 TLS 証明書の取得・更新を、Certbot や cert-manager といった既存の ACME クライアントから自動化できるようになる。
証明書の有効期限は短縮の一途をたどっている。CA/Browser Forum の規定により、公開 TLS 証明書の最大有効期間は 2027 年 3 月に 100 日へ、さらに 2029 年までに 47 日へと段階的に引き下げられる見通しだ。手動での更新運用はもはや現実的ではなく、自動化が不可避の状況にある。
ACM の ACME 対応は、単なる証明書自動化の一手を超えて、組織全体の証明書ガバナンスを一元化する大きな転換点となる。PKI 管理者は DNS 管理権限をエンドポイントに集約しつつ、アプリケーション担当者には EAB（External Account Binding）認証情報だけを配布すればよく、DNS キーを組織内にばらまくリスクを排除できる。
短命化する証明書と自動化の必然性
従来の TLS 証明書は最大 1 年を超える有効期間が一般的だった。しかし、CA/Browser Forum は証明書のライフサイクル短縮を段階的に進めており、2027 年 3 月には最大 100 日、2029 年までには 47 日への短縮が義務付けられる。これは証明書の更新頻度が年 1 回から年 3〜4 回、最終的には年 7〜8 回に跳ね上がることを意味する。
手動による更新フローでは、この頻度に耐えられない。更新漏れによる証明書切れは顧客にエラー画面を表示させ、サービス自体の停止を招く。ACME プロトコルはこうした課題に対処するために策定されたオープン標準であり、Let’s Encrypt をはじめとする多数の認証局が採用している。
このデモで示すように、ACME プロトコルを利用すると証明書ライフサイクルから人手を排除できる。AWS が ACME エンドポイントをマネージドサービスとして提供することで、利用者は証明書発行インフラの運用負荷からも解放される。
Amazon Trust Services による証明書発行
ACM が ACME 経由で発行するのは、Amazon Trust Services（ATS）を認証局とする公開証明書だ。ATS のルート証明書は主要なブラウザおよび OS にデフォルトで信頼されているため、発行された証明書は即座に本番環境で利用できる。
証明書の鍵タイプは ECDSA P-256 がデフォルトだが、RSA 2048 や ECDSA P-384 も選択可能だ。クライアント側の要件に合わせて設定できる柔軟性を持ちつつ、デフォルトではより高速でセキュアな ECDSA が推奨されている。
ACME エンドポイントの設定とドメイン検証の仕組み
ACM の ACME 対応で最も特徴的なのは、ドメイン検証を PKI 管理者がエンドポイントレベルで一括実施する点だ。一般的な ACME 環境では、証明書を必要とするクライアントごとに DNS レコードの設定権限が必要になる。これに対して ACM の方式では、管理者がエンドポイント作成時にドメインを検証し、以後の証明書リクエストはそのエンドポイントが管理する。
エンドポイントの作成手順
ACM コンソールの「ACME 証明書」ページからエンドポイントを作成する。設定項目は以下の通りだ。
- エンドポイント名（任意の識別名）
- エンドポイントタイプ（Public を選択）
- 証明書タイプ（Public を選択）
- 鍵タイプ（ECDSA P-256 がデフォルト）
- ドメイン名（証明書を発行する対象ドメイン）
- ドメインスコープ（厳密なドメイン、サブドメイン、ワイルドカードの許可設定）
ドメインスコープの設定はガバナンス上とくに重要だ。Exact domain（完全一致ドメイン）だけを許可すれば、サブドメインやワイルドカード証明書の発行を防げる。たとえば本番系のエンドポイントでは Exact domain と Subdomains のみを有効化し、Wildcards は無効にすることで、証明書の発行範囲を厳格に制限できる。
エンドポイント作成後、DNS 検証が実行される。Route 53 を利用していれば CNAME レコードが自動で作成されるため、手動での DNS 設定は不要だ。外部の DNS プロバイダーを使っている場合は、表示される CNAME レコードを手動で登録する必要がある。
EAB 認証情報によるクライアント登録
エンドポイントの準備が整ったら、EAB（External Account Binding）認証情報を発行する。EAB は Key ID と HMAC Key のペアで構成され、ACME クライアントがエンドポイントにアカウントを登録する際の初回認証に使われる。
一度クライアントが登録されれば、以降の証明書リクエストはクライアント自身が生成した非対称鍵ペアで認証される。EAB 認証情報はあくまで登録時のみの使い切りであり、有効期限を設定して不要な長期保管を防ぐのが望ましい。
この仕組みにより、PKI 管理者はドメイン検証という強力な権限をエンドポイントに閉じ込めつつ、アプリケーション担当者には EAB 認証情報だけを安全に配布できる。DNS キーを組織全体に配る必要がなくなる点が、従来の ACME 運用と決定的に異なる。
Certbot を使った証明書リクエストの実例
ACM コンソールには、Certbot と acme.sh 向けの CLI リファレンスが用意されている。以下は AWS News Blog の記事で紹介されている Certbot のコマンド例を再構成したものだ。
certbot certonly --standalone --non-interactive --agree-tos \
--email <EMAIL> \
--server https://acm-acme-enroll.us-east-1.api.aws/<ENDPOINT_ID>/directory \
--eab-kid <EAB_KID> \
--eab-hmac-key <EAB_HMAC_KEY> \
--issuance-timeout <ISSUANCE_TIMEOUT> \
-d <DOMAIN>--eab-kid と --eab-hmac-key に、先ほど発行した EAB 認証情報を指定する。各 ACME クライアントで引数名や設定ファイルの記法は異なるため、利用するクライアントのドキュメントを参照する必要がある。
コマンドが成功すると、Amazon Trust Services によって署名された有効な証明書が発行される。openssl コマンドで証明書の内容を確認したうえで、アプリケーションにインストールすればよい。発行された証明書は ACM コンソールの「ACME 証明書」タブにも表示され、コンソールや API 経由で発行した証明書と統合管理される。
一元管理がもたらす運用面の利点
ACM による ACME 対応は、単に証明書の自動発行を可能にするだけではない。最大の価値は、組織全体の証明書ライフサイクルを可視化し、ガバナンスを一元化できる点にある。
IAM ロールによるきめ細かなアクセス制御
ACM の ACME エンドポイントは IAM ロールと統合されている。ACME アカウントに対して IAM ロールをバインドすることで、どのクライアントがどのドメインの証明書をリクエストできるかを細かく制御できる。これにより、開発チームごとに発行可能なドメイン範囲を限定するといった運用が実現する。
監査ログとメトリクスの統合
すべての証明書リクエストは AWS CloudTrail に記録される。誰がいつどのドメインの証明書を要求したかを完全に追跡できるため、監査要件を満たすうえで強力な武器となる。また Amazon CloudWatch と連携することで、証明書の発行数やエラー率といった運用メトリクスもリアルタイムに把握できる。
ACM が標準で備える有効期限通知機能も ACME 経由で発行された証明書に適用される。更新が迫った証明書のアラートを一元管理でき、従来のように証明書管理ダッシュボードと ACME クライアントの管理画面を行き来する必要はなくなる。
上記のスタックは、ACM 単体で証明書管理から監査、予防までをカバーできることを示している。従来は外部の認証局と ACM の間で証明書管理が分断されていたが、ACME 対応によってこの断絶が解消された。
利用可能リージョンと料金体系
ACM の ACME 対応は、発表時点で全商用 AWS リージョンで利用可能だ。AWS GovCloud（US）および中国リージョン、AWS European Sovereign Cloud パーティションについては、後日の対応が予定されている。
料金は証明書発行時に含まれるドメインごとに課金される方式で、完全修飾ドメイン名（FQDN）とワイルドカードで単価が異なる。ボリュームティアは AWS アカウント単位で月間の全証明書における総ドメイン出現数に基づいて計算される。具体的な価格は ACM の公式料金ページで確認できる。
この課金体系は、ACME 経由で発行される証明書も従来の ACM 証明書と同じ仕組みでカウントされるため、新たなコスト管理の複雑さは生じない。
この記事のポイント
- ACM が ACME プロトコルに対応し、Certbot や cert-manager など既存クライアントからの証明書自動発行が可能になった
- PKI 管理者はエンドポイントレベルでドメイン検証とスコープ制御を一括管理でき、DNS キーを組織内に配布する必要がなくなる
- CloudTrail・CloudWatch・有効期限通知により、証明書ライフサイクル全体を単一ダッシュボードで可視化・監査できる
- 証明書の有効期間短縮が進む中、手動運用からの脱却と自動化基盤の構築が急務となっている
- 全商用リージョンで即日利用可能。費用はドメイン数ベースで、従来の ACM 料金体系に準じる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金
広告型モデルの限界とAIエージェント向け従量課金
2026年7月1日、CloudflareはMonetization Gatewayを発表した。HTTPの402ステータスコードを拡張したオープンプロトコル「x402」を基盤に、ウェブ上のあらゆるリソースに対して従量課金を適用できる仕組みである。保護対象はウェブページ、データセット、API、MCPツールにおよび、代理店や大規模言語モデルが自律的に支払う時代を見据えている。
背景にはウェブビジネスモデルの構造変化がある。30年にわたり、コンテンツは広告や月額課金で収益化されてきた。しかしAIエージェントが人間に代わって情報を消費するようになると、バナー広告をクリックすることも、毎月のサブスクリプションを維持することもない。エージェントは必要なデータを一度取得すれば、数十回、数千回と繰り返しアクセスし始める。Cloudflareの発表資料によると、AIクローラーのリクエスト数は、そこからサイトへ誘導される訪問者1人あたり数百～数万回に達しているという。
従来のAPI従量課金は既存ユーザー向けに限定され、サブセント単位の少額決済には向かなかった。クレジットカードの手数料が取引額を上回るためだ。ここでCloudflareが着目したのが、ステーブルコインによる一瞬の決済である。Monetization Gatewayは、支払い検証と流量制御をエッジで完結させ、オリジンサーバーに過剰な負荷をかけずに課金を実現する。
CloudflareはすでにContent Independence DayでAIクローラーの制御機能を提供し、Pay Per Crawlでクローラーに課金する仕組みを導入していた。Monetization Gatewayはその延長線上にあり、クローラー以外の任意の呼び出し元に対して課金できる点が新しい。
エージェントが変える支払いの単位
AIエージェントが自律的に行動するようになれば、サービスの課金単位も座席数や月額から「リクエスト数」「トークン数」「成果物」へと移行する。Cloudflareが例示したのは、1回のウェブ検索あたり数セント、アップロードエンドポイントで0.001ドルの基本料金＋1MBあたり0.01ドル、サポートエスカレーション解決時に0.99ドルといった単位である。
これまで実現が難しかったサブセントの決済を、x402プロトコルとステーブルコインが可能にする。ステーブルコイン（Open USDやUSDC）は1秒未満で決済が完了し、手数料が無視できるほど小さい。従来の決済手段では、手数料が支払い額を上回る逆転現象が起きていたが、それが解消される。
Cloudflareが提供する課金インフラ
Cloudflareの強みは、すでに自社の課金システムや顧客向けアナリティクスで従量課金の会計基盤を構築してきたことにある。Monetization Gatewayでは、売り手と買い手の間に入り、支払い証跡をHTTPリクエストに埋め込む形で検証パスを統合する。メータリング、支払い交換、決済はすべてオリジンサーバーの外で完結し、サイト運営者は課金ルールと価格だけを定義すればよい。買い手のオンボーディングや請求システムの構築は不要だ。
x402プロトコルとは
x402はHTTPのステータスコード「402 Payment Required」を実際に活用するオープンプロトコルである。この規格はCloudflareがx402 Foundationのもとで25以上の業界リーダーと共同開発を進めている。従来の402は予約状態にあり、実際の決済フローには使われていなかった。
x402のやりとりは単純だ。クライアントが支払い必須のリソースをリクエストすると、サーバーは402 Payment Requiredとともに価格、受け入れ可能な通貨、支払い先を含む小さなペイロードを返す。クライアントは支払いを実行し、支払い証明を添えてリクエストを再送する。ファシリテーター（検証者）が証明を確認し、オリジンサーバーが最終的にリソースを返す。すべてが通常のHTTPリクエスト/レスポンスの中で完了し、決済ページへのリダイレクトも個別の決済API呼び出しも発生しない。
x402の利点は2つある。1つは最小単位がセント未満まで刻めること。プロトコルのオーバーヘッドが極めて低く、取引額が支払いコストを下回る逆転を防げる。もう1つは、買い手が売り手のアカウントを事前に取得する必要がないことだ。支払い自体が資格情報として機能するため、サインアップやAPIキー発行なしに取引が成立する。
サブセント決済と一瞬の決済
ステーブルコインを使う決済は、現在の主要な決済レールでは実現できなかったスピードと低コストを両立する。Cloudflareはサブセカンド（1秒未満）の決済を目標に掲げている。エージェントが数セントのデータを購入するために数ドルの手数料と数日の決済期間を待つ必要はなくなる。この速度と低コストが、AI時代の大量のマイクロペイメントを支える。
Monetization Gatewayの機能
Monetization GatewayはCloudflareのエッジネットワーク上で動作し、330以上の都市でリクエストを処理する。x402ハンドシェイクが買い手の近くで実行されるため、レイテンシが小さくなり、オリジンサーバーへの負荷も軽減される。
具体的な課金ルールの適用方法として、以下のような機能が計画されている。
- 特定のRESTメソッドへの課金。/api/premium/* へのGETやPOSTに0.01ドルを設定できる
- タスクの複雑さに応じた変動価格。画像生成などの処理負荷に応じて最大2ドルまでの課金が可能
- 認証されていない発信者への402 Payment Requiredの返却。オリジンが401を返した際に、自動で402と価格情報に置き換える
ルールはCloudflareのダッシュボードから設定するほか、Cloudflare APIやTerraformを通じてコードとして管理できる。課金エンドポイントの追加が、単なる別のインフラ設定として扱えるようになる設計だ。
Cloudflareはまた、Web Bot Authとの連携も予定している。エージェントに認証を求め、既存のアカウントに対して従量課金を適用する柔軟性を提供する方針だ。これにより、完全な匿名取引だけでなく、信頼関係に基づく課金も選択できるようになる。
売り手にとっての変化
Monetization Gatewayを利用する売り手は、蓄積したステーブルコインをそのまま別の取引に使うことも、銀行口座で法定通貨に換金することもできる。Cloudflareが発表した構想では、支払い検証はすべてエッジで完結し、オリジンには課金ルールと実際の収益だけが残る。
これはAPIプロバイダーにとって、販売可能市場を拡大する直接的な手段になる。AIエージェントはリソースを要求し、価格を提示され、支払い、結果を得る。サインアップもAPIキーも事前の関係も必要ない。Cloudflareは、いつでも買い手の認証や既存アカウントとの紐付けを追加できる柔軟性を残している。
この記事のポイント
- CloudflareがHTTP 402を利用した従量課金プロトコルx402を実用化。Monetization Gatewayによりあらゆるウェブリソースへの課金が可能に
- AIエージェントが大量にコンテンツを消費する時代、広告に依存しない収益モデルとしてマイクロペイメントが鍵を握る
- ステーブルコインによるサブセカンド決済で、サブセント単位の取引でも手数料が収益を上回らない
- 課金ルールはコードで管理でき、売り手は買い手のオンボーディングや請求システムを構築する必要がない
- Web Bot Authとの連携や変動価格設定など、エージェント経済向けの拡張機能が計画されている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AWS Graviton5搭載EC2 C9gインスタンスが一般提供開始
計算負荷の高いワークロードを扱う企業にとって、「もう少しだけ処理が速ければ」という場面は多い。AWSが6月30日に発表したEC2 C9g/C9gdインスタンスは、その不満を根本から解決する新世代の計算特化型インスタンスだ。Graviton5プロセッサの投入により、前世代からvCPUあたり最大25%の性能向上を実現した。今回の発表で特に注目すべきは、クラウド最速級となるDDR5-8800MT/sメモリの採用と、正式検証済みのハイパーバイザー分離エンジン「Nitro Isolation Engine」の搭載だ。本記事では、CPU負荷の高いバッチ処理や動画エンコーディングを中心に、新しいインスタンスがどのような場面で威力を発揮するのかを詳しく解説する。
C9g/C9gdインスタンスの位置づけを見極める
AWSのEC2には多様なインスタンスファミリーが存在する。頭文字の「C」はCompute Optimized（計算最適化）を意味し、他のメモリ最適化（Rシリーズ）やストレージ最適化（Iシリーズ）とは設計思想が異なる。計算最適化インスタンスは、vCPUあたりの演算性能を最大化することに特化している。リアルタイム分析、機械学習の推論、動画エンコーディングなど、1秒でも短く計算を終えたい処理に適している。
今回発表されたC9g/C9gdは、2024年秋に登場したGraviton4搭載C8gの後継にあたる。AWS GravitonシリーズはArmベースの独自プロセッサで、x86系のIntel XeonやAMD EPYCと比較して、コストパフォーマンスに優れる点が強みだ。C9gの「g」はGravitonを示し、末尾に「d」がつくC9gdはNVMe SSDによる高速なローカルストレージを内蔵する。
Graviton5プロセッサの進化点を知る
Graviton5の最大の改良点は、メモリ帯域幅の拡張とレイテンシの低減にある。C9gインスタンスはDDR5-8800MT/sのDIMMを採用し、これは現在クラウド上で提供されているプロセッサインスタンスの中で最速のメモリ速度だ。数字だけでは実感しにくいが、これはメモリとCPU間のデータ転送速度が秒間8800メガトランスファー（MT/s）ということを意味する。前世代のC8gがDDR5-5600MT/sだったため、実に57%もの速度向上にあたる。
さらに、CPUのL3キャッシュ容量が5倍に拡張された。キャッシュはCPUとメインメモリの間に位置する超高速なデータ置き場で、容量が大きいほどメモリアクセスの待ち時間を減らせる。AWS News Blogの著者Seb氏によると、これらの改善により、インメモリ分析のスループット向上や、より応答性の高いエージェント型AIループが期待できるという。
ネットワーク面でも強化が施されている。パケット処理性能はGraviton4ベースのインスタンスと比較して最大3倍に向上し、インスタンスサイズ全体の平均でネットワーク帯域が約15%、EBS帯域が約20%増加した。
C9g/C9gdの主要スペック詳細と設計思想
スペック表を見ると、C9g/C9gdは最小のmedium（1vCPU/2GBメモリ）から、最大のmetal-48xl（192vCPU/384GBメモリ）まで11サイズで展開される。48xlargeではネットワーク帯域が100Gbps、EBS帯域が72Gbpsに達し、これは前世代の2倍にあたる。大規模な分散処理やリアルタイム分析基盤において、ネットワークがボトルネックになる状況を回避しやすくなるだろう。
C9gdシリーズには、ローカルのNVMe SSDストレージが追加される。容量は最小のmediumで59GB、最大の48xlargeでは3台合計で11,400GB（3×3,800GB）に達する。NVMe SSDはEBSよりもレイテンシが低いため、以下のような用途に適している。
- HPCシミュレーションのスクラッチスペース（一時的な作業領域）
- 機械学習推論の一時キャッシュ
- アドサーバーのローカルバッファ
ストレージ性能も向上しており、ローカルストレージのパフォーマンスは前世代比で約30%向上した。NVMe経由の詳細なI/Oパフォーマンス統計はCloudWatchやnvme-cli経由で取得可能で、I/Oサイズ別のレイテンシヒストグラムが1秒単位で確認できる。この機能は追加料金なしで利用できる。
Instance Bandwidth Configurationの実用性を測る
C9g/C9gdには、Instance Bandwidth Configuration（IBC）と呼ばれる帯域調整機能が搭載されている。これは、EBSとVPCネットワークの帯域配分を最大25%の範囲で調整できる仕組みだ。例えば、データベースやキャッシュ用途でEBSの帯域を優先したい場合、ネットワーク側を絞ってEBS側に割り当てを寄せることが可能になる。逆に、ネットワーク集約型の分散処理ではVPC側を優先すればよい。固定的な割り当てに縛られない柔軟性は、実運用のチューニングで大きな武器になる。
C9gとC9gdの使い分けフローを整理する
C9gとC9gdはスペックが似ているため、どちらを選ぶべきか迷う場面があるだろう。選択の決め手は「ローカルのNVMe SSDが必要かどうか」に尽きる。AWS News Blogでは、C9gを「バッチジョブ、動画エンコードパイプライン、分散分析」向け、C9gdを「HPCシミュレーションのスクラッチスペース、ML推論の一時キャッシュ、アドサーバーのローカルバッファ」向けとしている。EBSで十分な永続ストレージが足りるならC9g、一時的でも高速なローカルストレージが不可欠ならC9gdを選べばよい。
Graviton5がもたらすエージェント型AIへの適性を読み解く
AWS News Blogの発表では、C9gのワークロード例として「エージェント型AI（agentic AI）」が明記されている。エージェント型AIとは、単なる質問応答を超えて、コードを実行し、複数ステップのタスクを自律的に組み立てて完了させるAIシステムを指す。OpenAIのOperatorやAnthropicのComputer Useが代表例だ。
この種のワークロードでは、大規模言語モデル（LLM）の推論そのものに加えて、Pythonコードの実行、API呼び出し、結果の検証といったCPUバウンドな処理が連続的に発生する。Graviton5のコア数向上と大容量キャッシュは、こうした「思考と行動のループ」を高速化する土台となる。AWSの著者Seb氏によれば、アプリケーションがデータを待つ時間を削減し、結果的にエージェントループの応答性が高まるとのことだ。
AI推論といえばGPUの印象が強いが、実際には前処理、後処理、オーケストレーションの多くがCPU上で動く。ArmベースのGraviton5は、これらの処理を低コストでさばける点が実務的な魅力となる。
Nitro Isolation Engineのセキュリティ強化を理解する
C9g/C9gdは、計算最適化インスタンスとして初めて「Nitro Isolation Engine」を搭載した。これはAWS Nitro Systemの拡張機能で、仮想マシン間のメモリ空間、CPUレジスタ状態、I/Oデバイスへのアクセスを数学的正確さで強制的に分離する仕組みだ。
通常、ハイパーバイザーによる分離はソフトウェアの実装品質に依存する部分があるが、Nitro Isolation Engineは形式検証（formal verification）と呼ばれる数学的手法を用いて分離の正しさを証明している。形式検証とは、仕様を数理論理で記述し、実装がその仕様を厳密に満たすことを機械的に検証する手法だ。テストのように「見つかったバグがない」ではなく、「特定の前提条件下でバグが存在し得ない」ことを保証する。
AWSは2025年にこの技術を発表した際、ハイパーバイザーの分離を形式検証する取り組みについてホワイトペーパーを公開している。今回のC9g/C9gdで初めて、計算最適化インスタンスに実装されたことになる。
セキュリティ要件の厳しい金融サービスや医療データの分析をEC2上で行うケースでは、この正式検証済みの分離機構はインフラ選定の重要な判断材料になる。ソフトウェアレベルではなく、ハードウェア支援と形式検証の組み合わせで隔離を実現している点は、AWSの設計思想として特筆に値する。
利用可能リージョンと料金モデルを確認する
2026年6月30日時点で、C9g/C9gdは米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）の4リージョンで利用可能だ。AWSは追加リージョンへの展開も予定している。
料金モデルはSavings Plans、オンデマンド、スポットインスタンス、Dedicated Instances、Dedicated Hostsに対応する。常時稼働させるワークロードではSavings Plans、短期的なバッチ処理ではスポットインスタンスと使い分けられる。EBSボリュームは仮想インスタンス1台あたり最大128個までアタッチ可能で、大規模データの処理でもストレージ不足に悩むことは少ない。
インスタンスの起動はAWSマネジメントコンソール、AWS CLI、AWS SDKのいずれからでも可能だ。GravitonはArmアーキテクチャのため、AMIやコンテナイメージはArm向けにビルドされたものを選ぶ必要がある。公式のAmazon Linux 2023やUbuntuのArm版AMIはすでに提供されているため、新規導入時の障壁は低い。
この記事のポイント
- C9g/C9gdはGraviton5搭載の計算最適化インスタンス、vCPUあたり25%の性能向上を達成
- DDR5-8800MT/sメモリと5倍のL3キャッシュにより、メモリ待ち時間を大幅に削減
- 48xlargeでは100Gbpsネットワーク帯域と72GbpsのEBS帯域、前世代比2倍に拡張
- Nitro Isolation Engine搭載、形式検証による仮想マシン分離を実現
- エージェント型AIやHPC、動画エンコードなどCPU負荷の高い処理に最適
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験