トイルバジェット | IT 技書の森

トイルバジェットとは

トイル (Toil) は、Google の SRE チームが定義した概念で、「手作業で、繰り返し発生し、自動化可能で、戦術的で、長期的な価値を生まない運用タスク」を指す。トイルバジェットは、チームがトイルに費やす時間の上限を設定し、残りの時間をエンジニアリング (自動化、改善、新機能開発) に充てる管理手法だ。

Google SRE の原則では「トイルは業務時間の 50% 以下に抑える」とされている。この 50% ルールは単なる目安ではなく、組織的なコミットメントだ。50% を超えたら、新機能開発を止めてでもトイル削減に投資する。

トイルの 5 つの特徴

Google SRE Book では、トイルを以下の 5 つの特徴で定義している。すべてを満たす作業がトイルだ。

手作業 (Manual): 人間が手を動かす必要がある
繰り返し (Repetitive): 同じ作業が何度も発生する
自動化可能 (Automatable): 原理的にスクリプトやツールで置き換えられる
戦術的 (Tactical): 長期的な改善ではなく、目の前の問題への対処
価値が持続しない (No enduring value): 作業の効果が一時的で、システムの恒久的な改善につながらない

トイルとトイルでないものの境界

作業	トイルか	理由
手動デプロイ	✅ トイル	自動化可能、繰り返し発生
アラート対応の手動リスタート	✅ トイル	根本原因を解決していない
手動でのユーザーアカウント作成	✅ トイル	セルフサービス化で自動化可能
障害のポストモーテム作成	❌ トイルではない	学習と改善につながる持続的価値がある
アーキテクチャ設計レビュー	❌ トイルではない	長期的な品質向上に寄与
新しい監視ダッシュボードの構築	❌ トイルではない	一度作れば継続的に価値を生む

トイル削減の ROI 計算

トイルを自動化するかどうかは、投資対効果で判断する。

自動化の ROI = (週あたりのトイル時間 × 52 週) ÷ 自動化にかかる時間

例: 週 2 時間のデプロイ作業を自動化するのに 16 時間かかる場合

年間のトイル時間: 2 × 52 = 104 時間
回収期間: 16 ÷ 2 = 8 週間
年間の削減効果: 104 - 16 = 88 時間

8 週間で元が取れ、年間 88 時間を他の作業に充てられる。この計算を習慣化すると、「自動化すべきか」の判断が感覚ではなく数値に基づくようになる。

AWS サーバーレス環境でのトイル削減

トイル	自動化手段
手動デプロイ	GitHub Actions + SAM CLI
アラート対応の手動リスタート	CloudWatch アラーム + Lambda で自動復旧
ログの手動確認	CloudWatch Logs Insights + ダッシュボード
手動データバックアップ	DynamoDB のポイントインタイムリカバリ (PITR)
SSL 証明書の手動更新	ACM の自動更新
インフラの手動構築	CloudFormation / SAM テンプレート

トイルバジェットとエラーバジェットの関係

トイルバジェットとエラーバジェットは、SRE の 2 大バジェット概念だ。

エラーバジェット: 「どれだけ障害を許容するか」の予算。SLO (99.9%) から算出し、残りの 0.1% がエラーバジェット
トイルバジェット: 「どれだけ手作業を許容するか」の予算。業務時間の 50% が上限

両者は連動する。トイルが多いとエンジニアリングに時間を割けず、自動化や信頼性向上が進まない。結果としてエラーバジェットを消費しやすくなる。トイルを減らすことは、間接的にシステムの信頼性を高める。

よくある落とし穴

トイルの過小評価: 「5 分で終わるから大したことない」と思っても、週 5 回発生すれば年間 21 時間になる。小さなトイルの積み重ねを可視化することが重要
自動化の過剰投資: 年に 1 回しか発生しない作業を自動化するのは ROI が合わない。頻度と工数の両方を考慮する
トイルの移転: 自分のトイルを他チームに押し付けるだけでは、組織全体のトイルは減らない
計測の欠如: トイルの量を計測していないと、50% ルールを守れているか判断できない。タイムトラッキングツールで運用作業の時間を記録する習慣が必要

Google の「Site Reliability Engineering」(Betsy Beyer ら編) の第 5 章「Eliminating Toil」がトイルの原典であり、トイルバジェットの考え方が体系的に解説されている。

トイルバジェットについては関連書籍でも詳しく扱われている。