AI駆動開発で位置情報ゲームを作り始めた話 — 設計フェーズ3ヶ月の全記録
Mark4位置情報×AI×キャラクター育成 — 105クラスの設計をAIと共に歩んだ90日間
「位置情報×AI×キャラクター育成」という構想
「吾輩は少し寂れた自販機である、名前はまだない」
スマホのカメラで目の前の自販機を撮影すると、AIがその特徴と地域性を読み取り、キャラクターとして命を吹き込む。ユーザーが名前をつけると、そこから会話が始まる。場所を変えれば出会うキャラクターも変わり、育て方次第で性格も成長も分岐していく。
これが当社が作り始めた「wagahi（吾輩）」というアプリの構想です。
ポケモンGOのような位置情報ゲームの探索性と、たまごっちのような育成の楽しさ、そしてAIによる自然な会話。これらを掛け合わせた、ちょっと欲張りなWebアプリケーションです。H5ベースで動作するため、アプリストアを経由せずブラウザだけで遊べる設計にしました。
なぜAI駆動開発を選んだのか
正直に言えば、この規模のアプリを従来の手法で開発するには、相当な人数と期間が必要です。バックエンドだけで105クラス、フロントエンド27モジュール、データベース8テーブル。これを少人数で実現するには、開発プロセスそのものを根本から変える必要がありました。
今年6月と9月に開催したAI駆動開発セミナーで、当社は「自然言語だけで開発が完結する時代」の可能性と現実を参加者の方々と共有しました。セミナーで語った手法を、今度は自社プロダクトで本気で実践する。wagahiアプリは、まさにAI駆動開発から生まれるアプリです。
開発体制は「人間1名＋AIエージェント群」。人間が担うのは要件定義、技術判断、品質の最終承認。設計からコーディング、テスト設計まで、AIエージェントが主体的に担当します。
7月、Claude.aiのWeb版で設計を始めた
wagahiの設計フェーズは2025年7月に始まりました。最初に使ったのは、Anthropic社のClaude.aiのWeb版です。
開発業務計画書の策定から始まり、ウォーターフォール型V字モデルに沿って、外部設計書、OpenAPI仕様書、内部設計書、詳細設計書を順番に生成していきました。AIとの対話で設計書を作る作業は、想像以上にスムーズでした。こちらが要件や制約を伝えると、Claudeが設計書の骨格を組み立て、私がレビューして方向を修正する。この繰り返しです。
ただし、Claude一本に頼るつもりはありませんでした。
複数AIのクロスレビューという手法
設計の品質を担保するために、当社が採用したのは複数AIによるクロスレビューです。
- Claude: 設計書の主生成を担当。構造化された長文ドキュメントの生成に強く、V字モデルの各フェーズで一貫した設計書を出力できる
- ChatGPT: 設計書のレビュー・指摘に活用。異なる視点からの矛盾点の発見や、代替案の提示に優れている
- Gemini: 技術検証とファクトチェックに活用。Google系サービスとの親和性が高く、最新の技術情報との整合性確認に役立つ
- NotebookLM: 複数の設計書を横断的に分析する場面で活用。資料間の整合性チェックや、要件の抜け漏れ発見に力を発揮する
それぞれのAIには得意分野があります。1つのAIが生成した設計書を、別のAIがレビューする。さらに、最終的には人間の目で判断する。この3層構造によって、単一AIに依存するリスクを軽減しました。
実際、ChatGPTのレビューでClaudeが見落としていたエッジケースが見つかったり、Geminiの指摘でAPI仕様の不整合が発覚したりと、クロスレビューの効果は確実にありました。
Claude Codeでプログラム設計書を自動生成
設計フェーズが進み、詳細設計書がある程度固まった段階で、ツールをClaude.aiのWeb版からClaude Code（VSCode拡張）に切り替えました。
Claude Codeの強みは、プロジェクトのファイル構造を直接参照しながら作業できる点です。詳細設計書を読み込ませた上で、プログラム設計書の生成を指示すると、既存のコードや設定ファイルとの整合性を保ちながら、各クラス・各モジュールの設計書を出力してくれます。
結果として生成されたプログラム設計書は以下の規模になりました。
- データベース: 8テーブルの物理設計書
- バックエンド: 105クラスの設計書（Controller、Service、Repository、Entity、DTO、Config等）
- フロントエンド: 27モジュールの設計書（画面コンポーネント、Redux Store、カスタムHooks等）
合計140件のプログラム設計書。これを人力で書いていたら、どれだけの時間がかかったか。率直に言って、AI駆動でなければこの規模の設計は着手すらためらったと思います。
技術スタックの選定理由
wagahiの技術スタックは、AI駆動開発との相性を重視して選定しました。
- Java 21 + Spring Boot 3.x: AIが生成するコードの型安全性が高く、Spring Bootの規約ベースの構成はAIの出力品質を安定させる
- React 18 + TypeScript: TypeScriptの型システムにより、AI生成コードの品質が自然と担保される。Material-UIとの組み合わせで一貫したUI生成が可能
- PostgreSQL: Spring Data JPAとFlywayによるマイグレーション管理で、DBスキーマの変更履歴を追跡可能に
- Gemini API: アプリ内のAI会話エンジンとして採用。キャラクターとユーザーの対話を生成する中核機能
特にGemini APIの選定は、wagahiの世界観に直結する重要な判断でした。キャラクターが「吾輩はXXXである」と語り出す、あの独特の口調と地域性を反映した会話を生成するために、プロンプト設計には相当な試行錯誤を重ねています。
設計フェーズで見えた現実
3ヶ月の設計フェーズを経て、率直に感じたことがあります。
AI駆動開発は「魔法」ではない。しかし、確実に開発の常識を変える。
AIが生成した設計書は、そのまま使えるものもあれば、大幅な修正が必要なものもありました。特に、要件間の微妙な依存関係や、非機能要件（セキュリティ、パフォーマンス）の考慮は、まだ人間の判断が不可欠です。
一方で、設計書の「たたき台」を瞬時に生成できる効率は圧倒的です。ゼロから書くのと、AIの出力をレビュー・修正するのでは、生産性が桁違いに異なります。セミナーでお伝えした「Howから解放され、WhatとWhyに集中できる」という実感は、自社プロダクト開発でも変わりませんでした。
次回は、このプログラム設計書105件をベースに実装フェーズに入った話をお伝えします。Claude Codeに設計書通りの実装を任せたとき、何が起きたのか。その結果は、良い意味でも悪い意味でも、予想を超えるものでした。
本記事は2025年10月時点の情報に基づいています。
著者: 株式会社シーテン — インフラ系から宇宙関連システムまで20年以上の開発経験を持つ技術者集団。2025年より生成AI・AIエージェントを活用したAI駆動開発に本格参入し、自社プロダクト「wagahi」の開発を通じて実践知見を蓄積中。
関連記事:
投稿者プロフィール
