AIセキュリティフレームワーク比較：NIST・OWASP・ISOの選び方

AIセキュリティのフレームワークは、ひとつ選べば済むものではありません。役割ごとに組み合わせて使うものです。経営の仕組みはISO/IEC 42001やAI事業者ガイドライン、リスクの考え方はNIST AI RMF、技術的な脅威はOWASPとMITRE ATLASが受け持ちます。この組み合わせ方を自社の状況に合わせて決めることが、選定の中心になります。

AIセキュリティフレームワークとは？なぜ1つでは足りないのか？

AIセキュリティフレームワークは、AIのリスクを洗い出し、管理し、対策するための共通の物差しです。ただし対象とする層が違うため、複数を組み合わせる必要があります。

従来の情報セキュリティでは、ISO/IEC 27001のような管理の仕組みを1つ入れれば、全体の土台をおおむね作れました。生成AIやLLM、AIエージェントでは事情が違います。経営としての責任の持ち方、モデル固有のリスク、プロンプトインジェクションのような新しい攻撃手法が、それぞれ別の文書で整理されているからです。

フレームワークは「ガバナンス」「リスク管理」「技術的脅威」の3層に分かれる

主なフレームワークは、経営管理・リスク評価・攻撃対策の3層のどれかを主に扱っています。まずどの層を扱う文書かを見分けることが選定の出発点です。

1つに絞ると「規程はあるが攻撃を防げない」か「対策はあるが責任者がいない」状態になる

1つのフレームワークだけで運用すると、ガバナンスと技術対策のどちらかが手薄になりやすいです。現場でよく見る失敗です。

たとえば社内規程をISO/IEC 42001に沿って整えても、RAGで参照する社内文書に悪意ある指示が仕込まれる「間接プロンプトインジェクション」への具体策は、規程の文言からは出てきません。反対に、OWASPのリストで技術対策を進めても、AIエージェントにどこまで権限を渡すかを決める責任者が決まっていなければ、対策の優先順位は担当者の判断に任されたままになります。AI推進の現場では、この「層のずれ」を早めに見つけて埋めることが求められます。

NIST AI RMF・OWASP・MITRE ATLAS・ISO/IEC 42001・AI事業者ガイドラインはどう違う？

5つの文書の違いは、発行主体・認証の有無・扱う層の3点です。認証を取れるのはISO/IEC 42001だけで、ほかは任意の指針や知識ベースです。

※公開時期は各発行主体の公式発表にもとづきます。どの文書も改訂が続いているため、導入時には公式サイトで最新版を確認してください（本稿の確認日：2026年11月2日）。

NIST AI RMFとISO/IEC 42001は「考え方」と「仕組み」の関係にある

NIST AI RMFはリスクの捉え方を示す文書で、ISO/IEC 42001はそれを組織で回す仕組みの要求事項です。役割が重なることはほとんどありません。

NIST AI RMFは、Govern（統治）・Map（文脈の把握）・Measure（測定）・Manage（対処）の4つの機能でリスク管理を整理しています。一方、ISO/IEC 42001はISO/IEC 27001と同じマネジメントシステム規格の構造をとっていて、方針・役割・内部監査・マネジメントレビューといったPDCAの要求事項を定めています。すでにISMSを運用している企業なら、42001は既存の仕組みに追加する形で入れやすいのが利点です。その代わり、認証の取得・維持には審査対応の工数がかかります。

OWASPとMITRE ATLASは「守る側のチェックリスト」と「攻める側の地図」

OWASPは開発者が確認すべき脆弱性の一覧で、MITRE ATLASは攻撃者の手口の体系です。片方を見るだけでは脅威の把握に抜けが出ます。

OWASP Top 10 for LLM Applications 2025年版は、LLM01のプロンプトインジェクション、LLM02の機密情報の漏えい、LLM06の過剰なエージェンシー（Excessive Agency）など10項目を挙げています。設計レビューやテストの観点として使いやすい形です。MITRE ATLASはサイバー攻撃の知識ベースであるMITRE ATT&CKにならい、偵察から影響までの攻撃の流れの中にAI特有の技術を位置づけています。レッドチーミングの計画を立てるときに「攻撃者ならどこから入るか」を考える地図として役立ちます。

自社に合うAIセキュリティフレームワークの選び方は？

選定基準は、AIとの関わり方（作るのか、提供するのか、使うのか）と、対外的な証明が必要かどうかの2つです。この2軸でおおむね主軸が決まります。

AIとの関わり方別に主軸を決める

AI事業者ガイドラインは、AI開発者・AI提供者・AI利用者の3つの立場を区別しています。この区分を自社に当てはめると、どのフレームワークを主軸にするかが決まります。

企業規模・業種・既存環境で重みを変える

同じ立場でも、規模や既存の認証によって適した入り方は変わります。ISMSを運用しているかどうかが、とくに大きな分かれ目です。

1. ISO/IEC 27001（ISMS）の認証を持っている：ISO/IEC 42001を追加する形が効率的です。リスクアセスメントや内部監査の仕組みを流用できます。
2. 金融・医療など規制業種：業界の監督指針と照らし合わせることが前提になります。NIST AI RMFの用語でリスク評価を記録しておくと、監査で説明しやすくなります。
3. 中堅・中小企業でセキュリティ専任者が少ない：最初からISO認証を目指すのではなく、AI事業者ガイドラインのチェックリストとOWASPの上位項目に絞って始めるほうが現実的です。
4. 海外拠点や欧州の顧客がいる：EU AI Act（2024年8月発効、義務は段階的に適用）への対応も視野に入れ、ISO/IEC 42001やNIST AI RMFとの対応関係を整理しておきます。

ガバナンスと技術対策（プロンプトインジェクション・データ漏えい・エージェント権限）はどう対応づける？

代表的な脅威ごとに、技術対策はOWASPとMITRE ATLAS、責任と記録はISO/IEC 42001とAI事業者ガイドラインに割り当てます。脅威1つにつき上下2層をつなぐのが基本です。

脅威ごとの対応表を作る

脅威を行、フレームワークを列にした対応表を1枚作ると、規程と技術対策の抜けが見えます。監査のときにも説明資料としてそのまま使えます。

技術対策の詳細はプロンプトインジェクション対策の多層防御とAIガードレールの実装ガイドで解説しています。

AIエージェントは「権限」と「人への引き継ぎ」を規程に書く

AIエージェントでは、技術的な防御だけでなく「どの操作を人が承認するか」を規程に明記しておくことが、事故の範囲を限る一番確かな手段です。

AIエージェントを推進する現場でよく聞くのは、検証環境で広い権限を渡したままAPIキーを本番へ持ち込み、あとから権限を絞ろうとして業務フローが止まった、という話です。最初から「読み取りはエージェントに任せ、送信・削除・支払いは人が承認する」と線を引いておけば、こうした手戻りは減らせます。顧客対応のAIエージェントであれば、さらに次の3点を規程に書いておくと監査で説明しやすくなります。

• 人への引き継ぎ条件：回答の確信度が低いとき、苦情・解約・個人情報が絡むとき、利用者が求めたとき
• 回答の元データと更新責任者：FAQやマニュアルの持ち主となる部署と、更新を反映する周期
• 対象外の利用者への代替手段：電話窓口・有人チャット・問い合わせフォームなど

権限設計の進め方はAIエージェントのガバナンスと権限設計にまとめています。

日本企業はどの順番で導入すればよい？チェックリストは？

日本企業は、AI事業者ガイドラインで社内の共通言語を作る→OWASPで技術対策を固める→必要に応じてISO/IEC 42001で認証、という順番が進めやすいです。

4段階の導入ステップ

いきなり認証を目指すより、利用実態の把握から始めて段階的に厚くするほうが、現場の反発も手戻りも少なくなります。

1. 棚卸し（1段階目）：社内で使っている生成AIツール、LLMを組み込んだシステム、AIエージェントを台帳にまとめます。会社が把握していないシャドーAIの把握もここに含めます。
2. 方針と区分（2段階目）：AI事業者ガイドラインの「開発者・提供者・利用者」の区分で、自社の立場とシステムごとの責任者を決めます。社内ガイドラインはこの段階で作ります。
3. 技術対策（3段階目）：AIを組み込んだシステムごとに、OWASP Top 10 for LLM Applicationsで設計をレビューします。リスクの高いシステムはMITRE ATLASを参考にレッドチーミングを行います。AIセーフティ・インスティテュート（J-AISI）が公開している評価観点ガイドやレッドチーミング手法ガイドも参考になります。
4. 仕組み化と証明（4段階目）：内部監査とマネジメントレビューを回し、対外的な証明が必要ならISO/IEC 42001の認証取得を検討します。

着手前に確認したいチェックリスト

次の項目に答えられない場合は、フレームワークを選ぶ前に社内の前提をそろえる必要があります。

社内ルールの具体的な作り方は生成AI社内ガイドラインの作り方、全体の体制づくりはAIガバナンスの体制構築が参考になります。

AIセキュリティフレームワークの導入で失敗しやすい点と、向かないケースは？

最も多い失敗は、フレームワークの項目を埋めることが目的になり、実際のAIシステムの対策や運用につながらないことです。

よくある失敗パターン

失敗の多くは「文書と現場のずれ」から生まれます。どれも導入初期に気づけば修正しやすいものです。

• 翻訳・転記で終わる：NIST AI RMFやOWASPの項目を社内様式に写しただけで、どのシステムに当てはめるかが決まっていない。
• 一度作って更新しない：OWASPのリストは2023年版から2025年版で項目が入れ替わりました。AIエージェント向けの文書も追加が続いています。年1回以上の見直しを決めておかないと、すぐに古くなります。
• 認証取得がゴールになる：ISO/IEC 42001の認証を取っても、個々のLLMアプリの脆弱性が自動的に塞がるわけではありません。技術対策の層は別に回す必要があります。
• 推進部門だけで進める：情報システム・法務・事業部門が加わらないと、権限設計や情報区分が現場で守られません。

向かないケースと限界

フレームワークは万能の処方箋ではありません。規模や段階によっては、重い枠組みを入れるほど逆効果になります。

• PoC（概念実証）段階で利用者が数人に限られる：ISO/IEC 42001の仕組みを丸ごと入れるのは過剰です。入力してよい情報の区分と、ログの保存範囲だけを決めるほうが現実的です。
• SaaS型の生成AIを既定の設定で使うだけ：OWASPの開発者向けの項目の多くは自社で手を入れられません。ベンダーの管理体制を確認する評価項目に読み替えて使います。
• フレームワークでは防げないもの：新しい攻撃手法は、文書の改訂より先に現れます。OWASPやMITRE ATLASに載っていない脅威もあるため、インシデントの共有や脆弱性情報の継続的な収集と組み合わせることが前提です。

どの文書も「何を考えるべきか」は示しますが、「自社でどこまでのリスクを受け入れるか」は決めてくれません。その判断を誰が、どの頻度で下すかを決めることが、フレームワークを生きた仕組みにする最後の一手です。AIセキュリティ対策の全体像はAIセキュリティ対策の6層の実装手順で解説しています。

姉妹メディアの関連記事