「アプリ疲れ」のユーザに効くAppleウォレット・パス
スマートフォンの普及以降、多くの企業が顧客との関係を深めるために自社アプリを開発してきました。会員証やポイント管理、クーポン配布、予約、プッシュ通知などを一つのアプリにまとめ、継続的な利用を促してきたのです。
しかし、ユーザが新たにインストールし、継続的に利用するアプリの数には限りがあります。日常的に利用するサービスならともかく、数カ月に一度しか訪れない店舗や、年に数回しか使わないサービスのためにアプリをダウンロードし、会員登録まで行うことは、多くの人にとって負担です。
ユーザに「もう一つアプリを入れてもらう」こと自体が、企業にとってはすでに顧客獲得の障壁になっているのです。加えて、アプリの維持も悩みの種です。毎年のiOSアップデートへの対応に加え、セキュリティ対策、不具合修正、App Store審査、ユーザサポートなど、継続的な開発・運用コストが発生します。十分な利用頻度を確保できないまま、投資負担だけが積み上がっていくケースも珍しくありません。
顧客とデジタルでつながりたいものの、自社アプリを維持する予算や人員が足りない企業も多くいることでしょう。アプリを公開したものの、十分に活用されていないケースもあります。iOS 27におけるAppleウォレットの新機能は、そうした企業にとって現実的な選択肢になり得ます。
レガシー環境を活かす4つのバーコード
iOS 27では、AppleウォレットのパスにEAN-13、Code 39、Codabar、ITFの4種類のバーコードが追加されます。従来から対応していたQR、PDF417、Aztec、Code 128と合わせ、既存の業務システムで使われている幅広いバーコード形式を扱えるようになります。
いずれも目新しい規格ではありません。EAN-13は小売、Code 39は製造や在庫管理、Codabarは物流、医療、図書館、ITFは梱包や物流など、いずれも既存の業務環境で長く使われてきた形式です。
つまり、これはウォレット側を既存の業務インフラへ近づけるアップデートといえます。店舗や施設で使われているPOS、ハンディターミナル、バーコードリーダーで読み取れる形式をそのまま採用できれば、受付やレジの機器を大規模に入れ替えることなく、会員証や入館証をデジタル化できる可能性が高まります。
特に中小規模の小売店や、長年同じPOSを運用してきたチェーンでは、1次元バーコードを読み取るレーザー式スキャナーが今も現役で使われています。EAN-13やCode 39への対応により、こうしたビジネスは既存設備を活かしたまま、デジタルパスの導入を検討しやすくなります。
この拡張はiOS 27の新機能の中では目立たない存在ですが、レガシーインフラとデジタル体験をつなぐという点で、実務上の意味は小さくありません。
ユーザーによるパス作成と企業発行、二つの入口
iOS 27におけるウォレットの目玉の一つが、会員証やポイントカードなどから、ユーザー自身がAppleウォレットのパスを作成できる機能です。
バーコード付きのカードをiPhoneの「カメラ」アプリで読み取ったり、あるいはデジタルカードのスクリーンショットを認識させて、ウォレットにパスとして追加します。登録したパスはiPhoneやApple Watchから提示できます。
同時にAppleは企業向けにも、ウォレット・パスの内製化を支援する新しいツールを用意しました。パスを設計するMac用アプリ「Pass Designer」と、パスの個人化・署名・生成をサーバー側で処理する「Pass Builder」です。
Pass DesignerとPass Builderで内製化が現実に
これまでウォレット・パスを本格的に発行するには、PassKit独自のファイル構造を理解し、サーバー側で個別に署名（暗号署名）を行い、配布可能なパッケージにまとめる必要がありました。そのため、専門ベンダーへ開発や運用を委託する企業が少なくありませんでした。
Pass Designerは、作成中のパスがiPhoneやApple Watchでどのように表示されるかを視覚的に確認しながら編集できるWYSIWYG型のMacアプリです。背景や文字の色、画像、表示項目、バーコードなどを画面上で設定でき、問題のある項目や不足している定義も検証します。プログラムコードだけを見ながらレイアウトを調整する必要がなくなるため、デザイナーやマーケティング担当者もパスの設計に参加しやすくなります。
一方のPass Builderは、Pass Designerで作成したテンプレートを基に、顧客ごとの情報を組み込み、署名済みのパスを生成するSwift on Serverパッケージです。パスの内容一覧を示すマニフェストの生成、電子署名、検証、パッケージ化などを担います。企業はPass Builderを既存の顧客データベースや会員管理システムと連携させることで、会員番号、顧客名、ポイント数などが異なるパスを、顧客ごとに生成できます。
これにより、期間限定クーポンのテンプレートを作成し、既存の顧客基盤から対象者ごとのパスを生成・配布するといった運用がしやすくなります。変更のたびに外部ベンダーへ依頼するのではなく、デザイン、マーケティング、情報システムの各部門が連携し、より短いサイクルで施策を展開できる可能性が開けます。
パスからWebへつなぐ「フィーチャードアクション」
企業にとってもう一つ重要なのが「フィーチャードアクション」です。iOS 27では、すべてのパス形式に最大2件のアクションを設定し、パスの下部にタイルとして表示できるようになります。ユーザがタイルを選ぶと、Universal Linkを通じて企業のWebページなどへ移動する仕組みです。
たとえば、会員証から予約ページを開く、会員特典を確認する、店舗への経路を調べる、イベント情報を見るといった導線を設けられます。
重要なのは、複雑な機能をすべてウォレット内に実装する必要がない点です。頻繁に利用する会員証やチケットはウォレットに置き、予約、購入、登録情報の変更などはWeb側で処理する。ウォレットをOS標準の入口として使い、実際のサービスをWebアプリで提供する構成が取りやすくなります。
アプリかウォレットか、顧客接点を切り分ける
ウォレットのパスがこれほど充実すると、自社アプリとの役割が重なる部分も出てきます。ただ、両者は単純な競合関係にはありません。それぞれの利点は明確です。
会員限定コンテンツ、複雑な検索や予約、ゲーミフィケーション、詳細な通知設定、オフライン処理などを作り込むなら、依然としてネイティブアプリが適しています。顧客が日常的に利用するサービスであれば、アプリへの投資は正当化されるでしょう。
一方、ウォレット・パスはApp Storeからのインストールを必要とせず、Webサイト、メール、メッセージ、QRコードなどから追加できます。アプリのような多機能性はありませんが、会員証やチケットの提示、必要なタイミングでWebサービスへ顧客をつなぐ用途には適しています。
利用頻度の低い店舗、期間限定イベント、観光施設、スポーツクラブ、地域の小売チェーンなどでは、単発のイベントや利用頻度の低いサービスのためだけにアプリのインストールを求めることは、顧客の離脱要因になりかねません。こうしたケースでは、ウォレットを入口にして機能をWebで提供する方が、ユーザの負担と企業の開発コストを抑えられる可能性があります。
「顧客接点の民主化」から始まる次のデジタル戦略
ただし、Appleウォレット自体が顧客データを蓄積・分析するCRM（顧客関係管理）になるわけではありません。顧客情報の管理、同意の取得、セグメント分け、利用履歴の分析、キャンペーン効果の測定などには、別途CRMや会員管理システムが必要です。
それでも、ウォレットはネイティブアプリより軽量な顧客接点として機能します。言い換えれば、Appleウォレットは、企業の顧客基盤とユーザーを結ぶOS標準のフロントエンドになり得るのです。
ウォレットを活用することで、自社アプリへ大規模な投資ができない企業でも、Appleが用意したUIと配布基盤を使い、高品質なデジタル会員証やクーポンを提供しやすくなります。いわば「デジタルな顧客接点の民主化」です。
ユーザ側にとっても、あまり使わないアプリでホーム画面を埋め尽くすことなく、OS標準の洗練されたUI/UXの中でお気に入りの店舗と摩擦のない関係を維持できるというメリットがあります。
今年のWWDCでは生成AI関連の発表に注目が集まり、ウォレットのアップデートは相対的に目立ちにくい存在でした。しかし、「自社アプリをどうすべきか」という問いに頭を悩ませてきた企業にとっては、今後のデジタル戦略を見直すきっかけとなる重要な変化です。
iOS 27でAppleウォレットは、カードを保管する場所から、企業と顧客をつなぐ軽量なサービス窓口へと変わり始めています。
会員基盤やクーポン施策を検討する企業にとって、論点はもはや「アプリを作るかどうか」だけではありません。日常的に使われる機能はアプリで提供し、会員証、チケット、クーポン、予約への入口はウォレットに任せる。顧客接点を用途に応じて切り分けることが、有力な選択肢になりつつあります。
ただし、その適否は既存の設備やシステムによって異なります。すでにPOS、会員管理システム、顧客データベースを運用している企業ほど、新しい枠組みに自社の顧客接点を当てはめ、導入効果や既存システムとの互換性を検証する価値があります。
