使われていない機能を安全に止める｜廃止していい画面の見極め方
「この帳票出力の画面、去年から誰も触ってない気がする」 「メニューに残ってるけど、これって何のための機能でしたっけ」 「消したいのは山々だけど、万が一使ってる人がいたら怖い」
——こういう機能、どのシステムにも必ず残っていますよね。動いてはいる。誰も文句は言わない。でも、改修のたびに影響範囲を確かめる手間がかかり、バージョンアップのたびに動作確認の対象になり、脆弱性が見つかれば対応対象に入ってくる。使われていないのに、コストだけは払い続けている状態です。
そして消せない理由は、たいてい「たぶん使われていない」という推測に自信が持てないからです。もし誰かの月次業務がそこで止まったら、と考えると手が止まる。その気持ちは正しい慎重さだと思います。
この記事では、勘ではなく記録で使用実態を確かめて、いきなり消さずに段階を踏んで止めるやり方を一緒に整理します。環境や構成で細部は変わりますが、順番はそのまま使えます。
結論：使われていない機能は、「消す」の前に「調べる・隠す・止める」の3段を挟むと安全に減らせます。手順は、①候補を洗い出す → ②アクセスログや実行記録で使用実態を確かめる → ③止めたときに困る人と、裏でつながっている処理を洗う → ④告知したうえで、隠す（導線を消す）→止める（動かなくする）→消す（削除する）と段階を踏む → ⑤各段でしばらく様子を見て、戻せる形と記録を残す。いきなり削除しないこと、そして各段のあいだに待つ期間を置くことが、いちばんの安全装置になります。
なお、機能を減らすこと自体が目的ではありません。残すと決めるのも立派な結論です。「調べたうえで残す」と分かっていれば、次に迷ったときの時間はゼロで済みます。
何が起きているか：「たぶん未使用」が消せないまま溜まる
使われていない機能が残り続けるのは、担当者の判断が甘いからではありません。消す判断に必要な材料が、システム側から出てこないからです。
- 使用実態を測る仕組みがない：アクセスログは残っていても「どの画面が月に何回使われたか」の形では見えていないことが多いです。
- 依頼した人がもういない：作った経緯を知る人が退職・異動していて、必要かどうかを聞ける相手がいない。
- 年に1回だけ使う機能が混ざっている：直近3か月のログだけ見ると「未使用」に見えるのに、決算期や年度末にだけ動くものがあります。ここがいちばん怖いところです。
- 裏でつながっている：画面としては使われていなくても、そこから呼ばれる処理を別のバッチが共有していることがあります。
- 消して困っても、誰も褒めてくれない：うまく消せても評価されにくく、失敗したときだけ責任が来る。心理的に「触らない」が合理的になってしまいます。
つまりこれは、意志の問題ではなく情報と手順の問題です。使用実態を測る手段と、失敗しても戻せる段取りがあれば、判断はぐっと軽くなります。まずは、どこから手を付けるかを決めるところからです。
見極めの順番：調べる → 隠す → 止める → 消す
急がなくて大丈夫です。この4段を、それぞれのあいだに待つ期間を置いて進めます。
① 候補を洗い出す
まず、疑わしいものを一覧にします。全部を一度に扱わず、1つずつで構いません。候補になりやすいのはこのあたりです。
- 管理画面のメニューにあるが、説明を求められても答えられない画面
- 「暫定」「旧」「old」「bak」「test」といった名前が付いたページ・ファイル
- 一度きりのキャンペーンや、終了した施策のために作られた機能
- 外部システムとの連携で、相手側がもう存在しないもの
- 定期実行されているが、出力先を誰も見ていないバッチ
紙でもスプレッドシートでも構いません。「機能名／どこにあるか／作られた時期（分かれば）／疑う理由」の4列だけ書いておきます。
② 使用実態を記録で確かめる
ここが要です。印象ではなく、残っている記録で見ます。
Webの画面なら、アクセスログにURLごとの回数が残っています。
# 直近のアクセスログから、特定のURLが何回叩かれたか数える（nginx / Apache の既定形式の例）
grep "/admin/report_old" /var/log/nginx/access.log | wc -l
# アクセスの多い順にURLを並べて、逆に「出てこないURL」を見つける
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -50ファイルとして置かれているものなら、最終更新日や最終アクセス日も手がかりになります。
# 1年以上更新されていないファイルを探す
find /var/www/html -type f -mtime +365 -lsDBに紐づく機能なら、そのテーブルに最後にデータが入った日を見ます。
-- 例：直近のレコード作成日を確かめる（列名は環境に合わせて読み替え）
SELECT MAX(created_at) FROM report_requests;確かめるときの注意が3つあります。
- 見る期間は最低でも13か月。年に1回の業務（決算、年度切替、年次報告）を取りこぼさないためです。ログの保存期間が足りないなら、まず保存期間を延ばして待つのも正しい選択です。
- ログのローテーション後のファイルも含める。
access.logだけでなくaccess.log.1や圧縮された.gzも対象に入れます（zgrepが使えます）。 - 監視やクローラーのアクセスを除く。死活監視が定期的に叩いているだけで「使われている」と見えることがあります。ユーザーエージェントやアクセス元IPで区別します。
記録が足りなくて判断できないときは、先に計測を仕込むという手があります。該当の機能が呼ばれたときにログを1行出すようにして、数か月置いてから見る。遠回りに見えますが、いちばん確実です。
③ 止めたときに困る人と、裏のつながりを洗う
数字で「ほぼ使われていない」と出ても、そこで即決はしません。人と処理のつながりを確認します。
人の側は、これだけ聞けば十分です。
- 「◯◯の画面、いま使われている方はいらっしゃいますか」
- 「使っている場合、どのタイミングで（月次・年次・依頼が来たときなど）お使いですか」
聞く相手は、業務の担当部署と、その機能を最初に依頼した部署です。返事がないことを「使っていない」と読み替えないのがコツで、返事がなければもう一度、期限を添えて聞きます。
処理のつながりの側は、コードと設定を横断で探します。
# 機能名・URL・関数名で、呼び出し元がないか横断検索する
grep -rn "report_old" /var/www/html --include="*.php" --include="*.js"
# 定時実行から呼ばれていないか
crontab -l ; ls -l /etc/cron.d/見落としやすいのは、画面としては使われていないが、同じ処理をバッチや外部連携が呼んでいる型です。画面だけ消すつもりが、共通の関数まで消してしまうと別の場所が壊れます。影響範囲の追い方は、改修の影響範囲を見落とさない調査の順番にまとめています。
④ 段階を踏んで止める
ここからが実作業です。一段ずつ、間を空けて進めます。
- 告知する：「◯月◯日から、この機能を停止します。お使いの方はご連絡ください」と関係者に伝え、画面上にも案内を出します。ここで反応が出れば、それが最良の情報です。
- 隠す：メニューやリンクから導線を外します。機能自体はURLを直接叩けば動く状態のままにしておく。戻すのがいちばん簡単な段階です。
- 止める：機能が動かないようにします。アクセス制限をかける、設定フラグでオフにする、「この機能は停止しました」の案内画面に差し替える。コードやデータはまだ残っています。
- 消す：ここまでで問題が出なければ、コードとファイルを削除します。データ（DBのテーブルや保存ファイル）は最後にし、消す前に必ず退避を取ります。
各段の間隔は、業務の周期に合わせます。月次業務が絡むなら最低1か月、年次業務の可能性が残るなら1年は置く判断もあります。焦って詰めても得はありません。
なお「止める」で使うアクセス制限は、内側からも外側からも本当に届かないかを必ず自分で確かめます。設定したつもりで通ってしまう例は少なくないので、実際にアクセスして確認するところまでを1セットにします。
⑤ 戻せる形と、記録を残す
最後に、未来の自分のための保険をかけます。
- 削除前にバックアップを取る：ファイルはアーカイブして退避、DBは対象テーブルをダンプ。「消す前の状態に戻せる」という事実が、判断のこわさを大きく下げてくれます。
- 1コミット1機能で消す：まとめて消すと、戻すときに戻したくない分まで戻ることになります。戻す手順はロールバック手順の作り方と同じ考え方です。
- 「なぜ消したか」を残す：変更管理の台帳に、機能名・調べた結果・告知した日・段階ごとの実施日・戻し方を1行ずつ。数年後に「あの画面どこ行った？」と聞かれたときの答えになります。書き方は変更管理台帳の付け方が使えます。
具体例：「もう誰も使っていないはず」の帳票出力画面
よくある形を、順番にたどってみます。
- ①候補：管理画面に「帳票出力（旧）」というメニューがある。新しい帳票画面が3年前にできていて、こちらは残されたまま。
- ②実態を確かめる：アクセスログを13か月分（
.gz含む）調べると、該当URLへのアクセスは年2回だけ。時期は3月末と9月末。単なる未使用ではなく、半期の締めで使われていると分かった。 - ③人と裏を洗う：経理部門に確認したところ「新しい画面だと出せない集計項目があるので、半期だけこちらを使っている」との回答。さらに
grepで調べると、この出力処理は月次バッチからも呼ばれていた。 - 判断：消さない。代わりに、新しい画面に不足していた集計項目を足す改修を計画し、それが済んでから改めて廃止を検討することにした。メニュー名を「帳票出力（旧・半期用）」に変えて、用途を明示。
- 記録：変更管理台帳に「調査日／年2回使用中／経理部門で継続利用／新画面への項目追加後に再検討」と1行残した。
消せませんでしたが、これは失敗ではありません。「よく分からないから触れないもの」が「用途が分かっていて、廃止条件も決まっているもの」に変わりました。次に誰かが見たとき、調べ直す時間はもう要りません。
影響：見極めの順番を持つと、何が変わるか
未使用機能に手順を1つ持っておくと、システムが軽くなる以上に、判断が軽くなります。
- 「消していいか分からない」で止まらなくなる。調べる手順が決まっていれば、迷う時間が作業時間に変わります。
- 改修時の確認範囲が減る。使わない画面の動作確認に時間を取られなくなります。
- 脆弱性対応の対象が減る。使っていない機能でも、公開されていれば対応は必要です。止めておけば、その分の負担が消えます。
- 「調べて残した」も成果として残る。判断の履歴が積み上がり、同じ検討を繰り返さずに済みます。
- 引き継ぎのときに説明できるものが増える。「これは何ですか」に答えられる機能の割合が上がっていきます。
逆に、判断を先送りし続けると、分からないものが分からないまま次の担当者へ渡ります。棚卸しは、いまの自分のためだけの作業ではありません。
明日やること：疑わしい1つを、調べるところまで
全部の棚卸しは大仕事です。明日できる、いちばん小さな一歩はこれです。
- 疑わしい機能を1つだけ選ぶ。いちばん気になっているものでかまいません。
- アクセスログでその画面のURLを数える。まずは手元にある期間で。
grep "対象のURL" access.log | wc -lの1行から始めます。 - ログの保存期間を確認する。13か月遡れないなら、判断は保留にして、保存期間を延ばす設定だけ先に入れます。それが明日の成果で十分です。
grep -rnでコード内の呼び出し元を1回探す。裏でつながっていないかの当たりを付けます。- 調べた結果を1行メモに残す。「◯月◯日調査／直近◯か月でアクセス◯件／呼び出し元は◯◯」。結論が出ていなくても、この1行が次回の出発点になります。
消すところまで行かなくて大丈夫です。「調べた」という記録が残った時点で、その機能はもう正体不明のものではなくなっています。
未使用機能を止めるときのチェックリスト
判断の前に、これだけ確認できているかを見る項目です。全部を毎回そろえる必要はありません。
まず外せない最低ラインはこの3つです。急いでいても、ここだけは押さえます。
- 【最低ライン】使用実態を、印象ではなく記録（アクセスログ・実行記録・データの最終更新日）で確かめたか
- 【最低ライン】確かめた期間は13か月以上あるか（年に1回だけの業務を取りこぼしていないか）
- 【最低ライン】いきなり削除せず、隠す→止める→消す、の段階を踏む計画になっているか
次の項目は、実際に止めるときに追加で確認します。当てはまらなければ飛ばして大丈夫です。
- 関係部署へ告知し、返事がない場合は期限を添えてもう一度聞いたか
- コード全体を横断検索して、画面以外（バッチ・外部連携・共通処理）からの呼び出しがないか確認したか
- 監視やクローラーのアクセスを、利用実績から除いて数えたか
- ローテーション後・圧縮済みのログも調査対象に含めたか
- 各段階のあいだに、業務の周期（月次・年次）に見合う様子見の期間を置いたか
- アクセス制限をかけた後、実際にアクセスして本当に届かないことを確かめたか
- 削除の前に、ファイルとデータの退避（バックアップ）を取ったか
- 削除は機能ごとに分けて記録し、戻す手順が分かる形になっているか
- 調査結果・告知日・実施日・戻し方を、変更管理の記録に残したか
- 「調べたうえで残す」と決めた場合も、その理由と再検討の条件を書き残したか
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「記録で確かめてから、段階を踏む」さえ守れれば、この作業はもう危ない賭けではなくなります。
よければ、こちらも
使われていないものの棚卸しは、置き場所を変えれば同じ手順が使えます。あわせて少しずつ整えていくと効きます。
- 公開ディレクトリの置きっぱなしファイル棚卸し｜外から見えていないか：画面ではなく、サーバー上に残ったファイル側の棚卸しです。この記事と対で使えます。
- cron・常駐プロセスの棚卸し手順｜何が自動で動いているか把握する：出力先を誰も見ていないバッチを見つけるとき、まずここから始めると早いです。
- 既存システムの改修｜影響範囲を見落とさない調査の順番：裏でつながっている処理を見落とさないための調べ方をまとめています。
- 技術的負債の見える化｜優先順位のつけ方を一人運用の現場で：どの機能から手を付けるかを決めるとき、全体の優先順位づけが助けになります。
- 変更管理台帳の付け方｜いつ・誰が・何を変えたか残す：消した記録・残した記録を、後から引ける形にしておくための書き方です。
使われていない機能が残っているのは、放置してきたからではないと思います。消して困る人が出ることを、ちゃんと想像できているから手が止まっているだけです。その慎重さは、システムを預かる人として正しいものです。
だから、必要なのは思い切りではなく、順番でした。記録で確かめて、隠して、止めて、それから消す。各段のあいだに待つ時間を置く。それだけで、こわかった作業が普通の作業に変わります。そして調べた結果「残す」と決めるのも、立派に前進です。
まずは、いちばん気になっている画面を1つ、ログで数えてみるところから。今日その1件を調べておけば、次に棚卸しの話が出たとき、あなたはもう答えを1つ持っています。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。