結論

AIシステムの本番監視は、インフラ監視(死活・リソース)、アプリ監視(エラー・遅延)、AI品質監視(精度・ドリフト・誤出力)、コスト監視(API利用量)の4層で構成され、層ごとに適切な担当が異なります。引き継ぎの失敗は、全層をまとめて「監視はベンダーにお任せ」または「運用チームに移管」と一括で決めることから起きます。監視項目単位でRACI表を作り、特にAI品質監視のアラート一次判断に業務部門を組み込むことが、AI特有の設計ポイントです。

監視引き継ぎRACIとは

監視引き継ぎRACIとは、本番監視の各項目について、実行(R: アラートを受けて動く)、説明責任(A: 対応結果に責任を持つ)、協議(C: 判断時に相談される)、報告(I: 結果を知らされる)を、開発ベンダー・保守ベンダー・発注側情シス・業務部門の4者に割り当てた表のことです。開発から運用への移行期に作り、保守契約の別紙として合意します。

AIシステムで従来の監視分担が通用しないのは、「システムは正常だが出力がおかしい」という状態が存在するからです。エラーも遅延もないまま回答品質だけが劣化する事象は、技術者のダッシュボードには映らず、業務部門が最初に気づきます。この検知経路を体制に組み込まないと、品質劣化が数週間放置されます。

4層別のRACI標準形

AI品質層の責任(A)を保守ベンダーに置かないのは、品質の合格ラインが業務判断だからです。「この誤答率は許容か」を決められるのは業務側だけで、ベンダーには測定と報告の実行(R)を担わせます。コスト監視も、支払い当事者である発注側がAを持ち、閾値超過時の利用制限判断を自社でできるようにします。

引き継ぎ時に受け取るべき監視資産

RACI表とあわせて、開発ベンダーから次の監視資産を受け取ります。監視ダッシュボードの管理者権限、アラートルールの定義一覧(閾値の根拠メモつき)、アラート発生時の対応手順書(ランブック)、精度サンプリングの評価データセットと採点基準、過去の誤検知アラートのチューニング履歴です。

特にアラート閾値の根拠は口頭伝承になりやすい資産です。「なぜエラー率2%で警告なのか」の根拠がないと、運用側は閾値を調整できず、誤検知を放置してアラート疲れに陥ります。閾値ごとに設定理由を1行書かせるだけで、引き継ぎ後のチューニングが可能になります。

精度監視の運用設計

AI品質監視の実装は、全件評価が不可能なため、サンプリング+ユーザー報告の2経路で設計します。サンプリングは週次で固定件数(例: 100件)を業務担当が採点し、採点結果の推移をダッシュボード化します。採点工数は1件1-2分として週2-4時間が目安で、この工数は業務部門の正式な業務として割り当てないと、繁忙期に最初に削られて監視が止まります。

ユーザー報告経路は、誤出力を現場が報告するボタンや窓口を用意し、報告の集計とパターン分析を月次定例の議題にします。ドリフト指標(入力分布の変化)は保守ベンダー側で自動監視し、閾値超過時に「再学習の要否協議」を起票するトリガーとして使います。再学習の実施判断と費用承認は発注側Aです。

引き継ぎ完了の判定

監視引き継ぎの完了は、ドキュメントの授受ではなく運用の実演で判定します。判定条件の例として、模擬アラート(検証環境で意図的に障害を起こす)への対応がRACIどおりに回ること、精度サンプリングの1サイクルが業務部門で完走すること、月次の監視レポートが新体制で1回作成されることの3点を、引き継ぎ期間(1-2ヶ月)の出口条件にします。この期間は開発ベンダーの質問対応枠(週数時間)を契約に残しておくと、手順書の穴を埋められます。

実務チェックリスト

• 監視を4層(インフラ・アプリ・AI品質・コスト)に分けてRACI表を作ったか
• AI品質監視の責任(A)を発注側に、実行(R)に業務部門を入れたか
• コスト監視の閾値と超過時の利用制限判断を発注側に置いたか
• アラートルール一覧を閾値の根拠つきで受領したか
• 精度サンプリングの評価データセットと採点基準を受領したか
• 採点工数を業務部門の正式業務として割り当てたか
• 誤出力のユーザー報告経路と月次分析の場を作ったか
• 模擬アラート対応の実演を引き継ぎ完了条件にしたか

図解で確認するポイント

この記事の画像は、監視ダッシュボードの各領域から異なる担当へ通知が流れ、役割が分担されている構造を文字なしで図解しています。監視が単一の窓口ではなく、層ごとに異なる責任者へつながることが設計の要点です。

AllAI内での次の行動

監視設計の技術面はAI開発のログ監視設計ガイド、引き継ぎ全体は本番引き継ぎチェックリストが対になります。監視結果を事業評価につなげる方法はリリース後KPIレビューガイドへ進んでください。運用体制まで含めた発注要件はAI発注診断で整理し、AI開発パートナーで運用移管の実績を比較できます。運用担当者の育成にはAI講座も活用できます。

FAQ

Q. 監視をすべて保守ベンダーに任せるのはだめですか? A. インフラ・アプリ層は任せて問題ありません。ただしAI品質の合格判断とコストの支払い判断は、外部に委ねると「品質が下がっても誰も止めない」「請求書が来て初めて気づく」状態になります。この2つのAだけは社内に残してください。

Q. 業務部門が採点工数を出せない場合は? A. サンプリング件数を減らしてでも継続することを優先してください。週20件でも傾向は掴めます。ゼロにすると、次に品質劣化へ気づくのは顧客クレームになります。LLMによる自動採点の併用も有効ですが、自動採点の妥当性を人間が月次で抜き取り確認する設計にします。

Q. RACI表はどのくらいの粒度で作りますか? A. アラート単位では細かすぎ、層単位では粗すぎます。「監視項目グループ×対応フェーズ(検知・一次対応・原因調査・恒久対策)」で30-50行程度が実用的です。

Q. 開発ベンダーと保守ベンダーが別会社の場合の注意は? A. 監視資産(ダッシュボード、閾値根拠、ランブック)の引き渡しを開発契約の納品物に明記しておくことが前提になります。三者引き継ぎ会を設け、保守ベンダーからの質問に開発ベンダーが回答する期間を開発契約側に確保してください。

出典と確認日

• 経済産業省「AI事業者ガイドライン(第1.2版)」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
• NIST「AI Risk Management Framework」: https://www.nist.gov/itl/ai-risk-management-framework (確認日: 2026-07-10)
• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
• 総務省「AI利活用ガイドライン」: https://www.soumu.go.jp/iicp/research/results/ai-network.html (確認日: 2026-07-10)