--- title: "運用の自動化。人がやる作業、仕組みに任せる作業｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/cloud-operations-automation/ description: "クラウドの運用は、くり返しの作業を仕組みに任せ、判断の要る作業を人に残すと回しやすくなります。Google の SRE の「トイル」の考え方、仕組みに任せやすい作業、AWS の自動化の機能、人に残す作業と進め方を説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # 運用の自動化。人がやる作業、仕組みに任せる作業 クラウドの運用は、くり返しの作業を仕組みに任せ、判断の要る作業を人に残すと回しやすくなります。Google の SRE の「トイル」の考え方、仕組みに任せやすい作業、AWS の自動化の機能、人に残す作業と進め方を説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - 手作業で、くり返し、機械でもできて、終えても状態が良くならない作業は「トイル」と呼ばれ、仕組みに任せる候補になります。 - 更新の適用、設定の是正、決まった手順の実行は仕組みに任せやすく、AWS では承認や同時に動かす数の制御も組み込めます。 - 人を呼び出す連絡は、人の判断が要るものだけにします。手順書のうち、短くてよく使うものから自動化します。 運用の自動化は、くり返しで判断の要らない作業を仕組みに任せ、状況を見て決める作業を人に残すように、作業を仕分けることです。すべてを自動にすることが目的ではありません。仕組みに任せた作業の分だけ、人は原因の調査や再発の防止といった、システムを良くする仕事に時間を使えるようになります。 ## 仕組みに任せる作業は、どう見分けるのか 見分ける目安は、Google の SRE（サイト信頼性エンジニアリング）の考え方で「トイル」と呼ばれる作業かどうかです。Google の SRE の書籍は、トイルを、本番のサービスの運用に伴う作業のうち、次のような性質を持つものと説明しています。 - **手作業**：人の手を動かす必要がある - **くり返し**：同じことを何度も行う（初めての問題への対応は含まない） - **機械でもできる**：人と同じように機械でもこなせる - **場当たり**：計画からではなく、割り込みで発生する - **長く残る価値がない**：終えても、サービスの状態が前より良くならない - **規模に比例して増える**：サービスの規模や利用者の数に比例して作業が増える 同じ書籍は、運用の作業（トイル）を各担当者の時間の半分未満に抑え、少なくとも半分は改善の仕事に充てるという目標を示しています。 出典：[Eliminating Toil（Google SRE）](https://sre.google/sre-book/eliminating-toil/) 用語としての [SRE](https://www.ameliatechnology.co.jp/glossary/sre/) は用語集でも説明しています。人の少ない会社では「半分」という目標をそのまま当てはめる必要はありませんが、運用の時間が増え続けて改善に手が回らない状態は、自動化を考えるきっかけになります。 ## 仕組みに任せやすい作業 仕組みに任せやすいのは、手順が決まっていて、結果を機械で確かめられる作業です。次の表は、クラウドの運用でよく挙がる例です。 | 作業 | 仕組みに任せる形の例 | |---|---| | OS の更新の適用 | 足りない更新を調べ、決めた保守の時間帯に当てる | | 決まりに合わない設定の是正 | 決まりに反する設定を見つけたら、決めた手順で直す | | 決まった手順の実行 | 手順書の内容を、実行できる形に書き換えて動かす | | バックアップ | 決めた時刻に取り、残す世代を管理する | | 検証の環境の起動と停止 | 使わない夜間・休日に止め、朝に動かす | 更新の適用の進め方は、[OS・ミドルウェアの更新をどう回すか](https://www.ameliatechnology.co.jp/blog/os-middleware-update-operations/)で説明しています。 ## AWS の自動化の仕組み AWS では、Systems Manager の Automation が、手順を「ランブック」として定義し、順番に実行する仕組みです。ランブックは YAML か JSON で書き、手順は書いた順に動きます。AWS が用意しているランブックを使うことも、自社で書くこともできます。 自動化を本番で使うときに大切なのは、止める仕組みと、人の承認を組み込めることです。Automation には、同時に動かす対象の数と、許すエラーの数を決めておき、それを上回ったら止める「レート制御」があります。また、例として、CloudFormation の更新の前に、1人以上の承認を求める形も示されています。 出典：[AWS Systems Manager Automation（AWS）](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 設定の是正には、AWS Config の修復の機能が使えます。AWS Config のルールで決まりに合わないと判定された設定に対し、Systems Manager の Automation の文書で定めた処理を当てる仕組みです。AWS が用意した処理のほか、自社で作った処理も結び付けられます。こうした[自動の修復](https://www.ameliatechnology.co.jp/glossary/auto-remediation/)は便利な反面、誤った決まりを書くと正しい設定まで書き換えるおそれがあるため、まず通知だけにして様子を見るなど、段階を踏んで広げます。 出典：[Remediating Noncompliant Resources with AWS Config（AWS）](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) Microsoft Azure・Google Cloud にも、更新の予定の実行などの仕組みがあります。どのクラウドでも、作業の手順を[インフラのコード化（IaC）](https://www.ameliatechnology.co.jp/blog/infrastructure-as-code-why/)と同じように文書として管理しておくと、自動化に移しやすくなります。 ## 人に残す作業 人に残すのは、状況を見て判断する作業です。原因の分からない障害の調査、業務への影響を考えて止めるかどうかを決めること、本番への大きな変更の承認、再発を防ぐための設計の見直しは、人が担います。 人を呼び出す連絡の決め方も、この考え方に沿います。Google の SRE の書籍は、呼び出しは対応できるものに限り、呼び出しへの対応には人の判断が要るべきで、決まった手順で済む対応なら呼び出しにすべきではない、としています。決まった手順で済むものは、自動の処理に回します。 出典：[Monitoring Distributed Systems（Google SRE）](https://sre.google/sre-book/monitoring-distributed-systems/) 決まった手順で済むか、人の判断が要るか - **決まった手順で済む**：人を呼び出さず、**自動の処理**に回す - **人の判断が要る**：原因の分からない障害の調査、止めるかどうかの判断、本番への大きな変更の承認、再発を防ぐ設計の見直し。人が担い、必要なら人を呼び出す 夜間・休日にアラートを受ける[当番（オンコール）](https://www.ameliatechnology.co.jp/glossary/on-call/)の負担を減らすうえでも、この仕分けは役に立ちます。監視で何を見るかは[クラウドの監視は何を見るのか。死活・リソース・アプリ](https://www.ameliatechnology.co.jp/blog/cloud-monitoring-what-to-watch/)で説明しています。 ## どこから始めるか 自動化は、すでにある手順書のうち、短くてよく使うものから始めます。AWS の Well-Architected の運用の柱は、手順書（ランブック）をまず文章で整え、組織が成熟するにつれて自動化していくこと、短くよく使う手順書から始めることを勧めています。 出典：[OPS07-BP03 Use runbooks to perform procedures（AWS）](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 進め方の目安は次のとおりです。 1. 月に何度も行い、毎回同じ手順になっている作業を書き出す 2. 手順書が文章になっていない作業は、先に文章にし、別の人が手順書だけで実行できるか確かめる 3. 検証の環境で自動化し、結果を人が確かめる期間を設ける 4. 問題がなければ本番に広げ、止める条件と、うまくいかないときに人へ知らせる経路を決めておく 自動化した処理も、システムの変化に合わせて直す必要があります。誰が持ち主で、どこに置いてあるかを、手順書と同じように管理します。資料の管理の仕方は[構成図と運用の記録を「生きた資料」にする](https://www.ameliatechnology.co.jp/blog/living-architecture-docs/)で説明しています。 ## 当社のご支援 アメリア・テクノロジーの[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、いまの運用の作業の洗い出し、手順書の整備、仕組みに任せる作業の自動化と、人に残す作業の手順づくりをご支援しています。自動化のあとも、運用管理の月額の時間の中で、処理の見直しと月次の報告をお受けできます。料金の目安は[料金の目安](https://www.ameliatechnology.co.jp/pricing/#cloud)をご覧ください。 - クラウド - 運用管理 - 自動化 - SRE ## この記事に出てくる用語 - [SRE（サイトリライアビリティエンジニアリング）](https://www.ameliatechnology.co.jp/glossary/sre/) - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [バックアップ](https://www.ameliatechnology.co.jp/glossary/backup/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [運用手順書（ランブック）](https://www.ameliatechnology.co.jp/glossary/runbook/) - [JSON](https://www.ameliatechnology.co.jp/glossary/json/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「運用の自動化。人がやる作業、仕組みに任せる作業｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/cloud-operations-automation/