AI アシスタントでコーディングする際に開発者が犯す間違いとは？

Copilot、Claude、Cursor の組み込みモデルといった AI アシスタントはコード作成のスピードを大きく変えました。それでもコードの検証の慎重さが必要という状況は変わっていません。AI 支援コーディングから私が見てきた大部分の問題は、モデル自体ではなく、繰り返される習慣から生じています。

提案を読まずに受け入れる

最も大きな問題は、タブキーで補完を確定させることです。コンパイルできそうに見えるからという理由で。もっともらしいことは正しいわけではありません。提案された SQL クエリが WHERE 句を静かに落としていたのを見たことがありますが、変数名が一致していたので承認されていました。アシスタントから受け取った行を同僚のプルリクエストを読むのと同じスピードで読んでいないなら、理解していないコードをデプロイすることになります。すべての提案を、高速だけどコードベースの慣例を知らないジュニア開発者からの初稿だと考えてください。

セキュリティに関連するコードを信用する

AI アシスタントは膨大な量の公開コードで学習されており、そのコードの多くにはセキュリティ問題が組み込まれています。簡単なファイルアップロードハンドラをリクエストすると、拡張子チェックがなく、サイズ制限がなく、os.path.join や安全なライブラリ呼び出しではなく文字列連結で構築されたパスを返してくることがよくあります。認証も同じです。アシスタントは JWT を localStorage に保存することや、== の代わりに定時間比較を使わずにシークレットを比較することを提案するのが好きです。これらはいずれも悪意はなく、単に学習データで統計的に一般的なだけです。認証、ファイル I/O、逆直列化、SQL に触れるものに関しては、ロジックを自分で書くか、AI の出力を他の新しいコードに対して質問する脅威モデリングと同じ質問を通してください。敵対的な入力でどうなるか、この呼び出しが失敗したらどうなるか、他に誰がこのエンドポイントに到達できるか。

依存関係と API を発明させる

モデルはパッケージ名と関数シグネチャを完全な自信で幻想することがあります。これは「slopsquatting」問題です。攻撃者はモデルが頻繁に提案する偽のパッケージ名を登録するため、検証されていない pip install または npm install は実はロギングライブラリではないものをダウンロードする可能性があります。アシスタントが推奨する依存関係を追加する前に、PyPI または npm に実際に存在するかチェックし、ダウンロード数と最終公開日を確認し、十分に小さければソースをざっと目を通します。同じ注意は API 呼び出しに適用されます。アシスタントが認識していないメソッドを参照している場合、それが実際に存在すると仮定する前に実際のドキュメントをチェックします。

自分のコードのメンタルモデルを失う

コードを自分で書くとき、各部分が存在する理由のメンタルマップを構築します。セッション全体で大きなブロックの AI 生成コードを受け入れると、そのマップはすぐに薄くなります。それから 3 週間後にバグが現れ、自分で書いたことがなく完全には覚えていないコードをデバッグすることになります。解決策は AI 生成コードを避けることではなく、それをマージする前に各チャンクを自分やチームメイトに説明するのに十分な時間をかけることです。関数が何をするのか、なぜそのようにするのかを説明できないなら、まだマージしないでください。

コードが動いているからテストをスキップする