第2回で、仕様書を「行番号の一覧」ではなく「条件」で書くようにした話を書きました。その狙いは、人が見落とした該当を、実装を全文走査するエージェントの側で拾わせることでした。
最終回は、それが実際に起きた場面を書きます。TAKTが、人の作った一覧にも仕様書にも無かった乖離を、自ら見つけた実例が3つあります。
1. 誰も挙げていなかった一覧
設計文書への反映作業で、走査が2件の該当を検出しました。
- ある章の設定キー一覧に、新設した2つのキーが載っていなかった
- 別の節の記述が、処理の起動時刻を固定値かつ特定のタイムゾーン固定として述べていた（実際には設定変更が可能になっていた）
この2件が示すことは、単に「見落としがあった」ということではありません。調査ラウンドの報告も、その報告を読んで書いたひかりの仕様書も、どちらもこの章を一度も挙げていませんでした。
つまり、人（ひかり）が2段階の工程を経て作った一覧に、この2件は最初から入っていなかったのです。 条件による走査でなければ、そのまま取りこぼしていました。
2. 仕様書に書いていないことを、TAKTが直した
もう一つは、性質が異なります。
あるテストの是正作業で、期待値が旧い仕様のまま残っていた箇所を直す指示を出しました。仕様書には「改めた箇所にコメントを残す」としか書いていませんでした。
ところがTAKTは、そのファイルの冒頭にあるコメントが、旧い仕様を断定的に説明していることを自ら見つけ、あわせて是正しました。
期待値だけを直していれば、そのコードの冒頭に、誤った前提を説明するコメントが残り続けるところでした。 テストは通りますが、次にそのファイルを開いた人は、冒頭のコメントを読んで誤解します。最も見つかりにくい種類の負債です。
3. 判断を仰いだ場面
三つ目は、TAKTが「直さなかった」例です。
同じ作業で、TAKTはある群のテストについて「これは仕様判断を要する」と報告し、そこで止まりました。実装を直すべきか、テストの期待値を直すべきかが、コードだけからは判定できないという理由でした。
この報告は正しいものでした。 課題管理表を確認すると、その論点についての方針が、過去の課題の記録として残っていました。コードには書かれておらず、資料の側にしか存在しない情報でした。
ここで重要なのは、TAKTが「判定できない」と正しく述べたことです。もし推測で片方を選んでいたら、確定済みの方針と食い違う実装になっていた可能性があります。
4. 3つの例から見える線引き
この3つは、それぞれ違うことを示しています。
| 場面 | TAKTの振る舞い | なぜ正しかったか |
|---|---|---|
| 一覧に無い該当を発見 | 条件に該当するものとして報告 | 仕様書が「条件」で書かれていたため、一覧の外まで探せた |
| コメントの旧仕様を是正 | 仕様書に無いことを、自ら是正 | 是正の目的（旧仕様の記述を残さない）に照らして一貫していた |
| 仕様判断が必要と報告 | 判断せず、止まって報告 | コードの外にある情報が必要であり、推測すれば誤りえた |
2番目だけが「仕様書に無いことをした」例です。 これを許容してよかったのか——連載を通して「指示にないことは独自に判断させない」と書いてきた立場からすると、矛盾するように見えるかもしれません。
しかし、2番目は「是正の対象を広げた」のではなく、「同じ是正を、同じ理由が当てはまる箇所に適用した」ものです。 旧い仕様の記述を残さないという目的は、期待値にもコメントにも等しく当てはまります。目的の範囲内での適用は、範囲の逸脱ではありません。
一方、3番目で止まったのは、目的そのものが定まっていなかったためです。「実装が正しいのか、テストが正しいのか」は、是正の目的の定義に関わる問いであり、コードからは決められません。
この線引きは、実は第7回で書いた人間側の作法とまったく同じ形をしています。 任された範囲では決める。任されていない範囲では止まって報告する。同じ原則が、人にも、対話AIにも、実装エージェントにも適用されています。
5. 走査を「書き込みの後」に置く
ただし、この自律性には条件があります。走査は、書き込みの前ではなく後に置きます。
これは経験から定まった順序です。先に走査させると、TAKTがその結果を踏まえて、編集範囲を自ら広げる余地が生まれます。 走査で見つかった該当を、そのまま「ついでに」直してしまえる状態になります。
そこで、書き込みを終えてから走査させ、該当が見つかっても「是正せず報告する」という形にしています。冒頭で挙げた2件も、この形で報告され、次のラウンドとして人が判断してから是正しました。
自律的に発見させることと、自律的に是正させることは、分けて設計できます。 発見の範囲は広く取り、是正の範囲は狭く保つ。この2つを混ぜないことが、走査を安心して任せられる条件になっています。
6. 連載のまとめ——8回で書いてきたこと
全8回を通して書いてきたことを、最後に整理します。
- 三層構造——人が決め、対話AIが仕様と検証条件を設計し、実装エージェントが実装する
- 仕様書は条件で書く——一覧は書いた人が見つけた範囲でしかない
- 報告ではなく検証手段を疑う——誤っているのは、たいてい確認コマンドの側である
- 完了確認は「止まる条件」まで書く——数値を報告させるだけでは足りない
- バックアップは作業の外側に置く——gitの挙動を把握しないまま復元に使わない
- 誤りは消せない、拾う——1セッションで7件、すべて書き込み前に検知された
- 工程は人の実行回数で数える——最適化すべきはAIの手間ではない
- 発見は広く、是正は狭く（本稿）
この8つに共通するのは、どれもAIの性能の話ではないということです。 より賢いモデルが出れば不要になる工夫は、この中に一つもありません。むしろ、エージェントが賢くなるほど、「どこまでを任せ、どこで止めるか」の線引きは重要になります。
第1回に書いたとおり、この連載は成功談ではありません。書いてきたのは、誤りの記録と、その誤りが実害になる前に止まった仕組みの話です。 誤りが7件あったセッションを「うまくいった日」と呼べるのは、7件すべてがどこかで止まったからにすぎません。
AIと開発するとは、AIに開発させることではありません。 誤りうる主体を複数並べ、それぞれが違う種類の誤りを拾えるように工程を組み、そのうえで人が決める——そういう作業のことです。
この連載が、同じ問題に取り組んでいる方の参考になれば幸いです。 8回にわたりお読みいただき、ありがとうございました。
参考リンク
動画作成には自信があります！
