4.1 サービスレベルの定義と計測の重要性

4.1.1 利用者視点でのサービス品質評価の必要性

システム運用の目標は、システムを単に稼働させることではなく、利用者の要求を満たし、期待される価値を継続的に提供することである。

例えば、オンライン申請システムにおいて、システムが稼働していても以下のような状況では、利用者の要求を満たしているとは言えない。

• 申請手順の解説ページの表示に長時間かかる。
• 適切な申請内容であるにもかかわらず、システム側の問題により申請が完了しない。

このような状況を避けるためには、「システムが利用者の要求を満たしていること」を定量的に評価する運用が必要となる。本ガイドでは、この評価の基準としての目標を「サービスレベル」として定義し、その定義方法を「4.2 サービスレベルの定義」で、計測・監視方法を「4.3 サービスレベルの計測と監視」で、継続的改善の進め方を「4.4 継続的な改善活動」で説明する。

4.1.2 サービスレベルとは

前節で述べた「利用者の要求を満たしていることを定量的に評価する運用」として、本ガイドでは「サービスレベル」を説明する。サービスレベルとは、「組織やサービスが利用者に提供する価値を定量的に表現した目標水準の体系」を指す。

例えば、「国民がオンラインで行政手続きを便利に利用できるようにする」という組織目標があるとする。この目標を実現するためには、「オンライン申請率80%」といった組織レベルの成果指標だけでなく、「申請処理が99%成功する」「画面表示が2秒以内で完了する」といったシステムの技術的な目標値など、複数の層にわたる指標が必要となる。

本ガイドでは、このような組織の目標から具体的な計測方法まで、3つの階層で整理された指標のセットをサービスレベルとする。

• KPI（重要業績評価指標）
  • 組織やサービスの目標達成度を測る最上位の指標。例えば「オンライン申請率」「利用者満足度」「処理完了日数」など、ビジネス価値や政策目標に直結する指標。
• SLO（サービスレベル目標）
  • KPIを達成するために、システムが満たすべき具体的な技術的目標値。例えば「申請処理の成功率が99%以上」「応答時間2秒以内の割合が95%以上」など、計測可能な定量的指標。
• SLI（サービスレベル指標）
  • SLOの達成状況を計測するための具体的な測定指標。例えば「HTTP 5XXエラー数 / 全リクエスト数」「2秒以内レスポンス件数 / 全成功リクエスト件数」など。

これらは相互に関連し、KPIという組織目標を達成するためにSLOを設定し、その達成状況をSLIで継続的に計測するという構造を持つ。

4.1.3 利用者視点でのSLOとSLI設定の重要性

サービスやシステムのSLOとSLIを設定する際は、利用者の体験に直結する指標を重視すべきである。つまり、CPU利用率やメモリ利用率などのシステムリソースの状態ではなく、利用者からのアクセスにおけるレスポンス時間やエラー率など、実際のサービス利用における体験品質を測定・評価する指標を定義することが重要となる。

• SLIの定義例
  • ページロード時間が2秒以内であるリクエスト数の割合
  • API応答時間が200ミリ秒以内であるリクエスト数の割合
  • 利用者が実行した操作が正常に完了した割合
• SLOの設定例
  • ページロード時間が2秒以内であるリクエスト数の割合が95%以上であること。
  • API応答時間が200ミリ秒以内であるリクエスト数の割合が99%以上であること。
  • 利用者が実行した操作が正常に完了した割合が99.9%以上であること。

このように利用者視点での指標を重視する根本的な理由は、サービスやシステムの信頼性が「利用者が使いたいサービスを使いたい時に使え、操作した時に期待通りの動作をすること」にあるためである。例えば、CPU使用率が50%と低い場合でも、利用者からの要求に対する応答が遅延する可能性があり、逆にCPU使用率が高い状況でも適切な応答性能が維持できる可能性がある。つまり、これらのシステムリソース指標は、必ずしも利用者が体験するサービス品質と直接的な相関関係を持たないことがあるため、レスポンス時間やエラー率といった利用者の体験に直結する指標を測定・評価することが重要である。

4.1.4 サービスレベルに基づいた継続的改善の必要性

予測困難な障害などでサービスレベルが目標値を下回る状況が発生した際には、責任を追及するのではなく、サービスレベルの維持・向上に向けたメカニズムの検討に注力すべきである。

ここでいう「メカニズム」とは、人による24時間365日の監視体制や、人手によるチェック・監査プロセスの追加といった、人的リソースに依存する不完全な対策ではなく、問題の自動検知・対応や、作業の自動化によってヒューマンエラーを根本的に防ぐプロセス改善など、本質的な対策を指す。例えば、問題の自動検知には以下のような仕組みが考えられる。

• システムの異常を示す閾値を事前に定義
• 閾値超過時にアラートを自動発報
• 事前定義された手順に従った自動復旧の実施

なお、障害対応の自動化に関する具体的な実装方法については、「3.6 障害対応の自動化とリモート化」を参照のこと。

4.2 サービスレベルの定義

本節では、サービスレベルを定義するための考え方と進め方について説明を行う。

4.2.1 サービスレベル決定の2つのアプローチ

サービスレベルを決定するためのアプローチとして、組織やサービスの戦略的目的から出発するトップダウンアプローチと、利用者の体験の向上を出発点とするボトムアップアプローチの２つがあると考える。本ガイドでは、サービスレベル決定の際に、この2つのアプローチを組み合わせることを推奨する。

理由としては、両アプローチを組み合わせることで、組織目標と利用者の体験の両方に整合したサービスレベルを定義できるからである。特に重要なのは、設定したSLOがKPI達成にどの程度貢献するかという整合性を明確にすることである。すべてのSLOがKPIと直接関連している必要はないが、整合性が確保されている場合は、SLO設定の明確な根拠となり、複数のSLOの優先順位付けに活用できる。

トップダウンアプローチ（組織やサービスの戦略的目的起点）

組織やサービスの戦略的目標から出発し、それを実現するために必要なSLOを導出する方法である。このアプローチにより、システム改善の取り組みが組織目標の達成に確実に貢献することができる。

具体的内容は、「4.2.2 トップダウンアプローチの具体例」を参照のこと。

ボトムアップアプローチ（利用者の体験起点）

利用者がシステムを利用する際の具体的な操作の流れ（クリティカルユーザージャーニー: CUJ）を分析し、利用者の要求を直接反映したSLOを設定する方法である。このアプローチにより、実際の利用者の体験に即した指標設定が可能となる。

具体的内容は、「4.2.3 ボトムアップアプローチの具体例」を参照のこと。

4.2.2 トップダウンアプローチの具体例

トップダウンアプローチの具体例として、組織やプロジェクトの目標（KGI/KPI）からサービスレベルを導出する方法を説明する。

組織/事業/プロジェクトの目標設定には、KPIツリーやOKRなど様々なフレームワークが存在し、所属する組織により採用されるフレームワークやフレームワークの活用方法は異なる。そのため、各組織のガイドに従い目標設定を行うことが求められる。

例えば、政府情報システム向けでは、デジタル庁の「デジタル社会推進標準ガイドライン」の「DS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック」にて、以下の階層的な目標設定手法が示されている。

デジタル社会推進標準ガイドライン
https://www.digital.go.jp/resources/standard_guidelinesopen_in_newOpens in new tab

• KGI（Key Goal Indicator：重要目標達成指標）
• CSF（Critical Success Factor：重要成功要因）
• KPI（Key Performance Indicator：重要成果指標）

これらの目標の策定方法や、各指標の関係性の詳細については、上記ガイドラインを参照されたい。本ガイドでは、これらの目標体系を前提として、システムの品質目標（SLO）との関係性を説明する。

KGI/CFS/KPIとSLOは、相互に補完する関係であったり、組織/事業/プロジェクトの目標値を達成するための部分的要素として機能する場合など、状況により異なる関係性を持つ。

図4-1は、KGI/CSF/KPIとSLOの関係性を示している。

図 4-1 組織/事業/プロジェクトの目標値とサービス/システムの品質目標値の関係性

図に示す通り、KGI/CFS/KPIとSLOは、相互に補完する関係であったり、組織/事業/プロジェクトの目標値を達成するための部分的要素として機能する場合など、状況により異なる関係性を持つ。

「デジタル社会推進標準ガイドライン」で説明しているKGI/CSF/KPIを活用した目標策定の場合は、トップダウン志向の策定プロセスとなる。よってKGIからCSFを経てKPIとハイレベルな目標から個別の目標にブレイクダウンされ、策定されたKPIの内容に基づき、サービスやシステムの品質目標値が決定される、またはKPIの一部としてサービスやシステムの品質目標値が設定されることになる。

4.2.3 ボトムアップアプローチの具体例

ボトムアップアプローチの具体例として、利用者がシステムを利用する際の具体的な操作の流れ（クリティカルユーザージャーニー: CUJ）を分析し、利用者の要求を直接反映したSLOを設定する方法を説明する。

クリティカルユーザージャーニーとは、「あるサービスやシステムにおいて利用者が達成しようとする最も重要で核となるタスクや目標に至る一連の体験」を示す。これを行政機関のサービスやシステムに当てはめると、国民や職員などの利用者が求める主要な目的（例: 補助金の申請、証明書の取得、業務データの確認など）を達成するための操作の流れを指す。

以下では、利用者がインターネット経由で申請を行い、担当職員がその申請内容を審査を行う「電子申請・審査システム」を例に、クリティカルユーザージャーニー抽出・分析し、そこからSLI・SLO・KPIを決定するボトムアップアプローチを説明する。

ステップ1: クリティカルユーザージャーニー（CUJ）の抽出と分析

まず、利用者がシステムを通じて達成したい重要なタスクを特定し、その操作の流れを明確にする。CUJを抽出する際は、以下のアプローチを組み合わせて実施すると効果的に抽出できる。

• 利用者インタビューやアンケート調査: 実際の利用者（または想定利用者）に対して、システムで何を達成したいか、どのような操作を行うかをヒアリングする。
• 既存システムのアクセスログ分析: 既存システムがある場合、アクセスログやユーザー行動データを分析し、利用頻度の高い操作パターンを特定する。
• 業務フロー分析: 業務プロセス全体を俯瞰し、システムが担うべき重要な役割や、利用者が頻繁に実行する業務タスクを洗い出す。
• 関係者（事業部門、運用担当者等）とのワークショップ: システムを熟知した関係者と議論し、利用者にとって最も重要なタスクについて合意形成を行う。

これらの方法により、利用者の実際のニーズや行動パターンに基づいたCUJを抽出することができる。表4-1に、電子申請・審査システムの「申請の提出」における申請者のCUJの例を示す。

表 4-1 電子申請・審査システムの「申請の提出」におけるCUJの例

CUJを抽出する際には、以下の点に留意する。

• 操作の流れが明確であること: 開始から終了までのステップが具体的に定義できること。
• 成功/失敗が判定できること: 利用者の目的が達成されたか否かを客観的に測定できること。
• 段階的な拡張: 最初から多くのCUJを抽出せずに、1〜2件の重要なCUJから始め、運用の習熟度に応じて段階的に拡張することが望ましい。

ステップ2: 利用者の要求の特定とSLIの定義

CUJを抽出した後は、各CUJにおける利用者の具体的な要求を特定し、その要求を定量的に測定するためのSLIを定義する。表4-2に、「申請の提出」のCUJにおける利用者の要求とSLIの対応例を示す。

表 4-2 電子申請・審査システムの「申請の提出」におけるSLIの例

この例では、利用者が「スピーディに申請内容を送信したい」という要求を持っている場合には、送信処理のレスポンスタイムがSLIとなる。また、「確実に申請内容を送信したい」という要求がある場合には、送信時のエラー率がSLIとなる。

SLIを定義する際には、利用者の具体的な要求に対応し、かつ継続的に計測可能な指標を選択することが重要である。

ステップ3: SLOの目標値設定

SLIが定義されたら、次にそれぞれのSLIに対する目標値を設定することで、SLOの定義が完成する。目標値の設定においては、以下の2つの観点のバランスを考慮することが求められる:

① 利用者の要求を満たせるか（利用者視点）

• 設定した目標値が利用者の期待に応えられるレベルであるか。
• 利用者の要求を下回る目標値を設定した場合、本来の目的である利用者の要求を満たすことが疎かになる可能性がある。

② 現実的に達成できるか（実現可能性）

• システム構成や運用体制、コストの観点から実現可能な目標値であるか。
• 過度に高い目標値を設定した場合、システム構成や運用コストに大きな影響を与えることがある。
  • 例: 可用性を99.9%から99.99%に向上させる際には、冗長化レベルの大幅な見直しや監視・運用体制の強化が必要となる。

目標値の設定は、これら両者のバランスを考慮し、段階的に調整していくことが現実的である。初期段階では達成可能性を重視した目標値から始め、運用の成熟度や改善の進捗に応じて、より利用者の要求に近い水準へと段階的に引き上げていく方法が推奨される。

ステップ4: KPIとの整合性確認

ボトムアップアプローチでCUJから導出したSLOは、利用者の体験の向上に直結する指標として有効であるが、同時に組織/事業/プロジェクトのKPIとの整合性を確認することも重要である。

具体的には、「設定したSLOを達成すると、どのKPIがどの程度向上するか」について明確にし、SLOとKPIの整合性を確認しておくべきである。

例えば、表4-2で示した「申請の提出」に関するSLOが、以下のようなKPIにどう貢献するかを検討する:

• 「オンライン申請率」というKPIに対して
  • 申請送信のエラー率を低減することで、利用者がオンライン申請を選択しやすくなる。
  • レスポンスタイムを改善することで、利用者満足度が向上し、継続利用が促進される。
• 「申請処理の効率性」というKPIに対して
  • システムの安定性向上により、職員の手作業によるエラー対応が削減される。

このように、SLOとKPIの関係性を明確にすることで、以下のメリットが得られる:

• SLO設定の明確な根拠となる。
• 複数のSLOの優先順位付けに活用できる。
• システム改善の取り組みが組織目標達成に貢献していることを関係者に説明できる。

すべてのSLOがKPIと直接関連している必要はないが、可能な限り整合性を確保することで、ボトムアップアプローチとトップダウンアプローチの両面からバランスの取れたサービスレベルの定義が実現できる。

4.2.4 SLOとSLI定義の段階的な追加

SLOとSLI定義の数について

利用者の視点にてSLOとSLIを定義した場合、その定義数はシステムで一つとは限らない。

例えば、「4.2.3 ボトムアップアプローチの具体例」で例として出した「電子申請・審査システム」ではシステムとして利用者の利用において重要な機能が、（1）申請の提出、（2）ステータス確認、（3）問い合わせ、の３種類がある。またそれぞれの機能について観測点が一つとは限らず、例えば（a）レスポンスタイムと（b）エラー率の２つの視点で測定することなどが考えられる。この場合、SLOとSLIの定義は、6種類（3機能 x 2つの視点）が必要となる。

SLOとSLI定義の段階的な追加

このようにSLOとSLIの定義は、システムで複数定義を行うことが必要になるが、システムの本番開始時点で、重要となるSLOとSLIの定義を網羅的に定義しようとする行為は現実的ではない。SLOとSLIの定義は、運用開始の時点では優先順位が高いものを最小限の範囲で定義し、運用状況を見ながら段階的に追加することが望ましい。

理由としては、サービス開始前の段階では不明点や不確定要素も多く、妥当な基準値を定めることは難しいからである。その状況で網羅的にSLOとSLIを策定しても、実態にそぐわない指標が含まれるリスクがある。また「2.1.2 インシデント対応の重要性」にて、システムの設計・構築・テストで完全なシステム品質を作り込む行為は、コストの指数関数的な増加をもたらす非現実的なアプローチであることに言及しているが、SLOとSLIの定義もここに含まれる。

SLOとSLI定義の絞り込み方

SLOとSLIの定義は、開発または運用プロセスの中で関係者が合意し、その達成に向けた活動を継続的に行うものである。そのため、一度関係者で合意し定義した指標は、不要となった場合でも削除することが難しい傾向がある。結果として、保守運用の負担が増大するリスクが生じる。

そのため、運用開始の時点では以下の3つの基準をもとに定義数を絞り込むことが必要である。

• 基準A. 利用者の体験への直接影響が高いこと。
• 基準B. 測定が容易で既存基盤で取得可能なこと。
• 基準C. サービス品質への影響が定量化できること。

図 4-2 SLOとSLI定義に関する基準

例えば、リクエスト数に対するエラーの発生率には多数の対象や計測方法があるが、上記の基準をもとに以下のように絞り込みを行う。

• 基準A. 利用者からのリクエスト（フロント処理）に対するサーバーエラーレスポンス （5XX）（利用者操作ミスではなく、サーバー側起因で発生する可能性の高いもの）
• 基準B. CSP提供のメトリクスまたは容易に拡張可能なメトリクス（精密さを求めるための過度な作り込みはしない）
• 基準C. 利用者がホーム画面で必ず操作するメインの処理（全ての処理ではなく特定処理に絞り込む）

上記で定義したSLOとSLIの具体的な計測方法として、ロードバランサーから送信されるHTTP 5XX エラーの数からエラー発生率を計算する方法が考えられる。

4.2.5 SLIの定義例

システムの処理方式に応じたSLIの定義例を紹介する。「システムが利用者の要求を満たしていること」を正確に評価するために、処理方式の特性を考慮したSLIを定義する方法がある。本節では、以下の2つの処理方式に基づくSLIの定義例を示す。1つのシステムが複数の処理方式で構成される場合には、それぞれの処理方式に適したSLIを検討することが望ましい。

• オンライン処理
  • 利用者からのリクエストを受信し、即座に処理してレスポンスを返す一連の処理を行う方式
  • 処理の例: 申請データの受付、申請状況の照会、申請履歴の検索
• 非同期処理
  • 特定の処理をトリガーとして実行される関連処理や、スケジュールに基づく自動実行など、即座にレスポンスを返さない処理を行う方式
  • 処理の例: 申請データの審査システム連携、申請結果通知メールの送信、申請統計データの日次集計

なお、SLOについては、各システムの要件や利用者の要求に応じて個別に、目標値を検討・設定する必要があるため、ここでは具体的な数値例は示さない。本節のSLI定義例も参考に、システムに適したSLOを検討いただきたい。

オンライン処理の場合

表4-3に、オンライン処理の場合のSLIの定義例を示す。オンライン処理は、利用者からのリクエストに対して即座に処理してレスポンスを返す処理方式である。このため、成功した処理の割合や、処理が終わるまで時間など、利用者が直接体感する指標をSLIとすることが有効である。

表 4-3 オンライン処理の場合のSLI定義例

非同期処理の場合

表4-4に、非同期処理の場合のSLIの定義例を示す。非同期処理は、特定の処理やスケジュール実行をトリガーとして、データを継続的または定期的に処理・変換する処理方式である。このため、一定時間以内に更新されたデータの割合や、予定したデータのうち処理が完了したデータの割合など、処理が滞りなく実行されているかに関する指標をSLIとすることが有効である。

表 4-4 非同期処理の場合のSLI定義例

4.2.6 稼働率の水準の設定

SLOの定義の重要項目の1つである稼働率を設定する場合は、その設定を行う上で注意が必要である。稼働率は従来のシステム運用においてもサービスレベルの指標に用いられることが多く、非IT技術者でも馴染みがある指標である。そのため、使用するCSPサービスやアーキテクチャから想定される範囲を考慮せずに、イメージを基に稼働率に対する目標値を設定するケースがある。その結果として、システム化して得られる価値や、停止した場合の損失と比べ、過大にコストをかけたシステム構成や運用が発生してしまう場合がある。また、無理な目標値を達成するために、稼働率の例外となる条件を設定する、インシデントを隠蔽するといった品質低下につながるリスクがある。

このことから、各々のシステムにより基準は変わるが、過剰に高い目標値を設定するべきではなく、停止時影響の許容度および、コストと稼働率が釣り合う点を起点に、目標値を定めるべきである。

参考として、政府情報システム向けにデジタル庁で発出しているデジタル社会推進標準ガイドラインの「DS-100 デジタル・ガバメント推進標準ガイドライン」の「別紙5 システムプロファイルに係る定義について」に記載のあるシステムのプロファイルに基づく稼働率の目標値の例を参照いただきたい。

• 別紙5 システムプロファイルに係る定義について
  https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/d4e68a9b/20250619_resources_standard_guidelines_guideline_01.pdfopen_in_newOpens in new tab

4.3 サービスレベルの計測と監視

本節では、定義したサービスレベルに対する計測と監視方法について説明する。

4.3.1 SLIとSLOの計測

利用システムの品質状況を正確に把握するため、SLIのリアルタイム計測は不可欠な要素である。この実現には、システムから必要なデータを継続的に収集し、収集したデータに基づきレスポンスタイム、エラー発生率、利用者のアクションの成功率といったSLIを計測するための仕組みが必要となる。データの収集方法としては、以下の方法が挙げられる。

• アプリケーションの性能を監視するAPM（Application Performance Monitoring）ツールを使用して、Webアプリケーションや各種APIのレスポンスタイム、エラー回数を自動収集する。
• CSPが提供するロードバランサーなどのリソースから送信される標準的なメトリクスを自動収集する。
• 外形監視ツールを使用して、ネットワークの外部から実際の利用者と同様の方法でWebアプリケーションにアクセスを行い、HTTPステータスコードやエラー回数を自動収集する。

これらのツールから収集されたデータを基に、SLIを計測する。例えば、「API応答時間が200ミリ秒以内であるリクエスト数の割合」をSLIとして設定する場合、計算値は「200ミリ秒以内に応答したリクエスト数 / 全リクエスト数」となる。なお、SLOとして評価する場合には、過去1時間や過去30日間などの集計対象期間に基づく計算が必要となる。

計測データの信頼性向上

SLIのデータは継続的かつ欠けることなく収集することが理想であるが、システム障害やメンテナンスなどの要因により、一時的なデータ欠損が発生する可能性がある。このような状況に対処するため、SLIとして使用するデータに欠損が生じた場合の振る舞いを柔軟に選択できる仕組みを用意する。データ欠損期間を正常稼働時間または異常時間のいずれで扱うか、またはSLOの計算対象から除外するかを利用システムの要件に応じて設定可能とすることで、信頼性の高いモニタリングが実現できる。これにより、過剰なアラート発生による運用負荷の軽減が期待できる。

集計期間の柔軟な調整

短期的な異常検知から長期的なトレンド解析に至るまで、多角的に利用システムの品質評価を実現するため、日次、週次、月次など複数の集計期間におけるSLOの集計機能を用意することが重要となる。これにより、特定期間中におけるサービス品質の分析や季節変動の影響など、多角的な観点からサービス品質を評価し、効果的なシステムの改善施策を検討することが可能となる。

ばらつきが大きい指標の計測

国民からのインターネット経由のアクセス時のページロード時間の計測など、さまざまなクライアント環境やネットワーク環境があり不確定要素が多く含まれ、ばらつきが大きい指標の場合は、90パーセンタイルまたは95パーセンタイルでの評価が適している。例えば、SLIを「ページロード時間が2秒以内であるリクエスト数の割合」から「リクエストの90パーセンタイルのページロード時間が2秒以内」に変更することで、大多数の利用者が実際に体験する性能レベルを把握でき、外れ値による影響を排除した現実的な評価が可能となる。

上記の要件を満たす計測の仕組みの構築においては、CSPが提供するマネージドサービスを活用することが望ましい。多くのCSPでは、SLIとSLOの定義から計測、可視化、アラート設定に至る一連の機能を統合的に提供しており、マネージドサービスの活用により効率的な構築が期待できる。

4.3.2 SLIとSLOの可視化

SLIとSLOの効果的なモニタリングには、専用ダッシュボードの構築が望ましい。ダッシュボードを用いてSLIとSLOをリアルタイムで可視化し、閾値超過時のアラート機能を実装することで、SLO違反の兆候を迅速に検知し対応することが可能となる。例えば「ページロード時間が2秒以内であるリクエスト数の割合が95%以上であること」というSLOに対して、「現在の達成率が98.5%である」ことを即座に把握できる。

リアルタイムでの可視化に加えて、日次、週次、月次といった複数の時間軸でSLIとSLOの推移を可視化することで、長期的なトレンド分析を支援する。こうして得られた分析結果を過去の実績と比較することにより、サービス品質の動向把握と改善活動のための洞察を得ることが可能となる。

また、ダッシュボードの導入は、関係者間での情報共有の円滑化を促進し、問題発生時における対応方針の決定を効率化する。さらに、手動での指標収集やレポート作成作業が不要となり、運用担当者の作業負担軽減にも貢献が実現できる。

GCASガイドでは、「定量的計測の実装方法」にてサンプルのダッシュボードを提供している。2025年1月時点で提供しているサンプルダッシュボードを以下に提示する

• AWS : 定量的計測の実装方法(AWS編)open_in_newOpens in new tab
• OCI : 定量的計測の実装方法(OCI編)open_in_newOpens in new tab

具体的内容として、図4-3にAWSのサンプルダッシュボードを提示する。このサンプルのダッシュボードは、申請システムを想定しその上でサービス観点として「ビジネスメトリクス」を、システム観点でレスポンス時間やエラー率などをまとめた「主要システムメトリクス」としてダッシュボードを構成している。

図 4-3 定量的計測の実装方法(AWS編)のサンプルのダッシュボード

4.3.3 アラートの設定

SLOの達成状況は、月次や四半期毎などの中長期単位で評価し、関係者間で定期的な振り返りと改善のサイクルを回しサービス品質の向上に繋げていくことが重要である。しかしながら、利用者に重大な影響を及ぼす問題が発生した場合には、サービスの早期正常化のために迅速に検知し対処することも必要となる。このため、急激なSLIの低下によるSLO未達成の兆候を検知するためのアラート機能を構築する。

具体例として、申請システムにおいて「ページ読み込み時間が2秒以内となるリクエストの割合を95%以上維持する」というSLOを定義した場合、以下のような段階的なアラート条件を設定することで、利用者の体験に悪影響を及ぼす障害の早期発見が可能となる。

• アラート設定例
  • 緊急度中: 過去5分間のページ読み込み時間が2秒以内となるリクエストの割合が90%を下回った場合
  • 緊急度高: 過去5分間のページ読み込み時間が2秒以内となるリクエストの割合が80%を下回った場合

このような緊急度別のアラート設定により、問題の重要度に応じた対応が可能となり、効率的な運用を実現できる。

一方、SLOの中長期的な推移については、アラートではなくダッシュボードを活用した継続的な監視を行う。ダッシュボードではSLOの達成状況を可視化し、定期的な振り返りとシステムの改善に活用する。このような役割分担により、緊急対応と中長期的なシステム改善の両方を効率的に実現する。

4.4 継続的な改善活動

4.4.1 継続的な改善の重要性

SLOは単なる監視項目に留まらず、利用者の視点に立ったサービス品質向上を実現するための重要な指標として機能する。したがって、その達成状況を継続的に評価し、改善サイクルを回すことが重要である。

継続的な改善には、大きく分けて以下の2つの軸がある：

1. SLOとSLIに基づいたシステムの改善：設定されたSLOを達成するために、システムやプロセスを改善する(4.4.2節 参照)
2. SLO自体の見直し：環境の変化に応じて、SLOの設定自体を見直す（4.4.3節 参照）

本節では、まずSLO自体の見直しの重要性について説明する（システム改善の重要性については4.1.4節で説明）。

SLOの見直しの重要性

SLOは一度設定すれば完了するものではなく、その妥当性を継続的に検証し、環境の変化に応じて適切に見直していく必要がある。以下に、SLO見直しが必要となる主な理由を示す。

• SLOと組織目標の乖離防止
  • SLOがKPIと乖離している状況では、技術的な改善努力が組織目標に反映されず、投資効果が損なわれるリスクが生じる。
• 環境変化への適応
  • サービスの重要性の変化によりKPIが追加・変更される場合や、CSP提供サービスの進化を通じてより安定性の高いシステムが実現できる場合など、SLOに影響を与える要因は継続的に変化する。外部環境の変化に対してSLOが適応できなければ、指標としての有効性を失う。
• 現実的な目標設定の維持
  • 過度に厳しいまたは緩いSLOは、改善活動への意欲低下や品質劣化を招くため、適切なバランスの維持が求められる。

4.4.2 SLOとSLIに基づいたシステムの改善

システムの信頼性向上において、SLOとSLIに基づく改善は利用者の体験の向上を実現するための重要な取り組みとである。定期的な分析と評価を行う改善サイクルの確立により、システム品質の向上を図ることができる。

以下に、この改善サイクルを構成する3つのステップについて詳述する。

• 傾向分析と潜在課題の発見
  • 月次や四半期毎といった中長期的な視点でSLOの推移を分析し、繁忙時期における慢性的なレスポンス時間の悪化など、季節性や利用者の行動パターンに起因する潜在的な課題を発見する。さらに、課題の根本原因となるボトルネック箇所を明確化する。
• 改善活動の実施計画策定
  • 発見した課題から取り組むべきアクションを洗い出し、SLOへの影響度、発生頻度、対策に必要な工数を評価基準として各アクションの優先順位を決定し、システム改善の計画を策定する。アクションの検討においては、人的リソースに依存しない自動化機能の導入を検討し、システム品質の向上を図る。
• 改善効果の継続的評価
  • 実施したアクションの効果を月次や四半期単位で評価し、その評価結果を次回の改善計画にフィードバックする。定量的な評価においては、SLO達成状況（例:90%→95%）、インシデント発生件数（例:15件→8件）、平均復旧時間（例:4時間→2時間）といった指標の変化を追跡する。加えて、手作業から自動化への移行度合いや監視アラートの精度向上などの定性的な改善効果についても評価し、多角的な観点から施策の有効性を判断する。

4.4.3 SLOの改善

SLOは、KPIを達成するための実績指標として機能しているかという観点で、その妥当性と整合性を継続的に評価し、見直しサイクルを回すことが重要である。以下の観点から評価と改善を実施する。

SLOの妥当性の評価

• クリティカルユーザージャーニー（CUJ）に基づき設定したSLOとKPI達成率の相関を分析し、SLOがKPI達成の根拠となる指標として適切に機能しているかを評価する。
• 評価の観点では、SLOの達成状況と、利用者からのフィードバックによるサービスに対する定性的評価を組み合わせることで、SLOが実際の利用者の体験を適切に反映しているかということを重視する。例えばSLOを達成している場合でも、利用者からのフィードバックで満足度が低い結果となった場合には、SLOと利用者の体験が乖離していると考えられ、さらに適切なSLIを定義することや、SLOの変更が必要となる可能性がある。

SLOの整合性の評価

• 中長期単位で実施されるKPIの追加や変更に対して、SLOに適切に反映されているかを検証する。サービスの重要性やCSP提供サービスの進化などの外部の変化に伴い、重要視される指標が変化する場合があるため、定期的な整合性確認が必要である。
• 新機能の追加や既存機能の改修に伴うSLOの更新要否を確認し、システムアーキテクチャの変更がSLO設定に与える影響を評価する。例えば、マイクロサービスアーキテクチャやサーバーレス環境への移行といった技術的変更により、従来のSLO指標では適切な評価ができない場合があるため、アーキテクチャに適した指標への見直しを行う。
• 過度に厳しいSLOは現実的な値に調整し、達成可能な改善計画を策定することで、システムの運用に関わる関係者間の信頼関係確立と継続的改善の両立を図る。CSPが提供するコスト可視化ツールなどを活用し、SLO達成に必要なリソースとコストのバランスを考慮した現実的な目標設定を行う。

SLOの見直し

見直しプロセスでは、職員・事業者など関係者全体での議論を通じて、バランスの取れたSLO設定を行う。データドリブンな意思決定を支援するため、ダッシュボードを活用し、SLO達成状況の可視化と共有を行う。SLOの見直し後は効果測定を行い、新しいSLO設定の妥当性を段階的に検証する。

また、SLOの見直しプロセスにおいて、KPIが技術的な制約を考慮せずに設定されている場合など、KPI自体の妥当性に疑問が生じる場合がある。このような状況では、SLOの見直しだけでなく、KPI自体の妥当性についても組織レベルで再検討することが重要である。