WordPressのAI・API自動化セキュリティ｜誤公開を防ぐ10の実務対策

※本記事には広告・アフィリエイトリンクが含まれています。

WordPress自動化では、セキュリティというとWAFやログイン防御を思い浮かべがちです。しかしAPIやAI Agentを使うと、攻撃者がいなくても事故が起きます。slugの取り違え、再実行による二重投稿、古い情報の一括更新、テストdraftの誤公開などです。

僕自身、複数WordPressの更新を自動化する仕組みを作る際は、実行できる機能より「失敗したときに止まる条件」を先に置いています。公開処理を最後の独立ステップにする、対象post IDとslugが一致しなければ停止する、1件でもQAが落ちたらrollbackする、といった制約です。

アクセス権限と公開ゲート

1. readとwriteを別の権限・別の工程にする

投稿一覧を読む処理と本文を書き換える処理は、同じリスクではありません。最初はread-only credentialやAbilityで状態を取得し、writeが必要なジョブだけ別の権限を使うと、誤操作の影響を限定できます。

AI AgentへMCP toolを渡す場合も、検索・取得toolと更新toolを分離します。「記事を調べて改善して」という1つの指示だけでread→write→publishまで流れる経路を作るより、改善案の出力で一度止める方が監査しやすくなります。

2. draftとpublishを別ゲートにする

自動化で作る新規投稿はdraftを既定にします。公開は、本文文字数だけでなく、タイトル、meta、カテゴリ、タグ、featured image、ALT、内部リンク、禁止文字列、PR表記などを検査してから別操作で行います。

更新記事でも同じです。いったん本番記事へ上書きするのではなく、差分をpreviewできる設計やsnapshotを持つと安全です。公開ボタンは「作成処理の最後」ではなく、QA PASS後だけ有効になる独立した権限として扱います。

対象誤りと二重実行を防ぐ

3. 対象post ID・slug・statusを同時に照合する

タイトル検索だけで更新対象を決めると、似た記事名や過去記事を誤更新する可能性があります。既存記事はpost IDを正本にし、slugも期待値と一致するか確認します。更新前statusがpublishの想定なのかdraftの想定なのかもpreflightで固定します。

新規記事の場合は逆に、予定slugが既にpublish/draft/trashのどこかに存在しないか確認します。見つかった場合は「上書き」も「別slugで新規作成」も自動で選ばず停止する方が、カニバリと重複URLを防げます。

4. テスト用draftを公開対象から構造的に除外する

「タイトルにTESTがあれば除外」のような後付けfilterだけでは不十分です。公開処理は、事前に署名したmanifestや許可post ID一覧に載った投稿だけを対象にし、一覧外のdraftは件数に含めない設計が安全です。

この方式なら、WordPressに別用途のdraftが何十件あっても影響しません。僕自身も自動更新を組むときは、公開対象を特定slugや管理markerのホワイトリストだけに限定し、それ以外のdraftを探索して公開する経路を作らないようにしています。

5. 二重投稿は「再試行」の前に防ぐ

ネットワークtimeoutの直後に同じcreate requestを再送すると、最初の処理だけWordPress側で成功していた場合に重複投稿ができます。新規作成前にslug、外部job ID、独自metaなどで既作成を確認し、同じジョブが何度走っても結果が1つになるidempotentな設計へ寄せます。

画像も同様です。ファイル名だけでなくSHA-256等をmetaへ保存し、同じpackageから再実行したとき既存attachmentを再利用できるようにすると、メディアライブラリの重複を減らせます。

秘密情報とAI出力を安全に扱う

6. credentialはコード・HTML・ログへ出さない

Application PasswordやAI provider keyは、記事本文、pluginファイル、Gitリポジトリ、console logへ直接書かないようにします。必要な場所には環境変数やsecret管理機能から渡し、ログには連携名やcredential IDなど追跡用の識別子だけ残します。

「一時的なテストだから」と秘密情報をコードへ貼ると、そのファイルがZIPやbackupへ残ることがあります。漏えい対策は暗号化だけでなく、秘密情報がコピーされる場所を減らすことでもあります。

7. AI出力を命令としてそのまま実行しない

AIが「このpost IDを削除してください」と出力しても、その文字列自体を権限判定に使ってはいけません。tool引数は型・範囲・対象所有権をサーバー側で検証し、許可された操作だけに変換します。

外部WebページやメールなどをAIへ読ませる場合、コンテンツ内にAgentへの指示が紛れ込むprompt injectionも考慮します。外部情報を読んだ結果から、credential表示・plugin操作・公開・削除のような高権限toolへ直接つながらないよう、信頼境界を分けます。

復旧・監査・停止条件を先に作る

8. 変更前snapshotを「戻せる単位」で残す

rollbackはバックアップがあるだけでは足りません。1記事の更新失敗でサイト全体のDBを昨日へ戻すのは影響が大きすぎます。本文、title、excerpt、slug、status、taxonomy、SEO meta、featured imageなど、ジョブが触る範囲をsnapshotして個別に戻せる方が実用的です。

逆に、plugin/theme更新やDB migrationのように記事単位で戻せない処理は、サイトbackupやstagingを使うべきです。操作の粒度に合わせてrollbackの粒度も変えます。

9. 監査ログは「誰が・何を・なぜ・どう変えたか」まで残す

AIを使う場合は、全文promptを無期限に保存すればよいわけではありません。個人情報やcredentialが混ざる可能性があるため、監査に必要なmetadataと機密情報を分け、保存期間も決めます。

10. 停止条件を「障害後」ではなく先に決める

• 対象件数が予定より多い
• post ID/slug/statusが不一致
• 公式情報の確認日が期限切れ
• 画像/ALT/metaのいずれかが欠損
• 外部APIの応答形式が変わった
• 同じジョブで連続失敗が発生
• rollback自体が失敗した

自動化を安全にする最後のポイントは、続ける条件より止める条件を明文化することです。失敗を「AIが考えて回避」させるのではなく、想定外ならfail-closedで人へ返す方が、本番WordPressでは信頼性を作りやすくなります。

rollbackは手順だけでなく復元テストまで行う

backupやsnapshotが存在しても、実際に戻した経験がなければ本番事故時の復旧時間は読めません。stagingや検証用投稿で、本文・taxonomy・SEO meta・featured imageを変更し、snapshotから復元して差分が消えるところまで定期的に確認します。複数サイトなら1サイトだけ復元できるかも重要です。

復元テストでは「何分で戻せたか」も残します。自動化の範囲を広げる判断は成功率だけでなく、失敗したときに許容時間内で戻せるかを含めて行うと、公開事故の影響を小さくできます。

公式情報・参考資料

仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。

• https://developer.wordpress.org/advanced-administration/security/application-passwords/
• https://make.wordpress.org/core/2026/07/29/new-execution-lifecycle-filters-for-the-abilities-api-in-wordpress-7-1/
• https://make.wordpress.org/core/2026/08/04/a-unified-public-exposure-flag-for-abilities-in-wordpress-7-1/

あわせて読みたい

• Application Passwordの安全管理
• REST API自動化の実装順
• MCPと権限設計
• AIエージェントへ任せる範囲