Agent Operations Managerとは？AIエージェントを現場で運用する仕事

答えは、システムの稼働率ではなく、業務が保存先で完了した状態を管理する人である。

サーバーが落ちていないこと、処理が「成功」で終わったこと、業務が完了したこと。この3つは別の事実で、運用が見るべきなのは3つ目だ。エージェントは文章で報告を返すため、報告が自然であるほど完了したように見える。ここに従来のシステム運用との違いがある。

GoogleのSREの教科書は、監視すべき「エラー」を、明示的な失敗だけでなく、成功応答を返しながら中身が誤っている暗黙の失敗まで含めて定義している。エージェントの運用で起きる問題の多くは、この暗黙の失敗にあたる。

答えは、報告の文章ではなく、保存先の件数と主要項目を見て完了と判定することである。

エージェントの報告は実行の記録であって、結果の状態ではない。「84件を更新しました」という一文は、保存先を開いて84件が期待した項目を持っているかを見るまで、完了の証拠にならない。

当社の運用では、成功応答だけを信じず、保存先の件数と主要項目で完了を判定する規則を置いている。由来は実際に踏んだ落とし穴にある。業務データベースへ書き込む際、存在しない選択肢を渡してもエラーにならず無視され、レコードは作られたが、その列だけ空になった。応答は成功で、報告も完了だった。これは特定の環境で起きた一件で、すべてのツールが同じ挙動をするとは限らないが、成功応答が列の中身を保証しないという事実は変わらない。

成功応答は「処理を受け付けた」の意味であって、「業務が終わった」の意味ではない。

判定の手順は4つに分けておくと再現できる。投入前に期待値（件数、必須項目、重複ゼロ、参照先の形式）を書く。投入後に保存先から実物を取る。期待値と実物のずれを並べる。ずれの大きさで、続行、再実行、人への引き渡しを決める。期待値を投入前に書くのは、投入後に書くと実物に合わせて期待値を動かしてしまうからだ。

機械で確かめる項目と、人が見る項目も分ける。件数、空の必須項目、重複、URLの形式はコマンドで確かめられる。列の中身が業務として正しいか、たとえば段階の定義に合っているか、除外すべき行が混ざっていないかは、サンプルを人が読む。

答えは、実行中にその場で考えるのではなく、状況と行動の対応表を先に決めておくことである。

再実行の上限には意味がある。上限が無いと「もう一度やってみる」が際限なく続き、同じ誤りを違う形で積み上げる。上限を超えたら、原因は実行ではなく指示や手順の側にあると見なして人に戻す。

取り消せない操作の扱いも先に決める。削除、送信、公開、支払いは、エージェントが正しく判断できそうかどうかにかかわらず、人が承認してから実行する。運用責任者の成果物は、動いた記録ではなく、どう確かめ、いつ止めたかの記録である。 止めた理由が残っていれば、次に同じ条件で動かすかどうかを、担当者が替わっても同じ基準で決められる。

答えは、ツールの知識より、成功応答を見たときに何をどの順で確かめるかを決められる力である。

必要な力は4つ。業務の手順を工程に分解する力、実行記録と保存先の実物を読み比べる力、誰がどの操作の権限を持つかを理解する力、そして「止める」と決められることだ。採用や育成では、成功と報告されたバッチの結果を渡し、何を確かめてから完了と言うかを順に説明できるかを見れば足りる。

明日からやることは3つで足りる。エージェントに任せている業務を一つ選び、完了の条件を件数と項目で書く。次のバッチで、報告を読む前に保存先を開き、期待値と並べる。ずれが出たときの行動を、上の表の形で一枚にする。評価の基準を誰が決めるかはAI評価設計者とは何をする人か、エージェントを業務に定着させる手順はAI導入を業務に定着させる方法で扱っている。