直したはずの指摘が、また戻ってきた。
しかも、一度ではない。
同じような論点が何度も出てきて、こちらは「もう直したのに」と思っている。
AIに渡す指示も、修正履歴も、前より丁寧に書いている。
なのに、審査役のAIは、直した後の状態を見ていないような反応をする。
こういう時、つい「AIの判断が不安定だ」と片付けたくなる。
でも今日の差分を見ると、原因はもっと地味だった。
制作台本のメモが 27860字 までふくらみ、審査役へ渡す時に 24000字 で切り詰められていた。
その結果、途中からの修正履歴が、審査役AIの視界から物理的に消えていた。
AIに全部渡したつもりでも、AIが全部読めているとは限らない。
今日はその話を書く。
直したはずの指摘が戻ってきた
今日読んだ差分には、かなり生々しい中間物が残っていた。
審査役AIからの指摘に対応し、ラウンドを重ねて、台本や状態データを直していく。
ある段階では、人物の向き、座る位置、持ち物、台詞の時制まで細かく直していた。
たとえば、こんな種類の修正が並んでいた。
P16は「立ったまま諭す」に単純化
座り直しはP21へ移設
台本本文・要約・状態データ・パネル指示を同期ここだけ見ると、かなり丁寧だ。
一つの静止画に複数の動作を詰めすぎない。
人の向きと画面上の位置を合わせる。
台詞の時制と、実際の姿勢を矛盾させない。
AIに任せる仕事ほど、こういう細かい契約が大事になる。
ところが、直したはずの論点が、また審査で戻ってきた。
「まだ移動が説明されていない」
「前の学習ログと今の状態が合っていない」
「同じ箇所をさらに分割すべき」
人間側から見ると、もう対応済みの話に見える。
審査役AIから見ると、まだ見えていない話に見える。
このズレが、今日の壊れた瞬間だった。
原因は能力ではなく、文脈の詰め込みすぎだった
差分の中で、原因がはっきり書かれていた。
script.mdが27860字まで肥大化し、
director_gate.pyのプロンプト注入が契約ファイルごとに24000字で切り詰めるため、
ラウンド15以降の対応履歴が審査から見えなくなっていたこれは、かなり大事なログだ。
AIが気まぐれに忘れたのではない。
人間が渡したつもりの文脈が、途中で切れていた。
そして、切れた場所より後ろに、肝心な修正履歴があった。
問題は「もっと詳しく書けば伝わる」ではなかった。
むしろ、詳しく書きすぎたことで、後半の重要な情報が届かなくなっていた。
これはAI運用でよく起きる。
うまくいかない時、私たちは説明を足す。
注意事項を足す。
例外を足す。
過去の失敗ログを足す。
でも、足した情報が多すぎると、AIが見るべき現在地が埋もれる。
指示が長いほど賢くなるわけではない。
長い指示は、時々、古い説明と新しい判断を同じ重さで混ぜてしまう。
しかも今回のように、上限で切れる場合はもっと危ない。
後半に書いた「最新の正解」が、審査に入らない。
それなのに、人間側は「書いてあるのに」と思ってしまう。
このすれ違いは、かなり厄介だ。
履歴は退避し、正本は短くする
今日の良かった点は、原因が分かった後の対処が現実的だったことだ。
やったことは、履歴を消すことではない。
詳細記録を別ファイルへ退避し、台本本体は要約だけに戻していた。
詳細記録を _qc/director_review_history.md へ退避
script.md 本体は要約のみ
以後は script.md が24000字を超えないようにするここが大事だと思った。
履歴は必要だ。
でも、履歴と正本は同じ場所に置かなくていい。
むしろ同じ場所に置くと、AIの読み方が壊れる。
正本には、今守るべき状態だけを書く。
履歴には、なぜそうなったかを書く。
審査に渡す時は、正本を優先する。
必要な時だけ履歴を参照する。
AIに渡す文書は、詳しさよりも役割分担が先。
全部入りの1ファイルは、人間には安心に見える。
でも、AIの入力としては危ない。
現在の決定、過去の検討、破棄した案、例外条件が一列に並ぶと、どれが今日の正解か分かりにくくなる。
だから、分ける。
- 正本：今の決定だけを書く
- 履歴：判断の経緯を書く
- 検査結果：次に直す対象を書く
- 作業ログ：あとで追跡する証拠として残す
今回の対処は、この分け方に近い。
「長すぎたから短くする」ではなく、「読む目的ごとに置き場所を変える」だった。
この違いは大きい。
次から測るのは、完成度だけではない
もう一つ、今日の差分には数字が残っていた。
別の検査レポートでは、判定はPASSだった。
でもWARNは 27件 残っていた。
しかも内容は、全パネルでプロンプトが4000字を超えているというものだった。
判定: PASS (FAIL 0 / WARN 27)
panel24 WARN W10: プロンプト11140字(>4000)PASSは大事だ。
失敗していないことは、前に進む条件になる。
でも、PASSだけ見ていると、次の設計材料を見落とす。
今回なら、完成したかどうかだけでなく、次から見る数字はこれだと思う。
- 正本ファイルの文字数
- 審査に渡す入力の上限
- 上限で切れた時に消える範囲
- WARNの件数
- 1パネルあたりのプロンプト長
AIの仕事は、出力が完成した瞬間だけ見ても足りない。
完成までに、AIへ何文字渡したか。
どこで切れたか。
どの指摘が、実バグではなく文脈欠落から生まれたか。
そこまで見ると、次の失敗が減る。
私が次回から置くルールは、これにする。
AI審査へ渡す正本は、上限の8割を超えたら分割候補にする。
履歴は本体に積まず、別ファイルへ退避する。
審査に必要なのは「全部の経緯」ではなく「今の決定」と「未解決だけ」。これは派手な改善ではない。
でも、AI運用ではこういう地味な整理が効く。
AIが読めないほど丁寧な説明は、説明として機能しない。
次に同じことが起きたら、私はまずAIを疑う前に、入力の長さを見る。
AIに渡す文脈は、増やすほど安心ではない。正本は短く、履歴は別に、上限は数字で見る。