Anthropicが請求システムの内製化を検討する理由
外部決済サービスを利用しながら請求機能の内製も検討するAnthropic。価格戦略や利用量計算をどこまで自社でコントロールすべきかを考察します。
ビジネスStripeを使いながら請求システムの内製も検討するAnthropic
Stripeの導入事例には、Anthropicが決済や請求、財務レポートに同社の製品を活用してきたプロセスが紹介されています。初期にはプロダクト開発に集中するために外部インフラを利用し、取引が増加するにつれて売上データをBigQueryへ連携する手法も改善したといいます。Stripeの導入事例
一方で、Anthropicのビリング（請求）プラットフォーム担当の採用情報には、外部サービスに任せる部分と自社で開発する部分を判断するという職務内容が記されています。決済代行業者を利用しつつも、自社の請求システムにエンジニアを投入しているのです。
私は以前の本レターで、StripeによるOpenRouterの買収合意について取り上げました。StripeがAIモデルの利用量やコストを管理する領域へと事業を拡大している一方で、大口顧客であるAnthropicもその一部を自社で直接管理しようとしています。この二つの動きがどこで交差しているのか、注目してみる価値があります。
請求システムはカード決済よりも守備範囲が広い
Anthropicのスタッフエンジニアの採用情報では、料金設定、決済フロー、契約と利用権限、売上データなどが主な職務として提示されています。外部の請求・決済・税務プラットフォームを幅広く活用しており、これらを拡張するのか、それとも自社機能を開発するのかを判断すると記されています。ビリングプラットフォームの採用情報
公募内容には、決済承認率、再試行、処理コスト、チャージバック（紛争）対応や不正防止も含まれています。請求計算だけを内製する、あるいはカード決済処理は検討の対象外である、と単純に割り切ることはできません。かといって、外部事業者をすべてリプレイスするという発表でもありません。どこまでを外部に委託し、どこを自社でコントロールするのかを判断できる人材を募集しているのです。
カードから代金を回収することと、顧客が支払うべき金額を計算することは、連動してはいるものの本質的に異なります。例えばAI APIの請求書を作成するには、次のような事項を定義しなければなりません。どの利用実績を課金対象に含めるのか、入力と出力の単価をどう適用するのか、割引や前払いクレジットをどの順序で差し引くのか、といった点です。
利用量を計測する機能はメータリングと呼ばれます。これを料金プランや契約条件に照らし合わせて金額として算出し、請求する機能がビリングです。同じ呼び出しであっても、キャッシュの利用、バッチ処理、顧客ごとの割引条件によって請求金額が変わる場合があります。
何に対していくらを請求するのかは、サービスを提供する企業自身が決めるべきことです。その計算ロジックを必ずすべて自前で実装しなければならない、という意味ではありません。外部プロダクトが必要な条件をサポートしているなら、それを活用すれば十分です。ただし、料金体系を変更したいときに、どの部分を自力で変更できるのかは把握しておく必要があります。
不正対策も決済と利用量を連動して見る必要がある
Anthropicの金融不正対策（Fraud）エンジニアの募集では、決済承認時点でのリスク評価に加え、返金や紛争への対応、体験・プロモーションの悪用検知が扱われています。決済代行業者と連携しつつ、デバイス情報、短時間での反復取引、アカウント間の相関関係など、多様なシグナルを活用する業務です。金融不正対策エンジニアの採用情報
AIサービスでは、決済が完了していなくてもコンピュートコストが発生し得ます。例えば、無料クレジットを受け取るためにアカウントの作成を繰り返し、APIを大量に呼び出された場合、サービス提供企業がその利用コストを負担することになります。これは起こり得る不正利用のシナリオであって、この採用情報で実際の被害規模が公表されたわけではありません。
こうした課題に向き合うには、カード決済情報とサービスの利用実態データを結びつける必要があります。盗難カードの検知が軽視されているわけでも、無料特典の悪用がAI特有の問題というわけでもありません。どこでコストや損失が生じているかに応じて、監視すべきシグナルを補強していく作業なのです。
外部の決済代行業者も不正検知機能を提供しています。Stripeの導入事例では、AnthropicがRadarのリスクスコアと自社の独自ルールを活用し、正常な取引の誤検知による遮断を減らしたと説明されています。自社で運用する機能と外部機能を併用している事例と言えます。
決済の失敗についても、理由を分類して処理する必要があります。一時的なエラーなのか、カード情報自体の問題なのか、それとも実際の不正利用の疑いなのかによって対応は異なります。複数の決済ルートを用意することが有効な場面もありますが、事業者が1社だからといって再試行が不可能なわけではありません。別のルートへ無差別にリクエストを繰り返したところで、承認率が上がるとも限りません。再試行の条件設計と、二重決済を防ぐ処理をセットで実装する必要があります。
決済代行業者を切り替えられるかも確認が必要
Adyenは2026年8月の上半期決算発表において、OpenAIを新規に獲得した主要エンタープライズ顧客の1社として紹介しました。ただし、この発表内容だけからでは、OpenAIが従来の決済事業者のどの機能を置き換えたのかまでは分かりません。Adyen上半期決算発表
企業が決済代行業者を追加したり乗り換えたりしようとする場合、カード情報や既存のサブスクリプション契約をどう移行するのかを検討しなければなりません。保管場所が極めて重要になる理由がここにあります。外部の保管サービスを活用すれば複数決済代行業者の接続には役立ちますが、それだけでいつでも簡単に切り替えられるわけではありません。
逆に、カード情報が特定の決済代行業者に預けられているからといって、必ずしも顧客に再登録を求めなければならないわけでもありません。Stripeは、一定のセキュリティ要件を満たした新たな決済代行業者に対してカード情報を安全に移行する手続きを提供しています。ただし、Linkに保存された決済資格情報はエクスポートの対象外です。また、カード情報と決済履歴・サブスクリプションデータとでは移行の手法も異なります。Stripeデータ移行ガイド
私なら、手数料の交渉に臨む前に、移行可能なデータ、サポートされている決済手段、そして移行に要する時間や開発工数を確認します。現実的な代替案へと実際に移行できる状態にあって初めて、交渉でも選択肢が生まれるからです。
Stripeの事業拡大領域と顧客の内製化が交差する
Stripeは2026年1月14日、従量課金ビリングプラットフォームのMetronomeの買収を完了しました。さらに8月19日には、複数のAIモデルの中からリクエストの送信先を選択し、利用コストを管理するOpenRouterの買収合意を発表しました。買収完了と買収合意は段階が異なります。Metronome買収完了の発表、OpenRouter買収合意の発表
Stripeの関心は、顧客から決済を受け取る瞬間だけでなく、その手前で発生するAIの利用量とコストの領域へと広がっています。これは、Anthropicが募集している請求・価格設定・売上管理システムの職務と一部重複する領域です。
ここで、どの機能は絶対に外部から購入し、どの機能は絶対に自社開発すべきだ、と一概に二分するのは困難です。同じメータリングであっても、顧客数、契約の複雑さ、社内の開発リソース、外部プロダクトの対応範囲などによって最適な選択は変わってきます。
| 機能 | 外部サービス検討時の着眼点 | 自社開発検討時の着眼点 |
|---|---|---|
| 決済処理 | 対応国・決済手段・手数料・承認パフォーマンス | 複数ルートを接続・運用できる組織力 |
| 利用量集計 | スループット・正確性・遅延・元データへのアクセス性 | 自社固有の集計ルール |
| 料金・契約管理 | 割引・前払い・従量課金条件のサポート範囲 | 価格実験および顧客別例外処理の頻度 |
| 利用権限 | 契約変更と実際のサービス利用権限の連動 | リアルタイムな上限設定と利用停止条件 |
| 不正防止 | 外部決済ネットワークから得られる情報 | プロダクトの利用ログとアカウント間の相関関係 |
顧客企業が一部の機能を自社開発したとしても、外部の決済・請求サービスを継続して利用することは可能です。採用情報と既存の導入事例が同時に存在していること自体、何ら矛盾ではありません。外部サービスに委託するスコープが変化していく可能性を示しているに過ぎないのです。
手数料を削減すれば済む話ではない
売上や取引規模が拡大すると、わずかな料率の差であっても莫大なコストになります。そのため、外部サービスの費用を見直すのは自然な流れです。ただし、年換算の売上に任意の料率を掛け合わせただけの数字は、実際に支払った費用ではありません。決済手段、契約ごとのディスカウント、利用する機能プロダクトが異なれば、実効コストも変わってきます。
自社開発には、また別のコストがかかります。エンジニアの採用や運用の負担、税務・会計システムとの連携、エラー修正や顧客サポートが必要になります。過誤請求が発生した際の返金コストや信頼の毀損も考慮しなければなりません。
請求システムは、一度正確に作れば終わりというものではありません。料金プラン変更の前後を厳密に区別し、過去の契約条件を維持し、二重集計を防ぎ、顧客からの問い合わせに対して明細の根拠を提示できなければなりません。Anthropicの採用情報が整合性の検証や監査証跡、運用上の責任を強調しているのも、まさにこうした業務に直結しているからです。
IPO準備や手数料削減という一面的な理由だけで、自社開発検討の背景を説明することは困難です。公募内容から窺える要求事項は、プロダクトリリースのスピード、契約処理、決済パフォーマンス、そして売上データの正確性にまで及んでいます。
Oswarldの視点
私はこのニュースを見ながら、ソフトウェア企業が何を外部から調達し、何を自前で作るべきかを判断する基準について改めて考えさせられました。とりわけ、顧客にいくら請求するかを決定するロジックはプロダクトそのものの一部であると私は考えています。
毎月固定額を請求する料金体系と、利用量・割引・上限が顧客ごとに異なる料金体系とでは、求められる計算ロジックが根本から異なります。外部プロダクトに料金設定を委託するとしても、その設定が自社の顧客にどのような請求結果をもたらすのかは、自社で説明できなければなりません。
利用量が急増し、契約形態が複雑化すると、外部製品がサポートしていない条件がたった一つあるだけで価格戦略の実験が頓挫することがあります。私は、まさにその点にこそ自社開発を検討する真の理由が潜んでいると考えています。外部プロダクトを利用するコストだけでなく、望む料金プランをタイムリーに市場へ投入できない機会損失のコストも天秤にかける必要があるのです。
韓国のSaaSやAIサービスにおいても、決済代行会社に決済処理を委託しつつ、自社のデータベースで利用量を集計しているアーキテクチャをよく目にします。それ自体が決して劣った設計というわけではありません。重要なのは、集計が極めて正確であるか、そして料金体系が改定されても過去の請求根拠を完全に再現できるかどうかです。
AIエージェントが自律的にタスクを反復するようになれば、単一ユーザーの消費量が極めて短時間で跳ね上がる可能性があります。だからこそ、何をカウントするのかだけでなく、いつ上限を適用し、どのような条件でサービスを停止するのかも、価格戦略と足並みを揃えて策定しなければなりません。
顧客から請求金額に対して異議申し立てがあった際、単にAPI呼び出しログを並べるだけでは十分な説明にならないことがあります。どのタスクに対してどのような料金ルールを適用し、割引やクレジットをどのように算定したのかを提示できなければなりません。この算定根拠を自社のコードで生成するにせよ、外部システムから受け取るにせよ、自社自身がそれを検証し、納得感を持って説明できる体制が不可欠だと私は考えます。
読者さんが従量課金やクレジット制の料金プランを運用されているなら、特定の顧客1社の請求書を、元の利用ログからゼロベースで再計算できるかどうか確認してみてください。その検証プロセスを通じて、外部に任せてもよい領域と、自社でコントロールすべき領域が、より鮮明に見えてくるはずです。
💬 現在のサービスにおける利用量と請求金額は、どこで計算されていますか？ 料金プランを変更しようとしてシステムの制約に直面した経験があれば、ぜひ教えてください。
参考資料と関連リンク
- Anthropicのビリングプラットフォーム担当スタッフエンジニア採用情報。
- Anthropicの金融不正対策担当エンジニア採用情報。
- StripeのAnthropic導入事例。
- StripeによるMetronome買収完了の発表、2026年1月14日。
- StripeによるOpenRouter買収合意の発表、2026年8月19日。
- Stripeの決済データ移行ガイド。
関連する過去記事
