App Storeリジェクトへの返信をClaude Codeで下書きする手順

リジェクトの通知は、1通に複数のガイドライン番号が並ぶことがあります。直す場所はコードにもメタデータにも散らばり、返信文は「どの指摘に、どこをどう直したか」を1対1で書く必要があります。この突き合わせは、リポジトリを読めるClaude Codeに向いた仕事です。

ここでは、通知を指摘ごとのカードに分け、各カードを該当ファイルに対応づけ、最後にApp Review宛ての返信文を下書きするまでを扱います。返信の送信と再提出の操作は人が行います。

返信の前に押さえるApp Store Connect側の仕様

Claudeに頼む前に、返信の場そのものの決まりを確認します。Appleのヘルプには次の記述があります。

返信の画面までの道筋も、ヘルプに書かれたとおりです。Appsで対象のアプリを選び、上部の未解決の問題を示すリンクを開きます。In Progressの欄で対象の提出の横にあるResolveを押し、Reply to App Reviewを押して本文を入れます。ファイルはAttach Fileで添付し、最後にReplyを押します。

提出の一部だけが却下されたときは、状態がUnresolved Issuesに変わります。この提出は、却下された項目の編集か削除を済ませるまで、承認済みとは扱われません。項目を編集して再提出できるのは、再提出の前に1回までです。削除した項目は、同じ提出に戻せません。返信文に「あとでこの項目も追加します」と書いても、その提出には足せない点は、下書きの前提として覚えておく価値があります。

この返信の仕組みは、App Reviewだけでなく、TestFlightのApp Reviewで却下された場合にも使えます。ヘルプは両方をまとめて扱っています。ベータ版の審査でも、通知を同じカードに分ければ、手順は変わりません。

通知を指摘カードに分ける

通知の本文を、Claudeに指摘ごとのカードへ分解させます。ここで大切なのは、通知に書かれていない原因をClaudeが補わないことです。

通知はApp Store Connectの画面からコピーしてテキストファイルに保存し、標準入力で渡します。非対話モードは標準入力を読めるので、ビルドログを渡す使い方と同じ形で書けます。

cat rejection-notice.txt | claude -p \
  "指摘を1件ずつ分け、ガイドライン番号・引用・求められた対応を表にして" \
  > cards.md

カードの列は次の4つにします。

種別の列が、前節の「同じビルドで再提出できるか」を決める材料になります。ここが埋まらない指摘は、人が通知を読み直す行として残します。

ガイドライン番号から確認箇所を引く

カードができたら、各指摘を実際の確認箇所に結びつけます。Claude Codeには、プロジェクトのどこを見るかを指示します。次の表は、Appleのガイドラインの記述から、リポジトリで見る場所を引いた例です。

右端の列は「見る場所の例」です。実際のディレクトリ名はプロジェクトごとに違うので、Claudeに探させ、見つけた場所をファイルパスと行番号つきで返させます。

cards.md の指摘ごとに、次を調べてください。
- 該当しそうなファイル(コードとメタデータ)を、パスと行番号つきで挙げる
- 指摘の引用と、そのファイルの内容が食い違う点を1文で書く
- 見つからない場合は「該当箇所なし」と書き、推測で埋めない
まだファイルは変更しないでください。

最後の1行が要になります。調査の段階で修正まで進めると、返信に書く内容と実際の差分がずれやすくなるためです。Claude Codeには、ファイルを編集せずに計画だけを出すplan modeがあります。claude --permission-mode planで起動すれば、読んで調べて計画を示すまでで止まります。使い方はClaude Codeのplan modeの解説にまとめています。

審査向けの決まりをCLAUDE.mdに置く

毎回プロンプトに書くより、プロジェクトのCLAUDE.mdに置くほうが手間が減ります。公式のメモリのページは、同じ訂正を前回のセッションでも入力したときは、CLAUDE.mdに書く合図だと説明しています。リジェクト対応は、この条件に当てはまります。

## App Store審査の指摘への対応
 
- 通知の引用は要約せず原文のまま扱う
- 通知に書かれていない原因を推測で断定しない。断定できないときは「要確認」と書く
- 修正前に、該当ファイルのパスと行番号を示す
- 返信文に書く対応は、実際に差分へ入っているものだけにする
- デモアカウントのパスワードや個人情報は、返信の下書きに含めない

4つ目が、この手順の中心です。次の節で返信文を作るとき、書かれた対応と実際の差分を照合する根拠になります。

返信文を下書きする

調査と修正が済んだら、指摘カードと差分をもとに返信文を作ります。差分はgit diffで取り出して渡します。

git diff main...HEAD > fix.diff

cards.md の各指摘と fix.diff を突き合わせ、App Review宛ての返信文を下書きしてください。
構成は指摘ごとに次の順です。
1. ガイドライン番号と、指摘の要点
2. 行った対応(fix.diff にある変更だけ)
3. 対応した場所(ファイル名、またはApp Store Connectの欄名)
4. 添付するもの(スクリーンショットなど)
fix.diff に対応が無い指摘は、「未対応」と見出しに書いて別にしてください。
文体は事実だけを書く丁寧な文にし、感想や評価の語は入れないでください。

例えば、次のような形になります(構成の例で、実際の出力ではありません)。

ガイドライン2.1(a)について
ご指摘のとおり、審査用のログイン情報が不足していました。
App Store Connectの審査用アカウント欄に、デモアカウントを追加しました。
バックエンドは審査期間中、稼働させています。
 
ガイドライン5.1.1(i)について
プライバシーポリシーへのリンクを、設定画面の「アプリについて」に追加しました。
メタデータのプライバシーポリシーURLの欄にも同じURLを入れています。

下書きをそのまま送らず、次の3点を人が確かめます。

• 返信の「対応した場所」が、実際に提出する版に入っているか
• 通知の指摘に、返信で答えていない行がないか
• 添付に、個人情報やパスワードが写り込んでいないか

「未対応」の見出しに残った指摘は、返信を書く前に直すか、後述する異議申し立ての対象かを決めます。

メタデータの指摘は、文字数と語を機械的に確かめさせる

メタデータだけが理由の却下なら、同じビルドで再提出できます。Claudeが力を発揮するのは、この種の指摘の洗い出しです。

2.3.7はアプリ名を30文字以内とし、メタデータに商標や人気アプリの名前、価格などの無関係な語を詰め込むことを禁じています。サブタイトルについても、他のアプリへの言及や、裏づけのない製品の主張を載せないよう求めています。メタデータをリポジトリで管理しているなら、次のように頼めます。

metadata/ 配下のアプリ名・サブタイトル・キーワード・説明文を読み、
2.3.7 と 2.3.8 の条文(貼り付け済み)に照らして次を表にしてください。
- アプリ名の文字数
- 他社アプリ名・商標・価格に見える語と、その出現箇所
- 「For Kids」「For Children」の語の有無
条文に当たらない語は表に入れず、判断が割れる語は「要確認」としてください。

文字数は数え間違いが起きやすい項目です。Claudeに数えさせるより、スクリプトで数えて結果を貼るほうが確実です。表の「要確認」の行は、人が条文の原文と見比べて決めます。

再提出の前に、提出前の点検をもう一度通す

却下のあとに同じ理由で再び止まる原因は、指摘の箇所だけを直して、ほかの提出条件を見直さないことです。ガイドラインの「Before You Submit」には、提出前の確認項目が並んでいます。

• クラッシュや不具合がないかを試す
• アプリの情報とメタデータが、完全で正確か
• App Reviewが連絡できるよう、連絡先を更新しておく
• アカウント機能があるなら、有効なデモアカウントか、機能をすべて備えたデモモードを用意する
• 審査中にバックエンドが稼働し、アクセスできる
• 分かりにくい機能とアプリ内課金は、App Reviewのメモに詳しく書く

この一覧を貼り、今回の変更差分で影響を受ける項目だけを挙げさせます。たとえば画面を直したなら、スクリーンショットの更新が要るかどうかが論点になります。点検の結果は返信文に書かず、再提出のチェックとして手元に残します。

指摘に同意できないとき

通知の判断に納得できない場合は、返信ではなく異議申し立て(appeal)の出番です。ガイドラインの末尾に、審査結果に同意できない場合は異議申し立てを出せると書かれています。

対応した指摘への返信と、同意できない指摘への異議は、文面を分けて下書きします。1通に混ぜると、どの指摘に直したのか、どの指摘に反論しているのかが読み手に伝わりにくくなります。

Claudeに任せられるのは、論点の整理までです。次のように頼みます。

カード3の指摘に同意できません。通知の引用、該当するガイドラインの条文、
私たちのアプリの実際の動作を3列で並べ、食い違いが生じる箇所だけを示してください。
「Appleが間違っている」と書く文は入れないでください。

条文は、ガイドラインのページから該当番号の文章を貼って渡します。記憶に頼ると、番号と内容がずれます。2.1(a)と2.1(b)のように枝番が分かれている条もあるため、通知に書かれた枝番まで合わせます。

通知を渡す前に外すもの

通知やスクリーンショットには、アカウント情報やデモアカウントの認証情報が含まれることがあります。Claudeに渡す前に、パスワードと個人情報は伏せ字に置き換えます。返信文に認証情報を書くときは、App Store Connectの審査用アカウント欄を使い、Claudeの下書きには入れません。

まとめ

リジェクト対応で時間を食うのは、返信文を書く作業より、指摘とコード・メタデータの対応づけです。通知を原文のままカードに分け、カードごとに確認箇所を引き、実際の差分だけを根拠に返信を組み立てると、書いた内容と提出物のずれを防げます。

公開後のレビューを星の帯とテーマで分ける手順はClaudeでアプリのレビューを分析する手順に、審査の条文を年齢レーティングの申告と照らす手順はGoogle Play年齢レーティングの質問票をClaudeでApp Store審査と照合するにあります。