8月25日、Ali Nahvi、Akshit Behera、Yvonne Fan、Melissa Rameyが「From Prediction to Action: How to Turn AI Outputs Into Decisions」と題した記事を公開した。この記事では、AIモデルの予測結果を実際のユーザーアクションへと橋渡しする「中間レイヤー」の設計パターンについて詳しく紹介されている。チャーンリスクモデルがスコア 0.83 を返す——モデルは仕事を果たした。だが、それを受け取ったセールス担当者は次に何をすればいいのか。
「正確なモデル」が抱える本質的な問題
Salesforceは2025年初頭、あるパラドックスに直面していた。社内には約12,000のダッシュボードと20以上のアプリ・ツールが稼働し、機械学習の予測・アラート・スコア・レコメンデーションを絶えず吐き出し続けていた。技術的には何も壊れていない。にもかかわらず、それを受け取るセールス担当者は「どれが重要か」「何を意味するか」「次に何をすべきか」を自分で判断しなければならなかった。
記事はこの問題を具体的に示している。チャーン（解約）リスクモデルがスコア 0.83 を返したとする。モデルは仕事を果たした。しかしユーザーは何を学んだのか？ 0.83は行動を起こすべき水準か？ なぜそのアカウントがリスク扱いなのか？ 他の更新案件より優先すべきか？
記事の著者らが導いた核心的な結論はこうだ。「すべてのモデル出力をシグナルとして扱え。答えとしてではなく。」 モデルが失敗しているのではない。システムがモデルの出力に、設計されていない仕事をさせているのだ。
シグナルをアクションに変える3要素
0.83を「答え」ではなく「シグナル」と捉え直すと、次の問いが生まれる。そのシグナルを人が実際に行動できる何かに変えるには、何が必要か？
著者らは、Next Best Action（次に取るべきアクション）レイヤーという中間層を設計し、3つの要素を組み合わせることで解決策を構築した。
シグナル：XGBoostや勾配ブースティングなどの機械学習モデルが出力する予測値。パフォーマンス予測・パイプライン健全性・スキルギャップ・離職リスク・製品採用状況などを評価する。ただしシグナルは「何が起きているか」を教えるだけで、何をすべきかは教えない。
ビジネスロジック：予測をどう解釈すべきかを決めるしきい値・優先順位・運用ルール・現在の営業方針。シグナルを文脈に当てはめる役割を果たす。
ナレッジ：経験豊富な担当者が持つ暗黙知・文脈依存の判断。ドキュメント化されたプロセスは教えられても、特定顧客の組織力学への対応は教えられない。シグナルはスケールが安い。ナレッジはしない。
この3要素を組み合わせることで、単なるスコアではなく「アクション・対象アカウント・その根拠・期待される影響」を含む推薦が生成される。
著者らが強調する汎用的なパターンは特定のレイヤー実装ではなく、「評価（Assessment）とアクションの分離」だ。自分のシステムに同じギャップがある場合、次の3問を自分に問うことを勧めている。
- モデルが確実に評価できることは何か？
- その評価を解釈するための運用ルールは何か？
- 行動する前になお必要な知識は何か？
MCPでAIエージェントと推薦レイヤーを接続する
中間レイヤーを設計しても、AIエージェントがそこに確実にアクセスできなければ意味がない。著者らはAnthropicが策定したオープン標準である**Model Context Protocol（MCP）**を、エージェントと推薦レイヤーの間の「契約」として採用した。MCPとは、AIエージェントが外部ツールやデータソースと標準化された形式でやり取りするためのプロトコルであり、ツールの入力スキーマと戻り値の型を明示的に定義することで、エージェントが実行時に必要なツールを動的に判断できるようにする仕組みだ。
エージェントはすべてのパスをハードコーディングせず、ユーザーのリクエストに基づいて実行時に必要なツールを判断できる。
重要なのは「不在」の扱いだ。例えば有効なパイプラインや更新案件が存在しない場合、ツールが空を返すことでエージェントは「結果がない」と認識し、存在しない情報を捏造しない。また対応する能力が存在しなければ、推測せずに断ることができる。
著者らが伝える設計判断の本質はMCPの採用そのものではなく、「エージェントが取得できるものの明示的な契約を持っているか」という問いだ。会話として流暢に見える裏側に不確かなシステムが隠れていないか、確認する必要がある。
分散型 vs. 集中型：アーキテクチャはオーナーシップが決める
複数ドメインがデータと能力を持つとき、集中型MCPレイヤーに集約するか、ドメインチームがそれぞれ独自に管理する分散型にするか——この選択は設計論より先にデータガバナンスとオーナーシップの問題だと著者らは指摘する。
集中型は一貫した契約管理や横断的な優先順位づけがしやすい反面、変更のたびに複数チームの調整コストが生じる。一方、分散型はドメインチームが自律的に動ける反面、ツール仕様の乖離やバージョン管理の複雑化というリスクを抱える。著者らはどちらが普遍的に優れているとは断言しておらず、「アーキテクチャはオーナーシップに従うことが多い」という立場をとる。トポロジーを議論する前に、誰がデータを保持でき、誰がその契約を維持でき、誰が責任を持てるかをまず整理せよ、という指摘は実装経験に裏打ちされている。
「12,001枚目のダッシュボード」を作らない
アーキテクチャが整っても、ユーザーが新たなアプリを開かなければ推薦にアクセスできない構造であれば、ダッシュボードを12,001枚に増やしただけだ。
著者らが選んだ答えはSlack連携だ。セールス担当者がすでにSlackで取引の会話・マネージャーとのやり取り・顧客フォローアップをこなしていたため、そこにエージェントを置いた。担当者が「今日の予定を立てて」と話しかけると、優先アカウント・その根拠・期待される影響・実行に必要な知識が返ってくる。プッシュ通知ではなくプル型のインタラクションだ。
最後に著者らが提示する設計テストはこうだ。「予測の精度を上げた後、ユーザーに新たな場所を訪れることを強いていないか？そうなら、予測問題を解決しながら注意力の問題を温存したままだ。」
自分のシステムを点検する
記事が最終的に促すのはシンプルな問いだ。自分のシステムで、モデルが予測を出してからユーザーが何をすべきか分かるまでの間に何があるか。その答えが「ユーザーが自分で考える」であれば、そこにエンジニアリングのギャップがある。
詳細はFrom Prediction to Action: How to Turn AI Outputs Into Decisionsを参照していただきたい。
