🧐

そのコード、本当に大丈夫?〜ChatGPTコピペの落とし穴〜

に公開

はじめに

最近では、ChatGPTのようなAIツールを使って調べ物や実装を行うエンジニアが増えています。疑問をすぐに解決できる便利な存在として、開発効率の向上にも大きく貢献している一方、「とりあえずコピペして動けばOK」といった使い方も見かけるようになりました。

本記事では、ChatGPTの便利さを認めつつも、「なぜ出力されたコードをそのまま使うのは危険なのか」「どうすればより良く活用できるのか」をテーマに、例も交えて紹介していきます。
※言語はJavaScriptを例に考えています。


なぜコピペだけではダメなのか?

AIはとても優秀なサポーターですが、出力されたコードが常に安全・最適とは限りません
以下のようなリスクが潜んでいます。

  • セキュリティ的に脆弱なコード
  • 非推奨な書き方や古いAPIの使用
  • エラーハンドリングの欠如
  • プロジェクトの設計方針と合わない実装

例:ChatGPTに「CORSを回避したい」と聞いてみた結果…

// 絶対に本番で使ってはいけない例
fetch("https://api.example.com/data", {
  method: "GET",
  mode: "no-cors"
})
  .then(response => console.log("Success"))
  .catch(error => console.error(error));

このコードは一見すると「CORSを回避してリクエストを送れる便利な手法」に見えますが、実際には以下のような問題を含んでいます。

❌ 問題点

  1. mode: "no-cors" は“レスポンスの中身を取得できない”

    • ステータスコードもボディも読めず、実際に何が返ってきたのか分からない。
    • 成功/失敗の判定すらまともにできないため、使い道が限られる。
  2. CORSの根本的な問題を解決していない

    • 「CORSを回避したい」という要求自体が、API設計やサーバー設定の見直しを必要としている場合が多い。
    • クライアント側だけで“回避”しようとするのは本質的な解決にならない。
  3. セキュリティ上の誤解を助長する

    • 初学者が「no-cors を使えば大丈夫」と誤解して使い続けてしまう危険性がある。

✅ 本来の対応方法(サーバーと連携する)

  • サーバー側でCORSヘッダ(Access-Control-Allow-Origin など)を正しく設定する
  • 認証・認可フローを含めて、設計全体を見直す

ChatGPTの正しい使い方

ChatGPTは“使い方次第で味方にも敵にもなる”ツールです。
正しく使えば強力なアシスタントですが、判断力を持って使わなければ落とし穴にハマる可能性もあります

✅ 正しい活用のポイント

  • コードの意味を理解してから使う

    • 出力されたコードは、そのまま使うのではなく「なぜこのような書き方になっているのか」を考える癖をつけましょう。
  • 公式ドキュメントや信頼できるソースと照らし合わせる

    • ChatGPTが常に最新情報を提供するとは限りません。バージョン違いや非推奨のAPIなども混ざっていることがあります。
  • 出力されたコードは“参考”と割り切る

    • AIのコードは“正解の候補の1つ”であり、正解そのものではないという意識を持つことが重要です。
  • 実装後はテストやレビューをしっかり行う

    • コードが動くかどうかだけでなく、保守性・可読性・安全性も確認しましょう。

ケーススタディ:ありがちなミスとその対処

📌 ケーススタディ①:見落としがちなセキュリティリスク

ChatGPTに「ログイン処理のコードを教えて」と聞き、そのまま実装。
しかし、パスワードをプレーンテキストのまま送信していたため、セキュリティ上の重大な問題に繋がるところだった。

❌ 問題点

  • HTTPSでの通信前提が明示されていなかった
  • 入力値のバリデーションが一切なかった
  • エラーハンドリングが弱く、失敗時にログすら出ない構成だった

✅ 改善の流れ

  • 上長やチームメンバーにコードレビューを依頼
  • セキュリティガイドラインに沿った実装に修正
  • fetchの送信時にトークンベースの認証方式へ変更
  • try/catchとユーザーフィードバック表示を追加

📌 ケーススタディ②:非効率なアルゴリズムのコピペ

ChatGPTに「配列の重複を削除する方法」を聞いて、出力されたコードをそのまま使った。
小さなデータセットでは問題なかったが、大規模データを扱う処理で著しくパフォーマンスが劣化してしまった。

❌ 問題点

  • 出力されたコードが for ループの中で includes() を使っており、O(n^2) のアルゴリズムだった。
  • 開発者自身が「動くからOK」と判断して、性能面を考慮しなかった。

✅ 改善の流れ

  • プロファイラで処理時間を可視化 → ボトルネックを特定
  • Set を使ったO(n)の実装に差し替え
  • ChatGPTにも「パフォーマンスに配慮して書いて」と追加で聞き、比較検証する癖をつけた

📌 ケーススタディ③:サンプルコードの「罠」

ChatGPTで「フォームのバリデーション方法」を調べた際、常に true を返す関数が含まれたコードをそのまま採用。
本人は「バリデーションが通った」と誤解し、不正な値も登録できる状態になっていた。

❌ 問題点

  • ChatGPTの出力コードにおける validate() 関数が、サンプルのつもりで return true; になっていた
  • 初心者は「このままで完成形」と勘違いし、本番コードに組み込んでしまった

✅ 改善の流れ

  • 「サンプルコードには“意図的な穴”があるかも」という意識を学ぶ
  • 自分なりに console.log() や debugger を入れて検証するようにする(テストを行う)

おわりに

ChatGPTを活用するのは、とても良いことです。
また、ChatGPTのモデルもバージョンが都度上がってきており、例に上げた様な聞き方をしても、
補足/解説や安全な書き方を提案してくれるようになっています。

しかし、「動けばOK」でそのまま使ってしまうのは、技術者としての成長のチャンスを逃し、リスクも増やすことになると思います

AIはあくまで補助輪
本当に自走するためには、自分で調べ、考え、実装し、検証する力が必要だと思います。

ファースト・スクラッチTech Blog

Discussion