AI Agents 調査対象日 2025年8月1日最終更新 2026年10月11日

AgentOps：通信が切れた後、何をやり直してよいか

読了目安 8分

AgentCore、Foundry、LangGraphの実行管理と履歴を比較し、チケット作成の通信断から復旧を考える。途中保存と外部の確定状態、停止と取消しを分け、人の再調査を減らす運用を描く。

仕事が途中で止まる

「もう一度実行」の前に、チケットは作成済みか

問い合わせを調べたAIが、顧客対応のチケットを作成する。その途中で通信が切れ、画面にはエラーが出た。担当者はもう一度押せばよいのか、外部の管理画面で作成済みか調べるべきなのか。これは復旧を考えるための想定例だ。 AIが返事をできない場合でも、相手のシステムでは変更が済んでいる可能性がある。

エージェントが外部の道具を使い、長い仕事を続けるほど、途中の失敗を扱う仕組みが必要になる。 5月のFoundryやLangGraph Platformに続き、7月にはAmazon Bedrock AgentCoreが、実行環境、権限、実行の観測を含む機能をプレビューとして発表した。回答を生成する機能とともに、仕事を運用するための部品が提供されている。

本稿では、実行の記録、制御、復旧、改善をまとめて扱う仕事をAgentOpsと呼ぶ。結論は、記録を見られるだけでなく、何が確定し、何が不明で、次に何をしてよいかを判断できる形へつなぐ必要があるということだ。利用者に毎回最初から調べ直してもらう運用では、AIが途中まで進めた仕事の価値も失われる。

運用を支えるサービス

実行環境と履歴を任せても、業務の完了は別に確かめる

AgentCoreの7月16日の発表は、実行環境のRuntime、権限を扱うIdentity、実行を追うObservabilityなどを個別に利用できると説明する。顧客対応の例では、CRMから顧客を特定し、注文や製品情報を参照して返信を用意する。ただし、紹介する試作の社内システムはPython関数で模擬している。本番の顧客対応で、障害から安全に復旧できたという計測ではない。

FoundryのDeveloper Essentialsも、道具の接続に加え、実行の追跡、評価、監視を説明する。管理サービスを選ぶ際、モデルへ質問できるかに加えて、どの履歴を残し、どの失敗を調べられるかを比較できる。一方、実行環境が動いていること、回答が生成されたこと、チケットが一件だけ作成されたことは、別の確認である。

この違いは、道具を増やす判断にも関わる。文書を読むだけの試作から、チケットの作成や返信の送信へ進むと、失敗後に確認する外部の状態が増える。接続できる機能の一覧と、復旧に必要な記録や操作を並べて考えたい。

原因を調べる

「AIが間違えた」を、直せる場所へ分ける

Anthropicの調査システムの開発報告では、利用者から「明らかな情報を見つけない」と言われても、検索語、選ぶ資料、道具の失敗のどれが原因か分からなかったと述べる。本番の実行を追跡する仕組みを加え、原因を調べて修正したという報告だ。これはベンダーの開発経験であり、どの組織でも改善時間が同じ割合で減るという実験ではない。

CloudWatchの7月のプレビューは、遅延、使用量、エラーと、知識検索、道具、モデルをまたぐ実行の追跡を提供する。たとえば、検索で必要な規程を取得できなかったなら、検索対象を直すのか、取得方法を直すのかを調べたい。正しい規程を渡したのに回答へ反映しなかった場合とは、修正する場所が異なる。

ここから導く運用の方針は、入力、取得した根拠の版、道具の引数と結果、実行の版を結び付けて残すことだ。最終回答だけでは、誤った入力を受けたのか、途中で根拠を落としたのかを追いにくい。逆に、長い履歴があっても、外部の作成結果と結び付かなければ、冒頭のチケットの確定状態は分からない。

途中から再開する

保存した実行へ戻ることと、外部の変更を戻すことは違う

5月14日に一般提供となったLangGraph Platformは、長く続く処理や、人の返事を待つ処理の状態を保存する。 Studioでは、途中保存を使って失敗した箇所へ戻り、編集して再実行する機能を説明する。 Responses APIのbackground modeも、長い処理を開始し、その後で状態を確認する方法を用意する。待つことや再開することを、アプリケーションから扱うための部品である。

チケット作成の前へ戻る想定例では、エージェントの内部では「まだ作成していない」状態を復元できても、外部では作成済みかもしれない。そのまま作成の道具を再実行すれば、同じ内容のチケットが二件になる恐れがある。実行の途中保存を、外部の変更まで取り消す機能として扱うことはできない。

そのため、再開地点は処理の順序だけで決めない。資料を読み直す処理と、外部へ変更を確定する処理を区別する。前者でも資料の更新によって結果は変わり得るし、後者では先の変更が確定したかの照合が必要になる。どの入力と環境の版を使って再開するかも、記録から判断したい。

同じ操作を重ねない

通信断は、失敗と未確定を分けて扱う

StripeのAPI設計の説明は、処理が成功しても応答を受け取れない場合を含め、通信断後に結果が不明になる問題を扱う。同じ操作の識別子を再送し、相手側で重複を防いで結果を返す仕組みを説明する。何度呼んでも変更が重ならない性質を冪等性と呼ぶ。これは通常のAPIにもある問題で、エージェントだけの新しい障害ではない。

チケットの想定例では、外部システムが対応するなら、同じ操作を識別するキーと、確定したチケットIDを結び付ける。再試行の際には、同じ作成内容と同じキーを使えるか、キーの有効期間や相手側の処理条件を確認する。 AIが再び考えて似た文面を作り、新しいキーで送れば、相手には別の作成依頼として見えることがある。

識別子で照合できない場合、直後の検索に出ないだけで未作成と決めない。相手側で処理中だったり、検索へ反映するまで時間が掛かったりする可能性が残る。この場合は「失敗したので再作成」ではなく「結果を確認できていない」と伝え、先の操作内容と最後に確認した状態を担当者へ渡す。復旧を急ぐほど、未確定を消さない設計が重要になる。

止める場所を決める

承認、停止、取消しには、それぞれ違う確認が要る

Bedrockの人による確認の例は、休暇申請の作成前に入力を提示し、利用者が編集する流れを示す。エージェントが提案した操作と、人が実行してよいと確認した操作を対応させるための材料である。顧客対応へ当てはめるなら、チケットや返信の内容を、実際に送る直前の入力と結び付けたい。

承認後に文章や宛先が変わった場合、前の承認をそのまま使えるとは限らない。長い待機中に権限が変わる場合も、再開時に実行条件を確認する必要がある。人が承認する画面を置くだけでなく、その判断がどの内容と操作に対するものかを保存する。

停止を設計する際は、これからの道具の呼び出しと、すでに送った操作を分けて考える。すでに送った返信を回収できるか、作成済みのチケットを閉じるべきかは、外部システムの機能と業務の判断による。取消しも別の操作として権限と結果を確認する。止まった画面を、すべて元へ戻った画面と読み替えないことが必要だ。

残す記録を選ぶ

復旧に必要な記録と、会話の全文を分けて考える

原因を追うために、常に会話の全文を保存する必要があるとは限らない。 Anthropicは、個別の会話内容を監視せずに、判断や担当間のやり取りのパターンを観測すると説明する。 CloudWatchの発表も、収集・保存した観測データには料金が掛かると明記する。記録を増やす場合には、調べられる範囲と、保存する情報や費用がともに増える。

本稿の提案は、まず復旧の判断に必要な項目を決めることだ。操作と外部の識別子、確定した結果、利用した権限、承認した入力の版を、同じ実行へ結び付ける。機密を含む本文が調査に必要なら、見る人と保存期間を決め、認証情報そのものを履歴へ残さない。復旧担当者が必要な証拠を探せることと、誰でもすべて読めることは別である。

記録が一部しか残らない場合も、その限界を知れるようにしたい。履歴がない道具を使った区間や、外部の結果を受け取れなかった区間を、正常な完了と同じ表示へまとめない。確かめられる範囲が分かれば、担当者は不要な再調査を減らし、判断できない箇所へ集中できる。

復旧から改善へ

次の担当者が、同じ失敗を最初から調べずに済むようにする

一件の復旧が終わったら、何が不足して判断に時間が掛かったかを確認する。検索条件が原因ならその条件を評価例へ残し、応答が失われる場合なら同じ操作を再送する試験へつなぐ。入力、モデル、道具、外部データの版を記録して比べれば、修正が同じ条件で効いたかを調べやすくなる。実際の外部操作を重ねる再実行と、検証用の環境で原因を再現する試験は分ける。

改善を判断する際は、回答の正しさに加え、未確定を見落とさなかったか、重複を作らなかったか、担当者が何分調べ直したかも見る。これらは本稿の評価案であり、資料にある製品比較の実測ではない。記録を集める機能から、人の復旧負担を減らす運用へ進むための判断材料になる。