タグアーカイブ Cloudflare

Cloudflare DDoS脅威レポート2026年上半期、1Tbps攻撃が935件に急増

Cloudflare DDoS脅威レポート2026年上半期、1Tbps攻撃が935件に急増

Cloudflareが2026年8月11日、DDoS脅威レポートの2026年上半期版を公開した。今回で通算25回目の発行となる。四半期ごとの発表を統合し、1月から6月までを単一のレポートにまとめた形式だ。

レポートによれば、Cloudflareは上半期で2,320万件のネットワーク層DDoS攻撃と29兆6,400億件のHTTP DDoSリクエストを軽減した。1時間あたり約5,343件、1日あたり約12万8,000件の攻撃に相当する。

なかでも1Tbps(テラビット毎秒)を超える超大規模攻撃の急増が目を引く。攻撃ベクトルはボットネット直撃型から反射・増幅型へ移行しつつあり、防御側の自動化がこれまで以上に重要になっている。

2026年上半期のDDoS攻撃概況

2026年上半期のDDoS攻撃概況

4月にピーク、国際摘発作戦で減少へ

4月は攻撃のピーク月だった。攻撃リクエストは6兆4,600億件、通信量は165PB(ペタバイト)に達した。この量は大手動画プラットフォームが1日で処理するデータ量に匹敵する規模だ。

その後、攻撃件数と通信量は減少に転じた。同時期に実施された国際法執行作戦「Operation PowerOFF」が影響したとみられる。21カ国が参加し、DDoS攻撃代行サービスの利用者7万5,000人超を標的に、53のドメインを停止、25件の家宅捜索、4人の逮捕という成果を上げた。

法執行の直接的な抑止効果は計測しにくい。ただし摘発の直後に攻撃数が減少した事実は、DDoS攻撃代行サービス(いわゆるブートストレスサービス)の利用層がインターネット全体の攻撃量に与える影響の大きさを示している。個人が安価に攻撃を「注文」できる構造が、この規模の攻撃増加を支えている構図だ。

1Tbps超の攻撃が6倍以上に急増

1Tbps超の超大規模攻撃は第2四半期だけで805件に達した。前期比で6倍以上の増加だ。上半期全体では935件の1Tbps超ネットワーク層攻撃を軽減している。

DDoS対策の世界では「ハイパーボリュメトリック攻撃」という分類がある。1Tbps以上、または毎秒10億パケット(Bpps)以上、または毎秒100万リクエスト(Mrps)以上のいずれかを満たす攻撃だ。2026年はこの分類に入る攻撃が順調に増えている。

ただし攻撃の中央値は小規模だ。ネットワーク層攻撃の96.62%が500Mbps未満、90.60%が10分未満で終了している。「小規模」といっても相対的な話だ。100Mbpsの攻撃だけで一般的なサーバーやWebサイトは十分にダウンし得る。100Gbpsなら無保護のデータセンターを停止させる威力がある。

攻撃者は帯域とパケットレートの組み合わせも工夫する。高パケットレート(Mpps単位)と低帯域幅(Gbps単位)を組み合わせ、ネットワーク機器の処理限界と回線容量の限界という異なる弱点を同時に狙う手口が観測されている。

攻撃ベクトルの変化とCLDAP急増

攻撃ベクトルの変化とCLDAP急増

DNS系攻撃がネットワーク層の3分の1を占める

攻撃の中心はボットネット直撃型から反射・増幅型へ移っている。DNS系攻撃が上半期のネットワーク層攻撃全体の34.3%を占めた。第2四半期にはDNSフラッドの割合が25.7%から40.0%へ急拡大している。

DNSフラッドは、ボットネットが被害者の権威DNSサーバーへ大量のクエリを直接送りつける攻撃だ。このドメインの「電話帳」に当たるDNSサーバーが応答不能になると、そのドメインに依存するサービスはすべて機能を失う。

DNSアンプリフィケーションは別の仕組みだ。攻撃者は送信元IPを偽装した小さなクエリを公開DNSリゾルバへ送る。リゾルバは元のクエリよりはるかに大きな応答を、偽装されたIP(つまり被害者)へ返す。少ない帯域で大きな攻撃を生み出せるため、攻撃者にとって効率がよい。

DNS Flood
ボットネットからの大量DNSクエリを権威DNSサーバーへ直接送りつける。
ねらいはDNSサーバーの処理能力を枯渇させること。
DNS Amplification
送信元IPを偽装した小さなクエリを公開DNSリゾルバへ送る。
リゾルバからの大きな応答が被害者へ反射する。
CLDAP Flood
UDPポート389で公開されたActive Directoryへ偽装クエリを送る。
数十倍から数百倍の応答で被害者を圧倒する反射型攻撃。
ボットネット直撃型  反射・増幅型(DNS)  反射・増幅型(LDAP)

上の図は3つの攻撃ベクトルの違いを整理したものだ。直撃型は攻撃者自身の帯域がそのまま攻撃力になる。反射・増幅型は第三者のサーバーを踏み台にするため、攻撃者側の帯域が少なくても大きな打撃を与えられる。

CLDAPフラッドが580%増

CLDAPフラッドの伸びは顕著だ。前期比580%増となり、第2四半期だけで第3位の攻撃ベクトルに浮上した。

CLDAP(Connectionless Lightweight Directory Access Protocol)はLDAPのUDP版だ。UDPはTCPと違いハンドシェイクが不要で、送信元IPの偽装が容易になる。攻撃者はUDPポート389で公開されたドメインコントローラーへ偽装クエリを送り、元の数十倍から数百倍の応答を被害者へ反射させる。

CLDAPの急増が示すのは、公開されたUDPサービスの危険性だ。ポート389が外部に開いている組織は、自覚のないまま攻撃者の踏み台にされている可能性がある。インフラ管理者にとっての実務的な教訓は「UDPポートの露出を監査し、不要なら閉じる」という基本対策の重要性が再確認されたことにある。

標的産業と地域の動向

メディア産業が最大の標的に

メディア・制作・出版産業が両四半期で最も攻撃された産業になった。全HTTP DDoSリクエストの14.2%を占め、2位の約4倍に相当する。イランとウクライナの戦況報道、そしてワールドカップ関連の報道が攻撃対象になったとみられる。

報道機関へのDDoS攻撃は、単なる金銭目的や愉快犯ではなく、情報の流れを止める意図を持つことが多い。特定の報道を続けるメディアのサイトを落とすことで、世論に影響を与えようとする動機が背景にある。

2026年上半期の主要ランキング
産業別 1位 メディア・制作・出版(全体の14.2%)
急上昇 政府部門が第29位から第9位へ
国別最多 中国が全体の22.4%で最多
攻撃元 1位 ブラジルが14.9%で米国を逆転
産業  セクター  標的国  攻撃元国

この図が示すように、標的と攻撃元の分布は対称ではない。標的は中国・米国など経済規模の大きい国に集中し、攻撃元はブラジル・インドネシアなどボットネット感染端末が多いとされる国に偏る。

政府部門が29位から9位へ急浮上

政府部門の動きは今年最大のトピックだ。2026年2月28日にイスラエルと米国が「Operation Epic Fury」を開始。その72時間以内に、16カ国110組織に対する149件のハクティビストDDoS攻撃が記録された。標的組織の47.8%が政府部門だった。

この結果、政府部門のシェアは第1四半期の29位から第2四半期には9位へ急上昇した。単一セクターの移動幅としては2026年最大だ。地政学的な緊張がDDoS攻撃の規模と方向性に直接影響を与える構図が、データとして明確に現れた。

国別では中国が最多の標的になった。第2四半期に全世界のHTTP DDoSリクエストの22.4%を吸収した。米国は18.8%で2位を維持している。トルコは攻撃シェアが倍増し、第3位に浮上した。6月から7月にかけてのアンカラNATOサミット準備期間中、治安当局が209人以上を逮捕する大規模な事前摘発を行った時期と重なる。

攻撃元の国ではブラジルが米国を逆転して1位になった。上半期のシェアはブラジル14.9%に対して米国13.4%だ。ブラジルは第2四半期に21.4%まで急伸した。インドネシアは両四半期とも3位を維持し、複数四半期連続で上位3カ国に入る常連になっている。

短時間攻撃と自動防御の重要性

短時間攻撃と自動防御の重要性

90%以上が10分未満で終了

DDoS攻撃の大半は驚くほど短い。上位の超大規模攻撃ですら秒単位で終了する。過去には開始から終了までわずか35秒という記録的な攻撃も観測されている。

攻撃が30秒でも10分でも、人間が介入する実質的な時間窓は存在しない。セキュリティ担当者にアラートが届いた時点で、攻撃はすでに完了しているからだ。手動での軽減策やオンデマンド型の防御はこの現実に対して遅すぎる。

攻撃の短さと人の対応速度のギャップ
DDoS攻撃の持続時間
90.60%が10分未満で終了。最短35秒の観測事例もある。
人の対応速度
アラート通知、状況分析、手動対策まで数分以上かかる。
結論
人間が介在する余地はない。常時稼働する自動防御だけが実効的な対策になる。

この図のとおり、攻撃の持続時間と人手による対応時間は圧倒的に乖離している。従来型の「監視して手動で対応する」運用モデルは、DDoS対策においては成立しない。

自動防御が唯一の実効策

さらに、短い攻撃の余波は長引く。ルーティングの不安定化、TCP再送、アプリケーションのタイムアウト、下流サービスの劣化などが数時間から数日続くことがある。サービス停止や品質低下は攻撃の終了後も継続するのだ。

この環境では、常時稼働する自動防御が「あったほうがよい」ものではなく必須の要件になる。Cloudflareは330以上の都市に分散したネットワーク全体で、人間の介入なしに攻撃を検知・軽減する仕組みを運用している。ネットワーク容量は500Tbps規模だ。

同社はさらに、DDoS攻撃を仕掛けるIPアドレスやアカウントを特定する無料のフィードをホスティング事業者やISP向けに提供している。世界800以上のネットワークが登録しており、ボットネットノードの撤去に一定の成果を上げている。

日本の事業者にとっての示唆は明確だ。自社サイトが直接の標的でなくても、反射型攻撃の踏み台にされたり、同じホスティング上の他サイトへの攻撃に巻き込まれたりするリスクは常にある。小規模サイトでも「攻撃を受けたら止まる」前提ではなく、自動防御を標準装備する発想が必要になる。

この記事のポイント

  • 1Tbps超のネットワーク層DDoS攻撃が上半期で935件に達した
  • DNS系攻撃がネットワーク層全体の34.3%を占め、反射・増幅型への移行が進む
  • CLDAPフラッドが前期比580%増で第3位の攻撃ベクトルに浮上
  • メディア・制作・出版が最も攻撃され、政府部門は29位から9位へ急上昇
  • 攻撃の90.60%が10分未満で終了し、自動防御が実質唯一の対策になる
admin-ajax.phpへのボット大量アクセスでCPUが100%になる時の遮断と対策

admin-ajax.phpへのボット大量アクセスでCPUが100%になる時の遮断と対策

admin-ajax.php へのボットの大量リクエストでサーバーの CPU 使用率が 100% に張り付く場合は、一括遮断ではなく攻撃対象の AJAX アクションをログから特定し、不要な処理を止めた上で正規アクセスを通すレート制限を導入するのが現実的な対策だ。

なぜボットは admin-ajax.php を集中的に叩くのか

admin-ajax.php は WordPress が全 AJAX リクエストを受け付ける入口にあたるファイルだ。フォーム送信、商品カートの更新、ハートビート API による自動保存など、フロントエンドと管理画面の両方で使われている。

ボットがここを狙う理由は、ログイン不要でアクセスできる公開エンドポイントでありながら、リクエストごとに WordPress 全体を読み込んで PHP を実行するため、少ないリクエスト数でもサーバー負荷を大きくできる点にある。

URL に action パラメータを付けて呼び出す構造になっており、たとえば問い合わせフォームの送信処理、EC サイトのカート更新、管理画面の自動保存など、あらゆる AJAX 処理がここを通る。ボットはこれを悪用し、処理の重い action を何度も叩いてサーバーを圧迫する。

攻撃対象の AJAX アクションをログから特定する

攻撃対象の AJAX アクションをログから特定する

対策の最初の一歩は、どの action が攻撃されているのかをアクセスログで確認することだ。闇雲に遮断ルールを増やしても、正規のフォームを巻き込むだけで根本解決にはならない。

アクセスログで action パラメータを調べる

Apache なら /var/log/apache2/access.log、nginx なら /var/log/nginx/access.log にリクエスト履歴が残っている。admin-ajax.php を含む行を抽出し、action= の後ろに続く値を集計すると、攻撃対象が見えてくる。

サーバー管理画面からログをダウンロードできる場合も多い。Cloudflare を利用しているなら、分析画面のセキュリティイベントから admin-ajax.php 宛てのリクエストを絞り込み、クエリ文字列を確認する手もある。

STEP 1 アクセスログで admin-ajax.php へのリクエストを抽出する
STEP 2 action パラメータの値を集計して攻撃対象を特定する
STEP 3 不要なアクションを WordPress 側で無効化する
STEP 4 正規アクセスを通すレート制限を導入する

攻撃対象を特定せずに全リクエストを遮断すると、問い合わせフォームが動かなくなる原因になる。必ずログ調査から始めるのが安全だ。

代表的な攻撃対象を把握しておく

攻撃対象になりやすいのは、外部から呼び出せる未ログインユーザー向けの AJAX アクションだ。問い合わせフォームの送信処理、ハートビート API の更新処理、EC サイトのカート更新などが代表例になる。自分のサイトに不要なプラグインが残した action がしばしば悪用される。

正規のフォームを壊さずにレート制限する

正規のフォームを壊さずにレート制限する

すべての admin-ajax.php リクエストにチャレンジ(CAPTCHA や JS チャレンジ)を適用すると、ブラウザ内の JavaScript が裏で送る AJAX リクエストまで巻き込まれ、フォームが正常に動作しなくなる。これが一括チャレンジ方式が失敗する理由だ。

有効なのは、攻撃対象の action だけを条件にしたレート制限だ。単位時間あたりのリクエスト数を IP アドレスごとに制限し、上限を超えたら一時的にブロックする。正規ユーザーのフォーム送信は頻度が低いため、まず引っかからない。

Before 全リクエストにチャレンジを適用
ブラウザ内の AJAX リクエストがチャレンジに引っかかり、問い合わせフォームが送信できなくなる
正規ユーザーまでブロックしてしまう
After 攻撃対象の action だけをレート制限
頻度の低い正規のフォーム送信は通過し、ボットだけが制限を超えてブロックされる
正規ユーザーへの影響を最小限に抑える
一括遮断の失敗例  レート制限による解決

レート制限の閾値は、通常のフォーム送信頻度を大きく上回る値に設定する。たとえば同一 IP から 1 分間に 30 回を超える admin-ajax.php へのリクエストを制限する場合、正規ユーザーが 30 回もフォームを送ることはない。

WordPress側で不要な AJAX アクションを無効化する

WordPress側で不要な AJAX アクションを無効化する

攻撃対象のアクションが自分のサイトで使われていないなら、WordPress のフックを使ってそのアクション自体を止めてしまうのが最も確実だ。リクエストが届いても処理が実行されず、サーバー負荷は大きく下がる。

未ログインユーザー向けのアクションを止める

wp_ajax_nopriv_ から始まるフックは未ログインの訪問者からの AJAX 処理を担当する。使っていない action を特定したら、テーマの functions.php に下のコードを追加して 403 を返すようにする。

add_action('admin_init', function() {
    if (defined('DOING_AJAX') && DOING_AJAX) {
        $action = isset($_REQUEST['action']) ? $_REQUEST['action'] : '';
        if (in_array($action, array('unused_action_1', 'unused_action_2'), true)) {
            wp_die('403 Forbidden', 'Forbidden', array('response' => 403));
        }
    }
}, 1);

action 名はログで特定した値に置き換える。これで、その action へのリクエストは WordPress の初期化直後に拒否され、プラグインのコードが呼ばれる前に処理が終わる。

ハートビート API の負荷を下げる

管理画面や投稿編集画面で自動保存・ロック通知のために heartbeat が一定間隔で動く。編集画面を開きっぱなしにするボットがいると負荷がかさむ。管理画面を普段使わないサイトなら、heartbeat の頻度を下げるか停止する手もある。

add_filter('heartbeat_settings', function($settings) {
    $settings['interval'] = 300;
    return $settings;
});

interval の単位は秒だ。300 にすると編集画面の自動保存間隔が 5 分になり、サーバーへの負荷が大きく減る。完全に止めるのは編集画面のロック機能に影響するため、まず間隔を延ばすところから始めるとよい。

サーバー設定でボットを直接遮断する

サーバー設定でボットを直接遮断する

Cloudflare やサーバーレベルの設定でも、条件付きの遮断やレート制限を入れられる。正規のフォームを止めずにボットだけを弾くには、リファラー情報やリクエスト頻度を条件に使うのがポイントだ。

リファラーを条件に弾く

正規の AJAX リクエストは、自分のサイトのページから送られるため Referer ヘッダーに自ドメインが入る。一方、ボットは Referer なしや偽装した値で送ることが多い。Apache なら .htaccess で Referer を条件に遮断できる。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} /wp-admin/admin-ajax.php
RewriteCond %{HTTP_REFERER} !^https?://example.com/ [NC]
RewriteRule ^ - [F,L]
</IfModule>

これは自ドメイン以外からの Referer を持つ admin-ajax.php リクエストを 403 で拒否する設定だ。example.com の部分は自分のドメインに置き換える。ただし一部のブラウザ設定で Referer が送られないケースもあるため、完全な遮断には向かない。あくまで補助的な対策として使う。

nginx でレート制限する

nginx を使っているなら limit_req ディレクティブで admin-ajax.php 専用のレート制限を定義できる。サーバーブロックに以下の設定を追加する。

limit_req_zone $binary_remote_addr zone=ajax:10m rate=1r/s;

location = /wp-admin/admin-ajax.php {
    limit_req zone=ajax burst=20 nodelay;
    limit_req_status 429;
    fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    include fastcgi_params;
}

この設定では、同一 IP から 1 秒あたり 1 リクエストを超えると、バースト(突発的な超過)が 20 回まで許容される。超過分は 429(Too Many Requests)で拒否される。正規ユーザーのフォーム送信はこの制限内に収まるが、ボットの連打はすぐに上限を超える。

よくある質問

すべての admin-ajax.php リクエストを遮断してもよいか

やめておいたほうがよい。問い合わせフォーム、カート更新、検索機能など、多くのサイトで admin-ajax.php が使われている。全遮断すると重要な機能が動作しなくなる。

Cloudflare の Bot Fight Mode だけでは不十分なのか

Bot Fight Mode は既知のボットを自動判定して弾く基本的な防御で、未知のボットや単純なスクリプトには効果が薄い。特定のエンドポイントを狙う攻撃には、レート制限やアクション単位の対策を組み合わせる必要がある。

アクセスログの場所がわからない場合はどうするか

レンタルサーバーの管理画面にアクセスログの閲覧機能があることが多い。わからなければサーバー会社のサポートに問い合わせるか、Cloudflare の分析画面でリクエスト履歴を確認するとよい。

ボット対策プラグインだけでも解決できるか

Wordfence や Limit Login Attempts Reloaded のようなセキュリティプラグインは総合的な保護を提供するが、admin-ajax.php への大量アクセスには専用のレート制限やサーバー設定のほうが効果的な場合が多い。プラグインとサーバー設定の併用が望ましい。

この記事のポイント

  • admin-ajax.php は公開エンドポイントで、ボットが少ないリクエスト数でも負荷をかける
  • まずアクセスログで action パラメータを集計し、攻撃対象を特定する
  • 一括チャレンジは正規フォームを壊すため、action 単位のレート制限を使う
  • 使っていない AJAX アクションは functions.php から 403 で拒否する
  • サーバー設定(.htaccess や nginx)でも Referer 条件や limit_req で守れる
Cloudflare AI Searchがエージェント検索を簡素化、公開エンドポイントと価格プレビュー発表

Cloudflare AI Searchがエージェント検索を簡素化、公開エンドポイントと価格プレビュー発表

Cloudflareは2026年8月6日、AI Searchに大規模な機能拡張を発表した。従来はWorkers AIやVectorize、R2、Browser Runといった複数のプリミティブを組み合わせて独自の検索パイプラインを構築する必要があった。今回のアップデートによりAI Searchがこれらの処理を自動化し、開発者やエージェントが、まるで自前の検索エンジンを持っているかのような感覚で扱えるようになった。

新機能として、複数のWebサイトやファイルを横断して検索できる公開エンドポイントの提供、サイトマップ不要のクロール機能、カスタムドメインによるブランディング、EmDash CMS向けの検索プラグインなどが追加された。さらにプレビュー価格モデルも発表され、デフォルトの埋め込み・リランキングモデルを利用すれば、これらの処理が無料になる予測可能な料金体系が示されている。エージェントが信頼できる情報源から回答を引き出せるインフラが、これまでより格段に手軽になった。

AI Searchの主な機能強化点

AI Searchの主な機能強化点
従来の構成(Before)
開発者 手動組み合わせ Workers AI Vectorize R2 Browser Run
それぞれの設定を個別に管理し、データパイプラインを自前で構築する必要があった
AI Searchで統合(After)
開発者 データソース指定 AI Search が自動処理
クローリング 埋め込み リランキング 検索API
1コマンドでセットアップし、即座に検索エンドポイントが利用可能

AI Searchを導入する前は、ベクトル化したデータの格納先やクローリングの仕組み、リランキングのパイプラインなどを開発者が自前で組み上げる必要があった。しかし今回の強化により、それらの低レベルなサービスを意識せずに済む。結果としてエージェントが信頼できる最新情報を引き出せるインフラが、数分で立ち上がるようになった。

インデックス作成の簡素化

これまでAI SearchでWebサイトをインデックスに追加する際は、サイトマップが必須だった。しかし新たに追加された「Discover」パースオプションを使えば、サイトマップがなくてもページ内のリンクを辿って自動的にコンテンツを収集できる。Cloudflareアカウントに登録されたゾーンであれば、特定のページから始まる全サイトデータを取り込めるようになった。

さらに、HTMLやPDFなどの非構造化データから構造化データまで、幅広いファイル形式に対応した取り込みが可能になった。これにより社内Wikiや製品マニュアルといった多様なデータソースをエージェントの検索対象に加えやすくなっている。

公開検索/MCPエンドポイント

ネームスペースに対して公開URLを有効化すると、/search/mcp のエンドポイントが即座に利用できるようになる。/search は通常のREST APIとして、/mcp はモデルコンテキストプロトコル(MCP)に対応した形で提供される。どちらも認証不要で、複数のインスタンスにまたがる横断検索を1つのリクエストで実行できる。

外部のエージェントやアプリケーションに検索機能を提供したい場合、このエンドポイントをそのまま公開するだけで済む。Cloudflare以外の顧客に自社データへアクセスしてもらうシナリオでも、認証が不要で、URLを渡すだけのシンプルな共有が可能になっている。

EmDashとの統合とbotポリシー

Cloudflareが公開しているOSSのCMS「EmDash」向けに、AI Searchプラグインが提供された。これを導入すると、EmDashで構築したサイト内にセマンティック検索を組み込める。実際にCloudflare BlogやDeveloper Docsもこの仕組みで動いている。

また、AI Searchのクローラは独自のユーザーエージェント「Cloudflare-AI-Search」を使い、各サイトのrobots.txtに従う。ブラウザベースのクローリング機能を使う場合でも、このポリシーは変わらない。サイト運営者がクロールを拒否すれば収集が停止されるため、著作権や利用規約上の配慮が十分になされている。

Cloudflare Dev Stack MCPの実装事例

Cloudflare Dev Stack MCPの実装事例

Cloudflare自身がAI Searchをどう活用しているかを示す好例が、新しく公開された「Cloudflare Dev Stack MCP」だ。これはCloudflareのエコシステム全体(ドキュメント、ブログ、APIリファレンス、コミュニティなど)を横断検索し、コーディングエージェントへ最新の引用付き回答を返す仕組みである。古いトレーニングデータではなく、常にフレッシュな情報を基にコードを生成できる。

インスタンス作成とクロール

CloudflareはDocs、Blog、API Docs、コミュニティ、Astro、Viteなど計10以上のサイトに対して、それぞれ個別のAI Searchインスタンスを作成した。各インスタンスはドメインが異なるが、Cloudflareが所有するサイトデータであるため、統一的な方法でクロールできる。

npx wrangler ai-search instance create cloudflare-community \
  --namespace dev-stack \
  --source https://community.cloudflare.com \
  --type web-crawler \
  --parse-type discover

上記のコマンドでは、--parse-type discover を指定することでサイトマップなしにページを発見するクロールを実行している。この内部ではBrowser Runの/crawl機能が使用され、リンクを辿って再帰的にページを見つけ出す。

Workerを使ったマルチインスタンス統合

10個のインスタンスにまたがる横断検索を実現するため、CloudflareはWorkerを用いたMCPサーバを構築した。wrangler.jsonにAI Searchネームスペースのバインディングを追加し、1つのツール呼び出しで全インスタンスを同時に検索する。

{
  "ai_search_namespaces": [
    { "binding": "AI_SEARCH", "namespace": "cloudflare-stack" }
  ]
}
context.registerTool(
  'search_dev_stack',
  {
    description: 'Search current docs across the Cloudflare stack.',
    inputSchema: z.object({ query: z.string() }),
  },
  async ({ query }) => {
    const res = await context.env.AI_SEARCH.search({
      query,
      ai_search_options: {
        instance_ids: ['developers-cloudflare-com', 'astro', /* ... */],
        retrieval: { max_num_results: 10 },
        reranking: { enabled: true },
      },
    })
    return { content: [{ type: 'text', text: format(res.chunks) }] }
  }
)

この方式により、エージェントが単一のツール呼び出しで全ドキュメントを検索でき、結果にはどのインスタンスから取得されたかのメタデータが付与される。複数の検索先を順に叩く必要がなく、応答速度も一括で処理される。

コード不要の公開エンドポイントも選択可能

Workerを書かずに済ませたい場合、ネームスペースの公開URLを有効化するだけで、すべてのインスタンスにクエリを投げる/searchおよび/mcpエンドポイントが得られる。設定画面からワンクリックで有効化でき、即座に利用を開始できる。Cloudflare自身のMCPサーバもこの公開エンドポイントを活用している。

Workerを使う場合(カスタム制御)
開発者 Worker実装 MCPサーバ 経由で検索
既存アプリやエージェントに検索を組み込む場合に適する
公開エンドポイント(ノーコード)
管理者 ワンクリック有効化 /search /mcp エンドポイント公開
すぐにURLを共有でき、ブラウザやエージェントから直接呼び出せる

コードを書く場合は細かいチューニングやMCPツールとしての統合が可能で、コードを書かない場合は設定画面上の操作だけで外部共有が完了する。どちらの選択肢も提供されている点が、利用者のスキルや要件に応じた柔軟な導入を後押しする。

公開エンドポイントとカスタムドメインで検索を共有

公開エンドポイントとカスタムドメインで検索を共有

AI Searchでは、公開エンドポイントに独自のカスタムドメインを割り当てられる。デフォルトのCloudflare管理URLではなく、search.example.com/mcpといったブランド化されたエンドポイントを用意できるため、サービス提供時の信頼感が高まる。

さらに、検索を限定公開したいケースではCloudflare Accessを介した認証ゲートを追加できる。これによりエンドポイントへのアクセスを許可された人物やエージェントだけに制限し、認証情報を持たない第三者からの不正なクエリを防げる。社内データや顧客限定の検索サービスを安全に運用できる設計になっている。

デフォルト公開URL(無設定)
https://xxx.ai-search.cloudflare.com/search 認証なし
短時間の試験や内部検証には十分だが、ブランド観点では不十分
カスタムドメイン + Access制御(推奨)
search.example.com/mcp Cloudflare Access でログイン必須
ブランド力とセキュリティを両立し、顧客向け公開に最適

このカスタムドメイン機能は、SaaSプロダクトやエージェントサービスを展開する事業者にとってとくに有用だ。自社ブランドのURLで検索APIを提供することで、サービス全体の統一感が生まれ、導入先からの信頼獲得につながる。

プレビュー価格モデルでコストを予測可能に

プレビュー価格モデルでコストを予測可能に

AI Searchは現在ベータ版として無料提供されているが、正式版に向けたプレビュー価格が公開された。課金開始前には十分な通知が行われる予定だ。料金設計の中心にある考え方は「予測可能でスケーラブル」であり、埋め込みとリランキングをデフォルトモデル利用時に無料化することで、トークン数の見積もりに頭を悩ませる必要をなくしている。

料金の主な内訳

  • インジェスト(テキスト): $0.75 / 1Mトークン。月間無料枠5Mトークン。
  • 画像処理アドオン: +$0.50 / 1Mトークン。画像の埋め込みに使用される。
  • ストレージ: $2.00 / GB・月。月間無料枠10GB。
  • セマンティック検索(ハイブリッド+ベクトル): $0.75 / 1,000クエリ。無料枠2,000クエリ。
  • 全文検索: $0.10 / 1,000クエリ。同上の無料枠と共有。
  • 埋め込みとリランキング: 指定モデル利用時は無料。それ以外はWorkers AIの従量課金。

無料枠はインジェスト5Mトークンと検索2,000クエリがそれぞれ一つのプールとしてまとめられており、用途を気にせず使い切れる。埋め込みやリランキングのコストが気にならないため、データ更新や再インデックスの頻度を高めやすい。これは頻繁に情報が変わるナレッジベースをエージェントに与えたい開発者にとって大きなメリットだ。

2万ドキュメント規模の試算例

以下は、2万件の文書(約2,000万トークン)と1,000枚の画像をインジェストし、月間3万回のセマンティッククエリを実行した場合の想定コストである。ワーカーズ有料プランが前提で、埋め込みとリランキングにはデフォルトモデルを使用する。

  • インジェスト(テキスト): 18.1Mトークン × $0.75/1M = $13.58
  • 画像アドオン: 1.1Mトークン × $0.50/1M = $0.55
  • ストレージ: 約1.2GB → 無料枠内で$0
  • 検索: 28,000クエリ × $0.75/1k = $21.00
  • 埋め込み・リランキング: $0
  • 合計: 約$35.13

初月にインジェスト費用がかかるが、2か月目以降は主に検索クエリ分だけ(この例では約$21)で運用できる。ドキュメントの大幅な増加がなければ、ランニングコストを低く抑えられる構造だ。

初月のコスト内訳イメージ
インジェスト $13.58 + $0.55 検索$21
埋め込み・リランキングは無料
2か月目以降の月額
検索のみ 約$21.00
インジェスト費用が不要で、クエリ数に応じた変動

このように、AI Searchのコストは初回のデータ登録が大部分を占め、その後は利用量に比例した検索料金のみになる。大規模なデータベースを抱える場合でも、固定費ではなく使った分だけ支払うモデルのため、予算計画が立てやすい。

AI Searchの導入方法

AI Searchの導入方法

AI SearchはCloudflareダッシュボードから有効化し、すぐに使い始められる。もっとも簡単な導入は、次のwranglerコマンドでインスタンスを作成する方法だ。

npx wrangler ai-search create my-search \
  --namespace my-namespace \
  --source https://my-website.com \
  --type web-crawler \
  --hybrid-search

この1行でWebクローラー型のインスタンスが立ち上がり、ハイブリッド検索(セマンティック+キーワード)が有効になる。クロールが完了すれば、/searchエンドポイントで検索APIとして利用できる。さらに/mcpエンドポイントを使えば、ChatGPTやClaudeなどのモデルが直接ツールとして呼び出せる。

既存のアプリに組み込む場合はWorker経由でバインドし、エージェントと連携させればよい。カスタムドメインやCloudflare Accessを設定すれば、プライベートな検索サービスとしても公開できる。詳しい手順は公式ドキュメントを参照してほしい。

この記事のポイント

  • Cloudflare AI Searchは、複数サービスの組み合わせを自動化し、データ検索基盤をワンストップで提供する。
  • 公開/MCPエンドポイントやカスタムドメインにより、エージェントへの組み込みや外部共有が容易になった。
  • サイトマップ不要のクロールやEmDash CMSとの統合で、あらゆるデータソースを取り込める。
  • プレビュー価格ではデフォルトモデルの埋め込み・リランキングが無料で、予測しやすいコスト構造が示された。
  • wranglerコマンド1行でセットアップが完了し、すぐにエージェント向け検索エンジンとして利用開始できる。
エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

ソフトウェア開発のライフサイクル(SDLC)が、AIエージェントの登場によって根本から再定義されようとしている。Cloudflareは2026年8月4日、エージェント中心の新たな開発モデル「Agent Development Lifecycle(ADLC)」の構想と、それを支える具体的なツールセットを発表した。

従来のSDLCは「計画→設計→実装→テスト→デプロイ→保守」という人間中心の工程だった。しかしAIエージェントがコード生成の速度を劇的に高めた結果、周辺の工程がボトルネック化している。ADLCはこの課題を解決し、エージェントがライフサイクル全体を自律的に管理できる環境を提供する。

ADLC(エージェント開発ライフサイクル)とは何か

ADLC(エージェント開発ライフサイクル)とは何か

ADLCは、従来のSDLC(Software Development Lifecycle)をエージェント時代に合わせて再設計した概念だ。SDLCは1975年にランド研究所が提唱した「Systems Development Lifecycle」を起源とし、長年にわたりソフトウェア開発プロセスの標準だった。しかし、AIエージェントがコードを実装する速度は人間の比ではなく、テストやレビュー、デプロイといった他の工程が追いつかなくなっている。

Cloudflare Blogの著者Carlo Daniele氏によると、AIによって「実装」が最速かつ最安になった一方で、他の工程に携わる人々が膨大なプルリクエストやイシューに圧倒されるという逆説的な状況が生まれている。オープンソースメンテナの疲弊や本番環境の不安定化は、まさにこの非対称性の表れだ。

ADLCは、エージェントが実装だけでなく、テスト・デプロイ・監視・改善までを一貫して担うことを前提とする。そのために必要な要件は、プログラムによる操作が可能(Programmatic)、水平スケーラブル、再現可能、リアルタイムのプッシュ型イベント対応、アトミックな変更管理、適切な権限制御、そして自己改善能力の7つに整理されている。

従来のSDLC(人間主導)
計画 設計 実装(人間) テスト デプロイ 保守
ボトルネック: 実装だけが高速化し、他工程が逼迫
ADLC(エージェント主導)
計画 設計 実装 テスト デプロイ 保守・改善
全工程をエージェントが自律的に駆動。人間は監視と方針決定に集中

ADLCへの移行は、単にエージェントにタスクを委譲するだけでは実現しない。Cloudflareが提唱する7要件は、いずれも人間向けに設計された既存の開発基盤では満たせないものだ。次のセクションでは、なぜこのタイミングでパラダイムシフトが必要なのかを掘り下げる。

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

エージェント時代の「人間ボトルネック」

ChatGPTやClaude、GitHub CopilotといったAIツールの普及により、コード生成のスピードは飛躍的に向上した。ところが開発現場の実態を見ると、生成されたコードのレビューやテスト、本番デプロイは依然として人間が担っている。結果として、プルリクエストの滞留が慢性化し、オープンソースプロジェクトではメンテナが数千件のイシューに対処しきれずに疲弊する事例が相次いでいる。

Cloudflareの見解では、これは「エージェントを部分的にしか使えていない」ことに起因する。実装だけをエージェントに任せ、他の工程を人間が管理するという中途半端な状態が、かえって現場の負荷を増大させているのだ。

自律走行車に学ぶ「全体最適」の視点

Cloudflare Blogの記事では、ADLCの必要性を自律走行車に例えて説明している。人間向けの車にAIを載せただけでは、80%の性能は出せても、残りの20%が致命的な事故を引き起こす。安全に走行するには、LiDARや高性能コンピュータ、遠隔制御システムといった専用設計の技術が必要だ。

ソフトウェア開発でも同じで、エージェントが安全にコードをマージし、本番にデプロイするには、人間向けのCI/CDパイプラインでは不十分だ。エージェント専用のインフラ、トレーシング、権限管理、自己修復の仕組みが求められる。

ここで鍵となるのが、Cloudflare Workflowsとエージェントの組み合わせだ。従来のGitHub Actionsのような線形のパイプラインではなく、動的に分岐し、コンテナやブラウザを立ち上げ、ログを解析しながら自律的にソフトウェアを出荷する「ワークフロー」がADLCの中核を担う。

自律走行車とソフトウェアファクトリーの比較
人間用の車+AI
80%の走行は可能だが、緊急時の判断に限界。専用センサーなしでは安全性を担保できない。
自律走行専用車
LiDARや遠隔制御で99%以上の安全性を実現。専用設計が信頼を生む。
ソフトウェア開発も同じ。人間用パイプライン+AIでは限界があり、ADLC専用基盤が必要。

Cloudflareが提供するADLC基盤の全容

Cloudflareが提供するADLC基盤の全容

Workflowsが実現する動的なCI/CD

Cloudflare Workflowsは、複数のステップをチェーンし、失敗したタスクを自動リトライし、数時間から数週間にわたって状態を保持できるサービスだ。従来のCI/CDパイプラインが静的なYAML定義だったのに対し、WorkflowsはTypeScriptで動的にワークフローを定義できる。

さらにWorkflowsは、エージェントや別のWorkflowを子プロセスとして起動できる。たとえば、毎晩収集したデータをエージェントにレビューさせ、その結果を元に次のステップを動的に決定する、といった高度なオーケストレーションが可能だ。

import { CIWorkflow } from '@cloudflare/ci'

// CIパイプラインの例: 依存関係インストール後、lint/test/typecheck/buildを並列実行
const deps = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});
await Promise.all([
  deps.runner({ name: 'lint', command: 'bun run lint' }),
  deps.runner({ name: 'test', command: 'bun run test' }),
  deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
  deps.runner({ name: 'build', command: 'bun run build' }),
]);
await deps.runner({
  name: 'deploy',
  command: 'bun wrangler deploy',
  cloudflareCredentials: { accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID },
});

このコードは、依存関係のインストールをキャッシュしつつ、後続のlintやテスト、ビルドを並列で実行するパイプラインを簡潔に表現している。Workflowsによって、エージェントが生成したコードを安全に検証し、本番へデプロイするまでの一連の流れを自動化できる。

エージェントの可観測性と自己改善

ADLCにおいて、エージェントの動作を監視し、改善につなげる仕組みは欠かせない。Cloudflareは、OpenTelemetryベースのトレーシングをローカル開発環境(WranglerやViteプラグイン)に組み込み、本番環境と同等の可観測性を提供する。また、Agent Tracesによってエージェントのセッション全体をキャプチャし、パフォーマンス向上に活用できる。

さらに、Feature Flag管理のFlagshipや、段階的デプロイメント(Gradual Deployments)、Browser Runによるヘッドレスブラウザのプログラム操作など、エージェントが自律的にソフトウェアをテストし、リリースするためのプリミティブが一通り揃っている。

ADLCを支えるCloudflareの主要プリミティブ
Workflows 動的なオーケストレーションとエージェント起動
Agent Traces エージェントセッションの完全な記録と分析
Browser Run ヘッドレスブラウザを用いたE2Eテストのプログラム実行
Gradual Deployments トラフィックを徐々に切り替える安全なリリース
Cloudflare MCP Server API駆動のインフラ管理。エージェントが直接リソースを操作可能

エージェントが主導するソフトウェアファクトリーの実践例

エージェントが主導するソフトウェアファクトリーの実践例

Cloudflare自身のエンジニアリング標準化

Cloudflareは自社の全プロダクトとシステムリポジトリにわたり、AIを用いてエンジニアリング標準の遵守を強制している。具体的には、コードレビューや仕様チェックをエージェントが補助し、人間のレビュアーの負荷を軽減する仕組みだ。

これにより、コーディング規約の違反やセキュリティパターンの逸脱を自動検出し、修正案まで提示できる。人間はより創造的な設計判断や顧客との対話に時間を割けるようになったという。

Astroプロジェクトにおけるイシューゼロへの挑戦

また、CloudflareはAstroというオープンソースプロジェクトにおいて、イシューの自動トリアージ、再現、修正を行うシステムを構築した。この「ソフトウェアファクトリー」により、GitHub上のイシュー件数をゼロに近づける試みが行われている。

エージェントがバグレポートを受け取り、自動で再現環境をセットアップし、修正PRを作成する。Workflowsがこれらのステップをオーケストレーションし、テストと検証を経てマージする流れだ。この事例は、ADLCが現実のプロジェクトで有効に機能することを示している。

STEP 1 ユーザーがGitHubにバグレポートを作成
STEP 2 エージェントがイシューをトリアージし、再現環境をセットアップ
STEP 3 修正コードを生成し、PRを作成
STEP 4 Workflowsがテスト・検証を実行し、安全にマージ
Astroプロジェクトにおけるイシュー解決フロー。エージェントとWorkflowsの連携で、手動プロセスを大幅に削減している。

ADLCがもたらす開発現場の未来と課題

ADLCがもたらす開発現場の未来と課題

ソフトウェアファクトリーの民主化

現在、最先端の企業だけがソフトウェアファクトリーを構築できているのが実情だ。Cloudflareは、WorkflowsやAgent Traces、Browser Runといったプリミティブを誰でも使える形で提供することで、この格差を埋めようとしている。小規模なスタートアップでも、ADLCの恩恵を受けられるようにする狙いだ。

具体的には、@cloudflare/ciパッケージによるCI/CDの簡素化や、Flueエージェントフレームワークとの統合によって、複雑なオーケストレーションを少ないコードで実装できるようになっている。

残る課題と人間の役割

ただし、ADLCへの移行には越えるべきハードルもある。エージェントが本番環境に直接変更を加えることへの心理的な抵抗感は依然として強い。Cloudflare自身も、権限の段階的な委譲(エスカレーション)の仕組みや、監査証跡の確保が不可欠だと認識している。

また、エージェントが生成するコードの品質をどう担保するか、未知のエッジケースにどう対応するかは、自律走行車と同じく「99%の壁」をどう突破するかの問題だ。CloudflareはAgent Tracesを通じてエージェントの経験値を蓄積し、時間とともにパフォーマンスが向上する仕組みを描いているが、実運用でのデータ蓄積がこれから本格化する。

それでも、コードを書くだけのエージェントから、ソフトウェアのライフサイクル全体を駆動するエージェントへの進化は、もはや避けられない流れだろう。ADLCは、そのための地図と道路を提供するものだ。

この記事のポイント

  • ADLC(Agent Development Lifecycle)は、従来のSDLCをエージェント中心に再設計した新しい開発モデルである。
  • AIエージェントの実装速度に他の工程が追いつかない「人間ボトルネック」の解決を目指す。
  • Cloudflare Workflowsを中核に、動的でスケーラブルなCI/CDとエージェントオーケストレーションを実現する。
  • Agent TracesやBrowser Runなどのプリミティブが、エージェントの自己改善と安全な本番運用を支える。
  • ソフトウェアファクトリーの民主化により、スタートアップから大企業までADLCの恩恵を受けられる時代が近づいている。
Cloudflareがオリジン接続でポスト量子認証をサポート開始

Cloudflareがオリジン接続でポスト量子認証をサポート開始

Cloudflareがオリジンサーバーとの接続に対するポスト量子(PQ)認証のサポートを開始した。Authenticated Origin Pulls(AOP)とCustom Origin Trust Store(COTS)の2製品で、格子ベースのデジタル署名アルゴリズムML-DSAを導入する。これにより、Cloudflareと顧客オリジン間の相互TLS接続を完全に量子耐性化できるようになった。

今回の対応は、Cloudflareが掲げる2029年の完全ポスト量子セキュリティ達成に向けたマイルストーンの第一歩だ。量子コンピュータによるなりすまし攻撃の脅威が現実味を増すなか、暗号化だけでなく認証のレベルでも対策を打てる段階に入ったことを意味する。

量子コンピュータに備える認証のアップグレード

量子コンピュータに備える認証のアップグレード

Harvest-Now/Decrypt-Laterだけでは足りない

これまで量子耐性の議論は「Harvest-Now/Decrypt-Later」と呼ばれる攻撃への対策が中心だった。攻撃者が現在の暗号化通信を蓄積しておき、将来の量子コンピュータで解読するというシナリオだ。Cloudflareも2022年から来訪者との接続、2023年からはオリジン接続でポスト量子暗号化をサポートし、広く使われてきた。

しかし、近年の量子コンピュータと暗号解読のブレークスルーにより、スケジュールが前倒しされている。問題は暗号化にとどまらない。量子コンピュータは古典的な認証情報も破ることができるため、攻撃者が正規のサーバーになりすます「なりすまし攻撃」の脅威が高まっている。そこで認証にもポスト量子の仕組みを導入する必要が出てきた。

オリジン接続だからこそ先行できる理由

訪れるユーザーとCloudflareの間の接続(コネクション1)では、Web PKIの制約があり、ポスト量子証明書の普及には時間がかかる。一方、Cloudflareと顧客オリジンサーバー間の接続(コネクション2)は、あらかじめ信頼関係が確立された閉じた環境だ。このため、公開インターネット向けの証明書基盤を待たずに、独自のPKIでML-DSA署名を導入できる。

また、Cloudflareがクライアント側になるため、接続プーリングによって多数のリクエストを少数の接続に集約できる。これにより、ポスト量子署名の処理負荷をならすことが可能だ。クラウドサービスならではの制御性を活かし、Web PKIが同様の対応をするよりも早く、実際に運用できる段階までこぎつけた。

従来のTLS接続(Before)
ユーザー Cloudflare オリジン
認証はRSA/ECDSAベース → 量子攻撃で危殆化の可能性
ポスト量子mTLS接続(After)
ユーザー Cloudflare オリジン
双方向でML-DSA署名を使用。オリジンはCloudflareのクライアント証明書を検証

この接続構成では、Cloudflareがクライアント証明書を提示し、オリジン側でそれを検証することで、なりすましを阻止する。両者とも量子耐性のある署名アルゴリズムだけを信頼するよう設定すれば、ダウングレード攻撃も防げる。

AOPとCOTSの設定手順

AOPとCOTSの設定手順

ポスト量子認証を有効にするには、Custom Origin Trust Store(COTS)にML-DSAのCA証明書をアップロードし、Authenticated Origin Pulls(AOP)にはクライアント証明書と秘密鍵を登録する。以下にCloudflare APIを使った手順を示す。すべての鍵生成にはOpenSSL 3.5.0以降が必要で、秘密鍵はFIPS 204 seed-only形式を利用する。

COTS:オリジン証明書チェーンのML-DSA化

COTSは、デフォルトの公開CAに代えて顧客が指定したCAだけを信頼する仕組みだ。ML-DSA対応により、オリジンに接続する際のサーバー証明書をポスト量子化できる。まず、ML-DSA-44のプライベートCAを作成し、そのCAでオリジンサーバー証明書に署名する。

# プライベートML-DSA-44 CAの作成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-ca.key

openssl req -new -x509 -key origin-ca.key \
  -out origin-ca.crt -days 10950 \
  -subj "/CN=Origin Server CA"

# オリジンサーバー証明書の生成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-server.key

openssl req -new -key origin-server.key \
  -out origin-server.csr \
  -subj "/CN=origin.example.com"

openssl x509 -req -in origin-server.csr \
  -CA origin-ca.crt -CAkey origin-ca.key -CAcreateserial \
  -out origin-server.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\nsubjectAltName=DNS:origin.example.com\n")

生成したCA証明書をCOTSにアップロードし、SSL/TLSモードをFull(strict)に設定する。これでCloudflareは、アップロードされたCAからチェーンする証明書を持つオリジンとのみ接続するようになる。

AOP:Cloudflare側のクライアント証明書

オリジンサーバーがCloudflareからの接続だけを受け付けるようにするには、AOPでクライアント証明書を設定する。ML-DSA証明書とseed形式の秘密鍵をAPI経由で登録すれば、Cloudflareがオリジンに対して自らの身元を証明するようになる。

# AOP用CAとクライアント証明書の作成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-ca.key

openssl req -new -x509 -key aop-ca.key \
  -out aop-ca.crt -days 10950 \
  -subj "/CN=Authenticated Origin Pull CA"

openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-client.key

openssl req -new -key aop-client.key \
  -out aop-client.csr \
  -subj "/CN=cloudflare-aop-client"

openssl x509 -req -in aop-client.csr \
  -CA aop-ca.crt -CAkey aop-ca.key -CAcreateserial \
  -out aop-client.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\n")

AOPはゾーン単位またはホスト名単位で有効化できる。グローバル設定のML-DSA対応は、より大規模な変更が必要なため後日対応予定だ。

ダウングレード対策と接続確認

ポスト量子署名を導入しても、検証側が従来のRSAやECDSAを引き続き信頼していれば、経路上の攻撃者によるダウングレード攻撃を受ける可能性が残る。完全な量子耐性を確保するには、オリジン側で量子脆弱な認証方式を無効化し、ML-DSAのみを信頼する設定にしなければならない。

設定後は、openssl s_clientで署名タイプを確認したり、nginxのログにクライアント証明書のシリアル番号を出力させたりして、CloudflareがML-DSA証明書を提示していることを検証する。鍵合意でもX25519MLKEM768がネゴシエートされていることをあわせて確認したい。

STEP 1 ML-DSA鍵と証明書をOpenSSLで生成
STEP 2 CA証明書をCOTSに、クライアント証明書をAOPにアップロード
STEP 3 オリジンサーバーでnginxのssl_verify_clientをonに設定
STEP 4 Full(strict)で接続し、ログでML-DSA署名を確認

これらの手順を踏むことで、Cloudflareとオリジン間の通信が暗号化と認証の両面でポスト量子化される。

実装の舞台裏と教訓

実装の舞台裏と教訓

制御プレーンはGoの壁をCIRCLで突破

CloudflareのSSL/TLS設定を管理するサービスはGoで書かれている。ML-DSA対応にあたり、Goの標準ライブラリがまだ同アルゴリズムをサポートしていないという課題があった。そこでCloudflareは自社の暗号ライブラリCIRCLに必要な機能を実装し、標準ライブラリの不足を補った。

ただし、このアドホックな対応は一時的なもので、2026年8月にリリース予定のGo 1.27ではML-DSAがネイティブサポートされる。バージョンアップのみで多くのサービスがポスト量子認証に対応できるようになるため、エコシステム全体にとっての追い風となる見込みだ。

BoringSSL更新の遅れとインシデント

データプレーン側では、プロキシフレームワークPingoraのオリジン接続サービスがBoringSSLに依存している。同ライブラリには4年間ものアップデートが行われておらず、Cloudflareは内部フォークをメンテナンスして機能を追加していた。ML-DSAサポートがBoringSSL本体に取り込まれたことを機に、ついにアップデートを決断した。

しかし、4年分の変更にはKeyUsageルールの厳格化が含まれており、一部の顧客証明書がRFC準拠でないと判定されてしまった。慎重にテストを重ねたにもかかわらず、2026年6月10日に小規模な接続障害が発生し、ロールバックを余儀なくされた。その後、RSA証明書向けの緩和パッチを当てて再開し、現在は安定稼働している。長期間アップデートを控えることのリスクを改めて浮き彫りにした出来事だったといえる。

完全ポスト量子化へのロードマップ

完全ポスト量子化へのロードマップ

Cloudflareは2029年の完全ポスト量子セキュリティ達成を目標に掲げている。今回のAOP/COTS対応は最初のマイルストーンに過ぎない。ユーザーとCloudflare間の認証については、IETFで策定が進むMerkle Tree Certificates(MTC)による高速なポスト量子証明書の実験を経て、2027年をめどに初期展開を予定している。

Go 1.27の登場やブラウザベンダーの取り組みが進むにつれ、ポスト量子認証は急速に普及すると予想される。ひとまず、オリジンとの相互接続でML-DSAによる完全な量子耐性を確保できるようになったことは、インフラを預かる技術者にとって心強い前進だ。Cloudflareの製品別ポスト量子対応状況は、公式ドキュメントで継続的に更新されているため、導入の際は参照してほしい。

この記事のポイント

  • CloudflareがAOPとCOTSでML-DSA署名をサポートし、オリジン接続の相互TLSをポスト量子化
  • 量子コンピュータによるなりすまし攻撃に備え、暗号化だけでなく認証の強化が急務に
  • OpenSSL 3.5.0+で鍵生成し、API経由で証明書をアップロード。ダウングレード防止には従来署名の信頼解除が必須
  • Go 1.27のネイティブML-DSAサポートなど、エコシステム整備が加速中
.ALドメインのDNSSEC障害、CloudflareがEDE 33で透明性を向上

.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ドメインで何が起きたのか

.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レコード(鍵ID=26319) .ALネームサーバー DNSKEY(鍵ID=26319)
信頼チェーンが成立し、検証に成功する
障害発生時の検証チェーン(破綻)
ルートゾーン DSレコード(鍵ID=26319) .ALネームサーバー DNSKEY(新鍵・不一致)
DSレコードとDNSKEYが一致せず、検証に失敗(SERVFAIL)

この比較からわかるように、DNSSECの信頼チェーンはルートゾーンのDSレコードとTLDゾーンのDNSKEYが一致して初めて成立する。ロールオーバーの手順を誤ると、連鎖的に全下位ドメインの検証が失敗する仕組みだ。

NTA適用の判断基準

CloudflareはNTAを適用する前に、AKEPへの直接連絡とDNS-OARC Mattermostへの投稿を通じてコミュニティに注意喚起を行った。しかし、AKEPの連絡先アドレス自体が.ALドメインだったため、障害発生中は連絡が取れないという悪循環に陥った。

NTAの適用は、DNSSEC検証を停止するという強い措置だ。Cloudflareの著者によれば、.DEの事例と同様に「障害が公共に確認されており、すべての検証リゾルバに等しく影響する」という点を重視して判断したという。検証を停止しても名前解決を維持する方を優先した格好だ。

NTAの抱える透明性の課題

NTAの抱える透明性の課題

NTAはDNSSECの緊急回避手段として有効だが、一つ大きな欠点がある。それは、クライアント側からNTAの適用を検知できないことだ。NTA配下で返されたDNS応答は、通常の検証済み応答と見分けがつかない。

RFC 7646でもこの問題は認識されており、NTAの適用状況を運用者が公開することが推奨されている。Cloudflareは.DEや.ALの際にステータスページで情報を公開したが、それでも利用者が自発的に確認しなければ気づけない。監視ツールやアプリケーションがDNS応答だけで状況を把握する手段がなかった。

従来のNTA適用時のDNS応答(Before)
status: NOERROR
ANSWER: google.al → 142.251.142.196
※ 検証済み応答と外見上は区別できない
NTAの適用は応答からは一切わからない
EDE 33導入後のDNS応答(After)
status: NOERROR
EDE: 9 (DNSKEY Missing)
EDE: 33 (Negative Trust Anchor)
ANSWER: google.al → 142.251.142.196
EDE 33によってNTAの適用が明示的に通知される
EDE 9で根本的なDNSSECエラーも同時に通知

この「見えないNTA」は、なりすましDNS応答と正当な応答を区別するDNSSECの根幹を揺るがす。NTAが適用されている間、利用者は保護されていない状態で通信していることになるが、それを知る術がなかったのだ。

EDE 33がもたらす透明性

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.196

EDE 9(DNSKEY Missing)は、DNSSECの信頼チェーンが切断された根本原因を示している。EDE 33(Negative Trust Anchor)は、1.1.1.1がNTAを適用して応答を返したことを示す。この2つの情報が揃うことで、運用者は「本来は検証エラーになる状況だが、NTAによって暫定的に解決された」という全体像を把握できる。

STEP 1 クライアントが1.1.1.1に.ALドメインのDNSクエリを送信
STEP 2 1.1.1.1がDNSSEC検証を試行するが、DSレコードとDNSKEYが不一致
STEP 3 NTAが適用されているため、検証失敗でもNOERRORで応答を返す
STEP 4 EDE 9(原因)とEDE 33(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の標準化の必要性を浮き彫りにした
Cloudflare Workers Cache登場、Worker専用キャッシュでコスト削減

Cloudflare Workers Cache登場、Worker専用キャッシュでコスト削減

Workers Cache の登場でCloudflare Workersが「オリジン」から「静的配信」へ進化

Workers Cache の登場でCloudflare Workersが「オリジン」から「静的配信」へ進化

CloudflareがWorkers Cacheを正式にリリースした。これは単なるキャッシュ機能の追加ではない。Workersのアーキテクチャを根本から覆し、コストとパフォーマンスのトレードオフを解消する大きな転換点だ。一言で表せば「あなたのWorkerの前に、そのWorker専用のキャッシュを置ける機能」である。

1行の設定を追加するだけで、Workerが生成したレスポンスはCloudflareのエッジネットワークにキャッシュされる。キャッシュが有効な間はWorkerそのものが実行されず、CPU時間の課金もゼロになる。これは特に、サーバーサイドレンダリング(SSR)を行うアプリケーションにとって、待望のソリューションだ。

本記事では、なぜこの機能が必要とされていたのか、具体的に何が変わるのか、そして開発者がどのように活用できるのかを詳しく解説する。

従来のモデル(Before)
ユーザー Worker キャッシュ オリジン
Workerがリクエストの最前線に立つモデル。Workerはリクエストを処理した後、オリジンサーバーとキャッシュレイヤーに問い合わせる。
問題: Workerがオリジンの場合、処理のたびにコードが実行され、キャッシュの恩恵を受けにくい。
Workers Cache モデル(After)
ユーザー Workers Cache Worker
Workerの前に、そのWorker専用のキャッシュが配置される。キャッシュヒット時はWorkerが実行されず、Cloudflareのエッジから直接レスポンスが返る。
効果: レスポンスが高速化し、WorkerのCPU実行コストが削減される。
従来の処理フロー(Workerが起点)  Workers Cache導入後(キャッシュが起点)

この図が示すように、Workers Cacheはリクエストの最前線に立つ。これにより、Workerが事実上のオリジンサーバーとして振る舞う現代的なアプリケーションのパフォーマンスとコスト構造が劇的に改善される。

なぜサーバーサイドアプリに「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」の内部動作

パフォーマンスを極める主要機能「SWR」と「Vary」の内部動作

stale-while-revalidate が「待ち時間ゼロ」を実現する仕組み

Workers Cacheの真価を引き出すのが、stale-while-revalidate(SWR)ディレクティブだ。これはキャッシュされたレスポンスがTTLを超過した「古い(Stale)」状態でも、とりあえずその古いデータをユーザーに返しつつ、バックグラウンドで最新のデータを取得し直すHTTPの仕組みである。

SWRがない場合、キャッシュの有効期限が切れた後の最初のリクエストは、必ずWorkerが一からページをレンダリングするまで待たされる。しかしSWRがあれば、この最初のリクエストに対しても古いキャッシュが即座に返され、ユーザーは待ち時間を感じない。Workers CacheはこのSWRを完全にサポートしており、これによって「動的なサイトなのに、まるで静的サイトのように感じる」という体験を実現している。

SWR(stale-while-revalidate)の動作イメージ
TTL 内(新鮮) Cloudflareがキャッシュから即座にレスポンスを返す。Workerは実行されない。
TTL 切れ直後(古いが許容) Cloudflareが古いキャッシュを即座に返す。同時にバックグラウンドでWorkerが起動し、最新データをキャッシュに再投入する。
キャッシュ完全消失時 初めてWorkerが起動し、ユーザーはその処理完了を待つ。ただし、これは極めて稀なケースになる。
※ 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のキャッシュ」

開発者が知っておくべき設計思想「ゾーンではなくWorkerのキャッシュ」

エントリーポイント単位の柔軟なキャッシュ制御

Workers Cacheの最も革新的な部分は、それが「ゾーン(ドメイン)」ではなく「Worker」に紐づくという設計思想にある。この思想が、従来のCDNでは実現できなかったいくつもの高度なユースケースを可能にしている。

特に重要なのが、Workerのエントリーポイントごとにキャッシュの有効・無効を設定できる点だ。設定ファイルでエクスポート名("default""CachedBackend")を指定するだけで、認証処理を行うゲートウェイWorkerはキャッシュを無効化し(常にコードを実行するため)、その背後で重い処理を行うバックエンドWorkerだけにキャッシュを有効化する、といった構成が可能になる。

キャッシュの段階的構成(キャッシュ有効/無効の組み合わせ例)
ユーザー ゲートウェイWorker キャッシュ無効 Workers Cache(内部用) 重い処理の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をキャッシュキーに含めることで、マルチテナント環境でも安全なキャッシュが実現する。
Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金

Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金

広告型モデルの限界とAIエージェント向け従量課金

広告型モデルの限界とAIエージェント向け従量課金

2026年7月1日、CloudflareはMonetization Gatewayを発表した。HTTPの402ステータスコードを拡張したオープンプロトコル「x402」を基盤に、ウェブ上のあらゆるリソースに対して従量課金を適用できる仕組みである。保護対象はウェブページ、データセット、API、MCPツールにおよび、代理店や大規模言語モデルが自律的に支払う時代を見据えている。

背景にはウェブビジネスモデルの構造変化がある。30年にわたり、コンテンツは広告や月額課金で収益化されてきた。しかしAIエージェントが人間に代わって情報を消費するようになると、バナー広告をクリックすることも、毎月のサブスクリプションを維持することもない。エージェントは必要なデータを一度取得すれば、数十回、数千回と繰り返しアクセスし始める。Cloudflareの発表資料によると、AIクローラーのリクエスト数は、そこからサイトへ誘導される訪問者1人あたり数百~数万回に達しているという。

従来のAPI従量課金は既存ユーザー向けに限定され、サブセント単位の少額決済には向かなかった。クレジットカードの手数料が取引額を上回るためだ。ここでCloudflareが着目したのが、ステーブルコインによる一瞬の決済である。Monetization Gatewayは、支払い検証と流量制御をエッジで完結させ、オリジンサーバーに過剰な負荷をかけずに課金を実現する。

従来の広告モデル(Before)
人間の訪問者 ページ閲覧 → 広告クリック → 収益発生
※AIエージェントは広告をクリックしないため収益化できない
従量課金モデル(After)
AIエージェント リクエスト → 自動支払い → リソース取得
※1リクエスト単位の少額決済で収益化が成立
人間 = 広告・サブスクリプション  AIエージェント = 従量課金・自動決済

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プロトコルとは

x402はHTTPのステータスコード「402 Payment Required」を実際に活用するオープンプロトコルである。この規格はCloudflareがx402 Foundationのもとで25以上の業界リーダーと共同開発を進めている。従来の402は予約状態にあり、実際の決済フローには使われていなかった。

x402のやりとりは単純だ。クライアントが支払い必須のリソースをリクエストすると、サーバーは402 Payment Requiredとともに価格、受け入れ可能な通貨、支払い先を含む小さなペイロードを返す。クライアントは支払いを実行し、支払い証明を添えてリクエストを再送する。ファシリテーター(検証者)が証明を確認し、オリジンサーバーが最終的にリソースを返す。すべてが通常のHTTPリクエスト/レスポンスの中で完了し、決済ページへのリダイレクトも個別の決済API呼び出しも発生しない。

STEP 1 AIエージェント がリソースをリクエスト
STEP 2 APIサーバー が 402 Payment Required と価格を返す
STEP 3 エージェントが ブロックチェーン で支払いを実行
STEP 4 支払い証明付きで再リクエスト → リソース取得
AIエージェント = 利用者  APIサーバー = 提供者  ブロックチェーン = 決済基盤

x402の利点は2つある。1つは最小単位がセント未満まで刻めること。プロトコルのオーバーヘッドが極めて低く、取引額が支払いコストを下回る逆転を防げる。もう1つは、買い手が売り手のアカウントを事前に取得する必要がないことだ。支払い自体が資格情報として機能するため、サインアップやAPIキー発行なしに取引が成立する。

サブセント決済と一瞬の決済

ステーブルコインを使う決済は、現在の主要な決済レールでは実現できなかったスピードと低コストを両立する。Cloudflareはサブセカンド(1秒未満)の決済を目標に掲げている。エージェントが数セントのデータを購入するために数ドルの手数料と数日の決済期間を待つ必要はなくなる。この速度と低コストが、AI時代の大量のマイクロペイメントを支える。

Monetization Gatewayの機能

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との連携も予定している。エージェントに認証を求め、既存のアカウントに対して従量課金を適用する柔軟性を提供する方針だ。これにより、完全な匿名取引だけでなく、信頼関係に基づく課金も選択できるようになる。

ルール定義
サイト運営者 ダッシュボード / API / Terraform で設定
エッジで検証
Monetization Gateway 支払いを確認しオリジンを保護
決済完了
ステーブルコイン 売り手のウォレットに直接入金
運営者 = ルール設定  Gateway = 検証  決済 = 即時着金

売り手にとっての変化

Monetization Gatewayを利用する売り手は、蓄積したステーブルコインをそのまま別の取引に使うことも、銀行口座で法定通貨に換金することもできる。Cloudflareが発表した構想では、支払い検証はすべてエッジで完結し、オリジンには課金ルールと実際の収益だけが残る。

これはAPIプロバイダーにとって、販売可能市場を拡大する直接的な手段になる。AIエージェントはリソースを要求し、価格を提示され、支払い、結果を得る。サインアップもAPIキーも事前の関係も必要ない。Cloudflareは、いつでも買い手の認証や既存アカウントとの紐付けを追加できる柔軟性を残している。

この記事のポイント

  • CloudflareがHTTP 402を利用した従量課金プロトコルx402を実用化。Monetization Gatewayによりあらゆるウェブリソースへの課金が可能に
  • AIエージェントが大量にコンテンツを消費する時代、広告に依存しない収益モデルとしてマイクロペイメントが鍵を握る
  • ステーブルコインによるサブセカンド決済で、サブセント単位の取引でも手数料が収益を上回らない
  • 課金ルールはコードで管理でき、売り手は買い手のオンボーディングや請求システムを構築する必要がない
  • Web Bot Authとの連携や変動価格設定など、エージェント経済向けの拡張機能が計画されている
CloudflareのAIクローラールールがGooglebotをブロックする危険性

CloudflareのAIクローラールールがGooglebotをブロックする危険性

CloudflareがAIクローラー対策の仕組みを抜本的に見直し、2026年9月15日から新たなデフォルト設定を適用する。この変更は単なるAIボット対策の強化にとどまらず、Googlebotのような検索クローラーまで巻き込む可能性がある。AIにコンテンツを学習されたくないという意図で設定したブロックが、結果的に検索エンジンからの流入を断つリスクをはらんでいるのだ。

特に影響が大きいのは、Cloudflareの無料プランを利用するWordPressサイトや中小企業のオウンドメディアだ。AI学習ブロックの意図がなくても、9月15日以降にデフォルト設定が自動適用され、知らぬ間にGooglebotのクロールが制限される可能性がある。本記事では3つの振る舞い分類、デフォルト変更の詳細、そして今すぐ取るべき対応策を解説する。

従来の対策(Before)
AIクローラー ブロック
Googlebot 許可
単純な「AIボットブロック」スイッチで二項対立的に対応
9月15日以降の新ルール(After)
AI訓練 ブロック
Googlebot ブロック(巻き添え)
混合用途のクローラーは最も厳しいルールが適用される
検索クローラー  AI系クローラー  ブロック対象  許可対象

CloudflareがAIクローラー対策の方針を転換した背景

CloudflareがAIクローラー対策の方針を転換した背景

Cloudflareは2026年7月2日、第2回「Content Independence Day」の一環として、AIクローラー管理の新方式を発表した。従来の単一の「AIボットをブロック」スイッチを廃止し、クローラーの振る舞いに基づいた3つのカテゴリで制御する仕組みへ移行する。この変更は全顧客(無料プランを含む)に即時適用され、9月15日にはデフォルト設定も自動変更される。

背景にあるのは、AIクローラーによるコンテンツ収集の爆発的な増加だ。Cloudflareのネットワーク上では、AI訓練目的のクローラーリクエストが全体の過半数を占めるまでに成長した。2025年春時点では約20%だったが、1年で状況は一変した。AIエージェントのリクエスト数も前年比1700%増と、指数関数的な伸びを示している。

この急増に対し、多くのパブリッシャーやサイト運営者はAIクローラーを一律ブロックする方向に動いてきた。しかし、その「一律ブロック」が検索クローラーまで巻き込む副作用を生みつつあった。Cloudflareの今回の方針転換は、この問題に正面から取り組むものだが、同時に新たなリスクも生じさせている。

3つの振る舞い分類がクローラー制御を変える

3つの振る舞い分類がクローラー制御を変える

Cloudflareの新方式は、クローラーを「AIかどうか」ではなく「サイト上で何をするか」で分類する。この考え方は、サイト運営者にとってクローラー制御の解像度を格段に上げるものだ。3つのカテゴリは以下のとおり。

Search(検索) 後で質問に答えるためにインデックス
参照トラフィックと紐づく動作。検索エンジン向けの従来型クロール
Agent(エージェント) 人間の代わりにリアルタイム動作
ChatGPT-UserやGemini、ClaudeがChromeを操作するようなブラウザエージェント
Training(訓練) モデルの訓練や微調整のために収集
コンテンツをAIモデルの学習データとして利用するためのクロール
検索インデックス  リアルタイムエージェント  AI訓練データ収集

Cloudflareは、ボット運営者に対して「振る舞いごとに別々のクローラーを用意すべき」と要求している。サイト側が「なぜそのボットが来ているのか」を判断し、許可・ブロックを適切に選択できるようにするためだ。この考え方自体は合理的だが、現実にはGooglebotのように検索とAI訓練の両方を行う「マルチパーパスクローラー」が存在する。この点が後述する問題の核心となる。

検索クロールとAI訓練クロールの同居がリスクを生む

Googlebot、Applebot、Bingbotは、いずれも検索インデックス作成とAIモデル訓練の両方に使用される。Cloudflareの新ルールでは、こうした「混合用途のクローラー」に対して最も厳しい制限が適用される。つまり、AI訓練目的のクロールをブロックしているサイトでは、同じクローラーによる検索目的のアクセスも自動的にブロックされるのだ。

これはrobots.txtとは根本的に異なる。robots.txtはクローラーへの「お願い」に過ぎず、無視されることもある。しかしCloudflareのブロックはネットワークレベルで動作するため、robots.txtよりはるかに強力だ。グーグルでさえバイパスできない。AI訓練を止めたい一心で設定したブロックが、検索流入というサイトの生命線を断ち切ってしまう皮肉な構造が生まれている。

9月15日のデフォルト変更が生む3つのリスク

2026年9月15日に自動適用されるデフォルト設定の変更は、Cloudflareを利用するあらゆるサイトに影響を及ぼす。特に注意すべきは以下の3点だ。

リスク 1 広告表示ページでTrainingとAgentがデフォルトブロック
新規顧客および既存顧客の新規サイトでは、広告を表示するページにおいてTrainingとAgentが自動ブロックされる。Searchは許可。
リスク 2 既存無料ユーザーも設定未変更なら自動移行
9月15日までに設定を一度も変更していない無料プランユーザーは、新デフォルトに自動移行される。
リスク 3 マルチパーパスクローラーに最も厳しいルールが適用
検索とAI訓練の両方を行うGooglebot等は、AI訓練をブロックすると検索クロールも停止。旧「Block AI bots」設定が有効なサイトもこのルールの対象。

とりわけ危険なのはリスク3だ。従来の「AIボットをブロック」設定を有効にしたまま放置しているサイトは、9月15日以降にGooglebotのアクセスがネットワークレベルで遮断される可能性がある。検索クロールが停止すれば、新規コンテンツのインデックス登録が滞り、既存ページの再クロール頻度も低下する。検索順位への影響は数週間から数カ月かけて徐々に表面化するため、原因特定が遅れやすい。

robots.txtとの違いを理解しておくべき理由

多くのサイト運営者は「robots.txtでブロックしているから大丈夫」と考えがちだ。しかし、robots.txtはクローラーに対する紳士協定に過ぎず、グーグルも状況によって無視することがある。一方、Cloudflareのブロックはリクエストがオリジンサーバーに到達する前にネットワークエッジで遮断する。この違いは決定的だ。

robots.txtでのブロックは「できれば来ないでほしい」というお願いであり、Cloudflareのネットワークブロックは物理的な門番が門を閉ざすようなものだ。後者のほうが確実だが、その分だけ設定ミスの代償も大きい。AI訓練ブロックのつもりが検索クローラーまで締め出してしまうと、サイトの検索パフォーマンスは確実に悪化する。

実務者が今すぐ取るべき対応チェックリスト

実務者が今すぐ取るべき対応チェックリスト

9月15日までに対応を完了する必要がある。以下に具体的なアクションを時系列で整理した。

STEP 1 Cloudflareダッシュボードにログインし、AIクローラー設定を確認する
STEP 2 「Search」「Agent」「Training」の3カテゴリそれぞれの許可・ブロック状態を把握する
STEP 3 Searchカテゴリが「許可」になっていることを必ず確認する
STEP 4 旧「Block AI bots」設定が有効な場合は、Searchを個別に許可するか設定全体を見直す
STEP 5 Google Search Consoleでクロール統計を定期監視する体制を整える

STEP 5のクロール統計監視は特に重要だ。9月15日以降にGooglebotのクロール頻度が急落した場合、Cloudflare設定に原因がある可能性が高い。Search Consoleの「クロール統計レポート」で1日あたりのクロールリクエスト数を確認し、急激な減少があれば即座にCloudflareダッシュボードを再確認する習慣をつけておきたい。

無料プランユーザーが特に注意すべきポイント

Cloudflareの無料プランを利用しているサイトは、9月15日までに一度もAIクローラー設定を変更していない場合、自動的に新デフォルトへ移行される。つまり「設定を触っていないから大丈夫」という認識が最も危険だ。何もしないことが、意図せずGooglebotブロックを招く可能性がある。

無料プランであっても、ダッシュボードから3カテゴリの設定を手動で確認・変更することは可能だ。Searchカテゴリだけは明示的に「許可」に設定し、TrainingやAgentはサイトのポリシーに応じて判断する。この一手間をかけるかどうかで、9月15日以降の検索パフォーマンスが大きく変わる。

今後の展望とサイト運営者が持つべき視点

今後の展望とサイト運営者が持つべき視点

Cloudflareは、マルチパーパスクローラーの運営者に対して「振る舞いごとにクローラーを分離する」ことを求めている。グーグルやアップル、マイクロソフトがこの要求に応じてGooglebotを用途別に分割するかどうかが、今後の分岐点となる。仮に分割が実現すれば、サイト運営者はAI訓練だけをブロックし、検索インデックスは許可するという選択が可能になる。

しかし、現時点ではその保証はない。9月15日以降もGooglebotは単一のクローラーとして動作し続ける可能性が高い。つまり、AI訓練をブロックするという選択は、当面の間「検索流入とのトレードオフ」であり続ける。この現実を直視した上で、サイト運営者は自社のコンテンツ戦略とAIポリシーを再定義する必要がある。

Cloudflareは新しいコンテンツ利用シグナルもテスト中だ。robots.txtに記述するContent Signalsの拡張で、immediate(保存しない)、reference(インデックスしてリンクバック、新デフォルト)、full(要約・複製を許可)の3段階を指定できるようにする。ただしこれは設定上の「希望表明」であり、単体ではブロック機能を持たない点に注意が必要だ。

サイト運営者が今から準備すべき3つのこと

準備 1 Cloudflare設定の確認とSearchカテゴリ許可の徹底(9月15日期限)
準備 2 Google Search Consoleのクロール統計を週次で確認する運用フローの整備
準備 3 AI訓練許否に関する社内ポリシーの策定(検索流入とのバランス考慮)

AIにコンテンツを学習されることを完全に拒否するのか、それとも検索流入を優先するのか。この問いに明確な答えを持たないまま9月15日を迎えると、Cloudflareの新デフォルトによって想定外のブロックが発生し、検索パフォーマンスが毀損するリスクがある。サイトの規模や収益構造に応じて、今のうちに方針を固めておくことが重要だ。

この記事のポイント

  • CloudflareのAIクローラー管理が3つの振る舞い分類(Search、Agent、Training)に再編された
  • 9月15日から広告表示ページでTrainingとAgentがデフォルトブロックされ、無料プランユーザーも自動移行の対象
  • Googlebotのような混合用途クローラーは、AI訓練をブロックすると検索クロールも停止する
  • robots.txtと異なり、Cloudflareのブロックはネットワークレベルで動作しバイパスが困難
  • Searchカテゴリの許可確認とSearch Consoleでのクロール統計監視が当面の最優先対応
WPMU DEVがEmDash Hostingを発表、WordPressと同じ管理画面でTypeScript CMSを運用可能に

WPMU DEVがEmDash Hostingを発表、WordPressと同じ管理画面でTypeScript CMSを運用可能に

WordPress制作者の多くにとって、その手間こそが「EmDashを一度見てみたい」という思いを机の隅のTo-Doリストに留まらせる最大の壁だった。

WPMU DEVが発表したEmDash Hostingは、まさにその手間を取り除くために設計されたサービスだ。2026年6月の公式アナウンスにより、WordPressサイトと同じ管理画面からワンクリックでEmDashサイトを立ち上げられる環境が提供されている。

EmDash HostingがWordPress制作者にもたらすもの

EmDash HostingがWordPress制作者にもたらすもの

EmDashそのものは、CloudflareがオープンソースのMITライセンスで公開したTypeScript製CMSだ。サーバーレスかつセキュリティ重視の設計思想を持ち、従来のCMSとは一線を画すアーキテクチャで注目を集めている。

WPMU DEVが提供するのは、そのEmDashを動かすためのホスティングと管理のレイヤーである。具体的には、同社のUnlimited Hostingプラットフォーム上でEmDashサイトを稼働させる仕組みだ。Unlimited Hostingは、多数のサイトを運用するエージェンシーやフリーランサー向けに構築されたマネージド環境で、3GHz以上のIntel XeonプロセッサとNVMe SSDを搭載した高性能サーバー上で50以上のサイトを月額15ドルから運用できる。

WordPressとEmDashの混在運用が現実に

今回の発表で重要なのは、EmDashサイトがこのUnlimited Hostingの枠組みに含まれるようになった点だ。サーバーのリソースが許す限り、WordPressのインストールと並行してEmDashサイトをいくつでも立ち上げられる。

このアプローチが最初に訴求するのは、EmDashに興味を持ちながらも、テスト用に別のインフラを用意することに二の足を踏んでいたエージェンシーやフリーランサーだろう。TypeScriptベースでAstroフレームワークを採用したCMSを、ローカル環境のセットアップなしで触れる点は、開発者にとっても低リスクな検証手段となる。

従来のEmDash導入フロー(Before)
開発者 1. サーバー構築 2. CLIインストール 3. ランタイム設定 4. 動作確認
※数時間から半日の環境セットアップが必要
EmDash Hosting導入フロー(After)
WPMU DEV Hubからワンクリック 即時公開
※WordPressサイトと同じ管理画面で操作が完結

従来のCLIベースのセットアップでは、環境構築だけで数時間を要していた。EmDash Hostingではワンクリックでサイトが立ち上がり、即座に動作確認に移れる。

WordPressスタックにおけるEmDash Hostingの立ち位置

WordPressスタックにおけるEmDash Hostingの立ち位置

現状、EmDashを評価する人の多くは、それを独立したプロジェクトとして扱っている。専用のリポジトリ、デプロイ先、認証情報、そして運用の考え方も別々だ。サイトを維持すると決めた場合、WordPressの運用管理とEmDashの運用管理という2つの業務を並行して回すことになる。

WPMU DEVのEmDash Hostingは、この2つを1つに統合する。EmDashサイトはWordPressサイトと同じサーバー上に存在し、Hubと呼ばれる単一のダッシュボードから同じツールで管理される。

エージェンシーにとっての利点は明快だ。EmDashのクライアントサイトもWordPressのクライアントサイトも、同じ一覧に表示され、同じ方法でバックアップされ、同じログイン経路でアクセスできる。つまり、EmDashはワークフローの中で「特別扱い」する必要がなく、既存の運用に自然に溶け込む。

実験コストがゼロに近づく

WP Mayorの記事が指摘する通り、このサービスの本質的な価値は「EmDashがWordPressを置き換える」ことではなく、「EmDashが既存のワークフローで自動的に扱えるもう1つのサイト種別になる」点にある。実験にかかるコストは時間以外ほぼゼロになり、導入の敷居は極めて低くなる。

統合前のサイト管理モデル
WordPress運用
専用ダッシュボード
個別バックアップ
独立した監視
EmDash運用
別サーバー管理
手動バックアップ
独立した監視
※運用担当者の作業が2倍に
統合後のサイト管理モデル
Hub統合管理
WordPressとEmDashが同一ダッシュボードに表示
共通のバックアップとSSL管理
サーバーレベルのWAFとAntiBotで両方を保護
※運用負荷は据え置きのまま新技術を試せる

管理画面が統合されることで、EmDashサイトの追加が運用負荷の増大に直結しない。これは新技術の評価フェーズにおいて決定的な差となる。

EmDash Hostingの実際の動作

EmDash Hostingの実際の動作

WPMU DEVの発表から、実運用面で注目すべきポイントを5つに整理する。

インストールは文字通りワンクリック

標準的なEmDashのセットアップはCLIツールを経由するが、EmDash HostingではHubの管理画面からボタン1つでサイトが作成される。構築の仕組みを知る前に、まず動く状態を確認したいというニーズに応える設計だ。

WPMU DEVは初期状態で使えるコンタクトフォームプラグインも同梱しており、今後さらにプラグインを追加する予定としている。プラグインはローカルで動作するため、Cloudflareのアカウントを別途取得する必要はない。

WordPressサイトとまったく同じ管理体験

サイトが公開されると、WPMU DEV HubからのSSOログイン、日次バックアップ、カスタムドメイン設定、無料SSL証明書、サーバーレベルのSSH/SFTPアクセス、ストレージ使用量を可視化するサーバー分析が利用できる。新興プラットフォームでは後回しにされがちな基盤機能が、WPMU DEVの既存ホスティングレイヤーからそのまま提供される点が特徴だ。

セキュリティとサポートがそのまま適用

EmDashサイトにはサーバーレベルでのWAF(Webアプリケーションファイアウォール)とAntiBot保護が適用され、Proメールおよび24時間365日のライブチャットサポートも付帯する。WP Mayorの記事が評価するのは、サポートに対するWPMU DEVの正直な姿勢だ。同社は「我々もまだ学習中である」と明言し、EmDashに関する問い合わせには最善を尽くすとしつつ、この新しいCMSに対する深い専門知識を誇示しない。初期段階のCMSを試す際、障害が発生しても自力で解決するしかない状況が多い中、少なくともホスティング環境を熟知したサポートチームが背後にいることは安心材料となる。

公開直後からページが正しく表示される

これは実際に遭遇するまで気づきにくい問題だ。デフォルトのEmDashテンプレートでは、新規ページやプロジェクトを作成して公開しても、公開URLにアクセスすると404エラーになるケースがあった。理由は、EmDashが内部でAstroフレームワークを使用しており、ルーティングがテンプレート側で処理されるためだ。WordPressのように公開コンテンツが自動的にルーティングされるわけではない。

WPMU DEVはホスティング用のテンプレートに修正を加え、公開したページやプロジェクトが即座に表示されるようにしている。書類上は小さな変更だが、新プラットフォームを触り始めて10分で「操作ミスなのかバグなのか」と困惑する事態を防ぐ効果は大きい。

メール設定が自動化されている

EmDashのメール処理はWordPressと異なる仕組みを持ち、この違いが様々な機能の動作不良を引き起こす原因になりやすい。WPMU DEVはUnlimited Hosting上のEmDashサイトにメール設定を自動構成するプラグインをバンドルしており、パスキーログインリンクやフォーム通知などのトランザクションメールが、手動の配信設定なしですぐに機能する。

EmDash Hostingが自動処理する5つの要素
1. サーバー構築 WPMU DEVのUnlimited Hosting上に自動展開
2. SSL証明書 無料SSLが自動発行され、常時HTTPS化
3. ルーティング修正 公開直後から404にならないパッチ適用済み
4. メール自動設定 トランザクションメールが手動設定なしで機能
5. 日次バックアップ WordPressサイトと同じスケジュールで自動実行
※これらはWPMU DEVのホスティングレイヤーが提供する機能であり、EmDashのエコシステム成熟度には依存しない

新興CMSの導入時に障壁となる運用面の課題が、ホスティング側のレイヤーで吸収されている。

ユーザータイプ別に見るメリット

ユーザータイプ別に見るメリット

エージェンシー

現時点でEmDashをテストする可能性が最も高いのはエージェンシーだろう。クライアントからEmDashについて質問されたときに、運用体制を再構築することなく「対応できる」と答えられる点が最大の魅力だ。チームが日常的に使っているHubダッシュボードの中で、サイトの立ち上げ、評価、管理が完結する。

フリーランサーと開発者

現在注目を集めるTypeScript CMSを、環境構築に午後を費やすことなく実際に触れる手段となる。EmDashはAIエージェントを第一級のユーザーとして扱う設計思想を持ち、WordPress開発向けAIツールと同じ文脈で語られることが増えている。このホスティングを利用すれば、半日かけて環境を整える代わりに、すぐに自分の意見を形成できる。

ブロガーとコンテンツ制作担当者

より新しいパブリッシングスタックを試しつつ、WPMU DEVのマネージドバックアップやセキュリティ、サポートという安全網を維持できる点が訴求ポイントとなる。

WooCommerceストア運営者と大規模サイト管理者

WP Mayorの記事も指摘する通り、現時点では現実的かつ慎重な姿勢が求められる。EmDashそのものがまだ初期段階であり、本格的な移行対象として検討する段階ではない。このホスティングは「CloudflareのCMSがどこへ向かうのか、自分の手で感触を掴むための最も摩擦の少ない方法」と捉えるのが妥当だ。

制限事項とトレードオフ

制限事項とトレードオフ

最大の留保条件はホスティングそのものではなく、CMSとしてのEmDashの成熟度にある。プラグインマーケットプレイスも、サードパーティ製テーマのライブラリも、まだ充実しているとは言えない。現時点でEmDash上に構築できるものは、20年にわたるWordPressの開発が生み出した世界と比較すれば、明らかに限定的だ。

EmDash HostingはEmDashの運用を容易にするが、EmDashのエコシステムそのものを成熟させることはできない。本番サイトの大部分にとって、WordPressが依然として現実的な選択肢であることに変わりはない。

WooCommerceはさらに明確な例だ。ストアを運営している場合、ビジネスはWordPressとWooCommerceホスティングのエコシステムの中に存在しており、EmDashはその代替にはならない。ストア運営者にとっての正直な用途は、現段階では好奇心と実験に留まるだろう。

プラットフォームに関する制約もある。EmDash HostingはWPMU DEVのPremiumメンバーシップ限定で提供される。まだWPMU DEVのエコシステムに入っていない場合、EmDashを評価するということはWPMU DEVも同時に評価することを意味する。

機能面の現状

すべてのHubツールがEmDashに対応しているわけではない。現在EmDashで利用できる機能は以下の通りだ。

  • ワンクリックインストール
  • SSOログイン
  • リセット
  • リビルド/再起動
  • ドメイン管理
  • Proメール
  • バックアップと復元
  • WAF(Webアプリケーションファイアウォール)
  • AntiBot保護
  • サーバー分析
  • SSH/SFTPアクセス
  • 無料SSL証明書
  • クライアント管理と請求
  • サポートチケット

一方で、WordPress側では定番となっているステージング機能やクローン機能は、EmDash向けにはまだ提供されていない。SSH/SFTPはサーバーレベルでのアクセスとなり、1つのサーバーユーザーが同一サーバー上の全サイトにアクセスする形となる点にも注意が必要だ。

料金とライセンス

料金とライセンス

EmDash HostingはWPMU DEVのUnlimited Hostingに含まれるため、サーバー料金を支払えば、容量が許す限りWordPressサイトと並行してEmDashサイトを無制限に稼働させられる。サイト単位の追加料金は発生しない。

プランは以下の通り構成されている。

  • Alpha MU(月額15ドル): 1GB RAM、23GBストレージ
  • Beta MU(月額23ドル): エージェンシー向けの最も人気のあるプラン
  • Eta MU(月額300ドル): 32GB RAM、455GBストレージ

全プランで帯域幅は無制限、30日間の返金保証が付く。EmDash本体はMITライセンスのオープンソースであり、CMS自体にライセンス費用はかからないが、マネージドホスティングを利用するにはWPMU DEV Premiumメンバーシップへの加入が必要となる。

EmDash Hosting導入の意思決定フロー
Q1. WPMU DEVメンバーか?
Yes → 実験コストはほぼゼロ。即試行を推奨
No → Q2へ
Q2. 複数サイトを運用するエージェンシーか?
Yes → Unlimited Hostingの導入検討と同時にEmDash評価が可能
No → Q3へ
Q3. WooCommerceストアや大規模本番サイトを運営中か?
Yes → 本番移行は時期尚早。技術動向の観察対象として注視
No → EmDash単体への興味が主目的なら、他の学習リソースを検討

このサービスは、あくまでも「CloudflareのCMSがどの方向へ進むのか、最小の摩擦で自分の手で感触を掴む手段」として読むのが賢明だ。本業のサイトは今ある場所に置いたまま、未来の選択肢を検証できる点に価値がある。

この記事のポイント

  • WPMU DEVのEmDash Hostingは、WordPressと同じHub管理画面からワンクリックでEmDashサイトを立ち上げられるマネージドホスティングである
  • Unlimited Hostingプランに含まれ、追加料金なしでEmDashサイトをサーバー容量の許す限り稼働させられる
  • 日次バックアップ、WAF、AntiBot、SSL、SSH/SFTPなど、新興CMSに不足しがちな運用基盤が最初から整備されている
  • EmDashのエコシステムはまだ初期段階であり、本番サイトの移行先としては時期尚早だが、技術検証の手段としての価値は高い
  • エージェンシーやフリーランサーにとって、運用フローを変えずに次世代CMSを評価できる点が最大の利点である