AIが「完了しました」と言った。そのまま閉じる前に見る3つの証拠
木曜の18時12分。翌朝に受付を始めるイベント申込サイトで、スマホ画面の修正をAIエージェントへ任せていた。
少し待つと、画面に報告が出た。
実装が完了しました。テストはすべて成功しています。
その文を見た瞬間、肩が下がった。今日はこれで終われる。あとは担当者へ「対応しました」と返して、PCを閉じたい。
そこへ、確認のメッセージが届く。
申込ボタンは、小さいスマホでも同意欄に重ならない状態ですか？
AIの報告にはテスト成功とある。変更したコードもそれらしく見える。「はい、大丈夫です」と返しかけた。でも、実際のスマホ幅で申込画面を開いた記憶はない。
確認を始めたら、また作業が増えるかもしれない。問題が見つかれば、「終わった」と思った安心まで取り消される。自分でAIへ頼んだのに疑うのも、使いこなせていないようで落ち着かない。
そのまま返事をする方が、今はずっと楽だ。ここで手が止まる😮💨
ただ、AIの「完了」は、頼んだ人が確認した完了とは限らない。作業を閉じる条件は、AIの報告文ではなく、自分が確かめた証拠で決める。
見る場所は3つに分けられる。何を変えたか。どんなチェックを実際に通したか。利用者が触る場面でどう動いたか。この3つだ。
「完了」の二文字で、確認まで終えたくなる
AIは、調査、実装、テスト、報告を短い時間でまとめてくれる。便利なのは間違いない。一方で、最後の報告が整っているほど、こちらは途中の不確かさを忘れやすい。
完了報告は、証拠そのものではない
「テスト成功」と書かれていても、何のテストを、どの変更のあとに、どの環境で動かしたかまでは一文から分からない。対象テストだけかもしれない。途中で直したあとに再実行していないかもしれない。画面を開かず、コード上の確認だけで終えているかもしれない。
これはAIが毎回うそをつく、という話ではない。報告は作業の要約だから、細かい条件が落ちる。人の「確認しました」でも同じことは起こる。
GitHubのAI生成コードのレビュードキュメントは、まず自動テストと、コードを実行せず問題を探す静的解析を動かし、警告やエラーを確認したうえで、要求や設計に合っているかを人が見る流れを示している。見た目が正しそうでも意図と違うコードや、直す代わりに削除・スキップされたテストへ注意するようにも書かれている。
さらに、GitHub Copilot cloud agentは自身でセキュリティ確認を行うが、それでも作ったドラフトPRを自分で承認・マージできない。人のレビューを通す仕組みになっている。
AIがチェックしたことと、その変更を受け入れてよいと人が判断することは、別の仕事だ。
確認が重いのは、仕事をやり直す感じがするから
分かっていても確認を飛ばしたくなるのは、怠けているからではない。「完了」と表示された時点で、頭の中では作業を終わった箱へ移しているからだ。
そこから画面を開き、差分を読み、テスト結果をたどると、閉じた箱をまた開ける感じがする。締切前ならなおさら、「問題が見つからないでほしい」という気持ちが先に立つ。確認が品質のためではなく、自分の安心を壊す作業に見えてしまう。
DORAの2025年レポートは、AIを組織の強みと弱みの両方を大きくする増幅器として整理している。変更を速く作れるようになれば、確認の仕組みが弱い現場では、未確認の変更を閉じる速さまで上がる。
だから、最後に「全部もう一度レビューしよう」と考えると重い。作業を3種類の証拠に分けた方がいい。確認する場所が決まると、終わりを取り消すのではなく、終わりに必要な材料を順番にそろえる作業へ変わる。
作業を閉じる前に、3つの証拠を見る
3つの証拠は、特別な監査資料ではない。普段の差分、コマンド結果、実画面を、同じ変更の証拠としてつなぐだけだ🔍
1. 変更の証拠: 頼んだ場所が変わり、余計な場所が変わっていないか
最初に見るのは、AIの説明ではなく、実際に変わったファイルと内容だ。Gitならgit diffで、変更前と変更後の差を一覧にできる。Gitを使わない仕事なら、更新した文書、設定、データの一覧でもよい。
イベント申込サイトの依頼は、「小さいスマホで、固定した申込ボタンが同意欄へ重ならないようにする」だった。見るべきなのは、ボタンのCSSが変わったかだけではない。
- 同意欄とボタンの間に必要な余白が入ったか
- PC表示や別画面まで一緒に変えていないか
- 一時的なログ、不要な設定、関係ない整形が混ざっていないか
- 依頼文の条件を、コードのどこで満たしたか説明できるか
ここでAIの説明と差分が食い違ったら、差分を正本にする。「このファイルだけ変えた」と報告されても、別の設定ファイルが変わっていれば、そちらも理由を確認する。
反対に、差分が大きいだけで怖がらなくてよい。生成ファイルの更新など、理由を説明できる変更もある。大切なのは行数ではなく、頼んだ条件と、変わった場所の対応が取れていることだ。
木曜の修正では、スマホ用のスタイルだけでなく、画面幅を再現するテストも追加されていた。ただし、テストがあることと、そのテストが本当に動いたことはまだ別だ。次の証拠へ進む。
2. 自動チェックの証拠: コマンド名ではなく、今回の実行結果を見る
次に、テスト、型チェック、Lint、ビルドなどの結果を見る。Lintは書き方の乱れ、型チェックは値の扱い、テストは決めた振る舞い、ビルドは配布できる形へ組み立てられるかを確かめるものだ。役割が違うため、一つ通っただけで全部を確認したことにはならない。
最低限、次の4点を残す。
- 実行したコマンド
- 実行した時刻か、どの変更時点かを示すコミット
- 成功件数と失敗件数
- 警告、スキップ、実行できなかった確認
「テスト済み」ではなく、「修正後に全117件を実行し、失敗0件。モバイルの見た目は自動テスト外」のように書く。そうすれば、別の人も確認済みと未確認を分けられる。
以前、テスト結果だけを見て安心したあと、実は最後の文言修正より前の結果だったことがある。結果の数字は正しかった。でも、今の変更を証明していなかった。そこからは、最後の編集後に必要なコマンドをもう一度動かし、結果を読んでから閉じるようにした。
GitHubのガイドが、AI生成コードで削除・スキップされたテストに注意するよう促しているのも同じ理由だ。緑色の結果だけでなく、何が実行対象から外れていないかまで見る。
3. 利用場面の証拠: 本番に近い条件で、利用者と同じ入口から触る
最後は、実際に使う場面での確認だ。Web画面なら対象URLを開き、想定する画面幅と操作順で触る。APIなら実際のリクエストを送り、返った値を読む。データ更新なら保存後の値をもう一度取得する。
NISTのAIリスク管理フレームワークは、テストや評価を記録し、実際に使う状況に近い条件で性能を示すこと、確認できない限界も文書に残すことを挙げている。開発中の一変更へそのまま適用する義務があるという話ではない。ただ、「実行したテスト」と「使われる場面」をつなぐ考え方は、日常のAI開発にも使える。
木曜の申込画面を幅390pxで開くと、固定ボタンは同意欄に重ならなかった。ところが、入力中にソフトウェアキーボードが開くと、画面の高さが縮み、エラーメッセージとボタンが重なった。自動テストは画面幅を見ていたが、入力中の高さまでは再現していなかった。
ここで「テストが役に立たなかった」と責める必要はない。テストが確認した範囲と、実画面で初めて分かった範囲が違っただけだ。問題を直し、入力、エラー表示、送信まで操作し、PC幅も崩れていないことを確認した。スクリーンショットも残した。
利用者が触る入口から一度通すと、コードの正しさを、仕事として使える状態へ近づけられる。
証拠をそろえると、未確認も言いやすくなる
3つの証拠を求める目的は、「全部を完璧に確認した」と強く言うことではない。むしろ、どこまで見て、どこから先は見ていないかを言えるようにすることだ。
未確認を書くのは、能力不足の告白ではない
AIへ任せた作業で「ここは未確認」と書くと、自分の詰めが甘いように感じることがある。相手から追加確認を頼まれそうで、黙って済ませたくもなる。
でも、未確認を隠すと、受け取る側はすべて確認済みだと思う。問題が起きた時に初めて境界が分かる。これは本人にも相手にも重い。
たとえば、こう書けばよい。
変更: スマホの固定ボタンと同意欄の重なりを修正。関連する2ファイルだけ変更。
自動チェック: 型チェック、全テスト、ビルドに成功。失敗とスキップはなし。
実画面: iPhone相当の幅で入力から送信まで確認。Android実機と本番データでは未確認。
これなら「大丈夫です」と根拠なく即答せずに済む。相手も、Android実機の確認を今やるか、公開後の監視で補うかを選べる。
未確認は穴を隠さず置くための情報だ。確認できた範囲を狭く正確に言える人ほど、次の判断を相手へ渡しやすい。
人の確認は、AIの仕事を全部やり直すことではない
人が最初からコードを書き直し、全ケースを手作業で試すなら、AIへ任せた意味が薄くなる。確認は、AIと同じ工程を繰り返すことではない。
AIには、変更候補を作る、テストを追加する、コマンドを動かす、結果を要約するところまで任せられる。人は、依頼と差分が合うか、結果が今の変更を証明しているか、利用者の場面で困らないかをつなぐ。
AIレビューで見る観点を持っていれば、複雑な変更は意図、影響範囲、テスト、運用リスクへ広げられる。AIで作ったPRを渡す時の4項目と組み合わせれば、確認した証拠をそのまま次の人へ渡せる。
確認する場所が決まると、AIを疑い続けなくてよくなる。信じるか疑うかの二択ではなく、証拠があるところまで受け取り、ないところだけ見に行けばいい。
次の1件は、3行で閉じる
木曜の担当者には、すぐ「大丈夫です」と返さなかった。重なりを直して再確認したあと、次のように返した。
スマホ幅で、入力、エラー表示、送信まで確認しました。修正後の全テストとビルドも成功しています。Android実機は未確認なので、必要なら明朝の公開前に追加で見ます。
完璧に見せる返事ではない。それでも、最初の「対応しました」よりずっと安心して送れた。何を見たかが自分でも分かり、相手が追加確認を選べるからだ🙂
次にAIが「完了しました」と返したら、作業を全部やり直さなくていい。閉じる前に、次の3行だけ埋める。
- 変更の証拠: 何が変わり、依頼のどの条件へ対応したか
- 自動チェックの証拠: 最後の変更後に何を実行し、結果はどうだったか
- 利用場面の証拠: 誰が使う入口で何を試し、何が未確認か
空欄があれば、そこだけ確認へ戻る。問題が見つかっても、振り出しへ戻ったわけではない。公開前に止められたという、仕事の一部だ。
AIの完了報告で作業を閉じず、3つの証拠がそろったところで閉じる。 その習慣が、AIで増えた速さを、説明できる品質へ変えていく。
