この記事の目次
端末で見る詳細と、送る通知を分ける
- 端末内で確認
実行ファイルや対象の詳細を必要な範囲で見る。
- 承認した通知先へ
種類・件数・次の行動に絞れるか検討。
実例：実装者とレビュー役を分ける
元記事の再発防止スクリプトは、主にClaudeで作り、Codexがレビューしたものです。
最初に作ったのは、更新をまとめるweekly-updateと、更新前の版で動くプロセスを探すstale-procsです。別のAIがレビューすることで、作り手が見落とした情報漏えいの経路が見つかりました。
- 01Claudeが実装
- 02Codexが差分を確認
- 03修正して再レビュー
2回の指摘で何が変わったか
表がはみ出す場合は、横にスクロールして読めます。
| 段階 | 問題 | 学び |
|---|---|---|
| 最初の通知 | プロセスのコマンド・引数が出力されうる | 引数には認証情報が混ざる |
| 1回目の修正後 | ハイフン以外の引数を名前として採用 | 直接渡したコードやオプションの値も秘密になりうる |
| その後の修正 | 実在ファイルのファイル名だけを使い、それ以外は一般名にする | 表示情報を必要な項目へ絞る |
教材で示す悪い例は架空です。node app.js --password EXAMPLE_SECRETの引数を通知に出せば、通知先へ秘密を送ってしまいます。node -e 'EXAMPLE_CODE'のような直接実行の内容も、名前として表示してはいけません。
ファイル名にも個人情報が含まれる可能性があります。汎用の監視では、許可した種類名・件数・次の行動だけで足りるかを先に検討します。元の対策を、あらゆる環境で安全と保証するものではありません。
通知は「次に何をするか」まで
古い版の可能性がある対象：3件
種類：MCPサーバー
行動：作業を保存し、起動元アプリから再起動を検討
未確認：アプリ同梱ランタイムPIDや実行ファイルの詳細は端末内で確認し、通知には必要な情報だけを送ります。通知先への送信そのものも、利用者が管理・承認した範囲に限ります。
自動化には段階をつける
自動化は、確認できる段階から進める
- 観察する
停止せず、版や起動状況を見る。
- 人が判断する
対象と保存状況を確認して操作。
- 条件を絞る
誤検知・競合・保護対象を検証。
表がはみ出す場合は、横にスクロールして読めます。
| 段階 | 対象 | 判断 |
|---|---|---|
| 観察 | 版・起動時刻・更新状況 | 最初は停止せず一覧で確認 |
| 人が確認して操作 | 使用中のMCP・開発サーバー | 対象と保存状況を確認して再起動 |
| 条件を限定した自動化 | 十分に検証した休止対象 | 誤検知・競合・保護対象をテストしてから導入 |
停止の前に、もう一度対象を見よう。
親がいない、CPUを使っていない、古くから起動している、といった条件だけで「誰も使っていない」と断定しません。停止する直前に対象を再確認し、作業中セッションやデスクトップアプリを保護する必要があります。
自動停止は、保護対象や誤検知を検証してから段階的に導入します。
レビュー役が、何の設定で動くかも確かめる
実装するAIとレビューするAIを分けるとき、もう一つ確認したいのが、レビュー役を起動する場所と設定です。
Tsukinekoのガード検証記事（2026年10月18日公開、10月24日更新）では、レビュー対象のPR側にある設定を読み込んだままレビューを始める構成に、監査上の懸念を挙げています。記事で述べているのは追加検証が必要な懸念であり、この経路による攻撃の成立を確認したという報告ではありません。
レビュー対象と、レビューを動かす設定を分ける
- PR側：確認するデータ
変更コードや説明に、レビュー側の設定を決めさせない。
- 信頼できる側：実行条件
権限・ツール・起動設定を管理し、実際の起動元を確かめる。
学ぶ点は、変更され得るPRの内容と、レビューを動かす信頼済みの条件を分けることです。レビュー用の権限、秘密の受け渡し、ツールの起動元を確認し、PR内の設定を無条件に採用しません。具体的な設定方法は、使うレビュー製品とCIの公式資料に照らして決めます。
- 実行条件： どの場所から起動し、どの設定を読むかを実際の起動情報で確認する。
- 権限： レビューに不要な書き込み・公開・本番接続を付けない。
- 対象： レビューした差分の版と、反映する版が一致するかを確認する。
- 記録： レビューの出力へ秘密が混ざらないよう、残す項目を絞る。
会話やツール出力に残る情報は、AIの会話ログと秘密でも整理できます。
チーム・CI・クラウドへ広げる
- ランタイムの版指定と依存更新の通知先を決める。
- 依存更新PRは互換性と動作を検証してから反映する。
- ビルド時の版確認と、本番で実行している版の確認を分ける。
- 管理ランタイムの自動更新は設定・適用状況をサービスごとに確認する。
- 更新できない対象には担当者、期限、一時対応を残す。
大きいメジャー番号なら安全、とする自作判定は避けます。今回の対象系列と修正版の照合は、将来の未知の系列や別の脆弱性を安全と保証する判定ではありません。
出典と確認の範囲
書いた人
マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。
この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/operations/
このシリーズはここまで
次のテーマへ自分は直していないのに、更新が必要になるのはなぜ？
