AI Agentの精度が悪い。そこで「もっと強いモデルに替えましょう」と答えるのは、もっともらしく聞こえます。
しかし実務では、その提案だけでは足りません。モデルを強くしても、古い文書を渡せば古い答えを返します。顧客IDの正規化ができていなければ、正しいAPIを呼べません。業務ルールを検索結果の文章に埋め込めば、条件分岐が曖昧になります。
モデル変更は選択肢の一つです。ただし、品質改善の出発点ではありません。Agentの精度は、モデル単体の能力ではなく、入力データ、決定的なルール、外部システム、検索設計、評価を重ねたシステム全体の性質です。
結論：精度を上げる作業は「回答を賢くする」より「間違える余地を減らす」作業
Agentの品質は、次のように分解して考えると改善しやすくなります。
| 層 | 担当すること | 欠けたときの典型的な失敗 |
|---|---|---|
| 入力データ | 正規化、重複除去、更新日・権限・出所の付与 | 正しい質問でも古い・矛盾した情報を返す |
| ルール | 金額上限、承認条件、必須確認、禁止操作 | 本来は一意に決まる判断をモデルが推測する |
| 既存API | 在庫、契約、顧客、予約などの一次情報を取得・更新 | 文書から「推測」して最新状態を答える |
| 検索・RAG | 関連文書や根拠を絞る | 文脈不足、ノイズ混入、出典不明の回答になる |
| モデル | 意図理解、計画、説明、曖昧な情報の統合 | 与えられた材料を十分に使えない |
| 評価・監視 | 期待動作を測定し、失敗原因を特定する | 改善したつもりで別の品質を落とす |
この表で重要なのは、モデルを最後に置いたことではありません。モデルに任せるべき曖昧さだけを残し、それ以外をシステムとして確定させることです。
「返金できるか」「在庫があるか」「誰が閲覧できるか」は、言語モデルの表現力を試す問題ではありません。既存の業務ルールや一次システムに答えを持たせるべき問題です。一方、「この問い合わせはどの手続きに近いか」「複数の根拠をどう説明するか」は、モデルが強みを発揮しやすい領域です。
まず「精度が悪い」を5種類に分ける
品質改善が迷走する最大の理由は、精度という言葉が広すぎることです。最初に、失敗を分類します。
| 症状 | 主な原因候補 | 最初に疑う場所 |
|---|---|---|
| 事実が古い・足りない | データ更新、検索対象、チャンク設計 | データパイプラインと検索ログ |
| 回答は自然だが業務上誤り | ルール未実装、API未接続 | 決定表、業務API、権限設計 |
| 正しい根拠を見つけても結論を誤る | 指示、モデル推論、コンテキスト過多 | プロンプト、根拠の絞り込み、モデル |
| 同じ質問で結果がぶれる | 出力制約不足、検索の揺れ、評価不足 | スキーマ、検索条件、テストケース |
| 失敗の原因が分からない | ログと評価指標がない | トレース、評価データ、失敗ラベル |
ここで初めてモデル比較の意味が出ます。検索根拠、業務ルール、入力条件を同じに揃えたうえで、モデルを替えて結果が改善するなら、それはモデルがボトルネックです。逆に条件を揃えずにモデルだけを替えても、何が効いたのか分かりません。
1. 前処理は地味だが、Agentの回答品質を最も安定させる
RAGやファイル検索に渡す文書は、人間が読むための原稿のままでは使いにくいことが多いです。
改訂前後の規約が混在し、見出しがなく、表だけがPDF内に残り、部署ごとに顧客名の書き方が違う。これでは検索が正しくても、答えの土台が揺れます。
前処理では、少なくとも次を揃えます。
- 文書ごとの公開日、失効日、版番号、所有部署、閲覧権限
- 重複・旧版・ドラフトを検索対象から外す判断
- 見出し、表、箇条書き、FAQを意味の切れ目で分割するチャンク設計
- 顧客ID、製品SKU、部署名、日付、単位の正規化
- 回答に添えるべき出典URLや文書ID
ここでの狙いは、モデルに長い文章を「理解させる」ことではありません。必要な一次情報だけを、同じ形で取り出せる状態にすることです。
たとえば価格改定の質問なら、古い価格表を検索候補に残すより、「現在有効な価格表」というデータ条件で先に絞る方が強いです。この問題を高性能モデルに任せても、複数の版を見分ける根拠が入力になければ、正確さは保証できません。
一意に決まる判断は、ルールベースへ逃がす
モデルは曖昧な言葉を扱うのが得意です。一方、数値境界、権限、法令、手数料、承認条件のように、一意に決まる判断を自然言語の推論へ預ける理由はありません。
たとえば「返金額が3万円を超えるなら管理者承認が必要」というルールは、プロンプトに書くのではなく、アプリケーションコードまたはルールエンジンで判定します。モデルには、必要な項目を抽出し、結果を顧客へ説明させれば十分です。
// 何を: 返金可否を決定的な業務ルールとしてアプリ側で判定する。
// なぜ: 金額しきい値や承認要否をモデルの解釈に委ねないため。
function buildRefundDecision(amountYen: number, isWithinPolicy: boolean) {
if (!isWithinPolicy) return { status: "rejected", reason: "返金対象外です" };
if (amountYen > 30_000) return { status: "needs_approval", reason: "管理者承認が必要です" };
return { status: "approved", reason: "返金手続きを開始できます" };
}この戻り値をAgentへ渡せば、モデルは相手の状況に合わせて説明できます。反対に、モデルに金額と規約を読ませて可否まで決めさせると、同じ入力に対する再現性、変更時の保守性、監査可能性を同時に失います。
既存APIを「最新事実の正解」として使う
社内文書は説明に向いていますが、最新状態の照会に向かないことがあります。在庫、契約状態、配送状況、予約枠、利用権限のような情報は、原則としてそのシステムのAPIやデータベースから取得します。
Agentが担うべきなのは、ユーザーの曖昧な依頼をAPIが受け取れる形へ変換し、取得結果を分かりやすく説明することです。APIの戻り値そのものを、もう一度モデルに事実判定させないようにします。
OpenAIのツール機能では、関数呼び出しによってアプリケーション独自のコードを呼び出せます。ただし、モデルが返す関数呼び出しは実行提案であって、認可済みの操作ではありません。引数検証、ログイン利用者との照合、業務ルール、エラー処理はツール実行層で行います。
この設計にすると、品質を「モデルの正答率」ではなく、「正しいAPIに到達できた率」「API結果を改変せず説明できた率」として測れます。改善の打ち手も具体的になります。
RAGは検索器であり、知識の品質保証装置ではない
RAGは、モデルが回答前に関連文書を取り込む構成です。とても有効ですが、ベクトル検索を入れた瞬間に知識が正しくなるわけではありません。
特に失敗しやすいのは、次の3つです。
- 正解文書と旧版文書が同時に検索される
- 質問に近い単語はあるが、結論を支える条件が欠ける
- 表・注記・例外規定が別チャンクになり、関係が切れる
そのため、RAGでは検索精度と回答精度を分けて評価します。まず「必要な根拠が上位候補に入ったか」を測り、次に「その根拠だけで正しい答えを作れたか」を測る。この順番を飛ばすと、プロンプト調整で検索失敗を隠すだけになりがちです。
OpenAIのファイル検索は、アップロードしたファイルの内容を応答へ取り込む選択肢の一つです。採用する場合も、どの文書を登録し、更新・削除を誰が担い、検索結果をどこまで画面へ見せるかはアプリ側の設計です。
Graph RAGは「関係性」が答えの中心にあるときに検討する
通常のRAGは、質問に似た文書断片を探すのが得意です。しかし、答えが複数のエンティティと関係をまたぐときは、断片検索だけでは見落としが起きます。
たとえば次のような問いです。
- この顧客に影響する障害は、どの契約・製品・担当チームと関係しているか
- この部品変更は、どの製品バージョンと既知の不具合に波及するか
- この規制変更は、どの国・法人・契約条項へ影響するか
こうしたケースでは、顧客、製品、契約、障害、担当者のような実体と、その間の関係をグラフとして持つ価値があります。Graph RAGは、ベクトルの近さだけでなく、関係をたどって根拠候補を集める構成です。
ただし、Graph RAGは万能な上位互換ではありません。エンティティの名寄せが不十分、関係の定義が揺れている、更新責任者がいない状態でグラフを作ると、検索対象が複雑になるだけです。まずは文書メタデータ、ID正規化、既存API、通常RAGの検索評価を整えます。その後に「関係を2〜3ホップたどらないと答えられない質問」が評価データで繰り返し現れるなら、Graph RAGを比較検証する価値があります。
知識グラフそのものの設計・構築を基礎から押さえる資料として、Jesús Barrasa、Jim Webber著「はじめての知識グラフ構築ガイド」は、この記事でいう「関係をデータとして管理する」発想を深める参考になります。Graph RAGの製品選定ガイドではなく、グラフを導入する前のデータモデリングを考えるための一冊として読むのがよさそうです。
ポチップ
評価がない改善は、再現できない
「前より良くなった」は、Agent開発では危険な言葉です。ある質問への回答が改善しても、別の質問で根拠を取り違えたり、規則を破ったりしているかもしれません。
OpenAIの評価ガイドでは、期待する振る舞いを評価として記述し、テスト入力で実行して結果を分析・改善する反復を基本にしています。モデルやプロンプトを変更するときほど、同じ評価セットで前後比較することが重要です。
Agentの評価セットには、成功例だけでなく失敗させたい例を入れます。
| 評価するもの | 例 |
|---|---|
| データ取得 | 最新版の規約だけを根拠として選べるか |
| ルール遵守 | 金額条件を超える返金を承認待ちにできるか |
| API連携 | 同姓同名を曖昧に処理せず、追加確認できるか |
| 検索 | 例外規定を含むチャンクを取得できるか |
| 説明 | 根拠・不確実性・次の手順を過度に断定せず示せるか |
| 安全性 | 指示の上書きや権限外の依頼を拒否できるか |
さらに、失敗には原因ラベルを付けます。データ欠損、検索漏れ、ルール未実装、API失敗、モデル推論のように分類すれば、改善策をモデル変更だけに収束させずに済みます。
実装の順序：高価な技術から始めない
品質問題を見つけたときの優先順位は、私は次の順序が実務的だと思います。
1. 評価ケースを作り、何が失敗しているかを可視化する。
2. 最新性・権限・ID・版管理を前処理で揃える。
3. 一意に決まる判断をルールと既存APIへ移す。
4. 通常RAGで根拠取得を評価し、チャンク・メタデータ・検索条件を調整する。
5. 関係性をたどる質問が残ると確認できた場合だけ、Graph RAGを比較する。
6. ここまで同じ条件を揃えても推論・要約・計画が弱い部分で、モデル変更を比較する。
この順序なら、上位モデルの利用費をかける前に、より安定して改善できる層を潰せます。モデル選定を軽視するのではありません。モデルが本当にボトルネックであることを、評価によって確認してから投資するという考え方です。
最初の一手：失敗を30件集めて、原因を付ける
今すぐ始めるなら、新しいフレームワークを入れる必要はありません。最近の会話ログやテストから、失敗・ヒヤリハット・人が補正した回答を30件集めます。そして、各件に次のどれが原因かを付けます。
- データがない、古い、正規化されていない
- ルールをコード化していない
- 一次情報を持つAPIを呼んでいない
- 検索が根拠を取れていない
- 関係性の探索が必要
- モデルの解釈・推論・表現が足りない
この分類ができれば、次の投資は自然に決まります。品質を上げるとは、より賢いモデルを選ぶことだけではありません。正しいデータを、正しい経路で、正しい制約の下に渡し、その結果を測り続けることです。
それができて初めて、モデル変更が「なんとなくの期待」ではなく、効果を測れる技術判断になります。
コメント