Anthropicの新作を解読する：効率的なAI人間協働チームを構築する方法

2024年6月24日、Anthropic公式ブログに新記事「Building effective human-agent teams」が公開され、著者はKristen Swanson氏です。

この記事の核心は、AIによるチームレベルのコラボレーションのパラダイムが、「一人が一つのチャットボックス（背後に多くのエージェントがいる場合でも）に向かう」から、「一群の人々と一群のエージェントが同じワークスペースを共有する」へと移行している点です。

本稿では、原文の核心的な見解を伝えるとともに、AIエージェントの導入経験に基づいて、流れを整理し総合的な考察を加えます。

一、主旨：AIコラボレーションチームが「オンラインモード」へ

これまで、AIの使用は「シングルプレイヤー」体験でした。個人がエージェントと協力して個人タスクを完了するものです。

現在の新しいモードでは、人間とエージェントが同じワークスペースで協力し、チーム共通の目標に貢献します。

作業は「マルチプレイヤーゲーム」のように始まります。人間チームが戦略を立て、Claudeが実行します。

要するに、共通の目標、共通のコンテキスト、特に共通のワークスペースを共有するのです。

下図のように、右側の複雑な作業モードへの移行が進んでいます。

この移行を実現するのは、Anthropicの新製品Claude Tagです。これはClaudeをSlackなどのチームコラボレーションツールに常駐させ、チームメンバーのように@メンションやタスク割り当てを可能にする形態です。

したがって、この記事は理論だけでなく、Anthropicが「自社製品で推進している方向性」でもあります。

二、「マルチプレイヤーエージェント」のコラボレーション問題とは？

原文では「マルチプレイヤーエージェント」を次のように定義しています：同時に多くの異なる人間と協力するAIモデル。

これは私たちがよく知る通常のエージェントと共通点があり、また重要な違いもあります。

• 共通点：記憶とスキル（skills）を持つこと。

• 相違点：**独自の資格情報（credentials）**を持っていること。

さらに、「living where work happens」—すなわち、作業が実際に行われる場所で活動します。

Anthropicでは、その場所がSlackのようなチームコラボレーションツールです。

「独自の資格情報を持ち、チームチャンネルで活動する」という設定は非常に重要です。

これは、エージェントが誰かのアカウントを借りて、誰かのプライベートセッションで作業するのではなく、独立した身分を持つチームエンティティであることを意味します。チーム全体から見え、その成果は全員に公開され、読み取るコンテキストは個人レベルではなくチームレベルです。下図のように、あなたの業務ソフトの一員になります。

エージェントがチームチャンネルで「効果的に参加」するためには、特定の基盤能力（Claude Tagのような製品形態）と、特別に設計された永続的な記憶、専用の身分、情報源などの仕組みが必要です。

さらに、技術的な能力だけでは不十分であり、人間と機械のチームを「成功」させるには、一連の作業方法と共有規範が必要です。

そのため、記事の後半の4つの経験則は、すべてAIチームの「規範」を設計するための経験です。

三、AIエージェントチームの4つの経験則

経験則一：情報管理を改革し、エージェントに可能な限り広いコンテキストを与える

Anthropicは、ドキュメントごと、チャンネルごとにエージェントにどの情報を見せるかを決定するのではなく、明確に定義された**セキュリティ境界（security boundaries）**を用いて、Slackワークスペース全体、会議の書き起こし、ドキュメントライブラリに一律に適用することを推奨しています。

原文では、日常的な悩みが特に指摘されています：「このチャンネルは公開か非公開か？このドキュメントはあの人と共有できるか？このエージェントはこのメッセージを見られるか？」

境界内では、コンテキストはすべてのチームメンバー（人間もAIも）に可視であり、AIは人間と同じようにドキュメントのアクセス権を申請することもできます。

この方法の巧妙さは、同時に二つの問題を解決することにあります。

1.エージェントと人間が入手できるコンテキストを拡大すること。

2.「個別に共有する」ことによる意思決定の疲労を排除すること。

権限を開放することのリターンは確実で、情報伝達の損失がなくなり、エージェントはテキストを読む速度が人間よりはるかに速いため、「routinely surface relevant work that humans would otherwise have missed」（人間が見逃してしまう関連業務を日常的に表面化させる）ことができます。

筆者から見ると、これは本質的に組織文化と権限メカニズムの転換です。

「デフォルトで内部公開」は、多くの企業にとっては組織の根幹を揺るがす文化変革です。

Anthropicはもともと高度に信頼でき、情報がフラットな会社であるため、大企業病、特に伝統的な業界における階層を超えた情報格差に起因するリソース格差を理解できていない可能性があります。

また、コンプライアンスや情報隔離が厳しい組織（金融、医療、国境を越えた法域）では、「ワークスペースレベルでの一律適用」は必ずしも機能しません。

したがって、真に応用可能なのは、その背後にある簡素化された承認メカニズムです。例えば、エージェントが特定のグループに所属していれば、そのグループが権限を持つドキュメントを自動的に読み取れるようにするといったことです。権限管理があっても、ネイティブに一括管理でき、最初にドキュメントを割り当て、後で品質をチェックする必要はありません。

経験則二：各人/エージェントに明確な役割とツールを

原文の描写は非常にイメージしやすいです。人間と機械のチームは1つの名簿、1組の成果物、1つのワークスペースを共有します。

その上で、エージェントはそれぞれ役割分担します。

• あるエージェントはプロジェクトのデータ分析を担当。

• 別のエージェントはデザイン仕様を保持し実行。

• 3番目のエージェントは研究統合（research synthesis）を担当。

プロジェクト開始時には、人間がまずエージェントと話し合い、役割の割り当てや人間とエージェントの協力方法を決定します。

そして、下図のような役割とルール＋介入のタイミングの組み合わせを生成します。

役割が明確になると、エージェントは別のエージェントを「spin up」（起動）することもでき、各具体的なタスクが正しい記憶、正しいアクセス権を持つエージェントに確実に割り当てられます。

重要なのは、ツールを完備することです。データ分析を行うエージェントにはBigQueryのアクセス権が必要かもしれません。QAを行うエージェントにはPlaywright MCPが必要かもしれません。

人間は人間のみが担える役割を保持し、最も重要な判断には人間の判断が使われるようにします。

筆者の見解：これはAnthropicがこれまで研究してきたメカニズムワークフローのアーキテクチャでもあります。

リードエージェントが全体を調整し、並行して実行される専門化されたサブエージェントにタスクを委任します。このようなメカニズムは確かに実用的で、品質指標はほぼ2倍（90.2%向上）になりますが、トークンコストは15倍に増加します。ただし、「マルチエージェントの方が強い」というのは普遍的な結論ではなく、「特定のタイプのタスクにおいて、かなりの計算コストを払って得られる向上」です。

特に幅優先で並列化可能な作業において、そしてより強力なクロス検証メカニズムにより、情報の正確性が向上します。

さらに、細かい設計が必要であり、タスクの分解と役割の分離を適切に行う必要があります。単に「エージェントを何体も積む」だけでは不十分です。

そうでなければ、また新たな「1エーカーあたり1万8千斤」のような誤解を生むでしょう。

これらの見解の多くは、前回の記事「ClaudeのDynamic Workflowsを使った深層研究」でも述べられています。

経験則三：ノーススターの役割を設定し、エージェントが自律的に問題を解決するようにする

原文では2種類のエージェントを区別しています。一つは単に「指示されたタスクを完了する」だけのもの。そして最も重要なのは、能動的に新しいプロジェクトやワークフローを提案するものです。

後者は通常、すでに豊富なコンテキストと明確な役割を持つチームに現れ、それに加えて追加のガイドライン—ノーススター（north star）—が設定されます。

ノーススターは、「どのタスクやワークフローが正しいのか」をチームが判断するのを助けます。

原文はいくつかの規律を強調しています。

•ノーススターは常に人間が設定し、会社の使命とビジネス目標に根ざしていること。

•ノーススターは明確に文書化されたら、人間がそれをチーム内のエージェントと共有すること。

•そして—このステップが重要です—人間はどのエージェントが能動的に新しいワークフローを提案すべきかを選択すること。

運用主導の製品と会社であれば、運用の役割を主導エージェントにすべきであり、製品主導や技術主導、財務主導ではありません。

例えば、ClaudeのDynamic Workflowsを使った深層研究における**ルーティングパターン（Classify-And-Act）**のように、まずエージェントがタスクの種類を識別し、それを最も適した専門エージェントに振り分けます。

筆者の見解：以前Anthropicの記事をいくつか読んで感じたのは、彼らがエージェントとワークフローをどのように区別しているかということです。

前者は「動的に自身のプロセスとツール使用を主導し、どのようにタスクを完了するかを制御する」ものです。

後者は「事前定義されたコードパスを通じてオーケストレーションされる」決定論的なシステムです。

したがって、AIチームを構築するには、エージェントにタスクリストではなくノーススターを与えるべきであり、それはまさにシステムをワークフローからエージェントへと意識的に押し進めていることを意味します。

目標を持つチームは創造性を生み出し、限られた範囲内で無理に何かを探す必要はありません。

もちろん、現在私たちが構築している多くのAIチームは、プログラム化された、あるいはAI化されたワークフローであり、それでも多くの問題を解決できます。しかし、今後創造性、自発性、能動的に問題解決能力が必要であれば、そのようなエージェント型のチームを設計する必要があります。

経験則四：エージェントを時間とともに成長させる

ここで公式のデータは非常に驚くべきものでした。Anthropicのエンジニアは、チーム内のエージェントに500件のバグ修正を独立して処理させることができたと述べています。しかし、すぐに「things certainly didn't start off that way（最初からそうだったわけではない）」と強調しています。

エージェントを新入社員の人間の同僚に例えています。タスクをどう実行するのが最善かという暗黙知を外在化するには、複数回のフィードバックが必要です。

ユーザーは繰り返し様々なタスクでエージェントを試し、その能力の境界、目標を明確に記述する方法、必要なスキルファイル、望ましい行動を引き出すプロンプトなどを把握しなければなりません。

原文は、見落とされがちな点も特に注意しています：モデルはアップグレードされ、タスクは再テストする必要がある—プロンプトを書き直す必要があるかもしれません。過去に有効だったハーネス（Harness）が、より賢いモデルがより創造的な解決策を見つけるのを阻害する可能性があります。

この経験則の中で最も価値が高いのは、**検証（verification）**に関する論述です。

「私たちは、最も優れた長期エージェントは、人間に見せる前に、自分の作業を検証する多くの方法を持っていることに気づきました。」

• コードにはテストがあります。これは当然です。

• しかし、他のほとんどの作業も同様に検証可能です。技術文書には評価ルーブリック（rubric）やスタイルガイド（style guide）を適用できます。

• 人間が基準を設定し、エージェントに任せるすべての作業がレビュー可能であることを確認すれば、品質は維持され、本来の目的から逸脱しません。

• さらに、あるエージェントに作業をさせ、別のエージェントにチェックさせることもできます。これは「Doer-Verifier（実行-検証）」エージェントハーネスとして知られています。

原文には完全な事例があります。あるエンジニアリングリーダーが、積み残し（backlog）が多い新しいチームを引き継ぎました。彼は数人の人間と数体のエージェントを集めて優先順位を整理しました。

あるグループのエージェントはすべての積み残し項目を読み、誰かが取り組んでいるかどうかを判断し、未割り当ての項目に複雑度スコアを付けました。

別のグループはリストから中～低複雑度の項目を抽出し、直接コードの変更を生成しました。

最初は、人間がエージェントのすべての決定をレビューし、人間の介入が必要なものをマークしました。その後、人間はエージェントに、そのような決定を人間に直接委ねるように「教え」、難しいトレードオフを伴う決定には常に「human in the loop」が存在するようにしました。

さらに毎週、チームはエージェントに「教訓と失敗（lessons & missteps）」を含む週報を作成させ、エージェントがエラーを覚えて繰り返さないようにしました。時間が経つにつれて、リーダーはエージェントにますます複雑な変更を任せられるようになり、日常的な指導に費やす時間は減少しました。下図の通りです。

賢いロブスターを育てる過程によく似ています。

最後の部分は、全文で私が最も評価する洞察です—エージェントがより独立した後、リーダーはエージェントに「人間の注意力」を希少リソースとして扱うように教え始めます。

例えば、問題をバッチ化して人間が一度に回答できるようにする、重要なコンテキストを繰り返し伝えて人間がすぐに把握できるようにする、一度に人間に投げる事項の数を制限する、などです。

中には、バッチ処理を決定し、最も重要なコミュニケーションのみを人間にエスカレーションする専用のエージェントを設ける人もいます。

また、エージェントに「1日に実行できる作業量の上限」を設定する人もいます。そうすることで、人間が有意義に関与でき、自分にとって重要なスキルを衰えさせずに済みます。

筆者の見解では、これらの経験則は、「人間と機械の関係」において全文で最も深い部分です。

• 第一に、Anthropicの考えでは、効果的な監督とはすべての動作を承認することではなく、「重要な場面で介入できる位置にいること」（being in a position to intervene when it matters）です。

• 第二に、「人間の注意力」を明示的に希少リソースとして最適化することは深刻に過小評価されているデザイン原則ですエージェントに関する議論のほとんどは「エージェントの能力に焦点を当てていますが実際の効率上のボトルネックはすでに「人の認知帯域です」としています。* 第三に Harness（統制工学 は、機械・AI ではあるものの、人間と機械のチームにおいては優秀なチームの方法を完全に模倣すべきであり、優秀な馬には手綱は必要なく、目標だけで良い場合もあるのです。」ということです。

四、人間と機械の協働時代は、元のチームの組織品質を容赦なく拡大する

この記事の最も誠実で、見逃されがちな一文は、結びに現れます。

彼は、上記の4つの経験則は実は目新しいものではなく、AI登場以前から存在していた、強いチームには強力なノーススター、明確な役割、しっかりした文書、共有の品質基準、失敗から学ぶ余地があること、これらは何十年も前から知られている健全なチームの習慣であると述べています。

そしてAIエージェントチームは、これらの基本をより重要にするだけです。

合理的なメカニズム構築がなければ、AIは自動的にチームを強くせず、逆に圧迫を生み、最終的に混乱を引き起こします。例えば、

• コンテキストが散漫なチーム（情報格差で管理しているなど）は、エージェントを導入してもさらに散漫になります（情報の隔絶が大きいほど、成果は逸脱します）。

• 役割が混乱しているチームは、エージェントがその混乱を複製し、互いの作業責任が乱れ、意思決定者の判断源が歪みます。

• 検証文化のないチームでは、エージェントのエラーがより速い速度でスケールし、AIのコード速度は人間のCR速度をはるかに超えています。

したがって、筆者は、「このエージェントの恩恵を最も多く得るチームは、これらの基本を最も意識的に実践しているチームである」と考えます。

AIエージェントに賭けている組織にとって、この記事が示す本当の宿題は、おそらく「Claudeの使い方」ではなく、自らのチームのコンテキスト、役割、目標、品質基準という4つの古いことを、真剣にやり直すことにあります。