構成情報の正をどこに置くか — コードか台帳か本番の実物か

構成情報の「正」を台帳・IaCコード・本番の実物のどこに置くかは、管理対象が10台を超えた時点から問われる設計判断です。三者が食い違ったままでは、インシデント対応中に「現状を正確に言える人がいない」状態が生まれます。本記事では、食い違いが生まれる構造・情報源の役割分担の判断基準・台帳化の限界線を、構築プロジェクトの意思決定として整理します。手順の深追いは省き、設計判断に絞って解説します。

台帳・コード・本番が食い違い誰も現状を言えなくなる構造

食い違いが始まる3つの経路

構成情報の食い違いは、多くの場合3つの経路から積み上がります。第一は「緊急時の直接変更」です。障害発生中にレビューや変更管理プロセスを経ずにサーバへ直接アクセスして設定を変える判断は、現場では避けがたいものです。問題は、その変更がコードにも台帳にも反映されないまま放置されることにあります。第二は「環境間の差異放置」です。ステージングと本番で微妙に異なるパラメータが入ったまま「動いているから問題ない」として誰も修正しない状態が続きます。50台規模の環境ではこうした差異が数十か所に積み上がります。第三は「引き継ぎ漏れによる空白」です。前担当者しか把握していない手動設定が台帳に記載されないまま、新担当者が実機を確認して初めて差異に気づく、という状況は現場でよく聞きます。

「現状」への問いに誰も答えられない状態

インシデント対応中に「このサーバのNTPはどこを向いているか」と問われたとき、即答できるチームと実機を確認しに行くチームでは対応速度に大きな差が出ます。台帳があっても更新が半年前で止まっていれば参照価値はなく、IaCコードがあっても手動変更が加わっていれば実態を反映していません。こうした状態では誰かが「最後に触ったはずの人」を探してチャットを遡ることになります。これは技術的な問題ではなく、「正の情報源」を設計として決めなかった構造上の問題です。変更管理プロセスが整っていても、「正はどこか」という合意がなければ同じ状況に陥ります。

食い違いが可視化されないまま拡大する理由

食い違いが発見されにくい根本的な理由は、「今動いているから問題ない」という判断が合理的に見えることです。差分検出の仕組みがなければ、日常業務の中で食い違いに気づく機会はほとんどありません。30台の環境で手動の差分確認を1サーバあたり15分かけて行うと、全体で7.5時間の工数になる計算です。この確認を定期的に実施することは現実的ではないため、検証が後回しになります。気づいたときには乖離が取り返しのつかない規模に成長していた、という経緯をたどるのはそのためです。

正としてよい情報源と参照に留める情報源の判断

「正」に適する情報源の3つの条件

正の情報源として機能するためには、3つの条件が揃っている必要があります。一つ目は「変更が必ず通る経路であること」です。誰かがバイパスできる経路が存在する限り、その情報源は正にはなれません。二つ目は「差異を機械的に検出できること」です。記載内容と実態の差分を人手に頼らず検出できる仕組みがなければ、正であることを証明できません。三つ目は「変更の追跡ができること」です。いつ・誰が・なぜ変更したかが記録されていなければ、差異が生じたときに原因を遡れません。この3条件を各情報源に照らして判断することが、設計の出発点になります。3条件のうち1つでも欠けていれば、正ではなく「参照補助」として位置づける判断が適切です。

参照専用にとどめるべき情報源

正の条件を満たせない情報源は「参照専用」として位置づけます。典型的なのはExcelやスプレッドシートで管理された手動台帳です。変更の経路を制御できず、差異検出も手動になりやすいため、正としての信頼性は低くなります。ただし参照専用としての価値はあります。「正を確認するための補助線」「人間が判断材料として参照する概観」として活用することは有効です。問題が起きるのは、参照専用の情報源を正として扱い始めたときです。参照専用と正の区別が曖昧なまま運用が続くと、どちらを信じるべきか判断できない状態が常態化します。

複数の「正」が混在する危険性

「台帳が正」「コードが正」という認識がチーム内で分かれている状態は、食い違いそのものより危険です。食い違いは発見すれば修正できますが、「正の認識のズレ」は発見されにくいものです。構築を任されたあるチームでは、ネットワーク担当がCMDBを正として更新し、インフラ担当がTerraformのstateを正として管理し、二者間の同期ルールが存在しないまま半年が経過しました。大規模なインシデントが発生して初めて両者の認識が食い違っていたことに気づいた、というパターンは珍しくありません。正は情報の種類ごとに1つに絞り、チーム全体で合意することが設計の前提になります。

比較表: 手管理の台帳・IaCコード・実機からの自動収集

比較の軸と読み方

三つの情報源を比較するとき、「正として使えるか」だけでなく「どのユースケースに向いているか」という視点で読む必要があります。変更の追跡・差異の検出・可読性・維持コスト・緊急時の参照速度の5軸で整理すると、それぞれに得意と不得意があります。どれか一つで完結させようとするのではなく、役割を分担させる設計が現実的です。以下の比較表は「何を正にするか」の選択肢としてではなく、「どれに何の役割を割り当てるか」という設計の材料として読むことを勧めます。

比較軸	手管理の台帳	IaCコード	実機からの自動収集
変更の追跡	手動記録に依存・漏れやすい	Gitの履歴で追跡可能	取得時点のスナップショット（変更追跡は別途必要）
差異の検出	手動比較が必要・見落としリスクあり	check modeなどで機械的に検出可能	常に最新だが「意図との差」は別途判断が必要
可読性・文脈	高い（設計意図や背景を付記できる）	中（コードとして読めるが文脈は薄い）	低い（生データで文脈なし）
維持コスト	変更のたびに手動更新が必要	コードとして変更管理できる	収集基盤の初期構築コストが発生する
緊急時の参照速度	更新が止まっていると信頼できない	実機と乖離がある場合は参照価値が落ちる	高い（現在の実態を直接参照できる）
正として機能する条件	更新ルールと責任者の明確化が前提	全変更がコード経由という制約が前提	収集スコープと頻度の定義が前提

情報源の選択を決める問い

比較を踏まえた上で、実際にどれを正にするかは「変更の経路をどこまで制御できるか」で決まります。IaCを正とするには、全変更をコード経由にするという運用ルールと、それを強制する仕組みが必要です。自動収集を正とするには、収集の頻度・精度・スコープを事前に定義しなければ「何が収集されているか」自体が曖昧になります。手管理の台帳を正とするには、更新ルールと責任者を明確にした上で差異チェックのサイクルを設計に組み込む必要があります。「何が使いやすいか」ではなく「変更経路を制御できるか」が選択の軸になります。

手作業で入った変更をどの経路で正へ戻すか

手作業変更の検出アプローチ

手作業変更を検出するアプローチは大きく2つあります。一つは「差分検出ツールによる定期スキャン」です。構成管理ツールのcheck modeやサーバテストフレームワークを使って、コードと実機の差異を定期的に洗い出す手法は、自動化コストが低く導入しやすい特徴があります。もう一つは「変更ログの監視」です。OSの監査ログ機能でコマンド実行を記録し、想定外の変更を後から追跡します。どちらも「検出」はできますが、検出した後に正へ戻すプロセスを設計しておかないと、検出結果が積み上がるだけになります。検出の仕組みと対応フローをセットで設計することが重要です。具体的な操作手順については実践的なセミナーや本を参照することを勧めます。

変更を正の情報源へ反映する経路設計

手作業変更を正へ戻すフローは、変更の性質によって経路を分ける必要があります。「一時的な緊急対応」であれば、対応後にコードを修正して再適用するサイクルを明文化しておきます。「恒久的な変更判断」であれば、変更内容をコードに取り込んだ上でcommitし、実機への再適用で確定させます。問題になるのは、この二択のどちらでもない「判断が先送りされた変更」です。「あとでコードに反映する」という意図のまま放置された変更が積み上がると、正の情報源への戻しが困難なほど乖離が大きくなります。対応後24時間以内に変更の扱いを確定させるルールを持つチームは、乖離の蓄積を抑えている傾向があります。

「戻せない変更」を減らす構造的アプローチ

手作業変更が増える根本原因は、「コードを経由する経路が重すぎる」「レビュープロセスに時間がかかる」といった構造的な問題にあることが多いです。変更を正の情報源へ戻しにくい設計になっていると、現場は自然に手作業へ流れます。この状況では「手作業をなくす」よりも「手作業後の戻しコストを下げる」設計が先になります。特定の変更タイプには軽量なレビューパスを用意する、変更後のコード修正を補助するスクリプトを準備するといった工夫が有効です。構造を変えないまま「ルールを守れ」と求めても、手作業変更は減りません。

台帳の更新責任と更新タイミングをどう決めるか

更新責任の曖昧さが生む問題

「台帳はみんなで更新する」というルールは、実質的に「誰も更新しない」と同義になりやすいです。更新責任が個人に紐づかないと「自分が更新しなくても誰かがやる」という心理が働きます。現場でよく見られるパターンとして、作業担当者が更新することを想定していたが、レビュー担当者は更新済みだと思っていた、という二重の思い込みがあります。責任の曖昧さを解消するには、「作業チケットをクローズする条件に台帳更新を含める」という運用設計が有効です。台帳更新がタスクの完了条件でない限り、それは常に後回しにされます。

タイミングの設計パターン

更新タイミングには「変更直後」「週次定期」「スプリント末」「リリース後」などのパターンがあります。変更直後の更新は鮮度が高いですが、緊急対応中は後回しになりやすいです。週次定期は漏れを減らせますが、週内に複数の変更が重なると記憶が薄れる問題があります。実際には、変更の種類によってタイミングを分けるのが現実的です。「設定変更は変更直後」「構成の追加・削除はスプリント末のレビューに含める」という二段階の設計を持つチームは、更新漏れを抑えられています。一つのルールで全変更をカバーしようとすると、例外が増えてルール自体が形骸化します。

責任と権限の分離設計

更新責任者を決めるだけでなく、「台帳を参照する権限」と「台帳を更新する権限」を分離することも検討に値します。複数チームが同一の台帳を参照する場合、誰でも編集できる状態は意図しない書き換えのリスクを生みます。書き込み権限を変更作業の担当者に限定し、読み取りを広く開放する設計は、台帳の信頼性を維持しやすくなります。ただしこの設計は更新のボトルネックになりうるため、承認フローを軽量に保つこととセットで設計する必要があります。権限の分離が生む管理コストは、台帳の信頼性が失われたときのコストと比較すれば、多くの場面で前者の方が小さくなります。

全項目を台帳化して維持できなくなる境界

限界を示すサイン

「台帳に載っていない情報が正だと分かっている」という状態が日常的に発生するようになれば、維持の限界に近づいているサインです。また、台帳の更新に1件あたり30分以上かかる場合、変更が週20件を超えると更新だけで週10時間の工数が消える計算になります。更新工数が変更工数を上回る状況では、台帳の維持は実質的に不可能です。こうした限界が見えたとき、「より厳密に管理する」方向ではなく「台帳化の対象を絞り込む」方向に設計を転換する判断が必要になります。管理の密度を上げることが必ずしも信頼性の向上につながらない、という設計上の逆説がここにあります。

台帳化すべき情報と自動収集に委ねる情報の分類

すべての構成情報を台帳に載せる必要はありません。台帳化に向いているのは「変更頻度が低く、判断の根拠として人間が参照する」情報です。ホスト名の命名規則、ネットワークセグメントの設計意図、サーバの役割定義といった情報は台帳に置く意味があります。一方、「変更頻度が高く、機械的に収集できる」情報は自動収集に委ねます。インストール済みパッケージのバージョン、実行中のプロセス、現在のリソース使用率といった情報を手動で台帳に記載し続けることは、維持コストに見合いません。分類の軸は「人間が判断材料として読む情報か」「機械が最新状態を取得できる情報か」の二択になります。

維持できる台帳の規模感

経験則として、1人の担当者が正として維持できる台帳のエントリ数は、変更頻度にもよりますが300〜500項目程度が目安とされています。これを超えると、更新漏れと差異チェックを手動でカバーするコストが急増します。100台を超える環境で全台のすべての構成項目を台帳化しようとすると、専任の台帳管理者が必要になるか、台帳が形骸化するかのいずれかへ向かいます。現実的な設計として、台帳には「設計の意図と役割」を置き、「現状の実態」は自動収集ツールに委ねるという役割分担が、維持可能な範囲に収まりやすくなります。台帳に書くべきは「なぜそうなっているか」であり、「今どうなっているか」ではない、という整理が判断の軸になります。

構成情報設計チェックリスト

構成情報の正を設計する際に確認すべき判断ポイントを整理します。プロジェクトの序盤に一度通しで確認し、構成が大きく変化した節目に見直すことを勧めます。

1. 情報の種類ごとに「正」の情報源を1つ決め、チーム全体で合意しているか。
2. 「正」の情報源が、すべての変更経路を通過するよう設計されているか（バイパス経路がないか）。
3. 正の情報源と実機の差異を機械的に検出できる仕組みが存在するか。
4. 参照専用の情報源（補助線）と正の情報源の区別がチームで明示的に共有されているか。
5. 手作業変更が発生した場合に正へ戻すフローが明文化されており、担当者が認識しているか。
6. 「一時的な緊急対応」と「恒久的な変更」の扱いがフローとして分かれているか。
7. 台帳の更新責任者が個人単位で明確になっており、タスクの完了条件に含まれているか。
8. 更新タイミングが変更種別ごとに定義されているか（全変更に同一ルールを適用していないか）。
9. 変更頻度が高く自動収集できる情報は台帳から外す判断ができているか。
10. 台帳・コード・実機の三者が食い違った場合の優先順位がチームで合意されているか。