公開ディレクトリのファイル一覧を眺めながら、見覚えのある作業用ファイルに気づいて手を止めた一人運用の保守担当者
セキュリティ・パッチ約13分

公開ディレクトリの置きっぱなしファイル棚卸し｜外から見えていないか

「調査のために、一時的にphpinfo.phpを置いた」 「リリース前に、念のためconfig.php.bakにコピーを取った」 「移行のとき、旧サイトをoldディレクトリに残しておいた」

——あのとき置いたファイル、あれからどうなったか、思い出せますか。

思い出せなくても、まったく普通のことです。あの日は障害対応に追われていたし、リリースは無事に終わったし、次の依頼がすぐ飛んできた。片づける時間があれば、とっくに片づけていますよね。ファイルを置いた判断は、そのときは正しかったのです。ただ、置いたものは自分から消えてはくれない、というだけの話です。

ここでは、公開ディレクトリに何が置きっぱなしになっているかを洗い出して、外から見えていないかを確かめるところまでを、一緒に順番にやっていきましょう。難しい道具は使いません。今日30分あれば、ひととおり見終わります。

結論：棚卸しの順番はこうです。①公開されている場所（ドキュメントルート）の実体を確かめる → ②置きっぱなしになりやすい4種類を洗い出す → ③気になったものだけ、外から実際に見えるか確かめる → ④消す前に、公開ディレクトリの外へ退避する → ⑤リリース手順に「作業ファイルの撤去」を1行足す。ポイントは、いきなり消さないこと。まだ業務で使っているファイルかもしれません。「見つける」と「消す」は別の日にやって大丈夫です。

なお、公開ディレクトリの場所も、設定の変え方も、環境（自社サーバー・レンタルサーバー・クラウド・保守委託の範囲）でかなり変わります。本文は一般的な進め方の一例です。コマンドや設定は本番で実行する前に、検証環境と公式ドキュメントで挙動を確認してください。共用のレンタルサーバーなどで裁量が限られる場合は、契約先の窓口に相談しながら進めるのが安全です。

何が起きているか：公開ディレクトリは「置いた瞬間に外から届く場所」

サーバーの中で作業していると、どのディレクトリも同じ「フォルダ」に見えます。でも公開ディレクトリ（ドキュメントルート）の中だけは、少し性質が違います。そこにファイルを置いた瞬間から、URLさえ分かれば外から取りに行ける状態になります。ログインも社内ネットワークも関係ありません。

そして、置きっぱなしになりやすいファイルには、共通した困りごとがあります。

たとえば config.php を config.php.bak にコピーした場合。元の config.php はPHPとして実行されるので、ブラウザで開いても中身は表示されません。ところが .bak はPHPとして扱われないため、プログラムのソースがそのまま文字として表示されてしまうことがあります。中にデータベースの接続情報が書かれていれば、それも一緒に見えます。同じことが .old、.txt、config.php.20260401 のような日付つきの退避ファイルでも起こります。

これは「バックアップを取ったのが間違い」という話ではまったくありません。バックアップを取る判断は正しいのです。置き場所だけが、たまたま外から届く場所だったというだけです。

この違いは、知識や意識の差ではなく、単に一度も棚卸ししたことがないかどうかの差です。多くの現場では、公開ディレクトリを一覧で眺める機会そのものが、そもそもありません。

具体例：置きっぱなしになりやすい4種類

公開ディレクトリに置きっぱなしになりやすい4種類「バックアップ」「開発の跡」「調査用」「古い複製」を並べた図
この4つの引き出しを順に開けていけば、だいたい見つかります

引き出しを順に開けるつもりで、4種類に分けて探すと見落としが減ります。

① バックアップ .bak / .old / .orig / .zip / .tar.gz / .sql / *.dump / config.php.20260401 のような日付つきファイル。「戻せるようにしてから触る」という良い習慣の副産物なので、いちばんよく残っています。データベースのダンプが公開ディレクトリに残っているケースもあります。

② 開発の跡 .git / .svn ディレクトリ、.env、composer.json、package.json、.htaccess.bak、エディタが自動で作る index.php~ や .index.php.swp。特に .git が公開ディレクトリの直下に置かれていると、履歴からソース一式を復元できてしまう場合があります。.env に認証情報を書く構成のフレームワークでは、公開範囲の設計が重要になります。

③ 調査用 phpinfo.php / info.php / test.php / debug.php / check.php。障害調査のときに置いて、直った安心感でそのまま、というパターンです。phpinfo() はサーバーの構成情報がかなり細かく出るので、調査には便利な一方、置きっぱなしには向きません。

④ 古い複製 old/ bak/ tmp/ test/ new/ _20260401/ のようなディレクトリごとの退避、旧サイトの残骸、使わなくなった管理画面。中に入っているのは当時のソースなので、古いバージョンのまま更新が止まっています。

加えて、もうひとつだけ見ておきたいのがディレクトリ一覧が見えてしまう状態です。index.html や index.php の無いディレクトリにアクセスしたとき、中のファイル名がずらっと表示される設定になっていると、上の①〜④を探す手間そのものを外から肩代わりできてしまいます。Apacheなら Options -Indexes、nginxなら autoindex off;（nginxは既定でオフ）で止められます。

棚卸しの手順（30分・消さずに見るだけ）

① 公開されている場所の実体を確かめる

意外とここが曖昧なまま運用されていることがあります。まず、どのディレクトリが公開されているのかを一つに確定させます。

このとき一緒に見ておきたいのが、アプリ全体が公開されている構成か、public/ の中だけが公開されている構成かです。後者（ドキュメントルートが public/ を指す）なら、public/ の外に置いたファイルは元々外から届きません。棚卸しの範囲がぐっと狭くなります。

シンボリックリンクで公開ディレクトリの外を参照している場合は、そのリンク先も対象に入れておきます。

② 4種類を洗い出す（結果を眺めるだけ）

公開ディレクトリのパスが分かったら、名前で当たりをつけます。以下は「探すだけ」のコマンドです。何も変更しません。

# 公開ディレクトリのパスは自分の環境に置き換える
DOCROOT=/var/www/html

# ① バックアップ・④古い複製になりやすいもの
find "$DOCROOT" -maxdepth 3 \
  \( -name '*.bak' -o -name '*.old' -o -name '*.orig' -o -name '*~' \
     -o -name '*.zip' -o -name '*.tar.gz' -o -name '*.sql' -o -name '*.dump' \) \
  -printf '%TY-%Tm-%Td  %10s  %p\n' | sort

# ② 開発の跡
find "$DOCROOT" -maxdepth 3 \
  \( -name '.git' -o -name '.svn' -o -name '.env' -o -name '*.swp' -o -name '.DS_Store' \) \
  -printf '%TY-%Tm-%Td  %p\n' | sort

# ③ 調査用に置かれがちな名前
find "$DOCROOT" -maxdepth 3 \
  \( -name 'phpinfo.php' -o -name 'info.php' -o -name 'test*.php' -o -name 'debug*.php' \) \
  -printf '%TY-%Tm-%Td  %p\n' | sort

-printf は環境によって使えないことがあります（BSD系の find など）。その場合は末尾を -ls に置き換えれば、日付とサイズが一緒に出ます。-maxdepth 3 は深追いしすぎないための保険なので、浅い階層から見て足りなければ数字を増やしてください。

出てきた一覧を眺めるとき、更新日時が手がかりになります。数年前の日付で止まっているものは、今は使われていない可能性が高い。逆に最近の日付なら、まだ何かの処理が触っているかもしれないので、消す判断は保留にします。

ここまでで「見つける」は終わりです。まだ何も消していません。それで大丈夫です。

③ 気になったものだけ、外から確かめる

サーバーの中に存在することと、外から見えることは別です。設定で拒否されていれば届きません。気になったものだけ、実際にブラウザやコマンドで確かめます。

# 自社で管理しているサイトに対してのみ実行する
curl -I https://example.com/config.php.bak
curl -I https://example.com/.git/HEAD
curl -I https://example.com/phpinfo.php

403 や 404 が返ってくれば、外からは届いていません。200 が返ってきたものが、今日の棚卸しで拾いたい相手です。

ひとつだけ注意点があります。この確認は、自分が管理を任されているサイトに対してだけ行ってください。 他社や取引先のサイトに向けて同じことをするのは、たとえ善意でも避けます。気づいた場合は、相手先の窓口に連絡するのが筋です。

④ 消す前に、公開ディレクトリの外へ退避する

200 が返ってきたものが見つかっても、いきなり rm はしません。名前は作業用に見えても、実はバッチが参照していた、ということが本当にあります。

まず、公開ディレクトリの外に移すだけにします。

# 退避先を公開ディレクトリの外に用意する
sudo mkdir -p /var/backups/docroot-taihi/2026-08-18
sudo mv /var/www/html/config.php.bak /var/backups/docroot-taihi/2026-08-18/

移動した時点で、外からは届かなくなります。そのうえで、

という順番にすると、後戻りできます。移動と削除を同じ日にやらない、これだけで棚卸しはぐっと安全になります。

もし「業務で必要だが公開ディレクトリに置くしかない」ものがあれば、ファイルを消す代わりにサーバー設定でアクセスを拒否する方法もあります。設定の書き方は環境ごとに異なるので、公式ドキュメントを確認してから本番へ入れてください。

⑤ また増えないように、手順に1行足す

棚卸しがつらいのは、放っておくとまた同じだけ溜まるからです。溜まる速度を落とすほうが、たぶん本命です。おすすめは、大がかりな仕組みではなく、すでにある手順書に1行足すやり方です。

全部いっぺんにやらなくて大丈夫です。ひとつ目の「リリース手順書に1行」だけでも、来年の自分はだいぶ助かります。

明日やること

明日、30分だけ取れそうなら、この4つでちょうど収まります。

見つかったものが多くても、落ち込まなくて大丈夫です。長く動いているシステムほど溜まるのが普通で、それは動かし続けてきた証拠でもあります。

今日のチェックリスト

棚卸しを終えて整理されたファイル一覧を眺め、肩の力を抜いて穏やかな表情を見せる一人運用の保守担当者

置きっぱなしのファイルは、サボった証拠ではありません。むしろ、あの日きちんとバックアップを取り、原因を調べ、動くところまで持っていった手の跡です。その跡を、今日ひとつ拾って公開ディレクトリの外へ移せたなら、それだけで十分な仕事をしています。全部を今日きれいにしなくて大丈夫。次にリリースするとき、最後に一度だけ「何か置いたままにしていないかな」と思い出せる自分になっていれば、それでこの棚卸しは成功です。

よければ、こちらも

保守運用の実務ヒントを、メールでお届けしています。よかったら受け取ってください。