障害の7割は変更から来る — 戻せる形・検知できる形を作る

攻撃を防ぐ道具は、この数年で一気に増えました。クラウドの設定診断、端末の挙動監視、依存関係の脆弱性検出、AIによるペネトレーションテスト。カテゴリはほぼ出揃っていて、予算があれば買えます。

それでも、現場で止まらないのは別の種類の障害です。設定を変えた、ミドルウェアを上げた、スキーマを変えた、新しい機能を出した。稼働中のシステムに手を入れた瞬間に、事故の確率が上がる。Google の SRE チームは、障害のおよそ70%は稼働中システムへの変更に起因すると書いています。

結論から書きます。買うべき道具の選定より先に、変更を小さく入れる形、戻せる形、検知できる形、後から説明できる形を設計する必要があります。以下、その具体策と、効かない場面、AIに任せてよい範囲を書きます。

70%は変更から来る

この数字は Google の経験則で、当社の実測ではありません。ただ、変更の粒度と頻度を上げながら事故を増やさないための設計論は、そこから素直に導けます。

事故の総量は、おおまかに「変更の回数 × 1回あたりの危険度」から「検知と復旧の速さ」を引いたものになります。回数を減らす方向に振ると、1回あたりの危険度が上がります。四半期に1回の大型リリースは、失敗したときの影響範囲も最大になります。

だから取るのは逆の戦略です。回数は増やしてよい。ただし1回を小さくし、失敗したら数分で戻せるようにする。DORA の指標でいえば、デプロイ頻度と変更失敗率、復旧までの時間を同時に見る形になります。

道具はもう十分にある

前提として、守る側の道具が足りないわけではありません。2026年3月31日、AWS は「AWS Security Agent」のオンデマンドペネトレーションテストを一般提供開始しました。AI のエージェントが設計書・IaC・ソースコードからアプリケーションの文脈を作り、マルチステップの攻撃を実行し、悪用可能だと検証できたものだけを報告します。GitHub と繋ぐとプルリクエストへのコメントや修正PRの作成まで行います。いまは AWS Continuum の一部として提供されています。

AWS 以外の選択肢もあります。設定と資産の可視化なら Google Cloud の Security Command Center、Microsoft の Defender for Cloud、Wiz。端末と実行時の検知なら CrowdStrike の Falcon、Microsoft Defender。SOC の一次対応を AI に寄せるなら Palo Alto Networks の Cortex。コードと依存関係なら Snyk。

カテゴリで整理すると、①設定・資産の可視化（CSPM/CNAPP）、②端末と実行時の検知（EDR/XDR）、③コードと依存関係（SAST/SCA/ASPM）、④攻撃の検証（ペネトレーションテスト）、⑤一次対応の自動化（AI-SOC）。どれも「買えば終わる」ものではありません。アラートを処理する運用に載せないと、半年で誰も見なくなります。

予算が通るなら、迷わず入れたほうがいいと思います。導入は数週間で終わります。ただし、買っただけでは効果は出ません。運用に載せるところ——見る人、優先順位の基準、対応手順、記録——の設計が本体で、ここは製品では埋まらず、年単位の仕事になります。

戻せる形が、最大の保険

変更管理で最も効くのは、ロールバックの速さです。設計として効かせる手段は4つあります。

段階的リリース: カナリア、ブルーグリーン、リング同期。全台に一気に配らない
フィーチャーフラグ: デプロイとリリースを分ける。コードは入れて、機能は後から点ける
スキーマの後方互換: expand → migrate → contract の3段階。旧コードと新コードが同時に動ける状態を作る
同一成果物の再適用: ビルドし直さず、検証済みの成果物（イメージ、パッケージ）を戻す

当社のサイト配信もこの形です。GitHub Actions が OIDC で AWS のロールを引受け、コンテナイメージを ECR に push し、Knative のサービス定義にはイメージダイジェストを固定して適用します。戻すときは前のリビジョンに戻すだけで、ビルドもテストもやり直しません。

ロールバックは手順書ではなく、コマンド1つか、CI の1ジョブにしておきます。そして一度は試験環境で実際に実行します。半年動かしていない手順は、いざというときに動きません。

検知できない変更は入れない

戻せても、異常に気づけなければ被害は広がります。変更と観測を紐付けるところまでを1セットにします。

デプロイ ID やリビジョン名を、アプリログ・アクセスログ・メトリクスの次元に入れる
SLO とエラーバジェットを決め、リリース可否の判断材料にする
カナリアの段階で自動判定し、閾値を超えたら自動で戻す
「異常がないこと」を確認できる指標を、変更の前に用意しておく（従来値との比較対象）

最後の項目が抜けやすいところです。新しい監視を足すと、比較する前の状態が残っていないことがあります。デプロイ前のベースラインを取る処理を、パイプラインに組み込みます。

パイプラインに載せる範囲

手を入れる対象を、人の記憶ではなくパイプラインに寄せます。インフラは Terraform でも CDK でも CloudFormation でも構いませんが、変更の履歴が残り、レビューを通り、同じ手順で再現できることが条件です。

セキュリティ側の検査も同じ流れに置きます。SAST、依存関係のスキャン（SCA）、IaC の設定検査、シークレットの混入検査、コンテナイメージのスキャン。検査を別チームの月次作業にすると、リリースと切り離されて形骸化します。

パイプライン自体の守りも同じくらい重要です。クラウドの認証は OIDC で短命の資格情報にし、長期のアクセスキーを CI に置かない。ロールは環境ごとに分け、本番だけ強い権限を持つ形にしない。ブランチ保護とレビューを必須にし、実行ログを保全する。ここが緩いと、変更管理の設計は全部無効になります。

夜間作業を前提にしない

「止めないと入れられない」を前提にすると、変更は深夜に集まり、まとめて大きくなります。夜間にしか入れられない理由は、たいてい分解できます。

依存が同期的で、片方だけ新しくできない → 後方互換の API か、二重書きの期間を作る
スキーマ変更が破壊的 → expand/contract に分ける
顧客の利用時間と重なる → 影響の窓を短くし、告知を運用に組み込む
監視が弱く、昼に入れるのが怖い → 検知を先に作る（順番が逆になりがち）

深夜作業は、それ自体が事故率を上げます。判断力の落ちた時間帯に、最も影響の大きい作業を置く設計は合理的ではありません。

IoTと生活インフラの難しさ

ここまでは、いつでも直せるサーバの話です。今後、標的は生活の側に移ります。監視カメラ、冷蔵庫、病院の設備、携帯電話、車、鉄道、航空。共通するのは、サーバの常識が通じないことです。

ファームウェアの更新が届かない、または更新自体ができない
10年以上動き続ける前提で、部品のEOLが保守期限より先に来る
認証情報が固定・共通で、変更する手段がない
止めると物理的に困る（医療、交通、製造ライン）

効く手段は、設計段階でしか入れられません。SBOM/CBOM を持ち、更新に署名を付け、A/B パーティションで失敗しても戻せるようにする。デバイスごとの証明書で識別し、ゲートウェイ側で通信先を絞る。更新の成功率と失敗を監視する。

規制も動いています。自動車は国連の UN-R155（サイバーセキュリティ）と ISO/SAE 21434、産業制御は IEC 62443、医療機器は米国で市販前の要件が課されます。制度が先に要求を決め、実装が後から追う領域です。

AIをどこまで任せるか

攻撃側が AI で速く動くなら、守る側も同じ道具を使う必要があります。ログの量は人では読み切れず、アラートの一次処理を人が全部やる運用は回りません。

任せてよい範囲は、失敗したときに戻せるかで決まります。読み取りと提案（ログの相関、影響範囲の推定、修正PRの作成、ペネトレーションテスト、設計書への指摘）は任せやすい。本番の設定変更やデータ削除は、人の承認を挟みます。

権限は最小から始める（読み取り専用 → ステージング → 本番は承認付き）
エージェントが読む外部入力（チケット、Web、PRコメント）は信頼しない。プロンプトインジェクションで誘導される前提で設計する
実行した操作と参照したデータを、後から出せる形で記録する
誤検知率と見逃し率を測る。導入効果を「アラートが減った」で測らない

当社が運用に入る現場でも、最初に決めるのは「AIに何を決めさせるか」ではなく「どこで人が止めるか」です。ここが曖昧なまま権限だけ渡すと、事故のときに説明ができません。

それでも残る限界

この設計で事故がゼロになるわけではありません。AI の検知は既知の型に強く、そのシステムの設計意図や業務の例外は読めません。誤検知はゼロになりません。カナリアをすり抜ける不具合も残ります。

変更を止めれば事故は減りますが、穴が残り、古いまま動き続けます。触れば事故、触らなければ傷む。この板挟みは、道具では解けません。解けるのは、戻す速さと、気づく速さと、説明できる記録の3つを用意したときだけです。

相談できること

当社は、変更の入れ方・戻し方・検知・記録の設計から入ります。パイプラインの整備、IaC への寄せ、ロールバック手順の試験、AI に任せる範囲の線引きまで、実際の構成に合わせて一緒に作ります。製品の導入は数週間、体制は年単位です。そこをお客さまのチームと一緒に作る前提で動いています。

同じテーマをビジネス向けに書いた版はこちらです: 最新の安全装備より、日々の運転

構成の現状と制約を伺ったうえで、優先順位をご提案します。お問い合わせください。

参考

Google「Site Reliability Engineering」第1章 — 「障害のおよそ70%は稼働中システムへの変更に起因する」という経験則（Change Management）
AWS「AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始」 — 2026年3月31日の一般提供開始、マルチステップ攻撃と悪用可能性の検証
AWS「AWS Security Agent の特徴」 — 設計書・コードからの文脈理解と GitHub 連携
国連条約集「UN Regulation No. 155」 — 自動車のサイバーセキュリティ規制（2021年1月22日登録）
IPA「情報セキュリティ10大脅威 2026」 — 組織編3位に「AIの利用をめぐるサイバーリスク」が初選出

2026年11月時点の公開情報と、当社の運用の経験に基づきます。製品の評価は提供元の説明によります。