🤖

実務10年が見た、ジュニアがAIコーディングで陥る3つの罠

に公開
AI
エンジニア
ChatGPT
codereview
Claude
idea

はじめに

フロントエンド歴10年の筆者です。

最近、AIを使って実装したコードをレビューする機会が増えました。そこで気づいたのは、AIコーディングには「使いこなすための経験値」が必要だということです。

業界では、経験豊富なエンジニアから段階的にAIツールを導入する企業も出てきています。その理由を、現場で見た実例から解説します。

ジュニアがハマる3つの罠

罠1: コメントアウト地獄

// AI生成コード
export const fetchUser = async (id: number) => {
  // 旧実装（念のため残しておきます）
  // const response = await fetch(`/api/users/${id}`)
  // return response.json()

  // 新実装
  try {
    const response = await fetch(`/api/users/${id}`)
    if (!response.ok) throw new Error('Failed')
    return response.json()
  } catch (error) {
    console.error(error)
    throw error
  }

  // 以下、使わなくなった関数たち（念のため）
  // const oldHelper1 = () => { ... }
  // const oldHelper2 = () => { ... }
}

本質的な変更: 3行
diff の総行数: 50行超

なぜこうなるか

  • AIは「既存コードを壊すリスク」を避け、削除よりコメントアウトを選ぶ
  • ジュニアは「AIの出力は正しい」と信じ、そのまま commit
  • git diff を精査する習慣がない

影響

  • レビューコストが激増（本質的な変更が埋もれる）
  • git history の汚染
  • 技術的負債の蓄積

罠2: any型まみれ

// AI生成コード
const handleSubmit = async (formData: any) => {
  const response: any = await api.post('/submit', formData)
  return response.data
}

なぜこうなるか

  • AIは「とりあえず動くコード」を優先
  • 複雑な型定義より、any で逃げるのが最短ルート
  • ジュニアは「動いてるからOK」と判断

影響

const result = await handleSubmit(data)
console.log(result.userName)  // 実際は result.name
// ランタイムエラー: undefined
  • 型安全性の喪失
  • リファクタリング時に壊れる
  • TypeScript を使う意味がない

罠3: セルフレビューの欠如

// AI生成コード（一見良さそう）
const fetchArticles = async (): Promise<Article[]> => {
  try {
    const response = await fetch('/api/articles')
    const data = await response.json()
    return data.articles
  } catch (error) {
    console.error(error)
    return []  // ← エラー時に空配列（危険）
  }
}

// 使用側
if (articles.length === 0) {
  // エラーなのか、本当に0件なのか区別できない
  showMessage('記事がありません')
}

なぜこうなるか

時間がないと：

AI に丸投げ → 動いた！ → 即 commit

セルフレビューのステップが抜け落ちる

影響

  • エッジケースでの挙動が未検証
  • エラーハンドリングが甘い
  • コードが何をしてるか説明できない

なぜこうなるか - 経験値の差

ジュニア ミドル以上
コメントアウト大量 気づかない 「多すぎでは？」
any 型 「動いてる」 「型安全性が...」
エラー処理 「catch あるからOK」 「空配列返すの危険」

10年の経験で培われた**「なんか変だぞ」センサー**が、ミドル以上には備わっています。

ミドル以上のAI活用ワークフロー

筆者が実践しているワークフローです：

1. AI に使用箇所洗い出しを依頼
   ↓
2. markdown に可視化
   ↓
3. AI に実装させる
   ↓
4. AI 自身にレビューさせる（数回）
   ↓
5. 別のAIでセカンドオピニオン
   ↓
6. 目視確認 + 手直し
   ↓
7. git diff 確認
   ↓
8. commit

ポイント1: AI に「レビューさせる」

「この実装をレビューして、改善点を3つ挙げて」
→ AI「1. any型を避けるべき 2. エラー処理が甘い...」
→「じゃあ修正して」
→ AI「修正しました」
→「もう一度レビューして」

AIにもPDCAを回させる

ポイント2: 最終判断は人間

// AI生成
type UpdateInput = Partial<Article> & Pick<Article, 'id'>

// 手直し（可読性優先）
type UpdateInput = Partial<Article> & { id: number }

「AIを信頼しすぎない」姿勢が重要。

3つの罠を避けるために

ジュニアエンジニアへ

  1. commit 前に git diff 確認

    • 不要なコメントアウトを削除
    • 本質的な変更だけが残ってるか確認

  2. any 型は敵

    • AIが any を使ったら「なぜ？」と疑う
    • 適切な型定義を追加

  3. セルフレビュー必須

    • 「このコード、人に説明できる？」
    • エラー処理、エッジケース、型安全性をチェック

チームリーダーへ

【AIガイドライン例】
- commit 前に git diff 確認必須
- any 型は原則禁止
- AI生成コードもセルフレビュー必須

【レビューチェックリスト】
- [ ] 不要なコメントアウトがない
- [ ] any 型が使われていない
- [ ] エラーハンドリングが適切

まとめ

AIコーディングツールは強力ですが、**「使いこなすには経験が必要」**というのが現場の実感です。

業界では、経験豊富なエンジニアから段階的にAIを導入する動きがあります。これは長期的な品質・効率・学習効果を考えた合理的な判断です。

AI時代の差別化ポイント：

  • AI生成コードをレビューする目
  • セルフレビューの習慣
  • 経験で培った「違和感センサー」
  • ベーシックスキルとアーキテクチャの理解

急がば回れ。AIを使いこなすには、基礎力が不可欠ですなあ...
楽をできるようになっているようで実は学習コストが倍増しているという闇に気づかなければアンチパターン量産マシーンになりかねませんね。

早朝から作業してたので二度寝します🫠

この記事は実際の現場経験に基づいていますが、個人・企業が特定できないよう配慮しています。

Discussion