多くのAIスタートアップは、自分たちがAIプロダクトを作っているつもりです。
最初は、本当にそう感じます。
モデルを出荷します。
Stripeを追加します。
月額サブスクリプションを作ります。
おそらく、シンプルなクレジットのテーブルも追加します。
Webhookハンドラを作ります。
完了です。
すべてが管理できそうに思えます。
でも、利用が増え始めると——。
そして、次のような面白いことが起きます：
あなたのAIプロダクトが、ゆっくりと請求（ビリング）インフラ企業に変わっていきます。
初期の錯覚
ほとんどのAIプロダクトの最初のバージョンでは、収益化が見かけ以上に単純に見えます。
よくある構成：
- Stripe Checkout
- 月額プラン
- クレジットをデータベースに保存
- Webhookエンドポイントが1つ
- 基本的なアクセスチェック
最初のユーザーには、たいていこれはうまくいきます。
しかし、AIプロダクトは本質的に利用（usage）駆動のシステムです。
そして、利用駆動のシステムは、すぐに状態同期（state synchronization）の問題になっていきます。
何が実際に壊れ始めるのか
最初の問題は、通常は支払いではありません。
支払いはたいてい簡単な方です。
本当の問題は、支払いが成功した後から始まります。
例えば：
- 支払いは成功したが、クレジットが一度も追加されない
- 重複するWebhookイベントが、重複した利用割り当てを作る
- リトライがクレジットを2回消費する
- サブスクリプションの状態が古くなる
- 期限切れのサブスクリプションでもアクセスが有効のままになる
- 解約されたサブスクリプションでもリソース消費が続く
- 利用カウンタが現実からずれていく
- 非同期イベントが順不同で到着する
- アクセスチェックが古い状態に依存する
小規模では、これらの問題はランダムに見えます。
しかし大規模になると、運用上の問題になります。
AIプロダクトは本質的に非同期
ここで多くのチームが複雑さを過小評価します。
従来のSaaSプロダクトは、比較的安定したサブスクリプション状態を中心に回ることが多いです。
でもAIプロダクトは違います。
AIの収益化には、多くの場合次が含まれます：
- 利用パック
- 前払いクレジット
- 従量課金（メータリング）
- 利用制限付きサブスクリプション
- チャージ（トップアップ）
- 上限超過分（オーバージ）
- 機能ベースのアクセス
- API利用
- リアルタイムの消費
これを次と組み合わせると：
- 非同期Webhook
- リトライ
- ネットワーク障害
- 遅延イベント
- 同時リクエスト
- 最終的整合性（eventual consistency）
そして、いつの間にか「シンプルな請求システム」が分散状態管理になってしまいます。
Stripeはアクセスの唯一の真実（source of truth）ではない
これはチームが犯す最大級の概念的な間違いの一つです。
Stripeは支払い処理に非常に優れています。
しかし、支払いの成功だけではアクセスの真実にはなりません。
成功した支払いが、自動的に次を意味するわけではありません：
- クレジットが同期されていること
- エンタイトルメントが有効になっていること
- 利用状態が正しいこと
- アクセスを付与すべきであること
- 後からリトライが起きないこと
- 以前の失敗が照合（リコンシリエーション）されていること
いずれ、真剣に取り組むすべてのAIプロダクトが作り始めます：
- エンタイトルメント（権利付与）システム
- 利用台帳（usage ledgers）
- 照合のフロー
- Webhookリトライの取り扱い
- 冪等性（idempotency）レイヤ
- アクセスのバリデーション
- 請求状態の同期
望んでそうするからではありません。
結局そうしなければならないからです。
隠れたインフラ企業への変貌
ここは、最初の段階では誰も十分な早さで語りません。
多くのAIスタートアップは、収益化がプロダクトの機能だと信じています。
しかし最終的には、それが運用上のインフラだと気づきます。
エンジニアリングの課題は、だんだんと次から——。
「どうやってユーザーから課金するの？」
次のように変わっていきます：
「非同期の失敗が起きる状況で、どうやって請求状態の整合性を保証するの？」
これはまったく別の問題です。
そして、実際のお金、APIの利用、顧客の信頼が関わってくると、致命的に重要になります。
生き残るチームは通常、このレイヤを標準化する
十分なインシデントを経ると、ほとんどのチームは集約（centralizing）を始めます：
- 請求状態
- アクセスロジック
- 利用トラッキング
- Webhook処理
- リトライ
- エンタイトルメントの解決
このロジックをランダムなハンドラに分散させると、いずれ安全に保守するのが不可能になります。
特に、利用が継続的で非常に動的なAIプロダクトではなおさらです。
最後に
面白いのは、多くのAI創業者が、自分たちが請求インフラを作っていることに気づくのは、すでに深く入り込んだ後だという点です。
たいていは次から始まります：
「とりあえずクレジットを追加しよう。」
そして次のように変わります：
「なんでまたサブスクリプション、利用、アクセスが同期してないの？」
このパターンを何度も見た後、私は請求状態、利用の同期、エンタイトルメント、そしてStripeのライフサイクル処理のための社内インフラを作り始めました。
それが最終的に Licenzy になりました。
元の目的が請求インフラを作ることだったわけではありません。
ですが、どのAIプロダクトも最終的には必ずそれが必要になります。
