AIの「完成しました」を、何で確かめるか

「完成しました」は、AIの作業報告（Claim）です。役に立たないわけではありません。何を変え、何を試したつもりかを探す入口になります。ただし、その文章だけではコードも本番も変わりません。

確認根拠（Evidence）には、実行したテスト、対象のコミット、画面の観測、本番の応答、利用者による受入などがあります。大事なのは量ではなく対応関係です。別の版で成功した百件のテストより、今回の版と明示的につながった必要十分な証拠の方が強いことがあります。

コードが変われば、古いテスト結果はそのまま使えません。環境設定が変われば、本番確認も取り直す必要があります。受入条件が増えれば、以前の画面確認では不足します。証拠が古くなる条件を決めておかないと、記録が増えるほど誤認しやすくなります。

Developer Hubでは、作業報告と確認根拠を分け、根拠がどの対象へ結び付くかから状態を計算する考え方を採っています。これは「ダッシュボードが完了と言えば正しい」という意味ではありません。入力された根拠が古ければ、計算結果も古いままです。

確認役へ「問題ないですよね」と聞けば、元の結論を追認しやすくなります。変更の目的、差分、受入条件を渡し、作業者の自己評価とは別に、壊れ得る場所を探してもらいます。UIなら実際の画面、公開なら配信された版、業務なら代表例と例外を見ます。

軽い文言修正に全社受入は不要です。反対に、データ統合や権限変更を単体テストだけで受け入れることもできません。確認の重さは、AIを信用する度合いではなく、変更の影響と戻しやすさに比例させます。

CIの緑は便利です。ただ、緑という一色の表示には多くの違いが隠れます。単体テストが通ったのか、公開用の成果物を作れたのか、実際の画面が狭い幅でも読めるのか、公開先が今回の版を返したのか。それぞれは別の問いに答えています。全部を一つの成功表示として受け取ると、どこまで確認できたかが逆に見えなくなります。

特にAIが複数の変更を並行で作ると、確認結果と対象の版がずれやすくなります。テストを開始した後に別の変更が入り、結果だけを見ると成功している。あるいは、ローカルでは正しく見えたが、公開環境では設定やデータの違いで成り立たない。これはAI固有の失敗ではなく、変更と確認の対応を曖昧にしたときに起きる問題です。

そのため作業報告は、完了宣言ではなく確認への入口として扱います。何を変えたのか、どの版に対する結果か、どの環境で見たか、何がまだ未確認かをたどれるなら、報告は役に立ちます。たどれないなら、文章が丁寧でも証拠にはなりません。

文言を一行直す変更と、顧客データの統合や公開経路を変える変更を、同じ確認で受け入れる必要はありません。前者は差分、画面、リンクを確認できれば足りる場合があります。後者は、戻した場合に何が残るか、既存の記録を壊さないか、実際の利用条件で次の仕事まで進むかを見なければなりません。

ピース・ビズ グループでは、実装、テスト、本番確認、現場受入を別に扱う設計を進めています。ここで重要なのは、段階が多いことではありません。本番へ公開できたという事実は、公開できたことの証拠です。それだけで現場の仕事が置き換わった証拠にはなりません。逆に現場が使えたとしても、どの版で確認したかが分からなければ、次の変更へ安全に引き継げません。

AIの報告を信用するかどうかというより、何を受け入れようとしているかを先に決めます。対象、証拠、環境、受入条件が結び付いたときに初めて、完了という言葉に具体的な意味が生まれます。