Gumloop、$50M調達でAI workflowを全社員のagent基盤へ広げた転換

Gumloopは、社内のツールとデータをつなぎ、AI agentに業務を実行させるplatformです。

創業時のno-code automationから、agent・MCP・knowledge baseを含む全社向け基盤へ広げています。出典

Max Brodeur-UrbasとRahul Behalは、VancouverのbedroomでDiscordの非技術ユーザー向けside projectを始めた。

短いiterationとユーザーとの会話を重ね、no-code automationとして形にした。出典

小さなside projectからの出発

創業者たちは最初から巨大なAI platformを作ろうとしたのではない。

ユーザーが抱える一つの不便をworkflowにし、使われ方を観察した。出典

workflowからagentへ

Foundation modelの進歩に合わせ、Gumloopはdrag-and-drop workflowだけでなく、tool選択、knowledge、MCP、会話を組み込んだ。

Max Brodeur-UrbasとRahul Behalは「Raising money is not the goal — building a product people love is」と書いている。出典

調達を次の転機にする

Series Aの$17M、続くSeries Bの$50Mは、資金そのものより、全社員がAI-nativeになるplatformを作るための手段として位置づけられた。出典

今のGumloop

現在はagent、Brain、MCP、SDK、triggersをまとめ、個別の自動化から会社全体の実行基盤へ進もうとしている。

Gumloopの道のりは、AIを導入する最初の入口をworkflowに置き、成果が見えた後にagentへ広げる順序として読める。

Gumloopは、営業・マーケティング・サポートなど複数のSaaSを横断する業務担当者の痛みに刺さります。

SQLや個別automationを専門部署へ頼まず、既存データから結果まで進めたいチームが対象です。出典

顧客事例ではInstacartやGustoなどの利用が示され、単なるchatではなく業務の実行面を狙っています。出典

connector、agent runtime、Brain、MCP、利用ノウハウを一体化したworkflow基盤が障壁です。

個別のLLM機能ではなく、会社のデータと業務手順を蓄積するほど乗り換えコストが生まれます。出典

強い二面市場型ではありません。

顧客内でagentとskillsが増えるほど利用価値は上がりますが、外部ユーザー数そのものが品質を自動的に高める構造は限定的です。

営業、RevOps、マーケティング、サポート、データチーム。

複数ツールの手作業を減らしたいが、専任エンジニアを毎回割けない企業に向きます。

現場の仕事場に接続するconnector、workflowからagentへ段階的に移れるUX、顧客事例を通じて用途を具体化するGTMが強みです。

Series B発表では、使いやすさと柔軟性、顧客へのサービス姿勢が採用理由として語られています。出典

ARR、retention、agentの成功率は公開情報から確認できません。

自律実行が広がるほど、権限設定、誤実行、credit消費、モデル品質の差が導入障壁になります。

Enterpriseで安全性を説明し続ける必要があります。出典

テンプレートとユースケースページでself-serve導入を促し、顧客case studyでenterpriseへ拡張します。

Proの月額課金とcredits、Enterpriseのcustom pricingを併用し、利用量と安全要件に応じて単価を上げる設計です。出典

主要チャネル: content, customerStories, productLedGrowth, community

AI productはモデル性能だけでなく、接続先、権限、承認、再利用できるskillsまで設計して初めて業務基盤になります。

Gumloopはworkflowの透明性を残しながらagentへ拡張する順序が示唆的です。出典

日本では、まず営業日報、問い合わせ分類、会議準備など検証しやすい業務から始め、個人情報と承認を含むテンプレートを整えるべきです。

AIに任せる範囲より、誰が結果を確認するかを商品価値に含める必要があります。