オートポスト支社cronの中央指令・本社メンテ運用企画書

企画書: オートポスト支社cronの中央指令・本社メンテ運用

本企画書は、オートポスト支社の別PCで稼働するcronにエラーや指令不備が出た場合、本社PC側のCODE-YUKIが中央で修正し、別PC側のcronを作り直さずに次回実行から最新修正版を反映させるための運用案である。

現時点では企画・設計案であり、実装、cron差し替え、Hubテーブル追加、新サイト作成はまだ行わない。目視確認後に、段階を分けて着手する。

結論

本命は「358 Hubにcronごとの最新指令書を置き、別PC側cronは毎回Hubから最新版を取得して実行する」方式とする。

レポートサイトは企画書、運用説明、目視確認用の公開報告に使う。サブ・保険用のcron指令文置き場は、レポートサイトではなく、別途立ち上げる新サイトへ分離する。

基本構成

• Main Hub: 正本。cronごとの最新指令書、Rules、Manuals、Checks、TaskTemplates、Work Queue、References、FactChecksを置く。
• 別PC cron: 固定の短いローダーだけを持つ。長文指令や古い判断条件を抱え込まない。
• 本社PC CODE-YUKI: Hub側の指令書、Gate、エラー時分岐を修正する。
• 新サイト: サブ・保険用のcron指令文、ローダー仕様、緊急時の停止手順を保管する。秘密値は置かない。
• レポートサイト: 企画、方針、確認結果、代表確認用の公開報告だけに使う。

別PC cronの固定ローダー方針

別PC側のcronには、以下の最小ローダーだけを固定する。

1. cron起動
2. Main Hubを読む
3. 自分の cron_key に対応する最新CronInstructionを取得
4. Rules / Manuals / Checks / TaskTemplates / Work Queue / References / FactChecksを取得
5. 取得した最新版で実行
6. 結果、エラー、BLOCKED状態をHubへ返す

この形にすると、たとえば「Task10の訂正対象取得元が間違っていた」「301の扱いを8から11へ分離したい」「公式情報プレースホルダーをFAILにしたい」といった修正を、本社YUKIがHub側の指令書に反映するだけで、別PC側cronは次回起動時から最新版で動ける。

Hubに置く指令書の単位

Hub側には、cronごとに以下のような指令書レコードを置く案とする。

cron_key
site
workflow_id
task_scope
instruction_version
status
body
required_rules
required_manuals
required_checks
blocked_conditions
max_items_per_run
updated_by
updated_at

cron_keyの例:

• aifunio-score-0a-candidates
• aifunio-score-10-correction
• nightlife-store-score-8-quality-test
• nightlife-hotel-score-1c-to-7-production
• porn-fun-score-10-correction
• porn-fun-score-11-redirect

認証エラー時の扱い

Hub認証とWordPress認証は、扱いを明確に分ける。

Hub認証が壊れてHubを読めない場合

cronは実行しない。対象なし、FAILなし、PASS、完了、公開、修正、301を判断しない。終了状態は BLOCKED_HUB_AUTH とし、本社YUKIへ戻す。

401 / 403 / invalid token / token expired / timeout / DNS / network error
→ BLOCKED_HUB_AUTH
→ 投稿・修正・301禁止
→ 本社YUKIがHubトークン、API、認証経路をメンテする

WordPress認証が切れている場合

Hubが読めるなら、対象記事、工程、失敗内容をHubへ記録する。ただしWordPressへの投稿、本文更新、Directory Core入力、FAQ反映、301は行わない。終了状態は BLOCKED_WP_AUTH とする。

Hub OK / WordPress NG
→ 対象特定と修正案作成は可
→ WordPress反映は禁止
→ BLOCKED_WP_AUTHとしてHubへ記録
→ 本社YUKIが認証・権限・アプリケーションパスワードをメンテする

サブ・保険用新サイトの役割

サブ・保険用のcron指令文保管サイトは、Main Hubの代替正本ではなく、以下の用途に限定する案とする。

• cronローダー仕様の保管。
• 標準cron指令文の読み取り用ミラー。
• Hub認証不備時に、cronがどう止まるべきかの緊急手順。
• 本社YUKIがHub復旧時に参照する保険資料。
• レポートサイトに置きにくいcron指令本文の集約。

ただし、Main Hubが読めない状態で、この保険サイトだけを根拠に公開、修正、301を進める運用は標準禁止とする。Hub正本を確認できない場合は、実行ではなく停止と本社返却を優先する。

エラー分類

• BLOCKED_HUB_AUTH: Hub認証、Hub API、ネットワーク不備。実行禁止。
• BLOCKED_WP_AUTH: WordPress認証・権限不備。Hub記録は可、WP反映は禁止。
• BLOCKED_RUNTIME: 別PCのPython、Node、依存関係、cron実行環境不備。
• BLOCKED_MISSING_TARGET: Hubに対象URL、post ID、article_keyが無い。
• BLOCKED_LAYOUT_RISK: 設定変更でH1重複、評価表欠落、表示崩れの危険がある。
• FAIL_REQUEUED: 修正したが公開HTMLでまだFAILが残り、次回再処理へ戻す。
• PASS: 公開HTML、Gate、Hub記録まで確認済み。

導入手順案

目視確認後、以下の順で小さく着手する。

1. Hub側にCronInstructions相当の台帳を追加する。
2. まず1本だけ、例としてporn-fun Task10訂正管理cronの指令書をHubへ登録する。
3. 別PC側cronをHubローダー型へ1本だけ差し替える。
4. Hub上の指令書を本社YUKIが1箇所修正し、次回cronが最新版を読むか確認する。
5. Hub認証NG、WordPress認証NG、対象なし、FAILあり、PASSの5パターンをTask Testで確認する。
6. 問題なければ、AIfunIO、Nightlife夜遊び店舗、Nightlifeホテル、porn-fun 11 cronへ広げる。
7. サブ・保険用新サイトを立ち上げ、cron指令文ミラーと緊急停止手順を集約する。

実装前の確認事項

• Hubを読めない時に、保険サイトだけで公開・修正・301を進めない方針でよいか。
• 最初の実験対象をporn-fun Task10訂正管理cronにするか。
• サブ・保険用新サイトはnoindex、読み取り専用、秘密値なしでよいか。
• cron名は評価スコアページ用標準名を継続するか。
• 別PC側の既存cronは一括差し替えせず、1本ずつHubローダー型へ移行するか。

Report Privacy Gate

本記事には、APIキー、パスワード、トークン、WordPress REST認証情報、Hub認証値、個人ローカルパス、管理画面URL、不要な個人情報を含めていない。公開本文は企画・運用方針に限定している。