- 2026-05-17追記: 検索意図・上位傾向・共起語整理Gate
- 2026-05-17追記: 公開本文境界Gate
- 2026-05-17追記: 訂正対象の取得元Gate
- 今回の反映点
- 共通前提
- 頻度まとめ
- 24時間スケジュール例
- コピー用依頼文
- AIfunIO用 収集cron
- AIfunIO用 検査cron
- AIfunIO用 制作cron
- AIfunIO用 高品質テストcron
- AIfunIO用 訂正cron
- AIfunIO用 改善担当ハンドオフcron
- Report Privacy Gate
- 2026-05-17追加: Task10本文修正・終了状態Gate
- 2026-05-17追加: 評価項目本文化・FAQ qa-box・装飾バランスGate
- 2026-05-17追加: ✅/⚠️優先装飾Gate
- 2026-05-17追加: 制作完了→高品質テスト引き渡しGate
- 2026-05-17追加: cron標準・サイト別1スレッド運用
- 2026-05-17追加: cron個別作成Gate
- 2026-05-17追加: 評価スコアページ用cron命名Gate
2026-05-17追記: 検索意図・上位傾向・共起語整理Gate
全サイトの評価ページ共通で、公式情報と参照URL検証が終わった後、1-C記事制作パック前に検索意図・上位傾向・共起語を構成材料として整理する。
- 工程名は
1-B2 検索意図・上位傾向・共起語整理として扱ってよい。 - 目的は、H2/H3、評価表、FAQ、リード文、比較観点を作りやすくすること。
- 共起語は本文へ機械的に詰め込むノルマではない。
- 公式情報と矛盾する上位記事情報、サービス内容と関係が薄い語、根拠不足の語は使わない語として明記する。
- 8高品質テストと9-A改善候補抽出では、この整理メモを見て、不足・過剰・無関係語の混入を確認する。
2026-05-17追記: 公開本文境界Gate
全サイトの評価ページ共通で、公開本文には読者のサービス判断に必要な情報だけを書く。内部運用、移行作業、automation、Hub、Gate、QA、301、旧記事からの処理、タスク番号、台帳、作業者都合は本文に出した時点でFAILとする。
- 本文・見出し・表・FAQ・CTA周辺に、
301、旧記事、新辞書記事、移行、公開QA、Gate、PASS、FAIL、Hub、Work Queue、FactChecks、heartbeat、cron、automation、タスク番号、台帳、制作パックを書かない。 - これらは内部ログ、Hub、台帳、QA記録だけに残す。
- 公開本文では、サービス内容、料金、無料範囲、年齢制限、登録、決済、退会、安全面、注意点、公式リンクなど読者向け情報へ書き換える。
- 移行記事でも、301や旧URLの判断は公開本文に書かず、公開QA後の内部工程で扱う。
2026-05-17追記: 訂正対象の取得元Gate
全サイトの評価ページ共通で、task10 / 公開後訂正管理、8高品質テスト後の差し戻し、9-A/9-B/10改善担当ハンドオフは、「task10/FAILキュー」という名前だけを見て0件判定しない。
- Main HubのWork Queue / Tasks、References、FactChecks、9-A/9-Bのreturned状態を横断して確認する。
- Referencesの
correction_queue、public_qa_handoff、quality_fail、correction_requiredを訂正対象として見る。 - 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を自分の訂正対象にしない。
- Hubが401/403/invalid token/token expired/timeout/DNS/network errorで読めない場合は、対象なし扱いにせず
BLOCKED_HUB_AUTHで止める。
AIfunIO用オートメーション依頼文テンプレートの最新版。
今回の反映点
- 全記事共通の冒頭構成Gateを追加。
- ThinkMarkets型のH1、評価スコア表、リード文、右寄せ公式テキストリンク、最初のH2を固定。
- 改善担当ハンドオフ枠(9-A/9-B/10)を追加。
- 外部AI未整備時はCodex別スレッド/専門タスクへ渡せるように整理。
- handed_offかつlock中の本文を返却前に主観リライトしないルールを追加。
- ローカルSQLite不存在だけで止まらないMain Hub優先運用を明記。
共通前提
- 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中の本文を返却前に主観リライトしない。
- AIfunIOはAI評価ページとして、H1はツール名/サービス名のみ。SEOタイトルは「ツール名 + 評判・評価レビュー」系KWを含める。
- 料金、無料プラン、商用利用、権利、対応言語、API、制限は公式または信頼できる根拠で確認する。
- 公式で要確認、確認中、未確認のままなどの仮置き表現を本文/表/Directory Core値に残したらFAIL。
頻度まとめ
| automation | 起動時間 | 頻度 | 処理上限/メモ |
|---|---|---|---|
| 収集cron | JST 02:00 | 1日1回 | 1回最大10件。0-A在庫30件を超えたら整理優先。 |
| 検査cron | JST 00:30 / 06:30 / 14:30 / 18:30 | 1日4回 | 1回最大6件。0-B/1-A棚10件を超えたら整理優先。 |
| 制作cron | JST 08:00開始、約8時間ごと | 1日最大3回目安 | 1回1記事。1スレッド1heartbeatで近似起動。 |
| 高品質テストcron | JST 10:00開始、約8時間ごと | 1日最大3回目安 | 1回1記事。制作後の公開HTMLを確認。 |
| 訂正cron | JST 21:00 | 1日1回 | FAILキューがある場合のみ。 |
| 改善担当ハンドオフcron | JST 23:00 | 1日1回 | 9-A/9-B/10。外部AIまたはCodex別スレッドへ渡す。 |
24時間スケジュール例
| 時刻 | automation | 目的 |
|---|---|---|
| 00:30 | 検査cron | 夜間に0-B/1-A/1-Bを進める |
| 02:00 | 収集cron | 0-A候補を補充 |
| 08:00 | 制作cron | 1記事目を制作 |
| 10:00 | 高品質テストcron | 1記事目をQA |
| 14:30 | 検査cron | 棚を補充 |
| 16:00 | 制作cron | 2記事目を制作 |
| 18:00 | 高品質テストcron | 2記事目をQA |
| 21:00 | 訂正cron | FAILキューを処理 |
| 23:00 | 改善担当ハンドオフcron | 9-A/9-B/10を整理 |
コピー用依頼文
AIfunIO用 収集cron
automation名: 【AIfunIO評価スコアページ】0-A cron 候補収集
AIfunIO用 収集cron 新スレ起動文
# 【AIfunIO評価スコアページ】0-A cron 候補収集 新スレ起動文
このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。
作成するautomation名:
【AIfunIO評価スコアページ】0-A cron 候補収集
対象:
AIfunIO / AI評価ページ / ai-directory-review-ja
区分:
cron
起動時間:
JST 02:00
頻度:
1日1回 / 1回最大10件
目的:
AI評価ページ候補の0-A在庫を補充する。
最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/aifunio-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- AIfunIO作業場所: C:\Users\Public\Documents\LLC358\Autopost358\aifan
- AIfunIO作業ブック: C:\Users\Public\Documents\LLC358\Autopost358\aifan\workbooks\AIfunIO_Work_Sheet.ods
- AIfunIO記事別入力台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-article-input-ledger.md
- AIfunIO辞書セット台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-set-template-registry.md
- AIfunIO生成ログ: C:\Users\Public\Documents\LLC358\Autopost358\aifan\logs\generation
- AIfunIO担当作業室: C:\Users\Public\Documents\LLC358\Autopost358\aifan\agents\CODE-DOG
必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。
この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 収集cron automation作成依頼文
AIfunIO用 収集cron automationを作成してください。
automation名: 【AIfunIO評価スコアページ】0-A cron 候補収集
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。
対象: AIfunIO / AI評価スコアページ / ai-directory-review-ja
区分: cron
起動時間: JST 02:00
頻度: 1日1回 / 1回最大10件
目的:
AI評価ページ候補の0-A在庫を補充する。
共通ルール:
- 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確定を行わない。
全記事共通Gate:
- 全評価ページ共通で、冒頭は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中の本文を返却前に主観リライトしない。
サイト別Gate:
- AIfunIOはAI評価ページとして、H1はツール名/サービス名のみ。SEOタイトルは「ツール名 + 評判・評価レビュー」系KWを含める。
- 料金、無料プラン、商用利用、権利、対応言語、API、制限は公式または信頼できる根拠で確認する。
- 公式で要確認、確認中、未確認のままなどの仮置き表現を本文/表/Directory Core値に残したらFAIL。
やること:
- 候補をmemoryだけで終えず、Main Hubの棚/Work Queue/References/FactChecksへ次工程が読める形で残す。
- 既存上限を超える場合は新規収集より整理を優先する。
止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。
出力:
候補数、採用候補、保留候補、Hub登録結果を報告する。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 検査cron
automation名: 【AIfunIO評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
AIfunIO用 検査cron 新スレ起動文
# 【AIfunIO評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証 新スレ起動文
このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。
作成するautomation名:
【AIfunIO評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
対象:
AIfunIO / AI評価ページ / ai-directory-review-ja
区分:
cron
起動時間:
JST 00:30 / 06:30 / 14:30 / 18:30
頻度:
1日4回 / 1回最大6件
目的:
0-B候補精査、1-A参照URL整理、1-B URL検証を進める。
最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/aifunio-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- AIfunIO作業場所: C:\Users\Public\Documents\LLC358\Autopost358\aifan
- AIfunIO作業ブック: C:\Users\Public\Documents\LLC358\Autopost358\aifan\workbooks\AIfunIO_Work_Sheet.ods
- AIfunIO記事別入力台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-article-input-ledger.md
- AIfunIO辞書セット台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-set-template-registry.md
- AIfunIO生成ログ: C:\Users\Public\Documents\LLC358\Autopost358\aifan\logs\generation
- AIfunIO担当作業室: C:\Users\Public\Documents\LLC358\Autopost358\aifan\agents\CODE-DOG
必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。
この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 検査cron automation作成依頼文
AIfunIO用 検査cron automationを作成してください。
automation名: 【AIfunIO評価スコアページ】0-B/1-A/1-B cron 候補精査・参照URL整理・URL検証
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。
対象: AIfunIO / AI評価スコアページ / ai-directory-review-ja
区分: cron
起動時間: JST 00:30 / 06:30 / 14:30 / 18:30
頻度: 1日4回 / 1回最大6件
目的:
0-B候補精査、1-A参照URL整理、1-B URL検証を進める。
共通ルール:
- 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確定を行わない。
全記事共通Gate:
- 全評価ページ共通で、冒頭は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中の本文を返却前に主観リライトしない。
サイト別Gate:
- AIfunIOはAI評価ページとして、H1はツール名/サービス名のみ。SEOタイトルは「ツール名 + 評判・評価レビュー」系KWを含める。
- 料金、無料プラン、商用利用、権利、対応言語、API、制限は公式または信頼できる根拠で確認する。
- 公式で要確認、確認中、未確認のままなどの仮置き表現を本文/表/Directory Core値に残したらFAIL。
やること:
- 候補ごとに公式/補助URLを整理し、0-B/1-A/1-Bの判定をMain Hubへ残す。
- 制作readyに渡せる候補を複数件作る。ただし根拠不足や仮置きのまま制作へ進めない。
止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。
出力:
PASS/FAIL/保留、制作ready件数、根拠URL不足を報告する。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 制作cron
automation名: 【AIfunIO評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録
AIfunIO用 制作cron 新スレ起動文
# 【AIfunIO評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録 新スレ起動文
このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。
作成するautomation名:
【AIfunIO評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録
対象:
AIfunIO / AI評価ページ / ai-directory-review-ja
区分:
cron
起動時間:
JST 08:00開始、約8時間ごと
頻度:
1日最大3回目安 / 1回1記事
目的:
制作ready棚から1記事ずつ本文制作と公開工程へ進める。
最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/aifunio-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- AIfunIO作業場所: C:\Users\Public\Documents\LLC358\Autopost358\aifan
- AIfunIO作業ブック: C:\Users\Public\Documents\LLC358\Autopost358\aifan\workbooks\AIfunIO_Work_Sheet.ods
- AIfunIO記事別入力台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-article-input-ledger.md
- AIfunIO辞書セット台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-set-template-registry.md
- AIfunIO生成ログ: C:\Users\Public\Documents\LLC358\Autopost358\aifan\logs\generation
- AIfunIO担当作業室: C:\Users\Public\Documents\LLC358\Autopost358\aifan\agents\CODE-DOG
必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。
この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 制作cron automation作成依頼文
AIfunIO用 制作cron automationを作成してください。
automation名: 【AIfunIO評価スコアページ】1-C〜7 cron 記事制作・投稿・台帳記録
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。
対象: AIfunIO / AI評価スコアページ / ai-directory-review-ja
区分: cron
起動時間: JST 08:00開始、約8時間ごと
頻度: 1日最大3回目安 / 1回1記事
目的:
制作ready棚から1記事ずつ本文制作と公開工程へ進める。
共通ルール:
- 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確定を行わない。
全記事共通Gate:
- 全評価ページ共通で、冒頭は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中の本文を返却前に主観リライトしない。
サイト別Gate:
- AIfunIOはAI評価ページとして、H1はツール名/サービス名のみ。SEOタイトルは「ツール名 + 評判・評価レビュー」系KWを含める。
- 料金、無料プラン、商用利用、権利、対応言語、API、制限は公式または信頼できる根拠で確認する。
- 公式で要確認、確認中、未確認のままなどの仮置き表現を本文/表/Directory Core値に残したらFAIL。
やること:
- 制作ready棚から1回1記事だけ処理する。
- 冒頭構成Gate、SEO、装飾、常体、言語一致を満たす本文を作る。
- 公開後に7/8へ渡せるよう、URL、台帳、Directory Core入力状態を記録する。
止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。
出力:
対象記事、公開URL、Directory Core、次工程を報告する。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 高品質テストcron
automation名: 【AIfunIO評価スコアページ】8 cron 高品質テスト
AIfunIO用 高品質テストcron 新スレ起動文
# 【AIfunIO評価スコアページ】8 cron 高品質テスト 新スレ起動文
このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。
作成するautomation名:
【AIfunIO評価スコアページ】8 cron 高品質テスト
対象:
AIfunIO / AI評価ページ / ai-directory-review-ja
区分:
cron
起動時間:
JST 10:00開始、約8時間ごと
頻度:
1日最大3回目安 / 1回1記事
目的:
公開HTMLと台帳を確認してPASS/FAILを判定する。
最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/aifunio-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- AIfunIO作業場所: C:\Users\Public\Documents\LLC358\Autopost358\aifan
- AIfunIO作業ブック: C:\Users\Public\Documents\LLC358\Autopost358\aifan\workbooks\AIfunIO_Work_Sheet.ods
- AIfunIO記事別入力台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-article-input-ledger.md
- AIfunIO辞書セット台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-set-template-registry.md
- AIfunIO生成ログ: C:\Users\Public\Documents\LLC358\Autopost358\aifan\logs\generation
- AIfunIO担当作業室: C:\Users\Public\Documents\LLC358\Autopost358\aifan\agents\CODE-DOG
必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。
この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 高品質テストcron automation作成依頼文
AIfunIO用 高品質テストcron automationを作成してください。
automation名: 【AIfunIO評価スコアページ】8 cron 高品質テスト
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。
対象: AIfunIO / AI評価スコアページ / ai-directory-review-ja
区分: cron
起動時間: JST 10:00開始、約8時間ごと
頻度: 1日最大3回目安 / 1回1記事
目的:
公開HTMLと台帳を確認してPASS/FAILを判定する。
共通ルール:
- 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確定を行わない。
全記事共通Gate:
- 全評価ページ共通で、冒頭は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中の本文を返却前に主観リライトしない。
サイト別Gate:
- AIfunIOはAI評価ページとして、H1はツール名/サービス名のみ。SEOタイトルは「ツール名 + 評判・評価レビュー」系KWを含める。
- 料金、無料プラン、商用利用、権利、対応言語、API、制限は公式または信頼できる根拠で確認する。
- 公式で要確認、確認中、未確認のままなどの仮置き表現を本文/表/Directory Core値に残したらFAIL。
やること:
- 1回1記事だけ公開HTMLと台帳を確認する。
- H1重複、コード露出、公式リンク漏れ、装飾不足、言語不一致、Directory Core漏れをFAILにする。
- 過去記事の不備を見つけた場合もFAIL候補として記録する。
止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。
出力:
PASS/FAIL、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は別命名・別テンプレートにする。
AIfunIO用 訂正cron
automation名: 【AIfunIO評価スコアページ】10 cron 公開後訂正管理
AIfunIO用 訂正cron 新スレ起動文
# 【AIfunIO評価スコアページ】10 cron 公開後訂正管理 新スレ起動文
このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。
作成するautomation名:
【AIfunIO評価スコアページ】10 cron 公開後訂正管理
対象:
AIfunIO / AI評価ページ / ai-directory-review-ja
区分:
cron
起動時間:
JST 21:00
頻度:
1日1回 / FAILがある場合
目的:
FAILキューを1記事ずつ修正する。
最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/aifunio-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- AIfunIO作業場所: C:\Users\Public\Documents\LLC358\Autopost358\aifan
- AIfunIO作業ブック: C:\Users\Public\Documents\LLC358\Autopost358\aifan\workbooks\AIfunIO_Work_Sheet.ods
- AIfunIO記事別入力台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-article-input-ledger.md
- AIfunIO辞書セット台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-set-template-registry.md
- AIfunIO生成ログ: C:\Users\Public\Documents\LLC358\Autopost358\aifan\logs\generation
- AIfunIO担当作業室: C:\Users\Public\Documents\LLC358\Autopost358\aifan\agents\CODE-DOG
必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。
この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 訂正cron automation作成依頼文
AIfunIO用 訂正cron automationを作成してください。
automation名: 【AIfunIO評価スコアページ】10 cron 公開後訂正管理
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。
対象: AIfunIO / AI評価スコアページ / ai-directory-review-ja
区分: cron
起動時間: JST 21:00
頻度: 1日1回 / FAILがある場合
目的:
FAILキューを1記事ずつ修正する。
共通ルール:
- 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確定を行わない。
全記事共通Gate:
- 全評価ページ共通で、冒頭は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中の本文を返却前に主観リライトしない。
サイト別Gate:
- AIfunIOはAI評価ページとして、H1はツール名/サービス名のみ。SEOタイトルは「ツール名 + 評判・評価レビュー」系KWを含める。
- 料金、無料プラン、商用利用、権利、対応言語、API、制限は公式または信頼できる根拠で確認する。
- 公式で要確認、確認中、未確認のままなどの仮置き表現を本文/表/Directory Core値に残したらFAIL。
やること:
- FAILキューから1回1記事だけ修正する。
- 修正後は公開HTMLで再確認し、PASS/FAILと次工程をMain Hubへ記録する。
止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。
出力:
修正内容、再確認結果、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は別命名・別テンプレートにする。
AIfunIO用 改善担当ハンドオフcron
automation名: 【AIfunIO評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ
AIfunIO用 改善担当ハンドオフcron 新スレ起動文
# 【AIfunIO評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ 新スレ起動文
このスレッドは、以下のautomationだけを作成・運用する専用スレッドです。
1スレッドにheartbeatは1つだけなので、他のcron用途を混ぜないでください。
cron automationの場合も、このサイト別cron統括スレッド内で、このcron作成依頼として扱ってください。
作成するautomation名:
【AIfunIO評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ
対象:
AIfunIO / AI評価ページ / ai-directory-review-ja
区分:
cron
起動時間:
JST 23:00
頻度:
1日1回
目的:
9-A/9-B/10の文章改善ハンドオフを処理する。
最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/aifunio-automation-request-templates-20260517/
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- CODE-YUKI引継ぎ控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_global_opening_gate_external_hb_handoff.md
- 外部HB起動文控え: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI\handoffs\2026-05-17_external_improvement_hb_startup_prompt.md
- オートポスト支社共有: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common
- branch_common保険控え: C:\Users\Public\Documents\LLC358\Autopost358\_branch_common\manuals\first-development-source-copies\2026-05-17-global-opening-improvement-gate\global-opening-improvement-handoff.md
- AIfunIO作業場所: C:\Users\Public\Documents\LLC358\Autopost358\aifan
- AIfunIO作業ブック: C:\Users\Public\Documents\LLC358\Autopost358\aifan\workbooks\AIfunIO_Work_Sheet.ods
- AIfunIO記事別入力台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-article-input-ledger.md
- AIfunIO辞書セット台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-set-template-registry.md
- AIfunIO生成ログ: C:\Users\Public\Documents\LLC358\Autopost358\aifan\logs\generation
- AIfunIO担当作業室: C:\Users\Public\Documents\LLC358\Autopost358\aifan\agents\CODE-DOG
必ず守ること:
- automation作成時の名前は、上記のautomation名をそのまま使う。
- Main Hubを正本にし、agent_pack / Work Queue / References / FactChecks / Rules / Manualsを確認してから動く。
- ローカルPC内の storage/data/358-hub.sqlite が無いだけで停止しない。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身を読まない・表示しない。
- 通常の.mdログ、記事本文、キュー、投稿結果の更新ではapply_patchを使わない。
- GATE失敗、未承認、危険操作、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集は停止して確認する。
- Hubが401/403/invalid token等で読めない場合は、対象なし扱いにしない。`BLOCKED_HUB_AUTH / Hub認証不備 / 正本未確認 / 記事修正なし` と報告する。
全記事共通Gate:
- 冒頭構成は H1タイトル → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2。
- 公式テキストリンクは、アフィリエイトリンクがある場合はアフィリエイトリンク、無い場合は公式リンク。
- 公式テキストリンクはPC表示で本文右側または右寄せ。
- 参照例: https://invest358.com/ja/thinkmarkets-review/
- H1重複、コード露出、公式で要確認などの仮置き、言語不一致、装飾不足はFAIL。
この内容でautomationを作成してください。
作成後は、automation名、区分、起動時間、対象、初回実行で確認するHub項目を報告してください。
全評価ページ共通 / 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は別命名・別テンプレートにする。
AIfunIO用 改善担当ハンドオフcron automation作成依頼文
AIfunIO用 改善担当ハンドオフcron automationを作成してください。
automation名: 【AIfunIO評価スコアページ】9-A/9-B/10 cron 改善担当ハンドオフ
名前は必ずこの形で登録してください。人間がautomation一覧を見た時に、サイト名・タスク順番・cron/heartbeat・内容が分かるようにします。
対象: AIfunIO / AI評価スコアページ / ai-directory-review-ja
区分: cron
起動時間: JST 23:00
頻度: 1日1回
目的:
9-A/9-B/10の文章改善ハンドオフを処理する。
共通ルール:
- 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確定を行わない。
全記事共通Gate:
- 全評価ページ共通で、冒頭は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中の本文を返却前に主観リライトしない。
サイト別Gate:
- AIfunIOはAI評価ページとして、H1はツール名/サービス名のみ。SEOタイトルは「ツール名 + 評判・評価レビュー」系KWを含める。
- 料金、無料プラン、商用利用、権利、対応言語、API、制限は公式または信頼できる根拠で確認する。
- 公式で要確認、確認中、未確認のままなどの仮置き表現を本文/表/Directory Core値に残したらFAIL。
やること:
- 9-Aで見出し単位の文章品質と共起語改善候補を作る。
- 9-Bでimprovement_ownerとimprovement_lockを設定し、外部AIまたはCodex別スレッド/専門タスクへ渡す。
- handed_offかつlock中は返却まで主観リライトしない。10で返却分を反映する。
止める条件:
- GATE失敗、未承認サイト、認証情報、権限変更、ファイル削除/移動/上書き、本番コード編集、外部公開先の新規追加。
- 公開投稿そのものは停止条件にしない。
出力:
improvement_status、owner、lock、返却待ち件数を報告する。
全評価ページ共通 / 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
2026-05-17追加: Task10本文修正・終了状態Gate
公開後訂正管理では、FAILを検出して報告するだけで終えてはいけない。本文・FAQ・冒頭構成に原因がある場合、第一手はWordPress本文修正にする。
- 設定側変更は補助手段。Cocoon設定、page_type、テーマ設定、広告/PR表示設定でH1重複や表示崩れが出る場合は撤回し、本文修正へ戻る。
- 内部作業文を公開本文から削除する。
- FAQ内の内部作業設問を削除し、必要なら読者向けFAQへ置き換える。
- 冒頭順は H1 → 評価スコア表 → リード文 → 公式テキストリンク → 最初のH2 に整える。
- 公開HTMLで再確認するまで完了扱いにしない。
- PASS後にだけ301可否へ進む。PASS前に旧URLから301しない。
- 進めない場合は、PASS / FAIL_REQUEUED / BLOCKED_HUB_AUTH / BLOCKED_WP_AUTH / BLOCKED_WP_WRITE / BLOCKED_LAYOUT_RISK / BLOCKED_MISSING_TARGET のいずれかを記録して終了する。ローディングし続けない。
2026-05-17追加: 評価項目本文化・FAQ qa-box・装飾バランスGate
全評価ページでは、評価スコア表の項目を本文見出しとして扱い、各項目ごとに理由説明を書く。FAQは Schema & Structured Data for WP & AMP と本文表示を揃え、装飾はリスト・ボックス・✅・⚠️を重ねすぎず使い分ける。
- 評価スコア表の各項目は、本文内でH2またはH3見出しにして説明する。表だけではPASSにしない。
- 本文FAQは
<details class="qa-box">、<summary>、<div class="qa-answer">を標準にする。 - FAQPage JSON-LDは
Schema & Structured Data for WP & AMP用に作成し、本文FAQと一致させる。 <li>の先頭へ毎回✅/⚠️を付けない。ボックス内にも機械的に✅/⚠️を重ねない。- 既知の修正対象:
https://porn-fun.com/sites/fc2-live-adult-review/
2026-05-17追加: ✅/⚠️優先装飾Gate
全評価ページ共通で、強み・注意点・向いている人・向いていない人を短く見せられる箇所では、ただの箇条書きより✅/⚠️の単独強調文を優先する。
- ✅は強み、向いている人、判断しやすい利点に使う。
- ⚠️は注意点、向いていない人、確認が必要な条件や制約に使う。
<ul><li>やCocoon系ボックスは使ってよいが、毎回アイコンを重ねない。- 評価ページで✅/⚠️が0件のまま、強みや注意点を普通のリストやボックスだけで処理している場合はFAILにする。
- 既知の訂正対象:
https://porn-fun.com/sites/fc2-live-adult-review/
全評価ページ共通 / ✅・⚠️優先装飾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は別命名・別テンプレートにする。
2026-05-17追加: 制作完了→高品質テスト引き渡しGate
全サイト共通で、1-C〜7の制作・公開・台帳記録が完了した記事は、8高品質テストへ明示的に引き渡す。公開URLを作っただけで終わらせない。
- 制作側は
task_code=8/use_status=public_qa_handoff/check_status=readyをHubへ残す。 - 8高品質テスト側は
public_qa_handoffだけでなく、published_directory_articleと task7公開済み記事も横断して見る。 - 同じ記事にtask8 PASSが無い公開済み記事を「対象なし」と扱わない。
- 既知の補正対象:
https://porn-fun.com/sites/hey-douga-review/
全サイト共通 / 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は別命名・別テンプレートにする。
2026-05-17追加: cron標準・サイト別1スレッド運用
オートポスト支社の通常運用はcron標準にする。heartbeatは例外運用とし、各タスクごとの新スレッド立ち上げは行わない。
- サイト別スレッド立ち上げ文は、1サイトまたは1セットにつき1つだけにする。
- サイト別cron統括スレッド起動文を貼ってもcronは作成しない。状態復元、Hub確認、既存cronと未作成cronの整理だけを行う。各タスク欄のコピー文は、ユーザーが個別に貼った時だけ、そのcronを1つ作る依頼文として扱う。ユーザーが「全cronをまとめて作って」と明示しない限り一括作成しない。
- 通常運用はHub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- automation名は
【サイト名】タスク順番 cron 内容を標準にする。 - 1回1記事制限、最大処理件数、対象なし終了、BLOCKED_*終了条件はcron本文内に書く。
サイト別cron統括スレッド起動文
# AIfunIO評価スコアページ用 cron統括スレッド 起動文
このスレッドは AIfunIO / AI評価スコアページ運用のcron統括スレッドです。
最初に確認するもの:
- Main Hub: https://hub.goudou-358.jp
- 対象レポート: https://report.goudou-358.jp/aifunio-automation-request-templates-20260517/
- 第一開発部共有: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\_department_common
- CODE-YUKI作業室: C:\Users\Public\Documents\LLC358\HQ\10_FIRST_DEVELOPMENT\tool-design\agents\CODE-YUKI
- AIfunIO作業場所: C:\Users\Public\Documents\LLC358\Autopost358\aifan
- 作業ブック: C:\Users\Public\Documents\LLC358\Autopost358\aifan\workbooks\AIfunIO_Work_Sheet.ods
- 記事別入力台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-article-input-ledger.md
- 辞書セット台帳: C:\Users\Public\Documents\LLC358\Autopost358\aifan\ledgers\directory-set-template-registry.md
運用方針:
- 通常運用はcron標準。heartbeatは例外。
- この1スレッド内でAIfunIO評価スコアページ関連cronの状態を復元・確認する。サイト別起動文を貼っただけではcronを作成しない。
- 各タスクごとに新スレッドを立てない。全cron一括作成は、ユーザーが「全cronをまとめて作って」と明示した場合だけ。通常は1つずつ作成する。全cron一括作成は、ユーザーが「全cronをまとめて作って」と明示した場合だけ。通常は1つずつ作成する。
- 各タスク欄のコピー文は、ユーザーが個別に貼った時だけ、このスレッド内でcronを1つ作る依頼文として扱う。
- Hub正本、Work Queue、References、FactChecks、台帳で状態管理する。
- 認証情報、APIキー、パスワード、トークン、WordPress REST認証情報の中身は読まない・表示しない。
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は別命名・別テンプレートにする。
2026-05-17追加: cron個別作成Gate
サイト別cron統括スレッド起動文は、状態復元とHub確認のための文です。これを貼っただけではcronを作成しません。
- サイト別起動文では、Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告する。
- cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
- 1回のcron作成依頼文で作るautomationは1つだけにする。
- ユーザーが「全cronをまとめて作って」と明示しない限り、複数cronを一括作成しない。
- automation名は
【サイト名+評価スコアページ種別】タスク順番 cron 内容の形で、人間が見て分かる名前にする。
cron個別作成Gate コピー文
cron個別作成Gate:
サイト別cron統括スレッド起動文を貼っただけではcronを作成しない。
統括スレッド起動文では、Main Hub、agent_pack、Work Queue、References、FactChecks、台帳、既存automationを確認し、既存cronと未作成cronを整理して報告するだけにする。
cron作成は、ユーザーが各タスク欄のcron作成依頼文を個別に貼った時だけ行う。
1回のcron作成依頼文で作るautomationは1つだけにする。
ユーザーが「全cronをまとめて作って」と明示しない限り、0-A、0-B/1-A/1-B、1-C〜7、8、9-A/9-B/10、10、11などを一括作成しない。
評価スコアページ用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は別命名・別テンプレートにする。
2026-05-17追加: 評価スコアページ用cron命名Gate
この一連のcronは、まとめページ、キラーページ、通常記事、速報記事ではなく、評価スコア表を持つ辞書型・レビュー型ページ専用として扱う。
- automation名には必ず「評価スコアページ」を入れる。
- AIfunIOは
【AIfunIO評価スコアページ】を使う。 - Nightlife夜遊び店舗は
【Nightlife夜遊び店舗評価スコアページ】を使う。 - Nightlifeホテルは
【Nightlifeホテル評価スコアページ】を使う。 - porn-fun単体サービス移行は
【porn-fun単体サービス評価スコアページ移行】を使う。 - まとめ/ランキング/比較/通常/速報記事用のautomationを作る場合は、別記事・別命名で切り分ける。
命名コピー
評価スコアページ用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は別命名・別テンプレートにする。

コメント