社内ツール向けSLO：実際に効くシンプルな信頼性目標

なぜ社内ツールにもSLOが必要か（利用者が20人でも）

社内ツールは利用者が少ないので小さく感じますが、影響は小さくないことが多いです。オペスダッシュボードが落ちれば注文処理が止まる。サポートコンソールが遅ければ顧客が待たされる。管理画面が壊れれば修正がたまります。

明確な信頼性目標がないと、障害ごとに議論になります。ある人は10分の障害を気にしない一方、別の人は大騒ぎします。曖昧な優先度や驚きの作業に時間を奪われます。

SLOは測定可能なシンプルな期待値を設定して、この問題を解決します。何が動くべきか、そしてどの程度動けば仕事ができるか、という実用的な問いに答えます。

「まあまあ安定させる」という暗黙のコストはすぐ現れます。ツールの回復を待って作業が止まる。サポートの問い合わせが増える。エンジニアが計画的な改善ではなく緊急対応に取られる。プロダクトオーナーがシステムを信頼できなくなり手動の代替策を求める。小さな問題が明確な基準を超えないまま放置され続けます。

完全な信頼性プログラムは不要です。小さなチームなら「ログインが動く」「検索が速く返る」などユーザー視点の目標をいくつか決め、実際の行動につながる少数のアラートを設定するだけで始められます。

これはツールの作り方に関係なく当てはまります。もしAppMaster (appmaster.io)で内部アプリを作っているなら、人が頼る操作を選び、稼働率と応答時間を測り、業務に影響が出るときだけアラートするようにしてください。

SLO、SLI、SLAを分かりやすく

似た言葉に聞こえますが、それぞれ役割が違います。混同はよくある誤解の元です。

**SLI（Service Level Indicator）**は計測する指標です。例えば「成功したリクエストの割合」や「ページの読み込みにかかった時間」のように数えられるものです。信頼して計測できないものは良いSLIではありません。

**SLO（Service Level Objective）**はその指標に対する目標値です。普段の利用でユーザーが困らないレベルはどれくらいかを示します。SLOは、何を優先的に直すべきか、何を後回しにできるかの判断を助けます。

**SLA（Service Level Agreement）**は書面化された約束で、しばしば何らかの結果（ペナルティなど）を伴います。多くの社内ツールはSLAを必要としません。必要なのは明確な目標であって法的約束ではありません。

簡単な例:

• SLI（稼働率）: ツールが到達可能だった分の割合（分単位）
• SLO（稼働率目標）: 月間99.9%の稼働率
• SLI（レイテンシ）: ダッシュボードのp95読み込み時間
• SLO（レイテンシ目標）: 業務時間中のp95が2秒未満

ここで欠けているのは「決して落ちない」「常に速い」といった完璧さの約束です。SLOは妥協点を可視化して、小さなチームが機能追加、信頼性改善、無駄な手作業の回避を選べるようにします。

実用ルール：もし目標を達成するのに英雄的な対応が必要なら、それはSLOではなく希望にすぎません。まずはチームが落ち着いて維持できる目標から始め、ユーザーにまだ痛みが残るなら後から厳しくしてください。

本当に重要なユーザー操作を絞る

社内ツールの故障は特定の形で起きることが多いです：管理画面は表示されるが保存で永遠に待つ、オペスダッシュボードは開くがグラフが更新されない、スタッフポータルは動くがログインが更新後に壊れるなど。価値が最大化されるのは、日常的に人が頼る操作に焦点を当てることです。

まずツールの種類を名前にすること。種類が重要経路を示します。管理画面は「安全に何かを変更すること」がポイント。オペスダッシュボードは「今何が起きているかを確認すること」がポイント。ポータルは「入って情報を見つけ、申請する」ことがポイントです。

次に、主要なユーザージャーニーを分かりやすく書き出します。出発点に良い例：

• ログインしてホーム画面に到達する
• 検索やフィルタをかけて結果を得る
• フォームを送信（作成／更新）して成功メッセージが出る
• メインのダッシュボードビューを新しいデータで読み込む
• 日次作業で使うレポートをエクスポートまたはダウンロードする

各ジャーニーごとに失敗と見なす条件を定義します。厳密かつ測定可能に：500エラーは失敗、タイムアウトは失敗、ページが読み込み終わらないのは失敗、成功と返ってもデータが欠けているのは失敗です。

最初は範囲を小さく保ちます。実際の痛みとリスクに合う1〜3のジャーニーを選ぶ。もしオンコールでよく発生するのが「誰もログインできない」と「保存ボタンが固まる」なら、まずはログインとフォーム送信から始め、測定とアラートを信頼できるようになってから検索を追加します。

実際に計測できるSLIを選ぶ

良いSLIは地味です。既に持っているデータから取れ、ユーザーがツールの正常動作や障害を感じる点に一致します。新しい監視セットアップが必要になるなら、もっと単純なSLIを選んでください。

まずは利用者が理解しやすい可用性から始めます：ツールを開けるか、タスクを完了できるか。多くの社内ツールでは二つのSLIで痛みの大部分をカバーできます。

• ツールの稼働率（到達可能で応答があるか）
• 1〜3の主要操作の成功率（ログイン、検索、保存、承認など）

その後レイテンシを追加しますが、範囲は狭くします。ユーザーが遅さを覚える画面やエンドポイントを1〜2つ選びます（例：ダッシュボードの読み込みやフォーム送信）。全部を計測するとノイズと議論が増えます。

計測ウィンドウを最初に決めておきます。安定したツールならローリング30日が一般的。リリース頻度が高く早いフィードバックが欲しいなら週単位でも良い。何を選んでも一貫して使うことが重要です。

最後に、SLIごとに一つの真実の情報源を決めて書き残します。

• 合成チェック（ボットがヘルスチェックや簡単なフローを実行）
• サーバーメトリクス（リクエスト数、エラー、バックエンドのレイテンシ）
• ログ（特定操作の「成功」対「失敗」をカウント）

例：内部アプリがAppMasterで作られている場合、バックエンドへの合成pingで稼働率を測り、API応答で成功率を、バックエンドの処理時間でレイテンシを測ることができます。重要なのは完璧さではなく一貫性です。

現実的な稼働率とレイテンシのSLOを設定する

まずは悪い週でも擁護できる稼働率を選びます。多くの社内ツールで99.5%は良い最初のSLOです。高く聞こえますが、通常の変更作業の余地を残します。いきなり99.9%にすると深夜のページングやリリースの遅延につながりがちです。

稼働率を実感させるために時間に変換しましょう。30日（約43200分）では：

• 99.5%だと月あたり約216分のダウンタイムを許容
• 99.9%だと月あたり約43分のダウンタイムを許容

その許容ダウンタイムがエラーバジェットです。早めに使い切ったらリスクのある変更を止め、回復するまで信頼性作業に集中します。

レイテンシでは平均を避けてください。平均はユーザーが覚えている遅い瞬間を隠します。パーセンタイル（通常p95）を使い、実際の操作に結びつく閾値を設定します。例：「p95ダッシュボード読み込みが業務時間中2秒未満」「p95保存が800ms未満」など。

最初の数値を決める簡単な方法は、実際のトラフィックを1週間観察し、今日より少し良い値を目標にすることです。p95がすでに1.9秒であれば2.0秒のSLOは安全です。500msのSLOは雑音を生むだけです。

SLOはサポート能力に合わせてください。小さなチームなら多数の厳しい目標より達成可能な少数を選ぶべきです。誰も1時間以内に対応できないなら、その前提で目標を設定しないでください。

トレードオフを可視化する：コスト、リスク、エラーバジェット

厳しいSLOは安心を与えますがコストが伴います。99.5%から99.9%に上げると「許容できる悪い時間」が大幅に減り、ページングが増え、機能開発より信頼性作業に時間が割かれることが多いです。

これを実感させる最も簡単な方法はエラーバジェットで話すことです。月間99.5%なら30日で約3.6時間のダウンタイムを使えます。99.9%だと約43分しかありません。この差が機能作業を止める頻度を変えます。

また、期待値はツールが実際に使われる時間に合わせると良いです。24時間体制の目標は、ツールが9時〜18時にしか重要でない場合コストが高くなります。業務時間は厳しく、非業務時間は緩くする二つのSLOを設ければチームは眠れます。

計画的なメンテナンスは、事前に伝えられ範囲が定められていれば失敗と数えないで構いません。事後に無視するのではなくメンテナンスウィンドウとして明示してください。

誰もがトレードオフを見られるように基本を文書化します：

• SLOの数値と、それが外れたときにユーザーが失うもの
• 月間のエラーバジェット（分や時間で）
• ページングルール（誰が、いつ、何に対して）
• 業務時間と24/7の期待値の違い
• 計画メンテナンスが何に当たるか

4〜6週間の実データの後に目標を見直します。エラーバジェットをほとんど消費しないならSLOは緩すぎます。早期に使い切って機能が止まるなら厳しすぎます。

チームが維持できるアラートにSLOを結びつける

アラートはSLOそのものではありません。アラートはSLOを守るための「今何かがまずい」という合図です。実用ルール：SLOごとに意味のあるアラートを1つ作り、それ以上は本当に必要と証明できる場合だけ追加します。

実践的な考え方は、エラーバジェットの減り方が早いことをアラートするか、ユーザーへの痛みに合致する一つの明確な閾値でアラートすることです。例えばレイテンシSLOが「p95 800ms未満」なら、単発の遅延でページを飛ばさないでください。持続的な問題になったときだけページングします。

ノイズを抑えるための単純な分け方：

• 緊急ページ：ツールが実質的に使えなくなっていて、すぐに対応が必要
• 非緊急チケット：劣化はあるが業務時間に対応できる程度

具体的閾値（トラフィックに合わせて調整）：稼働率SLOが月間99.5%なら、5分間で可用性が99%未満ならページング（明確な停止）。6時間で99.4%未満ならチケット作成（徐々に悪化）。レイテンシはp95が15分間1.5s超ならページング、2時間で1.0s超ならチケット、など。

所有権を明確にします。誰がオンコールか（たとえ「今週の1人」でも）、確認の意味（例：10分以内に応答）と最初のアクションを決めます。小規模チームがAppMasterで内部アプリを運用しているなら、最初の行動は最近のデプロイを確認する、APIエラーを見る、必要ならロールバックや再デプロイする、などが現実的です。

実際にアラートがあったら必ず小さなフォローアップを一つ行ってください：原因を直すか、アラートを調整して本当に影響のあるときだけ鳴るようにします。

アラート疲れを生むよくある間違い

アラート疲れは良い意図から始まることが多いです。小さなチームが「ちょっとだけ」アラートを増やしていき、気がつくと通知を信頼しなくなり本当の障害を見逃します。

大きな落とし穴は、すべてのスパイクにアラートを出すことです。社内ツールはバースティなトラフィック（給与処理や月末のレポート）があり、2分の短いブリップでアラートが鳴ると人は無視するようになります。アラートはユーザー影響に結びつけてください。生のメトリクスのノイズではありません。

また「メトリクスが多いほど安全だ」という考えも危険で、たいていはページング増につながります。ユーザーが実際に感じる少数の信号に絞ってください：ログイン失敗、ページが遅い、主要ジョブが終わらない、など。

最もノイズを生むミス：

• CPUやメモリなどの症状でページングし、ユーザー影響には直結しない
• アラートに所有者がいないためチューニングや削除がされない
• ランブックがなく、毎回手探りになる
• ダッシュボードをアラートの代わりに使う（ダッシュボードは診断用、アラートは行動用）
• システムの計測が十分でないのに閾値をでっち上げる

ダッシュボードは大事ですが、アラートを置き換えるものではありません。アラート発生後の診断に使うべきです。

まだ計測が整っていないなら偽装しないでください。まず基本的な計装（成功率、p95レイテンシ、「ユーザーがタスクを完了できるか」のチェック）を追加し、1〜2週間の実データに基づいて閾値を設定します。

アラートをオンにする前の簡単なチェックリスト

アラート疲れの多くは、これらの基本をスキップして後で慌てることから来ます。小さなチーム向けの実用チェックリスト：

• 1〜3の主要ユーザー操作を確認（例：ダッシュボードを開く、チケット更新を保存、レポートをエクスポート）
• 今日計測できる2〜4のSLIに絞る（可用性／成功率、p95レイテンシ、重要エンドポイントのエラー率）
• ツールごとのアラートは合計2〜4件に制限する
• 計測ウィンドウと「悪い」の定義に合意する（高速検出なら直近5分、ノイズを減らすなら直近30〜60分）
• 担当者を決める（チームではなく個人）

次に、アラートが実際に対応できるものであることを確認します。誰も対応できない時間に鳴るアラートは無視されるようになります。

最初のページが飛ぶ前に運用の詳細を決めます：

• ページング時間帯：業務時間のみか24/7か
• エスカレーション経路：最初の人が応答しないとき誰が次か
• 最初にやること：影響確認とロールバックや緩和のための1〜2ステップ
• 月次の簡単なレビュー習慣：鳴ったアラート、見逃したインシデント、SLOの妥当性を15分で確認

ツールを作ったり変更したら（AppMasterでの再生成を含む）チェックリストを再実行してください。再生成されたコードや新しいフローはレイテンシやエラーのパターンを変え、アラートもそれに合わせる必要があります。

例：小さなオペスダッシュボード（SLO2つ、アラート3つ）

ある18人のオペチームが注文状況確認、失敗通知再送、返金承認を日常的に行う内部ダッシュボードを使っています。落ちるか遅いと作業がすぐ止まります。

彼らは二つのSLOを選びました：

• 稼働率SLO： 30日で99.9%の成功したページ読み込み（月約43分の「悪い時間」）
• レイテンシSLO： 業務時間中のp95ページ読み込みが1.5秒未満

次に小さなチームで対応できる3つのアラートを追加しました：

• ハードダウンアラート（ページ読み込み失敗）： 成功率が5分間で98%未満になったときに発生。最初のアクション：最近のデプロイを確認、ウェブアプリを再起動、データベースの健全性を確認。
• 遅いダッシュボードアラート： p95レイテンシが10分間で2.5秒超になったときに発生。最初のアクション：単一の遅いクエリや詰まったバッチジョブを探し、重いレポートを一時停止する。
• エラーバジェット燃焼アラート： 今後7日で月間エラーバジェットの50%を使いそうなときに発生。最初のアクション：必須でない変更を止める。

次週に何が起きるかが重要です。もしエラーバジェットアラートが2回鳴ったら、チームは明確に判断します：新機能を遅らせ、最も大きなレイテンシ原因を2日で直す（例：インデックスのないテーブルスキャン）。AppMasterでツールを作っているなら、データモデルを調整して再生成・再デプロイし、応急処置を積み重ねる代わりにクリーンなコードで直せます。

SLOをプロジェクト化せずに維持する方法

SLOは実際の仕事とつながっている限り役に立ちます。コツはSLOを新しい大きなプログラムにするのではなく、小さな習慣にすることです。

小さなチームに合う運用頻度を決め、既存の会議に組み込みます。週次の短いチェックで変化を捕まえ、月次の微調整で足りることが多いです。

耐えうる軽量なプロセス例：

• 週次（10分）：SLOチャートと直近のアラートを確認し、悪化が静かに進んでいないか確認
• インシデント後（15分）：原因にタグを付け、どのユーザー操作が影響を受けたか記録（ログイン、検索、保存、エクスポートなど）
• 月次（30分）：繰り返すインシデントパターンの上位をレビューし、来月の1つの修正を選ぶ
• 月次（10分）：ノイズの多いアラートを1つ削除または調整する

改善は小さく目に見えるものにします。もし「毎週月曜朝に遅くなる」が3回続くなら、1つ具体的な変更（レポートのキャッシュ、インデックス追加、重いジョブのスケジュール変更）を行い、翌週のSLIを観察します。

SLOは丁寧に「断る理由」としても使えます。価値の低い機能要求が来たら、現在のエラーバジェットを示して「この変更が保存や承認フローを危険に晒すか？」と問います。もし既にバジェットを消費中なら信頼性を優先します。それはブロックではなく優先順位付けです。

ドキュメントは最小限に：ツールごとに1ページ。主要ユーザー操作、SLO数値、それに紐づく少数のアラート、所有者を記載。AppMasterで作るならログ／メトリクスを見る場所と誰がデプロイできるかも書いておき、そこで終わりにします。

次のステップ：小さく始め、ツールを一つずつ改善する

信頼性を現実にする最も簡単な方法は、最初のセットアップを極小に保つことです。壊れたときに実際に痛みを生む1つの社内ツールを選び、日々の数アクションに焦点を当てます。

多くのチームがコピーできる最小限のセットアップ例：

• 1つのツールと2つの主要ユーザー操作を選ぶ（例：ダッシュボードを開く、承認を送信）
• 今すぐ計測できる2つのSLIを定義：エンドポイント／ページの稼働率と操作のp95レイテンシ
• 2つのシンプルなSLOを設定（例：月間99.5%の稼働率、業務時間中のp95 800ms未満）
• 合計2〜3のアラートを作る：ハードダウン、持続的なレイテンシ、エラーバジェットの急速消費
• 週に1回10分でレビュー：アラートは役に立ったか、それともノイズか？

安定したらゆっくり広げます：1つの操作を増やすか、月に1つのツールを追加。もしアラートの所有者が決められないなら、そのアラートはまだ作らないでください。

内部ツールを作ったり作り直す場合、AppMasterは保守を持続しやすくします。データモデルやビジネスロジックを視覚的に更新してクリーンなコードを再生成できるため、SLOを実際の挙動に合わせて保ちやすくなります。

初日から1つの社内ツールを作り、基本的なSLOを組み込んでみてください。期待が明確になり、驚きが減り、小さなチームでも維持できるアラートが実現します。