Claude Codeで回す小規模プロダクト開発 - 要求整理からリリースまでやってみた

Claude Codeで回す 小規模プロダクト開発 要求整理からリリースまでやってみた toutou (X: @__tou__tou)

プライベートで1年間に4つのプロダクトを開発した ※ 正社員としての業務プロダクトは含まない。プライベートで取り組んだもの # プロダクト 概要 開発形態 技術スタック 1 ColorPull ARアプリ チーム開発 Unity 2 mimiclip ショート動画作成 チーム開発 Unity + ASP.NET Core 3 業務委託先 Unityゲーム開発支援 チーム開発 Unity 4 mimiry 英語リスニングアプリ 個人開発 React + Hono / CF Workers ベストプラクティスというよりかは、「こういうやり方でやってみた」という体験記に近いかも... 2

開発フロー全体像 3

開発フローを6フェーズに分けて回している 要求整理 → 仕様策定 → 設計 → 実装 → レビュー → リリース 4

ドキュメント駆動で開発を回す AIが生成したドキュメント内容をレビュー・判断し、知見を獲得する → その知見でAIの出力を評価・修正できるようになる 各フェーズで 3 種類のADR（= 意思決定記録）ドキュメントを作成 対応フェーズ 目的 ドキュメント 要求整理 なぜ作るか business 仕様策定 何を作るか spec 設計 どう作るか archi 各ドキュメントに wip → accepted → archive のライフサイクルを導入 AI は基本的に accepted のみ参照 5

要求整理・市場調査 6

「やりたいことは何か」「実現する妥当性があるか」を検討する 「やりたいことは何か」「実現する妥当性があるか」を検討する プロジェクトの目的・モチベーションもここで決めておく 市場調査・競合分析で裏付けを取る 要求整理の精度が低いとモチベーション低下やリリース見送りにつながる 7

コアバリュー・ターゲット・MVPを決め判断軸を作る コアバリューを決める → プロダクトが提供する最も大きな価値を定義 競合調査 → AIに /deep-research で市場分析・競合調査させる ターゲット層を決める → コアバリュー × ターゲットの組を検討 優先度付け → MVP決定 → 開発期間・技術検証を踏まえて絞り込み ブランドカラー・世界観 → デザインの一貫性 上記の指針を決めることで、メンバーが自律的に判断・作業ができるようになる。 8

仕様策定（spec） 9

仕様をドラフト→壁打ち→分割→承認で段階的に固める 1. WIPとしてspecドキュメントを作成 2. Claude Codeと壁打ちして内容を練る 「この仕様で矛盾はないか」「懸念点があれば質問してよい」 3. ロードマップ軸で要件を分割 「この要件はMVPに必要か、Phase 1以降で良いか」 4. 固まったらAcceptedに昇格 10

デザイントークンで表現を制約する 3階層のデザイントークンを定義し、Claude Codeが使える表現を制約 インラインスタイル・具体的な値の書き込みをルールで禁止 ページごとのデザインのズレを防ぐ bg-[#EAB308] bg-primary style="color: ..." text-muted text-[14px] text-sm 階層 役割 例 Primitive 生の値に名前 yellow-500: #EAB308 Semantic 意味で命名 accent-primary: yellow-500 Component UIに紐づけ button-bg: accent-primary Claude Codeは Semantic・Component のみを使って実装 11

設計（archi） 12

モジュール独立性を高めるとClaude Codeの実装精度が上がる 独立モジュール + Interface: コード探索がモジュール内のコードとIF定義に閉じる 依存が複雑: コードベース全体の探索が必要 → コンテキスト消費増 → 精度低下 Unity開発での設計パターン パターン Layered Architecture Service Pattern 構成 3層 + Assembly Definition Feature層 / Base層 向いている規模 中〜大規模, 長期運用 小〜中規模, 買い切りゲーム 13

Layerd Architecture Assembly Definitionで依存関係をコンパイルレベルで制御する 不正な層間参照はコンパイルエラー → Claude Codeが自力で修正可能 14

Service Pattern Feature間の直接参照を禁止しBase層のInterfaceで連携する 15

技術選定はClaude Code任せにしない プラットフォーム 要件が許すなら Webアプリ がネイティブアプリよりも開発速度が出る React (Vite) + Hono + CloudFlare Pages/Workers + Supabase → ネイティブ化は Capacitor ライブラリ Claude Codeのデフォルト提案は古い技術スタック・汎用FWに偏りがち /deep-research で候補を洗い出し、自分で選定する必要がある Unity UI UI Toolkit（USS/UXML）は AIと相性が良い（コード定義ベース） ただしClaude CodeのUSS/UXML知識は薄い → Unityオフラインドキュメント参照必須 16

設計判断をADRに記録するとClaude Codeの出力ズレに気づける 技術スタックの選択肢・比較・判断根拠をADRとして記録 問題発生時に判断根拠を遡って再評価できる 17

実装 18

フィードバックループの整備が鍵 Claude Codeが自分の出力を検証できる仕組みを用意する 手法 Playwright MCP Unity MCP GitHub Actions CI TDD (Red-GreenRefactor) 対象 仕組み ブラウザ操作 + スクリーンショット判断 + E2Eテス Web ト実行 Unity コンパイルログ取得 全般 gh でポーリング → ログ取得 → 修正 Web カバレッジ目標をルールに明記 19

コンパイルエラーとCIでClaude Codeに自動修正させる Unity MCP コード変更 → コンパイルログ取得 → エラー修正 Assembly Definitionによる不正な依存はコンパイルエラーとして検出 GitHub Actions CI コード品質チェック（UTF-8、改行コード、.metaファイル検証） EditMode / PlayMode テスト自動化 「CIが通るまで修正して」で自動的にエラー解消 バッチ処理: claude -p "{prompt}" をシェルスクリプトでループ実行 20

レビュー 21

過去の指摘パターンからレビュー指針を作りレビューを半自動化 過去レビューの指摘パターンを抽出 → レビュー指針ドキュメントを作成 GitHub ActionsでPR自動レビュー — 指針を事前読み込み Critical / Major → /fix-review で修正 / Minor → 任意対応 22

claude-code-actionのレビュー例 23

UIUXは基準が言語化しにくく人間のレビューがボトルネック 動画コンテンツの評価システム Remotionで生成した学習動画を評価用アプリで採点 静的UIのレビュー カタログ形式の簡易レビューアプリで一覧表示 24

レビュー用Webアプリは使い捨て感覚でサクッと作れる 25

リリース 26

リリース戦略 ストアリリースのための事務手続き バーチャルオフィス契約 / DUNS番号取得 / Apple・Google開発者登録 場合によっては1~2か月かかるので早めに準備 小さくリリースし反応を得る ハッカソンや展示会、SNSちょい出しなどしてフィードバックを得て段階的に拡大する 広報 SNSコンテンツ作り / SNSコンテンツ制作フローの構築 広告 27

まとめ 28

眠らせていたアイデアを実現できるようになった この1年の変化 手を動かす部分はAIに任せる 人間は要求整理・判断・フィードバックに集中 「作って確かめる」サイクルを速く回せるようになった まだ道半ばなこと パブリックリリースはまだできていない 広報は試行錯誤中 「やりたいこと」が尽きないようにしていきたい 29