第 4 章 ASP･SaaS における SLA
4.4 SLA の締結
4.4.1 SLA締結の基本的方法
表 4-１０～表 4-１４において、「SLA締結の候補となる項目」の列に「○」を記して いる評価項目は、特に要求するサービスレベルとサービス提供コストのバランスを注意す べき項目であり、SLAを締結すべき項目の候補となるものである。これらの項目は主と してサービスの可用性に繋がる「稼動率」や各種の「サービスサポート品質」に関するも のである。これらの項目は、ASP･SaaS事業者が提供するSLAのモデル項目として位置 付けることができる。
地方公共団体は、ASP･SaaS事業者が提示するSLAの選択肢に対して、表 4-１０～表 4-１４が示す対策参照値も参考にしながら、以下の観点から、どの項目についてSLAを 締結するか、また業務に必要な要求水準と調達時に設定したコストとのバランスから、
ASP･SaaS事業者から示されるサービスレベル要求の選択肢のどれを選択するかを決定 することになる。
サービス停止時の利用者（職員や住民など）への影響の大きさ
個人情報保護などの法令遵守の観点
データの完全性が損なわれた時の利用者（職員や住民など）への影響の大きさ
ASP･SaaSを利用する場合の利用者目線から見た利便性
4.4.2 SLA締結のモデルケース
地方公共団体にとって、様々なASP･SaaSの中から最適なサービスを選別する場合、
その業務の要求事項を満たせるかどうかが重要である。特に、業務の要求事項に即したサ ービスレベルを必要以上に高く設定し、過剰な追加料金の発生を防ぐことが必要である。
一般的に、品質保証が高いレベルで設定されているサービスは、料金もより高額となるか らである。
業務要求に即して必要かつ十分なサービスレベルの設定を行うため、以下にいくつかの モデルとなるケースを例示する。
【ケース１：稼動率に対するSLA設定値】
稼動率とは、サービス時間帯に占める実稼動時間の割合のことである。ここで、サービ ス時間帯とは、契約サービス時間帯から定期保守時間を差し引いたものである。そして、
実稼動時間とは、サービス時間帯において実際にASP･SaaSの提供が実施された時間の ことである。
システム稼動率とコストはトレードオフの関係にあり、適切なサービスレベル設定が求 められる。
同じサービス時間帯を持つASP･SaaSが3種あると想定する。いずれのシステムも、契 約サービス時間帯は毎日8時～21時であり、月に1度5時間の定期保守がある。そして、
それぞれのSLAは以下の設定値である。容易にイメージできるように、1年間で見た平均 故障時間を算出し同表に記述する。
表 4-１５ 年間でのシステム稼動率に対するSLA設定値と故障時間（例）
SLA設定値 実稼動時間 故障時間（算出）
システムA 99.5% 4,662時間 23時間 システムB 99％ 4,638時間 47時間 システムC 95％ 4,451時間 234時間
※サービス時間帯を4,685時間（13時間×365日-5時間×12ヶ月）として算出 上記の表は、SLA設定値が95%に設定されたシステムCは、1年間に234時間以上の 故障が起きないことを保証しているということである。しかし、稼動率が99％を満たす システムを構築する場合は、一般的にシステムの多重構成が必要となり、構築・運用に要 する経費は倍以上となる。さらに、99.5%を満たす場合は、そのシステム専用の保守要 員を待機させるなど、システムの多重構成に加えて保守体制を充実させる必要があり、さ
らにコストは倍程度になる。そのため、コストに応じて料金が上昇することとなる。
業務の特性上サービス停止が許容できないものであれば、最低でもシステムAと同等以 上のサービスを選定する必要があるが、利用料金は高くなる。ある程度のサービス停止が 許容できるのであれば、利用料金を抑えるためシステムBやCの導入の検討を行うことも 選択肢となる。
NISC（内閣官房情報セキュリティセンター）が策定した「第２次情報セキュリティ基 本計画」（http://www.nisc.go.jp/active/kihon/pdf/bpc02_ts.pdf）においては、「事 故前提社会への対応力強化」を新たに打ち出している。ここでは、事故の可能性を完全に 排除する対策の実現は容易ではないという点に関する理解（気付き）を社会全体で増進し、
万が一問題が顕在化しても、気付きを持って自ら考える主体が、過敏な反応を起こさず、
事実を冷静に受け止めて適切な対応を迅速に行うための取り組みが不可欠としている。こ の観点からは、高い稼動率を求めることだけに終始せず、平時から事業継続性確保を強化 し、さらに障害などが発生した場合に迅速かつ実効的に対応を行うために必要な緊急時対 応体制の強化を推進する必要がある。ASP･SaaS事業者との関連においては、地方公共 団体は早急に復旧すべきシステム機能を平時から特定しておき、これらの機能の復旧に関 してASP･SaaS事業者の対応開始までの時間をSLA締結するなどの選択肢を検討するこ とが望ましい。
【ケース２：障害通知時間に対するSLA】
障害通知時間とは、ASP･SaaS事業者が、どれほど早くシステムの故障を検知して利 用者に通知するかという指標である。あるASP･SaaSには3段階のSLA設定値が以下の ようにメニュー化されていると想定する。
表 4-１６ パフォーマンス監視と通知に対するSLA設定値（例）
SLA値 システムA 日中帯 20分以内 システムB 日中帯 ５時間 システムC 日中帯 翌営業日
通知は直接電話やメールで対応するのが一般的であるから、ASP･SaaS事業者は運用 専門の組織を保持する必要がある。また、20分以内の即時に近い通知が求められる場合 には、ASP･SaaS事業者は緊急対応が遅滞しないように常に余剰要員を確保しておく必 要があるため、さらに運用要員の人数は多く必要になる。そしてASP･SaaS事業者が負 担する人件費は、その分料金にも反映されることになる。
金融システムと連携しているものなど、障害発生時の即時対応が求められる業務につい ては、SLAで定める対応時間はなるべく短い方が望ましい。しかし、システム障害時で も業務に及ぼす影響が軽微で、かつ地方公共団体のシステム担当職員が日中帯勤務のみと いう場合には、システムBやシステムCを検討することが現実的である。
【ケース３：オンライン応答遵守率のSLA設定値】
オンライン応答時間とは、利用者がシステムにアクセスを行い、レスポンスが戻ってく るまでの時間のことであり、オンライン応答遵守率とは、オンライン応答時間の目標値と、
それが遵守できる確率を定めたものである。
表 4-１７ オンライン応答遵守率に対するSLA設定値（例）
SLA値
システムA 3秒以下の遵守率80%以上 システムB 60秒以下の遵守率80％以上 システムC 3分以下の遵守率80%以上
ASP･SaaSは、一般的には複数のユーザでシステムを共有して利用するサービスであ る。システムのCPUやメモリーといったシステムリソースの設計は、全利用者が同時に 最大負荷をかけてくることは想定されておらず、利用者がある程度の集中率でアクセスす る前提で設計されている。オンライン応答遵守率を保証するということは、全利用者分の リソース（通常運用時と比べ数倍になる）を確保することになり、その分必要なコストも 上昇する。
利用者が混雑する主要な住民サービスなどは、利用者を窓口に待たせることになるため 即応が求められ、応答時間に対する要求は厳しい。しかし、過度に厳しいSLAを締結す ると利用が集中しない期間中はシステムリソースに大きな余剰が生じて、サービス利用料 金の上昇に大きく影響してしまう。また、インターネット回線を利用している場合は、途 中にベストエフォートのサービスを含んでいるため、そもそもオンライン応答遵守率につ いてのSLAを締結することが難しい。
上記の３つのモデルケースは、業務が用いるシステムの品質要求に見合ったSLA設定値 を選択することが重要であり、それ以上のレベルのSLA設定値の選択は不釣合いなコス ト増加を招く可能性があることを示している。SLA設定値は各地方公共団体における業 務の要求や組織体制に即した形で決定することが重要である。