外部ベンダーにWebサイト制作や運用を任せていると、「対応が遅い」「品質が安定しない」「追加費用の線引きが曖昧」といった不満が起きがちです。経営者・事業責任者の立場では、現場の努力だけに依存せず、契約と運用ルールで再現性を担保する必要があります。

ベンダーコントロール＝外部委託先の成果・品質・対応を、契約と日々の運用で管理することです。
SLA＝サービス水準を指標と目標値で取り決める合意文書（または契約条項）です。
本記事では、Web運用で使いやすいSLAの項目例と、要件定義から落とし込む考え方を整理します。

ベンダーコントロールとSLAの基本

なぜSLAが経営判断に効くのか

Webサイトは「作って終わり」ではなく、運用中に機会損失や信用毀損が起きます。フォーム障害で問い合わせが止まる、更新が遅れて重要情報が古いままになる、表示が遅くなって離脱が増えるなどです。SLAを整備すると、次の意思決定がしやすくなります。

• どの水準まで守るかを先に合意でき、予算と優先順位を決めやすい
• 障害時の初動や報告ラインが決まり、被害拡大を抑えやすい
• 品質を指標で評価でき、乗り換え判断の材料が揃う

SLAとKPIの違いを押さえる

KPI＝目標達成度を測る指標です。売上、商談、採用応募、問い合わせ数など、事業成果に直結する指標が中心になります。
一方でSLAは、成果を生む前提条件（止めない・遅らせない・一定品質で回す）を保証するための合意です。SLAの数値を守ってもKPIが伸びない場合は、訴求や導線、集客設計など別の論点が残っていると切り分けられます。

契約とSLAの役割分担

SOW＝作業範囲と成果物、前提条件を定義した文書です。SLAはSOWとセットで考えると、費用と責任のズレが減ります。

• SOW：何を作り、何を運用するか（範囲外も含める）
• SLA：運用中の品質・対応速度を、測れる指標で合意する
• 運用ルール：連絡手段、承認期限、報告フォーマットなど回し方

SLAが機能しなくなる典型パターン

SLAは「数値を書けば安心」ではありません。次の状態だと形骸化します。

• 測定方法がなく、報告が主観になる
• 例外条件がなく、休日・夜間・第三者サービス障害の扱いで揉める
• 変更管理がなく、追加改修が都度見積もりで遅延しやすい
• 依頼側の承認待ちが多いのに、遅延の責任だけがベンダーに寄る

このため、SLAは契約条項だけでなく、運用設計（会議体・連絡手段・承認フロー）とセットで作ります。

SLAが必要になる場面（リニューアル・ベンダー変更・運用不安定）

リニューアル時に起きやすい落とし穴

リニューアルは制作物の品質だけでなく、公開後の運用まで含めて成功と定義すべきです。公開直後は軽微な不具合、ページ追加、文言修正などが集中します。SLAがないと「どこまでが無償で、どこから追加か」「誰が優先度を決めるか」が曖昧になり、初動で不満が蓄積します。

ベンダー変更を検討するサイン

次のサインがある場合、SLAの再設計とベンダー評価を同時に進める価値があります。

• 一次回答や改修着手のタイミングが担当者次第
• 障害報告が遅い、または原因と再発防止が共有されない
• 納期と範囲が曖昧なまま進む
• 運用ドキュメントがなく、引き継ぎコストが膨らむ

運用が不安定なときに先に整えること

いきなり厳しいSLAを求めるとコストが跳ねます。まずは現状の事実を揃えます。

• 障害・問い合わせ・改修の履歴（いつ、誰が、どれくらいで対応したか）
• 依頼側の承認フロー（どこで止まりやすいか）
• 現行の運用範囲（保守、更新、監視、セキュリティ対応の有無）
• サイトの目的と優先順位（売上・問い合わせ・採用など）

ここまで整理すると、SLAで守るべき領域が「重要度の高い順」に見えるようになります。目的が曖昧なままSLAだけ厳格にしても、費用対効果は合いません。

SLAに盛り込む項目と目標値の例（運用・更新・障害・セキュリティ）

SLAは、全項目を高水準にするほど良いわけではありません。事業への影響が大きいところから指標化し、測定と報告が回る形にします。以下はWeb運用で使いやすい項目の例です（目標値は一例です）。

チケット＝依頼と対応状況を記録して追跡できる管理票です。
重大度＝障害の影響度で対応優先度を分ける区分です。
インシデント＝障害や事故として扱う事象です。

対象領域	指標	目標値例	測定・報告方法
問い合わせ対応	一次回答時間	1営業日以内	チケットのタイムスタンプで集計
障害対応	初動（一次切り分け）開始	受付後2時間以内（営業時間内）	連絡記録＋インシデント票
障害対応	復旧目標時間	重大度に応じて合意（例：重要は当日中）	事後報告で原因と恒久対応を整理
更新運用	定型更新の反映	受領後3営業日以内	依頼テンプレと反映ログ
改修	小改修の見積提示	依頼後5営業日以内	見積の前提条件と範囲外を明記
セキュリティ	脆弱性対応の方針	重大度に応じた期限を合意	適用内容、影響範囲、再発防止を報告
バックアップ	取得頻度と保持期間	例：日次取得、30日保持	取得ログと復元テスト結果を共有

目標値を決めるときのコツ

• 重大度を先に定義する：事業影響で揃えるほど、合意が早くなります。
• 依頼側の責務も明記する：素材提供、承認期限などを合意しないと、遅延要因が見えなくなります。
• 測定できない指標は置かない：測定できないと運用が回らず、感覚論に戻ります。

作り方：要件定義からSLA草案を作る手順（現状把握→合意→運用設計）

要件定義＝何を実現し、何を対象外とするか、前提条件と責任分界まで合意する工程です。
運用設計＝公開後の更新・保守・改善が滞りなく回るように、役割・手順・判断基準を決めることです。

手順0：窓口と意思決定者を固定し、役割を文章で残す

RACI＝業務の役割を「実行責任（R）／最終責任（A）／相談先（C）／共有先（I）」で整理する枠組みです。依頼側の窓口、承認者、ベンダー側の責任者をRACIで1枚にし、承認が止まるポイントを先に潰します。SLAの数字以前に「誰が判断するか」が決まっていないと、未達の原因が不透明になります。

手順1：サイトの目的と「止めたくない業務」を先に確定する

最初に決めるのは数値ではなく優先順位です。たとえば「問い合わせフォーム」「資料ダウンロード」「採用エントリー」など、止まると機会損失が大きい導線からSLAの対象にします。ここが曖昧だと、全項目を高水準にして費用が膨らむか、逆に重要領域の水準が低いままになります。

手順2：現状の事実を棚卸しし、無理のない初期値を置く

過去の障害・改修・更新依頼を、チケットやメール履歴から「受付→一次回答→着手→完了」の時間で整理します。実績を見える化すると、現実的な目標値と、ボトルネック（承認待ち・素材不足・属人化）が分かります。草案段階は“理想の数字”より“守れる数字”を優先します。

手順3：重大度と受付時間帯を決め、エスカレーションを設計する

重大度の基準は「事業影響」で揃えると合意が速くなります。加えて、営業時間内対応なのか、夜間休日はどう扱うのかを明確にします。エスカレーション＝通常ルートで解決できないときに上位の意思決定者へ引き上げる手順です。誰に・何分以内に・どの手段で連絡するかまで決めます。

手順4：測定できる指標に落とし、報告フォーマットを固定する

SLAは「測定できる」ことが前提です。一次回答時間、復旧目標時間、定型更新の反映期限など、タイムスタンプで追える指標から始めると運用が回ります。月次レポートは、件数・平均・未達理由・再発防止の4点を固定すると、改善が属人化しにくくなります。初期は試行期間を設け、運用で回る指標だけ残す判断も有効です。

手順5：例外条件と変更管理を同時に定義する

第三者サービス障害、依頼側の素材遅延、仕様変更など、SLA未達になり得る例外を先に列挙します。変更管理＝仕様や優先順位の変更を、記録と承認でコントロールする仕組みです。小改修の範囲、見積提示の期限、優先度の決め方まで書くと、追加費用トラブルが減ります。

費用と投資判断：SLA水準とコストの考え方（どこにお金が乗るか）

TCO＝導入後の運用費も含めた総コストです。SLAの議論では、月額だけでなく「障害で失う売上・商談・信用」との比較が重要です。

コストが増える主因は「時間帯」「体制」「監視」の3つ

• 時間帯：夜間休日を含めるほど、オンコール（待機）体制が必要になり費用が増えます
• 体制：属人化を避けるため複数人体制やシニア人材を入れると、単価は上がります
• 監視：監視・アラート設計、ログ管理、定期点検を増やすほど工数が増えます
  加えて、ドキュメント整備や引き継ぎ可能な設計（手順書・設定一覧・権限管理）も、初期に一定の工数が乗ります。これは「担当者が変わった瞬間に品質が落ちる」状態を避けるための投資です。

水準イメージ	コスト傾向	期待できる効果	注意点
最低限：営業時間内中心	抑えやすい	定型更新の遅延や認識違いを減らす	夜間休日の障害は復旧が翌営業日になり得る
標準：重要領域のみ強化	中程度	フォーム等の重要導線の機会損失を抑える	対象外領域を明確にしないと期待値が膨らむ
高水準：準24/7の初動	上がりやすい	重大障害の初動遅れを防ぎ、信用毀損を抑える	例外条件や連絡網が弱いと「高いだけ」になる

投資判断は「守る価値のある導線」に限定して最適化する

SLAをサイト全体に一律適用すると、費用対効果が崩れます。問い合わせ・採用・購買など、事業に直結する導線だけ水準を上げ、その他は標準に寄せると、投資が読みやすくなります。設計の目的は“数字を増やす”ことではなく、重要領域の機会損失を減らすことです。

効果：SLAで得られる成果と限界（事業KPIにつなぐ考え方）

得られる成果1：意思決定が速くなり、改善が回る

SLAがあると、遅延や障害の議論が「誰が悪いか」ではなく「どの指標が未達で、次に何を変えるか」に寄ります。経営側は、未達の原因が体制・範囲・優先順位のどこにあるかを把握しやすくなります。

得られる成果2：ベンダー比較と乗り換え判断が定量化できる

同じ指標でレポートを受け取れると、現ベンダーの課題と、乗り換えで改善できる余地が分かります。さらに、提案段階で「何を守る契約か」が揃うため、見積もりの比較がしやすくなります。

SLAとKPIをつなぐ簡易マップを持つ

たとえば「フォーム停止時間」は問い合わせ数や商談数の減少に直結しやすく、「定型更新の遅延」はキャンペーン機会の損失や社内工数増につながります。逆に、集客が弱い状態では稼働率を上げても成果が伸びません。SLAの指標ごとに「影響するKPI」を1つだけ紐づけておくと、投資判断が速くなります。

限界：SLAだけでは売上や問い合わせは増えない

SLAは運用品質の合意であり、事業成果そのものを保証しません。成果を伸ばすには、目的の具体化、ターゲット設計、伝える内容の整理、導線設計が別途必要です。みやあじよでは「デザインとは問題解決」であり、成果は売上・問い合わせ・採用など目的に紐づくと定義しています。
また、クライアントが「やりたいけどわからないこと」を言語化し、ページ全体のストーリーとして伝わる構成にすることが重要という考え方もあります。
SLAは、その“伝える設計”が継続して機能するための土台として位置づけると、投資判断がぶれにくくなります。

リスクとトラブル予防：ペナルティ、例外、エスカレーション、変更管理

ペナルティ＝SLA未達時に、料金減額などの不利益をあらかじめ定める条項です。ペナルティは「強くするほど良い」ではなく、測定できる前提と例外条件が揃って初めて抑止力になります。

ペナルティは「SLAクレジット」で設計すると運用に載る

SLAクレジット＝SLA未達時に、一定額を月額費用から控除する仕組みです。損害賠償より運用に落とし込みやすく、金額上限（キャップ＝補償額の上限）も設定しやすいのが利点です。

例外条件を先に決め、境界で揉めない

最低限、次の線引きを文章化します。

• 計画停止：メンテナンス通知の期限と、対象外時間の扱い
• 第三者要因：外部サービス障害・通信障害の扱い（連絡と迂回策の範囲）
• 依頼側要因：素材未提出、承認遅延、権限不足などで遅れる場合
• 夜間休日：オンコール＝夜間休日も緊急連絡に備えた待機体制を含むか

障害対応は「初動・復旧・報告」を分けて合意する

• 初動：受付後、切り分け開始までの時間
• 復旧：サービス再開までの目標（重大度別）
• 報告：原因、影響範囲、再発防止を所定フォーマットで提出

変更管理は「小改修の範囲」と「優先度」で固定する

• 小改修の定義：対象作業、月内上限、範囲外例
• 優先度の決定：事業影響を基準に、着手順と例外をルール化
  ここが固まるほど、追加費用と納期の納得感が上がります。

体制：依頼側とベンダーの役割分担、会議体、レポート、改善サイクル

会議体＝定例会議など、意思決定と情報共有の場を設計することです。SLAを機能させるには、数値より「回し方」を先に固定します。

依頼側が持つべき役割（最小セット）

• 事業責任：目的と優先順位を決める（問い合わせ・採用など）
• 運用責任：更新判断、素材提供、承認期限を管理する
• 技術窓口：環境・権限・セキュリティ方針を確認する（兼務でも可）

定例は「事実→判断→次アクション」で型化する

• 事実：件数、平均、未達理由（重要指標に絞る）
• 判断：優先度の見直し、SLA目標値の調整、改善テーマ採否
• 次アクション：担当・期限・完了条件
  みやあじよは成果を「売上・問い合わせ・採用」など目的に紐づけ、デザインを問題解決と捉えています。この前提に立つと、SLAレポートも「数字の報告」ではなく、目的達成に必要な改善へつなげやすくなります。

レポートは「経営向け要約」と「実務向け詳細」に分ける

経営向けは重要導線の停止や重大障害など、判断に直結する指標だけに絞ります。実務向けは対応履歴と再発防止を残し、引き継ぎ可能な資産にします。

ベンダー選定・乗り換え時の評価チェックリスト（比較観点と見落とし防止）

ベンダー変更は価格だけで決めると、移行トラブルや品質低下が起きやすくなります。SLAを軸に「体制」「測定できる運用」「資産の引き継ぎ」を比較します。

観点	確認ポイント	依頼側の準備物	判断の目安
体制	責任者・窓口・バックアップ体制が明確か	社内の窓口と承認者の整理	担当交代でも品質が落ちにくい
SLA	指標・目標値・測定方法が提示されるか	重要導線と営業時間の定義	「測れるSLA」を前提に提案できる
運用設計	定例、チケット運用、承認フローが設計されるか	現行フローとボトルネック	回し方まで提案に含まれる
セキュリティ	更新・権限・バックアップ方針が文書化されるか	社内ポリシーと権限一覧	方針と報告手順がセット
資産管理	ソース、設定、手順書の引き継ぎ範囲	現行の契約と納品物一覧	乗り換え前提でも情報が残る
見積	範囲外、追加費用条件、前提が明記されるか	要件の優先順位と対象外	比較できる内訳がある

乗り換え時は「移行期間のSLA」を別立てで合意する

移行中は旧環境と新環境が混在し、責任分界がぶれやすい局面です。窓口、緊急連絡、作業時間帯、リリース手順だけでも短く合意すると、想定外の遅延を減らせます。

みやあじよは、クライアントの「やりたいけどわからないこと」を言語化し、初見で伝わるストーリーに落とし込むことを重視しています。
ベンダー選定でも同様に、要件と優先順位を言語化できるほど比較の精度が上がります。

まとめ

• SLAは運用品質を指標で合意し、ベンダーコントロールを再現性ある形にするための枠組み
• 重要導線から対象を絞り、重大度・例外条件・測定方法を先に固めると投資判断がぶれにくい
• ペナルティはSLAクレジット等で運用に載せ、変更管理と会議体をセットで設計すると揉めにくい
• 乗り換えや選定は、SLAを軸に体制・運用設計・資産引き継ぎを比較する

要件定義の整理、SLA草案の作成、ベンダー比較表の整備、運用設計まで一気通貫で整えると、意思決定が速くなり、移行後の運用も安定しやすくなります。

株式会社みやあじよでは、要件定義支援からWeb制作・リニューアル、PM支援、運用設計までを一貫して整理し、SLAと運用ルールを“回る形”に整備する支援を行っています。