実務ガイド

AIプロジェクトのセキュリティ要件定義書ひな形

admin · · 最終更新 2026年5月17日 · 14 min read

Picsum ID: 125

AIプロジェクトのセキュリティ要件定義書ひな形

AI／LLMを組み込んだ業務システムは、従来の要件定義書テンプレートではカバーしきれない領域が広い。プロンプトインジェクション、モデル供給継続性、推論ログのPII、ハルシネーションの責任分界など、調達時にRFPで握っておかねば事故が起きる論点が多い[1][2][3]。本稿はIPA「セキュリティ要件定義書ひな形」[4]を基底に、NIST SP 800-160 Vol.1[5]、OWASP ML Security Top 10[2]、Microsoft SDL for AI[6]、英国NCSCのSecure AI Guidelines[3]を横串で参照し、情シス・開発・PMOがそのままベンダーへ提示できる10章構成、AI特有要件20項目、非機能の書き方、選定接続までを実装粒度で整理する。

AI要件定義の特殊性

従来の要件定義は「入力→決定論的処理→出力」が前提だった。LLM／生成AIは前提が3点異なる。第一に非決定性で、同じ入力でも出力が確率的に揺れるため「100%一致」のSLAは破綻する[7]。第二にサプライチェーン依存で、基盤モデルの挙動・価格・提供条件がベンダー都合で変わり、長期可用性を自社で担保しきれない[3][8]。第三に新しい攻撃面で、プロンプトインジェクション、間接インジェクション、データポイズニング、モデル抽出、メンバーシップ推論などSQLi級の標準攻撃が成立する[1][2]。これらを前提に機能・非機能・運用を明示的に分けないと、ベンダーは「仕様通り作った」で防御線を張る。

要件定義書の標準10章構成

IPAひな形[4]とNIST SP 800-160 Vol.1[5]を基に、AIプロジェクト用に再構成した10章テンプレートを示す。RFP添付・PoC契約・本開発契約のいずれにも転用可能。

章 記載内容 典拠
1. 概要・スコープ 業務目的、対象ユーザー、AI責任範囲（assistive／autonomous）、HITL要否 IPA[4]／SDL[6]
2. 脅威モデル STRIDE＋OWASP LLM／ML Top 10で脅威リスト、リスクマトリクス OWASP[1][2]
3. 機能要件（AI） 入出力、許容生成範囲、拒否要求、ツール権限、RAG参照範囲 SDL[6]
4. 非機能要件 可用性、応答時間、スループット、コスト・トークン上限、再現性 NIST[5]
5. データ要件 データ分類、PII処理、保持期間、削除権、越境移転 個情法[9]／GDPR[10]
6. モデル管理 バージョニング、入替手順、切戻、評価指標、モデルカード NIST AI RMF[8]
7. セキュリティ 認証認可、暗号化、入出力検証、インジェクション対策、レート制限 OWASP[1]／NCSC[3]
8. 監査・ログ 推論ログ保存範囲、PIIマスキング、保存期間、改ざん耐性 NIST[5]／SDL[6]
9. 運用・インシデント 監視指標、アラート閾値、エスカレーション、ロールバック、停止権 NIST AI RMF[8]
10. 受入・退出条件 レッドチーム合格基準、SLA違反対応、契約終了時のデータ・モデル返却 NCSC[3]

AI特有のセキュリティ要件20項目

OWASP LLM Top 10[1]、ML Top 10[2]、SDL for AI[6]、NCSC Guidelines[3]、NIST AI RMF[8]を統合し、要件定義書「7章」に貼れる粒度で20項目に集約した。

# カテゴリ 要件（要約） 典拠
1 入力検証 RAG／Web取得含め間接インジェクション対策（プロンプト分離、デリミタ、サニタイズ）[1] LLM01
2 出力検証 バックエンド処理前にスキーマ検証・許可リスト・SQL／シェルエスケープ[1] LLM02
3 権限分離 エージェントのツール／API／DBは最小権限、毎呼び出し承認[1][6] LLM07
4 機密漏洩 Few-shotにPIIを含めない、出力フィルタでPII検知[1] LLM06
5 サプライチェーン 基盤モデルのSOC2／ISO、データ保持・学習条項、終了通知を契約明記[3][8] LLM05
6 ポイズニング FT／RAG投入データの署名・整合性検証・差分レビュー[2][3] ML#1
7 モデル抽出 レート制限、クエリ異常検知、確率分布非開示[2] ML#5
8 メンバーシップ推論 過学習防止、差分プライバシ、出力丸め評価[2] ML#4
9 敵対的入力 画像／音声／テキスト敵対的サンプル試験を受入基準化[2] ML#2
10 推論ログ プロンプト・出力・ツールコール・モデル版を保存、PIIはトークナイズ[6] SDL
11 監査証跡 WORM／ハッシュチェーンで改ざん耐性、90日＋契約期間保持[5] NIST
12 レート制限 ユーザー／テナント／全体でトークンと同時実行数を上限化[1] LLM04
13 自律性制限 金銭・PII・外部送信アクションはHITL承認必須[1][3] LLM08
14 説明可能性 参照ソース・信頼度・代替候補と「AI生成」表示[11] EU AI Act
15 ハルシネーション RAG根拠提示、信頼度閾値で抑制、不明領域は「分からない」明示[1][6] LLM09
16 PII処理 入力時DLP自動マスキング、出力時再検出、削除要求対応[9][10] 個情法
17 暗号化 TLS1.2＋／AES-256、モデル重みKMS、APIキーのシークレット管理[5][6] NIST
18 認証認可 SSO、ロール別プロンプト・ツール権限、IPアロウリスト[5] NIST
19 レッドチーム 受入時／モデル更新毎にインジェクション・脱獄・PII抽出試験、合格率を契約化[3][6] NCSC
20 有事停止権 発注者からモデル無効化・APIキー失効・ログ封鎖を一元実施するSLA[3] NCSC

非機能要件の書き方

AIシステムは「測定可能な数値」と「測定方法」をセットで書く必要がある。応答時間はトークンストリーミング開始までのTTFB、完了までのトータル時間、長文生成時の劣化を分けないと、ベンダーは平均値だけ提示しP95を隠す。可用性は基盤モデル提供者のSLAが支配的（OpenAI／Anthropic Enterpriseで99.9%程度）[12][13]であり、それ以上を書くなら複数モデルフェイルオーバ要件として再定義する必要がある。再現性はtemperature=0でもモデル更新で出力が変わるため「同条件で○%以上の意味的一致」と許容幅を明記。コスト上限はテナント別月次トークン上限と超過時挙動（ブロック／警告／降格切替）を記載。バイアス／公平性はEU AI Act第10条[11]でハイリスクAI評価義務化、属性別の精度差上限を書く。説明可能性はISO/IEC 42001[14]で組織要件化、曖昧表現でなく「上位3件のソース文書ID＋該当パラグラフを返す」まで具体化する。

ベンダー選定への接続

要件定義書はRFPに添付されベンダー比較表の軸になる。AI領域では「機能の有無」より「セキュリティ要件への対応度」と「契約条項の柔軟性」が差を生む。(1)基盤モデルベンダーとのDPAの写し開示[12][13]、(2)推論ログのスキーマ・保持・引渡条件、(3)モデル更新の事前通知期間（90日以上が望ましい）、(4)レッドチーム結果開示、(5)契約終了時のデータ・モデル返却証明、の5点を比較表化する。準拠フレームワーク（NIST AI RMF、ISO/IEC 42001、23894、EU AI Act）[8][11][14][15]のマッピング有無も問い、独自基準のみのベンダーは要注意。価格は「トークン課金＋運用工数」総コストで比較し、安価なベンダーほどログ／監査／HITLが薄いトレードオフを直視。PoCで「敵対的プロンプト50件・PII含有20件・業務シナリオ30件」をベンチマークし、結果を本契約SLAに引き写す運用が筋が良い。

情シス／PMO向けチェックリスト（5項目）

  1. 10章構成での網羅 — AI特化章（モデル管理、推論ログ、退出条件）が抜けていないか[4][5][8]
  2. 20項目の組込 — OWASP LLM／ML Top 10の該当項目を要件番号として明示、抜けは「該当なし＋理由」を記録[1][2]
  3. 非機能の数値化 — 応答時間・可用性・再現性・コスト・バイアス・説明可能性が測定方法込みで記述[8][11]
  4. 契約条項の事前合意 — DPA／モデル更新通知／ログ引渡／停止権／退出時データ返却の5項目を契約反映[3][12][13]
  5. 受入レッドチーム — 脱獄／間接インジェクション／PII抽出／敵対的入力の4カテゴリ各20件以上で合格基準を契約化[3][6]

打ち手

要件定義書ひな形を「会社のテンプレート資産」化するのが最短の打ち手。(1)10章構成をWord／Confluenceテンプレート化しAI案件は強制適用、(2)20項目を社内Wikiの「AIセキュリティ要件カタログ」として番号管理し案件ごと採否記録、(3)RFP添付の比較表（対応度、エビデンスURL、代替策）をフォーマット化、(4)PoCテストケース（敵対的プロンプト・PII・業務）を社内蓄積し再利用、(5)四半期ごとにOWASP・EU AI Act・ISO/IEC 42001の更新を反映するオーナーをCISO配下に置く。半年スプリントで整備すれば、調達品質が担当者依存から組織能力に移管される。

「AIシステムにおけるセキュリティとは、開発の最後に追加する機能ではなく、要件定義から設計・実装・運用・退役の全ライフサイクルに組み込まれた属性である。後付けで担保することは不可能に近い」[3]

結論3点

  1. AI要件定義書は従来の機能・非機能の枠だけでは足りず、モデル管理／推論ログ／退出条件／レッドチーム合格基準を独立章として持つ10章構成が必要。IPA＋NIST 800-160＋OWASP＋NCSCを横串参照すべき[1][2][3][4][5]。
  2. AI特有要件は20項目に集約可能。プロンプトインジェクション・出力検証・モデル供給・PII・有事停止権はRFP段階で必ず握り、標準フレームワーク番号（LLM01等）を要件番号として明示する[1][2][6]。
  3. 非機能は数値と測定方法をセットで記述。可用性は複数モデルフェイルオーバで担保、再現性は「意味的一致率」、説明可能性は「ソース文書IDと該当箇所」まで具体化する[8][11][12][13]。

経営者視点：AIガバナンスを調達プロセスに埋め込む

経営層が直視すべきは、AIプロジェクト失敗の多くが「技術選定」ではなく「要件定義段階で論点を握れていなかった」ことに起因する点である。基盤モデルがブラックボックス・サプライチェーン依存・確率的振る舞いを持つ以上、後工程で防御を積み上げる従来型品質保証は通用しない。要件定義テンプレートと20項目カタログを社内資産化することは、CISO・PMO・調達の認知負荷を下げ、ベンダー交渉力を構造的に高める投資である。EU AI Act[11]とISO/IEC 42001[14]の本格運用を控え、「AIガバナンス体制が整備されている」ことは2026年以降の大型受注・上場審査・M&A評価の前提条件となる蓋然性が高い。経営判断は「禁止」でも「都度議論」でもなく、要件定義テンプレート＋ベンダー評価表＋PoCスイート＋契約雛形の4点を半期で整備し、案件のバラつきを構造的に潰す方向が筋が良い。CISO／CTO直轄で組成すべき全社イシューである。

参考文献

  1. OWASP. “Top 10 for LLM Applications v1.1.” https://owasp.org/www-project-top-10-for-large-language-model-applications/
  2. OWASP. “Machine Learning Security Top 10 (2023).” https://owasp.org/www-project-machine-learning-security-top-10/
  3. NCSC UK / CISA. “Guidelines for secure AI system development (2023).” https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
  4. IPA. 「セキュリティ要件定義書ひな形」「非機能要求グレード」. https://www.ipa.go.jp/security/
  5. NIST. “SP 800-160 Vol.1 Rev.1: Engineering Trustworthy Secure Systems (2022).”
  6. Microsoft. “SDL / Threat Modeling AI/ML Systems.” https://learn.microsoft.com/security/engineering/threat-modeling-aiml
  7. Bender, E. M. et al. (2021). “On the Dangers of Stochastic Parrots.” FAccT.
  8. NIST. “AI RMF 1.0 / Generative AI Profile (NIST AI 600-1, 2024).” https://www.nist.gov/itl/ai-risk-management-framework
  9. 個人情報保護委員会. 「個人情報保護法ガイドライン」「生成AI注意喚起（2023）」. https://www.ppc.go.jp/
  10. EU. “GDPR (Regulation 2016/679).” https://gdpr.eu/
  11. EU. “AI Act (Regulation 2024/1689).” https://artificialintelligenceact.eu/
  12. OpenAI. “Enterprise privacy / DPA / Trust portal.” https://trust.openai.com
  13. Anthropic. “Trust Center / Commercial Terms / DPA.” https://trust.anthropic.com
  14. ISO/IEC. “42001:2023 – AI Management System.” https://www.iso.org/standard/81230.html
  15. ISO/IEC. “23894:2023 – AI Risk Management Guidance.” https://www.iso.org/standard/77304.html
  16. MITRE. “ATLAS – Adversarial Threat Landscape for AI Systems.” https://atlas.mitre.org/
SHARE 𝕏 in f
編集部
Omamori AI 編集部
CISO・情シス・経営層向けに、AIセキュリティの一次情報を編集視点で整理

あわせて読みたい

記事の論点を、自社のリスク評価に

90秒の自己診断 or CISO/情シス向け月次レビュー（顧問契約）でアクションに繋げます。

無料 90秒 自己診断 顧問契約 詳細