結論：
intent:// は「Androidなら何でも開ける魔法のURL」ではありません。対象ActivityがBROWSABLEであること、ユーザー操作、アプリ導入状態などの条件があり、必要に応じて S.browser_fallback_url を用意します。Intent URIの基本構造
Chrome for Developersは、intent: URIにhost/path、package、schemeなどを指定してAndroidアプリを起動する方法を文書化しています。Androidの Intent.URI_INTENT_SCHEME も公式APIとして存在します。
実際の形式は対象アプリが受け付けるscheme/host/pathとpackageに合わせる必要があります。第三者アプリ向けに推測でpackageやschemeを作るのは避けます。
browser_fallback_url
Chromeの公式資料では、アプリを解決できない場合などにブラウザへ戻すURLを S.browser_fallback_url として指定できます。fallback URLはURLエンコードしてIntent URIへ含めます。
ポイント：アプリを開けない利用者を「何も起きない」状態にしないため、Webで到達できる元URLをfallback候補として持つ設計が重要です。
Chromeが外部アプリを起動しないケース
Chromeは、対応アプリが見つからない場合だけでなく、ユーザー操作なしのJavaScriptタイマーから起動しようとした場合などに外部アプリを開かないことがあります。typed URLからのredirectを経由したIntent URIにも制限があります。
そのため、テスト時は実際のリンクタップとアドレスバー入力を混同しないようにします。
App Linksとの違い
| 項目 | Intent URI | Android App Links |
|---|---|---|
| 形式 | intent://... | HTTP/HTTPS |
| ドメイン検証 | App Links方式の検証ではない | assetlinks.jsonで検証 |
| Web fallback | Intent extraで指定可能 | 元のWeb URL自体がfallback |
| 主用途 | 特定Androidアプリ起動の制御 | Webとアプリの検証済み関連付け |
現在の製品との関係
製品コードはInstagram、YouTube、TikTokなど複数サービスでAndroid Intent候補を作ります。ここでも「Intent文字列を生成できる」と「その対象アプリで2026年現在確実に解決される」は別です。
確認項目
- package IDが正しいか。
- scheme/host/pathを対象アプリが受け付けるか。
- ユーザーの明示的なタップから起動しているか。
- アプリ未導入時のfallback URLがあるか。
- Android/Chromeの実端末で確認したか。
- App Linksで解決できる用途をIntent URIへ複雑化していないか。