構成管理とは？IT資産管理との違いと台帳の作り方

構成管理は続ける仕事、CIは対象、CMDBは記録を置く仕組み

台帳を作っただけでは、構成管理が続いているとは限りません。登録する対象を決め、変更の扱いを決め、状態と履歴を記録し、記録と根拠を照合する仕事までつなぎます。設定を自動適用することや、ソースコードの版を管理することも関係する場合がありますが、それだけで構成管理全体を表すわけではありません。

IT資産管理と構成管理は、対象も情報も重なる

同じサーバーについて、IT資産管理では利用者、契約、保守、更新・廃棄などを確認し、構成管理ではどのアプリが動き、どのサービスに関係するかを確認する場面があります。ただし、IT資産管理を財務情報だけと決めたり、資産台帳には関係が一切ないと断定したりはしません。製品や組織によって情報は連携し、CMDBを含む仕組みもあります。

また、一つの物理機器と一つのCIが必ず対応するわけではありません。業務上のサービス、アプリ、仮想環境など、目的に合わせて区別する単位が変わります。手元の全資産を無条件で登録する前に、何の問い合わせや変更判断に使うかを決めましょう。

IBMの公式解説は、構成の識別、変更の制御、状態・履歴の記録、照合を説明し、CMDBを支える仕組みの一つとして扱っています。IT資産管理の解説でも、ライフサイクルや契約・棚卸情報と、CMDBなどの機能が説明されています。ここでは役割の違いと重なりの参考にし、特定製品の導入や効果を勧めていません。IBM：構成管理／IBM：IT資産管理

図で見る問い：機器名が分かる一覧に、どんな関係を加えると、照会サービスの確認先へ近づけるでしょうか。一覧の名前と、サービス・アプリ・動作先を結ぶ意味を見てください。

この解説図を原寸で見る

図の読み方：一覧は対象を探す入口です。関係には「利用する」「動作する場所」などの意味を添え、根拠がある範囲をたどります。線が描かれているだけで、全依存先や変更の影響が分かったことにはしません。次の節で、対象を一つのサービスに絞ります。

台帳の項目を増やす前に、一つのサービスと判断目的を決める

直前の一覧と関係の図も使い、名前を集める目的と、根拠がある関係の意味を確かめてください。

この例の目的は、変更時に、照会サービスに関係する確認先と資料を探すことです。障害時の確認先を探すのか、変更前に関係する資料をそろえるのかで、必要な対象と関係の粒度は変わります。「全てを管理する」だけでは、どこまで調べ、誰が維持するかを決めにくくなります。

最初の登録候補は、照会Webアプリ、業務用仮想サーバー、照会データベースです。候補に挙げたことと、実際の依存関係を確認したことは別です。会計・給与システムは今回の記録対象外。依存なしを確認した意味ではない。外部サービスなどの依存先全体も未確認です。

名前だけでなく、線の意味と根拠を記録する

次の関係は、架空の資料に書かれた内容を照合する例です。線はネットワーク接続やデータの流れを一律に表しません。「利用する」と「動作する場所」では、確かめる資料も相手も違います。実環境での確認結果は補いません。

データベースの現状は、下の資料照合で未確認のまま扱います。候補の名前を、確認済みの線としてこの図へ追加しません。自社ではサービス名や対象を識別できる情報と、関係ごとの根拠・確認時点を残し、同名の別環境や別用途を結ばないようにします。

登録する単位と、対象外の理由を決める

一つのサービスを複数のアプリが支える場合や、一つの基盤を複数サービスが使う場合があります。業務上の識別名と本番・検証などの環境をそろえ、変更や問い合わせを分けて扱える粒度を選びます。資料の一行が違うだけで別物と増やしたり、名前が同じだから同一と統合したりしないでください。

目的に関係する対象から始め、何を対象外としたか、その理由も記録します。対象外にした要素が、将来も不要・接続なし・安全と分かったわけではありません。共有基盤や委託先の範囲が不明なら、必要な資料と確認先を残します。

台帳には、識別・関係・根拠・確認時点・更新担当をつなぐ

項目名をそろえるだけでなく、その値をどこから得て、誰が確かめ直せるかを残します。この例では、照会Webアプリを本番環境の対象として識別し、根拠と確認時点を付けます。下の日時は架空の資料を説明するための値で、実サービスの調査日ではありません。

名前・環境・版は、同じ対象を探す手掛かりにする

同じアプリ名でも、本番と検証、旧版と現行版では確認する内容が違います。組織内の識別子がある場合はその識別子へ結び付け、記録を探す名前と技術側の識別が食い違わないようにします。記事の表記を、そのまま自社の必須命名規則にはしません。

版が未取得なら推測で埋めず、参照する管理画面や承認済みの資料を誰へ確認するかを残します。実ホスト名や私設IP、顧客情報、認証情報を社外の相談や画像へそのまま出す必要はありません。共有範囲と閲覧権限を分けてください。

値の情報源と、更新・確認の役割を分ける

自動収集、設計資料、保守窓口の回答、現状を確認した記録は、同じ情報を同じ時点で表すとは限りません。属性ごとに情報源を付けると、名前は資産台帳、実行中の版は別の確認記録、関係は担当者の確認資料という違いを追えます。全属性で最新の一資料を正しいものと決める方法にはしません。

入力・更新する人、技術的内容を確認する人、必要な業務側の確認先も整理します。担当案を書いただけでは本人が了承した状態になりません。更新をどの仕事で行い、誰が記録と根拠の整合を確かめるかを、役割と連絡先へ具体化します。

図で見る問い：照会Webアプリの一行を、何の資料で、いつ、誰が確かめるのでしょうか。対象の記録と、根拠の資料・確認時点・更新する役割のつながりを見てください。

この解説図を原寸で見る

図の読み方：構成要素の名前と、確認に戻れる資料を対応させます。未取得の版や担当の了承は、記入済みにしません。図だけで全項目を読ませず、直前の全文例と合わせて、確認先と次に必要な資料を決めてください。

資料が食い違ったら、日付だけで現在の値を決めない

移行計画に書かれた接続先は、実際に切り替わった接続先の証拠とは限りません。ここで照合する属性は、照会Webアプリが参照するデータベースです。二つの資料が違う対象・環境・期間を指していないかを、値の新旧を選ぶ前に確かめます。

同じ属性について、根拠・対象・時点を合わせる

まず資料の対象アプリと環境、属性の意味、書かれた時点と実施予定の時点を確認します。そのうえで、実施記録や現在の設定を確認できる承認済みの記録など、現状の根拠を担当へ求めます。計画案、承認の記録、実作業の記録、観測した状態を同じ証拠として扱わないでください。

現状がまだ分からない間は、二つの値と各資料、食い違う属性、確認先を残します。古い行を破壊して新しい案へ置き換えたり、未確認を「接続なし」にしたりはしません。同名の重複が疑われる場合も、識別条件を確かめてから、統合する範囲と履歴の残し方を決めます。

自動収集の情報だけでは、分からない関係もある

AWS Configの公式資料では、構成アイテムは対応するAWSリソースのある時点の属性を表し、関係情報にも範囲があります。特に、その関係欄はネットワークやデータフローの依存関係を含まず、アプリ構成を表すように自由に変更できるものではない、と説明されています。これはAWS Config固有の仕様で、全てのCMDBの制約ではありません。AWS Config：構成アイテムの構成要素

利用する仕組みが何を収集し、何を収集しないかを確かめ、業務サービスとの関係は別の資料や担当の確認で補う必要があるかを判断します。自動で得たデータを捨てるという意味ではなく、取得できた範囲と未確認を分けて使うためです。

図で見る問い：構成メモと移行計画で接続先が違うとき、何を追加で確かめるのでしょうか。二つの資料、現状確認の未確認、確認する担当の関係を見てください。

この解説図を原寸で見る

図の読み方：計画案の値を、実施済みの現在値へ移しません。同じ対象・属性・時点かを確かめ、実施記録や現状の根拠を確認先へ求めます。次の節の予定変更の例も、実施・更新・照合が済んだ結果ではありません。

予定・承認・実施・現状確認・台帳更新を、それぞれの記録で追う

直前の資料照合の図で、計画案と現状確認を分けて見てください。ここでは別に、照会アプリの動作先を変更する案を扱います。提案があるだけで、変更が承認されたり、実行されたり、影響がなかったりしたことにはなりません。

変更前は、影響を調べるための材料と判断先をそろえる

対象の構成要素、関係するサービス、変更する属性、確認済みの関係と未確認を、変更相談の資料へ結び付けます。共有する要素があるなら、その要素に関係する担当やサービスも調べる必要があります。台帳の線が網羅的だと確認できていなければ、「他へ影響なし」と結論付けません。

変更を実施してよいかは、組織の権限、変更管理、契約や業務上の条件に沿って判断する仕事です。台帳の作成者が、記入しただけで承認者になるわけではありません。現在の資料が不十分な場合、必要な調査範囲と確認先を明らかにして判断側へ返します。

変更後は、実施記録と確認した状態を台帳へ結び付ける

実作業の報告が届いたら、変更した対象と属性、実施内容、実際に確認した状態を照合します。台帳にはその根拠と確認時点を結び付け、更新した人と必要な確認をたどれるようにします。「作業完了」という連絡だけで、全関連情報の更新・照合が完了したとは扱いません。

予定と違う状態や、確認できない属性が残った場合は、未解決の内容と確認先を残します。台帳上の値だけを都合よくそろえて、実際の確認を終えたことにはしません。旧状態の記録は当時の根拠として履歴へ残し、現行として参照する記録と区別します。

更新するきっかけと担当を、普段の仕事に組み込む

作成時の一斉入力だけに頼ると、その後の変更で記録が古くなります。導入・設定変更・移行・契約や担当の変更・停止や廃止など、自社で記録に影響する仕事へ更新を結び付けます。定期確認も必要な範囲で組み合わせますが、一律の頻度を記事の例から決めるものではありません。

属性ごとの情報源と、変更後に確認する人を決める

誰が何の情報を更新し、どの根拠で確認し、食い違いがあれば誰へ返すかを、少数の対象で試します。自動収集と手入力の優先順位も、組織で定めた属性ごとの根拠に沿って扱います。仕組みの更新時刻が最新だからといって、その値が業務上の現状に最も正しいとは限りません。

ServiceNowの社員による専門家FAQも、目的に役立つ対象へ絞ること、情報源の限界や重複・正確さを確認することを説明しています。ここでは考え方を参考にし、特定製品の識別・統合機能や導入手順を全組織の必須方法へ移していません。ServiceNow：CMDBの専門家FAQ

試すのは「埋まったか」だけでなく、目的の判断へたどれるか

例えば、照会アプリの変更相談を受けた担当が、対象を識別し、関係と根拠、未確認、回答先を探せるかを確かめます。見つからない資料、同名で区別できない対象、担当案のまま止まる仕事があれば、必要な範囲を直します。登録件数だけで、実態との一致や変更判断の安全を測ったことにはしません。

役割の交代やサービスの廃止時は、現行として参照する対象と、過去の履歴を区別します。廃止したと報告された要素を、関係や契約を確かめず消したり、過去の記録を現在の構成として残したりしないようにします。保存期間やアクセス権は、社内の運用と情報管理の条件を確かめて決めてください。

日々の仕事の開始・判断・完了・例外を、担当者が使える資料へ組み立てる説明は、運用設計書の項目と作り方で扱っています。本稿は、構成要素と関係、根拠、状態を記録して照合する仕事を中心に説明しています。

まとめ：一つのサービスを、関係・根拠・更新の仕事へ結ぶ

構成管理は、機器名を増やすことだけではありません。何の判断に使うかを決め、必要な構成要素を識別し、関係の意味、値の根拠、確認時点、更新・確認する人をたどれるようにする仕事です。CMDBはその記録を支える仕組みで、IT資産管理とは対象や情報が重なります。

資料が違うときは、対象・属性・時点と根拠を確かめます。予定、承認、実施、観測した状態、台帳の更新、照合完了を一つにまとめず、未確認を「なし」「安全」「完了」に変えないでください。自動収集の結果も、取得できた範囲を確認して使います。