しっぽのさきっちょ 2003年12月

マスコミ報道（という名の「ワイドショウ」）に呆れてしまう。 そろそろイラクが「戦場」であることをもっと強く意識すべきだ。 たとえ長閑な土地に見えても自衛隊（＝日本軍）を派遣すればそこが戦場になる。 まずその大前提のもとに自衛隊を派遣することの合理性を議論しなければならない。 たとえどのような大義名分（＝復興支援）を掲げようとも自衛隊がイラクに行くことはイラク戦争に「参戦」することに他ならない。

私はガチガチの平和主義者ではないが， 今の日本がイラク戦争に参戦しても何の益もないと思っている。 既に米英軍に「勝ち目」はないのだ。 「勝ち目」のないところに荷担してどうする。

既に欧米から「臆病者」と見なされている日本は今回の事件（テロ？）で引くに引けなくなっている。 このままでは無理やりにでも「派遣」（＝参戦）せざるを得ないだろう。 しかし， （以前は日本を参戦させないための脅迫だと思っていたが）それこそが相手側の狙いじゃないのか？ 何故なら米英軍を攻撃するより（行動についての縛りが大きい）自衛隊を攻撃する方が簡単だからだ。 そうなれば米英軍は更に負担を抱え込むことになり， かつ撤退もより困難になる。 アメリカもそれが分かってるから「行け！」とは言わなくなっているのに， 何故日本政府だけがこんなにしゃかりきになるのだ。

たとえ「臆病者」と蔑まれようとも， ここは「引く」べきである。 J-RCOM の神浦元彰さんのコメント（12/1）じゃないが， アメリカに申し訳が立たないと言うのなら小泉首相を切ればすむ。 日本では総理大臣なんてアンパンの首と同様いくらでも交換可能な存在なのだから。

「Noras?」 12/1 の記事経由。

• 著作権とかネットラジオとか音楽配信とか

素晴らしい！ 分かり易い！

こういう図解の仕方はいいなぁ。 CC の FAQ でも応用できるのでは？ つか是非！

12/1 から大阪だった。 前の仕事の残務整理と障害対応。 最低でも一泊程度で帰るつもりが， あれもこれもどれもそれもとズルズルと三泊もしてしまった。 しかも着替えを持っていかなかったので4日間着たきりスズメ。

しかもミーティングキャンセルのメールを送るの忘れてるし。 こんなの書いてる暇があったならもっとちゃんとやれ＞自分。

コンビニで割高な下着を買ってどうにか凌ぐ。 学生のときは一週間くらい着替えなくても全然平気だったのに， 環境が変われば感性も変わるものである。

ミーティングの方はなかなか面白いことになっていたようで。 行きたかったなぁ。 面白そうなミーティングや学会がある時って必ず仕事。 新人の頃は「研修」扱いで「出張」させてもらっていたものだが。 ひょっとして「出張」扱いで参加してる人とかもいたのかな。 ネットで公開されている感想とか読むとそんな感じ。 でも CC について業務レポートを出すのは難しいんじゃないのか。 せいぜい「わが社には関係ない話でした」って書くのが関の山じゃないだろうか。

iCommons Japan の立ち上げに合わせ Creative Commons のサイトもリニューアルしていた。 （トップページは変わらないけど）

大きく変わったのが「Choose Commons」のページ。 どうやらブラウザが送るサポート言語（HTTP_ACCEPT_LANGUAGE）を見て自動的に切り替えているようである。 コモンズ証も切りかわる。 法的条項（Commons Deed）は英語のまま。

用語がまた変わってるんだよなぁ。 ドキュメントを修正しなきゃ。

• もっと辺境から戯れ言

既にあちこちのサイトでツッコまれているようだが， 個人的には「こんなもんじゃないの」という感じ。 しかし， 確かにスタイルシートとページデザインはもう少し融通をきかせて欲しいと思う。 あとアクセス解析の表示機能も欲しいところ。（公開する必要はないと思うが）

まぁでもアレで「新規顧客」は無理なんじゃないだろうか。 cocolog を中心に何らかのコミュニティが出来上がれば長期的には集客効果はあるかもしれないが。 しばらく無料で使わせといて， より高機能な「有料版」が出れば集金効果はあるかもしれない。

しかし， ああゆう運用スタイルはちょっと苦手。 コンテンツの全てを自分でコントロールできないからかもしれない。 まぁ， でも， Wiki にも適応できたんだから Weblog もそのうち慣れるであろう。 バックアップのやり方を考えないとなぁ。

「Weblog 運用方針」にも書いたが， 「もっと辺境から戯れ言」には当面うちのサイト運用ポリシーを適用しないことにした。 CCPL も付与しない予定。

Weblog に CCPL を付与することについては以前から議論があるが， 個人的には「Weblog には CCPL を付与しない方がいい」と思う。 意味的にはともかく， Weblog の運用スタイルは BBS や Wiki に近いもので， ひとつのコンテンツに不特定の人が関ることを許容している。 CCPL が著作権をベースに設計されている限り， 不特定の人が関るコンテンツに CCPL を付与するのは基本的に無理だと思う。

もちろん全く方法がないわけではない。 私が考えたのは二つ。

ひとつはコンテンツの全ての著作権を一人の著作権者に帰属させることを明示する方法。 これは BBS などでよく使われる方法で著作権の帰属先が分かり易いので使い勝手がよいが， 日本の場合には人格権の問題があるため完全とは言いがたい。 また cocolog のように環境をレンタルする場合には使えないだろう。

もうひとつは CCPL を本文テキストにのみ付与する方法だ。 巷にある Weblog のシステムはページごとにひとつの CCPL マークを貼り付けてしまう。 そこで CCPL マークを記事ごとに貼り付けるように改造し， ページのどこかに「CCPL は本文テキストにのみ適用されます」と明示しておけばよい。 記事に日付とライターの名前を表示することは既に可能なので， これでも充分機能する筈である。 RSS についてもアイテムごとに CCPL をセットすることは可能なので（ただし RSS 2.0 については分からない）， こちらも問題ないだろう。

ナゾなのが cocolog に実装されている FoaF 生成機能。 どう使うつもりなのか現時点ではさっぱり見えない。 せっかく RSS も提供しているんだから両者を連携させればいいのに， そういうつもりもないらしい。 しかも私のように自前で FoaF を提供している人にはかえって邪魔な機能である。

cocolog では「人」タイプのリストを作成すると， その内容が FoaF のお友達（knows）リストに反映されてしまう。 「人」タイプのリストをリンク集として使っている方はご用心を。

「もっと辺境から戯れ言」は当面ネタ帳として使う予定。 従って Wiki 版のネタ帳はしばらく更新を停止する。 荒川の文章は嫌いだが時事ネタを追いかけるために渋々この「戯れ言」を読んでいるという方は， 「もっと辺境から戯れ言」を見た方が幸せになれます。 そしてここの「戯れ言」では「時事ネタをフォローしなければ」という強迫観念から解放されることになる。 私としては昔のような日記スタイルに戻りたいのだが， ちょっとでも感情的なことを書くとすぐ反動がくるので， そゆのがやりにくくなってるんだよなぁ。 ふぅ。

先日亡くなられたＭａｇ．さんのサイトのミラーが公開された。 CISNet と @nifty のサイトは今のところ何とか公開中だが， Vector のサイトは亡くなられた直後に速攻で削除されていた。 今回のミラー公開は非常に有難い。 と同時に「コンテンツの相続」について考えてしまった。 Web スペースのレンタルは相続を含め譲渡が難しいらしい。 特に Vector は「シェアレジ」のサービスもやってるし簡単に譲渡・相続ってわけにはいかないよなぁ。 まぁ自前で立てている人は死んじゃったらそれっきりだろうし， 難しいよねコンテンツの相続ってのは。

まぁ私の場合， 後世に残すような価値のあるコンテンツはひとつもないのだが， 「不慮の死」ってのは今やその辺に転がっているものだからなぁ。（「世の中が」というより，そういうことを考える年齢になってしまったということ）

ここからは「クリエイティブ・コモンズは誰のもの？」の補足。 まず私のお気に入りである「Music Box Player」は上記のミラーサイトで公開されている。 もうひとつ。 私が本文中で

つまりMIDIデータというのは演奏テクニックの塊であると言い換えることもできます。このようなテクニックを「素材」として抽出しライブラリ化（データベース化）できれば，もっと面白い作品をもっと簡単に創作できるようになるかもしれません。

と書いているが， これは同じくＭａｇ．さんの「MIDI Espressivo」を念頭に置いて書いている。 「MIDI Espressivo」は「MIDI ファイルのレタッチソフト」と呼ばれている（というか公開ページにそう書いてあるのだが）非常にできの良いソフトで， 「PickPix」（「ピクピク」と読む）と並んで人気が高い。 シェアウェアで現在は「購入」できないのが残念である。

（12/7 追記） おっと， 忘れちゃいけないのが「Chaos von Eschenbach」。 遊んだよなぁ，これ。 ちなみに Club-HUAA サイトの BGM （ブラウザによっては鳴らないかもしれない。ゴメン）は， このツールで作曲したものを基にＭａｇ．さんがアレンジしてくださったものだ。 こういうものも「素材」と言えなくもない。 これに関連した「自動作曲と著作権」も面白い。

何年ぶりでスキル・シートを書く。 つか， マジメに営業してないってことだよな， それ。 日頃から作っとかなきゃなぁ， こゆのは。

「Surf Club Apple Town」の釣果をいただく。

「大物がかかった！」と思ったらインスタントコーヒーのビンで， しかも中にタコ（体長53センチ）が入ってたという罠。 タコをオリーブオイルとニンニクで炒めると美味い！

今回もご馳走様でした。

• 新しい快楽のフォーマット （圏外からのひとこと）
• ネットでの儀礼的無関心の可能性

なかなか想像力をかきたてられる内容。 ここ数日ずぅっとこれらの記事について（頭の隅で）考えていた。 本当は哲学とか社会学とかの見地から合理的に説明できるのかもしれないが， 今回は完全に私の主観のみで書いてみる。 従って内容がかなり妙かもしれないが， あしからず。

私はいわゆる「パソコン通信」から「インターネット」に転向した人間である。 「パソコン通信」と「インターネット」との決定的な違いは「所有欲」のベクトルにあるのではないだろうか。

「パソコン通信」時代はとにかく数々のフォーラムを巡回しひたすらダウンロードする「バッチ処理」を繰り返していた。 「NIFTY Serve」や「日経 MIX」の巡回ログは今でも大事に持っている。 この時代， 私にとって「情報」とは「所有するもの」だった。

一方「インターネット」（の様々なサービス）を利用するようになってしばらくすると， 「情報」へのアクセスの仕方が変わっていることに気がついた。 しゃかりきに「情報」をダウンロードしなくなったのである。 これは Web ベースの「情報」へのアクセスが多いことも原因のひとつかもしれないが， 何よりもネット上でフラットに展開される情報資産の圧倒的な「量」が「ダウンロードする」行為を諦めさせてしまったように思える。 ここに至って私は， 「情報」は「所有するもの」ではなく「常にそこにあるもの」と考えるようになってきたのである。

「所有欲」というのは対象となるものが「無くなるかもしれない」という強迫観念の裏返しだ。 しかし「無くなるかもしれない」とか「アクセスできなくなるかもしれない」という強迫観念が薄らいだ時， 人はどのように振る舞うのだろう。

自分でコントロール可能な Web サイトを持った人がよくやるのがお気に入りコンテンツの「リンク集」を作ることだ。 お気に入りコンテンツをバックアップする代わりにリンクを張って（≠貼って）おくことで「接続」を保持し， いつでもアクセスを可能な状態にしておく。 これはブラウザの「ブックマーク」にお気に入りコンテンツをブックマークするのとは微妙に違う。 「ブックマーク」はあくまでも（「外部」からは手のとどかない）ローカルの機能であり「情報の所有」の分かり易い例だ。 しかし， 自分のサイトにリンク集を（ローカルに置くのではなく）「公開」しようとするのは何故なのか。

「情報にアクセスする」という行為を行う際， もしアクセスへのコストが格段に安くて情報自体も「そこら中にある」状態であるなら， 情報に対する所有欲は「ローカルへのダウンロード」から「共有地へのアップロード」に向かうのではないだろうか。 インターネットへの「接続」がいつでもどこでも保証されるのなら「情報」を（ローカルではなく）インターネットに置いておくのが合理的（合利的）だ。 つまり「所有した情報」の置き場所が自分の部屋やパソコンのハードディスクのみならずネット上の「サイト」に拡大してきているのである。 ここで各自の「サイト」がもっと大きな「共有地」（ネット上の各サービスが提供する「場」）と重なり合っているのがポイントだ。 ネットにおいては「情報を所有する」行為と「情報を（共有地に）公開する」行為は同じものを指す。

そして「共有地」と各自の「サイト」が重なり合っているということは各自の「サイト」同士もまた重なり合っていることを意味する。 所有するために「共有地」に置かれた「情報」は， その「共有地」に参加する利用者同士で共有されるのだ。 そして面白いことに共有された情報を媒体として利用者同士でコミュニケーション（のようなもの）が発生する。 そしてこれがネットにおける新しい欲望を喚起する。

「共有地」で行われるコミュニケーション（のようなもの）は実世界のものと違って容赦がない。 何故なら， それぞれ皆「自分のサイト」の中で行っているため， それぞれ皆そのコミュニケーション（のようなもの）が自分にとってコントローラブルだと思っているから。 そして「接続」されていることで維持されている「共有地」では， 「儀礼的無関心」といったものでコミュニケーションをコントロールすることよりも「接続」が絶たれないように（場合によっては過剰なまでに）「リンク」することが重要視される。 ここから逃げるには「共有地」から完全に撤退し切断するしかない。

従来のビジネスモデルは「情報は所有するもの」という前提の下に様々なアイデアが考えられた。 しかしネットにおいては「所有する」ことは「共有する」ことであり， 情報に対する所有欲は簡単に「共有する欲望」に相転移する。 この辺のメカニズムを正しく理解しないと新しい需要は掘り起こせない。 企業が膨大なコストをかけて「所有欲」を喚起するようなコマーシャルメッセージを流しても， その欲望はそのままの強度で「共有する欲望」にベクトルを変えてしまうのだ。

（「所有欲」から相転移した）「共有する欲望」を励起させておきながら， 一方では恫喝によって「共有」そのものを否定しようとする。 そのような（消費者から見て）矛盾した態度をとる旧来企業・団体に憤りを感じても「無理もない」と思ってしまうのだ。

pgpdump 0.20 がリリースされた。 早速ビルドを行う。

その前に MinGW & MSYS のアップグレード。 いや， 随分前にバージョンアップしていたのは知っていたが， ここのところ gcc を使う機会がなかったので放ったらかしていたのだ。 今回も問題なく configure と make が通った。 作者の山本和彦さんに感謝。

そのうち venona さんのところで公開されると思うが， それまでの場つなぎとして私がビルドしたものを晒しておく。

「萌えクリ」でキャラクタ設定が公開されている。 やっぱキャラが見えてくると見通しがよくなったような感じがするねぇ。 妄想が膨らむ膨らむ。

• 4人のキャラをレジェンド・カードとして登場させる。 当然レア。 同じカードを場に複数出せない。 ノーデリーとシェアラーは同時に場に出せない。
• Napster とか Winny とかファイル共有ソフトを「特殊ランド」として登場させる。 特殊ランドが場に出ている間は萌えクリの4人に限り2つ分のマナを得る。
• RIAA 等の著作権管理団体をアーティファクト・カードとして登場させる。 上記の特殊ランド・カードを破壊できる。
• 4人の各武器はエンチャント・カードとする。各自に合うエンチャントを付けることでパワーが上がる。
• アトリーに羽根ペンのエンチャントが付いている場合は特殊能力が使える。 相手のクリーチャに刻印を付け指名したプレイヤーのものにすることができる。 ただし一回使うとエンチャントが外れ墓地に置かれる。

ああああっ， MTG ができるじゃないか。 誰かトレーディングカードを作ってくれ〜！

• 英国議会、IDカード導入義務付けを検討へ
• 「英でIDカード論争」
• BIOMETRICS

バイオメトリクス技術を採用する多くのシステムがこれを「認証」と呼ぶ。 そもそもこれが間違いだ。 バイオメトリクス技術はあくまでも個人の「識別」技術なのだ。 それにしても何故「認証」などというレトリックを用いるのか。 そのおかげで「セキュリティとプライバシーのトレードオフ」が云々， なんて妙ちきりんな話になる。

個人のプライバシーに踏み込まない「認証」の実装法方法はいくらでもある。 それをしないのはシステムの目的が「認証」ではなく「識別」にあるからだ。 私達はこのようなレトリックに躍らされるべきではない。

「専門家」と呼ばれる人達はこの点をちゃんと指摘し， その上で個人のプライバシーに踏み込む（可能性のある）「識別」技術が本当に必要なのか議論し， 私達「消費者」に説明すべきだ。 いったんシステムとして組み込まれたものを取り消すのは簡単ではない。 しかしそれが必要な実装であるなら私達は受け入れられる筈だ。

レトリックにまみれたその場しのぎの説明では反発が起きて当然。 君らみんな小泉首相か！

「「バイオメトリクス認証」と呼ぶのは止めよう」キャンペーン

（12/11 追記） 「Esaka Takeru's Memo」でバイオメトリクス関連のリンク集を公開されてる。

• 100円ショップの青空文庫

へぇ，買ってみようかな。 意地悪っぽく「インセンティブはライセンスによって与えられるものではないという好例」とでも書いておこうか。

私の Weblog で「レッシグ・ウィーク」絡みの記事をまとめてみた。 既に参照してくださっている方もおられて恐縮です。 フィードバックはいつでも歓迎ですので面白いコンテンツがあったら紹介してください。

• Meeting with Prof.Lessig
• 「Lessig Week」 2nd half

私はイベントそのものには参加していないので， それについて感想を書くことはできないが， 上記のリンク集で紹介した各コンテンツを読んで思うのは「彼等は CC/CCPL に一体何を期待しているんだ」ということだ。 これは 「クリエイティヴ・コモンズに関する悲観的な見解」 以来ずぅっと抱き続けてきた疑念でもある。

ひょっとしたら CCPL を貼り付けたら， がっぽり著作権料が貰えたり， 著作権を侵害する輩をチェックしてくれたり， あるいはみんな仲良くコモンズの中でコンテンツを共有し戯れることができるとでも思っているのだろうか。 あり得ないだろう， そんなこと。

それとも CCPL が何かクリエイターにインセンティブを与えるような機能があるとでも思われているのだろうか。 それもあり得ない。 ものを作る（創る）人達は「はじめにライセンスありき」でものを作るわけではない。 そもそも「萌えクリ」からして CC/CCPL をネタにはしても「はじめにライセンスありき」で作っているわけではないのだ。 それは Wiki の中のライセンスに関する議論をみれば分かるだろう。 ライセンスなんてぇのはコンテンツを作った後で付与されるものだ。 ライセンスがなくても当事者間で合意ができていればコンテンツを運用できるし， ライセンスがあってもそれを守らない奴が出てくれば機能しない。

CCPL やその他のライセンスというのは（エンジニア的な言い方をすれば）プロトコルに過ぎない。 インターネットでいえば RFC みたいなもんだ。 著作権ライセンスと RFC の違いはエンジニアリング上の整合性以外に法的な整合性についてもチェックしなければならない点だろう。 RFC があるだけでは何もおこらない。 何かしたいなら（RFC に基づいた）具体的な実装が必要だ。 著作権ライセンスも同様。 ライセンスを使って何かしたいなら相応の実装（＝アプリケーション）が必要だ。 そこまでできて初めてインセンティブだのイノベーションだのといった話ができるようになるのだ。 そしてそれを考えるのは CC/CCPL ではなく私達である。（まぁ CC プロジェクトでプロモーションも兼ねてそういうことをやるかもしれないけど）

もちろん CC/CCPL が未成熟なのは分かっている。 「レッシグ・ウィーク」に参加するまでもなく CC/CCPL をみればそれは明らかだ。 しかし未成熟な部分の多くはライセンスそのものよりも「具体的な実装がない（少ない）」ことにあるのではないか。 であるならそれは CC/CCPL の問題ではない。 私達の問題だ。

著作権上ヤバいかもしれないコンテンツが見逃されているのは現時点で「必要がない」または「コストに見あわない」というだけのこと（「根拠なき信頼」というやつか？）であり， 必要とあらば容赦なく攻めたてられる。 それは先日の Winny を巻き込んだ騒動やそれ以前の例を見れば明らかだろう。 私達が著作権について無頓着でいられなくなるのは， もはや時間の問題なのだ。

しかし非合法な手段をとらなければネット上で自由に「作品をプレイする」ことができないというのは明らかにおかしい。 たとえ全面解放でなくとも「自由な流通と消費」が保証される「余地」を残すべきだ。 これは今の私達だけの問題ではない。 私達より（もしかしたらまだ生まれてもいないような）若い世代の問題でもあるのだ。 私達は「次の世代」のために草を刈り地面をならして「道」を作ってあげなければならない。 道を作るための道具は提示された。 しかし「道」を作るのはあくまでも今の私達なのだ。

もちろん CC/CCPL が最良の道具であるとは限らない。 もっと違う道具が必要かもしれない。 真紀奈さんの CeM もそうした提案のひとつだろう。 もし著作権について今より意識されるようになればたくさんの「俺ライセンス」が登場するに違いない。 つか，今までそういう動きがなかったことの方が不自然かも。（フリーソフト界隈の動きと比較しての話だが）

大事なのは「実践してみること」だと思う。 道具は「使ってなんぼ」である。 使いもしないであれこれ言うのは「評論家」に任せておけばよい。

（12/15 追記） 以下の記事もご参考に。 ここよりはちゃんと考えて書いてある。

• Communitas ex Machina
• クリエイティブ・コモンズのジレンマ、または構造からこぼれ落ちるもの

「MinGW と MSYS を使った Windows 用 pgpdump の作り方」でも書かれているが， libbz2.a のビルドがうまくいかなくて四苦八苦。 試行錯誤中に MinGW 識別用の定義文字列を「__MINGW32__」ではなく「__MINGW32_」にしていたという罠。 結果をコンテンツを書かれている venona さんに報告。 これでうまくいくといいけど。 （12/15 追記： その後該当コンテンツは更新されている。感謝です）

ツッコミで結城浩さんよりアドバイスをいただく。 もう少しお待ちを。 つか， こういう文章って（「戯れ言」なんかじゃなく）ちゃんと書いたら， それなりに需要があるものなのだろうか。 アイリス（虹彩）を使ったバイオメトリクス絡みの仕事は昔にやったこともないこともないけど， 昔の話だしなぁ。 今から調べて厳密に書くとなるとかなり大変。 やっぱ結城浩さんが指摘された点だけフォローするに留めるか？

Weblog 用に書いていた文章を誤って消してしまう。 書きなおす気力はないのでなかったことにしちまおう。 そういえば cocolog って会員外の人にも切り売りするらしい。 なるほど。 金払ってまで使いたいという人がどのくらいいるかだな。

• 「kayakayaの日記」 12/11 の記事

ん？ Unicode というか ISO/IEC 10646-1 の文字集合は 31 ビットです。 TRON コードについては詳しくないですが 16 ビットを 1 面として 31 面しかないのなら ISO/IEC 10646-1 の方が広い空間を持っていることになります。（12/15 の記事で，もう少し具体的に検証しています） まぁ実際には最初の一面（BMP）しか使ってないんですけどね。 （詳しくは拙文「文字コードとその実装」（PDF）を参照してください）

ISO/IEC 10646-1 の CJK 漢字が一緒くたにされているのは技術的な問題ではなく政治的な問題とみるべきでしょう。 まぁ漢字の場合， 包摂の問題とか色々あって難しいのは分かりますが。 その他にも ISO/IEC 10646-1 にはシロートの私から見てもアレな実装が多いです。 そういう意味で日本における TRON コードの（特に政治的な）位置付けというのは重要だと思うんですけどねぇ。

（12/15 追記） kayakaya さんよりフォローの記事が出ています。 どうもです。

今回は「Surf Club Apple Town」について倉橋町の「とうせん浜」というところへ行った。 っても別に釣りをするわけではなく浜辺でごろごろと一日を過ごす。

TV も「パソコン」もなぁんにもなし。 コンビニもなし。 ラジオを聞きながらノンビリ。 まさに「終日のたりのたりかな」。 いや， まぁ， 冬の海だけどね。 でも瀬戸内海って冬でもまるで湖のように穏やかでうねりも少ないのでとても和める。 干潮→満潮→干潮と汐の満ち引きをしみじみ眺めるなんて何年ぶりだろう。 たまにはいいよね， こゆのも。

ケータイに GPS 機能があるので早速チェック。

場所：	広島県安芸郡倉橋町 とうせん浜（地図）
測地系：	WGS-84
経度：	北緯35度05分36.60秒
経度：	東経132度33分45.76秒

地図をみれば分かるが本当に何にもない。 一番近い民家からも相当離れているので星見にもよい。 まぁ海辺に機材を出すのはかなり勇気がいるけどね。

ツッコミより TRON コードの資料の場所を教えていただいた。 感謝です。

• TRON コード体系
• BTRON3仕様書(Ver 3.20.00) に対する制限・補足 TRONコード体系

いずれも「BTRON3仕様書 Ver 3.20.00」から辿れる。

まず， TRON コードでは「言語指定」と呼ばれるコード領域（2バイト以上の可変長コード）があるらしい。 ひとつの言語指定コードがひとつの「面」を指す仕組みになっている。 これは ISO/IEC 2022 の「指示」に似ている。 言語指定コードのバイト数は可変長なので事実上無限大の文字空間を持てることになる。 従って先日「ISO/IEC 10646-1 の方が広い」と書いたのは私の方が間違っていることになる。 ゴメンなさい。

面白いと思ったのは， TRON コードでは JIS X 0201 に相当する文字集合を持っていないことだ。 同様の文字は JIS X 0208 にも含まれるのでそちらに統合したということだろう。 これで文字コードについては全角／半角の区別がなくなったことになる。（ただし「文字指定付箋」を使うことで半角表現は可能） 更に TRON コードでは Unicode （おそらく UCS-2）まで丸ごと取り込んでいる。

注意しないといけないのは， この資料で示されているのは「文字集合（文字セット）」であり「文字エンコーディング」ではないということだ。 それは他のプロットフォームとの情報交換の仕組みが書かれてないということである。 TRON プラットフォーム内部では TRON コードをそのまま「文字コード」として使用できるが， 他のプラットフォームではそういうわけにはいかない。 何らかの変換手段が必要である。

TRON コードでは全角／半角の区別がないため他のエンコーディングからの変換で全角／半角情報が失われる可能性がある。 もちろんこれは「文字指定付箋」を使うことでカバーできるかもしれないが， そうなると「アプリケーションの実装しだい」ということになってしまう。

もうひとつ気になるのは同じ文字に複数のコードが割り当てられる可能性だ。 例えば「荒川靖弘」という文字列を TRON コードで表現する場合に， システムスクリプト，GT書体フォント，大漢和辞典収録文字，Unicode 等の複数の「言語指定」で表現できてしまう。 これはアプリケーション作成時に「言語指定」の選択の仕方を巡ってかなりの混乱をもたらすのではないだろうか。 またテキストに対して電子署名を行う場合に， 見た目は同じ文字列なのに内部表現が異なるため署名検証に不都合が生じるなんてことも起こりそうである。

とはいえ TRON は現実に実装されているプラットフォームであり， 上記のような点も当然考えられている筈である。 どうやってんだろ。 こりゃあ，本格的に調べないといけないかなぁ。

（ツッコミより） Daa さんもココログユーザだったのか。

なんかトラブルらしくて cocolog の管理画面に入れないので， 時事ネタだがこっちに書いておく。

「圏外からのひとこと」で紹介されている「イスラム文明論」やその他のコンテンツがいまいちピンとこなかったので， 私としては 「パルヴェーズ・フッドボーイ氏による文章」 を推しておく。

パルヴェーズ・フッドボーイ (Pervez Hoodbhoy) 教授はパキスタンの理論物理学者。 9.11 直後に発表された 「暗黒の火曜日：イスラマバードから（BLACK TUESDAY: THE VIEW FROM ISLAMABAD）」 は新聞にも要約が掲載されたりしたので知っている方も多いかもしれない。 もしご存じない方がいたら 「パルヴェーズ・フッドボーイ氏による文章」 にあるテキストを一通り読まれることをお薦めする。

何故フセイン氏が「生きて」捕まったのかが謎。 だってニュースソースは米軍の発表しかないんだから， それが「死体」であっても何ら不自然じゃない。 銃も持ってたんでしょ。 生きていれば彼をひとりの「人間」として扱わなければならないし， 彼に罪があるというのなら「裁判」を通じてそれを決着しなければならない。 ということは今後アメリカが彼をどのように遇しまたどのように裁判を行うのかを注目して見ていかなければならないということであろう。

まぁいずれにしろこれで日本の予定が変わることはないだろうし現地の危険度も（増えることはあっても）減ることはないだろう。 なにせ日本はアルカイダから「宣戦布告」されてるんだから。

（12/16 追記） 早速こんな分析が。 早い！

• アメリカの戦略としてのフセイン拘束

nDiary の 0.9.4 がリリースされたので早速導入。 RSS フィルタはこのバージョンのものに変えた。

出力ファイルの文字エンコードを UTF-8 にできるようになったそうだが， 入力は相変わらず Shift-JIS なので今回はパス。 この機能は入力も UTF-8 に対応しないとメリットが薄いような気がする。

打ち消し線のタグが <strike> から <del> に変わっていた。 なるほど， こうすれば lint で怒られないのか。

「kayakayaの日記」 12/15 の記事経由。

• エンジニア的「これって職業病？」大全

だはは！ やっぱ職業病なんだ， これ。

最初の「つい、技術・専門用語が出てしまいます」の事例は「用語」というよりは「隠語」に近いよね。 「オトナ語」のコンピュータ業界版かな。 「親を殺す」とか「子を殺す」なんて会話は身に覚えあり過ぎ。 やはり公衆の場でケータイで仕事の話をするのは控えなきゃ。 何を口走ってるか分からん。

「なんでも計算」はあまりないかな。 「換算」は無意識でやってること多いけど。 でも換算なんてみんなやるよね。 コンピュータエンジニアの「換算」なんて可愛いものでしょ。 「宇宙までの距離は東京-熱海間とほぼ同じ」に比べれば。

分解癖は子供のころが強かった。 何でやらなくなったかというと， 分解したものを元に戻せないのよ，私。

「デフォルト」の話も出てるねぇ。 そういや， 昔の記事をひっくり返してたらこの前とは反対のことを書いていた (^^;)。 いや， やっぱり「既定値」の意味では使ってなかったんだけど， ここ一年くらいで私のコーディングスタイルが激変してるってこと？

「理工学部 Admin 日記」 12/16 の記事に Promotional 版 eTrust Antivirus の導入について記述があったので， 私も真似して実験用に使ってる W2K Server 機に導入してみる。 特に問題はなさそう。

Signature Update だが NAT 越しでも問題ない。 ちゃんと PASV モードで動いてるってことかな？ これでしばらく使ってみよう。

再びツッコミをいただいたので， いただいた情報を元に「超漢字」の仕様に関連するリンクを挙げておく。 情報感謝です。

• 超漢字開発者サイト
• 同 仕様書
• 超漢字ウェブサイト

「超漢字ウェブサイト」を見たけど， 486機でも一応動くんだねぇ。 うちに一台放置プレイ中のがあるんだけど， 少し心揺らめく。

Windows は言わずもがな， Linux にしても最近はやたらとリソースを喰いまくってるのを考えると， 「超漢字」の要求スペックの謙虚さは魅力だよなぁ。

漢字の同定は学術的に微妙すぎて、文字コードで解決しようとすると いつまでたっても文字コードが確定できないからTRONコードでは関知 しないことになったようです。

ってのは割り切り方としては「あり」なのかもしれない。 文字集合は政治的な思惑が絡み過ぎてるし， それに振り回されたくないというのも分かる気がする。 まぁその分アプリケーションに負担がかかってしまうのだが。

• Yes-No

いや， 前後の文脈をすっ飛ばして「君をイラクに送ってもいいの？」だけ読むと， まるで小泉首相が脅迫してるようにみえてしまうところが何とも... (^^;)

しかし今回， 小泉首相がよくも悪くも「決断」したかどうかは怪しい話だ。 考えてみれば自衛隊のイラク派遣は総選挙直後に既に「決定」されていたのである。 「決断」と「決定」では天地ほども違う。 世間が「イラク派遣反対」を唱えればきっと「もし反対なら自民党に投票しなければよかったではないか」と反論されるだろう。 派遣先で死傷者が出れば「先遣隊の見立てが甘かった」と返されるだろう。 そう， 総選挙で自民党が勝った時点で既に選択肢などなかったのである。 選択肢がないのだから責任もとる必要がない。 そういう状況のもとに自衛隊は派遣されるのである。 これが重要だ。

私自身非常に甘い考え方をしていたので他人のことは言えないが， 自衛隊は「軍隊」であり自衛官は「軍人」なのである。 軍人を先遣隊として現地に派遣しておいて， 「現地は危ないので軍を派遣しない方がいい」なんて結論になるわけがないのだ。 そして自衛隊派遣が決定されれば大抵の自衛官は（どこぞの居酒屋の店員ではないが）「よろこんで！」と言うに決まっている。 それは戦争が好きだからでも危険手当が貰えるからでもない。 軍人というのはそういうものだし， そのように訓練されているものからだ。

イギリスのメディアでは 「日本と世界のため政治生命をかけた」 とか 「小泉首相のかけであり、憲法改正論議のきっかけとなる」 とか評されているそうである。 しかし個人的には韓国やシンガポールのメディアが報じる 「平和憲法が無力化した」 とか 「実績作りのため、ます派遣ありきだった」 とかいった見解の方を支持する。

「憲法改正」自体は以前から言われている事なので（たとえそれが小泉首相によるものではなくても）必ず行われるだろう。 しかし今回の「イラク派遣」が「憲法改正」に影響するとは思えない。 「イラク派遣」が示す実績とは「その場の政治判断で世界中どこにでも「日本軍」を派遣できる」というものだ。 その時々に合わせて「なんたら特措法」をでっち上げ自衛官が現地で「視察」すればそれで「軍隊」を送り込めるのである。 国会開催時期を外せば審議も不要。 「憲法改正」なんかよりよっぽど簡単だ。 日本はそういう国であることを内外に示したのである。

21日は行きつけのお店の常連で集まって「忘年会&クリスマス&誕生会」の宴が催された。 昔はこういうイベントはそれぞれ別々でやったものだが， みんな忙しいし身体も持たないしねぇ。

毎年この時期は「クリスチャンでない日本人がどうしてクリスマスを祝うの？」とか「クリスマスなんてク○」みたいな話が噴出してくるが， 酒飲みというのは何時でも何処でも宴会を催す口実を探しているのだ。 酒飲みこそクリスマスを祝わんでどうする， ってなものである。

今回は参加の条件として「ひとり500円程度のプレゼントを用意すること」が提示された。 そんなこと当日に言わんでくれ。 前もって言ってくれれば， 宮島にでも行ってペナントとかしゃもじとか木刀とかおよそ役に立ちそうもないグッズを用意したのに。 かといって東急ハンズや100円ショップで買ったんじゃ絶対に他の人とかぶってしまうし。

ちうワケで， 悩んだ揚げ句文房具屋に行く。 製図用シャーペンを選択。 本当はノギスとかコンパスとかテンプレートとか大抵の人には用のなさそうなものにしたかったのだが， 予算を大幅超過してしまうので泣く泣く諦めた。

そのシャーペンは留学生の娘に渡った。 まっいいか。 私といえば「タイムスリップグリコ」をいただいた。

あとはひたすら飲んで喰う。 やっぱクリスマスは鍋だよね。 すき焼き美味しゅうございました。

今年ももうすぐ終わり。 トップページに置いた「よかった探しリース」のコンテンツは移動した。 なんかクリスマスの飾りを片付けてる気分だよ。

今年は（リアルでは仕事一辺倒だったのとは対照的に）ネットでは色々あった。 大きくはふたつ。 ひとつはサイトの整理と全面的なリニューアルを行ったこと。 もうひとつは Creative Commons に関っちまったこと。

以前 FlowerLounge さんに話してビックリされたことがあるけど， もともと「「クリエイティブ・コモンズ」について」ってこのサイトの運用ポリシーの補足説明のために作ったんだよね。（もちろん単独でも使えるように「完成図書」の体裁をとってるんだけど） それがあちこちのテキストで参照され再利用され， ついには HotWired Japan で記事を書かせていただけるまでエスカレートしちゃうんだもの。 どんな粗末なものであれコンテンツを「再利用可能」にしておくことがいかに大事なことか， あの拙文の使われ方を見ても分かろうというものだろう。 私にとっては全く畑違いの Creative Commons に， いくらかでも首を突っ込ませていただいた経験は今後も役に立つに違いない。

ひとつ難癖をつけるとするなら， 『コモンズ』 の実践（実装）であるはずの Creative Commons （私は今でもそう思っている）についての議論が法的コードに関する内容に偏り過ぎているように見えることだ。 もちろん「使える」ライセンスにするためには法的コードとの整合性について議論することは重要なステップだが， ほとんど何も実装のないうちから「捕らぬ狸の皮算用」をはじめる人達を見ると腹立たしいようなもどかしいような思いでいっぱいになる。 CCPL の位置付けというのは OSI モデルにたとえるなら物理層かせいぜいデータリンク層程度だろう。（たとえが古臭くてゴメン） 人とコンテンツ，コンテンツとコンテンツ，あるいは人と人を「接続」するプロトコルは CCPL より上位の実装だ。 この実装ができれば本格的に人やコンテンツの流通について， そしてそこから生まれる「コモンズ」についての議論とその結果としての「アプリケーション」が生まれる筈だ。 せっかく面白いプロジェクトに関ったのだから， 来年はそういう方向で考察を重ねていきたい。

そういえば更にもうひとつ， 私にとって大きなことがあった。 それは巡回サイトの激増とそれに伴う興味範囲のシフトだ。

最近の私が好きなサイトというのは傾向があるようだ。 豊富に情報を取りそろえているサイトにはあまり行かなくなった。 むしろ絞り込んだ情報を上手に見せるサイトに目が行くようになる。 そういう意味で個人的に好きなのが以下のサイト・コンテンツだ。

• 田中宇の国際ニュース解説／田中宇の国際情勢ウェブログ （田中宇さん）
• J-RCOM （神浦元彰さん）
• 圏外からのひとこと （essa さん）
• 的日記 （Mat さん）
• What's New or What's going on （山根信二さん）
• K嬢の長野県政ウォッチング日記 （K嬢（？）さん）
• バーチャルネット法律娘 真紀奈17歳 （真紀奈さん）

そういえば結城浩さんの日記で特に印象的だったのが親子の会話。 結城浩さんが私の親だったら小学生時代に「算数大嫌い」にならなかったかも， とか思ったり。（私が算数／数学を好きになるには中三まで待たなければならなかった） 「親子の会話」が違う意味で面白いのがいろもの物理学者さんの日記。 12/24 の記事なんかモニタの前で大爆笑してしまった。

最後に私にとって今年のベストコンテンツは例のアレ。

• 固有IDのシンプル・シナリオ

次点は「オトナ語の謎。」かな， やっぱし。 先程の CC の話じゃないが， ネット上のテキストコンテンツの価値のひとつは「いかに「再利用可能」か」ということだと思う。 「固有IDのシンプル・シナリオ」は時事性や反響の大きさも凄かったが， 一番いいのは応用に対する自由度の高さだと思う。

来年も素晴らしいコンテンツに出会えますように。

まずは， @IT より先月の記事の続きが出ているので紹介する。

• 【特集】導入前に知っておきたいバイオメトリクス認証（後編）

よくできてるなぁ。 もうあまりくどくど書かない方がいいかも。 ちうわけで， 宿題になっていた「認証」と「識別」の違いについてのみ書いておく。

セキュリティを問題にする場合の「認証」は， いわゆる PKI の4要素のひとつを指す。 念のため PKI の4要素を書き出すと以下のとおり。

1. 機密性（Confidentiality）
2. 完全性（Integrity）
3. 認証（Authentication）
4. 否認防止（Non-repudiation）

『暗号技術入門』の読者の方は「完全性」を「真正性」と読み替えるといいだろう。 これらの要素は独立に存在しているわけではなくお互いに関連している。 特に「機密性」を除く3つは関連性が高い。 たとえば「完全性」は「認証」の担保となる。 また「完全性」と「認証」は「否認防止」の担保となる。

確実に「認証」を行うのは容易ではない。 『暗号技術入門』の後半部分で特に強調されているが， 「認証」は技術だけでは達成しない。 社会的な要件もシステムに組み込まなければならない。 そのためには「認証」として使われる技術がカバーする範囲を知らなければならない。

仮にバイオメトリクス技術を「認証」に用いたとしよう。 バイオメトリクス技術は「認証」の要件をどこまで満たすことができるのか。

まず， バイオメトリクスによる識別技術には誤差がある。 本人を本人以外と誤認する可能性と本人以外を本人と誤認する可能性である。 どの程度の誤差が現れるかは @IT の記事に示されているので参照して欲しい。 例えばある空港で1日1万人の利用客があるとしよう。 これらの客に対し一人一人顔認証を行うとすると FRR/FAR を併せて1日に200件のエラーが発生する可能性がある。 問題はこれらの誤差を 0 にすることが「できない」ことである。 生体情報は非常に複雑な上に変化するからだ。

もうひとつは「なりすまし」の可能性である。 バイオメトリクス技術における「なりすまし」の問題は色々と議論されている。 この件については以前 kayakaya さんが言及しておられて， 個人的にもいくつかお伺いしたことがあり， その時にいくつか資料を教えていただいた。

• 週間バイオ 33号 （横浜国立大学大学院）： 人工指によるなりすまし
• 週間バイオ 49号 （富士研究所）： 静脈認証について （「kayakaya の日記」 09/12 の記事も参照）
• バイオメトリクス 顔・虹彩で開けゴマ！

しかし， 他の認証技術でも「なりすまし」の可能性はつねにある。 バイオメトリクス技術における「なりすまし」が問題なのは認証に使うデータが生体情報であり， 他のものと取り替えがきかないことである。 したがって「なりすまし」によっていったん破られれば防ぎようがない。

要するにバイオメトリクス技術をつかって「認証」を行おうにも， もとになる生体情報では「完全性」を保証できないのだ。 「完全性」という担保を持たない認証は認証たり得ない。 これこそ私が「バイオメトリクス技術は認証ではない」と言う理由だ。

では， 認証でなければなんなのか。 バイオメトリクス技術は上記の誤差やなりすましの問題を除けば本人識別のための非常に優れた技術だといえる。 他の認証技術と組み合わせて効率的なシステムも構築できる。 たとえば顧客管理とか。 そう， バイオメトリクス技術は「識別」（Identification）技術なのである。

バイオメトリクス技術を「認証」に使うにはどうしても無理がある。 他の認証技術を並列して実装しなければおそらく実用に堪えられない。 それなのに何故バイオメトリクス技術を「認証」と呼び積極的に導入しようとするのか。 そこで前回の話に戻るのである。

最後にひとつ， 最近私が面白いと思った実装例があったので紹介しておこう。

• 沖電気、成田空港で生体認証チェックインシステムの実証実験を開始

このシステムのポイントはふたつ。 まず基になる顔情報を永続的に管理するのではなく搭乗券に格納することで適用されるドメインを限定していること。 もうひとつは PKI 的な「認証」ではなく「本人確認」に限定していること。

搭乗時のセキュリティのために本人確認を徹底させたいという要求は当然のもの。 しかし本人の識別情報を永続的に保存し別の場所で再利用するとなるとプライバシーの観点から利用者の反発もあり得る。 本人を確認するのはチェックイン手続きから実際に搭乗するまでの間で構わないのだから， 搭乗券にデータを乗せるというのは実に合理的である。 よく分からない，って方はこのシステムを「固有IDのシンプル・シナリオ」に当てはめて考えてみるとよい。 バイオメトリクス技術が「識別」技術であるなら使われる生体情報はまさしく「固有ID」である。

参考：

• 「「バイオメトリクス認証」と呼ぶのは止めよう」キャンペーン
• 「認証」という名のレトリック

• H8マイコン基板がトラ技の付録に

おおおっ！ なんちう太っ腹な。 H8 のコンパイラって結構高かったんだよな。 いや， 高かったのは ICE の方か。 2004年4月号か。 こいつぁ買わねば！

やったよ，やった， H8。 結構好き。 8086 みたいに性悪じゃないし。 でも SuperH よりも前の時代のチップ。 懐かしいなぁ...

そういや，上記の記事じゃ gcc がないのがどうとかいってたけど， H8 みたいなシビアなチップに gcc でいけるものなのか？ gcc ってコード効率が悪すぎるイメージがあるんだけど。

私の公開鍵（KeyID: 0xD390BF4CB46A4F0E）の有効期限を2005年1月4日まで延長しました。 以前のは来年 1/4 で期限が切れちゃうので， 私の公開鍵を使っておられる方はアップデートしておいてください。 preferred algorithms も GnuPG 1.2.4 ベースに更新してます。 署名専用鍵（KeyID: 0x1B1B373B76F72BE7）の方は変更なしです。

本当は GPGrelay 経由で OpenPKSD に対してアップデートかけたんだけどうまくいかなくて， しょうがないので JPNIC の鍵サーバに手動で登録した。 なんか手順間違ったかなぁ。

鍵の運用の仕方でいまだに悩んでいる。 今のところの方針は署名専用鍵をメインに据えて， 暗号化可能な鍵はその時々に応じて期限付きで調達する， というものだ。 プライベートで暗号化を行うことはあまりないし仕事ではプロジェクトごとに鍵を生成する必要があるので， この方が都合がいいのだ。 しかしプライベート用の暗号化鍵まで期限付きにするのはやり過ぎだったかなぁと思いはじめている。 署名専用鍵も実は2006年初で期限が切れちゃうんだよねぇ。 署名専用鍵は無期限にして， ヤバそうになった時点で Revoke する方がいいのかもしれない。

• SoftEther Virtual Ethernet System

配布が停止されただの再開されただの， なぁにがそんなに問題なんだと思ったら。 まぁ ssh や SSL を経由できるというのは（パケットが暗号化されちゃうので）確かに管理者泣かせかもしれないけど， 今に始まったことじゃないぢゃん。 OpenVPN だってあるんだし。 （OpenVPN との比較は「セキュリティホール memo」の記事が参考になる） メールだって SSL 経由でやり取りする時代だぜ。

こういうのって結局「通達」と「徹底」でコントロールするしかない。 ファイアウォール等のチューニングである程度カバーできるかもしれないが完全というわけではない。 あとは snort のような IDS ツールで地道にトラフィック解析するとか。 下手くそな無線 LAN の AP と組み合わせられたら目も当てられないけど。 インターネットの基本思想は End to End なんだから， 途中をインターセプトしてコントロールしようとしても無理がある。

しかし， SoftEther は面白そうだなぁ。 でも， 私は今管理者モードじゃないので遊べない。 今の管理者が SoftEther で VPN を構築してくれんかな。

ユーザ認証だけど， Windows プラットフォームなら ISA と連携できるようにすればいいのに。 単独で認証機能を組み込むのは大変だしねぇ。

少し前の話だが， FoaF を更新した。 cocolog に合わせるために少々不本意な記述もしてるけど， まぁこれで当分やってみるつもり。

今回は（戯れ言を含めた）今までの私のドキュメントを foaf:made プロパティで列挙し， 詳細を foaf:Document クラスで記述してみた。 RSS を提示しているドキュメントについては rdfs:seeAlso プロパティで RSS の位置を指示している。 これで FoaF と RSS が一応繋がったことになる。 ちなみにこの FoaF を FoaF Explorer にかけると面白い表示になる。 是非ご覧あれ。

（12/29 追記） また修正した。 cocolog 用の FoaF とここの FoaF は別々に扱うことにした。 ここの FoaF から rdfs:seeAlso で cocolog 用の FoaF に繋いでるので問題あるまい。

今回試したかったのは人とコンテンツの接続。 FoaF の語彙を用いれば人にコンテンツ（組織（foaf:Organization），グループ（foaf:Group），プロジェクト（foaf:Project），文書（foaf:Document），画像（foaf:Image））を接続することができる。 コンテンツを説明するものとしては RSS があるが， RSS に FoaF の語彙を含めることで逆にコンテンツに人を接続することもできる。（これもそのうちやってみるつもり）

少し前から「コンテンツの流通には間に「人」を意識させる仕掛けが必要」なんじゃないかと思いはじめている。 今巷にある P2P をベースにしたファイル交換ソフト（全部じゃないけど）は「匿名性」が意識され過ぎているように思える。 特にコンテンツの「作り手」の存在が見えにくい。 ユーザ間をただ「もの」だけが漂っているようなイメージだ。 本当はもっと人の振る舞いが見えるような形でもいいんじゃないのか。 コンテンツを通して「作り手」と「利用者」が顕名的に結びつくような仕掛けだ。 コンテンツに上記のような RDF 情報を付与し「人」を意識させるような仕掛けができれば， もっと違う「ものの流れ」が発生するんじゃないのか。

...なんてなことを考えはじめている。 まぁまだ妄想段階なんだけど。

なんか面白い企画があるようなので，こっちにもリンク。 その筋の方々が「おおっ！」とか言って反応されると面白いのに， とか独り言を言ってみる。

2002面サイコロ欲しい！ とか思ってしまった。 多面体サイコロを欲しがるのはビョーキですかね。 いや， 私はしませんよ， テーブルトークなんて。 最近はモノポリも MTG も控えてるのに。

明日はカニだ！ きゃほほい。 んでもって来年早々フグ（フク）をいただきに参上の予定。

そろそろ，実家に帰んなきゃ。 今年の更新はこれで終わりです。 来年は（いや，来年も）， お仕事に恵まれますように。 では， また来年。