サーバー・サービス構成を1枚にまとめる方法
「このサービス、どのサーバーで動いてたっけ」 「このサイトのDB、あのサーバーと同居だったか、別だったか」 ——障害の夜や、久しぶりに触る改修のとき、まずこの思い出し作業から始まっていませんか。
構成が頭の中にしかない状態は、めずらしくありません。作った人がいないシステムを引き継いだ、いつのまにかサーバーもサービスも増えた、ドキュメントを作る時間なんてなかった。どれも、日々の対応に追われていれば当たり前に起きることです。あなたの整理が下手なわけではありません。
足りないのは、精密なネットワーク図ではありません。「何が・どこで動いていて・どこにつながっているか」がひと目で分かる1枚です。今日は、その1枚に何を書けばいいか、一緒に決めていきましょう。全部を一度に描かなくて大丈夫です。
結論：構成情報は、いきなり正確な図を目指さなくていいです。まずは「①サーバー一覧 ②サービス一覧（どのサーバーで動くか） ③つながり（サービス→DB・外部連携） ④入口（ドメイン・SSL・DNS） ⑤依存する外部サービス」を1枚に書き出す。表と、簡単な矢印のメモで十分です。障害調査と改修の影響範囲がぐっと追いやすくなります。
環境や規模（サーバーの数、クラウドかオンプレか、コンテナ利用の有無）で最適な形は変わります。本文はあくまで一例として、自分の現場に読み替えながら、続けられる軽さを優先してください。
何が起きているか：構成が頭の中だけだと「思い出す時間」で消耗する
構成情報がまとまっていないと、いちばん困るのは「範囲を確かめたいとき」です。
- 障害中に「このサービスが落ちると、他のどこに影響するか」がすぐ分からない
- 改修の前に「このDBを触ると、どのサイト・バッチが使っているか」を追いきれない
- サーバー移行やバージョンアップで「このサーバーに何が同居しているか」の棚卸しから始まる
- 自分が休んだ日・辞めた後に、全体像を知る人がいなくなる
つまり、構成が頭の中にあるだけだと、「思い出す・調べ直す」作業が毎回発生する状態です。これは能力の問題ではなく、全体像の置き場所がないだけの問題です。そして困るのは、いちばん余裕のない障害の夜や、影響を読みたい改修の直前だったりします。
具体例：1枚があるときと、ないとき
同じ「深夜にサイトが落ちた」でも、1枚があると景色が変わります。
構成の1枚がないとき：どのサーバーの問題か当たりをつけるのに、管理画面を順にたどり、設定ファイルを開き、「このサイトのDBはどこだったか」を調べ直す。原因にたどり着く前に、構成の確認で時間が溶ける。
構成の1枚があるとき：1枚を開けば、落ちたサービスがどのサーバーで動き、どのDBと外部連携につながっているかが並んでいる。影響範囲の見当がすぐつき、調べる場所を絞って初動に入れる。
差を生んだのは知識量ではありません。「全体のつながりが1か所に描いてあったか」だけです。
1枚に書く5つの要素（これだけで影響範囲が追える）
まずはこの5つを見出しにして、分かるところから書きます。正確な図でなく、表と矢印のメモで十分です。
- サーバー一覧：サーバー名（ホスト名）／役割（Web・DB・バッチ等）／稼働環境（OS・主要ミドルウェアとバージョン）／置き場所（クラウド名・リージョン、またはオンプレの所在）。「これが止まると何が動かなくなるか」まで書けると、優先度の判断に効きます。
- サービス一覧：動いているサービス・サイト・アプリ名／それがどのサーバーで動くか／利用者・関係部署。1台に複数が同居していることも多いので、「サーバー↔サービス」の対応をはっきりさせます。
- つながり（依存関係）：サービスから、DB・キャッシュ・ファイルストレージ・バッチへの矢印。「AサービスはBのDBを見ている」「この処理は夜間バッチが前提」など、壊すと連鎖するつながりをメモします。ここが影響範囲調査の要です。
- 入口（ドメイン・DNS・SSL）：公開ドメイン／DNSの管理元／SSL証明書の管理元と更新時期／ロードバランサやCDNの有無。「利用者はどこから入ってくるか」を上流から並べます。
- 依存する外部サービス：決済・メール送信・外部API・SaaS・監視サービスなど、止まると自分たちも影響を受ける外部連携。連絡先や契約先も添えておくと、障害の切り分けで「相手側の問題か」を早く判断できます。
余裕があれば、これらを線でつないだ簡単な構成図（1枚）を足すと、口頭説明や引き継ぎがぐっと楽になります。ただし最初は上の表とメモで十分です。きれいさより「今の実態と合っていること」を優先してください。
そのまま使えるテンプレート
テキストや表計算1ファイルなら、この見出しをコピーして埋めるだけで始められます。
# 〇〇システム 構成一覧（最終更新: 2026-07-04 / 記入者: 自分）
## 1. サーバー一覧
| ホスト名 | 役割 | OS・主要ミドル(版) | 置き場所 | 止まると困ること |
|----------|------|--------------------|----------|------------------|
| | | | | |
## 2. サービス一覧（どのサーバーで動くか）
| サービス/サイト名 | 稼働サーバー | 利用者・関係部署 | 備考 |
|-------------------|--------------|------------------|------|
| | | | |
## 3. つながり（依存関係）
- （例）Aサービス → DB: db01 / キャッシュ: redis01 / 夜間バッチ: batch01
- （例）B処理 → 外部API: 〇〇決済
## 4. 入口（ドメイン・DNS・SSL）
- 公開ドメイン /
- DNS 管理元 /
- SSL証明書（管理元・更新時期） /
- LB・CDN の有無 /
## 5. 依存する外部サービス
| 外部サービス | 用途 | 契約先・連絡先 | 止まると起きること |
|--------------|------|----------------|--------------------|
| | | | |大事なのは、体裁のきれいさより「今動いている実態」を、分かるところから埋めること。全部そろっていなくても、サーバーとサービスの対応が入った時点で、もう十分に役立ちます。
影響：たった1枚が、障害・改修・移行を助ける
この1枚があると、いざというときの景色が変わります。
- 障害の切り分けが速くなる：落ちたサービスの影響範囲と依存先が見えるので、調べる場所を絞れる。
- 改修の影響範囲を読みやすい：「このDB・このサーバーを触ると、どこに波及するか」を先に確認できる。
- 移行・バージョンアップが楽になる：同居サービスや依存関係の棚卸しが、最初から1枚で済む。
- 引き継ぎ・相談がしやすい：全体像を1枚見せれば、「何がどこで動いているか」を短時間で共有できる。
構成の1枚は、評価のためや形式のために作るものではありません。いちばん助かるのは、次に影響範囲を追う人——多くの場合、未来のあなた自身です。
続けるコツ：完璧な図を目指さず「1枚から育てる」
構成ドキュメントが続かない一番の理由は、「正確できれいな構成図を一気に描こう」として力尽きることです。だから、軽く始めて少しずつ育てます。
- 表とメモから始める：作図ツールにこだわらない。まずテキストや表計算で「サーバー↔サービス↔つながり」を書く。図は後からで十分。
- 調べたついでに書き足す：障害調査や改修で構成を確認したとき、その場で1行・1本の矢印を足す。実際に追った関係から埋めると、使える1枚になる。
- 最終更新日と記入者を書く：構成は変わります。古いか新しいかが分かるだけで、信頼して使える。
- 触ったら直す：サーバーやサービスを増減したら、そのときに直す。定期棚卸しより「変えたら直す」のほうが続きます。
「正確な構成図」より「今の実態が分かる1枚」。空欄や不確かな矢印があっても、全体像が1か所にあるだけで前に進みます。
明日やること
- 構成一覧の置き場所を1つ決める（テキスト or 表計算1ファイル）
- 「サーバー一覧」と「サービス一覧（どのサーバーで動くか）」だけ先に埋める
- 主要なサービスから、DB・外部連携への矢印を数本だけメモする
- 先頭に「最終更新日・記入者」を書く
今日のチェックリスト
- 構成一覧の置き場所を1つに決めた
- サーバー一覧（役割・環境・置き場所）を書いた
- サービスとサーバーの対応（どこで動くか）を書いた
- 主要サービスの依存（DB・外部連携）を矢印でメモした
- 入口（ドメイン・DNS・SSL・LB/CDN）を書いた
- 依存する外部サービスと連絡先を書いた
- 最終更新日と記入者を書いた
最初の1枚は、たぶん「サーバーとサービスの対応」と「主要な依存の矢印」だけで十分です。その1枚が、次の障害の夜や、影響範囲を読みたい改修の日のあなたを助けてくれます。正確な構成図じゃなくていい。全体像を置いておく場所を、今日ひとつ作っておきましょう。
よければ、こちらも
保守運用の実務ヒントを、メールでお届けしています。よかったら受け取ってください。