AI開発時代のセキュリティとは

AI開発時代のセキュリティとは、AIを使って作るソフトウェアと、AIを組み込んで動くソフトウェアの両方を、資産・脅威・権限・責任の観点から守る活動である。

AIはセキュリティをまったく別物にしたわけではない。認証・認可・入力検証・ログ・暗号化・脆弱性管理の重要性は変わらない。変わったのは、ソフトウェアが自然言語、外部ドキュメント、生成コード、ツール実行、エージェントの判断を扱うようになり、攻撃面が広がったこと。

従来のWebアプリでは、攻撃者がHTTPリクエスト、Cookie、ファイルアップロード、APIパラメータを操作した。AIアプリではそれに加えて、プロンプト、RAGの参照文書、モデル出力、エージェントのツール呼び出し、開発者がAIに渡す社内情報も攻撃対象になる。

何が変わったのか

AIは「入力を解釈する部品」であり、「権限を持つ部品」にもなりうる。
そのため、AIを便利な補助輪として扱うだけでなく、信頼できない入力を処理する実行経路として設計する必要がある。

AI開発時代に守るべき資産は、データベースやAPIキーだけではない。

個人情報、契約情報、医療情報、決済情報、社内文書、顧客問い合わせ履歴など。
RAGや要約機能でLLMに渡すと、ログ、学習、外部送信、権限越境のリスクが生まれる。

AIエージェントがメール送信、チケット作成、DB参照、ファイル更新、クラウド操作を行う場合、そのエージェントは実質的な操作主体になる。
モデルそのものではなく、モデルに接続されたツール権限が被害範囲を決める。

AIコーディング支援に、未公開コード、設計資料、秘密情報、社内API仕様を渡す場面が増える。
開発者のPC、IDE拡張、エージェント実行環境、CI/CDの権限が新しい保護対象になる。

AIがレビュー、診断、優先度付け、承認支援を行う場合、誤った判断が業務リスクになる。
なぜその判断を採用したのか、誰が承認したのか、後から追える状態が必要になる。

AI固有のリスクはあるが、土台は従来のセキュリティである。

既存の原則	AI時代での意味
最小権限	エージェントのツール権限、RAGの検索範囲、APIトークンを最小化する
多層防御	プロンプト対策だけでなく、認可、出力検証、監査ログ、実行前承認を重ねる
入力を信頼しない	ユーザー入力だけでなく、Webページ、PDF、社内文書、モデル出力も信頼しない
Security by Design	AI機能を後付けせず、設計段階で信頼境界と失敗時の挙動を決める
Assume Breach	プロンプトインジェクションや情報漏洩が起きても被害を限定する

「AIだから特別」ではなく、「AIが既存の失敗を増幅する」と捉えると学習順を間違えにくい。

LLMは自然言語を理解しているように見えるが、セキュリティ設計上は信頼境界の内側に置きすぎてはいけない。
モデルの出力をそのままSQL、HTML、シェル、認可判断、メール送信に接続すると、従来のインジェクションと同じ構造の問題が起きる。

AIエージェントは権限を与えるほど便利になる。
しかし、権限が広いほどプロンプトインジェクション、誤判断、ツール悪用の被害も広がる。最初に決めるべきなのは「何ができるか」ではなく、「失敗しても何が起きないようにするか」である。

AIを使う開発は速い。セキュリティレビューを最後にまとめて行う運用では追いつきにくい。
設計、実装、レビュー、CI、運用の各地点に小さな確認を埋め込み、開発者自身がリスクを言語化できる状態を作る必要がある。

このシリーズは、AI開発時代にセキュリティを学ぶための地図である。

個別の攻撃手順を深掘りするよりも、開発者が設計・レビュー・学習計画で使える判断軸を重視する。