更新日: 2026年7月17日

AIを「コアエンジン」に置く時代
自社開発AIアプリに潜む、新しいセキュリティの死角

ここ数年でLLM（大規模言語モデル）の導入ハードルは劇的に下がった。金融、保険、医療、メディア——業界を問わず、AIをプロダクトのコアエンジンに据えたアプリやSaaSが、次々と生まれている。本コラムは、その流れの真ん中にいるAI搭載SaaSベンダー——自社プロダクトにLLMを組み込んで顧客に届ける側——の視点から、内製AI時代に立ち上がってきた新しいリスクと、その守り方を整理する。

いま、あらゆる業界で「AIを内製する企業」が量産されている

API一本を叩けば、要約も、対話も、コード生成も、自社プロダクトに組み込める。その結果として起きているのは、単なる「AIツールの利用」ではない。AIを事業そのものを動かす心臓に据えた製品が、業界を問わず次々と生まれている。

これは大きな地殻変動だ。かつてAIは「便利な追加機能」だったが、いまや事業の心臓になりつつある。心臓を新しく手に入れた以上、それを狙う攻撃と、それを守る仕組みもまた、新しくなければならない。

「作って売る」側に生まれた、これまで存在しなかったリスク

従来のセキュリティは、ネットワークやエンドポイント、アプリケーションの脆弱性を守ることに主眼が置かれてきた。しかし、LLMを組み込んだプロダクトには、従来のWAFやEDRだけでは捉えきれない、質の異なる脅威が加わる。代表的なものを挙げる。

プロンプトインジェクション／ジェイルブレイク

ユーザーの入力そのものが攻撃ベクトルになる。巧妙に設計された指示文でモデルの挙動を乗っ取り、本来出してはいけない情報を吐き出させたり、想定外の動作をさせたりできる。入力＝データであると同時に、入力＝命令にもなり得るのがLLMの本質的な難しさだ。

Denial of Wallet（DoW／財布の枯渇攻撃）

LLMはトークン従量課金であることが多い。大量のリクエストを浴びせられれば、サービスが落ちる前に請求額が跳ね上がる。従来のDoS（サービス停止）に加えて、「稼働させたまま金銭的に消耗させる」という新種の攻撃が成立してしまう。高トラフィックのGenAIアプリでは1日あたり数千ドル規模の外部API費用が発生し得るため、事業インパクトは直接的だ。

機密データの漏えいとコンプライアンス違反

ユーザー入出力に個人情報や機密情報が混ざり、それが外部LLMやベクトルDBに渡ってしまえば、それだけで規制違反になり得る。特に規制産業では致命的だ。

ブランド毀損につながる出力

不適切・有害・ブランドにそぐわない生成結果が、そのまま顧客の目に触れる。「出力＝顧客体験」の領域では、これは信頼の問題に直結する。

いずれも、「AIを使うこと」ではなく「AIを製品として提供すること」で初めて顕在化するリスクだ。作って売る側になった瞬間、守るべき対象が一段増える。

なぜ規制産業とAI搭載SaaSベンダーが最前線なのか

こうしたリスクが最も鋭く効いてくるのが、規制の厳しい産業で自社／顧客向けにLLMアプリを内製している企業だ。金融・保険・医療がその筆頭に挙がる。理由は明快で、データ漏えい防止とコンプライアンス要件が厳しく、しかも顧客企業ごとに別の鍵・別のポリシーで管理する「データ主権」への対応が求められるからだ。

もう一つの最前線が、AIを組み込んだSaaS／プラットフォームを提供するベンダーである。「作って売る」側は、顧客向けAIの入出力を守る責任を製品の一部として負う。ここを疎かにすれば、それはもう機能不足ではなく、製品の欠陥として扱われる。

海外では、この領域を狙った専業プレイヤーが台頭している。イスラエル発のPrompt Security（2025年8月にSentinelOneが買収に合意）は、「自社開発AIアプリ（Homegrown Apps）」の保護を看板に掲げ、金融・保険とヘルスケアの2業種に専用ページを設けて主戦場に据えている。公開情報では、メディア（The New York Times）、金融プラットフォーム（10x Banking）、ヘルスケア（St. Joseph’s Healthcare Hamilton）といった名前が挙がる。いずれも「自社でAIアプリを作る／顧客向けAIを出す」プロファイルの企業だという点が象徴的だ。

守り方の要は「自社に合わせて選び、モデルに縛られず、多層で見る」

AI搭載SaaSベンダーは何を基準に防御を設計すべきか。海外先行事例が示す勘所は、大きく三つに集約できる。

第一に、導入方式に選択肢があること

防御の組み込み方には、通信を経由させるゲートウェイ（プロキシ）型と、アプリケーションにAPIで組み込む型がある。前者は既存のベースURLを向け替える形で比較的少ない改修から始めやすく、後者は制御の粒度や柔軟性に優れる。ただしAPI組み込み型は「どこで・何を・どう検査するか」というアプリケーション設計を伴うため、決して「差し替えれば即完了」という単純な話ではない。要は、スピードと柔軟性のトレードオフを理解したうえで、自社のアーキテクチャや要件に合わせて方式を選べることが、実務上の要になる。