SLAとOLA、UCの違い：三つの合意の役割

要点： SLAは、サービス提供会社が顧客に対して行う約束です。OLA（運用レベル合意）は、提供会社の社内チーム同士の約束で、SLAを守れるようにするためのものです。UC（Underpinning Contract、外部委託契約）は、外部の事業者と結ぶ契約で、役割はOLAと同じです。SLAの各目標の裏には、それより遅くないOLAかUCが必要です。

ITサポートを外部の会社から購入するとき、お客様が結ぶのは三つの合意のうちの一つ、SLAです。残りの二つはその裏側にあって見えませんが、SLAの数字が現実的かどうかを左右します。この記事では、三つがそれぞれ何であり、当事者は誰か、どう積み重なるのか、そして情シスが外部委託を検討しているときにこの図が何を意味するのかを説明します。

外部の定義は2026年10月28日に確認しました。参照したのは、WikipediaのService-level agreement、Operational-level agreement、Service-level objectiveの各項目です（いずれも2026-10-28確認）。「Underpinning Contract」はITILの用語ですが、ITIL用語集の原文は同日に取得できていません。そのため、以下のUCの説明は引用ではなく当社なりの平易な解釈です。Brocentの数字は、公開しているSLAのページによります。

SLA・OLA・UCの違いは何か

三つを分ける最も簡単な方法は、「誰と誰が結ぶのか」を問うことです。

SLA（サービスレベルアグリーメント）： サービス提供会社と顧客のあいだの合意。顧客が気にする言葉、つまり初回応答、復旧、対応時間帯、可用性、報告で、何を期待できるかを定めます。
OLA（運用レベル合意）： 同じ提供会社の内部にあるチーム同士、たとえばサービスデスクとネットワークのエンジニアリングチームのあいだの合意。ある部署が別の部署に対して何を、どのくらいの速さで行うかを定め、提供会社がSLAを守れるようにします。
UC（Underpinning Contract）： 提供会社と外部の事業者、たとえば回線事業者、ソフトウェアベンダー、ハードウェア保守会社とのあいだの契約。外部事業者が提供会社に対して何を、どのくらいの速さで行うかを定め、やはりSLAを下支えします。

この三つは、どれか一つを選ぶものではありません。一本の鎖の異なる層であり、顧客に見えるのは最上位の層だけです。

SLAとは何か、誰のためのものか

WikipediaのService-level agreementの項目（2026-10-28確認）は、SLAを、サービス提供者と顧客のあいだの、通常は拘束力のある契約であり、サービス品質、可用性、責任といったサービスの特定の側面を定めるものとしています。また、SLAには通常、稼働時間や初回解決率といった指標に対する測定可能な目標、つまりサービスレベル目標が含まれると述べています。

SLAは顧客のために書かれます。「どのくらいで誰かが応答するのか」「いつ直るのか」「直らなかったら何が得られるのか」に答えるものです。内容の詳細はITサポートにおけるSLAとはで、優先度が目標値を決める仕組みはP1〜P4の優先度ガイドで説明しています。

同じ項目には、大きな組織では社内でもSLAを結び、ある部署が顧客、別の部署が提供者になることも書かれています。これも正当な使い方ですが、OLAと混同しやすいため、この記事では、SLAは顧客向けの合意、OLAは提供会社の社内の合意として使い分けます。

OLAとは何か

WikipediaのOperational-level agreementの項目（2026-10-28確認）は、運用レベル合意を、SLAを支える相互依存の関係を定めるものとしています。各社内サポートグループが他のグループに対して負う責任を、サービス提供の手順と所要時間まで含めて明記します。同じ項目は、OLAはSLAの代わりにならないこと、そして複数のサポートチームが行う下支えの作業を揃えてSLAを果たすことが目的であることも述べています。

実務では、OLAは顧客が尋ねることはなくても、いつも体感している問いに答えます。

引き継ぎ： サービスデスクが直せなかったチケットを、次のチームはどのくらいの速さで受け取らなければならないか。
情報： 次の技術者が一から調べ直さなくて済むよう、チケットを回す前に何を書くべきか。
時間帯： どのチームがどの時間帯を担当し、夜間は誰が待機するのか。
エスカレーション： 期限を逃しそうなとき、誰が呼び出されるのか。

これらの答えがなければ、SLAの目標は願望にすぎません。この項目には関連する指摘もあります。下支えとなるOLAが事前になければ、あとから各サポートチームのあいだに合意を作り込むのは、多くの場合とても難しいというものです。OLAが通常、明文化する引き継ぎと連絡先については、L1・L2・L3サポートレベルとエスカレーションマトリクスで説明しています。

名前にはいくつかの言い換えがあります。organizational-level、operating-level、operations-level agreementです。項目では、いずれも同じ意味だとされています。

UC（Underpinning Contract）とは何か

ITILの用語では、UCは、サービス提供会社と外部の事業者のあいだの契約で、事業者の働きが、提供会社が顧客に行った約束を下支えするために結ばれるものです（当社の解釈です。上記の出典に関する注記を参照）。外部の事業者には、たとえば次のようなものがあります。

インターネットや専用線の回線事業者、
ライセンスとサポートを提供するソフトウェアベンダー、
交換部品を供給するハードウェア保守会社、
データセンターやクラウド基盤の運営事業者。

UCは商業条件を伴う本物の契約なので、その中に独自のSLAを持つことも多くあります。違いは、両側にいるのが誰かです。SLAの片側にいるのは最終顧客です。UCでは、提供会社が顧客側に立ち、外部の会社が提供者です。

三つはどうつながるのか

顧客から下に向かって鎖を描きます。

顧客と提供会社のあいだにSLAがある。
提供会社のサービスデスクとエンジニアリングチームのあいだにOLAがある。
提供会社と外部事業者のあいだにUCがある。

それぞれの層は、上の層の約束と同じか、それより速くなければなりません。SLAが重大インシデントへの20分以内の初回応答を約束するなら、初回応答を担当するチームのOLAは、20分が達成できるように設定されている必要があります。SLAが回線事業者の障害を1時間以内にエスカレーションすると約束するなら、回線事業者とのUCは、その速さで相手の障害窓口に連絡する手段を提供会社に与えていなければなりません。

確認の簡単な方法は、時間の配分表を作ることです。SLAの目標を一つ取り、その中に含まれるステップをすべて書き出します。初回応答の目標なら、次のとおりです。

チケットが届き、システムに登録される。
サービスデスクが受け取り、優先度を判定する。
顧客に受付の連絡が送られる。

三つのステップに許される時間の合計が、SLAの数字に収まっていなければなりません。算術を示すための例です（数字は説明のための仮のもので、Brocentの数字ではありません）。SLAが20分以内の初回応答を約束しているのに、社内の合意がサービスデスクに重大チケットの受け取りまで30分を許しているなら、どんなに頑張っても達成できません。人間が失敗する前に、計算のほうが先に破綻しています。

ITサポートを外部委託すると、この図はどう見えるか

外部委託は、この図に二つのものを加えます。契約前にどちらも質問しておく価値があります。

御社の担当者も鎖の一部になる

外部の技術者は、そのアカウントを誰が解除してよいのかを知らなければロックアウトに対応できず、人事の担当者の承認がなければ新入社員のアカウントを追加できません。これらは顧客側の依存関係です。良い合意は、これを顧客の責任として時限付きで挙げます。たとえば、アクセス申請を誰が承認し、どのくらいで承認するのか、といった内容です。IT、人事、総務のあいだの短い社内取り決めとして書く会社もあり、御社側にも、OLAに相当する取り決めがあるとよいでしょう。顧客側の承認者が遅ければ、提供会社の時計はそのことを示すべきで、よく書かれた停止条件があれば、それができます。

提供会社の取引先も重要になる

提供会社が管理できない部分については、SLAはせいぜいUCと同じ強さにしかなりません。回線の障害、ソフトウェアベンダーの基盤の障害、取り寄せ中のハードウェア部品を、提供会社がどう扱うのかを尋ねてください。正直な答えは、たいてい「SLAの範囲で対応し、取引先にエスカレーションして、状況を随時お知らせしますが、取引先の修理時間は当社の管理外です」というものです。更新の頻度とともに書面になっていれば、妥当な答えです。提供会社が修理できないものにまで復旧時間を約束しているSLAは問題です。

提供会社の目標が、取引先の目標と「バックトゥバック」になっているかも尋ねてください。専用線を4時間で直すと約束しながら、自社の回線事業者との契約が24時間を許している提供会社は、そのリスクを抱えています。それは目標の未達として表れるか、免責事項の制限に埋め込まれます。

具体例：オフィスのインターネット障害

これは説明のための想定で、実在の顧客ではありません。小規模なオフィスで、平日の午前中にインターネットが切れたとします。

ユーザーが障害を報告します。オフィスとIT提供会社のあいだのSLAは、業務に影響する障害には、定められた分数以内に初回応答すると定めています。
サービスデスクがチケットを登録し、原因が建物の外にあることを確認して、ネットワークチームに回します。そのときOLAが、ネットワークチームがどのくらいの速さで受け取るべきかを定めています。
ネットワークチームが、回線事業者の障害窓口に連絡します。UCが、回線事業者の対応時間と修理時間を定めています。
提供会社は、回線事業者が回線を修復するまで、合意した間隔で顧客に状況を連絡し、その後チケットを閉じて根本原因を記録します。

顧客が「誰が遅いのか」と尋ねたとき、層ごとの合意があれば答えははっきりします。最初の返信が遅いのは、提供会社のSLAの問題です。提供会社の社内の引き継ぎが遅いのはOLAの問題です。回線事業者の修理が遅いのは、提供会社が顧客に代わって管理すべきUCの問題です。層がなければ、答えは「全員が少しずつ、そして誰も責任を負わない」になります。

全社に影響する障害については、コミュニケーションと役割を扱った重大インシデント管理のプロセスをご覧ください。

SLAとSLO、KPI、契約書の違い

これらの用語は重なるので、短く整理します。

SLAとSLO： SLOは、SLAのなかの測定可能な目標の一つです。WikipediaのService-level objectiveの項目（2026-10-28確認）は、SLAを、どんなサービスを提供し、どう支援し、時間、場所、費用、性能、各当事者の責任を定める合意全体とし、SLOはその具体的で測定可能な特性だとしています。
SLAとKPI： KPIは、チームが自らの成果を追うために使うあらゆる指標です。SLAの目標は、提供会社が顧客に約束したKPIです。
SLAと契約書： SLAは通常、契約書の別紙です。契約書本体が扱うのは価格、期間、責任、解約です。
OLAとSLA： OLAは社内の合意で、SLAを支えます。SLAの代わりにはなりません。

SLAやOLAを測るときによく使われる指標は、MTTR・MTBF・MTTAの解説と初回解決率（FCR）で説明しています。

発注側と提供側がよくやる間違い

SLAだけを全体像と考える。 SLAは単体では完結して見えますが、信頼できるかどうかは、その裏にあるOLAとUCで決まります。
第三者の障害に復旧時間を約束する。 提供会社が約束できるのは、取引先の障害への対応とエスカレーションです。自社で管理できない修理時間は、更新ルールとともに免責事項に入れるべきです。
OLAをSLAより遅く設定する。 算術が先に破綻し、責められるのは窓口の担当者です。
引き継ぎに責任者がいない。 二つのチームがそれぞれ「相手が持っている」と思い込むと、時計は進むのに、誰も作業しません。OLAには、誰がいつまでに受け取るかを書くべきです。
顧客側の遅れを書かない。 顧客の承認者が図に入っていなければ、提供会社は返事を待つあいだも時計が進みます。公正な合意は、これを明示的に扱います。
見直さない。 チームも取引先も変わります。2年前に決めた目標は、もう合わないかもしれません。SLAを変更するときは、OLAとUCも見直してください。
社内SLAとOLAを混同する。 御社が部署間で社内SLAを運用しているなら、そのまま社内SLAと呼べばよいのですが、それが提供会社自身のOLAの代わりになるとは考えないでください。

OLAとUCについて、提供会社に何を尋ねるべきか

提供会社の内部文書を見る必要はありません。結果についての次の質問ならできます。

SLAのどの目標が外部事業者に依存していて、その障害はどう扱われるのか。
チケットはサポートレベル間でどう引き継がれ、受け取りまでの最大時間はどれだけか。
営業時間外は誰が待機し、重大チケットはどうやってその人に届くのか。
引き継ぎの各段階はどう計測され、受け取るレポートに出てくるのか。
取引先が遅いとき、どうするのか。名前のある連絡先を伴うエスカレーション経路はあるか。
顧客側のどの作業が時計を止め、止まったときはどう知らせてもらえるのか。
私のSLAを支える社内の合意と取引先との契約は、どのくらいの頻度で見直されるのか。

これらに明確に答えられる会社は、SLAの裏側の鎖をおそらく真剣に考えています。

BrocentはSLAをどう示しているか

SLAとサービス優先度のページでは、顧客向けの合意を公開しています。5段階の優先度（P1〜P5）ごとの初回応答、リモート対応、オンサイト、復旧の目標、2種類のサービス時間帯（8x5と24x7）、影響度と緊急度のマトリクスです。2026年10月28日時点の表では、P1とP2の初回応答が15分、復旧の目標がP1は営業時間で8時間、P2は24時間です。ページには、数字がサービス時間帯と契約条件に左右されることも記載しています。

このページが扱うのはSLAです。当社のチーム間の社内の合意や、取引先との契約は、そこで公開している範囲に含まれません。お客様が求められること、そして求めるべきことは、SLAが実際に計測されているという証拠、つまり各目標に対する実績の月次レポートです。サービスの提供のしかたはマネージドITサポートのプランと24時間365日のヘルプデスクで説明しており、マネージドITサポートのプランとユーザー単価では、公開している初回応答の約束とプラン料金を並べて掲載しています。