verify / production
上げた後は、本番を読んで確かめる：照合が通っても本番は変わっていなかった
結論です。上げた場所を読み返す照合は、自分の書き込みを読んでいるだけで、本番の証明になりません。確かめるのは、利用者が見る本番のURLを取り直し、バイト数を手元と突き合わせることです。2026年9月4日、14ファイルを上げて「上げ14・照合できず0」と出たのに、本番は1バイトも変わっていませんでした。このページは、その原因と、再発を防ぐ確かめ方、相対パスで古い版を上げた事故、検査スクリプトが設定値を表示して誤診した記録をまとめたものです。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論：確かめる対象を取り違えない
| 確かめ方 | 何を見ているか | 本番の証明になるか |
|---|---|---|
| FTPで上げた場所を再ダウンロードして比べる | 自分が書いたファイル | ならない（書いた場所が違っても必ず通る） |
| ディレクトリの一覧に新しい日付が出る | その場所のファイルの存在 | ならない |
| ステータスコード200を確認する | 何かが返ること | ならない（古い版でも200） |
| 本番のファイルのURLをHTTPで取り直し、バイト数と中身の目印を手元と突き合わせる | 利用者に配信されている実物 | なる |
URLは、ディレクトリのURLでなく、ファイルのURL（またはその面のURL）で確かめます。ディレクトリのURLは別のファイル（既定ページ）を返しているだけのことがあります。
確かめる手順：上げたら必ずやる4つ
- 手元のファイルのバイト数を控える。上げる前に、対象ごとにバイト数を出しておきます。
- 本番のURLをHTTPで取る。キャッシュに惑わされないよう、検査用のクエリを付けて1本だけ取ります。バイト数が手元と同じか見ます。
- 変えたはずの箇所の目印を、本番の応答から探す。設定ファイルやテンプレートの値を表示に混ぜず、本番のレスポンスから抜いた値だけを表示します。
- 見つからないなら、書き込み先の記録を疑う。サイトとFTPアカウントの対応表が古いと、道具は静かに別の場所へ書きます。両方のアカウントで同名のディレクトリが実在しないかを実測します。
本番を何本も叩くと遮断の原因になるので、確かめは1サイト1本までにしています。それ以上は、読むだけのFTP操作で補います。
実際に起きた記録1：14ファイルが残骸に書かれた（2026年9月4日）
解析タグの一括設置で、あるサイトに14ファイルを上げました。道具の報告は「上げ14・照合できず0」。しかし本番は1バイトも変わっていませんでした。
| 場所 | サイズ | 更新日 | 内容 |
|---|---|---|---|
| 別アカウント側の公開フォルダ（記録上の書き込み先） | 405バイト | 2020年2月6日 | 古い残骸 |
| 実際に本番を配信しているアカウント側 | 36,820バイト | 2026年8月22日 | 本番と一致 |
| 本番（HTTPで取得） | 36,820バイト | - | - |
原因は、対応表が2026年8月20日時点の記録のままで、書き込み先を誤っていたことです。道具は残骸ディレクトリへ書き、そこから取り直して照合し、当然一致しました。書き込みと読み返しが同じ場所なら、検査は必ず通ります。以後、「上げた」と書く前に本番をHTTPで取り直してバイト数を突き合わせる、が必須になりました。両アカウントに同名があるサイトは、実測で5件ありました。
さらに、HTTPで本番を確認できないサイト（サーバー側が自分のIPを弾く）では、この確認ができません。その場合は盲目で上げないことにして、確認できる担当へ渡します。
実際に起きた記録2：相対パスで古いリポジトリの版が出た（2026年11月6日）
ある面を上げるとき、作業フォルダに入ってから「上げる道具 サイト名 面のパス=面のパス」と打ちました。すると、作業フォルダの版（136,925バイト）ではなく、道具が既定で見ている別フォルダの古い版（2026年8月31日のまま、33,251バイト）が本番に出ました。
道具の実装は、左側の指定が絶対パスでなく、かつ既定のフォルダが設定されていれば、今いるフォルダではなく既定のフォルダを基準にパスをつなぐ作りでした。気づけたのは、表示された「OK … (N バイト)」の数字が手元より小さかったからです。約30秒後に、絶対パスで上げ直して戻しました。
対策は2つです。左側は必ず絶対パスで書くこと。そして上げた後の「OK (N バイト)」を手元のサイズと見比べ、違えば別のファイルが上がっていると疑うことです。
FTPの補助ツールにも、似た罠がありました。Git Bash から /domains/... で始まる遠隔パスを渡すと、シェルがそれをローカルのパスに書き換え、エラー文はパスと無関係な「undefined の replace」になります。遠隔の絶対パスは PowerShell から渡す、と決めました。
実際に起きた記録3：検査が「設定値」を表示していた（2026年8月18日）
被リンクの検査スクリプトが「10サイトすべてが旧ドメインを指している」と出しました。実際は前日に張り替え済みで、古かったのは表示文字だけでした。スクリプトは、リンクの有無は本番から取り、リンク先のURLは手元に書いた生成時のHTMLから取っていたのです。本番がどう変わっても、永遠に生成時のURLを表示します。
対策は、検査が表示する値を必ず本番の応答から抜くこと、報告の前にHTMLを1本だけ目で見ることです。スクリプトの出力と生のHTMLが食い違ったら、スクリプトを疑います。
確かめを省略しない理由
「道具がOKと出したから」は理由になりません。このページの3つの記録は、どれも道具がOKと出していました。照合が通ること、数字が出ること、色が緑になることは、確かめた中身が正しいことを意味しません。確かめた中身が本番の実物かどうか、つまり何を読んで「OK」と判断したのかを毎回言葉にしてから、「上げた」と報告します。読んだのが自分の書き込みや設定値なら、まだ確かめていません。
書き込み先が分からないサイトは、盲目で上げません。確かめる手段が無いなら、確かめられる担当へ渡すのが、この運用での決まりです。
よくある質問
本番をHTTPで取るのは何本までにしていますか？
1サイト1本までです。自分の検査が多すぎると接続元ごと遮断される事故があったためです。それ以上は読むだけのFTP操作に任せます。遮断の話は自分の検査で接続元が止まった記録に書きます。
ステータスコード200だけでは足りないのはなぜですか？
古い版も200で返るためです。バイト数と、直したはずの箇所の目印で確かめます。
手元の版が古いときの確かめ方はありますか？
本番を取り直して手元と差分を出す手順があります。詳しくは手元のコードは本番より古いことがあるを見てください。