CMDBとは何を記録する台帳？｜AIの構成を追える形に

「社内でAIを使い始めたが、どのモデルがどの社内データにつながっているのかを聞かれて答えられませんでした」「契約しているサービスの一覧はあるのに、止まったときにどの業務が止まるのかが分かりません」——AIの仕組みを社内に入れた情報システムの担当者から、この半年でよく聞く言い方です。足りていないのは一覧ではありません。足りていないのは、物と物がどうつながっているかを記録した台帳です。この記事では、CMDBが何を記録する台帳なのか、持つ項目とつながりの記録の仕方、更新の回し方、そして台帳が腐る原因までを整理します。

CMDBが記録するのは、物の数ではなくつながり

CMDBは構成管理データベースの略で、ITサービスを成り立たせている要素と、その要素どうしの関係を記録して見えるようにするための台帳です。記録の単位は構成アイテムと呼ばれます。台帳の中心にあるのは要素そのものではなく、要素と要素の関係の情報で、ここが物品の一覧との決定的な違いになります。

構成アイテムに入るものの幅は広く、解説では、機器のようなハードウェアだけでなく、基本ソフトや業務のアプリといったソフトウェア、ネットワークの設定情報、仕様書などの文書、さらに資産の持ち主にあたる人、設備や建物までが例として挙げられています。物として触れるものだけを入れる台帳ではない、という点を先に押さえておくと、項目を決める段で迷いません。

一覧と台帳の違いは、答えられる問いの違いです。一覧は「何があるか」に答えます。つながりの台帳は「これが止まると何が止まるか」に答えます。ある構成アイテムで起きた障害が、ほかのどの構成アイテムやサービスに影響するかを、依存の関係をたどって特定できるのがこの台帳の効き目です。

もう1つ、単位の考え方に癖があります。構成アイテムは物と1対1ではありません。解説では、机の上の端末と画面をまとめて1つの構成アイテムとして扱う例が挙げられています。単位は物の切れ目ではなく、運用の都合で決めるということです。一緒に動き、一緒に止まり、一緒に替えるものは、1つにまとめたほうが使いやすくなります。

この言葉は、ITILという枠組みから来ている

CMDBは製品の機能名ではありません。ITIL、つまりITサービスの運用の進め方をまとめた枠組みの中で、構成管理という位置づけで扱われてきた考え方です。解説でも、構成管理はITILの基本に置かれたプロセスであり、サービスを安定して提供するために欠かせない構成アイテムを体系的に管理する仕組みだと説明されています。

出どころが枠組みの側にあることには、実務上の意味があります。呼び名と考え方が社外と共通なので、道具を替えても、運用を外部に委託しても、同じ言葉で話が通る。台帳の項目を自社の造語で作ってしまうと、委託先への引き継ぎや道具の乗り換えのたびに翻訳の作業が発生します。

ただし留保が1つあります。この枠組みは版を重ねており、版によって実践の呼び名や整理の仕方が変わります。社内の規程や手順書に書くときは、どの版を前提にしているかを添えておくのが安全です。版を書かないまま年数が経つと、書いた人の前提が分からなくなり、更新の判断ができなくなります。

資産の台帳と、何が違うのか

同じ機器を指していても、資産の台帳と構成の台帳は目的が違います。解説では、資産の管理は財務や経理の処理を最適にすることを目的とし、構成の管理はITサービスを最適にすることを目的とすると整理されています。目的が違うので、持つべき項目も、正しさの基準も変わります。

この違いから、片方があれば足りるという話にはなりません。台数と金額が合っている台帳を見ても、止まったときにどの業務が止まるかは出てきません。逆も同じです。なお、資産の台数が合わなくなる原因や、棚卸しの進め方はこの記事では扱いません。ここで扱うのは、つながりを持つ台帳の作り方です。

1つの道具で両方を持つこともできます。その場合に気をつけるのは、項目を混ぜないことです。契約と金額の項目と、依存の関係の項目を同じ画面に並べると、どちらの目的でも読みにくい台帳になります。同じ道具に置くとしても、見る画面は目的ごとに分けるのが現実的です。

AIを社内に入れると、つながりが見えなくなる

従来のシステムのつながりは、比較的まっすぐでした。業務のアプリが特定のサーバーの上で動き、そのサーバーが特定のネットワークにつながっている。縦にたどれば端まで届きます。AIの仕組みを入れると、この形が崩れます。呼び出し元、使うモデル、発行した鍵、参照する社内データ、動かしている端末が、それぞれ別の方向に散るためです。

具体的に見えなくなるのは、次のような問いです。どのモデルを替えると、どの業務の出力が変わるのか。どの鍵を止めると、どの処理が止まるのか。どの社内データが、どの用途で読まれているのか。この3つは、契約しているサービスの一覧を見ても答えが出ません。一覧に載っているのは契約の単位であって、つながりの単位ではないからです。

答えが出ないままにしておくと、外から予定が降ってきた日に困ります。使っているモデルの提供が終わる、料金の体系が変わる、版が上がる。どれも外の都合で起きるので、時期を選べません。そのとき必要なのは影響の範囲の一覧で、台帳が無いと、心当たりを聞いて回る作業から始まることになります。

ここが体制の話につながります。つながりを追える台帳を持っている組織は、外の変化に対して「調べます」ではなく「影響はこの範囲です」と返せます。返せるかどうかは、担当者の記憶の量ではなく、台帳の設計で決まるということです。

台帳に持つ項目は、5つの層で決める

項目を決めるときに、最初から網羅しようとすると失敗します。埋める人がいない項目が半分を超えた台帳は、どの値が信用できるのか分からなくなります。層に分けて、層ごとに必須の項目を絞るのが実務的です。

層	持つ項目の例	その層が要る理由
基本	名前／種別／状態（使用中・停止・廃止）／所有者／置かれている場所	どの台帳からでも引ける最小限の情報
契約	提供元／契約の区分／期限／サービスの水準（SLA）	止まったときの責任の切れ目と問い合わせ先
AIの中身	モデルの名前と版／呼び出しの入口／利用の用途／出力を確認する人	版が変わったときに影響する業務を引くため
データ	参照する社内データの範囲／持ち出しの可否／保存の期間	情報の扱いの線引きを台帳で示すため
つながり	依存している構成アイテム／依存されている構成アイテム／関係の種類	障害と変更のときに影響の範囲をたどるため

項目の具体例としては、解説で、種別、名前、説明、置かれている場所、ライセンスの情報、持ち主、状態、提供元の情報、関連する文書、期限、サービスの水準が挙げられています。この並びを出発点にして、自社で埋められないものを落とし、AIの層とデータの層を足す形で組むと早く決まります。

文書を構成アイテムとして持つ考え方も押さえておくとよいところです。解説では、構成アイテムの管理に、契約書や機密保持契約書といった関連文書を含める整理が示されています。委託先が関わる構成では、この紐付けが責任の切れ目を示します。止まったときに、どの契約の範囲で誰が直すのかが、台帳から引けるという形です。書類の保管場所を台帳に書くだけでも、緊急のときに探す時間が消えます。

原則は1つだけ覚えておきます。埋める人が決まっていない項目は作らない。必須と任意を分け、必須は各層で5つ以内に収めます。任意の項目は、埋まらなくても台帳の価値が落ちない場所に置きます。

AIの仕組みで新しく増える構成アイテム

AIを入れたときに台帳へ足すものは、大きく4つです。モデル（名前と版と提供元）、鍵（誰に発行した何のための鍵か）、参照するデータの置き場、そして呼び出し元（業務のアプリ、担当者の端末、自動で動く処理）。この4つを構成アイテムとして持たせると、先ほどの3つの問いに答えられるようになります。

モデルに版の項目を持たせる理由は、名前が同じでも中身が入れ替わるからです。版が替わると出力の傾向が変わります。版を持たない台帳では、出力が変わった日に何が変わったのかを追えません。いつからどの版を使っているかを記録しておくと、業務側からの問い合わせに事実で答えられます。

鍵を構成アイテムとして持たせる理由は、鍵が止める操作の単位だからです。鍵と用途が1対1で結ばれていない台帳では、止めた瞬間にどの業務が止まるか分かりません。1本の鍵を社内で共用している状態は、台帳の側から見ると、つながりの情報が失われている状態です。

自動で動く処理は、呼び出し元として必ず記録します。人が画面を開いて押している処理は、止まれば誰かが気づきます。人が介在しない処理は、止まっても誰も気づきません。気づかないまま日次の集計が抜け、月末に発覚する、という形の事故はここから起きます。

つながりは、向きと種類を付けて記録する

つながりを「関係がある」としか記録していない台帳は、使うときに役に立ちません。関係の線が引かれているだけでは、どちらがどちらに頼っているのか、無くなったら止まるのか品質が落ちるだけなのかが読めないからです。必要なのは向きと種類の2つです。

向きとは、どちらがどちらに依存しているかです。向きが入っていると、2つの問いに答えられます。「これが止まると何が止まるか」は依存されている側をたどり、「これを直すには何を先に見るか」は依存している側をたどる。同じ線を逆から読むだけなので、向きが無いとどちらも出せません。

種類とは、依存の強さです。動作に必要（無いと止まる）、参照している（無いと品質が落ちる）、置き換えられる（別の手段がある）の3つで足ります。障害のときに最初に見るのは、動作に必要と記録された線だけです。種類が入っていない台帳は、緊急の場面で線の数だけ確認の作業が増えます。

関係の記録を手で維持するのは現実的ではありません。AI時代の台帳の要件を整理した資料では、関係性は検出したデータから自動で組み立てるものとし、手で維持する運用は取らないと明言されています。合わせて、業務のサービスへの紐付けまで作ると、何層かにまたがる依存もたどれるとされています。

項目ごとに、出どころと最後に確かめた日を持たせる

台帳の値は、すべて同じ信用度ではありません。自動で検出した値、他の仕組みから連携で入った値、人が手で書いた値。この3つは正しさの見込みが違います。だから、値そのものの横にその値がどこから来たかの札を持たせるのが要件として挙げられています。

合わせて持たせるのが、最後に確かめた日です。検出の仕組みが止まっていても、台帳の値は消えません。古い値がそのまま居座ります。日付が入っていれば、値の古さが数字として見えます。同じ資料では、検出の処理が失敗したことを、すぐ気づける形にしておく必要も挙げられています。失敗が静かに続くと、台帳は見た目の整ったまま実態から離れていきます。

変更の記録も残します。構成アイテムの記録が変わったら、何が変わったか、いつ変わったか、変更前の値は何だったかを残す。この3点が揃っていると、障害の原因が台帳の書き換えだった場合にも戻せます。値の履歴が無い台帳は、間違いを見つけても直す前の状態が分からないため、調査がそこで止まります。

所有者の欄が空の台帳は、判断に使えない

項目の中で1つだけ優先度が高いものを選ぶなら、所有者です。所有者が空だと、止める判断の行き先も、確認の依頼先も決まりません。AI時代の台帳の要件を整理した資料では、所有者の欄が無いために、自動で進む処理が実行の一歩手前で止まるという表現で、この欄の重さが指摘されています。

AIの構成では、所有者を2種類に分けておくのが実務に合います。1つは技術の所有者で、設定を触る人。もう1つは業務の所有者で、止めてよいかを判断する人。この2つが同じ人になっている状態は、判断の独立性が無い状態です。止めた影響を受ける側と、止める操作をする側が同じだと、影響の見積りが甘くなります。

運用で崩れるのは異動のときです。個人の名前だけで所有者を持つと、異動のたびに欄が空になります。役割の名前と個人の名前を両方持ち、異動の手続きの中で台帳の所有者欄を直す作業を入れておきます。年に1回の棚卸しで直そうとすると、その1年のあいだ判断の行き先が消えます。

更新は手で回さない。入り口を2つに絞る

台帳は、作るより保つほうが難しい領域です。解説でも、担当者が手作業で更新していく運用は実行不可能で、情報が古いまま放置される危険があると指摘されています。だから設計の段で、更新の入り口を自動の検出と変更の手続きの2つに絞ります。

差分を見る担当を1人決めておきます。台帳は作った日から古くなるので、直す作業が誰の仕事かを決めていないと止まります。週に30分の枠で足ります。件数が多い週は上から順に当たり、残りは翌週に回す形にします。

もう1つ効くのが、他の作業とつなげることです。障害の記録と変更の記録から台帳を引けるようにすると、使われるから直ります。逆に、どこからも引かれない台帳は直りません。使う場面を作ることが、更新を回す最短の手当てになります。

台帳が腐る原因は、3つに集約できる

腐った台帳を見ていくと、原因はほぼ3つに収まります。手で書く運用にしたこと、直す担当を決めなかったこと、他の作業とつながっていないことです。どれも道具の性能の問題ではなく、運用の設計の問題です。

• 担当者が手で更新する前提で作った。件数が増えた時点で追いつかなくなり、古い値のまま残った
• 項目を先に増やした。埋める人がいない項目が半分を超え、どの値が信用できるのか分からなくなった
• 障害や変更の手続きとつながっていない。影響の範囲の特定が手作業のままで、台帳を見る理由が無くなった
• 所有者を個人の名前だけで持った。異動のたびに空欄が増え、止める相談の行き先が消えた

腐り方には順番があります。まず鮮度が落ち、次に値の信用が落ち、最後に使われなくなります。使われなくなった台帳は、直す動機も一緒に消えるので、ここまで来ると作り直しに近い手間がかかります。腐り始めの合図は、担当者が台帳ではなく個人の記憶や手元の表を見始めることです。

直すときは全部を直しません。よく参照される構成アイテムから直すのが順番です。障害の記録をさかのぼり、この半年で問い合わせが来た構成アイテムを並べ、その周辺の関係と所有者だけを正します。全件を正そうとすると、終わる前に次の古さが積み上がります。

台帳の健全性は、3つの見方で測る

台帳の良し悪しは、登録件数では測れません。運用の整理では、3つの見方を合わせた点数で健全性を測る形が定着しています。埋まっているか、値が合っているか、決めた形に沿っているかの3つです。

見方	測ること	測り方の例
埋まっているか	必須の種別と項目が埋まっているか	必須項目が埋まっている構成アイテムの割合
合っているか	値が実態と合い、論理的に矛盾していないか	検出した値と台帳の値が一致している割合
決めた形に沿っているか	名前の付け方の規則と、状態の段階に沿っているか	規則どおりの名前になっている構成アイテムの割合

この3つに、AIの構成では次を足します。関係の線を1本も持たない構成アイテムの件数、最後に確かめた日から一定の日数が過ぎた件数、検出の処理が失敗した件数です。点数は四半期に1回ではなく、続けて測る形にするのが要件として挙げられており、しきい値を割ったときに是正の手続きが動く形まで作るとされています。

• 点数を上げること自体を目的にすると、埋めやすい項目だけが埋まる
• 必須の項目を減らせば点数は上がる。項目を変えた月は、前の月と比べられないと割り切る
• 他社の目安値は借りない。まず自社の現状を測り、前の月と比べる
• 最後の判断は点数ではなく、直近の障害と変更で台帳が実際に使えたかどうかで下す

障害のときに、台帳が効く場面

止まったという連絡が入った直後に必要なのは、原因ではありません。最初に必要なのは影響の範囲です。原因の特定には時間がかかりますが、影響の範囲は台帳の関係をたどれば出ます。解説でも、ある構成アイテムで発生した障害がほかのどの構成アイテムやサービスに影響するかを、依存の関係をたどって特定できると説明されています。

AIの構成では、この効き方が具体的になります。モデルの呼び出しが失敗したとき、その入口を使っている用途を台帳から引けば、止まる業務の一覧が出ます。手作業に切り替える必要がある業務と、待てる業務の区別が、担当者の記憶ではなく記録から付きます。

台帳が無いときに何が起きるかというと、心当たりを聞いて回る時間が復旧の時間より長くなります。この時間は、技術の力では短くできません。記録があるかどうかだけで決まる時間だからです。なお、当番の置き方や連絡の順番の決め方は別の主題なので、ここでは影響の範囲の洗い出しまでで止めます。

変更のときに、台帳が効く場面

台帳のもう1つの使い場面は、変更を入れる前です。解説でも、変更を計画するときに現状の構成情報を参照する使い方が挙げられています。AIの構成では、モデルの版を上げる、鍵を入れ替える、参照するデータの範囲を変える——どれも出力が変わる操作なので、事前に影響の範囲を見ておく価値が大きくなります。

手続きに組み込むと、台帳が使われて同時に直ります。変更の申請に、影響する構成アイテムの一覧を添付させる。添付が無い申請は受け付けないという一文を入れるだけで、申請を出す人が台帳を開くようになります。開かれた台帳は、間違いが見つかるので直ります。

外から予定が降ってくる場面でも効きます。提供の終了や仕様の変更の予告が来たとき、どの用途が影響するかを台帳から引けます。手で洗い出すと、使われ方の把握が薄い部署の分から漏れます。漏れた分は、止まってから見つかるので、対応の順番が最悪になります。

見落とされがちな使い方が、過去をさかのぼる使い方です。解説では、障害時の影響の範囲の特定と変更計画時の現状の参照に並んで、過去の対応と変更の追跡が活用の場面として挙げられています。同じ構成アイテムで前にも変更を入れていれば、そのときに何が起きたかを引けます。前例が引ける台帳は、同じ検討を毎回やり直さずに済むので、変更の検討にかかる時間が回を重ねるほど短くなります。

道具を選ぶときに見る4点

製品の機能の一覧を並べても選べません。台帳として保てるかどうかで見るので、確認するのは次の4点に絞れます。

• 自動の検出がどこまで届くか。社内の機器だけか、クラウドの契約や呼び出しの入口まで見えるか
• 関係の持ち方。向きと種類を持てるか。関係の種類を自社で増やせるか
• 変更と障害の記録とつながるか。別の道具を使っている場合、連携の手段があるか
• 出どころと最後に確かめた日を、項目ごとに持てるか

この4点に加えて、自社で決めた項目を足せるかを見ます。AIの用途は増え続けるので、項目を足せない道具は2年で足りなくなります。導入のときに完璧な項目設計を作る必要はなく、あとから足せる前提で小さく始めるほうが早く回り始めます。

始め方も判断に含めます。全社の構成を入れ終えてから使うのではなく、よく止まる業務に関わる構成アイテムから入れて、障害と変更で1回使ってみる。1回使うと、足りない項目が実際の困り方として出てくるので、机の上で項目を議論する時間が短くなります。

AIに任せる範囲と、人が決める範囲

台帳の整備にAIを使うのは相性のよい作業です。検出した結果と台帳の値の差分の一覧づくり、名前の付け方の規則から外れた値の抽出、関係の候補の提示、変更の影響の範囲の下書き。ここまでは任せてよい範囲です。作業の量が多く、間違いが人の目で確かめられる範囲だからです。

任せない範囲は、関係があると確定すること、所有者を推定すること、廃止してよいと判断することです。理由は、AIが見ているのが検出された通信の記録や名前の似かただからです。たまたま名前が似ている別物を、同じ系統として結んでしまうことが起きます。結ばれた線は、障害のときに間違った範囲を示します。

運用の決め事は2つで足ります。1つは、AIが出したものは候補として扱い、何を根拠に結んだかを必ず付けさせること。根拠が示せない線は登録しません。もう1つは、人が確認する範囲を先に決めることです。業務に直結する構成アイテムと、関係の種類が動作に必要になっているものは、必ず人が目を通すと決めておきます。

逆向きの話もあります。台帳を読ませてAIに自動で動かす仕組みを作るなら、所有者と出どころと鮮度が揃っていることが前提になります。揃っていない台帳をもとに自動で動かすと、実行の一歩手前で止まるか、間違った先を止めます。自動化の準備は、台帳の項目を整える作業そのものだということです。

まとめ

CMDBという台帳の要点は、物の数ではなく、物と物のつながりを記録することにあります。項目は基本・契約・AIの中身・データ・つながりの5つの層で決め、必須は各層5つ以内に絞る。AIを入れたらモデルと鍵と参照するデータと呼び出し元を足し、モデルには版を、鍵には用途を結びつける。関係は向きと種類を付けて記録し、手では維持せず検出した結果から組み立てる。値には出どころと最後に確かめた日を持たせ、所有者は技術と業務の2種類を役割の名前で持つ。更新の入り口は自動の検出と変更の手続きの2つに絞り、差分を見る担当を1人決める。差分の一覧づくりや候補の提示はAIに任せてよいものの、関係の確定と所有者の推定と廃止の判断はさせず、根拠を必ず付けさせる。まずは、この半年で問い合わせが来た構成アイテムを並べ、そのうち所有者の名前が言えるものが何割あるかを数えるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。