AIエージェント、Asana×StackAI 75M買収の3シグナル

Asanaが、no-codeのAIエージェントビルダーStackAIを約75百万ドルで買収しました。発表は2026年5月28日、Q1決算と同時に投じられたディール。金額だけ見れば、生成AIブームのM&Aとしては控えめな水準です。それでも僕がこのニュースに強く反応したのは、買い手の正体でした。

OpenAIやAnthropicのようなAIラボでもなく、Microsoftのようなクラウド大手でもなく、$3B規模のタスク管理SaaSだったのです。つまり「SaaSの本体がAIエージェントビルダーを自社製品として取り込んだ」最初の大型ディールが、今回起きた。これがAIエージェント市場の地図を確実に書き換えます。

ここ1年、僕はClaude Code+MCPで自分用のエージェントを組み、Zapierとn8nを試し、no-codeビルダー数本に触ってきた。「中小企業はno-codeビルダーを単独で導入すべきか、SaaS側のAI機能を待つべきか」。この問いで悩む読者から、ほぼ毎週相談を受けています。今回の買収は、その悩みへのひとつの答えになる出来事でした。

この記事を読み終わったあとにできること

「今週中に確認するプラットフォーム選定3点」のチェックリストを手にする。自社で導入中・検討中のno-code AIエージェントについて、「単独で続けるか、本体SaaSの動きを待つか」の方針を1つ決められる状態にします。読み終わったら社内Slackで共有し、週末までに方針案を1行で固める。ここまでが、この記事の出口です。

Asana×StackAI 75M買収、5月28日発表の事実関係

最初に、報道と公式リリースで確認できる事実関係を並べていきます。憶測の部分は後ろの章で別途明示する形にしました。

買収金額と発表日 SEC開示に基づき、買収金額は約75百万ドル。発表は2026年5月28日（木）の市場閉場後でした。AsanaのQ1決算発表と同時にアナウンスされた形です（Business Wire公式リリース、TechCrunch、Investing.com）。

StackAIとは何者か スタートアップ支援機関Y Combinator（通称YC）の2023年冬期コホート出身。創業者はTony Rosinol氏とBernard Aceituno氏で、両者ともMITのPhD保持者です。サンフランシスコ拠点。累計調達額は20百万ドル未満、うち直近のSeries Aで16百万ドルを調達していた（TechCrunch、PitchBookデータ）。

製品は、ノーコードでAIエージェントを設計・テスト・デプロイ・ガバナンスまで一気通貫で扱えるプラットフォーム。連携先として公式リリースが挙げているのは、Salesforce・AWS・Oracle・Docusign・Slack・Google Workspace・SharePoint・Asana、そして業界特化アプリ。導入実績の業界は金融サービス、製造業、ヘルスケア、専門サービス、テクノロジーです。

買収後の扱い StackAIは、Asana傘下になった後も独自ブランド・独立した製品として運営を継続します。創業者2名はAsanaに合流。これは、買収後すぐに本体に統合して名前を消すパターンとは違うシグナルです。

Asana CEOのフレーミング CEOのDan Rogers氏は、公式リリースでこう述べています。

“This acquisition accelerates our roadmap and marks the next phase of human-agent work. StackAI now lets them go further, agentifying the most complex business processes end-to-end, across every system and tool their business runs on.”

「human-agent work（人間とエージェントの協働）」を次フェーズと位置づけた発言です。Asana本体をhuman-agent teamsのオペレーティングシステムとして再定義しようとしている。StackAIは、その実行レイヤーを担います。

ここまでが報道ベースで確認できた事実関係。次の章から、僕の解釈に入ります。

「AIエージェント市場の収斂期入り」と呼べる3つの根拠

なぜ、たった75百万ドルのディールを「市場の地図が変わった」と捉えるのか。3つの根拠を順に説明します。

根拠1：SaaS本体が「自社製品」として取り込んだ

これまでno-code AIエージェントビルダーは、Zapier・Make・n8nのように「複数SaaSを横断する独立ベンダー」が中心でした。SaaS本体は、Salesforce Einstein StudioやNotion AIのように「自社サービス内のAIアシスタント」を持つに留まる。汎用的なエージェントビルダー機能は、外部接続で済ませる構図が主流だったのです。

今回Asanaが選んだのは、その外部接続を自社製品として吸収する道です。プラグインでも、提携でも、出資でもなく、買収。これは「AIエージェントの設計レイヤーは、SaaS事業者にとってアウトソース不可」と判断した、ということになります。

Y Combinatorの単独ビルダーが、$3B規模のSaaSに飲み込まれる構図。これが1件起きたなら、2件目・3件目が続くと考えるのが自然です。

根拠2：連携先がすでにSaaS市場と重なっている

StackAIが連携している先を見ると、Salesforce、Slack、Google Workspace、SharePoint、Oracle、Docusign。これ全部、企業内で「本体SaaS」として存在しているプロダクトばかりです。

つまり、no-code AIエージェントビルダーは、SaaS本体と顧客接点を奪い合う関係にすでに入っていた。Asanaにしてみれば「自社の上に乗っかるエージェントレイヤーを他社に取られる前に、自分で握る」のは合理的な判断と読めます。

同じ計算は、Salesforce・Microsoft・Atlassian・Notionも例外ではない。

根拠3：「human-agent OS」という言葉が出てきた

Dan Rogers氏の発言にある “operating system for human-agent teams” は、単なるキャッチコピーとして読み流せます。けれど、SaaSベンダーが「OS」を名乗るとき、それはプラットフォーム戦争の宣言。

Slackが「work OS」を名乗ったとき、Monday.comが同じフレーズを使ったとき、その後の3〜5年で何が起きたかを思い出してください。プラットフォームを名乗る側は、その上に乗るアプリやワークフローを自社経済圏に取り込もうとします。AIエージェント市場では、Asanaがその名乗りを上げました。

ここから先、競合各社は「うちのプラットフォームに合わせて作って」と言える立場を奪い合うフェーズに入ります。これが収斂期の意味です。

次に動く可能性が高いプラットフォーム3つ

Asanaが先陣を切った以上、追随する動きを予測しておく価値があります。あくまで僕の予測ですが、根拠は1件ずつ添えていく形で。

予測1：Notion / Monday.com / ClickUpのいずれかがno-codeビルダーを買収する

タスク管理・ナレッジ管理のSaaSは、Asanaと同じプレッシャーを受けます。「うちのユーザーがエージェントを組むときに、外部ビルダーを使わせるか、自社製品で吸収するか」の決断を6〜12ヶ月以内に迫られる。

Notionは2024年時点でNotion AIを自社開発してきましたが、「エージェント構築機能」までは公開していません。Monday.comもmonday AIで先行しつつ、複雑なワークフローエージェントは外部任せ。ClickUpはClickUp Brainを抱える同様の状況。

このうち1社が、StackAIに似た規模感のno-codeエージェントビルダーを買収する確率は、僕の体感では今後12ヶ月で50%を超えます。理由は単純で、社内会議で「うちもAsana追従の議論をしよう」が始まらないSaaS経営陣はいないからです。

予測2：Salesforce / Microsoftはオーガニック強化＋小規模買収

巨大ベンダーは、すでに自社のAgentforce（Salesforce）やCopilot Studio（Microsoft）でno-codeに近いビルダーを持っています。彼らが買収するとしても、機能補完目的の小規模M&Aに留まる可能性が高い。

ただし「業界特化のno-codeエージェントビルダー」、たとえば医療・法務・金融に強い小型スタートアップは、Salesforceなら買う動機があります。理由は、Industry Cloudの戦略と重なるから。

予測3：Atlassianがエージェントレイヤーを正式リリースまたは買収する

Jira/ConfluenceのAtlassianは、Rovo（社内AI）を持ちつつ、エージェント構築の正式機能はまだ限定的。Asanaがhuman-agent OSを名乗った以上、Atlassianが沈黙を続けるとは考えにくい。

買収か自社開発かは読めませんが、6ヶ月以内にエージェント構築の正式アナウンスが来る可能性は高い。これは公式発表が出てから「予測の答え合わせ」をしてみてください。

僕がここで言いたいのは、「次のAsana」が誰になるかを当てることが目的ではない、ということ。複数の追随が起きる前提で、自社の選定方針を先に作っておく。それがこの章の役割になります。

中小企業担当者が今週確認すべきプラットフォーム選定3点

ここから実務に入ります。買収を読み解いて終わりにせず、自社の判断に翻訳していきましょう。今週中にできる3点を、順番に並べていきます。

確認1：自社の中心SaaSのAIエージェント機能ロードマップ

最初にやることは、シンプルな話。「自社が一番使っているSaaSは何か」を1つに絞り、そのベンダーのAIエージェント機能ロードマップを確認する。

確認の手段は3つ。

• ベンダーの公式ブログで直近6ヶ月のAI関連リリースを追う
• 担当営業に「貴社のno-codeエージェント構築機能のリリース予定」を直接質問する
• 競合SaaSの動向（Asanaのような買収）を引き合いに出して、自社向けの優先度を聞く

ここで「ロードマップを共有してもらえない」「担当者が答えられない」という反応が返ってきた場合、それ自体が判断のシグナルになります。SaaS側に明確な方針がないなら、自社で先に動く必要があるということ。

確認2：「自社で組んだAIエージェント」のSaaS吸収リスク

すでにno-codeビルダー（Zapier・Make・n8n・StackAI等）でエージェントを組んでいる場合、次のリスクを評価してください。

• 使っているビルダーが、自社の中心SaaSと競合する大手に買収されたら？
• 買収後にビルダー製品が統合・廃止されたら、現在のワークフローはどうなるか
• 移行先候補が、自社の中心SaaS本体の自社製エージェント機能になるシナリオは現実的か

具体的には、エージェントごとに「依存ビルダー」「代替手段」「移行コスト」を1行で書き出すだけで十分。30分もかからない作業です。

StackAIは買収後も独立運営を継続する明示がありますが、これは今回のケースの話。次の買収が同じパターンとは限りません。

確認3：「単独no-codeビルダー」vs「SaaS統合型」の判断軸

今後の新規エージェント構築では、選択肢が大きく2つに分かれます。

• 単独no-codeビルダー型（Zapier・Make・n8n・StackAI等）：複数SaaS横断、柔軟性高い、ただし提供元の事業継続リスクあり
• SaaS統合型（Asana×StackAI、Salesforce Agentforce、Notion AI等）：1つのSaaS内で完結、深い統合、ただし他SaaSへの依存度低下が前提

僕の現時点の判断軸は、こうです。業務の中心が1つのSaaSに集中している組織はSaaS統合型を優先、複数SaaSをまたぐ業務が主体の組織は単独ビルダーを継続。ただし後者でも、選ぶビルダーは「資金調達が厚く・上場準備かそれに近い段階」を1つの基準にする。買収・統合リスクを下げる狙いがあるから。

この判断軸を社内で1行に決めて共有する。これが今週の最大の成果です。

僕がこの買収から1週間で変えた3つの判断

ここから実体験ベースで3つ書きます。読者の参考用としてどうぞ。

変更1：Claude Code+MCPの「単独構成」を主軸に据え直した

僕は記事執筆ワークフローの自動化にClaude CodeとMCPサーバーを組み合わせて使っています。一時期、no-code AIエージェントビルダーへ一部を移す選択肢も考えていた。理由は、開発スキルがない仲間にも触ってもらいやすいからです。

今回の買収を見て、その方針を保留にしました。買収・統合リスクが読みづらい時期にビルダー側へ寄せると、移行コストが後で跳ねると判断したからです。Claude Code+MCPは「Anthropicという1社」への依存ですが、エコシステムが整うまでこちらに賭ける方が結果的に安定する。

詳しい構成と組み方は AIエージェント作り方、ノーコード3ルート で別記事にまとめてあります。今回の買収を踏まえて、3ルートの優先順位が一段変わった感覚です。

変更2：「単独ビルダーで組んだ既存エージェント」の棚卸し

僕の場合、Zapier・n8nで組んでいた既存エージェントが小さくいくつかありました。それぞれについて「依存ビルダー」「代替手段」「移行コスト」を表に書き出した。

結果、3本中1本は「Claude Code+MCPに移行可能」、残り2本は「単独ビルダーで継続だが、代替プランを文書化」と決まりました。30分の作業ですが、頭の中で漠然と抱えていた不安が言語化されただけで、判断スピードが上がります。

運用フェーズで起きやすい落とし穴は AIエージェント、運用フェーズの3つの落とし穴 でまとめています。今回の棚卸しは、その3つ目「ベンダーロックイン」の更新版だと考えてください。

変更3：読者相談への回答パターンを更新

冒頭で触れた「no-codeビルダーを単独で導入すべきか、SaaS本体のAI機能を待つべきか」という相談。これまでの答えは「規模次第」の一言でした。今週からは、もう1段細かく答えるようにしています。

• 自社の中心SaaSが明確にあり、その本体ベンダーが直近6ヶ月でAI機能を強化している場合、SaaS統合型を待つ判断もアリ
• 中心SaaSが定まっていない、または本体側にAI機能のロードマップがない場合、単独ビルダーで先に動く方が早い
• ただし単独ビルダーを選ぶときは、調達ステージと連携先の重なりを必ず確認する

この3点を1分で説明できる相手なら、相談の結論まで5分で到達できる。回答の質が上がった実感を、確かに持てています。

まとめ：M&Aは「市場の地図」が動いた合図

最後に整理します。

• 2026年5月28日、Asanaが約75百万ドルでStackAIを買収した（SEC開示・Business Wire・TechCrunch）
• 「SaaS本体がno-code AIエージェントビルダーを自社製品として取り込んだ」最初の大型案件
• 「human-agent teams」のオペレーティングシステムを名乗ったAsanaに続き、Notion・Monday・ClickUp・Atlassianのいずれかが追随する可能性が高い
• 中小企業担当者が今週やるべきは3つ。中心SaaSのロードマップ確認、既存エージェントの吸収リスク評価、「単独ビルダーvsSaaS統合型」の判断軸を1行で言語化

75百万ドルは、AIスタートアップのバリュエーションとしては大きくありません。けれど、市場の地図が動いた合図としては、十分すぎる金額です。読み終わったら、自社のSaaSロゴを1つ思い浮かべて、そのベンダーの最新リリースページを開いてください。今週の最初の一歩は、そこから始まります。

僕も同じことを、この記事を書き終わった直後にやるつもりです。