「コードを書く」から「検証する」へ、移り変わる現場の負荷

レポートは明確なパターンを特定しています。AIツールはコードを「書く」行為を加速させますが、そのスピードが他のあらゆる場所に新たな圧力を生み出しているのです。10チーム中9チームが、AIが生成したコードに関連する何らかの問題を、開発フローのどこかで経験しています 。問題はランダムに発生するのではなく、以下の3つの後工程に集中し、コーディング段階で短縮できた時間をまとめて吸収してしまいます。

• 手動コードレビュー（52%）：レビュー担当者は、人間が書いたコードよりもはるかに大量のAI生成コードを処理することを強いられており、その量は増加の一途をたどっています 。
• セキュリティテスト（51%）：AI生成コードは、手書きのコードには見られなかった新たな種類の脆弱性を生み出します。特に、依存関係の注入、ハードコードされたシークレット情報、古い推奨ライブラリの利用などが顕著です 。
• 生成コードの修正・再作業（48%）：半数近くのチームが、AIの出力をリリース前に修正、リファクタリング、または完全に書き直す作業に多大な時間を費やしていると回答しています 。

この現象には「Toil（苦役）の移動」という名前が付けられています。AIが面倒な作業を無くしたのではなく、その負荷を「コード作成」段階から「検証」「テスト」「修正」段階へと移動させたに過ぎないのです 。Black Duckの表現は率直です。「ほとんどの組織は、レビューし、保護し、管理できるよりも早く、AI生成コードを生産している」。

ガバナンスこそが投資対効果を決める

エンジニアリングリーダーがこのレポートを読み、即座に行動に移すべき教訓があるとすれば、それは次の一点に尽きます。ガバナンスこそが、AI投資の効果を何倍にも高める「倍率装置（ROI multiplier）」であるということです 。

AI利用を適切に管理できているチームと、そうでないチームの間にある差は、わずかなものではありません。それは、効率化の果実をしっかりと刈り取れるか、それとも指の間からこぼれ落ちるのを見ているだけかの違いです。

Black Duckの調査では、包括的なガバナンスの枠組みを持つ組織の90%が、AIコーディングツールによって「大幅な効率化」を達成したと報告しています。一方、体系的な監視体制を持たないチームで同じ結果を得られたのは、わずか44% でした 。

この文脈でのガバナンスとは、官僚主義的な手続きを増やすことではありません。どのツールを使うか、AI生成コードをどうレビューするか、どのセキュリティチェックを通過させる必要があるか、そしてその成果物の責任は誰が負うのか、といった明確なポリシーを定義することを意味します。「開発者が好きなツールを自由に使う」状態と、「開発者が、監査可能な構造化されたパイプラインの中で承認済みのツールを使う」状態の違いです。

忍び寄る「シャドーAI」のリスク

ガバナンスの難易度をさらに高めているのが、シャドーAIの台頭です。これは、開発者が会社のポリシーに反して、あるいはそれを知らずにAIツールを使用してしまう現象です。Black Duckは、回答組織の18%が、シャドーAIを重大な未管理リスクとして認識していることを明らかにしました 。Cursor、Windsurf、Claude Codeといったツールが、調達やセキュリティレビューを経由せずに個々の開発者レベルで導入されてしまうと、組織は自社の攻撃対象領域に対する可視性を失います 。

サプライチェーンリスク：AI生成コードは何を「継承」するのか

ガバナンスの欠如が具体的な脆弱性へと変わるのが、サプライチェーンの領域です。Black Duckの一連の調査（関連する2026年のOSSRAレポートを含む）は、AIコーディング支援ツールに特有の、相互に関連する3つのリスクを浮き彫りにしています。

ライセンスのロンダリング
AIアシスタントはオープンソースのリポジトリを学習しているため、コピーレフト（著作権継承義務）を含むソースからコードの断片を生成しても、元のライセンス情報を保持しない可能性があります 。2026年のOSSRAレポートによると、監査対象コードベースの3分の2にライセンスの競合が存在し、これはレポート史上最悪の水準です 。組織は、自分たちが使用する法的権利を持たないコードを、気付かぬまま出荷している可能性があります。

依存関係の爆発的増加
コードベースあたりのオープンソースコンポーネントは前年比で30%増加し、平均的な脆弱性の数は107%も急増しました 。AIコーディング支援ツールは、より広範な学習コーパスから、より高速に解決策を構成するため、この傾向を加速させます。つまり、AIが生成した一つの機能が、開発者が明示的に選択していない依存関係を大量に引き込む可能性があるのです。

コンプライアンスの空白地帯
AI生成コードに対して、知的財産権、ライセンス、セキュリティ、品質を包括的に評価している組織は、全体のわずか24% に過ぎません 。これは、4分の3の組織が「当社は今、どのような法的・セキュリティ上の義務を負ったのか？」という問いに、確実に答えられないことを意味します。

「AIは使わざるを得ないが、信頼もできない」開発者の葛藤

Black Duckの調査結果は、単独で存在しているわけではありません。同時期に発表された複数の独立した調査が、この信頼問題をより詳細なデータで補強しています。

• Sonarの「2026 State of Code Developer Survey」（1,100人以上の開発者を対象）によると、開発者の96%が、AI生成コードの機能的な正確性を完全には信頼していません 。しかし、そのコードをコミットする前に常に検証している開発者は、わずか48% に留まっています。つまり、開発者自身が信頼していないコードが、定期的に本番環境に送り出されているのです 。
• Stack Overflowの「2025 Developer Survey」（49,009人が回答）では、AIの精度に対する信頼度が1年で40%から29%に低下しました。積極的に「不信」を抱く開発者は46%に上り、AIへの好意的な見方も72%から60%に減少しています 。
• Harnessの「State of AI-Driven Software Releases 2026」（エンジニアリングリーダー500人を対象）では、57%がいまだにAI生成コードの全行に対して「ヒューマン・イン・ザ・ループ（人間による介在）」レビューを必要とし、29%はAIアシスタント導入前よりもコードレビューに多くの時間を費やしていると回答しています 。

これらの調査結果に共通するのは、驚くほど一貫した構図です。開発者はもはやAIツールなしでは仕事ができない一方で、その出力を完全には信頼できないのです。コード生成速度と検証精度の間のギャップが、新たな最大のボトルネックとなっています。

Noma SecurityのCISOであるDiana Kelley氏は、この中核的な緊張関係を端的に言い表しています。「より速いコードが、より安全なコードと同じ意味を持つわけではありません」。

「ガバナンスのある現場」は何が違うのか

30%の成功事例から、Black Duckは具体的な処方箋を導き出しています。完全なガバナンスを持つ組織と、そうでない組織を分けるのは、以下のような具体的な施策です。

1. 構造化されたAIガバナンスの枠組み：単なる非公式なガイドラインではなく、ツールの承認、成果物のレビュー、説明責任を定めた、文書化され強制力のあるポリシー 。
2. パイプラインに統合されたレビューゲート：46%の企業がいまだに依存している「人手によるセキュリティテスト待ち行列への受け渡し」から脱却し、すべてのAI支援によるコミットに対して自動化された品質・セキュリティチェックを実行する 。
3. デプロイ後の継続的な監視：Black Duckは「リスクはソフトウェア開発ライフサイクル全体で導入され、発見され、管理されなければならないため、シフトレフトだけの戦略はもはや不十分である」と指摘しています 。
4. セキュリティツールチェーンの合理化：回答者の71%以上が、ツールの無秩序な増加を大きな摩擦の原因として挙げています。安全にAIをスケールさせるには、より少数の、より統合されたツールに集約することが前提条件となります 。

結論：ガードレールを先に作らなければ、得た時間は検証で溶けていく

Black Duckのレポートは、AIコーディング支援ツールの使用に反対しているわけではありません。そうではなく、見合ったガバナンスなしにAIを使うことは、自家撞着（じかどうちゃく）に陥る行為だと主張しているのです。

開発チームの97%が前例のない速度でコードを生成している一方で、それを管理する監視基盤を持つチームがわずか30%に過ぎないという現状は、業界全体が「現金化できない小切手」を書きまくっているようなものです。

ガバナンスと効率化の相関関係（90%対44%）は、ビジネス上の必然性を明白に示しています。最初にガードレールを構築した組織だけが、AIが約束する真の生産性を手に入れることができるでしょう。そうでない組織は、キーボードの前で節約した時間が、レビュー待ち行列で溶けていくという事実を、これからも繰り返し思い知ることになるはずです。

「コードを書く」から「検証する」へ、移り変わる現場の負荷

レポートは明確なパターンを特定しています。AIツールはコードを「書く」行為を加速させますが、そのスピードが他のあらゆる場所に新たな圧力を生み出しているのです。10チーム中9チームが、AIが生成したコードに関連する何らかの問題を、開発フローのどこかで経験しています 。問題はランダムに発生するのではなく、以下の3つの後工程に集中し、コーディング段階で短縮できた時間をまとめて吸収してしまいます。

• 手動コードレビュー（52%）：レビュー担当者は、人間が書いたコードよりもはるかに大量のAI生成コードを処理することを強いられており、その量は増加の一途をたどっています 。
• セキュリティテスト（51%）：AI生成コードは、手書きのコードには見られなかった新たな種類の脆弱性を生み出します。特に、依存関係の注入、ハードコードされたシークレット情報、古い推奨ライブラリの利用などが顕著です 。
• 生成コードの修正・再作業（48%）：半数近くのチームが、AIの出力をリリース前に修正、リファクタリング、または完全に書き直す作業に多大な時間を費やしていると回答しています 。

この現象には「Toil（苦役）の移動」という名前が付けられています。AIが面倒な作業を無くしたのではなく、その負荷を「コード作成」段階から「検証」「テスト」「修正」段階へと移動させたに過ぎないのです 。Black Duckの表現は率直です。「ほとんどの組織は、レビューし、保護し、管理できるよりも早く、AI生成コードを生産している」。

ガバナンスこそが投資対効果を決める

エンジニアリングリーダーがこのレポートを読み、即座に行動に移すべき教訓があるとすれば、それは次の一点に尽きます。ガバナンスこそが、AI投資の効果を何倍にも高める「倍率装置（ROI multiplier）」であるということです 。

AI利用を適切に管理できているチームと、そうでないチームの間にある差は、わずかなものではありません。それは、効率化の果実をしっかりと刈り取れるか、それとも指の間からこぼれ落ちるのを見ているだけかの違いです。

Black Duckの調査では、包括的なガバナンスの枠組みを持つ組織の90%が、AIコーディングツールによって「大幅な効率化」を達成したと報告しています。一方、体系的な監視体制を持たないチームで同じ結果を得られたのは、わずか44% でした 。

この文脈でのガバナンスとは、官僚主義的な手続きを増やすことではありません。どのツールを使うか、AI生成コードをどうレビューするか、どのセキュリティチェックを通過させる必要があるか、そしてその成果物の責任は誰が負うのか、といった明確なポリシーを定義することを意味します。「開発者が好きなツールを自由に使う」状態と、「開発者が、監査可能な構造化されたパイプラインの中で承認済みのツールを使う」状態の違いです。

忍び寄る「シャドーAI」のリスク

ガバナンスの難易度をさらに高めているのが、シャドーAIの台頭です。これは、開発者が会社のポリシーに反して、あるいはそれを知らずにAIツールを使用してしまう現象です。Black Duckは、回答組織の18%が、シャドーAIを重大な未管理リスクとして認識していることを明らかにしました 。Cursor、Windsurf、Claude Codeといったツールが、調達やセキュリティレビューを経由せずに個々の開発者レベルで導入されてしまうと、組織は自社の攻撃対象領域に対する可視性を失います 。

サプライチェーンリスク：AI生成コードは何を「継承」するのか

ガバナンスの欠如が具体的な脆弱性へと変わるのが、サプライチェーンの領域です。Black Duckの一連の調査（関連する2026年のOSSRAレポートを含む）は、AIコーディング支援ツールに特有の、相互に関連する3つのリスクを浮き彫りにしています。

ライセンスのロンダリング
AIアシスタントはオープンソースのリポジトリを学習しているため、コピーレフト（著作権継承義務）を含むソースからコードの断片を生成しても、元のライセンス情報を保持しない可能性があります 。2026年のOSSRAレポートによると、監査対象コードベースの3分の2にライセンスの競合が存在し、これはレポート史上最悪の水準です 。組織は、自分たちが使用する法的権利を持たないコードを、気付かぬまま出荷している可能性があります。

依存関係の爆発的増加
コードベースあたりのオープンソースコンポーネントは前年比で30%増加し、平均的な脆弱性の数は107%も急増しました 。AIコーディング支援ツールは、より広範な学習コーパスから、より高速に解決策を構成するため、この傾向を加速させます。つまり、AIが生成した一つの機能が、開発者が明示的に選択していない依存関係を大量に引き込む可能性があるのです。

コンプライアンスの空白地帯
AI生成コードに対して、知的財産権、ライセンス、セキュリティ、品質を包括的に評価している組織は、全体のわずか24% に過ぎません 。これは、4分の3の組織が「当社は今、どのような法的・セキュリティ上の義務を負ったのか？」という問いに、確実に答えられないことを意味します。

「AIは使わざるを得ないが、信頼もできない」開発者の葛藤

Black Duckの調査結果は、単独で存在しているわけではありません。同時期に発表された複数の独立した調査が、この信頼問題をより詳細なデータで補強しています。

• Sonarの「2026 State of Code Developer Survey」（1,100人以上の開発者を対象）によると、開発者の96%が、AI生成コードの機能的な正確性を完全には信頼していません 。しかし、そのコードをコミットする前に常に検証している開発者は、わずか48% に留まっています。つまり、開発者自身が信頼していないコードが、定期的に本番環境に送り出されているのです 。
• Stack Overflowの「2025 Developer Survey」（49,009人が回答）では、AIの精度に対する信頼度が1年で40%から29%に低下しました。積極的に「不信」を抱く開発者は46%に上り、AIへの好意的な見方も72%から60%に減少しています 。
• Harnessの「State of AI-Driven Software Releases 2026」（エンジニアリングリーダー500人を対象）では、57%がいまだにAI生成コードの全行に対して「ヒューマン・イン・ザ・ループ（人間による介在）」レビューを必要とし、29%はAIアシスタント導入前よりもコードレビューに多くの時間を費やしていると回答しています 。

これらの調査結果に共通するのは、驚くほど一貫した構図です。開発者はもはやAIツールなしでは仕事ができない一方で、その出力を完全には信頼できないのです。コード生成速度と検証精度の間のギャップが、新たな最大のボトルネックとなっています。

Noma SecurityのCISOであるDiana Kelley氏は、この中核的な緊張関係を端的に言い表しています。「より速いコードが、より安全なコードと同じ意味を持つわけではありません」。

「ガバナンスのある現場」は何が違うのか

30%の成功事例から、Black Duckは具体的な処方箋を導き出しています。完全なガバナンスを持つ組織と、そうでない組織を分けるのは、以下のような具体的な施策です。

1. 構造化されたAIガバナンスの枠組み：単なる非公式なガイドラインではなく、ツールの承認、成果物のレビュー、説明責任を定めた、文書化され強制力のあるポリシー 。
2. パイプラインに統合されたレビューゲート：46%の企業がいまだに依存している「人手によるセキュリティテスト待ち行列への受け渡し」から脱却し、すべてのAI支援によるコミットに対して自動化された品質・セキュリティチェックを実行する 。
3. デプロイ後の継続的な監視：Black Duckは「リスクはソフトウェア開発ライフサイクル全体で導入され、発見され、管理されなければならないため、シフトレフトだけの戦略はもはや不十分である」と指摘しています 。
4. セキュリティツールチェーンの合理化：回答者の71%以上が、ツールの無秩序な増加を大きな摩擦の原因として挙げています。安全にAIをスケールさせるには、より少数の、より統合されたツールに集約することが前提条件となります 。

結論：ガードレールを先に作らなければ、得た時間は検証で溶けていく

Black Duckのレポートは、AIコーディング支援ツールの使用に反対しているわけではありません。そうではなく、見合ったガバナンスなしにAIを使うことは、自家撞着（じかどうちゃく）に陥る行為だと主張しているのです。

開発チームの97%が前例のない速度でコードを生成している一方で、それを管理する監視基盤を持つチームがわずか30%に過ぎないという現状は、業界全体が「現金化できない小切手」を書きまくっているようなものです。

ガバナンスと効率化の相関関係（90%対44%）は、ビジネス上の必然性を明白に示しています。最初にガードレールを構築した組織だけが、AIが約束する真の生産性を手に入れることができるでしょう。そうでない組織は、キーボードの前で節約した時間が、レビュー待ち行列で溶けていくという事実を、これからも繰り返し思い知ることになるはずです。