記録システムは「何が起きたか」を保存しますが、エージェントが「どう判断したか」は保存しません。

ヘルプデスクで解決済みのチケットを1件開いてみてください。チケット4471：起票、キューへの割り当て、返金処理、クローズ。何が起きたかはすべてのステップがタイムスタンプ付きで記録され、検索もできます。

では、その理由を探してみてください。なぜこの顧客は30日の期限を過ぎても返金を受けられたのか。担当者は判断の前に何を確認したのか。スーパーバイザーが介入して判断を変えたのか。こうした情報は、どれも記録に残っていません。

システム・オブ・レコード本来の役割

CRM、チケット管理プラットフォーム、請求システムは、いずれもシステム・オブ・レコードです。顧客が誰か、何を購入したか、何が未解決で何が完了したか。データを保持するという本来の役割は十分に果たしています。

しかし、判断を記録するようには設計されていません。「クローズ」というステータスは作業が終わったことを示すだけで、どのように作業が行われたかについては何も語りません。そのため、フィードバックや学習のループが生まれないのです。

欠けているのは「意思決定トレース」

意思決定トレースとは、1件の解決がどのように行われたかの記録です。顧客が置かれていた状況、エージェントが参照したコンテキストとその取得元のシステム、実行したアクション、そしてそのアクションがうまくいったかどうかを捉えます。多くの場合、最も価値があるのは最後の部分、つまり事後に人間が何を修正したか（あるいは修正しなかったか）です。

Mavenでは、こうしたトレースの蓄積をGraph of Recordと呼んでいます。Graph of Recordは「どのように判断したか」を保存し、次の判断を前回よりも良いものにする学習ループを実現します。

意思決定トレースが複利的に効く理由

エンタープライズアーキテクトは長年、データグラビティについて語ってきました。アプリケーションはデータのある場所へ引き寄せられる傾向がある、という考え方です。意思決定トレースはそれとは別の引力、いわば「トレースグラビティ」を生み出します。

インテリジェンスは、意思決定が行われる場所に蓄積されます。解決したケースの一つひとつ、そしてうまくいかなかったケースへの修正の一つひとつが、次のケースのより良い出発点になります。

だからこそ、導入初期の数週間が非常に重要なのです。最も速く成果を伸ばすのは、実際のケースと実際の修正がエージェントの動作に直接フィードバックされる導入です。

Mastermindは、こうしてMaven導入からわずか6週間で93%の自律解決を達成しました。

多くのチームは、その下のレイヤーをまだ接続していない

BoxのState of AI in the Enterprise 2026レポートでは、96%の組織が、AIエージェントが自社固有のコンテンツやナレッジにアクセスできることは重要だと回答しています。

ところが、エージェントを利用・試行している組織のうち、多くのユースケースにわたって信頼できる社内コンテンツと接続しているのは36%にすぎません。さらに、エージェントによる社内データへのアクセスについて正式な基準を設けているのは、わずか34%でした。

これがコンテンツレイヤー、つまりエージェントが読み込むドキュメントやナレッジです。意思決定トレースは、その1つ上のレイヤーに位置します。

大半の企業がまだナレッジすら接続できていないのなら、エージェントがそれをどう使っているかを意図的に記録している企業はごくわずかです。それを実践するチームにとっては大きなチャンスであり、自社で管理できない場所にトレースが蓄積され続けているチームにとっては現実的なリスクです。

システム・オブ・レコードはそのまま

CRMやヘルプデスクを置き換える必要はありません。これらのシステムは、得意な役割をこれまでどおり担います。ただし、位置付けは変わります。作業レイヤーが読み取り、書き戻す先の「状態レイヤー」になるのです。

これがオーバーレイ型アーキテクチャの考え方です。ZendeskやSalesforceの上で動作するAIエージェントプラットフォームは、既存のシステムから状態を読み取り、ケースを解決し、結果を書き戻し、そこに至るまでのトレースを保持します。移行作業も、新たなシステム・オブ・レコードの導入も必要ありません。

契約前に確認すべきこと

カスタマーサービス向けAIエージェントを評価しているなら、意思決定トレースを評価項目に加えるべきです。次の質問で、違いはすぐに明らかになります。

• 意思決定トレースはどこに保存されるのか。契約を終了した場合、持ち出せるのか。
• チームがエージェントを修正したとき、その修正が次の類似ケースの対応に反映されることを確認できるか。
• 任意の1件の解決について、それを生んだコンテキストとアクションまでさかのぼって監査できるか。
• 自社のトレースから他に誰が学習できるのか。それは契約書に明記されているか。

トレースを中心に設計されたベンダーであれば、具体的に答えられるはずです。そうでないベンダーは、話をデモに戻そうとするでしょう。

向上し続ける解決

解決率は注目を集めますし、それは当然のことです。しかし2年間の契約期間で見れば、より重要なのは解決率がどれだけ速く向上するかです。それは、自社がどのように判断しているかの記録が残されているかどうか、そして誰がそれを保持しているかにかかっています。

これがService as Softwareの核心です。作業がどのように行われたかの記録を保持しているからこそ、作業を実行し、しかもその精度を高め続けられるソフトウェア。全文をお読みいただくか、最も難しいチケットの種類をデモでお試しください。30分間、お客様のシステムで、お客様が定義する「解決」に基づいて検証します。