はじめに
こんにちは！
ポケモンチャンピオンズを楽しんでいるGameWithのエンジニアのinosy22です。
現在ダブルバトルをメインでチャンピオン級目指して奮闘中です！
なんとかレート2100までは行くことができました！
今回は、4/8にリリースされた「ポケモンチャンピオンズ」のゲームのリリースに合わせて、攻略ツール5つを初期リリースした話をしたいと思います。
昨今のAIエージェントの進化のおかげもあって、2.5人日(20時間)ほどの開発時間で実現することができました！
仕様をよくわかっている状態の Claude Code でAIを使わずに実装したパターンと比較見積もりしてもらいましたが、生産性は1760%になっているという状態でした。
まだ改善の余地はあるかもしれませんが、このツールたちをどのように効率よく開発していったかの話を共有していきたいと思います。
なお、AIがコーディングに関連する事以外の情報収集は禁止するように細心の注意を払って利用しています。
利用したAIエージェント
開発中は、 Claude Code Teamプラン Premiumシートでモデル「Opus 4.6」を利用していて、レビューには Github Copilot を使っていました。
※開発モデルに関する補足
現在は
Opus 4.7が出ており、プロンプトのベストプラクティスや挙動が一部異なる可能性があります。最新モデルでのClaude Codeの活用については、公式の以下の記事も併せてご参照ください。 Best Practices for using Claude Opus 4.7 with Claude Code
作ったツールはどんなもの？
※ 日本向けの GameWith とは別でグローバル向けのサービスになります！
↓実際のツールはこちらからご覧いただけます。
要件など
- 新しいサービスとして新規開発、横展開できるベースとなるようにする
- データベースを軸としたツール展開
- グローバルに使える多言語対応
初期リリースした5つのツール
- ポケモンDB
- 育成シミュレーター
- ダメージ計算機
- 耐久計算機
- 素早さ比較ツール
現在では、ティア表作成ツールなどの新規ツールを追加したり、自分のプレイ経験から欲しいと感じた機能を各種ツールに追加したり、ブラッシュアップを日々行なっています。
おかげさまでグローバルに数万人の方に使っていただけています。
開発にあたっての準備
今回全く新規のリポジトリで、AIエージェントを使ったバイブコーディングを行うことになるという前提の元で始めました。
そのため効率よく開発するためのツールとして、GSD (Get Shit Done) に目をつけました。
GSD とは
GSDとは、 Claude Code によるバイブコーディングの信頼性を高めるためのツールです。
以下のフローに従って、対話的に必要な要素を形作っていくことで、徹底的にマークダウンファイルに落とし込むことによって、効率的なバイブコーディングを実現します。
| フェーズ | 目的・内容 |
|---|---|
| 0. 既存理解 | 既存のコードベースを解析し、AIのコンテキストとして読み込む。 |
| 1. 初期化 | プロジェクトの目的を対話で固め、土台となるファイルを生成する。 |
| 2. 議論 | 実装に入る前に、仕様のグレーゾーンをAIとすり合わせる。 |
| 3. 調査 | 実装に必要な外部APIや複雑なドメイン知識を自律的に調査する。 |
| 4. UI計画 | フロントエンドのUI設計やデザインのルール（契約）を決定する。 |
| 5. 計画 | 議論や調査をもとに、フェーズごとの詳細な実装タスクを作成する。 |
| 6. 実行 | 計画に基づいて自律的にコードを生成し、機能ごとにコミットする。 |
| 7. 検証 | 実装が要件を満たしているかテストし、検証を行う。 |
GSDは使うべきか？
自分が体感したメリットデメリット
メリット
- 大規模で曖昧な状態のプロジェクトの開発スタートの整理に向いている
- 実行フェーズに入れば、自律的に長時間対応してくれる
- 作業履歴をわかりやすく管理してくれるので離席しても安心
- コンテキスト管理をマークダウンで行うのでセッションは切れても大丈夫
デメリット
- 膨大なマークダウンファイルを読み込みながら自動実行なのでコンテキスト消費が大きくなることがある
- 開発作業スタートまでの仕様作成にとても時間がかかる
- マークダウンファイルの作成が過剰だと感じる
結論
GSDの仕組み自体はすごく良いですが、過剰な部分で無駄にコンテキストや時間を消費している箇所もあると感じました。
仕様などについてはある程度、GSDを経由せずに作ってから、GSDのフローに行く方が効率的です。
一方で、曖昧な状態から開発をスタートしたい場合は、GSDで最初から始めるのも良いと感じています。
そのため、最終的な私の開発では自分自身でGSDのいいとこどりをして、各フェーズを必要な時に必要なだけやる形にしました。
開発フロー
攻略ツールのデータ集め
GameWithのポケモン攻略班の方達が頑張って集めていただいているデータを利用させていただきました！
いつも有用な情報を集めて記載いただいている攻略班の方達には頭が上がりません！
ドメイン知識の仕様書作成
- ステータス計算式
- ダメージ計算式
- 用語のまとめ
など、ポケモンの仕様をまとめるのはとても楽しい作業でした！
基本的には自分で内容を作りつつ、AIにフォーマットだけ整えてもらいながらまとめていきました！
技術的な仕様書作成
- デザインルール（
DESIGN.md） - コーディングの設計ルール
- 多言語対応ルール
- URLのルーティングルール
- 各ページの細かい仕様書
ここが一番大変でした。特に DESIGN.md は開発当時定まったものがなかったので、GameWithのデザインを読み込ませながら頑張ってルール化しました！
これについては、会社としてルールを整備していく必要があると感じ、現在はデザイナーさんと協力して DESIGN.md の制作を行なっています！
また、各ページの細かい仕様書は各セクション要素の配置を指示する程度まではいいですが、テキストボックスの配置など細かいUI要素の指示は、実際に開発しながら調整した方が早いと感じたので、あまり踏み込まないように気をつけました。
技術選定
| カテゴリ | 技術 | 用途 |
|---|---|---|
| ランタイム | Node.js | JavaScript実行環境 |
| パッケージマネージャ | pnpm | 依存管理 |
| フレームワーク | Next.js | Reactフレームワーク |
| 言語 | TypeScript | 型安全な開発 |
| UIコンポーネント | shadcn/ui | コンポーネントライブラリ |
| スタイリング | Tailwind CSS | ユーティリティファーストCSS |
| データベース | SQLite | マスターデータの管理・検索 |
| リンター | ESLint | コード品質 |
Next.jsはWebに知見も多く、skillの配布もされており、サーバーとフロントをまとめて作ることができるので、バイブコーディングに非常に向いているフレームワークだと思います。
また、shadcn/ui というデザインフレームワーク基盤もskillの配布がされているため、扱いやすいと感じて採用しています。
マスターデータの扱いについて、膨大な量の固定データを扱う場合にCSVやJSONなどの生データのまま扱うよりも、SQLiteを利用して必要な分だけデータ取得する形にした方が、AIエージェントのコンテキストの節約になりながら、高速な処理を行うことができました。
インフラについては、コンテナベースで動くように作っていますが、詳細は割愛します。
開発フェーズ
1. 仕様書をインデックスする
バイブコーディングをする上で、「コンテキスト劣化」の対策を行う必要があります。
そのため、AGENTS.md もしくは CLAUDE.md に対して、仕様書を参照できるように目次を作ります。
具体的には以下のような形です。
AGENTS.md もしくは CLAUDE.md については、下記のような記事も書いていますので、興味のある方はご確認ください。
2. ページごとの初期構築
ページごとの初期構築など時間がかかるものはがっつりと設計書を作った状態で離席して、長時間AIエージェントに作業してもらいます。
その中で壁となったのが、 Claude Codeの「5時間のセッション制限」でした...。
これを乗り切るための泥臭い工夫として、/loop コマンドを利用しました。離席する前や、退勤前に大規模な改修を頼んでおいて、
/loop 1時間 セッション制限による中断作業があれば再開してください
と指示して、cronによる定期的な指示を設定してもらいます。
これによって、 制限に引っかかって一時停止しても、制限が解除されたタイミングでAIが自動的に作業を再開してくれます。
人間が稼働しない時間をAIの「待ち時間」に充てることで、限られた時間を効率的に使うことができました。
3. テストコードの充実化
今回は計算系のツールが中心のため、特に効果的でした！
ポケモンのダメージ計算は特性や技などによって大きく変わり、そのパターンは膨大なので、TDD（テスト駆動開発）も交えながら、膨大なユニットテストコードを作成しました。
AIなら網羅的に1万件ほどのテストパターンでも即座に作ってくれて、機能追加時のデグレチェックなども安心して行うことができました！
4. ブラッシュアップ
初期構築が終わった後に、PCやスマホなどで使い心地を担保する部分については、どうしても人間がやらなくてはならない作業でした！
UIコンポーネントの作成などを適当に指示すると、多重管理になってしまいす。 最初はそれでもなんとかしてくれるのですが、セッションが長くなってコンテキスト劣化が始まると、途端に多重管理のことは忘れてしまい、バグが起きやすくなります。
そのため、処理やコンポーネントの共通化 を指示することは作業効率化としてとても重要な事項でした。
また、共通化はコーディングルールとして AGENTS.md もしくは CLAUDE.md に記載しておくと、いい感じに機能します。
まとめ
効率的なバイブコーディングのコツ！
- GSDの開発フローを参考に仕様書から作る
AGENTS.mdへの仕様書インデックス- UIの細かい指示は仕様で定義しない
/loopを使って長い作業を任せる- ユニットテストによる堅牢性を担保
- 処理やコンポーネントの共通化を意識
おわりに
GameWithではAIを活用した開発を行うエンジニアを募集中です！
ご興味ありましたら是非カジュアル面談をお申し込みください！ github.com
