「AIが間違えた」の次に起きる、本当の問題
AIを組み込んだ業務システムを導入すると、必ず一度は「出力がおかしい」という場面に行き当たります。見積書の金額が合わない、問い合わせ回答に存在しない規約が書かれている、分類タグが明らかに違う。こうした事象そのものは、ある程度は織り込み済みで設計すべきものです。
問題はその次です。現場が気づいても誰に言えばいいか分からない、情報システム担当に上がっても原因が特定できない、ベンダーに連絡しても「仕様です」と返ってくる。結果として利用者が黙ってAIを使わなくなる、というのが導入失敗の典型的な形です。
本記事では、AIの出力不具合を「気づく人」「切り分ける人」「直す人」の3つの役割に分け、さらに原因がプロンプト・データ・モデルのどこにあるかで対応を変える、という運用体制の組み方を説明します。
AIの「おかしい」には3つの層がある
まず前提として、生成AIを使ったシステムの出力がおかしくなる原因は、大きく3層に分かれます。どの層かによって、直せる人も、直すのにかかる時間も、費用も違います。
- プロンプト層：プロンプトとは、AIに与える指示文のことです。システム側に埋め込まれた固定の指示（システムプロンプト）と、利用者が入力する内容の両方を含みます。出力形式の崩れ、指示の取りこぼし、トーンのずれはここが原因であることが多い層です。
- データ層：AIが参照する社内文書やデータベースの中身です。多くの業務システムではRAG（検索拡張生成。社内文書を検索してAIに渡し、それを根拠に回答させる仕組み）が使われます。古い規程が残っている、PDFの表がうまく読み取れていない、検索がそもそも目的の文書を引けていない、といった問題がここに当たります。
- モデル層：AIモデルそのものの能力や癖です。計算が苦手、長文の中盤を読み飛ばす、もっともらしい嘘を書く（ハルシネーション）といった、モデル固有の限界が該当します。
現場から上がってくる報告はたいてい「AIが間違えた」の一言です。これを3層のどこかに仕分けする工程を、誰かが必ず担う必要があります。
役割を3つに分ける
中小企業では「AI担当者」を1人置いて丸投げになりがちですが、求められるスキルが違うため分けたほうが機能します。
| 役割 | 担う人 | やること | やらないこと |
|---|---|---|---|
| 気づく人 | 業務の現場担当者 | おかしい出力を定型フォーマットで報告する。入力内容・出力内容・期待した結果をセットで残す | 原因の推測、自己判断での設定変更 |
| 切り分ける人 | 社内のシステム担当、または情報システム兼務者 | 再現確認、プロンプト／データ／モデルのどの層かを判定、緊急度の判断、必要ならベンダーへ連携 | モデルの入れ替えなど構成変更の決定 |
| 直す人 | 層によって変わる（下記参照） | 修正の実施と、修正後の再テスト | 再発防止の記録を残さないこと |
重要なのは「気づく人」に原因分析を求めないことです。現場に「なぜ間違えたか考えてから報告して」と求めると、報告自体が止まります。報告のハードルは徹底的に下げ、判断は切り分け役に集約します。
報告フォーマットは4項目で足りる
凝ったものは続きません。次の4つが揃っていれば切り分けは始められます。
- いつ、どの機能で
- 何を入力したか（コピーそのまま）
- 何が出てきたか（コピーそのまま）
- 本来どうあってほしかったか
4番目が抜けている報告が非常に多いのですが、ここがないと「仕様どおりなのか不具合なのか」が判定できません。
原因の層ごとに、直し方と担い手が変わる
切り分けができたら、層に応じて対応を割り振ります。目安は次のとおりです。
| 層 | 主な症状 | 直し方 | 主な担い手 | 対応の重さ |
|---|---|---|---|---|
| プロンプト | 出力形式が崩れる／指示の一部を無視する／敬語や文体がばらつく | システムプロンプトの修正、出力例の追加、出力スキーマ（形式の定義）の明示 | 社内担当またはベンダー | 軽い。数時間〜数日 |
| データ | 古い情報で回答する／社内にある情報を「分かりません」と返す／根拠の引用がずれる | 文書の更新・削除、文書の分割単位（チャンク）の見直し、検索条件やメタデータの整備 | 業務部門＋ベンダー | 中。文書整備に期間を要する |
| モデル | 計算・集計を誤る／存在しない制度や条文を作る／長文で精度が落ちる | モデル変更、処理の分割、計算は外部ツールに任せる、人の確認を挟む設計に変更 | ベンダー中心 | 重い。再設計と再テストが必要 |
実務でよくあるのは、モデル層の問題をプロンプト層で解決しようとして時間を溶かすパターンです。たとえば次のような場面です。請求データの合計金額が合わないという報告に対し、プロンプトに「正確に計算してください」という一文を足し続ける。これは原理的に解決しません。計算はAIにさせず、システム側で計算した結果をAIに渡して文章化だけさせる、という設計変更が正しい方向です。
逆に、データ層の問題をモデル変更で解決しようとするのも遠回りです。参照する規程集が3年前のまま更新されていないのなら、どれほど高性能なモデルに替えても古い回答が返ります。
エスカレーションと「止める」判断
運用体制でもう一つ決めておくべきは、どの段階でAIの利用を止めるかです。誤りの性質によって、放置してよいものと即座に止めるべきものがあります。
- 即時停止を検討：対外的に出る文書で事実と異なる内容が生成された、個人情報や機密情報が意図しない相手に出力された、金額・数量など取引に直結する値が誤った
- 継続しつつ修正：文体のばらつき、形式の崩れ、社内利用に限った軽微な誤り
個人情報が絡む事象については、個人情報保護法および個人情報保護委員会の示す考え方に照らして、社内の報告ルートと合わせて確認が必要になる場合があります。また、AIの利活用全般にあたっては、総務省・経済産業省が示すAI事業者ガイドラインが、事業者に求められる取り組みの整理として参照されています。自社の運用ルールを文書化する際の下敷きとして目を通しておくと、ベンダーとの議論もしやすくなります。いずれも内容は更新されうるため、最新版を一次情報で確認してください。
ベンダーとの契約で決めておきたいこと
受注開発でAIシステムを導入する場合、次の点を事前に握っておくと、不具合発生時の押し問答を避けられます。
- プロンプトの修正は社内でできるのか、ベンダー作業なのか
- 参照データの更新は誰が行うのか、その頻度と手順
- モデルの提供元がモデルを更新・廃止した場合の対応と費用負担
- 出力ログをどこまで保存するか（原因究明にはログが不可欠です）
特に最後のログは軽視されがちですが、入力と出力が残っていなければ再現も検証もできません。保存期間と、保存してよい情報の範囲は設計段階で決めておくべき項目です。
小さく始めるなら、この最小構成から
従業員数十名規模で専任を置けない場合でも、次の3点だけは決めておくことをおすすめします。
- 報告先を1か所にする：チャットツールに専用チャンネルを作るだけでも構いません。口頭報告は記録に残らないため避けます。
- 切り分け役を1人決める：専門家である必要はありません。「再現するか試す」「層を仕分ける」「判断できなければベンダーに投げる」の3動作ができれば務まります。
- 月1回、報告を見返す時間を取る：同じ種類の誤りが繰り返されているなら、それは個別対応ではなく設計で直すべき問題です。
AIを業務に入れる以上、誤りはゼロにはなりません。前提を「誤らないシステム」から「誤りが速やかに見つかり、正しい担当者に届き、適切な層で直されるシステム」に置き換えることが、運用体制設計の出発点です。
まとめ
AI業務システムの運用でつまずく原因の多くは、技術そのものではなく体制の未整備にあります。本記事の要点を整理します。
- 役割を気づく人・切り分ける人・直す人に分け、現場に原因分析を求めない
- 報告は「入力・出力・期待した結果・発生箇所」の4項目で十分
- 原因はプロンプト層・データ層・モデル層に仕分け、層に応じて担い手と修正方法を変える
- モデル層の限界をプロンプトで埋めようとしない。設計で回避する
- 停止基準とログ保存、修正の責任分界点を契約段階で決めておく
導入を検討している段階であれば、機能要件と同じ温度感で「不具合が起きたときに誰がどう直すか」をベンダーと詰めてください。そこまで含めて設計されたシステムが、結果として長く使われるシステムになります。