2026-02-13

システム変更前に影響範囲を可視化して本番障害と計画外ダウンタイムを防ぐ方法

システムの設定変更やバージョンアップを行ったあと、まったく関係ないと思っていた別のシステムが止まる。こうした予期しない障害は、変更作業そのものが悪いのではなく、影響範囲を事前に把握できていないことが根本原因です。構成情報はIT資産管理台帳に、過去の障害記録はインシデント管理ツールに、変更の申請履歴はまた別のシステムに散在しており、変更計画の段階でこれらを横断的に突き合わせる仕組みがないまま作業が進んでいるケースが大半です。

この記事は、従業員100〜1,000名規模の企業で、情シス部門やインフラ運用チームのリーダーとして変更管理を担当している方を想定しています。読み終えると、変更申請から影響範囲の特定、リスク判定、実施後の記録までを一本のワークフローとしてつなぎ、変更起因の本番障害を大幅に減らすための具体的な手順が分かります。大規模エンタープライズ向けのITIL全プロセス導入や、個別ツールの網羅的なレビューは扱いません。

なお、本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、変更申請が起票されてから影響範囲の自動照会とリスク判定を経て実施に至るまでの運用フローを、自社に当てはめて設計できる状態になります。

Workflow at a glance: システム変更前に影響範囲を可視化して本番障害と計画外ダウンタイムを防ぐ方法

Step 1: 変更対象を指定して影響範囲を自動照会する (ServiceNow) (ワークフローシステム)
Step 2: 過去の障害履歴を照合してリスクレベルを判定する (ServiceNow × Confluence)
Step 3: 変更実施後の結果を記録し次回の判定精度を上げる (ServiceNow × Confluence)

なぜシステム変更のたびに想定外の障害が起きるのか

構成情報と依存関係が別々に管理されている

多くの現場では、サーバーやネットワーク機器の台帳はExcelやIT資産管理ツールに、システム間の連携情報は担当者の頭の中や個別のドキュメントに存在しています。たとえばサーバーAのOS更新を計画するとき、サーバーAに接続しているミドルウェアやAPI連携先の一覧をすぐに引き出せる状態にはなっていません。結果として、変更担当者は自分の知っている範囲だけで影響を判断し、見落としが発生します。

過去の障害パターンが変更計画に反映されない

過去に同じような変更で障害が起きていたとしても、その記録はインシデント管理ツールの中に埋もれています。変更を計画する担当者がインシデント管理ツールを検索して過去事例を調べる運用ルールがなければ、同じ失敗を繰り返します。特に担当者が交代した直後は、属人的な経験値がリセットされるため、障害の再発リスクが跳ね上がります。

変更承認がレビューではなく形式的な押印になっている

変更管理プロセスが存在していても、承認者がリスクを判断するための材料が揃っていなければ、承認は形だけの作業になります。影響を受けるシステムの一覧、過去の類似障害、想定されるリスクレベルといった情報が変更申請に添付されていない限り、承認者は実質的にゴム印を押しているだけです。

重要な考え方：変更申請の時点で構成情報と障害履歴を自動で突き合わせる

変更管理の品質を上げるために最も効果的なのは、変更申請が起票された瞬間に、関連する構成情報と過去の障害履歴が自動的に集まる仕組みを作ることです。人の注意力や記憶に頼る運用は必ず破綻します。

構成情報データベースを変更管理の起点にする

IT資産管理ツールに登録されたサーバー、ネットワーク機器、アプリケーション、そしてそれらの間の依存関係を、変更管理の起点として使います。変更対象のサーバーを指定すれば、そのサーバーに依存しているシステムの一覧が自動で表示される状態を目指します。これはCMDB（構成管理データベース）と呼ばれる考え方で、要するにシステム同士のつながりを地図のように記録したデータベースです。

過去の障害パターンを変更リスクの判定材料にする

変更対象と同じシステム、同じ種類の変更で過去に障害が起きていないかを自動検索し、変更申請に添付します。これにより、承認者は過去の失敗パターンを踏まえた判断ができるようになります。

判定結果を人が確認する最終チェックポイントを残す

自動で集めた情報をもとに、最終的には人がリスクを判断して承認する流れを崩してはいけません。ツールが出した影響範囲の一覧を鵜呑みにするのではなく、構成情報の登録漏れがないか、最近追加された連携がないかを承認者が確認するステップを明示的に設けます。

変更申請から実施・記録までの実践ワークフロー

ステップ 1：変更対象を指定して影響範囲を自動照会する（ServiceNow）

変更担当者がServiceNow上で変更申請を起票し、変更対象のCI（構成アイテム、つまりサーバーやアプリケーションなどの管理単位）を指定します。ServiceNowのCMDB機能が、指定されたCIに依存している他のCI、つまり上流・下流の接続先を自動的にリストアップします。

具体的には、変更申請フォームの変更対象フィールドにCIを入力すると、依存関係マップが表示されます。たとえば基幹システムのDBサーバーを変更対象に指定した場合、そのDBに接続している業務アプリケーション、バッチ処理、外部連携APIの一覧が自動で表示されます。この一覧が影響範囲の第一次リストになります。

担当者はこのリストを確認し、CMDB上に登録されていない非公式な連携がないかを関係者にヒアリングで補完します。この作業は変更申請の起票から1営業日以内に完了させるルールにします。

ステップ 2：過去の障害履歴を照合してリスクレベルを判定する（ServiceNow × Confluence）

ステップ1で特定した影響範囲のCIに関連する過去のインシデント記録を、ServiceNowのインシデント管理モジュールから自動検索します。過去12か月以内に同じCIで発生した障害、同じ種類の変更（たとえばOSパッチ適用）で発生した障害を抽出し、変更申請に自動リンクします。

同時に、Confluenceに蓄積されたポストモーテム（障害の振り返り記録）や変更手順書のナレッジベースを検索し、過去の教訓や注意事項を変更申請のコメント欄に転記します。たとえば、半年前に同じDBサーバーのパッチ適用でバッチ処理が停止した記録があれば、その原因と対策がConfluenceのページとして参照できる状態にします。

これらの情報をもとに、変更のリスクレベルを3段階（低・中・高）で判定します。判定基準の例は以下のとおりです。

低リスク：影響を受けるCIが3つ以下、過去12か月に同種の障害なし
中リスク：影響を受けるCIが4〜10、または過去12か月に同種の障害が1件
高リスク：影響を受けるCIが11以上、または過去12か月に同種の障害が2件以上

リスクレベルに応じて承認フローを分岐させます。低リスクはチームリーダー承認、中リスクは部門マネージャー承認、高リスクは変更諮問委員会（CAB）での審議を必須とします。

ステップ 3：変更実施後の結果を記録し次回の判定精度を上げる（ServiceNow × Confluence）

変更作業が完了したら、ServiceNow上で変更申請のステータスを完了に更新し、実施結果（成功・一部障害あり・ロールバック）を記録します。障害が発生した場合は、インシデントチケットと変更申請を紐づけます。

変更の結果、新たに判明した依存関係や注意事項があれば、CMDBの依存関係情報を更新し、Confluenceのナレッジベースにポストモーテムを追記します。この記録が次回以降の変更申請時にステップ2で自動参照されるため、判定精度が回を重ねるごとに向上します。

月次で変更管理レポートを作成し、変更件数、リスクレベル別の内訳、変更起因の障害件数を集計します。この数値を追跡することで、ワークフロー全体の改善効果を定量的に把握できます。

この組み合わせが機能する理由

ServiceNow：構成管理と変更管理とインシデント管理を一つのプラットフォームで連携できる

ServiceNowを選ぶ最大の理由は、CMDB、変更管理、インシデント管理が同一プラットフォーム上にあるため、データの突き合わせにツール間連携の開発が不要な点です。変更申請からCIの依存関係マップを参照し、同じCIに紐づくインシデント履歴を検索する操作が、追加のAPI開発なしに標準機能で実現できます。

一方で、ServiceNowは導入コストと学習コストが高めです。ライセンス費用は企業規模によって大きく変わるため、事前に見積もりを取る必要があります。また、CMDBの初期データ投入には相応の工数がかかります。自動ディスカバリ機能（ネットワーク上の機器を自動検出する機能）を使えば物理・仮想サーバーの登録は効率化できますが、アプリケーション間の論理的な依存関係は手動で登録する部分が残ります。最初から完璧を目指さず、主要システム50〜100件の登録から始めて段階的に拡充する進め方が現実的です。

Confluence：障害の教訓と変更手順を検索可能なナレッジとして蓄積できる

Confluenceを選ぶ理由は、ポストモーテムや変更手順書をチーム全体で編集・検索できるナレッジベースとして運用しやすい点です。ServiceNowのインシデント記録は構造化されたデータとして優れていますが、障害の根本原因分析や再発防止策といった文脈のある情報は、Wikiスタイルのドキュメントのほうが記述しやすく、読みやすくなります。

Confluenceの弱点は、情報が増えるにつれて検索精度が下がりやすいことです。対策として、ポストモーテムのテンプレートを統一し、変更種別やCI名をラベルとして必ず付与するルールを設けます。これにより、ステップ2でCI名や変更種別をキーワードにして関連ナレッジを検索する際の精度が保たれます。

ServiceNowとConfluenceの連携は、ServiceNowの変更申請画面にConfluenceページへのリンクを貼る運用で十分です。API連携で自動リンクを実装することも可能ですが、まずは手動リンクから始めて運用を定着させることを優先します。

Recommended tool list

Tool	Role	Pricing	Implementation time	Notes
ServiceNow	構成管理・変更管理・インシデント管理の統合プラットフォーム	要問い合わせ	2〜4か月（CMDB初期登録含む）	ITSM（IT Service Management）モジュールを利用。CMDBの初期データ投入が最大の工数。自動ディスカバリで物理・仮想サーバーを検出し、アプリケーション間の論理依存関係は手動登録で補完する。主要システム50〜100件から段階的に拡充する進め方を推奨。
Confluence	障害の振り返り記録と変更手順書のナレッジベース	無料枠あり	1〜2週間	ポストモーテムテンプレートを作成し、変更種別・CI名をラベルとして統一運用する。ServiceNowの変更申請画面からConfluenceページへリンクを貼る運用から開始し、必要に応じてAPI連携を追加する。