LASSIC Media らしくメディア
アプリのウォレットパス（Apple Wallet/Google Wallet）を実装する外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Apple WalletとGoogle Walletは技術スタック・証明書体系が異なるため、両OS対応には相応の準備が必要です
- 自社実装とSaaS活用それぞれに向いている状況があり、外注前に方式を選ぶと費用・工期が大きく変わります
- 証明書取得・テンプレ設計・更新プッシュの3点が実装品質を左右します。外注先の選定時に漏れなく押さえましょう
目次
スマートフォンのホーム画面から1タップで会員証やクーポンを取り出せる体験は、顧客接点の利便性を高める手段として小売・飲食・イベント・交通など幅広い業種で活用が広がっています。その基盤となるのがApple WalletとGoogle Walletのパス機能です。
しかしiOSとAndroidでは証明書体系・APIが異なり、発行後のリアルタイム更新も考慮すると技術的なハードルは高めです。本記事では、ウォレットパスの仕組みと実装方式、外注で進める手順、費用の変動要素、外注先選びのポイントを順に解説します。
ウォレットパスとは — 会員証・クーポン・チケットをスマホに格納する仕組み
ウォレットパス（Wallet Pass）とは、会員証・ポイントカード・クーポン・イベントチケット・搭乗券などの情報をiOSのApple WalletまたはAndroidのGoogle Walletに格納し、スマートフォン上で表示・更新できるデジタルカードの形式です。
物理カードや専用アプリのダウンロードを不要にし、ユーザーが普段使いのWalletアプリで一元管理できるのが特徴です。店頭でのバーコードスキャンやNFC読み取りとも連携でき、ポイント残高・有効期限・クーポン状態をサーバー側からリアルタイムに書き換えられます。
なお、Apple Pay・Google Payはクレジットカードや電子マネーによる「決済」の仕組みであり、本記事が扱うウォレットパスとは別の技術です。ウォレットパスはあくまで会員証・クーポン・チケットなど「提示・認証」用途のデジタルカードを指します。
実装方式の比較 — PassKit／Google Wallet API、自社実装 vs SaaS
iOSとAndroidで技術スタックが異なる
iOSのApple WalletはAppleのPassKit（パスキット）フレームワークを使います。パスは.pkpass形式のZIPファイルで、Apple WWDR（Worldwide Developer Relations）認証局による署名と、開発者アカウントで取得したPass Type ID証明書が必要です。
AndroidのGoogle WalletはGoogle Wallet APIを利用します。GenericクラスやLoyaltyクラスなどパス種別ごとにクラスとオブジェクトを定義し、JWTで署名した保存リンクを発行してユーザーに渡します。GoogleアカウントでIssuer（発行者）登録を完了させることが前提となります。
| 比較項目 | Apple Wallet（PassKit） | Google Wallet API |
|---|---|---|
| パス形式 | .pkpass（JSON+画像のZIP） | クラス＋オブジェクト（REST API） |
| 署名・認証 | WWDR証明書＋Pass Type ID証明書 （Apple Developer Program加入が必要） |
JWT署名（Google Cloud Service Account） Issuer登録＋API有効化 |
| パス種別 | Boarding Pass / Event Ticket / Coupon / Store Card / Generic |
Generic / Loyalty / Offer / Event Ticket / Flight / Transit |
| リアルタイム更新 | APNs（Apple Push Notification service） 経由でパスを再取得させる |
クラス/オブジェクトをAPI PATCHで 上書き更新（即時反映） |
| 開発難易度 | 証明書管理・有効期限更新が必要 APNs連携で工数増 |
証明書有効期限なし。 REST APIで比較的扱いやすい |
自社実装 vs SaaS活用 — 選択の目安
両OS対応のウォレットパスを一から自社実装する場合、PassKitサーバーとAPNs連携基盤・Google Wallet APIのREST呼び出しラッパー・証明書ローテーション管理・パステンプレートのCI/CDを個別に構築する必要があります。モバイルバックエンドエンジニアとインフラエンジニアが兼任できる体制でなければ、対応工数が積み上がりやすい構成です。
一方でPassSlot・PassNinja・Walletlyなどのウォレットパス専用SaaS（パスキット代行サービス）を使うと、証明書管理・テンプレートエディタ・更新API・追加導線ボタン生成がまとめて提供されます。月額利用料が発生しますが、自社実装より短期間で両OS対応を完結させられます。
| 比較項目 | 自社実装（フルスクラッチ） | SaaS活用（低コード） |
|---|---|---|
| 初期費用 | 高め（設計・実装・インフラ） | 低め（設定・連携のみ） |
| ランニング | サーバー・証明書更新コスト | 月額ライセンス料（枚数課金が多い） |
| カスタマイズ性 | 高い（独自ビジネスロジック実装可） | SaaSの仕様内に限定される |
| 向いているケース | 発行枚数が大規模・既存基盤との 深い連携が必要な場合 |
小〜中規模・素早くPoC検証したい場合 |
| 外注での対応 | 要件定義〜開発〜テスト一式を委託 | SaaS選定＋テンプレ・連携設定を委託 |
実装の5ステップ — 証明書取得からリアルタイム更新まで
ステップ1：証明書・発行者アカウントの取得
Apple WalletはApple Developer Programへの年間登録（有料）が必要です。証明書はPass Type ID証明書とWWDR中間証明書の2種類を管理し、有効期限が到来したら証明書を更新してサーバーに再デプロイする運用が発生します。
Google WalletはGoogle Pay & Wallet Consoleで発行者（Issuer）アカウントを登録し、本番利用の審査を通過する必要があります。Google Cloud上でサービスアカウントを作成してAPIを有効化し、JWTの署名鍵を適切に管理する体制を整えます。
ステップ2：パステンプレートの設計
パスの見た目（ロゴ・背景色・フィールド名・フィールド配置）と機能（バーコード種別・NFC対応有無）をテンプレートとして定義します。iOSとAndroidで利用できるフィールド配置の仕様が異なるため、両プラットフォームのガイドラインを参照しながらデザインを統一する必要があります。
バーコード種別はQRコード・PDF417・Aztecなど複数の選択肢があり、店頭スキャナーの対応状況に合わせて選定します。バーコードの値に動的なユーザーIDやチケット番号を埋め込む場合は、後述のデータ連携と合わせて設計します。
ステップ3：顧客データとのAPI連携
ポイント残高・会員ランク・クーポン内容などのパーソナライズ情報を既存の顧客DBやポイント基盤から取得してパスに埋め込みます。パスの発行・更新トリガー（会員登録完了・購入・ポイント加算など）をシステム側で検知し、Walletパスサーバーへ通知するイベント設計が必要です。
個人情報（氏名・会員番号・ポイント残高）を扱うため、通信の暗号化・アクセス制御・ログ管理などのセキュリティ対策も設計段階で確定させます。
ステップ4：Walletへの追加導線（Add to Wallet）
ユーザーがパスをWalletに追加するには「Add to Apple Wallet」「Add to Google Wallet」ボタンを会員登録完了メール・マイページ・アプリ内に設置します。Apple/Googleともにボタンのデザインガイドラインがあり、規定に従ったバッジ画像の使用が義務付けられています。
WebページからのWallet追加（メール・LPリンク経由）とアプリ内からの追加では実装方法が異なります。両経路に対応することで、専用アプリを持たないユーザーにもウォレットパスを配布できます。
ステップ5：発行後のリアルタイム更新（プッシュ更新）
ポイント残高・有効期限・クーポン利用済みフラグ・バーコード値などをパス発行後に変更するには、プッシュ更新基盤が必要です。iOSはAPNs（Apple Push Notification service）経由でパスの更新通知を送り、デバイスがサーバーからパスを再取得します。AndroidはGoogle Wallet APIのPATCHエンドポイントを叩けばほぼ即時に反映されます。
この更新基盤を省くと、残高変化がパスに反映されず「店頭で古い情報が表示される」クレームの原因になります。設計初期から更新頻度・更新量・エラー時のリトライ設計を明確にしておくことが大切です。
外注で進める手順 — RFP作成・ベンダー選定・検収
外注前に固める3つの要件
ベンダーに依頼する前に、次の3点を自社で決めておくと見積もりの精度が上がります。
- 対応OS範囲：iOS・Android両対応か、まず片方から始めるか
- 方式選択：自社実装かSaaS活用か（既存基盤の連携深度と発行想定枚数で判断）
- パスの種別と更新要件：発行するパスの種類（会員証/クーポン/チケット）と更新頻度・リアルタイム性の要否
これらが不明確なまま見積もりを依頼すると、後から「iOS対応を追加したい」「リアルタイム更新が必要だった」と仕様変更が生じ、追加費用と工期延長につながりやすくなります。
RFP（要件定義書）に盛り込む項目
ウォレットパス外注のRFPには、次の項目を含めると比較見積もりが取りやすくなります。
- 既存システム構成（顧客DB・ポイント基盤・CMS）とAPI仕様の有無
- 対象ユーザー規模（発行想定枚数・月間更新件数）
- バーコード種別・NFC対応の要否
- 個人情報の取り扱い方針（管理委託の可否・データ保存場所）
- 納期・保守・サポート体制の希望
ベンダー選定から検収まで
RFPを2〜3社に提示して提案書・見積書を比較します。技術面では「PassKit証明書の管理は自社で持てるか」「APNs連携の実績があるか」「Google Wallet APIのIssuer申請の支援経験があるか」を事前に聞いておきます。
開発完了後の検収では、①両OS実機でのパス追加・表示・スキャン動作、②残高やクーポン状態の更新が反映されること、③証明書の有効期限通知フローが動作することを検証します。証明書の有効期限管理をベンダーに委託する場合は、契約書で責任範囲と通知タイミングを明文化しておくと後々のトラブルを防げます。
費用を左右する要素と依頼前の整理ポイント
ウォレットパス実装の費用は対応範囲・既存システムとの連携深度・更新基盤の複雑さによって大きく変わります。以下は費用に影響する主な要素です（参考値であり一次資料に基づく相場ではありません）。
| 費用変動要素 | 費用が上がる方向 | 費用が下がる方向 |
|---|---|---|
| 対応OS | iOS＋Android両対応（設計・テスト2倍） | まず片方から順次対応 |
| 実装方式 | フルスクラッチ（証明書管理・APNs基盤） | SaaS活用（設定・連携のみ） |
| 既存連携 | レガシーDBのAPI化・スキーマ変更が必要 | 既存REST APIで呼び出せる状態 |
| 更新プッシュ | 高頻度リアルタイム更新（APNs基盤構築） | 静的パス（発行のみ・更新なし） |
| パス種別数 | 会員証＋クーポン＋チケットを同時対応 | 会員証1種別からスモールスタート |
依頼前に整理しておくべきポイント
費用見積もりの前に、次の点を社内で整理しておくと交渉・比較がスムーズになります。
- Apple Developer Program加入状況：未加入なら加入費用と証明書取得の工数が別途発生します
- Google Wallet API のIssuer審査：本番利用には審査通過が必要で、審査期間（数営業日〜数週間程度）を工程表に含める必要があります
- 個人情報委託の可否：ウォレットパスには氏名・会員番号・ポイント残高などが含まれます。外部委託先への個人データ提供に関して自社のプライバシーポリシー・委託契約で問題がないか点検します
- 証明書の更新運用：Apple証明書には有効期限があり、更新対応をベンダーに委託するか自社で持つかを決めておきます
外注先の選び方 — 押さえるべき3つの実績軸
ウォレットパスの外注先を選ぶ際は、以下の3つの実績軸でベンダーを評価することをおすすめします。
①両OS（PassKit／Google Wallet API）の開発実績
iOSとAndroidでは証明書体系・APIの設計思想が大きく異なります。片方の実績しかないベンダーに両OS対応を依頼すると、どちらかで手戻りが発生するリスクがあります。提案時に「PassKit証明書管理の運用経験」と「Google Wallet Issuer審査の支援経験」を具体的に問い合わせます。
②リアルタイム更新基盤の構築経験
APNs連携は証明書管理と通知フローの設計が複雑で、実装ミスがあると残高やクーポン状態がパスに反映されない障害につながります。「APNs経由のパス更新を本番稼働させた経験があるか」「エラー時のリトライ設計をどう実装したか」を問い合わせます。
③既存基盤との連携・個人情報取り扱い実績
顧客DBやポイント基盤との連携には既存システムへの理解が必要です。レガシーシステムとのAPI設計経験を持つベンダーは、追加工数を最小化しやすい傾向があります。個人情報の取り扱いについては、プライバシーマーク取得や情報セキュリティマネジメント（ISMS）認証の有無も選定の目安になります。
なお、SaaSを活用する方式を選ぶ場合は、ベンダーのSaaS選定・設定・既存システム連携の実績を重視します。自社実装とSaaS活用では必要な技術スタックが異なるため、方式を決めた上で外注先を絞り込むと効率的です。
まとめ — ウォレットパス外注を成功させる3つの判断軸
本稿ではApple Wallet・Google Walletパスの実装方式、外注で進める手順、費用の変動要素、外注先の選び方を整理しました。要点を3つに集約します。
第一に、iOSとAndroidは技術スタックが異なります。PassKitは証明書管理・APNs連携への対応が求められ、Google Wallet APIはREST呼び出し中心と設計思想が対照的です。両OS対応の場合は、それぞれの実績を持つベンダーを選ぶことが重要です。
第二に、自社実装かSaaS活用かを発行枚数・カスタマイズ要件・既存基盤の連携深度で判断します。スモールスタートならSaaS活用が費用・工期ともに有利で、大規模発行や独自ビジネスロジックが必要な場合はフルスクラッチが選ばれます。
第三に、リアルタイム更新基盤を設計初期から組み込むことが大切です。後から更新機能を追加すると再設計コストが膨らみます。残高・有効期限・バーコード値の更新頻度と要件を要件定義段階で明確にした上で外注先に共有しましょう。
よくある質問
Apple WalletとGoogle Walletのパス、どちらから実装を始めるのがよいですか？
自社ユーザーの主要OSに合わせて判断するのが現実的です。国内ではiOSユーザーが多い業種も多いためApple Walletから着手するケースが見られますが、Android比率が高いユーザー層を持つサービスではGoogle Walletを先行させる場合もあります。両OS同時対応の場合、Google Wallet APIはREST呼び出し中心で証明書有効期限管理が不要なため、先行して動作検証しやすい面があります。まずPoC（概念実証）として片方を実装し、運用フローを把握してから両対応に拡張するスモールスタートも有効です。
SaaS型のパス発行サービスを使えば開発なしで実装できますか？
SaaS（PassSlot・Walletlyなどのウォレットパス代行サービス）を使うと、証明書管理・テンプレートエディタ・更新APIが提供されるため、自社でPassKitサーバーを構築する必要がなくなります。ただし、既存の顧客DBやポイント基盤とデータを連携させる部分は、SaaSが提供するWebhook・REST APIを介した設定・開発作業が残ります。「開発ゼロ」にはならない点に注意が必要です。既存システムとの連携設計は外注先に依頼することで工数を削減できます。
ウォレットパスに含まれる個人情報の取り扱いで注意すべき点はありますか？
ウォレットパスには氏名・会員番号・ポイント残高などの個人情報が含まれます。外注先にパスの発行・更新処理を委託する場合は、個人情報保護法に基づく委託先の安全管理措置の点検と、委託契約における守秘義務・再委託の制限を明文化することが求められます。Apple・Googleのデベロッパーガイドラインでも、パスに含めるデータの最小化と適切な暗号化が義務付けられています。外注先のISMS認証やプライバシーマーク取得状況を調べ、データ保存場所（国内／海外）についても事前に合意しておくことをおすすめします。
Apple Wallet証明書の有効期限が切れるとどうなりますか？
Pass Type ID証明書の有効期限が切れると、新規パスの発行ができなくなります。既存ユーザーが保持するパスの表示は継続されますが、残高変更などの更新プッシュが届かなくなる場合があります。証明書の有効期限管理を外注先に委託する場合は、更新対応の責任範囲と通知タイミングを契約書に明記することが大切です。Apple Developer Programへの年次更新も合わせて管理スケジュールに組み込んでおく必要があります。
既存のポイントアプリに後からウォレットパス機能を追加することはできますか？
既存アプリにウォレットパスの追加導線（Add to Apple Wallet / Add to Google Walletボタン）を組み込むことは可能です。ただし、パスに表示するポイント残高や会員情報をリアルタイムで反映させるには、既存のポイント基盤との連携APIとプッシュ更新基盤を新たに設計・実装する必要があります。既存システムの設計によっては、連携のためのAPIを新規開発する工程が生じることがあります。追加対応の影響範囲をシステム担当者と整理した上で、外注先に現状のシステム仕様を共有することをおすすめします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Inc.「PassKit（Apple Developer Documentation）」（2024年）
- *2 出典：Google LLC「Google Wallet API（Google Developers）」（2024年）
