AIが書いたコードを確認する方法。初心者向けチェックリスト
AIが生成したコードを実行する前に、目的、変更範囲、秘密情報、安全性、テストを確認する手順を解説します。
AIが一瞬で何十行もコードを書いてくれると、助かる半面、「これ、実行して大丈夫かな」と迷いますよね。
初心者が最初からすべての不具合を見抜くのは難しいです。それでも、確認を順番に分ければ、見落としを減らせます。
この記事では、目的 → 入出力 → 危険な操作 → 小さなテスト → 差分の順に見ます。最後は、入力をそのまま実行してしまうPythonコードを、安全な足し算へ直す練習です。
1. まず、何をするコードか一文にする
コードの細かい書き方より先に、「正しく動いたら何が起きるか」を決めます。
2つの整数を入力すると、その合計を画面に表示する。
整数以外を入力したら、説明を出して終了する。
ファイル保存や外部送信は行わない。このように必要な動作を決めたものを、仕様と呼びます。
「便利な計算機」では、掛け算も必要なのか、計算履歴を保存するのか分かりません。足し算だけでよいなら、関係のない機能が入っていないかも確認できます。
AIに説明させるなら、次のように範囲を絞ります。
まだ実行・編集はしないでください。
入力、計算、出力を、それぞれ一文で説明してください。
ファイル操作と通信があれば、その対象も挙げてください。説明だけで安全だと判断せず、その説明と実際のコードを照合するのが次の段階です。
2. 入力と出力を、具体的な数値にする
「足し算できる」だけでなく、期待する結果を書きます。
| 入力 | 期待する動作 | 確かめたいこと |
|---|---|---|
2 と 3 |
5 を表示 |
基本の計算 |
-2 と 3 |
1 を表示 |
負の数 |
0 と 0 |
0 を表示 |
0の扱い |
hello |
整数を求める説明を表示 | 数字以外 |
3.5 |
整数を求める説明を表示 | 小数を受け付けない仕様 |
| 空欄 | 整数を求める説明を表示 | 入力なし |
先にこの表を作ると、AIの出した結果に合わせて「これでいいことにしよう」となりにくくなります。
条件の境目も大切です。たとえば「60点以上で合格」なら、59・60・61を試します。80点だけ合っていても、60点ぴったりの処理を間違えているかもしれません。
3. 分からない行は、役割と影響を分けて調べる
長いコードは、まず「入力を読む部分」「計算する部分」「表示する部分」に分けます。
次に、知らない関数やライブラリを一つずつ確認します。関数は処理をひとまとめにしたもの、ライブラリは再利用できる機能をまとめた道具です。
聞き方の例は、こうです。
この関数について、次の3点を説明してください。
1. 何を受け取るか
2. 何を返すか
3. ファイルや通信など、外部への影響があるか「短いコードだから安全」とは言い切れません。短い命令でも、広いフォルダを消したり、外部へ情報を送ったりできます。
また、AIの説明自体にも間違いはあります。使っている言語やライブラリの公式説明で確かめましょう。GitHubの公式ガイドも、提案されたコードの理解、レビュー、テストを求めています。
4. 実行前に、危険が大きい操作を探す
次の操作があるときは、目的と対象を説明できるまで止めます。
| 操作 | 確認すること |
|---|---|
| 削除・上書き | 対象のファイルはどこか。元へ戻せるか |
| 管理者権限の利用 | その権限が本当に必要か |
| 外部への通信 | どの相手へ、何を送るのか |
| パッケージの追加 | 公式に案内される名前・配布元か |
| 入力を命令として実行 | 利用者が勝手な処理を指定できないか |
| 公開・データベース変更 | 他人や本番データへ影響しないか |
パッケージは、インストールして使うソフトウェアのまとまりです。AIが書いた名前を検索して、似た名前が見つかっただけでは不十分。元の公式サイトが、その配布先を案内しているか確認します。
練習用のフォルダを使うことも役立ちますが、フォルダを分けただけでは、コードが外へ出ることを防げません。作業範囲やネットワークの制限も必要に応じて使います。サンドボックスの意味も押さえておきましょう。
5. 秘密情報は「今のファイル」以外も確認する
パスワードや秘密のAPIキーは、コードへ直接書きません。
確認対象は、コードだけでなく、設定ファイル、実行ログ、画面共有、Gitの履歴にも広がります。.env に移せば自動で安全になる、というものでもありません。
環境変数は設定をコードの外から渡す仕組みで、秘密を暗号化する機能そのものではありません。ブラウザ向けの公開ファイルに値が埋め込まれる使い方も避ける必要があります。
秘密のキーを公開した場合は、発行元での無効化・再発行などが必要です。コードから消しただけでは、コピーされたキーを使われるおそれが残ります。GitHubの流出対応ガイドでも、削除だけでは不十分とされています。
学校やチームの情報なら、自己判断で処理を進めず、管理者へ知らせてください。
6. テストは、正解を別に用意して比べる
テストは、実際の結果が期待した結果と一致するかを確かめることです。
Pythonなら、assert を使って、条件が成り立つかを小さく確認できます。次は説明用の練習コードです。
def add(first, second):
return first + second
assert add(2, 3) == 5
assert add(-2, 3) == 1
assert add(0, 0) == 0
print("3つの計算を確認できました")条件が違っていれば AssertionError というエラーで止まります。3つとも合っていれば、最後の文章が表示されます。assert はここでは学習用の検査に使っています。本番の入力チェックをこれだけに任せる用途ではありません。
AIが書いたテストも、そのまま信用しない
たとえば add(2, 3) == add(2, 3) では、同じ計算結果を自分自身と比べるだけです。関数がいつも100を返しても、比較は通ってしまいます。
「2と3なら5」のように、人が独立に分かる答えを用意することが重要です。
テストが通っても、それは試した範囲の確認です。画面の崩れ、遅さ、権限の問題など、別の確認が必要なこともあります。
7. 既存のコードは、差分を読んで採用する
AIが変更した場合は、ファイル全体だけでなく差分、つまり変更前後の違いを見ます。
git status
git diff
git diff --stagedこれらは状態や差分を見る操作で、変更を公開する命令ではありません。
git status：変更されたファイル、未追跡ファイル、ステージング状態を確認git diff：まだステージングしていない変更を確認git diff --staged：コミットに入れるために選んだ変更を確認
新規の未追跡ファイルは、通常の git diff だけでは本文が見えません。git status で存在を確認し、内容も開きます。Git公式のdiff説明
見る順番は、ファイル数 → 依頼との関係 → 削除された処理 → 新しく入った処理です。「見出しを直して」と頼んだのに料金設定まで変わっていたら、一度止めましょう。
練習：入力をそのまま実行するコードを直す
次は問題点を考えるための例です。実行せずに読んでください。
calculation = input("計算式: ")
print(eval(calculation))eval は、文字列をPythonの式として評価します。信頼できない入力を渡すと、意図しないコードの実行につながる危険があります。Python公式のevalの警告
このコードを、記事の最初に決めた「2つの整数の足し算だけをする」仕様に直してください。
模範解答
def add(first, second):
return first + second
try:
first = int(input("1つ目の整数: "))
second = int(input("2つ目の整数: "))
except ValueError:
print("整数で入力してください")
else:
print(f"合計は{add(first, second)}です")解説：3段階に分けて読む
1. 入力を数値へ変える。 input は文字列を返します。int で整数に変換することで、入力を好きな命令として実行するのではなく、計算する値として扱います。
2. 変換できない入力を受け止める。 hello や 3.5 は整数への変換で ValueError になります。except はそのエラーを受け取り、説明を表示します。
3. 変換が成功したときだけ計算する。 else の中で合計を表示します。関数に計算だけを分けたので、前の節のように入力操作なしでテストできます。
2 と 3 を入れた場合は「合計は5です」です。記事の最初の表を使い、負の数、0、数字以外、小数、空欄も確認できます。
ここでは整数の大きさや、端末からの入力終了までは仕様に入れていません。公開サービスへ組み込むなら、入力長や受付範囲など、その用途に必要な制約を追加します。短い練習コードが、そのまま本番用の完成品になるわけではありません。
採用前の最終チェック
- 何をするコードか、自分の言葉で言える
- 入力と期待する出力が決まっている
- 知らない処理を調べた
- 削除・上書き・外部送信・追加ソフトを確認した
- 秘密情報を含めていない
- 普通の入力と、失敗する入力の両方を試した
- 差分を読み、依頼していない変更がない
- 試せなかったことを「未確認」のまま把握している
不明なまま採用するより、「この行の影響が分からない」と止まれる方が大切です。エラーが出た場合は、エラーの読み方から一緒にほどいていきましょう。