単にまとめただけです。 あ、Type 3 Tagのヘッダ説明は追加しました。

2. おじいちゃんは
どんなNDEFが好き？
やっぱり
Short Record
かな
FeliCa Lite Short Recordなら
メモリの少ないNFCタグでも
MIFARE UL
十分対応できます！
第１章 Short Recordって？
そもそも、Short Record ってなんなの？
第２章 絵でわかる！ Short Recordの読み方
実際に Short Record NDEF を読んでみよう
Appendix Shortじゃない方は、いるの？

3. 月刊 NDEF 2013 年 1, 2, 3 月号
第１章 Short Recordって？
NDEF NDEF の Short Record とはどういったものであろうか。
基本を振り返ろう。
Short Record の NDEF を見る
今回の特集で見ていく、 Short Record の NDEF レコード構成を Fig.1-1 に示す。
この場合、 SR は 1 となる。
b7 b6 b5 b4 b3 b2 b1 b0
MB ME CF SR IL TNF
普通のNDEFと
TYPE LENGTH 何が違うのかしら？
PAYLOAD LENGTH
ID LENGTH
TYPE
ID
PAYLOAD
Fig. 1-1 Short Record の NDEF レコード(SR=1)
これに対して、 Short Record ではない NDEF レコード構成を Fig.1-2 に示す。
この場合、 SR は 0 となる。
PAYLOAD b7 b6 b5 b4 b3 b2 b1 b0
LENGTHが
MB ME CF SR IL TNF
多いんだね！
TYPE LENGTH
PAYLOAD LENGTH 3
PAYLOAD LENGTH 2
PAYLOAD LENGTH 1
PAYLOAD LENGTH 0
ID LENGTH
TYPE
ID
PAYLOAD
Fig. 1-2 Short Record ではない NDEF レコード(SR=0)
大きな違いは PAYLOAD LENGTH で、 Short Record では 1 byte 分なのに対し、そうではない場合
は byte 分確保されている。
すなわち Short Record とは、ペイロード長が 255 byte までの NDEF レコードなのである。
-1-

4. 月刊 NDEF 2013 年 1, 2, 3 月号
第２章 絵でわかる！
NDEF
Short Recordの読み方
最初の 1 byte ですべてがわかる
NDEF レコードの 1 行目には、そのレコードを読むための情報がすべて書かれている。
MB ME CF SR IL TNF
Fig. 2-1 まず 1 行目を読み取れ
MB (Message Begin)
この NDEF レコードが、一連の NDEF メッセージの先頭かどうかを示すビット。
先頭であれば 1 、そうでなければ 0 となっている。
「一連の NDEF メッセージ」としたのは、 NDEF レコードのペイロードとして入れ子となった
NDEF メッセージを含む場合があるからである。例えば Smart Poster の場合、全体としては
「 Smart Poster 」の NDEF レコード 1 つを含んだ NDEF メッセージが 1 つしかない(NDEF メ
ッセージは 1 つしか含まない仕様)。しかし Smart Poster の NDEF レコードのペイロードに
は、 URI や TEXT などの複数 NDEF レコードを含んだ NDEF メッセージを持つ。
NDEF メッセージ
NDEF レコード Smart Poster(MB=1, ME=1)
NDEF メッセージ
入れ子だニャ
NDEF レコード URI (MB=1)
"http://～"
NDEF レコード TEXT (ME=1)
"○○ blog"
Fig. 2-2 入れ子となった NDEF メッセージ
ME (Message End)
MB の逆で、 NDEF メッセージの末尾であれば 1 を、そうでなければ 0 となっている。
-2-

5. 月刊 NDEF 2013 年 1, 2, 3 月号
CF (Chunk Flag)
chunk of a payload で「ペイロードの塊」となるが、ここでは分割されたペイロード、という意味。大きな
ペイロードを持つ NDEF メッセージを複数に分割した場合に使う。
分割していないときは、 0 。
ストリーミングのような目的で分割しないこと(NFC タグではできないが、携帯電話同士が NDEF デー
タを交換する場合には、やろうと思えばやれるため)。 HTTP/1.1(RFC2616)のような意味で使うため
に設けているとのこと。
通常の使用であれば、 0 と考えていいだろう。
SR (Short Record)
ここが 1 の場合、この NDEF レコードは Short Record ということになる。
NDEF として使えるメモリは、 FeliCa Lite で 208 byte(14 のユーザブロックのうち、先頭の 1 ブロック
は Type 3 Tag の属性情報として使う)、 MIFARE Ultralight で 48 byte となっていて、 256 byte 以
上のユーザメモリを持たない NFC タグも多い。
IL (ID LENGTH 有無)
ここが 1 の場合、 ID LENGTH フィールドが存在する。 0 の場合は存在しない。
よく使われる NDEF では、 ID を使わないことが多い。 IL=0 とすることで 1 byte の ID LENGTH フィ
ールドを削除でき、 PAYLOAD として使うことができるようになる。
TNF (Type Name Format)
NDEF レコードのタイプが記載されている。
よく使われるのは、 well-known 、 media-type 、 URI であろう。 Android アプリでは external type も
使用されるようである。
ここまで解析できると、それ以降のデータが解析できるようになる。
もう少しだよ
-3-

6. 月刊 NDEF 2013 年 1, 2, 3 月号
LENGTH を把握する
ここまでで、この NDEF レコードについて以下の情報がわかっている。
・NDEF メッセージの先頭かどうか
・NDEF メッセージの末尾かどうか
・複数に分割されているかどうか(今回は分割無ししか考えない)
・Short Record かどうか(今回は Short Record の場合)
・ID LENGTH があるかどうか
・NDEF レコードタイプは何か
TYPE LENGTH
PAYLOAD LENGTH
ID LENGTH (IL=1 の 場 合 )
Fig. 2-3 LENGTH が 3 つ
LENGTHが0だと
フィールドが隠れるぞ
LENGTH フィールドが続くが、注意するのは以下の２点である。
・LENGTH は 0 の場合もある
・ID LENGTH は IL=1 の場合しか存在しない
IL=0 の場合は、 ID LENGTH フィールドも ID フィールドも存在しない。
それだけでなく、例えば TYPE LENGTH が 0 の場合には、 TYPE フィールドも
存在しないようになる。
極端な場合、 TNF=Empty では、 TYPE LENGTH=0 、 PAYLOAD LENGTH=0 、 IL=0 のため、全
部で byte しかないことになる。
各フィールドを読む
ここまでで、残りを読むための情報がわかっている。
・TYPE LENGTH はいくつか(フィールドが存在するか)
・PAYLOAD LENGTH はいくつか(フィールドが存在するか)
・ID LENGTH はいくつか(フィールドが存在するか)
TYPE, PAYLOAD, ID は、 LENGTH が 0 かどうかで読むかどうかを決めるようにしておくとよいだろ
う(IL=1 としておきながら、 ID LENGTH が 0 という可能性もあるので)。
これで読み込み完了である。
あとは TNF や TYPE によってペイロードを解析することになる。
読めなかった子は
いねぇがぁぁ！
-4-

7. 月刊 NDEF 2013 年 1, 2, 3 月号
Appendix Shortじゃない方は、いるの？
今回の特集では、 NDEF の Short Record について見ていった。
実際に市販されている NFC カードを見た際、メモリ容量が 256 byte 以上あるものはほとんどない。
少なくともそれらのカードについては、 Short Record ではない NDEF メッセージというのはメモリの無
駄でしかない。少しでも多くの情報を載せたいのであれば、 SR=1 、 IL=0 としてペイロードの容量を
稼ぐべきであろう。これだけで byte 多くなるのだ。
では、 Short ではない NDEF レコードが必要となるのはどういう場合だろう
か？ もちろん 256 byte 未満の NFC カードであっても Short ではない
NDEF レコードを使うことは可能であるが、ここでは必要性だけを考えること
にする。
少しでも稼ごう
まず、ペイロードが 256 byte 以上存在する、ということになる。
もちろんそれは、 NFC カードが 256 byte 以上の容量を持つということでもある。
よく使う NDEF のレコードタイプでは、それほど大きなデータを必要とすることが少ないのではないだ
ろうか。
URI は長くなりがちではあるが、そもそもそういう長い URI を NDEF にするような運用はそれほどな
いのではなかろうか。
私は、今のところ NFC カードは「高価な」扱いだと思っているので、ちょっと検索した URI を入れるより
も、「うちのブログです」のような URI を入れることの方が多いのではなかろうか。
市販で入手しやすい大きな容量の NFC カードが、 FeliCa Lite や MIFARE Ultralight C くらいで、そ
れらの容量が 256 byte を超えていないことを考えると、今のところではあるが Short Record よりも
大きなデータがまだ必要になっていない、ということではないかと考えている。
とはいえ、フロッピーディスクだってハードディスクだって、小さな容量からどん
どんと大容量化が進んでいった。 NFC もその道をたどらないとは限らない。
まだ NFC も一般用途として広まりだしてから歴史が浅いので、どういう方向に
進んでいくかわからない。
現在の状況だけですべてを判断するのは危険だ。
NFC を愛する我々としては、どのような進化になったとしても見守っていきたいところである。
-5-

8. 月刊 NDEF 2013 年 1, 2, 3 月号
おにぎりとType2、
どっちが好き？
どっちも好き！
今月のメニューはこちらです！
第１章 Type 2 Tagの基本
何がどうなったら Type 2 Tag なんだろう？
第２章 Type 2 Tagを読もう
実際に Type 2 Tag の NDEF データを読んでみよう
Appendix MIFARE? Mifare? どっち？？
-6-

9. 月刊 NDEF 2013 年 1, 2, 3 月号
第１章 Type 2 Tagの基本
Tag Type 2 Tag は、そもそもどういうものだっただろうか。
基本をおさらいしよう。
NFC Forum の定義
「 Type 2 Tag 」という呼び名は、 NFC Forum が付けた名前で、 ISO/IEC などの機関が決めた名前
ではない。
Platform
NFC Forum 仕様書「 Digital Protocol 1.0 」(NFCForum-TS-DigitalProtocol-1.0)では「 Type 2 Tag
Platform 」として定義されている。
無線の方式(Technology)として、 NFC-A を使用している。 106kbps で無線通信を行うのだが、「 A
と B と F があって、その中の A 」くらいで十分だろう。
Operation
NFC Forum 仕様書「 Type 2 Tag Operation Specification 」(NFCForum-TS-Type-2-Tag_1.1)に
扱うときの詳細が書かれている。
・メモリ構造
・ユーザメモリ部の使い方
・無線で読み書きするときのコマンド
・使用例
■メモリ構造
Static Memory Structure と Dynamic Memory Structure があるが、これは NXP の製品である
「 MIFARE Ultralight 」(64 byte)と「 MIFARE Ultralight C 」(192 byte)の違いだと思ってよいだろう。
64 byte のメモリ構造が Static Memory Structure で、それより大きいものが Dynamic Memory
Structure となっている。
違いは、 Dynamic Memory Structure の場合はユーザメモリ領域の次に拡張領域があるということ
だ(Fig.1-1)。
とりあえず使ってみるのであれば、あまり細かいことは
気にしなくてよいだろう。
細かいことは
忘れてしまえ
-7-

10. 月刊 NDEF 2013 年 1, 2, 3 月号
Block 0 1 2 3
メモリが64 byteなら
0
15ブロックまでよ
1 UID / Internal
2 Lock bytes
3 Capability Container
4 ～ 15 Data Area
16 ～ n Data Area
n+1 ～ Lock / Reserved
Fig. 1-1 メモリ構造
■ユーザメモリ部の使い方
ユーザメモリ(Fig. 1-1 の「 Data Area 」)は、単なるメモリなので、ユーザが好きなように使ってよい。
ただ、そうすると互換性がないので、アプリごとに違ったフォーマットを生みだしてしまう。 NFC Forum
は標準化を行おうとしているので、メモリの使い方に決めごとを作っている。
Type 2 Tag の場合、メモリを TLV 形式(Type 、 Length 、 Value)で使う。
Type (1 byte) Length (1 byte) Value (Length)
Fig. 1-2 TLV 形式
■無線で読み書きするときのコマンド
ここまでの話は、すべて NFC タグに読み書きできる前提で進められた。
では、どうやって NFC タグに読み書きするかというと、 Technology 「 NFC-A 」方式で NFC リーダラ
イタという機械と NFC タグが無線通信を行うことによって実現する。
そう書くと非常に難しそうだが、無線通信の仕方は NFC リーダライタがうまくやってくれるので、使う人
は NFC リーダライタに送信してほしいコマンドデータを作ったり、 NFC リーダライタが受信したデータ
を解析したりするだけだ。 Android OS のように、基本機能として NFC が組み込まれている場合はさ
らに手軽に使えるようになっている。
さらにさらに、 Android OS では Type 2 Tag 製品の１つである MIFARE Ultralight をアクセスするた
めの手段が既に用意されているため、 Type 2 Tag であれば敷居が低くなっている(おそらく、
Android が NFC をアクセスするために採用した部品が NXP 社だったため、優遇されているのだろう
と思われる)。よって、 Android から Type 2 Tag にアクセスするのであれば、コマンドまで知らなくても
NFC タグにアクセスすることができる。
まあ、そう悩むな
まずはそんなに悩まず、やってみるとよいだろう。
-8-

11. 月刊 NDEF 2013 年 1, 2, 3 月号
第２章 Type 2 Tagを読もう
Tag
Type 2 Tag を読むのだ。
お前は NDEF なのか？
NFC タグは単なるメモリであり、第１章で書いた内容は NFC Forum が定義した仕様に従った場合、
という前提である。
他の仕様に従ったデータが書かれているかもしれないので、アプリケーションはデータを読んだときに
「自分の意図するフォーマットで書かれているのか？」ということをチェックしなくてはならない。
この章であれば「お前は NDEF なのか？」というチェックをすることになる。
NDEF のデータであることがわかれば、
はい、ここでは
それ以降は NDEF の読み方をすれば
NDEFを読むまでの
よいだけである。 説明をしますよ
NDEF Detection Procedure
Type 2 Tag の仕様書に「 NDEF Detection Procedure 」という、 NDEF を検出する手順が書かれて
いるので、それを追ってみよう。
なお、 NXP 社のドキュメントには他のフォーマットを読むときの方法も書かれているので、興味がある
方はダウンロードするとよいであろう。
まず CC を読め
Fig. 1-1 に「 Capability Container 」(以下、 CC))という情報が Block 3 にある。
NDEF の場合、 CC に特定のデータを書き込むことになっている。
まず、 CC[0]に 0xE1 が書き込んであること。
これが大前提である。この数値はマジックナンバーで、 0xE0 だったら、とか、 0xE2 だったら、という
わけではない。
読むのをやめて
そうなっていない場合は、もう NDEF として 違うことでもしようか
読み込むのをやめてよい。
-9-

12. 月刊 NDEF 2013 年 1, 2, 3 月号
CC[1]には Type 2 Tag のバージョンが入っている(上位 4 bit がメジャーバージョン、下位 4 bit がマ
イナーバージョン)。今までリリースされた Type 2 Tag のドキュメントは「 1.0 」と「 1.1 」なので、それぞ
れ「 0x10 」と「 0x11 」になる。
このバージョンは、 Type 2 Tag Operation Specification のドキュメントバージョンとなる。現在は 1.1
だが、少し前までは 1.0 だった。今後もバージョンが上がっていくことが予想される。
メジャーバージョンアップ、マイナーバージョンアップについてどうあるべきか仕様書に書かれている
が、まあ今の段階では気にしなくてよいだろう。
仕事でやるときは
気をつけるのだ
CC[2]はユーザデータのサイズを 8 分の 1 した値が入っている。例えば「 0x06 」ならば 48 byte 、
「 0x12 」なら 144 byte 、という具合だ。これは NDEF として使っているサイズではなく、ユーザデータ
領域のサイズを指すようである。
CC[3]は、上位 4 bit に読み込む方の、下位 4 bit に書き込む方の制限というか、能力というか、そう
いった値が入っている。
・上位 4 bit
・0x0 ・・・セキュリティ設定なし
・0x01 ～ 0x07 、 0x0F ・・・ RFU(将来のために空けている)
・0x08 ～ 0x0E ・・・プロプライエタリ(メーカー用)
・下位 4 bit
・0x0 ・・・セキュリティ設定なし
・0x01 ～ 0x07 ・・・ RFU(将来のために空けている)
・0x08 ～ 0x0E ・・・プロプライエタリ(メーカー用)
・0x0F ・・・書き込み禁止
NDEF であれば、だいたいこういう値になるのではなかろうか。
・MIFARE Ultralight : 0xE1 0x10 0x06 0x00
・MIFARE Ultralight C : 0xE1 0x10 0x12 0x00
もうちょっと
- 10 -

13. 月刊 NDEF 2013 年 1, 2, 3 月号
NDEF TLV を読む
CC が期待通りの値だった場合、ユーザデータ(Block 4 以降)は NFC Forum が定義する TLV 形式
であると想定してデータを読み込む(違う可能性もあるので、サイズの異常対策だけはしておこう)。
先頭から TLV を順に読んでいき、 T=0x03(NDEF メッセージ)が見つかるまで読み進める。もしユー
ザデータの最後まで 0x03 が見つからない場合や、先に T=0xFE(TLV 終わり)が見つかった場合は、
そこまでで終わる。
次に NDEF メッセージの L(Length)を確認する。もし 0 であれば、そこまでで終わり、これ以降の TLV
検索は進めない(最初の NDEF メッセージ TLV だけが有効)。
後は読むだけ！
あとは、この TLV の Value 部分を NDEF メッセージとして読むだけである。
NDEF メッセージの読み方は、タグの種類によらず同じである。
読めなかった子は
いねぇがぁぁ！
- 11 -

14. 月刊 NDEF 2013 年 1, 2, 3 月号
Appendix MIFARE? Mifare? どっち？？
Type 2 Tag といえば、 NXP 社。
さて、「 MIFARE 」か「 Mifare 」か？ いつも迷う。
ここまでの文章を振り返るとわかるように、正解は「 MIFARE 」である。
ホームページより(http://www.mifare.net/overview/)
「 TM 」とついているので、登録商標ということであろう。
同じようなことがフェリカでも気になる。
これは「 FeliCa 」と、 F と C が大文字である。
FeliCa に関する製品の商標が以下のページに書かれていた。
http://www.sony.co.jp/Products/felica/attention.html
交通カードには「○○カ」のような名前が多いのだが、「 Suica 」のように先頭だけが大文字だったり、
「 TOICA 」のように全部大文字だったり、「 nimoca 」のように全部小文字
だったり、みんなばらばらである。
文章で書くときには、やはり正しい名前を使うように心がけたいが、特にルールがあるわけではないの
で間違えないように気をつけたいものだ。
正しさを
人に求めすぎると
嫌われるぞ
- 12 -

15. 月刊 NDEF 2013 年 1, 2, 3 月号
今日のお洋服は
PASMOっぽいわね
そういうあなたも
Suicaカラーだわ
今月の内容はこちらです！
第１章 Type 3 Tagの基本
第２章 Type 3 TagとFeliCa
第3章 FeliCaとNFC
付 録 Type 3 Tagヘッダ
- 13 -

16. 月刊 NDEF 2013 年 1, 2, 3 月号
第１章 Type 3 Tagの基本
Tag Type 3 Tag をおさらいしよう。
NFC Forum の定義
Technology として「 NFC-F 」を使う唯一の Platform である。
Technology
NFC Forum の用語で、無線の通信方式を表している。
「通信」という動作を行う場合、だいたい次のようなことを考えることになる。
1. 物理的な接続方法(○○ケーブルで接続する、無線を使う、など)
2. 物理的な接続を行った後の、物理的な通信方式(通信速度や、 1 と 0 をどう表すかなど)
3. 物理的に通信できるようになった後の、論理的な通信方式(パケットの構造など)
4. 通信を使ったアプリケーション
項目の 1 と 2 を表しているのが Technology で、 3 は Platform 、 4 が NDEF 、のようなイメージでい
たら、だいたいよいのではなかろうか。
NFC-F は、「 F 」とついているので気付いたかもしれないが、 FeliCa の通信方式である。国際規格の
ISO/IEC 18092 にある「 212kbps / 424kbps 」の通信方式でもある。
あまり難しく考えず、「 FeliCa と同じなんだ」くらいわかっておけば十分だろう。
難しいところは
洗い流しておくわ
Platform
これも NFC Forum の用語である。
Technology では「無線通信」のところしか決めていないので、 Platform でソフトウェア的なアクセス方
法(パケットの構造)や、 Tag としてのメモリ構造などを決めている。
- 14 -

17. 月刊 NDEF 2013 年 1, 2, 3 月号
NFC-F が FeliCa の通信方式だったように、 Type 3 Tag も FeliCa のアクセス方式になっている。
現在(2013 年 2 月)のところ、 FeliCa のタグとしては「 FeliCa Standard 」と「 FeliCa Lite / Lite-S 」が
ある。
Type 3 Tag は、 FeliCa Lite / Lite-S を基本としている。
経緯は詳しくないのだが、 FeliCa Lite / Lite-S (以下、 Lite)は FeliCa Standard をベースに作られて
いると考えている(私は)。 FeliCa Standard は、 Suica のような決済にも使えるほどのセキュリティと、
複数の FeliCa アプリ(Suica 、 nanaco など)の同居ができるような汎用性を考えているため、メモリア
クセスにいろいろな種類がある。
Lite はそのあたりを削除した簡易版と考えてよいが、通信方式が同じなので、ある程度の部分は概念
が残っている。
そういったこともあり、 Type 2 Tag と比べると多少の知識が必要になる。
メモリ構造
■基本的な考え方
FeliCa 自体のメモリは、単なる RAM 配列ではなく「ファイルシステム」という考え方になっている。
ハードディスクに「パーティション」「フォルダ」「ファイル」「クラスタ」があるように、 FeliCa には「システ
ム」「エリア」「サービス」「ブロック」がある。
「セクタは？」と思われそうだが、上記はクラスタでもセクタでもどっちでもよいだろう。
■ブロック
メモリの最小アクセス単位は「ブロック」である。 1 ブロックは 16 byte (Type 2 Tag は 4 byte)。
ディスクのファイルシステムと照らし合わせると、 1 クラスタ = 1 セクタ = 16 byte 、くらいになるだろ
うか。
■サービス
サービスとは、ブロックをグループにして、同一グループに対して同じアクセス方法を。
FeliCa Standard には、「ランダムサービス」「サイクリックサービス」「パースサービス」の 3 つがある。
さらにその 3 つの中に、「読み書き可能」「読み込みのみ」や、「認証不要」「認証必要」などの属性が
あるため、種類としては 16 あることになっている。
サービスの 16 種類にはそれぞれ値があり、「サービスコード」と呼ばれている。
サービス
しときました！
- 15 -

18. 月刊 NDEF 2013 年 1, 2, 3 月号
Type 3 Tag では、その中で以下の２つをサポートしている(仕様書「 2.3.3 」)。
・ 「ランダムサービス」の「読み書き可能」で「認証不要」 : サービスコード = 0x0009
・ 「ランダムサービス」の「読み込みのみ」で「認証不要」 : サービスコード = 0x000B
ランダムサービスは、ブロック番号を指定してアクセスできる。ディスクのファイルシステムで考えると
「ファイル」と「ファイル属性」が一緒になったようなものと思えばよかろうか(ちょっと強引か)。
■エリア
FeliCa Standard には、エリアという考え方がある。
が、 Type 3 Tag にはないので、安心して忘れよう。
ないものは
忘れてしまえ
■システム
メモリ構造の一番上で、メモリにアクセスする場合には最初に指定することになる。
パーティションやドライブのようなイメージか。
たとえば Suica では「 0x0003 」というシステムを使っているが、 Edy では「 0xFE00 」というシステム
を使っている。かといって「 0x0003 」は Suica だけが使っているわけではなく、 nimoca など他のアプ
リもつかっているし、「 0xFE00 」も然りだ(なお、 0xFE00 は「共通領域」というシステムで、他の人もた
くさんいる)。
Type 3 Tag では「 0x12FE 」というシステムを使うことになっている。 Lite はシステムとして
「 0x88B4 」を使っているが、設定によって「 0x12FE 」としても使うことができるようになっている。これ
は特殊な例で、通常１枚のカードが複数のシステムを持つ場合には、それぞれのシステムごとにメモ
リを分けるようになっている。
■IDm
Manufacture ID や NFCID2 とも呼ばれる(製造者コードだから Manufacturer ID じゃないのか？)。
主な用途としては、複数枚のカードが同時にかざされたとき、リーダライタが 1 枚を指定するために使
うものだと思っている(セッション ID みたいなものか)。
現在使われている製品には、 IDm だけで世の中から 1 枚の FeliCa カードを識別できる前提になっ
ているものもあるが、セキュリティが必要なところではそういうやり方はしないように注意しよう。
システムで使うなら
しっかりと考えよう
- 16 -

19. 月刊 NDEF 2013 年 1, 2, 3 月号
アクセス
FeliCa Standard には多くのアクセスコマンドがあるが、 Type 3 Tag には 3 つだけ用意されている。
・Polling
・Check (Read Without Encryption)
・Update (Write Without Encryption)
括弧内は、 FeliCa での名称である。
詳細は仕様書を確認してほしいが、ここではわかりづらい(と私が思った)ところを説明する。
■手順
NFC リーダライタ側の目線で、アクセスする手順を書こう。
1 Polling(ワイルドカード)で、 Tag の存在を確認する
2 Polling(システムコード指定)で、アクセスしたいシステムを確認する
3 Check や Update を行う
4 接続を切る
Polling コマンドの戻り値として、 IDm と一緒にシステムコードを返してもらうこともできる。
このときに返ってくるシステムコードは「最初のシステムコード」である。携帯電話であればおそらく
「 FE00 」だろうし、 Lite であれば「 88B4 」である。
FeliCa Standard には「 Request SystemCode 」というコマンドがあり、カードが持っているシステム
コード一覧を取得することができるが、 Lite にはそれがない。つまり、 Lite は設定で Type 3 Tag とし
てアクセスできるようになっていたとしても、 Polling コマンドで取得することはできない。
どうするかというと、システムコード 12FC を指定して Polling を投げて確認するしかない。「なら、ワイ
ルドカードで Polling しなくていいではないか」と言われそうで、たぶんそうなのだろう。
■いきなりアクセスできるか？
システムコードもわかっていて、 IDm もわかっているならば、 Check や Update をいきなり使ってもよ
さそうだが、そうはいかない。
Polling には「システムを捕捉する」という意味合いもあるので、やはり Polling はいるのだ。
■接続を切る？
手順の最後で「接続を切る」と書いたが、これはリーダライタが送信している無線を止めることである。
ハード的に止めてもいいし、無線が届かない距離までカードを離してもよい。
NFC のタグは、だいたい電源を持っていない。リーダライタが送ってくる無線を使って発電してチップ
が動作するのだ。
FeliCa Lite の説明を読んだが、「電源を切ると、それ以降アクセスできないようにできる」というよう
に、電源が切れることによって設定が完了するものもあるので、気にしておくとよいかもしれない。
無線が
降ってくるわ
- 17 -

20. 月刊 NDEF 2013 年 1, 2, 3 月号
第２章 Type 3 TagとFeliCa
Tag
じゃあ、Type 3 Tag = FeliCa でよいね？
Type 3 Tag と FeliCa Lite は同じものか？
Type 3 Tag と FeliCa Lite / Lite-S の関係は、 Type 2 Tag と MIFARE Ultralight の関係と同じであ
る。
つまり「 Type 3 Tag 」は概念であり、それを製品化した一例が「 FeliCa Lite / Lite-S 」なのである。オ
ブジェクト指向っぽく考えると、 Type 3 Tag という基底クラスがあり、それを継承して FeliCa Lite とい
う派生クラスがある、という感じか。
FeliCa Lite-S
FeliCa Lite
Type 3 Tag そんなものかね
FeliCa Lite は何が追加されている？
減算レジスタブロック Reg
1 ブロック分のユーザブロックだが、ランダムサービスのブロックのように自由に書き込めるわけでは
なく、条件を満たした場合のみ書き込みができる。
まず、 16 byte が以下のように 3 分割されている。
・RegA : 4 byte 分
・RegB : 4 byte 分
・RegC : 8 byte 分
RegA と RegB は、リトルエンディアンの 32bit 値として扱われる(RegC は自由)。
以下の条件を満たすとき、このブロックに書き込みができる。
・RegA : 現在の値以下の値
・RegB : 現在の値以下の値
- 18 -

21. 月刊 NDEF 2013 年 1, 2, 3 月号
わかりづらいので、例を挙げよう。
なお、私は Reg ブロックを使ったことがないので、間違っていたら申し訳ない。
■例
Reg ブロックの値 : 67 45 23 01 EF CD AB 89 xx xx xx xx xx xx xx xx
RegA : 0x01234567
RegB : 0x89ABCDEF
この場合、書き込みたいのであれば、
RegA : 0x00000000 ～ 0x01234567
RegB : 0x00000000 ～ 0x89ABCDEF
の値を書き込むことになる。 1 ブロック単位でしかアクセスできないので、一部だけ書き込みたい場合
でも 16 byte 指定して書き込むことになる。
つまり、 RegA や RegB に現在値よりも小さい値を書き込むと、それより大きい値に戻すことはできな
いことになる。
使い道としては、回数券のように、制限を設けたい場合だろう。 RegA と RegB は同値でも書き込め
るので、書き込み回数が必ず制限されている、ということではないが、そこら辺は運用で考えることに
なるだろう。
片側認証
カードを発行した側が「このカードは第３者に書き込まれていないだろう」と認証する方法。
FeliCa Lite には「カード鍵ブロック」という値を書き込むブロックがある。そのブロックは書き込み専用
なので、書き込んだ人しかその値を知らない。
別のブロックとして「ランダムチャレンジブロック」というものがあり、そこに値を書き込むと、カード鍵の
値と書き込んだ値を使って、あるアルゴリズムを使った計算を行い、結果を「 MAC ブロック」として読
み込めるようになる。
カードを発行した人は、カード鍵の値と、ランダムチャレンジに書き込んだ値と、計算するアルゴリズム
がわかるので自分で計算し、読み込んだ MAC ブロックの値と比較して、カード鍵が発行したときと同
じものかどうかが識別できる、という考え方だ。
実際はもう少し手が込んでいるのだが、難しいので説明しない。
仕様書もあるので興味がある人は調べてみよう。
ネズミにしか
興味がないな
- 19 -

22. 月刊 NDEF 2013 年 1, 2, 3 月号
第3章 FeliCaとNFC
Tag
じゃあ、FeliCa と NFC の関係はどうなのだ？
FeliCa と NFC の関係は、 MIFARE と NFC の関係と同じようなものだ。
ただ、 MIFARE について語ることができるほど私の知識は広くない。 FeliCa についてもそれほど広く
ないのだが、私の知っている範囲で書いていく。
NFC とは？
そもそも、「 NFC 」という語り方をしたときの「 NFC 」とは、一体なんなのだろうか。
13.56MHz の無線を使ったものを NFC と呼ぶのか、その通信距離が数 cm のものを呼ぶのか。
はたまた、 ISO/IEC 14443 や ISO/IEC 18092 を満たしているものを呼ぶのか。
どれも、間違っていないとは思うが、そうなると「 NFC ってなによ」というのが結局わからない。
なので私の場合は「 NFC Forum で規定している内容を満たしている(と思っている)」ものを NFC と呼
ぶようにしている。仕様を全部把握しているわけでもないので、この「月刊 NDEF 」シリーズもあやしい
ところはあるかもしれないが、気持ちとしてはそうしている。
気持ちが大切でございます
NFC Forum から見ると？
NFC Forum では、無線通信方式である Technology と、そのアクセス方式の Platform くらいまでし
か規定していない。
その視点からすると、 FeliCa は NFC に沿っている。
NFC Forum
NFC-A NFC-B NFC-F
Type 3
Type 1
Type 4B
Type 2 FeliCa
Type 4A
- 20 -

23. 月刊 NDEF 2013 年 1, 2, 3 月号
世の中には、 13.56MHz の無線を使って、数 cm のところでしか通信しないような規格がいくつもあ
り、それらは実際に運用されている。
NFC Forum では、それらすべてを取り込もうとしている。だから、 NFC Forum から見ると、 MIFARE
も NFC Forum の規格を満たしているし、 FeliCa も NFC Forum の規格を満たしている。
運用面から見ると？
MIFARE や FeliCa は、 NFC 製品と言うよりも、 NFC の規格を使ったシステムである。タグを使って
アクセスするのは、システムの一部に過ぎない。
システムについては詳しくないのだが、こういうイメージではなかろうか。
各拠点に NFC の R/W があり、そこで MIFARE なり FeliCa なりのカードにアクセスし、情報をやりと
りする。その情報はネットワークを介してサーバに集約される。最終的なお金の決済などは、サーバが
銀行のシステムなどとやりとりをする。
本当はもっと難しいシステムなのだろうが、こうやって見ると、 NFC の部分は大切ではあるけれども
わずかだ。大半は拠点とサーバをどうつなぐかとか、どうやって決済を行うだとか、そういうところが重
要になってくる。
NFC Forum では、もちろんこういうことには触れていない。そもそも NFC 通信のセキュリティには踏
み込んでいないので、実際に決済で使うのであれば各社が自前でセキュリティを用意するしかない。
その部分は「 NFC Forum 対象外」なので、 NFC Forum の規格を守りつつ独自システムを組み入れ
ることは可能なのだ。
違う見方をすると、 NFC Forum としては MIFARE も FeliCa も規格内ではあるものの、相互交換が
できるのは NFC Forum で規定された範囲に限るのである。今のところ NDEF がそれにあたるが、セ
キュリティについては取り決めがないため、決済のような目的には使うことが難しい。
- 21 -

24. 月刊 NDEF 2013 年 1, 2, 3 月号
決済方面での普及はゆっくりじゃなかろうか
「 NFC を使おう！」と考えたとき、このようなシステムを作ることを考えると、費用の面から二の足を踏
むだろう。既にクレジットカードのような金融システムがあることを考えると、爆発的に普及する、という
ことは難しいように思う。進んだとしても、ゆっくりじゃなかろうか。
ゆっくり
もし NFC Forum がセキュリティにも言及した NDEF 規格を作り、それがかなり万全なものであったと
しても、 MIFARE と FeliCa のタグにセキュアなアクセスができる、というところしか実現できない。
「海外で FeliCa を使いたい」と思ったときにやらないといけないのは、
・現地で運用されている MIFARE などの R/W システムを FeliCa にも対応
・MIFARE で運用しているシステムの決済方式と FeliCa で運用している運用方式をなんとかする
と、可能ではあるけれども莫大な費用と時間がかかるようなことをやらないといかんのじゃなかろう
か。
そう思った矢先、 DoCoMo がいろいろとやっている話が出ていた。
http://www.itmedia.co.jp/mobile/articles/1302/27/news107.html
この記事にある「 NFC 」は、 GSMA が標準とした NFC 方式のことと思われる。携帯電話の決済、つ
まりモバイルペイメントの方である。
詳しくないので語るものがないが、なかなか大変そうである。
こりゃ大変だ
- 22 -

25. 月刊 NDEF 2013 年 1, 2, 3 月号
付録 Type 3 Tagヘッダ
Tag
Type 3 Tag のヘッダを見ておこう。
今のところ、 Type 3 Tag として動作させることができる NFC タグは、 FeliCa Lite/Lite-S(以下、
FeliCa Lite)しかないと考えている。
もちろん、 FeliCa Standard でも可能だとは思うが、お金がかかるので私は注文したことがない。
前提条件
FeliCa Lite を Type 3 Tag として使えるようにするためには、 NFC Forum の決まりとは関係ない操
作を行う必要がある。 MC というレジスタが 1 ブロックあるのだが、その中の SYS_OP(0 から数えて
先頭から 3 番目)に 0x01 を書き込むことで、 Type 3 Tag の条件であるシステムコードが NDEF 対
応(0x12FC)になる。
詳細は、以下の資料を参照のこと。
・FeliCa Lite ユーザーズマニュアル
購入したばかりの FeliCa Lite は、 SYS_OP が 0x00 になっている。
このときはシステムコードが FeliCa Lite 用(0x88B4)になっているため、 NFC-F ではあるものの
Type 3 Tag としては動作させることができない。
なお、 FeliCa Plug という組込み機器用のタグがあるが、これも設定によって NDEF 用のシステムコ
ードにするか、 FeliCa Plug 用のシステムコード(0xFEEL)にするのかを決めることができる。
RC-S620/S のような NFC リーダライタでカードエミュレーションを行う場合は、システムコードを自由
に設定することができる。
■注意
FeliCa のカード検出のためにポーリングを行うが、システムコードをワイルドカード「 0xFFFF 」で行う
ようにしている場合が多い。
このときにシステムコードを返すように要求していると、 FeliCa Lite は 0x88B4 を返す。 SYS_OP の
設定がどうであっても、ワイルドカードで指定した場合には最初にひっかかったシステムコードを返す。
FeliCa Standard の場合は「 Request System Code 」というコマンドがあり、カードが持つシステムコ
ード一覧を取得することができるが、 FeliCa Lite にはそのコマンドがない。
何が言いたいかというと、かざしたカードが NDEF 対応しているかどうかを確認するならばポーリング
時にシステムコードを「 0x12FC 」と指定して行わなくてはならない、ということである。
詳細は、以下の資料を参照のこと。
・FeliCa Lite に関するソフトウェア開発テクニカルノート
・フォーマット判別シーケンス設計ガイドライン
- 23 -

26. 月刊 NDEF 2013 年 1, 2, 3 月号
Type 3 Tag ヘッダ
Type 3 Tag ヘッダは、 FeliCa Lite の 0 ブロック目(PAD0)に書き込む。
Ver Nbr Nbw Nmaxb - - - - WriteF RW Ln Checksum
10 04 01 00 0D 00 00 00 00 00 01 00 00 4C 00 6F
■Ver
バージョン。現在は 1.0 なので、 0x10 。
■Nbr
同時読み込み可能ブロック数。「同時」とは、 1 回の Read Without Encryption で指定できるブロック
数と考えてよい。 FeliCa Lite は 4 ブロックまでなので、 0x04 。
■Nbw
同時書き込み可能ブロック数。「同時」とは、 1 回の Write Without Encryption で指定できるブロック
数と考えてよい。 FeliCa Lite は 1 ブロックまでなので、 0x01 。
■Nmaxb
NDEF データ部として使用できるブロック数。 FeliCa Lite のユーザブロックは、 PAD0 ～ PAD13 ま
での 14 と、減算レジスタ REG が 1 つの計 15 ブロックある。このうち自由に書き込みができるのは
PAD0 ～ 13 で、 PAD0 はヘッダとして使われているため、 13 ブロックが使用できる。よって 0x0D 。
ビッグエンディアン。
■WriteF
Write Flag 。 NDEF として書き込む前に 0x0F にし、書き込みが終わったら 0x00 にする。 NDEF と
して読み込む前にチェックし、 0x00 じゃなかったら読み込みを行わないようにするという取り決め。書
き込んでいる間に NFC タグが離れて中途半端な書き込みになることを想定したものだろう(Write
Without Encryption コマンド 1 回は成功するか失敗するかしかない)。
なお、書き込み時にはフラグをチェックしない。
FeliCa Lite 自体の機能を制限するものではないので、使う側が注意することになる。
■RW
RW Flag 。 0x00 であれば読み込み専用、 0x01 であれば読み書き可能という取り決め。
FeliCa Lite 自体の機能を制限するものではないので、使う側が注意することになる。
- 24 -

27. 月刊 NDEF 2013 年 1, 2, 3 月号
■Ln
実際に書き込んでいる NDEF データサイズ(ヘッダは含まない)。単位はバイト。
FeliCa Lite は Nmaxb が 13 ブロックなので、全部使っても 208 バイト。
ビッグエンディアン。
■Checksum
ヘッダ部のチェックサム。 Ver から Ln まで(0 から 13 まで)を単純に 1 バイトずつ足していった値。
ビッグエンディアン。
感想
Type 2 Tag(以下、 T2T)と比較すると、ちょっとめんどくさく感じる。
Ln に相当するものは T2T にはない。 Ln があるから Checksum もあるのだろう。同時アクセスブロッ
ク数も、あってもなくてもなあ、と感じてしまう。
NDEF アクセスに高速性と安全性を求めるならば、同時にアクセスできる最大ブロック数がわかった
方がよいと思う。 1 回分のアクセスは FeliCa Lite が保障することになっているからだ。
ただ、ちょっと書いたが FeliCa Plug も NDEF タグとして動かすことができる。 Nbr は 12(0x0C)、
Nbw は 12(0x0C)で、 Nbmax に至ってはほぼ自由である。そこまで視野に入れると、巨大な NDEF
タグも作り出すことができるので、こうなるしかないか、という気もする。
新たな製品が出たときにも対応できるようにこうなった、と思っておこう。
いざというとき
対応できるよう
- 25 -

28. 月刊 NDEF 2013 年 1, 2, 3 月号
編集後記
単に、 3 回作った内容を 1 つにしただけです。
単に「まとめたら何ページくらいになるんだろう？」ということを
確認したかっただけです。
2013/03/27 10:45
- 26 -