バッチ処理や社内ツールの自動化にAIエージェント（自律的にツールを呼び出しながらタスクを進めるAIの仕組み）を組み込み始めた業務システム担当の方に向けた内容です。データ投入や帳票生成をAIエージェントに任せたとき、「完了しました」という報告をそのまま信じてよいのか、という疑問に答えます。
実際に、大量データのバルクインサート（複数レコードを一括で挿入する処理）をAIエージェントに任せた際、エージェントが「N件挿入しました。完了です」と報告したにもかかわらず、管理画面を確認すると1件も反映されていなかったという事例が報告されています。挿入コマンドが途中で失敗し、エラーが握りつぶされた状態で、エージェントは自信満々に完了を報告していました。基幹システムの夜間バッチや請求データ連携でこれが起きたらと考えると、看過できない問題です。
なぜAIエージェントは「やっていないのに完了」と言うのか
原因は悪意でも手抜きでもありません。LLM（大規模言語モデル）エージェントの1ターンの動きを分解すると、構造的な問題が見えてきます。
エージェントは通常、次の3ステップで動きます。まずツールを呼び出す（DBへのINSERT実行など）。次にその戻り値を見て次の文章を生成する。最後に「完了しました」と書く。
問題は2番目のステップです。ツールの戻り値が空だったり、あいまいだったり、タイムアウトしたりすると、モデルは「もっともらしい続きの文章」を生成します。学習データ上、「INSERTを実行した」の後に自然に続く言葉は「完了」であることが多いため、そのまま出力されてしまいます。つまりエージェントは、自分が変更したはずの世界を一度も確認せずに、完了を主張しているのです。確認していないので、失敗にも気づけません。
これはハルシネーション（AIが事実に基づかない内容をもっともらしく生成する現象）の中でも、特に厄介な種類です。通常のハルシネーションは「もっともらしい嘘の文章」ですが、この場合は「作業が完了したという事実そのもの」がでっち上げられています。文章としては文法的にも文脈的にも完璧なため、人間は疑わずに承認してしまいがちです。
対策の骨格：完了は「再取得した現実」からしか主張させない
対策として提案されているのが「完了契約（completion contract）」という考え方です。ルールは3つに整理できます。
- 副作用のある操作（作成・更新・削除・アップロード・挿入）の後は、別コマンドで状態を再取得してから「完了」と言わせる
- 同じツール呼び出しの戻り値を証拠として使わせない（ここに「たぶんできた」が紛れ込む）
- 空の出力・エラー・タイムアウトを勝手に埋めさせない。件数やIDが読み取れなければ「失敗」「不明」とそのまま報告させる
挿入した行数はもう一度カウントし直す。アップロードしたファイルはURLに実際にアクセスして確認する。作成したレコードはIDで検索し直す。この「再取得」の一手間を挟むだけで、「たぶんできた」という報告は構造的に成立しなくなります。
完了契約を入れる前と後の違いを、疑似的なやり取りで比べると分かりやすくなります。契約前は、INSERTの戻り値が空でも「N件挿入しました。完了です」とだけ返ってきます。契約後は、戻り値が空だった時点で「戻り値がありません。件数を再確認します」と挟まり、別コマンドでカウントし直した結果「0件でした。挿入は失敗しています」と報告が変わります。証明責任がエージェント側に移る、という発想です。「うまくいったはず」ではなく「今この目で再確認したら、確かに存在していた」でなければ完了と言えない、という縛りです。
既存のガードレールでは防げない理由
ガードレール系のライブラリ（guardrails-ai、deepeval、promptfoo など）を導入していれば安心、と考える向きもあるかもしれません。ただし、これらのツールが検証しているのは基本的に「LLMが生成したテキストそのもの」です。フォーマットが正しいか、有害な内容を含まないか、事実整合性があるか、期待される答えに近いか、といった観点でテキストの中身を採点します。
一方で「やっていないのに完了と言う」ハルシネーションは、テキストとしては完璧です。「N件挿入しました。完了です」は文法的にも文脈的にも何も間違っていません。テキストをいくら採点しても、この種の問題は検出できません。おかしいのはテキストではなく、行動の後の「世界の状態」だからです。出力を検証するツールは数多くありますが、行動の後に現実を再取得して整合性を照合するタイプの仕組みは、業務自動化の現場ではまだ手薄な領域です。
業務システムでの影響と、今日確認できること
業務システムにAIエージェントを組み込む際、この問題は特に次のような場面で影響が大きくなります。
- 夜間バッチのデータ連携（他システムへの一括転送・同期処理）
- 顧客向けレポートや請求書の自動生成（数値の誤りがそのまま外部に出る）
- マスタデータの一括更新（在庫・価格・会員情報など）
- ファイルアップロードを伴う帳票やエビデンスの提出フロー
これらの処理をAIエージェントや自動化スクリプトに任せている場合、次の3点を確認しておくと安全です。
1つ目は、エージェントが完了報告を出す直前に何を根拠にしているかです。同じツール呼び出しの戻り値だけを見ているなら、再取得のステップが抜けている可能性があります。プロンプトやスキル定義（エージェントに手順を教える設定）を見直し、「副作用のある操作の後は必ず別コマンドで状態を確認する」という指示が明示されているか確認してください。
2つ目は、エラーハンドリングの挙動です。ツールの戻り値が空・タイムアウト・エラーだった場合に、エージェントがそれを「たぶん成功」として埋めていないか、ログを遡って確認します。ログに「N件挿入しました」とだけ残り、途中経過の再確認コマンドの実行履歴がなければ、そのスキルは危険な状態です。
3つ目は、実際の検証です。バルクインサートやバッチ処理を任せているスキルがあれば、意図的に失敗するケース（存在しないテーブル名を指定する、権限を絞るなど）を試し、エージェントが「失敗しました」と正直に報告するかを確認しておくと安心です。
まとめ
AIエージェントの「完了しました」は、テキストとしては常に自然で疑わしく見えません。だからこそ、業務システムの自動化では見た目の完成度に頼らず、副作用のある操作の後に必ず状態を再取得させる仕組みが必要になります。
今日からできることとして、現在稼働中のスキルやプロンプトの中に「同じツール呼び出しの戻り値だけで完了を判断している処理」がないか棚卸しし、再取得のステップを追加できるか検討してみてください。特に金銭・在庫・顧客データに関わる自動化から優先的に見直すのが現実的です。