日本ではiOSの利用シェアが高く、Apple Walletはすでに交通系ICカード（SuicaやPASMOなど）で日常的に使われているため、会員証やクーポンを「Apple Walletに追加」する導線への抵抗感はほとんどありません。とはいえ、実装の現場でつまずくのはボタンの見た目ではなく、その先にある署名済みパス（.pkpass）との連携です。
本記事では、Apple Walletボタンをメール・Webサイト・アプリのどこに置くべきか、Appleが定める公式ルール、そして実際にパスを保存できるインストールリンクへの正しい接続方法を、実装担当者向けに整理します。正しく実装できれば、テンプレートに埋もれるだけのボタンではなく、インストール率を押し上げる導線になります。
セキュリティ・コンプライアンス：情シス審査で確認されるポイント
ウォレットパスの発行・配信基盤を選定する際、多くの日本企業では情報システム部門による審査が必須です。会員情報や購入履歴などの個人情報を扱う以上、第三者認証とデータ所在地の明示は導入判断の前提条件になります。
Pushwoosh Wallet passesは、SOC 2 Type IおよびISO 27001:2022の認証を取得し、GDPRおよびHIPAAに準拠したプラットフォームです。データセンターはEUおよび米国に設置されており、パスの発行・更新・配信にかかわるデータの所在と管理体制を明確に説明できます。情シス審査で必ず問われる「第三者認証の有無」「データ保管場所」「委託先の管理体制」といった論点に、あらかじめ答えを用意できる点は、導入担当者が社内稟議を通すうえでも大きな助けになります。
ボタンを置くべき3つの場所（メール・Web・アプリ）
Apple Walletボタンが機能する場所は3つあり、それぞれパスが価値を持つ瞬間と結びついています。
メールでは、注文確認やクーポン案内、会員登録完了メールなど、確認・オファー系のメッセージに配置します。注意点が一つあります。顧客がパソコンでメールを開くとボタンが機能しないため、「iPhoneでこのメールを開いてパスを追加してください」といった一文を添えておきましょう。
Webサイトでは、決済完了ページや予約確認ページ、専用のクーポンページなど、保存対象そのものに近い場所に置きます。
アプリ内では、パス情報がすでに表示されている画面、つまり購入・登録・発券といったアクションの直後に配置します。ネイティブアプリでは画像ではなく、Apple提供のボタンコントロールを使用します。
Appleの公式ボタンガイドライン
Appleはこのバッジを商標登録されたアートワークとして扱っており、ルールは厳格です。守らなければ、アプリ審査で却下されたり、ボタンの見た目が崩れたりするリスクがあります。
Web・メール用にはApple提供のSVGを、印刷物のQRコード周りにはEPS版を使用します。独自にデザインしたり、色を変えたり、回転・アニメーション・影を加えたりしてはいけません。ネイティブアプリではPKAddPassButtonコントロールを使うと、正しい見た目と言語が自動的に反映されます。
レイアウト面では、バッジの高さの10分の1以上のクリアスペースを確保し、白または明るい背景に配置します。暗い背景にはアウトライン版が用意されています。バッジはあくまでメインコンテンツに対して副次的な存在であるべきで、レイアウトを支配してはいけません。
名称については、初出時は「Apple Wallet」、以降は「Wallet」と表記し、法的テキストを表示する箇所にはApple指定のトレードマーク表記を含めます。この命名規則もApple審査の確認項目に含まれます。
見落としがちなミスもあります。独自デザインのバッジは審査に通りません。目的が分かりにくい場所に配置されたバッジも、存在ごと無視されます。未署名や不正な形式のパスへのリンクはタップしても何も起きず、「iPhoneのウォレットに保存」のような表記のゆれはブランドルール違反になります。いずれも公式アートワークと正しく署名されたパスを使えば避けられます。
Google Walletボタン：役割は同じ、ルールは別物
AppleとGoogle両方のウォレットに対応する場合（多くの消費者向けビジネスはそうすべきです）、Appleのボタンと並べてGoogleのボタンを配置することになります。役割は同じでも、細部のルールは異なります。
Googleのボタンは、Android XML・SVG・PNG形式で提供され、色は黒のみ、プライマリと簡略版の2種類があります。クリアスペースは全辺8dp固定、ボタンの最小高さは48dpです。見落としやすいルールとして、他のボタンが同じ画面にある場合、Add to Google Walletボタンはそれらと同じかそれ以上の大きさでなければならず、小さくしてはいけません。
ボタンはGoogle Wallet APIのフローを呼び出す必要があり、これによりGoogle Walletアプリが開いて、ユーザーがAndroid端末とGoogleアカウントにパスを保存できます。表記は「Google Wallet」（GとWは大文字）とし、自作の文言ではなくGoogleが提供するローカライズ済みのボタンテキストを使用します。
つまり、同じテンプレートの中に2つのボタンと2つのルールセットが存在することになります。両方の規格に合わせてパスを用意し、バッジを並べて配置すれば、あとは顧客の端末が処理してくれます。
有効なインストールリンクとの連携
バッジは、実際に署名済みのパスを指し示していなければ、ただの画像に過ぎません。顧客が実際に保存できる状態にするために必要な3つのステップがあります。
-
ユーザーごとにインストールリンクを生成する
ボタンは、署名済みパスに解決されるインストールURLにリンクします。パスの生成方法は2通りです。AppleのPassKitフレームワークを使って自社で構築する方法（.pkpassの生成・署名とホスティング用サービスの運用が必要）、または署名とホスティングを代行してくれるパス基盤を利用する方法です。前者は自由度が高くバックエンドリソースを持つチーム向け、後者はほとんどのマーケティング・プロダクトチームにとって早く着手できる選択肢です。共通クーポンのような共有パスであれば1つのリンクで全員に対応できますが、特定顧客のポイントを含む会員証のようなパーソナライズされたパスでは、ユーザーごとに固有のリンクを生成し、保存されたパスにその人のデータが反映されるようにします。Pushwoosh Wallet passesのようなプラットフォームを使えば、.pkpassの署名処理を自分で行うことなく、パスを一度作成してインストールリンクを生成できます。
-
配信テンプレートにボタンを設置する
メール配信ツール上で、Apple SVGバッジ（両対応の場合はGoogleボタンも）を配置し、リンク先をインストールURLに設定します。ユーザーごとのパスの場合、多くのメール配信ツールでは固有リンクをパーソナライズ変数として挿入できるため、受信者ごとにボタンの遷移先が個別のパスになります。「iPhoneで開いてください」という一文を添え、Appleのルールに沿って明るい背景にバッジを配置しましょう。
-
クリックだけでなく「保存」を計測する
バッジのクリックは保存ではありません。顧客はパスの追加を確認するステップをもう一段踏む必要があります。実際の「追加」を独立したイベントとして計測し、クリック率ではなくインストール率を測定対象にしましょう。この数値が、配置とオファーの設計が機能しているかどうかを示す指標であり、最適化すべき対象です。保存されたパスこそが、実際に端末に残り続けるものだからです。
1つのリンクを、あらゆるチャネルで
ユーザーごとのインストールリンクを生成し、チャネルごとに手作業で貼り付ける運用は、数キャンペーンを超えると破綻します。リンクはメール・プッシュ通知・SMSのどこに乗せても同じアセットなので、一度生成してあらゆる場所で使い回すのが効率的です。
Pushwoosh Wallet passesを使えば、パスの作成、インストールリンクの生成、プッシュ通知・メール・SMSを横断した配信までを1か所で完結できます。AppleとGoogleのボタンは同じパスを指しており、.pkpassファイルに触れることなく保存状況や更新を管理できます。
Pushwooshでウォレットパスのインストール率を高める
ボタンは一度実装すれば、リンクはあらゆる場所で再利用できます。Pushwoosh Wallet passesは、AppleとGoogle Wallet向けのインストールリンクを生成し、プッシュ通知・メール・SMSを横断して1つのダッシュボードから配信します。SOC 2・ISO 27001認証を備えた基盤なので、情シス審査への対応もスムーズです。
