この記事で分かること／分からないこと
- 分かること: 運用体制で「壊れた」をどう定義するか
- 分かること: 実行時0LLMという構成が気づく仕組みに与える影響
- 分からないこと: 誰が一次対応するかという体制の正解
- 分からないこと: 現在の監視体制が十分かどうか
「壊れた」をどう定義するか
運用体制を作る前に、何を「壊れた」とするか決めておく必要がある。公開前ゲートで使った基準(hit率91%を下回る、致命的な失敗が起きるなど、出所: services/verifier/out/ucaro-verification.json、確認日2026-09-06)は稼働後にも同じ意味を持ち、判定基準としてそのまま使える。
実行時0LLMという構成の意味
自社の構成では、実行時に触るのは索引(D1のfaqs)だけで、確定回答の配信時にLLMを呼び出さない(実測0.12円/session、確認日2026-09-06)。運用コストを抑える一方、会話ごとにLLMが応答の妥当性を確認する仕組みは働かない。検証はビルド時に集中し、稼働中の応答が検証時と同じ水準かは実行時の仕組みだけでは分からない。
検証レポートの置き場所
検証結果のフルJSONはR2に置かれ、UIが1回だけ取得する設計になっている(出所: docs/STORAGE_AND_BILLING.md)。毎回参照される設計ではなく、必要なときに見に行く設計である点は前提になる。誰かが能動的に見に行かない限り、更新されても気づかれない。
気づく仕組みを人に依存させない工夫と限界
会話のたびにLLMが確認する仕組みが無い以上、気づく仕組みは、期間を決めて検証(Layer1・Layer2)を再実行する、追加文書の差分を検証するといった能動的な運用でしか作れない。ビルド時検証の仕組み自体は実在するが、再実行の頻度や担当を定めた運用ルールは本稿の範囲外である。
運用体制を決めるときに残る論点
誰が検証を再実行し、どの頻度で行い、結果をどこで確認するかを公開前に決めておく必要がある。決めないまま稼働に入ると、気づく主体が「たまたま気づいた誰か」に依存する状態になる。
よくある質問
Q1. 稼働後に「壊れた」をどう判定すればよいか
公開前ゲートで使った基準(hit率91%を下回る、致命的な失敗が起きるなど、出所: services/verifier/out/ucaro-verification.json、確認日2026-09-06)を、稼働後もそのまま使う考え方が取れる。
Q2. 実行時0LLMという構成では何が測れないのか
会話のたびに応答の妥当性をLLMが自動で確認する仕組みは働かない。検証はビルド時に集中しており、稼働中の応答が検証時と同じ水準かは実行時の仕組みだけでは分からない。
Q3. 検証レポートはどこに置かれているのか
検証結果のフルJSONはR2に置かれ、UIが1回だけ取得する設計になっている。毎回自動で参照される設計ではない。
Q4. 気づく仕組みは何で補えばよいか
期間を決めて検証を再実行する、追加文書の差分を検証するといった能動的な運用で補う。誰が・どの頻度で再実行するかを公開前に決めておく必要がある。
判定に使う合格基準の決め方は合格基準の決め方の記事、基準を下回った場合の対応は撤退条件の記事で扱う。前段の段階公開は段階公開の記事を参照してほしい。運用体制について相談したい方はお問い合わせから編集部までご連絡いただきたい。
- ハブ記事: RAGサービス比較15選
- 関連記事: 段階公開の考え方
- 関連記事: 撤退条件を先に決める
- 関連記事: 公開前検査の読み方