AIエージェントの運用保守｜失敗と該当なしを分けて記録する

毎朝届く自動の一覧に「該当なし」と書かれていても、その朝に仕組みが動いたのか止まっていたのかは一覧だけでは分かりません。扱うのは動かし始めたエージェント自体の保守で（AIでシステムの運用を自動化するAIOpsは対象の外）、道具の比較や通知の設定より手前にある問いは止まった朝に出力ファイルへ何が書かれるかです。動いた日・該当なしの日・失敗した日を書き分ける決めごとと止まる箇所の一覧の作り方を、当社の小さな仕組みが失敗を「該当なし」と書いた2日の記録とあわせて示します。

当社の記録は、月曜から金曜の朝に返信の候補を集める小さな仕組み1つの2026年9月16日から10月14日までの実行と、10月7日に止まった動画制作の仕組みの記録です。1社の小さな仕組みで起きた出来事で、成果の実績でも業務システム一般の結論でもありません。外部の記述はGoogle・NIST（米国国立標準技術研究所）・総務省と経済産業省・Anthropic・OpenAIの公開資料を2026年10月19日に読んだ範囲に限ります。

AIエージェントの運用保守とは、止まっていないか・誤った結果を出していないかを監視し、止まったら直して再開させる仕事である

AIエージェントの運用保守とは、動かし始めたエージェントが止まっていないか・誤った結果を出していないかを監視し、止まったら直して再開させる仕事です。作る仕事が終わったところから始まり、エージェントが動いているかぎり続きます。ここで見張る対象は、エージェントそのものの動き方です。

図の上段は3つの記録の見え方を並べた表で、失敗の行だけは気づける場所が毎朝の一覧の外にあります。下段は月曜から金曜の21日を並べた帯で、失敗した2日と予定より遅れて動いた日に印を付けました。右の欄には止まる箇所ごとに、直して再開させる人を止まる前に書き込む空欄を置きました。

米国国立標準技術研究所（NIST）が2023年1月26日に公開したAIリスクマネジメントフレームワーク（AI RMF 1.0）は、組織が任意で使うための枠組みです。管理の機能を定めたMANAGEの4.1には、導入後のAIシステムの監視計画を実施することが挙がっています。計画に含めるものとして、利用者などの意見を集めて評価する仕組み・異議申し立てと上書き・運用の終了・インシデント（事故や障害）対応・復旧・変更管理を挙げています（NIST（米国国立標準技術研究所）「Artificial Intelligence Risk Management Framework (AI RMF 1.0)（NIST AI 100-1）」／2026年10月19日閲覧）。見張ることと直して戻すことが、同じ1つの計画の中に並んでいます。

当社が動かしている返信の候補を集める仕組み・検索順位の監視・動画制作の3つが何をしているかは、AIエージェントの導入方法に書きました。ここで扱うのはそのうち2つの止まり方と、止まったことの見張り方だけです。毎週の作業を定期実行へ移していく進め方は、Claude Codeの業務効率化の記事が扱っています。朝の仕組みは小さなものですが、外部を呼ぶ部分の止まり方はツールを呼ぶエージェントでも同じ形で起こり得ます。

「該当なし」と「失敗」を同じ書き方で残すと、止まった日に気づけない

「該当なし」と「失敗」を同じ書き方で残すと、止まった日に気づけません。毎朝読む出力ファイルが同じ形で届けば、何も起きなかった朝と仕組みが止まった朝の区別が一覧の上ではつかないからです。

当社の朝に返信の候補を集める仕組みは月曜から金曜に動き、2026年9月16日から10月14日の21日（祝日を含む）すべてに実行の記録があります（9月16日は試しの実行を含めて2回）。このうち9月24日と10月14日は、外部サービスへの検索の通信が名前解決（接続先の名前を通信用の住所に引き直す処理）で失敗していました。それでも毎朝読む候補の一覧は「該当なし」と書き、検索の条件を広げるか対象の時間を伸ばすよう案内していました。失敗が該当なしとして残ったうえに、直し方の案内も原因に合っていなかったことになります。

実行の記録のほうには、検索ごとの失敗が1行ずつ残っていました。候補を集めたあとに続く工程も異常終了していましたが、記録の最後の行はほかの日と同じ完了の行です。自分宛ての反応（返信や引用）の一覧はこの2日だけ作られておらず、ファイルが無いこと自体が失敗の印でした。候補を集める処理は検索の失敗を記録に書いたうえで、その検索を結果0件として先へ進む作りです。

Googleの「Site Reliability Engineering」第6章は、利用者から見える外側の振る舞いを利用者と同じ見え方で試す監視をブラックボックス監視、ログなどシステムの内部が出す指標にもとづく監視をホワイトボックス監視と定義しています。同じ章によればブラックボックス監視は症状を見る監視で、ホワイトボックス監視は差し迫った問題や再試行で覆い隠された失敗を検出できます（Google「Site Reliability Engineering」第6章「Monitoring Distributed Systems」／2026年10月19日閲覧）。当社の2日では、利用者と同じ見え方に当たる候補の一覧は症状を見せず、内部の記録だけが失敗を持っていました。再試行の代わりに「該当なし」の一文が失敗を覆っていた形です。

同じ章は、エラーを明示的に失敗した要求だけで数えていません。成功の応答を返していても中身が誤っている暗黙の失敗や、方針で決めた失敗（約束した応答時間を超えた要求など）も含めています。完全に失敗した要求はロードバランサ（要求を振り分ける装置）でかなり捕まえられる一方、誤った中身を返していることはエンドツーエンドのシステムテスト（入口から出口までを通しで試す検査）でしか検出できないとしています（Google「Site Reliability Engineering」第6章「Monitoring Distributed Systems」／2026年10月19日閲覧）。失敗した朝の候補の一覧は、成功の形をした誤った中身でした。

実行の終わり方も分けて記録します。OpenAIの「A practical guide to building agents」は、どのオーケストレーション（エージェントの処理の組み立て）にも「run」の概念が要るとしています。runは終了条件に達するまでエージェントを動かすループで、よくある終了条件にツール呼び出し・特定の構造化出力・エラー・最大ターン数への到達が挙がっています（OpenAI「A practical guide to building agents」（PDF）／2026年10月19日閲覧）。エラーで終わった回も出力で終わった回も同じ完了の行で閉じると、最後の行だけでは違いが見えません。

記録を並べ直した結果から引くと、書き分けの形は次の3行になります。

表は横にスクロールできます。

当社のこの記録は直す前のもので、2026年10月19日の時点で候補の一覧に「該当なし」を書く処理は変わっていません。上の表は、直すときに使う書き分けの形として置いています。

同じ記録には、動いた時刻も残しておきます。結果の中身だけを残す記録では、動いたかどうかは分かってもいつ動いたかは分かりません。

当社の朝の仕組みの実行の記録は、各回の始まりと終わりの行に日付と時刻を持っています。予定の時刻と並べると、10月14日は予定の時刻より3時間15分遅れて動いていました。ほかに9回が4〜14分遅れて動いています。遅れの原因は確かめていません。10月14日は遅れて動いた日であり失敗した日でもありますが、2つの関係も確かめていません。

時刻が要るのは、遅れがそのまま結果の中身に入るからです。候補を集める仕組みは動いた時点からさかのぼった決まった時間の範囲を検索するので、遅れて動いた日はほかの日と同じ条件で集めた一覧ではありません。一覧を読む時刻より後に動いた日は、読む時点で一覧がまだありません。

総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」別添は、AI提供者向けの「P-6）i. システムアーキテクチャ等の文書化」の具体的な手法に、ログの記録・保存で検討する項目を並べています。目的・取得頻度・精度・保存期間・保護・保存容量・ログの時刻の記録（時刻同期による正確性確保等）・開示する範囲・保存方法・保存場所・ログの確認手順（アクセス方法等）です（総務省・経済産業省「AI事業者ガイドライン（第1.2版）別添（付属資料）」（PDF）／2026年10月19日閲覧）。時刻はこの一覧の中で、正確さまで含めて1項目として挙がっています。

Anthropicは2024年12月19日公開の「Building effective agents」で、エージェントを実装するときに守る3つの基本原則を挙げています。その1つが、エージェントの計画の手順を明示的に見せて透明性を優先することです（Anthropic「Building effective agents」／2026年10月19日閲覧）。当社の記録で失敗と遅れを後から拾えたのも、工程ごとの行と各回の時刻が残っていたからです。

残す時刻は、予定の時刻と実際に動き始めた時刻と終わった時刻の3つです。予定の時刻を記録の側にも書いておけば、遅れは引き算で出ます。記録を並べ直すときの列は、次の形にすると失敗と遅れが同じ表で見えます。

表は横にスクロールできます。

失敗したときの案内は原因ごとに出し分け、条件の見直しと通信の失敗を同じ文で案内しない

失敗したときの案内は原因ごとに出し分け、条件の見直しと通信の失敗を同じ文で案内しません。案内は読んだ側が次にする操作そのものなので、原因と合わない案内は誤った操作を呼びます。

先の2日に出た「条件を広げる」案内のとおりに動いても、通信の失敗は直りません。そのうえ翌日からの候補は別の条件で集めたものになり、前の日の一覧と並べて比べられなくなります。案内の文は、本当に該当がなかった日のための1種類しか用意されていませんでした。

Googleの同じ章は、監視の仕組みが答えるべき問いを「何が壊れているか」と「なぜか」の2つとし、前者を症状・後者を原因と呼んでいます。原因は中間的なものであることもあるとしたうえで、この区別を信号を最大にして雑音を最小にする監視を書くうえで最も重要な区別の1つに挙げています（Google「Site Reliability Engineering」第6章「Monitoring Distributed Systems」／2026年10月19日閲覧）。当社の一覧は「何が壊れているか」を書かないまま、「なぜか」には条件の側の答えだけを用意していたことになります。

人に知らせる部分の書き方にも、同じ章の考え方が使えます。同章は雑音を減らして信号を保つため、監視のうち人を呼び出す部分はごく単純で頑健であるべきだとしています。人に通知を出すルールは、理解しやすく明確な失敗を表すものにすべきだとも書いています。呼び出しの基本の考え方としては、すべての呼び出しは対処できるものであるべきで、機械的な対応で済むものなら呼び出しにすべきではないとしています（Google「Site Reliability Engineering」第6章「Monitoring Distributed Systems」／2026年10月19日閲覧）。

案内の文を原因の種類ごとに持てば、読んだ側がすることは1つに決まります。通信の失敗のあとに同じ条件で動かし直すような機械的な対応は、案内に書くより仕組みに入れるほうが同章の考え方に合います。ただし動かし直したことは記録に残し、成功した回だけが残って再試行が失敗を覆い隠す形を避けます。

当社の記録にある止まり方から作った書き分けの案は、次のとおりです。

表は横にスクロールできます。

通知が要るのは結果を毎回は読まない作業で、毎回読む作業なら記録の直しで足りる

通知が要るのは結果を毎回は読まない作業で、毎回人が結果を読む作業なら通知の仕組みを足す前に記録の直しで足ります。夜間に動いて朝まで誰も見ない処理や、出力がそのまま公開や送信に進む処理は、次に人が読む前に止まり方を届ける必要があります。その場合も通知に載せる中身は記録の書き分けと同じで、原因の種類と次にする操作です。

読む人がすでに毎回いるなら、記録が失敗を失敗と書くだけでその回のうちに気づけます。当社の朝の仕組みの出力は、毎朝読む候補の一覧です。先の2日の一覧の1行目に失敗と止まった工程が書かれていれば、一覧を読んだ時点で止まり方が分かる形でした。足りなかったのは、一覧の中の書き分けのほうです。

Googleの同じ章は結論で、メールでの通知は価値がごく限られ雑音に埋もれやすいとしています。代わりに進行中の軽微な問題をまとめて見るダッシュボードを勧め、過去の相関を分析するためにダッシュボードとログを組み合わせることもあるとしています（Google「Site Reliability Engineering」第6章「Monitoring Distributed Systems」／2026年10月19日閲覧）。毎朝読む一覧は、小さな仕組みにとってのダッシュボードの役を果たせます。

OpenAIの手引きは人の介入を、利用者の体験を損なわずにエージェントの実環境での性能を上げられる重要な安全策としています。人の介入は失敗の特定・エッジケース（想定外の場合）の発見・堅牢な評価サイクルの確立に役立つとしています（OpenAI「A practical guide to building agents」（PDF）／2026年10月19日閲覧）。毎回結果を読む作業では、人が毎日結果を見る形がすでにあります。そこへ通知を重ねても、同じ失敗を知らせる経路が2本になるだけです。

この節の判断は当社の小さな仕組み1つの記録から引いたもので、業務システム一般で監視の道具が要らないという意味ではありません。

外部サービスの残高と回数の上限は、止まる箇所として最初に一覧にしておく

外部サービスの残高と回数の上限は、止まる箇所として最初に一覧にしておきます。どちらも自社の仕組みの外で決まる値で、尽きた時点で自社の側に誤りがなくても仕組みは止まります。

2026年10月7日、当社の動画を作る仕組みで使う生成サービスの前払いの残高が尽きました。声・画像・聞き取り確認・音楽の工程は、すべて止まっています。4つの工程が1つの残高を共有していたので、尽きると全部が同時に止まる形でした。残高が尽きたのは参考にする動画を解析したあとで、翌日に残高を足して再開しています。同じ仕組みの声の工程は10月2日に1日の回数上限にも当たっていて、その経緯と作れた行から続きを作る動き方はAI導入の失敗事例に書きました。朝の仕組みの2日は、外部サービスへの通信で止まっています。

NISTのAI RMF 1.0のMANAGE 3.1は、第三者の資源から生じるAIのリスクと便益を定期的に監視することを挙げています。あわせて、リスクの管理策を適用して文書化することも挙げています（NIST（米国国立標準技術研究所）「Artificial Intelligence Risk Management Framework (AI RMF 1.0)（NIST AI 100-1）」／2026年10月19日閲覧）。外部の生成サービスや検索の窓口は、ここでいう第三者の資源に当たると読めます。

残高は、尽きる前に見張れる値です。Googleの同じ章は飽和（Saturation）を、最も制約のある資源を中心にサービスがどれだけ満杯かを測る信号としています。そこには差し迫った飽和の予測も含まれ、例としてデータベースが4時間でディスクを使い切りそうだという予測を挙げています（Google「Site Reliability Engineering」第6章「Monitoring Distributed Systems」／2026年10月19日閲覧）。前払いの残高も、減り方から尽きる日を見積もれる側の値です。

止まる箇所の一覧は、当社の記録にある3つで作ると次の形になります。右端の欄は、止まる前に埋めておく欄としてここでは空けてあります。

表は横にスクロールできます。

表の戻し方の欄は、再開できる作りかどうかで書く中身が変わります。朝の仕組みには、同じ日に2回取りに行かない決まりがあります。9月16日の2回目の実行では、候補を集める工程が「その日の分は取得済み」として何もせずに終わっています。ただしこの決まりは、失敗した日に残る候補0件の記録も取得済みとして扱います。2026年10月19日時点の処理の作りでは、失敗した日にそのまま動かし直しても取り直しには進みません（実際に試してはいません）。

再開できる作りは、作れたものと作れなかったものを記録が見分けられて初めて働きます。済みと数える基準に失敗が混ざると、再開の仕組みが失敗をそのまま次へ持ち越します。

止まった後に直して再開させる人は、作る前に名前で決めておく

止まった後に直して再開させる人は、作る前に名前で決めておきます。止まったことが記録に正しく出ても、その記録が届く先に直す人がいなければ仕組みは止まったままです。

AI RMF 1.0のMANAGE 2.4は、意図した用途と合わない性能や結果を示すAIシステムを置き換える・切り離す・停止するための仕組みを用意して適用することを挙げています。その責任が割り当てられ理解されている状態も、あわせて挙げています。同じ文書の5.4 Manageは、リスクへの対処をインシデントや事象への対応・復旧・伝達のための計画からなるものとしています（NIST（米国国立標準技術研究所）「Artificial Intelligence Risk Management Framework (AI RMF 1.0)（NIST AI 100-1）」／2026年10月19日閲覧）。

総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」別添は、AI利用者向けの「U-2）i. 安全を考慮した適正利用」の解説で、被害の性質・態様等に応じて関係するステークホルダーと協力し予防措置と事後対応に取り組むことが重要だとしています。事後対応には情報共有・停止と復旧・原因解明・再発防止措置等が含まれ、具体的な手法には利用前にログ（操作履歴、入力・出力の記録等）の管理体制を整えることも挙がっています（総務省・経済産業省「AI事業者ガイドライン（第1.2版）別添（付属資料）」（PDF）／2026年10月19日閲覧）。停止と復旧が同じ事後対応の中に並び、その前に置かれているのがログの管理です。

失敗したエージェントが人へ制御を戻す仕組みはAIエージェントの導入方法で引いたので、ここでは戻された先で誰が直すかだけを決めます。

当社の2つの止まり方は、知らせの届き方が違いました。動画の仕組みは止まった時点で工程が先へ進まなくなり、手順書には残高を足して動かし直す手順が書いてありました。朝の仕組みでは直す人を決める以前に、先の2日に止まったこと自体がどこにも届いていませんでした。

名前で決めるのは、止まる箇所の一覧の1行ごとに1人です。権限設計の記事では止める人を役職名で決めましたが、再開させる人は各行に担当者の名前まで書きます。残高を足す人と通信の失敗を見に行く人は同じ人が兼ねても別の人に分けてもよく、避けたいのは空欄の行を残したまま動かし始めることです。止める操作の決め方は同じ記事に譲り、ここでは止まった後の側だけを扱います。

Claude Codeのような道具で社内ツールを自分たちで作った場合も同じです。作った人しか再開の手順を知らない状態だと、その人が不在の朝に止まった仕組みは戻ってくるまで止まったままです。再開の手順は、止まる箇所の一覧の横に文書として書いておきます。

AIエージェントの運用保守についてよくある質問

Q. 監視の道具は何から入れればよいですか？

道具より先に、出力ファイルと実行の記録の最後の行を動いた・該当なし・失敗で書き分けます。書き分けがないまま道具を入れても、道具が読む記録の側に失敗が出ていなければ拾えません。Claude Codeでエージェントを動かしている場合の記録の取り方と止め方は、AIエージェントの導入方法の権限と停止の節に書きました。道具を選ぶのは、書き分けた記録を毎回読む人がいないと分かってからで足ります。

Q. ログはどこまで残せばよいですか？

AI事業者ガイドライン第1.2版の本編は、共通の指針「6）透明性」①検証可能性の確保でログの記録・保存に触れています。そのうえで記録方法・頻度・保存期間等は、事故等の原因究明・再発防止策の検討・損害賠償責任要件の立証上の重要性等を踏まえて検討するとしています（総務省・経済産業省「AI事業者ガイドライン（第1.2版）本編」（PDF）／2026年10月19日閲覧）。同じ本編の「7）アカウンタビリティ」⑥文書化の脚注46は、適切なツールで記録が残されていれば必ずしも紙媒体や特定の文書の形式による必要はないとしています（総務省・経済産業省「AI事業者ガイドライン（第1.2版）本編」（PDF）／2026年10月19日閲覧）。当社の小さな仕組みで最低限と考えるのは、各回の予定と実際の時刻・工程ごとの結果・終わり方の3つです。監査ログとして誰が何をしたかまで残すかは業務と契約で決まるので、法務や専門家に確認してください。

Q. 止まったら誰に知らせればよいですか？

まず、その仕組みの出力を毎回読む人です。AI RMF 1.0のMANAGE 4.3は、インシデントとエラーを影響を受けるコミュニティを含む関係するAIアクター（AIにかかわる組織や人）に伝えることを挙げています。あわせて、インシデントとエラーを追跡し対応し復旧する手順に従って文書化することも挙げています（NIST（米国国立標準技術研究所）「Artificial Intelligence Risk Management Framework (AI RMF 1.0)（NIST AI 100-1）」／2026年10月19日閲覧）。AI事業者ガイドライン第1.2版の別添は、AI利用者向けの「U-5）i. セキュリティ対策の実施」の具体的な手法に「ログの定期的な確認」を挙げています。システムの利用状況や異常な操作を把握するためにログを定期的にレビューし、異常な操作を検知したら即時に報告する体制を整えるとしています（総務省・経済産業省「AI事業者ガイドライン（第1.2版）別添（付属資料）」（PDF）／2026年10月19日閲覧）。止まる箇所の一覧の行ごとに、知らせが届く人と再開させる人を同じ欄に書いておくと知らせた先で止まりません。

Q. 運用保守は外部に頼めますか？

頼めますが、止まったときの知らせが社内と外部の両方に届き、再開の手順を両方が持っている形にします。知らせが外部にだけ届く形では、外部の担当が動けない日に社内は止まったことを知りません。再開の手順は契約が終わったあとも社内に残る文書に書き、止まる箇所の一覧の再開させる人の欄には社内の名前も入れます。外部から社内へ運用を移していく段階の進め方は、FDEの仕事内容の定着と移管の段階に書きました。

SAIの視点：「該当なし」が失敗だったと分かったのは、毎朝の一覧ではなく実行の記録を並べ直したときだった

先の2日の「該当なし」が失敗だったと分かったのは、21日分の実行の記録と出力ファイルを並べ直したときでした。毎朝読む一覧の上では、2日とも何も起きなかった朝と同じ形をしています。失敗は最初から実行の記録の中にあり、違っていたのは見る場所でした。

監視の道具を選ぶ前に記録の書き分けを直すという順番は、この並べ直しから出てきたものです。

今朝届いた自動の仕組みの出力ファイルを1つ開き、失敗した日にも同じ形で届くかを確かめてください。同じ形で届くなら、止まったことは実行の記録の奥にしか出ていません。お問い合わせには、いま動いている自動化の一覧と、それぞれが止まったときに誰へ知らせが届くかを書いてください。

FDE伴走開発は、一緒に作りながら技術を移し、文書と運用体制を整えて自社だけで改善が回る状態を目標にする伴走です。止まる箇所の一覧のような文書は、運用を続ける社内の側に残す前提で作ります。任せる業務をまだ決めていない段階なら、AI導入支援で業務の入力と出力を決めるところから始めます。

出典と確認日

外部の出典はいずれも2026年10月19日閲覧。当社の数値は朝の仕組み（月曜から金曜に動く）の実行の記録（2026年9月16日から10月14日の分）と同じ期間の出力ファイルから取ったもので、成果の実績ではない。動画制作の仕組みの記述は、同じ仕組みの手順書と社内の作業一覧（2026年10月7日と8日の記録）による。

• Google「Site Reliability Engineering」第6章「Monitoring Distributed Systems」
• Anthropic「Building effective agents」（2024年12月19日公開）
• OpenAI「A practical guide to building agents」（PDF）
• NIST（米国国立標準技術研究所）「Artificial Intelligence Risk Management Framework (AI RMF 1.0)（NIST AI 100-1）」（2023年1月26日公開）
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）本編」（PDF）（令和8年3月31日公表）
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）別添（付属資料）」（PDF）（令和8年3月31日公表）
• 当社の運用記録: 朝の仕組みの実行の記録と出力ファイル（2026年9月16日から10月14日）・候補を集める処理の作り（2026年10月19日時点）・動画制作の仕組みの手順書と社内の作業一覧（2026年10月7日の停止と8日の再開）