【2026年最新】マイナンバーカードはスマホのみで生活できる?できること・できないこと・おすすめ運用法

マイナンバーカードや免許証をスマホにまとめて、カードを一切持ち歩かない『完全カードレス生活』にしたい!

そう考える方が増えていますが、結論から言えば、現時点で「完全カードレス」はまだできません。

しかし、「日常の買い物やカフェなどの外出はスマホ1台で済ませ、実物カードは自宅に置いておく」という運用は十分に可能なレベルまで進んでいます。

今回は、マイナンバーカードのスマホ搭載でできること・できないことと、今ベストな持ち歩き・運用スタイルを分かりやすく解説します!

 

🧑🏻‍💻 スマホだけでできること/できないこと一覧

まずは、シーンごとの対応状況をチェックしてみましょう。


💡 ここに注意!
「スマホで免許証提示」はまだできません マイナンバーカードと運転免許証の一体化(マイナ免許証)はスタートしていますが、

スマホ画面を警察官等に見せて運転免許証の代わりにする機能(モバイル免許証)はまだ未対応

です。

スマホにマイナンバーカード機能を登録していても、運転時に物理カード(マイナ免許証または従来の運転免許証)を携帯していないと「免許不携帯」になってしまうので注意しましょう

 

🧑🏻‍💻 現状のベストな持ち歩き・運用スタイル

「完全カードレス」が無理だからといって、毎日重いカード類を持ち歩く必要はありません。おすすめの運用方法は以下の通りです。

📱 普段の外出(電車移動、買い出し、カフェなど)

・ 持ち物:スマホのみ
・ 運用のコツ: スマホに電子証明書を登録しておけば、マイナンバーカード本体は自宅の金庫や引き出しに保管しておいて問題ありません。持ち歩かないことで、紛失・盗難リスクを最小限に抑えられます。

🏥 病院にかかる時・役所の窓口・車を運転する時

・ 持ち物:実物のマイナカード(または運転免許証)を鞄に入れて持参
・ 運用のコツ: スマホ保険証非対応の病院や、機器トラブル・システム障害が発生した際に備えて、必要な時だけ実物カードを持ち出すのが一番安心です。もちろん、車を運転する際はカードの所持が必須となります。

 

🧑🏻‍💻 まとめ:上手に使い分けて紛失リスクを減らそう!

現時点では「スマホ1台あればカード類は全部捨ててOK」とはいきません。

しかし、普段の生活ではスマホだけを持ち歩き、カード現物は自宅で保管するという運用をするだけでも、カード紛失のリスクを大幅に減らすことができます。

スマホへの登録自体は数分で完了しますので、まだ設定していない方はぜひ試してみてくださいね!


PHP2Shell で騒ぐ前に知っておくべきこと:「PHPのバージョンを上げれば終わり」ができない現場の構造的欠陥

最近、「PHP2Shell」と呼ばれる深刻な脆弱性が話題になり、SNSやセキュリティ関連のニュースで大きく取り上げられています。

これに対して「何をそんなに大騒ぎしているのか? PHPのバージョンを安全な版にアップデートすれば終わる話ではないのか?」と感じた人も多いのではないでしょうか。

結論から言えば、その通りです。

技術的な解決策としては「修正されたバージョンに上げる」のが唯一かつ完全な正解です。しかし、それでもこれほどの大騒ぎになっているのは、「バージョンを上げることすらできないレガシーシステムが、世の中に大量に放置されているから」に他なりません。

この記事では、なぜ「バージョンアップ」という当たり前の対応ができないのか、そしてその裏にある現場の構造的な課題について整理します。

 

🤔 なぜ「PHPのバージョンアップ」で終わらないのか?

今回の脆弱性は、PHP 5.4から8.5という非常に広い範囲に影響を与えます。そして、ここが最大のネックなのですが、すでにサポートが終了(EOL)しているPHP 8.1以前のバージョンには、公式からのパッチが提供されません。

つまり、古いPHPを使っている環境は「修正版の8.2以降」へ一気にジャンプアップ(メジャー/マイナーバージョンアップ)する必要があります。

しかし、古いPHPで動いているシステムをそのまま最新のPHP 8.2/8.3に持っていくと、以下のような問題が確実に発生します。

・ 非推奨(Deprecated)機能・廃止関数の影響で画面が真っ白になる
・ 古いフレームワークやWordPressプラグインが動作しなくなる
・ データベースの接続ドライバや仕様変更に伴う挙動不審

結果として、「ただPHPのバイナリを差し替える」だけでは済まず、アプリケーションコードの大規模な改修と全機能の再テストが必要になります。

 

🤔 バージョンアップできないシステムは、ただの「延命」である

「コードを直せばいいじゃないか」と思うかもしれませんが、現場ではそれができません。

・ 仕様書がなく、当時の開発者もいない(誰も全体像を把握していない)
・「現状動いているから触るな」という経営陣・決裁者の圧力
・ 売上を生み出さない基盤改修に予算が出ない

このようにして、「修正費用が出せないから」「壊れるのが怖いから」とバージョンアップを先送りにしてきたシステムが、今回のPHP2Shellのような致命的な脆弱性に晒された瞬間、手も足も出なくなるのです。

WAF(Web Application Firewall)の設定調整や、一時的な設定変更で攻撃を防ごうとする現場もありますが、これはあくまで「時間稼ぎの応急処置」にすぎません。

バージョンアップに追従できないシステムは、ソフトウェアとしての寿命をすでに迎えており、「技術的負債の返済を先送りして延命しているだけ」というのが残酷な現実です。

 

🤔 開発者・エンジニアが取るべき姿勢

今回の騒動から私たちが学ぶべきなのは、「脆弱性が出たときにどう対処するか」だけではありません。「そもそもバージョンアップを前提としたアーキテクチャや保守体制をどう維持するか」という点です。

・ フレームワークや言語のマイナーアップデートを日々の運用に組み込む
・ EOL(サポート終了)を迎える前に、計画的なマイグレーション予算を確保する
・「動いているから触らない」ではなく、「触り続けられる状態(テストコードやCI/CD)を保つ」

これらができていないシステムは、どれだけ強固なセキュリティ製品を前段に置いたとしても、いつか必ず破綻します。

 

🤔 まとめ

「PHPのバージョンを上げたら終わりじゃないの?」という疑問に対する答えは、「理屈の上ではその通り。でも、上げられないシステムがあまりにも多すぎるから大騒ぎになっている」です。

セキュリティの脆弱性問題は、単なる技術の問題ではなく、これまでのシステム運用・投資判断のツケが可視化された結果とも言えます。

「そもそも、アナウンス済みのさまざまな脆弱性を放置したままだったよな?」

自社で管理しているシステムや関わっているプロダクトがあるなら、今回の件を機に「いつでも言語バージョンを上げられる状態になっているか?」を改めて見直してみるのが良いかもしれません。

👉 PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.


5-Minute TLS/SSL Troubleshooting Playbook - IP-direct access only (curl / openssl)

 

🧑🏻‍💻 Introduction

When you go through DNS, you can be misled by:

  • caching
  • load balancers / CDNs
  • name-resolution mistakes

This guide standardizes all commands to IP-direct access + correct SNI so you can isolate the real cause quickly.

 

🧑🏻‍💻 Prerequisite Variables


DOMAIN=example.com 
IP=1.2.3.4

 

🧑🏻‍💻 Overall Flow


① Check reachability with curl (IP direct) 
    ↓ 
② Read certificate verification result 
    ↓ 
③ Get raw TLS data with openssl 
    ↓ 
④ Check certificate expiration 
    ↓ 
⑤ Verify SAN 
    ↓ 
⑥ Check intermediate certificate 
    ↓ 
⑦ Verify TLS versions

 

🧑🏻‍💻 ① HTTP Reachability (IP direct + SNI)


curl -v https://$DOMAIN \
 --resolve $DOMAIN:443:$IP \
 -o /dev/null

OK


* Connected to example.com (1.2.3.4) port 443
* SSL certificate verify ok.
< HTTP/1.1 200 OK

Failure


Connection refused

  • nginx / apache not running
  • closed port
  • firewall

 

🧑🏻‍💻 ③ Raw TLS Layer Information


openssl s_client \
 -connect $IP:443 \
 -servername $DOMAIN

OK


CONNECTED(00000003)
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

 

🧑🏻‍💻 ④ Certificate Expiration


openssl s_client \
 -connect $IP:443 \
 -servername $DOMAIN 2>/dev/null \
 | openssl x509 -noout -dates


notAfter=May 2 23:59:59 2026 GMT

 

🧑🏻‍💻 ⑤ SAN (Domain Match)


openssl s_client \
 -connect $IP:443 \
 -servername $DOMAIN \
 | openssl x509 -noout -ext subjectAltName


DNS:example.com
DNS:www.example.com

 

🧑🏻‍💻 ⑥ Missing Intermediate Certificate Check


openssl s_client \
 -connect $IP:443 \
 -servername $DOMAIN \
 -showcerts

OK


Certificate chain
 0 s:CN = example.com
 1 s:C = US, O = Let's Encrypt, CN = R3

Missing


Certificate chain
 0 s:CN = example.com

→ fullchain.pem not configured

 

🧑🏻‍💻 ⑦ TLS Version Restrictions

TLS 1.2


curl --tlsv1.2 -v https://$DOMAIN \
 --resolve $DOMAIN:443:$IP \
 -o /dev/null

TLS 1.3


curl --tlsv1.3 -v https://$DOMAIN \
 --resolve $DOMAIN:443:$IP \
 -o /dev/null


unsupported protocol

→ ssl_protocols misconfiguration

 

🧑🏻‍💻 ⑧ Detect SNI Misconfiguration (intentionally omit it)


openssl s_client -connect $IP:443


subject=CN = default.example.net

→ default certificate returned
→ virtual host configuration issue

 

🧑🏻‍💻 Copy-Paste 5-Minute Diagnosis Set



DOMAIN=example.com 
IP=1.2.3.4 

curl -v https://$IP \
 -H "Host: $DOMAIN"\
 -o /dev/null 

openssl s_client -connect $IP:443 \
 -servername $DOMAIN -brief 

openssl s_client -connect $IP:443 \
 -servername $DOMAIN 2>/dev/null \
 | openssl x509 -noout -dates 

openssl s_client -connect $IP:443 \
 -servername $DOMAIN \
 | openssl x509 -noout -ext subjectAltName

 

🧑🏻‍💻 Root-Cause Shortcut Map


Cannot connect even with IP direct
 → server or firewall 

Verify error 
 → intermediate certificate 

Expired
 → certificate renewal missed

SAN mismatch
 → wrong certificate selected 

Different cert without SNI
 → virtual host configuration 

Only one of TLS1.2 / 1.3 fails
 → protocol restriction

 

🧑🏻‍💻 Summary

By eliminating DNS and fixing:

  • IP-direct access
  • correct SNI

your TLS troubleshooting speed improves dramatically.

This workflow is ready to copy-paste in real incidents.

👉 openssl-s_client - OpenSSL Documentation
👉 curl - SSL CA Certificates


AIが書いたコードは静かにアプリを壊す — “動く”ことに満足した開発の行き着く先 —

 

🧑🏻‍💻 1. 「動くコード」を生み出すAIの魔法と、その落とし穴

最近の開発現場では、「AIにコードを書かせる」のが当たり前になってきた。
ChatGPTやGitHub Copilotに「○○を実装して」と伝えれば、数秒で動くコードを出してくれる。
それをコピーして貼り付ければ、ビルドも通り、アプリも動く。
——まるで魔法のようだ。

けれど、実はこの“動くコード”こそがアプリを静かに壊していく。
なぜなら、そのコードは「なぜ動くのか」を誰も理解していないからだ。
AIは文脈を「設計思想」ではなく「統計的パターン」で捉える。
だから動作優先で、構造や責務を無視したコードを出すことがある。

その結果、「とりあえず動いたからOK」というコードが少しずつ積み上がる。
数カ月後、いざ修正しようとしたとき、
「この処理、誰がどうしてこう書いたんだっけ?」
——誰も答えられない。
そんな“ブラックボックス化”が静かに進んでいく。

 

🧑🏻‍💻 2. 小さな歪みが積もって、アプリの寿命を縮める

AIが生成するコードは、局所的には正しい。
しかし全体で見れば、設計のバランスを壊していることが多い。

たとえばMVVM構造のアプリで、AIが「便利なショートカット」としてUI層から直接データベースにアクセスするようなコードを出す。
確かに動く。けれど、これは明確に“構造違反”だ。
一見問題ないように見えても、
こうした「小さな歪み」が何十箇所も積み重なると、アプリは急速に脆くなる。

特にAIは“最短距離”で解決しようとする。
テストやエラーハンドリングは省かれ、
依存ライブラリも無自覚に増える。
それでも最初は動くため、気づかない。
だが、ある日突然ビルドが通らなくなったり、
AndroidやiOSのバージョン更新で全体が壊れたりする。

原因を追っても、「どこから手をつければいいのか」が分からない。
AIが生み出した“つぎはぎ構造”が、まるで崩れかけた積み木のように、
どこを直しても全体がぐらつく。
——それが「AIがアプリの寿命を縮める」という現象の正体だ。

 

🧑🏻‍💻 3. AIと共存するために、設計を“守る人間”が必要になる

AIを完全に排除することは現実的ではない。
むしろ、うまく使えば開発効率は飛躍的に上がる。
問題は、「AIに書かせたあとをどう扱うか」だ。

たとえば、AIに出させたコードは必ずレビューする。
一人開発でも“レビュー時間”を意識的に取る。
「動くかどうか」ではなく、「構造的に正しいか」を基準に見る。
さらに、AIへの指示(プロンプト)も工夫する。
「なぜこの方法なのか」「設計上のリスクは?」と質問を加えるだけで、
AIの出力品質は大きく変わる。

AIはあくまで“補助輪”だ。
自転車を前に進ませることはできても、
どの道を走るべきかまでは決めてくれない。

これからのエンジニアは、
AIを“使う人”ではなく“指揮する人”になる必要がある。
AIの力で速く動く一方で、
人間が「構造を守るブレーキ役」を担う。
そのバランスこそが、アプリを長生きさせる秘訣だ。

 

🧑🏻‍💻 まとめ:AIは便利な酸素、でも吸いすぎると毒になる

AIは開発のスピードを何倍にも引き上げる。
しかし、構造を無視したまま使えば、
そのスピードでアプリの寿命を削り取る。

“動く”ことだけをゴールにしてしまうと、
“生き続ける”ための土台が壊れていく。

AIが生み出すコードは、確かに速く、便利で、魅力的だ。
でも、それを理解し、守り、磨き続けるのは人間の役割だ。
アプリの未来は、AIの性能ではなく、
それを正しく使う開発者の構造への愛情にかかっている。


スマートフォン を ドリル で破壊する

電源が入らなくなったスマートフォンたち。

バッテリー交換したり、してもらったり、保証期限内交換とかしてましたが、もうめんどくさい。

👉 スマホのバッテリーが膨張し始めたときどうするか。 hatena-bookmark

👉 Android端末のバッテリーが膨らんできた場合 hatena-bookmark

今回は、セキュアに破壊して捨てます。

 

🔥 新規購入アイテム

ドリルドライバーです。めっためたにやってやります。

 

🔥 電動ドリルドライバー到着

到着しました。

同梱物。

と説明書でした。

いざ。

「+」のビットでは無理ですね。

ホームセンターに行ってきます。

 

🔥 ドリルビット

種類が多すぎてわからん。

初心者はここらへんかな?

こんな記事。

電動ドリルは、金属を貫通する必要があるので5N・m以上のトルクがあるものが望ましく、ドリルビット(替芯)は鉄工用が必要です。筆者はカインズのACドリルドライバー「KT-01」(3280円)と、直径6mmの鉄工用ドリルビット(2本で578円)を使用しました。

👉 ASCII.jp:定番のHDD破壊方法 これであなたもドリル◯◯ hatena-bookmark

 

🔥 ガラスは強い

18V のドリルドライバーでこの感じ。




ガラスをズボズボっと穴を開けていくには厳しい感じがします。

ガラス部分を貫通させることはやめておくことにします。

カバーを開いてから基盤部分をドリルすることにします。

ヘラ的なものをメルカリや100均で手に入れます。

あとはマイナスドライバーなどをつかってカバーやガラスを含む表面部分をめくっていきます。

 

🔥 内蔵バッテリーは危険

破壊するの危険。

一般ごみと一緒に捨てるのも危険です。




破壊する前にすべて取り外します。

まとめて自治体の指示にしたがって捨てることにします。

 

🔥 ドリルビット到着

これ買いました。

むむ。

硬え。各部品、穴あけに対して強くね ?

 

🔥 新アイテム購入

ロックチェーンも南京錠もガンガン切っちゃうこれ。

チップを狙ってガンガン切断していきます。

これが一番良いですわ。

 

🔥 まとめ

ドリルはスマホやパソコンを破壊するのには適してない。

バッテリーの液漏れや巻き込みなど取り扱いは素人には危ないし、

メモリチップやディスクを確実に貫通できないので

データを救出できる可能性はあると思う。

最後に、スマホ破壊に役立った工具 のみを。

メガネ大事。

ケガをしないように気をつけてください。