ネクストベストアクション：カテゴリー名は、決して取らないアクションを名乗っている

あるお客様からこう連絡が届きます。「二重に請求されたのに、まだ返金されていません」。あなたのサポートAIエージェントはこのチケットを読み、内容を完璧に理解し、数秒で返金を推奨します。速く、自信に満ち、そして――おそらく――間違っています。

なぜなら、返金はすでに処理待ちかもしれないからです。不正調査が進行中かもしれません。お客様は返金不可のプランに加入しているかもしれません。既知の請求バグが二重請求の原因を説明できるかもしれません。チケットだけでは、そのいずれも分かりません。だからこそ、推奨されたネクストベストアクションは画面上では正しく見えても、それを実際に取っても安全かどうかを決める事実を見落としているのです。

そのギャップ――正しく聞こえる推奨と、システムが安全に完了できるアクションとの間の隔たり――こそ、よりスマートな提案以上のものが必要になる場所です。それには、つながったコンテキスト、実際の権限、そして作業をやり遂げて記録する能力が必要です。

推奨の品質がなぜつながったコンテキストに依存するのか、統制された実行がどのように評価を変えるのか、そしてサービスリーダーがエージェントアシストプラットフォームに何を求めるべきかを学びましょう。

TLDR: ネクストベストアクションが本当に約束するものとは？

• ネクストベストアクションは、サービスチームが正しいステップを選び、完了できるよう支援することを約束します。それはエージェントに別のタスクを生み出すのではなく、作業を締めくくるべきものです。その判断の品質は、お客様、ポリシー、チケット、製品、システムに関するライブのコンテキストと、それに基づいて行動する権限に依存します。
• Computer, by DevRevは、Native Shared Memory――お客様、製品、システムのデータに関するライブで権限を意識したビュー――の上に構築されたAI解決プラットフォームです。だからこそ、つながったビジネスコンテキストを横断して推論し、統制されたアクションを取ることができます。
• 実践的なテストはシンプルです。システムは作業を前に進めたのか、それとも作業を増やしたのか？

なぜ推奨は、あらゆるツールが見せる部分なのか？

推奨は、ネクストベストアクションの中でもデモ映えする部分です。エージェントがチケットを開くと、ソフトウェアがナレッジ記事、返信、マクロ、エスカレーション、アカウント変更などを提案します。その結果は速く、知的に見えます。20分のデモにもきれいに収まります。それが、ほとんどのネクストベストアクションソフトウェアの背後にある約束です。

このアプローチには本物の価値があります。エージェントは、すべての答えを求めて5つのシステムを検索する必要などあってはなりません。AIエージェントは、判断にかかる時間を短縮し、関連するガイダンスを提示し、経験の浅いエージェントが確立されたプロセスに従えるよう支援できます。

しかし、提案は依然として人によるフォロースルーに依存します。エージェントはそれが該当するかどうかを判断し、関連するシステムを確認し、アクションを実行し、レコードを更新しなければなりません。多くの導入が、せっかく得た効率をそこで失ってしまうのです。

サービスリーダーは、2つの結果を区別すべきです。

エージェントアシストは、人がより良い判断を下すのを支援できます。同じワークフローが、承認された判断を、実際に作業が行われるシステムへと運べるようになると、その価値ははるかに大きくなります。

目的は推奨を否定することではありません。推奨は多くの場合、正しい出発点です。問題は、出発点をゴールラインと呼んでしまうことにあります。

重要ポイント: 良い推奨は判断を向上させることができます。本物のアクションは、それに加えて手作業を減らし、運用のループを閉じます。

カスタマーサービスに「提案ギャップ」があるのはなぜか？

提案ギャップとは、ネクストベストアクションが約束するものと、実際に提供するものとの間の隔たりです。それは、Co-pilotが自信を持って聞こえるだけの情報を持ちながら、安全に行動するのに十分なコンテキストを持たないときに現れます。チケットを正しく読み取りながらも、推奨されたステップが許可されるかどうかを決める条件を見落とすのです。

次のチケットを考えてみてください。

「二重に請求されたのに、まだ返金されていません」

Co-pilotは返金マクロを推奨するかもしれません。その提案は妥当に見えます。しかし、正しい次のステップはまったく異なる可能性があります。

• 返金がすでに処理中かもしれません。
• 不正調査が取引をブロックしているかもしれません。
• お客様が返金不可のプランに加入しているかもしれません。
• 既知の請求バグにより、製品側へのエスカレーションが必要かもしれません。
• その二重請求が別のアカウントのものかもしれません。
• 決済プロバイダーが元の返金を拒否したかもしれません。

チケットの文面だけでは、これらの疑問を解決できません。提案は妥当に見えました。ただ、それが真実に基づいていなかっただけなのです。

これはサポートAIによくあるパターンです。システムは表面的な意図を正しく特定しながらも、その意図を取り巻く条件を見落とします。お客様が何を言ったかは理解しますが、組織がすでに何を知っているかは理解していないのです。

実務者も同じ点を指摘しています。ネクストベストアクションのガイダンスに関するあるコミュニティの議論では、AIの提案は、その基盤となるワークフローとデータが整って初めて役立つと、サポートチームが論じています。

提案されたアクションがデータや金銭を変更する場合、問題はさらに深刻になります。一般的な回答は次のメッセージで訂正できます。しかし、誤った返金、解約、権限変更、アカウント更新は、リカバリのためのプロセスを必要とするかもしれません。

返金を実行すべきでないとき、何が起きるのか？

エージェントは提案されたマクロを信頼し、2回目の返金を実行し、照合上の問題を生み出すかもしれません。お客様は混乱する体験をし、財務部門は調査を強いられ、エージェントは自分が引き起こしたわけでもない誤りを説明する羽目になります。

これは常にモデルの知能の問題というわけではありません。たいていはコンテキストの問題です。システムは請求クレームの言い回しを認識しながらも、安全な対応を決める関係性と状態を見落とすことがあるのです。

同じ問題は請求以外でも現れます。

• アカウント変更が契約上の例外規定に違反するかもしれません。
• すでに出荷が予定されているため、交換が不要かもしれません。
• エスカレーションが、すでに担当者のついているエンジニアリングの課題と重複するかもしれません。
• 解約が、別のチームが対応中のリテンションワークフローを発動させるかもしれません。
• トラブルシューティングのステップが、進行中のインシデント中には安全でないかもしれません。

その推奨は、狭い視野では論理的かもしれません。運用上の全体コンテキストを考慮すると、それは誤りになります。だからこそ、ネクストベストアクションは、最新のメッセージだけでなく、状況全体に依存するのです。

重要ポイント: 自信のある提案でも、最新のコンテキストを欠いていれば安全でないことがあります。サポートAIは、次に何をすべきかを推奨する前に、これまで何が起きたのかを理解しなければなりません。

「正しいステップ」は「次のステップ」とどう違うのか？

正しいステップとは、お客様の実際の状況、ビジネスルール、権限、望ましい結果に合致した次のステップです。それには推奨エンジン以上のものが必要です。作業に関するつながった運用ビューが必要なのです。システムは次のことを理解できるべきです。

• お客様が誰で、何を経験してきたか。
• どの製品、プラン、注文、サービスが関係しているか。
• その状況にどのポリシーが適用されるか。
• これまでにどのアクションが試みられたか。
• どのシステムが現在の状態を保持しているか。
• ユーザーと組織が何を変更することを許可されているか。
• 提案されたアクションがレビュー可能か、または取り消し可能か。

Shared Memoryのないネクストベストアクションは、ネクストベストな当て推量にすぎません。

ここで評価基準が変わります。買い手は、推奨の関連性だけでツールを評価すべきではありません。コンテキストの網羅性、判断の透明性、アクションの統制、システムの更新、リカバリの選択肢もあわせて評価すべきです。

優れたプラットフォームは、10の問いに答えられるべきです。

1. システムはこのケースについて何を知っているか？
2. システムは正しいアクションを特定したか？
3. そのアクションの背後にあるコンテキストを示したか？
4. エージェントの権限を尊重したか？
5. 適切なタイミングで承認を求めたか？
6. システム・オブ・レコードを更新したか？
7. アクションが実行された後、何が変わるのか？
8. そのアクションは監査可能か？
9. それは取り消し可能か？
10. お客様の問題は、解決に近づいたか？

これらの問いは、判断の品質を可視化します。また、その製品がアシスタントなのか、Co-pilotなのか、それともアクションを実行できるエージェントなのかを明らかにします。実践的な違いはシンプルです。推奨が表示された後、システムはワークフローを継続するのか、それともエージェントが引き継がなければならないのか、ということです。

エージェントは、正しい次のアクションをどのように知るのか？

エージェントには、お客様のレコード、チケット履歴、ポリシー、製品データ、取引の状態、関連する作業からの、最新で権限を意識したコンテキストが必要です。さらに、どのアクションが許可されるか、いつ承認が必要か、結果をどのように記録すべきかを説明する明確なビジネスロジックも必要です。

だからこそ、判断の背後にあるエンタープライズAIメモリが重要になります。共有されたコンテキストは、システムがすべてのチケットを孤立したプロンプトとして扱うのではなく、システム横断の関係性を理解するのに役立ちます。

システムは、チケットをアカウント、決済、権限、製品インシデント、エンジニアリングの課題、社内承認、過去の例外などに結びつける必要があるかもしれません。そうした関係性が、正しいアクションを決めることがしばしばあるのです。

目的は、エージェントをより確信ありげに聞こえさせることではありません。目的は、判断をより説明可能（弁明可能）にすることです。

重要ポイント: ネクストベストアクションは、その背後にあるコンテキストの分だけしか信頼できません。つながったデータと明示的なルールが、もっともらしい提案を、説明可能な判断へと変えるのです。

Enterprise-Benchはアクションの品質について何を示しているのか？

Enterprise-Benchは、Laude Instituteとともに開発され、UC Berkeley教授でありDevRevの取締役でもあるAlexandros Dimakisによって検証された、エンタープライズAIのベンチマークです。42の顧客アカウント、40の製品パーツ、そして相互接続された5つのエンタープライズシステムを備えた、現実的なB2B企業をモデル化しています――これは、本番のAIが実際に稼働する、広大でサイロ化されたデータ環境そのものです。

同一のL1〜L2タスクでの結果:

• 精度: ComputerはClaude Codeの63.6%に対し94.3%に達しました――48%の差です。
• 同じモデル、異なるアーキテクチャ: 両システムは同じOpus 4.8モデルファミリー上で動作しました。

この精度の差は、それぞれのシステムがエンタープライズデータにどのように到達し、整理したかに由来するものであり、その下にあるLLMによるものではありませんでした。

これがネクストベストアクションAIにとって意味すること: アクションが安全かどうかを決める事実にシステムが到達できなければ、より高性能なモデルであっても誤った結果を生み出しうるということです。Enterprise-Benchは、すべての推奨が自律的になるべきだと主張しているわけではありません。判断の品質は現実的なエンタープライズコンテキストのもとで評価されなければならないと主張しているのです。なぜなら、検索（リトリーバル）アーキテクチャは、基盤モデルの選択よりも、本番でのパフォーマンスを強く予測するからです。

有用なテストは、2つのプロンプトを比較することです。

• プロンプト1: 「お客様が二重に請求されたと言っています。何と言えばいいですか？」
• プロンプト2: 「お客様が二重に請求されたと言っています。決済の状態、過去の返金、プランのポリシー、不正のステータス、関連するインシデントを確認してください。どのアクションが許可されており、何を書き戻すべきですか？」

2つ目のプロンプトは、実際のサービス上の判断を反映しています。これは、応答と解決を区別するために必要なものをシステムに与えます。

重要ポイント: より優れたモデルは役立ちますが、より優れたコンテキストも同じくらい重要になりえます。Enterprise-Benchは、アクションの品質を、判断の時点で利用可能な情報と結びつけています。

ネクストベストアクションは、どのようにして「安全なアクション」になるのか？

推奨が安全なアクションになるのは、システムがコンテキストを理解し、再利用可能な判断ロジックを適用し、権限を尊重し、結果を記録し、必要なときに変更を取り消せるときです。これら5つの統制のそれぞれが、AIが提案したステップがお客様のレコードに触れることを許される前に、成立していなければなりません。

Computer, by DevRevは、これを既存のビジネスツールと連携して動作するAI解決プラットフォームとしてとらえています。これらのシステムを置き換えるのではなく、それらを横断してコンテキストと作業をつなぎます。

この運用モデルには3つの要素があります。

• Computer Memoryは、あなたのドキュメント、商談、チーム、ワークフローを記憶する、永続的で権限を意識したレイヤーです。関連するお客様、製品、サポート、運用のコンテキストをつなぎ、システムが関係性と現在の状態を理解するのを助けます。
• Agent Studio Skillsは、再利用可能なビジネスロジックをエンコードします。チームは、エージェントがどのように調査し、判断し、承認を求め、繰り返し可能なワークフローを完了すべきかを定義します。
• Safe Actionsは、実行を統制します。アクションは権限管理され、記録され、取り消し可能にでき、機微な作業には人による承認を付けられます。

フローは次のようになります。

推奨 → コンテキストチェック → 権限チェック → 必要なら承認 → システム更新 → 監査証跡

これは、提案された回答を別のツールにコピーするようエージェントに求めるのとは異なります。Computerはつながったシステムから読み取り、ワークフローが許可する場合にはあなたのシステムに書き戻します。

たとえば、請求スキルは次のようなことができます。

1. 二重請求が存在するかどうかを確認する。
2. 返金がすでに処理待ちかどうかを確認する。
3. プランと不正のポリシーをレビューする。
4. 金額またはリスクがしきい値を超える場合、承認を求める。
5. 許可された返金を実行する。
6. ケースと決済レコードを更新する。
7. 監査証跡を保持する。
8. ワークフローがロールバックをサポートしている場合、アクションを取り消す。

このパターンは机上の空論ではありません。 50万社以上の企業にサービスを提供する財務オペレーションプラットフォームのBILLは、Computer, by DevRevを顧客対応のAIエージェントとして導入しました。20万件の実際の顧客クエリを対象としたPoC（概念実証）で、このエージェントは70%の解決率に達しました――一般的な問題を数秒で解決し、複雑なケースについてはトリアージして自動化されたワークフローを実行するか、コンテキストを完全に保持したまま人へエスカレーションしました。BILLの事例を読む。

パターンは一般化できるが、統制はそうではない

同じネクストベストアクションのパターンは、アカウント変更、権限の更新、チケットのルーティング、インシデントのエスカレーション、フォローアップのコミュニケーションを支えます。アクションはユースケースによって変わります。統制は一貫したままです。

重大な判断は依然としてエージェントが担います。違いは、ワークフローが安全な道を簡単な道にするという点です――エージェントが何をしていようと、同じガードレール、監査証跡、承認ゲートを維持することによって。

「統制されている」とは実際に何を必要とするのか

すべてのアクションが同じリスクを伴うわけではないため、統制されたワークフローは2つのことを行います。当て推量する代わりに不確実性を表面化させること、そしてアクションをリスクによって段階分けすることです。

必要なデータが欠けている場合、システムはそれを求めるか、エスカレーションすべきです。自信ありげな当て推量でギャップを埋めるべきではありません。

組織はアクションの段階（ティア）を定義すべきです。L

• タグの追加やケースの要約といった低リスクのアクションは、軽量なロギングとともに自動で実行してよいかもしれません。
• チケットステータスの更新や重要でないフィールドの変更といった中リスクのアクションは、実行してよいものの、事後レビューや信頼度のしきい値を必要とするかもしれません。
• 返金、アカウント変更、外部コミュニケーションといった高リスクのアクションは、実行前に明示的な承認とより強力な監査統制を必要とします。

このリスクベースの設計により、チームはすべてのアクションを等しく安全とみなすことなく、自動化を拡大できます。難しいのはモデルではありません。その周りにある配管（プラミング）、権限、書き戻しのルールなのです。

重要ポイント: AIが担う作業が増えるほど、何が起きたのか、なぜ起きたのか、どのように是正するのかを知ることがますます重要になります。統制された実行こそが、その可視性を運用上の安全性へと変え、正しい次のステップを毎回、明確で、統制され、監査可能なものにします。

サポートチームは、アドバイスをさらなる作業に変えてしまうのをどうすればやめられるか？

サポートチームは、AIを提案の品質だけで測るのをやめるべきです。システムが検索、検証、クリック、引き継ぎ、未解決のフォローアップ作業を減らすかどうかを測りましょう。その一つの転換が、評価においてどのベンダーが強く見えるかを変えます。

ベンダーには、きれいなサンプル質問ではなく、現実的なケースを実演するよう求めましょう。顧客履歴、ポリシー、請求の状態、そして関連する製品課題に依存するチケットを与えてください。そして、システムが何をするかを見てください。

最も優れたネクストベストアクションのカスタマーサービスワークフローは、エージェントをデータ入力の作業者ではなく、判断のオーナーとして扱います。システムは証拠を準備し、ルールを適用し、承認されたステップを処理します。人は、判断、共感、例外、そして説明責任に集中します。

チームは成果指標を追跡すべきです。これらの指標は、AIがサービスを良くしているのか、それとも単にやり取りを速くしているだけなのかを明らかにします。

エージェントは、過去のコンテキストを探し回ったり、一般的なアドバイスを疑ったりする必要があってはなりません。ルーティンなステップが統制されたワークフローを通じて前に進む一方で、彼らは判断、共感、例外に時間を使うべきです。

誰も実行しない推奨は、アクションではありません。それは「ネクストベストなアドバイス」です。

Computerがどのように推奨を安全なアクションへと変えるかを、チームとのデモの予約でご覧いただき、エージェント型ワークフローがガイダンスから解決へとどう進むかの広い視点を、カスタマーサービスの自動化でご確認ください。