Lemon Squeezy（レモンスクイーズィー）は、ソフトウェアやデジタル商品の販売で、販売者に代わって自社が売主になり、各国の消費税・VAT・売上税の計算と納付まで引き受けるMerchant of Record（MoR）型の決済サービスです。この記事では、MoRの仕組みとStripeを直接使う場合との責任範囲の違い、チェックアウト作成とWebhook署名検証のコード、日本拠点の販売者が実際に負担する手数料の内訳を整理します。後半では、2024年のStripe買収と2026年1月の公式アップデートを踏まえ、新規導入でLemon Squeezyを選ぶかStripe Managed Paymentsを選ぶかの判断基準を示します。
まとめ：税務を外に出したい小規模SaaS向け、新規導入はStripe側も並べて比較
Lemon Squeezyの価値は、海外の個人や企業へソフトウェアを売るときに発生する各国の間接税の登録・申告・納付を、5%＋50¢の手数料と引き換えに丸ごと手放せる点にあります。経理と法務の人員を持たない数人のSaaSや、海外向けのデスクトップアプリ・テンプレート販売では、この肩代わりの価値が手数料の差を上回ります。
一方で、2026年1月28日の公式ブログでCEOが、開発の軸足をStripe Managed Paymentsへ移したことと、サポート応答や機能更新が遅れていることを認めました。サービス終了は告知されていませんが、これから組み込むならStripe Managed Paymentsを同じ土俵で比べてから決めるのが安全です。既にLemon Squeezyで売上が立っているストアは、移行ツールの提供を待ってから動いても遅くありません。
Lemon Squeezyの仕組み：MoRとして売主の立場と各国の税務を肩代わりする構造
Lemon Squeezyは2024年7月にStripeが買収した決済サービスで、ストアの作成、商品とサブスクリプションの管理、チェックアウト画面、ライセンスキー発行、アフィリエイトまでを1つの管理画面で扱います。他の決済サービスと分ける軸は、取引の法的な売主が誰になるかです。
MoRとは何か：購入者の請求書に販売者でなく決済事業者が売主として載る形
Merchant of Recordは、購入者との取引で法的な売主となる立場を引き受ける事業者のことです。Lemon Squeezy経由で売ると、購入者のカード明細と請求書に載るのはLemon Squeezy側で、販売者はLemon Squeezyへ商品を卸している立場になります。公式の料金ページは、VAT・売上税の徴収と申告・納付、不正検知、カゴ落ちと決済失敗の回収を、すべて追加料金なしの標準機能として並べています。
売主が変わるため、返金やチャージバックの窓口もLemon Squeezy側に移ります。公式サイト下部の表記が「Sold through Link, LLC f/k/a Lemon Squeezy LLC」に変わっており、2026年10月時点の契約主体はStripe系列のLink, LLCです。
Stripeを直接使う場合との違い：税務登録と申告の責任がどちらにあるか
Stripeを直接契約すると、売主は販売者自身です。Stripeの仕組みと手数料で整理しているとおり、Stripe Taxは税額の計算と徴収を手伝いますが、EUのOSSやイギリスのVAT、米国各州の売上税への登録と申告は販売者が行います。
| 責任の所在 | Lemon Squeezy（MoR） | Stripe直接契約 |
|---|---|---|
| 法的な売主 | Lemon Squeezy（Link, LLC） | 販売者 |
| 海外の間接税の登録・申告 | Lemon Squeezyが実施 | 販売者が実施 |
| チャージバック対応 | Lemon Squeezyが窓口 | 販売者がダッシュボードで対応 |
| 決済画面の自由度 | ホスト型とオーバーレイ中心 | Elementsで自作も可能 |
海外で税務登録を持たない日本の会社にとって、差が出るのは2行目です。販売国が増えるほど、申告の手間はMoR側に寄せたほうが軽くなります。
Stripe買収後の2026年方針：Managed Paymentsへ軸足を移す経緯
2025年4月29日の公式ブログは、Stripe内部にMoR機能を組み込むStripe Managed Paymentsを発表し、Lemon Squeezyの利用者には「変更も対応も不要」と説明しました。その9か月後の2026年1月28日の公式アップデートでは、Lemon Squeezyの利用者がStripe Managed Paymentsへ簡単に移れる道を用意することを目標に掲げています。
同じ投稿で、サポート応答の遅れと製品更新の減少も認めました。npmの公式SDK「@lemonsqueezy/lemonsqueezy.js」の最新版は2024年11月5日公開の4.0.0のままで、2026年10月時点で約2年更新がありません。
Lemon Squeezyの始め方：テストモードでストアと商品・バリアントを作る手順
アカウントを作ると、最初のストアはテストモードで開きます。審査を待たずに商品作成から購入、Webhook受信まで通しで試せるため、実装はここから始めます。
テストモードと本番モードの違い：APIキーが別で、販売前にストア有効化が必要
Test Modeのドキュメントによると、テストモードで発行したAPIキーはテスト用のデータしか読み書きできません。本番では本番モードで作ったキーに差し替えます。テストカードはVisaの4242 4242 4242 4242のほか、残高不足や3Dセキュア用の番号が用意されています。
実際に売るにはストアの有効化が必要です。テストモードで作った商品は有効化しても自動では移らず、「Copy to Live Mode」で1件ずつコピーします。またAPIの認証仕様では、キーの有効期間は1年です。期限切れで本番のチェックアウト作成が止まらないよう、更新日を運用カレンダーに入れておきます。
商品とバリアントの設計：月額・年額やライセンス台数をバリアントで分ける
Lemon Squeezyでは、1つの商品（Product）の下に価格違いのバリアント（Variant）を並べます。月額プランと年額プラン、1台用と5台用のライセンスなどは、商品を分けずにバリアントで表現します。チェックアウトもWebhookもバリアントIDで識別するため、アプリ側のプラン定義とバリアントIDの対応表を最初に作っておくと、後の権限付与がぶれません。
ストアIDとバリアントIDはテストと本番で値が変わるため、環境変数で切り替えます。
Lemon Squeezy APIのチェックアウト作成：curl例と顧客IDの渡し方
curlのリクエスト例では、顧客IDを渡しながらチェックアウトを作成します。購入画面はLemon Squeezyがホストします。アプリ側の仕事は、誰が買うのかを紐づけたチェックアウトURLを発行し、そこへ利用者を送ることです。
POST /v1/checkoutsの実装例：商品指定と顧客のcustomデータ
Create a Checkoutのリファレンスに沿ったリクエストです。storeとvariantでストアと商品バリアントを指定し、customデータに顧客の識別子を渡します。JSON:API形式のため、AcceptとContent-Typeの両方にapplication/vnd.api+jsonを指定します。
curl -X POST https://api.lemonsqueezy.com/v1/checkouts \
-H "Accept: application/vnd.api+json" \
-H "Content-Type: application/vnd.api+json" \
-H "Authorization: Bearer $LEMONSQUEEZY_API_KEY" \
-d '{
"data": {
"type": "checkouts",
"attributes": {
"checkout_data": { "custom": { "user_id": "123" } },
"product_options": { "redirect_url": "https://example.com/thanks" },
"test_mode": true
},
"relationships": {
"store": { "data": { "type": "stores", "id": "STORE_ID" } },
"variant": { "data": { "type": "variants", "id": "VARIANT_ID" } }
}
}
}'レスポンスのdata.attributes.urlが購入画面のURLです。checkout_options.embedをtrueにするとオーバーレイ表示になり、自社サイトから離れずに決済できます。expires_atを省くと期限のないURLになるため、使い捨てにしたい場合は、有効期限として日時の指定が必要です。Node.jsでは公式SDKのlemonsqueezy.js、LaravelではLemon Squeezy for Laravelが同じ呼び出しを包んでいます。
URL方式の使い分け：checkout[custom]でユーザーIDを渡す場面
APIを呼ばずに、管理画面で作った購入リンクへクエリを足す方法もあります。Passing Custom Dataの形式は?checkout[custom][user_id]=123で、キーを増やせば複数の値を渡せます。
どちらの方式でも、渡した値は注文・サブスクリプション・ライセンスキーのWebhookでmeta.custom_dataに入って戻ってきます。ログイン済みの利用者に売るなら、ここに自社のユーザーIDを入れるのが基本形です。ドキュメントの例では数値で送った123がWebhookでは文字列になっているため、受け取り側は文字列として比較します。メールアドレスや氏名は載せず、必要最小限の識別子だけにします。
Lemon SqueezyのWebhook実装：署名検証とイベントによる権限同期
署名検証にはX-Signatureを使い、受信したイベントで権限を同期します。支払い完了や解約をアプリへ反映する経路はWebhookです。リダイレクト先の画面表示を購入完了の根拠にすると、タブを閉じた利用者の権限が付与されません。
X-Signatureの検証コード：生の本文でHMAC-SHA256を計算して照合
Signing Requestsによると、Lemon SqueezyはWebhook作成時に登録した署名シークレットで本文のHMACを計算し、16進数の値をX-Signatureヘッダーに入れて送ります。JSONとして解析する前の生の本文で計算する点が肝です。
import crypto from "node:crypto";
import express from "express";
const app = express();
const secret = process.env.LEMONSQUEEZY_WEBHOOK_SECRET;
app.post("/webhooks/lemonsqueezy", express.raw({ type: "*/*" }), (req, res) => {
const digest = Buffer.from(
crypto.createHmac("sha256", secret).update(req.body).digest("hex"), "utf8");
const signature = Buffer.from(req.get("X-Signature") || "", "utf8");
if (digest.length !== signature.length || !crypto.timingSafeEqual(digest, signature)) {
return res.status(401).send("invalid signature");
}
const payload = JSON.parse(req.body.toString("utf8"));
const event = payload.meta.event_name;
const userId = payload.meta.custom_data?.user_id;
// ここで event と userId をキューに積み、200 を先に返す
res.sendStatus(200);
});Expressでexpress.json()を全体に掛けていると、本文が解析済みのオブジェクトに置き換わり、署名が一致しなくなります。Webhookのパスだけexpress.raw()にするのはこのためです。長さが違うとtimingSafeEqualは例外を投げるので、先に長さを比べています。
購入確定とサブスク状態の更新：最低限受けるWebhookイベントと権限同期
Event Typesには17種類のイベントが並びます。権限同期ではorder_createdとsubscription_updatedを含む、次のイベントを受け取る設計です。全部を受ける必要はありません。
order_created：買い切り商品の購入確定。権限付与の起点subscription_createdとsubscription_updated：サブスクの開始と状態変化。解約予約や支払い遅延もupdatedで届くsubscription_payment_failedとsubscription_payment_recovered：更新失敗と回復。利用停止の猶予判定に使うorder_refunded：返金。権限の取り消しlicense_key_created：ライセンスキー付き商品の発行通知
サブスクの権限は、個々のイベントの種類ではなく、届いたペイロードのstatusをそのまま自社DBへ書き写す設計にすると、順序の入れ替わりに強くなります。更新失敗時の猶予期間や再請求の考え方はサブスクリプション課金の更新失敗対策と共通です。
ライセンスキーAPIでデスクトップアプリの利用権を確認する手順
ダウンロード型のソフトでは、購入時に発行されるライセンスキーをアプリ起動時に照会します。Validate a License KeyはストアのAPIキーを使わない別系統のエンドポイントで、フォーム形式で送ります。
curl -X POST https://api.lemonsqueezy.com/v1/licenses/validate \
-H "Accept: application/json" \
-d "license_key=LICENSE_KEY" \
-d "instance_id=INSTANCE_ID"応答のvalidが真偽値、license_key.activation_limitとactivation_usageが台数の上限と使用数です。端末ごとのinstance_idは、初回起動時にLicense APIの有効化エンドポイントで発行して端末に保存します。オフラインでも起動できるよう、照会結果を数日分キャッシュしておくと利用者の不満を避けられます。
Lemon Squeezyの手数料を日本の販売者目線で試算：5%＋50¢に足される上乗せ
料金ページの「5%＋50¢」は基本料率です。日本拠点で海外へ売る場合、Feesのドキュメントにある上乗せのいくつかが必ず乗ります。
上乗せ料率の一覧：海外取引・PayPal・サブスク・海外口座への出金
| 項目 | 料率（2026年10月時点） | 日本の販売者への影響 |
|---|---|---|
| 基本料率 | 注文総額の5%＋50¢ | 全取引 |
| 米国外の取引 | ＋1.5% | 米国以外の購入者 |
| PayPal払い | ＋1.5% | 購入者がPayPalを選んだ取引 |
| サブスクリプション | ＋0.5% | 継続課金の各回 |
| カゴ落ちメールで回収 | ＋5% | 回収できた決済のみ |
| アフィリエイト経由 | ＋3% | 紹介経由の売上 |
| 出金（Stripe・米国外の銀行） | 出金額の1% | 日本の銀行口座で受け取る場合 |
| 出金（PayPal・米国外） | 3%（上限30ドル） | PayPalで受け取る場合 |
日本は銀行出金の対応国に含まれます。ただし銀行出金は米ドル建てのため、円への換算は受取銀行の為替レートと手数料に左右されます。
50ドルの月額プランを欧州の購入者にカード払いで売った場合の手取り試算
カード払いで、米国外の購入者に50ドルのサブスクを1回請求したと仮定します。料率は5%＋1.5%＋0.5%で計7%、金額にすると3.50ドルに固定の0.50ドルを足して4.00ドルです。売上に対して8%が引かれ、さらに日本の銀行へ出金する時点で残額の1%が差し引かれます。
手数料の計算で基準となる金額は、税抜きの商品価格ではなく税込みの注文総額です。VATが20%の国では購入者の支払額が60ドルになり、料率部分もその60ドルを基準に計算されます。価格表を税抜きで設計していると、想定より手取りが目減りします。月の売上が数十万円規模なら、この8〜9%は税務の外注費と見合うかどうかで判断する数字です。
Stripe Managed Payments移行判断：新規導入と既存ストアの違い
Stripe Managed PaymentsはStripeのアカウント上でMoRを有効にする製品で、Lemon Squeezyの後継の位置づけです。日本の販売者にとっての条件と、乗り換えるかどうかの線引きを整理します。
Managed Paymentsの条件：日本は対象、Connect・独自UIは非対応
Managed Paymentsの利用資格では、事業所在地のアジア太平洋枠にJP（日本）が含まれています。対象はソフトウェア、SaaS、電子書籍、オンライン講座などのデジタル商品で、コンサルティングや開発、テクニカルサポートといった人が介在するサービスは対象外です。
製品ページの比較表によると、使える決済画面はCheckoutとPayment Linksだけで、ElementsやConnectには対応しません。サブスクはStripe Billingの実装と同じ仕組みで作り、決済画面はStripe Checkoutの実装のセッション作成にmanaged_payments[enabled]=trueを足す形になります。設定手順のページでは、APIバージョン2025-03-31.basil以降と、商品ごとに対象の税コードを付けることが前提条件です。仕組みのページによれば、購入者の明細にはLINK.COM*で始まる表記が出て、Checkoutのカスタムドメインは使えません。
手数料の比較：Managed Paymentsは日本のカード料率3.6%に3.5%が加算
Stripeのサポートページは、Managed Paymentsの手数料を成功した取引ごとに3.5%とし、間接税を含む取引総額に掛かると説明しています。これは通常の決済手数料への上乗せです。日本の料金ページではカード決済が3.6%、Billingが0.7%、通貨換算が必要な場合は＋2%です。
日本のアカウントでサブスクを売ると、3.6%＋3.5%＋0.7%で7.8%、通貨換算が入ると9.8%になります。前章の試算のLemon Squeezy（50ドルで8%、出金時に1%）とほぼ同じ水準で、手数料だけで乗り換えを決める差はありません。差が出るのは機能面と、Stripeの他製品と同じダッシュボードで扱えるかどうかです。
既存ストアと新規導入で異なる判断：今すぐ移行する条件と提供を待つ条件
既にLemon Squeezyで継続課金の顧客を抱えているなら、公式の移行ツールが出るまで待つのが妥当です。カード情報はLemon Squeezy側に保管されており、自前で移すと顧客に再登録を頼むことになります。待つあいだに、顧客・注文・サブスクの一覧をAPIで定期的に書き出しておけば、移行時の照合が楽になります。
新規に組み込むなら、Stripe Managed Paymentsを第一候補に置きます。理由は、SDKの更新が止まっている製品に新しくコードを書くと、2〜3年後に同じ移行作業がもう一度発生するからです。例外は、ライセンスキー発行やアフィリエイトを標準機能で今すぐ使いたい場合で、Managed Paymentsの公式ドキュメントにはこの2機能の記載がありません。この場合だけはLemon Squeezyで始め、Stripe側の機能追加を見て移る計画を最初から立てておきます。
MoR型を選ばない場面：国内向けBtoBの請求書払いと物販・受託サービス
国内企業向けのSaaSで、請求書払いや口座振替が中心なら、MoRは選びません。売主が米国法人になると、日本の取引先が受け取る請求書の発行元も自社ではなくなり、経理部門に支払先の変更から説明し直すことになります。物販やコンサルティングのように人が介在する商品も、Stripe Managed Paymentsでは対象外です。
この場合は、国内の決済代行や決済システムの接続方式から選び直すことになります。スマートフォンアプリの課金をまとめたいならRevenueCatの仕組みが別の選択肢です。MoRと国内決済を併用する構成や、既存の会員基盤への組み込みを検討している場合は、決済・サブスクリプションシステム開発として要件整理から相談を受けています。
Lemon Squeezyの導入前によくある質問：日本での利用・税務・移行
Lemon Squeezyの検討でよく出る質問に、2026年10月時点の公式ドキュメントをもとに答えます。
Lemon Squeezyは日本の個人や法人でも使えますか？
使えます。公式の対応国一覧で、日本は銀行出金の対象国に入っています。販売者は銀行かPayPalで出金を受けられる国に所在していればよく、米国法人を作る必要はありません。銀行出金は米ドル建てで、日本の口座へ送る場合は出金額の1%が引かれます。本番で売るにはストアの有効化が必要なため、公開日から逆算して早めに申請してください。
Lemon Squeezyはサービス終了しますか？
2026年10月時点で終了の告知はありません。2026年1月28日の公式アップデートは、Stripe Managed Paymentsへ利用者が簡単に移れる道を用意する方針を示したもので、期限や終了日は書かれていません。一方で、サポートの遅れと更新頻度の低下を公式に認めているため、新規の大きな投資は避け、移行ツールの公開時期を追っておくのが無難です。
LemonSqueezyとStripeの違いは何ですか？
一番の違いは、法的な売主が誰になるかです。Lemon Squeezyでは自社が売主になり、各国の消費税・VATの登録と申告まで代行します。Stripeを直接使うと売主は販売者自身で、Stripe Taxが計算を手伝っても申告は自社で行います。その代わり、Stripe直接のほうが決済画面の作り込みや手数料の低さで有利です。
Lemon Squeezyで日本の消費税はどう扱われますか？
購入者側の税金は、売主であるLemon Squeezyが購入者の国の税率で計算して徴収し、納付します。日本の販売者が自社の申告で考えるのは、Lemon Squeezyから受け取る売上の扱いです。取引の相手が米国法人になるため、国内の消費税の課否判定や帳簿の付け方が通常の国内売上と変わります。具体的な処理は顧問税理士に確認してください。
Lemon SqueezyのWebhookが届かないときはどこを確認しますか？
まず、ストアの設定で登録したWebhookのURLがテストモードと本番モードのどちらに属しているかを確かめます。両モードは設定が別です。次に、署名検証で401を返していないかをサーバーログで確認します。多いのは、フレームワークがJSONを先に解析してしまい、生の本文でHMACを計算できていないケースです。管理画面からテスト送信を再送して切り分けます。
関連記事
- Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：Lemon Squeezyの親会社であるStripe本体の仕組みと手数料。
- Stripe Billingの実装手順：Price設計・従量課金・カスタマーポータルのコード：Managed Paymentsでサブスクを組むときの土台。
- Stripe APIの使い方：PaymentIntentの作成・APIキー認証・冪等キーをNode.jsとcurlで実装：Stripe側へ移るときのAPIの基本。
- StripeとPayPalの違い：日本の手数料・入金・API実装をコードで比べる選び方：MoRを使わない場合の決済サービスの比べ方。
- サブスクリプション課金とは？継続課金の仕組み・オフセッション決済と更新失敗対策の実装を開発視点で解説：決済サービスを問わない継続課金の設計。
