Managed Agentsで営業の問い合わせ対応を再設計 — 成約が約5日早まった

Anthropicの営業チームが、Claudeの購入相談に答えるエージェントをClaude Managed Agents(ベータ)で作りました。Contact Salesフォームに入力した人が数日待たされる状況を、チャットで即答する形に置き換えた事例です。2026年9月30日、営業開発リーダーのCarl Johnson氏がClaude公式ブログで経緯を語っています。

要点

• 以前は、フォームに入力した購入検討者が返信まで数日待つことがあった
• 質問の多くは、プランの料金、席数の下限、HIPAAの契約要件といった、ドキュメントに書いてある内容だった
• 購入相談エージェントは、プロンプト、少数のツール、Claudeの組み合わせで、Managed Agents上で動く
• 1日あたり数千件の会話を処理し、会話は「購入」「営業への引き継ぎ」「質問への回答のみ」の3通りで終わる
• 営業に回ってきたリードは、従来のフォーム経由より商談化する割合が2倍超で、成約までが約5日短い

営業の人手が足りない問題を、問い合わせの入口で解く設計だと言えます。

問い合わせ窓口は何が詰まっていたのか

従来の流れは単純でした。購入検討者がフォームを入力し、BDR(インバウンド対応の営業開発担当)が選別して、アカウントエグゼクティブに渡します。

この流れは、興味を持った全員と話せる規模なら機能します。ところが月に数万件の問い合わせが入り、BDRチームでは追いつきませんでした。担当者はドキュメントに書いてある質問に答えるだけで一日が終わり、待ち行列の全員には届きません。

営業側が目指した状態は3つです。

1. どの時間帯でも、どの言語でも、詳しい回答が得られる
2. 営業担当と話さずに購入できる
3. 営業担当は、結果を左右できる会話に時間を使う

購入相談エージェントはどう動くのか

置き場所は、Contact SalesとPricingのページ、製品内、メールです。Claude.ai内でもチャットから使えます。

購入検討者がチームの要件を話すと、エージェントがいくつか追加の質問をします。そのうえで料金、セキュリティ、データの質問に答え、プランと席数を提案します。会話の終わり方は次の3通りです。

エージェントを使うか営業担当と話すかは、最初に顧客が選びます。この体験はあえてオプトイン(選択式)にしたとのことです。

引き継ぎ後の営業は、白紙から始めません。営業担当は、顧客が何を必要とし、何を伝えられたかを知った状態で会話を始められます。新しいセルフサーブのEnterprise顧客には、購入前にエージェントと話す人が多いといいます。エージェントと先に話した顧客は購入するものへの理解が深かったとありますが、これは営業側の感触で、測定方法は示されていません。

エージェントの動きは、営業担当の仕事に沿って作られています。顧客が何を解決したいか、現在のClaudeの使い方、どう支援できるかを順に確かめる流れです。

なぜManaged Agentsを選んだのか

購入相談エージェントの要素を、Managed Agentsの4つの概念に当てはめると次のようになります。

Environmentの種別(Anthropic管理のクラウドサンドボックスか、自社基盤か)と、ナレッジベースの実装方法は、ブログでは明かされていません。表のSessionとEventsの行はドキュメントの定義からの当てはめで、ブログが明言した対応ではありません。

ブログは選定理由を5点挙げています。

• 本番までが速い: エンジニア1人が数週間で初期版を作った
• 非エンジニアも参加できる: コードはエンジニアが持つが、システムプロンプトは営業とコンテンツ担当がConsoleで直接レビュー・編集した。変更はまずステージング用のエージェントに入り、顧客に届く前に試せる
• ハーネスに手を取られない: エージェントループ、セッション、ホスティングはプラットフォーム側が担う。チームはプロンプト、ツール、ナレッジベースに集中できた
• バージョン管理で試行錯誤が安い: 変更のたびに別バージョンとして保存される。社内テスト開始から1週間ほどでv7に達し、公開後も毎週プロンプトを更新した。必要なら新しいセッションを前のバージョンに戻せた
• 用途を広げやすい: 現在は顧客がサイトから見つける形だが、Managed Agentsは定期実行に対応しており、別の顧客接点を試す道がある

バージョンと定期実行の2点は、Managed Agentsのドキュメントでも確かめられます。エージェントは「作成して、IDで参照する」再利用可能なリソースで、versionは1から始まり、設定が変わる更新のたびに増えます。更新時にversionを渡すと、他の更新との衝突を検知でき、食い違えば409が返ります。省略すれば最後の書き込みが勝ちます。設定項目の詳細はManaged Agentsのagent設定にあります。

毎週のプロンプト更新を支える仕組みは、agentのライフサイクル操作に揃っています。

プロンプトを週次で書き換えても履歴が残るので、変更を遡れます。ブログにある「新しいセッションを前のバージョンに戻せた」は、この履歴を前提にした運用です。セッション作成時にagentをIDの文字列で渡すと最新バージョンで起動し、{"type": "agent", "id": ..., "version": 1}のようにバージョンを指定すると、そのバージョンに固定できます(sessionsのドキュメント)。新しいバージョンを段階的に展開するための仕組みです。ブログの切り戻しがこの指定によるものかは書かれておらず、筆者の推定になります。Archiveは戻せない操作なので、旧バージョンへの切り戻しには使えません。

Consoleでの共同編集は、ConsoleでManaged Agentsを構築する手順が扱う領域です。定期実行はスケジュールデプロイのcron設定で確認できます。

現場で得られた3つの知見

目標を渡し、プロンプトは短く保つ

「顧客の要件を理解し、見込み客を選別し、最適なプランを推奨する」程度の目標を書くほうが、選別条件をフローチャートのように並べるより効果的でした。プロンプトの長さ、複雑さ、構成を変えて試したところ、短いほうが良い結果になったそうです。席数課金の範囲や請求サイクルの時期のような、判断に必要な知識と文脈を渡して、あとはClaudeの邪魔をしない方針です。

この試行錯誤は、変更が毎回バージョンとして残るから回せた面があります。短いプロンプトと長いプロンプトを並べて試し、結果が悪ければ前のバージョンに戻せるからです。

専門家を開発ループに入れる

Managed AgentsとClaude Codeで開発の時間が浮き、エンジニアは営業チームと過ごす時間を増やせました。早い段階から何度も試せたことが、反復の速さにつながっています。営業とコンテンツ担当がConsoleでプロンプトを直接編集でき、変更はステージング用のエージェントで先に確かめられる分担が、この関わり方を支えました。

顧客にとって正しい答えを優先し、引き継ぎを改善に使う

小規模チームにはEnterpriseでなくTeamプランを案内することがあります。営業側はこれを機能として受け入れました。売り込まれずに合うプランへ着地した買い手のほうが、定着しやすいという判断です。

エージェントが営業に引き継ぐたびに、理由が付きます。初期は、セルフサービスの製品では顧客が自分でできないことが理由の大半でした。その積み上げで体験を改善し、成約に人の手が必要だった会話の割合は約半分に減ったとのことです。引き継ぎ時に会話の全内容を営業へ渡す設計が、理由の記録をそのまま改善の材料にしています。

数字はどう読めるか

効果の数字は次のとおりです。

いずれも営業チーム自身の報告で、母数や期間は示されていません。「2倍超」は比較対象が従来のフォームなので、エージェント経由の絶対的な商談化率までは読み取れない点に注意が必要です。

もう1つ見落としやすい点があります。エージェントは大きい案件や複雑な案件を営業へ引き継ぎ、自力で購入できた人は営業に来ません。そのため、残る案件の質が上がるのは構造上自然な側面もあります。それでも「教育済みのリード」が営業の時間を使う先を変えた、という証言は具体的です。

窓口の設計は営業組織の役割を変える

この事例の核心は、チャットボットの精度ではありません。引き継ぎ理由の記録を製品改善に回し、人間が対応する範囲を絞り込んでいく運用ループにあります。

エージェントの出来を測る物差しが、会話数でなく「営業に回った理由」である点が重要です。理由が減れば、セルフサービスの製品側が育った証拠になります。逆に理由が減らなければ、エージェントでなく製品の穴が見つかったことになります。

営業担当の役割も変わりました。回答係から、早い段階で顧客を教育し、対面イベントで時間を使う役割へ動いています。エージェントの採用が営業チームの時間の使い方まで変えた一例が、Johnson氏の投稿です。Managed Agents自体の使い分けはAgent SDKやClaude Codeとの比較記事で扱っています。

同じ構成を試す前に確認しておきたい点

Managed Agentsのドキュメントには、この構成を検討する人が知っておきたい条件が書かれています。

• ベータであり、全エンドポイントにmanaged-agents-2026-04-01ベータヘッダーが必要(SDKが自動で付ける)
• セッションは状態を保持する設計のため、現時点ではZero Data Retention(ZDR)とHIPAAのBAAの対象外
• セッションとアップロードしたファイルは、APIから削除できる

ブログ本文に出てくるHIPAAは、購入検討者が契約要件を尋ねた質問の例です。エージェントが実際にどう答えるかはブログに書かれていません。セッションの保持条件は上のとおりなので、機微な情報を扱う用途では、ドキュメントの適格性の記述を先に確認する必要があります。料金面はManaged Agentsの料金、売る側のプラン構成はClaudeの料金プランで確認できます。

まとめ

問い合わせの待ち行列に悩む営業やカスタマーサクセスの組織には、入口での即答と引き継ぎ理由の記録を組み合わせた構成が参考になります。Managed Agentsを検討する開発者にとっては、エンジニア1人で数週間、プロンプトは非エンジニアがConsoleで直接編集、という分担が具体例です。

数字はAnthropic自身の報告で、母数と期間は不明です。自社に当てはめるなら、まず引き継ぎ理由の分類から始める形が現実的です。

Anthropicはこのエージェントを「顧客との関係全体にエージェントを広げる最初の一歩」と位置づけています。