AWSをめぐる「驚き」と「誤解」～Amazon Web Services入門(2)

契約の基本は英語、裁判所は米国

　サービス約款やSLAの一部は、日本語でAWSのWebサイトに掲載されている。これは「日本のユーザーがSLAを理解するための補助」であり、最終的に正式なドキュメントは英語版である。特に（前に述べた）約款の変更時などは、翻訳が間に合うまでの間は、英語版しか参照するものがないという可能性も大きそうだ（AWSのサービス追加の速さと、リリースと同時にアナウンスする体質を思い返してもらいたい）。いずれにせよ、ワールドワイドで、均質なサービスを提供していることもあり、これらの内容は、国や地域で変更が加えられることは考えにくい。ユーザーはインターネット経由で何十カ国に存在しているが、取引しているのは「米国のAWS社という1組織だけ」だ。当然、規約類も単一の英文ドキュメントが世界中で適用されることになる。そしてサービスには米国の法律が適用される。万が一AWS社と訴訟になった場合の裁判所は米国になると明記されている。

　大手企業の一部などでは、上記の前提では「社内ルール上、取引ができない」という状況があるようだ。ADSJ社に駆け込んでも解決はしないだろう。ここはAWSパートナーを上手に活用したい。ただ、訴訟までは対応できないというパートナーも多いので、事前によく確認すべきである。

個別契約に応じてくれない

　「個別契約」も従来的なデータセンター事業者に慣れた方の、前時代的な発想である。ユーザーとAWS社の間の関係は、契約関係ではあるが、約款に対する合意によって形成されるものであり、いわゆる個別交渉の契約書に基づくものではない。「社内ルール上、我が社の契約テンプレートに沿った契約がないと利用できない」という形式論にこだわり、結果的にAWSが使えないという状況もあるようだ。

　前節で述べたように、ユーザーとAWS社が直接契約するのではなく、ユーザーは日本のAWSパートナーと契約することで、間接的にAWSを使う方法がある。AWSパートナーのカバレッジにもよるが、少なくともユーザーにとって交渉の余地が生じ、自由度は高まるので、有効な手段といえる。

　ただ、この方法で何もかも完全に（従来通り）上手くいくわけではない。「我が社の契約テンプレート」には、いくつかの改変が必要だろう。場合によっては全然使えないことも想定される。小手先の対応策として、たとえば「AWS社が＊＊しないことを、AWSパートナーが保証する」などという文言を盛り込めないかという案が飛び出すことがあるが、契約上の主体を超えており、このような契約は交わせないことは自明である。ユーザー側も従来的な習慣を墨守（ぼくしゅ）するのではなく、新しい時代に合った新しい考え方に馴染む必要はありそうだ。

　法務関係者の間でもクラウドに対する理解や議論が進んでおり、現実的なリスク判断に基づく新しい契約のあり方が広まっていると聞く。実際、弊社の経験でも、交渉の過程の中で、エンドユーザー側（お客さま）から、まったく新しい考え方のテンプレートが提示されたケースも出てきている。

30日後にサービス撤退？！

　ここまでAWS約款の「驚き」を概観してきたが、クライマックスは「30日撤退問題」だろう。約款上、AWSはサービスの一部あるいはすべてを、ユーザーに30日前にノーティス（通知）することで、完全に停止する権利を留保している。一切の前提条件なし。芝居がかった言い方をすれば、ユーザーが泣こうが喚こうがお構いなしといった風だ。わずか30日の猶予でサービスが止まる恐れがあるとしたら？　企業活動の生命線たるエンタープライズシステムの基盤として、AWSは選択肢にならないと思い込む方が現れるのは不思議ではない。

　ユーザーがこれまで列挙してきたさまざまな「驚き」をすべて理解し、受け入れたとしても、最後の最後にこの問題が待っている。理解も受け入れも、安くて堅牢なクラウド環境を利用し続けるメリットがあるからこそだ。ここで卓袱台（ちゃぶだい）返しのように「あっという間に（＝30日で）やめるかも」と言われれば面食らう方が多いのは事実だ。

　実際、筆者が過去に相談を受けたなかでも、この問題でAWS利用の検討が止まった事案が残念ながらある。今となっては、これは筆者の説明が稚拙だったか、あるいは先方の思い込みが過剰だったかのいずれかだろうと思わざるを得ない。冷静に考えれば、この問題はそれほど大きくないはずだ。

　詳細は後述するが、ここではこれまでに書いてきたことを踏まえて、次の推測を示しておこう。AWSがサービスを停止すれば、オンラインストアのAmazon.comも大きな影響を免れないだろう。世界最大のeコマース企業、6兆円の売上を誇るスーパーカンパニーが、活動を著しく制約されそうだ。これほど考えにくい事態もない。

　筆者は、この条項は一種の米国流の契約上のマナーのようなものだと考えている。実際に撤退する気など毛頭ないのだが、撤退に関する記述がまったくないのはオカシイ（マナーに反する）というわけだ。いまでこそAWSは、一種の社会インフラとなっているが、そもそもはサービスインからわずか8年しか経っていないベンチャー企業である。30日を確保したのは誠意とすら言えるのではないか。実際、日本の社会インフラ事業者（例：通信事業者など）の約款などを見直してみると、個々の利用者へのサービス遮断については延々と記載されているが、事業そのものの撤退に関しては明記されていないようである。日本の事業者は「撤退など考えられないし、考えていない」とも受け止められるが、逆に、やろうと思えば即日サービス停止も可能な風なのだ（規制当局からいろいろ言われるかもしれないが、廃業を決め込めば気にする必要もないだろう）。契約は「言った、言わない」や「揉め事を回避する」ためにある。撤退に関して明記するのとしないのと、どちらが優れた態度なのか^*1、改めて考えみるとよいだろう。

驚きに関するまとめの解説（なぜこれでOKなのか）

　ここまでさまざまな「驚き」の例を挙げてきた。他にもありそうだが、このくらいにしておこう。「どうしてこんなにAWSは何もかも風変わりなのでしょう」「本当に使いにくいですよね」、そんな声も聞こえてくるのだが、ここでそろそろ根本的な理解に切り込んでみたい。基本原理がわかれば、これまでの疑問が氷解するだけでなく、今後、どのように対応していけばよいか、光明が得られよう^*2。

　「驚き」の根本原因は那辺（なへん）にあるのか？　それはユーザー側が慣れている「取引の形態」と、AWSをめぐる「取引の形態」の違いにある。従来的なIT産業の慣行をベースにした理解や契約テンプレートは、パブリッククラウドの調達に馴染んでいないと言い換えてもよい。だからといって、クラウド時代の取引形態が新しすぎるというわけではない。実は従前からある契約形態の一部を援用することで、対応は可能だと筆者は考える。

　エンタープライズシステムの調達における従来型の考え方は、基本的にはオーダーメイド型である。取引のトリガとなるのは、ユーザー側のニーズだ。たとえばRFPを提示するような形で、ニーズが示される。ニーズは個別に多様であるが、これに応えるITベンダー側も多様な選択肢を用意している。両者がマッチングすれば契約交渉となり、契約が締結されればサービス提供となる。契約は「ユーザーのニーズ」という原点に基づいているので、当然、ユーザー主導でユーザーのニーズに沿った条項が盛り込まれる。ITベンダー側が契約書のテンプレートを提示したとしても、個別交渉の余地があるのが普通だ。取引のすべてはユーザーのニーズを満たすためになされるので、掛かる費用のすべてとリスクはユーザー側が負担する。リスクの一部をベンダーに転嫁している場合には、逆にサービスを一定期間以上利用しなければならないなどの縛りが生じる場合がある。結果、選定したITベンダーとは一蓮托生の関係になりがちだ。ニーズが高度になればなるほど、当然費用も嵩（かさ）む。ITベンダー側は高いマージンを確保していることが多く、価格交渉は日常茶飯事である。

　これに対して、AWS社（をはじめとするパブリッククラウド）では、取引のトリガはAWS（ITベンダー、と読み替えてもよい）側にある。サービスはレディメイド型であり、ユーザーが興味を持つ以前から準備され、提供されている。多少は選択肢の幅があるように見えたとしても、メニュー化されたオプションの一部にすぎない。ここで提供されているサービスが自分のニーズに合うと思えばユーザーは使えばよいし、合わなければ無理に使う必要はない。契約は約款の形で提示され、ユーザーには合意するかしないかの選択肢がある。サービスが気に入っても、約款に合意できなければ使わなければよい。約款はITベンダー側が、なるべく多くのユーザーに満足してもらえるよう、かつ、双方のリスクを最小化するように企図されている（ユーザー数を増やしたいベンダー側としては当然の対応）。最初に膨大な投資が必要だが、この原点においてすべてのリスクはAWS社側が負っており、ユーザーにリスクはまったくない。価格は約款に基づいており、価格交渉の余地はない。

　ながながと書いたが、以上をまとめると次の表3-1のようになる。

　これがまったく新しい取引形態かというと、そういうわけではない。類似の例としては電話や携帯電話の利用が挙げられよう。前記の表の中で「クラウド型IT調達」の「ITベンダー」の部分を通信キャリアで読み替えてみると、意外としっくりとくるのではないか。大手通信事業者は客（ユーザー）のニーズを先取りして巨大投資を行っている。ユーザーは（投資費用に比べれば）圧倒的低コストで通信施設の機能を利用することができる。細かいオペレーションは機器のマニュアルなどを参照しながらセルフサービスとなるし、利用は（誤用も含め）自己責任である。

　「通信業なら理解できるが、AWSはそうではないだろう」という声も聞こえてきそうだが、AWSは、もう、従来の産業の枠に当てはめることが非常に難しい存在になってきていると筆者は思う（実際にそう感じている人も多い）。クラウドベンダーの中には本業は通信業で、その延長線で（AWS同様の）サーバー貸しを行っている事業者もある。ネットワークに繋がっていないコンピュータなどもはやほとんど意味はないし、ネットワーク自体もオープンなものから、クローズドなものまでさまざまなものが用意できる。通信（約款型ビジネス）の先にクラウド（コンピュータのリソース貸し）があることは不思議ではないし、むしろ自然なことだと理解したい。

書誌情報

タイトル：Amazon Web Services入門
サブタイトル：－企業システムへの導入障壁を徹底解消－
著者：加藤 章
判型：A5判
ページ数：192p
定価：2300円＋税
ISBN：978-4-8443-3647-1