Claude Opus 4.5 Thinkingは最高評価を獲得したが、生成されるコードのうち正しく安全なのは、わずかに半分を上回る程度にとどまる。出典: BaxBench.com
ある著名なテック界の人物の言葉を借りれば、ソフトウェアが世界を食い尽くしているのかもしれない。しかし2025年には、AIがソフトウェア開発を食い尽くした。いまやプロのプログラマーの大半が、大規模言語モデル（LLM）をコード提案、デバッグ、さらには「vibe coding」にまで利用している。
それでも課題は残る。開発者がAIエージェントを使ってアプリケーションを構築し、AIサービスを開発・本番パイプラインに統合し始める一方で、コードの品質—とりわけコードのセキュリティ—には大きなばらつきがある。グリーンフィールドのプロジェクトでは、既存コードの書き換えよりも生産性とセキュリティの結果が良くなる可能性がある。 特に古いコードの脆弱性が引き継がれてしまう場合はなおさらだ。生産性の向上がほとんど見られない企業もあれば、大きな恩恵を得ている企業もある。
アプリケーションセキュリティ企業Veracodeのチーフ・セキュリティ・エバンジェリストであるChris Wysopal氏は、ソフトウェア開発者はより速く動いているが、知識や実践次第では安全なコードを生み出せていない可能性があると述べる。
AI支援によるコーディング、リファクタリング、アーキテクチャ生成はコード量と複雑性を劇的に増大させるため、組織はより多くのソフトウェアをより速く出荷するようになる一方で、人間の可視性は低下すると同氏は説明する。
Wysopal氏によれば、2026年にはソフトウェア開発者は、AIツールやエージェントが、コード内のバグ検出から欠陥のトリアージ、セキュリティ改善に至るまで、開発パイプラインを変革することを見込むべきだという。
「要点は、チームがツールを成熟した形で使いこなさなければならないということです」と同氏は言う。
新しいAI開発には新しいセキュリティを
すでに開発者は、AIによるコード生成と分析をワークフローに完全に統合している。開発ツールメーカーが2025年10月に実施した調査では、JetBrainsが、約2万5,000人の回答者のうち85%がコーディングやソフトウェア設計の作業で定期的にAIツールを使用していることを発見した。Googleが実施した同様の調査では、ソフトウェア開発の専門職の90%がAIを採用していることが分かった。
それでも、セキュリティは引き続き問題だ。現在、AnthropicのClaude Opus 4.5 Thinking LLMは、生成コードのセキュリティを測定するために学術・産業界の研究者グループが作成したBaxBenchベンチマークで最高評価を得ている。とはいえ研究者によれば、このLLMがセキュリティの促し（プロンプト）なしで安全かつ正しいコードを生成できるのは56%にすぎず、既知の特定の脆弱性を避けるよう指示した場合でも69%にとどまる。これは実運用の開発にとっては非現実的な但し書きだという。
同じ脆弱性発生率のままコード生成量が増えれば、修正すべきバグも増える。多くの開発チームはAI生成コードの手直しを余儀なくされ、それがAIで強化された開発者が潜在的に達成し得る30%〜40%の生産性向上のうち、15〜25ポイント分を食い潰してしまうと、スタンフォード大学の研究は示している。
2026年には、開発パイプライン—特に開発者がAIシステムとやり取りする部分—にセキュリティツールを組み込むことが必要になる。まず、LLMを使ってコードを生成する開発者は、少なくともセキュリティを優先する標準プロンプトを含める必要がある。そうすることで安全なコードになる可能性はしばしば高まる。Claude Opus 4.5 Thinkingでは、一般的なセキュリティ注意喚起により、安全かつ正しいコードが66%の確率で得られたのに対し、注意喚起なしでは56%だった。（ただし、セキュリティ注意喚起はOpenAIのGPT-5の性能を低下させたようで、提案された解決策のうち正しいものが減った。）
静的スキャナーのような従来型ツールや、新しいAIベースのセキュリティスキャナーを追加すれば、性能はさらに改善し得る。しかし、古いスキャナーでは新しいAI特有の攻撃の一部を検出できないと、セキュア開発プラットフォームSnykの最高イノベーション責任者Manoj Nair氏は言う。Nair氏によれば、出現している攻撃の種類は、セキュリティ文脈の欠如、AIのハルシネーション、確率的システムに伴う問題に起因している。
「[これらのAIシステムは]決定論的ではなく、確率的です」とNair氏は言う。「それはさまざまな方法で悪用され得るため、まったく異なるやり方で保護する必要があります」
あらゆる場所にAI
VeracodeのWysopal氏によれば、開発ツールメーカーはプラットフォーム全体にAIエージェントや機能を組み込んでいる。適切に設定されれば、これらのAIエージェントはコード生成にとどまらず、安全でないコードを検出して安全な代替案を自動的に提案し、企業が定めたセキュリティポリシーを強制し、危険なパターンがリポジトリに到達する前にブロックするようになるという。
Wysopal氏によれば、開発者は統合開発環境、継続的インテグレーション（CI）パイプライン、コードレビューのワークフローに組み込まれたAIシステムと、安全にやり取りする方法を学ばなければならない。
「開発者はAI生成コードを潜在的に脆弱だと扱い、人間が書いたコードと同様にセキュリティテストとレビューのプロセスに従う必要があります」とWysopal氏は言う。「テストと、AI生成コードの修正に向けた自動化パイプラインを用意すべきです」
重要な構成要素の一つが、モデル・コンテキスト・プロトコル（MCP）サーバーだ。MCPサーバーは、LLMや他のAIシステムをデータベースや企業リソースへと結び付ける役割をますます担っており、保護が必要な次世代アプリケーションの重要部品になっている。ところが、サーバーが無防備なまま放置されることも多い。7月に実施されたMCPサーバーのスキャンでは、公開インターネットに接続された1,862台が発見され、そのほとんどが認証なしだったことが示された。
企業は、アプリケーションやサービスに含まれるこれらAIコンポーネントに関してポリシーを定める必要があると、SnykのNair氏は言う。
「シャドーエージェントは新しいシャドーITです。開発者がどのツールやどのMCPサーバーを使っているのか分からなければ、どうやってそれらを守るのですか？」と同氏は言う。「エージェント的な盲点という点で、人々が見つけているものには驚かされます。私たちは、厳しく規制された環境のコードベースにMCPサーバーが組み込まれているのを見つけました」
AIを盲点にしない
AIコンポーネントが開発者のアプリケーション作成を支援するだけでなく、アプリケーションの重要部品にもなりつつあるため、開発者を支える新たな能力を整備する必要がある。Nair氏によれば、企業はソフトウェア部品表（SBOM）を超えて、特定の検証済み技術に焦点を当てたAI部品表（AI BOM）を作成し、開発者がそれらの範囲外へ逸脱しないようにすべきだという。
例えばAIコーディングプラットフォームCursorは、AIエージェントを使ってプログラムの実行時状態を検査できる機能を導入したばかりだ。デバッグモードでは、エージェントがコードに計測用の仕込み（インストゥルメンテーション）を行い、実行時出力をログに記録し、そのログを分析して修正案を導き出せる。
Snykのような他のツールメーカーは、あらゆる段階でセキュリティチェックを統合することに注力している。Nair氏によれば、セキュリティを重視する開発チームほど、低品質で安全でないコードの手直しをせずにAIの生産性メリットを得られる可能性が高い。
「これらのAI技術を最初から安全に採用することは、ソフトウェア[を開発できる]速度を変えるだけです」と同氏は言う。「エージェントを作り始めた時点からメリットは得られますが、同時にセキュリティのためにやらなければならない作業が非常に多いのも、まさにその地点なのです」
翻訳元: https://www.darkreading.com/application-security/coders-adopt-ai-agents-security-pitfalls-lurk-2026
