WooCommerce Social Loginに深刻度9.8の脆弱性。管理者アカウント乗っ取りの危険
WooCommerce Social Loginプラグインに、未認証の攻撃者が任意のユーザーアカウントにログインできる重大な脆弱性が報告された。CVSSスコアは9.8と最高クラスの深刻度であり、管理者権限の奪取も可能になる。バージョン2.8.7以下を利用しているすべてのサイトが対象だ。
この脆弱性はAppleログイン処理に存在し、攻撃者は特別な権限を必要としない。正規のユーザーのメールアドレスさえ知っていれば、管理者を含む任意のアカウントに不正ログインできる。2026年8月1日に公開されたCVE-2026-8457として識別されており、即時対応が求められる。
深刻度9.8の認証バイパス脆弱性と影響範囲
Wordfenceのセキュリティ研究者によって発見されたこの脆弱性は、WooCommerce Social LoginのAppleサインイン機能に潜んでいた。ユーザーがAppleアカウントでログインする際、プラグインはAppleから返されるIDトークンの正当性を検証していなかった。このため攻撃者は、なりすましたいユーザーのメールアドレスを含む偽のトークンを作成し、認証をすり抜けられる。
被害を受けるのはWooCommerce Social Loginのバージョン2.8.7以下の全インストールだ。プラグインを有効化しているサイトであれば、特別な設定ミスがなくても攻撃が成立する。攻撃者はユーザー名やパスワードを一切知る必要がなく、標的のメールアドレスさえ分かれば管理者権限でログイン可能になる。
一般的なWordPressの脆弱性では、攻撃者が何らかの権限をあらかじめ持っていたり、管理者がリンクをクリックするなどの操作が必要になることが多い。しかし今回は、攻撃者が標的サイトにリクエストを送るだけで管理者アカウントにログインできてしまう。いわゆる「認証なしの管理者乗っ取り」に分類され、CVSS 9.8という評価はその直接的な危険性を反映している。
なぜこれほど危険なのか
認証バイパスにより管理者権限を取得した攻撃者は、WooCommerceサイトの全データを自由に操作できる。具体的には、顧客情報や注文データの窃取、不正な管理者アカウントの追加、プラグインやテーマの改ざんによるマルウェア注入、支払い情報への介入などが考えられる。さらに、サイトのSEO評価を意図的に下げるスパムリンクの埋め込みや、Googleからのインデックス削除といった攻撃も容易に行われてしまう。
WooCommerceを利用するECサイトでは、顧客の個人情報や購入履歴が保存されている。こうしたデータが流出した場合、個人情報保護法やGDPRなどの規制違反に発展する可能性もある。サイトの信用失墜だけでなく、法的なリスクや多額の損害賠償にまでつながりかねない。
WooCommerceのコア機能や他の決済プラグインでは、こうした認証処理に対する検証が厳格に行われている。しかし、Social LoginプラグインのAppleログイン部分だけが例外的に署名検証を欠いていた。そのため、攻撃の標的として非常に狙われやすい。
Appleログイン処理の具体的な問題点
Appleサインインでは、ユーザーが認証を完了すると、AppleのサーバーからIDトークンと呼ばれるデータがサイト側に送られる。このトークンにはユーザーのメールアドレスなどの情報が含まれ、改ざんを防ぐためにAppleの秘密鍵で電子署名が付与されている。プラグインは本来、Appleが公開している鍵を使ってこの署名を検証し、トークンが本物であることを確認しなければならない。
ところが、WooCommerce Social Loginはこの署名検証のステップを実装しておらず、受け取ったメールアドレスをそのまま信頼してログイン処理に使っていた。結果として、攻撃者が偽のIDトークンを作り、その中に標的ユーザーのメールアドレスを入れて送信するだけで、そのユーザーとして認証が通ってしまう状態になっていた。
Wordfenceの調査によると、管理者ロールかどうかのチェックも行われていなかった。攻撃者が管理者のメールアドレスを指定すれば、管理画面へのフルアクセスが即座に与えられる。これはIDトークンに含まれる「email」フィールドを、ログインにそのまま使う実装ミスに起因している。
つまり、IDトークンの署名確認という重要な防御ラインがまるごと欠落していたわけだ。この種の不備は、OpenID ConnectやOAuth 2.0を利用するソーシャルログイン実装では絶対にあってはならないものであり、Wordfenceの報告では「未認証の攻撃者が、偽造したid_tokenのペイロードに対象ユーザーの電子メールアドレスを含めて送信するだけで、管理者を含む任意のアカウントでログインできる」と指摘されている。
影響を受けるバージョンと今すぐ取るべき対策
この脆弱性の影響を受けるのは、WooCommerce Social Loginバージョン2.8.7以下のすべてのリリースだ。8月1日の公開後、プラグイン開発元はすぐに修正版2.8.8をリリースしている。Wordfenceは、該当バージョンを使用しているユーザーに対して、2.8.8またはそれ以降のバージョンへの即時アップデートを強く推奨している。
アップデートを適用しないまま放置すると、攻撃者に管理者権限を奪取された後に、バックドアを仕込まれたり、サイトの完全な乗っ取りが発生する可能性が高い。特にWooCommerceサイトでは決済情報や顧客データが絡むため、被害が拡大する前に一刻も早く更新を済ませてほしい。
- WordPress管理画面から「プラグイン」→「インストール済みプラグイン」を開く
- 「WooCommerce Social Login」を探し、利用可能なアップデートがあれば「今すぐ更新」をクリック
- バージョンが2.8.8以上になっていることを確認する
- 万が一、プラグインをすぐに更新できない事情がある場合は、一時的にプラグインを無効化する
また、サイトの管理者アカウントに不正なログインがなかったかどうか、アクセスログやユーザー一覧を至急確認してほしい。身に覚えのない管理者アカウントが追加されている場合は、すでに攻撃を受けている可能性がある。その場合は、プラグインの更新だけでなく、全ユーザーのパスワードリセットや、サイト全体のマルウェアスキャンも併せて実施する必要がある。
この記事のポイント
- WooCommerce Social Login 2.8.7以下にCVSS 9.8の認証バイパス脆弱性が存在する
- AppleログインのIDトークン署名検証が行われておらず、攻撃者が任意のユーザーになりすませる
- 管理者アカウントも標的になるため、ECサイトの全データが危険にさらされる
- 修正版2.8.8への即時アップデートが必須
- すでに攻撃を受けた可能性がある場合は、ユーザー一覧の確認とサイト全体のセキュリティチェックを推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
大量メール配信の落とし穴、800,000通で自社サイトがダウンした理由
2026年、WooCommerce.comが約80万の購読者に向けてニュースレターを一斉配信したところ、わずか数分でサイトがダウンするという思わぬトラブルが発生した。原因は攻撃でもリリースミスでもなく、メール配信そのものだった。配信先に企業向けメールシステムが多く含まれていたため、メールセキュリティスキャナーが一斉にリンク先を自動クロールし、膨大なトラフィックを引き起こしたのである。
この出来事は、当該チームに「大量メール配信はインフラの負荷テストと同義である」という教訓を残した。本記事では、この障害の経緯と原因、そして再発防止策を紹介する。メールマーケティング施策を運営するすべての企業にとって、無視できない警鐘だ。
800,000通のメールで自社サイトがダウン、その経緯
ある日の午前9時15分（UTC）、WooCommerceのチームは約80万人に向けたニュースレター配信を実行した。配信開始からわずか3分後の9時18分、同僚からの「サイトが落ちている」という一報が届く。監視アラートが作動したのはその4分後（9時22分）であり、人が気づく方が先だった。
状況をさらに混乱させたのは、その朝には一切のデプロイがなく、攻撃の痕跡も皆無だった点だ。にもかかわらず、エッジレベルでのリクエスト総数は平時の約25万から急増し、ピーク時には約53万を記録した。実際のダウンタイムは3〜4分程度にとどまった。この短い間に、一部のユーザーには「429 Too Many Requests」が返され、ごく一部で5xx系エラーも発生したが、大多数のリクエストは正常な200応答を返し続けている。つまり「短時間の部分的な停止」であり、それでも立派なインシデントだった。
補足すると、当初のトラフィックグラフでは合計リクエスト数が実際の2倍に表示されるというダッシュボードの不具合が見つかった。後に修正されたが、正しい数字はステータス別の線であり、ピークは約53万、平常時が約25万。いつも通りの約2倍のトラフィックが数分間だけ発生したことに変わりはない。
原因はメールセキュリティスキャナーだった
まず疑ったのは当日のリリースや攻撃の兆候だが、どれも該当しなかった。しかしアクセスログには二つの異様な痕跡が残されていた。
一つは、トラフィック元の大半がデータセンターやVPNのIPアドレスで、実際のショッピング利用者が使うような一般ISPからではなかった点だ。もう一つは「JavaScript ChunkLoadError」の大量発生である。ChunkLoadErrorとは、HTMLだけを取得し、ページのJavaScript（JS）をダウンロードする前に接続が切断された場合に起こるエラーだ。数千回のこのエラーが数秒のうちに集中した。
この断片的な情報をつなぎ合わせると、犯人像が見えてくる。企業向けメールシステム（Office 365やMimecastなど）は、メールが受信トレイに届いた瞬間に、本文中のすべてのリンクを自動的にたどり、マルウェアチェックを行う。受信者がメールを開封する以前に、セキュリティスキャナーがリンク先を叩くのだ。
WooCommerceのニュースレターはストアオーナー向けだったため、送信先には企業ドメインが非常に多かった。80万通を一斉に配信すると、それら企業メールシステムのスキャナー群もほぼ同時に作動し、一瞬のうちに大量のリクエストが殺到した。これがスパイクの正体である。もし同じ配信をGmailが中心の一般消費者向けに行っていれば、このような急増は起きなかっただろう。
なぜ同じ規模の前回は耐えられたのか
実はその1週間前にも、さらに大規模な配信を実施していた。その際にも今回とほぼ同じボットトラフィックのスパイクが発生していたが、誰も気づかないままインフラは何事もなく耐え抜いた。だから今回も「配信量が特に多すぎた」わけではない。
問題は配信のサイズではなく、タイミングだった。前回の配信では偶発的に、ボットの同時接続数がわずかに抑えられたり、キャッシュの状態が良好だったりした可能性がある。今回はほんのわずかな違いが、耐えられる負荷と許容限界との差になった。正確な理由を断定するのは難しいが、一瞬の集中がすべてを変えたことは確かだ。
オートスケーリングが追いつかなかった瞬間
WooCommerce.comはWordPress VIPのホスティング上で稼働しており、オートスケーリングは正常に動作していた。もしトラフィックが徐々に増加するパターンであれば、新しいリソースが立ち上がるまでの数分間で対応できたはずである。実際に追加されたキャパシティが整った頃には、スパイクはすでに通過し、被害も収束していた。
しかし今回の攻撃（自爆攻撃とも言える）は、段階的な増加ではなく「ステップ関数」のような瞬間的な跳ね上がりだった。スケーリングが反応するための傾斜が存在しないため、自動化の仕組みは事実上役に立たなかった。問題はサーバーに到達する前、配信の仕組みそのものにあったのだ。
トラフィックが瞬間的に跳ね上がる一斉配信と、分散されて緩やかな山になるバッチ配信の比較を示した。今回の対策では、後者の方式を採用することでスパイクを回避した。
対策〜バッチ配信でスパイクを防ぐ
次のキャンペーンは、たまたま1週間後のブラックフライデーに予定されていた。チームは全リストを一気に送信するのではなく、数時間かけて小分けにバッチ配信する方式に変更した。利用しているメール配信プラットフォームがこの機能をサポートしているかを事前に確認した上での判断である。
結果は明確だった。バッチ配信へ切り替えた後は、あのスパイクは一切発生しなくなった。追加のサーバーキャパシティは投入しておらず、今後も増強予定はない。オートスケーリングは自然な成長や季節変動を十分に吸収できるが、自ら招く瞬間的な高負荷には対応しきれないからだ。
大規模なマーケティングメールの配信は「インフラに関わるイベント」として認識し、特に最大規模の配信の前にはサーバー運用チームと連携することが推奨される。
大量メール配信は負荷テストである、という教訓
企業向けのメールアドレスを含む大規模リストに一斉配信を行うと、受信者が何もしなくても、配信開始と同時にメールセキュリティスキャナーがすべてのリンクを叩く。これは結果として、自社サイトに対して意図しない大規模な負荷テストを実施しているのと同じだ。
重要なのは、配信停止やメールマーケティングの否定ではない。適切に管理すればニュースレターは強力なチャネルである。ただし、送信ボタンを押す前に「ボットによる一斉アクセスが起こりうる」と想定しておくことが不可欠だ。配信のタイミングを分散するだけでも、今回のような障害は回避できる。
この記事のポイント
- 80万通のメール一斉配信で自社サイトが3〜4分ダウンした
- 原因は企業向けメールセキュリティスキャナーの一斉リンクチェックだった
- 同じ規模の前回は偶然耐えられたが、タイミング次第で失敗しうる
- オートスケーリングは段階的な増加には強いが、瞬間的なスパイクには無力
- 対策として配信を時間差バッチに変更し、再発を防止した
- 大量メール配信は意図しない負荷テストとなりうる、分散配信が鍵
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GKE Agent Sandboxがエージェント1台あたりのコストを75%削減する仕組み
AIエージェントを本番環境でスケールさせようとすると、すぐにコストとリソースの壁にぶつかる。Google Cloudが2026年7月30日に公開したブログ記事では、Google Kubernetes Engine（GKE）の新機能「GKE Agent Sandbox」とオーケストレーションを組み合わせることで、同一の仮想マシン上で動かせるエージェント数を最大3.5倍に増やし、エージェント1台あたりのコストを最大75%削減できるという検証結果が示された。
エージェントは要求に応じて動作するバースト型のワークロードであり、何もしない待機時間が長い。従来のように固定的なコンピュートリソースを割り当てる方法では、遊休状態のエージェントが貴重なCPUやメモリを消費し続けてしまう。この問題に対するGKEのアプローチを詳しく見ていく。
マイクロVM方式の限界とGKE Agent Sandboxの登場
マルチエージェントを安全に動かすための一般的な方法として、各エージェントを専用のマイクロVM（Kata Containersなど）で隔離するやり方がある。ハードウェアレベルの隔離によってセキュリティを確保する狙いだ。しかしこの方式には大きな落とし穴がある。
マイクロVMはエージェントごとにゲストOSを起動するため、メモリとCPUに無視できないオーバーヘッドが生じる。実際にGoogle CloudのチームがOpenClawプロファイルを使い、48vCPUの標準VMインスタンス（n2-standard-48）上でテストしたところ、61個のエージェントを起動した時点で信頼性が低下し、ヘルスチェックの失敗が頻発し始めたという。
これに対してGKE Agent Sandboxは、gVisorというオープンソースのセキュアコンテナサンドボックスを土台にしている。gVisorはユーザー空間カーネル（Sentry）でシステムコールを捕捉・フィルタリングし、ハードウェア隔離に近いセキュリティを実現しつつ、ゲストOSを丸ごと動かす必要をなくした。
結果として、同一VM上で動作可能なエージェント数は88個まで増加。これはベースライン比で44%の密度向上であり、エージェント1台あたりのコストは30%以上削減された計算になる。しかも性能プロファイルはほぼ維持できると報告されている。
この方式が評価を得たのは早く、2026年5月の一般提供開始から4週間足らずで利用量が7倍以上に急増した事実が、その実用性を裏付けている。
遊休エージェントを「凍結」するオーケストレーションの威力
GKE Agent Sandboxは稼働中のワークロードを効率化するが、遊休状態のエージェントがリソースを占有し続ける問題は残る。そこでカギを握るのが、Kubernetes本来のオーケストレーション機能とGKE Podスナップショットを組み合わせた「凍結・再開」パターンだ。
具体的には、エージェントが待機状態に入ったタイミングでPodスナップショットを作成し、永続ストレージにチェックポイント（凍結）として保存する。これにより物理的なCPUとメモリが解放され、クラスタに返却される。新しいトリガーが届くと、軽量なコントローラやイベントゲートウェイがリクエストを捕捉し、ミリ秒単位でスナップショットからエージェントを再開する。
この仕組みによって、物理リソースをワークロードの実態に基づいて「オーバーサブスクライブ（超過割り当て）」できるようになる。つまり、実際の瞬間的な需要以上のエージェントを同じノードに詰め込めるわけだ。その結果、間欠的にしか動かないエージェントであれば、ベースラインの3.5倍にあたる274個のエージェントを単一ノードで動作させることが可能になった。
ただし、やみくもに詰め込めばよいわけではない。エージェントの種類によって求められる起動時間やレイテンシは大きく異なるからだ。
エージェントの特性に合わせた3つのデプロイ戦略
GKEでは、すべてのエージェントに一律の戦略を強制するのではなく、ノードプールやワークロード設定ごとに異なる挙動を共存させられる。Google Cloudのブログでは、レイテンシ要件に応じた3つの典型例が紹介されている。
リアルタイムコーディングアシスタント（レイテンシ重視）
開発者向けの対話型エージェントでは、起動時間が1秒未満であることと、待ち行列が一切発生しないことが絶対条件だ。このケースでは、GKE Podスナップショットと「Agent Sandboxウォームプール」を組み合わせる。事前にウォームアップされた隔離サンドボックスを常時待機させておくことで、ほぼ瞬時に実行を開始できる。この構成で同一ノード上に133個のエージェントを収容できたと報告されている。
自律的なチームメイト型エージェント（バランス型）
バックグラウンドで対話的に動くエージェントは、平均的な起動時間（数秒）を許容できる。サスペンド＆レジューム機能を利用し、遊休時にはリソースを解放、必要時にオンデマンドで復元する。待機中のコンピュートコストを支払う必要はない。
ヘッドレスなバックグラウンドエージェント（レイテンシ許容型）
日次レポートの生成や調査タスクのような定期ジョブは、多少の待ち時間があってもビジネス成果に支障をきたさない。こうしたエージェントには最大限のリソース超過割り当てを適用し、クラスタに空きが出るまで1時間ほど待つ戦略も有効だ。
このように、ワークロードの性質に合わせて「パフォーマンス最適化」と「コスト最適化」のバランスをチューニングできるのがGKEの強みだ。サンダリングハード（多数のエージェントが一斉に起動してコンピュートを要求する問題）に対しても、ウォームプールやサスペンド＆レジュームの設定で自由度の高い制御が可能になる。
コスト削減を実現するための実践的なアプローチ
GKE Agent Sandboxとオーケストレーションの組み合わせによって、エージェントの台数に比例してインフラ予算が増えていく構図を抜本的に変えられる。Google Cloudの検証では、パフォーマンスを重視する構成でも133個のエージェント（ベースライン比約2.2倍）、コスト最適化を突き詰めた構成では274個（同3.5倍）のエージェントを同一ノードで動作させることに成功した。
実務に落とし込む際のポイントは3つある。第一に、セキュリティを保ったままオーバーヘッドを削減するGKE Agent Sandboxへの移行を検討すること。第二に、Podスナップショットによる「凍結・再開」をアーキテクチャに組み込み、遊休リソースを徹底的に活用すること。第三に、すべてのエージェントを同じ扱いにせず、レイテンシ要件に応じてデプロイ設定を変えることだ。
なお、GKE Agent Sandboxの詳細な設定やウォームプール、サスペンド＆レジュームの具体的な手順は、Google Cloudの公式ドキュメントで公開されている。まずは既存のエージェントワークロードを対象に、小規模なPoCから始めてみるとよいだろう。
この記事のポイント
- GKE Agent SandboxはgVisorベースの軽量サンドボックスで、マイクロVMに比べてエージェント密度を44%向上させ、1台あたりのコストを30%以上削減する
- Podスナップショットとサスペンド＆レジュームの組み合わせにより、遊休エージェントを凍結して物理リソースを解放し、理論上3.5倍の密度（最大75%のコスト削減）を達成可能
- ワークロードのレイテンシ要件に応じて「リアルタイム型」「バランス型」「コスト最適化型」の3戦略を使い分けることで、無理なくスケールできる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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が同様の対応をするよりも早く、実際に運用できる段階までこぎつけた。
この接続構成では、Cloudflareがクライアント証明書を提示し、オリジン側でそれを検証することで、なりすましを阻止する。両者とも量子耐性のある署名アルゴリズムだけを信頼するよう設定すれば、ダウングレード攻撃も防げる。
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がネゴシエートされていることをあわせて確認したい。
これらの手順を踏むことで、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サポートなど、エコシステム整備が加速中
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ChatGPTでSupabaseにログイン可能に。ベータ提供が開始
Supabaseは2026年7月29日、ChatGPTアカウントを使ったサインイン機能のベータ提供を開始した。supabase.comのログインページと、デスクトップ、Web、モバイル版のChatGPTプラグインの両方で利用できる。
ChatGPT WorkやCodexで開発プロジェクトを始める場面では、プロンプトとバックエンドの間のアカウント管理がシームレスになる。既存のChatGPTアカウントをそのまま使ってSupabaseアカウントを作成または連携でき、少ない手順でデータベースの準備に移れるようになった。
ChatGPTアカウントでSupabaseにログインする仕組み
GitHubアカウントでログインするのと同じ感覚で、ChatGPTアカウントを認証プロバイダーとして使えるようになる。Supabaseのログインページで「ChatGPT」を選択すると、ChatGPT側の承認画面が表示され、数クリックでダッシュボードにアクセスできる。
このサインインフローにより、初回のアカウント登録からプロジェクト作成までのハードルが大きく下がる。メールの確認リンクを待つステップがなくなり、思考の流れを止めずにバックエンドの準備に入れる。
新規アカウント作成と既存アカウントの自動連携
ChatGPTサインインは、Supabaseをまだ使ったことがない人にも、既にアカウントを持っている人にも対応する設計だ。
- 新規ユーザーの場合、ChatGPTでサインインすると自動的にSupabaseアカウントが作成される。以降はそのChatGPTアカウントのみで管理できる。
- 既存ユーザーの場合、ChatGPTアカウントに登録されているメールアドレスがSupabaseのものと一致していれば、自動的に連携が行われる。新しいアカウントは作られず、既存のSupabaseアカウントにChatGPTがもうひとつのログイン手段として追加されるだけだ。ただし、SSO（シングルサインオン）アカウントはこの自動連携の対象外となり、別管理になる。
ChatGPTがプロジェクトの出発点なら、バックエンドのアカウントも同じ場所から始められる。管理するパスワードがひとつ減り、アカウント管理の手間も軽減される。
ChatGPTやCodexからSupabaseを直接接続する手順
SupabaseをChatGPTに接続する操作は、クリックと承認だけで完了する。認証済みのアカウントを使い、プラグインの追加から接続までが短いステップでまとまっている。
この接続フローは認証と権限付与を明確に分離している。サインインしたあと、改めてプラグインがアクセスできる範囲が表示され、利用者がそれを確認・承認する。承認後に初めてSupabaseがChatGPTの会話に連携される仕組みだ。
許可の管理と取り消し
接続の許可はいつでもSupabaseダッシュボードから取り消せる。プロジェクトの途中で方針が変わっても、ワンクリックでChatGPTからのアクセスを遮断できるため、セキュリティ面でも柔軟に対応できる。
初めてSupabaseを使う場合、ダッシュボードで組織を作成しておく必要がある。組織がひとつでもあれば、その後はChatGPT側からプロジェクトを作成・操作できるようになる。
OpenAIとのパートナーシップで実現
この機能は、Supabaseが「Sign in with ChatGPT」のローンチパートナーに選ばれたことで実現した。OpenAIはサードパーティサービスがChatGPTアカウントを認証に使える仕組みをベータ提供しており、Supabaseはその初期導入企業のひとつにあたる。
日常的にChatGPTやCodexからSupabaseのデータベース構築や認証周りを操作している開発者は多い。今回の統合は、その導線をさらに短くする一手であり、プロンプトから本番稼働までの時間を縮める流れを加速させるものと考えられる。
この記事のポイント
- SupabaseのログインページとChatGPTプラグインで「Sign in with ChatGPT」ベータが利用可能になった
- GitHubログインと同様の操作感で、既存のChatGPTアカウントを使ったワンクリック認証ができる
- ChatGPT側からSupabaseを接続する手順は4ステップ。認証と権限付与が分離され、いつでも取り消し可能
- SupabaseはOpenAIのローンチパートナーとして、この認証機能をいち早く導入した
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google Search Consoleの生成AI検索除外設定 仕組みと判断すべきポイント
Google Search Consoleに、AI OverviewsやAI Modeなど生成AIによる検索機能からサイトを除外できる新設定が追加された。Search Consoleの設定項目に新設されたこのコントロールは、サイト単位でAI検索体験への表示をオフにする一方で、通常の検索結果への影響はないとされる。しかし、実際に使うかどうかの判断は一筋縄ではいかない。Top StoriesがAI Overview内に表示されるケースが増えており、除外設定によって思いがけず貴重な掲載機会を失う可能性が指摘されているからだ。
この記事では、新設定の仕組みと背景、そしてオプトアウトを検討する前に把握しておくべき3つの要素を、データと規制動向を交えて整理する。
生成AI検索除外設定の概要
Search Consoleの「設定」内に追加されたこのコントロールは、サイトのコンテンツをAI Overviews、AI Mode、Discoverの生成AI機能に表示するかどうかを決定する。デフォルトは「サイトを含める」で、AI機能内でリンクとして表示され、AIの回答を裏付ける情報源として使われる。除外を選択すると、リンクや文章を問わず、それらの生成AI領域からサイトのコンテンツが一切表示されなくなる。
設定変更が有効になるまでには通常数日かかり、さらにキャッシュの影響で反映に1〜2日を要することもある。ただし、この設定は通常のウェブ検索結果やランキングシグナルにはまったく影響しないと公式ヘルプページで明言されている。また、Merchant CenterやGoogle Adsの参加設定を上書きするものではなく、ショッピング関連の表示とは独立した判断になる。さらに、AIの学習データとしての利用を制御する仕組みとは別物であり、そちらは別のオプトアウト（Google-Extended）を経由する。
CMAの関与と設定誕生の経緯
この除外設定が実装された背景には、英国の競争市場庁（CMA）による規制がある。今年に入るまで、AI検索機能だけを対象にサイトを除外する手段は存在しなかった。従来使えたnosnippetはスニペットを非表示にするが、同時にAI Overviewsの表示も奪うオールオアナッシングだったし、Robots.txtはクロール制御に過ぎず、インデックス済みコンテンツの表示可否は決められない。Google-ExtendedはGeminiモデルの学習や一部のグラウンディングを制御するが、AI Overviewsへの表示には関与しなかった。
状況が動いたのは今年1月だ。GoogleがAI検索機能のオプトアウト手法を検討中と発表したのと同日に、CMAが事業者へのAIオプトアウトを義務付ける協議を開始した。そして6月、CMAは生成AIをめぐるコンテンツ使用に関する「行為要件」を課し、Googleは同一週に英国のプロパティで設定のテストを開始した。現在、この要件は英国でのみ法的拘束力を持ち、より詳細な制御の導入期限は来年まで延びている。
Top StoriesとAI Overviewの融合がもたらすジレンマ
Googleの説明では、この設定はAI機能と通常の検索結果を別物として扱う。しかし実際の検索画面では、その境界が曖昧になりつつある。トレンドのニュース検索で、従来は独立して表示されていたTop Storiesのカルーセルが、AI Overviewの枠内に埋め込まれるケースが増加しているのだ。
SEO分析ツールを提供するNewzDashの調査によると、米国でトレンドニュースクエリを追跡した結果のうち15.5%、英国では17.46%で、Top StoriesがAI Overview内に表示されていたという。NewzDashのCEOであるJohn Shehata氏は、この現象について「新しいSearch Consoleの生成AI除外設定を使うと、AI Overview内のTop Storiesからもパブリッシャーが除外される可能性が高い」とLinkedIn上で指摘している。ワシントンポストのSEO責任者Kyle Sutton氏も、自身の観測として同様の傾向を確認しているとコメントしている。
ただし、この解釈はあくまでShehata氏の見解であり、Googleが公式に認めたものではない。公式ヘルプページには「除外されたサイトはAI機能に表示されなくなる」とあるが、AI機能の内部に組み込まれた伝統的な機能についての挙動は明記されていない。つまり、除外設定をオンにすると、AI Overviewsの魅力を削ぐだけでなく、これまでAI機能とは別に獲得していたTop Storiesの露出まで手放すリスクがある。軽々に設定を切り替えられない理由はここにある。
オプトアウト判断前に確認すべき3つの要素
1. AI機能での現在の表示状況を把握する
まず自社サイトがAI機能でどれだけのインプレッションを得ているかを確認する。Search Consoleには「生成AIパフォーマンスレポート」が順次ロールアウトされており、ページ別、国別、デバイス別のインプレッション数が確認できる。ただし、このレポートにはクリック数や検索クエリのデータは含まれていない。Googleアナリティクスなどの一般的な分析ツールでも、流入をAI Overviewsと通常の検索に切り分けることはできない。現状では、AI機能経由のトラフィックを正確に把握できない点を認識しておく必要がある。
2. 各制御ツールの役割を整理する
除外に関する判断を混乱させるのが、類似した複数のコントロールが存在していることだ。どのツールが何を制御するのか、違いを正しく理解しておきたい。
ポイントは、このSearch Consoleの設定がAI機能の表示だけを扱う点だ。これに対して、Google-Extendedはモデルの学習やグラウンディングに特化しており、検索結果の表示可否には関与しない。複数のレバーがあるからこそ、意図しない情報コントロールを避けるためには、それぞれの適用範囲を正確に把握しておく必要がある。
3. ビジネスへの影響を慎重に評価する
除外がもたらす影響は業態によって異なる。ニュースメディアにとっては、AI Overview内のTop Stories露出が収益源のひとつになり得る。ECサイトであれば、サイトコンテンツの表示とショッピング枠への参加は独立した意思決定であるため、除外設定が直接的に商品表示を消すわけではない。ただ、いずれの事業者にとっても共通するのは、AI機能での表示が代替しているトラフィックの規模を正確に評価する手段が今のところ存在しないという事実だ。
CMAの要件では、クリックデータやクリック率といった指標が提供される予定で、その多くは今年12月から順次展開される見通しである。だが現時点では、AI機能へのオプトアウトがもたらす具体的なコストを数字で判断できない。データがない段階での切り替えは、将来の規制対応を先取りする戦略的判断か、あるいは様子見のリスク回避か、経営方針と照らし合わせながら決めるしかない。
今後の展開と欠けているピース
CMAのスケジュールでは、より詳細なページ単位の除外設定が2027年3月までに導入されることになっている。また、Googleは検索コンソールを通じてクリックデータやクリック率を共有し、パブリッシャーがその数字を評価できるツールを提供する必要がある。さらに、初年度は半年ごとに、その後は状況が落ち着けば年次で、コンプライアンス状況の報告が求められる。
一方で、このような規制によって本当にパブリッシャーの利益が守られるのか疑問視する声もある。オックスフォード大学の研究者Spencer Cohen氏とUCLのTodd Davies氏は、学術誌に寄稿した論文の中で「オプトアウトの救済策では不十分」との見解を示している。Davies氏は過去にGoogleでソフトウェアエンジニアとして勤務した経歴を持ち、LinkedIn上でも「オプトアウトはAI Overviewsが引き起こす問題を解決せず、パブリッシャーのビジネスモデルを保護する効果は限定的だ」と述べている。
結局のところ、今はコントロールが与えられたが、その操作に必要なデータはまだ揃っていない。NewzDashは近日中に除外効果の直接テストを実施すると予告しており、近いうちに実際の影響を測る材料が増える可能性はある。当面は、設定の存在を認識しつつ、運用判断はクリックデータの提供開始後まで保留する、あるいは試験的に一部のプロパティで効果を観察するといった現実的なアプローチが求められるだろう。
この記事のポイント
- Search ConsoleにAI Overviews等の生成AI検索機能からサイトを除外する新設定が追加された。通常の検索結果には影響しない
- 英競争市場庁（CMA）の要請により導入され、現在はサイト単位でのみ制御可能。ページ単位のコントロールは2027年3月までに実装予定
- Top StoriesがAI Overview内に表示されるケースが15〜17%存在し、除外によってそれらの露出も失うリスクがある
- 現状ではAI経由のトラフィックやコンバージョンを切り分けるデータがなく、オプトアウトの損得を数値で評価することはできない
- Google-ExtendedやRobots.txtなど類似の制御ツールとの違いを理解し、本来の意図に合った設定を行う必要がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GPT-5.6 API料金改定、Lunaは80%値下げでTerraも20%減。Fastモード登場
OpenAIは2026年7月30日、大規模言語モデル「GPT-5.6」シリーズのAPI料金を大幅に引き下げた。最速かつ最安価なモデル「Luna」は80%値下げされ、バランス型の「Terra」も20%安くなる。あわせて最上位「Sol」向けにFastモードも導入され、標準処理の最大2.5倍の速度を提供する。
これらの改定は、OpenAIが掲げる「高度な知能をより豊富で手頃なものにする」という目標の実践だ。企業はコストと処理速度をワークフローごとに最適化できるため、AI利用の幅が大きく広がる。
GPT-5.6 LunaとTerraの大幅値下げ
今回の値下げの中心は、高速処理向けのLunaだ。LunaはAPI料金が80%引き下げられ、100万入力トークンあたり0.20ドル、同出力トークンあたり1.20ドルという破格の水準になった。一方、日常的な業務全般に使えるTerraは20%値下げされ、入力トークン100万あたり2ドル、出力は12ドルとなっている。
この値下げによって、Lunaは1タスクあたりのコストが非常に低くなり、大量処理に適したモデルへと進化した。OpenAIのブログによれば、専門的な作業指標で測った場合、同社の旧モデルFable 5と比べてLunaの推定タスク単価は99%近く低いという。小規模事業者が高度なAIを日常的に使うハードルが格段に下がったと言える。
FastモードでSolが最大2.5倍高速化
最上位モデルのGPT-5.6 Solには、新たにFastモードが追加された。これは従来の優先処理（Priority Processing）を置き換えるもので、APIでFastモードを有効にすると、標準処理の最大2.5倍の速度で応答が得られる。価格は標準の2倍だが、知能の質はまったく変わらない。既存の優先処理指定リクエストは自動的にFastモードに移行するため、コードの修正は不要だ。
応答速度が重要な場面、たとえばユーザー向けのリアルタイムチャットボットや緊急度の高い意思決定支援などで効果を発揮する。一方で、コストが2倍になるため、処理の内容に応じて標準モードとの使い分けが鍵になる。OpenAIはこの仕組みによって、企業が「結果に対して適正な価格を払う」バランスを取りやすくしたとしている。
効率化を支えるモデル自身の最適化ループ
今回の値下げを支えているのは、GPT-5.6シリーズの稼働効率の劇的な向上だ。OpenAIはモデルそのもの、推論システム、そしてツールやコンテキストを扱うエージェント機構のあらゆる層で改良を重ねた。より直接的な処理経路の選択、ハードウェア生産性を維持するルーティング、トークン生成の最適化、重複作業を避ける賢いコンテキスト管理などが組み合わさり、同じ計算資源でより多くの有用な成果を出せるようになっている。
とりわけ注目されるのが、Sol自身が効率改善のプロセスに貢献した点だ。人間の管理のもと、Solは本番カーネルを自律的に書き換えて最適化し、トークン生成効率を高める数百の実験を設計・実行した。この取り組みによって、モデル提供にかかるエンドツーエンドのコストが20%削減され、トークン生成効率は15%以上向上した。AIがAIの運用コストを下げるフィードバックループが動き始めている。
こうした自己最適化のループは、OpenAIが目指す「インテリジェンスの価格性能比を継続的に向上させる」戦略の中核をなす。モデルが賢くなるほど、次の効率化のサイクルが加速するというわけだ。
企業がAI活用を進める際の新たな選択肢
LunaとTerraの値下げ、そしてSolのFastモードの登場によって、企業がワークフローごとに最適なモデルを選べる幅が大きく広がった。コストと速度、知能のバランスをタスク単位で調整できるようになったことで、AIの適用範囲を無理なく拡大できる。
たとえば、コード生成のワークフローを考えてみる。要件が曖昧で高度な判断が必要な設計段階ではSolを使い、確定した仕様に沿ったコード実装やテストの実行は低コストのLunaに任せる、といった割り振りが現実的になる。ドキュメントの大量分析や顧客対応の振り分けといった高頻度の業務も、Lunaを活用すれば予算内に収めやすい。
このように、単一のモデルですべてをこなすのではなく、処理の性質と求める品質に応じて使い分ける設計が、これからのAI戦略の基本になるだろう。SolのFastモードは、応答速度が収益に直結する顧客向けサービスなどで即効性が期待できる。
OpenAIのブログによれば、今回の改定によって、1年前に最先端とされたモデル並みのパフォーマンスをLunaで1タスク約6%のコストで実現できるという。AI活用が一部の専門領域から、あらゆる業務の日常ツールへと移行する大きな一歩だ。
この記事のポイント
- GPT-5.6 LunaのAPI料金が80%値下げされ、100万入力トークンあたり0.20ドルに。Terraも20%引き
- Sol向けFastモードが追加され、標準の最大2.5倍の速度を2倍の価格で提供
- 値下げの背景には、Sol自身がカーネル最適化などで推論コストを20%削減した成果がある
- 企業はタスクの難易度や処理量に応じてLuna、Terra、Solを柔軟に組み合わせ、コストと品質を両立できる
- ChatGPT WorkやCodexのサブスクリプション価格は据え置きのまま、LunaとTerraの消費クレジットが減少
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Shopify×Vercel、Hydrogenフレームワークを再構築。マルチフレームワーク対応とAIエージェント導入
ShopifyとVercelが、ヘッドレスコマースフレームワーク「Hydrogen」の全面的な再構築に着手した。2026年7月30日にVercel Blogが発表した内容によると、新バージョンはオープンソース化され、Next.js以外のフレームワークでも動作するランタイム非依存型へと生まれ変わる。
この刷新により、開発者は型安全なAPIクライアントやカート状態管理をワンインポートで利用でき、ストアフロントの構築が大幅に効率化される。さらに「Standard Actions」と呼ばれるエージェント型コマース機能が追加され、AIが購入支援や在庫確認などを自律的に処理する仕組みが提供される。
Hydrogenとは何か？
HydrogenはShopifyが提供するヘッドレスコマース専用のフロントエンドフレームワークだ。従来のShopifyストアはテーマで構築するが、Hydrogenを使うとReactコンポーネントで自由にカスタマイズした店舗を開発し、Shopifyのバックエンドとシームレスに連携できる。つまり「自由な画面デザイン」と「Shopifyの堅牢なバックエンド」を両立させる架け橋と言ってよい。
これまでHydrogenはNext.jsに最適化された形で展開されていたため、開発者はReact/Next.jsのエコシステムに縛られていた。NuxtやSvelteなど別のフレームワークを使う場合は、独自にAPI連携や状態管理を実装する必要があり、それが導入障壁になっていた。
何が変わるのか？
今回の再構築では、Hydrogenの根本的な設計が刷新される。具体的には以下の3つの大きな変化がある。
この比較から分かる通り、新しいHydrogenではフレームワークの選択肢が広がり、面倒な共通処理はフレームワークが肩代わりしてくれる。結果として、開発者はビジネスロジックに集中できる。
オープンソース化とランタイム非依存
最大の変更点は、Hydrogenが完全オープンソースになり、ランタイムにも依存しなくなったことだ。旧バージョンは実質的にNext.jsアプリとして動作する設計だったが、新しいHydrogenは@shopify/hydrogenパッケージをブラウザ用JavaScriptで動作するように再実装し、@shopify/storefront-api-clientと共に利用する形になる。
これにより、開発者はNext.jsはもちろん、Nuxt、SvelteKit、あるいは純粋なViteアプリケーションなど、好みのフレームワーク上でHydrogenストアフロントを構築できる。Vercelの発表ブログでは「cart.query()やcart.lineItems()といったAPIをインポートするだけで、カートの操作や状態管理が完了する」と説明されており、従来のようにフレームワークごとに接着コードを書く手間が不要になる。
標準Actionsとエージェントコマース
もうひとつの目玉は「Standard Actions」の導入だ。これはAIエージェントがショッピング行動を自立支援するための統一インターフェースであり、店舗の様々な操作（検索、商品詳細の取得、カート追加、購入）をアクションとして定義する。
ユーザーが自然言語で要望を伝えると、AIエージェントが最適なアクションを選択して結果を返す。この仕組みを利用すれば、「オススメの夏用ジャケットを見せて」「先週買おうとした商品をカートに戻して」といった会話型の購買体験をストアフロントに組み込める。
Standard Actionsは、AIモデルが商品データや在庫情報にアクセスしやすい形で提供されるため、自前で複雑なAIパイプラインを構築する必要がない。ChatGPTやClaudeといった外部AIと統合する場合も、アクション定義を合わせるだけで済む設計だ。
なぜこのパートナーシップが重要なのか
ShopifyとVercelの連携強化は、単なるコードのリファクタリングではない。ここには二つの大きな戦略的意義があると考えられる。
一つは「Shopifyのバックエンドをあらゆるフロントエンドから利用可能にする」という方向性だ。ヘッドレスコマース市場では、各ブランドが独自のデザインシステムや技術スタックを持つことが当たり前になってきた。Hydrogenがランタイム非依存になることで、React以外のスタックを使っている企業も無理なくShopifyに移行できるようになる。
もう一つは「AI時代のコマース体験の標準化」だ。Standard Actionsは、AIエージェントが安全かつ一貫した方法で店舗操作を行えるプロトコルを定義する。これが広く採用されれば、どんなストアフロントでも同じ仕組みでAIアシスタントを動かせるようになるため、エコシステム全体のAI対応速度が上がる。
さらに、オープンソース化によってコミュニティの貢献が期待でき、Hydrogen自体の開発スピードも加速する。プラットフォームに閉じない設計は、長期的なベンダーロックインの回避にもつながる。
実務への影響と開発スピード
Vercel Blogの記事では、ファッションブランド「Paige」の事例が紹介されている。新しいHydrogenを採用した結果、それまで数か月かかっていた新機能の開発が1週間に短縮されたという。これは単にコード量が減っただけでなく、標準化されたAPIクライアントと状態管理によって、チームが細かい実装に悩まなくなり、ビジネスロジックの試行錯誤に集中できるようになった成果だ。
中小規模のECサイト運営者にとっては、これまで「ヘッドレス」と聞くだけで専門のReactエンジニアが必要だと思われていた壁が下がる。HydrogenがNuxtやSvelteでも動くため、社内のフロントエンドチームが使い慣れたフレームワークをそのまま活かせる。さらに型安全なクライアントが用意されているため、APIの仕様変更に伴う不具合もコンパイル時に検出しやすくなる。
パフォーマンス面でも、ランタイムの最適化が進んだことで、ストアフロントの表示速度が向上する。Vercelのエッジネットワークとの組み合わせにより、世界中のユーザーに高速な体験を提供できるのも大きな強みだ。
この記事のポイント
- Hydrogenがオープンソースかつランタイム非依存となり、Next.js以外のフレームワークでも動作する
- 型安全なAPIクライアントとカート状態管理が標準提供され、開発効率が飛躍的に向上する
- Standard Actionsによって、AIエージェントが自然言語でショッピングを支援する仕組みが組み込まれる
- ファッションブランド「Paige」では開発期間が数か月から1週間に短縮された事例が報告されている
- 中小規模のECサイトでも、ヘッドレスコマースの導入ハードルが大きく下がる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1ベータ公開、ノート機能の大幅強化とCSS不要のレスポンシブ編集
WordPress 7.1のベータ版が7月下旬に公開され、編集体験に大きな改善が盛り込まれた。ノート機能がチームでの共同編集に本格対応し、CSSを一行も書かずに端末ごとの見た目を調整できるようになる。正式版はWordCamp USが開催期間中の8月19日にリリースされる予定だ。
今回の目玉は「ノート機能の強化」「レスポンシブスタイリング」「ホバーやフォーカス状態の視覚編集」の3本柱である。さらに、かねてから要望の多かったタブブロックとプレイリストブロックが追加され、管理画面の使い勝手も向上する。テスト段階のため本番環境への適用は避ける必要があるが、正式版までに知っておきたいポイントを詳しく見ていこう。
ノート機能がチーム編集ツールに進化
WordPress 6.9で導入されたノート機能は、ブロック単位の簡素なコメント機能だった。WordPress 7.1ではそれが一変し、複数人でのフィードバックに耐える本格的なツールへと変わる。
@メンションで担当者を直接指名
ノートの入力欄で「@」を打ち込むと、サイトの共同編集者の一覧が検索候補として表示される。目的のメンバーを選択すれば、その人を指名したノートが作成される。これにより「この修正は誰に伝えればいいのか」という迷いがなくなり、チーム内でのやり取りが格段にスムーズになる。
インラインノートで誤解を減らす
これまでのノートはブロック全体に対してしか付けられなかったため、長文の中で「ここを直してほしい」と書いても具体的な箇所が伝わりにくかった。WordPress 7.1では、文章内の特定の語句や文を選択し、その部分だけにノートを付けられる。該当部分はハイライト表示されるため、どの言葉に対する指摘なのかが一目でわかる。WP Beginnerの記事でも「『この部分を言い換えてほしい』という指示が、長い段落の中のどの単語を指すのかを推測する必要がなくなった」と評価されている。
このように、修正箇所と指示がピンポイントで結びつくため、レビューにかかる時間が劇的に短縮される。
その他の改善点
- 同じブロックに対して複数のノートスレッドを立てられる。議題ごとに会話を分離できる
- ノート本文に太字、斜体、コード、リンク、絵文字を使ったリッチテキストが可能
- 長いノートは初期状態で折りたたまれ、サイドバーが散らからない
CSS不要のビジュアルスタイリングが編集画面で完結
WordPress 7.1で最もインパクトが大きいのが、レスポンシブデザインのビジュアル操作である。これまではスマホやタブレット用の見た目を調整するには、CSSメディアクエリを手書きするか、テーマの設定に頼るしかなかった。今回のアップデートで、ブロックエディタ上でプレビューを切り替えながら、直感的にスタイルを設定できるようになる。
端末別のスタイル設定
エディタ上部のプレビュー切り替えで「デスクトップ」「タブレット」「モバイル」を選択すると、以降のブロックスタイルの操作はその画面サイズにだけ適用される。たとえばモバイル表示を選んで見出しのフォントサイズを小さくすれば、実際のスマホでの表示だけが変わる。デスクトップ表示には影響しない。
さらに、ブロック設定パネルには、現在どの画面サイズを編集中かを示す小さなバッジが表示される。意図しない画面用のスタイルを上書きしてしまうミスを防げる。エディタキャンバス自体も、プリセットの3サイズに縛られず、横幅をドラッグして任意の幅での表示をリアルタイムに確認できるようになった。テーマがtheme.jsonで独自のブレイクポイントを定義していれば、その値に合わせたプレビューも可能である。
CSSを書く必要がなくなり、カスタマイズのハードルが大きく下がる。サイト全体に一括適用したい場合は、グローバルスタイルで設定し、変更内容を選択的にグローバルへ反映させることもできる。
ホバーやフォーカス状態も視覚的に編集
ボタンなどのブロックには新たに「状態」ドロップダウンが追加され、ホバー時やフォーカス時、アクティブ時の見た目をエディタ上で直接編集できる。背景色や枠線、テキスト色を状態ごとに変え、その場でプレビュー確認できる。これまではほんの小さな変更であっても、カスタムCSSを追加せざるを得なかったが、今後は組み込みのデザインオプションで完結する。
待望のタブブロックとプレイリストブロック
これまでプラグインで実装していたタブ切り替えのレイアウトが、ついにコアブロックとして導入される。また、音声ファイルをまとめて再生できるプレイリストブロックも新登場する。
タブブロック
商品の仕様、よくある質問、料金プランの比較など、情報をパネルで区切って見せたい場面で重宝する。クリックでパネルを切り替える形式で、長いページを避けたい場合に効果的だ。既存のプラグインで作成したタブは、自動的にはコアブロックに変換されないため、移行の際は手作業が必要になる点に注意しておきたい。
プレイリストブロック
複数の音声ファイルを一つのプレイヤーにまとめ、タイトルやアーティスト名、カバーアート、波形グラフィックとともに表示できる。ミュージシャンや教会、教育機関、ポッドキャスト運営者にとっては、エピソードをまとめて提供するのに理想的なブロックだ。WordPressだけで手軽に音声配信の体裁を整えられるようになる。
加えて、既存のブロックにも多くの改善が加わっている。背景グラデーションと画像の同時適用、テキストシャドウのtheme.json対応、HTMLブロック内でのブロックネストの編集、装飾画像をスクリーンリーダーに読み上げさせない設定、ショートコードのEmbedブロックへの自動変換、ColumnsやGalleryからのグリッドレイアウト変換、アイコンブロックの回転・反転・アイコンセット登録機能など、日常的な制作を後押しするアップデートが多数含まれている。
画像編集とメディア処理の刷新
WordPressに組み込まれている画像編集機能が大幅に変わる。従来の狭いインライン操作から、専用のモーダルウィンドウでの本格的な編集へと進化した。
専用の画像編集モーダル
画像ブロックの「切り抜き」ボタンを押すと、フルスクリーンに近い編集画面が開く。自由トリミング、アスペクト比のプリセット、回転・反転、メタデータの編集を一か所で行える。カバーブロックにも対応しており、背景画像をその場でトリミングできる。本格的な写真編集ソフトには及ばないものの、サイト運営者が日常的に行う作業としては十分な機能を備えている。
ブラウザで画像を前処理しHEICにも対応
WordPress 7.1では、画像のリサイズや圧縮、サムネイル生成の大部分を、アップロード前にブラウザが処理する仕組みが導入される。これにより、サーバーの負荷が大幅に減り、低スペックなホスティング環境でもアップロードエラーが起きにくくなる。
さらに、iPhone標準の画像形式であるHEICをはじめ、UltraHDR、AVIF、WebPといった最新フォーマットへの対応が強化される。これまではサーバー側のImageMagickのバージョンに依存してHEICの変換が失敗することがあったが、ブラウザが変換を担うことで環境を選ばずに済むようになる。なお、ChromeとEdgeではフル機能が利用でき、Safariでは一部がサーバー処理に委ねられ、Firefoxでは従来通りサーバー側で処理される。
アップロードの堅牢性と細かな改善
アップロード中にネットワークが切断されても、キューが自動で一時停止し、再接続後に中断したところから再開される。一括アップロード時には進行状況が表示される。このほか、投稿に添付された画像を自動で引っ張ってくる動的ギャラリーモード、投稿専用の「添付画像」セクションがインサーターに追加され、メディアライブラリは自動読み込みの無限スクロールに対応する。日々のメディア管理のストレスを確実に減らす改良が詰め込まれている。
管理画面と編集体験の快適化
WordPress 7.1では、編集画面と管理画面の連携を改善する数々の小さな改良も施されている。
管理ツールバーが常に表示される
ブロックエディタやサイトエディタで編集しているときも、管理ツールバーが非表示にならず、画面上部に固定される。これにより、作業中でもサイトの管理メニューに素早くアクセスできる。ツールバーそのものもデザインが整理され、戻るボタンがわかりやすい山形アイコンに変更され、サイトアイコンと丸いプロフィールアバターが表示される。アイコン類も旧来のDashiconsからモダンなSVGに置き換わった。もちろん、集中執筆モードではツールバーが隠れるため、文章だけに集中したい場合も安心だ。
コマンドパレットとアイデンティティ設定の進化
コマンドパレット（Ctrl+K / Command+K）は、最近使ったコマンド、一致する候補、おすすめの3つに分類されるようになった。利用履歴はログインをまたいで保存されるため、よく使う操作に素早くたどり着ける。サイトエディタのサイドバーも、ユーザーが選んだ管理画面のカラースキームを反映するようになり、全体的な統一感が増した。
サイトのタイトル、キャッチフレーズ、ロゴ、サイトアイコンといった基本情報は「デザイン」内の「アイデンティティ」セクションにまとめられ、設定画面とテンプレートを行き来する手間がなくなった。
「あの日何を書いたか」ウィジェットとコメント親変更
ダッシュボードに新たに「On This Day」ウィジェットが追加され、過去の同じ日に公開した記事を表示してくれる。長く続けているブログにとっては、更新のネタを見つけるきっかけになる。また、コメント編集画面では「どのコメントへの返信か」を後から変更できるようになり、誤って違うスレッドにぶら下がったコメントを正しい位置に付け替えられる。対象は同一投稿内に限られるが、コメント管理の柔軟性が向上した。
見送られた機能と開発舞台裏
今回のリリースには含まれなかったが、注目すべき開発項目がいくつかある。
リアルタイム共同編集は次期以降に持ち越し
Googleドキュメントのような複数人同時編集は、WordPress 7.1では搭載が見送られた。Gutenbergプラグイン上では既に動作しており、複数人が同じ投稿を同時に編集できる段階にある。しかし、コアチームは協調編集データの保存方法や、完全な機能を提供するか基盤だけを先にリリースするかといった重要な判断を続けている。コミュニティによるテストも継続中で、時期尚早な投入によるデータ消失リスクを避けるための慎重な判断と見られている。WP Beginnerの記事でも「作業内容を失う共同編集機能ほど最悪なものはない」と指摘されており、この慎重さは妥当だろう。
Unicodeメールアドレス対応も見送り
日本語などの非ラテン文字を含むメールアドレスへの対応も、ベータテスト中に課題が見つかり延期された。互換性とセキュリティの検証をコミュニティプラグインで続けた後、改めてコアへの導入を目指す方針だ。
パフォーマンスと開発者向けの内部改善
投稿エディタは常にiframe内で動作するようになり、管理画面のCSSによる表示崩れを根本的に防ぐ。ただし、旧APIで作られたブロックは影響を受ける可能性があるため、プラグイン開発者はBlock API v3への移行が推奨される。アイコンAPIが公開され、プラグインやテーマが独自のSVGアイコンセットを登録・レンダリングできるようになった。そのほか、デザインシステムの成熟や、外部サービス接続の認証方式拡充など、長期的な安定性と拡張性を見据えた改良も進められている。
この記事のポイント
- ノート機能に@メンションとインラインノートが追加され、チームでのフィードバックが格段に正確になった
- レスポンシブスタイリングとホバー・フォーカス状態の編集がCSS不要で行える
- タブブロックとプレイリストブロックがコアに加わり、コンテンツ表現の幅が広がった
- 画像編集モーダルとブラウザベースの画像処理で、メディアまわりの操作性と安定性が向上
- 管理ツールバーの常時表示やアイデンティティ設定の集約など、管理画面の使い勝手が改善された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0でAIプラグインを作る！Abilities APIとAI Client連携の実際
WordPress 7.0から導入された3つのAI関連コンポーネント、Abilities API、AI Client、そしてMCP Adapterがプラグイン開発の風景を大きく変えようとしている。これらを組み合わせると、AIが画像を解析し、自動で記事を生成するプラグインを驚くほど少ないコードで実装できる。
本記事では、実際に「Photo to Post」というプラグインの構築を通して、各APIの役割と連携方法を具体的に解説する。WordPressの管理画面から画像URLを入力するだけで、AIがビジョンで内容を理解し、下書き投稿を自動生成する流れを追いながら、新しい開発スタイルの全体像をつかんでほしい。
情報源はWordPress Developer Blogのチュートリアル「Build your first AI-Powered WordPress plugin」（2026年7月30日公開）だ。ここで示されるコードと設計思想は、今後のWordPressエコシステムにおけるAI統合の方向性を色濃く反映している。
新しいAI開発基盤の3要素
WordPress 6.9以降で整備されたAbilities API、7.0で正式に取り込まれたAI Client、そしてMCP Adapterは、それぞれ独立して使えるが、組み合わせることで真価を発揮する。まずはこの3つの役割を押さえておく。
Abilities API
Abilities APIは、プラグインが提供する機能を「能力」として登録し、REST APIやAIエージェントなどが統一された方法で発見・実行できる仕組みだ。入力スキーマ、出力スキーマ、パーミッションコールバック、そして実処理を行うコールバックを定義する。これにより、従来のようにエンドポイントを個別に実装する手間が省け、一度登録した能力が管理画面・REST・MCP経由でそのまま利用可能になる。
WordPress AI Client
AI Clientは、プロバイダー（OpenAI、Anthropic、Googleなど）に依存しないPHPライブラリだ。プラグインコードはwp_ai_client_prompt()というフルーエントなビルダーでプロンプトを組み立て、テキスト生成やファイル送信を依頼するだけでよい。プロバイダーの切り替えは管理画面のConnectors API（後述）でAPIキーを設定するだけで済み、コードを一切変更する必要がない。
MCP Adapter
MCP（Model Context Protocol）は、AIエージェント（デスクトップアプリやVS Code拡張など）が外部ツールを呼び出すための標準プロトコルだ。MCP Adapterプラグインをサイトにインストールすると、登録したAbilityがMCPツールとして自動公開される。ClaudeやChatGPTなどのAIクライアントにWordPressの機能を認識させ、「この画像から投稿を作成して」と自然言語で指示するだけで、プラグインの能力が裏側で呼び出される。
同じ能力が3つの入口からシームレスに使える
上の図はAbilities APIの最大のメリットを示している。一度登録すれば、UI、REST、AIエージェントのどこからでも同一の能力を実行できる。エンドポイントごとに別の処理を書く必要はない。
プラグイン「Photo to Post」の仕組み
チュートリアルで構築する「Photo to Post」は、画像URLを入力するとAIが画像の内容を解析し、その説明文をもとにブログ投稿用のタイトルと本文を生成、さらにその画像をアイキャッチに設定した下書き投稿を作成するプラグインだ。
内部では、3つのAbilityが連携している。ここで重要なのは、最後の能力が他の能力を呼び出す「能力の合成（composition）」を実践している点だ。
この合成パターンは、WordPressのフィルターフックやアクションフックで築かれた「小さな機能を組み合わせて大きな機能を作る」という哲学のAI時代バージョンといえる。
実装の流れを追う
ここからはチュートリアルの主要な実装ステップを、要点を絞って解説する。すべてのコードはスタータープラグインをベースにしており、TODOコメントを置き換える形で進められる。AIプロバイダーとしてはOpenAI、Anthropic、Google Geminiなどが利用可能だ。
AIプロバイダーとの接続
WordPress 7.0では、設定メニューに「コネクター」画面が追加された。Connectors APIによって、各プラグインはAPIキーの保存場所を一元管理できる。従来はプラグインごとに設定ページでキーを管理する必要があったが、これで1箇所に集約される。
OpenAI、Anthropic、Googleの公式プロバイダープラグインをインストールし、コネクター画面でAPIキーを登録すれば、あとはAI Clientが自動的にそのプロバイダーを使う。ビジョンモデルを使う場合は、Anthropicのように画像をBase64で送る必要があるが、AI Clientが吸収するためコード上の差異はほとんど生じない。
能力の登録
Abilities APIにおける能力の登録は、wp_register_ability()関数にラベル、説明、入出力スキーマ、パーミッション、コールバックを渡すだけだ。ここで定義したスキーマが、RESTやMCP経由で能力を呼び出す際の「説明書」になる。
チュートリアルでは、describe-image（画像URL → テキスト説明）、generate-post-from-description（説明文 → 投稿タイトルと本文）、create-post-from-photo（画像URL → 下書き投稿）の3つを登録する。
能力を登録したら、wp_abilities_api_initアクションにフックし、RESTで表示するためにメタ情報にshow_in_rest => trueを指定する。これだけでアプリケーションパスワードを使ったcurlで能力の一覧を取得できる。
AI Clientによる画像解析とテキスト生成
最初の能力describe-imageのコールバックでは、wp_ai_client_prompt()でプロンプトを構築し、with_text()とwith_file()で画像のデータURIを渡してgenerate_text()を呼ぶ。戻り値はWP_Errorの可能性があるため、必ずチェックする。
画像はwp_remote_get()で取得しBase64エンコードしたデータURIにして送る。これにより、URLでの画像指定を受け付けないプロバイダーでも動作する。
2つ目の能力generate-post-from-descriptionでは、AIに「画像説明文から魅力的なブログ投稿を生成し、JSONで返す」よう指示する。プロンプトには「markdownコードフェンスで囲まない」と明示するが、AIは非決定論的なため、念のためpreg_replace()でフェンスを除外し、JSON文字列の中からオブジェクトを抽出する防御的なパース処理を入れている。
能力の合成
3つ目の能力create-post-from-photoがこのプラグインの心臓部だ。ここでwp_get_ability()を使って自分自身以外の能力を取得し、execute()で実行する。最初にdescribe-imageを実行して画像説明を取得し、次にその説明を使ってgenerate-post-from-descriptionを実行、最後に得られたタイトルと本文からwp_insert_post()で下書きを作成する。
このように、能力を「LEGOブロック」のように組み合わせられることがAbilities APIの真骨頂だ。各能力は単独でテスト可能であり、後から新しい能力を追加して組み合わせることも容易である。
管理画面の拡張
スタータープラグインに付属するDataFormベースの設定画面を、実際の能力と連携させる。JavaScript側からは@wordpress/abilitiesパッケージのgetAbility()とexecuteAbility()を使い、先ほどPHPで登録したcreate-post-from-photo能力を呼び出す。
スクリプトをモジュールとして読み込み、readyプロミスでAPIが利用可能になるのを待ってから実行する。これで管理画面から画像URLを入力し「投稿を生成」ボタンを押すだけで、一連のAI処理が走り、下書きが作成される。成功すると編集画面へのリンクが表示される。
MCP対応でAIエージェントにも開放
能力の登録時にメタに'mcp' => array( 'public' => true )を追加し、MCP Adapterプラグインを有効化するだけで、その能力がMCPサーバー経由で外部AIエージェントに公開される。
例えばClaudeデスクトップアプリの設定ファイルにWordPressサイトのURLとアプリケーションパスワードを記述すれば、「この写真から投稿を作成して」と話しかけるだけで、create-post-from-photoが自動的に呼ばれる。REST、管理画面、MCPという3つの入口を同じコードで実現できるのは、Abilities APIの設計の妙だ。
実装から見える将来性
WordPressのコアに組み込まれたこれらAIビルディングブロックは、単なる補助機能ではない。プラグイン開発のパラダイムを「単一の機能提供」から「再利用可能な能力の提供と合成」へとシフトさせる可能性を秘めている。
さらに、Connectors APIによるAPIキーの一元管理は、複数プラグイン間の設定のばらつきを解消し、サイト管理者の負担を大きく下げる。開発者は「どのAIモデルを使うか」を気にせず、ビジネスロジックに集中できる環境が整いつつある。
注意点として、AI呼び出しには時間がかかるため、デフォルトのHTTPタイムアウトでは処理が中断される可能性がある。チュートリアルではwp_ai_client_default_request_timeoutフィルタでタイムアウトを120秒に延長する対処が示されている。このような実運用の勘所も押さえておきたい。
プラグイン開発者がこうした基盤を活用し始めれば、WordPressエコシステム全体のAIリテラシーが一気に加速する。非エンジニアでも「写真から投稿を作って」と指示するだけでコンテンツ制作が進む未来は、すぐそこまできている。
この記事のポイント
- WordPress 7.0のAbilities API・AI Client・MCP Adapterにより、AI搭載プラグインを少ないコードで構築できる
- 能力を1回登録すればREST・管理画面・AIエージェントの3経路で同一機能を提供可能
- AI Clientはプロバイダー非依存で、Connectors APIがAPIキー管理を集約
- 能力の合成で「LEGOブロック」のように複雑な自動化を実現
- 実運用ではタイムアウト延長フィルタなど、実装上の注意点も必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験