対外向けの検証記事（note）とは役割を分ける。
こちらは AdAffiTower の実績を証明する運用実証アーカイブ。
「開発ログ」ではなく、止まったサイトをどう戻したか のケース台帳として残す。
- note（公開検証）: https://note.com/affiri_gen/n/n8ed530e14157
- 公開予定: 2026-08-29 19:00（note と同タイミング）
このページの目次
ケース概要
| 項目 | 内容 |
|---|---|
| ケース番号 | #001 |
| 対象 | 自社 FANZA / MGS 系サイト（収益ほぼゼロ） |
| 状態 | 復旧作業開始（本記事時点） |
| 目的 | 停止→復旧→72h安定→GSC/収益回復を記録 |
1. 今回証明したいこと
収益がほぼゼロまで落ちた既存サイトを題材に、次を 数字付きで 残す。
- 停止原因の特定
- 投稿ラインの復旧
- AdAffiTower からの継続監視
- 24〜72時間の安定稼働
- GSC / 収益回復の推移
対外ストーリーは note。
一次データ（症状・原因・実施・数値）は本アーカイブ に残す。
2. 現状（AdAffiTower の到達点）
できている（問題を見つける）
- 複数サイト横断・オーナー別管理
- 自動投稿設定・成功/失敗ログ
- 24h / 7日集計、稼働・停止・沈黙判定
- サイト詳細・比較・ポートフォリオ
- GSC / 収益 / 異常履歴 / 週次レポート
- Celery backlog・最新公開日・投稿停止サイト検出
まだ弱い（判断→修復→確認）
- 障害原因の自動分類
- 安全な範囲での自動修復
- 復旧後の再監視ループ
- 実績 KPI の専用保存面
評価: 検知は実運用可。修復実証はこれから。
3. 監視チェックリスト（ケース #001）
復旧作業中は最低でも毎日記録する。
| 項目 | 見る場所 | 記録 |
|---|---|---|
| 最終投稿日 | AdAffiTower / WP | YYYY-MM-DD |
| 投稿成功数（24h） | PostLogs | 本 |
| 投稿失敗数・代表エラー | PostLogs | 文言 |
| scheduler / Celery / cron | 基盤監視 | OK/NG |
| WP 実投稿増加 | 対象サイト | 本 |
| GSC 表示・クリック | GSC | 数値 |
| ASP クリック・売上 | 収益面 | 数値 |
| 検知→復旧までの時間 | 本ケース | 時間 |
成功条件: 投稿再開だけでなく、検索流入・売上・運用時間の回復 まで含める。
4. 優先順位（本ケース限定）
- FANZA / MGS 投稿ライン完全復旧
- 復旧後 24〜72時間監視
- 実績 KPI の保存
- 既存投稿ラインの AdAffiTower 統一監視
- 障害原因分類 → 自動診断 → 安全な自動修復
投稿エンジン全面移植はしない。既存ラインを wrapper で観測・制御する。
5. いまやらないこと
- note 記事の文言コピー・二重投稿
- 大規模 UI リニューアル
- 投稿エンジン全面書き直し
- 決済会社未確定での専用実装
- 実績がない状態での大量広告
6. 次回追記（ケース #001 更新）
確定した事実のみ追記する。
- 症状: （最終投稿日・影響サイト）
- 原因: （確定 / 仮説を明記）
- 実施: （設定・再起動・デプロイ単位）
- 結果: （24h / 72h の投稿・GSC・売上）
- 残課題:
note には数字が固まってから要約を出す。盛らない。
コメント