AIは誤る前提で工程を組む

第1回の最後に、こう書きました。「このセッションで、AIは7回誤った。そのすべてが、ファイルへ書き込まれる前に検知されている。」第6回は、その7件を実際に開き、なぜ実害が生じなかったのかを書きます。

結論を先に書きます。誤りを無くす設計はしていません。誤りが実害になる前に止まる設計をしています。 この違いは小さくありません。

1. 実測せずに書いた「8個」は、実は12個だった

あるスクリプトで、追記文に含まれるバッククォートの個数を、実測せずに「8個」と書きました。 実際は12個でした。

これは自己検査によって検知されました。第4回で書いた完了確認の考え方を、スクリプト自身の自己申告にも適用しています。冒頭に「この追記文にはバッククォートが何個含まれるか」を定数として書き、実行前にその数を数え直して照合します。 数が合わなければ、そこで止まります。

ここでの教訓は、対象が広いものです。「実測してから期待値を書く」は、ファイルの実測値だけでなく、自分自身が書いた文字列の属性にも当てはまります。 自分で書いた文章の中の記号の数を、自分は正確に把握していない——これは、人がコードレビューで見落とす感覚と同じものです。

2. アンカーの末尾の記号を、目の前にありながら写し落とした

ある文書の行末をアンカーとして使う際、実測の出力には行末が太字の記号（**）で終わっていることが表示されていました。それを見ながら、末尾の記号を落として書きました。

結果、アンカーは0件でヒットし、そこで停止しました。実測値が画面に出ていたにもかかわらず、写し取る段階で情報が欠落しました。 これは「実測していない」誤りではなく、「実測した結果を正確に転記できなかった」誤りです。両者は原因が異なるため、対策も異なります。前者は実測を義務化すれば防げますが、後者は転記後にもう一度、実測値と転記結果を突き合わせる工程が要ります。

3. 手元の写しへ適用した事実を、報告し忘れた

ある起票用のスクリプトを、本番ではなく手元の写しへ適用したまま、その事実を伝えずに次の作業へ進もうとしました。

技術的には何も壊れていません。しかし、さくらが把握している状態と、実際の状態が食い違ったまま進行するという、性質の異なるリスクです。是正は、原本へ前段の手順を順に再現し、ハッシュ値が一致することで写しの状態が正当であることと、本番が未変更であることを確認する形で行いました。

これはコードの誤りではなく、報告の誤りでした。 「何をしたか」を漏れなく報告することも、検証対象の一部として扱っています。

4. 「数が等しいこと」で書いた検証条件が、正常な編集を止めた

課題管理表を更新するスクリプトで、「置換の前後で強調記号の数が等しいこと」を事前の検証条件に置きました。ところが、旧が4個、新が8個——数としては変わっている（4≠8）が、どちらも偶数であるという編集で、条件に引っかかって停止しました。

ファイルは正常であり、誤っていたのは検証条件の側でした。 正しい条件は「数が等しいこと」ではなく「偶奇が保たれること」でした。第4回で書いた「正しい条件が、正しい作業を止める」構図の、初出の一件です。

5. 表の本数を、実測せずに「8本」と述べた

ある文書のある行にあるパイプ記号（表の区切り）を「8本」と述べました。実際は6本でした。 8本は別の章にある別の表の本数であり、参照する行を取り違えていました。

この誤りは、検証用に作った合成ファイル（本番に似せた再現用のファイル）を組み立てる段階で検知されました。 実測すべき値を、別の実測値と混同するという誤りは、単純ですが起きます。件数を扱うときは、「どの行の、どの表の」本数かを、値と一緒に書くようにしています。

6. 実文を確認していない箇所を、参考所在に含めた

仕様書の「参考所在」に、実際の文章を確認しないまま2箇所を含めました。 一つは表示順序についての記述で、是正条件には該当しないものでした。もう一つは画面の説明文であり、設定項目の列挙ではありませんでした。

どちらも、調査ラウンドの報告の要約だけを見て書いたことが原因です。ここで機能したのが、第2回で書いた「除外条件」の設計でした。仕様書に「参考値であり網羅ではない」と明記していたため、TAKTは独自に是正せず、対象外として報告しただけで済みました。

もし参考所在を「行番号の一覧」として断定的に書いていたら、この2件はそのまま是正されていたはずです。 条件で書くという設計そのものが、仕様書を書いた側の誤りを吸収しています。

7. 実文を確認せずに、追随の指示を仕様書へ書いた

最後の一件は、性質が少し異なります。ある版数の追随作業で、対象の記述を「版数だけを差し替えればよい」と仕様書へ書きました。しかし実文を確認すると、それは版数の数字だけの行ではなく、「その版が何を反映したか」を述べる488字の説明文でした。 版数だけを機械的に差し替えると、内容と版数が食い違った、意味の通らない文章になるところでした。

この誤りは、TAKTの走査ではなく、ひかり自身が実文を確認して気づきました。 気づいた時点で作業を止め、判断を仰ぎました。仕様書はすでにコミット済みだったため、書き換えるのではなく、次のラウンドの指示文の冒頭で、その一文を無効化する形で対応しました。

8. 7件を並べて分かること

7件を並べると、原因は一つではないことが分かります。

誤りの種類	検知した仕組み
自分の書いた文字列を実測しなかった	自己検査（定数と実測の照合）
実測値を見ながら転記を誤った	アンカー0件による停止
実施した事実を報告しなかった	—（気づいて自主的に是正）
検証条件の立て方を誤った	偶奇ではなく数の一致で判定していたことによる誤検知
実測値を別の値と混同した	合成ファイルでの試走
要約だけを見て断定した	除外条件の明記（TAKT側の設計）
実文を確認せず指示を書いた	実文確認（人＝ひかり自身の気づき）

検知した仕組みは、毎回同じではありません。 自己検査で拾われたもの、TAKTが仕様書どおりに動いたことで実害化しなかったもの、そして人（ひかり）自身が実文を見て気づいたもの——複数の異なる仕組みが、それぞれ違う種類の誤りを拾っています。

これは偶然ではありません。第2回から第5回まで書いてきた「条件で書く仕様書」「実測に基づく検証」「壊れる前に止める完了確認」「gitに頼らないバックアップ」は、それぞれ単体でも機能しますが、どれか一つが漏れても、別の仕組みが拾う設計になっています。 7件のうち、もし1つの仕組みしか無かったら、少なくとも数件は書き込みまで進んでいたはずです。