IT」カテゴリーアーカイブ

接触確認アプリはそもそも役に立たない:その1

※以下、IT業界用語はできるだけ避ける。

政府が2020年6月に導入するらしい接触確認アプリの仕様書を読んで、いちばん危ないんじゃないのと思う点があった。(仕様書はこちら

「処理番号」だ。

仕様書のp.13に、検査で陽性になった場合の処理の流れが書かれている。p.5のデータの流れと合わせると分かりやすい。

検査で陽性になった人に、保健所が「感染者システム」で処理番号を発行し、陽性者に通知、陽性者は自分のスマホから接触確認アプリに入力することになっている。

入力された処理番号はいったん「通知サーバー」に送信され、そこから感染者システムに送信、感染者システムが正規の処理番号であることを確認する。

確認結果は「通知サーバー」経由で陽性者の端末のアプリに送信される。

確認結果がOKならアプリから自動的に「通知サーバー」に感染報告(日次キーと時刻情報)がアップロードされる。確認結果がNGならエラーメッセージが表示される。

処理番号の確認が取れる前に、アプリから感染報告ができてしまったのではマズいので、確認結果OKを受信してはじめて、感染報告処理が実行される。

ここまででもうナゾが山ほどある。そのナゾは以下、順に書いていく。

ところで「認証情報」という意味不明の用語が登場し、仕様書の中でここにしか登場しない。

「認証情報」の定義はないが、p.11に「認証機能」の定義は書いてある。「感染時に、感染者本人から入力かどうかを確認する」とのこと。(「~からの入力か」で「の」がないのは誤植だろう)

感染者本人かどうかを確認する認証のしくみについて、この仕様書のどこにも書かれていないのに、かんたんな定義だけがサラッと書いてある。

この「認証情報」が要配慮個人情報に当たるかもしれないにもかかわらずだ。

いずれにせよ、明確な定義がないのでいったん置いておく。後から「実はこの本人認証機能が不正利用を防ぐために重要なんです」とならなければいいけれど。

かんたんな処理番号のリスク

話をもどして、このアプリの不正利用をどうやって防ぐかだが、処理番号がかんたんに推測できたのでは、イタズラ入力で接触確認アプリの信用が落ちる。

たとえば、頭文字が都道府県コードで、その後は年月日と連続番号、なんていうのはダメだろう。

いちばん良いのは、人間が覚えられない長くて複雑な文字列をQRコードなどにして送信し、感染者がアプリで読み取るというふうに、人間が入力をしない仕様だろう。

そうすれば入力ミスも防げるし、勝手な処理番号の作成も難しくなる。じっさいのアプリではどうなるだろうか。

処理番号を本人に伝えるときのリスク

たぶんメールかSMSだろう。メールアドレスと携帯番号は「感染者システム」に入力するはずなので。

メールの場合、陽性者がかんたんなパスワードで二要素認証もなしにメールを使っていないことを祈る。陽性者のメールがかんたんに不正アクセスされるのでは、不正利用につながってしまう。

SMSの方が良さそうだが、どちらも詐欺被害のおそれはある。

「システムの不具合でセンターと通信ができないため、お手数ですが保健所のホームページから処理番号の入力をお願いします」などの文面で、ニセのウェブサイトに誘導され、処理番号をだまし取られてしまうという詐欺だ。

「フィッシング」「スミッシング」と呼ばれるものだが、たぶん起こるだろう。

処理番号が通知サーバーを通るリスク

陽性者がアプリから処理番号を入力した後、なぜ直接保健所の「感染者システム」に送信せずに、通知サーバーを経由する仕様になっているのか。筆者には分かりづらい。

一つ考えられるのは、保健所の「感染者システム」は個人情報のかたまりなので、このシステム自体にインターネットから処理番号を直接受けとる口を作りたくないという理由。

通知サーバーはもともと不特定多数のスマホと通信するので、高いセキュリティが求められる。一方、場所が特定できる保健所のシステムとの通信は、セキュリティを確保しやすい。

なので、通知サーバーで両者を仲介し、感染者システムを直接インターネットにさらさないようにすれば、全体としてより安全なシステムになるということかもしれない。

この接触確認アプリと感染者システムの連携の部分が、要配慮個人情報の漏えいを防ぐためのいちばんの肝になると思う。

(通知サーバーと感染者システムを同一業者が運用する場合の漏えいリスクも含めて)

残念ながらこの仕様書には「本アプリと感染者システムとの連携については、本仕様書の範囲に入れずに」(p.5)とあり、どのように実現されるかはこれからになる。

処理番号だけで「本人のスマホ」をどう確認するのか

たぶんできない。

保健所の感染者システムが、アプリから入力された処理番号を受け取ったとき、その処理番号が「本人のスマホ」から入力されたものであることは確認できない。

この話の前にまず確認したいのは、「本人が」入力したかをチェックする必要はないということだ。

誰が入力しようと、陽性者の日次キーと時刻情報が記録されている「本人のスマホ」に入力してくれれば、正確な接触履歴が通知サーバーに送信されるのでOK。

「本人」かどうかを確認する必要はなく、「本人のスマホ」かどうかが確認できればよい。

イタズラで無関係なスマホから入力されたのでは、無関係な日次キーが感染者のものとして通知されてしまうので、接触確認アプリの信用がガタ落ちになるためだ。

※ちなみにスマホ2台持ちの場合、たとえば会社から支給された業務用スマホと、プライベートのスマホを持って生活している場合どうするのかなど、細かい問題は残るが、本筋から外れるので省略。

しかし、保健所の感染者システム側で、「本人のスマホ」から入力されたものだと確認するには、接触確認アプリがスマホを特定する端末IDを、処理番号とともに感染者システムへ送信する必要がある。かつ、感染者システム側も、事前に端末IDを知っている必要がある。

確認した結果を感染者システムから「本人のスマホ」に返すときにも、「本人のスマホ」を特定する端末IDが必要だ。

端末IDがなくても、一連の処理を開始するときその処理に唯一のID(セッションID的なもの)があればいい、というのは間違いだ。

処理の開始そのものを別の端末で不正に行われるおそれがあり、処理に対するIDしかなく、端末IDがないしくみでは、通信元が「本人のスマホ」であることを確認できない。

処理番号より端末ID

いろいろ考えると、最初から端末IDを処理番号にすればいいことになる。

つまり、保健所は事前に、陽性者本人のスマホのアプリが発行した端末IDを感染者システムに登録しておく。本人の端末から感染報告をするための予約番号的な意味合いになる。

そして、感染者本人(でなくてもよい)が「本人の端末」のアプリから「陽性報告します」という意思表示を入力する。

意思表示だけで、処理番号のようなものを入力する必要はない。「報告する」ボタンを押すだけになる。(もちろん報告の義務はないので押さなくてもいい)

この報告を感染者システムに送信するとき、自動的に事前に感染者システムに知らせておいた端末IDをくっつけて送ればよい。

すると、感染者システム側で事前に登録してある端末IDと突き合わせて「本人のスマホ」だと確認でき、本人の「報告します」という意思も確認できる。

そして通知サーバー経由で、端末IDをたよりに「本人のスマホ」へ確認完了を返信すると、その「本人のスマホ」内のアプリが自動的に通知サーバーに日次キーをアップロードするという流れになる。

このやり方だと、端末IDも要配慮個人情報になってしまうが、陽性者以外の誰かが不正に処理番号を入手し、無関係なスマホから入力することは防げる。

処理番号も要配慮個人情報、端末IDも要配慮個人情報で、不正利用をより強力に防げるのは端末IDパターンとなる。

だとすれば、なぜ処理番号ではなく端末IDにしなかったのか。

アプリが発行する端末IDも、その人が陽性になって報告の意思を示すたびに(ご承知のように退院後にふたたび陽性になる事例はある)発行しなおして使い捨てにすればよい。

いずれにせよ、処理番号パターンでは、無関係なスマホから処理番号を不正に入力され、陽性者のスマホものではない日次キーが、アプリの利用者に通知されるおそれがある。

「使い捨て端末ID」の方が、アプリの不正利用防止の点ではすぐれているように見える。

それでも処理番号になっているのは、ここで例の「認証情報」の出番になるからではないのか。処理番号と「認証情報」を合わせて感染者システムに送信することで、「本人のスマホ」からの送信だと確認することを想定しているのではないか。

もしそうなら、この仕様書にはもっとも重要なことの一つが書かれていないことになる。

そもそも接触確認アプリは役に立つのか

ここまで接触確認アプリの不正利用リスクについてさんざん書いておきながら何だけれど、個人的にこのアプリは役に立たないと考えている。

理由は大きく二つ。有効性がないことと、通知をうけてもどうしようもないこと。

まず有効性がないこと。

有効性がない理由は、使う人が増えないと無用の長物になること。海外の導入済みの国で利用者が伸び悩んでいるのはご承知のとおり。

シンガポールではとうとう、人が多く集まる場所で強制的に入退場を記録するアプリを導入して、感染リスクの高い場所にフォーカスした対策を追加でやらざるを得なくなった

いちばん単純な計算で、人口の4割が使っても、すべての接触の可能性の2割弱しか把握できない。接触通知をうけても「残りの8割は?」となる。

しかも常にBluetoothをONにしてスマホを使っているとは限らないし、肌身離さずスマホを持ってるわけではない。スマホをどこかに置き忘れたら、接触していない人と接触したことになる。

狭いマンション暮らしでは、上下左右のお隣さんが接触者になる。

満員電車で通勤すれば大量の無意味な接触履歴が残る。

満員電車で集団感染が起こることは少ない、という説が正しくても、間違っていても、接触履歴は無意味になる。なぜ無意味かはこのあと説明する。

また、仕事で感染者と接する人、たとえば感染者を受け入れる病院の医療従事者やスタッフ(事務員、清掃員、売店の店員さん等々)の方々は、受けても意味のない通知をたくさん受けることになる。

感染者は、来院して診断が確定した後に感染を報告するため、報告する前に感染者と接触した医療従事者やスタッフの方々は、そのときスマホを持っていればシステム上は接触者になる。

感染者をつぎつぎ受け入れていれば、無意味な接触通知がつぎつぎ届くことになる。

ただそういう方々は、病院での感染者との接触については十分な対策をしているので通知を受けても意味はないとしても、プライベートで誰かと接触があれば、そちらの方は報告したいと思うだろうし、通知を受ける意味があるかもしれない。

しかしアプリは病院での接触とプライベートでの接触を区別してくれないので、病院関係者の方々にとって、アプリの通知はほぼ無意味になる。

このように接触通知アプリは、使う人によって、利用者が少なくて通知が来ないか、誤検知が多くて通知が来すぎるかになる。海外で使われている同じ種類のアプリにも同じことが起こる。

通知が来るにしても来ないにしても、そのことをどう判断すればいいのか分からなくなる、ということだ。

通知をうけてもやることがない

次に、二つ目の理由。通知をうけてもどうすればいいの?ということ。

接触通知をうけたら単に「体調の変化に気をつけましょう」だけなら、「これだけ流行してるんだから普段から気をつけてますよ」でおしまいだ。

毎日満員電車で通勤している人は、満員電車に集団感染リスクがあろうとなかろうと、感染するかもしれないと恐れつつ乗っている。

ところがアプリの通知が来ても、感染者と接触した場所を教えてくれるわけではない。

やっぱり満員電車が危なかったのか、生活の中で他の場所を避けるべきだったのか、という情報さえ手に入らない。

また、通知をうけたらすぐ病院に行って診察をうけましょうというなら、症状も出ていない人で外来がたちまちいっぱいになってしまう。

通知をうけたらPCR検査を受けられるように制度化するとなると、かなりの規模の検査体制の整備が必要になり、現実的ではない。

通知をうけたことが心配で保健所に電話をかける人が増え、保健所の方々の負荷がさらに大きくなるかもしれない。

このように、そもそも通知がどこまで信用できるのか分からないし、通知をうけたとしても、いつ、どこで接触したのか分からないので、どう行動を変えればいいのかも分からない。

個人的に接触確認アプリには、社会的距離をとる、手洗いをしっかりする、ふだんから体調に注意するといったこと以上の防疫効果が、まったくないと思っている。

接触確認アプリが存在しなければ、その不正利用リスクについて考える必要もない。

・・・という身も蓋もない結論になったところで、この記事はおしまい。

(アイキャッチ画像は StockSnapによるPixabayから)

PHPをWindows 10上のVisual Studio Codeを使って「Webサーバなしで」デバッグする方法

Windows 10でPHPをサーバサイド開発ではなく、VBScriptやPowerShellと同じようにローカルで実行するスクリプトとして使っている。

MicrosoftのVisual Studio Codeを使えばIntellisenseの自動補完でコーディングもできて便利だが、どうすればデバッグでステップ実行ができるのか、ネットで調べ始めた。

とりえあずXdebugというPHPの拡張機能(DLLファイル)が必要なことは分かった。

Xdebug – Debugger and Profiler Tool for PHP

ところが、Xdebugの使い方について、リモートのWebサーバやローカルにApacheかIISで構築したWebサーバでPHPを動かす前提の記事ばかりで参考にならない。

試行錯誤してようやくWebサーバなしでデバッグする方法が分かった。

すでにPHPスクリプトは実行できる状態になっているとする。

(1) XdebugのDLLのダウンロード

上記リンク先からXdebugのDLLファイルをダウンロードし、PHPのインストールフォルダ配下の「ext」フォルダ内に保存する。長いファイル名のままでいい。

ただしダウンロードするDLLファイルのバージョンを間違えないこと。

正しいバージョンをダウンロードするには、Windowsのコマンドラインで「php.exe -i」を実行、出力結果部分だけをコピーし、Xdebugの下記ページに貼り付け、「Analyse my phpinfo() output」ボタンをクリックする。

Xdebug: Support; Tailored Installation Instructions

すると正しいバージョンのダウンロードリンクが自動的に表示される。

(2) php.iniファイルの編集

php.iniファイルの冒頭に以下の内容を追記する。

zend_extension = C:\php\ext\php_xdebug-2.7.2-7.3-vc15-x86_64.dll
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_host = 127.0.0.1
xdebug.remote_port = 9000

「zend_extension」の後のDLLファイルのフルパスは、自分がダウンロードしたDLLファイルのフルパスに適宜変更すること。その他はこのままコピペすればよい。

Webサーバなしでなのに、どうしてremote_hostやremote_portの指定が必要なのかと思うが、これらの記述がないとXdebugが動いてくれないので、何も考えずに記述すること。

ここまででXdebugが正しく動くかどうかは、コマンドラインプロンプトで先ほどの「php.exe -i」を再度実行し、以下のメッセージが表示されないことを確認すればよい。

Failed loading C:\php\ext\php_xdebug-2.x.x-x.x-vc15-x86_64.dll

(3) Visual Studio Codeに拡張機能 PHP Debug をインストール

Visual Studio Codeを起動、メニューの「表示>拡張機能」をクリック。

画面左上に「Marketplace で拡張機能を検索する」という入力欄が出てくるので「PHP Debug」と入力。緑色の「インストール」ボタンをクリックする。

ついでに「PHP IntelliSense」がインストールされていなければ、「PHP IntelliSense」と入力。同様に緑色の「インストール」ボタンをクリックしてインストールする。

(4) 編集するPHPファイルのあるフォルダを Visual Studio Codeで開く

筆者はここでつまずいた。PHPファイルを編集するんだから、そのPHPファイルを開けばいいと普通は思う。

しかしXdebugでデバッグするには、PHPファイルのあるフォルダを開く必要がある

Visual Studio Codeを起動したら、メニュー「ファイル>フォルダーを開く…」をクリックする。

そして編集したいPHPファイルのあるフォルダを開いて「フォルダーの選択」ボタンをクリックする。

その後、メニュー「表示>エクスプローラー」をクリックし、左側に選択したフォルダ内のファイル一覧が出てきたらOK。

本来、Visual Studio Codeはフォルダ単位(プロジェクト単位)でPHPをコーディングするもので、PHPファイルを単体でコーディングするものではないので、ファイルではなくフォルダーを開くのが正しい。

(5) 編集したいPHPファイルを開く

左に表示されたフォルダ内のファイル一覧で、編集したいPHPファイルをクリックすると、右側のエディター部分にPHPファイルの中身が表示される。

(6) launch.json ファイルを作成する

このlaunch.jsonファイルをどうやって作成すればいいのかが、どの記事にも書かれていなかった。

メニュー「デバッグ>構成を開く」をクリックすればいい。

すると開いているフォルダ内に「.vscode」というフォルダが自動作成され、その中にlaunch.jsonファイルが自動作成される。

そして自動作成されたlaunch.jsonがエディター画面に自動的に開く。

中身はだいたい以下のようになっているはず。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

このうち後半の「Launch currently open script」の設定部分の「”port”: 9000」という行の直下に、次のような行を追加する。

"runtimeExecutable": "c:\\php\\php.exe"

runtimeExecutableというパラメータに、php.exeのフルパスを指定する。フルパスは自分の環境に合わせて正しく指定すること。

さらに、前半の「Listen for XDebug」のパラメータ設定部分をまるごと削除してしまう。

launch.jsonファイルの中身全体は以下のようになる。太字部分が追加した1行。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
            "runtimeExecutable": "c:\\php\\php.exe"
        }
    ]
}

編集したらメニュー「ファイル>保存」やCtrl + Sで保存し、このJSONファイルのタブは閉じてしまっていい。

(7) デバッグしてみる

以上で準備はととのったので、実際にデバッグしてみる。

何度も書くが、PHPファイルを単体で開くのではなく、あくまでメニュー「ファイル>フォルダを開く…」でフォルダを開くこと。

つまり左側に開いたフォルダ内のファイル一覧を表示できる状態にすること。(左上隅の書類のアイコンをクリックすると表示、非表示を切り替えられる)

そのファイル一覧からデバッグしたいPHPファイルを開く。

そして適当な場所にF9キーでブレークポイントを設定してみる。(行頭に赤丸が付く)

F5キーでデバッグ実行を開始する。(Ctrl + F5だとデバッグなしの単なる実行になる)

するとデバッグ実行の状態になり、F10やF11でステップ実行ができる。

上記で「launch.json」ファイルから「Listen for XDebug」のデバッグ構成部分を削除したのは、この構成ではステップ実行のデバッグができないため。

上記で削除しておいたので使えるデバッグ構成は「Launch currently open script」のみとなり、正しくステップ実行ができる。

ついにWebサーバなしでPHPのデバッグができるようになった。

(8) 他のフォルダにあるPHPファイルをデバッグする場合

ここまででお分かりのように、PHPファイルのあるフォルダ配下に「.vscode」というフォルダと、そのフォルダ内に上記の「launch.json」と同じ内容の「launch.json」ファイルが必要になる。

そのつど上記の手順で作成するのは面倒なので、「.vscode」フォルダごとコピペすればいい。

これでechoやログファイルへの書き出し結果を見ながらデバッグをする手間がなくなり、楽しくPHPをスクリプト言語として使える。

中国式QRコード決済について(6):「中国QRガー」にだまされないために日本の銀行系「~ペイ」を自習

中国のインターネット決済、主にスマートフォン決済の普及率の高さを手放しで称賛する人々を、5ちゃんねるから言葉を借りて「QRガー」と呼んでいるが、もしかすると日本でのモバイル決済の普及のスピードに追従できていないだけかもしれない。

「中国QRガー」の皆さんは日本に無知すぎるのか

筆者もここ数日ネットで調べて知ったのだが、メディア露出の高いLINE Pay、PayPay、楽天ペイに加えて、大手金融機関も続々スマホアプリによるQRコード決済に進出、個人間送金サービスも始めている。

下記のような日本のQRコード展開状況にまったくふれない「中国QRガー」のみなさんは、わざと無視しているのか、単に知らないだけなのかは分からない。

ただ日本におけるQRコード決済で強調したいのは、とにかくいろんなサービスが乱立し、囲い込み戦略をとっていること。

中国はアリババのアリペイ、テンセントのWeChat Payの2社が寡占している。

「中国QRガー」のみなさんはこの2社で中国全土をカバーできることをメリットだと訴求しているが、寡占状態は必ずしもメリットとは言えない。

しかもアリペイが寡占状態なのは、はもともとアリババの「タオバオ」という、楽天のようなネットモールが中国で寡占状態だった背景の流れというだけ。(ネットモールは京東という競合があるが、オンライン決済ではアリペイの寡占をまったく切り崩せていない)

WeChat Payが寡占状態なのは、もともとテンセントのQQというチャットアプリが国民的な普及率を誇るほぼ独占状態といえるアプリで、テンセントがPCメインだったQQをスマホ対応にするのと並行して、ほぼスマホ専用のWeChatへユーザを誘導したというだけ。

中国ではアリババ、テンセントというネット企業がそれぞれEコマース分野、チャットアプリを中心とするオンラインアプリケーション分野でほぼ独占状態にあったから、アリペイ、WeChat Payも寡占状態にあるだけなのだ。

そういう中国の特殊事情がなく、資本主義の正常な競争が行われている日本のQRコード決済業界について、「統一的なQRコード決済が無いのはダメだ!」的な議論は、完全に筋違いと言っていい。

「中国QRガー」のみなさんは、徹底して日本の現状や日本市場の正常な競争状態を、平気で無視するから煙たがられるのだ。

前置きが長くなったが、日本の金融機関のQRコード決済展開として以下のようなものがある。

みずほ系「Jコインペイ」

J-Coin Pay公式サイト

『スマホQR決済「Jコインペイ」、全国50以上の地銀が3月から導入へ』 (iPhone Mania 2019/02/18 13:24)

『銀行スマホ決済「Jコインペイ」で大競争時代に』 (野村総研 2019/02/18)

みずほフィナンシャル・グループが中心になって、50行以上の地方銀行が参加。参加銀行は順次増やしているようだ。

中国のAliPayとも提携し中国観光客にも対応するという、日本でありがちなスマートフォン決済導入パターンである。

このプラットフォームは個人間送金もできる。筆者は個人間送金ができるのはてっきりLINE Payだけだと思っていたが、Jコインペイもできるんじゃないか!

加盟店側手数料は2~5%程度でクレジットカード手数料を下回り、導入費用はスマホやタブレットがあればアプリをインストールするだけなので0円とのこと。

ゆうちょPay

『ゆうちょ銀行、スマホQRコード決済「ゆうちょ Pay」5月開始、口座直結で支払い』 (iPhone Mania 2019/02/07 00:31)

『なぜゆうちょ銀行がスマホ決済に参入するのか? 「ゆうちょPay」の狙いを聞く (1/2)』 (ITMedia Mobile 2019/04/11 06:00)

ゆうちょ銀行はメガバンクと比べると収益性が低いが、その優位性は言うまでもなく顧客との接点の多さ、ATMと店舗数の多さだ。

この「ゆうちょPay」のポイントはGMOペイメントゲートウェイの「銀行Pay」を利用している点だ。

SaaS型銀行間決済「銀行Pay」

GMOペイメントゲートウェイ 銀行Pay公式サイト

『地銀、ゆうちょ銀行が取り組む、銀行Payとは何か?口座連携のQRコード決済のメリット、デメリット』 (Money Lifehack 2018/10/23)

筆者も初耳だったのだが、GMO運営のこのシステムは、ユーザ向け、加盟店向けのスマートフォンアプリと、加盟金融機関の勘定系システムをインターネット経由で連携するSaaS型プラットフォームで、中国のAlipayにも連携、外部連携APIも提供している。

この銀行Payはあくまでプラットフォームであり、じっさいにサービスを提供するのはこのSaaS型サービスを利用する各金融機関となる。

ゆうちょ銀行以前に、りそなグループ、すでに横浜銀行、福岡銀行、熊本銀行、親和銀行、近畿大阪銀行、沖縄銀行、北陸銀行、北海道銀行が参加。

QRコードでの決済方式は、顧客読み取り型、店舗読み取り型、自動精算機型がそろっており、今後は自動精算機で現金の引き出しまで出来てしまうようだ。

Bank Pay (仮)

これが本命のようだが、日本の三大メガバンクが2018/05にQRコード規格の統一で合意していたようだ。

『スマホ決済、3メガ銀がQRコード規格統一で合意 地方銀行に参加促す』 (日経新聞 2018/05/22 20:04)

ただ、みずほは上記の「Jコインペイ」、GMOがSaaS型銀行間決済プラットフォーム「銀行Pay」、ゆうちょは「ゆうちょPay」をすでにサービスインしているので、この「Bank Pay」は本当に実現するのか不安。

膨大なセキュリティ投資

中国のQRコード決済、インターネット決済について、不正アクセスなどサイバー攻撃のリスクが低いのは、中国のインターネットの内部から外部への接続が強力に規制されていることが最大の理由だ。

このインターネット規制は政府が調整できるため、国外から中国内部への逆方向の接続も、通信遅延が増減するなど明らかに規制を受けている。

インターネット全体が中国全体で保護されているおかげで、中国のインターネット決済はサイバー攻撃などのセキュリティ対策にかけるリスクを大幅に抑えられるメリットを享受している。

他方、中国以外の日本を含む、国外とのインターネット接続を規制していない国は、インターネット決済プラットフォームのセキュリティ対策に莫大な投資をする必要がある。

乱立が健全なんです

結論はこれにつきる。

じっさいにLINE PayとメルPayが提携しても、LINE PayとPayPayが提携しそうにないのは、乱立する「~ペイ」がQRコード決済の普及率向上よりも、顧客囲い込みによる自社の利益を優先しているからだ。

これは自由主義の市場ではきわめて正常でまっとうで健全なことである。

かりに日本のQRコード決済が中国のように寡占状態になり、加盟企業に不利益な状況が発生すれば、日本では確実に公正取引委員会が動き出すだろう。

消費者にとって寡占の利便性と、例えば加盟店の手数料が寡占企業によって引き上げられ、価格に転嫁されることによる不利益はもちろん、どちらかを取れば他方を捨てざるを得ない関係にある。

おそらく日本の公正取引委員会は中国のような2社の寡占は許さないのではないか。

「三大メガバンク」や「三大携帯電話会社」の例からすると、全国の消費者に生活基盤にあたるサービスを提供する事業者は、少なくても3社までが許容限度ではないかと思われる。

いずれにせよ自由主義経済の健全な競争を阻害してまで、中国のような寡占状態のQRコード決済の普及を良いことのように称賛する「QRガー」がいたとすれば、遠慮なく非難してよい。

以上、「中国QRガー」のみなさんに騙されないようにするための基礎知識として、自分自身のためにもまとめておいた。

中国式QRコード決済について(5):自ら存在意義を抹殺する中国デジタル社会報告書

「QRガー」に関連して、重大な欠陥のある報告書を見つけてしまった。極めて価値のある内容であるのに、冒頭の第1章で自らその価値を台無しにするという「自殺」報告書だ。

どうして中国テクノロジーを称揚したい方々の先入観はここまで強いのか。

最初に断っておくと、筆者は10年来の中国ガジェット好きである。届いた翌日に電源が入らなくなるクオリティの中華タブレットを数枚購入したことがある。

スマートフォンは、7~8年前、Huawei製でも数時間で交換式バッテリーが切れてしまうような代物だったころから始まり、ZTE製も使ったことがある。最近は劇的にコストパフォーマンスが高くなり、ここ数年、Xiaomi、OnePlus製しか使っていない。

中国SNSはWeiboと百度貼吧を10年以上使っており、WeChat Payも現地ネット決済のために便利に利用している。

したがって中国のIT産業について普通の日本人ほど偏見は持っていないつもりだ。

問題の報告書へのリンクがある、報告書の筆者の方自身のブログ記事を貼っておく。

「報告書『中国14億人の社会実装―「軽いIoT」が創るデジタル社会』が刊行されました。」 (Aseiito.net 2019/04/09)

リンク先にある報告書『中国14億人の社会実装―「軽いIoT」が創るデジタル社会』(伊藤亜聖・高口康太)が、冒頭にあげた重大な欠陥のある報告書である。

(わが母校の東京大学も目先の利益に直結する研究に偏向し、基礎研究の質を軽視し始めたか)

あえて「重大な欠陥」と強い表現をつかった理由は、報告書全体の議論の前提となる導入部分に深刻なミスリードと統計の意図的な読み替えがあり、報告書全体の価値を台無しにしているからだ。

その重大な欠陥はp.27にある。

図表2、横軸に国レベルの一人当たりGDP、縦軸に「過去1年間に携帯電話またはインターネットを通じた金融機関口座にアクセスした人の比率」をとったチャートだ。

この図表2を元にして「先進国のほうがIT技術を利用した金融機関利用が普及してるといえる。おおむねベースラインの傾向としては、デジタルエコノミーも経済発展水準と相関するのである」

何の説明もなくインターネットを通じた金融機関利用が、デジタルエコノミーの決定要因であるとされている。あまりに乱暴な議論だ。

しかも「インターネットを通じた金融機関口座へのアクセス」にはPC、スマートフォンなど、複数の手段があるにもかかわらず、図表2で見事に「モバイルバンキングの普及比率」にすり替えられている。

論文ではない報告書とはいえひどすぎるミスリードだ。

なぜ日本が高いGDPのわりに「過去1年間に携帯電話またはインターネットを通じた金融機関口座にアクセスした人の比率」が低いのか、妥当な原因に本当に思い当たらないのだろうか。

一つは、言うまでもなく日本が異常に現金決済に執着する社会であること。それはこのブログの一つ前の記事を参照頂きたい

かつ、都市部ではATMがあらゆる場所に設置されているからだ。

あらゆる場所にATMを設置できる主な理由は治安が良いからだ。治安が良いということは、治安の悪い国よりも相対的に現金の管理コストを抑える要因にもなっている。

警察庁の平成29年版犯罪白書で、強盗の発生率(人口10万人当たり発生件数)は2014年で米国101.1、英国81.8、フランス177.9、ドイツ56.4に対し、日本は2.4。先進国の中でも異常なほど低い。窃盗の発生率も他の4か国のおおむね5分の1以下だ。

ATMが普及する前も、日本の金融機関の経営は極めて「非効率」で、支店が全国津々浦々あり、現金の出し入れができた。銀行のない地域は郵便局がカバーしていた。

ウィキペディアによれば、1970年代に金融機関がクローズドなネットワークで相互接続され、平日日中の即日送金を実現した日本は世界最先端の金融情報技術を誇っていた。

さらに街角のクレジットカード端末にATM機能が備わり、コンビニエンスストアにもATMが設置された。

コンビニエンスストアの店舗そのものが過当競争になるほど増えたため、ますます現金の出し入れが手軽になっている。通勤・通学のついでにいつでも金融機関のATM相当の現金の取扱ができる。

一方、インターネットを経由したネットバンキングやモバイルバンキングについては、不正アクセスやマルウェアによる被害を防止するため巨額のセキュリティ投資が、ユーザには見えないところで行われており、日々「進化」するサイバー攻撃に対応するコストは年々上昇している。

強盗の発生率が極めて低い日本であっても、電話やインターネットを悪用した物理的接触のない犯罪の発生率は高止まりするだろう。

日本における強盗による現金被害金額は2016年で4.0億円だが、特殊詐欺(いわゆるオレオレ詐欺)の同年の被害金額は406.3億円と100倍にのぼる。

強盗のような「体力」犯ではなく、通信網を利用する「知能」犯は、日本の物理的な治安の良さをやすやすと乗り越えてしまう。

日本でインターネットバンキングやモバイルバンキングの必要性が低いのは、こういったさまざまな社会的・文化的要素が理由になっているのであって、決して日本のデジタル化が遅れているわけではない。

これらの要素をすべて無視して、日本のデジタル化の遅れだけに言及するのは、日本でデジタル化の技術開発に取り組んでいるすべての人々に対する侮辱だ。

この報告書はさらに次の図表3にも「モバイルバンキング」というミスリードを確信犯的に持ち込んでいる。

それどころか最終的に次のように書いている。

「日本のデジタル化を議論する際に度々言及されるのは高齢化による影響であるが、比較的近い高齢化水準にあるスイスやデンマークではデジタル化が進んでいる。日本のデジタル化の遅れを人口構造のせいにできないのである」

高齢化とモバイルバンキングの普及率に相関関係がないという事実は、「高齢化しているからモバイルバンキングの普及率が低い」という因果関係を肯定も否定もしない。

図表2においても同じ誤りを犯している。日本と中国だけに注目するという恣意的なサンプリングを行いつつ、経済発展水準とデジタル化に負の相関関係があるという事実で、「経済発展水準が高いからデジタル化する」という因果関係を否定している。相関関係は因果関係を肯定も否定もしない。

相関関係は因果関係ではない。統計学の基礎さえ理解していない人は統計数値を使わない方が良い。

以上、p.29前半部分まででこの報告書の筆者にデジタル化一般について議論をするだけの正確な認識や客観的な思考能力がないことが明白になった。

これらの箇所に見られる報告書の筆者の無意識の”Japanophobia”は、p.29の後半に思わず漏れ出てしまっている。

「技術的に可能なことが、経済的・社会的な要因によって社会への導入が遅れる現象」

これは明らかに日本を指している。

日本はGDPが高いのにデジタル化が遅れていてダメ、中国はGDPが低いのにデジタル化が進んでいてすごい!という稚拙な論評に陥っている。

意図的かどうかは別として、この長い報告書の冒頭、第1章の段階で日本人の神経を逆なですることに成功している。

中国のモバイル決済賛美者の皆さんはこのようなフォーマルな報告書でさえ、モバイル決済に話をつなげるための強引なミスリードをし、わざわざ日本人の神経を逆なでするような議論の組み立てをする。

だからこそ自分で自分の首を絞めているのだが、そのことを「中国屋」のみなさんはいつになったら自覚し、改められるのだろうか。

じっさいにはこの報告書の残りの部分は非常に参考になる具体的な記述が満載である。

シャオミ大好きで、シャオミのバックパックまで中国から取り寄せて使っている筆者にとって、じっくり楽しみたい非常に充実した報告書になっている。

しかしこの報告書は第1章だけで普通の日本人読者を拒絶している。この冒頭の議論にイラっとする日本人は読まなくて良いと言わんばかりに、報告書の残りの部分の価値を自ら抹殺している。

非常にもったいない。もったいなさすぎる。

中国式QRコード決済について(4):「QRガー」のみなさんには絶望が足りない

ネット上の「中国のQRコード決済すごい!日本でも普及させるべき!」という人々は、日本のQRコード決済利用実態や現金決済主義の現実から目をそむけ、QRコード決済をまだ使っていない人々への訴求力がほぼゼロである点で、完全に空回りしており、見ものとしては面白い。

以下、このような人々を「QRガー」と呼ぶことにする。この名称はすでに5ちゃんねるで使われている

いかに「QRガー」のみなさんの努力が空回りしているか、下記リンク先の日本でのQRコード決済の実態調査で確認してみたい。IT系でおなじみ、MMD研究所のアンケート調査だ。

PayPayユーザは日本のスマホ所有者の約8.6%

「みんなが一番使っているQRコード決済、現時点でのトップはアレ!」 (GIZMODO 2019/02/06)

引用元のMMD研究所の調査はこちら。「2019年2月 QRコード決済サービスの利用に関する調査」 (MMD研究所 2019/02/05)

なお無用な反論を避けるため、このMMD研究所の調査は2019/01/08~01/10だが、PayPayの大規模キャンペーンを反映していることを別の調査で確認しておく。

「『100億円キャンペーン』はどれくらい効果があったのか? PayPayの利用動向を調査会社が発表」 (Forbes Japan 2019/04/09)

引用元のVALUESの調査はこちら。「『100億円あげちゃうキャンペーン』、その後のマーケティング効果を調査」 (VALUES 2019/04/08)

PayPayをふくむ各種決済アプリの月次ユーザ数推移はこちら。「行動ログ」が基準なのでMAUと考えてよい。

2019/02のPayPayのMAUは599万に達している。インストールベースでは2019/02時点で774万ユーザとある。

NTTドコモ系のモバイル社会研究所の調査によれば2018年の日本のスマートフォン所有率は74.3パーセントのため、スマートフォン所有者のうち約8.6パーセントがPayPayユーザとなる。

インストールユーザ数の推移はこちら。やはりPayPayは2018/12のキャンペーンで現在にいたる8割以上のユーザを獲得しており、MMDの調査期間はPayPayの急激な成長を反映していると考えてよい。

ただそのPayPayも、大きなユーザベースにもかかわらず、1日平均の1ユーザ利用回数は3回以下、キャンペーン終了後は他の決済アプリと大差なく1日平均2回前後と、利用頻度は意外に少ないことが分かる。

このように、MMDの調査は2018/12に一気にユーザベースを増やしたPayPayの急成長を反映していることを確認しておいた。

QRコード決済に消極的、無関心なスマホ所有者は8割

ではそのMMDの調査について、「スマートフォン所有者のQRコード決済サービス利用状況」から見てみよう。

先のVALUES、モバイル社会研究所の調査結果をあわせて、スマートフォン利用者のうちPayPay利用者が約8.6パーセントと計算されたので、このアンケート調査結果でPayPayを「現在利用している」割合の数値8.1パーセントは妥当と考えていい。

このチャートの重要な点は、QRコード決済に対して無関心、消極的な日本人の比率が圧倒的であることだ。

無関心、消極的な日本人の比率は、チャートの緑色と黄色を除いた部分、つまり、「利用したことはあるが、現在は利用していない」+「どんなものかわかるが、利用したことはない」+「聞いたことはあるが、内容はよく知らない」+「全く知らない」の合計だ。

これだけネットで簡単に調べものができる中で、「聞いたことはあるが、内容はよく知らない」のは積極的に調べる気がないとしていいだろう。

消極的な比率がもっとも少ないPayPayの回答者でも82.4パーセント。すべてのQRコード決済アプリで約8割のスマートフォン所有者がQRコード決済の利用に消極的、無関心である。

つぎに「QRコード決済サービスを利用する理由」を見てみる。

回答数887人のうち、QRコード決済を利用していると回答した188人に絞られてしまっている。

ポイントに関係する回答が1位、3位。ポイントは運営会社の囲い込み戦略のため、QRコード決済を社会インフラとして普及させることより、自社顧客の囲い込み優先の運営会社の狙いが反映されていると見ていいだろう。

利便性は2位、5位、6位、8位、10位など。ただしいずれもQRコード決済だけの利便性ではなく、Felica式決済にも共通する内容であり、おそらく回答者の多くはFelica式キャッシュレス決済を併用していると思われる。

「QRガー」のみなさんが、よくメリットとして強調する個人間送金は、13位の8.5パーセント。回答数全体の188×8.5%÷887=1.8パーセント。

日本の全スマートフォン所有者のうち2パーセント弱しか個人間送金を理由として挙げていない計算になる。「QRガー」の一部の方々が個人間送金のメリットを訴求している努力は空回りしているようだ。

「クレジットカードで十分」が4割

つぎは「QRコード決済サービスを利用しない理由」。こちらは母数が699人。

複数回答可で、「クレジットカードで十分だから」が43.1パーセント、2位の「現金で十分だから」が23.6パーセント。日本人が決済手段の変更について異常に保守的だと言える。

3位は決済の取引情報はユーザ別、一件別に記録されるキャッシュレス決済特有の懸念と言っていい。

クレジットカードもQRコード決済も大企業が運営しており、信用の点で大きな差はないはずだが、「クレジットカードで十分」とする人が43.1パーセントである一方、QRコード決済については、情報漏えいの不安が21.6パーセントと第3位になってしまう現実がある。

これこそ、信用にもコストがかかり、誰かがそれを負担しなければならないと筆者が言い続けている点だ。

QRコード決済を利用しない人たちは、そのコストを自分は負担したくないので、QRコード決済は使わない、何かあったときに補償があるクレジットカードで十分だと言っていることになる。「QRガー」のみなさんは常に信用にかかるコストを小さく見積もりすぎている。

意外なのは、「街中で使えるお店が少ないから」という比率が非常に小さいことだ。

「QRガー」のみなさんは使える店舗が増えれば、ネットワーク外部性で利用者も増えると考えているが、QRコード決済を利用しない人にとっては、使える店舗が増えたとしても、クレジットカードや現金の十分さをくつがえす要因になりづらいことが分かる。

以上、MMD研究所の調査結果を見てきたが、フツーの日本人の直感にもほぼ合致していると思われる。

「QRガー」のみなさんが本来やるべきこと

「QRガー」のみなさんが本来やるべきことは、日本人のクレジットカード信仰、現金信仰を「脱洗脳」することだ。

しかし「QRガー」のみなさんがいくら自身の議論の客観性や合理性を主張しても、日本社会の現状の中に置かれた途端に、QRコード決済「信者」になってしまい、両社は宗教戦争の様相を呈してしまう。

筆者がこの記事で「QRガー」のみなさんを「QRガー」とあえて蔑称しているのも、ご自身の主観性やイデオロギー性に無自覚な点を指摘したいからだ。

日本人の決済手段の変更にかんする異常な保守性は、合理性ではなく直感的なものであるため、説得方法も非合理的でなければならない。その一例がPayPayの2018/12の第一弾キャンペーンといえる。

しかしQRコード決済事業者がいっせいに同様のキャンペーンを行えば、日本では行政の指導や規制がなされ、事業者がかんたんに折れることは容易に想像できる。最近ではふるさと納税の規制の例があった。

したがって、「QRガー」のみなさんが日本でQRコード決済を共通の社会基盤として普及させるためにできることは少ない。

ご自身がQRコード決済「信者」だという自覚がなく、QRコード決済の長所を訴える方法しかとれないのでは、決済手段の変更にかんする日本人の異常な保守性を変えることはできない。

筆者がQRコード決済について少しでも否定的なことをツイートするやいなや、たちまち「FF外」からの反論が返ってくるくらいなので。

「QRガー」のみなさんには、現実に対する「絶望」が足りない。

もしもあなたがこの記事に反感を抱いたとしたら、あなたにはこの異常な保守性を変え、QRコード決済を日本の社会インフラにする能力が無いことの、何よりの証拠だ。