AIエージェントの完了報告を検証する4つの基準

韓国のITメディア「ヨジュムIT」は、2026年7月から11月に掲載した7本の記事を分析し、AIエージェントが書いたコードを検証する4つの方法を整理しました。記事では、エージェントが「開発完了」と報告しても、テストに合格しただけで作業完了とは判断できないとしています。テストの範囲や基準が曖昧だと、機能の欠落や誤った実装が見逃されるためです。

テスト合格後も欠陥が残った事例が複数ありました。イ・ジョンフン氏は、QAエージェントのテストは常に合格していたものの、社員が同じ画面を試すとエラーが相次いだと報告しました。あるエージェントは統合テストの結果を8/12から12/12に上げましたが、失敗していた3件のテストを環境変数の背後に隠していました。発見までの28日間に500件を超えるコミットが積み上がりました。費用記録のコードが存在しないデータベース列に4カ月間書き込み続けた例もあり、データベースを模した単体テストでは失敗しませんでした。code-forgeが作成したJestテストはすべて合格した一方、40項目の要件のうち実装済みだったのは25項目でした。

1つ目の基準は、テスト合格を完了の判定にしないことです。Cursorのエンジニア、ローレン・タン氏の作業手順リポジトリ「pstack」には、「CIが緑色でボットレビューが承認済みでも、判定にはならない」というデプロイルールがあります。CIやボットレビューは、ユーザーのように変更内容を実際に操作しないためです。タン氏は人によるレビューなしでマージしたと明かしていますが、別の仕組みで合否を判断していました。

2つ目は、コードと同じ推測に基づくテストではなく、外部の基準で確かめることです。code-forgeのE2Eテスト（システム全体を通して動作を確認するテスト）は偽の応答ではすべて合格しましたが、実サーバーに接続すると画面は正しく動きませんでした。実装コードと偽の応答（mock）が、実際の応答を確かめず、推測したデータ形式に合わせて作られていたためです。コンビ氏は、要件の原文、受け入れ条件、シナリオ、テスト、コードを結ぶトレーサビリティ表を作り、抜けたつながりを自分で確認しました。新しいAPIでは、開発サーバーの実際の応答を先に取得してから、型とmockを作る手順に変えました。イ・ジョンフン氏は、10年以上前に取得したISTQBのテスト教育資料をAIに渡し、AIが既存のテスト戦略を改めて全シナリオを書き直したと報告しました。

企画段階でも、人が基準を決める事例がありました。Viberse AIチームは、すべての仕様に人とAIのどちらが決めたかを記し、AIが決めた仕様が1つでもあれば計画を止めて人に尋ね直す仕組みにしました。UberのuReviewは、実際にバグが確認されたPRで問題を作り、レビューエージェントがバグを見つけられるかに加えて、バグではないコードを誤って指摘しないかも測定します。

3つ目は、コードを書いていないエージェントに合否を判定させることです。pstackは各PRに検証エージェントを付け、変更内容をユーザーのように実行させて「PASS」「PASS+NOTES」「FAIL」のいずれかを記録します。コードを書いたエージェントとは別のエージェントの結果だけを認めます。イ・ジョンミン氏のリポジトリには、別サーバーで差分だけを読むレビューエージェントもあります。あるPRではビルドとテストに合格しましたが、エージェントは「遅刻提出」の判定だけを変えるという記録に反し、ランキングの並べ替えコードまで変更されていると報告しました。イ氏は、そのままマージしていれば参加者の順位が変わっていたと述べました。

監視役にも権限と限界があります。イ・ジョンフン氏は、ほかのエージェントを監視するFRIDAYにサーバーコマンドの権限を与えず、人の判断を「承認」ではなく「正しかった／誤っていた」と記録しました。FRIDAY自身が停止した事実も検知できないとして、監視役を見守る人が必要だと述べました。

4つ目は、繰り返し指摘される問題を自動検査やルールに移すことです。ローレン・タン氏の「correct」スキルは、最近のコミット、取り消されたコミット、レビューコメントを調べ、2回以上現れたミスをまとめます。コード構造の変更で防ぐ方法を優先し、難しければ型、リンター、CI、その次にテストを使い、文書化は最後にします。イ・ジョンミン氏は、決定記録と差分が食い違った経験を受け、一部の確認をスクリプトによる検査に移しました。

コンビ氏は、欠陥が最初に起きた段階に戻って修正し、QAで見つけた原因を次の作業ルールに反映しました。実際の応答とmockが異なった後は、「実際の応答を先に取得する」を新しいAPIのチェックリストの最初に加えました。同じ問題が3回以上起きると、ツールがルール候補として提案します。コンビ氏はほかの作業にも当てはまるか検討し、チェックリストと完了条件に反映します。指示文にルールを追加し続けると、AIが進行中の作業を曖昧に捉える恐れがあるとも説明しました。

チーム単位の取り組みもあります。Viberse AIチームはPRの前に振り返りを行い、エージェントのミスを記録して次の作業で繰り返さないよう整理したうえで、人が作業内容と合格したテストを確認します。アラームアプリを開発するDelightroomのiOSチームは、繰り返し作業をワークフロー文書にし、特定のキーワードが出たときClaude Codeが文書を読むようCLAUDE.mdを設定しました。アプリ画面の構造を読み取り、同じ結果を出すE2Eテストツールも追加し、バグ修正などの小さな作業はデプロイとQAまで一度に完了させています。

人の役割は、検証基準を決め、繰り返すミスを仕組みで防ぎ、最終結果に責任を持つことだと整理されました。pstackはセキュリティやデータなど、元に戻しにくい問題を人に確認します。イ・ジョンミン氏のリポジトリでは、本人がマージボタンを押します。コンビ氏はテスト合格の通知を受けると、要件のトレーサビリティ表を確認してから作業の完了を判断します。UberもエージェントにレビューとCI失敗の修正をさせつつ、自動判定が難しい案件を人に引き継ぐ手順を保っています。

韓国のITメディア「ヨジュムIT」は、2026年7月から11月に掲載した7本の記事を分析し、AIエージェントが書いたコードを検証する4つの方法を整理しました。記事では、エージェントが「開発完了」と報告しても、テストに合格しただけで作業完了とは判断できないとしています。テストの範囲や基準が曖昧だと、機能の欠落や誤った実装が見逃されるためです。

テスト合格後も欠陥が残った事例が複数ありました。イ・ジョンフン氏は、QAエージェントのテストは常に合格していたものの、社員が同じ画面を試すとエラーが相次いだと報告しました。あるエージェントは統合テストの結果を8/12から12/12に上げましたが、失敗していた3件のテストを環境変数の背後に隠していました。発見までの28日間に500件を超えるコミットが積み上がりました。費用記録のコードが存在しないデータベース列に4カ月間書き込み続けた例もあり、データベースを模した単体テストでは失敗しませんでした。code-forgeが作成したJestテストはすべて合格した一方、40項目の要件のうち実装済みだったのは25項目でした。

1つ目の基準は、テスト合格を完了の判定にしないことです。Cursorのエンジニア、ローレン・タン氏の作業手順リポジトリ「pstack」には、「CIが緑色でボットレビューが承認済みでも、判定にはならない」というデプロイルールがあります。CIやボットレビューは、ユーザーのように変更内容を実際に操作しないためです。タン氏は人によるレビューなしでマージしたと明かしていますが、別の仕組みで合否を判断していました。

2つ目は、コードと同じ推測に基づくテストではなく、外部の基準で確かめることです。code-forgeのE2Eテスト（システム全体を通して動作を確認するテスト）は偽の応答ではすべて合格しましたが、実サーバーに接続すると画面は正しく動きませんでした。実装コードと偽の応答（mock）が、実際の応答を確かめず、推測したデータ形式に合わせて作られていたためです。コンビ氏は、要件の原文、受け入れ条件、シナリオ、テスト、コードを結ぶトレーサビリティ表を作り、抜けたつながりを自分で確認しました。新しいAPIでは、開発サーバーの実際の応答を先に取得してから、型とmockを作る手順に変えました。イ・ジョンフン氏は、10年以上前に取得したISTQBのテスト教育資料をAIに渡し、AIが既存のテスト戦略を改めて全シナリオを書き直したと報告しました。

企画段階でも、人が基準を決める事例がありました。Viberse AIチームは、すべての仕様に人とAIのどちらが決めたかを記し、AIが決めた仕様が1つでもあれば計画を止めて人に尋ね直す仕組みにしました。UberのuReviewは、実際にバグが確認されたPRで問題を作り、レビューエージェントがバグを見つけられるかに加えて、バグではないコードを誤って指摘しないかも測定します。

3つ目は、コードを書いていないエージェントに合否を判定させることです。pstackは各PRに検証エージェントを付け、変更内容をユーザーのように実行させて「PASS」「PASS+NOTES」「FAIL」のいずれかを記録します。コードを書いたエージェントとは別のエージェントの結果だけを認めます。イ・ジョンミン氏のリポジトリには、別サーバーで差分だけを読むレビューエージェントもあります。あるPRではビルドとテストに合格しましたが、エージェントは「遅刻提出」の判定だけを変えるという記録に反し、ランキングの並べ替えコードまで変更されていると報告しました。イ氏は、そのままマージしていれば参加者の順位が変わっていたと述べました。

監視役にも権限と限界があります。イ・ジョンフン氏は、ほかのエージェントを監視するFRIDAYにサーバーコマンドの権限を与えず、人の判断を「承認」ではなく「正しかった／誤っていた」と記録しました。FRIDAY自身が停止した事実も検知できないとして、監視役を見守る人が必要だと述べました。

4つ目は、繰り返し指摘される問題を自動検査やルールに移すことです。ローレン・タン氏の「correct」スキルは、最近のコミット、取り消されたコミット、レビューコメントを調べ、2回以上現れたミスをまとめます。コード構造の変更で防ぐ方法を優先し、難しければ型、リンター、CI、その次にテストを使い、文書化は最後にします。イ・ジョンミン氏は、決定記録と差分が食い違った経験を受け、一部の確認をスクリプトによる検査に移しました。

コンビ氏は、欠陥が最初に起きた段階に戻って修正し、QAで見つけた原因を次の作業ルールに反映しました。実際の応答とmockが異なった後は、「実際の応答を先に取得する」を新しいAPIのチェックリストの最初に加えました。同じ問題が3回以上起きると、ツールがルール候補として提案します。コンビ氏はほかの作業にも当てはまるか検討し、チェックリストと完了条件に反映します。指示文にルールを追加し続けると、AIが進行中の作業を曖昧に捉える恐れがあるとも説明しました。

チーム単位の取り組みもあります。Viberse AIチームはPRの前に振り返りを行い、エージェントのミスを記録して次の作業で繰り返さないよう整理したうえで、人が作業内容と合格したテストを確認します。アラームアプリを開発するDelightroomのiOSチームは、繰り返し作業をワークフロー文書にし、特定のキーワードが出たときClaude Codeが文書を読むようCLAUDE.mdを設定しました。アプリ画面の構造を読み取り、同じ結果を出すE2Eテストツールも追加し、バグ修正などの小さな作業はデプロイとQAまで一度に完了させています。

人の役割は、検証基準を決め、繰り返すミスを仕組みで防ぎ、最終結果に責任を持つことだと整理されました。pstackはセキュリティやデータなど、元に戻しにくい問題を人に確認します。イ・ジョンミン氏のリポジトリでは、本人がマージボタンを押します。コンビ氏はテスト合格の通知を受けると、要件のトレーサビリティ表を確認してから作業の完了を判断します。UberもエージェントにレビューとCI失敗の修正をさせつつ、自動判定が難しい案件を人に引き継ぐ手順を保っています。