AI が書いたコードのレビューは、分担して進められます。コードに書かれていることの洗い出しは、AI にさせられます。私たちも、レビューの洗い出しに AI を使っています。人が見るのは、次の3点です。実際に動かして確かめること。誰が使うか、どんなデータを扱うかで優先順位を決めること。頼んだことと違うことをしていないかを見ることです。
レビューを、2つに分ける
レビューには、性質の違う2つの作業が混ざっています。
| 作業 | 内容 | 向いている担当 |
|---|---|---|
| 洗い出し | コードに書かれていることを読み、問題になりそうな箇所を挙げる | AI にもさせられる。観点を指定して、何度でも回せる |
| 判断と確認 | 実際に動かした結果を見る。どれから直すかを決める。頼んだことと合っているかを見る | 人 |
これは、公式の基準があるわけではなく、私たちの整理です。分け方の理由は単純で、AI が読めるのは「コードに書かれていること」だからです。動かして初めて分かること、コードのどこにも書かれていないこと、頼んだ側の意図は、コードを読むだけでは出てきません。
洗い出しの工程を置く理由として、調査が1つあります。セキュリティ企業 Veracode の「2025 GenAI Code Security Report」は、100以上の LLM が書いたコードのサンプルを調べ、「45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities」（訳: コードサンプルの45%がセキュリティテストに失敗し、OWASP Top 10 のセキュリティ上の脆弱性を持ち込んだ）と報告しています。さらに、新しいモデルでも、安全なコードを書く力は上がっていなかったと書いています（Veracode（新しいタブで開きます））。
この数字は、LLM が書いたコードのサンプルを調べた結果です。実際に作られたアプリの調査ではないので、「AI で作ったアプリの45%に問題がある」という意味にはなりません。ここから私たちが読み取るのは、AI が書いたコードにも見落としが混ざることがあるので、書いたあとに洗い出す工程を置いておくほうがよい、ということです。AI の開発を否定する材料ではありません。
人が見る1: 実際に動かして確かめる
AI にレビューを頼むと、「問題は見つかりませんでした」「修正しました」と返ってくることがあります。この報告は、読んだ結果です。動かした結果ではありません。
私たちの現場では、AI が実行していない作業を「成功しました」と報告した例があります（AIの「成功しました」をそのまま信じない）。レビューでも同じ構造が起きえます。「修正済み」と言われたら、修正後の画面を自分で操作して確かめます。
コードを読めない人でも、動かして確かめられることはあります。
- 画面から、実際に登録・更新・削除をしてみる
- アカウントを2つ作り、片方でログインしたまま、もう片方のデータが見えないか試す（ログインと権限の制御）
- 外部との連携を止めたり、おかしなデータを入れたりして、画面がどうなるか見る（「うまくいかないとき」の処理）
人が見る2: 優先順位を、誰が使うか・どんなデータかで決める
AI に洗い出しをさせると、指摘は長い一覧になります。全部を同じ深さで直そうとすると、終わりません。
私たちは、一覧を並べ替える基準を、次の2点に置いています。
- 誰が使うか。 自分だけ、社内の数人、取引先、一般の利用者。
- どんなデータを扱うか。 個人情報や決済を含むか。
| 使われ方 | 先に見るもの |
|---|---|
| 自分や社内の数人が、個人情報を含まないデータで使う | 正しく動くか。データが消えたら戻せるか |
| 社外の人が使う、または個人情報や決済を扱う | 秘密情報の置き場所、権限、復旧、保守。この4つは公開前に答えられるようにする |
AI の指摘は、重要度の見立てを付けてくることがあります。ただ、そのアプリを誰が使うかは、作った人しか知りません。優先順位を決めるのは、人の仕事です。公開前に確かめる4点は、AIで作ったアプリを本番化するにはにまとめています。
人が見る3: 仕様と合っているか
コードに問題がなくても、頼んだことと違うことをしている場合があります。これは、洗い出しでは出てきにくい種類の問題です。
頼んだことはできていても、余計なものが残っていたり、見た目では気づけない違いがあったりします。私たち自身の失敗は、AIの「成功しました」をそのまま信じないに書きました。
レビューでは、変更の一覧（差分）を見て、頼んだ内容と関係のないファイルや設定が増えていないかを確かめます。文字列やデータの一致は、目で見比べるのではなく、プログラムで比較して確かめます。
仕様に書かれていないことは、AI も書かず、レビューでも見えない。 ある業務システムの例です。お客様が Claude Code で作った試作には、既存のシステムからデータを取ってくる処理がありました。ただ、その処理が失敗したときや、処理は正常なのにデータがおかしいときにどうするかは、考えられていませんでした。コードには問題がなく、洗い出しでも指摘されにくい。仕様の側に「うまくいかない場合」が無かったからです。これは本番化の中で整えました。
つまり、仕様と合っているかを見るには、仕様を人が持っていることが前提になります。何を頼んだか、うまくいかないとき何が起きてほしいかを、レビューする人が言葉にできるようにしておきます。
進め方の例
これは、私たちの整理した手順です。
- AI に洗い出しをさせる。 観点を指定します。たとえば、秘密情報の置き場所、権限、失敗したときの処理、使っている外部ライブラリです。
- 一覧を、誰が使うか・どんなデータかで並べ替える。 先に確かめるものを決めます。
- 実際に動かして確かめる。 指摘された点も、「問題なし」という報告も、動かした結果で判断します。
- 変更の一覧を見る。 頼んだ内容と関係のない変更が入っていないかを確かめます。
- 直したあとに、もう一度同じ確認をする。 直した箇所が、別の箇所を壊すことがあるためです。
これは、2026年10月時点の私たちのやり方です。AI の進化は速いので、AI に任せられる範囲は広がっていくと思います。それでも、「動かして確かめる」「優先順位を決める」「頼んだことと合っているかを見る」は、人の側に残ると考えています。
wizgeek にできること
自分でレビューしても不安が残る、または、何から見ればよいか分からないときは、ご相談ください。AI で作った試作の構成と機能を把握し、認証・データベース・インフラ・セキュリティ・監視のうち何が足りないかを整理して、構成案をお渡しします（本番化の診断：5万円〜、税別）。構成案をもとに、お客様側で実装していただくこともできます。本番化の作業は別途お見積りします。
まずは、AIで作ったアプリの本番化のご相談からお問い合わせください。