AIエージェントの待機｜状態と実行を分ける
承認や外部応答を待つAIエージェントは、実行環境を持ち続ける必要があるのでしょうか。Google Cloudの11月5日の発表を手がかりに、保存する状態、再開時の確認、待機費用と復帰時間の比較を解説します。
AIエージェントが資料をまとめ、人の承認を待っている。その間、作業用の実行環境も動かし続ける必要があるのでしょうか。長い案件を扱うほど、処理している時間と、返事を待つ時間を分けて考えることが重要になります。
ここでのテーマは、仕事を忘れずに待つための仕組みです。案件の状態を保つことと、計算資源を使い続けることを分けられるか。この問いを、導入担当者と開発・保守担当者で確認します。
11月5日のGoogle Cloud発表で何が変わったか
Google Cloudは2026年11月5日、Agent Substrate、gVisor、OpenRLのCNCFへの寄贈を発表しました。前月にCNCF Sandboxへ受け入れられたと説明する一方、Agent Substrateは1.0に達し、GKE上で一般提供すると案内しています。受け入れの時期と今回の発表日、提供形態を分けて読みます。Google Cloud公式発表
本記事が注目するのは、Agent Substrateが作業の状態と実行用の資源を分ける点です。公式解説では、待機時にメモリーやファイルの状態を保存し、実行用のWorkerを共有プールへ戻し、次の依頼で状態を復元する構成が紹介されています。
これは実行基盤の選択肢に関する発表です。自社のすべてのAI業務を、そのまま停止・再開できると示すものではありません。以下はIvyLeapによる導入時の判断材料であり、当社が同製品を実装した事例や性能検証の結果ではありません。
「何を待っているか」を先に記録する
待機には、人の承認、資料の到着、外部システムの応答などがあります。一方、処理が進まず止まっている障害も、利用者からは同じように見えることがあります。
まず案件ごとに、次の情報を確認できるようにします。
- 待つ理由：誰の返事や、どの処理の結果が必要か。
- 戻ってくる条件：承認、資料到着、応答受信など、何をきっかけに再開するか。
- 期限と担当者：いつまで待ち、期限後は誰が扱うか。
- 完了済みの範囲：何を保存し、外部への操作はどこまで終わったか。
例えば、問い合わせ回答の下書きを作り、担当者の確認を待つ案件を考えます。この例は仮想の業務です。「下書き保存済み・承認待ち」と分かれば、担当者は次の対応を判断できます。「実行中」とだけ表示されていると、AIが作業しているのか、人の確認が必要なのかを区別できません。
実行環境の停止方法を決める前に、業務として待機してよい状態を明確にすることが必要です。
保存する状態と、再開時に取り直す情報を分ける
実行環境の状態を復元できても、接続先の情報まで待機前と同じとは限りません。顧客の依頼内容が変わる、参照資料が更新される、担当者の権限が失効する、といった変化があります。
保存したいものには、案件を識別する番号、作成済みの下書き、確認待ちの内容、最後に確かめた処理結果があります。一方、実行直前の権限、期限のある認証、最新の業務データなどは、再開時の確認対象として整理します。
どこまでを実行基盤が保存し、どこからを業務アプリ側が記録するかも確認してください。メモリーやファイルを戻す機能だけを、案件管理の代わりにしないことが要点です。利用する製品や構成で保存対象は変わるため、開発担当者に項目ごとの復元結果を示してもらいます。
下書きの保存や人の修正を守る考え方は、AIコールセンターの下書き保存と再開でも説明しています。本記事では、その下で使う実行資源を待機中も確保するか、という判断を扱っています。
環境の復元と、外部の処理結果を混同しない
特に気を付けたいのが、外部システムへ依頼した直後に待機する場面です。申込登録やメール送信を依頼した後で環境を保存しても、相手側の処理が取り消されるわけではありません。
仮に、送信結果の返事が届く前に実行環境が中断したとします。復元後に手元へ結果がないことだけで、未送信と判断すると二重送信につながります。外部側の受付番号や履歴と照合し、完了済み、未実行、結果不明を分けて扱う設計が必要です。
これは特定製品に不具合があるという指摘ではなく、社外・別システムの処理を伴う業務で確認すべき境界です。処理状態を確かめられない場合は、担当者が判断できるよう保留状態にします。
待機を減らす費用と、再開の負担を比較する
状態と実行資源を分ける方式を検討するなら、まず現在の案件で、処理時間と待ち時間を実測します。待機が少ない短い処理と、担当者の返事を長く待つ処理を、同じ条件で比較しないようにします。
比較したいのは、待機中の実行資源、保存領域、保存と復元の処理、再開後の確認、運用保守を含む費用です。実行環境を戻せることだけで、全体の請求が安くなるとは判断できません。契約や料金の対象範囲を、保守担当者と確認します。
また、顧客が待てる時間と、社内のバッチ処理で許される時間は違います。代表的な案件を使い、再開の合図から業務上の結果が確認できるまでを測ります。基盤の復元だけが速くても、その後の接続や再照会で待つなら、利用者の体感は変わります。
保存した状態には顧客情報が含まれる場合があります。保持期限、閲覧できる担当者、完了後の削除方法も比較条件へ含めます。費用だけを減らす目的で、保管先や権限の確認を省かないようにしてください。
小さな案件で、待機と再開を試す
本番の顧客データや送信先を使わない検証環境で、次の五つを確認します。
- 承認を待ってから再開する。 下書きと確認内容が保たれ、承認された案件だけが進むか。
- 待機中に条件が変わる。 古い資料や失効した権限のまま処理せず、必要な確認へ戻れるか。
- 外部の応答が分からない。 相手側の履歴を照合し、二重送信・二重登録を防げるか。
- 複数の案件が同時に戻る。 再開待ちの状態と担当者が分かり、許容した時間内に進めるか。
- 待機期限を超える。 期限切れを記録し、保存状態の扱いや人への引き継ぎが決めたとおりか。
評価結果には、復元の成否に加え、復帰までの時間、外部処理との照合、人の確認負担、保存対象を残します。基盤の選定前に、待機が長い一つの業務でこの比較を行うと、常時確保する方式を続けるか、状態を分ける方式を試すか判断しやすくなります。
実行場所の選び方はローカルとクラウドの業務設計、費用の整理はAIエージェントの費用管理も参考になります。IvyLeapのAIエージェント構築支援については、待機が発生する業務と再開の条件を添えてお問い合わせください。
※出典の発表日は2026年11月5日、確認日は11月6日です。製品の復元速度や削減効果を自社で確認したとは主張していません。利用可能な環境や契約条件は、導入時の公式資料で確認してください。