WordPress wp2shell攻撃後の完全クリーンアップと再発防止手順
WordPress が REST Batch API を悪用した wp2shell 攻撃を受け、Web シェルを仕込まれたり偽の管理者を作られたりした場合は、WordPress 本体の更新だけでなくファイルとデータベースの完全な掃除が必要になる。攻撃者は認証なしでコードを実行できるため、必ず FTP/SSH と SQL の両面から対処する。
この攻撃は SQL インジェクションで PHP ファイルをサーバーに直接書き込み、データベース内にも偽のメニュー項目や changeset を残す。パッチを当てただけではバックドアが生き残り、再侵入される危険がある。
上図は攻撃直後と完全クリーンアップ後の違いだ。この記事ではファイル・データベース・ユーザー管理の3層で掃除し、再発を防ぐまでの手順を詳しく解説する。
wp2shell 攻撃で何が起きているのか
WordPress の REST Batch API は複数の REST API リクエストをまとめて送信できる機能だ。この脆弱性を突かれると、認証なしで SQL インジェクションを起こし、INTO OUTFILE 命令で PHP ファイルをサーバーに書き込める。書き込まれた PHP ファイルは Web シェルとして機能し、攻撃者が自由にコマンドを実行できるようになる。
さらに攻撃者はデータベースに直接アクセスできるため、パスワードのハッシュを盗んだり、自分自身に管理者権限を付与したりすることが可能だ。偽のプラグインを /wp-content/mu-plugins/ に仕込んで恒久的なバックドアにする手口も確認されている。
被害にあったサイトを完全に掃除する手順
掃除は「ファイルの掃除」「ユーザーとセッションの掃除」「データベースの掃除」の3段階で進める。始める前に必ずファイルとデータベースの完全バックアップを取る。
ファイルシステムから Web シェルと偽プラグインを削除する
FTP クライアントや SSH でサーバーに接続し、まず /wp-content/cache/ ディレクトリを開く。キャッシュ系のディレクトリ（/cache/ や /wpo-cache/ など）に不自然な英数字の羅列（e042u9xy9ra1.php のようなファイル名）があれば、それが Web シェルだ。すべて削除する。
次に /wp-content/mu-plugins/ を確認する。Must-Use プラグインは自動的に有効化されるため、攻撃者が好んで使う場所だ。身に覚えのないファイル（galex_patch.php など）があれば削除する。通常の /wp-content/plugins/ にも見慣れないプラグインが追加されていないか調べる。
ファイルの掃除が終わったら、WordPress 本体をパッチ適用済みバージョン（6.9.5 または 7.0.2 以上）に更新する。この更新で Batch API の脆弱性自体が塞がる。
wp-config.php にファイル改変防止の定数を追加する
将来の攻撃に備え、管理画面からのファイル編集とプラグインのインストールを無効化する。FTP または SSH で wp-config.php を開き、以下の2行を追記する。
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );DISALLOW_FILE_EDIT は管理画面の「テーマエディター」「プラグインエディター」を無効化する。DISALLOW_FILE_MODS は管理画面からのプラグイン追加や更新をブロックする。すでに侵入された後の対策ではなく、掃除が完了した後に再発を防ぐ設定だ。
ユーザーとパスワード、セッションの掃除
攻撃者はデータベースに直接アクセスしていたため、パスワードのハッシュを抜き取った可能性が高い。管理者を含む全ユーザーのパスワードを変更する。WordPress 管理画面だけでなく、MySQL データベース自体のパスワードも変更し、wp-config.php の DB_PASSWORD を新しいものに書き換える。
パスワード変更だけでは不十分だ。攻撃者がまだログインしたままかもしれない。全セッションを強制的に切断するには、Salt Keys（ソルトキー）を再生成して wp-config.php に上書きする。WordPress 公式の Salt Keys ジェネレーターで新しいキーセットを取得し、既存のキーと置き換えれば全デバイスのログイン状態が即座に無効になる。
最後に、管理画面の「ユーザー」一覧を開き、見覚えのない管理者アカウントが作られていないか確認する。もし存在すれば即座に削除する。
データベースに残った偽のレコードを削除する
wp2shell 攻撃は、WordPress のセキュリティフィルターをすり抜けるために、データベース上に偽のナビゲーションメニュー項目と changeset（カスタマイザーの変更履歴）を一時的に生成する。これらのレコードは post_date が 2020-01-01 00:00:00 に固定されており、URL ペイロードに example.invalid を含むという特徴がある。
以下の SQL を phpMyAdmin などで実行する。なお、接頭辞（プレフィックス）がデフォルトの wp_ ではない場合は、コード内の wp_ を実際のプレフィックス（例: wp2_ や mysite_）に置き換える必要がある。
偽の changeset を削除する
DELETE FROM wp_posts WHERE post_type = 'customize_changeset' AND post_date = '2020-01-01 00:00:00';偽のナビゲーションメニュー項目を削除する
DELETE FROM wp_posts WHERE post_type = 'nav_menu_item' AND post_date = '2020-01-01 00:00:00';悪意のあるメタデータを削除する
DELETE FROM wp_postmeta WHERE meta_value LIKE '%example.invalid%';これらのクエリでデータベース上の痕跡を一掃できる。実行前には必ずデータベースのバックアップを取る。
データベースユーザーから FILE 権限を剥奪する
今回の攻撃は SQL インジェクション経由で INTO OUTFILE 命令を使い、データベースからディスクにファイルを書き込んでいた。WordPress の通常動作に FILE 権限はまったく不要だ。この権限を WordPress のデータベースユーザーから剥奪しておけば、同種の攻撃が再び成功する可能性を大きく下げられる。
データベースに root 権限でログインし、以下の SQL を実行する。'wp_user_name'@'localhost' は実際の WordPress 用データベースユーザー名に置き換える。
REVOKE FILE ON *.* FROM 'wp_user_name'@'localhost';
FLUSH PRIVILEGES;REVOKE FILE は FILE 権限を取り消し、FLUSH PRIVILEGES は変更を即時反映する。これでデータベースからファイルシステムへの書き込み経路が遮断される。
よくある質問
WordPress を更新しただけで掃除は不要か
更新だけでは不十分だ。攻撃者はすでに Web シェルをサーバーに書き込んでおり、そのファイルは更新では削除されない。データベース内の偽レコードや不正な管理者アカウントも残ったままになる。必ずファイルとデータベースの両方を掃除する。
DISALLOW_FILE_MODS を設定すると管理画面からプラグインを追加できなくなるのか
そのとおりだ。DISALLOW_FILE_MODS を true にすると、管理画面からのプラグインのインストール・更新・削除、テーマのインストール・更新がすべてブロックされる。必要な更新は FTP や SSH 経由で手動で行う運用になるが、攻撃者が管理画面からファイルを改変する経路を完全に塞げる。
SQL クエリのプレフィックス wp_ を変更し忘れるとどうなるか
テーブルが存在しないというエラーが出るだけで、データが破壊されることはない。それでも、間違ったテーブルを操作しないよう実行前に必ず実際のプレフィックスを確認する。多くのレンタルサーバーではインストール時に自動生成された固有のプレフィックスが使われている。
FILE 権限を剥奪すると WordPress の動作に影響は出るか
WordPress の通常動作に FILE 権限は一切使われない。記事の投稿やプラグインの動作、データベースの読み書きに影響は出ないため、安全に剥奪できる。
この記事のポイント
- WordPress 本体の更新だけではバックドアとデータベースの痕跡が残る
- /wp-content/cache/ と /wp-content/mu-plugins/ の不審な PHP ファイルを削除する
- 全ユーザーのパスワード変更と Salt Keys 再生成でセッションを強制切断する
- データベースから post_date が 2020-01-01 の偽 changeset とメニュー項目を削除する
- WordPress の DB ユーザーから FILE 権限を剥奪し INTO OUTFILE 経路を塞ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce.comがプラグイン読み込みを最適化、応答時間を最大400ms短縮
WooCommerce.comが大規模WordPressサイトのパフォーマンスを大幅に改善した手法が公開された。特定のリクエストで不要なプラグインを読み込まない「選択的プラグイン読み込み」である。この手法により、WooCommerce.comの内部APIエンドポイントではメモリ使用量が50%以上削減され、主要エンドポイントの応答時間が最大400ミリ秒以上短縮されたという。
WordPressはリクエストのたびにすべての有効化プラグインを読み込む仕組みだ。大多数のサイトでは問題にならないが、WooCommerce.comのように100を超えるプラグインが稼働する大規模サイトでは無視できないオーバーヘッドになる。今回の事例は、大規模WordPressサイトのパフォーマンスチューニングに新たな選択肢を示すものだ。
プラグインの一括読み込みは大規模サイトの足かせになる
WordPressのプラグインモデルはシンプルだ。有効化されているプラグインは、フロントエンドの表示でも管理画面の操作でも、REST APIの呼び出しでも、すべてのリクエストで例外なく読み込まれる。ほとんどのサイトにとってこれは合理的な設計である。挙動が予測しやすく、プラグイン同士の依存関係を意識せずに組み合わせられる。
しかしWooCommerce.comのように、マーケットプレイス、決済、アカウント管理、API、チェックアウト、パートナー向けワークフロー、検索連携、トラッキング、そして運用コードが複雑に絡み合う大規模アプリケーションでは、事情が異なる。100個以上のプラグインのうち、特定のリクエストで実際に必要なのはごく一部であることが多いのだ。
WooCommerce.comの開発者ブログで紹介された実例を見てみよう。商品の検索・表示ページは、マーケットプレイスへの出品ツールを必要としない。キャッシュされた内部APIは、チェックアウト処理と同じプラグイン群を必要としない。公開ドキュメントの表示に注文番号の採番ロジックは不要だ。にもかかわらず、これらすべてのリクエストが同じプラグインセットを読み込んでいる。
各プラグインは読み込み時にフックの登録、サービスの初期化、オプションの読み出し、翻訳ファイルのロード、カスタム投稿タイプの定義、RESTルートの追加、アセットのキューイング、互換性コードの実行などを行う。1つひとつは小さなコストでも、成熟したWooCommerceアプリケーションで積み重なると無視できない負荷になる。
ページキャッシュやエッジキャッシュはこの問題をある程度隠すが、根本的な解決にはならない。キャッシュミスは依然として発生する。APIリクエストは動的なものが多い。ログイン状態のリクエストはキャッシュをバイパスする。トラフィックが急増するタイミングで、運用系のエンドポイントが高いレイテンシに悩まされることもある。大規模WordPressサイトにとって、ブートストラップ処理の削減は確かなパフォーマンス向上手段だ。
選択的プラグイン読み込みの基本的な仕組み
WordPressは有効化プラグインの一覧を active_plugins オプションに保持している。ブートストラップ時にこのオプションを読み取り、リストにある各プラグインのメインファイルを順に読み込んでいく。
ここに介入する仕組みがオプションフィルターだ。pre_option_active_plugins または option_active_plugins フィルターを使えば、WordPressが実際にプラグインを読み込む前にリストを書き換えられる。重要なのは、このフィルターを通常のプラグインより先に実行される mu-plugin（Must-Use Plugin）に配置することだ。
add_filter(
'option_active_plugins',
function ( array $plugins ): array {
if ( ! should_limit_plugins_for_this_request() ) {
return $plugins;
}
return array_values(
array_diff(
$plugins,
plugins_to_skip_for_this_request()
)
);
}
);このコードの要点は3つある。どのリクエストでフィルターを適用するか、そのリクエストにとって安全に除外できるプラグインはどれか、そしてプラグインの一部を読み込まなかったことでサイト全体の状態が破損しないか、という点だ。
WooCommerce.comでは、mu-pluginでルートルールを早期に登録し、リクエストURIを完全一致、前方一致、または正規表現で照合する。ルールがマッチすると、あらかじめ定義されたプラグインを読み込み対象から外す仕組みだ。
この仕組みは、APIエンドポイントやブログ記事の表示など「ほとんどのプラグインが不要なリクエスト」で高い効果を発揮する。
ルール設計と安全性のトレードオフ
許可リストと除外リスト
選択的プラグイン読み込みの設計で最初に直面するのが、読み込むプラグインを決める方式だ。大きく分けて許可リスト方式と除外リスト方式がある。
許可リスト方式は、そのルートに絶対必要なプラグインだけをゼロからリストアップする。理論上は最も効果が高いが、大規模サイトでは脆さが問題になる。テーマ関数が別プラグインのクラスに依存しているケース、RESTハンドラが間接的に他のプラグインのヘルパー関数を呼んでいるケース、キャッシュミス時にのみ実行されるコードパスなど、暗黙の依存関係を見落とすとルートが壊れる。見落としはテストをすり抜けやすい。
除外リスト方式は、通常のアクティブプラグインリストから「このルートでは確実に不要」とわかっているものだけを取り除く。理想的な最小化にはならないが、安全性が段違いに高い。管理画面専用ツール、決済ゲートウェイ、メール配信処理など、明らかに関係ないグループをまとめて外すので、予期せぬ依存による障害が起こりにくい。
WooCommerce.comのチームは後者を主軸に採用している。開発者ブログの言葉を借りれば「各ルールをコードレビューの差分として確認でき、どのプラグインを残したか、なぜ外したかをコメントで説明できる」状態が、運用上の安心感をもたらすという。
除外が危険なリクエスト
すべてのリクエストが選択的読み込みの対象になるわけではない。WooCommerce.comでは以下のリクエストタイプを一律で除外対象から外している。
- wc-ajax
- wc-api
- rest_route（広範なクエリ文字列エントリポイント）
- クエリパラメータを含むダウンロードリクエスト
これらは動的に多様なコードパスに分岐する可能性があり、副作用の範囲を予測しにくいためだ。チェックアウト、カート、アカウント、管理画面、cron、Webhook、決済コールバック、ダウンロードといった「金銭・顧客データ・認証・権利確認・メール送信・サードパーティ連携」に触れるリクエストには、特に慎重な扱いが求められる。
依存関係の発見が最大の難所
動的なWordPressアプリケーションでは、あるルートが実際にどのプラグインに依存しているかを静的に解析する方法は存在しない。WooCommerce.comのチームは、ルートのコードを読み込み、明白な依存関係を追跡し、手動でリクエストフローを検証し、URLマッチングとエンドポイント動作のテストを書き、段階的にロールアウトしてエラーログとパフォーマンスデータを監視する、という実践的なアプローチを取っている。
注意すべきは、問題が特定の条件下でのみ表面化することだ。特定の商品ページ、特定のロケール、特定のリクエストパラメータ、キャッシュミス時、ログイン状態など、組み合わせは膨大になる。プラグインの読み込み不足によるエラーは再現条件が狭く、発見が遅れやすい。
WooCommerce.comで得られた具体的な効果
WooCommerce.comの開発者ブログでは、いくつかのエンドポイントで測定された具体的な数値が公開されている。
- 必要なプラグインのみを読み込んだリクエストでは、メモリ使用量が50%以上削減された
- 接続ストアが所有する有料サブスクリプション情報を返すエンドポイントは、約800msから約475msに短縮
- ストアにインストールされたプラグインの利用可能アップデートを通知するエンドポイントは、約880msから約550msに短縮
- WooCommerceオンボーディングフローで毎回呼ばれるエンドポイントも、同様の大幅改善
- 商品ページに対して決済ゲートウェイと無関係な拡張機能を除外した初期テストでは、ページ生成時間が約10%改善
これらの改善は、高トラフィックで責務が限定されたエンドポイントや、大規模なプラグイン構成を持つ匿名ユーザー向けページで特に顕著だった。逆に、ほぼすべてのプラグインが関与しうる動的なステートフルフローでは、相対的な効果は小さくなる。
監視すべき指標は、レスポンスタイム、PHPメモリ使用量、データベースクエリ数、高コストなプラグインのブートストラップ処理、デプロイ後のエラー率、予期しないリライトルールの変更、キャッシュミス時のルート固有の致命的エラーなど、多岐にわたる。
この手法が適するサイトと適さないサイト
この手法が効果を発揮するのは、以下の条件が揃っているサイトだ。
繰り返しになるが、これは最初に手をつけるべき最適化ではない。キャッシュ戦略の見直し、クエリパフォーマンスの改善、アセット読み込みの最適化、オブジェクトキャッシュの導入、明らかに不要なプラグインの整理といった基本的な施策を先に済ませてから検討するのが現実的な順序だ。
この記事のポイント
- 特定のリクエストで不要なプラグインを読み飛ばす「選択的プラグイン読み込み」により、WooCommerce.comの大規模サイトでメモリ使用量50%以上の削減と大幅な応答時間短縮が達成された
- 仕組みは
option_active_pluginsフィルターとmu-pluginの組み合わせで実装でき、技術的なハードル自体は高くない - 安全性を確保するには「許可リスト」より「除外リスト」方式が現実的であり、ルールをコードとして管理しテストと監視を徹底することが不可欠
- この手法は大規模サイト向けの「最後の一手」であり、キャッシュやクエリ最適化といった基本的な施策を先に実施すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceバリエーション商品のカート追加で重大エラーが出る時の修正方法
WooCommerce のブロックベースカートでバリエーション商品を追加した際に「woo-min-max-quantity-step-control-single」プラグインが原因で「このサイトで重大なエラーが発生しました」と表示される場合、原因はプラグインが商品オブジェクトの取得失敗を考慮していないことだ。該当ファイルの PHP コードに数行の修正を加えればエラーを回避できる。
なぜブロックカートでバリエーション商品だけエラーになるのか
エラーログを確認すると、問題はプラグインの min-max-controller.php 872行目付近で発生している。この行では wc_get_product() で商品情報を取得した直後に ->get_id() を呼んでいるが、wc_get_product() は対象の商品が見つからなかった場合に false を返す。ブロックベースのカート（Store API）経由でバリエーション商品が追加されると、この関数がまれに false を返す状況が発生する。プラグインのコードはその可能性をまったく想定しておらず、結果として「Call to a member function get_id() on false」という致命的な PHP エラーに直結している。
エラーを根本解決するためのコード修正手順
false チェックを追加する該当ファイルを開き 872 行目周辺を特定する
FTP クライアント、またはレンタルサーバーのファイルマネージャーで、以下のパスにあるファイルを開く。WordPress 管理画面の「プラグイン」→「プラグインファイルエディター」から編集するのはできるだけ避ける。エディター画面で編集ミスをするとサイト全体が停止するリスクがあるためだ。
/wp-content/plugins/woo-min-max-quantity-step-control-single/includes/min-max-controller.php
使用しているエディタで行番号表示を有効にし、872 行目付近まで移動する。エラーログに表示されているとおり、->get_id() を直接呼んでいる箇所を探そう。
修正前と修正後のコードを比較する
$min = $product->get_id();
if ( ! $product || ! is_a( $product, ‘WC_Product’ ) ) {
return;
}
$min = $product->get_id();
PHP コード修正の内容と意味
修正の核心は、$product が有効なオブジェクトかどうかを事前に検証することだ。
! $product は wc_get_product() が false を返した場合を検出する。is_a( $product, 'WC_Product' ) は、取得できたとしてもそれが WooCommerce の正規の商品オブジェクトであることを確認する。どちらかの条件を満たさなければ return で処理を中断し、以降の ->get_id() が呼ばれないようにする仕組みだ。
このガード節を入れることで、ブロックカート経由でどういった商品情報が渡ってきても、致命的なエラーにはならなくなる。
修正してもエラーが直らない場合の確認点
まれに、修正だけでは根本解決しないケースがある。以下の点も確認してみてほしい。
WooCommerce データベースのクリーンアップを実行する
「WooCommerce」→「ステータス」→「ツール」タブに移動し、「WooCommerce トランジェントをクリア」と「期限切れのトランジェントを削除」を実行する。キャッシュが原因で商品情報が正しく取得できていない場合に効果がある。
最小最大数量プラグインのバージョンと WooCommerce のバージョンを確認する
プラグインが最新の WooCommerce や Store API に対応していない可能性がある。プラグインの公式ページで対応バージョンを確認し、場合によっては別の数量制御プラグインを検討する必要がある。修正を加えても根本的な設計の問題で他の不具合が発生する場合は、開発者に修正リクエストを送りつつ、一時的に従来のショートコードカート（[woocommerce_cart]）へ切り戻すことも視野に入れる。
よくある質問
この問題はブロックカートだけに発生するのか
主にブロックベースのカートとチェックアウト（Store API）で発生する。従来のショートコードカートではエラーが出ないことも多いが、プラグインコードに潜在的な問題があるため、修正しておく方が安全だ。
プラグインがアップデートされたら修正は消えるか
消える。今回の修正はプラグインのコアファイルを直接編集しているため、プラグインにアップデートが配信されると編集内容は上書きされる。アップデート後に同様のエラーが再発した場合は、再び同じ手順で修正するか、開発者が修正を取り込むまでアップデートを控える必要がある。
子テーマの functions.php でこのエラーを回避できるか
難しい。今回のエラーはプラグイン内部の特定の行で発生しており、かつ商品取得のロジック周辺にフックが用意されていない限り、テーマファイル側から割り込んで防御することはできない。直接ファイルを編集する今回の方法が最も確実な対処法になる。
修正中にサイトが壊れてしまった場合の直し方は
FTP でサーバーにアクセスし、修正前にバックアップしておいた min-max-controller.php を上書きアップロードする。バックアップがない場合は、プラグインを一度削除して再インストールするのが早い。ただし、プラグインの設定内容はあらかじめメモしておく必要がある。
この記事のポイント
- エラー原因はプラグイン内での
get_id()呼び出し前にfalseチェックがないこと - 修正対象は
min-max-controller.phpの 872 行目付近 wc_get_product()がfalseを返す状況を考慮したガード節を追加する- ブロックカート（Store API）利用時に特に発生しやすい PHP エラーへの対処法
- 直接ファイルを修正するため、プラグインのアップデートで編集が上書きされる点に注意
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
AIで返金証拠の偽造が容易に、EC事業者に迫る新たな脅威
オンラインストアにおける返金申請に、生成AIで偽造された証拠写真や配送記録を使う手口が急増している。実店舗を持たずに商品を販売するEC事業者にとって、返品プロセスのデジタル化はコスト削減に直結するが、その裏で「証拠の信頼性」という前提が根底から揺らぎ始めたのだ。特に自動審査システムを導入する事業者ほど、巧妙化するAI画像に脆弱になりやすい。
米国では2025年の返品総額が約8,499億ドルに達し、そのうち約9%が不正申告と推計されている。ECの返品率は実店舗の2倍以上に上る。実務に詳しい業界関係者の間では、これまで人の手で検知できていた偽装が、AIによって誰でも量産できる段階へ移行したとの危機感が強い。この記事では、AI返金詐欺の実態と、事業者が現実的に取りうる対策、そしてその経済的なジレンマまでを整理する。
EC返金の仕組みと「証拠写真」の脆さ
写真1枚で成立していた返金審査
一般的なECサイトでは、返品返金の審査を写真と購入者の申告文のみで完了させるケースが多い。商品の破損やパッケージの潰れを写した画像を確認し、配送記録と照合して問題がないと判断すれば、そのまま返金が実行される。
この流れを支える前提は「購入者が提出する写真は、実際の商品を写したものだ」という一点に尽きる。生成AIはこの前提そのものを無力化してしまう。実在しない破損をあたかも本物のように描写できるため、写真1枚の信頼性では太刀打ちできなくなるからだ。
特に低額商品や食品など、返送コストが商品価格を上回るケースでは、商品の返却を求めずに返金に応じる「返品不要返金」が多用される。詐欺師がこの仕組みを悪用するのは以前からだが、AI画像の登場でそのハードルは大幅に下がった。
返品不要返金が狙われる理由
送料と検品コストを考慮し、商品を送り返させずに返金する方式は、カスタマーサポートの効率化に寄与する。しかし同時に、詐欺師にとっては「商品を手元に残したまま返金だけを受け取れる」絶好の抜け穴になる。生成AIによる偽造証拠は、この穴をさらに拡大する存在だ。
Practical Ecommerceの記事は、米国の小売企業Bogg BagとBoll & Branchが、実際にAIで改ざんされた返品証拠に遭遇したと報じている。こうした事例は大企業に限らず、中規模以下のネットショップにも波及しつつある。
生成AIが作る偽造証拠の手口
AIによる返金詐欺は、単に商品画像を改変するだけにとどまらない。返品プロセス全体のストーリーを捏造できる点が、これまでの手口と一線を画す。
偽造できる証拠の範囲
詐欺師が短時間で生成できる偽造証拠の範囲は広い。以下に主な種類を整理する。
- 商品のひび割れ、汚れ、カビ、破れ、漏れ、へこみ、部品欠落
- 損傷したパッケージや潰れた配送箱の写真
- 掲載写真と色・機能が異なると見せかける加工
- 「返金を承諾した」とする架空のカスタマーサポートチャット
- 配送記録、運送会社の書類、配達完了画面の偽スクリーンショット
- 各ストアの返品ポリシーに合わせた苦情文の自動生成
- 複数店舗で使い回すためのバリエーション作成
いずれの偽造も、数回のプロンプト入力で完成させられる。写真編集ソフトの知識や文書の改ざんスキルはもはや不要だ。これが「誰でも詐欺師になれる」と言われるゆえんである。
AI画像のリアリティと簡単さ
Practical Ecommerceの記事では、わずか10単語のプロンプトから、ガラス花瓶が粉々に割れた説得力のある画像が生成された例が紹介されている。照明の反射や影の付き方まで自然で、一見しただけでは実写と区別がつかない。
詐欺の実行に必要なコストも時間も極小化され、同時に複数アカウントや複数店舗を横断して悪用できる。従来のように一人の詐欺師が手作業で細工する手法とは、規模感がまったく異なる。AI返金詐欺は、取引・紛争・物流・カスタマーサポートの各段階にまたがる「拡張可能な欺瞞」と呼べるレベルに達している。
この比較で示すように、詐欺の効率性と拡張性が段違いに向上した。事業者は、こうした「量産型の偽装」への耐性を今から備えなければならない。
AI詐欺に立ち向かうための対策とコスト
検知技術と審査プロセスの強化
EC事業者が取れる防御策はいくつか存在する。画像のメタデータ分析や圧縮パターンの精査、逆画像検索による使い回し画像の発見、アカウントの返品履歴や行動ログのスコアリングなどは、従来からある不正検知の延長線上にある手法だ。
さらに実効性が高いとされるのは、次のような対策である。
- 商品写真を1枚だけでなく、別アングルや短い動画の提出を必須にする
- 高額商品や返品履歴に不審な動きがあるアカウントは、人手による詳細審査に切り替える
- 特定の商品カテゴリや顧客セグメントに対して、返品時に現物の返送を義務付ける
- 提出された画像をAIでスキャンし、合成や改変の痕跡を自動判定する
ただし、これらの対策にも限界はある。AIによる画像生成技術は日進月歩で進化しており、検知ツールが誤って正当な申告を不正とみなす「偽陽性」も無視できない。偽陽性が増えれば、誠実な顧客に無用な負担を強いることになり、サポートコストやブランドイメージへの悪影響につながる。
対策コストが上回るジレンマ
より深刻なのは、不正防止にかけるコストが、防げる被害額を上回ってしまうケースだ。Practical Ecommerceの記事は「3万ドルの不正を防ぐために10万ドルのコストをかけるのは無意味だ」という端的な指摘を紹介している。
厳格な返品ポリシーを設ければ、返送送料や検品費用、カスタマーサポートの問い合わせ対応が増大する。顧客満足度の低下がリピート率やLTV（顧客生涯価値）に及ぼす影響を加味すれば、単純に「不正をゼロにする」施策は経済合理性を欠くのだ。
このジレンマは、AI詐欺のコストがあまりに低いことに起因する。詐欺師側は数分で偽造証拠を作れる一方、事業者側はそれを証明するためにサポートスタッフの確認作業、倉庫記録の照合、運送会社との連携、場合によっては正式な異議申し立て手続きまでが必要になる。攻撃と防御の非対称性が、年々拡大しているのが現状だ。
攻撃側と防御側の非対称性を視覚化すると、その差は歴然としている。AIがもたらすインパクトは、単に詐欺が増えたという量的な問題にとどまらず、防御の経済性そのものを破綻させかねない質的な変化だ。
実務に落とし込む現実的なアプローチ
全件精査ではなく「優先度ベースの審査」へ
限られたリソースの中でAI詐欺に対抗するには、「全件を完璧に防ぐ」発想を手放すことが出発点になる。代わりに、不正のリスクが高い申告を優先的に精査し、それ以外はある程度の漏れを許容する設計が現実的だ。
具体的には、商品単価の高い申告、返品頻度が異常に高い顧客、新規アカウントからの高額返金申請、画像のメタデータに不自然な欠落があるケースなどをスコアリングし、閾値を超えたものだけを手動で再確認する仕組みが考えられる。これらのルールベースのフィルタは、AI検知ツールと組み合わせることで精度を上げられる。
不正対策とCXのバランス設計
返品ポリシーを厳格化するほど、一般的な顧客の購入障壁は上がる。「返品時に動画を必須とする」「返送を全商品に義務付ける」といった一律のルール変更は、CX（顧客体験）を大きく毀損し、売上全体に悪影響を及ぼす可能性が高い。
むしろ有効なのは、優良顧客と疑わしい顧客をセグメントし、前者にはこれまで通りのスムーズな返金体験を維持しつつ、後者にのみ追加の証拠提出を求める段階的なアプローチだ。購買履歴や会員登録からの経過期間、過去の返品率などは、セグメントの判断材料として実装しやすい。
また、AIによる画像スクリーニングを導入する場合も、完全自動化ではなく「疑わしい画像を人間の担当者に提示する」補助ツールとして位置づけることで、偽陽性による誤った拒否を減らせる。
この段階的なアプローチなら、防御コストを抑えつつ、AIが生成した偽装画像の多くを発見できる可能性が高まる。最初から完璧を目指さず、リスクベースでリソースを集中させる考え方こそ、AI時代の返金審査に求められる現実解である。
今後広がるAI詐欺とEC事業者の備え
画像生成AIの進化はさらに加速する
画像生成AIの品質は、ここ1〜2年だけでも目覚ましく向上してきた。指の本数に違和感が残っていた初期段階はすでに過去のものとなり、テクスチャの再現性や光の反射、被写界深度の自然さは、人間の目では実写と区別できない水準に近づいている。
音声や動画の生成技術も同時に進化しており、将来的には「壊れた商品を手にした購入者が不満を訴える短い動画」すら数クリックで捏造される可能性がある。そうなれば、動画による証拠提出ですら防御策としての有効性を失いかねない。
まずは直近の返金履歴を監査する
Practical Ecommerceの記事は「問題を認識することが戦いの半分だ」と述べ、近い時期の返金記録を精査し、AIによる偽装がすでに紛れ込んでいないか確認することを推奨している。
具体的には、過去3〜6ヶ月の返金申請から、同じような構図・影の付き方・背景の写真が複数アカウントで使われていないか、メタデータに不自然な欠落や一貫性のなさがないか、という観点でのチェックが有効だ。AI画像生成ツールは撮影機器情報やGPSタグを埋め込まないため、Exifデータの不在そのものが一つのシグナルになりうる。
AI返金詐欺はまだ黎明期にある。にもかかわらず、手口の洗練と低コスト化は予想以上の速度で進んでいる。EC事業者にとっての最善手は、抜本的な対策を急ぎつつ、経済的なバランスを冷静に見極めることだ。
この記事のポイント
- 生成AIにより、返金詐欺の証拠写真や文書が誰でも短時間で偽造できるようになった
- 「返品不要返金」のような効率重視のプロセスが、AI詐欺に悪用されやすい構造になっている
- 防御策には画像解析や動画提出の義務化があるが、偽陽性やコスト増という副作用を伴う
- 不正額を上回る防御コストをかけることは経済的に無意味であり、リスクベースの優先審査が現実解
- まずは直近の返金履歴を監査し、AIによる偽装の混入有無を確認することから始めるべきである
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressカスタムHTMLブロックが編集画面で消える原因と直し方
WordPress のブロックエディターでカスタム HTML ブロックを保存後に編集画面を開き直すと、ブロックの中身がまるごと消えて空欄に見える現象は、Gutenberg の React 側パーサーが HTML 構造を正しく解析できずに描画を放棄しているのが主な原因だ。script タグや閉じタグのない要素、複雑なインラインスタイルなどが引き金になる。
なぜカスタムHTMLブロックが編集画面で空になるのか
フロントエンドでは正しく表示されるのに、管理画面のブロックエディターだけで中身が空になるのは、データそのものはデータベースに保存されている証拠だ。コードエディターモードに切り替えれば、貼り付けた HTML が消えずに残っているのが確認できる。この現象が起こるのは、ブロックエディターがビジュアルモードでブロック内容を再表示するときに、DOM パーサーが特定の HTML を「壊れた構造」と判断してレンダリングを飛ばしてしまうからだ。
具体的には、Gutenberg が内部的に使用している React の DOM レンダリング機構が、管理画面の安全な枠組みの中で処理できないタグや構文に遭遇すると、そのブロック全体を安全のためにスキップする。結果として視覚的には空のブロックに見えるが、データベースの post_content には元のコードがそのまま格納されている。
カスタムHTMLブロックの中身が消える原因を特定する手順
まず、どの部分が問題を引き起こしているのかを切り分ける。以下の手順で原因箇所を絞り込む。
ブロックエディターのコードエディターモードで現状を確認する
編集画面右上の「︙」メニューから「コードエディター」を選択すると、ビジュアル表示ではなく生の HTML 構造が表示される。カスタムHTMLブロック内のコードがここで確認できれば、データは失われていない。このとき、Markdown 記法でブロック境界を示す <!-- wp:html --> と <!-- /wp:html --> のコメント行の内側にコードが残っているかを確かめる。
HTMLを最小単位に分解して原因のタグを特定する
ブロックに貼り付けた HTML を、1つのタグ単位で分割してカスタムHTMLブロックに1つずつ入れ直す。たとえば script タグ、style タグ、空要素（<div></div> など）、インラインイベントハンドラ（onclick など）をそれぞれ別のブロックに分けて保存し、再読み込み時に消えるかどうかをテストする。問題を起こすタグが特定できれば、その部分だけ別の実装方法に切り替えられる。
プラグイン競合の可能性を調べる
特定のプラグインがブロックエディターの動作に干渉して、カスタムHTMLブロックの描画を阻害しているケースもある。特にエディター拡張系のプラグインや、セキュリティ目的でスクリプトをフィルタリングするプラグインが入っている場合は、すべてのプラグインを一度無効化して標準テーマに切り替え、問題が再現するか確認する。プラグインが原因であれば、1つずつ再有効化して犯人を特定する。
カスタムHTMLブロックを正常に表示させる具体的な修正手順
原因が特定できたら、次は実際にブロックを正常に表示させる。script タグや複雑な HTML 構造が原因だった場合、以下のアプローチで回避できる。
script タグや iframe はカスタムHTMLブロックではなく適切な場所に配置する
Gutenberg のカスタムHTMLブロックは、セキュリティ上の理由から script タグの実行を制限している。また、ビジュアルエディターでの再レンダリング時に script タグを含むブロックを空として扱う挙動が確認されている。JavaScript を埋め込みたい場合は、カスタムHTMLブロックではなく、functions.php に wp_enqueue_script で登録するか、専用のコード埋め込みプラグインを使う。iframe も同様に、エディターのプレビューで空白になることがあるため、フロントエンドのみで描画される仕組みを検討する。
閉じタグのない空要素を見直す
カスタムHTMLブロックに <div></div> のような中身のない空タグや、閉じタグを省略した要素が含まれていると、Gutenberg のブロックパーサーが構造を正しく解釈できずにブロック全体をスキップすることがある。空の div や span は削除するか、 を入れて実体を持たせる。とくに WordPress の自動整形機能（wpautop）が余分な p タグや br タグを挿入することで、意図しない空要素が生まれることもある。
複雑なHTML構造はカスタムフィールドやショートコードに置き換える
テーブルやフォーム、装飾を多用したマークアップは、カスタムHTMLブロック1つにまとめるよりも、ACF（Advanced Custom Fields）のテキストエリアフィールドや、ショートコード化して出力する方が安定する。とくにクライアントが自分で編集する前提のサイトでは、カスタムHTMLブロックを直接触らせると今回のようなトラブルが再発しやすい。テーマ側でテンプレートパーツとして管理し、投稿画面では入力欄だけを提供する設計が安全だ。
今後同様のトラブルを防ぐための運用ポイント
カスタムHTMLブロックに貼り付ける前にコード検証を行う
外部の HTML スニペットをそのまま貼り付ける前に、W3C のバリデーターや VSCode の構文チェック機能でタグの閉じ忘れや文法エラーがないかを確認する。コピー元の Web ページから取得したコードには、不要な属性や非推奨のタグが混じっていることが多い。貼り付け前に一度テキストエディターにペーストし、明らかな問題を取り除いてからブロックに入力する習慣をつける。
WordPress と Gutenberg を最新バージョンに保つ
Gutenberg プラグインを単体でインストールしている場合は、定期的に更新することでブロックパーサーの改善や既知の不具合修正が適用される。コア組み込みのブロックエディターであっても、WordPress 本体のアップデートによってパースエンジンの挙動が改良されることがある。編集画面でカスタムHTMLブロックが空になる現象の一部は、過去のバージョンで修正されたバグに起因している可能性もあるため、まずは最新の状態であることを確認する。
どうしても必要な場合はコードエディターモードを常用する
ビジュアルエディターで空になってしまう HTML をどうしてもページに残したいときは、編集時にコードエディターモードに切り替えて作業する方法が最終的な回避策になる。データベースにコードが正しく保存されているなら、コードエディター表示では常に中身が確認できる。手間は増えるが、複雑なマークアップや埋め込みコードを扱うページでは、あらかじめこの運用を前提にしておくとトラブルが起きても編集が止まらない。
よくある質問
カスタムHTMLブロックの中身は完全に消えたのか
ビジュアルエディターでは空に見えても、コードエディターモードに切り替えると HTML が残っていることがほとんどだ。データベースの post_content にも保存されているため、失われたわけではない。
プラグインをすべて無効化しても直らない場合はどうすればいいか
テーマの functions.php や使用中の子テーマがエディターの動作に干渉している可能性がある。標準テーマ（Twenty Twenty-Five など）に一時的に切り替えて再現するか確認し、テーマ側のフィルターやアクションを調査する。
script タグをカスタムHTMLブロックで使う正しい方法はあるか
原則としてカスタムHTMLブロック内の script タグは推奨されない。管理画面でのレンダリング問題に加え、セキュリティプラグインやサーバー側のフィルターで除去されるリスクもある。どうしても必要な場合はショートコード化するか、wp_enqueue_script でテーマに登録するのが安全だ。
ビジュアルエディターで空白になる特定の HTML タグの一覧はあるか
公式の一覧は存在しないが、script タグ、style タグ、iframe、object、embed、空の div や span、コメントアウト行、複雑に入れ子になったインラインスタイル付き要素などが報告されている。問題が起きたら該当タグを一つずつ検証するのが確実だ。
ビジュアルエディターで空になる現象は Gutenberg のバグなのか
仕様とバグの両面がある。script タグの実行制限はセキュリティ上の意図的な制限であり、空要素のパース失敗はブロックエディターの改善が期待される領域だ。WordPress コアのバージョンアップによって挙動が変わることもあるため、最新バージョンへの更新が有効な場合が多い。
この記事のポイント
- カスタムHTMLブロックが空に見えてもデータはデータベースに残っている
- script タグや空要素、閉じタグ省略がパース失敗の主原因
- コードエディターモードで中身を確認し原因タグを特定する
- 複雑な HTML はカスタムフィールドやショートコードで管理する
- WordPress と Gutenberg の最新化で改善するケースがある
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Google、匿名化検索データを競合と共有へ EUのDMA決定の全容
EUの欧州委員会が2026年7月16日、Googleに対して2つの拘束力のある決定を下した。検索データを匿名化した上で競合他社と共有すること、そしてAndroidの一部機能を競合AIアシスタントに開放することだ。いずれもデジタル市場法（DMA）に基づく措置である。
この決定の影響は検索エンジンにとどまらない。AIチャットボットも対象に含まれており、検索とAIが融合しつつある現在の状況において、今後の競争環境を左右する転換点となる可能性が高い。
DMAに基づく2つの決定の全体像
今回の決定は、欧州委員会が2026年4月に公開協議を経て暫定的な見解を示していたものを最終化した形だ。2つの柱で構成されている。
- 検索データの共有義務。Googleの検索結果に関するクエリ、クリック、閲覧、ランキング位置の匿名化データを、公正かつ非差別的な条件で競合に提供すること
- AndroidのAI相互運用性の確保。競合AIアシスタントが音声起動やアプリ内操作を実行できるよう、OSレベルの機能を開放すること
違反時の罰金を伴う独占禁止法の案件とは異なり、DMAに基づく今回の措置は構造的な是正を目的とする。欧州委員会は、Googleの現在のデータ共有の取り組みは不十分だと明確に指摘している。
この図で示した通り、データ共有の枠組みが整うことで、競合検索エンジンやAIチャットボットはGoogleが長年かけて蓄積してきた規模の検索インタラクションデータを活用できるようになる。
検索データ共有の具体的な仕組みと対象範囲
共有されるデータの内容
共有対象となるのは、Google検索の無料・有料を問わずすべての検索結果から生成される匿名化データである。具体的には以下の情報が含まれる。
- 検索クエリ（ユーザーが入力した検索語句）
- メタデータ（使用言語、デバイスの種類）
- 表示されたURL一覧
- ユーザーのクリックや閲覧といったインタラクション情報
- 検索結果内での表示位置（ランキング）
一方で、Googleのランキングアルゴリズムそのものは共有対象外だ。また個人を特定できる情報（アカウント詳細、検索履歴、タイムスタンプ、極端に稀または長大なクエリ）は除外される。
利用資格と審査プロセス
このデータを利用できるのは誰でもない。欧州委員会が定めた要件を満たす必要がある。
- EU圏内で月間5万人以上のユーザーを持つこと
- 2年以上の事業運営実績があること。新規参入企業の場合は投資実績による代替審査を受けること
- セキュリティ審査と独立監査を通過すること
これらの条件をクリアした事業者のみが、Googleとライセンス契約を結びデータの提供を受けることができる。データ価格は市場レートではなくコスト回収ベースで算定される。
AIチャットボットについても、DMA上でオンライン検索エンジンと見なされるものは利用資格がある。ただしデータの用途は、自社の検索・ランキングシステムの改善に限定され、汎用AIモデルの学習やGoogleの検索結果の複製には使用できない。
AI検索時代におけるデータの重要性
この決定が単なる検索エンジン間の競争を超えた意味を持つのは、AIチャットボットが回答を生成する仕組みと深く関わるからだ。
グラウンディングと検索データ
AIチャットボットが正確な回答を返すためには「グラウンディング（事実確認のための根拠付け）」と呼ばれるプロセスが欠かせない。最新のWebデータを参照し、回答の確からしさを検証する仕組みだ。
Googleは自社のAIに対して「FastSearch」というシステムでグラウンディングを行っている。これはGoogle自身の検索ランキング信号に依存する仕組みであり、当然ながら競合には提供されていなかった。
今回の決定で共有される匿名化データ（クエリ、クリック、閲覧、結果位置）は、競合各社が独自の情報検索・ランキングシステムを構築するための材料となる。グラウンディングもこの用途の一つとして認められている。
検索トラフィックへの影響は限定的か
短期的に見れば、Webサイト運営者が感じるトラフィックへの影響は限定的だろう。SE Rankingのデータによると、2026年1月時点で全AIプラットフォームを合わせた紹介トラフィックは、世界のインターネットトラフィック全体の約0.24%に過ぎない。
データへのアクセスが改善されれば競合エンジンやチャットボットの開発が進む可能性はあるが、それだけでユーザーの検索行動が一気に変わるわけではない。重要なのは、このデータを実際に製品開発に活かせるかどうかだ。
AndroidのAIアシスタント開放
2つ目の決定はAndroidに関するものだ。GoogleはOSレベルの機能を競合AIアシスタントに開放する義務を負う。
- ユーザーが「Hey Google」のような音声コマンドで競合アシスタントを起動できるようにすること
- 競合アシスタントがアプリ内で動作し、タクシーの予約や返信文の作成といった操作を実行できるようにすること
Google自身のGeminiアシスタントはすでにこのレベルのアクセス権を持っている。今回の決定はこの非対称性を是正するものだ。
主な機能の実装期限は次期メジャーリリースのAndroid 18、遅くとも2027年8月1日までとされている。複数のアシスタントが異なるウェイクワードで同時応答できる機能にはさらに1年の猶予が与えられ、2028年8月1日が期限となる。
Googleの反応とプライバシーをめぐる議論
Googleは両方の決定に反対の立場をとっている。Alphabetのグローバル問題担当プレジデントであるKent Walker氏は公式ブログで、「数百万人の欧州市民にとって不可欠なプライバシーとセキュリティの防御線を損なうリスクがある」と表明した。
同氏はまた、GoogleがDMAの目的に沿った解決策を繰り返し提案してきたことも強調している。検索データの共有については、適切な匿名化やユーザーの知識・同意なしに、欧州の検索データが見知らぬ企業に開示されることへの懸念を示した。
これに対し欧州委員会は、匿名化のプロセスが多層的な技術処理と契約上の保護措置で構成されており、内部および外部のプライバシー専門家の関与のもとで開発されていると説明する。Googleはデータ共有前にサイバーセキュリティやデータ保護の基準に基づいて申請者を審査できる。独立したテストで保護措置が不十分と判明した場合は、措置の見直しも可能だ。
今後の展開とスケジュール
2026年後半は、Googleがデータセットの整備と提供条件の策定に費やす期間となる。価格提案の期限は遅くとも2027年1月だ。各事業者はライセンス契約と価格合意を経て、それぞれのスケジュールでデータ提供を受けることになる。
Android側の主な変更は2027年8月1日、複数アシスタントの同時音声起動は2028年8月1日が期限だ。欧州委員会はこれらの措置を2年ごとに見直し、匿名化が不十分と判断されれば再検討を行うとしている。
この決定が実際に検索エンジンやAIチャットボットの多様化を促すかどうかは、資格審査を通過する事業者の顔ぶれと、提供されたデータをどれだけ製品開発に活かせるかにかかっている。すぐに目に見える変化はないが、中長期的には検索とAIの競争環境を変える可能性を秘めた決定と言えるだろう。
この記事のポイント
- EU欧州委員会がDMAに基づき、Googleに匿名化検索データの共有とAndroidのAIアシスタント開放を義務付ける決定を下した
- 共有対象はクエリ・クリック・閲覧・結果位置のデータで、ランキングアルゴリズム自体は対象外。AIチャットボットも利用資格あり
- Googleはプライバシーとセキュリティへの懸念を表明しているが、欧州委員会は多層的な匿名化と審査プロセスで対応
- 短期的な影響は限定的だが、中長期的には検索とAIの競争環境に変化をもたらす可能性がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ハッキングされたWordPressサイトの完全復旧手順と再発防止策
ハッキングされた WordPress サイトを復旧するには、マルウェアの削除だけでは不十分であり、SFTP や SSH といったホスティングレベルの認証情報をすべてローテーションし、バックドアを残さず完全に除去した上で、数週間にわたって再感染していないか監視を続ける必要がある。
WordPress がハッキングされる主な原因はどこにあるのか
侵入経路として圧倒的に多いのが、更新されていないプラグインやテーマの脆弱性だ。Patchstack の統計では、WordPress エコシステム全体の脆弱性の約96%がプラグイン、残り4%がテーマに存在し、コア本体に起因するものはごくわずかである。脆弱性が公表され修正パッチがリリースされると、攻撃者は数時間以内にそのバージョンを標的としたスキャンを開始する。
もう一つの主な侵入口は、弱いパスワードや使い回しの認証情報、あるいはフィッシング詐欺などで盗まれたログイン情報だ。攻撃者は WordPress の管理画面だけでなく、SFTP や SSH、ホスティングコントロールパネルといった上位のアクセス権も狙う。
侵入に成功した攻撃者は、すぐに目立った改ざんを行うとは限らない。ファイルに巧妙に偽装したバックドアを仕込み、追加の管理者アカウントを作成した後、数週間から数カ月潜伏するケースが一般的だ。そのため、サイト改ざんの直前に取得したバックアップであっても、見えないバックドアがすでに仕込まれている可能性を前提に復旧作業を進めなければならない。
上図の流れが示すとおり、攻撃者はサイトに侵入したあと長期間潜伏し、ファイルやデータベースの奥深くに復旧を妨げる仕掛けを残す。
完全な掃除と再発防止のための5ステップ
証拠を保全しログを収集する
復旧作業に着手する前に、改ざんされた状態のサイト全体（全ファイルとデータベースダンプ）のバックアップを取得し、証拠として安全な場所に保管する。ログの収集も同時に行う。利用しているサーバー会社へ、ウェブアクセスログ、SSH ログ、SFTP ログを依頼する。ログの保存期間はサーバー会社によって異なり、ウェブアクセスログは48時間程度、SFTP ログは提供されない場合もあるため、できるだけ早く依頼する必要がある。
解析ツールを使って感染範囲を特定する
取得したバックアップとログを解析する。AI を活用した解析ツールを使うと、大量のファイルからパターンを検出しやすい。もし感染前のクリーンなバックアップが存在するなら、それと比較することで未知のバックドアの発見率が大幅に上がる。スキャン範囲は wp-content ディレクトリ内だけに限定せず、ドキュメントルート全体とし、フォントファイルやキャッシュディレクトリに偽装されたシェルスクリプトも見落とさないようにする。
見つかったマルウェアと不正アカウントを削除する
検出された悪意のあるファイルは無効化ではなく削除する。単にプラグインを無効化しただけでは、該当ファイルに直接 URL でアクセスされると動作してしまう。また、管理画面のユーザー一覧に表示されない管理者アカウントや、データベースに直接埋め込まれた不正なエントリも除去する。
すべての認証情報をローテーションする
ファイルの掃除が完了しても、認証情報が漏洩したままだと再感染を繰り返す。WordPress のソルト（暗号化用の乱数文字列）とデータベースのパスワードを変更し、全ユーザーのパスワードをリセットする。さらに、SFTP のパスワード、SSH の公開鍵（身に覚えのない鍵はすべて削除）、API トークン、ホスティングのコントロールパネルのパスワードもすべて変更し、多要素認証を有効にする。作業に関わった全員が、自分のパソコンをマルウェアスキャンし、FTP クライアントにパスワードを保存する習慣をやめることも忘れてはならない。
この三層すべてで認証情報を更新しない限り、攻撃者は残った認証情報を使って何度でも侵入できる。
再感染の有無を監視し、クリーンな状態を維持する
一度の掃除で完全に除去できたと判断してはならない。掃除中に攻撃者が再侵入している可能性もあるため、作業が完了したら新しいバックアップとログを取得し、最初の解析ステップから再度実行する。このサイクルを、少なくとも二回連続で異常が検出されなくなるまで繰り返す。
本当にクリーンだと確信できるバックアップが取得できたら、それを信頼できるソース・オブ・トゥルース（基準点）として保管する。その後の定期バックアップはすべてこの基準点と比較し、差分が発生した瞬間を検知できるようにする。サイトが改ざんされる前に異常を捉えるには、復旧後も数週間は毎日バックアップとスキャンを継続し、問題がなければ監視頻度を徐々に落としていく方法が現実的だ。
アクセス権限を「必要性」で見直す
WordPress の管理者アカウント、SFTP ユーザー、SSH 鍵、ホスティングのコントロールパネルユーザーは、それぞれが攻撃者にとっての侵入口になり得る。信頼できる人物であっても、その人が使うパソコンがマルウェアに感染したり、パスワードがフィッシング詐欺で盗まれたりすれば、そのアカウントは攻撃者に利用される。
そのため、アクセス権限は「信頼」ではなく「業務上の必要性」だけを基準に付与する。サイトの編集者に管理者権限は必要ないし、たまにコンテンツを修正するだけの担当者に SFTP アカウントは不要だ。経営者であっても、サーバーの操作が業務に含まれないならば管理者アクセスを持つべきではない。権限を持つアカウントの数を最小限に減らし、それぞれの権限レベルも必要最低限に絞ることが、最も低コストで効果的な防御策となる。
上記のように、権限を必要最低限に絞り込むだけで、攻撃者が悪用できる認証情報の総数は大幅に減る。
よくある質問
バックドアはどこに隠れていることが多いのか
wp-content 内のプラグインやテーマだけではなく、ドキュメントルート直下や、画像アップロードディレクトリ、キャッシュフォルダなどに偽装されるケースが多い。フォントファイル（.woff や .ttf）に偽装した悪意ある PHP コードが埋め込まれている事例もある。スキャンは必ずサイトのルート全体を対象にする必要がある。
データベースにもバックドアは残るのか
残る。管理画面のユーザー一覧に表示されない管理者アカウントや、プラグイン一覧から隠蔽された悪意あるプラグインのエントリがデータベースに直接書き込まれていることがある。ファイルの掃除だけでなく、データベースの直接確認も必須だ。
無料のセキュリティプラグインだけで復旧できるのか
セキュリティプラグインは感染の検知や予防には有効だが、すでに深く侵入されたサイトの完全な復旧を保証するものではない。特にホスティングレベルの認証情報が漏洩している場合、プラグインのスキャンでは検出できない経路から再侵入される。認証情報のローテーションと継続的なスキャンの組み合わせが不可欠になる。
復旧後、いつまで監視を続ければよいのか
少なくとも2週間は毎日のバックアップとスキャンを継続するのが現実的な目安だ。攻撃者が盗んだ認証情報をしばらく寝かせてから使うケースもあるため、数日間問題がなかったというだけで監視をやめてはいけない。2週間以上経過し、その間の全スキャンで異常がなければ、監視頻度を週に数回へ徐々に落としてもよい。
WP CLI を使わずに復旧作業は可能か
可能だが、手作業でのファイルの確認やデータベースの直接操作が必要になるため、作業時間と見落としのリスクが増加する。WP CLI に抵抗がある場合は、信頼できるエンジニアに依頼する方が安全だ。サーバー会社によっては、マルウェアスキャンと駆除の有償サービスを提供しているところもある。
この記事のポイント
- ハッキングの侵入経路はプラグインやテーマの脆弱性、および漏洩した認証情報が大半を占める
- バックドアはファイルとデータベースの両方に潜伏し、直近のバックアップも汚染されている前提で作業する
- 復旧にはファイル削除と同時に、WordPress、ホスティング、作業端末の三層で認証情報のローテーションが必須
- アクセス権限は「信頼」ではなく「必要性」で付与し、不要なアカウントは即座に削除する
- 一度の掃除で完了とせず、数週間の継続監視と複数回のスキャンで再感染の有無を確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Cloud Runのマルチリージョン高可用性が強化、障害検知と自動復旧が数秒単位に
発表の概要
Google Cloudは2026年7月20日、Cloud Runにおけるマルチリージョン高可用性の機能強化を発表した。ミッションクリティカルなアプリケーションのダウンタイムは、企業の収益や評判に直結する問題だ。これに対処するため、Cloud Runは単一コマンドで複数リージョンに同一サービスを展開できる設計をとってきたが、今回のアップデートで障害検知と自動復旧の精度が大幅に向上している。
新たに導入された機能は「Readiness Probe」と「Service Health」の2つだ。インスタンスレベルの死活監視とリージョンレベルの健全性評価を組み合わせることで、リージョン障害が発生した際のトラフィック迂回が数秒単位で自動化される。
マルチリージョン高可用性を支える2つの新機能
Readiness Probeの役割は「個々のコンテナが外部リクエストを受け付けられる状態か」を確認することだ。この結果はCloud Runコンソールからもリージョン別に確認でき、どのリージョンでインスタンスが縮退しているかが一目で分かる。
Service Healthはこのプローブ結果をリージョン単位で集約するレイヤーにあたる。複数のヘルスチェック結果を「そのリージョンが正常に稼働しているかどうか」というひとつの評価に落とし込み、グローバルロードバランサがこの評価に基づいてルーティングを切り替える。この仕組みにより、障害発生時の手動オペレーションが原則不要になる。
パブリックとプライベートで異なる自動フェイルオーバーの経路
自動フェイルオーバーを実現するには、トラフィックが流入してくるネットワーク層によってロードバランサの種類を選択する必要がある。Cloud Runは外部向けと内部向けで最適なバランサ構成を用意している。
この構成の利点は、どちらのパターンでもロードバランサ側が自動でService Healthを参照し、異常リージョンをルーティング対象から外してくれる点にある。手動でのDNS切り替えや手作業によるトラフィック操作が不要になるため、復旧までの時間が大幅に短縮される。
設計段階で押さえるべき3つのポイント
Service Healthの活用を前提にマルチリージョン構成を設計する際、見落としやすい検討項目が3つある。いずれも高可用性に直結するため、初期段階で整理しておくことが望ましい。
単一障害点をなくすには、インフラ層だけでなくアプリケーション自体のステートレス設計が前提になる。データ層を別途冗長化し、ロードバランサの背後で自由にインスタンスを入れ替えられる状態を作っておくことが、Cloud Runのマルチリージョン構成を最大限活かす秘訣だ。
利用開始とコスト
Cloud Runのマルチリージョン高可用性に関する一連の機能は、すでに全リージョンで利用可能だ。Service Healthの機能そのものに追加料金は発生しない。Readiness Probeの実行に伴う標準的なCPU・メモリ消費のみが課金対象となる。
導入にあたっては、既存のCloud RunサービスにReadiness Probeを設定し、Service Healthを有効にしたうえで適切なロードバランサに接続するだけでよい。公式ドキュメントにチュートリアルが用意されており、少ないステップでマルチリージョン高可用性の基盤を整えられる。
この記事のポイント
- Readiness Probeがコンテナ単位の死活監視を行い、Service Healthがリージョン単位の健全性を可視化する
- Serverless NEGを通じてグローバルロードバランサに健全性が通知され、障害リージョンを数秒で自動迂回する
- パブリック向けは外部ALB、VPC内向けは内部ALBを選択すれば、どちらも自動フェイルオーバーに対応可能
- DB層を含めた全レイヤーでの冗長化と、データレプリケーションの方針決定が設計の鍵を握る
- 機能追加に伴う追加コストはなく、通常のリソース消費のみで全リージョンですぐに利用を開始できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
grüumがShopifyとMagentoを評価しWooCommerceを選んだ理由
イギリス発のスキンケアブランド「grüum（グルーム）」は、月間8万件の注文を1人のフルタイム開発者で処理する。2023年、彼らは成長に伴い「WooCommerceでこのまま進むべきか」を再検討した。Shopify PlusとMagento（Adobe Commerce）を4か月かけて評価した結果、grüumはWooCommerceに残る決断を下した。
その背景には、複雑な商品構成を維持するための柔軟性、サブスクリプション収益に比例する手数料の回避、そして顧客データの完全な所有権があった。本記事では、月間8万件規模のEC事業者が下したプラットフォーム選定の判断基準を具体的に解説する。
grüumのビジネスモデルと商品構成の複雑さ
grüumは2016年、英国とオランダで活動する4人の同僚によって設立された。当初は男性向けスキンケアとシェービング製品を中心に約10商品でスタートしたが、現在では年齢や性別を問わず使えるスキンケア、ヘアケア、ボディケア、シェービング製品を展開する。売れ筋はシャンプーバーで、累計数百万個を販売している。
製造は英ストックポートの自社工場で一貫して行い、化粧品科学者も社内に抱える。段ボール包装の徹底、水を使わない製剤、天然成分の使用など、サステナビリティを製品開発の中心に据えている点が特徴だ。
300SKUを支える特殊なバンドル構造
grüumは約300SKUの商品を扱い、単品購入、定期購入（サブスクリプション）、そして独自の組み合わせが可能なバンドル販売を提供している。共同創業者のBethanie Sleigh氏は「私たちは製品の設定方法に多くの独自の仕組みを持っている」と語る。彼らの商品バンドルは「内容物、価格設定、在庫管理」を1つの設定単位として扱う必要がある。
具体的には、顧客は石鹸セットを購入した上で別の製品を追加したり、個別の製品を定期購入に切り替えて割引を受けたりできる。このような複雑な商品構成は、標準的なECプラットフォームの枠組みでは再現が難しい。
オープンソースであるWooCommerceは、条件付きロジックを必要とするバンドル機能があれば、拡張機能を導入するか開発者が独自に作成できる。ほとんどのEC事業者には不要な機能でも、特殊なカタログ構造を持つブランドにとっては事業形態を変えずに販売を継続できることを意味する。
Shopify Plusがgrüumのビジネスに合わなかった理由
grüumが最初に評価したShopify Plusは、ホスティングやセキュリティをプラットフォーム側で管理するSaaS型ECの代表格だ。しかし、grüumの複雑な商品構成を前にして、Shopify Plusではビジネス側をプラットフォームに合わせる必要があった。
プラットフォームに事業を合わせるのか、事業にプラットフォームを合わせるのか
共同創業者のSimon Leonard氏は「Shopify Plusに移行するなら、私たちのビジネスをプラットフォームに合わせて変えなければならなかった」と振り返る。WooCommerce Blogの記事によれば、grüumのバンドル構造（内容物、価格設定、在庫管理を1つの設定単位として扱う）はShopify Plusではネイティブにサポートされていなかった。
この制約は、EC事業者にとって重要な分岐点を浮き彫りにする。プラットフォームのデフォルト機能から外れた運用をしている場合、SaaS型では「ビジネスを変える」か「高額なカスタム開発に投資する」かの二択になりがちだ。WooCommerceはオープンソースであるため、プラットフォームを事業に合わせて拡張できる。Leonard氏は「私たちはWooCommerceを自分たちのビジネスに合わせて機能させることができる。原則を変える必要はない」と結論づけた。
サブスクリプション収益に比例する手数料の重み
grüumにとってサブスクリプション（定期購入）は重要な収益源だ。全収益の10%を占め、平均継続期間は30か月に達する。この定着率の高さゆえに、サブスクリプションのインフラコストは事業の収益性を大きく左右する。
Shopifyはサブスクリプション収益に対して売上の一定割合を手数料として課金する。Leonard氏が試算したところ、サブスクリプション経由で100万ポンド（約1.9億円）から1,000万ポンド（約19億円）の売上がある場合、年間10万ポンド（約1,900万円）規模の手数料が発生する計算になる。
一方、WooCommerce Subscriptionsは定額制の年間ライセンス料で提供される。grüumの規模では、Shopifyの従量課金モデルと比較して大幅なコスト削減につながる。これは「成長すればするほど手数料が増える」モデルと「成長しても固定費で済む」モデルの構造的な違いだ。
この料金体系の違いは、月間8万件の注文を処理するEC事業者にとって年間数百万円規模のコスト差を生む。WooCommerce Blogの記事でも、Leonard氏が「サブスクリプションで100万ポンドや1,000万ポンドの売上があると、すぐに年間10万ポンドの出費になる」と試算したことが紹介されている。
Magento（Adobe Commerce）の運用負荷とコスト構造
grüumが次に評価したMagento（現在のAdobe Commerce）は、エンタープライズ向けの高度なカスタマイズ性を持つオープンソースプラットフォームだ。Shopify Plusとは異なり、Magentoは拡張性の面ではgrüumの要件を満たす可能性があった。
専任の技術チームが不可欠な運用現実
しかし、Magentoの運用には相応の技術リソースが必要になる。サーバー管理、パフォーマンスチューニング、セキュリティパッチ適用、バージョンアップ対応などを継続的に行うには専任の技術スタッフが欠かせない。Leonard氏は「ウェブサイトを運営するために20人のチームを雇うつもりはなかった」と語っている。
grüumの開発チームはフルタイム1人とパートタイムのQAテスター1人という最小構成で運営されている。Magentoの運用に必要なリソースは、この体制では経済的に成立しなかった。拡張性の高さと引き換えに、運用負荷とインフラコストが大きく跳ね上がる点が決定的なマイナス要因となった。
これは中規模EC事業者にとって重要な示唆だ。機能の豊富さや拡張性だけでプラットフォームを選ぶと、運用フェーズで想定外のコストが発生する。自社の技術リソースと運用体制を正確に見積もった上で判断する必要がある。
この比較から見えるのは、ECプラットフォーム選定において「機能の多さ」よりも「自社の運用体制に合うか」が重要だということだ。grüumはMagentoの拡張性を評価しつつも、1人体制で回せる軽量な運用を優先した。
1人の開発者で月間8万件を処理できる運用設計
grüumのWebサイトは、フルタイム開発者1人とパートタイムのQAテスター1人で運用されている。小規模なコンテンツチームが商品登録、ページ作成、日々のコンテンツ更新を担当し、開発者の手を借りることはほとんどない。
非エンジニアが自律的に運営できるツール選定
コンテンツチームはページ作成にGutenberg（WordPressのブロックエディタ）、ナビゲーション管理にMax Mega Menu、SEO対策にYoast SEOを使用している。商品リスティング、プロモーション、季節ごとの更新はすべて開発者の介在なしで完了する。
この分業が成立するのは、WordPressエコシステムに成熟したノーコードツールが豊富に存在するからだ。grüumの開発者は、ルーチン作業ではなく顧客体験の改善や新機能の開発に集中できる。WooCommerce Blogの記事によれば、CTOの試算では「以前なら1年かかっていたタスクがWooCommerceなら1か月で完了する」という。開発速度の差はそのままコスト削減と市場投入の迅速化につながる。
決済基盤としてのWooPayments
決済についても、grüumはWooCommerceネイティブのWooPaymentsを選択した。外部の決済サービスを別途契約するのではなく、WooCommerceに統合された決済基盤を使うことで管理の一元化と手数料の最適化を図っている。プラットフォームと決済が分離していると、売上データの突合や手数料計算が複雑化するが、統合されていれば管理負荷が大幅に下がる。
この構成図からわかるように、grüumの運営は「開発者がルーチン作業から解放されている」点が最大の強みだ。コンテンツチームが自律的に動けるツールを選び、開発者は成長のための改善に専念する。この分業設計が1人体制での月間8万件処理を可能にしている。
データ所有権がもたらす事業の独立性
grüumがWooCommerceに残る決断をした理由の最後の1つが、データ所有権だ。SaaS型ECプラットフォームでは、顧客データや購買履歴はプラットフォーム側のデータベースに保存され、事業者が自由にアクセスできるとは限らない。移行時にはデータのエクスポートに制限があったり、追加費用が発生したりするケースもある。
30か月の顧客関係を自社で保有する意味
grüumのサブスクリプション顧客の平均継続期間は30か月だ。この間に蓄積された購買履歴、好み、購買パターンは、マーケティング戦略の基盤となる重要な資産である。Leonard氏はWooCommerce Blogの記事で「データは私たちのものだ。他のサブスクリプションプラットフォームとは大きく異なる。顧客をサードパーティに渡すのではなく、自分たちで管理できる」と述べている。
オープンソースのWooCommerceでは、データベースは事業者のサーバー上に存在する。仮に将来プラットフォームを移行する場合でも、データを完全な形でエクスポートできる。これはSaaS型プラットフォームにはない構造的な優位性だ。特にサブスクリプションモデルで長期的な顧客関係を構築しているEC事業者にとって、データアクセスの制限は重大な事業リスクになる。
データ所有権の問題は、短期的なコスト比較では見落とされがちだ。しかし、サブスクリプション事業のように顧客との長期関係が収益の柱となるビジネスモデルでは、データの可搬性とアクセス権が戦略的な価値を持つ。grüumの判断は、この点を明確に意識したものと言える。
この記事のポイント
- grüumは月間8万件の注文を1人の開発者で処理する中規模EC事業者であり、Shopify PlusとMagentoを評価した結果WooCommerceに残る決断を下した
- 複雑な商品バンドル（内容物、価格設定、在庫管理の一元設定）はShopify Plusではネイティブにサポートされず、ビジネス側をプラットフォームに合わせる必要があった
- サブスクリプション収益に対する従量課金（Shopify）と定額制（WooCommerce）の差は、年商1,000万ポンド規模で年間約10万ポンドのコスト差を生む
- Magentoは拡張性は高いが、運用に専任の技術チームが必要で、grüumの1人体制では経済的に成立しなかった
- オープンソースのWooCommerceはデータベースを事業者が完全に所有でき、顧客データの可搬性とアクセス権がSaaS型よりも優位
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google NotebookLMがGemini Notebookに改称、AIスクレイピング対策の緊急対応
Googleが研究支援ツールNotebookLMをGemini Notebookに改称した。実体は同じだが、このタイミングでユーザーエージェントの表記が「Google-NotebookLM」から「Google-GeminiNotebook」に変更される。旧ユーザーエージェントは2026年8月をもって廃止されるため、サイト運営者は数週間のうちにスクレイピング対策の見直しを迫られている。
今回の変更は単なる名称の刷新にとどまらず、AIによる自動コンテンツ収集と再利用のリスクを改めて浮き彫りにする。本記事では、Gemini Notebookのスクレイピング機能の実態、robots.txtを無視するユーザートリガー型フェッチャーの仕組み、そして具体的なブロック手法を簡潔にまとめる。
NotebookLMがGemini Notebookに改称、機能は変わらず
名前変更の背景と影響
2026年7月18日、Googleはユーザートリガー型フェッチャーのドキュメントを更新し、NotebookLMをGemini Notebookに置き換えた。ブランド統合の一環であり、既存のNotebookLMユーザーにとって使い勝手に違いは生じない。
しかし、サイト運営者にとって重大なのは、旧ユーザーエージェント「Google-NotebookLM」が2026年8月で無効になる点だ。ファイアウォールや.htaccessにこの文字列を直書きしている場合、猶予期間内に新しいユーザーエージェントへ切り替えなければ、ブロックが機能しなくなる。
Gemini Notebookの主な機能
Gemini Notebookは、ユーザーが提供した文書やURLを「グランドトゥルース（信頼できる基盤情報）」として扱い、AIが調査や学習を支援するマルチモーダルツールだ。YouTubeの動画や音声ファイルを取り込んで分析することも、逆にアップロードされた資料を音声ポッドキャストや動画解説に変換することもできる。
この「資料をもとに新しいコンテンツを自動生成する」という特徴が、後述するスクレイピング問題の根本にある。生成された音声や動画がオンラインで公開されれば、元の記事と直接競合する可能性があるからだ。
Gemini Notebookが引き起こすスクレイピング問題
Discover Sourcesによる自動スクレイピング
Gemini Notebookの「Discover Sources」機能は、ユーザーが設定したクエリやテーマに沿って最大10件のオンライン記事を自動で収集し、AI要約を生成する。問題は、サイト所有者の許可を一切取らずにクローリングが行われ、参照元へのリンクも一切発生しない点だ。
従来の検索エンジンであれば、クローラーが収集した情報は検索結果としてユーザーをサイトへ誘導する。しかしGemini Notebookの要約はクローズドな環境で完結し、トラフィックの恩恵は元サイトに還元されない。SEOの観点からは、コンテンツが無断で「搾取」される構造といえる。
音声・動画コンテンツの自動生成と競合
さらに、アップロードした資料からポッドキャストや動画解説を生成できる点も看過できない。仮に自社サイトの記事が材料に使われ、第三者が公開すれば、同一テーマでオリジナルと競合する二次コンテンツが無数に生まれる危険がある。
Googleのドキュメント上、これらは「ユーザー調査のための機能」と位置づけられているが、実質的には許可なきスクレイピングとリパーパス（再利用）を自動化する仕組みにほかならない。コンテンツを資産とするウェブサイト運営者にとって、対策は急務だ。
緊急対応すべきブロック手法
ユーザートリガー型フェッチャーとは
Gemini Notebookのクローラーは「ユーザートリガー型フェッチャー」に分類される。これは、ユーザーが明示的に指示（URL貼り付けやDiscover Sourcesの実行）をトリガーとして起動するため、robots.txtの指示に従わない。robots.txtはあくまで紳士協定であり、一般的なクローラーは自発的に従うが、ユーザートリガー型には適用されないのだ。
ただし、robots.txtが効かないからといって手立てがないわけではない。サーバー側でHTTPリクエストのユーザーエージェント文字列を検査し、該当するアクセスを拒否することは可能である。
.htaccessによる具体的なブロック例
多くのレンタルサーバーで使えるApache環境であれば、.htaccessに以下のルールを追記するだけでGemini Notebookのアクセスを遮断できる。
RewriteEngine On
# Gemini Notebookのユーザーエージェントをブロック
RewriteCond %{HTTP_USER_AGENT} Google-GeminiNotebook [NC]
RewriteRule ^ - [F,L]この設定により、該当のユーザーエージェントを含むすべてのリクエストに対して「403 Forbidden」が返される。Nginxを利用している場合は、if ($http_user_agent ~* "Google-GeminiNotebook") { return 403; } のような記述で同様の制御が可能だ。
重要なのは、新旧両方のユーザーエージェントをカバーするか、あるいは直ちに新UAのみに移行することである。2026年8月以降、旧UAはGoogle側で廃止されるが、それまでにサイト側のルールを更新しておかなければ、一時的にブロックがすり抜けるリスクが生じる。
旧ユーザーエージェントの猶予期間と注意点
Googleはドキュメント内で、旧ユーザーエージェント「Google-NotebookLM」を2026年8月までサポートすると明記している。ハードコードしているサイト運営者は、この期間内に新しい文字列へ切り替える必要がある。
なお、合わせて「Project Mariner」に関する記述がドキュメントから完全に削除された。同プロジェクトは2026年5月に終了しており、混乱を避ける意味でも、ユーザーエージェント周辺の情報は最新版を参照すべきである。
この記事のポイント
- NotebookLMはGemini Notebookに改称され、ユーザーエージェントが変更された
- Discover Sources機能が許可なく記事を収集し、AI要約や音声コンテンツを生成する
- ユーザートリガー型フェッチャーはrobots.txtを無視するが、ファイアウォールや.htaccessでブロック可能
- 旧UA「Google-NotebookLM」は2026年8月に廃止、既存のルールを直ちに更新する必要がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験