オートポスト支社 評価スコアページ用 cron標準 起動命令文集 v5（2026-05-17）

0-A〜10運用で使うheartbeatスレッド立ち上げ文の最新版。

今回の反映点

• 全記事共通の冒頭構成Gateを追加。
• ThinkMarkets型のH1、評価スコア表、リード文、右寄せ公式テキストリンク、最初のH2を固定。
• 改善担当ハンドオフ枠（9-A/9-B/10）を追加。
• 外部AI未整備時はCodex別スレッド/専門タスクへ渡せるように整理。
• handed_offかつlock中の本文を返却前に主観リライトしないルールを追加。
• ローカルSQLite不存在だけで止まらないMain Hub優先運用を明記。

heartbeatの前提

• 1スレッドにheartbeatは1つだけ。複数の厳密な時刻を1本に詰め込まない。
• 複数時刻が必要な場合は複数スレッドに分けるか、開始時刻から一定間隔で近似する。
• 制作、高品質テスト、訂正、改善担当ハンドオフは別スレッドに分けるのが基本。
• 各サイト別テンプレート記事の各項目にある「新スレ起動文」を、まず新規スレッドの冒頭へ貼る。
• automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形にする。

automation命名ルール

共通Gate

• Main Hubを正本にする。Standby Hubはreadonly、Googleスプレッドシート/Apps Script/Google承認には戻らない。
• ローカルPC内の storage/data/358-hub.sqlite が無いだけで止まらない。Main Hub Web、agent_pack、Work Queue、References、FactChecks、hub_table_upsert相当の利用可能手段を優先する。
• 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は表示しない。
• 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。承認が出にくい安全な書き込み手段を使う。
• PHP/JS/CSS等の本番コード編集、ファイル削除、移動、上書き、外部公開先の新規追加、認証情報、権限変更は停止して確認する。
• 公開投稿そのものは停止条件ではない。止めるのは未承認、未検査、危険操作、GATE失敗の場合だけ。
• 0-A/0-Bなどの棚処理は複数候補を扱ってよい。1回1記事制限は制作cron、高品質テストcron、訂正cron、改善担当ハンドオフcronに適用する。
• automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` の形で登録する。
• 各cronを作る時は、対象レポート記事の各項目にある新スレ起動文を先に貼り、専用スレッドとして状態復元してからautomationを作成する。
• Main Hubが401/403/invalid token/token expired/timeout/DNS/network error等で読めない場合、その回は対象なし、FAILなし、PASS、完了と判断しない。必ず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
• Hub正本を読めない状態で、公開、修正、301、Hub更新、PASS/FAIL確定を行わない。
• 全評価ページ共通で、冒頭はH1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2の順にする。
• 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンクにする。
• 公式テキストリンクはPC表示で本文右側または右寄せに置く。読者が本文導線として見つけられる位置にする。
• 参照例は https://invest358.com/ja/thinkmarkets-review/ とする。完全コピーではなく、冒頭構成と導線を継承する。
• H1重複、H1へのSEOタイトル混入、評価表の順序崩れ、公式リンク漏れ、コード露出、言語不一致はFAIL。
• 日本語ページは常体を基本にする。ただし偉そうにせず、落ち着いた説明文にする。対象ページの言語に合わせて基本表/補足情報も同じ言語で書く。
• 装飾は既存良質記事を継承する。太字、太字+黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックスを必要箇所へ自然に入れる。
• 9-Aで文章QA/共起語改善候補を抽出し、9-Bで改善担当へ渡し、10で返却反映と硬いGate確認を行う。
• improvement_status、improvement_owner、improvement_lockを記録する。handed_offかつlock中の本文を返却前に主観リライトしない。

立ち上げ文

制作cron

コピー

制作cronを作成してください。

起動時間: 1スレッドにheartbeatは1つだけなので、指定時刻を複数列挙せず、開始時刻から一定間隔で近似起動してください。3記事/日なら約8時間ごと、porn-fun移行10記事/日なら約2時間ごとを目安にしてください。

役割: 0-B/1-A/1-Bを通過して制作readyになった棚から、1回1記事だけ本流制作する。0-Aから10までを丁寧に進めるが、外部公開や認証情報など停止条件だけ止める。

必須Gate: H1→評価スコア表→リード文→右寄せ公式テキストリンク→最初のH2。装飾Gate、常体、言語一致、公式根拠、apply_patch不使用。出力は対象記事、進捗、PASS/FAIL、次に渡したキュー。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

高品質テストcron

コピー

高品質テストcronを作成してください。

起動時間: 制作cronより後ろの時間帯で、1スレッド1heartbeatとして一定間隔起動にしてください。

役割: 制作済み記事を1回1記事だけ確認する。H1、SEO、冒頭構成、Directory Core、構造化データ、公式リンク、装飾、言語、公開HTMLを確認し、PASS/FAILを記録する。不備があれば訂正cronまたは10へ送る。過去記事の不備を見つけた場合もFAIL候補として拾うが、その場で雑に全件修正しない。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

訂正cron

コピー

訂正cronを作成してください。

起動時間: 夜または低負荷帯に1日1回から数回。FAILキューがある場合だけ動き、対象がなければ短く報告して終了してください。

役割: FAILになった記事を1回1記事だけ修正する。修正後は公開HTMLで再確認し、H1重複、コード露出、公式で要確認などの仮置き、言語不一致、評価表漏れを残さない。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

改善担当ハンドオフcron

コピー

改善担当ハンドオフcronを作成してください。

起動時間: 公開QA後の夜帯または1日1回。外部AIが無い場合はCodex別スレッドまたはCodex専門タスクへ渡してください。

役割: 9-Aで見出し単位の文章品質、共起語、読みやすさ改善候補をまとめ、9-Bで improvement_owner と improvement_lock を設定して渡す。handed_offかつlock中は、返却されるまで本文を主観的に書き直さない。10で返却分を反映し、硬いGateだけ確認する。

全評価ページ共通 / task10・8・9-A/9-B 訂正対象取得Gate（2026-05-17追記）:
- `task10/FAILキュー` という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの `use_status=correction_queue`、`public_qa_handoff`、`quality_fail`、`correction_required`、または `check_status=ready/fail/failed` を訂正対象として見る。
- FactChecksの `fact_check_id`、`check_status`、`notes` に `fail` / `FAIL` / `Gate failed` / `Gate失敗` / `要修正` があるものを拾う。
- workflow共通の `article_key` だけに限定せず、記事別key、slug別key、移行記事keyも同じsite/workflow/domain内なら拾う。
- agent_packに他サイトのFAILが混在して見える場合は、対象site / workflow / domain / article_typeで絞り込み、別サイトのFAILを自分の訂正対象にしない。
- 上記を確認せずに「FAILキュー0件」「対象なし」「記事修正なし」「301対応なし」「PASS/完了」と報告しない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず `BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。

全評価ページ共通 / 公開本文境界Gate（2026-05-17追記）:
- 公開本文には、読者のサービス判断に必要な情報だけを書く。
- 301、リダイレクト、旧URL、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、References、FactChecks、agent_pack、heartbeat、cron、automation、タスク番号、制作パック、台帳、作業ログを本文に書かない。
- 「この制作cronでは301を実行しない」「別工程で旧URLからの301を扱う」「辞書記事では整理する」など、作業工程の説明を本文に出さない。
- これらは内部ログ、Hub、台帳、QA記録にだけ残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 本文・見出し・表・FAQ・CTA周辺に内部運用語があればFAILとし、公開継続または301実行前に修正する。

全評価ページ共通 / 検索意図・上位傾向・共起語整理Gate（2026-05-17追記）:
- 公式情報と参照URL検証が終わった後、1-C記事制作パック前に `1-B2 検索意図・上位傾向・共起語整理` を行う。
- 整理するものは、読者の主要検索意図、上位記事でよく扱われる論点、自然に使えそうな共起語、使わない語、H2/H3・評価表・FAQ・リード文への反映案。
- 共起語は本文へ機械的に詰め込むノルマではない。読者理解を助ける範囲で自然に使う。
- 公式情報と矛盾する上位傾向、サービス内容と関係が薄い語、根拠不足の語は採用しない。
- 1-C制作パックには「自然使用候補」「使わない語」「構成への反映案」を分けて残す。
- 8高品質テストと9-A改善候補抽出では、このメモを見て「不足」「過剰」「不自然な詰め込み」「無関係語の混入」を確認する。

Task10本文修正・終了状態Gate（2026-05-17追加）:
- FAIL原因が本文、FAQ、冒頭構成にある場合、第一手はWordPress本文修正にする。
- Cocoon設定、page_type、テーマ設定、広告/PR表示設定などの設定側変更は補助手段。H1重複、表示崩れ、評価表欠落、本文順序崩れのリスクが出た時点で撤回し、本文修正ルートへ戻る。
- 設定側を触って失敗しただけで本文修正せずに終了しない。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。例: 「旧記事から301してよいか」「この制作cronでは301を実行しない」「公開QAが通ったあと」は削除対象。
- 冒頭順を H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLでH1重複、コード露出、内部作業語、評価表、公式リンク、canonical、noindexを再確認する。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 1回のcronでは1記事だけ処理する。同じ失敗ルートを繰り返さない。
- 作業は必ず PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかで終了する。ローディングし続けない。

評価項目本文化・FAQ qa-box・装飾バランスGate（2026-05-17追加）:
- 評価スコア表の各項目は、本文内でH2またはH3見出しとして扱い、スコア理由、読者が確認すべき点、向いている人/注意点を書く。表だけで終わらせない。
- 評価項目名と本文見出し名は、完全一致または読者が同じ項目だと分かる名前にする。評価項目の説明が無い場合は本文ボリューム不足としてFAIL。
- 本文FAQは `<details class="qa-box"><summary>質問文</summary><div class="qa-answer">回答文</div></details>` を標準にする。
- FAQPage JSON-LDは `Schema & Structured Data for WP & AMP` 用に作成し、本文FAQと質問文・回答内容を一致させる。JSON-LDだけあり本文FAQが無い、または本文FAQがqa-boxでない場合はFAIL。
- FAQには、旧記事、301、公開QA、Hub、heartbeat、cron、Gate、PASS/FAILなど内部作業設問を入れない。
- 装飾は太字、黄色アンダー、赤太字、✅、⚠️、Cocoon系ボックス、リストをバランスよく使い分ける。
- `<li>` の先頭へ毎回✅/⚠️を付けない。リスト記号とアイコンの二重信号で読みづらい場合はFAIL。
- `information-box` / `warning-box` / `blank-box` などボックス自体が意味を持つ場合、原則として✅/⚠️を重ねない。必要な場合だけ最小限にする。
- ✅/⚠️だけを使う箇所、リストを使う箇所、ボックスを使う箇所を分ける。装飾不足も過剰装飾もFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、評価項目本文見出し不足、qa-box FAQ不足、装飾バランス不備として訂正対象。

全評価ページ共通 / ✅・⚠️優先装飾Gate（2026-05-17追加）:
- 強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み/向いている人/判断しやすい利点、⚠️は注意点/向いていない人/確認が必要な条件/制約に使う。
- 1文で伝わる強み/注意点は `<p>✅ ...</p>` / `<p>⚠️ ...</p>` のような単独文を優先する。
- 複数条件を並列整理するときは`<ul><li>`を使ってよいが、各`li`先頭へ毎回✅/⚠️を付けない。
- `information-box` / `warning-box` / `blank-box`などボックス自体が意味を持つ場合、ボックス内へ✅/⚠️を機械的に重ねない。
- 評価ページで✅/⚠️が0件のまま、強みや注意点をすべて普通の`li`やボックスだけで処理している場合は装飾不足としてFAIL。
- 既知の検出必須例: https://porn-fun.com/sites/fc2-live-adult-review/ は、qa-boxは改善済みだが✅/⚠️が0件のため訂正対象。

全サイト共通 / 1-C〜7制作完了→8高品質テスト引き渡しGate（2026-05-17追加）:
- 1-C〜7で記事を公開したら、公開URLを作っただけで終わらず、同じarticle_keyで task_code=8 / use_status=public_qa_handoff / check_status=ready / status=active のReferencesを必ず作る。
- 8高品質テストは、public_qa_handoffだけでなく、use_status=published_directory_article / task_code=7 / 公開済み新記事URLも横断して確認する。
- 同じarticle_keyにtask8 PASSまたはtask8 high-quality test完了記録が無い公開済み記事を「未処理対象なし」と扱わない。
- 7の公開HTML QA PASS、Directory Core入力PASS、published_directory_articleがあるのに8のPASSが無い場合は、明示ハンドオフ漏れとして8対象にする。
- Hub認証不備時は対象なし/PASS/完了と誤判定せず、BLOCKED_HUB_AUTHとして終了する。
- 既知の補正例: https://porn-fun.com/sites/hey-douga-review/ は1-C〜7で公開済みだが、8用の明示的ハンドオフが弱かったため、public_qa_handoffを追加して8対象に戻した。

cron標準 / サイト別1スレッド運用（2026-05-17追加）:
- オートポスト支社の通常運用はcron標準。heartbeatは例外運用に限る。
- 1サイトまたは1セットにつき、関連cronを依頼・管理する起動スレッドは1つだけにする。
- 各タスクごとの新スレッド立ち上げ文は不要。各タスク欄のコピー文は、そのサイト別cron統括スレッド内で使うcron作成依頼文として扱う。
- automation名は `【サイト名＋評価スコアページ種別】タスク順番 cron 内容` を標準にする。
- 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- heartbeatは、ユーザーと同じスレッドで短時間だけ追跡する場合、手動確認が必要な一時作業、緊急修正、外部AI/改善担当との会話型ハンドオフが必要な場合だけ使う。

cron個別作成Gate:
- サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
- 統括スレッド起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。

評価スコアページ用cron命名Gate:
このcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
automation名には必ず「評価スコアページ」を入れる。
例:
- 【AIfunIO評価スコアページ】0-A cron 候補収集
- 【Nightlife夜遊び店舗評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
- 【Nightlifeホテル評価スコアページ】8 cron 高品質テスト
- 【porn-fun単体サービス評価スコアページ移行】11 cron 301実行・リダイレクト確認
まとめ/ランキング/比較/通常/速報記事用のautomationは別命名・別テンプレートにする。

Report Privacy Gate

このレポートには認証値、APIキー、パスワード、トークン、WordPress REST認証情報、個人ローカルパスの中身を含めない。

updated: 2026-05-17 17:41:52 JST / CODE-YUKI