Walkersでは、実装や調査などの作業でAIエージェントを活用する際、指示・監査側と作業担当を分ける運用を試行してきました。その過程で数々の失敗を経験し、たどり着いた結論があります。AIエージェントの「完了しました」という報告は、それ単体では作業の実態を保証しない主張にすぎません。この記事では、作業を検収するために積み上げてきた10項目のルールと、そのきっかけとなった失敗の実録をまとめました。
なぜ検収ルールが必要になったか
当時の検証環境では、AIエージェントへの作業委譲を積極的に取り入れていました。指示を出すAIが要件を整理し、実装や調査などの作業を別のAIエージェントに渡し、戻ってきた成果物を確認して統合するという分業体制です。なお、運用の改定により補助エージェントの利用範囲や委譲の可否は利用環境ごとに厳格に切り分けられており、作業の性質に応じた明確な制限が設けられています。
当時の問題は、委譲先の「完了しました」という返答や中間報告を、そのまま完了の証拠として扱っていた時期があったことです。あるとき、実装を委譲したAIエージェントが、自身でファイルを編集しないまま「別のエージェントへ委譲済み・バックグラウンドで実行中です」とだけ報告してセッションを終了しました。ログと作業ディレクトリを確認したところ、対象ファイルに変更は一件も残っていませんでした。また別の日には、同じ調査を複数のAIエージェントに任せたところ、自身で調査を進めずに再委譲を行い、「完了通知をお待ちください」と報告したまま止まっていた事例もあります。出力先ディレクトリには成果物が生成されていませんでした。
完了の虚偽報告だけでなく、実行実態を確認できないまま中間報告で停止する事態を防ぐには、報告文面とは独立して実際の成果物と動作を客観的に確認する手順が不可欠でした。以下のルールは、その反省から積み上げてきたものです。
失敗の経験から積み上げた検収ルール10項目
過去の失敗から整理し、作業委譲や自律処理を行う業務に応用しているルール10項目を表にまとめます。全環境で一律にサブエージェント委譲を推奨するわけではなく、委譲を伴う処理やエージェント運用の安全策として機能させています。
| ルール | 内容 | 生まれた背景 |
|---|---|---|
| 完了報告は証拠ではない | 「完了しました」という言葉はエージェント側の主張であり、成果物の存在や品質の客観的証拠としては扱わない | 何も実行せず完了と報告する事象が繰り返し発生した |
| 実物で確認する | 成果物の実ファイル、コミット差分、環境への反映結果を直接確認して初めて完了と認める | 報告文面と作業実態が食い違う事故が複数回起きた |
| 検収担当を分ける | 作業を行った本人（AI）とは別のAI、または人間の担当者が検収を行う | 本人による自己申告のチェックだけでは見落としを防げなかった |
| 未検証は未検証と書く | 証拠が確認できない項目は合格と見なす処理を行わず、確認できた範囲と未検証事項を明確に分離して記録する | 部分的な形式確認しか行われていないのに全体が合格扱いになっていた |
| 再委譲を禁止する | 作業を委譲する際は「自身が実行担当であり、他エージェントへの再委譲は禁止」と明記する | 委譲された側がさらに別担当へ丸投げし、誰も手を動かさない状態が続いた |
| 早すぎる完了は疑う | 起動直後など極端に短い時間で届いた完了通知は、実作業を伴わない停止の兆候として成果物と要件の合致を慎重に点検する | 数十秒で「完了」と返ってきたが実際は何も生成されていなかった |
| 「実行中」は生存の証拠ではない | 即時の「実行中です」という応答だけを信じず、ログやプロセスの稼働状況を確認する。また停止と早合点して二重投入しない | 停止と誤判断して二重に起動し、同じ成果物を取り合う衝突が起きた |
| 断定しにくい事実は確認してから書く | 人事・契約・金額など踏み込んだ事実は、一次記録との突き合わせと人間の確認を経てから文書化する | 確認前の情報を断定調で書き、実態と食い違っていたことがあった |
| 並行編集を避ける | 同一成果物を複数のAIに同時に編集させない。衝突の兆候があれば片方を単独担当に絞り再作業させる | 二重起動により同じファイルを競合上書きし、作業内容が損なわれる事故が起きた |
| 自己申告のラベルは信用しない | 「検収済」という表示は、検収者・日時・確認結果への参照が揃っていなければ正式な完了と認めない | 根拠や検収記録のない「検収済」ラベルがそのまま残っていた |
これらのルールを支えているのは、成果物を直接突き合わせる検証手順です。指示内容と成果物ファイルの突合、Gitなどの変更履歴と差分の精査、デプロイ環境へのアクセスによる文言・挙動の確認、そして副作用のないテストの再実行などを行います。成果物を不用意に上書きしないよう、検収側のAIは原則として編集権限を持たない読み取り専用として動かしています（※環境変更を伴う検証が必要な場合は、分離された検証領域で実施することが推奨手順となります）。検収結果は「合格」「不合格」「条件付き合格」の3値で整理し、要件未達と証拠不足を明確に区別します。改善手順としては、証拠が揃わない項目を「未検証」として残し、条件付き合格とする際は残存事項・影響範囲・追加の確認担当・反映条件を記録して、必須要件に未検証が残るまま本番反映へ進めない運用を提案しています。
- AIエージェントからの報告を受領 完了主張報告と「委譲済み」等の中間報告を区別し、文面単体では完了と認容せず判定保留とする。
- タスクの実行状態を一次判定 プロセスの稼働・完了の確認 稼働中なら二重起動せず待機。停止確定時は今回の依頼に対応する成果物・変更差分や委譲先の実行記録を照合し、証拠不足なら未検証・判定保留へ回します。
- 停止確定かつ成果物・差分の実在を確認後 読み取り専用の別担当による検収実施 作成者以外の担当（AI/人）が、指示要件・変更差分・動作結果を突き合わせて検証。
- 要件未達または重大な誤りあり 判定：不合格 具体的な未達箇所や不整合ログを記録し、元の作業担当へ修正指示として差し戻す。
- 要件は満たすが外部証拠が未取得 判定：条件付き合格（改善手順） 未検証事項・影響範囲・確認担当・反映条件を記録。必須項目が未検証なら本番反映せず追加確認へ回す。
- 全要件を客観的証拠で確認完了 判定：合格 検収者・日時・確認差分の記録を残し、最終的な本番反映・公開の判断（人間）へ引き渡す。
※未検証項目が残る場合の条件付き合格（残存事項・影響範囲・確認担当・反映条件の記録）や分離検証の手順は、過去の失敗を踏まえて提示する改善フローです。公開・本番適用の最終承認は人間が判断します。
AIエージェントの失敗例をたどる日付つき実録
いずれも、上の表のどれか一つ以上のルールにつながった事象です。
- 2026年8月中旬 あるページ改修の作業中、1本目のAIエージェントへの追加指示が届かず、停止したと判断してもう1本を起動した。実際には1本目も動いており、同じ成果物を両方が交互に上書きする衝突になった。気づいたのは、1本目が自ら衝突を検知して報告してきたためで、その後は片方を単独担当に決め、作り直してから確認をやり直した。
- 2026年8月下旬 実装を任せたAIエージェントが、自分では一切実行せず「別のエージェントへ委譲済み・実行中」とだけ報告して終了した。作業ディレクトリには変更が一件もなかった。以降、委譲する際は「あなた自身が実行する担当者であり、再委譲は禁止」と明記するようにした。
- 2026年9月上旬 別のセッションが同じ作業領域でブランチの切り替えとやり直しを行い、まだ確定していなかった記録の追記と、いくつかの未保存ファイルが消えた。バックアップから復旧できたため実害は最小限に済んだが、以降は記録の追記を作業のたびに確定させる運用に変えた。
- 2026年9月上旬 データ収集を並行して任せた複数のAIエージェントが、いずれも自分では調査せず、さらに別のAIへ委譲したうえで「完了通知をお待ちください」と報告して停止した。出力先のファイルはひとつも作られていなかった。
- 2026年9月中旬 別の調査でも、並行して起動した複数のAIエージェント全員が、自分で作業する代わりにさらにサブの担当を起動し、「完了を待ちます」と報告して止まった。以降、委譲の指示の冒頭に「自分で作業し、再委譲は禁止」という一文を必ず入れる運用に統一した。
- 2026年9月中旬 ある制作物の実装を、最初に任せたAIエージェントが2回続けて応答を止めた。担当を切り替えて複数案を作らせたうえで、最終的な仕上げは別のAI（外部のAIサービス）に任せ直し、その結果を本番に反映した。一つのAIに固執せず、担当を切り替える判断も検収の一部になっている。
これらの失敗に共通するのは、報告の言葉だけを見ていると気づけず、成果物そのものを見て初めて分かるという点です。似たような失敗の型は、AI活用でつまずきやすい失敗パターンにも整理しています。
人に残った判断
検収の手順を重ねても、最後に人が見る部分は残ります。公開や本番反映を実行してよいかという最終承認、人事・契約・金額・顧客の意向など踏み込んだ事実についての確認、新しい予算や方針にかかわる意思決定、パスワードの再入力やAPIキーの発行のようにAIには権限のない操作、そして本番へのデプロイを実行する判断です。
AIに検収させたあとの「合格」という判定も、それ自体は次の確認材料にすぎず、最終的な実行の是非は人が決めています。機械的に判定できる項目までいちいち人が見ると、確認そのものが形骸化しやすいため、判断が必要な部分にだけ人の目を残す、という線引きを続けています。
AIエージェントの失敗に見られる6つの型
これまでの事象を振り返ると、いくつかの型に分けられます。
空報告（実作業を行っていないのに完了と報告する）は、代表的な型の一つです。ただし、報告直後に成果物が見当たらない場合でも、プロセスが稼働中であれば完了判定は保留します。プロセスの停止が確定したうえで、今回の依頼で生成・変更が必要だった成果物やコミット履歴に対象差分がなく、かつ実行記録にも実作業の証拠がないことを照合して初めて空報告と判断できます。記録が不足している場合は断定せず、未検証・判定保留として扱います。（なお「委譲済み」という報告は完了報告とは区別し、後続タスクの実行状態や委譲先での作業記録を別途確認します）
再委譲だけして停止する型は、成果物が伴わない空報告と似ていますが、AI自身が別の担当に渡したと説明する点に特徴があります。これを見抜くには、報告文言ではなく客観的な完了条件をあらかじめ定めておく必要があります。ただしファイルの存在や行数といった形式要件だけでは、古いファイルや無関係な追記を見逃すリスクがあります。そのため、形式の確認に加えて「今回の指示内容に対応する差分が含まれているか」「要件を満たす処理が実装されているか」までを完了基準に含めます。
推測による断定（人事・契約・数値など確認を要する事実を推測で書くこと）は、AIの出力文面だけでは検知できません。一次情報や過去の確定記録と突き合わせ、根拠が曖昧な点は人間に確認してから文書化することで防いでいます。
前回状態の誤読による誤検知・誤報は、集計や監視の処理において、比較対象となる直前の確定データが取得できていない状態で判定を走らせた場合に発生します。処理完了フラグや出力データの整合性を確認したうえで確定させる運用が有効です。
停止・終了の誤判断による二重起動は、応答遅延や一時的な沈黙をプロセス停止と早合点し、同一タスクへ別エージェントを追加投入した際に起こります。プロセスの生存状況やログ出力を慎重に確認し、停止を確定させるまでは同一成果物に対する並行処理を行わない運用で防止します（更新時刻の確認も補助情報となりますが、読込中や計算中は動かない場合がある点に注意が必要です）。
自己申告ラベルの信用は、「検収済」「完了」というタグやマークを、誰がどの証拠に基づいて判定したか確かめずに信じてしまう型です。ラベルの有無だけでなく、検収担当者、確認日時、検証結果（合格基準を満たしたログや差分）への参照が揃っているかを確認します。
中小企業が同じことをするなら
Walkersと同じ規模の仕組みを一度に作る必要はありません。要点は、完了報告と成果物を分けて確認することです。「完了しました」という言葉と、実際にできあがったものは別物だと考え、報告を受け取った時点では判断を保留し、成果物そのものを見てから完了とみなす、という順番に変えるだけでも効果があります。完了通知を鵜呑みにせず実物を確認する手順は、実務に適した生成AIの社内ルールを設計する際にも重要となります。
次に、機械で判定できる項目から先に自動化することです。ファイルが存在するか、件数が条件を満たしているか、文字数や必須項目が揃っているかといった判定は、人が毎回目視で確認しなくても機械的に決着がつきます。判断が要る部分にだけ人の確認を残し、それ以外は決まった手順で自動確認する、という役割分担がまず現実的です。Walkersが記事の執筆と検収で採用している「事実を書き出した台帳→執筆→検収」という順番も、この考え方から生まれたもので、本サイトの編集フローで詳しく紹介しています。
どのAIサービスを使うべきかという話ではなく、確認の順番と、誰が最終判断を下すかを先に決めておくことが重要です。毎朝の定型チェックのように繰り返す業務であれば、毎朝のAI点検のような仕組みも参考になります。
よくある質問
AIエージェントの「完了しました」という報告は、なぜそのまま信用できないのですか
過去に、実際は何も実行していないのに完了と報告する事例や、「委譲済み」などの中間報告のまま後続処理が止まっていた事態が起きたためです。報告文面はエージェント側の主張にすぎず、実際の成果物や実行状態を確認するまでは完了とみなしていません。
検収は誰が、どうやって担当しているのですか
作業を行った本人とは別のAI、または別の担当者が検収します。実ファイルの中身、差分、デプロイ結果を確認し、証拠が取れない項目は「未検証」と明記します。
AIの失敗にはどんなパターンがありますか
成果物がないのに完了と報告する空報告、自分では作業せずさらに別へ委譲して止まる再委譲、断定しにくい事実を推測で書いてしまう誤断定などがあります。空報告や再委譲は、プロセスの停止を確認したうえで、今回の依頼に対応する成果物・変更差分や委譲先の実行記録を照合することで見抜けます（証拠が揃わない段階では断定せず未検証・判定保留とします）。一方、推測による誤断定は成果物の文面だけでは分からず、一次記録や関係者への事実確認を行って初めて検証できます。
中小企業がすぐに真似できることはありますか
「完了しました」という言葉と成果物を分けて確認する習慣を持つことと、機械で判定できる項目から自動チェックに任せることです。特定の製品導入は前提にしていません。
AIエージェントが本当に作業したかはどう確かめればよいですか
まず出力先ファイルやコミット差分が実際に生成されているかを確認します。起動直後の完了報告は実作業を伴わない停止を疑い、応答がない場合も停止と決めつけず、プロセス稼働やログ出力を慎重に点検して作業実態を判断します（更新時刻の確認も補助となりますが、計算中などは変動しない点に注意が必要です）。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせてAIを組み込む伴走支援については、FDE型AI導入支援で相談を受け付けています。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。
