CMDBとは？ わかりやすく10分で解説

CMDBは、サーバやネットワーク機器の一覧を置くための台帳ではありません。IT資産、アプリケーション、クラウドリソース、SaaS、業務サービスをCIとして整理し、それぞれの依存関係まで追えるようにする管理基盤です。変更の影響範囲を見たい、障害時にどのサービスが止まるかを早く知りたい、更新漏れや保守切れを減らしたい。CMDBは、そうした判断の材料をそろえるために使います。

一方で、CMDBは登録件数を増やせば価値が出る仕組みでもありません。更新責任が曖昧なまま全資産を入れると、実態とずれた台帳になります。導入判断では、最初から全社を対象にするより、重要サービスや障害が多い領域から始め、変更管理や問い合わせ対応と一緒に育てる形のほうが失敗しにくくなります。

CMDBとは

CMDBはConfiguration Management Databaseの略で、日本語では設定管理データベースと訳されます。役割は、IT環境を構成する要素を記録し、それらの関係を追える状態にすることです。対象は物理サーバ、仮想基盤、ネットワーク機器、OS、ミドルウェア、アプリケーション、データベース、証明書、アカウント、クラウドリソース、SaaS、業務サービスなどです。

ポイントは、「何が存在するか」だけで終わらない点にあります。どのサーバでアプリケーションが動いているか、どのデータベースに接続しているか、どの業務サービスを支えているか、誰が管理しているかまで追えるようにして、運用判断に使える状態を作ります。

資産台帳との違い

資産台帳は、機器名、型番、購入日、設置場所、保守期限のような属性を記録する用途に向いています。CMDBはそこから一歩進み、資産どうしの関係を管理します。たとえば「このロードバランサ配下にこのWebサーバ群があり、その先でこのアプリケーションが動き、この業務サービスを提供している」という形です。

その違いが効くのは、変更と障害の場面です。台帳だけでは対象機器の情報しか見えませんが、CMDBでは関連先まで辿れるため、「この変更でどこに影響が出るか」「この障害でどの利用部門が困るか」を判断しやすくなります。

CIとは何か

CMDBで管理する対象単位をCI（Configuration Item）と呼びます。CIはサーバのような機器だけではありません。アプリケーション、クラウドアカウント、設定ファイル、証明書、SaaSテナント、業務サービスも、運用上追跡したいならCIとして扱えます。

ただし、最初から細かく分けすぎると維持できません。どの粒度で持つかは、実際に何へ使うかで決めます。障害時に影響範囲を見たいならサービス単位のCIが要りますし、設定変更の追跡を重視するなら構成要素の粒度を細かくする場面もあります。

CMDBは何に使うのか

変更管理で使う

CMDBが最も効きやすいのは変更管理です。アプリケーション更新、パッチ適用、ネットワーク設定変更の前に、関連CIを見て影響範囲を洗い出します。どのシステムが止まり得るか、どの利用部門へ連絡すべきか、どこまでテストすべきかを整理しやすくなります。

変更申請とCIが結び付いていれば、後から「どの変更がこの不具合に関係したか」も追いやすくなります。逆に、チケットとCMDBが切り離されていると、台帳はあっても変更の履歴がつながらず、調査で使いにくくなります。

インシデント対応で使う

障害時は、まず影響範囲と優先順位を決めます。CMDBがあれば、障害が起きたサーバやネットワーク機器に紐付くアプリケーション、業務サービス、担当部門、連絡先を辿れます。初動で「誰に連絡するか」「どこまで止まるか」を探す時間を減らせます。

また、直近の変更とCIが結び付いていれば、原因候補を絞り込みやすくなります。特に、複数チームが別々に運用している環境では、連絡先や責任範囲の見落としが復旧を遅らせやすいため、CMDBの有無で差が出やすくなります。

監査とセキュリティ運用で使う

監査やセキュリティ運用でもCMDBは使えます。たとえば、保守期限が近い資産、特定バージョンのOS、インターネット公開資産、重要サービスに関係するCIを抽出しやすくなります。脆弱性対応やEOL対応では、対象を素早く絞れるかどうかが作業速度を左右します。

ただし、この用途では最新性が崩れると逆効果です。対象外の機器を含めたり、本来入るべき資産を漏らしたりすると、優先順位を誤ります。セキュリティ用途まで見据えるなら、更新の仕組みを先に固めておく必要があります。

CMDBを導入するメリット

情報探索の時間を減らしやすい

障害や変更のたびに、担当者が過去資料や個人メモを探し回る状態は非効率です。CMDBに基本情報と関係性が集約されていれば、問い合わせ先、関連システム、業務影響を一か所から辿りやすくなります。属人化の圧力も下がります。

影響分析の精度を上げやすい

構成が複雑になるほど、「どこへ波及するか」が見えないまま変更しやすくなります。CMDBで依存関係が見えていれば、テスト範囲、作業時間帯、ロールバック判断を組み立てやすくなります。完全なモデルでなくても、主要な関係だけ見えるだけで失敗は減らしやすくなります。

投資判断の材料をそろえやすい

資産と業務サービスの関係が見えると、更改、増強、廃止、統合の判断をしやすくなります。どの資産が重要サービスを支えているのかが分からない状態では、更新順序も保守予算の配分も決めにくくなります。CMDBは、技術運用だけでなく、投資判断にも関わる基盤です。

CMDB導入でつまずきやすい点

最初から範囲を広げすぎる

全社の全資産を最初から入れようとすると、CI設計も属性設計も更新ルールも固まりません。その状態で入力を始めると、粒度が揺れ、重複CIが増え、すぐに維持不能になります。導入初期は、重要サービスや障害が多い領域に絞ったほうが安定します。

入力項目を増やしすぎる

理想を追うと、持ちたい属性は増えます。所有者、用途、重要度、契約、保守、クラウドタグ、関連手順書、監視設定など、入れようと思えば際限がありません。ですが、項目が多すぎると更新負荷が上がり、入力されないまま放置されます。最初は、変更管理や障害対応で本当に使う項目から始めるほうが現実に合います。

更新責任が曖昧なまま始める

CMDBが古くなる最大の理由は、誰が更新するか決まっていないことです。サーバチーム、ネットワークチーム、開発チーム、クラウド管理者のどこが責任を持つのかが曖昧だと、変更後に誰も直しません。CIごとにオーナーを持たせ、どのタイミングで何を更新するかを決める必要があります。

自動収集を過信する

ディスカバリーツールやクラウドAPI連携は有効ですが、それだけでCMDBが完成するわけではありません。自動収集は、識別子のずれ、重複CI、関係性の誤結合を起こすことがあります。ツールが拾える情報と、人が補うべき情報を分けて考えたほうが運用しやすくなります。

変更管理と切り離して運用する

CMDBを別システムとして置き、変更管理や問い合わせ管理と連動させないと、情報が更新されません。変更申請で対象CIを選ぶ、障害チケットに関連CIを紐付ける、といった流れがあると、CMDBの情報が日々の運用と一緒に更新されやすくなります。

導入前に決めておきたいこと

目的

最初に決めるのは、何のためにCMDBを使うかです。変更管理の精度を上げたいのか、障害初動を速くしたいのか、監査やセキュリティ対応まで含めたいのかで、対象範囲も属性も変わります。目的が曖昧なまま始めると、広く浅い台帳で終わりやすくなります。

対象範囲

次に、どのサービスと資産から始めるかを決めます。重要サービス、障害が多い領域、クラウド移行中の系統など、効果が見えやすい範囲から入ると運用ルールを固めやすくなります。最初のスコープが曖昧だと、CIの粒度も定まりません。

CIの粒度と属性

サーバ単位で持つのか、仮想マシン単位で持つのか、サービス単位まで持つのかを決めます。属性も同じです。最低限、識別情報、担当、状態、関連サービス、重要度、契約や保守に関する基本情報をどこまで持つかを決めておくと、入力負荷を抑えやすくなります。

更新責任と更新タイミング

誰が、いつ、どの場面で更新するかを決めます。たとえば、変更実施後に対象CIを更新する、クラウド自動収集で日次同期する、四半期ごとに棚卸しする、といった形です。ルールがないと、CMDBは早い段階で信用を失います。

正とする情報源

どの情報をどこから持ってくるかも決めます。クラウド資産はAPI、ネットワーク機器は監視基盤、契約情報は資産管理台帳、担当情報は組織マスタ、というように、項目ごとの正本を決めておくと衝突を減らせます。これを決めないと、同じCIに複数の値が並び、どれを信じるべきか分からなくなります。

CMDBが向くケースと向きにくいケース

向くケース

• 変更件数が多い環境
  変更の影響分析や連絡調整に時間がかかっている組織では効果が出やすくなります。
• 複数チームで一つのサービスを支える環境
  責任範囲や連絡先の探索に時間がかかる場合、関係性の整理が効きます。
• クラウドとオンプレミスが混在する環境
  構成が見えにくく、台帳だけでは判断しづらい場面が増えるためです。
• 監査や脆弱性対応の対象特定に時間がかかる環境
  資産とサービスの関係が見えると、優先順位を付けやすくなります。

向きにくいケース

• 更新ルールを決める運用体制がない
  人も責任分界も決まらないまま入れると、古い台帳になる可能性が高くなります。
• 小規模で構成が単純な環境
  対象が少なく、関係性も人がすぐ把握できるなら、台帳で足りる場合があります。
• 目的が「とりあえず整備したい」だけ
  何に使うかを決めないまま導入すると、更新負荷だけが残りやすくなります。

まとめ

CMDBは、IT資産の一覧を持つための仕組みではなく、構成要素どうしの関係を見えるようにして、変更、障害、監査、セキュリティ対応の判断に使う基盤です。価値が出るのは、情報が最新で、日々の運用とつながっているときです。

導入を成功させるには、最初から全社の全資産を抱え込まないことが大切です。目的を絞り、対象範囲を決め、CIの粒度を定め、更新責任を持たせ、変更管理や自動収集とつなげる。この順で進めると、使われないCMDBになりにくくなります。

CMDBに関するよくある質問