落語ネタ：ルビという小さな虫

はっつあん：ご隠居さん、ご隠居さん、なんとかしてくださいよ。クライアントの若い編集者がコロナの濃厚接触者になっちまって、昭和生まれの上司がピンチヒッターで出て来たかと思ったら、制作中のコンテンツのルビから小書きの仮名をぜ〜んぶ排除して、普通の仮名に書き換えろ、って言うの。「ルビに小書きの仮名を使うのは、下品だ」なんて言いやがって。 ご隠居さん：おいおい、かりそめにもお客様だろう。その言い草はよろしくないね。ま、気持ちは分からないでもないがね。ルビについては、相変わらず、いろいろなところでいろいろな議論があるね。この際だから、論点だけでも纏めておくかね。

ルビの配置処理は，むつかしいだけでなく，処理法が定まっていないというか，正解がないといってよいと思う．活字組版時代に有力な配置方法があり，今日でも，それにならった配置処理されている例もあるが，コンピュータでの機械的な処理ではなく，ケースによっては，個別箇所でかなり細工をしないといけないのではないかな．

ルビの配置方法には肩ツキと中ツキがあるといわれているが，この用語も2つの解釈があり，そもそも肩ツキと中ツキと指示すればよいということはではなく，それだけではルビの配置位置が決まらないケースも多い．次に例を示すが，ルビ文字のサイズを親文字に1/2とした場合でも，多くの処理方法が考えられる．また，グループルビでは，ほとんどが中ツキと肩ツキという方法とは異なる処理をしている．モノルビ例a.pdf 熟語ルビ例a.pdf

中ツキと肩ツキの2つの意味 1）肩ツキと中ツキは，あくまで，親文字1字に対し，ルビ1字の場合の配置方法である． 2）親文字1字でルビ1字の場合と限定しない．親文字の先頭とルビの文字列（ルビ文字列）の先頭をそろえる方法が肩ツキであり，親文字の文字列（親文字列）とルビ文字列の中心をそろえる方法が中ツキである．

そして，もっとも悩ましいのは，望ましいすべての要求を満たす方法がない場合もある，ということである．どこか不満が残る．ある程度は妥協しないといけないケースもあるということである．

ルビの小書きの仮名ねー，私も，どっちかといえば，小書きは使用したくない派で，老眼だから，小さいルビでは小書きかどうかわからい場合もある．ただ，私は毎月40冊くらい多様な本を読んでいて，ルビとか約物の使用法や配置法，表外漢字の字体など，いろんなことも観察しているんですが，この経験からいえば，今や小書きが多数派になったのではないかな，と感じている．しかし，しばらくは小書きの不使用派は残るので，この問題と付きあっていくしかないでしょう．読み上げなどのことを考えると，元のデータは小書きでも，表現形としては，小書きでない仮名にする処理が選択できるのが望ましいといえよう．ただ，私みたいな人は，いずれ死んでいくから，小書き不使用派は，将来はなくなるんじゃないかな．

すこし昔話をすると，普通の本文でも，小書きの仮名は使用していなかった時代があったんだ．私が仕事を始めた時期には，原稿に“捨て仮名使用”とか，“半音使用”とか指定してあったものを見ている．つまり，原稿に明示しないといけなかったんだ（かつては小書きの仮名は捨て仮名とか，半音とよばれていた）．法令でも“法令における拗音及び促音に用いる「や・ゆ・よ・つ」の表記について”という通知が1988年に出される以前は小書きの仮名は使用されていなかった．

活字組版でも，小書きの仮名は準備されていなく，小さくするには，本文が9ポイントに対し，小書きにする場合は，6ポイントにして処理していた時代もあった．

当然，活字組版ではルビ用の文字には小書きの仮名はなかった．ルビのように小さい文字は区別ができないという考えで使用されなかったのだが，そもそも使用できなかったんだ．それが写真植字などにより小書きの仮名が使用できるようになって，徐々にルビに小書きの仮名が使用されだしていったんだ．それが現在は多数派になり，いつかは一般化されるということなんでしょう．

本文の両側にルビが付いているの、両側ルビの問題も。「りょうがわ」って読むんですか、「りょうそく」って読むんですか。あと、視覚障害者の問題にもからめて、ルビって読み仮名（振り仮名）のことか、広い意味で、行間に置かれた注釈(inter linear annotation)のことか、みたいな揉んだも。印刷雑誌の記事では、それぞれの問題を深掘りするのではなくって、問題圏の拡がりを複数の論点から示す、みたいな方向がいいですね。

中ツキと肩ツキの2つの意味 1）肩ツキと中ツキは，あくまで，親文字1字に対し，ルビ1字の場合の配置方法である． 2）親文字1字でルビ1字の場合と限定しない．親文字の先頭とルビの文字列（ルビ文字列）の先頭をそろえる方法が肩ツキであり，親文字の文字列（親文字列）とルビ文字列の中心をそろえる方法が中ツキである．

中ツキと肩ツキの意味はあいまいですが，主に1で考えた場合，最近は中ツキが多くなったように感じています．以前は肩ツキで処理していた出版社でも中ツキに変えたところもあり，多くは肩ツキを原則としている出版社でも，本によっては中ツキの例も見かけます．

活字組版では，中ツキは，多少は面倒であったからということもありますが，先頭から読んでいくのだから，先頭をそろえた方が読みやすいというか，なじみやすいと考えたのでしょう．これが横組になると，その点よりも，横組のできるだけ左右のバランスをとりたいという要求が強く，中ツキが選択されています．

でも，縦組での肩ツキと中ツキの読みやすさの差は，微妙なものであり，縦組と横組の組方向の変更を予定したデジタルの世界では，縦組も中ツキでいいように思っています．

活字組版時代に有力な配置方法があり，今日でも，それにならった配置処理されている例もあるが，……

この方法については，配置処理がめんどうな主に熟語につけるルビの配置方法について，細部は多少は異なりますが，JLReqの“F. Positioning of Jukugo-ruby（熟語ルビの配置方法）”で説明しておきました． https://www.w3.org/TR/jlreq/#positioning_of_jukugoruby

“活字組版時代に有力な配置方法”を解説した技術書の説明（“校正必携”など）では，原則が示されているだけで，細かい処理はあいまいです．JLReqでは，細かく説明しておきました．

この点について，少し補足しておくと，あそこまで細かく考えて処理する方法を採用することはあると思いますが，デジタルなドキュメントでの組方向を含め，配置処理を読者が変更する，ということを考えると，もっと単純にしてよいのではないか，単純化しないといけないのでは，と最近は思い始めています．

本文の両側にルビが付いているの、両側ルビの問題も。「りょうがわ」って読むんですか、「りょうそく」って読むんですか。あと、視覚障害者の問題にもからめて、ルビって読み仮名（振り仮名）のことか、広い意味で、行間に置かれた注釈(inter linear annotation)のことか、みたいな揉んだも。印刷雑誌の記事では、それぞれの問題を深掘りするのではなくって、問題圏の拡がりを複数の論点から示す、みたいな方向がいいですね。

私も，そのように考えています．

“りょうがわ”なんでしょうね．国語辞典では，“りょうがわ”はあるが，“りょうそく”は，採用されていないんではないかな．

両側ルビと行間に置かれた注釈は，最後の方で問題にしようと思っています．日本史では，最近，“百済”を“くだら”ではなく“ひゃくさい”，“白村江”も“はくすきのえ”ではなく，“はくそんこう”と読むようで，読みが2つあるよ，ということで両側にルビを付けたい例も結構見かけますし，両側に付けたいという要望は，それなりにあるのでしょう．

配置方法によるルビの種類としては，次の3つがほしい． 1）モノルビ：親文字が1文字 2）グループルビ：親文字が2文字以上で，親文字列全体に対してルビを配置（配置方法はいろいろある） 3）熟語ルビ：熟語に付けるルビで，個々の漢字の読みとの対応を考慮し，かつ，熟語としてのまとまりも考えてルビを配置する

1は親文字は1字であるが，2と3は，親文字が複数になる．なお，熟語ルビの場合，個々の漢字ごとに対応したルビを示すとともに，ルビも熟語としてのまとまりを示す必要がある．熟語としてのまとまりを示しておけば，読み上げの際に単語として扱うことも可能になる．

熟語ルビは，熟語としてのまとまりを重視する配置方法であるが，ドキュメントの目的として，個々の漢字の読みを示したいというケースもある．また，熟語ルビでもグループルビの配置と同じ処理とすると処理が単純化できる．そこで，スイッチを付けるなどして，実際の表示（表現型）としては，モノルビ的な処理やグループルビ的な処理が選択できるとよい．

ただ，何を熟語とするかという問題がある．例えば，姓名の場合，姓名を1つのまとまり（熟語）と考えるか，姓と名とを別々のまとまりと考えるか，東京都といった場合では，“東京都”か，“東京”＋“都”かという問題である．これは著者または編集者の判断によるというか，元データの作成方法に従うということでよい．

この熟語ルビは，前述のJLReqの“F. Positioning of Jukugo-ruby（熟語ルビの配置方法）”は，デジタルのドキュメントでは簡単ではない．そこで簡略化が求められる．その方法は，あとでごく簡単に説明する予定である．

なお，熟語に付けるルビでは，熟語の一部だけ，例えば常用漢字に含まれない漢字にだけルビを付ける例も見かけるが，読んでいく場合は，言葉（熟語）を単位として読んでいくことが多いので，熟語の一部ではなく，全部に付けるのが望ましいでしょう．一般の書籍では一部だけにルビを付ける例は，ほとんど見かけない．，

ルビは，そもそも必要なの，という議論が昔あった．山本有三が“戰爭と二人の婦人”（岩波書店，1938年）の“あとがき”で振り仮名（ルビ）の廃止を主張したことがきっかけで，多くの議論があった．その多くは白水社編“ふりがな廃止論とその批判”（白水社，1938年）という本にまとめられている．この本は，日比谷図書文化館，東京都の中央区や都立図書館などで所蔵しているので読むことができる．

一つのことを二列に書くのは愚かしいことだとも書いているが，そもそも，ルビを付けなくても読める，やさしい言いまわし，やさしい言葉にすべきである，といのが山本の主張である．これに対し，橋本進吉は，同書のなかで弊害もあるが，“著者の言葉を最正確に伝えることができる”，“通読を容易ならしめる（ふりがなのある方が早く読める）”，“言葉が不統一になるのを防ぐ”，“知らないものに漢字のよみ方を知らせ，又，言葉をどんな漢字で書くべきかを教える”といったふりがなの効用を記し，ふりがな廃止に賛成していない．

こうしたこともあり，戦後に内閣告示された“当用漢字表”の“使用上の注意事項で“ふりがなは，原則として使わない”との説明もされている．この影響もあり，ルビの使用は一時は少なくなった．

しかし，書籍などではルビは使用されており，1981年の“常用漢字表”の答申前文では，“読みにくいと思われるような場合は，必要に応じて振り仮名を用いるような配慮をするのも一つの方法であろう”と述べている．今日では，書籍に限れば，ルビを使用していない例は少ないといえよう．

なお，ルビの代わりに親文字の直後に括弧に入れて示す，ポップアップで表示するという方法もある．括弧に入れて示す場合，数が少なければよいが，以前，すべての漢字について，その読みを括弧に入れて示したものを読んだことがある．とても読めたものではなく，読むのを途中で放棄した例もあった．また，ポップアップも数が少ない場合はよいが，数が多くなると，かえって読むのを妨げるケースもあるので，その方法は，完全にルビの代用になるとはいえない．

また，アクセシビリティを向上させるひとつの方法としてルビは有効であり，そのためには，特にデジタルのドキュメントではルビの機能をより利用しやすいように改良していくことが必要であろう．いくつか例示しておく．　全部に漢字にルビを付ける（自動化されれば，なおよい）．　ルビが逆に障害になる場合もあり，ルビ表示をする／しないの選択を可能にする．　更にいえば，ルビの性格（パラルビなど）や漢字の種類により，レベルをつけて，表示／非表示の選択ができるとよい，　ルビの文字を大きくできるようにする．　ルビに色を付けることを可能にする．　親文字とルビの間隔は，文字の外枠を接して配置するのが原則であるが，選択により，この間隔を空けて配置できるようにする．

ただし，個々の人により要求内容の違いは大きく，要求内容が逆の場合もある．読者の側で変更が可能になるとよい．

モノルビ，グループルビ，熟語ルビの配置方法について簡単に解説しておく．

モノルビの配置方法について，主なものとしては，以下がある．　1　親文字の中心とルビ文字列の中心をそろえる．　2　親文字の先頭とルビ文字列の先頭をそろえる　3　親文字の先頭とルビ文字列の先頭をそろえる方法を原則とするが，ルビ文字列がはみ出した場合，後ろへのはみ出しを優先する．後ろにはみ出すことができない場合は前にはみ出す．行頭・行末の位置や前後の文字種によりルビと親文字との位置関係は変わることがある．

グループルビの配置方法について，主なものとしては，以下がある．　1　短い方の文字列の先頭，末尾及び字間を空ける．先頭及び末尾と字間との比率は，原則として1/2にする．　2　短い方の文字列の字間だけを空け，両方の長さをそろえる．　3　親文字列とルビ文字列ともにベタ組とし，それぞれの中心をそろえる．

熟語ルビの配置方法について，主なものとしては，以下がある．　1　熟語ルビを構成する各親文字に対応するルビの文字列の長さにより，各親文字に対応するルビをモノルビで処理するか，又は熟語ルビ全体をグループルビとして処理する．　2　熟語ルビを構成する各親文字に対応するルビの組み合わせにより，それぞれをモノルビとして処理する．　3　熟語ルビ全体をグループルビとして処理する．　4　熟語内で各親文字と対応するルビが親文字からはみ出した場合，熟語内における前後の別の漢字に親文字サイズで1/2まで掛かってよいが，各親文字と対応するルビ1字は少なくとも該当する親文字に掛かっていないといけない，という処理を行う．この方式では，親文字列からのルビのはみ出しは，後ろへのはみ出しを優先する．前後の文字種や行頭・行末の位置によりルビと親文字との位置関係は変わることがある．

なお，ルビの代わりに親文字の直後に括弧に入れて示す，ポップアップで表示するという方法もある．括弧に入れて示す場合，数が少なければよいが，以前，すべての漢字について，その読みを括弧に入れて示したものを読んだことがある．とても読めたものではなく，読むのを途中で放棄した例もあった．

慶應義塾の中野先生の調査によれば、パーレンで囲ったフリガナを弱視者さえも嫌うようです。もちろん、晴眼者も嫌います。弱視者でさえルビのほうが好きだとあれば、ルビとどう付き合うかを考えるほうが大事でしょうね。

熟語や用語などで複数の読み方がある例もあり，これらをルビで示すために親文字の両側に付けている例を最近は見かける（両側ルビ），　例　白村江：はくそんこう，はくすきのえ　　　東南：とうなん，たつみ　　　向日葵：ひまわり，sunflower，サンフラワーこうした処理について，自動処理を前提とするデジタルなドキュメントで実現する必要はあるのだろうか．あるにこしたことはないが，どれだけ必要とするかが問題である．書籍では実例はあるが，数は少ないのが現状である．であるならば，ひとつは括弧に入れるなど別の表現手段もあるので，コストベネフィットを考慮するならば，機能としては取り入れないというのも，ひとつの判断であろう．どうであろうか．

両側ルビのもうひとつの問題は，自動処理を前提すとする場合，なんらかの処理方法を決める必要がある．両側ルビの処理方法については，JIS X 4051に規定がある．ただし，モノルビとグループルビの組合せしか規定していない．熟語ルビを組合せた方法は規定していない．しかも，この方法は，一般で行われている方法というわけではなく，ある意味でモノルビとグループルビそれぞれの配置処理から考えられる方法として書かれたものである．ある意味で両側ルビの決まった配置方法はない，ともいえるし，不完全だがJISに規定があるので，それでよいともいえる，

なお，W3CのWarking Draftとして公開されている以下の“Rules for Simple Placement of Japanese Ruby”では，熟語ルビ含めた処理方法が記されている（オリジナルの和文のドキュメントも，ここから参照できる）． https://www.w3.org/TR/simple-ruby/

さらに，両側にルビを付けた場合，隣の行のルビと重なってしまう恐れもある．こうした場合の行間の処理方法も考えておく必要がある．

親文字からルビ文字列がはみ出した場合，前後の文字に掛けるか掛けないか．これについては以下のような方法がある．　1　親文字の前後の文字には，アキのある約物を除き，掛けない．　2　親文字の前後の漢字には掛けないが，仮名や一部の約物には親文字サイズの1/2まで掛けてよい．　3　親文字の前後の文字には，文字種を限らないで親文字サイズの1/4まで掛けてよい．

また，行頭と行末では，行頭ではルビ文字列の先頭，行末でもルビ文字列の末尾をそろえる，という方法と，行頭では親文字の先頭，行末でも親文字の末尾をそろえる方法がある．．

ルビに似た組版処理に行間に配置する注がある．行間注などと呼ばれている．歴史の教科書など用語や人名に簡単な説明を付ける場合に利用されている例を見かける．また，小説などで，複数の説明を同時に行うために利用される例もある．注の形式にはいろいろあるが，縦組の頭注・脚注，横組のサイドノートなどに比べると，行間注は少ないと思われますが，ある意味で便利な注の形式ですので，根強い要望はあるでしょう．

注というものは，できるだけ近くにあると，すぐに参照できて，たしかに便利である．割注の要望が根強いのも，そうした理由からであろう．しかし，確実に参照が予定され，しかも，分量が短い場合は，それでもよい．しかし，注は必ずしも参照されるわけではなく，あると，読んでいく際の妨げになる場合もあり，注を邪魔に感じる場合もある．．その意味で，近くにあるのが望ましいが，本文の読んでいく際の妨げにならないようにしてほしいという矛盾した要求がある．この要求を比較的に満たしているのが横組の脚注であり，縦組の傍注である．横組の注として最も多いのは脚注形式であるのは，そんな理由があるからだろう．縦組の傍注は，かつては組版処理が面倒であることから，あまり見かけなかったが，最近はやや増えているように感じている．

注として，比較的に多いのが巻末にまとめた後注である．これは参照するのに少し手間がかかるという欠点がある．でも，あまり参照されない注では利用価値がある．私が読む書籍では，この後注が多い．そこでどうしているかといえば，本文を読む前に，あらかじめ後注をざっと眺めておき，参照の必要性を前もって判断しておく．必要ないと思えば，いっさい参照しない，本文の内容により部分的に参照する，常に参照するという方法を使い分けている．参照される必要性が少ない場合は，利用価値があると思っている．

このように注というものは一筋縄にいかないもので，注の形式の選択は，著者なり編集者の判断が大切である．

話がすこしずれたが，本題の行間注の必要性であるが，私はあまり高いとは思っていない．

もしこの行間注を実現するとした場合は，以下の3つが考えられる．　1　ルビの機能を拡張して，行間注が利用できるようにする．　2　ルビの機能を拡張するが，モノルビ，グループルビ，熟語ルビに追加して新たに行間注（名前を注ルビとでも変えてよい）を追加する．　3　ルビの機能とは別に，あらたに行間注の機能を追加する． 2の方法では，親文字として位置だけが指定されたものとすれば，他のルビ形式から区別できる．ただし，親文字列を選択できないという欠点がある．なにか親文字列の指定で区別できれば，この欠点はなくなる．

私は，もし行間注の機能を実現したいのであれば3が望ましいと思っている．それは，ルビの機能から考えて，かなり無理を行わないといけないからである．つまり，ルビとは，その組版処理の内容について，相当に異なっている，といえるからである．

以下，その違いを考えてみる．

まず，親文字について

ルビの場合の親文字は，文字1字か，複合語を含めた単語である．ですから親文字の長さはある程度の長さにとどまる．また，グループルビでは親文字列の分割は許されていない．これに対し，行間注の場合，多くの対象が考えられ，1字の文字，単語だけでなく，文，さらには段落全体も対象になる．当然に親文字列の2行にわたる分割も可能にしておく必要がある．親文字列を指示する方法は，親文字列を具体的に指示するだけでなく，位置だけが指示されていてもよい．

次にルビまたは行間注のテキスト

ルビの場合，文字種はある程度は限られている，また，モノルビやグループルビではルビ文字列の2行にわたる分割は禁止されている．熟語ルビでも，各親文字ごとに対応したルビのまとまりについては分割できない．

これに対し，注記に使用する文字種も様々である．となると文字間のアキなど，行処理にともなう種々の禁則処理を決めないといけないし，2行にわたる分割できる位置も問題となる（原則として本文と同じでよい）．

また，ルビでは，親文字との対応は強く，親文字列からはみ出したルビ文字列が親文字列の前後の文字に掛からないのが望ましい（ある条件で，限られた範囲では認める場合がある）．これに対し，行間注では，そのような条件を付けると組版処理が不可能になる場合もでてくる．

行間注（以下，注ルビという）の配置処理についても，ルビとは大きく異なる．以下に行間注の配置処理の方法について簡単にまとめておく．

1　注ルビの行送り方向の配置位置は，先頭側をデフォルトとして，指定により末尾側にも配置できるものとする．（縦組では右側，横組では下側の例があるので）

2　注ルビ文字列と指定された親文字の前後の文字に対し，行送り方向のそれぞれの文字の外枠を接して配置する．ただし，指定により空けることを可能にしてもよい．

3　注ルビ文字列の字間処理は，本文と同じとする．ただし，先頭又は末尾に配置する括弧類，句読点の前又は後ろの二分アキは確保しないものとする．また，2行に分割する場合の処理は，本文の処理と同じとし（つまり，2行への分割な可能な位置では分割できる），行末にアキがでた場合には，そのアキを確保し，行の調整処理は行わない．

4　注ルビの親文字に対する字詰め方向の配置位置は，次とする．デフォルトは4.1とする． 4.1　親文字の位置に対し，注ルビ文字列の字詰め方向の中心をそえる． 4.2　親文字の位置に対し，注ルビ文字列の字詰め方向の先頭をそろえる． 4.3　親文字の位置に対し，注ルビ文字列の字詰め方向の末尾をそろえる．　＊末尾を選べば，行間に配置する注番号も，これで処理できます．

5　注ルビ文字列が親文字のある行の先頭又は末尾よりはみ出した場合は，次の順序ではみ出した注ルビ文字列を配置する． 5.1　注ルビ文字列の字詰め方向の中心をそえる場合は，親文字の位置から両側に延ばし，行の先頭又は末尾を超えるときは，親文字の逆方向の前又は後ろに延ばし，それでも配置できないときは，段落の先頭行の先頭及び末尾行の両方向に延ばす．段落の先頭行の先頭又は末尾行の末尾に達した場合は，逆方向に延ばす． 5.2　注ルビ文字列の字詰め方向の先頭をそえる場合は，親文字の位置から末尾側に延ばし，行の末尾を超えるときは，その行の前方向に延ばし，それでも配置できないときは，段落の末尾側の行に伸ばし，段落の最終行の末尾に達したときは，先頭側に延ばす． 5.3　注ルビ文字列の字詰め方向の末尾をそえる場合は，親文字の位置から先頭側に延ばし，行の先頭を超えるときは，その行の後ろ方向に延ばし，それでも配置できないときは，段落の先頭側の行に伸ばし，段落の先頭行の先頭に達したときは，末尾側に延ばす．なお，注ルビ文字列が，段落の先頭及び末尾よりはみ出した場合は，上記と同様にして，前後の段落に延ばす．

ルビ処理では，さまざまなケースが出現し，また，ルビで実現したい目的もいろいろとある．つまり要求事項も多い．また，ルビ処理では，誤読されないことが第一に必要なことであるが，読みやすさも考慮しないといけない．

一方で，デジタルなドキュメントでは，自動処理が求められており，例外のあまりでない，機械的に処理できる方法を考えていく必要がある．その際には，ある程度の割り切りというか，妥協も必要である．

こうした点を考慮したルビの処理方法について，W3CのJLReqタスクフォースでは検討を作業を行っており，“Rules for Simple Placement of Japanese Ruby (ルビの簡便な配置ルール) ”（Editor's draft (編集草案) ）を公開している． https://www.w3.org/TR/simple-ruby/

w3c / jlreq

落語ネタ：ルビという小さな虫 #323