Lindy vs Tasklet AI：料金、シート、本当の違い

LindyとTaskletをひと目で比較

私は仕事としてAIエージェントを構築しているので、この記事の視点について正直に言っておく。どちらのツールが連携ロゴを多く持っているかにはあまり関心がなく、それよりも30日目、クレジットが底をつきかけてチームの誰かが請求額が変わった理由を突き止めようとしているときに何が起きるかのほうが気になる。まさにそこで、この2つのツールは本当に分かれる。

それぞれを深掘りする前に、まず全体像を示す。

どちらも誠実で有能な製品だ。ただし狙っている買い手が違う。LindyはSlackを拠点にする小規模チームで、スレッドに座ってくれるアシスタントを求める層に向いている。Tasketは常時稼働するクラウドエージェントに、シート計算なしでバックグラウンド作業をさせたいオペレーター層に向いている。お金の話に入る前に、それぞれが実際に何であるかを見ていこう。

Lindyの実態

Lindyは自らを「あなたの生産性を3倍にするAIチームメイト」と呼ぶ。チームメイトという打ち出し方の下は、トリガーベースのノーコードエージェントビルダーだ。トリガーを選び、仕事を平易な英語で説明すると、Lindyがステップを組み立てる。Slackで@メンションしたり、iMessageでDMしたり、大きなテンプレートライブラリからカスタムエージェント（「Lindy」と呼ぶ）を作ったりできる。

際立っているのは次の点だ。モデル非依存なのでタスクごとにモデルを選べること、40以上の組み込みスキルとコンピュータ操作、ほぼ何でも接続できるMCP対応があること、そして外部に向かうあらゆるアクションの前に承認ゲートを置いていることだ。メール送信、チケット更新、チャンネルへの投稿——Lindyは人間の承認を待つ。読み取り専用の参照はこのゲートなしで実行される。ルールベースのチャットボットが暴走することを心配したことがあるなら、この承認ステップは理にかなった設計だ。

ゼロから作る場合はフローエディタに入る。トリガーを選び、そこにアクション、ナレッジベース検索、条件分岐、あるいはネストされたAIエージェントを連結していく。

レビューも「使いやすい」という評判を裏付けている。G2ではLindyが171件のレビューで4.9/5を獲得し、上位のポジティブタグは使いやすさ、自動化、時間節約だ。エージェントを設定するのは本当に楽しく、チームが非技術系で、ワークフローグラフを手で配線せずにAIパーソナルアシスタントが欲しい場合には重要な点だ。ユーザー自身が唯一反発しているのはコストで、これは後述する。

Taskletの実態

Taskletは同じ問題に別の角度から取り組む。掲げるスローガンは「仕事を引き受けるエージェント」と「エージェント時代のIFTTT」で、そのピッチはこうだ。タスクや恒常的な役割を平易な英語で入力すると、Taskletは自律的なエージェントを構築し、ラップトップを閉じていてもクラウド上でそれを実行する。描くべきビジュアルなフローチャートは存在しない。

仕組みとして興味深いのはここからだ。各エージェントは専用の隔離されたクラウドサンドボックス（2 vCPU、空き14.8 GB）を持ち、その中でコードを実行したり、ファイルを処理したり、本物のブラウザを操作して、人間がやるようにログインの向こう側で作業を進めたりできる。トリガーの種類は3つ、スケジュール、イベント（新しいHubSpotの連絡先、受信メールなど）、Webhookだ。Claude、GPT、Geminiを横断してルーティングし、「インテリジェンスレベル」（Basic、Advanced、Expert、Genius）を公開することで、タスクごとにコストと推論の深さをトレードオフできるようにしている。15以上の名前付き統合（Gmail、Slack、Salesforce、HubSpot、Asana、QuickBooks）に加え、任意のHTTP APIやMCPサーバーへの自動接続も備える。

誰が開発しているかを知っておく価値はある。それが基準を決めるからだ。TaskletはY Combinatorのスタートアップで、Firebaseの創業者たちが作った。真剣なインフラの血統であり、それはエージェントごとのサンドボックス設計にも表れている。

当然の疑問はローンチした瞬間に出た。Show HNのスレッドで、あるコメント投稿者が誰もが思うことを尋ねた。

"How is this different from Zapier?"

mceoin, Hacker News

Tasklet自身の創業者はこれにうまく答えた。Zapierのようなツールはソフトウェア上でフローチャートを定義することを求めるため、構築に手間がかかりエッジケースで壊れやすい。一方Taskletは実行にエージェントを使うため、モデルがテキストの指示から各ステップで何をするかを自ら判断し、フローチャートはまったく存在しない。これは本物のアーキテクチャ上の違いであり、現代のAIワークフロー自動化の多くの背後にあるのと同じ転換だ。ZapierやIFTTTのような成熟したエンジンを手放す価値があるかどうかは、その柔軟性を予測可能で検査可能なステップよりどれだけ重視するかにかかっている。

Taskletのホームページは、40日間のオンボーディングの後にチーム自らの雑務を自動化した、創業51年のヒューストンの製造業者という一次情報の顧客事例を軸にしている。

買い手にとって公平な注意点として、独立したレビューはまだ薄い。G2やCapterraでの実績はまだなく、検証できることの大半はTasklet自身のページとローンチ当日の数件のコメントから来ている。新しい製品としては普通のことだが、群衆よりもドキュメントを信頼することになる。

本当の違い：それぞれの課金方法

ここで両ツールは本当に分かれる。どちらも「作業」を繰り越されないクレジットで計測するが、そのクレジットを取り巻く構造はまったく異なり、それぞれのツールを誰が負担できるかを左右する。

Lindyは2つのメーターを重ねている。シートごとに支払い、各シートが月間クレジット割当を共有プールに追加する。全体の表はこうなる。

落とし穴はシートのルールだ。Lindyを使う人は誰でも有料シートが必要で、Slackのスレッドで@メンションするだけの人も含まれる（Slack経由の参加者はシートが課金される前にまず7日間のトライアルを受ける）。クレジットは繰り越されず、従量課金の超過分もない。プールが枯渇すると、Lindyは次のサイクルまで、または管理者がアップグレードするまで、クレジットを消費するアクションを一時停止する。この「請求書に驚かない」挙動は良い配慮だ。裏を返せば、3,000クレジットのPlusシートは一気になくなりうる。1件の「Big Build」ジョブだけで1,000〜2,500クレジットを消費することがあるからだ。

Taskletはシートのメーターを完全に廃止している。組織全体でクレジットを購入し、無制限のシートがそこから消費する。

有料プランはすべて、無制限の自動化実行、専用のエージェントブラウザ、フルサイズのアップロードを利用できる。月間クレジットはリセットされ繰り越されず、1日600のボーナスクレジットは積み上がらずUTCの深夜0時にリセットされる。単発のトップアップも存在し（1ドルにつき320クレジット、最低25ドル、1年間有効、最後に使用される）、14日以内なら最大250ドルまでの返金も受けられる。

しかしここで「タスクごとのコスト」のギャップに注目してほしい。ここが本当に重要な点だからだ。

Lindyは少なくとも帯を示してくれる。「Everyday Ask」は2〜250クレジット、「Deep work」は250〜1,000、「Big Build」は1,000〜2,500だ。不透明ではあるが、計画を立てられる範囲ではある。Taskletはクレジット単価もタスクあたりの典型的なクレジット数も一切公表していない。コストは定性的にしか説明されず、タスクの複雑さ、コンテキストサイズ、アクティブなツール、トリガー頻度、選択したインテリジェンスレベルによって変わり、ブラウザ操作と高いインテリジェンスが最も速く消費するという。それはある程度まで誠実だが、しばらく製品を使ってみるまで実際の月間コストをモデル化できないということでもある。

参考までに、これはまさに私が買い手にとって最も痛いところだと見ている摩擦だ。Lindy自身のユーザーもそれを率直に語っている。

"For many Lindy AI will give them the ability to automate typical office tasks in a way which is at once not too complicated, but also practical."

My Lindy AI Review, Reddit

それが両ツールにとって正直なスイートスポットだ。実用的で、複雑すぎないオフィス自動化。厄介なのは、サポートキューのような大量かつ収益に直結するワークロードのどちらかに向けようとしたときで、「請求額を予測できない」がただの煩わしさから障害へと変わる瞬間だ。G2では、Lindyの最も声の大きい2つのネガティブタグは文字通り「高額」（42件）と「サブスクリプション費用が高い」（35件）だ。ツール自体は良い。料金モデルが単に大量利用向けに設計されていないだけだ。

どちらも大量のサポート業務向けには作られていない

これは私が最も伝えたい部分で、まさにこれがうまくいかない現場を見てきたからだ。eeselでは3年以上にわたり、稼働中のサポートキューにAIエージェントを導入してきたが、その傷跡は具体的だ。自信満々な口調のボットが、ナレッジベースに関連情報が何もなかったために完全にでっち上げた回答を実際の顧客に返すのを見たことがある。あるチームのボットは存在しないサブスクリプション機能をでっち上げた。別のチームのボットは、製品に関する質問に周期表からそのまま持ってきた「酸素」と答えた。それらは実際の顧客への実際の返答だった。

だからこそ、サポートエージェントの裏にある仕組みは、それを取り巻くビルダーよりも重要だ。LindyやTaskletのような汎用ツールはキャンバスを与え、ガードレールを正しく設定するのはあなた次第だと信頼する。会議の要約を下書きする分には問題ない。しかし出力がすでに苛立っている有料顧客に届く場合は、リスクのレベルがまったく違う。

具体的に言えば、サポート特化型のツールが行い、水平型のビルダーが行わないことはこうだ。

• 本番稼働前にシミュレーションする。 実際の顧客が回答を目にする前に、実際の過去チケット数千件でエージェントを実行し、それが何と答え、何を解決していたかを正確に確認する。私が最近見たある導入事例では、月間およそ1,000件の実チケットに対して、エージェントは93%のトリアージ精度を達成し、返信が1件送られる前にスパムの100%を捕捉した。LindyもTasketも過去チケットでのドライランは提供していない。
• サポートで本当に重要な単位で課金する。ヘルプデスクチームは仕事をクレジットやシートではなくチケットで測る。定額のチケットごとの料金なら、繁忙期であっても11月の請求書は3月のものと同じに見える。
• エスカレーションと確信度をネイティブに扱う。 私が話すサポートの買い手たちが一様に譲らないのはこの点だ。AIは確信を持てることだけに答え、それ以外は静かに人間に任せるべきだという点。これはカスタマーサービス向けAIの最低条件であり、汎用のワークフロービルダーが最適化しているものではない。

これはLindyやTasketへの批判ではない。彼らはヘルプデスクのふりをしているわけではないからだ。批判すべきは、サポートキューに対して間違ったカテゴリーのツールを使うことであり、両方とも技術的にはサポート返信を下書きできてしまう以上、犯しやすい間違いだ。

ターミナルで生きる人へ：CLI、API、MCPという切り口

Taskletが真に開発者フレンドリーな領域の一つが、プログラムによる制御だ。Freeの時代のプランでさえ、すべてのエージェントにサンドボックス化されたコマンドライン環境が付属し、Taskletは任意のHTTP APIやMCPサーバーに接続できる。UI上でクリックして組み立てるのではなく、スクリプト化して社内システムに配線できるエージェントが欲しいなら、これは本物の強みであり、エンジニアリング色の強いチームで実際にAIエージェントがどう導入されているかにより近い。

そうしたアクセスこそ求めているものだという場合、eeselがサポート用チームメイトに同じ表面を提供していることを知っておく価値がある。公開のeesel CLI（@eesel/cli）が、MCPサーバー、Webhook、ネットワークアクセスと並んで用意されている。ポイントは、ダッシュボードで設定するのと同じチームメイトをターミナルからも操作できることだ。人が手動で実行することも、スクリプトがパイプラインの中で自動化することも、Claude Code、Codex、Cursorのようなコーディングエージェントが直接操作することもできる。つまり、「使いやすいダッシュボードのエージェント」と「プログラム可能なエージェント」のどちらかを選ぶ必要はない。人間向けの表面とエージェントに優しい表面を両方備えた1つのエージェントであり、すでに動かしているワークフロー自動化やCIにサポート自動化を組み込みたい場合に重要になる。

Tasketとの違いはCLIの下に何があるかだ。Tasketの場合、ゼロから教え込む必要がある汎用エージェントをスクリプト化することになる。eeselの場合、ヘルプセンター、過去のチケット、エスカレーションルールをすでに知っているチームメイトをスクリプト化することになり、そのプログラム的な表面は、空のサンドボックスではなく仕事特有のコンテキストを携えて到着したものを操作している。

どちらを選ぶべきか

具体的に言おう。正直な答えは完全に仕事の内容次第だ。

Lindyを選ぶのは、Slackを拠点にする小規模チームで、会議メモ、受信トレイのトリアージ、リサーチとレポート、素早い社内構築といった日常的なオフィス自動化のために、心地よくモデル非依存のアシスタントが欲しい場合だ。承認ゲートは安心材料になり、セットアップは両者の中で最も簡単で、アクティブユーザー数が少なければシートごとのモデルでも問題ない。ただしコストは人数に比例して増え、いくつかのBig Buildだけで1つのPlusシートの月間クレジットを食い尽くしうることは知っておこう。

Tasketを選ぶのは、シート計算なしでバックグラウンド作業を行う常時稼働のクラウドエージェントが欲しく、レビューの群衆よりドキュメントを信頼することに抵抗がなく、エージェントごとのサンドボックスアーキテクチャとフローチャートのないノーコードのアプローチを評価する場合だ。非公表のタスクごとの単価は、トライアル中に徹底的にテストすべき点だ。予算を確定させる前に、実際のワークロードを動かして消費量を観察してほしい。

どちらも選ばず、専用に作られたチームメイトを選ぶのは、実際の仕事が大量のカスタマーサポートである場合だ。それはこれらのツールが戦うべき土俵ではない。チケット履歴でシミュレーションを行い、解決件数に応じて課金する専用のカスタマーサービス向けAIエージェントのほうが、中小企業であれ社内サポートを拡大している場合であれ、自分で設定する汎用ビルダーよりも安全で見積もりやすい。

機能一覧よりカテゴリーのほうが重要だ。LindyもTasketも柔軟なツールキットであることには長けている。読者向けの問題がサポートであるなら、不足しているのは柔軟性ではなく、すでに仕事を知っているチームメイトだ。

安全にリリースできるサポートにはeeselを試す

サポートキューを自動化しようとしてLindy対Tasketの比較にたどり着いたのなら、正直な捉え直しはこうだ。eeselは自分で組み立てる汎用エージェントではない。AIチームメイトのプラットフォームであり、定義された仕事のためにすぐ働けるチームメイトを雇う場所だ。現在のラインナップはAIヘルプデスクチームメイトとAIブログライターで、それぞれが空白のキャンバスではなく、その役割に必要なスキル、統合、企業のコンテキストを備えて到着する。

サポートに限って言えば、ヘルプデスクのチームメイトは既存のヘルプデスクに組み込まれ、実際の過去チケットとナレッジで学習し、そのうえで汎用ビルダーにはできない唯一のことを行う。実際の顧客一人に回答する前に、過去のチケット数千件で完全なシミュレーションを実行し、解決率とリスクのあるケースを事前に把握できるようにする。料金はチケットあたり0.40ドルの定額（ブログ執筆は1本4ドル）で、月額50ドルを超えるまでは無料、シートを数える必要も最低利用料もない。11月の請求書は3月のものと同じに見える。

念のため言っておくと、eeselはLindyやTasketの中の統合機能ではなく、任意の社内CRUDアプリを作ってくれるわけでもない。それがトレードオフだ。より狭い仕事を、より多くのコンテキストとより少ないリスクでこなす。仕事がサポートであるなら、それこそが望むトレードオフだ。何かが本番稼働する前に、自分自身のチケットでeeselを無料で試し、シミュレーションしてみることができる。