WEBサイトSiteGuard Server Editionの脆弱性は、開発元が悪用を確認している。更新の前に診断情報を保存する ── サイトの前に置いた部品の台帳を作って確認する13項目（2026年10月時点）
SiteGuard Server Editionの脆弱性は、開発元が悪用を確認している。更新の前に診断情報を保存する ── サイトの前に置いた部品の台帳を作って確認する13項目（2026年10月時点）
目次
01 何が起きたか・いま最新の版は何か — サイトを守る製品のほうに、悪用されている脆弱性が見つかった
2026年10月14日に公表され、開発元は悪用を確認している
WAF（Web Application Firewall・ウェブアプリケーションへの攻撃を見分けて止める仕組み）の製品「SiteGuard Server Edition」に、OSコマンドインジェクションの脆弱性（CVE-2026-106931）が見つかった。開発元のEGセキュアソリューションズが2026年10月14日に公表し、同じ日に、JPCERT/CCが注意喚起（JPCERT-AT-2026-0032）を出した。10月20日には、米国のCISAが、悪用が確認された脆弱性の一覧（KEV）に加えている。2026年10月23日に、これらのページを開いて読んだ。
結論から書く。サイトを守るために置いた製品も、攻撃の入口になりうる。対象の版を使っているなら、更新の前に「診断情報」を保存する。使っていなくても、サイトの前に置いている部品の一覧（この記事では「台帳」と呼ぶ）を作っておくと、次の知らせに数分で答えられる。台帳という進め方は、この記事の提案であり、公式の手順ではない。
本脆弱性の悪用により、当該製品が動作するサーバー上で、rootまたはSYSTEM権限で任意のOSコマンドが実行される可能性があります。EGセキュアソリューションズ株式会社は、本脆弱性の悪用を確認しているとのことです。
上の引用は、JPCERT/CCの注意喚起の「概要」の文である。同じ注意喚起は、この製品が国内で広く利用されていることをJPCERT/CCが確認している、とも書いている（要旨）。
対象は、Ver2.20以降で、統計機能が有効な版
対象の版は、04章の表に原文のまま写した。ここでは条件だけ書く。製品の版が古いだけでなく、統計機能が有効であることも、影響を受ける条件に入っている。JPCERT/CC、開発元、JVNの3つが、同じ条件を書いている。
当該製品においてデフォルトで有効となっている統計機能が有効な場合に本脆弱性の影響を受けます。
統計機能は、初期値で有効である。何も設定を変えていなければ、有効のまま動いている。
更新の前に、診断情報を保存する
この件で、読み落とすと取り返しがつかないのは、作業の順番である。開発元は、更新やパッチの適用で、攻撃の痕跡が消える可能性がある、と書いている。
アップデートの前に必ず：「診断情報」をダウンロードして保管してください（攻撃の痕跡が消える可能性があります）
保存の場所は、開発元のページに画面の経路で書かれている。ウェブ管理画面の［診断情報］から［診断情報をダウンロード］を選ぶ。更新が先で、診断情報があとになると、保存するものが無くなる。順番を間違えないよう、05章のチェックリストでは、診断情報の項目を更新の項目より前に置いた。
この記事が根拠にした文書と、その日付
日付は、各ページに書かれている表記を写した。CISAの一覧は、公開されているデータの項目を読んだ。
| 文書 | 日付（ページの表記） | 使いどころ |
|---|---|---|
| JPCERT/CC 注意喚起 JPCERT-AT-2026-0032 | 2026年10月14日（公開日・最終更新とも） | 概要、対象、対策、回避策、更新の注意 |
| EGセキュアソリューションズ「SiteGuard Server EditionにおけるOSコマンドインジェクションの脆弱性(緊急)」 | 2026年10月14日 | 影響範囲、修正された版、痕跡の保全方法 |
| JVN#88474777 | 2026年10月14日（公開日・最終更新日とも） | CVSSの表記、修正された版 |
| CISA Known Exploited Vulnerabilities Catalog（公開データ） | 追加日 2026年10月20日 | 悪用が確認された脆弱性としての掲載 |
| EGセキュアソリューションズ「php2shellとSiteGuardシリーズの対応について」 | 2026年10月22日 | WAFの限界についての開発元自身の書き方 |
02 なぜ・背景 — 統計機能の欠陥で、製品が動くサーバーの上の強い権限が取られうる
統計機能は初期値で有効で、無効にすることが回避策になる
脆弱性があるのは、WAF本体の検知の仕組みではなく、統計機能である。JPCERT/CCの注意喚起は、回避策（IV）として、統計機能を無効にすることで、この脆弱性の影響を避けられる、と書いている。開発元の告知とJVNが挙げている対策は、更新とパッチの2つで、無効化は書かれていない。無効化の手順は、JPCERT/CCも自分では書かず、開発元の最新の情報を見るように促している。手順は開発元のページで確かめる。この記事には写さない。開発元の製品ページには、攻撃の検出状況を集計して表示する「統計・レポートの機能」がある、と書かれている。脆弱性の「統計機能」が、これと同じものかどうかは、原典に明記が無い。
実行される権限は、rootまたはSYSTEMと書かれている
rootはLinuxやFreeBSDで、SYSTEMはWindowsで、それぞれ最も強い権限にあたる。サーバーの上でこの権限のコマンドが動けば、WAFの設定だけでなく、同じサーバーの中の他のものにも届く。製品が動くサーバーを、他のサイトと共用している場合は、他のサイトも対象になりうる。ただし、どこまで届くかは、サーバーごとの作りで変わる。原典はそこまで書いていない。
契約のある顧客には、公表の約2週間前に個別の案内が出ていた
開発元のページには、サポート契約のある顧客には、2026年9月29日に個別に案内済みだ、とある（要旨）。公表は10月14日なので、契約の窓口を通じた案内は、約2週間先に出ていたことになる。契約している側は、その案内が自分に届いていたかを確かめられる。届いていなかったなら、案内の宛先が古い担当者のままかもしれない。05章に、契約の窓口へ聞く項目を入れた。
CVSSの表記は、原典のとおりに写す
開発元とJVNは、CVSS v4.0で基本値8.5、v3.0で基本値7.8、と書いている。ベクターの文字列は、どちらも攻撃元の区分が「AV:L」で始まる。CVSSの定義では、Lはローカルを指す。この記事では、この表記から攻撃の経路を読み取らない。攻撃の経路を詳しく書いた文書は、開いた範囲に無かった。数字の大小で急ぐかどうかを決めず、悪用が確認されているという事実で急ぐ。
開発元は、別の件で「WAFによる完全な対策は困難」と書いた
2026年10月22日の告知は、PHPの重大な脆弱性（php2shell）に触れている。そこで開発元は、検知の署名を出したと書いたうえで、WAFで防ぎきれない、と明記している。
しかしながら、本件の影響範囲は幅広く、WAFによる完全な対策は困難なため、前述のとおり、開発元から提供されている情報をもとに、対策することを最優先でご検討いただきますようお願い申し上げます。
WAFは追加の層であり、更新の代わりにはならない。この考え方は、記事「PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）」で扱った。今回の件は、その続きに当たる。守られる側のソフトの更新も、守る側の製品の更新も、同じ重さで要る。
CISAの一覧に入ったことの読み方
CISAの一覧は、悪用が確認された脆弱性の一覧である。この件の項目の「必要な対応」の欄には、次の1文がある。
Apply mitigations in accordance with vendor instructions
（訳: 開発元の指示に従って、緩和策を適用する。）
項目には、対応の期限（dueDate）として2026年10月23日が記録されている。同じ欄は、CISAの指令BOD 26-04と、その中の「Forensics Triage Requirements」に従うように、という趣旨を書いている（要旨）。BOD 26-04のページは、この指令の適用先を、米国の連邦政府の文民行政機関（Federal Civilian Executive Branch）のシステムと説明している（要旨）。この期限は、日本の事業者に向けた期限ではない。それでも、CISAが同じ指令の実施手引きに書いた、保全と更新の順番は、日本の事業者にも参考になる。
CISAの手引きも、証拠の保全を、パッチより先に置いている
実施手引きには、KEVに加わった脆弱性への対応が6つの段として並んでいる。見出しは、「Step 1: Scoping」「Step 2: Preserve and Collect Evidence」「Step 3: Critical Patching and Stabilization」「Step 4: Contain and Control」「Step 5: Triage Analysis」「Step 6: Escalation Decision」の順である。証拠の保全（2番目）が、パッチ（3番目）より前に来る。3番目の段には、保全の理由が書かれている。
Collect all required evidence prior to this step as patching may jeopardize the availability of artifacts.
（訳: パッチを当てると、痕跡として使える材料が失われるおそれがあるので、必要な証拠はすべて、この段の前に集める。）
開発元の案内と同じ順番である。痕跡を残したいなら、直す前に集める。この手引きは、連邦機関向けの手引きであり、民間の義務ではない。
03 用語 — この記事で使う5つの言葉
WAF、ホスト型、OSコマンドインジェクション、診断情報、KEV
用語
WAF：Webアプリケーションファイアウォール。サイトに届く通信の中身を見て、攻撃らしいものを止める仕組み。置き方は、サーバーに組み込む形、サーバーの前に置く形、クラウドで使う形などに分かれる。
用語
ホスト型WAF：Webサーバーの中に組み込んで使うWAF。JVNは、SiteGuard Server Editionを、Webサーバーに組み込んで使うホスト型のWAFと説明している。開発元の製品ページは、リバースプロキシに導入してゲートウェイ型の構成で使うこともでき、その場合のライセンスは「プロキシライセンス」だが、製品はServer Editionのままだと書いている（要旨）。製品が動くサーバーが侵害されると、WAFだけでなく、同じサーバーの上のサイトにも影響しうる。
用語
OSコマンドインジェクション：外から与えた文字列が、サーバーのOSのコマンドとして実行されてしまう欠陥。CWEの番号はCWE-78で、JVNと開発元は、この脆弱性をCWE-78に分類している。
用語
診断情報：開発元が、ウェブ管理画面から取り出せるようにしている情報。開発元は、更新の前に取得して保管し、攻撃の痕跡を残すよう案内している。中に何が入っているかは、開いた文書に書かれていない。
用語
KEV（Known Exploited Vulnerabilities）：CISAが公開している、悪用が確認された脆弱性の一覧。載っていることは、悪用が確認されているという意味であり、自分のサイトが攻撃されたという意味ではない。
04 型別 — 対象の版を原文のまま確かめ、測られていないことを分け、手順を5つに分ける
🅰 適用範囲 — 版の範囲は、原文のとおりに読む
次の表は、JPCERT/CC、開発元、JVNの記載を、言い換えずに並べたものである。「Ver2.20以降」という書き方に注意してほしい。
| 製品の種類・条件 | 影響を受ける版 | 修正された版 | 原典の書き方 |
|---|---|---|---|
| Apache版、Nginx版、IIS版 | Ver2.20以降で、Ver8.00 Update5より前のバージョン | Ver8.00 Update5（FreeBSDを除く） | 対象 |
| FreeBSD Apache版、Nginx版 | Ver2.20以降で、Ver7.00 Update6より前のバージョン | Ver7.00 Update6 | 対象 |
| IIS版 Ver3.10からVer4.00 Update4 | 影響を受けない | — | 対象外と明記 |
| 統計機能を無効にしている場合 | 統計機能が有効な場合に影響を受ける、と書かれている | — | JPCERT/CCが回避策として明記。開発元とJVNは、更新とパッチだけ |
| Ver2.20より前の版 | 書かれていない | 書かれていない | 記載なし。開発元に確かめる（この記事の整理） |
| Proxy Edition、Cloud Edition | 対象として挙がっていない | — | 対象外とも書かれていない。使っているなら開発元に確かめる（この記事の整理） |
表の「影響を受ける版」は、どれも統計機能が有効な場合の話である。「対象外と明記」されているのはIIS版の一部だけで、他の行は、書かれていないことを「安全」と読まない。パッチは、バージョンアップが困難な利用者向けに用意されていて、サポート終了バージョンを含む、と書かれている。
製品の構成は、開発元の製品ページでは3つのライセンスに分かれている
開発元の製品ページは、基本の構成を、保護するWebサーバーのモジュールとして入れるホスト型だと書いている。ライセンスは、通常、マネージド、プロキシの3つに分かれる。マネージドライセンスは、設定変更などの作業を開発元の専門のエンジニアが担当し、複数台の集中管理ができる、と書かれている（要旨）。プロキシライセンスは、ApacheやNginxのリバースプロキシの上で動かし、複数のWebサーバーを保護できる、とある（要旨）。どのライセンスで使っているかによって、誰が版を上げるかが変わる。05章の項目は、その窓口を確かめる。
被害の件数や、使っているサイトの数は、原典に書かれていない
JPCERT/CC、開発元、JVN、CISAの文書には、被害を受けた件数や、製品を使っているサイトの数は、書かれていなかった。この記事も、件数は書かない。数字として載っているのは、CVSSの基本値、版の番号、案内や公表の日付である。
🅱 その調査が測っていないこと — Ver2.20より前の版、攻撃の経路、侵害の有無
文書が書いていないことを、3つに分けた。1つ目は、Ver2.20より前の版が影響を受けるかどうかである。原典は「Ver2.20以降」を対象としていて、それより前の版には何も書いていない。「書かれていないから安全」とは読めない。古い版を使っているなら、開発元に確かめる。
2つ目は、攻撃の経路と、痕跡の具体である。どのような通信で悪用されるか、診断情報のどこに痕跡が出るかは、開いた文書に無かった。この記事も書かない。3つ目は、自分のサイトが侵害されたかどうかである。公表を読んだだけでは分からない。侵害調査は、開発元の案内とJPCERT/CCの窓口に沿って進める。
🅲 手順 — 5つの段に分ける
手順は、公式の文書の順序を、次の5つの段に並べ直したものである。5段への分け方は、この記事の提案である。
1段目は、版と統計機能を確かめる。管理画面で版を開き、表の「修正された版」と比べる。統計機能が有効かも、同じ画面で見る。2段目は、診断情報を保存する。対象の版なら、更新の前に必ず行う。3段目は、直す。更新、パッチ、統計機能の無効化のうち、1つを選ぶ。4段目は、侵害調査の担当を決める。更新で痕跡が消えうるので、3段目の前に保存した診断情報が、この調査の材料になる。5段目は、台帳に書く。何を、いつ、誰が直したかを残す。
注意
診断情報を保存する前に、更新やパッチの作業を始めない。更新の予定日が決まっている場合でも、診断情報の取得は、その前の日に済ませてよい。保管の場所は、製品が動くサーバーの外に置く。サーバーの中に置くと、侵害されたときに一緒に触られうる。
05 サイトの前に置いた部品を確かめるチェックリスト
下の13項目は、1項目5分ほどでできる作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。管理画面を開く項目は、自分が管理する製品にだけ行う。
- 担当サイトごとに、サイトの前に置いている部品（WAF・CDN・ロードバランサー・リバースプロキシ）を、3つまで書き出す
- 各部品の製品名と提供元を、契約書か請求書で確かめ、台帳の1行目に書く
- 台帳の製品名を上から追い、SiteGuardを含む行を数えて、本数と種類（Server Edition・Proxy Edition・Cloud Edition）を書き、リバースプロキシに入れたServer Editionは、Server Editionの行に書く
- サポート契約があるなら、窓口に、2026年9月29日付の個別の案内が届いていたかを聞き、答えを日付つきで書く
- Server Editionの管理画面を開き、版を書き出して、04章の表の修正された版と比べ、対象か対象外かを書く
- 同じ管理画面で、統計機能が有効か無効かを見て、台帳に書く
- 更新やパッチの作業の前に、管理画面の［診断情報］から［診断情報をダウンロード］を実行し、保存した日時とファイル名を書く
- 診断情報のファイルを、製品が動くサーバーの外の保管場所に1つ置き、置いた場所を台帳に書く
- 更新、パッチ、統計機能の無効化のうち、使う方法を1つ決め、作業する日付を書く
- 作業のあと、管理画面で版が修正された版になっているかを見て、サイトのトップを含む3ページを開き、表示を確かめる
- 侵害調査を担当する人を1人決め、開発元の窓口とJPCERT/CC（ew-info@jpcert.or.jp）のどちらに相談するかを書く
- 管理画面のURLを、社外の回線（携帯回線など）から1回開き、開けたかどうかを台帳に書く
- 各部品の行に、更新の知らせを受け取る人の名前と、開発元か販売店の連絡先を1つずつ書く
時間がないときは、項目1・3・5・7の4つだけでも、状況はつかめる。
06 代替・他の選択肢 — 直し方は3つで、サイトの前の部品は台帳で見張る
直し方は、更新、パッチ、統計機能の無効化の3つ
更新とパッチは、開発元とJVNとJPCERT/CCが挙げている。統計機能の無効化は、JPCERT/CCだけが回避策として挙げている。次の表は、書かれている範囲を並べたものである。向く場面の列は、この記事の整理である。
| 直し方 | 原典の書き方 | 向く場面（この記事の整理） |
|---|---|---|
| 修正された版へ更新する | 開発元は、修正されたバージョンへのアップデートを推奨している | 更新できる状態で、作業の時間が取れるとき |
| パッチを適用する | バージョンアップが困難な利用者向けに、統計処理の対象ファイルを差し替えるパッチを提供している（サポート終了バージョンを含む） | 版を上げる試験に時間がかかるとき |
| 統計機能を無効にする | JPCERT/CCが回避策として記載し、手順は開発元の最新の情報を見るよう促している。開発元とJVNには記載がない | 更新とパッチの両方がすぐにはできないとき |
更新とパッチは、診断情報の保存が先である（開発元の案内）。無効化は、保存を先にする根拠が原典に書かれていないので、先にするのはこの記事の提案である。無効化の手順は、この記事に写さず、開発元のページで確かめる。
3つの道の手順は、原典の書いた順番のまま並べる
次の3つの並びは、JPCERT/CCと開発元の記載の順番を、そのまま番号にしたものである。手順の細部（ファイル名や設定の書き方）は、開発元のページで確かめる。
更新の道は、次の順である。1. ウェブ管理画面の［診断情報］から［診断情報をダウンロード］で診断情報を取り、保管する。2. 開発元が提供する情報をもとに、修正されたバージョンへアップデートする。
パッチの道は、バージョンアップが困難な利用者向けで、サポート終了バージョンも含む。1. 適用の前に診断情報を取り、保管する。2. 統計処理の対象ファイルを差し替えるパッチを、開発元の案内で適用する。
統計機能を無効にする道は、JPCERT/CCだけが回避策として挙げていて、手順は自分では書かず、開発元の最新の情報を見るよう促している。開発元の告知とJVNには、無効化の記載がない。無効にする前に診断情報を取るかどうかは、原典に書かれていない。この記事は、変更の前に診断情報を保存することを提案する。この1行は、公式の手順ではない。
場面別の使い道 — 管理会社に聞く場合と、自社で確かめる場合
誰が製品を運用しているかで、やることが分かれる。次の4つの場面は、開発元の製品ページとサポートの案内の書き方をもとにした、この記事の整理である。
場面1は、制作会社や管理会社が運用している場合である。マネージドライセンスのように、設定変更を専門の担当者が行う契約もある（製品ページの要旨）。管理会社には、製品の種類と版、統計機能の有効・無効、診断情報を保存したか、作業の予定日を聞く。場面2は、自社で運用している場合である。管理画面で版と統計機能を見て、05章の順に進める。
場面3は、サポート契約があり、案内が届いていたか分からない場合である。開発元は、サポートの窓口を、納品時の契約内容確認書か、契約した販売店だと書いている（要旨）。そこに、9月29日付の個別の案内が来ていたかを聞く。場面4は、環境の提供元がWAFを組み込んでいる場合である。自分では入れた覚えがなくても、提供元に、製品名と版と更新の担当を聞く。
台帳の作り方 — 6つの列で足りる
台帳は、表計算の1枚で足りる。サイトの前に置く部品1つにつき、1行を書く。列は、次の6つにした。部品の名前、製品名と種類、版、管理する人、更新の知らせの窓口、管理画面を社外から開けるか、である。記事「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）」は、PHPの版の台帳を扱った。部品の台帳は、その隣に置ける。
管理画面は、外から開けなくする
JPCERT/CCの別の注意喚起（JPCERT-AT-2026-0030・2026年10月8日公開、10月23日更新）は、汎用的な対策の1つに、次の項目を挙げている。
業務上必要のないサービスや機能（管理機能など）がインターネットに公開されている場合、公開を停止する
この引用は、SiteGuardの件に向けて書かれた文ではない。それでも、守る製品の管理画面が社外から開けるなら、攻撃の面が1つ増えている。05章の12番目の項目は、これを確かめる。見つかった場合の閉じ方は、製品と環境で変わるので、開発元か構築した事業者に聞く。
環境に組み込まれているWAFも、台帳に載せる
レンタルサーバーやマネージドの環境の中には、WAFが標準で組み込まれているものがある。自分で入れた覚えがなくても、使っている環境の側に入っていることがある。入れた覚えがない部品こそ、台帳の行に書く。環境の提供元に、WAFが入っているか、入っているなら製品名と版と更新の担当を、問い合わせる。
見つけた後の作業は、記録に残す
台帳に、作業の日付と、診断情報を保存した場所を残す。あとから、更新の前に診断情報を取ったかを問われても、日付で答えられる。ログの保存の範囲や、「0件」の書き方は、記事「「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直した」と、記事「AIは331回来たと書いた。実際は11,024回だった ── HTTPのログだけを52日間 見ていた」に書いた。
07 この記事を書くために確かめたことと、確かめていないこと
開いたものと、読み方
2026年10月23日に、01章の表の文書と、CISAの指令BOD 26-04のページ、その実施手引き、開発元の製品ページを開いた。引用した日本語の文と英文は、開いたページの本文と機械で照らし、すべて一致した。照らせなかった文は、引用の形にしていない。CISAの一覧の情報は、公開されているデータを取得して、項目を読んだ。BOD 26-04のページ、実施手引き、製品ページには、日付の表記が見当たらなかったので、日付は書いていない。
確かめていないこと
4つある。1つ目は、診断情報の中身と、管理画面の操作の画面である。製品を持っていないので、画面は開いていない。2つ目は、無効化の手順である。JPCERT/CCは開発元の最新の情報を見るよう促していて、この記事は写していない。開発元の告知とJVNには、無効化の記載自体がなかった。3つ目は、Ver2.20より前の版の扱いである。4つ目は、脆弱性の「統計機能」と、製品ページにある「統計・レポートの機能」が、同じものかどうかである。原典は、同じだとも違うとも書いていない。
当サイトの運営の記録
当サイトもこの記事の手順で確かめた。製品の名前、版、設定の中身、管理画面の置き場所は、書かない。
数え方の限界
5段の分け方、台帳の6つの列、向く場面の列は、この記事の整理で、公式の分類ではない。台帳が埋まっても、その部品が安全であるとは言えない。台帳は、知らせが来たときに、自分の側に該当があるかを数分で答えるための道具である。点検の道具の「0件」は、探した範囲の中での0件でしかない。記事「PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録」は、更新の順番と、更新のあとに確かめることを扱った。
08 このテーマの、これまで — 同じ週に、攻撃を防ぐ側の話が続いた
2026年10月14日からの流れ
開いた文書の日付を並べると、この週の流れは次のようになる。10月14日にSiteGuard Server Editionの脆弱性が公表され、10月20日にCISAの一覧に加わった。10月22日には、開発元が、PHPの重大な脆弱性（php2shell）への対応を告知し、WAFだけでは防ぎきれない、と書いた。防ぐ側の製品も、防がれる側のソフトも、同じ週に更新の対象になった。この並びは、日付を並べたものであり、2つの件に関係があるという意味ではない。
当サイトでこの周辺を扱った記事
記事「PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）」は、痕跡を探すときの、ログの落とし方を扱った。診断情報を保存したあとの調査でも、同じ落とし方に注意する。記事「公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す ── 自社と担当サイトの.bak・.old・日付付きの写しを棚卸しする13項目（2026年10月時点）」は、更新の作業で生まれる控えの扱いを扱った。ブログの記事「記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった」は、サーバーのソフトの更新の例である。
外へつなぐ通信の台帳という、似た形
ブログの記事「認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録」は、サーバーから外へつなぐ先の一覧を作る話だった。今回の台帳は、サイトの前に置く部品の一覧である。向きは逆だが、知らせが来たときに、数分で答えるための一覧という点は同じである。
現在の貴方のIPアドレス
このサイトで書いている人
