サイトやアプリを自分で作るようになったら、脆弱性(セキュリティの弱点)のニュースが他人事ではなくなりました。その対策を自動化できないか、という実験の記録です。
※最初に正直に書いておきます。これは構想段階のものです。全部が動いているわけではありません。「どこまで動いていて、どこからが構想か」を分けて書きます。
きっかけ
ある日、受講中の学習システムが、PHPという仕組みの重大な脆弱性への対応で緊急メンテナンスに入り、1週間近く止まりました。
「脆弱性が見つかったら、自分の使っているものが対象かどうかを調べるのに、こんなに時間がかかるのか」と実感したのが始まりです。
ニュースは毎日のように出ます。でも大事なのは「世界で何か起きたか」ではなく、「自分の環境が対象か」です。そこを自動で照合できたら、と思いました。
構想の全体像
役割は2つに分けています。
・dots(監視役):公式発表・脆弱性データベース・不具合報告などの公開情報を定期的に監視し、あらかじめ登録した自分の環境(サイト・アプリ・ソフトとバージョン)と照合して、対象を特定する
・Codex(実行役):引き継ぎを受けて、影響確認・レビュー・事前テストを行い、許可した範囲でだけ更新し、動作確認と復旧まで担当する
異常があったら更新は止める。勝手に本番を触らない。「許可した範囲でだけ」という線引きが、この構想で一番大事にしている点です。
流れは6ステップ
1. 公開情報を継続監視する
2. 登録環境と照合し、対象・根拠・公式の修正版情報をまとめてCodexへ引き継ぐ
3. Codexが影響確認・レビュー・事前テスト(修正版がない/検証に落ちたら保留して通知)
4. テスト合格後、許可した範囲で更新する
5. 更新後の動作確認。異常時は止めて、可能なら復旧する
6. 結果をまとめて報告し、次の監視に戻る
正直ポイント:動いている所と、まだの所
動いている所
・重大な脆弱性の監視:公式情報源を定期確認し、重大なものだけ拾う運用をしています
・Codexへの引き継ぎ:メールでアラートを渡す方式で実際に回っています(テスト送信で、受信・重複判定まで確認済み)
・Codex側の確認:毎日9時と21時に確認し、結果をメールで返す運用です。「対象外」「変化なし」の時も返ってきます
まだの所
・「24時間の継続監視」までは未達です(現状は定時確認)
・照合の完全自動化は途中です。登録環境の情報が一部そろっていない所があります
・自動更新・復旧は検証前です。ここが一番危険な部分なので、実機で確かめるまで手を出しません
実際に回った例
2026年10月27日の朝、PHPの重大な脆弱性が2件出ました。
アラートが送られ、Codexが登録済みの環境(9つのサイトやMac、開発中のアプリなど)を確認し、「対象のPHP環境は検出されず、対応は不要」という結果が返ってきました。
全部自動、ではありません。でも「ニュースを見て不安になる」から「自分の環境は対象外だと分かる」までの距離は、確実に短くなりました。
なぜ公開するか
まだ構想だからです。
検証が進んで、「自分の環境向けに、同じ見守りの仕組みを作る手順」としてまとめられるようになったら、その時に作り方をまとめるかもしれません。ま
ずはこの形で公開して、同じように小さなサイトやアプリを運用している人の反応を見たいと思っています。
おわりに
あなたの使っているサイトやアプリの「環境リスト」、すぐに書き出せますか? 私は書き出せませんでした。パッチキーパーは、その問いへの自分なりの答えの途中経過です。
進展があったら、また正直に報告していきます。