Security 2026年8月28日

第12回 運用と初動 — 気づける状態を作り、起きたときに順番を間違えない

AI開発セキュリティ実践の最終回。何を記録し何を記録しないか、気づく経路の三本立て、事故が起きたときの初動5手順とよくある順番の間違い、四半期ごとの棚卸し、そして全12回を3層モデルへ戻して5つの原則にまとめます。

#情報セキュリティ #リスク管理 #AIガバナンス #Claude Code
難易度基本的な操作を一度試したことがある前提です種別学習コース

この回のキーメッセージ

目指すのは「事故が起きない状態」ではなく「起きたときに気づけて、正しい順番で動ける状態」です。初動は順番を間違えると被害が広がります。

ここまでの11回は、事故を起こしにくくする設計の話でした。それでも確率はゼロになりません。依存パッケージの発行経路が乗っ取られることもあれば、使っているサービスの側で侵害が起きることもあります。

そこで最後に扱うのが、気づく仕組み と 気づいたあとの手順 です。この2つは対で機能します。気づけなければ手順は始まりませんし、手順が決まっていなければ気づいても被害を広げるだけの行動を取ります。

実務で差が出るのは後者です。事故の直後は判断が急ぎがちで、良かれと思ってやった操作が調査を不可能にします。順番をあらかじめ決めておくことが、いちばん効く準備になります。

1. 気づける状態を作る

「ログを取る」から「気づいて動く」へ

OWASP Top 10 の 2025年版で、A09 は Security Logging & Alerting Failures へ名称が変わりました。旧版の Logging and Monitoring Failures から、Alerting という語に置き換わっています。焦点が「記録があるか」から「記録から気づいて動けるか」へ移った、と読むのが素直です。

ログは出ているが誰も見ていない、という状態は、監査の観点では合格でも、事故の観点では記録がないのとほとんど同じです。誰かの目に届くまでを設計に含める 必要があります。

同じ 2025年版では A10 として Mishandling of Exceptional Conditions が新設されました。エラー処理では、継続不能な失敗と縮退可能な失敗を分けること、失敗を握りつぶさないことが、そのまま記録の質にも効いてきます。

何を記録するか

すべてを記録すると量に埋もれて誰も見なくなります。あとから「誰が、いつ、何をしたか」を辿るのに必要な最小限 から始めます。

記録するものなぜ必要か
認証の失敗総当たりや漏れた資格情報の試行が、まとまった件数として見える
認可の拒否本来触れないはずのリソースへの到達試行。第8回で設計した境界が実際に効いた証跡になる
管理操作権限付与、ユーザー削除、設定変更。影響が大きく件数が少ないため、全件残せる
秘密情報へのアクセスどの実行主体がどの秘密を取り出したか。ローテーション範囲の判断に直結する
外部への大量送信通常運転との差分。持ち出しの兆候として最も分かりやすい
デプロイ何が、いつ、どのバージョンで出たか。事象の発生時刻と突き合わせる基準線になる

認可の拒否を残す意味は、第8回 で設計した所有者チェックが「動いている」ことの確認になる点にもあります。

記録してはいけないもの

記録の設計と同じ重さで決めるべきなのが、書かないもの です。

  • トークン、APIキー、パスワードなどの秘密値
  • 個人情報
  • リクエストやフォームの入力本文
  • 認証ヘッダを含む生のリクエスト

ログ自体が漏えい経路になる ためです。ログは秘密情報より広い範囲へ配られます。監視サービスへ転送され、CI の出力に出て、障害調査のためにチャットへ貼られます。秘密値をログに書くことは、その秘密の保管等級をいちばん緩い場所に合わせて下げることに等しくなります。

代わりに残すのは識別子です。ユーザーIDやリクエストIDのように、それ自体では意味を持たないが後から突き合わせられる値を出します。入力本文が必要に見える場面でも、長さや形式の検証結果だけで足りることが大半です。

エージェントの操作ログを、この文脈に置き直す

第4回 で PostToolUse を使った監査ログを組みました。あれは事故を止めるガードレールではなく、あとから何をやらせたかを追えるようにする記録 で、位置づけは上の表の「管理操作」に近いものです。

エージェントが関わる事故では、最初の問いがほぼ必ず「何を読んだか、どこへ書いたか、どのコマンドを実行したか」になります。この記録がないと、調査は本人の記憶から始まります。あれば、影響範囲の特定（後述の①）が最短で終わります。

書かないものの原則はここでも同じです。ツールの入力全文を残すとファイルの中身や秘密値が混ざるため、ツール名、対象パス、終了状態、時刻に絞ります。

気づく経路は三本立てにする

自前の監視だけに寄りかからないことが要点です。外から来る通知のほうが早いことは珍しくありません。

経路例特徴
プラットフォームの通知GitHub の secret scanning、Dependabot のアラート、利用サービスのセキュリティ告知設定コストが低く、検出範囲は自分で作れないほど広い
自前のアラート認証失敗の急増、外部送信量の異常、デプロイ失敗の連続自分のアプリ固有の異常はここでしか見えない
外部からの報告利用者からの問い合わせ、第三者の指摘遅いが、他の2つが見落としたものが来る。受け口を用意していないと届かない

GitHub の secret scanning と push protection は、パブリックリポジトリでは設定不要・無料で有効です。Dependabot はパブリック・プライベートを問わず無料で使えます。secret scanning のパートナープログラムでは、検出された資格情報が発行元へ通知され失効させられる仕組みも動いています。まず無料で有効にできるものを全部有効にする のが、費用対効果としては最初に来ます。詳細は 第11回 で扱いました。

三本目の「外部からの報告」は忘れられがちです。連絡先が公開されていなければ、指摘を受け取ることもできません。

2. 起きたときの初動 — この順番を守る

順番がこの回の核です。手順の中身より、順番のほうが被害の大きさを決めます。

#やること目的
①露出範囲を特定する何が、いつから、誰に見えたか。証跡を先に確保する
②止血するローテーション・失効・公開範囲の縮小
③影響を確認するその資格情報で何ができたか、実際に使われた形跡があるか
④恒久対策同じ経路が塞がったことを動作で確認する
⑤記録する次に同じことが起きたときの初動を早くする

① 露出範囲を特定する

最初にやるのは調査であって、対処ではありません。「何が」「いつから」「誰に見えたか」の3つを押さえます。

このとき最も重要なのは 証跡を先に確保する ことです。ログを消さない、リポジトリを消さない、コンテナを作り直さない。慌てて環境をきれいにすると、その時点で調査は終わります。ログのエクスポート、該当コミットのハッシュ、アクセス履歴の取得。手を動かす前に、消えるものから保全します。

「いつから」が分からないときは、最も古い可能性のある時刻 を仮の基準に置きます。範囲を狭く見積もると、後の影響確認が漏れます。

② 止血する

露出範囲が分かったら止めます。秘密値のローテーション、キーの失効、公開範囲の縮小、該当機能の一時停止。

ここでの原則は 漏れた値を再掲しない ことです。漏れたキーそのものを社内チャットへ貼る、チケット本文に書く、ログへ出力する。いずれも露出範囲を自分の手で広げる行為です。参照するときは「どの環境の、どの名前の変数か」で足ります。

ローテーションは、漏れた1本だけでなく 同じ場所に置かれていた一式 を対象にします。1つの環境変数が読めた状況では、隣も読めたと考えるのが妥当です。

③ 影響を確認する

止血は「これ以上広がらない」だけで、「使われていない」ことの証明にはなりません。2つを分けて確認します。

  • 何ができたか — その認証情報に紐づく権限の範囲。読み取りだけか、書き込みや削除まで可能だったか
  • 実際に使われた形跡があるか — 該当期間のアクセスログ、想定外のIPや時間帯、データ量の異常

「何ができたか」は権限設定から機械的に出せます。ここが広いほど確認の負担が増える、というのが 第2回・第3回 で権限を絞ってきた実利的な理由です。事故対応のコストは、平時に配った権限の広さに比例します。

④ 恒久対策

同じ経路が塞がったことを、設定画面ではなく動作で確認します。ポリシーを直したら、直す前に通っていた操作が実際に拒否されることを確かめる。第10回 のプリフライトと同じ考え方を、公開前ではなく事故後に適用する形です。可能ならこの確認を自動テストか CI へ落とします。人が思い出して実行する対策は、時間が経つと実行されなくなります。

⑤ 記録する

最後に、起きたことと対応を残します。目的は 次に同じことが起きたときの初動を早くすること で、責任追及の資料を作ることではありません。人を責める記録は、次から報告が上がってこなくなるという形で跳ね返ります。

残す項目は多くありません。時系列、影響範囲、実施したローテーションの一覧、恒久対策、そして「次に同じ兆候を見たら最初に何を見るか」。最後の1行が次回いちばん役に立ちます。

よくある順番の間違い

間違い何が起きるか
先にキーを消すキーに紐づくアクセスログや監査記録も一緒に消え、実際に使われたかが永久に分からなくなる
先に公開を止めて環境を作り直す調査対象そのものが消える。証跡の保全より前に「きれいにする」を置かない
慌てて秘密値をチャットへ貼る露出範囲を自分で広げる。共有は変数名と環境名で足りる
影響確認を飛ばして再発防止だけやる「もう安全です」と言えない状態のまま運用が再開される
①〜④が終わる前に社外へ確定的な説明をする後から範囲が広がったときに、訂正のコストが対応本体より大きくなる

3. ケース別の初動

秘密情報をコミットしてしまった

Git 履歴からの除去は必要ですが、本体はローテーションです。push 済みであれば、クローン・フォーク・CI キャッシュ・通知メールといった経路がすべて成立しえます。履歴を書き換えても、それらは戻りません。値の失効と再発行を先に、履歴の整理を後に置きます。除去作業をしている間、キーは生きたままです。あわせて push protection を有効にし、同じ経路が塞がったことを確認します。

依存パッケージが汚染された

Shai-Hulud 型の事例で狙われているのは、クラウド鍵・SSH鍵・環境変数といった、開発マシンとCIに置いてある認証情報 です。自己複製型のワームとして npm エコシステムへ広がり、2026年5月には npm と PyPI にまたがる派生も報告されています。

そのため初動は、パッケージのバージョンを戻すことではなく、そのマシンとCIに置いてある認証情報を洗い出すこと から始めます。インストールが走った時点で読める場所にあったものは、すべて対象です。

プレビュー環境が意図せず公開されていた

確認するのは2つです。何が見えていたか（本番データを向いていたか、管理画面が含まれていたか、クライアント側へ露出する環境変数に何が入っていたか）と、インデックスされていないか（検索エンジンのキャッシュ、外部サービスのプレビュー展開、CI ログに残ったURL）。URLが推測困難であることは保護になりません。保護機能が別途用意されているのは、既定で掛かっていないからです（第10回）。

使っているサービス側でインシデントが起きた

2026年4月に Vercel が公表したインシデントでは、サードパーティ製AIツールの OAuth アプリ侵害を起点に、Sensitive フラグの付いていない環境変数が一部顧客で列挙・復号されたと報告されています。Vercel は全顧客に対し、Sensitive でないものも含めた秘密のローテーション、MFA の有効化、アクティビティログの確認を推奨しました。

ここが実務上いちばん納得しづらいところですが、自分に落ち度がない事故でも、ローテーションと影響確認は自分の仕事になります。プラットフォームが直せるのは自分たちの側だけで、そこに預けた認証情報を新しくできるのは預けた側だけだからです。

前提として、告知を受け取る経路を持っておく必要があります。ステータスページやセキュリティ告知の購読が効いてくるのはこの場面です。

4. 使い続けるための定期点検

設定は入れた時点が最も正しく、そこから少しずつ実態とずれていきます。四半期ごとに次を見ます。

点検項目見るところ参照
permissions / 承認モードが今の作業に合っているか一時的に緩めたまま戻していない設定、使わなくなった許可第2回 / 第3回
Hooks が実際に動いているか意図的に引っかかる操作を1つ流して、止まることを確認する第4回
MCP サーバーの棚卸し接続一覧を出し、使っていないものを外す。付与スコープを見直す第5回
生成AIツールの設定がプラン変更で戻っていないかデータの取り扱い設定、共有範囲、組織ポリシーの適用状態第6回
依存とキーの棚卸し未更新の依存、使われていないキー、最終ローテーション日第11回
レビュー観点が今のコードベースに合っているかチェックリストで一度も引っかかっていない項目、逆にすり抜けた事故第7回 / 第9回

「Hooks が実際に動いているか」を独立した項目にしているのは、設定してあることと動いていることは別だから です。記法が変わった、パスが変わった、スクリプトの実行権限が落ちた。いずれも静かに失敗し、静かに素通りします。動作で確認する以外に知る方法はありません。

MCP の棚卸しは外す判断が中心です。接続先は増えることはあっても減りません。使っていないサーバーは、価値をもたらさずに攻撃面だけを提供します。

5. 連載を束ねる

12回を3層へ戻す

第1回 で置いた3層モデルに、各回を配置します。

層回その回で決めること
エージェント層第2回Claude Code に何を許し、何を都度確認にするか
第3回Codex の承認モードとサンドボックスの選び方
第4回機械的に止めるものと、記録に留めるものの切り分け
第5回外部入力の入口をどこまで開けるか。lethal trifecta の数え方
第6回ツール側の設定で下げられるリスクの範囲
生成物層第7回機械に任せる検査と、人が見る観点の分担
第8回認可をどの境界で強制するか
第9回入出力と外部連携で検証する位置
実行基盤層第10回公開前に動作で確認する項目
第11回秘密の保管等級と、依存の受け入れ方
第12回（本記事）気づく仕組みと、起きたときの順番

層をまたいで効く対策はありません。逆に言えば、どの層の話かを最初に特定すれば、打つ手の候補は3分の1に絞れます。

5つの原則

12回を通して繰り返し出てきた判断基準を、5つに畳みます。

  1. 権限は足りない状態から始める。 必要になったときに足すほうが、配ってから回収するより安全で、実は手間も少なくなります。事故対応のコストは、平時に配った権限の広さに比例します
  2. lethal trifecta を3つ揃えない。 プライベートデータへのアクセス、非信頼コンテンツへの露出、外部への通信能力。攻撃を検知しようとするより、3つ目を揃わせないほうが設計として安定します
  3. 機械が確実にできる検査を、人間の注意力の前に置く。 秘密情報の検出、型チェック、依存の脆弱性、フォーマット。人が見るべき箇所を絞り込むために、機械で落とせるものは機械で落とします
  4. 設定したことと、動いていることを区別する。 ポリシーを書いた、Hooks を置いた、フラグを付けた。いずれも「掛かっている」ことの証明ではありません。動作で確認したものだけを、確認済みとして数えます
  5. マネージドサービスも、自分で設定した分だけ守られる。 機能があることと既定で有効なことは別で、プランによって使える範囲も違います。そして提供者側が侵害されたとき、預けた認証情報を新しくできるのは預けた側だけです

この5つは、新しいツールが出るたびに覚え直す種類の知識ではありません。判断の軸として持っておくと、この連載で扱っていないサービスに対しても同じ問いを立てられます。

まとめ

  • OWASP Top 10 の 2025年版で A09 が Security Logging & Alerting Failures へ改称されたとおり、焦点は「記録があるか」から「気づいて動けるか」へ移っています。誰かの目に届くまでを設計に含めます
  • ログに秘密値・個人情報・入力本文を書きません。ログは秘密情報より広い範囲へ配られるため、書いた時点で保管等級がいちばん緩い場所に下がります
  • 初動の順番は、露出範囲の特定 → 止血 → 影響確認 → 恒久対策 → 記録です。先にキーを消す、先に環境を作り直すといった行動は、証跡を消して調査を不可能にします
  • 自分に落ち度がないインシデントでも、ローテーションと影響確認は利用者側の仕事になります。預けた資格情報を新しくできるのは預けた側だけです
  • 四半期ごとに、権限・Hooks・MCP・ツール設定・依存とキーを棚卸しします。設定してあることと動いていることは別 なので、動作で確認します

事故を完全に防ぐ設計はありません。この連載で組んできたのは、確率を下げ、起きたときの影響範囲を小さくし、気づくまでの時間を短くするための仕組みです。

ルールを組織としてどう作るかは AI導入ガバナンス解説、その中で日々AIを使う側の判断軸は 業務AI安全利用ガイド が扱っています。実装者としての設定を終えたら、次はその2つの層と接続すると全体がつながります。

参考リンク