Open Badge v2 と v3 を徹底比較：今どちらの仕様を選ぶべきか？

2026 年にクレデンシャル発行のプログラムを立ち上げようとすると、調査を始めて 1 時間もしないうちにこの疑問にぶつかります。Open Badge v2.0 を発行すべきか、それとも新しい v3.0 にすべきか。正直な答えは「あなたのクレデンシャルを誰が読むかによる」ですが、金曜日までに決めなければならない立場からすると、これでは納得できないはずです。そこで、この 2 つの仕様の間で実際に何が変わったのか、今日どこがそれぞれをサポートしているのか、そして今すぐほとんどの発行者がどちらを採用すべきかを見ていきます。

Open Badge v2.0 とは実際どういうものか

Open Badge v2.0 は 1EdTech（旧 IMS Global）による仕様で、2017 年以来デジタルバッジの基盤であり続けています。JSON-LD の上に構築されており、互いにリンクした 3 つのオブジェクトを中心に構成されています。

• IssuerOrg —— 誰がクレデンシャルを発行したか（名前、URL、メール、ロゴ）
• BadgeClass —— クレデンシャルの種類そのもの（名前、説明、基準、画像）
• Assertion —— 特定の受領者への具体的な授与記録（受領者の識別情報、issuedOn 日付、証跡、検証方法）

受領者の Assertion は BadgeClass を指し、BadgeClass はさらに IssuerOrg を指します。検証方法は 2 通りあります。hosted（検証者が安定した URL から Assertion の JSON をライブで取得し、そのドメインを信頼する方式）と、signed（Assertion が JWS 署名を持ち、検証者が発行者の公開鍵と照合する方式）です。badges.ninja を含むほとんどのプラットフォームは、デフォルトで hosted 検証を採用し、signed をオプションとして提供しています。hosted の方が実装がシンプルで、人間の目でも確認しやすいからです。

以下は GET /awards/{id} の呼び出しで返ってくるような、簡略化した v2.0 の Assertion です。

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://badges.ninja/certify-badge/award/9f2a1c...",
  "recipient": {
    "type": "email",
    "hashed": true,
    "salt": "a1b2c3",
    "identity": "sha256$8f14e45..."
  },
  "badge": "https://badges.ninja/certify-badge/badge/7d3e...",
  "issuedOn": "2026-08-01T00:00:00Z",
  "verification": { "type": "hosted" }
}

この構造こそが、v2.0 が事実上の標準になった理由です。半日もあれば実装できるほどシンプルで、バッジデータを扱うほぼすべての利用者が当然のように期待する形式でもあります。

v2.0 における hosted 検証と signed 検証

v2.0 内部にあるこの 2 つの検証モードの違いを理解しておく価値があります。というのも、「v2.0 は v3.0 より安全性が低い」という話と、「hosted 検証は signed 検証より安全性が低い」という話を、人々はよく混同するからです。これらは別の軸の話です。

• Hosted —— verification.type が "hosted" で、Assertion の id はライブの URL です。検証者はその URL を取得し、レスポンスが一致するかを確認します。信頼の根拠は、そのドメインを支配しているという事実にあります（たとえば badges.ninja/certify-badge/award/... に公開できるのは badges.ninja だけです）。多くの一般向け検証ページでこの方式が使われるのは、人間がリンクをクリックするだけで確認できるからです。
• Signed —— verification.type が "signed" で、Assertion は payload 全体を対象とした JWS 署名を持つ（または参照する）形になります。検証者は発行者の公開鍵を解決し、どの URL にもアクセスできるかどうかとは無関係に署名を検証します。この考え方は v3.0 のモデルにより近いものですが、DID のレイヤーは持ちません。

Node での最小限の signed 検証は、次のようになります。

import { jwtVerify, importJWK } from 'jose';

const publicKey = await importJWK(issuerJwk, 'RS256');
const { payload } = await jwtVerify(assertionJws, publicKey);
// payload now contains the verified Assertion claims

自社の API がメンテナンスでダウンした後もクレデンシャルの検証可能性を維持したいというニーズがあるなら、signed 方式の v2.0 だけで、DID を採用しなくても v3.0 が持つ耐久性のメリットの大部分を得られます。

Open Badge v3.0 で何が変わるのか

Open Badge v3.0 は W3C Verifiable Credentials（VC）Data Model の上に構築された書き直しであり、v2.0 の JSON-LD 構造を段階的に更新したものではありません。実務上重要な違いは次のとおりです。

• デフォルトで暗号署名される。 すべての v3.0 クレデンシャルは署名済みの VC です。「hosted、URL を信頼する」というフォールバックは存在しません。検証は常に数学的なものであり、ドメインベースではありません。
• DID ベースの発行者アイデンティティ。 URL とメールを持つ IssuerOrg オブジェクトの代わりに、発行者は分散型識別子（DID）で識別され、それが公開鍵ドキュメントに解決されます。
• Comprehensive Learner Record（CLR）2.0 との整合。 v3.0 は CLR との相互運用を前提に設計されているため、1 つのクレデンシャルが達成データに加え、CLR の利用者が期待するような構造化された成績情報の詳細（コンピテンシー、評価結果、コース・学期のコンテキスト）を運べます。
• デジタルウォレットとの互換性。 v3.0 のクレデンシャルは標準的な W3C VC であるため、運転免許証やワクチン接種証明書と同じように、ウェブページに表示するだけでなく、アイデンティティウォレットに保管できます。

要するに、v2.0 が答えるのは「人間、あるいは単純なスクリプトがこのクレデンシャルを検証できるか」という問いであり、v3.0 が答えるのは「このクレデンシャルが、ウォレット・DID・正式な学習記録といった、より広い検証可能クレデンシャルのエコシステムと相互運用できるか」という問いです。

両者の比較

既存の基盤がいまだに v2.0 で動いている理由

ここが、ほとんどのプログラムにとって判断の決め手になる部分です。受領者が本当にクレデンシャルを表示したい場所は、今も v2.0 を前提としています。 LinkedIn の Add to Profile フロー、Credly、Badgr、そして大多数の応募者追跡システム（ATS）連携は、v2.0 の Assertion/BadgeClass 構造をパースします。「受領者が LinkedIn に投稿でき、採用担当者がクリックして検証できる」ことが目標なら、v2.0 は仕方なく使い続けているレガシー形式ではなく、今のエコシステムが実際に話している言語そのものです。

このテンションについては、受領者側の視点から LinkedIn Skill Assessments vs Open Badges でも取り上げました。バッジの価値の多くは、採用担当者や同僚がすでに見ている場所にどれだけ簡単に組み込めるかで決まりますが、今日それは圧倒的に v2.0 形式のインフラです。

v3.0 が本当に意味を持つケース

v3.0 は単なる誇大宣伝ではなく、特定のプログラムにとっては実際の課題を解決します。

• CLR の義務を負う大学や発行者。 正式な成績証明システムと並行して発行している場合、あるいは州や地域の教育機関が CLR 2.0 互換の出力を要求している場合、v3.0 に組み込まれた整合性があれば、v2.0 の Assertion に CLR のフィールドを無理に追加せずに済みます。
• デジタルウォレットへの保管を目指すプログラム。 受領者がウェブページに表示するだけでなく、ウォレットアプリにクレデンシャルを保管する必要がある場合、そこにネイティブで対応できるのは W3C VC、つまり v3.0 だけです。
• DID ベースの信頼による発行者間のクレデンシャル交換。 発行者のアイデンティティが「この URL を信頼する」ではなく暗号的にポータブルである必要があるネットワークを構築、あるいは参加する場合、DID こそが適切なプリミティブです。

2026 年の研修プログラム、ブートキャンプ、あるいは職能開発の発行者にとって、これらはいずれもよくあるケースではありません。CLR や W3C VC を名指しで要求するコンプライアンスや相互運用性の要件を持つ機関にとっては、よくあるケースです。

簡略化した v3.0 のクレデンシャルを見ると、その中身、つまり達成データが概念的には同じ授与であっても、封筒の形がいかに違うかがわかります。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": { "id": "did:web:issuer.example.edu" },
  "credentialSubject": {
    "type": "AchievementSubject",
    "achievement": { "type": "Achievement", "name": "Developer Associate" }
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022" }
}

issuer フィールドが URL ではなく DID であること、そしてドキュメント全体が verification へのポインタではなく proof ブロックを持っていることに注目してください。これが、先ほど触れた DID の解決と VC 署名ツールというものです。実際のエンジニアリング作業であり、下流に消費するものが何もなければ、その作業は無駄になってしまいます。

よくある誤解を整理する

• 「v3.0 の方が安全」。 必ずしもそうではありません。signed の v2.0 も v3.0 も、どちらも暗号による検証に依存しています。v3.0 の強みは標準化された アイデンティティ（DID）と ウォレット の相互運用性であって、signed の v2.0 に対するセキュリティ面での優位性ではありません。
• 「v2.0 は非推奨」。 そうではありません。1EdTech は両方の仕様をメンテナンスし続けており、発行者が日々実際に使っているプラットフォームや連携が参照しているのは、今も v2.0 です。
• 「プログラム全体でどちらか 1 つを選ばなければならない」。 そんなことはありません。発行者が一般利用向けに v2.0 を公開しつつ、それを要求する特定のパートナー連携のために v3.0 出力を追加することを妨げるものは何もありません。基になる授与データ自体は変わらず、変わるのは表現形式だけです。

移行の進め方（そして、なぜ永久にどちらかを選ぶ必要がないのか）

ほとんどすべての発行者にとって現実的な進め方はこうです。今は v2.0 を出しておき、v3.0 は置き換えではなく、特定の下流の利用者から実際に求められたときに追加するもの、として扱う。 これがうまく機能する理由はいくつかあります。

1. 後から v3.0 対応を追加するときも、BadgeClass や Assertion の ID を変更する必要はありません。既存の受領者のクレデンシャルを移行するのではなく、同じ基になる授与に対して、形の異なる 2 つ目の表現を追加しているだけだからです。
2. v2.0 しか理解しない検証者は、これまでどおり問題なく動き続けます。
3. 具体的な要件が出てくる前から DID インフラや VC 署名パイプラインを構築せずに済みます。

これは badges.ninja が社内で使っているのとまったく同じロジックです。あらゆる授与は Open Badge v2.0 の形で出力されます —— JSON-LD、安定した /certify-badge/award/{guid} URL での hosted 検証、そして標準で LinkedIn の Add to Profile にすぐ使える状態です。これで、発行者が実際に求められている内容の圧倒的多数をカバーできるからです。もしプログラムが後から特定の機関パートナー向けに v3.0/CLR 出力を必要とするなら、それはすでに機能している v2.0 パイプラインの上に加える、範囲の限定された追加作業であり、作り直しではありません。

この順序には、もう 1 つ気づきにくいリスクを避けるという効果もあります。それは、パートナーが実際にどの DID メソッドを期待しているかを知る前に、DID インフラに先にコミットしてしまうリスクです。VC のエコシステムはまだ単一の DID メソッドに収束しておらず、did:web、did:key、そして台帳に紐づいた各種メソッドが実際に並存しています。パイロットパートナー向けに間違ったものを選んでしまうと、後で発行者アイデンティティの作業をやり直すことになります。名指しの要件が出てくるまで待てば、実際に何を構築する前に、自分に必要なメソッドがどれかを見極められます。

自分のプログラムのための簡単なチェック

v3.0 にエンジニアリングの時間を投じる前に、この 3 つの質問を自分に投げかけてみてください。

• 雇用主の ATS、免許を発行する機関、パートナー機関など、クレデンシャルの利用者の中に、CLR 2.0 や W3C VC の出力を明確に要求している相手はいますか？ いなければ、v2.0 で十分です。
• 受領者は、ウェブのプロフィールや LinkedIn だけでなく、デジタルウォレットアプリにこのクレデンシャルを保管する必要がありますか？ なければ、v2.0 で十分です。
• URL ベースの hosted 検証では本当に不十分な、発行者間の信頼インフラを構築していますか？ そうでなければ、v2.0 で十分です。

3 つとも「いいえ」だったなら、2026 年に v2.0 を出しているからといって遅れているわけではありません。むしろ、実際にそれを消費しているエコシステムに仕様を合わせているということです。「v3 の方が新しいから」という漠然とした感覚ではなく、特定のパートナーやコンプライアンス要件が名指しで v3.0 を求めてきたときに、改めてこの問いを見直しましょう。

バッジの検証データが、より古い非標準のクレデンシャル形式と比べてどう優れているかについては、Blockchain Certificates vs Open Badges で別の角度から検証性とポータビリティのトレードオフを掘り下げていますので、あわせてご覧ください。

---

最初の検証可能なクレデンシャルを発行する準備はできましたか？ badges.ninja で無料で始める —— ビジュアルデザイナー、公開検証ページ、PDF 証明書、Open Badge v2.0 出力に対応。クレジットカードは不要です。