AIが生成したコードをレビューする方法：チェックリスト

AIが生成したコードをレビューするには、まず何が変わったか（どのファイルが、なぜ変わったか）を確認し、コードを1行も読む前に自分で動作をテストします。そのうえで、AIのコードが間違えやすい箇所を確認します。サーバー側の権限チェックの欠如、ブラウザに露出した秘密情報、検証されていない入力、存在しないパッケージや関数、頼んでいないものへの変更です。

AIのコードは、たいてい動きますし、見た目も整っていることが多いです。そのため、本当に確認しないまま承認しやすくなります。このガイドは、コードを流暢に読める人にも、まったく読めない人にも使えるレビューの手順です。

リスクに応じてレビューの深さを決める

すべての変更に同じ注意が必要なわけではありません。

ステップ1：何が変わったかを確認する

コードを判断する前に、変更の一覧を手に入れましょう。

• プロジェクトがGitで管理されているなら、**差分（diff）**を見ます。前回のコミット以降に変更されたファイルと行です。AIで作ったアプリでGitを使う方法をご覧ください。
• もしくは、AIに直接聞きます。

直前の変更で変更したファイルをすべて挙げ、それぞれについて何がなぜ変わったのかを一文で説明してください。

この段階での危険信号は、依頼と関係のないファイル、削除されたファイル、頼んでいない設定や依存関係の変更です。

ステップ2：まず動作をテストする

コードを読むと、何をするように意図されているかは分かります。テストすると、実際に何をするかが分かります。読む前に、次を試してください。

• 通常のユーザーとして、デスクトップと小さめの画面幅のスマートフォンで変更を試す。
• 不正な入力で試す。空の欄、非常に長い文字列、負の数、過去の日付など。
• ログアウトした状態で試す。別のユーザーとしても試す。
• 最も重要な流れを再確認する。サインアップ、ログイン、主要な操作、決済。

テストで失敗したら、読む時間を節約できています。問題を明確に報告し、AIに直してもらいましょう。良いバグレポートの書き方もご覧ください。

ステップ3：サーバー側で権限を確認する

もっとも重要な確認です。AIツールは、ページ上でボタンを隠すだけで、サーバーは誰からの依頼でも実行してしまうことがよくあります。

データを読み取ったり変更したりするすべてのルートや関数について、次を問いましょう。

• そのユーザーはログインしているか？
• そのユーザーは、この特定のレコードにアクセスしてよいか？
• そのチェックはページ側ではなく、サーバー側で行われているか？

追加または変更したすべてのAPIルートについて、サーバー上でどの権限チェックを行っているかを、該当行を引用して説明してください。権限チェックがないルートがあれば指摘してください。

そのうえでテストします。ユーザーAでログインし、レコードのIDを控えます。次にユーザーBでログインして、そのIDをリクエストします。AIで作ったアプリのセキュリティチェックリストに、完全なテスト手順があります。

ステップ4：露出した秘密情報を探す

• 変更されたファイルの中から、キーやパスワードのように見えるものを検索する。
• 秘密のキーは環境変数から読み込み、サーバー側のコードでのみ使われていることを確認する。
• 秘密の変数にVITE_やNEXT_PUBLIC_などの公開用のプレフィックスが付いていないか注意する。これらはブラウザ用のコードに組み込まれてしまいます。

APIキーを安全に管理する方法もご覧ください。

ステップ5：入力とエラーを確認する

• サーバー側での検証。 ブラウザでのチェックは回避されてしまいます。必須項目、長さ、形式、許可された値は、サーバーでも検証する必要があります。
• データベースへの問い合わせにはパラメータを使う。 ユーザーの入力をそのままクエリの文字列に組み立てないでください。
• エラーを握りつぶさない。 何もしないtry/catchは失敗を隠してしまいます。エラーはログに記録し、ユーザーにはわかりやすいメッセージを表示するべきです。
• 内部の詳細をユーザーに見せない。 スタックトレースやデータベースのエラーは、ログに残すものです。

ステップ6：本当に存在するかを確認する

AIモデルは、正しく見えるけれども存在しないものを参照するコードを生成することがあります。

• パッケージ： 新しい依存関係はすべて、その正確な名前で実在し、保守されているパッケージであるべきです。人気のあるパッケージの誤字のような名前には注意してください。
• 関数とAPIのオプション： ライブラリの関数や外部APIのオプションが見慣れないものなら、公式ドキュメントで確認してください。
• 仮のコード： TODO、mock、fake、ハードコードされたサンプルデータ、常に固定値を返す関数を検索します。

新しいパッケージを追加しましたか？ 追加したものごとに、正確な名前、用途、なくても済むかどうかを教えてください。

ステップ7：プロジェクトに合っているかを確認する

コードは動いていても、後から変更しにくいアプリを作ってしまうことがあります。

• 重複。 同じロジックが複数箇所にコピーされていると、いずれ食い違います。
• 一貫性。 アプリの他の部分で使われているパターンに従うべきです。
• 規模。 20行の依頼に対して600行のコードが生成されたなら、確認すべきです。
• 未使用のコード。 新しいものの横に残された古いバージョン。

この変更によって、プロジェクト内で未使用になったコードや、他の場所で重複しているロジックはありますか？ 変更はせず、一覧にしてください。

よくある間違い

• きれいに見えるから承認する。 整ったコードでも、権限チェックを飛ばしていることがあります。
• テストせずに読むだけにする。 先にテストし、その後で読みましょう。
• 正常系だけをテストする。 不正な入力、別のユーザー、ログアウト状態も試してください。
• 関係ないファイルの変更を無視する。 なぜすべてのファイルが変わったのかをAIに聞きましょう。
• 自己レビューを完全に信用する。 AIのレビューは一次チェックとして使い、テストで確認してください。
• 1週間分の変更をまとめてレビューする。 小さな変更は、発生したときにその都度レビューしましょう。

チェックリスト

• どのファイルがなぜ変わったかを把握しており、関係ない変更はない。
• デスクトップとスマートフォンで、不正な入力、ログアウト状態、別のユーザーとして、変更が動作する。
• データを扱うすべてのルートが、サーバー側でログインと所有者を確認している。
• コードやブラウザ用のバンドルに秘密情報がない。
• 入力はサーバーで検証されており、クエリはパラメータを使っている。
• エラーはログに記録され、握りつぶされず、ユーザーには詳細を見せていない。
• 新しいパッケージは実在し、必要なものである。存在しない関数や仮のコードが残っていない。
• リスクの高い変更は慎重に読まれ、必要に応じて2人目のレビュアーも確認した。

Mythexでのコードのレビュー

• Askモードは、コードを編集せずにコードについての質問に答えます。「変更をすべて説明して」「権限チェックのないルートはどれか」といった依頼に最適です。詳しくはチャットをご覧ください。
• コードビューでは、すべてのプランでファイルツリー、エディター、ターミナルを表示できます（Freeでは読み取り専用、Proでは編集可能）。変更されたものを自分で読めます。詳しくはコードエディターをご覧ください。
• /test を使うと、エージェントがプレビューをユーザーとしてクリックして回り、壊れている流れを報告します。
• チェックポイントを使えば、レビューで問題が見つかった変更を元に戻せます。

開発者にレビューを依頼する場合は、AIで作ったアプリを開発者と進める方法で引き継ぎ方を説明しています。レビューでバグが見つかった場合は、AIで作ったアプリのデバッグ方法をご覧ください。

よくある質問