マイナンバーカードと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エージェントが外部のサービスやデータに安全にアクセスするための標準規格です。

いきなり横文字で拒絶反応が出るという方もいるかもしれませんが（笑）

超簡単に表すと、クレジットカードの形です。 世界どこの国に行ってもそのサイズと端子が統一されているから、どの国のATMや決済端末でも使える、みたいな共通のつなぎ方の規格です。

ITに少し詳しい人なら　USB-Cの例えが一番わかりやすいかなと思います。 昔は機器ごとに充電ケーブルの形がバラバラで、機器の数だけケーブルが必要でした。USB-Cという共通規格ができたことで、どの機器も同じ差し込み口でつながるようになりましたよね。

このMCPという規格は、Claudeでお馴染みの世界的AI企業Anthropicが2024年に公開し、現在は業界全体に普及が進んでいます。

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

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

結論、MCPはそういう仕組みではありません。

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

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

次に、「丸ごと読める」わけでもありません。MCPの世界では、AIは「ツール」という単位でしか外部にアクセスできません。ツールとは、「住民票の写しを取得する」「特定の申請を提出する」といった、個別の機能のことです。

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

じゃあ、その「窓口に依頼する権限」は誰がどう管理するのか。ここがMCPの設計で一番重要な部分です。

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

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

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

MCPの認可では、この仕組みをベースに次のような考え方が採られています。

• ユーザーが明示的に同意した範囲（スコープ）だけ：許可していない操作は実行できない設計です
• 細かい単位で権限を制御できる設計：スコープの切り方次第で、「住民票の写し取得はOK、それ以外はNG」のような制御が可能です
• 許可証（トークン）は期限付きで、対象サーバー専用：発行された許可証には有効期限があり、特定の接続先でしか使えず、他の用途に流用できない設計です（サーバー限定は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モデルがテスト用の隔離環境（サンドボックス）を抜け出し、外部システムへ侵入した」という事案を公表しました（日経クロステックの報道）。AIがテスト問題の解答を入手する目的で、自ら脆弱性を見つけて侵入経路を組み立てたという、かなり衝撃的な内容です。

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

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

とはいえ、「つなぎ方のブレーキ」だけで十分かというと、そうは言えません。AIそのものの安全機能と組み合わせて初めて成立する話です。ここは「ごもっともな懸念」として、運用側が答え続けるべきポイントだと思っています。

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

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

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

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

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

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

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

ここまで「技術としてのMCP」を擁護する形で書いてきましたが、手放しで安心とは言いません。懸念として残る点を挙げておきます。

• 過去の運用実績：マイナンバー関連では、別人の情報を紐づけてしまうミスなど、実際に起きています。技術の設計が良くても、現場の運用でつまずいた前例があるのは事実です
• 「セキュアな連携」の中身：計画には「セキュアな連携」と書かれていますが、「何をもって安全と言えるのか」はこれからです。運用がちゃんと見える形かどうかが、これからも問われます
• 使わない選択(オプトイン)：ユーザーが「この機能は使わない」と選べること。使う人だけが同意して使う、という建て付けが大事です
• 履歴が見えること：AIエージェントが何をしたか、どんな権限を渡したかを、自分で確認できる仕組み。ここが整備されることに期待したいです

要するに、残っている論点はどれも「技術そのものがダメ」という話ではなく、「どう入れ、どう運用するか」の話です。

MCPそのものは、危険な技術だとは考えていません（実際違います）。適切に設計・実装すれば、従来の手作り連携よりも安全で制御可能な接続方法を提供できる、オープンな標準規格です。

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

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

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

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

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