XServerのWordPress API、操作権限と非同期処理・復旧を設計する

REST APIの提供後、CLIとMCPにも対応

8月6日の案内では、サイト作成、プラグインやテーマの管理、ステージング、バックアップ、WordPress本体、ユーザー、セキュリティ設定、ドメイン、DNS、PHP、ログ、Cron、SSHなどが列挙された。APIキーごとに対象契約やサイト、機能別の権限、IPアドレスの制限を設定できると説明されている。

当初の発表はREST APIに関するものだったが、公式更新履歴によれば、8月20日にWordPress APIのCLI・MCP対応が追加された。8月26日にはWordPressを含む新規契約の申し込みや、契約管理、API実行ログも追加されている。記事公開時点で「CLIやMCPは未対応」と説明すると古い情報になる。

MCPはAIコーディングツールから操作へ接続する方法で、APIの権限や契約条件を不要にするものではない。また新規申し込みは、無料試用を開始する操作ではなく、前払い残高から料金を引き落とす本契約だと更新履歴は明記している。文章で依頼できるからといって、費用の発生まで曖昧にしたまま実行させるべきではない。

キーの対象範囲を広げ過ぎない

8月6日にはキーの発行単位も、サーバーアカウント単位からXServerアカウント単位へ刷新された。一つのキーへ複数サービスや複数サーバーの権限を設定できる。管理の手間を減らせる一方、漏えいした場合の影響が設定範囲に応じて広がる。

公式マニュアルでは、キーの作成、権限の設定、削除、実行ログの確認などを案内している。キーを不要になった時点で無効化することも管理の一部だ。キーを削除すれば、そのキーで動く処理に影響が出るため、利用先を把握しておく必要がある。

以下は編集部の運用上の考察である。最初の接続では、対象サイトを絞った読み取り権限を使い、一覧取得や状態確認から始めたい。更新作業に進むときは、必要な機能だけを追加し、本番サイトと検証用サイトのキーや承認者を分ける方法が考えられる。操作できる範囲と、業務として許可した範囲を一致させることが目的だ。

作成・復元・削除は受付と完了を区別する

現行APIリファレンスは、サイト作成や削除、ステージング作成、バックアップの作成・復元などを非同期処理として説明する。HTTP 202で受け付けられたことは、処理が完了したという意味ではない。処理状態を確認し、完了後のサイトの状態まで確かめる工程が要る。

通信が途中で切れた場合、依頼が届かなかったのか、受け付け後に応答だけ失われたのかは画面上では分からないことがある。同じ作成や復元の依頼を無条件に再送するのではなく、ジョブの状態や対象の存在、冪等性キーの仕様を確認する必要がある。APIが示すエラーの意味に応じて、再試行できる条件を決めたい。

削除や復元では、取り消せる範囲も重要だ。サイト削除は、単に一覧表示を消す操作とは異なる。復元は現状のデータを上書きし、ステージングやバックアップの扱いも含めて影響し得る。実行対象、取得済みバックアップ、復旧手順を確認した上で、破壊的な操作は別の承認工程へ分けるのが望ましい。

ステージングが作成できることも、本番と同じ条件の試験が自動的に終わることを意味しない。外部決済、メール送信、連携先への通知などが検証環境から実行されないか、運用側で確認すべき点が残る。これは今回のAPIに特定の不具合があるという指摘ではなく、サイトの複製を使う際の一般的な設計課題である。

WordPress管理にも操作できない条件がある

APIのカテゴリ名だけを見て、管理画面のすべての操作を同じように自動化できると考えない方がよい。リファレンスには、サイトや契約の状態、WordPressの構成によって利用できない機能や、機能固有の制約が記載されている。マルチサイトや独自のテーマを使っている場合は、対象のエンドポイントで確認する必要がある。

テーマの取得・更新についても、WordPress.org由来のものと、サービス固有のテーマでは扱いが異なる。DNSのレコード変更とネームサーバー変更も同一ではない。必要な操作のカテゴリがあるという理由だけで、すべての値や種類を変更できると推測しないことが重要だ。

セキュリティ設定では、サービス側で固定・保護されている条件がある。例えば解除できない設定は、APIを使えば迂回できるというものではない。AIがエラーを見て別の方法を自動的に試し続ける構成より、権限不足、対象外、状態による制限を記録して人へ戻す方が、運用の説明可能性を保ちやすい。

制限はAPIキーではなく契約で共有する

現行文書で示されるWordPressのレート制限は、ベーシックが毎分60回・1日1万回・同時5接続、スタンダードが120回・3万回・同時10接続、プレミアムとエンタープライズが300回・10万回・同時20接続である。複数のキーを作っても、同じ契約の利用分は合算される。

制限超過にはHTTP 429と待機時間を示すヘッダーが返される。認証に繰り返し失敗した場合も、一時的な制限がかかることがあるため、単に時間を置いて大量に再試行するのではなく、キーとヘッダーの設定を確認する必要がある。非同期処理の状態確認も、短い間隔で全サイトへ繰り返すと負荷になる。

複数の自動化ツールが同じ契約を使う場合は、個別の処理が上限内でも合計で制限に達し得る。バックアップ、監視、更新の時刻を調整し、リクエスト数と同時接続数をまとめて把握する運用が役立つ。処理速度だけでなく、失敗しても重複実行せず復帰できるかが重要になる。

ログと権限の棚卸しを運用に組み込む

公式マニュアルでは、APIの実行履歴を過去90日分確認でき、キー、期間、成功やエラーなどで絞り込む方法が説明されている。ログは障害の原因調査だけでなく、不要なキーや使われていない権限を見直す材料にもなる。一方、API実行ログとWebアクセスログ、エージェントの会話は別の記録である。どの指示からどの操作へつながったかを追うには、時刻や対象を対応付ける必要がある。

API側で成功しても、公開ページに意図した内容が表示されるとは限らない。キャッシュ、WordPressのプラグイン、DNSの反映、外部連携などが関わる場合がある。操作の応答、管理対象の状態、利用者が見るHTTPや画面という複数の層を確認すると、完了の判断を具体化できる。

AIクローラーからの閲覧を制御する機能と、APIキーで管理操作を許可する仕組みも別のものだ。公開情報を誰が取得できるかと、サイトを誰が変更できるかを混ぜない方がよい。機能の名前だけで安全性を評価せず、認証情報と操作権限がどこで使われるかをたどりたい。

公開サイトへ任せる前の判断

以下は編集部の考察である。まずAPIで確認した情報と、実際の公開HTTPや管理画面の状態を対応付け、次に検証サイトで小さな変更を試す。本番では対象と差分を確定し、バックアップ、実行、結果確認、戻し方までを一つの作業として設計したい。作業ログにはキーそのものを残さず、利用した権限と操作結果を記録する方法が適している。

8月の記事に載ったキャンペーン価格を、10月29日の有効な価格として転載することは避ける。契約料金や対象プランは現在の公式料金ページで確認し、APIによる契約や追加機能の費用とは分けて見たい。自動化の便益も、保守の確認時間や障害時の復旧費を含めて比べる必要がある。

AIを使ったサイト運用や権限設計を検討する際の会社情報・相談先はRO合同会社で確認できる。本稿は公開仕様に基づく整理で、紹介したAPIを当社環境で実行した検証記録や、特定の運用成果を示すものではない。