はじめに
20歳の大学生が、Claude Code を使って AI 自動化システムを 9 ヶ月運用してきた中で構築した「8層 Validator」の話を書きます。
最初に断っておくと、ここで紹介するパターンの大半は新規研究ではありません。形式検証 / コードレビュー / TDD など、既知の原則を AI 出力に適用しただけです。
新しいのは「個人が AI 自動化を本番運用する時、これくらいの層を持っていないと事故る」という体感値の方です。9 ヶ月の運用で実際に踏んだ事故 4 件と、それを構造的に防ぐ層別設計を共有します。
結論（先に出す）
| 層 | 名称 | 主検査 |
|---|---|---|
| 0 | Typography | 誤字脱字・末尾形 |
| 1 | 地雷ワード | NG ワード正規表現 |
| 2 | プレースホルダ |
{{xxx}} 残留検出 |
| 3 | 重複送信 | append-only ログとの照合 |
| 4 | brand_guard | マッチョ煽り検出 |
| 5 | sanity | 文字数・無償オファー禁止 |
| 6 | reflection_preamble | 過去失敗教訓注入 |
| 8 | secrets_leak | API key / 個人情報検出 |
| 9 | sender_pattern_audit | 副作用前 Inbox/Atomic ガード（静的検査） |
各層は単一責務で fail-closed。1 層でも error なら送信/公開を停止します。
4 件の事故と、それぞれが生んだ層
事故 1：同じメッセージを 4 回送ってしまった（→ Layer 3 + 9 が誕生）
ある日、取引先に同じ提案メッセージが 4 通送信されました。原因は wrapper script の auto-restart loop。crash 復帰時に副作用前のガードが無く、同一メッセージで再送が発火しました。
構造解
- append-only proposals_log で「送信済 messageId」を記録
- send 直前に has(messageId) チェック → skip if seen
- file ベースの Inbox Pattern（DB 不要・crash 安全）
const inbox = require('./inbox');
if (inbox.has(messageId)) return; // skip
await sendMessage(...);
inbox.commit(messageId);
これが Layer 3（重複送信検査）の起点です。さらに、新規 sender 追加時に Inbox 統合を機械検査する Layer 9 sender_pattern_audit を追加しました。
事故 2：プレースホルダ {{client_name}} がそのまま送信された（→ Layer 2）
テンプレベース提案文の {{client_name}} を埋め忘れて submit。クライアント体験として最悪。
構造解
- 送信前に
{{[a-z_]+}}regex 検出 -
XXXTODO[ここ埋める]等の典型プレースホルダも対象 - 検出時は draft を
failed/退避 + LINE 通知
事故 3：「劇的に効果！」「絶対成功！」が混じった（→ Layer 4 brand_guard）
LLM が「響きの良いコピー」として煽り訴求を生成 → 自分のブランド方針（等身大・透明性）に反する。
構造解
- NG 語辞書（"劇的" / "圧倒_的" / "No.1" / "絶対" / "完全自動" / "革命" / "必ず..." 等の煽り表現）を separate file 化
- 検出時 error severity → 送信停止
- 辞書は editable な txt/json で運用（prompt に埋めない）
事故 4：API トークンがエラー output に丸出し（→ Layer 8 拡張）
健全性チェックスクリプト v1 で curl エラー時に command line に含まれた API トークン全文が console に表示されました。幸い外部公開には到達せず。
構造解
- secrets_leak_validator (Layer 8) に regex 追加：API token / OAuth secret / Webhook secret 全種
- 全エラーログに sanitize 処理：
[REDACTED]化 - 過去公開コンテンツの後追い scan も実施
設計原則 3 点
1. Cheap regex first → LLM judge last
Layer 0-3 と 8 の Stage A は正規表現・速い・コスト低。Layer 4-6 と 8 Stage B が LLM 呼出し。実測で Layer 0+4 chain は 0.6ms 以内。LLM judge は 100ms 〜 数秒。順序が重要。
2. Fail-closed
1 層でも error なら停止。warn-only 化は禁止（自己評価盛りで漏洩許容に緩和されるリスク）。
3. Generator と Validator は別エージェント
同モデル self-check は agreement bias の論文証明あり。Generator が Sonnet なら Validator は Haiku、もしくは別 prompt persona で動かす。
全体の参照
このパターン群は「Arena Blueprint」に Module 4（Validator）+ Module 8（Generator+Validator 原則）として整理しました。
- Notion で全文無料公開：arena_blueprint_complete_v1
- Skills Bundle (MIT)：github.com/pikuto1125-pixel/claude-skills-pikuto
- LP：ai-hack-lab.com/products/arena-blueprint
- AI Hack Lab Daily Digest（無料）：ai-hack-lab.com/insights
終わりに
書いてある内容の大半は新規ではなく、9 ヶ月の運用で「これがないと事故る」と分かった層を整理しただけです。導入には初期設定・調整・運用が必要で、簡単ではありません。
ただ、4 件の事故を踏まずに済む可能性があるなら、それだけで価値があるはずです。
参考にしていただければ嬉しいです。
— pikuto / AI Hack Lab