AIエージェントの「精度が落ちた」は、モデルのせいとは限らない
AIエージェントを導入した直後は的確に動いていたはずなのに、運用を続けるうちに期待通りに動かない場面が増えてくることがあります。原因を探すとき、多くの場合は「モデルの性能が落ちたのでは」「プロンプトの書き方が悪かったのでは」という方向に目が向きます。しかし実際には、モデル自体は変わっていないことが大半で、変わっているのはエージェントに渡している「定義」の側であるケースが少なくありません。
定義ファイルとは何か
AIエージェントは、役割・参照先・判断基準を記した定義ファイル（プロンプトやコンフィグ）をもとに動作します。定義ファイルは一度書いたら固定されるものではなく、事業の状況や周辺の仕組みが変わるたびに更新が必要になる、いわば「生きたドキュメント」です。
運用開始後に起きていること
運用を続けるほど、定義ファイルの数は増え、互いの参照関係も複雑になっていきます。新しい業務が発生するたびに新しい定義を足し、既存の定義を書き換える。この積み重ねの中で、少しずつ定義同士の整合が崩れていきます。これが、体感としての「精度低下」の実体であることが多いです。
定義ファイルが劣化する4つの型
劣化は一様ではなく、いくつかの型に分類できます。それぞれ発生条件・起きる症状・気づき方が異なるため、型を知っておくことが点検設計の出発点になります。
型1：参照先ファイルの参照切れ
定義ファイルの中で他のファイル（別の定義・ナレッジ・データソース）を参照している箇所が、参照先のファイル名変更・移動・削除によって切れてしまう型です。
エージェントは参照エラーを出しません。参照先が存在するという前提のまま、参照できていた頃の文脈や一般論で穴を埋めて回答します。表面上は自然な回答が返ってくるため、参照が切れていること自体に気づきにくいという特徴があります。
型2：定義同士の内部矛盾
複数のエージェント定義が、同じルール・数値・方針について記述を持っている場合、片方だけを更新するともう片方は古い記述のまま残ります。
同じ質問を異なるエージェントに投げたときに、答えが微妙に食い違うという形で表面化します。1つのエージェントだけを見ていると矛盾には気づけず、複数のエージェントの出力を横並びで比較して初めて発覚することが多い型です。
型3：役割の重複と境界の曖昧化
似た目的のエージェントを増やしていくと、どちらが何を担当するかの境界が運用の中で少しずつにじんでいきます。
同じ依頼に対して毎回どちらのエージェントを使うか判断が割れる、あるいは両方が中途半端に対応して抜け漏れが生じるといった形で表面化します。最初から境界が曖昧だったわけではなく、後から追加した定義が既存の役割と重なっていくことで発生します。
型4：前提としていた外部仕様・自社状況の陳腐化
定義ファイルの中には、外部サービスの仕様・自社の商品ラインナップ・連携している事業の状態など、時間とともに変わる前提が書き込まれています。前提となる状況が変わっても、定義ファイルの記述はそのまま残ります。
エージェントは古い前提を正しい情報として扱い続けるため、実態と食い違う案内をしても、エージェント自身はそれを異常として検知しません。例えば、提供を終了したサービスを、定義ファイルの記述だけを根拠に案内し続けるといった形で表面化します。
なぜ気づけないのか — 劣化は「失敗」ではなく「緩やかな低下」として現れる
4つの型に共通するのは、エラーとして表面化しないという性質です。プログラムのバグであれば、動かなくなる・エラーメッセージが出るという形で発見のきっかけが生まれます。しかし定義ファイルの劣化は、エージェントが古い定義のまま堂々と動き続けることで発生します。回答は一見自然で、文章として破綻していません。
だからこそ、品質は落ちているのに、それに気づくきっかけが運用の中に用意されていなければ、誰も気づかないまま進んでいきます。
「使われているうちは大丈夫」という誤解
定義ファイルは、頻繁に呼び出されているからといって正しく更新され続けているとは限りません。むしろ日常的に使われているエージェントほど、少しずつ古くなった前提を大量の回答に反映し続けてしまうリスクがあります。
人の記憶に依存した点検の限界
「気になったときに見直す」という運用は、気になるきっかけが発生しなければ機能しません。エージェントの数が増えるほど、どの定義がいつ更新されたか、どの定義同士が関連しているかを人が記憶し続けることは現実的ではなくなります。だからこそ、点検を定期的に・機械的に実行する仕組みが必要になります。
AIエージェント運用のメンテナンス設計 — 定期点検を仕組みにする
定義ファイルの劣化を前提にすると、AIエージェント運用のメンテナンスで必要なのは「気づいたら直す」ではなく「気づく仕組みを先に作る」ことです。relmeaでは、複数のAIエージェント定義を横断的に点検する工程を運用フローに組み込んでいます。
横断スキャンで検出する
点検の第一段階は、定義ファイル群を横断的にスキャンし、劣化の兆候を機械的に検出する工程です。人が1つずつ目視で見直す方式では、定義の数が増えるほど点検自体が破綻します。スキャンで確認する主な観点は次の通りです。
- 参照先ファイルが実在するか
- 同じ論点について複数の定義が異なる記述を持っていないか
- 役割の説明が他の定義と重複していないか
- 定義内の前提（外部仕様・自社の状況）が最終更新から時間が経ちすぎていないか
検出 → 承認 → 一括修正という流れにする
検出しただけでは点検は完了しません。検出結果をそのまま自動修正すると、意図しない変更が本番の運用に影響します。relmeaでは、検出結果を一覧化し、修正の要否を人が判断してから、承認された範囲だけを一括で反映する流れにしています。この「検出」と「修正の実行」を分けることが、機械点検を安全に運用の仕組みへ組み込むポイントです。
修正の順序 — 他の定義を壊さないために
複数の定義に修正を加える場合、順序を誤ると新たな矛盾を生みます。他の定義から参照される基盤的な定義を先に直し、それを参照するだけの個別定義を後から直すという順序にすることで、修正の途中で一時的な矛盾が発生する範囲を最小化できます。
点検の頻度と粒度
点検は一律の頻度で行う必要はありません。
- 全定義を対象にした横断スキャンは、低頻度でも成立する
- 直近で変更が入った定義・利用頻度の高い定義は、変更のたびに重点的に点検する
- 外部仕様に依存する定義（連携先の仕様・料金体系など）は、外部側の変更が起きやすい時期に合わせて点検頻度を上げる
粒度についても、全件を毎回同じ深さで見るのではなく、参照切れの検出のような機械的にできる軽い点検は高頻度で回し、内容の矛盾や前提の陳腐化のような判断を要する点検は低頻度でまとめて行うという二段構えが、運用上は現実的です。
エージェントを増やす前に、統合を考える
定義ファイルの劣化は、定義の数が増えるほど発生源も増えます。新しい業務が発生するたびに新しいエージェントを作ると、点検すべき対象と、矛盾が起きうる組み合わせの両方が増えていきます。
役割重複は劣化の総量を増やす
似た役割を持つエージェントが複数存在すると、片方を更新したときにもう片方が取り残されるリスクが常に発生します。エージェントを1体増やすたびに、既存の定義との間に新しい参照関係・重複の可能性が生まれるため、劣化が起きうる箇所は単純な足し算では済まず、既存の定義との組み合わせの分だけ増えていきます。
統合を検討する判断基準
新しい業務が発生したときに、新しいエージェントを作る前に確認する価値がある観点は次の通りです。
- 既存のエージェントの役割定義に、新しい業務を吸収できる余地はないか
- 同じ種類の質問・依頼に対して、複数のエージェントが反応する状態になっていないか
- 似た出力を複数の定義がそれぞれ個別に管理していないか
- 役割の境界を、毎回そのつど人が判断して振り分けている状態になっていないか
これらに当てはまる場合、新しいエージェントを追加するのではなく、既存の定義を拡張・統合するほうが、点検対象を増やさずに済みます。
まとめ — 定義ファイルは「書いたら終わり」ではない
AIエージェントの精度低下は、モデルの性能そのものよりも、運用の中で定義ファイルが少しずつずれていくことが原因になっているケースが少なくありません。参照切れ・内部矛盾・役割の重複・前提の陳腐化という4つの型を知っておくこと。そして劣化はエラーとしてではなく緩やかな品質低下として現れることを前提に、気づく仕組みを先に用意しておくこと。この2点が、AIエージェント運用のメンテナンス設計の土台になります。
relmeaでは、91体のAIエージェントとオーケストレーターコマンド41本を、この点検の仕組みとともに運用しています。エージェントを「作って終わり」にせず、定義ファイルを継続的に健全な状態に保つための運用設計は、Brain Vol.1（運用編）で扱っている領域です。AIチームの構築・運用そのものを任せたい場合は、Relmea AI Ops（AIチーム構築代行）でも対応しています。