▼ この記事の内容
AIエージェントツールは、文章生成だけでなく、状況に応じて情報参照や外部操作の手順を選ぶ設計を含みます。候補は製品名で並べず、任せる業務、確認者、接続範囲、停止条件、保守作業を同じ表で比べると、試行の範囲を決めやすくなります。
営業の商談準備を題材に、固定の手順で足りる作業と、状況に応じた処理を分けます。ここで示す表と会話は説明用の架空例であり、特定製品の出力、性能検証、導入成果ではありません。
候補製品の機能、料金、契約条件は変わり得るため、各社の公式情報と契約条件で確認してください。まずは参照と更新案の作成を試し、確認後に許可した保存操作へ進む手順を扱います。顧客への送信や契約の確定は、この架空例の対象に含めません。
AIエージェントツールとは｜固定処理との違い
状況に応じて手順を選ぶ仕組み
Anthropicの「Building effective agents」では、あらかじめ決めた処理経路に従うワークフローと、状況に応じて手順やツールの使い方を選ぶエージェントを区別しています。これは設計上の区別であり、特定製品の標準機能や利用成果を示すものではありません。
外部ツールを使う業務を検討する時は、どの条件で情報を参照し、誰が操作を確定するかを先に決めます。会話画面の有無ではなく、判断と操作をどこまで任せるかで範囲を比べます。
参考：Building effective agents｜Anthropic
要約や下書きなら固定処理も選択肢
商談メモの要約や質問案の下書きだけなら、固定した入力と出力の処理で足りる場合があります。外部システムを更新しない作業まで、必ずエージェント型にする必要はありません。
外部操作を加える場合も、読み取り、更新案の作成、書込み、送信を同時に許可しないことが比較の出発点です。次に、候補の導入形態と保守責任を同じ表に置きます。
AIエージェントツールの選び方｜導入形態と比較項目
保守責任で導入形態を分ける
候補は、既成の業務アプリ、既存の業務基盤を拡張するもの、開発用フレームワークに分けて考えます。分類は優劣ではなく、誰が構築し、設定変更や障害時の対応を誰が担うかを確認するための枠組みです。
既成アプリでも接続範囲や権限の設定は残り、フレームワークなら実装と保守の責任が増えます。営業領域の周辺ツールも含めて役割を整理するなら、営業ツールの役割を参照してください。
候補を絞るときは、既存の業務環境と構築担当の有無を先に確認します。以下は導入形態の違いをつかむための製品・開発手段の例です。同じ機能を備える製品の順位表ではありません。公式情報の確認日は2026年9月15日です。
| 候補を検討する条件 | 例と公式情報で確認した範囲 | 契約・試行で別途確認すること |
|---|---|---|
| Salesforce内の営業業務を対象にし、既成の用途から検討したい | Agentforce for Sales。Salesforceの教材では、営業開拓を支援する機能と営業コーチングの用途を紹介している | 必要な契約、対象データ、外部送信の範囲、操作前の確認方法。既成の用途でも設定は必要 |
| 業務データへの接続を組み合わせ、管理担当がエージェントを構成する | Microsoft Copilot Studio。公式文書では既成・カスタムのコネクタでデータやAPIへ接続し、知識とツールを拡張できると説明している | 接続先ごとの操作、認証・ライセンス、書き込み権限、失敗時の復旧。接続名だけで対応操作を判断しない |
| 開発担当が確認・停止の処理を実装し、運用も担える | LangChainのHuman-in-the-Loop機能。ツール呼び出しを設定した条件で止め、人の承認・編集・拒否を受ける仕組みを説明している。状態保存にはLangGraphを使う | 永続化、確認画面、再開処理、監視を誰が実装するか。導入するだけで自社の承認手順が完成するわけではない |
参考：Discover Agentforce for Sales｜Salesforce、Extend the capabilities of your agent｜Microsoft、Human-in-the-loop｜LangChain
比較表では利用者・接続・試行環境をそろえる
比較表には、利用者、構築担当、参照する情報、書込み権限、保守担当、試行環境を並べます。機能名だけを横に並べると、実際に必要な設定や確認作業が比較から抜け落ちます。
| 比較項目 | 自社の必要条件 | 公式資料で確認すること | 同条件で試すこと |
|---|---|---|---|
| 業務範囲 | 参照のみ／案作成／保存を分ける | 対象業務と操作可能なシステム | 商談記録から未確認事項を残した案を作る |
| 接続・権限 | 閲覧と書込みの許可範囲 | 誰の権限で接続するか、対象レコードの制限 | 権限外の案件を指定した時の動作 |
| 人の確認 | 保存前に内容を確認できること | 確認画面、却下、取消の適用範囲 | 案を却下して保存が行われないことを確認 |
| 構築・保守 | 自社と提供側の担当を決める | 設定変更、障害対応、更新時の試験範囲 | 接続条件を変えて担当者が復旧手順をたどる |
| 試行環境 | 本番と分けたデータで試す | 試用で使える接続先・モデル・操作の制限 | 本番との差と未確認事項を記録 |
営業の商談準備で試す手順
商談記録とCRM更新案を分けて扱う
小規模試行では、許可済みの商談記録を入力し、顧客の原発言と未確認事項を整理して、CRMへの更新案を作るまでを別々に扱います。保存は担当者が案と根拠を確認した後に行う、という架空の手順です。
たとえば「来月に再確認したい」という発言は原発言として残し、日程が確定したと補完しません。下表は実在顧客や製品出力ではなく、確認の置き場所を示す説明用の例です。
| 段階 | 架空の記入例 | 人が確認すること |
|---|---|---|
| 入力 | 許可済みの商談記録 | 利用範囲と記録の対象 |
| 更新案 | 未確認の質問をCRM項目へ提案 | 識別子と原発言の対応 |
| 保存 | 確認後に更新を実行 | 保存結果と重複の有無 |
| 記録欄 | 架空の商談準備例 |
|---|---|
| 対象 | 青葉機器の更新相談案件A。企業名だけでなく案件の識別情報で照合 |
| 顧客の原発言 | 来月に再確認したい |
| 確認済みの範囲 | 再確認の希望はあるが日程の合意はない |
| 更新案 | 次回日程は未確定。担当営業が希望時期と確認先を相談する |
| 確認者の判断 | 原発言と更新対象を照合し、この内容で保存するかを判断 |
| 保存後の照合 | 対象案件の値と更新履歴を確認。応答だけで成功と決めない |
CRM更新前に識別子と空欄の扱いを決める
更新案を扱う場合は、どの顧客や案件に対応するかを識別子で照合し、空欄が未確認なのか削除の意図なのかを区別し、移行先での扱いを確認します。根拠のない値を補いません。候補製品に重複抑制や取消の機能があるとは限らないため、仕様を確認してから範囲を決めます。
営業AIを比べる時の確認軸は、営業AIの比較方法も参考になります。更新案の作成と実際の書込みは、同じ許可として扱わないでください。
例外試行で停止・再実行・引き継ぎを確認する
根拠なし・権限なし・承認却下を試す
書込み前の試行では、根拠が足りない更新案、権限のない操作、担当者が承認しない案を用意し、期待する停止動作と実際の結果を別欄に残します。人の確認を標準搭載と仮定せず、候補ごとの設定と運用で確認します。
タイムアウトや接続失敗の扱いは、情報システム担当者と事前に決めます。営業データを扱う範囲では、営業AIのセキュリティ確認も確認材料になります。
保存結果が不明な場合は再実行前に照合する
保存結果が不明な状態で同じ依頼を再実行すると、二重の更新や送信につながることがあります。保存済み、未保存、不明を分け、候補システムで照合する場所と取消可否を確認します。
例外試行表には、再実行した人、照合した記録、引継ぎ先も残します。既存システムとの接続を扱う場合は、営業ツールの連携設計で検討項目を整理できます。
| 試行条件 | 期待する動作（設計例） | 実結果として残す記録 |
|---|---|---|
| 根拠に日程がない | 日程確定を補わず、未確認の更新案にする | 原記録、生成案、確認した担当 |
| 対象レコードへの権限がない | 書込みを進めず確認先を示す | 拒否された操作、表示内容、担当への通知 |
| 担当者が案を却下する | 保存を実行せず理由を残す | 却下内容と保存されていないことの照合 |
| 接続がタイムアウトする | 保存結果を確認するまで同じ操作を繰り返さない | 対象ID、操作時刻、保存先の現在値 |
| 保存済みだが応答が返らない | 保存先を照合し重複実行を避ける | 変更前後の値、履歴、再実行の要否 |
| 同じ依頼が再送される | 依頼と対象操作を照合して処理の要否を判断する | 依頼の識別方法、既存履歴、判断者 |
利用料金と構築・保守の作業を同じ期間で比べる
課金単位と失敗時の費用を同じ表で比べる
費用を比べる時は、基本料金、モデル利用、外部サービス、試行、失敗時の再実行、構築、監視・更新を同じ期間と対象範囲で並べます。不明な費用をゼロとして計算せず、確認先を残します。
営業支援のFAZOMも併せて検討する場合は、FAZOMの導入ガイドも参照できます。FAZOMを営業支援の候補として検討する場合の確認資料であり、各AIエージェント製品の仕様を示すものではありません。
構築・監視・更新の担当を決める
比較表では、自社と提供側のどちらが設定、監視、変更時の確認、再試行を担うかを分けます。担当が不明な作業は、候補を選ぶ前に質問として残し、契約条件と公式情報で確認します。
費用表の記入例は次のとおりです。固定の金額や工数を示すものではなく、比較時に見落としやすい作業を並べるためのひな型です。
| 費用・作業 | そろえる単位 | 確認する条件 |
|---|---|---|
| 基本料金 | 席数・契約期間・必要プラン | 最低利用条件とオプションの範囲 |
| モデル利用 | 入力・出力や呼出しなど契約上の課金単位 | 試行、修正、失敗、再実行にかかる利用量 |
| 外部サービス | 接続先ごとの操作件数と契約 | 別契約、上限、追加料金、基本料金との重複 |
| 構築・変更 | 初期設定と接続変更の作業範囲 | 担当者、作業費、試験環境の費用 |
| 継続運用 | 監視・確認・更新・再試行の作業時間 | 自社の人件費と提供側費用を分け、不明はゼロにしない |
完了結果と人による確認作業を分けて評価する
案の生成と保存完了を分けて確認する
評価では、案が生成されたことと、確認後に保存されたことを別の状態として記録します。対象業務と対象期間を固定し、処理中や確認待ちを完了の分母から消さずに扱います。
架空の評価記録には、依頼、案、確認結果、保存結果、修正理由、中止理由を残します。商談内容を読む観点は、商談分析の考え方も参照してください。
次は状態の記録方法を示す架空例です。実際の製品試験ではありません。対象依頼4件のうち保存確認済みは1件ですが、この値を製品の性能や導入効果として比較には使いません。修正は途中経過、保存状態は操作結果として別の列に残します。
| 依頼（架空例） | 案の状態 | 保存の状態 | 次の確認 |
|---|---|---|---|
| A：再確認希望の整理 | 原発言と照合済み | 担当者の確認後に保存し履歴も照合済み | 次回日程は未合意として残す |
| B：根拠のない日程補完 | 担当者が修正を要求 | 未保存 | 日程を消して再確認 |
| C：対象案件の更新 | 案は確認済み | 接続エラーで保存結果不明 | 同じ依頼を実行せず保存先を調査 |
| D：対象外の契約確定 | 依頼を中止 | 未実行 | 対象業務を限定した案内を返す |
修正・中止の理由を次の試行に生かす
修正や中止が起きた時は、顧客の原発言、営業側の仮説、未確認事項を混ぜずに残します。次の試行では、どの条件を変え、誰が確認し、どの時点で停止するかを一つずつ見直します。
この記録は受注や売上への因果を示すものではありません。練習テーマへ戻す場合は、営業ロープレの選び方のように対象場面と観察項目を決めて扱います。
まとめ
AIエージェントツールは、固定処理で足りる作業と、状況に応じた参照や外部操作が必要な作業を分けて比較します。候補ごとの機能名ではなく、任せる業務、確認者、接続、停止、保守を同じ表に置いてください。
営業の商談準備では、入力、更新案、人の確認、保存結果を分離して小さく試します。費用と評価も同じ対象範囲で記録し、不明な条件は確認先として残してから候補を比べてください。
