定期実行するAIエージェントの本番前チェックリスト

なぜ定期実行だけは別に考えるのか

人がボタンを押すAIと、毎日・毎週自動で動くAIは、同じ機能でもリスクが違います。定期実行は、担当者が不在でも始まり、前回の失敗や古い状態を引き継ぎ、同じ誤りを繰り返す可能性があります。

NIST AI RMFは、AIリスクを一度の審査で終わらせず、Govern、Map、Measure、Manageの循環で扱う任意の枠組みです。生成AI向けプロファイルでも、導入前テスト、文書化、監視、インシデント対応などが示されています。

本番投入の条件： 正常系が1回動くことではなく、入力が古い、二重起動する、費用上限へ達する、出力が壊れる、担当者が不在という状況でも安全側へ止まれることです。

定期実行AIを本番へ出すまでの8つの関門 入力から復旧までを別々の関門として確認し、1つでも未確認なら公開・送信・更新へ進めない。

1. 目的と成果物

何を減らす・速めるための自動化か、1文で説明できる
成果物の形式、保存先、受け取り手が固定されている
「記事を作る」ではなく「review状態の下書きを1本作る」のように完了条件が具体的
AIを使わない既存手順と戻し方が残っている

目的が「AIを活用する」だけなら、本番へ出す理由として不十分です。削減したい時間、見逃し、待ち時間などを決めます。

2. 入力の鮮度と正本

入力元が正本か、コピーかを区別している
取得日時、対象期間、欠損、エラーを検査する
前回と同じ入力なら重複実行しない
古い入力や途中生成物を、最新として扱わない
個人情報や秘密情報を必要以上に渡さない

アクセス解析なら、データ取得に成功した時刻と対象期間を確認します。ファイル監視なら、更新途中のファイルを読まないようatomicな受け渡しを使います。

3. 権限と作業場所

読み取り、下書き保存、公開、削除を別権限にする
書き込み先を専用フォルダーへ限定する
本番原本、秘密鍵、他案件へアクセスできない
外部送信先とネットワーク接続先を許可リスト化する
エージェント自身が制約や監査設定を変更できない

最小権限は、プロンプトの注意書きではなくOS、アプリ、APIの権限で強制します。

4. 実行量と費用

1回の入力・出力サイズに上限がある
実行時間と同時実行数に上限がある
トークン、API、外部サービス、ストレージを別々に管理する
上限到達時は失敗を隠さず、途中成果物を公開しない
自動retryが同じ費用や副作用を繰り返さない

ベンダーのトークン上限だけでは、メール送信や外部ツールの課金まで止まらない場合があります。

5. 出力検証

JSON Schemaや固定フィールドで形式を検査する
URL、日付、数値、件数を元データと照合する
出典のない重要主張を警告へ分ける
既存データの上書き、同名作成、重複公開を拒否する
検査失敗時はlast-goodを保持する

「生成に成功」と「利用可能な成果物」は別状態にします。画面にも前回成功と今回失敗を分けて表示します。

6. 人間承認と外部作用

送信、公開、支払い、削除、権限変更は人が承認する
承認画面に差分、根拠、対象、失敗警告がある
承認者が元データへ戻って確認できる
承認トークンやセッションをAIへ渡さない
担当者不在時は自動承認せず、待機またはskipする

人が確認する設計でも、確認画面が結論だけなら形式的な承認になります。変更前後と根拠を並べます。

7. ログと通知

実行時刻、入力ID、モデル・設定、結果、承認を追跡できる
プロンプト全文、Cookie、認証情報を通常ログへ残さない
成功、skip、失敗を区別する
重大失敗だけでなく「何日も実行されていない」状態を通知する
ログの閲覧者と保存期間を決める

全文を多く残すほど安全とは限りません。対象を特定できるIDと判断結果を中心にします。

8. 停止と復旧

次回実行を止める方法がある
実行中のジョブを安全に中断できる
変更前の版、last-good、バックアップが残る
rollbackを実際に試している
復旧後に件数、ハッシュ、HTTP、権限を再検証する

停止ボタンがあっても、誰が押すか分からなければ使えません。担当者、連絡先、判断条件を運用文書へ残します。

本番前に行う5つの失敗試験

入力を古くし、AIを起動せずskipできるか
同じ入力で2回起動し、成果物が重複しないか
出力を壊し、last-goodが上書きされないか
外部接続を切り、秘密をログへ出さず失敗できるか
公開切替の途中で止め、旧版へ完全に戻せるか

正常系だけを繰り返すより、この5つで運用境界が見えます。

最小構成の状態モデル

scheduled
  -> input_validated
  -> generated
  -> verified
  -> awaiting_human_review
  -> approved
  -> published

どの段階でも失敗したら:
  -> skipped または failed
  -> last-goodは保持

generatedからpublishedへ直接進めないことが重要です。下書き生成の自動化と、公開の自動化を同じ権限で動かさないでください。

AI活用ナビの判断

定期実行するAIは「優秀な担当者」ではなく、条件が揃ったときだけ狭い処理を進めるジョブとして設計する方が安全です。入力の鮮度、同一入力の重複防止、last-good保持、外部作用の人間承認を最初の4要件にしてください。

権限の詳細はAIエージェントの権限設計、テスト項目はLLM評価をテストケースで行う方法、承認設計はAI出力を人が承認するワークフロー設計へつなげられます。

確認日と適用範囲

確認日：2026年8月11日

本記事は業種共通の運用開始チェックです。法令、契約、個人情報、医療・金融・人事などの高リスク用途では、組織の専門担当者と追加要件を確認してください。

PRIMARY SOURCES