1. はじめに
こんにちは。Oisixプロダクト開発部の栗崎です。
前回の記事では、第三世代アーキテクチャのアプリケーションを Spring Boot 4 に揃えた話を紹介しました。
今回はその反対側の話です。 Oisix技術スタック紹介（2025年度版）では意図的に触れられていなかったレガシー側——2000年から動き続けてきた EC サイトのコードベースから、もう使われていないコードを掘り出して消していく取り組みを紹介します。
デッドコードの削除は誰が進めてもよい作業ですが、主に同僚のひとり（Findy Team+ の事例インタビューにも登場しています）が精力的に進めてくれています。ありがたいことです。私はもっと積極的に関わりたいと思いつつ、いまのところレビュアーとしての関わりに留まっています。 レビューをしていると、見覚えはあるものの正体は知らないコードが diff になって流れてきます。残骸であることはほぼ分かっていても、それが「何の」残骸なのかは、消すための調査で初めて分かることが少なくありません。デッドコードの削除は、結果として25年分の歴史の発掘作業にもなっていました。
この取り組みは現在も継続中です。本記事は最終報告ではなく、発掘の途中経過の記録です。
2. 背景
2-1. 25年分のコード
ECサイト「Oisix」は2000年のサービス開始から、25年以上動き続けています。 その間に、キャンペーン、実験的なサービス、他社との協業、買収したサービスの統合——さまざまな機能がコードベースに追加されてきました。
機能は終わってもコードは自動では消えません。 呼ばれなくなったコードは「デッドコード」としてコードベースに残り続けます。
2-2. デッドコード削除の取り組み
このデッドコードをリファクタリングの一環として継続的に削除しています。
進め方は起票ベースです。 コードを触っていて「これは使われていないのではないか」と気づいたものを候補として一覧に起票し、調査のうえで削除するかを判断します。調査した結果「削除できるが、いまは触らない」と却下になるものもあります。
起票された候補は、リスクで分類して優先度をつけています。
- 低リスク: テストコードのみの削除
- 中リスク: 本番コードに触れる削除
- 高リスク: 設定ファイルなど、影響範囲の見極めが難しいものに触れる削除
「使われていない」の裏取りは、複数の証拠を重ねて行います。 アクセスログと静的解析が基本で、外部サービスと連携するコードならそのサービス自体がまだ生きているかを確認します。データを書き込む経路なら、シーケンス番号やレコード量といった「使われていれば必ず変化する値」がいつから止まっているかを見ます。そして一番重いのが、開発環境で実際に動かしてみることです。
なお、アクセスログに記録があることは、必ずしも使われていることを意味しません。 bot からのアクセスしか残っていないこともあるためです。誰が（何が）アクセスしているのかまで見て、初めて生死を判定できます。
3. 発掘エピソード
ここからは削除の diff から出てきたものを4つ紹介します。
3-1. Okasix（おかしっくす）
ひとつ目は isOkasix() という判定メソッドです。
Okasix というサービスを判定していたようなのですが、その Okasix が何だったのかは、いまとなってはよく分かりません。名前と断片的な記憶から「たぶんお菓子を売っていた」と言われている程度です。
コードは残っているのに、それが何かを説明できる人もドキュメントも残っていない。 放置されたデッドコードの行き着く先が、これです。
Okasix に関連する URL にはいまもアクセスがあります。 ログに残っていた User-Agent がこちらです。
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
ClaudeBot、Anthropic のクローラーです。
誰も正体をよく知らないサービスを、AI だけがいまも読みに来ています1。
isOkasix() は調査のうえ削除されました。
3-2. ガラケー向けサイト
かつての Oisix には、ガラケー（フィーチャーフォン）向けのサイトがありました。 User-Agent でガラケーを判定して専用画面へ振り分け、キャリアごとの絵文字に対応し、文字コードは Shift_JIS。スマートフォン以前の Web 開発がひとそろい、コードベースに残っていました。
ガラケー判定のメソッドは isMobile() という名前でした。
命名された当時は「モバイル」といえばガラケーのことだったので、正しい名前でした。しかしスマートフォンの時代にこの名前を見ると、スマホ判定に使えるメソッドに見えてしまいます（使えません）。コードは何も変わっていないのに、言葉の意味が時代とともにズレて、名前が罠に変わっていました。
しかもこの UA 判定、同じ実装が2箇所にあり、ガラケー向けの分岐は View 層に限らずあちこちに散らばっていました。 役目を終えた分岐は、調査のノイズとしてだけ働き続けていました。
3-3. ごちまる
ごちまるは、2021年に Oisix へ統合されて終了したサービスです。
サービスの統合とコードの削除は別の作業です。
統合から4年以上たったコードベースには、ごちまるかどうかの判定 isGochi() がいたるところに散らばっていました。メール文面のクラスには「ごちまる」というブランド名がハードコードされ、クーポンのテーブルにも痕跡が残っていました。体感では、今回の4つの中でこれが一番のノイズでした。
散らばりの物量はそのまま削除の物量になります。
isGochi() の参照の削除は、第1弾から第4弾まで分割してリリースする規模になりました。ひとつのサービスを畳んでも、その判定分岐は畳まれずに全域で生き続ける。「サービスの終了」と「コードの終了」の間にはこれだけの距離があります。
そして、コードから消してもまだ終わりではありません。 DB のカラムには、ごちまるのフラグがいまも残っています。残骸にはコードの層の下にデータの層があります。
3-4. Wellness
Wellness は、買収によってグループに加わり、その後終了したサービスです。
コードベースに残っていたのは、Wellness かどうかを判定する処理でした。 判定した先のサイトはもう存在しないのに、判定メソッドとその参照、そして使われることのないユニットテストが大量に残っていました。
Wellness には過去に一度きちんと消す対応をした形跡がありました。 今回残っていたのは、そのときの消し残しとみられます。一度掃除をしても残骸は残ります。
使われていないユニットテストを大量に消した効果は、CI の実行時間が少し短くなるという形で現れました。 地味な話ですが、削除の効果が数字で見えた実例です。
4. デッドコードの弊害
デッドコードは動きません。動かないコードがなぜ問題なのか。
まず調査のノイズになります。 仕様を調べるために grep をすればデッドコードもヒットし、読まなくていいものを読んで、追わなくていい分岐を追うことになります。放置が長引くほど「これは消していいのか」を判断できる人もいなくなり、ノイズは固定化します。
変更の足かせにもなります。 デッドコードもビルドの対象であり、依存関係の一部です。ライブラリのバージョンアップをすれば、デッドコードのコンパイルエラーも直すことになります。使われていないコードの面倒を、使われているコードと同じコストで見続けることになります。
そして、これが今回の取り組みの大きなモチベーションですが、AI エージェントにとってデッドコードは人間以上のノイズになります。 経験のあるエンジニアは「このあたりは古いから見なくていい」という暗黙の地図を持っていますが、AI エージェントはコードベースをフラットに読みます。コード上は生きているのか死んでいるのか区別がつかないため、デッドコードの分だけ余計な調査コストがかかり、判断もブレます。
レガシーコードと AI エージェントの相性の悪さの、少なくとも一因はここにあります。 AI に任せられる範囲を広げたいなら、読ませるコードベースからノイズを減らす。デッドコード削除は、AI 駆動開発の土台作りでもあります。
5. どう消しているか
大きな機能をひと息に消すことはせず、段階に分けて削除しています。 3-3 で書いたごちまるの判定メソッドを第1弾から第4弾に分けたのも、この考え方です。一度に消す範囲を絞ることで、レビューの範囲と、問題があったときの切り戻しの範囲が小さく保たれます。
テストコードのみの低リスクな削除から着手して、本番コードに触れる削除へ進む順序も同じ発想です。
消し方にも段取りがあります。 たとえばガラケー判定のメソッドは、いきなり消すのではなく、まず戻り値を false に固定して挙動を確定させました。そのうえで「常に false なら、この分岐は不要」と参照箇所を機械的に削除していき、参照がなくなったところでメソッド本体を削除します。挙動の変更と、コードの削除を、別のステップに分ける段取りです。
ここでも AI を活用しています。 事前調査の段階で対象範囲を Claude Code に調査させてその結果を記録しておき、削除の実作業でも、CI の前後で別セッションの Claude Code に PR をレビューさせています。PR の本文も Claude Code に書かせていますが、社内の読者に伝わらない調査メモの名前まで書いてしまうことがあるので、伝わりづらいときは人間が手直ししています。
事前調査の記録は資産になります。 一度調査した結果を残しておくと、次の削除で AI が再調査する時間が大幅に減り、「次はここが消せるのではないか」という候補の提案も的確になっていきました。前回の記事で書いた「覚書を育てながら横展開する」と、まったく同じ構造です。
一方で任せきれない部分も残っています。 削除後の動作確認やユニットテストの実行は人間の確認が必要なため、体感の速度は手動で消していた頃と大きくは変わりません。AI で速くなるのは調査と機械的な書き換えで、「壊れていないことの確認」は依然として人間の仕事です。
6. お掃除でやらかした話
あるクリーンアップのリリース後、一部の画面が表示されなくなる障害が起きました。ログ監視のアラートで検知し、原因のファイルを特定して、すぐに止血対応をしています。
原因は、削除した Java のクラスを別リポジトリの JSP が import していたことでした。 リポジトリを跨いだ参照は、検索から漏れやすい場所です。加えて、古い JSP はコメントアウトされたコードにも検索がヒットするため、実体の参照なのかコメントなのかの判別が難しい。結果として、AI による事前調査、AI による対応、AI によるレビュー、そして人間によるレビュー2回——このすべてを、1ファイルだけがすり抜けました。
この事故の種がずっと昔に仕込まれていたことも分かっています。 問題のファイルは2016年に、不要な import を含むファイルを複製して作られました。2018年に中身がコメントアウトされましたが、参照と import は残されました。2020年の大規模なクリーンアップでは、削除対象から漏れました。そして2026年、import の先を削除したことで発火しました。
もうひとつ、古いコードベースならではの事情もあります。 古い JSP は文字コードが Shift_JIS で、AI がファイル検索に失敗することがあります（現在は対策済みです）。25年もののコードベースには、コードの内容だけでなく、文字コードという地層まであるわけです。
同じ漏れがほかにないかも確認しました。 止血対応の際に検索でヒットしたファイルをすべて調べ、ほかに生きている参照は残っていないことを確認したうえで、無効なままになっていたファイルも合わせて削除しています。
ポストモーテムの結論は「クリーンアップをやめる」ではありませんでした。 そもそも不要になった時点で消えていれば、この事故自体が存在しませんでした。事故はお掃除をやめる理由ではなく、続ける理由である——そう整理して、発掘は続いています。
7. 数字で振り返り
これまでの削除の累計をクリーンアップの PR のマージ実績から集計しました（2026年8月時点）。
| 指標 | 値 |
|---|---|
| 削除の PR 数 | 83 |
| 削除した行数 | 732,697 |
| 追加した行数 | 2,560 |
| 変更ファイル数 | 約5,800 |
| 期間 | 2025年12月〜（継続中） |
削除73万行に対して追加は2,560行。 diff のほぼすべてがマイナスという、機能開発ではあまり見ない数字です。なお、行数の大半はバックアップや生成物といった、まとまって消せるファイル群です。行数の大きさがそのまま作業の大変さではありませんが、コードベースが軽くなった量ではあります。
この削除は思いつきで進めているわけではありません。 たとえば画面まわりのあるクラス群は、全件調査したうえで、2〜3割が削除可能と判定してから着手しています。削除の裏には、その何倍もの調査があります。
そしてこの数字は誰かに依頼されて積み上がったものでもありません。 削除を進めている同僚の社内発表資料に、こんな一節があります。
増やすのは仕様で決まる。でも、減らすのは誰も依頼してくれない。
自発的に動かない限り、不要なコードは永久に残ります。 累計73万行はその積み重ねです。
8. まとめ
本記事では、25年動き続ける EC サイトのデッドコード削除の取り組みを、実際に出てきたコードの記録とともに紹介しました。
Oisix のバックエンドには、25年もののレガシーシステムと、新しい基盤の上のシステムが同時に稼働しているという特徴があります。 前回の記事で書いた新基盤側の整備と、今回のレガシー側のデッドコード削除。やっていることは反対に見えますが、どちらも「AI に任せられる範囲を広げるための土台作り」という同じ方向を向いています。
レガシーシステムそのものをなくせれば話は早いのですが、25年分のシステムは一足飛びにはなくせません。 だから、いまできる範囲で効果の高いところから手を入れます。デッドコード削除はその1つです。
発掘は続いています。また何か出てきたら報告します。
- Dear Anthropic, this service has been dead for years. We would appreciate it if you could kindly tell ClaudeBot that it can stop visiting. (Yes, we are aware of robots.txt.)↩
