■ 1. 取り組みの背景
- 取り組みの概要:
- PlayPASS Music Player Androidチームで約1.5ヶ月間、Claude Code / Claude Code Actionを活用したIssue駆動開発を実践
- PlayPASS Music Player:
- レコチョクストア、Music Store、murket storeなど複数の音楽配信サービスの購入コンテンツを一元管理するモバイルアプリ
- プレイパスオートリップ機能により、対応CD/DVD/Blu-rayのQRコードからコンテンツを再生可能
- 2025年9月末に、NFCつきグッズをかざすだけでデジタルコンテンツを楽しめる「PlayPASS PAK」をリリース
- PlayPASS PAKは会員登録不要で、カードデザインによりコレクションとしても楽しめるファンアイテム
- チーム体制:
- Android開発チームは2名構成
- 機能開発からリファクタリング、保守運用まで幅広く担当
- 導入前の課題:
- タスクの属人化により、個々の開発者が抱えるタスクが可視化されにくい
- 人的リソースが限られ、複数タスクの同時進行が困難
- PRレビューが人的作業に依存し、開発速度のボトルネックになっている
- 解決策:
- Issue駆動開発とClaude Code Actionによる自動実装を導入
■ 2. ローカル/リモート実装の判定
- 判定フロー:
- すべてのタスクについて、まずローカル実装とリモート実装のどちらで進めるかを判定
- ローカル実装（Claude Code）の条件:
- 実装方針が不明確で、対話的に設計を進める必要がある
- ローカルDBやデバイス固有機能に依存する
- 難易度が中〜高で、人間の判断が必要
- リモート実装（Claude Code Action）の条件:
- スタンドアロンで完結する
- 難易度が低い（内容によっては中難易度も可）
- 明確な仕様が定義されている
■ 3. Issueテンプレートの活用
- 実装の流れ:
- IssueテンプレートからIssueを作成し、本文を記述してチームでレビュー
- Issueコメント欄の@claudeをトリガーに実装を開始
- Claude Code ActionがIssue本文を仕様として自動実装
- テンプレートの役割:
- Claude Code Actionに対する作業指示書として機能
- 実装精度を高めるため、仕様はできるだけ明確に記載
- 軽微な修正用テンプレート:
- 対象ファイル、修正箇所、誤った内容と正しい内容を記載
- 完了条件として、対象箇所の修正と画面表示や動作での確認をチェックリスト化
- UseCaseユニットテスト用テンプレート:
- テスト対象のUseCase名、パッケージ、ファイルパス、責務（主要機能・入力・出力）を記載
- 正常系テストと異常系テストの仕様をチェックリストで列挙
- 完了条件として、全パターンのテスト、分岐網羅、Repositoryの呼び出し順序・回数検証などを要求
- 各テストが500ms以内に完了し、独立して実行可能であることも要求
- カバレッジ目標はDomain層全体60%以上、対象UseCase80%以上、ビジネスロジック部分90%以上
- コーディング規約として、
メソッド名_前提条件_期待結果形式の命名とGiven-When-Thenパターンを規定- Repositoryの必須モック化、verify()による呼び出し検証、Truthによるアサーション、runTest {}の使用も規定
- テンプレート運用のポイント:
- ラベル claude-code-action でClaude Code Action向けIssueを分類し、実装開始は@claudeメンションで行う
- 難易度ラベルで優先度を管理
- チェックリスト形式で完了条件を明確化
■ 4. タスクストック習慣
- 「まずIssueを作る」習慣:
- Issue駆動開発のコツ
- 思いついたタスクはすぐにIssue化
- どんなタスクでもClaude Code Actionで自動化できないか検討
- 適切なラベル付けで優先度を管理
- 習慣化の効果:
- 常にAIでのタスク処理が可能な状態を維持
- 人間は優先度の高いタスクや複雑な設計に集中可能
■ 5. GitHub連携とビルド最適化
- ビルド環境の重要性:
- Android開発では特にビルド環境の整備が重要
- Composite Actionでの環境セットアップ:
- JDK 17（corretto）をGradleキャッシュ付きでセットアップ
- gradle/actions/setup-gradleで不要なキャッシュを自動削除
- Gradleの並列ビルド:
- gradle.propertiesで org.gradle.parallel=true を設定
- 最適化の効果:
- ビルド時間を10〜15分から6分前後に短縮
- Claude Code Actionのタイムアウト制限（10分）を回避
■ 6. カスタムコマンドによる自動化
- カスタムコマンド化の狙い:
- 頻出する操作をコマンド化し、開発効率をさらに向上
- pr-createコマンド:
- git diffで変更内容を分析
- PULL_REQUEST_TEMPLATE.mdを使用して説明文を自動生成
- 変更内容から適切なラベルを最大3個自動選択し、Draft PRとして作成
- 自動ラベル選択の例:
- ドキュメント変更（*.md）はdocumentation、テスト追加はtest
- バグ修正はbug、新機能はfeature
- カスタムコマンドの効果:
- PR作成時間を70%削減
- pr-reviewコマンドとの組み合わせでレビュー工数を50%削減
- commit-messageコマンドによる自動生成で規約遵守率100%
■ 7. 人間とAIによるタスク並列化
- 並列処理への転換:
- 従来人間が順次処理していたタスクを、人間とAIで並列処理
- 役割分担:
- 人間は複雑な設計や新機能の実装に集中
- Claudeは単体テスト作成、リファクタリング、軽微な修正を担当
- GitHub CopilotとClaudeが並列でコードレビュー
- AIレビューで検出された問題をClaudeが自動修正
- 最終チェックは人間が実施
- 並列化の効果:
- レビュー対応の50%を自動化
- 実質的な開発速度が平均2倍に向上
- 人間は設計やアーキテクチャなどのコア業務に集中可能
■ 8. タスク種別ごとの適性
- 単体テスト作成:
- 適性が最も高く成功率も高い
- 既存コードのカバレッジ向上に最適
- リファクタリング:
- 適性があり成功率も高い
- メソッド抽出、命名改善などが該当
- 軽微な修正:
- 適性があり成功率も高い
- バグ修正、UI微調整などが該当
- 新機能開発:
- 適性があり成功率は中〜高
- Plan Modeで設計を固めてから実装
- 大規模ライブラリ移行:
- 適性が低く成功率も低い
- パッケージの誤参照や未定義パラメータの使用が発生
- 効果的な活用のポイント:
- 曖昧さを排除した詳細な要件定義による明確な仕様
- 1タスクはなるべく1機能を原則とする限定的なスコープ
- 大規模変更は小さなタスクに分割する段階的な実装
■ 9. 再修正率と対策
- リモート実装の再修正率:
- 約3割のケースで手直しが必要
- 主な原因:
- 依存関係の見落とし
- エッジケースの考慮漏れ
- プロジェクト固有の規約の理解不足
- 対策:
- CLAUDE.mdでプロジェクトルールを明文化
- カスタムコマンドで頻出パターンを自動化
- 自動レビューでCopilotとClaudeの二重チェック
■ 10. 定量的な効果
- PR数とAI活用率:
- 約1.5ヶ月で総PR数は約100件
- 半数以上でAIを活用（ローカル約30件、リモート約25件）
- 実装速度:
- 平均2倍に向上
- 単体テスト作成は数時間から数十分に短縮
- リファクタリングと軽微な修正はそれぞれ1時間から20分に短縮
- チームの声:
- 単純作業から解放され、コア機能の設計に集中できるようになった
- 並行作業が当たり前になり、レビュー待ちの時間を有効活用できている
■ 11. 今後の改善方向
- MCP連携の拡大:
- Figma MCPによるデザインからの自動コード生成（導入中）
- Notion MCPによる要件ベースの開発フロー
- Google Analytics MCPによるデータ分析の効率化（定常業務で活用中）
- より複雑なタスクへの適用:
- serena MCPなどLSPベースのツールの導入を検討
- アーキテクチャ変更への適用可能性を探索
- チーム標準化の推進:
- CLAUDE.mdのベストプラクティスを共有
- 成功パターンをテンプレート化
■ 12. まとめ
- 実現できたこと:
- 実装速度が平均2倍に向上
- 人間とAIが役割分担して並行作業を実現
- 単純作業から解放され、設計・アーキテクチャに集中
- 残る課題:
- 大規模な移行作業や複雑なドメイン知識が必要なタスクには課題が残存
- 運用のコツは「Issue駆動の習慣化」:
- まずIssueを作り、AIに任せられないか検討する
- この小さな習慣の積み重ねが大きな生産性向上につながる
- 他プロジェクトへの展開:
- Issue駆動開発とAIツールの組み合わせはAndroid開発に限らず多くのプロジェクトで活用可能
- 注意事項:
- 実際の運用結果は環境やプロジェクトの特性により異なる場合がある