AI エージェント ops スタック — エンジニアなしで動く always-on エージェント

誰かが開くのを覚えていなければならないチャット画面ではなく、イベントで発火するエージェントが欲しくなったときに、少人数の ops チームが組む スタック です。Gumloop がエージェントを構築してホストし、n8n がシステム間で処理を動かして承認ゲートを強制し、Clay がエージェントの判断に必要な社外データを供給し、Slack で人間が可否を判断します。ツールは 4 つ、年間およそ $4K〜$12K、組織図にエンジニアは不要です。

これが必要かどうかを決める線引きはこうです。固定された既知の手順を自動化するための スタック ではありません。手順が一切変わらないなら — フォームが発火したらフィールド A をフィールド B に写す — n8n 単体のほうが安く、確実です。この スタック が費用に見合うのは、入力が非構造で、判断を 1 件ずつ下す必要がある場合です。本物の引き合いかどうか判別できないインバウンドメール、スコアカードに照らす履歴書、標準外の補償条項が入った NDA、解約の兆候かもしれないサポートスレッド。

各パーツの役割

• Gumloop はエージェント層です。 エージェントと ワークフロー はビジュアルなキャンバス上で組み立てます。トリガーノードが発火し、データが抽出ノードとモデルノードを通り、アクションノードが書き戻します。モデルはノード単位で選べるため、1 つのエージェントが同じ実行の中で条項抽出に Claude を、分類にはより安価なモデルを呼び分けられます。Gumloop は非構造の入力が、理由付きの構造化された判断に変わる場所です。状態は保持せず、システム・オブ・レコードでもありません。読み、考え、出力するだけです。

• n8n はオーケストレーションとガードレールの層です。 Gumloop と残りの SaaS のあいだの受け渡しは、すべて n8n の ワークフロー です。エージェントの出力を受け取り、設定した閾値と突き合わせ、無人で実行してよいか人間が必要かを判定し、システム・オブ・レコードに書き込み、失敗を捕捉します。監査証跡が残るのもここです。n8n の実行ログが、エージェントが何をなぜ行ったかの記録になります。誰かが最初に問い合わせてきたとき、これが効きます。

• Clay は社外データの層です。 インバウンドの リード、候補者、取引相手について考えるエージェントには、トリガーイベントに含まれていない事実が要ります。従業員数、資金調達、技術スタック、そのドメインが既存顧客かどうか。Clay は各照会を複数のデータプロバイダーにウォーターフォールで流し、ヒットした分だけ課金します。これがないと、エージェントはメール署名だけを根拠に自信満々の判断を下します。

• Slack は承認と監査の面です。 権限の閾値を超えるエージェントの操作は、実行前に承認・却下のメッセージとしてチャンネルに投稿されます。チームが省きがちなのがこの部品で、省くからこそ無人のエージェント案件は 2 か月目に止められます。何をしているのか誰にも見えなかったからです。

受け渡しの定義

1. イベント → トリアージ。 共有受信箱にメールが届く、フォームが送信される、フォルダにファイルが置かれる → Gumloop のエージェントがエンティティを抽出し、依頼を分類し、確信度つきの構造化 JSON を出力します。
2. 未知のエンティティ → データ拡充。 Gumloop の出力が CRM にまだない企業や人物を指す → n8n が Clay のテーブル実行を起動 → 拡充された行がエージェントのコンテキストに戻ってから、アクションが提案されます。
3. 提案 → ゲート。 Gumloop が推奨アクションを返す → n8n が閾値と照合します（確信度が基準を超え、金額が上限未満なら無人で実行。それ以外はエージェントが述べた判断理由を添えて、承認カードとして Slack に回ります）。
4. 承認 → 書き込み。 人間が Slack で承認をクリック → n8n がシステム・オブ・レコード（CRM、ATS、CLM）に書き込み、同じスレッドに実行結果を投稿します。判断とその結果が 1 か所に揃います。
5. 失敗 → 担当者。 エージェントの実行がエラーになる、Clay の照会が何も返さない、月次のクレジット消費が上限を超える → n8n のエラー ワークフロー が、黙って失敗する代わりに指名された ops 担当者へ Slack で通知します。

この組み合わせを選ぶ理由

各ツールが 1 つの層に収まり、層は重なりません。Gumloop が考え、Clay が事実を供給し、n8n が振り分けと制御を行い、Slack が人間を受け持ちます。この分離があるから、エンジニアでない人にも デバッグ できます。何かが壊れたとき、壊れた場所はちょうど 1 か所です。

2 つの統合案は挙げておく価値があります。どちらも正解になる場面があるからです。n8n 単体でも Gumloop の仕事はすべてこなせます。AI Agent ノードが任意のモデルをツールとメモリにつなぎ、セルフホストなら無料です。代わりに払うのは構築時間と、夕方 6 時に落ちた webhook を誰かが デバッグ できるという要件です。Gumloop 単体でも API を直接呼び、n8n を飛ばせます。失うのはゲートです。承認ロジック、閾値、リトライ、エラー振り分けが、強制力のある 1 つの層ではなく個々のエージェントに散らばります。エージェントが 2 つなら問題なく、10 になると手に負えません。

ここで既定のエージェント層に座席課金のアシスタント製品ではなく Gumloop を置くのは、そのプランがシート数無制限でクレジット課金だからです。ops チーム全員が同じエージェントの上に構築しても追加費用はゼロで、共有キューを回すことこそがこの スタック の存在理由です。

コストの実際

3〜10 名の ops チームの年間レンジです。ベンダーの料金ページを 2026-08-03 に確認しました。

• Gumloop: 年間 ~$450〜$3,000。Pro プラン 1 本のみで、年払い時は 20,000 クレジットの下限で月 $37 から。シート数は無制限、ワークフロー の同時実行 5 本、エージェントの同時チャット 25 本、ホスト型 MCP サーバー 1 台が付きます。クレジットはスライダーで月 1.5M まで増やせます。エージェントを毎日複数動かすチームは下限をかなり上回ります。恒久無料プランは 2026-07-30 に廃止され、14 日間の Pro トライアルに置き換わりました。2 週間を超えて $0 で試す道はもうありません。Enterprise（RBAC、SCIM/SAML、監査ログ、VPC）は見積のみです。
• n8n: 年間 ~$0〜$800。セルフホストの Community Edition は無料で、VPS 代として月 $20〜40 を見込みます。クラウドでは Starter が年払いで月 €20（実行 2,500 回）、Pro が月 €50（実行 10,000 回）。課金はステップ数に関係なく ワークフロー の実行回数単位で、ユーザー数はどのプランも無制限です。年払いで月 €667 の Business が SSO/SAML と Git によるバージョン管理を足しますが、この規模のチームはそこに届く前にセルフホストへ移ります。
• Clay: 年間 ~$2,000〜$5,400。Launch が月 $185（年払いで $167）、Growth が月 $495（年払いで $446）。2026 年 3 月の改定以降、課金は 2 本のメーター — プロバイダー照会の Data Credits と、AI 実行や連携の Actions — で走ります。トリガーのたびに Clay を呼ぶエージェント構成は、その両方を消費します。
• Slack: 年間 ~$450〜$1,800。Pro は年払いで 1 ユーザー月 $7.25（月払いは $8.75）、Business+ は年払いで 1 ユーザー月 $15。有料シートが要るのは承認する人だけです。

合計は年間 ~$4K〜$12K。 効いてくるのは隠れコストです。最初の 3 体を無人で回せる状態にするまでに ops 担当者の 2〜4 週間、エージェントが饒舌になるにつれて進むクレジットの上振れ、そしてノードが 30 を超えて読めなくなった Gumloop キャンバスの保守税です。

この スタック が置き換えないもの

• システム・オブ・レコード。 顧客、候補者、契約の状態を保持するものはここにありません。エージェントは CRM、ATS、CLM に対して動くだけで、それ自体にはなりません。
• トランザクションを伴う領域のエンジニアリング。 送金、プロビジョニング、本物のトランザクション境界や稼働率のコミットが要るものは、ホスト型キャンバスではなくテスト付きのコードの仕事です。
• データウェアハウス。 Clay は流れの中でレコードを拡充します。履歴分析、アトリビューション、レポーティングには依然として着地先が要ります。
• 判断の説明責任。 承認ゲートは責任をエージェントに移しません。承認を押した人が結果を負います。だからこそ判断理由は実行ログの奥ではなく Slack のメッセージ本文になければなりません。

適合ルール

この スタック が向くのは:

• 量が最も多い ops 業務が非構造テキストから始まり — 受信箱、応募、チケット、契約書 — 現状は誰かがその全部を読んでいる場合。
• ビジュアルキャンバスを扱えて JSON が読める ops 担当者はいるが、エンジニアリングの工数は今もこの先も確保できない場合。
• 1 件ずつの人手トリアージが実コストになる程度に量が多く（月 100 件以上が目安）、かつミスがコンプライアンス事故ではなく回復可能な程度に収まる場合。
• 閾値を言語化できる場合。エージェントに無人で何を許すか言えないなら、無人で動かす準備はできていません。

この スタック が向かないのは:

• 手順が固定で既知の場合。n8n 単体で回し、浮いた分は別に使ってください。
• 判断が規制対象の場合。候補者への不利益処分、法的ポジション、法定の通知義務が伴うもの。エージェントは起案と振り分けまでで、決めるのは人間であり、監査証跡がそれを示せなければなりません。
• 所有者が決まっていない場合。指名された責任者のいないエージェント構成は静かに劣化します。クレジットは膨らみ、連携の認証は期限切れになり、障害は数か月後に顧客からの苦情として表に出ます。
• そもそも業務プロセスを探っている段階の場合。エージェントは判断ルールを運用に落とすもので、ルールを見つけるものではありません。まず 1 か月、手作業で書き出してください。

よくあるバリエーション

• チームのキューではなく個人の受信箱が対象なら、Gumloop を Lindy に差し替えます。 現在の Lindy の パッケージ は個人単位です。Plus が月 $49.99、Pro が $99.99、Max が $199.99 で、接続できる受信箱はそれぞれ 2、3、5 まで。computer use は Pro から開きます。自社の料金ページで月 $8,000 の人間のエグゼクティブアシスタントと比較しており、想定顧客が誰かはそこに出ています。ルールはこうです。経営層 1 人のメール、カレンダー、フォローアップ → Lindy。複数人が構築する共有キュー → Gumloop。
• エージェントが自社データしか触らないなら Clay を外します。 サポートチケットのトリアージ、契約レビュー、社内文書の処理に外部拡充は不要で、Clay は スタック の中で最も大きな削除可能行です。CRM にまだない企業や人物についてエージェントが判断を始める日に戻してください。
• 作れる人が入ったら n8n 単体に畳みます。 技術職の採用が決まれば AI Agent ノードが Gumloop 層を吸収し、経常コストは VPS 代まで落ちます。ただし維持できる人の幅は確実に狭まります。実行するのはその人がチームにいるときであって、採用計画に載っているときではありません。
• Slack を Microsoft Teams に差し替えます。 承認の面としての形は同じで、n8n には十分な Teams ノードがあります。ほかは何も変わりません。

この スタック が回す具体的なエージェントの型は、インバウンドリードのトリアージ、NDA 受付のトリアージ、Clay と Claude による リード 拡充 を参照してください。前提となる考え方は、ops のための AI エージェント がスケジュール実行のスクリプトとエージェントの違いを扱っています。