2026.09.28

AIプロダクト

生成AIの運用・保守の進め方|PoCの後に必要な監視・更新・改善の体制

※本記事は2026年9月時点の公開資料(総務省・経済産業省「AI事業者ガイドライン(第1.1版)」、Anthropic公式ドキュメントのモデル廃止方針 等)と、当社が社内で毎日動かしている生成AIの自動処理の運用記録にもとづく内容です。顧客案件は業界・概要のみに匿名化しています。確認頻度などの数値は当社の運用での目安であり、業務により適切な値は変わります。

「PoC(試験導入)はうまくいった。でも、本番で誰がどう面倒を見るのかが決まらず、そのまま止まっている」——生成AIの導入で、いちばん多い止まり方です。

生成AIの運用・保守は、稼働・品質・コスト・変化の4点を決まった頻度で監視し、月1回の改善会議で直す・戻す・止めるを決める仕組みです。

本記事では、PoCの後に必要な監視の項目、プロンプトとデータの更新手順、問い合わせと障害への対応、体制と役割分担、外注と内製の考え方を順に整理します。PoCそのものの設計は生成AIのPoCの進め方、費用対効果の測り方は生成AI導入のROIの考え方で扱っており、本記事は「本番に乗せた後、どう使い続けるか」に絞ります。

この記事の結論(30秒サマリ)
– 生成AIの保守は、従来システムと違い「動いていても質が落ちる」「提供側の都合で変わる」のが前提。
– 監視は「運用4点監視」=稼働・品質・コスト・変化。1件ずつのチェックでは見えない劣化があるため、横断の定期点検を入れる。
– プロンプトやデータの更新は評価セットで確かめてから、戻せる形で切り替える。
– 運用の担当・頻度・止める条件は、PoCの企画段階で決めて書いておく。

この記事の監修:大槻 伸夫(キュリオシティ株式会社 代表取締役CEO)。”現場主義 × AI”を掲げ、業務改善(BPR)から生成AIのPoC・社内実装までを一貫して支援。社内では文書生成や会議記録の整理など、生成AIの自動処理を複数本番で運用し、その監視と改善の仕組みを自ら設計している。


結論:運用・保守は「運用4点監視」と月1回の改善会議で回す

生成AIを本番で使い続けるために、私たちは次の4点を決まった頻度で見ています。これを「運用4点監視」と呼んでいます。

生成AIの運用4点監視と改善の回し方|稼働・品質・コスト・変化の4点を日次〜四半期で確認し、改善会議で検知→原因の切り分け→評価セットで確認→戻せる形で切り替え、の順に回す
生成AIの運用4点監視と改善の回し方|稼働・品質・コスト・変化の4点を日次〜四半期で確認し、改善会議で検知→原因の切り分け→評価セットで確認→戻せる形で切り替え、の順に回す
監視の点 見る問い 主な指標・確認方法 確認頻度の目安
① 稼働 止まっていないか 失敗件数と原因の内訳(タイムアウト・異常終了・連携先の停止) 日次
② 品質 質が落ちていないか 抜き取りの人手確認、複数の出力をまとめて見る横断点検 週次〜月次
③ コスト 費用が膨らんでいないか 1件あたり費用、利用者数と利用量、上限アラート 月次
④ 変化 外の変化に追随できるか モデルの廃止・仕様変更の告知、社内データの鮮度 月次〜四半期

見つけた問題は、月1回の改善会議で「直す・戻す・止める」のどれかに決めます。国の「AI事業者ガイドライン」も、AIの提供者に対して入出力を定期的に評価し、モニタリングすることを求めています(出典:総務省・経済産業省「AI事業者ガイドライン(第1.1版)」令和7年3月28日)。

なぜ生成AIはPoCの後に止まりやすいのか?

PoCでは「使えるか」だけを確かめ、「誰が面倒を見るか」を決めないまま終わるからです。

PoCの報告会では精度や効果の数字が並びますが、本番化の稟議に進むと「障害が起きたら誰が対応するのか」「回答がおかしくなったら誰が気づくのか」「月の費用の上限は」と聞かれ、答えられずに止まります。

加えて、生成AIの保守は従来のシステム保守と前提が違います。

観点 従来のシステム保守 生成AIの運用・保守
出力 同じ入力なら同じ結果 同じ入力でも結果が揺れる
劣化 壊れなければ動き続ける 動いていても質が落ちる(データの古さ・使われ方の変化)
変更のきっかけ 自社の改修 提供側のモデル廃止・仕様変更でも変わる
費用 月額固定が中心 利用量に比例して増減する
正しさの確認 テストで合否が決まる 評価セットと人の確認で判断する

このため、「エラーが出ていないから大丈夫」という従来の監視だけでは足りません。

何を監視すればよいか?「運用4点監視」の中身

① 稼働:失敗の多くはAIの「質」ではなく「動き方」で起きる

当社では、社内の定型文書を毎日自動で生成する仕組みを本番で動かしています。2026年6月から9月までの約3か月半で約270回実行し、失敗は17回(約6%)でした。

注目すべきは内訳です。

  • 処理時間の上限(1回60分)を超えたもの:5回
  • 処理が途中で異常終了したもの:11回
  • 周辺の仕組み(終了時の後処理)で止まったもの:1回

17回すべてが「AIの回答の質」ではなく「処理が最後まで動かなかった」種類の失敗でした。質の問題と動作の問題は、見つけ方も直し方も違います。そこで当社では次の2つを決めています。

  • 成否を「結果ファイル」で判定する:処理が終わったら、成否・識別番号・自己評価点を決まった形式で必ず書き出させ、書き出されていなければ失敗とみなす。「ログを読んで判断する」を人に残さない。
  • 処理ごとに状態を持たせる:「待ち→処理中→下書き→公開」と「エラー」「保留」を台帳で管理し、保留にした案件は自動で飛ばす。止めたいときに止められるスイッチを最初から用意しておく。

② 品質:1件ずつの確認では見えない劣化がある

品質の監視でいちばん大事なのは、1件ずつの確認だけに頼らないことです。

当社の同じ仕組みで、生成した文書200本超をまとめて機械的に突き合わせたところ、本来は別々であるべき事例の段落が、業種名だけ差し替えて複数の文書に使い回されていることが分かりました。最も似ていた組では23文が一字一句同じでした。1本ずつの人の確認でも、AI自身による採点でも、この問題は見つかっていませんでした。どの1本も、それ単体では自然に読めたからです。

原因はAIへの指示文ではなく、AIが参照すべき社内の知見の置き場所が空だったことでした。対策も指示文の修正ではなく、参照データの側で行いました。事例を1件ずつ台帳に登録し、使った文書を記録して、同じ事例を二度使えないルールにしています。

ここから言える運用のポイントは2つです。

  • 抜き取りの人手確認(週次)に加えて、複数の出力を並べて見る横断点検(月次)を入れる。
  • 質が落ちたとき、「AI」「実行基盤」「参照データ」のどこが原因かを先に切り分ける。指示文をいじる前に、参照データを疑う。

誤答そのものを減らす設計は生成AIのハルシネーション対策、社内文書検索型AI(RAG)の検索精度の改善はRAGの精度を上げる方法で詳しく解説しています。

③ コスト:1件あたりと上限の2つで見る

生成AIの費用は利用量に比例して増えるため、月末の請求書で初めて気づく、という事態が起こりがちです。見るのは次の2つで十分です。

  • 1件あたり費用:問い合わせ1件、文書1本あたりいくらかかっているか。効果(削減時間)と並べて、ROIの前提が崩れていないかを確かめる。
  • 上限アラート:月の予算の7〜8割に達したら担当者に通知する。処理1回あたりの時間上限も、暴走したときの費用の歯止めになる。

費用が上がったときは、利用者が増えた(良い増加)のか、1件あたりが膨らんだ(悪い増加)のかを分けて見ます。後者なら、長すぎる参照文書や不要な再実行を疑います。

④ 変化:モデルは提供側の予定で廃止される

生成AIの保守で見落とされやすいのが、自社が何も変えていなくても、提供側の都合で動かなくなることです。

たとえばAnthropicは、公開モデルの廃止について少なくとも60日前に通知し、廃止日を過ぎたモデルへのリクエストは失敗すると明記しています。あわせて、廃止日よりかなり前に新しいモデルで自社の用途を試験することを推奨しています。モデルそのものだけでなく、特定の設定値(生成のランダムさを調整するパラメータ等)が新しいモデルでエラーになる、といった仕様変更も告知されています(出典:Claude公式ドキュメント「Model deprecations」)。

社内データの側も変わります。規程の改定、商品の入れ替え、組織変更があれば、RAGが参照する文書が古くなり、AIは古い答えを自信を持って返します。「文書の最終更新日」を月次で一覧にして、更新漏れを確認するのが確実です。

プロンプトやデータはどう更新すればよいか?

変更は1回に1つだけ、評価セットで確かめてから、戻せる形で切り替えます。

  1. 版を残す:指示文(プロンプト)、参照データ、モデルの指定を、日付つきの版として保存する。どの版で何が起きたかを後で追えるようにする。
  2. 評価セットで確かめる:PoCで使った「正解つきの質問集」を運用でも使い続け、変更の前後で結果を比べる。良くなった点だけでなく、前はできていたことが崩れていないかを見る。
  3. 1回に1つだけ変える:指示文とモデルを同時に変えると、結果が変わった原因が分からなくなる。
  4. 戻せる形で切り替える:前の版にすぐ戻せる状態で切り替え、数日は抜き取り確認を増やす。

評価セットは作って終わりではなく、問い合わせで寄せられた誤答を1件ずつ追加して育てていくものです。PoC段階での評価の組み立て方は生成AIのPoCの進め方の評価・撤退基準の節を参照してください。

問い合わせや障害にはどう対応するか?

まず4つに仕分け、誤答の報告は評価セットに戻すのが基本です。

問い合わせの種類 例 一次対応 その後
使い方 「どう聞けばいいか分からない」 よくある質問・使い方ガイドで回答 多い質問はガイドに追記
誤答 「規程と違う答えが出た」 正しい答えを案内し、入力と出力を記録 評価セットに追加し、原因を切り分け
障害 「動かない」「遅い」 稼働状況を確認し、影響範囲を周知 原因と再発防止を記録
要望 「この業務にも使いたい」 受付のみ 改善会議で優先順位を判断

障害時に大事なのは、「止める」判断を誰がするかを先に決めておくことです。誤った内容が社外に出る恐れがある用途では、原因が分かるまで人の確認を必須に戻す、あるいは一時停止する、といった判断基準を事前に書いておきます。社内の利用ルールの作り方は生成AI 社内利用規程の作り方で解説しています。

社内の問い合わせ窓口にAIを使う場合の設計は、社内問い合わせチャットボットの作り方も参考になります。

運用体制は誰が何を持てばよいか?

「業務の持ち主」と「仕組みの持ち主」を分け、両者が月1回同じ席で話す形が基本です。

役割 主な担当 運用4点監視での持ち分
業務オーナー(利用部門の責任者) 使う・使わないの判断、止める判断、効果の確認 ②品質の合否判断、③費用対効果
運用担当(利用部門の実務者) 抜き取り確認、問い合わせの一次受け、評価セットへの誤答追加 ②品質の確認
開発・保守担当(社内IT/外部パートナー) 稼働監視、版の管理と切り替え、モデル変更への対応 ①稼働、④変化
情報システム・ガバナンス担当 権限・ログの管理、利用規程、費用の上限管理 ③コスト、④変化(契約・規約)

中小企業では、業務オーナーと運用担当を同じ人が兼ね、開発・保守を外部に任せる形が現実的です。その場合でも、抜き取り確認と止める判断だけは社内に残すことをおすすめします。ここを外に出すと、業務に合っているかを誰も判断できなくなるからです。

全社としての管理の枠組みはAIガバナンスとはで整理しています。

保守は外注と内製のどちらがよいか?費用はどう考える?

稼働監視と版の切り替えは外注しやすく、品質の判断と改善の優先順位は内製で持つ、という分け方が失敗しにくい形です。

保守の費用は、次の3つに分けて見積もると比較しやすくなります。

  • 利用料:AIの利用量に比例する費用。上限アラートで管理する。
  • 定常の保守:稼働監視、障害対応、モデル変更への追随。月額の定額で持つことが多い。
  • 改善の開発:指示文の見直し、参照データの追加、機能追加。改善会議で決めた分だけ都度見積もる。

「保守費に何が含まれるか」を契約前に確認しないと、モデル変更への対応が追加費用になって揉める、ということが起こります。内製と外注の判断軸は生成AIは内製か外注か、本番開発まで含めた費用の内訳は生成AI導入の費用相場で詳しく扱っています。

PoCの段階で決めておくべき運用の5項目は?

本番化で止まらないために、PoCの企画書に次の5項目を書いておくことをおすすめします。

  1. 運用の担当者:業務オーナー・運用担当・保守担当の名前(または役割)。
  2. 監視の頻度:運用4点監視を、それぞれ誰がいつ見るか。
  3. 品質の合格線と止める条件:どこを下回ったら人の確認に戻す・一時停止するか。
  4. 費用の上限:月の予算と、アラートを出す水準。
  5. 変更の手順:評価セットで確かめてから、戻せる形で切り替えること。

この5項目がPoCの時点で決まっていれば、「効果は出たが誰が面倒を見るのか」で止まることはなくなります。企画書づくりには、「生成AI PoC企画テンプレート」を無料で配布しています。対象業務の選定から評価指標・撤退基準まで、埋めるだけで企画書の骨子ができる形式です。

よくある質問(FAQ)

Q. 生成AIの運用・保守では、最低限何を監視すればよいですか?
A. 稼働・品質・コスト・変化の4点です。稼働は失敗件数と原因を日次で、品質は抜き取りの人手確認を週次で、コストは1件あたり費用と上限を月次で、変化はモデルの廃止告知と社内データの鮮度を月次〜四半期で確認するのが目安です。

Q. エラーが出ていなければ、生成AIは正常に動いていると考えてよいですか?
A. いいえ。生成AIは動いていても質が落ちることがあります。1件ずつの確認では自然に読めても、複数の出力を並べると同じ内容の使い回しや偏りが見つかることがあるため、月次の横断点検を入れることをおすすめします。

Q. 使っているAIモデルが廃止されたらどうなりますか?
A. 廃止日を過ぎるとそのモデルへのリクエストは失敗します。提供側は事前に通知するため、告知を定期的に確認し、廃止日よりかなり前に後継モデルで評価セットを流して結果を比べ、戻せる形で切り替えます。

Q. プロンプトを改善するときの注意点は何ですか?
A. 1回に1つだけ変え、変更前後を同じ評価セットで比べることです。良くなった点だけでなく、以前はできていたことが崩れていないかも確認します。版は日付つきで残し、すぐ前の版に戻せるようにしておきます。

Q. 運用・保守は外部に任せても大丈夫ですか?
A. 稼働監視や版の切り替え、モデル変更への対応は外部に任せやすい領域です。一方、出力が業務に合っているかの判断と、止める判断は社内に残すべきです。契約前に、保守費にモデル変更への対応が含まれるかを確認してください。

まとめ:生成AIは「作って終わり」ではなく「見て直し続ける」

  • 生成AIの保守は、動いていても質が落ちる・提供側の都合で変わることが前提。
  • 監視は「運用4点監視」=稼働・品質・コスト・変化。失敗の多くは質ではなく動き方で起きるため、結果ファイルで成否を判定し、止めるスイッチを用意する。
  • 品質は1件ずつの確認に加えて横断の定期点検。原因はAI・実行基盤・参照データに切り分ける。
  • 更新は1回に1つ、評価セットで確かめ、戻せる形で。誤答の報告は評価セットに戻して育てる。
  • 担当・頻度・合格線・費用上限・変更手順の5項目をPoCの企画段階で決めておく。

まずは、いまPoC中または本番化を待っている生成AIについて、5項目を1枚に書き出すところから始めてみてください。


監修:大槻 伸夫(キュリオシティ株式会社 代表取締役CEO)
業務改善(BPR)とAI活用を”現場主義 × AI”で支援。業務の可視化から生成AIのPoC・社内実装、本番運用の仕組みづくりまで、現場に定着する形で伴走しています。


監修者

大槻 伸夫/ 代表取締役 CEO

キュリオシティ株式会社 代表取締役CEO。「現場主義×AI」を掲げ、業務改善(BPR)・PMI・経営支援・AIプロダクト開発を一気通貫で支援。クライアント現場での実行支援を重視する。

業務改善・PMIのご相談はキュリオシティへ

記事で紹介したテンプレートの配布や、貴社課題に合わせた無料相談を行っています。

BACK TO INDEX