Lago、従量課金の複雑さをOSS billing engineで解く設計

課金のブラックボックスを疑う

LagoのCEO兼共同創業者Anh-Tho ChuongとCPO兼共同創業者Raffi Sarkissianは、課金システムについて「full transparency and control your financial infrastructure」と説明している。出典

その問題意識が、後から請求額を直すのではなく、利用イベントから請求書までを追跡可能にする出発点になった。

OSSを入口にする

二人は自作billingの負担と、第三者サービスがブラックボックスになる不満の間に、open-sourceという選択肢を置いた。出典

GitHubでengineを公開し、API-firstでusage・pricing・invoiceをつなぐことで、課金をプロダクトチームが理解できる部品へ変えた。出典

複雑さを顧客事例で証明する

LagoはMistral AI、PayPal、Groq、Synthesiaなどの事例を前面に出し、単純なsubscriptionではない請求を扱えることを示した。出典

公式ページは累計$22Mの調達と月間$829Mの請求書発行も掲げているが、ARRや顧客数は公開されていない。出典

OSSからPremiumへ

現在はCloud deploymentとSelf Hosted deploymentのPremiumを用意し、open-source engineの透明性と、運用・support・高度なbilling機能を組み合わせる。出典

これは「無料で試す」と「本番の責任を委ねる」を分ける設計だ。

今も残る選択

Lagoの道のりは、課金を決済providerの設定ではなく、利用量とrevenueをつなぐ基盤として再定義する道のりだった。

導入側には自由度が増える一方、税務・回収・運用の責任が残る。

その境界まで含めて採用判断することが、Lagoを正しく使う条件になる。

利用量課金や複雑なentitlementを持つSaaS・AI・IoT企業は、課金ロジックを自作すると請求・決済・会計の境界で開発負債を抱える。

Lagoはusage event、billable metric、pricing、invoiceを一つのAPI-firstモデルに揃え、financeとengineeringの共通言語を作る。

公式は「full transparency, control and flexibility」を価値として掲げる。出典

強みは課金機能そのものより、usageからrevenueまでのデータモデルと、OSS・Cloud・self-hostedをまたぐ運用知識にある。

実際のbilling edge caseがAPIやdocsへ蓄積されるほど移行コストが上がるが、巨大なnetwork effectではない。

ネットワーク効果は弱い。

請求データは顧客ごとに閉じるため利用者が増えて直接価値が増す構造ではない。

一方、GitHub・顧客事例・integrationが増える間接効果はあり、課金パターンの学習資産が導入判断を助ける。

usage-based pricing、AI API、developer tool、IoT、marketplaceなど、顧客ごとに請求ルールが変わるプロダクトのengineering・finance責任者向け。

単純な固定月額だけならStripe Billing等の方が軽い可能性がある。

第一にopen-sourceで課金エンジンを試せるため、ブラックボックスを避けたい技術チームに届く。

第二にMistral AIやPayPalなど複雑な請求を持つ顧客事例で、抽象的な機能を運用課題に接続する。

第三にUIだけでなくREST API、SDK、webhook、MCPを揃え、導入後の拡張面を広げている。出典

課金は金額・税務・回収に直結するため、OSSを置くだけでは運用責任が消えない。

公開pricingはPremiumがcustom中心で、導入前の総コストを比較しにくい。

また、多機能なmeteringとentitlementは単純なsubscriptionだけを求めるチームには過剰になり得る。

公開情報だけではARRや顧客数は要確認。

Lagoはopen-sourceを入口にし、GitHubと技術コンテンツでengineeringへ届き、Premium deployment・support・高度な機能へ拡張するopen-core型を取る。

Mistral AI、PayPal、Groqなどのcustomer storyは、単なるOSSではなく本番billingを支える証拠として働く。

無料でコードを試せる代わりに、security・運用・アップグレードの不安を有償支援で回収する設計だ。出典

主要チャネル: open-source community, developer content, customer stories, GitHub

課金を決済画面の後工程ではなく、product usageからrevenueまでのデータ基盤として扱うと、pricing変更をプロダクト戦略と接続できる。

Lagoの例は、OSSを配ること自体ではなく、複雑な運用境界を再利用可能なモデルへ翻訳することが差別化になると示す。

日本では従量課金に加えて請求書払い、代理店、インボイス制度、複数税率などの業務要件が重なる。

Lagoを導入するなら、OSSの柔軟性だけでなく国内決済・会計との接続、監査ログ、データ保管地域を先に検証するべきだ。