Hatchet、AIエージェントの長時間処理をdurable workflowへ変えた設計

Hatchetは2023年、Alexander BelangerとGabe Ruttnerによって創業された。

Y Combinatorのプロフィールでは、チームはAI agents、background tasks、mission-critical workflowsのorchestrationを使命として説明している。出典

創業の出発点

創業者が向き合ったのは、アプリケーションの本体ではなく、その裏側で失敗し続ける非同期処理だった。

queue、retry、worker、状態保存を個別に組み合わせるほど、障害時の再実行とデバッグが難しくなる。

Hatchetはtaskをdurably persistする設計を中心に置いた。出典

転機

AI agentが長時間のtool callやhuman-in-the-loopを必要とするようになると、単なるjob queueでは状態を扱いきれない。

Hatchetはdurable workflow、checkpoint、replayという言葉で、開発者の問題を「失敗しないqueue」から「途中から再開できる実行基盤」へ言い換えた。出典

Alexander BelangerはHatchetの使命を、開発者が「great applicationsを作ることに集中できる」よう、simpleでpowerfulなorchestration layerを提供することだと説明している。出典

成長と現在

OSSとしてself-hostでき、CloudではDeveloper、Team、Scaleへ進める構成にしたことで、個人検証から組織運用まで同じ製品を使える。

2026年にはSSO、tenant isolation、audit logs、dedicated shardsを含むenterprise readinessを発表した。出典

結び

Hatchetの設計は、AI時代の特別な魔法というより、非同期処理を本番の一級データとして扱うという堅実な選択に見える。

AI agentの性能競争が進むほど、裏側のdurabilityと説明可能性が差別化になる。

AIエージェントや長時間のbackground taskは、失敗時のretry、状態保存、観測を自前で実装すると本来の機能開発から離れる。

Hatchetはtaskをdurably persistし、retry・replay・monitoringを一つの実行モデルにまとめる。出典

OSS self-hostingとCloudを同じモデルで使える点が、検証から本番への移行コストを下げる。

実行状態、retry、worker capacity、tenant分離を同じモデルで扱う実装と運用知識が蓄積するほど、単純なqueue置換より移行コストが高くなる。

OSSで導入されるほど実ケースの知見も増える。出典

強いconsumer network effectはない。

導入企業が増えることでSDKや事例、OSSの信頼性は高まるが、価値の中心は各社のworkflow実行品質にある。

AI agentを本番運用するbackend team、並列データ処理を持つ開発者、既存queueやDAG基盤の運用負荷に困るteam。

単発cronだけで高度なdurabilityが不要な小規模処理には過剰。

PostgreSQLを基盤にdurabilityを中心概念へ据え、queueだけでなく実行履歴・checkpoint・observabilityまで扱う。

さらにPython、TypeScript、Go、RubyのSDKとMIT licenseで入口を広げた。出典

AI agentsという新しい用途に、既存のworkflow engineとは異なる文脈で訴求した点も効いている。

durable executionは便利だが、運用対象に実行履歴が増えるほどstorage、retention、権限設計が複雑になる。

Cloud料金もtask runsに連動するため、並列化を進める顧客ほどcost governanceが必要になる。出典

OSSをself-hostingの入口にし、Cloudでは無料枠からtask runs従量課金へ接続する。

docsと複数言語SDKでdeveloper adoptionを取り、enterprise readinessではSSO、audit logs、dedicated shardsへ拡張する。出典

主要チャネル: open_source, developer_docs, yc, content, community

新しいAI用途を入口にしても、価値の核はretry、state、observabilityという既存の痛みを確実に解くことにある。

OSSとCloudを同一の実行モデルにすると、試行と本番の分断を小さくできる。

日本ではAI agentの業務導入が進むほど、長時間処理の再開、監査、個人情報を含むworkflowの可視化が課題になる。

国内リージョン、既存SIerとの運用分担、監査ログの日本企業向け説明を揃えると導入理由を作りやすい。