はじめに
Salesforceは2026年9月、Agentforce向けのCRM reasoning modelとして「Koa」を発表しました。
公式ページを読むと、Koaには「CRM業務を学習している」「組織のデータでgroundingする」「適切なactionを選ぶ」といった説明が出てきます。ただし、この3つは同じ処理ではありません。
ここを混ぜると、
- 顧客データでモデルが再学習される
- Koa自身がSalesforceレコードを直接更新する
といった誤解につながります。
本記事では、Koaを次の3つの観点に分けて整理します。
- 学習（post-training）：モデルにどのような業務パターンを身につけさせたか
- grounding：実行時に、どの情報をモデルへ渡すか
- action：モデルの判断を、どの業務処理につなげるか
この3分類は、Koaの公式アーキテクチャ名ではありません。公開情報を読み解くための整理です。
※本記事は2026年10月1日時点の公式情報を基にしています。Koaは現在、限定された顧客向けのPilotです。一般提供（GA）は米国リージョンでWinter 2026に予定されています。GA後にはopen betaを始める計画も示されています。日本での提供、価格、対象Edition・SKUは、確認した公式ページでは明示されていません。
※本記事の図解は、公開情報をもとに筆者が独自に作成したものです。Salesforce公式の資料ではありません。
Koaはゼロから作った基盤モデルではない
SalesforceはKoaを、NVIDIAのNemotron 3 Superを基盤にpost-trainingしたモデルと説明しています。公式解説では、Nemotron 3 Superは1,200億パラメータのオープンモデルとされています。
Salesforceのプレスリリースでは、Koaの学習コーパスは実在する顧客データを使わず、CRM業務を模した合成シナリオのみから構築したと説明しています。
公式発表では、製造、金融、医療、旅行など14以上の業界を想定したシナリオが作られたと説明されています。
シナリオには、リードの獲得、商談の評価、サービスケースの解決といった業務に加え、必要なactionやtool callの流れも含まれます。
post-trainingの説明は資料によって少し異なる
post-trainingの手法については、公式資料によって説明に差があります。
-
プレスリリース
- SFT（Supervised Fine-Tuning、教師あり微調整）と、GRPO（Group Relative Policy Optimization）を用いた強化学習でpost-trainingしたと説明しています
- NVIDIAのNeMo系ツール（NeMo RL、NeMo Gym、NeMo AutoModelなど）を利用したとしています
-
公式解説記事
- まずSFTを試したものの、得られた改善は限定的だったため、強化学習へ移行したと説明しています
-
技術論文
- 最終的なKoaは、Nemotron-3-Super-120BにGRPOによる強化学習を適用して作ったモデルとして説明されています
- SFTは、RL採用前の予備検証と、SFTのみ／RLのみを比べる追加の比較実験として扱われています
技術論文では、
We apply RL directly to the base model rather than to an SFT checkpoint
と説明されており、SFT済みcheckpointを経由せず、base modelに直接RLを適用したとしています。
なお、SFTとRLの比較実験については注意が必要です。
比較の起点となるNemotronは、Koa向けの追加学習以前にもRL post-trainingを受けたモデルです。論文自身もこの点を限界として挙げており、pre-RLのcheckpointから比較した場合には結論が変わる可能性があるとしています。
そのため、この比較だけから「一般的にRLがSFTより優れている」とまでは結論づけられません。
本記事では、最終モデルの学習方法について技術論文の記述に従い、SFTを最終モデルの学習工程とは断定しません。
Koaの「CRM向け」という特徴は、利用企業のレコードを事前に覚え込ませたことではありません。
CRM業務を模したデータを使い、業務上の推論やtool利用をpost-trainingした点にあります。
Salesforceは、Koaの学習に顧客データを使わず、利用時のデータや推論traceもモデルの学習に使わないと説明しています。
なお、Salesforceの研究チームがarXivで公開した技術論文の要旨では、学習データを「公開データと合成データ（顧客データは含まない）」と表現しています。
プレスリリースの「合成シナリオのみから構築した学習コーパス」という説明とは粒度が異なりますが、顧客データを含まないという点は共通しています。
groundingは、実行時に業務情報を渡すこと
学習済みの業務パターンだけでは、
- この顧客の現在の契約状況
- この組織で定めた承認条件
- 現在進行中の商談内容
といった情報は分かりません。
そこで必要になるのがgroundingです。
ここでは、言葉の使い分けにも注意が必要です。
製品ページには、
Koa is grounded in nearly three decades of CRM deployments
という表現があります。
このgrounded inは、約30年にわたるCRM導入の知見を背景にしている、という通常の英語表現です。
実行時にレコードなどを渡す、次のFAQのgroundingとは用法が異なります。
KoaのFAQでは、利用者が提供したgrounding data、レコード、指示をKoaが参照すると説明されています。
Koaが見られるのは、利用者側が共有するよう設定したcontextです。
また、SalesforceはKoaの重みを自社で管理し、推論も自社インフラのtrust boundary内で実行すると説明しています。
groundingは、モデルの重みを更新する学習とは別の処理です。
実行時に関連情報をcontextとして渡し、その内容を踏まえて推論させます。
| 観点 | 主な役割 | Koaでの整理 |
|---|---|---|
| 学習（post-training） | モデルの能力や振る舞いを形成する | 合成CRMシナリオなどを使い、業務推論やmulti-turnのtool利用を追加学習する |
| grounding | 現在の業務情報を推論材料として渡す | 利用者が共有したgrounding data、レコード、指示を実行時に参照する |
| action | 推論結果を業務処理へつなぐ | Agentforceで利用するtoolやactionを選び、複数stepの処理につなげる |
groundingされた情報が常に正しい、最新である、閲覧を許可されている、という意味ではありません。
元データの品質、共有範囲、権限設定は別に確認する必要があります。
actionでは「判断」と「実行」を分けて考える
Salesforceはreasoning modelについて、複雑な問題を段階的に考え、どのtoolを呼ぶかを決め、回答またはactionの前に経路を検証するものと説明しています。
Koaの学習シナリオにも、actionとtool callの順序が含まれています。
公式解説には、必要なtoolが用意されていない状況も意図的に学習させた例があります。
似た名前のtoolを誤って呼ぶことや、実行していないactionを完了したと伝えることを避けるためです。
代わりに、
- できないことを説明する
- 必要な情報を求める
- 人へ引き継ぐ
といった振る舞いをKoaに学習させたとしています。
これは保証された動作結果ではなく、post-trainingで狙った振る舞いについての説明です。
一方で、モデルがactionを選ぶことと、外部システムで副作用を伴う処理が実行されることは分けて考える必要があります。
たとえば商談更新では、概念的には次の流れになります。
- Koaが、与えられたcontextを基に次の処理を判断する
- 利用するtoolやaction、その引数を選ぶ
- Agentforceなどの実行基盤が、設定された範囲で処理を呼び出す
- Salesforce側でレコード更新などの結果が生じる
したがって、
Koaが無条件にレコードを書き換える
という捉え方は適切ではありません。
Koaが担うreasoningと、Agentforce側のaction定義、アクセス権、実行制御を分けて確認する必要があります。
公式製品ページでは、Koaを複数の場所で選択する構成が紹介されています。
- Data CloudのGenerative Modelsカタログ
- Agentforceの組織レベル
- Agent／Sub-Agent単位
などです。
ただし、現在の提供段階はselect customer pilotです。画面や設定手順がすべての組織で利用できるという意味ではありません。
なお、同じ製品ページの「Managed LLMs」の説明には、Data CloudのGenerative Modelsカタログについてavailable to all customers out of the boxとする表現もあります。Pilotという提供状況の記述と併記されているため、本記事では実際の利用可否についてはPilotの説明を優先して扱います。
ベンチマーク値はSalesforceの発表値として読む
Salesforceは独自のCRM Benchで、商談更新、ケースのルーティング、フォローアップの予定作成などを評価したと説明しています。
製品ページには、比較対象の異なる2種類の結果が掲載されています。
-
leading modelとの比較- CRM actionで同等以上の性能を示し、エラーは
3x fewer
- CRM actionで同等以上の性能を示し、エラーは
- 現行の既定の汎用モデルとの比較
- action選択のprecisionは11%高い
- 顧客contextを想起するreliabilityは2.1倍
- 長い会話でのcontext記憶は15%良い
これらはSalesforceによる評価結果です。
したがって、
精度が3倍
あるいは、
どの業務でもエラーが3分の1
という意味ではありません。
Koa製品ページからリンクされているCRM Benchの紹介ページも確認しました。
しかし、次のKoa固有情報までは確認できませんでした。
- 比較したモデルの名前
- 評価件数
- 各改善値の算定方法
- 第三者による再現結果
一方で、Salesforceの研究チームは2026年9月14日に技術論文「Salesforce Koa: An Enterprise Language Model for Agentic Tool Use」をarXivで公開しています。
論文では、公開のtool利用ベンチマークであるTau2Bench、BFCLなどや企業CRM向けベンチマークを用いて評価しています。
その結果についてSalesforceは、
- Koaが基盤となったNemotronモデルを上回る
- GPT-4.1を上回る
- 一方で、最も強いフロンティアモデルには届いていない
とまとめています。
なお、Salesforceの公式解説記事では、CRM固有タスクの初期ベンチマークについて「最も強い汎用モデルを上回った」と説明しています。上記の技術論文の結論とは表現が異なります。
評価対象のモデル、ベンチマーク、条件が異なる可能性があるため、本記事では両者を同一条件の結果としては扱いません。
また、製品ページの数値、
3x fewer errors- 11%
- 2.1倍
- 15%
が、論文中のどの評価に対応するのかは確認できませんでした。
論文もSalesforce自身による評価であり、第三者による再現結果ではありません。
現段階では、製品選定の参考値の一つとして扱うのが安全です。
導入前に確認したいこと
Koaを検討するときは、モデルの性能だけでなく、次の境界を確認すると整理しやすくなります。
- どの業務パターンがpost-trainingに含まれているか
- どのレコードや指示をgrounding contextとして渡すか
- Agent／Sub-Agentにどのactionを許可するか
- actionの実行権限、入力値、失敗時の動作をどう制御するか
- 推論traceや監査情報をどこまで確認できるか
- 利用リージョン、価格、Edition、SKUが自社条件に合うか
- Salesforce発表のベンチマークを、自社の業務でどう再評価するか
まとめ
Koaの特徴を理解するときは、「CRM向けモデル」という一言でまとめず、3つに分けると見通しがよくなります。
-
学習
- 合成CRMシナリオなどを用いたpost-trainingで、業務推論やtool利用のパターンを身につける
-
grounding
- 利用時に、組織が共有したレコードや指示をcontextとして渡す
-
action
- reasoningの結果を、Agentforce側で定義された業務処理へつなげる
Koaが業務特化モデルであっても、
- 最新データの品質
- アクセス権
- actionの安全性
まで自動的に保証されるわけではありません。
モデルの能力と、実行時のデータ・権限・処理を分けて確認することが、導入判断の出発点になりそうです。
※本記事は個人の整理メモです。実際の提供状況と契約条件は、Salesforceの最新ドキュメントおよび担当窓口で確認してください。