PoCで動いたAIを落ちない本番にする運用設計 評価と監視の実装手順

PoCで動いたAIが本番で止まるのは、評価と監視の設計が抜けているから。落ちない本番にする運用設計を、評価・監視・運用の3層で実装手順まで具体的に解説する。

PoCのAIが本番で落ちる本当の理由

PoCで動いたAIの多くが本番で止まる。理由は技術ではなく、運用の設計が抜けていることにある。

実際に相談を受ける現場で多いのは、PoCのデモは完璧に動いたのに、本番で1週間も経たないうちに「精度が落ちている」「ハルシネーションが出た」「LLMの仕様変更で出力形式が変わった」という事象が連続し、誰も対処できない状態に陥るケースだ。原因は3つに分けられる。

1つめは入力データの分布変化。PoCで使った10件のサンプルと、本番で来る数百件の実データは中身が違う。表記揺れ、画像の解像度、文章の長さ、業界用語の出現頻度。これらが少しずつズレていくだけで、AIの出力品質は静かに劣化する。

2つめはモデル側の変更。GPTやClaudeのようなSaaS型LLMは、ベンダーが裏側でモデルをアップデートする。出力フォーマットや微妙な振る舞いが変わる。PoC時点のプロンプトがそのまま動く保証はない。

3つめは運用体制の不在。誰がいつ何を見て、何を判断するかが決まっていない。エラーログを誰も見ない、出力品質を誰も評価しない、再現確認の手順がない。この状態で本番に置いた瞬間、AIは「動いているように見えて実は崩れている」状態に進む。

落ちない本番にするには、評価と監視と運用の3層を最初から設計する必要がある。技術の問題ではなく設計の問題だと理解することが出発点になる。

評価設計 AIの正しさを継続的に測る仕組み

評価設計とは、AIの出力が「期待した品質を保っているか」を機械的に判定できる仕組みを作ることだ。

最初に必要なのは評価データセット。本番で来る実データの代表例を、入力と「正解」のペアで50件から100件用意する。完璧である必要はない。むしろ「ここを外したら困る」典型例と、過去に間違えた例、エッジケースを優先する。

次に評価指標を3種類定義する。1つめは正解一致率や類似度などの定量指標。LLMなら埋め込みベクトルでのコサイン類似度、構造化抽出ならフィールド一致率を使う。2つめはハルシネーション検知。出力に含まれる事実が入力やナレッジベースに存在するかをチェックする。3つめは業務ルール違反検知。出力フォーマットや禁則語、文字数上限などのビジネス制約を満たしているかを判定する。

評価バッチは週次か月次で自動実行する。GitHub Actionsで評価データセットに対してAIを実行し、3指標をスコア化してSlackに通知する形が最小構成だ。スコアが閾値を下回ったら、本番のプロンプトやモデルを変える前にアラートが立つ状態を作る。

ここで重要なのは、評価の「合格基準」を事前に決めることだ。たとえば類似度0.85以上、ハルシネーション率3%以下、ルール違反0件、といった具体的数字を決め、これを下回ったら本番を止める判断ルールを書いておく。事前に決めていないと、スコアが下がっても「まあいいか」で流れる。本番化の境界線は数字で持つ。

自社のどの業務にAIを入れるかと並行して、評価設計をどう組むかで迷ったら、初月無料の経営AI診断（通常30万円相当）で現状の業務と評価可能なポイントを一緒に整理することもできる。

監視設計 壊れていることに気づける仕組み

評価が「合格基準を満たしているか」を測るのに対し、監視は「いま何が起きているか」をリアルタイムに見える化する仕組みだ。

監視で見るべきは4つの層に分けられる。インフラ層は応答時間とエラー率と稼働率。API層は呼び出し回数とトークン使用量とコスト。出力層は出力長の分布と禁則語の検知数。業務層は人が手動で修正した件数と棄却した件数。

このうち中小企業で最低限入れるべきは、エラー率とトークン使用量と業務層の修正件数の3つだ。エラー率が急増したらAPI障害かプロンプト崩壊が疑われる。トークン使用量が急増したら入力が想定外に肥大化している。修正件数が増えたら品質劣化のサインだ。

具体的な実装は最小構成で十分回る。AIの呼び出しログを構造化JSONでS3かGCSに残し、エラーが出たら即時にSlackに通知する。日次でログを集計し、トークン使用量とエラー件数を可視化する。これだけで「壊れていることに気づける」状態は作れる。

ここで陥りがちなのは、最初から大型のMLOps基盤を入れようとして、構築に3ヶ月かかり結局運用が止まることだ。中小企業の現実解は、Datadogの無料枠やGrafana Cloudで小さく始め、業務に乗ってから必要な指標を足していく順序が現実的に回る。詳しいコスト感は中小企業のAI導入 費用相場と内訳も参考になる。

監視で重要なのは「アラートの数を絞る」こと。本当に対応が必要なものだけを通知する。アラート疲労が起きると、誰も見なくなる。エラー率が一定の閾値を超えたとき、トークン使用量が前日比2倍を超えたとき、業務修正件数が週次で増えているとき、この3種類だけに絞れば運用が回る。

運用設計 壊れたあと素早く戻せる仕組み

評価と監視で「壊れたことに気づける」状態を作ったら、次は「壊れたあと素早く戻せる」仕組みを設計する。

最初に必要なのはバージョン管理。プロンプト、評価データセット、モデルのバージョン、これら3つをGitで管理し、どのバージョンの組み合わせで動いているかを追跡できる状態にする。本番のAIで何かが起きたとき、どのプロンプトとどのモデルとどの評価結果の組み合わせなのかを5分以内に特定できることが目標になる。

次に必要なのはロールバック手順。プロンプトを変えたあとに評価スコアが落ちたら、即時に前のバージョンに戻せる仕組みを用意する。CI/CDパイプラインで、評価バッチが通らないものは本番に出さない、本番に出てから問題が出たら1コマンドで前のバージョンに戻せる、この2点を最低限満たす。

3つめはランブック。「エラー率が10%を超えたら誰が何をするか」「ハルシネーションが報告されたら誰が確認するか」を1ページのドキュメントにまとめる。中小企業なら担当1人で十分だが、その1人が動けないときの代替手順まで書いておく。

最後に月次のレビュー会議。30分でいい。先月のエラー件数、評価スコアの推移、業務修正件数、改善した点と次に取り組むことを共有する。レビューを回すだけで、AIの品質は継続的に改善する。レビューがないと劣化に気づけない。

注文管理のような業務にAIを入れた場合、こうした運用設計があるかないかで、その後のトラブル対応コストが大きく変わる。具体的な業務ごとの自動化設計は注文管理業務のAI自動化どこまでできるかも併せて参考になる。

中小企業が現実的に始める3ステップ

ここまで読んで「全部やるのは大変そう」と感じた経営者向けに、現実的な3ステップを示す。

ステップ1は最小監視。AIの呼び出しログをS3かGCSに残し、エラーが出たらSlack通知。所要時間は1日から2日、コスト月額1,000円以下で実装できる。これだけでも「壊れていることに気づけない」状態は脱却できる。

ステップ2は最小評価。50件の評価データセットを作り、月次でGitHub Actionsから評価バッチを実行する。所要時間は立ち上げ20時間、その後月3時間。コスト月額500円から3,000円。ここまでで「品質を測る仕組み」が回り始める。

ステップ3はバージョン管理とロールバック。プロンプトと評価データセットをGit管理し、CI/CDで評価が通らないものは本番に出さない設計に切り替える。所要時間は5日から10日、コストはほぼゼロ。ここまでで「壊れたら戻せる」状態が完成する。

3ステップ合計で2週間から1ヶ月、コスト月額数千円から1万円の範囲で本番運用の最低限は作れる。これを「最初から完璧にやろう」とすると3ヶ月かかって挫折する。順番に1つずつ立ち上げ、業務に乗せてから次に進むのが続く設計だ。

PoCから本番への移行を検討中で、自社のどこから始めるべきか迷っているなら、初月無料の経営AI診断（通常30万円相当）で現状の業務とAI導入候補を整理し、運用設計まで含めた改善提案をご一緒できる。

まとめ AIの本番化は技術ではなく設計の問題

PoCで動いたAIを本番で落ちないようにする鍵は、評価と監視と運用の3層を最初から設計しておくことだ。評価で「品質を測る基準」を持ち、監視で「壊れたことに気づける」状態を作り、運用で「素早く戻せる」手順を整える。

中小企業でも月額1万円から3万円、立ち上げ工数2週間から1ヶ月の範囲で最低限の本番運用は組める。重要なのは技術選定よりも、合格基準を数字で決め、誰が何を見て何を判断するかを明文化することだ。

PoCで止まっているAIプロジェクトがあるなら、まず最小監視と最小評価から始めることをお勧めする。落ちない本番にするための運用設計は、特別な技術ではなく当たり前の設計の積み重ねで作れる。

関連記事

• AIアプリ本番化前のセキュリティ監査チェックリスト — 関連: 本番化前の最終確認をセキュリティ観点で網羅
• 注文管理業務のAI自動化どこまでできるか — 関連: 業務単位での自動化と運用設計の組み合わせ
• 中小企業がClaude Codeで業務自動化する導入ステップとROI試算 — 関連: 自動化導入の段階設計
• 中小企業のAI導入 費用相場と内訳 — 関連: 監視・評価まで含めたコスト感の把握