開発実績

日本のガチャガチャ（カプセルトイ）は、店頭に足を運んで実機を回すことが前提の売り方でした。欲しい景品があっても設置店舗が分からず、海外からは手に入れる方法がほとんどありません。

この課題に対して開発したのが、景品配送型のオンラインガチャガチャサービス「ガチャWith」です。ブラウザからガチャを回し、当たった景品をあとでまとめて配送申請できます。日本語と英語に対応し、海外からの購入も想定した設計になっています。

プロジェクト概要

• プロダクト名：ガチャWith

• カテゴリ：オンラインカプセルトイEC（越境EC）

• 対象ユーザー：日本のカプセルトイを購入したい国内・海外のユーザー

• 対応プラットフォーム：Webアプリ（PC / スマートフォン）

• 開発内容：既存サービスのリプレイス、Webアプリ開発、管理画面開発、インフラ構築、保守運用

UI・機能紹介

トップ画面

新着ガチャとジャンル別の一覧を並べ、目的が決まっていない状態でも見て回れる構成にしました。カプセルトイは景品のビジュアルそのものが購入の決め手になるため、台紙の画像を大きく扱い、価格と名称を添えるだけの簡潔なカードにしています。

画面右上には日本語と英語の切り替えを常設しました。海外からの訪問者が最初に迷う箇所なので、メニューの中に隠さず表に出しています。

ガチャ詳細画面

1回あたりのポイント数、販売期間、在庫、景品のサイズと種類数を一覧で確認できます。オンラインで回す以上、実機のように現物を見て判断できないため、手元に届くものを事前に把握できる情報量を優先しました。

景品のラインナップと排出確率も公開しています。残数によって実際の確率が変動することも画面上に明記し、回してから認識が食い違うことがないようにしています。

スマートフォン対応

利用の中心がスマートフォンになることを前提に、画面下部にホーム・さがす・コレクションのタブを固定しました。横スクロールで並ぶジャンル一覧から、片手で目的のガチャまで到達できます。

購入から発送申請までの流れ

ポイントを購入してガチャを回し、当たった景品はコレクションに蓄積されます。景品は獲得のたびに発送するのではなく、あとから選んでまとめて発送申請する方式にしています。1回ずつ配送すると送料が購入体験を圧迫するため、複数回分をまとめられるようにしています。

決済はStripeを利用し、ポイント購入のみをオンライン決済の対象にしました。ガチャを回す操作自体は保有ポイントの消費で完結するため、抽選のたびに決済処理が走らない構成になっています。

管理画面

運営側が日々の運用を完結できるよう、専用の管理画面もあわせて開発しました。ガチャと景品の登録、在庫と排出確率の設定、発送申請の確認と処理、ユーザーとポイントの管理、問い合わせの対応までを扱えます。

景品の入れ替えが頻繁に発生する商材なので、新しいガチャの公開と販売終了を運営だけで操作できることを重視しました。

課題

ガチャWithは当初ノーコードツールBubbleで構築しておりましたが、動作状況などを鑑みてより安定してユーザー様にご利用いただくためにコードを主体とした開発に切り替えました。サービスを止めずに中身を入れ替える必要があり、次の点が論点になりました。

• 仕様書が残っておらず、現行サービスが実際にどう動いているか書類から把握できない

• 国内と海外では配送できる景品や送料が異なり、一律の購入フローにできない

• 抽選を扱うため、表示している確率と実際の排出が食い違ってはならない

• 在庫が有限で、同じ景品に購入が集中したときの整合を保つ必要がある

• 景品ごとに配送すると送料がかさみ、購入のハードルになる

• 日本語と英語で同じ情報を提供し続ける必要がある

解決アプローチ

1. 現行の挙動を機械的に記録してから作り直す

仕様書が無い状態で作り直すと、画面を見て再現したつもりでも細かい挙動が抜け落ちます。そこで専用のクローラを書き、現行サービスを未ログインとログイン済みの両方で巡回し、画面遷移と通信の中身を日本語版・英語版それぞれで記録しました。

人の記憶や口頭の説明ではなく、記録した通信の一覧を突き合わせの材料にしています。どの画面がどのデータを呼んでいるかを先に押さえたことで、作り直しの範囲を推測で決めずに済みました。

2. 配送条件を購入前に提示する

対象国と国別の送料をデータとして持ち、登録住所の国に配送できる景品だけを扱えるようにしました。送料は発送申請の段階で確定しますが、配送できない組み合わせは購入前の時点で分かるようにしています。

3. 抽選と在庫をサーバー側で確定させる

抽選結果と在庫の減算はサーバー側の処理で完結させ、画面側の演出とは切り離しました。排出確率は景品ごとの設定値として管理し、残数の変動も含めて利用者に説明しています。

4. 発送をまとめられる仕組みにする

獲得した景品をいったんコレクションとして保持し、利用者が任意のタイミングで複数をまとめて発送申請できるようにしました。送料の負担を抑えつつ、回す体験と受け取る体験を分けています。

5. 多言語を前提に組む

画面の文言はすべて言語リソースとして外に出し、日本語と英語を同じ仕組みで切り替えています。あとから言語を足す場合も、画面の作りを変えずに対応できます。

稼働中のサービスを止めずに基盤を移す

作り直しにあわせて、実行環境も別の構成へ移しました。すでに使われているサービスなので、移行の失敗がそのまま利用者の損失になります。切り替えの前に、何が移行済みで何がまだ残っているかを一つずつ確かめて行いました。

利用者のアカウントは、ポイントと獲得済みの景品、購入履歴を保ったまま新しい認証基盤へ移しています。パスワードだけは仕組み上そのまま持ち込めないため、本人に再設定してもらう前提で導線を用意しました。ここを曖昧にすると、ログインできない利用者が理由の分からないまま離脱します。

旧環境の解約時も、配信中のファイルを実際に取得して旧システムへの参照が残っていないかを確認し、止める順番を決めてから進めました。あわせて構成を見直したことで、月あたりのインフラ費用は試算ベースで4分の1程度に下がっています。

技術構成

• フロントエンド：React / TypeScript / Tailwind CSS

• 多言語対応：i18next

• バックエンド：TypeScript（Hono）/ PostgreSQL

• インフラ：AWS（AWS CDKでコード管理）

• 認証：Amazon Cognito

• 決済：Stripe

リリース後も保守運用を継続して担当しています。景品の入れ替えが続くサービスなので、作って終わりではなく、運用しながら改善を重ねられる体制で支援しています。