Claude CodeやChatGPTに「記事を下書きしておいて」と頼むと、本当にWordPressに下書きができる。そんな使い方が、2026年に入って現実になりました。WordPress公式もAIから操作するための仕組み(MCP AdapterやAbilities API)を整えつつあります。便利な反面、AIに渡した権限の範囲で、AIは実際に動きます。うっかり管理者の権限を渡せば、記事の削除も、プラグインの停止も、理屈の上ではできてしまいます。
当社はWordPressの記事運用の大部分を、すでにAIとプログラムで自動化しています。この記事では、その運用と、公式の仕組みで組んだ検証環境をもとに、AIにWordPressを操作させる前に決めておくべき5つのことを整理します。実は、この記事を書くために自社の設定を点検したところ、直すべき点が2つ見つかりました。それも含めて書きます。
結論から言うと、決めるのは「どのアカウントで」「何をさせるか」「どこで人が確認するか」「失敗したらどうするか」「何を記録して、どう戻すか」の5つです。最初は読み取りだけに絞り、書き込みは1つずつ、人の確認を挟んで足していくのが安全です。
この記事は2026年9月28日時点の情報です。WordPress公式のAI関連の仕組みは開発中のものが多く、変化があれば追記します。
なぜ今、AIに渡す権限を考える必要があるのか
これまで、WordPressを外から操作するのは「人が書いたプログラム」でした。決まった処理を、決まった順に実行するだけです。いま広がっているのは、AIが自分で「どの操作を使うか」を選んで実行する使い方です。
AIは頼まれたことを達成しようとして、使える手段を探します。当社が別の記事で試したWebMCPの実験では、用意した道具がうまく使えなかったとき、AIが「別の経路を探す」と言ってパソコンの中で動いているプログラムの一覧を調べ始めました。今回は害のない動きでしたが、AIは「渡された範囲」の中なら、人が想定していない手段も選ぶということです。だからこそ、渡す範囲を人が先に決めておく必要があります。
当社で実際にやっていること
当社のブログ記事は、次の流れでAI(Claude Code)とプログラムが準備しています。
- 記事の原稿ファイルと画像を用意すると、画像の圧縮・アップロード・下書き登録・予約までを自動で行う
- 既存記事のタイトルや本文を直すときは、まず変更前と変更後の差分だけを表示し、人が確認してから反映する
- 反映する前の内容は、毎回自動でバックアップを残す
WordPressとの接続には、WordPress標準のREST APIと「アプリケーションパスワード」を使っています。アプリケーションパスワードは、普段のログインパスワードとは別に、外部のプログラム専用に発行できるパスワードです。
さらに、WordPress公式のMCP Adapterを検証環境(本番サイトのコピー)に入れ、Claude Codeから直接操作できる窓口も作りました。MCP Adapterの仕組みと導入手順はClaudeからWordPressを操作する公式MCP Adapterの検証記事で詳しく解説しています。この2つの経験から、決めるべきことを5つに分けて説明します。
決めること1:AIにどのアカウントを使わせるか
一番大事なのに、一番見落とされやすいのがここです。AIに渡すパスワードは、そのアカウントの権限をまるごと渡すことになります。
この記事を書くにあたって当社の設定を点検したところ、記事投稿の自動化に使っていたのは、管理者アカウントのアプリケーションパスワードでした。当社の自動化でやっている下書きの作成、画像の登録、タグの作成、記事の更新は、どれも「編集者」の権限で足ります。管理者の権限は必要ありません。動いているから気づかない、というのが一番の落とし穴でした。
おすすめは次の形です。
- AI専用のユーザーを作る(人のアカウントと分ける)
- 権限は、やらせたい作業に必要な最小のもの(記事の作成・編集なら「編集者」、下書きだけなら「投稿者」)
- アプリケーションパスワードは、用途ごとに名前を付けて1つずつ発行する
専用ユーザーにしておくと、「どの変更をAIがしたのか」が投稿者の名前で一目で分かるようになります。WordPress公式のMCP Adapterの解説でも、本番環境では専用のユーザーと権限を絞ったロールを使うよう勧められています。
決めること2:AIに何をさせるか(させないか)
AIに渡す操作は、「できないことを禁止する」のではなく、「できることを列挙する」形で決めます。列挙していない操作は、最初から存在しない状態にするのが安全です。

当社がMCPの検証で公開したのは、次の3つの操作だけです。
| 操作 | 区分 | 制限 |
|---|---|---|
| サイト情報を取得 | 読み取り | サイト名・URL・バージョンだけを返す |
| 最近の記事を取得 | 読み取り | 公開済みの記事を最大10件まで |
| 下書きを作成 | 書き込み | 必ず「下書き」で作成。公開・更新・削除はできない |
ポイントは3つ目です。AIに「記事を作って」と頼めるようにしつつ、公開ボタンを押すのは必ず人という線を、仕組みの側で引いています。削除、設定の変更、プラグインやユーザーの操作は、そもそも公開していません。AIからは、登録されていない操作は見えもしません。
決めること3:どこで人が確認するか
すべての操作に人の確認を挟むと、AIに任せる意味がなくなります。逆に、確認をすべて省くと事故が起きます。図の3段階に合わせて、確認の場所を決めるのが現実的です。
- 読み取り:確認なしでAIに任せる
- 戻せる書き込み(下書き・メタ情報・画像):実行前に差分を見て承認する
- 戻せない・外に出る操作(公開・削除・メール送信):AIには渡さず、人が操作する
当社の記事更新は、何も指定しなければ「差分を表示するだけ」で終わる作りにしてあります。反映するには、差分を確認したうえで、はっきり「反映する」という指示を足す必要があります。AIが気を利かせて勝手に反映することは、仕組みとして起きません。
AIのアプリ側にも、同じ考え方の設定があります。ChatGPTのデスクトップアプリでは、AIがウェブを閲覧する、ファイルをダウンロードする、アップロードするといった操作が、初期設定ですべて「承認が必要」になっていました。

アプリの承認とWordPress側の権限は、二重の鍵です。アプリの承認を「常に許可」に変えるときほど、WordPress側の権限を絞っておくことが大切になります。
決めること4:失敗したときにどう振る舞わせるか
AIやAPIは、いつか必ず失敗します。接続が切れる、相手のサービスが止まる、想定外の入力が来る。そのとき「何もしないで止まる」のか「別の手段で続けようとする」のかを、先に決めておく必要があります。
先に書いたWebMCPの実験では、道具が使えなかったAIが、別の手段を探し始めました。WordPressの操作では、これを避けるために次の2つを決めておきます。
- AIに渡す手段を、WordPressの窓口だけに絞る。同じAIにサーバーへのログインやコマンドの実行まで許していると、窓口が使えないときにそちらへ回り込む余地が生まれます。
- 失敗したら「元の動作に戻る」を既定にする。当社がAIチャットボットに判定専用AIを組み込んだときも、「最初は機能をオフ」「接続できないときは従来どおり動く」を最初に決めてから作りました。
決めること5:何を記録して、どう戻すか
最後は、何か起きたときの備えです。
- 変更前の内容を残す。当社は記事を更新するたび、変更前の本文を自動でファイルに保存しています。WordPressのリビジョン機能も有効にしておきます。
- 誰が変えたかを分ける。決めること1の専用ユーザーにしておけば、投稿者の名前でAIの変更を見分けられます。
- 止め方を決めておく。アプリケーションパスワードは、ユーザー編集画面から1つずつ取り消せます。AIの動きがおかしいときは、そのパスワードを取り消せば、ほかに影響を出さずに接続だけを止められます。
ここでも、点検で見つかったことがあります。8月11日を最後に使われていないアプリケーションパスワードが、1つ残っていました。以前、別の用途で発行したものです。使っていない鍵は、持っている意味がないどころか、漏れたときの入口になります。発行した日と最後に使った日は、ユーザー編集画面の「アプリケーションパスワード」の一覧で確認できるので、定期的に見直してください。
パスワードの扱いで守ること
AIと一緒に作業していると、ついチャット欄にパスワードを貼り付けたくなります。これは避けてください。当社では次のルールで運用しています。
- パスワードはチャットに貼らず、専用の設定ファイル(.env)にだけ書く
- AIが作業の途中でパスワードを画面に表示しないようにする
- 設定ファイルは公開される場所やバックアップの共有フォルダに置かない
WordPress 7.2では、プラグインが外部サービスの鍵を安全に保存するための「Secrets API」が検討されています。AIとの接続が当たり前になるほど、鍵の保管場所は重要になっていきます。
チェックリスト
| 項目 | 確認すること |
|---|---|
| アカウント | AI専用のユーザーか。権限は編集者以下か |
| パスワード | 用途ごとに発行しているか。使っていないものは取り消したか |
| 操作の範囲 | できる操作を列挙しているか。削除・設定変更・プラグイン操作を含めていないか |
| 公開 | 公開ボタンを押すのは人か |
| 確認 | 書き込みの前に差分を見る仕組みがあるか |
| 失敗時 | 失敗したら止まる(元の動作に戻る)作りか。AIにほかの手段を渡していないか |
| 記録 | 変更前の内容が残るか。誰が変えたか分かるか |
| 停止 | パスワードの取り消しで接続を止められるか |
開発者向け:Abilities APIで操作を公開するときの要点
ここからは、WordPressの開発者向けです。当社の検証では、Abilities APIで操作を登録し、MCP Adapterの独自サーバーでその3つだけを公開しました。押さえておきたい点は次のとおりです。
- permission_callbackで権限を確かめる。読み取りは read、下書き作成は edit_posts のように、操作ごとに必要な権限を返します。
- input_schemaで入力を絞る。件数に上限を付ける、文字数に上限を付ける、想定外の項目を受け付けない(additionalProperties を false)。
- 実行の中でも値を無害化する。タイトルは sanitize_text_field、本文は wp_kses_post を通し、投稿の状態は入力に関係なく draft に固定します。
- annotationsで性質を宣言する。読み取り専用か、破壊的か、何度実行しても同じ結果か。MCPでは readOnlyHint や destructiveHint としてAIのアプリに伝わり、承認の判断に使われます。
- 既定のサーバーに頼らず、公開する操作を明示したサーバーを作る。公開の範囲を1か所で管理できます。
- 環境で動作を止める。検証用の操作は、wp_get_environment_type() が local 以外なら何も登録しないようにしました。本番に誤って置かれても動きません。
下書き作成の操作は、たとえば次のように書いています(抜粋)。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
wp_register_ability( 'edel/create-draft', array( 'label' => '下書きを作成', 'description' => 'タイトルと本文を受け取り、投稿を「下書き」として作成する。公開・更新・削除はできない。', 'category' => 'edel-demo', 'input_schema' => array( 'type' => 'object', 'properties' => array( 'title' => array( 'type' => 'string', 'minLength' => 1, 'maxLength' => 200 ), 'content' => array( 'type' => 'string', 'maxLength' => 20000 ), ), 'required' => array( 'title' ), 'additionalProperties' => false, ), 'execute_callback' => function ( $input ) { return wp_insert_post( array( 'post_title' => sanitize_text_field( $input['title'] ), 'post_content' => wp_kses_post( $input['content'] ?? '' ), 'post_status' => 'draft', // 入力に関係なく常に下書き 'post_type' => 'post', 'post_author' => get_current_user_id(), ), true ); }, 'permission_callback' => function () { return current_user_can( 'edit_posts' ); }, 'meta' => array( 'annotations' => array( 'readonly' => false, 'destructive' => false, 'idempotent' => false ), ), ) ); |
なお、検証はローカル環境で行ったため、接続には管理者のアプリケーションパスワードを使いました。本番で同じことをするなら、ここまで書いてきたとおり、編集者以下の専用ユーザーにします。認証なしでこの窓口を呼ぶと、WordPressが拒否(401)することも確認しています。
よくある質問
Q. AIに管理者の権限を渡すと何が危ないのですか?
AIは渡された権限の範囲で実際に動きます。管理者の権限があれば、記事の削除、プラグインの停止や追加、ユーザーの作成まで、理屈の上ではすべてできてしまいます。頼んだ内容の解釈違いや、読み込んだページに仕込まれた指示(プロンプトインジェクション)で、意図しない操作が起きる可能性があります。
Q. アプリケーションパスワードとは何ですか?
WordPressのログインパスワードとは別に、外部のプログラム専用に発行できるパスワードです。ユーザー編集画面から用途ごとに発行し、1つずつ取り消せます。取り消しても普段のログインには影響しません。
Q. MCPを使わず、REST APIで自動化するのとどちらが安全ですか?
どちらも、使うアカウントの権限の範囲で動く点は同じです。違いは、REST APIは人が書いたプログラムが決まった処理をするのに対し、MCPはAIが使う操作を選ぶことです。MCPでは、公開する操作を列挙して絞れるのが強みです。どちらを使う場合も、この記事の5つを決めてから始めてください。
Q. 本番サイトでいきなり試してもよいですか?
おすすめしません。まず本番サイトのコピーやローカル環境で、読み取りの操作だけを試してください。当社も検証はすべて本番のコピーで行いました。
AIにサイトを操作させる設計から相談したい方へ
AIにWordPressを操作させるのは、もう難しいことではありません。難しいのは、何を任せて、何を任せないかを決めることです。当社はWordPress専門のエンジニアとして、MCPやREST APIを使ったサイト連携と、AIが処理して人が最後に確認する業務の自動化を、権限の設計から実装しています。「うちのサイトでAIに何をさせてよいか」から、お気軽にご相談ください。
▶ AI業務自動化・AIシステム開発の詳細を見る(相談無料)
更新履歴
- 2026年9月28日:作成(当社の運用の点検結果と、ローカル環境での検証にもとづく)