最終更新日: 2025年8月16日 by it-lawyer

こんにちは、IT企業のための弁護士、宮岡遼です。

今回は、IT企業が必要なSLAについて説明したいと思います。

SLAは適当に定めてしまうと、自らの首を絞めてしまい、損害賠償責任を増やすという自分も傷つく可能性のある諸刃の刃とも言えるものです。

逆に、SLAをしっかり定めた場合は、品質保証がされているサービスとして顧客の不信感を払拭して成約数が増えます。

システム開発においては、ミスコミュニケーションが減って関係者のストレスが軽減し、紛争も減ります。

この記事を最後まで読んでいただくことで、IT企業に必要なSLAの内容・種類、その定め方のポイント、相談する弁護士を選ぶ際のポイントについて知ることができます。

それでは、説明していきます。

SLAとは

SLAとは、Service Level Agreementの略です。

その内容は、ITサービスの提供者とユーザー・顧客の間に取り交わされる合意文書であり、提供されるITサービスの内容と品質基準を明確に定めたものです。

例えば、サービスの稼働率が●%以上、障害の際の平均復旧時間が●時間以内、バックアップデータの保存期間、問合せに対するサポート内容などが記載されます。

SLAは、物理的には契約書と別途の書類として整理されますが、ITサービスの提供者とユーザー・顧客の合意内容とされる点では契約書と同じ意味をもつものとなります。

SLAを導入する意味

SLAを導入する意味や目的は、ユーザー・顧客の期待を管理し、期待されるサービスレベルと提供するサービスレベルのバランスを取りながら、ITサービスの品質を段階的に改善していくこととされています。

SLAを導入することによって、ユーザー・顧客の期待値コントロールを行なって、無駄なクレーム対応の工数を減らすことができるということですね。　

また、ITサービス提供者の側からすれば、自社のサービスの各項目の品質を整理する機会となるとともに、サービス提供状況のデータを取得することにより、継続的なPDCAサイクルによる品質向上を行うことができることとなります。

ITサービスを提供する企業にとっては、SLAがどのような項目を定めるものなのかということを知るだけでも、ITサービスの品質管理は楽になり効率化することができるでしょう。

実際の現場では、大企業は品質管理・改善の指標の素材となることに着目して、スタートアップ・ベンチャー企業ではユーザー・顧客に対するITサービスの品質の最低保障ないしは品質のアピールによる失注防止策として利用されているのが多いように思います。

SLAが必要な場面

SLAが想定される場面は大きく以下の３つに分かれます。

①は、日本ではあまり利用されていません。

１つの会社内で完結するITサービスの場合は、ITサービスがビジネスのためというようりも社内業務の効率化のための場合が多いと思われるので、無理に作る必要はないでしょう。

②は、大企業では利用されていることがあります。システム開発でも利用されます。

③は、大企業のみならず、スタートアップ・ベンチャーでも広く利用されています。自社サービスの提供のみならずシステム開発でも利用されます。

SLAの種類

• １：１型と１：n型

SLAには、１：１型と１：n型があります。

１：１型というのは、ユーザー・顧客ごとに契約書を作成して取り交わす場合のことを言います。情シスの親会社と子会社の契約、問合せ→成約という流れでそれぞれのユーザー企業とITサービスの契約を結んでいくときが該当します。

１：n型の場合は、特にクラウドサービスなどにおいて、多数のユーザー・企業と同じSLAの内容を合意する場合です。

契約書の締結というようなものではなく、例えば、「利用規約・SLAへ同意する」横のチェックボックスにチェックさせたり、自社が用意した「サービス利用規約・SLA」に同意して申込むと記載した申込書の提出を受ける場合があるでしょう。

この場合は、民法上の「定型約款」というものに該当することとなり、内容を改訂するには民法の規定に反しないようにする必要があります。

ITサービスの契約書に詳しい弁護士に相談すると安全です。

• 責任保証型と努力目標型

例えば、責任保証型は、SLAで定めた数値を下回った場合には一部返金・利用料金の減額を行うなどです。

努力目標型は、SLAで定めた数値をを下回ったとしても一部返金・利用料金の減額などのペナルティを受けません。努力義務を怠ったというような例外的な場合にのみ、そのような責任を負うこととなります。

１：１型は努力目標型が、１：n型では責任保証型を求める傾向が強いとされています。

その理由は、１：１型は継続的にサービスレベルの改善・目標達成のプロセスが重視されるのに対し、１：n型はITサービスの性能・機能に重点が置かれるからと言われています。

大企業とスタートアップ・ベンチャーでの使い方は異なる

大企業がSLAを使う際には、ITサービスの品質管理・改善の指標の素材となることに着目して、利用することが少なくないでしょう。

スタートアップ・ベンチャー企業は、SLAをユーザー・顧客との間で取り交わすことになるでしょう。

そこでは、ITサービスの品質のアピールに使うというのが現実的です。　最低限の保障や宣言によって潜在顧客の不安を解消して失注を予防した上で、品質よりも課題解決において顧客にニーズを拾っていくという方が大事です。

システム開発の合意形成・ミスコミュニケーションの予防としても使われる

SLAは、企業の規模にかかわらず、システム開発案件における合意形成・ミスコミュニケーションの予防策として使用されることがあります。

現在の現場では、システム開発を各工程ごとに区切って契約を取り交わすことが少なくないですが、そのそれぞれの工程でSLAを作ることによって、システム開発で起きがちな認識のずれをできるだけ防ぐというものです。

SLAの具体的な内容

例えば、セキュリティーサービスにおいて、まずは以下のようなSLAを用意することが考えられるでしょう。

責任保証型とする場合は、「備考」欄を「補償内容」欄に変更し、補償内容を記載します。

別紙１

 SLA(Service Level Agreement)

カテゴリ	サービス項目	サービス内容	備考
可用性	サービス時間	24時間365日 （計画停止/定期保守を除きます）
	計画停止予定通知	●日前にメール/ホームページにて通知します
	サービス稼働率	●％以上
	ディザスタリカバリ	災害発生時のシステム復旧及びサポートとして、遠隔地のバックアップ用データセンタで保管している日次バックアップデータと予備システムへの切り替えを行います。
	重大障害時の代替手段	早期復旧が不可能な場合の代替措置として、バックアップデータの取得が可能なホームページを用意します。
	代替措置で提供するデータ形式	CSVあるいはExcelファイルで提供
	アップグレード方針	年●回の定期バージョンアップ を実施
信頼性	平均復旧時間	●時間以内
	システム監視基準	１日●回のハードウェア／ネットワーク／パフォーマンス監視
	障害通知プロセス	指定された緊急連絡先にメール／電話で連絡し、併せてホームページで通知
	障害通知時間	●分以内
	障害監視間隔	●分以内
	サービス提供状況の報告方法／間隔	●月に１度ホームページ上で公開
	ログの取得	セキュリティ（不正アクセス）ログ／バックアップ取得結果ログを利用者の要望に応じて提供
性能	オンライン応答時間	●秒以内
	バッチ処理時間	●時間以下
拡張性	カスタマイズ性	利用画面上の項目配置変更や新 規項目の追加が設定画面より可能
	外部接続性	API（プログラム機能を外部から利用するための手続き）を公開
	同時接続利用者数	●ユーザ（保証ではなく最善努力数値とする）
サポート	別紙２「サポート仕様書」による
データ管理	バックアップの方法	日次でフルバックアップ。遠隔地のデータセンタにテープ形式保管。アクセス権はシステム管理者のみに制限。復旧／利用者への公開の方法は別途規定
	バックアップデータの保存期間	●か月以上
	データ消去の要件	サービス解約後●ヶ月以内にデータおよび保管媒体を破棄
セキュリティ	公的認証取得の要件	ISMS 認証取得 プライバシーマーク取得
	アプリケーションに関する第三者評価	年１回、外部機関によりサービスの脆弱性に関する評価を受け、速やかに指摘事項に対して 対策を講じる
	情報取得者の制限	利用者のデータにアクセスできる社員等はセキュリティ管理者の許可を得た者に限る
	情報取扱い環境	オフィスは ICカードによる運用で執務室に入室可能な社員等を最小限に制限しており、PCはすべてシンクライアントである
	通信の暗号化レベル	SSL あるいはVPN

SLAの定め方のポイント

自らの首を絞めることがあることにも注意

責任保証型として定める場合、該当数値を下回った際には補償内容を実行しなければなりません。

攻めるところと抑え気味にいくところをちゃんと考えて定めましょう。

SLAは紛争となったときに裁判官が参照する資料でもあります。

ITサービスに強い弁護士に、裁判になったときにどうなるかという見込みを聞いて参考にしましょう。

柔軟に運用するためのポイント

• 契約書とは分ける

SLA文書は、基本契約書、個別契約書などの契約書とは物理的に分けて独立した文書にしましょう。

もし、基本契約書、個別契約書などとひと続きの文書としてしまうと、仮に契約時に経営層の決済を得ていた場合、SLAの内容を改定する度に経営層の決済を仰がなければならなくなり、運用上困ります。

SLAは半年〜１年のスパンで見直すものです。また、契約更新をさせたいITサービス提供者にとっては契約期間中でも機会をとらえてITサービスの品質改善をアピールしたいものです。

これらのことから、SLAは契約書自体よりも改訂する期間は短いものなのです。

• 定型約款に該当する場合に注意

１：n型の場合は、特にクラウドサービスなどにおいて、多数のユーザー・企業と同じSLAの内容を合意する場合です。

契約書の締結というようなものではなく、例えば、「利用規約・SLAへ同意する」横のチェックボックスにチェックさせたり、自社が用意した「サービス利用規約・SLA」に同意して申込むと記載した申込書の提出を受ける場合があるでしょう。

この場合は、民法上の「定型約款」というものに該当することとなり、内容を改訂するには民法の規定に反しないようにする必要があります。

参考になる資料

経済産業省や総務省、JEITA（一般社団法人　電子情報技術産業協会）からガイドラインなどが出ています。

本記事の筆者もこれらには目を通しています。

注意：現実的なプロセスを経ること

SLAに意欲的な企業は、ITIL（Information Technology Infrastructure Library）などの国際的なガイドラインに基づいた大規模なITサービスマネジメントに取り組むところもあるようですが、このプロセス自体が膨大なコストを要求するものであり、企業を疲弊させてしまうといった本末転倒となってしまうことがあります。

特にスタートアップ・ベンチャー企業は、規模なITサービスマネジメントに取り組もうとして腰が重たくなってしまい、簡便なSLAさえ作らないということに陥るという罠にはまらないように注意しましょう。

ガイドラインなどにあまり忠実にやりすぎず、本記事を参考にして、まずは作ってみて改良していくというふうにやるのが最適解だと思います。

弁護士を選ぶ際のポイント

ポイント１：IT企業の契約書に知見がある弁護士を選ぶ

近年、法律分野や法律業務が多様化しており、弁護士の専門化も進んでいます。意味があって効果の高いSLAを作成するためには、ITサービスの契約書業務に明るく実績も多い弁護士を選ぶことをおすすめします。

ポイント２：アフターサポートがある弁護士を選ぶ

「納品して終わり」ではなく内容について気軽に質問したり相談することが可能な弁護士を選ぶことをおすすめします。

SLAは、サービスやシステムごとに記載する項目や重点ポイントが異なるので、単純な雛形・テンプレートというものがほとんどありません。

質問・協議しながらSLAを作成できる弁護士を選びましょう。

ポイント３：スピード対応が可能な弁護士を選ぶ

SLAの取り交わしはタイミングというものがあります。

全て即日にというのは難しいでしょうが、ご依頼の際にはいつまでに納品してもらいたいが可能か、ということを確認してから依頼するようにしましょう。

ポイント４：誰が実際に業務をするのかを行うのか分かる法律事務所を選ぶ

必ず、ご依頼する法律事務所に対して、誰が実際にあなたがご依頼したSLAを行うのか確認するようにしましょう。

担当の弁護士のプロフィールを確認し、不安であれば他のITサービスの契約書やSLAに強い弁護士に担当してもらうように伝えましょう。

ポイント５：現場感覚を持っている弁護士を選ぶ

弁護士が適切なアドバイスをするためには、弁護士がITサービスやシステムの内容、取り交わしまでの実際の社内プロセス、取引先に対する交渉力の強さ、SLA作成の目的などを理解していることが重要となります。

現場で実際に役にたつSLAを作成するために、事前にオンラインミーティングなどで状況を説明できる弁護士に依頼することが良いでしょう。