複数コード体系相互運用プラットフォーム

この記事のURLhttp://japan.internet.com/public/technology/20070411/5.html

■ 概要

平成18年度、経済産業省は電子タグの事業のひとつとして「マルチコード相互運用実証実験事業」を公募した。筆者の所属する組織はこの事業の委託を受け、東京大学大学院情報学環/ユビキタス ID センター（ucode）や慶應義塾大学 SFC 研究所/Auto-ID Lab. Japan（EPC）と共に実証実験を行った[1]。本稿ではこの事業で構築した「マルチコード相互運用プラットフォーム」について解説する。

■ マルチコード
個体識別コードには、EPC、ucode、そして企業内で使われる独自コードなど、さまざまなコード体系がある。今後これらの複数コード体系(以下、「マルチコード」)が混在する環境では、コード体系を使い分けるための混乱が予想される。

電子タグ導入を検討する企業にしてみれば、最終的にどのコード体系を選べばよいのか、標準化動向や技術動向が気になり、電子タグ導入に逡巡することがありがちだ。コード体系は異なるが、要するに「相互運用」ができれば、「どのコード体系を選んでも、後でどうにでもできますよ」という安心感を持ってもらうことができる。これが今回の実験の目的である。

個体識別コードが複数のコード体系になったのには訳がある。製品識別は「POS システムを使う小売業からの要請」があったため、小売業界を中心に製品識別コードの統一の必要性に共通認識が得られ標準化は順調に進んだ。JAN コードの確立、そして国際的な規格の統一が図られた[2]。

個体識別については、個体識別のニーズについての発想がコード体系ごとにそれぞれ異なる。

【EPC】
EPCglobal で標準化を進めているコード体系。これは JAN コード、EAN/UCC コードという流通用の製品識別コードの流れを汲み、さらにそれを個体識別に発展させようという発想。製品識別コードは GTIN（Global Trade Item Number）に統一される。それに個体ごとのシリアルナンバーをつけたものが SGTIN[3]である。つまり既存の識別コードを個体識別に使えるように発展させる、という発想である。

【ucode】[4]
ユビキタス ID アーキテクチャでは、実世界のさまざまなモノに、個体識別コードとしての ucode が埋め込まれることを前提としている。発想はいつでもどこでもコンピューティングから由来しており、実世界を認識するために個体識別が必要だというところにある。

このため、EPC と違い、コードの内容に意味を持たない。EPC では国番号、発行企業、商品アイテム番号、などの意味がコードの内容に含まれているが、ucode はまったく意味を持たないコードであり、ucode タグにはモノを識別する ID（ユビキタス ID）だけを格納し、容量の範囲内で付加的な属性情報を格納している。ucode タグに格納できない情報は、ネットワークの先のデータベースに格納される。

【社内独自コード】
これは発想も何も、千差万別である。企業内で備品管理をしたいときには備品個体を管理するためのコードを設計するし、マニュファクチャリング オートメーションで個々のラインの識別やユニット個体を識別するためにはそれぞれの目的にあわせてコードを設計する。

また、先行して IC タグを業務に導入している企業では、タグメーカーがタグに書き込んだ ID（Tag Identifier：TID）を個体識別に使っている場合もある。

■ 相互運用のための仕組み
マルチコード相互運用のために、「マルチコード相互運用プラットフォーム」（以下「プラットフォーム」）を構築し、実用可能性を検証した。図はプラットフォームの概念図である。IC タグなどを読み込んだという「イベント」が発生してから業務アプリケーションがその情報を使用するまでの過程を、アプリケーションがコード体系を意識しなくてもよいように仮想化した。

それぞれのコード体系ごとにリーダが読み取る情報は違い、コードの情報がどこにあるかを解決する「名前解決サーバー」、コードの意味を返す「情報サーバー」が別々に存在する。

今回構築されたプラットフォームは名前解決や情報サーバーへの問い合わせ、イベント情報への問い合わせはコード体系の違いを無視できるようになっている。

少なくとも情報システム空間内では、今回設計された MCI（Multi Code Identifier）を用いてコード体系の区別をし、どの名前解決サーバーに、どの情報サーバーに問い合わせるか、を自動的にプラットフォームが振り分ける。

海外でもマルチコードに関する取組みが行われているが、国際標準規格になったコードを識別する点に注力している。標準化されたコードの区別には有力な方法だが、独自コードを区別するにはまだひと工夫要りそうだ。その点、MCI による区別は独自コードにも適用できる点が優れていると思われる。



■ 公開実証実験
今回は2006年11月22日から23日までの ORF（Open Research Forum：慶應義塾大学 SFC 研究所主催）、および12月5日から6日までの TRONSHOW（ユビキタス ID センターなどによる実行委員会主催）で公開実証実験が行われた。

実験協力者に IC タグを埋め込んだカードを持ってもらい、IC タグリーダーが検知すると、どの業種のヒトがどの場所に何人くらいいるかを表示するアプリケーション（倉庫内での部材位置管理をイメージ）、希望するヒトの携帯メールに場所に関する情報を配信するアプリケーション（業務ハンディターミナルへの自動情報配信をイメージ）が展示された。

大勢の実験参加者のトラフィックを捌き切れることを実証し、プラットフォームが実用に耐え得ることが検証された。さらに、直前での追加アプリケーションの要望にも応え得たなど、機能的汎用性も検証された。

■ イベントデータベース
さて、プラットフォームはイベントを蓄積するデータベースを持っている。このデータベースには大量のイベントデータが蓄積された。これによってスタンプラリーで抽選する際に20か所すべてを回ったかどうかを調べる、というような使い方もできた。

また、イベントに付随する属性は、ヒトモノ識別 ID、場所識別 ID、タイムスタンプという基本情報に加え、ORF の UHF リーダでは、ヒトの「入、出、滞留」という属性を持つように設計された。

直前に、ポイントラリーのアンケートデータをイベントと一緒に格納したいという追加要求があった。このような、イベントによって種類の違う属性のダイナミックな追加は RDB では困難であり、半構造化 DB（Semi-Structured Database：SSDB）の必要性も感じさせた。

■ おわりに
IT システムが部門の壁や企業の壁を越えられないということはすでにいろいろなところでいわれている。本当に社会の中に IT が入っていくには、複数の、標準/コンセプト/アーキテクチャを乗り越えて、相互の連携を進めなければならない。

今回「相互運用」に取組んだことは、今後他の相互運用に取組む際の知見を得る意味があった。今後も「社会プラットフォーム」という観点から取組みを続けていきたい。プラットフォームは、こちらで OSS として公開されている。

セキュリティ、MCI に対するコンセンサスの形成などの課題が明確化できたことは今回の成果であり、イベントデータベースがこのプラットフォームの中で検証されたことも大きな成果である。今後、膨大なイベントデータをどう処理し、有効活用していくかも含めて、実用化への取組みを進めていきたい。

[1] 報告書は経済産業省から公開される予定である。
[2]（財）流通システム開発センター：JAN コード（国際的には EAN コード）の UPC コード（北米）への乗り入れなどの経緯が記述されている。
[3] EPCglobal, "EPCglobal Tag Data Standards Version 1.3, Ratified Specification", March 8, 2006 [4] ユビキタス ID センター

右近 豊
日本ユニシス株式会社
先端技術部
上席研究員

提供:日本ユニシス