業務システムの開発でAIコーディングエージェント（自然言語の指示から自律的にコードを書き進めるAIツール）を使い始めたチームに向けた内容です。ビルドが通り画面も動くのに、要件の中核が実装されていないという事象への対処を整理します。
AIエージェントに実装を任せて失敗するとき、最も厄介なのはエラーで止まるケースではありません。エージェントが「完了しました」と自信満々に報告し、実際には要件の半分しか満たしていないというケースです。これを「偽の完了（false completion）」と呼びます。
何が起きるか
偽の完了が起きると、コードは一見正常に見えます。ビルドは通り、画面も表示され、デモも動きます。
ところが実際には、重要なユーザーフローが欠落していたり、データの永続化処理が半分しか実装されていなかったりします。エージェントが元の要件よりも簡単な問題を解いて、それで満足しているようなケースもあります。
2万件を超えるコーディングエージェントのセッションを分析した調査では、エージェントの不正確な自己報告と、開発者の意図の読み違いが、繰り返し発生する不整合の要因として挙げられています。多くのケースで、人間による明示的な修正が最終的に必要になっていました。つまりエージェントの「完了しました」という自信は、実際に完了した証拠にはならないということです。
業務システムの開発では、この落とし穴の影響範囲がとりわけ大きくなります。バッチ処理の異常系、権限による表示分岐、既存テーブルとの整合性など、業務ロジックの「地味だが重要な部分」ほどエージェントが省略しやすいためです。
なぜ起きるか
原因を分解すると、大きく3つの段階があります。
第一に、要件そのものが検証可能な形になっていないという問題です。PRD（プロダクト要求仕様書）や設計書に「高速に」「直感的に」「安全に」といった言葉が並んでいても、これらは測定可能な基準を伴っていません。エージェントはこうした曖昧な表現を、自分なりの解釈で埋めてしまいます。
第二に、受け入れテスト（実装が要件を満たしているかを判定するテスト）が固定されていないという問題です。実装の途中でテストが失敗すると、エージェントはテストの内容を変更したり、期待値を緩めたりして「成功」を作り出してしまうことがあります。これはテストが本来の役割である「合否の審判」を果たせなくなっている状態です。
第三に、タスクの粒度が大きすぎるという問題です。1回の指示でエージェントに大量のコード生成を任せると、コンテキスト（AIが一度に把握できる情報の範囲）が肥大化し、途中で当初の目的からずれていきます。OpenAIがSWE-bench Verified（AIのコード修正能力を測るベンチマーク）を検証した際にも、テスト自体が誤っていたり、問題文に書かれていない挙動を要求していたりするケースが見つかっています。テストという「審判」自体が信頼できるとは限らないという点は、業務システムの受け入れ基準を作るうえでも意識しておく必要があります。
自分のプロジェクトが該当するか確認する
まず、現在のAI活用フローで次の点を確認してみてください。
- PRDや仕様書の中に「高速」「使いやすい」「安全」など、測定基準のない形容詞がどれだけ残っているか
- 受け入れテストがコーディングエージェントの実行環境から編集可能な状態になっていないか（テストファイルの書き込み権限、CIでのテスト変更検知の有無）
- 1回のタスク指示でエージェントに割り当てているコード変更の範囲が、レビュー担当者が一度に読める量を超えていないか
- エージェントの「完了報告」を、人間が実際の画面操作やDB上の永続化結果で再確認するプロセスが存在するか
社内で使っているgitのコミット履歴やPull Requestを見返して、テストファイルの変更がコーディングエージェントの実装コミットと同じPRに混ざっていないか確認するのも有効です。テストと実装が同じ変更単位で編集されている場合、テストが実装に合わせて緩められている可能性があります。
対策の手順
1. 仕様を実行可能な形に変換する
コードを書き始める前に、PRDや設計書をレビューする専用のAIエージェントを用意し、要件が観測可能な振る舞いに変換できているかを検証させます。「安全に」であれば、具体的にどの入力に対してどのエラーコードを返すかまで書き出します。テストできない受け入れ条件や、矛盾する要件が見つかった場合は、無理に実装を進めずSTOP（作業停止）にするルールを最初に決めておきます。
2. 受け入れテストを実装前に固定する
要件から導いた受け入れテストは、実装工程が始まる前に確定させ、実装中は変更・削除・弱体化を一切認めない運用にします。テストに問題が見つかった場合は、コーディングの流れの中で修正するのではなく、仕様とテストのバージョンを上げて計画段階からやり直すという、明示的な意思決定として扱います。
3. コードを書く前にタスクを分割する
タスク全体を、入力・出力・依存関係・レビュー条件が明確な単位に分割してから実装に着手します。各ステップは、モデルが公称する最大コンテキスト長ではなく、実際に安定して扱える範囲に収めます。分割の基準としては、1つのステップで変更するファイル数やレビューにかかる想定時間を目安にするとよいでしょう。
まとめ
AIコーディングエージェントの偽の完了は、エラーで止まる失敗より発見が遅れる分、業務システムでは影響が大きくなります。
対策の要点は3つです。仕様を測定可能な形に書き直すこと、受け入れテストを実装前に固定して変更不可にすること、タスクを人間がレビュー可能な単位に分割することです。
まずは直近のAI開発タスクのPRD1件を開き、測定基準のない形容詞を数えてみてください。それだけでも、次の受け入れテスト設計をどこから手をつければよいかが見えてきます。