AIで速く作れるほど、後から直せる設計が重要になる
AIコーディング支援ツールを使うと、簡単な業務アプリや管理画面は驚くほど速く形になります。問い合わせ一覧、見積作成、社内検索、レポート生成など、以前なら数週間かかった試作が数日で動くこともあります。
ただし、速く作れることと、長く安全に使えることは別です。AIが追加した処理、人間が急いで直した処理、過去の仕様を守るための例外処理が重なると、最初は動いていたコードでも、次の修正が急に難しくなることがあります。
ここで必要になるのがリファクタリングです。リファクタリングは、動作を変えずに既存コードの設計を改善する取り組みです。Martin Fowler は、リファクタリングを小さな振る舞い保存の変更を積み重ねて既存コードの設計を改善する技法として説明しています。
大切なのは、「きれいにしたいから直す」だけでは足りないということです。AIに「もっと整理して」と頼むと、改善案は延々と出てきます。目的を決めないリファクタリングは、終わりのない作業になりがちです。
リファクタリングすべき5つのサイン
AIコーディングで作ったシステムでも、すべてを毎回リファクタリングする必要はありません。まずは、次のようなサインがあるかを見ます。
1つ目は、同じ処理が複数箇所に増えていることです。例えば、同じ顧客データを複数回問い合わせている、同じ形式チェックを別々の画面で書いている、同じメール文面生成ロジックが散らばっている、といった状態です。このまま機能追加を続けると、修正漏れが起きやすくなります。
2つ目は、仕様の例外対応でコードが膨らんでいることです。たった1つの特殊ケースを守るために、全体の見通しが悪くなっている場合があります。その仕様が本当に必要か、運用で吸収できないかを確認するだけで、システムがかなり簡単になることがあります。
3つ目は、次の機能追加が怖くなっていることです。「ここを直すと別の画面が壊れそう」「どの関数が本体なのか分からない」と感じるなら、すでに変更コストが上がっています。動いているから大丈夫ではなく、次の変更が安全にできるかを見るべきです。
4つ目は、AIと人間の修正方針が混ざっていることです。AIは既存コードを見てかなり自然に合わせますが、常に完全ではありません。少しだけ違う命名、少しだけ違うエラー処理、少しだけ違うデータ取得方法が積み重なると、コードベース全体のノイズになります。
5つ目は、レビューやテストで説明しにくいことです。担当者が「たぶん動きます」としか言えない状態は危険です。AI生成コードであっても、人間が読んで責任を持てる状態にしておく必要があります。OWASPのSecure Coding with AIでも、AI生成コードには人間の所有者と承認が必要だと整理されています。
「無限改善」を止めるための依頼の仕方
AIにリファクタリングを頼むときは、「きれいにして」ではなく、完了条件を先に決めます。
例えば、次のように依頼します。
- 重複している顧客取得処理を1つの関数にまとめる
- 画面表示用の処理とDB更新処理を分離する
- 既存のテストが通る範囲で、1コミットに収まる差分にする
- 仕様変更は行わず、関数名・責務・ファイル分割だけを整理する
- 変更後に実行するテストコマンドを明記する
これだけで、AIの作業はかなり安定します。逆に、最終形を人間側が持っていないままAIに任せると、もっともらしい改善が何ターンも続きます。コードは変わっているのに、保守性が本当に上がったのか判断できない状態になります。
リファクタリングは、AIに考えさせる作業ではなく、人間が設計判断を行い、AIに安全に手を動かしてもらう作業です。ここを分けておくと、AIコーディングの疲労感はかなり減ります。
チームで使うなら、プロジェクト標準を文章にする
1人でAIコーディングを使う場合と、チーム全員が使う場合ではリスクが変わります。チームでは、各自のAIが少しずつ違う書き方を持ち込みます。短期的には問題なく見えても、半年後には「誰の書き方でもないコード」が増えることがあります。
そのため、AI導入時には以下を文章化しておくのがおすすめです。
- 命名規則
- ファイル分割の基準
- APIやDBアクセスの責務
- エラー処理の方針
- テストを書く範囲
- AIに触らせてよいファイル、触らせないファイル
- レビュー時に必ず見る観点
GitHub Copilot code review では、リポジトリにカスタム指示ファイルを置き、レビュー時に考慮させる情報を定義できます。ツールにより方式は異なりますが、「毎回チャットで説明する」のではなく、プロジェクトの標準をリポジトリに残す考え方は共通して有効です。
ただし、AIレビューは人間レビューの代替ではありません。OWASPも、AIが書いたコードであっても、提出者が理解し、レビューし、責任を持つべきだとしています。AIを使うほど、最終承認者の役割はむしろ重要になります。
Optiensの見方
Optiensでは、AI活用診断や小規模業務システムの設計支援において、「作れるか」だけでなく「あとから直せるか」を重視しています。
AIは初期実装を速くします。しかし、問い合わせ分類、見積作成、社内検索、レポート生成のような業務システムは、運用が始まってから例外が増えます。担当者が変わる、帳票の形式が変わる、確認フローが増える、外部サービスの仕様が変わる。そうした変更に耐えられるように、最初から責務分離、ログ、テスト、手動復旧手順を設計しておく必要があります。
AIコーディングを導入する中小企業にとって、最初のゴールは「AIで何でも自動化すること」ではありません。
まずは小さく作る。次に変更しやすい形に整える。最後に、チームで安全に育てるルールを作る。この順番が現実的です。
AIで速く作れる時代だからこそ、リファクタリングは職人の趣味ではなく、事業を止めないための保守設計になります。