あなたのAI、「勝手に終わって」いないか？

AIで業務を自動化した。コストが下がった。人手が減った。——ここまではいい話だ。

問題は、その自動化が 「動いているように見えて、中身が壊れている」 ケースが想像以上に多いということ。エラーが出るならまだマシで、最もタチが悪いのは エラーも出さずに間違った結果を返し続ける パターンだ。

最新の研究論文を3本読み込んだ結果、AIの自動化が静かに壊れるメカニズムは大きく3つに整理できた。RAG（検索拡張生成）の構成崩壊、エージェント記憶の腐敗、ツール実行のサイレントフェイル。どれも「動いているつもり」の裏で確実に品質を蝕む。

中小企業にとって、これは他人事ではない。大企業なら専任のMLOpsチームが監視できるが、3〜5人のチームでAIを回している会社に、そんな余裕はない。だからこそ 「何を見れば壊れていると分かるのか」 を知っておく必要がある。

—

壊れ方①：RAGの構成が知らないうちにズレる

RAGシステムとは、社内文書やFAQなどの情報を検索し、その結果をもとにLLM（大規模言語モデル）が回答を生成する仕組みだ。社内チャットボットや問い合わせ対応の自動化で導入する中小企業が増えている。

ある研究では、実世界のRAGシステムから 654件の構成問題 が収集・分析された。ここで浮かび上がった最大の発見は、問題が発生する段階と、症状が表面化する段階がズレる ということだ。

具体的にどういうことか。たとえば、検索（Retrieval）の段階でチャンクサイズの設定がおかしくなっていても、症状としては生成（Generation）の段階で「回答がおかしい」という形で出る。原因を探すとき、生成部分ばかり調整しても直らない。根っこは検索設定にあるからだ。

さらに厄介なのは、問題の多くが 初期設定段階と最終出力段階に集中している 点。つまり「最初のセットアップ」と「最後のアウトプット」が壊れやすい。途中のパイプラインは正常に見えるから、気づきにくい。

中小企業が今週やること

300万円かけてRAGを構築しても、構成がズレれば5万円の価値もない回答を返し続ける。逆に言えば、週1回15分のチェックでこれは防げる。

• 検索結果の抜き打ち確認：チャットボットに既知の質問を5つ投げて、引用されたソース文書が正しいか目視で確認する。ソースがズレていたら検索設定を疑え。
• チャンクサイズとオーバーラップの記録：設定値を変更したら必ず日付とともに記録する。「誰がいつ変えたか分からない」が最大のリスク。
• 回答精度のスコアリング：週に10件の回答を「正しい／部分的に正しい／間違い」の3段階で記録する。数字にしないと劣化に気づけない。

—

壊れ方②：エージェントの記憶が「腐る」

長期記憶を持つAIエージェントが増えている。過去のやり取りや蓄積した知識をもとに、より文脈に沿った回答をする——はずだった。

研究で指摘されたのは 「メモリーエコー」 という現象だ。これは、同じ情報源から取り出された過去の情報が繰り返し参照され、あたかも複数の独立した根拠があるかのように扱われてしまう問題を指す。

たとえるなら、1人の人間の発言を10回聞いて「10人が同じことを言っている」と判断してしまう状態だ。結果として、すでに古くなった情報や、一度しか確認されていない事実が、高い確信度で回答に組み込まれる。

この問題に対して提案されているのが 「FPA（Family–Provenance–Authority）」フレームワーク だ。情報の「出自（どこから来たか）」と「権威性（どれだけ信頼できるか）」を追跡し、同一ソースからの重複参照を排除する。研究ではFPAの適用により、回答精度が有意に改善したと報告されている。

中小企業が今週やること

専用フレームワークの導入はハードルが高いが、原理を理解すれば手動でもチェックできる。

• 回答の根拠を逆引きする：エージェントが返した回答に対して「その情報のソースは何か」を確認する。3つの根拠が実は同じ文書から来ていないかチェック。
• 古い情報の棚卸し：知識ベースに入っている文書の最終更新日を確認する。半年以上更新されていない文書にフラグを立てる。
• 「この情報はいつ時点のものか」をプロンプトに入れる：エージェントへの指示に「回答に使う情報の時点を明記せよ」と加えるだけで、古い情報の混入に気づきやすくなる。

—

壊れ方③：ツール呼び出しが「成功したフリ」をする

AIエージェントが外部ツールやAPIを呼び出して作業する——これも自動化の定番パターンだ。在庫確認、データ取得、メール送信。ツールが正しく動けば、人間がやるより圧倒的に速い。

問題は、ツール呼び出しが「成功」のステータスを返しているのに、中身が欠落している ケースだ。研究では15の科学ツールを対象に実験が行われ、91件のサイレントフェイル が確認された。

最も多かったのは データフィールドの欠落 と 検索・フィルタリング条件の不整合 だ。APIは200（成功）を返しているのに、返ってきたデータの一部が空、あるいはフィルタ条件が無視されている。エージェントは「成功した」と判断して次のステップに進むから、最終的なアウトプットが静かに狂う。

これは中小企業にとって特に危険だ。大企業ならデータエンジニアが異常値を検知する仕組みを持っているが、中小企業では「APIが200を返したからOK」で終わりがちだ。

中小企業が今週やること

• 出力の「空欄チェック」を自動化する：ツールの戻り値にnullや空文字が含まれていたらアラートを出す。たった数行のスクリプトで実装できる。
• 期待値との突合：「この検索条件なら最低でも3件は返るはず」という期待値を設定し、0件や1件だった場合に通知する仕組みを入れる。
• APIの変更履歴を追う：外部ツールのAPIは予告なく仕様変更されることがある。月1回、ドキュメントの更新日を確認するだけでも事故は減る。

—

結局、何が起きているのか

3つの壊れ方に共通するのは、「正常に見える異常」 だということ。エラーログに何も出ない。ダッシュボードは緑色。でも、出てくる答えは静かに間違っている。

中小企業がAI自動化で本当にコストを下げたいなら、「導入コスト」だけでなく「監視コスト」を計算に入れる 必要がある。月額5万円のAIツールでも、壊れた状態で3ヶ月動き続ければ、間違った回答による顧客対応ミス、誤発注、機会損失で数十万〜数百万の損害になり得る。

逆に言えば、週1回15分のチェックリストを回すだけで、この「静かな崩壊」はかなり防げる。専任のMLOpsチームなんていらない。必要なのは 「AIは壊れるものだ」という前提 と、壊れたことに気づく仕組み だ。

大企業は専門チームで監視する。中小企業は「チェックリスト」で監視する。やり方が違うだけで、やるべきことは同じだ。

まずは今週、自社のAIに「既知の質問」を5つ投げてみてほしい。答えが正しいかどうか、15分で確認できる。それが、あなたの会社のAIが「勝手に終わっていない」ことを確認する最初の一歩だ。

—