AIが書いたコードの良し悪しを判断するには、「コードの目利き力」が必要です。この記事では、目利き力の正体をレイヤー構造で整理して、AIを「感覚の通訳」として使う具体的な練習方法を紹介します。バイブコーディングに慣れてきて「このままで大丈夫か？」と感じ始めた方に、特に参考になると思います。
「なんとなくヤバい気がする」その感覚、実は正しい
AIを使って開発していると、こんな瞬間ありませんか？
- AIが出したコードをそのまま使ったけど、なんかこれ大丈夫かな…
- レビューに出したら「まぁいいんじゃないですか」と返ってきて、結局そのままリリースした
- ヤバそうな感じはするんだけど、なぜヤバいのか説明できない
実はその「なんとなくヤバい感覚」は、すでに目利き力の芽なんですよね。
問題は感覚がないことじゃなくて、その感覚を言語化する機会がないことです。
現場でも「まぁいいんじゃないですか」という空気で進んでしまうことは多くて、感覚が育っていても言語に変換されないまま終わる、という環境の問題だったりします。
目利き力の正体：4つのレイヤーで整理する
「コードの良し悪しを判断する」といっても一口には言えなくて、実はレイヤー構造になっています。
Layer 4: 将来変更できるか（保守性）
Layer 3: セキュリティ的に問題ないか
Layer 2: 壊れたとき気づけるか（エラー・ログ）
Layer 1: 動いているか・意図した処理か個人開発や学習用途のバイブコーディングなら、Layer 1の確認が最低ラインです。「動いてるし、意図した処理をしてるよね」というレベル。
でも会社の業務として、誰かが使うサービスに関わるなら、Layer 2以上を意識できると安心感が変わります。「これが壊れたとき、どこを見ればわかるか」という問いです。
全部を一度に意識する必要はなくて、まずレイヤーがあることを知っているだけで「今はLayer 1しか見てないな」と気づけるようになります。
経験のパラドックス：ジュニア・初心者はどうする？
「経験がないと判断できない、でも経験するには判断できないといけない」
これ、学習中に詰まる壁のひとつかなと思います。
でも解決策はシンプルで、自分が失敗しなくても、他人の失敗パターンを先に知識として仕入れることです。
OWASP Top 10（Webアプリのよくある脆弱性トップ10）というものがあります。世界中のエンジニアが過去に踏んだ失敗を集めた集合知みたいなもので、これを読むだけで「ここを見ておけば最低限OK」という外付けの判断基準ができます。
「調べても出てこない」と感じるのは、検索ワードがわからないからかなと思っていて。「コード 安全 判断」では出てこなくても、「コードレビュー チェックリスト」や「OWASP Top 10 WordPress」なら出てきます。知識の入口を知っているかどうかの差だったりします。
AIを「感覚の通訳」として使う方法
ここが一番実践的な話です。次の4ステップを試してみてください。
① 「なんか気になる」と感じたコードをAIに貼る
② こう聞く
このコードに何か問題があると思いますか？
ある場合は、理由も含めて説明してください。③ AIの説明を読んで「あ、だからヤバいと思ったのか」と後付けで言語化する
④ その説明を自分の言葉で1行だけ書き直す
この④が大事です。AIの説明をそのまま受け取るだけだと次に活かせなくて、自分の言葉に変換することで初めて「自分の判断基準」になります。
これを繰り返すことで、感覚が少しずつ言語に変わっていきます。経験者との差は能力じゃなくて、この変換を何回やったかだと思っています。
具体例：SQLインジェクションのBefore/After
実際のコードで見てみましょう。WordPressでよくあるパターンです。
Before（危ないコード）
$id = $_GET['id'];
$result = $wpdb->query("SELECT * FROM posts WHERE id = $id");一見動いているように見えます。でも、ユーザーが ?id=1 OR 1=1 のような値を渡すと、全データが取得できてしまいます。これがSQLインジェクションです。
「なんか気になる」と感じるとしたら、ユーザーの入力をそのままSQLに渡しているところです。
After（安全なコード）
$id = absint($_GET['id']);
$result = $wpdb->get_results(
$wpdb->prepare("SELECT * FROM posts WHERE id = %d", $id)
);変わったのは2点です。
absint()で整数以外の値を強制的に無効化するprepare()でSQLと入力値を分離し、悪意ある値が混入できない構造にする
AIにBeforeのコードを貼って「問題ありますか？」と聞けば、SQLインジェクションのリスクを指摘してくれます。そこで初めて「ユーザー入力をそのまま渡すのが問題だったのか」と言語化できる、という流れです。
デバッグも目利き力を育てる
目利きと関係ないように見えてデバッグも実は直結しています。
- コードを書く = 前向き（仕様 → 実装）
- デバッグ = 後ろ向き（エラー → 原因）
- 目利き = 後ろ向きの思考を前に持ってくること（「これ後で壊れそう」という先読み）
デバッグを繰り返すと、自然と「ここが壊れやすい」という勘所が育ちます。
ただし、console.log をとにかく全部に仕込むやり方ではあまり伸びない気がします。伸びるのは、仮説を立ててから確認するプロセスです。
- エラーを見る
- 「たぶんここが原因」と仮説を立てる
- その一点だけ確認する
- 外れたら仮説を修正する
AIにエラーを貼るときも、「直して」ではなく「原因を教えて」と聞くと、この仮説→確認の練習になります。
まとめ
目利き力を鍛えるのに、最初から豊富な経験は必要ありません。
- 「なんとなくヤバい」感覚は目利き力の芽。問題は言語化されていないだけ
- 目利きはレイヤー構造になっていて、全部を一度に意識しなくていい
- AIを通訳として使い、感覚を言語に変換する練習を積み重ねる
- 他人の失敗パターン（OWASP等）を先に知ることで、経験がなくても判断基準が持てる
AIが書いたコードを「なんとなく」使い続けるより、1つ1つ「なぜこう書くのか」を確認しながら使う習慣が、目利き力を育てる一番の近道かなと思います。
コメント