「その基盤は、あなたの製品の品質を決めるか」 ― Claude Managed Agentsで作る3社の実装論

AIエージェントを製品に組み込むとき、実行基盤（ハーネス）を自社で作るべきか、マネージドサービスを使うべきか。この問いに対して、抽象論では、なく実際の判断と数字で答えた座談会がAnthropicから公開されました。

登壇したのは、Claude Managed Agentsを使って製品を構築している3社の創業者です。

• Sahaj氏：会議プロダクト。会議の前・中・後を通した体験を設計

• Mihir氏：営業チーム向けエージェント。アカウントごとに常時稼働するエージェントが中核

• Todd氏：プロダクトアナリティクス。アプリケーションに組み込み、ユーザーの実際の挙動を捕捉

3社が使っている機能は、それぞれ異なります。Sahaj氏は、Outcomes、Mihir氏は、メモリ、Todd氏は、サンドボックス。同じ基盤の別々の側面を使っているため、結果的にManaged Agentsの機能全体が立体的に見える構成になっています。

以下、実装の詳細と、そこから読み取れる論点を整理します。

1. それぞれが何を作っているのか

1-1. 会議の「前」と「後」にエージェントを置く

Sahaj氏の問題設定は明快です。ほとんどの人は会議を、文字通り会議が行われている時間だけで考えている。しかし、エージェントが最も面白くなるのは、その前後だという主張です。

• これから行う会話にどう備えるか

• その会話で本当に達成したいことを、確実に起こすには

• 会議後に実行されるべきことを、どう実行するか

同社は、Managed Agentsを使い、準備側の「ブリーフ」機能と、会議後の作業を処理するタスク自動化の双方で新機能を構築しています。

1-2. Watchtower ― アカウント横断のロールアップ

Mihir氏の製品は、営業チーム向けエージェントで、中核にあるのはすべてのアカウントに、常時稼働してメモリを構築し、案件を前進させる方法を考えるエージェントがいるという発想です。

ただし、営業には、単一アカウントに閉じないワークロードが多数あります。担当者なら「今日攻めるべきトップ5アカウントは何か」、マネージャーなら「来四半期にどの案件をフォーキャストすべきか」といった問いです。

そこで構築したのが、Watchtower。アカウント横断のレポーティング、集計、ロールアップを担う製品です。

重要なのは、このエージェントが、アカウント単位のエージェントとは形が大きく異なる点でした。必要なツールも機能も別物です。

現在では最も使われている機能の一つとなり、製品の他の多くの部分も支えているとのことです。

1-3. コードベースと現実を接続する

Todd氏の製品は、プロダクトアナリティクスです。アプリケーションに統合し、ユーザーが実際に何をしているかを捕捉して、改善のためのデータをフィードバックします。

課題は、開発速度の上昇です。人々が速く動くほど、アプリケーションへの計測実装は難しくなり、アナリティクスが実態からどこでズレているかの把握も困難になる。

そこで、同社は、プラットフォームの前段に新しいエージェントを置きました。コードベースを統合し、コードベースが何をしているかと、実際に何が起きているかを接続する役割です。

Managed Agentsは、コードベースのバージョンをスナップショットし、アプリケーションで実際に起きていることと比較し、インサイトや修正案を能動的に送る、という一連の処理に使われています。

2. Outcomes ― 「正しくないなら、何も見せない」

2-1. 誤った情報は、情報がないより悪い

Sahaj氏が、Outcomes機能を重視する理由は、ブリーフ機能の性質から来ています。

ブリーフは、これから話す相手が誰か、なぜ関連があるか、何を話す合意だったか、会議で得るべきものは何か、数週間前に忘れていた前提文脈は何か——といった情報を提示するものです。

そして、同氏はこう指摘します。

問題は誤りのケースです。Tomという人物と話すのに別のTomの情報が出てきたら、それはほとんど破壊的である。会議に入った瞬間に相手について詳しく見ようとして、混乱することになるからです。

したがって、エージェントが正しい結果を出したかを正しく判定し、そうでなければユーザーに何も表示しないと選択できることが、誤った情報を与えるよりはるかに良い、という結論になります。

同氏は、「能動的に役立つものを作るなら、これで問題ない」と述べ、方針を端的にまとめています。

2-2. ルーブリックをどう設計するか

Outcomesは、エージェントにルーブリック（評価基準）を与え、それが満たされるまでエージェントに反復させる仕組みです。同社の設計は2層になっています。

客観的に検証可能な部分

• 該当する人物の正しいLinkedInを取得できているか

提示のされ方に関する部分

• 情報がざっと目を通せて読みやすい形になっているか

• 会議前に5ページの資料が出てきても誰も読まない

• 順序が誤っていれば——まず相手が誰か、次になぜ会うのか、そして何をすべきか、という順でなければ——やはり難しい

UXの観点からユーザーに体験してほしい要素をそれぞれルーブリックの一部に変換し、そこに向けて改善を重ねる、というアプローチです。

2-3. 独立した検証エージェントという設計

実装上のポイントは、実行時（ランタイム）に走ることです。同社はこれを会話の24時間前に実行しており、評価のための十分な時間窓を確保しています。

そして、最も重要なのが、検証の独立性です。

独立して作業するエージェントであっても、LinkedInを見て、メールを見て、カレンダー招待を見て、これはおそらく正しかったかどうかを自ら判断できる。同氏は人間の類推も添えています——初対面の相手でも、LinkedInを見て「なぜかは分からないが、この人物ではない気がする」と判断できる、と。

Managed Agentsでは、独立したコンテキストウィンドウと独立した検証エージェントが使われ、それがOutcomesに組み込まれています。

エージェントループ自体の一部にしてしまうのとは、質的に異なる、という説明です。

副次効果としてフィードバックループも駆動されます。その場で評価できるほど、最初のエージェントループに知見を織り込めるようになり、最初から正しく出せるようになる、という循環です。

3. メモリ ― 「アカウント×組織」の2×2

3-1. 企業固有の概念という難問

Mihir氏が挙げた難しさは、企業ごとに固有の概念が多すぎることです。営業チームが所有権をどう定義するか、フォーキャストをどうやるか、案件がどう進むか——すべて会社ごとに違います。

さらに、元データが厄介です。

この状況で「来四半期にフォーキャストすべき案件は何か」という重要な問いに正しく答えるには、多くの前提が必要になります。

3-2. 組織全体のメモリで初期設定を不要にする

同社のアプローチは、ユーザーが製品を使うなかでこれらの概念を学習し、組織全体（org-wide）のメモリに保存するというものです。これにより他のユーザーにもより良い結果を返せるようになります。

利点は導入時のコンフィグレーションが不要になることです。最初に大量の設定作業をする代わりに、システムが概念を素早く拾い上げていく。初回の質問時にはユーザーに確認質問をして明確化し、その結果を保存する、といった動きもします。

3-3. コードを書いてファンアウトする

もう一つ、Managed Agentsが役立っている点として挙げられたのが、複雑なクエリへの対応です。

500件の案件があり、より深い分析をしたい場合、基本的なフィルタリングだけでは足りない。そこでシステムはコードを書いて質問に答え、プログラム的なツール呼び出しも行います。候補セットを絞り込み、そこから個々のアカウントで作業する独立エージェントに処理をファンアウトし、結果をロールアップして戻すという構造です。

3-4. メモリの4象限

司会者の整理により、メモリ構造が明確になりました。

アカウント単位のメモリ：各アカウントにライフサイクル全体を通じて永続稼働するエージェントがいる。アカウントの文脈を構築し、ロールアップ可能な概念を拾い上げる

アカウント横断のメモリ：フォーキャストの仕組みや組織内のプロセスなど。個別アカウントでは重要度が低いが、Watchtowerの文脈では重要になる

同氏は、これを2×2として説明しています。

3-5. 自作とmanagedの使い分け

ここで重要な区別が示されました。アカウント単位のエージェントは、Managed Agents上にはなく、メモリアーキテクチャも同社が完全に独自に所有しているとのことです。

理由は明確です。アカウントごとのメモリは中核であり、大量のカスタマイズが必要になる。永続的で、詳細で、時間とともに破損しうる。効率的にクエリできるようインデックスする必要もある。だから自社で管理する。

一方、フィールドの意味、組織の仕組み、ユーザーの好みといったメモリは、機能する必要はあるが他社と異なる動き方をする必要はない。そこはマネージドメモリが多くを解放してくれる、という整理です。

そして、Watchtowerというマネージドエージェントが、自社構築したエージェント群のメモリにアクセスする形になっています。「今日取り組むべき5つのアカジェントは何か」という問いは、100件のアカウントのメモリの関数であると同時に、ユーザー自身の優先順位づけや組織の仕組みに関する知識の関数でもある。前者は自社メモリ、後者はマネージドメモリが担う、という分担です。

なおこの構造は、対象ユーザーの拡大にも効いています。個人担当者だけでなく、5人の担当者を管理する営業リーダーは、500アカウントに責任を持つことになり、そこでも有用だと述べられました。

4. サンドボックス ― ソースコードを扱う責任

4-1. なぜサンドボックスが必須なのか

Todd氏の用途は、サンドボックスの必要性が最も分かりやすいケースです。顧客のソースコードをスナップショットするからです。

リスクは具体的です。エージェントとやり取りする人が誰かのソースコードにアクセスできてしまえば、シークレット（機密情報）を取得できる可能性がある。そのコードに対して、どのツールが露出しているか、どんなデータが送られるか、どんなアクションが起きるかにも細心の注意が要ります。

最終的にやり取りの結果はプルリクエストの生成と、実際のリポジトリへのプッシュになるため、扱いの重みはさらに増します。

4-2. 「自作したが、コアではなかった」

同氏の判断は率直です。

ただ動けばよい。安全でセキュアである必要があり、中小企業から大企業まですべてが信頼できる必要がある。Managed Agentsでそこにかなり速く到達できた、というのが結論です。

4-3. 3種類のセッション

同社のセッションは用途別に分かれています。

• オーバーナイトのバッチ処理：夜間に問題を探す。大規模なファネル変化などはリアルタイムでやりたくないので、cronプロセスで回す

• リアルタイムのクエリ応答：質問が来たとき、ソースコードを素早く参照して真実の源を理解し、より正確に答える

• PRトリガー：ソースコードに変更が入りプルリクエストが提出されるたび、マネージドエージェントのセッションを起動してコードをレビューし、何が変わったかを理解する

PRレビューでは、軽量なUXレビューも適用し、率直に言って質の悪いUXがそもそもコミットされるのを防いでいるとのこと。マージ後には、アナリティクスの更新や計測の作成が必要かを判断し、提出されたPRの上に自社のPRを重ねて発行し、正確な計測を維持します。

夜間の処理では、前日に何が起きたか、ファネルのコンバージョン率が一晩で落ちていないか、30日間でも週次で微妙な劣化がないかを見ます。劣化があれば、4週間前に何が変わったかを遡って修正案を提示する。エージェント同士・人間との会話についても、通常よりエラー率が高くないかを見て、プロンプト修正を提案します。

目指すゴールは明確です。

5. 自作か、マネージドか ― 4つの判断基準

座談会の核心が、この論点です。

5-1. 基準1：コア能力かどうか

Sahaj氏の基準はシンプルです。構築している機能のコア能力の一部かどうか。

ブリーフのような新機能では、ハーネス自体はその機能のコア能力ではない。重要なのは「エンドユーザーに必要な価値を届けられているか」だけです。

一方で、たとえば、完全に音声制御されるJarvis的なシステムを作るなら、ハーネス自体が、コア能力になり得るし、まったく新しい能力を届けられるかもしれない。

品質を規定するものでないなら買う。規定するなら自分で作る。同氏は、Jarvis的な音声制御チーフオブスタッフを作るなら「自前のハーネスを持つ確率はかなり高そうだ」としつつ、だからといってすべてを自作するわけではないとも述べています。

5-2. 基準2：速度が最重要な局面

Todd氏が挙げたのは、急速な実験と探索の局面です。

プロダクトの初期には、プロダクトマーケットフィットの検証、製品を特別にする中核機能の検証が必要になる。全員が難しい問題を、従来型より10倍良い方法で解こうとしている。その問題を解くために自前のインフラは必要ない、という主張です。

いつか解く問題が自前のインフラを必要とする日が来るかもしれない。より細かい制御が必要だったり、特定領域のコストや運用面で望む水準に届かなかったり。だが初期には、イノベーションし、機能を素早く顧客の前に出し、非常に速く変更できることが重要である、と。

5-3. 基準3：コストが機能実現の条件になる場合

Sahaj氏の3つ目は、コストや制御の最適化がそれなしには作れないものを可能にする場合です。

5-4. 基準4：実現可能性の検証

Todd氏が追加した4つ目が示唆的です。

5-5. 実際にかかった時間

具体的な数字も共有されました。

Todd氏の場合は、既存の自社製ソリューションがありましたが、問題が出始めて全面的な作り直しが必要と判断し、Managed Agentsと比較検討したところ、立ち上げが速く、自分たちがカバーしようとしていたエッジケースの多くをすでに満たしていた、という経緯でした。

Sahaj氏によれば、作業の大半を占めたのは、ユーザーがその機能に何を求めているかを突き止めることであり、作る・自分で使う・他人でテストする・改善するというサイクルを回す作業でした。それでも2〜3週間で完了したとのことです。

反復対象は、プロンプト、スキル、ツール、そして、ループのオーケストレーション——いつ検索し、いつ取得し、関連部分をどうランキングし、何をユーザーに返し、複数ソースにまたがってどう調整するか。コンパクションなどハーネス構築の他の側面を気にせずに済むことで、本質的な問いだけに集中できた、と述べられています。

6. 評価（eval）― 「定着していないものは、評価しても定着しない」

6-1. フェーズゼロはバイブス

司会者が、Claude Codeの初期にevalがなかったという話に触れると、Sahaj氏が的確な整理をしました。

そして、重要な補足です。

体系的なevalなしに改善を続けようとすれば、人として非常につらいことになる、とも述べています。

6-2. 社内ドッグフーディングの限界

evalの作り方についても、両者から実践的な指摘がありました。

Sahaj氏は、社内で始めてフィードバックを集めるのは簡単だが、自社ユーザーへの過剰適合のリスクがあるとします。そこから外部のユーザーからデータポイントとフィードバックを集める。機能の結果に対するサムズアップ／ダウンがあれば、十分なユーザー数でかなり早く相応のevalセットが作れる、という見立てです。

そのうえで、evalを種類別に分けます。

• 回帰（リグレッション）用のコホート

• 難易度の高いシナリオ用のコホート

• データの分割ごとのコホート

• エージェントに割り当てられるタスク種別ごとのコホート

• それぞれに割り当てるルーブリック

そして、オフラインのevalのルーブリックとOutcomesのルーブリックを揃えられるほど理想的だと述べています。

Mihir氏は、さらに踏み込んだ課題を共有しました。同社も自社の営業チームがドッグフーディングしていたが、実際の顧客を代表していない。そこで有効だったのが——

以前のevalは抽象化されすぎていて代表性がなかった、という反省です。

6-3. まだ解けていない問題

正直な限界も共有されました。

メモリを持つステートフルなシステムのeval。Mihir氏は、メモリとどれだけうまくやり取りするかという軌跡（trajectory）のevalはできるが、外部状態が存在する状況でのオフラインの結果evalは、まだ完全には解けていないと述べています。

外部サービスへのツール呼び出しを伴うeval。Sahaj氏も、同様の課題を挙げ、Slack MCPに依存して情報を生成するevalは、自分たちの制御外の要因で時間とともにドリフトしない体系的なスイートを作るのが極めて難しいとします。全体をモックすれば別だが、それは膨大な作業になる。

6-4. モデル移行への向き合い方

新モデルが出たときの対応についてのSahaj氏の考え方も実用的です。

良いevalスイートがあれば移行はできる。プロンプトが特定モデルファミリーに過剰最適化されていなければ、なおよい。

そのうえで注目すべきは「最後の1%」ではないとします。

具体例として、5系列のモデル全般が以前の系列よりAI的な兆候の強い文章を生成する傾向を挙げ、em dash（ダッシュ）の多用や、読みづらい文構造を指摘しています。既知の失敗モードへのヘッジこそが重要だ、という主張です。

7. コスト ― 最大の論点

7-1. 「コストを気にしないなら、持続する事業にはならない」

Sahaj氏の前提は率直です。

同社が内部で繰り返し問うているのは、「制御を自社で持つことのコストと価値のトレードオフが、内製に傾くのはいつか」という問いです。

現時点の評価としては、インフラ実行にかかるCPUオーバーヘッドという意味でManaged Agentsのマークアップは低いとしています。

7-2. 具体的な要望：バッチモード

一方で、明確な制約も指摘されました。

同氏の姿勢はバランスの取れたものです。短中期にユーザーへ生み出せる価値が大きいなら、コスト最適化は「成熟し、意識的に、賢く使う」ことにとどめ、細部の最適化は後から戻ってくればよい、と。

7-3. アトリビューション（費用の帰属）

Todd氏が挙げたのは、どの呼び出しにいくらかかっているかの細粒度なテレメトリです。

夜間の大規模バッチ処理は大量のデータを処理するため高額になり得る。現時点ではエンジニアリング時間をほとんどかけずに、頻度を下げる・送るデータを減らすといった安価な対処ができる。過剰に最適化しなくて済むからです。ただし一定の規模と成熟度に達すれば、もう少し制御が欲しくなるだろう、としています。

7-4. 「オール・オア・ナッシング」問題

Mihir氏の指摘が、最も構造的です。

製品のうち真にフロンティアの知能が必要な部分——Watchtowerで検索を調整するメインエージェントなど——では、Opusのようなモデルは十分良く、価格も相対的に妥当だとします。

問題はそれ以外です。

そこは大幅に安いモデルを使うなど、コスト最適化せざるを得ない領域です。しかし——

司会者は、これを「コストのレバーの可視化」の課題として受け止め、エフォート設定、マルチエージェント、複数モデルといった既存の手段に加え、フレックスモードやバッチモードがあれば2倍・50%の改善になるという認識を示しました。

7-5. レイテンシとUX

もう一つ挙げられたのが、レイテンシに敏感な部分でのサンドボックスの事前ウォーミングです。コールドスタートのレイテンシを賢く減らしたいが、マネージドエージェント製品の性質上そこに手が届きにくい、という指摘でした。

Mihir氏は、Managed Agentsが最もよく機能する条件を明確に定義しています。

逆に言えば、それ以外ではUX改善やコスト削減のレバーが多くない、というのが現時点の評価です。

オススメ記事

Next Big Wave——成長株・アイデアの種・トレンド深掘り