システムを一度点検すると、いくつかの問題が見つかった。同じ名前のエージェント用スキルが異なる読み込み元にあり、エラーログには読み込み失敗がすでに記録されていた。揃っているはずの設定の複製には差が生じ、使われなくなった作業ディレクトリも名前の解決を妨げていた。どれか一つがシステム全体を止めたわけではない。それでも、次の実行を予測しにくくするには十分だった。
一番気になったのは、ディレクトリが残っていたこと自体ではない。以前の記録に「修正済み」と書いてあったことだ。その日の時点では、確かに解決していたのかもしれない。しかし、ツールの更新、ディレクトリの移動、読み込み元の変更が起きる。過去についての一文だけでは、今日の状態は判断できない。
修正は一度の行為だ。修正された状態が続いているかは、別の問いになる。
完了記録を、確かめられる条件に変える
私の記録には「解決済み」がいくつも残っていた。だが、肝心な後半がない。次に同じ問題が起きたら、どうやって気づくのか。スキル名の衝突なら、現在の読み込み元から判定できる条件に変えられる。実際に読み込まれるスキルに、読み込みを曖昧にする未承認の同名定義があってはならない。衝突した場合は両方の定義を示す。承認済みの例外は指定したファイルだけに適用し、三つ目の同名定義を自動的には許さない。古いノートに「完了」とあっても、それは合格の根拠にならない。
「またスキルが使えない」と誰かに言われるまで待つのとは違う。読み込み失敗は結果であり、名前の衝突は先に見つけられる条件だ。残存ディレクトリも同じだ。片付け忘れに見えても、読み込み元に入り込めば、解決器に複数の候補を与える。エラーだけを見ていれば、毎回故障の再発を待つことになる。条件を見ていれば、次に使う前に危険を見つけられる。
別の「解決済み」も条件に変えた。複数の設定が使われている間は、両方に存在し、同期する約束になっているファイルの内容が、正本から静かにずれてはならない。修正した日に同じでも、次に片方だけを編集すれば変わる。検査は共通のファイルを読み取って比較し、差分の場所を示すだけだ。欠けたファイルまで同期済みとは証明できず、ファイルを自動で上書きもしない。自動修復は残すべき変更を消すかもしれない。警告の後に同期するか、差異を残すか、構成そのものを変えるかは人が決める。
検査器にも修正が必要になる
最初の検査は完璧ではなかった。本来許される状態を故障と判定したことがある。赤い結果は判決ではない。実際のディレクトリと読み込みの挙動を見て、システムが壊れたのか、それとも条件が広すぎたのかを調べ直した。条件を直して初めて、その検査を続ける意味が生まれる。誤報が続けば、本当の後退が雑音に埋もれてしまう。
その後、運用構成を整理し、同期が必要な複数のコピーを持たなくなった。すると「コピーが一致しているか」を毎日確かめる検査のほうが古くなる。存在しないコピーを「合格」とは扱わず、理由を残して検査を無効にした。かつて必要だった保護策も、規則として書いたというだけで永久に正しくはならない。
この二つの修正を経て、継続的な再検証の意味が変わった。検査器は間違えない自動化の層ではない。検査の論理も事実に合わせて直す必要があり、前提には有効期限がある。
何を繰り返し確かめるべきか
すべての作業記録を日次ジョブにはしない。見張る価値があるのは、気づかないうちに後退し、その後の行動に影響し、現在の状態を低いコストで確かめられるものだ。スキル名、読み込み元、設定の整合性はこれに当てはまった。議論で本当に合意できたか、利用者が満足したかを、スクリプトが人に代わって判定することはできない。
重要な状態を「完了」と記録するなら、少なくとも四つを残したい。その時何を検証したか、今どう再検証するか、失敗時にどんな証拠が見えるか、前提が変わった時にいつ検査を廃止するか。これがなければ完了記録は単なるアーカイブだ。あれば、次に使う前に現実と照らし直せる。
それでも私は「修正済み」と書く。ただし、その言葉が示すのは過去の一度の結果であって、未来の毎日の保証ではない。
私の考え
今でも「修正済み」と記録する。ただし、再確認の方法、失敗時に残す証拠、検査を廃止する条件も併せて残す。完了記録が述べるのは過去の結果だ。今も成立するかどうかは、今の状態で確かめるしかない。