そのコード、本当に大丈夫?〜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を回避してリクエストを送れる便利な手法」に見えますが、実際には以下のような問題を含んでいます。
❌ 問題点
-
mode: "no-cors"
は“レスポンスの中身を取得できない”- ステータスコードもボディも読めず、実際に何が返ってきたのか分からない。
- 成功/失敗の判定すらまともにできないため、使い道が限られる。
-
CORSの根本的な問題を解決していない
- 「CORSを回避したい」という要求自体が、API設計やサーバー設定の見直しを必要としている場合が多い。
- クライアント側だけで“回避”しようとするのは本質的な解決にならない。
-
セキュリティ上の誤解を助長する
- 初学者が「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はあくまで補助輪。
本当に自走するためには、自分で調べ、考え、実装し、検証する力が必要だと思います。
Discussion