AsanaのAIチームメイトを育てる仕組み — 役割・記憶・可視化

要点

Asanaは、AIエージェントを人間の同僚と同じ作業モデルの中に置いています。Anthropicのブログが、同社CPOのArnab Bose氏への取材として紹介しました。

• エージェントは専用の文脈構造を持たず、タスク・プロジェクト・ゴール・会話を関係づけたWork Graph(Asanaの作業モデル)の中で動く
• 各エージェントには役割・利用者・管理者・スキル・連携先・権限を書いたプロフィールページがある
• エージェントの実効アクセスは、起動した人の権限の範囲に収まる
• 共有メモリに永続的に書き込めるのは管理者と編集者だけで、ほかの人のフィードバックはそのタスク限りになる
• 依頼・計画・手順・結果は共有タスクに残り、レビュアー全員が見て指示を直せる

「エージェントを賢くする」より先に、誰が何を任せ、誰が育てるかを決める。それが全体を通したメッセージです。

あなたのチームの運用はどう変わるか

ブログは各節の末尾に「実践するなら」の手順を添えています。

エージェントを設計する人

先に役割を書き、次に権限を絞ります。Asanaのエージェントは、コンテンツライター、インサイトアナリスト、プロジェクトマネージャー、依頼受付担当、キャンペーンアナリスト、キャンペーンコーディネーターのように、仕事の種類で作られています。

各エージェントには、顧客がその仕事をどう進めるかというAsanaの調査に基づく事前構築スキルが付きます。HubSpotやドキュメントドライブなど、必要な連携も最初から組み込まれます。プロフィールページには名前と目的、使える人、管理者、指示、スキル、連携、権限が並びます。

ブログが挙げる手順は3つです。

1. エージェントを作る前に役割を決める。目的・指示・担当する仕事を、新入社員の最初の四半期の目標を書く要領で書き出す
2. アクセスを絞る。読めるプロジェクトとドキュメント、使えるアプリ、実行できる操作を決める
3. 利用者と管理者を分けて名前を挙げる。使う人は多くてよいが、権限と挙動を決める人は少人数に限る

エージェントを日常で使う人

Bose氏は、Slackの会話、Zoomの録画、Databricksのレポート、Googleドキュメントなど、構造のない情報をClaudeと話して整えてからAsanaに流し込むと語っています。AsanaではClaudeが社内の標準AIツールで、Google Drive、Slack、Asanaに接続されています。

流れは次のとおりです。自分の考えをClaudeに投げ、壁打ちで次の一手が見えるまで詰める。動けるものだけをプロジェクトとタスクに移す。その時点で、エージェントも同僚も拾える状態になります。

レビューする側の人

共有タスクの上でエージェントに指示すれば、依頼から結果までが1か所に残ります。@メンションで呼び出し、返答を見ながら往復できます。同じタスクを見ている同僚が、同時に会話へ加われます。

記憶を育てる人

共有メモリの書き込み権限は、管理者と編集者にあります。ほかの人のフィードバックは、そのタスクにだけ効きます。Asanaの広報チームは自社の声とトーンの基準を持つので、文章を書くエージェントの編集者と管理者になります。Bose氏はそのエージェントで下書きを作れますが、挙動は変えられません。

Asanaが実際に任せている3つの仕事

Claudeは、Asanaの中でドキュメントを作る仕事や複雑なタスクの実行を支えています。ブログは3つの例を紹介しています。

Slackの製品質問を、タスクに変えて捌く

機能の公開のたびに、営業やカスタマーサクセスが共有Slackチャンネルへ質問を書き込みます。以前は同じ質問が何度も投稿され、そのたびに専門家がメンションされていました。答えが微妙で、しかも変わっていくため、検索できる知識ベースでは追いつかなかった、とBose氏は言います。

質問の入口は今もSlackです。チャンネルに入れたAsanaアプリが質問をタスクに変え、エージェントが拾います。

• 承認済みの回答があれば、出典リンク付きで返す
• 承認済みの回答が無く、製品の穴を示す質問なら、製品チームの受付プロジェクトにタスクを作ってバックログへ入れる
• 同じ質問が続き、同じ記録を返し続けているなら、研修資料とドキュメントの更新をイネーブルメントチームのタスクにする

副産物として、新製品に関する質問が集中した話題は、イネーブルメントチームが追加研修に回す合図になります。

解約リスクの案件を、毎朝のダイジェストにする

最高顧客責任者のJosh Abdulla氏は、以前は週次で解約リスクの更新案件をまとめ、経営陣に報告していました。顧客数が数千に及ぶため、更新を追い続けるには専任者が要り、後手に回っていたといいます。「問題を知るのは、データが最初に示したときではなく、リーダーから聞かされたときだった」とBose氏は振り返ります。

カスタマーエクスペリエンス部門は「At-Risk Renewal」というエージェントを作りました。全世界のリスク案件のタスクを、CSMの更新・ステータスメモ・コメントごと読み込みます。好材料、悪材料、推奨フォローアップの3区分で、構造化された日次ダイジェストを作ります。全体で先にまとめ、地域別に切り分け、毎朝、最高顧客責任者、最高売上責任者、各地域のリーダーへ届けます。

ダイジェストは共有の場所に着くので、リーダーは「ある顧客の解約予測の先行指標は何か」と追加で聞けます。記憶させたいことは次回の実行に向けて指示できます。Bose氏は「各自がClaudeにレポートを作らせることもできる」と認めたうえで、標準化された報告、共有の作業場、実行のたびに良くなる仕組みをどう得るかが課題だったと話します。

エンジニアリングの計画をCommandで回す

Asanaは自社製品で、顧客フィードバックを集めて要約し、コーディングエージェントにプルリクエストを作らせる自動ループを回しました。結果は、自動生成された変更でサイクルが膨らみ、リリースが遅れることでした。Bose氏は「コード生成はもうボトルネックではない。ボトルネックは計画、意思決定、洗練にある」と述べています。

いまは、大規模なエンジニアリングチームを管理するCommand by Asanaでこのループを運用しています。10〜12人のエンジニアが1つの製品を担当するチームスペースがあり、エージェントが顧客フィードバックとSlackのフィードバックチャンネルのコメントからチケットを起こして、未計画ボードに置きます。サイクルに入れるかどうかは人が決めます。Commandはサイクルの完了時期を、楽観・標準・保守の3通りで予測します。

チケットは人にもコーディングエージェントにも割り当てられます。リリースが遅れている理由も、チャットで聞けます。これらはAsanaのMCPサーバー経由で公開されるため、Bose氏やCTOは、Commandを開かなくてもClaudeに進捗を尋ねられます。

背景・文脈

シリーズ3本目、Slackの事例に続く回

この記事は、人間とエージェントのチームをテーマにしたAnthropicのシリーズの3本目です。1本目はAnthropic社内の知見(2026年6月24日)、2本目はSlackの事例で、今回はAsanaが続きます。

1本目は、エージェントに必要な条件として永続的な記憶、人間に紐づかない資格情報、広い情報アクセスを挙げました。ブログは、Asanaのエージェントもこの3つの能力を持って動くと位置付けています。作業がWork Graphで構造化されていれば、エージェントは記憶も資格情報も共有された文脈も使えるという筋立てです。そのうえでAsanaは、エージェントごとに固有のIDを与えて貢献とアクセスを監査できるようにし、実効アクセスを起動した人の権限の範囲に収める安全策を重ねています。

1本目の教訓との対応

1本目の教訓のうち「全員が役割を持つ」「公開の場で働く」は、Asanaの運用と対応します。エージェントが自分の役割に必要な道具を持ち、人間だけが持てる役割も残す考え方は、Asanaのプロフィールページや管理者・編集者の分離と発想が近く見えます。ただしAsana自身が、人間限定の役割に触れているわけではありません。

Slackの事例は、会話を知識にする側から同じ問題に近づきました。ClaudeをSlackで使う方法はClaudeとSlackの連携で扱っています。

権限の二重の縛りをどう読むか

今回の記事で目を引くのは、権限の話が2層に分かれている点です。

1つ目は、エージェントが固有のIDを持ち、人間のユーザーと同じく明示的なアクセス制御に従うことです。そこに追加の安全策として、実効アクセスが起動した人の権限で上限を切られます。エージェントは公開コンテンツには広く触れられますが、誰かが非公開の場で教えた内容を、権限のない別の人が引き出すリスクは抑えられます。

2つ目は、記憶を書き換える権限の分離です。使うことと育てることを分ければ、一人の一言がチーム全員の使うエージェントの挙動を変えてしまう事態を避けやすくなります。

Claude側でも似た考え方があります。AsanaのConnectorは、接続した本人がAsana側で持つ権限を超えて触れません。手順はClaude Asana連携の始め方、会話での使い方はClaude Asanaタスク管理にあります。

ただし、今回のブログはAsana側のAIチームメイトの話で、Connector経由でClaudeが触る場合の挙動とは別の機能です。両者の権限の扱いが同じ設計かどうかは、ブログからは分かりません。

エージェントの権限を外側から縛る別のアプローチは、Managed AgentsとNVIDIAの連携にあります。こちらは資格情報の保管と実行環境の制限で縛る話で、Asanaのような業務アプリ内の権限設計とは層が違います。

「賢いエージェント」より先に決めることが多い

3つの事例に共通するのは、モデルの性能を上げる話が出てこないことです。

出てくるのは、質問が流れ込む入口の固定、受け取ったあとの分岐、結果の置き場、直す人の指定です。At-Risk Renewalの例では、各自がClaudeでレポートを作れる状況でも、標準化と共有と改善の積み上げが目的になっています。個人の生産性ではなくチームの資産として運用する発想です。

裏を返すと、この運用が成り立つ前提は、作業がすでにWork Graphのように構造化されていることです。構造のない現場でそのまま真似すると、エージェントの居場所が無いままになる可能性があります。これはブログの記述からの推測で、Asana自身がそう述べているわけではありません。

また、取材はAsana自身の運用で、成果を示す数値は出てきません。日次ダイジェストで実際に把握が早まったかどうかは、ここからは判断できません。

まとめ

Asanaの運用の核は、エージェントを賢くすることではなく、役割・権限・記憶を書き換える人を先に決めることです。起動した人の権限で実効アクセスが決まる点は、Asanaで同じ運用を組むときの前提になります。