はじめに
こんにちは！PlayPASS Music Player Androidチームでエンジニアをしている齋藤です。
私たちのチームでは、約1.5ヶ月間にわたりClaude Code / Claude Code Actionを活用したIssue駆動開発を実践してきました。本記事では、その取り組みと実際の効果について紹介します。
PlayPASS Music Playerアプリについて
PlayPASS Music Player は、レコチョクが展開する複数の音楽配信サービス（レコチョクストア、Music Store 、murket storeなど）で購入したコンテンツのダウンロード・再生を一元管理できるモバイルアプリです。また、プレイパスオートリップ機能により、対応CD/DVD/Blu-rayのQRコードからコンテンツを再生することも可能です。
2025年9月末に、NFCつきグッズをスマートフォンにかざすだけで音楽・映像・画像などのデジタルコンテンツを楽しめる新しい再生メディア「 PlayPASS PAK」をリリースしました。会員登録不要で直感的に使用でき、カードデザインでコレクションとしても楽しめるファンアイテムとなっています。
Android開発チームは2名で構成されており、機能開発からリファクタリング、保守運用まで幅広い業務を担当しています。
導入前の課題
従来の開発では、以下のような課題がありました：
- タスクの属人化：個々の開発者が抱えているタスクが可視化されにくい
- 並行作業の難しさ：人的リソースが限られる中で、複数タスクの同時進行が困難
- レビュー待ちのボトルネック：PRレビューが人的作業に依存し、開発速度のボトルネックに
これらの課題を解決するため、Issue駆動開発とClaude Code Actionによる自動実装の導入を試みました。
Issue駆動開発のワークフロー
ローカル/リモート判定フロー
すべてのタスクについて、まず「ローカル実装」と「リモート実装」のどちらで進めるかを判定します。
判定基準
ローカル実装（Claude Code）
- 実装方針が不明確で、対話的に設計を進める必要がある
- ローカルDBやデバイス固有機能に依存する
- 難易度が中〜高で、人間の判断が必要
リモート実装（Claude Code Action）
- スタンドアロンで完結する
- 難易度が低（内容によっては中難易度も可）
- 明確な仕様が定義されている
Issueテンプレートの活用
Claude Code Action用のIssueテンプレートを複数用意し、タスクの種類に応じて使い分けています。
- IssueテンプレートからIssue作成
- 本文を記述しチームでレビュー
- Issueコメント欄で
@claudeトリガーに実装開始 - Claude Code ActionがIssue本文を仕様として自動実装
Issueテンプレートは、Claude Code Actionに対する作業指示書として機能します。 実装の精度を高めるため、仕様はできるだけ明確に記載します。
以下に、使用しているテンプレートを一部紹介します。※ 内容は主要部分を抜粋
軽微な修正用テンプレート
---
name: "Claudeへ依頼する軽微な修正"
labels: ["claude-code-action", "small-fix", "difficulty:easy"]
---
## 修正内容 / Fix
- 対象ファイル: <ファイル名>
- 修正箇所: <具体的に記載>
- 修正内容:
- **誤り**: <誤った文言やUI>
- **正しい内容**: <修正後の正しい内容>
## 完了条件 / Done
- [ ] 対象箇所が修正されている
- [ ] 画面表示や動作確認で正しいことが確認できる
テスト実装用テンプレート
UseCaseのユニットテスト作成では、より詳細なテンプレートを活用しています。
---
name: "UseCaseユニットテスト実装"
labels: ["test", "usecase", "claude-code-action"]
---
## テスト対象 UseCase
- **UseCase名**: GetUserPlaylistUseCase
- **パッケージ**: com.example.domain.usecase.playlist
- **ファイルパス**: androidModule/domain/src/main/java/.../GetUserPlaylistUseCase.kt
## UseCase の責務
- 主要機能: ユーザーのプレイリスト取得と並び替え
- 入力: UserId, SortOrder
- 出力: Flow<List<Playlist>>
## テスト仕様
### 正常系テスト
- [ ] Repository からデータ取得成功時の変換ロジック
- [ ] ソート・並び替えロジックが期待通り動作
### 異常系テスト
- [ ] Repository がエラーを返した際の適切なエラー変換
- [ ] 不正な入力パラメータのバリデーション
## 完了条件
### UseCase テスト品質
- [ ] invoke() メソッドの全パターンをテスト
- [ ] すべてのビジネスルール分岐をカバー
- [ ] 正常系・異常系・境界値をテスト
- [ ] Repository の呼び出し順序・回数を検証
- [ ] テストが独立して実行可能（@Before でセットアップ）
- [ ] 各テストが 500ms 以内に完了
### カバレッジ目標
- [ ] Domain層全体: 60%以上
- [ ] 対象UseCase: 80%以上
- [ ] ビジネスロジック部分: 90%以上
### UseCase テストのコーディング規約
- [ ] テストメソッド名: `メソッド名_前提条件_期待結果` 形式
- [ ] Given-When-Then パターンを厳守
- [ ] Repository は必ずモック化（実装に依存しない）
- [ ] verify() で Repository の呼び出しを検証
- [ ] アサーションは Truth を使用
- [ ] runTest {} で Coroutines をテスト
ポイント：
- ラベル
claude-code-actionでClaude Code Action向けIssueを分類（実装開始は@claudeメンションで行う） - 難易度ラベルで優先度を管理
- チェックリスト形式で完了条件を明確化
タスクストック習慣の構築
Issue駆動開発のコツは、「 まずIssueを作る」という習慣です。
- 思いついたタスクはすぐにIssue化
- どんなタスクでもClaude Code Actionで自動化できないか検討
- 適切なラベル付けで優先度管理
この習慣により、常にAIでのタスク処理が可能になり、人間は優先度の高いタスクや複雑な設計に集中できるようになりました。
Claude Code Actionによる自動実装
GitHub連携の設定ポイント
Android開発では、特にビルド環境の整備が重要です。PlayPASSでは以下の構成を採用しています。
Composite Actionでの環境セットアップ
# .github/actions/setup-android-env/action.yml
name: 'Setup Android Environment'
description: 'Android プロジェクトのビルド環境をセットアップ'
runs:
using: 'composite'
steps:
- name: Set up JDK 17
uses: actions/setup-java@v4
with:
java-version: '17'
distribution: 'corretto'
cache: 'gradle'
- name: Setup Gradle
uses: gradle/actions/setup-gradle@v4
with:
cache-read-only: false
gradle-home-cache-cleanup: true # 不要なキャッシュを自動削除
ビルド最適化の設定
# gradle.properties
org.gradle.parallel=true # 並列ビルド
これらの設定により、ビルド時間を 10〜15分から6分前後に短縮し、Claude Code Actionのタイムアウト制限(10分)を回避できました。
カスタムコマンドによるワークフロー自動化
開発効率をさらに高めるため、頻出する操作をカスタムコマンド化しています。
pr-createコマンド
PR作成時に、変更内容を自動分析してDraft PRを作成します。
# PR作成の自動化
/pr-create
# Claudeが以下を自動実行：
# 1. git diff で変更内容を分析
# 2. .github/PULL_REQUEST_TEMPLATE.md を使用して説明文を自動生成
# 3. 変更内容から適切なラベルを自動選択（最大3個）
# 4. Draft PR として作成
自動ラベル選択の例：
- ドキュメント変更 (
*.md) →documentation - テスト追加 (
test,spec) →test - バグ修正 (
fix,bug) →bug - 新機能 (
feat,feature) →feature
効果
- PR作成時間：70%削減
- レビュー工数：50%削減（
pr-reviewコマンドとの組み合わせ） - 規約遵守率：100%（
commit-messageコマンドによる自動生成）
タスク並列化の実現
従来は人間が順次処理していたタスクを、人間とAIが並列処理できるようになりました。以下の図は、実装からマージまでのフローを示しています。
役割分担の詳細：
- 人間：複雑な設計や新機能の実装に集中
- AI（Claude）：UT作成、リファクタリング、軽微な修正を担当
- 自動レビュー：GitHub CopilotとClaudeが並列でコードレビュー
- 修正対応：AIレビューで検出された問題をClaudeが自動修正
- 最終承認：人間が最終チェックを実施
効果：
- レビュー対応の50%を自動化
- 実質的な開発速度が平均2倍に向上
- 人間は設計やアーキテクチャなどのコア業務に集中可能
運用のポイント
向いているタスク / 向いていないタスク
約1.5ヶ月の運用で、以下の傾向が明らかになりました：
| タスク種別 | 適性 | 成功率 | 備考 |
|---|---|---|---|
| 単体テスト(UT)作成 | ◎ | 高 | 既存コードのカバレッジ向上に最適 |
| リファクタリング | ◯ | 高 | メソッド抽出、命名改善など |
| 軽微な修正 | ◯ | 高 | バグ修正、UI微調整 |
| 新機能開発 | ◯ | 中〜高 | Plan Modeで設計を固めてから実装 |
| 大規模ライブラリ移行 | △ | 低 | パッケージの誤参照、未定義パラメータの使用 |
効果的な活用のポイント
- 明確な仕様：曖昧さを排除した詳細な要件定義
- 限定的なスコープ：1タスク = なるべく1機能を原則
- 段階的な実装：大規模変更は小さなタスクに分割
再修正率と対策
リモート実装では、約3割のケースで手直しが必要でした。主な原因と対策：
原因
- 依存関係の見落とし
- エッジケースの考慮漏れ
- プロジェクト固有の規約の理解不足
対策
- CLAUDE.mdでプロジェクトルールを明文化
- カスタムコマンドで頻出パターンを自動化
- 自動レビューでCopilotとClaudeの二重チェック
効果と今後の展望
定量的な効果
約1.5ヶ月の検証期間で、以下の成果が得られました：
- 総PR数：約100件
- AI活用率：半数以上（ローカル約30件、リモート約25件）
- 実装速度：平均2倍に向上
- UT作成：数時間 → 数十分
- リファクタリング：1時間 → 20分
- 軽微な修正：1時間 → 20分
チームの声
「単純作業から解放されて、コア機能の設計に集中できるようになった」
「並行作業が当たり前になり、レビュー待ちの時間を有効活用できている」
今後の改善方向
現在検討中の改善項目：
- MCP連携の拡大
- Figma MCP：デザインからの自動コード生成（導入中）
- Notion MCP：要件ベースの開発フロー
- Google Analytics MCP：データ分析の効率化（すでに定常業務で活用中）
- より複雑なタスクへの適用
- LSPベースのツール（serena MCPなど）の導入検討
- アーキテクチャ変更への適用可能性を探索
- チーム標準化の推進
- CLAUDE.mdのベストプラクティス共有
- 成功パターンのテンプレート化
まとめ
Issue駆動開発とClaude Code Actionの組み合わせにより、以下を実現できました：
✅
開発速度の向上：実装速度が平均2倍に
✅
並行作業の実現：人間とAIが役割分担して並行処理
✅
コア業務への集中：単純作業から解放され、設計・アーキテクチャに集中
一方で、大規模な移行作業や複雑なドメイン知識が必要なタスクには課題も残っています。
運用のコツは「Issue駆動の習慣化」です。まずIssueを作り、AIに任せられないか検討する。この小さな習慣の積み重ねが、大きな生産性向上につながりました。
Android開発に限らず、Issue駆動開発とAIツールの組み合わせは、多くのプロジェクトで活用できると思います。ぜひ皆さんのプロジェクトでも試してみてください！
参考リンク
本記事は社内での実践事例を基に執筆しました。実際の運用結果は環境やプロジェクトの特性により異なる場合があります。
齋藤匠
