クラウド運用の現場では、監視ルールや障害対応手順を記した文書が数多く存在します。Runbook（障害発生時の対応手順書）や監視設計書、SLO（サービスレベル目標）の運用ルールなどです。こうした文書を持つ組織の担当者、特に「ルールはあるが実際に守られているか自信がない」という状況にある方に向けて、ルールの実効性を点検する考え方を整理します。
最近、AIコーディングエージェント向けの指示書（AGENTS.mdやCLAUDE.mdといったファイル）を対象にした興味深い調査結果が公開されました。8つの公開プロジェクトから1,332個の指示単位、17,611個の個別指示を分析したところ、「実際に守られたかどうかをリポジトリだけから確認できる」指示の割合は中央値でわずか11.1%だったというものです。範囲は2.2%から22.9%。つまり大半の指示は、エージェントが「やった」と言えばそれで済んでしまう「主張のみ」の状態でした。
この調査が使った分類は単純です。チェックボックス、実行可能なコマンド、具体的なファイル成果物、終了コードや差分など、リポジトリを見れば第三者が判定できるものを「CHECKABLE（検証可能）」と呼び、それ以外を「CLAIMABLE（主張のみ）」と呼びます。さらに衝撃的なのは、8つのうち5つのプロジェクトが成果物（アウトプットとして残るファイル）を一切義務付けていなかった点です。残る3つが義務付けた103個の成果物のうち、44個（43%）は一度もコミット履歴に存在しませんでした。調査者はこれを「幽霊成果物（phantom artifacts）」と呼んでいます。誰も見ていなかったから、誰も気づかなかったという意味です。
この構図は、クラウド運用の監視ルールや障害対応手順にもそのまま当てはまります。「デプロイ前に必ずヘルスチェックを実行する」「障害発生時はまずダッシュボードで指標を確認する」といったルールは、実際にCI（継続的インテグレーション）やフックで強制されているのか、それとも「覚えている人がいれば実行される」だけの状態なのか。この違いを切り分ける判断軸を以下に整理します。
判断軸1: 検証可能性 — 誰が見ても判定できるか
まず確認すべきは、そのルールが「守られたかどうかを第三者が機械的に判定できるか」です。たとえば「監視アラートのしきい値は月次で見直す」というルールがあっても、見直した記録がどこにも残らなければ検証不可能です。
一方、「デプロイ後にSyntheticモニタリング（合成監視、擬似的なユーザー操作で外形監視するツール）が成功ログを出力する」という形なら、ログファイルという成果物が残ります。第三者が過去のコミットやログを遡って「本当に実行されたか」を確認できます。
判断軸2: 強制メカニズムの有無 — 誰が押し付けているか
次に見るべきは、そのルールを実行させる仕組みが人の記憶に依存していないかです。CIパイプライン、Gitフック、cronによる定期ジョブ、アラートマネージャーの自動エスカレーションなど、機械が強制する仕組みがあるかどうかを確認します。
分析対象になった指示書の例では、コミット前に必ず実行すべきとされていた2つのチェックが、実はCIにもフックにもスケジュールタスクにも組み込まれていませんでした。過去200コミットを遡ると、そのうち片方のルール（インデックスの鮮度チェック）は対象となる61コミット中29コミットで違反していました。約半数です。これは「ルールが存在すること」と「ルールが機能していること」が全く別の話であることを示しています。
判断軸3: 成果物の永続性 — 消えずに残るか
3つ目の軸は、ルールの実行結果が後から追跡可能な形で残るかです。障害対応でよくあるのは「対応した」という口頭やチャットのメモだけが残り、実際にどのコマンドを打ったか、どのメトリクスを確認したかが記録されないケースです。
ポストモーテム（障害の事後分析レポート）を書く文化があっても、そのテンプレートに「実行したコマンド」「確認したダッシュボードのスクリーンショットURL」といった具体的な成果物欄がなければ、次にレビューする人は「本当にやったのか」を推測するしかありません。
判断軸4: 判断系ルールと手続き系ルールの区別
最後に、そもそも検証可能性で測ること自体が適さないルールもあることに注意が必要です。「障害の重大度を判断する前に、影響範囲の仮説を立てる」といった思考プロセスに関するルールは、成果物ではなく判断力を養うものです。これを無理に検証可能にしようとすると、形式だけのチェックボックスが増えて本質を見失います。
手続き系（コマンド実行、ログ確認、通知送信など）と判断系（原因の仮説立案、優先度判断など）を分けて評価することが、監視ルールの棚卸しでも有効です。
| ルールの種類 | 検証可能にすべきか | 具体例 |
|---|---|---|
| デプロイ前チェック | する | ヘルスチェックのHTTPステータスをCIログに記録 |
| 障害対応の初動 | する | インシデント管理ツールにタイムスタンプ付きで記録 |
| 根本原因分析の視点 | しない（判断系） | 「他システムへの波及を先に疑う」という思考習慣 |
| 定期的な設定見直し | する | 棚卸し結果をドキュメントにコミットする |
ケース別の推奨
監視ルールやRunbookが10個以上あり、かつオンコール担当者が定期的に交代する組織なら、まず手続き系ルールから検証可能性を高める作業に着手するのが妥当です。担当者が固定的で暗黙知に頼れる小規模チームでは、優先度は下がりますが、担当者の異動や退職リスクを考えると後回しにしすぎるのは危険です。
具体的な着手方法としては、まず手持ちのRunbookやAGENTS.md相当のドキュメントを一覧化し、各項目を「CHECKABLE」か「CLAIMABLE」かに仕分けます。分類の基準は、上記の判断軸1と同じく「リポジトリやログ、監視システムの記録だけを見て、実行有無を判定できるか」です。
CLAIMABLEに分類された項目のうち、特に障害対応の初動やデプロイゲートに関わるものは、CIやアラートルールに組み込めないかを検討します。たとえば以下のように、デプロイパイプラインにヘルスチェックの結果検証を追加する形です。
# デプロイ後にヘルスチェックを実行し、失敗時はパイプラインを止める例
curl -sf https://service.internal/healthz || exit 1
echo "healthcheck passed at $(date -u +%FT%TZ)" >> deploy-audit.logこのようにログファイルという成果物を残すだけで、後から「本当に確認したか」を第三者が検証できるようになります。
あえて見送るべき条件
一方で、すべてのルールを機械的に検証可能にしようとするのは避けたほうがよい場合もあります。判断系のルール（前述の根本原因分析の視点など）を無理にチェックボックス化すると、形式だけを満たして本質的な思考が省略される「チェックボックス疲れ」を招きます。
また、成果物を残す仕組み自体の運用コストが、得られる安心感に見合わない場合も見送る判断が必要です。小規模なチームで、障害対応の頻度が年に数件程度であれば、大掛かりな検証基盤を作るより、ポストモーテムのレビューを丁寧に行うほうが費用対効果は高くなります。
まとめ
監視ルールやRunbookは、文書として存在することと、実際に機能していることは別問題です。まず手元のドキュメントを棚卸しし、各項目が検証可能か主張のみかを仕分けることから始めてみてください。
特に「成果物を一つも要求していないルール」がないか、そして「要求している成果物が実際に一度も生成されていないか」の2点は、比較的短時間で確認できます。過去のデプロイログやインシデント管理ツールの記録を遡り、ルールに対応する記録が実在するかを数件サンプリングするだけでも、運用の実効性が見えてきます。