--- title: "構成図と運用の記録を「生きた資料」にする｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/living-architecture-docs/ description: "構成図や手順書は、作った日から実際の環境とずれ始めます。資料が古くなる理由、残しておく資料の種類、実際の環境やコードから資料を作る方法、変更の手続きの中で資料を直す決まり、運用の記録の残し方を説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # 構成図と運用の記録を「生きた資料」にする 構成図や手順書は、作った日から実際の環境とずれ始めます。資料が古くなる理由、残しておく資料の種類、実際の環境やコードから資料を作る方法、変更の手続きの中で資料を直す決まり、運用の記録の残し方を説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - 資料が古くなるのは、環境を変える手続きと、資料を直す手続きが別になっているからです。変更の手続きの中に、資料の更新を組み込みます。 - 構成は、実際の環境の記録や、基盤を作るコードから確かめられるようにし、人が描く図は全体を説明するものに絞ります。 - 手順書は1か所に置き、持ち主を決め、別の人が実行して確かめます。障害や変更の記録も、同じ置き場所で後からたどれるようにします。 構成図や手順書を「生きた資料」にするとは、資料が実際の環境と同じ状態に保たれ、担当が替わっても、その資料だけで運用を引き継げる状態にしておくことです。そのためには、資料をきれいに作ることより、環境を変えるたびに資料も一緒に直る仕組みをつくることが大切です。 ## 資料は、なぜ古くなるのか 資料が古くなるのは、環境を変える作業と、資料を直す作業が、別々に行われているからです。急ぎの変更を先に済ませ、資料は後で直すつもりのまま残る、ということがくり返されると、資料と環境の差は広がっていきます。 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) 古い資料は、資料がないより困ることがあります。障害のときに資料を信じて作業し、実際の構成と違っていたために、復旧が遅れるおそれがあるからです。 ## 残しておく資料 クラウドの運用で残しておく資料は、おおむね次のとおりです。すべてを細かく書くより、引き継ぎと障害のときに困らないことを基準に、必要なものから整えます。 | 資料 | 内容 | 主に使う場面 | |---|---|---| | 全体の構成図 | システムの役割、つながる先、データの流れ | 引き継ぎ、変更の影響の確認 | | 設定の一覧 | アカウント、ネットワーク、主な設定の値 | 障害の調査、点検 | | 手順書 | 定期の作業、障害のときの作業、戻す手順 | 日々の運用、障害の対応 | | 連絡先と役割 | 担当、外部の会社、事業者の窓口、判断する人 | 障害のとき | | 変更と障害の記録 | いつ、誰が、何を、なぜ変えたか。障害の経過と対策 | 原因の調査、再発の防止、監査 | 手順書の役割は[ランブック](https://www.ameliatechnology.co.jp/glossary/runbook/)の用語の説明でも整理しています。 ## 構成は、実際の環境とコードから確かめる 設定の値のように細かく変わる情報は、人が書き写すのではなく、実際の環境の記録やコードから確かめられるようにします。 AWS Config は、アカウントの中にどのような資源があり、どう設定されているかを詳しく見られる仕組みです。過去の設定の履歴を残し、問題のあった資源の、直近の正常な設定を確かめることもできます。また、変えようとする資源がほかの資源とどうつながっているかを見て、変更の影響を確かめられる、と説明されています。 出典：[What Is AWS Config?（AWS）](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 基盤をコードで作る方法（[Infrastructure as Code](https://www.ameliatechnology.co.jp/glossary/infrastructure-as-code/)）を使っている場合は、コードそのものが構成の記録になります。Microsoft Azure の Well-Architected は、基盤の変更（設定の変更を含む）は、コードを通じてだけ行う、という厳格な決まりを持つことを勧めています。コードを通さない変更が混ざると、コードと実際の環境がずれていきます。 出典：[Architecture strategies for using infrastructure as code（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/infrastructure-as-code-design) コード化の考え方は、[インフラのコード化（IaC）とは](https://www.ameliatechnology.co.jp/blog/infrastructure-as-code-why/)で説明しています。人が描く全体の構成図は、細部を書き込むより、役割とつながりが分かることを優先します。細部は、上の記録やコードを見に行けばよい形にしておくと、図を直す頻度が下がります。 ## 変更の手続きの中で、資料を直す 資料を生きたままにする決まりは、変更の手続きの中に、資料の更新を入れることです。 同じ AWS の運用の柱は、手順書には期待する結果と、必要な権限や道具、うまくいかないときの対応と連絡先を書き、持ち主を決めて1か所に公開すること、書いたら別の人に実行してもらって確かめること、手順が変わったら変更の手続きに沿って直すことを勧めています。置き場所がまだなければ、変更の履歴を残せる場所（バージョン管理）から始めるとよい、としています。 出典：[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か所（変更の履歴を残せる場所）に置く 変更の申請の書式に「直した資料」の欄を設け、空のままでは変更を終えられないようにするのも、手軽な方法の一つです。 ## 運用の記録を残す 運用の記録は、後から「なぜこうなっているのか」をたどるための資料です。変更の記録には、何を変えたかだけでなく、なぜ変えたかを書きます。理由が残っていないと、後の担当が設定を元に戻してよいのか判断できません。 障害の記録には、経過、影響の範囲、原因、とった対策、残っている課題を書きます。毎月の報告は、その月の変更と障害、監視の傾向、次の月に行うことをまとめ、同じ置き場所に残します。こうした記録は、担当が替わるときの引き継ぎや、上場の準備などで管理の状況を説明するときにも使えます。障害のときの動き方は[障害が起きたときの一次対応](https://www.ameliatechnology.co.jp/blog/cloud-incident-first-response/)で説明しています。 ## 当社のご支援 アメリア・テクノロジーの[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、いまの環境の調査にもとづく構成図と設定の一覧の作成、手順書の整備、変更の手続きに資料の更新を組み込む決まりづくりをご支援しています。運用管理の月額の中で、変更と障害の記録と月次の報告をお渡しします。いまの資料の状況は、無料の[クラウドの自己診断](https://www.ameliatechnology.co.jp/diagnosis/cloud/)でもおおまかに確かめられます。 - クラウド - 運用管理 - 手順書 - ドキュメント ## この記事に出てくる用語 - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Well-Architected Framework](https://www.ameliatechnology.co.jp/glossary/well-architected-framework/) - [運用手順書（ランブック）](https://www.ameliatechnology.co.jp/glossary/runbook/) - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [Infrastructure as Code（IaC）](https://www.ameliatechnology.co.jp/glossary/infrastructure-as-code/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [Git（バージョン管理）](https://www.ameliatechnology.co.jp/glossary/git/) - [監視](https://www.ameliatechnology.co.jp/glossary/monitoring/) この記事を書いた人 [石田誠](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/living-architecture-docs/