Gmail承認の役割は、メール返信だけでWordPressを公開することではありません。人が下書きとレビュー結果を見て返した意思を、正しい記事の正しい版へ記録することです。
MANABU WORK LABでは、本番環境で承認依頼を送り、同じスレッドへ人が「OK」と返信するところまで試しました。しかし承認は成立しませんでした。照合でSecretと承認対象版の不一致を検知し、WordPressを下書きのまま止めたためです。旧記事182の失敗記録を、本記事の設計根拠として必要な範囲に統合します。
承認メールは判断資料への入口にする
メール本文には、承認者が元の資料へ戻れる情報を置きます。
- 記事タイトルとWordPress下書き
- レビューした版を示す情報
- 重要な指摘と未確認事項
- 返せる判断の種類
- 承認の期限または失効条件
返答は「承認」「修正」「見送り」を区別できれば十分です。公開日時の指定が書かれていても、この工程では希望として保存するだけにします。空き枠の計算やWordPressの予約更新は記事ID 202の役割です。
返信を一つの手掛かりだけで採用しない
「OK」という本文だけでは、どの記事への返答か分かりません。送信者だけを見ても、同じ承認者が別の記事へ返信している可能性があります。
承認処理では、少なくとも次を組み合わせます。
- 送信者が許可された承認者か
- 返信が承認依頼と同じGmailスレッドにあるか
- 対象TaskとWordPress投稿IDが一致するか
- Taskが承認待ちの状態か
- レビュー対象と現在の本文が同じ版か
- 承認用の識別値が対象記事のものか
- 同じ返信を処理済みではないか
- 返信内容を既知の判断へ分類できるか
Gmail APIでは返信を同一会話として扱うthread情報を取得できます。ただし、同じthreadであることだけを本人確認や版確認の代わりにはしません。
本番テストでは承認成立前に止まった
統合元の記事182で確認できた範囲は次のとおりです。
| 項目 | 結果 |
|---|---|
| WordPressの専用テスト下書き | 確認 |
| AI Reviewとの対応 | 確認 |
| 実Gmail承認メールの送信 | 成功 |
| 人による同一threadへのOK返信 | 確認 |
| Approval Checkerの実行 | 実施 |
| Secretと対象版の照合 | 不一致 |
| Taskへのapproved保存 | 未成立 |
| 予約・公開 | 未実行 |
結果を「メール承認に成功」とは扱いません。成功したのは送受信までであり、承認処理は不一致を検知して停止しました。公開中の記事への変更はなく、対象のWordPress投稿も下書きのままでした。
失敗から三つの設計を直した
一つ目は、承認用Secretを記事単位に分けることです。登録後に実値を読み戻せないSecret Storeへ複数記事分を一つのJSONで保存すると、安全な追記が難しくなります。記事ごとに分離すれば、別記事の値を壊さず更新できます。
二つ目は、古い承認依頼を失効させることです。新しい依頼を発行したら、旧message、旧thread、旧返信はstaleとして承認対象から外します。処理が再開しても、過去の「OK」を現在の意思として再利用しません。
三つ目は、承認対象本文の版を固定することです。依頼時の本文から正規化したハッシュを保存し、承認時の本文と比較します。メール送信後に本文が変わっていれば、同じタイトルでも承認を成立させません。
状態更新とWordPress更新を分離する
照合に通った返信が変えるのは、記事管理データの承認状態までです。
- 承認：対象版を
approvedとして記録 - 修正：
revisionとして制作工程へ戻す - 見送り：
rejectedとして停止 - 不明：状態を変えず、人の確認を求める
ここでWordPressを publish や future へ変更しません。承認は内容に対する意思、予約は公開日時と対象を更新する操作で、失敗原因も責任も違うからです。
不一致は自動修復せず証拠を残す
照合が一つでも欠けた場合、最も都合のよい返信や記事を推測して進めません。次の情報を秘密を含めない形で記録します。
- 確認時刻
- 対象TaskとWordPress投稿ID
- 一致した条件と一致しなかった条件
- 返信のmessage IDとthread ID
- 承認対象版の識別情報
- 最後に成功した工程
- WordPressが下書きのままであること
Token、アプリパスワード、OAuth認証情報、個人のメールアドレスはログへ出しません。再試行する前に、現在のTaskとWordPressを読み直し、古い返信を再利用しない状態を作ります。
承認完了の条件を明文化する
承認完了と呼べるのは、許可された人の返信が、同じ依頼、同じ記事、同じ本文版に結び付き、未処理で、意味を一意に分類でき、その結果をTaskへ保存したときです。
メールを送れた、返信が届いた、Checkerが起動した、という個別の成功だけでは足りません。逆に、不一致で下書きのまま止まることは、運用上の失敗を広げない正常な安全動作です。
次の記事ID 202では、approved になった対象だけを空き枠へ予約します。予約時刻後の公開確認は、さらに分けて記事ID 212で扱います。
公式資料と確認日
- Gmail API「Manage threads」（2026-09-07確認）
- WordPress「Application Passwords」（2026-09-07確認）