［ビジネスマン向け］Asanaに学ぶ人間とAIエージェントのチーム設計

2026-10-02

はじめに

　Claude by Anthropicが 2026年9月29日、AsanaがClaudeを使って人間とAIエージェントのチームを運用する方法を紹介しました。本稿では、Work Graph、役割と権限、共有メモリ、作業の可視化、3つの社内事例から、組織導入の設計原則を整理します。

参考記事

タイトル: Agents you can coach: how Asana builds human-agent teams with Claude
著者: Aleksandra Todorova、Kristen Swanson
発行元: Claude by Anthropic
発行日: 2026年9月29日
URL: https://claude.com/blog/agents-you-can-coach-how-asana-builds-human-agent-teams-with-claude

要点

AsanaはAI専用の文脈基盤を作らず、人間とエージェントを同じWork Graph上で働かせている。
エージェントごとに役割、利用者、管理者、指示、スキル、連携、権限を定義し、実効アクセスは起動した人の権限を上限とする。
誰でもタスク単位のフィードバックを送れるが、恒久メモリを変更できるのは管理者と編集者だけである。
調査計画や実行手順を共有タスクへ表示し、依頼、反論、出力をチームで確認・修正できる。
社内では製品質問への回答、更新リスクの毎朝の要約、開発サイクル計画にエージェントを利用している。

詳細解説

AI専用の別基盤を作らない

　AsanaはAIエージェントを導入する以前から、タスク、プロジェクト、目標、会話を、所有者、協力者、依存関係とともに結び付けるWork Graphを整備してきました。エージェント向けに別のデータ構造を増設するのではなく、人間と 同じWork Graph の中で、役割を持ち、タスクを担当し、メッセージを読み書きし、活動フィードへ現れる設計を選んでいます。

　この方式の利点は、AIの出力を既存の仕事から切り離さないことです。個人のチャット画面だけで完結すると、成果物は共有できても、依頼の背景、参照した情報、判断の経緯が残りにくくなります。既存のタスク管理構造にエージェントを入れれば、担当、期限、依存関係、コメント、承認といった人間向けの管理手法をそのまま利用できます。

考える工程と実行する工程をつなぐ

　Asana社内ではClaudeが標準AIツールで、Google Drive、Slack、Asanaなどに接続されています。従業員はアイデア、Slackの会話、Zoom録画、Databricksレポート、Google Docsといった 非構造情報をClaudeと議論 し、次の行動を明確にします。実行可能な項目をプロジェクトやタスクへ移した後に、エージェントが引き継ぎます。

　この流れを支えるのが、持続的メモリ、独自の認証情報、共有コンテキストという3つの能力です。 持続的メモリ、独自の認証情報、共有コンテキスト を持つことで、エージェントは一度きりの回答ではなく、役割に沿った継続作業を担当できます。

　実務では、最初から曖昧な依頼を自律実行させるのではなく、①散在情報を集める、②Claudeを思考相手に議論する、③実行項目をWork Graphへ記録する、④担当エージェントが処理する、という順序が参考になります。AIに考えさせる範囲と、正式な業務として実行させる範囲の境界を作れるためです。

役割とアクセスをプロフィールで管理する

　Asanaのエージェントは、コンテンツライター、インサイト分析担当、プロジェクトマネージャー、受付担当、キャンペーン分析・調整担当など、仕事の役割を中心に設計されています。それぞれがAsanaの顧客調査に基づく 事前定義スキル と、HubSpotや文書ドライブなど必要な連携を持ちます。

　プロフィールページには、名前、目的、利用者、管理者、指示、スキル、連携、権限をまとめて表示します。アクセスは特定のプロジェクト、文書、アプリへ限定できます。さらに、エージェントが実際に使える情報は、 起動した人の権限を上限 とします。エージェント自体に広い接続先があっても、依頼者が見られない私的情報を回答へ混ぜにくくする二重の境界です。

　導入時には、役割名だけでなく、目的、具体的な担当業務、読める情報、実行できる操作を明文化する必要があります。多くの人が利用できることと、少数の人だけが管理できることを分けると、利用範囲を広げながら挙動の一貫性を保ちやすくなると考えられます。

利用者と学習管理者を分離する

　AsanaのAI teammatesは共有メモリを持ち、過去の指示から得た情報を複数利用者の仕事に再利用します。ただし、フィードバックをすべて無条件に恒久学習へ入れるわけではありません。誰でも タスク単位のフィードバック を送れますが、恒久メモリへ保存し、元に戻し、削除できるのは 管理者と編集者だけ です。それ以外の人の指摘は、そのタスクだけに適用されます。

　たとえば文章のトーンを守るエージェントなら、基準を所有する広報チームが編集者・管理者になります。他部門の利用者は下書きを依頼し、その場の修正はできても、将来の出力を左右する恒久的なルールは変更できません。Asanaでは1〜2人の専門家が仕組みを理解して設定し、他の利用者は複雑な内部構造を意識せずに同じ恩恵を得る形を想定しています。

　この分離は、誤った指摘や一時的な例外が組織全体のエージェント挙動へ広がるのを防ぐ承認フローとして機能します。共有メモリには、登録者、根拠、適用範囲、更新日、削除方法を持たせると、長期運用での陳腐化にも対応しやすいと思います。

過程を共有しチームで指示を直す

　AI teammateへタスクを割り当てると、担当がエージェントであることが明示され、 調査計画や実行手順 が活動ログへ表示されます。アクセス権を持つ人は過程と結果を読み、コメントし、追加指示を与えられます。

　Chief Product OfficerのArnab Boseが講演資料をレビューした例では、以前の講演内容も考慮するよう共有タスク上で依頼しました。過去情報がWork Graphに残っていたため短い指示で済み、広報担当者も同じ場所で依頼と応答を確認しながら修正できました。個人とAIの1対1対話では見えにくい 依頼、反論、出力 が一か所に残り、レビュー担当者は完成物だけでなく、結果を生んだ指示も直せます。

　これはエージェントの監査性だけでなく、チーム学習にも関わります。どの情報を与え、どの判断で進み、どこを人間が修正したかが共有されれば、次の依頼品質を改善できます。AI作業を人間の仕事に見せかけず、担当主体を明示することも重要です。

事例1：製品質問を組織改善へつなぐ

　営業やカスタマーサクセスからSlackへ届く製品質問は、Asanaアプリによって自動的にタスク化され、エージェントが処理します。承認済み情報があれば出典リンク付きで回答し、答えがなく製品上の不足を示す場合は製品チームのバックログへ追加します。同じ質問が繰り返されれば、研修・文書の更新タスクを作ります。

　つまり、問い合わせ処理を回答だけで終わらせず、 回答、バックログ、文書更新 へ分岐させています。質問の増加自体を、新機能に関する研修や案内が不足しているシグナルとして活用できるため、専門家の負担軽減と組織改善を同時に進められます。

事例2：更新リスクを毎朝共有する

　At-Risk RenewalというAI teammateは、世界中の更新リスク付きタスク、担当者の更新、ステータス、コメントを読み、 良い動き、悪い動き、推奨フォロー の3区分で日次ダイジェストを作ります。全世界を俯瞰した後に地域別へ分け、毎朝、顧客・売上部門の責任者へ共有します。

　責任者は離反予測の先行指標などを同じ共有空間で追加質問し、次回以降に覚える内容を指導できます。単に各自がClaudeへレポートを作らせる場合と異なり、書式が標準化され、関係者が同じ結果を見て、毎回の修正を共有メモリへ反映できる点が運用上の価値です。

事例3：コード生成より計画を管理する

　Asanaは自社製品で自動コーディングループを試した際、自動生成された変更が サイクルを膨張させ、リリースが遅れた と説明しています。コード生成そのものではなく、計画、意思決定、要求の磨き込みが新たなボトルネックになったため、Command by Asanaで工程全体を管理するようになりました。

　Commandでは、 10〜12人のエンジニア が1製品を担当するチーム空間へ、エージェントが顧客フィードバックやSlackコメントからチケットを投入します。どの項目を開発サイクルへ入れるかは人間が決め、完了予測は 楽観・均衡・保守 の3種類で示されます。チケットは人間にもコーディングエージェントにも割り当てられ、管理者は遅延要因やトレードオフをチャットで確認できます。

　この事例は、AIの生成量を増やすだけでは生産性が上がらないことを示しています。投入前の選別、優先順位、容量計画、レビューを共有データへ戻す必要があります。既存システムとの協調を重視する過去記事や、AIエージェントのROIを扱う記事と合わせると、成果はモデル性能より業務フローの設計に左右されると考えられます。

Asana事例から見える導入原則

　Asanaの実践は、①人間と同じ仕事の構造へ置く、②役割とアクセスを限定する、③利用と恒久学習の権限を分ける、④過程を共有する、⑤成果を次のタスクや知識更新へ戻す、という5点に整理できます。

　これらはエージェントを「便利なチャット」から「組織の一員」へ移す際の管理策です。誰が利用し、誰が教え、何を見られ、何を実行し、どの記録を残すかを決めることで、人間とAIの共同作業を 監査・改善できる状態 にできます。導入初期は対象業務を絞り、指示と結果が既に共有される業務から始める方法が現実的だと思います。