Black Duck調査、AI開発の成果を支える検証とガバナンス

97%を読む前に、調査の母集団を確認する

同社発表によると、調査はUserEvidenceと共同で2026年3月に実施され、従業員500人以上の企業に所属するソフトウェアエンジニアとDevOps担当者831人が回答した。技術・SaaS企業が多い構成で、回答者側のAIコーディング採用率は97%だった。世界の全企業や日本の中小企業の97%が利用している、という意味ではない。

生産性やリリース速度の改善を報告したチームは92%。一方、全面的なガバナンスを整えているとの回答は30%にとどまる。追跡や影響測定を重要とする意識と、それを日々の工程に組み込む実装には距離がある。同調査では、ガバナンスが整ったチームほど大きな効率改善を報告しやすい関連も示されたが、制度を導入すれば同じ効果が必ず出るという因果の証明ではない。

作成の時短を、工程全体の時短へ変える

調査で浮かぶのは、作業の消滅より移動である。レビュー、セキュリティ試験、手戻りがボトルネックとして挙がった。コードを大量に生成しても、仕様との照合を一人の熟練者に集中させれば、承認待ちが増える。変更量が増えたのにリリースまでの時間が変わらない場合、生成速度だけを評価しても改善点は見えない。

ここからは編集部の考察だ。導入前後を比べるなら、実装時間に加えてレビュー待ち時間、差し戻し回数、不具合の流出、修正完了までの時間を同じ単位で残すとよい。案件の難易度や担当者が違う週を単純比較せず、小さな同種作業を継続して測る。AIが作った行数は活動量の指標にはなるが、利用者へ届いた価値や品質の代わりにはならない。

独立した検証と人の承認をつなぐ

発表では、生成したコードを別のAIが評価することへの期待と、人の関与を維持したい意向が併存している。レビュー用AIを増やすだけで、独立性が自動的に確保されるわけではない。同じ誤った仕様を渡せば、生成側と検証側が一緒に誤解する可能性がある。

実務では、変更の目的、受入条件、テスト結果を先にそろえる必要がある。AIの自己申告を完了条件にせず、実行した試験、変更したファイル、失敗した条件をレビューへ渡す。認証や課金など影響の大きい変更は、通常の文言修正と別の承認経路にする。これは調査が直接実証した手順ではなく、結果を自組織へ応用する際の設計例である。

管理対象を増やしすぎない導入

AI利用履歴には、ソースコードや顧客情報が混ざり得る。追跡を目的に会話全文を広く集めると、別の情報管理負担を生む。まずは利用ツール、対象リポジトリ、変更ID、実行した検証、承認者など、目的に必要な記録から始めたい。内容の保存が必要なら、閲覧者、保存期間、削除方法を決める。

調査はアプリケーションセキュリティ企業による発表であり、回答者の自己申告という限界もある。自社の効果測定を置き換える統計ではない。それでも、導入率の高さだけでは説明できない検証工程の負担を可視化する点に意義がある。開発支援を相談する場合も、生成機能と同時に確認工程を設計することが大切だ。運営会社のRO合同会社でも、業務の責任分担を含めたAI活用の相談先を案内している。

参考報道：イノベトピア。調査条件と数値は上記Black Duck発表に基づく。企業ごとの改善方法は編集部の考察である。

調査の回答を自社へ当てはめる前には、担当する開発工程の違いも確認したい。新規画面の作成と、長く運用してきた決済処理の変更では、生成に要する時間が同じでも確認の負担は異なる。チーム単位で変更の種類を分け、レビューで見つかった問題と修正時間を残すと、支援が有効な場面を具体的に把握できる。これは調査が実証した効果ではなく、導入評価のための提案である。