何が起きたか

VB Transform 2026でVentureBeatのSam Witteveen氏と対談したAsanaの最高プロダクト責任者Arnab Bose氏は、新しい「オペレーティングシステム」としてAgentic Work Management（AWM）を説明しました。AWMはAIエージェントを個人専用アシスタントではなく、人間の隣で働き、指導（coach）できる「チームメイト」として扱います。すでに複数顧客で本番稼働しており、FedExは自社で移行のケーススタディを公開しています。

なぜ重要か：問題は「モデル」ではなく「記憶がないこと」

Bose氏の指摘の核心は、いまの企業AI導入の弱点がモデル性能ではなくステートレス性にある、という点です。MCP（Model Context Protocol）連携でLLMをSlackやGoogle Drive、Databricksにつなぐことは誰でもできますが、チャット型エージェントは呼び出しごとに記憶を失います。過去の実績データと競合調査からマーケ施策案を書かせても、それは真空の中の単発作業に終わり、次の担当者が再利用できるワークフローにはなりません。

AWMが依拠するのは、18年前から積み上げてきたWork Graphです。Asanaが「Pyramid of Clarity」と呼ぶ構造で、担当者と期限を持つタスクが最小単位、それがプロジェクト、ポートフォリオ、全社ゴールへと積み上がります。遅延した1件のデザインタスクが売上目標にどう波及するかを辿れる、リアルタイムの台帳です。AWMのエージェントはこの台帳に接続されるため、全社ゴールを参照し、プロジェクトのステータスを更新し、人間の同僚と記憶を共有できます。タスク完了時にはメタデータが記録され、その完了がプロジェクトの状態と上位ゴールをどう動かしたかまで登録されます。

実装で先に潰した3つの壁

第一はデータガバナンスです。ワークフローと人間のフィードバックから作られる共有メモリは、たとえば秘匿のM&Aプロジェクトで生まれた文脈を、同じエージェントを後から使う無権限の社員に漏らしてはなりません。Asanaは「何がメモリの生成をトリガーし、何が単なるタスク実行に留まるか」を制御するアクセス管理を作り込みました。エージェントの価値と情報漏えいリスクが同じ仕組みから生まれる以上、ここを後回しにした設計は企業では通りません。

第二は動的モデルルーティングです。複雑なタスクはAnthropicのOpusやOpenAIのモデルといったフロンティアモデルへ、軽いタスクは高速・安価なモデルへ自動で振り分け、利用者からプロンプトエンジニアリングを隠します。Bose氏は、ゼネラルマネージャー職の求人票作成を例に挙げました。公開求人、社内スタイルガイド、製品要求仕様書を横断参照させる作業です。狙いは「人間に仕事を頼むのと同じ感覚」で任せられることにあります。

第三はその副作用として生じた課金の抽象化です。タスクごとに計算量が違えばクレジット消費は読めません。予測不能な価格は、顧客が自衛のためにAIチームメイトの利用回数に上限を設け、結果として自社の従業員の手を縛る事態を招きます。Asanaはタスク完了あたり固定額という課金設計を選び、モデル選択・トークン数・実行回数はプラットフォーム側が飲み込む形にしました。

CoreWeaveの事例：決定論とエージェントの分業

早期採用企業のCoreWeaveは、決定論的なAI Studioのワークフロールールと複数のAIチームメイトを併用して新製品ローンチを回しています。従来はプロダクトマネージャーがインフラ・パラメータ・コストを書く複雑なフォームを埋め、人間のレビュアーが手作業で評価して財務・マーケ・ハードウェア各チームのタスクに分解していました。現在はPMが製品要求仕様書を指すGoogleドキュメントを書けば、決定論的ワークフローがそれを読んでプロジェクト構造を作り、タスクを割り当て、その後に専門エージェントが実行します。全体のステータスを監視してボトルネックを指摘するエージェントと、個別タスクの中でインフラコストを予測し過去予算と整合すれば承認を推奨するエージェントが分業する構成です。「全部AIに任せる」ではなく、構造化は決定論、判断はエージェントという線引きが実務的です。

「フレネミー」問題をどう見るか

AWMを動かすフロンティアモデルの提供元であるAnthropicとOpenAIは、同時に競合するエージェント製品も出しています。Bose氏はこの緊張関係を「我々全員が生きるべき現実」と認めた上で、AWMの持続性の根拠を18年分のUX・ワークフローデータと、業界別に作り込まれた標準業務手順（SOP）に置きました。AnthropicのClaude in Slack（Tag）のような製品はSlack内では機能するが、高度に整理されたチャンネルと、接続先アプリごとの個別認証情報が必要になる、というのが同氏の見立てです。モデルの力に軽量な価値提示を足したものと、エンドツーエンド利用を前提に作り込まれたものは別物だ、という主張です。

💼 事業会社視点：これは自社にどう効くか

日本企業の経営層がここから読み取るべきは、AIエージェント投資の勝敗が「どのモデルを使うか」ではなく「自社に権限管理された業務台帳があるか」��決まる、という点です。ERPやSFA、プロジェクト管理ツールを入れていても、実態が個人のExcelとメールに散っている会社では、エージェントに渡せる共有記憶がそもそも存在しません。まず着手すべきは、誰が・いつまでに・なぜやるかが構造化されたデータの整備で、これは18年かけてWork Graphを積んだAsanaの優位性を自社側で持つことに相当します。

SaaS事業者にとっては、タスク完了あたり定額というAsanaの課金設計が直接の競争圧力になります。従量課金でトークン消費を顧客に転嫁している製品は、顧客が利用上限を設けて自社の現場を縛るという同じ失敗をたどります。原価を吸収して価格を平準化できるだけの粗利設計とルーティング技術を、いま持っているかを点検すべきです。

受託開発・SIerには、CoreWeaveの事例が示す分業が示唆的です。フォーム記入とタスク分解の代行という受注は縮み、決定論ワークフローと専門エージェントの設計、そして業界別SOPの作り込みが売り物になります。ECのように業務手順が定型化された領域ほど、SOPをデータ化した側が先行します。