あらゆる社員がAIエージェントを作れるようにするというアイデアは、スタートアップの提案として最もよく見かけるものの一つになりましたが、本番環境で幅広く使われるところまで押し進めた企業は多くありません。Shopify、Gusto、Instacartで使われているエージェントビルダーのGumloopは、それを実現した数少ない例です。同社の歩みを見ると、大企業を獲得できたかどうかはモデルの性能そのものよりも、二つの設計判断にかかっていたようです。社員が普段使っているツールの中にエージェントを置くこと、そしてIT部門にセキュリティ、データアクセス、コストをしっかり管理する権限を渡すことです。
ノードエディターから自律型エージェントへ
GumloopがY CombinatorのWinter 2024バッチに応募したとき、社名はAgent Hubでした。AIエージェントという言葉が広く知られる前だったため、不動産仲介会社と勘違いする人もいました。
最初の製品はエージェントではなく、ワークフロー自動化ツールでした。ユーザーはビジュアルエディター上でノードをつなぎ、処理の手順を一つひとつ書き出します。当時の言語モデルはタスク全体を任せられるほど信頼できなかったため、チームはAIの出番を固定された予測可能なワークフローの中の狭い部分に限りました。これにより結果の信頼性を保ち、コストも抑えられました。
モデルの推論力と指示に従う能力が向上すると、チームは同じビルダーにエージェント機能を加えました。エージェントが自らタスクを進められるようになったため、ユーザーは途中の手順をすべて設定する必要がなくなりました。その後、導入数と利用量は急増しました。つまりGumloopは、その時点の技術で実現できるものを出荷し、モデルが追いついた段階で製品を引き上げたことになります。
現在、ユーザーはチャット形式の画面でエージェントを作り、用意されたコネクターの一覧から接続する業務アプリを選びます。エージェントはチームが普段やり取りしているSlackやMicrosoft Teamsに配置できます。エンジニアリングチーム向けには、SDK、REST API、そしてModel Context Protocolサーバーとして公開した数百のインテグレーションを提供しています。MCPは、AIシステムが外部のツールやデータにアクセスするための標準的な方式です。
個人ユーザーから大企業へ移った理由
初期の成長を支えたのは、個人開発者やソロのエンジニア、生産性向上に熱心な人たちでした。初期の利用例の一つは、2時間に及ぶDungeons & Dragonsのセッションを文字起こしして要約し、そのメモを全プレイヤーにメールで送るというものです。こうした使い方は目新しいものでしたが、経済的な価値は小さく、標準化も難しいものでした。
転機となったのは、オーストラリアのあるヘルステック企業です。同社はGumloopで複雑なリサーチのパイプラインを自動化し、散らばったウェブデータを集めて整理されたリポジトリにまとめました。高くつく業務上のボトルネックを解消するツールになら、企業ははるかに多くの金額を払うことがこれで分かりました。最初の1年間で、CEOは約1,100件の顧客発掘とオンボーディングの通話をこなし、どの機能に企業ユーザーが強く反応するかを一件ずつ確かめました。
最初の大型顧客となったInstacartは、営業活動から生まれたわけではありません。熱心な一人の社員が社内のSlackチャンネルでGumloopを紹介し始め、使い方を教えるスレッドを立て、同僚に実際に動く自動化を見せました。利用は部署をまたいで広がりました。Gumloopは後にこの社員を採用し、その社員が創業者たちに大企業の調達と営業の仕組みを教えました。
Shopifyは、Instacartの関係者からの紹介をきっかけに導入しました。Shopifyは同じ週に複数の自動化ツールを試し、社内で最も自然に広がるツールを見極めたうえで、一晩で4,000～8,000人の社員にGumloopを開放しました。数千人が手取り足取りの支援なしにそれぞれ自動化を作り上げたことで、製品が単独で使われることが確かめられました。Shopifyはその後、同社に出資しています。
▲ 口コミによる社内での導入拡大
大企業が実際に求めたもの
大手上場企業に売り込むと、要件は自動化機能をはるかに超えて広がります。Gumloopは次の機能を作る必要がありました。
| 要件 | 役割 |
|---|---|
| ロールベースのアクセス制御 | 職務に応じて機能とデータを制限する |
| SAMLシングルサインオン | 社員が会社のアカウント一つでログインできる |
| SCIMプロビジョニング | ユーザーアカウントを自動で作成・削除する |
| 監査ログ | 誰が何を実行したかを記録し、企業のデータレイクに送る |
| プライベートクラウドでのホスティング | 顧客自身のクラウド内でプラットフォームを動かす |
| 独自のAPIキー | 顧客が契約しているモデルを接続する |
顧客からは、外部の委託先には特定の機能だけを使わせるといった、きめ細かな分離も求められました。強力な機能をオフにするための管理機能を作る作業は、当初エンジニアにとってもどかしいものでしたが、大企業への導入に欠かせない条件だと分かりました。
ブラウザー自動化のように単純に聞こえる機能でも、その下には大きなガバナンスの層が必要です。IT管理者は、エージェントがアクセスしてよいウェブサイトを承認し、許可していない操作をブロックし、何が起きたかを確認できなければなりません。Gumloopはセッションリプレイ機能を作り、管理者が個々の実行を確認したり、並行して動く5,000のセッションをコストと安全の面から監査したりできるようにしました。
性能だけでなく、使われるための設計
創業者たちによれば、社員の利用を広げる最大の鍵は、人々がすでに働いている場所にエージェントを置くことです。別のポータルへ移動するたびに手間が増えます。同じ職務の同僚が公開のSlackチャンネルでエージェントに質問している様子を見ると、ほかの社員もそれを見て自然と使うようになります。
自由度の高いビルダーを前にして、何から始めればよいか分からず手が止まる「白紙の問題」には、テンプレートとワークショップで対応しました。テンプレートが三つしかなかった頃、Y Combinatorのパートナーは創業者たちに少なくとも100個は作るよう助言しました。Gumloopは現在、大規模なテンプレートギャラリーとユースケース別のページを用意しています。顧客チームとのワークショップでは、魔法の杖があったら何を自動化したいかと尋ねるだけで、数十のアイデアが一度に出てくることが多いといいます。
料金体系も同じ方向で変えました。
- Gumloopは、ChatGPT Plusのような消費者向けツールにならった月額$20と$40のプランで始めました。
- 企業が得る価値がはるかに大きいと分かり、Y Combinatorのバッチ期間中に価格を3回、2倍に引き上げました。
- クレジット制の時期を経て、コストに上乗せする方式に移りました。トークン、計算資源、外部APIは原価で請求し、それとは別にオーケストレーション料金を受け取ります。
創業者たちは、席数単位の課金は管理者が席を割り当て制にし、社員が試すのをためらうため、導入の妨げになると主張しています。コストを隠さずそのまま転嫁することで、Gumloopはマージンを隠すソフトウェアベンダーではなく、VercelやCloudflareと同じ分類のインフラとして見られるといいます。
モデルの選択とコスト管理
GumloopはClaude、OpenAIのモデル、Amazon Bedrock、企業独自のモデルゲートウェイに対応し、顧客がワンクリックでモデルを切り替えられるようにしています。同社は自らをスイスのような中立的なプラットフォームと表現しています。これと組み合わせているのが、同社が「agentic sovereignty」と呼ぶ考え方です。企業は自社のデータベース、実行トレース、認証情報、インテグレーションのロジックを自社のプライベートクラウド内で所有すべきであり、そうすれば一つのモデル提供企業に縛られない、というものです。創業者たちは、モデルを開発する企業が自社のAPI顧客と競合するアプリケーションを作り続けると見ており、だからこそこの所有権がより重要になると考えています。
モデルの選択はコストの問題でもあります。取締役会資料向けの成長モデルを作るような重要度の高いタスクには、最新のフロンティアモデル、つまり利用できる中で最も高性能な最上位モデルが必要です。一方、1時間に80,000回実行されるサポートの振り分けワークフローには、小さく安価なモデルが適しています。Gumloopの経験では、社員に任せきりにするとほぼすべてを最も高価なモデルに回してしまうため、管理者はどのチームやタスクがどのモデルを使えるかを一元的に管理する必要があります。
▲ 大小のモデルへのタスク振り分け
関心は現場から、展開はIT部門の主導で
企業での関心は、たいていXやLinkedInでGumloopを見つけた一人の社員から始まります。しかしIT部門が関わらなければ、その勢いは止まります。ITがAPIキー、データベースへのアクセス、シングルサインオンを用意するまで、試験導入では実際の社内ツールに接続できないからです。散らばったAIサービスの契約を、規制に準拠し監査可能な一つのハブにまとめられると分かると、IT部門の責任者が社内で最も強力な推進役になることも少なくありません。ある顧客の試験導入では、小規模な営業チームがわずか1週間で、それまでの3か月間の合計の3倍の営業パイプライン収益を生み出しました。これは一社の結果であり、一般的な成果ではありません。
経営陣の姿勢も重要です。ShopifyのようにAIに積極的な企業では、経営陣がすぐに道を開きました。一方、ヨーロッパのある大手ヘルステック企業では、組織の硬直性とIT部門の抵抗によって展開が遅れました。
Gumloopが経営陣に示す主張は、一つの考えに基づいています。毎日その業務を行っている人こそが、その業務を自動化すべきだというものです。Gumloopが置き換えたいのは、よくあるパターンです。マーケティングオペレーションのチームが何週間もかけて仕様書を書き、それをエンジニアや高額な外部コンサルタントに渡し、半分しか完成していないパイプラインを受け取るという流れです。
小さなチームを大きなチームのように動かす
Gumloopは自社の製品で会社を運営しています。社内のデータ用エージェントはすべての社内データソースに接続されているため、社員はSlackで質問するだけで、データアナリストがいなくても複数のデータベースにまたがる複雑な回答を約20分で得られます。営業の準備、顧客の利用量の急増や急減の通知、2週間ごとに開く教育プログラムの運営業務も、すべて自動化されています。8人のコアエンジニアリングチームは長時間かかるタスクやテストをエージェントに任せており、創業者たちによれば、エンジニア一人が約5人分、合わせて40人分の成果を出しています。
創業者たちはかつて、10人で企業価値$10億の会社であり続けたいと投稿したことがあります。GumloopがシリーズAを終えた時点では、チームは共同創業者2人とインターン2人だけでした。大企業向けの営業によってサポート、セキュリティ、インテグレーションの作業が大きく増え、現在の従業員数は45～50人です。その代わりに同社は、顧客が従業員数を250～300人だと思い込むかどうかを効率の指標にしています。創業者たちは現在の主な制約として、モデルの品質ではなくブランドの認知度を挙げ、その次に数百件たまった機能要望に応えるためのエンジニアリングの余力を挙げています。
資金調達については、ほぼすべてのスタートアップが業務の自動化を掲げるようになった今、実際に動くデモはピッチ資料の約100倍説得力があると感じたといいます。シードラウンドの後、NexusとBenchmarkが主導したラウンドは、正式なピッチ資料や調達プロセスなしに先回りして持ちかけられました。
開発する側と導入する側への要点
Gumloopの成長から得られる教訓は、短いチェックリストにまとめられます。
- モデルが未熟なうちは固定されたワークフローで信頼を得て、モデルの向上に合わせてエージェントへ広げる。
- 大企業に売るなら、アクセス制御、シングルサインオン、ユーザープロビジョニング、監査ログ、プライベートホスティングを中核機能として扱う。
- 社員がすでに使っているツールの中にエージェントを置き、共有チャンネルで同僚どうしが使い方を見られるようにする。
- テンプレートを数多く用意し、何を自動化したいかをチームに尋ねるワークショップを開く。
- 試験導入はIT部門と一緒に始めて権限とデータアクセスを先に解決し、どのチームがどのモデルを使えるかを決めておく。
- 一つの提供企業に縛られないよう、モデルを切り替えられる仕組みとエージェントのデータの所有権を確保する。
自社でエージェントプラットフォームを検討しているなら、どのモデルで動くかよりも先に問うべきことがあるかもしれません。業務に最も近い人が自分でエージェントを作れるか、そしてIT部門がそのエージェントの動きを管理できるか、という点です。