■1 ユビキタスIDアーキテクチャ
ユビキタスIDセンターは、ユビキタスIDアーキテクチャに基づく次世代の情報流通基盤の実現をめざしています｡ユビキタスIDアーキテクチャとは、ucode（ubiquitous code）によって識別された実世界のモノや場所から、それに関連する情報を引き出す、広域分散型の情報サービスアーキテクチャです。
●1.1 ユビキタス・コンピューティング
ユビキタスIDの背景は、「ユビキタス・コンピューティング」（Ubiquitous Computing）という、新しい情報通信技術のあり方です。ユビキタス・コンピューティングとは、小型のコンピュータやセンサを身の回りのさまざまなモノや場所に埋め込み､それらが互いに通信を行って協調処理をし、人間に役立つ環境制御や情報提供を行う技術です（図 1）。
図 1：ユビキタス・コンピューティングのイメージ
このようなユビキタス・コンピューティングを実現するために、最も重要な考え方は、状況認識（context-awareness）です。つまり、身の回りに埋め込まれた無数のコンピュータやセンサが、実世界の状況を認識し、高度な情報サービスや環境制御に役立てるのです。
ここで、実世界の状況のうち、もっともわかりやすい「状況」は、目の前にあるモノは何で、いま自分がいる場所はどこか、ということです。これらをコンピュータが自動認識できるようになると、利便性の高いサービスが可能になります。
このような状況を認識するためには、モノや場所を確実に認識する必要があります。現在の技術で、モノや場所を最も確実かつ簡単に認識する方法は、自動認識させたい対象に番号（ID: Identifier）をつけて、そのIDをコンピュータが自動認識しやすい媒体に格納してモノや場所に結びつける、ということです。たとえば、IDをバーコードとして印字し、スキャナで自動読み取りできるようにする、あるいはRFID（Radio Frequency IDentification）タグに代表される電子タグに格納し、電波で自動読み取りできるようにすることが、最も現実的です。
●1.2 ユビキタスIDアーキテクチャの機能構成
ユビキタスIDアーキテクチャは、ucodeによって識別される実世界のモノや場所から、それに関連する情報やサービスを引き出す、広域分散型のアーキテクチャです。
ユビキタスIDアーキテクチャには、2つの前提があります。第1の前提は、実世界のさまざまなモノや場所が、ucodeと呼ばれる番号によって識別される、ということです。また、このucodeを自動認識するために、ucodeを付与したモノや場所には、このucodeを格納したバーコードや電子タグ、センサなど（これらをucodeタグといいます）が埋め込まれています。
第2の前提は、21世紀のユビキタス・ネットワーク、つまり常時接続環境が整っていることを基本とする、ということです。もちろん、実世界には良好なデジタル通信環境が整備できない場所もありますので、そういう環境でも動作するためのオプションも設けています。
ユビキタスIDアーキテクチャの機能構成を図示すると、図 2のようになります。ユビキタスIDアーキテクチャは、（1）ucode、（2）ucodeタグ、（3）ユビキタス・コミュニケータ、（4）ucode解決サーバ、（5）ucode情報サーバの5つから構成されます。
図 2：ユビキタスIDアーキテクチャの機能構成
（1） ucode: 誰でも・いつでも・何にでも発行できる番号
ucodeは、実世界のモノや場所を識別するための番号です。ucodeはユビキタスIDアーキテクチャの中で、あくまでも純粋に識別番号としてのみ機能します。つまり、ucodeの番号の中に、識別対象となるモノや場所の属性が表現されていることを保証しません。もっとも、利用者の運用によっては、ucodeに識別対象の属性をエンコードしたいケースもありますので、ucodeに識別対象の属性をエンコードすることを禁止していません。
（2） ucodeタグ: タグを選ばない（Tag agnostic）
ucodeタグは、ucodeを格納するタグ（媒体）です。ユビキタスIDセンターは、タグを選びません。バーコードや二次元バーコードのような印刷タグ、パッシブ型RFIDタグのような無電源型の電子的タグ、電波ビーコン（マーカ）や赤外線ビーコン（マーカ）、アクティブRFIDのように電源を搭載して端末にIDを通知するタグなど、さまざまなタグを用いることができます。
（3） ユビキタス・コミュニケータ（Ubiquitous Communicator）: ucodeと情報を橋渡しする端末
ユビキタス・コミュニケータは、ucodeタグからucodeを取得し、このucodeに関連する情報サービスを受けて、利用者に提供するサービスを提供する端末です。
（4） ucode解決サーバ: ucodeから情報を引き出す広域分散データベース
ucode解決サーバとは、ucodeと、そのucodeに関連する情報・コンテンツ・サービスを提供するサーバ（ucode情報サーバ）との対応関係を管理する広域分散データベースサーバです。ユビキタス・コミュニケータがucode解決サーバにucodeを問い合わせると、ucode解決サーバは、そのucodeに関連する情報やサービスを提供するサーバのアドレスを返します。ucode解決サーバは、ucodeとコンテンツ位置との対応付け情報を管理する、つまり、ucodeを付与したモノや場所が構成する「現実世界」と情報システムが構成する「仮想世界」をつなぐ、ユビキタスIDアーキテクチャの基幹ノードの1つです。
目の前にあるモノや場所について、検索エンジンで調べるためにはキーワードが必要です。一方、ucode解決サーバでは、知りたいモノや場所についての知識（手かがり）がなくても、モノや場所のucodeが取得できれば情報を引き出すことができます。
（5） ucode情報サーバ: コンテンツやサービスの提供元
ucode情報サーバは、ucode解決サーバから導かれた、ucodeに関する情報やサービスを提供するサーバです。
●1.3 ucode
ucodeは、誰でも、いつでも、何にでも発行できる個体識別番号です。実世界のモノや場所はもちろん、実世界に存在しないコンテンツや情報、またより抽象的な概念に発行することもできます。ucodeは、128ビット（2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 ≒ 3.4×1038個）固定長の識別子体系です。さらに、将来の要求に応じて128ビット以上の長さのコードも定義できるように、コード長を128ビット単位で拡張できるメカニズムも用意しています。
ucodeを実世界のモノや場所に発行するとき、そのucodeはバーコードや二次元コード、RFIDタグなどのucodeタグに格納します。
ucodeは単なる識別番号です。その番号とucodeが与えられた対象の属性や意味との間に関係はありません。ユビキタスIDアーキテクチャでは、対象の属性や意味を表す情報を、データベースに格納することを基本としています。その属性や意味情報は、ucodeをキーとしてデータベースから取り出すことができます。
ucodeは識別番号ですから、発行されたucodeの唯一性（uniqueness）を保つことが不可欠です。つまり、世の中に同じucodeを付けられた対象が重複することはありません。また、ucodeの発行対象が消滅したとき、ucodeも破棄されます。後から同じucodeを再利用することはありません。発行対象が消滅したucodeは欠番となります。従って、ucodeは空間方向への唯一性だけでなく、時間軸方向への唯一性も保障します。
1.3.1 ucodeの管理構造
ucodeの発行・管理の利便性を確保するために、ucodeに図 3、図 4に示すような、管理区分や割当単位の構造を定義しています。ただし、これはあくまで管理のための構造であり、ucodeの構造と発行対象の属性や意味との関連はありません。
図 3：ucode（128bit基本長）の構造
図 4：定義済CCの値とSLDCとICのビット境界
ucodeは、バージョン（Version）、最上レベルドメインコード（Top Level Domain Code: TLDC）、クラスコード（Class Code: CC）、ドメインコード（Domain Code: DC）、識別コード（Identification Code: IC）の5つのフィールドから構成されます。
● バージョン
バージョンは、ucodeの規格バージョン番号です。現在のバージョンは，"0000"（2進数表記）です。
● 最上レベルドメインコード
ucode空間は、ドメイン（Domain）と呼ぶ部分空間に分割して管理されます。つまり、ドメインは、ucodeの管理単位となる部分空間です。ドメインは2段階構成であり、上位レベルのドメインを最上レベルドメイン（TLD：Top Level Domain）と呼びます。TLDは108ビットの固定長です。最上レベルドメインコード（TLDC: Top Level Domain Code）は、TLDを識別する番号です。
● クラスコード
クラスコード（CC: Class Code）の先頭ビットが1であるucodeは128ビット長です。このとき、CCの下位3ビットは、第2レベルドメインコードと識別コードとの境界を示します。なお、CCの先頭ビットが0であるucodeは、256ビット以上からなる拡張コードです。
● 第2レベルドメインコード
TLDの下のレベルとして、第2段階のドメインがあります。これを通常、単にドメインと呼びます。ドメイン空間は、16 bitから96 bitまで16 bit単位で6種類のサイズがあり、空間の大きさに応じて、Class A～Class Fと呼びます。第2レベルドメインコード（Second Level Domain Code: SLDC）とは、各ドメインを識別するコードです。SLDCのビット長とドメイン空間のビット長を足すと常に104 bit（固定）になります。
● 識別コード
識別コード（Identification Code: IC） とは、各ドメインの中にある識別番号本体です。
1.3.2 ucodeの特長
ucodeは、モノに付与する既存のさまざまなコード体系と比べて、以下のような特長を持っています。
- ucodeは、商品コードのように製品種別を表すのではなく、個体を識別するコードです。
EAN，UCC，JANコードといった商品コードは，ベンダー毎の商品の種類を識別するコードです。従って、2つの同じ製品には同じ商品コードが割り振られます。ところが、ucodeでは、同じ製品であっても、個々に異なる番号を発行します。
- ucodeは、モノだけでなく場所やコンテンツ、概念にも振ることができます。
モノ、場所、コンテンツなどを共通に識別できるコード体系は、ucodeしかありません。
- ucodeは応用分野や業種に依存しません。
ucodeは、例えば物流といった特定の業界だけで使うためのコード体系ではありません。ucodeは、電気製品、食品、場所、音楽コンテンツなど、応用や業種に依存せず、さまざまな対象に振ることができるコード体系です。これは、ucodeがモノや場所に対して、それら個々を識別することだけを目的としており、かつucode内部に意味を持たない番号体系だからです。従って、複数の業種や応用にまたがるサービスや物品管理、また場所とモノを同じシステムで管理するようなときには、ucodeは特に有効です。
- ucodeは意味を含まない，純粋なシリアル番号です。
モノや場所の性質や意味の情報は、ネットワークの先のサーバ上に格納されることを基本アーキテクチャとしています。こうした方式は、特にucodeが割り当てられたモノや場所の意味や性質が、時間によって刻々と変わっていくような応用に対して有効です。
例えば、道路に置かれているガードレールを考えます。工場で生産されて工事場所に流通してくるまではガードレールという製品です。それが道路に設置されると、場所の構成要素の1つにもなります。最後に、それが撤去されて破棄されるまでの間、それは廃棄物という性質をもちます。このように、製品・場所・廃棄物と、そのモノのライフサイクルに応じて意味が刻々と変わる場合、ucodeはそれを素直に識別できます。
- ucodeは、格納するタグを選びません。
ucodeはバーコード、二次元バーコード、RFID、アクティブタグなど、あらゆる種類のタグに格納することができます。従って、応用や利用環境に応じた最適なタグを選んでucodeを使うことができます。
- ucodeはセキュアです。
ucodeを扱う体系であるユビキタスIDアーキテクチャでは、ユビキタスセキュリティフレームワークであるeTRONの機能を備えています。そのため、強固なセキュリティやプライバシ情報保護を実現することができます。
●1.4 ucodeタグ
ucodeタグとは、ucodeを格納することを目的とした媒体です。
ユビキタスIDアーキテクチャでは、タグを選びません。バーコードや二次元コードのような印刷タグや、RFIDやスマートカードに代表される電子型のタグなど、さまざまな種類のタグをucodeタグとして利用することができます。これは、応用や利用環境によって、ucodeを格納するために最適なタグが異なるからです。
● コストが安いタグ
● 金属に貼っても読めるタグ
● 水分を含むモノに貼っても読めるタグ
● 読み取り距離が長い／短いタグ
● 高セキュリティであるタグ
1.4.1 ucodeタグの認定制度
ユビキタスIDセンターは、多様なucodeタグをタグからucodeを取り出す通信手段と、ucodeの格納方式やucodeの取り出し方に対するセキュリティ強度の2つの観点から分類しています。前者を「インタフェースカテゴリ」（表 1）、後者を「セキュリティクラス」（表 2）と呼びます。
表1：ucodeタグのインタフェースカテゴリによる分類
Category |
内容概要 |
0 |
印刷タグ |
1 |
パッシブ型RFIDタグ／スマートカード |
2 |
アクティブ型RFタグ（電池内蔵型） |
3 |
アクティブ型赤外線タグ（電池内蔵型） |
表2：ucodeタグのセキュリティクラスによる分類
Class |
内容概要 |
0 |
データ欠損検出機能 |
1 |
耐物理複製／偽造 |
2 |
同定防止機能 |
3 |
耐タンパ性／資源別アクセス制御機能 |
4 |
未知ノードとの安全な通信路構築機能 |
5 |
タイマを用いた資源管理機能 |
6 |
内部プログラム／セキュリティ情報の更新機能 |
ユビキタスIDセンターは、ucodeを利用するための基盤技術確立の一環として、多様なucodeタグを包括的に扱うために、ucodeタグの認定を行っています。ucodeタグの認定とは、あるタグをucodeタグとして利用することに問題がないことを確認する手続きをいいます。この手続きにより認定されたタグを「ucode認定タグ」といいます。2009年12月現在、37種類の認定タグがあります。
ucodeタグの認定を行うために、ucodeタグのインタフェースカテゴリごとに認定基準が制定されています。その基準は仕様書として公開しています。それぞれの基準は、いずれも以下に示す7つの基準に基づいています。
1. タグの種別
表 1に示したカテゴリのいずれかに当てはまらなければなりません。
2. ucodeの唯一性保証
ucodeは唯一の値である必要があります。そのため、ucodeタグはucodeの唯一性を保証しなければなりません。
3. 非ucodeタグとの識別
同一規格のタグで、ucodeタグと非ucodeタグを区別できる必要があります。これが区別できないと、タグリーダがucodeタグでないタグのIDをucodeと誤認して取得してしまいます。これはアプリケーションに取って不都合となります。
4. 無応答の原則
他のプロトコルや他の方式のタグが混在している環境では、タグは、対応していない方式でタグの読み出しを行っている間、無応答であることが望ましいです。ucodeタグとしてさまざまなタグが存在し、環境のあらゆるところにタグが埋め込まれているユビキタス・コンピューティング環境を想定すると、この点は重要です。
5. ucode取得機能の保証
タグからucodeを正しく読み取ることが保証されている必要があります。
6. インタフェースの相互運用性の保証
これは、認定タグ同士で相互に運用できるようなマルチリーダを開発する場合、インタフェース情報が必要であれば、ユビキタスIDセンターが情報を開示できることを意味しています。
7. ucodeタグの存在明示
ucodeタグがそこに存在することを、外見から容易に判断できるようにするために、ucodeマークを明示することを認定の条件としています。
■2 uID 2.0 -- ucRに基づくより豊かなユビキタス世界の実現
ユビキタスIDアーキテクチャ2.0は、これまでのユビキタスIDアーキテクチャのucode解決部分にucR（ucode Relation）と呼ぶメタ情報処理技術を導入して拡張したものです。これにより、リッチな実世界記述と、リッチな実世界記述に基づいたコンテキスト依存型（context-aware）のucode解決を実現できます。
●2.1 ucRの基本理論
実世界の状況（コンテキスト）、つまりモノや場所の間の関係を、モノや場所に付与したucode間の関係として表現するモデルをucode関係モデル（ucode Relation model: ucRモデル）といいます。ucRモデルでは、モノや場所だけでなく、「ucode間の関係」という概念もucodeで識別します。このように、関係を識別するucodeをとくに関係ucode（relation ucode）と呼びます。また、ucRモデルでは、文字列やウェブページのURL、数値など、ucodeを付与したモノや場所の属性値となる情報をatomと呼びます。
ここで、（ucode、関係ucode、ucode）または（ucode、関係ucode、atom）という3つ組をucR unitと呼びます。これが、ucRモデルの基本単位です（図 5）。また、この3つ組を、関係ucodeを述語とする文にあてはめたとき、主語にあたるucodeをsubject ucode、目的語または補語にあたるucodeをobject ucodeと呼びます。この3つ組構造は、きわめて単純ですが、実世界の状況に対する高い表現能力を持っています。
図 5：ucR unit
（例1）場所の表現
たとえば、椅子が部屋の中にあるという状況をucR unitで表現してみましょう。椅子の識別子としてucode:u1が、部屋の識別子としてucode:u2が付与されているとします。また、「含まれている」という関係を表現するために、ucode:uAが付与されているとします。このとき「椅子が部屋の中にある」という状況は、2つのucode:u1とu2を関係ucode:uAでつないだものになります（図 6）。
図 6：ucR unitの例（1）
（例2）製品情報
コンピュータ製品があり、この製品名称が「ユビキタスPC」、説明書がhttp://www.example.org/に掲載されているとしましょう。
ここで、コンピュータ製品を識別するためのucodeとしてu3を付与し、「名称」という関係にuBというucodeを、「説明書URL」という関係にuCというucodeを付与したとします。このとき、「この製品の名称はユビキタスPCであり、その説明書はhttp://www.example.org/にある」という状況を表現するucR unitは図 7のようになります。
図 7：ucR unitの例（2）
図 6の例で、この部屋はABCビルの6階にあったとします。そうすると、この部屋は「ビルの6階」に含まれていて、ビルの6階は「ABCビル」に含まれています。これらはそれぞれucR unitで表現することができます。さらに部屋やビルの名称、住所などを結びつけることができます。このように、複数のucodeとatomが関係ucodeによって結びつけられた有向グラフをucode関係グラフ（ucode Relation Graph: ucRグラフ）と呼びます。なお、atomはucRグラフの葉にのみ現れます。
図 8：ucR Graphの例
ucRでは、あらかじめデータ構造を定義する必要はありません。ucR unitを追加したり削除したりすることにより、ucodeに関連する情報を自在に更新させることができます。従って、ある場所に対して新たな種類のサービスが追加された、逆にある種のサービスが廃止された、複数のサービスが連携を始めた、あるいは企業間の合併がおこり、あるサービスを受けていたユーザが別のサービスの顧客としてそのまま引き継がれることになった、など、頻繁に変化するコンテキストにも対応することができます。
●2.2 ucRデータベースとucode解決
ucode関係データベース（ucode Relation Database: ucRデータベース）とは、ucRグラフを管理するデータベースです。従って、ucRデータベースには、ucodeを付与した個々のモノや場所に関する情報やコンテンツの参照先に加えて、それぞれのucode間の関係という情報も管理しています。
ucRモデルでのucode解決は、ucRグラフに基づいて、ucodeから状況に応じた適切な情報を特定することをいいます。たとえば、図 8のようなucRグラフが格納されているucRデータベースに対しては、ucode解決によって場所の緯度・経度情報や場所間の接続・包含関係を問い合わせることができます。
ucRモデルでのucode解決プロトコルでは、ucRデータベースに対してucR unitやucRグラフを取得するコマンドのほか、グラフのパターンマッチを行うコマンドも提供されています。従って、グラフの構造がわかっている場合は、ucRデータベースから効率的に情報を取得することもできます。
●2.3 ucRスキーマとucR SOAP API
先に述べたとおり、ucRは強力な情報表現と、それに対する豊富なパターンの検索が可能です。関係データベースのようにデータスキーマを決めるものではないため、一個一個個別に異なる性質のものを表現することにも適しています。
ところが、すべての情報がこのように個別化されているとは限りません。むしろ、同じ構造の情報が繰り返して大量に現れるケースの方が多いといえます。たとえば、図 9は空間情報サービスのアプリケーションで使われるucRグラフの例です。図中の枠で括った部分に同じような構造が現れています。すなわち、施設を表すノードから名前、キーワード、値段、住所、最寄りバス停という関係ucodeで接続されるucR unitがあり、最寄りのバス停のucodeからはタグ、名前という関係ucodeで接続されるucR unitがある、という構造が、繰り返し現れています。
図 9：空間情報サービスで頻繁に現れるucRグラフ構造
（注意：このグラフでは、読みやすくするためにucode部分を文字で表現している）
ucRスキーマ（ucR Schema）とは、このように繰り返し現れる構造を抽象化したものです。ucRスキーマは、抽象化されたucRグラフの各ノードに変数を割り当てた構造です（図 10）。ucRスキーマを用いることで、ucRグラフの構造を意識することなく、つまりグラフ構造に関する知識を必要とせずに問い合わせができます。
図 10 ucRスキーマの例
このucRスキーマは、一見すると関係データベースのスキーマと似ていますが、重要な相違点があります。関係データベースのスキーマは、挿入されるデータの構造をあらかじめ決めておくものです。従って、データベース内に保存されるデータの構造は基本的にデータベースのスキーマに従わなければなりません。一方、ucRスキーマは、ucRグラフのパターンを予め定義しておくものです。従って、ucRデータベース内のデータの構造をucRスキーマに従わせる必要はありません。そのため、ucRモデルの柔軟性、汎用性を担保しつつ、アプリケーションから抽象度が高く利用しやすい問い合わせを記述することができます。
ucR SOAP APIは、このようなucRスキーマを利用してucRデータベースにアクセスするための、SOAP 1.2準拠のAPIです。このAPIを利用すると、ucRスキーマで定義された変数名を用いて、ucRデータベースに対して情報の登録・更新・検索ができます。また、ucRスキーマを複数用意して適宜切りかえることもでき、他のアプリケーションとのマッシュアップも可能です。
