AIは、導入した時点が最高品質とは限らない。むしろ、業務や情報が変わるなかで放置すると、回答や予測の精度は少しずつずれていく。これを防ぐのが運用、いわゆるLLMOps（生成AIの運用）の役割である。ところが、開発費は確保しても、運用を担う人と仕組みを決めていない発注は多い。
本記事では、運用者が不在のままAIを導入すると何が起きるかを発注者の視点で整理し、発注前に確認すべき項目と開発会社への質問を示す。運用は派手ではないが、AIが「使い続けられる」かどうかを決める要素である。開発と同じくらい、誰がどう運用するかを発注前に描いておきたい。運用の体制が描けていないと、導入時は良くても、時間とともに「最近使えなくなった」という評価に変わっていく。
結論：AIは導入後の評価、更新、改善担当まで発注範囲に入れる
AIの精度は、公開時点で固定されるものではない。GXOが運用設計で確認するのは、参照情報の更新担当、回答評価、ログ確認、改善定例、品質責任者、運用費の扱いである。
- 月次でもよいので、ログを見て回答を直す場を作る
- 制度、価格、商品など変わりやすい情報の更新担当を決める
- 開発費とは別に、運用と改善の継続費用を見積に入れる
運用者がいないAIは、導入直後よりも時間が経ってから信頼を失いやすい。
MANUFACTURING DX
Excel限界から受発注システムへ、同規模の概算は？
中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。
運用者がいないと、何が起きるか
導入後に運用者がいないと、次のような劣化が静かに進む。
- 業務や制度が変わっても、AIの参照情報が古いまま残る
- 誤った回答が放置され、利用者の信頼が下がる
- 「答えられなかった質問」が記録されず、改善されない
- 問い合わせの傾向が変わっても、対応する範囲が見直されない
- 誰が品質に責任を持つのか曖昧で、改善が止まる
精度の劣化は一気には起きないため気づきにくい。気づいたときには「最近使えなくなった」という評価が定着していることがある。
なぜ運用が後回しになりがちか
開発がゴールだと考えてしまう
AIは「作れば終わり」ではなく「運用しながら育てる」仕組みである。開発の完了をゴールと捉えると、運用の体制づくりが計画から抜け落ちる。
運用の費用と工数が見えていない
回答の評価、情報の更新、ログの確認、改善の検討。これらには継続的な工数がかかる。見積に運用が含まれていないと、運用は「誰かが片手間でやるもの」になり、続かない。費用の内訳はAI開発見積の読み解きガイドも参照してほしい。
ログを活用する仕組みがない
「どんな質問に答えられなかったか」「どの回答が役立たなかったか」はログに表れる。しかし、ログを見て改善につなげる仕組みがないと、貴重な改善材料が埋もれる。権限とログの設計はAIエージェントの権限・ログと暴走リスクでも扱っている。
責任者が決まっていない
品質に責任を持つ人が決まっていないと、誰も改善を主導しない。「みんなの仕事」は「誰の仕事でもない」状態になりやすい。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
運用がある場合とない場合の違い
| 観点 | 運用者がいない | 運用の仕組みがある |
|---|---|---|
| 参照情報 | 古いまま放置 | 更新の担当と頻度が決まっている |
| 回答品質 | 誤りが残る | 定期的に評価・修正する |
| ログ | 見られない | 答えられなかった質問を改善に回す |
| 対象範囲 | 固定のまま | 問い合わせ傾向に合わせて見直す |
| 責任 | 曖昧 | 品質責任者が決まっている |
| 改善 | 止まる | 定期的な改善の場がある |
運用は、特別なことを毎日やることではない。少人数でも、評価・更新・改善の場を回す仕組みがあれば成立する。
小さく回す運用サイクルの例
運用は、専任の担当者が毎日張り付くことを意味しない。少人数でも、決まったサイクルで「見る・直す・決める」を回せば成立する。たとえば、次のような月次のサイクルが一つの型になる。
- ログを見る：その月に「答えられなかった質問」「役に立たなかった回答」を抽出する。
- 情報を更新する：制度や価格など、変わった情報を反映する。古いまま残っている文書を最新版に差し替える。
- 回答を直す：誤りや分かりにくさが見つかった回答を修正する。よく聞かれるのに答えられていない質問を追加する。
- 改善点を一つ決める：次の一か月で取り組む改善を一つ決める。あれもこれもと広げず、効果の大きいものに絞る。
このサイクルを回すだけでも、精度の劣化を防ぎ、少しずつ改善できる。重要なのは、頻度と担当を決めて「やる場」を作ることである。場がないと、運用は「気づいた人がたまにやる」ものになり、やがて止まる。
担当は一人に固定しなくてよいが、品質に責任を持つ人は決めておきたい。責任者がいると、改善の優先順位を判断でき、迷ったときの拠り所になる。社内だけで回すのが難しい場合は、ログの確認や改善の検討を外部に任せ、情報の更新だけ社内で担う、といった分担も有効である。発注前に、この運用サイクルを誰が、どの頻度で回すのかを描いておくと、導入後の劣化を防ぎやすい。
発注前に確認すべき項目
- 運用を担う担当者（社内または外部）を確保できる見込みがあるか
- 参照情報・ナレッジを誰が、どの頻度で更新するか決めたか
- 回答品質を定期的に評価する仕組みを想定したか
- 問い合わせログ（答えられなかった質問など）を確認する運用を決めたか
- 改善を検討する場（定例の見直しなど）を設けるか決めたか
- AIの品質に責任を持つ担当者を決められるか確認したか
- 運用にかかる費用・工数を見積に含めたか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| 導入後の精度はどう維持しますか | 運用の考え方があるか |
| 回答品質はどの頻度で、誰が評価しますか | 評価の仕組み |
| ログから改善する流れはどうなりますか | ログ活用の設計 |
| 情報の更新は社内と分担できますか | 内製と外注の切り分け |
| 運用は契約に含まれますか、別ですか | 運用費の所在 |
「導入したら自動で賢くなる」という説明だけでは不十分である。誰が、何を見て、どう改善するかを具体的に説明できるかを確認したい。
GXOに相談する前に整理するとよい情報
- AIに使わせる情報のうち、変わりやすいもの（制度、価格、商品など）
- 社内で運用に関われそうな担当者がいるか
- 問い合わせや業務の傾向が、季節や時期で変わるか
- 品質に責任を持てる立場の人がいるか
- 運用にかけられる時間・費用の見込み
運用に使えるリソースが見えると、「どこまで内製し、どこを外部に任せるか」を現実的に設計できる。
これらが整理されていなくても相談は可能である。運用に関われそうな人と、変わりやすい情報が見えていれば、無理のない運用サイクルの設計から一緒に検討できる。
参考にした外部観点
AIの運用では、品質、ログ、更新、リスク管理を継続的に扱う必要がある。NIST AI Risk Management FrameworkはAIリスクを管理する枠組みであり、IPAのDX推進指標は組織としてDXを継続する観点を確認する際に参考になる。
運用設計では、月10件の回答評価、30日ごとのログ確認、3ヶ月ごとの改善判断、1年分の運用費と担当者を決めておくと、精度劣化を早期に見つけやすい。
関連記事
よくある質問
Q1. 少人数の会社でも運用体制は作れますか
作れる。毎日専任で見る必要はなく、月次でログを確認し、情報を更新し、改善点を一つ決める、という小さなサイクルでも効果がある。重要なのは、担当と頻度を決めておくことである。
Q2. 運用は開発会社に任せきりでよいですか
任せる部分があってよいが、社内の情報更新や品質判断は、業務を知る社内の人が関わるほうが現実的である。内製と外注の分担を発注前に決めておきたい。
Q3. 精度が落ちてきたら、作り直すしかないですか
多くの場合、作り直す前に、参照情報の更新やログに基づく改善で回復できる。運用の仕組みがあれば、劣化に早く気づいて手を打てる。
Q4. 運用を外部に任せる場合、何を社内に残すべきですか
情報の正しさを判断する部分は、業務を知る社内の人が担うほうがよい。ログの抽出や改善案の整理といった作業は外部に任せられるが、「この回答は自社として正しいか」「この情報は最新か」という判断は、社内でなければ難しい。外部に任せる作業と、社内で判断する部分を分けて契約に落とすと、運用が回りやすい。責任の所在を曖昧にしないことが、外部活用を成功させる前提になる。
Q5. 運用にかかる費用は、どのくらい見ておくべきですか
利用規模や更新頻度で変わるため一律には示せないが、初期の開発費だけでなく、運用にかかる継続費用を最初から見込んでおくことが重要である。運用費を別予算として確保していないと、せっかく作った仕組みを維持できなくなる。見積に運用の項目が含まれているかを確認するとよい。
AIの運用体制を、発注前に設計しませんか
GXOでは、回答評価、ナレッジ更新、ログ確認、改善定例、品質責任者、運用費を整理し、導入後も精度を維持する体制づくりを支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。