鈴木淳也のPay Attention
第286回
Apple PayとGoogle Payの違いにみる「Androidのマイナンバーカード」
2026年8月28日 08:20
6年近く前の2020年12月、「Apple Payが日本にやってくるまでの話」と題してApple Pay登場前後の話題を振り返ったが、それから時代は移り変わり、“モバイルウォレット”を取り巻く情勢もいろいろ変化してきた。
今回は技術面からApple Pay(Wallet)を振り返りつつ、Androidスマートフォンとの仕様上の違い、そして2026年秋にリリースされる「“Android”のマイナンバーカード」の実装方法について触れたい。
最新のApple Payの実装はどうなっているのか?
UWB(Ultra Wide Band)を絡めた最新動向については直近のレポートで触れているが、まずはApple Payの基本動作についておさらいする。
Apple Payでは決済に必要なカード情報等をセキュアエレメント(SE)に保存しており、このセキュアエレメントを本体に内蔵する「eSE」方式を採用している。SEはNFCコントローラを介してNFCアンテナに接続されており、これを使って“非接触”での“タッチ決済”が可能となる。
SEはJava Cardの仕様に則った一種の小さなコンピュータであり、データを安全に保管するためのストレージを備えているが、その容量は多くても数MB程度と非常に限られている。
ICチップ付きクレジットカードやSuicaのような交通系ICカード、マイナンバーカードなど、今日利用されるスマートカードは基本的にこのJava Cardのハードウェアをベースに、国際標準のGlobalPlatformに準拠する形で内部で動作する“アプレット”やデータの入出力が制御される。
ただし前述のように容量上の制限があり、1枚のカードに登録可能な“アプレット”やデータは限られる。そのため、eSEを利用するiPhoneでも同様の制限がある。
Apple Payがリリースされた当初「(Walletに)登録可能なカードは最大8枚」のような制限があったのはこれが理由だ。その後、Walletにおけるカード枚数制限は段階的に緩和されていったが、これは最新機種になるほど搭載されるeSEの世代が新しくなり、容量も増加したことに起因する。
この仕組みが大きく変わったのは2023年9月にiOS 17が提供されて以降だ。
同年に欧州で「デジタル市場法(DMA：Digital Markets Act)」が施行され、Appleに対してもそれまで同社が独占してきたiPhoneのSEへの“アクセス”権がやり玉に挙がる機会が増えていた。ただ、EU DMAに合わせてサードパーティに無作為にSEのセキュア領域を開放すると当時で最大16枚までだったカード上限が一瞬で食い潰される可能性があり、このタイミングで“Walletを介さない”SEへのアクセス手段がサードパーティに開放されると同時に、Wallet上でのカード枚数上限を事実上撤廃するダイナミックロード/アンロードの仕組みが導入された。
従来までの仕組みでは、iPhoneのSEにカード情報を含むアプレットがすべて格納される形式だったものが、状況に応じてSecure Enclaveによって保護された領域にアプレットを待避(アンロード)したり、逆にアプレットをSEに書き戻す(ロード)したりする方式に変更したことで、実質的にカード枚数の登録上限がなくなった。
Secure Enclaveとは2013年にiPhone 5sがTouch IDを搭載した際に発表された仕組みで、AppleのAシリーズSoCに内蔵されたメインプロセッサとは独立したセキュリティサブシステムであり、Touch ID/Face IDの生体情報やiCloudのキーチェーンを暗号キーを使ってメインストレージ(NAND)内に保護領域を作って保管する。
ストレージこそ共有するもののハードウェア的にメインシステムとは独立しているため安全性は高く、容量不足が懸念されるSEの退避先としての機能を持たされたわけだ。
このSEとSecure Enclave間のロード/アンロードは自動的に行なわれ、例えばよく利用される“カード”であればSE内にアプレットが残っている可能性が高いため、アクティブ/非アクティブの切り替えで対応でき、もしSEの容量が不足したと判断されれば“古い”カードから自動的にSecure Enclave側にアンロード(スワップ)される。
なお、エクスプレスカードに設定されたカードは“優先順位”がトップで固定されるため、このようなダイナミックロード/アンロードの仕組みからは除外される。スワップが発生すると単純なアクティブ/非アクティブの切り替え(実質的には“優先順位”を入れ替える処理のことを指す)よりもレスポンスが落ちるため、反応速度を重視するエクスプレスカードではつねにSEの保護領域内にアプレットが残る形となる。
Androidの2種類あるGoogle Pay実装
冒頭で紹介した記事でも触れたように、AndroidスマートフォンのGoogle Payは基本的に「HCE(Host Card Emulation)」でNFCによる“非接触”の“タッチ決済”機能を実装している。
HCEはeSEなどのSEを使わない方式で、NFCコントローラがSEではなくホストOS(この場合はAndroid)内の領域と通信することでNFCによるセキュア通信を実現している。ただし、ハードウェア的に保護されたSEとは異なり、HCEではホストOSやメインプロセッサがその制御を担うことになるのでハッキングによる漏洩や被害が問題となる。そこで登場するのがTEE(Trusted Execution Environment)とLUK(Limited Use Key)だ。
TEEはメインのホストOS(Android)とは独立した状態で動作する保護領域で、今回のケースでいえばLUKを保管する領域として動作し、NFCにおけるカードエミュレーション(CE)モード上で通常の“タッチ決済”の振る舞いを“エミュレーション”する。
TEEはTrustZoneなどの仕組みで構築され、RTOS(Real Time OS)などのセキュアOSが動作している。TrustZoneはeSEやAppleのSecure Enclaveのような専用のプロセッサ機構がなくても、メインプロセッサがモードを切り替えることでセキュア領域のプロセッサとして動作可能な仕組みを提供する。
ARMv7以前のTrustZoneはメモリ保護やレジスタの自動リフレッシュ機能がなかったため、OSの実装によってはモード切り替え時にセキュア領域内のデータを推測される危険性があったものの、ARMv8以降の命令セットではハイパーバイザが標準搭載されたため、TEEがより安全な形で保護されるようになっている。
このTEEと組み合わせることでより安全な決済を可能にするのがLUKだ。
Apple Payでは「PAN(Primary Account Number)」と呼ばれる15〜16桁のクレジットカード番号を直には使わず、「トークン」と呼ばれる別の番号を割り当て決済させることで(トークナイゼーション)、カード番号漏洩などのリスクを減らして安全性を高めている。
LUKも同様にデバイスごとに発行された“使い捨ての暗号キー”であり、その最大の特徴は「有効期限や使用回数が設定されている」点にある。つまり、HCEでは定期的にデバイスをオンライン状態にしてTSM(Trusted Service Manager)というアプレットのマスターキー管理を行なうサーバに接続して情報をリフレッシュしなければならず、この点がオフライン状態を(基本的には)継続できるApple Payとの大きな違いとなる。
そしてGoogle Payの2種類あるうちのもう1つの実装方法が「おサイフケータイ」のようなeSE方式だ。
Google Payとしては日本固有の実装形態であり、その理由はFeliCaにある。FeliCa SEはその仕様上、HCEとしては実装できないため、“ガラケー”と呼ばれた従来型携帯電話同様にeSEを内蔵する方式を採用することになった。「HCE-F」というFeliCa版HCEのような仕様が存在するが、HCE-FはあくまでFeliCaの通信インターフェイスをエミュレーションするだけであり、TEE上でFeliCa SEの動作を保証するものではない(いろいろ説はあるが速度要件を満たして検証をパスするのが難しいと言われる)。
結果として日本におけるGoogle PayはHCEとeSEの混在となっている。
クレジットカードなどの“タッチ決済”ではHCEを用いつつ、モバイルSuicaやiD/QUICPayなどのFeliCaベースの決済手段ではeSEを用いる。そのため、eSEを搭載しないおサイフケータイ未対応端末では後者のサービスを利用できず、また次項で説明する「“マイナンバーカード”を搭載可能なAndroid端末」にも影響することになる。
余談だが、iPhoneで行なわれているようなダイナミックロード/アンロードの仕組みはAndroidでは採用されていない。理由としてはSuicaやPASMOのような交通系ICカードをおサイフケータイで利用する際、FeliCa SEのセキュア領域を“がっつり”と押さえてしまうため、動的スワッピングによるメモリ管理が難しいことがあるようだ。
「“Android”のマイナンバーカード」で変わる実装方法
現在、Androidにおけるマイナンバーカードは「署名用電子証明書」と「利用者証明用電子証明書」の2種類の電子証明書が搭載されるのみで、(住所・氏名などの)券面情報の取得が行なえない。そのため、Androidスマートフォンを使って本人確認や電子署名はできても、例えば入力フォーム上でマイナンバーカードに記載された券面情報を使ってフィールドを埋めたり、入力した情報自体が正しいのかは相手側が確認することができない。
それが、今秋リリースされる「“Android”のマイナンバーカード」ではiPhoneと同様の方式に変更され、券面情報の確認のみならず、IHV(Issuer, Holder, Verifier)モデルに則った「検証可能証明書(VC：Verifiable Credentials)」によるデジタル身分証(DIW：Digital Identity Wallet)の本人確認証明が行なえる。
現状でAndroidにおけるマイナンバーカードは「おサイフケータイ対応機種」に対応が限定されている。理由としては電子証明書が「GP-SEに搭載される」(デジタル庁)ということで、実質的に国内で販売されるAndroid端末に搭載されているおサイフケータイのFeliCa SE(つまりGP-SE)の利用を前提としているからだ。
デジタル庁内でもいろいろ議論があったようだが、電子証明書の搭載にFeliCa SEを用いるのは互換性を重視したからだと思われる。以前、関係者に話を聞いた際、「(マイナンバーカードが利用する)Type-Bは読み取りの相性問題が大きい」とコメントしていた。Type-Bは仕様上の理由から機器間通信の判定がシビアで設計が難しく、ノイズ等の外部要因ですぐに通信が寸断するといった課題があるようだ。
そのため、NFCを搭載した幅広い端末をサポートするのではなく、RF性能や相互接続試験を厳密にクリアしたおサイフケータイ対応機種であれば問題が少ないと判断し、このような実装になったとみられる。
だが間もなく登場する「“Android”のマイナンバーカード」ではこれを見直し、eSEを使わない方式を採用する。具体的には「StrongBox」という仕組みを用い、ここで保護される領域にマイナンバーカードの情報を保管し、iPhone同様にGoogle Wallet標準の仕組みに則る形でデジタル認証を可能にする。
StrongBoxはシンプルにいえば、AppleのSecure Enclaveと同様のメインプロセッサとは独立して動作するセキュリティサブシステムだ。先ほどHCEで利用するTEEではメインプロセッサのTrustZoneを用いていると述べたが、StrongBoxを用いることでより安全性を高めることが可能なため、この仕組みを用いてTEEを構築しているケースもある。
StrongBoxで提供されるセキュア領域には決済情報やデジタル証明書に加え、ロック解除など生体認証に使う情報などが保管される。ただAndroidではiPhoneとは異なり、Appleのような単一ベンダーによってハードウェアとソフトウェアが垂直統合されているわけではないため、StrongBoxのような仕組みを実際に搭載するかどうかも含めAndroid端末を出荷するメーカーの判断に実装方法が委ねられている。
例えばGoogleではPixelに「Titan」と呼ばれる専用のセキュリティチップを採用しているほか、QualcommのSnapdragon SoCには「SPU(Secure Processing Unit)」というメインCPUとは独立した処理ブロックが存在しており、ハードウェア自体が異なる。そのため、StrongBoxはHAL(Hardware Abstraction Layer)という形でハードウェア部分を抽象化する仕様になっており、この点で実装上の柔軟性がある。
現在日本で出荷されるほとんどのスマートフォンはStrongBoxに対応していると思われるが、輸入品やミッドレンジ/ローエンドモデルなどではその限りではない点に注意したい。
現在、Androidにおけるマイナンバーカード搭載対応機種はメーカー側の検証結果を経てデジタル庁側のデータベースに反映されるホワイトリスト方式を採用しているため、次期「“Android”のマイナンバーカード」でおサイフケータイ対応が必須ではなく、StrongBoxベースに移行して対応可能機種が広がったとしても、必ずしも正式対応に含まれることを保証しない。
また、StrongBoxのような専用ハードウェアでTEEの仕組みが代替されることになり、「近いうちにFeliCa SE非搭載機種でもStrongBox経由でサポートされるのでは?」と考えた方がいるかもしれないが、おそらくそれも難しいだろう。そもそもおサイフケータイ対応にはFeliCa用のミドルウェアの組み込みやFeliCa検定をパスする必要があり、この課題がクリアできるわけではない。