WEBサイト
2026年9月8日の見直しで、本番のコードの1か所が、試験用の環境の設定ファイルを読んでいるのが見つかった。中身は本番側の設定と同じで、実害は無いと判断して記録し、直さなかった。それから62日たった11月9日、未完了の作業の一覧を見直していた別の担当が、この件を「止まっているのに、待ちの印すら付いていない項目」として挙げた。測り直すと、設定の中身は今も一致していた。同じ日のうちに、本番の読み先を、本番の側の設定へ1行で直した。
この記事は、その経緯と、直した前後の確かめ方、直したあとで本番のコードの中にある「試験環境の名前」を数えた結果を書く。数えた結果は、本番のコード2,615本のうち19本だった。ただし19本の1本ずつが問題かどうかは、まだ判定していない。「数えただけで、判定はこれから」というのが、この記事の時点の正直な現在地だ。
読み終えたら、担当サイトで「本番が、試験や開発の環境を見に行っていないか」を、名前で数えて確かめる手順が分かるようにしたい。安全のため、当サイトのCMSの名前や版、ファイルやフォルダの名前、サーバーの場所、設定の中身は書かない。書くのは、日付、数えた件数、考え方、手順の順番までだ。お客さまの案件の話も書かない。
何が見つかったか ── 3行で、そして62日のあいだ直さなかったこと
3行で言うと
- 本番のコードの1か所が、試験環境の設定ファイルを読んでいた。測ったのは9月8日と11月9日の2回だけで、2回とも本番の設定と中身が同じだった。その間の62日は確かめていない。
- 9月8日に見つけて記録したが、「中身が同じで実害なし」という理由で直さなかった。そのまま62日、未完了の一覧の中で、待ち状態の印も付かずに止まっていた。
- 11月9日に、読み先を本番の側の設定へ直した。同じ日に、本番のコードの中で試験環境の名前を含むファイルを数えると、2,615本のうち19本だった。19本の判定は、これからだ。
見つけた9月8日に、記録していたこと
9月8日の記録には、事実が3つ書いてあった。1つ目は、本番のコードの1か所が、試験環境の設定を読んでいること。2つ目は、その設定が本番側の設定と同じ中身（確かめにはハッシュの一致を使った）で、実害は無いこと。3つ目は、危険が2つあることだ。
危険の1つ目は、「試験環境を触った瞬間に、本番が変わる」こと。試験環境は、設定を変えて試すための場所だ。そこを触ると、本番のコードが読んでいる値も変わる。2つ目は、「読めないときは、空の設定に落ちる」こと。試験環境の設定が読めなくなったとき、本番の部品が、止まって知らせるのではなく、空の設定のまま動く作りだった。
危険を2つとも書いていたのに、直す作業には回さなかった。理由はひとつで、「今は中身が同じだから」だった。
62日止まっていた間、分かっていること・分からないこと
止まった理由として、記録から言えるのは1つだけだ。一覧の中で、この項目に「待ちの印」が付いていなかった。何かが起きるのを待っている項目なら、一覧に「何を待っているか」が書いてあって、その事が起きたら動く。この項目には、その印が無かった。なぜ決めなかったのか、決める人や期限があったのかは、記録から分かっていないので、ここには推測を書かない。
別の担当が見直しで挙げたのは、この点だ。止まっていること自体より、「止まっているのに、待ちの印すら付いていない」ことを問題にした。
- 2026年9月8日: 見直しの中で、本番の部品が試験環境の設定を読んでいるのを見つけた。中身が同じなので実害なしと記録して、直さなかった。
- 9月8日から11月8日まで: 変化には気づかなかった。ただし、この間は設定の一致を測っておらず、一覧の中で止まったままだった。
- 2026年11月9日: 未完了の作業の一覧を見直した別の担当が、待ちの印すら付いていない項目として挙げた。同じ日に、中身の一致を測り直して、読み先を本番の側へ直した。そのあと、試験環境の名前を数えた。
見つけた日と直した日の間は、62日ある。測ったのは9月8日と11月9日の2回だけで、その間に試験環境の設定が変わっていたかどうかは、今回は確かめていない。変化に気づかなかったことと、変化が無かったことは別だ。確かめていないので、「たまたま何も起きなかった」と「何も起こりえなかった」の区別も付けられない。
本番が、試験環境の設定を読むとは、どういうことか
中身が同じ間は、何も見えない
本番の部品が読む設定ファイルを、試験環境の側に置いた設定に向けてしまう取り違えは、起こりうる形の一例だ。たとえば、試験環境で作った部品を本番へ運ぶときに、読み先の指定だけが試験環境の側のまま残る、という経路が考えられる。ただし、当サイトの件で、そうなった原因は特定していない。本番と試験で、設定の中身がもともと同じなら、動きも同じなので、気づきにくい。
当サイトで見つかった件も、動いていて、画面も同じで、エラーも出ない状態だった。9月8日の見直しの中で見つけた。なぜその読み先になったのか（いつ、どう書かれたのか）は、調べていない。普段の確かめ（画面を見る、応答のコードを見る）では、見つかりにくい種類の取り違えだと考えている。
試験環境は、壊す前提の場所だ
試験環境は、本番に出す前に試すために使う。うまくいかなければ、戻したり、わざと壊したりもする。当サイトでも、11月7日に、試験用のサイトで全ページがエラーの画面になる約1分間があった（ログインのCookieにSameSiteを書いたのに、応答には付いていなかった ── 設定が2か所にあり、後から読まれる側が置き換えていた。試験用のサイトで1回壊して戻し、書き方を直して本番に出した記録）。試験環境は、そういう使い方をしてよい場所だ。
もし本番のコードが、その壊れた設定と同じ種類の設定を読んでいたら、どうなるか。試験環境を直している最中に、本番にも影響が出る。しかも、影響を受けた本番側から見れば、自分は何も触っていない。原因が試験環境にあると気づくまで、時間がかかる。
もう1つ、考えておきたいのは、読む向きだ。試験環境は、本番を真似て作る。本番の設定をコピーして、試験環境の設定にすることが多い。そのため、中身が同じなのは、自然なことだ。ところが、本番が試験環境を読むと、依存の向きが逆になる。本番を守るために作ったはずの試験環境が、本番の動きを決める側に回ってしまう。向きは、必ず「試験が本番を真似る」の一方向にして、「本番が試験を見る」配線は作らない。
「中身が同じ」を、安心の根拠にしてはいけない
同じなのは、今日までの事実だ
ハッシュが一致していたことは、「今日の時点で、2つのファイルの中身が同じ」という事実を示す。明日も同じとは限らない。試験環境の設定は、試すために変えるものだ。変えた瞬間に、一致は崩れる。この件の記録には、一致が崩れたかを見張る手段は書かれていない。
実害が無いという判断は、測った日の時点では言えた。ただ、その判断は「同じである間は」という条件付きだった。条件付きの判断は、条件を見張る手段とセットで置くべきだった。記録には「直すときは動作確認の手段を先に決める」とあるだけで、見張る手段も、直す期限も書かれていなかったので、条件付きの判断が、そのまま「判断済み」の顔をして残ったと考えられる。
| 9月8日の判断 | 足りなかったもの |
|---|---|
| 中身が同じなので、実害なし | 記録に、「同じ」が崩れたかを見る手段が書かれていなかった |
| 危険を2つ書いた | 記録に、直す日が書かれていなかった |
| 今は直さない | 待ちの印（何を待っているか）が付いていなかった |
この表の3行は、記録の上で「足りなかったもの」として言えることだ。62日止まった本当の理由は、当サイトでは確かめられていない。判断が間違っていたとは限らない。ただ、判断のあとに、見張る手段と見直しの日が記録に無かったことは、事実として言える。
直し方と、前後の確かめ
直したのは、読み先の1行
11月9日、読み先の指定を、試験環境の側から、本番の側の設定へ向けた。1行の変更だ。変更する前に、試験環境の設定と本番側の設定を比べ直し、中身が今も一致していることを確かめた。一致していたので、直しても動作は変わらないはずだった。
この比べ直しは、手順として大事だった。もし一致していなければ、直すことで本番の動きが変わる。その場合は、先に「どちらが正しい中身か」を決める必要がある。一致を確かめてから直すと、直す作業が「動きを変えない直し」だと言える。
前と後で、確かめたこと・確かめていないこと
直したあとに、本番の応答と画面を確かめた。結果は次の表のとおりだ。
| 確かめた項目 | 結果 | 備考 |
|---|---|---|
| 応答のコード | 200 | 前後の比べ |
| 応答の大きさ | 前後で同じ（60,606バイト） | 前後の比べ |
| 3ページの画面の中身（ブラウザ相当で取得） | 壊れた画像0・PHPのエラー表示0・構造化データの壊れ0 | 直したあとだけ取得 |
| 直す前の画面の中身 | 取っていない | 前後の比べは、応答の大きさだけ |
| この部品が実際に動くとき | 試していない | フォームを送ったときに動く部品 |
正直に書くと、確かめは完全ではない。画面の中身は、直す前の分を取っていないので、前と後の比べにはなっていない。「後で壊れていない」ことは言える。「前と同じ」とは言えない。そして、この部品が動くのはフォームを送ったときなので、実際の分析の動作は試していない。応答の大きさが同じで、設定の中身が同じだったことが、動きが変わらない根拠になっている。
これは、本番を触るときの決まりとして、直す前の画面の中身を先に取っておく、という教訓になった。応答のコードが200で、大きさも同じなら、ほとんどの場合は問題ない。ただ、「ほとんど」の外にあるものは、前の姿を取っておかないと、後からは比べられない。
本番のコードの中で、試験環境の名前を数えた
数え方 ── 名前で探し、外したものを書く
1か所の取り違えが見つかったなら、同じ形の取り違えが、ほかにも無いかを確かめたくなる。当サイトでは、本番のコードの中で、試験環境の名前（フォルダの名前とホストの名前）を含むファイルを数えた。
数えた範囲は、テーマ、設定、プラグイン、コントローラ、自作の処理で、合計2,615本だった。名前に控えの印があるファイルと、記事の本文は、数えから外した。控えは、前の版の写しなので、読み込まれていないことが多いと考えた（当サイトの19本では、読み込まれているかを、まだ確かめていない）。記事の本文は、試験環境の名前が、文章の中に出てくるだけのことがある。外した理由を、数える前に決めて、外した事実を、結果と一緒に書く。これを書かないと、「0件」と「見ていない」の区別が付かなくなる。
結果は、2,615本のうち19本だった。比率にすると、約0.7パーセントだ。
19本の内訳 ── 数えただけで、判定はこれから
19本は、名前の周りを見て、次のように分けた。
| 分け方 | 本数 | わかっていること |
|---|---|---|
| 古い分析の出力や、控えのフォルダの中にあるもの | 8本 | 名前から見た分類。中身は開いていない |
| ホストの名前で試験と本番を切り替える所、試験から本番へ公開する仕組み、ログの置き場、点検の道具の設定など | 11本 | 名前の周りを見ただけ。1本ずつの判定はしていない |
| 合計 | 19本 | 「全部が問題」とは言えない |
この19本について、「全部が問題だ」とは言えない。ホストの名前で試験と本番を切り替える所は、本来、試験環境の名前を書くのが正しい場所だ。試験から本番へ公開する仕組みも、試験環境の名前を知っているのが当然だ。問題なのは、「本番として動くコードが、本番の判断に、試験環境の値を使っていること」だ。名前を含むことと、問題があることは、別だ。
逆に、「8本は、中身を開いていないので、問題無し」とも言えない。名前から古い出力や控えのフォルダだと見ただけで、開いていない。開いて、本番のコードから読まれていないかを確かめるまでは、「問題無し」とは書かない。数えた結果は、問題の件数ではなく、これから見るファイルの一覧だ。
名前で数える方法には、限界がある。1つ目は、名前の別の書き方を拾えないことだ。試験環境のフォルダ名を、変数に分けて書いていたり、短い略称で呼んでいたりすると、探した名前では見つからない。2つ目は、コードの外にある設定、たとえばサーバーの設定や定時に動く処理の設定を、数えていないことだ。3つ目は、読み込む先を、実行のときに文字をつなげて作っているコードだ。名前がコードに書いてなくても、実行のときに試験環境を指すことがある。
だから、19本は「見つかった下限」と読む。0本の日が来ても、「無い」と書かず、「この数え方では見つからなかった」と書く。数え方は、月に1回、1つずつ増やして、拾える範囲を広げていくつもりだ。
公式の文書は、環境と設定について何と言っているか
The Twelve-Factor App ── 設定は、デプロイごとに変わるもの
アプリの作り方の指針としてよく引かれるThe Twelve-Factor Appは、設定について、こう書いている。
"An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc)."
（日本語訳: アプリの設定とは、デプロイ（staging・本番・開発者の環境など）ごとに変わりうるもののすべてだ。）
同じ文書は、設定とコードを厳密に分けるよう勧めている。
"strict separation of config from code"
（日本語訳: 設定とコードの、厳密な分離。）
"Config varies substantially across deploys, code does not."
（日本語訳: 設定はデプロイごとに大きく変わるが、コードは変わらない。）
今回の件を、この文書の言葉で言い直すと、こうなる。コードは本番と試験で同じものを使う。変わるのは設定で、どの設定を読むかは、環境が決める。コードの中に「試験環境の設定を読め」と書いてしまうと、コードを本番へ運んだだけで、設定の選び方まで一緒に運んでしまう。
この文書は、設定が正しく分けられているかを確かめる目安も書いている。
"whether the codebase could be made open source at any moment, without compromising any credentials."
（日本語訳: そのコードベースを、いつでも、認証情報を漏らさずに、オープンソースにできるか。）
この目安は、認証情報の話だ。ただ、環境の名前についても、同じ見方ができる。コードの中に、試験環境の名前を書いたまま本番へ運ぶと、環境の分け方が、コードの中に混ざっている。
OWASP ── 環境は同じ形で作り、認証情報は環境ごとに変える
OWASP（Webの安全の啓発団体）のトップ10の2025年版では、「セキュリティの設定ミス」が、2番目に載っている。その対策の中に、環境の分け方についての項目がある。
"Development, QA, and production environments should all be configured identically,"
（日本語訳: 開発・QA・本番の環境は、すべて同じ形で設定するべきだ。）
"with different credentials used in each environment."
（日本語訳: そのうえで、環境ごとに違う認証情報を使う。）
「同じ形で作る」ことと、「環境が互いを読まない」ことは、両立する。環境は同じ形で作って、中の値は、環境ごとに別に持つ。ほかの環境の値を、うっかり読んでしまう配線が無ければ、1つの環境で起きた変更は、その環境の中で止まる。
GitHubの文書 ── 環境ごとに、値と承認を分ける
GitHubの文書（環境の管理）は、環境ごとの値の持ち方を、こう説明している。
"These secrets are only available to workflow jobs that use the environment."
（日本語訳: これらの秘密の値は、その環境を使う作業（ワークフローの処理）にだけ使える。）
環境に値を結びつけておけば、ほかの環境の処理からは、その値が見えない。今回の件は、まさにこの逆だった。本番の部品が、試験環境の側の値を見ていた。環境ごとに値を結びつける仕組みを使っているサイトなら、この取り違えは、仕組みのほうで防げる。使っていないサイトは、数えて確かめるしかない。
3つの文書は、書き方も対象も違う。ただ、共通して言っていることがある。環境ごとに値を分けて持つこと、コードは環境をまたいで同じにすること、そして、ほかの環境の値を、うっかり読めてしまう道を作らないこと。今回の件は、3つ目を、本番の部品が破っていた例だった。
自分のサイトで、明日できる10項目
この記事を読んでいる人が、本番と試験の2つの環境を持っているなら、今回のような取り違えは、起こりうる。持っていなくても、「開発用」「検証用」「古いほうの環境」が残っていれば、同じ形が起こる。サイトの規模にかかわらず、環境が2つ以上あるなら、確かめる価値がある。
次の10項目は、担当サイトで、明日から1つずつ進められる順番に並べた。1〜3は数える作業、4〜6は直す作業、7〜10は再発を防ぐ作業だ。
- 本番のコードのフォルダの中で、試験・開発の環境の名前（フォルダ名・ホスト名・サブドメイン）を含むファイルを数える。数えた範囲と、全部で何本のうちの何本かを、結果と一緒に書く。
- 控えのファイルと、記事の本文など、意味が違うものを外して数え直す。外した理由と、外した本数を書く。
- 残ったファイルを、3つに分ける。(a) 設定やファイルを読み込んでいるもの、(b) 名前が文字として出てくるだけのもの、(c) 環境を切り替える所。
- (a) は、読み先を、本番の側へ向ける。向ける前に、今の読み先と、向け先の設定の中身が同じかを、ハッシュで比べる。
- 中身が違うなら、先に「どちらが正しいか」を決める。決める前に読み先を変えると、本番の動きが変わる。
- 直す前に、応答のコードと大きさ、複数ページの画面の中身を取っておく。直したあとに同じものを取って、比べる。
- 読み先を、コードの中に書かず、環境で決める形にする。環境変数や、環境ごとの設定が使える。
- 設定が読めなかったときに、黙って空の設定で動かず、止まって理由を出す形になっているかを確かめる。
- 試験環境の設定を触る作業の前に、本番が、その設定を読んでいないかを、1と同じ数え方で確かめる。
- 月に1回、同じ数え方で数え直して、本数の推移を残す。直さずに残すものには、「何を待っているか」と見直す日を、必ず書く。
4の「2つの設定の中身が同じかを比べる」作業のうち、設定ファイルそのものの比べは、サーバーの中でハッシュを取って行う。外から見える画面や応答の比べには、🔧 【メンテナンス】WEBサイトの状況チェック・比較ツール★チガウンが使える。試験用に用意したサイトと本番の違いを、ページごとに自動で比べて、結果をExcelとJsonでダウンロードできるツールだ。Basic認証をかけた試験用サイトにも対応している。サインインして使う（会員限定）。
6の「直す前の画面の中身を取っておく」ことは、後から比べられる形で取っておけば足りる。ブラウザで開いて目で比べるやり方でも、画面の中身をファイルに保存して比べるやり方でも、「直す前の姿」が残っていれば、前と後を比べられる。
見つけ方の手順 ── 名前で数える・読み先を環境で決める
名前で数えるときの、3つの注意
名前で数えるときは、注意が3つある。1つ目は、見つからないことを「無い」と読まないことだ。探す名前が足りなければ、取り違えは見つからない。試験環境の名前は、フォルダの名前、ホストの名前、サブドメイン、略称と、複数の形で書かれていることがある。形ごとに数える。
2つ目は、数えた範囲を書くことだ。「19本見つかった」だけでは、その19本が、どの範囲のものかが分からない。「2,615本のうち19本」と書けば、読む人は、数えなかった範囲があるかを、自分で考えられる。
3つ目は、名前を含むことと、問題があることを分けることだ。本来、試験環境の名前を書くべき場所（環境を切り替える所、試験から本番へ公開する所）にも、名前は出てくる。出てきたこと自体は、問題ではない。問題かどうかは、1本ずつ開いて、「本番として動くときに、試験環境の値を使っているか」で決める。
数えたあとの判定は、順番を決めて進める。まず、本番の判断に使う値（設定、切り替えの条件、公開の可否）を読んでいるものから開く（この順番は考え方の提案で、当サイトの19本は、まだこの順で開いていない）。次に、ログや出力の置き場を決めているもの。最後に、点検用の道具の設定のように、止まっても本番の表示に影響しないものだ。影響が大きい順に開くと、時間が足りなくなっても、大きなものから片付く。
1本ずつ開いたときの判定は、3つに絞っておくと迷わない。「意図したもの（直さない・理由を書く）」「取り違え（直す）」「判断できない（持ち主に聞く）」だ。「判断できない」を無理に前の2つへ振り分けると、今回と同じ形の、理由の無い後回しが、また1つ増える。
読み先を、環境で決める形にする
読み先を、コードの中に書かない形にするには、大きく3つのやり方がある。1つ目は、環境変数で、読む設定の場所を渡すやり方だ。コードは「環境変数が指す設定を読む」とだけ書き、本番と試験で、環境変数の値を変える。2つ目は、環境ごとに設定を置く場所を決めておき、コードは、その環境の側にある設定を、決まった相対的な位置から読むやり方だ。3つ目は、起動のときに、環境の名前を1回だけ決めて、それ以外の場所では、環境の名前をコードに書かないやり方だ。
どのやり方でも、守りたいことは同じだ。コードは、本番と試験で同じものを使う。環境が違えば、読む設定が変わる。そして、設定が読めなかったときは、黙って空の設定で動かず、何が読めなかったかを出して止まる。止まるのが重すぎる場所（全ページに出る部品など）では、その部品だけを出さずに、理由をログへ残す形もある。どちらを選ぶかは、サイトごとの判断だが、「黙って動く」という選択だけは、避けたい。
ハッシュの一致は、「いま同じ」までしか言えない
ハッシュが一致しているのを見て、「この取り違えは安全だ」と言いたくなる。ただ、ハッシュが示すのは、確かめた時点で、2つのファイルが同じ中身だということだけだ。確かめた後の変更は、含まれない。
だから、一致を理由に直さないと決めるなら、次の3つを一緒に決める。見張る手段（月に1回、同じハッシュを比べ直す）、見直す日、一致が崩れたときの動き（本番が止まって知らせるのか、黙って動くのか）。この3つが決まっていない「直さない」は、後回しと区別が付かない。
当サイトの現在地 ── 実施したことと、これから
- ✅ 当サイト実施済 本番の部品が試験環境の設定を読んでいたのを、本番の側の設定へ直した（2026年11月9日）。直す前に、2つの設定の中身が一致していることを確かめた。
- ✅ 当サイト実施済 本番のコード2,615本のうち、試験環境の名前を含むファイルを数えた。結果は19本だった。控えと記事の本文は外した。
- ✅ 当サイト実施済 直した後に、3ページの画面の中身（壊れた画像0・PHPのエラー表示0・構造化データの壊れ0）と、応答の大きさ（前後で同じ）を確かめた。
- ✅ 当サイト実施済 19本を1本ずつ開いて、本番として動くときに試験環境の値を使っていないかを判定する。8本は、まず、本番のコードから読まれているかを確かめる。（2026年11月10日 追記: 数える範囲を少し広げて23本を見た。20本は、環境で切り替えている所・説明の文・試験環境でだけ動く処理・使われていない古いものや控えで、本番の動きには関わらなかった。1本は同じ日に直した。本番の処理の途中経過の記録が、試験環境のフォルダに書かれていて、一番古いものは約1年4か月前だった。残りの2本は、サーバーの引っ越しのときに直すと決めて、一覧に載せた。）
- 🔧 当サイトこれから 設定の読み先を、コードの中に書かず、環境から決める形にする。
- 🔧 当サイトこれから 設定が読めなかったときに、黙って空の設定で動かず、止まって理由を出す形になっているかを確かめる。
- 🔧 当サイトこれから 月に1回、同じ数え方で数え直して、本数の推移を記録する。
- 🔧 当サイトこれから 未完了の作業の一覧に、「何を待っているか」と見直す日を書く欄を足す。
まとめ
持ち帰ってほしいことは、5つだ。
- 本番のコードが、試験環境の設定を読んでいても、中身が同じ間は、画面や応答に違いが出にくい。普段の確かめ（画面を見る・応答のコードを見る）では、見つかりにくい。
- 「いま同じ」は、安心の根拠にならない。「同じである間は」という条件付きの判断なので、条件を見張る手段と、見直す日を、一緒に置く。
- 名前で数える。数えた範囲と、全体の本数を書く。名前を含むことは、問題があることとは別なので、1本ずつ判定する。
- 直す前に、前の姿を取っておく。応答のコードと大きさだけでなく、複数ページの画面の中身も、直す前の分が要る。
- 直さないと決めたものには、「何を待っているか」と見直す日を書く。印の無い「止まり」は、後回しと区別が付かない。
確かめていないことも書いておく。1つ目は、19本の1本ずつの判定だ。名前を含む19本のうち、問題があるものが何本かは、これから見る。2つ目は、直した部品が実際に動くときの動作だ。フォームを送ったときに動く部品なので、分析の動作は試していない。3つ目は、直す前の画面の中身だ。取っていないので、前と後の比べは、応答の大きさだけになっている。4つ目は、設定が読めなかったときの動きだ。止まるのか、空の設定で動くのかを、今回は確かめていない。5つ目は、試験環境のほかに、開発用や古い環境の名前が、本番のコードに残っていないかだ。数えたのは、試験環境の名前だけだった。6つ目は、9月8日から11月9日までの間に、試験環境の設定が変わったかどうかだ。測ったのは2回だけで、間は確かめていない。
関連 archives（連載軸として読む）
- ログインのCookieにSameSiteを書いたのに、応答には付いていなかった ── 設定が2か所にあり、後から読まれる側が置き換えていた。試験用のサイトで1回壊して戻し、書き方を直して本番に出した記録 ── 設定が2か所にあり、書いたはずの指定が効いていなかった記録（11月7日）
- 毎朝の解析の処理が、保守の終わった系統の実行環境で動いていた ── 解説記事を書いている途中で見つかり、提供元の修正版へ切り替えて、2回の朝で確かめた記録 ── 定時の処理が使う環境の一覧を、月に1回見直す約束の記事（11月6日）
- Basic認証のパスワードのファイルが、公開の場所の中に9本あった ── 外からは全部403だったが、読めなかったのは1つの決まりのおかげだった。確かめ方と、公開の外へ移した記録 ── 自分のサーバーの中を数えて、その日のうちに直した記録（10月30日）
- PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録 ── 表示ではなく値で確かめるという考え方の記事（10月26日）
- 控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順 ── 本番の場所に残った控えを数えて、外へ移した記録（10月23日）
解説記事では、公開の場所に残った控えファイルは、名前で探して状態コードで確かめ、外へ移す ── 自社と担当サイトの.bak・.old・日付付きの写しを棚卸しする13項目（2026年10月時点）と、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）もあわせて読める。ツールでは、外から見える範囲の点検を、🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルンで始められる（会員登録が必要）。
出典
すべて2026年11月9日に開いた。
