マイナンバーカードのスマートフォン搭載や、資格情報をアプリで持ち歩く仕組みの整備が進み、開発の現場でも「デジタルクレデンシャル」「検証可能な資格情報（VC）」という言葉を目にする機会が増えています。紙やICカードで管理してきた証明書をデータとして安全に発行・提示・検証する仕組みには、認証基盤や暗号技術、モバイル開発でこれまで積み上げてきた経験が生きる余地が広がっています。本記事では、発行機関・利用者・検証者という三者モデルと相互運用を支える標準規格の基本を整理し、リモートで関わる案件の入り口までをまとめます。資格情報の発行・保存・提示・検証は、それぞれ担う実装の中身が異なり、同じ「デジタルクレデンシャル」という言葉でもエンジニアが関わる場所は一様ではありません。

1. なぜいまデジタルクレデンシャルの案件が増えているのか

紙の証明書から、スマホで提示するデータへ

本人確認書類や資格証明書は、これまで紙やICカードという物理的な媒体で管理されてきました。提示のたびに原本を持ち歩き、確認する側も目視でしか照合できない状況が続いてきました。デジタル庁の資料では、デジタルIDウォレット（DIW）を、属性情報や資格情報等をスマートフォン等に保存し、利用者の操作を介して提示できるアプリケーションと整理しています¹。証明書という紙の情報を、暗号技術で保護されたデータへ置き換える動きが、開発案件の増加につながっています。

証明書のデジタル化と聞くと、業務システムの入力画面をアプリに移すだけの作業に見えるかもしれません。実際に求められるのは、発行者の署名を検証し、利用者の同意のもとで必要な項目だけを取り出す設計です。画面の見た目よりも、データの発行・保存・提示の流れをどう守るかという設計力が問われる領域です。

こうした変化は、行政や大企業だけの取り組みにとどまりません。会員証や資格証明といった身近な仕組みにも同じ考え方が広がりつつあり、バックエンドや認証まわりの実装経験を持つエンジニアが関わる接点は今後も増えていく見込みです。

実装を任される場面では、暗号技術やモバイル開発の基礎を持つエンジニアが、発行・保存・提示・検証のどこかの工程に関わる形になります。専門分野を大きく変えるのではなく、これまでの経験を新しい仕組みに当てはめる案件です。

マイナンバーカードとウォレットの動き

日本国内でも、マイナンバーカードの機能をAppleウォレットへ搭載する予定が示されており、ISO/IEC 18013（mDL）シリーズの規格への対応も示されています⁶。行政のIDが手元のスマートフォンに搭載される流れは、モバイルアプリの開発経験やセキュリティ設計の経験を持つエンジニアにとって、関わりやすい領域が広がっていることを意味します。次の章では、この仕組みを支える三者の役割を整理します。

モバイル端末の中で資格情報をどう安全に保持し、必要な場面でだけ提示するかという設計は、画面の使いやすさとセキュリティの両方を理解しているエンジニアが力を発揮しやすい領域です。

出典：デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）をもとに作成

2. 発行機関・利用者・検証者の三者モデル

三者がそれぞれ担う役割

デジタルクレデンシャルの仕組みは、発行機関（Issuer）が本人確認書類や資格証明書等をDIWに発行し、利用者（Holder）がサービス利用時に提示するという三者モデルを基本としています²。それぞれの立場でシステムに求められる要件が異なるため、案件の内容も担う役割によって変わります。

三者モデルは概念として説明されることが多い一方で、実装の現場ではAPIの設計、鍵の管理、データの検証ロジックといった具体的な作業に置き換わります。抽象的な関係図を、動くシステムに落とし込む工程こそが案件の中心です。

発行機関はデータの署名と発行の基盤を、利用者はウォレットアプリでの保存と提示の操作性を、検証者は提示された情報の検証と信頼の判断を担います。同じ資格情報の仕組みでも、どの立場のシステムに関わるかによって、必要な実装知識や連携先が変わります。次の表に、三者それぞれの主な役割と、実装で意識する点を整理しました。

立場	主な役割	実装で意識する点
発行機関（Issuer）	本人確認書類や資格証明書に署名して発行する基盤を提供	署名鍵の管理と失効の仕組みの設計
利用者（Holder）	資格情報をウォレットに保存し、必要な場面で提示する	保存データの保護とアプリの操作性
検証者（Verifier）	提示された資格情報の署名と提示者を検証する	検証結果の扱いと同意の記録

出典：デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）をもとに作成

三者の間のやり取りを独自形式のAPIに閉じてしまうと、後から別の発行機関や検証者と接続する際に手直しが増えます。標準化されたデータ形式に合わせておくことで、接続先が変わっても土台を作り直さずに済みます。

三者の間で交わされるのはデータだけではありません。検証者が発行機関の署名をどこまで信頼するかという合意そのものが、システム設計の前提になります。この合意の設計に関われることは、単なるAPI連携以上の経験として評価されやすい部分です。

三者の役割が独立しているからこそ、それぞれが異なる標準規格や仕様に沿って実装されている点も欠かせません。次の章では、相互運用を支える主な標準規格を見ていきます。

3. 標準規格で相互運用する

代表的な標準規格

デジタルクレデンシャルを特定のサービスの中だけで完結させず、異なる組織やサービスの間で使えるようにするには、共通の標準規格が欠かせません。代表的な規格として、検証可能な資格情報を汎用的に管理するためのW3C Verifiable Credentialsと、モバイル運転免許証に特化したISO/IEC 18013シリーズなどが挙げられます³。加えて、資格情報の提示や検証の手続きを定めるOpenID for Verifiable Credentialsという仕様も、実装の現場で参照されています。

規格の名前を覚えることよりも、それぞれの規格がデータの何を定めているかを区別できることのほうが、実装では役立ちます。データの中身を定める規格なのか、提示や検証の手順を定める規格なのか。この違いを押さえておくと、案件で求められる仕様書の読み方も変わってきます。

規格は今後も改定が重ねられていく分野です。仕様書を継続して読み解きながら実装を調整していく姿勢そのものが、特定のバージョンの知識よりも長く役立つ経験になります。

複数のクライアントの案件に関わる働き方では、特定のサービスだけに閉じた実装よりも、共通規格に沿った設計の経験のほうが、次の案件でも活かしやすい資産になります。

相互運用を確かめるには、他の実装と組み合わせた検証環境で動作を確かめる工程も欠かせません。仕様書どおりに作っても、組み合わせる相手のシステムによって挙動の違いが表面化することがあります。

三つの規格は役割が重なっているわけではなく、資格情報のデータ形式、モバイル運転免許証という用途、提示と検証の手続きという、それぞれ異なる層を担っています。次の表に、規格ごとの主な役割を整理しました。

規格	主な役割	関連する技術要素
W3C Verifiable Credentials	検証可能な資格情報のデータ形式を汎用的に定義	署名形式、データモデルの設計
ISO/IEC 18013（mDL）	モバイル運転免許証など特定用途の仕様を規定	近接通信での提示、端末側の実装
OpenID for Verifiable Credentials	資格情報の提示・検証の手続きを規定	認可の仕組みとの連携

出典：デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）をもとに作成

各国で進められているデジタルIDウォレットの取組と協調することで、行政・民間の証明書を国境を越えて相互運用できる環境づくりが期待されています⁵。国内向けの実装であっても、こうした標準規格に沿って設計しておくことが、案件を通じて評価される実装力につながります。次の章では、実装で押さえておきたい要素を見ていきます。

4. 実装で押さえる要素

選択的開示・提示者検証・不正防止

デジタルクレデンシャルの実装では、資格情報をそのまま渡すのではなく、必要な項目だけを選んで開示する「選択的開示」の設計が重要になります。年齢の証明だけを求められている場面で、生年月日や住所まで渡してしまう設計は、利用者にとって望ましいものではありません。

あわせて、利用者が情報を提示する際に、提示している本人（提示者）の検証も可能となるため、なりすましなどの不正の防止につながります⁴。データの正しさだけでなく、それを提示している人物が正当な保有者かどうかまで確認できる設計が求められます。

選択的開示、提示者検証、そして不正防止という三つの要素は、それぞれ独立した機能に見えて、実際には一連の流れの中で組み合わさって働きます。次の表に、要素ごとの目的と実装で検討する点を整理しました。

要素	目的	実装で検討する点
選択的開示	必要な項目だけを開示し、余分な情報を渡さない	開示範囲を絞る仕組みの設計
提示者検証	提示している人物が正当な保有者かを確認する	端末側の認証との連携
不正防止	なりすましや改ざんの検知につなげる	署名検証と失効確認の実装

あわせて、発行した資格情報を無効化する仕組みや、検証に失敗した場合の扱いをどう設計するかも、実装を任せられる案件で問われやすいポイントです。細部の仕様は案件によって異なりますが、失効や例外の扱いまで見据えて設計できるかどうかが、実装の完成度を左右します。

選択的開示の実装では、開示する項目の組み合わせによって検証側の判断が変わる場合があるため、想定される提示パターンを洗い出してテストしておくことも実装の一部です。不正防止の設計も、一度作って終わりではなく、新しい手口が明らかになるたびに検証のロジックを見直す運用が求められる場面があります。

検証の判断や同意の記録を残しておく設計も、後から見返して説明できる実装にするうえで欠かせません。

出典：デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）をもとに作成

規格や実装要素を理解したうえで、実際の案件でどの立場に関わるのかを見ていきましょう。

5. リモート・フリーランス案件でどう関わるか

発行・ウォレット・検証、それぞれの実装

デジタルクレデンシャルに関わる案件は、発行機関側のバックエンド実装、利用者が使うウォレットアプリのモバイル実装、検証者側の認証・認可基盤への組み込みという、複数の切り口に分かれます。バックエンドの認証基盤に携わってきた経験は発行や検証の実装に、モバイルアプリの開発経験はウォレット側の実装に、それぞれ生きる形です。

特定の規格をどこまで覚えているかよりも、署名と検証の流れをコードで追える経験のほうが、案件では重視されやすい傾向があります。標準規格は仕様書を確認しながら実装を進められるため、まず押さえておきたいのは暗号技術や認証まわりの基礎です。

実装を進める際は、署名や検証のロジックを単体テストで確認しながら組み立てる進め方が向いています。仕様の解釈に迷う箇所は、先にテストケースを書いて確認すると手戻りを減らせます。

リモートで関わりやすい理由

発行・ウォレット・検証のいずれの実装も、仕様書とAPI連携が中心となる作業が多く、クライアントとの要件のすり合わせをオンラインで進めやすい領域です。稼働の形は案件によって異なりますが、コードと仕様に向き合う時間が長い実装だからこそ、リモートで参画しやすい案件が見られます。まずは自分の経験に近い立場の案件から確認してみましょう。

仕様のすり合わせはチャットやドキュメント上でのやり取りが中心になりやすく、対面での確認が必須になる場面はそれほどありません。画面越しの連携で完結しやすい実装だからこそ、居住地に関わらず参画できる案件が見られます。

案件を見極めるポイント

案件を選ぶ際は、発行・ウォレット・検証のどの部分を担当するのか、そして仕様書やAPI連携が中心の作業なのかを確認しておくと、これまでの経験との相性を見極めやすくなります。

標準規格への準拠の度合いや、既存システムとの連携範囲も案件によって幅があります。これまでの実装経験に近い部分から関わり始め、規格への理解を実務の中で広げていくやり方も選べます。

案件によっては、発行機関や検証者となる既存システムの制約が先に決まっている場合もあります。そうした前提条件を早い段階で確認しておくと、実装の手戻りを避けやすくなります。

クライアントとの最初のすり合わせで、担当する範囲と検証環境の有無を確認しておくと、着手後の認識のずれを防ぎやすくなります。

6. まとめ

積み上げてきた経験を、次の案件でどう活かすか

デジタルクレデンシャルの案件は、発行機関・利用者・検証者という三者モデルと、W3C VCやISO/IEC 18013といった標準規格の基本を押さえることで、認証基盤やモバイル開発でこれまで積み上げてきた経験を新しい領域につなげられる分野です。規格の名前を覚えることよりも、署名と検証の流れを設計として理解していることのほうが、案件では評価につながります。

発行・ウォレット・検証という三つの立場のどこに関わるかによって求められる技術は変わりますが、共通して必要になるのは、標準規格を確認しながら安全な設計に落とし込む姿勢です。

読み終えたときに「なるほど」で止まらず、まずは自分の得意分野がどの立場に近いかを考えてみることが、次の案件を探す出発点になります。

まずは自分の経験がどの立場の実装に近いかを整理し、Remoguで案件の傾向を確認しながら、参画できる条件をすり合わせてみましょう。登録して自分に合う案件の条件を確かめておくことが、次の一歩になります。

7. よくある質問

認証やeKYCの経験は活きますか

認証基盤やeKYCに関わってきた経験は、署名の検証や本人確認の設計という点でデジタルクレデンシャルの実装と重なる部分があり、発行機関側や検証者側の案件で活かしやすい経験です。eKYCで培った本人確認フローの設計経験は、発行機関が本人確認書類を発行する場面や、検証者が提示者を確認する場面でそのまま役立ちます。

どんなスキルが活きますか

暗号技術や公開鍵基盤の基礎知識、API設計の経験、モバイルアプリ開発の経験など、これまでバックエンドや認証まわりで積み上げてきたスキルが幅広く活かせる領域です。加えて、失効や例外の扱いまで考慮した設計経験があると、実装の完成度を高めやすくなります。

標準規格の知識は必要ですか

W3C VCやISO/IEC 18013といった規格の細部をあらかじめすべて把握している必要はありません。案件によっては仕様書を読み進めながら実装する場面が中心となるため、規格の全体像を理解したうえで、必要な部分を都度確認していく姿勢が重要です。新しい仕様が公開される場合もあるため、案件の中で最新の資料を確認する習慣を持っておくと安心です。

モバイルやWebの経験は活きますか

利用者が使うウォレットアプリはモバイル開発の経験が、検証者側の連携画面はWeb開発の経験が、それぞれ活かせます。どちらか一方の経験しかなくても、関わりやすい立場の案件から選び、得意な領域から関わり始めて、必要に応じてもう一方の経験を補っていく進め方もできます。

案件はフルリモートでもできますか

Remogu（株式会社LASSIC運営）が扱う案件は、90%以上がフルリモート可能です⁷。デジタルクレデンシャルの実装は仕様書とコードに向き合う作業が中心となるため、リモートで参画しやすい案件が見られます。稼働のタイミングはクライアントとの協議によって調整できる案件が中心です。まずは登録して、自分の経験に合う条件を確かめてみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）
＊2 デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）
＊3 デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）
＊4 デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）
＊5 デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）
＊6 デジタル庁「令和6年度DIWアドバイザリーボード報告書」（2025年3月）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能