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

Lagoの創業者はAnh-Tho ChuongとRaffi Sarkissianだ。

公式AboutページはAnh-Tho ChuongをCEO & co-founder、Raffi SarkissianをCPO & co-founderとして紹介している。出典

請求を機能ではなく基盤として捉える

Lagoは、subscriptionの画面を作るだけでなく、顧客の利用イベントを受け取ってinvoiceへつなぐbilling infrastructureとして始まった。

event、subscription、invoiceを別のAPIオブジェクトにすることで、seat・usage・hybridの価格モデルを同じ流れに載せられる。出典

OSSを入口にする

課金基盤は一度選ぶと移行が重い。

だからこそ、LagoはGitHubで実装を読める入口を用意し、cloudとself-hostedの両方を提示した。出典

複雑さが成長の条件になる

従量課金を採用する企業が増えるほど、請求ロジックはプロダクト本体から切り離したくなる。

しかし、決済や税務まで含めると運用の難度も上がる。

Lagoの挑戦は、価格実験の自由度とbillingの信頼性を同時に成立させることだ。

今の立ち位置

Lagoは、OSSの試しやすさを保ちながら、usage-based billingの導入を支える基盤へ広がろうとしている。

日本企業が参考にするなら、APIの抽象化と地域固有の請求実務を分けて考えるのがポイントだ。

LagoのPMFは、subscriptionだけでなく従量課金・ハイブリッド課金を実装したいsoftware teamにある。

イベント、subscription、invoiceをAPIで分離し、課金ロジックをアプリから切り出せる。出典

OSS版を試せるため、既存billing providerの制約を嫌う開発者が導入判断をしやすい。

顧客事例でも複雑なmonetizationを扱う用途が示される。出典

独自の障壁は、events・subscriptions・invoicesを横断するbilling domain modelと、OSSで蓄積される実装知見の組み合わせだ。

単なるcheckout APIより、価格モデルの変更を吸収する設計資産が効く。出典

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

利用者が増えても同じ顧客の請求精度が直接上がるわけではない。

ただしGitHubで開発者・connector・事例が増える間接効果はある。出典

対象は、API SaaS、AI、marketplaceなど、seat課金だけでは価値を表現できないsoftware companyのproduct・engineering team。

単純な月額subscriptionだけの小規模事業者には過剰になりやすい。

第一に、usage-based billingのデータモデルをevent中心に固定したこと。出典

第二に、open-sourceとcloudを併記し、開発者の評価コストを下げたこと。出典

Billingは決済・税務・会計との接続が必要で、APIがあっても導入設計は軽くない。

公式pricingでもenterpriseは個別設計で、公開情報だけでは総保有コストを比較できない。出典

また、OSSのself-hostingでは運用責任が顧客側に残るため、規模拡大時のサポート品質とデータ移行が要確認だ。

入口はOSS repositoryとdocs、出口はcloud・enterpriseの運用支援というproduct-ledな構造だ。出典

usage-based pricingが増えるほど、billingの複雑さが顧客獲得の理由になる。

一方で、決済・税務の地域差に対応するほどプロダクトの範囲は広がるため、APIの中核と周辺連携を分ける必要がある。

主要チャネル: content, github, community, productLedGrowth

インフラ型SaaSでは、顧客が避けたい複雑さをAPIのdomain modelへ移すことがPMFになる。

Lagoは請求画面を先に売るのではなく、課金イベントを正規化することで価格実験の余地を作っている。出典

日本では、SaaSの従量課金だけでなく、請求書・インボイス制度・販売管理との接続が導入障壁になる。

Lago型を展開するなら、billing APIの翻訳だけでなく、日本の税区分・請求書ワークフロー・会計ソフト連携を最初から設計対象にすべきだ。

これは市場適合の仮説であり要検証。