年別アーカイブ 2026年8月18日

  1. ホーム   /  2026 ( 固定ページ10 )
Google Cloudが2029年までに耐量子暗号へ完全移行。PQCロードマップの全容と企業が取るべき3ステップ
2026年8月17日 0

Google Cloudが2029年までに耐量子暗号へ完全移行。PQCロードマップの全容と企業が取るべき3ステップ

Google Cloudが2026年8月11日、2029年までに耐量子暗号（PQC / Post-Quantum Cryptography）へ完全移行するためのロードマップを公開した。量子コンピュータによる将来の暗号解読リスクに備え、APIエンドポイントやロードバランサーの対応はすでに始まっている。

今回の発表では、移行戦略の3つの重点領域、2026年に完了した基盤整備、2027年から2028年にかけてのドメイン別計画が示された。企業が今すぐ着手すべき3つのステップも提示されている。

量子コンピュータが実用化されれば、現在広く使われているRSAやECDSAなどの公開鍵暗号は解読可能になる。その影響はクラウドサービス全体に及ぶ。本記事では、Google CloudのPQCロードマップの全容と、企業に求められる対応を整理する。

PQC移行の全体像と2029年目標

PQC移行の全体像と2029年目標

Google CloudのPQC移行戦略は「セキュアバイデザイン」を基本方針とする。設計段階から量子安全を組み込むアプローチであり、単なる後付けの対策ではない。Google Quantum Threat Modelという独自の脅威モデルを土台に、3つの重点領域で保護を進める。

SNDLリスクとは何か

SNDL（Store Now, Decrypt Later）は「今保存して後で復号する」攻撃だ。攻撃者が現在の暗号化通信を傍受してデータを蓄積しておき、量子コンピュータが実用化された時点で一括して復号する。今日の暗号化データが将来の量子コンピュータで解読されるリスクは、すでに現実のものとなっている。

これがPQC移行を急ぐ最大の理由だ。機密データの保存期間が数十年に及ぶ場合、現在の暗号化方式のままでは将来の解読リスクを抱え続けることになる。特に金融機関や政府機関、医療機関では、このリスクへの対応が喫緊の課題だ。

従来の暗号化（Before）
暗号化データ 送信 → 攻撃者が傍受
攻撃者は現在の暗号化通信を傍受し、データを蓄積する。量子コンピュータが実用化されれば、保存済みのデータをすべて復号できる。
↓
PQC導入後（After）
暗号化データ 送信 → ML-KEM量子安全鍵交換
量子安全な鍵交換方式（ML-KEM）を採用し、傍受されても将来の量子コンピュータでは復号できない。

このデモはSNDL攻撃のリスクとPQCによる防御の違いを示している。攻撃者がどれだけデータを蓄積しても、量子安全な鍵交換を使っていれば将来の解読は不可能になる。

Googleが定める3つの重点領域

Google CloudがPQC移行戦略で優先するのは、以下の3領域である。

  • SNDLリスクの緩和。現在の暗号化データが将来の量子コンピュータで解読されることを防ぐ。
  • 偽造に対する完全性の確保。デジタル署名を強化し、データやIDの偽造を防ぐ。
  • 暗号アジリティの基盤強化。暗号標準の進化に合わせて、新しい方式を最小限の工数で採用できる柔軟なシステムを構築する。

3番目の「暗号アジリティ」は特に重要だ。暗号標準は今後も進化し続ける。特定のアルゴリズムに依存せず、新しい標準が出たら容易に切り替えられる仕組みがあれば、将来の移行コストを大幅に抑えられる。Googleはこの基盤への投資を戦略の中核に置く。

Google Cloudは規制期限を待たずに、内部インフラと顧客向けサービスのPQC移行を前倒しで進めている。2029年の完全対応を目標に、Sovereign Cloudの取り組み（Google Cloud DedicatedやGoogle Distributed Cloud）にもPQCソリューションを展開中だ。

2026年に完了した基盤整備

2026年に完了した基盤整備

2026年時点で、すでに複数の基盤的マイルストーンが達成されている。これらは顧客に対して即座の保護を提供するものだ。

APIエンドポイントとロードバランサーの対応

Google CloudのAPIエンドポイントは、量子安全な鍵交換に対応した。google.comと*.googleapis.comの両方が、NIST標準化済みのML-KEM（FIPS 203）をハイブリッドモードで実装している。ハイブリッドモードとは、従来の暗号とPQCを併用する方式だ。互換性を保ちながら量子安全性を確保できる。

アプリケーションロードバランサーとプロキシロードバランサーも、TLS 1.3における量子安全ハイブリッド鍵交換（X25519MLKEM768）をサポートする。当初はオプトイン方式で提供され、顧客は既存アプリケーションへの影響を最小限に抑えながら検証を進められる。

さらに、ChromeとCloudflareが進めるMerkle Tree Certificatesの実験にも参画している。PQC署名をWebPKIに適用する際の課題（署名サイズの肥大化など）に対処する取り組みだ。

Cloud KMSのPQCアルゴリズム一般提供

Cloud KMSでは、NIST標準化済みのPQCアルゴリズム（ML-KEM、ML-DSA、SLH-DSA）が一般提供（GA）に達した。暗号化鍵と署名鍵の両方で量子安全なアルゴリズムを利用できる。

これは企業にとって大きな意味を持つ。既存のCloud KMS利用者は、新しいPQCアルゴリズムを試すために特別な準備をする必要がない。すでに一般提供されているため、本番環境での利用も可能だ。

ドメイン別ロードマップ（2027〜2028年）

ドメイン別ロードマップ（2027〜2028年）

Google Cloudは2029年の完全対応に向けて、リスクベースのアプローチで3つのドメインを定義した。各ドメインには目標完了時期が設定されている。サービスによって個別のタイムラインは調整される可能性があるが、大多数のサービスは目標時期に合わせて移行を完了する見込みだ。

2026 基盤整備完了
APIエンドポイント、ロードバランサー、Cloud KMSのPQC対応が完了
↓
2027 ドメイン1 SNDL対策
顧客ワークロード、管理者フロー、データパイプラインの量子安全なTLS対応
↓
2028 ドメイン2・3 完全性と鍵管理
ソフトウェアサプライチェーン、量子安全な証明書、ID・アクセス保護、Cloud HSM対応
↓
2029 完全対応
Google Cloud全体でポスト量子レディネスを達成。2030年代も標準化対応を継続

このタイムラインは、Google CloudのPQC移行が段階的に進むことを示している。2026年の基盤整備から始まり、2027年には通信経路の保護、2028年には署名と鍵管理、2029年に全体の収束を目指す。

ドメイン1 SNDL対策（2027年目標）

ドメイン1は非対称暗号の脆弱性に対処する。将来の量子コンピュータが今日の暗号化データを復号するリスクを防ぐのが目的だ。対象となるのは以下の3つの経路である。

  • 顧客ワークロードの保護。Google Cloudサービスとロードバランサーに量子機密TLS 1.3ハンドシェイクを提供する。
  • 管理者・開発者フローの保護。Cloud VPNやInterconnectを含む管理者経路をSNDLから守る。開発者向けにはクライアントライブラリ、SDK、オープンソース暗号ライブラリのTinkを対応させる。
  • データパイプラインの保護。分析・ストレージプラットフォームのデータ転送を保護し、機密情報が傍受・蓄積されても将来復号されないようにする。

このドメインの特徴は、通信経路の保護に焦点を当てている点だ。特にTinkの対応は重要である。TinkはGoogleが開発したオープンソース暗号ライブラリで、多くの開発者が利用している。TinkがPQCに対応することで、開発者はアプリケーションレベルで量子安全な暗号を容易に導入できる。

ドメイン2 完全性と否認防止（2028年目標）

ドメイン2はデジタル署名と証明の量子対応を扱う。量子コンピュータによる偽造攻撃からデータの完全性と信頼性を守る。3つの主要分野がある。

1つ目はソフトウェアサプライチェーンの保護だ。Binary Authorization、Cloud Build、Assured Open Source Softwareなどのサービスで、量子耐性のある証明（アテステーション）を導入する。信頼できる変更されていないイメージだけが本番環境で実行されることを保証する。

2つ目は量子安全な証明書の発行だ。内部および外部の認証局（CA）をML-DSA証明書に対応させる。状況に応じてSLH-DSA証明書もサポートする。IETF（Internet Engineering Task Force）の標準化に積極的に貢献しており、大規模な署名サイズ問題にはMerkle Tree Certificatesなどの新しいアプローチを検証中だ。

3つ目はIDとアクセスの保護である。サービスアカウントキーやトークン（JWT / OAuth）を量子偽造に対して耐性のある方式に移行する。

ドメイン3 基盤と鍵管理（2028年目標）

ドメイン3はPQC移行の土台となる暗号アジリティを扱う。ここでの投資が、ドメイン1と2の実現を支える。

基盤となる鍵管理とライブラリでは、Cloud KMSとBoringSSL、Tinkを通じてNIST承認アルゴリズムを有効にする。Cloud KMSはすでにML-KEM、ML-DSA、SLH-DSAの一般提供を開始しており、量子安全な鍵のインポートも準備中だ。

ハードウェアが関わる部分では、Confidential ComputingとCloud HSMにPQCを組み込む。量子的なルートオブトラストを確立し、物理的な基盤を保護する。OpenTitanやCaliptra v2.1、TPM 2.0 v185などのオープンソースシリコン基盤もPQC対応を進めている。

Google Workspaceのクライアントサイド暗号化（CSE）と外部鍵マネージャー（EKM）にもPQCオーケストレーションを導入する。オンプレミスの鍵プロバイダーとの連携も進める計画だ。

量子安全における共有責任モデル

量子安全における共有責任モデル

量子安全はGoogle Cloudと顧客の共同作業である。クラウドセキュリティの共有責任モデルがPQCにもそのまま適用される。

Google側の責任 クラウドのセキュリティ
ネットワーク、転送中の暗号化、グローバルフロントエンド、ALTSプロトコルのPQC移行。サーバーのハードウェアとOSの量子脅威対策も含む。OpenTitanによる量子安全ブート、Caliptra v2.1、TPM 2.0 v185などのシリコン基盤を活用する。
↓
顧客側の責任 クラウドの中のセキュリティ
自社アプリケーションの管理。クライアントソフトウェアをPQCハンドシェイク対応に更新し、非対称鍵のライフサイクルを管理する。Google Cloudサービスの設定を量子安全なものに変更する作業も必要だ。

この図は責任の境界を明確にしている。重要なのは、Google Cloud側のPQC対応が完了しても、顧客がクライアントソフトウェアを更新しなければ量子安全な接続は確立しない点だ。

Google側の責任範囲

Googleはサーバー、ネットワーク、転送中の暗号化、グローバルフロントエンド、ALTSプロトコルのPQC移行を一括して管理する。ハードウェアの移行は、積極的な交換と自然な機器更新サイクルを組み合わせて段階的に進める。物理コンポーネントの中には2029年を超えて移行が続くものもあるが、安定性を優先したフェーズドアプローチを取る。

顧客側の責任範囲

顧客は自社アプリケーションの管理に責任を持つ。クライアントソフトウェアをPQCハンドシェイク対応に更新すること、非対称鍵のライフサイクル管理、Google Cloudサービスの設定変更が含まれる。

ここが最も見落とされやすいポイントだ。インフラ側がPQC対応しても、クライアント側が古い暗号方式で接続すれば、量子安全性は確保されない。企業のセキュリティチームは、自社のクライアントソフトウェアがPQC対応済みかどうかを確認する必要がある。

企業が今すぐ着手すべき3つのステップ

企業が今すぐ着手すべき3つのステップ

Google CloudはPQC移行の第一歩として、企業が即座に着手できる3つのステップを提示している。どれも実務に直結する具体的なアクションだ。

  • 棚卸し（Inventory）。Cloud Asset InventoryやWizなどのツールを使って、鍵や証明書などの暗号資産を特定する。組織全体の暗号リソースをマッピングし、移行バックログの優先順位を定義する。
  • 更新（Update）。開発チームとSREチームが使うソフトウェアが、BoringSSL、Chrome、SDKなどPQCアルゴリズムに対応していることを確認する。エッジで量子安全接続が有効化された際に、社内ワークフローが準備できている状態を作る。
  • 検証（Validate）。Google Cloudの量子安全APIとロードバランサーを使って既存アプリケーションの挙動をテストする。本番環境に影響が出る前に、アーキテクチャ上のボトルネックを特定できる。

この3ステップは、PQC移行を「待つ」のではなく「準備する」アプローチだ。特に検証は重要である。量子安全なTLS接続は従来よりオーバーヘッドが大きい場合があり、アプリケーションのパフォーマンスに影響を与える可能性がある。事前のテストで課題を洗い出しておけば、本番移行時のリスクを大幅に減らせる。

この記事のポイント

  • Google Cloudは2029年までにPQC完全対応を目指し、ロードマップを公開した
  • SNDLリスク（今保存して後で復号）は企業にとって喫緊の課題である
  • 2026年時点でAPIエンドポイント、ロードバランサー、Cloud KMSのPQC対応が完了している
  • 3つのドメイン（SNDL対策、完全性確保、鍵管理基盤）で2027〜2028年に移行を進める
  • 企業は棚卸し、更新、検証の3ステップで今すぐ準備を開始できる
海田 洋祐
, , , , , ,
クラウド・インフラ
WordPressに勝手にインストールされるwp-flareマルウェアの感染経路と駆除方法
2026年8月17日 0

WordPressに勝手にインストールされるwp-flareマルウェアの感染経路と駆除方法

WordPressに「wp-flare」という身に覚えのないプラグインがインストールされていた場合、それはマルウェアによる不正侵入の痕跡だ。感染したプラグインファイルとデータベース上の登録を削除し、侵入経路を特定して塞ぐことが根本対策になる。

wp-flareマルウェアの感染経路はどこにあるのか

wp-flareマルウェアの感染経路はどこにあるのか

wp-flareは正規のプラグインディレクトリには存在しない、攻撃者が設置する不正なプラグインだ。このプラグインがインストールされるということは、すでに何らかの方法でサイトの管理者権限を奪われている、またはファイルを書き込む経路を確保されていることを意味する。

感染経路として最も多いのは、使用しているプラグインやテーマに存在する脆弱性の悪用だ。すべてのプラグインが最新版でも、サポートが終了した古いプラグインや、公式ディレクトリにない野良プラグインに脆弱性が残っているケースがある。攻撃者はこうした穴を突いて任意のファイルをアップロードし、不正なプラグインを設置する。

次に疑うべきは、管理者パスワードの漏洩や総当たり攻撃の成功だ。二段階認証（2FA）を導入していても、XML-RPC経由の認証試行や、別サイトから流出した同じパスワードを使い回している場合は突破されることがある。

複数サイトが同時期に感染する理由

異なるホスティングの複数サイトが同時期に感染する場合、共通して使っているプラグインやテーマ、管理ツールが感染源になっている可能性が高い。たとえば、同じ開発元が配布するプラグインの配布元が改ざんされていたり、管理用のパソコン自体がマルウェアに感染してFTPやSSHの認証情報を窃取されているケースもある。

感染経路の特定には、各サイトのファイル更新日時とアクセスログを突き合わせるのが有効だ。wp-flareのファイルが設置された日時を調べ、その前後に不審なPOSTリクエストやログイン試行がないかを確認する。

感染経路の候補
プラグインの脆弱性 → 任意ファイルのアップロード → wp-flare設置
パスワード漏洩 → 管理者ログイン突破 → プラグインインストール
FTP・SSH認証情報の窃取 → ファイル直接改ざん → wp-flare設置
■ 侵入の入口　■ 攻撃者の行動　■ 最終的な被害

上の図は感染に至る典型的な3つの経路を示している。どの経路であっても最終的にはwp-flareという不正プラグインが設置される点が共通している。

感染したサイトで最初に確認すべき症状

感染したサイトで最初に確認すべき症状

wp-flareに感染したサイトでは、管理画面のプラグイン一覧に「wp-flare」という名前の見慣れない項目が表示される。ただし攻撃者がプラグインの表示名を偽装している場合もあるため、一覧に表示されないこともある。

そのほか、以下のような症状が現れることがある。すべてに該当する必要はなく、1つでも当てはまれば感染を疑うべきだ。

  • サイトが知らないURLにリダイレクトされる
  • 検索結果に表示されるタイトルや説明文が書き換えられている
  • 管理画面の動作が急に重くなった
  • 見覚えのない管理者ユーザーが追加されている
  • サーバーに身に覚えのないファイルが増えている

最も確実なのは、サーバーのプラグインディレクトリ（wp-content/plugins/）を直接確認することだ。wp-flareという名前のフォルダが存在する場合は、マルウェア感染と断定してよい。

wp-flareマルウェアを駆除する手順

wp-flareマルウェアを駆除する手順

wp-flareの駆除は、プラグインファイルの削除だけでなく、データベース上の不正な登録や、設置されたバックドアの除去まで行う必要がある。以下の手順で進める。

STEP 1 サイト全体のバックアップを取得する
↓
STEP 2 wp-flareプラグインのフォルダを削除する
↓
STEP 3 データベースから不正な登録を削除する
↓
STEP 4 全ファイルをスキャンしてバックドアを除去する
↓
STEP 5 全パスワードと認証情報を変更する

この手順は上から順に実施する。途中でサイトが表示できなくなっても復旧できるよう、STEP 1のバックアップは必ず最初に行う。

wp-flareのプラグインフォルダを削除する

FTPソフトまたはホスティングのファイルマネージャーにログインし、wp-content/plugins/wp-flare ディレクトリを丸ごと削除する。管理画面からプラグインを「削除」しようとしても、プラグイン自体が無効化を妨害する仕組みを持っている場合があるため、ファイルシステム上から直接削除するのが確実だ。

削除後、管理画面のプラグイン一覧に「wp-flare」が表示されなくなることを確認する。もしプラグイン一覧にまだ表示される場合は、データベース側に登録が残っている可能性が高い。

データベースから不正な登録を削除する

WordPressのプラグイン情報は、データベースの wp_options テーブルにある active_plugins という項目で管理されている。不正プラグインがここに登録されていると、ファイルを削除しても管理画面に残り続ける。

phpMyAdminなどのデータベース管理ツールで wp_options テーブルを開き、option_name が active_plugins の行を探す。その値の中に wp-flare や wp_flare を含む文字列があれば、その部分を削除する。操作前にデータベースのバックアップを取得しておくこと。

バックドアの痕跡を全ファイルから探す

wp-flare本体を削除しても、攻撃者が別の場所にバックドア（再侵入用の隠しファイル）を設置している場合がある。主に以下の場所を確認する。

  • テーマディレクトリ内の見覚えのないPHPファイル
  • アップロードディレクトリ内のPHPファイル（画像のはずなのに拡張子がPHPになっているもの）
  • WordPress本体の wp-admin や wp-includes 内の改ざんファイル
  • サイトのルート直下に置かれた小さなPHPファイル

ファイル数が多い場合は、サーバー上で find コマンドを使って直近に変更されたファイルを抽出すると効率的だ。感染が確認された日時以降に更新されているPHPファイルを重点的に調べる。

find /path/to/wordpress -name "*.php" -mtime -30

このコマンドは、指定したWordPressディレクトリの中で過去30日以内に更新されたPHPファイルを一覧表示する。感染が判明した時期に合わせて日数を調整する。

全パスワードと認証情報を変更する

駆除が完了したら、侵入経路に関係なく以下の認証情報をすべて変更する。感染中に窃取されていた可能性を考慮し、同じパスワードの使い回しは避ける。

  • WordPress管理画面の全ユーザーのパスワード
  • FTP・SSHの接続パスワード
  • データベースの接続パスワード
  • ホスティングのコントロールパネルのパスワード
  • メールアカウントのパスワード

再発を防ぐためのセキュリティ対策

再発を防ぐためのセキュリティ対策

wp-flareを駆除しても、感染経路を塞がなければ再び同じ被害に遭う。特に複数サイトが同時期に感染した場合は、サイト単体の対策だけでなく、管理環境全体の見直しが必要だ。

使用中のプラグインとテーマを棚卸しする

すべてのサイトで使用しているプラグインとテーマの一覧を作成し、以下に該当するものがないか確認する。これらが感染源になっている可能性が高い。

  • 配布元が公式ディレクトリではないプラグイン
  • 更新が1年以上停止しているプラグイン
  • サイトの機能上不要になったプラグイン
  • 正規の配布元ではないサイトから入手したテーマ

不要なプラグインは削除し、更新が停止しているプラグインは代替品への移行を検討する。どうしても使い続ける必要がある場合は、開発元のセキュリティ情報を定期的に確認する。

管理用パソコンのマルウェアスキャンを行う

複数のサイトが同時期に感染した場合、サイトではなく管理用のパソコンが感染源になっている可能性がある。FTPやSSHの接続情報を保存しているFTPソフトの設定ファイルから認証情報が窃取され、攻撃者に悪用されるケースがある。

管理用パソコンで信頼できるアンチウイルスソフトのフルスキャンを実施し、FTPソフトやパスワード管理ソフトの保存データが漏洩していないか確認する。スキャン後は、保存済みのパスワードもすべて変更するのが安全だ。

Before FTPソフトに平文で保存された認証情報が窃取される
↓
After パスワードを変更し、FTPソフトの保存機能を使わない運用に切り替える

FTPソフトにパスワードを保存する機能は便利だが、マルウェア感染時には認証情報の流出経路になる。可能であれば、接続のたびにパスワードを入力する運用に切り替えるとリスクを減らせる。

ファイル変更の監視を導入する

感染の早期発見には、サーバー上のファイル変更を監視する仕組みが有効だ。WordPressのセキュリティプラグインには、ファイルの改ざんを検知して通知する機能を持つものがある。プラグインの新規インストールや、想定外のファイル変更があった場合にメールで知らせる設定にしておくと、被害が拡大する前に対処できる。

XML-RPCを無効化する

XML-RPCはWordPressの外部連携機能だが、総当たり攻撃やSSRF攻撃の入口として悪用されることが多い。外部サービスとの連携で使っていない場合は、無効化するのが効果的な対策になる。

セキュリティプラグインの多くにXML-RPCを無効化するオプションがある。もしくは、以下のコードをテーマの functions.php に追加する方法もある。

add_filter( 'xmlrpc_enabled', '__return_false' );

ただし、このコードは子テーマの functions.php に追加するのが基本だ。親テーマを直接編集すると、テーマ更新時にコードが消えるため注意する。

よくある質問

wp-flareは公式プラグインディレクトリに存在しないのか

存在しない。wp-flareはWordPress公式ディレクトリに登録されておらず、攻撃者が独自に設置する不正なプラグインだ。プラグイン一覧に表示される名前が同じでも、正規のプラグインと混同しないよう注意する。

管理画面からwp-flareを削除できない場合はどうするのか

管理画面からの削除ができない場合は、FTPまたはファイルマネージャーでサーバーに直接アクセスし、プラグインディレクトリからフォルダを削除する。削除後もプラグイン一覧に表示される場合は、データベースの active_plugins に残っている登録を手動で削除する必要がある。

感染したサイトのバックアップは復元に使えるのか

感染前のバックアップが確実に存在する場合は、バックアップからの復元が最も確実な駆除方法になる。ただし、バックアップ自体が感染後に取得されたものであれば復元しても意味がない。取得日時を必ず確認し、感染前のものを使う。

wp-flare対策に有効なセキュリティプラグインはあるのか

定期的なマルウェアスキャン、ファイル変更の監視、ログイン試行の制限、XML-RPCの無効化などを提供するセキュリティプラグインが有効だ。ただし、プラグインを導入するだけで完全に防げるわけではない。プラグインの棚卸しやパスワード管理など、運用面の対策と組み合わせることが重要になる。

同じパスワードを複数サイトで使い回してもよいのか

避けるべきだ。1つのサイトでパスワードが漏洩すると、同じパスワードを使うすべてのサイトが連鎖的に感染する原因になる。サイトごとに異なるパスワードを設定し、パスワード管理ソフトで一元管理するのが安全な運用だ。

この記事のポイント

  • wp-flareは攻撃者が設置する不正なプラグインだ
  • 感染経路はプラグインの脆弱性、パスワード漏洩、FTP認証情報の窃取が主な候補になる
  • 駆除はファイル削除とデータベースの掃除、バックドア除去まで行う
  • 複数サイトが感染した場合は管理用パソコンのマルウェアスキャンも必要だ
  • 再発防止にはプラグインの棚卸しとファイル変更の監視が有効だ
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WooCommerceのStripe決済が自動更新後に消えた時の原因と対処法
2026年8月16日 0

WooCommerceのStripe決済が自動更新後に消えた時の原因と対処法

WooCommerceのStripe決済プラグインを自動更新した直後に、設定画面の「決済」タブからStripeが丸ごと消えた場合は、更新時に発生した致命的エラーか、他の決済プラグインとの競合が主な原因だ。まず「ステータス」→「ログ」で fatal-errors の有無を確認し、競合を切り分けた後、キャッシュ削除と設定の再保存で復旧できる。セキュリティパッチ自体がStripe決済を意図的に隠すことはない。

Stripe決済が消える原因は何か

Stripe決済が消える原因は何か

Stripe決済プラグインのアップデート後に、WooCommerceの「設定」→「決済」画面からStripeの項目が消える現象には、いくつかの典型的な原因がある。セキュリティパッチの更新処理そのものがStripeを除外する仕様は存在しないため、まず「更新に伴って別の何かが壊れた」と考えるのが正しい。

最も多いのは、アップデート処理中に発生した致命的エラーだ。プラグイン更新時にPHPのメモリ不足やファイルの不整合が起きると、WooCommerceがプラグインを正常に読み込めなくなり、決済方法の一覧からStripeが消える。管理画面には「このサイトで重大なエラーが発生しました」と表示される場合もあれば、画面に何も表示されず設定一覧だけが欠けるケースもある。

次に多いのがプラグイン競合だ。複数の決済ゲートウェイ系プラグインを導入していると、アップデート後に読み込み順序が変わって競合し、Stripeが一覧から漏れることがある。WooCommerceの決済方法はフィルターを通して一覧に追加されるため、競合相手のプラグインがエラーを出すと後続の読み込みが止まり、Stripeが表示されない。

キャッシュが原因になるケースも見逃せない。アップデート直後にサーバーキャッシュやオブジェクトキャッシュへ古い状態が残っていると、管理画面の一覧にだけ反映されずStripeが消えて見える。ブラウザキャッシュでも同様の現象が起こる。

Before「Stripeが見つからない状態」
WooCommerceの「設定」→「決済」画面を開くと、有効な支払い方法の一覧にStripeが表示されない
↓
After「Stripeが復活した状態」
Stripeが一覧に再び表示され、チェックアウトでクレジットカード決済が利用できる
■ Stripeが消えた状態　■ 復旧後

このデモは、決済タブでStripeが消えた状態から復旧した状態への変化を示している。ここから先の手順を順に実行すれば、原因の特定と復旧まで進められる。

致命エラーログで原因を特定する手順

致命エラーログで原因を特定する手順

最初に確認すべきは、WooCommerceが記録している致命的エラーのログだ。管理画面の「WooCommerce」→「ステータス」→「ログ」タブを開くと、保存されているログの一覧が表示される。この中に fatal-errors で始まる名前のログがあれば、アップデート時になんらかの致命的エラーが発生している。

fatal-errors ログを開くと、エラーが発生した日時、原因となったプラグインやテーマ名、エラーが起きたファイルのパスが確認できる。Stripeプラグインのファイルパスが記録されていれば、そのエラーが原因で一覧から消えた可能性が高い。ログの内容は専門的なPHPの記述が多いが、どのプラグインでエラーが出たかを特定できれば十分だ。

ログに何も出ていない場合は、WP_DEBUG（デバッグモード）を有効にして再現させる方法もある。wp-config.php にデバッグ定数を追記してから決済設定画面をリロードすると、画面にエラー文言が直接表示される。ただし共用サーバーでは本番サイトでデバッグをオンにするとセキュリティ上望ましくないため、確認後は必ず元に戻す。

プラグインの競合を切り分ける

プラグインの競合を切り分ける

致命エラーログが出ていない、または出ていても原因が特定できない場合は、プラグイン競合の切り分けに進む。決済系プラグインを複数導入している環境では、どれか1つがStripeの読み込みを妨げている可能性がある。

切り分けの基本は「一度に全部を無効化しない」ことだ。Stripeを除く他の決済プラグインを1つずつ無効化し、そのつど「設定」→「決済」画面をリロードしてStripeが表示されるか確認する。たとえば「WooCommerce PayPal Payments」や「Amazon Pay」などを無効化するたびに確認を繰り返すと、競合相手を特定できる。

決済プラグインだけでなく、最近更新したプラグインやテーマも疑う。プラグインを全無効化してもStripeが表示されない場合は、テーマを標準テーマの「Twenty Twenty-Four」などに切り替えて同じ画面を確認する。テーマ側のフックが決済一覧を書き換えている例も過去にある。

STEP 1 致命エラーログを確認する
WooCommerceの「ステータス」→「ログ」で fatal-errors の有無を調べる
↓
STEP 2 プラグイン競合を切り分ける
他の決済プラグインを順に無効化して症状が直るか確認する
↓
STEP 3 サイトキャッシュを削除する
サーバーキャッシュとブラウザキャッシュを消して再読み込みする
↓
STEP 4 Stripe設定を再保存する
Stripe設定を開いて保存し直し、API接続が有効か確認する

このデモは、Stripe決済が消えたときに進めるトラブルシューティングの流れを示している。各ステップの詳細は本文の対応する見出しで確認できる。

キャッシュ削除と設定の再保存で復旧させる

キャッシュ削除と設定の再保存で復旧させる

競合の切り分けで原因が特定できた場合も、原因がまだ判明しない場合も、次に試すのはキャッシュの削除とStripe設定の再保存だ。この2つを実行するだけで、実害のない一時的な不整合が解消されてStripeが一覧に復活することが多い。

キャッシュ削除は、レンタルサーバーの管理画面で提供されているサーバーキャッシュ、WooCommerceのシステムが内部で使うオブジェクトキャッシュ、そして自分が閲覧しているブラウザのキャッシュの3つを対象にする。キャッシュ系プラグインを導入している場合は、そのプラグインの管理画面から全キャッシュを削除してから、決済設定画面をリロードする。

Stripe設定の再保存は、WooCommerceの「設定」→「決済」でStripeの項目が表示されていなくても実行できる場合がある。「決済」タブの一覧にStripeが出ていなくても、左メニューに「Stripe」の設定ページが残っていれば、そこを開いて「変更を保存」を押す。これにより設定値が再評価され、一覧に反映される。

設定を保存し直すと、StripeのAPI接続状態も再チェックされる。接続が切れていた場合は「接続」ボタンが表示されるため、そこからStripeアカウントに再接続できる。APIキーが無効になっている、あるいはテストモードと本番モードの切り替えが正しくない場合も、再接続で直るケースがある。

それでも直らない場合の追加チェック

ここまでの手順を実行してもStripeが一覧に表示されない場合は、環境そのものに問題がある可能性が高い。「WooCommerce」→「ステータス」→「システムステータス」を開き、WordPress本体、WooCommerce本体、PHPの各バージョンがStripeプラグインの推奨要件を満たしているか確認する。プラグイン更新後にPHPのバージョン要件が引き上げられ、サーバーのPHPが古いままだと読み込みに失敗することがある。

システムステータスレポートには、有効化している全プラグインの一覧と、WooCommerceが認識している各設定値がまとまっている。この中でStripeプラグインが「有効」になっているか、「非アクティブ」や「エラー」になっていないかを確認する。プラグイン一覧のページでStripeが有効化されていても、WooCommerce側で読み込めていない状態が可視化されることがある。

最終手段として、以前の安定したバージョンへロールバックする方法もある。プラグインの配布ページから過去バージョンのZIPファイルを取得して手動で上書きするか、「WP Rollback」のようなロールバック用プラグインを使って1つ前のバージョンへ戻す。ただしロールバックはセキュリティパッチを巻き戻すことになるため、あくまで復旧のための一時的な手段として扱い、原因を特定した上で最新版へ戻す計画を立てる。

よくある質問

Stripe決済が消えたのは自動更新の不具合か

自動更新自体がStripeを意図的に外すことはない。更新処理の中で発生した致命的エラーや、更新後に顕在化したプラグイン競合が原因であるケースがほとんどだ。ログを確認して切り分けることで特定できる。

セキュリティパッチによってStripeが意図的に隠されることはあるか

通常のセキュリティパッチがStripe決済を隠す仕様は存在しない。もしセキュリティ上の理由で決済方法が制限されるなら、公式リリースノートに明記される。リリースノートに記載がないのに消えた場合は、パッチの直接の影響ではなく別の要因を疑う。

Stripe Linkだけが表示されない場合は何を確認するか

Stripeゲートウェイ自体は表示されているが、Stripe Linkという特定の支払い方法だけが表示されない場合は、Stripe設定ページ内の「支払い方法」セクションでLinkが有効化されているか確認する。また、Stripeのアカウント側でLinkが利用可能な地域・通貨であるかも確認が必要だ。

システムステータスレポートのどこを見れば原因が分かるか

まず「環境」セクションでPHPとWooCommerceのバージョンが要件を満たしているか、次に「有効なプラグイン」でStripeが正常に読み込まれているか、そして「ログ」セクションでエラーが記録されていないかを順に確認する。レポートはサポートに共有する際にもそのまま使える。

プラグインを以前のバージョンに戻してもよいか

復旧を優先するなら一時的なロールバックは有効な手段だ。ただしセキュリティパッチを含む更新を巻き戻すため、原因を特定して修正した後は最新版へ戻すことが前提になる。ロールバック前に必ずサイト全体のバックアップを取る。

この記事のポイント

  • Stripeが決済一覧から消えた主因はupdate時の致命的エラーとプラグイン競合
  • セキュリティパッチ自体がStripeを隠すことはない
  • 最初にWooCommerceの「ステータス」→「ログ」で fatal-errors を確認する
  • 競合切り分け後はキャッシュ削除とStripe設定の再保存で復旧を試す
  • 復旧しない場合はシステムステータスでPHP・WooCommerceの要件を確認する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
Gemini 3.7 Flash登場。エージェント向け性能向上と半額価格の全容
2026年8月15日 0

Gemini 3.7 Flash登場。エージェント向け性能向上と半額価格の全容

Google DeepMindは8月13日、新しいAIモデル「Gemini 3.7 Flash」を発表した。コーディングとエージェント用途に特化したFlashシリーズの最新版で、わずか3週間前に登場したGemini 3.6 Flashから大幅な性能向上を実現している。

特に注目したいのは価格だ。導入価格として入力トークン100万個あたり0.75ドル、出力トークン100万個あたり3.75ドルに設定された。これは3.6 Flashの当初価格の半額にあたる。

本記事では、ソフトウェアエンジニアリング、Web開発、知識処理の各ベンチマークを掘り下げつつ、エージェント開発者にとって何が変わるのかを具体的に解説する。

Gemini 3.7 Flashの概要と位置付け

Gemini 3.7 Flashの概要と位置付け

Gemini 3.7 Flashは「Flashシリーズ史上もっとも知的な作業用モデル」という位置付けで投入された。3.6 Flashの発表からわずか3週間という短期間での後継モデル登場は異例の速さだが、Google DeepMindによればこれは開発者からのフィードバックとアルゴリズムの革新的な改善によるものだという。

モデル名の「Flash」は、大規模モデルと比べて応答速度を重視した軽量版という意味を持つ。処理速度を保ちながら推論能力を高めるのがFlashシリーズの設計思想で、3.7 Flashはそのバランスを一段階引き上げている。

改善領域はソフトウェアエンジニアリング、ナレッジワーク、Web開発ワークフローの3つに大別される。単にベンチマーク数値が上がっただけでなく、実務のワークフローに組み込んだ際の体感品質が向上している点が特徴的だ。

コーディング性能の飛躍的向上

ソフトウェアエンジニアリングのベンチマーク

デバッグやイシュー解決などのコーディングタスクで、3.7 Flashは3.6 Flashに対して明確な差をつけた。フロンティアコードと呼ばれる本番品質のコード生成ベンチマークでは43.6%を記録し、3.6 Flashの34.4%から約9ポイント向上している。

長期にわたるソフトウェアエンジニアリングタスクを測るDeepSWE v1.1でも、65.3%と3.6 Flashの49.0%から16ポイント以上の伸びを示した。初回のコード精度が上がったことで、修正のための再試行が減り、開発サイクル全体の効率が改善する。

Gemini 3.6 Flash（Before）
FrontierCode 34.4%
DeepSWE 49.0%
※修正と再試行が多く、開発工数が膨らみやすい
↓
Gemini 3.7 Flash（After）
FrontierCode 43.6%
DeepSWE 65.3%
※初回精度が上がり、再試行と手動監視を削減できる

このデモでは2つのベンチマークを比較している。FrontierCodeとDeepSWEのいずれも、3.7 Flashは3.6 Flashを大きく上回る結果を示している。

Web開発とUI生成の実力

Web開発では、より機能的なレイアウトと完成度の高いアプリを少ないプロンプト数で生成できるようになった。UI生成では、スクリーンショット、画像、デザインシステムのいずれを参照として与えた場合でも、高いデザイン忠実度を発揮する。

Arena.aiのWebDev Arenaというベンチマークでは、Eloスコア1588を記録し、3.6 Flashの1538から50ポイント上回った。Eloスコアとはチェスなどで使われる相対評価の指標で、数値が高いほど他のプレイヤーとの対戦で勝率が高いことを意味する。

実際のユースケースとしては、シンプルなテキストプロンプトからプレイ可能な3Dゲームを動的生成するデモや、パララックス効果を使ったインタラクティブなランディングページを一発生成するデモが紹介されている。副次的なエージェントをオーケストレーションする能力も備えており、複数コンポーネントを連携させたUI構築が可能になった。

知識集約分野での大幅改善

知識集約分野での大幅改善

複雑文書処理の進化

金融、法律、バイオサイエンスなど、専門知識が求められる分野でも3.7 Flashは大幅な改善を見せた。複雑なPDF文書を処理する能力を測るGDP.pdfベンチマークでは34.0%を記録し、3.6 Flashの22.0%から12ポイント向上している。

この改善は、静的なPDFをインタラクティブなデータストーリーに変換するというデモで具体的に示されている。複雑な年次報告書を、ライブチャートや集計済みの洞察を含むWeb体験に変換できるというものだ。単なるテキスト抽出を超え、文書構造の理解と再構築が可能になっている。

業務自動化ワークフロー

実世界のビジネスワークフローを完遂する能力を測るAutomationBenchでは、30.4%を記録し、3.6 Flashの17.0%を大きく上回った。この数値は、複数のアプリケーションやデータソースをまたいだ業務フローを、どれだけ正確に遂行できるかを示す指標だ。

STEP 1 ユーザーが自然言語で業務タスクを指示する
↓
STEP 2 3.7 Flashがワークフローを分解して必要なツールを特定する
↓
STEP 3 各アプリケーションを順次呼び出して実データを処理する
↓
STEP 4 結果を統合してファイルを整理し、レポートを作成する

このステップ図は、3.7 Flashが複数ツールを連携させて実業務を自動化する流れを示している。分解したタスクを順番に実行し、最終成果物までまとめ上げる自律性が向上した。

価格改定と開発者体験の改善

導入価格の詳細

3.7 Flashの導入価格は、入力トークン100万個あたり0.75ドル、出力トークン100万個あたり3.75ドルに設定された。これは3.6 Flashの当初価格と比較して半額である。年内いっぱいこの価格が適用される。

Gemini 3.6 Flash 当初価格（Before）
入力 100万個あたり 1.50ドル
出力 100万個あたり 7.50ドル
↓
Gemini 3.7 Flash 導入価格（After）
入力 100万個あたり 0.75ドル
出力 100万個あたり 3.75ドル
※どちらも半額。年内いっぱい適用される

価格が半額になったことと性能向上が組み合わさることで、本番環境でのエージェントを大規模に展開する際のコスト効率が大きく改善する。特に出力トークンの価格引き下げは、長い推論を必要とするエージェント用途で効果を発揮する。

エージェントワークフローへの適合

3.7 Flashは開発者体験の面でも改善されている。障害に遭遇した際の適応力が高まり、必要に応じて意図を明確化するための質問を行う。指示への忠実度も向上した。複数ステップの計画立案とツール呼び出しに、より多くの推論リソースを費やすようになったことで、手動の監視や再試行が減る。

この「規律のある実行」は、エージェントワークフローにおいて重要な意味を持つ。エージェントが途中で誤った判断をして軌道修正が必要になる回数が減れば、開発者の介入コストが削減され、自動化の信頼性が高まるからだ。

Gemini Sparkとの統合と安全性

Gemini Sparkとの統合と安全性

Sparkへの適用

Google AI ProおよびUltraプランの加入者が利用できるパーソナルAIエージェント「Gemini Spark」は、8月13日からGemini 3.7 Flashを基盤モデルとして使用するようになった。SparkはGoogle I/Oで発表された24時間稼働の個人向けエージェントで、ユーザーの指示のもとで自律的にタスクを実行する。

今回のモデル更新により、Sparkはファイルの整理、メールの下書き、ステータス文書の更新などの知識作業をより効率的にこなせるようになった。Google Workspaceアプリとの連携も改善され、複数のスキルを組み合わせた複雑なワークフローの精度が向上している。

安全対策の強化

3.7 Flashは、化学・生物・放射線・核（CBRN）分野およびサイバー攻撃分野における悪用を防ぐための最新の安全対策を備えて出荷される。Google DeepMindのフロンティアセーフティの枠組みに基づき、有益なユースケースを維持しながら悪用リスクを低減する設計になっている。

モデルの詳細な安全性情報や性能データは、公開されているモデルカードで確認できる。エンタープライズ環境で導入を検討する際には、このモデルカードを確認しておくとよい。

利用方法と提供チャネル

利用方法と提供チャネル

3.7 Flashはすでに複数の経路で利用可能だ。開発者はGoogle Antigravityでエージェントファーストのワークフローを試せるほか、Google AI StudioからGemini APIを直接呼び出すことができる。Androidアプリ開発者はAndroid Studioからもアクセス可能だ。

エンタープライズ向けには、Gemini Enterprise Agent PlatformとGemini Enterpriseアプリで提供される。個人ユーザーはGeminiアプリ内のSparkを通じて利用できる。対応国や地域の詳細はGoogleのサポートページに掲載されている。

この記事のポイント

  • Gemini 3.7 Flashは3.6 Flashからわずか3週間で登場した後継モデル
  • コーディングの初回精度が大幅に向上し、再試行コストを削減できる
  • Web開発では少ないプロンプト数で機能的なUIを生成可能
  • 導入価格は3.6 Flash当初価格の半額に設定され、年内いっぱい適用
  • Gemini Sparkの基盤モデルとしても即日採用された
海田 洋祐
, , , , ,
AI・開発支援
Tutor LMSでコース画像が小さくぼやける原因と画像サイズ変更の手順
2026年8月15日 0

Tutor LMSでコース画像が小さくぼやける原因と画像サイズ変更の手順

Tutor LMSのコース一覧でサムネイル画像が小さくぼやける症状は、プラグインが登録した専用画像サイズ（約370×235px）をテンプレートが呼び出し、ブラウザ側で大きな容器に引き伸ばしているのが主な原因だ。子テーマでテンプレートを上書きするか、フィルターフックで画像サイズを変更すれば解決する。

Tutor LMSでコース画像がぼやける仕組みと原因

Tutor LMSでコース画像がぼやける仕組みと原因

Tutor LMSはコース一覧ページを表示する際、専用の画像サイズを呼び出す。このサイズはプラグインがサーバー環境に登録したもので、コースカードのレイアウトに合わせて小さい寸法に設定されていることが多い。

問題は、テーマ側のスタイルシートがコースカードをより広い幅で表示しようとする場面だ。画像の実寸（約370×235px）に対して、実際の表示領域がそれを上回ると、ブラウザが画像を無理に拡大する。高解像度の元画像をアップロードしても、プラグインが生成した小さなサムネイルを参照している限り、ぼやけや文字の潰れは解消されない。

また、Tutor LMSのコースループ用テンプレートは標準の post_thumbnail_size フックを無視し、独自のサイズ指定を直接コード内に持っている。そのため、WordPressの標準設定から画像サイズを変更しても、コース一覧に反映されないという構造的な理由がある。

Before（症状）
元画像は高解像度（4K）でも
370×235pxのサムネイル生成 → 広い容器に引き伸ばし → ぼやける・文字が読めない
↓
After（修正後）
高解像度の画像サイズを直接参照
fullサイズ画像 → 表示領域に最適化 → 鮮明で読みやすい
■ 症状の状態　■ 修正後

このデモは、Tutor LMSが小さいサムネイルを呼び出してからブラウザが拡大する流れと、修正後に高解像度画像を直接参照する流れを示している。

テンプレート上書きで画像サイズを変更する手順

テンプレート上書きで画像サイズを変更する手順

最も確実な方法は、Tutor LMSのテンプレートファイルを子テーマにコピーし、画像サイズの指定を書き換えることだ。プラグイン本体のファイルを直接編集するとアップデートで上書きされるため、必ず子テーマを使う。

Tutor LMSのテンプレート構造を確認する

Tutor LMSのテンプレートは wp-content/plugins/tutor/templates/ ディレクトリ内に配置されている。コース一覧のカードを構成するテンプレートは、templates/course/loop/ または templates/loop/ 以下のファイル群だ。バージョンによって多少の違いはあるが、コースカードの表示を担当するファイルにサムネイル呼び出しが含まれている。

管理画面の「プラグイン」→「プラグインファイルエディター」からTutor LMSを選択し、templates/ フォルダを展開すると実ファイル名を確認できる。FTPで接続できるなら wp-content/plugins/tutor/templates/ を直接参照する方が速い。

子テーマにテンプレートをコピーする

対象のテンプレートファイルを子テーマ内の tutor/ ディレクトリにコピーする。Tutor LMSは子テーマの tutor/ フォルダを優先的に読み込む仕組みを持っている。コピー先のパスは wp-content/themes/子テーマ名/tutor/ だ。ディレクトリ構造を保ったままコピーする。

画像サイズの指定を変更する

コピーしたテンプレートファイル内の get_the_post_thumbnail() または tutor_course_loop_thumbnail() の呼び出し部分を探す。第二引数に指定されているサイズ名（例 'tutor-course-thumbnail'）を 'full' または 'large' に変更する。

// 変更前
get_the_post_thumbnail($course_id, 'tutor-course-thumbnail');

// 変更後
get_the_post_thumbnail($course_id, 'full');

テンプレート内に the_post_thumbnail() が直接記述されている場合は、同じくサイズ引数を 'full' に置き換える。

STEP 1 templates/loop/ 内のコースカード用ファイルを特定する
↓
STEP 2 子テーマの tutor/ ディレクトリに同一構造でコピーする
↓
STEP 3 画像サイズの引数を full または large に変更する
↓
STEP 4 キャッシュを削除し、コース一覧の表示を確認する

このデモは、テンプレート上書きの4つの手順を順番に示している。

フィルターフックで画像サイズを変更する方法

フィルターフックで画像サイズを変更する方法

テンプレートを編集せずに済ませたい場合は、Tutor LMSが提供するフィルターフックを利用する。functions.php に数行追加するだけで、コースループで呼び出される画像サイズを変更できる。

functions.phpにフィルターを追加する

子テーマの functions.php に以下のコードを追加する。tutor_course_thumbnail_size フックは、コースループで使われるサムネイルサイズを差し替えるためのものだ。

add_filter('tutor_course_thumbnail_size', function($size) {
    return 'full';
});

このコードは、Tutor LMSがコースカードのサムネイルを出力する際に参照するサイズ名を full に上書きする。元画像が十分な解像度でアップロードされていれば、一覧表示でも鮮明になる。

なお、プラグインのバージョンや使用中のテーマによってフック名の実装が異なる場合がある。テンプレート上書きの方が確実に効くため、フィルターで変化が見られない場合はテンプレート上書きに切り替えるのが確実だ。

サムネイル再生成とキャッシュのクリア

サムネイル再生成とキャッシュのクリア

画像サイズの指定を変更した後は、既存の画像に対して新しいサイズのサムネイルが生成されていない場合がある。特に full サイズを使う場合は元画像そのものを参照するため再生成は不要だが、large や独自サイズを使う場合は再生成が必要になる。

サムネイル再生成で古いサイズを更新する

「Regenerate Thumbnails」などの再生成プラグインを使うと、WordPressに登録されている全画像サイズを一括で作り直せる。再生成の所要時間は画像点数に依存するが、数百枚程度なら数分で完了する。

サイトキャッシュとブラウザキャッシュを削除する

変更後に表示が古いままの場合は、キャッシュ系プラグインの全削除と、ブラウザのキャッシュクリアを行う。CDNを利用している場合は、CDN側のキャッシュもパージする。これで新しい画像サイズがサーバーから配信される。

変更後チェック
サイズ変更 → 再生成 → キャッシュ削除 → 表示確認
■ 設定変更　■ 再生成　■ キャッシュ

このデモは、画像サイズ変更後に確認すべき作業の流れを示している。

よくある質問

Tutor LMSのコース画像サイズはどこで登録されているのか？

Tutor LMSはプラグインのコード内で add_image_size() 関数を使って専用サイズを登録している。登録名は tutor-course-thumbnail などで、コースループ用テンプレートがこのサイズを参照する。標準のWordPress設定画面からは変更できない。

子テーマを作っていない場合はどうすればよいか？

まず子テーマを作成する。WordPress公式ドキュメントに従い、style.css と functions.php を含むフォルダを作成すればよい。親テーマを直接編集するとアップデートで変更が消えるため、子テーマ運用が安全だ。

画像を変更しても古いサイズのまま表示されるのはなぜか？

ブラウザキャッシュやサイトキャッシュが古い画像を保持している可能性が高い。キャッシュ系プラグインの全削除と、ブラウザのキャッシュクリアを行う。CDNを使っているならCDN側のパージも必要だ。

フィルターフックが効かない場合はどうする？

プラグインのバージョンやテーマの構造によって、特定のフックが実装されていない場合がある。その場合はテンプレート上書き方式に切り替える。テンプレートファイル内のサイズ指定を直接書き換えれば、フックの有無に関係なく確実に反映される。

CSSだけで画像を鮮明にできるか？

できない。CSSで image-rendering プロパティを調整しても、元の画像データが小さい限り拡大によるぼやけは残る。根本的な解決には、テンプレートやフィルターで大きなサイズの画像を呼び出す必要がある。

この記事のポイント

  • Tutor LMSのコース画像ぼやけは小さい専用サイズの参照が原因
  • 子テーマへのテンプレート上書きで確実に修正できる
  • フィルターフックでもサイズ変更が可能
  • サイズ変更後は再生成とキャッシュ削除が必須
  • CSSだけでは根本解決にならない
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
WP Offload Mediaでサイトに重大なエラーが発生した時の原因と対処法
2026年8月14日 0

WP Offload Mediaでサイトに重大なエラーが発生した時の原因と対処法

WP Offload Media（S3/CloudFrontにメディアを転送するプラグイン）でサイトに「このサイトで重大なエラーが発生しました」と表示され、画面が表示されなくなる場合、PHP 8.xではプラグイン内部のsprintf()呼び出しに引数が1つ足りないのが原因だ。最新版へのアップデートで解消する。

なぜWP Offload MediaでArgumentCountErrorが起きるのか

なぜWP Offload MediaでArgumentCountErrorが起きるのか

このエラーの直接の原因は、WP Offload Mediaの remove-local-handler.php 内にある sprintf() 呼び出しだ。メディアをS3へ転送（オフロード）した後、ローカルファイルを削除しようとして失敗すると、エラーメッセージを整形する処理が走る。その際、翻訳文字列にファイルパス用の %s が含まれているのに、実際のファイルパスが渡されていない。

PHP 7.xまでは引数不足の sprintf() は警告で済んでいた。ところが PHP 8.0 以降では ArgumentCountError という致命的エラーになり、未処理の例外としてサイト全体が停止する。本来なら所有権やパーミッションの警告で済むはずの内部メッセージ生成が、フロントエンド全体を落とす事態になる。

発火のきっかけは特定の操作に限らない。Yoast SEO のスキーマ生成が wp_head 内で wp_get_attachment_image_url() を呼ぶケースもある。カスタム投稿やギャラリー、商品ページのサムネイル取得など、アップロード済みメディアの URL を取得する場所ならどこでも起こり得る。

Before（エラー状態）
sprintf() にフォーマット文字列だけを渡し、%s 用のファイルパスが無い。PHP 8が ArgumentCountError を投げ、サイト全体が停止する。
↓
After（修正後）
sprintf() の第2引数に $file を渡す。エラーは警告として記録されるだけで、サイトは稼働を続ける。
■ エラー状態　■ 修正後

修正版では sprintf() の第2引数として $file（実際のファイルパス）が追加される。未処理の例外がなくなるため、フロントエンドの停止を防げる。

エラーログから原因の関数名を確認する手順

エラーログから原因の関数名を確認する手順

画面上では「このサイトで重大なエラーが発生しました」とだけ表示され、詳細はわからない。管理者宛のメールやサーバーのPHPエラーログにスタックトレースが残っている場合もあるが、WordPress の debug.log を有効にするのが最も確実だ。

  • wp-config.php をテキストエディタかFTPで開く
  • WP_DEBUG と WP_DEBUG_LOG を true にして保存する
  • エラーが起きたページを再読み込みする
  • wp-content/debug.log を開き、ArgumentCountError と Remove_Local_Handler を探す

スタックトレースに「2 arguments are required, 1 given」という記述があれば、この症状と一致する。Yoast SEO が呼び出し元に含まれる場合もあるが、他のプラグインやテーマ由来でも発火するため、関数名の確認を優先する。

WP Offload Mediaをアップデートして修正する手順

WP Offload Mediaをアップデートして修正する手順

修正が取り込まれたバージョンがリリースされていれば、管理画面からプラグインを更新するのが最短の対応だ。WP Offload Media はサブスクリプション型のライセンスで更新が配布されるため、ライセンスが有効かどうかも確認しておく。

STEP 1 管理画面の「プラグイン」を開く
↓
STEP 2 WP Offload Media に更新があるか確認する
↓
STEP 3 プラグインを更新する
↓
STEP 4 キャッシュを削除し、ページの復旧を確認する

更新後はサーバーキャッシュとブラウザキャッシュを削除してから、エラーが出ていたページを開き直す。WP CLI を使える環境では wp plugin update コマンドでも更新できる。

すぐに更新できない場合の一時的な対処

すぐに更新できない場合の一時的な対処

サブスクリプションの期限切れなどで更新が受けられない場合は、remove-local-handler.php に直接修正を加える方法がある。管理画面の「プラグイン」メニューにある「プラグインファイルエディター」からWP Offload Media を選び、remove-local-handler.php を開く。

sprintf() に $file を追加して回避する

修正箇所は2つある。remove-local-handler.php の180行付近と185行付近だ。どちらも sprintf() の閉じ括弧の前に、カンマと $file を追加する。このファイルはプラグイン本体のため、次回のアップデートで上書きされるが、修正版が配布されるまでの時間稼ぎにはなる。

// 修正前（180行付近）
$file_to_remove['remove_result']['message'] = sprintf(
    __( "Error removing local file. Couldn't find the file at %s", 'amazon-s3-and-cloudfront' )
);

// 修正後
$file_to_remove['remove_result']['message'] = sprintf(
    __( "Error removing local file. Couldn't find the file at %s", 'amazon-s3-and-cloudfront' ),
    $file
);

// 185行付近も同様に $file を追加する

プラグインを一時的に無効化する

管理画面に入れる場合は、WP Offload Media を一時的に無効化すればサイトは復旧する。ただし、メディアがすでにS3にオフロードされていると、無効化中はローカルに存在しない画像が表示されないことがある。緊急時の対応と割り切って使う。

PHPバージョンを7.4に戻す

サーバーの設定で PHP を 7.4系に戻せばエラーは出なくなる。ただし、PHP 7.4はセキュリティサポートが終了しているため、恒久対策にはならない。あくまで更新までの一時的な回避策だ。

所有権とパーミッションを見直して再発を防ぐ

所有権とパーミッションを見直して再発を防ぐ

このエラーが起きたということは、オフロード後に削除するはずのローカルファイルに削除権限がなかった可能性が高い。プラグインの修正後は、アップロードディレクトリの所有権とパーミッションを確認し、Webサーバーユーザーが書き込める状態にしておく。

アップロードディレクトリ（wp-content/uploads）は、ディレクトリが755、ファイルが644であることが一般的だ。所有権がFTPユーザーになっていると、Webサーバープロセスが削除できず同じ状態になる。サーバー管理画面やシェルから、アップロードディレクトリの所有者をWebサーバーの実行ユーザーに合わせる。

# 所有者とグループをWebサーバー実行ユーザーに合わせる（www-data は環境により異なる）
sudo chown -R www-data:www-data wp-content/uploads

# ディレクトリとファイルの権限を整える
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

実行ユーザーの名前はサーバー環境によって www-data、apache、nginx など異なる。レンタルサーバーでは管理画面のファイルマネージャーから所有者を変更できないこともあるため、その場合はカスタマーサポートに依頼するか、PHP を実行ユーザーと同じ権限で動かす設定を検討する。

よくある質問

管理画面にも入れないほど真っ白になった場合はどうする？

FTPやサーバーのファイルマネージャーから wp-content/plugins/ に入り、WP Offload Media のフォルダ名を「WP Offload Media_backup」のように変更して無効化する。WordPress はプラグインが存在しないと認識し、サイトを復旧できる。その後、原因を修正してからフォルダ名を元に戻す。

プラグインを更新したのにまだエラーが出るのはなぜ？

キャッシュが残っている可能性が高い。サーバーキャッシュとブラウザキャッシュを削除してから再確認する。それでも出る場合は、別のプラグインが同様の sprintf() 引数不足を起こしている。デバッグログのスタックトレースを再確認する。

ArgumentCountError は WP Offload Media 以外でも起きる？

起きる。PHP 8.0以降では、翻訳文字列に %s を含む sprintf() で引数を渡し忘れると同様の致命的エラーになる。古いテーマやプラグインで潜伏していることが多い。PHP 8.x へ移行する際は事前にステージング環境でテストするのが基本だ。

所有権の問題を放置するとどうなる？

ローカルファイルの削除が失敗し続け、アップロードディレクトリに同じファイルが重複して残る。ディスク容量やバックアップサイズにも影響する。プラグイン自体は修正されても、警告ログが出続けるため、所有権は合わせて直しておくべきだ。

この記事のポイント

  • WP Offload Media の sprintf() 引数不足が PHP 8.x で致命的エラーになる
  • 「このサイトで重大なエラーが発生しました」の裏で ArgumentCountError が起きている
  • 修正版への更新が最短の解決策
  • 更新できない間は sprintf() の第2引数に $file を追加する
  • 所有権とパーミッションを整えて同じ失敗が起きないようにする
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WordPress 7.1正式版が8月19日リリース。レスポンシブスタイルと疑似状態の全容
2026年8月14日 0

WordPress 7.1正式版が8月19日リリース。レスポンシブスタイルと疑似状態の全容

WordPress 7.1の正式版が2026年8月19日にリリースされる。WordCamp US最終日と重なるタイミングで、すでにRC1とRC2が公開され、機能セットは確定済みだ。先月にはセキュリティリリース2件も出ており、影響を受けるサイトは自動更新が強制された。

今回のアップデートで注目が大きいのは、レスポンシブブロックスタイルと疑似状態スタイルのコア導入だ。テーマ開発者はモバイルとタブレットの表示をtheme.jsonだけで制御できるようになる。プラグイン開発者もリストテーブルの構造変更に注意が必要だ。正式版まで残り数日、互換性確認のポイントを解説する。

WordPress 7.1は8月19日リリース、RC2まで公開済み

WordPress 7.1は8月19日リリース、RC2まで公開済み

正式版はWordCamp US最終日に到着

WordPress 7.1は8月19日にリリース予定だ。ちょうど8月16日から19日にかけて米国フェニックスで開催されるWordCamp USの最終日と重なる。年次フラッグシップイベントの最終日に正式版が出るのは珍しいスケジュールで、現地参加者はその瞬間をライブで目撃できる。

先週までにRC1とRC2が立て続けに公開された。RC（Release Candidate / リリース候補版）とは、正式版の一歩手前の段階だ。ここまで来ると新機能の追加は終了し、バグ修正だけが行われる。Field Guideも公開済みで、全機能の開発者向け詳細がまとまっている。

セキュリティリリース2件、強制自動更新も発動

先月はセキュリティリリースが2件公開された。7月17日に出たWordPress 7.0.2は、重大な脆弱性1件と高深刻度の脆弱性1件に対処したものだ。深刻度が高かったため、影響を受けるバージョンのサイトには強制自動更新が適用された。続いて8月6日には7.0.3が公開され、十数件の追加修正が入っている。

管理しているサイトが両方の自動更新を何らかの理由で逃していた場合、先にそちらの更新を済ませることが最優先になる。7.1のテストはその後でかまわない。

レスポンシブスタイルがコアに登場

レスポンシブスタイルがコアに登場
デスクトップビュー（デフォルト）
パディング幅 3rem（約48px）
theme.json のデフォルト値がそのまま適用される
↓
タブレットビュー（@tablet）
パディング幅 2rem（約32px）
782px 以下の画面で適用される
↓
モバイルビュー（@mobile）
パディング幅 1rem（約16px）
480px 以下の画面で適用される

上記の図は、theme.jsonでデスクトップ・タブレット・モバイルのパディングを切り替える様子を視覚化したものだ。実際には端末の画面幅に応じて、この3つの状態が自動的に切り替わる。

theme.jsonでモバイルとタブレットのスタイルを定義

春先から開発が進められていたレスポンシブスタイルが、WordPress 7.1で正式にコアに導入された。ブロックのスタイルをタブレットとモバイルのビューポートごとに定義できる。Global Styles（グローバルスタイル）ではブロックタイプ単位で、個別のブロック単位でも設定可能だ。theme.jsonでは@mobileと@tabletというキーの中にネストして記述する。

ここで押さえておきたいのは、@desktopキーが存在しない点だ。ブロックのデフォルトスタイルがそのままデスクトップスタイルになる。モバイルやタブレットで上書きしなかったプロパティは、すべてのビューポートでデフォルト値が適用される。

さらにテーマ側でブレークポイントを設定できる。theme.jsonのトップレベルにsettings.viewportプロパティを追加する仕組みだ。デフォルトはモバイルが480px、タブレットが782px。値はpx、em、remの非負の長さのみ許可され、CSS関数やパーセント、単位なしの値は無視される。タブレット値がモバイル値と同じか小さい場合は、モバイルのみが使われる。

標準ブロックサポートを使っているブロックは、タイポグラフィ、カラー、背景、ボーダー、寸法、スペーシング、レイアウトが自動的に対応する。逆に独自のスタイルコントロールを持つブロックは対象外だ。自作ブロックがある場合、この線引きで対応有無を確認してほしい。

疑似状態スタイルでホバーやフォーカスを制御

ボタンの疑似状態スタイル（4状態）
通常状態 ボタン
ホバー状態 ボタン
フォーカス状態 ボタン
アクティブ状態 ボタン
■ 通常　■ ホバー　■ フォーカス枠　■ アクティブ

ホバーやフォーカスは実際の操作で状態が変わるため、上記は4つの状態を並べて示したものだ。実際の編集画面では「Hover」タブを選んでスタイルを設定する。

かねてから要望の多かった疑似状態スタイルも7.1で実装された。:hover、:focus、:focus-visible、:activeをtheme.jsonとエディタで定義できる。現時点ではButtonブロックとNavigation Linkブロックに限定されている。

さらに初期段階のカスタムステート機能も入った。現状はtheme.jsonのみで、管理画面のUIはまだない。Navigation Linkブロックが現在のメニュー項目をスタイルするために-currentプロパティを使う仕組みだ。カスタムステートは-接頭辞を使い、ブロックのblock.jsonにあるselectors.statesプロパティで宣言したクラス名をターゲットにCSSを生成する。現時点では限定的だが、今後の拡張に向けた重要な布石だ。

新しいデザインツール3点

新しいデザインツール3点

テーマ開発者が長年待っていた変更を含む、デザインツールの追加が3つある。グラデーションと背景画像を同時に使えるようになるのは特に大きい。

背景グラデーションと背景画像を併用可能に

新しいbackground.gradientは既存のcolor.gradientとは別のサポートとして追加された。違いはCSSの出力先にある。従来のサポートはbackgroundショートハンドを通じて描画されるため、background-imageを含むすべてのbackground関連プロパティをリセットしてしまっていた。ブロックにグラデーションか画像のどちらか一方しか使えなかった理由だ。

新しいサポートはbackground-imageロングハンドで描画される。スタイルエンジンが1つの宣言内にグラデーションと画像をカンマ区切りで出力できるようになった。7.1ではGroup、Accordion、Pullquote、Post Content、Quoteがコアで対応する。値はstyle.background.gradientに保存される。

最小幅とテキストシャドウ

dimensions.minWidthは既存のminHeightと同じパターンで、CSSのmin-widthとして適用される。テーマがdimensionSizesプリセットを提供していれば、それを活用できる。1点注意があり、この設定はデフォルトではブロックインスペクターに表示されない。ブロック側で__experimentalDefaultControlsを通じてopt-inした場合のみ表示される。Global Stylesではデフォルトで表示される。

テキストシャドウもGlobal Stylesでサポートされた。これまでは個別ブロックやCSSでしか指定できなかったが、theme.jsonからサイト全体またはブロックタイプ単位で制御できる。

SVG Icon APIが正式公開

アイコン名の衝突を防ぐ名前空間の仕組み
名前空間なしの場合（衝突する）
core / star → my-plugin / star 同じ名前で衝突
↓
名前空間を付けた場合（安全）
core/star → my-plugin/star それぞれ別のアイコンとして識別

アイコン名の衝突を防ぐため、コレクション名が名前空間の接頭辞になる。プラグイン独自のアイコンを登録しても、コアのアイコンと混同される心配がない。

WordPress 7.0でエディタとIconブロック向けにSVGアイコンのセットが同梱された。7.1ではこれが正式な公開APIになり、プラグインやテーマから登録できるようになった。wp_register_icon_collection()でコレクションを登録し、wp_register_icon()でアイコンを追加する。PHPの任意の場所でwp_get_icon()を使えば、サイズやクラス、ラベルを指定してアイコンを表示できる。

計画時に意識したい制限が2つある。登録したSVGはwp_ksesによって保守的な許可リストでサニタイズされる。許可されるのは<svg>、<path>、<polygon>のみ。許可リストの拡大作業は進行中だ。fillは図形部分にのみ許可され、外側の<svg>には付けられない。またwp_get_icon()単体で呼び出すとSVG自身のfill（黒）で描画される。周囲のテキスト色に合わせたい場合は、渡したクラスに対して自前でCSSを指定するのが推奨される。

エディタのiframe化とプラグインへの影響

エディタのiframe化とプラグインへの影響

投稿エディタは常時iframe表示へ

テンプレートエディタがiframe化されたのはWordPress 5.8からだ。それ以来、投稿エディタも段階的に移行してきたが、7.1で最終段階に入った。テーマの種類や登録ブロックのAPIバージョン、コンテンツ内のブロックのAPIバージョンに関係なく、投稿エディタは常にiframeで表示される。レガシーメタボックスを登録しているサイトも同様だ。

7.0では投稿ごとに挿入されたブロックに基づいて判断されていた。つまりコンテンツによってiframedモードと非iframedモードが切り替わり得た。この条件付き動作がなくなり、挙動が単純化された。

大半のブロックは変更なしで動作する。問題が起きる場合、ほとんどは1つの根本原因にたどり着く。iframeは管理者ページとは別のdocumentとwindowを持つ。エディタスクリプトが実行される管理者ページからグローバルのdocumentやwindowにアクセスしてキャンバスを操作しようとすると、間違ったドキュメントを見ていることになる。対処としては、キャンバス内の要素からownerDocumentとdefaultViewでドキュメントを取得するか、useRefEffectでキャンバス要素にリスナーをアタッチ・クリーンアップするのが一般的だ。

リストテーブルの行ヘッダーが移動

カスタムCSSやJavaScriptを書いているプラグインにとって、静かに何かを壊す可能性が高いのがリストテーブルの変更だ。投稿一覧テーブルで、プライマリのth scope="row"がチェックボックス列からタイトル列に移動した。チェックボックスセルはtdになり、タイトルセルがthとして投稿タイトルを含むaria-labelを持つ。レスポンシブ表示で折りたたまれるセルはflexレイアウトを使うようになった。

これはアクセシビリティの大きな改善だ。スクリーンリーダーは各行を、場合によっては存在しないチェックボックスではなく投稿名で認識できるようになる。ただしこのマークアップは2010年以降ほぼ安定していたため、多くの拡張が暗黙的に依存している。th.check-columnを選択するCSSやJavaScript、td内の行アクションや投稿タイトルを期待するコードがある場合は確認が必要だ。

この記事のポイント

  • WordPress 7.1は8月19日リリース予定、RC2まで公開済みで機能セットは確定
  • セキュリティリリース7.0.2と7.0.3が先月公開され、強制自動更新も適用された
  • レスポンシブスタイルがコアに入り、モバイルとタブレットのスタイルをtheme.jsonで定義可能に
  • 疑似状態スタイルでホバー、フォーカス、アクティブをテーマから制御できる
  • SVG Icon APIが公開され、プラグインが名前空間付きでアイコンを登録可能に
  • 投稿エディタは常時iframe化され、リストテーブルの行ヘッダー移動も要確認
海田 洋祐
, , , , ,
WordPress
admin-ajax.phpへのボット大量アクセスでCPUが100%になる時の遮断と対策
2026年8月14日 0

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 で守れる
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
Google広告が検索キャンペーンの言語ターゲティング設定を廃止。9月下旬から順次適用
2026年8月14日 0

Google広告が検索キャンペーンの言語ターゲティング設定を廃止。9月下旬から順次適用

Google広告が2026年9月下旬から、検索キャンペーンとP-MAX（パフォーマンスマックス）の検索枠におけるキャンペーンレベルの言語ターゲティング設定を廃止する。広告文とランディングページの言語が配信判断の主な基準となり、GoogleのAIによる言語理解がより大きな役割を担う。

この変更により、多言語キャンペーンの運用方法が変わる。既存キャンペーンの再構築は不要だが、規制業界の広告主には配信実績の文書化という未解決の課題が残る。

本記事では、言語ターゲティング廃止の具体的な内容、Googleの判定ロジック、広告主が取るべき対応を解説する。

言語ターゲティングで何が変わるのか

言語ターゲティングで何が変わるのか

現行の仕組みと変更後

現在のGoogle広告では、キャンペーン設定で広告主が1つ以上の言語を選択する仕組みだ。同時にGoogleは検索クエリ、ユーザー設定、その他のAI由来のシグナルを基に、ユーザーが理解する言語を独自に判定している。この2つの条件が重なったときにだけ検索広告が配信される。

9月下旬以降、キャンペーンレベルの言語設定が検索キャンペーンから削除される。代わりにGoogleは広告クリエイティブとランディングページの言語、およびユーザーの理解言語に関する既存のAI判断を組み合わせて配信を決定する。

従来の言語判定（Before）
キャンペーン設定で言語を選択する
＋
Googleがユーザーの理解言語をAIで判定する
＝
両方が一致した場合のみ広告が配信される
↓
変更後の言語判定（After）
広告文とランディングページの言語を基準にする
＋
Googleがユーザーの理解言語をAIで判定する
＝
キャンペーン設定なしで自動最適化される
■ 従来の言語判定　■ 変更後の言語判定　■ AIによる判定（共通）

この変更により、キャンペーン設定で言語を指定する手間がなくなる。広告文とランディングページの言語がそのまま配信基準として機能するようになるのだ。

P-MAXへの影響範囲

P-MAX（パフォーマンスマックス）では、この変更の影響を受けるのは検索枠のみ。検索以外のチャネルではキャンペーンレベルの言語設定が引き続き使用される。つまりP-MAX全体が変わるわけではなく、Google検索に表示される部分だけが対象になる。

複数言語ユーザーへの広告配信ロジック

複数言語ユーザーへの広告配信ロジック

変更後の大きなポイントは、複数言語を理解するユーザーへの配信方法だ。英語とスペイン語の両方を理解するユーザーには、どちらの言語の広告も配信される可能性がある。GoogleのAIが広告グループ単位で優先順位付けを行い、検索に対して最適な言語を選ぶ。

検索クエリに明確な言語がある場合は、その言語の広告とランディングページが優先される。たとえばスペイン語で検索したユーザーには、スペイン語の広告が優先的に表示される仕組みだ。

複数言語ユーザーへの配信フロー
STEP 1 ユーザーが英語とスペイン語を理解している
↓
STEP 2 Google AIがクエリとユーザー設定から言語を推定する
↓
STEP 3 広告グループの優先順位付けで最適な言語を選択する
↓
STEP 4 ユーザーの理解言語に合った広告を配信する
■ STEP 1（ユーザー）　■ STEP 2（AI判定）　■ STEP 3（優先順位付け）　■ STEP 4（配信結果）

Googleはクエリの言語だけでなく、ユーザー設定や過去の行動など複数のシグナルを組み合わせて最適な言語を選ぶ。複数言語を理解するユーザーに対しては、AIが広告グループ単位でより適切な言語を優先する仕組みだ。

ブランド検索における言語判断

ブランド検索では状況が少し複雑になる。ブランド名が複数言語で同一であることが多く、クエリ自体から言語を判断する手がかりが少ないからだ。たとえば「Nike」というブランド名は英語でもスペイン語でも同じ表記になる。

このような場合、Googleはクエリ以外の言語シグナルに依存し、ユーザーの優先言語を重視する。日常的に英語とスペイン語の両方で検索するユーザーには、どちらの言語の広告も配信対象になり得る。

Googleはこの変更が、キャンペーン設定による意図しないトラフィック制限を減らすとも説明している。たとえば英語でターゲティングしたキャンペーンにスペイン語の広告文やランディングページが含まれる場合、従来はキャンペーン設定がブロック役を果たしていた。今後はGoogleの言語理解に委ねられ、関連トラフィックを取りこぼしにくくなる見込みだ。

広告主が懸念する規制対応とAI生成クリエイティブ

広告主が懸念する規制対応とAI生成クリエイティブ

規制業界の配信実績の文書化

発表前に行われたバーチャルラウンドテーブルでは、広告主からいくつかの質問が寄せられた。特に規制対象業界の広告主は、コンプライアンスに関する懸念を示した。

保険業界の広告主を例にとると、英語話者とスペイン語話者の両方に広告が公平に届いていることを文書で示さなければならない場合がある。Googleは両言語で広告を提供していれば、両方のグループにリーチする意図があると判断されると説明した。

ただし、ラウンドテーブルで出た質問は意図の話だけにとどまらなかった。キャンペーン設定ではなくGoogleの自動判定が言語ごとの配信を決めるようになった場合、広告主がどのように配信実績を証明するかという点は未解決のままだ。Googleは言語別の配信状況やパフォーマンスの差を確認できる追加のレポート機能を発表していない。

AI Maxと自動生成クリエイティブ

P-MAXと自動生成クリエイティブに関しても質問があった。ケベック州をターゲットにしたAI Maxキャンペーンで、AIがフランス語のクリエイティブを生成した場合、英語で検索するユーザーにそのフランス語広告が表示される可能性はあるのか。Googleは「可能性がある」と回答した。

クリエイティブの生成が先に行われ、その後Googleが利用可能な広告とランディングページをユーザーが理解できるかをチェックする。クエリの言語と広告の言語が一致していなくても、ユーザーが理解できると判断されれば配信される仕組みだ。

AI Maxで起こりうる配信シナリオ
ケベック州をターゲットにしたAI Maxキャンペーンを配信中
↓
AI生成 フランス語のクリエイティブを自動生成する
↓
ユーザー 英語で検索する
↓
配信結果 ユーザーがフランス語を理解するとGoogleが判断した場合、フランス語広告が配信される可能性がある
■ ユーザー　■ AI生成クリエイティブ　■ 配信結果

検索クエリの言語と広告の言語は必ずしも一致する必要がない。Googleがユーザーの理解言語を判断し、優先順位付けシステムが最適なクリエイティブを選ぶためだ。

広告主が取るべき具体的な対応

広告主が取るべき具体的な対応

既存キャンペーン構造の扱い

大多数の広告主にとって、この変更は大きな影響を及ぼさない。Googleも既存キャンペーンの再構築は不要だと明言している。言語別にキャンペーンを分けている場合も、そのままの構造を維持してよい。言語設定が検索からなくなったからといって、キャンペーンを統合する必要はない。

注意が必要なのは、言語ターゲティングを本来の目的以外に使っていたケースだ。旅行、国際展開、規制対象などの業界では、言語設定がオーディエンスの絞り込みやコンプライアンス要件に影響していることがある。

Google広告APIを利用する広告主は、検索キャンペーンの作成・更新時に言語条件を送信するのをやめることが推奨されている。既存の言語条件は残っても構わないが、検索ターゲティングには影響しなくなる。

適用後に監視すべき指標

具体的には、広告文とランディングページが意図した言語で書かれているか確認するべきだ。特に多言語キャンペーンやAI生成アセットを利用する場合は注意が必要。Googleが広告文とランディングページの言語を基準にするため、これらの言語が正確に設定されていないと配信に影響する。

変更が適用された後は、検索語句や地理的トラフィックの変化、流入ユーザーの言語属性などを確認し、パフォーマンスを監視する。国際展開や多言語運用を行う広告主は、特にこれらの指標に注意を払う必要がある。

適用後に確認すべきチェックリスト
広告文とランディングページの言語が意図した通りか確認する
検索語句のパターンに変化がないか監視する
地理的トラフィックの変動をチェックする
流入ユーザーの言語属性を確認する
■ クリエイティブ確認　■ 検索語句　■ 地理的トラフィック　■ 言語属性

パフォーマンスと流入ユーザーの構成がおおむね安定していれば、Googleの主張どおり言語設定が実質的に重複していたと言える。一方、言語設定を追加のオーディエンス制御層として使っていたケースでは、適用後の変化を見極めるのに時間がかかるかもしれない。

この記事のポイント

  • Google広告が検索キャンペーンとP-MAXの検索枠からキャンペーンレベルの言語ターゲティング設定を廃止する
  • 変更は2026年9月下旬から順次適用され、広告文とランディングページの言語が配信判断の主な基準になる
  • 既存キャンペーンの再構築は不要で、言語別に分けている場合もそのまま維持できる
  • 規制業界では配信実績の文書化について未解決の課題が残る
  • P-MAXでは検索以外のチャネルでキャンペーンレベルの言語設定が引き続き使われる
海田 洋祐
, , , ,
SEO対策
« 前ページへ 次ページへ »

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

サービス一覧

ウェブシステム開発

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.