艦長日誌・私的記録 DS9

　コンピュータは，これまで様々な工夫で速く動作するように作られてきました。その当時は最先端だったことでも，今は非常に基礎的なものとなっていたりするのですが，何分普段使うものではないので，ついつい忘れてしまいがちです。

　そこで，この場をちょっとした復習に使おうと思います。第1回目はパイプラインです。

問題:あるCPUも命令実行におけるパイプライン処理が，以下の6段のステージをもつとする。

　F:命令読みだし（instruction fetch）
　D:命令解読（instruction decode）
　A:番地計算（address calculation）
　B:オペランド読みだし（operand fetch）
　E:命令実行（instruction execution）
　W:結果格納（write back）

　パイプライン処理を行わない場合，命令実行Eの所要時間は15ns，Eを除く各ステージの所要時間は10nsであるとする。また，パイプライン処理を行う場合は，上記の他に各ステージにおいて2ns必要となる。2nsの打ち合わせは，クロックスキューの調整とパイプライン処理の準備のための時間である。この時，以下の問いに答えよ。

1)パイプライン処理を行わない場合の実行過程（時間を横軸）を3命令分図示せよ。
2)パイプライン処理を行う場合，ステージの所要時間（パイプラインピッチ）はいくらとなるか？
3)パイプライン処理を行う場合の命令実行過程を3命令分図示せよ。
4)パイプライン処理による定常状態における速度向上率を求めよ。
5)命令実行パイプライン処理の流れを阻害する要因（ハザード）について説明せよ。

回答:

1)

　このCPUは6つのステージを持っていますが，Eステージだけは15nsかかり，それ以外は10nsで処理が出来るということです。Eステージというのは実際の命令の処理を行う部分ですから，時間が余計にかかる傾向があります。そこでここをさらに2つに分けるなどして，処理時間を短くするようなことも行われます。

　パイプライン処理を行わない，つまり順番に3命令分処理するという事ですので，以下のように書くことができます。下の数字は時刻です。

　Ｆ　Ｄ　Ａ　Ｂ　Ｅ　Ｗ　Ｆ　Ｄ　Ａ　Ｂ　Ｅ　Ｗ　Ｆ　Ｄ　Ａ　Ｂ　Ｅ　Ｗ
0 10 20 30 40 55 65 75 85 95 105 120 130 140 150 160 170 185 195
　
　このCPUは，3命令を実行するのに195nsかかるという事になりますね。1命令当たりの65nsかかっています。

2)

　パイプライン処理というのは，各ステージを同時に実行していく方法です。パイプラインというより，ベルトコンベアという感じが正しいと思います。1つの製品を作るのに1時間かかるとしても，1つの行程が10分の流れ作業で作ると，完成品は10分に一度の割合で出てきます。ということは，見た目には1つの製品を10分で作っているように見えるわけです。

　一見ウソのように思いますが，これはウソでもなんでもなく，6つの行程がひっきりなしに動いているからです。いわば，1つの製品を作るの必要な工程を順番にせず，一気に同時に行っているから時間が短くなっていると考えられるわけですね。

　ややこしいのは，ステージの時間が揃っていない場合です。自分が5分で出来ても，次の人が10分かかっていたら，次の人の手前にものが溜まってしまい，結局10分に一度しかものが完成しません。つまり，一番長い時間のかかる処理に全ての処理を揃えて上げないと，パイプライン処理というのは成り立たないのです。

　さて，このCPUは，6つのステージに分かれています。それぞれのステージの処理時間は，Eを除いて10ns，Eだけは15nsかかります。

　このCPUでパイプライン処理を行う場合，一番遅いステージに揃えて上げる必要があります。一番遅いのはEの15nsに2nsを確か足した17nsですので，全てのステージを17nsで並べて上げるとよさそうです。この17nsという数字が，パイプラインピッチです。

3)

　では，実際にパイプライン処理を図示してみましょう。

　Ｆ　Ｄ　Ａ　Ｂ　Ｅ　Ｗ
　　　Ｆ　Ｄ　Ａ　Ｂ　Ｅ　Ｗ
　　　　　Ｆ　Ｄ　Ａ　Ｂ　Ｅ　Ｗ
0 17 34 51 68 85 102 119 136

　どうですか，始めと終わりに全てのステージが動いていない部分がありますが，3命令とは言わずたくさんの命令を流せば，ほとんどの時刻で全てのステージが動いてくれそうです。

　実際，同じ3命令の仕事をパイプライン処理することで60ns近くも早く終わらせることに成功しています。この威力は大きいです。

4)

　まず，パイプライン処理をしなかった場合の処理時間ですが，これは1)にあるように，195nsです。

　これをパイプライン処理にした場合，3)のように136nsで済んでいます。速度向上率は，(195-136)/136*100=43.38%です。

　一番遅いステージに揃え，なおかつ各ステージに2nsの余計な時間がかかってしまうとしても，4割も速度が上がっています。これがパイプライン処理の効能です。

5)

　ところで，4)の「定常状態」なのですが，では定常状態ではない時というのはどういう時かというと，ステージが遊んでしまうような状態をさします。例えば分岐命令があった場合に起こる状態です。

　分岐命令があると，その後に続く命令が確定しません。ですから確定するまで，次の命令が取り込まれることなく，各ステージはしばらく遊んでしまいます。

　これをハザードといいます。

　パイプライン処理というのは並列処理の一種ですから，前後の命令が時間的に相関がある，つまり前の命令の結果が後ろの命令に影響を与えるような場合，同時に処理することは出来ません。

　分岐もそうですし，他にも前の命令で計算した結果を次の命令で使うような場合，前の命令の処理が完了しないと後ろの命令が実行できません。

　こうしたハザードをなんの対策も行わずに放置すると，せっかくのパイプライン処理が台無しになってしまうので，いろいろな対策を盛り込むことになります。

　まず，前の命令の結果を続く命令が利用する場合です。これは，前の命令の計算結果が出るステージから，結果を次に使うステージにバイパスしてやれば，前の命令の完了を待たずに済みます。これをレジスタフォワーディングといいます。

　レジスタフォワーディングでも間に合わない様な場合，残念ながら結果が出るまで次の命令の実行を止めます。この待ち時間をロード遅延といい，ロード遅延を行うために必要なパイプラインを止める仕組みを，インタロックといいます。

　ロード遅延を許さず，必ずパイプラインを止める方法もありますが，もしも後の命令と依存関係のない命令と順番を入れ替えることが出来るなら，パイプラインを止めずに済みます。これを遅延ロードといいます。

　しかし，現実的に命令の入れ替えが可能になることは少なく，その場合は何もしない命令（NOP）を入れて，パイプラインを止めないようにします。これで，インタロックを実装しなくても待ち時間（ロード遅延）を確保出来ます。

　ですが，結局なにもしない命令を入れることは，パイプラインを止めることと同じ事です。なら，インタロックを入れてパイプラインを止めてしまっても結果は同じですし，何もしない命令が入ってこない分プログラムが小さくなるということもあり，こちらの仕組みを使うCPUも多くあります。

　もう1つ，分岐命令ですね。分岐命令は，実行結果によって処理する命令が違ってきますから，分岐の結果が確定するまで次の命令を取り込むことが出来ません。

　当たり前のこととはいえもったいないですから，分岐命令に続く命令が置かれる場所を遅延スロットという特別な場所とし，ここに置かれた命令を，実際の分岐を遅らせて先に実行してしまいます。分岐を遅らせることから，これを遅延分岐といいます。

　こうすると分岐命令があっても命令の実行が行われるようになります。そして，もしこの遅延スロットに入れる命令が，分岐の結果に依存しないような命令だったりしたら，1つ余計に命令が実行出来た事になりますね。

　これを目指してコンパイラは，遅延スロットに置くことの出来る命令を探し出して，入れ替えるように動いてくれます。それでも入れ替えることの出来る命令がなかった場合には，なにもしない命令（NOP）を入れる事になります。

　この仕組みは，CPUの回路規模がほとんど大きくならずに済み，分岐が行われる場合でも余計に1命令実行することが可能になるというメリットがあります。

　なお，遅延スロットは1つとは限りません。2つの場合も3つの場合もありますが，それぞれ実際の分岐が行われるより先に2つもしくは3つの命令が先に実行されるように作ってあります。だから，遅延スロットの数が変わるとプログラムの互換性が損なわれますので，その数は互換性を維持する限りは変更が許されません。

　もう1つ，最近は，ふんだんに使えるようになったトランジスタを利用し，こっと積極的に分岐先を予測する分岐予測と，予測された命令を実行する投機実行が使われるようになりました。予測の精度上げれば遅延分岐よりも効率が良く，遅延分岐のようなわかりにくさもないため，新しいプロセッサでは遅延分岐よりも分岐予測と投機実行が好まれる傾向にあるようです。

　マイクロソフトが，ARMのライセンスを受けることになったそうです。

　ここ最近のマイクロソフトの動きにはちょっと不可解なものがあり，かつての輝きを失った迷走っぷりに残念な気持ちになっている方も多かろうと思います。

　創業者が特に優れていた場合の世代交代が難しいという話は，世の東西を問わず，また規模の大小を問わないものだと，つくづく思います。

　今から20年ほど前の，WindowsNTの開発の顛末を語った「闘うプログラマ」という本には，DECから移ってきたデイブ・カトラーが，自由奔放なマイクロソフトのキャンパスの雰囲気に嫌悪感を示すシーンがあります。

　今のマイクロソフトに，そうした大人が煙たがるような「遊び心」があるのか，ないのか。

　部外者の私にはさっぱり分かりませんが，なにやら巨大企業が遭遇する「お疲れ感」をそれとなく感じているのは，私だけではないのでは，と思います。

　そんなおり，ARMのライセンスの話です。

　ARMのライセンスと聞いてもぴんと来ない方も多いと思うので，ごく簡単に説明をします。

　ARMというのは言うまでもなく，CPUメーカーのARMのことです。イギリスのケンブリッジに本社がある半導体メーカーの1つですが，彼らの売り物は自前の半導体製品ではなく，CPUの設計情報です。

　例えばインテルにしてもルネサスにしても，CPUの設計はあくまでCPUを作ってそれを売るために作るものであり，それ自身は売り物にしません。しかし，ARMは半導体の実物はそれぞれの半導体メーカーが作るものとし，自分達はその設計情報だけを販売することにして，もうけています。

　設計情報が売り物になるのか？と疑問に思う方もあると思いますが，CPUをゼロから作るというのはとてもとても大変です。CPUを作るだけでも死ぬ思いをするのに，コンパイラやデバッガ，ICEなどの開発環境に加え，周辺機能も一式用意しないといけません。これがとても大変です。それだけしても，そのCPUが売れるかどうかはわかりません。

　ARMというCPUは処理能力はそれほどでもなかったのですが，当時からビックリするほど低消費電力であり，携帯電話に採用されてから爆発的に普及するようになりました。開発環境もARM純正だけではなく，他の専門の会社がARM向けに作るようになり，周辺機能についてもARMに繋がるものがどんどん揃い始めます。

　ARMのライセンスを購入し，ARMのCPUの設計情報を手に入れることは，これら開発環境や周辺機能をすべて使えるようになることを意味します。（もちろん結構なお金がかかるのですが）

　こうしてARMが普及すれば，ARMのCPUならすぐに製造できますよ，と言う工場が当たり前になってきます。半導体というのは，実は製造会社によってちょっとずつ違いがあって，設計情報に互換性がありません。それも最近は強い製造会社のルールに統一されてきましたが，ARMの設計情報と互換性を持たない工場は仕事を受けられませんから，自ずと対応するようになります。

　結果，上流から下流まで，ARMを選べば全部問題なく揃うという状況が作られます。

　ARMは技術的には低消費電力を売りにしたものですが，技術的なメリットよりむしろ，エコシステムについての魅力が圧倒的で，同業他社の追随を許しません。

　このARMを使うために必要なものがライセンスですが，実はこれも2種類があります。1つはインプリメンテーションライセンス，もう1つはアーキテクチャライセンスです。

　実はこれらのライセンスの中身は機密扱いになっていて，実際に契約を結んだ人でないと詳しい内容はわかりません。私ももちろんわかりませんが，そこはそれ，憶測も入れて書きますので，話半分で読んで下さい。

　インプリメンテーションライセンスというのは，ARMのCPUコアを「買う」ライセンスです。買い方には2つあって，1つは中身をブラックボックスとして買う方法，もう1つはソースコードで買う方法です。前者をハードマクロ，後者をソフトマクロと呼んだりします。

　ハードマクロはブラックボックスで買いますからそのまま工場で作るだけになってしまいますが，ソフトマクロで買った場合は，ちょっとしたカスタマイズ，例えばキャッシュメモリのサイズを変更するとか，その工場の半導体に最適化するとか，そういうことが可能になります。

　ただし，基本的にソースコードはいじれません。もしそんなことを許したら，ARMと微妙に互換性を失った「なんちゃってARM」があちこちにいっぱい出来てしまい，大混乱になってしまいます。

　ということで，あくまで作るのはARMで，それをそのまま利用するのがインプリメンテーションライセンスです。ARMを利用するメリットは，このインプリメンテーションライセンスでほぼ手に入ります。

　もう1つのライセンスであるアーキテクチャライセンスというのは，CPUのソースコードをいじることが許されるライセンスです。もっというと，ARMの互換プロセッサを「作る」ライセンスです。

　ARMのプログラムが走り，ARMが持つ機能が実装されていて，外側から見るとARMそのものでも，中身は完全に別物であるということが許されるライセンスなわけですが，なにぶん機密扱いですので，アーキテクチャライセンスでどこまで出来るのか，あるいはアーキテクチャライセンスが何種類あるのか，私にはわかりませんし，本当に互換プロセッサを作ってよいのかどうか，確かめたわけではありません。

　でも，本家ARMが作ったCPUに互換CPUを作っても，おおむね勝てるわけがありません。互換CPUを作ってもメリットがあるという「実力のある」会社だけが，どうしても既存のARMコアでは実現出来ない「なにか」を仕込むときに，このライセンスを手に入れる事になります。

　例えば，ARMはどんな工場でも作る事が出来るようにゆとりのある設計になっていますが，これを自社の工場に最適化して，カリカリにチューンするということも，このライセンスで可能になります。

　噂ではものすごく高価だとか，お金を出してもなかなか手に入らないとか，A社だけではなく実はB社もこのライセンスを持っているとか，優れた設計は無条件にARMにフィードバックしないといけないとか，まあそんな邪推を私も耳にしたことがありますが，本当に所は何度も言うように，私にはわかりません。

　はっきりしていることが1つあって，このアーキテクチャライセンスを受けた最初の1社が，旧DECです。DECは，ARMの低消費電力に適したアーキテクチャに目を付け，さらに低消費電力でさらに高速クロックで動作する新しいARM互換コア，StrongARMを開発しました。ARM7では3段パイプラインだったものを5段に増やしてクロックを向上させ，DEC自身が持つ製造プロセスに最適化した設計を行っています。

　そしてこの開発成果がDECからARMにフィードバックされて誕生したのが，ARM9です。ARM9も5段パイプラインですが，内部はより余裕のある設計がなされていて，どんな工場で作っても大丈夫なような汎用性のある設計がなされています。

　DECのARM部門はこの貴重なライセンスごとインテルに買収されてしまいます。一説になかなか手に入らないアーキテクチャライセンスを手に入れるのがDECを買った理由だとも言われていたのですが，StrongARMの後継として生まれたXscaleは，インテルの製造プロセスに最適化されてさらに高クロックで動作するARM互換プロセッサとなりました。

　この成果がフィードバックされたのが，ARM11と言われています。

　そのXscaleも，現在はインテルからMarvellに売却されており，Marvellがそのままアーキテクチャライセンスを保有しています。

　とまあ，このように，インプリメンテーションライセンスではどうしても越えられない壁があって，それをどうしても取り払いたい会社が，それ相応の技術力を認められた上で，ようやく手にすることのできる「なんでもできる」ライセンスが，アーキテクチャライセンスです。

　ライセンスにも多額の費用がかかりますし，これを使ってCPUを1から開発するわけですから，その開発費用も膨大です。それでも十分儲ける事が出来るという目算がなければ，およそこんな恐ろしいライセンスを取得しても，得なことはありません。

　さてさて，今回の主役であるマイクロソフトが手に入れたライセンスは，なんとこのアーキテクチャライセンスだというのです。

　？？？

　CPUを売って儲ける会社になるつもり？インプリメンテーションライセンスではダメだったの？わざわざアーキテクチャライセンスを手に入れて何をするつもり？

　いろいろ業界で憶測は飛び交っているとは思いますが，ここから先は全くの私の私見に基づく想像です。

　まず，マイクロソフトはCPU市場に参入するのか？答えはノーです。単に参入するだけならインプリメンテーションライセンスだけでもいいはずです。

　それに，マイクロソフトはソフト，特にOSの会社です。今さら設備産業である半導体に乗り込む理由は見当たりません。ファブレスの設計会社という選択肢もあるかも知れませんが，それこそそんな会社は世界中にいくらでもあり，悪いことにどの会社もそんなに儲かっていません。

　ではアーキテクチャライセンスでなにをするのか？これは，おそらくですが，OSを作る過程で感じていた，ARMアーキテクチャに対する不平不満を根本的に改善しようとしているのではないでしょうか。

　ご存じの通り，マイクロソフトはWindowsCEの時代から，ARMをサポートしていました。ARMと言うCPUに取って，WindowsCEというOSが動くことは何より心強いものがあったはずです。

　当時はMIPSやSH3などでも動いたWindowsCEですが，WindowsMobileとなった現在ではARMでしか動作しないOSになっています。マイクロソフトは売り物であるOSを，別にアーキテクチャライセンスを取得しなくても，十分に作ってこれたはずでした。

　しかし，実はARMというCPUは，私の言葉で「トルクのない」CPUです。粘りがないというか，底力がないというか，高クロックでぱぱーっと回るんですが，負荷がかかると途端にパワーが落ちるという印象があるのです。このあたり，x86や良くできたMIPSが，まるでディーゼルエンジンのトラックやバスでも運転しているかのような頼もしい感じがしたことを思い出します。

　ARMコアが原因と言うより，バス設計に問題があったからこういう印象があったのかもなと思い当たるところもあるのですが，では実際，1GHzのARMで動いているiPadと，似たようなクロックでもx86で動いているネットブックを比べてみると，どちらの方がサクサク動くかと少し考えて頂ければ，なんとなく想像出来るのではないでしょうか。

　WindowsCEは昔からもっさり動いているOSです。これがもしARMのアーキテクチャによるものだとマイクロソフトが結論していたら，アーキテクチャライセンスを手に入れて改善しようと考えても不思議ではありません。

　他にもあります。低消費電力を実現するには，主体的にCPUの消費電力を下げる必要がありますが，突き詰めるとそれだけでは限界があり，ソフトウェア，特にOSが頑張らないと下がりません。

　x86はインテルがだけが作っている（AMDも作っていますが，一応オリジナルはインテルです）ので，マイクロソフトとしてはWindowsをチューニングする過程で，インテルにどうしてもらえるとうれしいか，伝える機会を持っているはずです。

　インテルも，x86がWindowsを前提としてCPUであることを知っているので，マイクロソフトからの意見には真摯に耳を傾けていることでしょう。

　しかし，ARMは半導体会社には違いありませんが，実際に半導体を作っているわけではありません。マイクロソフトがARMにいろいろ意見を言っても，それがそのまま聞き入れられるとはちょっと考えにくいものがあります。

　WindowsCEとタブレットや携帯電話に向けて本格的に投入するにあたり，もうOSだけではどうにもならないところまで来てしまった・・・だからいよいよCPUそのものに手を入れて，より自分達に最適化されたCPUを作ろうとしている，というのが，私の考えです。

　この話が本当だとして，マイクロソフトの強力なライバルで，むしろ押され気味なAppleとGoogleには，およそ出来そうにないことをやって頭一つ抜け出ようとしたように思えてなりません。

　AppleのiPadやiPhone4には，彼ら独自開発といわれるA4というプロセッサが使われています。しかし実際にこれを設計しているのはSamsungで，AppleもSamsungもアーキテクチャライセンスを持っていませんから，既製品のARMコアをそのまま使っているはずです。

　1GHzという高クロックのわりには，そんなに高速で動作しているわけではないiPadは，消費電力の低さによる電池寿命の長さで評価は高いですが，でもそれだけです。処理能力で3年前のMacBookにさえ及びません。

　GoogleはAndroidをフリーでばらまいていますが，誰にでも使ってもらえるものであるためには，誰にでも手に入るCPUをターゲットにせねばなりません。Androidが実質ARM専用OSになっているのは，この戦略が故です。

　AppleもGoogleも，プロセッサそのものを作って，それ用のOSを作る事の出来ない事情があります。マイクロソフトもかつてはそうでしたが，彼らは果敢にもアーキテクチャライセンスを手に入れ，自分達のOSが最も効率よく動くCPUを作ろうとしています。

　マイクロソフトの主力製品はあくまでOSです。ですから，アーキテクチャライセンスにかかった多額の費用を，CPUを売ることによって回収しようとは考えていないと思います。マイクロソフトが狙っているのは，その主力製品であるOSが最も効率よく動くCPUを自ら用意して，これをリファレンスデザインとして提供し，他のライバルには到底実現出来ないような完成度の高い製品を，誰にでも簡単に作る事が出来るようにすることです。

　ここから先はいろいろなオプションがあるでしょうが，1つにはOSを売るためのオマケとして，CPUの設計情報とそのCPUを使ったリファレンスデザインの回路図を無償で提供し，これを使ってCPUと回路を作る事を最終製品のメーカーに許可するというシナリオです。

　あるいは，このCPUの設計情報を一部の半導体メーカーにライセンスし，そのCPUで高性能を発揮するOSをマイクロソフトが最終製品メーカーに対して供給する，とぃう話です。いわばスマートフォンのウィンテルを目指そうという作戦です。

　インテルはARMのアーキテクチャライセンスを手放しましたし，いくらATOMが低消費電力だといってもARMには全然かないませんから，実用的な電池寿命のスマートフォンをインテルのCPUで作ることは無理です。さりとて現状のARMでは処理能力に物足りないものがあり，しかもARMコアのCPUはARMからインプリメンテーションライセンスを受ければ製造できるので，多くの半導体メーカーが手がけています。

　マイクロソフトはこのあたりをよく分かった上で，PCにおけるインテルのような，スマートフォンにおけるパートナーを，自ら育てようとしているのかも知れません。

　いずれにせよ，スマートフォンを作るのに，これまでは既存のハードウェアにOSをあわせ込んで作っていたものを，それでは限界があるのでOSとハードウェアの両面から作る事にした，ということは間違いないでしょう。これはAppleにもGoogleにも現時点では真似の出来ないことです。

　言い方を変えると，マイクロソフトはソフトだけではもう改善できないと白旗を揚げたとも言えます。AppleもGoogleもまだまだソフトでがんばれると思っているのかも知れません。

　多額の費用を投じて，OSだけにとどまらずCPUにまで手を突っ込み，最終製品の性能向上を目論むマイクロソフトという会社は，いったいどれだけの巨大企業なのかと，背筋が寒くなる思いがします。

　Appleは，かつてPAsemiというCPUメーカーを買収しました。直接間接にこの会社の持っていた資産がA4というプロセッサの実現に役に立ったことは想像に難くありませんが，このPAsemiという会社は，もともとDECでStrongARMを開発した人々が作った会社だということを，最後に添えておきます。

　Appleは，PAsemiの直接の成果物や人的資産でA4を作ったのではなく，設計と製造を依頼したSamsungのいいなりにならず，自分達の欲しいCPUを作ってもらうためにちゃんと意思疎通ができるよう，その道の専門家（それもこの業界なら知らない人はいないと思われるCPU設計のカリスマです）を手に入れたかったというのが，現在の大方の見解です。

　AppleもGoogleもマイクロソフトも，しっかりしたビジョンと良いOSを持っている業界のリーダーですが，それぞれが専門外の半導体に対して，これだけスタンスが違ってくるというのが，大変に興味深いですね。

　ここ数日，少しずつKindleDXの環境構築を進めています。

　なんとか持ち歩きに便利になるよう，KindleDXで出来ることと出来ない事をはっきりさせ，快適に使えそうな機能の洗い出しと，すっぱりあきらめるべきところを切り分けたいと考えて試行錯誤を続けています。

　現在解決の目処が立っていないのが，PDFのメタデータの取り扱いです。

　事の起こりは，青空文庫をPDFにオンラインで変換してくれるというありがたいサービス「青空キンドル」を使って作成したPDFを入れた時に，それまで出てこなかった著者名がローマ字で出ていたことを見つけたことに始まります。

　そういえば，プリインストールされていたKindleDXの説明書にも，著者名としてAmazon.comと出ていたことを思い出しましたが，なぜか自炊したPDFファイルには著者名が出てきません。

　きっと空欄になっているのだろうと，PDFのメタデータを確認すると，予想通り空欄になっています。そこでここに日本語で著者名とタイトルを書き込み，ワクワクしながらKindleに入れたのですが，結果は変わらず表示されません。

　なぜだ，この疑問が消えるまで試行錯誤がしばらく続くことになります。

(1)青空キンドルで作成したPDFではなぜ著者名が出ているのか

　青空キンドルで作成したPDFでは，半角アルファベットで著者名が出ています。一方タイトルは日本語ですが，これはファイルネームがそのまま，拡張子無し表示されているだけです。

　このファイルをBeCyPDFMetaEditで開いてみると，Authorに半角アルファベットで著者名が書かれています。ならばこれを日本語に書き換えて試してみると，著者名は出てこなくなってしまいました。

(2)再起動

　Kindleはフォントの入れ替えを行った際にも再起動しなければ変更が反映されません。本も同じ話らしく，キャッシュをクリアしないといけないとのことで，メタデータを埋め込んだ同名のファイルを上書きした場合，再起動がないと著者名が表示されないようです。

　結果，日本語でメタデータを書いたものは再起動後も著者名が出てきませんが，半角のアルファベットで書いたものは再起動後には著者名が出てきました。やはり再起動は必要なようです。

(3)メタデータが正しく埋め込まれているのか

　ある海外のblogによると，正しいメタデータが埋め込まれないとダメだとあります。当たり前の話ですが，ではその正しいメタデータの埋め込みとは，どうやって行えば良いのでしょうか。

　PDFのメタデータはAdobe Acrobatで書き込むのが確実なのでしょうが，そこそこ高価なアプリですのでどこにでもあるようなものではありません。私の場合，AcrobatとBeCyPDFMetaEditというフリーソフトと，定番のpdftkの3つを使ってみました。

　結果だけ書くと，どれも同じになりました。当たり前の話ですが，足下をすくわれたのは，Acrobatをインストールしたマシンでは，エクスプローラ上でプロパティを選ぶとPDFタグが現れ，ここでメタデータを編集できるのですが，実際には編集が反映されていないケースがあったようです。

　でも，そんなことが本当にあるのか，作業がややこしくなって変更前のファイルが混じってしまったんじゃないかなど，不確かなことも多いので，話半分と思っていてください。

(4)メタデータの文字エンコード

　ふと，メタデータの文字エンコードって実はなにを使ってんだろ？と疑問がわきました。KindleはUnicodeですので，もしメタデータの日本語がSJISなどで書かれていたら正しい表示は期待できません。

　そこで，pdftkを使ってメタデータを打ち込んでみます。pdftkでは，メタデータを別途テキストファイルに書いておく必要があるのですが，このテキストファイルをSJISとUTF-8の両方で作成し，それぞれで試してみました。

　出来上がったPDFをBeCyPDFMetaEditで見ると，UTF-8では正しく表示されているのに，SJISでは文字化けしています。予想通り，メタデータはUnicodeで書くべきもののようです。

　さっそくこのUTF-8でメタデータを書いたPDFをkindleに入れてみましたが，結果は残念なことに，なにも表示されませんでした。

(5)PDFのバージョン

　これも同じ海外のblogにあったのですが，Kindleでメタデータを反映させるには，PDFのバージョンが1.4以上でなければならないらしいのです。1.4というのはAcrobat5以降で対応可能なフォーマットなのですが，実はMacOSXのQuartzは1.3でPDFを生成します。ということは私が自炊したPDFは，メタデータが反映されないということになります。事実だとしたら結構深刻です。

　でこれは結論から言うとウソでした。

　1.3と1.4のそれぞれに，BeCyPDFMetaEditを使って日本語と半角アルファベットを著者名に埋め込んだファイルを用意しました。すると，1.3だろうが1.4だろうが，半角のアルファベットを埋め込んだ方は表示されたし，日本語を埋め込んだ方はどちらも表示されませんでした。

　
(6)タイトルはどうなの

　Authorについては，どうやら半角なら出てくるらしいとわかりました。ではTitleはどうかというと，これが不思議なもので，半角だろうと全角だろうと，メタデータからは表示されず，あくまでファイルネームの拡張子無しがそのまま出てきます。日本語のタイトルを付ければ，それがそのままタイトルとして列びます。

(7)フォントのせいではないのか

　日本語を含まないフォントを使っているから非表示なっているという可能性については，否定こそ出来ませんが，Kindleで使用するSans，Serif，Monospaceの3書体のうち，日本語を含まないフォントのままにしてあるのはMonospaceだけです。

　表示されている著者名のアルファベットを見ていると，およそMonospaceとは思えませんので，Monospaceを日本語を含むものにしたところで，解決しないと思います。

　とまあ，こんな具合です。

　すでにおわかりのように問題はとてもシンプルで，結局メタデータはAuthorだけが有効で，それも半角で書かれた場合のみ表示されるようです。タイトルはメタデータに関係なく，ファイル名から拡張子を除いたものがそのまま日本語だろうが何だろうが表示されます。

　しかし，google先生に聞いてみますと，「メタデータを日本語にすれば著者名も日本語で出るはず」という意見が見られる上，日本語は著者名では出ない，という記述が見当たりません。私だけの問題なのか，そういうものとあきらめるべき所なのか・・・

　さらにgoogle先生に聞いてみると，某巨大掲示板の過去ログに，同じ疑問で悩んでいる人がいて，どうも半角アルファベット以外は無効なデータとしてスキップするようになっているんじゃないだろうか，ということが書かれていました。

　うむー，ファイルネームに日本語が混じっていた場合，無効なデータとしてタイトルを空欄にすると，そのファイルへのアクセスが出来なくなってしまいますので，特にそういうフィルタを入れていないというのはなるほど分かる話で，メタデータのみに限定してフィルタを入れたというこの憶測は，あながち否定できません。

　まあどっちにしても，仕様であるかないかに関わらず，私と同じく著者名が日本語で出ないという人がいて，同時に日本語で出たという人が見当たらない現状では，最終的にPDFのメタデータを使って著者名を日本語で出す方法はない，という結論に落ち着きそうです。

　実は，Kindleは著者名でソートをかけられるので，著者名が出てきてくれるととてもありがたいのです。そこで，著者名は半角アルファベットで記述するという運用を行うことにしました。

　過去の自炊データも含めてすべてのPDFにメタデータを書くのはさすがに骨が折れるので，Kindleに入れることになったものに限定することとします。

　とにかく，BeCyPDFMEtaEditを使えばKindleに有効なメタデータを書き込むことが出来て，同じ名前のファイル名のものを上書きしても再起動すれば茶社名が反映されることが分かっていますので，あとは単純な作業をコツコツやるだけです。

　でも，やっぱり日本語にこだわる書籍だからこそ，著者名も日本人として，日本語で書かれたものを見たいものです。これを実現するにはフォントハックを改良し，著者名をメタデータから取ってくるときに，余計なフィルタを外すだけで済みそうな気もするのですが，私にそこまでの根性もあるわけはなく，さくっとあきらめることにします。

　最後の手段は，PDFをmobipocket形式に変換することです。MobiPocketCreatorというソフトが無償で公開されていて，これを使えば一応作る事ができるということなのですが，どういうわけだか私は一度もPDFからまともに変換できずにいます。手間もかかるし綺麗に変換できないので，メタデータのためにわざわざこの手順を開拓するのは，やめにします。

　さあ，あとは持ち運びのためのケースを考えれば，持ち歩きが可能になります。いろいろ考えていますが，いいものが出来たらここで紹介したいと思います。

　さて，私の手元に届いたKindleDXですが，久々にワクワクしています。絶対に必要という訳ではないが，あれば確実に生活を変えてくれるであろうという期待がある時には，特有の高揚感を楽しむことが出来るものです。

　はるばるアメリカからやってきた段ボール箱を開くと，充電をしなさいと言う画面を表示した本体が目に飛び込んできます。

　私は紙を挟んであると一瞬考えてしまったのですが，冷静に考えるとこれは紙を挟んであるわけでも，シールを貼ってあるわけでもありません。本体のディスプレイにそのまま表示されているものです。

　保護用のフィルムを剥がすと，さらに感動します。いやー，eInkも良くなっているんだなあ。

　本体を取り出します。底にはケーブルとアダプタ，そして簡単なスタートアップガイドが入っていますが，iPodほどでなないにせよ，十分に開梱の儀式を楽しめました。統一された世界観で作られていることが，なにより楽しいです。

　まずは充電をしないといけません。充電が終わったら，いろいろいじってみますが，思った以上にディスプレイの書き換えも速く，私はストレスをほとんど感じませんでした。

　書籍は何も買っていないので，とりあえずインストール済みの取扱説明書を読んでみますが，その段階で表示の美しさと，大画面の見やすさに素直に感動しました。紙の本ように分厚くなく，それで紙に近い取り扱いが出来ていることは，全く新しい体験と言えます。

　UIは前近代的な感じがする古くさいものではありますが，これがリッチなものであってもきっとディスプレイが原因で破綻したでしょうし，タッチパネルがあるとよいとは思いましたが，単機能なKindleの操作方法がややこしいわけでもありませんから，タッチパネルを付けることで重くなったり見にくくなるくらいなら，私はいりません。

　操作はとてもシンプルです。文字の拡大などはQWERTYキーで行うので知らないと操作できないのですが，知ってしまえばなんと言うことはありません。基本的にページ送りをするだけの話です。

　そして非常にシンプルなのは，書籍の格納方法です。USBで繋ぐとマスストレージでマウントします。第1階層にあるdocumentというフォルダにファイルを突っ込んでアンマウントすれば，すぐに認識されて画面から選択できるようになります。

　あとは普通のPDFのようにパラパラめくって読むだけです。

　ただし，よく言われていることですが，自炊PDFのように画像でスキャンしたPDFファイルなら日本語だろうとなんだろうと表示は可能ですが，日本語テキストが入ったPDFは開くことが出来ません。

　これは，フォントがKindleにないことも理由になっています。だからPDFにフォントの埋め込みを行うと表示されるようになるのですが，Macの場合この作業はとても楽で，プレビューで表示した後，別名で保存するとフォントが埋め込まれます。

　しかし，開くことが出来るようになっても，線画や解像度の高い画像の扱いが苦手なKindleは，フォントが埋め込まれてもそれらの画像の処理に膨大な時間がかかり，ものにも寄りますが実用的な速度で読むことが出来ない場合もありました。

　例えば先日購入したテレビの説明書です。そのままでは開くことが出来ず，フォント埋め込みで開くことが出来ましたが，図が多いページにさしかかるとフリーズしたかと思うくらい黙り込んでしまいます。電子レンジの説明書はもっと深刻で5分ほどなんの操作も受け付けませんでした。しばらく放っておくと動くようになっていたので，やっぱりPDFというのは重いフォーマットなんだなあと思いました。

　ということで，自炊PDFについては，何の工夫もしないで，十分に読書端末として機能してくれそうです。

　しかし，やっぱり書籍一覧で口の字がずらーっとならんで日本語が一切出ないというのは，やっぱり寂しいものです。せめてそこだけでも改善できないものでしょうか。

　世の中には，いろいろ面白いことを考える人たちがいます。実はHackすることで機能拡張を行うのが，すでにKindleでは当たり前のことになっているのです。

　スクリーンセーバを入れ替えるもの，フォントを入れ替えるものなど，いろいろあるようですが，定番はやはり日本語表示が可能になるようなHackです。

　しかし，私のKindleDXは7月7日に出たばかりの最新版。これにHackが揃っているとは思えません。複雑な手順を一発で済ませるHackも日本の有志の方が用意してくださっていて，これを使うと失敗することなく一発で日本語が扱えるようになるのですが，そんな便利なものがあるわけありません。

　ところが，海外には，すでに新しいKindleDXで動作可能なHackが用意されているのですね。早速JailBreakとFontHack，そしてScreenSaverHackを入手し，ドキドキしながら自分のKindleに入れます。

　フォントはUnicodeでエンコードされたTrueTypeでないといけない（ここで失敗すると再起不能になるらしい）とのことですが，私は手持ちがなかったのでxxxをyyyしてzzzすることで，ささっと作ってしまいました。必要な書体はサンセリフとセリフのレギュラー，ボールド，イタリックのレギュラーとイタリックのボールドの，合計8つです。FontForgeを使って作りました。

　そしてドキドキしながらインストール。再起動してやると，うまい具合に日本語のタイトルが出るようになりました。WEBを見てみましたが，Wikipediaの日本語サイトなども問題なく表示されるようになっています。

　残念ながらスラッシュドットをみたら再起動がかかってしまいました。

　まあ，WEBを見るのが目的ではありませんので，これで十分です。そもそも日本語入力も出来ないわけですからgoogleも使い物にならず，KindleであちこちWEBを見て回ろうとは思いません。確かに無料で使える3Gの通信回線は魅力的なのですが・・

　スクリーンセーバは，デフォルトのものがちょっと日本人には気持ち悪い図柄が多いので，是非入れ替えたいところです。何を入れようかなあと考えたのですが，本屋さんで付けてもらえる，あのブックカバーをスキャンして表示させようと閃きました。

　いくつか集めてみると，本屋さんごとに，あるいは時期によって，なかなかバラエティに富んでいて，面白いものです。電子書籍端末でもこうして本屋さんの個性を持ち歩けると，また別の楽しみが生まれます。

　ということで，ここまでは昨日までに終わった話。ここから先のお話として，デフォルトの辞書を英和辞典にすることがあります。もちろんコンテンツの充実も必要です。青空文庫をPDFにして読むとよいそうですので，早速作成してインストールしました。

　コレクションという，フォルダに似たような概念の仕組みがあるのですが，コレクション名は当然ながらアルファベットしか入力できないので，日本語のものを作成できません。しかし，USBで接続し，systemフォルダにあるファイルをエディタで開き，該当する名前に日本語を使い，en-USをja-JPに変更すると，ちゃんとコレクション名も日本語になってくれました。

　それとなにより，持ち歩きのために，カバーなり袋を用意しなければなりません。純正も含めてカバーを考えていましたが，せっかくの薄い本体が何ミリか分厚くなってしまうことは惜しいので，本のケースのような長辺側に口のある袋を用意し，これに入れて持ち歩けたらなと思っています。まあ，こんなものは既製品があるとは思えませんので，自分で何とか作らねばならんでしょう。

　このWelcomeは，私にとっては，単なる顧客としての歓迎ではなく，一度は否定された電子書籍との関係を，違う立場から取り戻したという記念すべきWelcomeなのです。

　2010年は，私にとっての電子書籍元年となりました。

　久々にワクワクするガジェットを買いました。Amazon Kindle DXです。

　ご存じのように，KindleはアメリカのAmazon.comが販売する電子書籍端末です。薄く，軽く，持ち運びに便利で，高反射率，高コントラストの電子ペーパー「eInkディスプレイ」を搭載し，本を読むという行為に最適化された，単機能端末です。

　我々日本人はこうしたハードウェアそのものに目が行きがちですが，Kindleの本質は，携帯電話を内蔵し，24時間いつでもどこでも繋がっていることと，そして繋がっていることに費用が一切かからないことです。もちろん，この通信機能を使って本を購入すれば，それにはお金を支払わねばなりませんが，費用の発生は購入したときだけ，とにかく繋がっているだけでお金がかかるという心理的負担が一切ないのです。

　考えてみてください。送料がかかる，電車賃がかかる，という話になったとき，その本を気軽に買おうという気がするでしょうか。

　もちろん，本当に欲しい本なら送料がかかろうと電車賃がかかろうと，プレミアが付いていようと買うとは思います。しかし，雑誌やどこにでもある本を，そうして買おうとするでしょうか。

　逆の視点で考えてみると，入手の難しい部数の少ない書籍であっても，予約もせず，大きな本屋に行くこともなく，もちろん送料もかからず，24時間どこでも買えてすぐに手元にやってきたなら，その本をもっと気軽に，それこそ雑誌気分で読んでみようと思うのではないでしょうか。

　私の思う，Kindleの本質はここにあります。我々は本を読みたいのであって，本を買いたいわけではありません。もっとも，本屋さんはブラブラするだけで楽しい場所ですが，通販サイトであるamazonにはその楽しさはありません。だから，目的である「読書」に極力早く簡単に達することができれば，それが一番だといえるわけです。

　かつて，内外の電機メーカー数社から，似たような書籍端末が出ていました。しかし，本体だけで本を買うことは当然出来ず，PCとの接続が前提でした。ひどいものになるとレンタルだけで購入することすら出来ないという，本好きを愚弄するような事を平気でやってのけて，当然ながら見事に大失敗をこいた例すらありました。

　電子ペーパーと言われる新しいデバイスは，LCDのように1/60秒でリフレッシュされるようなディスプレイではありません。LCDがブラウン管の後継なら，電子ペーパーはプリンタと紙の後継です。

　しかし，書き換え可能な紙をプリンタで何度も何度もその場で印刷するような経験を我々はしたことがありません。加えて，低速デバイスの代表であるプリンタを，組み込みシステム上どうやって扱うのがふさわしいのか，そこが思案のしどころです。

　当時はパネルだけが存在する状態で，これを制御するLSIもなければ，動かすソフトも，動かし方の大枠を決める概念すらありません。

　決まったパターンを専用の装置を使って表示することは出来ても，組み込み用のマイコンで任意の画像を描く方法が存在せず，それをどうやって作り上げればいいかさえ誰も答えを持っていませんでした。

　いかにすぐれたデバイスでも，他と組み合わせて完成品にしなければ，広くお客様に使って頂くことはできません。そして完成品があまりに複雑であると，今度はお客様に提供する側の負担が大きく，結果として良い製品を作ることが出来なくなります。

　何もお手本がないところで物事をスタートさせるときには，こうして買って頂く方と，作る人たちの顔を思い描きながら，どちらもハッピーになるように，考えて作る事が求められると，私は思っています。

　見た目はLCDのようなディスプレイパネル，でもその本質は紙，もし理解を誤ってしまうと，この新しいディスプレイはお客様を失望させ，受け入れられる事無しに，姿を消すことになるでしょう。

　私の父は出版社の営業にいました。母は本屋さんで店員をしています。本は大好きで，本屋も大好きです。そして私は技術者になり，自分の力を大好きな本と本屋さんのために使うことが出来るはずと，そう考えていました。

　しかし，よくある「失敗」として処理され，私は本からも本屋からも必要のない人間だと宣言されるに至ります。

　Kindleの画面を見ると，なぜか暗雲の垂れ込めたような，今にも雨の降り出しそうな，複雑な気持ちになってしまいます。これはもう避けようのないことですね。

　閑話休題。

　そのKindleは，本を読む，本を買うということに特化した単機能端末であることは既に書きました。この点で何でも出来るマシン，例えばiPadなどとは全く性格を異にします。

　動画も音楽もゲームも満足に扱えませんが，文字を読むにはこれ以上のものはないと思われるほど視認性に優れたeInkディスプレイを持っています。私が選んだDXは，実に824x1200ピクセルという高精細なもので，その解像度は150dpiです。かつて日本の標準プリンタだったNECのPC-PR201などは160dpi，エプソンのVPシリーズで180dpiでしたし，プリンタと違って16階調のグレイスケールですので，うまくデータを作れば300dpi程度の視認性は持っているでしょう。

　カラーではなく，自発光でもありません。まさにモノクロの印刷がなされた紙です。書き換えには時間がかかり，しかも表示完了から時間が経過すると少しずつコントラストが落ちてしまい，白がグレーに寄ってきます。

　ちょうど，紙の悪い週刊誌や新聞という感じでしょう。しかし，紙と同じとは言いませんが，明らかにコンピュータとは異なる，間違いなく本を読むという体験を味わうことが出来ます。

　ここに，全世界で無料で接続可能なワイヤレス接続機能が付いていて，世界中どこからでも本を買うことが出来ることも前述の通りです。

　Kindleには初代のKindleの系統である小型版のKindle2と，大型化したKindle DXの2つがあり，それぞれにアメリカ国内版と国際版の2種類があります。初期のKindleは専用フォーマットのみが扱えたのですが，最近はPDFやMobipocketも扱う事が出来るようになりました。

　残念なことに，国際版でも購入はアメリカのamazon.comからでないとダメなのですが，手続きは簡単ですし，受け取ることも問題はありません。大した時代になったものです。

　7月7日，そのKindleDXにグラファイトと呼ばれる最新のモデルが加わりました。改良されたのは電子ペーパーの性能向上です。

　お値段は送料と関税をいれて約400ドル。円高ですので，35000円ほどで買える計算です。

　ずっとこの手の書籍端末を買おう買おうと思っていましたが，なかなか日本語に対応してくれず，国内販売も行われません。富士通から出てはいますが，あれもWindowsCEだったりして，今ひとつな感じです。

　iPadはやっぱり電子書籍端末ではないと私は思いますし，国内でも始まるであろう電子書籍ビジネスを待つのも，ちょっとどうかなと思っていました。

　それに私は，いわゆる「自炊」を初めて，もう3年になります。300GBを越える大量のPDFが，蔵書として揃っています。古いトラ技から新書・文庫，果てはコミックのたぐいまで，本を捨てられない本好きの私は，本を切り刻んでスキャンし捨てるという苦渋の選択によって，ようやく新しい本を買うことが可能な状態にあります。

　入力と蓄積は出来ています。あとは出力です。

　ここで紙に近いディスプレイを持つ電子書籍端末を揃えれば，このワークフローは完成します。

　そして，7月7日の新しいKindleDXの登場は，紙に変わる新しい出力先を提供するものとして，私の目に映りました。

　白より黒い方が好きでしたし，電子ペーパーはコントラストが命と思っている私は，もうくよくよしていても仕方がないと，思い切って買うことにしたのです。

　本体の大きさはおおよそB5のノートくらいです。厚みもノートくらいです。重さは結構あるのですが，薄くできているためハードカバーの文芸書を持ち歩くよりはずっと楽でしょう。

　なにもいいことがなかったという複雑な気持ちも手伝って，なかなか踏ん切りの付かなかった私は，amazon.comでぽちった後，大変に晴れやかな気持ちになりました。

　それでも持ち続けていたかすかな期待との完全なる決別，過去を踏み越えて進むことの気持ちよさ，そしてくだらないバイアスに惑わされることなく，手元に届く新しいガジェットを純粋に待ち焦がれる気持ち，数日そうした気分を味わいながら，7月6日に発送，翌日には日本に向けて飛び立ち，7月8日に成田に到着，当日中に配達されるも不在で受け取り損ね，そして7月10日に再配達という手順で，それは私の手元にやってきたのです。

　・・・長くなったので，続きは明日。