タグアーカイブ REST API

WordPressをサブフォルダにインストールするとREST APIが404になる原因と直し方

WordPressをサブフォルダにインストールしている環境で、REST APIのエンドポイントが404エラーを返す場合は、プラグインがサブフォルダを考慮せずにAPIのURLを生成しているバグが原因だ。該当プラグインを最新版に更新するか、パーマリンク設定のリフレッシュで解決する。

なぜサブフォルダ環境でプラグインのAPIが404になるのか

なぜサブフォルダ環境でプラグインのAPIが404になるのか

WordPressをドキュメントルート直下ではなく/blog/siteのようなサブフォルダにインストールした場合、REST APIのベースURLはhttps://example.com/subfolder/wp-json/となる必要がある。ところが一部のプラグインは、内部でAPIのURLを組み立てる際にこのサブフォルダを考慮しておらず、https://example.com/wp-json/...のようにルート直下を指してしまう。その結果、実在しないパスへのリクエストとなり404が返る。

今回のケースでは、プラグインが独自に追加したエンドポイント/profeedwp/v1/linkedin/company-posts/smartに対して、サブフォルダを含まない不完全なURLでリクエストを発行していた。同様の問題は、テーマや他のプラグインがrest_url()関数を正しく使わずにハードコードしたパスを参照している場合にも起こる。

解決手順

解決手順

まず簡単かつ即効性のある方法として、問題のプラグインを最新版へ更新する。次に、WordPressのパーマリンク設定をリセットし、REST APIのルートURLが正しく再構築されるか確認する。これで直らない場合は、手動でrest_url()が返す値を検証し、他のプラグインとの競合を調べる。

STEP 1 問題のプラグインを最新版に更新する
STEP 2 パーマリンク設定をリセットして API ルートを再構築する
STEP 3 rest_url() の戻り値を検証し、サブフォルダが含まれるか確認する
STEP 4 全プラグインを無効化して競合を切り分ける

プラグインを最新版に更新する

本件ではバージョン1.6.10で修正が行われている。管理画面の「プラグイン」→「インストール済みプラグイン」から対象プラグインを確認し、更新が表示されていれば適用する。更新が出ていない場合は、一度プラグインを削除して再インストールするか、開発元の公式ページから修正版がリリースされていないか確認する。

パーマリンク設定をリセットする

プラグインの更新で直らなかった場合、パーマリンク構造の再保存でWordPress内部のルーティングをリフレッシュできる。「設定」→「パーマリンク」を開き、現在選択されている設定をそのままの状態で「変更を保存」をクリックする。これにより.htaccessの再生成と、REST APIのルート定義が再構築される。サブフォルダ環境では特に、リライトルールが正しくサブフォルダをプレフィックスとして含む必要があるため、この一手順で解決するケースが多い。

rest_url() の戻り値を検証する

根本原因がプラグイン側のURL組み立てにあるかどうかを切り分けるには、WordPressが正しいREST APIのルートURLを返しているかを確認する。テーマのfunctions.phpなどに次のようなテストコードを一時的に追加する。

add_action('wp_footer', function() {
    echo '<!-- REST URL: ' . esc_url(rest_url()) . ' -->';
});

サイトのフッター部分のHTMLソースに出力されたURLがhttps://example.com/subfolder/wp-json/の形式になっていれば、WordPress本体の認識は正しい。もし/subfolderが欠落している場合は、wp-config.phpWP_HOMEWP_SITEURLが正しくサブフォルダを含んだ値で定義されているか確認する。

全プラグインを無効化して競合を切り分ける

それでも404が解消しない場合、別のプラグインがREST APIのルーティングに干渉している可能性がある。すべてのプラグインを一括で無効化し、問題のエンドポイントにアクセスして200番台のレスポンスが返るかテストする。正常動作が確認できたら、プラグインを1つずつ有効化して原因のプラグインを特定する。キャッシュ系プラグインやセキュリティプラグインは、REST APIへのリクエストをブロックしたり、URLを書き換えたりする設定項目を持つことがあるため、該当するプラグインの設定もあわせて確認する。

よくある質問

サブフォルダにインストールする際にwp-config.phpで注意すべき点は?

WP_HOMEWP_SITEURLの定数をhttps://example.com/subfolderのようにサブフォルダを含めて明示的に定義しておくと、サイトURLの誤認識を防げる。wp-config.phpに記述しなければならないわけではないが、マルチサーバー構成やリバースプロキシの背後で運用する場合は特に有効だ。

REST APIの404エラーはどのようにデバッグすればいいか?

ブラウザのデベロッパーツールのネットワークタブで、実際に送信されたリクエストURLを確認する。サブフォルダが欠落したURLでリクエストが発生している場合は、呼び出し元のJavaScriptファイルやPHPコードでURLの組み立て方をチェックする。rest_url()を使わずにハードコードされたパスが原因であることが多い。

プラグインを更新しても問題が再発する場合は?

修正パッチが適用されたバージョンでも、キャッシュの残存やデータベースに保存された古い設定値が原因で再発することがある。プラグインを完全に削除したあと、wp_optionsテーブルに残っている該当プラグインのオプションを手動で削除し、最新版を再インストールすると改善する場合がある。

サブフォルダ環境でなくてもAPIが404になる原因は?

パーマリンク設定が「基本」になっているとREST APIが動作しない。また、セキュリティプラグインが/wp-json/へのアクセスを制限しているケースもある。.htaccessのリライトルールが破損している場合も404になるため、パーマリンク設定の再保存でリフレッシュするのが初手として有効だ。

この記事のポイント

  • サブフォルダ環境でプラグインのAPIが404になるのは、URLにサブフォルダが含まれない不完全なパスが原因
  • 問題のプラグインを最新版に更新し、パーマリンク設定を再保存するのが解決の基本手順
  • rest_url() の戻り値とwp-config.phpの設定を確認し、WordPress本体のURL認識が正しいか検証する
  • 全プラグインの無効化で競合を切り分け、キャッシュやセキュリティ系プラグインの干渉を疑う
WP-CLIとREST APIとAbilities API、WordPressインターフェースの選び方

WP-CLIとREST APIとAbilities API、WordPressインターフェースの選び方

3つのインターフェースの全体像

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エージェントが安全に操作を行えるように設計
Abilities API(AIエージェント層)
AIエージェントが安全にWordPressを操作するためのケイパビリティ定義
「何ができるか」を記述し、許可された操作のみを公開する
REST API(HTTP層)
ブラウザ、アプリ、外部サービスからのHTTP通信
「どんなデータがあるか」を公開し、認証付きで読み書き可能に
WP-CLI(コマンドライン層)
サーバー上での直接PHP実行、SSH経由の一括操作
HTTP往復なし、認証トークン不要、最高速での実行が可能
■ 上位層ほど「自律性」が高く「説明的」 ■ 下位層ほど「高速」で「直接操作」

3つのインターフェースは、下位ほど呼び出し元がサイトに近く、信頼度も高い。上位になるほど、呼び出し元は自律的で遠隔地に位置する。この構造を理解すれば、「どれを使うべきか」の判断はシンプルになる。

WP-CLI:サーバー上のコマンドライン

WP-CLI:サーバー上のコマンドライン

WP-CLIはWordPressのインストール環境に対して直接PHPを実行する。コマンド例としては wp post createwp plugin updatewp search-replacewp db export などがある。実行にはサーバーへのシェルアクセス(SSH)が前提だが、その分HTTPの往復も認証トークンの管理も不要になる。

WP-CLIが最も威力を発揮するのは、サイトを完全に制御できる状況だ。1000件の投稿を移行する、データベース全体でドメインを置換する、定期メンテナンスをスクリプト化する、あるいはデプロイの自動化など、スピードが求められる一括操作では他の追随を許さない。

WP-CLIが適さないケース
ブラウザやモバイルアプリからのアクセス、リモートサービスとの連携には使えない
WP-CLIが最も輝く場面
一括移行、データベース操作、定期メンテナンスの自動化、デプロイスクリプト

WP-CLIはシェルアクセスが前提のため、ブラウザやモバイルアプリ、外部サービスがサイトと通信する手段にはなりえない。しかし開発者がサイト全体を制御できる状況では、WP-CLIは圧倒的な速度と柔軟性を提供する。ターミナルからすべてを操作するワークフローが浸透している開発現場も多く、管理画面(wp-admin)をほとんど開かない運用も可能だ。

REST API:HTTP越しのWordPress

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エージェントにはハードルが高い

REST APIには重要な限界がある。公開するのは「データの構造」であり、「そのデータで何をしたいのか」という操作の意図までは記述しない。どのエンドポイントが存在し、どうリクエストを組み立てるべきかは、呼び出し元が自ら理解する必要がある。人間の開発者であれば問題ないが、AIエージェントにとっては推論すべき情報が多すぎるという課題が残る。

Abilities 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 ],
    ] );
} );
REST API
データの構造を公開する
「どんなリソースがあるか」に答える
Abilities API
操作の意図と許可を公開する
「何ができるか」「誰が許可されているか」に答える
アビリティは「これが実行可能な操作であり、必要な入力と許可条件はこれだ」という契約をAIエージェントに提示する

meta.show_in_rest をtrueに設定すると、そのアビリティは wp-json/wp-abilities/v1/abilities で公開され、クライアントが検出できるようになる。JavaScript側では @wordpress/abilities パッケージを介して利用する。

Abilities APIの最大の価値は、エージェントが安全に行動するために必要な「契約」を提供することだ。操作の定義、必要な入力形式、実行許可の条件が明示されるため、AIエージェントがサイトを壊すリスクを最小限に抑えられる。複数のエージェントが共通の語彙で協調動作するマルチエージェント構成でも、Abilities APIが基盤になりつつある。

3つのインターフェースの積み重なり方

3つのインターフェースの積み重なり方

3つのインターフェースは互いに積み重なる関係にある。Abilities APIは多くの場合REST APIの上に構築され、REST APIはWP-CLIが直接駆動するPHPの上で動作する。すべての基盤にあるのは、同じWordPressコア、同じデータベース、同じ関数群だ。

したがって問うべきは「どれが最善か」ではない。「呼び出し元がサイトからどれだけ離れているか」「操作の意図をどこまで明示する必要があるか」という視点で選択することが本質になる。呼び出し元が近く信頼できるほど下位層を、自律的で遠隔にあるほど上位層を使う。

距離:最短 サーバー上(SSH) WP-CLI 一括操作・最高速
距離:中程度 HTTP越し(リモート) REST API データの読み書き
距離:最長 AIエージェント(自律的) Abilities API 安全な操作定義

上位層になるほど「記述性」と「安全性」が重視され、下位層ほど「速度」と「直接制御」に優れる。これらは設計上、相補的な関係にあり、実際のプロジェクトではすべてを併用するのが理想的な構成だ。

各インターフェースの使い分け方

各インターフェースの使い分け方

日常的なタスクにおける選択指針を整理する。

  • 自分が制御するサイトに対して、一括かつ高速に操作したい → WP-CLI。移行、デプロイ、定期ジョブ、データベース操作が該当する
  • ブラウザ、アプリ、外部サービスがコンテンツを読み書きする必要がある → REST API。ヘッドレスフロントエンド、モバイルアプリ、外部連携が該当する
  • AIエージェントにサイトを壊さず操作させたい → Abilities API。許可したい操作をスキーマと権限付きで登録し、エージェントに発見させる
STEP 1 呼び出し元の「距離」を確認する(サーバー内か、リモートか、自律エージェントか)
STEP 2 操作に必要な「明示性」を判断する(データ構造だけで足りるか、操作意図の記述が必要か)
STEP 3 最適なレイヤーを選ぶ(多くの場合、複数レイヤーの併用が正解)

実際のプロジェクトでは、この3つを排他的に使うことはまれだ。むしろそれぞれの得意領域を活かして組み合わせるのが、効率的なWordPress運用の鍵になる。

3つを組み合わせた実践的な構成

3つを組み合わせた実践的な構成

WP Mayorの記事では、実際に3つのインターフェースを併用している構成例が紹介されている。まず、公開運用と日常的な運用作業はSSH経由のWP-CLIで実行される。新規投稿、メディアのインポート、プラグイン更新、キャッシュクリアといった操作をターミナルから完結させ、管理画面(wp-admin)をほとんど開かない運用が行われている。

フロントエンドはヘッドレス構成で、REST API越しにコンテンツを取得する。Astroで構築されたサイトが wp-json 経由でWordPressからデータを取得し、高速な静的ページとして配信する。訪問者はWordPressテーマに触れることなく、WordPressはバックエンドのエンジンとして機能し、REST APIがそのパイプ役を担う。

エージェント向けの機能はAbilities APIを通じて提供される。AIエージェントに限定的なタスクを任せたい場合、関連プラグインがその操作をアビリティとして登録する。権限チェックとスキーマを伴うため、シェルアクセスを丸ごと渡したり、大量の生エンドポイントをエージェントに解析させたりする必要がなくなる。

WP-CLI(運用層)
投稿・メディア・プラグイン管理をターミナルから一括実行。シェルアクセス可能なAIアシスタントも直接駆動できる
REST API(配信層)
ヘッドレスフロントエンドがコンテンツを取得。Astroが静的ページとして配信し、訪問者はWordPressテーマに触れない
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つを組み合わせ、各レイヤーの得意領域を活かすのが理想的な運用だ
Trustindexプラグインの脆弱性、認証なしでトークンが漏洩する問題と対策

Trustindexプラグインの脆弱性、認証なしでトークンが漏洩する問題と対策

Trustindexプラグインのトラブルシューティング用RESTエンドポイントが認証なしでアクセス可能になっていると、Instagram Graph APIのアクセストークンを含む全オプションが外部に漏洩する。HMAC署名のキーに公開情報を使っている設計上の欠陥が原因であり、修正パッチが配布されるまでの間はエンドポイント自体を遮断する応急処置が必要になる。

何が起きているのか 〜 脆弱性の全体像

何が起きているのか 〜 脆弱性の全体像

この問題は、Trustindexの「Instagram Feed」ウィジェットを設置したWordPressサイトで発生する。プラグインは管理画面のトラブルシューティング用に /wp-json/trustindex_feed_hook_instagram/troubleshooting というRESTエンドポイントを用意している。このエンドポイントに正しい署名付きリクエストを送ると、プラグインが保存している全オプション、つまりInstagramのアクセストークンや各種設定をJSON形式で返してしまう。

認証にはHMAC-SHA256による署名検証が使われているが、その署名用の秘密鍵(キー)がサイトごとに公開されている「パブリックID」になっている。このIDは、プラグインが生成するCDNのURL(https://cdn.trustindex.io/wp-feeds/XX/パブリックID/data.json)に含まれ、ページのソースコードやネットワークリクエストを覗けば誰でも取得できる。つまり署名の計算に必要な材料がすべて攻撃者の手に渡ってしまうため、認証がまったく機能していない状態だ。

影響は深刻だ。漏洩したInstagramアクセストークンを使えば、サイト運営者になりすましてInstagram Graph APIを呼び出し、プロフィール情報の取得やメディア投稿の操作が可能になる。トークンの有効期限が切れるか運営者が手動で失効させるまで、不正利用のリスクが続く。

自分のサイトが影響を受けるかどうかの確認方法

自分のサイトが影響を受けるかどうかの確認方法

まず、TrustindexプラグインをインストールしてInstagramフィードを表示しているサイトが対象だ。それ以外のフィード(FacebookやGoogleレビューなど)を使っているだけの場合は、今回のエンドポイントとは関係がない。確認手順は次の3ステップで行える。

STEP 1 ブラウザで自サイトの任意のページを開き、右クリック→「ページのソースを表示」を選択する。
STEP 2 Ctrl+Fで「cdn.trustindex.io」を検索し、URLの中にある英数字2文字+ハイフン+英数字のパブリックIDを見つける。
STEP 3 curlなどのツールでエンドポイントに署名付きリクエストを送り、レスポンスにトークンが含まれていないか調べる。

STEP 3の詳細は、UNIXのターミナルで以下のようなリクエストを投げる。HMACの計算にはパブリックIDと現在のUNIXタイムスタンプを使うため、スクリプトを組むか手動で計算する必要がある。

# PUBLIC_ID と TIMESTAMP は各自の値に置き換える
PUBLIC_ID="取得したパブリックID"
TIMESTAMP=$(date +%s)
SIGNATURE=$(echo -n "$TIMESTAMP" | openssl dgst -sha256 -hmac "$PUBLIC_ID" | awk '{print $2}')
curl -H "X-Signature: $SIGNATURE" -H "X-Timestamp: $TIMESTAMP" \
  "https://あなたのサイトドメイン/wp-json/trustindex_feed_hook_instagram/troubleshooting"

レスポンスに source.access_tokenaccess_token といった文字列が含まれていれば、情報が丸見えの状態だと判断できる。この確認はあくまで自己診断用であり、他者のサイトに対して行ってはならない。

修正パッチが配布されるまでに取るべき応急措置

修正パッチが配布されるまでに取るべき応急措置

プラグイン開発者から公式のアップデートが提供されるまでは、以下のいずれかの方法で該当エンドポイントへの外部アクセスを完全に遮断する。

修正前 誰でもエンドポイントにアクセス可能。トークンが平文で返る
修正後 外部からのアクセスを禁止。管理者のみ必要に応じて利用

.htaccessでエンドポイントをブロックする

サーバーがApacheを使っている場合、WordPressのインストールディレクトリにある.htaccessファイルに以下の記述を追加する。これにより、該当URLへのリクエストは403 Forbiddenで弾かれる。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-json/trustindex_feed_hook_instagram/troubleshooting - [F]
</IfModule>

functions.phpでREST APIアクセスを制限する

テーマのfunctions.php(子テーマ推奨)に下記のコードを追加すると、未ログインユーザーからの該当エンドポイントへのアクセスを拒否できる。管理画面にログインしているユーザーは引き続き利用できるため、サポートが必要になった際にも支障がない。

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) {
        return $result;
    }
    $current_route = $GLOBALS['wp']->query_vars['rest_route'] ?? '';
    if ( strpos( $current_route, '/trustindex_feed_hook_instagram/troubleshooting' ) !== false && ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_forbidden',
            'このエンドポイントへのアクセスにはログインが必要です。',
            array( 'status' => 403 )
        );
    }
    return $result;
} );

プラグインを一時停止する判断

Instagramフィードの表示が必須でないなら、脆弱性が修正されるまでプラグイン自体を無効化するのが最も確実だ。フィードが表示されなくなる影響が許容できるビジネスであれば、この選択肢も検討しよう。

すでにトークンが漏洩した可能性がある場合の対処

すでにトークンが漏洩した可能性がある場合の対処

アクセスログを精査して不審なリクエストがなかったか確認するのが先決だが、ログが十分に残っていないケースも多い。疑わしい場合は、以下の手順でトークンを強制的に無効化し、新しいトークンを再発行する。

STEP 1 Facebook開発者コンソールで該当アプリのInstagram Basic DisplayまたはInstagram Graph APIの設定を開く
STEP 2 既存のアクセストークンをすべて取り消し(Revoke)、新しいトークンを生成する
STEP 3 WordPress管理画面でTrustindexプラグインの設定画面を開き、新しいトークンを再入力する

特にInstagram Graph APIのアクセストークンは長期トークン(Long-Lived Token)で運用していることが多く、一度漏洩すると数カ月単位で悪用されるリスクがある。トークン失効後は、フィードが一時的に表示されなくなるが、再設定すればすぐに復旧する。

根本的な原因と再発防止の考え方

根本的な原因と再発防止の考え方

今回の脆弱性の本質は、認証用の秘密情報が公開前提の値になっている設計ミスにある。HMAC署名を使うこと自体は正しいが、秘密鍵が「誰でも見られるURLの一部」にある時点でセキュリティは成り立たない。

プラグイン開発者側が取るべき修正は、プラグイン有効化時にランダムなシークレットを wp_options テーブルに保存し、その値を署名キーに使う方式へ変更することだ。さらに、トラブルシューティングという目的を考えれば、current_user_can('manage_options') で管理者権限を要求するだけでも十分な防御になる。このエンドポイントはあくまでサポートスタッフ向けであり、未認証ユーザーに開放する理由は一切ない。

サイト運営者としても、すべてのプラグインを無条件に信頼するのではなく、導入後に「どんなRESTエンドポイントが増えたか」「公開される情報はないか」をセキュリティプラグインや手動チェックで確認する習慣が身を守る。WordPressのサイトヘルス機能やQuery Monitorのようなツールを普段から使い、異常なAPIリクエストがないか注視しておくことが再発防止につながる。

よくある質問

プラグインのどのバージョンから修正されますか

2026年6月17日時点では、開発者は調査中と回答しており修正バージョンは未発表だ。Trustindexの公式チェンジログとWordPress管理画面の更新通知を定期的に確認し、セキュリティアップデートが配信され次第ただちに適用する必要がある。

応急処置としてプラグインを無効化すると、フィードはどうなりますか

プラグインを無効化すると、Instagramフィードは表示されなくなる。ただ、表示崩れが起こるだけでサイト全体がダウンするわけではない。トークン漏洩のリスクと天秤にかけて、ビジネス上の重要性が高い場合は上記の.htaccessやfunctions.phpによる遮断を選ぶほうが現実的だ。

Instagramのトークンを変えたあと、再度漏洩することはありますか

アプリやサーバー側の脆弱性が修正されていない限り、新しいトークンも同じエンドポイントから再び漏洩する可能性がある。必ず、アクセス制限の応急措置を先に施したうえでトークンを再発行する順序を守ってほしい。

FacebookやGoogleのフィードにも同じ問題はありますか

今回確認されたのは trustindex_feed_hook_instagram のエンドポイントのみだが、同じ認証設計を他のフィード用エンドポイントにも流用している可能性は否定できない。不安があれば、trustindex_feed_hook_facebooktrustindex_feed_hook_google といった類似のエンドポイントが存在しないか、REST APIのルート一覧で確認しておくと安心できる。

自分のサイトがすでに攻撃されたかどうか確かめる方法はありますか

サーバーのアクセスログに /wp-json/trustindex_feed_hook_instagram/troubleshooting へのリクエストが記録されていれば、それが正規のサポート用途か攻撃かを判別する必要がある。あわせて、Instagram Graph APIの使用状況をFacebook開発者コンソールの「アプリのインサイト」で確認し、見覚えのないAPIコールや異常なリクエスト数がないかを調査するのが確実だ。

この記事のポイント

  • Trustindexプラグインのトラブルシューティング用RESTエンドポイントが認証不備によりInstagramアクセストークンを露出させている
  • 原因はHMAC署名の秘密鍵として、誰でも取得できるパブリックIDを使用している設計ミス
  • 修正パッチが配布されるまでは、.htaccessかfunctions.phpでエンドポイントへの外部アクセスを遮断する
  • トークン漏洩が疑われる場合はInstagram側でトークンを即時失効させ再発行する
  • 常にプラグインのREST APIエンドポイントを定期的に監視し、不要な露出がないか確認する習慣が再発防止の鍵
AI EngineとJetpackが衝突してGeminiが使えない時の解決策

AI EngineとJetpackが衝突してGeminiが使えない時の解決策

AI Engine プラグインをバージョン 3.5.5 以降にアップデートすれば、この問題は即座に解決する。根本原因は Jetpack が REST API に追加する整数型 enum フィールドを、Google Gemini がツール定義で拒否していたことにある。AI Engine の開発者がこのスキーマ生成ロジックを修正し、文字列型以外の enum を自動除去するようになった。

どのようなエラーが発生するのか

どのようなエラーが発生するのか
エラー発生時 AI Engine が Gemini に送るツール定義に Jetpack の整数 enum が混入
修正後 AI Engine が文字列型以外の enum を自動除去してからツールリストを生成
エラー状態  修正後

Desktop Commander で AI Engine を MCP サーバーとして管理モードで接続し、AI モデルに Google Gemini を指定すると、次のようなエラーで通信が失敗する。

「GenerateContentRequest.tools[0].function_declarations[30].parameters.properties[jetpack_publicize_connections].items.properties[status].enum: only allowed for STRING type」という趣旨のエラーが返る。翻訳すると「enum は STRING 型にしか使えない」という厳格な制約に違反した形だ。

管理画面では具体的に「AI Engine が Gemini API からの応答に失敗しました」といった形で表示され、チャットが開始できないか、途中で止まる。管理モードでなければ発生しないエラーだ。

なぜ Jetpack と AI Engine が衝突するのか

なぜ Jetpack と AI Engine が衝突するのか

核心は Google Gemini API の「ツール定義」に対する極めて厳格なバリデーションにある。Gemini は利用可能な関数のパラメータをスキーマで受け取るが、enum(許容値の固定リスト)を使う場合、そのデータ型を必ず文字列にしなければならない。

一方 Jetpack は、WordPress の投稿作成や更新時に使われる REST API エンドポイントへ、ソーシャルメディア連携用のフィールドを動的に追加している。その中の jetpack_publicize_connections フィールドには status というパラメータがあり、Jetpack はこれを整数型の enum([0, 1])として定義している。

AI Engine が WordPress のスキーマ全体を走査して Gemini 向けのツールリストを組み立てる際、この整数型 enum をそのまま継承してしまう。その結果、Gemini API がリクエスト全体を「400 Bad Request」ではねつける流れだ。

読み取り専用モードならば投稿作成系のツールが含まれないため、このエラーは発生しない。管理モードで書き込み権限を付与する場合に限って表面化する。

AI Engine 3.5.5 以降へのアップデートで恒久修正する

AI Engine 3.5.5 以降へのアップデートで恒久修正する

AI Engine の開発者によって、バージョン 3.5.5 で根本的な修正が加えられた。ツールスキーマを作成する際、文字列型以外の enum 定義を自動的に除去する処理が追加されている。

STEP 1 WordPress 管理画面から AI Engine を最新版(3.5.5 以上)に更新する
STEP 2 更新後、新しいチャットを管理モードで開始する
STEP 3 Gemini が正常に応答すれば修正完了

スキーマキャッシュのバージョンも同時に引き上げられているため、更新後に手動でキャッシュをクリアする必要はない。自動的に再生成され、Jetpack の整数型 enum は除去された状態でツールリストが構築される。

どうしてもアップデートできない場合の手動修正

何らかの理由で AI Engine を最新版にできない場合、子テーマの functions.php または Code Snippets プラグインに以下のコードを追加し、Jetpack の整数型 enum フィールドを強制的に文字列型へ変換できる。

<?php
/**
 * Jetpack と AI Engine、Google Gemini の競合を修正する。
 * Jetpack の status enum フィールドを文字列型に変換する。
 */
add_action( 'wp_enqueue_scripts', 'enqueue_parent_styles' );
function enqueue_parent_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}

add_action( 'rest_api_init', 'fix_jetpack_enum_for_gemini', 9999 );
function fix_jetpack_enum_for_gemini() {
    global $wp_rest_additional_fields;

    if ( ! empty( $wp_rest_additional_fields ) ) {
        foreach ( $wp_rest_additional_fields as $post_type => $fields ) {
            if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections'] ) ) {
                if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status'] ) ) {
                    // 問題を起こす整数 enum を除去
                    unset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['enum'] );
                    // データ型を文字列に明示
                    $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['type'] = 'string';
                }
            }
        }
    }
}
?>

コード追加だけでは修正されないケースがある。AI Engine はツールリストをデータベースに強力にキャッシュしているため、キャッシュを強制的に再生成させる必要がある。

STEP 1 プラグイン一覧から Jetpack を一時的に無効化する
STEP 2 AI Engine で新しい管理モードチャットを開き、簡単な質問を送信する
STEP 3 Jetpack を再有効化する。以降 PHP フィルタがスキーマを清浄に保つ

Jetpack を無効化した状態でチャットを実行することで、AI Engine は Jetpack 関連フィールドのないスキーマを新規に作成する。Jetpack を再有効化した後は上記のフィルタが働き、問題の enum がスキーマに混入することはなくなる。

よくある質問

Jetpack を使っていなければこの問題は起こらないのか

Jetpack の jetpack_publicize_connections フィールドが原因であるため、Jetpack を導入していなければ発生しない。ただし、他のプラグインも整数型 enum を REST API に追加している場合は似たエラーが出る可能性がある。その場合も AI Engine 3.5.5 以降であれば同様に自動除去される。

読み取り専用モードではなぜ問題ないのか

読み取り専用モードでは、投稿の作成や更新といった書き込み系のツールが Gemini に送信されない。問題の jetpack_publicize_connections フィールドは投稿作成時に登場するため、ツールリストから除外される。管理モードだけが影響を受ける。

AI モデルが Gemini 以外でも同じエラーは出るか

このエラーは Gemini のツール定義バリデーションが特に厳格なために発生する。OpenAI の GPT シリーズなど、他の AI モデルでは整数型 enum を許容するものもあるが、根本原因はスキーマにあるため、どのモデルでも潜在的な問題になりうる。AI Engine 3.5.5 の修正で全モデルに対応できる。

AI Engine 3.5.5 にアップデートした後、スキーマキャッシュは本当に自動クリアされるのか

開発者によれば、スキーマキャッシュのバージョンナンバーが引き上げられているため、更新後の初回リクエスト時に自動的に再生成される。手動でキャッシュを削除する操作は不要。もし不安があれば、AI Engine の設定画面からキャッシュを手動クリアしても問題ない。

この記事のポイント

  • AI Engine 3.5.5 以降のアップデートで根本解決する
  • 原因は Jetpack の整数型 enum を Gemini が拒否するため
  • 読み取り専用モードでは書き込み系ツールが送信されず問題は出ない
  • 手動修正する場合は Jetpack 一時無効化によるキャッシュ再生成が必須
  • 修正後は文字列型以外の enum が自動除去され、あらゆる AI モデルで安定する
Elementorエディタが開かない時のREST API 403エラー解決法

Elementorエディタが開かない時のREST API 403エラー解決法

Elementorエディタが読み込まれずにフリーズし、REST APIが403禁止エラーを返す場合、根本原因は「プラグインコアファイルの破損」「WordPressのサブディレクトリ構成による認証不整合」「サーバーレベルのアクセス制限」のいずれか、または複合にある。FTPやファイルマネージャーから手動でElementorを再設置し、サイト設定の見直しとパーマリンク構造のリセットを実施すれば、大半のエラーは解消する。

なぜ Elementor エディタが開かず REST API が403エラーになるのか

なぜ Elementor エディタが開かず REST API が403エラーになるのか

プラグインコアファイルの破損が引き起こす連鎖不具合

Elementorが途中でアップデートに失敗したり、サーバー上でファイルが欠損したりすると、致命的なクラス読み込みエラーが発生する。代表的なものが「Uncaught Error: Class “Elementor\Controls_Stack” not found」だ。これはElementor本体の動作に必須のファイルが物理的に存在しないか、PHPの要求に対して不完全な状態で読み込まれていることを示す。管理画面からの再インストールではサーバーキャッシュや権限の影響で上書きに失敗するケースがあるため、手動での完全初期化が必要になる。

WordPressのサブディレクトリ構成が生む認証クッキーのズレ

WordPress本体を/wordpressに配置し、サイトアドレスだけをルートドメインに設置する構成は、REST APIの認証において深刻な不具合を引き起こす。ブラウザはWordPressのログインクッキーを物理的なインストールパスに対して発行するため、サイトURLと実際のパスが異なると、APIリクエストに必要なnonceや認証クッキーが正しく送信されず「rest_not_logged_in」が返る。Elementorエディタは内部的に多数のREST API通信を行っているため、この認証エラーが編集画面そのものを動作不能にする。

サーバー設定やセキュリティプラグインがAPIをブロックしている

ModSecurityやWAF(ウェブアプリケーションファイアウォール)、あるいは.htaccessに記述された独自ルールが、/wp-json/パスへのアクセスを機械的にブロックしている場合も403エラーが発生する。また、一部のセキュリティプラグインはREST APIのエンドポイントを厳格に制限する機能を備えており、無効化したと思っていてもキャッシュ層に設定が残って影響していることがある。

Before(エラー状態)
Fatal Error Class “Elementor\Controls_Stack” not found
403 Forbidden /wp-json/elementor/v1/site-navigation/recent-posts
要素: エディタ画面が白またはローディング停止。REST APIがログイン状態を認識せず全遮断。
After(解決状態)
200 OK 全プラグインファイルが完全に復元される
Auth OK REST APIがユーザー認証を正しく通過
要素: Elementorエディタが即座に起動し、ウィジェットの読み込みや保存が可能に。

エラーが発生している環境では、管理画面からの通常操作がほぼ通じない状態になっている。上のBefore/AfterのようにエディタとAPI認証を同時に復旧させるには、外部からのファイル操作とURL設定の修正が不可欠となる。

実際に環境を修復する4ステップの手順

実際に環境を修復する4ステップの手順
STEP 1 FTPからElementorを手動で再設置する
STEP 2 パーマリンクをリセットしキャッシュを削除する
STEP 3 wp-config.phpでサイト構成の不整合を補正する
STEP 4 .htaccessとサーバー側の認証ブロックを解除する

STEP 1 FTPからElementorを手動で再設置する

管理画面の「プラグイン」から削除するだけでは、不完全なファイルが残る危険がある。FTPソフト、またはサーバーのファイルマネージャーを開き、/wp-content/plugins/elementor/ディレクトリを直接削除する。Pro版を使用している場合は/wp-content/plugins/elementor-pro/も同様に削除する。削除後、Elementorの公式サイトから最新のzipファイルをダウンロードし、同じディレクトリにアップロードして展開することで、完全に健康なコアファイルが書き戻される。これで「Controls_Stack」を含むクラスファイルの欠損は物理的に解消される。

STEP 2 パーマリンクをリセットしキャッシュを削除する

管理画面の「設定」→「パーマリンク」にアクセスし、「変更を保存」を2回クリックするだけでもREST APIのルーティング情報が再生成される。これにより、サイトの内部URL構造が強制的にリセットされる。あわせて、導入しているキャッシュプラグインの全キャッシュ削除、およびサーバー側のVarnishやNginxキャッシュが有効な場合はそれらのパージも実行する。

STEP 3 wp-config.phpでサイト構成の不整合を補正する

WordPress本体がサブディレクトリにある環境では、認証クッキーのパス指定を明示的に定義することで403エラーが劇的に改善する。ルートのwp-config.phpに以下の定数を追記する。これは「COOKIE_DOMAIN」の指定だけでなく、管理画面と公開側で異なるパスにクッキーを適応させるための指示だ。

define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '.〇〇.com'); // 自ドメインに合わせる

自サイトがSSL化されている場合は、管理画面の「設定」→「一般」内の「WordPressアドレス」と「サイトアドレス」の両方がhttpsで始まっているかも再確認する。片方がhttpで残っているとREST APIのリクエストがクロスオリジン扱いされ、認証が外れる。

STEP 4 .htaccessとサーバー側の認証ブロックを解除する

WAFやModSecurityが/wp-json/へのアクセスを攻撃と誤認してブロックしている場合、サーバー管理パネルから当該ルールを一時無効化するか、ホワイトリストに追加する。レンタルサーバーの場合、管理画面の「セキュリティ」関連項目にWAFの遮断ログが記録されていることが多い。.htaccessに手動でREST APIを遮断する記述を追加した覚えがなくても、セキュリティプラグインが自動追記しているケースがあるため、以下の記述群が存在しないか確認する。

# もし以下のような記述があれば一時的に削除かコメントアウト
# RewriteRule ^wp-json - [F]

致命的エラー「Class “Elementor\Controls_Stack” not found」の根本対応

致命的エラー「Class

このエラーは単にファイルが見つからないと言っているのではなく、「Elementorの起動シーケンスの中で呼び出されるべき抽象クラスがメモリ上に展開できない」という致命的な状態を指す。管理画面から一度プラグインを「無効化」して「再有効化」してもPHPのオートローダーが不完全なファイル索引を参照し続けるため、FTPから一度完全に削除して、再設置するSTEP 1だけが確実な解決策となる。Pro版を導入している場合、Free版のコアクラスが正しくロードされていないとPro版の処理がすべて失敗するため、必ず両方を手動で入れ直す。

サブディレクトリ環境で403を連発させない設定の定石

サブディレクトリ環境で403を連発させない設定の定石

WordPressを/wordpressに置き、公開URLはルートにする構成は、管理画面へのアクセスパスと公開APIパスの二重構造を生む。システム内部ではadmin-ajax.phpやREST APIの呼び出し元が物理パスを参照する傾向にあるため、ここでクッキーの不一致が起きる。最も安定させる方法は、ルートにあるindex.phpが正しくサブディレクトリを指しているかを確認し、かつwp-config.phpで前述のクッキー定数を定義することだ。可能ならば、この際にWordPressをサブディレクトリからルートディレクトリへ正式に移動させることも検討する価値がある。

よくある質問

セーフモードを有効にしてもElementorエディタが開かないのはなぜか

セーフモードはテーマとElementor以外のプラグインを外して動作するが、今回の主原因は「Elementor本体ファイルの破損」と「REST APIの認証エラー」である。そのため、セーフモードでも参照するコアファイルが破損していれば画面は起動せず、API認証の障害もそのまま残り続ける。セーフモードはあくまで「他のプラグインとの競合」を疑う場合の手段であり、今回のような根本的なファイル破損には効果がない。

変更を保存したはずのパーマリンク設定が元に戻ることはあるか

サーバーの.htaccessファイルやNginxの設定ファイルが書き込み禁止になっていると、パーマリンクの更新が表層的に成功したように見えても内部的に反映されない。FTPで.htaccessのパーミッションが606や666など適切な値になっているか確認し、WordPressが自動生成するRewriteEngine On以下のブロックが存在するかも検証する必要がある。

PHPのバージョンアップが原因でElementorが動かなくなることはあるか

PHP 8.2や8.3、8.4へのアップデートで、従来は警告で済んでいたコードが致命的エラーに格上げされるケースは確かにある。しかし「Controls_Stack not found」はバージョン互換性よりもファイルの単純な欠落または不完全なアップロードが原因だ。事前にサーバーのPHPエラーログを開き、不足している具体的なファイルパスが出力されていないかを確認すると、欠落しているファイルが明確になる。

REST APIを意図的に無効化するセキュリティプラグインの代表例はあるか

WordfenceやiThemes Securityなどの包括的なセキュリティプラグインは、設定次第で未認証または全ユーザーのREST APIアクセスを制限できる。今回のケースではログイン済みの管理者でも「rest_not_logged_in」になるため、むしろクッキーやURLの不一致が強く疑われるが、検証のためにはそれらのプラグインを本当に全停止し、サーバー側のキャッシュを完全にパージする必要がある。

この記事のポイント

  • 403エラーとエディタ停止はコアファイル破損と認証不整合の複合症状である
  • 管理画面ではなくFTPから手動でフォルダを削除し再設置する
  • サブディレクトリ環境では必ずCookie定数を明示的に定義する
  • パーマリンクの再保存と全キャッシュの削除をセットで実行する
  • WAFや.htaccessがREST APIをブロックしていないか確認する
WooCommerce 10.8でOrder更新APIが非Order IDを弾く仕様に。サブスク型データの消失を防止

WooCommerce 10.8でOrder更新APIが非Order IDを弾く仕様に。サブスク型データの消失を防止

WooCommerce 10.8が2026年5月19日にリリース予定で、そのなかでREST APIの注文更新エンドポイントに重要な変更が入る。具体的には、/wc/v3/orders/{id} および /wc/v2 相当のルートが、注文ID以外のIDを指定された場合にHTTP 400エラーを返すようになる。

一見すると小さな修正に思えるが、この変更の背景には「サブスクリプションなどの注文以外のデータが、注文更新APIを通じて誤って通常注文に変換され、種別固有のデータが消失する」という深刻な問題がある。WooCommerceのサブスクリプション機能を使っている事業者や、カスタム連携を組んでいる開発者にとっては見逃せない変更だ。

注文更新APIの型検証が強化された背景

注文更新APIの型検証が強化された背景

従来、WooCommerceのREST API v2およびv3における注文更新エンドポイントは、指定されたIDが本当に注文(shop_order)レコードに属するかをチェックしていなかった。Developer WooCommerce Blogの記事によると、このエンドポイントはサブスクリプション(shop_subscription)など、注文以外のレコードのIDを受け付け、保存時にそれらを通常の注文へとサイレントに変換していたという。

この挙動が引き起こす最大の問題は、サブスクリプション固有のデータ(定期購読の周期、支払いスケジュール、関連する親注文とのひも付けなど)が完全に失われることだ。データが失われているにもかかわらず、APIはHTTP 200で成功を返すため、開発者もサイト運営者も異常に気づきにくい。この問題は GitHub Issue #63936 で報告された。

Before(10.7以前)
PATCH /wc/v3/orders/subscription_id_123
→ 200 OK(サブスクリプションデータ消失)
※IDが実在すれば中身の型を問わず成功を返していた
After(10.8以降)
PATCH /wc/v3/orders/subscription_id_123
→ 400 Bad Request(拒否・データ保護)
※注文以外のIDは即座にエラーになる

実はこの「エンドポイントが受け付けるIDの型を事前に検証する」仕組み自体は、v1エンドポイントには当初から存在していた。v2とv3で欠落していた検証が、10.8でようやく追加される形になる。後方互換性を多少犠牲にしても、データの整合性を守ることを優先した判断といえる。

影響を受けるのはどのようなケースか

影響を受けるのはどのようなケースか

Developer WooCommerce Blogの記事では、影響を受ける開発者の条件が明示されている。/wc/v2/orders/{id} または /wc/v3/orders/{id} に対して、shop_order レコード以外のIDを指定した更新リクエストを送信しているコードやインテグレーションが該当する。

具体的なシナリオとしては、以下のようなケースが考えられる。

  • サブスクリプションの更新処理を誤って注文エンドポイントで行っている
  • カスタムプラグインが注文IDとサブスクリプションIDを区別せずに同一の処理関数に渡している
  • 外部のCRMや基幹システムとの連携で、IDの種別チェックを怠っている
  • バッチ処理やデータ移行スクリプトが注文以外のレコードもまとめて注文APIに送っている

10.8にアップグレードした後、これらのリクエストは以下のようなエラーレスポンスを受け取ることになる。

{
  "code": "woocommerce_rest_shop_order_invalid_id",
  "message": "ID is invalid.",
  "data": {
    "status": 400
  }
}

エラーコード woocommerce_rest_shop_order_invalid_id は、今後ログ監視のキーワードとして覚えておくとよい。このエラーが出ている場合は、注文更新APIに誤ったIDが渡されていることを示す。

過去に影響を受けたデータの取り扱い

過去に影響を受けたデータの取り扱い

ここで重要なのは、過去にすでに変換されてしまったデータは元に戻らないという点だ。10.8より前のバージョンで、非 shop_order のIDに対して注文更新APIが200を返したケースでは、そのレコードはすでに通常注文へと変換されており、種別固有のデータは削除されている。

過去のリクエスト(10.7以前)
PATCH /wc/v3/orders/{subscription_id} → 200 OK
⚠️ サブスクリプション → 通常注文に変換済み(復元不可)
対応策
バックアップの確認と手動復元が必要
APIログの精査 → 影響レコードの特定 → データベース復元

この変更の根本にあるPull Request(#64050)は、型検証の追加というよりも「これ以上のデータ破壊を防ぐ安全装置の設置」と捉えるのが正確だ。10.8は事後対応ではなく、予防措置としてのアップデートである。

開発者が取るべき具体的な対応

開発者が取るべき具体的な対応

サブスクリプション更新処理の移行

WooCommerce Subscriptionsプラグインを使用している場合、サブスクリプションの更新には注文エンドポイントではなく、サブスクリプション専用のRESTエンドポイントを使う必要がある。具体的には /wc/v3/subscriptions/{id} だ。

Developer WooCommerce Blogの記事でも、この移行が最初に推奨されている。コードレベルの修正は単純で、API呼び出しのパスを /orders/ から /subscriptions/ に変更するだけだが、同時にリクエストボディの構造もサブスクリプション用のフォーマットに合わせる必要がある点に注意が必要だ。注文APIとサブスクリプションAPIでは受け付けるパラメータが異なる。

APIログの監査

アップグレード前に、これまでのAPIリクエストログを精査しておくことを強く推奨する。特に以下のシグネチャに注目してほしい。

  • /wc/v2/orders/ または /wc/v3/orders/ へのPATCH/PUTリクエスト
  • レスポンスが200だが、対象IDが注文以外のレコード(サブスクリプション、返品、クーポンなど)
  • サードパーティプラグインや外部サービスからの自動連携リクエスト

影響を受けたレコードが見つかった場合、バックアップからの復元が必要になるケースもある。特にサブスクリプション型のビジネスモデル(定期購入、メンバーシップ、SaaS課金など)を運用している事業者は、この監査を優先タスクとして扱うべきだ。

エラーハンドリングの追加

10.8以降、woocommerce_rest_shop_order_invalid_id エラーが新たに発生し得ることを踏まえ、APIクライアント側のエラーハンドリングにもこのケースを追加しておく必要がある。HTTP 400が返ってきた場合に、単に「リクエスト失敗」としてログに残すだけでなく、IDの種別が誤っていないかをチェックするフローを組み込むとよい。

// 推奨されるエラーハンドリングの擬似コード
if ( response.code === ‘woocommerce_rest_shop_order_invalid_id’ ) {
  // ID の種別を確認し、適切なエンドポイントに振り分ける
  if ( isSubscription( id ) ) {
    patch( `/wc/v3/subscriptions/${id}`, body );
  }
}
※APIクライアント側でエラーコードを判定し、適切なエンドポイントに再ルーティングするパターン

この変更の本質的な意味

この変更の本質的な意味

今回の変更は、単なる「バグ修正」ではなく、WooCommerceのREST APIがデータの型安全性を重視する方向へ舵を切ったことを示すシグナルだ。従来は「多少のデータ不整合には目をつぶり、とにかく動かす」というPHP/WordPressエコシステムの寛容な文化が反映されていたが、ECプラットフォームとしての成熟に伴い、データの一貫性を厳格に守る姿勢へとシフトしている。

実際、GitHub上での議論を見ると、この問題が最初に報告されたのはv1エンドポイントがすでに型検証を持っていたにもかかわらず、v2/v3でそれが欠落していたことへの疑問からだった。APIバージョン間での挙動の不一致が長年放置されていたこと自体が、WooCommerceのREST APIの設計上の技術的負債だったといえる。

EC事業者にとっての実務的な教訓は明確だ。サブスクリプション、予約、会員権など、WooCommerceのカスタム注文タイプを利用している場合は、それぞれのデータ種別に対応する専用エンドポイントの使用を徹底すること。複数の注文タイプを横断するような汎用的なAPIクライアントを自作している場合は、今回の変更を機にアーキテクチャの見直しを検討する価値がある。

この記事のポイント

  • WooCommerce 10.8で注文更新APIが非注文IDをHTTP 400で拒否するようになる
  • これまではサブスクリプションなどのデータが誤って通常注文に変換され、固有情報が消失していた
  • サブスクリプション更新は /wc/v3/subscriptions/{id} 専用エンドポイントへ移行が必要
  • 過去に変換されたレコードはバックアップからの復元以外に手段がないため、APIログの監査が急務
  • 正式リリースは2026年5月19日を予定、事前対応の猶予は短い