この記事で分かること／分からないこと
- 分かること: 運用体制で「壊れた」をどう定義しておくか
- 分かること: 無人で動かし続けるための実装に、どれだけの検証工数がかかるか
- 分からないこと: 誰が一次対応するかという体制の正解(組織による)
- 分からないこと: 監視の頻度として何が十分かという一般的な基準
「壊れた」を導入前に定義しておく
運用体制を組む前に、何を「壊れた」とするかを決めておく必要がある。自社のRAG運用では、公開前の検査で使った基準(hit率91%を下回る、致命的な失敗が起きるなど)を稼働後にもそのまま判定基準として使っている(出所: 自社の運用記録、確認日2026-09-06)。この基準を稼働後に流用できるようにしておくと、公開前と稼働後で「壊れた」の定義がぶれない。
実行時にAIを呼ばない構成でも気づく仕組みは要る
自社の構成では、実行時に触るのは索引だけで、確定回答の配信時にAIを呼び出さない(実測0.12円/session、確認日2026-09-06)。運用コストを抑えられる一方、会話のたびにAIが応答の妥当性を確認する仕組みは働かない。検証はビルド時に集中しており、稼働中の応答が検証時と同じ水準かどうかは、実行時の仕組みだけでは分からない(出所: 自社の運用記録、確認日2026-09-06)。気づく仕組みは、期間を決めて検証を再実行する、追加した文書の差分を検証するといった能動的な運用でしか作れない。
無人で動かし続けるための実装にも工数がかかる
AI導入後に人手を減らす狙いで自動化を進めても、無人で安定して動かし続けるための実装そのものに工数がかかる。自社が社内で運用する無人自動化システムを、無人運用に堪える品質(処理が失敗しても壊れずに再試行できること、途中で壊れた状態を検知できること、実行結果を1か所にまとめて確認できること)へ引き上げた際には、対象ごとにテストを実装し、32件・26件・61件のテストがすべて通過することを確認してから本番へ反映した(出所: 自社の運用記録、確認日2026-09-06)。監視や再構築だけでなく、無人運用そのものを支える実装と検証にも継続的な工数がかかることになる。
年間で発生する運用イベントの種類
年間の運用工数を見積もる際は、少なくとも次の3種類のイベントを想定しておく必要がある。1つ目は期間を決めた検証の再実行、2つ目は追加した文書やデータの差分検証、3つ目は自動化システムの改修・機能追加を本番へ反映する作業である。いずれも「動いているかどうか」の確認ではなく、「壊れたことに気づけるかどうか」を確認する作業である点が共通している。
体制を決めるときに残る論点
誰が検証を再実行し、どの頻度で行い、結果をどこで確認するかは、公開前に決めておく必要がある。決めないまま稼働に入ると、気づく主体が「たまたま気づいた誰か」に依存する状態になる。この論点への一般的な正解は無く、組織の規模や監視体制に応じて個別に決める必要がある。
導入前に測っておくべき数字はAI導入前に測っておく数値の記事、事前登録した検証で誤投資を防いだ実例は効果の検証設計の記事、最初に着手する業務の選び方は最初に着手する業務の選び方の記事を参照してほしい。運用体制の設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 運用体制を組む前にまず何を決めておくべきか
何を「壊れた」とするかの定義である。自社のRAG運用では、公開前の検査で使った基準を稼働後もそのまま判定基準として使っている。
Q2. 実行時にAIを呼ばない構成では何が測れないのか
会話のたびに応答の妥当性をAIが自動で確認する仕組みは働かない。検証はビルド時に集中しており、稼働中の応答が検証時と同じ水準かは実行時の仕組みだけでは分からない。
Q3. 無人自動化を進めれば運用工数はゼロになるか
ならない。自社が無人運用に堪える品質へ引き上げた際には、対象ごとにテストを実装し、32件・26件・61件のテストがすべて通過することを確認してから本番へ反映しており、無人運用そのものを支える実装と検証に工数がかかる。
Q4. 年間の運用工数はどのようなイベントを想定すればよいか
期間を決めた検証の再実行、追加した文書やデータの差分検証、自動化システムの改修・機能追加を本番へ反映する作業の3種類を想定しておく必要がある。