OECD FRAMEWORK FOR THE CLASSIFICATION OF AI SYSTEMS まとめ

本記事では「OECD FRAMEWORK FOR THE CLASSIFICATION OF AI SYSTEMS」について原文を翻訳・意訳しながら日本語でまとめ、同フレームワークの理解を深めることを目的としています。原文はこちらからアクセスをお願いします。

どのようなフレームワークなのか

一言でわかりやすく説明するとすると、「AIシステムの特性と相互作用を整理するためのフレームワーク」となると思います。AIシステムを表現する観点として5つのディメンジョンが定義され、それぞれ異なるAIシステムを共通のフレームワークを用いて整理できます。原文にも政策立案者、規制当局、議員などが人々が特定のプロジェクトやコンテキストに合わせて AI システムを特徴付けるための使いやすいフレームワークとして開発されたとあります。本フレームワークは次のベースラインを提供します。

• AI についての共通理解を促進する: 最も重要な AI システムの機能を特定し、政府やその他の企業が特定の AI アプリケーションに合わせて政策を調整できるようにし、より主観的な基準 (幸福への影響など) を評価するための指標の特定または開発を支援する
• レジストリまたはインベントリに情報を提供する: アルゴリズムまたは自動意思決定システムのインベントリまたはレジストリにおけるシステムとその基本特性を説明するのに役立つ
• セクター固有のフレームワークのサポート: 医療や金融などのセクターにおける、より詳細なアプリケーションまたはドメイン固有の基礎を提供する
• リスク評価のサポート: リスク回避と軽減に役立つリスク評価フレームワークを開発し、インシデント報告における世界的な一貫性と相互運用性を促進する AI インシデントに関する報告のための共通フレームワークを開発するための関連作業の基礎を提供する
• リスク管理のサポート: コーポレート ガバナンスに関するものも含め、AI システムのライフサイクルに沿った緩和、コンプライアンス、施行に関する関連作業の情報提供を支援する

AIシステムの特性と相互作用を構成する主要なディメンジョン

本フレームワークは、人と地球、経済的コンテキスト、データと入力、AIモデル、タスクと出力の5つディメンジョンに沿ってAIシステムとアプリケーションを分類します。 それぞれには、AIシステムの考慮事項の評価に関連する独自のプロパティと属性、またはサブディメンションがあります。

人と地球: 人と地球に利益をもたらす、人間中心で信頼できるAIを促進するAI システムの可能性を考慮しています。 それぞれのコンテキストにおいて、AIシステムと相互作用する、またはAIシステムの影響を受ける個人およびグループを識別します。 主な特徴には、ユーザーと影響を受ける利害関係者だけでなく、アプリケーションのオプション性と、それが人権、環境、幸福、社会、仕事の世界にどのような影響を与えるかが含まれます。

経済的コンテキスト: AIシステムが実装される経済的および分野別の環境とAIシステムが開発される組織の種類と機能領域について説明します。 特徴には、システムが導入されているセクター (ヘルスケア、金融、製造など)、そのビジネス機能およびモデル、性質、そ入、影響、規模、および技術的成熟度が含まれます。

データと入力: AIモデルが環境の表現を構築するために使用するデータや入力について説明します。 特性には、データと入力の出どころ、データの収集方法、データの構造と形式、データのプロパティが含まれます。 データと入力の特性は、AI システムのトレーニングに使用されるデータ「in the lab」と生産で使用されるデータ「in the field」に関係します。

AI モデル: AIシステムの全てまたは外部環境の一部を計算的に表現したもので、たとえば、その環境で行われるプロセス、オブジェクト、アイデア、人々、相互作用が含まれます。 主な特性には、技術的な種類、モデルの構築方法 (専門知識、機械学習、またはその両方を使用)、モデルの使用方法 (どのような目的で、どのようなパフォーマンス測定値を使用するか) が含まれます。

タスクと出力: システムが実行するタスク、例えばパーソナライゼーション、認識、予測、または目標主導型の最適化、その出力、そしてその結果として全体的なコンテキストに影響を与えるアクションを指します。このディメンジョンの特性には、システム タスク、行動の自主性、自動運転車のようにタスクとアクションを組み合わせるシステム、コンピュータビジョンなどのコアアプリケーション領域、および評価方法が含まれます。

フレームワークの主要な要素

フレームワークの各ディメンジョンには、さまざまな AI システムに関連する考慮事項の属性、またはサブディメンジョンがあります。 ステークホルダーには、AIシステムに関係する人、またはAIシステムの影響を受ける人が含まれます。 AIアクターは、AIシステムのライフサイクル全体を通じて積極的な役割を果たすステークホルダーであり、各側面に応じて異なります。

AIシステムの各分類ディメンジョン毎の性質と、キーとなるAIアクターが整理されたものが以下のフローとなります。

• AIの「in the lab」とは、導入前のAIシステムの構想と開発を指します。 これは、フレームワークのデータと入力 (データの修飾など)、AIモデル (初期モデルのトレーニングなど)、およびタスクと出力のディメンジョン (パーソナライゼーション タスクなど) に適用できます。 これは、事前のリスク管理アプローチと要件に特に関連します。
• 「in the field」AIとは、導入後のAIシステムの使用と進化を指し、特に事後のリスク管理アプローチと要件に関連します。 これは、人々と地球、経済的コンテキストを含むすべての次元に適用できます。 さらに、「in the field」AIシステムは、特に導入範囲の広さ、技術の成熟度、ユーザーと機能に関して、時間の経過とともに多くの大幅な変化を起こす可能性があることを強調することが重要です。 たとえば、これはモデル構築に利用できるようになった改良されたデータセットや異なるデータセットによって発生する可能性があります。

AIシステムのライフサイクルは、システムの主要な技術的特性を理解するための補完的な構造として機能します。 ライフサイクルには、必ずしも連続しているわけではない次のフェーズが含まれます（データの収集と処理、モデルの構築と利用、検証、展開、および運用と監視）。 AIシステム分類のための OECD フレームワークのディメンジョンは、AIシステムのライフサイクルの段階と関連付けて、説明責任に関連するAIアクターを特定できます。

このフレームワークは、AIシステム開発の倫理的・社会的な側面を考慮した上で、その開発と利用を促進するための指針を提供します。フレームワークは定期的に見直し、必要に応じて更新していく必要があります。

• フレームワークの継続的な見直し
  • 動的な性質や社会・技術・法的な発展を考慮し、フレームワークの継続的な関連性を定期的に見直す必要があります
  • フレームワークの各要素は独立しているが、相互に影響を与え合います
  • データ収集の目的は、後の利用目的と一致させる必要があります
• AIシステムの汎用性
  • 汎用性とは、訓練を受けたタスク以外にも複数のタスクを実行できる能力を指します
  • 単一の指標ではなく、複数の基準を組み合わせて客観的に評価します
• 詳細
  • フレームワークは、AIシステム開発の指針としてだけでなく、その進化に伴うリスクを評価するためにも利用できます
  • フレームワークの各要素は、独立しているように見えますが、実際には相互に影響を与え合っています。例えば、タスクと出力の定義は、データと入力、そしてAIモデルの設計に影響を与えます
  • データは、特定の目的のために収集されたものである必要があります。収集段階で意図していなかった目的に使用すると、タスクの理想的な目的と、データに基づいて達成できる目的との間にズレが生じる可能性があります
  • AIシステムの汎用性は、単一の指標で測定することはできません。複数の基準を組み合わせて評価する必要があります。これらの基準には、タスクの類似性、データの多様性、モデルの複雑性などが含まれます

以後原文の2章では各ディメンジョンを掘り下げて、詳細な説明が述べられていますが、ボリュームが多く内容が詳細であるため本まとめでは省略します。3章では具体的なAIシステムに対して本フレームワークを用いて整理された具体例が載っています。単純にフレームワークを説明するだけのものは多いと思いますが、実際にフレームワークを利用した実例が盛り込まれているのは非常に有益だと思います。次回のブログで生成AIアプリケーションについて実践してみたいと思います。

Next Step

4章のNext stepではAIシステムの開発と利用に伴うリスクを評価するための枠組みの構築について論じており、AIシステムの分類、インシデントの追跡、リスク評価のフレームワークの3つが論点となっています。

• AIシステムの分類では、実世界の事例をもとに分類基準を洗練していくことが提案されています。わかりやすい評価と正確な評価の間でトレードオフがあることも指摘されており、状況に応じて詳細な質問が必要になる場合もあるとしています
• AIインシデントの追跡では、共通の報告フレームワークを構築することが目指されています。これにより、世界的に一貫性のあるインシデント報告が可能となり、OECDのグローバルAIインシデント追跡システムへのデータ蓄積にも役立ちます
• リスク評価フレームワークの開発では、AIシステムの分類に加え、ガバナンスやリスク緩和プロセスなどの情報を用いて、倫理的・社会的なリスクを評価することができるようになるとしています。政策立案者や企業など様々な関係者が実務的に活用できることが期待されます

リスク評価の際に考慮すべき基準として、影響の深刻さ・範囲、利用者の選択可能性などが挙げられています。OECDは、国際的な相互運用性を促進するため、AIリスク評価・管理に取り組む様々なグループとの連携・調整を図ることも重要視しています。なお、AIリスクの議論は、機能安全やサイバーセキュリティなどの既存の評価フレームワークを補完するものであり、人権や責任ある企業行動に関するガイドラインとも密接に関連しているとされています。

OWASP Top 10 for LLM Applicationsを超わかりやすく図解してみた（その1）

サマリ

本記事はOWASP Top 10 for LLM Applicationsを図を用いてなるべく超わかりやすく図解してみたものとなります。

出典

本記事では必要に応じてOWASP Top 10 for LLM Applicationsまたはその日本語訳から一部を引用しています。

はじめに

LLMを用いた生成AIアプリケーションについてTechな観点でのセキュリティを考える上で非常に参考になるナレッジが「OWASP Top 10 for LLM Applications」です。OWASPといえば「OWASP Top 10」というWebアプリケーションの10のセキュリティ上の脆弱性がまとめられたものが有名ですが、 今回扱うのはfor LLM Applicationsとあるように大規模言語モデル（Large Language Model：LLM）を用いたアプリケーションに特化した10の脆弱性が整理されているものです。OWASP Japanさんにて日本語に翻訳されたものがありますので、日本語で理解されたい方は日本語版をご確認下さい。

実際に原文または翻訳を見て頂けるとわかりますが、10の脆弱性について次の4つポイントでわかりやすく整理されています。これらが具体的な事例や技術的な内容を含んで整理されていることから、とても活用し易いナレッジになっています。

• 脅威の概要
• 一般的なリスクのサンプル
• 予防・緩和戦略
• 攻撃シナリオのサンプル

原文を見ていただくと代表的なアーキテクチャに対してどのコンポーネント、あるいはどのインタラクションに脆弱性があるかマッピングされたものがありますが、まだ日本語版の翻訳には反映されていないようです。また10の脆弱性のそれぞれの説明には図表が無く、一部理解に苦労される内容が含まれているのではと思っております。

OWASPの各脅威に移る前に、LLMアプリケーション（以後生成AIアプリと呼びます）の正常な挙動について振り返ってみます。

基本的な挙動

1. 正常な利用者は生成AIアプリのUI上でプロンプトを入力します
2. 生成AIアプリはモデルにプロンプトを入力しその応答を得ます
3. 生成AIアプリはモデルから受け取った応答を利用者に応答します

追加の考慮点

• モデルが持っていない最新のデータや固有のデータを利用できるようにするため、1と2の間に外部データを利用できるように生成AIアプリを構成するかもしれません（RAGとか検索拡張生成と呼ばれています）
• モデルをユースケースに特化して拡張できるよう、モデル自体をトレーニングするか、あるいはファインチューニングすることがあるかもしれません
• 生成AIの活用が進んでいる場合、生成AIアプリ利用者に代わってバックエンドのシステムに対して何かしらの特権操作を実施できるよう構成するかもしれません（メールの送付、データベースへのアクセスなど）

これを踏まえてOWASPの各脆弱性について見てみましょう。

LLM01：プロンプト・インジェクション

まず1つ目の脆弱性はプロンプトインジェクションです。1つ目に出てきていることから最も一般的かつリスクの高いものであると理解して良いと思います。プロンプトインジェクションというと生成AIアプリケーションのインタラクティブなUIに悪意あるプロンプトを入力して攻撃することを思い浮かべると思います。これを「直接的なプロンプトインジェクション」と呼びます。一方この脅威で興味深い点は、これとは別に「間接的なプロンプトインジェクション」も存在することを示しています。間接的なプロンプトインジェクションがどのような脆弱性であるのか、直接的なプロンプトインジェクションと合わせて説明します。

直接的なプロンプトインジェクション

これはイメージしやすいと思います。攻撃者は生成AIアプリに悪意あるプロンプトを入力することで、本来意図しない応答を生成AIアプリから得ようとしたり、バックエンドのシステムに対して不正アクセスや不正操作を試みる攻撃です。

間接的なプロンプトインジェクション

間接的なプロンプトインジェクションのシナリオは直接的なものと比べて少し複雑です。

例えば攻撃者は生成AIアプリが利用する外部データに対する何かしらの操作権限を持っていると仮定します。あるいは生成AIアプリはパブリックなデータソースを利用しているとします。攻撃者は悪意あるプロンプトを含んだデータをアップロードします（例えばバックエンドのデータベースにアクセスするとか、〇〇さんは優秀だという回答を返すなど）。この悪意あるプロンプトは生成AIアプリが読み取れる形式であれば良く、人間が可読である必要はないというのがポイントです（一見正常なファイルにプロンプトが埋め込まれる可能性があるということです）。

利用者または攻撃者が生成AIアプリを利用した際に、生成AIアプリが悪意あるプロンプトを含むデータを参照することで、生成AIアプリがモデルに悪意あるプロンプトを入力してしまうのが、間接的なプロンプトインジェクションのポイントです。結果悪意ある応答を利用者に返したり（〇〇さんは優秀だ）、攻撃者がバックエンドのシステムにアクセスするなどの影響が生じます。

予防・緩和戦略

OWASPによるとプロンプトインジェクションの脆弱性は、命令と外部データを分離しないLLMの性質に起因していること、LLM は自然言語を使うので、両方の入力フォームをユーザが提供したものと見なされるという性質のため、確実な防止策はないとされています。OWASPで紹介されている緩和策を図示すると次のようになります。

• アクセス制御・最小権限：当たり前の対策ではあると思いますが、生成AIアプリと各種システムとのアクセス制御、生成AIアプリが持つ権限を最小化するなどの対策です
• Human in the loop：特権操作を行う際には人間による判断プロセスを追加する予防策です
• 外部コンテンツの分離：モデルへの入力を行う際に、利用者が入力したものと外部データから取得したコンテキストを分離して入力する、ということを指しているものと思います
• 信頼境界の確立：生成AIアプリやモデルを信頼されないユーザとして扱い、各コンポーネント間の信頼境界を確立することで保護します

これらの緩和策を見ると、間接的なプロンプトインジェクションは特に防ぐのが難しい攻撃のように見受けられます。外部データへのアクセス制御や意図しないデータを参照しない設計をするなど、特に間接的なプロンプトインジェクションを意識した取り組みが必要であると考えられます。

NIST AI RMF 1.0 の日本語まとめ（その1）

サマリ

本記事ではAIシステムのリスクやリスクの管理策のナレッジがつまったNISTのAI Risk Management Frameworkについて日本語でまとめました。

はじめに

NISTが発行するドキュメントではサイバーセキュリティフレームワーク（CSF）が非常に有名ですが、１年以上の時間をかけて整備されたAIに特化したリスクマネジメントフレームワークが2023年１月にリリースされています。まずは日本語で概要を把握したいということであれば、PwCさんが出しているこちらの記事が非常に有益です。ですが、当ブログでは管理人自身が内容を深く理解したいということ、また2024年3月時点でIPAさんなどから全文翻訳が出ていないこともあり、一つでも多く日本語での解説があったほうが有益であろうとの思いから「日本語まとめ」を執筆しています。執筆時点では生成AIが一世を風靡していますが、本AI RMFは生成AIだけではなく、AIシステム全般を対象としたものとなっています。

原文はNISTのこちらのページ内にある「AI Risk Management Framework (AI RMF 1.0)」というリンクをクリックすると閲覧できます。

全体感

AIリスクマネジメントフレームワーク（以下AI RMF）は全体で2部構成になっています。Part1では基礎情報として、「AIのリスクマネジメントにおける課題」や「信頼できるAIシステムの特徴」、「AIのライフサイクルと各ライフサイクルにおけるAIアクターの関わり」について書かれています。後半のPart2ではフレームワークメインパートであり、リスクマネジメントの対応策が4つのコア（Govern、Map、Measure、Manage）として整理されています。

Part1 基礎情報

1.1 リスクの構成

AI RMFの文脈では「リスク」とは事象が発生する確率と事象がもたらす影響の大きさや程度を総合的に測定したものを指しています。リスクと聞くとマイナスの印象を持たれる場合が多いと思いますが、ISO31000:2018では、影響とはプラスやマイナスのもの、あるいはその両方であり、機会あるいは脅威をもたらすと考えます。またリスク管理とはリスクに関して組織を統制するための協調的な活動のことを指しています。リスク管理プロセスでは一般的にマイナスの影響に対して対処しますが、AI RMFではAIシステムの予想されるマイナスの影響を最小限に抑え、プラスの影響を最大化する機会を特定するアプローチを提供する、と述べられています。

AIシステムに関連する潜在的な危害の例として、次の3点が例示されています。

1.2. AI特有のリスク管理の課題

ここではAI特有のリスク管理の課題について述べられています。

リスクの測定

• リスクは第三者のデータやソフトウェアから発生するだけでなく、利用方法からも発生する
• リスクや信頼性の測定方法が未成熟である
• AIのライフサイクルの異なる段階ではリスクの測定結果が異なる可能性がある
• 検証環境と運用環境ではリスクが異なる可能性がある
• 不透明なAIシステムではそもそもリスクの測定が困難である
• 人間を代替、補助するようなAIシステムにおいては、比較のための人間のベースラインが必要であるが、体系化することが難しい

リスクの優先順位付け

• リスクを完全に排除することは現実的ではなく、無駄なリソースの配分に繋がる可能性がある
• AIシステムごとにリスク評価を行い、リスクレベルと影響に基づいてリソース配分の優先順位付けをするリスク管理文化が重要である
• 最もリスクが高いシステムを最優先で管理する
• 人間と直接対話するAIシステムは、人間と対話しないシステムよりも優先度が高い場合がある
• 残存リスクを文書化し、エンドユーザーへの影響を考慮、管理する必要がある

組織的な統合とリスクの管理

AI RFMはAIリスクを個別に考えるべきではないとしています。AIアクターはライフサイクルにおける役割に応じて異なる責任と認識を持つからです（AI アクターは、経済協力開発機構（OECD）によって「AIを導入または運用する組織や個人を含め、AI システムのライフサイクルにおいて積極的な役割を果たす人々」と定義されています）。例えばAIシステムを開発する組織は、そのシステムがどのように使用されるかわからないかもしれません。このためAIのリスク管理は、より広範な企業のリスク管理の戦略やプロセスに統合されるべきだと述べられています。

• サイバーセキュリティやプライバシーなど、他の重要なリスクとともに扱う
• AI固有のリスクに加え、ソフトウェア開発や運用に共通のリスクも考慮する
• 組織は適切な説明責任、役割、文化、インセンティブ構造を確立し維持する必要がある

2. 関係者

AIのリスクと潜在的な影響を特定し管理するためには、AIのライフサイクル全体に渡る様々な視点と関係者を考慮する必要があると述べられています。

TEVV：test, evaluation, verification and validation

3. AIリスクと信頼性

AI システムが信頼されるためには、利害関係者が重要視する様々な基準を満たす必要があるとしています。このAI RMFでは、信頼できる AI の特性を以下のように示し、それらへの対応方法をガイドしています。

• 信頼できるAIの特性：正確性と信頼性、安全性、セキュリティと耐障害性、説明責任と透明性、説明可能性と解釈可能性、プライバシー保護、公平性と有害バイアスの管理
• 信頼できるAIの構築は、これらの特性間のバランスを取ることが必要です。 全ての特性が社会技術的システム属性ですが、説明責任と透明性はAIシステム内部のプロセスや活動、および外部環境にも関連します。 
• AIの信頼性はトレードオフが伴い、全ての特性が全ての状況に当てはまるわけではありません。 特定の状況においては、例えば、解釈可能性を最適化することとプライバシー保護との間でトレードオフが生じる可能性があります。
• AIリスクを管理する際、組織はこれらの特性間のバランスを取るという難しい決断に直面する可能性があります。 コンテキストを考慮した分析を行うことで、トレードオフの存在や程度を明らかにすることができますが、その解決方法については示唆されません。 解決方法は、関連するコンテキストにおける価値観に依存しており、透明性をもって正当化できる方法で解決する必要があります。
• AIのライフサイクル全体を通してコンテキストに対する理解を深めるためのアプローチがいくつかあります。 例えば、ドメイン専門家はTEVV（Testing and Evaluation of Values and Biases）の結果の評価を支援し、製品開発チームと導入チームがTEVVのパラメータを要件や導入条件に合わせるように連携することができます。 関係者やAI関係者からの幅広く多様な意見を取り入れることで、コンテキストに敏感な評価を行い、AIシステムのメリットとポジティブな影響を特定する機会を高めることができます。
• AIシステムの信頼性は、AIライフサイクルにおける各関係者の役割によって異なります。 同じ AI システムでも、設計者や開発者と導入者では、重要視する特性が異なる可能性があります。

信頼性の特性は相互に影響し合い、非常に安全だが不公平なシステム、正確だが不透明で解釈不能なシステム、不正確だが安全でプライバシー保護されており透明なシステムなどは望ましくありません。 リスク管理への包括的なアプローチは、信頼性の特性間のトレードオフのバランスを取ることが求められるとしています。 AI技術が特定のコンテキストや目的において適切なツールであるかどうか、そして責任を持って使用する方法を判断するのは、全てのAI関係者の共同責任であると説明されています。 

一旦ここで区切って、次回続きからまとめていきます。