Refactoring
読み: リファクタリング
リファクタリングとはAIでコード改善
既存のソフトウェアの外部的な動作を変えることなく、大規模言語モデルなどのAI技術を用いて内部のソースコードを整理し、システムの可読性や保守性を向上させる技術。
かんたんに言うと
増築を重ねて迷路になった古い旅館の配管を、宿泊客に気づかれないように最新の塩ビ管へ交換し、水漏れリスクをなくすような作業。
退職者が残したスパゲティコードにAIがメスを入れるリファクタリングの基本
経理部門が15年使い倒しているオンプレミスの経費精算システム。中身は退職したエンジニアたちが残したスパゲティコードの山である。
これを人間が手作業で直すのは骨が折れる。触ればどこかが壊れる恐怖と戦いながら技術的負債を返済する作業は、誰だってやりたくない。そこでAIの出番となる。既存システムの動作を変えずに内部構造を整理し、保守性を高める。
レガシーシステムにメスを入れる際、AIは感情を持たずに淡々とコードを削っていく。人間特有の「もったいない」という感情がないのは強みである。
ソースコードを解析し修正提案を行う仕組み
LLMがコードの文脈や依存関係を読み解き、バグの温床を特定して安全な構造へ書き換える。
従来の静的解析ツールはルールベースで警告を出すだけだった。SonarQubeなどで大量の警告を出されて絶望した経験を持つエンジニアは多いはずである。AIは単に警告するだけでなく、修正案まで提示する。
ただ、その修正案が本当にシステムの意図を汲んでいるかは悩ましい。変数のスコープを勝手に変えられて、別の機能が動かなくなることもある。
開発現場での活用事例と代表的なAIツール
物流部門の在庫管理APIを刷新した際、Cursorを導入した。
ファイル間の依存関係を考慮して一気に書き換えてくれる体験は悪くない。GitHub CopilotやAmazon Q Developerもエディタに組み込んで日常的に使っている。不要なループ処理や冗長な条件分岐を数秒で消し去るスピードは、人間のタイピング速度を凌駕する。
だが、ツールに依存しすぎるとエンジニアのコードを読む力が落ちるのではないか。現場のマネージャーとしては判断が分かれるところである。
導入による費用対効果と技術的限界
AI特有のハルシネーションには常に警戒が必要である。
存在しないライブラリのメソッドを平然と呼び出すコードを提案されたときには、ため息が出る。セキュリティコンプライアンスの観点からも、未検証のコードをそのまま本番環境にデプロイするのは正気の沙汰ではない。
開発スピードが上がるメリットと、情報漏洩やバグ混入のリスク。このトレードオフをどう評価するか。現場のエンジニアとセキュリティ担当者の間で意見が対立することも珍しくない。
自社システムへの適用を判断するための評価基準
自社の開発体制に合わせてAI導入を進めるべきか。
ROIを算出し、PoCを回して効果を測るのは定石である。しかし、それ以前に絶対的な評価基準がある。それはテストコードの有無である。テストコードのないシステムにAIを突っ込む勇気はあるか。
テストカバレッジが低いシステムにAIリファクタリングを適用するのは自殺行為に近い。動作が変わっていないことを証明できないからである。AIを導入する前に、まずは泥臭くテストを書く体制が整っているか。そこを見極めないと痛い目を見る。
当社の見解
当社ではClaude Code・Antigravity・Codexの3つのAIエージェントを日常業務で併用している。記憶を共有しているため、別のAIに同じ説明を繰り返す必要がない。ただし、記憶共有だけでは足りなかった。一方のAIが他方の成果物を勝手に修正して壊す事故が起きた。これを受けてファイル所有権制度を導入し、どのAIがどのファイルを所有するかを定義した。AIの自主性に頼らず、仕組みで上書きや巻き戻りを防いでいる。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。