AIへリファクタリングを任せるとき、どこまで直してよいか

「このディレクトリを整理して」と依頼すると、対象ファイルは指定できても、許した変更の種類は曖昧なままです。識別子の名前を変えるのか、配置を変えるのか、処理結果まで変えてよいのか。人なら作業中に確認する境目を、AIは依頼文と手元の文脈から推測します。そこで範囲をファイルの場所だけで表すと、依頼者が想定していない変更も「整理」の一部に見えてしまいます。

2026年9月21日時点で、Googleの公式コードレビュー指針は、適切な変更単位を原則として一つの自己完結した変更、つまり一つの事柄に対する最小限の変更としています。また、クラスの移動・名前変更と、そのクラスの不具合修正を分ける例を示しています（[Google「Small CLs」](https://google.github.io/eng-practices/review/developer/small-cls.html)）。対象は、人がレビューしやすい変更の作り方です。AI製品の機能仕様には当たりません。

この原則をAI利用へ落とし込む実務提案が、変更を「名前変更」「移動」「振る舞い変更」の三つに分ける方法です。名前変更や移動の途中でも、処理条件や返却値を触る差分が混ざれば別単位へ切り出します。境界を引く目的は、人が差分から許可と越境を判定できる状態を作ることです。

依頼文には、許可する分類、対象、してよい操作、触れてはいけない境界を書きます。作業後の説明から範囲を推測する運用では、越境を止めるタイミングを失います。編集前の台帳として固定してください。次の内容は、チームが自社の責任で採用する運用例です。

たとえば、内部サービスのクラス名を責務に合う名前へ変えたいとします。台帳の許可分類は「名前変更」、対象はクラス宣言とその参照、禁止はファイル移動とロジック変更です。完了条件は「新旧の識別子を検索し、旧名が意図せず残っていないこと」「既存の検証が通ること」「差分の各行を名前変更として説明できること」とします。ここにファイル配置の変更が必要だとAIが判断しても、自動的に許可範囲を広げません。理由を記録して止め、移動を別の依頼として切り出すかを人が決めます。

反対に、依存方向を整えるためのファイル移動なら、許可分類は「移動」です。参照先の更新は移動を成立させる付随作業として認めますが、循環依存を解くために条件分岐や初期化の意味を変える必要が出たら、それは振る舞い変更の候補です。「移動を完成させるため」という理由で混ぜず、中断事由として残します。

難しいのは、差分の見た目が小さい変更です。既定値の変更、例外処理の追加、公開される文字列の置換は、行数が少なくても利用者から見える結果を変え得ます。台帳は差分の意味で分類します。三分類のどこへ置くか確信を持てない場合は、振る舞い変更として扱うか、責任者へ戻します。

停止条件には、エラーに加えて差分の越境も含めます。許可していない分類へ踏み込んだとき、影響範囲を人が再評価できる状態で止める条件が必要です。AIには、中断時に追加修正を続けず、判明した事実、該当する差分、未解決の判断を報告するよう依頼します。

中断したかどうかにかかわらず、レビュー担当者は台帳と実際の差分を照合します。2026年9月21日時点のGitHub公式ドキュメントでは、プルリクエストのFiles changedは提案された変更を理解するための差分、Checksは自動テストやビルドなどの検証結果を示し、マージ状態は未承認などの阻害条件を示します（[GitHub「Pull requests」](https://docs.github.com/en/pull-requests/reference/pull-requests)）。したがって、AIの「名前変更だけ完了した」という説明は補助情報であり、変更範囲の根拠にはしません。

レビューの順序は、まずFiles changedの各差分を台帳の一分類へ対応付け、次にChecksの結果と未解消の阻害条件を確認し、最後にマージ可否を決める形にします。分類外の一行を見つけたら、元の変更から外して別のレビュー単位に戻せるかを判断します。AIが広く編集した後に人が意図を復元する状況を、ここで防ぎます。

Googleの同じ指針は、ロジックを追加・変更する変更には新しい振る舞いに対応するテストを伴わせ、純粋なリファクタリングもテストでカバーし、依存する複数変更の各段階でシステムを動作可能に保つとしています。テストの準備そのものを検討するときは、AI駆動開発のワークフローも合わせて整理すると、依頼、実装、検証、レビューの責任を分けやすくなります。

どのコードを人がレビューし、どこへ自動分析を使うかは、組織が定義する事項です。2026年9月21日時点のNIST SSDF 1.1は、コードレビューまたはコード分析の利用を組織が定義し、組織のセキュアコーディング標準に基づいて実施するとしています。発見事項と推奨対応は、開発ワークフローまたは課題管理へ記録し、トリアージする考え方です（[NIST「SSDF Version 1.1」](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf)）。

NIST SSDF 1.1は、適用するプラクティスをリスクに基づいて選び、組織の状況に合わせて調整する出発点としています。三分類と中断条件も、その組織でレビュー対象と判断記録を定義するための実務提案です。公式文書が直接指定した方式、あるいは全チームに共通する唯一の方式としては扱えません。

責任者は、対象リポジトリごとに、誰が中断後の再開を承認するか、公開API・永続化形式・権限境界をどの資料で識別するか、中断事由をプルリクエストと課題管理のどちらへ残すかを決めます。権限や機密情報へ触れる変更では、実行環境と許可も独立した境界です。Claude Codeを安全に使うためのセキュリティ設計で扱う実行権限の考え方と併せ、変更範囲と実行操作を別々に管理してください。

AIへ任せてよいのは、名前変更・移動・振る舞い変更のうち一つを台帳で許可し、実際の差分を同じ分類で説明でき、必要な検証を確認できる範囲です。編集可能な広さより、この判定可能性を優先します。別分類、公開API、永続化形式、権限境界、判定できない振る舞いへ触れたら、その場で人へ戻します。

導入時は、既存の一つの変更依頼を三分類へ書き直し、禁止境界と中断時の記録先を追加します。そしてレビューで、台帳、Files changed、Checks、阻害条件の順に照合します。この一巡を責任者がレビューできなければ、対象を広げる段階ではありません。差分から越境を見つけ、追加修正の前に止められること。それが、自社でAIによるリファクタリングを実行するための具体的な条件です。