ci-discovery

構成アイテムの検出

概要

構成アイテム（CI）は、CMDB の基盤です。このスキルでは、以下について説明します。

• CI クラス階層の理解
• CI の検出と分類
• 自動検出を利用できない場合の CI の手動作成
• CI データ品質の維持
• CI 間の関係の確立

使用するタイミング： CMDB へのデータ登録や維持、新しいインフラストラクチャの導入、CI データの検証を行う場合です。

前提条件

• ロール： cmdb_admin または CMDB への書き込みアクセス権を持つ itil
• アクセス： CMDB テーブル（cmdb_ci とそのサブクラス）
• 知識： CMDB のクラス構造、CI 属性

手順

ステップ 1：CI クラス階層を理解する

CMDB では継承が使用されます。すべての CI は cmdb_ci を継承します。

cmdb_ci (Base CI)
├── cmdb_ci_computer
│   ├── cmdb_ci_server
│   │   ├── cmdb_ci_win_server
│   │   ├── cmdb_ci_linux_server
│   │   └── cmdb_ci_unix_server
│   └── cmdb_ci_pc_hardware
│       ├── cmdb_ci_computer_win
│       └── cmdb_ci_computer_mac
├── cmdb_ci_service
│   ├── cmdb_ci_service_auto
│   └── cmdb_ci_service_manual
├── cmdb_ci_appl
│   ├── cmdb_ci_app_server
│   └── cmdb_ci_database_instance
├── cmdb_ci_network_gear
│   ├── cmdb_ci_netgear
│   └── cmdb_ci_ip_router
└── cmdb_ci_storage_device

利用可能な CI クラスを検出する：

Tool: SN-Query-Table
Parameters:
  table_name: sys_db_object
  query: nameLIKEcmdb_ci^super_class.name=cmdb_ci
  fields: name,label,super_class
  limit: 50

ステップ 2：既存の CI を照会する

新しい CI を追加する前に、既存のものを確認します。

MCP を使用する：

Tool: SN-List-CmdbCis
Parameters:
  ci_class: cmdb_ci_server
  query: operational_status=1
  fields: name,ip_address,os,sys_class_name
  limit: 100

名前で検索する：

Tool: SN-Query-Table
Parameters:
  table_name: cmdb_ci
  query: nameLIKEweb-server
  fields: sys_id,name,sys_class_name,operational_status

ステップ 3：新しい CI を作成する

CI の手動作成（検出を利用できない場合）：

Tool: SN-Create-Record
Parameters:
  table_name: cmdb_ci_linux_server
  data:
    name: "prod-web-01"
    ip_address: "10.0.1.100"
    dns_domain: "corp.company.com"
    fqdn: "prod-web-01.corp.company.com"
    os: "Red Hat Enterprise Linux"
    os_version: "8.5"
    cpu_count: 8
    ram: 32768
    disk_space: 500
    serial_number: "SN12345678"
    asset_tag: "ASSET-001"
    operational_status: 1
    install_status: 1
    environment: Production
    location: [location_sys_id]
    department: [department_sys_id]
    support_group: [group_sys_id]
    managed_by: [user_sys_id]
    comments: "Production web server - Node 1"

CI 属性リファレンス：

属性	説明	例
name	CI の表示名	prod-web-01
ip_address	プライマリ IP	10.0.1.100
fqdn	完全修飾ドメイン名	prod-web-01.corp.com
operational_status	1=稼働中、2=稼働停止	1
install_status	1=インストール済み、7=廃止	1
environment	本番／テスト／開発	Production
support_group	サポートチーム	Linux Admins

ステップ 4：CI を適切に分類する

該当する中で最も具体的なクラスを選択します。

判断ツリー：

Is it hardware?
├── Yes → Is it a computer?
│   ├── Yes → Server or Workstation?
│   │   ├── Server → What OS? → cmdb_ci_win_server / cmdb_ci_linux_server
│   │   └── Workstation → cmdb_ci_pc_hardware
│   └── No → Network gear? Storage? → cmdb_ci_netgear / cmdb_ci_storage
└── No → Is it software?
    ├── Application → cmdb_ci_appl
    ├── Database → cmdb_ci_database_instance
    └── Service → cmdb_ci_service

属性を確認するためにクラスのスキーマを取得する：

Tool: SN-Discover-Table-Schema
Parameters:
  table_name: cmdb_ci_linux_server

ステップ 5：CI 間の関係を確立する

CI は単独では存在しません。関係を定義します。

関係タイプ：

タイプ	説明	例
Runs on	ハードウェア上のソフトウェア	アプリケーションはサーバー上で稼働
Depends on	サービスの依存関係	Web は DB に依存
Contains	物理的な包含関係	ラックにサーバーが格納される
Owned by	所有関係	サーバーはチームが所有

関係を作成する：

Tool: SN-Create-Record
Parameters:
  table_name: cmdb_rel_ci
  data:
    parent: [parent_ci_sys_id]
    child: [child_ci_sys_id]
    type: [relationship_type_sys_id]

関係タイプを検索する：

Tool: SN-Query-Table
Parameters:
  table_name: cmdb_rel_type
  fields: sys_id,name,parent_descriptor,child_descriptor
  limit: 50

ステップ 6：CI データを検証する

検証クエリを使用してデータ品質を確保します。

必須データが不足している CI を検索する：

Tool: SN-Query-Table
Parameters:
  table_name: cmdb_ci_server
  query: ip_addressISEMPTY^operational_status=1
  fields: name,sys_class_name,support_group

重複する CI を検索する：

Tool: SN-Query-Table
Parameters:
  table_name: cmdb_ci
  query: nameLIKEserver-name
  fields: sys_id,name,ip_address,sys_created_on

孤立した CI（関係がない CI）を確認する：

# Query CIs not in any relationship
# This requires a more complex query or script

ステップ 7：CI のライフサイクルを維持する

状況の変化に応じて CI のステータスを更新します。

稼働ステータスの値：

値	ステータス	使用するタイミング
1	稼働中	CI が正常に機能している
2	稼働停止	CI が停止または故障している
3	修理中	修理中
4	DR 待機	災害復旧の待機状態
6	廃止	使用されていない

CI のステータスを更新する：

Tool: SN-Update-Record
Parameters:
  table_name: cmdb_ci_server
  sys_id: [ci_sys_id]
  data:
    operational_status: 6
    install_status: 7
    decommissioned: true
    comments: "Decommissioned per CHG0012345 on 2026-02-06"

CI データ品質チェックリスト

• 名前が命名規則に準拠している
• IP アドレスが正確で一意である
• シリアル番号が記録されている（ハードウェアの場合）
• サポートグループが割り当てられている
• ロケーションが指定されている
• 環境が設定されている（Prod/Test/Dev）
• 関係が定義されている
• 稼働ステータスが最新である
• 検出元が記録されている

ツールの使用概要

操作	MCP ツール	REST エンドポイント
CI の照会	SN-Query-Table, SN-List-CmdbCis	GET /cmdb_ci
CI の作成	SN-Create-Record	POST /cmdb_ci_*
CI の更新	SN-Update-Record	PATCH /cmdb_ci/{id}
スキーマの取得	SN-Discover-Table-Schema	GET /sys_dictionary
関係	SN-Create-Record	POST /cmdb_rel_ci

ベストプラクティス

• 最も具体的なクラスを使用する： cmdb_ci_server ではなく cmdb_ci_linux_server を使用します
• 命名を標準化する： 一貫した命名規則に従います
• 資産にリンクする： 該当する場合、CI を資産レコードに接続します
• ソースを記録する： CI が検出されたものか手動で作成されたものかを記録します
• 定期的に監査する： CI データの正確性を定期的に検証します
• 関係を網羅する： CI には少なくとも 1 つの関係を設定します

トラブルシューティング

レポートに CI が表示されない

原因： クラスが間違っているか、属性が不足しています
解決策： sys_class_name を確認し、必須フィールドに値が入力されていることを確認してください

CI の重複

原因： 複数の検出元があるか、手動で重複が作成されています
解決策： 識別ルールを使用し、重複を統合するか廃止してください

リレーションが表示されない

原因： リレーションタイプが CI クラスに対して無効です
解決策： リレーションタイプが親クラスと子クラスに対応していることを確認してください

関連スキル

• cmdb/relationship-mapping - リレーションの詳細
• cmdb/impact-analysis - CMDB を使用した影響分析
• cmdb/service-graph-diagnosis - 検出とサービスグラフの不足を診断
• itsm/change-management - 変更に伴う CI の変更

参考資料

• ServiceNow CMDB
• ITIL Configuration Management
• CMDB Best Practices