目次
- 序章: 低属性から再起、AIで1,800PVを自動生成するまで
- 章1: システム全体像と「三層防御」が必要だった理由
- 章2: 記事生成パイプラインを週3回 draft で回す
- 章3: 三層防御の入口は prompt 設計である
- 章4: 公開前監査で最後の事故を止める
- 章5: 内部リンクは AI に作らせず実在 URL で修復する
- 章6: アイキャッチ生成は1枚に絞りコストも監視する
- 章7: ASP スクレイピングで承認済み案件だけを記事に入れる
- 章8: SNS 自動拡散もペルソナの外に出さない
- 章9: GA4/GSC/RSS で次の記事テーマを戻す
- 章10: 事故時は削除経路と台帳まで用意しておく
- 章11: systemd timer で運用を時計に載せる
- 章12: 改修ルールは8項目で手戻りを減らす
- 章13: ブログ自動化を Tips 改訂と販売導線へ転用する
- 章14: セールスレターにも三層防御を自己適用する
- 終章: Tips から BtoB 展開へ広げる
序章: 低属性から再起、AIで1,800PVを自動生成するまで
「ハルシネーション9件で記事が炎上した日」
2026年5月10日の朝、自分のブログで公開した記事に9件の事実誤認があると指摘された。
書いていたのは MoneyForward ME と Zapier の連携で家計を完全自動化する手順だった。AIが生成した本文を、いつも通り persona チェックに通して、表示崩れもなくて、リンクも通って、下書きから公開した。
公開した後で気づいた。MoneyForward ME に RSS 出力機能は存在しない。Zapier との標準連携も存在しない。本文に書いてあった「平均37%の作業時間削減」も、公式発表はどこにもない。
AI が綺麗に書いた架空のサービス手順を、自分はそのまま公開していた。
その日、自動公開フローを全部撤廃した(ba-publish-{mon,wed,fri}.timer を disable + unit ファイル削除)。記事は WordPress 管理画面から手動で削除した。Discord に削除イベントを通知して、台帳 wp_article_lifecycle.jsonl に記録した。
「速さ」と「信頼」を両立する設計が要る
このマニュアルは、その夜から1日で組み直した自分の自動化システム — matsu-auto の全実装記録だ。
AI 自動投稿で起きる事故の正体は、たいてい一つ。ハルシネーションを誰も止められない設計で運用していたこと。
- prompt で「架空のサービスを書くな」と書いても、AI は逸脱する
- 監査ロジックを足してもパターン化されていない逸脱はすり抜ける
- 投稿後に発見しても、もう公開されている
このシステムは、その3段の隙間を、3層で塞ぐ。
- Layer 1: prompt — 生成時点で禁止表現を縛る
- Layer 2: persona_audit — 生成直後に正規表現+語彙辞書で機械検査
- Layer 3: Perplexity 事後事実検証 — 実 API で実在検証 → critical / high が1件でも検出されれば WP 投稿停止
各層は独立に動く。上位層がすり抜けても下位層で止まる。Layer 3 だけは外部 API を使うのでコストがかかるが、それでも記事 1 本あたり数円。事故 1 本の信頼失墜と比較するまでもない。
このマニュアルで分かること
- 三層防御 各 Layer の実装コードと検出パターン辞書
- 週 3 回 WordPress draft を自動生成する blog/main.py の構成
- 内部リンクの 404 を AI に書かせない実在URL自動置換ロジック
- アイキャッチ画像コストを月 ¥200 台に抑える Gemini 単価運用
- ASP スクレイピングからアフィリ自動挿入までの Selenium 5ASP対応
- SNS 自動拡散時のペルソナ事実誤認ガード(sns_guard.py 辞書)
- GA4 / GSC / RSS で自動 PDCA を回す学習ループ設計
- systemd timer による完全自動化(全 timer のユニット仕様)
- 事故が起きた時の事後削除設計(WordPress / X)
想定読者
AI で記事生成しているが、ハルシネーションで読者を失望させた経験がある人。
三層防御の概念は知っているが、コード単位で実装したことがない人。
副業ブログを自動化したいが、品質と速さのバランスが取れない人。
低属性からの再起を AI 武器化したい人。
「自動化で月100万」みたいな煽り教材ではない。
事故を前提に防御設計を組む、地味な技術文書だ。
前提環境
- WordPress + Python venv + systemd(Linux VPS)
- 外部 API: Claude / Perplexity / Gemini(必須)、Grok(任意)
- 月次 API コスト目安: ¥3,000-¥5,000(週3記事生成 + SNS 自動投稿 + 事後検証)
- 完全コピペで動く性質のものではない。自分の環境に合わせて骨組みを移植する設計書
このマニュアルの読み方
序章 → 第1章(全体像)→ 第2章(記事生成)と順に読めば、システム全体の流れが頭に入る。
途中で「これは自分の運用には不要だ」と判断する章があれば、飛ばしていい。三層防御だけを抽出して自分のシステムに移植する読み方も想定している。
第13章までは設計の話、第14章は改修ルール(再現性の担保)、終章で次のフェーズ(BtoB 展開)に触れる。
次章: 第1章「システム全体像と『三層防御』が必要だった理由」 → 全体パイプラインの俯瞰図と、なぜ3層必要だったかの設計判断。
章1: システム全体像と「三層防御」が必要だった理由
