サーバー、クラウド、アプリケーション、データ、外部サービスの一覧を作っても、障害や変更の場面で「この停止は誰に影響するのか」「この更新で何が変わるのか」をすぐ答えられないことがあります。登録件数を増やすことが目的になり、サービスとの関係、情報の鮮度、判断への使い方が置き去りになるためです。

PeopleCertが示すITIL 4 Service Configuration Managementの要点は、サービスと構成アイテムについて、必要な時に正確で信頼できる情報を提供することです。公式教材の説明でも、構成データを価値ストリームへ統合し、変更、運用、関係者との連携に使うことが重視されています。構成管理データベースを整備すること自体がゴールではありません。

本記事では、構成情報を完全な「社内百科事典」にするのではなく、経営者、IT責任者、サービス担当者が影響を判断し、変更を進め、復旧や改善につなげるための実務基盤として整える方法を解説します。

課題：登録は増えたのに、判断に使えない

第一の課題は、対象範囲が曖昧なことです。発見できる機器やソフトウェアをすべて登録しようとすると、管理対象は急速に増えます。一方で、どのサービス、利用者、業務に関係するかが記録されていなければ、障害時の影響範囲や変更の優先順位は判断できません。

第二の課題は、情報源と更新責任が分散していることです。クラウド管理画面、資産台帳、監視、契約管理、開発リポジトリ、担当者の資料に異なる情報が残り、どれを正とするか決まっていないと、更新作業が人手の照合作業になります。登録値が古いと分かれば、現場は台帳を参照せず、詳しい人へ聞く運用へ戻ります。

第三の課題は、構成情報を使う場面が設計されていないことです。変更申請、インシデント、問題管理、脆弱性対応、監査で参照されなければ、誤りが見つからず、改善の優先順位も生まれません。正確さを求めるほど入力負担だけが増え、利用価値との均衡を失います。

考え方：構成情報を「記録」から「判断の地図」へ変える

構成情報は、モノの一覧ではなく、サービスを支える要素と関係を示す地図として考えます。重要なのは、すべての属性を持つことではなく、特定の判断に必要な情報が、必要な鮮度と信頼度で取り出せることです。

NIST Cybersecurity Framework 2.0は、組織が管理するハードウェア、ソフトウェア、サービス、システムの棚卸しをIdentify機能の資産管理に位置づけています。NIST SP 800-128も、構成ベースラインを定め、変更を管理し、実際の状態を継続的に監視する考え方を示しています。ここから得られる実務上の示唆は、初回登録の正しさだけでなく、変更後の実態と記録の差を見つけ、修正できる仕組みが必要だということです。

CISAのBOD 23-01は米国連邦政府機関向けの指令であり、日本企業へ直接適用されるものではありません。ただし、資産の可視化はそれ自体が目的ではなく、更新、構成管理、脆弱性対応などの基礎になるという説明は、民間組織が構成情報の利用目的を考える際にも参考になります。

実践手順：サービス判断を速める5ステップ

1．対象サービスと判断場面を一つに絞る

最初に、事業上重要なサービスを一つ選びます。次に「重大障害の影響判定」「本番変更のリスク評価」「緊急脆弱性の対応範囲」など、構成情報を使う判断場面を一つか二つに絞ります。全社資産を一度に完全化するより、使う場面が明確な範囲から始めた方が必要項目を決めやすくなります。

サービス責任者、運用、開発、セキュリティ、調達などの関係者と、判断に答えるべき問いを列挙します。例えば「停止時に影響を受ける業務と利用者は誰か」「代替経路はあるか」「外部事業者への連絡が必要か」です。問いに使わない項目は、初期範囲から外す選択も必要です。

2．最小限の構成モデルと関係を定める

サービス、アプリケーション、データストア、実行基盤、ネットワーク、外部サービス、責任者を主要な構成アイテムとして整理します。各要素を細かく分解する前に、「支える」「接続する」「依存する」「所有する」といった関係を定義します。影響判断では、属性の多さより関係の追跡可能性が重要です。

各構成アイテムには、一意の識別子、名称、種別、ライフサイクル状態、サービスとの関係、責任者、正本となる情報源、最終確認日時を最低限持たせます。機密性や重要度など判断に必要な属性は追加しますが、入力できるからという理由だけで項目を増やしません。

3．情報源、責任者、鮮度を決める

項目ごとに正本を決めます。クラウド資源はクラウド側の管理情報、アプリケーション責任者はサービス管理台帳、契約期限は契約管理など、既存の仕組みを尊重します。同じ値を複数の場所で手入力せず、可能な範囲で参照または同期します。

自動発見の結果も無条件に正しいとは限りません。短時間だけ存在する資源、名称の揺れ、権限不足で見えない領域、外部サービスは別の確認が必要です。最終確認日時と情報源を表示し、未確認、推定、担当者確認済みなど信頼度を区別すると、利用者は前提を理解して判断できます。

4．変更・障害・脆弱性対応の流れへ組み込む

変更を計画するときは、対象構成だけでなく、上流・下流の依存先、利用者影響、監視、切り戻し対象を構成情報から確認します。実施後は、実際に変わった状態を更新し、計画との差を記録します。緊急変更でも後追い更新の期限と責任者を残します。

インシデントでは、影響を受けたサービスと依存関係を特定し、復旧後に誤っていた関係や不足項目を修正します。脆弱性対応では、該当製品が存在するかだけでなく、外部公開、重要サービスとの関係、代替策、所有者を確認します。実際の利用場面を、構成情報の品質を高める検証機会として使います。

5．登録件数ではなく、判断への貢献を測る

指標は、登録率だけにしません。重要サービスの関係がたどれる割合、変更後に期限内で更新された割合、重大インシデントで所有者を特定できたか、構成情報の誤りで調査が止まった件数など、判断の速度と品質に関係する指標を選びます。

誤りが見つかったら個人の入力ミスだけで終わらせず、情報源、同期、責任分担、変更フローを見直します。使われない属性は削り、繰り返し確認される情報は自動取得や定期照合へ移します。利用と修正の循環があることで、構成情報は現場に信頼される判断基盤へ近づきます。

注意点：完全性を追いすぎない

  • すべてを同じ粒度で管理しない：事業影響と判断頻度に応じて、重要サービスほど関係と鮮度を詳しくします。
  • CMDBを唯一の正本にしない：項目ごとに既存の正本を決め、CMDBは判断に必要な関係を統合する役割として使います。
  • 自動発見を過信しない：技術的に見える資産と、契約・責任・事業上の重要性は別の確認が必要です。
  • アクセス権を広げすぎない：ネットワーク構成、脆弱性、委託先情報などは、業務上必要な範囲で閲覧・出力を制御します。
  • 更新負担を現場だけへ寄せない：変更や配備の仕組みから自動更新し、人が確認すべき例外を明確にします。

最初の30日で作るべき成果物

最初の週に対象サービスと判断場面を選び、答えるべき問いを一枚にします。二週目に、サービスを支える主要な構成アイテムと関係を簡単な図へ描き、識別子、責任者、情報源、確認日を整理します。三週目に、直近の変更または障害を使って影響をたどり、不足や誤りを記録します。四週目に、変更記録、監視、クラウド管理情報などから更新できる項目を決め、責任と見直し頻度を定めます。

最初の成果物は巨大な台帳ではありません。対象サービスの構成モデル、情報源・責任表、判断場面ごとの確認手順、品質課題一覧、改善バックログがそろえば、次のサービスへ展開するための実践的な型になります。

まとめ

構成情報の価値は、登録件数や項目数ではなく、変更、障害、脆弱性対応で必要な判断を支えられることにあります。対象サービスと判断場面を絞り、最小限の関係を定め、情報源と鮮度を示し、日常の価値ストリームへ組み込み、判断への貢献から改善する。この循環によって、構成管理は保守されない台帳から、サービス運営の地図へ変わります。

FourthWallは、サービス単位の構成モデル、CMDBの適用範囲、情報源と責任分担、変更・インシデント・脆弱性対応との接続、品質指標、段階導入の設計を支援します。最初の一歩は、全資産を数えることではなく、重要なサービス一つについて「どの判断を、どの構成情報で速くするか」を決めることです。

参考資料

本記事は公開資料に基づく一般的な情報提供を目的とし、個別の経営判断、監査、法務、契約、個人情報保護、セキュリティに関する専門的助言ではありません。実際の構成管理範囲、記録項目、アクセス権、保存期間、自動収集、委託先との役割分担は、事業目的、契約、法令、社内規程、システム特性を踏まえ、関係する専門家と確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る