Cassidy AIとは何か、費用はいくらか、どんなチームに向いているか

Cassidy AIとは実際どんなものか

Cassidy Inc.は2023年設立で拠点はニューヨーク、小さな会社だ。共同創業者でCTOのIan Woodfillは2026年4月にHacker Newsでチームについて「25人、急成長中」と語っている。これまでの累計調達額は1,370万ドルで、The General Partnershipが主導した370万ドルのシードラウンドに続き、2025年9月にHOF Capitalが主導した1,000万ドルのシリーズAを実施した。

CEOのJustin Finebergは資金調達の発表文を自ら書いており、珍しい流通面での強みも持っている。彼自身が語るところでは、AI教育の視聴者層が「50万人以上」に成長したという。これは聞こえる以上に重要な話で、Cassidyについてネット上で読める情報の大半が彼に行き着く理由でもあるからだ。

ホームページのH1見出しは「あなたの最も複雑な業務を処理するAIエージェントを構築する」であり、その下にある主張は技術論というより人員配置論だ。Cassidy自身の説明によれば、「業務に最も近い人が、それを自動化する人であるべきだ」という。つまり、自動化を作ってもらうためにエンジニアリング部門の順番待ちをする必要がなくなる、というのが売り文句だ。

その位置づけは、Cassidyの販売先とも一致している。ホームページでは保険、製造業、プロフェッショナルサービスという3つの業種を挙げ、「ワークフローが手作業で、ドキュメントが密で、正確性が重要な」領域だと説明している。顧客ロゴもそれに沿っており、Tokio Marine、NTT Data、Geodis、Quad、Frontier Behavioral Healthなどが名を連ねる。

1つの数字は慎重に扱う価値がある。顧客ページには「従業員1,000人以上の企業・チーム2万社がCassidyを信頼している」とあるが、シード投資家であるThe General Partnership自身は「1万2,000社以上」と記している。両者は食い違っており、前者は25人規模の会社にしては違和感のある数字だ。どちらも監査済みの数字ではなく、マーケティング上の規模訴求として受け取っておくのがよい。

4つの製品と、その積み重なり方

Cassidyは自社プラットフォームをコンテキストレイヤーとオートメーションレイヤーに分けている。これはCassidy自身の言葉であり、製品全体を理解するうえで最も分かりやすいモデルだ。

Knowledge Base

これが基盤であり、他のすべてがこれに依存している。PDF、Officeファイル、CSV、音声・動画(自動で文字起こし)、ソースコードを取り込み、ドメイン、サブドメイン、ページ、globパターンといったモードを持つクローラーでウェブサイト全体も取り込める。コネクタとしてはGoogle Drive、SharePoint、OneDrive、Notion、Confluence、Slack、Box、Coda、Jira、Gong、Zendeskのヘルプセンター記事、ServiceNowのナレッジ記事と同期できる。これまでにAIナレッジベースツールを検討したことがあるなら、このコネクタの充実ぶりはこのカテゴリの中でもかなり強い部類だと分かるはずだ。

検索はキーワードではなくセマンティック方式で行われるため、単なる検索ボックスというより他のナレッジ検索ツールと同じ系統に位置づけられる。すべての回答にはCassidyがディープリンク引用と呼ぶ機能が付き、元の該当箇所をそのまま開ける。権限は元のシステムから継承されるため、ドキュメントによればエージェントは「ユーザーがアクセスを許可されている情報のみを取得する」という。さらに、検証済み、マネージャーへの検証依頼、古い情報としてフラグ付けという3つの状態を持つドキュメント検証メニューもある。ボットが2023年のポリシーを自信満々に引用するのを見たことがある人にとっては賢い仕組みで、これはモデルの欠陥というより古くなった参照元という、AIハルシネーションの多くと同じ根本原因に対処している。

ここで明確な制約がある。Enterpriseプランでない限り、連携元のソースは24時間ごとにしか同期されない。RFPのライブラリならそれで問題ないが、毎週更新されるヘルプセンターの場合、1日古い回答は不便というより正確性の問題になる。

Agents

Agentはそれ自体がランタイムというより、保存された設定のまとまりだ。ドキュメントには10の構成要素が挙げられている。ベースモデル、平易な言葉での指示、ナレッジベース検索、コネクタ、機能(ウェブ検索、画像生成、アーティファクト、ブラウザ利用)、コード実行、スキル、ブランドボイス、ワークフローを呼び出す機能、そしてデプロイ先だ。

80以上のエージェントテンプレートが用意されており、Slack、Microsoft Teams、Google Chat、ウェブサイト埋め込み、メールアドレス、API、Chrome・Edge拡張機能、さらにWord、Excel、Outlookの中にもデプロイできる。この展開先の広さこそが、単一の場所でしか使えないAIアシスタントとの本当の差別化ポイントだ。

気に入った点が1つある。Cassidyが標準で用意するエージェントは、あえて自社のナレッジベースで学習させていない。これは汎用的なタスク用に存在しており、誰かが誤って「既製のアシスタントが会社のポリシーを知っている」と思い込むことがないようにするためだ。ナレッジベースでAIを学習させたことがある人なら、この切り分けがなぜ重要なのか理解できるはずだ。

Workflows

Workflowsは決定論的な側の機能だ。トリガーと、順序立てられたアクションの連鎖から成り、生成、ナレッジ検索、リサーチ、ドキュメント抽出、制御フローなどをカバーする約45個のアクションが文書化されている。さらに、誰かが承認するか入力するまで実行を一時停止する2つのヒューマン・イン・ザ・ループステップもある。

Cassidy自身のドキュメントは、たいていのベンダー資料よりも率直に両者の違いを説明している。ワークフロー概要によれば、「予測可能で反復可能なプロセスが欲しいとき」はワークフローを、「経路があらかじめ決まっていないとき」はエージェントを使う。エージェントは会話の途中でワークフローを呼び出せるため、両者は2つの別システムではなく1つのシステムとして機能する。

Meetings

Zoom、Teams、Google Meetの通話に参加し、話者識別付きで文字起こしを行い、その記録をKnowledge Baseに落とし込むノートテイカー機能で、エージェントが正確なタイムスタンプを引用できるようになる。ミーティングの文字起こしは、通常であればナレッジマネジメントにまったく組み込まれない会社の知識の塊なので、これはなかなか良いアイデアだ。CassidyはMeetingsページで競合を率直に名指ししている。単体レコーダーとしてはFireflies、Otter、Fathom、レベニューインテリジェンスとしてはGong、Chorus、Clariだ。

ワークフローが実際にどう作られるか

ここは、実際に触ってみることでマーケティング文句以上のことが分かる部分だ。開始方法は、カスタムビルド(平易な言葉で説明すると、Workflow Copilotがトリガー、アクション、設定を生成してくれる)、白紙のキャンバス、インポートしたJSONファイル、または100以上あるテンプレートのいずれかから選べる。

トリガーは5系統ある。手動フォーム、スケジュール実行(1時間ごとから月次まで)、Webhook、専用の受信メールアドレス、そして連携イベントだ。最後の連携イベントには、Zendeskチケットの新規作成・更新、HubSpotやSalesforceのレコード変更、Slackメッセージ、GmailまたはOutlookのメール、カレンダーの予定、Gongの文字起こし、Jiraのissueが含まれる。特にメールトリガーを使えば、ヘルプデスクにまったく触れずに受信箱のトリアージを簡単に構築できる。

ほとんど誰も触れていない重要な詳細が構築ドキュメントにある。ステップは暗黙的には連結されないのだ。Cassidyの言葉を借りれば、「デフォルトでは、アクションは前のステップの出力にアクセスできない」。各ステップは#で変数を挿入することで明示的に接続する必要がある。これは妥当な設計ではあるが、出力が自動的に下流へ流れると思い込んでいると、最初のワークフローが静かに壊れる原因にもなる。

最も感心したのはBulk run(一括実行)モードだ。ファイルをアップロードすると、Cassidyが行を抽出し、そのすべてに対してワークフローが実行される。Workflowsページのスクリーンショットでは、3段階の進捗バーの背後でRFPのジョブが「1,125件の返信を生成中」と表示されている。RFPや提案書のチームにとっては、この機能1つだけで導入する理由になり得るだろう。

Cassidyはあなたの課題に合った形か?

このカテゴリのツールをめぐる混乱の多くは、品質の優劣ではなく、用途とのミスマッチが原因だと私は見ている。AIに実際にやってほしいことを選んでみてほしい。

サポートチームにとってのCassidyの立ち位置

Cassidyは、Auto-Responder、チケットのトリアージとルーティング、感情分析に基づくSLA優先度付け、多言語サポート返信、Ticket Context Enricherなど、12のカスタマーサポート向けソリューションを挙げている。書面上はサポート製品のように読める。だが説明を読んでいくと、あるパターンがすぐに見えてくる。

Auto-Responderは「チケットとメールの詳細を取得し、Knowledge Baseを検索して、ブランドに沿った返信の下書きを生成する」。Ticket Context Enricherはエージェントに対して出典付きの要約を提供する。Cassidy自身のFAQでは、サポートのユースケース全体を「受信チケットへの返信を自動下書きする」と説明している。どの仕組みも最終的には人間で終わる。これは正当な設計上の選択ではあるが、ツールを比較する際には正直に伝えておく価値がある点だ。

サポート目的でこのツールを検討しているなら、重要なギャップが3つある。

• 信頼度しきい値がない。 「confidence(信頼度)」という言葉が調整可能な設定として登場することはない。公開されているエスカレーションルールはコンテンツカテゴリ(「センシティブな話題」)とseverity(重大度)ベースのものだけで、本当の意味でのヒューマンハンドオフ制御からは程遠い。
• サポート関連の文章に具体的なヘルプデスク名がない。 サポート関連のページでは一貫して「ヘルプデスク」「チケッティングシステム」と一般的な表現しか使われていない。連携ディレクトリにはZendesk、Freshdesk、ServiceNow、Jiraが確かに並んでいるが、Zendesk連携の中身はヘルプセンター同期とチケットトリガー、コメント追加にすぎない。これはエージェントコンソールではなく単なるデータパイプだ。
• 成果を示す数字がない。 公開されている3件の事例をすべて読んだが、削減時間の基準値、導入率、デフレクション率、CSATのいずれも1つも出てこない。顧客事例ライブラリ全体で唯一のパーセンテージが登場するのは営業向けの事例だけだ。

最後の点は、デモの場で最も強く突っ込むべきところだ。何年も実際のサポートキューにAIエージェントを導入してきた経験から、私が信用しないようになったのは、実測数値が伴わない自信満々なボットだ。だからこそ、eeselのすべての導入は、顧客に触れる前にその会社自身の過去のチケットに対してシミュレーションを行う。そうすることで解決率は「期待した数字」ではなく「自社のデータで実際に見た数字」になる。

Cassidy AIの料金:公開されていること、いないこと

ここが最も驚いた発見だ。Cassidyの料金ページには金額がまったく記載されていない。月額料金も、シート単価も、クレジット単価もない。2つのURLパターンで2回確認した。

ページが言葉で述べている内容は次の通りだ。

第3のプランであるEnterpriseは、ページ自体のFAQには登場するが比較表には出てこない。名称変更の途中であることをうかがわせる。ログイン後には月額・年額の切り替えとStripeでの決済を備えたセルフサーブの有料プランが実際に存在するが、その価格は公開されている場所のどこにも記載されていない。

クレジットが実際にどう消費されるか

クレジットはタスク単位でもメッセージ単位でもない。ドキュメントによれば、「チャットメッセージからワークフローの実行まで、あらゆるAIとのやり取りは、リクエストの複雑さと使用するAIモデルに応じてクレジットを消費する」という。消費量は入力トークンと出力トークンの合計をモデルごとに調整したもので、標準モデルは1倍、プレミアムは約3倍、高度な推論モデルは約5倍という相対コスト表が公開されている。

購入者が織り込んでおくべき3つの影響がある。

1. クレジットは繰り越されない。 Enterpriseプランを除き、どのプランでも繰り越しはされない。Enterpriseでは「契約内容による」とされている。
2. 枯渇すると完全に止まる。 ドキュメントには、エージェントとのチャットやワークフローの実行が「クレジットが補充されるまで一時的に利用できなくなる」とある。一方、同じサイトのマーケティング向けFAQには「中断されることは決してありません」とある。両方が同時に正しいということはあり得ない。
3. グラウンディングそのものがコストになる。 Cassidy自身が挙げる節約のアドバイスは「各やり取りで取り込むKnowledge Baseのコンテキスト量を制限する」ことだ。回答を正確にするコンテキストが、そのまま請求額を押し上げるコンテキストでもある。これはサポートワークフローを構築するうえで、居心地の悪いトレードオフだ。

公平を期すために言うと、ある実行が俳句1つで、次の実行が1,125件のRFP返信になり得るような横断的プラットフォームでは、クレジット制はごく普通のモデルだ。ただし予測が難しいモデルであることに変わりはなく、だからこそeeselはサポート責任者がすでに考えている単位、つまりチケットまたはチャットセッションあたり0.40ドルで価格を設定している。何往復メッセージがやり取りされても課金は1回だけで、プラットフォーム料金もシート料金も最低利用料もなく、ページで公開されている。

セキュリティ、ガバナンス、管理機能

これは強みのある領域で、ドキュメントはバッジを並べただけでなく具体的だ。

ガバナンス面で平均以上の点が2つある。グローバル指示は個々の設定にかかわらず、組織内のすべてのエージェントとワークフローに一律で適用される。これにより、各作成者を信頼するかどうかにかかわらず、トーンやコンプライアンス上の免責事項を統一的に徹底できる。また、データを変更するコネクタアクションは、実行前にチャット内での明示的な承認を必要とする。非技術者が自動化を作る環境では、これが正しいデフォルト設定だ。

小規模チームにとっての落とし穴は、SSOがEnterpriseの向こう側にあることだ。カスタムロール、毎週のウェブサイト再クロール、保持ポリシーも同様だ。ITサービスマネジメント向けにこのツールを評価しているなら、このゲートはセキュリティレビューで不利な結果になりやすいだろう。

実際の顧客の声

コミュニティでの存在感は薄いため、数字はその点を踏まえて見る必要がある。G2でのCassidyの評価はわずか5件のレビューで5.0点満点中5.0で、そのレビュアーは全員が従業員50人以下の中小企業だ。Capterraには掲載がなく、Trustpilotのプロフィールもまったく存在しない。つまり、エンタープライズ向けというポジショニングの裏には、独立系のエンタープライズレビューが1件も存在しないことになり、これがエビデンスの中で最大の穴だ。

実際に存在する5件のレビューは、実感を補うのに役立つ。次のレビューは、ドキュメントの量が増えるにつれて直面しやすい摩擦を言い当てている。

「これまでで唯一の課題は、アップロードしたいデータの量があまりに多く、エンタープライズレベルのストレージ要件に達してしまったことだ。」

Martin F., G2

そして、この製品が「誰向けではないか」を最も明確に語っているのが次のレビューだ。

「もっと多くの連携と、開発者向けのより細かい制御があればと思うが、製品が成熟していくにつれ時間の問題だと思う」

Tarun A., G2

Redditでは、Cassidyはサポートツールに関する議論よりも、ノーコードのエージェントビルダーの候補リストの中で登場することが多く、r/AI_AgentsのこのスレッドのようにDifyやLangflowと並んで語られている。開発者はCassidyを見つけるが、サポート責任者はほとんど見つけない。

私が見つけた中で最も参考になった独立した意見はLinkedInにあり、ある実務者がCassidyとn8nを比較し、トレードオフを的確にまとめていた。

「比較的習得しやすい……ただ、私たちのコホートの多くはn8nを使っている。その機能性と技術的な選択肢の豊富さのためだ。」

Brett Bouchard, LinkedIn

これがこのカテゴリの位置づけを正直にまとめたものだ。Cassidyは非エンジニアでも実際に扱えるツールであり、n8nは深さが欲しいときに行き着く先だ。

それ以外で内容のある声は、Cassidy自身の事例に見られる。評価できる点として、それぞれに実名と実際の肩書きが記載されている。

「ドキュメントは存在していたが、何かを見つけること自体が時間の有効な使い方とは言えなかった。」

Paul Arguinchona、最高情報責任者(CIO)、Frontier Behavioral Health、Cassidy事例より

FBHは自社のアシスタントに「Single Point of Truth」の略でSPOTという名前を付け、現在はMicrosoft Teams内で800人以上の臨床医が日常的に利用している。事例によれば、うまくいった理由は回答が「元の出典へのリンク付きで返ってきて、二度確認する必要がない」ことだった。信頼の仕組みはスコアではなく引用だったわけだ。

Crain Communicationsでは、興味深いのは最終的に誰が構築するのかという点だ。

「タイプライターでジャーナリストのキャリアを始めた編集者が、編集アシスタントをまるごと自分で構築し、今では他の編集者たちとそれを共有できるまでになった。」

Marisa Marcinkowski、Enterprise AI Enablement戦略担当、Crain Communications、Cassidy事例より

Quad傘下のエージェンシーであるRiseでは、正直なところ競合相手は別のプラットフォームではなかった。

「以前は、わずかな手直しだけで済むはずの、すでに書いてある回答を探すためだけに数え切れないほどの時間を費やしていた。今ではCassidyのおかげで、回答をすばやく見つけ、カスタマイズし、提出できる。」

Andrew Boylan、プロダクトマネジメント担当グループディレクター、Rise(Quad傘下のエージェンシー)、Cassidy事例より

Riseは以前ChatGPTとClaudeを試したが、データ学習への懸念から見送った経緯がある。これが3つの事例すべてに共通するパターンだ。Cassidyが勝っているのは、生のモデル性能ではなくガバナンスと手厚いサポートの面だ。どの事例でも、定着した主な理由として導入チームの存在が挙げられており、これはセルフサーブのスイッチというより、サービス主導で販売されている製品だということを物語っている。

同じトレードオフは私たちの側にも当てはまることに触れておく価値がある。自作するという選択肢は、この領域のどのプラットフォームにとっても本物の競合であり、これは性能というよりメンテナンスの問題に行き着く。私たち自身の顧客の1つ、GENERAL BYTESのエンジニアリングリードは率直にこう述べている。「自分たちでLLMアプリケーションを書こうとすることもできたが、そこに時間を投資したくなかった。メンテナンスしなくて済むものが欲しかったのです。」

Cassidyが向いている人、他を検討すべき人

**Cassidyを選ぶべきなのは、**ボトルネックがドキュメント絡みの社内業務にある場合だ。RFPや提案書、ポリシーや契約書の比較、雑然としたDriveやSharePointをまたいだ社内の回答検索、CRMに落とし込むミーティングのフォローアップなどだ。Bulk runモード、45個のアクションライブラリ、ガバナンス機能はどれも本物であり、ノーコードビルダーによって非エンジニアでも何かを作り上げられる。

検討対象がZapier、n8n、Glean、あるいはCopilotのような汎用アシスタントであるなら、それはまさにCassidyが自ら選んだ比較対象であり、その比較は妥当だ。また、「顧客」が従業員であるHRヘルプデスクにも十分に適している。

**他を検討すべきなのは、**顧客対応型のサポート自動化が必要な場合だ。Cassidyが力不足だからではなく、そもそもそこを狙っていないからだ。自動送信も、信頼度ベースのルーティングも、デフレクション指標も、サポートの事例もなく、サポートは12あるソリューションカテゴリの1つにすぎない。下書きを作るヘルプデスクコパイロットは有用だが、それは解決までこなすエージェントとは別物だ。チケット数の削減が目標として掲げられているなら、代わりにサポート向けに作られたツールから候補リストを始めるべきだ。

**どちらを選ぶにせよ、価格については強く食い下がるべきだ。**デモには自分たちの数字を持って臨もう。月間の想定実行回数、平均的なドキュメントサイズ、各ステップに必要なモデルなどだ。これはどんなチャットボットのROIを検討する際にも必要な規律であり、契約後より契約前にやっておくほうがずっと楽だ。クレジット単価を書面で求め、残高を使い切った月に何が起きるかを確認し、自分たちの契約に繰り越しが適用されるかを尋ねよう。この3つの答えが実質的なコストを決めるが、どれもウェブサイトには載っていない。

サポートキューの解決策としてeeselを試す

チケットの問題を解決したくてここにたどり着いたなら、それはまさにeeselが作られた目的そのものだ。ZendeskでもFreshdeskでもGorgiasでも、数分でヘルプデスクに接続でき、ヘルプセンターと過去のチケットを学習した上で、下書きをエージェントに返すのではなく会話全体を処理する。どのチケットに触れさせるかは自分で選べ、それ以外には手を出さない。これは、AIを顧客に近づける前に、ほとんどのサポート責任者が実際に求めているコントロールだ。

まだ候補リストを作っている段階なら、横断的なプラットフォームよりも、私たちがまとめたAIヘルプデスクソフトウェアの一覧の方が良い出発点になるはずだ。何を購入するにせよ参考にする価値がある部分は「まずシミュレーションする」ことだ。過去のチケットに対してエージェントを実行し、自社のデータでの解決率を確認してから、何を自動化するかを決めよう。クレジットカード不要で50ドル分の利用枠付きでeeselを無料で試す、あるいは誰かと一緒にキューを確認したいならデモを予約することもできる。