WebViewアプリ（ガワアプリ）は審査に落ちると聞いたことがあるかもしれません。ネット上には「ガワアプリはApp Storeでリジェクトされる」という情報が見られます。この記事では、それがどこまで正しいのか、通すには何が必要なのかを整理します。
結論から言うと、WebViewアプリでもストア審査を通すことは可能です。ただし「Webサイトを表示するだけ」の構成では、特にAppleの審査で問題になる可能性があります。AppleとGoogleで審査の基準が異なり、自社サイトをアプリ化する場合はApple側が主な関門になります。以下では、落ちる条件と通る条件、両ストアの基準の違い、落ちにくい作り方の3点を扱います。
WebViewアプリを含むWebサイトのアプリ化全般については、「Webサイトをアプリ化する方法と費用」で解説しています。本記事はその続きとして、審査に焦点を絞って扱います。
WebViewアプリとは｜Webサイトをアプリの中に表示する仕組み
WebViewはOSが提供する「アプリ内ブラウザ」の部品
WebView（ウェブビュー／アプリの中にWebページを表示するためのOSの機能）は、iOSとAndroidの両方に標準で用意されている仕組みです。SafariやChromeとは別に、アプリの画面内でWebページを表示するために使われます。
WebViewアプリ（ガワアプリ）とは、その仕組みで既存サイトを表示するアプリ
WebViewアプリは、アプリの外側（ガワ）だけを作り、中身は今のWebサイトを表示する方式です。「ガワアプリ」という通称でも呼ばれます。本記事では、既存のWebサイトをアプリ内のWebViewで表示することを中心としたアプリをこう呼びます。一部の画面だけWebViewを使うハイブリッドアプリなど、WebViewを使うアプリすべてが対象ではありません。アプリの枠組みの中にWebViewを組み込み、そこで既存サイトを開きます。ストアに並べられるのがPWAとの違いです。
PWAとの違いは「ストアに出せること」
PWAはそのままの状態ではアプリストアに並びません（AndroidではTrusted Web Activityという仕組みを使えばGoogle Playに配信できますが、別途の対応が必要です）。またiOSではプッシュ通知に条件があり、ユーザーがWebサイトをホーム画面に追加していることが前提になります（iOS 16.4以降）。WebViewアプリはストアにそのまま出せる代わりに、審査という関門があります。PWAの詳細についてはPWAの仕組みと活用事例、iOSの対応状況はiOSのPWA対応状況と使える機能、プッシュ通知はPWAのプッシュ通知の現状と業種別事例を参照してください。
WebViewアプリはストア審査でリジェクトされるのか
「WebViewアプリはリジェクトされる」と言われる理由
「ガワアプリは審査に落ちる」という情報の出どころは、実際にApp Storeの審査でリジェクトされた開発者の報告です。「WebViewでWebサイトを表示しただけのアプリを提出したら落ちた」という経験談が積み重なり、「WebViewアプリ＝落ちる」という見方が広まったと考えられます。
結論：落ちるケースと通るケースは分かれている
落ちやすいのは「Webサイトを表示するだけ」のアプリで、通る可能性があるのは「アプリならではの機能を持っている」アプリです。この線引きの手がかりは、両ストアが公開している規約から読み取れます。
AppleとGoogleでは基準が異なる
Appleはアプリとしての有用性や独自性を重視します。一方Google Playでは、他者のサイトを無断で表示することに加えて、既存アプリと同じ体験を提供するだけの「コンテンツの繰り返し」なども問題になります。Google自身も公式ブログで、既存Webサイトを表示するだけのアプリを「Webview スパム」と表現しています。自社サイトであれば無条件に通るわけではありません。そのうえで実務上の傾向としては、自社サイトを自社でアプリ化する場合の主な関門はApple側になります。「iOSだけ落ちてAndroidは通る」と言われるのは、この差によるものと考えられます。根拠は次の2章で示します。
App Storeの審査基準｜ガイドライン4.2で何が問われるか
公式ガイドラインの原文
App Storeの審査でWebViewアプリに関わる条項が、ガイドライン4.2です。
4.2 最低限の機能 アプリを作成する際は、Webサイトを単に再パッケージしたようなものではなく、優れた機能、コンテンツ、UIを作成するようにしてください。特に利便性も独自性もなく、アプリらしさもない場合、そのアプリをApp Storeで提供することはできません。アプリが継続的に楽しめる何らかの価値、または十分な有用性を備えていない場合は、承認されない可能性があります。アプリが単に曲または映画のみである場合は、iTunes Storeに提出してください。アプリが単に書籍またはゲームの攻略本のみの場合は、Apple Books Storeに提出してください。
出典：Apple「App Reviewガイドライン」日本語版、2026年9月時点
このなかで押さえておきたいのが2文目です。「特に利便性も独自性もなく、アプリらしさもない場合、そのアプリをApp Storeで提供することはできません」という記述から、Webサイトを表示するだけのWebViewアプリが却下の対象になり得ることが読み取れます。
さらに、4.2.2という条項もあります。
4.2.2 カタログを除き、主な目的がマーケティングの資料の提供、広告、Webクリッピング、コンテンツのまとめ、リンク集であるアプリは許可されません。
「Webクリッピング」という語が挙げられています。既存サイトの内容をアプリに載せただけのものは、この条項に該当する可能性があります。
アプリ生成サービスを使う場合は提出方法にも注意
Webサイトをアプリ化するサービスを利用する場合、ガイドライン4.2.6も関わってきます。
4.2.6 有料のテンプレートやアプリ作成サービスを使用して制作されたアプリは、コンテンツのプロバイダから直接提出されたものでない限り却下されます。
出典：Apple「App Reviewガイドライン」日本語版、2026年9月時点
開発方式だけでなく、誰がアプリを提出するのかも事前に確認しておく必要があります。
何が「単なる再パッケージ」と判断されるのか
審査で「単なる再パッケージ」と判断される可能性があるのは、例えば以下のような状態です。
- ・Webサイトをそのまま表示するだけ
- ・アプリ固有の機能が何もない
- ・ブラウザで見るのと違いがない
アプリを開いてもSafariやChromeでサイトを開いたのと同じ体験しか提供しない場合、4.2と4.2.2の両方に触れる可能性があります。
Google Playの審査基準｜Appleとは禁じている対象が違う
公式ポリシーの原文
Google Playの「スパム」ポリシーには、ウェブ表示に関する規定があります。
ウェブ表示スパムやアフィリエイト スパム ウェブサイトへのアフィリエイト トラフィックを誘導する、またはウェブサイトの所有者や管理者に無断でウェブサイトの表示を提供することを主な目的とするアプリは認められません。
違反の例
- ・ウェブサイトの参照トラフィックを誘導して、そのウェブサイトでのユーザーの登録や購入のクレジットを受け取ることを主な目的とするアプリ。
- ・無断で特定のウェブサイトのウェブ表示を提供することを主な目的とするアプリ:「Ted’s Shopping Deals」というこのアプリには、Google ショッピングのウェブサイトを表示する機能しかありません。
出典：Google Play「スパム」ポリシー、2026年9月時点
AppleとGoogleで何が違うのか
Appleが「アプリとしての価値」を問うのに対し、Google Playでは「所有者に無断でWebサイトを表示すること」や、既存アプリと同じ体験を提供するだけの「コンテンツの繰り返し」などが問題になります。自社サイトを自社でアプリ化する場合、Google側の「無断で」という条件には当てはまりません。この点から、自社サイトのWebViewアプリでは主な関門はApple側になります。
出典：Google Play「スパム」ポリシー、2026年9月時点
また、Googleの公式ブログも「Webview スパム」という語を使っています。
このようなアプリは、Webview スパムと見なされ、Play から削除されます。アプリではウェブ以上の機能を提供することを検討し（後略）
出典：Android Developers Blog 日本語版、2020年11月、2026年9月時点
「Androidなら何でも通る」とは言えません。
「iOSだけ落ちてAndroidは通る」が起きる理由
両ストアの規約の書き方の違いが、この現象の背景にあります。Appleはアプリとしての価値を問うため、自社サイトであっても「アプリらしさ」がなければ却下され得ます。Googleは無断利用を禁じているため、自社サイトであれば条件を満たしやすくなります。実務上は「iOSの基準に合わせて作る」という進め方になります。
リジェクトされないWebViewアプリをどう作るか
前提：Appleの基準に合わせて作る
基準が厳しい側（Apple）に合わせて作れば、Google Playの基準も満たしやすくなります。
「このアプリにしかできないこと」を1つ決める
最初に決めるのは機能ではなく、アプリを入れてもらう理由です。「このアプリならではの価値」を1つ以上説明できる状態にしておくと、審査で示す材料が整います。これはAppleの規定ではなく、価値を整理するための実務上の目安です。挙げられない場合は、審査でつまずきやすくなります。アプリとしての位置づけが問われるため、ここが決まっていないと「単なる再パッケージ」と判断されやすくなります。
ネイティブ機能をどう足すか
「アプリらしさ」を作るには、Webサイトだけでは提供できないネイティブ機能を追加します。
- ・プッシュ通知 — 再訪促進が目的のサイトに向く
- ・カメラ・写真 — 会員証の表示やバーコード読み取りに使う
- ・位置情報 — 現在地に基づく情報提供
- ・オフライン閲覧 — 通信環境がない場所でもコンテンツを見せる
- ・生体認証ログイン — パスワード入力を省く
これらは、Webサイトだけでは提供しにくいアプリ固有の体験を作るための手段であり、審査での説明材料になります。ただし審査は個別判断であり、特定の機能を入れれば通るというものではありません。Appleのガイドラインに「ネイティブ機能を追加しなければならない」という要件はなく、求められているのは再パッケージを超えた有用性・独自性です。
Web部分とネイティブ部分の切り分け
全画面をWebViewにせず、ネイティブ画面を持たせる方法もあります。起動直後の画面やログインをネイティブ側に置くと、アプリ固有の要素を示しやすくなります。どこをWebViewにし、どこをネイティブにするかの切り分けが、審査対策の基本になります。
申請時に用意しておくもの
審査担当者にアプリ固有の機能が伝わるよう、スクリーンショットと説明文を用意します。機能が伝わらないと、再パッケージと見なされやすくなります。Appleは審査の準備として、アカウント情報をベースにした機能がある場合は「有効なデモアカウントまたは全機能を使用できるデモモードを用意」すること、「App Reviewの『メモ』欄に、わかりにくい機能やアプリ内購入の詳細な説明を明記する」ことを求めています（出典：Apple「App Reviewガイドライン」日本語版、2026年9月時点）。アプリ固有の機能が確認できる状態にしておくことが前提になります。
それでも落ちた場合
審査でリジェクトされた場合、開発者には次の文言で通知が届きます。
「Guideline 4.2 – Design – Minimum Functionality」
この文言は、リジェクトの理由を調べる際の手がかりになります。4.2を理由とする場合は、アプリとしての独自性や有用性を高める機能・UIの見直しを行って再申請する流れになり、追加開発には費用と期間がかかります。指摘内容によっては、機能追加ではなく説明や申請情報の修正で対応できる場合もあります（アプリ開発費用の相場）。この点は次章のリスクにつながります。
WebViewアプリを選ぶ前に知っておくべきリスク
審査に落ちたときは追加の対応が発生する
リジェクトされると、指摘内容に応じた対応が発生します。申請情報や説明の不足であれば修正と再申請で済みますが、4.2を理由に「アプリとしての価値が足りない」と判断された場合は、機能やUIの追加開発が必要になります。「安く作れる」という前提が崩れやすい点が、想定から外れやすい部分です。費用の考え方全般については「Webサイトをアプリ化する方法と費用」を参照してください。
規約は改定される
今回通っても、改定によって基準が変わる可能性があります。AppleとGoogleの規約はこれまでにも改定されており、ストアに依存する事業上の前提として踏まえておく必要があります。法令の側でも変化があり、アプリ運営企業に求められる対応はスマホ新法でアプリ運営企業がすべきことで整理しています。
アップデートの自由度には注意点がある
アプリのバイナリを更新せずWeb側のコンテンツを変更する範囲であれば、審査を通さず更新できるのがWebViewアプリの利点です。ただし、審査を回避する目的で機能をWeb側に寄せるような運用は、規約違反につながる可能性があります。規約に沿った運用が前提です。
操作感がネイティブと異なる場合がある
WebサイトをそのままWebViewで表示する構成では、画面遷移やスクロール、戻る操作などで、ネイティブアプリとは異なる操作感になる場合があります。特にモバイル向けに最適化されていないWebサイトをそのまま使うと、使いにくさにつながります。操作性の差がレビュー評価に影響することもあります。
WebViewそのものの保守
OSやWebViewの更新で表示が崩れることがあります。既存サイトを変更したら、アプリ側でも確認が必要になります。メンテナンスの手間は継続的にかかります。WebViewはWebの通信をアプリの中に持ち込む仕組みでもあるため、セキュリティ面の設計も欠かせません（新規事業のアプリセキュリティ超入門）。
それでもWebViewアプリが向いているケース・向かないケース
向いているケース
- ・既存サイトのコンテンツが中核で、そこに通知やカメラなどを足したい
- ・自社サイトを自社でアプリ化する（他社サイトではない）
- ・更新頻度が高いコンテンツを扱っている
向かないケース
- ・サイトをそのまま出したいだけで、機能を足す予定がない（審査で却下される可能性が高い）
- ・機器連携や高い描画性能が必要（ネイティブアプリにできて、Webアプリで実現できないことを参照）
- ・ストアでの露出が事業の中核で、審査で止まるリスクを負えない
判断に迷う場合の考え方
「このアプリにしかできないこと」を1つ挙げられるかが目安になります。挙げられない場合、審査で示す材料が不足している状態だと考えられます。
WebViewアプリの開発を相談するときに整理しておくこと
開発会社に相談する前に、以下を整理しておくとスムーズです。
- ・何のネイティブ機能を入れるか
- ・iOS・Androidのどちらに出すか
- ・既存サイトの構成
- ・審査で落ちた場合の対応方針を事前に決めておく
詳しくは要件定義で依頼側がやるべきことを参照してください。
よくある質問（FAQ）
Q. WebViewアプリとガワアプリは同じものですか？
A. 同じです。ガワアプリはWebViewアプリの通称です。
Q. WebViewアプリはApp Storeの審査に通りますか？
A. 通すことは可能ですが、「Webサイトを表示するだけ」の状態では却下される可能性が高くなります。App Reviewガイドライン4.2では、Webサイトを単に再パッケージしたものではなく、アプリとしての機能・コンテンツ・UIを備えることが求められています。プッシュ通知やカメラなどのネイティブ機能の追加は、その価値を示す手段の一つです。
Q. Google PlayではWebViewアプリの審査は通りやすいですか？
A. 両ストアの規約が禁じている対象は異なります。Google Playのポリシーは「所有者や管理者に無断で」ウェブサイトの表示を提供することを禁じているため、自社サイトを自社でアプリ化する場合はこの条件に当てはまりません。この点からAppleより関門が少ないと考えられます。ただし「コンテンツの繰り返し」の規定があり、無審査ではありません。
Q. 審査に落ちたらどうなりますか？
A. 指摘内容に応じた対応が必要になります。申請情報や説明の修正で済む場合もあれば、4.2などを理由に機能やUIの追加開発が必要になる場合もあります。費用と期間が想定を超える可能性があります。
Q. PWAとWebViewアプリはどちらを選ぶべきですか？
A. ストア配信が必要かどうかが分かれ目です。詳細は「Webサイトをアプリ化する方法と費用」を参照してください。
まとめ
WebViewアプリはストア審査を通すことが可能です。ただし「Webサイトを表示するだけ」の構成では、特にAppleの審査で問題になる可能性があります。Appleはガイドライン4.2で「アプリとしての価値」を問い、Googleは「他者のサイトを無断で利用すること」を問題にしています。自社サイトを自社でアプリ化する場合、主な関門はApple側になります。
通すために必要なのは「このアプリならではの価値」を明確にし、それをユーザーが実感できる機能やUIとして実装することです。プッシュ通知やカメラ、位置情報などのネイティブ機能は、その価値を実現する手段の一つです。審査は個別判断であり、通る保証はありません。落ちた場合は、指摘内容に応じて説明や申請情報の修正で済むこともあれば、追加開発が必要になることもあり、費用と期間が想定から動きます。これらを踏まえて、WebViewアプリが自社に向いているかを判断してください。
