実装した本人に検収させない。別のAIに疑わせたら、通したはずの欠陥が出てきた
このサイトの開発はAIに任せていて、私は指示と判断をしています。あるとき、やり方をひとつ変えました。実装するAIと、それを検収するAIを、別々に立てるよう指示する。1日それで回した結果が思いのほかはっきりしていたので、AIと一緒にひとりで作っている人向けに書き残します。検収役は1日に7回立てました。そのうち、再現できる形で説明できるのは4件です。内訳はコードの不具合が2件、公開予定の文章の誤りが1件、私自身の計測のミスが1件。どれも、実装役の動作確認や私の確認では見つけられなかったものです。残りの指摘は表記ゆれや、直したあとの記録が残っていないものなので、数に入れていません。
分けかた
実装役には作業場所と触ってよいファイルを区切って渡します。並行して走らせるときは、担当ファイルが重ならないように切るところまでが指示です。ここが重なると、あとで差分がコンフリクトして、解消のときに片方の仕事が消えます。
検収役には、実装役の成果物の場所だけを渡して、3つの縛りを付けます。修正はするな、報告だけしろ。推測で書かず、実際にコマンドを流し、実際にブラウザで開いて確かめろ。そして、断定できないことは「判断できない」と書け。結果を分けるのは3つ目です。縛らないと、AIは確かめていないことを確かめたかのように書きます。
大事なのは、検収役に実装の経緯を渡さないことです。実装役は自分の置いた前提ごと仕事をしているので、その前提の中では正しく見えます。経緯を知らない検収役は前提そのものを疑うところから始めるので、違う種類の欠陥を見つけます。
出てきた欠陥の実例
抽象論だと伝わらないので、その日に実際に出た4件を並べます。最初の2件はコードの不具合で、実装役が動作確認を済ませ、私も差分を見て通していたものです。3件目は文章、4件目は私の計測です。
勝ったのに次へ進まなくなる変更。勝ち負けが決まったときに鳴る結果のジングルを、ページを開いた瞬間ではなく、鳴らす直前に読み込むよう変えようとしました。読み込みで720KB減る変更です。動作確認は通りました。ところが検収役は、こう指摘しました。音源を指定し直した時点で、曲の長さは「不明」に戻る。再生が終わったかどうかは終了通知で分かるが、通知が来ない環境のために予備のタイマーがある。その予備のタイマーは、曲の長さが分かっているときしか張られない。だから通知が来ない環境では、ジングルのあとの処理が呼ばれず、勝っても先へ進まない。コードの分岐を追った結果です。
この変更はやめて、読み込みを戦闘の始まりに前倒しする形にしました。ただしこれは、長さが不明になる確率を下げただけで、保証ではありません。その場では先送りにして、課題として残しました。3日後に、長さが不明のあいだも予備のタイマーを張るよう直しています。
共通化が単一障害点を作っていた。単一障害点とは、そこが壊れると全体が止まる1か所のことです。セーブの読み書きを共通モジュールに寄せたとき、検収役はそのファイルをわざと404にして、公開中の8本すべてを開きました。報告は、「読み込みに失敗すると全ゲームが、見た目は正常のまま全ボタン無反応になる」。共通化の前は各ゲームが自己完結していたので、この壊れ方は存在しませんでした。対策は、読めなかったときの代わりの定義を各ページに1行ずつ置くことです。ただ、これは共通化で消したはずの重複を、また増やしています。
公開予定の文章に混じった嘘。バックアップ機能の説明に「名前や連絡先のようなものは入っていません」と書いてありました。検収役が実際に書き出して中身を開き、プレイヤーが入力した名前が入っていることを確かめました。機能は正しく動いていて、文章だけが事実と違っていた。動作確認では出ない種類の欠陥です。
私自身の計測のミス。転送量の削減記録を、ディスクの占有量で数えていました。小さいファイルほど、実際より大きく出ます。これは実装役ではなく、指示を出していた私の間違いです。検収役は実装役と私を区別しません。それでいいのだと思います。
なぜ本人の検収では出ないか
人間のコードレビューと同じ理屈です。実装した本人は、自分が置いた前提を検証の外に置きます。「読み込みは済んでいるはず」「このファイルは配信されないはず」。テストはその前提の内側で書かれるので、前提が誤っていても全部通ります。
AIは特にこの傾向が強いと感じます。実装役は自分の書いたコードの説明がうまく、動作確認の報告も整っています。整っているほど、読む側は通したくなります。検収役を分ける意味は、疑う動機を構造で作ることです。信頼で解決しようとしない。
コストの感覚
検収は実装と同じくらいの手間がかかります。半日で終わる変更が1日になる感覚です。それでも続けているのは、出てきた欠陥の質のせいです。この日の4件は、どれも通常の動作確認では見落としやすいものでした。とくに最初の2件は、通知が来ない環境や読み込みに失敗した環境のときだけ起きるので、本番に出てから「たまに先へ進まない」という報告から追うことになります。その工数を思えば、検収の1回は安い買い物です。コードだけでなく、文章や測定の誤りも見つけられるのは、実装した本人が前提を疑わないからです。
ひとつだけ注意があります。検収役の報告にも誤りは混じります。うちでは検収の指摘も鵜呑みにせず、重いものは自分で裏を取ってから直しています。役割を分けるのは疑いを分散するためで、どこかを無条件に信じるためではありません。
まず小さな変更1件で、検収役だけ分けてみる
ひとりで作っていると、実装も確認も同じ頭でやることになります。AIに任せても同じで、書いたAIに確認させると、書いたときの前提がそのまま残ります。全部を分ける必要はありません。まず小さな変更1件で、次の順に試すと、効果が見えます。
- 実装が済んだら、別のAIを立てて、成果物の場所と確認してほしい対象だけを渡す。経緯は渡さない
- 縛りは前に書いた3つ。指摘には、再現の手順と、そう言える根拠を付けてもらう
- 重い指摘は、自分でも再現してから直す