trigger-cost-savings について
ソースコードの確認と実行状況の分析により、Trigger.dev タスクのコスト削減策を探すスキルです。SDK のバージョンに対応した指針と Trigger.dev MCP サーバーの実行データを使い、開発者が対策の優先順位を付けられます。
主な機能
- 01タスクソースのコストリスク確認
- 02実行状況と失敗パターンの分析
- 03マシン設定と稼働状況の確認
- 04リトライ、待機、デバウンスの確認
- 05優先順位付き提案の作成
活用シーン
- 01タスクコード内の過剰なマシン設定を発見
- 02コストのかかる失敗実行とリトライを特定
- 03チェックポイント付き待機に替えられるポーリングを発見
- 04高頻度トリガーのデバウンス要否を確認
MCP 対応
Trigger.dev MCP サーバーの `list_runs`、`get_run_details`、`get_current_worker` ツールで、実行状況とタスク設定を調べます。ツールが使えない場合も、静的なソース分析を実施できます。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/trigger-cost-savingsを入力して読み込まれたか確認します。
詳細
Trigger.dev のコスト削減分析
タスクの実行状況と設定を分析し、コスト削減の機会を見つけます。このスキルでは、ソースコードの静的分析と Trigger.dev MCP サーバーを介した実行状況のライブ分析を組み合わせます。
始める前に：正式なガイダンスを読む
このスキルには、信頼できるバージョン固定のコストガイダンスが同梱されています。推奨事項をインストール済みの SDK バージョンに合わせるため、まずこれを読んでください。
@trigger.dev/sdk/docs/how-to-reduce-your-spend.mdx— 正式な「支出を削減する」ガイド（マシンサイズ、冪等性による重複排除、並列処理、リトライ、maxDuration、チェックポイント付きの待機、デバウンス）。- 関連リファレンス：
@trigger.dev/sdk/docs/machines.mdx、runs/max-duration.mdx、queue-concurrency.mdx、idempotency.mdx、triggering.mdx（デバウンス＋バッチ）、errors-retrying.mdx（AbortTaskRunError）。
前提条件：MCP ツール
実行状況のライブ分析には、Trigger.dev MCP サーバーが必要です。次のツールを利用できることを確認してください。
list_runs— フィルター（ステータス、タスク、期間、マシンサイズ）を指定して実行を一覧表示get_run_details— 実行ログ、所要時間、ステータスを取得get_current_worker— 登録済みのタスクと設定を取得
利用できない場合は、MCP サーバーをインストールするようユーザーに伝えてください。
npx trigger.dev@latest install-mcp
MCP ツールがなくても、以下のソースコードの静的分析は実行できます。実行データを捏造しないでください。
分析ワークフロー
ステップ 1：静的分析（ソースコード）
タスクファイルをスキャンして、次の項目を確認します。
- 過剰に大きいマシン — 明確な必要性がないのに
large-1x／large-2xを使用しているタスク。 maxDurationの未設定 — 実行時間の上限がなく、コストが際限なく増えるリスクがある。- 過剰なリトライ — 既知の恒久的な失敗に対して
AbortTaskRunErrorを使用していないのに、maxAttempts> 5 となっている。 - デバウンスの未設定 — デバウンスなしで高頻度のトリガーが発生している。
- 冪等性の未設定 — 冪等性キーのない決済タスク／重要なタスク。
- 待機の代わりにポーリング —
wait.for()の代わりにsetTimeout／setInterval／スリープループを使用している。 - 短い待機 — 5 秒未満の
wait.for()（チェックポイントが作成されず、コンピューティングリソースが無駄になる）。 - バッチではなく逐次実行 —
batchTriggerAndWait()で実行できる複数のtriggerAndWait()呼び出し。 - スケジュール頻度が高すぎる cron — 必要以上の頻度で実行されるスケジュール。
ステップ 2：実行分析（MCP ツールが必要）
- 2a. コストの高いタスク —
period: "30d"／"7d"を指定してlist_runsを実行し、総コンピューティング量（所要時間 × 実行回数）が多いもの、失敗率が高いもの、所要時間が短い大型マシン（過剰プロビジョニング）を見つけます。 - 2b. 失敗パターン —
status: "FAILED"／"CRASHED"を指定してlist_runsを実行し、一時的な失敗（リトライ可能）と恒久的な失敗を区別します。後者にはAbortTaskRunErrorを提案し、無駄になったリトライのコンピューティング量を推定します。 - 2c. マシン使用率 — サンプル実行に対して
get_run_detailsを実行します。large-2xのタスクが常に 1 秒未満で完了する場合や、I/O バウンド（API／DB）である場合は、過剰プロビジョニングです。 - 2d. スケジュール頻度 —
get_current_workerで cron パターンを一覧表示し、目的に対して頻度が高すぎるスケジュールにフラグを立てます。
ステップ 3：推奨事項を作成
影響の見積もりを添えた優先順位付きレポートを提示します。
## Cost Optimization Report
### High impact
1. **Right-size `process-images`** — currently `large-2x`, average run 2s. `small-2x` could cut this task's cost by ~16x.
`machine: { preset: "small-2x" }` // was "large-2x"
### Medium impact
2. **Debounce `sync-user-data`** — 847 runs/day, often bursty.
`debounce: { key: \`user-${userId}\`, delay: "5s" }`
### Low impact / best practice
3. **Add `maxDuration` to `generate-report`** — no timeout configured.
`maxDuration: 300` // 5 minutes
マシンプリセットのコスト（相対値）
大きなマシンほど、コンピューティング 1 秒あたりのコストが比例して高くなります。
| プリセット | vCPU | RAM | 相対コスト |
|---|---|---|---|
| micro | 0.25 | 0.25 GB | 0.25x |
| small-1x | 0.5 | 0.5 GB | 1x（基準） |
| small-2x | 1 | 1 GB | 2x |
| medium-1x | 1 | 2 GB | 2x |
| medium-2x | 2 | 4 GB | 4x |
| large-1x | 4 | 8 GB | 8x |
| large-2x | 8 | 16 GB | 16x |
主な原則
- 5 秒を超える待機は無料です — チェックポイントが作成され、コンピューティング料金は発生しません。
- 小さく始めて、必要に応じて拡張します — デフォルトの
small-1xは、ほとんどのタスクに適しています。 - I/O バウンドのタスクに大型マシンは不要です — API 呼び出しや DB クエリはネットワークの応答を待ちます。
- 高頻度タスクではデバウンスが最も大きな節約になります — 集中的なイベントをまとめて、単一の実行にします。
- 冪等性により、課金対象となる作業の重複を防げます — 特にコストの高い処理で効果的です。
AbortTaskRunErrorで無駄なリトライを停止できます — 恒久的な失敗をリトライするために料金を支払わないでください。
バージョン
このスキルは @trigger.dev/sdk に同梱され、node_modules から直接読み込まれるため、インストール済みの SDK バージョンと常に一致します（隣接する package.json を参照してください）。コストに関するドキュメント一式も @trigger.dev/sdk/docs/ に同梱されています。