はじめに
私は個人でいくつかのモバイルアプリ（iOS/Android）をリリースしていますが、アプリが増えるにつれて開発の課題も増えてきました。
- 時間がない: 1 人で開発するため、細かい部分まで見る時間が取れない
- リソース不足: デザイン、コーディング、テスト、リリース...全部一人
- 品質との両立: 早く出したいが、バグだらけでは困る
私はこれらの課題を「AI に作業を任せ、人は基本的に判断だけに集中する」というアプローチで解決しました。
本記事では、AI チャットアプリを題材に、企画からリリース・運用までの開発パイプラインを紹介します。Claude を中心に、cc-sdd（仕様駆動開発）、GitHub Actions、Maestro（E2E テスト）などを組み合わせた実践的な内容となっています。
実際にリリースしたアプリ
Sodalio
本記事のスコープ: 各ツールの詳細な設定方法ではなく、開発フローの全体像に焦点を当てています。各工程の詳細は個別記事へのリンクから参照してください。
対象読者
- 個人開発者
- AI を使ったアプリ開発に興味がある方
- 開発効率を上げたい方
この記事で得られること
- AI 活用による開発パイプラインの全体像
- 各フェーズでの AI ツールの使い分け
- 「人が判断すべきポイント」の明確化
詳細記事一覧
| # | 記事 | 内容 |
|---|---|---|
| 1 | 企画編 | 市場調査、ペルソナ、収益戦略、product.md、アプリ名、アイコン |
| 2 | プロジェクト初期化編 | cc-sdd 導入、ステアリング設定、ディレクトリ構成 |
| 3 | cc-sdd 開発編 | 要件 → 設計 → タスク →TDD 実装の詳細フロー |
| 4 | コードレビュー編 | ローカルレビュー、AI レビューツール比較 |
| 5 | E2E & VRT 編 | Maestro、Visual Regression Testing |
| 6 | CI/CD & リリース編 | GitHub Actions、ストア文言、自動デプロイ |
| 7 | 運用/改善編 | クラッシュ監視、GA 分析、LEARNINGS.md |
全体像：開発パイプラインの設計思想
設計原則：「人は判断だけ、作業は AI へ」
このパイプラインの核心は、人間の役割を「判断」に限定することです。
- ❌ コードを書く → ✅ AI が書いたコードをレビュー
- ❌ テストを書く → ✅ AI が書いたテストを承認
- ❌ ドキュメントを書く → ✅ AI が生成した仕様を確認
作業は AI が実行し、人間は「これで OK」「ここを修正」という判断だけを行います。
全体フロー
┌───────────────────────────────────────────────────────────────────┐
│ 開発パイプライン全体像 │
├───────────────────────────────────────────────────────────────────┤
│ │
│ 【企画】Claude.ai + Skills + ChatGPT + Canva │
│ ① 市場調査 → ② ペルソナ設計 → ③ 収益戦略 → ④ 開発方針の決定 │
│ → ⑤ アプリ名決定 → ⑥ アプリアイコン作成 │
│ ↓ │
│ 【プロジェクト初期化】Claude Code + YokoFlu │
│ ⑦ Flutterプロジェクト作成 + cc-sddセットアップ │
│ ↓ │
│ 【開発】Claude Code + cc-sdd + Maestro │
│ ⑧ 仕様策定 → ⑨ 設計検証 → ⑩ TDD実装 → ⑪ E2E + VRT │
│ ↓ │
│ 【CI/レビュー】GitHub │
│ ⑫ Push → ⑬ CI実行 → ⑭ AIレビュー（Claude/Codex/BugBot） │
│ ↓ │
│ 【リリース】 │
│ ⑮ リリースブランチ → ⑯ ストア文言生成 → ⑰ 自動デプロイ │
│ ↓ │
│ 【運用】 │
│ ⑱ クラッシュ監視 → ⑲ GA分析 → ⑳ 学びの蓄積 → 【企画】へ │
│ │
└───────────────────────────────────────────────────────────────────┘
各フェーズ概要
1. 企画（Phase 1-6）
Claude の Skills を活用し、市場調査からアプリアイコン作成までを行います。
Skills とは
Claude に追加できる「マニュアル」や「テンプレート」です。例えば市場調査用のSkillsを一度作っておけば、「市場調査して」と伝えるだけで毎回同じフォーマット・同じ観点で分析してくれます。必要な文脈の時だけ読み込まれるため、コンテキストを節約しながら適切なガイダンスを提供できます。
| ステップ | 内容 | ツール |
|---|---|---|
| ① 市場調査 | 競合分析、市場トレンド把握 | Claude.ai + market-research Skill |
| ② ペルソナ設計 | ターゲットユーザーの具体化 | Claude.ai + user-persona Skill |
| ③ 収益戦略 | フリーミアム、サブスク設計 | Claude.ai + monetization-strategy Skill |
| ④ 開発方針 | product.md 生成 | Claude.ai + kiro-product-md Skill |
| ⑤ アプリ名 | 命名、重複チェック | Claude との壁打ち |
| ⑥ アイコン | 素材生成 + 仕上げ | ChatGPT + Canva |
詳細記事で学べること:
- Skills の作成方法と設計意図
- 対話形式での企画進行（選択式質問で方向性を確認）
-
product.md（製品ビジョン）の生成と活用
2. プロジェクト初期化（Phase 7）
企画が固まったら、ローカル環境でプロジェクトを作成し、cc-sdd（Spec-Driven Development）をセットアップします。
cc-sdd とは: AWS の AI IDE「Kiro」が提唱する 仕様駆動開発 のワークフローを Claude Code で再現するためのツールです。「仕様を先に固める」アプローチで、要件の曖昧さ・設計の欠如・手戻りの多さを解決します。
| ステップ | 内容 |
|---|---|
| Flutter 雛形生成 | プロジェクトの生成 |
| cc-sdd インストール | npx cc-sdd@latest --claude-agent --lang ja |
| product.md 配置 |
.kiro/steering/ に企画情報を配置 |
| ステアリング生成 |
/kiro:steering で tech.md, structure.md を自動生成 |
ステアリング（steering）とは: プロジェクトの「記憶」として機能し、AI が全体像を理解した上で仕様策定・実装できるようになります。
-
product.md: なぜこのアプリを作るのか（企画意図） -
tech.md: どんな技術で作るのか（技術スタック） -
structure.md: どう構成するのか（ディレクトリ、規約）
詳細記事で学べること:
- cc-sdd のインストールと設定
- サブエージェント（9 個）とスラッシュコマンド（12 個）の役割
-
.kiro/配下のディレクトリ構成
3. 開発：cc-sdd（Phase 8-11）
cc-sdd（Spec-Driven Development） で、仕様を策定してから実装します。
ただし、仕様駆動開発を行うのは自分で実装すると明らかに数日かかるだろうなという内容のみにしています。
それ以外はバイブコーディングをした方が早いためです。
あくまでも、仕様をきちんと事前に整理しておかないとリスクがあるものや、時間のかかるタスクだけに絞っています。
要件定義 → 👤承認 → 技術設計 → 👤承認 → タスク生成 → 👤承認 → TDD実装
各段階で人が「OK」を出さないと次に進めない仕組みで、無駄な実装を防ぎます。
spec.json による承認管理: 承認状態は spec.json で管理されます。前のフェーズが承認されていない場合、cc-sdd はコマンドを打っても実行を拒否します。全ての承認が完了すると ready_for_implementation: true となり、TDD 実装を開始できます。
利用可能なコマンド（12 個）
仕様策定コマンド:
| コマンド | 役割 |
|---|---|
/kiro:spec-init |
仕様ディレクトリ作成、spec.json 生成 |
/kiro:spec-requirements |
EARS 記法で要件定義 |
/kiro:spec-design |
技術設計書生成 |
/kiro:spec-tasks |
実装タスクリスト生成 |
/kiro:spec-impl |
TDD で実装 |
/kiro:spec-status |
進捗確認 |
/kiro:spec-quick |
クイック仕様生成（対話なしで一気に生成） |
検証コマンド:
| コマンド | 用途 |
|---|---|
/kiro:validate-gap |
要件と既存コードの差分分析 |
/kiro:validate-design |
設計の品質チェック |
/kiro:validate-impl |
実装が仕様を満たすか検証 |
ステアリングコマンド:
| コマンド | 用途 |
|---|---|
/kiro:steering |
ステアリングの初期化・同期 |
/kiro:steering-custom |
カスタムステアリング作成 |
開発支援スキル:
| コマンド | 用途 |
|---|---|
/development:ui-create |
デザインシステムに従った Flutter UI 生成 |
スキルでデザイン一貫性を担保: UI 生成スキルには、ガラスモーフィズム・カラースキーム・スペーシングなどのデザインガイドラインが定義されています。これにより、画面ごとにデザインが揺れることを防ぎます。
詳細記事で学べること:
- 実際の機能追加を通じた cc-sdd ワークフローの実践
- EARS 記法による要件定義の書き方
- TDD サイクル（テスト作成 → 失敗確認 → 最小限の実装 → リファクタ）
4. コードレビュー
PR 作成前のローカルレビューと、PR 後の AI レビューを組み合わせます。
| タイミング | ツール | 得意分野 |
|---|---|---|
| PR 作成前 | ローカル Claude Code | 設計・ロジック・アーキテクチャ |
| PR 後 | Claude Code Action | 俯瞰的レビュー |
| PR 後 | Codex Review | 実装の妥当性 |
| PR 後 | BugBot | バグ・セキュリティ |
複数 AI によるレビュー: 各ツールの得意分野が異なるため、組み合わせることでレビュー品質が向上します。ローカルでの事前レビューにより、PR 作成時点で多くの問題が解消されています。
詳細記事で学べること:
- カスタムスキル（
/code-quality:code-reviewer）の作成方法 -
@claudeメンションで PR タイトル・説明文を自動生成 - レビュー指摘への対応フロー（Critical/Important/Minor の分類）
5. E2E テスト & Visual Regression
単体テストに加えて、E2E テストと Visual Regression Testing で品質を担保します。
| 種類 | ツール | 目的 |
|---|---|---|
| E2E テスト | Maestro | UI 操作の自動テスト |
| Visual Regression | ImageMagick | スクリーンショット差分検出 |
Maestro とは: 宣言的な YAML 形式でモバイルアプリの E2E テストを記述できるツールです。iOS / Android 両対応で、スクリーンショット取得や待機処理の柔軟な制御が可能です。
詳細記事で学べること:
- requirements.md から E2E テストを自動生成（
/e2e:create） - Visual Regression の仕組み（差分率 > 閾値で失敗）
- 失敗時のデバッグ方法（スクリーンショットから AI が自動修正）
👉 詳細記事: E2E & Visual Regression 編
6. CI/CD & リリース（Phase 12-17）
GitHub Actions で CI を実行し、Fastlane で自動デプロイします。
| ステップ | 内容 |
|---|---|
| CI 実行 |
flutter analyze, flutter test
|
| CHANGELOG 更新 | @claude に依頼 |
| ストア文言生成 | 多言語リリースノート自動生成 |
| 自動デプロイ | Fastlane + workflow_dispatch |
@claude でストア文言生成: PR 上で @claude CHANGELOG.md の更新と、App Store 用のリリースノートを多言語で生成して と依頼すると、CHANGELOG 更新とストア文言生成の作業 PR を自動作成してくれます。
詳細記事で学べること:
- モノレポ対応の CI 設定（paths による変更検出）
-
workflow_dispatchによる柔軟なデプロイオプション - メタデータの管理（
Store/ディレクトリで一元管理）
7. 運用（Phase 18-20）
リリース後は運用フェーズに入り、継続的な改善を行います。GitHub Actions で自動化し、@claude メンションで Claude Code Action を起動することで、分析から改善提案までを自動化しています。
| 機能 | 内容 |
|---|---|
| クラッシュ監視 | BigQuery API → GitHub Issue 自動作成（@claude 分析依頼を含む） |
| GA 分析 | 週次 Issue + 日次コメント → @claude 分析 → 改善提案 |
| 学びの蓄積 | 週次で LEARNINGS.md 更新 PR を自動作成 → 人がレビュー |
@claude で Claude が起動する仕組み: Issue/PR に @claude メンションを含めると、.github/workflows/claude.yml が起動し、リポジトリのコードベースを理解した上で分析・提案を行います。GITHUB_TOKEN ではワークフローをトリガーできないため、MONITORING_PAT（GitHub PAT）が必要です。
詳細記事で学べること:
- Crashlytics → BigQuery → GitHub Issue の自動化設定
- GA レポートの週次 Issue + 日次コメント方式
- LEARNINGS.md の週次自動更新フロー（Claude に分析と PR 作成を任せる）
人が行う判断ポイント（14 箇所）
このパイプライン全体で、人が判断を行うポイントは14 箇所です。
| # | 判断内容 | フェーズ | 詳細 |
|---|---|---|---|
| 1 | アイデアの方向性を決める | 企画 | 市場調査・ペルソナ・収益戦略 |
| 2 | ステアリング・アプリ名・アイコンの最終確認 | 企画 | product.md, アプリ名, tech.md, structure.md, アプリアイコン |
| 3 | 要件定義の承認 | 開発 | /kiro:spec-requirements 後 |
| 4 | 技術設計の承認 | 開発 | /kiro:spec-design 後 |
| 5 | 実装タスクの承認 | 開発 | /kiro:spec-tasks 後 |
| 6 | ローカルコードレビューの指摘確認 | 開発 | TDD 実装完了後、PR 作成前 |
| 7 | E2E テストの目視確認 | 開発 | Maestro 実行結果 |
| 8 | Visual Regression 差分の判断 | 開発 | 意図した変更 or バグ |
| 9 | PR のマージ | CI/レビュー | AI レビュー通過後 |
| 10 | ストア文言の最終確認 | リリース | リリースノート・説明文 |
| 11 | ストアアップロードの実行判断 | リリース | 手動実行 |
| 12 | クラッシュ対応方法の選択 | 運用 | 修正方法の決定 |
| 13 | 改善施策をやるかどうか | 運用 | GA 分析結果から |
| 14 | 学びの PR をマージするか | 運用 | 週次 LEARNINGS.md 更新 PR |
cc-sdd の承認プロセス（#3-5）が品質の要: 各段階で人が判断することで、無駄な実装を防ぎ、設計品質を保ちます。spec.json で承認状態が管理され、全ての承認が完了しないと実装に進めません。
作業環境の使い分け
シーンに応じて最適な環境を選びます。
| シーン | 推奨環境 | 理由 |
|---|---|---|
| 新規アプリ企画 | Claude.ai | Skills 活用、ステアリング生成 |
| 新機能開発 | ローカル Claude Code | cc-sdd ワークフロー、TDD |
| リファクタ・設計変更 | ローカル Claude Code | cc-sdd で設計から |
| 簡単な修正・緊急対応 | Claude Code on Web / Claude in Slack | 外出先からも対応可能 |
| ストア文言生成 | どちらでも | CHANGELOG が読めれば OK |
| PR レビュー指摘の修正 | BugBot / Claude in Slack | ワンクリック or Slack 指示 |
使用ツール紹介
このパイプラインで使用する主要なツールを紹介します。
Claude 関連ツール
| ツール | 説明 | 用途 |
|---|---|---|
| Claude.ai | Web ブラウザで利用できる Claude | 企画フェーズでの調査・生成 |
| Claude Code | ローカル環境で動作する CLI ツール | cc-sdd ワークフロー、TDD 実装 |
| Claude Code Action | GitHub Actions として動作 | PR/Issue での @claude メンション対応 |
| Claude Skills | Claude に専門知識を提供するファイルベースのリソース | 市場調査、ペルソナ設計、デザインシステム |
@claude メンションの仕組み
GitHub の Issue や PR で @claude とメンションすると、Claude Code Action ワークフローが起動します。これにより：
- クラッシュ Issue の自動分析
- PR のコードレビュー
- 修正提案と自動修正 PR 作成
が可能になります。詳細は運用/改善編を参照してください。
開発ツール
| ツール | 説明 | 用途 |
|---|---|---|
| cc-sdd | 仕様駆動開発（Spec-Driven Development）のフレームワーク | 要件 → 設計 → タスク → TDD 実装 |
| Maestro | YAML 形式で記述するモバイル E2E テストツール | UI 操作の自動テスト |
| ImageMagick | 画像処理ツール | Visual Regression Testing |
| BugBot | Cursor 製の AI コードレビューツール | バグ・セキュリティ検出 |
| GitHub Copilot Code Review | GitHub 製の AI コードレビュー機能 | 実装の妥当性チェック |
| Fastlane | モバイルアプリの自動化ツール | ストアへの自動デプロイ |
まとめ
個人開発 × AI で得られたメリット
- 時間の節約: 作業時間の大部分を AI が担当
- 品質の向上: 仕様駆動開発 + 複数 AI レビュー + Visual Regression で見落とし減少
- 継続性: 仕様・学びがドキュメント化され、プロジェクトが属人化しない
- 判断への集中: 作業から解放され、本質的な判断に時間を使える
参考リンク
Claude 関連
開発ツール
- cc-sdd（Spec-Driven Development）
- Maestro（E2E テスト）
- ImageMagick（Visual Regression）
- BugBot（Cursor）
- GitHub Copilot Code Review
- Fastlane - App Store / Google Play への自動デプロイ
運用・監視
その他
- Keep a Changelog
- EARS 記法（要件定義）
- Kiro の仕様書駆動開発プロセスを Claude Code で徹底的に再現した - cc-sdd 作者による解説記事