はじめに

「AIが出してくれたコード、だいたい動くしレビューも通していいよね?」

最近このような空気感が現場に生まれつつあります。
Copilot、CodeWhisperer、Cursor などのAIコード補完ツールの進化により、人がコードを書く前に“答え”が出る時代になったのは間違いありません。

しかし、レビューアーはこの流れに対して冷静な目線を持つ必要があります。
コードが「正しそうに見える」ことと、「設計意図に沿っている」ことは全く別だからです。

コード補完AIが得意なこと・不得意なこと

AIによるコード補完は、膨大な学習データと直近の文脈(プロンプト)を元に、パターンに基づいた出力を行います。

得意なこと

  • 型定義や引数をもとにした構文的補完
  • よくある処理パターンの提示(例:フィルタ → ソート → map)
  • 一般的なユースケースに沿った関数構造の提案

苦手なこと

  • 業務ドメイン特有の設計意図やユースケースの解釈
  • 既存モジュール間の暗黙的制約の尊重
  • “なぜこの設計にしたのか”という背景の再現

レビューアーとして見るべき観点は、まさにこの「意図の再現性」です。

ケーススタディ:Copilotの提案が“正しそう”に見える例

提案されたコード例

商品価格に対する税込み金額を計算する処理
function calculateTax(price: number): number {
  return price * 1.1;
}

これは一見、非常にそれっぽいコードです。ですが、実際の業務要件はこうです:

  • 税率は商品カテゴリによって変動(標準10%、軽減8%)
  • 社内ルールでTaxCalculatorユーティリティクラスにロジックを集約
  • 計算誤差対策としてBigNumberライブラリを使用

AIの提案は「平均的な解」としては正しく見えますが、設計方針・業務要件には全く沿っていません

レビュー指摘
@Reviewer: 税率が固定化されており、カテゴリ別の扱いが考慮されていません。また、共通ユーティリティ `TaxCalculator` の利用ルールが遵守されていないため、設計上の意図と乖離があります。

AIによるコード補完をそのまま受け入れると、設計上の「暗黙の決まり」を見落とした実装が増えていきます。

「設計意図」とは何か?

設計意図とは単なる仕様のことではありません。

  • なぜこの関数が必要なのか?
  • どうしてこのモジュールに責務を持たせたのか?
  • 今後の拡張性・保守性をどう考慮したのか?

といった、設計者の判断基準と背景にあるロジックの集合を指します。

設計意図とは

設計意図とは、仕様の実装方針・構造選定・責務分離などの判断に至った背景的な理由や方針を含めた「設計者の思考過程」を指す。
ドキュメント化されていない場合も多く、レビュー時に読み取る必要がある。

AI補完コードのレビュー観点

1. 社内設計ルールに従っているか

たとえば以下のような規則がある場合、AI補完はまず従いません。

  • 「データアクセスはすべてRepository経由にする」
  • 「ReactのuseEffect内で非同期関数を定義しない」

AIが提案するコードがルール違反になっていないかをレビューアーが確認する必要があります。

2. 拡張性・保守性の観点があるか

AIの補完は基本的に「今すぐ動くコード」を出力します。
将来的な変更やモジュール化の観点が抜けているケースが多いため、レビューアーは以下を意識してチェックします。

  • constで直接処理を書いていないか?
  • テスト可能性が担保されているか?
  • 意図的な分離が見られるか?
テスト困難な例
const doLogin = async () => {
  const res = await axios.post("/login", { id, pass });
  if (res.status === 200) {
    localStorage.setItem("token", res.data.token);
  }
};
保守性の観点からの指摘
@Reviewer: HTTP処理とストレージ操作が密結合しています。`LoginService`などに分離し、テストしやすい構造に変更することを検討してください。

3. 誤った前提や仮定が含まれていないか

AIは「文脈から最適解らしきもの」を出すため、文脈そのものが不完全な場合、誤ったコードを出力するリスクがあります

  • 誤ったデータ構造の想定
  • 存在しない関数名
  • 暗黙的なユースケースの混同

これらに対しても、レビューアーが業務知識と照らして整合性を確認する役割を果たす必要があります。

AI補完の活用方法:レビューアーが“指摘しやすい構造”を選ばせる

実は、AI補完を「レビューしやすくする」方向で活用することも可能です。

ポイント:

  • 設計方針を事前にコメントで与える
  • ファイル名・関数名に意図を込める
  • 短い関数に分割し、文脈を限定させる
意図をコメントで明示した例
// 商品カテゴリに応じて税率を計算する
function calcTax(price: number, category: string): number {
  if (category === "food") return price * 1.08;
  return price * 1.1;
}

AIは「周囲のテキストを強く参照して補完する」ため、レビュー観点での情報整理にも使えます。

設計意図の共有構造

UML Diagram

まとめ:AIは“コードを出す”が“意図を読む”わけではない

AIの補完は「よくある構造」を出すだけであって、文脈の解釈力には限界があります
レビューアーは、以下の観点を意識して評価することが求められます。

  • AIが出したコードが社内設計方針に沿っているか
  • 保守・拡張・再利用性を持った構造か
  • 実装が設計意図に合致しているかどうかを、必要に応じて作者に確認する

設計意図の読み取りは、AIに任せられるものではありません。
それを読む目を持つのが、レビューアーの役割です。