新たなAIサービスを作るうえで、開発者の誰もが頭を抱える「地味だけど厄介な問題」がある。それは使った分だけ、トークンごとに、GPU時間ごとに、複雑になっていく料金計算をどう決定するか、という課金の問題だ。2025年に設立されたスタートアップのAutumn AIは、この難問をたった3行のコードで解いてみせた。デモデーの前日に事業を丸ごと方向転換したファウンダー2人が下した決断とは。
AI時代の課金をどう管理するのか?
Autumn is the open-source billing database and mission control that all apps (poorly) build in-house
— Autumn (@autumnpricing) 2025年12月17日
this has never been harder to manage: usage-based limits need sub-100ms latency and 100% reliability
let's leave debugging webhook handlers in 2025 👋 https://t.co/nWABrHMHJ3
“Autumnは、どのアプリも(たいてい下手に)自社で作ってしまう課金データベースと管制塔をオープンソースで提供する。この領域の運用はかつてないほど難しくなった。使用量の上限判定には100ミリ秒未満の応答と100%の信頼性が要る。Webhookの調査に追われる日々は2025年に置いていこう。”
Autumn公式(@autumnpricing)2025年12月の投稿より(日本語訳)
AIの急激な隆盛に伴って時代の到来とともに、ソフトウェア企業が直面した新たな課題がある。それは「どうやって課金するか」だ。従来のSaaSなら月額固定のサブスクリプションで済んだ。しかし、AIサービスでは話がまったく異なる。
まず前提としてユーザーごとにAPIコールの回数が違う。トークン消費量が違う。GPUの使用時間もバラバラだ。そのうえで従量課金、クレジットシステム、サブスクリプション、メータリング、これらを組み合わせた課金モデルを構築しなければならない。しかも、顧客が増えるたびに課金ロジックはどんどん複雑になっていく。まさに悪夢に等しい。
一方でStripeのような優れた決済サービスインフラは既に存在する。しかしStripeは「お金を受け取る」パイプラインであって、「いくら請求するかを計算する」のは開発者の仕事だ。つまりAIスタートアップのエンジニアたちは、本来プロダクトの改善に費やすべき貴重な時間を、課金ロジックの再構築開発という「退屈だが致命的に重要な問題」に奪われているのだ。
この難題をたった3つの関数呼び出しで解決しようとしているスタートアップがある。それがAutumn AIだ。
フィンテック向けソフトから一転、課金インフラへ
We are so grateful to finally close this chapter. Thank you for an amazing Demo Day ❤️
— John Yeo (@johnyeo_) 2025年9月12日
But what actually we're most proud about is how many founders have started reaching out to us to chat when they feel stuck and want to pivot
9 months ago we did YC's F24 batch. We spent the… pic.twitter.com/k0L4B1wbda
“9ヶ月前、僕らはYCのF24バッチにいた。3ヶ月間まるで確信が持てないまま、50人の投資家にピッチして、その全員に無視された。いまAutumnを作れているのは幸せだけど、どん底で暗闇をさまよい、もう諦めたいと思っていたあの感覚は、はっきり覚えている。もし今そこにいるなら、僕らはいつでも力になる。”
共同創業者ジョン・ヨー(@johnyeo_)の投稿より(日本語訳)
Autumnの共同創業者はアユシュ・ロドリゲスとジョン・ヨーの2人だ。アユシュはケンブリッジ大学(University of Cambridge)で自然科学を学んだ後、欧州を代表する決済フィンテック企業Checkout.comでプロダクトマネージャーとして2021年から課金・決済の仕組みを内側から設計してきた。もう一人のジョンはImperial College London出身のエンジニアで、バックエンド開発を簡略化する独自のローコードプラットフォーム「Visual Backend」など、開発者ツールを6年にわたって作り続けてきた実績を持つ。
二人が最初に取り組んでいたのは、フィンテック企業向けの顧客審査・オンボーディング自動化プロダクト(Recase)だった。YCの2024年秋(F24)バッチに参加し、決済業界の経験を活かした堅実な事業を進めていた。しかし、F24デモデーの前日、プレゼン直前というタイミングで方針を全面的に変える決断をした。その後数ヶ月、新たな方向性を模索しながら、最終的にAI向け課金インフラという領域にたどり着き、2025年のS25バッチに改めて参加した。
転機となったのは、YCの創業者らへの聞き込みだった。30人以上のYC創業者・リーダーに課金の実態を取材して回ると、繰り返し出てきたのが「課金の実装がしんどい」「Stripeだけじゃ全然足りない」「従量課金にサブスクを組み合わせるのは地獄だ」という声だった。アユシュは元Checkout.comのPM(プロダクトマネージャー)だ。課金の複雑さは誰よりも理解している。そして彼は気づいた。この問題は、自分たちが解くべき問題だと。
S25のバッチ仲間であるAI系スタートアップが、そのまま最初の顧客になった。
「課金の複雑さを知る人間」と「開発者体験を設計できる人間」。片方だけでは、課金の複雑さを丸ごと肩代わりするという発想は生まれなかっただろう。課金ドメインの深い理解と、開発者ファーストの設計思想。この掛け合わせこそがAutumnのプロダクトの核心となっている。
たった3つの関数を呼び出せば全てが完結!
Why do people use Autumn?
— Autumn (@autumnpricing) 2025年12月31日
Today, billing providers handle payments, then send you webhooks to manage fulfilment – giving customers access to plans, features and usage limits. This creates 2 problems:
1. It's unreliable
11+ webhook events, out-of-order delivery, race conditions,… https://t.co/l4rYNfZ5EH pic.twitter.com/LmE3AZoQib
“なぜみんなAutumnを使うのか。いまの課金サービスは決済を処理したあと、webhookを送ってくる。それを受けてプランや機能、利用上限を管理するのは開発者の仕事だ。11種類を超えるイベント、順序の狂った配信、競合状態——正しく動くまでに数週間かかる。ARR数百万ドル規模の企業がAutumnに移ってきている。webhookはゼロだ。”
Autumn公式アカウント(@autumnpricing)の投稿より(日本語訳)
Autumnのプロダクトは、そのシンプルさにおいて際立っている。従来、AI企業の課金を実装するには、webhookの設定、メータリングサービスの構築、Stripeとの連携ロジック、サブスクリプション管理、クレジット残高の追跡と、膨大なコードを書く必要があった。
Autumn AIは、これをたった3つの関数呼び出しになんと凝縮したのだ。webhookなし。複雑な設定なし。わずか3行のコードで、従量課金、クレジット、サブスクリプション、メータリングのすべてが動く。
-
1
顧客を作成する 新規ユーザーを登録するだけ。難しい設定はいらない
-
2
使った量を記録する APIを何回呼んだかなど、使用量を送るだけ。従量課金はAutumnが裏で計算する
-
3
使えるか確認する その顧客が機能を使えるかをAutumnに聞くだけ。残高やプランの判定も任せられる
このシンプルさの裏には、膨大な複雑さの抽象化がある。Autumnは内部で、メータリング、プラン管理、クレジット計算、Stripeとの同期をすべて自動処理する。開発者はAutumnの3つの関数を呼ぶだけでいい。課金の専門家になる必要がなくなったのだ。
この設計の強みは、Stripeの上に乗るレイヤーとして機能する点にある。Stripeはすでに世界中の何百万もの企業に導入されている。Autumnはそのインストールベースを活用できる。Stripeを使っている企業は、既存の決済設定を一切変えずにAutumnを追加できる。導入の障壁が限りなく低いのはそのためだ。
実績も出始めている。すでに本番環境で数百人の開発者がAutumnを利用し、数百万ドル(約3億円以上)規模の課金処理が行われている。YC S25のバッチ仲間を起点に、口コミで広がっている。
オープンソース戦略の堀
Autumn is the open-source billing database and mission control that all apps (poorly) build in-house
— Autumn (@autumnpricing) 2025年12月17日
this has never been harder to manage: usage-based limits need sub-100ms latency and 100% reliability
let's leave debugging webhook handlers in 2025 👋 https://t.co/nWABrHMHJ3
“Autumnは、どんなアプリも結局は自前で(しかも出来の悪いものを)作ってしまう課金データベースであり、その管制塔だ。そしてこの領域は、かつてないほど難しくなった。従量課金の上限判定には100ミリ秒未満の応答と100%の信頼性が要る。webhookハンドラのデバッグは2025年に置いていこう。”
Autumn公式アカウント(@autumnpricing)の投稿より(日本語訳)
Autumnのもうひとつの戦略的選択が、オープンソースだ。コードはGitHub上で公開されており、誰でもセルフホストできる。これは単なる善意ではない。緻密に計算された配布戦略だ。
開発者ツールの世界では、オープンソースは最強の配布チャネルだ。HashiCorp(Terraform)、Vercel(Next.js)、Supabase(Firebase代替)、成功した開発者ツール企業はほぼ例外なくオープンソースから始まっている。開発者は「試してから買う」人種だからだ。
- 1信頼の構築コードが公開されているから、中で何をしているか分かる。課金という機密性の高い領域で、ブラックボックスは受け入れがたい。
- 2無料で始められるセルフホストなら無料。小さなスタートアップでもリスクなく導入できる。成長したらマネージドプランに移行する。
- 3コミュニティによる改善外部の開発者がバグを見つけ、機能を提案し、プルリクエストを送る。開発速度が自社だけの何倍にもなる。
- 4ロックインの排除いつでも自社運用に切り替えられる安心感。逆説的に、この自由さがマネージドプランの契約を促進する。
日本のSaaS企業への示唆
🍁@AutumnPricing lets you build any pricing model with a few lines of code. It’s the easiest way to set up and iterate on pricing & billing.
— Y Combinator (@ycombinator) 2025年2月17日
Subscriptions, usage-based, credits, add-ons— Autumn handles it all for you. And it's open source.https://t.co/rqUDaFq70f pic.twitter.com/Sp0Cbbbk6N
“Autumnを使えば、どんな料金モデルでも数行のコードで組める。料金設計と請求を用意し、作り替えていくのにもっとも簡単な方法だ。定額購読、使用量課金、クレジット、追加オプション。すべてAutumnが引き受ける。しかもオープンソースだ。”
Y Combinator公式(@ycombinator)2025年2月の投稿より(日本語訳)
Autumnの物語は、日本のSaaS企業やAIスタートアップにとって、いくつかの重要な示唆を含んでいる。
まず、日本のSaaS企業も、まったく同じ課金の複雑性に直面している。従来の月額固定サブスクから、AI機能の従量課金への移行を迫られている企業は多い。しかし、日本にはAutumnのような「課金インフラのミドルウェア」がまだ存在しない。各社がそれぞれ独自に課金ロジックを構築しているのが現状だ。
次に、開発者ツール×オープンソースというプレイブックが、日本にはまだほとんど存在しないという事実がある。米国では、PostHog(プロダクトアナリティクス)、Cal.com(スケジューリング)、Novu(通知インフラ)など、オープンソースの開発者ツールが次々と生まれ、巨額の資金を調達している。日本では同様のムーブメントが起きていない。
- 1課金ミドルウェアの機会日本のSaaS企業向けに、Stripe Japanの上に載る課金ミドルウェアを作る。Autumnのアプローチを日本市場に最適化すれば、大きな需要が見込める。
- 2OSS開発者ツールの空白日本発のオープンソース開発者ツールは極めて少ない。しかし、日本の開発者コミュニティは大きく、品質への要求も高い。ここにチャンスがある。
- 3「ピボットの意思決定」という教訓愛着のあるプロダクトを捨て、顧客の痛みに忠実であること。Autumnはその重要性を、身をもって示している。
Autumnが証明しようとしているのは、巨大なプラットフォーム(Stripe)の上にも、まだ巨大な課題と機会が残っているということだ。Stripeが銀行の上に載るレイヤーとして成功したように、AutumnはStripeの上に載るレイヤーとして成功しようとしている。プラットフォームの上にプラットフォームを作る。これはテクノロジー産業に普遍的なパターンだ。
3つの関数呼び出し。それは単なるコードの簡潔さではない。「開発者の時間を尊重する」というStripeの哲学を、次の時代に受け継ぐ宣言だ。AI時代の課金は複雑だ。しかし、その複雑さを開発者に押し付ける必要はない。Autumnは、その複雑さを3行のコードの裏側に隠そうとしている。
起業家への示唆
- 1ドメイン知識こそが最速の発見経路アユシュがCheckout.comで決済の内側を設計してきたからこそ、課金ロジックの複雑さを誰より深く理解できた。自分がかつて現場で苦しんだ問題こそ、最もリサーチコストが低く、解像度が高い課題の源泉になる。
- 2デモデー前日のピボットを恐れないAutumnはプレゼン直前に前のプロダクトを捨て、数ヶ月かけて新領域にたどり着いた。コミットメントより顧客の痛みへの忠実さを優先した判断が、YC S25での再挑戦と成長につながった。
- 3巨大プラットフォームの「上」に市場があるStripeやAWSのようなインフラが整備されるほど、その上に乗るレイヤーの機会も広がる。「既存の強者の上に乗る」設計は、導入障壁を下げ、既存ユーザーベースをそのまま市場として活用できる。
Over the last decade every other part of the software stack has been replaced by a higher level of abstraction:
— John Yeo (@johnyeo_) 2025年8月14日
AWS (2006) -> Vercel
Heroku (2007) -> Supabase
Twilio (2008) -> Resend
Okta (2009) -> Better Auth
Datadog (2010) -> Sentry
Stripe is the only product founded pre 2010… https://t.co/KwHXic5q4e
“この10年で、ソフトウェアスタックの他の部分はすべて、より高い抽象化に置き換えられてきた。AWS→Vercel、Heroku→Supabase、Twilio→Resend、Okta→Better Auth、Datadog→Sentry。2010年以前に生まれた製品で、アーリーステージの開発を今も独占しているのはStripeだけだ。現場から見れば、近く地殻変動が起きるのは明らかだ。”
共同創業者ジョン・ヨー(@johnyeo_)の投稿より(日本語訳)
※本文中の円換算は1ドル=155円で計算した参考値です。為替レートにより実際の金額は変動します。



