この記事は「モバイルアプリ開発における AI 活用術」の詳細記事です。
目次
- はじめに
- cc-sdd とは
- 利用可能なコマンド
- 開発支援スキル（Claude Code Skills）
- 実践：カスタムキャラクター画像の自動生成機能
- Step 1: 仕様初期化
- Step 2: 要件定義
- Step 3: 技術設計
- Step 4: タスク生成
- Step 4.5: 設計検証（オプション）
- Step 5: TDD 実装
- Step 6: 実装検証（オプション）
- 進捗確認
- 👤 人の判断ポイント（まとめ）
- 次のステップ
- 参考リンク
はじめに
開発フェーズでは、cc-sdd（Spec-Driven Development） という手法を使います。これは「仕様を策定してから実装する」アプローチで、3 段階の承認プロセスを経て品質を担保します。
このフェーズのゴール:
- 要件定義 → 技術設計 → タスク生成 → TDD 実装の流れを理解
- 各段階での人の判断ポイントを明確化
- 実際の機能追加を通じたワークフローの習得
cc-sdd とは
cc-sdd は「仕様駆動開発」のフレームワークです。
┌─────────────────────────────────────────────────────────────────────┐
│ cc-sdd（Spec-Driven Development） │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 要件定義 ──→ 👤 人が承認 ──→ 2. 技術設計 ──→ 👤 人が承認 │
│ │ │ │
│ └─ validate-gap（既存実装との差分分析） └─ validate-design │
│ │
│ ──→ 3. タスク生成 ──→ 👤 人が承認 ──→ 4. TDD 実装 │
│ │ │
│ ↓ │
│ 5. ローカルレビュー │
│ │ │
│ 👤 指摘確認・修正 │
│ │ │
│ validate-impl（実装検証） │
│ │
│ ※ AI は .kiro/specs/ と .kiro/steering/ を参照しながら仕様を策定 │
│ │
└─────────────────────────────────────────────────────────────────────┘
核心：各段階で人が「OK」を出さないと次に進めない
これにより
- 無駄な実装を防げる
- 設計段階で問題を発見できる
- AI の暴走を防げる
利用可能なコマンド
cc-sdd をインストールすると、12 個のスラッシュコマンドが利用可能になります。
仕様策定コマンド（Spec）
| コマンド | 役割 |
|---|---|
/kiro:spec-init |
仕様ディレクトリ作成 |
/kiro:spec-requirements |
EARS 記法で要件定義 |
/kiro:spec-design |
技術設計書生成 |
/kiro:spec-tasks |
実装タスクリスト生成 |
/kiro:spec-impl |
TDD で実装 |
/kiro:spec-status |
進捗確認 |
/kiro:spec-quick |
クイック仕様生成（対話なしで一気に生成） |
検証コマンド（Validate）
| コマンド | 用途 | 使いどころ |
|---|---|---|
/kiro:validate-gap |
要件と既存コードの差分分析 | 既存アプリへの機能追加 |
/kiro:validate-design |
設計の品質チェック | 複雑な機能の設計レビュー |
/kiro:validate-impl |
実装が仕様を満たすか検証 | 実装完了後の最終確認 |
ステアリングコマンド（Steering）
| コマンド | 用途 |
|---|---|
/kiro:steering |
ステアリングの初期化・同期 |
/kiro:steering-custom |
カスタムステアリング作成（独自ルール） |
ステアリングコマンドの使い分け: /kiro:steering は product.md、tech.md、structure.md などコアファイルの管理に使います。/kiro:steering-custom は API 規約やテスト方針など、プロジェクト固有のルールを追加したいときに使います。
開発支援スキル（Claude Code Skills）
cc-sdd のコマンドに加えて、Claude Code のスキル機能を活用することで、プロジェクト固有のルールやデザインシステムに従ったコード生成が可能です。
スキルとは
スキルは Claude Code に専門知識を提供するファイルベースのリソースです。.claude/skills/ ディレクトリに配置することで、必要なコンテキストの時だけ自動で読み込まれます。
このプロジェクトで使用しているスキルの一例
| スキル/コマンド | 用途 |
|---|---|
development:ui-create |
Sodalio デザインガイドラインに従った Flutter UI 生成 |
※これは筆者の独自スキルです
UI 生成スキルの内容
/development:ui-create コマンドを使うと、以下のデザインシステムに従った UI コードが生成されます。コマンドを使わなくても文脈から必要な時に自動で読み込まれることもあります。
デザインシステムの構成要素:
| 要素 | 内容 |
|---|---|
| ガラスモーフィズム | 半透明背景 + ブラー効果のカード・コンテナ |
| カラースキーム | Primary (#6C63FF), Accent (#FF6584), Background (#0F0F1E) など |
| スペーシング | 8px ベースのシステム（xs=4, sm=8, md=16, lg=24, xl=32） |
| タイポグラフィ | h1-h3, bodyLarge/Medium/Small, caption, button |
| Border Radius | sm=8, md=16, lg=24, xl=32, pill=999 |
含まれる機能:
- Riverpod による状態管理パターン
- Flutter Intl による多言語対応（i18n）
- アクセシビリティ対応（セマンティックラベル、タップターゲット）
- アニメーション（フェードイン、スケール）
- レスポンシブデザイン
使用例
# UI作成を依頼
/development:ui-create
# 具体的な依頼例
「設定画面を作成してください。ガラスカードでセクションを分け、トグルスイッチとラジオボタンを配置してください」
ポイント: デザインシステムをスキルとして定義しておくことで、画面ごとにデザインが揺れることを防ぎ、一貫した UI を維持できます。新しいメンバーが参加しても、スキルを通じてデザインルールが自動適用されます。
実践：カスタムキャラクター画像の自動生成機能
ここからは cc-sdd を用いた実際の機能追加の流れを記載していきます。
追加する機能
今回追加する機能は AI のカスタムキャラクター作成時に、入力した設定内容（名前・性格・口調など）をもとに AI がアバター画像を自動生成する機能です。
↓ この画面に生成ボタンを配置し、キャラクター画像を自動生成するようにする。
↓ 機能追加後のイメージ
Step 1: 仕様初期化
/kiro:spec-init カスタムキャラクター作成時に設定内容からAIでキャラクターの画像を自動生成する機能を作成する
実行結果
.kiro/specs/ai-character-image-generation/ ディレクトリが作成され、spec.json と初期の requirements.md が生成されます。
.kiro/specs/
└── ai-character-image-generation/
├── spec.json ← フェーズと承認状態を管理
└── requirements.md ← 初期の要件（簡潔な内容）
spec.json によるフェーズ管理
spec.json は仕様の進捗と承認状態を管理するファイルです。
要件定義 → 技術設計 → タスク生成の各フェーズで approved: true になると次のフェーズに進めます。
前のフェーズが承認されていない場合は cc-sdd はコマンドを打っても実行を拒否します。
全ての承認が完了すると ready_for_implementation: true となり、/kiro:spec-impl で TDD 実装を開始できます。
| フィールド | 説明 |
|---|---|
phase |
現在のフェーズ（initialized → requirements → design → tasks） |
approvals.*.generated |
ドキュメントが生成されたか |
approvals.*.approved |
人が承認したか |
ready_for_implementation |
全承認後に true になり、実装可能になる |
Step 2: 要件定義
/kiro:spec-requirements ai-character-image-generation
EARS（Easy Approach to Requirements Syntax） 記法で要件が生成されます。
| パターン | 構文 | 例 |
|---|---|---|
| 普遍的 | The [system] shall [action] | The system shall display error messages in red |
| イベント駆動 | When [event], the [system] shall [action] | When user taps generate, the system shall call AI API |
| 状態依存 | While [state], the [system] shall [action] | While generating, the system shall show progress |
| オプション | Where [condition], the [system] shall [action] | Where premium user, the system shall allow unlimited |
生成される requirements.md の例
以下は実際のプロジェクトで生成された requirements.md の抜粋です
# Requirements Document
## Introduction
本ドキュメントは、Sodalio アプリにおける「AI キャラクター画像自動生成機能」の要件を定義する。
## Requirements
### Requirement 1: AI 画像生成の起動
**Objective:** As a ユーザー, I want カスタムキャラクター作成画面で AI 画像生成を起動できること, so that 手動で画像を用意しなくてもキャラクター画像を作成できる
#### Acceptance Criteria
1. When ユーザーがカスタムキャラクター編集画面で AI 画像生成ボタンをタップする, the アプリ shall AI 画像生成フローを開始する
2. While AI 画像生成に必要な設定項目が未入力である, the アプリ shall 生成ボタンを無効化し、必要項目を示すツールチップを表示する
3. When AI 画像生成ボタンが有効な状態でタップされる, the アプリ shall 現在の設定内容から画像生成用プロンプトを構築する
### Requirement 3: 画像スタイル選択
**Objective:** As a ユーザー, I want 生成する画像のスタイルを選択できること, so that 自分の好みに合ったキャラクター画像を作成できる
#### Acceptance Criteria
1. When AI 画像生成フローが開始される, the アプリ shall 画像スタイル選択 UI を表示する
2. The アプリ shall 既存の ImageStyle から選択可能なスタイル（アニメ、写実、ピクセルアート等）を提供する
3. When ユーザーがスタイルを選択する, the アプリ shall 選択されたスタイルをプロンプトに適用する
### Requirement 7: 使用制限とクォータ管理
**Objective:** As a システム, I want AI 画像生成の使用回数を管理すること, so that サービスコストを適切に管理できる
#### Acceptance Criteria
1. The アプリ shall ユーザーのサブスクリプションレベルに応じた画像生成回数制限を適用する
2. When ユーザーが画像生成制限に達している, the アプリ shall 制限到達メッセージを表示し、プレミアムアップグレードを案内する
3. While 無料ユーザーの場合, the アプリ shall 画像生成機能をプレミアム限定機能として表示する
実際の requirements.md: 完全版は .kiro/specs/ai-character-image-generation/requirements.md に 10 個の Requirement として定義されています。各 Requirement には Objective（User Story 形式）と Acceptance Criteria（EARS 記法）が含まれます。
👤 人の判断ポイント
要件に漏れがないか、既存機能との整合性があるかを確認して承認します。
確認観点：
- 機能要件の網羅性
- 非機能要件（性能、セキュリティ）
- 既存機能との整合性
- 受け入れ基準の妥当性
Step 3: 技術設計
要件が承認されたら、技術設計に進みます。
/kiro:spec-design ai-character-image-generation
生成される design.md の例
# 技術設計書
## 概要
**目的**: カスタムキャラクター作成時にユーザーが入力した設定内容から
AI 画像を自動生成し、手動での画像選択を不要にする。
**影響**: 既存の CustomCharacterEditorScreen に AI 画像生成ボタンを追加し、
既存の generateImage Cloud Function および ImageStyle enum を再利用する拡張実装。
## アーキテクチャ
┌──────────────────────┐
│ CustomCharacter │
│ EditorScreen │──┬─▶ ImageStyleSelectorDialog
└──────────────────────┘
│ └─▶ ImagePreviewDialog
▼
┌──────────────────────┐
│ CharacterPrompt │
│ Builder │
└──────────────────────┘
│
▼
┌──────────────────────┐ ┌──────────────────────┐
│ AIService │───▶│ Cloud Function │
│ (既存) │ │ (generateImage) │
└──────────────────────┘ └──────────────────────┘
│
▼
┌──────────────────────┐
│ Vertex AI Gemini │
└──────────────────────┘
## コンポーネント
| コンポーネント | 役割 |
| ------------------------ | ---------------------------------- |
| CharacterPromptBuilder | キャラクター属性からプロンプト構築 |
| ImageStyleSelectorDialog | 画像スタイル選択 UI |
| ImagePreviewDialog | 生成画像のプレビュー・採用・再生成 |
| AIService（既存） | Cloud Function 呼び出し |
| FirestoreService（既存） | 画像圧縮・Storage 保存 |
## エラーハンドリング
| エラー | 対応 |
| ------------------------- | -------------------------------------- |
| クォータ超過 | 制限到達メッセージ + プレミアム案内 |
| コンテンツポリシー違反 | プロンプト修正を促すメッセージ |
| タイムアウト | 再試行オプション表示 |
| ネットワークエラー | リトライボタン表示 |
実際の design.md: 完全版には Mermaid 図、要件トレーサビリティ表、インターフェース定義（Dart コード）、テスト戦略、多言語対応キー一覧なども含まれます。
👤 人の判断ポイント
既存の Service/Provider との整合性、パフォーマンスへの影響を確認します。
確認観点：
- アーキテクチャの一貫性
- 既存コンポーネントとの統合（AIService、FirestoreService）
- エラーハンドリングの網羅性
- パフォーマンスへの影響
Step 4: タスク生成
設計が承認されたら、実装タスクを生成します。
/kiro:spec-tasks ai-character-image-generation
生成される tasks.md の例
# Implementation Plan
## Tasks
- [ ] 1. プロンプト構築ユーティリティの実装
- [ ] 1.1 キャラクター属性からプロンプトを構築するクラス作成
- [ ] 1.2 プロンプト構築ロジックのユニットテスト
- _Requirements: 2.1, 2.2, 2.3, 2.4, 2.5_
- [ ] 2. 画像スタイル選択ダイアログの実装
- [ ] 2.1 スタイル選択 UI をガラス風デザインで構築
- _Requirements: 3.1, 3.2, 3.3, 3.4_
- [ ] 3. 画像プレビューダイアログの実装
- [ ] 3.1 生成画像のプレビュー表示と操作 UI を構築
- _Requirements: 5.1, 5.2, 5.3, 5.4_
- [ ] 4. 多言語対応のローカライゼーション追加
- [ ] 4.1 AI 画像生成機能の UI 文字列を 16 言語でローカライズ
- _Requirements: 10.1, 10.2_
- [ ] 5. キャラクター編集画面への AI 画像生成機能統合
- [ ] 5.1 AI 画像生成ボタンを編集画面に追加
- [ ] 5.2 AI 画像生成フローの実装
- [ ] 5.3 生成画像の採用・保存処理を実装
- [ ] 5.4 再生成機能の実装
- _Requirements: 1.1, 1.2, 1.3, 6.1, 6.2, 6.3, 8.1, 8.4_
- [ ] 6. エラーハンドリングとクォータ管理の実装
- [ ] 6.1 画像生成エラーの処理とユーザーフィードバック
- _Requirements: 7.1, 7.2, 9.1, 9.2, 9.3, 9.4_
- [ ] 7. 統合テストの実装
- [ ] 7.1 AI 画像生成フロー全体の統合テスト
- [ ] 7.2 エラーケースとクォータ制限の統合テスト
- _Requirements: 全要件_
ポイント: 各タスクには _Requirements:_ で対応する要件番号が紐付けられます。これにより「どの要件を満たすための実装か」が明確になり、トレーサビリティが確保されます。
👤 人の判断ポイント
タスクの粒度が適切か、漏れがないかを確認します。
確認観点：
- タスクの粒度（大きすぎ/小さすぎ）
- 依存関係の順序
- テストタスクの有無
Step 4.5: 設計検証（オプション）
複雑な機能や既存コードへの影響が大きい場合、設計を検証できます。
# 設計の品質チェック（対話形式）
/kiro:validate-design ai-character-image-generation
validate-gap について
既存コードベースがある場合、/kiro:validate-gap で要件と既存実装の差分を分析できます。
/kiro:validate-gap ai-character-image-generation
これにより：
- 既存コードで再利用できる部分
- 新規に実装が必要な部分
- 既存コードへの影響範囲
が明確になります。
タスクまでを承認すると"ready_for_implementation"が true になり、実装着手可能になります。
Step 5: TDD 実装
実装準備ができたので、テスト駆動開発（TDD） で実装していきます。
/kiro:spec-impl ai-character-image-generation
TDD サイクル
cc-sdd では、以下の TDD サイクルを厳密に守ります：
┌─────────────────────────────────────────────────────────┐
│ TDDサイクル │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. テスト作成 ──→ 2. テスト実行（失敗を確認） │
│ ↑ │ │
│ │ ↓ │
│ 4. リファクタ ←── 3. 最小限の実装（テスト通過） │
│ │
│ ※ 実装中はテストを変更しない（テストが仕様） │
│ ※ テストが通るまで実装を修正し続ける │
│ │
└─────────────────────────────────────────────────────────┘
AI の実装フロー
AI が各タスクについて以下を繰り返します：
- テスト作成（期待する入出力に基づく）
- テスト実行（失敗することを確認 → テストが正しい証拠）
- 最小限の実装（テストを通すためだけのコード）
- リファクタ（テストを壊さずに改善）
実装が完了していくと、順次 Tasks のチェックボックスにチェックがついていきます。
重要なルール
重要: 実装中にテストを変更するのは NG です。テストは「仕様書」であり、実装の都合で変えてはいけません。テストが通らない場合は実装を修正します。
Step 6: 実装検証（オプション）
実装が完了したら、仕様を満たしているか検証できます。
/kiro:validate-impl ai-character-image-generation
検証内容
- 要件（requirements.md）を全て満たしているか
- 設計（design.md）に従っているか
- タスク（tasks.md）を全て完了しているか
- テストが全てパスするか
進捗確認
いつでも進捗を確認できます：
/kiro:spec-status ai-character-image-generation
出力例
## ai-character-image-generation
| Phase | Status | File |
|-------|--------|------|
| Requirements | ✅ Approved | requirements.md |
| Design | ✅ Approved | design.md |
| Tasks | ✅ Approved | tasks.md |
| Implementation | 🔄 In Progress | 3/5 tasks |
全てのタスクが完了するとこのように結果が表示されます。
👤 人の判断ポイント（まとめ）
| # | 判断内容 | タイミング |
|---|---|---|
| 1 | 要件定義の承認 |
/kiro:spec-requirements 後 |
| 2 | 技術設計の承認 |
/kiro:spec-design 後 |
| 3 | 実装タスクの承認 |
/kiro:spec-tasks 後 |
次のステップ
👉 コードレビュー編 へ進む