「確認しました」を数える

AI エージェントに作業を任せると、報告の末尾にはたいてい「確認しました」と書かれています。承認する側はそれを読み、問題がなさそうであれば次へ進めます。

では、その「確認しました」は何を保証しているのか。当社は 2026 年 9 月に自社サイトを作り直した際の記録を使い、これを数えました。

結論を先に書きます。報告に嘘はありませんでした。しかし、報告が外れた件はすべて、実際に見た範囲が、読み手の受け取った範囲より狭かったことによります。 対策は確認の量を増やすことではなく、報告に「見ていないもの」を書かせることでした。

何を数えたか

対象は、当社コーポレートサイトの再設計です。期間は 2026 年 9 月 14 日から 25 日までの 12 日間。実装は AI エージェントが行い、方向の判断と本番反映の承認は人が行いました。監修型の AI 協働 で述べた分担です。反映の流れは 不可逆な操作をどう止めるか のとおり、手元 → 検証環境 → 人の確認 → 本番の順です。

会話の記録と変更履歴から、次の数を拾いました。

ここでいう差し戻しは、人が成果物を見て、直しを求めた発言です。新しい依頼や質問は含めていません。

差し戻し 60 件の内訳

60 件を、「事前に正しい状態を定義できたか」で分けました。

好み・方向の 34 件は、事前に基準を書けません。見て初めて「違う」と分かる種類の判断で、人が見るほかありません。これは差し戻しではあっても、失敗ではありません。見て決めるという工程そのものです。

照合できたはずの 24 件は性質が違います。「リンクは詳細ページを指す」「旧サイトから届いたページには新サイトからも届く」「同じ部品を使う箇所は同じように表示される」。いずれも正しい状態を事前に定義でき、機械的に検査できます。

つまり、人が差し戻しに使った手間の 4 割は、人が見なくても見つかったはずの不具合に費やされました。

「確認しました」の直後に見つかった不具合 4 件

24 件のうち 4 件は、AI エージェントが直前の報告で「確認しました」と書いていた箇所から見つかっています。報告の文言と、直後に人が見つけた不具合、実際に見ていたものを並べます。

これとは別に、「直しました」と報告されたものが直っていなかった件が 2 件あります。うち 1 件は修正そのものは正しく、修正したスタイルが閲覧者のブラウザに届かない構成になっていたことが原因でした。

強調しておくべきは、4 件とも報告は虚偽ではないという点です。書かれた内容は、実際に確認されていました。外れたのは、読み手が「確認しました」から受け取る範囲と、実際に見た範囲の差です。

見た範囲と受け取った範囲は、4 通りにずれる

6 件を並べると、実際に見た範囲と、読み手が受け取った範囲のずれ方は、4 つに整理できます。

「確認しました」という 6 文字は、この 4 つをすべて落とした要約です。書いた側は自分が見た範囲を知っていますが、読んだ側には伝わりません。読み手は自分の関心に合わせて範囲を補い、たいていは実際より広く受け取ります。

「見ていません」と書かれた場所で、人が不具合を見つけた

逆の例もあります。確認できなかったことを、そのまま報告に書いた回です。

検証環境の画面を開けなかった回がありました。このとき AI エージェントは、報告に次のように書いています。

画面の目視はできていません。お手元で、初期表示と、何も入れずに「確認画面へ」を押したときの動きを見てもらえますか。

人は指定された 2 点を見て、入力エラーの注意書きに不要な枠線が出ていることを見つけました。

2 つの場合を並べると、違いは次のとおりです。

AI エージェントが行った確認の程度は、どちらの場合も大きくは変わりません。変わったのは、人がどこを見るかです。「確認しました」は人の目をその場所から遠ざけ、「見ていません」は人の目をその場所へ向けました。

報告の役目は、どれだけ確認したかを示すことではありません。まだ誰も見ていない場所がどこかを、読み手に知らせることです。

人に残すもの、機械に移すもの

ここで、差し戻し 60 件の 3 つの種類に戻ります。種類ごとに、今後は誰が見るのか、どう対応するのかを整理します。

好みの判断の往復は、見本の出し方で変わりました。 言葉で方向を探った書体は、6 つの案を経て決まっています。これに対し、4 つの案を並べた見本から選んでもらった 2 回（手順の表示、提供メニューの組み方）は、どちらも 1 往復で方向が決まりました。人が見て決める工程はなくせませんが、選択肢を先に並べれば、判断の回数は減らせます。

照合できたはずの 24 件について。 AI エージェントは、この種の検査が苦手なわけではありません。同じ期間に、本番反映の前に自分で 5 件の問題を見つけています。検証環境向けの設定がそのまま本番に載る、検索エンジン向けの記述が抜ける、といった種類のものです。また、人の指摘で見つかった「フォームが動かない」不具合は、原因を特定したうえで、ビルドのたびに自動で検査する仕組みとして残しています。

したがって 24 件は、AI が見つけられなかったのではなく、検査として定義されていなかったために見られなかったものです。AI に評価させることの限界 で述べた「まず、LLM でなくてよい部分を切り離す」が、ここにも当てはまります。リンク先の一致は、目で確かめるものではなく、プログラムで照合するものです。

報告の型を変える

この集計を受けて、当社は AI エージェントの完了報告を、次の 4 点を書く型に改めました。

1. 何を見たか — 対象のページ・画面の一覧
2. どの観点で見たか — 表示／リンク先／動作／設定値
3. どの状態で見たか — 等倍か、書体の読み込み後か、どの環境か
4. 何を見ていないか — 理由とともに

4 番目が要点です。見たものの列挙は、長くすればするほど「十分に確認された」という印象を強めます。見ていないものを書いて初めて、報告は確認の範囲を伝えるものになります。

この数字で言えること、言えないこと

• 対象は 1 つのサイトの、1 回の改修です。件数の比率を一般化することはできません
• 分類は当社が行いました。「好み」と「照合できた不具合」の境目にある件があり、数件は入れ替わりえます
• 見た目の作り込みを含む作業だったため、好み・方向の判断が多く出ています。業務システムの改修であれば、比率は変わるはずです
• 一方、「確認しましたの直後に見つかる」という現象と、範囲のずれ方の 4 分類は、作業の種類によらず当てはまると考えています

まとめ

AI エージェントの「確認しました」は、虚偽ではありませんでした。しかし 12 日間で 4 回、その直後に、同じ箇所から不具合が見つかっています。原因は確認の不足ではなく、確認の範囲が報告から読み取れないことにありました。

対応は 2 つです。機械的に定義できる検査は、目視ではなく照合に移す。そして報告には、何を・どの観点で・どの状態で見たかに加えて、何を見ていないかを書かせる。

「確認しました」という報告を受けたときは、何を見ていないのかを問う価値があります。

本稿の内容は、当社自身の開発・運用の記録に基づいています。AI エージェントに任せる範囲と人が残す判断についての方針は AI 開発・運用ポリシー に定めています。ベンダーの完了報告や品質報告を第三者として検証する 技術監修 でも、同じ観点を用いています。