EUデジタルIDウォレットの期限は2026年12月24日：パスポートをスキャンするアプリにとって何が変わるのか

アプリでユーザーにパスポートやIDカードの写真を求めているなら、EUデジタルIDウォレット（EU Digital Identity Wallet）が「2026年末」に登場すると耳にしたことがあるでしょう。この日付は本物で、しかも正確に決まっています。2026年12月24日です。ただし、これはあなたではなく加盟国に課された期限であり、書類のスキャンを終わらせるものでもありません。

この記事では3つのことを扱います。まず、この日付がどこから来るのかを計算とともに示します。次に、法令の属性表をもとに、ウォレットが実際に何を渡すのかを列挙します。そして、ユーザーがウォレットを持っていればそれを受け付け、持っていなければ書類のスキャンにフォールバックする設計を素描します。この記事を書いているのはパスポート・身分証OCR APIのdoc.cheapです。製品に関する部分はその点を踏まえて読んでください。doc.cheapは書類の画像を読み取るサービスで、ウォレットは読み取りません。

2026年12月24日の根拠

この義務は、eIDAS改正法であるReg. (EU) 2024/1183によって挿入された、Reg. (EU) No 910/2014の第5a条第1項にあります。そこでは各加盟国は「本条第23項および第5c条第6項に定める実施法の発効日から24か月以内に、少なくとも1つの欧州デジタルIDウォレットを提供しなければならない」とされています。

つまり、時計はeIDAS改正法そのものから動き出すわけではありません。起点は欧州委員会の実施法です。第5a条第23項に基づく実施法は、2024年11月28日付の4本の欧州委員会実施法で、その中にウォレットの完全性と中核機能に関するImplementing Reg. (EU) 2024/2979が含まれます。これは2024年12月4日に官報（OJ L, 2024/2979）で公布されました。その第15条は、「欧州連合官報での公布の日の翌日から起算して20日目に発効する」と定めています。

計算は次のとおりです。

ステップ	日付
官報で公布	2024年12月4日
公布後1日目	2024年12月5日
公布後20日目：発効	2024年12月24日
プラス24か月（第5a条第1項）：ウォレットの期限	2026年12月24日
プラス36か月（第5f条第2項）：一部の民間の依拠当事者がウォレットの受け入れを義務付けられる	2027年12月24日

「翌日から起算して20日目」は公布日の翌日から数えるので、12月4日に20日を足すと23日ではなく24日になります。表の2つ目の日付も同じ実施法から計算され、多くのプロダクトチームが実際に気にするのはこちらです（詳しくは後述）。

ウォレットが渡すもの

ウォレットはパスポートの画像を送りません。署名されたデータを提示します。自然人のデータセットは、Implementing Reg. (EU) 2024/2977の附属書で定められた「個人識別データ」（person identification data、PID）です。附属書によれば、PIDは2つの形式で発行されます。ISO/IEC 18013-5:2021と、W3Cの「Verifiable Credentials Data Model 1.1」です。

以下が属性と、それぞれについて本文が定める要否です（附属書の表1、2、5。2024年12月4日の公布版による）。最後の列はdoc.cheapのスキャンレスポンスで最も近いフィールドで、2つの世界がどこで一致し、どこで一致しないかがわかります。

PID属性	要否	書類スキャンで最も近いフィールド
`family_name`	必須	`holder.surname`
`given_name`	必須	`holder.given_names`
`birth_date`	必須	`holder.birth_date`（ISO 8601）
`birth_place`	必須	書類に印字されている場合、`fields[]` 内の `birth_place` エントリ
`nationality`	必須（alpha-2、1つ以上）	`holder.nationality`（alpha-3、1つ）
`resident_address`、`resident_country`、`resident_state`、`resident_city`、`resident_postal_code`、`resident_street`、`resident_house_number`	任意	パスポートの身分事項ページにはない
`personal_administrative_number`	任意	同じものではない。`fields[]` に書類が印字する `personal_number` が含まれる場合がある
`portrait`	任意	`images.main_photo`
`family_name_birth`、`given_name_birth`	任意	整形済みフィールドなし
`sex`	任意（コード 0、1、2、3、4、5、6、9）	`holder.sex`（`M`、`F`、`X`）
`email_address`、`mobile_phone_number`	任意	書類には載っていない
`expiry_date`（メタデータ）	必須	`document.expiry_date`。ただしPIDではなく書類の有効期限
`issuing_authority`（メタデータ）	必須	印字されている場合、`fields[]` 内の `authority` エントリ
`issuing_country`（メタデータ）	必須（alpha-2）	`document.issuing_state`（alpha-3）
`document_number`（メタデータ）	任意	同じものではない。PIDの番号はPIDプロバイダーが割り当て、`document.number` はパスポートの番号
`issuing_jurisdiction`、`location_status`（メタデータ）	任意	なし

マッピングのコードを書くときには、この表の3つの点が重要になります。

国コードが異なります。 PIDはISO 3166-1 alpha-2（DE）を使います。パスポートと機械読取領域（MRZ）はalpha-3（DEU）を使います。内部の形式は1つに決め、境界で変換してください。
「必須」は「常にわかっている」という意味ではありません。 表1の下で本文はこう付け加えています。「ある属性の値がその人について知られていない場合、またはその他の理由で個人識別データセットの一部として発行できない場合、加盟国は代わりにその状況に適した属性値を使用しなければならない。」キーの欠落ではなく、プレースホルダー値を想定してください。
本人に関する必須属性は5つだけです。 住所、顔写真、性別、出生時の氏名はすべて任意です。フローでそのいずれかが必要な場合、ユーザーによってはウォレットにその値がまったく含まれていないことがあります。

それでも書類を持って来る人

この期限が加盟国に義務付けているのは、ウォレットを提供することです。誰かにウォレットの使用を義務付けるものではありません。第5a条第15項ははっきりこう述べています。「欧州デジタルIDウォレットの使用は任意とする。」さらに続けて、「その他の既存の識別および認証の手段によって公的および民間のサービスにアクセスすることは、引き続き可能でなければならない。」

そのため、2026年12月24日以降も次のような人やケースに出会います。

EU域外からの旅行者や顧客。 前文はウォレットを「連合の市民、連合内の居住者または法人の法的なID」に結び付けています。他の地域のパスポートを持つ訪問者には、提示できるEUウォレットがありません。
ウォレットをインストールしていない人、できない人、あるいはしたくない人。本文はその選択を保護しています。
書類そのものが必要なフロー。 本人についての証明ではなく、物理的な書類の画像、書類番号、機械読取領域を必要とするプロセスもあります。ウォレットのPIDにはPIDプロバイダーが割り当てた独自の document_number があり、それはパスポートの番号ではありません。
特定の国のウォレットが稼働する前の期間。 2026年12月24日は法的な期限です。各国のウォレットが実際にいつユーザーに届くかは別の問題で、ある国について信頼できる唯一の答えは、その国自身の発表か欧州委員会の発表です。

両方を受け付ける設計

これらすべてを踏まえても成り立つ形はシンプルです。ユーザーがウォレットを持っていればウォレットの提示を求め、持っていなければ書類のスキャンにフォールバックします。どちらの経路も同じ内部レコードに行き着きます。

user starts verification
        |
        v
  offers a wallet? --yes--> wallet presentation --> verify signature --> map PID
        |                                                               |
        no                                                              v
        |                                                      internal identity
        v                                                          record
  document photo --> POST /v1/scans --> map scan fields ----------------^

2つの経路を入れ替え可能にするためのルールがいくつかあります。

両方を1つのレコードにマッピングする。 フィールド名は自分たちのものを使います。上の表をマッピング表として使ってください。
出どころを保持する。 レコードがウォレットから来たのか、スキャンから来たのかを保存します。両者は異なる証拠を持っており、審査担当者はどちらなのかを知りたがります。
nullを正直な値として扱う。 doc.cheapのレスポンスでは、すべてのキーが常に存在し、不明な値は null になります。ウォレットは代わりにプレースホルダーを送ることがあります。両方を1つの規約に正規化してください。
フローに必要な最小限だけを保存する。 スキャンは、API側に何も書き残さないように実行できます（後述）。

以下は素の fetch によるフォールバックの呼び出しです。公開sandboxキー sk_sandbox_public はドキュメントに掲載されており、登録は不要です。クライアントのアドレスごとにレート制限がかかります。

import { readFileSync } from "node:fs";
import { randomUUID } from "node:crypto";

async function scanDocument(path, apiKey = "sk_sandbox_public") {
  const response = await fetch("https://api.doc.cheap/v1/scans", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      "Idempotency-Key": randomUUID(), // リトライすると最初の結果が返る
    },
    body: JSON.stringify({
      image: readFileSync(path).toString("base64"),
      options: { retain_hours: 0, return_portrait: false }, // 何も保存しない
    }),
  });
  if (!response.ok) throw new Error(`scan failed: HTTP ${response.status}`);
  return response.json();
}

// スキャン結果を、ウォレットの提示で埋まるのと同じレコードにマッピングする。
function fromScan(scan) {
  if (scan.meta.status !== "recognized") return null;
  const field = (name) => scan.fields.find((f) => f.id === `${name}@0`)?.value ?? null;
  return {
    source: "document_scan",
    family_name: scan.holder?.surname ?? null,
    given_name: scan.holder?.given_names ?? null,
    birth_date: scan.holder?.birth_date ?? null,
    birth_place: field("birth_place"),
    nationality_alpha3: scan.holder?.nationality ?? null,
    issuing_country_alpha3: scan.document?.issuing_state ?? null,
    document_number: scan.document?.number ?? null,
    mrz_status: scan.mrz.status, // "passed"、"failed" または "absent"
  };
}

meta.status は5つの文字列のいずれかです。recognized、no_document_found、unreadable、unsupported_document、rejected。レコードを埋めるべきなのは最初のものだけで、それ以外はユーザーに撮り直しを促すべきです。有料キーでは、課金対象のスキャンのときだけ残高が引き落とされます。

私たちは2026年9月24日21:17 UTCに、製品自身のテスト用書類（パスポート）を使って、sk_sandbox_public に対してこの種の呼び出しを1回実行しました。レスポンスはHTTP 200で返りました。以下の書類の値はすべてマスクしており、fields、images、mrz.lines は省略しています。

{
  "meta": {
    "schema_version": "1.0",
    "id": "<SCAN_ID>",
    "status": "recognized",
    "billed": true,
    "confidence": "medium",
    "timing": { "upload_ms": 255, "processing_ms": 409, "total_ms": 678 },
    "created_at": "<RUN_TIMESTAMP>",
    "reference": null
  },
  "document": {
    "kind": "passport", "country": "<ISO3>", "country_name": "<COUNTRY>",
    "issuing_state": "<ISO3>", "number": "<DOCUMENT_NUMBER>", "series": null,
    "issue_date": "<DATE>", "expiry_date": "<DATE>", "is_expired": false, "days_remaining": "<N>"
  },
  "holder": {
    "given_names": "<GIVEN_NAMES>", "surname": "<SURNAME>", "full_name": "<FULL_NAME>",
    "birth_date": "<DATE>", "sex": "<SEX>", "nationality": "<ISO3>"
  },
  "mrz": { "status": "passed", "reason": null, "lines": ["<LINE_1>", "<LINE_2>"], "text": "<MRZ>" },
  "quality": { "overall": "pass" },
  "authenticity": { "overall": "not_checked", "checks": [] }
}

ここでの billed: true は、そのスキャンが課金対象であり、sandboxの無料枠から差し引かれたことを意味します。sandboxキー自体に料金が請求されることはありません。この実行の fields 配列には birth_place、authority、personal_number のエントリが含まれており、上の表でそれらのPID属性の対応先として示したのがこれです。パスポートの身分事項ページには、TD3レイアウトの2行のMRZがあります。TD1、TD2、TD3の形式のページでは、各レイアウトを並べて示しています。

authenticity.overall: "not_checked" に注意してください。このようなスキャンは認識です。印字されている内容を読み取り、MRZのチェックディジットを検証します。偽造検知ではなく、署名されたウォレットの提示と同じ保証でもありません。スキャン経路でより高い保証レベルが必要なプロセスであれば、それはフローの別の部分で確保する必要があります。フォールバック用のプロバイダーを選んでいるなら、パスポートOCR APIの比較で、認識以上のことを行う選択肢も含めて整理しています。

今後注目すべき点

2026年12月24日 – ウォレットの期限。 第5a条第1項、Reg. (EU) 2024/1183。上で示したとおり、実施法の発効日から起算します。
2027年12月24日 – 民間の依拠当事者。 第5f条第2項は、法律または契約によりオンラインでの識別に強力なユーザー認証を用いなければならない民間の依拠当事者は、「第5a条第23項および第5c条第6項に定める実施法の発効日から遅くとも36か月以内に、かつユーザーの任意の要請があった場合に限り、欧州デジタルIDウォレットも受け入れなければならない」と定めています。本文は運輸、エネルギー、銀行、金融サービス、社会保障、保健、飲料水、郵便サービス、デジタルインフラ、教育、電気通信を挙げ、零細企業と小企業を除外しています。
超大規模オンラインプラットフォーム。 第5f条第3項は、これらのプラットフォームにユーザー認証でウォレットを受け入れることを義務付けています。こちらもユーザーの任意の要請がある場合に限り、必要最小限のデータについてです。
実施法の改正。 Implementing Reg. (EU) 2024/2979の前文第4項は、欧州委員会が必要に応じてこれを「見直し、更新すべきである」と述べています。マッピングを確定する前に、2024/2977の属性表を確認してください。

実務上のポイントはこうです。ユーザーの国がウォレットを提供し始めたらウォレットの経路を作り、書類の経路は残し、最初の日から両方を1つのレコードにマッピングすること。スキャン側の詳細はパスポート・身分証OCR APIのドキュメントですべて解説しています。

これは技術的な要約であり、法的助言ではありません。