「この複雑に入り組んだレガシー関数、可読性が低すぎるからAIエージェントにリファクタリングさせよう」

現代のAI駆動開発において、これは最も日常的で、最も無害に見える指示の一つでしょう。実際にClaude CodeやCursor、自律エージェントに「この関数を分割し、早期リターンを使ってDRYにリファクタリングして」と命じると、驚くほど美しく整頓されたコードが一瞬で返ってきます。

手元でユニットテストを回せば全件グリーン。カバレッジレポートも90%超を維持している。レビュー担当者も「見やすくなったね」と快くApproveを押し、コードは本番環境へとデプロイされる——。

しかしその数時間後、監視アラートが鳴り響きます。「決済処理で特定のステータス遷移がスキップされた」「DBトランザクションでデッドロックが多発している」「なぜか空文字列のペイロードでスキーマバリデーションエラーが噴出している」。

これが、本番AI駆動開発の現場で最も発見が遅れ、最も壊滅的な被害をもたらす「意味論ドリフト（Semantic Drift / 意味論の漂流）」の罠です。

リファクタリングとは「外部から観測可能な振る舞いを変えずに内部構造を整理すること」である。しかしLLMは本質的に「外部から観測できない振る舞い」を確率的に破壊する。

1. 意味論ドリフト（Semantic Drift）の正体

マーチン・ファウラーが定めたリファクタリングの厳密な定義は、「ソフトウェアの外部から見た振る舞いを保ちつつ、理解しやすく変更が容易になるように内部構造を改善すること」です。

しかし、自己回帰型の大規模言語モデル（LLM）の動作原理は、「事前学習データセット全体における最も確率の高いトークン列の生成」です。ここに致命的なアーキテクチャ上の断絶が存在します。

原型バイアス（Prototypical Bias）によるエッジ防御コードの平滑化

本番で何年も稼働し続けているコードベースには、一見すると奇妙で冗長に見える「泥臭い分岐」や「二重チェック」が無数に存在します。それらの多くは、かつて本番障害を踏んだエンジニアが、外部APIの未ドキュメントの挙動や、特定のDBドライバのバグ、OSの非同期スケジューリングの気まぐれに対処するために血肉を削って追加した「防御壁」です。

しかし、LLMに「綺麗にリファクタリングして」と指示を与えた瞬間、モデルの注意機構（Attention）は「クリーンで典型的なコード（Prototype）」へとバイアスをかけます。

LLMにとって、現場の泥臭い防御策は「学習データの統計的分布から外れた低確率なノイズ」に過ぎません。モデルは悪意なく、それらを「一般的な良いコード」へと平滑化（Smooth out）して消し去ってしまうのです。

2. 現場を地獄に変える「3大破壊パターン」

意味論ドリフトがどれほど狡猾であるか、現場で頻発する具体的なコード例を見てみましょう。

パターンA: 評価順序と短絡評価（Short-circuit）の破壊

TypeScriptによるユーザー認証・トークン検証ロジックのリファクタリング例です。

// 【リファクタリング前】泥臭いが堅牢に動いていたコード
async function verifySession(req: Request): Promise<SessionResult> {
  // ① ヘッダーの存在確認（軽量なメモリ内チェック）
  const token = req.headers.get("x-auth-token");
  if (!token) return { ok: false, reason: "NO_TOKEN" };

  // ② レートリミットの消費（外部RedisへのI/O + カウンター加算という副作用を持つ）
  const rateLimitOk = await consumeRateLimit(req.ip);
  if (!rateLimitOk) return { ok: false, reason: "RATE_LIMITED" };

  // ③ トークンの暗号署名検証（CPUバウンド）
  const payload = await verifyJwtSignature(token);
  return { ok: true, user: payload };
}

このコードをAIエージェントに「非同期処理を整理して可読性を上げて」と依頼すると、次のようなコードを出力することがあります。

// 【AIによるリファクタ後】一見スマートだが「意味論」が破壊されたコード
async function verifySession(req: Request): Promise<SessionResult> {
  const token = req.headers.get("x-auth-token");

  // AIの判断: 「独立した非同期処理だから並列化してレイテンシを削減しました！」
  const [rateLimitOk, payload] = await Promise.all([
    consumeRateLimit(req.ip),
    token ? verifyJwtSignature(token) : Promise.resolve(null),
  ]);

  if (!token) return { ok: false, reason: "NO_TOKEN" };
  if (!rateLimitOk) return { ok: false, reason: "RATE_LIMITED" };
  return { ok: true, user: payload! };
}

何が起きたかお分かりでしょうか？

変更前のコードでは、x-auth-token が存在しない不正なBotリクエストは①で即座に弾かれ、Redisのレートリミットを消費しませんでした。しかしAIがリファクタしたコードでは、トークンを持たないスパムアクセスであっても無条件に consumeRateLimit(req.ip) が実行され、Redisへ不要なWriteトラフィックが集中し、IP全体のクォータが枯渇するという深刻な副作用の逆転が発生しています。

パターンB: FalsyとNullishの平滑化によるデータ汚染

JavaScript/TypeScriptの null、undefined、""（空文字）、0、false の境界線は、言語の歴史的経緯もあって極めて繊細です。

// 【リファクタ前】外部連携の古い仕様に合わせた厳密な処理
function resolveDisplayName(user: UserProfile): string {
  // 過去の経緯: 空文字 "" は「ユーザーが意図的に名前を非表示にした」状態であり、
  // 未設定を表す null / undefined とは区別して処理する必要がある
  if (user.displayName !== undefined && user.displayName !== null) {
    return user.displayName;
  }
  return user.defaultHandle;
}

AIエージェントは「モダンな構文で簡潔に書けます」と、誇らしげに次の提案をしてきます。

// 【AIによるリファクタ後】
function resolveDisplayName(user: UserProfile): string {
  // Nullish coalescing で1行にすっきり整理
  return user.displayName ?? user.defaultHandle;
}

一見、完璧に見えます。しかし、もし別の箇所で user.displayName = "" だった場合、Null合体演算子 ?? は空文字をそのまま返します（これは元のコードと挙動が一致）。しかし、さらに「DRYに」「Falsyを弾いて」とプロンプトが重なると、AIは無邪気に return user.displayName || user.defaultHandle; へとドリフトさせます。この瞬間、空文字がデフォルトハンドルに化け、ユーザーのプライバシー設定が静かに破壊されます。

パターンC: 並行性境界とロック順序の「DRY化」によるデッドロック

Go言語によるデータベース更新トランザクションです。

// 【リファクタ前】行ロックのデッドロックを防ぐため「ID昇順」で愚直に直列更新
func TransferCredits(ctx context.Context, tx *sql.Tx, fromID, toID int64, amount int64) error {
    firstID, secondID := fromID, toID
    if firstID > secondID {
        firstID, secondID = toID, fromID
    }

    // 常にIDの小さい順にSELECT FOR UPDATEをかける（デッドロック防止の鉄則）
    if err := lockAccount(ctx, tx, firstID); err != nil {
        return err
    }
    if err := lockAccount(ctx, tx, secondID); err != nil {
        return err
    }

    return applyBalance(ctx, tx, fromID, toID, amount)
}

このロジックをAIエージェントに渡すと、AIは「重複コードの排除」と「関数の疎結合化」を試みます。

「firstID と secondID の順序入れ替えはトリッキーで直感的ではないため、スライスに対してループで処理するように改善しました」と称してソート順保証を共通ヘルパーに隠蔽した結果、コンテキストの継承漏れや、トランザクション分離レベルの暗黙の前提が崩れ、秒間数百件のトランザクションが衝突した瞬間に本番DBでロックタイムアウトが多発することになります。

3. なぜユニットテストは「意味論ドリフト」を検知できないのか？

「でも、テストコードがしっかり書いてあれば、リファクタリングで壊れたらテストが落ちるはずでは？」

そう考えるエンジニアは多いでしょう。しかし、ここに**アサーションの空隙（Assertion Hole）**という残酷な現実があります。

テストスイートは「開発者が意識して表明（Assert）した動作」しか保証しない。本番の信頼性を支えているのは、テストに書かれていない「暗黙の契約（Implicit Contract）」である。

先ほどのレートリミットの例で言えば、既存のユニットテストは「有効なトークンを渡したら200が返ること」「無効なトークンなら401が返ること」を検証していても、「無効なトークンのときにRedisの INCR コマンドが何回呼ばれたか」までモックで検証していないケースが大多数です。

AIエージェントは、既存のテストコードを読み込みます。そして**「テストのアサーションを通す範囲内において、自由度の最も高い（かつ学習確率の高い）コード」**を生成します。

テストに書かれていない副作用、評価順序、メモリ配置、例外の派生クラス、マイクロタスクの消化タイミング——それら「Assertion Hole」に落ち込んだ挙動の変化を、テストランナーは一切検知できません。結果として、オールグリーンのまま本番が崩壊する「グリーンハルシネーション」が完成するのです。

4. 防壁アーキテクチャ: AIに「自由なコード書き換え」を許すな

では、AI駆動開発においてコードの改善やリファクタリングを諦めるべきなのでしょうか？

結論は**「No」**です。ただし、**「AIエージェントにソースコードの自由編集を単独で任せる」運用は即座に停止しなければなりません。**

本番レベルの安全性を担保するために導入すべき、3つの防壁アーキテクチャを提示します。

防壁1: キャラクタライゼーションテスト（Golden Master）の自動固定

リファクタリングの対象となるモジュールに対して、既存のユニットテストだけに頼ってはいけません。コードを変更する**直前**に、現在の挙動を1ビットの狂いもなく固定する「キャラクタライゼーションテスト（承認テスト）」を機械的に生成します。

「振る舞いが変わっていないこと」を自然言語の約束や大雑把なテストで済ませず、入出力と副作用の不変性として数学的に証明するのです。

防壁2: AST CodemodとLSPによる「手足の拘束」

AIにテキストエディタの全権限（ファイルの直接書き換え）を与えてはいけません。AIに任せるべきは**「リファクタリング方針の計画（Planning）」**であり、実行そのものは**「決定論的な構文木変換ツール（AST Codemod / LSP）」**に委ねるべきです。

【危険な設計】
ユーザー指示 → AIエージェントが自由にコードを全置換 → （意味論が崩壊）

【堅牢な防壁アーキテクチャ】
ユーザー指示
  ↓
[AI Planner] 「関数 handleAuth の L45-L62 を 'validateHeader' として抽出せよ」
  ↓ （JSONによる命令定義）
[Deterministic Tool] Language Server Protocol (LSP) / AST Codemod (jscodeshift等)
  ↓ （数学的に振る舞いが保証された変換）
意味論が保証された安全なリファクタリングコード

「関数の抽出（Extract Function）」「シンボルの改名（Rename Symbol）」「変数のインライン化（Inline Variable）」といった基本操作は、現代の言語サーバー（Language Server）がASTを解析し、スコープや参照関係を壊さない決定論的アルゴリズムとして既に提供しています。AIにはそれらの操作コマンドを選定させ、実行自体は決定論的ツールに制限することで、勝手なコードの平滑化を物理的に遮断します。

防壁3: 敵対的セマンティック差分監査（Diff Semantic Auditor）

リファクタリングを行ったエージェント自身に「変更内容を自己レビュー」させてはいけません。自己回帰モデルは自らが生成したトークンに対して強い確証バイアスを持ち、「問題ありません、動作は同一です」と自信満々に嘘をつきます。

パイプラインには必ず、「この差分はどこかで意味論を破壊しているはずだ」と疑ってかかる敵対的（Adversarial）な別インスタンスの監査エージェントを配置します。

【Diff Semantic Auditor への制約プロンプト例】
あなたはこのPRの差分によって発生した「暗黙の仕様変更」を告発する監査官です。
コードの可読性や美しさには一切興味を持たないでください。
以下の観点のみを厳格に検査し、1つでも該当すればFAILと判定してください：
1. 評価順序（Short-circuit）の逆転がないか？
2. 例外の型やエラーメッセージの文字列が変わっていないか？
3. null / undefined / 空文字のハンドリングが同一か？
4. 非同期処理の並行化により、共有状態やロックの順序が崩れていないか？
5. 呼び出される外部I/O（DB, キャッシュ, API）の回数・タイミングが狂っていないか？

5. まとめ: コードの美しさに騙されるな

「動いているコード」は、往々にして美しくありません。過去のパッチや仕様の歪み、泥臭い例外処理が積み重なり、一見するとリファクタリングの絶好の標的に見えます。

しかし、その泥臭さの中にこそ、数多の本番障害を生き延びてきた「システムの生きた歴史」が刻まれています。

AIエージェントに「リファクタリング」を単独で任せてはいけません。確率統計マシンであるLLMに無防備にコードを委ねることは、システムの魂である「暗黙の仕様」をドブに捨てる行為です。

真のエンジニアリングとは、コードの見た目の綺麗さに自己満足することではなく、「どんな変更があっても、本番環境でユーザーとの約束（仕様）を1ミリも違えずに守り抜くこと」にあります。AIの強力な推論能力を活用するからこそ、その手足を決定論とテストの鎖で縛る冷徹なアーキテクチャ設計を忘れてはならないのです。