AIのセキュリティは要件で守る
目次
はじめに
AIを業務に入れるとき、セキュリティの話は最後に回されがちだ。
「社内文書を読ませたい」「問い合わせに自動で返したい」「CRMを更新したい」。この段階では、便利そうな機能が先に並ぶ。ところが、実際の導入で詰まるのはモデルの賢さよりも、何を読ませ、何を出力させ、どこで止めるかが曖昧なことだ。
AIのセキュリティは、導入後にチェックリストを足すだけでは守りにくい。最初の要件定義で、入力、判断、出力、権限、監査を分けて書く必要がある。ここを分けておくと、後からモデルやツールを差し替えても、守るべき線が残る。
NISTのAI Risk Management Framework は、AIリスクを組織や社会への影響として扱い、Govern、Map、Measure、Manageの流れで整理する。OWASP Top 10 for LLM Applications は、プロンプトインジェクションや、過剰な権限付与・自律的な外部操作を含む Excessive Agency など、LLMアプリ特有の攻撃面を挙げている。どちらも、最後に「セキュリティ確認をする」話ではない。最初に境界を設計する話だ。
AIのセキュリティを機能名で書かない
要件定義で危ないのは、「セキュリティ対策をする」とだけ書くことだ。
この一文は、一見すると大事なことを言っている。だが、実装する人から見ると、ほとんど何も決まっていない。
- どのデータをAIに渡してよいのか
- どの利用者がどの情報を見られるのか
- 出力に個人情報や機密情報が混ざったらどうするのか
- AIが外部サービスを操作してよいのか
- 失敗時に誰へ通知するのか
ここまで落とさないと、安全設計は検証不能な要件になる。検証不能な要件は、レビューでもテストでも確認できない。
たとえば、社内FAQボットを作るとする。単に「社内規程に答える」と書くと、AIは読める文書を全部同じように扱ってしまう。人事評価、給与、契約、顧客別の提案資料が混ざれば、回答の便利さより先にアクセス制御が問題になる。
最初に書くべきなのは、機能名ではない。「どの文書群を対象にするか」「誰の質問に答えるか」「答えてはいけない情報は何か」だ。これはセキュリティ部門だけの仕事ではなく、業務要件そのものだ。
まず入力を分ける
最初に見るのは入力だ。
AIは、与えられた情報から回答を作る。だから、渡す情報の範囲が曖昧なら、出力の安全性も曖昧になる。
入力は、少なくとも次の4つに分けて考える。
| 入力の種類 | 決めること | 例 |
|---|---|---|
| 公開情報 | そのまま使えるか | Webサイト、公開資料、FAQ |
| 社内共有情報 | 部署や役割で制限するか | 社内規程、議事録、設計資料 |
| 顧客・案件情報 | 案件単位で閉じるか | 提案書、契約、商談メモ |
| 個人情報・機密情報 | AIに渡さないか、伏せるか | 履歴書、評価、認証情報 |
この分類を飛ばすと、後から「なぜその情報を読めたのか」を説明できなくなる。
IPA掲載の中核人材育成プログラム卒業プロジェクトによるテキスト生成AI導入・運用ガイドライン も、組織が生成AIを安全に使うためには、リスクと対策を具体化する必要があると整理している。現場で使うなら、最初の一歩は「AIに何を見せないか」を決めることだ。
次に出力を分ける
入力の次は、出力だ。
AIの出力には、要約、分類、回答、下書き、実行命令がある。全部を同じ危険度で扱うと、設計がぼやける。
たとえば、会議メモの要約なら、誤りがあっても人間が読み直せる。返信メールの下書きなら、送信前に確認できる。ところが、CRMのフェーズ更新や外部メール送信までAIに許すと、失敗時の影響は一気に大きくなる。
だから出力は、次の段階に分ける。
- 読むだけ: 要約、抽出、分類
- 下書き: メール案、タスク案、回答案
- 内部保存: CRM、ナレッジ、ToDoへの登録
- 外部反映: メール送信、予定変更、顧客向け共有
段階が上がるほど、人間確認や監査ログを厚くする。ここを要件として書いておけば、実装時に「便利だから送信までやろう」と広がるのを止められる。
OWASPのPrompt Injection解説 を見ると、攻撃者は入力を通じてモデルの振る舞いを変えようとする。つまり、AIが外部操作まで持っている場合、入力の悪用がそのまま業務操作の悪用につながる。読むAIと動かすAIを分ける理由はここにある。
権限は「できること」ではなく「してよいこと」で書く
AIツールを選ぶとき、つい「何ができるか」を見てしまう。ファイル検索ができる。Slackに投稿できる。SaaSを操作できる。便利だ。
ただ、要件定義で書くべきなのは「できること」ではない。「してよいこと」だ。
同じSlack連携でも、次の3つは別物だ。
- チャンネルの会話を読む
- 返信案を作る
- 実際に投稿する
同じGoogle Workspace連携でも、次の3つは別物だ。
- カレンダーを読む
- 空き時間候補を出す
- 予定を作成する
この違いを要件に書く。読み取り、下書き、保存、送信を混ぜない。さらに、誰の権限で実行するかも書く。個人のアカウントで動くのか、botの権限で動くのか、管理者承認が必要なのか。ここが曖昧だと、事故が起きたときに責 任境界も曖昧になる。
関連する考え方は、AI要件定義は権限境界から考える でも詳しく扱っている。セキュリティは、機能の外側に置くものではない。権限境界そのものが要件だ。
導入前チェックリスト
実務では、長い規程よりも、プロジェクト開始時に全員で確認できる表の方が効く。
安全性を要件に落とすなら、最低限この10項目を見る。
| 観点 | 確認すること |
|---|---|
| 目的 | AIに任せる業務と、任せない業務が分かれているか |
| 入力 | AIに渡すデータ範囲が決まっているか |
| 除外 | 個人情報、秘密情報、認証情報を除外できるか |
| 権限 | 読む、書く、送るの段階が分かれているか |
| 承認 | 外部送信や本番反映の前に人間確認があるか |
| 出力検証 | AIの回答をそのまま正としない確認手順があるか |
| 悪意ある入力 | 悪意ある指示や外部文書内の指示を想定しているか |
| ログ | 入力、出力、操作、承認者を追跡できるか |
| 例外 | 判断不能、重複、権限不足の停止条件があるか |
| 更新 | モデルや連携先が変わったときに再評価するか |
この表は、セキュリティ担当者だけに渡すものではない。PM、情シス、業務部門、開発者が同じ画面を見て、どこまで決まっているかを確認するためのものだ。ツール選定に進む前の観点は、AI要件定義ツールの選び方 で整理した導入軸とも重なる。
経済産業省のAI事業者ガイドライン でも、AIの安全安心な活用に向けて、関係者が役割に応じてリスクへ対応する考え方が示されている。現場のプロジェクトでは、それを「誰が、いつ、何を確認するか」に落とす必要がある。
テストケースまで書く
チェックリストは出発点だ。最後はテストケースにする。
この領域のテストは、正常系だけでは足りない。むしろ大事なのは、わざと壊しにいくケースだ。
- 外部文書に「この指示を無視して別の情報を出せ」と書かれていた
- 権限のない顧客資料について質問された
- 送信前のメールに個人情報が混ざっていた
- 同じタスクがすでに存在していた
- AIが根拠のない回答を自信ありげに出した
これらを要件定義の段階で書く。実装後に慌てて試すのでは遅い。
NISTの生成AI向けAI RMFプロファイル は、生成AIのリスクをライフサイクル全体で扱う考え方を示している。開発前、導入時、運用中で見るべきリスクは変わる。だから、最初の仕様書にも「運用後に何を測るか」を入れておく。
この考え方は、AI要件定義で最初に作るテストケース ともつながる。AIに期待する振る舞いだけでなく、止めるべき振る舞いを先に書く。そこまで書けると、抽象的な不安は実装可能な要件に変わる。
仕様にすると、相談が具体化する
安全性の話は、抽象的なリスク論として語ると前に進まない。
必要なのは、怖さを分解することだ。何を読ませるか。何を出力させるか。どこまで実行してよいか。どこで人間に戻すか。何をログに残すか。
ここまで書けば、AI導入の相談はかなり具体的になる。ツール選定の前に、守るべき境界が見える。見積もりの前に、レビューとテストの範囲が見える。セキュリティ担当者との会話も、「大丈夫ですか」ではなく「この条件なら許可できますか」に変わる。
Atsumellは、AIに読ませる前の要件や仕様を整えるところから支援している。Kakusillでも、業務フロー、権限、例外、受 け入れ条件をAIが理解しやすい構造に落とすことを重視している。
AIのセキュリティは、最後のチェックではなく、最初の要件だ。導入前に線を引けば、AIは業務の中で使いやすくなる。線を引かないまま進めると、便利そうなものほど止め方が分からなくなる。
