AIで作ったコードのバグ検査はどう進めるか【納品前に見る3点】

AIで社内ツールや小さな業務アプリを作れるようになると、次に困るのは納品前に何を見ればよいかです。

画面が開き、ボタンを押せて、エラーが出ない。そこまで確認できると安心したくなります。
ただ、AIで作ったコードのバグ検査は、画面の動作確認だけでは足りません。仕様どおり動くか、守れるか、戻せるかを分けて見る必要があります。

この記事では、非エンジニアの経営者や発注者でも外注先や社内担当者へ確認しやすいように、納品前の見方を実務の言葉へ落とします。AIで業務ツールを作り始めた背景は、非エンジニアでも業務ツールを自作する時代へでも整理しています。

AIで作ったコードのバグ検査は「動くか」だけで終わらせない

AIで作ったコードは、見た目の完成が早いぶん、確認が浅くなりがちです。入力フォームが動いても、裏側で顧客データを書き換える処理、権限の分岐、外部API失敗時の動きまで正しいとは限りません。

NISTIR 8397は、ソフトウェア検証の例として、脅威モデリング、自動テスト、静的コードスキャン、ハードコードされた秘密情報の検出、ブラックボックステスト、ファジング、Webアプリスキャン、含まれるコードの確認などを挙げています。
これは大企業だけの話ではなく、AI生成コードにも複数の見方が必要という基本線です。

出典: NISTIR 8397「Guidelines on Minimum Standards for Developer Verification of Software」(英語)

この3点で見れば、AIで作ったコードのバグ検査は専門家だけの仕事ではなくなります。発注者は「全部のコードを読めるか」ではなく、受け入れ基準と証跡があるかを見ればよいからです。

AIで作ったコードのバグ検査で最初に見る「仕様どおり動くか」

最初に見るのは、仕様どおり動くかです。ここでいう仕様は長い設計書だけではなく、現場で実際に使う入力例、承認の流れ、失敗時の連絡先まで含みます。

たとえば予約管理、請求書作成、在庫更新、顧客リストの整形のような小さなツールでも、正常に動く1例だけでは判断できません。空欄、重複、桁あふれ、権限なし、外部API停止を最低限の入力例に入れてください。

• 正常系として、いつもの入力例で期待どおりの結果になるかを見る
• 異常系として、空欄、形式違い、重複、権限なしを入れて止まるかを見る
• 業務影響として、データを書き換える処理の前後を確認する

この確認は、AIが自動で作ったテストだけに任せないほうが安全です。AIはそれらしい入力例を作れますが、現場で過去に起きた入力ミスや、担当者だけが知っている例外までは知りません。

AIで作ったコードのバグ検査を社内に定着させるなら、Apps Scriptの業務自動化を担当者任せにしない保守ルールのように、所有者、更新日、戻し方を台帳化しておくと後から追いやすくなります。

AIで作ったコードのバグ検査で外せない「守れるか」

次に見るのは、守れるかです。ここでの対象は、顧客情報、従業員情報、APIキー、パスワード、トークン、契約条件、未公開の価格表などです。

AIで作ったコードでは、動作を急ぐあまり、コード内にAPIキーを直書きしたり、管理者だけが見るべきデータを一般ユーザーにも表示したりする危険があります。画面がきれいでも、秘密情報が混ざっていれば納品前に止めるべきです。

GitHub CodeQLは、コードをデータとして扱い、クエリで潜在的な脆弱性やエラーを見つける仕組みです。対応言語は限られますが、GitHub上でコード管理しているなら静的解析の候補になります。

出典: GitHub Docs「Code scanning with CodeQL」(英語)

また、GitHub Secret ScanningはAPIキー、パスワード、トークンなどのハードコードされた秘密情報を検出する機能です。納品前に秘密情報が残っていないかを見る時、こうした機械的な検査は役に立ちます。

出典: GitHub Docs「Secret scanning」(英語)

確認対象	見る場所	止める判断
APIキー	コード、環境変数、Git履歴	直書きがある
権限	ログイン後の画面、管理メニュー	一般ユーザーが管理情報を見られる
依存関係	パッケージ一覧、更新履歴	古い脆弱なライブラリを放置している
個人情報	入力、表示、出力CSV	不要な項目まで保存している

社内データをAIへ読ませる前提があるなら、生成AIに社内データを読ませる前の保全ルールも合わせて見てください。コードの検査とデータ保全は別物に見えますが、実務では同じ事故につながります。

AIで作ったコードのバグ検査で最後に見る「戻せるか」

3つ目は、戻せるかです。社内ツールの不具合で一番困るのは、失敗した後に誰も戻せない状態です。
AIで作ったコードのバグ検査では、本番反映前にバックアップ、ロールバック、ログ、担当者を確認します。

NIST SP 800-218のSecure Software Development Frameworkは、脆弱性を減らし、未検出脆弱性の悪用影響を緩和し、根本原因へ対処する考え方を示しています。納品前チェックも、単に一度合格する作業ではなく、問題が出た時に被害を小さくする仕組みとして扱うべきです。

出典: NIST SP 800-218「Secure Software Development Framework」(英語)

戻し方の確認は技術者だけの作業ではなく、経営者や現場責任者も何が起きたら止めるか、誰が戻すか、どの画面やログを見ればよいかを決めます。これは中小企業のセキュリティ初動手順と同じで、証跡を残すほど初動は速くなります。

AIレビューはバグ検査の第一チェックにとどめる

GitHub Copilot code reviewは、Pull Requestや未コミット変更に対してレビューを依頼でき、提案変更を返す場合があります。こうしたAIレビューは、見落としを減らす第一チェックとして使えます。

出典: GitHub Docs「Using GitHub Copilot code review」(英語)

ただし、AIレビューは業務の受け入れ判断を代わりに引き受けるものではありません。仕様の優先順位、顧客への影響、現場の例外運用、公開日の判断は人が決めます。

OWASP Top 10 for Large Language Model Applicationsでは、LLMの出力を十分に検証しないことが、下流システムでのセキュリティ上の悪用やコード実行につながるリスクとして説明されています。AIの出力をそのまま業務システムへ入れないという前提は、コード生成でも同じです。

出典: OWASP「Top 10 for Large Language Model Applications」(英語)

AIエージェントに自律実行を任せる場面でも、承認の置き場所が重要です。運用の考え方は、AIエージェントの自律実行は暴走を止められるかで解説した承認設計と重なります。

AIで作ったコードのバグ検査で外注先に出してもらう証跡

外注先や社内担当者に確認する時は、難しい専門用語で詰めるより、提出物を決めたほうが早いです。「テストしました」ではなく「何を、いつ、どう確認したか」を見ます。

• テストした正常系と異常系の入力例
• 静的解析、lint、型チェック、秘密情報検査の結果
• AIが生成した箇所と、人が確認した箇所の説明
• 本番反映前のバックアップと戻し手順
• 障害時に見るログ、連絡先、停止判断

この証跡が出てこない場合、AIで作ったコードのバグ検査はまだ終わっていないと見てください。特に顧客情報、請求、予約、在庫を扱うツールでは、納品前に止める勇気が必要です。

発注者の質問	確認したいこと
どのデータを書き換えますか	事故時の影響範囲
失敗時はどう戻しますか	復旧手順と担当者
秘密情報はどこで管理しますか	コード直書きの有無
どの入力例で試しましたか	仕様と異常系の範囲
AIレビュー以外に何をしましたか	人の確認と機械検査の分担

AI活用の成果を管理するなら、検査結果も成果物の一部として残すべきです。AI導入KPIの成果測定でも触れている通り、利用回数だけでなく、作ったものが安全に使える状態かを見る必要があります。

AIで作ったコードのバグ検査は受け入れ基準から決める

最後に、AIで作ったコードのバグ検査は、コードを書き終えてから慌てて始めるより、依頼時点で受け入れ基準を決めたほうがうまく回ります。

AIでコードを作る速さは、今後さらに上がります。だからこそ、納品前の確認は「気合いで読む」ではなく、動くか、守れるか、戻せるかに分けて仕組みにしてください。
速く作れることと、安心して使えることは別です。

AIで作ったコードのバグ検査でよくある質問