AIにコードを書かせるときの注意点は？そのまま使わないための確認ポイントを解説

AI にコードを書かせること自体は、もう珍しくありません。
実際、ちょっとした関数、テスト、ドキュメント、リファクタのたたき台を作る速さではかなり便利です。

ただ、問題は 書けること と 安心してそのまま使えること は別だという点です。
AI は見た目が整ったコードを返しやすい一方で、仕様を誤解していたり、既存コードの流儀を無視していたり、危ない依存やセキュリティ上の穴を持ち込んだりすることがあります。

このページでは、2026年4月4日時点で OpenAI の Codex 活用ガイドとコード生成ガイド、GitHub Copilot の responsible use、NIST SSDF / SP 800-218A、OWASP の LLM Prompt Injection Prevention Cheat Sheet を確認しながら、AI に書かせてもそのまま使わないための確認ポイント を整理します。
言語やフレームワーク選びから見直したい場合は、代表的なプログラミング言語8選｜向いている用途・特徴・選び方をわかりやすく解説 や 代表的なフレームワーク7選｜向いている用途・特徴・選び方をわかりやすく解説 もつながりやすいです。
個人の使い方だけでなく、社内で生成AIを使うときの入力ルールや運用設計まで整理したい場合は、生成AIを社内で使うときのセキュリティ対策は？入力ルールと運用設計を解説 もあわせて読むとつながりやすいです。
外部ツールや社内データを生成AIとどうつなぐかという視点まで広げたい場合は、MCPとは？仕組み・できること・便利な理由を初心者向けにわかりやすく解説 も続けて読むと整理しやすいです。

まず前提として何が危ないのか

AI にコードを書かせるときの危なさは、単純に 間違ったコードを書く だけではありません。
実務でよくつらいのは、次のようなケースです。

• 仕様にない処理まで足してくる
• 既存の命名や設計方針に合っていない
• 例外処理や入力チェックが浅い
• 依存ライブラリを軽い気持ちで増やす
• テストを書いたように見えて、実は薄い
• 危ないコードを自信ありげに返す

つまり、AI の出力は 完成品 ではなく たたき台 と見る方がかなり安全です。

そのまま使わないために最初に決めたいこと

最初に大事なのは、AI へ投げる単位を小さくすることです。
OpenAI の Codex 活用ガイドでも、比較的短時間で終わる、よく切り出されたタスクの方が扱いやすいと案内されています。

実務では、次のような依頼の切り方がかなり相性がよいです。

• 1関数だけ実装する
• 既存コードの一部だけリファクタする
• テストケースだけ追加する
• バグ原因の候補を絞る
• API のバリデーションだけ直す

逆に、

• システム全体をよしなに改善して
• セキュリティも含めて全部いい感じにして
• 保守しやすいように全部直して

のような雑に広い依頼は、出力が広がりすぎやすいです。

まず見るべきは「仕様を外していないか」

見た目がきれいでも、仕様を外していたら意味がありません。
最初に確認したいのはここです。

1. 入力と出力は合っているか
2. 成功時だけでなく失敗時の挙動も合っているか
3. 既存の仕様や業務ルールを勝手に変えていないか
4. 例外系や境界値を落としていないか

AI のコードは、いかにもそれっぽい 一般解 に寄りやすいです。
でも実務では、この画面では null を通してよい、このAPIはこの順でロールバックする のような事情がかなりあります。

だから、まずは 正しそうか より 要件どおりか を先に見る方が安全です。

差分は広さより「余計なことをしていないか」で見る

コードレビューで一番見たいのは、追加行数より 変更の広がり方 です。

たとえば危ない差分はこのあたりです。

• 依頼していないファイルまで大量に触る
• 命名や整形だけでなく挙動まで変わっている
• 既存の共通処理をバイパスする
• 便利そうなヘルパーを勝手に増やす
• 例外を握りつぶす

一方で、良い差分は 目的に対して変更範囲が狭い ことが多いです。

差分を見るときのチェック

テストは「あるか」より「何を守れているか」で見る

AI はテストも書けますが、テストがあるだけでは安心できません。
見たいのは、どこを守れているかです。

よくある弱いテストはこのあたりです。

• 正常系しか見ていない
• モックだけで成立していて実挙動が薄い
• アサーションが少なく、実質何も守っていない
• 失敗しないだけで、仕様確認になっていない

そのため、少なくとも次は確認したいです。

• 境界値
• 異常系
• 権限違い
• null / empty / missing
• 既存バグの再発防止

NIST SSDF の考え方でも、レビューやテストは あること より、リスクの高い変更をちゃんと検証しているかが大事です。
AI が書いたコードでも、そこは同じです。

ローカルで確認するだけでなく、Push や Pull Request のたびに自動でテストを回したいなら、GitHub Actionsとは？できること・最初の使い方を初心者向けに解説 もあわせて読むとつながりやすいです。
git pull の前にローカル変更が残っていて詰まりやすい場合は、Gitで unstaged changes があって pull できないときの対処法まとめ｜stash・restore・commit の使い分けを解説 もあわせて読むと進めやすいです。
GitHub や Stripe のような外部サービスからの通知をどう受けるのかまで見たいなら、Webhookとは？APIとの違いと実務でよくある使い方をわかりやすく解説 も続けて読むと整理しやすいです。

静的解析と型チェックはかなり相性がよい

AI にコードを書かせるとき、静的解析 や型チェックはかなり効きます。
人が全部を手で見切れないときでも、最低限の崩れを早く拾いやすいからです。

特に見つけやすいのはこのあたりです。

• 未使用変数
• 到達しない分岐
• 型の不整合
• null 周りの危ない扱い
• import 漏れや参照ミス

もちろん、静的解析が通ったから安全とは言えません。
でも AI が書いたコードをまず荒くふるいにかける 手段としてはかなり相性がよいです。

セキュリティは「いつも通り危ないところ」を先に見る

AI が書いたコードだから特別に危ない、というより、いつもの危ない場所を普通に踏みやすいと考えた方が近いです。

まず見たいのはここです。

• SQL を文字列連結していないか
• ファイルパスやコマンドをそのまま組み立てていないか
• 権限チェックを飛ばしていないか
• XSS / HTML エスケープを落としていないか
• 認証やセッション処理を雑に触っていないか

OWASP のチートシートが今でも役に立つのは、AI が書いたコードでも落とし穴の種類はそこまで変わらないからです。

外部入力を読ませるときはプロンプトインジェクションも意識する

プロンプトインジェクション は、AI が issue、ドキュメント、コメント、チケット本文、外部サイトの内容を読むときに効いてきます。
OWASP でも、外部入力でモデルの挙動を意図しない方向へ変えられるリスクとして整理されています。

たとえば、AI に

• issue コメントを読んで修正して
• 外部ドキュメントを読んでコードを書いて
• リポジトリ内の指示を全部見て判断して

のような広い仕事をさせるほど、余計な命令を拾う余地が増えます。

だから実務では、

• 信頼できる入力だけを渡す
• 重要な指示は別で固定する
• 差分を人がレビューする
• 破壊的操作は人が最終判断する

を外しにくいです。

依存関係とライセンスは地味に危ない

AI は便利そうなライブラリを軽く提案しやすいです。
でも実務では、依存追加はコード数行より重いことがあります。

確認したいのはこのあたりです。

• 本当に新しい依存が必要か
• メンテされているか
• ライセンス上問題ないか
• 既存の標準機能で代替できないか
• 依存を入れることで更新負荷が増えないか

GitHub Copilot の responsible use でも、生成コードの正しさだけでなく、設計、規制、公開コードとの近似、法的観点まで人が責任を持つべきと整理されています。
依存ライブラリやビルド基盤まで含めた全体像を整理したいなら、サプライチェーンとは？ITでどうかかわる？ソフトウェアや委託先とのつながりを解説 も合わせて読むとつながりが見えやすいです。
ここは 動いたからOK にしない方が安全です。

実際のやり方をざっくり言うと

AI にコードを書かせるなら、この流れがかなり現実的です。

1. タスクを小さく切る
   1関数、1バグ、1テスト、1ファイル単位くらいまで絞ります。
2. 仕様を短く明確に渡す
   入出力、禁止事項、触る範囲、既存パターンを先に示します。
3. 差分で確認する
   完成コード全体より、何を変えたかで見ます。
4. テストと静的解析を通す
   単体テスト、型チェック、lint を最低限回します。
5. 危ない場所だけ人が重点レビューする
   認証、権限、入力処理、SQL、ファイル操作、依存追加は特に人が見ます。

この順なら、AI の速さを使いつつ、人が持つべき判断も残しやすいです。

よくある失敗

ほかにも、この失敗はかなり多いです。

• 大きすぎるタスクを投げて、差分が読めなくなる
• レビューせずにそのままマージする
• テストが薄いのに テスト付きだから安全 と思ってしまう
• issue や外部テキストを大量に食わせ、余計な指示を拾わせる
• 秘密情報や本番ログをそのまま入力してしまう

まとめ

AI にコードを書かせるときの注意点は、使うな ではなく そのまま使わない ことです。
実務では、AI をたたき台として使いながら、仕様確認、差分確認、テスト、静的解析、セキュリティ確認、依存関係確認を人が持つ方が安全です。

特に、タスクを小さく切ること、差分で見ること、危ない場所を人が最終判断することはかなり効きます。
AI は速いですが、責任まで代わってくれるわけではありません。そこを分けて考えると、かなり使いやすくなります。

参考情報

• OpenAI: How OpenAI uses Codex
• OpenAI API Docs: Code generation
• GitHub Docs: Responsible use of GitHub Copilot coding agent on GitHub.com
• NIST: SP 800-218, Secure Software Development Framework (SSDF)
• NIST: SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
• OWASP: LLM Prompt Injection Prevention Cheat Sheet