スマホアプリ有料化で直面する「D.U.N.S番号1.5万円の壁」と、そのスカッとする解決策（と儚い夢）

スマホアプリを開発していて、いざ有料化しようとすると突然目の前に立ちはだかる謎の存在「D.U.N.S（ダンズ）番号」。

調べてみると、どうやら9桁の識別番号らしく、アプリストアで有料販売を行う開発者（法人等）の身元確認などで必要になるらしい。

「よし、じゃあ取得するか」と思って日本の取扱元である東京商工リサーチ（以下TSR）のサイトを見てみたのですが……ここで猛烈な違和感に襲われました。

なんなんですか、このD.U.N.Sってのは。

そもそもD.U.N.Sとは何なのか調べてみると、アメリカのD&B（Dun & Bradstreet）という会社が1800年代から世界中の企業に勝手に（！）独自に番号をつけてデータベース化していたのが始まりとのこと。それが便利だということで米国政府やGoogle、Appleなどが使うようになり、巡り巡って世界標準の価値を持つようになったらしい。そして日本ではTSRが独占的にD&Bと契約しているそうです（ここは後で知りました）。

で、TSRのサイトによる説明をまとめるとこうです。

• 発番（新規作成）：勝手に自動的に行われている。未発番なら発番する。もちろん無料。
• 番号の検索・確認：1.5ヶ月待つなら無料。すぐに検索したいなら1.5万円。

……えっ？ 自社の番号を「検索」するだけで1.5万円？？？（あるいは1.5ヶ月放置？？？）

発番自体は無料なのに、検索に1.5万円かかる仕組み。この独特な価格設定に、思わず口がぽかんと空いてしまいました。

「Apple経由で無料検索」という裏技

さらに調べを進めると、「Apple ID（無料）さえ持っていれば、Appleの開発者向けページからD.U.N.S番号を無料で検索・申請できる」との情報が。1.5万円を節約できるという意味ではありがたい裏技です。

私も10年以上前にiPhone 5を使っていた頃、Apple IDを作った気がするのですが……もうIDもパスワードも覚えていないし、記録も残っていません。

ここでふと、根本的な疑問が湧いてきました。

「いや、番号を検索するためだけにApple IDを作る（思い出す）のって、どうなの？」

1.5万円を節約するための裏技としては知っておいて損はないですが、そもそも自社の番号をただ確認する程度の手続きに、なぜ別サービスの裏技を経由させられないといけないのか。正攻法はないのか？

正面入り口から突撃してみた

裏道を通るのがどうにもモヤモヤした私は考えました。

「もうストレートに本家D&Bのサイトに行けば、普通に検索できるんじゃないの？」

というわけで、日本の代理店でも他社の裏ルートでもなく、米国D&Bの正面入り口（UPIK検索ページ）へ直接突撃してみることにしました。

▼正面入り口はこちら

https://www.dnb.com/de-de/upik-en.html

使い方は驚くほどシンプルでした。

1. 「Search here...」と書かれた検索窓に、自社の英語社名を入力する（前方一致で検索されるようです）。
2. 国欄で「Japan」を選択してSearchボタンを押す。
3. 同名企業がいくつか表示されるので、住所を見て自社を特定する。

……あっさり見つかりました。

1.5万円払う必要も、1.5ヶ月指をくわえて待つ必要も、わざわざApple IDを掘り返す必要すらありませんでした。英語の検索窓に社名を入れるだけ。一瞬です。

……これ、知らない人めちゃくちゃ多いんじゃないでしょうか。知らずに1.5万円払っちゃってる人、相当いるのでは……？

500円くらいでサービス化できるのでは！？

ここで私の頭の中に、ひとつのビジネスアイデアが舞い降りました。

「日本の国税庁法人番号公表サイトから英語社名データを自動取得して、このD&Bサイトの検索と連携させれば……日本語で社名を入れるだけで一発でD.U.N.S番号が検索できるWebツールが作れるのでは？」

• TSRで即時検索：1.5万円（または1.5ヶ月待ち）
• 自作ツール：500円で即時検索

「これなら1.5万も払いたくない開発者や事業者に喜ばれるし、ワンコインビジネスとして成立するぞ！」

大興奮のまま、さっそく実装に向けてAIに相談してみることにしました。

結末：冷や水をぶっかけられる

私「こういう仕組みで有料の検索代行サービスを作りたいんだけど、どう思う？」

AI「結論から言うと、D&Bの利用規約違反です。スクレイピングや再配布にあたり、損害賠償を求められるリスクが極めて高いため、開発のお手伝いはできません。」

……秒で終戦。 AIからの超絶ドライかつ正論すぎる回答により、私の500円ビジネスの夢は一瞬で泡となって消えました。

おわりに

というわけで、「D.U.N.S番号の検索に1.5万円かかる問題」は、「本家D&Bのサイトから正攻法で探せばタダで一瞬」という拍子抜けな結論で解決しました。

もしこれからアプリの有料化や法人登録などでD.U.N.S番号が必要になり、「1.5万円かぁ…」「1.5ヶ月待ちかぁ…」と頭を抱えている方がいたら、ぜひ本家サイトの検索窓を試してみてください。

そして、間違っても「これを自動化して500円でサービス化しよう」などとは考えないことを強くおすすめします（笑）。

連日の個人情報流出報道から考える、パスワード管理の基本原則

連日、企業の個人情報流出に関するニュースが後を絶ちません。本日は、某ソフトウェア会社と電子書籍会社におけるインシデントが報じられています。

どのようなセキュリティ対策が講じられていたのか、どこに不備があったのかを外部から責めるのは容易ですが、現実のサイバーセキュリティにおいては攻撃側が常に優位であり、侵入経路の是非についてここで論じることはしません。また、各事業においてどのような個人情報をどの範囲で保持すべきかも、事業特性によって異なるためここでは割愛します。

しかし、「パスワードの扱い」に関しては別です。

報道によれば、某ソフトウェア会社では「暗号化されていないパスワードが流出」したとされています。セキュリティの観点から言えば、システム側がパスワードの文字列自体を保持せず、ハッシュ値のみを保持することは基本中の基本です。

認証の仕組みを振り返ると、ユーザーが入力したパスワードをハッシュ値に変換し、あらかじめデータベースに保持しているハッシュ値と比較して一致を確認するのが鉄則です。この実装が正しく行われていれば、仮にデータベースが不正アクセスを受けたとしても、パスワード自体がそのまま外部に流出することは防げるはずです。

平文、または可逆的な状態でパスワードを保持し続ける実装は、現代のWebサービスにおいてリスクがあまりにも大きすぎます。基本に忠実な実装と管理が求められます。

とりわけセキュリティ対策ソフトの開発・販売も手がける企業であれば、ユーザーが寄せる信頼の前提には「自社のシステム基盤においても高度なセキュリティ水準が保たれているはずだ」という強い期待があります。そうした企業において基本的な実装の欠落が疑われるような事態が生じれば、「この程度の実装をしているようでは……」と受け取られても仕方がなく、製品やブランドそのものの信頼性まで大きく揺らぎかねません。残念ですね。

AIと手を組んで「地域の電子回覧板」Webサービスを開発した話

はじめに：単体アプリから、憧れの「Webサービス開発」へ

もともと単体アプリだけでなく、いつかは自分の手でWebシステム／Webサービスを開発してみたいという想いがありました。

最近になってLinuxやDockerの便利さを知り、さらにAI技術の進歩によって「プログラミングを仕事にしていない人でも、アイデアを形にできる時代が来たのでは」と感じるようになりました。

最初は自分用のデスクトップアプリをいくつか作成して試していたのですが、ふとAI（チャット）に「Webシステムサービスを作れますか？」と尋ねてみたところ、「むしろWebシステムの方が得意です」 と言わんばかりの自信満々な回答が返ってきたのです。

この一言に背中を押され、本格的なWebサービス開発へ足を踏み出すことにしました。

開発環境：Windows PCを1台つぶしてLinux化

本格的な開発に入るにあたり、まずは環境構築からスタートしました。

サーバーとして運用していたWindows PCを1台思い切ってつぶし、OSにLinuxをインストール。さらにそこにClaudeを環境として組み込み、メインで使っているWindowsノートPCからSSHでリモート接続して開発できる体制を整えました。

手元の端末からSSH越しにAIと対話しながらサーバー上でシステムを組み上げていくスタイルは、それだけでもワクワクするものがありました。

開発スタイル：コードを書くのではなく、「やりたいこと」を伝える

私が「こんな電子回覧板を作りたい」と要望を伝えると、AIがそれをしっかりと要件定義として取りまとめてくれます。しかも、自分では気づけなかった仕様の抜け漏れや矛盾についても、AI側から「この場合どうしますか？」と適切な質問を投げかけて気づかせてくれるのです。

開発の具体的な流れはこのような形でした：

1. やりたいこと・機能をAIに伝える

2. AIが整理した仕様とコードを生成する

3. できあがったプロトタイプを動かして評価する

4. 気に食わない部分や修正点を指摘する

5. AIが即座に修正・改善する

このループを繰り返すだけで、見る見るうちにシステムが形になっていきました。

疲れを知らない「最強の相棒」

どれだけ仕様変更を頼んでも、何十回コードを書き直させても、AIは一切の不平不満も言わず、疲れることもなく瞬時に対応してくれます。

しかし、その一方で人間側の集中力や体力には限界があります。「AIは24時間フルスロットルで付き合ってくれるのに、こちら側の体力が持たない」という、新しい時代ならではの疲労感を味わうことになりました。

わずか3日でプロトタイプが完成。初めてスマホに通知が飛んだ感動

驚くべきことに、AIと二人三脚で開発を進めた結果、システムそのものはわずか3日程度でほぼ完成形になってしまいました。

実際にコードが動き、自分のスマホに初めてプッシュ通知が飛んできた瞬間は、思わず「おぉ……！」と声を上げてしまうほどの感動がありました。頭の中のアイデアが、目の前のデジタル空間で現実のサービスとして動き出した瞬間でした。

VPSへの移行と、AIと議論したセキュリティ対策

プロトタイプが動いたあとは、本番リリースに向けた「守りの開発」です。

1. インフラの移管（VPSの導入）

   PCをそのままサーバーとして使っていたのでは、ハードウェアの故障や停電の際にサービスが止まってしまいます。安定稼働させるためVPSを契約し環境を移行しました(もちろんAIが。私は指示するだけです)。

2. 堅牢なセキュリティ対策と「暗号化」の議論

   今回は「個人情報を極力扱わない設計」にしていましたが、だからといってセキュリティ対策を怠ってよいわけがありません。

   SQLインジェクションやXSS、CSRFといった基本的な脆弱性対策については、こちらから言わなくてもAIが最初からコードに対策を組み込んでくれていたため、人間側は「正しく実装されているか」の確認がメインで済みました。

   一方で、データの暗号化についてはAIと少し意見が分かれました。「VPS内のデータを暗号化したほうがよいのでは？」と主張する私に対し、要件を確認しつつ慎重に進めようとするAI。AIいわく、「暗号化しても鍵がサーバーにあれば、金庫のドアに鍵を貼り付けておくようなもので意味がない」とのこと。ごもっともな意見です。

   最終的には「鍵はVPS外に安全に保存し、OS再起動などによるサービス停止時には自動で鍵を使ってデータ接続を復旧させてからサービスを再起動する」という仕組みを、AIと相談しながら構築しました。

振り返って：開発の常識がガラリと変わった

ほんの数年前までであれば、今回のようなシステムを作ろうと思ったらベンダーの担当者と打ち合わせを重ね、開発、レビュー、修正というプロセスを何度も繰り返していたはずです。

要件定義漏れが発生すれば大きな手戻りとなり、それにかかる金銭的・時間的なコストもバカになりません。おそらく外部に発注すれば数十万〜100万円ほどの費用と、1ヶ月単位の時間がかかっていたことでしょう。

それが今や、AIと対話し、的確な質問を受けながら要件を詰め、修正を繰り返し、わずか数日でプロトタイプから本番環境の構築まで辿り着ける時代になりました。

ただ、実際にやってみて感じたのは「Linuxの基礎知識は少し学んでおいた方が良い」ということです。AI（CLIツール等）との親和性の高さはもちろん、VPSを借りて運用する際の価格性能比（コスパ）を考えると、Windows ServerよりもLinuxを扱えるアドバンテージは絶大です。

もちろん、セキュリティや運用の責任は開発者自身にありますが、「アイデアを即座に形にして世に出せる」という圧倒的なスピード感とアクセシビリティは、誰にとっても本当に素晴らしい武器になると実感しました。極論すればシステム開発の民主化です。これまではプログラマ―を擁するベンダーの独占でしたが、これからは非ベンダーでも自社で開発できます。

もし「作ってみたいサービスがあるけれど、ハードルを感じている」という方がいたら、ぜひAIを最高の相棒にして一歩を踏み出してみてはいかがでしょうか。

Dockerが面白い

ここ1ヶ月ほど、Linuxに熱中しています。

だいたい10年に1回くらいの周期で「Linux熱」がやってくるのですが、これまでは「Windowsの代わり（デスクトップ用途）にするにはまだ早いかな……」という結論に至り、いつの間にか熱が冷めるのがお決まりのパターンでした。

しかし、今回は少し違います。きっかけは「Pleasanter（プリザンター）をLinuxで動かしてみたい」という、サーバー用途での興味でした。

Dockerとの出会いで変わったLinux体験

実際にやってみて驚いたのが、Dockerの便利さです。 Docker Engineさえ入れてしまえば、環境構築が驚くほどスムーズ。Windows版よりもずっと簡単に構築できました。

Dockerの何が良いかというと、「本体の環境を汚さない」「コンテナは使い捨て。再構築も簡単」という点に尽きます。この手軽さに魅了され、今ではいろいろなツールを試しています。

• Nextcloud（オンラインストレージ・予定表・オンライン会議）

• WordPress（ブログ・サイト作成）

• Minecraft（統合版）サーバー

今回は、その中でもネット上に意外と情報が少なかった「Minecraft 統合版（Bedrock）サーバー」の構築手順をメモとして残しておきます。特に設定ファイルの扱い（手順1）で迷っている方の参考になれば幸いです。

---

Docker ComposeによるMinecraftサーバー構築手順

0. 前提条件

• インターネットに接続されていること

• Docker Engine / Docker Compose がインストール済みであること

• プロジェクトディレクトリ（例：minecraft）が作成済みで、そこを作業ディレクトリとしていること

1. 各種設定ファイルの用意

カレントディレクトリに、データ保存用の bedrock ディレクトリを作成します。アローリストや権限設定を行う場合は、あらかじめファイルを用意して配置しておくのがスムーズです。（server.propertyの内容は後で作業します）

1. bedrock ディレクトリを作成

2. その中に allowlist.json および permissions.json を作成して配置

2. compose.yml の作成

以下の内容で compose.yml を作成します。 environment セクションのコメントアウトを外すことで、server.property同様、サーバー名やゲームモードなどの詳細設定を反映できます。

参考記事：

Minecraft Bedrock Server を Docker で構築する（Official）

 

services:
  bedrock:
    container_name: mc_bedrock # なんでもよい
    image: itzg/minecraft-bedrock-server
    tty: true         # ターミナルの割り当て（-t オプション）
    stdin_open: true  # 標準入出力ストリーム（-i オプション）
    environment:
      SERVER_NAME: "Bedrock Server" # なんでもよい
      # 詳細設定が必要な場合は以下のコメントを解除して編集
      #GAMEMODE: "SURVIVAL"
　　　#FORCE_GAMEMODE: "TRUE" # 基本的にTRUEで
      #DIFFICULTY: "EASY"
      #ALLOW_CHEATS: "FALSE"
      #MAX_PLAYERS: 10
      #ALLOW_LIST: "FALSE" #まずはFALSEで動作確認
      #SERVER_PORT: "19132" #変更したい場合は下のports:で変更するためここは変更しない
      #ENABLE_LAN_VISIBILITY: "TRUE"
      #VIEW_DISTANCE: 12
      #TICK_DISTANCE: 4
      #PLAYER_IDLE_TIMEOUT: 30
      #MAX_THREADS: 8
      LEVEL_NAME: "lv1"
      EULA: "TRUE"    # 利用規約への同意。かならずTRUEで
      VERSION: "LATEST"
    ports:
      - 19132:19132/udp # ポート番号を変更したい場合は前の番号を変更
    volumes:
      - ./bedrock:/data
      - /etc/timezone:/etc/timezone:ro
    restart: unless-stopped #alwaysでも良い。お好みで。

構築を終えて

あとは docker compose up -d を実行するだけ。 サーバーがこれほど簡単に立ち上がるのはDockerならではの面白さですね。次は何をコンテナ化してみようかと、今回のLinux熱は当分冷めそうにありません。

マイナンバーカードを用いた運転免許証更新のオンライン講習を受講しました

先日、運転免許証更新時のオンライン講習を受けました。
その結果、交付当日の免許センターでは、

	これまで	今回
何時に行くか	朝イチ	15:30
所用時間	ほぼAMいっぱい	20分くらい

と劇的なユーザー体験をしました。

免許更新手続きは、申請書記入→証紙購入→視力検査→講習→免許証交付という流れですが（運用では視力検査を証紙購入より先にしているみたいですが）、このうち、講習を好きな場所で好きな時間にオンラインでできるというものです。

マイナンバーカードをスマホで読み取る必要があります。
スマホとMNCの位置関係が非常にシビアなのが難点ですが、試行錯誤すればなんとかなります。
時間にして約30分（優良の場合）ですが、途中に自分の顔写真の撮影タイムがあり、カラ視聴を抑止しているようです（免許証交付手続きの際に旧免許証の顔写真と照合しているようです）

現地講習は講習時間が決まっています。
ある時間帯の講習が埋まっていたら次の時間帯の講習まで待たねばなりません。
それを踏まえて即日交付を希望するなら14:00までに受付を終えておくことになっています。
いつもは朝イチで行って終わったら昼でした。半日仕事です。

今回は15:30に行きました。ガラガラに空いていました。

北海道・千葉県・京都府・山口県でモデル事業としての取組みですが、早く全国に広がるといいですね。

Pleasanterがすごいかも

1年半ぶりくらいにブログ書きます。なかなか時間が取れず・・・。

地方自治体のDXに関わっていますが、結構、情報共有・集約にExcelを用いているがうまくいっていないというケースがあります。例えば、

• 出先機関からExcelファイルをメールで送ってもらい、本庁で手作業でコピペしているが、出先機関の数が多くて面倒
• 共有ファイルサーバにExcelファイルを置き、職員に入力してもらうが、同時編集できないため待ちが発生している

というものなどです。前者はメール提出ではなくファイルサーバに置いてもらい、マクロなりRPAで集約するという方法もありますが、後者とあわせて考えると、そもそも「Excelで管理」がどうなのよ？というところです。Excelは表計算ソフトであり、本質的にDBではありません。｢できなくはない｣程度のものを主機能のように使用しているので、不便なのは当然なのです。Excelが機能不足なのではありません。

したがって、データベースを使用すべきであり、利用者にブラウザでアクセスしてもらうということを考えることになります。

このような場合、有名なのはサイボウズ株式会社様のkintone（キントーン）です。インターネットだけではなく、官公庁が使用しているネットワーク（LGWAN）内でもサービスとして利用できます。構築も比較的簡単です。マクロどころかExcelの関数より簡単かもというレベルです。

さて・・・最近、このノーコード・ローコード業界で、株式会社インプリム様のPleasanterというツールが存在感を増しているようです。弊社もデモ環境を試用させていただきましたが、あまりにも感動したので試用期間開始後まもなく契約してしまいました（後述と矛盾しますが、別要件でクラウド版が必要だったためです）。

特徴としては・・・

• アプリ構築が簡単（かつ、複雑な作り込みも可能）
• ユーザ単位課金ではない（スタンダードプラン除く）ため、規模が大きいほど費用対効果が高い
• 機能に制限はあるものの、3ユーザまでなら無料、10ユーザまでなら月1000円のプランもあり、小規模企業にも優しい
• オンプレミスでも構築可能で、サポート不要なら、ほぼ無制限かつ永久無料
• 有償サポに加入すると開発キットが提供され、改造して自社製品として販売可能みたい（一部ベンダーはやってるみたいですね）
• 有償サポは年180,000～と、この手のものとしては格安

この中で重要なのが、オンプレミスで構築可能（なんなら無料で）という部分です。WebサーバやSQLサーバーも構築する必要がありますが、行政機関内のみに閉じたシステムにすることが可能です。当然、インターネット側に構築して施設予約システムに使用したり、ということもできます。

セッアップマニュアルが充実しているので、オンプレミス構築はそれほど難しくはありません。弊社も試しにノートPC・ミニPCに構築してみましたが、きちんと動きました。

もしかしら、kintoneに代わってデファクトスタンダードになるかもしれませんね。

役所のDXを考えたい（第4回「マイナポイント」）

皆様は公的分野のデジタル化についてはどう捉えていますでしょうか。
「デジタル化が遅れてる」「そもそも非効率的」
というイメージ・経験をお持ちかもしれません。

この連載では、私が役所生活で経験したことのうち、特にデジタル化を阻む要因と感じたものを取り上げていきます。これにより、
「なぜそうなのか」「ではどうしたらよいのか or 難しいのか」
について、皆様の理解を深めていただく一助になれば幸いです。

第4回の今回は「マイナポイント」です。

マイナポイントとは

R4.6.30からマイナポイント2弾が開始されました。
マイナポイントとは、マイナンバーカードを作り所定の手続（長いので省きます）をした方が、最大2万円分のキャッシュレス決済のポイントがもらえるというものです。
当初は「R3.3末までにカードを申込み、かつ、R3.9末までに所定手続を済ませることで、最大5,000円分のポイントが貰える」（その後、4月末まで申込、12月まで手続きに変更）というものでした（第1弾）。
しかし、思ったより発行枚数が伸びずさらなるテコ入れとして、上記の期限を撤廃し、かつ、ポイント対象となる手続を増やして合計最大20,000円分のポイントが貰えるようになったものです。

カード交付の裏側

長いので結論を先に書くと、マイナンバーカード導入により、住民登録の現場の業務はかなり増えました。

あまり知られていませんが、カードはJ-LIS（地方公共団体情報システム機構）で作成され、各市町村に送られてきます（市町村では作成していません）。

受取ると、カード1枚ごとに該当者を端末で検索し、カードが役所に届いたことをカードとサーバに記録します（他にもありますが省略。なお、この処理、一頃よりは早くなったそうですが書込み命令を出してから1分以上かかります）。

そして、カード受取案内ハガキを発送します。市民が受取に来た際に迅速に出せるよう保管用IDをカード収納ケースとハガキに記載する必要があります。
カード自体を発送する場合もありますが、その場合はさらに暗証番号書き込みの処理が別途必要です（また検索から）。この辺のフローの違いは省略します。

市民がカード受取に来庁されると、カードを取り出してきて、端末で検索（カード作成時点と住所・氏名に変動がないか確認とか、再交付有無とかいろいろ確認することはあります）、カードに暗証番号を設定してもらい、カードとサーバに交付状態であることを記録して終了です。

交付した後も、住所変更や婚姻・離婚等のたびにカードの変更（裏書もＩＣチップ内も）もあります。電子証明書の有効期限切れによる更新業務もあります。もちろん、マイナンバーカード普及前は一切なかった事務です。減った事務はありません。
カードを使った市外転入の入力処理は楽になりましたが、カードの住所変更処理の方が長くかかるのでトータルで減ったフローはありません。

カード普及の目的

前述のとおり、住民登録の現場についてはカード普及につれ行政コストは上昇傾向にあります。
したがって、その分、他の行政部門をスリム化し国全体でプラス効果を産み出す必要がありますが、カード普及と行政の効率化はどのように結びつくのでしょうか。
ここでは、マイナンバー付番による行成効率化と、カード普及によるそれは分けて論じる必要があります。前者だけならカードを普及させる理由にならないからです。

マイナンバー制度の目的は、税・防災・社会保障ですが、いずれも本人同一性確認でしょう。「必要な人に必要な支援を届けるため」という言い方もあるようですが、所得隠しの防止、市町村を跨いでの給付金二重受取の防止、所得がなくても資産がある人には適正負担を求めるなど、「必要のない人に過度な支援をしない」という面の方が大きそうな気もします（今のところ完全には実現はしていませんが、目指すのはそこでしょう）。財源には限りがありますから、後者は前者の手段とも言えるわけで、全くの筋違いというわけでもありません。ただ、これはDBにマイナンバーが付番されていればできるハナシです。カード普及とは特に関係ありません。

では、どうしてもマイナンバーカードでなければならないシーンは何でしょうか。それは電子証明書の格納媒体としての役割です。大雑把にいうと厳格な本人（意思）確認とオンライン手続の両立です。

オンライン申請が普及すると市民は窓口に行く必要がありません（行政は対面対応が不要となります）。また正しくUI設計すれば手書き申請に比して正確な情報を入力させることができ、事後チェックがスムーズになります。住民対応コストが減少し、それにより余ったリソースをオンライン手続ができない情報弱者と呼ばれる方たちへの支援に回すことが可能になります。

つまり、オンライン申請の普及は、できない人にとっても望ましいものであリ、これこそがマイナンバーカード普及の目的であるべきです。

オンライン申請を装った窓口申請？

他の回でも触れましたが、マイナンバーカードはデジタル社会のパスポートたるべき存在であり、社会全体に恩恵を齎す可能性を秘めていることから普及を図るべきです。
本来は利用シーンを増やすことでカード自体の魅力を高めることが肝要なことは言うまでもありませんが、将来的なコストパフォーマンスが見込めないから利用手続きが増えない（予算がつかない）、利用手続きが増えないから便利にならずカードが普及しない、の堂々巡りを断ち切るため、一時的にマイナポイントのような経済的インセンティブによる普及策を採るのは已むを得ないかな・・・と思っています（5,000円でダメなら20,000円、には驚きましたが、驚かせるくらいじゃないと効果は薄い、と判断したのでしょう）。

そのマイナポイント申込ですが、先日、私が住んでいる札幌市から画像のようなLINEが来ました。
マイナポイント手続の急増によりJ-LISのシステムが動かなくなり、全国の役所のマイナポイント申込窓口で対応できなくなった件です。
J-LISのシステムの弱さについては報道されてない部分も含め度々現場で見てきましたが、今回、論じたいのは申込窓口の件です。

マイナポイントの申込手続はすべてオンラインで行う必要がありますが、自力でできない方でも安心してカードを取得してもらえるよう、国が自治体に支援窓口の設置を指導しました。
市町村は民間業者等に委託し窓口を設置し、業者は窓口で市民の申込支援を行います。
国から補助金（たぶん100%）が出るので、わざわざ節約して自前でやるところはないでしょう。地域経済のためにも。
支援内容ですが、

• サイトへのアクセス
• カードの読込（スマホまたはPC）
• ポイントを付ける決済サービスの（画面上の）申込処理

などのいずれか、あるいは全部（結構いると思います）を行っているのでしょう。支援というより一部手続代行に近いのが実態かもしれません。
（暗証番号入力はさすがに自分でやってもらってるでしょうが）

さて、カード普及の目的は、オンライン申請の普及により社会全体を良くするためであるべき、という話をしました。
また、マイナポイントについては、カード普及のためにやむを得ない旨も述べました。
つまり、マイナポイントの目的は「（カード普及を通じて将来的に）オンライン申請の普及により社会全体を良くするため」であるべきです。
「オンライン申請用の窓口を設け、そこで（本人ではなく）担当者が処理をする」は、オンライン申請を装った窓口申請で意味がありません。

政府はデジタル化に「誰も取り残さない」としています。できない人に不利益があってはいけません。ですから、誰もがデジタル化についていくための機会を提供することが重要です（機会平等）。デジタルスキルが平等（結果平等）である必要はありません（無理です。そんなスキル要らない、という方も一定数残るでしょうし）。
「できる人はよりお得に、できない人はそれなりに」で構わないのです。

したがって、支援窓口は「申請の仕方を教室のように教える」ものであるべきです。
膨大な費用をかけてカード普及率は上がったとしても、オンライン申請のやり方を聞くため（というよりオンライン申請を代行してもらうため）に窓口に来庁するような人を増やしてどうするのでしょうか。それって行政コストは下がらないですし、自力不可だった市民自体も全然便利になってませんよね。

時々、レジで今使う分だけチャージしその電子マネーで払う人を見ます。
んなコトするくらいなら現金で払え、とレジ担当者も後ろに並んでいる人も思ってるでしょうね。いや、本来、これはレジでチャージ可能なのが間違っており、レジに並ぶ前に自力でチャージできる手段を用意せねばなりませんし（できればオンライン）、それができない人は諦めてもらうべきです（単に「わからないモノには手をだすな」です）。それと同じことです。

この点、税務署は（良くも悪くも）すごいですね。確定申告時期、税務署の周りに車がどれだけ渋滞し階段にどれだけ行列ができようがお構いなしです。「自宅でe-Taxでやれ」「出来ない人は並べ。e-Taxが普及すれば行列も減るハズだから」という思想なのでしょう。おそらく国の「署」だからできることであって市町村の「所」だとクレーム多数で無理な気もします。
結局のところ、DXを阻むものは日本人の意識なのかもしれません。