Managed AgentsでBDR業務を5体に分担 — Anthropic日本チームの運用

Anthropic日本チームの営業開発担当(BDR)が、自分の1日の仕事を5体のエージェントに分け、Claude Managed Agents(ベータ)とClaude Tag(ベータ)で回す方法を公開しました。2026年10月16日にClaude公式サイトのリソース記事として出た一人称の事例で、筆者はShahboz Ibragimov氏です。エージェントの総称は「Nakama」(日本語で仲間)です。

要点

• 以前は毎朝2時間ほどをリードの振り分けと日英のメール作成に使い、CRMの更新は1日以上遅れていた
• 仕事を5つに分け、1体に1つの役割を持たせた。調整役の6体目が、他のエージェントの指示とナレッジベースを更新する
• 最初はClaude上のスキル、スケジュールタスク、共有フォルダで試作し、数が増えた段階でManaged Agentsへ移した
• 例外的な案件は、エージェントがSlackでClaude Tagに渡す
• 筆者の集計では、作業時間の節約は約60時間。モデルは役割ごとに使い分けている

業務の置き換えよりも、1体1役・共有メモリ・モデルの使い分けという設計の型が読みどころです。

5体と調整役は何を担当するのか

記事に出てくるエージェントは、日本語の名前で呼ばれています。働く言語が主に日本語だからだそうです。

Furiwakeは、リードの件数と優先度を見ながら、その日出社している人を確認して割り当てます。全員が仕事を始める前に、すべてのリードに持ち主が付く設計です。

Sabakiは、事前に決めた基準でリードを分類し、分類ごとの次の手を実行します。セルフサーブへの誘導メールの下書きも、個別の初回メールの作成もここに含まれます。

SabakiとHenji、Nokoriは、同じ共有ナレッジベースから下書きの材料を引きます。この共有が運用の要です。後半で詳しく見ます。

朝の働き方はどう変わったのか

筆者の役割は、下書きの確認と、人の判断が要る案件の処理に移りました。料金の質問、慎重な扱いが要るアカウント、意図が曖昧な依頼は、文書化されたルールに従って筆者に回ります。

Henji、Sabaki、Nokoriの下書きには、冒頭に状況の短い要約が付きます。スレッド全体をたどらなくても、要約を読んで確認し、直して送れます。

節約時間の数字には、読み方の注意があります。筆者は週次のログを見て、エージェントが処理した作業をすべて手作業なら何時間かかったかに換算し、約60時間としています。ただし記事には、この60時間が1週間あたりか、導入からの累計かが書かれていません。本人の換算であり、第三者の計測でもありません。

浮いた時間の使い道は、顧客との会話、アウトバウンドの戦略、部門横断のプロジェクト、そして同僚が自分のエージェントを作る手伝いだそうです。

試作から本番移行まで

試作はClaudeだけで足りた

筆者は最初からManaged Agentsを使ったわけではありません。試作はClaudeの通常機能で組んでいます。

1. エージェントごとに、仕事1つ分の指示をスキルにする
2. スキルごとにスケジュールタスクを置き、手動で起動しなくて済むようにする
3. ノートPC上の共有フォルダを、全スキルの共通ナレッジベースにする。下書きと実際に送ったメールの差や、調べて分かった新情報を書き戻す

同僚が欲しがったとき、渡せたのはスキルのzipとナレッジベースのMarkdownだけで、受け取った側は設定の質問に答えるところから始める必要がありました。筆者自身も、同じスキルが複数の会話から編集され、変更履歴が追えない状態になっていました。これが移行の動機です。

Managed Agentsでは何に置き換わったか

筆者は、社内の開発者でなくても移行できたと書いています。各エージェントの仕事を平易な言葉で説明すると、Claudeが短いセットアップスクリプトを書き、それをノートPCのターミナルから実行する流れでした。スクラッチから始める人向けには、Consoleにテンプレート付きのクイックスタートもあるとのことです。

試作の段階から入れるなら、エージェントが無理なく追えるうちはClaude上、追い切れなくなったらManaged Agentsへ、というのが筆者の勧めです。

Managed Agentsに移して効いた3点

記事は、移行の利点を3つ挙げています。ドキュメントと照らすと、それぞれの裏にある仕組みが分かります。

ノートPCを閉じていても動く

スケジュールはデプロイの一部で、ノートPCが閉じていても、オフラインでも走ります。頻度とタイムゾーンはConsoleで、エージェントの指示やツールと同じ画面に置きます。cronをどこかに別で持つ必要がありません。

ドキュメントでは、スケジュールデプロイはcron式とタイムゾーンで定義し、粒度は分単位が上限です。仕組みはManaged Agentsのスケジュールデプロイをcronで定期実行するで手順にまとめています。

筆者はもう1点、運用上の利点を書いています。エージェントを手直ししている最中も、定期実行は配備済みのバージョンを使い続けるため、書きかけの編集が翌朝の実行に混ざりません。実行が失敗したときは、Consoleでエージェントの各ステップを開いて確認できます。

全員が同じ記憶を読み書きする

5体と調整役は、1つのメモリストアを共有します。下書きと実際に送ったメールを比べ、その差を「筆者ならこう言う」というメモとして保存します。調べる過程で見つけた情報も、社内ドキュメントと公式サイトから書き込みます。

Henjiの下書きで言い回しを1回直せば、SabakiとNokoriも同じ間違いをしなくなります。

ドキュメントによると、メモリストアはワークスペース単位のテキスト文書の集まりで、セッションにアタッチするとサンドボックス内のディレクトリとしてマウントされます。メモリへの変更はそのつど不変のバージョンとして残り、監査記録と時点指定の復元に使えます。アタッチ時の権限は既定が読み書き可で、読み取り専用も選べます。記事に、エージェントごとにこの権限を分けているかどうかの記載はありません。操作の詳細はManaged Agentsのメモリストアの使い方にあります。

認証情報は保管庫に置く

エージェントはメールとSalesforceに触れます。顧客とのやり取りと社内記録を扱うので、アクセスを絞りたいという動機でした。認証情報は、OAuthのアクセス・リフレッシュトークン、APIキー、個人アクセストークンを保護する保管庫(vault)に置きます。各エージェントのデプロイは、その仕事に必要な保管庫だけを使い、値そのものは見えません。取り消しは1操作です。

ドキュメントの記述とも合います。環境変数型の認証情報は、サンドボックスの中では不透明なプレースホルダとして保持され、外向きのリクエストを出すときに本物の値へ置き換えられます。値はAPIの応答にも返りません。取り消しは、保管庫か認証情報を削除する形です。

想定外の案件はClaude Tagに渡す

下書きを読んで送るか、更新されたSalesforceを眺めるだけで済む案件が大半です。ただし、アップグレードの経路や購入ルートの整理、他チームへのエスカレーションは、次の一手が要ります。ここでエージェントは待たずに、案件をClaude Tagに渡します。

Claude Tagは、SlackワークスペースにClaudeがメンバーとして参加する機能です。チャンネルにいる人も、エージェントも、@Claudeを付けて依頼すると、Claudeがスレッドで作業します。筆者の運用は次の流れです。

記事のスレッド例では、火曜日に「顧客の返信」と「ディールデスクのチケット回答」を確かめるリマインダーが置かれています。

もう1つの用途があります。Claudeが製品と料金の更新を朝のブリーフとして投稿し、調整役がそれを拾って、必要な変更を共有ナレッジベースへ書き込みます。製品情報が変わると、下書きの元ネタも自動で追随する形です。

Claude Tagのドキュメントでは、提供はTeamプランとEnterpriseプランで、Anthropicのファーストパーティ提供に限られます。Free、Pro、Max、Ultraの個人向けプランでは使えません。チャンネルの作業は、組織の利用残高に使用量で課金されるとあります。Slackユーザーの全員がClaudeのシートを持つ必要はないとも書かれています。TagとClaude CodeのSlack連携との違いは、Claude TagとClaude CodeのSlack連携の違いで比べています。

コストと信頼性の設計

毎日走るエージェントは、見ていなくても動くため、無駄が積み上がります。筆者は、よくある失敗を3つ挙げています。

• 指示を書き換えず、既存の指示に足し続ける
• 仕事に要る以上の文脈を渡す
• すべての仕事を、最大のモデルと最高の思考量で回す

効率の大半は、エージェントの分け方で決まるとしています。1体1役なので指示が絞られ、スケジュール起動なので、起きて1回こなして止まります。共有メモリがあるので、1度の修正がどこでも再利用されます。

モデルは仕事の難しさで割り当てる

仕事が決まれば、最も高性能なモデルは要らないことがあります。FuriwakeとShoudanは書かれたルールに従う仕事なのでSonnetです。Sabaki、Nokori、調整役は判断が要るのでOpusです。調整役が最も判断を要するのは、他のエージェントの指示を編集するからで、誤った編集1つが全員に届くためです。

悩ましいのはHenjiです。Sabakiと同じ水準の判断が要りますが、勤務時間中ずっと走り、どのエージェントよりも実行回数が多くなります。毎回Opusで回すのが最も高くつきます。そこでManaged Agentsのadvisorを使い、HenjiはSonnetで動かし、自力で決められない判断に来たときだけOpusに助言を求めます。advisorはHenjiがそこまでにしたことを読み、計画、修正、停止の合図のいずれかを返します。Henjiは下書きを仕上げて、筆者のレビューに回します。

ドキュメントでは、advisorはエージェントのmultiagent設定に置き、typeとmodelの2項目だけを持ちます。ドキュメントの例に沿うと、Henjiのような構成はおおむね次の形です。モデル名はドキュメントの例からそのまま写したもので、記事のHenjiが実際に使う設定値ではありません。

{
  "name": "Reply drafter",
  "model": "claude-sonnet-5",
  "system": "You draft replies. Consult the advisor before hard calls.",
  "multiagent": {
    "type": "multiagent_20261001",
    "advisor": {"type": "enabled", "model": "claude-opus-5-5"}
  }
}

思考量(回答前にモデルがどれだけ考えるか)も、モデルとは別にエージェントごとに設定し、推論が難しいHenjiの返信のような所だけ上げているそうです。モデルの選び分けの理屈は、Managed Agentsのオーケストレーターでコストが下がる2条件、advisorの仕組みはManaged Agentsのadvisorがプライマリスレッドの判断を助ける仕組みが詳しいです。

同じ営業でも、顧客向けとは別の型

営業チームの別の事例が、すでにあります。営業チームが顧客の購入相談に答える窓口を作り直した話は、Managed Agentsで営業の問い合わせ対応を再設計した事例で扱いました。あちらは顧客と直接話すエージェントで、狙いは待ち時間の短縮です。

今回の事例は反対側にあります。エージェントが話す相手は顧客でなく担当者本人で、顧客に届くメールは必ず本人の確認を通ってから出ます。顧客に送るメールは下書きまでで、送信ボタンは筆者が押します。

その分、設計の重心は即答の精度でなく、本人の癖を学習する経路に置かれています。筆者は「ナレッジベースはプロンプトより大事」と書き、下書きを筆者らしくするために、下書き、修正、保存を数百回、低コストで繰り返したそうです。

もう1つ目を引くのが、変更の窓口です。エージェントの指示やシステムプロンプトの変更依頼は、Slackのチャンネルに平易な言葉で書き込み、投稿できるのは筆者だけです。調整役が15分ほどおきにそのチャンネルを見て、依頼を拾って更新します。権限の境界を「誰がチャンネルに書けるか」に置く設計で、指示を書き換えられる経路が1本に絞られます。調整役が全エージェントに影響する以上、この絞り込みは理にかなっています。

筆者が人に勧める3つのこと

記事の締めの教訓は3つです。

• 毎回詳しいプロンプトを書かない。仕事を1度説明し、Claudeに下書きさせ、直し、その直しを覚えさせる
• プロンプトよりナレッジベースを育てる。修正も過去のやり取りもエージェント全員が読み書きできる場所に置き、長いプロンプトの代わりに文脈をそこから取らせる
• Claudeに任せる範囲を早く広げる。当初はナレッジベースの更新と指示の編集を自分で続けていたが、手放しても問題なく動いた

3つ目に筆者は、「信頼できる仕事に対して慎重すぎた」と書いています。

記事に書かれていない点

事例を自分の組織に当てはめるときは、次の点を先に押さえておく必要があります。

• 費用の記載がない。Managed Agentsは料金体系を持つので、毎時間走るエージェントを複数置くと実費は無視できません。構造はManaged Agentsの料金で確かめられます
• 60時間の期間が不明で、手作業換算の見積もりである
• 各エージェントの実行頻度は、Furiwakeの日次、Henjiの毎時間、Nokoriの1日の終わり、調整役の15分ほどおきしか書かれていない(SabakiとShoudanの頻度は不明)
• Managed Agentsはベータで、メモリストア機能は専用のベータヘッダーで呼ぶ。ドキュメントには、メモリストアの呼び出しでManaged Agents用のベータヘッダーと併用すると400エラーになる、とあります
• Claude Tagもベータで、利用はTeamかEnterpriseの組織に限られる

まとめ

営業の個人担当者が、開発者でなくても自分用のエージェント群を持てる例として読めます。再現しやすい部分は、1体1役への分割、共有メモリへの修正の蓄積、役割に合わせたモデル選び、変更依頼の窓口の一本化の4つです。

一方で、数字は筆者本人の換算で、費用は書かれていません。まず試すなら、Claude上のスキルと共有フォルダで1つの仕事から始め、修正が複数のエージェントにまたがるようになった段階で、メモリストアとスケジュールデプロイへ移す順番が、記事の流れに沿っています。