● アップルコンピュータは「改正されたJIS X 0213には対応済み」
（特別編23から続く）ある意味でマイクロソフトの方針と正反対の立場をとるのがアップルコンピュータだ。2月6日に行なわれたイベント『PAGE2004』（主催：日本印刷技術協会）において、マイクロソフトの阿南康宏氏の次にマイクを握ったアップルの木田泰夫氏（CJKテクノロジーインターナショナルテキストグループ）は、今回の改正を「一見複雑に見えるかもしれないが、すでにUnicodeにはあった文字が、JIS X 0213に含まれるようになったというだけ」とシンプルに総括した上で、「例示字体が変更されたが、それらの文字の形はすべてMac OS Xの標準フォント、ヒラギノにはすでに存在している」と指摘し、結果として「改正されたJIS X 0213には、すでに対応済み」とした。結果としてアップルは、マイクロソフトの対応とは反対にフォントデザインは変更しない。これが同社の対応策だ。
この木田氏のコメントは非常に簡潔だったので補足説明が必要だろう。アップルは2001年9月リリースのMac OS X 10.1の時点で、すでに表外漢字字体表にあるすべての文字を収録したヒラギノフォントをバンドルしている。木田氏の「対応済み」という言葉は、このことに基づいている。
改正が決まらない前から、どうして改正に対応することができたのだろう？ それは同社のMac OS Xにおける純正フォントの文字実装モデルを説明することが回答になる。同時にその説明は、なぜ同社はマイクロソフトのように、純正フォントのタイプフェイスを、改正JIS X 0213例示字体に基づいたデザインに変更するといった「大技」に出なかったのかという疑問への回答にもなる。
● まず「文字の形」から集め、次に文字コード規格と対応づける
多言語OSであるMac OS Xは、さまざまな言語のフォントを標準添付している。ここで取り上げるのは『ヒラギノ明朝W3 Pro』をはじめとして「Pro」が名前に付属する5つの日本語フォントだ。これは一般に「Pro版」[*1]などと呼ばれるが、この原稿では特に「ヒラギノフォント」と総称することにする。
他にも用語の定義が必要なものがある。この原稿では、文字同士を比較してたびたび「同じ字」とか「一致・合致」などの表現を使うが、これは文字の形がぴたりと一致することを意味しないことに注意してほしい。完全に「同じ字」など、この世にめったに存在するものではない。
特別編19でも詳述したが、例えば牛丼の吉野屋の「吉」の上部が「土」か「士」かという違いを、多くの人が意識しないことからもわかる通り、私たちは日常の中で、細かな形の違い（デザインの違い）を無視して「同じ文字」と認識している。そうした「社会の中で同じとされる範囲」を明示したのが、例えばJIS X 0208／JIS X 0213の「包摂規準」なのだが、これに限らず「違う」文字を集めてセットを規定すれば、そこには「違う字と同じ字の境界線」があることになる。
これは「ふるい」の網の目に喩えられるだろう。ふるいが変われば網の目の大きさも変わる。一般に文字セットの総数が多くなるほど網の目は細かくなり、違いはより多く弁別され、結果としてセットの総数も多くなる道理だ。例えばJIS X 0208包摂規準の網の目より、これから説明するAdobe-Japan1-5の方が、はるかに細かな違いを見分ける。
以下、この原稿で使われる「同じ字」や「一致・合致」といった表現は、上記のような考え方を踏まえたものであり、そこでは必ずなんらかの仕様／規格にのっとって判断されるはずだ。結果として、ぴたりと一致しなくても「同じ字」と書くことになる。先取りすると、じつはアップルとマイクロソフトの改正JIS X 0213対応策を分けるものは、こうした文字に対する考え方の違いなのだが、それは最後まで読んだお楽しみとしよう。
では本論に入ろう。ヒラギノフォントの文字セットの特徴は、大小4つのセットが整然と積み重なって1つの構造をなしているところにある（図1）。
■図1-1 ヒラギノフォントにおける文字セットのピラミッド構造（1）
 |
| 下に行くほど文字の数は増えていき、より下はより上を包括する構造になっている。例えばAdobe-Japan1-5の差分は図の赤い部分だけだが、Adobe-Japan1-5の総体はピラミッド全体となる。同様にUnicodeの差分は黄土色の部分だけだが、Unicode総体としてはこれより上の部分全体となる |
■図1-2 ヒラギノフォントにおける文字セットのピラミッド構造（2）
 |
| 全体構造をわかりやすくするため、図1-1を横に倒すとこのようになる。複数のピラミッドが重なり合っており、上面に露出した部分が差分ということになる |
■図1-3 ヒラギノフォントにおけるUnicodeはサブセット
 |
| ただし、文字セット同士の大きさの対比という意味で言えば、ピラミッド構造というのは正確さを欠く。上図のように、もともと4つの文字セット中でUnicodeは一番大きく、ヒラギノフォントが実装するのはそのサブセットだからだ。他はすべてフルセットを実装しており、ピラミッド形は維持される。また、Unicode全体として見てもAdobe-Japan1-5とは一部重ならないのは前図と同様 |
これは、どのようにして作られたのだろう？ 収録された文字の属性をよく吟味することにより、やがて「このようにしてしか作られなかったはず」という手順が浮かび上がってくる。それは、おそらく以下のようなものであったはずだ。
ひと言で同社の実装を言えば、「“字形”優先主義」となるだろうか。まず最初に文字コード規格とは関係なく、「これだけあれば需要は満たせる」というだけの「文字の形＝字形」を集め[*2]、これに「グリフ番号」（CID＝Character IDentifier）というものを割り当てる。
その数は2001年9月のMac OS X 10.1時点で20,296文字、現行バージョンと同じ完成形となった2003年2月のバージョン10.2.4時点[*3]で20,317文字に及んでいる。このヒラギノフォントの文字セット名を、10.1では『アップルパブリッシンググリフセット（APGS）』、10.2.4以降は『Adobe-Japan1-5』[*4]と呼ぶ。
文字の形を集めたら、ようやく文字コード規格の出番だ。初めにJIS X 0208と突き合わせ、合致したものにJIS X 0208の符号位置を与える。同様にJIS X 0213（当然、改正前の初版）と突き合わせ、合致したものに符号位置を与える[*5]。なお、Mac OS Xはデフォルトの符号化方法としてUnicodeを採用しているから、正確に言うと、ここで実装されるのは、JISで規定されているUCS（≒Unicode）へのマッピングということになる[*6]。ここまでの文字を『文字パレット』上で「日本語」[*7]として分類し、純正の日本語入力プログラム『ことえり』の初期設定時の変換範囲とする。
次に残った文字とUnicodeを突き合わせ、同じ文字があればその符号位置を割り当てる。ここまでがUnicodeの符号位置を持った文字だ。そしてここまでの作業で残った、どれとも対応づけられなかった文字が、図1-1では赤で示したAdobe-Japan1-5差分に落ちる。これは、符号位置ではなくグリフ番号だけを使って表示・印刷することにする。以上の流れをフローチャートにまとめてみた。
■図2 ヒラギノフォント実装の手順
上図のポイントは水色の部分、つまりヒラギノフォントの文字すべてが符号位置を持ってはいないというところで[*8]、これにより既存OSのように文字コード規格にメーカー外字を付け足して作ったのでなく、意図的にまず必要な字形を集め、それに符号位置を後付けしたものだとわかる。私がヒラギノフォントの実装を「“字形”優先主義」とする理由だ。
● 表外漢字字体表に対しても同じ作業を実施
アップルは表外漢字字体表（2000年）に対しても上述の作業をしたと思われる。つまりこれをJIS X 0208、JIS X 0213と付け合わせ、一致するものに符号位置を割り当てる（図1で言うと上から1、2番目の階層に落ちる）。これらと一致しなかった文字はUnicodeと突き合わせ、一致したら符号位置を割り当てる（同じく3番目の階層に落ちる）。最後にいずれとも一致しないものを最下層に割り当てる。
こうした作業の結果、ヒラギノフォントはJIS X 0213に対応するのはもちろん、表外漢字表にも対応することになった。しかもこれは、2001年9月のMac OS X 10.1の時点からだ（ちなみに原稿執筆の2004年10月時点での最新バージョンは10.3.5）。マイクロソフトがJIS X 0213サポートを予告している『Longhorn』が2006年末の発売予定だから、そこから数えれば約5年も前ということになる。
Mac OS X 10.1発売当時のパンフレット[*9]を見ると、ヒラギノフォントの特徴として「JIS X 0213:2000のサポート」を挙げ、〈JIS（日本工業規格）の新しい漢字集合規格「JIS X 0213:2000」をフルにサポートしており、Unicodeに対応したアプリケーション等から使用することができます。業界標準規格をベースとしていますので、「JIS X 0213:2000」を採用するシステム間であれば、インターネットを介した情報交換も可能です。〉（p.6）とある。この「JIS X 0213:2000」とは改正前の初版だ。
次回は、本当にヒラギノフォントが改正JIS X 0213をサポートしているのか、実際に入力しながら検証してみよう。
[*1]……ヒラギノフォントには、「Std」を末尾に付けるフォントもあり（Std版）、これはAdobe-Japan1-5とは下位互換の関係にあるAdobe-Japan1-3の文字セットに準拠している。なお、Mac OS Xの各バージョンとそこにバンドルされるヒラギノフォントPro版、Std版のバージョン、収容文字数、対応するUnicodeのバージョンなどの相関関係は、大日本スクリーン製造のWebページで詳しく整理されている。これを見ると、例えばPro版は完成形である現行ver.7.11まで3回のバージョンアップが重ねられたことがわかる。
ヒラギノOpenTypeとMac OS Xのバージョン相関表
http://www.screen.co.jp/ga_product/sento/support/otf_ver.html
|
|
[*2]……文字の形を集めるに際しては、まずJIS X 0208の文字セットを基本とし、それに積み増しする形でJIS X 0213の差分（第3、第4水準）を集め、さらにこれでは足りないものを電算写植の文字セットで補うという方法をとっている。後者は2000年当時も、印刷業界で大きなシェアを持っていた写研によるものだ。こうしたことから、アップルはこの文字セットの訴求対象を、DTPに移行できずにいた電算写植ユーザーと想定したいたことがわかる。つまり、ごく普通のユーザーはこの文字セット全部を使うことは想定されていない。一般向けにはJIS X 0208のセットがあり、これを補うものとしてJIS X 0213があり、さらに補うのがUnicode、そしてプロ向けにはAdobe-Japan1-5という考え方なのだ。
|
|
[*3]……正確に言えば、10.2.4に先行する10.2.3の中にも、Adobe-Japan1-5をサポートするものが存在する。注1で引用した『ヒラギノOpenTypeとMac OS Xのバージョン相関表』を見ると、ビルド番号6G30がAPGS（20,299文字）をサポートする一方、6H58と6H60がAdobe-Japan1-5（20,317文字）をサポートしていることがわかる。実際、アップルも「Adobe-Japan1-5は10.2.3から」としている。ただしこれらはPowerBookなどへのバンドル版固有のビルド番号であり、一般ユーザーが初めて20,317文字を使えるようになったのは、10.2.4以降だ
|
[*4]……『Adobe-Japan1』はアドビシステムズによるCID／OpenTypeフォントのための文字セット規格。ハイフンに続く番号がバージョンを表わす。増えた分だけ上積みされるので、過去のバージョンとは上位互換となる。なお2004年6月11日、アドビシステムズはAdobe-Japan1-6を発表した。これにより、以前まで仕様書は1-4以前と1-5差分に分けて公開されていたが、1つのファイルにまとめられることになった。
Adobe-Japan1-6 Character Collection for CID-Keyed Fonts
http://partners.adobe.com/public/developer/en/font/5078.Adobe-Japan1-6.pdf
この1-6の差分は共同通信社が策定した新聞各社に配信するための私的な文字コード規格『U-PRESS』をサポートするための非漢字と、1-5まででサポートされなかったJIS X 0212（補助漢字）の漢字等を収録するもの。
私の質問に答えてアドビシズテムズの山本太郎氏（日本語タイポグラフィマネージャ）は、基本的にAdobe-Japan1という文字セットは日本で使われるさまざまな用途に向けて開発されたものであり、このうちどの部分をサポートするかは製品の用途や性格、メーカーの方針によって選択されるべきとし、同社としては現時点で1-6をフル実装するフォントの発売計画はないことを明らかにした。[追記]
一部には、この1-6をアップルが2005年前半に発売を予定しているMac OS Xの次期バージョン『Tiger』に搭載するのではないかという観測もある。しかし、従来からアップルもアドビシズテムズと同様の立場から、1-5は最大文字集合であり、これをフル実装する必要はないと繰り返し表明していた。こうしたことを考えると、Tigerで1-6がサポートされる可能性は極めて低いと考えられる。
|
|
[*5]……規格の上から言うと、JIS X 0213はJIS X 0208部分とJIS X 0213差分の2つの部分に分かれるが、Mac OS Xでもこの2つの部分によって対応が変わる。前者については入力に際してなんのアラートも出ないが、後者の文字については入力対象のアプリケーションが扱うことのできる文字コードの範囲や使用目的に応じて、注意を促すアラートが出ることになっている。ここからJIS X 0208こそが、なんの注釈もいらない日本語の共通基盤であるという考え方が伺える。
|
[*6]……ここで問題になるのはJIS X 0213:2000（初版）制定時点でUCS（ISO/IEC 10646）未収録だった「カッコ付きUCS符号位置」の扱いだ。この問題については特別編4を参照してほしいが、簡単に言うと規格票において、UCS未収録文字へのマッピングがUCSとは無関係にカッコ付きで掲載されてしまったという問題だ。残念なことに、このうち39文字がMac OS X 10.1とその後のバージョン間で化けることになってしまった（注図1、2）。化けてしまう文字を、それぞれのバージョンの文字パレットで表示させれば、何が原因で化けるのか、事態は明確になる（注図3、4）。
■注図1
 |
| Mac OS X 10.1のうち39字が…… |
■注図2
 |
| Mac OS X 10.1.5にバージョンアップした後、再度開くと化けてしまう。1文字減ったように見えるのは、このバージョンでは文字列最後の符号位置に文字イメージがマッピングされていないため |
■注図3
 |
| Mac OS X 10.1の文字パレット。この中のFA45～FA4Bを注目してほしい |
■注図4
 |
| Mac OS X 10.10.1.5の文字パレット。10.1と比べると、FA45にあった「概」の異体字がなくなり、これ以降がそっくり1文字ずつずれている。これによりFA45以降の39文字が化けるわけだ |
Mac OS X 10.1当時にこれらの文字を使って作成した書類は、バージョンアップして再度開くと化けるので、現行バージョンを使っているユーザーも注意が必要だ。また、これらはMac OS X 10.1とUnicodeをサポートする他のプラットフォーム（例えばWindows XP）の間でも、フォントに依存はするが、やはり化ける（注図5）。
■注図5
この現象はアップルが10.1発売後に、文字コードのマッピングを変更したことにより発生する。問題はどの時点で変更されたかだが、同社の技術文書「Technical Note TN2043 Mac OS X: v10.1.1-10.1.3」（2002年5月6日、英文、http://developer.apple.com/technotes/tn/tn2043.html）を読むと、10.1.3（2002年2月公開）で行なわれたことがわかる。[訂正2]
さて、ではなぜこのようなことが起きたのか？ これはUCS（ISO/IEC 10646）における、カッコ付きUCS符号位置の審議過程と深く関係している。アップルが「もう動かない」と判断して実装に踏み切ったであろう原案に、Mac OS X 10.1発売後になって誤りが見つかり、異動が出てしまったのだ。同社はマッピングを正規の符号位置に変更せざるを得ず、文字化けは起こることになった。
問題のカッコ付きUCS符号位置は、CJK互換漢字としてISO/IEC 10646-1:2000の追補1（Amendment-1）に収録されることになっていた。原案作成を担当する国際機関のWG 2委員会の公開文書のうち、見つけられた限りで最も新しい、FA45に「概」の異体字が割り当てられた文書は、2001年6月付『N2388』（http://std.dkuug.dk/jtc1/sc2/open/02n3530.pdf、p.45）だ。この『N2388』は最初のページに「For further processing as an FDAM by SC2」とあるように、WG 2の上部機関であるSC 2委員会に送られる「FPDAM」（Final Proposal Draft AMendment：最終追補原案の提案）だ。Mac OS X 10.1のマッピングは、この文書と一致する。
このFPDAMの誤りを指摘したのが2001年10月『N2389』（http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/n2389.doc）[訂正1]。これは先のN2388に対する各国コメントを集めたもので、2001年10月15～19日に開かれたシンガポール会議での審議文書。11～12ページの見出し「T.11」を見てほしい。米国代表団から、FA45として提案されている文字は69EAとして収録済みという指摘がある。会議の報告書『N 2404R』（http://std.dkuug.dk/JTC1/SC2/WG2/docs/n2404r.doc）1ページ「RESOLUTION M41.1」を読むと、これは各国から受け入れられ、FA45以降を1つずつずらすと決まったことがわかる。この変更は同時に開催されていたSC 2総会でも承認され、そのまま最上位機関であるJTC 1に送付されている。その日本代表団による報告が『SC 2総会報告』（http://www.itscj.ipsj.or.jp/report/02_200110.html）。ちなみにMac OS X 10.1の発売が2001年9月。このシンガポール会議のわずか1カ月前のことであった。
追補についての大ざっぱな制定過程について、下の表にまとめてみた。
■注表1 2001年当時の追補（Amendment）の制定過程
| 段階 | 略語 | 原語 | 筆者訳
| | 提案段階 | NP | New Project | 新規事業 |
| 作成段階 | WD | Working Draft | 作業原案 |
| 委員会段階 | PDAM | Proposal Draft Amendment | 追補原案の提案 |
| FPDAM | Final Proposal Draft AMendment | 最終追補原案の提案 |
| 承認段階 | FDAM | Final Draft AMendment | 最終追補原案 |
| 発行段階 | AMD | Amendment | 追補 |
アップルはこのうち「委員会段階」の最後であるFPDAMを実装したことになる。同社は発売段階での実装をあきらめ、アップデータで対処することにしさえれば、マッピングを変更することなく「承認段階」であるFDAMを実装できた。そしてこの後、符号表は変更されることなく、翌2002年7月発行に至っている。この期間のSC 2／WG 2各委員会の動きを追って感じるのだが、私にはアップルがJIS X 0213のフルサポートを、少し急ぎすぎたように思える。
化けてしまう39文字の中には、つい先頃、正式な人名用漢字に格上げされた文字（10.1発売時は人名用漢字許容字体表）が含まれている。これらを名前に使っている人にとって文字化けは深刻だろう。これについてアップルに照会したところ、以下のようなコメントをもらった。
アップルとして問題回避のための10.1.5アップデータを提供しており、ほとんどの方がそれを導入したか、それ以降のバージョンにすでに移行しています。10.1.5アップデータは10.1を未だお使いのユーザーの方のために現在でも提供中です。
アップデータで解決可能かどうかが問題なのではない。今まで同社がこの現象について沈黙していたことが問題なのではないか。化ける文字は本当に39文字だけだろうか？ 同社はこれ以降もマッピングを変更していないのだろうか？ 悲しいことだが、今の私には確言できない。率直でオープンな対応こそが、信頼回復の近道であるように思う。
|
|
[*7]……これはバージョン10.2以降での呼び方。10.1では「新JIS」となっていた。
|
|
[*8]……これら符号位置を持たない文字は、アップルが独自に仕様拡張したRTF（Rich Text Format）で書き出せる。これにより符号位置がなくてもMac OS X同士ならば情報交換が可能となる。アップルによれば、同社はサン・マイクロシステムズ、アドビシステムズ、ジャストシステムと共同で、こうした符号位置を持たない文字の情報交換を可能にするための機構をUnicodeに提案しているとのことだ。
|
|
[*9]…… http://images.apple.com/jp/datasheet/software/pdfs/MacOS_X101_DS.pdf。なお、6ページに〈「JIS X 0213:2000」を採用するシステム間であれば、インターネットを介した情報交換も可能です。〉とあるが、注6にある通り、少なくとも39文字については当てはまらない。
|
● 付記
筆者は『デザイン、DTPのためのフォントの鉄則』（オブスキュアインク編、毎日コミュニケーションズ、2003年）において、本稿では触れられなかったAdobe-Japan1-4の詳細や、文字コード規格との関係について書いたことがある。興味のある向きは参照されたい。
◆修正履歴
[訂正1]……注6にある文書『N2389』のURLを間違って掲載していた。お詫びして以下のように訂正する。
誤：http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/n2389.pdf
正：http://anubis.dkuug.dk/JTC1/SC2/WG2/docs/n2389.doc
『スラッシュドット』のマックセクション（http://slashdot.jp/mac/）でご指摘いただいた、Livingdeadさん（http://slashdot.jp/comments.pl?sid=226055&cid=659956）とT.MURACHIさん（http://slashdot.jp/comments.pl?sid=226055&cid=659995）に感謝します。（2004/12/6）
[訂正2]……私は注6において、39文字が化ける現象を取り上げて、詳細な情報を公開しないアップルコンピュータの姿勢を批判した。これについて読者の方から以下の文書の存在をお知らせいただいた。
「Technical Note TN2043 Mac OS X: v10.1.1-10.1.3」（2002年5月6日、英文）
http://developer.apple.com/technotes/tn/tn2043.html
この文書の「Font Manager」の項には、「ヒラギノフォントのcmapテーブル、Zapfテーブルにあった、JIS X 0213とUnicodeのマッピングのバグを修正」とある。また「Text Encoding Converter」の項には、39文字の変更前と変更後の面区点位置とUnicode符号位置が掲載されている。つまり、同社はマッピングの変更後にその事実を公開していたことになる。この事実に基づき、原稿を以下のように修正する。
◎修正前
この現象はアップルが10.1発売後に、文字コードのマッピングを変更したことにより発生する。問題はどの時点で変更したかだが、今のところは10.1.5以前としか把握できない。現在10.1以降のアップデータは、最終版である10.1.5への統合版しか公開されていないからだ。これ以前のアップデータが入手できない以上、現在は「10.1.1～10.1.5のいずれかで変更」とするしかない。ただし、注1で引用した『ヒラギノOpenTypeとMac OS Xのバージョン相関表』をじっと見ると、10.1.3（2002年2月公開）あたりが怪しいように思える。
◎修正後
この現象はアップルが10.1発売後に、文字コードのマッピングを変更したことにより発生する。問題はどの時点で変更されたかだが、同社の技術文書「Technical Note TN2043 Mac OS X: v10.1.1-10.1.3」（2002年5月6日、英文、http://developer.apple.com/technotes/tn/tn2043.html）を読むと、10.1.3（2002年2月公開）で行なわれたことがわかる。
さらに、以下の1文をそっくり削除する。
これについてアップルは今まで一切公表してこなかったが、無責任と言えないだろうか。少なくとも同社は、ユーザーが影響を正確に把握できるよう、どのバージョンでマッピングを変更したのかを知らせる義務があると思う。
アップルコンピュータの皆様にご迷惑をおかけしたことをお詫びするとともに、このことを『スラッシュドット』のマックセクション（http://slashdot.jp/mac/）でご指摘いただいた匿名氏（http://slashdot.jp/comments.pl?sid=226055&cid=662629）に感謝します。（2004/12/10）
[追記]……注4において、アドビシステムズのAdobe-Japan1-6への方針として「同社としては現時点で1-6をフル実装するフォントの発売計画はないことを明らかにした。」と書いた。しかしその後、読者からの「Adobe Reader 7.0用のJapanese font packにはAdobe-Japan1-6規格と思われるフォントが含まれている」というお知らせにより、同社はAdobe-Japan1-6を実装した『Adobe Reader Japanese Fonts』の配布を開始していることがわかった。入手方法は以下の通り。
Windowsで動作するAdobe Reader 5.0以降がインストールされていること、HDDに15MB以上の空き容量があることが必要。条件を満たすなら以下のURLにアクセス。
http://www.adobe.com/products/acrobat/acrrasianfontpack.html
「version」は適宜、「Language」は「Japanese」を選択してダウンロード、インストールする。フォントがインストールされるパスは以下の通り。
C: Program Files Adobe Acrobat X.X Resource CIDFont
この中の「KozMinProVI-Regular.otf」がAdobe-Japan1-6をサポートしたフォントである。
Adobe-Japan1-6フォントの日本における配布については、現在同社に問い合わせ中だ。わかり次第お知らせしようと思う。「Adobe Reader 7.0用のJapanese font packにはAdobe-Japan1-6規格と思われるフォントが含まれている」という情報を提供してくださった読者の方に感謝いたします。
なお、この追記は何度が修整している。詳細は以下のURLのうち、[XML MOJI 01573]以降を参照。（2005/1/18）
http://www2.xml.gr.jp/1ml_main.html?MLID=xmlmoji
（ 小形克宏 ）
2004/11/29
- ページの先頭へ-
 |
|
|
 Copyright ©2004 Impress Corporation, an Impress Group company. All rights reserved. |
|
