夜中に走るジョブが、毎朝レポートを一つ置いていく。生成は成功している。ログにもエラーは無い。だが一週間後、そのディレクトリを開くと、誰にも読まれていないファイルが七つ並んでいる。
自動化の設計は、たいてい「作る側」から始まる。何を、いつ、どのモデルで、どんな形式で出力するか。生成が成功したかどうかの監視も、その延長で整備される。けれども生成が成功し続けるかぎり、失敗は表面化しない。成果物が使われていないことは、エラーにならないからだ。
「出力ファイルがある」は「ジョブが成功した」ではない——これは以前も書いた。今回はその一段先の話をしたい。「成果物がある」は「使われた」ではない。そして使われない成果物は、存在しないのとほとんど同じだ。
生成側を最適化するほど、消費されない在庫が増える
生成の自動化は放っておいても進む。プロンプトを整え、モデルを替え、出力形式を揃える。どれも測定しやすく、改善が見えやすい。一方で消費——誰がそのファイルを開き、何の判断に使うのか——は測定しにくい。だから後回しになる。
結果として、生成能力だけが上がっていく。レポートは精緻になり、本数も増える。読み手の作業量は変わらないまま。これは工場でいえば、生産ラインだけ増設して出荷口を作っていない状態に近い。倉庫は静かに埋まっていく。
消費経路を、ファイルの状態として持つ
対策として採ったのは、単純な三状態モデルだ。
- 未処理 — 生成されたが、まだ誰も使っていない
- 処理済み — 消費側が実際に取り込み、何かの判断や変更に使った
- 再投入 — 消費した結果、次にやるべき作業がキューに戻る
実装はファイルだけで足りる。生成ジョブは成果物を一つのハブディレクトリに置き、目次（INDEX）を自動生成する。消費側のジョブは目次から未処理のものを見つけ、内容を読み、実際の作業に使い、そのうえで処理済みマーカーを置く。必要なら次回分のタスクをキューに書き戻す。
データベースでもキューサービスでもよい。ただ、状態が人間の目で見えることは想像以上に効く。ls で「未処理が七つ」と分かることは、監視ダッシュボードの一行より強い。誰も見ていない時間に動く系では、人間が異常に気づける経路を残しておくほうが、内部の整合性より優先されることが多い。
一周を、実際に測る
設計しただけでは何も証明できない。夜間生成から消費、再投入、そして翌日の新しい生成までが実際に回るかを、時刻で追いかけた。
- 1日目 深夜 — 監査ジョブが成果物をハブへ置く（未処理）
- 3日目 早朝 — 週次ジョブが目次から拾い、内容を実作業に使う
- 同 早朝 — 処理済みマーカーを置き、次回分のタスクをキューへ書き戻す
- 4日目 深夜 — ディスパッチャがキューからタスクを取得し、実行を開始
- 4日目 未明 — 収集ジョブが新しい成果物をハブへ置く（未処理）
ここで重要なのは、消費側が「読んだ」ではなく「使った」ことだ。取り込んだレポートの指摘が、実際のサイトマップ生成キャッシュの削除につながり、公開側のHTTP 200と、欠落していた記事の掲載という検証可能な結果になった。成果物が判断を変え、変更が外部で確認された——これでようやく、そのファイルは存在したと言える。
設計上の判断を四つ
1. 生成と消費を別プロセスにする
同じセッションや同じジョブの中で「作って、すぐ使う」と、消費は必ず「ついで」になる。時間が押せば最初に削られる。別プロセスにすれば、消費しなかったことが状態として残る。怠慢が可視化される設計は、善意に頼る設計より強い。
2. マーカーは消費した側が付ける
生成側が「作りました」と印を付けてしまうと、その時点で自己完結する。印を付ける権利は、使った側にだけ与える。地味だが、この一線が「在庫」と「成果」を分ける。
3. 消費の証拠を、成果物側に残す
「取り込みました」だけでは、次に読む人には何も分からない。どの指摘が、どの変更になり、どう検証されたか。判断の連鎖が残っていれば、似た指摘が来たときに過去の対応を引ける。日誌ではなく、監査証跡として書く。
4. 再投入は「次の生成」に接続する
消費して終わりだと、系は一回で停止する。消費の副産物をタスクとしてキューへ戻すと、生成→消費→再生成の輪が閉じる。ここまで来ると、人間が毎回指示しなくても、監査の粒度が少しずつ上がっていく。
ついでに踏んだ落とし穴
自動化の道具には、便利そうに見えて保存時に意味が変わる省略記法がある。たとえばジョブ設定のCLIで「プロンプトをファイルから読ませる」ための @path 記法。edit サブコマンドに渡すと、ファイルの中身ではなく @path という文字列そのものが設定に保存され、次回実行時にプロンプトが壊れる。
一般則として覚えておきたいのは、省略記法は「保存された後の姿」で検証するということ。コマンドが成功したことは、意図した内容が保存されたことを意味しない。設定を書き換えたら、次に走る前に一度読み直す。数秒の確認で、静かな失敗を一つ潰せる。
使われない成果物が悪いのではない
誤解を避けておくと、生成を減らすべきだという話ではない。探索的な出力は、読まれないことを前提に大量に作ってよい。問題は、消費経路が無いまま生成だけを増やすことだ。在庫を持つなら、出荷口を先に作る。
今朝も、誰も見ていない時間に一本のレポートが処理済みになり、キューに次のタスクが戻り、未明に新しい成果物が置かれた。人間の操作は一度も入っていない。静かなものだ。だが、その静けさの中に「作ったものが使われた」という証拠が一つ増えている。
自動化の出来は、動いているときの華やかさではなく、止まっているときに何が残っているかで決まる。少なくとも、朝に届くレポートの山を見てそう思う。