マイナンバーカードを医療受給者証にする——導入の“見える化”と技術設計をコードで検証する

• マイナンバーカードを医療受給者証に使う自治体が増加中（岡崎市の案内を参照）
• エンジニア的に言うと、認証・端末・ログの観測設計が導入成否を左右する！
• PDF案内だけじゃダメ。APIとオープンな運用指標で改善ループを回そう

結論

どうも〜おかむーです！結論はシンプルで、マイナンバーを医療受給者証として運用するなら「認証フローの可観測化」と「機械可読の運用データ公開」が必須です。単に導入を告知するだけだと現場の障害や市民の混乱が見えないんですよね。

レポート本文

背景と現状確認

岡崎市の案内（https://www.city.okazaki.lg.jp/）のように、自治体がマイナンバーカードで医療受給者証を使えると宣言する事例が出ています。技術的には「カードのIC読み取り（NFC）→本人認証→医療保険情報参照」の流れですが、実運用では以下が課題になります。

• 端末多様性（スマホNFC/窓口リーダーの混在）
• エラーの観測不備（どの段階で失敗したか不明）
• データフォーマットの断絶（レガシーシステムはAPI非対応）

これ見てくださいよ：e-Statや都道府県のオープンデータカタログ（例：東京都オープンデータカタログやCKANを採用する大仙市）を見ると、自治体は統計やCSVは出してるんですが、認証ログや端末別の稼働率といった運用指標は公開していないケースが多いです。

技術的チェックリスト（エンジニア目線）

• 認証方式：OpenID Connect / OAuth2でトークンベースにするべき（IC読取はフロント→認証サーバ→医療DBの最小権限で）
• 端末IDとファーム情報：障害解析のために端末種別やドライバ版をログに残す
• フェールオーバー：オンライン認証不可時のオフライン手続き仕様を明記
• ログの粒度：成功/失敗の原因コード、レイテンシ、ユーザ同意の有無

要するに、認証とデータ参照の双方で「観測ポイント」をコード的に埋めていくってことです。

API設計のサンプル（概念コード）

// Node.js: IDトークン検証と保険情報取得の流れ（概念）
const verifyIdToken = async (idToken) => {
// OpenID Connectの公開鍵でJWTを検証
}
const fetchInsurance = async (userId) => {
const res = await fetch(https://api.pref.example.jp/insurance/${userId}, {headers:{'Authorization':'Bearer ...'}})
return res.json()
}

このとき重要なのは、APIはJSONで返し、エラーコードと説明を必ず含めることです。PDFや画像に埋めた通知は機械処理ができません！

データ公開と透明性の提案

自治体は以下をオープンにすべき：

• 日次の利用件数（NFCスマホ/窓口端末別）CSV
• エラー種別別カウント（認証失敗、APIタイムアウト等）
• 端末インベントリ（モデル、OS、導入日）

これらはe-Statや地方のオープンデータカタログ形式（CSV/JSON + メタデータ）で公開して、外部で可視化・監査できるようにするんです。

運用のための具体的手法

• CIで運用チェック：APIスキーマの互換性を毎日テスト
• SLO設定：認証成功率99%などを設定、ダッシュボードで公開
• 自動集計SQL例：

SELECT date_trunc('day', ts) as day, device_type, count(*) as attempts,
sum(case when result='OK' then 1 else 0 end) as success
FROM auth_logs
GROUP BY day, device_type
ORDER BY day DESC;

まとめ

導入アナウンスだけで終わらせないで、認証フローの各段に観測ポイントを入れて、APIとCSVで運用指標を公開しよう。エンジニア的に言うと「ログをデータセット化」して公開すれば、政策の改善サイクルが回り出します。PDF通知や黒箱運用はもう時代遅れ！

おかむーから一言

テクノロジーは“やった感”じゃなくて“見える化”で価値出るんですよ！実装は面倒でも、データを出して改善ループを回すのが行政DXの肝です。