https://hdknr.github.io/blogs/tags/%E6%8F%90%E6%A1%88%E6%9B%B8/Recent content in 提案書 on hdknr blogHugo -- 0.157.0jaMon, 11 May 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/05/sli-slo-sla-proposal/Mon, 11 May 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/05/sli-slo-sla-proposal/<p>IoT システムや SaaS の提案書を書いていると、お客様から「このシステム、ちゃんと動くんですか?」と聞かれます。<strong>この質問にどう答えるか</strong> で、契約交渉の主導権が決まります。</p> <p>「99.9% 動きます」と言い切れば SLA（契約）になり、下回ったら違約金。「目標値です」と言えば SLO（内部目標）で、未達でも返金義務はない。<strong>この 1 文字違いで法的拘束力が変わります</strong>。</p> <p>本記事では、SRE（Site Reliability Engineering）業界で標準となっている <strong>SLI / SLO / SLA</strong> の 3 用語の <strong>違いと使い分け</strong> を、提案書を書く立場から整理します。</p> <h2 id="3-用語の違い要点">3 用語の違い（要点）</h2> <table> <thead> <tr> <th>略語</th> <th>正式名</th> <th>一言で</th> <th>性格</th> </tr> </thead> <tbody> <tr> <td><strong>SLI</strong></td> <td>Service Level <strong>Indicator</strong></td> <td>計測する指標</td> <td>データ</td> </tr> <tr> <td><strong>SLO</strong></td> <td>Service Level <strong>Objective</strong></td> <td>目指す目標</td> <td><strong>内部約束</strong></td> </tr> <tr> <td><strong>SLA</strong></td> <td>Service Level <strong>Agreement</strong></td> <td>契約上の保証</td> <td><strong>対外契約</strong></td> </tr> </tbody> </table> <p>順序は <strong>SLI → SLO → SLA</strong> で考えます。</p> <ol> <li><strong>SLI</strong> で「何を測るか」を決める（例: イベント検知から通知メール送信までの遅延時間）</li> <li><strong>SLO</strong> で「目標値」を内部で握る（例: 95%ile が 60 秒以内）</li> <li><strong>SLA</strong> で「契約条項」に格上げする（例: SLO 違反が月 3 件超えたら月額の 10% 返金）</li> </ol> <h2 id="なぜ-3-つに分かれているのか">なぜ 3 つに分かれているのか</h2> <p><strong>Google SRE Book</strong> が提唱した「エラーバジェット」の考え方が背景にあります。</p>