ITエージェントの承認は障害を越えて有効か

2026年10月13日、DXCはLangChainとの提携を発表した。対象は企業のIT運用だ。人間がエージェントの操作を承認した後に必要な仕組みを考える契機になる。

三つの記録を分ける

LangGraphの永続化文書は、スレッド単位のチェックポイントとスレッドをまたぐ保存情報を区別している。中断に関する文書は、中断したノードを再開すると中断前のコードが再実行されると説明する。これはフレームワークの性質であり、特定顧客の導入成果を独立に検証したものではない。

当媒体の分析では、運用管理システムは「何が許可されたか」「何を実行しようとしたか」「外部で何が変わったか」を別々に示す必要がある。会話記録は意図を説明できても、接続先が操作を受理した証拠にはならない。逆に、接続先の成功応答も、操作が以前の承認範囲に収まっていたことまでは証明しない。

あえて難しい受け入れ試験をする

保守時間内に一つのサービスを再起動する仮想例を考える。担当者は具体的なサービスと環境を承認した。要求はサーバーに届いたが、確認応答が戻る前に接続が切れた。待機中に別の担当者が保守計画を変更した。

ここで自動的にもう一度再起動すればよいわけではない。有用な試験では、元の操作を識別し、接続先の状態を調べ、以前の承認が今も適用できるかを確認させる。結果を確定できなければ、人間に引き継ぐことを正しい動作として評価すべきだ。単なるタスク完了率の失敗にしてはいけない。

これは当媒体が提案する試験であり、DXCの事故を描いたものではない。調達時の検証にある隙間を示している。承認待ちで停止できる実演だけでは、承認から外部の結果確認までの期間を検証したことにならない。その間の通信障害や業務条件の変化が、それまで合理的だった計画を不適切にする可能性がある。

完了件数だけでなく例外を測る

購入側は四つの実演を求められる。承認後に対象を変え、古い承認が黙って流用されないかを見る。結果不明の要求を再送し、効果が重複しないかを見る。待機中に権限を撤回し、実行直前の権限確認を試す。最後に、交代した担当者がエージェントの説明に頼らず、保存証拠だけで結果を再構成できるかを確かめる。

これらは提案する評価基準であり、発表された製品で検証済みの機能ではない。導入にはコストもある。証拠保存にはアクセス管理、例外の処理待ちには責任者、人間の審査には応答期限が必要だ。確認画面だけを増やし、運用資源を用意しなければ、ボトルネックを移すだけになり得る。

より意味のある指標は、適切な承認、接続先が確認した結果、明確な復旧手順がそろった重要操作の割合である。提携発表は方向性を示す。実運用の保証には、これらの記録が食い違ったときの振る舞いを確認する必要がある。