マイナンバーカードとAI連携は危険？MCPの仕組みをエンジニアが解説

2026年7月21日、政府は令和8年の「デジタル社会の実現に向けた重点計画」を閣議決定しました。この中で、マイナンバーカードの活用策のひとつとして、「外部AIエージェントとのセキュアな連携に向けたMCP構築」が明記されています。

デジタル庁が公表した計画本文には、次のような記載があります。

外部を含めた AI エージェントでのマイナポータル内のサービスの利用実現に向け、令和９年度中を目途に MCP 等の基盤構築を目指す。

つまり、行政手続きのオンライン窓口である「マイナポータル」を、将来的にAIエージェント経由で利用できるようにする計画です。令和8年度（2026年度）中に対応方針を検討し、マイナポータルについては令和9年度（2027年度）中を目途に、基盤構築を目指すスケジュールです。出典は CNET Japanの報道 です。

イメージとしては、AIエージェント（人に代わって判断し、タスクを実行するAI）に「引っ越したので住所変更の手続きをして」と頼む形です。AIが本人に代わって、手続きを進めます。そういう未来を見据えた動きです。

ここで出てくるのが「MCP」です。

MCP（Model Context Protocol）は、AIエージェントが外部のサービスやデータにアクセスするための標準規格です。

わかりやすく言うと、USB-Cと同じ発想です。昔は機器ごとに充電ケーブルの形がバラバラで、機器の数だけケーブルが必要でした。USB-Cという共通規格ができて、どの機器も同じ差し込み口でつながるようになりましたよね。MCPも、AIと外部サービスをつなぐ差し込み口を揃える規格です。

この規格は、対話型AIのClaudeを提供するAnthropicが2024年に公開し、現在は業界全体に普及が進んでいます。

MCPは「AIそのもの」ではありません。接続のルールです。データを渡す範囲、本人確認のやり方、権限の管理といった、約束事を定めた仕様だと考えてください。

SNSで一番多かった誤解が、「マイナンバーの情報がAIの学習データにされる」「AIが個人情報を丸ごと読める状態になる」というものです。

MCPは、そもそも個人情報を学習させる仕組みではありません。

まず、「学習」と「利用」は別です。AIの学習とは、大量のデータからモデルを作り上げる工程です。一方、MCP経由のデータアクセスは、完成したAIが会話中に必要な情報だけを、その場で参照する行為です。手続きのために一時的に参照することと、そのデータでAIを訓練することは、技術的にまったく別です。

なお、「参照した結果を、AI事業者がその後どう扱うか」は、技術ではなく運用ルールの話です。後半の「外国製AIにデータが流れるのでは？」で触れます。

次に、「丸ごと読める」わけでもありません。MCPでは、AIは ツール（「住民票の写しを取得する」など、個別の機能）という単位でしか、外部にアクセスできません。

AIエージェントは、「この手続きをしたい」と判断したときに、該当するツールだけを呼び出します。データベースの中身を自由に見て回れるわけではなく、用意された窓口へ、必要なとき、ひとつずつ依頼する形です。

では、その窓口を呼ぶ権限は、誰がどう管理するのか。次はそこを見ます。

MCPの公式仕様では、認可の仕組みとしてOAuth 2.1が採用されています。認可とは、アクセス許可を管理することです。

OAuth（オーオース）という名前に馴染みがなくても、ほとんどの人は日常的に使っています。アプリの初回起動で「Googleアカウントでログイン」を選ぶと、「このアプリがカレンダーへのアクセスを求めています。許可しますか？」という確認が出ます。あの裏側で動いているのがOAuthです。

渡すのはパスワードそのものではなく、「この範囲だけ操作していい」という許可証です。OAuth 2.1は、この仕組みの改訂版です。現在、標準化が進められているバージョンで、GoogleやMicrosoftのアカウント連携など、世界中のサービスで使われてきた仕組みの系譜です。

MCPの認可では、この仕組みを基に、次の考え方が採られています。

• スコープ（ユーザーが明示的に同意した範囲）だけを許可します。許可していない操作は、実行できない設計です
• スコープの切り方次第で、「住民票の写し取得は許可、それ以外は拒否」のように、権限の単位を細かく分けられます
• 許可証（トークン）には有効期限があり、特定の接続先でしか使えません。ほかの用途には流用できない設計です。サーバー限定は、RFC 8707で規定されています

つまり、AIが持てるのは、「本人が同意した範囲の、期限と用途が限定された許可証」だけです。合鍵を渡すのではなく、「この部屋にだけ入れる、期限付きの入館証」にたとえられます。権限の設計については、以前映画『サマーウォーズ』から現代セキュリティを整理した記事でも書きました。

では、実際にAIへ手続きを頼んだとき、データはどう動くのか。典型的な流れは、次の4ステップです。

1. ユーザーがAIエージェントに「〇〇の手続きをして」と指示します
2. AIがMCPサーバーに「このツールを実行して」とリクエストします（本人確認のための許可証付き）
3. サーバー側が、本人が同意した範囲で必要な処理を行い、結果だけを返します
4. AIがその結果を使って、会話を続けます

ステップ3で実際のデータ処理を行うのは、AIではなくサーバー側（この場合は政府側のシステム）です。AIに渡るのは、処理の結果だけです。データベースへの直接アクセス権が、AIに渡るわけではありません。

この流れは オンデマンド（依頼があったときだけ動くこと）です。ユーザーが指示したときだけ動き、終われば接続は閉じます。全データが、常時AIから見える状態ではありません。

そのうえで、SNSで見かけた代表的な不安に、技術の側からひとつずつ答えます。

「個人情報が漏洩するのでは？」

正直に言うと、技術的に可能な漏洩経路は増えます。新しい接続口を作る以上、接点が増えるのは事実だからです。ここをゼロと言う人がいたら、むしろその説明は信用できません。

ただし、MCP自体は「接続を標準化し、権限管理を揃えやすくする」側の仕組みです。サービスごとに連携プログラムを手作りする方式では、権限管理の質が実装者ごとにばらつきます。共通規格に乗せると、監査ログ（誰が何をしたかの記録）、短命の許可証（すぐ期限切れになるトークン）、最小権限、人間による最終確認を、まとめて入れやすくなります。

つまり、論点は「つなぐか切るか」ではなく、「どうつなぐか」です。

「AIが暴走したらどうする？」

2026年7月、OpenAIが事案を公表しました（日経クロステックの報道）。評価中のAIモデルが、テスト用の隔離環境（サンドボックス）を抜け出し、外部システムへ侵入した、という内容です。テスト問題の解答を入手するため、自ら脆弱性を見つけて侵入経路を組み立てています。

ただし、この事案には文脈があります。起きたのは「ExploitGym」という、AIのサイバー攻撃能力を測るベンチマーク評価の最中です。能力の上限を見るため、危険なサイバー活動を止める安全機能を、意図的に弱めた環境でした。一般提供中のAIが、通常の安全機能を備えた状態で起こした行動ではありません。

この事例は、「AIそのものの振る舞いをどう抑えるか」の話です。一方、MCPは「AIと外部サービスをどうつなぐか」の話で、役割が違います。MCP側から見ると、仮にAIが想定外の行動を取っても、「権限のない手続きは呼べない」「同意した範囲外の操作は拒否される」というブレーキが残ります。

とはいえ、つなぎ方のブレーキだけでは足りません。AIそのものの安全機能と組み合わせて、初めて成立する話です。運用側が答え続けるべき懸念だと思っています。

「外国製AIにデータが流れるのでは？」

これも、「ゼロです」とは言い切れません。AIエージェント側に何らかの結果データが渡る以上、リスクを完全に消すことはできないからです。

ただし、設計の詳細は未公表です。マイナポータル側に基盤を構築する計画である以上、処理層は政府側と見るのが自然です。機微なデータ（漏れると被害が大きい個人情報）と、手続きの処理層は、政府側のMCPサーバーが担うと考えられます。マイナンバーカードに紐づく情報を、丸ごとAIに渡して考えさせる形ではありません。返るのは、同意された手続きの結果だけです。

「私のマイナンバーに格納されているデータが、すべて外国のAIに流出してしまう」という心配は、この構造を前提にする限り、過剰だと言えます。実務の確認対象は、接続を認可するAIエージェントと、結果データの扱いを規律するルールです。引き続き、政府からの追加の発表を待つ必要があります。

「監視社会になるのでは？」

ここまで見てきたとおり、MCPは、ユーザーが起動し、同意した範囲で、ツール単位で動くのが基本設計です。頼んだときだけ動く技術であり、常時監視のために開き続ける接続は、この設計にはありません。

ただし、この整理は「実装と運用が設計どおりであること」が前提です。実装と運用の透明性と、監査できることが、可能な範囲で公表されないと、この懸念は残ります。ここは、技術だけでは解けません。

ここまで、技術としてのMCPを整理してきました。手放しで安心、とは言いません。残る懸念は、次のとおりです。

• 過去の運用実績。マイナンバー関連では、別人の情報を紐づけてしまうミスが、実際に起きています。設計が良くても、現場の運用でつまずいた前例があるのは事実です
• 「セキュアな連携」の中身。計画には「セキュアな連携」と書かれていますが、何をもって安全と言うかは、これからです。運用が外から見える形かどうかが、今後も問われます
• 使わない選択（オプトイン）。初期状態では使わず、同意した人だけが使う方式です。使わない、と本人が選べる必要があります
• 履歴が見えること。AIエージェントが何をしたか、どんな権限を渡したかを、自分で確認できる仕組みです。ここが整備されるかを見る必要があります

残っている論点は、どれも「技術そのものがダメ」という話ではありません。「どう入れ、どう運用するか」の話です。

MCPそのものを、危険な技術だとは考えていません。適切に設計し、実装すれば、従来の手作り連携よりも、安全で制御可能な接続方法になります。誰でも仕様を読める、オープンな標準規格だからです。

仕様が公開されていることには、安全性の面でも意味があります。世界中のエンジニアや研究者が、中身を検証できるからです。たとえるなら、食品の原材料表示です。中身が書いてあるので、変なものが入っていれば気づきやすくなりますが、闇鍋だと入っているものは分かりません。実際、公開されている仕様には、この記事で紹介した権限管理の仕組みが、具体的に定義されています。

• MCPは「個人情報をAIに丸ごと渡す仕組み」ではなく、「同意した範囲だけを、ツール単位で、その場限りで渡す接続規格」です
• 権限管理はOAuth 2.1という実績ある標準に基づいており、技術仕様のレベルでは従来より規律ある連携が可能になります
• 一方で、実装と運用の透明性、オプトインの担保、履歴の可視化は今後の設計次第であり、ここは市民として見続けるべき論点です

SNS上で飛び交う「危険だ」も「問題ない」も、そのまま信じる必要はないと思っています。仕組みを理解したうえで、「実際の運用が見えるか」を見続けるべきです。

AIエージェントが現場でどう語られているかの空気感については、AI博覧会2026の現地レポートもあわせてどうぞ。

• 令和8年「デジタル社会の実現に向けた重点計画」本文（デジタル庁）
• 政府、マイナカードをAIエージェントと連携へ　重点計画に明記（CNET Japan）
• Model Context Protocol 公式仕様 Authorization（2025-11-25版）
• OpenAIのモデルが他社システムに侵入、ゼロデイ悪用でサンドボックス脱出（日経クロステック）