Asanaが発表したAgentic Work Managementを、クラウドネイティブの日次レポート運用から考える

どうも おかしん です。

Asanaが現地時間2026年6月4日付で、AIエージェントと人間のチームを前提にした新しい方向性として、Agentic Work Managementを発表しました。

クラウドネイティブでもAsanaは日常的にかなり使っていますが、現状では割と人間味のある使い方をしていると思います。

タスク管理やプロジェクト管理の中にAIエージェントが入ってくると、「便利そう」で終わる話ではありません。仕事の入口、判断、実行、承認、監査の一部を、AIが担う可能性が出てくるからです。

この記事では、Asanaの発表を紹介しつつ、公開済み記事で紹介されているクラウドネイティブの日次レポート運用の文脈も踏まえて、Asanaを使っている組織がAIエージェント時代の仕事管理をどう考えるべきかを整理します。2026年6月6日時点の公開情報ベースで書いているため、実際の提供範囲、契約条件、管理者設定、ログの粒度は、導入前に必ず公式ドキュメントや管理画面で確認してください。

Asanaが発表したAgentic Work Managementとは

AsanaのAI製品ページでは、Agentic Work Managementを、AI Teammates、AI Studio、Asana Dash、MCPやAI Connectorsをまとめて、チームとAIエージェントが重要なワークフローを一緒に進めるためのものとして説明しています。

ざっくり分けると、見えている構成要素は次のようなものです。

なお、AsanaはAI TeammatesとAI Studioを含むAgentic Work Managementを提供開始済みとし、Asana Dashなど一部は今後段階的に提供するとしています。構成要素ごとに提供時期が異なる点には注意が必要です。

ここで重要なのは、AsanaがAIを「チャット欄で質問に答えるもの」としてだけ扱っていないことです。Asanaは、仕事の文脈を持つWork GraphにAIを接続し、プロジェクト、タスク、承認、依頼、外部ツールとの連携の中でAIを動かそうとしています。

これは、従来の「タスク管理ツールにAI機能が付きました」より一段大きい変化です。AIがタスクの横にいるのではなく、タスクの中に入り、場合によっては担当者のように振る舞うからです。

これは「AIでタスク作成が楽になる」だけの話ではない

AsanaのAI Teammatesは、マーケティング、Ops、IT、プロダクト・エンジニアリングなどのチーム向けに、事前定義されたAIエージェントを示しています。たとえば、Campaign Brief Writer、Brand Auditor、IT Support Specialist、Vendor Evaluator、Bug Investigatorのような役割が並んでいます。

AsanaはAI Teammatesについて、チームの文脈、共有メモリ、Work Graph、ガバナンスを持ち、実際のワークフローの中でチームと一緒に働くものとして説明しています。また、AI Teammatesは既存の権限制御に従い、アクセスを昇格しない、監査可能でリバーシブルである、といった説明もされています。

この方向性は歓迎できます。AIエージェントを業務に入れるなら、権限、監査、データ境界は避けて通れないからです。

Asanaは、AIパートナーが顧客データを学習に使わず、やり取りのあとに削除すること、AIが参照できるデータを管理者側で制御できることも説明しています。前向きな前提ですが、実際にどのデータを参照させるかは利用者側で決める必要があります。

一方で、利用者側が考えるべきことは増えます。AI Teammateが「誰かの補助」ではなく「チームの一員のようにタスクを担当する」なら、次の問いが出てきます。

• そのAIエージェントは、誰の責任範囲で動くのか。
• どのプロジェクト、タスク、添付ファイル、外部データを見てよいのか。
• 生成した下書き、判断、優先度付けを誰が承認するのか。
• 誤った分類、誤った要約、誤ったルーティングが起きたときに、誰が検知して戻すのか。
• 監査ログは、情シス、セキュリティ、業務オーナーの誰が、どの頻度で見るのか。

これは以前書いた AIエージェントが決済する時代のIDと権限制御 と同じ構図です。決済ほど直接的なお金の移動がなくても、仕事管理ツールの中でAIが依頼を受け、優先度を付け、担当者を変え、外部ツールを呼び出すなら、そこには権限設計が必要です。

Asanaをよく使う組織ほど気にしたいこと

Asanaを日常的に使っている組織では、Asanaの中にかなり多くの業務文脈が溜まっています。タスク名、コメント、添付ファイル、プロジェクト構造、担当者、期日、依存関係、意思決定の履歴。きれいに整理されているかどうかは別として、仕事の実態に近い情報が入っています。

AIエージェントがそこへ入ると、価値もリスクも大きくなります。

価値としては、依頼の受付、分類、重複確認、優先度付け、担当者へのルーティング、ステータスレポート作成、過去の意思決定検索、リスク検知のような仕事をかなり助けてくれそうです。AI Studioのページでも、入力内容の確認、重複検知、ポリシー準拠の確認、分類、SLAルール適用、担当チームや承認ステージへのルーティング、リスクや遅延の検知、社内ドキュメントやGoogle Drive、Web検索などが説明されています。

弊社の文脈でいうと、シンジ が以前書いた 従業員1日の活動履歴を全部AIに投げて働き方を指示してもらう では、Slack、Gmail、Google カレンダー、Asana、Box、Zoomの活動履歴を集め、AIで日次レポートを作り、SlackやNotionにつなぐ試みが紹介されています。

これはAsanaのAgentic Work Managementそのものではありません。ただ、Asanaを含む仕事データをAIへ渡し、日次レポートやマネージャー向けサマリーとして返すという意味では、かなり近い論点を含んでいます。Asanaの新機能を見るときも、単にAsanaの画面内で何ができるかだけでなく、他のSaaSから集まる仕事データとどう接続され、誰にどんな出力として返るのかを見る必要があります。

シンジの記事では、AIに渡すプロンプト側で、入力にない事実を作らないこと、数値は入力値を使うこと、個人情報や機微情報は概要へ丸めることも明示されています。ここはとても重要です。AIが賢いかどうか以前に、どのデータを渡し、何を根拠にし、どこへ出力し、どこへ保存するのかを決めないと、仕事管理のAIは便利な補助ではなく、見えにくい業務判断の経路になります。

一方で、リスクは「AIが間違える」だけではありません。

たとえば、AIが誤って重要度を下げたタスクが放置される。顧客対応の依頼を不適切なチームへ回す。セキュリティや人事に関わるタスクの情報を、見るべきでない人に見える形で要約する。外部連携を通じて、Asanaの外にあるデータを参照して判断する。こうしたことは、単なる生成ミスではなく、業務プロセス上の事故になります。

なので、AsanaのAI機能を見るときは「何が自動化できるか」だけでなく、自動化した結果、どの業務判断が前倒しでAIに渡るのか を見る必要があります。

AIエージェントに任せる前に決める5つのこと

Asanaに限らず、仕事管理SaaSにAIエージェントを入れる前に、少なくとも次の5つは決めておくのがよいと思います。

1つ目は対象業務です。AIに任せやすいのは、入力が定型的で、失敗時の影響が小さく、人間が後から確認できる業務です。たとえば、問い合わせの一次分類、タスクの重複候補提示、週次レポートの下書き、プロジェクト遅延の検知などです。

反対に、顧客への確定回答、契約条件の判断、人事評価、セキュリティインシデントの封じ込め判断、費用や権限の確定変更は、少なくとも最初からAIだけに任せるべきではありません。

2つ目は権限です。AsanaはAI Teammatesについて、既存の権限制御に従い、アクセスを昇格しないと説明しています。これは重要な前提ですが、利用者側では「そもそも人間側の権限が広すぎないか」を確認する必要があります。人間の権限が広すぎる組織では、それを継承するAIの参照範囲も広くなります。あわせて、誰がAI Teammateやワークフローを作成・変更できるかも統制の対象です。AsanaのAI Studioは管理者が有効化してからメンバーが使える設計なので、AIが何を見てよいかだけでなく、誰がAIの動きを作れるのかも先に決めておくべきです。

3つ目は承認です。AIが作ったものを「案」として扱うのか、「確定した処理」として扱うのかを分ける必要があります。AI Studioの画面例にも人間の入力や承認が出ていますが、実運用ではどの条件で人間に戻すかを業務ごとに決めることが大事です。

4つ目は監査です。監査ログは「問題が起きた後に見るもの」ではなく、「AIエージェントが想定外の動きをしていないかを見るもの」です。誰が作ったAI Teammateか、どのプロジェクトを見たか、何を出力したか、誰が承認したか、どの外部ツールに接続したかを、必要な粒度で追えるか確認します。

5つ目は停止です。AIワークフローは一度便利になると、止めるのが難しくなります。だからこそ、誤分類が増えたとき、外部連携に問題が起きたとき、機密情報の扱いに疑義が出たときに、誰がどの範囲を止めるのかを先に決めておきます。

この考え方は、AnthropicのAIエージェント向けゼロトラスト ともつながります。AIエージェントを信用するかどうかではなく、信用しすぎなくても業務が回るように、権限、承認、監査、停止を設計するという話です。

まず小さく試すならどこから始めるか

Asanaを使っている組織がまず試すなら、私は「人間の判断を置き換えないが、人間の確認を楽にする場所」から始めるのがよいと思います。

たとえば、次のような領域です。

• フォームから入ってきた依頼の分類案を出す。
• 不足している入力項目を検出する。
• 類似タスクや重複依頼の候補を出す。
• 週次ステータスレポートの下書きを作る。
• 遅延しそうなタスクや依存関係のリスクを知らせる。
• 社内ドキュメントをもとにIT問い合わせの回答案を作る。

ポイントは、AIの出力をそのまま確定させないことです。最初は「AIが見る、まとめる、候補を出す」までに留め、人間が承認してから次のステップに進めるのが安全です。

逆に、最初から避けたいのは、外部への自動送信、顧客への確定回答、権限変更、契約や費用に関わる判断、機密性の高い人事・セキュリティ情報をまたぐ処理です。これらはAIができるかどうかより、失敗時の影響範囲をどこまで制御できるかで判断した方がよいです。

もう1つ大事なのは、AsanaのAIだけを見ないことです。AsanaはMCPやAI Connectorsによって、ChatGPT、Claude、GeminiなどからAsanaのWork Graphに接続する方向性も示しています。さらにAsanaは2026年5月に、ノーコードでAIエージェントを作るStackAIの買収を発表しました。Salesforce、SharePoint、Oracle、CRM、ERP、ITSMなど複数の業務システム上でAIワークフローを動かすための買収とされ、Asanaのエージェントが計画や追跡だけでなく、他システムでの実行まで担う方向を示しています。つまり、仕事管理のデータはAsanaの画面内だけで使われるとは限りません。

この点は、AIに個人情報を入れてはいけない、で思考停止していないか でも書いたように、利用可否を一律で決めるより、データ種別、利用目的、保存・学習・削除、アクセス権、監査可能性を分けて確認する必要があります。

まとめ

AsanaのAgentic Work Managementは、AIでタスク作成が楽になるという話に見えます。しかし、実際にはもっと大きく、仕事の入口、判断、実行、承認、監査をどのように設計するかという話です。

Asanaをよく使っている組織ほど、この変化の恩恵は大きいはずです。仕事の文脈がAsanaに集まっているほど、AIエージェントは良い補助者になり得ます。

ただし同時に、権限が広すぎる、承認が曖昧、ログを見ていない、止め方が決まっていない、という状態のままAIエージェントを入れると、事故の影響も大きくなります。

だから、まず決めるべきことは「AIを使うか使わないか」ではありません。

どの業務に入れるのか。何を見てよいのか。どこまで実行してよいのか。誰が承認するのか。どう監査し、どう止めるのか。

Asanaの発表は、その確認を始めるよいタイミングだと思います。クラウドネイティブでもAsanaを日常的に使っているので、このニュースはかなり気になっています。今後、実際の管理者設定や提供範囲がもう少し見えてきたら、より具体的な運用設計まで掘り下げたいです。