AIエージェントが『承知しました』と返したら、依頼は完了ですか？
完了とは限りません。受付、資料取得、下書き、人の確認、送信・登録のどこまで進んだかを確認します。受付時は次の処理を示し、必要な処理と確認がそろったときだけ完了と伝えます。
AI AGENT BASICS / ARTICLE 45
AIエージェントの実行状態を分ける方法｜受付・処理中・確認待ち・完了を混同しない
AIエージェントの受付、処理中、人の確認待ち、完了、保留・失敗を分け、利用者へ現在地と次の行動を正確に伝える方法を解説します。
この記事の目次
SHORT ANSWER
まず、結論から。
結論依頼を受け付けた時点では『受付済み』と伝え、実行結果と必要な確認がそろったときだけ『完了』にします。処理中、人の確認待ち、保留・失敗を別の状態として持ち、各状態に担当者、根拠となる記録、期限、次の行動を付けます。画面、通知、台帳で同じ状態を使い、再試行や引継ぎでも元の依頼を識別できるようにします。
AIエージェントが『承知しました』と返しても、資料の取得、下書き、人の確認、送信や登録まで終わったとは限りません。受付、処理中、人の確認待ち、完了、保留・失敗を分け、各状態に担当、証拠、期限、次の行動を結びます。利用者への案内と内部記録をそろえ、二重実行や確認漏れを防ぎます。
主な対象
AIエージェントの導入・運用責任者問い合わせ、文書作成、登録・送信業務を設計する担当者AIの処理結果を確認・承認する業務責任者
KEY POINTS
この記事の、4つの要点。
- 受付済み、処理中、人の確認待ち、完了、保留・失敗を同じ言葉で管理する
- 各状態に担当、入力、出力、証拠、期限、次の行動を結び付ける
- 完了条件を業務ごとに決め、返答や処理受付だけで完了にしない
- タイムアウト、再試行、取消し、引継ぎを元の依頼へ結び、二重実行を防ぐ
ACKNOWLEDGEMENT IS NOT COMPLETION
返事が届いた時点で、仕事を完了にしない。
問い合わせを送ると、AIエージェントからすぐに『承知しました』と返ることがあります。しかし、その返事が意味するのは、依頼を受け付けたことなのか、必要な資料を取得したことなのか、回答案を作ったことなのか、送信や登録まで終えたことなのかが分かりません。利用者は返事を完了と受け取り、同じ依頼を別の担当者へ出したり、未確認の内容を使ったりすることがあります。
最初に、会話の返答と業務の進み具合を分けます。受付時には依頼番号、対象、受け付けた時刻、次に行う処理を示します。まだ結果がないなら、完了を思わせる表現は使わず、現在の状態と確認予定を伝えます。
NIST AI RMF Coreは、人とAIの役割、監督、責任を定義し、運用中の機能や振る舞いを継続して確認する考え方を示しています。実務では、AIが返事をした事実だけでなく、誰がどの結果を確認し、どの条件で次へ進めたかを追える状態にします。
- 受付済み
- 依頼を受け取り、対象と次の処理を確認した
- 処理中
- 資料取得、検索、下書き、照合などが進行している
- 人の確認待ち
- AIの作業は終わり、承認や判断を待っている
- 完了
- 必要な処理と確認が終わり、結果を利用できる
- 保留・失敗
- 進められない理由と再開条件が分かっている
DEFINITION OF DONE
完了の意味を、仕事ごとに具体化する。
同じ『完了』でも、仕事によって必要な条件は違います。案内文の下書きなら、承認済み資料を参照し、指定形式で案を作り、根拠を示すところまでがAIの完了です。顧客への送信は別の業務であり、宛先、内容、権限を人が確認してから実行します。台帳更新なら、入力案の作成と実データへの反映も分けます。
完了条件には、成果物の有無だけでなく、使った資料の版、対象、確認者、承認、外部操作の結果を含めます。画面に『成功』と表示されても、別システムへ反映されていない場合があります。必要なら、更新後の値や送信結果を読み直し、期待した状態と一致したことを確認します。
デジタル庁の生成AIガイドライン第2.0版は、利活用の促進とリスク管理を一体で進める枠組みを示しています。自社では、速く処理を始められることと、安全に完了を確認できることを同じ業務設計へ入れます。
- 文章作成
- 必要な根拠、指定形式、禁止表現、確認者がそろったか
- 問い合わせ
- 一般案内で終わるか、個別確認や専門引継ぎが残るか
- 登録・更新
- 対象、変更前後、実行権限、反映結果を確認したか
- 送信・公開
- 宛先、公開範囲、承認、配信結果を確認したか
- 定期処理
- 対象期間、件数、未処理、次回条件を確認したか
EVIDENCE AND OWNER
状態の名前だけでなく、証拠と次の行動を結ぶ。
状態を増やしても、担当者が見る画面と利用者への通知が別々に更新されると、かえって混乱します。一件の依頼に共通の識別子を付け、受付、実行、確認、完了の記録を同じ案件へ結びます。再試行や担当変更でも、新しい依頼として数え直しません。
各状態には、担当、開始時刻、最後に確認した時刻、使った入力、作成した出力、根拠となる記録、次の行動、期限を付けます。人の確認待ちなら、誰が何を見るかを示します。保留なら、不足している情報と再開条件を示し、理由のない『処理中』を長く残しません。
通知文は台帳の状態から作り、AIが推測で進捗を補わないようにします。利用者向けには必要な範囲だけを伝え、内部エラーや個人情報、認証情報をそのまま表示しません。説明できることと、安全に開示できることの両方を満たします。
- 依頼ID
- 同じ案件の受付、再試行、引継ぎを結ぶ
- 担当
- AI、人、部門、外部サービスのどこにあるか
- 証拠
- 取得結果、作成物、承認、反映後の確認記録
- 期限
- 次の確認時刻、回答予定、期限超過の扱い
- 次の行動
- 待つ、確認する、追加情報を出す、再開する
RETRY, CANCEL, HANDOFF
例外が起きたときほど、元の依頼を見失わない。
通信が途切れた、外部サービスから返事がない、担当者が不在、利用者が依頼を取り消した。このような場面で同じ処理をすぐにやり直すと、二重送信、二重登録、重複請求につながることがあります。まず、相手側で処理が終わっていないかを確認し、未実行と確定した場合だけ再試行します。
再試行は元の依頼IDへ回数、理由、開始・終了、結果を追加します。取消しは受付と実行の間だけ可能なのか、外部操作後は取り消せないのかを決めます。人へ引き継ぐ場合は、会話全文を丸ごと渡すのではなく、依頼、確認済みの事実、未確認事項、実施済みの操作、次の判断をまとめます。
失敗を完了へ言い換えず、原因が分からない場合は不明と記録します。復旧の見込みを約束できないときは、再開条件と代替手順を案内します。AIが自分で解決できる範囲と、人や管理者が判断する範囲を事前に分けておくことが、例外時の安心につながります。
- タイムアウト
- 相手側の処理結果を照合してから再試行する
- 再試行
- 元の依頼ID、回数、理由、結果を残す
- 取消し
- 取消し可能な状態と、完了後の訂正手順を分ける
- 引継ぎ
- 確認済み、未確認、実施済み、次の判断を渡す
- 失敗
- 原因、影響、残る作業、再開条件を示す
ACCEPTANCE TEST
導入前に、正常系と止まる場面を通して試す。
状態設計は、一覧表を作るだけでは完成しません。実際の担当者が、依頼を受け、AIが処理し、人が確認し、結果を利用するところまで通して試します。正常に完了する一件だけでなく、資料不足、承認者不在、外部サービスの遅延、重複依頼、取消し、権限不足も用意します。
確認するのは、AIの回答だけではありません。画面、メールやチャットの通知、案件台帳、外部システムの記録が同じ状態を示すかを見ます。利用者が『次に何をすればよいか』を理解できるか、担当者が期限超過や確認待ちを見つけられるかも確かめます。
NIST AI RMF Playbookは、運用環境に近い条件でのテスト、結果の文書化、警告後の人による確認や行動記録を提案しています。小さな一業務で状態遷移を確かめ、未完了を完了に見せないこと、止まった仕事を再開できることを合格条件にします。ここで示す内容は一般的な活用例であり、個別の導入実績や効果を示すものではありません。
- 受付後に、依頼ID、対象、次の処理が案内される
- 処理中と人の確認待ちを、利用者と担当者が区別できる
- 完了時に、成果物、承認、反映結果がそろっている
- タイムアウトや再試行で、送信・登録が重複しない
- 保留・失敗から、担当者が条件を確認して再開できる
- 画面、通知、台帳、外部記録の状態が一致している
FREQUENTLY ASKED QUESTIONS
この記事のよくある質問。
状態は細かく分けるほどよいですか？
細かさより、担当者と利用者が次の行動を判断できることが大切です。受付済み、処理中、人の確認待ち、完了、保留・失敗を基本に、業務上必要な差だけを追加します。
人の確認待ちは、処理中に含めてもよいですか？
分けることを勧めます。AIやシステムの処理が続いている状態と、担当者の判断を待つ状態では、次の担当と期限超過への対応が異なります。
外部サービスがタイムアウトしたら、すぐ再送してよいですか？
相手側で処理が完了している可能性があるため、まず結果を照合します。未実行と確認できた場合だけ、元の依頼IDと再試行回数を保持して再送します。
利用者には内部のエラー内容をすべて見せる必要がありますか？
すべてを見せる必要はありません。現在の状態、影響、次の行動、再開条件を伝え、認証情報、個人情報、内部構成など開示すべきでない内容は分けて管理します。
状態管理の導入効果は、処理時間だけで測れますか？
処理時間だけでは不十分です。未処理、確認待ち、期限超過、二重実行、差戻し、再試行、誤った完了通知、人の確認時間も見て、利用者と運用担当者の両方で改善を確かめます。
PRIMARY SOURCES
判断の基準にした、公式情報。
制度・製品・提供条件は変更されるため、リンク先の最新表示も併せて確認してください。
CONTACT LUMINA