はじめに

20歳の大学生が、Claude Code を使って AI 自動化システムを 9 ヶ月運用してきた中で構築した「8層 Validator」の話を書きます。

最初に断っておくと、ここで紹介するパターンの大半は新規研究ではありません。形式検証 / コードレビュー / TDD など、既知の原則を AI 出力に適用しただけです。

新しいのは「個人が AI 自動化を本番運用する時、これくらいの層を持っていないと事故る」という体感値の方です。9 ヶ月の運用で実際に踏んだ事故 4 件と、それを構造的に防ぐ層別設計を共有します。

結論（先に出す）

各層は単一責務で fail-closed。1 層でも error なら送信/公開を停止します。

ある日、取引先に同じ提案メッセージが 4 通送信されました。原因は wrapper script の auto-restart loop。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 を追加しました。

テンプレベース提案文の {{client_name}} を埋め忘れて submit。クライアント体験として最悪。

LLM が「響きの良いコピー」として煽り訴求を生成 → 自分のブランド方針（等身大・透明性）に反する。

NG 語辞書（"劇的" / "圧倒_的" / "No.1" / "絶対" / "完全自動" / "革命" / "必ず..." 等の煽り表現）を separate file 化
検出時 error severity → 送信停止
辞書は editable な txt/json で運用（prompt に埋めない）

健全性チェックスクリプト v1 で curl エラー時に command line に含まれた API トークン全文が console に表示されました。幸い外部公開には到達せず。

secrets_leak_validator (Layer 8) に regex 追加：API token / OAuth secret / Webhook secret 全種
全エラーログに sanitize 処理：[REDACTED] 化
過去公開コンテンツの後追い scan も実施

Layer 0-3 と 8 の Stage A は正規表現・速い・コスト低。Layer 4-6 と 8 Stage B が LLM 呼出し。実測で Layer 0+4 chain は 0.6ms 以内。LLM judge は 100ms 〜数秒。順序が重要。

1 層でも error なら停止。warn-only 化は禁止（自己評価盛りで漏洩許容に緩和されるリスク）。

同モデル self-check は agreement bias の論文証明あり。Generator が Sonnet なら Validator は Haiku、もしくは別 prompt persona で動かす。

このパターン群は「Arena Blueprint」に Module 4（Validator）+ Module 8（Generator+Validator 原則）として整理しました。

書いてある内容の大半は新規ではなく、9 ヶ月の運用で「これがないと事故る」と分かった層を整理しただけです。導入には初期設定・調整・運用が必要で、簡単ではありません。

ただ、4 件の事故を踏まずに済む可能性があるなら、それだけで価値があるはずです。

参考にしていただければ嬉しいです。

— pikuto / AI Hack Lab