Hara Daizo WordPress REST APIを使うと、ブラウザー以外のアプリやJavaScriptから、WordPressの投稿などをJSONとして取得・更新できます。公開済み投稿の読み取りは認証なしで試せますが、下書きの取得や書き込みには認証と権限が必要です。
最初から本番で更新を試すのは危険です。この記事では、公開GETの確認から始め、HTTPメソッド、認証、カスタムデータ、安全性へ段階的に進みます。
WordPress REST APIとは
WordPress REST APIは、HTTPリクエストを通じてWordPressのデータを扱うためのインターフェースです。標準では投稿、固定ページ、メディア、カテゴリー、ユーザーなどのルートがあり、応答は主にJSON形式です。
REST APIを使う代表的な場面は次のとおりです。
- 外部サイトやアプリへ公開記事を表示する
- WordPress管理画面内のJavaScriptからデータを操作する
- 許可された外部処理から投稿を作成・更新する
- カスタム投稿タイプを別のフロントエンドへ渡す
WebサイトにREST APIのURLが見えること自体は、直ちに脆弱性を意味しません。公開情報を返す要求と、認証済みユーザーだけに許される操作を区別し、各エンドポイントの権限判定を確認する必要があります。
ルート・エンドポイント・リクエスト・レスポンス
APIルートは利用できる名前空間や経路の入口、エンドポイントは特定の経路とHTTPメソッドの組み合わせです。標準APIの基本URLは、通常はサイトURLにwp-jsonを続けた形になります。
たとえば、wp-json/wp/v2/postsは投稿コレクションを表し、同じ経路でもGETは取得、POSTは作成に使われます。個別投稿では末尾にIDを加えます。応答には本文データだけでなく、HTTPステータス、ヘッダー、エラー時のcodeやmessageも含まれます。
WordPressを表示側から分離する設計は「ヘッドレスCMS化」で構成、キャッシュ、プレビューまで確認できます。本記事ではAPIの操作境界に絞ります。
WordPress REST APIへアクセスする方法
公開情報の確認は、検証サイトのURLを使い、次の順で進めます。
- ブラウザーでサイトURL/wp-json/を開く
- 名前空間の一覧にwp/v2があるか確認する
- サイトURL/wp-json/wp/v2/postsを開く
- JSON内のid、date、slug、status、title、linkを確認する
- 必要ならAPIクライアントで応答ヘッダーも確認する
パーマリンク設定によっては、クエリ形式のrest_routeを使う経路もあります。まず公式のAPIルートが応答するかを確認し、独自プラグインの経路は後から調べると切り分けやすくなります。
ブラウザーのアドレス欄はGETの確認には便利ですが、認証情報をURLへ含めてはいけません。書き込みテストには、HTTPSの検証環境と、ヘッダーを安全に扱えるAPIクライアントを使います。
GETでコンテンツを取得する
投稿一覧はGETで取得できます。次は公開投稿を5件に絞り、必要な項目だけを返す例です。
curl 'https://example.test/wp-json/wp/v2/posts?per_page=5&_fields=id,date,slug,title,link'コレクションではpageでページ番号、per_pageで1回の件数を指定できます。WordPress公式ではper_pageは1〜100で、総件数と総ページ数はX-WP-Total、X-WP-TotalPages応答ヘッダーから確認できます。大量データを1回で要求せず、複数ページへ分けます。
検索や絞り込みに使えるパラメータはエンドポイントごとに異なります。OPTIONSリクエストやREST APIリファレンスでスキーマを確認してください。_fieldsで不要な項目を省くと、応答サイズと生成処理を減らせます。
個別投稿はpostsの末尾へIDを付けて取得します。contextの値により返される情報が変わり、編集用のcontextは通常、認証と適切な権限が必要です。
POST・PUT・DELETEでコンテンツを更新する
WordPress REST ServerはPOST・PUT・PATCHを編集可能なメソッドとして扱えます。一方、標準Postsエンドポイントの公式リファレンスは投稿の作成・更新をPOST、削除をDELETEとして案内しているため、この記事の標準投稿例もPOSTに合わせています。更新操作はサイトのデータを変えるため、必ず認証され、対象操作の権限を持つユーザーとして実行します。
次は構造を理解するための例です。example.testの検証環境、権限を限定した専用ユーザー、環境変数に保存したアプリケーションパスワードを使う前提です。
curl --request POST \
--user "$WP_API_USER:$WP_API_APP_PASSWORD" \
--header 'Content-Type: application/json' \
--data '{"title":"API動作確認","content":"検証環境の下書きです。","status":"draft"}' \
'https://example.test/wp-json/wp/v2/posts'最初はstatusをdraftにし、応答のidとstatusを確認します。本番管理者の通常パスワードをコードへ直書きしたり、公開リポジトリへ置いたりしないでください。
DELETEは削除権限を必要とし、forceの指定でゴミ箱を経由するか完全削除するかが変わるリソースがあります。実行前に対象ID、現在の状態、復旧方法を確認します。
認証が必要な操作
認証方式は、どこからAPIを呼ぶかで選びます。WordPress内のログイン済み画面からの操作ではCookie認証とnonceが一般的です。外部クライアントからHTTPS経由で接続する場合、WordPress 5.6以降のコアにはアプリケーションパスワードがあります。
| 利用場面 | 主な方式 | 注意点 |
|---|---|---|
| 管理画面内のJavaScript | CookieとREST nonce | nonceだけで認証を代替せず、ログインと権限も必要 |
| 外部スクリプト・連携 | アプリケーションパスワード | HTTPSを使い、用途別に発行して不要時に失効 |
| 独立したサービス | OAuth等の認証プラグイン | 製品の保守状況とトークン管理を確認 |
アプリケーションパスワードはユーザー編集画面で発行し、外部アクセスではBasic認証の資格情報として送れます。これは通常のログインパスワードを公開する仕組みではなく、用途ごとに削除できる認証情報です。
API用ユーザーにも、必要な操作だけを許す権限を割り当てます。アカウント自体のログイン防御は「二段階認証の設定」で確認できますが、2FAとAPI資格情報の保護は別々に設計してください。
カスタム投稿タイプ・カスタムフィールドをAPIに公開する
カスタム投稿タイプを標準コントローラーでREST APIへ出すには、登録時のshow_in_restをtrueにします。必要に応じてrest_baseやコントローラーも指定できます。
register_post_type(
'book',
array(
'label' => 'Books',
'public' => true,
'show_in_rest' => true,
'rest_base' => 'books',
'supports' => array( 'title', 'editor', 'excerpt' ),
)
);公開すべきでないフィールドを、便利だからという理由だけで応答へ追加しないでください。スキーマ、表示context、更新時の権限、sanitize_callbackやvalidate_callbackを設計します。
ACF 5.11以降にはコアREST APIとの統合があり、フィールドグループの「Show in REST API」は既定で無効です。対象のカスタム投稿タイプもAPIに見えている必要があります。具体的なデータ型と設定は「カスタムフィールドとACF」で確認し、外部処理の接続設計は「AI・外部ツール連携」で分けて検討できます。
WordPress REST APIの活用例
REST APIは、コンテンツをHTTPで扱う共通の窓口として利用できます。
- JavaScriptフロントエンドで記事一覧を取得する
- モバイルアプリへ公開コンテンツを配信する
- 社内システムから下書きを登録する
- 投稿公開後に別システムへ情報を同期する
- AI処理の入力・出力を承認フロー付きで連携する
どの例でも、取得だけか更新を伴うか、個人情報が含まれるか、停止時に再実行できるかを先に決めます。APIが使えることと、業務処理として安全に自動化できることは別です。
REST APIのセキュリティ上の注意
APIは一律に無効化するより、必要な機能と公開範囲を表で確認します。
| 確認軸 | 読み取りAPIで見る点 | 書き込みAPIで見る点 |
|---|---|---|
| 認証 | 公開情報以外を返さないか | 方式、HTTPS、失効手順 |
| 権限 | context別の応答 | current_user_can相当の権限判定 |
| 個人情報 | ユーザー名、メール、メタデータ | ログや応答へ秘密を残さない |
| 入力 | クエリ件数と許容値 | 型、検証、サニタイズ |
| 負荷 | ページング、キャッシュ、_fields | 連続実行、タイムアウト、再試行 |
| 監視 | 4xx・5xxの増加 | 操作者、対象ID、変更結果 |
資格情報はURLへ入れず、ソースコードやフロントエンドJavaScriptにも埋め込みません。外部クライアントからブラウザーへ配布された秘密は、利用者に見えるものとして扱う必要があります。
CORSは、ブラウザーが別オリジンから応答を読めるかを制御する仕組みで、サーバー側の認証や権限確認の代わりではありません。許可元を必要最小限にし、ワイルドカードと認証情報を安易に組み合わせないでください。
REST APIが動かない場合の対処
まずHTTPステータスとJSONのcode、message、dataを保存します。そのうえで次を確認します。
- wp-jsonのルート自体が応答するか
- 対象の名前空間とエンドポイントが登録されているか
- パーマリンクを再保存して経路が直るか
- 認証情報、HTTPS、ユーザー権限が正しいか
- WAF、セキュリティプラグイン、キャッシュが遮断していないか
- ブラウザーだけ失敗するならCORSとプリフライト応答を確認する
401は認証できていない場合、403は認証済みでも権限がない場合に多く見られますが、実際のcodeとサーバー構成で判断します。404ではURL、名前空間、show_in_rest、パーマリンクを確認します。
よくある質問
一律無効化は推奨できません。ブロックエディターやプラグインが依存している場合があり、機能を壊す可能性があります。不要な独自エンドポイント、公開フィールド、権限設定を個別に見直します。
REST APIはHTTPでWordPressのリソースを扱う基盤です。MCPはAIクライアントがツールや情報源を扱うための接続規約で、WordPress REST APIを内部で利用する実装もあり得ますが、同じものではありません。
公開済み記事と同等の情報を返すGETは、標準の利用方法です。危険性は、非公開情報、不要なユーザーデータ、秘匿すべきメタデータまで返していないかで評価します。
まとめ
WordPress REST APIは、投稿などをHTTPとJSONで扱うための仕組みです。まず公開GETでルートと応答を確認し、_fieldsとページングで必要なデータだけを取得します。
書き込みはHTTPSの検証環境で、権限を限定したユーザーと失効可能な認証情報を使います。公開・認証、読み取り・書き込み、権限、個人情報、負荷を分けて点検し、API全体を止める前にエンドポイント単位で安全性を整えてください。