WordPressへ下書きを保存できても、公開してよいとは限りません。画像が欠けていないかは機械で調べられますが、体験と本文が一致するか、読者に誤解を与えないかは人が読む必要があります。

この回では、公開前レビューを「検査」と「判断」に分けます。検査結果は人が見る場所を絞るために使い、総合点だけで公開可否を決めません。

レビュー対象の版を先に固定する

WordPress下書きをAIがReviewし人間が確認して承認待ちで止める公開前フロー

最初に、どの下書きを確認するのかを一意にします。タイトルだけでは似た記事を取り違えるため、WordPress投稿ID、原稿ファイル、更新時刻、必要なら本文ハッシュを組にします。

レビュー中に本文が変わったら、古い結果を流用しません。修正後の版へ対象を更新し、影響する検査をやり直します。「レビュー済み」というラベルより、何をレビューしたかの証拠が重要です。

機械検査は明確な条件を確かめる

自動処理に向くのは、期待値と実測値を比較できる項目です。

  • H2・H3の階層と本文内H1の重複
  • 内部・外部リンクのURLと応答
  • 非装飾画像のalt空欄
  • featured imageと本文画像の重複
  • 画像形式、寸法、ファイルの有無
  • front matterの必須項目とシリーズ前後ID
  • 秘密情報らしい文字列、編集メモ、禁止表現

結果は「合格」「不合格」だけでなく、対象箇所、検査方法、実測値を残します。たとえば「画像に問題あり」ではなく、「本文3枚目のaltが空欄」と示せば、人がすぐ直せます。

AIは意味上の問題を候補として示す

AIは、同じ説明の反復、根拠のない数値、古い可能性がある仕様、強すぎる断定などを見つける補助に使えます。ただし、これらは機械的に真偽を確定できないため「要確認候補」です。

AIが問題なしと判定しても、事実の正しさは保証されません。反対に、独自の言い回しを異常と判断することもあります。指摘には該当文と理由を添え、人が採用・却下・保留を決めます。

人は意味、根拠、公開責任を判断する

人のレビューでは、文章の表面より、公開後に読者へ与える意味を見ます。

  1. タイトルの約束を本文が果たしているか
  2. 実体験と調査結果を区別しているか
  3. 変動仕様を確認日現在の公式資料で確かめたか
  4. 未確認の成功、数字、操作を作っていないか
  5. 読者が危険な操作や誤った判断へ進まないか
  6. 現在のサイト構成や前後記事と矛盾しないか

誤字1件と、根拠不明の重要事実1件は同じ重さではありません。点数が高くても重要事実を確認できなければ止め、軽微な体裁指摘だけなら修正範囲を限定します。

指摘には状態と処置を付ける

レビュー項目は、修正の行方が分かる形にします。

状態 意味 次の処置
confirmed 問題を確認した 修正して再検査
needs_check 根拠または判断が不足 人が資料・実画面を確認
accepted 意図した表現・既知の制約 理由を記録して維持
resolved 修正と再確認が完了 承認資料へ結果を反映
blocked 公開条件を満たせない 公開工程へ渡さない

単に指摘数をゼロにすることが目的ではありません。却下した指摘にも理由を残すと、同じ論点を次のレビューで繰り返さずに済みます。

承認資料は判断に必要な情報へ絞る

レビュー後は、長い実行ログをそのまま承認者へ渡しません。承認資料には次をまとめます。

  • 対象記事とレビューした版
  • WordPress下書きの確認先
  • 検査の実行結果
  • 人が確認した重要項目
  • 残っている要確認事項
  • 修正前後の差分
  • 推奨する処置と、その理由

MANABU WORK LABでは、Review結果と下書きをまとめる承認資料を作成し、承認待ちを追跡できる形を検証しました。ここでの目的は自動採点ではなく、人が短時間で本文と証拠へ戻れることです。

承認待ちは正常な停止地点

検査に通っても、そのまま予約・公開へ進めません。人の判断が返るまで、WordPressは下書きのままにします。

修正が必要なら記事制作へ戻し、公開を見送るなら止めます。問題がなければ、対象版を明示して承認します。下書き作成、機械検査、人の承認は、それぞれ別の完了条件を持つ工程です。

次の記事ID 136では、この承認待ちに対する人の意思をGmailから受け取り、別の記事や古い版を承認しないための照合を扱います。

公式資料と確認日