機能追加や修正を繰り返すうちにコードは少しずつ「汚れ」ていきます。エンジニアが「リファクタリング」と呼ぶクリーンアップ作業の意味と目的、実際の現場でよく見つかる問題事例をもとにわかりやすく解説します。
ホームページを公開・運用していく中で、機能の追加や修正をくり返すうちに、コードの中に「不要なもの」や「重複したもの」が少しずつたまっていきます。コードクリーンアップとは、そうした積み重なった汚れを取り除き、コードを整理・整頓する作業のことです。
本記事では、実際のサイト制作・運用の現場で見つかった7つの問題と原因、AIでコードを書く時代にクリーンアップの重要性が増している理由、そして非エンジニアの発注者が品質を確かめる方法までを整理します。
1. コードクリーンアップとは何か
エンジニアの間では「リファクタリング」とも呼ばれます。見た目や機能を変えずに、コードの内部の品質を高める作業です。「家の大掃除」に近いイメージで、住み続けるほど必要になり、定期的に行うことで快適さが保たれます。
大切なのは、「見た目や動きは変えない」という点です。デザインを変えるリニューアルとは別物で、中身を整理して、将来の修正をしやすくするための投資です。
2. なぜ必要なのか：技術的負債という「見えない経費」
コードが散らかった状態だと、次に修正しようとしたときに「どこを触ればいいかわからない」「なぜこうなっているのかわからない」という状況が起きやすくなります。これは「技術的負債」と呼ばれ、後回しにするほど返すのが大変になります。
散らかったコードに新しい修正を頼むと、制作会社はまず「今どうなっているか」を調べる時間が必要になります。この調査の時間は見積書に明記されないことも多く、「簡単な修正のはずなのに、なぜか工数が膨らむ」という体感につながります。特に、制作会社を乗り換えるとき、担当者が退職・異動したとき、デザインを一部だけ変えたいときに、このコストが表に出やすくなります。
決済サービス大手のStripeが、米国・英国・ドイツなどの開発者と経営層を対象に行った調査（2018年）では、開発者は週約41時間の労働のうち約17時間（約4割）を、技術的負債への対応（約13.5時間）や質の悪いコードの手直し（約3.8時間）に費やしていると報告されました。大規模な開発の調査なので、中小企業のサイト運用にそのまま当てはまるわけではありませんが、「表に出る修正費用の裏に、見えない調査と手直しの時間が隠れている」という構図は、規模を問わず共通しています。
3. 実際の現場で見つかった7つの問題
いずれも「動いているから問題ない」と判断されやすく、通常の確認では見つかりにくいものばかりです。
問題 | 何が起きていたか | 放置した場合のリスク |
|---|---|---|
1. 同じ条件のCSSが2か所に重複 | 「スマホのヘッダーを広げて」「行間を広げて」と修正を重ねるうちに、同じ画面幅向けの指定が別々の場所に追記されていた | 片方を直しても「なぜ反映されないのか」という事態になる |
2. 記事が0件のときのリンクのバグ | 「記事は必ず1件以上ある」という前提で書かれていた | 設定ミスなどで記事が取れないと、ページが壊れて見える |
3. 使われなくなったクラスが残存 | 演出の作り方を変えた後も、古いクラスを付ける処理が残っていた | 後から読む人が「何のためのコードか」と混乱する |
4. 何も変えないクラスが残存 | 修正の過程で親と同じ値になったクラスの定義が残っていた | 「意味のある設定か、バグか」が判断できなくなる |
5. 部品が必要以上に複製 | 記事が少なくても途切れないよう、自動で流れる表示のデータを多めに複製していた。実際は半分で十分だった | ページの読み込みや処理に余分な負荷がかかる |
6. 調整の痕跡が未整理 | 「1.375rem + 5px」のように、単位の違う値を足して見た目を合わせた跡が残っていた | 後から見ると意図が読み取れない |
7. 使われていない変数が残存 | 「将来使うかも」と用意したフォントの変数が、使われないまま同じ値で2つ残っていた | 片方だけ更新して食い違う原因になる |
4. 問題が生まれる5つの根本原因
原因 | 該当する問題 |
|---|---|
段階的な修正の積み重ね | 重複したCSS、調整の痕跡 |
例外的なケースの見落とし | 記事0件のときのバグ |
作り方を変えたときの削除漏れ | 使われないクラス、何も変えないクラス |
過剰な安全マージン | 部品の過剰な複製 |
使われなかった将来の想定 | 重複した変数 |
共通しているのは、機能には影響しないため、通常の確認では見つからず、定期的なクリーンアップで初めて見つかるという点です。
5. AIでコードを書く時代に、なぜ重要性が増すのか
AIにコードを書かせる進め方が広がり、指示を出せば数秒でコードができるようになりました。その便利さの裏で、今回紹介したような重複や削除漏れが起きやすくなっています。AIは「いま指示された内容」には応えますが、過去に書いたコードとの整合性まで自発的に配慮してくれるとは限らないからです。
データでもこの傾向が示されています。開発データの分析を行うGitClearが、2020〜2024年に書かれた約2億1,100万行のコードの変更を分析した2025年の報告では、AIによるコーディング支援が広がるのと同じ時期に、コピー＆ペーストで複製された行の割合が2021年の8.3%から2024年には12.3%に増えました。一方で、既存のコードを整理して再利用する「移動」の割合は、2021年の約25%から2024年には10%未満に下がり、「コピー＆ペースト」が「移動」を初めて上回ったとされています。重複したコードは、片方だけを直してもう片方を直し忘れる、という不具合の原因になりやすいため、AIで作る量が増えるほど、定期的な整理の重要性は増していきます。
一方で、AIはクリーンアップの「発見」には強力な武器にもなります。人が目視で全ファイルを見比べるのは現実的ではありませんが、AIにコード全体を読ませて「重複しているCSSはないか」「使われていない変数やクラスはないか」を洗い出させるのは得意な作業です。ただし、「削除して本当に問題ないか」を判断し、動作を確かめるのは、人の役割として残ります。
6. 進め方：見つける、確かめる、直す、確かめる
- 記録を残す：作業前にGitなどで現在の状態を記録し、いつでも戻せるようにする
- 見つける：AIに候補を洗い出させるほか、ブラウザの開発者ツールの「カバレッジ」機能で、使われていないCSSやJavaScriptの割合を確かめることもできる
- 確かめる：候補ごとに「本当に使われていないか」を検索して確認する。特定の画面幅や条件のときだけ使われているコードもある
- 直す：一度に全部直さず、種類ごとに小さく分けて直す
- もう一度確かめる：主要なページを、パソコンとスマートフォンの両方で表示して、見た目と動きが変わっていないことを確認する
「小さく分けて直す」のが大切なポイントです。まとめて直すと、どの修正で問題が起きたのかが分からなくなります。
手順2の「カバレッジ」は、Google Chromeの開発者ツール（ページを右クリックして「検証」を選ぶと開く画面）に入っている機能です。コマンドメニューで「Show Coverage」を選び、再読み込みのボタンを押すと、ファイルごとに「読み込まれたうち、実際には使われなかった量」が一覧と棒グラフで表示されます。ただし、分かるのは「記録している間に、そのページで使われたかどうか」だけです。別のページや、スマートフォンの画面幅、メニューを開いたときにだけ使われるコードも「使われていない」と表示されるため、この結果だけで削除を決めず、手順3の「確かめる」と組み合わせて判断します。
AIに洗い出しを頼むときは、いきなり「きれいにして」と任せるより、次のように「まず報告だけ」を求めるのが安全です。
- 「このサイトのCSSとJavaScriptを読んで、重複している指定、使われていないクラスや変数の候補を一覧にしてください。まだ修正はしないでください」
- 「それぞれの候補について、本当に使われていないと判断した根拠と、消した場合に影響しそうなページを書いてください」
- 「一覧のうち、影響の小さいものから1種類ずつ直してください。直すたびに変更点を報告してください」
「報告→判断→小さく修正→確認」の順にすると、AIが「使われていない」と誤って判断したコードを消してしまう事故を防げます。AIの洗い出しは速い一方で、条件付きで使われるコードを見落とすこともあるため、根拠を書かせることが大切です。
7. メリットと注意点、行うタイミング
メリット | 注意点 |
|---|---|
次回以降の修正・追加が速くなる | 見た目や機能が変わらないため、成果が見えにくい |
バグが起きにくくなる | 作業中に誤って動作に影響を与えるリスクがある |
引き継ぎ先が読みやすいコードになる | 短期的には時間と費用がかかる |
ページの読み込みが軽くなる場合がある | 「特定の条件でだけ使われるコード」を消してしまう恐れがある |
行うとよいタイミングは、大きな機能追加やリニューアルが一段落したとき、制作会社や担当者が変わるとき、表示の速さや動きに違和感を感じ始めたとき、そして半年〜1年に1回の定期点検です。定期的なクリーンアップは、「将来の修正費用を先払いで抑える保険」と捉えることができます。
8. 依頼するときのチェックリストとよくある誤解
コードの中身が分からなくても、次の4点を確認すれば、依頼した作業がきちんと行われたかを判断できます。
- バックアップ：作業前に、変更の記録（Gitなど）を取っているか
- 報告：見つかった問題を一覧で報告してもらえるか（原因まで説明があるとなお良い）
- 動作確認：作業後に、主要なページの表示と動きを、スマホとパソコンの両方で確認してもらえるか
- 次回の目安：次にいつ頃、再度確認すべきかを聞いておく
よくある誤解1：「クリーンアップ＝作り直し」：クリーンアップは見た目や機能を変えずに内部を整理する作業で、ゼロから作り直すリニューアルとは別物です。はるかに小さな費用と期間で行えます。
よくある誤解2：「エンジニアでないと良し悪しを判断できない」：確認すべきは、「作業後も見た目と動きが変わっていないか」「変更の記録が残っているか」「対応内容が一覧で報告されているか」の3点で十分です。
9. よくある質問
クリーンアップをすると、サイトの表示は速くなりますか？
速くなる場合はありますが、必ずではありません。使われていないCSSやJavaScriptを多く読み込んでいたサイトでは、整理によって読み込む量が減り、表示が軽くなることがあります。速さを目的にするなら、作業の前後に同じページをGoogleの無料の診断ツール「PageSpeed Insights」で測り、数値を比べてもらうと効果を確かめられます。
Gitを使っていないサイトでも、クリーンアップを頼めますか？
頼めます。その場合は、作業前にサーバー上のファイル一式を日付付きでコピーして保管してもらい、問題が起きたらそこへ戻せるようにします。ただし、コピーだけでは「どこを変えたか」を比べにくいため、この機会にGitでの管理も相談するとよいでしょう。
AIに頼めば、エンジニアがいなくても自分でできますか？
洗い出しまでは、エンジニアでなくても試せます。AIに「まだ修正せず、候補と根拠の一覧だけ出して」と頼めば、どこに整理の余地があるかを把握できます。ただし、実際に消すかどうかの判断と、消した後の表示の確認には、コードの知識と手間が必要です。社内にエンジニアがいない場合は、その一覧を制作会社に渡して、修正と確認を依頼するのが安全です。
10. まとめ
- コードクリーンアップは、見た目や機能を変えずにコードの内部を整理する作業。将来の修正を楽にする投資
- 散らかったコードは「見えない調査の時間」として、修正のたびに費用を押し上げる
- 現場で見つかる問題は、修正の積み重ね、例外の見落とし、削除漏れなど5つの原因から生まれる
- AIでコードを書く量が増えるほど重複がたまりやすい。一方で、候補の発見はAIの得意分野
- 記録を残し、小さく分けて直し、パソコンとスマホで確かめる。発注者は「バックアップ・報告・動作確認・次回の目安」を確認する
参考資料
