結論：モバイルアプリの審査前QAでClaude Codeを使うなら、AIに「テストを全部任せる」のではなく、リリース差分、ログ、権限、ストア審査メモ、CI結果を同じ文脈で読み合わせるレビュー補助として設計するのが安全です。
- 対象読者：iOS/Androidアプリを運用するエンジニア、QA担当、EM、PM。
- 事例区分：想定シナリオ。実在企業の成果ではなく、典型的なリリース前QAフローをモデル化しています。
- この記事でできること：Claude Codeの権限設計、CLAUDE.md、Hooks、GitHub Actions、MCPを使った審査前チェックリストを作れます。
「リリース候補版は通ったのに、ストア審査や本番配信後に権限まわりの見落としが出る」——モバイルアプリ開発では、こういう地味な事故が一番つらいですよね。ユニットテストやE2Eだけでは拾いきれない、設定ファイル、依存関係、権限説明文、ログ出力、Feature Flag、CIの警告がバラバラに存在するからです。
Claude Codeは、公式ドキュメント上でも「コードベースを理解し、ファイル編集、コマンド実行、開発ツール連携を行うAI-powered coding assistant」と説明されています。つまり、単なるチャットではなく、リポジトリ全体の文脈とローカル/CIの実行結果をまとめて扱えるのが強みです。
ただし、審査前QAでいきなり自動修正まで許可すると危険です。公式のSecurityページでも、Claude Codeは初期状態でread-onlyを基本にし、編集やコマンド実行など追加操作には明示的な許可を求めるpermission-based architectureだと説明されています。この記事では、その前提を崩さず「レビューは広く、実行権限は狭く」設計する想定モデルを整理します。
関連する考え方として、運用インシデント側の型はSaaS障害対応をClaude Codeで標準化する5手順、レビュー品質の標準化はデータ基盤のSQLレビューをClaude Codeで標準化する5手順でも扱っています。今回はモバイルアプリのリリース判定に絞ります。
想定シナリオ：審査前QAが属人化したモバイル開発チーム
事例区分：想定シナリオ。以下は実在企業の成果ではなく、アプリ開発現場でよくある構成をもとにしたモデルケースです。数値は効果保証ではなく、運用設計を説明するための試算・想定です。
対象は、iOS/Androidアプリを毎月リリースするSaaS・IT企業のモバイルチームです。React Native、Flutter、Swift/Kotlinのいずれでも考え方は同じですが、ここでは「モバイルアプリのリリースブランチを切ったあと、審査前に複数人で確認する」状態を想定します。
- リリース担当が毎回、変更差分、権限、文言、ストア申請メモを手作業で確認している。
- QA担当はテストケース表を見るが、Git差分やCI警告までは追いきれない。
- エンジニアはログやクラッシュレポートを見るが、App Store / Google Play の説明文までは最後に確認しがち。
- セキュリティレビューは重要だが、毎回フルレビューするほどの時間はない。
- 過去の審査リジェクト理由がSlackやIssueに散らばり、次回リリース時に再利用されにくい。
Claude Codeをここに入れる狙いは、QA担当者を置き換えることではありません。リリース担当が見るべき材料をClaude Codeに集約し、「見落としやすい観点」をPull Request、リリースノート、設定ファイル、CIログから抽出させることです。
想定上の目標は、リリース前の確認観点を「担当者の記憶」から「リポジトリ内のルールと自動レビュー」に移すことです。これにより、属人化したチェックリストを減らし、新任メンバーでも同じ観点でリリース判定に参加できる状態を作ります。
Claude Codeに任せる範囲と任せない範囲
最初に決めるべきなのは、Claude Codeに「何をさせるか」より「何をさせないか」です。モバイルアプリの審査前QAでは、ストア申請、証明書、署名鍵、個人情報、課金、医療・金融情報など、扱いを誤ると影響が大きい領域があります。
公式Securityページの考え方に沿うなら、最初の導入はread-onlyレビュー中心が無難です。コード編集やコマンド実行は便利ですが、審査直前のブランチで無制限に許可すると、意図しない変更やビルド成果物の差し替えが起きても気づきにくくなります。
- 任せる：Pull Request差分から、権限・ログ・例外処理・Feature Flagの変更点を抽出する。
- 任せる：審査チェックリストと差分を照合し、未確認項目を列挙する。
- 任せる：CIログ、lint、型チェック、テスト失敗の要約を作る。
- 任せる：リリースノート、ストア申請文、社内告知文の整合性を見る。
- 任せない：署名鍵、秘密情報、課金設定、ストア公開操作を自動実行する。
- 任せない：人間の承認なしに審査提出、タグ作成、production向け配信を行う。
この線引きは地味ですが、導入初期ほど重要です。Claude Codeはツール連携が強いぶん、便利さに寄せると権限が広がりやすい。逆に、最初から「読む、要約する、差分を指摘する」役割に限定すれば、チームの心理的抵抗も下がります。
Claude CodeのCLI referenceには、--allowedTools、--disallowedTools、--tools、--permission-modeなど、利用可能なツールや許可モードを制御するフラグが掲載されています。審査前QAでは、便利な--dangerously-skip-permissionsのようなバイパス系は原則使わず、明示許可ベースで始めるのが安全です。
実装ステップ1：CLAUDE.mdで審査前QAの基準を固定する
Claude Code overviewでは、プロジェクトルートに置くCLAUDE.mdを、コーディング標準、アーキテクチャ判断、推奨ライブラリ、レビュー観点を伝えるファイルとして説明しています。モバイルQAでは、このファイルを「審査前レビューの憲法」にします。
ポイントは、抽象的な「安全にレビューして」ではなく、モバイル特有のチェック観点を箇条書きで固定することです。たとえば次のように、ストア審査、権限、ログ、個人情報、Feature Flag、バックエンドAPI互換性を分けて書きます。
# CLAUDE.md 抜粋：mobile-release-review
あなたはモバイルアプリのリリース前QAレビュアーです。
リリース候補ブランチでは、以下を必ず確認してください。
1. iOS/Androidの権限説明文が、実際の機能差分と矛盾していないか
2. 個人情報・位置情報・課金・医療/金融に関わる変更がある場合、必ず「人間確認必須」と明記する
3. debugログ、個人情報を含むログ、不要なconsole出力が残っていないか
4. Feature Flagのデフォルト値と、既存ユーザーへの影響を確認する
5. APIレスポンス変更が古いアプリバージョンに影響しないか確認する
6. 審査提出、署名、production配信は実行しない。必要なら手順だけ提示する
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。このCLAUDE.mdを置くと、レビューのたびに「何を見ればいいか」を口頭で説明する必要が減ります。特に、リリース担当が変わった時や、外部パートナーが参加する時に効きます。
注意点は、CLAUDE.mdに秘密情報や本番鍵を貼らないことです。Claude Codeに限らず、リポジトリに置く指示ファイルはチームで共有される前提で書きます。権限や秘密情報の扱いは、設定ファイル、環境変数、シークレット管理のルール側で分離しましょう。
実装ステップ2：CLIの権限をレビュー用途に絞る
次に、Claude Codeを起動する時の権限を絞ります。公式CLI referenceでは、--allowedToolsは許可なしで実行できるツールを指定するもの、--disallowedToolsは拒否ルールを指定するものとして説明されています。ここでは、最初から編集や破壊的コマンドを許可しない運用にします。
# 例：審査前QA用の起動イメージ
claude --permission-mode plan --allowedTools "Bash(git diff *)" "Bash(git log *)" "Bash(git status *)" --disallowedTools "Bash(rm *)" "Bash(git push *)" "Bash(fastlane deliver *)" "Bash(bundle exec fastlane release *)" --append-system-prompt "審査提出・署名・production配信は実行せず、必要な手順とリスクだけを提示してください。"上記は概念例です。実際の許可構文やチームの運用は、公式Settings/Permissionsドキュメントと自社のセキュリティポリシーに合わせて調整します。大事なのは、レビュー時に必要なgit diffやgit logは読める一方で、公開・配信・削除・push系は明示的に止めることです。
また、Claude Codeの設定はグローバルとプロジェクトレベルで管理できます。公式Settingsページでは、settings.jsonや権限設定、環境変数による設定が扱われています。個人の便利設定と、チームで守るべき審査前QA設定は混ぜない方が運用しやすいです。
審査直前ブランチでは、「便利だから」と自動承認を増やしすぎないのがコツです。AIレビューは速いですが、モバイル公開は一度ストアへ提出すると巻き戻しに時間がかかります。速さより、再現性と説明責任を優先します。
実装ステップ3：リリース差分レビューのプロンプトを標準化する
審査前QAの中心は、リリース差分レビューです。Claude Codeには、単に「レビューして」ではなく、出力形式とリスク分類を固定して依頼します。これにより、QA担当、PM、エンジニアが同じフォーマットで判断できます。
リリース候補ブランチの差分をレビューしてください。
対象：main..release/2026-06-xx
出力形式：
1. 変更概要（非エンジニアにも分かる表現）
2. ストア審査に影響しそうな変更
3. 権限・個人情報・課金・位置情報に関わる変更
4. 既存ユーザーへの互換性リスク
5. ログ・クラッシュ・監視に関する確認事項
6. 人間が必ず確認すべき項目
制約：
- 審査提出や本番配信は実行しない
- 数字と固有名詞は、根拠となるファイルパスや差分を添える
- 不足している情報があれば、最初に質問してから作業を開始してください
- 仮定した点は必ず「仮定」と明記してくださいこのプロンプトの良いところは、「AIが何を見たか」が残ることです。リリース後に問題が起きた場合も、当時の差分、判断、未確認項目を追いやすくなります。
さらに、差分レビューは1回で終わらせず、QA指摘後の修正差分にも同じプロンプトをかけます。初回レビューで見つかった問題が、修正によって別の問題を生んでいないかを見るためです。
想定モデルでは、レビュー対象を「全コード」ではなく「今回のリリース差分」に絞ります。全コードを毎回見せると、重要度の低い指摘が増え、リリース判定が重くなります。差分、設定、ログ、ストア申請文という審査前に関係する材料へ絞ると、出力が実務で使いやすくなります。
実装ステップ4：Hooksでレビュー前後の機械チェックを挟む
Claude CodeのHooksは、ファイル編集後やタスク完了時などのタイミングでシェルコマンドを自動実行できる仕組みとして公式ドキュメントに説明されています。審査前QAでは、Claude Codeの文章レビューと機械的なlint/testを分けて考えます。
たとえば、レビュー前に必ず依存関係の状態、型チェック、lint、テストを走らせ、その結果をClaude Codeに読ませます。AIの主観レビューだけではなく、実行結果を根拠にするためです。
# Hooksで実行するチェックの例（概念）
npm run lint
npm run typecheck
npm test -- --runInBand
bundle exec fastlane ios beta --dry_run
bundle exec fastlane android internal --dry_runここで重要なのは、dry runや検証系に限定することです。fastlaneやストア連携は強力なので、実際のアップロード、審査提出、production配信はHooksから外します。Claude Codeのレビュー結果に「人間確認必須」と出た項目を見て、担当者が手動で判断する流れにします。
Hooksのもう一つの使い道は、禁止コマンドの検知です。たとえばreleaseブランチでは、特定の配信コマンドや鍵ファイル操作が出たら止める、といったガードを置けます。Claude Code側の権限設定と、CI/Hooks側の機械的ガードを二重にしておくと安心です。
ただし、Hooksに複雑な業務判断を入れすぎると、メンテナンスできなくなります。最初は「lint/test/dry-run/禁止コマンド検知」の4つに絞り、レビュー観点はCLAUDE.mdとプロンプトに寄せるのが現実的です。
実装ステップ5：GitHub ActionsでPRレビューを半自動化する
Claude CodeはGitHub Actions連携の公式ドキュメントも用意されています。モバイルチームでは、リリースPRやhotfix PRが作られたタイミングで、Claude Codeにレビュー要約を作らせると効果が出やすいです。
やることはシンプルです。releaseラベルが付いたPR、またはrelease/*ブランチへのPRだけを対象にし、Claude Codeに審査前QA観点でコメントさせます。全PRに広げるとノイズが増えるため、最初はリリース前の高リスクPRに限定します。
# GitHub Actionsでの指示イメージ（概念）
name: mobile-release-review
on:
pull_request:
branches: ["release/**"]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: |
npm ci
npm run lint
npm test -- --runInBand
- name: Claude Code review
run: |
claude -p "このPRをモバイル審査前QAの観点でレビューしてください。権限、個人情報、ログ、Feature Flag、互換性、ストア申請文の未確認項目を分類してください。"上記はあくまで構成例です。実際の認証、secret管理、Claude Codeの実行方法は公式GitHub Actionsドキュメントと自社のCIポリシーに合わせます。CIに秘密情報を置く場合は、ログへ出ないこと、fork PRから参照できないこと、最小権限であることを必ず確認してください。
PRコメントで便利なのは、PMやQA担当がGit差分を読まなくても、リスク分類だけ先に把握できる点です。「今回、位置情報の説明文変更あり」「Android 13以降の通知権限に影響の可能性あり」「古いAPIレスポンスとの互換性を確認」など、判断の入口を作れます。
CI/CD観点でさらに踏み込みたい場合は、CI/CD自動修復をClaude Codeで実装する5手順も参考になります。モバイルでは自動修復よりも、審査前の差分説明と人間承認の設計を優先するのがおすすめです。
実装ステップ6：MCPでJira・Sentry・Firebaseを読む設計にする
Claude Code overviewでは、MCPを外部データソースへ接続するオープン標準として説明し、Google Drive、Jira、Slack、自社ツールなどとの接続例に触れています。モバイルQAでは、Jira、Sentry、Firebase Crashlytics、Datadog、ストア申請メモなどを「読む」用途でつなぐと便利です。
ただし、MCPは便利なぶん、接続先を増やしすぎると情報漏えいリスクや誤操作リスクも増えます。最初はread-onlyで、対象プロジェクト、対象Issue、対象リリースだけに絞るのが安全です。
- Jira/Linear：今回リリースに含まれるIssue一覧、未完了タスク、QAブロッカーを読む。
- Sentry/Crashlytics：直近バージョンのクラッシュ傾向、既知の高頻度エラーを読む。
- Firebase Remote Config：Feature Flagや段階配信設定の確認メモを読む。
- Google Drive/Notion：ストア審査チェックリスト、過去リジェクト理由、運用手順を読む。
- Slack：リリース判断の会話を読む場合は、チャンネルと期間を限定し、個人DMは対象外にする。
MCPで重要なのは、Claude Codeが「どの情報を根拠にしたか」を出力させることです。審査前QAでは、根拠のない断定が一番危険です。ファイルパス、Issue ID、CIジョブ名、Crashlyticsのイベント名など、追跡可能な単位で書かせます。
MCPで取得した情報を使って、リリース判定メモを作ってください。
必ず以下を守ってください。
- 根拠ごとに、参照元（Issue、CIジョブ、ログ、ファイルパス）を明記する
- 個人情報や秘密情報は本文に貼らない
- 確認できない点は「未確認」として残す
- リリース可否は断定せず、人間が判断すべき条件を整理するこの形にすると、Claude Codeは単なる「賢い要約」ではなく、リリース判定会議の下準備役になります。最終判断者は人間のままですが、見るべき材料を集める時間を減らせます。
【要注意】よくある失敗パターンと回避策
失敗1：Claude Codeに審査提出まで任せる
❌「問題なさそうならApp Store Connectに提出して」
⭕「審査提出前の未確認項目を分類し、提出操作は人間が行う」
審査提出やproduction配信は、AIが便利でも自動化の最後に置くべきではありません。特に初期導入では、Claude Codeはレビュー、要約、手順提示に限定し、提出操作は担当者が行います。
失敗2：権限設定を個人任せにする
❌「各エンジニアが好きな設定でClaude Codeを使う」
⭕「releaseブランチ用の設定、禁止コマンド、CLAUDE.mdをチームで固定する」
Claude Codeは個人開発では自由度が高いほど便利ですが、業務導入では再現性が大事です。誰が実行しても同じ観点でレビューされるように、設定とプロンプトをリポジトリ側へ寄せます。
失敗3：AIの指摘をそのままリリース判定に使う
❌「Claude CodeがOKと言ったのでリリース」
⭕「Claude Codeの出力を、QA担当・リリース責任者・エンジニアの確認リストに変換する」
Claude Codeは強力ですが、最終判断者ではありません。公式ドキュメントにもあるように、ツール実行や権限にはユーザーの承認が関わります。業務導入では、その思想をリリース判定にも適用します。
失敗4：外部ツール連携を最初から広げすぎる
❌「Jira、Slack、Drive、Sentry、Firebase、本番DBを全部つなぐ」
⭕「最初はJiraとCIログだけ。read-onlyで対象プロジェクトを限定する」
MCP連携は価値が大きい一方、接続範囲が広いほど監査が難しくなります。最初は読み取り専用、対象リリース限定、ログに秘密情報を出さない、の3条件を守るのが現実的です。
導入ロードマップ：3段階で審査前QAを固める
Phase 1：1〜2週間。CLAUDE.mdと審査前プロンプトを作り、ローカルでread-onlyレビューを試します。対象はリリースPR 1本だけに絞り、出力が人間のレビューに役立つかを確認します。
Phase 2：3〜4週間。GitHub ActionsやHooksにlint/test/dry-runを組み込み、Claude Codeのレビューコメントと機械チェック結果をセットで見られるようにします。ここでも審査提出や配信は自動化しません。
Phase 3：2〜3ヶ月。Jira、Sentry、Firebaseなどのread-only MCP連携を段階的に追加し、過去リジェクト理由やクラッシュ傾向もレビュー材料に含めます。接続先を増やすたびに、権限、ログ、監査方法を見直します。
このロードマップでは、効果測定も「何時間減ったか」だけで見ません。審査前の未確認項目数、リリース後のhotfix発生有無、レビュー観点の再利用率、QA担当の差し戻し理由など、品質に近い指標も見ます。
想定モデルとしては、最初の1ヶ月で全リリースを置き換える必要はありません。むしろ、1つのアプリ、1つのリリースPR、1つのチェックリストから始める方が失敗しにくいです。
チェックリスト：審査前QAで見るべき12項目
- 今回の差分で新しい権限要求が増えていないか。
- 権限説明文と実際の機能が矛盾していないか。
- 個人情報、位置情報、課金、医療・金融情報に関わる変更がないか。
- debugログ、個人情報を含むログ、不要なconsole出力が残っていないか。
- Feature Flagのデフォルト値と段階配信条件が確認済みか。
- 古いアプリバージョンとAPIの互換性が保たれているか。
- ストア申請文、スクリーンショット、リリースノートが差分と合っているか。
- クラッシュ監視やアラートの対象イベントが更新されているか。
- CIのlint、型チェック、テスト、ビルドが通っているか。
- QAブロッカーIssueが未完了のまま残っていないか。
- 署名鍵、証明書、シークレットがログやPRに露出していないか。
- 最終的なリリース可否判断者と承認ログが残っているか。
この12項目をClaude Codeのプロンプトに含めるだけでも、レビューの抜け漏れはかなり減ります。重要なのは、毎回同じ順番で確認することです。属人化したレビューでは、忙しい日ほど確認順が崩れます。
Claude Codeに出力させる時は、「OK/NG」だけでなく、「根拠」「未確認」「人間確認必須」を分けます。確認できない項目を無理にOKにしないことが、審査前QAでは一番大切です。
社内展開時の運用ルール
業務導入では、ツールそのものより運用ルールが効きます。Claude CodeをモバイルQAに入れる場合、少なくとも次のルールを決めてから広げます。
- リリースPRでClaude Codeレビューを実行する責任者を決める。
- レビュー結果のうち、人間確認必須項目を誰が閉じるか決める。
- Claude Codeが参照してよいMCP接続先と、参照してはいけない情報を分ける。
- 審査提出、署名、production配信は人間が行うことを明文化する。
- 出力ログに個人情報、秘密情報、認証情報を貼らないルールを作る。
- 月1回、CLAUDE.mdとチェックリストを振り返り、実際のリジェクト理由や障害を反映する。
この運用ルールがないと、Claude Codeの出力は「便利なメモ」で止まります。逆に、リリース判定フローに組み込めば、毎回のレビュー観点がチーム資産になります。
特にモバイルアプリは、ストア審査、OSバージョン差分、端末差分、権限、課金、通知、外部SDKなど、Webアプリとは違う確認ポイントが多い領域です。Claude Codeの導入も、Web開発のレビュー設定をそのまま流用せず、モバイル固有のルールへ調整します。
参考・出典
- Claude Code overview — Anthropic / Claude Code Docs（参照日: 2026-05-28）
- Claude Code CLI reference — Anthropic / Claude Code Docs（参照日: 2026-05-28）
- Claude Code settings — Anthropic / Claude Code Docs（参照日: 2026-05-28）
- Claude Code security — Anthropic / Claude Code Docs（参照日: 2026-05-28）
- Claude Code GitHub Actions — Anthropic / Claude Code Docs（参照日: 2026-05-28）
- Claude Code permissions — Anthropic / Claude Code Docs（参照日: 2026-05-28）
- Claude Code hooks guide — Anthropic / Claude Code Docs（参照日: 2026-05-28）
- Claude Code MCP — Anthropic / Claude Code Docs（参照日: 2026-05-28）
まとめ：今日から始める3つのアクション
- 今日やること：releaseブランチ用の審査前QAプロンプトを1つ作り、直近のPR差分にだけ試す。
- 今週中にやること：CLAUDE.mdへ権限、ログ、Feature Flag、ストア申請文の確認観点を追加する。
- 今月中にやること：GitHub ActionsまたはHooksでlint/test/dry-run結果をClaude Codeレビューに渡し、人間確認必須項目をリリース会議で使う。
モバイルアプリの審査前QAは、すべてを自動化するより、確認材料を集めて判断しやすくする方が効果的です。Claude Codeは、コード、設定、CI、外部ツールをまたいで文脈を扱えるため、リリース担当の「見落とし防止レイヤー」として相性が良いです。
まずはread-onlyレビューから始め、権限を狭く、根拠を明確に、人間承認を残す。この3つを守れば、Claude Codeを業務導入したいエンジニアチームでも、比較的安全に審査前QAへ組み込めます。
Uravationでは、Claude Codeを使った開発チーム向けワークフロー設計、社内ルール化、レビュー観点の標準化を支援しています。自社のリポジトリやCIに合わせた導入設計を相談したい場合は、お問い合わせフォームからお気軽にご相談ください。
あわせて、障害対応・SQLレビュー・CI/CDなど、リリース品質に近いテーマの記事も読むと全体像がつかみやすくなります。
