🦆
生成AIを利用する上でのセキュリティ成熟度モデルを眺めてみる

2025/03/27に公開
 なぜ作成したのか絶対成熟してないけど目標って大事ですよね

 参考https://www.jnsa.org/result/aisec/2024/index.html

https://github.com/JNSA-AISecurityWG/Generative_AI_Doc

 生成AIを利用する上でのセキュリティ成熟度モデル
 概要近年、テキスト・画像・動画などをAIで自動生成する生成AIの利用が様々な分野で進んでおり、今後さらに普及すると予想されています。
本ドキュメントは、生成AIをセキュアに活用するために必要な項目を、生成AIの利用ケースごとにマッピングし、組織で安全に生成AIを利用する際の一助とすることを目的としています。対象とする組織の利用形態は以下の4つです：

外部サービスの利用:
提供元が公開するWebインタフェースやスマートフォンアプリ等から、ChatGPTやGoogle Bard、Geminiなどクラウドの生成AIサービスを直接利用するケース。


APIを利用した独自環境:
OpenAI APIやGoogle PaLM API、Gemini APIなどの生成AI APIを自社のシステムと連携させて利用するケース。


自組織データの活用:
ファインチューニングやRAG（Retrieval-Augmented Generation）の技術を用いて、自社保有データを生成AIに組み込んで活用するケース。


自組織向けモデルの開発:
自社専用の生成AIモデルを独自に開発・運用するケース。

以上の利用形態ごとに直面し得る脅威と、それらに対処するための**セキュリティ対策（アクション）**を整理し、組織のセキュリティ成熟度向上に役立てます。

 脅威とアクション・対策の一覧
 外部からの脅威
入出力関連の脅威
E-01: プロンプトインジェクション

E-02: モデルへのDoS（サービス拒否攻撃）

E-03: 過剰な代理行為（AIエージェントの暴走）

E-04: 機微情報の漏洩（センシティブ情報の流出）


モデル関連の脅威

L-01: 訓練データの汚染（データポイズニング攻撃）

L-02: モデルの盗難（モデル不正取得・複製）


 脅威へのアクション・対策
アプリケーションのセキュリティ（システム・アプリ側の対策）
A-01: 適切なアカウント管理
A-02: 構築したアプリケーションのセキュリティ
A-03: 利用するインフラのセキュリティ
A-04: 利用するサービスの管理


モニタリング（利用状況の監視と制御）
M-01: 利用量のモニタリング
M-02: コンテンツフィルタリング
M-03: 履歴のモニタリング


ポリシーと教育（内部ルール整備と人材教育）
P-01: 生成AI利用に関するポリシーの整備
P-02: 生成AI利用に関する教育
P-03: 法律や規制の確認

上記に示した脅威（E-xx、L-xx）と対策項目（A-xx、M-xx、P-xx）は、組織の生成AI利用におけるセキュリティ成熟度を高めるために対応すべき事項です。以下では各脅威と対策項目の内容を詳しく説明します。

 想定される脅威の詳細
 E-01: プロンプトインジェクション概要:
プロンプトインジェクションは、生成AIに対する代表的なサイバー攻撃手法の一つです。攻撃者が悪意のある入力を行い、開発者の意図しない操作や回答をAIに実行させる攻撃です。
通常の入力では取得できない情報を引き出したり、AIの挙動を不正に操作したりする可能性があります。プロンプトインジェクションには以下の2種類があります。
直接的なプロンプトインジェクション（ジェイルブレイクとも呼ばれる）:
攻撃者が開発者の用意したシステムプロンプトを上書き実行したり、プロンプト自体を不正取得したりして、AIから本来得られない情報や操作を引き出す攻撃です。
間接的なプロンプトインジェクション:
外部コンテンツをAIが読み込む際に行われる攻撃です。攻撃者が仕込んだ悪意あるWebサイトやファイルをAIに読み込ませ、意図しない指示を実行させます。
攻撃例:
攻撃者がチャットAIに対し、開発者が設定した指示を無視させ、機密情報を答えるよう仕向けるプロンプトを入力して不正に情報を取得する。
利用者がウェブサイト要約のAIサービスを使う際、攻撃者が用意した間接的プロンプトインジェクションを含むページを要約させ、開発者の想定外の有害な内容を出力させる。
対策:
プロンプトインジェクションへの主な対策として、入力・出力のフィルタリングや権限制御があります。
入力時の対策:
ユーザからの入力に対し不正な指示が含まれていないかフィルタリングを行います（例えば「禁止ワード」や構文の検知）。
内部の対策:
AIモデル側で過度な動作を制限したり、AIがアクセスできる機能やデータに最小限の権限のみ付与します。また、バックエンドの重要システムへAIが勝手に操作できないよう権限管理を行い、特権操作については**人間の承認（Human in the Loop）**を必須にするなどの対策を取ります。
出力時の対策:
AIの出力フォーマットを定義・検証し、不正な構造の出力（例えばコードインジェクションにつながる出力など）を弾きます。
その他:
定期的にAIに対する攻撃シミュレーションを実施し、脆弱な点を評価・改善します。

 E-02: モデルへのDoS概要:
モデルへのDoS（サービス拒否）攻撃は、生成AIを利用するシステムに大量のリクエストや負荷の高い要求を送りつけ、リソースを枯渇させたりシステムを遅延・停止させる脅威です。
生成AIサービスは使用量に応じ課金が発生したり、計算資源が限られていることが多いため、攻撃により想定外の高額請求やサービスダウンが起こり得ます。
攻撃例:
コンテキストウィンドウ（AIが一度に処理できるテキスト長）を超えるような極端に長い入力を何度も送信して処理負荷をかける。
入力により再帰的な処理（AIが延々と自己呼び出しするような状況）を発生させ、計算資源を浪費させる。
APIエンドポイントに大量のリクエストを短時間で送りつけ、サービスを逼迫させる。
対策:
モデルへのDoS対策として、入力内容とリクエスト頻度の両面で制限を設けます。
入力検証とサニタイズ:
ユーザ入力を検証し、極端に長い入力や再帰構造を持つ不正な入力を受け付けないようにします。
リソース使用量の制限:
1リクエストあたり、または1ユーザあたりの処理量に上限を設けます（例: API呼び出し回数やトークン数の制限）。
APIレート制限:
短時間に過剰なリクエストを送れないようレートリミットを設定します。
厳密な入力サイズ制限:
生成AIのコンテキストウィンドウ上の制約を超える入力は切り捨てたり拒否するなど、長大入力による過負荷を防止します。

 E-03: 過剰な代理行為概要:

AIエージェントと呼ばれる、生成AIの出力に基づいて他のシステムと連携し様々な自動操作を行う仕組みがあります。
過剰な代理行為とは、そのエージェントが生成AIからの予期しない・曖昧な出力を根拠に動作し、ユーザの承認なしに問題ある処理を実行してしまうことです。
攻撃例:
生成AIの指示によって、ユーザの許可を得ずにデータベースのレコードを編集・削除してしまう。
生成AIの出力により、ユーザ承認なしに連携アプリで予約を勝手に申し込んでしまう。
（上記は、AIが想定外の命令を出力し、それをエージェントが実行してしまうケースです。）
対策:
過剰な代理行為を防ぐには、エージェントに与える権限や動作範囲を制限するとともに人間の確認プロセスを組み込みます。
機能・権限の最小化: 生成AIと連携する外部サービスやエージェントには、必要最小限の機能のみを持たせ、権限を絞ります（例: 書込みや削除操作を極力させない等）。
人間による最終確認: エージェントが重要な操作を行う前に、必ず利用者の承認を求めるようにします（例えば「○○を実行します。よろしいですか？」という確認を入れる）。

 E-04: 機微情報の漏洩概要:

機微情報とは、個人データや高度に機密な顧客情報、公開すべきでない秘密情報などを指します。
生成AIを用いたシステムでは、出力結果を通じて機微情報が漏洩する恐れがあります。
たとえば、誤って機密データをAIに入力してしまい、他のユーザへの出力にその内容が現れてしまうとプライバシー侵害や知的財産の流出につながります。
また、生成AIの提供者が入力情報を学習データやモニタリング用に保持している場合、適切な設定を行わないと内部から情報が流出するリスクもあります。
攻撃例:
攻撃者がプロンプトインジェクションを悪用して入力値検証・サニタイズ（無害化処理）を迂回し、AIに本来出力させない機密情報を吐き出させる。
（※想定例）システム側の機微情報アクセス制限が甘い場合、攻撃者が本来アクセスできない機微データをAIに問い合わせ、漏洩させる。
対策: 機微情報漏洩を防ぐには、入力段階とモデル内部でのフィルタリングが重要です。

入力時のチェック: ユーザがAIに送る入力に機密情報が含まれていないか検証・サニタイズし、誤って社内機密や個人情報を入力しないようにします（例えば社内データをコピー＆ペーストできないよう注意喚起・UI制御するなど）。

悪意入力の除外: 強力な入力フィルタで、攻撃者による有害な入力（例えば特殊なシーケンスで機密データを引き出そうとする試み）を検知・ブロックし、モデルが汚染されないようにします。

出力のフィルタ: AIの回答内容にもフィルタをかけ、機密情報らしきデータが出力されそうな場合は遮断するなどのガードレールを設けます（NVIDIA NeMo Guardrailsの活用なども一案です）。

 セキュリティ対策項目の詳細
 A-01: 適切なアカウント管理概要:
生成AIサービスを安全に利用するには、まずアカウントの適切な管理が不可欠です。
WebサービスのログインアカウントやAPIキー発行用のアカウントなど、生成AI利用には様々なアカウントが関係します。
これらが乗っ取られるとなりすましによる不正利用や情報漏洩につながるため、従来の情報システムと同様に厳重なアカウント管理が非常に重要です。
攻撃例:
アカウントに対する典型的な攻撃として、他サービスから漏れた認証情報の悪用や、フィッシング・マルウェアで盗んだログイン資格情報の流用が挙げられます。
攻撃者が正規ユーザになりすましてAIサービスにログインし、勝手に操作を行う恐れがあります。
また、APIキーが流出した場合、そのキーを使った不正なAPIコールによって想定外の課金が発生する可能性もあります。
対策:
アカウント管理に関する主な対策は以下のとおりです。

多要素認証を利用する
多要素認証（MFA）はID・パスワードのみのログインに比べて格段に安全です。
メールによるワンタイムコード送信や認証アプリでのコード生成など、可能な場合は必ずMFAを有効化します。
また、管理画面でMFAを強制できる場合は強制設定します。


パスワードを長く推測されにくいものにする
短いパスワードやキーボード配列など規則的なパスワードは総当たりや推測で破られるリスクが高まります。
パスワードは十分長く（例: 10文字以上）し、推測されにくいランダムな文字列を設定してください。


パスワードを使い回さない
多くのサービスでメールアドレスをIDとして使います。
このIDとパスワードの組が他で漏洩した場合、同じパスワードを再利用していると他のサービスにもログインされてしまいます。
従って、サービスごとに異なるパスワードを設定しましょう。


不要なアカウントは削除する
アカウントの放置は内部不正のリスクも高めます。
異動・退職者のアカウント削除はもちろん、定期的にアカウント棚卸しを行い、不要アカウントを残さないようにします。


APIキーを適切に管理する
APIキーが流出すると第三者に勝手にAPIを使われる恐れがあります。
APIキー発行時には必要最小限の権限設定やアクセス制限を行い、ソースコード内にハードコードすることは避け安全に保管してください。


 A-02: 構築したアプリケーションのセキュリティ概要:
生成AIを組み込んだ自社アプリケーションには多様な形態があります。
Webアプリへの組込みだけでなく、LangChainのようなフレームワークで社内システム群と連携させたり、VLA（Vision-Language-Action）モデルのようにロボットに組み込むケースもあります。
したがって、従来のアプリケーションセキュリティ対策に加えて、その環境に合わせた生成AI特有の対策も考慮する必要があります。
開発時からセキュリティを織り込む「セキュア開発」が重要です。
対策:
アプリケーション側の対策は、生成AIへの入力・出力データを厳密にチェックし、基盤の安全性を確保することです。
また、生成AI連携により発生しうるWebセキュリティ上の脅威にも備えます。
入出力の検証と権限設定:
生成AIに渡す入力データおよびAIから受け取る出力データを常に検証し、不正な内容がシステムに影響を与えないようにします。
また、生成AIから他システムへのアクションには適切な権限範囲を設定します。
一般的な脆弱性対策:
Webアプリに組み込む場合や、LangChain等で他システムと連携する場合、従来から知られるXSS、SQLインジェクション、SSRF、リモートコマンド実行などの攻撃を受ける可能性があります【参考: OWASP Top 10】。
これらからアプリを守るには、セキュアな設計・実装が必要です。
目安としてOWASPが公開しているアプリケーションセキュリティ検証基準（ASVS）【参考資料あり】などの基準に沿って開発・テストを行うことで、Webアプリの安全性を高められます。

 A-03: 利用するインフラのセキュリティ概要:
多くの生成AIサービスや自社モデルはクラウド環境で提供・運用されます。
そのため、通常のクラウド利用と同様のインフラセキュリティ対策を講じる必要があります。
クラウド上の設定ミスや権限管理の不備による情報漏洩は、生成AIに限らず重大なリスクです。
対策:
クラウドインフラに関する代表的なセキュリティ対策は以下のとおりです。
ベンチマークに沿った設定:
クラウドの構成はセキュリティベンチマーク（例: CIS Benchmarks）に従って堅牢化します。
CIS（Center for Internet Security） Benchmarksは各種クラウドサービス（Azure【参考資料あり】やAWS【参考資料あり】等）向けに公開されており、主要クラウドもCIS準拠設定をサポートしています。
これに沿って設定することで設定ミスによる脆弱性を減らせます。
クラウド固有のセキュリティサービス活用:
クラウドプロバイダが提供するセキュリティ機能（Azure Security CenterやAWS Security Hubなど）を活用し、誤設定の検出・修正や脅威検知を自動化します。
アクセス管理:
クラウド環境へのアクセスは原則IAMで**最小権限（Least Privilege）**を徹底します。
開発者・運用者に与える権限を必要最低限に絞り、APIキーや認証情報も安全に保管・ローテーションします。

 A-04: 利用するサービスの管理概要:
生成AIそのもののサービスに加え、周辺の連携サービス（プラグイン、外部ツール等）を併用すると利便性が向上します。
しかし利用するサービスが増えるほど、それら各サービスを適切に管理する必要があります。
つまり、「どの外部サービスを使ってよいか・使ってはいけないか」を決め、継続的に評価・管理することが重要です。
対策:
組織として連携サービスを利用するにあたり、サービスの評価基準を設け定期的に見直します。以下はサービス選定時の評価例です。

第三者認証の有無を確認:

利用しようとするサービスが情報セキュリティに関する第三者認証（例: ISMS認証、クラウドセキュリティ認証、SOC 2報告、政府のISMAPなど）を取得済みか確認します。認証取得済みなら一定の信頼性があります。

認証未取得の場合の対応:

認証が無いサービスについては、「ASP・SaaSの安全・信頼性に係る情報開示指針（ASP・SaaS編）第3版」【総務省によるガイドライン】への質問票回答をサービス提供者に依頼し、その回答内容を評価します。問題がなければ利用を検討します。

総合判断:

上記のような客観的基準で評価が難しい場合、サービス利用の責任者が総合的にリスクを判断して採否を決めます。
このようにサービス選定・管理の基準を設け、定期的にサービス一覧を見直すことが望まれます。また、組織全体のセキュリティ対策状況についてはIPA（情報処理推進機構）の「中小企業の情報セキュリティ対策ガイドライン」なども参考にしつつ、総合的な安全性確保に努めます。

 M-01: 利用量のモニタリング概要:
生成AIの利用状況をモニタリングすることは、不正利用の早期発見や、想定外の利用増加によるリソース不足・高額請求を防ぐ上で有効です。
正しく監視していれば、不正な大量利用による過大なコスト発生や異常なリクエスト増加を早期に検知し、対策を講じることができます。
対策:
利用量監視には、可視化と通知の仕組みが必要です。具体的には:
ダッシュボードでの可視化:
管理者がいつでもAPIコール数や消費トークン数、課金額などを確認できるダッシュボードを用意します。
閾値超過時の通知:
一定のしきい値（リクエスト数やコスト）が超えた場合や異常な挙動を検出した場合に、管理者へメールやアラートで通知が飛ぶように設定します。これによりリアルタイムに異常に気付けます。
主要プラットフォームの監視機能利用:
各生成AIプラットフォームが提供するモニタリング機能を活用します（例: Azure OpenAI ServiceではAzure MonitorでAPI呼び出し回数やトークン使用量を監視可能、Amazon BedrockではCloudWatchとEventBridgeで同様の監視が可能）。

 M-02: コンテンツフィルタリング概要:
生成AIの出力内容は、入力次第で暴力的・有害になったり、ユーザにとって不適切な回答を返すことがあります。
これを防ぐためにコンテンツフィルタリングが重要です。
フィルタリングすべき対象は2つあり、1つはユーザが入力する有害な入力（例: 悪意あるプロンプトや暴力・差別・わいせつな内容）に対するもの、もう1つはそれに応じてAIが生成した不適切な出力です。
両方にフィルターをかける必要があります。
対策:
入力と出力の双方でコンテンツフィルタリングを実施します。
入力フィルタリング:
利用者からのプロンプトに暴言や違法な指示、不適切な要求が含まれる場合はAIに渡す前にブロック・修正します。
また、明らかに**ポリシー違反のプロンプト（例えば差別発言の要求など）**には警告を出し受け付けないようにします。
出力フィルタリング:
生成AIが返す回答についてもモニタリングし、過激・有害なコンテンツや機密情報が含まれる場合はユーザに表示しない、あるいはマスク・要約した形で提供する、といった措置を講じます。
プラットフォームのガードレール活用:
主要クラウドAIサービスの組込みフィルタを活用します（例: Azure OpenAI Serviceにはコンテンツフィルタリングシステムがあり利用可能、Amazon Bedrockではガードレール機能でコンテンツフィルタを設定可能）。

 M-03: 履歴のモニタリング概要:
生成AIにどんな入力を行い、どんな出力が得られたかの履歴を記録・監視することは、万一機密情報を入力してしまった場合に「何が入力されたか」を調査したり、不審な入出力があった際の追跡に有効です。
ただし、すべての履歴を長期間保存するとストレージ容量を圧迫するため、保存期間のポリシーを定めて運用する必要があります。
対策:
履歴モニタリングは、問題発生時の調査に備えて一定期間のログを安全に保存することが基本です。実装例として:
モデル呼び出しログの活用:
例えばAmazon Bedrockでは「モデル呼び出しのログ記録」機能により、アカウントで実行した全リクエストとレスポンス、メタデータを収集できます。
このような仕組みを使い、誰がいつどんなプロンプトを送り何を回答されたか、を記録します。
ログの保護と期間:
記録した履歴ログは機密情報として厳重に保護し、不正アクセスされないようにします。
また保存期間は必要最小限にとどめ、定期的に古い履歴を削除するなど、プライバシーと容量に配慮します。
定期レビュー:
ログを監査し、不適切な利用（たとえば禁止されたデータ入力や目的外利用）がないか定期的にチェックします。
問題があればユーザへの注意喚起や追加教育につなげます。

 P-01: 生成AI利用に関するポリシーの整備概要:
生成AIサービスはWebブラウザ等から手軽に使い始められ、無料プランでも高度なテキスト生成などが可能です。
また最近の生成AIはテキストだけでなく、Word/Excel/PDFファイル、画像や音声、プログラムのソースコードの入出力や実行まで対応するものもあります。
利便性が高い反面、企業の機密情報や個人情報を誤って生成AIに入力してしまうと情報漏洩につながるリスクがあります。
これは、生成AIプロバイダが入力データを学習やモニタリング用に保持する場合があり、適切な設定（学習への未利用設定等）をしないと流出の可能性があるためです。
実際、企業向けプランでは「ユーザデータをモデル学習に利用しない」オプションが提供される場合もあるため、事前に確認が必要です。
また、生成AIの出力には事実誤認（ハルシネーション）やバイアス、文脈の欠落が含まれる場合があり、特に法律・医療・金融など専門分野では誤情報が重大な影響を及ぼす可能性があります。
そのため、生成AIから得られた文章や回答を鵜呑みにせず、利用者自身が必ず内容を検証・確認することが重要です。
さらに、生成AIの出力が既存の著作物と類似または一部一致する場合、著作権侵害に該当する恐れがあります。
モデルの訓練データに著作物が含まれている場合、AIがそれを再現してしまうリスクがあり、商用利用時には出力コンテンツの著作権チェックを徹底する必要があります。
以上の点を踏まえ、組織で生成AIサービスを利用する際にはAI利用ポリシーを策定し、以下の点を明確に定めることが重要です。

入力制限:
機密情報や個人情報は絶対に入力してはならないことを定める。


出力確認:
AIの回答に含まれる可能性がある虚偽情報や著作権侵害の有無をチェックする手順を定める。


利用範囲:
生成AIの利用目的・範囲を定義し、商用利用の可否や業務での適用ルールを設定する。


データ保持:
利用するAIプラットフォームがユーザデータをどう保持・利用するかを確認し、必要に応じ学習への不使用設定などを適用する。

このように適切なポリシーとルールを整備することで、組織として生成AIを安全かつ効果的に活用できるようになります。
対策:
ポリシー策定後は、それを組織全体で共有し徹底することが重要です。以下のポイントを盛り込んだポリシーを整備し、全社員に周知しましょう。
責任体制の明確化:
生成AIの開発・運用について責任部署と担当者を定義し、管理体制を構築する。
AI導入・利用に関する承認プロセスを設定し、適用範囲やリスクを管理する。
リスク承認の決裁レベルを明示し、経営会議やリスク管理委員会、IT部門などが適切に関与する仕組みを整える。
利用ルールと禁止事項の策定:
機密情報・個人情報のAIへの入力禁止を定め、誤って入力しないためのチェック体制を整える。
業務で利用してよい生成AIサービスを限定し、安全なプラットフォームのみ使うよう統制する。
著作権・商標権のリスクに配慮し、生成物の商用利用や公開時のレビュー手順を設ける。
例外承認プロセスの設定:
機密データをどうしてもAIで扱う必要がある場合の例外承認フローを明示し、特別な場合は適切な管理下で利用するルールを定める。
AIプラットフォーム側でデータが保持されるケースでは、情報セキュリティ部門や法務部門の承認を義務付け、監査可能な体制を敷く。
運用のモニタリングと定期的な見直し:
生成AIの利用ログを監査し、ポリシー違反や不適切な利用がないか定期チェックする。
技術動向・法規制の変化に応じ、ポリシーを定期的に更新し組織のリスク管理レベルを維持する。
従業員向けトレーニングを実施し、ポリシー遵守を徹底する（この点は次項P-02にも関連）。
!参考: ポリシー策定の参考として、IPAや日本ディープラーニング協会（JDLA）が公開している生成AI利用ガイドライン【参考資料あり】などがあります。自社の利用目的や業務に応じてこれらをカスタマイズし、自社ガイドラインとして制定・運用しましょう。

 P-02: 生成AI利用に関する教育概要:
生成AIの技術進歩は非常に速く、活用範囲も日々広がっています。そのため組織内で生成AIを利用する際、ポリシー整備だけでなく従業員への教育も不可欠です。
教育により、生成AI利用に関するリスクを最小化し、組織内でポリシーが一貫して遵守されるようになります。
特に、データの入力制限や出力の確認といった重要ポイントを周知することで、情報漏洩や誤情報提供を防ぐことができます。
また技術の進化が早い分野なので、教育は定期的に更新・実施することが推奨されます。
対策:
生成AI利用に関する教育は、情報セキュリティ教育や情報モラル教育と同様に定期的に実施します。
一度研修するだけでなく、最新の状況に応じて内容をアップデートし続けることが必要です。
教育内容の充実:

ポリシーとルールの理解: 自社で定めた生成AI利用ポリシーやルールをきちんと理解し、遵守を促す教育を行います。

セキュリティリスク意識: 機密情報・個人情報をうっかり入力しないよう注意喚起し、生成AIの出力に潜むリスク（誤情報、著作権侵害など）について具体例を交えて教育します。

適切な利用シナリオ: 生成AIをどういった業務で使うのが適切か/不適切かを示し、特に商用利用する際に必要なレビュー・承認プロセスを徹底するよう教えます。
教育方法:

eラーニング: 従業員が繰り返し学べ、参加の負担が少ないオンライン教材を用意し、ポリシーや基本ルールの理解を深めます。

シナリオベースの演習: 可能なら工数や費用はかかりますが、実際の業務シナリオを想定した机上演習を行い、生成AI利用時に起こり得るリスクや問題への対処を学びます。

ワークショップや勉強会: インタラクティブな場を設け、利用者の疑問を解消したり実際に手を動かしたりしながら学ぶ機会を提供します。ハンズオン形式にすることで理解度を高めます。
定期的な見直しと更新:

技術進展への対応: 生成AIに関する技術は日進月歩のため、新しい機能やリスクに対応できるよう教育内容や社内ルールも定期的に見直します。

法規制や倫理の変更への対応: AIを取り巻く法規制や社会的倫理基準が変化した際は、教育内容をアップデートし、従業員が常に最新の知識を持つようにします。
社外資格の活用（任意）:
例えばJDLAのGenerative AI Test（ジェネレーティブAI検定）【参考資料あり】は、生成AIの基礎知識から実務応用までカバーした認定資格です。社員のスキル証明や専門人材育成に有用で、社内教育の目標として活用できます。

 P-03: 法律や規制の確認概要:
生成AIの利用拡大に伴い、各国で関連する法規制の整備が進んでいます。
特にデータの取り扱いや、データの国際的な移転に関しては厳格な規制が設けられる場合が多いため、生成AIサービスを利用する際はサービス提供者の利用規約をよく確認することが重要です。
また、そのサービスが提供されている国・地域の法律や規制、およびデータの保存場所に関する法的要件についても確認する必要があります。
現時点で日本には生成AI固有の法律はありませんが、個人情報保護法、著作権法、不正競争防止法など既存の法律が生成AIの利用場面に適用されるケースが多くあります。
生成AIを業務利用する場合、こうした法令を遵守することが求められますし、今後もAI技術に関連する新たな法規制が整備される可能性があります。
対策:
生成AIサービス利用時には、そのサービスが適用国・地域の法規制に従って運用されているか確認することが不可欠です。
特に重要なポイントは次のとおりです。
サービス利用規約の確認:
利用する生成AIサービスの利用規約を読み、データの利用方針やプライバシー保護措置がどう記載されているか確認します。
とくに「ユーザデータを学習に使わない」といったオプションが提供されている場合は積極的に利用することが推奨されます。
法域の確認:
その生成AIサービスがどの国・地域の法律下で提供されているか、どの法域の規制を受けるかを確認します。
例えばサービス提供者の拠点がEUにある場合はGDPR（一般データ保護規則）への対応が必要ですし、米国なら州ごとのプライバシー法など厳格な規制があります。
それらに沿った運用をサービス側が行っているか把握します。
個人情報・機微情報の送信可否:
自社ポリシーに従い、機密情報や個人情報を生成AIに送信する必要がある場合、その送信先や保存先が法的に問題ないか確認します。
特にデータが国境を越えて送信・保存される場合、送信元・送信先双方のデータ保護法を遵守することが重要です。
複数拠点の法規制対応:
貴社が複数の国や地域で事業をしている場合、各拠点ごとに適用される法規制が異なる可能性があります。
それぞれの国・地域で必要な法遵守措置を取れる運用体制を整えます。
法制度の動向注視:
AIに関する法規制は各国で頻繁に更新・制定されています。
常に最新の規制動向をウォッチし、自社の法的要件を定期的に見直せる体制を整えておきます。
ライセンスや契約条項のレビュー:
利用する生成AIサービスの契約条件（利用許諾）を理解し、商用利用時の著作権やデータ使用に関する条項を十分確認します。
必要に応じて法務部門や弁護士の助言を仰ぎます。
!補足: 法規制や契約条項の詳細な解釈については、社内の法務担当者や専門の弁護士からアドバイスを受けることが推奨されます。特に異なる国の法律が絡む場合や契約が複雑な場合、専門家の見解が重要です。
なお、国際的な動向としてはAI Now Instituteによる各国のAI規制比較レポートなどが参考になります。
また米国では 「AI権利章典 (Blueprint for an AI Bill of Rights)」 といった生成AIを含むAI技術全般の基本指針が策定されつつあります。
EUでも AI規制法（AI Act） がまもなく成立予定であり、これらも注視が必要です。
（※出典ドキュメントのライセンスは**Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**です）

 所感明日時間取れたらチェックシート作成してみたいな（希望的観測）
GitHubで編集を提案
Discussion

ログインするとコメントできます