AIが書いたコードは、見た目がきれいです。命名は整っていて、コメントも付いていて、動かしてみると一発で通る。だから、つい読み飛ばします。
ただ、納品したコードで障害が起きたとき、クライアントに責任を問われるのはAIではなくあなたです。フリーランスは、自分で書いたかどうかにかかわらず、自分の仕事の品質に責任を持ちます。この記事では、AIが書いたコードを納品する前に見る7項目を、実際に起きやすい失敗とあわせて整理します。
先に言っておくと、AIのコードは「動く」ことと「正しい」ことが別
AIが出したコードを実行して、期待どおりの結果が出た。それで安心するのが一番危ないところです。
AIは、与えた例に合うコードを作るのが得意です。逆に、与えなかったケースへの配慮は、人間が足さないと入りません。空の配列、nullの値、同時に2つのリクエストが来た場合、日をまたぐ時刻の計算。こうしたケースで壊れるコードは、手元の動作確認では見つかりません。
だから、レビューの目的は「動くか」を見ることではなく、「動かなくなる条件が残っていないか」を探すことです。
レビュー7項目
1. 存在しない関数・パッケージが使われていないか
最初に見るのはここです。AIは、実在しないライブラリのメソッドやオプションを、もっともらしく書くことがあります。実行すればエラーで気づけるので、まだ軽い方です。
厄介なのは、存在しないパッケージ名をimportしているケースです。そのまま npm install や pip install をすると、同じ名前で第三者が登録した別物が入る恐れがあります。AIが提案した新しい依存パッケージは、インストールする前に、公式のレジストリでの登録状況と公開元、更新日、ダウンロード数を確認してください。
2. 古い書き方・非推奨のAPIを使っていないか
AIの知識には期限があります。使っているフレームワークのバージョンより古い書き方を提案してくることが、よくあります。動くのに、公式ドキュメントでは非推奨になっている、というパターンです。
使っているライブラリのバージョンを、プロンプトに書いておくと減らせます。それでも出てくるときは、公式ドキュメントの該当ページで確認しましょう。
3. 入力値の検証とエラー処理が抜けていないか
AIが書くコードは、正常に動く道筋(ハッピーパス)を中心に作られています。次の観点で、読んでみてください。
- ユーザーの入力をそのままSQLやコマンドに渡していないか
- 外部APIの呼び出しが失敗したときの処理があるか
- ファイルやDB接続を、エラー時にもきちんと閉じているか
- エラーを握りつぶして、何事もなかったように進めていないか
特に、Pythonの except: pass のように、例外を握りつぶして先へ進む書き方は要注意です。他の言語の空の catch も同じです。障害が起きても、ログにも残らず、原因を探せなくなります。
4. セキュリティの基本が守られているか
AIは、動くことを優先して、安全性を後回しにしたコードを出すことがあります。確認したいのは次のあたりです。
- パスワードや秘密鍵が、コードに直接書かれていないか
- SQLが文字列結合で組み立てられていないか
- 権限のチェックが、画面側だけで終わっていないか
- 利用者に見せるエラーメッセージに、内部の情報が混ざっていないか
網羅的に見たいなら、OWASPが公開している「OWASP Top 10」の項目と照らし合わせるのが、定番のやり方です。
5. テストが「通るためだけのテスト」になっていないか
AIにテストも書かせると、実装に合わせて期待値を作るテストが出てくることがあります。実装が間違っていても、テストは通ります。これでは意味がありません。
見るのは次の2点です。期待値が、仕様や要件から独立して決められているか。境界値、つまり0、空、最大値、最大値プラス1のようなケースが入っているか。テストが全部緑でも、それだけで安心してはいけません。
6. 依存関係とライセンス
AIが提案したコードには、新しいライブラリが含まれていることがあります。その1行で、納品物のライセンス条件が変わりえます。GPL系のライセンスのライブラリを、商用の納品物に入れるのが契約上問題にならないか、確認してください。
また、AIの出力が既存のコードに酷似する可能性はゼロではありません。長く特徴的なコードがそのまま出てきたときは、出所を疑って検索する習慣をつけておくと安心です。
7. 自分の言葉で説明できるか
最後は、レビューというより、自分への問いです。そのコードがなぜその書き方になっているのか、クライアントに聞かれて説明できますか。
説明できないコードは、納品しないでください。保守を引き継ぐ人が困りますし、障害時に自分も直せません。説明できない箇所があれば、AIに「この行は何をしているのか、別の書き方との違いは何か」と聞いて、理解してから採用します。
AIを使った開発は、クライアントの期待値も一緒に変わります。「どこまでAIを使うか」「レビューにどれくらい時間をかけるか」といった前提がずれると、見積もりや納期のトラブルのもとになります。PRO WORKSでは、クライアントとフリーランスの双方と密にコミュニケーションを取り、ミスコミュニケーションを防ぐ連携フォローを実施しています。定期アンケートで両者の声を集め、関係を良好に保ちながら進められるので、はじめての高単価案件でも安心です。
7項目を毎回回すための、短い手順
7項目を毎回すべて深く見ると、AIで短縮した時間が消えます。おすすめは、変更の大きさで深さを変えることです。
- 数行の修正:項目1、3、7を見る。入力・認証・外部通信に触れる変更なら、項目4も見る
- 新しい関数やクラスの追加:項目1〜5と7を見る
- 新しい依存パッケージの追加や、認証・決済まわり:7項目すべてに加えて、人にも見てもらう
認証や決済は、AIが書いたコードを自分ひとりのレビューで通さない方が無難です。他のエンジニアの目を入れられない一人案件なら、レビュー専用のプロンプトでAIに別の角度から指摘させる方法もあります。ただしそれは補助であり、最終判断は自分が持ちます。
よくある質問
A: AIを使ったかどうかは関係なく、責任は受注した側が負います。ただし、責任の中身は契約の種類で変わります。成果物の完成を約束する請負契約では、納品物に不具合があれば契約不適合責任を問われます。作業の遂行を約束する準委任契約では、完成の責任ではなく、注意を尽くして作業する義務(善管注意義務)が中心です。案件の前に、自分の契約がどちらか、契約不適合に関する条項があるかを確認しておきましょう。
A: クライアントの方針によります。禁止や条件がある場合もあるので、案件の開始時に確認するのが無難です。機密情報の扱いは、別の記事AIコーディングツールに案件のコードを渡していい？で詳しく書いています。
A: ありです。別のツール、または別の会話で「脆弱性の観点でこのコードを指摘して」と頼むと、見落としに気づくことがあります。ただし、指摘が正しいかどうかの確認は、人間の仕事です。
A: 生成から納品までの全体で考えてください。書く時間が減っても、レビューを省いて障害が出れば、修正対応に何倍もの時間を取られます。レビューは、手戻りを防ぐ保険です。
まとめ
AIが書いたコードの納品前に見るのは、次の7項目です。
- 存在しない関数・パッケージがないか
- 古い書き方・非推奨のAPIがないか
- 入力値の検証とエラー処理が抜けていないか
- セキュリティの基本が守られているか
- テストが通るためだけのものになっていないか
- 依存関係とライセンスに問題がないか
- 自分の言葉で説明できるか
AIは書くのが速い相棒です。ただ、最後に「これで出す」と決めるのは、フリーランス本人です。
責任を持って仕事を進めたい人へ:PRO WORKS
AIを使いこなしながら、品質で信頼を積み上げたいフリーランスのために、PRO WORKSは案件の紹介だけでなく、案件の最中も伴走してサポートします。
PRO WORKSに無料登録する※本記事は2026年10月時点の一般的な情報をもとに作成しています。ツールの仕様やライセンス、契約上の判断が必要な点は、公式情報や専門家にご確認ください。
