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

※以下、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から)

「GOVERNANCE INNOVATION: Society5.0の時代における法とアーキテクチャのリ・デザイン」報告書(案)の無意味さを東浩紀のポンチ絵一枚で無理やり説明する

問題の経産省がパブコメを募集した「GOVERNANCE INNOVATION: Society5.0の時代における法とアーキテクチャのリ・デザイン」報告書(案)はこちら。

https://search.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=595219066&Mode=0

この報告書(案)がいかに無意味かを、東浩紀『動物化するポストモダン』(昔読んだ)のポンチ絵一枚で説明してみる。

上の「近代の世界像」は、世の中のいろんな出来事はその背後にある大きな理論で説明できる、という世界像のこと。

ふつうの人はあまり意識せずこちらの世界像を持っている。

情報技術の発展にともなって社会全体の姿が変わり、それによって僕らの自身の生活も変わる(私は物語を通して決定される)的な。

世界の歴史、経済、文化、政治、技術などなどの変化を何かの理論で説明しようとする発想は、すべて上図の「近代の世界像」にあてはまる。

その発想の背後には、世界で起こるだいたいの出来事を説明できるような理論、公理のようなものがあるという、暗黙の前提がある。(宗教家にとっては神様がそれ)

そういう大きな理論のことを、ポストモダン思想家は気取って「大きな物語」と呼んでいる。

いっぽうポンチ絵の下半分、「ポストモダンの世界像」は世界全体を説明できるような理論や神様が存在するかどうかなんてどうでもいい、という世界像のことを言っている。

重要なのは、「世界全体を説明できる理論なんて無い」ではなく、「あっても無くてもどうでもいい」という点。けっして「大きな物語」を否定しているわけではない。どうでもいいのだ。

そういう「ポストモダンの世界像」に出てくる「データベース・モデル」は、IT業界でいうデータベースとは無関係で、単なる比喩だ。

上半分の「近代の世界像」では、世の中の出来事は大きな理論でだいたい説明できると見なすので、秩序立って見える。

「ポストモダンの世界像」では、世の中の出来事の背後に大きな理論があるかどうかどうでもいいので、そもそも「私」は出来事のあいだに秩序を見出す気がない。

たぶん東浩紀が「データベース・モデル」で言いたかったのは、無数にある出来事(小さな物語)には秩序がなく、「私」は欲望にまかせて好きなものをピックアップするのだ、ということ。

つまり、背後に大きな理論がある秩序立った世界だと、何かが起こると、次に起こることはだいたいいくつかの条件分岐で予測できるので、私はあたかもツリー構造、もしくはそれをタテにすれば階層構造で出来事を見ている(見させられている)。

一つの根本(大きな物語)から、いくつもの小さな物語が枝分かれしているイメージだ。

いっぽう、背後に大きな理論があろうがなかろうがどうでもいい世界だと、私の方から欲望のままに好きな物語を取り上げて、その深読みにのめりこむ。

みんながそうやって自分の好きなものを漁っている様子を横から見ていると、それぞれがランダム・アクセスしているように見える。

小さな物語というネタがずらりと並んでいるのを前に、どこからでも好きなものをピックアップしている様子を、東浩紀は「データベース・モデル」という言葉で表現したかったんだろうと思う。

たとえばリレーショナルデータベースのテーブルなら厳密な階層構造はないので、どのレコードを読みに行こうが勝手、というニュアンスで「データベース・モデル」と言えなくもない。

そして、私の方から好きなものだけとりに行き、かつ、出来事の背後に大きな理論があろうがどうでもいいので、自分の好きなようにその背後の「深層」を深読みできる。

政治的な陰謀論から、エヴァンゲリオンの解説本まで、自分の好きな出来事(小さな物語)について、勝手にその背後を深読みできる。

それぞれの人が自分の好きなネタだけピックアップして深読みをすると、偶然同じような裏読みをすることもありうる。エヴァンゲリオンのファンが深読みするうちに、いつの間にかパヨクの陰謀論と同じことを考えてたとか。

さて、ここまでくると経産省情報経済課の報告書(案)の無意味さが説明できる。

この報告書は「Society 5.0」というタイトルからすぐに分かるように、社会全体を説明できる枠組み(大きな物語)とそれに対応する法制度(ガバナンスモデル)を描き出そうとしている。

社会は「Society 1.0(?)」から、経済や技術の発達にともなって変化し、「Society 5.0」になるという、どうしようもなく古くさい進歩史観も「近代の世界像」の典型だ。

ところが、彼らは「大きな物語」を描き出そうとして、最近流行のありとあらゆるIT界隈の小道具を寄せ集めてきて、それらの小道具が相互につながることで「Society 5.0」が成立するという書き味になっている。

「Society 5.0」が本当に世界全体を裏付けるような「大きな物語」であれば、それが「サイバー空間」と「フィジカル空間」の二項対立だけで説明できるはずがない。

この報告書(案)を書いた人たちの関心は、経済格差でもなく、人口動態でもなく、環境問題でもなく、「サイバー空間」という自分たちの大好きな「小さな物語」にあった。

そこで、自分の欲望にしたがってそれだけをピックアップし、それをつかって背後にある「深層」を深読みした。その結果がこの報告書(案)だ。

つまり、この報告書(案)と、エヴァンゲリオンの解説本に、本質的な差はない。

彼らは、自分たちが「ポストモダンの世界像」の枠組みにはまっていて、自分たちの大好きなネタだけをピックアップして深読みをしているにすぎない、ということに気づいていない。

本来彼らがやりたかったことは「Society 5.0」という大きな物語を描き出すことだったのに、ゼーレが人類を補完しようとしてました、みたいな単なるマニアックな深読みになっている。

やろうとしていることと、実際に出来上がったもののギャップに、僕らは苦笑するしかない。

以上、東浩紀のポンチ絵(これ自体が正しいかどうかはどうでもいい)を使うと、「GOVERNANCE INNOVATION: Society5.0の時代における法とアーキテクチャのリ・デザイン」報告書(案)の壮大な勘違いと無意味さを、かなりうまく説明できる。

こういうふうに、世の中で起こっている出来事をうまく説明できれば、ポストモダン思想にも一定の価値はあることになる。

ただ、それってポストモダン思想も「大きな物語」を目指してるってことになり、「ポストモダンの世界像」そのものと矛盾してるんじゃないの?というツッコミはありうる。

なので、東浩紀とはちがう本物の(?)ポストモダン思想は、ジャック・デリダのように、最終的に何が言いたいのか、何のためにそんなおしゃべりを延々とやっているのか、よく分からないものになるのが「正しい」姿かも。

接尾辞の ‘-ship’ は船の意味ではない

会社員向け研修で講師がアカデミックなことをしゃべり出したら、まず真偽を疑った方がいい。

skinship, internshipなどの接尾辞 ‘-ship’ の語源が船のshipなはずがないことは直感的に分かる。まして「船が港Aから港Bへ人を運ぶことから、人と人の間や関係性を意味する接尾辞」というのは完全に誤りだ。

念のため語源辞典で調べてみる。

https://www.etymonline.com/word/-ship

意味は「品質、条件、行為、力量、技能、事務所、地位、~との関係」など。中英語の ‘-schipe’、古英語の ‘-sciepe’ 、アングル語の ‘-scip’ が語源で、これらは「状態、存在の状態」を意味し、ゲルマン祖語では ‘-skepi-‘ とある。インド・ヨーロッパ祖語までさかのぼると ‘(s)kep’ で、「切る、皮をそぐ、たたき切る」などから ‘shape’ 、つまり「形づくる、創造する」の原義を持つらしい。

一方、船の意味の ‘ship’ の語源は古英語で ‘scip’ 、ゲルマン祖語で ‘skipa-‘、いずれも最初から船、ボートの意味で、もともと「切り出された木、中が空洞になった木」。「切る、裂く」の原義があり、接頭辞 ‘schizo-‘ と同じ語源までたどれるとする説もあるようだ。

接尾辞の ‘-ship’ が「形づくる (shape)、創造する (create)」という意味で木を切る、皮をそぐ、たたき切るのに対し、船の ‘ship’ は同じ木の加工でも「切り裂く (split)」方の意味。かつて精神分裂症と訳されていた ‘schizophrenia’ (統合失調症)の接頭辞 ‘schizo-‘ につながるのはうなずける。

https://www.etymonline.com/word/ship

つまり接尾辞の ‘-ship’ と船の ‘ship’ は無関係どころか、ほぼ反対の原義をもつことになる。

接尾辞の ‘-ship’ は何かを創り出す条件や性質のこと、たとえば leadership なら leader を leader たらしめる条件や性質、sportsmanship なら sportsman を sportsman たらしめる条件や性質を意味していると考えると、なるほどと思える。

高校時代にハイデガーを読んで、やたらと言葉の語源にこだわる。そんな会社員が日本にそう多くないことは分かっているし、いちいちそんな会社員がいることを前提に講師が話す必要もないと思う。

ただ、会社員向けの研修を受けていると、講師が無理をしてアカデミックなことを話して墓穴を掘る場面に出くわし、聴いているこちらが気まずくなることがままあり、悲しい。

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ガー」のみなさんに騙されないようにするための基礎知識として、自分自身のためにもまとめておいた。