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最適化の豊富な経験
WP-CLIとREST APIとAbilities API、WordPressインターフェースの選び方
3つのインターフェースの全体像
WordPressには外部からデータをやり取りするための主要なインターフェースが3つ存在する。WP-CLI、REST API、Abilities APIだ。それぞれが異なる距離感でWordPressと向き合い、異なる呼び出し元に対応する。これらを競合関係と捉えるのは誤りで、実際には階層構造をなしている。
WP-CLIはサーバー上で動作し、REST APIはHTTPを介して通信する。そしてAbilities APIは、そのさらに上位に位置し、AIエージェントが何をすべきかを判断する層になる。どのレイヤーがどこに位置するのかを理解すれば、タスクに応じた最適な選択はおのずと見えてくる。
- WP-CLI：サーバー上で直接PHPを実行（またはSSH経由）。一括操作、移行、デプロイ、メンテナンス向き
- REST API：wp-jsonへのHTTPリクエスト。ブラウザ、モバイルアプリ、外部サービスからコンテンツの読み書きに使用
- Abilities API：RESTとMCPで公開される名前付きPHPケイパビリティ。AIエージェントが安全に操作を行えるように設計
3つのインターフェースは、下位ほど呼び出し元がサイトに近く、信頼度も高い。上位になるほど、呼び出し元は自律的で遠隔地に位置する。この構造を理解すれば、「どれを使うべきか」の判断はシンプルになる。
WP-CLI：サーバー上のコマンドライン
WP-CLIはWordPressのインストール環境に対して直接PHPを実行する。コマンド例としては wp post create、wp plugin update、wp search-replace、wp db export などがある。実行にはサーバーへのシェルアクセス（SSH）が前提だが、その分HTTPの往復も認証トークンの管理も不要になる。
WP-CLIが最も威力を発揮するのは、サイトを完全に制御できる状況だ。1000件の投稿を移行する、データベース全体でドメインを置換する、定期メンテナンスをスクリプト化する、あるいはデプロイの自動化など、スピードが求められる一括操作では他の追随を許さない。
WP-CLIはシェルアクセスが前提のため、ブラウザやモバイルアプリ、外部サービスがサイトと通信する手段にはなりえない。しかし開発者がサイト全体を制御できる状況では、WP-CLIは圧倒的な速度と柔軟性を提供する。ターミナルからすべてを操作するワークフローが浸透している開発現場も多く、管理画面（wp-admin）をほとんど開かない運用も可能だ。
REST API：HTTP越しのWordPress
REST APIはWordPressサイトを、あらゆるHTTPクライアントが読み書きできる状態に変換する。エンドポイントは /wp-json/wp/v2/ 配下に存在し、認証にはアプリケーションパスワード、Cookieとnonce、あるいはOAuthを用いる。ブラウザ、モバイルアプリ、外部サービスがインターネット越しにコンテンツを取得・更新できるようになる。
ヘッドレスCMS構成のWordPressは、このREST APIを基盤に動作する。AstroやNext.jsで構築したフロントエンドがREST経由でコンテンツを取得し、モバイルアプリが投稿を行い、サードパーティ連携がデータを同期する。呼び出し元がサーバー外にいる場合、REST APIがほぼ唯一の通信経路となる。
投稿、ユーザー、タクソノミー、設定といった「リソース」
「誰が何をしたいのか」という意図や操作の文脈
REST APIには重要な限界がある。公開するのは「データの構造」であり、「そのデータで何をしたいのか」という操作の意図までは記述しない。どのエンドポイントが存在し、どうリクエストを組み立てるべきかは、呼び出し元が自ら理解する必要がある。人間の開発者であれば問題ないが、AIエージェントにとっては推論すべき情報が多すぎるという課題が残る。
Abilities API：AIエージェントのためのケイパビリティ層
Abilities APIはWordPress 6.9でコアに導入された最新のインターフェースだ（それ以前のバージョン向けにはプラグインも提供されている）。REST APIが残した「AIエージェントが何を許可されているのかをどう知るか」という課題を解決するために設計された。
Abilities APIでは、生のリソースを公開する代わりに、プラグインやテーマが「名前付きケイパビリティ（能力）」を登録する。各アビリティは、一意のID、人間が読めるラベル、説明文、入力・出力のスキーマ、権限チェックのコールバック、そして実行コールバックを備えた独立した操作単位となる。
add_action( 'wp_abilities_api_init', function () {
wp_register_ability( 'my-plugin/publish-draft', [
'label' => '下書きを公開',
'description' => 'IDを指定して既存の下書き投稿を公開する',
'category' => 'my-plugin',
'input_schema' => [ /* 期待する入力のJSON Schema */ ],
'output_schema' => [ /* 結果のJSON Schema */ ],
'permission_callback' => 'my_plugin_can_publish',
'execute_callback' => 'my_plugin_publish_draft',
'meta' => [ 'show_in_rest' => true ],
] );
} );meta.show_in_rest をtrueに設定すると、そのアビリティは wp-json/wp-abilities/v1/abilities で公開され、クライアントが検出できるようになる。JavaScript側では @wordpress/abilities パッケージを介して利用する。
Abilities APIの最大の価値は、エージェントが安全に行動するために必要な「契約」を提供することだ。操作の定義、必要な入力形式、実行許可の条件が明示されるため、AIエージェントがサイトを壊すリスクを最小限に抑えられる。複数のエージェントが共通の語彙で協調動作するマルチエージェント構成でも、Abilities APIが基盤になりつつある。
3つのインターフェースの積み重なり方
3つのインターフェースは互いに積み重なる関係にある。Abilities APIは多くの場合REST APIの上に構築され、REST APIはWP-CLIが直接駆動するPHPの上で動作する。すべての基盤にあるのは、同じWordPressコア、同じデータベース、同じ関数群だ。
したがって問うべきは「どれが最善か」ではない。「呼び出し元がサイトからどれだけ離れているか」「操作の意図をどこまで明示する必要があるか」という視点で選択することが本質になる。呼び出し元が近く信頼できるほど下位層を、自律的で遠隔にあるほど上位層を使う。
上位層になるほど「記述性」と「安全性」が重視され、下位層ほど「速度」と「直接制御」に優れる。これらは設計上、相補的な関係にあり、実際のプロジェクトではすべてを併用するのが理想的な構成だ。
各インターフェースの使い分け方
日常的なタスクにおける選択指針を整理する。
- 自分が制御するサイトに対して、一括かつ高速に操作したい → WP-CLI。移行、デプロイ、定期ジョブ、データベース操作が該当する
- ブラウザ、アプリ、外部サービスがコンテンツを読み書きする必要がある → REST API。ヘッドレスフロントエンド、モバイルアプリ、外部連携が該当する
- AIエージェントにサイトを壊さず操作させたい → Abilities API。許可したい操作をスキーマと権限付きで登録し、エージェントに発見させる
実際のプロジェクトでは、この3つを排他的に使うことはまれだ。むしろそれぞれの得意領域を活かして組み合わせるのが、効率的なWordPress運用の鍵になる。
3つを組み合わせた実践的な構成
WP Mayorの記事では、実際に3つのインターフェースを併用している構成例が紹介されている。まず、公開運用と日常的な運用作業はSSH経由のWP-CLIで実行される。新規投稿、メディアのインポート、プラグイン更新、キャッシュクリアといった操作をターミナルから完結させ、管理画面（wp-admin）をほとんど開かない運用が行われている。
フロントエンドはヘッドレス構成で、REST API越しにコンテンツを取得する。Astroで構築されたサイトが wp-json 経由でWordPressからデータを取得し、高速な静的ページとして配信する。訪問者はWordPressテーマに触れることなく、WordPressはバックエンドのエンジンとして機能し、REST APIがそのパイプ役を担う。
エージェント向けの機能はAbilities APIを通じて提供される。AIエージェントに限定的なタスクを任せたい場合、関連プラグインがその操作をアビリティとして登録する。権限チェックとスキーマを伴うため、シェルアクセスを丸ごと渡したり、大量の生エンドポイントをエージェントに解析させたりする必要がなくなる。
WP-CLIは速度と一括処理能力で、REST APIは外部連携の柔軟性で、Abilities APIはAIエージェントの安全性で優位性を持つ。1つのインターフェースに別の役割を強制しようとするところから問題は始まる。3つのレイヤーを適材適所で使い分けることが、WordPress自動化の効率を最大化する道筋だ。
この記事のポイント
- WP-CLI、REST API、Abilities APIは競合ではなく、呼び出し元の距離に応じた階層構造をなす
- WP-CLIはサーバー上の直接操作に最適で、一括処理と速度が求められる場面で選ぶ
- REST APIはHTTP越しのデータ読み書きを担い、ヘッドレス構成やモバイルアプリ連携の基盤となる
- Abilities APIはAIエージェントに操作の安全な契約を提供し、マルチエージェント構成でも威力を発揮する
- 実際のプロジェクトでは3つを組み合わせ、各レイヤーの得意領域を活かすのが理想的な運用だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Gravity Forms PDFで合計金額が倍になる原因と修正方法
Gravity Forms で作成したフォームから PDF を出力するプラグイン「PDF Invoices for Gravity Forms」を使っていて、テンプレート内で get_total() メソッドを複数回呼び出すと合計金額が呼び出し回数に応じて倍々に膨らんでしまう現象は、静的変数 self::$total が各呼び出しのたびに加算され続ける設計になっているのが原因だ。直すにはヘルパークラスを子テーマから拡張し、get_total() の内部で毎回リセットして再計算させる変更を加える。
合計金額が倍になる現象はどのようなときに起こるのか
たとえば請求書のテンプレートに「小計」と「総合計」を別々の位置に表示したい場合、PDF_Invoices_For_GravityForms_Helpers::get_total() を2回呼ぶことになる。ところがイベント参加登録や商品注文フォームなどで実際にこの処理を通すと、2回目の呼び出し時には1回目に加算された値にさらに同じ計算が上乗せされ、本来 10,000 円のところが 20,000 円になるといった不具合が起きる。
なぜ get_total() を複数回呼ぶと値が積み上がるのか
問題の根本は class-pcafe-gfpi-helpers.php ファイル内の get_total() メソッドにある。このメソッドは静的変数 self::$total を使い、内部で次のように加算している。
public static function get_total(){
self::$total += self::get_subtotal();
self::$total += self::$shipping;
return self::$total;
}静的変数はリクエストの間ずっと値を保持するため、同じ処理中に get_total() が呼ばれるたびに前回の合計に小計と送料が足されていく。2回呼べば「小計 + 送料」が2倍になり、3回なら3倍になる。通常、こうした合計取得メソッドは毎回ゼロから計算し直すべきであり、内部で継ぎ足す構造は意図したものでない可能性が高い。
変数 self::$total が 10,500 を保持したまま
2回目呼び出し: 変数をリセット後 再計算 → total=10,500
上の図のように、2回目で合計が倍になる。特に「小計」「消費税」「総合計」など複数の金額を PDF テンプレートに配置する場合にこの問題が顕在化しやすい。
get_total() 修正の基本的な考え方
プラグイン本体のファイルを直接編集してしまうと、アップデートのたびに修正が上書きされて消える。そのため子テーマの functions.php を使い、プラグインのヘルパークラスを拡張した独自クラスを用意する方法をとる。拡張クラスでは get_total() メソッドをオーバーライドし、計算前に self::$total を強制的に 0 にリセットしてから小計と送料を加算する。
子テーマでヘルパークラスを拡張して修正する手順
独自ヘルパークラスを作成する
まず子テーマの functions.php に、プラグインのヘルパークラスを継承したクラスを定義する。子テーマがない場合は、Code Snippets プラグインを使うか、wp-content/themes/（現在のテーマ）/functions.php に追記する形でもよい。コードは以下のようになる。
class Custom_GFPI_Helpers extends PDF_Invoices_For_GravityForms_Helpers {
public static function get_total() {
self::$total = 0; // 計算前に必ずリセットする
self::$total += self::get_subtotal();
self::$total += self::$shipping;
return self::$total;
}
}テンプレート内でカスタムクラスを呼び出す
拡張クラスを作っただけでは既存のテンプレートには反映されない。PDF テンプレート内で PDF_Invoices_For_GravityForms_Helpers::get_total() を呼んでいる箇所を、先ほど定義した Custom_GFPI_Helpers::get_total() に置き換える。
テンプレートファイルは多くの場合 wp-content/uploads/pdf-invoices-for-gravity-forms/templates/ 以下にカスタムテンプレートとして配置されている。該当の .php ファイルを開き、以下のように書き換える。
<?php
// 修正前
// echo PDF_Invoices_For_GravityForms_Helpers::get_total();
// 修正後
echo Custom_GFPI_Helpers::get_total();
?>これでテンプレート内のどの場所から呼び出しても、毎回リセット後に計算が走るため合計が積み上がることはなくなる。
変更後にキャッシュと動作を確認する
変更を加えたあとは、必ず PDF を生成し直して合計金額が正しいか確認する。Gravity Forms のエントリーから「PDFを表示」ボタンで実際の請求書を開き、同じ合計が要求された位置すべてに正しく表示されているかをチェックする。サイトでキャッシュプラグインを使っている場合は、キャッシュを全削除してから確認すると確実だ。
よくある質問
プラグイン本体のファイルを直接修正してもよいか
推奨しない。プラグインがアップデートされるたびに修正が上書きされ、その都度同じ変更を加えなければならなくなる。子テーマや Code Snippets を使う方法なら、アップデートに影響されず継続的に動作する。
他の金額表示（税額や値引き額）も倍増している場合の対処は
同じヘルパークラス内で定義されている get_tax() や get_discount() にも同様の静的変数の加算構造がある可能性が高い。それらのメソッドも同じ要領でカスタムクラス内にオーバーライドし、内部で該当の静的変数をリセットする処理を加えるとよい。
子テーマを使っていない場合でも対応できるか
子テーマがない場合は Code Snippets プラグインが便利だ。スニペットとしてクラス定義を追加すれば、テーマに依存せず同じ修正を適用できる。テンプレートの書き換えは手動で行う必要があるが、クラスの読み込み自体はスニペット経由で問題なく動作する。
修正後に PDF が真っ白になる場合の確認点は
クラス名やメソッド名のスペルミス、オートローダーがカスタムクラスを見つけられていないケースが考えられる。まず PHP のエラーログを確認し、クラスが見つからないという趣旨の致命的エラーが出ていないか調べる。出ている場合はクラス定義の記述ミスか、定義のタイミングが早すぎる可能性があるため、init フックなどで定義を遅らせると改善することがある。
この記事のポイント
get_total()の多重呼び出しで合計が倍増するのは、静的変数self::$totalが加算され続ける設計のため- プラグイン本体を直接修正せず、子テーマの functions.php でカスタムクラスを定義する
- カスタムクラス内で
get_total()をオーバーライドし、計算前にself::$total = 0;でリセットする - PDF テンプレート側の呼び出しをカスタムクラスに差し替え、キャッシュ削除後に動作確認する
- 同様の構造を持つ
get_tax()やget_discount()も併せて修正を検討する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
GA4にAI Assistantチャネル追加、ChatGPT流入を可視化
Google Analytics 4（GA4）に2026年5月、生成AIプラットフォームからの流入を可視化する「AI Assistant」チャネルが追加された。ECサイト運営者にとって、ChatGPTやClaudeが商品情報を紹介した結果のトラフィックを正確に把握できる初めての標準機能だ。
この記事ではAI Assistantチャネルの基本的な仕組みと、ECサイトでの具体的な活用法を解説する。設定不要でデータが自動収集される一方、AI Overviewsは含まれないといった注意点もあるため、正しい読み方を押さえておく必要がある。
WooCommerceサイトを運営する中小企業の担当者や、ECのアクセス解析を担当するWeb担にとって、これまで「参照元不明」だったAI経由の流入を可視化できる意味は大きい。
AI Assistantチャネルとは何か
AI Assistantチャネルは、GA4のデフォルトチャネルグループに追加された新しい分類項目だ。ChatGPTやGemini、Claudeといった主要な生成AIプラットフォームからのトラフィックを自動的に判別し、ひとつのチャネルとして集計する。
計測対象となるプラットフォーム
Googleの公式ヘルプドキュメントによると、AI Assistantチャネルに含まれるのは「ChatGPT、Gemini、Claudeといったチャットボット」からのトラフィックだ。具体的な全リストは公開されていないが、主要な生成AIサービスはおおむねカバーされていると見てよい。
ここで重要な注意点がある。Google検索のAI Overviews（旧SGE）やAI Modeは、このチャネルには含まれない。これらは引き続き「Organic Search（オーガニック検索）」チャネルとして報告される。同じAI由来の流入でも、検索エンジン経由かチャットボット経由かで扱いが異なるわけだ。
ECサイトにとっての意味
ECサイト運営者にとって、AIチャットボット経由の流入は従来のSEOとは異なる文脈で発生する。たとえば「予算3万円で買えるおすすめのワイヤレスイヤホン」といった自然言語の質問に対し、ChatGPTが具体的な製品名とURLを提示するケースだ。この流入経路を正確に把握できれば、AIに自社商品がどのような文脈で言及されているかを分析できる。
AIトラフィックの確認手順
GA4でAI Assistantチャネルのデータを見るための手順を解説する。初期設定は不要で、GA4が自動的に分類を開始しているため、すぐに確認できる。WooCommerceサイトでGA4を導入済みであれば、追加のコード実装も必要ない。
トラフィック全体像の把握
まずはECサイト全体で、AI経由の流入がどの程度あるのかを確認する。GA4管理画面で「レポート」→「集客」→「トラフィック獲得」の順に開き、「セッションのデフォルトチャネルグループ」ディメンションを選択する。ここで「AI Assistant」という行が表示されていれば、すでにAI経由のトラフィックが発生している。
表示される指標はエンゲージメント率、セッションあたりのイベント数、平均セッション時間などだ。これらの数字をOrganic Searchチャネルと比較することで、AI経由ユーザーの行動特性が見えてくる。
ランディングページの特定
AIがどの商品ページを参照しているのかを特定するには、「レポート」→「エンゲージメント」→「ページとスクリーン」を開く。画面上部の「フィルタを追加」から、以下の条件で絞り込む。
- ディメンション：セッションのデフォルトチャネルグループ
- マッチタイプ：完全一致
- 値：AI Assistant
このフィルタを適用すると、AIプラットフォームからのクリックが多いページが上位に表示される。WooCommerceの商品ページやカテゴリページのうち、どのURLがAIに評価されているかを把握できるはずだ。
AIトラフィックと他チャネルの比較
同じ「ページとスクリーン」レポートで「比較を追加」ボタンを使うと、AI経由とオーガニック検索経由のトラフィックを横並びで比較できる。Practical Ecommerceの記事著者Carlo Daniele氏の検証によれば、オーガニック検索で上位のページとAI Assistant経由で上位のページは重複しなかったという。
これはEC担当者にとって示唆が大きい。Google検索で上位表示されている商品と、AIがユーザーに推薦する商品が異なる可能性があるためだ。AI経由の流入を伸ばすには、従来のSEO対策とは別のアプローチが必要になるかもしれない。
正規表現を使った詳細なソース分析
AI Assistantチャネルは便利だが、どのAIプラットフォームからの流入なのかまでは分解できない。ChatGPT経由なのかClaude経由なのかを個別に知りたい場合は、正規表現（regex）を使ったフィルタリングが有効だ。
設定手順
「レポート」→「集客」→「トラフィック獲得」で、グラフ上部の「フィルタを追加」をクリックする。ディメンションに「セッションの参照元/メディア」、マッチタイプに「matches regex」を選択し、以下の正規表現を値欄に貼り付ける。
.*chatgpt.com.*|.*perplexity.*|.*edgepilot.*|.*copilot.microsoft.com.*|.*openai.com.*|.*gemini.google.com.*|.*claude.ai.*|.*grok.x.ai.*このフィルタを適用すると、AIプラットフォームごとのセッション数やエンゲージメント指標を一覧できる。ただしPractical Ecommerceの記事でも指摘されているように、AI Assistantチャネルとの間にわずかなデータの不一致が生じる場合がある。これは「Organic」や「(not set)」と分類される一部のAIトラフィックが正規表現では拾えていないためだ。
WooCommerceサイトでの活用ポイント
正規表現フィルタを使えば、たとえば「ChatGPT経由では商品Aへの流入が多いが、Claude経由では商品Bが多い」といったプラットフォーム別の傾向を把握できる。AIによって得意とする商品カテゴリや、参照する情報ソースが異なる可能性があるためだ。
このデータをもとに、特定のAIプラットフォームで自社商品が言及されやすいコンテンツを強化するといった戦略が考えられる。Semrushなどの外部ツールで、どのようなプロンプトがAIの引用を生んでいるのかを調査するのも有効だ。
EC担当者が今すぐやるべき3つのアクション
AI Assistantチャネルの登場を受けて、ECサイトのアクセス解析にすぐに組み込むべき施策を整理する。いずれも追加コストなしで今すぐ始められるものばかりだ。
特にアクション2は重要だ。AIは商品スペックや口コミ、価格情報を総合的に評価して回答を生成する。商品ページの情報が不十分だとAIに引用されにくくなるため、商品説明の充実や構造化データの実装はAI時代のECに不可欠な施策といえる。
AIトラフィックとECの未来
GA4のAI Assistantチャネルは、ECにとって「AI経由の流入」という新たな指標を提供し始めた。現時点ではまだAIトラフィックの絶対量は小さいかもしれないが、ChatGPTやClaudeがデフォルトでWeb検索を行うようになり、AIを経由した商品発見は確実に増えていく。
AI OverviewsがOrganic Searchに含まれるという設計からもわかるように、GoogleはAIを「検索の拡張」と位置づけている。EC担当者はSEOとAI最適化を別物ではなく、同じ「検索体験」の両輪として捉えるべきフェーズに入ったといえる。
WooCommerceサイトであれば、GA4の標準機能だけでAIトラフィックの可視化は十分に可能だ。まずはデータを取得し、AIが自社商品をどう評価しているのかを把握することから始めてほしい。
この記事のポイント
- GA4に2026年5月追加のAI Assistantチャネルで、ChatGPTやClaudeなど生成AIからの流入が自動分類される
- AI OverviewsやAI Modeは含まれず、これらはOrganic Searchとして報告される点に注意が必要
- ページとスクリーンレポートでAI経由ランディングページを特定し、商品情報の最適化に活かせる
- 正規表現フィルタでAIプラットフォーム別の傾向を把握し、より細かな流入分析が可能
- AIトラフィックはSEOと地続きの指標であり、商品ページの情報充実がAIからの引用を増やす鍵になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceで北アイルランド向けVAT税率だけ20%に設定する方法
{ “title”: “WooCommerceで北アイルランド向けVAT税率だけ20%に設定する方法”, “meta_description”: “WooCommerceで英国は税率0%、北アイルランドだけ税率20%に設定するには、国「UK」と州コード「Northern Ireland」を組み合わせる。設定手順とテスト方法まで解説。”, “tags”: [“WooCommerce”, “税率設定”, “VAT”, “北アイルランド”, “EC運営”, “Brexit”], “slug”: “woocommerce-northern-ireland-tax-rate”, “image_prompt”: “WooCommerceのロゴ（紫の丸みを帯びたマーク）を3Dで目立つように大きく配置する。上部には、ダークなEU地図の上に北アイルランドだけがハイライトされ、20%のプレートが浮かぶリアルな構図。下部には英国本土と北アイルランドが色分けされたVAT設定画面のUIを配置。構図は上下分割スタイルとし、主要な視覚要素を画面の上部と下部に配置して、その間を自然で大気感のあるトランジションでつなぐ。画面を横切る水平の帯やストライプは描かない。画像の右下の領域には文字・ロゴ・重要な被写体を置かず、背景や余白にする。アスペクト比16:9。UI画面・ダッシュボード・コードエディタ・管理画面が写る場合、その中の文字はすべて英語にする。ノートPCやモニターが写る場合は極細ベゼルの現代的なデザインにする。カレンダー・画面・書類・タイムラインに年号の数字を表示しない。”, “featured_text”: “北アイルランドだけ\n税率20%にしたい？” }
WooCommerceで英国本土と北アイルランドに異なるVAT税率を設定するには、税率設定画面で国として「United Kingdom (UK)」を選び、州コードに「Northern Ireland」を指定して、英国全体の税率と北アイルランドのみの税率をそれぞれ登録する。
WooCommerceの税率設定で英国と北アイルランドを区別できない原因
WooCommerceは国単位で税率をマッチさせるが、標準状態では英国全体が「GB」という国コードでまとめられている。そのため、英国本土向けの税率と北アイルランド向けの税率を単一の国設定で区別できないように見える。しかし実際には、州コード（State Code）を使って地域を細分化できる仕組みが備わっている。英国本土と北アイルランドはVAT制度上、EUと英国内で異なる扱いを受けるため、州レベルでの切り分けが不可欠だ。
WooCommerceで英国本土と北アイルランドの税率を別々に設定する手順
WooCommerceの管理画面から、税率の新規追加・編集を行う。まずは英国全体に対する税率0%を設定し、その後に北アイルランドだけを対象とした税率20%を追加する。この順序で設定する必要は必ずしもないが、後のテストが楽になる。
このデモは英国全体（州コードなし）と北アイルランド（州コードあり）の2つの税率エントリを示している。実際の設定画面でも同じ構造で登録する。
英国全体の税率0%を設定する
WooCommerceの管理メニューから「WooCommerce」→「設定」→「税率」タブを開く。「税率を追加」ボタンを押し、以下のように入力する。
- 国コード: ドロップダウンから「United Kingdom (UK)」を選ぶ
- 州コード: 何も入力せず空欄のままにする
- 税率: 0%（英国本土向けVATは0%のため）
- 税率名: 例「UK VAT 0%」など分かりやすい名前
- 税率の優先度: 0（デフォルトで問題ない）
「変更を保存」をクリックする。これで英国本土向けの注文には0%が適用される。
北アイルランド向けの税率20%を設定する
同じ税率一覧画面で再び「税率を追加」を押す。今度は州コードを指定して北アイルランドだけに20%が適用されるエントリを作る。
- 国コード: 「United Kingdom (UK)」を選ぶ
- 州コード: ドロップダウンまたは手入力で「Northern Ireland」を指定する。入力欄に文字を打つと候補が表示される
- 税率: 20%（標準VAT）
- 税率名: 例「Northern Ireland VAT 20%」
- 税率の優先度: 0
「変更を保存」をクリックする。WooCommerceは注文時に配送先住所の国と州を照合し、より具体的な州コード指定のある税率エントリを優先して適用する。これで北アイルランド宛ての注文には20%が、それ以外の英国本土宛てには0%が自動で適用される。
設定後は必ずテスト購入で税率を確認する
本番運用する前に、かならずテストモードまたはステージング環境で実際の購入フローを試してほしい。配送先住所を英国本土（例: London）と北アイルランド（例: Belfast）の2パターンで入力し、カートやチェックアウト画面に表示される税額が想定どおりになっているか確認する。
もし北アイルランド住所でも税率が0%のままだった場合は、税率エントリの州コードが正しく「Northern Ireland」になっているか、また住所欄に入力した州名が税率設定のものと一致しているかをチェックする。WooCommerceは住所の州名と税率テーブルの州コードを厳密に突き合わせるため、スペルミスや表記ゆれがあるとマッチしない。
よくある質問
英国全体の税率エントリと北アイルランドの税率エントリの優先度は同じでよいのか
問題ない。どちらも優先度が同じ場合、WooCommerceはより具体的な条件を持つエントリ（州コード指定あり）を自動的に優先する。本土用（州指定なし）より北アイルランド用（州指定あり）のほうが具体的なため、優先度の値にかかわらず正しく適用される。
州コードに「Northern Ireland」が表示されない場合はどうするか
WooCommerceの州コードリストはデフォルトで主要な州を含んでいるが、何らかの理由で表示されない場合は手入力も可能だ。入力欄に直接「Northern Ireland」とタイプして保存すれば機能する。もしどうしてもリストに出ないなら、WooCommerceの一般設定で販売地域を「すべての国に出荷する」などに一時変更してから再確認する。
欧州連合（EU）のVAT設定と衝突しないか
WooCommerceの税率設定は国単位・州単位で独立しているため、EU加盟国向けの税率エントリとは別に管理できる。英国（GB）向けのエントリは、EUの税率設定テーブルとは独立して動作するので衝突しない。ただしEU全域向けの税率設定をまとめて有効にしている場合は、英国向けエントリが優先されるよう、税率の優先度や対象地域を整理しておくと安心だ。
北アイルランド宛ての配送時にだけ異なる税率を表示したいが可能か
可能だ。本記事で解説した州コード指定の方法を使えば、北アイルランド向けの注文だけ異なる税率（例: 20%）を表示し、英国本土向けには別の税率（例: 0%）を表示できる。条件は住所の州名が税率エントリの州コードと一致することだけだ。
WooCommerce以外のプラグインでもこの方法は使えるか
この解説はWooCommerceの税率設定機能を前提としている。ECプラグインによっては州コードを使った税率の細分化に対応していない場合もあるため、利用しているプラグインのドキュメントを確認する必要がある。WooCommerceを推奨する趣旨ではないが、同様の要件を満たすには国と州を組み合わせた柔軟な税率設定ができるプラグインを選ぶことがポイントになる。
この記事のポイント
- WooCommerceでは国コード「GB」と州コード「Northern Ireland」で税率を分けられる
- 州コード指定のある税率エントリは、指定のないエントリより優先される
- 英国全体に税率0%、北アイルランドに税率20%をそれぞれ追加する
- 設定後はテスト購入で英国本土と北アイルランド両方の税額を確認する
- 州コードは手入力でも有効、表示されない場合は直接タイプする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
OpenAI、フルデュプレックス音声モデルGPT‑Liveを発表、会話の自然さを大幅向上
OpenAIは2026年7月8日、新しい音声対話モデル「GPT‑Live」を発表した。人が話しかけるのと同時に聞き取り、相槌を打ったり沈黙を尊重したりできるフルデュプレックスアーキテクチャが最大の特徴だ。
モデル自体は単体の音声モデルでありながら、高度な質問に対してはバックエンドのGPT‑5.5に自動で推論を委譲する。これにより、速さと知性を両立させた自然な会話体験を実現している。
フルデュプレックスアーキテクチャが会話の自然さを変える
従来の音声AIが抱えていた限界
これまでのChatGPT音声機能は、大きく分けて2つの方式を経て進化してきた。最初のカスケード型は、音声認識→テキスト生成→音声合成という3つのモデルを直列に繋いでいた。各段階で情報が欠落し、応答までに長い沈黙が生まれる欠点があった。
次世代のターンベース型（Advanced Voice Mode）は単一モデルで音声を処理し、レイテンシを削減した。しかし「ユーザーが話し終えるまで待つ」というターン制のため、割り込みや考え込む間といった自然なやり取りができず、わずかな無音で誤って応答を開始する問題も残っていた。
このデモはGPT‑Liveがもつ同時双方向処理の概念を簡略化したものだ。実際の会話では秒単位で割り込みやツール呼び出しの判断が行われている。
連続的な相互作用が生むリアルタイム性
GPT‑Liveのフルデュプレックス構造では、入力と出力が同時に連続的に処理される。モデルは1秒間に何度も発話や傾聴、一時停止、割り込み、ツール起動といった行動を判断できる。この仕組みが、相槌や「ええ」といった自然なフィードバック、沈黙の尊重、さらには会話中のリアルタイム翻訳まで可能にしている。
バックエンド委譲で高度な推論をリアルタイム対話に統合
対話と思考の分離がもたらすメリット
GPT‑Liveはフロントエンドの自然な対話と、バックエンドの深い処理を分離した。Web検索や複雑な推論が必要な質問が来ると、自身は会話を続けながらGPT‑5.5にタスクを委譲する。回答が用意でき次第、会話に自然に織り込まれる。
この分離により、常に最新のフロンティアモデルが活用され、モデル更新のたびにGPT‑Liveの知性も自動的に向上する。発表時点ではGPT‑5.5がバックエンドとして使われる。
この委譲の仕組みにより、GPT‑Liveは会話のテンポを保ちつつ、最新のフロンティアモデルの知性を引き出せる。
評価指標が示す会話品質の飛躍的向上
人間による比較評価でAdvanced Voice Modeを圧倒
OpenAIの発表によれば、5〜10分の会話を対象にした人間評価では、GPT‑Live‑1とGPT‑Live‑1 miniの両方がAdvanced Voice Modeより強く選好された。話者交替のスムーズさ、割り込みの自然さ、会話全体の心地よさで高い評価を得ている。
専門的な推論力を測るGPQA（物理学・化学・生物学の高度な質問）ではGPT‑Live‑1が大幅に上回り、Web検索能力を問うBrowseCompでも強い改善を見せた。音声エージェントとしての電話サポートタスクでも、内部指標でAdvanced Voice Modeを凌駕した。
ChatGPT Voiceに搭載される新機能と使い勝手
相槌や割り込み、視覚的応答の追加
GPT‑Liveの導入により、ChatGPTの音声ボタンを押すとすぐに自然な会話が始まる。ユーザーは質問を遮ったり、考え込む間を作ったり、「ゆっくり話して」と頼んだりできる。モデルは「うん」「なるほど」といった相槌で話を聞いていることを伝え、背景ノイズがあっても話者の声に集中する。
さらに、天気や株価、スポーツの試合予定などの情報は、音声会話中にビジュアルカードとして画面に表示される。従来通り画像やファイルのアップロードにも対応し、Web検索やメモリー機能とも連携する。
回答の思考深度も選択可能で、「Instant」なら即答、「Medium」や「High」にするとモデルが時間をかけて深く推論する。全9種類の声もGPT‑Live向けにリマスターされた。
音声特化の安全性設計と継続的な監視
リアルタイムの有害出力検出と介入
GPT‑Liveは音声会話の即時性に対応するため、発話中でも安全性チェックが動作する。不適切な内容が検出されると、より安全な応答へ誘導したり、追加の安全メッセージを表示したり、深刻なケースでは会話を終了させたりする。
自傷行為に関する会話では、専門家が確認したクライシスヘルプライン情報を音声で案内する仕組みも組み込まれた。10代のユーザー向けには年齢に適した振る舞いを直接モデルに学習させ、保護者がChatGPT Voiceの利用を制限できる機能も用意されている。
実利用データに基づく安全対策の進化
OpenAIは感情的な依存に関する長期モニタリングを展開し、実際の利用パターンから新たなリスクを特定して対策を強化する方針だ。音声のなりすましを防ぐため、GPT‑LiveはChatGPTに用意された定義済みの声のみを使用し、実在の人物の声を模倣しないように設計されている。
この記事のポイント
- GPT‑Liveはフルデュプレックス構造で同時に聞きながら話し、相槌や沈黙を自然に扱える音声モデル
- 高度な質問はバックエンドのGPT‑5.5に自動委譲し、会話のテンポを保ったまま深い推論結果を返す
- 人間評価やGPQAなどのベンチマークでAdvanced Voice Modeを大きく上回る会話品質と知性を達成
- ChatGPT Voiceに即日導入され、ビジュアル応答や思考深度の選択が可能に
- リアルタイムの安全性介入や利用後監視により、音声ならではのリスクに対処している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GPT-5.6ファミリー登場、Sol・Terra・Lunaの全容と実務メリット
OpenAIは2026年7月9日、次世代フラッグシップモデル「GPT-5.6」ファミリーを一般提供開始した。プレビュー期間を経て投入された本リリースには、フラッグシップのSol、バランスモデルのTerra、コスト効率重視のLunaの3モデルが揃う。
GPT-5.6 Solはコーディング、知識労働、サイバーセキュリティ、科学研究の各領域で従来のフロンティアモデルを上回る性能を達成しつつ、消費トークン数と推定コストの大幅削減を両立した。これにより同一予算でもより多くの成果を出せる、いわば「コストパフォーマンスの再定義」を実現している。
この記事では、GPT-5.6の各モデルの特徴と性能、実務者にとってのメリット、そしてOpenAIが打ち出した新たな安全性対策を掘り下げる。
GPT-5.6ファミリーの全体像～3モデルの違いと狙い
GPT-5.6ファミリーは3つのモデルで構成される。Sol・Terra・Lunaはいずれも第5.6世代の基盤技術を共有するが、ターゲットとする用途とコスト構造が異なる。OpenAIによれば、これらのモデル名（Sol・Terra・Luna）は永続的な能力階層を示しており、今後それぞれのペースでアップデートが進む見込みだ。
Solが実現する「1トークンあたりの仕事量」の進化
Solの最大の特徴は、消費トークンあたりの実用成果の高さにある。Agents’ Last Exam（55分野の長時間ワークフロー評価）ではスコア53.6を記録し、競合のClaude Fable 5を13.1ポイント上回った。中程度の推論設定でも、Fable 5に対して11.4ポイント優位に立ちつつ、推定コストは約4分の1に抑えている。
この効率性は下位モデルにも波及している。GPT-5.6 TerraとLunaは、Fable 5の性能を上回りながら推定コストは約16分の1だ。単に「強いAI」を作るだけでなく、同じ予算でより多くの知的作業をこなせる点が、今回のリリースの中核的価値といえる。
ultra設定がもたらす並列エージェント駆動
GPT-5.6 Solには「ultra」と呼ばれる最高能力設定が搭載された。ultraはデフォルトで4つのエージェントを並列動作させ、複雑なタスクを複数のワークストリームに分割して処理する。これにより単一エージェント構成と比べて、スコアとレイテンシの両方で改善が確認されている。
BrowseComp、SEC-Bench Pro、Terminal-Bench 2.1の3評価すべてで、並列エージェントの追加により「より高スコアをより短時間で」達成する結果が得られた。開発者はAPIのマルチエージェントベータ機能を通じて、同様の並列処理を独自に構築することも可能だ。
実務者にとってのGPT-5.6～コストと速度の再定義
GPT-5.6の真価はベンチマークスコアだけではない。実務者が日々使うツールやワークフローの中で、どれだけ「手戻り」を減らし「完成度」を高められるかが鍵だ。
Programmatic Tool Callingでツール連携が変わる
GPT-5.6に導入された Programmatic Tool Calling（プログラマティックツール呼び出し）は、モデル自身が軽量なプログラムをメモリ内で作成・実行し、ツール連携や中間結果の処理を自律的に進める仕組みだ。開発者が全ステップをスクリプト化する必要はなく、大量の中間データから必要な情報だけを抽出して次のアクションを判断する。
この仕組みにより、ツールを多用するワークフローでのトークン消費と往復回数が大幅に削減される。Responses APIで利用可能で、Zero Data Retention（ZDR）にも対応している。
max・ultra設定で複雑タスクを加速
GPT-5.6は効率重視のデフォルト動作に加えて、難易度の高いタスクに対して計算リソースを集中的に投下する設定を備える。max設定はxhighより長時間の推論と検証を許容し、ultraは並列エージェントで処理を高速化する。APIの価格帯は Sol が入力100万トークンあたり5ドル、出力同30ドルと公表されている。
コーディング性能の飛躍～開発者にとってのGPT-5.6
GPT-5.6 Solは現時点で最強のコーディングモデルと位置づけられている。Artificial Analysis Coding Agent Indexでは、max推論設定でスコア80を達成し、Claude Fable 5を2.8ポイント上回った。出力トークン数は半分未満、所要時間も半分以下、推定コストは約3分の1減という結果だ。
実コードベースでの強さ～DeepSWEとTerminal-Bench
GPT-5.6の優位性は、実コードベースでの長期エンジニアリングタスクを評価するDeepSWE v1.1やTerminal-Bench 2.1でも確認されている。Terminal-Bench 2.1ではSolが88.8%、ultra設定では91.9%に達し、GPT-5.5（85.6%）やClaude Fable 5（83.1%）を明確に引き離した。
複雑なコマンドラインワークフローを自律的に処理できるようになったことで、開発者がスクリプトの細部を逐一指示する必要は減り、「何を実現したいか」の指示だけで作業が進む体験に近づいている。
知識労働とデザイン判断力の進化
GPT-5.6は知識労働の質でも段違いの進化を見せる。Slack、Notion、Microsoft 365、Google Driveといった日常ツールから雑多な文脈を取り込み、専門家レベルの成果物に変換する能力が強化された。
プレゼンテーション・文書作成の実力
特に顕著なのがプレゼンテーション作成能力だ。GPT-5.6はプロンプトとソース資料から完全に編集可能なスライドを一から生成できる。レイアウト、階層構造、デザインの一貫性を備えた視覚的ナラティブを構築し、テンプレートやリファレンスデッキがある場合は、スライドマスターに埋め込まれたデザインルールさえ推論して適用する。
OpenAIの比較事例では、GPT-5.5が参照ファイルのマスタースライドコンポーネントを欠落させたのに対し、GPT-5.6はレイアウト・タイポグラフィ・配色・コンテンツパターンを忠実に再現した。文書やスプレッドシートでも、複雑な参照フォーマットの遵守、数式や財務モデルの精度、ページレイアウトの洗練度が向上している。
コンピュータ操作とUIデザインの判断力
GPT-5.6のコンピュータ操作能力は、コード生成にとどまらず、レンダリング結果の視覚的検証と改善までカバーする。高水準の指示だけで機能的かつ洗練されたUIを作成し、仕上がりを目視確認してから納品するフローが可能になった。BrowseCompではスコア92.2%と競合を上回り、OSWorld 2.0では62.6%を達成しながら出力トークン数を85%削減している。
セキュリティと安全性～進化した防護策
GPT-5.6はサイバーセキュリティ領域で飛躍的な性能向上を示した。ExploitBenchではGPT-5.5の47.9%から73.5%へ、ExploitGymでは15.1%から24.9%（2時間制限、6時間では33.7%）へと大幅に改善している。
デュアルユースを前提とした安全性設計
サイバーセキュリティは本質的にデュアルユース（両義的利用）の領域だ。脆弱性をつく能力が高まれば、同時にそれを見つけて修正する防御能力も高まる。OpenAIは「過剰なブロックは防御側の活動を阻害し、攻撃者は他のモデルやオープンソースツールを使い続ける」との立場をとっている。
そのためGPT-5.6の安全策は、一律ブロックではなく、リクエストの文脈と想定される結果を評価する多層構造を採用した。モデル内部に訓練された保護機能に加え、リアルタイムチェック、継続的モニタリング、アカウントレベルの制御が重層的に機能する。最も機微な能力はOpenAI DaybreakのTrusted Access for Cyberプログラムを通じて、認証済みの利用者のみに提供される。
約70万GPU時間のレッドチーミング
一般提供に先立ち、OpenAIは過去最大規模の安全性評価を実施した。外部専門家によるレッドチーミングに加え、約70万A100e GPU時間を投じたブラックボックス型の自動レッドチーミングで弱点を体系的に探索した。GPT-5.6 Solのサイバーセーフガードは、GPT-5.5比で約10倍の有害活動をブロックしている。
提供形態と価格～ChatGPT・Codex・APIのロールアウト
GPT-5.6は7月9日から全世界で段階的に提供が開始され、24時間以内に全ユーザーへの展開が完了する予定だ。
Free/Go Terraを利用可能
Terra $2.50 input / $15 output
Luna $1 input / $6 output
ChatGPTでは、Plus・Pro・Business・EnterpriseユーザーがGPT-5.6 Solに中〜高エフォート設定でアクセスできる。ProとEnterpriseは最高品質のSol Proも選択可能だ。Codexでは、Plus以上でSol・Terra・Lunaを選択でき、ultraはProとEnterpriseが利用できる。
APIの価格体系は前世代と比べて明確な選択肢を提供する。TerraとLunaの登場により、予算やタスクの重要度に応じて同じGPT-5.6アーキテクチャの恩恵を受けながら、コストを最適化できるようになった。
AI研究の自己加速～内部導入で見えた効果
OpenAIの社内では、GPT-5.6のテスト期間中に研究者1人あたりの1日平均出力トークン数がGPT-5.5のピーク時の2倍以上に達した。過去6カ月間で社内の研究向けコーディング推論の計算リソース消費は100倍に、エージェント型トークン利用は約22倍に増加している。
OpenAIはこの再帰的自己改善能力を「RSI Index」という内部評価指標でスコア化しており、GPT-5.6 SolはGPT-5.5から16.2ポイントの改善を示した。研究デバッグ、カーネル最適化、機械学習実験の自動化など、AIがAIの開発を加速する好循環が始まっている。
この記事のポイント
- GPT-5.6はSol・Terra・Lunaの3モデル構成で、フラッグシップから低コストまで用途に応じた選択が可能
- コーディング・知識労働・サイバーセキュリティ・科学研究の全領域でGPT-5.5を大幅に上回る性能を達成
- 消費トークン数とコストの大幅削減により、同一予算での成果最大化を実現
- 並列エージェントのultra設定やProgrammatic Tool Callingで複雑タスクの自律処理が加速
- 約70万GPU時間のレッドチーミングを含む多層的安全策で、防御的利用を阻害せずに悪用を抑制
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.0でget_queried_object()がショップページでもWP_Postを返す改善
WooCommerce 11.0より、ショップページで get_queried_object() を呼び出した際の戻り値の型が WP_Post_Type から WP_Post に統一される。これまでショップページだけが例外的に商品の投稿タイプオブジェクトを返していたが、今回の変更でWordPress標準の挙動と一貫性が保たれることになる。
この修正は、WooCommerceが内部的に管理するクエリの取り扱いをWordPressコアに合わせるもので、テーマやプラグインの開発者が「ショップページかどうか」を意識せずに get_queried_object() を扱えるようにする狙いがある。フロントページにショップページを設定している場合も同様の挙動となる。
WooCommerce 11.0のショップページ改善
get_queried_object() は現在のWordPressクエリに対応するオブジェクトを取得する標準関数だ。通常の固定ページや投稿ページでは WP_Post オブジェクトを返すが、これまでのWooCommerceではショップページに限り WP_Post_Type オブジェクト、つまり商品（product）の投稿タイプ情報を返していた。この不一致が開発者にとって混乱の元となっていた。
WooCommerce Developer Blogの説明によれば、ショップページで get_queried_object() を呼び出して「商品アーカイブであること」を判定するコードを書いていた場合、この変更の影響を受ける可能性がある。逆に言えば、今回の修正で is_shop() のような条件分岐タグと get_queried_object() の戻り値の関係が整理され、より直感的なコードが書けるようになる。
この変更の背景には、WordPressの「投稿ページ」設定と同様にショップページでも WP_Post を返すべき、という設計上の判断がある。WooCommerce 11.0ではこの長年の不一致が解消され、より予測しやすいAPIへと改善された。
影響を受けるコードの判断方法
自作のテーマやプラグインでショップページのクエリオブジェクトを参照している場合、以下のいずれかの関数やプロパティを使用していないか確認する必要がある。
get_queried_object()を呼び出しているget_queried_object_id()を呼び出している$query->queried_objectに直接アクセスしている$query->queried_object_idに直接アクセスしている
これらのコードがショップページ上で実行され、戻り値として WP_Post_Type オブジェクトを期待しているなら、WooCommerce 11.0へのアップデート後に動作が変わる可能性が高い。とくに、queried_object->labels->name などのプロパティに依存している場合は要注意だ。
Before / After コードの比較
具体的なコードの違いを見てみよう。以下はショップページでの get_queried_object() の戻り値の変化を示している。
// WooCommerce 10.x まで Shopページのみ例外
get_queried_object(); // → WP_Post_Type
get_post_type_object( 'product' ); // → WP_Post_Type
// その他の固定ページ
get_queried_object(); // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Type// WooCommerce 11.0 以降 Shopページも含めて統一
get_queried_object(); // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Typeこの変更の影響を受けないケース
次のような状況では、WooCommerce 11.0の変更による影響はなく、既存のコードはそのまま動作する。
- 単一の商品ページ（
single-product）では引き続き商品のWP_Postオブジェクトが返る - 商品カテゴリやタグ、ブランド、属性などのタクソノミーページでは
WP_Termオブジェクトが返る - その他の投稿タイプアーカイブや個別ページはもともと変更の対象外
is_shop()やis_archive()、is_post_type_archive( 'product' )といった条件分岐関数の挙動は従来どおり変わらない
開発者が取るべき具体的な対応
もし既存のコードがショップページで get_queried_object() の戻り値を WP_Post_Type として扱っている場合、WooCommerce 11.0へのアップデートに備えて改修が必要だ。修正の基本方針は「オブジェクトの型をチェックしてからプロパティにアクセスする」ことにある。
商品の投稿タイプ情報を取得する推奨方法
商品の WP_Post_Type オブジェクトが必要な場合は、get_post_type_object() を使うのが安全で推奨される方法だ。この関数はWooCommerceのバージョンに関係なく常に正しいオブジェクトを返す。
$product_post_type = get_post_type_object( 'product' );
if ( $product_post_type instanceof WP_Post_Type ) {
// 商品のWP_Post_Typeオブジェクトは
// get_post_type_object() から引き続き取得できる
$singular_name = $product_post_type->labels->singular_name;
}ショップページのWP_Post情報を扱うコード例
ショップページ自体の情報（ページタイトルやスラッグなど）を取得したい場合は、WooCommerce 11.0以降は get_queried_object() から直接 WP_Post としてアクセスできるようになる。以下はその典型的な使用例だ。
$shop_page = get_queried_object();
if ( $shop_page instanceof WP_Post ) {
// WooCommerce 11.0以降、ショップページでも
// WP_Postとして扱える
$shop_title = $shop_page->post_title;
$shop_slug = $shop_page->post_name;
}get_queried_object() / $query->queried_object を使っている箇所を特定するWP_Post_Type として使っているか確認する（ instanceof や型チェックをしていない場合）get_post_type_object( 'product' ) で商品の投稿タイプ情報を個別に取得し、既存コードを書き換える重要なのは、get_queried_object() の戻り値に依存した条件分岐を書く前に、必ず instanceof でオブジェクトの型をチェックする習慣をつけることだ。これにより、WooCommerceの将来のアップデートや他のプラグインとの競合にも強いコードになる。
この記事のポイント
- WooCommerce 11.0ではショップページの
get_queried_object()がWP_Postを返すように統一される - 商品の投稿タイプ情報が欲しい場合は
get_post_type_object( 'product' )を使用する is_shop()などの条件分岐関数の挙動は変わらないため、ページ判定ロジックの修正は不要- 影響を受けるコードは、おもにショップページでクエリオブジェクトのプロパティに直接アクセスしている箇所
- アップデート前に
instanceofによる型チェックを追加し、テスト環境で検証するのが安全な移行手順
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
OpenAIがコード評価ベンチマークの30%に欠陥を発見、SWE-Bench Pro監査結果
コード生成AIの能力を測るベンチマークは、モデルの安全性と展開判断の重要な根拠となる。そのベンチマーク自体に欠陥があれば、過大評価や過小評価を招き、誤った研究優先順位や安全性の見落としにつながる。
OpenAIが2026年7月、広く使われているコード評価ベンチマーク「SWE-Bench Pro」の大規模な監査結果を公開した。タスク全体の約30%に「破損（broken）」と呼ぶべき根本的な問題があり、評価指標としての信頼性が揺らいでいるという。
SWE-Bench Proとは何か
SWE-Bench Proは、AIモデルのソフトウェア開発能力をより現実的なタスクで測るために作られたベンチマークだ。前身のSWE-bench Verifiedが抱えていた設計上の問題やデータ汚染（contamination）を受け、より長期のタスクと実践的なコーディング能力を評価できるように設計されている。
具体的には、GitHub上の公開・非公開リポジトリから実際の機能変更履歴をもとにタスクを抽出する。モデルは既存の機能を壊さずに新機能を実装し、追加されたテストケースをすべて通過するコードを書く必要がある。公開されている731のタスクに対し、わずか8カ月で最先端モデルの合格率は23.3%から80.3%に急上昇した。
上の図は、SWE-Bench Proで見つかった「過度に厳格なテスト」と呼ばれる破損パターンを簡略化したものだ。プロンプトでは「ログイン機能」とだけ指示されているのに、裏側のテストでは特定のライブラリ使用を強制している。こうしたタスクでは、機能的に正しいコードが機械的に不合格になる。
監査で明らかになった破損タスクの実態
データの3割が信頼できない
OpenAIの監査パイプラインは、731件の公開タスクのうち200件（27.4%）を破損としてフラグした。さらに経験豊富なソフトウェアエンジニア5名による独立した人間レビューでは、249件（34.1%）が破損と判定されている。単純計算で、評価データの約3割がモデルの真の実力を反映していないことになる。
この数字の意味は重い。8カ月で合格率が約3.4倍に向上したという華々しい進歩の裏で、点数を押し上げた要因の一部が「タスク側の欠陥をうまくすり抜ける能力」だった可能性を否定できないからだ。
4つの主要な破損カテゴリ
監査で特定された問題は、大きく4つのタイプに分類される。いずれも「モデルが正しくコーディングできたか」ではなく「テストの書き方やプロンプトの不完全さ」が合否を決めてしまうパターンだ。
- 過度に厳格なテスト（Overly strict tests）: プロンプトには書かれていない特定の実装詳細（使用するライブラリ、関数名、データ構造など）をテストが要求する。機能としては正しいコードが不合格になる。
- 要件不足のプロンプト（Underspecified prompts）: プロンプトに記載されていない要件が隠しテストで課せられている。しかも、周辺コードやリポジトリの慣習からも合理的に推測できない内容だ。
- 低カバレッジのテスト（Low-coverage tests）: テストが機能のごく一部しか検証しておらず、不完全な実装でも合格してしまう。
- ミスリーディングなプロンプト（Misleading prompt）: プロンプトの指示がテストの要件と矛盾している。モデルが指示通りに実装すると不合格になるという、本末転倒な状態。
特に注目すべきは、人間レビューとエージェントによる自動分析で頻度の評価が異なった点だ。最も顕著な差が出たのが「低カバレッジのテスト」で、エージェントが4.1%と評価したのに対し、人間レビューでは9.4%がこれを主な問題として指摘した。人間の方が複数の破損パターンの重なりを認識しやすいことが一因とみられる。
品質監査パイプラインの仕組み
3段階のフィルタリング
OpenAIが構築した監査プロセスは、大きく3つの段階で構成されている。
第1段階は自動フィルタリングだ。プロンプトの指示内容、モデルの解答試行、採点用テストの3つを照合し、矛盾や問題のありそうなタスクを機械的に抽出する。この段階で286件がフラグされた。
第2段階はエージェント支援の詳細監査。Codexベースの調査エージェントがリポジトリ環境にアクセスし、テストの実行、ファイルの精査、モデルの解答パターンと失敗モードの分析を繰り返す。周辺コードやリポジトリの慣習を理解した上で「単なる曖昧さ」と「真の要件不足」を区別する点がポイントだ。
第3段階は経験豊富なソフトウェアエンジニア5名による独立レビュー。各タスクについて、問題文、テストケース、正解パッチを検討した後に、エージェントの分析結果を補足情報として参照する。意見が分かれたり確信度の低いケースは追加レビューに回された。
この3段階構成で特筆すべきは、AIエージェントと人間のダブルチェック体制だ。AIだけでは保守的になりがちな判定を、複数人の専門家が補完する。OpenAI Blogの記事によれば、エージェントが「破損でない」と判断したタスクで、人間レビューで最も多いラベルが「破損」だったケースはゼロだったという。74%のケースで両者の判断は重なっていた。
なぜ破損タスクが生まれるのか
根本的な原因は、SWE-Benchシリーズのタスク抽出方法にある。GitHub上の実際のIssueやプルリクエストは、元々人間同士の協業のために書かれたものだ。メンテナーとコントリビューターの間で長いやり取りを経て仕様が固まり、コードがマージされる。
このプロセスでは、問題文とマージされたコード、添付されたユニットテストがきれいに一対一対応するとは限らない。テストは「その変更が正しいか」を検証するために書かれており、「同じ機能を実現する他の方法」を許容するようには設計されていないケースが多い。つまり、人間用の協業ツールをそのままAI評価用に流用したことに、そもそも無理があったというのが実態だ。
ベンチマーク設計の難しさと今後の展望
「難しくて公平」なベンチマークのジレンマ
評価の難易度と公平性はトレードオフの関係にある。難しくしようとすればタスクは複雑になり、意図せず特定の実装方法に依存したテストが紛れ込む。公平にしようとすればタスクは抽象的になり、現実のソフトウェア開発から乖離する。
SWE-Bench Proのケースは、このジレンマに真っ向から直面した好例だ。最先端モデルの合格率が80%を超えた段階で「さらに難しい評価が必要」という圧力がかかる一方、タスクの質を担保する仕組みが追いついていなかった。
AIエージェントによる品質チェックの可能性
今回の監査自体が、AIエージェントの新しい活用方向を示している。Codexベースの調査エージェントは、大量のタスクに対してテスト実行やリポジトリ精査を高速に繰り返し、人間だけではスケールしない品質チェックを実現した。
従来、ベンチマークの品質管理は人手に頼る部分が大きく、大規模なデータセットでは現実的ではなかった。OpenAIの事例は「AIがAIの評価基準をチェックする」というメタ評価の時代の到来を感じさせる。
これからのベンチマーク開発に求められるもの
OpenAIは今回の監査結果を受け、SWE-Bench Proを推奨するという以前の見解を撤回した。同時に、評価コミュニティ全体に向けて、経験豊富なソフトウェア開発者がAI評価専用にベンチマークを設計するアプローチを提唱している。
重要なのは「ゲーム化されにくく」「信頼でき」「本当のモデル能力を反映する」評価基盤だ。それが安全性判断や展開戦略の土台になるからだ。SWE-Bench Proの教訓は、どんなに広く使われているベンチマークでも、定期的な品質監査が欠かせないというシンプルな事実に尽きる。
この記事のポイント
- SWE-Bench Proの公開タスク731件のうち、約30%が破損していると判明した
- 問題は「過度に厳格なテスト」「要件不足のプロンプト」「低カバレッジテスト」「ミスリーディングなプロンプト」の4カテゴリに分類される
- OpenAIは3段階の品質監査パイプライン（自動抽出 → AIエージェント調査 → 人間レビュー）で問題を特定した
- ベンチマークの定期監査と、AI評価専用に設計されたデータセットの必要性が改めて浮き彫りになった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0.1でクラシックエディタ保存できない時の原因と直し方
WordPress 7.0.1 更新後にクラシックエディタや WPBakery などのページビルダーで投稿や固定ページを保存できない、下書きが消えるといった症状は、PHP 8.4 との互換性問題が原因だ。PHP バージョンを 8.3 以下に切り替えればこの問題は解消する。
クラシックエディタで保存できずリダイレクトされる現象の正体
WordPress 7.0.1 に更新した直後から、クラシックエディタプラグインを有効化していると「公開」「下書き保存」をクリックしても保存されず、投稿一覧にリダイレクトされてしまう。保存したはずの記事や固定ページは一覧からも消え、下書きにも残らない。
さらにややこしいのは、ブロックエディタ（Gutenberg）では問題なく保存できるという点だ。クラシックエディタのプラグインを無効化せずとも、ブロックエディタ側で開いて操作すれば保存は成功する。このため一見すると「特定のプラグインだけが壊れている」ように見えるが、実際にはクラシックエディタ系や WPBakery など旧来の編集画面に依存するツール全般で同じ症状が出る。
この現象はプラグイン側の不具合ではなく、WordPress コアが動作する PHP のバージョンに起因する。特に PHP 8.4 環境で顕在化しやすい。
なぜ PHP 8.4 でクラシックエディタが動作しなくなるのか
根本原因は PHP 8.4 で廃止または挙動が変更された関数や構文が、クラシックエディタの編集画面や保存処理の中で使われていることにある。古いエディタ画面は WordPress コアの一部として動作するが、その内部処理が新しい PHP の厳格な型チェックや廃止予定の警告（Deprecated）に引っかかり、画面遷移やデータ保存に失敗する。
たとえば、PHP 8.4 では暗黙の nullable 型宣言が非推奨になり、引数のデフォルト値や型宣言の扱いが厳密化された。WordPress の管理画面まわりには長い歴史を持つコードが多く、こうした細かな PHP の変更に対してすべてのプラグインやテーマが追随できているわけではない。
ブロックエディタが正常に動作するのは、ブロックエディタの保存処理が REST API を経由し、比較的新しいコードベースで実装されているため、PHP 8.4 の影響を受けにくいからだ。
PHP バージョンを 8.3 に切り替えて問題を解消する
現時点で最も確実な対処法は、サーバーの PHP バージョンを 8.3 にダウングレードすることだ。PHP 8.4 はリリースされたばかりで、WordPress エコシステム全体の完全な互換性が確保されるまでは安定動作が見込める 8.3 を使うほうが無難である。
クラシックエディタ保存不可 → 一覧にリダイレクト → 記事消失
クラシックエディタ正常保存・下書きも残る
多くのレンタルサーバーではコントロールパネル（cPanel や独自管理画面）から簡単に PHP バージョンを切り替えられる。
サーバー管理画面での具体的な操作
cPanel を使っている場合は「PHP の選択」または「MultiPHP Manager」といったメニューを探す。対象ドメインを選択し、ドロップダウンメニューから「PHP 8.3」を選んで保存するだけだ。変更は数分以内に反映される。
独自の管理画面を提供しているサーバーでも、多くの場合「PHP 設定」「PHP バージョン管理」といった項目がある。もし見つからなければサーバー運営会社のサポートに「PHP バージョンを 8.3 に変更したい」と伝えれば対応してくれるケースが多い。
変更前に現在の PHP バージョンを確認する
WordPress 管理画面の「ツール」→「サイトヘルス」→「情報」タブを開き、「サーバー」セクションを見ると現在の PHP バージョンが表示されている。ここで 8.4 以上であれば今回の問題に該当する可能性が高い。
PHP 8.3 への切り替えでも直らない場合の追加確認
ごくまれに、PHP バージョンを下げても問題が続くことがある。そんなときは次の3点を順に確かめる。
ブラウザキャッシュと WordPress キャッシュのクリア
PHP の変更後にブラウザのキャッシュが残っていると、古い JavaScript や CSS で画面が正しく動作しないことがある。ブラウザのキャッシュを削除するか、シークレットウィンドウで管理画面を開き直す。また、WordPress 側でキャッシュプラグインを使っている場合はそのキャッシュもすべて削除する。
管理画面で JavaScript エラーが出ていないか調べる
ブラウザの開発者ツール（F12 キー）を開き、「コンソール」タブで赤いエラーが出ていないか確認する。保存ボタンを押した瞬間に何らかの JavaScript エラーが記録されていれば、それが原因の手がかりになる。
WordPress のデバッグモードでログを取得する
wp-config.php に以下のコードを追加してデバッグモードを有効にすると、保存時のエラーが wp-content/debug.log に記録される。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);ログに「Deprecated」や「Fatal error」が記録されていれば、それが直接の原因を示している。ただし、大半のケースでは PHP 8.3 への切り替えだけで問題が解消するため、ログを調べるのはレアケースの最終手段と考えてよい。
よくある質問
PHP 8.3 に戻すとセキュリティ面で問題はないか
PHP 8.3 は現在もアクティブサポートが継続しており、セキュリティ修正は提供され続けている。WordPress 公式の推奨バージョンでもあるため、本番環境で使っても安全だ。無理に最新の 8.4 に上げるよりも、安定した 8.3 で運用するほうが結果的にリスクが低い。
PHP 8.3 に変更したのにクラシックエディタがまだ使えない
PHP の変更がサーバーに完全に反映されるまで数分かかることがある。まずは数分待ってから再度試す。それでも改善しない場合は、一度プラグインを無効化して再度有効化してみる。また、前述のキャッシュクリアも忘れずに行う。
WPBakery や他のページビルダーでも同じ症状が出るのか
出る。クラシックエディタだけでなく、WPBakery をはじめとする旧型の編集画面を使うページビルダー全般が PHP 8.4 の影響を受ける。これらもブロックエディタと異なり、内部の保存処理が古いコードに依存しているためだ。
PHP バージョンを自由に変更できないサーバーではどうすればいいか
サーバー管理画面に PHP バージョンの変更オプションがない場合は、サーバー運営会社のサポートに連絡して「PHP 8.3 への切り替えを依頼したい」と伝える。ほとんどの会社は対応してくれる。もし変更ができないと言われた場合は、PHP 8.4 の環境でも動作するように WordPress のアップデートを待つか、ブロックエディタに一時的に切り替えて運用するしかない。
この記事のポイント
- WordPress 7.0.1 でクラシックエディタ保存不可になる原因は PHP 8.4 の互換性問題
- PHP バージョンを 8.3 に下げると問題は即座に解消する
- ブロックエディタは PHP 8.4 でも正常に動作するため一時的な回避策になる
- 変更後はブラウザキャッシュと WordPress キャッシュを忘れずにクリアする
- PHP 8.3 は公式推奨でありセキュリティ面でも安全に運用できる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている