AIが生成したコードの危険なサイン5選

2026年6月17日

― AIを使うな、ではなく「AIをレビューできる人」になろう ―

生成AIを使ってコードを書くことは、もはや珍しくありません。ChatGPT、Claude、Gemini、Cursor など、多くのツールがエラー解決・コード生成・リファクタリング・設計相談を助けてくれます。これは悪いことではなく、現代の開発では AIを活用する能力 はむしろ重要なスキルです。

ChatGPT
Claude
Gemini
Cursor

これらを使って、エラー解決・コード生成・リファクタリング・設計相談をしている人も多いでしょう。

ただし、ここに大きな落とし穴があります。

AIが書いたコード＝正しいコード、ではありません。

AIは「それっぽいコード」を書くのが非常に得意です。コンパイルが通り、なんとなく動き、コメントも丁寧。なのに 設計的には危険 というコードを平気で出します。だから重要なのは、AIに書かせる力ではなく AIのコードをレビューする力 です。

今回は、AIが生成したコードに潜む危険なサインを5つ紹介します。

1. 危険サイン1：メソッドが長すぎる
- 1.1. チェックポイント
2. 危険サイン2：変数名が雑
- 2.1. チェックポイント
3. 危険サイン3：Null対策が雑
- 3.1. チェックポイント
4. 危険サイン4：同じ処理のコピペが多い
- 4.1. チェックポイント
5. 危険サイン5：コメントが多すぎる
- 5.1. チェックポイント
6. AI時代に必要な視点
7. まとめ

危険サイン1：メソッドが長すぎる

例えばこんなコード。

public void Attack()
{
    // 攻撃処理
    // アニメーション
    // SE再生
    // UI更新
    // ダメージ計算
    // 死亡判定
    // アイテムドロップ
    // 実績解除
}

一見、動きそうです。でもこの Attack() は攻撃・演出・UI・戦闘判定・報酬処理をすべて担っています。つまり 責務を持ちすぎ です。AIはしばしば「全部入りメソッド」を作ります。局所的に正解を作るのが得意な反面、グローバルな設計の一貫性よりも目の前のリクエストに答えることを優先するためです。

チェックポイント

メソッドを見て自問してください。「このメソッド、何個の仕事をしている？」 2個以上なら分割を検討しましょう。攻撃判定・演出・報酬のように役割ごとに分けることで、テストも保守もしやすくなります。

危険サイン2：変数名が雑

AIコードで意外と多いパターンです。

var data = GetData();
var result = Process(data);
var temp = result;

data、result、temp — これらは何でしょうか？わかりません。良いコードであれば名前だけで意味が伝わるべきです。

var playerStatus = GetPlayerStatus();
var calculatedDamage = CalculateDamage(playerStatus);
var remainingHp = calculatedDamage;

AIは文脈が薄いと雑な命名をしがちです。プロジェクト全体の文脈を把握していないためです。

チェックポイント

変数名だけを見て意味が伝わるか確認してください。data・result・temp のような汎用名が出てきたら、具体的な名前に置き換えましょう。命名はコードの読みやすさに直結します。

危険サイン3：Null対策が雑

AIはNullReference対策として、よくこう書きます。

if (obj != null)
{
    obj.DoSomething();
}

一見正しく見えます。でも考えてください。なぜ obj が null なのか？ そこを調べないと本質的には未解決です。特に Unity では、Inspector 未設定・GameObject.Find() 失敗・シーン遷移での破棄・Singleton 初期化失敗などが原因になります。AIは「落ちないコード」は書けても、null になった理由まで把握していないことがほとんどです。null チェックは「エラーを黙らせる」だけで、根本解決ではありません。

チェックポイント

null 回避コードを見たら、「そもそもなぜ null になるのか？」 を必ず調べましょう。Inspector のアサイン漏れ、Find の名前ミス、初期化順序のバグなど、原因を特定して正しく修正することが大切です。

危険サイン4：同じ処理のコピペが多い

例えばこういうコードです。

if (weapon == "Sword") { damage = 10; }
if (weapon == "Axe")   { damage = 15; }
if (weapon == "Bow")   { damage = 8;  }

AIはこの手のコードをよく増殖させます。1回の要求には正しく答えても、次の要求に追加で答え続けた結果、構造が崩れていきます。人間なら途中で Dictionary・enum・クラス化を考えますが、AIは明示的に要求されないとそこまで踏み込みません。

var weaponDamage = new Dictionary<string, int>
{
    { "Sword", 10 },
    { "Axe",   15 },
    { "Bow",    8 },
};
damage = weaponDamage[weapon];

なお、Dictionary を使う場合は存在しないキーを参照すると例外が発生します。TryGetValue を使うか、キーの存在チェックを忘れずに。

チェックポイント

同じ形のコードが3回以上出てきたら、「データ化できないか？」 を考えましょう。Dictionary・enum・ScriptableObject など、Unityらしいデータ管理の方法に置き換えることで保守性が大きく向上します。

危険サイン5：コメントが多すぎる

意外かもしれませんが、コメント過剰は危険なサインです。AIはこういうコードを書きがちです。

// プレイヤーのHPを減らす
playerHp -= damage;
// HPが0以下か確認する
if (playerHp <= 0)
{
    Die();
}

コメントがなくても読めます。良いコードはコメントで説明しなくても読めるのです。悪いコードほど、コメントで補おうとします。必要なのは Why（なぜそう書いたか）を書くコメント です。

// 悪い例：コードを日本語で言い換えただけ
count++;
// 良い例：なぜそう書いたかを説明している
// サーバ同期遅延を吸収するため1フレーム猶予を持たせる
count++;

チェックポイント

コメントを読んで「コードを見れば分かること」しか書いていないなら、それは不要なコメントです。「なぜこう書いたのか」「この値はどこから来るのか」「ここだけ例外的な理由」 など、コードから読み取れない情報こそコメントに書きましょう。

AI時代に必要な視点

生成AIは今後さらに賢くなります。でも、おそらく最後まで人間に残る仕事があります。それが 設計判断・トレードオフ判断・責務分離・保守性評価 です。つまり、書く能力よりレビュー能力の価値が上がるということです。AIの出力を見て「本当にこれでいい？」「もっと良い設計は？」「将来困らない？」と問いかけられる人は、AI時代でも強いです。