AI がコードを書く時代は、単に開発が速くなるだけでは終わりません。Apiiro は、いまの焦点は「AI が何を作るか」だけでなく、「その AI が何を漏らし、どこに危険を持ち込むか」に移っているのだと訴えています。この記事は、そうした agentic development、つまり自律的に動く coding agent を前提にした開発環境をどう守るべきかを、かなり広い視点で説明するものです。単なるセキュリティ製品の紹介というより、AI 開発そのものの前提が変わったという宣言に近い内容でした。
元記事の中心にあるのは、Apiiro が「Secure your agentic development」と掲げ、AI アプリケーションのセキュリティを開発の前工程から後工程まで一体で扱おうとしている点です。サイト内には「AI AppSec Agent. Built for Enterprise Security.」や「Protect your entire AI development environment.」といった文言が並び、単体のスキャンツールではなく、開発環境全体を包み込む構想が前面に出ています。
その中で目立つのは、製品や機能の並び方です。Apiiro はホーム、Platform、Product、Solutions といった通常の導線に加えて、Protect、Prevention、Auto Fix、Secrets Security、API Security、AI SAST、AI SCA、ASPM、Software Graph、Risk Graph、Integrations など、多数のページを用意しています。名前から読み取れるのは、脆弱性を見つけるだけではなく、コードができる前からリスクを防ぐこと、そして見つかった問題を自動で修正することまで視野に入れている点です。紹介文でも「prevent risk before code exists, AutoFix the backlog, and protect the coding agents and supply chain」と表現されていました。ここでいう supply chain は、ソフトウェアの依存関係や配布経路を含む、開発から出荷までの一連の流れを指します。
記事のタイトルには「coding agents leaking secrets」とあり、AI エージェントが秘密情報を漏らす危険が主題に置かれています。元記事はこのリスクを、単なる一時的な事故ではなく、AI が開発に深く入り込んだことで起きる構造的な問題として扱っています。だからこそ、Secrets Security が独立した領域として並び、OAuth Consent や Integrations まで含めて守る対象にしているのでしょう。つまり Apiiro の主張は、AI を使う開発ではコードの品質管理だけでは足りず、認可、接続、依存関係、修正自動化までを横断して見なければならない、というものです。
この記事で面白いのは、漏えいや脆弱性を「成果物の中の問題」としてではなく、「開発プロセスの中で AI が触ってしまうもの」として扱っている点です。普通の AppSec は、完成したコードや依存パッケージを監視する発想になりがちです。でも agentic development では、AI がターミナル、リポジトリ、認証情報、設定ファイルに触れる。そこで漏れるのは、完成後の成果物だけではなく、開発の途中にあるはずの秘密です。私はここが本質だと思います。
しかも、記事全体の語り口はかなり強めです。単に「AI は危ない」と言うのではなく、AI 開発環境そのものを守る control plane が必要だ、と持っていく。これはマーケティングとしては自然ですが、同時に現実でもある程度正しい。コード生成 AI が普及すると、開発者は便利さと引き換えに、プロンプト、トークン、API key、CI/CD の権限といった境界を曖昧にしやすいからです。人間が手で確認していたころより、情報の出入り口が増える。そこで「秘密情報の漏えい」を個別の事故扱いにすると追いつかない、という感覚はかなり筋が通っています。
もうひとつ引っかかったのは、Apiiro が「見つける」より「直す」をかなり前に出していることです。Auto Fix という名前からも分かる通り、検知だけで終わらず backlog を自動で片づける方向へ寄せています。これは便利そうに見える一方で、かなり難しい設計です。セキュリティ修正は、単純な置換で済まないことが多いからです。依存関係の更新ひとつ取っても、動作確認や例外処理、組織内の承認が必要になる。
だから私は、ここには二面性があると思います。ひとつは、修正の遅れが最大のリスクになる現場では自動修正が強い味方になること。もうひとつは、修正の自動化が進むほど、どこまでを機械に任せるのかという運用設計が重要になることです。たとえば secrets が含まれる pull request を自動で止めるのか、警告だけ出すのか、あるいは API Security と連携して一括で差し戻すのか。ここを曖昧にしたまま Auto Fix だけ導入しても、現場ではたぶん回りません。
Apiiro のページ一覧を見ると、Software Graph と Risk Graph が両方並んでいます。私はこの並びに少し注目しました。Graph という言葉は、単なるダッシュボードよりも、関係性を追う発想です。どのコードがどの依存関係に結びつき、どの権限や secret に接続し、どこでリスクが増幅されるのか。AI が開発のあちこちに入るほど、点ではなく線や面で把握しないと追いつかない。そういう問題意識が見えます。
一方で、こうした統合プラットフォームは、導入する側にとっては便利でも、既存ツールとの重複を起こしやすい面もあります。SAST、SCA、Secrets scanning、ASPM を全部ひとつにまとめると、見た目はすっきりする。でも大企業ほど、既存のセキュリティ基盤がすでにあるはずで、そこに新しい control plane を足すのは簡単ではないはずです。だから Apiiro の提案が刺さるかどうかは、機能の多さよりも、既存の開発フローにどれだけ自然に入り込めるかで決まると思います。
最後に、この記事は開発者向けというより、むしろ経営層やプラットフォームチームに向けたメッセージとして読めました。なぜなら、「agentic development を安全にする」という話は、個々のエンジニアに気をつけろと言うだけでは実現しないからです。必要なのは、OAuth Consent の管理、Integrations の統制、Secrets の検査、AI のふるまいの可視化、そして問題が起きた時にすぐ直せる運用です。つまり技術の問題であると同時に、組織設計の問題でもある。
私は、この方向性はかなり今っぽいと思います。AI 開発をめぐる議論は、生成精度や開発速度ばかりに寄りがちですが、実務では「誰が何にアクセスできるのか」「どこで secret が混ざるのか」「誰が修正の責任を持つのか」が先に効いてきます。Apiiro はそこを真正面から取りに行っている。誇張気味に見える部分もありますが、少なくとも“AI がコードを書く”ことより、“AI が安全に開発へ組み込まれる”ことのほうが難しい、という現実はよく捉えていると思います。
