「いつかやろう」と思っていたリファクタリングを、Codexと一緒に進めた話

コードベースの中に、見るたびに「いつか整理しよう」と思いながら、何ヶ月も放置しているファイルがある——そういう経験がある人は、決して少なくないはずだ。

リファクタリングは大切だと分かっている。技術的負債が積み上がれば、後になるほど修正が難しくなることも知っている。それでも後回しになる。「今は新機能が優先」「動いているコードをわざわざ触るリスクは取れない」「どこから手をつければいいか分からない」——正直なところ、全部が理由だった。

変わったきっかけは、あるとき試しにCodexに「このファイルのコードの問題点を指摘してください」と渡してみたことだった。返ってきた内容は、自分が薄々気づいていたことと、全く気づいていなかったことが混ざっていた。そこから少しずつ、Codexを使ったリファクタリングが習慣になっていった。

この記事では、Codexとリファクタリングを進めた実際の体験と、具体的な使い方、そして「ここだけは自分でやるべき」と学んだことを書いていく。

結論から言うと、Codexはリファクタリングの「どこから手をつければいいか分からない」という最初の詰まりを解消してくれる存在として、使い方次第で強力なツールになる。ただし、リファクタリングの最終的な判断は人間がしなければならない部分が多く、そこを理解した上で使うことが重要だ。

リファクタリングが後回しになり続けた理由

なぜリファクタリングは後回しになるのか。自分の経験から整理してみると、大きく2つの理由があった。

「壊れていないものは触らない」という感覚

動いているコードを変えることには、リスクが伴う。リファクタリングは機能を変えない変更のはずだが、それでも何かが壊れる可能性はゼロではない。特にテストが充実していないコードは、「触ったら壊れるかもしれない」という不安が強くなる。

この感覚は理性的でもある。新機能の開発やバグ修正には明確な成果が見えるが、リファクタリングの成果は「コードがきれいになった」という抽象的なものだ。チームや上司に対して「今週はリファクタリングをしていました」と報告しにくい雰囲気がある場合もある。

結果として、リファクタリングは「やるべき」という認識はあっても、「今やる理由」が見つかりにくい作業になっていた。

どこから手をつければいいか分からない問題

リファクタリングのもう一つの障壁は、「どこから始めるか」だ。コードベース全体を見渡すと、気になる箇所はあちこちにある。長すぎる関数、意味の分からない変数名、コピーペーストされた重複コード、複雑すぎる条件分岐——問題を挙げだしたらきりがない。

全部やろうとすると途方もない作業量になり、「やっぱり後で」になる。一部だけやっても「中途半端に手を入れた」という後ろめたさが残る。この心理的な詰まりが、リファクタリングを後回しにし続ける大きな原因だった。

Codexは、この「どこから手をつければいいか」という問いに対して、優先度付きで答えを出してくれる。これが、Codexをリファクタリングに使う最初の価値だと気づいた。

Codexにリファクタリングを頼むとはどういうことか

Codexとは、OpenAI社が提供するAIコーディングエージェントのことだ。コードを読み取り、問題点の指摘や改善案の提示、リファクタリング後のコードの生成まで行うことができる。

Codexへのリファクタリング依頼の基本

最も基本的な使い方は、対象のコードを貼り付けて「このコードの問題点を指摘してください」または「このコードをリファクタリングしてください」と依頼することだ。

より効果的な依頼の仕方として、以下のパターンを使い分けている。

• 問題点の洗い出し：「このコードの可読性・保守性の問題点を列挙してください」
• 優先度付き改善：「このコードで最初に改善すべき箇所を3つ教えてください」
• 改善案の生成：「このコードをより読みやすい形にリファクタリングしてください。変更点を説明してください」
• 特定の観点での指摘：「このコードで関数が長すぎる、または責務が多すぎる箇所を指摘してください」

「問題点を教えてください」だけでも有用な回答は返ってくるが、「最初に改善すべき箇所を3つ」のように絞ることで、どこから手をつければよいかが明確になる。リファクタリングの「最初の詰まり」を解消するには、この絞り込みが効果的だ。

どんな種類の改善提案が返ってくるか

Codexが返してくれるリファクタリング提案は、大きく以下の種類に分類できる。

• 命名の改善：意味の分かりにくい変数名・関数名を、より意図が伝わる名前に変える
• 関数の分割：1つの関数が複数のことをやっている場合に、責務ごとに分割する
• 重複コードの統合：同じ処理が複数箇所に書かれている場合に、共通化する
• 条件分岐の簡略化：複雑なif-elseを、より読みやすい形（ガード節・早期リターンなど）に変える
• マジックナンバーの定数化：コード中に直書きされた数値・文字列を、意味のある定数に置き換える

これらはいずれも、コードの「動き」を変えずに「読みやすさ・保守性」を高める変更だ。Codexはこういった変更を、変更前後のコードと変更理由をセットで提示してくれるため、「なぜこう変えるべきか」を理解しながら適用できる。

実際にCodexとリファクタリングを進めてみた

実際に試して印象に残った2つの場面を書く。

関数の分割と命名の改善

最初に試したのは、長い間そのままにしていた処理関数だった。100行を超えていて、データの取得・変換・バリデーション・保存を一つの関数の中でやっていた。

Codexに「この関数の責務が多すぎる部分を指摘して、どう分割すべか教えてください」と渡したところ、4つの独立した関数への分割案が返ってきた。それぞれの関数名もより意図が明確なものに変えられていて、変更後のコードの方がずっと読みやすかった。

注目したのは、Codexが「この関数はデータの変換と保存を同時にやっているため、テストが書きにくくなっています」という指摘を一緒に入れてきたことだ。関数を分割することがテスタビリティの向上につながるという観点を、私は意識していなかった。リファクタリングがテストの書きやすさと直結していることを、このとき初めて体感した。

重複コードの検出と整理

次に試したのは、複数のファイルにまたがって似たような処理が書かれているケースだった。「このファイル群の中で重複している処理を見つけて、共通化の提案をしてください」と渡してみた。

Codexは、3箇所に分散していたバリデーション処理が実質的に同じロジックであることを指摘し、共通のヘルパー関数としてまとめる案を提示してくれた。自分では「似ているけど微妙に違う」と思い込んでいたコードが、実は全く同じ処理だったことに気づかされた。

Codexにコードを渡すことで、「近い場所にいるから見えていなかった問題」に気づける。書いた本人には当たり前すぎて見えない重複や非効率を、外部の視点として指摘してもらえるのが、Codexをリファクタリングに使う独特の価値だと感じた。

Codexのリファクタリング提案で気づいたこと

自分の「コードのクセ」が見えてくる

Codexを使ってリファクタリングを続けていると、同じ種類の指摘が繰り返されることに気づく。私の場合は「変数名が省略されすぎている」「条件分岐が深くネストしている」という指摘が頻出した。

これは、Codexが自分のコードのクセを映し出してくれているということだ。「自分はこういう書き方をしがちだ」と客観的に認識できるようになると、新しいコードを書くときにも意識が変わってくる。Codexによるリファクタリングの指摘が、コーディングスタイル全体の改善につながっていった。

設計の問題が「可読性の問題」として表面化する

Codexが「この関数が長すぎる」「命名が不明瞭」と指摘してくる場合、その奥に設計の問題が潜んでいることが多い。関数が長い理由は、責務が分離されていないからだ。命名が不明瞭な理由は、その変数が何を表すのかを書いた本人も明確に説明できていないからだ。

Codexの可読性への指摘は、設計の問題のサインとして読める。「Codexにリファクタリングしてもらった」だけで終わらず、「なぜこのような指摘が出るコードを書いたか」を振り返ることで、設計の考え方が少しずつ変わっていった。

Codexに任せすぎないために

ビジネスロジックの判断は人間が行う

Codexはコードの構造・命名・重複といった「技術的な観点」での改善提案は得意だが、「このコードがビジネス上の何をするか」は知らない。そのため、ビジネスロジックに深く関わる判断——たとえば「この条件分岐はビジネスルール上必要だから残すべき」という判断——はCodexにはできない。

Codexが「この条件分岐は不要に見える」と提案してきても、ビジネス要件上の理由があれば残さなければならない。コードを渡す前に「このコードのビジネス上の制約として〜があります」と伝えることで、誤った提案を減らせる場合があるが、最終的な判断は必ず自分で行う必要がある。

リファクタリング前後のテストの重要性

Codexが提案したリファクタリングを適用する前に、既存のテストが通ることを確認する。テストがない場合は、リファクタリング前のコードの動作を確認するテストを先に用意することを強く勧める。

リファクタリングは「動作を変えない変更」のはずだが、Codexの提案を適用することで意図せず動作が変わるリスクはゼロではない。特に、副作用のある処理や外部システムと連携する箇所は注意が必要だ。「Codexが正しいと言ったから」ではなく、テストが通ることで動作が変わっていないことを確認する習慣が、安全なリファクタリングの基本だ。

よくある質問（FAQ）

まとめ：「いつかやろう」は、Codexが終わらせてくれた

Codexとリファクタリングを進めてから変わったことを振り返る。

変わる前は、「どこから手をつければいいか分からない」という詰まりが最初の壁になっていた。コードの問題は見えているのに、全体の量に圧倒されて何も動けない——という状態が続いていた。

Codexを使い始めてから、「まずCodexに問題点を出してもらい、優先度の高いものから1つずつ進める」という流れが生まれた。最初の壁がなくなったことで、リファクタリングを小さく始めることができるようになった。

さらに予想していなかった変化として、「Codexの指摘から自分のコードのクセが見えてくる」という学習効果があった。同じ種類の指摘が繰り返されることで、自分が新しいコードを書くときにも「またこのクセが出ていないか」を意識するようになった。リファクタリングが、コーディングスタイル全体の改善につながったのだ。

「いつかやろう」が終わらなかったリファクタリングは、「最初の一手」を出してくれるパートナーがいれば動き始められる。Codexは、その最初の一手を担ってくれる存在だった。

「いつかやろう」と思っているコードが手元にある方は、まずそのファイルをCodexに渡して「問題点を3つ教えてください」と聞いてみてほしい。「どこから手をつければいいか分からない」という詰まりが、そこから動き始めるかもしれない。