🧭 本記事は Claude Code実務運用シリーズ の STEP 4「カスタムコマンド化する」です。
自作の前に、公式が用意した標準Skillの使い所を整理します。
シリーズ全体の地図と読む順は 親記事 にまとめています。
※ iOS開発者は iOS版 へ。
はじめに
この記事は、以前公開した Claude Code標準SkillをAndroidアプリ開発でどう使うか という記事を、Claude Codeの最新changelogに合わせてアップデートしたものです。
公開当初は、Claude Codeのbundled skillsとして /simplify、/batch、/debug を中心に整理していました。
しかし、Claude Codeのchangelogを確認すると、/simplify は現在 /code-review に改名されています。また、以前のようなcleanup-and-fix寄りの挙動ではなく、現在は correctness bugを見つける差分レビュー用Skill として説明されています。
そのため、この記事では、以前の /simplify 中心の説明を、現在の推奨表記である /code-review 中心に更新します。
この記事で扱う主なSkillは以下です。
/code-review
/batch
/debug
加えて、実行確認に関係する補足として、以下も扱います。
/run
/verify
/run-skill-generator
Androidエンジニアが最初に使うなら、まずは以下の2つが実用的です。
/code-review
/batch
/code-review は実装後の差分レビューやバグ検出に、/batch は大きな変更を安全に分割する用途に向いています。
この記事でアップデートした内容
今回の主な更新点は以下です。
1. /simplify を /code-review に置き換えた
2. /code-review を「コード整理」ではなく「correctness bugを見つける差分レビュー」として説明した
3. /batch の説明を、worktreeとbackground subagentを使った大規模変更の分割という位置づけに更新した
4. /debug を、Claude Code側のセッション・設定・MCP・ログ調査用として整理した
5. /run /verify /run-skill-generator を、実行確認の補足として追加した
特に重要なのは、/simplify の扱いです。
古い記事や過去の説明では /simplify と書かれている場合がありますが、現在は /code-review を使う方が正確です。
旧表記:
/simplify
現在の推奨表記:
/code-review
/simplify がaliasとして動く環境もありますが、記事としては /code-review に統一した方が読み手に誤解を与えにくいです。
公式ドキュメント上の根拠
Claude CodeのSkillsドキュメントでは、Skillは SKILL.md に書かれた指示をClaudeのツールキットに追加する仕組みとして説明されています。
Claudeは必要に応じてSkillを使うことも、ユーザーが /skill-name の形で直接呼び出すこともできます。
また、Claude Codeにはbundled skillsが用意されており、/code-review、/batch、/debug、/loop、/claude-api などが含まれます。
重要なのは、bundled skillsは、多くの組み込みコマンドのように固定ロジックを直接実行するものではないという点です。
bundled skillsは prompt-based であり、Claudeに詳細なplaybookを渡し、Claudeがツールを使いながら作業を進めるものとして説明されています。
つまり、Claude CodeのSkillは「固定された処理を機械的に実行するコマンド」というより、Claudeに作業手順を渡して、Claude Code上のツール操作を含めて実行させるための標準ワークフロー と理解すると実務で使いやすくなります。
また、Claude CodeのCommandsドキュメントでは、/code-review は現在の差分をcorrectness bugsの観点でレビューし、ファイルを編集せずに結果を報告するSkillとして説明されています。
Claude Codeのchangelogでは、/simplify は /code-review に改名され、旧来のcleanup-and-fix挙動は削除されたと説明されています。
そのため、Androidアプリ開発の記事としては、/simplify を中心に説明するよりも、/code-review を中心に説明する方が現在の仕様に合っています。
Androidアプリ開発での基本方針
Androidアプリ開発でClaude Code標準Skillを使う場合、重要なのはSkill名そのものよりも、渡す前提条件の具体性です。
Androidアプリには、WebやiOSとは異なる固有の確認観点があります。
- Kotlin / Java のどちらが中心か
- Jetpack Compose / XML View のどちらが中心か
- minSdk / targetSdk / compileSdk
- Gradle / Android Gradle Plugin / Kotlin Plugin
- single-module / multi-module構成
- Hilt / Dagger / KoinなどのDI構成
- Coroutine / Flow / LiveData / RxJavaの利用有無
- Room / Retrofit / OkHttpなどの利用有無
- Firebase Analytics / Crashlyticsを使っているか
- R8 / ProGuardの設定
- 署名、Play App Signing、リリース設定への影響
たとえば、Android Developersのアプリアーキテクチャガイドでは、Modern App Architectureとして、layered architecture、Unidirectional Data Flow、UI layerのstate holder、coroutines and flows、dependency injection best practicesなどが挙げられています。
AndroidアプリをClaude Codeでレビューする場合も、単に「コードを整理して」ではなく、UI、状態管理、非同期処理、DI、データ層まで含めて前提を渡す方が実務に近くなります。
たとえば、単に次のように入力するだけでは、Claudeは一般的な差分レビューとして判断します。
/code-review
Androidアプリ開発では、以下のように前提条件を付けた方が実用的です。
/code-review high 最近変更したKotlinコードを、Androidアプリ開発・Jetpack Compose / XML View混在・既存挙動維持の前提でレビューしてください。
確認観点:
- correctness bug
- Activity / Fragment lifecycleへの影響
- Compose stateへの影響
- ViewModelの責務
- Coroutine / Flowのキャンセル漏れ
- collectのライフサイクル安全性
- Repository / UseCase / DataSourceの責務分離
- Firebase Analytics / Crashlyticsへの影響
- R8 / ProGuard / release buildへの影響
- テストで担保すべき観点
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
1. /code-review：実装後の差分レビューに使う
/code-review の位置づけ
/code-review は、現在の差分や指定した対象に対して、正しさに関係する問題を見つけるためのSkillです。
以前は /simplify という名称で説明されていましたが、現在は /code-review に改名されています。
/code-review には、次のような使い方があります。
/code-review
/code-review high
/code-review max
/code-review high --comment
/code-review high path/to/file.kt
low、medium、high、xhigh、max などのeffort levelを指定できます。
通常の業務では、まず high を使うとバランスが取りやすいです。
--comment を付けると、GitHub PR上にinline commentとして指摘を投稿できます。PRレビューの文脈では便利ですが、まずは通常の /code-review high でレビュー結果だけを確認する使い方が安全です。
Android開発で使う場面
/code-review は、以下のような場面で有効です。
- Activity / Fragment の修正後に副作用を確認したい
- ViewModelに責務が集まりすぎていないか確認したい
- Jetpack Composeのstate管理に問題がないか確認したい
- Coroutine / Flowの扱いに問題がないか確認したい
- Repository / UseCase / DataSourceの責務分離を確認したい
- Hilt / Dagger / KoinなどのDI設定への影響を確認したい
- Firebase Analyticsイベント送信処理の重複や揺れを確認したい
- WebViewやログイン処理を修正した後に副作用を確認したい
- R8 / ProGuard / release buildへの影響を確認したい
- PR前に差分のcorrectness bugを洗い出したい
以前の /simplify という名前からは「コードをきれいに整理する」「自動でリファクタリングする」という印象を受けやすいですが、現在の /code-review は、あくまで 差分の正しさを確認するレビュー用途 として使う方が実務向きです。
そのまま使えるプロンプト例
/code-review high 最近変更したKotlinファイルをレビューしてください。
前提:
- Androidアプリ開発
- Kotlin中心
- Jetpack Compose / XML Viewが混在している
- minSdk / targetSdk / compileSdkはプロジェクト設定に従う
- 既存挙動は変えない
- public APIは不用意に変更しない
- まだコードは変更しない
確認観点:
- correctness bug
- Activity / Fragment lifecycleへの影響
- Composableの責務過多
- ViewModelの責務過多
- state hoistingが適切か
- Coroutine / Flowのキャンセル漏れ
- collectのライフサイクル安全性
- UI stateとdomain modelの分離
- Repository / UseCase / ViewModelの責務分離
- R8 / ProGuard / release buildへの影響
- テストで担保すべき観点
出力形式:
- 対象ファイル
- 問題箇所
- 問題の理由
- 影響範囲
- 修正方針
- 優先度: High / Medium / Low
- 事実 / 仮説 / 不明点
Jetpack Compose向けの例
/code-review high ProductDetailScreen.ktを中心に、最近変更したComposableをレビューしてください。
目的:
- Composableの変更によって既存UIの挙動が壊れていないか確認する
- UI stateの持ち方に問題がないか確認する
- ViewModelとの責務分離に問題がないか確認する
確認観点:
- Composableの分割候補
- remember / rememberSaveable の使い分け
- LaunchedEffect / DisposableEffect の副作用管理
- recompositionが不要に増えそうな箇所
- state hoisting
- ViewModelとの責務分離
- Previewしやすい構造か
- UI Testで確認しやすい構造か
制約:
- まだコードは変更しない
- まずレビュー結果だけを出す
- 推測は「仮説」と明記する
Composeでは、UIは状態に応じて再構成されるため、stateの持ち方やイベントの流し方が重要です。
Android DevelopersのCompose UI Architectureでは、Composableはstateを受け取り、eventを公開する形がUnidirectional Data Flowに合うと説明されています。
そのため、Compose画面をレビューするときは、単にComposableを分割するだけでなく、stateがどこで保持され、eventがどこへ流れているかまで確認するのが重要です。
XML View / Fragment向けの例
/code-review high UserProfileFragment.kt と関連するXML layoutをレビューしてください。
前提:
- XML Viewベース
- Fragment + ViewModel構成
- 既存挙動は変えない
- まだコードは変更しない
確認観点:
- Fragmentにロジックが集まりすぎていないか
- ViewBindingの扱いが安全か
- lifecycleOwnerの指定が適切か
- LiveData / Flowのcollectがライフサイクル安全か
- 画面回転やプロセス再生成で問題が起きないか
- XML layout側の重複やネスト過多
- テスト観点
Repository / Data Layer向けの例
Android DevelopersのData layerドキュメントでは、data layerはアプリケーションデータとビジネスロジックを含み、repositoriesが0個以上のdata sourceを持つ構成として説明されています。
RepositoryやDataSourceをClaude Codeで確認するときは、UI層との責務分離やテスト容易性を確認観点に入れると有効です。
/code-review high 最近変更したRepository / DataSource / UseCaseをレビューしてください。
前提:
- Kotlin
- Repository + DataSource構成
- Retrofit / Room / DataStoreを利用している可能性がある
- 既存のAPI仕様やDB schemaは変更しない
- まだコードは変更しない
確認観点:
- RepositoryとDataSourceの責務分離
- UI層の都合がData layerに漏れていないか
- Coroutine / Flowの扱い
- error handling
- retry / timeout
- cache方針
- Unit Testでmockしやすい構造か
ポイント
既存アプリでは、いきなり修正させるよりも、まずレビューだけにするのが安全です。
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
/code-review は、コードを勝手に整理させるためのものではなく、差分の問題を見つけるためのレビュー用途として使うのが実務向きです。
2. /batch：大規模変更を安全に分割する
/batch の位置づけ
/batch は、複数ファイル・複数画面・複数module・複数レイヤーにまたがる大きな変更を、独立した作業単位へ分割するためのSkillです。
Claude CodeのCommandsドキュメントでは、/batch はコードベースを調査し、5〜30個程度の独立した作業単位に分解し、承認後に各作業を個別のgit worktreeとbackground subagentで進めるものとして説明されています。
そのため、/batch は1ファイルだけの軽微な修正には向きません。
影響範囲が広い変更を、安全に分けて進めたいときに使うのが適切です。
Android開発で使う場面
- XML ViewからJetpack Composeへの段階移行
- JavaからKotlinへの段階移行
- Activity / Fragmentの責務整理
- multi-module化
- RxJavaからCoroutine / Flowへの移行
- deprecated APIの置換
- targetSdk更新に伴う影響調査
- Android Gradle Plugin更新に伴う影響調査
- R8 / ProGuard設定の見直し
- Firebase Analyticsイベント設計の整理
- WebView処理の共通化
- 署名・リリース設定の確認
XML ViewからJetpack Composeへの段階移行の例
/batch XML Viewベースの画面をJetpack Composeへ段階移行するため、影響範囲を調査して作業単位に分割してください。
前提:
- 既存Androidアプリ
- Kotlin中心
- 現在はFragment + XML layout構成
- 一度に全面移行しない
- 既存の画面遷移や表示仕様は変えない
- まず調査と分割計画だけを出す
- まだコード変更はしない
確認観点:
- Compose化しやすい画面
- XML layout依存が強い画面
- ViewModelの再利用可否
- UI stateの整理
- Navigationへの影響
- Preview作成のしやすさ
- UI Testへの影響
- 段階移行の順序
出力形式:
## 作業分割案
1. 対象領域
2. 対象ファイル
3. 修正方針
4. リスク
5. テスト観点
6. 推奨する実施順序
targetSdk更新の例
/batch targetSdk更新に伴う影響範囲を調査し、安全な作業単位に分割してください。
前提:
- Androidアプリ開発
- Kotlin中心
- 既存挙動を変えない
- まず調査と計画だけを出す
- まだコード変更はしない
確認観点:
- AndroidManifest.xmlへの影響
- Runtime Permissionへの影響
- PendingIntentのflag
- notification permission
- foreground service関連
- WebViewや外部アプリ連携
- Firebase / Google Play services SDK
- Gradle / Android Gradle Pluginとの互換性
- 手動確認が必要な端末・OSバージョン
出力:
- 影響がありそうな領域
- 対象ファイル
- 対応優先度
- リスク
- テスト観点
Gradle / Android Gradle Plugin更新の例
Android DevelopersのAndroid Gradle Pluginドキュメントでは、Android StudioのビルドシステムはGradleをベースにしており、Android Gradle PluginがAndroidアプリのビルドに固有の機能を追加すると説明されています。
AGPやGradle更新は、ビルド、Lint、依存関係、生成コード、CIに影響しやすいため、/batch で影響範囲を分けて確認するのが安全です。
/batch Android Gradle Plugin更新の影響範囲を調査してください。
前提:
- 既存Androidアプリ
- Kotlin中心
- multi-module構成の可能性がある
- 既存のビルド設定を不用意に変えない
- まず調査と計画だけを出す
- まだコード変更はしない
確認観点:
- build.gradle / build.gradle.kts
- settings.gradle / settings.gradle.kts
- Gradle wrapper
- Kotlin plugin
- Compose Compiler
- Android Lint
- CI
- 生成コード
- 外部ライブラリ互換性
- リリースビルドへの影響
R8 / ProGuard見直しの例
Android DevelopersのR8ドキュメントでは、R8は未使用コードの削除、実行効率の改善、難読化などを行い、アプリのサイズや速度を最適化する仕組みとして説明されています。
一方で、reflection、serialization、DI、外部SDKなどが絡むと、release buildでのみ起きる不具合につながる場合があります。
そのため、R8 / ProGuard設定の見直しは慎重に進める必要があります。
/batch R8 / ProGuard設定を見直すため、影響範囲を調査して作業単位に分割してください。
前提:
- Androidアプリのrelease buildが対象
- minifyEnabled / shrinkResources の設定を確認する
- 既存のリリース挙動を壊さない
- まず調査と計画だけを出す
- まだコード変更はしない
確認観点:
- proguard-rules.proのkeep rule
- reflectionを使っている箇所
- JSON serialization / deserialization
- DI framework
- WebView JavaScript interface
- Firebase / Crashlytics
- 外部SDK
- 難読化後クラッシュログのretrace
- release buildでのみ起きる不具合リスク
署名・リリース設定確認の例
Android Developersのアプリ署名ドキュメントでは、Androidアプリはインストールまたは更新の前に証明書で署名されている必要があると説明されています。
また、Google PlayでAndroid App Bundleを配信する場合は、Play App Signingやupload keyの扱いも重要になります。
リリース設定をClaude Codeに確認させる場合も、まずレビューだけにするのが安全です。
/batch Androidアプリの署名・リリース設定をレビューするため、確認作業を分割してください。
前提:
- release buildが対象
- Google Play配信を想定
- まだ設定ファイルは変更しない
- まず確認項目とリスクを整理する
確認観点:
- release buildType
- signingConfig
- keystore情報がリポジトリに含まれていないか
- Play App Signing前提の設定か
- CI上でsecretをどう扱っているか
- versionCode / versionName
- 不要なログ出力がrelease buildに残っていないか
- ProGuard / R8設定との関係
- リリース前に確認すべき項目
ポイント
/batch は小さな修正よりも、影響範囲が広い変更を分解する用途に向いています。
特にAndroidアプリでは、1つの変更が以下に波及することがあります。
- ログイン状態
- 課金・購入導線
- WebView
- Push通知
- Deep Link / App Links
- Firebase Analytics / Crashlytics
- targetSdk / permission / manifest
- Gradle / AGP / Kotlin Plugin
- R8 / ProGuard
- 署名・リリース設定
1ファイルだけの軽微な修正であれば、通常のプロンプトや /code-review の方が扱いやすいです。
一方で、複数画面・複数module・複数レイヤーにまたがる変更では、いきなり実装させるよりも、まず /batch で影響範囲と作業分割を整理する方が安全です。
3. /debug：Androidアプリのデバッグではなく、Claude Code側の不調調査に使う
/debug の位置づけ
/debug は、Claude Codeのセッション、設定、MCP、ツール実行、ログまわりを調査するためのSkillです。
名前だけを見ると、Androidアプリのクラッシュ調査に使うものだと思うかもしれません。
ただし、実務上は、/debug はAndroidアプリのクラッシュ解析そのものというより、Claude Codeのセッション、設定、MCP、ツール実行がうまく動かないときの調査 に使うものと考える方が自然です。
Claude CodeのCommandsドキュメントでは、/debug は現在のセッションでdebug loggingを有効にし、session debug logを読んで問題を調査するSkillとして説明されています。
そのため、/debug はAndroidアプリそのもののバグ解析というより、Claude Codeの実行環境、設定、MCP、permission、ツール実行、ログまわりの調査に向いています。
Android開発で使う場面
- Claude CodeがAndroidプロジェクトを正しく認識しない
- ./gradlew test がClaude Code経由だと失敗する
- Android SDK / JDK / Gradleのパス解決がおかしい
- MCPツールが動かない
- .claude/skills 配下のSkillが認識されない
- permission promptが多すぎる
- ファイルアクセスや実行ディレクトリがおかしい
- Claude Codeから実行したコマンドと手元のターミナル実行結果が違う
Gradle実行失敗の例
/debug Claude Codeから ./gradlew test を実行したときに失敗します。
状況:
- ターミナルで手動実行すると成功する
- Claude Codeから実行するとGradleまたはJDK関連のエラーになる
- 実行ディレクトリや環境変数に問題がある可能性があります
確認してほしいこと:
- Claude Codeの現在の作業ディレクトリ
- ./gradlew の存在場所
- JAVA_HOME
- Android SDKの参照
- Gradleの実行コマンド
- 権限やパスの問題
- Claude Codeのログ上でどこから失敗しているか
Skillが認識されない場合の例
/debug .claude/skills 配下に追加したSkillがClaude Codeで認識されません。
確認してほしいこと:
- .claude/skills の配置場所
- SKILL.md の有無
- frontmatterの形式
- Claude Codeの現在のproject root
- commands一覧に出ているか
- ログ上の読み込みエラー
MCPが動かない場合の例
/debug Claude CodeからMCPツールを呼び出したときに失敗します。
確認してほしいこと:
- MCPサーバーが認識されているか
- 設定ファイルが正しいか
- 権限エラーが出ていないか
- Claude Codeのログ上でどこで失敗しているか
- 再設定が必要か
Androidアプリのクラッシュ調査は通常プロンプトで行う
Androidアプリのクラッシュログを調査したい場合は、/debug ではなく、通常のプロンプトで依頼した方が明確です。
以下のAndroidクラッシュログと関連コードを調査してください。
目的:
- クラッシュ原因の仮説を出す
- 再現条件を整理する
- 修正候補を出す
- 影響範囲を確認する
- 必要なテスト観点を作る
制約:
- 推測は「仮説」と明記する
- 断定できない場合は「不明」と書く
- 既存挙動を変えない修正を優先する
- まず原因分析だけを出し、コード変更はしない
確認観点:
- Activity / Fragment lifecycle
- Coroutine / Flow
- NullPointerException
- IllegalStateException
- RecyclerView / Compose state
- Navigation
- DI
- release build特有のR8影響
4. /run・/verify・/run-skill-generator：実行確認の補助として使う
位置づけ
Claude CodeのSkillsドキュメントでは、アプリを起動して変更を確認するためのbundled skillsとして、/run、/verify、/run-skill-generator も紹介されています。
/run
/verify
/run-skill-generator
これらは、テストや型チェックだけでなく、実際にアプリを起動して変更を確認するためのSkillです。
/run はアプリを起動して変更が動いているか確認するために使います。
/verify は、コード変更が意図どおりに動くかを、ビルド・起動・観察によって確認するために使います。
/run-skill-generator は、/run や /verify がプロジェクトをビルド・起動するための手順を学習・記録するために使います。
Android開発で注意すべき点
Androidアプリの場合、ビルド・起動・Emulator・Gradle・JDK・Android SDK・環境変数など、プロジェクト固有の前提が多くなりがちです。
そのため、Android開発では、いきなり /run や /verify に任せるよりも、以下の情報を整えてから使う方が現実的です。
- 使用する Gradle task
- app module名
- build variant
- Emulator / 実機の前提
- minSdk / targetSdk
- JAVA_HOME
- Android SDKのパス
- Firebase設定ファイルの扱い
- debug build / release build の違い
- 社内環境でのみ必要な設定
Android向けの使い方例
/run-skill-generator このAndroidプロジェクトをビルド・起動・確認するための手順を記録してください。
前提:
- Androidアプリプロジェクトです
- Gradle wrapperを使います
- app moduleは :app です
- debug buildで確認します
- Emulatorでの起動を前提にします
記録してほしいこと:
- clean buildの手順
- test実行コマンド
- assembleDebugの実行コマンド
- Emulator起動後のインストール手順
- よく失敗するポイント
- Claude Codeが次回以降に参照できる確認手順
変更後の確認では、次のように使えます。
/verify 今回の変更で、ログイン済みユーザーの購入導線に影響がないか確認してください。
確認観点:
- アプリがビルドできること
- 対象画面まで遷移できること
- 既存の購入導線が壊れていないこと
- エラーやクラッシュが発生しないこと
- release buildに影響しそうな変更がないこと
ポイント
/run や /verify は便利ですが、Androidアプリではプロジェクト固有の起動条件が多いため、最初に実行手順を明文化しておくことが重要です。
README、Makefile、Gradle task、.claude/skills などにプロジェクト固有の手順を残しておくと、Claude Codeの再現性が上がります。
実務で使いやすい組み合わせ
実装前：影響範囲を整理する
今回の変更について、Androidアプリ開発の観点で影響範囲を整理してください。
前提:
- Kotlin中心
- Jetpack Compose / XML Viewの混在
- multi-module構成
- 既存挙動を変えない
- public APIや画面遷移仕様を不用意に変更しない
確認観点:
- 対象画面
- 対象module
- 対象ファイル
- 画面遷移への影響
- ログイン状態への影響
- 課金・購入導線への影響
- WebViewへの影響
- Firebase Analytics / Crashlyticsへの影響
- targetSdk / permission / manifestへの影響
- Gradle / AGP / Kotlin Pluginへの影響
- R8 / ProGuard / release buildへの影響
- Unit Test / UI Testで確認すべきこと
まだコードは変更しないでください。
大きい変更：/batch で分割する
/batch 今回の変更を安全に進めるため、作業を独立した単位に分割してください。
前提:
- Kotlin中心
- Jetpack Compose / XML Viewの混在
- multi-module構成
- 既存挙動を変えない
- まず調査と計画だけを出す
- すぐにコード変更しない
出力:
- 作業単位
- 対象module
- 対象画面
- 対象ファイル
- 依存関係
- リスク
- テスト観点
- 推奨順序
実装後：/code-review でレビューする
/code-review high 最近変更したKotlinファイルを確認してください。
目的:
- 既存挙動を壊す可能性がある問題を見つける
- correctness bugを検出する
- Androidアプリとしての副作用を確認する
確認観点:
- Activity / Fragment lifecycle
- Compose state
- ViewModelの責務
- Coroutine / Flow
- DI
- Repository / UseCaseの責務
- Firebase Analyticsイベントの重複
- WebViewやログイン導線への影響
- R8 / ProGuardへの影響
- テスト観点
まずレビューだけを出し、コード変更はしないでください。
起動確認：/verify を使う
/verify 今回の変更が対象画面で正しく動作するか確認してください。
前提:
- Android Emulatorで確認する
- debug buildで確認する
- 既存のログイン済み状態を前提にする
- 購入導線やWebViewに副作用がないか確認する
確認観点:
- ビルド成功
- アプリ起動
- 対象画面への遷移
- クラッシュなし
- 既存導線への副作用なし
Claude Codeが不調：/debug で調査する
/debug Claude CodeがAndroidプロジェクト内のファイルを正しく認識していないようです。
確認してほしいこと:
- 現在の作業ディレクトリ
- settings.gradle / settings.gradle.kts
- build.gradle / build.gradle.kts
- app moduleの場所
- ./gradlew の場所
- JAVA_HOME
- Android SDK
- .claude 配下の設定
- permission関連の問題
- 実行ログ上のエラー
Android開発で使うときの注意点
1. /simplify ではなく /code-review を使う
古い記事や過去の説明では /simplify と書かれている場合があります。
現在は /code-review を中心に書く方が正確です。
古い表記:
/simplify
現在の推奨表記:
/code-review
/simplify がaliasとして動く環境もありますが、記事としては /code-review に統一した方が読み手に誤解を与えにくいです。
2. いきなり修正させない
既存アプリでは、まずレビューだけにするのが安全です。
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
特に、ログイン、課金、WebView、Push通知、Deep Link / App Links、Analytics、release buildに関係する変更では、レビューと修正を分けた方が安全です。
3. Androidの前提条件を明記する
前提:
- Kotlin中心
- Jetpack Compose / XML Viewの混在
- single-module / multi-module構成
- minSdk / targetSdk / compileSdk
- Gradle / Android Gradle Plugin / Kotlin Plugin
- 既存挙動を変えない
- public APIは不用意に変更しない
Androidアプリはプロジェクト構成の差が大きいため、UI実装方式、module構成、Gradle構成、DI、非同期処理、テスト構成を明記した方が精度が上がります。
4. Compose・ViewModel・Repositoryの責務を確認する
以下の責務分離に問題がないか重点的に確認してください。
- Composable
- ViewModel
- UseCase
- Repository
- DataSource
- API client
- local DB
Android DevelopersのData layerドキュメントでは、data layerはアプリケーションデータとビジネスロジックを含む層として説明されています。
UI層にビジネスロジックが寄りすぎていないか、RepositoryがUI都合に引っ張られていないかを確認することが重要です。
5. R8 / ProGuard / release buildの影響を確認する
release buildでのみ起きそうな問題がないか確認してください。
確認観点:
- R8
- ProGuard keep rule
- reflection
- JSON serialization / deserialization
- DI framework
- WebView JavaScript interface
- Firebase / Crashlytics
- 外部SDK
- 難読化後クラッシュログ
R8はアプリのサイズや実行時性能の最適化に関係しますが、reflectionやserialization、DI、外部SDKの扱いによってはrelease build特有の問題につながる場合があります。
6. 署名・リリース設定は慎重に扱う
署名・リリース設定に影響する変更がないか確認してください。
確認観点:
- release buildType
- signingConfig
- keystore情報
- Play App Signing
- CI上のsecret管理
- versionCode / versionName
- minifyEnabled / shrinkResources
Androidアプリは、インストールまたは更新前に証明書で署名されている必要があります。
リリース設定や署名設定を扱う場合は、まずレビューと確認項目の整理だけにする方が安全です。
7. テスト観点まで出させる
最後に、確認すべきUnit Test / UI Test / 手動確認観点を出してください。
Androidアプリの場合、特に以下の観点が重要です。
- ログイン済み / 未ログイン
- 通信成功 / 通信失敗
- 初回起動 / 通常起動
- 画面回転
- プロセス再生成
- ダークテーマ / ライトテーマ
- フォントサイズ変更
- TalkBack
- Push通知経由の起動
- Deep Link / App Links経由の起動
- WebView内リンクタップ
- 課金・購入導線
- release buildのみで発生するR8影響
8. 事実・仮説・不明点を分けさせる
事実、仮説、不明点を分けて出してください。
推測は「仮説」と明記してください。
ログやコードから確認できないことは断定しないでください。
AIの出力では、事実と推測が混ざることがあります。
チーム共有やPRレビューに使う場合も、この指定は有効です。
まとめ
Claude Codeの標準Skillは、単なる固定処理を実行するコマンドではありません。
Claudeに標準化された作業手順を渡し、Claude Code上のツール操作を含めて作業を進めるための仕組みです。
最新の状況を踏まえると、Androidアプリ開発では以下の使い分けが実用的です。
/code-review
- 実装後の差分レビュー
- correctness bugの検出
- PR前の確認
/batch
- 大規模変更の分割
- 影響範囲調査
- 作業単位と実施順序の整理
/debug
- Claude Code側の不調調査
- MCP、設定、ログ、permission、Gradle実行まわりの確認
/run / verify / run-skill-generator
- アプリ起動や変更確認の補助
- Androidではプロジェクト固有の起動手順を先に整えると効果的
Androidエンジニアが最初に使うなら、まずは以下の2つから始めるのが実用的です。
/code-review
/batch
/code-review は実装後のバグ検出や差分レビューに、/batch は大きな変更を安全に分割する用途に向いています。
そして、Claude Code自体の挙動が不安定なときは /debug を使い、ビルドや起動確認までClaude Codeに任せたい場合は /run、/verify、/run-skill-generator を検討するとよいです。
重要なのは、単にSkill名を入力することではありません。
以下のような Android開発固有の前提条件 を明示することです。
- Kotlin / Java
- Jetpack Compose / XML View
- minSdk / targetSdk / compileSdk
- Gradle / Android Gradle Plugin / Kotlin Plugin
- single-module / multi-module構成
- Coroutine / Flow
- Hilt / Dagger / Koin
- Repository / UseCase / DataSource
- Firebase Analytics / Crashlytics
- R8 / ProGuard
- Play App Signing
- 既存挙動を変えない
- まずレビューだけ
- 事実・仮説・不明点を分ける
- テスト観点まで出す
Claude Code標準Skillは、うまく使えば単なるコード生成ツールではなく、設計レビュー、影響範囲調査、差分レビュー、実行確認、Claude Code自体の不調調査まで支援する開発パートナーとして活用できます。
参考リンク
- Claude Code Changelog
- Extend Claude with skills - Claude Code Docs
- Commands - Claude Code Docs
- Guide to app architecture - Android Developers
- Compose UI Architecture - Android Developers
- Enable app optimization with R8 - Android Developers
- Sign your app - Android Developers
このシリーズの歩き方
Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。
- ◀ 前の記事: 電子書籍アプリ開発で考える Claude Code の
/goalコマンド入門：AI に「完了条件」まで進めてもらう - ▶ 次の記事: 1体AIレビューを6体チームに分割：Claude Codeで作る責務分割型コードレビュー【テンプレ全公開】
- 🔍 あわせて読む: Claude Codeは「コードを書くAI」で終わらせるな：公式 document-skills でPDF・Excel・Word・PowerPointまで自動化する ― 標準Skillの次は公式document-skills
- 🗺 シリーズ全記事の地図(親記事)