Gartnerは2027年までにエージェント型コーディングを使うチームの65%超がIDEを必須と考えなくなると予測する。だが本質的な変化はコードを書く人の範囲が広がることだ。開発会社の素人層、そして自覚のない非開発会社へとリスクは逓増し、AppSecが対象とする市場は開発組織の外側・下側へ拡大していく。
AIがコードを書く時代、AppSec市場は「開発会社の外側」へ広がる
Gartnerが興味深い予測を出している。
2027年までに、エージェント型コーディングを利用するエンジニアリングチームの65%以上が、IDEを「必須のもの」とは考えなくなる。コードを書く場所はIDEから離れ、統制、ガバナンス、検証は自動化されたプラットフォーム側へ移っていく、という見立てだ。
Publickeyでもこの予測が紹介されていた。
これは単に「開発者の道具が変わる」という話ではないと思う。
もっと大きい変化は、コードを書く人の範囲が広がることだ。
そして本当に危ないのは、AIでコードを書き始めた会社ではない。 自分たちがソフトウェアを作っているという自覚がない会社だ。
これまでAppSecの主な市場は、ソフトウェア会社、SaaS企業、SIer、内製開発組織だった。つまり、もともと開発体制があり、SAST、SCA、コードレビュー、CI/CD、脆弱性管理といった言葉が通じる世界である。
もちろん課題は多い。だが、少なくともそこには「セキュリティを考えるべき」という前提があった。
AIエージェントは、この前提を崩す。
最初に影響を受けるのは、既に開発をしている会社だ。
ここは読者にも分かりやすい。開発者がいて、GitHubがあり、CI/CDがあり、レビューもある。SASTやSCAを導入している会社も多い。
ただし、AIエージェントが入るとコード生成の速度が変わる。
人間が1日に書けるコード量を前提にしていたレビュー体制は、AIが大量の修正案、依存追加、設定変更、テストコード、IaCを生成する世界では追いつかない。さらに、AIを使うのは熟練エンジニアだけではない。若手、業務部門、外部委託、場合によっては非エンジニアも、自然言語でコードを作れるようになる。
つまり、コードを生む人数と速度が、セキュリティを理解してレビューできる人数を一気に追い越す。
ここで必要になるのは、「分かる人が最後に全部見る」仕組みではない。作る人が玄人でなくても、危険な依存、危険なコード、危険な設定を早い段階で止められるガードレールだ。
AppSecは、専門家向けの検査ツールから、開発フローそのものに埋め込まれた安全装置へ変わっていく。
次の変化は、いわゆる「素人層」の増加だ。
ここでいう素人とは、能力が低い人という意味ではない。セキュリティやソフトウェア運用を専門にしていない人、という意味である。
これまでもExcelマクロ、Access、ノーコード、RPAで、業務部門は自分たちの道具を作ってきた。だが多くの場合、それは社内の小さな自動化に閉じていた。
AIエージェントは、その境界を押し広げる。
APIを呼ぶ。データベースにつなぐ。SlackやTeamsと連携する。顧客データを扱う。社内ワークフローを自動化する。場合によっては、外部公開に近いアプリケーションまで作れてしまう。
問題は、作れることと、安全に運用できることは別だという点だ。
セキュリティを理解しないまま、本番に近いものを作る人が増える。依存パッケージのリスク、シークレットの扱い、認可の抜け、入力検証、ログ、監査、データ保持、脆弱性対応。これらを知らない人が、AIの助けでそれらしいシステムを作れるようになる。
この世界では、従来型のAppSec UXは重すぎる。
大量のアラートを出して、「あとは開発者が判断してください」では回らない。低ノイズであること。自動修正できること。依存関係を整理できること。優先順位が分かること。何をすればよいかが、セキュリティ専門家でなくても分かること。
AppSecのユーザー体験は、非専門家向けに再設計される必要がある。
本当にリスクが高いのは、非開発会社だと思う。
理由は、単に開発経験が少ないからではない。リスクが4つ重なるからだ。
第一に、AppSecの体制がそもそもない。
ソフトウェア会社なら、脆弱性診断、依存管理、コードレビュー、リリース管理という発想がある。完璧でなくても、問題を受け止める組織の器がある。
非開発会社には、それがないことが多い。
第二に、指摘を解釈できる人がいない。
脆弱性スキャンで何かが出ても、それが本当に危険なのか、誤検知なのか、今直すべきなのか、後でよいのか、判断できない。セキュリティ製品を入れても、運用できなければノイズになる。
第三に、シャドーAI開発で「何が作られているか」すら見えない。
業務部門がAIで小さなツールを作る。外部サービスをつなぐ。社内データを読み込ませる。便利だから広がる。だが情報システム部門は、それを知らない。セキュリティ部門も知らない。
これはシャドーITの再来ではない。
シャドーAI開発は、コード生成能力まで持ったシャドーITである。
第四に、「うちは開発会社ではない」という認識が、需要の自覚を遅らせる。
ここが一番危ない。
ソフトウェア会社なら、自分たちはソフトウェアを作っているという自覚がある。だからAppSecの必要性も理解しやすい。
しかしAI時代には、開発会社でなくてもソフトウェアを作る。問題は、本人たちがそれを「開発」と呼ばないことだ。
業務改善。自動化。AI活用。社内ツール。効率化。
名前は何でもいい。実態としてコードが生成され、データに接続され、業務を動かすなら、それはソフトウェアリスクである。
リスクが最大なのは、自覚が最小の場所だ。
ここで市場の大きさ——TAM（Total Addressable Market、その製品が理論上対象にしうる市場全体の規模）——の話をしておきたい。
AppSecのTAMは、かなり大雑把に言えば、これまで「ソフトウェアを作る会社」の数にほぼ等しかった。
AIが変えるのは、ここである。
コードを書く参入障壁が下がると、あらゆる会社がソフトウェア生産者になる。製造業、金融、医療、教育、小売、物流、士業、自治体。これまで「開発会社ではない」と考えていた組織が、AIエージェントを通じてコードを生む側になる。
つまりAppSecのTAMは、従来の開発組織の内側だけでなく、その外側へ広がる。
さらに、成熟した開発者だけでなく、非専門家、業務部門、AIに作らせる人たちへも広がる。市場は「外側」——従来の開発組織の外——へ、そして「下側」——セキュリティを専門としない作り手——へ広がっていく。
ただし、この新しい市場は成熟していない。
だから勝つのは、最も高機能な製品とは限らない。セキュリティ専門知識を前提にしない製品だ。オンボードが軽く、ノイズが少なく、修正方針が分かり、できれば自動修正まで進められるもの。開発者だけでなく、「開発者になってしまった人」にも使えるもの。
Aikidoのような開発者ファースト、即オンボード、低ノイズ、自動修正を重視する設計思想は、この流れと相性がよい。
ただし、ここで重要なのは「Aikidoが非開発会社向けになった」と言うことではない。
本質は逆だ。
市場の側が変わっている。
AIによってソフトウェアを作る人が増え、AppSecを必要とする会社が増え、しかもその多くはセキュリティ専門家を持たない。だから、これからのAppSecに求められる条件が変わる。
専門家だけが使えるセキュリティ製品では、広がる市場を受け止められない。
AIがコードを書く時代に必要なのは、コードを作る人がセキュリティを知らなくても、危険なものを作らせない仕組みだ。
AppSec市場は、ソフトウェア会社のための市場から、ソフトウェアを生み出してしまうすべての会社の市場へ変わり始めている。
Aikido Community Japan
公開日: 2026/6/14
最終更新: 2026/6/14
セキュリティの最新情報をお届けします。