［ビジネスマン向け］Anthropic日本の営業担当者はClaudeエージェント6体でどう働いているか——Managed AgentsとClaude Tagの実践例

2026-10-18

はじめに

　Anthropicは2026年10月16日、日本チームのBDR（見込み顧客の開拓を担う営業職）が複数のClaudeエージェントで日々の業務を回す事例を公開しました。本稿では、役割分担、Claude Managed Agentsへの移行、Claude Tagとの連携、効率化の工夫を解説します。

参考記事

タイトル: How an Anthropic Japan BDR runs his day with a fleet of Claude agents
著者: Shahboz Ibragimov
発行元: Anthropic（Claude公式サイト）
発行日: 2026年10月16日
URL: https://claude.com/ja/resources/articles/how-an-anthropic-japan-business-development-representative-runs-his-day

要点

筆者は業務を5体の実務エージェントと1体の調整役に分け、全体を「仲間（Nakama）」と名付けて運用している。
当初はClaude上のスキルと定期タスクで試作し、数が増えた段階でClaude Managed Agents（ベータ）へ移行した。
エージェントは共有メモリで学びを共有し、認証情報は権限を絞った管理ボールトで保護される。
定型外の作業はSlack上のClaude Tagに引き継がれ、筆者は人の判断が必要な部分の確認に集中している。
週次ログの換算で、約60時間分の作業が削減されたと筆者は試算している。

詳細解説

手作業が残っていた営業の朝と、移行のきっかけ

　筆者は、日本企業にClaudeでの業務自動化を提案する立場にありながら、今年の前半までは自身の業務の多くが手作業だったと振り返っています。毎朝数時間をリード（見込み顧客）の振り分けと選別に使い、日本語や英語でメールを書き、残りの時間でCRM（顧客管理システム）を更新していたものの、更新は1日以上遅れることも多かったといいます。現在は、始業前にエージェントが大半を準備し、筆者はそれを確認する形に変わりました。

　最初のワークフローは、作業を1つずつClaudeに渡し、誤りを直し、その修正を保存するという素朴なものでした。それが次第に複数のエージェントへ育ちましたが、同僚に共有する手段はスキルとMarkdownファイルをまとめたzipファイルしかなく、受け取った側は設定の質問に答える手間が必要でした。また、1つのスキルを複数のチャットから編集していたため、自分でも変更履歴を追いにくくなっていたといいます。

　そこで筆者は、各エージェントを1か所で定義し、変更履歴を確認できる環境としてClaude Managed Agentsを試しました。当初は「スケジュールやツール、認証情報ボールトの話が出てくるので開発者向けだろう」とためらったものの、実際には各エージェントの仕事を平易な言葉で説明し、Claudeが書いた短いセットアップ用スクリプトをノートPCのターミナルで実行するだけで済んだと述べています。ゼロから始める場合は、Consoleにテンプレート付きのクイックスタートも用意されています。

　開発者ではない営業職が、自分の業務を自分で自動化した事例である点が、本稿としては最も注目したいところです。システム部門に依頼せずに現場で改善を回せる形は、中小企業でのAI活用を考えるうえでも参考になると思います。

「仲間（Nakama）」の設計——1エージェント1業務

　筆者は業務を複数のエージェントに分け、それぞれに明確な仕事を1つだけ与えました。責任を1つに絞ると、各エージェントの挙動を理解しやすく、問題が起きた際にも追跡しやすいためです。主に日本語で作業することから、エージェントには日本語の名前を付けています。

フリワケ（振り分け）: 毎日の問い合わせを読み、件数・優先度・当日の出勤状況を考慮してチームの担当者に割り振ります。終了時には専用のSlackチャンネルに、全リードの受付と割り当ての結果を報告します。
サバキ（捌き）: 筆者に割り当てられたリードを評価し、事前に決めた基準で分類して、分類ごとの次の行動（セルフサービスへの案内、個別の初回メールなど）を実行します。Salesforceのリード情報を更新し、初回メールの下書きも作成します。
ヘンジ（返事）: 1時間ごとに受信箱を確認し、返信が必要な顧客メールに対して、スレッドに合わせて日本語または英語の返信案を用意します。筆者は確認・修正してから送信します。
ショウダン（商談）: 最近の顧客とのやりとりを読み、Salesforceの商談情報を更新して、手入力なしで最新の状態を保ちます。
ノコリ（残り）: 終業時にカレンダーを確認し、添付された会議の文字起こしを読んで要約を作り、フォローアップのメールを下書きします。

　各エージェントは決められたスケジュールで動きます。加えて6体目の「調整役」が、いわば運用マネージャーとして、実行の合間に各エージェントの指示と共有ナレッジベースを更新します。筆者が働き方を変えたいときは、専用のSlackチャンネルに平易な言葉で要望を書き込み、調整役が約15分おきにそれを拾って反映します。指示やシステムプロンプトの変更を依頼できるのは筆者だけに限定されています。

　人間の組織で言えば「職務分掌」を明確にした設計と読めます。1つのエージェントに多くを任せるより、役割を分けた方が誤りの原因を特定しやすいという考え方は、AIに限らず業務設計一般に通じると考えられます。

まずはClaude上で試作する

　筆者は、最初からManaged Agentsを使う必要はないと述べ、全体をまずClaude上で次の3つの要素で試作しました。

エージェントごとのスキル: 1つの仕事のための指示書です。
スキルごとの定期タスク: 手動で実行しなくて済むようにするための仕組みです。
ノートPC上の共有フォルダ: 全スキルが学びを書き戻すナレッジベースです。自分が下書きした内容と実際に送った内容の差分や、調査中に見つけた新しい情報が蓄積されます。

　Managed Agentsへの移行後は、スキルがエージェントのシステムプロンプトに、定期タスクがデプロイ上のスケジュールに、共有フォルダがメモリストアに置き換わりました。変更の依頼は引き続き平易な言葉で行いますが、窓口が1つのSlackチャンネルにまとまり、指示の変更ごとに新しいバージョンとして番号付きで履歴が残るようになったといいます。筆者は、管理しきれないほどエージェントが増えた時点で移行することを勧めています。

　小さく試して効果を確かめ、規模が大きくなったら管理基盤に移すという順序は、導入のハードルを下げる進め方だと思います。最初から本格的な基盤を整えようとすると、検討だけで止まってしまうことも少なくないためです。

Claude Managed Agentsで得られた3つの利点

　筆者は、Managed Agentsで特に重要だった点として次の3つを挙げています。

バックグラウンドでの実行: ノートPCを閉じていても、オフラインでも、エージェントはスケジュールどおりに動きます。実行頻度とタイムゾーンはConsoleで指示やツールと並べて設定でき、別途cronジョブ（定期実行の設定）を管理する必要はありません。実行に問題があればConsoleで各ステップを確認できます。また、変更を試している間も、定期実行はデプロイ済みのバージョンを使い続けるため、編集途中の内容が翌日の実行に混ざることはありません。
共有メモリと修正からの学習: 全エージェントが同じメモリストアを読み書きするため、互いの学びを活用できます。エージェントは自分の下書きと筆者が実際に送ったメールを比較し、その差分を「筆者ならこう書く」というメモとして保存します。社内資料や公式サイトで調べた新しい情報も蓄積されます。ヘンジの下書きで言い回しを一度直すと、サバキやノコリも同じ誤りをしなくなるといいます。
権限を絞った管理ボールトでの認証情報保護: エージェントはメールやSalesforceにアクセスしますが、顧客とのやりとりや社内記録を扱うため、筆者はその権限を管理下に置きたいと考えました。OAuthのトークンやAPIキーなどの認証情報は管理ボールトに保管され、各エージェントは仕事に必要なボールトだけを使います。エージェント自身は認証情報を直接見ることがなく、アクセスは1操作で取り消せます。

　3点目は、業務でAIエージェントを使う際に多くの企業が気にする部分ではないでしょうか。どのエージェントが何にアクセスできるかを明示的に絞れることは、社内の承認を得るうえでも説明しやすい材料になると考えられます。

定型外の作業はClaude Tagへ引き継ぐ

　仲間が作る成果物の多くは、筆者が受信箱で下書きを読んで送るか、更新されたSalesforceの記録を確認するだけで済みます。一方で、アップグレードの方法や購入経路の確認、他チームへのエスカレーションなど、追加の対応が必要なものもあります。

　そうした案件では、エージェントは筆者を待たずにClaude Tag（ベータ）へ引き継ぎます。Claude Tagは、Slackワークスペースのメンバーとして設定されたClaudeで、参加しているチャンネルでは人間でもエージェントでも「@Claude」とタグ付けすれば依頼でき、スレッド内で作業を進めます。筆者の環境での流れは次のとおりです。

エージェントが対応事項を専用チャンネルに投稿し、Claudeをタグ付けする
Claudeがスレッドを読み、社内ルールや適用される条件を確認して選択肢を整理し、必要な文面を下書きする
確認や承認が必要な段階では、筆者をタグ付けする
顧客や他チームの返答待ちの場合は、決まった日に確認するリマインダーを自分で設定する
期日が来ると状況を確認して同じスレッドに報告し、催促が必要なら文面を下書きして筆者に送信を依頼する

　記事中の例では、Claudeが火曜日にリマインダーを設定し、顧客の返信と社内の契約窓口（ディールデスク）のチケット回答を確認していました。また、Claudeは毎朝、製品や価格の更新情報をまとめて投稿し、調整役がそれを読んで共有ナレッジベースに反映しています。

　Claude Tagについては、6月のベータ公開時の内容もあわせて参照いただくと、全体像がつかみやすいと思います。定型処理はスケジュール型のエージェント、例外対応は会話型のClaude Tagと使い分けている点が、この事例の構成上の要だと読めます。

働き方の変化——判断が必要な部分に集中する

　問い合わせへの返信準備やCRMの更新をClaudeがほぼ担うようになり、筆者の役割は人間の判断が必要なものを確認することに変わりました。各エージェントの担当範囲は文書化されたルールで定義されており、価格に関する質問、慎重な対応が必要な顧客、意図があいまいな依頼などは筆者に回されます。ヘンジ、サバキ、ノコリが作るメールの下書きには、冒頭に状況の短い要約が付いているため、スレッド全体をたどらずに要約を読み、確認・修正して送信できるといいます。

　筆者によれば、仲間が処理した作業の週次ログをもとに、各作業を手作業でかかっていた時間に換算すると、約60時間分の作業が削減されているとのことです。空いた時間は、顧客との会話、アウトバウンド（能動的な営業）の戦略、部門横断のプロジェクト、同僚のエージェント構築支援など、エージェントには（まだ）難しい仕事に充てています。

　なお、この60時間は筆者自身による換算値であり、確認作業にかかる時間をどう差し引いているかは記事からは読み取れません。数字そのものより、「何を人に残し、何を任せるか」の線引きを文書化している点の方が、他社でも再現しやすい要素だと本稿としては考えています。

コストと信頼性を保つ設計とモデルの使い分け

　定期実行のエージェントは誰も見ていなくても毎日動くため、無駄があるとコストと信頼性の両面で積み重なります。筆者は、よくある失敗として次の3つを挙げています。

既存の指示を更新せず、継ぎ足していく
仕事に必要な以上の文脈をエージェントに与える
すべての仕事を最大のモデル・最高の思考レベルで実行する

　効率を保つ要因の多くは全体の設計にあり、1エージェント1業務なので指示が絞られ、スケジュールで起動して処理が終われば停止し、メモリを共有しているので一度の修正がすべてに生きる、と筆者は説明しています。

　もう1つの大きな要因がモデルの選択です。各エージェントの割り当ては次のとおりです。

Sonnet（小型モデル）: 文書化されたルールに従うフリワケとショウダン
Opus（大型モデル）: より多くの判断を要するサバキ、ノコリ、調整役。特に調整役は他のエージェントの指示を編集するため、1回の誤った編集が全体に波及する可能性があり、最も高い判断力が必要とされています。
アドバイザー戦略: ヘンジはサバキと同程度の判断が必要ですが、勤務時間中ずっと最も頻繁に動くため、毎回Opusで動かすと最も高くつきます。そこでヘンジ自体はSonnetで動かし、自分で決められない場面でだけOpusに助言を求めます。助言役はそれまでの作業を読み、計画、修正、または中止の指示を返し、ヘンジが下書きを仕上げます。

　さらに筆者は、各エージェントの思考レベル（回答前にどれだけ考えるか）をモデルとは別に設定し、ヘンジの返信のように推論が難しい部分だけ引き上げています。すべてを最上位モデルで動かすのではなく、仕事の性質に応じて配分する考え方は、人員配置にも似ています。利用料金を抑えたい企業にとっては、特に参考にしやすい部分だと思います。

筆者が伝えたい3つの学び

　記事の最後で、筆者は自分のエージェント群を作る人に向けて次の3点を挙げています。

毎回詳細なプロンプトは不要: 仕事を一度説明し、Claudeに下書きさせ、それを直し、修正を保存させればよい。
プロンプトよりナレッジベースが重要: 修正や過去のやりとりは全エージェントが読み書きできる場所に保存されるため、Claudeは長いプロンプトではなくそこから文脈を得る。自分らしい文面になるまでに、下書き・修正・保存という低コストな反復を数百回重ねた。
早めにClaudeへ任せる範囲を広げる: ナレッジベースの更新や各エージェントの指示の手動編集など、自分がやるべきと思っていた作業も、任せてみると問題なく機能した。今ではエージェントが学びを自らナレッジベースに書き込み、調整役が指示を更新している。筆者は「信頼して任せられる仕事に対して慎重になりすぎていた」と振り返っている。

　2点目の「数百回の反復」という具体的な数字は、AIが最初から自分の文体で書けるわけではないことを率直に示していると受け止めています。導入初期は修正の手間がかかる前提で、少しずつ育てていく姿勢が大切だと思います。