全自動処理の指示ルールを実行ファイルに直接書き込んだ——「参照される保証」を設計に組み込む

🎯 結論

今週、全自動処理の指示ルールを外部ファイルから実行ファイルに直接埋め込む方式へ切り替えた。合わせて、自動実行環境で使用するモデルから特定の選択肢を除外するポリシーを明文化し、管理画面上で各処理がどの執筆ルールで動いているかを可視化した。動機はひとつ——「指示ルールが確実に参照されている」という保証を持てる構造にすることだ。

◾️ 背景：「ルールはある」が「参照されているか分からない」問題

自動化処理が増えるにつれ、ひとつの不安が膨らんでいた。各処理が「どのルールに従って動作しているか」が外から見えない。

指示ルールを外部ファイルや共有設定に分離していると、処理の構成が変わったときにルールの参照経路が静かに切れる。新しい処理を追加するとき、担当者が「このルールを適用すべきか」を個別に判断することになり、適用漏れが生じる。

問題の根はもっと深い。ルールが参照されているかどうかを確認する手段自体がない。実行ログには「何を出力したか」は残るが、「どのルールに基づいて判断したか」は残らない。品質の揺れを検知したとき、それが指示ルールの適用漏れなのか、モデルの確率的なばらつきなのか、入力データの問題なのかを区別できない。

インシデントが起きてから調査する負荷ではなく、構造として「参照漏れが起きえない」設計に変えることにした。

◾️ 判断1: 指示ルールの inline 化

外部ファイルに分離されていた「記事執筆上の制約・トーン・禁止表現リスト」を、各処理の実行ファイルに直接埋め込む方式へ変更した。

構造の変化

変更前:
実行ファイル → 「規律ファイルを参照せよ」という指示 → 外部の共有ファイル
                ↑
                参照経路が切れても誰も気づかない

変更後:
実行ファイルにルールを直接記述
                ↑
                ファイルが動く = ルールが適用される、が自明

inline 化には明確なトレードオフがある。ルールを修正するとき、参照箇所を一括更新できなくなる。「一箇所直したが他の処理には反映されていなかった」という問題が起きうる。

それでも inline 化を選んだ理由は参照保証を得るためのコスト比較だ。外部ファイルを参照する構造では、「確かに参照されているか」を検証する仕組みを別途設けなければならない。参照経路のテスト、参照先の存在確認、内容が最新かどうかの検証——これらを管理し続けるより、「実行ファイルに書いてある = 必ず参照される」という自明な構造を選ぶ方が、システム全体の認知負荷が低い。

コスト配分の問題だ。ルール変更のコストは「修正作業が増える」という形でメンテナーに集中する。参照されているかどうかの不確実性は「何が起きているか分からない」という形でシステム全体に拡散する。前者のコストを意識的に引き受けた。

◾️ 判断2: 無人実行に不適なモデルの除外

自動実行環境で使用するモデルのリストから、特定の選択肢（内部では「claude-9」と呼んでいた）を除外した。

除外の理由はシンプルだ。このモデルは対話的なセッションでは高い性能を発揮するが、無人実行との相性が悪い。長い指示を受け取ったとき、「意図を確認してから進める」という挙動を取ることがある。

対話的なセッションなら人間がその場で応答できる。しかし無人実行では確認を求められた時点で処理が詰まる。詰まった処理は「失敗」として記録されることすらなく、単に出力を生成しないまま終わる。翌朝確認すると記事が生成されていない、という状況だ。

この経験から、モデル選定のポリシーを更新した。

「デフォルトで最新・最高性能モデルを使う」から「無人実行に適したモデルを陽に指定する」への変更だ。最高性能と無人実行適性は独立した評価軸だ。ベンチマークのスコアが高いことと、24時間無人で止まらずに動くことは別の問題だ。自動化パイプラインでは後者を優先する基準を設けた。

◾️ 判断3: 執筆ルールの可視化

管理画面に「各処理が現在どの執筆ルールで動いているか」を一覧表示する機能を追加した。

これは inline 化と組み合わせてはじめて意味を持つ。inline 化によって「参照されている」という保証は得られた。しかし管理者が「今、どんなルールが各処理に適用されているか」を確認するには、個別の実行ファイルを開いて読むしかない。処理の数が増えると、この確認は現実的ではなくなる。

可視化の設計方針はひとつだけ決めた。実行ファイルから機械的に抽出して表示する。管理画面用に別途ルール定義を用意するのではなく、実行ファイルのなかの「規律セクション」を読み取って一覧に変換する。

この設計の目的は二重管理の排除だ。「管理画面に表示されているルール」と「実際に処理で適用されているルール」が乖離するリスクを構造的になくす。管理画面を更新しても実行ファイルには反映されていなかった、という問題が起きえない。

◾️ 教訓と SOP 化

原則 1: AI への指示は「参照される位置にある」を設計の要件にせよ

「書いてあれば読まれる」は人間向けドキュメントの前提だ。自動実行の文脈ではそうではない。指示が確実に参照される位置にあるかを、システム設計の段階で問わなければ、ルールは形骸化する。運用フェーズになってから「実は読まれていなかった」と気づくのでは遅い。

原則 2: 無人実行適性はモデル選定の独立した評価軸

モデルの性能評価は対話的な用途を前提にしていることが多い。自動実行では「止まらない」「確認を求めない」「長い指示を解釈しきる」という別の適性が求められる。これらは一般的な品質評価には含まれない。無人実行に使うモデルは、無人実行環境で実際に動かして検証した結果に基づいて選定せよ。

原則 3: 設定の重複は「どちらが本当か」問題を生む

管理画面用設定・実行用設定・ドキュメントに同じ内容が三箇所ある状態は、「どれが正しいか」を判断するコストを乗算で増やす。単一の情報源から機械的に生成・表示する構造にすることで、「更新したが反映されていなかった」クラスの問題を構造的に排除できる。同じ情報を複数箇所に書き直す作業は、誤りの温床だ。

今回の変更で「ルールの参照保証」「モデル選定ポリシーの明文化」「実行状況の可視化」という三つの問題に同時に対処できた。次の課題はルール変更の伝搬管理だ。inline 化によって参照保証は強固になったが、ルールを修正したとき「全処理に反映されたか」を確認する手段が現時点では手作業だ。処理数が現在の規模を超えてくると、この手作業は維持できなくなる。差分検出と一括更新の仕組みを設けることが直近の改善目標になる。