URLスキームとは？アプリを開く仕組み・作り方・注意点

結論：URLスキームは今も使われるdeep linking方式ですが、Appleは可能な場合Universal Linksを強く推奨しています。自社アプリで使うなら、URL形式を定義し、schemeを登録し、受信URLを検証して処理するところまでが最低限です。

URLの「scheme」がhttps以外になる

通常のWeb URLは https:// から始まります。カスタムURLスキームではアプリ独自のschemeを登録し、OSがそのschemeを処理できるアプリへURLを渡します。

Spotifyの spotify:、Slackの slack:// のように公式に公開されたschemeもあります。一方、第三者サービスのschemeは現在仕様を必ず一次情報で確認する必要があります。

Appleの公式資料は、custom URL scheme対応を大きく3段階で説明しています。

「schemeを登録したら完成」ではありません。外部から任意URLを渡される前提で、想定外のpath・壊れたquery・危険な操作を拒否する処理も必要です。

Appleはcustom URL schemeを許容しつつ、Universal Linksを強く推奨しています。schemeはWebドメイン所有のように一意検証されず、複数アプリが同じschemeを登録する可能性があります。

また、対象アプリがインストールされていない場合、custom schemeだけでは通常のWebページへ自然にfallbackできないことがあります。一般公開するリンクでは、元のHTTPS URLや別のfallback導線を残す設計が重要です。

方式	URL	関連付け	未導入時
Custom URL scheme	`myapp://...`	アプリがschemeを登録。ドメイン所有との検証はない	別途fallback設計が必要
Universal Links	HTTPS	AASA/Associated Domains	同じWeb URLへ到達できる
Android App Links	HTTPS	Digital Asset Links	同じWeb URLへ到達できる

自社Webと自社iOSアプリを結ぶならUniversal Links、AndroidならApp Linksも比較してください。

ブラウザやSNS内WebViewは、外部schemeを常に同じように処理するとは限りません。ユーザー操作なしの起動を抑制する、外部アプリ起動を確認する、何も起こさないなどの差があります。

対象アプリ未導入時の設計はfallback設計、公開前確認はテスト方法に分けています。

Appleはcustom URL schemeをアプリへの攻撃経路になり得ると警告し、URLパラメータの検証、不正形式の拒否、ユーザーデータを危険にさらす操作をリンクだけで実行させないことを案内しています。

避けたい実装：URLに含まれた認証tokenを無条件に信用する、リンクを開くだけで削除や重要設定変更を行う、受信したURLを未検証のままWebView・SQL・コマンドへ渡す、といった設計です。

現在のディープリンクジェネレーターは、第三者サービスURLを解析してcustom schemeやAndroid Intent候補を組み立てるコードを持ちます。これは自社ドメインへUniversal Links/App Linksを設定するツールとは違います。

第三者サービスでは：コード内にscheme候補があるだけで、そのschemeが対象サービスの現行公式仕様だとは扱いません。サービス別記事で一次情報と実端末検証状態を分けています。