エンジニアがAIコーディングで失敗しない方法
AIコーディングで失敗するエンジニアの多くは、「AIが書いたコードが動いたから、もう大丈夫」と考えています。けれど、目の前で動くことと、いつでも正しく動くことは別の話です。AIは、こちらのシステムの事情や、まれにしか起きない条件までは知りません。AIのコードは「自分が説明できるか」を基準に読み、テストで確かめ、社内のコードや設定情報の扱いを守ったうえで使う。この3つを押さえれば、AIは開発のスピードと質の両方を支える心強い相棒になります。
「動いたからOK」のコードが、月末に止まった
エンジニアとして転職して2年目。まなぶは、社内の勤怠システムなどを保守するチームで働いていました。配属された当初は、何年も前に書かれた古いコードに戸惑うばかりでしたが、最近はAIのコーディング支援ツールを使うようになり、作業のスピードが一気に上がっていました。
ある日、まなぶは勤怠システムの不具合を直す仕事を任されました。残業時間の集計が、一部の社員だけずれてしまうというものです。まなぶは関係しそうなコードをAIに貼り付け、「この不具合を直して」と頼みました。数秒で修正案のコードが返ってきます。自分のパソコンで試しに動かしてみると、問題の社員の残業時間は正しく表示されました。
「動いた!」。まなぶは、返ってきたコードの中身をよく読まないまま、そのまま修正として反映しました。チームのレビューも、忙しい時期だったため、動作の確認だけで通っていきました。
異変が起きたのは、その月の最終日の夜でした。月末の締め処理が途中で止まり、全社員の残業時間が集計できなくなったのです。総務からの連絡を受け、まなぶは先輩と一緒に、夜のオフィスでエラーの原因を調べ始めました。
原因は、まなぶが反映したコードでした。月末の日付をまたぐ場合の計算が考慮されておらず、さらに、AIが使っていた日付の処理の書き方は、このシステムで使っている古いバージョンの仕組みには対応していませんでした。普段の日には動いても、月末という特定の条件でだけ止まるコードだったのです。
先輩はモニターを見ながら、静かに尋ねました。「この処理、なぜこう書いたの?」まなぶは答えられませんでした。自分で理解して書いたコードではなかったからです。さらに先輩は、まなぶがAIに貼り付けていたコードの中に、データベースへの接続情報が含まれていたことにも気づきました。
夜遅く、二人がかりでなんとか修正を終えたあと、まなぶは自分に問いかけました。速く書けるようになったのに、自分が書いたことになっているコードを、自分で説明できなかった。その事実が、何より重く感じられました。
AIコーディングで失敗する原因
理解しないまま、AIのコードを貼り付けた
AIは、もっともらしく動くコードを短い時間で書いてくれます。ただし、そのコードがどんな前提で、どんな処理をしているのかを理解しないまま使うと、問題が起きたときに原因を見つけることも、直すこともできません。「このコードを自分で一行ずつ説明できるか」を、使ってよいかどうかの基準にすることが大切です。説明できない部分があれば、AIに解説を求めたり、公式のドキュメントで確かめたりしてから使いましょう。
目の前で動いたことだけを確認し、テストをしていなかった
自分のパソコンで一度動いたことは、そのコードが正しいことの証明にはなりません。月末や年末、うるう年、空のデータ、想定外の入力など、まれにしか起きない条件でこそ、不具合は表に出てきます。AIにテストコードの下書きを作ってもらい、「どんな条件で試すべきか」を一緒に洗い出すのも効果的です。動作の確認だけでなく、境界になる条件をテストで確かめる習慣が、障害を防ぐ一番の守りになります。
既存システムの前提を、AIに伝えず確かめもしなかった
社内のシステムには、使っている言語やライブラリのバージョン、チームで決めている書き方など、それぞれの事情があります。AIは何も伝えなければ、一般的で新しい書き方でコードを提案してきます。それが古いシステムでは使えない書き方だったことが、今回の障害の原因の一つでした。AIに頼むときは前提を伝え、返ってきたコードがその前提に合っているかを確かめることが欠かせません。
社内のコードや設定情報の扱いを確認していなかった
不具合を直すためとはいえ、社内のコードや、接続情報のような設定値をそのままAIに貼り付けることには注意が必要です。どのAIツールに、どこまでの情報を入力してよいかは、会社のルールによって決まっています。特にパスワードや接続情報などの秘密の情報は、貼り付ける前に必ず取り除くべきものです。便利さを優先して確認を省くと、障害とは別の大きな問題を抱えることになりかねません。
レビューで説明できないコードを、そのまま通してしまった
コードレビューは、ほかの人の目でコードの問題を見つけるための大切な仕組みです。しかし、書いた本人が中身を説明できなければ、レビューする側も意図をくみ取れず、確認は表面的になってしまいます。AIが書いた部分も含めて、自分のコードとして責任を持って説明することが、チームでの開発の前提です。AIを使ったことは隠さず、どこをAIに任せ、どこを自分で確かめたのかを伝えると、レビューの質も上がります。
失敗するAIコーディングと、うまくいくAIコーディングの違い
2つのパターンの違いは、AIを使うかどうかではありません。AIのコードを「完成品」として受け取るか、「自分が確かめる下書き」として受け取るかの違いです。
AIを上手に使っているエンジニアは、AIに書いてもらうことで生まれた時間を、コードを読み、テストを書き、前提を確かめることに使っています。だからこそ、AIを使わなかったときより速く、しかも質の高いコードを書けるのです。AIは、エンジニアの考える時間を奪う存在ではなく、考える時間をつくってくれる存在だと捉えることが大切です。
AIコーディングで失敗しないためのチェックリスト
- AIに頼む前に、言語・ライブラリのバージョン・社内の書き方などの前提を伝える
- パスワードや接続情報などの秘密の情報は、貼り付ける前に必ず取り除く
- 会社のルールで、どのAIツールにどこまでのコードを入力してよいかを確認する
- 返ってきたコードは一行ずつ読み、説明できない部分は調べてから使う
- 月末・空のデータ・想定外の入力など、境界の条件をテストで確かめる
- レビューでは、AIに任せた部分と自分で確かめた部分を伝える
まずは「説明できないコードは反映しない」というルールを自分の中に一つ決めてみてください。AIのコードを読む時間は増えますが、そのぶん障害の原因を探す時間や、手戻りの時間は大きく減ります。何より、自分のコードとして自信を持って説明できるようになります。
また、AIはコードを書くだけでなく、「このコードの問題点を指摘して」「どんなテストをすべき?」と、レビュー役としても使えます。書く道具としてだけでなく、確かめる道具としてAIを使うことで、開発の質はさらに高まっていきます。
AIと一緒に開発する力を身につけたい人へ
資格と仕事に強い!個人レッスンのプログラミングスクール【Winスクール】
プログラミングの基礎から、業務での活用シーンまで体系的に学べるタイプ。AIが書いたコードを読み解き、正しく確かめるための土台となる力を身につけたい人に向いています。
開発外注・エンジニア相談サービス【MENTA】
開発で行き詰まった部分について、経験のあるエンジニアに相談できるタイプです。AIのコードが正しいか不安なときや、古いシステムならではの事情に悩んだときに、第三者の視点を取り入れられます。テストの考え方やレビューの進め方についても相談できます。
まなぶ
みらいAIコーディングは、エンジニアの仕事のスピードを大きく変えてくれる技術です。ただし、目の前で動いたことだけを確かめて反映すると、特定の条件で起きる不具合や、秘密の情報の扱いといった問題を見落としてしまいます。前提を伝え、秘密の情報を取り除き、コードを説明できるまで読み、テストで確かめ、レビューで意図を共有する。その積み重ねが、AIを使って速く、しかも安心できる開発を実現します。
まなぶがエンジニアとして転職したときの失敗については、IT・エンジニア転職で失敗する人の特徴5選で紹介しています。
AIを使い始めたばかりの頃に陥りがちな失敗については、ChatGPTを使って失敗する人の特徴でもまとめています。あわせて読んでみてください。
