AIが書いたコードを自分で確かめる
AIにコードを書いてもらうと、動くものが一気にできあがります。しかし「動いた」と「正しく動き続ける」は別物です。AIの提案は統計的にもっともらしいコードであり、あなたのアプリの事情をすべて知っているわけではありません。
GitHubのCopilotのベストプラクティスでも、提案されたコードを理解し、検証する責任は利用者にあると繰り返し説明されています。この記事では、プログラミング経験が浅くてもできる、AIが書いたコードの確かめ方を順に整理します。
説明できないコードを残さない
最初のルールはシンプルです。何をしているか一行も説明できないコードを、そのまま取り込まないことです。
取り込む前に、AI自身に「このコードが何をしているか、一行ずつ日本語で説明して」と依頼します
説明を読んで、自分のアプリでやりたいことと一致しているかを確認します
説明されても分からない部分は、「もっと簡単な書き方はないか」と聞き直します
理解できない高度な書き方より、自分が読める素朴な書き方のほうが、個人開発では価値があります。直せるのは、読める人だけだからです。
動作を自分の手で確認する
AIが「これで動きます」と言っても、確認するのは自分の環境です。
まず、依頼したとおりの正常な操作を一周します
次に、空の入力、長すぎる入力、連続クリック、再読み込みなど、意地悪な操作を試します
変更した機能だけでなく、その周辺の機能が壊れていないかも一周します
この確認の型は初めて作ったアプリを自分で確認する方法で詳しく説明しています。エラーが出たら、エラーメッセージを読んで自分で直すの手順でエラー全文とコードをAIに戻すと、修正の往復が速くなります。
危ない箇所だけは必ず目視する
すべての行を深く読めなくても、次の箇所だけは自分の目で確認します。
秘密情報：APIキーやパスワードがコードに直接書かれていないか。書かれていたら個人開発の秘密情報を安全に管理するの方法で分離します
外部への送信：見覚えのないURLへデータを送る処理が入っていないか
削除や上書き：ファイルやデータベースを消す処理が、想定した範囲だけを対象にしているか
入力の扱い：利用者の入力をそのまま画面やデータベースに渡していないか（考え方は個人開発のセキュリティを最初の一歩から固めるで整理しています）
ライブラリの追加：知らないパッケージが増えていないか。増えていたら、それが何かをAIに説明させます
チェックの観点を固定しておくと、コードが読めるようになる前から危険の芽を摘めます。
小さく依頼して小さく確かめる
確認のしやすさは、依頼の大きさで決まります。
「アプリ全体を作って」ではなく、一つの機能、一つの画面単位で依頼します
一度に受け取る変更が小さいほど、どこが変わったかを把握できます
動作確認が済んでから次の依頼へ進み、動く状態を常に保ちます
依頼の切り分け方はAIに作りたいアプリを伝える方法で説明しています。大きな変更を受け取ってしまい、どこが壊れたか分からなくなったら、動いていた状態まで戻ってやり直すほうが早いこともあります。
確認の記録を一行残す
確認したことを、コミットメッセージやメモに一行で残します。
[ ] 何を依頼したか（一文）
[ ] 正常な操作を一周した
[ ] 意地悪な操作を試した
[ ] 秘密情報・外部送信・削除処理を目視した
[ ] 説明できない行が残っていないこの5項目が習慣になると、AIとの開発は「速いが不安」から「速くて説明できる」に変わります。
次に読む記事
セキュリティの観点は個人開発のセキュリティを最初の一歩から固めるでまとめて確認できます。公開前の総点検は個人開発を公開する前のチェックリストを使ってください。