EPUB3は，HTMLとCSSなどのWeb技術に基づいた電子書籍フォーマットである。EPUB3は国際化されており，その1つとして日本語組版を扱うことができる。縦書き等の機能は，まずW3CにおいてCSS Writing ModesとCSS Textを作成し，次にIDPFにおいてこれらをもとにEPUB3を作成することによって導入された。この標準化経験に基づいて，国際的標準化において日本が陥りやすい落とし穴を指摘し，成功するアプローチを示唆する。
電子書籍のためのフォーマットとしてEPUBが注目されている。EPUBは米国をはじめとして世界中で用いられ始めており，各国における国内規格化および国際規格化も検討されている。従来用いられてきたのはEPUB2であるが，その次期バージョンであるEPUB31)の制定はすでに完了しており，2012年には急速に普及することが予想されている。縦書き・ルビを含む日本語組版はEPUB2ではほとんど扱えなかったのに対し，EPUB3ではこれらを扱えるように拡張されている。
EPUB3の国際化では高いハードルを乗り越えなければならなかった。W3C注1)のHTMLとCSS注2)に日本語組版を導入し，それをただちにEPUB3に取り込むことである。仕様制定（特にW3C）には時間がかかるので，このハードルを乗り越えられたのは奇跡と評する人もいる。
本稿では，EPUBを簡単に説明したのち，その国際化がどのように行われたかを述べる。さらに，どのようにすれば国際標準化に失敗するかを述べたあとで，どうすれば成功するかをその裏返しとして示す。
EPUBは，HTML5を筆頭とするWeb技術に基づく電子書籍フォーマットである。EPUBを制定しているのは，International Digital Publishing Forum（IDPF）という国際的なフォーラムである。EPUBの仕様書は誰でも無料で入手できるし，EPUB書籍を作成しても誰にもライセンス料を払う必要はない。
EPUBは，リフロー型のフォーマットである。すなわち，閲覧に用いる機器・ソフトウェアおよびユーザーの指定によってページ数が変わる。逆に言えば，閲覧環境とユーザーにふさわしいページレイアウトが自動的に行われる。
リフローの反対の固定レイアウト，すなわちどんな閲覧環境であってもページ数が変わらない書籍も，EPUBでは扱うことができる。固定レイアウトの取り扱いをさらに容易にするため，固定レイアウト用メタデータ語彙（メタデータとして指定できる値の集まり）が2012年3月に公開予定である。
EPUBにはいくつもの重要な特徴があるが，それらを単に列挙しても本質はかえって見えにくくなる。EPUBで最も大事なのは，以下の3つの理念だと筆者は考える。
これらがIDPFの公式文書に理念として記されているわけではないし，これらとは関係ない機能（たとえば数式）も多い。しかし，EPUBはこれらの理念をもとに設計されたと筆者は思うし，EPUB3が他のフォーマットとは一線を画す理由もここにあると信じる。
理念1と3についてまず簡単に説明する。理念1は，HTML5をはじめとするW3C技術を採用することによって体現される。端的に言えば，EPUBはHTML文書などの複数のファイルをZIPで固めたものにすぎない。理念3は，アクセシビリティを目的とするDAISYコンソーシアムと連携し，DAISYの機構を採用することによって体現される。
一方，世界中の言語・文化を扱うという理念2は，EPUB2まではほとんど実現されていなかった。以下に，いくつかの欠点を示す。
EPUB3においては，これらの問題が解決し国際化は大きく前進した。縦書き，禁則，ルビ，右開きは，すべて取り入れられている。具体的には，CSSのモジュールであるCSS Writing Modes2)とCSS Text3)を取り入れることによって，縦書きと右開きを実現している。ルビは，HTML5を採用することによって実現している。HTML5のruby要素がルビを表す。
図1に，EPUB3で表現した『草枕』（夏目漱石）のソースを示す（XMLエディタのoXygenを利用している）。左側のサブウインドウに示されているのはZIPファイルであるEPUB書籍の中のフォルダ階層であり，右側のウインドウに示されているのはHTML5文書のソースである。ruby要素が使われていることに注意されたい。図2は，同じEPUB書籍を，電子書籍オーサリングソフトウェアFUSEeβで表示したところである。HTML5文書から参照されているCSSスタイルシートが縦書きを指定しているので，縦書きレイアウトになっている。
EPUB3の細部には本稿では立ち入らない。よい解説書が日本でも出版されつつあるので，それらを参照されたい。
EPUB3の国際化という歴史を語るのに，ここでは，日本における流れ，W3Cにおける流れ，IDPFにおける流れについて順に説明する。
日本では，JIS X 4051日本語文書の組版方法4) (日本語文書の行，版面およびページについての基本的な組版方法を規定したJIS規格）が以前から組版の専門家によって進められ，さらにW3Cノート「日本語組版処理の要件」5)が英語と日本語の両方で出版された。この2つは，どちらも組版の要件を規定したものであって，それをマークアップ言語・スタイルシート言語でどう実現するかは扱わない。このW3Cノートは国内ではそれほど知られてはいないが，世界でとても高く評価されており，台湾の組版にもあてはまる部分は多いという。
W3Cでは，縦書きを含んだ仕様が勧告候補（勧告になる2つ前の段階）まで進んだが，問題点を指摘されて頓挫していた。この仕様はInternet Explorerで実装されたにも関わらずまったく普及していなかった。一方，ルビはXHTMLへの追加として設計され，HTML5にも取り込まれつつあった。
IDPFでは，EPUB3の制定が2011年に開始されることになり，日本語組版についての要求項目の提案がいくつかの関係者によってなされた。特に重要なのは日本電子出版協会（JEPA）から提出されたMinimal Requirements on EPUB for Japanese Text Layout6)であり，これはW3Cノート「日本語組版処理の要件」からの抜粋である。台湾も縦書きの実現についてIDPFにロビー活動を展開した。
IDPF EPUB WG の第1回会議（2010年6月）で，Enhanced Global Language Support（EGLS）サブグループを作ること，筆者がそのコーディネーターに就任することが決まった。このEGLSサブグループは，札幌（2010年8月）と台北（2010年10月）の2回の対面会議を行い，国際化についての要求仕様と実際の仕様をそれぞれ検討した。この活動に触発され，W3Cにおける縦書きの仕様制定は急速に進んだ。EGLSの提案は，EPUB WGの第2回会議（2010年11月）で概ね承認され，EPUB3（2011年10月）に取り込まれた。
3.2 IDPFにおける困難EPUB3で日本語組版に急いで対処するためには，国際化のためのサブグループをIDPF EPUB WGの下に設けること，そしてそのリーダーシップをとることが必要だと筆者は最初から考えていた。今までIDPFの活動に加わったことがなかったにも関わらず筆者がコーディネーターになれたのにはいくつかの要因がある。
2回の対面会議のうち，特に難しかったのは札幌会議であった。この時点で台湾・韓国の参加者とは筆者は初対面であった。この会議で要求仕様をまとめること，参加者相互の信頼を確立することに成功しなければEPUB3の国際化は失敗していただろう。会議の前のひりつくような緊張感は忘れ難い。国内にはEPUBの国際化を支持する組織もほとんどなく，JEPAが会場費と懇親会費を負担し，マイクロソフト社がコーヒ代を負担してくれただけであった。むしろ会議の妨げとなりかねない動きが国内にはあった。
一方，会議に参加してくれた専門家は，会議を実りあるものにすることに大きく貢献してくれた。台湾・韓国からの参加者も満足してくれたように見受けられた。会議の終わりに台北会議の開催を決めた。台北会議では，台湾側の手厚いもてなしを受けた。
3.3 W3Cにおける困難冒頭にも書いたように，W3CのHTMLとCSSを国際化し，それをただちにEPUB3に取り込むのは並大抵のことではない。この困難さは最初から見えていた。
W3Cとの整合を諦めIDPFで独自拡張しようという案は最初からずっと筆者の頭の中にあった。しかし，この方法は，Webと電子書籍のシナジーを追求するという理念1に反する。WebKit注5)などのブラウザ実装がIDPF独自拡張に対応するかどうか，ユーザーがついてくるかどうかも不明である。
この困難を突破できたのは，村上真雄氏の熱意に始まり，続いてはElika Etemad（Fantasai）氏と石井宏治氏を中心とした突貫工事による。CSS Writing Modesは，最初のワーキングドラフト（2010年12月）から最新のワーキングドラフト（2011年9月）まで，なんと5回も改定されている。彼らの献身的な努力のおかげで，CSS Writing ModesとCSS Textはワーキングドラフトの段階まで進み，EPUBからなんとか参照できるようになった。
EPUBの都合に合わせて，W3CはCSS Writing ModesとCSS Textを進めたことになる。仕様というものはできても普及するとは限らないし，タイミングを逃せば失敗する。EPUB3は，Webで縦書きを実現するおそらく最後のチャンスであったと筆者は信じる。
3.4 HTMLレンダリングエンジンWebKitでの実装仕様は制定さえすればよいというものではなく，実装されて初めて意味を持つ。CSS Writing ModesおよびCSS Textは，2010年10月ごろからApple社によってWebKitの一部として実装され始めた。WebKitはオープンソースのHTMLレンダリングエンジンであり，ブラウザのSafariやChromeに用いられ，多くのモバイル機器でも動作する。今後，EPUB3のための閲覧システムとしては，WebKitベースのものが増えると予測されている。2012年2月に，IDPFが旗振り役となって始めたEPUB3オープンソース実装のReadiumも，WebKitに基づいている。
WebKitにおける日本語組版の実装は，前述の活動に関わった方々との密接な情報交換のもとに行われた。仕様制定と実装の両方にとって幸福なことだったと思う。
国際の場でどう行動すれば，日本語についての要件を満たすようにすることができるだろうか。まず，典型的であって駄目な発想を示し，それを否定する形で国際の場で勝つ発想を示す。
4.1.1 国内合意から始めるという発想国内で日本語組版に関する有識者を集めて議論し，得られた結果を国際で通すという発想がある。これは日本では当たり前の発想であり，普通はこう振る舞うだろう。しかし，これはうまくいかないことが多い。EPUBのときにこう振る舞っていたら，確実に失敗していただろう。以下に何が問題なのかを示す。
(1) 国際へ出ていく人にとっての問題点日本の中で議論しているとき，所属する組織とその中での地位は重要かも知れない。しかし，国際の場に出たとき，国内の企業・肩書はほとんど何の意味も持たない。それがどうした，世界に通用する実装がある会社ならともかく⋯⋯というのが国際の反応であろう。
4.1.3 夜郎自大の発想世界標準はアングロサクソンが握っている，アングロサクソンは英語のことしか考えていない，アングロサクソンに日本人が異を唱えなければならないという発想が一部にある。こういう発想を持つ人は，中国・韓国・台湾の要求さえもろくに知らず，中東他の文化圏にいたっては完全に無知なことが多い。一方，ヨーロッパどころか，中東やアジアのことまで知っている人が国際の場にはいることがある。彼らからすると，こういう発想は夜郎自大でしかない。下郎，推参なりと切って捨てられても仕方がない。
4.2 国際の場で勝つ発想これまで述べてきたことを逆にすれば，そのまま国際の場で勝つ発想が見えてくる。
こういう発想で行動すると，国内では反感を買うことはよく知っている。しかし，国際の場で勝とうと思えば，こういう発想はイロハのイである。
4.2.1 具体例EPUB3への漢数字やイロハの導入を，国際の場での戦いの実例として示す。これらはさほど重要な機構ではないが，技術内容は誰にでも理解できるので，国際の場で勝つ発想がどんなものかをわかりやすく示すのに適している。なお，この件はアップルの木田泰夫氏とグルーソフトウェアの石井宏治氏がおもに成し遂げたことであり，私はほとんど関わっていない。
(1) 背景番号を自動生成する機構がCSSには含まれている。HTMLの箇条書きのとき番号が振られるのは，これが自動的に適用されるからである。EPUBはCSSとHTMLを採用しているので，番号を自動生成する機構をこれらから引き継いでいる。
ここで問題となるのは，漢数字やイロハの自動生成がCSS 2.1には含まれていないことである（後述するがCSS 2.0には入っていた）。EPUB3 はCSS 2.1を基準としているので，普通に考えればEPUB3にもこれらは入らないことになる。
(2) 負ける発想漢数字やイロハがないと日本では困る，だからEPUB3に入れてくれというのが負ける発想である。国際の場では，どんな反応が返ってくるかは簡単に予想できる。CSS 2.1にないならW3C CSS WGで拡張を提案すべきだと言われるだろうし，日本だけの都合でCSS 2.1をベースとするという原則を曲げることはできないと言われるだろう。こういう発想では，通るものも通らない。
(3) 勝つ発想外資系企業（アップルとマイクロソフト）で鍛え上げられた木田泰夫氏と石井宏治氏は，まったく別の発想をする。日本ということを少しでも目立たなくしようとするし，日本のユーザー要求すら積極的には持ち出さない。
まず，EPUB2との互換性を主張する。CSS 2.1にはない番号生成方式がCSS 2.0にはいくつか含まれていた。EPUB2 はCSS 2.0をベースとしたので，EPUB2にも当然含まれている。互換性のために，EPUB3でも落とさないことが望ましい。CSS 2.1にない番号生成方式はすべて国際化に関連するものなので，国際化のためにも落とすべきでない。
それでは，なぜCSS 2.1ではいくつかの番号生成方式をあえて除いたのだろう。CSS 2.1は，CSS 2.0にある曖昧さを取り除くことが最優先であった。そのため，ある時点で実装されていない機能はすべて落とされてしまった。しかし，その後になって，WebKitなどの実装ではいくつかの番号生成方式が追加された。CSS 2.1から落ちてしまったのは仕方ないが，すでに実装されたものをEPUB3からあえて落とす理由はないのではないか。
この主張にはまったく異論が出ず，ほんの数分審議しただけで簡単に通った。結果として通ったのは，ヘブライ語の番号生成，漢数字，アイウ，あいう，イロハ，いろはの五つである。説明のときに例として使ったのは，むしろヘブライ語の番号生成方式であった。
4.3 駄目な拡張方法日本語に対応する機能を仕様書の中にどう盛り込むかについても，日本では十分に理解されていないように見受けられる。
4.3.1 駄目な拡張方法1: 追加の別仕様書EPUB本体に追加する日本語拡張仕様書を別途に作るのがよいと考える人がおそらく日本には多いだろう。総務省の支援事業の名称である「EPUB日本語拡張仕様策定」もこの方法を示唆している。昔は，この方法しかなかったかも知れない。しかし，今となってはまったく駄目な方法であることは断言できる。
なぜ駄目なのだろう。まず，この方法は，国際的には日本語対応はやらなくてもいい，EPUB本体だけを実装すればよいと言っているのに等しい。それでは日本語に対応しない実装が普通になってしまうだろう。より本質的な問題は，日本語拡張部分が他の言語から孤立してしまうことである。他の言語との共通部分をできるだけ見出す努力をしていかなければ，仕様制定においても実装においても，日本人だけですべてをやらないといけなくなってしまう。コストにも跳ね返るし，アクセシビリティは疎かになるだろう。
4.3.2 駄目な拡張方法2: 妙な変種EPUB本体とは別に，日本語EPUB仕様を作るという動きがないわけではなかった。これは，標準的なツールが使えないという意味でただの独自仕様であり，論外といえる。
4.4 望ましい拡張方法前項で説明した2つをまったく反対にしたものが，望ましい拡張の仕方である。つまり，EPUB3本体のなかに日本語関連部分が組み込まれて渾然一体となり，どの部分が日本語に関係するのかは一見してもわからないことが望ましい。実際のEPUB3はこうなっているし，XMLもUnicodeも同様である。
IDPFにおけるEPUB3仕様制定活動は，国際化サブグループリーダーとしての責任も重くのしかかっていたが，やりがいのある仕事，使命感をもって取り組める仕事であった。今となってみればただひたすら楽しかったとすら思う。
国内では苦い思いをさせられることがいろいろあった。しかし，陰鬱な音程でこの稿を終えたくはない，うれしかったことを書いて締めくくりとしたい。
EPUB3の制定後，2011年11月に，台湾を再び訪問したとき，中央研究院の何博士と再会することができた。博士はEGLSの2回のミーティングの参加者である。台湾は，縦書きと注印符号をぜひEPUBに入れてくれとIDPFに熱心に要請し，私がリードするEGLSサブグループに期待と不安を感じながら札幌にやってきた。私は何博士の到着を待って一献を傾け，会議中も台湾の意見をよく聞くことを心がけた。
博士は，私のリーダーシップに従ってよかった，電子書籍だけではなくWebブラウザにまでわれわれは影響を与えることができたと言ってくれた。台湾の信頼を得ることができたのは，EGLSサブグループが成功した理由の1つである。夜郎自大では軽蔑を買うだけだが，他と協調しつつリーダーシップを発揮すれば尊敬されるのだと思う。
