ログイン機能の実装サービスとして人気のClerkに、この数か月で大きな機能強化が続いています。私たちも自社サービス「レポアン」の認証にClerkを採用しており、変化を実務目線で追ってきました。この記事では、最近のアップデートの要点と、課金基盤としてStripeやRevenueCatとどう使い分けるかを整理します。
この数か月で何が変わったか
公式チェンジログから、実務に効く4つを取り上げます。
1. シート課金に対応（2026年6月10日）
Clerk Billingで、組織のメンバー数に応じた従量課金（シート課金）が作れるようになりました。基本料金と込みシート数、シート単価、シート上限の組み合わせが可能です。たとえば「基本料金月20ドル・2シートまで込み・追加1シート8ドル・上限10シート」という設計を、課金コードを書かずに設定できる仕組みです。組織にメンバーが増えると、Clerkが席の追加購入フローまで自動で案内し、期の途中の追加は日割り計算されます。
2. アカウントクレジットに対応（2026年6月30日）
顧客のサブスクリプション設定を変えずに、請求額だけを調整できる仕組みです。障害のお詫びクレジット、初期顧客への優待、請求トラブルの解消などが、ダッシュボードとAPIの両方から操作できます。調整履歴は台帳に残るため、後から「なぜこの顧客の請求額が違うのか」を追えます。地味に見えますが、サブスク運営で必ず発生する例外処理が標準機能になったのは大きい変化です。
3. CLI 2.0でWebhookのローカルテストとユーザーなりすましデバッグ（2026年7月9日）
ターミナルから clerk webhooks listen でWebhookをローカルに転送し、clerk impersonate で特定ユーザーとしてログインして不具合を再現できるようになりました。注目すべきは、公式が「開発者とエージェントの両方が使える単一のツール」を明言している点です。安定したエラーコード、データはstdout・表示はstderrという出し分け、非対話環境で隠れたプロンプトを出さない設計など、AIエージェントに操作させる前提の作法がCLI全体に貫かれています。AIにコードを書かせる開発では、こうしたCLIの行儀の良さがそのまま開発速度に効きます。
4. モバイルのホスト型認証（2026年7月28日）
Expo・iOS・Androidの各SDKから、メソッド1つでブラウザ経由のホスト型認証ページに遷移できるようになりました。メール認証やパスワードからソーシャルログイン、SSO、多要素認証までカバーされるため、ネイティブUIを作る必要がありません。モバイルアプリの認証実装が大幅に軽くなる変更です。
課金をClerkに一元化する判断
これまでの一般的な構成は「認証はClerk、課金はStripeを直接実装」でした。Clerk Billingは以前はベータ段階で本番採用しづらい状態でしたが、シート課金とクレジットが揃ったことで、Webサービスのサブスク課金なら一元管理を検討できる段階に入ったと見ています。
一元化の利点は、ユーザー・組織・プラン・課金状態が1つの管理画面とAPIで完結することです。「この組織はどのプランで、誰が何席使っているか」を、認証情報と課金情報を突き合わせるコードを書かずに参照できます。
手数料は、Clerk Billingが決済額の0.7%、これにStripeの決済手数料（米国カードで2.9%と30セント）が加わります（公式料金ページ・2026年8月3日確認）。なお料金ページには「従量・シート課金は近日対応」と旧い表記が残っていますが、チェンジログのとおりシート課金は既に提供されています。
Stripe・RevenueCatとの使い分け
| 観点 | Clerk Billing | Stripe Billing直接実装 | RevenueCat |
|---|---|---|---|
| 主戦場 | Webサービスのサブスク（認証・組織と一体） | あらゆる課金モデル（従量・請求書・複数フェーズ） | モバイルアプリ内課金（App Store・Google Play） |
| 強み | 認証・組織・課金の一元管理。課金UIほぼ不要 | 自由度と機能の広さ。日本の決済手段対応 | ストア課金の差異吸収。ペイウォールABテスト |
| 手数料の目安（確認日2026-08-03） | 決済額の0.7%＋Stripe手数料 | 日本はカード決済成功ごとに3.6%（Billing機能込みの表記） | 追跡収益（MTR）連動。Growth Toolsのみの利用は追跡分の1%。無料枠と段階は公式ページで要確認 |
| 向くケース | B2B SaaSでシート課金・組織課金をすぐ出したい | 複雑な従量課金・請求書払い・既存Stripe資産がある | iOS/Androidアプリのサブスクが主戦場 |
判断の物差しはシンプルです。Webのサブスクで、課金の単位がユーザーや組織と一致しているならClerk一元化が有力。請求書払いへの対応や複雑な従量制など課金そのものが複雑ならStripe直接実装。モバイルアプリ内課金が主戦場ならRevenueCat。どれも併用は可能なので、認証だけClerkで課金は別、という現行構成から段階的に寄せる道もあります。
私たちの判断: レポアンは当面Stripe直のまま
自社サービスのレポアンでは、認証にClerkを使い、課金はStripeを直接実装しています。今回の強化を受けて一元化を検討しましたが、結論は「当面Stripeのまま」でした。
理由は移行の対価です。Clerk Billingの0.7%で買えるのは、課金UIやプラン管理を自作しない開発時間に相当します。しかし、すでに動いている課金では、その開発時間は支払い済みです。動いているものを移す作業自体が新たなコストになるので、新規開発とは損益分岐がまったく違います。
ただし固定の判断ではありません。プラン体系を作り替えるタイミング、特にシート課金や組織課金を入れる時が来たら、そこはClerk Billingの主戦場なので再検討します。乗り換えは「今の構成に不満があるか」ではなく、「次に課金を作り直すのはいつか」で考えるのが実感に合っています。
CLIの使い心地で比べる
もう1つ、実務者として無視できないのが開発体験、特にCLIです。
Stripe CLIは成熟しています。stripe listen でWebhookをローカル環境へ転送し、stripe trigger で決済成功や支払い失敗などのテストイベントも起こせる仕組みです。テストクロックを使えば「3か月後に更新が走ったら」のような時間経過も再現できます。課金開発でいちばん面倒な「本番相当の挙動をローカルで試す」がCLIで完結するのは、長年の蓄積の強さです。
Clerk CLIは2.0（2026年7月）で方向性が独特です。人が叩く道具としての機能に加えて、AIエージェントに操作させる前提の設計（機械可読な出力・破壊的操作の前の確認ステップ）が明示されています。人間向けの成熟度と周辺情報の量ではStripe CLIに分がありますが、コーディングエージェントに設定作業を任せる運用を想定するなら、先を行っているのはClerkです。
RevenueCatは管理の中心がダッシュボードとSDKで、CLI起点の開発体験は前の2つほど前面に出ていません。モバイル課金の検証はストア側のサンドボックスに依存する部分が大きく、そもそもCLIだけで完結しにくい領域でもあります。
一元化する前に確認しておきたいこと
良いことばかりではないので、乗り換えを検討する際の注意点も挙げておきます。
第一にロックインです。認証と課金を同じサービスに寄せるほど、将来別のサービスへ移る費用は大きくなります。顧客データと課金履歴のエクスポート手段を契約前に確認しておくことをおすすめします。第二に障害時の影響範囲です。認証だけなら「ログインできない」で済みますが、一元化するとログインと決済が同時に止まります。稼働率の保証条件はプランによって異なるため、事業の性質に応じた確認が要ります。第三に日本特有の決済手段です。コンビニ払いや銀行振込のような日本の商習慣に合わせた決済は、Stripeを直接実装するほうが選択肢が広いのが現状です。Clerk Billingの決済処理はStripeの上に載っているため、対応範囲はそのサブセットになります。
また、手数料は二重に見る必要があります。Clerk Billingの0.7%はStripe手数料への上乗せです。この上乗せで何を買っているかというと、課金UI・プラン管理・シート管理・クレジット台帳を自作せずに済む開発時間です。月商規模が大きくなるほど0.7%が生む支払い額も増えるので、「開発時間を買う」対価として釣り合うかを定期的に見直すのが健全だと考えています。
AI開発との相性という観点
私たちがClerkを評価しているもう1つの理由は、AIと一緒に開発する前提が製品設計に入っていることです。CLIのエージェント対応はその代表で、認証や課金のような「間違えられない領域」こそ、AIに任せたときの挙動が予測できる道具を選ぶ価値があります。ツール選定の基準に「AIに操作させたときに安全か・確認可能か」を加えることを、私たちは研修や導入支援でもお伝えしています。
まとめ
- Clerkはこの数か月でシート課金・クレジット・CLI 2.0・モバイルホスト型認証と、実務直結の強化が続いた
- Webサブスクの課金は「認証はClerk、課金はStripe直」の定番構成から、Clerk一元管理を検討できる段階に入った
- 使い分けは、Web×組織課金ならClerk、複雑な課金ならStripe直、モバイルIAPならRevenueCat
- すでに動いている課金を移す理由は薄い。再検討するのは「次に課金を作り直す」タイミング（レポアンもStripe直を継続中）
- CLIの使い心地は、人が叩くならStripeの成熟、AIエージェントに任せる前提ならClerk 2.0の設計が光る
KOIYALでは、認証・課金まわりを含む自社サービス開発の伴走支援と、AIを使った開発の企業研修を行っています。ツール選定のご相談もお問い合わせページからどうぞ。