7月23日、ARMはMicrosoftとアーキテクチャライセンスを締結したと発表した。これまでにもMicrosoftはWindows CEあるいは、これをベースにしたWindows Mobileといった組み込みOSにおいて、ARMアーキテクチャをサポートしてきた。なぜ、今になってARMとアーキテクチャライセンスを締結したのだろう。

　ご存じのようにARMは自社開発のRISCプロセッサに関するIPをライセンスする企業で、そのライセンスにはさまざまな形態がある。ライセンス期間の違いもその一例だが、アーキテクチャライセンスとインプリメンテーションライセンスの違いもあると言われている。

　一般に、ARMコアの各種SoC製品を製造するパートナーが取得しているのは後者、インプリメンテーションライセンスだ。このライセンスで、ARMが設計したプロセッサコアを用いてSoCを開発するのに必要なすべての情報が含まれるとされる。そのコアのライセンスも特定のファウンダリの製造プロセスに依存しない汎用のソフトライセンスと、特定のファウンダリの製造プロセスに最適化されたハードライセンスが存在し、ファウンダリ等が締結するのは後者だと言われる。

　インプリメンテーションライセンスを取得した設計会社は、定められた期間(1製品から永久までさまざま)ARMの技術を用いて製品を開発することができる。ライセンス期間は開発期間を対象としており、ライセンス期間が終了しても、開発が完了した製品の製造は永遠に継続できる(別途ロイヤリティは製品毎に生じる)。このインプリメンテーションライセンスを取得した場合、A社(ライセンシー)がARMのXXX(ARMが開発したプロセッサコアやそれをベースにしたチップの名前)をライセンス、という形でプレスリリースが出されることが多い。

　一方、アーキテクチャライセンスについては、供与の例は少ない(そこまでしなくても、製品開発できるからだろう)。歴史上最も有名なアーキテクチャライセンスは、1995年2月にARMが旧DECに供与したもので、これを用いてDECはStrong ARMの開発を行なった。1997年、DECが半導体部門をIntelに売却した際、Strong ARM製品もIntelに移管されたが、IntelはARMとライセンス契約することによりDECのアーキテクチャライセンスを継承、XScale製品開発の基盤とした。2006年5月、IntelはXScale事業をMarvellに売却したが、Marvell自身も2004年に2社目として(DEC～Intelを1社目と数えるのだろう)アーキテクチャライセンスを締結済みであった。

　さて、このアーキテクチャライセンスにより、インプリメンテーションライセンスでは不可能な何ができるようになるのか、具体的な情報は公開されていない。冒頭で記したMicrosoftとのライセンス締結を発表するARMのプレスリリースでも、詳細は機密とハッキリ書かれている。

　このアーキテクチャライセンスについてIntelは、1998年7月に開催されたXScaleに関する説明会において、これによりARMコアを再設計することが可能だという趣旨のことを述べた。命令セットレベルでの互換性等、いくつかの条件を満たせば、コア内部を含めた自由度の高いカスタマイズが可能だと考えられる。実際、ライセンシーであった当時のIntelや現在のMarvellは、ARMが提供するデザインより高クロックで動作するプロセッサを開発している。

　では、このライセンスを得てMicrosoftは何をしようというのか。冒頭でも述べたように、OSの実装はアーキテクチャライセンスがなくても可能だ。というより、ARMアーキテクチャをサポートしたOSは、ARM製品の販売を後押しするものであり、そこからライセンス料を要求するということは考えにくい。それ以上の何かをMicrosoftは考えているのだろう。

　Microsoftが何を考えているのか、同社が発表しない以上、すべては推測の域を出ない。しかし、XScaleのようなチップを独自に開発して、それをMicrosoftブランドで売り出したり、Microsoftブランドの端末に自社開発のチップを使おう、と考えているわけではないと思う(Kinの早急な打ち切りの裏には、この懸念を払拭する狙いもあったのかもしれない)。

　筆者は、Microsoftに自社で開発したARMベースのSoCデザインを、サードパーティにライセンスしたいという意向があるのではないか、と考えている。Microsoftが自社の製品としてチップを販売するのではなく、サードパーティにデザインだけライセンスし、サードパーティの製品として(場合によってはMicrosoft開発であることは伏せられて)販売される、という形だ。自社OSに最適なプロセッサを設計する自由度を得るには、アーキテクチャライセンスが不可欠だったのではないだろうか。

　Microsoftがチップの開発やライセンスを行なうと言うと、奇異に感じる人もいるだろうが、実は過去に実績がある。Windows NTのオリジナルはMIPSアーキテクチャで開発されたが、そのリファレンスデザインに使われていたチップセットやグラフィックスチップは、Microsoftが開発し、カリフォルニアのベンチャー企業がライセンスを得て販売していた(Microsoftの開発であることは伏せる形で)。タイリングベースのGPU(開発コード名Talisman)を設計したこともあったが、こちらはDirectX 4とともに、実用化されることなく消えている。

　iPadやiPhoneの成功をみて、Microsoftが自社のOSに最適化されたプロセッサの必要性、あるいはプロセッサに最適化された形でOSを提供する必要性を感じたとしても不思議はない。しかし、Microsoftが自社のチップのみに最適化された形でOSをリリースすることは、水平分業システムの否定につながりかねない。それは、既存のプラットフォームから、特定ベンダーのチップ1種類(たとえばQualcommのSnapdragon等)を選定するのに等しい。市場による淘汰の結果、1種類に集約されるのならしょうがないが、Microsoftが選んだ結果、1種類に集約されるのは(独禁法的にも)望ましくない。

　Googleが自社の端末を売ることが、Androidベースの携帯電話を販売するサードパーティにとって楽しかろうハズがないのと同様、Microsoftが自社でハードウェアを販売しては、他のハードウェアベンダーにおもしろいハズがない。少なくとも、ハードウェアベンダーにOSをライセンスする立場であるMicrosoftが、ハードウェアベンダーと市場で競合したり、ハードウェアで儲ける形は避けるべきだ。

　Microsoftが、OSとハードウェア(プロセッサ)の関係を今より密にしたいと考えているのはおそらく間違いない。バッテリ駆動されるポータブルデバイスで、性能とバッテリ駆動時間の両立を図るには、特定のハードウェアを前提にしたOSのインプリメントが必要になることもある。これは、IntelがAtom向けにMobilin(現在のMeeGoの前身)を開発する際にも述べていたことだ。

　Microsoftは、将来リリースする組み込み機器用のOS(それがWindows phone 7なのか、その次の世代なのかは別にして)で、特定のハードウェア実装への最適化を行なうのではないだろうか。その代わり、そのハードウェアを自社では製品としては提供せず、チップメーカーや端末メーカーへIPとしてライセンスする。そうすることで、水平分業モデルから踏み出すことは避けるというシナリオだ。

　こうなると面白くないのは、組み込み機器用プロセッサ、特にスマートフォン向けにAtomを推進しているIntelだろう。確かに、Intelが示すAtomプロセッサの対応OSに、Windows CEやWindows Mobile、Windows phoneといった、Microsoftの組み込み機器向けOSの名前はない(Windows CEはx86もサポートしているが)。あるのはGoogleのAndroid、あるいはMeeGoであり、WindowsをサポートしたOak Trailに加わるのはフルスペックのWindowsであるWindows 7だ。Windows Mobile(Windows CEをベースにしたPDA/スマートフォン向けの実装)がARM専用であることを考えると、その後継であるWindows phoneがARM専用であってもおかしくないが、MoorestownやMedfieldに、スマートフォン向けOSであるWindows phoneが対応しないというのは、Intelにとって愉快な話ではないだろう(皮肉にもWindows MobileがARM専用になったのは、IntelがXScale事業を行なっていた期間のことだが)。

　AtomでGoogleのAndroidと、自社が深くかかわったLinuxベースのMeeGoを推すIntelと、ARMのアーキテクチャライセンスを取得し、Windows phoneをARMへ特化させようとしているMicrosoft。この分野における両社の対立は、避けられないもののように思える。

　しかし、この対立が両社間の全面戦争につながる、というのは早計だ。両社は、ある意味大人の関係であり、利益になる部分では手を握り、そうでない部分では対立も辞さない。あくまでも是々非々の関係であり、それは過去にもたびたび示されてきた。そうでなければ、両社の関係そのものが独禁法上の問題となっただろう。

　したがって、今回の提携でMicrosoftがWindows 7(フルスペックのWindows)をARMに移植するのでは、という憶測はあり得ないと筆者は考えている。すでに述べたように、仮にWindowsをARMに移植するのだとしても、そのためにアーキテクチャライセンスを取得する必要はない。ARM向けのLinuxを開発したデベロッパーは、アーキテクチャライセンスを取得しただろうか。そんなものは要らなかったハズである。

　そもそも、現時点においてARMアーキテクチャのプロセッサにWindows 7を移植してメリットがあるのかどうかも良く分からない。Windows 7のベースとなるIntelのメインストリームプロセッサと、ARMプロセッサは、相当に性格が違っているからだ。

　アーキテクチャもOSも違う2つのプラットフォーム間で性能を比較するのは難しいが、表は筆者の手持ちのノートPCとiPadで、JavaScriptのベンチマークテストであるSunSpider 0.9を実行した結果だ。この表からまず言えることは、このテストの結果はブラウザに依存する部分が非常に大きい、ということである。4種類のブラウザをテストしたIdeaPad U350とThinkPad X200sの結果を見れば分かるように、最速グループがAppleのSafariとGoogle Chromeで、それより少し遅れてMozilla Firefoxが続き、大差がついてIE8という結果になっている。IEを除く3種類のブラウザをテストしたMacBook Airの結果でも、ほぼ同様の傾向となっている。この3機種のテストから、Safari 5.0が内蔵するJavaScriptエンジンは高性能であり、Appleにはこの技術に関する蓄積があるのではないかと推定される。

　ところがiPadのスコアを見ると、MacBook Air上のSafariに対して、20倍以上の時間がかかっている。プロセッサの動作クロックが半分に近いことを勘案しても、10倍ほどの差があることになる。Appleが自社製プロセッサに最適化したと思われるiPad上のSafariでもこの差が生じているということは、プロセッサの素の処理能力に相当な差があることをうかがわせる(ただしIdeaPad U350とIE8によるスコアにはかなり近接しており、iPadの使用感がサクサクしたものである秘密の一端もうかがえる)。

　ここでiPadと比較したのは、筆者が持ち歩き用に使っているモバイル向けのノートPCであり、決して高性能PCではない。それでもARMアーキテクチャのA4との性能差は大きい。だが、だからARMのアーキテクチャが劣っているというのではなく、10時間というバッテリ駆動時間を700g弱の本体で実現するには、性能を抑えてでも消費電力を削減することも必要になるだろう、ということだ。

　現在のARMのアーキテクチャは、バッテリ駆動されるモバイル機器向けを意識しており、消費電力と重量の両面で不利になるHDDが事実上不可欠なWindowsを載せても、おそらくはミスマッチになるだろう。フルスペックのWindowsを快適に利用できるARMアーキテクチャが技術的に不可能だとは思わないが、それはIntelがメインストリーム向けとは別に省電力向けのAtomプロセッサを開発したように、現在のARMプロセッサとは別にWindows向けのARMプロセッサを開発する必要が生じるのではないか。しかも、ソフトウェア資産がゼロのところから、IntelベースのWindowsと競うことまで考えると、ARMにとってそれほど魅力的な市場とは思えない。ARMでWindows 7が動くというのは「真夏の夜の夢」、そう筆者は考えている。