WordPressには「REST API」という機能が標準で組み込まれています。
REST APIを使うと、管理画面を開かずに、外部のプログラムやAIツールからWordPressのデータを取得・作成・更新・削除できます。
この記事では、WordPress REST APIでできることを整理したうえで、実際に接続して使えるようにするまでの構築手順を解説します。
カスタム投稿タイプやカスタムフィールドをAPIに対応させる方法、独自エンドポイントの追加方法、つまずきやすいポイントまでまとめています。
WordPress REST APIとは
WordPress REST APIは、WordPressのデータをHTTP経由で操作するための公式インターフェースです。
WordPress 4.7以降、プラグインなしで標準搭載されています。
データのやり取りはすべてJSON形式で行われます。
まずは自分のサイトで有効になっているか確認してみます。
https://example.com/wp-json/このURLにアクセスしてJSONが表示されれば、REST APIは有効です。
投稿一覧を取得する場合は次のURLです。
https://example.com/wp-json/wp/v2/postsここまでは認証不要で、公開済みの情報であれば誰でも取得できます。
一方で、下書きの取得や記事の作成・更新には認証が必要になります。
REST APIの基本構造
エンドポイントは次のような構造になっています。
https://example.com/wp-json/{名前空間}/{バージョン}/{リソース}WordPress本体の機能は wp/v2 という名前空間にまとまっています。
プラグインが独自機能を追加する場合は、woocommerce/v3 のように別の名前空間が使われます。
操作はHTTPメソッドで指定します。
- GET：取得
- POST：作成・更新
- PUT / PATCH：更新
- DELETE：削除
WordPressの場合、更新はPUTではなくPOSTでも受け付けてくれるため、実務ではPOSTを使うことが多いです。
WordPress REST APIでできること
標準で用意されている主なエンドポイントは以下のとおりです。
/wp/v2/posts：投稿の取得・作成・更新・削除/wp/v2/pages：固定ページの操作/wp/v2/media：画像などメディアのアップロード・編集/wp/v2/categories：カテゴリーの操作/wp/v2/tags：タグの操作/wp/v2/comments：コメントの操作/wp/v2/users：ユーザー情報の取得・編集/wp/v2/taxonomies：登録済みタクソノミーの一覧/wp/v2/types：登録済み投稿タイプの一覧/wp/v2/settings：サイトタイトルなど基本設定の取得・変更/wp/v2/search：横断検索/wp/v2/block-types：ブロックタイプの一覧
このうち settings は管理者権限が必要で、認証しないと表示されません。
投稿・固定ページで編集できる項目
投稿と固定ページでは、次のような項目をAPI経由で扱えます。
- タイトル
- 本文
- 抜粋
- スラッグ
- 公開状態（publish / draft / private / pending / future）
- 公開日時
- 投稿者
- アイキャッチ画像
- カテゴリー・タグ
- 親ページ・メニュー順（固定ページのみ）
- テンプレート
- コメント許可設定
ブロックエディタで作成した記事も、本文はブロックコメント付きのHTMLとしてそのまま取得・更新できます。
メディアで編集できる項目
画像のアップロードに加えて、次の項目も編集できます。
- タイトル
- 代替テキスト（alt）
- キャプション
- 説明
altの一括修正などをスクリプトで処理したい場合に便利です。
認証方法を決める
外部から記事を編集するには認証が必要です。
WordPressで使える主な認証方法は次の4つです。
アプリケーションパスワード
WordPress 5.6以降に標準搭載されている方式です。
追加のプラグインが不要で、外部ツールから接続する場合はこれが第一候補になります。
HTTPS環境が必須である点だけ注意が必要です。
Cookie認証（nonce）
管理画面内のJavaScriptから叩く場合に使う方式です。
外部サーバーやAIツールからの接続には使えません。
JWT認証
プラグインを導入してトークンで認証する方式です。
トークンの有効期限を管理できるため、アプリケーション連携で使われることがあります。
OAuth 2.0
複数ユーザーに権限を委譲するような、本格的なサービス連携向けの方式です。
個人サイトの運用で使うことはあまりありません。
以下ではアプリケーションパスワードを前提に進めます。
構築手順1：アプリケーションパスワードを発行する
WordPressの管理画面にログインします。
次にプロフィール画面を開きます。
ユーザー > プロフィールページ下部にある「アプリケーションパスワード」の欄に、用途がわかる名前を入力します。
AI連携用「新しいアプリケーションパスワードを追加」を押すと、パスワードが発行されます。
発行されるのは次のような形式の文字列です。
abcd EFGH ijkl MNOP qrst UVWXこのパスワードは一度しか表示されないため、その場で控えておきます。
空白は含めたままでも、削除しても、どちらでも認証は通ります。
なお、この項目が表示されない場合はHTTPSになっていない可能性が高いので、まずはSSL設定を確認します。
接続先のAIツールで認証情報の保存方法と実行できる操作を確認し、専用ユーザーで接続します。
認証情報の設定だけで、更新内容や操作権限が自動的に適切になるわけではありません。
自動処理ではアプリケーションパスワードを環境変数やアクセスを制限した設定ファイルから読み取り、会話本文・リポジトリ・ログへ出力しません。
.envを使う場合も共有やGit管理の対象から外します。
構築手順2：接続を確認する
まず認証が必要なusers/meで、接続した専用ユーザーのIDを確認します。
以下のcurl例はPOSIX系シェルの改行・引用符です。
Windows PowerShellではcurl.exeを使い、改行やJSONの渡し方をそのシェルに合わせてください。
-uには専用ユーザー名だけを指定し、表示されるパスワード入力欄へアプリケーションパスワードを入力します。
通常のログインパスワードは使いません。
入力待ちを避ける自動処理には、この対話入力例をそのまま流用しません。
認証情報の扱いはcurlの公式マニュアルも参照してください。
curl -u "専用ユーザー名" \
https://example.com/wp-json/wp/v2/users/meログイン中のユーザー情報がJSONで返ってくれば成功です。
401が返る場合は、認証情報かサーバー設定に問題があります。
403が返る場合は、認証は通っているものの権限が足りていない状態です。
構築手順3：記事を取得する
公開済みの投稿を5件取得する例です。
curl "https://example.com/wp-json/wp/v2/posts?per_page=5"下書きを含めて取得したい場合は、認証したうえでstatusを指定します。
curl -u "専用ユーザー名" \
"https://example.com/wp-json/wp/v2/posts?status=draft"記事を編集する目的で本文を取得する場合は、context=edit を付けます。
curl -u "専用ユーザー名" \
"https://example.com/wp-json/wp/v2/posts/123?context=edit"これを付けないと、本文はショートコードやブロックが展開された表示用HTMLで返ってきます。
context=edit を付けると content.raw にエディタ上のままのブロックHTMLが入るため、リライト用途ではこちらを使います。
レスポンスが大きすぎる場合は _fields で項目を絞れます。
curl "https://example.com/wp-json/wp/v2/posts?_fields=id,title,slug,link&per_page=100"per_page の上限は100件です。
全件を扱うときは、レスポンスヘッダーの X-WP-Total と X-WP-TotalPages を見ながら page を進めます。
構築手順4：記事を作成・更新する
下書き記事を新規作成する例です。
curl -X POST https://example.com/wp-json/wp/v2/posts \
-u "専用ユーザー名" \
-H "Content-Type: application/json" \
-d '{
"title": "テスト記事",
"content": "<!-- wp:paragraph --><p>本文です。</p><!-- /wp:paragraph -->",
"status": "draft",
"slug": "test-post",
"categories": [3]
}'既存記事を更新する場合は、URLに投稿IDを付けてPOSTします。
curl -X POST https://example.com/wp-json/wp/v2/posts/123 \
-u "専用ユーザー名" \
-H "Content-Type: application/json" \
-d '{"title": "更新後のタイトル"}'送信した項目だけが更新され、指定しなかった項目はそのまま残ります。
JavaScriptから扱う場合は次のようになります。
const auth = btoa(`${username}:${appPassword}`);
const res = await fetch("https://example.com/wp-json/wp/v2/posts", {
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Basic ${auth}`,
},
body: JSON.stringify({
title: "テスト記事",
content: "本文です。",
status: "draft",
}),
});
const data = await res.json();
console.log(data.id, data.link);
なお、この書き方はブラウザ上で実行すると認証情報が丸見えになります。
認証を伴う処理は、必ずサーバー側やローカル環境から実行します。
構築手順5：画像をアップロードする
メディアのアップロードはJSONではなくバイナリを送信します。
curl -X POST https://example.com/wp-json/wp/v2/media \
-u "専用ユーザー名" \
-H "Content-Disposition: attachment; filename=sample.jpg" \
-H "Content-Type: image/jpeg" \
--data-binary @sample.jpg返ってきたIDを使えば、アイキャッチ画像として設定できます。
curl -X POST https://example.com/wp-json/wp/v2/posts/123 \
-u "専用ユーザー名" \
-H "Content-Type: application/json" \
-d '{"featured_media": 456}'代替テキストを後から編集する場合はmediaエンドポイントを更新します。
curl -X POST https://example.com/wp-json/wp/v2/media/456 \
-u "専用ユーザー名" \
-H "Content-Type: application/json" \
-d '{"alt_text": "サンプル画像の説明"}'カスタム投稿タイプをREST APIに対応させる
カスタム投稿タイプは、登録時に show_in_rest を有効にしないとAPIに現れません。
functions.php またはプラグイン側で次のように登録します。
add_action('init', function () {
register_post_type('works', [
'label' => '実績',
'public' => true,
'has_archive' => true,
'show_in_rest' => true,
'rest_base' => 'works',
'supports' => ['title', 'editor', 'excerpt', 'thumbnail', 'custom-fields'],
]);
});これで次のエンドポイントが使えるようになります。
https://example.com/wp-json/wp/v2/worksすでに動いているサイトで対応状況を確認したい場合は、typesエンドポイントを見ます。
https://example.com/wp-json/wp/v2/typesここに載っていて rest_base が設定されていれば、API経由で操作できます。
既存のカスタム投稿タイプがテーマやプラグインで登録されていて直接編集できない場合は、フィルターで後から有効化する方法もあります。
add_filter('register_post_type_args', function ($args, $post_type) {
if ($post_type === 'works') {
$args['show_in_rest'] = true;
$args['rest_base'] = 'works';
}
return $args;
}, 10, 2);カスタムタクソノミーをREST APIに対応させる
考え方は投稿タイプと同じです。
add_action('init', function () {
register_taxonomy('works_cat', ['works'], [
'label' => '実績カテゴリー',
'public' => true,
'hierarchical' => true,
'show_in_rest' => true,
'rest_base' => 'works_cat',
]);
});公開されているタクソノミーの一覧はこちらで確認できます。
https://example.com/wp-json/wp/v2/taxonomiesターム一覧の取得や、記事へのターム紐付けもAPIから行えます。
タームIDは一覧から取得した存在するIDを使い、更新後のレスポンスでも保存された配列を確認してください。
存在しないタームIDだけを指定すると、エラーにならず既存の紐付けが外れる場合があります。
curl -X POST https://example.com/wp-json/wp/v2/works/123 \
-u "専用ユーザー名" \
-H "Content-Type: application/json" \
-d '{"works_cat": [5, 8]}'カスタムフィールド・メタディスクリプションを扱う
カスタムフィールドは、標準ではREST APIに公開されていません。
register_post_meta で明示的に登録する必要があります。
function waza_register_rest_note() {
register_post_meta( 'post', 'waza_rest_note', array(
'single' => true,
'type' => 'string',
'sanitize_callback' => 'sanitize_text_field',
'show_in_rest' => array( 'schema' => array(
'type' => 'string',
'context' => array( 'edit' ),
) ),
'auth_callback' => function ( $allowed, $key, $post_id ) {
return current_user_can( 'edit_post', $post_id );
},
) );
}
add_action( 'init', 'waza_register_rest_note' );
この例のキーはwaza_rest_noteです。
投稿別の編集権限を確認し、edit文脈でのみ値を返すため、公開読取用のフィールドにはなりません。
登録すると、レスポンスの meta 内に含まれるようになります。
curl -X POST https://example.com/wp-json/wp/v2/posts/123 \
-u "専用ユーザー名" \
-H "Content-Type: application/json" \
-d '{"meta": {"waza_rest_note": "任意の値"}}'
SEOプラグインの説明文は投稿メタに保存される場合がありますが、独自テーブルを使うものもあります。
プラグインによってキー名が異なり、REST API対応の有無も変わります。
- SEO SIMPLE PACK：
ssp_meta_descriptionなどのメタキー - Rank Math：
rank_math_description - Yoast SEO：
_yoast_wpseo_metadesc - All in One SEO：独自テーブルに保存されるため通常のメタでは扱えない
RESTで利用できない場合は、プラグインが提供する連携方法とデータ構造を確認します。
Rank Mathなど既存プラグインのメタキーは、上の独自キーの例で再登録しないでください。
プラグイン側のREST対応、キー名、保存権限、出力への反映を確認してから連携します。
アンダースコアで始まるメタキーは保護されたメタとして扱われるため、auth_callback の指定が必須になります。
プラグインのアップデートで保存先の仕様が変わることもあるため、更新前に必ずバックアップを取ります。
独自エンドポイントを追加する
標準のエンドポイントで足りない場合は、自分でルートを追加できます。
次の例はサイト全体の公開件数と下書き件数を返すため、edit_others_posts権限を持つ利用者だけに許可します。
通常の著者・寄稿者・購読者には返さず、全体の投稿を管理する編集者や管理者が認証して利用する想定です。
add_action('rest_api_init', function () {
register_rest_route('motoki/v1', '/summary', [
'methods' => 'GET',
'callback' => function (WP_REST_Request $request) {
$count = wp_count_posts('post');
return new WP_REST_Response([
'publish' => (int) $count->publish,
'draft' => (int) $count->draft,
], 200);
},
'permission_callback' => function () {
return current_user_can('edit_others_posts');
},
]);
});呼び出しはこうなります。
https://example.com/wp-json/motoki/v1/summary
permission_callback は省略できません。
省略すると警告が出るうえ、誰でもアクセスできる状態になってしまいます。
読み取り専用で公開したい場合でも、明示的に __return_true を書きます。
ChatGPTなどのAIツールと接続する
接続に必要な情報は次の3つだけです。
WORDPRESS_URL=https://example.com
WORDPRESS_USERNAME=
WORDPRESS_APP_PASSWORD=
これを .env に保存し、.gitignore に .env を追加して公開されないようにします。
AIツール側との接続方法は、大きく3パターンあります。
MCPサーバー経由で接続する
Claude DesktopやAI開発ツールから使う場合は、MCPサーバーを立てる方法が主流です。
WordPress REST APIをラップしたMCPサーバーを用意し、環境変数に上記3つを渡します。
MCPサーバーで公開するツールから削除操作を外せます。
ただし、ツール定義はWordPressの認証情報そのものを操作単位で制限する機能ではありません。
専用ユーザーの権限、WordPress側の投稿別権限、MCPサーバーが許可する操作と対象IDをそれぞれ確認します。
GPTsのActionsとして登録する
ChatGPTのGPTsから使う場合は、OpenAPIスキーマを定義してActionsに登録します。
GPTsのActionsで選べる認証方式は、OpenAIの公式認証資料ではNone・API Key・OAuthです。
WordPressのアプリケーションパスワードはHTTP Basic認証を使いますが、ユーザー名とパスワードをActionsへ入力するだけで接続できるとは限りません。
必要なAuthorizationヘッダーを送れる構成か、サーバー側でWordPressの認証へ変換する中継処理が必要かを確認します。
OpenAPIスキーマはActionsに見せる操作を定義します。
スキーマから操作を省いても、同じ認証情報を別のクライアントで使った場合のWordPress側の権限は変わりません。
実際の許可・拒否は、WordPressのユーザー権限と各ルートのpermission_callbackなどで判定します。
スクリプト経由で処理する
まとまった件数を機械的に処理するなら、Node.jsやPythonのスクリプトが確実です。
AIには文章生成だけを任せ、WordPressへの反映は自分のスクリプトから行う形が一番安全です。
つまずきやすいポイント
Authorizationヘッダーが届かない
サーバー設定によっては、Authorizationヘッダーが削除されて401になることがあります。
Apacheの場合は .htaccess に次を追記します。
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
エックスサーバーなど一部のレンタルサーバーでは、この対応が必要になるケースがあります。
セキュリティプラグインにブロックされる
SiteGuard WP PluginやWordfenceなどが、REST APIやXML-RPCへのアクセスを制限していることがあります。
401や403が解消しない場合は、プラグインの設定も確認します。
権限が足りない
投稿の作成には edit_posts、公開には publish_posts の権限が必要です。
寄稿者権限のユーザーでは公開まで到達できません。
APIの接続元ごとに専用ユーザーを作り、必要最小限の権限を割り当てるのがおすすめです。
本文が意図した形で保存されない
content に生のHTMLを渡すと、ブロックエディタ側では「クラシックブロック」として扱われます。
ブロックとして正しく認識させたい場合は、<!-- wp:paragraph --> などのブロックコメントを含めた形式で送信します。
日時の扱い
date はサイトのタイムゾーン基準、date_gmt はUTC基準です。
予約投稿を作る場合は、status を future にしたうえで date を指定します。
安全に運用するためのルール
編集権限を持つ認証情報を外部ツールに渡すことになるため、運用ルールを決めておきます。
- 接続用のユーザーは専用に作り、管理者権限は避ける
- アプリケーションパスワードは用途ごとに分けて発行する
- 使わなくなったパスワードはすぐに失効させる
- 新規記事は必ず下書きとして作成する
- 公開済み記事の上書きは人の確認を挟む
- 削除系の操作はAIに任せない
.envは絶対にリポジトリに含めない- 一括更新の前にデータベースをバックアップする
まずは読み取りと下書き作成から始めて、問題がないことを確認してから範囲を広げるのが安全です。
まとめ
WordPress REST APIを使えば、投稿・固定ページ・メディア・カテゴリー・タグを外部から自由に操作できます。
カスタム投稿タイプやカスタムタクソノミーも、show_in_rest を有効にすれば同じように扱えます。
カスタムフィールドやSEOのメタディスクリプションは、register_post_meta でAPIに公開することで編集可能になります。
さらに register_rest_route を使えば、自分のサイト専用のエンドポイントも追加できます。
WordPressのアプリケーションパスワードで接続する基本情報は、HTTPSのサイトURL・専用ユーザー名・アプリケーションパスワードです。
AIツール側の認証方式や中継処理によって、追加の設定が必要になることがあります。
まずは wp-json/wp/v2/users/me で疎通を確認し、下書き作成から試してみるとイメージがつかみやすいはずです。
権限とバックアップの管理さえ押さえておけば、記事のリライトや情報整理を大幅に効率化できます。
この記事で紹介しているコードは、GitHubのMOTOKI-LLC/WAZA-codeにもまとめています。
独自メタの検証と戻し方
検証用投稿で値を保存し、編集権限のあるedit文脈では読めることと、ログアウトした公開読取では返らないことを確認します。
編集権限のない利用者の更新を拒否することも確認します。
停止する場合は追加した登録関数とフックを外しますが、保存済みの値は自動では削除されません。
既存プラグインのメタを変更してしまった場合は、変更前バックアップから対象値を復元してください。
ローカルWordPressで投稿の作成・更新、投稿別権限、公開用と編集用のレスポンス、カスタム投稿・タクソノミーと集計ルートを確認しました。
2026年10月3日、WordPress 7.1.2の隔離環境でHTTPSのアプリケーションパスワード認証、下書き作成、独自メタの保存とHTMLタグ除去、購読者の更新拒否、著者による集計ルートの拒否と編集者の許可を確認しました。
画像アップロード・代替テキスト・アイキャッチ設定も同じ認証で検証しました。
HTTPの検証にはPythonクライアントを使用しました。
curl例の各シェルでの対話操作、GPTsのActionsやMCPサーバーとの接続は未検証です。
