ftp helper traps
FTP取得・アップ用の小さな道具で踏んだ3つの罠と、直した手順
数十のサイトを運用していると、FTPで取る、置く、名前を変える、消すための小さな道具を自作することになります。便利な反面、道具のほうに欠陥があると、エラーが出ないまま誤った場所に書き込みます。この面は、実際に踏んだ3つの罠を、読者が自分の道具で確かめられる形に直した記録です。上げた後に本番を読み直す一般論は別の面にあり、ここは道具そのものの欠陥に絞ります。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論：3つの罠と、見つける最短の確かめ
| 罠 | 症状 | 最短の確かめ |
|---|---|---|
| リモートの絶対パスが、シェアの変換で別の文字列になる | 原因と無関係なエラー文で落ちる | 落ちた時の引数をそのまま出力して先頭を見る |
| 同名の置き場が2つの口座にあり、先に見つけたほうを採用してしまう | 成功と表示され、本番が変わらない | 本番のバイト数と、各候補の置き場のバイト数を突き合わせる |
| 自分の書き込みを読み返して照合する | 誤った場所に書いても必ず照合が通る | HTTPで本番を取り直して比べる |
3つに共通するのは、道具が「成功」と言っても、本番が変わったことの証明にはならない点です。
罠1：絶対パスが書き換わる
WindowsのGit Bashから、リモートの絶対パス（スラッシュで始まるもの）をそのまま引数に渡すと、シェアがそれをローカルの絶対パスに変換してしまいます。道具の中では「スラッシュで始まるか」で絶対か相対かを判定していたため、変換後の文字列は相対パス扱いになり、サイトごとの既定の置き場を引こうとして、定義の無い項目を参照しました。出たのは、パスと無関係に見える「未定義の値のプロパティを読めない」という種類のエラーです。
もう1つ重なっていたのが、設定ファイルの形の不揃いです。一方の口座ではサイトごとの値が文字列、もう一方ではオブジェクトの形で、文字列の側は相対パスが一切使えません。2026年8月13日に、1つのページを置くだけの作業で、この2つが重なって原因不明の失敗を繰り返しました。
直し方は2つです。PowerShellから実行する。もう1つは、リモートのパスを常に /domains/ドメイン名/public_html/... のような絶対形で書く。エラー文がパスと無関係なときは、まず引数が実際にどう渡ったかを出力して見ます。
罠2：同名の置き場が2つの口座にある
道具が持つ対応表（どのサイトがどの口座のどこにあるか）の作成処理は、2つの口座を順に一覧し、先に見つけたほうを採用していました。ところが、両方の口座に同名のディレクトリを持つサイトが5件あり、うち3件は先に見つかるほうが残骸で、実際に配信されているのは後ろの口座でした。残骸には、2026年5月26日付けの1枚のHTMLだけが入っているものもありました。
書き込み系の道具は、宛先のディレクトリがあれば成功します。存在しない場所への書き込みも成功と表示されます。ある日のサイトマップの日付を直す作業の対象9件の中にも、この取り違えのあるサイトが含まれていて、気づかずに流していたら「直した」と報告しながら本番は変わらなかったところでした。最初は「配信の場所にサイトマップの実体が無い」と見えて、サイト側の欠陥と誤診しかけました。
判定の手順は推測せず、本番とバイト数を突き合わせます。
- 本番のサイトマップのサイズを取る：
curl -s -o /dev/null -w "%{size_download}" https://サイト/sitemap.xml - 各候補の置き場にある同じファイルのサイズを取る。
- 一致したほうが配信元。サイトマップが無ければ、トップのHTMLで同じことをする。
圧縮されたサイズが返ると一致しないので、Accept-Encoding: identity を付けます。修正した対応表の作成処理は、重複したサイトを黙って選ばず、一覧にして警告を出すようにしました。
同じ形は手元にも起きます。ある1つの本番に対し、手元の作業コピーが2つあり、どちらも同じ本番を指していました。名前では選べないので、ファイルのハッシュ照合で決めました。片方は手元19本のうち一致15本、中身が違うものが4本で、古い複製と分かりました。送っていたら4本が古い中身に戻るところでした。
罠3：自分の書き込みを読み返しても照合にならない
2026年9月4日、計測タグの一括設置で14ファイルを上げ、道具は「上げた14、照合できず0」と報告しました。本番は1バイトも変わっていませんでした。道具の照合が、上げた場所からダウンロードし直して中身を見る方式だったため、残骸のディレクトリへ書いても照合は必ず通りました。
| 場所 | サイズ | 更新日 |
|---|---|---|
| 残骸の置き場（記録上の宛先） | 405バイト | 2020年2月6日 |
| 実際の配信元 | 36,820バイト | 2026年8月22日 |
| 本番をHTTPで取った値 | 36,820バイト | 配信元と一致 |
対応表の記録が2026年8月20日時点のもので、記録が古いと道具は静かに外します。直し方は、「上げた」と言う前に本番をHTTPで取り直し、バイト数を突き合わせること。FTPの再ダウンロードは照合になりません。また、このマシンからHTTPで見えないサイトは、この方法で確認できないため、盲目のFTPアップをせず、担当に渡します。
ついでに、検証用に本番へ置いた一時ファイルを消す手段が無く、重複URLとして残りかけたことがあり（2026年9月2日）、削除用の道具を足しました。消す前に一覧し、消した後に再確認して「消えたこと」を出す作りです。変更したファイルだけを上げる運用は変わったファイルだけ上げる記録にまとめています。
よくある質問
FTPの道具は自作せず、既製品を使えばこの問題は起きませんか。
既製品でも、宛先を取り違えれば同じ「成功したのに変わらない」は起きます。違いは、道具の内部ではなく、本番をHTTPで取り直して比べる確認を自分の手順に入れているかどうかです。
対応表の記録は、どのくらいの頻度で見直すべきですか。
日付が古い記録は疑う、が基準です。両方の口座に同名がある場合は、一覧表示で重複を実測する処理を定期的に回し、ずれていたら直します。
本番がHTTPで見えない環境では、どう確かめますか。
確かめる手段が無い宛先に、盲目で書き込まないのが原則です。そのサイトは、確認できる環境を持つ担当に渡します。