Gumloopの料金2026年版:クレジット1個の本当のコスト

まとめ

Gumloopは20,000クレジット付きのProプランが月額$37で、これに加えて要見積もりのEnterpriseプランがあります。無料プランはもう存在せず、14日間のトライアルはカード登録が必要で、事前にキャンセルしない限り有料サブスクリプションに移行します。

しかし$37は実際の価格ではありません。それは前払い金にすぎません。請求額を決める数字は1クレジット=$0.005です。Gumloopがパススルー型の料金体系に移行したためで、モデルのトークンは原価、計算リソースも原価、そこに8%のオーケストレーション料金が上乗せされます。つまり同じ質問でも2クレジットになることも200クレジットになることもあり、価格を決める3つの要素(エージェントが選ぶモデル、考える時間の長さ、接続されているツールの数)はいずれも登録時に固定されるものではありません。

覚えておくべき数字が2つあります。まず、Gumloop自身のドキュメントによると、$37プランは"7,400 credits at the $0.005 list price, plus 12,600 bonus credits"とのことです。つまりクレジット20,001個目は、実際の作業単位あたりで見るとクレジット1個目よりも約2.7倍高くつきます。次に、超過分はデフォルトで100万クレジット、つまり請求期間あたり$5,000が上限です。

もし自動化したい対象が一般的な業務のつなぎ込みではなく、特にサポートキューであるなら、チケット単位の料金は全く異なる形の請求になります。eeselはチケットあたり$0.40を請求し、メッセージ数やAIが考える時間の長さに関係なく1チケットが1単位です。

2026年のGumloop料金を一目で見る

GumloopはノーコードのAIエージェントプラットフォームです。ビジュアルキャンバス上でエージェントとワークフローを組み立て、Slack、Gmail、BigQuery、HubSpotなどに対して動作させます。同社はBenchmarkが主導する5,000万ドルのシリーズBを調達しており、Shopify、Ramp、Gusto、Samsara、Instacart、Opendoorが顧客として名前を挙げられています。

このカテゴリーに馴染みがない場合、役に立つ考え方の区分けは、これらのプラットフォームが売っているのはチャットボットではなくAIエージェントだという点です。あなたが購入しているのは他のシステムでアクションを実行するものであり、まさにそれゆえに座席単位のSaaSライセンスよりも料金を予測しにくいのです。

Gumloopの料金ページのプラン構成は、現在3段階ではなく2段階になっています。

最近2つの点が変更されましたが、多くの解説記事はまだ追いついていません。

無料プランは存在しません。 Gumloopのクレジットに関するドキュメントにはそれがはっきりと書かれており、さらに旧無料プランで作成されたアカウントは残っている残高をそのまま保持するものの、その残高はもう毎月更新されないとも書かれています。もしGumloopが月5,000の無料クレジットをくれると書かれたページを読んだなら、そのページはもう存在しないプランについて説明しているのです。代わりに得られるのは、カード登録が必要で顧客1人につき1回限り、終了時にキャンセルしない限り有料サブスクリプションに移行する14日間のProトライアルです。

2つ目の変更はより大きく、この記事全体のテーマです。

請求額を実際に決める唯一の数字

Gumloopは課金方式をパススルー型に書き換えました。同社自身の発表記事は、その仕組みについて驚くほど率直に述べています。"We pass through tokens at cost / We pass through compute at cost / We charge a base 8% orchestration fee on top of these costs."

これによりクレジットはクーポンではなく通貨になります。為替レートは公開されています。1クレジット=$0.005なので、$1で200クレジット購入でき、$0.03のモデル呼び出しは切り上げて整数クレジットにすると6クレジットになります。

eeselで提供しているインテグレーションのために課金ドキュメントを読み込んできた経験から言うと、クレジットのドキュメントにあるこの一文こそが重要です。"Agent credit costs are variable. The same agent might cost 2 credits for a quick question and 200 for a deep research task. You pay for what the agent actually does, not a fixed per-message price."

それは公平な課金方法です。同時に予測しにくい方法でもあり、この2つの事実は表裏一体です。あなたは20,000個のアクションを買っているわけではありません。あなたはリスト価格ベースで$100分の基礎的な支出を買っているのであり、「やってほしかったこと」と「クレジット」の間の交換レートは、エージェントが実行時に選んだモデルによって決まります。

これは私の側の会話でも繰り返し出てくる話です。あるバイヤーが1回のテスト日で200件のやり取りに達し、実際の月間ボリュームである約9,000件でこれがどうなるのか、すぐに不安になり始めたのを目にしたことがあります。その不安の正体は単位あたりの価格ではありませんでした。普通の火曜日にどれだけの単位数が発生するのか分からないことだったのです。

エージェントとのチャット1回にかかる5つの計測項目

Gumloopのドキュメントによると、エージェントとの会話は5つの別々の項目の合計として請求されます。

Gumloopは実際に計算した例を公開しており、これは良い姿勢です。Chat & Reasoningに400クレジット、Computeに10クレジット、Tool Callsに15クレジットを使うチャットは"pays a 34 credit fee (8% of 425, rounded up), for 459 credits in total."となります。1クレジット$0.005なら、その1回の会話は$2.30です。

細かい注記の中に見逃せない3つの詳細があり、これらが第1の計測項目を静かに膨らませます。

• メッセージのたびにそれまでの文脈が再送されるため、長い会話は1ターンあたりのコストが短い会話より高くなります。
• 接続された各ツールはその定義をプロンプトに追加します。めったに使わない20個のインテグレーションを接続すると、1メッセージごとのコストが高くなります。
• ユーザーの1メッセージが複数のAIステップを引き起こすことがあり、"and each step is billed separately."

モデルの選択は3つの中で最も大きなレバーであり、その差は圧倒的です。Gumloopの現在のRecommendedプリセットはGrok 4.6で、その両側にFastestとSmartestのプリセットがあります。高ボリュームのタスクで最先端モデルを小型モデルに切り替えると、実際のプロバイダー料率を支払うことになるため、第1の計測項目は桁違いに変化します。私のClaudeの料金の解説を見ると、その通過する幅の感覚がつかめるはずです。

Computeには面白い例外があります。ユーザーからの応答を待っている間はコストがかからず、自社VPCで稼働するEnterprise顧客はComputeを一切請求されません。

自分のGumloop月額料金を見積もる

段階的な料金表を渡すのではなく、実際の計算式をここに示します。デフォルト値はGumloop自身が公開している459クレジットの例を再現しているので、自分の数値を入力する前に計算を検算できます。

「エージェントが稼働する分数」のスライダーを少し動かしてみてください。1分から5分に増やすとチャット1回あたり20クレジット増えますが、これは何でもないように見えて、数百回の会話に掛け合わせると効いてきます。Computeは人々が忘れがちな計測項目です。なぜならこれだけが結果ではなく時間に対して課金されるからです。

これはまた、エージェントが得意とされていること自体を罰する計測項目でもあります。ルールベースのボットは、その仕組み上、実行ごとに固定コストです。難しいケースについて4分間考えるエージェントは、1分で答えるエージェントの4倍のコストがかかります。これはルールベースのチャットボットを置き換える前に理解しておく価値のあるトレードオフです。

ワークフロー実行はまったく別の計算式で課金される

これはGumloopの料金体系の中で最も重要な区別ですが、料金ページではなくドキュメントの奥に埋もれています。

Computeとオーケストレーション料金はエージェントチャットにのみ適用されます。 ワークフローの実行は、それが単独で動くものであれ、エージェントから呼び出されるものであれ、ノードのコストのみで課金されます。公開されている計算式は1 credit (base) + the cost of each node that runsです。

そして、ほとんどのノードは無料です。Gumloopはテキスト操作(Combine Text、Text Formatter、Find & Replace)、ロジック(If/Else、Switch、Router)、ループ、データ変換、入出力、そして"most integrations (Google Sheets, Slack, Gmail, Airtable, Salesforce, etc.)"をゼロクレジットとして挙げています。同社自身の例では、Google Sheetを読み込み、行をフィルタリングし、Slackメッセージを送信して、合計コストは1クレジットです。

この無料インテグレーションのリストは注意深く読む価値があります。なぜならそこがこのプラットフォームで最も安上がりな部分だからです。ここでは無料になっているのと同じコネクターが他の場所では計測対象になっており、そうした細部こそが移行を左右します。

移行を検討している場合、私はn8n側の同等機能をコネクターごとにマッピングしています。Google Sheetsはほとんどのチームが最初に確認するものです。Salesforceの解説では、ノード数が最も速く増えるCRMのケースを扱っています。

つまり同じ仕事を2通りの経路で処理すると、まったく異なる請求額になります。あるタスクが決定的すぎるほど明確でスケジュール型ワークフローとして表現できるなら、それをエージェントに会話形式でやらせるよりも実質的に安く抑えられます。これはこの製品における単一最大のコストレバーであり、プランの選択ではなく設計上の選択です。これはワークフローを構築する前に決めておく価値のあることであり、後からではありません。

このレバーには落とし穴があり、それこそが私がこれに5年計画を立てない理由です。料金ページでは今や製品のこちらの半分を「Workflows (Legacy)」と表示しています。重心は明らかにエージェントへと移りました。この安価な経路は今も機能し、今もドキュメント化されていますが、それは会社が明らかに距離を置きつつあるプラットフォームの部分に頼ることになります。これは、チームと話した後にあるRedditのコメント投稿者が報告した内容と一致します。ワークフロー機能を使うのではなく、エージェントループを構築するよう誘導されたとのことです。

実際にクレジットがかかるもの

有料ノードは、クレジットのドキュメントによると以下の通りです。

Gumloop自身がこの落とし穴を指摘しており、これは言い換えるより引用したい部分です。"Enriching 100 contacts costs 6,001 credits (1 + 60 x 100)"。このループひとつだけでProの月間割当の30%、つまり$37のうち$30を消費します。ループモードのノードは項目ごとに1回実行されるため、各ノードのコストはリストの長さに比例して掛け算されます。

サードパーティツールの料金は1クレジットのツール呼び出しに加算され、呼び出し単位ではなく結果単位で課金されます。ApolloのインテグレーションはPeople Searchを結果1件あたり3クレジットで請求するため、50人がヒットする検索は3ではなく150クレジットになります。

これが、社内オペレーションではなくgo-to-market自動化を運用している人々をクレジットモデルが痛めつけるポイントです。エンリッチメントと検索は、実行回数ではなくリストの長さでスケールする2つのノードだからです。これがあなたのユースケースなら、私のAIマーケティング自動化ツールのまとめもあわせて確認する価値があります。

誰も言及しないボーナスクレジットの崖

これは私が見つけるとは思っていなかった詳細で、Gumloop自身のドキュメントに書かれています。

$37のProプランの20,000クレジットは、"7,400 credits at the $0.005 list price, plus 12,600 bonus credits"という内訳になっています。一方で超過分は、補助のない定価$0.005で課金されます。

割り算をしてみると、含まれるクレジットは1個あたり約$0.00185になります。超過クレジットは$0.005です。つまり20,000を超えた限界クレジットは、プラン内の平均クレジットと比べて1ドルあたりの作業量が約2.7倍少なくなります。

これらは何も隠されていたり不誠実だったりするわけではなく、寛大な含有量というのはほとんどの従量課金型ソフトウェアの仕組みそのものです。しかしこれはコスト曲線が線形ではないことを意味し、「多少の超過分くらいなら払えばいい」というのはプラン料金が示唆するよりも悪い取引です。これはまた、「$37から」という一文がほとんどの人が読み取る以上の意味を持っている理由でもあります。

この着地を和らげる2つのガードレールがあり、これらは他社よりも優れています。従量課金はデフォルトで無効になっているため、20,000クレジットに到達するとエージェントは静かに2つ目の請求を始めるのではなく停止します。超過分は自分で有効化しなければなりません。一度有効化すると、Proの超過分には常に上限があり、デフォルトでは請求期間ごとに100万超過クレジット($5,000)が上限で、サブスクリプションページからより低い上限を設定できます。クレジット使用量のメールは75%と90%で送信されます。

これら2つの間で、Proの最悪ケースの請求額は把握可能な数字になります。$37に加えて設定した上限、デフォルトのままなら$5,037です。これはほとんどの従量課金型ツールが事前に教えてくれる以上の情報です。

自前のキーを持ち込む:クレジット80%減、料金は倍増

すでにAnthropicやOpenAIに直接支払っているなら、BYOKは計算を大きく変えます。Chat & Reasoningは0クレジットまで下がり、ワークフロー内のAIノード、画像生成、文字起こしも0まで下がります。

落とし穴は、オーケストレーション料金が8%から16%に倍増し、それが実際に請求される金額ではなく、その実行が本来いくらの価値だったかを基準に計算される点です。Gumloop自身が公開している同じチャットのビフォーアフター比較は以下の通りです。

これはクレジットの80%削減ですが、節約ではなく支出の移動です。トークン分は自分のプロバイダーへ支払うことになります。BYOKにはPro以上のプランが必要で、各キーはそのプロバイダーが提供するモデルのみを免除し、Proユーザーは個人用または共有チーム用のキーを設定できますが、組織単位のキーはEnterprise専用のままです。またサードパーティのツール料金には影響しません。これらは直接そのまま通過するためです。

それが割に合うかどうかはシンプルな話に帰着します。プロバイダーとの実効レートがリスト価格より良ければ、BYOKに軍配が上がります。Gumloopのボーナスクレジット補助に頼っていた場合は、そうならないかもしれません。

Gumloopが請求しないもの

計測項目だけを数える料金記事を書くのは簡単なので、モデルが買い手側に有利な部分について率直に述べておく価値があります。

失敗したツール呼び出しは課金されません。これははっきりと述べられています。"Every successful tool call costs at least 1 credit. Failed calls are not charged." 途中で停止したワークフローは、失敗前に実行されたノード分のみが請求されます。人間の対応を待つことにコストはかかりません。座席数とチーム数はどちらのプランでも無制限であり、Zapierと違って2人目のチームメンバーはプランのアップグレードにはなりません。

透明性のためのツール群も他社より優れており、多くの従量課金型ツールがこれに匹敵するものを提供していないことから言及する価値があります。エージェントが作業している間に更新されるチャットヘッダー内のライブなコインバッジ、会話を計測項目ごとの行に分解するChat Detailsパネル、エージェントチャットやワークフロー実行でフィルタリング可能なクレジットログ、CSVエクスポートがあります。AIチケッティングの請求とボットが実際に行ったことを照合しようとしたことがあるなら、この会話ごとの内訳をありがたく感じるはずです。BYOK下で免除されたクレジットは取り消し線付きで表示され、「Free」とラベル付けされるので、その実行が本来いくらかかったはずかを確認できます。Insightsダッシュボードと、「先月ユーザーごとに何クレジット使ったか」といった質問に答える分析エージェントはEnterprise専用です。

Enterpriseはチャットごとのクレジット警告機能も得られます。設定した閾値を超えると、エージェントは一時停止し、続行前に承認を求めるAction Requestを発行します。これは良い設計であり、本番データに対してAIエージェントを実行するどのチームも欲しいと思うべき種類の制御です。これはエージェントのハンドオフの背後にあるのと同じパターンの予算版です。機械がどこで止まり、人間がどこで引き継ぐかを事前に決めておくということです。

これらすべての中にある隙間は次の点です。トークンと計算リソースを消費した後にエラーになったエージェントチャットが返金されるかどうかについて、公開された記載はありません。失敗したツール呼び出しはカバーされています。失敗したワークフローもカバーされています。失敗した会話はどちらの方向にも言及されておらず、その時点でトークンとセッション分はすでに消費されているため、素直に読むならそれらはコストがかかるということです。これは契約前に営業に尋ねる価値のある質問です。

実際に人々が請求額について語っていること

感情はある1本の線できれいに分かれます。そのワークフローがどれだけの期間本番稼働しているかです。導入1週目のユーザーはキャンバスを気に入ります。3ヶ月目のユーザーは「クレジット」と言い始めます。

"But Gumloop seems to freeze or have issues too frequently and then burns credits running faulty automation."

r/automation thread, Reddit

この点については正確を期す価値があります。というのもこれは最も繰り返される不満であり、ドキュメントは今や部分的にそれに答えているからです。Gumloopは失敗したツール呼び出しに課金せず、失敗したワークフローもすでに実行されたノード分のみを請求します。未対応のまま残っているのはエージェントチャットのケースで、まさにあのスレッドが描写しているものです。

「簡単だが割高」という受け止め方は、1年分のスレッドを通じて驚くほど一貫しています。

"-> Gumloop : Easy to build, easy to run but little more expensive."

Alexmamy, Reddit

"I think the biggest tradeoff with Gumloop is simplicity vs ownership. It's incredibly fast to prototype AI workflows, especially for non-devs, but once workflows become mission critical people start comparing reliability, hosting, and cost much more seriously."

EnvironmentalOil5959, Reddit

Gumloopを評価すべき点として、料金への不満に対して肩をすくめるのではなく公式な対応をしました。$37のエントリーポイントはそれによって生まれたものです。Gumloop自身の投稿はそれを"making the starting point on Solo 10,000 credits for $37/mth down from $97/mth for 30,000 credits"と表現し、創業者は直接こう発表しました。

"We heard you. Gumloop is getting a more affordable pricing tier. $37/month for 10,000 credits"

Max Brodeur-Urbas, X

SoloとTeamはその後Proに統合され、これが現在の「20,000クレジットで$37」という数字の出どころです。この移行について正直に付け加えると、20万クレジット未満ではユーザーは同じ金額でより多くを得ましたが、上限に近いところではより少なくなり、30万クレジット層は25万に、50万クレジット層は33万に、価格は変わらないまま下がりました。ヘビーユーザーは実質的な削減を被りました。

レビューサイトについて1つ注意点があります。G2では7件のレビューで4.8/5、Capterraでは2件で5.0となっていますが、G2の7件のレビューのうち6件は2026年1月の2週間の間に投稿されたものです。これらのスコアは、どちらの方向であれ、定まった評価としてではなく、少数かつ最近のものとして扱ってください。

課金単位で見るGumloop対Zapier、n8n、Make、Lindy

このカテゴリーで最も高くつく間違いは、単位を比較せずに価格だけを比較することです。それらは互いに換算できません。

このギャップはボリュームではなく複雑さによって広がります。10レコードを処理する10ステップのワークフローを1回トリガーすると、n8nではおよそ1実行、Zapierではおよそ10タスク、Makeではおよそ91オペレーションになります。n8nは自社の料金ページでこの点を主張しており、1回の実行が他社では10,000オペレーションに相当するものを代替できると述べています。

この単位の問題は、単一のドル金額を比較する前に検討する価値があります。私のMake対n8nの比較記事ではこれを詳しく扱っています。エージェント時代版の同じ疑問については、AgentKit対Zapierが、モデルプロバイダー自身のオーケストレーションがタスク単位で計測される既存プレイヤーに対してどう位置づけられるかを扱っています。

移行の途中ではなく比較検討リストの途中でここにたどり着いたなら、Makeの代替のまとめがより広い分野をカバーしています。座席単位のクレジットに抵抗があるなら、Lindyの代替がより近い内容です。

Gumloopの単位は特定の意味で異例です。それは同じアクションが安定した価格を持たない唯一のものだからです。Zapierのタスクは、AIステップが賢くても単純でも、タスクはタスクです。Gumloopのクレジットは基礎となるモデルの請求額をそのまま追いかけるため、より誠実であると同時に予測しにくいものになっています。

Gumloopの料金が実際に合うのは誰か

向いているケース: 1人か2人が多くを構築する小規模チームで、1回あたりの価値が高くボリュームが中程度な会話型エージェントを運用する場合。リサーチ、エンリッチメント、レポーティング、社内のナレッジベース検索など、$2の会話が誰かの午後の20分を置き換えるような仕事です。$37プランでの座席数無制限は、Zapierの座席制限と比べて異例なほど寛大であり、1回の実行が本当にお金の価値を持つエンリッチメントやリサーチ業務であれば、実際のモデルコストに8%を上乗せして支払うのは公正な取引です。すでにプロバイダー契約を持っておりBYOKを有効化できるチームが最も得をします。

向いていないケース: ボリュームが多く1回あたりの価値が低い自動化。何千もの小さな決定論的なジョブを実行しているなら、コンピュートと8%の上乗せ料金を抱える会話型エージェントではなく、n8nの実行単位モデル、あるいは(エージェントではない)Gumloopのワークフローの無料ノード構造の方が適しています。財務のために固定された予測可能な月額数字が必要な場合や、5件の同時ワークフロー実行が実質的な上限になる場合も向いていません。Proはこの上限でキューではなくHTTP 429の厳格な拒否になるからです。

顧客対応のボリュームは、この向いていないケースの中でも最も鋭い形です。サポートのトラフィックは、突発的な請求額を最も避けたい日にこそ急増するものであり、そのため私はAIカスタマーサービスのコストをまず料率の問題としてではなくボリュームの問題として扱っています。

私の見解: Gumloopの料金体系はこのカテゴリーの中で知的に最も誠実なモデルであり、同時に最も予算を立てにくいものでもあります。そしてそれは同じ性質を両側から見たものにすぎません。パススルー型の課金は、使わなかった安価なモデルにマークアップを支払うことが決してないという意味です。同時にそれは、あなたの請求額があなたのエージェントが実行時に下す判断の関数であるという意味でもあります。超過上限をデフォルトの$5,000のままにせず、意図的に設定した状態で始めるべきです。

サポートを自動化する場合の意味

上記すべてに対する1つの注意点として、一般的な自動化プラットフォームは一般的な自動化のために価格設定されています。具体的な仕事がサポートキューであるなら、単位のミスマッチはより深刻になります。サポートチケットは自然な大きさを持つ作業単位ですが、クレジットはそうではないからです。クレジット制のキャンバス上にカスタマーサービスの自動化を構築することは間違いなく可能で、実際にそうしている人もいます。ただ請求額は、あなたのサポートリーダーが認識できるものを追跡しなくなってしまうだけです。

これがeeselの背後にある設計上の判断です。eeselはチケットあたり$0.40を請求し、メッセージが何往復あろうと、顧客が何回返信しようと、AIがどれだけ考えようと、1チケットは1つのタスクです。プラットフォーム料金もなく、座席料金もなく、最低利用料金もありません。月1,000チケットなら$400で、それぞれのチケットが2ターンだったか12ターンだったかに関わらず$400です。この計測単位はあなたのチームがすでに数えているものと一致しているため、請求額はコンピュートの請求書ではなくサポートワークフローのレポートのように読めます。

具体的に指摘したいことがいくつかあります。これはこうした問題がうまくいかなくなるのを実際に見てきた経験から来ているものです。

• クレジットカードなしで$50分の無料利用から始められます。これはカードが必要で自動的に切り替わるトライアルとは異なる提案です。
• 月間利用上限があり、デフォルトは$250で、50%、75%、100%でメールアラートが届きます。上限に達するとエージェントは一時停止します。
• 段階的に展開できます。月間1,000チケットのうち200件をAIに振り分ければ、その200件分だけ支払い、人間が対応したチケット分は決して支払いません。
• ノードのキャンバスを最初に手作業で構築させる代わりに、既存のナレッジベースと過去のチケットで学習します。
• eeselは本番のキューに触れる前に、あらゆる展開を過去のチケットに対してシミュレーションします。自信ありげなボットが間違った回答をするのを見てきた経験があるので、それを今朝のチケットではなく前四半期のチケットで発見したいからです。

すでに使っているヘルプデスクに接続するため、Zendeskを使っているチームは何も移行することなく試すことができます。Freshdeskも同様です。Gorgias上のShopifyストアも変わりません。

まだ「そもそもこれをやる価値があるのか」という段階にいるなら、サポートチケット自動化についてのより広い議論は別の読み物として役立つでしょう。

もしあなたの自動化が十数個のSaaSツールをまたぐ業務のつなぎ込みなら、Gumloopの方が形として適したツールであり、私はそう伝えるでしょう。もし対象がヘルプデスクで、請求額をトークン消費量ではなくチケット量のように見せたいなら、eeselを試してみてください。既存のチケットシステムに接続し、数分で過去のチケットを使って学習します。