SRE業務の中に「毎回手で同じことをやっている作業」はないでしょうか。
「デプロイのたびにSlackで通知を送っている」「毎朝ログを確認してCSVに貼り付けている」「サービス再起動をSSHで手動実行している」——こういった作業は、エンジニアの時間を静かに蝕んでいます。
Google SRE本はこれをToil（トイル）と呼び、意図的に削減すべき作業として定義しています。Toilを放置するとエンジニアの時間がどんどん消費され、本来やるべき信頼性向上への投資ができなくなります。
この記事では、Toilの定義・計測方法・削減アプローチ・AWSでの実践例を解説します。
この記事でわかること
– Toilとは何か（Google SRE本の定義と6つの特徴）
– Toilを見極める判断基準
– Toilの量を計測する方法と「50%ルール」
– Toil削減の3つのアプローチ
– AWSでの具体的なToil削減実例
– Toil削減を組織として継続的に回す仕組み
Toilとは何か
Google SRE本の定義
ToilはGoogleのSREブック（Site Reliability Engineering）で提唱された概念です。原文の定義は以下のとおりです。
“Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.”
日本語にすると：「本番サービスの運用に付随する、手動・繰り返し・自動化可能・戦術的・将来的価値がなく、サービスの成長に比例して増える種類の作業」
重要なのは、「忙しい」「大変」な作業がすべてToilというわけではないという点です。難易度が高い問題解決・システム設計・コードレビューは負荷が高くても「Toilではない」とされます。Toilかどうかは性質によって決まります。
Toilの6つの特徴
Google SRE本はToilを以下の6つの特徴で定義しています。
| 特徴 | 説明 |
|---|---|
| ① 手動（Manual） | 自動ではなく人間が直接操作する必要がある |
| ② 繰り返し（Repetitive） | 同じ作業を何度も繰り返す |
| ③ 自動化可能（Automatable） | 機械やスクリプトに任せられる |
| ④ 戦術的（Tactical） | 割り込みで発生し、計画的に進めにくい |
| ⑤ 永続的価値がない（Devoid of enduring value） | やっても翌日にはまた同じ状態に戻る |
| ⑥ 線形増加（Scales linearly） | サービス規模が大きくなるほど作業量が増える |
この6つのうち複数に該当する作業は、Toilとして削減対象にすべきです。
Toilを見極める判断基準
「やらなかったら何が起きるか？」で判断する
Toilかどうかを現場で素早く判断するには、「この作業をやらなかったら何が起きるか？」を考えます。
- 「サービスが壊れる・障害になる」 → Toilではなく本質的な作業（ただし、なぜ手動なのかは問い直すべき）
- 「翌日には誰かが同じことをまたやる」 → Toil
- 「ログが取れないだけで実害はない」 → Toil
- 「やらないと誰かがクレームを言うが、ビジネス価値は薄い」 → Toil
よくあるToilの例
現場でよく見かけるToilを具体的に挙げます。
監視・運用系
– 毎朝手動でログを確認してSlackに貼る
– CloudWatchメトリクスを毎週スクショしてレポートに添付する
– アラートを確認して「対応不要」とコメントし続ける（不要なアラートを止めていない）
インフラ操作系
– デプロイ前後にSSH接続して手動でサービス再起動する
– 毎月AMIのバックアップをコンソールから手動実行する
– 証明書の期限をスプレッドシートで管理して手動で更新する
開発支援系
– 新メンバーのAWSアカウントをコンソールで毎回手動作成する
– ステージング環境へのデプロイをSlackコマンドではなくコンソールで都度実行する
Toilの量を計測する
時間ベースで計測する
Toilが「どのくらい存在するか」を把握するには、エンジニアの作業時間に占めるToilの割合を計測します。
計測の手順：
- 1週間または2週間、作業ログをつける（時間単位で何をしたかを記録）
- 各作業をToilか否かに分類する
- Toilの合計時間 ÷ 総作業時間 を計算する
例）1週間の作業ログ（エンジニアAさん）
設計・実装: 12時間
コードレビュー: 4時間
ミーティング: 6時間
手動ログ確認・Slack転記: 3時間 ← Toil
手動バックアップ操作: 1時間 ← Toil
アラート確認（対応不要）: 2時間 ← Toil
Toil割合 = 6時間 / 28時間 ≒ 21%
Google SREの「50%ルール」
Google SRE本は「SREの作業時間のうちToilが50%を超えてはならない」という指針を示しています。
“If you’re spending more than 50 percent of your time on toil, that’s a sign you’ve lost the balance between toil and engineering work.”
SRE本来の価値は「信頼性エンジニアリング」——システム設計の改善・自動化・モニタリング強化にあります。Toilが50%を超えると、SREが「運用オペレーター」になってしまいます。
Toilが50%に近づいているチームは、それ自体を問題として組織に見せる必要があります。
Toil削減の3つのアプローチ
アプローチ① 自動化（Automation）
最も直接的な削減方法です。繰り返し発生する手動作業をスクリプト・Lambdaなどで自動化します。
効果が高い自動化対象の見つけ方
– 「毎日・毎週必ずやる」作業
– 「やり方が決まっていて、誰でも同じ結果になる」作業
– 「5分でできるが毎週あるので年間40時間消えている」作業
自動化の優先順位は「頻度 × 所要時間 × 人数」で計算します。年間1時間しか使わないToilを自動化するより、毎日5分かかるToilを自動化する方が費用対効果が高いです。
アプローチ② セルフサービス化（Self-service）
依頼を受けるたびに対応するTolilは、依頼者が自分でできる仕組みを作ることで削減できます。
例：
– 「開発者がステージングデプロイをSlackコマンドで実行できるようにする」
– 「新環境のS3バケット作成をセルフサービスポータルから申請・自動作成できるようにする」
– 「Runbookをドキュメント化して、誰でも作業を実行できるようにする」
セルフサービス化は「自分が対応しなくていい」ことが目的ではなく、「依頼〜対応のリードタイムをゼロにする」ことが目的です。
アプローチ③ サービス設計の改善
ToilはサービスやシステムのDesign上の問題から発生することがあります。この場合は自動化ではなく、根本的な設計を変えることが解決策になります。
例：
– 毎回手動でサービス再起動しないと回復しない → ヘルスチェック + Auto Healingを実装する
– 証明書を手動更新している → AWS ACMを使って自動更新に変える
– 毎週ログを手動で集計している → CloudWatch Logs Insightsで定期クエリを実行する
AWSでのToil削減実践例
AWS Lambda + EventBridge：定期タスクの自動化
「毎朝決まった時間に実行する」系のToilはEventBridge（旧CloudWatch Events）+ Lambdaで自動化できます。
# Lambda関数例：毎朝9時にCloudWatchメトリクスをSlackに通知する
import boto3
import json
import urllib.request
def lambda_handler(event, context):
cw = boto3.client('cloudwatch')
# メトリクス取得
response = cw.get_metric_statistics(
Namespace='AWS/EC2',
MetricName='CPUUtilization',
Dimensions=[{'Name': 'InstanceId', 'Value': 'i-xxxxxxxxxx'}],
StartTime='...',
EndTime='...',
Period=3600,
Statistics=['Average']
)
avg_cpu = response['Datapoints'][0]['Average']
# Slack通知
payload = {'text': f'昨日のCPU平均: {avg_cpu:.1f}%'}
req = urllib.request.Request(
'https://hooks.slack.com/services/...',
data=json.dumps(payload).encode('utf-8')
)
urllib.request.urlopen(req)
EventBridgeのcronルールで「毎朝9:00 JST」に起動するよう設定するだけで、手動確認・Slack転記という毎日のToilがゼロになります。
// EventBridge Scheduleルール（JST 9:00）
{
"ScheduleExpression": "cron(0 0 * * ? *)"
}
AWS Systems Manager Automation：定型運用作業の自動化
インスタンスの再起動・パッチ適用・バックアップなどの運用タスクは、Systems Manager Automationで標準化できます。
AWSが用意しているRunbook例：
– AWS-RestartEC2Instance：EC2インスタンスの安全な再起動
– AWS-CreateImage：AMIバックアップの作成
– AWS-PatchInstanceWithRollback：パッチ適用（失敗時に自動ロールバック）
# CLIでAutomationを実行する例
aws ssm start-automation-execution \
--document-name "AWS-CreateImage" \
--parameters "InstanceId=i-xxxxxxxxxx,NoReboot=false"
EventBridgeと組み合わせて定期実行にすることで、「毎月1日にバックアップを手動で取っていた」というToilを完全に排除できます。
AWS Certificate Manager (ACM)：証明書の手動更新を排除
SSL証明書をスプレッドシートで期限管理し、手動で更新していた場合、ACMに移行することでToilをゼロにできます。
ACMで発行した証明書は：
– 90日前から自動的に更新処理が始まる
– ALBやCloudFrontに紐付けると更新作業が不要になる
– 期限切れ直前のアラートをEventBridgeで飛ばすことも可能
# CloudFormationでACM証明書を管理する例
Resources:
SiteCertificate:
Type: AWS::CertificateManager::Certificate
Properties:
DomainName: example.com
ValidationMethod: DNS
SubjectAlternativeNames:
- "*.example.com"
Terraform / CloudFormation：インフラ構築作業の自動化
「新しい環境を作るたびにコンソールを開いてポチポチ設定する」のは典型的なToilです。IaCで定義しておくことで、コマンド1つで同じ環境を再現できます。
# Terraform で環境を複製する
terraform workspace new staging
terraform apply -var-file="staging.tfvars"
IaCはインフラ構築のToilを削減するだけでなく、設定ドリフトの防止・レビュー可能性の向上・障害時の素早い再構築にも効果があります。
Toil削減を組織として継続的に回す仕組み
Toil計測を定期化する
Toilは「いつの間にか増える」性質があります。新しいサービスが加わるたびに手動運用が増え、気づいたら工数の半分を占めているという事態が現場では頻繁に起きます。
対策として、四半期に1回のToil計測を習慣にすることを推奨します。
チームで2週間の作業ログをつけ、ToilとNon-Toilに分類してパーセンテージを出すだけです。この数字を「Toil率」として可視化し、チームのOKRやスプリントの振り返りで共有します。
ポストモーテムとToil削減を連動させる
インシデントの振り返りで「なぜこの対応に時間がかかったか」を分析すると、Toilが根本原因になっているケースが多くあります。
- 「Runbookがなくて手順を毎回調べていた」→ Runbook整備
- 「証明書期限を手動で確認していて気づかなかった」→ ACM移行
- 「デプロイを手動で実行していてオペミスした」→ CI/CD整備
ポストモーテムのアクションアイテムとしてToil削減タスクを登録し、スプリントに組み込む流れを作ることで、インシデントが自動化のトリガーになります。
エンジニアリング時間の確保
Toilを削減するには「削減するための作業時間」が必要です。Toilが多すぎると削減作業をする余裕がない、という悪循環に陥ります。
Google SREが実践する指針：
– SREの20%の時間をToil削減・自動化プロジェクトに充てることをマネジメントと合意する
– スプリントに「Toil削減チケット」を1本以上含める
– 新機能開発と信頼性改善の比率をチームとして定期的に見直す
Toilを削減するために時間を使うことは、中長期的に見てチーム全体の生産性に直結します。
まとめ：ToilはSREが設計で解く問題
Toilの削減ポイントをまとめます。
| 項目 | チェックポイント |
|---|---|
| 定義の理解 | 手動・繰り返し・自動化可能・線形増加の4条件で判断 |
| 計測 | 作業ログから「Toil率」を四半期ごとに算出している |
| 50%ルール | SREのToilが50%を超えていないか確認している |
| 自動化 | 「頻度×時間×人数」で優先順位をつけて着手している |
| セルフサービス化 | 依頼ベースの手動作業を依頼者が自己完結できる仕組みにしている |
| 設計改善 | Auto Healing・ACM・IaCなどでToilの発生源を根絶している |
| 組織化 | ポストモーテムとスプリントにToil削減を組み込んでいる |
Toilは「ちゃんとやっている証拠」でも「頑張っている結果」でもありません。設計の隙間から生まれる余分なコストです。 SREはこれを意識的に計測し、削減し続けることで、本来のエンジニアリング——信頼性向上・アーキテクチャ改善・インシデント予防——に時間を使えるようになります。
Toil削減スキルを体系的に学ぶには
Toil削減・自動化設計・SLO運用などのSREプラクティスは、AWSのLambda・Systems Manager・CloudWatchを組み合わせながら実践的に習得するのが最も効果的です。
現役SREが設計した実践コースで、CloudWatchを使った監視設計・自動化の基礎から応用まで体系的に学べます。
📌 AWS×SRE入門〜CloudWatchで学ぶ監視設計の基礎〜を見てみる
関連記事
📌 インシデント対応フローの設計｜検知から復旧・振り返りまでSRE流に解説
📌 ポストモーテムの書き方完全ガイド｜blameless文化を現場に根付かせる5つのポイント
📌 オンコール設計のベストプラクティス｜疲弊しない体制の作り方をSRE視点で解説
コメント