Summary
この文書の要点
- 公開用データと業務DBの内部データを分ける。
- WordPressへの反映は差分同期とし、再実行できるようにする。
- 下書き、予約、公開、更新、削除を状態遷移として扱い、単発のPOSTで終わらせない。
- 外部ID、同期履歴、差分、失敗理由を保存し、再実行できるようにする。
どこが設計の難所か
業務システム側のデータをWordPressへ直接反映すると、内部項目が公開されたり、公開状態の管理が曖昧になったりします。API連携が失敗した時に、どこまで反映されたか分からない問題も起きます。
WordPressは公開表示に強い一方で、業務システムの正本ではない場合があります。どちらを正とするか、手動編集を許すか、公開前レビューを挟むかを決める必要があります。
WordPressへ外部システムから情報を流す場合、記事本文だけでなく、カテゴリ、タグ、アイキャッチ、公開日時、更新者、削除時の扱いが問題になります。API呼び出しが成功しても、CMS上の状態が期待通りとは限りません。
境界をどう切るか
業務システム側で公開用DTOを作り、WordPressには公開してよい項目だけを送ります。同期は全件上書きではなく、外部IDを使った作成・更新・非公開化として扱います。失敗時は同期ログから再実行します。
設計では、外部データを直接WordPressへ投げず、同期対象、変換結果、送信結果を分けます。外部側のレコードIDとWordPressのpost_idを対応付け、同じデータを再送しても重複投稿にならないようにします。
実装で効く細部
API連携では、投稿ID、外部ID、最終同期時刻、同期状態、エラー内容を保存します。WordPress側の下書き、公開、非公開と業務側の状態をマッピングし、本文生成はテンプレート化して差分をレビューしやすくします。
Laravelやバッチ側では、publish_jobs、publish_targets、publish_attemptsを持ち、payload_hashで差分を見ます。アイキャッチ画像はメディア登録と投稿紐付けを別ステップにし、途中失敗時にどこから再開できるかを明確にします。
- WordPress側のpost_idだけでなく、外部IDと同期バージョンを保存する。
- 公開前プレビュー、下書き更新、本公開を別のジョブ種別として扱う。
- API失敗時はレスポンス本文、HTTPステータス、対象IDを記録して再処理できるようにする。
壊れ方を観測する
検証では、API認証失敗、投稿作成後の更新失敗、手動編集との競合、削除ではなく非公開にするケースを確認します。同期先のURLやIDをログに残し、同じデータを再送しても二重投稿にならないことを見ます。
検証では、初回投稿、更新、画像差し替え、カテゴリ変更、削除、予約投稿を一通り確認します。WordPress側で手動編集された場合に、次回同期で上書きしてよい項目と保持する項目をテストに含めます。
捨てた選択肢とトレードオフ
API同期を厳密にすると、手動で自由に編集する運用とは相性が悪くなります。公開品質を重視する場合はWordPress側で最終編集を許し、業務データの自動更新範囲を限定する判断もあります。
WordPressを唯一の編集場所にすると運用は分かりやすくなりますが、外部システムとの整合性は取りづらくなります。外部から完全同期すると一貫性は上がりますが、CMS上の手動編集が制約されます。どちらを正とするかを先に決める必要があります。
現場に残す判断軸
WordPress連携は、投稿できることより同期の責任範囲が重要です。公開用データを分け、差分と再実行を前提にすることで、手作業より安全な公開フローを作れます。
WordPress REST API連携の設計では、投稿できるかより、同期状態を説明できるかが重要です。外部IDと履歴を持たせるだけで、再実行と復旧のしやすさが大きく変わります。
