Claude Fable 5でソシャゲ的なゲームを作ってみた。...やっぱすげぇわ

今回はFable 5で、ヒーローコレクション型ゲームを作ってみました。
いわゆるソシャゲ的なやつです。

Fable 5はトークン消費がスゴいとは分かっていたので、今回は事前に設計など細かくOpus 4.8で仕様を詰めて、それをもとに実装させてみました。
（ここがFable 5じゃないところはミスりました）

それが功を奏したのか、
仕様詰めに15分程度、実装に40分くらいで5時間のリミットに届くことなく一回で実装できました。

プランとバージョンは以下の通りです。

まずは完成したゲームです。

ゲーム

タイトル画面

タイトル画面です。
横画面でキャラクターは3Dにしました。

プレイヤー名入力

次にプレイヤー名の入力です。

そしてプロローグです。
ここでストーリーの導入とか、チュートリアルが始まる感じですね。
今回はメッセージを表示して進みます。

ホーム画面です。
ここからいろいろな機能に遷移して行きます。
右側にあるボタンまたは、下のショートカットから。
まだ何もキャラクターがいないので、ガチャを引きます。

ガチャ

ガチャも実装しました。
1連か10連です。
これはゲーム内通貨を使って回します。

ヒーローがフィールドを探索していると卵があるので、
割ってキャラクターをゲットします（笑）

卵からキャラクターが出て入手です。
1体ずつ出てきます。
スキップもあるので結果まですぐに移動できます。

結果画面です。
キャラクターの名前とジョブ、レアリティが表示されてます。
レアリティは、ノーマル、レア、スーパーレアがあります。（ここは伸び代がありますね）

デッキ編成

キャラクターをゲットしたら、デッキを編成します。
パーティは4名です。
上にメンバー、下に手持ちのキャラクターが並んでいるのでタップして入れ替えて編成します。

スーパーレアが出たので入れてます。
ジョブの特性もあるので、バトルによって入れ替えるという遊びも入れておきたいところです。

デッキ編成してホームに戻ると、キャラクターが表示されてます。
デッキの1番左のキャラクターを表示してます。

クエストとバトル

キャラクターが揃ったらクエストに出発します。
それぞれ難易度と、出現する敵が個別に設定されてます。
クエストは、バトルです。
ストーリー読むパートとかあってもいいかもしれません。

バトルはオートバトルです。
キャラクターと敵が交互に戦います。
ジョブによってはスキル使ったりします。
スピード調整変えられるようにしました。

敵を倒すと、リザルト画面が表示され、プレイヤーへの経験値やゲーム内通貨を獲得します。
スタミナ制で、時間で回復、プレイヤーレベルが上がると全回復となってます。

ボス戦の前は、軽く演出が入ってバトルです、

スキルもこのような感じで発動します。
スキル発動時にカメラ寄るところがいいですね。

ボスを倒すことで次のクエスト、いわゆる次の章に行くという流れです。
ここまでが、基本ゲームサイクルです。

ショップ

ショップもあります。
商品は、定番のスタミナ回復剤と、キャラクター強化素材です。

一応リロードすれば最初からですが、リセットボタンも入れました。

キャラクター強化

ショップですキャラクター強化素材を購入します。

デッキ編成画面に移動して、ちょっと小さいですが強化ボタンを押して強化します。

キャラクターもレベルアップしてますね。

動画はこちら

実装

今回は、
事前に仕様をまとめてから実装します（キリッ）
まずはどういったものを作るかざっと書いてそこから概要をまとめます。

これを元に、概要書を作り、概要書から各機能の仕様を詰めて行きます。
基本OKかNG、代案と調整をこちらで出して、完成系のイメージを仕上げます。

仕上がったら、そこからCLAUDE.mdに落とし込み、実装開始できるところまでまとめてもらいました。この作業は15分くらいです。

出来上がったCLAUDE.mdがこれです。
v2となっているのは作り直しをしたので（笑）

# CLAUDE.md — ぱぱぱのヒーローコレクション v2（プロトタイプ）

Claude Code はセッションの最初にこのファイルを読むこと。ここはプロジェクトの憲法。

---

## プロジェクト概要

- タイトル：**ぱぱぱのヒーローコレクション**。ヒーローコレクション型（いわゆるソシャゲ）の **スタンドアロン・プロトタイプ**。
- 目的：**コアループの手触り検証**。オフライン完結。ダメなら引き返す前提の見切り発車。
- 最終形は Unity / ローポリ3D / Google Play を想定。**本プロトは Web だが 3D（ローポリ）で作る**。
  Three.js でローポリ表現を実装し、ロジックと見た目の両方の手触りを確かめる。
  ※ ローポリの**形状の作り方**（パーツ構成・寸法）は `reference/lowpoly_preview.html` を参照。ただし**配色・ライティング・カメラ・レイアウトは引き継がない**（見た目はデザインリソースを正とする）。
- **画面は横向き（landscape）固定。UI・キャラは全体的に大きめに見せる。**
- **画面フロー：タイトル画面 →（タップ）→ 名前入力 →「冒険の始まりです」演出 → ホーム →（各機能へ）**。ホームでは**デッキ先頭キャラを3Dで大きく表示**する。
- **プレイヤー名は非永続**：起動ごとに名前入力画面で設定し、localStorage には保存しない（毎回入れ直す）。

## 技術スタック

- **Vite + React + TypeScript**
- **3D：Three.js + React Three Fiber（@react-three/fiber）**、補助に @react-three/drei（カメラ操作など）
- 状態管理：**useReducer**（状態管理の外部ライブラリは入れない。3Dライブラリはこの例外）
- 永続化：**localStorage**
- スタイル：CSS。**現行HTMLプロトのCSS・レイアウト・配色は流用しない**（プロトは縦画面の動作確認用）。見た目は横画面前提でデザインリソースを正に新規で作る。
- ビルド：`vite build` で静的な HTML+JS を吐き、サーバ不要で手元配布できる状態を保つ

## まず読むべきドキュメント（参照順）

1. `docs/spec/hero_collection_overview_v2.md` … ゲーム概要 v2（**仕様の正**）
2. `docs/art/hero_collection_art_assets_v2.md` … デザインリソース v2
3. `docs/02_data_model_v2.md` … データモデル v2（型定義の正）
4. `docs/03_roadmap_v2.md` … 実装ロードマップ v2（次にやることの正）
5. `docs/04_battle_v2.md` … バトル仕様 v2（見せ方の正）
6. `reference/hero_collection_prototype.html` … **挙動・ロジック・データ構造の正**。挙動で迷ったらこれ。※**見た目（CSS/レイアウト/配色）は参照しない**（縦画面の動作確認用。v2は横画面で新規に作る）
7. `reference/lowpoly_preview.html` … **ローポリ形状の参照**（パーツ構成・寸法の作り方）。※**配色・ライティング・カメラ・レイアウトは最終形ではない**
8. `reference/home_design_final.html` … **ホームUIの見た目の正**（ブライト×エピックの確定モック。配色・角丸・光の演出の基準）
9. `reference/screens_design.html` … **全画面の見た目の正**（タイトル／名前入力／ホーム／クエスト／バトル／ガチャ演出の確定モック）

## ディレクトリ構成

```
src/
  core/            # ゲームロジック。表示に一切依存しない
    types.ts       # 型定義（= データモデル）
    master/        # マスターデータ（今は配列で直書き）
      characters.ts
      stages.ts
    gacha.ts       # 排出ロジック
    battle.ts      # オートバトルのシミュレーション
    economy.ts     # 通貨・報酬・強化コスト
    progression.ts # プレイヤーLv / スタミナ
    reducer.ts     # 状態遷移（useReducer の本体）
  ui/              # React コンポーネント（表示のみ）
    three/         # 3D描画（R3F）。core に依存しない、表示専用
      models/      # buildHero / buildMinion / buildBoss（preview から移植）
      Stage.tsx    # Canvas・ライト・地面・カメラ
      CharacterModel.tsx  # role/element/rarity を受け取り 3D キャラを描く
    screens/       # 各画面（ホーム/ガチャ/編成/クエスト/ショップ）
  storage/         # localStorage 読み書き
  App.tsx
docs/
  spec/hero_collection_overview_v2.md
  art/hero_collection_art_assets_v2.md
  02_data_model_v2.md
  03_roadmap_v2.md
  04_battle_v2.md
reference/          # ← ルート直下（CLAUDE.md の参照パスと一致させる）
  hero_collection_prototype.html
  lowpoly_preview.html
```

## アーキテクチャ原則（最重要）

- **core は表示に依存しない。** core から React / DOM / window を触らない。純粋関数中心に保つ。
- 理由：将来 core を **サーバ(C#)と共有** し、**Unity 移行時にそのまま移植**するため。ここが崩れると移行コストが跳ねる。
- UI は「core の状態を表示し、アクションを dispatch する」だけ。ロジックを UI 側に書かない。
- **3D描画（Three.js / R3F）は ui/three に閉じ込める。** core は 3D を一切知らない。キャラの見た目は `role/element/rarity` から生成し、専用の「モデルID」は持たせない（マスターの情報だけで描ける状態を保つ）。
- ガチャ確率・報酬・強化コストなどの数値は **core/master に集約**。マジックナンバーをUIやあちこちに散らさない。
- **見た目はプロトを引き継がない。** `reference` のHTMLは「挙動・ロジック・ローポリ形状」の参照であって、CSS・レイアウト・配色の見本ではない。UIの見た目・画面レイアウト・配色は**デザインリソース概要書を正**とし、**横画面前提でゼロから設計**する。

## コーディング規約

- TypeScript は strict。**型を先に書く**（型 = 設計の固定）。
- 命名：型・コンポーネントは PascalCase、関数・変数は camelCase。
- マスターデータの ID は概要書準拠（`n1`,`r1`,`sr1`… / 表示名は日本語）。
- 1ファイルが大きくなったら遠慮なく分割する（Claude Code が対象を絞れるように）。
- 依存追加は最小限。迷ったら入れない。

## データ保存の段階（概要書 5-1 準拠）

- 現段階：**メモリ（useReducer）＋ localStorage**。
- マスターは配列（`core/master`）。**後で DB / マスタ配信に載せ替えられる形**を保つ（配列→テーブルが素直に写るように）。
- 確率・報酬の計算は必ず core に閉じ込める（将来サーバ権威に移せるように）。

## 現行の数値（概要書 9章 / すべて調整対象）

- ガチャ：単発10G / 10連100G、排出 SR5% / R25% / N70%、天井なし
- ステージ報酬：通常1G / ボス8G、初回クリアボーナス厚め（通常+5 / ボス+20）
- スタミナ：最大10、消費1、Lvアップで全回復＋最大+2、自然回復 本番15分/1
- 強敵：出現25%、敵ステータス×1.4 / 報酬×1.6
- 戦闘：速度順・必殺ゲージ(+25/行動, 100で発動, ×2.2)・属性三すくみ(火→風→水→火, ×1.5/×0.75)・ヒーラーAI(味方HP60%未満で回復優先)
- レアリティ倍率 N1.0 / R1.35 / SR1.8、レベル成長 +8%/Lv
- 強化コスト：素材=現Lv / ゴールド=現Lv×3
- → これらは `core/master` に定数として集約すること。

## やらないこと（スコープ外）

- サウンド、課金(IAP)、フレンド / ギルド / PvP
- サーバ通信、本物のDB（3Dは今回やる。ただしローポリのプロシージャル生成に留め、外部モデルアセットの読み込みは後回し）
- 過度な最適化・過度な抽象化（プロトなので手触り優先、素朴でよい）

## 作業の進め方

- 迷ったら `docs/03_roadmap_v2.md` の先頭タスクから着手する。
- **挙動・データで**迷ったら、勝手に決めず `reference/hero_collection_prototype.html` に合わせる。**ローポリ形状**は `reference/lowpoly_preview.html` を参照。ただし**見た目・レイアウト・配色はデザインリソース概要書を正とし、プロトのCSSは流用しない**。
- 大きな設計変更をする前に、一言サマリを出してから進める。

その他にも仕様書を機能別にいろいろ用意しました。
ページの都合で全部掲載は難しいのですが、それぞれ細かく書いてあります。

そして実装は、

これで開始です。
ホントに資料大事です（笑）

一部のセットアップ時の承認くらいで、気づいたら出来上がっていたという感じでした（驚）
実装39分2秒、流石だなあと思います（笑）

コンテキストも案外消費少ない印象でした。

リセットからスタートして71%使用でした。
Fable 5の方は14%くらい。

おわりに

やっぱりスゴいですね、Fable 5は。
しっかり資料用意して実装させれば、多少はトークン消費がコントロールできそうで、使えそうな気もしてきました。

以前のは丸投げだったので、書いていないことを調べて探して実装していたので、時間とトークンを消費しまくっていたのではと思います。

とは言え、実装終わってターミナル見返してみると、いろいろやっくてれてますね、テストしてバグったから直すとか、処理時間がかかり過ぎてるところを直したとか、他にも。

完成度はとても高いです（凄）
一式入ってるのはもちろんのこと、あとでツッコミそうなとことか実装入ってました。
もちろん資料をまとめて用意したというのは大きいと思いますが（汗）

今度はこれをOpus 4.8を使って実装させたらどんなアウトプットになるか比較してみたいと思います。
（どっちもスゴいことには変わりないんですが）

【最後まで読んでいただきありがとうございます！】
面白かったと感じた方は、ぜひ「スキ」と「フォロー」をお願いします！

関連記事