社内ネットワーク・サーバーの変更申請が出たときに、構成台帳と過去の変更・障害の記録から影響する機器とシステムを探し、根拠付きで変更審査の資料にする

処理の起点を決める

変更申請の状態が「審査待ち」に変わったときを起点にします。 起票の直後に動かさないのは、起票者が対象機器や変更内容を書き直す途中の申請を相手にしないためです。 状態の変更をITサービス管理ツールから通知できない環境では、5分ごとに「審査待ち」の一覧を取りに行く形にします。

変更内容が書き換えられて「審査待ち」に戻ったときも、もう一度動かします。 前回の結果は残し、差分が分かるように並べます。

台帳の索引の更新は、別の起点です。 構成管理台帳が更新されたときに、変わった機器の文書だけを入れ直します。台帳の更新から索引への反映が遅れると、入れ替え済みの機器を経路に含めてしまいます。 毎晩、台帳と索引の件数を突き合わせ、ずれがあれば運用チームに通知します。

入力データを集める

質を決めるのは、システムの台帳の depends_on です。 いまは備考欄に文で書かれているので、最初の作業は、この文を番号の一覧に直すことです。 150のシステムについて、構築に関わった担当者と一緒に依存を書き出します。

変更記録と障害記録には、型番を持たせます。 記録には機器名しか書かれていないので、取り込むときに台帳から型番を引いて足します。 これで「同じ型番の別の機器で起きた失敗」が引けるようになります。

データの取得方法を決める

経路のたどり方は、次の順にします。

1段目をたどる問い合わせは、次の形になります。 台帳の索引 cmdb_devices のうち、対象機器の文書から connected_to の値を集め、それに一致する機器を返します。

{
  "query": {
    "terms": {
      "device_id": {
        "index": "cmdb_devices",
        "path": "connected_to",
        "query": { "terms": { "device_id": ["FW-DC-001"] } }
      }
    }
  }
}

返ってきた機器の device_id を集めて、2段目の query の中の一覧に入れ直します。同じ形の問い合わせを path を hosts に変えて投げると、上で動くシステムが集まります。 システムの台帳の索引に対して depends_on で同じことをすれば、依存がたどれます。

ドキュメントの terms lookup の説明では、項目が一覧なら全要素が集められ、複数の文書から集めた値の重複は除かれるとされています。 同じ機器に2つの経路でたどり着いても、一覧には1回だけ載ります。どの経路で来たかは、Lambda が段ごとの結果を残して組み立てます。

構成図は索引に入れません。 絵の中の線を文字として取り出すことはできないので、経路は台帳の項目だけでたどり、構成図は人が確かめる参照先にします。

AIへ渡す前に整形する

1. 台帳の番号の正規化 … 機器番号の表記（SW-HQ-012、sw-hq-12）をそろえます。terms のドキュメントでは、値が空白と大文字小文字まで正確に一致した場合にだけ一致するとされています
2. 備考欄の依存を番号に直す … 文で書かれた依存を、システム番号の一覧に直します。この作業は人が行い、AIには下書きだけをさせます
3. 記録への型番の付与 … 変更記録と障害記録の対象機器から、台帳で型番を引いて足します
4. 設定の秘密情報の除去 … 変更内容に貼られた設定の断片から、パスワード、共有鍵、SNMP のコミュニティ名を正規表現で除きます。除去してから索引に入れます
5. 段数と件数の上限 … 2段目までにし、集まった機器が500台を超えたら3段目に進まずに打ち切ります。上限で止めた場合はその旨を結果に書きます
6. 埋め込みの対象を絞る … 変更内容と、切り戻しの理由、障害の事象の文だけを埋め込みます。機器番号やIPアドレスは埋め込まず、keyword の項目として持ちます
7. terms の上限を確かめる … terms クエリの値の数は既定で65,536までで、index.max_terms_count で変えられるとされています。1,200台の規模なら届きませんが、IPアドレス単位でたどる設計にすると上限に近づきます。 たどる単位は機器番号にします
8. 使われていない接続を外す … 台帳の connected_to に、撤去済みの機器や予備のポートが残っていることがあります。状態が「稼働中」でない機器は、たどる対象から外します

1番目を軽く見ないでください。 大文字と小文字、ゼロ埋めの違いだけで、つながっている機器が経路から黙って抜けます。 経路から抜けた機器は、結果の画面にも出てこないので、誰も気づきません。

5番目の上限は、コアスイッチの変更で効きます。 コアスイッチは社内のほぼすべてにつながっているので、2段たどると全機器が集まります。このときは「全社に影響」と表示し、経路の一覧ではなく、システムの一覧で見せます。

AIに処理させる

経路はAIにたどらせません。AIの仕事は、集まった結果のまとめです。

1行目がいちばん起きやすい失敗です。 変更内容に「認証」と書かれていると、AIは経路に無くても「認証基盤にも影響する可能性があります」と書き足したくなります。台帳に依存が書かれていないなら、それは台帳を直す話で、まとめで補う話ではありません。 足りない依存に気づいたら、審査の担当者が台帳の修正を起票します。

指示内容を固定する

あなたは情報システム部の変更審査を助ける担当です。
渡された経路の表と、検索結果として渡す過去の記録だけを根拠にしてください。

【変更申請】{change_request}
【経路の表】{paths}（段、起点、行き先、使った項目、台帳の記録番号）
【過去の記録】検索結果として渡します（変更記録と障害記録）

【書くこと】
1. 影響する機器とシステムを、システムごとにまとめ、それぞれの経路を書く
2. 同じ機器、または同じ型番への過去の変更と、その結果・切り戻しの理由
3. 影響範囲の機器で起きた障害のうち、変更が原因とされたもの
4. 上の2と3に書かれた事実から、審査で確かめる点

【厳守事項】
- 経路の表にない機器やシステムを書かないでください。
  影響がありそうだと思っても、表にないものは書かないでください。
- 承認すべきか、危険度がどれくらいかを書かないでください。
- 過去の記録にない原因を推測しないでください。
  原因が記録に書かれていなければ「原因の記載なし」と書いてください。
- 確かめる点は、過去の記録の内容から言えることだけにしてください。
- 経路が上限で打ち切られている場合は、その旨を最初に書いてください。
- 過去の記録が1件もなければ「関連する過去の記録は見つかりませんでした」と書いてください。

過去の記録は、Claude の検索結果ブロックで渡します。 1件の記録を1つの search_result にし、source に記録番号、title に記録の題名、content に変更内容と結果を別々のテキストブロックで入れます。引用には search_result_location として、どの検索結果のどのブロックかの番号が付きます。ブロックを分けておくと、「切り戻しの理由」の部分だけを引用させられます。

引用は、すべての検索結果でそろえて有効にします。 ドキュメントでは、1つのリクエストの中で、引用を有効にした検索結果と無効にした検索結果を混ぜるとエラーになるとされています。

「経路の表にないものを書かない」を2回書いているのは、1回では止まらないからです。 変更内容に業務名が出てくると、AIはその業務のシステムを結び付けたくなります。禁じるのは、表の外の知識で範囲を広げることそのものです。

出力形式を固定する

経路の表は、Lambda が次の形で組み立て、Claude に渡します。

{
  "change_id": "CHG-2026-1042",
  "targets": ["FW-DC-001"],
  "truncated": false,
  "paths": [
    { "hop": 1, "from": "FW-DC-001", "to": "SW-DC-014",
      "via": "connected_to", "record": "CMDB-SW-DC-014" },
    { "hop": 2, "from": "SW-DC-014", "to": "SYS-HR-01",
      "via": "hosts", "record": "CMDB-SYS-HR-01" },
    { "hop": "dep", "from": "SYS-HR-01", "to": "SYS-AUTH-01",
      "via": "depends_on", "record": "CMDB-SYS-AUTH-01" }
  ],
  "systems": [
    { "system_id": "SYS-HR-01", "name": "人事システム",
      "business_hours": "平日 8:00-20:00", "sites": ["本社", "大阪"] }
  ]
}

1つ目の理由は、経路の1行ずつに台帳の記録番号が付くことです。 審査の担当者は、「なぜ人事システムが入っているのか」を、記録番号から台帳の1行へたどって確かめられます。 自由文で受け取ると、どの台帳の項目から来たのかが消えます。

2つ目は、truncated で打ち切りを機械で示せることです。 上限で止めた結果を、全部たどった結果と見分けられます。

3つ目は、systems の業務時間と拠点を、まとめに渡せることです。 審査会が実施日時を決める材料になります。AIに日時を提案させずに、材料だけを並べます。

審査の画面には、次の3つを並べます。

システムへ連携する

申請への書き戻しは、審査の担当者が確定ボタンを押したときだけです。 起票者が書いた影響範囲は消さずに残し、確定した影響範囲を別の欄に書きます。 両者の差が、起票者への教育の材料になります。

構成管理台帳には書き込みません。 足りない依存に気づいたときは、担当者が台帳の修正を起票します。

人が確認する

1. 経路を確かめる … 経路の表と構成図を見比べ、入れ替え済みの機器や、使われていない接続が混ざっていないかを見ます
2. 抜けを確かめる … 自分の知っている依存が経路に無ければ、台帳の修正を起票します。まとめに書き足すのではなく、台帳を直します
3. 過去の記録の引用を開く … 切り戻しや障害の記録は、引用された記録番号を開いて原文を読みます
4. 影響範囲を確定する … 確定したものだけが審査会の資料に載ります

1件あたり15分を目安にします。 経路の表を構成図と見比べ、過去の記録のうち切り戻しと障害の記録を開いて読む時間です。コアスイッチのような「全社に影響」の申請は、15分では収まらない前提で、審査会で別に時間を取ります。

2番目は、この構成で初めて回る仕組みです。 これまで担当者の記憶にあった依存は、審査のたびに口頭で補われ、台帳には戻りませんでした。経路に出てこないことが目に見えるので、気づいた人が台帳を直す流れができます。 台帳の修正の起票件数は、最初の数か月は多く、台帳が追いつくにつれて減っていくはずです。

例外に対処する

| 同じ申請が何度も「審査待ち」に戻る | 毎回動かし、前回の結果との差分を並べる。差分が無ければまとめを作り直さない |

| 実施予定日時が業務時間に重なる | 判断はせず、systems の業務時間を影響範囲の欄の先頭に出す |

上から2行目までは、台帳の整備の問題です。 どちらも件数を月ごとに数え、多い月は台帳の更新の決まりが守られていないと読みます。台帳を直すのは運用チームの仕事で、この構成はその材料を出すところまでです。

記録を残す

• 申請番号、対象機器、変更内容、動いた日時
• 経路の表（段ごとの結果、打ち切りの有無）と、そのときの台帳の更新日時
• ハイブリッド検索の候補と、Claude に渡した記録、返ってきたまとめと引用
• 審査の担当者が確定した影響範囲と、まとめから外した・足した項目
• 台帳の修正を起票した記録
• 変更の実施後に障害が起きた場合の、障害番号との結び付け

2つ目で台帳の更新日時を残すのは、後から台帳が変わるためです。 障害が起きたあとに「事前に影響範囲を見ていたか」を確かめるとき、当時の台帳で何が出ていたかが要ります。

最後の行は、この構成の精度を測る材料になります。 実施後の障害が、事前の影響範囲に入っていたか。入っていなかった障害は、台帳の抜けか、たどる段数の不足のどちらかです。