はじめに
Claude Codeには、標準でいくつかの bundled skills が用意されています。
Claude Code公式ドキュメントのSkillsページでは、Claude Codeに /simplify、/batch、/debug、/loop、/claude-api などのbundled skillsが含まれると説明されています。また、bundled skillsは、多くの組み込みコマンドのように固定ロジックを直接実行するものではなく、prompt-based にClaudeへ詳細なplaybookを渡し、Claudeがツールを使いながら作業を進めるものだと説明されています。
ただし、iOSアプリ開発の記事として考えると、すべてを同じ重さで扱う必要はありません。
この記事では、iOSアプリ開発で特に使いやすい以下の3つに絞って整理します。
/simplify/batch/debug
特に、iOSエンジニアが最初に使うなら、まずは以下の2つが実用的です。
/simplify
/batch
/simplify は実装後のコード品質チェックに、/batch は大きな変更を安全に分割する用途に向いています。
公式ドキュメント上の根拠
Claude CodeのSkillsドキュメントでは、Skillは SKILL.md に書かれた指示をClaudeのツールキットに追加する仕組みとして説明されています。Claudeは必要に応じてSkillを使うことも、ユーザーが /skill-name の形で直接呼び出すこともできます。
また、Claude CodeのSlash commandsドキュメントでは、Slash commandsとAgent Skillsの違いも説明されています。Slash commandsは単一ファイルの簡単なプロンプトに向き、Skillsは複数ファイル・スクリプト・標準化された複雑なワークフローに向く、と整理されています。
このため、bundled skillsは「固定された処理を機械的に実行するコマンド」というより、Claudeに作業手順を渡して、Claude Code上のツール操作を含めて実行させるための標準ワークフローと理解すると実務で使いやすくなります。
iOSアプリ開発での基本方針
iOSアプリ開発でClaude Code標準Skillを使う場合、重要なのはSkill名そのものよりも、渡す前提条件の具体性です。
iOSアプリには、WebやAndroidとは異なる固有の確認観点があります。
- Deployment Target
- UIKit / SwiftUI のどちらが中心か
- Swift / Objective-C混在か
- Storyboard / Xib / Programmatic UI のどれを使っているか
- WKWebViewを使っているか
- Firebase Analytics / Crashlyticsを使っているか
- Push通知、Deep Link、Universal Linksがあるか
- 認証、課金、購入、会員登録など副作用の大きい導線があるか
- App Store審査やPrivacy Manifestに影響する変更か
たとえば、単に次のように入力するだけでは、Claudeは一般的なコード改善として判断します。
/simplify
iOSアプリ開発では、以下のように前提条件を付けた方が実用的です。
/simplify iOS 15以上を前提に、最近変更したSwift/Objective-Cコードを保守性・副作用・既存挙動維持の観点でレビューしてください
1. /simplify：実装後のコード品質チェックに使う
/simplify の位置づけ
Claude Code公式ドキュメントのSkillsページでは、/simplify はbundled skillsの1つとして挙げられています。bundled skillsは、Claudeに詳細なplaybookを渡して、Claudeがツールを使いながら作業を進めるものとして説明されています。
iOSアプリ開発では、/simplify は 実装後のセルフコードレビュー に向いています。
iOS開発で使う場面
/simplify は、以下のような場面で有効です。
- ViewControllerが肥大化した
- SwiftUI Viewのbodyが複雑になった
- Optional処理が読みにくい
- 同じような分岐処理が複数箇所にある
- Objective-CとSwiftの橋渡し部分を整理したい
- Firebase Analyticsイベント送信処理が散らばっている
- WKWebViewやログイン処理を修正した後に副作用を確認したい
- 非同期処理やMainActorまわりの安全性を確認したい
そのまま使えるプロンプト例
/simplify 最近変更したSwift/Objective-Cファイルをレビューしてください。
前提:
- iOS 15以上を対象にする
- UIKitベースの既存アプリ
- Swift / Objective-Cが混在している
- 既存挙動は変えない
- public interfaceは不用意に変更しない
- まだコードは変更しない
確認観点:
- 重複コード
- ViewControllerの責務過多
- Optionalの安全性
- Main Thread / MainActorでのUI更新
- 非同期処理のキャンセル漏れ
- メモリリークの可能性
- delegate / closureの循環参照
- 命名のわかりやすさ
- テストで担保すべき観点
出力形式:
- 対象ファイル
- 問題箇所
- 問題の理由
- 影響範囲
- 修正方針
- 優先度: High / Medium / Low
ViewController向けの例
/simplify UserProfileViewController.swiftを中心に、最近変更したコードをレビューしてください。
目的:
- ViewControllerの責務を整理する
- 表示ロジック、API呼び出し、画面遷移処理が混ざっていないか確認する
- 既存挙動を変えずに、読みやすくできる箇所を提案する
制約:
- まだコードは変更しない
- UIKit前提
- iOS 15以上前提
- 大規模なアーキテクチャ変更は提案だけにする
- 小さく安全に直せる改善を優先する
SwiftUI向けの例
/simplify ProductListView.swiftを確認してください。
目的:
- SwiftUIのbodyが複雑になっていないか確認する
- Viewの分割候補を提案する
- 状態管理がViewに寄りすぎていないか確認する
確認観点:
- Viewの分割候補
- State / Binding / ObservableObjectの責務
- 非同期処理の扱い
- 再描画が増えそうな箇所
- Previewしやすい構造か
- UI Testで確認しやすい構造か
制約:
- 既存UIの見た目は変えない
- 既存の画面遷移は変えない
- まずレビュー結果だけを出す
- 修正案は小さな単位に分ける
Analyticsイベント追加後の例
/simplify 最近追加したAnalyticsイベント送信処理をレビューしてください。
確認観点:
- 同じイベント送信処理が重複していないか
- イベント名やパラメータ名に揺れがないか
- 個人情報に該当しうる値を送っていないか
- 画面表示時とタップ時の送信タイミングが混ざっていないか
- テストしやすい設計になっているか
制約:
- 既存の計測仕様を変えない
- 不明点は推測で断定せず、確認事項として出す
ポイント
既存アプリでは、いきなり修正させるよりも、まずレビューだけにするのが安全です。
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
この一文を入れるだけで、実務投入しやすくなります。
2. /batch：大規模変更を安全に分割する
/batch の位置づけ
Claude Code公式ドキュメントのSkillsページでは、/batch もbundled skillsの1つとして挙げられています。bundled skillsは、ユーザーが /skill-name の形で直接呼び出せると説明されています。
iOSアプリ開発では、/batch は、複数画面・複数ファイル・複数導線にまたがる変更を安全に分割する用途に向いています。
iOS開発で使う場面
- ダークモード対応
- deprecated APIの置換
- Objective-CからSwiftへの段階移行
- UIKit画面の一部SwiftUI化
- WKWebView処理の共通化
- Analyticsイベント設計の整理
- Firebase Crashlyticsログ方針の整理
- App Store審査やPrivacy Manifestに関係する修正
- 複数画面にまたがるUI改修
ダークモード対応の例
/batch iOSアプリのダークモード対応を安全に進めるため、影響範囲を調査して作業単位に分割してください。
前提:
- iOS 15以上
- UIKitベースの既存アプリ
- Swift / Objective-Cが混在している
- 既存の画面遷移や表示仕様は変えない
- まず調査と分割計画だけを出す
- まだコード変更はしない
確認観点:
- ハードコードされた色
- UIColorの直接指定
- Asset CatalogのColor Set化候補
- Storyboard / Xib内の色指定
- NavigationBar / TabBar / Toolbarの見え方
- WKWebViewを含む画面の背景色
- 画像アセットの視認性
- Dynamic Typeやアクセシビリティへの影響
出力形式:
## 作業分割案
1. 対象領域
2. 対象ファイル
3. 修正方針
4. リスク
5. テスト観点
6. 推奨する実施順序
Objective-CからSwiftへの段階移行の例
/batch Objective-Cで実装されている一部のユーティリティ処理をSwiftへ段階移行する計画を作ってください。
前提:
- 既存アプリはObjective-CとSwiftが混在している
- 一度に大きく移行しない
- 既存のpublic APIをできるだけ維持する
- まず調査と分割計画だけを出す
- まだコード変更はしない
確認観点:
- Swift化しやすいクラス
- 依存関係が少ないファイル
- Objective-Cから参照されている箇所
- Bridging Headerへの影響
- Unit Testを先に用意すべき箇所
- 移行後のリグレッションリスク
WKWebView処理の共通化の例
/batch アプリ内のWKWebView関連処理を調査し、共通化できる箇所を作業単位に分割してください。
前提:
- 既存挙動を変えない
- ログイン、外部ブラウザ遷移、Cookie、JavaScript連携への影響を重視する
- まず調査結果と作業分割だけを出す
- まだコード変更はしない
確認観点:
- navigationDelegateの重複
- target="_blank" 相当の処理
- 外部ブラウザへ逃がすURL判定
- Cookieやセッションの扱い
- JavaScript bridgeの安全性
- エラー画面表示
- ローディング表示
- テスト観点
Privacy Manifest対応の例
/batch Privacy ManifestやRequired Reason APIに影響しそうな変更を調査し、確認作業を分割してください。
前提:
- iOSアプリのリリース前確認
- 追加SDKや新規API利用がある可能性がある
- まず調査と確認項目の整理だけを行う
- まだ設定ファイルは変更しない
確認観点:
- Required Reason APIに該当するAPI利用
- PrivacyInfo.xcprivacyの更新要否
- 追加SDKのPrivacy Manifest対応状況
- Firebaseなど外部SDKの影響
- App Store審査で説明が必要になりそうな変更
- リリース前に確認すべき項目
ポイント
/batch は小さな修正よりも、影響範囲が広い変更を分解する用途に向いています。
1ファイルだけの軽微な修正であれば、通常のプロンプトや /simplify の方が扱いやすいです。
3. /debug：iOSアプリのデバッグではなく、Claude Code側の不調調査に使う
/debug の位置づけ
Claude Code公式ドキュメントのSkillsページでは、/debug もbundled skillsの1つとして挙げられています。
名前だけを見ると、iOSアプリのクラッシュ調査に使うものだと思うかもしれません。
ただし、実務上は、/debug はiOSアプリのクラッシュ解析そのものというより、Claude Codeのセッション、設定、MCP、ツール実行がうまく動かないときの調査に使うものと考える方が自然です。
iOS開発で使う場面
- Claude CodeがXcodeプロジェクトを正しく認識しない
- xcodebuildの実行結果を正しく読めていない
- MCPツールが動かない
- .claude/skills 配下のSkillが認識されない
- permission promptが多すぎる
- ファイルアクセスやパス解決がおかしい
xcodebuild実行失敗の例
/debug Claude Codeからxcodebuild testを実行したときに失敗します。
状況:
- ターミナルで手動実行すると成功する
- Claude Codeから実行するとschemeが見つからないと言われる
- workspaceまたはschemeの指定に問題がある可能性があります
確認してほしいこと:
- Claude Codeの現在の作業ディレクトリ
- 利用しているworkspace / project
- scheme指定
- 実行コマンド
- 権限やパスの問題
- 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のログ上でどこで失敗しているか
- 再設定が必要か
iOSアプリのクラッシュ調査は通常プロンプトで行う
iOSアプリのクラッシュログを調査したい場合は、/debug ではなく、通常のプロンプトで依頼した方が明確です。
以下のiOSクラッシュログと関連コードを調査してください。
目的:
- クラッシュ原因の仮説を出す
- 再現条件を整理する
- 修正候補を出す
- 影響範囲を確認する
- 必要なテスト観点を作る
制約:
- 推測は「仮説」と明記する
- 断定できない場合は「不明」と書く
- 既存挙動を変えない修正を優先する
- まず原因分析だけを出し、コード変更はしない
確認観点:
- Optional unwrap
- delegate / dataSource
- async / await
- MainActor
- UIViewController lifecycle
- WKWebView
- Firebase Crashlytics
- release build特有の挙動
実務で使いやすい組み合わせ
実装前：影響範囲を整理する
今回の変更について、iOSアプリ開発の観点で影響範囲を整理してください。
前提:
- iOS 15以上
- UIKitベース
- Swift / Objective-C混在
- 既存挙動を変えない
- public APIや画面遷移仕様を不用意に変更しない
確認観点:
- 対象画面
- 対象ファイル
- 画面遷移への影響
- ログイン状態への影響
- 課金・購入導線への影響
- WKWebViewへの影響
- Firebase Analytics / Crashlyticsへの影響
- App Store審査やPrivacy Manifestへの影響
- Unit Test / UI Testで確認すべきこと
まだコードは変更しないでください。
大きい変更：/batch で分割する
/batch 今回の変更を安全に進めるため、作業を独立した単位に分割してください。
前提:
- iOS 15以上
- UIKitベース
- Swift / Objective-C混在
- 既存挙動を変えない
- まず調査と計画だけを出す
- すぐにコード変更しない
出力:
- 作業単位
- 対象画面
- 対象ファイル
- 依存関係
- リスク
- テスト観点
- 推奨順序
実装後：/simplify でレビューする
/simplify 最近変更したSwift/Objective-Cファイルを確認してください。
目的:
- 既存挙動を変えずに保守性を上げる
- 重複や責務過多を見つける
- iOSアプリとしての副作用を確認する
確認観点:
- Main Thread / MainActorでのUI更新
- Optionalの安全性
- delegate / closureの循環参照
- 非同期処理
- ViewControllerの責務
- Analyticsイベントの重複
- WKWebViewやログイン導線への影響
- テスト観点
まずレビューだけを出し、コード変更はしないでください。
Claude Codeが不調：/debug で調査する
/debug Claude CodeがiOSプロジェクト内のファイルを正しく認識していないようです。
確認してほしいこと:
- 現在の作業ディレクトリ
- .xcodeproj / .xcworkspace の場所
- scheme一覧
- .claude 配下の設定
- permission関連の問題
- xcodebuild実行時のパス
- 実行ログ上のエラー
iOS開発で使うときの注意点
1. いきなり修正させない
既存アプリでは、まずレビューだけにするのが安全です。
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
2. iOSの前提条件を明記する
前提:
- iOS 15以上
- UIKit / SwiftUI
- Swift / Objective-C混在
- Storyboard / Xib / Programmatic UI
- 既存挙動を変えない
- public APIは不用意に変更しない
iOSアプリはプロジェクト構成の差が大きいため、Deployment Target、UI実装方式、Swift / Objective-C混在の有無、テスト構成を明記した方が精度が上がります。
3. WebView・認証・課金導線は重点確認する
以下の導線に影響がないか重点的に確認してください。
- WKWebView
- ログイン
- 会員登録
- 課金・購入
- Push通知
- Deep Link / Universal Links
- Firebase Analytics / Crashlytics
これらは、1ファイルの修正でもユーザー体験、売上、ログイン状態、計測、審査に影響する可能性があります。
4. Privacy ManifestやRequired Reason APIも確認する
App Store審査やPrivacy Manifestに影響する変更がないか確認してください。
確認観点:
- Required Reason API
- Privacy Manifest
- 追加SDK
- トラッキング関連
- Firebaseなど外部SDKの利用
- App Store審査で説明が必要になりそうな変更
5. テスト観点まで出させる
最後に、確認すべきUnit Test / UI Test / 手動確認観点を出してください。
iOSアプリの場合、特に以下の観点が重要です。
- ログイン済み / 未ログイン
- 通信成功 / 通信失敗
- 初回起動 / 通常起動
- ライトモード / ダークモード
- Dynamic Type
- 端末回転
- Push通知経由の起動
- Deep Link経由の起動
- WKWebView内リンクタップ
- 課金・購入導線
6. 事実・仮説・不明点を分けさせる
事実、仮説、不明点を分けて出してください。
推測は「仮説」と明記してください。
ログやコードから確認できないことは断定しないでください。
AIの出力では、事実と推測が混ざることがあります。チーム共有やPRレビューに使う場合も、この指定は有効です。
まとめ
Claude Codeの標準Skillは、公式ドキュメント上でも、通常の固定ロジックを実行するだけのコマンドとは区別されています。
Claude Code公式ドキュメントのSkillsページでは、bundled skillsはprompt-basedであり、Claudeに詳細なplaybookを渡して、Claudeがツールを使いながら作業を進めるものとして説明されています。
iOSアプリ開発で重要なのは、単に /simplify や /batch を実行することではありません。
重要なのは、以下のような iOS開発固有の前提条件 を明示することです。
- iOS 15以上
- UIKit / SwiftUI
- Swift / Objective-C混在
- Storyboard / Xib / Programmatic UI
- WKWebView
- Firebase Analytics / Crashlytics
- Push通知
- Deep Link / Universal Links
- App Store審査
- Privacy Manifest
- 既存挙動を変えない
- まずレビューだけ
- 事実・仮説・不明点を分ける
- テスト観点まで出す
Claude Code標準Skillは、うまく使えば単なるコード生成ツールではなく、
設計レビュー、影響範囲調査、リファクタリング計画、Claude Code自体の不調調査まで支援する開発パートナーとして活用できます。
iOSエンジニアが最初に使うなら、まずは以下の2つから始めるのが実用的です。
/simplify
/batch
/simplify は実装後のコード品質チェックに、/batch は大きな変更を安全に分割する用途に向いています。
/debug はClaude CodeやMCP、xcodebuild実行まわりの不調調査に使うのが現実的です。