地域におけるデータ利活用のためのコード決済情報等の取得に係る標準 API ガイドライン

2021 年 4 月 27 日
一般社団法人キャッシュレス推進協議会

目次
1

2

3

4

5

6

はじめに ............................................................................................................................ 3
1.1

データ利活用の必要性、キャッシュレス化の意義について ......................................... 5

1.2

地域のデータ利活用を取り巻く課題について ............................................................... 6

1.3

本書の位置付け .............................................................................................................. 7

1.4

適用範囲 ....................................................................................................................... 11

1.5

本書の想定読者 ............................................................................................................ 13

1.6

本書の構成 ................................................................................................................... 14

決済情報等の取得方法と課題........................................................................................... 16
2.1

決済情報等取得フロー ................................................................................................. 16

2.2

決済情報等取得に関わる課題 ...................................................................................... 25

データ間の紐付け ............................................................................................................ 28
3.1

基本的な考え方 ............................................................................................................ 28

3.2実現方式の例 ................................................................................................................ 30

データの集め方 ............................................................................................................... 34
4.1

基本的な考え方 ............................................................................................................ 34

4.2

電文仕様標準 ................................................................................................................ 34

4.3

利用者属性データと購買データ ................................................................................... 42

4.4

連携方式の拡張（連携方式②） ................................................................................... 44

4.5

連携方式の拡張（連携方式③の方向性） .................................................................... 55

地域ウォレットの実装に向けて ....................................................................................... 60
5.1

本書の改訂方針 ............................................................................................................ 60

5.2

決済事業者とデータ連携を始めるにあたり考慮する留意点 ....................................... 60

5.3

地域ウォレットとのデータ連携に伴う決済事業者の業務 ........................................... 62

5.4

決済事業者との共創に向けて ...................................................................................... 63

5.5

本ガイドラインの改訂検討項目 ................................................................................... 63

用語集 ............................................................................................................................. 65

2

1 はじめに
本書は、総務省「地域における決済情報等の利活用に係る調査」を踏まえて作成された「地域におけるデータ利活用のためのコード決済情報等の取得に係る標準 API ガイ
ドライン」と「地域におけるデータ利活用のためのコード決済情報等の適正な取扱に関するガイドライン」のうち、前者の「地域におけるデータ利活用のためのコード決済情報等の取得に係る標準 API ガイドライン」である。

政府は、「成長戦略フォローアップ」（令和元年 6 月 21 日閣議決定）において、2025
年 6 月までにキャッシュレス決済比率を倍増し、4 割程度とすることを目指している。
新たなデータの蓄積や、現金処理コストの削減による店舗の生産性向上、消費者の支払いにおける利便性向上等を実現する観点から、キャッシュレス化の推進を掲げ、その更なる進展が期待されている。
キャッシュレス決済のうち、モバイル端末を用いたバーコード・QR コード1決済（以下、コード決済という）は、その低廉な手数料等から地域の店舗にとって導入が容易であり、地域のキャッシュレス化を推進する上で効果的な決済手段である。

総務省は「コード決済に関する統一技術仕様ガイドライン」 2 に基づき、統一 QR「JPQR」を活用した実証事業を「統一 QR『JPQR』普及事業」として令和元年度に実施した。同事業において、小規模店舗を含め「JPQR」を活用したコード決済を地域で面的に導入するためのモデルを確立し、地域におけるキャッシュレス決済比率の向上を後押しした。
既にコード決済の導入が進んでいる地域では、店舗の生産性向上、消費者の支払いにおける利便性向上等を実現しており、店舗や消費者はキャッシュレス化による更なるメリットを期待している。例えば、店舗は決済金額・決済日時等を活用することで需要傾向を把握しやすくなり、消費者は個人の消費行動に併せて店舗からきめ細かいサービスを受けられるようになる。このように店舗や消費者にとっての継続的なメリット
をよりわかりやすく提示することが地域全体にキャッシュレス化、決済データの利活用を広げる上で重要となる。
しかしながら、現状では新たなデータの蓄積や決済データの利活用は進んでいない。
その理由の一つとして、決済事業者や店舗が分断してデータを保有し、異なる事業者間
1

QR コード®は、株式会社デンソーウェーブの登録商標である。

2

一般社団法人キャッシュレス推進協議会（以下、キャッシュレス推進協議会という）公表の Ver2.0（公表日令和 2 年 4 月 27 日）
参照 URL：https://www.paymentsjapan.or.jp/wordpress/wp-content/uploads/2020/04/MPM_Guideline_2.0.pdf

3で共有しづらいことが挙げられる。決済データを授受する API 等、決済事業者とデー
タ利活用を推進したい第三者の間で決済データ連携に係るルールがなく、結果として決済データを流通させづらい状況になっている。
総務省は、決済データの利活用に向けて、決済事業者等から決済データを取得する際の API 接続、及び決済事業者の持つ決済データや店舗の持つ購買データを扱うためのルール作りを促すために、令和 2 年度「地域における決済情報等の利活用に係る調査」を実施した。
本調査では、決済データ等を地域で利活用する場面を仮説的に設定したモデル事業に取組み、それぞれのケースにおいて、決済事業者とデータ利活用を推進したい第三者の間で決済データ等の連携を行う際に必要な要件の洗い出しを実施した。また、洗い出した要件を基に、決済事業者等から決済データを取得する際のルール作りや、決済事業者の持つ決済データ、店舗の持つ購買データ、及びコード決済を利用した利用者の属性
データ（以下、利用者属性データという）を第三者が扱うためのルール作りを実施した。
モデル事業を通して作成したルールをガイドラインとしてまとめる際には、キャッシュレス推進協議会と連携しながら作成した。
仮説的に設定したモデル事業内容は、地域における決済データの利活用に向け、決済
データの発生源である決済事業者、店舗や消費者、自治体・公共機関等にとって長期的なインセンティブ創出につながるように設計し推進した。加えて本書は、モデル事業実施地域以外において決済データや購買データ等の利活用を試みる際の参考となるように設計したガイドラインである。

（参考）
1.

地域におけるデータ利活用のためのコード決済情報等の取得に係る標準 API ガイド
ライン
コード決済に係る既存の決済事業者、及び今後事業を開始する決済事業者や地域ウ
ォレット事業者3（以下、決済事業者等という）が、データを利活用する基盤（以下、
データ利活用基盤という）に対して決済データ等を連携する際のルール作りを目的としたガイドラインである。決済事業者等が、決済データ等を連携してデータを利活用す
る基盤を整えるための指針の一つとして位置づけられる。総務省「地域における決済情3

地域ウォレット事業者とは、地域ウォレットを提供する事業者を指す。地域ウォレットとは、地域利用者にとって、その地域の中での暮らしや体験のために身近にあると役に立つものが「財布」のようにまとめて管理されているスマートフォンアプリケーションと本書では定義する。詳細は本書「1.3 本書の位置付け」を参照4

報等の利活用に係る調査」におけるモデル事業を通じて、必要とされる API 等の仕様
標準を検証し作成された。

地域におけるデータ利活用のためのコード決済情報等の適正な取扱に関するガイド

2.

ライン
データ利活用に係る各関連事業者（自治体、データ利活用基盤の運営主体、決済事業者、店舗等）（以下、各関連事業者という）が決済データや購買データを取扱い、利活用する際のルール作りを目的としたガイドラインである。各関連事業者が決済データ等を連携して、データ利活用基盤を整えるための指針の一つとして位置づけられる。総務省「地域における決済情報等の利活用に係る調査」におけるモデル事業を通じて、決済データを取扱う上での望ましい運用上のルール（同意取得のあり方、データフロー、
セキュリティ要件等）を検証し作成された。

1.1 データ利活用の必要性、キャッシュレス化の意義について
政府は「まち・ひと・しごと創生長期ビジョン（令和元年改訂版）及び 第 2 期『まち・ひと・しごと創生総合戦略』」4にて、国として目指すべき大きな柱として、「将来にわたって活力ある地域社会の実現」を掲げており、地域社会の課題解決を中心に据えている。また、総務省は「地方公共団体におけるデータ利活用ガイドブック Ver.2.0」
にて、地方公共団体が直面する地域社会の課題解決手段として、データ利活用の必要5

性を表明している。しかし、地方公共団体におけるデータ利活用においては、紙媒体による情報管理、データ形式の不統一化、各種データの共同管理の未実施等多くの課題がある。地域社会の課題解決手段としてデータを活用するためには、まず取扱うデータを取得し、整理する所から始める必要がある。決済データにおいては、キャッシュレス化
がこのデータ取得と整理をするための後押しとなり得る。

キャッシュレス化とデータ利活用が地域全体に広がると、次のような社会課題解決の糸口がみつかることが期待される。
• 決済データや購買データと周辺情報を組み合わせることで、消費者の見える化ができ、買い物弱者、交通弱者の支援等に役立つサービスが生まれる。それにより
4

まち・ひと・しごと創生長期ビジョン（令和元年改訂版）及び 第 2 期「まち・ひと・しごと創生総合戦略」が閣議決定（公表日令和元年 12 月 20 日）参照 URL：
https://www.kantei.go.jp/jp/singi/sousei/info/pdf/r1-12-20-gaiyou.pdf
5

総務省情報流通行政局公表 地方公共団体におけるデータ利活用ガイドブック Ver.2.0（公表日令和元年

5 月 21 日）参照 URL：https://www.soumu.go.jp/main_content/000620312.pdf

5消費者の生活が変化し、それが課題解決の糸口になる。実際に幾つかの地方公共団体では、キャッシュレス化に取組み、「地域の稼ぐチカラの向上」「新しいサービスの提供」等で成果を創出することに成功している6。
• 決済データや観光資源の情報と観光客の属性情報を組み合わせることで、特定地区に偏る混雑の解消や、人流の分散が見込める。それにより観光客の満足度が向上するだけでなく、周辺地域への送客や注目度が低かった観光資源の発掘等に繋がり、観光地が抱える課題解決の糸口となる。
• 自治体が中心となり、貨幣とは異なる地域内限定のポイント等、独自通貨を作る
ことで、地域内の消費や流通を活性化させる施策が見込める。それを持続することにより、 地域の経済・コミュニティの付加価値向上に繋がり、過疎化が進む地域が抱える課題解決の糸口となる 。

1.2 地域のデータ利活用を取り巻く課題について
前項にて地域の社会課題解決や地域活性化のためにデータ利活用の有効性を示したが、データの利活用推進にあたり現状では大きく三つの課題が存在する。自治体等がこれらの課題に対応する負荷を回避すべくデータ利活用を断念すると、結果として地域の利便性が損なわれる可能性がある。
本書は、こういった事態にならぬよう、決済事業者とデータ利活用を推進したい第三者との間での決済データ連携に係るルールをガイドラインとして定め、自治体等がデータ利活用に取り組む手続の複雑化を防ぐことを図るものである。
1.2.1

データの所有者と所在の課題
一般的に複数種類のデータを組み合わせることで新たな事象を発見できることがある。決済データを例にとると、購買商品の情報を含む購買データやコード決済を利用した際の利用者属性データと突合することで消費行動を類型化できる等、新たな価値を生む見込みがある。しかし現状では、決済データは決済事業者に、購買データは店舗に存在し、利用者属性データは消費者のスマートフォンアプリ等に利用が制限された状態で存在している。データの所有者が異なり所在も分散しているため、複数種類のデー
タを組み合わせて活用することは困難である。

6

経済産業省公表キャッシュレス・ビジョン外伝 キャッシュレスから始めるデータ利活用 ～地域と中小企業編～（令和 2 年 3 月公表）
参照 URL：https://www.meti.go.jp/policy/mono_info_service/cashless/cashless_sub/cashless_data_utilization_report.pdf

6

1.2.2

決済データ等の取得に伴う課題
前項の通り、現状では、データの所有者が異なり所在も分散しているため、仮に自治体や地域の事業者（自治体の外郭団体等）（以下、自治体等という）が主体となって地域のデータ利活用を行う際には、決済事業者や店舗とデータを取得する契約を締結する必要がある。現状では共通の契約や接続（以下、手続という）が確立されておらず7、自治体等が複数の決済事業者や店舗からデータを取得する際には、各社と個別の手続をする必要がある。そのため自治体等にも混乱や誤解に基づく不利益が生じることが懸念される。
1.2.3

決済データ等の取扱いに関する課題
決済データや購買データ、利用者属性データ等を利活用する者は、それらのデータの利用目的等について消費者へ説明を丁寧に行い、同意を取得する必要がある。また、それらのデータを格納、加工する場となるデータ利活用基盤にはセキュアな管理が求められ、第三者へのセキュアな伝送が求められる。このように情報の取扱いに関して満たすべき法的・技術的水準が高いため、自治体等が独自に取り組むことは困難である。

1.3 本書の位置付け
本書は、前項に挙げた決済データ等の取得に伴う課題を解決し、決済事業者とデータ利活用を推進したい第三者との間で決済データ連携の手続等を円滑に進めるための指針である。
特に、決済情報等の関連付け、及び決済データ取得のための API 仕様標準について参考となる解決策を示すことを目的としている。
決済情報等を地域で利活用する場面を想定したモデル事業を実施し、モデル事業を通じて有効性が認められた解決策等を指針として提示する。
次年度以降、他地域にて決済データ等の利活用の取り組みを横展開できるように汎用化し、経済活性化等、地域社会の課題解決に寄与するものとする。

（参考）
今回のモデル事業では、スマートフォン向けアプリである地域ウォレットアプリを通じて決済情報等を取得した。地域ウォレットアプリは決済事業者と API 連携等をすることによりキャッシュレス決済が可能となる。またそれに加えて、ポイント機能や、
7

Fintech 等事業者向けの取得方法については、キャッシュレス推進協議会にてガイドラインを策定済

参照 URL：https://www.paymentsjapan.or.jp/wordpress/wp-content/uploads/2020/12/API_Guideline_Ver2.1.pdf

7

クーポン、証明書、鍵、診察券といった様々な機能を付加することが可能であり、「財布」のように汎用性の高いアプリとなる。更に、地域ウォレット事業者等が、その地域の生活に必要な機能を独自に付加することも可能な拡張性の高いアプリでもある。
図表 1 地域ウォレットのイメージ図

地域のステークホルダーにとって、地域ウォレットというサービスや概念を利用することで、複数の決済事業者と接続することが可能となり、幅広いデータを取得が可能になる。また決済データと購買データ、利用者属性データとの紐付けも可能になる。そして最も重要な価値は、データの地産地消、すなわち、決済情報等をはじめとして地域で発生したデータが地域に残り、地域での社会課題解決や活性化等に繋げられることである。地域ウォレットは、「地域に特化したレコメンド」（例：利用者の嗜好に合った地域の特色ある店舗を紹介する）、「地域商品券等のお得感」（例：地域の飲食店のみで使える割引クーポン）、「地域貢献の実感」（例：地域での利用が地域の商店街を元気にする）等、地域主導の価値観をリードしていく仕組みである。また、地域ウォレットアプリは、全国的に幅広く使われるアプリと併用することで、今後地域のデータ利活用において重要なツールとなりうる。

8

図表 2 地域ウォレットの概要図

地域ウォレットアプリは決済機能や認証機能を備えており、UI8やミニアプリ9等によって地域独自の機能を提供することが可能である。また、近年では地域ウォレットアプ
リのみならず大手流通業10や製造業11にて提携 Pay として決済機能を提供するウォレッ
トアプリが登場している。よって、地域ウォレット事業者と決済事業者、店舗間の標準的な手続に係るルール作りをすることにより、API の整備や決済情報等の連携を促進することが期待されている。
なお、今回のモデル事業で取扱う地域のデータ利活用においては地域ウォレットア
プリの活用を中心に検討を行っているが、全国的に広く使えるアプリであっても以下の観点を満たせば、地域ウォレットが目指すもののいくつかを別の連携方式にて実現するものと考えられるため、本書の対象とする。
• 地域にてデータを集め、地域でのデータ利活用を目的としていること• 提携 Pay の API を組込んだ決済機能を含むアプリであること• または、既に登録済みの決済事業者アカウントを使用して地域ウォレットから決済事業者登録できるアプリであること（連携方式②）8

UI とはユーザインターフェイス（User Interface）の略で、例えば OS やアプリの表示画面や操作方法がこれにあたる。
9

ミニアプリとは特定の親アプリ（本書では地域ウォレット）を基盤にする小さなアプリケーションのことである。親アプリと連携する機能をシームレスに起動できるメリットがある。ユーザの利便性のみならず、ユーザ認証やアプリ開発の点でも有効な手段とされている。
10「ローソンアプリ」で「au PAY」の利用が可能に（https://www.au.com/information/topic/auwallet/2021-003/）
11

トヨタのキャッシュレス決済アプリ 「TOYOTA Wallet」誕生（https://www.tfsc.jp/news/2019/191119.pdf）

9• または、決済事業者のスーパーアプリ12のミニアプリ等、各決済事業者の個別ソ
リューション内部へ作り込むことで連携を実現できるアプリであること（連携方式③）

本書では、今回のモデル事業で採用した連携方式（連携方式①）に加えて、それを拡張した二つの連携方式（4.4 に記載した連携方式②と 4.5 に記載した連携方式③）の 3
方式について取扱う。
決済事業者は 3 方式のうち自社の方針に合った連携方式を選択することができる。
図表 2 に示した通り、地域ウォレット事業者は、採用する決済事業者に応じて、最大で三つの連携方式を準備することになる。
なお、地域ウォレット事業者と決済事業者の接続においては、決済事業者側に用意された API を地域ウォレット側からアクセスする方式以外に、決済事業者から提供される SDK（ソフトウェア開発キット）13を地域ウォレット側に組み込む方式がある。

以下の図表 3 にモデル事業で使用した地域ウォレットアプリの画面イメージを参考として掲載した。

12

スーパーアプリとは、日常生活のさまざまな場面、例えばソーシャルメディア利用、タクシー配車、決済、ホテル予約などにおいて、それぞれのアプリを立ち上げることなく、統合されたプラットフォームを提供するアプリである。スーパーアプリの中で起動できるアプリ群をミニアプリと呼ぶ。
13

SDK は、プログラム、API、サンプルコードなどをパッケージにしたソフトウェアライブラリのことである。決済事業者の中には、地域ウォレット事業者や Fintech 事業者等が、自社のサーバーへ接続する
場合、その開発負荷を低減させるために SDK を提供することがある。

10

図表 3 地域ウォレットアプリ画面イメージ

1.4 適用範囲
以下の図表 4 において、地域のデータ利活用を実現するにあたり作業手順と各地域のデータ利活用に係る各関連事業者が行う主な活動を示す。データ利活用の実施における主な作業手順は、5 ステップで表すことができる。本書では、ステップ 3 のうち、データ収集、及び収集したデータを突合する際の課題となる関連データの紐付けや API
仕様標準について記載する。
図表 4 データ利活用を実施するときの作業手順
作業手順
ステップ 1
課題を設定する

本書の対象各地域のデータ利活用に係る各関連事業者が行う主な活動‐

当該地域で解決したい課題を洗い出し、優先度をつける‐

課題が発生している原因を調査する

11

解決策を検討するステップ 2
仮説を検討する

検証方法を検討する、必要に応じて目標値設定等をする●

データ収集及び、収集したデータを突合する（API の活用等による
連携方式）

‐

データ収集、及び収集したデータを突合する（ユーザ合意や、契約等）‐

分析を意識したデータ取得項目の整理をする

ステップ 4
データを分析する‐分析のためのデータの保管から破棄まで管理するステップ 5
データを利活用する‐

データの生成方法や提供における留意点を確認した上で、地域の社会課題解決や活性化につなげるステップ 3
データを集める※ステップ 3～5 は「決済情報や購買情報の取扱に関する標準ガイドライン」にて定義• 利活用するデータに関する地域ウォレット事業者、決済事業者、店舗（POS 利用）等の連携方式と役割分担を例示する。尚、自治体や団体等が地域の活動情報等を提供する場合もあるが、本書では便宜上、店舗（POS 利用）等に含まれるものとする。店舗における POS 利用は必ずしも前提としていないが、POS を店舗が保有していない場合、データ利活用するための安定的なデータの提供に支障が生じる可能性がある。そこで地域ウォレット事業者は、POS を保有していない店
舗に対して、タブレット等を活用した簡易 POS の提供、または地域ウォレット
アプリを機能拡張するなどの考慮が必要になる場合もある。
• 標準的な API 入出力データ項目の例を提示する。
尚、本書において「決済事業者」はコード決済事業者を想定している。

12

図表 5 本書の適用範囲

地域ウォレット事業者、決済事業者、店舗（POS 利用）等の主な役割を以下に示す。
図表 6 事業者の役割
事業者種別

地域ウォレット事業者

決済事業者

店舗（POS
利用）等

主な役割
役
割
①

地域ウォレットを地域に提供、運用する事業者。連携する決済事業者から決済データ、店舗から購買データ、地域利用者から利用者属性データを収集し、データの紐付けを行う。また、集約したデータを加工・分析し、地域のデータ利活用を主体的に行う。

役

地域ウォレット事業者に決済機能を提供する事業者。地域ウォレットアプリ

割を通じて決済された決済取引データのみを地域ウォレット事業者に連携す②る。連携された決済データは地域のデータ利活用のためだけに使用される。

役

地域ウォレットが利用できる店舗等。地域ウォレットアプリを通じて地域利割用者が商品の購入等をした購買データのみを地域ウォレット事業者に連携す③る。連携された購買データは地域のデータ利活用のためだけに使用される。

1.5 本書の想定読者
本書の主な読者は地域ウォレット事業者、決済事業者、地域ウォレットを活用する店
舗の IT システムに関わる企画担当者、推進担当者、エンジニア等である。

13

想定読者がデータ利活用において担う役割を図表 7 に整理した。データ利活用における役割については、地域におけるデータ利活用のためのコード決済情報等の適正な取扱に関するガイドラインも参照。
図表 7 想定読者のデータ利活用における役割
想定読者

データ利活用における役割
ケース①

地域ウォレット事業者
ケース②

データ利活用推進主体 かつ
データ利活用基盤システム運用者想定される事業者
自治体の外郭団体等

データ利活用基盤システム運用者（データ利活用推進主体のコントロ

地域の開発会社等ールのもと実施）

決済事業者

データ提供者

コード決済事業者

店舗

データ提供者

購買データを扱う店舗※データ利活用推進主体：課題を解決するための仮説検討、及びその推進を行う団体や事業者等。
※データ利活用基盤システム運用者：データ利活用基盤を提供し、データ保持、及び加工をする事業者等。
※データ提供者：個人データ等を提供する事業者等。

1.6 本書の構成
本書は「1.3 本書の位置付け」に記載した通り、地域ウォレット事業者と決済事業者の連携方式について、連携方式①、連携方式②、連携方式③と３方式について説明している。各方式が記載されている章を、図表 8 に明示する。
図表 8 本書の構成
分類章
2 決済情報等の取得方法と課題

連携方式①

2.1 決済情報取得フロー
2.2 決済情報等取得に関わる課題

14

分類

章
3 データ間の紐付け
3.1 基本的な考え方
3.2 実現方式の例
4 データの集め方
4.1 基本的な考え方
4.2 電文仕様標準
4.3 利用者属性データと購買データ

連携方式②

4.4 連携方式の拡張（連携方式②）

連携方式③

4.5 連携方式の拡張（連携方式③）15

2 決済情報等の取得方法と課題
本章では、地域ウォレット事業者が決済情報等を取得する上で直面する課題と対策について記載するが、その課題の前提となる決済情報等取得フローを先に明示する。

2.1 決済情報等取得フロー
2.1.1

決済情報等取得フロー概要
地域ウォレットは、前述の通り地域ウォレットアプリと、地域ウォレット基盤、デー

タ利活用基盤で構成される。まず、図表 9 中に記載した地域ウォレット基盤と、決済情報等取得フローの概要を説明する。尚、地域ウォレットを通じた決済において、デー
タ利活用に使用されるデータは、地域利用者から取得する「利用者属性データ」、決済事業者から連携される「決済データ」、店舗から連携される「購買データ」が想定される。
図表 9 決済情報等取得フロー概要14

14

本「決済情報等取得フロー概要」は店舗提示型（MPM）にて説明している。店舗提示型とは QR コー

ド決済において、消費者が店舗のステッカーに掲示、または端末に表示された QR コードをスマートフォ
ンの決済アプリで読み取り、支払いを行う方式である。省略して MPM(Merchant Presented Mode)と呼
ばれている

16

a.

地域ウォレット基盤の機能
地域ウォレット基盤は、地域ウォレットのサービスを構成する中核基盤である。地域

利用者が行う会員登録・認証、QR コード決済機能を地域ウォレットアプリに提供し、地域ウォレットアプリと連携して決済事業者や店舗に接続する機能を持つ。
また、取得した決済情報等を管理し、データ利活用基盤にデータを送信する。データ
利活用基盤とは、地域ウォレット基盤より受信した決済情報等を加工・分析し、データ利活用を行うためのデータベースを意味する。
b.

処理フロー

i. 利用者属性データの取得
図表 9 で利用者属性データの処理フローは、ブルーの矢印で示した。地域利用者が、地域ウォレットアプリから登録した氏名、住所、電話番号等の属性は、地域ウォレット
基盤上の会員管理データベースに利用者属性データとして登録される。また、利用者属
性データはデータ利活用のため、地域ウォレット事業者のデータ利活用基盤に送信され、データ利活用データベースに登録される。その際、地域利用者一人に一つ発番される ID（以下、利用者 ID という）が付与される。
ii. 決済データの取得
図表 9 で決済データの処理フローは、ピンクの矢印で示した。地域利用者が、店舗にて地域ウォレットアプリを通じて商品の購入等を行う際、地域ウォレットアプリから決済入力データが地域ウォレット基盤に送信され、地域ウォレット基盤を経由して決済事業者に送信される。決済入力データには、コード情報、加盟店 ID、決済金額等が含まれる。また、決済事業者における決済処理の結果である決済取引データには、結果コード、決済処理通番などが含まれ、決済事業者から地域ウォレット基盤に応答される。これらの決済入力データと決済取引データは決済データとしてデータ利活用基盤に送信され、データ利活用データベースに登録される。
iii. 購買データの取得
図表 9 で購買データの処理フローは、オレンジの矢印で示した。店舗（POS 利用）
等は、地域利用者が地域ウォレットアプリを通じて購入した取引結果を購買データとして保有している。購買データには、店舗 ID 、商品データ、商品単価、購入数、合計
金額、決済時間等が含まれる。店舗 ID は決済を行う際に、店舗を識別するコードであるが、統一 QR コードを使用する場合、一般社団法人キャッシュレス推進協議会事務17

局から発番される15。地域ウォレット基盤は、店舗（POS 利用）等から購買データを受信し、データ利活用基盤のデータ利活用データベースに購買データを送信する。
c.

地域ウォレット事業者の役割
本章において、これら決済情報等を収集し、データ利活用のためのデータ加工・分析を行う（以下、データ利活用基盤を運用するという）役割を地域ウォレット事業者が担うものとした。しかし、地域の実情やサービス内容に合わせて関与する事業者や団体が担う役割を調整することを妨げるものではない。
本書では、店舗における購買をひとつの例として説明するが、地域で実装する際には、実際の利用環境や実情と照らし合わせた読み替えが必要である。
2.1.2

決済情報等取得フロー詳細
次にデータ利活用基盤にこれらのデータがどの時点でどのように送信されるかを処理フローにて説明する。処理フローは、a.利用者提示型(CPM)16と b.店舗提示型(MPM)に分けて例示する。データ間の紐付けについては、「3 データ間の紐付け」にて述べる。
a.

利用者提示型(CPM) の決済情報等取得フロー
利用者提示型(CPM)の決済情報取得フローを以下に記載する。利用者属性データ、決済データ、購買データの取得方法を順に説明する。図中地域ウォレット事業者については、地域ウォレット基盤とデータ利活用基盤を記載している。地域ウォレット基盤
は、地域ウォレットの機能全体を管理する地域ウォレット事業者の中核基盤であり、データ利活用基盤は、データ利活用に使用するデータを集約するデータベース基盤である。丸数字は図表 10 に表記されている①から⑬のフローに対応する。

15

店舗 ID の取得については、一般社団法人キャッシュレス推進協議会発行「コード決済に関する統一技

術仕様ガイドライン【店舗提示型】 Ver.2.0 「3.2 統一店識別コードの取得」に記載されている。参照
URL https://www.paymentsjapan.or.jp/wordpress/wp-content/uploads/2020/04/MPM_Guideline_2.0.pdf
16

利用者提示型とはバーコード・QR コード決済において、消費者のスマートフォン決済アプリの画面に表示されたバーコード・QR コードを店舗のリーダーが読み取り、支払いを行う方式である。省略してCPM(Consumer Presented Mode)と呼ばれている。

18

図表 10 決済情報等取得フロー(CPM）

i. 利用者属性データの取得① 地域ウォレット事業者が、地域利用者に提供した地域ウォレットアプリに申込
規約を表示する。地域利用者が規約に同意した場合、申込みを受付ける。
② 地域ウォレット事業者はプライバシーポリシー（共同利用や委託先に関する記載を含む）を地域ウォレットアプリに表示し、地域利用者に同意を求める。
③ 地域ウォレット事業者は、地域利用者に氏名、住所、電話番号等の個人属性情報の入力を求める。また、同時に地域ウォレットアプリより地域利用者の嗜好や趣味等についてアンケート入力を求めることも可能である。
④ 地域ウォレット事業者は、地域利用者に決済機能を提供するために地域ウォレ

19

ットアプリに決済事業者登録機能を設ける。地域ウォレット事業者は、決済事業者 API の入力に必要なデータを地域ウォレットアプリから地域利用者に入力を求め、決済事業者 API 経由で決済事業者に地域利用者の登録を要求する。
⑤ 決済事業者登録完了後、地域ウォレット事業者は、登録された「利用者属性データ」をデータ利活用基盤に送信する。
ii. 決済データの取得⑥ 地域ウォレット事業者は CPM の場合、地域利用者が地域ウォレットアプリで選択した決済事業者にバーコードまたは QR コード生成情報を要求し、決済事業者から受け取ったコード情報を地域ウォレットアプリに送信する。
⑦ 決済事業者から受け取ったコード情報をもとに、地域ウォレットアプリはバー
コード・QR コードを画面に表示する。地域利用者は表示されたコードを店舗に提示するので、店舗スタッフはコードリーダーにより、コードを読み取り、
POS レジに決済金額を入力する。店舗 POS は入力されたコード情報と決済金額に加え、予め POS に設定されていた加盟店 ID 等をもとに決済入力データを作成し、決済事業者に送信する。
⑧ 決済事業者は決済処理を行った後、その結果コード、決済処理通番を、決済取引データとして店舗へ送信する。
⑨ 決済事業者は加盟店のみでなく、地域ウォレット事業者にも決済処理結果を知らせる。決済用顧客 ID、加盟店 ID、決済金額、決済処理通番等を含む取引結果通知を地域ウォレット事業者に送信する。地域ウォレット事業者は取引結果通知を地域ウォレットアプリに送信する。
⑩ 地域ウォレット事業者が取引結果通知をネットワークの異常等により受取ることができなかった場合、地域ウォレット事業者は地域利用者からの問合せ等によりそれを検知し、地域ウォレット事業者の業務運用対処として、決済取引の照会を決済事業者に送信する。決済事業者は照会に対する応答として、取引結果通知と同様の決済取引データを地域ウォレット事業者に送信する。
⑪ 地域ウォレット事業者は取得した決済データをデータ利活用基盤に送信する。
iii. 購買データの取得⑫ 店舗は決済終了後、地域ウォレット事業者と事前に合意したタイミング（店舗閉店後等）で購買データを地域ウォレット事業者に送信する。購買データの送信処理は、予め設定された時間等にシステムにより自動起動する場合と店舗ス
タッフにより閉店後締め処理に続いて、手動で送信処理する場合等が考えられる。購買データは、当該日の購買取引の明細データであり、利用者 ID、店舗 ID、
購買商品情報（JAN コード）、商品名、単価、個数、合計金額等を含む。

20

⑬ 地域ウォレット事業者は、取得した購買データをデータ利活用基盤に送信する。
b.

店舗提示型(MPM)の決済情報取得フロー
店舗提示型(MPM)の決済情報取得フローを以下に記載する。利用者属性データ、決済データ、購買データの取得方法を順に説明する。丸数字は図表 11 に表記されている①から⑪のフローに対応する。
図表 11 決済情報取得フロー(MPM)

i. 利用者属性データの取得① 地域ウォレット事業者が、地域利用者に提供した地域ウォレットアプリに申込
規約を表示する。地域利用者が規約に同意した場合、申込みを受付ける。
② 地域ウォレット事業者は、プライバシーポリシー（共同利用や委託先に関する21

記載を含む）を地域ウォレットアプリに表示し、地域利用者に同意を求める。
③ 地域ウォレット事業者は、地域利用者に氏名、住所、電話番号等の個人属性情報の入力を求める。また同時に地域ウォレットアプリより地域利用者の嗜好や趣味等についてアンケート入力を求めることも可能である。
④ 地域ウォレット事業者は、地域利用者に決済機能を提供するために地域ウォレットアプリに決済事業者登録機能を設ける。地域ウォレット事業者は決済事業者 API の入力に必要なデータを地域ウォレットアプリから地域利用者に入力を求め、決済事業者 API 経由で決済事業者に地域利用者の登録を要求する。
⑤ 決済事業者登録完了後、地域ウォレット事業者は、登録された「利用者属性データ」をデータ利活用基盤に送信する。
ii. 決済データの取得⑥ MPM の場合、店舗が提示するバーコードまたは QR コードを地域利用者が地
域ウォレットアプリで読み取り、決済金額を入力する。地域ウォレットアプリ
は、地域ウォレット基盤経由で、コード情報、加盟店 ID、決済金額等をもとに決済入力データを作成し、決済事業者に送信する。
⑦ 決済事業者は決済処理を行った後、その結果コード、決済処理通番を決済取引データとして地域ウォレット事業者へ送信する。地域ウォレット事業者は、地域ウォレットアプリに取引結果通知を送信する。地域利用者は店舗スタッフに
地域ウォレットアプリの支払完了画面を提示し、決済が完了する。
⑧ 決済事業者は地域ウォレット事業者のみでなく、店舗にもメール等による取引結果通知にて、決済処理結果を取引後すみやかに知らせる。決済用顧客 ID、加盟店 ID、決済金額、決済処理通番等を含む取引結果通知を店舗に送信する。
⑨ 地域ウォレット事業者は、取得した決済データをデータ利活用基盤に送信する。
iii. 購買データの取得⑩ 店舗は決済終了後、地域ウォレット事業者と事前に合意したタイミング（店舗閉店後等）で購買データを地域ウォレット事業者に送信する。購買データの送信処理は、予め設定された時間等にシステムにより自動起動する場合と店舗ス
タッフにより閉店後締め処理に続いて、手動で送信処理する場合等が考えられる。
⑪ 地域ウォレット事業者は、取得した購買データをデータ利活用基盤に送信する。
2.1.3

モデル事業における決済情報等取得の事例
買い物支援のモデル事業において、決済情報等を取得した事例について述べる。今回のモデル事業では、買い物車両を運行する（MPM で決済）と共に、地域のスーパーで22

顧客の買い物行動を分析することで、買い物弱者候補の地域を特定し、具体的な買い物支援策を提供することを目的としている。これにより地域利用者は買い物する手段が確保され、地域の小売り店舗（スーパー）の売上増にも繋がることを仮説として設定した。本モデル事業においては、地域ウォレットアプリに登録する利用者属性データ、買い物車両乗車時の決済データ、小売り店舗（スーパー）での購買データを活用した。
図表 12 にてデータ取得の事例を説明する。図中の丸数字は、以降の説明文に対応する。
図表 12 モデル事業におけるデータ取得方法

i. 利用者属性データの取得① 地域ウォレット事業者が、地域利用者に提供した地域ウォレットアプリに申込
規約を表示する。地域利用者が規約に同意した場合、申込みを受付ける。
② 地域ウォレット事業者は、プライバシーポリシー（共同利用や委託先に関する記載を含む）を地域ウォレットアプリに表示し、地域利用者に同意を求める。

23

③ 地域ウォレット事業者が提供する地域ウォレットアプリにて地域利用者が初期登録で入力した氏名、住所、電話番号等の情報は、地域ウォレット基盤に利用
者属性データとして登録される。同時に利用者より入力された小売店舗（スーパー）のポイントカード ID も利用者属性データに保存される。また、地域ウォ
レットアプリは地域利用者にアンケート入力を促し、利用者の嗜好、その他付
属情報を地域ウォレット基盤の利用者属性データに付加する。
④ 地域ウォレット事業者は決済事業者 API の入力に必要なデータを地域ウォレッ
トアプリから地域利用者に入力を求め、決済事業者 API 経由で決済事業者に地域利用者の登録を要求する。
⑤ 決済事業者登録完了後、地域ウォレット事業者は、登録された利用者属性デー
タをデータ利活用基盤に送信する。
ii. 決済データの取得⑥ 買い物車両乗車時に地域利用者が地域ウォレットアプリで車内に掲示した QR
コードを読み取り、金額を入力する。
⑦ 地域ウォレットアプリは、決済の要求を地域ウォレット基盤に送信する。
⑧ 地域ウォレット基盤は決済入力データを作成し、決済事業者に送信する。
⑨ 決済事業者は決済処理後、決済取引データを地域ウォレット事業者に応答する。
その後、地域ウォレット基盤は決済入力データと決済取引データより作成した決済データを保存する。
⑩ 地域ウォレット基盤は取引結果通知を地域ウォレットアプリに送信する。
⑪ 地域ウォレット基盤は決済データをデータ利活用基盤に送信する。
iii. 購買データの取得⑫ 地域の小売店舗（スーパー）における購買データは、地域利用者が地域の小売店舗（スーパー）において買い物を行うと取得される。買い物車両に乗車した
地域利用者は、地域の小売店舗（スーパー）のポイントカードを購買時に提示する。
⑬ 店舗担当者が、地域の小売店舗（スーパー）の POS 端末から抽出した購買デー
タを地域ウォレット事業者に送信する。地域ウォレット事業者は、地域ウォレット基盤において、スーパーのポイントカード ID に紐付いた利用者 ID を購買
データに付加し保存する。
⑭ 地域ウォレット基盤は、収集した利用者属性データ、決済データ、購買データ
をデータ利活用基盤に送信する。

24

2.2 決済情報等取得に関わる課題
決済情報等は、決済事業者や店舗が個別の形式でそれぞれ保管している。これらのデータを地域で利活用する際にいくつかの課題が存在する。本節ではそれらの課題のう
ち、決済情報取得に関わる課題について整理し、解決策の指針を示す。
また、決済情報等取得に関わる課題の中には、個人情報の取扱い、地域利用者本人の事前同意、各種認証等データの取扱いに関する課題があるが、これらの課題については「地域におけるデータ利活用のためのコード決済情報等の適正な取扱に関するガイド
ライン」にて記載する。
2.2.1

決済データ取得方法に関する課題
今回のモデル事業で取扱った地域ウォレットは連携方式①の提携 Pay 方式、すなわ

ち地域ウォレットに決済機能を保有せず、決済事業者と連携し、決済事業者の決済機能を利用する方式を採用した。しかし、地域ウォレット事業者との連携方式に提携 Pay 方式を採用する決済事業者は限られている。また前述の通り、それ以外の方式も含めデー
タ利活用を想定した API は未整備状態である。
本書では地域ウォレット事業者によるデータ利活用を想定した API 仕様標準を、今回のモデル事業で取扱った連携方式①を用いて本書「4 データの集め方」に記載する。
API 仕様標準では、連携方式②、及び連携方式③を採用する決済事業者の参加も容易となる API 仕様案を併せて掲載する。
図表 13 決済データ取得方法に関する課題

25

2.2.2

データの紐付けに関する課題
地域ウォレット事業者が決済情報等のデータ利活用を行う場合、データの紐付けを行う必要がある。
決済データは、誰が、いつ、どこで、どの様な支払い方法で決済を行い、その結果の正常、または異常を知ることができる。しかし、どの様な商品をいくつ購入したといった情報等は、一般的に決済データには存在しない。購買データは、誰が、いつ、どこで、どの商品をいくつ購入したのかという情報を把握することが可能となる。通常、一件の決済データに対応する購買データが一件存在する場合、決済データと購買データを紐付けるための鍵となる共通データが必要となる。それらを紐付けるために、決済データと購買データ作成に関わる地域ウォレット事業者、決済事業者、店舗が紐付けを目的とした共通データの活用に合意する。そして、決済データと購買データに設定するために事前に合意し、基盤構築時に対応する必要がある。
更に、地域ウォレット事業者はデータ利活用を行うために、地域利用者の属性を把握し、決済データと購買データを利用者属性データと紐付ける必要がある。
利用者属性データを識別する利用者 ID は、地域ウォレット事業者が発番した ID であり、決済データと購買データそれぞれの消費者識別 ID は、決済事業者や店舗がそれぞれ異なる ID を設定すると考えられる。その場合、地域ウォレット事業者は決済事業者や店舗が個々に発番した消費者識別 ID と利用者属性データの利用者 ID を紐付けることになる。
図表 14 データの紐付け概観

26従って、データ利活用のためには関連データの紐付けが必要となる。データ紐付けの詳細に関しては、本書「3 データ間の紐付け」に記載する。

27

3 データ間の紐付け
本章では、地域ウォレット事業者が関連データの紐付けをする上で直面する課題と対策について記載する。

3.1 基本的な考え方
利用者属性データ、決済データ、購買データを紐付ける方法は、複数パターン存在する。ここでは一例として、ⅰ利用者属性データと決済データの紐付け、ⅱ決済データと購買データの紐付けについて記載する。
これらの紐付けによって、3 つのデータを相互に紐付けることが可能となる。また、
図表 15 にてデータ紐付け関連項目の事例を説明する。尚、データ紐付けの具体的な方式については「3.2 実現方式の例」に記載する。
図表 15 データの紐付け関連項目

28

文中の丸数字は、図中の丸数字と対応している。尚、今回のモデル事業では、データの紐付け処理は地域ウォレット事業者が行う。
3.1.1

利用者属性データと決済データの紐付け
a ①の利用者属性データは、②の地域ウォレットアプリから③地域利用者が利用者登録を行う時に入力したデータである。
b 利用者登録時に、④の地域ウォレット事業者が⑤の地域ウォレット基盤で、③の地域利用者に発行する ID を本書では⑥の利用者 ID と称する。
c また、③の地域利用者が②の地域ウォレットアプリから決済事業者登録を行う時に、⑦の決済事業者によって発番・管理される ID を、本書では⑧の決済用顧客
ID と称する。
d ⑤の地域ウォレット基盤で、⑥の利用者 ID と⑧の決済用顧客 ID を紐付けるため、地域ウォレット事業者は⑨の ID 紐付けテーブルに登録する。
e それにより⑤の地域ウォレット基盤では、⑦の決済事業者から連携される⑩決済
データに含まれる⑧の決済用顧客 ID と⑥の利用者 ID を突合することで、①の利用者属性データと⑩の決済データを紐付けることが可能となる。
f⑨の ID 紐付けテーブルは、⑤の地域ウォレット基盤上で管理する ID データを紐付けるためのコード変換用テーブルである。

g 本章では地域ウォレットの⑥利用者 ID と⑦の決済事業者が管理する⑧の決済用
顧客 ID を紐付けている。
h このテーブルを利用することにより、⑩の決済データに入っている⑧の決済用顧客 ID を⑥の利用者 ID に変換することが可能になる。
i③の地域利用者を識別する ID を⑥の利用者 ID に統一することで、データ分析を容易にすることができる。

j

最終的にデータ利活用を行うために、⑤地域ウォレット基盤上では①の利用者属性データと⑩の決済データを⑪のデータ利活用基盤に渡す必要がある。

k その際に⑩の決済データの⑧決済用顧客 ID を⑥利用者 ID に変換し、⑪データ
利活用基盤に送信する。
3.1.2

決済データと購買データの紐付け
a ③の地域利用者が⑫の店舗において商品購入時に⑤地域ウォレット基盤上に⑩決済データが生成され、⑫の店舗（POS 利用）等が⑬の購買データを生成する。
b その際取引を一意に特定するための⑬取引通番が地域ウォレット基盤から発番される。
c この⑬取引通番を⑩の決済データと⑬の購買データで共有することにより、③の29

地域利用者による購買取引を一意に特定でき、⑩決済データと⑬購買データの紐付けが可能となる（図表 15 矢印⑭）。
d また、取引を一意に特定するために⑬取引通番が利用できない場合は、取引日時、加盟店 ID、利用者 ID、取引金額など複数データ項目を組み合わせて突合するこ
とも可能である（図表 15 矢印⑮）。
e この場合、店舗⑫の（POS 利用）等が②の地域ウォレットアプリから⑥の利用者
ID を読み取り⑬購買データに設定する必要がある。

3.2 実現方式の例
上記データの紐付けの手法を前提に、その実現方式を記載する。実現方式は様々な方式が想定されるが、本書では一例を紹介する。
3.2.1
a.

利用者属性データと決済データの紐付け
概要
a 地域ウォレット事業者が、利用者属性データと決済データを紐付けるためには、
利用者属性データの利用者 ID と決済データの決済用顧客 ID を紐付けることで、実現することが可能となる。
b これら ID の紐付けは、地域ウォレット基盤による ID 紐付けテーブルを使用する。ID 紐付けテーブルは、地域利用者が地域ウォレットアプリから行う利用者登録と決済事業者登録を行った後に、地域ウォレット事業者が作成する。
c 利用者登録とは、地域ウォレット事業者が提供する地域ウォレットアプリから地域利用者が行う初期登録である。
d ここで利用規約等の同意、本人認証を行った後、利用者属性データが地域ウォレット基盤に登録される。その際、地域ウォレット基盤が地域利用者ごとに一意に発行する ID を利用者 ID と称する。
e 決済事業者登録とは、地域ウォレットアプリから地域利用者が利用する決済事業者の初期登録である。
f

決済事業者登録を行うことで、地域ウォレットアプリで登録した決済事業者の決済機能を地域利用者が利用できるようになるため、決済事業者登録は地域ウォレットアプリを使って地域利用者が店舗で決済する前に行う必要がある。

g 登録時には決済事業者の決済サービス利用規約への合意、決済事業者による本人確認を行った後、決済事業者システムに地域利用者が登録される。その際、決済事業者が地域利用者ごとに一意に発行する ID を決済用顧客 ID と称する。
h 地域ウォレットによっては複数の決済サービスが利用可能となる。その場合、決30

済事業者毎に決済事業者登録が必要となる。
b.

地域ウォレット事業者が ID 紐付けテーブルへ登録する手順
図表 16 に利用者 ID と決済用顧客 ID 紐付け処理フローを示す。図中では 2 社の決済事業者を登録するフローを以下の 3 ステップで記載している。尚、文中の丸数字は図中の丸数字に対応している。

ステップⅠ 地域ウォレットアプリ利用者登録
ステップⅡ 決済事業者 1 社目の登録
ステップⅢ 決済事業者 2 社目の登録
図表 16 利用者 ID と決済用顧客 ID 紐付け処理フロー

i. ステップⅠ 地域ウォレットアプリ利用者登録① 地域ウォレット事業者は、地域利用者から利用者登録を受付ける際、地域ウォ
レット利用規約への同意要求と本人認証を行う。
② 地域ウォレット事業者は、本人認証承認後に利用者 ID を発行する。（図表 16
では利用者 ID に 001 が発行されている。）この時点では決済事業者登録を行31

っていない。従って、ID 紐付けテーブルにデータの登録は行わない。
ii. ステップⅡ 決済事業者 1 社目の登録③ 地域ウォレット事業者は、地域利用者による 1 社目の決済事業者（以下、決済事業者 1 という）登録を受付ける。地域利用者は、決済事業者 1 からの決済利用規約に同意し決済事業者 1 の登録が完了する 。その際、決済事業者 1 によって「決済用顧客 ID」が発番され、地域ウォレット事業者に通知される。（図表 16 では「決済用顧客 ID」に A000001 が発番されている。）「決済用顧客
ID」は、決済事業者から発番される場合と、地域ウォレット事業者が発番し、決済事業者に通知する場合があるため、発番方式は決済事業者に確認する必要がある。
④ 地域ウォレット事業者は、ID 紐付けテーブルに「利用者 ID」（図表 16 では
001）とそれに紐付く決済事業者 1 の「決済事業者識別」（図表 16 では 0000A）と「決済用顧客 ID」（図表 16 では A000001）を登録する。この時点で「利用者 ID」と決済事業者 1 に登録された「決済用顧客 ID」の紐付けが完了する。
iii. ステップⅢ 決済事業者 2 社目の登録⑤ ステップⅡと同様、地域ウォレット事業者は、2 社目の決済事業者（以下、決済事業者 2 という）を地域ウォレットに登録を行う。
⑥ ステップⅡと同様、地域ウォレット事業者は、ID 紐付けテーブルに「利用者 ID」（図表 16 では 001）とそれに紐付く決済事業者 2 の「決済事業者識別」（図表 16 では 0000B）と「決済用顧客 ID」（図表 16 では B000001）を登録する。
この時点で「利用者 ID」と決済事業者 2 に登録された「決済用顧客 ID」の紐付けが完了する。
3.2.2

決済データと購買データの紐付け
a 地域ウォレット事業者と決済事業者間で作成される決済データと、店舗（POS 利用）等が作成する購買データには、通常、取引を一意に特定する取引通番がそれぞれ発番される。
b データ利活用において、決済データと購買データを紐付けるためには、この取引通番を決済事業者と店舗（POS 利用）等で共有する必要がある。
c 例えば、店舗で発番する加盟店処理通番を地域ウォレット事業者が決済データに加えるという方法が考えられる。
d 加盟店処理通番が店舗毎に発番される場合、店舗 ID と加盟店処理通番を組合せて管理するといった必要もある。
e また、決済事業者側の処理通番を店舗側と共有する、あるいは取引を一意に特定32する処理通番を新たに作成することも可能である。
f

店舗側と決済事業者間で処理通番を共有できない場合、他のデータ項目を組み合わせて取引を一意に特定する必要がある。

g 例えば、取引日時、利用者 ID、加盟店 ID、取引金額を組み合わせることにより、通常、取引を一意に特定することが可能である。
h 地域ウォレット事業者と店舗、決済事業者で取引を一意に特定する項目の組合せについて事前の合意を行い、インターフェイスや情報システムへ反映する必要がある。

33

4 データの集め方
4.1 基本的な考え方
本章では、今回のモデル事業で取扱った連携方式①を用いて地域ウォレット事業者
または店舗と、決済事業者間の API 入出力データ項目のモデルを示す。API 入出力データのフローは、本書「2 決済情報等の取得方法と課題」を参照のこと。本章のデータ
項目は、地域ウォレット事業者、または決済事業者が API 入出力データ項目を設計する際の参考として利用することを想定している。
なお、本入出力データ項目は、利用者提示型(CPM)と加盟店提示型(MPM)を分けて記載する。
API の基本的な考え方と開発原則は、キャッシュレス推進協議会公表のキャッシュ
レス決済データ利活用に係る API ガイドライン17 、及び API 仕様の標準化を参照のこと。

4.2 電文仕様標準
4.2.1

通信プロトコル
API 通信プロトコルは HTTPS 通信、アーキテクチャスタイルは REST を使用した

Web API とし、詳細は決済事業者が提供する通信仕様に従うこととする。
データ利活用の場合は、リアルタイムによるデータ反映を必要とせず、バッチ処理にてファイル送受信することも考えられる。その場合は、送信側と受信側双方合意の上、
FTPS/SFTP 通信、もしくは伝送データ暗号化機能を含む商用のファイル伝送ソフトウ
ェアを利用することが可能である。
4.2.2

認証・認可の方式
地域利用者が、地域ウォレットから決済事業者を登録する際の認証・認可の方式は、キャッシュレス推進協議会のクレジットカード分野のオープン API に係る電文仕様標
準18 3 電文仕様標準を参照のこと。

172020 年 4 月 27 日一般社団法人キャッシュレス推進協議会公表の Ver2.0。原文はhttps://www.paymentsjapan.or.jp/wordpress/wp-content/uploads/2019/11/API_Guideline_Ver2.0.pdf
18

2019 年 10 月 30 日一般社団法人キャッシュレス推進協議会公表の Ver1.0。原文はhttps://www.paymentsjapan.or.jp/wordpress/wp-content/uploads/2019/11/API_Message_Standard_Ver1.0.pdf

34

4.2.3

API 入出力データ
本項では、地域ウォレットまたは店舗と決済事業者間の決済データに関する API 入

出力データ項目を API の種類別に明示する。
利用者属性データと購買データは、地域ウォレットの提供機能や店舗で提供する商品・サービスによってデータ項目の内容が大きく異なる。従って、本書「4.3 利用者属
性データと購買データ」にて、データ項目の事例を記載する。
なお、項目の規定に際しデータ利活用における必要度として、以下のような 3 区分で定義した。
• 標準項目： 各項目の定義が明確であり、且つ最低限必要と考えられるもの。
• 推奨項目： 各決済事業者で実現可否や仕様が異なるものの、対応することが望ましいもの。
• 任意項目： 各決済事業者で実現可否や仕様が異なるものの、可能な場
合は対応が望まれるもの。

API 入出力データ項目は、決済とデータ利活用に必要なデータ項目に限るべきである。特にプライバシーに関わるデータを API 入出力データ項目に採用することは、極力最小限に留めるべきである。
a.

利用者提示型（CPM）
バーコード・QR コード決済で利用者提示型（CPM）の場合の API 入出力データの一覧は以下の通り。

API 入出力データ（CPM）
a

取引結果通知b

照会

35

i. 取引結果通知① 決済事業者が地域ウォレットに対して送信する取引結果通知メッセージ API のことである。決済事業者から送信先への一方向通知メッセージとなる。

② 店舗が売上の取消を行った場合、決済事業者は取引結果通知（取消）を地域ウ
ォレット事業者に送信する。

図表 17 取引結果通知 API 項目
項目

説明

標準項目

1

決済用顧客 ID

決済事業者が管理する地域利用者の ID。決済データと利用者属性デー
タの紐付けキーとして利用する。
決済用顧客 ID は地域ウォレットの利用者 ID と決済データを紐づけることができればどの様な ID でも良い。必ずしも決済事業者の内部で管理している顧客 ID を指していない。

2

加盟店 ID

加盟店企業を識別する ID

3

店舗 ID

加盟店企業の店舗を識別する ID

4

決済処理通番決済事業者が発番した取引のユニークな通番、トランザクション ID として利用可能なデータ

5

決済金額

決済取引の合計金額（税・送料含む）

36

6

処理種別

取引の処理種別（「売上」または「取消」）

7

決済処理結果取引の決済処理結果

8

元取引決済処理通番取消の場合に元取引の決済処理通番を設定

9

元取引金額

取消の場合に元取引の決済金額を設定

推奨項目
10

加盟店処理通番加盟店企業が発番した取引のユニークな通番

11

元取引加盟店処理通番取消の場合に元取引の加盟店処理通番を設定

任意項目
12

その他任意項目API 提供者（決済事業者）による任意追加項目

ii. 照会地域ウォレットが取引結果通知を受け取ることができなかった場合、本照会 API により、決済事業者より決済データを取得することが可能である。
照会 API は、要求メッセージの一部データ項目が設定された場合、複数取引が引き当てられ、応答されるケースがある。

図表 18 照会 API（要求メッセージ）項目
項目

説明

標準項目
1

加盟店 ID

加盟店企業を識別する ID

2

店舗 ID

加盟店企業の店舗を識別する ID

決済用顧客 ID

決済事業者が管理する地域利用者の ID。決済データと利用者属性データの紐付けキーとして利用する。
決済用顧客 ID は地域ウォレットの利用者 ID と決済データを紐づけることができればどの様な ID でも良い。必ずしも決済事業者の内部で管理している顧客 ID を指していない。

3

推奨項目
4

元取引トランザクショ
ン ID

照会対象取引を引き当てるための情報（例：「決済日時＋決済処理通番」等）

5

加盟店処理日時

照会対象取引の加盟店処理日時（From/To）

37

任意項目
6

その他任意項目API 提供者（決済事業者）による任意追加項目

図表 19 照会 API（応答メッセージ）項目
項目

説明

標準項目
1

結果コード

照会処理の結果（iii.結果コードとして返送すべき項目一覧

2

結果メッセージ

照会結果の補足情報

3

決済用顧客 ID

照会対象取引の決済顧客 ID

4

決済日時

照会対象取引の決済日時

5

決済金額

照会対象取引の決済金額

6

処理種別

照会対象取引の処理種別（「売上」または「取消」）

7

決済処理結果

照会対象取引の決済処理結果

参照）

推奨項目
8

加盟店処理通番

照会対象取引の加盟店発番の決済処理通番

9

決済処理通番

照会対象取引の決済事業者発番の決済処理通番

任意項目
10

その他任意項目API 提供者（決済事業者）による任意追加項目

38

b.

店舗提示型（MPM）
バーコード・QR コード決済で店舗提示型（MPM）の場合の API 入出力データの一覧は以下の通り。

API 入出力データ（MPM）
a

売上

b

取引結果通知（取消）

i. 売上
地域利用者が店舗にて商品の購入またはサービスの提供を受ける時の決済 API をこ
こでは売上と称する。

図表 20 売上 API（要求メッセージ）項目
項目

説明

標準項目
1

コード情報

バーコード、QR コードデータの全体または一部

2

加盟店 ID

加盟店企業を識別する ID

3

店舗 ID

加盟店企業の店舗を識別する ID

4

決済金額

決済取引の合計金額（税・送料含む）

5

加盟店処理日時

取引の発生した日時

推奨項目
6

端末識別番号店舗の決済用端末または POS 端末の識別 ID

7

加盟店処理通番加盟店企業が発番した取引のユニークな通番

8

レシート番号

店舗で出力するレシート番号

任意項目
9

その他任意項目API 提供者（決済事業者）による任意追加項目39

図表 21 売上 API（応答メッセージ）項目
項目

説明

標準項目
1

結果コード

売上処理の結果

2

結果メッセージ

売上処理結果の補足情報

3

決済処理通番決済事業者が発番した取引のユニークな通番

推奨項目
4

決済日時

決済事業者が取引を処理した日時

5

決済金額

決済取引の合計金額（原則要求メッセージと同じ値）

任意項目

6

決済用顧客 ID

決済事業者が管理する地域利用者の ID。決済データと利用者属性データの紐付けキーとして利用する。
決済用顧客 ID は地域ウォレットの利用者 ID と決済データを紐づけることができればどの様な ID でも良い。必ずしも決済事業者の内部で管理している顧客 ID を指していない。

7

その他任意項目API 提供者（決済事業者）による任意追加項目

ii. 取引結果通知
売上取引の要求情報の入力に誤りがあった場合や、地域利用者から商品・サービスの返品があった場合、店舗より売上の取消を行う。決済事業者は、地域ウォレット事業者に取引結果通知（取消）を送信する。

図表 22 取引結果通知（取消）項目
項目

説明

標準項目
1

加盟店 ID

加盟店企業を識別する ID

2

店舗 ID

加盟店企業の店舗を識別する ID

3

決済処理通番決済事業者が発番した取引のユニークな通番

4

決済金額

決済取引の合計金額（税・送料含む）

40

5

処理種別

取引の処理種別（「売上」または「取消」）

6

決済処理結果取引の決済処理結果

7

元取引決済処理通番取消の場合に元取引の決済処理通番を設定

8

元取引金額

取消の場合に元取引の決済金額を設定

推奨項目
9

加盟店処理通番加盟店企業が発番した取引のユニークな通番

10

元取引加盟店処理通番取消の場合に元取引の加盟店処理通番を設定

任意項目

11

決済用顧客 ID

決済事業者が管理する地域利用者の ID。決済データと利用者属性データの紐付けキーとして利用する。
決済用顧客 ID は地域ウォレットの利用者 ID と決済データを紐づけることができればどの様な ID でも良い。必ずしも決済事業者の内部で管理している顧客 ID を指していない。

12

その他任意項目API 提供者（決済事業者）による任意追加項目iii. 結果コードとして返送すべき項目一覧
各 API の応答メッセージの結果コードの内容で必要とされる結果コード項目の参考例を記載した。結果コードは取引結果通知には存在しないが、取引の処理結果を表す決済処理結果の内容は結果コードになることを想定している。なお、具体的なコード値は決済事業者が定義するものとする。
図表 23 結果内容一覧
項目

説明

正常結果
決済成功

決済事業者にて決済が正常に行われた取消成功取消が正常に行われた照会成功

照会対象取引が存在した

異常結果
残高不足

残高不足により取引が不可となった

限度額不足

取引限度額上限を超えたため取引が不可となった

利用者不可

利用不可能な利用者であったため取引が不可となった

加盟店不可

利用不可能な加盟店であったため取引が不可となった

有効期限切れ有効期限を超えているため取引が不可となった

無効ユーザ

無効登録されているユーザであったため取引不可となった

フォーマットエラー

取引電文フォーマットに異常があったため取引不可となった

取消対象なし取消対象取引が存在しなかった

照会取引なし照会対象取引が存在しなかった

その他エラー

上記以外の理由により取引が不可となった

41

4.3 利用者属性データと購買データ
地域ウォレット事業者にて管理される利用者属性データと購買データのデータ項目
をそれぞれ事例として記載する。これらのデータを管理するシステムの設計者は、決済
情報と購買情報の取扱に関するガイドラインを参照の上、プライバシーに対して適切な設計を行う必要がある。
4.3.1

利用者属性データ
利用者属性データは、地域ウォレットを利用する地域利用者の属性データである。本節では一般的な個人の属性データのみを事例として掲載する。地域ウォレットのサー
ビスの特性に合わせて、必要に応じてデータ項目の追加・変更を行うことができる。

図表 24 利用者属性データ項目
項目

説明

1

利用者 ID

地域ウォレットが管理する地域利用者の ID

2

携帯電話番号

地域利用者本人が、地域ウォレットをインストールしたスマートフォン
の電話番号

3

メールアドレス

地域利用者本人の所有するメールアドレス

4

氏名（姓）

地域利用者本人の氏名（姓）

5

氏名（名）

地域利用者本人の氏名（名）6

性別

地域利用者本人の性別（男性、女性、不明）

7

生年月日

地域利用者本人の生年月日

8

郵便番号

地域利用者本人の住所の郵便番号

9

住所

地域利用者本人の住所10

その他任意項目

地域ウォレット事業者よる任意追加項目

42

4.3.2

購買データ
購買データは、地域利用者が店舗において商品の購入またはサービスを利用した際の取引内容を店舗側で記録したデータであり、店舗が提供するサービス内容によってデータ項目が大きく異なる 。本節においては商品購入の事例を記載する。

図表 25 購買データ項目

19

項目

説明

1

取引日付

店舗にて取引が発生した日付

2

取引時刻

店舗にて取引が発生した時刻

3

利用者 ID

地域ウォレットで管理されている地域利用者の識別 ID、もしくは店舗と地域ウォレットが事前に共有している紐
付け ID

4

加盟店 ID

加盟店企業を識別する ID

5

店舗 ID

加盟店企業の店舗を識別する ID

6

端末識別番号店舗の決済用端末または POS 端末の識別 ID

7

合計金額

購入金額の合計（税・送料含む）

8

加盟店処理通番加盟店企業が発番した取引のユニークな通番

9

JAN コード

購入商品の商品識別番号

10

商品名

購入商品の商品名（漢字）11

単価

購入商品の単価

12

個数

購入商品の個数

13

商品合計金額

購入商品の合計金額

14外税額

外税の場合の税金額15内税額

内税の場合の税金額

19×N 繰り返しN : 購入商品種
類数

JAN コードは GS1 Japan(一般財団法人流通システム開発センター)が事業者に貸与した GS1 事業者コードを用いて商品ごとに設定された世界共通の商品識別番号である。
詳しくは GS1 Japan 公式サイト：https://www.dsri.jp/ 参照。

43

16

その他任意項目

店舗による任意追加項目

4.4 連携方式の拡張（連携方式②）
本書では今回のモデル事業で取扱った連携方式①を用いて、地域ウォレット事業者と決済事業者間における決済情報等のデータ連係方式について述べてきた。決済事業者が連携方式②、及び連携方式③を採用する際のデータ連携方式拡張案を、本節(4.4)
および次節(4.5)にて提示する。

連携方式①は、地域ウォレットから決済事業者登録をする場合、決済事業者側にアカウントを新規で登録する方式となっている。本節(4.4)で述べる連携方式②は、地域利用者が既に決済事業者の決済アプリにおいて、アカウント登録が完了していることを前提に、地域ウォレットから決済事業者登録する際に、登録済みの決済事業者アカウン
トを使用する方式となる（以下、既存アカウント連携方式という）。

なお、連携方式③を希望する決済事業者との連携方式として、次節(4.5）において、地域ウォレットが決済事業者のスーパーアプリ等によって連携する方向性を提示する（以下、スーパーアプリ等連携方式という）。
4.4.1

連携方式①の概要（再掲）
連携方式②を説明するにあたり、まず連携方式①の概要を再度要約して MPM の場合を例に説明する。黒丸数字は図表 26 中の黒丸数字に対応する。

44

図表 26 連携方式①概要（MPM の例にて説明）

a.

連携方式①では、地域ウォレットから決済事業者登録を行う際に、決済事業者 Aにより❶の決済用顧客 ID(図中では BBB)が払い出され、地域ウォレットの利用
者 ID と紐付けを行う。

b.

❶の決済用顧客 ID（BBB）は地域ウォレットの地域利用者用に、決済事業者 Aが新規で払い出したアカウントである。

c.

地域利用者が地域ウォレットを使って、地域の加盟店で決済を行った場合、決済事業者 A には❷の決済用顧客 ID(BBB)として、決済データが保存される。

d.

地域利用者が決済事業者 A の標準アプリで新規アカウント登録を行った場合、決済事業者 A は地域ウォレットとは異なる❸の決済用顧客 ID（CCC）を払い出す。

e.

地域利用者が決済事業者 A の標準アプリを使って、地域の加盟店で決済を行った
場合、決済事業者 A には❹の決済用顧客 ID（CCC）として、決済データが保存される。

連携方式①においては、地域ウォレットと決済事業者を決済事業者登録で紐付ける
場合、新規のアカウント登録が決済事業者側で行われる。また、実現するためには、決済事業者より新規で登録された決済用顧客 ID を地域ウォレットに通知する必要がある。地域ウォレット用に新たに決済事業者アカウントが作成されるため、地域利用者が45

決済事業者の標準アプリで作成したアカウントと別になってしまい、地域利用者が利用明細を一元管理できない課題もある。連携方式①は提携 Pay 方式として既に実績が存在するアカウント連携方式であるが、地域ウォレットと決済事業者標準アプリで別アカウントになることを推奨しない決済事業者向けに、連携方式②を次項に記載する。
4.4.2

連携方式②の概要
連携方式②は今回のモデル事業で取扱った連携方式①とは異なり、地域利用者はまず決済事業者の決済アプリから、決済事業者の新規アカウント登録を行う。決済事業者によって払い出された決済用顧客 ID を地域ウォレットにおいても共用する方式である。以下図表 27 にて概要を MPM の場合を例に説明する。黒丸数字は図表中の黒丸数字に対応する。
図表 27 連携方式②の概要（MPM の例にて説明）a.

地域利用者が決済事業者 A の標準アプリで新規アカウント登録を行った場合、決済事業者 A は❶の決済用顧客 ID（CCC）を払い出す。

b.

地域利用者が地域ウォレットから決済事業者登録を行う際、すでに取得済みの決済用顧客 ID(CCC)で❷で示すように決済事業者 A にログインを行うことで地域
ウォレットの利用者 ID と紐付けを行う。

c.

地域利用者が地域ウォレットを使って、地域の加盟店で決済を行った場合、また、地域利用者が決済事業者 A の標準アプリを使って、地域の加盟店で決済を行46

った場合、どちらの決済データも決済事業者 A には、❸の決済 ID(CCC)として保存される。

連携方式②においては、地域ウォレットの利用者 ID と決済事業者の決済用顧客 IDを決済事業者登録で紐付けする場合、既存の決済用顧客 ID を使用するため、決済事業者が新規でアカウントを作成する必要はない。
a.

連携方式②の課題と対策
地域ウォレットの利用者 ID と決済事業者の決済用顧客 ID を紐付けるためには、決済事業者より、地域ウォレット事業者に決済用顧客 ID の通知が必要である。
i. 課題
決済用顧客 ID を決済事業者の既存アカウントに紐付ける際の実現方式が決済事業者毎に異なる方式となることが考えられる。
決済事業者毎の方式を妨げることは避けたいものの、地域ウォレット事業者が複数の決済事業者と接続する際の負荷を減少させるためには、方式を共通化することが必要である。また、決済用顧客 ID 以外の適切な紐付けキーが必要となる。
ii. 対策
コード決済において、決済用顧客 ID 以外の紐付けキーが必要となるのは、利用者提示型（CPM）のみである。なぜならば、加盟店提示型（MPM）については、地域ウォ
レット事業者が決済事業者に決済入力データを送信するため、決済データと地域ウォレットの利用者 ID の紐付けが不要なためである。
利用者提示型（CPM）の場合、地域ウォレットの利用者 ID と決済事業者の決済デー
タ紐付けキーとして、一般社団法人キャッシュレス推進協議会発行の「コード決済に関する統一技術仕様ガイドライン【利用者提示型】」の「統一 QR コードの格納データ」に定義されている「決済 ID（事業者識別コード 8 桁＋トークン部）」20を使用することが可能である。
この「決済 ID」はユニークな ID として一般社団法人キャッシュレス推進協議会の「コード決済に関する統一技術仕様」(以下、JPQR 統一 QR コード仕様という)の必須項目として定義されており、JPQR 統一 QR コード仕様対応のバーコード、QR コード20「決済 ID」については、一般社団法人キャッシュレス推進協議会発行の「コード決済に関する統一技

術仕様ガイドライン【利用者提示型】」 Ver.1.2 の P.6 に掲載されている【表 3.2(2)統一 QR コードの格納データ】タグ’57’として定義されている。
参考 URL: https://www.paymentsjapan.or.jp/wordpress/wp-content/uploads/2019/10/CPM_Guideline_1.2.pdf

47

に必ず設定されているデータ項目であるため、決済データの紐付けキーとして適切で
ある。
4.4.3

CPM における連携方式②の概要
CPM において、決済 ID を活用した地域ウォレットの利用者 ID と決済データとの紐付け方式について図表 28 にて説明する。文中黒丸数は図表中の黒丸数字と対応する。
図表 28 決済 ID を活用した連携方式②の概要❶ CPM の場合、地域利用者が地域の加盟店で決済を行う時に、地域ウォレット
事業者は、決済事業者 A に QR 生成依頼を送信する。
➋ 決済事業者 A は、JPQR 統一 QR コード仕様に則った QR コードまたはバー
コードデータを地域ウォレット事業者に返却する。返却されたコードデータの中には決済 ID が必ず含まれている。
❸

地域ウォレット事業者は、決済事業者 A より返却されたコードデータに含まれる決済 ID を取り出し、地域利用者の利用者 ID と共にデータベースへ保存する。

❹

地域ウォレット事業者が地域ウォレットアプリにコードデータを返却した後、地域ウォレットアプリは、QR コードまたはバーコードを画面に表示する。

48

❺ 地域利用者は、地域ウォレットアプリの画面に表示された QR コードまたはバーコードを地域の加盟店で提示すると、加盟店 POS がコードデータスキャン
し読み取る。
❻ 加盟店 POS は地域ウォレットアプリから読み取ったコードデータを含む決済
入力データを作成し、決済事業者 A に送信する。この決済入力データには決済 ID が含まれている。
❼ 決済事業者 A は決済処理完了後、取引結果通知を地域ウォレット事業者に送信する。この時に既存アカウント連携方式を成立させるために、決済事業者 A
は、取引結果通知に必ず決済 ID を含める必要がある。
❽ 地域ウォレット事業者は、決済事業者から受信した取引結果通知に含まれる決済 ID から③で保存したデータベースを検索し、利用者 ID を取得すること
で、決済データと利用者 ID の紐付けが可能となる。
4.4.4

連携方式①との差異
連携方式②を採用した場合に連携方式①との間に生じる差異の有無を、以下図表 29に示す。MPM については、差異は生じないため、CPM のみが差異有りの対象となる。
図表 29 連携方式①との差異
項目

差異有無

2 決済情報等の取得方法と課題無し

3 データ間の紐付け有り「4.4.5 データ間の紐付けに関する差異」参照

4 電文仕様標準有り「4.4.6 電文仕様標準に関する差異」参照

4.4.5

備考

データ間の紐付けに関する差異
本書「3 データ間の紐付け」にて、連携方式①について「3.1.1 利用者属性データと決済データの紐付け」と「3.1.2 決済データと購買データの紐付け」の紐付けについて
記載した。
a.

利用者属性データと決済データの紐付け

i. 概要
利用者属性データと決済データの紐付けについては、決済 ID と利用者 ID を紐付けることで可能となる。図表 15 データの紐付け関連項目の図は、紐付けキーに決済用
顧客 ID を使用していたが、決済 ID を紐付けキーとすることで、以下図表 30 の通りに変更となる。

49

図表 30 データの紐付け関連項目（決済 ID 活用）

文中の丸数字は、図中の丸数字と対応している。なお、今回のモデル事業では、データの紐付け処理は地域ウォレット事業者が行う。

a ①の利用者属性データは、②の地域ウォレットアプリから③地域利用者が利用者登録を行う時に入力したデータである。
b 利用者登録時に、④の地域ウォレット事業者が⑤の地域ウォレット基盤で、③の地域利用者に発行する ID を本書では⑥の利用者 ID と称する。
c ③の地域利用者が⑫の店舗で商品購入時に、⑦の決済事業者により QR コードまたはバーコードデータが作成され、⑤の地域ウォレット基盤に連携される。QR
コードまたはバーコードデータの中に取引毎にユニークな ID として設定されているのが⑧の決済 ID である。
d ⑤の地域ウォレット基盤で、⑥の利用者 ID と⑧の決済 ID を紐付けるため、地域
ウォレット事業者は⑨の ID 紐付けテーブルに登録する。それにより⑤の地域ウ50ォレット基盤では、⑦の決済事業者から連携される⑩決済データに含まれる⑧の決済 ID と⑥の利用者 ID を突合することで、①の利用者属性データと⑩の決済データを紐付けることが可能となる。
e ⑨の ID 紐付けテーブルは、⑤の地域ウォレット基盤上で管理する ID データを紐付けるためのコード変換用テーブルである。
f

本章では地域ウォレットの⑥利用者 ID と⑦の決済事業者が管理する⑧の決済 IDを紐付けている。

g このテーブルを利用することにより、⑩の決済データに入っている⑧の決済 ID
を⑥の利用者 ID に変換することが可能になる。
h ③の地域利用者を識別する ID を⑥の利用者 ID に統一することで、データ分析を容易にすることができる。
i

最終的にデータ利活用を行うために、⑤地域ウォレット基盤上では①の利用者属性データと⑩の決済データを⑪のデータ利活用基盤に渡す必要がある。

j

その際に⑩の決済データの⑧決済 ID を⑥利用者 ID に変換し、⑪データ利活用
基盤に送信する。

地域ウォレット事業者が ID 紐付けテーブルへ登録する手順
図表 16 で利用者 ID と決済用顧客 ID の紐付けフローについて記載したが、決済用
顧客 ID の代わりに決済 ID を紐付けるため、図表 4.4-06 に利用者 ID と決済 ID の紐付け処理フローを示す。図表 3.2-01 においては、決済事業者登録において、利用者 IDと決済用顧客 ID の紐付けを行ったが、図表 4.4-06 では地域利用者が店舗で決済を行おうとする度に、決済事業者より QR コードまたはバーコードデータと共に新たな決済 ID が発番される。図表 3.2-01 では決済事業者登録時に、ID 紐付けテーブルを作成したが、図表 31 では決済の都度 ID 紐付けテーブルを作成する違いに留意が必要である。以下に利用者 ID と決済 ID が地域ウォレット事業者により ID 紐付けテーブルへ登録される手順を示す。決済 1 回目、2 回目は決済事業者 1 が発番した決済 ID と利用
者 ID の紐付け、決済 3 回目は決済事業者 2 が発番した決済 ID と利用者 ID の紐付けについて記載している。丸数字は図表中の丸数字に対応する。

51

図表 31

ID 紐付けテーブル登録手順① 地域利用者（利用者 ID：001）が決済を行う前は地域ウォレット事業者の ID 紐
付けテーブルに利用者 ID が 001 のデータは登録されていない。
② 地域利用者（利用者 ID：001）が店舗で CPM による決済を行おうとした場合、地域ウォレットアプリは、QR 生成依頼を地域ウォレット事業者経由で決済事
業者 1（決済事業者識別：0000A）に送信する。
③ 決済事業者 1 は、QR コードデータを生成し、地域ウォレット事業者に返答する。その際 QR コードデータに決済 ID A000001 が含まれている。
④ 地域ウォレット事業者は、地域利用者(利用者 ID：001)に対して、決済事業者
1（決済事業者識別：0000A）が発番した決済 ID A000001 が紐付けられた旨のレコードを登録する。

52

⑤ 更に地域利用者（利用者 ID：001）が 2 回目の決済を行おうとした場合、同様に 2 回目決済用の決済 ID A000002 が登録される。
⑥ 地域利用者（利用者 ID：001）が 3 回目の決済として、決済事業者 2（決済事
業者識別：0000B）で決済を行おうとした場合、地域ウォレット事業者は、地域利用者（利用者 ID：001）に対して、決済事業者 2 が発番した決済 ID B000001
が紐付けられた旨のレコードを登録する。

以上の様に、地域ウォレット事業者は ID 紐付けテーブルにより利用者 ID と決済 IDを紐付けることができるため、決済事業者から決済データを受信した際に、決済データに登録されている決済 ID から、ID 紐付けテーブルにより利用者 ID を割り出し、利用者 ID と決済データを紐付けることが可能となる。
b.

決済データと購買データの紐付け
決済データと購買データの紐付けについては、連携方式①と同じ方式で紐付けることになるため、決済 ID を活用することによる影響はない。
4.4.6

電文仕様標準に関する差異
本節(4.4) の「4.4.3 CPM における連携方式②の概要」に記載した通り、CPM において、決済事業者が地域ウォレット事業者に送信する取引結果通知に決済用顧客 ID の代替として、決済 ID を標準項目として追加する。
尚、MPM における連携方式②では、地域ウォレット事業者が決済事業者に決済入力
データを送信するため、連携方式①と比較して電文仕様に差異はない。
a.

API 入力データ 利用者提示型（CPM）

i. 取引結果通知① 決済事業者が地域ウォレットに対して送信する取引結果通知メッセージ API のことである。決済事業者から送信先への一方向通知メッセージとなる。

53

② 店舗が売上の取消を行った場合、決済事業者は取引結果通知（取消）を地域ウ
ォレット事業者に送信する。

■取引結果通知
項目

説明

標準項目
1

決済 ID

JPQR 統一 QR コード仕様 Tag’57’に定義されている「決済 ID」(事業者識別コード 8 桁＋トークン部）

2

加盟店 ID

加盟店企業を識別する ID

3

店舗 ID

加盟店企業の店舗を識別する ID

4

決済処理通番決済事業者が発番した取引のユニークな通番、トランザクション ID として利用可能なデータ

5

決済金額

決済取引の合計金額（税・送料含む）

6

処理種別

取引の処理種別（「売上」または「取消」）

7

決済処理結果取引の決済処理結果

8

元取引決済処理通番取消の場合に元取引の決済処理通番を設定

9

元取引金額

取消の場合に元取引の決済金額を設定

54

推奨項目
10

加盟店処理通番加盟店企業が発番した取引のユニークな通番

11

元取引加盟店処理通番取消の場合に元取引の加盟店処理通番を設定

任意項目
12

その他任意項目API 提供者（決済事業者）による任意追加項目

ii. 照会（取引結果通知が受け取れない場合の対応）
上記取引結果通知がネットワーク障害等の理由により受け取ることができなかった
場合、連携方式①では照会 API の利用を提示した。しかし、連携方式②では、決済用
顧客 ID で照会することができないため、照会 API の利用は現実的ではない。
課題
照会 API に代わる仕組みに構築が必須である
解決策
照会 API の代替として、取引結果通知を受け取ることができない場合は、運用対応が必要となる。具体的な運用対応については、地域ウォレット事業者と決済事業者による事前の合意が必要である。
例） 地域ウォレット側の 1 日分の取引明細を、決済事業者に送信し、決済事
業者側にて決済事業者側の取引明細との差異を確認するという対応が考えられる。

4.5 連携方式の拡張（連携方式③の方向性）
本節では、連携方式③として決済事業者のスーパーアプリのミニアプリ等、各決済事
業者の個別ソリューション内部へ作り込むことで連携を実現するアプローチを提示する。
連携方式③は、各決済事業者が個別で提供する API に大きく依存するアプローチであるため、現時点では方向性の提示にとどめる。
図表 32

決済事業者と地域のデータ利活用における共創についての考えを提示した。地域のデータ利活用において両者が相互協力し、双方にバリューが生じる方向性が望ましい形と考える。

55

図表 32 決済事業者と地域のデータ利活用における共創4.5.1

連携方式③-1：スーパーアプリ内ミニアプリ連携方式
決済処理はスーパーアプリ内のミニアプリで行い、地域利用者の属性等のデータ収集と複数決済手段の振り分けは地域ウォレットで行う方式である。取得する決済デー
タのデータ項目は連携方式①、及び連携方式②と同様になることを想定している。以下
図表 33 で説明する。丸数字は図表中の丸数字に対応する。

56

図表 33 スーパーアプリ内ミニアプリ連携方式① 地域利用者は地域ウォレットアプリの決済手段選択にて、決済事業者 B の決済
手段を選択する。
② 地域ウォレットは決済事業者 B のスーパーアプリに処理を遷移させる。
③ 地域利用者のスマートフォンでは、決済事業者 B のスーパーアプリが起動されるので、地域ウォレットのミニアプリで決済を行う。
④ 地域加盟店の QR コードを読取り、決済事業者 B にて決済が行われる。
⑤ 決済完了後、地域ウォレットのミニアプリは、地域ウォレット基盤に決済デー
タを保存する。
⑥ 地域ウォレット基盤は地域ウォレット（本体アプリ）の地域のデータと地域ウォレットミニアプリの決済データを紐付けて、データをデータ利活用基盤に送信する。
⑦ データ利活用基盤は地域の利活用データを決済事業者に提供可能とする。
4.5.2

連携方式③-2：地域ウォレットとオンライン決済の連携方式
連携方式③-2 は、決済機能を分割する方式だが、QR コード読取りまでを地域ウォレ

ット側で行い、その後の決済処理をモバイルオーダー等のアプリで使われている既存手法（決済事業者のオンライン決済の仕組み）で行う方式である。本連携方式では、決済事業者のスーパーアプリとの連携は行わないが、取得する決済データのデータ項目
は連携方式①、及び連携方式②と同様になることを想定している。以下図表 34 で説明する。丸数字は図表中の丸数字に対応する。

57

図表 34 地域ウォレットとオンライン決済との連携イメージ① 地域利用者は地域ウォレットアプリの決済手段選択にて、決済事業者 B の決
済手段を選択する。
② 地域利用者は、地域ウォレットアプリ内の QR コード読み取り機能を使って、地域加盟店の QR コードを読み取る。
③ 地域ウォレットは決済事業者 B のオンライン決済 API をコールする。
④ 決済完了後、地域ウォレットは、地域ウォレット基盤に決済データを保存する。
⑤ 地域ウォレット基盤は地域の取得データと決済データを紐付けて、データ利活用基盤に送信する。
⑥ データ利活用基盤は地域の利活用データを決済事業者に提供可能とする。
4.5.3

今後の検討事項
連携方式③は、前述の通り決済事業者と継続的な議論が必要であり、現時点での主要検討項目は以下の通りである。

58

図表 35 連携方式③に係る今後の検討事項
連携方式素案１

連携方式素案２（別案）

決済方式

スーパーアプリ内でのＱＲ決済を実現する技 オンライン決済にて、店舗によるオフライン決済と術的な課題と対策を検討
同等機能の実現が可能か検討

アクセシビィリティ

スーパーアプリ内でのミニアプリの検索性や、外部からミニアプリへのリンクの可能性 特に検討項目なし
についての検討

データ取得

ミニアプリ提供者がデータ取得・利活用する オンラインＡＰＩの呼び出し元でデータ取得・利活ことに関して課題があれば検討用することに関して課題があれば検討

59

5 地域ウォレットの実装に向けて5.1 本書の改訂方針
本書の記載内容に関しては、今後発生する課題、及び法規制や社会環境の変化等に応じて改訂が必要である。キャッシュレス推進協議会は適時、本書の改訂についての検討を行うものとする。

5.2 決済事業者とデータ連携を始めるにあたり考慮する留意点
本節では、モデル事業で実際に地域ウォレット事業者が決済事業者とデータ連携を始める際に考慮が必要となった留意点を記載する。尚、取得した決済データの取扱いに係る課題は、地域におけるデータ利活用のためのコード決済情報等の適正な取扱に関するガイドラインに記載する。なお、本節は連携方式①と連携方式②が対象となる。連
携方式③については、今後検討が必要となる。
（「5.5 本ガイドラインの改訂検討項目」
を参照）
5.2.1

決済事業者との事前共有事項
地域ウォレット事業者は、決済事業者とのデータ連携において、地域ウォレットの目

的や位置付け、決済事業者との役割分担、ビジネスモデル等を事前に共有し、決済事業者と合意する必要がある。

地域ウォレット事業者から決済事業者へ事前に共有すべき事項を以下に記載する。
尚、これ以外にも両者協議の際に、条件や役割分担、責任所在等で不明点が生じる可能性もあるため、協議の中で明確にした上で合意する必要がある。
a.

地域ウォレットの目的と位置付け• 地域ウォレットの対象地域や実施目的、地域ウォレット事業者の位置付けや主体
者の明確化

b.

決済事業者との役割分担• 地域ウォレット事業者と決済事業者の役割の明確化（地域ウォレットの利用者募
集、地域ウォレット参加店舗開拓、地域ウォレット参加店舗管理、加盟店精算業
務等の役割分担）60

c.

ビジネスモデルの概要• 地域ウォレット事業者と決済事業者を中心に、関連事業者も含まれた提供サービ
スと資金の流れの概要について明確化

d.

想定業務フロー• 地域ウォレット事業者と決済事業者間の想定業務フローを明示

e.

想定システム処理フロー• 地域ウォレット事業者と決済事業者間の想定システム処理フローを明示

f.

運用開始までのスケジュール• 地域ウォレット事業者の運用開始までの想定スケジュールを明示

5.2.2

セキュリティレベルの合意形成
地域ウォレット事業者が、決済事業者とデータ連携するにあたり、経済条件や技術仕様をはじめとし特にセキュリティレベルの合意形成で慎重な検討が必要になる。以下、システム構築や運用におけるセキュリティ要件の代表的な事例を記載する。具体的なセキュリティ要件は、データ連携する決済事業者と個別にすり合わせを行う必要がある。
a.

開発・運用体制• システムの開発、運用、保守に関連するドキュメントの整備、リスクへの措置・対策、オフショア開発業務リスクへの対策、脆弱性への対策、セキュリティ監視対応等

b.

アクセス管理• ユーザのアクセス管理手順、ID・パスワード漏洩対策、ID の在庫管理、操作ロ
グの取得等

c.

ネットワーク• ネットワーク設定情報の管理、機器の導入手続き等d.

サイバーセキュリティ対策• 不正アクセス防止への対策、不正発覚時の対応手順、HW/SW のセキュリティパ
ッチポリシー等e.

マルウェア対策• ウイルス対策ソフトの利用、OS のシステム構成ファイル管理実施等

61

f.

不正利用対策
• 社内利用者のアクセス管理ポリシー、不正利用検知に関する運用ルール等

g.

クラウド利用• 社外クラウドサービス利用における契約、体制の確認等

h.

外部委託管理• 外部委託取引におけるセキュリティ確保対策等

5.3 地域ウォレットとのデータ連携に伴う決済事業者の業務
今後、決済事業者が地域ウォレットとデータ連携を進めるにあたり、決済事業者側に発生する業務は、主に次のようなものが想定される。
a.

各種契約手続き• 地域ウォレット事業者との各種契約手続き（例えば包括加盟店契約、業務提携契約、API 接続契約、決済代行サービス利用契約等の該当契約）b.

API 仕様提示• 地域ウォレット事業者と決済事業者間で接続に必要な API について地域ウォレッ
ト事業者へ提示c.

接続技術のサポート• 地域ウォレット事業者が決済事業者と接続する上で、地域ウォレット事業者からの技術的な問合せに対するサポート

d.

疎通試験
• 地域ウォレット事業者と決済事業者との事前の疎通・接続試験対応の実施

e.

各種開発・設定変更作業• 決済事業者が地域ウォレット事業者と接続するにあたり、決済事業者システムの開発・設定変更等の対応

f.

本番運用サポート• 本番運用開始後の各種問題に対する地域ウォレット事業者からの問合せ対応

62

5.4 決済事業者との共創に向けて
各決済事業者も自社アプリを軸に地域活性化とデータ共有の取組みを今後の想定においている。地域におけるデータ利活用という本取組みは、各決済事業者のアプリ戦略と共存しつつ、共創可能な選択枝の一つとなることを目指す。
図表 36 決済事業者との共創に向けて

5.5 本ガイドラインの改訂検討項目
本書は、現時点において考え得る範囲で決済事業者や店舗からの決済データ、購買データの取得について、主にその実現方式を記載したものである。

63

5.1 本書の改訂方針に示した通り、本書の記載内容に関しては、今後発生する課題、及び法規制や社会環境の変化等に応じて改訂が必要であり、キャッシュレス推進協議
会は適時、本書の改訂についての検討を行うものとする。
仮説的に設定した今回のモデル事業では、決済事業者、店舗や消費者、自治体・公共機関等にとって長期的なインセンティブ創出につながるように設計し推進したが、モデル事業を通していくつかの課題も抽出できた。
地域全体にキャッシュレス化、決済データの利活用を広げる上で、いま一度、店舗や消費者にとってのキャッシュレス化によるメリットをよりわかりやすく提示することが重要であることも再認識した。
今後の取組みとして、本書を基に各ステークホルダーのメリットや実装に向けたフィージビリティを高めるためにも、継続的に各決済事業者と議論を重ねることが肝要である。
なお、次版の改訂に向けて以下に論点の事例を示す。本書の主な読者である地域ウォ
レット事業者、決済事業者、地域ウォレットを活用する店舗の IT システムに関わる企画担当者、推進担当者、エンジニア等の声にも耳を傾け、次版の改訂に繋げたい。
図表 37 本書の改訂に向けた論点例
No
1

論点例
ステークホルダーが取組やすい利用シーンの具体化2

個人情報の流通に伴う課題や対策

3

地域利用者の使い易さ

4

決済事業者の実装方式

5

データ連携を始めるにあたっての留意点

概要
地域ウォレット事業者、決済事業者、店舗、地域利用者等、各ステークホルダーが、決済データの利活用を自分事として考えやすい具体的な利用シーンを議論する
地域のキャッシュレス化や決済データの利活用によって取得した個人情報が、地域やステークホルダー間で流通することに伴う課題や対策を議論する
利用シーンを特定した場合に、その利用シーンにおける地域利用者の使い易さ（アプリの操作性等）を議論する
利用シーンを特定した場合に、その利用シーンに最もフィットした実装方式について、決済事業者と議論する
決済事業者が地域ウォレットへの連携を実装するにあたり、特に連携方式②や連携方式③においてデータ連携を始めるにあたっての考慮点、決済事業者の責務等について具体的に議論する

64

6 用語集
用語

読み方

意味

API

えいぴーあいApplication Programming Interface の略称である。外部シ
ステムや外部アプリケーションの機能を共有するためのイ
ンターフェイスのことである。

加盟店処理通番

かめいてんしょりつうばん

加盟店が決済取引 1 件毎にユニークに発番する通番である。決済データと購買データ双方に設定された場合、決済データと購買データの紐付けキーとして使用することが可
能である。

決済事業者

けっさいじぎょうしゃ

店舗に決済手段を提供している企業のこと。本書ではバー
コード・QR コード決済を提供している事業者である。

決済情報等

けっさいじょうほうとう

本書ではデータ利活用に使用する決済データ、購買デー
タ、利用者属性データを総称して決済情報等と呼称する。

けっさいしょりつうばん

本書では決済事業者が決済取引 1 件毎にユニークに発番する通番である。決済データと購買データ双方に設定された
場合、決済データと購買データの紐付けキーとして使用することが可能である。

決済データ

けっさいでーた

本書では決済取引が発生したときに、店舗から決済事業者に送信した決済入力データとおよび決済事業者から店舗へ
決済処理結果を返答する決済取引データを総称して決済データと呼称する。「いつ」、「どの店舗で」、「誰が」、「いくらで」、「どの決済手段」を使ったのか知ることが可能である。

決済取引データ

けっさいとりひきでーた

本書では地域利用者が店舗で決済を行う際、決済事業者が決済を行った結果を店舗に応答するデータを決済取引デー
タと呼称する。

決済入力データ

けっさいにゅうりょ
くでーた

本書では地域利用者が店舗で決済を行う際、店舗から決済事業者へ決済を依頼するデータを決済入力データと呼称する。

決済処理通番65

用語

決済用顧客 ID

購買データ

コード決済事業者

読み方意味

けっさいようこきゃ
くあいでぃー

本書では決済事業者が管理する地域利用者の ID を決済用
顧客 ID と呼称する。決済データと利用者属性データの紐付けキーとして利用する。
決済用顧客 ID は地域ウォレットの利用者 ID と決済デー
タを紐づけることができればどの様な ID でも良い。必ずしも決済事業者の内部で管理している顧客 ID を指していない。

こうばいでーた

本書では店舗側で生成する購買取引データである。「いつ」、「どの店で」、「誰が」、「どの商品を」、「いくつ」、「いくらで」購入したのかを含むデータである。購入商品名、単価、購入数等が含まれる。

こーどけっさいじぎょうしゃ

主にバーコード決済および QR コード決済を提供する決済事業者のこと。コード決済事業者の中には、他の決済手段（オンライン決済、非接触決済等）を取り扱う事業者も存在する。

じぇいぴーきゅーあーる

総務省が経済産業省と連携して、一般社団法人キャッシュレス推進協議会が策定した決済用統一 QR コード・バーコード」のことである。
出典：2020 年度総務省統一 QR[JPQR]普及事業ホームペ
ージより

しょうかい

本書では決済取引後に取引明細を決済事業者に照会をする業務のことである。本書では地域ウォレット基盤が取引結
果通知を取得できなかった時に利用する業務として記載している。

地域ウォレット

ちいきうぉれっと

本書では地域の暮らしの中で役立つ「財布」のような決
済、ポイント、クーポン、診察券などの機能を備え、地域に特化したスマートフォンアプリケーションとサービス全体を総称して地域ウォレットと呼称している。

地域ウォレット基盤

ちいきうぉれっとき
ばん

本書では地域ウォレットアプリと連携するサーバーシステ
ム基盤のことを地域ウォレット基盤と呼称する。アプリ利
用者の管理、データ利活用基盤との連携を行う地域ウォレットの中核システム基盤である。

地域利用者

ちいきりようしゃ

本書では地域ウォレットを利用する地域住民を指す。また地域への観光客を利用対象とする地域ウォレットの場合
は、観光客を指すこともある。

ていけいぺい提携する決済事業者の機能を利用して決済サービスを提供するが、ウォレット事業者自身は決済機能を保有しない。
すなわち提携により決済機能を提供することから名付けられた呼称である。

JPQR

照会

提携 Pay

66

用語

読み方

意味

データ利活用基盤

でーたりかつようきばん

本書では利用者属性データ、決済データ、購買データを集約し、データ利活用のためのデータ分析を行うシステム基
盤である。

店舗提示型
(MPM)

てんぽていじがた（えむぴーえむ）

店舗提示型とはバーコード・QR コード決済において、消費者が店舗に掲示または POS 画面に表示されたバーコー
ド・QR コードをスマートフォン決済アプリで読み取り、支払いを行う方式である。省略して MPM(MerchantPresented Mode)と呼ばれている。

取引金額

とりひききんがく

本書では一回の決済取引において、決済した金額の合計のこと。通常、税送料含む金額を指す。

取引結果通知とりひきけっかつうち

本書では決済取引が行われた結果（正常または異常）を店
舗や利用者に通知するシステム通知メッセージのことである。

とりひきつうばん

本書では取引を一意に特定するための通番の総称。加盟店
処理通番や決済処理通番は取引通番に含まれる。通し番号ではなくアルファベットを併用することもある。通常、決済事業者側だけでなく、店舗側でも発番することがある。
取引を一意とするため、どちらを利用するかは、決済事業
者と店舗の合意が必要となる。

POS

ぽす

販売時点情報管理(Point of sales の略)のこと。店舗において「いつ、どの商品が、いくらで、いくつ売れたか」を把握し、売れ行き動向を分析することが可能である。本書では店舗の購買データを POS にて生成することを想定している。

利用者 ID

りようしゃあいでぃー

本書では地域ウォレット基盤にて発管理番する地域利用者
個人を識別する ID のことである。

利用者属性データ

りようしゃぞくせい
でーた

本書では地域利用者個人の属性データのことである。通常
は地域ウォレット利用登録時に、アプリから地域利用者によって入力されるデータである。

りようしゃていじがた（しーぴーえむ）

利用者提示型とはバーコード・QR コード決済において、消費者のスマートフォン決済アプリの画面に表示されたバーコード・QR コードを店舗のリーダーが読み取り、支払いを行う方式である。省略して CPM(Consumer PresentedMode)と呼ばれている。

取引通番

利用者提示型(CPM)

67