第3章 · ProjectVIEW ERP マスターSaaSフレームワーク
ProjectVIEW ERPサービスレベル契約では、Production環境の月間可用性99.9%、復旧時点目標15分、復旧時間目標4時間を約束します。インシデントはP1からP4に分類され、定義済みの応答および復旧（MTTR）目標が設定されています。P1インシデントには即時応答と4時間のMTTR目標が適用され、24×7×365で対応します。また、SLA実績は毎月報告され、四半期ごとにレビューされます。
- 99.9%月間可用性（Production）
- 15分復旧時点目標
- 4時間復旧時間目標
- 4時間P1 MTTR目標、24×7×365
3.1 SLA概要
本項では、プラットフォームの提供およびサポートにおいて、提供者が達成することを約束するサービスレベルを定義します。提供者は、本サービスを提供する際、本項に定めるサービスレベルを満たす、または上回るために商業上合理的な努力を行うものとします。
サービスレベルには、プラットフォーム可用性、インシデント対応、復旧目標、バックアップおよび復旧目標、ならびに不遵守時のサービスクレジットが含まれます。
SLAはプラットフォームのProduction環境にのみ適用されます。商業契約書に別段の定めがない限り、非Production環境（開発、Sandbox／テスト）はSLA測定の対象外です。
3.1 プラットフォーム可用性
3.1.1 サービスレベル目標（SLO）
提供者は、プラットフォームのProduction環境について、対象暦月の総分数に対する割合として測定される月間稼働率99.9%のサービスレベル目標を約束します。
| 指標 | 目標 | 測定期間 |
|---|---|---|
| サービスレベル目標（SLO） | 99.9% | 暦月 |
| 許容最大停止時間 | 43.2分／月 | 算出式: (1 – 0.999) × 43,200 分 |
3.1.2 可用性算定
月間可用性は以下の式で算出されます。
可用性 % = ((総分数 – 停止分数) / 総分数) × 100
以下のとおりです。
- 総分数 = 対象暦月の総分数
- 停止分数 = Production環境が利用不能となった総分数。ただし、計画保守および除外事象は除きます
3.1.3 計画保守
提供者は、事前に合意した保守時間帯において計画保守を実施するものとします。計画保守は、以下を条件として可用性算定から除外されます。
- (a) 提供者が、計画保守について、お客様に少なくとも5営業日前の書面による通知を行うこと。
- (b) 保守は、別途合意がない限り、オフピーク時間帯（お客様の主要拠点の現地時間22:00から06:00の間）に予定されること。
- (c) 月間の計画保守時間の合計が暦月あたり4時間を超えないこと。
- (d) 提供者が、各保守時間帯の期間および影響を最小化するために商業上合理的な努力を行うこと。緊急保守: 重大なセキュリティ脆弱性または差し迫ったシステム障害が発生した場合、提供者は5営業日未満の通知で緊急保守を実施できるものとします。提供者は、合理的に実行可能な限り速やかにお客様へ通知し、保守後2営業日以内に保守報告書を提供するものとします。
3.2 環境ライフサイクル
導入期間中、提供者はお客様向けに2つの別個の環境を用意します。
| フェーズ | 環境 | 目的 |
|---|---|---|
| 導入 | 開発／Sandbox | 設定、カスタマイズ、データ移行、統合テスト、およびUniversal User Acceptance Testing（UAT）。お客様と提供者は、Go-Live前にすべての機能要件を共同で検証します。 |
| 導入 | Production | すべての認可ユーザー向けの本番運用環境。本項3で定義する完全なSLA指標の対象となります。 |
3.2.1 Go-Live後の環境移行
Go-Live後、環境構成は以下のとおり移行します。
| 環境 | Go-Live後の役割 | 目的 |
|---|---|---|
| 開発／Sandbox | Staging Environment | 次の用途に使用される恒久的なStaging環境になります。デバッグおよび障害再現、変更要求および機能拡張の開発、ソフトウェア更新およびパッチテスト、ならびにProductionへの展開前のUniversal User Acceptance Testing（UAT）。 |
| 生産 | Production環境 | 本番運用環境として継続します。Staging環境での事前検証およびUAT承認なしに、Productionへ変更を展開することはありません。 |
Universal User Acceptance Testing（UAT）: すべてのソフトウェア変更、パッチ、更新、および新機能リリースは、Productionへ展開する前にStaging環境でUATを通過しなければなりません。お客様にはUATを完了するために最低5営業日が付与され、Productionへの展開にはお客様の書面による承認が必要です。提供者は、Section 3.1.3で定義する緊急保守の場合を除き、確認済みのUAT承認なしにProduction環境へいかなる変更も展開しません。
提供者は、UAT結果がProductionの挙動を代表するものとなるよう、StagingとProductionの環境同等性を維持するものとします。両環境は常に同一のソフトウェアバージョン、設定、およびセキュリティポリシーで稼働し、異なるのはデータ内容のみとします。
3.3 回復目標
提供者は、プラットフォームの事業継続および災害復旧（BC/DR）アーキテクチャに整合する、Production環境に対する以下の復旧目標を約束します。
| 指標 | 目標 | 定義 |
|---|---|---|
| 復旧時点目標（RPO） | 15分 | 時間で測定される許容最大データ損失量です。トランザクションログのバックアップは15分ごとに実行され、災害シナリオにおいて失われるデータは15分以内に抑えられます。 |
| 復旧時間目標（RTO） | 4時間 | 許容最大サービス中断時間です。提供者は、災害事象を宣言してから4時間以内にプラットフォームの全機能を復旧するものとします。 |
これらの復旧目標は、以下のバックアップアーキテクチャによって支えられます。
| バックアップ種別 | 頻度 | 保持期間 | 暗号化 |
|---|---|---|---|
| トランザクションログのバックアップ | 15分ごと | 7日 | 保存時AES-256 |
| データベース完全バックアップ | 12時間ごと | 30日 | 保存時AES-256 |
| 増分ファイルバックアップ | 毎日 | 30日 | 保存時AES-256 |
| 週次完全バックアップ | 週次（日曜日） | 90日 | 保存時AES-256 |
| 月次アーカイブバックアップ | 月次（1日） | 12か月 | 保存時AES-256 |
すべてのバックアップは、お客様が指定したAzureリージョン内の地理的冗長Azureストレージに保存され、商業契約書に定めるとおり、リージョン間レプリケーションをオプションで利用できます。バックアップの整合性は、四半期ごとに実施される自動復元テストによって検証されます。
Azure Backupの概要: https://azure.microsoft.com/en-us/products/backup
3.4 インシデント優先度区分
Provider Service Desk（PSD）に報告されたすべてのインシデントは、以下の優先度レベルに従って分類されます。
| 優先度 | 重大度 | 定義 | 例 |
|---|---|---|---|
| P1 | 重大 | すべて、または実質的にすべての認可ユーザーに影響する、システム全停止または重要な業務機能の障害。データ整合性にリスクあり。 | Productionサーバー停止、重大なデータベース破損、プラットフォームへの完全なアクセス不能、データ損失事象。 |
| P2 | 緊急 | 重要な業務機能の著しい低下。システムは稼働しているが、機能は著しく制限されている。主要機能が利用不可。 | 主要モジュールが機能しない（例: Cost Control）、深刻な性能低下、重要な統合障害。 |
| P3 | 大 | 非重要機能の障害、または中核業務を妨げない性能低下。合理的な回避策が存在する。 | レポート生成失敗、非重要モジュールの問題、使い勝手に影響する外観上の不具合、軽微な統合障害。 |
| P4 | 軽微 | 外観上の問題、情報提供依頼、または直ちに運用影響のない機能改善提案。 | UIの配置不具合、文書修正、機能要望、一般的な問い合わせ。 |
優先度分類は、チケット登録時にお客様と提供者の間で相互に合意されたものとします。両当事者が合意できない場合、次回予定されているサービスレビュー会議におけるService Delivery Managerの確認までの間は、お客様の分類が優先されます。
P1およびP2インシデントは、直ちに対応するため、Provider Service Deskへ電話で報告しなければなりません。P3およびP4インシデントは、メール、PSDポータル、または電話で報告できます。
3.5 SLA応答・復旧マトリクス
提供者は、以下のSLAマトリクスに定める目標内でインシデントに対応し、解決するものとします。
| 優先度 | 応答時間 | MTTR目標 | 回避策目標 | 運用時間帯 | GOS目標 |
|---|---|---|---|---|---|
| P1 － 重大 | 即時 | 4時間 | 解決まで継続対応 | 24 × 7 × 365 | 98% |
| P2 － 緊急 | 即時 | 8時間 | 15営業日 | 24 × 7 × 365 | 95% |
| P3 － 大 | 2時間以内 | 12時間 | 20営業日 | 24 × 7 × 365 | 93% |
| P4 － 軽微 | 4時間以内 | 次回リリース | 次回予定リリース | 営業時間 | 90% |
以下のとおりです。
- 応答時間 = PSDによるインシデント受付から、担当エンジニアによる最初の診断アクションまでの時間
- MTTR（平均修復時間） = インシデント受付から完全解決または有効な回避策までの目標経過時間
- 回避策目標 = 恒久修正を待つ間に中核業務機能を復旧させる、一時的解決策を提供するまでの最大経過時間
- GOS（サービス提供率） = 測定期間中に各優先度レベルでMTTR目標内に解決されたインシデントの割合
3.6 SLA除外事項
以下の事象はSLA測定から除外され、停止時間としてもGOS算定にも影響しないものとします。
- (a) 計画保守 : 第3.1.3節で定義される、合意済みの保守時間帯内で実施される事前通知済みの保守
- (b) セキュリティ事象 : プラットフォームおよびお客様データを保護するために適用される、セキュリティ侵害、DDoS攻撃、または緊急セキュリティパッチに起因する停止時間
- (c) 不可抗力 : 第9節で定義される、提供者の合理的支配を超える事象
- (d) お客様起因の遅延 : 適時の情報提供の不履行、承認遅延、または無断変更を含む、第2.8節に基づくお客様の義務不履行に起因する遅延
- (e) 第三者障害 : Microsoft Azureプラットフォームの停止を含め、インターネット接続、DNS、または提供者が直接管理していないその他のサービスの停止
- (f) 承認ライフサイクルの遅延 : お客様の承認ワークフローまたは承認プロセスに起因して、提供者が復旧活動を進められないことによる遅延。Azureプラットフォームの停止が発生した場合、提供者は、Microsoftによる公表後5営業日以内に、関連するMicrosoft Root Cause Analysis（RCA）レポートをお客様に提供するものとします。
Azure Service Health: https://azure.microsoft.com/en-us/features/service-health/ Azure Status: https://status.azure.com/
3.7 SLA不遵守ペナルティ
提供者が本第3節に定めるSLOまたはサービス提供率（GOS）目標を達成できない場合、お客様は提供者から支払われる金銭的ペナルティを受ける権利があります。ペナルティの段階、算定基準、および上限は、各お客様の商業契約書に定めます。概要は以下のとおりです。
- (a) 乖離幅に応じた段階制: ペナルティは、目標に対する不足の大きさに応じて増加します。合意された許容範囲内の軽微な乖離にはペナルティは発生しません。
- (b) 2つの指標: 可用性（SLO）とサービス提供率（GOS）の両方がペナルティ算定に含まれ、可用性の比重がより大きくなります。
- (c) 直接支払い: ペナルティは、請求が確認された後、クレジットノートではなく直接の金銭支払いとして支払われます。四半期上限が適用されます。
- (d) 請求手続: お客様は、違反が発生した月の末日から30日以内に、関連するインシデントと裏付け証拠を添えた書面による請求を提出します。提供者は10営業日以内に請求を確認または異議申立てします。異議はSteering Committeeに付託されます。
- (e) 唯一の金銭的救済: ペナルティは、サービスレベル未達に対するお客様の唯一かつ排他的な金銭的救済です。これは、第7節に基づく重大な契約違反によるFramework解除権を制限するものではありません。
- (f) 除外事項: 第3.6節で定義する除外事象に起因してSLA未達となった場合、ペナルティは支払われません。
3.8 追加ライセンスおよび新規ユーザー
お客様がサブスクリプション期間中に新しい認可ユーザー（追加ライセンス）を追加することを選択した場合、以下の規定が適用されます。
- (a) 同一SLA適用範囲: 本第3項に定めるすべてのサービスレベル、性能目標、回復目標および違約金規定は、追加の認定ユーザーおよびライセンスすべてに対して、利用開始日から同等に適用される。新規ユーザーに対してSLAが縮小されたり段階的に適用されたりすることはない。
- (b) ARR調整: 第3.8節に基づくペナルティ算定に使用されるARRは、有効化日から、該当測定期間の残余について按分により追加ライセンス料金を含めて再計算されます。
- (c) 環境の一貫性: 新規ユーザーは同一のProductionおよびStaging環境にアクセスできます。提供者は、性能または可用性を低下させることなく追加ユーザーを収容できるよう、プラットフォームを拡張するものとします。
- (d) オンボーディングSLA: 事業者は、顧客から完全なライセンス追加申請を受領した後、2営業日以内に、新規ユーザーアカウントを有効化するものとする。これには、役割の割り当て、アクセス権の付与、および初期トレーニング資料が含まれる。
- (e) 容量保証: 提供者は、専用のプライベート主権環境に追加ユーザーを支援するのに十分な余力があること、または必要に応じて事前に拡張されることを保証し、SLO 99.9%またはいかなるGOS目標にも影響を与えません。新規ライセンスの追加手順、価格設定および商業契約書の変更要件を含む詳細は、第6節（料金、請求および支払条件）に定めます。
3.9 SLA報告およびサービスレビュー
3.9.1 月次SLAレポート
お客様からの要請に応じて、提供者は各暦月末から10営業日以内に、お客様へ月次SLA実績レポートを提供できるものとします。レポートには以下を含めるものとします。
- (e) 月次可用性率およびSLO目標に対する比較
- (f) 優先度別のインシデント総件数、ならびに応答時間と解決時間
- (g) 優先度別のGOS達成状況
- (h) バックアップ成功率および失敗したバックアップ事象
- (i) いかなるSLA違反も、根本原因分析および是正措置を含む
- (j) ペナルティ計算（該当する場合）。ARR算定根拠を明示
- (k) 直近3か月との比較によるトレンド分析
3.9.2 四半期サービスレビュー
各当事者は、SLAパフォーマンスを確認し、サービス改善施策を協議し、未解決事項に対処するため、四半期サービスレビュー会議を実施する場合があります。Providerは、各レビュー会議の少なくとも5営業日前までに、Customerが合意した形式で四半期サービスレポートを作成し、提出しなければなりません。四半期レポートには、以下を含めるものとします。
- (l) 四半期を通じたSLAパフォーマンスの集計
- (m) 根本原因分析を含む重大インシデント要約
- (n) サービス改善計画の更新状況および進捗
- (o) 容量およびパフォーマンスのトレンド分析
- (p) 変更管理の要約（適用済みパッチ、更新、リリース）
- (q) 将来を見据えたリスク評価および緩和計画
3.9.3 継続的サービス改善
Providerは、特定した改善機会、合意済み対応、責任者、および目標完了日を記録した継続的サービス改善（CSI）登録簿を維持しなければなりません。CSI登録簿は、各四半期サービスレビューで確認するものとします。
3.10 SLAガバナンス
SLA管理には、以下のガバナンス構造が適用されます。
| 役割 | 責任 | 頻度 |
|---|---|---|
| Service Delivery Manager（Provider） | SLAパフォーマンスに関する主要な責任者。月次SLAレポート、エスカレーション管理、CSI登録簿を管理します。 | 継続的 |
| Account Manager（Provider） | 商取引関係の管理。SLAに関する紛争およびService Credit請求のエスカレーション窓口です。 | 必要に応じて |
| Customer IT Liaison | 日常のサービス管理、インシデント報告、UAT調整におけるCustomerの主要窓口です。 | 継続的 |
| Steering Committee | サービス関係の戦略的レビュー、重大インシデントのレビュー、および契約レベルの意思決定を行う、双方の上級管理職フォーラムです。 | 年2回 |
本項に定めるSLA目標は、毎年 Steering Committee会議で見直され、当事者の書面による相互合意により修正されることがあります。
Azure SLA Summary: https://azure.microsoft.com/en-us/support/legal/sla/summary/ ITIL Service Level Management: https://www.axelos.com/best-practice-solutions/itil
3.11 プロセス登録簿
以下の表は、本章で定めるSLA管理プロセスを要約したものです。責任者の役割、期待される成果、および他章における関連プロセスとの相互参照を含みます。
役割凡例: P = Provider | C = Customer | PSD = Provider Service Desk | SDM = Service Delivery Manager | SC = Steering
Committee
3.11.1 プロセス登録
| 参照 | プロセス | トリガー | 担当者 | 承認者 | 期待される成果 | 参照先 |
|---|---|---|---|---|---|---|
| P-3.01 | 可用性監視 | 継続的（自動化） | Provider（NOC） | SDM | 99.9%のSLOを維持。しきい値超過時にアラートを発報 | § 3.2 |
| P-3.02 | インシデント分類 | インシデントをPSDに報告 | PSD | Customer / SDM | 相互合意した優先度（P1～P4） | § 3.5, § 4.3 |
| P-3.03 | SLAパフォーマンス測定 | 月末締め | SDM | — | 10営業日以内に月次SLAレポートを提出 | § 3.9.1 |
| P-3.04 | SLA違反検知 | 月次SLAレポートで違反を確認 | SDM | Provider Account Mgr | ペナルティ計算を開始 | § 3.8 |
| P-3.05 | Penalty Claim & Payment | Customerは30日以内に請求を提出 | Provider Finance | Provider Account Mgr | 検証後30日以内に金銭支払 | § 3.8 |
| P-3.06 | 四半期サービスレビュー | 四半期末 | SDM + Customer IT Liaison | 運営委員会 | サービスレビュー完了。CSI登録簿を更新 | § 3.9.2, § 4.10 |
| P-3.07 | 新規ユーザー有効化 | Customerのライセンス追加依頼 | Provider（PSD） | お客様IT窓口 | 2営業日以内にユーザーを有効化。ARRを日割り調整 | § 3.9, § 6 |
| P-3.08 | 予定メンテナンス | メンテナンスウィンドウを計画 | 提供者（Infra） | SDM | メンテナンス完了。月4時間以下。Customerへ5営業日前に通知 | § 3.1.3 |
3.11.2 RACIマトリクス
| プロセス（参照） | プロバイダー | PSD | 顧客 | SDM | SC |
|---|---|---|---|---|---|
| P-3.01 可用性監視 | R | I | I | A | — |
| P-3.02 インシデント分類 | — | R | C | A | — |
| P-3.03 SLA測定 | — | — | I | R/A | I |
| P-3.04 違反検知 | — | — | I | R | I |
| P-3.05 ペナルティ請求 | R | — | R | A | I |
| P-3.06 四半期レビュー | C | — | R | R | A |
| P-3.07 ユーザー有効化 | R | R | A | I | — |
| P-3.08 予定メンテナンス | R | I | I | A | — |
R = Responsible（実行） | A = Accountable（承認責任） | C = Consulted（協議先） | I = Informed（通知先） | — = 不関与
3.11.3 プロセスフロー ― SLAライフサイクル
| 段階 | 活動 | 役割 | 成果物 |
|---|---|---|---|
| ① 監視 | 可用性とパフォーマンスの継続監視（Azure Monitor、Defender） | Provider（NOC） | リアルタイムアラート、稼働時間データ |
| ② 検知 | PSDのオムニチャネル経由でインシデントを検知または報告 | PSD / Customer | チケット作成 → § 4.3 |
| ③ 分類 | 優先度を割当て（P1～P4）、SLAクロックを開始 | PSD + Customer | 合意済み優先度、応答タイマー |
| ④ 解決 | MTTR目標に従って解決。必要に応じてエスカレーション | Provider Engineering | インシデント解決 → § 4.4 |
| ⑤ 報告 | 月次SLAレポートを作成。GOSと可用性を算出 | SDM | SLAレポート → § 3.9.1 |
| ⑥ レビュー | 四半期サービスレビュー。CSI登録簿を更新 | SDM + Customer + SC | CSI対応 → § 4.10 |
| ⑦ ペナルティ適用 | 違反時: ペナルティ請求、検証、金銭支払 | Customer → Provider Finance | 30日以内に支払 |
