AIが書いたコードを、誰が確かめるのか
コーディングエージェントが普及して、専門の訓練を受けていない人でも、自然言語で指示するだけで動くプログラムを作れるようになりました。試作の速さは段違いです。ただ、ここ1年ほどで、その裏側を示す調査もいくつか出てきています。
調査が示していること
コード解析サービスの GitClear は、2億行を超える変更履歴を分析した2025年のレポートで、5行以上の重複したコードブロックが2024年に前年の8倍に増えたと報告しました。既存のコードを整理して再利用する変更の割合は、2021年の約25%から2024年には10%を下回っています。
Veracode が100以上のLLMを80の課題で検証した2025年のレポートでは、生成されたコードの約45%がセキュリティ上の問題を含んでいました。新しいモデルや大きなモデルでも、この割合はあまり改善していないとされています。
GitGuardian の2025年のレポートによると、2024年に公開GitHub上で新たに見つかった機密情報（APIキーやパスワードなど）は約2,380万件でした。GitHub Copilot を使っているリポジトリでは、機密情報が漏れている割合が全体平均より約40%高かったと報告されています。
現場で起きていること
数字の背景にあるのは、次のような状況です。
生成されるコードの量が増え、人のレビューが追いつかなくなっています。重複や場当たり的な修正が見過ごされたまま積み上がると、半年後には誰も手を付けたくないコードベースになります。
AIが書いたコードの脆弱性を、責任を持って確かめられる人がいないこともあります。生成したのが誰であれ、マージした時点でそのコードは自社の責任です。
会社が認めていないAIツールを各自が使う「シャドーAI」も広がっています。ソースコードや顧客の情報を外部のAIサービスに貼り付けてしまえば、それは情報漏えいです。IPAの「情報セキュリティ10大脅威 2026」でも、AIの利用をめぐるリスクが組織編の3位に初めて入りました。
仕組みで確かめる
人の注意力に頼るだけでは、生成の速さに勝てません。確かめる作業を仕組みに移します。
- 静的解析、テスト、依存パッケージの検査を CI に組み込み、通らないコードはマージできないようにする
- コミットの段階でシークレットスキャンをかけ、APIキーや認証情報の混入を止める
- 重複や短期間での書き直しを定期的に計測し、増えてきたら整理の時間を取る
- 使ってよいAIツールと、渡してよいデータの範囲をポリシーとして決める。禁止するより、安全に使える道具を用意するほうが守られます
- 機密性の高いコードは、社外に送らないローカルLLMで扱う選択肢も検討する
形式的な指摘を機械に任せられれば、人のレビューは設計とロジックの確認に時間を使えます。
まず何から始めるか
最初にやるのは、いまの利用状況を知ることです。誰が、どのAIツールを、どの業務で使っているか。どのリポジトリに CI があり、どこにないか。ここが分かれば、手を付ける順番はおのずと決まります。
関連するサービス
- AI前提の開発プロセスと内製化：コーディングエージェントの導入と品質ゲートの整備
- AIエージェントの業務適用：AI利用ポリシーと評価の仕組み
- ローカルLLM・閉域環境のAI：ソースコードを社外に出さないAIの利用