クラウドサービスの利用が世の中に普及するに連れて、クラウドサービスで障害が発生して大勢のユーザーが被害を被る事故も増えてきています。
このように、クラウドサービスで障害が発生した場合、ユーザーサイドとしては、ベンダーに対して、契約責任を追求したいところでしょう。逆に、ベンダーサイドとしては、クラウドサービスには絶対はない以上、何か障害が発生するたびに、契約責任を負っていたら、事業が成り立たなくなります。
そこで、今回の記事では、クラウドサービスで障害が発生した場合に、ベンダーがどんな責任を負うのかについて解説したいと思います。
クラウドサービスは完璧ではない
そもそも、クラウドサービスというのは、完璧なサービスではありません。世界最高レベルのクラウドサービスと言って差し支えないAmazonのAWSやMicrosoftのAzureですら、時たま障害が発生しています。
ですが、多くのユーザーは、クラウドサービスに完全性を求めています。
インターフェースや機能は、現状より改善されることさえあれ、改悪ということはありえない。セキュリティに関する事件、事故が頻発している以上、常に最新のセキュリティ対策がアップデートされなければならない。メンテナンスでの計画停止や、緊急時の短時間の停止くらいなら我慢はするが、ビジネスアワーに長時間停止することは、あってはならない。データの破損や消失事故が生じた場合は、何としてもデータを復旧させるべきであり、万が一復旧できないのであれば、損害を全額賠償すべきだ。
・・・ベンダーの皆さんからすれば、「そんな無茶言わないでくれ」という感じですよね。
（まぁ、ベンダーの方でも、クラウドサービスを利用すればバラ色の未来が待ってます！みたいな感じで、過度な期待や幻想を招いている面がありますが）
このように、ユーザーが要求（期待）するサービスレベルと、ベンダーが現実に提供できるサービス内容には、大きな溝があります。
この溝は、ひとまずサービスが安定して稼働している間は、特に問題ありません。ですが、ひとたび障害などが発生した場合、この溝が一気に顕在化して、大きなトラブルになるわけです。
この問題の対策として、経済産業省は、SLA（サービスレベルアグリーメント）を締結しよう、と呼びかけを行っています。
SLAとは何か
SLAとは、「Service Level Agreement」（サービスレベルアグリーメント）の略で、サービスの内容・品質や、障害・事故発生時の対応などを定めたものです。
クラウドサービスの利用規約とは別に（附属資料として）、SLAが定められている場合が多いです（利用規約の中で、SLAに該当する条項が定められている場合もあります）。
それではなぜ、このSLAがクラウドサービスでは必要なのでしょうか。
上で解説したとおり、クラウドサービスでは、クラウド事業者としてできること（提供できるサービスの内容）と、ユーザーが求めるそれに、ギャップがあります。そのため、クラウド事業者として、やるべきことはやっている（適切な範囲内のサービスを提供している）つもりでも、ユーザーから不満が出たり、逆に、ユーザーとしては、クラウド事業者がやるべきことをやっていない（適切な範囲内のサービスが提供されていない）と受け止めても、クラウド事業者から問題ないと言われたりして、トラブルになることがよくあります。
こういったトラブルになった場合、まずは話し合いで解決を目指しますが、解決できなければ、裁判になります。裁判になると、裁判所が、様々な要素（契約書・利用規約や営業資料の記載内容、契約時の担当者同士のやり取り内容、利用料の価格設定、一般的なクラウドサービスの水準、当時の社会情勢、etc）を考慮した上で、クラウド事業者が契約責任を果たしているかどうか、（えいやで）決めることになります。
ですがそれでは、クラウド事業者、ユーザー、いずれにとっても、トラブルになったときに大きな負担になります。それに、結論がどう転ぶかわからないので、そもそも安心して契約を結べません。
そこで、予めサービスのレベルについて合意をしておく（SLAを定めておく）ことで、クラウド事業者、ユーザー、いずれも安心して契約を結ぶことができ、また、クラウド事業者がやるべきことをやっているか（適切な範囲内のサービスが提供されているか）、何かあったときに明確に判断できるようにすることができるようにするわけです。
どうでしょう。SLAの重要さについて、クラウド事業者、ユーザー、いずれの立場からもお分かりいただけましたか。
このように重要なSLAですが、大手企業以外では、きちんと定めているクラウド事業者は、ほとんどありません。それはなぜかというと、クラウド事業者の皆さんが、SLAに何を規定すればいいのかについて、あまりよくわかっていないのですね・・・。
SLAには何を規定すればいいのか
そこで今回、SLAには何を規定すればいいのかについて解説をします。
とはいっても、まずは現物を見たほうが早いでしょう。
天下のGoogleのSLAは、どんなかんじでしょうか。
思いのほかシンプルな内容ですよね。ようするに、サービスの各月の稼働率を一定の数値で保証して、その保証が下回る月があった場合に、翌月以降の利用料金に充当できる「サービスクレジット」が発行される、という内容です。
それでは、同じくITの巨人であるMicrosoftはどうでしょうか。
各サービスごとに、細かくSLAが定められていますが、基本的には９９．９％以上の可用性を保証していますね。
では、国内大手企業ということで、NTTコミュニケーションズはどうでしょうか。
表を駆使することで、各項目ごとの保証数値がわかりやすいですね。また、保証数値を下回った場合に、Googleのように「サービスクレジット」が発行されるのではなく、シンプルに料金を返還することになっています。
このように、SLAと一口に言っても、クラウド事業者によって、定めている内容が全く違います。いったいぜんたい、SLAには何を規定すればいいのでしょうか。
困ったときは、お役所の見解を聞いてみましょう。経産省は、「SaaS サービスを利用する中小企業およびサポートする IT ベンダや IT コーディネータ、あるいはサービス提供企業ばかりでなく、SaaS に関心のある人々が積極的に活用されることを切に願って（「発刊に寄せて」から抜粋）、平成２０年に「SaaS向けSLAガイドライン」を公表しました。
それが、こちらです。
・・・長い。
とても有益な情報が盛り込まれているのですが、いかんせん、普通の人が読み込むにはしんどいボリュームですね。端的に、SLAにはどんな項目を書けばいいのか知りたい方は、ガイドラインの最後のページの別表「SaaS 向け SLA におけるサービスレベル項目のモデルケース」を見れば、大体のイメージは掴めるでしょう。
とはいっても、クラウドサービスを利用する対象となる社内業務や、サービス上で取り扱われるデータの重要性などによって、これらの項目の内容や基準値は、当然変わってきます。実際、先に紹介したGoogle、Microsoft、NTTコミュニケーションズの各SLAも、ここで挙げられた項目が全て規定されているわけではありません。別表記載のこれらの項目は、一つの参考要素にしていただければと思います。
さて、ここまで読んできて、鋭い方なら疑問を感じているかもしれません。SLAでは、色々な項目について保証がされていますが、では、これらの項目に違反（保証数値への未達成）があった場合、クラウド事業者はどんな責任を負うのでしょうか。
SLAに違反した場合の責任はSLA次第
皆さんの感覚からすれば、「保証に違反したなら、契約違反だから、支払った利用料金の返金や、損害賠償の請求、契約の解除ができるのでは？」と思うかもしれません。
ですが、実はそうではないんですね。これは結局のところ、SLAになんと規定されているか次第なのです。
例えば、前回紹介した、Google AppsのSLAを見てみましょう。
このSLAでは、サービスの各月の稼働率が一定の数値で保証されていますが、
『Google が G Suite SLA を満たしておらず、かつお客様が本 G Suite SLA に基づく義務を満たしている場合、お客様は下記のサービス クレジットを受けることができます。』
『本 G Suite SLA は、Google による G Suite SLA へのあらゆる不履行に対して、唯一かつ排他的にお客様を救済する手段を定めるものです』
上記のとおり、その保証が下回った場合でも、Googleの責任（ユーザーの救済手段）は、「サービスクレジット」（＝サービス期間終了後に無償で追加されるサービスの日数、または、毎月後払いで請求するユーザーに対するサービスの日数分に相当する金銭）の発行だけです（利用料金の返金や損害賠償は、請求できないということです）。
しかも、サービスクレジットの発行を受けるためには、
『サービス クレジットの要求義務: 上記のサービス クレジットを受けるには、お客様がサービス クレジットの対象となった時点から 30 日以内に、お客様が Google に通知する必要があります。この要件を遵守しなかった場合、サービス クレジットを受ける権利は失効します。』
ユーザー側からGoogleに対して、30日以内に通知をする必要があります（それをしないと、サービスクレジットを受ける権利は無くなるということです）。
「これはけしからん！責任逃れだ！」と思うかもしれませんが、サービスクレジットの発行がきちんと約束されているだけでも良心的です。というのは、世の中のSLAには、
『本SLAで規定された数値は、あくまでも当社の努力目標であり、この数値を下回ったとしても、本サービス利用契約における当社の債務不履行とは扱われず、利用料金の返金や損害賠償の支払などの責任は生じません。』
というようなことが書かれているものも、多いのですね…。
このように、SLAで一番重要なのは、「保証に違反（保証数値への未達成）した場合、ベンダーがどんな責任を負うと規定されているのか」という点です。
ユーザー側の立場に立つときは、ここは必ずチェックする必要があります。逆に、ベンダー側の立場に立つときは、自社の体力・体制に見合った責任内容に留めておく必要があります。
では、ユーザーとして、ベンダーが定めたSLAに不満がある場合に、どう対応すればいいのでしょうか。逆に、ベンダーとして、ユーザーからSLAの内容に突っ込まれた場合、どう対応すればいいのでしょうか。
SLAをめぐる契約交渉のテクニック
まず、ユーザーからベンダーに対して、SLAの内容の変更を申し入れることは、通常は困難です。というのは、クラウドサービスは、全ユーザーに一律に同じ水準で同じ内容のサービスを提供することによって、コストを下げられる（低額の料金設定ができる）という特性があるため、ベンダーとしては、個別のユーザーごとに希望を聞いていられない、という事情があります。
ユーザーとして、まずクラウドサービスを導入するにあたっては、必ずしも自分が希望する通りのサービスが提供されるわけではない（そういう「わがまま」を言いたいなら、高い費用を払って、希望通りの仕様のシステムをスクラッチで開発してもらうしかない）、ということを念頭に置く必要があります。
その上で、SLAの内容を精査し、リスクとコストのバランスから妥協できるところで、クラウドサービスを選定することになります。
とはいってもベンダーは、必ずしもMAX保証できる範囲でSLAの内容を定めているわけではなく、ある程度バッファを設けた内容にしている面もあります（そうしないと、予期せぬ事態がちょっとでも起きてしまうと、途端にSLA違反になってしまうので）。また、ベンダーにとっても、ビジネス判断でリスクを取る取引をする場合もあります。
そのため、ユーザーが（料金を沢山払ってくれるような）大口の取引先であったり、（導入事例として紹介できれば宣伝になる）有名企業であった場合は、ベンダーとしても、リスクを取ってでも取引を結びたいと考えて、個別の「覚書」を締結するなどして、そのユーザーに限って、バッファの範囲内で、あるいは、それを超えて、SLAの内容を変更してくれるケースも、珍しくはありません。
ユーザーの立場に立つときは、とりあえず、交渉するだけならタダですので、SLAの内容を変更する覚書を締結するよう、申し入れてみればいいのではと思います。
逆に、ベンダーの立場に立つときは、上で書いたような理由を挙げて、変更を拒否しつつ、リスクを取れる範囲で、変更に応じるのがいいのではと思います。
というわけで、SLAに関してひと通り理解できたでしょうか。きちんとしたSLAを定めているベンダーは、まだあまり多くはありませんが、SLAの重要性は、これから益々高まっていきますし、ユーザーからも、SLAの提示を求められる機会が増えてくることは間違いありません。今のうちから、SLAの作成に取り掛かっておいたほうがいいでしょう。
そして、SLAの作成で悩まれたときは、いつでも私に相談してください！
