導入：Webを開く手段、雑に選ぶと後で詰む
Androidアプリで「Webを開きたい」って、日常茶飯事です。
外部リンク、規約ページ、ログイン、決済、ヘルプ、埋め込みの管理画面…。
で、毎回出てくるのがこの悩み。
- Chrome Custom Tabs（以下Custom Tabs）で開くべき？
- WebViewで埋め込むべき？
結論から言うと、「自分の責任範囲をどこまで持つか」でほぼ決まります。
- ブラウザに任せて安全・手堅くいく → Custom Tabs
- アプリ内のUI/挙動まで作り込みたい → WebView
この記事では、用途別に「どっちを使うべきか」を迷わないように整理します。
まず押さえる：Custom Tabs と WebView の根本的な違い
ざっくり言うと、Custom Tabs は「端末のブラウザをアプリ内に埋め込む入口」です。
WebView は「アプリが自前でブラウザ部品を持つ」です。
違いを一言で
- Custom Tabs：ブラウザの機能・セキュリティ・Cookie状態を使う（＝ブラウザに寄せる）
- WebView：アプリが挙動を握れるが、設定・保守・事故対応も自分（＝アプリに寄せる）
比較表：迷ったらここを見る
| 観点 | Custom Tabs | WebView |
|---|---|---|
| ユーザーのログイン状態 | ブラウザのCookie/セッションを使える | 基本的にアプリ内で別管理になりがち |
| 安全性の責任 | ブラウザ側に寄せられる（アプリはページ中身に基本触れない） | 設定ミスで事故りやすい（JS、URLハンドリング等） |
| UIの自由度 | 限定的（ツールバー等のカスタム） | 高い（UI・遷移・JS連携まで自由） |
| 実装コスト | 低い（Intent + 少し設定） | 中〜高（設定、Cookie、リダイレクト、戻る制御など） |
| 保守コスト | 低い（基本ブラウザ任せ） | 高い（端末差・挙動差・セキュリティ対策） |
| ページの中身をアプリが扱う | 基本できない（境界が強い） | やろうと思えばできる（それが事故要因にもなる） |
判断基準：これならCustom Tabs、これならWebView
Custom Tabs を選ぶべきケース
- 外部サイトに飛ばす（規約/ヘルプ/FAQ/キャンペーン）
- OAuthログイン（Google/Twitter/LINE等）で、ユーザーのブラウザ状態を使いたい
- 決済など安全性・信頼性が重要（アプリ側で中身を触らない方が良い）
- Webの見た目や挙動をアプリ側で細かく制御しなくてよい
この手は「アプリが余計なことをしない」方が強いです。ここでハマる確率が下がります。
WebView を選ぶべきケース
- 自社ドメインのWebをアプリの一部として提供（会員ページ、管理画面、Webベース機能）
- ナビゲーションやヘッダー/フッターをアプリUIと統一したい
- JSブリッジでアプリ機能と連携したい（※設計とセキュリティが必須）
- オフライン表示、キャッシュ戦略などを作り込みたい
実務での落とし穴（3〜6個）
落とし穴1：ログイン状態が引き継がれない問題
WebView はブラウザと状態が別になりやすく、「ブラウザではログイン済みなのにWebViewだとログイン画面」が起きがちです。
ログイン体験が重要な導線なら、まず Custom Tabs を検討した方が安全です。
落とし穴2：WebViewのURLハンドリングで事故る
shouldOverrideUrlLoading の実装を雑にすると、意図しないURLが開けたり、逆に必要な遷移が止まったりします。
「WebViewに任せるURLはfalseを返す」など、役割を固定するのが基本です。
落とし穴3：WebViewの設定盛りすぎ（特にJavaScript）
とりあえずで JavaScript 有効、ファイルアクセス許可、ユニバーサルアクセス許可…。
これ、後から回収不能な地雷になりやすいです。
必要なものだけ許可し、不要なら明示的にOFF。これが一番堅いです。
落とし穴4：戻る/閉じるのUXが崩れる
WebViewは「戻る＝Web履歴に戻る」なのか「画面を閉じる」なのかが混線しがちです。
戻る挙動が曖昧だと、ユーザーはすぐ離脱します。ここ、軽視しない方がいいです。
落とし穴5：Custom Tabs でも「プライバシー的に共有したくない」ことがある
Custom Tabs はブラウザ状態（Cookie等）を使えるのが強みですが、逆に「共有したくない」ケースもあります。
その場合は、隔離されたタブ（エフェメラル/一時的なタブ）系の選択肢を検討すると設計がきれいになります。
最短で動くサンプル
Custom Tabs（Kotlin）最小例
dependencies {
// Custom Tabs 用
implementation("androidx.browser:browser:1.8.0")
}import android.net.Uri
import androidx.browser.customtabs.CustomTabsIntent
fun openWithCustomTabs(url: String) {
val intent = CustomTabsIntent.Builder()
// 必要ならツールバー色などを設定
.build()
intent.launchUrl(this, Uri.parse(url))
}これで「アプリ内っぽいブラウザ」で開けます。実装コストはかなり低いです。
WebView（Kotlin）最小例
import android.annotation.SuppressLint
import android.os.Bundle
import android.webkit.WebView
import android.webkit.WebViewClient
import androidx.fragment.app.Fragment
class SampleWebViewFragment : Fragment(R.layout.fragment_webview) {
@SuppressLint("SetJavaScriptEnabled")
override fun onViewCreated(view: android.view.View, savedInstanceState: Bundle?) {
val webView = view.findViewById<WebView>(R.id.webView)
webView.webViewClient = object : WebViewClient() {
// WebView自身に処理させるURLは false を返すのが基本
}
webView.settings.javaScriptEnabled = true // 本当に必要な場合だけON
webView.loadUrl("https://example.com")
}
}WebViewはここから先の「調整ポイント」が多いです。最小例が動いても、実務でそのまま行けることは少ないです。
代替案/ベストプラクティス：判断フロー（これで迷わない）
実務での判断は、これが一番速いです。
- 外部サイトに飛ばす？ → 基本 Custom Tabs
- ログイン/決済でユーザーのブラウザ状態を活かしたい？ → Custom Tabs
- アプリの一部としてWebを組み込む？（自社ドメイン中心） → WebView
- JS連携やUI統合が必要？ → WebView（ただし設計と制限を固める）
- Cookie共有したくない？ → 隔離タブ系を検討
応用：設計・テスト・パフォーマンス・セキュリティの深掘り
設計：境界を決める（これがないと破綻する）
Webを扱う実装は、境界が曖昧だとすぐ混線します。
- どのURLをアプリ内で扱うか（ホワイトリスト）
- どの遷移を外部に逃がすか（intent起動）
- ログインや決済など重要導線は「中身に触れない」設計に寄せる
テスト：確認観点を先に決める
- 戻る操作（Web履歴 / 画面終了）が想定通りか
- リダイレクト（http→https、別ドメイン）で破綻しないか
- Cookie/セッションが想定通りか（WebViewの場合は特に）
- 端末差（Chromeなし、デフォルトブラウザ違い）で動くか
パフォーマンス：WebViewは起動・再生成が重い
WebViewは初回生成が重く、画面回転やプロセス再生成で体感が悪化しやすいです。
「使う」なら、ライフサイクルや再生成時の挙動まで含めて設計した方が安定します。
セキュリティ：WebViewは「できること」が多い＝事故の余地が多い
WebViewは自由度が高い反面、設定・URLハンドリング・JS連携の設計ミスで事故りやすいです。
やるなら「最小許可」「ホワイトリスト」「例外時の閉じ方」までセットで考えるのが現実的です。
デバッグ/確認チェックリスト
- 外部サイトならまず Custom Tabs を検討したか
- ログイン/決済は「中身に触れない」設計になっているか
- WebViewでJavaScriptを本当に必要最小限にできているか
- URLハンドリングの責務が固定されているか
- 戻る/閉じるのUXが崩れていないか
- 端末差（ブラウザ差）での挙動を確認したか
よくある質問（Q&A）
Q. とりあえず WebView で全部やるのはアリ？
短期的には早いですが、保守と事故対応の責任が全部アプリに乗ります。
外部サイトや認証/決済は、まず Custom Tabs に寄せた方が安定するケースが多いです。
Q. Custom Tabs って、結局ブラウザに飛ばしてるのと何が違う？
アプリから離脱しにくいUIで開けるのが大きいです。
完全に別アプリへ切り替わるより、文脈が切れにくいのがメリットです。
Q. WebView でログイン状態を共有できないのがつらい
そこがまさに「Custom Tabs を検討すべきサイン」です。
WebViewに寄せるなら、ログイン体験が悪化しない設計（導線や説明、戻り方）まで作る必要があります。
Q. Cookie共有したくない場合はどうする？
「共有できる」ことが強みでもありますが、用途によっては逆に困ります。
その場合は隔離されたタブの仕組みなどを検討すると、責務が整理しやすいです。
Q. 結局、迷ったらどっち？
迷ったら Custom Tabs が事故りにくいです。
WebViewは「作り込みたい理由」が明確な時だけ選ぶと、後で後悔しにくいです。
まとめ：要点3つ＋迷ったらこれ
- 外部サイト・認証・決済は Custom Tabs が堅い
- WebViewは自由度が高いぶん、設計と保守コストも高い
- 境界（URL/責務/戻り方）を決めないと混線する
迷ったらこれ：外に出すなら Custom Tabs、アプリの一部にしたいなら WebView。
コメント