図:Active Directoryのふりがな属性
図:Active Directoryのふりがな属性
[画像のクリックで拡大表示]

 5月に公開した「ついに実現したActive Directoryの『ふりがな』機能」という記事について,この機能がLDAP標準から逸脱しているのではないかと指摘された。実は,編集部からはコメントが付いてすぐに連絡を受けていたのだが,何が問題か理解できなかったので放置していた。先日,Mozilla24の実行委員でもあった及川氏のblogを見て,初めて問題に気付いた次第である。全く申し訳ない。私に誤解があるのか,コメントした人に誤解があるのか分からないので,一般的な話をしておこう。

 LDAPは,X.500をベースに,RFCで定義された標準規約である。LDAPは,RFC 2252で決められた属性規約に従う必要がある。「RFCで定義された属性のみを使うべきだ」ということであれば,Active Directoryはご要望に添えない。別の製品を使ってください。拡張を禁止すると,最新技術の採用はできなくなるが,安定した運用が可能になる。

 ただしLDAPのRFCでは,一定の条件を守ればベンダー毎の拡張が許されている。もちろん,Active Directoryはこの条件に基づいて属性を拡張している。拡張が許されないと,SIDやSID History等の重要なWindows機能が実装できず,Active Directoryは存在し得ない。ふりがな機能も,ベンダー固有の拡張の1つである。ふりがなにはmsDS-Phoneticで始まる属性名が使われる()。msDSで始まる名前は,明らかにマイクロソフト固有の実装である。この名前はRFCその他の公的標準にはないが,既に他の業界標準で使われているのであれば,マイクロソフトの実装に問題がある。しかし,筆者の知る限り(読者コメントでは,頻繁に「この程度の知識」と呼ばれる程度の知識でしかないが)そういう標準はない。

 「ふりがな機能は非常に有益なので,ベンダー固有の実装は適切でない」ということであれば,確かにおっしゃるとおりである。コラムを書いた時点では知らなかったが,既にふりがなを実装している処理系もあるようだ。マイクロソフトの功績として強調するのは適切ではなかった。しかしActive Directoryの新機能として,日本から働きかけた結果が実った事実を伝えることには意味があったと信じている。ふりがなが最も有効なのは,単一の文字に複数の読みがある場合だ。このような文字は(筆者の乏しい知識の範囲では)日本語だけである。中国語は,異なる時代や方言によって読み方は変わるが,ある時点での共通語としての読みは同じである(2007年9月28日:追記があります)。韓国語もそうだ。ふりがなを使った検索にはメリットがあっても,日本語ほどには便利さを感じないと思われる。

2007年9月28日:追記

 中国語にも,同じ漢字で違う読みをするものがあるという指摘をいただきました。

 例えば,「行」xingと読む場合は「行く・行なう・流通する・旅・良い…」等の意味があり,hangと読む場合は「職業・行,列・商店」などの意味になります。旅行の「行」はxing,銀行の「行」はhangだそうです。

 「還」は「返す」という意味の時はhuanと読み,「まだ」という意味のときはhaiと読みます。このほかにも「了」(liao/le),「的」(di/de)など,使い方によって発音が変わるということです。

 コラムの記載が事実ではなかったことを,お詫びして訂正させていただきます。

追記終わり

 ついでなので,標準について,及川氏のまとめを借りて補足しよう。氏によると,標準を逸脱するパターンには大きく分けて以下の4つがあるという。

(1)相互運用や互換などを考慮する必要がほとんどないため,標準化のための作業を一切排除したい場合

(2)標準化にかかる時間が長期に渡るため,早期に市場にその技術を紹介したい場合

(3)標準化のプロセスが複雑であったり政治的な活動が必要であったりして,そのコストに見合うメリットが無いと判断される場合

(4)標準化の前に意図的に市場でその技術を普及させることを考えている場合(政治的な判断でデファクト標準化の後にデジュール標準化を図るような場合)

 なお(4)で触れた「デファクト標準」は「業界標準」,「デジュール標準」は「公的標準」のことである。ITU-T勧告はデジュール標準,RFCは形式的にはデファクト標準だが事実上のデジュール標準である。

 Active Directoryのふりがな機能は(2)に相当する。(1)でないことは明らかである。実態は別として,相互運用性はActive Directoryの登場以来の売り文句である。(3)は,最近のマイクロソフトの動きからするとRFC化を望んでいるはずである。ITU-T等の厳密な標準と異なり,RFCのハードルはそれほど高くない。(4)は,以前マイクロソフトによく見られた姿勢だが,現在はあまり意図していないように思える。

 結局,ふりがなを実装する優先度が非常に高く,次期バージョンまで待てないと判断したのだろう。日本市場を重視したという意味ではありがたい話である。他のLDAP製品との相互運用は,属性名の変換で対応できると思うのだがいかがだろう。