広告づくりの「工場のルールブック」を固定した日

広告を作るとき、これまでは「やることリスト」（.ops task）しかありませんでした。作業は進むけれど「なぜ作ったのか」が終わると消えてしまいます。そこで production_brief（制作依頼書）という紙を新しく作りました。ここには「なぜ作るか・何を試すか・何が勝てば学びになるか」を書きます。

役割分担はハッキリさせました。依頼書＝意図（なぜ）の記録、やることリスト＝進み具合の記録。同じ情報を2か所に書いてズレないようにします。依頼書を書けるのは小澤さんと判断係（handan）だけ。台本係などの現場AIは書けません。

台本を書くAI（/script）は毎回、「読者の気持ちがどう動くか（不安→納得→行動）」という設計図を下書きで出します。これを flow_draft と呼びます。でもこれはあくまでAIの仮説（予想）であって、正しいと決まったわけではありません。

だから、AIの下書きをそのまま正式な知識ベース（Koza OS＝小澤さんの頭の中を写した知識置き場）には入れません。小澤さんがレビューしてOKを出したものだけが、正式な知識に「昇格」します。

実験の設計図（route brief）を渡して台本を作らせるとき、台本AIがその指示をどこまで守ったかを4段階で残すようにしました。これが route_compliance です。

これがあると、実験がうまくいった（or 失敗した）とき、それが「指示が良かったからか」「AIが勝手に変えたせいか」を後から区別できます。

「どのAIが何をしていいか」を、文章だけでなくプログラムのレベルでも縛りました。具体的には —

・台本係（daihon）は、データベース（BQ）には下書きの登録しかできない（本確定や書き換えは禁止）。
・検品係（bucho）から、使っていない余分な権限を削除。
・判断係（handan）を「工場に住み込みで常駐する人」ではなく、「毎朝出勤して判断だけして帰る人」として正式に定義。

この変更で壊れていないことを確かめるため、自動テスト118件がすべて合格しています。

広告の「冒頭（つかみ）」を何パターン作るか。決裁では6本が正しいと決まっているのに、古い設計書やスキルの一部に「8本」という表記が残っていました。これをすべて6本に直しました。

ただし、過去に8本で行った実験の記録はそのまま履歴として残します（歴史を書き換えない）。