AIにWordPress記事を公開させる手順｜バックアップからHTTP・表示確認まで

バックアップ、人による記事確認、パソコンとスマートフォンでの公開確認を順番に行うイラスト AIサイト管理
2026.08.16

CodexやClaude CodeにWordPress記事の登録を頼み、「公開しました」と報告されたら作業完了でしょうか。

実際には、公開操作は工程の中間です。変更前に戻せる状態を作り、下書きを人が確認し、公開後のページが正常に応答するか、本文や画像が意図どおり表示されるかまで確認して、初めて完了と判断できます。

この記事では、バックアップ → 下書き → 人の承認 → 公開 → HTTP確認 → 画面確認を一つの流れとして解説します。コマンド例は架空環境用です。契約中のサーバーや保守担当者の手順を優先してください。

最初に決める三つの境界

AIへ依頼する前に、作業を三段階へ分けます。

  1. AIだけで進めてよい：原稿確認、リンク調査、下書き登録、読み取り確認
  2. 人の承認後に進めてよい：本番公開、既存記事の更新
  3. AIだけでは進めない：削除、データベース操作、サーバー更新、復元

「記事を追加して」とだけ依頼すると、下書きまでなのか本番公開までなのかが曖昧です。対象記事、公開範囲、停止条件、確認項目も伝えます。

全体の流れ

対象サイトと記事を確認
  ↓
バックアップを取得・検証
  ↓
記事を下書きで1件登録
  ↓
人が内容と公開条件を承認
  ↓
対象IDを指定して公開
  ↓
WordPress上の状態を確認
  ↓
HTTP応答・本文・画像・リンク・スマホ表示を確認
  ↓
結果と未確認事項を記録

途中で失敗したら、次の操作を重ねず、その段階で止めます。

1. 対象サイトと変更内容を固定する

最初にAIへ、次の情報を整理させます。

  • 対象サイトと、本番かテスト環境か
  • 新規記事か既存記事の更新か
  • タイトル、slug、description
  • 本文の正本となるファイル
  • カテゴリ、タグ、アイキャッチ
  • 下書きまでか、承認後に公開するか
  • 公開後に確認するURL

秘密情報やサーバー内部の設定値をAIの回答に表示させる必要はありません。「対象を確認した」と「接続情報を全文表示する」は別です。

2. バックアップを取得して検証する

バックアップは、ファイルが一つ作られただけでは成功と判断できません。少なくとも次を確認します。

  • バックアップ処理が正常終了した
  • データベースと必要なファイルが含まれる
  • アーカイブを読み取れる
  • チェックサムなどで破損を検出できる
  • 保存先と取得時刻が分かる
  • 復元手順と担当者が決まっている

記事の新規公開だけならWordPressのリビジョンやゴミ箱で戻せる場合もあります。しかし、画像、カテゴリ、メニュー、テーマを同時に変更すると、記事だけを戻しても元の表示へ戻らないことがあります。変更対象に合ったバックアップが必要です。

バックアップが失敗したら

失敗後に同じ公開コマンドを何度も実行しません。まず、不完全なバックアップが残っていないか、直近の検証済みバックアップがあるかを確認します。

  • DB移行、削除、WordPress本体・テーマ・プラグイン更新：正常な最新バックアップなしでは進めない
  • 新規下書きなど容易に取り消せる操作：担当者が影響と復旧方法を確認して判断する
  • 原因が不明、または既存バックアップを検証できない：作業を止める

「バックアップに失敗したが続けました」だけで済ませず、続行できる理由と戻し方を記録します。

3. 最初は下書きで一件だけ登録する

WP-CLIのwp post createでは、投稿状態を指定できます。最初はdraftへ固定し、一件だけ登録します。

wp post create article.md \
  --post_type=post \
  --post_status=draft \
  --post_title="記事タイトル" \
  --post_name="example-article" \
  --porcelain

これは仕組みを示す例であり、そのまま本番へ貼り付けるコマンドではありません。実運用では、制限付きラッパーを通し、投稿形式、状態、件数、本文ファイルの場所、カテゴリ候補を固定します。

--porcelainなどで得た投稿IDは、以後の確認対象として記録します。タイトル検索だけで対象を選ぶと、同名記事を誤って更新する可能性があります。

4. 人が下書きを確認する

AIは次の項目を機械的に点検できますが、最終判断は人が行います。

  • タイトルと検索意図が一致している
  • descriptionが本文を正しく要約している
  • 見出しの順番と結論が分かりやすい
  • 事実、料金、仕様、日付に確認元がある
  • 内部リンクと外部リンクの行き先が正しい
  • カテゴリ、タグ、投稿者が正しい
  • アイキャッチと代替テキストが内容に合う
  • 個人情報、認証情報、内部パスが含まれない
  • 実体験のないことを体験談として書いていない

管理画面のプレビューも開き、Markdown、表、コード、画像が崩れていないか確認します。この段階では公開URLがHTTP 200になるとは限りません。

分類と画像をWP-CLIで設定する具体的な手順は、カテゴリ・タグ・アイキャッチを安全に設定する方法で解説しています。

5. 公開承認を具体的に伝える

人が確認したら、対象IDと許可する操作を限定して承認します。

下書きの投稿ID 123を確認しました。
この1件だけを公開してください。

タイトル、slug、本文、カテゴリ、タグ、画像は変更しないでください。
他の記事、プラグイン、テーマ、設定には触れないでください。
公開後はWordPress上の状態と公開URLを報告し、
HTTP応答と画面表示を確認してください。

「OK」「公開して」だけより、対象と変更しない範囲が明確です。

6. 投稿IDを指定して公開する

WP-CLIでは、対象の投稿IDに対して投稿状態をpublishへ変更できます。

wp post update 123 --post_status=publish

自由なWP-CLIをAIへ渡すのではなく、「承認済みIDを一件だけ公開する」専用処理にします。処理側では、公開前に現在の状態がdraftであることも確認します。すでに公開済み、IDが存在しない、投稿タイプが違う場合は止めます。

7. WordPress内部の状態を確認する

公開コマンドの終了コードが0でも、別の記事を対象にしていた可能性があります。投稿ID、状態、slug、タイトルを読み直します。

wp post get 123 \
  --fields=ID,post_title,post_name,post_status \
  --format=json

期待する投稿ID、slug、publishが一致しているか確認します。投稿者、カテゴリ、アイキャッチ、descriptionも別途確認します。

8. 公開URLのHTTP応答を確認する

次に、閲覧者がアクセスするHTTPSのURLを外側から確認します。

curl --location --silent --show-error \
  --output /dev/null \
  --write-out '%{http_code}\n' \
  https://example.com/example-article/

--locationは転送先をたどり、--write-outのhttp_codeは最終応答コードを表示します。自動処理で4xx・5xxを失敗として扱う場合は、利用中のcurlの仕様を確認して--failまたは--fail-with-bodyを組み合わせます。

確認するのは記事だけではありません。

  • 公開記事：HTTP 200で応答する
  • トップページ：公開後もHTTP 200で応答する
  • カテゴリページ：記事が意図した分類に表示される
  • 内部リンク：リンク先が404にならない
  • 転送：意図しないURLへ移動していない

HTTP 200は「ページを受信できた」という確認であり、正しい記事が美しく表示された証明ではありません。

9. パソコンとスマートフォンで画面を確認する

最後に実際の画面を確認します。

  • タイトル、見出し、段落、箇条書きが崩れていない
  • アイキャッチと本文画像が表示される
  • 表やコードが画面からはみ出さない
  • 内部リンク、外部リンク、予約リンクを開ける
  • ヘッダーとフッターを操作できる
  • スマートフォンで文字やボタンが小さすぎない
  • キャッシュのため古い内容が残っていない
  • 意図しない新着欄やカテゴリへ表示されていない

予約フォームや問い合わせフォームに関係する変更では、送信や決済のテスト方法を施設側と決めます。実在する宿泊者の情報や本物のカード情報で試してはいけません。

完了報告に含めるもの

AIからの報告は「終わりました」だけでなく、次の形にします。

公開結果
- 対象：投稿ID 123、example-article
- バックアップ：取得・整合性確認済み
- 公開状態：publishを確認
- 公開URL：HTTP 200
- 確認済み：本文、アイキャッチ、description、カテゴリ、内部リンク
- 表示確認：PC幅、スマートフォン幅
- 変更していないもの：他の記事、テーマ、プラグイン、設定
- 未確認事項：予約フォームの実送信

未確認事項を隠さないことが重要です。「確認していない」と「問題がない」は同じではありません。

コピペで使える一連の依頼文

この記事をWordPressへ追加してください。

作業順：
1. 対象サイトと変更内容を整理する
2. 変更前バックアップを取得し、整合性を確認する
3. 新規記事を下書きで1件だけ登録する
4. 投稿IDとプレビュー方法を報告して停止する
5. 私の公開承認後、その投稿IDだけを公開する
6. WordPress上の状態を読み直す
7. 公開記事、トップ、カテゴリのHTTP応答を確認する
8. PC幅とスマートフォン幅で表示を確認する

禁止事項：
- 他の記事の変更
- 削除、DB操作、テーマ・プラグイン・サーバーの更新
- 秘密情報や内部設定値の表示
- バックアップ失敗時の無断続行

最後に、確認済み項目、変更していない範囲、
未確認事項を分けて報告してください。

この依頼文だけで技術的な権限は制限されません。AGENTS.md・CLAUDE.md、専用ユーザー、制限付きラッパー、承認工程と組み合わせます。

まとめ

AIを使った記事公開では、速く投稿することより、対象を一件に固定し、途中で止まれる工程にすることが重要です。

バックアップを検証し、下書きを人が承認し、公開後にWordPress内部と外部HTTPの両方を確認します。さらにパソコンとスマートフォンで本文、画像、リンクを見て、未確認事項を残して完了報告します。

初めてWP-CLIを使う方はWP-CLIの基礎と安全な始め方から、実行できる操作を技術的に絞りたい方は制限付きラッパーの作り方から確認してください。記事一覧は宿主さん向けWeb運営ガイドにまとめています。

公開後の確認項目を、15分で実施できる形にまとめた記事は、WordPress公開後の確認方法｜HTTP・SEO・スマホ表示チェックリストです。

参考資料

※バックアップ、復元、SSH、WordPressの権限設計は環境ごとに異なります。契約先や保守担当者の案内を優先し、復旧方法を確認できない変更は実行しないでください。

タイトルとURLをコピーしました