TL;DR
- Toil = 手作業・反復的・自動化可能・価値を生まない・スケールしない作業。Google SRE 本の定義は2026年も有効
- 「Toil 率 50% を超えたら持続不可能」のルールは AI 自動化時代でも基準として機能する
- 測定は週次タイムログ（toil / engineering / 学習）の自己申告 + チーム平均 + 4週移動平均
- 削減サイクル：上位3 Toil 特定 → 自動化 / 廃止 / 委譲 → 2週後に再測定
- AI エージェントに Toil を委譲する際は「権限最小化 + 監査ログ + rollback」を必須に
この記事の目的と成功基準
- 目的: Toil 50%ルールを測定・分類・削減の継続サイクルとして実装可能にする
- 想定読者: SRE / Platform チームの IC・EM、運用負荷に悩むチームリード
- 成功基準: 「Toil 削減」「SRE 50%ルール」関連クエリでの流入、SRE KPI ツールキット への回遊
Toil とは何か
Google SRE 本 の定義：Toil は以下の性質を持つ作業。
- 手作業（manual）: 人が毎回手を動かす
- 反復的（repetitive）: 何度も同じことを繰り返す
- 自動化可能（automatable）: 機械に任せられる
- 戦術的（tactical）: 価値創造でなく対症療法
- 価値を生まない（no enduring value）: 終わっても状態が改善しない
- スケールしない（scales linearly）: サービス成長に比例して増える
例：手動デプロイ、アラート対応の定型処理、手動のデータ修正、繰り返しの問い合わせ対応。
逆に Toil でないもの：設計、コードレビュー、自動化の実装、インシデントの根本対応。
なぜ50%がラインなのか
"If SREs spend >50% of their time on tickets vs. engineering, the system is unsustainable."
50% を超えると：
- engineering（自動化・改善）の時間がなくなる
- Toil がさらに Toil を生む悪循環
- バーンアウト・離職リスク
- サービス成長に運用が追いつかなくなる
SRE best practices 2026 でも、Toil 率は「持続可能性の最重要シグナル」と位置づけられている。
測定方法
週次タイムログ（軽量）
各メンバーが週末に5分で自己申告：
今週の作業時間配分（合計100%）:
- Toil（手作業・反復）: ___%
- Engineering（自動化・設計・改善）: ___%
- 学習・その他: ___%
集計ルール
- 個人別でなくチーム平均で見る（個人を責めない）
- 4週移動平均でトレンドを捉える（単週のブレを除去）
- 50% を3週連続で超えたら緊急介入
可視化
SRE KPI ツールキット の週次レビューに Toil 率を組み込み、4 KPI（SLI/SLO/Error Budget/Toil）の一つとして常時監視。
削減サイクル
50% 超を検知したら：
Step 1: Toil の棚卸し
チームで「今週やった Toil」を全部リストアップ。頻度 × 1回あたり時間で重み付け。
Step 2: 上位3つを特定
最も時間を食っている Toil トップ3に絞る。全部やろうとしない。
Step 3: 3つの選択肢で対処
各 Toil に対し：
| 選択肢 | 判断基準 |
|---|---|
| 自動化 | 頻度高 + ロジック明確 → スクリプト / CI / エージェント化 |
| 廃止 | そもそも不要 → やめる（意外と多い） |
| 委譲 | 他チーム / セルフサービス化で消す |
「自動化」が常に正解ではない。廃止できるものは廃止が最速。
Step 4: 2週後に再測定
介入の効果を測る。Toil 率が下がっていなければ別の手を打つ。
AI 自動化時代の Toil 委譲
2026年は Toil を AI エージェントに委譲できる。ただし注意：
- 権限最小化: エージェントが扱う権限を必要最小に（LLMガードレール設計 参照）
- 監査ログ: エージェントの全アクションを記録
- rollback: 自動対応が誤った時に戻せる設計
- HITL: 破壊的操作（削除・本番変更）は人間承認
AI に委譲した Toil は「消えた」のではなく「AI が実行している」状態。AI 由来の新 KPI（auto-remediation success rate 等）で監視する。
委譲しやすい Toil / しにくい Toil
| 委譲しやすい | 委譲しにくい |
|---|---|
| 定型アラートの一次対応 | 判断を要するインシデント |
| ログ調査・要約 | 根本原因の設計判断 |
| 定型問い合わせ回答 | 顧客との交渉 |
| データの定型修正 | スキーマ設計変更 |
委譲しにくい Toil は「廃止 / プロセス改善」で減らす。
アンチパターン
- Toil 率を個人評価に使う: 自己申告が歪む、チーム平均のみ
- 50% 超を放置: バーンアウトまで進む、3週ルールで強制介入
- 全 Toil を一度に自動化: リソース分散、上位3つに集中
- 自動化が常に正解と思う: 廃止できるものは廃止が最速
- AI 委譲で監査を省略: AI 誤動作が新たな Toil/障害を生む
Growth Lab の運用例
参考：本サイト Platform チーム：
- Toil 率：30%（健全レンジ）
- 測定：週次 Slack 自己申告、4週移動平均をダッシュボード化
- 直近の削減例：手動 thumbnail 再生成 Toil を
render:article-images --forceスクリプト化で削減 - AI 委譲：定型リンク切れ検知を CI（links:check）に自動化
50% を超えたのは過去1回（大型移行期）、3週ルールで検知し2週で34%に回復。
FAQ
Q. Toil の自己申告が正確でない懸念があります A. 正確さより傾向です。完璧な計測でなくても4週移動平均で傾向は掴めます。匿名性とチーム平均運用で歪みを抑えます。
Q. Toil 率が常に低い（20%以下）のは良いこと？ A. 必ずしも。極端に低いと「engineering に偏り運用が見えていない」可能性も。20-40% が健全レンジとされます。
Q. AI に Toil を委譲したら Toil 率はどう計算しますか？ A. AI が実行している分は「人の Toil」からは外れますが、AI 監視（誤動作対応）が新たな作業として乗ります。AI 由来 KPI を別途追跡してください。
まとめ
Toil 50%ルールは AI 自動化時代でも持続可能性の最重要シグナル。週次タイムログ（チーム平均・4週移動平均）で測定し、50% 超3週連続で緊急介入。上位3 Toil を自動化 / 廃止 / 委譲し2週後に再測定する継続サイクルを回す。AI 委譲は権限最小化・監査・rollback を必須に。Toil を消すのではなく「人がやるべきことに時間を戻す」のが目的。
