キラキラ玉からトークンへ — ゲーム内通貨の一本化設計記

2つの通貨が生んだ混乱 — 設計書間整合性レビュー11タスクの顛末

2つの通貨が生んだ混乱

wagahiアプリには当初、2種類のゲーム内通貨が存在していました。「キラキラ玉」と「トークン」です。

キラキラ玉はゲーム内のイベント報酬やログインボーナスで獲得する通貨。トークンは課金や広告視聴で獲得し、擬人化画像の生成などに使用する通貨。それぞれの用途を分けることで、無課金ユーザーと課金ユーザーの体験を差別化する狙いがありました。

しかし、RC_01のテストを重ねるうちに、この二重通貨システムがユーザー体験を複雑にしていることが明らかになりました。

なぜ一本化を決断したのか

ユーザーの混乱

「キラキラ玉で何ができて、トークンで何ができるのか」をユーザーが直感的に理解するのが難しい。特に初見のユーザーにとって、2つの通貨の違いを覚えるのは不要な認知負荷です。

実装の複雑さ

2つの通貨を管理するということは、残高管理、消費ロジック、表示UIのすべてが2系統必要になります。バグの温床になるだけでなく、新機能を追加するたびに「この機能はどちらの通貨を使うのか」という設計判断が必要になります。

運用の煩雑さ

レート設定、キャンペーン設計、収支分析のすべてが2通貨分必要になります。運用フェーズを考えると、管理コストが倍になることは避けたい状況でした。

総合的に判断し、キラキラ玉を廃止してトークンに一本化することを決断しました。シンプルさはユーザー体験の根幹です。

一本化で実現した設計改善

広告報酬の動的計算化

通貨を一本化したことで、広告視聴の報酬計算がシンプルになりました。

  • Rewarded広告視聴 → 固定トークン付与(管理画面から設定可能)
  • インタースティシャル広告表示 → 少額トークン付与
  • バナー広告クリック → 微量トークン付与

これらのレートをすべて管理画面から動的に変更できるようにしたことで、広告収益とユーザー体験のバランスをリアルタイムで調整できるようになりました。

設計書6種の同時改定

通貨一本化は、アプリ全体に影響する大きな変更です。以下の設計書を同時に改定しました。

  1. DB詳細設計書(v3.9): token_balancesテーブル廃止、新テーブル定義
  2. バックエンド詳細設計書(v18.2): トークン管理API、消費・付与ロジック
  3. フロントエンド詳細設計書(v9.0): 残高表示UI、消費確認ダイアログ
  4. OpenAPI仕様書(v4.2.0): エンドポイント定義の更新
  5. 内部設計書(v3.35): トークンフロー図の更新
  6. 外部設計書(v1.7.36): ユーザー向け仕様の更新

6種類の設計書を同時に改定するのは、かなりの作業量です。しかし、AI駆動開発だからこそ可能な手法がありました。

AI駆動開発での大規模設計書改定

設計書間整合性レビューの自動化

6種類の設計書を同時改定する際、最も怖いのは設計書間の不整合です。DB設計書ではテーブルを廃止したのに、バックエンド設計書では旧テーブルを参照している — こうした不整合は手動レビューでは見落としがちです。

当社は、Claude Codeに「設計書間整合性レビュー」を実行させました。具体的には、以下の11タスクを設定して自動チェックを実施しました。

  • DB設計とバックエンド設計のテーブル参照整合性
  • バックエンドAPIとOpenAPI仕様のエンドポイント一致
  • フロントエンドのAPI呼び出しとバックエンドのレスポンス型一致
  • 内部設計のフロー図とAPI仕様の処理順序一致
  • 外部設計の画面遷移とフロントエンド設計の一致
  • その他6タスク(エラーコード、定数値、バリデーションルール等)

11タスクすべてを完了し、3件の不整合を発見・修正しました。手動では数日かかる作業が、AI駆動開発では数時間で完了しました。

変更影響の自動追跡

「キラキラ玉」という文字列を含むすべてのファイルを検索し、変更が必要な箇所を網羅的にリストアップ。漏れのない改定を実現しました。

移行の実際

既存のキラキラ玉残高をトークンに移行するマイグレーションも実施しました。

  • キラキラ玉1個 = 10トークンのレートで自動変換
  • 移行前後の残高整合性チェック(全ユーザー分)
  • ロールバック手順の事前準備

テスト環境での検証を経て、問題なく移行が完了しました。

まとめ — シンプルさは正義

ゲーム内通貨の一本化は、一見すると「機能を削る」決断に見えます。しかし実際には、ユーザー体験の改善、実装の簡素化、運用コストの削減という三方良しの結果をもたらしました。

複雑さを増やすことは簡単だが、減らすことは難しい。RC_02で学んだ最大の教訓です。

次回は、RC_02完了後の大きな取り組み「設計書6種一斉改定」の全貌をお伝えします。


本記事は2026年1月時点の開発状況に基づいています。

著者: 株式会社シーテン — インフラ系から宇宙関連システムまで20年以上の開発経験を持つ技術者集団。2025年より生成AI・AIエージェントを活用したAI駆動開発に本格参入し、自社プロダクト「wagahi」の開発を通じて実践知見を蓄積中。

関連記事:

投稿者プロフィール

Mark4
Mark4