楽天レビュークーポン配信SaaSを自作で置き換えた — 反応率4.64%と年20万円規模の固定費を同時に見直した話

「月2万円台のSaaSをひとつ解約して、自作で置き換えた」。

文字にすると小さな話ですが、ここに辿り着くまでに2年かかりました。今日はその「楽天のレビュークーポン配信SaaSを内製化した話」を、判断の順番と数字つきで書いていきます。中小ECが運営SaaSを見直すときに、同じ判断軸が使えるはずです。

なぜ楽天レビュークーポン配信SaaSを外注していたのか

当店(楽天市場店)では、2年前から「ある楽天レビュークーポン配信SaaS」を月2万円台で使ってきました。注文の発送後にお客様へメールが自動で飛び、レビューを書いてくれた方には次回使えるクーポンや特典が届く — いわゆる 楽天レビュープレゼント 施策を、SaaSに巻き取ってもらう仕組みです。

選んだ理由はシンプルで、「楽天Order APIとSMTP配信を自社で叩く工数を、外注で買った」 ということに尽きます。当時はEC運営のリソースが今より薄く、レビュー獲得という1施策のために自社の開発時間を割くより、月額固定費で巻き取ってもらう方が合理的でした。SaaSとしては素直に良い買い物だったと思います。

2年間の稼働実績はこうです。

• 累計フォロー配信: 33,237件
• レビュー投稿への反応率: 4.64%
• 月額固定費: 2万円台(年間で20万円規模)

実数で書くと地味ですが、施策として「ちゃんと動いている」状態ではありました。

「解約しよう」と判断した3つの理由

ところが、2年経ったところで複数の理由が重なり、内製化フェーズへの移行を決めました。

反応率4.64%の裏側に「改善余地」が見えていた

SaaSの管理画面には、自店反応率と並んで 全店平均6.95% が表示されていました。つまり当店は全店平均より2ポイント以上下にいたわけです。33,237件配信して2ポイント差ということは、ざっくり月に40〜60件のレビューを取り損ねている計算になります。

「SaaSが悪い」のではなく、ここから先の改善余地を全部自社の手元に置きたかった、というのが本質でした。商品カテゴリ別に件名を変える、季節商品は到着翌日に前倒し、リピート顧客には別文面、楽天イベントに合わせて特典内容を切り替える — こうした次の一手は、SaaS側でテンプレや仕様が拡張されるのを待つよりも、自社で組み替えられる状態のほうが圧倒的に速い。機能不足を埋めるための内製化ではなく、自分たちの実験速度を上げるための内製化でした。

楽天が公式APIを揃え終わっていた

外注した2年前と今で変わったのは、楽天市場の公式API群の充実度です。注文を取る 楽天Order API、クーポンを発行する 楽天Coupon API、配信に使える楽天SMTPサーバ — レビュー獲得施策に必要な部品が、すべて公式の形で揃っていました。

つまり「外注で買っていた工数」の中身が、2年前と今で大きく変わっていたわけです。SaaS提供側もこのAPI群を組み合わせて配信していた、という見立てになります。

社内のAI×コード体制が立ち上がっていた

これが3つ目で、一番効いた理由でした。この2年で社内にClaudeとCodex CLIを使ったコード執筆体制が定着し、「以前なら2週間かかった配信フロー実装」が、設計だけ人間がやれば実装は2〜3日で動くようになっていました。

月2万円台 × 12ヶ月 = 年20万円規模。これを「自社で書ける状態」になった時、外注継続の合理性が静かに崩れていたことに気づきました。

自作MVPの構成 — GAS × Cloudflare Workers

置き換え先として作ったのが、自社プロジェクト gas-rakuten-review-coupon です。構成はシンプルに分解しました。

1. 注文取得: Google Apps Script(GAS)から 楽天Order API を毎日ポーリングし、発送済み注文を抽出
2. クーポン発行: 商品カテゴリと購入金額に応じて、社内クーポンマスタからクーポンコードを 楽天Coupon API で発行
3. 配信: 楽天SMTPサーバ(sub.fw.rakuten.ne.jp:587)経由で、楽天マスクアドレス宛にHTMLメール送信
4. 管理UI: Cloudflare Workers上に、配信履歴・クーポン在庫・テンプレ管理の薄い管理画面を実装

楽天SMTPには注意点があり、送信できる宛先は楽天マスクアドレス(@reg.shopping.rakuten.co.jp 系)のみで、Gmailなど外部宛は550エラーになります。これは仕様で、楽天Order APIから取得できるemailAddressは元々マスクアドレスなので本番運用には支障なし、と分かるまでに少し試行錯誤しました。

開発期間は実働2週間。これでSaaSと同等の動作にたどり着き、加えて以下の自由が手に入りました。

内製化で得た4つの効果

1. 年20万円規模のSaaS固定費がそのまま消えた

直接効果はここ。月2万円台 × 12ヶ月 = 年20万円台の固定費が、自社運用コスト(=ほぼ¥0、APIは無料利用枠内)に置き換わりました。複数店舗展開なら年40万円台、3店舗なら年60万円台 — このまま積算で効きます。

2. 文面ABテストが秒で打てる

差出人名、件名、本文、特典内容 — すべて自社コードなので、1行直してデプロイで即反映できます。レビュー反応率4.64%という数字も、文面変更で改善実験が打てるようになりました。

3. 商品別/モール別/季節別の配信ロジック分岐が自由

「アパレル商品は到着3日後」「家具は到着7日後」「梅雨時期は別文面」 — こうした分岐も、SaaS共通仕様に乗せると拡張のたびに先方の対応待ちになりがちですが、自作なら if 文一行で済みます。

4. 自社DB直結でCRM化の土台ができた

配信ログ・反応ログがすべて自社スプレッドシート(将来的にはDB)に蓄積され、リピーター施策・LINEメッセージ配信・楽天R-Mail配信との連携の足場ができました。SaaSを使い続けていたら、ここで分断されていた部分です。

SaaS内製化が向く店・向かない店

判断軸は経験上シンプルです。向く店は次の3条件をだいたい満たしています。

• 月1万円以上のSaaSを2年以上使っている(=年12万円以上の固定費が回収対象になる)
• 利用しているのが 公式APIが公開されているモール(楽天/Yahoo/Amazon/Shopify等は基本OK)
• 社内 or 外注でコードを書ける人が確保できる(AI支援前提なら、現場担当+AIで十分なケースが増えました)

逆に向かない店は、SaaSを継続した方が安全です。

• 月商規模が小さく、固定費削減より施策の安定運用が大事な店舗
• APIサポートが薄いモール(独自仕様で叩けない、ドキュメントが古い)
• 障害対応の体力がない店(配信が止まった時に深夜でも手を入れられないなら、SLA付きSaaSが正解)

中小ECがSaaS見直しを始める順番

最後に、見直しを始める時の「順番」だけ共有します。

1. 手元の月額固定費を「年額 × 解約難度」で並べる — 数字で見えると、外注継続の判断が冷静になります
2. 公式APIが公開されているモール機能なら、原則自作優先で考える — 外注の中身がAPIの組み合わせなら、内製化の検討余地があります
3. 自社で書けない場合の判断軸を3つに整理する — 「外注継続」「他SaaSへの乗り換え」「軽く書ける開発パートナーに委託」のどれが合うか、年額コストと自由度のトレードオフで決める

「全部内製化が正解」とは思いません。当店も全SaaSを置き換えたわけではなく、継続している外注SaaSの方が今もはるかに多いです。判断軸さえ揃えれば、解約・継続・乗り換えのどれもが冷静な選択肢になります。

---

EC運営のSaaS見直し・内製化判断の壁打ちが必要な方は EC運営の伴走コンサル や、API周りも含めた全体設計が必要なら 物流DX / システム内製化 をご覧ください。具体的なご相談は contact からどうぞ。