RAGは動くのに、なぜ本番のAIエージェントは間違えるのか──DevRevが説く、AIに渡す記憶の設計

【17-C-3】AIエージェントは「チームメイト」になれるか - 開発・サポート・ビジネスをつなぐ新しい働き方

記憶をあらかじめ用意して、LLMは判断だけを担う

　鈴木氏は、ナレッジグラフに教え込むべき情報を「関係性」「時系列」「権限」という3つの鍵に整理する。開発チケット、カスタマーサポート、プロダクトフィードバックといった領域をこの3つの鍵でオントロジーにマッピングすることで、AIはベテラン社員のように振る舞えるようになるという。

　「関係性」では、チケットを起点にグラフを深さ3までたどるクエリを1回実行するだけで、原因のIssue、影響を受ける複数の顧客、止まっている商談の金額、参照すべき手順書のバージョンまでが同時に確定する。「時系列」では、過去のIssueがいつ閉じられ、いつ新しいバージョンがリリースされ、いつからエラーが増えたのかという流れを見せることで、「似ているが別の現象である」とAIが正確に判断できるようになる。

　「権限」では、同じ質問でも回答者が変わる。同じ「チケットの状況を教えて」という問いに対し、営業担当者が聞けば「あなたの担当のお客様が影響を受けます。早めにお客様と密にコミュニケーションを取り、調整と謝罪をしておきましょう」と商談への影響を中心に返し、サポート担当者が聞けば「現在開発はこの段階まで進んでおり、いつ直る予定です」と対応状況を中心に返す。同じAIを個別にチューニングしなくても、権限情報を埋め込んでおくだけで質問者の役割に応じて回答の中身そのものを切り替えられる。権限外のデータはそもそも回答に含まれないため、情報漏洩の防止にもつながる。

ナレッジグラフの「関係性」の鍵──1回のクエリで、原因・影響顧客・商談金額・対応手順が同時に確定する

　これをシステムとして構成すると、思考と判断を担うエージェント層、ナレッジグラフや時系列・権限・クエリルーターを持つコンテキスト層、ガードレールやロールバック、人間の承認を組み込むオーケストレーション層、そしてJiraやGitHub、Zendesk、Salesforce、Confluenceなどと双方向に同期する外部システムという4層構造になる。集計や確定値の取得にはSQL、類似文書の検索にはベクトル検索、IDやチケット番号の完全一致には逆インデックス、関係性の探索にはグラフデータベースというように、用途ごとに最適な技術を使い分ける。LLMにすべてを検索させるのではなく、記憶をあらかじめ用意しておき、LLMは判断だけを担うという構成だ。

　もし最初から記憶を持つエージェントがこの障害に対応していたらどうなるか。チケット作成の瞬間にエージェントが起動し、同一顧客・同一コンポーネントの過去のIssueから「別事象である可能性が高い」と判断する。デプロイ履歴とログの相関から原因を特定し、直前のリリースにセキュリティパッチが含まれているためロールバックできないと判断した上で、その方針の可否だけを人間に確認する。影響を受ける顧客への通知ドラフトも自動生成され、内容の最終確認だけ人間が行う。修正が完了すればチケットは自動でクローズされ、関連システムも横断的に更新される。この一連の流れの中で、人間が行うのは方針への承認2回だけだった。

着弾から原因特定、ロールバック判断、インシデント起動、影響顧客通知、自動クローズまでの6ステップで、人間が行うのは承認2回のみ