はじめに
AI が生成したコードを目にしたとき、
「これ、そのまま使っていいのか？」と一瞬止まる感覚は、多くのエンジニアが一度は経験している。
一見すると正しそうに見える。
テストも通りそうだし、動きも想定どおりに見える。
しかし、どこかで引っかかる──その感覚自体は、決して間違いではない。
本記事では、
AI が生成したコードを“そのまま使っていいか迷ったとき”に、どう考えるべきかを、
実務前提で整理する。
結論から言えば、判断基準は「AIが書いたかどうか」ではない。
どの責務をAIに任せ、どの判断を人が握るかが明確かどうかである。
前提整理：AIコードの扱いで起きやすい誤解
まず整理しておきたいのは、AIコードを巡る典型的な誤解である。
- 「AIが書いたコード＝危険」
- 「人が書いたコード＝安全」
- 「テストが通れば問題ない」
いずれも、実務では成立しない。
人が書いたコードでも、設計が破綻していれば事故は起きる。
AIが書いたコードでも、責務が限定されていれば問題にならない。
問題は 生成主体ではなく、扱い方 にある。
判断の前提となる考え方
AIコードは「成果物」ではなく「作業結果」
AIが出力するコードは、完成品ではない。
位置づけとしては、以下に近い。
- 下書き
- たたき
- 作業途中の案
- 人がレビュー前提で受け取るアウトプット
これを 成果物として扱うか、作業結果として扱うかで、判断は大きく変わる。
そのまま使ってよいケース
AIが生成したコードを、そのまま（ほぼ修正せず）使っても問題になりにくいケースは、実務上いくつかに限られる。
ケース1：責務が局所的で閉じている
- 単一関数
- ユーティリティ
- 明確な入出力を持つ変換処理
- 周辺に副作用を持たないロジック
このようなコードは、
- 何をしているか理解しやすい
- 影響範囲が限定的
- テストで振る舞いを固定しやすい
ため、AI生成コードをそのまま採用してもリスクが低い。
ケース2：仕様が完全に固定されている
- APIレスポンスの整形
- 定型フォーマットへの変換
- 明文化されたルールの実装
仕様が曖昧でなく、
「正解が一意に近い」処理ほど、AIコードは安定しやすい。
この場合、人がやる判断は
「仕様どおりかどうか」だけになる。
ケース3：テストが先に書かれている
テストが先に存在し、
- 入力
- 期待される出力
- 境界条件
が明確な場合、
AIコードは 実装担当者の代替 として扱える。
このとき重要なのは、
テストがAIコードを保証しているのではなくテストが仕様を固定している
という点である。
そのまま使うべきでないケース
一方で、迷った時点で「そのまま使うべきではない」ケースも存在する。
ケース1：設計判断を含んでいる
以下を含むコードは要注意である。
- データモデルの構造
- 責務の切り分け
- 層（Controller / Service / Domain など）の分離
- 非機能要件（性能・セキュリティ）に関わる判断
これらは プロジェクト固有の判断であり、
AIに委ねると、意図しない前提が混ざりやすい。
ケース2：影響範囲が読み切れない
- 複数モジュールを横断
- 既存仕様との暗黙依存がある
- 将来変更を見越す必要がある
この場合、「動くかどうか」では判断できない。
変更耐性と意図の説明可能性が重要になる。
ケース3：理由を説明できない
AIコードを見て、
- なぜこの実装なのか
- なぜこの設計なのか
を説明できない場合、そのまま使うべきではない。
レビューで問われるのは、
「誰が書いたか」ではなく「なぜそうしたか」である。
実務で使える判断基準
迷ったときに使える、実務向けの判断軸を整理する。
判断軸1：このコードは“差し替え可能”か
- すぐ捨てられる
- 将来差し替えても影響が小さい
→ YES なら採用しやすい。
判断軸2：このコードの責任は誰が持つか
- バグが出たとき、誰が直すのか
- 仕様変更時、誰が判断するのか
責任が人に帰るなら、
人が理解できる状態であることが必須になる。
判断軸3：テストがコードより強いか
- テストが仕様を定義しているか
- コードがテストに従っているか
この関係が逆転している場合、
AIコードはリスクになる。
AIコードを安全に使うための実務ルール
実務では、以下のような運用が現実的である。
- AIコードは「下書き扱い」
- 採用する場合でも、最低限のリネーム・整形を行う
- 重要ロジックには必ずテストを書く
- 設計判断が混ざる部分は人が書き直す
特に重要なのは、
AIコードを“レビュー免除”にしないことである。
よくある失敗パターン
失敗1：動いたからOKにする
- 初期は速い
- 後で仕様変更に耐えられない
- 誰も触れなくなる
典型的な技術的負債の入口である。
失敗2：怖くて一切使わない
- 作業量が減らない
- AI導入の意味がなくなる
AIコードは、
判断を放棄しない範囲で使うのが前提である。
まとめ
AIが生成したコードをそのまま使ってよいかどうかは、
技術力や勇気の問題ではない。
- 責務が限定されているか
- 判断が人に残っているか
- 捨てられる前提で扱われているか
この3点が揃っていれば、
AIコードは「危険な近道」ではなく、実務を前に進める手段になる。
迷ったときは、
「このコードを半年後の自分が直せるか」という問いに立ち返るとよい。
