Trigger.devの使い方と料金：TypeScriptのバックグラウンド処理を任せるには

Trigger.devで何を置き換えられるのか

Trigger.devは、タスクランナー、キュー、スケジューリング、デプロイ、実行状況のダッシュボードをまとめて提供します。非同期関数を書いてペイロードを渡せば、アプリがユーザーにレスポンスを返した後も、別のワーカーが処理を進めます。バックグラウンドジョブのために自前で組み合わせていたインフラを代替できますが、アプリのデータベース、業務ルール、AIエージェントの判断を担うモデルまで置き換えるものではありません。

2026年11月11日に、公開中のドキュメント、料金表、変更履歴、GitHubリポジトリで確認しました。 本稿はドキュメントに基づく評価であり、ログインしての動作検証や性能ベンチマークは行っていません。推奨の基準は、実行環境を誰が運用するか、復旧の単位、運用担当者の扱いやすさ、本番環境の制限です。

2025年8月18日付のv4公開時の変更履歴では、ウォームスタート、承認やコールバックを待つwaitpoint、優先度付きキュー、ダッシュボードの変更、ライフサイクルフックが追加されました。確認時点で掲載されていた最新リリースは、2026年11月10日公開のv4.8.4で、ワークロードIDと信頼済みデプロイの公開機能が加わっています。これらのID機能により、対応するサービスやデプロイシステムでは、長期間有効な認証情報を保存する代わりに、有効期間の短いIDトークンで認証できます。

プロダクトの創業者にとっての実益は、「アップロード後にレポートを生成する」処理を、完了まで開き続けるWebエンドポイントから、管理されたバックグラウンドタスクへ移せることです。ただし、どのレポートがどの顧客のものかを記録し、生成に失敗した際の扱いを決めるのは、引き続きアプリ側の責任です。

どのチームに向き、どのチームには向かないか

Trigger.devが向いているのは、エンジニアが開発・運用を担い、バックグラウンド処理もほかのTypeScriptコードと一緒に管理したいプロダクトです。「この関数を依存関係ごと確実に実行したい」という要件に近いほど、適合度が高くなります。

以下の比較では、どこにワークフローを記述し、何を自分たちで担うかに注目します。機能の多さを競うランキングではなく、アーキテクチャの選択肢として見るための表です。

n8n：業務運用担当者がワークフローを管理する場合

見込み客の取り込み、情報補完、フォローアップをつなぐ営業オペレーション担当者には、n8nのほうが適しています。ビジュアルなワークフローなら、変更のたびにアプリコードを修正せずに、プロセスを確認できます。AIにも業務自動化にも対応しているため、「エージェントが必要」という理由だけで候補から外すべきではありません。

違いは、誰が保守を担うかです。ライブラリやデプロイ時の依存関係を伴う独自のアプリロジックが難所なら、拡大し続けるビジュアルフローよりTypeScriptタスクのほうが保守しやすいかもしれません。一方、運用担当者自身が業務の手順を変更できることが重要なら、Trigger.devではその変更にエンジニアの手が必要になります。この観点での製品選定は、n8n代替ツールの比較も参照してください。

InngestとTrigger.devの違い

耐久性のある関数を求める開発者にとって、Inngestは近い比較対象です。現在のドキュメントには、ステップの結果を保存し、失敗したステップから再試行する仕組みと、TypeScript、Python、GoのSDKが記載されています。処理を名前付きのステップに自然に分解できるアプリや、Pythonでワークフローを書きたいチームなら、候補に入れる価値があります。

Trigger.devの魅力は、オーケストレーションに加えて、タスクの実行環境と依存関係もまとめて扱える点です。Inngestの明示的なステップモデルでは、どこを単位に復旧するかがコード上で見えます。どちらを選んでも、外部への書き込みを安全に繰り返せる設計は必要です。待機やエージェントに対応するのは片方だけだと思い込まず、処理をどうデプロイし、障害をどう捉えたいかで選んでください。

Temporal：実行基盤全体の設計を決める場合

業務プロセスが複数サービスを横断し、バックグラウンド関数を素早くデプロイすることより、そのライフサイクルの管理が重要なら、Temporalを候補に入れるべきです。ドキュメントでは、複数言語のSDKと、セルフホストまたはマネージドのTemporalサービスとともにアプリをデプロイする方法が説明されています。

ここで引き受けるのは、アーキテクチャへの継続的な責任です。エンジニアがワークフローアプリと運用設計を担います。レポート生成をリクエスト処理から切り離したい小規模なTypeScriptプロダクトには、必要以上に大きな仕組みになるかもしれません。長期にわたる業務プロセスを標準化するプラットフォームチームにとっては、まさにそれが導入の目的になり得ます。

バックグラウンドタスクの作成・デプロイ・再試行

Trigger.devでは、リクエストの遅い処理を、独立して実行状況を確認できるタスクへ移せます。文書インポート機能を例にすると、アプリはアップロードを受け付け、インポートを記録して処理を起動し、顧客に操作を返します。抽出や分類は、その後もバックグラウンドで進められます。

以下はタスクのドキュメントにあるhello-worldの例からコメントを省き、タスクを検出・インポートできるようexportを追加したものです。

import { task } from "@trigger.dev/sdk";

export const helloWorld = task({
  id: "hello-world",
  run: async (payload: { message: string }) => {
    console.log(payload.message);
  },
});

重要な境界はペイロードです。対象のインポートを特定し、処理するために必要な情報を渡し、顧客向けのリクエストはタスクの完了と切り離します。

再試行のドキュメントでは、タスク全体の再試行と、retry.onThrowで小さな処理ブロックを再試行する方法、retry.fetchでHTTPリクエストを再試行する方法が区別されています。タスクの再試行では、タスク全体が繰り返されることがあります。インポート処理が成功しても、その後の通知で例外が発生した場合、何も考えず全体をやり直すと、完了済みの書き込みまで繰り返すおそれがあります。

**設計の原則は、**一時的な障害をできるだけ失敗した操作の近くで再試行し、書き込みを冪等にすることです。つまり、同じ操作を繰り返しても、業務上の効果が重複しないようにします。タスク基盤が提供するのは復旧の仕組みであり、再試行で請求書、メール、レコードが重複するかどうかは、データベースの制約や外部APIの選び方に左右されます。

Trigger.devでPythonを使うには

Trigger.devは、Pythonビルド拡張を通じて、TypeScriptタスク内からPythonスクリプトを実行できます。WebプロダクトはTypeScriptで、文書パーサーはPythonという場合に便利です。ただし、これはランタイム間をつなぐ仕組みであり、PythonネイティブのワークフローSDKと同じ開発体験ではありません。

デプロイ時に注意したい点があります。この拡張のrequirementsFileによるインストールは本番環境のみで行われ、開発用の依存関係はローカルでインストールする必要があります。手元のPCでパーサーが動いても、デプロイ先の依存関係が正しいとは限りません。

エージェントを承認待ち・コールバック待ちで一時停止する

Trigger.devのwaitpointを使うと、人や外部サービスから必要な結果が届くまでワークフローを停止できます。返金エージェントなら、「返金を提案する」と「返金を実行する」を分けることになります。タスクは提案を準備して承認を待ち、承認結果が届いてから処理を続けられます。

開発元のwaitpoint解説では、この受け渡しにwait.createToken、wait.forToken、wait.completeTokenを使っています。外部サービス向けのコールバックURLも紹介されています。誰が承認でき、その承認によって何を許可するかは、引き続きアプリが決めます。

時間とコストには、それぞれ別の扱いがあります。現在の待機ドキュメントによると、5秒を超える時間指定の待機はコンピュート使用量に含まれません。ただし、同時実行枠が解放されるのは、待機開始から60秒後にマシンのスナップショットが作成され、シャットダウンされた時点です。そのため、短い待機ではコンピュート料金がかからなくても、実行枠を占有し続けることがあります。

多数のエージェント実行が同時に短時間停止する場合、この違いが重要になります。タスクが休止中だからといって、別のタスクに実行枠が空くとは限りません。CPU負荷の高い処理だけでなく、実行中の処理と短時間の待機も含めて、同時実行数を設計してください。

エージェントの推論部分については、別稿のAIエージェントフレームワーク比較を参照してください。Trigger.devの実行基盤は処理の継続を支えますが、エージェントが何をするかを決めるのは、プロンプト、ツール、承認ルールの選択です。

同期スケジュールは実行時刻の前提まで確認する

Trigger.devはschedules.taskによる定期実行に対応しており、スケジュールはコードで定義するほか、ダッシュボードやSDKから設定できます。顧客データの同期がよい例です。スケジュールが処理を開始し、タスクが作業を進め、実行履歴で完了したかを確認できます。

定期実行タスクのドキュメントには、「cron」という言葉以上に重要な制限が記載されています。新しいスケジュールには、デフォルトで60分の実行時刻分散ウィンドウが設定されます。毎日のジョブが、cronで指定した時刻ちょうどに始まるとは限りません。対応するプランでは、window: "0m"で分散を無効にできます。

Freeで新規作成するスケジュールは、実行頻度が最大で1時間に1回、ウィンドウが最短60分に制限されます。従来の条件が適用される既存スケジュールは例外です。アップグレードしても、制限付きスケジュールが即座に書き換わるわけではありません。有料プランの状態でもう一度保存するか、再デプロイしてください。

毎日のダイジェスト配信なら、時刻の分散を許容できるかもしれません。顧客に決まった時刻のレポート提供を約束しているなら、デフォルトの挙動をそのまま前提にしてはいけません。既存のcronジョブを置き換える前に、実行間隔、タイムゾーン、許容できる遅延を別々の要件として整理してください。

ユーザーには進捗を、開発者には障害箇所を見せる

Trigger.dev Realtimeを使うと、バックグラウンドジョブを、理由の分からないローディング表示から、進行状況が見えるワークフローへ変えられます。インポート画面なら実行状態と進捗メタデータを表示し、文章生成なら処理中の出力をストリーミングします。この2つは異なるデータ経路です。

Realtimeの概要では、ステータスとメタデータを追跡するuseRealtimeRunと、定義済みのストリームから出力されたデータを受け取るuseRealtimeStreamが区別されています。Realtimeのフックと関数には、すべて認証が必要です。顧客に見せるべきなのは自分のインポートの進捗であり、ほかの顧客の実行情報まで閲覧できてはいけません。

開発者向けのダッシュボードとタスクログが答えるのは、「どこで実行が止まったか」という別の問いです。ユーザー向けの進捗メッセージは役に立つ分かりやすさを保ちつつ、内部エラーの詳細をそのまま製品UIへ流さないようにしてください。

Trigger.devのMCP連携

Trigger.devのMCPサーバーは、ドキュメント検索、プロジェクトの初期化、タスクの起動、デプロイ、実行状況の確認を行うツールをコーディングアシスタントに提供します。MCPはModel Context Protocolの略で、アシスタントがこれらのツールを呼び出すためのインターフェースです。

編集とデバッグの往復を短くするために使い、タスクの挙動をレビューする代わりにはしないでください。アシスタントがワークフローをデプロイできることと、再試行で外部への操作を安全に繰り返せることは別です。

Trigger.devの料金：本番運用ではどのプランを選ぶか

制限内に収まる小規模な本番アプリなら、Trigger.dev Hobbyが妥当な出発点です。月額$10で$10分の利用クレジットが含まれ、同時実行数は50、ログ保持期間は7日です。Freeは月額$0で$5分のクレジット付き、同時実行数は20、ログ保持期間は1日で、クレジットを使い切った後もタスクを動かし続けるにはアップグレードが必要です。これらは2026年11月11日に確認した公開料金ページの数値です。

Hobby未満のプランで問題になるのは、使用量だけではありません。Freeでは、コンピュート料金が膨らむ前にスケジュール制限が導入の障害になることがあります。Realtimeの同時接続数も判断の境界で、Freeには10、Hobbyには150接続が含まれます。Proは月額$50で$50分のクレジット付き、同時実行数の基本枠は200、ログ保持期間は30日です。同時実行数やデバッグのための履歴が必要なら、アップグレードを検討する理由になります。

具体的な試算として、月に10,000件のジョブが成功し、各ジョブがSmall 1xで60秒実行され、再試行はないと仮定します。1秒あたり$0.0000338に呼び出し1回あたり$0.000025を加えると、使用料金は次のようになります。

10,000 × ((60 × $0.0000338) + $0.000025) = $20.53.

Hobbyの月額$10には、この使用料金のうち$10が含まれるため、追加分は$10.53です。したがって、この条件でのプラットフォーム費用の総額は$20.53、完了したジョブ1件あたり$0.002053になります。これは公開単価からの計算であり、実際のワークロードを測定した結果ではありません。モデルAPI呼び出し、ストレージ、その他のサービスは別料金で、再試行すれば実行量も増えます。

必要な同時実行数、スケジュール条件、履歴の長さに合わせてプランを選んでください。実行時間から使用量を見積もり、失敗や再試行の余裕も加えます。成功した場合だけの試算を、支出の上限と考えるべきではありません。

導入判断を左右する制約

Trigger.devはワーカー用インフラの多くを肩代わりしますが、利用者側に残る責任も具体的で、結果に大きく影響します。

セルフホストでCloudと同じ機能が使えるとは限らない

Trigger.devのリポジトリには、ライセンスがApache-2.0であることが明記され、Docker ComposeとKubernetesによるデプロイガイドへのリンクがあります。コードとライセンスはGitHubリポジトリで確認できます。

セルフホストの比較ページでは、現在、ウォームスタート、オートスケーリング、チェックポイント、専任サポートがCloud限定とされています。またセルフホストでは、Webアプリ、Redis、Postgres、ワーカースーパーバイザー、更新、信頼性の確保を自分たちで担います。

承認待ちの多いワークフローでは、チェックポイントの挙動がCloudを選ぶ重要な理由になります。一方、最新リリースにはセルフホスト環境のmicroVMスナップショットのクリーンアップへの言及もあります。そのため、比較表とリリースの詳細だけで、単純に同等の機能があると判断することはできません。予定している構成でサポートされる挙動を確認し、インフラ運用も含めて判断してください。

基盤側に実行時間の上限がなくても、失敗時の方針は必要

Trigger.devでは、プラットフォーム固定の実行時間上限なしで処理を継続できますが、設定でコンピュート時間の制限であるmaxDurationを指定することはできます。実行時間のドキュメントには、上書き設定と、無期限実行のためのtimeout.Noneが記載されています。

また、最大実行時間を超えた場合、cleanup、onSuccess、onFailureは呼び出されないとされています。失敗フックで予約枠を解放したり、インポートを失敗状態に更新したりするアプリには、注意が必要な挙動です。単一のフックを唯一の復旧手段にせず、未完了のアプリレコードを突き合わせて整合させる方法を用意してください。

再試行の仕組みだけでは業務操作の安全性を判断できない

Trigger.devは、途中まで進んだ返金、連続メール送信、データインポートを繰り返してよいか判断できません。実行の復旧が機能しても、外部への操作を繰り返したことで別の効果が生じれば、業務上の結果は誤ったものになります。

導入前に、二重に行ってはいけない書き込みと、それが完了した証拠になる記録を特定してください。その境界がワークフローにないままでは、タスク基盤を変えても正しさの問題は解消しません。

Cloudに認証情報を預ける際は信頼範囲を明確にする

Trigger.devは、2026年11月1日、一部環境で顧客のルートAPIキーが侵害され、環境変数への不正アクセスが発生したセキュリティインシデントを報告しました。インシデント報告によると、影響を受けた顧客には通知済みで、該当キーは失効されました。セルフホスト環境は影響を受けていません。

新規導入を検討する側にとっては、認証情報の権限範囲とベンダーの是正措置も評価対象になります。ただし、すべての顧客が被害を受けたことや、セルフホストなら自動的に安全になることを示すものではありません。ワーカーが保持する認証情報と、対応するID機能が利用サービスに合うかを確認してください。

結論：ワーカーの運用を任せたいチームに向く

本稿で挙げた選択肢の中では、バックグラウンドコード、実行インフラ、実行状況のダッシュボードをまとめて利用したいTypeScriptプロダクトチームに、Trigger.devが最も適しています。インポートやレポート生成など、負担の大きい処理から着手し、ほかを移行する前に再試行の境界を定めてください。

業務運用担当者が連携フローを管理・編集する必要があるならn8nを選びます。明示的なステップモデルやPython/GoネイティブのワークフローSDKが必要ならInngestを候補に入れます。複数サービスを横断する耐久性のある業務プロセスの設計を、プラットフォームチームが意図的に担いたいならTemporalが選択肢になります。

主な要件が業務アプリ間での情報の受け渡しなら、タスク用インフラを導入する前に、Zapier代替ツールのガイドから検討するほうが適切です。

移行前にAI業務ワークフロー監査チェックリストを使い、対象の処理、担当者、失敗時の経路、引き継ぎを整理してください。

よくある質問