local vs production
手元のコードは本番より古いことがある：眠っていた道具が壊れたまま出た
結論です。リポジトリの中身と、本番で動いているコードは別物です。長く上げていない道具は、壊れたまま眠っていることがあります。久しぶりに上げた瞬間、その壊れが初めて本番に出ます。このページは、2026年9月20日に申込の集計が500エラーになった原因調査、2026年8月に本番を直接編集したら巻き戻しの危険が見つかった件、生成サイトの上げで消えたページが残る件をもとに、「手元が古い」ことを前提にした確かめ方をまとめた記録です。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論：疑う順番
上げた直後に本番が壊れたとき、多くの人は「自分の直しが悪い」と考えます。しかし2026年9月20日の記録では、自分の編集を書き戻しても直りませんでした。原因は、道具のPHPの中にあったSQLの括弧が1つ余分だったことです。その誤りはリポジトリに前からありましたが、一度も上げられていなかったため表に出ていませんでした。本番では、古い（正しい）版が動き続けていたのです。
疑う順番はこうです。(1) 戻しても直らないなら、原因は元から埋まっている。(2) 長く上げていない道具は、壊れている可能性がある。(3) 手元の版と本番の版のどちらが新しいかを、まず確かめる。
確かめる手順：上げる前に5つ
- 本番の現物を取り直し、手元と差分を出す。手元が新しい前提を置かず、「どちらが新しいか」を日付とサイズで見ます。
- 手元で構文を検査する。PHPなら
php -l ファイル名を通します。括弧の収支を行単位で数える道具も併用します。この検査は本番に触れずにできます。 - 別名で上げて試す。キャッシュを疑うときは、別名のファイルで同じ症状が出るかを見ます。別名でも500なら、キャッシュではありません。
- エラー表示を有効にした版を別名で上げる。例外の本文と行番号が出ます。今回は、MySQLが報告した位置と括弧の数え直しの位置が一致しました。
- 検査用に置いたファイルを全部消し、消えたことを404で確認する。置きっぱなしの検査用ファイルは、重複URLとして残ります。
実際に起きた記録1：括弧が1つ多いSQL（2026年9月20日）
| 順番 | やったこと | 分かったこと |
|---|---|---|
| 1 | 自分の編集を書き戻した | 直らない。自分の編集が原因ではなかった |
| 2 | 別名で上げて試した | 別名でも500。キャッシュ（OPcache）ではない |
| 3 | 起動処理とDB接続だけを叩く検査ファイルを置いた | PHPのバージョンもDBも正常 |
| 4 | エラー表示を有効にした版を別名で上げた | 例外の本文と行番号が出た |
| 5 | 括弧の収支を機械で数えた | 27行目で深さ0、28行目で-1。MySQLの報告位置と一致 |
| 6 | 手元で構文を通してから上げ、検査用ファイルを全部消した | 404を確認して終了 |
誤りは、条件式（CASE式）の閉じ括弧が1つ多いという単純なものでした。ほかに、PHPの二重引用符の中では $名前 が変数として展開されるため、SQLのコメントに書いた変数名で未定義の通知が出て、紛らわしい手がかりになりました。これは500の原因ではありませんでした。
実際に起きた記録2：本番を直接編集したら、配信対象と重なっていた（2026年8月15日）
あるサイトで、全290ページに運営者表示を、58ページに広告のスクリプトを、本番へ直接入れました。あとで確認すると、自動配信の設定ファイルが指す70件のうち54件が、今回触ったファイルと重なっていて、リポジトリ側は追加前のままでした。その自動配信が1回でも動いていれば、運営者表示53件と広告スクリプト32件が本番から消えていました。
手順はこうでした。配信対象の一覧と、本番を触ったファイルの集合の積を取る。同期する前に「リポジトリにしか無い成果物」がないか、タグを剥がした表示テキストで比べる。生バイトで比べると空白やタグ位置の違いで54件中53件が差分に見えましたが、表示テキストでは54件すべて一致でした。検算が通ったら、本番から取り直した現行版でリポジトリを上書きします。本番が正だからです。作業ツリーを直しただけでは保護にならず、マージされるまで巻き戻しの危険は残ります。
実際に起きた記録3：写しが3つあった（2026年9月21日）
あるサイトでは、同じサイトの写しが3つありました。「リポジトリと本番」の2者で考えると外します。新しい順が本番、手元のドライブ、リポジトリでした。どの写しが最新かは、日付とサイズを実測しないと決められません。
上げるだけの道具は、消えたページを知らない
生成サイトでは別の古さも出ます。2026年8月27日、採点対象から3店を外したところ、手元の出力からは消えたのに、本番の該当ページは200で生き続けていました。リンクもsitemapにも無く、内容は古い点数のままです。ステータスコードの検査でもリンク切れ検査でも見つかりません。ビルド側の掃除はローカルにしか効かないからです。
対策は、上げる道具に「本番にあって手元に無いディレクトリを消す」段を入れ、消す前に別名で公開領域の外へ退避することです。検算は、本番のディレクトリ数と手元の数で行います。ただし、期日が過ぎた催しや便の面は消さずにアーカイブとして残す、が運営者の決まりなので、消すのは作り間違いと名前を変えた旧ページだけにします。上げの途中でビルドを走らせると、本番が2つのビルドの混ざりになります。2026年9月12日の記録では、上げの途中で作り直すと 2,600/4,907 で止まりました。ロックファイルで防ぎます。
古い道具を動かす前の最小限の儀式
久しぶりに動かす道具には、手元で構文検査を通し、別名のファイルで試し、本番を取り直して差分を見る、という最小限の儀式を決めておくと事故が減ります。道具の最終実行日をREADMEの先頭に書いておくと、「長く上げていない」かどうかがすぐ分かります。眠っている道具ほど、本番に出る瞬間まで誰も壊れに気づけません。
公式の記載で見る：php -l が見る範囲と見ない範囲（2026年11月15日確認）
「手元で構文を検査する」手順に出てくるphp -lは、PHP公式マニュアルのコマンドラインオプションの項に、次のとおり書かれています。
- 実行せずに構文だけを見る：
-l（--syntax-check）は、コードを実行せずに構文の誤りを調べます。 - 結果の出方：問題がなければ「No syntax errors detected in ファイル名」と標準出力に書きます。失敗すれば「Errors parsing ファイル名」と、内部の解析エラーを出します。終了コードは、どれかが失敗すれば-1、それ以外は0です。
- 見ないもの：未定義の関数を呼ぶといった、実行して初めて分かる致命的な誤りは検出しません。
- 複数ファイル：PHP 8.3.0より前は、指定できるファイルは1つだけでした。
9月20日の記録の括弧の誤りは構文の誤りなので、この検査で上げる前に拾えます。一方で、実行して初めて出る誤りは構文検査を通ります。構文検査の合格は「文法として読める」までの確認であり、本番と手元のどちらが新しいかの確認は別の手順で行う、という分け方がこの記載と合います。出典：PHP Manual「Command line usage / Options」（2026年11月15日確認）。
よくある質問
手元が本番より新しいか、どう見分けますか？
本番を取り直し、日付とサイズ、表示テキストの差分で見ます。生バイトの比較は空白の違いで誤解しやすいので、タグを剥がして比べます。
他のセッションが本番を触ったかは分かりますか？
編集の直前と上げの直前に本番を取り直し、土台と完全一致するか照合します。違っていたら上げずに止めます。この照合が実際に3枚を救っています。
上げ方の基本はどこに書いてありますか？
本番へ上げるのは変わったファイルだけと、上げた後に本番を読んで確かめるを見てください。