日本の Anthropic BDR が Claude Managed Agents を活用して日々の業務をどのように運営しているか
Claude Managed AgentsとClaude Tagを活用して、受信案件の処理とバイリンガル顧客メールの作成を効率化するビジネス開発担当者。
Anthropic 日本チームの事業開発担当者としての私の仕事は、Claude によってワークフローをいかに簡素化・自動化できるかを日本企業に示すことです。しかし、今年の初めまで、私自身のワークフローのほとんどはまだ手動でした。 以前は毎朝2時間ほど、リードの振り分けや見込み度の評価を行い、その後、日本語または英語でメールを書いていました。残された時間に、CRM の更新を進めていましたが、多くの場合、1 日かそれ以上遅れていました。 現在は、その大部分をエージェントが始業前に準備し、私はそれを確認しています。
最初に構築した Claude を使ったワークフローはかなり粗削りなものでしたが、十分に役目を果たしてくれました。 業務を一つずつ Claude に任せ、間違えた部分を修正し、その修正内容を保存していました。 時間の経過とともに、それはいくつかのエージェントへと発展し、それぞれが異なる定型業務を担当するようになりました。
その話はすぐに広まり、チームメンバーから、自分たちでも構築できるように私のプロンプトやスキルを共有してほしいと頼まれるようになりました。 私が共有できたのは、自分のスキルをまとめた ZIP ファイルとナレッジベース内のいくつかの Markdown ファイルだけでした。チームメンバーは、それらを Claude にアップロードしたうえで、一連の初期設定の質問に答えなければ利用を開始できませんでした。自分の設定も、次第に管理しきれなくなっていました。各エージェントは、スキル、スケジュールされたタスク、共有フォルダで構成されていました。変更する際はその時に開いていたチャットで Claude に依頼していたため、同じスキルが多くの異なる会話から編集される状態になっていました。
各エージェントを一か所で定義・管理し、自分が加えた変更をすべて追跡できるようにしたいと考えていました。そこで、Claude Platform 上の Managed Agents 基盤である Claude Managed Agents (opens in new tab)（ベータ版）を試すことにしました。
最初は、試してみることに躊躇しました。 ドキュメントではスケジュール、ツール、認証情報ボールトについて説明されていたので、営業担当者である私は、Managed Agents は必要なインフラストラクチャを構築・維持できる開発者向けのものだと思い込んでいました。それでも試してみたのは、エージェントがすでに存在しており、移行するだけで済んだからです。
結果的に、開発者である必要はありませんでした。各エージェントの業務をわかりやすい言葉で説明すると、Claude が短いセットアップスクリプトをいくつか作成し、私はそれをノートパソコンのターミナルから実行しました。（ゼロから始める場合は、コンソールに既製のエージェントテンプレートを備えたクイックスタートも用意されています。）それ以来、私が管理しなければならないインフラストラクチャはなくなりました。
この記事では、エージェント群の設計とプロトタイプ作成から、Managed Agents への移行、Claude Tag による例外対応、導入によって私の働き方がどう変わったのか、そして反復的な手作業を自動化する独自のエージェントを構築したい営業担当者へのアドバイスまで、順を追って紹介します。
エージェント群の設計
私は、ワークフローを複数のエージェントに分割し、各エージェントに明確な役割を 1 つずつ割り当てました。役割を 1 つに絞ることで、各エージェントの動作を把握しやすく、追跡もしやすくなります。特に何か問題が起きたときに効果的です。また、エージェントのほとんどが日本語で業務を遂行するため、各エージェントに日本語の名前も付けました。 これらのエージェントは総称して Nakama と呼んでいます。「クルー」、つまり仕事を共にする仲間という意味を込めています。
- 最初に動き出すのは Furiwake（「振り分け」）です。毎日の受信キューを読み取り、リードの数と各リードの優先度のバランスを取りつつ、その日の出勤者を確認したうえで、各リードをチーム内の適切な担当者に割り当てます。これにより、私たちが 1 日の業務を始める前に、すべてのリードの担当者が決まります。各実行の最後に、専用の Slack チャンネルにレポートが投稿されます（受信したすべてのリードと、割り当てられたすべてのリード）。これにより、私は引き継ぎの状況を追跡できます。
- Sabaki（「捌き」）は、私に割り当てられたリードをトリアージします。各リードを評価し、事前に設定された基準に照らして分類したうえで、そのカテゴリに定められた次のステップ（セルフサービスへ案内する返信の下書き作成、カスタマイズした最初のメールの作成など）を実行し、Salesforce のリードレコードを更新して、初回コンタクト用メールの下書きを作成します。下書きの内容は、Nakama の共有ナレッジベースから取得されます。これは、すべてのエージェントが読み書きするメモリストア (opens in new tab)です（詳細は後述）。
- Henji（「返事」）は、1 時間ごとに受信トレイをスキャンして返信が必要な顧客メールを探し、Sabaki と同じナレッジベースを活用して、スレッドに応じて日本語または英語で返信の下書きを作成します。下書きの確認、編集、送信は、私自身ができます。
- Shoudan（「オポチュニティ」）は、顧客との最近のやり取りを読み取り、更新内容を Salesforce に反映します。これにより、手動でデータを入力することなく、オポチュニティの記録を常に最新の状態に保てます。
- Nokori（「残り」）は 1 日の終わりに実行されます。カレンダーをスキャンし、添付された会議のトランスクリプトを読み取り、各会議を要約して、フォローアップの下書きを作成します。これも同じ知識ベースを基に行います。
各エージェントは、スケジュールに従って動作します。 6 番目のエージェントである Nakama のコーディネーターが、フリートの運用マネージャーを務めています。 実行の合間に、エージェントの指示と共有知識ベースを更新します。 エージェントの動作を変更したいときは、Nakama の Slack チャンネルに平易な言葉で希望する内容を書き込みます。 エージェントの指示やシステムプロンプトの変更依頼を投稿できるのは、私だけです。 コーディネーターが 15 分ほどおきにそのチャンネルを確認し、依頼を受け取り、更新を行います。
Claude でフリートのプロトタイプを作成
開始するのに、Managed Agents は必要ありません。 まず、以下の要素を使って、フリート全体を Claude でプロトタイプ化しました。
- エージェントごとのスキル：1 つの業務に対する指示。
- スキルごとのスケジュールされたタスク：手動で実行する必要はありません。
- 知識ベースとしてのノートパソコン上の共有フォルダ：各スキルが学んだ内容をここに書き戻します。下書きした内容と私が実際に送信した内容の違いや、その過程で新たに見つけた情報などです。
Managed Agents では、スキルはエージェントのシステムプロンプトに、定期実行タスクはデプロイ時のスケジュール設定 (opens in new tab)に、共有フォルダーはメモリストアにそれぞれ置き換わりました。今も変更は平易な言葉で依頼していますが、現在はすべて 1 つの Slack チャンネルで行っています。エージェントの指示に対する変更はそれぞれ新しいバージョンとして保存されるため、各エージェントは指示の履歴を番号付きで保持します。 まずは Claude から始め、無理なく管理できる数を超えたら、エージェントを Managed Agents に移行することをお勧めします。
Claude Managed Agents でフリートを運用
Managed Agents で得られたもののうち、私のワークフローにとって特に重要だった点は次の 3 つです。
エージェントはバックグラウンドで実行可能
エージェントは、ノートパソコンが開いているかどうかにかかわらず、オフライン時でも、設定されたスケジュールに従って実行されます。 スケジュールは、各エージェントのデプロイの一部です。 Claude でもスキルのスケジュール実行は可能でしたが、それらはすべて自分のアプリ側で設定・管理するタスクでした。Managed Agents では、デプロイ済みエージェントの指示やツールと並んで、コンソール上で実行頻度やタイムゾーンを設定できます。そのため、別途 cron ジョブを管理する必要はありません。実行に問題が生じた場合は コンソールで開き、エージェントが実行した各ステップを確認できます。 エージェントの変更を試している間も、スケジュール実行では引き続きデプロイ済みのバージョンが使用されるため、編集途中の内容が翌日の実行に反映されることはありません。
Nakama は 1 つのメモリを共有し、私の編集から学習する
すべてのエージェントが同じメモリストア (opens in new tab)を読み書きするため、どのエージェントでも、他のエージェントが学習した内容を利用できます。エージェントは、自分たちが書いた下書きと私が送信したメールを比較し、それぞれの違いを、私ならどう表現するかについてのメモとして保存します。 また、回答を調べる過程で社内ドキュメントや公式ウェブサイトから新たに見つけた情報も保持します。 Henji の下書きで表現を一度修正すれば、Sabaki と Nokori も同じ間違いをしなくなります。
認証情報は、権限範囲が制御されたマネージドボールトに保管
エージェントは私のメールや Salesforce の記録にアクセスできますが、これは顧客の会話や会社の記録であるため、アクセスを制御したいと考えていました。 認証情報はマネージドボールト (opens in new tab)に保存されています。ボールトは、OAuth のアクセストークンやリフレッシュトークン、API キー、個人用アクセストークンなど、外部サービスへのログイン時にエージェントが使用する認証情報を保護します。 各エージェントのデプロイでは、ジョブに必要なボールトのみが使用され、エージェントが認証情報を目にすることは一切ありません。また、アクセス権は 1 つのステップで取り消せます。
次のステップを Claude Tag に任せる
Nakama が作成する仕事の大半は、受信トレイにある下書きを読んで送信するか、Salesforce の更新済み記録をざっと確認するだけで済みます。 しかし、案件によっては追加対応が必要です。たとえば、アップグレードや購入に向けた進め方を検討したり、別のチームに問題をエスカレーションしたりするケースがあります。
これらについては、エージェントは作業を止めて私を待つことはありません。エージェントは、その項目を Claude Tag (opens in new tab)（ベータ版）に引き渡します。Claude Tag は、Slack ワークスペースのメンバーとして設定された Claude です。Claude が参加しているチャンネルにいる人なら誰でも（人間でも私のエージェントでも）、依頼内容を添えて @Claude をタグ付けできます。Claude はその依頼を受け取り、スレッド内で対応します。いったんワークスペースで設定すれば、新たに覚えることは何もありません。Claude へのタグ付けは、同僚をタグ付けするときと同じ方法で行います。
私の環境では、次のように動作します。エージェントが Nakama の Slack チャンネルにアクションアイテムを投稿し、Claude をタグ付けします。Claude は、スレッドを読み取り、適用される規則や条項を確認し、選択肢を整理して、必要な内容の草案を作成します。 レビューや承認が必要な段階になると、私をタグ付けします。顧客や他のチームが先に返信する必要がある場合は、Claude は決まった日に確認できるように、自らリマインダーを設定します。以下のスレッドでは、顧客から返信があったかどうか、また、ディールデスクがチケットに回答したかどうかを確認するため、火曜日のリマインダーを設定しました。リマインダーの期日になると、Claude は両方を確認し、現在の状況を同じスレッドに投稿します。誰かへの催促が必要な場合は、メッセージの下書きを作成し、送信するよう私をタグ付けします。
Claude は、製品や価格の最新情報をまとめた朝のブリーフも投稿します。Nakama のコーディネーターがブリーフを受け取り、必要な変更内容を共有のナレッジベースに書き込みます。
導入による 1 週間の変化
Claude が受信メッセージへの返信を準備し、（ほぼ）私の手作業なしで CRM レコードを最新の状態に保つようになったため、現在は人間の判断が必要なものをすべて確認することです。明文化されたルールブックで各エージェントの担当範囲を定義しており、料金に関する質問、慎重な対応が必要なアカウント、判断が難しい依頼などは私に回されます。Henji、Sabaki、Nokori が作成するメールの下書きには、状況を簡潔にまとめた要約が冒頭に付いているため、コンテキストを把握するためにメールスレッド全体を追う必要はありません。要約を読み、内容を確認し、必要に応じて修正を加えて送信するだけです。
Nakama が処理する作業の週次ログを確認し、各タスクを手動で行った場合にかかる時間として計算すると、フリートによって約 60 時間の作業が削減されています。こうして確保できた時間は、エージェントがまだ十分にこなせない業務に充てています。顧客との会話、アウトバウンド戦略、部門横断的なプロジェクト、そしてチームメンバーによる独自のエージェント群の構築支援などです。
より効率的なエージェントの設計
スケジュール設定されたエージェントは、私が見ているかどうかにかかわらず毎日実行されるため、無駄がコストと信頼性の両面で積み重なる可能性があります。よくある失敗としては、既存の指示を更新せずに追記を重ねること、エージェントに必要以上のコンテキストを与えること、そしてすべてのジョブを最大規模のモデルで最高エフォートレベルに設定して実行することなどが挙げられます。
エージェントの効率を支えている最大の要因は、フリートの設計そのものにあります。各エージェントは1つの役割だけを担うため、その役割に特化した指示を維持できます。また、稼働するエージェントはスケジュールに従って起動し、処理を一巡したら停止します。さらに、エージェント同士でメモリを共有するため、一度行った修正を全体で再利用できます。
もう一つの大きな要因は、各エージェントがどのモデルで実行されるかです。 エージェントの業務が明確に定義されれば、当社の最も高性能なモデルは必要ない場合もあります。Furiwake と Shoudan は明文化されたルールブックに従うため、当社のより小型のモデルである Sonnet で実行しています。Sabaki、Nokori、そしてコーディネーターには、より高度な判断が求められるため、より大規模なモデルである Opus を利用しています。特にコーディネーターにはそれが最も重要です。他のエージェントの指示を編集する役割を担っているため、1つの誤った変更がすべてのエージェントに波及しかねないからです。顧客のメールはそれぞれ異なるため、Henji には Sabaki と同程度の判断力が必要ですが、同時に業務時間中を通して他のどのエージェントよりも頻繁に実行されます。毎回 Opus で実行するのは最もコストの高い選択肢となるため、Managed Agents のアドバイザー戦略 (opens in new tab)を採用しています。Henji は Sonnet で実行され、単独では下せない判断に直面すると、Opus に助言を求めます。アドバイザーは、Henji がそれまでに行った内容を読み取り、計画、修正、または停止の合図を返します。その後、Henji が下書きを仕上げ、私がレビューできるようにします。また、各エージェントのエフォートレベル（回答する前にモデルが考える時間）はモデルとは別に設定し、Henji の返信のように推論が難しい場合に限ってエフォートレベルを上げています。
学んだこと
独自のフリートを構築するすべての方に伝えたい 3 つのこと。
- 毎回、詳細なプロンプトを用意する必要はありません。 作業内容を一度説明したら、Claude に下書きを作成させ、必要な修正を加え、その修正内容を今後に生かせるよう記憶させます。
- プロンプトよりも、知識ベースの方が重要です。 修正内容や過去のやり取りは、どのエージェントからも読み書きできる場所に保存されます。そのため、Claude は長いプロンプトではなく、その保存された情報からコンテキストを取得します。下書きの作成、修正、保存という低コストのサイクルを数百回繰り返すことで、下書きが私らしい文体になりました。
- 早い段階から Claude に任せる。 最初は、知識ベースの更新や各エージェントの指示の手動編集など、自分がやる必要があると思っていた作業を続けていました。 手放してみると、どちらも問題なく機能しました。 現在では、エージェント自身が学んだことを知識ベースに記録し、私が平易な英語で指示を出せば、コーディネーターが他のエージェントの指示を更新してくれます。エージェントに安心して任せられる仕事に対して、慎重になりすぎていたのです。