Bodilab AIAIボディアプリがApple審査に3回リジェクトされた話｜指摘と修正の全記録
写真から体組成を推定するAIアプリが、App Store審査で3回リジェクトされた。理由はガイドライン5.1.1(iv)（カメラ許可の求め方）と1.4.1（健康情報の推奨・計算に出典が無い）の2つ。Appleの公開情報では審査結果の50%は24時間以内、90%は48時間以内に届くとされる（Apple Developer「App Review」より）が、指摘→修正→再提出を2周したことで、公開は単純計算で数日単位後ろ倒しになった。通した修正は「許可ボタンを中立語の『続ける』にし拒否後の自動Settings遷移を廃止」「健康数値ごとに出典を明記した出典ページを新設」の2点。さらに提出前の自主監査でプライバシーポリシーのHealthKit開示漏れも発見して塞いだ。それでも3回目は来た——3.1.2（自動更新サブスクの利用規約リンクが説明文に無い）。アプリ内は元から要件を満たしており、足りなかったのは説明文だけで、ビルドを差し替えずメタデータの修正だけで承認された。
この記事の要点
- 3回のリジェクトは5.1.1(iv)（カメラ許可の導線）・1.4.1（健康数値の出典）・3.1.2（サブスクの規約リンク）。
- 権限ボタンは「許可」でなく中立語の「続ける」。拒否後の自動Settings遷移は不可。
- 体重予測・タンパク質・カロリーなど個別計算する数値には出典表示がほぼ必須。
- HealthKitを読むなら、読み取り専用・端末内保持・利用範囲をポリシーに明記。
- 修正は新ビルドに焼き込んで再提出。OTAだけでは審査バイナリに反映されない。
- 3.1.2は例外——サブスクの規約リンクはメタデータの問題なので、同じビルドのまま説明文だけ直せば通る。
- 審査対象はASC上の実体。直したつもりを防ぐため、再提出前に説明文を読み戻して確認する。
写真1枚で体組成を推定するBodilab AIを、個人開発で作っている。公開までにAppleから3回リジェクトされた。リジェクトは食らうまで抽象的に見えるので、この記事では具体的なガイドライン番号・指摘された実際の文言・直したコードや内容をそのまま書く。フィットネスや健康系アプリを個人開発で出す人が、同じ往復を繰り返さずに済むように。
最初の2回は何が理由だったのか？（5.1.1(iv)と1.4.1）
3回のうち最初の2回は毛色が違う。1回目はガイドライン5.1.1(iv)（データ収集・権限を求める導線）、2回目は1.4.1（安全性—身体的危害、健康数値の出典）が理由だった。5.1.1(iv)はカメラや写真へのアクセスを求める前後の画面設計を対象にし、1.4.1は健康・医療に関わる推奨や計算を出典なしで見せることを問題視する。どちらも「悪意のある機能」への指摘ではなく「見せ方・導線」への指摘で、直す内容自体は難しくない。難しいのは、何を直せば通るのかが審査文からは断片的にしか分からないことだった。
5.1.1(iv)のカメラ許可フローで何を指摘されたのか？
指摘は2点だけだった。1つは事前説明のボタンが同意を誘導する文言「カメラを許可」だったこと、もう1つは「許可しない」を押した後に自動でSettingsアプリへ遷移していたことだ。
| 指摘された点 | 直した内容 |
|---|---|
| 事前説明のボタンが 「カメラを許可」 | 中立な 「続ける」 に変更（Appleの指針は"Continue"/"Next"を使い、"Allow"のような同意語をボタンに使わない） |
| 「許可しない」を押した後に 自動でSettingsへ遷移 | 自動遷移を全廃。恒久拒否のときだけ、ユーザー自身がタップする 「設定を開く」 を表示 |
原則は「許可要求はユーザーに主導権を残し、"はい"へ誘導しない」こと。機能が動かない場面でSettingsへの導線を出すこと自体は問題なく、問題は自動遷移かユーザーのタップかという一点だった。加えて、カメラを拒否しても行き止まりにならないよう「ライブラリから選ぶ」導線を常時併設した。
1.4.1の健康情報の出典漏れはどう直したのか？
審査文はこうだった——「オンボーディングとAIコーチが、健康・医療の推奨と計算を出典なしで提供している」。オンボの体重予測、コーチのタンパク質・カロリーの助言に出典が無かった。対処は専用の「情報の根拠（出典）」ページを新設し、プロフィール・オンボ（予測が出る画面）・コーチの複数箇所からリンクすることだった。
| アプリ内の数値 | 出典 |
|---|---|
| 健康的な減量ペース | NIH / NIDDK |
| 筋肉のためのタンパク質量(g/kg) | ISSN ポジションスタンド(2017) |
| 維持カロリー | Mifflin–St Jeor, Am J Clin Nutr(1990) |
| BMI区分 | 世界保健機関(WHO) |
| 体脂肪率の目安 | American Council on Exercise |
| FFMIの基準 | 査読論文 |
効いたのは2点。出典が見つけやすいこと（1箇所に埋もれさせない）と、アプリを「推定を返すフィットネス/ウェルネス」として位置づけ（Bodilab AIとは何か）、非医療の免責を常時出したことだ。前段の審査では「診断」「処方」といった医療語も指摘されており、これは「分析」「プラン」に中立化済みだった。
どの数値に出典が必要かは、どう線引きすればいいか？
線引きの基準は「ユーザーごとに個別計算した、体に関する具体的な数値かどうか」だ。一般的な豆知識やモチベーション文言に出典は求められにくい一方、体重予測・カロリー・タンパク質量・BMI・体脂肪率など個別計算した数値を画面に表示する機能は1.4.1の対象になりやすい。以下は自分たちが運用しているリスクの段階分けで、公式のルールではなく経験則だ。
| 健康情報の種類 | リスク | 必要な対応 |
|---|---|---|
| 一般的な豆知識・モチベーション文言 | 低 | 通常は出典不要。ただし断定的な医療表現は避ける |
| 一般論としての目安数値（例：BMI区分の説明） | 中 | 出典を明記し、非医療の免責を近くに置く |
| ユーザー個別に計算した数値（体重予測・カロリー・タンパク質量など） | 高 | 数値ごとに出典を明記し、見つけやすい複数箇所からリンク。免責は数値の近くに常時表示 |
HealthKitを使うアプリはプライバシーポリシーに何を書くべきか？
体重・体脂肪・歩数・睡眠・安静時心拍などHealthKitのデータを読むなら、プライバシーポリシーでその取得と利用方法を開示する必要がある。今回は2回のリジェクトを受けて当てずっぽうをやめ、提出前にフル監査をしたところ、3回目になりかねない漏れが見つかった——プライバシーポリシーにApple Healthの記載が無い。写真については書いてあったのに、HealthKitには一切触れていなかった。
追加した節は4点。読み取り専用（書き込みはしない）・端末内保持・週平均のみAIへ送信・販売や広告への利用は無し。監査はほかにも細かい地雷を拾った。「(開発)」表記のリセットボタン（→「すべてのデータを削除」に改名）と、内部の「採点エンジン」というデバッグ行（本番ビルドで非表示に）。直接のリジェクト理由ではなくても、審査員に「未完成」という心証を与えかねない。
3.1.2でリジェクトされたのは何が足りなかったのか？（3回目）
2回のリジェクトのあと自主監査でHealthKitの漏れを潰し、「これで3回目は無い」と思っていた。実際にはまったく別の理由で3回目を食らった。2026年8月10日、審査文はこうだった——「The submission offers auto-renewable subscriptions but does not include a functional link to the Terms of Use (EULA) in the app's metadata.」。ガイドライン3.1.2、自動更新サブスクリプションの表示要件だ。
意外だったのは、アプリ内は最初から要件を満たしていたことだ。課金画面には価格・期間・無料トライアル日数・購入の復元・利用規約とプライバシーポリシーへのリンクが揃っていた。足りなかったのはApp Store Connectの「説明文」だけだった。アプリを直す必要はまったく無かった。
| 3.1.2で要求される表示 | アプリ内 | 説明文（メタデータ） |
|---|---|---|
| サブスクの名称 | あり | 無かった |
| 期間（月額／年額） | あり | 無かった |
| 価格・単位あたりの価格 | あり | 無かった |
| プライバシーポリシーへのリンク | あり | ASCのURL欄にあり |
| 利用規約（EULA）へのリンク | あり | 無かった＝これが指摘点 |
ビルドを作り直す必要はあるのか？
無い。ここが5.1.1(iv)や1.4.1との決定的な違いだった。3.1.2のこの指摘はメタデータの問題なので、同じビルドのまま説明文を直して再提出すれば通る。ボタン文言や遷移ロジックの修正は新ビルドへの焼き込みが要るが、説明文はApp Store Connect側の編集だけで完結する。実際、ビルド番号を変えずに再提出し、翌々日に承認された。
EULAはApple標準とカスタムのどちらを指すべきか？
審査文には「標準のApple EULAを使うなら説明文にリンクを入れよ、カスタムEULAならApp Store Connectに登録せよ」と併記されていた。自社の利用規約ページを持っていたので迷ったが、App Store ConnectにカスタムEULAを登録していない以上、法的に適用されるのはApple標準EULAだと整理し、標準EULAのURLを説明文に入れた。自社の規約はサービス規約として別行で併記し、アプリ内の表示と矛盾しないようにした。説明文の末尾に置いたのはこの3行だ。
| 種別 | 指したURL |
|---|---|
| 利用規約（EULA） | Apple標準EULA（apple.com/legal/internet-services/itunes/dev/stdeula/） |
| サービス利用規約 | 自社の規約ページ |
| プライバシーポリシー | 自社のポリシーページ |
あわせて商品名・期間・価格（月額／年額と月あたり換算）と、自動更新・解約方法の定型文も説明文に入れた。3.1.2は同じ条項でこれらの表示も求めているので、次のラウンドで追加指摘される芽を先に潰す狙いだった。
「直したつもり」を防ぐには何を確認すべきか？
審査で見られるのはApp Store Connect上の実体であって、手元のファイルではない。メタデータの反映は失敗しても静かに失敗するので、直したつもりで同じ指摘を受けると原因の切り分けができなくなる。そこで再提出の前に、ASCのAPIから説明文を読み戻してURLが3本とも入っていることを確認した。リンクは「functional（機能する）」であることが要件なので、各URLがHTTP 200を返すことも実測した。ここが死んでいれば同じ理由で落ちる。
もうひとつ、メタデータだけを直すときはスクリーンショットに触れないようにした。過去に一括アップロードのツールが既存のスクショを消さずに追加し、4枚が8枚に増えた事故があったためだ。枚数の検証はブラウザの見た目ではなくAPIで行っている。
Apple審査の再提出はOTA配信だけで済むのか？
済まない。審査は提出されたバイナリそのものをテストするため、ボタン文言や遷移ロジックの修正はコードの変更であり、新しいビルドに焼き込んで初めて審査に反映される。Appleの公開情報では、提出の50%は24時間以内、90%は48時間以内にレビュー結果が届くとされる（Apple Developer「App Review」より）。今回は「指摘→修正→再提出」を2周したため、公開時期は往復の回数分だけ、単純計算で数日単位で後ろ倒しになった計算だ。提出前の自主監査で3回目の指摘を防げたことが、結果的に最も時間を節約した一手だった。
フィットネス/健康アプリのリジェクトを避ける閾値・ルールは何か？
自分たちが以後の提出で運用している基準は次の3つだ。いずれも公式のルールブックそのものではなく、2回のリジェクトから抽出した実務上のルール・オブ・サムである。
- ボタンの語彙ルール：権限を求めるボタンに「許可」「OK」など同意を意味する語を使わない。「続ける」「次へ」のような中立語に統一する。
- 拒否後の遷移ルール：許可を拒否された後、自動でSettingsへ遷移しない。恒久拒否のときだけ、ユーザー自身がタップするボタンとしてSettings導線を出す。
- 出典必須ルール：ユーザーごとに個別計算した健康数値（体重・カロリー・タンパク質・BMI・体脂肪率など）を画面に表示するなら、その数値のすぐ近くか、見つけやすい専用ページに出典を明記する。
これらは審査を必ず通す保証ではない。Apple自身、審査は人間のレビュアーが行うため一定のばらつきがあると述べており、同じ文言・同じ実装でも別のレビュアー・別のタイミングで判断が変わることはありうる。それでも、この3つのルールを事前チェックリストとして運用するようになってから、少なくとも同種の指摘（許可文言・出典欠如）での再リジェクトは起きていない。
フィットネスアプリを作る人へ（教訓）
- 健康数値には必ず出典を。見つけやすい場所に。AI検索も審査員も評価する。
- 権限要求は中立語で——「続ける」、自動Settings遷移はしない。
- HealthKitを触るならポリシーに開示。
- 「推定のウェルネスアプリ」であって医療機器でないと、免責で明言する。
- 修正は新ビルドに焼き込んで再提出（OTAは審査バイナリに確実には届かない）。
- App Privacy質問票は正確に（健康フィットネス・写真・使用状況・購入を申告し、すべて Not Linked・トラッキング無しで運用する）。
審査は水物ではない。同じ指摘は、同じ理由でまた来る。そしてリジェクトの半分は法務問題ではなく、ボタン1つの言葉選びだった。
この話の主役アプリ
Bodilab AI は写真1枚から体脂肪・筋肉を推定し、「その努力、効いてる？」に答えます。体組成の数値は推定であり、医療診断ではありません。
Download on theApp Storeよくある質問
サブスクアプリが3.1.2でリジェクトされるのはなぜですか？
自動更新サブスクを提供しているのに、利用規約（EULA）への機能するリンクがメタデータに無い場合です。今回はアプリ内の課金画面には価格・期間・無料トライアル・購入の復元・規約とプライバシーのリンクが揃っていたのに、説明文に規約リンクが無いという理由で落ちました。アプリ本体が要件を満たしていても、説明文だけで落ちることがあります。
3.1.2のリジェクトはビルドを作り直す必要がありますか？
必要ありません。メタデータの問題なので、同じビルドのまま説明文を直して再提出すれば通ります。審査で見られるのはApp Store Connect上の実体なので、再提出前に説明文を読み戻し、リンクが実際に200を返すことまで確認しておくと安全です。
Apple審査で健康系アプリが1.4.1でリジェクトされるのはなぜですか？
1.4.1は「安全性—身体的危害」に関するAppleの審査区分で、健康・医療に関わる推奨や数値計算を出典なしで提示しているアプリを対象にします。今回はオンボーディングの体重予測とAIコーチのタンパク質・カロリー数値に出典が無い点を指摘されました。対処は、体重減のペース・タンパク質・維持カロリー・BMI・体脂肪率・FFMIなど、アプリが使う数値ごとにNIH・WHO・ACE・査読論文などの出典を明記した「情報の根拠」ページを作り、数値が実際に出る画面（オンボ・コーチ・プロフィール）の複数箇所から見つけやすくリンクすることでした。
5.1.1(iv)のカメラ許可フローはどう直せばいいですか？
指摘は2点で、事前説明のボタンが同意を誘導する「カメラを許可」だったことと、「許可しない」を押した後に自動でSettingsアプリへ遷移していたことです。対処は、ボタンを中立語の「続ける」に変更し、自動遷移を廃止したうえで、恒久拒否のときだけユーザー自身がタップする「設定を開く」ボタンを表示する形にしました。カメラを拒否しても行き止まりにならないよう、写真ライブラリから選ぶ導線を常に併設しています。
HealthKitを読むアプリはプライバシーポリシーに何を書く必要がありますか？
必要です。体重・体脂肪・歩数・睡眠・安静時心拍などHealthKitのデータを読み取るなら、プライバシーポリシーでその取得と利用方法を開示するようAppleが求めます。提出前の自主監査で、写真については書いてあるのにApple Healthに一切触れていない漏れを発見し、読み取り専用（書き込みはしない）・端末内保持・週平均のみAIへ送信・販売や広告利用は無し、という4点を明記しました。
Apple審査の再提出はOTA配信だけで済みますか？
済みません。審査は提出されたバイナリそのものをテストするため、コード内で完結するOTA（サーバー側の設定変更など）だけでは修正が審査に反映されない可能性があります。ボタン文言や遷移ロジックの修正は、必ず新しいビルドに焼き込んでApp Store Connectへ再提出するのが確実です。
健康系アプリの数値に出典が必要かどうかはどう判断すればいいですか？
「体に関する具体的な数値をアプリが個別に計算して見せているか」で判断します。一般的な豆知識やモチベーション文言は出典が無くても通ることが多い一方、体重予測・カロリー・タンパク質量・BMI・体脂肪率など、ユーザーごとに個別計算した数値を画面に表示する機能は1.4.1の対象になりやすく、出典表示がほぼ必須です。迷ったら「その数値だけ切り出してWebで検索したときに、医療アドバイスに見えるか」を基準にすると判断しやすくなります（ルール・オブ・サムであり公式基準ではありません）。
App Store審査にはどれくらい時間がかかりますか？
Appleの公開情報では、提出の50%は24時間以内、90%は48時間以内にレビュー結果が届くとされています（Apple Developer「App Review」より）。今回のケースでは、1回目のリジェクトからの修正・再提出、2回目のリジェクトからの修正・再提出という2周分の往復が発生したため、公開時期はこの往復の回数分だけ、単純計算で数日単位で後ろ倒しになりました。
フィットネスアプリがリジェクトされないためのチェックリストは何ですか？
「推定を返すウェルネスアプリ」であり医療機器でないと明確に位置づけたうえで、健康数値には出典を付け、権限要求は中立語で自動Settings遷移をせず、HealthKitを使うならポリシーで開示し、開発用のデバッグ表記を本番ビルドから消し、App Privacy質問票を正確に申告する、の6点です。この記事のHowTo手順としてもまとめています。
「(開発)」表記のようなデバッグUIは審査で問題になりますか？
直接のリジェクト理由にはなりにくいですが、審査員に「未完成のアプリ」という印象を与え、他の指摘への心証にも影響しかねません。今回の提出前監査でも「(開発)」表記のリセットボタンや内部の「採点エンジン」というデバッグ行を見つけ、それぞれ「すべてのデータを削除」への改名と非表示化を行いました。