デッドコードとは?もう使われていないのに残り続けるコードをやさしく解説
「これ、消していいのかな」で手が止まる
リポジトリを開くと、いつからあるのか分からない関数が残っている。名前からして、たぶんもう使っていない。でも消す踏ん切りがつかなくて、そのまま閉じる。次に開いたときも、また同じところで指が止まる。この「もう動いていないのに残っているコード」のことを、デッドコードと呼びます。
デッドコードとは?ひとことで言うと
デッドコードとは、ざっくり言うと、プログラムの中に残っているけれど、実際にはもう実行されないコードのことです。日本語では「死んだコード」「不要コード」などと呼ばれることもあります。
たとえば、どこからも呼ばれなくなった関数、if の条件が絶対に成立しなくなって通らなくなった分岐、置き換え済みの古い実装、終わったキャンペーン用の処理などが当てはまります。壁にスイッチだけが残っていて、押しても何も起きない——そんなイメージです。

開発現場ではどこで使う?
実際の開発では、こんな場面で出てきます。
- 機能を作り替えたあと、古いほうの実装が残っている
- 一時的に止めた処理が、そのまま何年も残っている
- リファクタリングの前に「まず不要なコードを消したい」と考える
- AIに「未使用のコードを洗い出して」と頼む
とくに最近は、AIにコードを書かせる機会が増えたぶん、似た処理や使われないまま残る処理が生まれやすくなっています。
なぜ大事なのか
デッドコードが増えると、読む人の時間が少しずつ削られていきます。次に触る人は、それが生きているのか死んでいるのか分からないまま、念のため残す。すると、また次の人が同じところで迷う——という繰り返しになります。
検索したときのノイズも増え、影響範囲の調査に時間がかかるようになります。だから、片付けられるなら片付けたほうがいい。ただし、「使われていないように見える」と「本当に使われていない」は別物という点が、この用語のいちばん大事なところです。
具体例で見る
たとえば、createInvoicePdf という関数が、リポジトリ内のどこからも呼ばれていなかったとします。検索しても0件。消してもビルドは通り、テストも全部通りました。
ところが、月末の請求バッチが別のリポジトリにあって、そこから設定ファイル経由でこの関数名を文字列で指定していた——というケースがあります。月末までは何も起きないので、消した直後は誰も気づきません。
このように、静的な検索では見つからない呼ばれ方(動的な呼び出し、設定ファイルからの指定、フレームワークの規約による自動実行、別サービスからの参照、例外時だけ通る経路など)があるため、「見つからない=デッドコード」とは言い切れないのです。
つまり現場では?
デッドコードを消すということは、「もう誰も通らない」ことを確かめてから消す、という作業です。AIや検索が「参照なし」と言ってくれるのは、あくまで根拠の1つ目。そこから、設定ファイルやテンプレート、別リポジトリまで探し、可能なら実行ログで「本当に通っていないか」を確かめる。ここまでが、安心して消すためのひとそろいです。
知らないとどう困る?
「デッドコード=すぐ消していいコード」だと思っていると、AIが挙げた候補一覧をそのまま信じて削除してしまいます。ビルドもテストも通るので、その場では何も起きません。問題が出るのは、月末や年次の処理が動いたとき、あるいは障害時のフォールバックが必要になったときです。原因から時間が空くほど、調査は難しくなります。
よくある勘違い
- 「検索して0件だから未使用」は言い切れません。文字列で組み立てられた呼び出しは、検索に引っかかりません。
- 「テストが通ったから安全」も証明にはなりません。テストが薄い領域では、テストは何も言ってくれません。
- 「機能フラグでオフになっている=デッドコード」ではありません。止めているだけで、また使う予定かもしれません。
- コメントアウトして残せば安全、とも限りません。次の人にとっては「消していいか分からないコード」のままです。
明日やるならこれ
気になっている関数を1つだけ選んで、名前をリポジトリ全体で検索してみましょう。このとき、コードだけでなく設定ファイル・テンプレート・ジョブ定義まで対象に広げるのがコツです。それでも見つからなければ、消す前に「通ったら1行ログを出す」だけ入れて、しばらく様子を見る。判断を来月の自分に渡すのも、立派な一手です。
ひとことで言うと
デッドコードとは、プログラムに残っているけれど、もう実行されないコードのこと。ただし「見えないだけで実は生きている」ことがあるので、消す前に確かめるのが前提です。






