Cassidy AI vs n8n：あなたのチームに本当に合うのはどちらか?

Cassidyの正体

Cassidyは、ドキュメントを大量に扱う企業向けに作られたAIエージェント兼ワークフロープラットフォームで、正直なところ理解するいちばん早い方法はトリガーピッカーを見ることだ。まずイベントから始め、その後にドキュメントを推論するステップをつなげていく。

このプラットフォームは4つのプロダクトで構成されている。Knowledge BaseとMeetingsがコンテキスト層を形成し、その上にAgentsとWorkflowsが自動化層として乗る。Workflowsページではこれらを「トリガー、AI推論、そしてツール横断のアクションを組み合わせる」複数ステップの自動化と説明しており、100以上の事前構築済みアクションと100以上のテンプレートが含まれる。モデル選択はステップごとに行え、選択肢は30以上あり、すべての出力は出典を示す。

ワークフローを自分で描くわけではなく、代わりに頼むだけだ。この構築画面はWorkflow Copilotと呼ばれ、名前の付いたステージを経ながらステップを組み立てていく。

会社の規模は小さいが資金は潤沢だ。2023年にニューヨークで設立され、社員はおよそ25人、2025年9月にHOF Capital主導で**$10MのシリーズA**を調達している。同社のCTOはHacker Newsで、これを「非技術系のナレッジワーカー」向けのプラットフォームだと説明しており、私に言わせれば、両社が書いた中でいちばん正直な一行ポジショニングだ。

サポート面で期待しすぎる前に指摘しておく価値がある。Cassidyはサポート関連資料のどこにもヘルプデスク製品の名前を挙げていない。Zendeskもなければ、FreshdeskもGorgiasもHelp Scoutもない。サポートは12あるソリューションカテゴリのうちの1つに過ぎず、宣伝されている展開先はSlackとTeams、それにブラウザ拡張機能だ。あなたのヘルプデスクの中にではなく、隣に座る存在なのだ。

n8nの正体

n8nは技術系チーム向けに作られたソースアベイラブルなワークフロー自動化プラットフォームであり、正直、見た目そのままの製品だ。

キャンバス上のノード、実行ログ、テストボタン、それが画面のすべてだ。どのノードを開いても、認証情報、リソース、オペレーション、そしてライブ結果プレビュー付きの式エディタが出てくる。

ここでの規模はCassidyとはまったく桁が違う。n8nは2025年10月に評価額$2.5bnで**$180MのシリーズCを調達し、その後2026年5月にSAPからの戦略的投資を受けて評価額は$5.2bnまで押し上げられた。GitHubリポジトリのスター数は198,139に達し、それに加えてn8nは月間180万人のアクティブビルダーがいると報告している。Vodafoneは自社側で、n8nのセキュリティワークフローによって220万ポンド**を節約したとしている。

セルフホスティングは現実的な選択肢であり、n8nはそれが実際にどれだけのコストになるかについて、珍しいほど正直だ。同社のDockerインストールページには、セルフホスティングは「上級ユーザー向け。ミスはデータ損失、セキュリティ問題、ダウンタイムにつながる可能性がある」と書かれている。実運用の規模になると、キューモードにはPostgres 13以上、Redis、ワーカープール、Webhook用の層、ロードバランサーに加え、添付ファイル用のS3が必要になる。キューモードはファイルシステムにバイナリデータを保存できないためだ。ここで驚かされる点が2つある。S3ストレージとワークフロー共有はどちらも無料のCommunity版から除外されているため、ワークフローを開けるのは作成者本人だけであり、セルフホスト環境ですら、ドキュメントがCloudflareのIP範囲全体をアローリストに入れるよう指示している、Cloudflareでホストされたライセンスサーバーに通信している。

n8nは自社を「ノーコード」ではなく「ローコード」と呼び、はっきりと「技術系チーム向けに設計されている」と言っている。つまり、Cassidyの顧客層を奪い合うつもりはまったくないと、会社として決めているようなものだ。

Cassidyが公開する比較表を1行ずつ検証する

Cassidyはn8nと比較する対決ページを公開しており、そのキャッチコピーは「Cassidyはインテリジェンスを作り、n8nはワークフローを作る」だ。日付も記載されておらず、これが意外と重要になる。というのも、いくつかの行はしばらく前に存在しなくなったバージョンのn8nを説明しているからだ。

n8nの現行ドキュメントと照らし合わせながら、1行ずつ確認していった。実際に成立している内容は次の通りだ。

9行のうち4行は成立せず、成立するのはナレッジベースの1行だけだ。正直これがおもしろいところで、その生き残った1行こそが、この2つのプロダクトの本当の違いのすべてだからだ。Cassidyは残りの8行など、本当は必要なかった。

この表がひっそりと作り出している非対称性がもう一つある。Cassidyはここでセキュリティとガバナンスの勝利を自分に与え、SOC 2 Type IIと細かな権限管理を根拠に挙げ、n8nには単純に✕をつけている。それはそれでいい。しかしn8nは公開ページに完全な価格表を掲載しているのに対し、Cassidyはどこにもドル金額を公開していない。あなたの疑問が「営業電話を予約する前にどちらを評価できるか」であるなら、この表は間違った方向を指し示している。

価格：片方は数字を公開し、もう片方は公開しない

正直、ここから比較は接戦ではなくなる。まず何よりも先に、両方の課金モデルを並べて見せておこう。

n8nは実行単位で課金する

実行1回はワークフロー1回分の完全な実行を意味し、これが課金単位だ。ステップが3個でも50個でも料金は同じで、これがほぼすべての売り文句だ。価格ページにもはっきり書かれている。「ワークフローにいくつのステップがあっても、どれだけのデータを処理しても、実行は1回とみなされる」

超過分の料金も公開されており、これはこの業界では珍しい。Businessプランでは追加30万実行あたり€4,000で、その時までにアップグレードしなければ45日後に請求される。1実行あたりに換算するとおよそ€0.0133だ。上限を超えてもワークフローが完全に止まるわけではなく、そのまま動き続ける。

ただし落とし穴は、何が「1実行」としてカウントされるかだ。これはおそらく、n8nの価格について誰かが言った中でいちばん鋭い指摘であり、実際に料金を払っている顧客からのものだ。

"That's great if you're just doing traditional automations, but think about things like the chatbot trigger or MCP server trigger. Every single user interaction counts as an execution. Even something as simple as a polling workflow, need to do something once per minute? There's a workflow that now costs $1000 per month to run."

u/coinclink, r/n8n

もう一度、今度はサポート担当の視点で読み直してほしい。会話の中では、顧客からのメッセージ1つひとつが1実行としてカウントされる。10往復のチャットなら、チケット1件分ではなく10回分の課金対象実行になる。サポートキュー向けにn8nの価格を試算するなら、このページ全体の中でこれがいちばん重要な点だ。

ここでのエンタープライズの数字は実際のもので、n8n自身ではなく買い手側から出てきたものだ。従業員100人超の企業のある評価担当者は、無制限実行に対して「7桁をゆうに超える」見積もりを提示されたと報告しており、年間60万実行なら2万ユーロという例もある。実際に契約した顧客が同じ段階的な料金体系を裏付けている。「60万実行分のライセンスを2万ユーロで買ったばかりだ……200万実行なら5万ユーロになる」

Cassidyはクレジット単位で課金するが、その単価は言わない

Cassidyの価格ページには、月額料金も年額料金もシート単価もクレジット単価も一切書かれていない。Starterは無料で、シート3つ、エージェント5つ、ワークフロー5つ、クレジット10,000が含まれる。Businessは数値を伴う行すべてが「カスタム」だ。一方Enterpriseに至っては列としてすら存在せず、FAQにしか登場しない。

クレジットはタスク単位ではなく、トークン量から算出され、さらにモデルによって倍率がかかる。Cassidyのクレジットに関する記事には唯一の具体的な範囲が示されている。エージェントチャットは1〜30クレジット、ワークフローは1〜100クレジット、プレミアムモデルは標準モデルのおよそ5倍を消費する。無料枠で計算すると、10,000クレジットは月に重いワークフロー実行およそ100回分に相当する。

一見した以上に予算を立てにくくする要素がいくつかある。クレジットは繰り越されない、Enterpriseの契約で個別に交渉しない限りは。マーケティング向けFAQは「中断されることは決してありません」と約束している一方で、プロダクトドキュメントにはAI機能が「クレジットが補充されるまで一時的に利用できなくなる」と書かれており、両方のページを続けて読むと矛盾している。さらに、支出を抑えるためのCassidy自身のアドバイスは、各やり取りが取り込むナレッジベースのコンテキスト量を制限することであり、つまり回答を正確にする仕組みそのものが、回答を高くつかせる仕組みでもあるということだ。

実際の姿は使用状況ダッシュボードで見ることができ、正直なところ実際の割り当て数値が現れるのはそこだけだ。

もう一つ触れておく価値があるのは、これがCassidy自身のCEOによる主張だからだ。Justin FinebergはX上で投稿し、AIはシートライセンスではなく、それが置き換える人員数に対して価格をつけるべきだと述べたうえで、同じ投稿の中で買い手側の事情も認めていた。「その数字は財務側の誰もが想定していたよりもずっと高くなる」。正直、彼はどちらの点についても正しい。とはいえ、数字が一切載っていない価格ページを運営しながら言うには、奇妙な発言だ。

検索(retrieval)層を誰が組み立てるか

ここでCassidyが実際に獲得した行を、今度はきちんと掘り下げてみよう。これこそが、この比較全体の裏にある本当の決め手だからだ。

n8nのAI Agentノードは、何かをつなげるまでは何もしない不活性な状態にある。ドキュメントもこの点についてはっきりしている。少なくとも1つのツールサブノードを接続しなければならず、チャットモデルをつなぎ忘れた場合のためだけに専用のエラー状態まで用意されている。バージョン1.82.0以降、エージェントタイプはTools Agentただ1つしかなく、その内部にはLangChainがあり、ノードの内部名にすらそれが表れている。

そのエージェントを自分のナレッジベースに根ざすためには、設定を1つ切り替えるのではなく、自分で構築する必要がある。n8nには「ヘルプセンターを指定するだけ」というオプションはない。RAGガイドによれば、データを挿入するにはインサートモードのベクトルストアノード、埋め込みサブノード、データローダー、テキストスプリッターが必要で、チャンクサイズとオーバーラップも自分で選ぶ。そのうえでベクトルストアをもう一度ツールとして追加し、エージェントにいつ使うべきかを説明する記述を書き、さらに同じ埋め込みモデルを上に付ける必要がある。ここが食い違うと、エラーを一切出さないまま、静かに検索精度が落ちていく。

部品箱は大きい。13のベクトルストアノード、12の埋め込みノード、19のチャットモデルノードがあり、そのうちエージェント向けに公式サポートされているのはわずか5つだ。メモリのバックエンドは7種類あり、さらにドキュメントの中の一文は、どんなサポートチームも凍りつかせるはずだ。メモリはセッションをまたいで保持されない。顧客の履歴を1回の問い合わせから次の問い合わせまで残したいなら、それは自分で立ち上げて維持するRedisかPostgresのインスタンスが必要になる。

きちんと数えると、n8nで1つのサポートエージェントを立ち上げるには、トリガー、エージェントノード、チャットモデルと認証情報、機能ごとに手書きの説明を付けたツール、メモリ、埋め込み、ベクトルストア、データローダーとスプリッター、出力パーサー、人間によるレビューステップ、さらに評価ハーネスまで配置・設定する必要がある。合計で11のコンポーネント、4〜6個の認証情報オブジェクトを、チケット1件に回答する前に用意しなければならない。

エージェントはループもする、それも別の要注意点だ。n8n自身のドキュメントには、1回の実行の中で「複数回実行される」とあり、デフォルトで10回に設定されたMax Iterationsオプションで上限がかかる。つまりユーザーからの1つのメッセージが、あなたのAPIキーを使ったモデルとの往復10回に化ける可能性があり、n8nはその支出に一切上限を設けてくれない。

はっきりさせておくと、これは批判ではまったくない。設計通りに動いているだけであり、この柔軟性こそがここでのポイントの1つだ。ビルダーたちはまさにその理由でこれを気に入っている。

"I've moved everything from a paid power automate to a free self hosted n8n and it's been 100x easier to use too."

u/bradhawkins85, r/selfhosted

とはいえ、目を曇らせずに見るべきだ。組み立てのコストは本物であり、それは完全になくなることもない。APIが変わるたびに、また戻ってくるだけだ。

どちらが自分の状況に合うか

いちばん自分に近いと感じる行を選んでほしい。

両方が止まる場所

正直、ここが私がいちばん気にかけている部分だ。実際に自分が取り組んでいる部分だから。

Cassidyの看板とも言えるサポートテンプレートはCustomer Support Auto-Responderで、その説明自体がここでの上限を正確に示している。「チケットとメールの詳細を取得し、ナレッジベースを検索して、ブランドに沿った返信の下書きを生成する」。Ticket Context Enricherが要約を渡す相手はエージェントであって、顧客ではない。サイト横断のFAQも、注目すべきことに「自動送信」ではなく「自動下書き」と表現している。解決率もディフレクション率も、Cassidyのサポート関連資料のどこにも出てこないし、確信度のしきい値も出てこない。

実際、プロダクトそのものにそれが表れている。ステップの名前がそのまま「Draft Reply Message（返信メッセージの下書き）」なのだ。

n8nの限界はもっと具体的で、正直ここまではっきりしているとは思っていなかった。Zendeskノードは4つのリソースにまたがる23のオペレーションを提供しているが、そのうちの1つも顧客への返信を投稿できない。コメント追加もマクロもヘルプセンター記事もチケット検索もない。できるのはチケットレコードの作成、読み取り、更新、削除くらいだ。ドキュメントに書かれている回避策は、n8nがほぼすべての機能不足に対して出す答えと同じ、HTTP Requestノードを使って自分でREST APIを呼び出せというものだ。ノーコードの比較のはずの真ん中に、手書きのZendesk API呼び出しが座っている。

ヘルプデスクごとに見ていくと、さらに鮮明になる。Freshdeskは10オペレーションで、こちらも返信用の操作はない。Help Scoutは3つの中で唯一、Threadリソースを通じて実際に進行中の会話にメッセージを追加できる。そしてGorgiasノードはそもそも存在せず、Shopify中心のEコマースチームは連携全体をHTTP Requestノードで組み立てる羽目になる。

エージェントを本番のキューに向ける前に知っておく価値のある落とし穴が1つある。ZendeskノードのUpdate Ticketオペレーションは、タグを追加するのではなくタグリスト全体を置き換えてしまう。タグを1つ追加しただけのエージェントが、そのチケットのルーティングタグやSLAタグをすべて消し去ってしまう。取得・マージ・更新を自分で組み立てない限りは。

n8nはその点を偽っておらず、それは評価できる。人間によるレビュー機能はリスクのあるツール呼び出しの際に、9つの承認チャネルを通じて処理を一時停止し、自社のAIページには「オートパイロットは飛行機のためのものであって、本番AIのためのものではない」とある。評価ドキュメントの実例も、サポートチケットにカテゴリと優先度を割り当てるワークフローだ。上限は解決ではなく分類なのだ。コミュニティのビルダーたちも自力で同じ結論にたどり着いており、ある人は「AIは分類と優先度タグ付けだけに使い、ユーザー向けの回答生成には使わないように」と勧めている。

正直、どちらの立場も擁護できる。ただ、サポート責任者が実際に探しているものとは違い、そのズレはよく耳にする反論として表面化する。月に約7,000件のGorgiasチケットを扱う、あるDTCのサプリメントブランドのCXリードは、私よりもうまく言い表していた。

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

それが確信度ゲートであり、どちらのプラットフォームにも搭載されていない唯一のピースだ。下書きキューもこれを解決しない。7,000件の下書きをレビューすることは、結局7,000件の返信を自分で書くのと同じ仕事になってしまうからだ。

実践者たちが実際に言っていること

この対決全体でいちばん参考になる外部の声は、実はどちらのベンダーからのものでもない。自らを非エンジニアと称し、AI構築コホートを運営するBrett Bouchardが両者を直接比較している。

"We've been using Cassidy in Build Lab, and it has been relatively easy to pick up and has user-friendly features for builders and businesses. But many in our cohort are using n8n, for its functionality and technical options."

Brett Bouchard, LinkedIn

どちらにも利害関係のない人物による、たった一文でのトレードオフの要約だ。

両方を使ったことのあるRedditのマーケターも、同じ論点の分別ある版にたどり着いており、ほとんどの比較記事が飛ばしてしまう部分を付け加えている。

"All of these tools like Zapier, Cassidy, n8n, Lindy, Relay, make etc. have great templates already available - I encourage everyone to browse before reinventing the wheel. Also before selecting a tool review UX and costs - not all of these are built and priced the same, some are much easier to use for non technical folks and some are much more expensive than others."

u/gravi_ai, r/AskMarketing

私が見つけた中でn8nに関する到達数が最大の投稿は、価格の話ではまったくなく、学習曲線についてのものだった。3,813いいねを獲得している。

"n8n's learning curve is brutal.

I've lost count of how many smart business owners I've seen:

Get excited about n8n"

Tom, X

同じ投稿はその理由も名指ししており、これはこの議論全体の中でもっとも役に立つ一文かもしれない。n8nは「長年ワークフローを構築してきた開発者たちによってすべて作られている」ため、チュートリアルがHTTPリクエストノードを設定しろと言ったとき、「その言葉の意味がわからなければ、そこで詰む」。それこそがCassidyの市場のすべてであり、ほかでもないn8nの教育者自身がそれを言い表している。

n8n側で過去1年間もっとも盛り上がったスレッドは、セルフホストプランにおける実行単位課金への移行についてであり、そこでの反発は金額そのものというより構造的なものだ。

"I get unlimited executions on the free Community tier, but if I pay for the Business plan… I don't? Someone explain this to me from n8n please....."

u/jsreally, r/n8n

エージェントの品質については、行動に移す価値があるほど具体的な批判が出ている。あるビルダーは、n8nのエージェントが「ツール選択、コンテキストの記憶、プロンプトへの追従において非常に弱い」と感じており、もっとも技術的な返信がその理由を説明している。n8nはモデルプロバイダー自身の構造化出力機能ではなく、構造化出力のためにLangChainに頼っているため、「基本的には『お願いだからマスターLLMさん、私のJSONスキーマで出力してください』と言っているようなものだ」という。

大量処理時の信頼性は、4.7という平均評価がある意味隠してしまっている不満であり、サポートキューをn8n Cloudに乗せる前に読んでおく価値がある。

"We use the cloud version, and I really dislike the RAM exhaustion when multiple workflows run. Also, the fact that they never clarify how much RAM your instance has. Also, customer service is only available via email, and 99% of the time, they blame you for the issues the workspace has."

Juan Jose C., G2

Cassidyのコミュニティははるかに静かで、それ自体が一つのシグナルだ。n8nの294件からの5段階中4.7に対し、CassidyはG2でレビュー5件、Capterraへの掲載もTrustpilotもなく、それ以外にもHacker Newsでの議論も、自社の採用投稿を除けば見当たらない。価格ページで2万以上のチームを謳う企業にしては、公開されている実績はかなり薄い。称賛も批判の少なさも、それを踏まえて受け止めるべきだと思う。

両社の売り文句を取り除いた、正面比較

正直にまとめると、n8nを選べばロジックとインフラは自分のものになり、その代わりにエンジニアリングの時間で対価を払う。Cassidyを選べばどちらも自分のものにはならず、営業と話すまで見えない価格を払うことになる。どちらもそれぞれの意味で妥当なトレードオフだ。ただし、どちらもサポート製品ではない。

サポートチケットにはeeselを試してみる

もしあなたがここにたどり着いた理由が、実際に自動化したいのはサポートキューだからというものなら、正直、私は第三の選択肢を見てみることを勧める。それを生業として作っている立場からの意見だ。

eeselはZendesk、Freshdesk、Gorgiasなどにわずか数分でつながり、移行作業なしで既存のヘルプセンターと過去のチケットを読み込み、この記事全体がずっと巡ってきたことを実際に行う。まず過去のチケットに対して実行することで、実際の顧客に何かを言う前に、どんな返答をしていたはずかを確認できる。確信が持てることだけに回答し、それ以外はエスカレーションする。これは先ほどのDTCリードが求めていたコントロールそのものだ。価格は1チケットあたり$0.40で、シート料金もプラットフォーム料金もなく、最初の$50は無料でカードも不要だ。

私たちがこのように作ったのは、自信たっぷりに聞こえるボットが静かに間違った回答を出すのをこれまで見てきたからだ。ある顧客は自作か購入かという判断をかなり率直に言い表していた。300以上の記事からなるナレッジベースを運用する、ビットコインATMのハードウェア企業のエンジニアリングリードは、私たちにこう語った。「自分たちでLLMアプリケーションを書くこともできたが、そこに時間を投資したくなかった。メンテナンスしなくていいものが欲しかった」

キャンバスが欲しいならn8nを選べばいい。代わりにドキュメント層が欲しいなら? Cassidyを選べばいい。そして、本当にチケットをクローズしたいなら、eeselを試してみてほしい。