
LLM AI サイバーセキュリティとガバナンスのチェックリストとは、OWASP(ソフトウェアのセキュリティ向上に取り組むオープンコミュニティ)の大規模言語モデル アプリケーション リスク トップ10チームがまとめた、LLMを業務に取り入れる組織のための確認項目集です。自社でLLMを開発しない社員10〜200名の会社であれば、第三章の13領域のうち、ガバナンス・AI資産目録・研修・法務・ビジネスケースの5つを自社で満たし、技術寄りの領域は使うサービスの提供元に確かめる、という読み方で十分でしょう。モデル・カードやRAG、AIレッドチームといった開発者向けの領域まで、自社で抱え込む必要はありません。社内の生成AI対策を項目単位で見渡したい方は、生成AIセキュリティ対策チェックリスト30項目から先に読むことも出来ます。
※版と日付は、2026年10月3日にOWASPの公式ページ(genai.owasp.org)と日本語版PDFで確認した内容です。公式ページで確認できる最新は1.1版で、英語版・日本語版とも掲載日は2024年5月7日、日本語版PDFの日付は令和6年4月10日です。ライセンスはCC BY-SA 4.0で、PDFには法的助言ではない旨の注記があります。原文の項目は要約して紹介しています。
LLM AI セキュリティおよびガバナンスチェックリストとは|4章と13領域
このチェックリストは、LLMを使う・買う・作る組織が、導入の前後で見落としやすい論点を4つの章に分けて並べた資料になります。日本語版は31ページで、表題には「失敗しない大規模言語モデル導入のために」という副題が付いています。想定する読み手は、経営幹部・技術者・サイバーセキュリティ・プライバシー・コンプライアンス・法務などの各分野のリーダーです。開発部門を持たない会社の総務や情シス担当の方が読んでも、使える部分は多く残ります。
版は、英語版が2023年11月の0.1版から始まり、2024年4月10日の1.1版まで改定を重ねてきました。日本語版も同じ1.1版で、公式ページでは英語版・日本語版とも2024年5月7日に掲載されています。2026年10月3日時点で公式ページから確認できる最新は、この1.1版となります。
4つの章の中身
第一章は概要で、LLM固有の課題、AIの脅威の分類、研修、既存施策への組み込み、セキュリティの基本原則、リスクの種類が書かれています。第二章はLLM導入戦略の策定で、導入までの6つのステップと、使い方の違いによる6つの導入タイプが示されます。第三章が本体のチェックリストで、13の領域ごとに□付きの確認項目が並びます。第四章は参考資料の案内で、OWASP Top 10 for LLMやMITREの資料などが紹介されています。
第一章では、AIの脅威を「AIモデルを使わないことによる脅威」「使うことによる脅威」「狙われることによる脅威」「AIモデルが生み出す脅威」「法律と規制による脅威」の5つに分けて整理しているのが特徴です。使わないことも脅威に数えている点は、禁止だけで済ませようとする会社にとって見落としやすい視点となります。
第三章の13領域の一覧
第三章の13領域は次のとおりです。
- 敵対的リスク
- 脅威のモデリング
- AI資産目録
- AIセキュリティとプライバシー研修
- ビジネスケースの確立
- ガバナンス
- 法務
- 規制(米国、カナダ)
- LLMソリューションの使用または実装
- 試験・評価・検証・妥当性確認(TEVV)
- モデル・カードとリスク・カード
- RAG(大規模言語モデルの最適化)
- AIレッドチーム
前半の8つ(敵対的リスクから規制まで)は組織の判断や体制の話で、後半の5つはLLMを使う・作る技術の話という並びになっています。自社でLLMを開発しない会社が重く見るのは前半の8つのうち規制を除く7つで、後半は確かめる相手が提供元に変わります。7つのうち5つは自社の規程や台帳で満たし、敵対的リスクと脅威のモデリングは一部を提供元に確かめる形です。後半で自社が持つ作業は、「LLMソリューションの使用または実装」の手順づくりと、TEVV・RAGに伴う業務ルールの決定が中心と考えてみてください。
導入6タイプの早見|自社はどれに当たるか
社員がChatGPTなどをブラウザで使っている会社の多くは、第二章の導入タイプでいえばタイプ1〜3のどれかに当たります。タイプによって深く読むべき領域が変わるため、判断表に入る前に自社の位置を決めておきましょう。
| タイプ | 原文の説明(要約) | 原文の例 | 当てはまる会社の姿 | 深く読む領域 |
|---|---|---|---|---|
| 1 一般的な使用法 | LLMを一般向けの使い方で利用する | Perplexity、ChatGPT、big-AGI | 社員がWeb画面でAIを使っている | ガバナンス・研修・AI資産目録 |
| 2 モデルのAPI経由 | ベンダーが提供するAPIで利用する | Claude、ChatGPT、Gemini | 業務システムや法人向けサービスがAPIでAIを呼んでいる | 上に加えて法務・LLMソリューションの使用 |
| 3 モデルをライセンス | サポート付きの企業向けLLMを契約する | Microsoft Enterprise CoPilot、Amazon Codewhisperer、SalesForce Einstein GPT | グループウェアや業務アプリに組み込まれたAIを契約している | 上に加えてLLMソリューションの使用(最小権限) |
| 4 学習済みモデルを使う | 自社データで基盤モデルを微調整する | QwenLM/Qwen 1.5、DBRX、Starling 7B | 開発部門を持たない会社では該当しないことが大半 | TEVV・モデル・カード |
| 5 微調整済みモデルを使う | 特別仕様のモデルを自社データでさらに微調整する | Google MedPalm、Amazon Bedrock、Llama2、LegalAI | 同上 | TEVV・モデル・カード・RAG |
| 6 モデルを自社開発 | 自社仕様のAI/MLモデルを開発する | (例の記載なし) | 同上 | 13領域すべて |
原文はタイプ1と2の軽減策として、どちらにも会社の方針を決めて従業員のトレーニングを行うことを挙げています。タイプ1〜2の会社に求められているのは、技術的な対策より先に、方針と教育を整えることだと読めます。法人向けのAIサービスを契約し、提供元がAPIで各社のモデルにつないでいる形は、原文に専用の分類がありません。利用する会社から見ればタイプ1の使い勝手で、裏側ではタイプ2の接続を提供元が担っている、と置いて読むのが実務的です。この形では、APIの管理や接続の安全性は提供元に確かめる項目となり、自社に残るのは方針・教育・利用状況の把握になります。
13領域の判断表|関係するか・誰が担当か・何を確かめるか
13領域を、自社でLLMを開発しない会社の目線で1つずつ判定すると次の表になります。担当は社員10〜200名で専任の情シスがいない会社を想定し、兼務の前提で置いています。
関係の度合い:◎=自社の規程や台帳で満たす ○=一部を自社で行い、残りは提供元に確かめる △=自社の作業は読み替えや業務ルールの決定など軽いものに限り、中身は提供元の資料で確かめる
| 領域 | 関係 | 担当の目安 | 自社でやること | SaaS型の法人AIサービスを選ぶ時に確かめること |
|---|---|---|---|---|
| 敵対的リスク | ○ | 経営者・情シス兼務 | 生成AIで破られやすくなった本人確認(電話や声での確認など)を洗い出し、事故対応の手引きにAI絡みの攻撃を足す | サービス選びとは別に自社で行う |
| 脅威のモデリング | ○ | 情シス兼務 | なりすましのメールや偽の音声、社内での誤用を想定して書き出す | 不正な入力への対策や、外部からの不正アクセスへの備えの説明があるか |
| AI資産目録 | ◎ | 総務 | 使っているAIツール・所有者・扱うデータの機密性を台帳にする | 利用者と利用モデルを管理画面で確かめられるか |
| 研修 | ◎ | 総務・情シス兼務 | 全員向けと担当者向けに分けて行う | 管理者向けの説明や操作の案内があるか |
| ビジネスケース | ◎ | 経営者 | 使う業務と期待する効果を決める | 対象の業務で事前に試せる手段があるか |
| ガバナンス | ◎ | 経営者・総務 | RACI・AIポリシー・使ってよいツールの一覧表を作る | 使わせるAIを会社が選べるか、利用者ごとに制限できるか |
| 法務 | ◎ | 総務(必要に応じて顧問の専門家) | 利用規約・ベンダー契約・保険を見直す | プロンプトの扱い、出力の権利、データの扱い、責任の所在が規約に書かれているか |
| 規制(米国、カナダ) | △ | 総務 | 日本の法令やガイドラインに置き換えて読む | 個人データの扱いと保存場所の説明があるか |
| LLMソリューションの使用または実装 | ○ | 情シス兼務 | 権限・ログの確認方法・事故対応の手順を決める | 学習利用の扱い、ログの範囲、データの保存場所、SLA(サービス水準) |
| TEVV | △ | 情シス兼務 | 出力を人が確かめてから使う業務ルールを決める | 提供元がモデルの評価や更新をどう行うか |
| モデル・カードとリスク・カード | △ | 情シス兼務 | 使うモデルの公開資料の所在を目録に控える | 使えるモデルの名称が明示され、各モデルの公開資料をたどれるか |
| RAG | △(社内文書を読ませる場合は○) | 情シス兼務 | 読み込ませる文書の範囲を決める | 読み込ませた文書を参照できる範囲を設定できるか |
| AIレッドチーム | △ | 提供元 | 自社で攻撃の試験は行わない | 第三者による監査や脆弱性診断の有無を説明できるか |
◎の5領域が、自社の規程や台帳として形に残す範囲です。○の3領域は自社でやる部分と提供元に聞く部分が混ざるので、表の右の列を質問に変えて提供元に送ると進めやすくなります。△の領域は自社の作業を読み替えや業務ルールの決定に絞り、中身は提供元の公開資料で確かめる扱いで構いません。表の右の列は、後半に載せた確認質問のひな形と対応させています。
脅威のモデリングとAI資産目録|所有者・データ源・機密性を1枚に
開発をしない会社の脅威のモデリングは、構成図を描く作業ではなく、AIを使って自社がどう狙われるかと、社内でどう誤用されるかを書き出す作業になります。原文は、生成AIを使った大規模で高度ななりすまし攻撃や、LLMで狙いを絞ったスピア・フィッシング(特定の相手を狙った偽メール)を予測するよう求めています。さらに敵対的リスクの領域では、音声認識によるパスワードのリセットのように、従来は難しかった攻撃が生成AIで容易になった例を挙げ、効かなくなった管理策を調べるよう促します。
社員10〜200名の会社に当てはめると、社長や取引先を装った音声やメールでの振込依頼、AIツールへの顧客情報の入力といった場面が考えられます。電話一本で振込先を変えられる運用が残っていないか、まずは経理の手順を見直してみてください。
AI資産目録の列見本
AI資産目録は、社内で開発したものだけでなく、外部のサービスにも当てはめるよう原文で求められている台帳です。原文の項目は、AIサービス・ツール・所有者の記録と固有のタグ付け、AIに使うデータソースと機密性(保護・機密・公開)の記録、導入時の検査プロセスの策定などになります。SBOM(ソフトウェア部品表)にAI部品を含める項目もありますが、ソフトウェアを作らない会社では対象外として扱って差し支えありません。表計算ソフトで次の列を作れば、原文が求める記録をひととおり押さえることが出来ます。
| 列 | 記入例1 | 記入例2 |
|---|---|---|
| 管理番号(タグ) | AI-001 | AI-002 |
| ツール名・契約名 | 法人向けAIサービス(会社契約) | 会議の文字起こしツール(無料版) |
| 用途 | 文書の下書き・要約・翻訳 | 営業会議の議事録 |
| 利用者・人数 | 全社員 | 営業部の3名 |
| 契約の主体 | 会社 | 個人(未承認) |
| 所有者(責任者) | 総務部長 | 営業部長 |
| データソース | 社員が入力する文章・アップロードする文書 | 会議の録音 |
| 入力してよい機密区分 | 公開・社内限り(機密は承認制) | 公開のみ |
| 学習利用の設定 | 学習に使わない設定を会社で確認済み | 不明 |
| ログの有無 | 管理画面で確認できる | なし |
| 提供元への質問の回答 | 回答あり(回答日を記入) | 未送付 |
| 承認日・次の見直し | 導入した月・半年後 | 未承認(今月中に判断) |
記入例2のように、部署が独自に使い始めたツールが見つかったとき、禁止か承認かを決める場所として台帳が働きます。原文の機密性の3区分(保護・機密・公開)は、自社の情報分類が既にあればそちらに合わせて構いません。台帳に学習利用の設定とログの有無の列を入れると、不明のまま使われているツールが一目で分かります。
独自に使い始めるツールを減らすには、使ってよい環境を会社で1つにまとめる方法があります。UPGEAR AI(アップギアAI)は、ChatGPT・Claude・Gemini・Perplexityを1つの契約で使える法人向けサービスです(人数無制限)。
ガバナンスと法務|兼務で回すRACIとポリシー
ガバナンスの領域で原文が最初に挙げるのは、AIのRACIチャート(責任者・説明責任者・相談役・報告先を作業ごとに決める表)を作ることです。法務の領域ではIT・セキュリティ・法務の三部門の連携が不可欠とされていますが、社員10〜200名の会社でこの3部門がそろうことは多くありません。そこで、兼務を前提に役割を割り振った簡易版を置いておきます。
| 作業 | 経営者 | 総務 | 情シス兼務 | 各部署の責任者 |
|---|---|---|---|---|
| AIポリシーの決定 | A | R | C | I |
| 使ってよいAIツールの一覧表の公開 | A | R | C | I |
| AI資産目録の更新 | I | A | R | C |
| 新しいAIツールの導入審査 | A | C | R | C |
| 利用規約・ベンダー契約の確認 | A | R | C | - |
| 研修の実施 | I | A | R | C |
| 利用状況(ログ)の確認 | I | C | A・R | - |
| AI絡みの事故の初動 | A | R | R | I |
R=実際に作業する人、A=最終的な責任を持つ人(1つの作業に1人)、C=事前に相談を受ける人、I=結果の報告を受ける人。
Aは1つの作業につき1人に絞るのが原則で、経営者が全部のAを持つと判断待ちで止まりやすくなってしまいます。日常の更新作業は総務と情シス兼務に任せ、経営者は方針と事故対応の決裁に集中する形が回しやすいでしょう。
AIポリシーと一覧表に書くこと
原文のガバナンス領域には、データの分類と使用制限を決めるデータ管理ポリシーの例として、保護されたデータや機密データを会社が管理していないツールに入力しないと明記することが挙げられています。あわせて、従業員が使ってよい生成AIツールの一覧表を公開することも求められます。ポリシーの書き方そのものは、生成AIの社内ガイドラインの作り方で手順を確かめることが出来ます。
既存のセキュリティ・個人情報・委託先管理の規程にAIを組み込む
第一章は、AIの管理方法を既存の組織の慣行と統合し、既存のプライバシー・ガバナンス・セキュリティ施策に従わせ、必要に応じてAI固有の施策を作るよう勧めています。第二章の導入ステップでも、契約・NDA・ガバナンス・セキュリティの見直しにLLMを加えることと、第三者やベンダーのAI機能を精査できるよう第三者リスク管理を改めることが挙げられます。新しい規程を一から作るより、既存の規程にAIの扱いを1〜2行ずつ足すほうが現実的です。足す先は、情報セキュリティ規程の社外サービスの利用、個人情報取扱規程の委託先の管理、取引先との秘密保持契約が候補になります。法務の領域にある保険の見直し(会社役員賠償責任保険などがAIの利用を十分に補償しない可能性)も、次の更新時に保険会社へ一度確かめてみましょう。ベンダー契約に生成AIの適切な使用に関する条項を入れる項目は、AIを使って業務を受ける外注先との契約にも当てはまります。
AIセキュリティとプライバシー研修|全員向けと担当者向けを分ける
研修について原文が求めるのは、全従業員向けの教育と、人事・法務・開発・データ・セキュリティなど職種に合わせた教育の両方です。第三章の項目には、計画中のLLM導入について従業員の懸念を聞いて対処することや、倫理・責任・法的問題(保証・ライセンス・著作権)の理解を全員に徹底することが含まれます。セキュリティ意識向上の研修を更新し、ボイスクローニング(声の複製)やイメージクローニング、スピアフィッシングの増加を前提にした内容を入れることも項目の1つです。中小企業に置き換えるなら、全員向けと担当者向けの2本立てにすると無理なく回せます。
- 全員向け:入力してよい情報と入力してはいけない情報の線引き、会社が認めたAIツールの一覧と使い方、出力をそのまま社外に出さず人が確かめること、声や映像の偽物による振込依頼への確認手順、誤って入力したときの連絡先
- 担当者向け(総務・情シス兼務・各部署の責任者):AI資産目録の付け方と導入審査の流れ、利用規約で確かめる点(プロンプトの扱い・出力の権利・責任の所在)、管理画面での利用状況の見方、事故のときの初動
懸念を聞く項目は見落とされがちで、仕事を奪われるのか、入力した内容は誰に見られるのか、といった声を先に拾うと、ルールの受け止め方が変わります。
シャドーAI(野良AI)は研修と入口の一本化で減らす
原文は第二章で、多くの組織にとって差し迫ったLLMの脅威としてシャドーAIを挙げています。ここでのシャドーAIは、従業員が未承認のオンラインAIツールや安全でないブラウザのプラグインを使ったり、正規の承認手続きを経ずにLLM機能付きのアプリを使ったりする状態を指します。研修で禁止を伝えるだけでは、便利さを理由に個人の無料アカウントへ流れる動きは止まりにくくなってしまいます。使ってよいAIを会社で1つの入口にまとめて先に渡すことが、一覧表と研修を効かせる前提になります。実態の調べ方や対策の全体像は、野良AI(シャドーAI)とはで確かめてみてください。
提供元への確認質問のひな形|EULA・データ・ログ・モデルカード
技術寄りの領域を自社で抱えない代わりに、契約前の質問で提供元から答えをもらうのが、開発しない会社の進め方になります。法務領域のAI EULA(利用者向けライセンス契約)のレビュー、規制領域のベンダーへの聞き取り、LLMソリューション領域のログ・SLA・第三者監査、モデル・カード領域のカードの追跡を、質問の形に置き換えたのが次のひな形です。メールや問い合わせフォームにそのまま貼り付けて使うことが出来ます。
件名:AIサービスの導入検討にあたっての確認事項 〇〇株式会社 ご担当者様 貴社のAIサービスの導入を検討しております。社内の確認手続きのため、次の点についてご回答をお願いいたします。 【データの扱い】 1. 入力した文章やアップロードしたファイルは、AIモデルの学習に使われますか。使われない場合、その扱いは会社単位で適用されますか。 2. 会話履歴・利用ログ・アカウント情報は、どの国のサーバーに保存されますか。 3. 入力データの保存期間と、解約時の削除の方法を教えてください。 4. 各AIモデルの提供事業者の側では、入力データはどのように扱われますか(保存の有無・保持期間)。 【管理とログ】 5. 管理者は、誰が・いつ・どのAIを使ったかを確認できますか。記録の書き出しは可能ですか。 6. 利用者ごとに、使えるAIモデルや機能を制限できますか。 7. 退職者のアカウントはすぐに停止できますか。 【規約と責任】 8. 生成された文章や画像の権利は誰に帰属しますか。利用規約のどの条文に書かれていますか。 9. 情報漏えいなどの事故が起きた場合の連絡体制と、連絡までの目安を教えてください。 10. 稼働率などのサービス水準(SLA)の定めはありますか。 【モデルと検査】 11. 利用できるAIモデルの名称と、各モデルの公開資料(モデルカード等)の所在を教えてください。 12. モデルが更新・入れ替えされる際の通知の方法を教えてください。 13. 第三者による監査や脆弱性診断を受けていますか。受けている場合、概要を共有いただけますか。 14. 社内文書を読み込ませる機能がある場合、読み込んだ文書を参照できる範囲(利用者・部署)を設定できますか。 ご多忙のところ恐れ入りますが、よろしくお願いいたします。
回答は、AI資産目録の該当するツールの行に日付と一緒に残しましょう。回答が曖昧な項目は、利用規約やプライバシーポリシーの該当条文の場所を聞き返すと確かめやすくなります。複数のサービスを比べる段階なら、法人向け生成AI 38サービスの料金比較で候補を絞ってから質問を送ると手間を減らせます。
モデル・カード、TEVV、RAG、AIレッドチームは提供元の資料で読む
モデル・カードは、AIモデルの名前・版・学習データ・性能・偏りや限界などをまとめた標準的な文書で、原文はサードパーティ経由で使うモデルも含めてカードを追跡・維持するプロセスを作るよう求めています。利用する会社にとっては、質問11の回答で得た資料の所在を目録の行に書き足すことで、この項目の入口は満たせます。TEVV(試験・評価・検証・妥当性確認)はモデルの機能・安全性・信頼性を継続的に確かめる工程で、利用する側では出力を人が確かめてから使うという業務ルールに置き換えるのが実際的です。RAG(社内文書などを検索してから回答を作る仕組み)は社内文書を読み込ませる機能を使う場合にだけ関係し、質問14の参照範囲の確認が中心になります。AIレッドチーム(攻撃者の立場でAIを試験すること)は、原文でも単独では十分でなく他の評価と組み合わせる必要があるとされており、利用する側は第三者の検査の有無を聞く質問13で代えて構いません。
OWASP Top 10 for LLMは利用する側にどう関係するか
第四章には、LLMアプリケーションの代表的なリスクを10項目にまとめたOWASP Top 10 for LLMの2023年版が載っています。プロンプト・インジェクション、安全が確認されていない出力ハンドリング、訓練データの汚染、モデルのDoS、サプライチェーンの脆弱性、機微情報の漏えい、安全が確認されていないプラグイン設計、過剰な代理行為、過度の信頼、モデルの盗難の10項目です。Top 10はチェックリストとは別に改定されており、公式サイトには2025年版と、2026年8月3日に掲載された2026年版のページがあります。チェックリストの第四章は2023年版の項目名のままなので、Top 10の現在の項目は公式サイトで確かめてみてください。
10項目の多くはアプリを作る側の対策ですが、利用する会社に直接関係するのは、機微情報の漏えい、過度の信頼、プロンプト・インジェクションの3つでしょう。機微情報の漏えいは応答に機密データが混ざるリスクで、利用する側では入力してよい情報の線引きと学習利用の設定で備えることになります。過度の信頼は、AIの出力を確かめずに社外へ出してしまう失敗で、研修とTEVVの業務ルールで防ぐことが出来ます。
プロンプトインジェクションは使う側でも起きる
プロンプト・インジェクションとは、巧妙な入力でLLMを操作して意図しない動作を引き起こす攻撃で、原文はシステムのプロンプトを直接上書きする手法と、外部ソースからの入力を操作する間接的な手法があると説明しています。利用する側で気を付けたいのは間接的なほうで、AIに読み込ませたWebページやメール、取引先の文書の中に、AIへの指示が紛れ込んでいる場面が考えられます。外部から受け取った文書をAIに要約させるときは、出力に不自然な指示やリンクが混ざっていないかを確かめ、AIの答えだけで送金や外部への送信をしないよう研修で伝えましょう。AIに自動で操作を任せる機能を使う場合は過剰な代理行為の項目にも当たるため、与える権限を最小限に絞ることが原文の考え方に沿います。
規制の章は米国・カナダ向け|日本の会社の読み替え
第三章の規制の領域は表題どおり米国とカナダが中心で、EUのAI法は2024年時点の見込みとして、GDPR(EU一般データ保護規則)は生成AIに影響しうる既存の規則として触れられています。州ごとの従業員の電子的な監視や、顔認識の同意に関する項目は、日本の会社にはそのまま当てはまりません。一方で、ベンダーが機密データを収集しているかを尋ねて文書化する、ベンダーがデータをどう保存・削除するかを尋ねる(原文は採用時の顔認識・ビデオ分析ツールの文脈)、採用や人事管理に使うAIツールを確認する、といった項目は国を問わず使えます。日本の会社は、国内の法令やガイドラインに当てはめて読み替える必要があります。
日本で当てはめる主な法令・ガイドライン
- 人工知能関連技術の研究開発及び活用の推進に関する法律(AI推進法・令和7年法律第53号):内閣府によると、令和7年6月4日に公布・一部施行され、同年9月1日に全面施行されました。第7条は、事業活動でAIを活用しようとする者に、積極的な活用に努めることと、国や地方公共団体の施策への協力を求めています。罰則を定めた条文は見当たりません。
- AI事業者ガイドライン(第1.2版・総務省と経済産業省・令和8年3月31日):事業者を「AI開発者」「AI提供者」「AI利用者」の3つに大別しており、自社で開発しない会社は主にAI利用者に当たります。法的拘束力のないソフトローの位置づけです。
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」(令和5年6月2日):個人情報を含むプロンプトの入力が利用目的の達成に必要な範囲内かを十分に確認すること、本人の同意なく個人データを含むプロンプトを入力し、それが応答の出力以外の目的で扱われる場合は法違反となる可能性があることを示し、提供事業者が機械学習に利用しないこと等を十分に確認するよう求めています。
米国・カナダの項目を日本の法令に置き換える作業は、法務の領域と同じく総務が持ち、判断に迷う点だけ顧問の専門家に確かめる形が現実的です。特に個人情報保護委員会の注意喚起は、提供元への質問1〜4と対応するため、回答の控えが社内の確認記録として役立ちます。
会社で使うAIの入口を1つにすると満たしやすくなる項目
13領域のうち自社で満たす◎の領域は、社員が使うAIの入口が1つにまとまっているかどうかで手間が大きく変わります。入口が個人の無料アカウントや部署ごとの契約に分かれていると、目録の行は増え、一覧表が守られているかも確かめようがなく、利用の記録も集まりません。反対に入口が1つなら、原文の項目を次のように満たしやすくなります。
- ガバナンスの一覧表使ってよいツールの一覧表が短くなり、社員に伝わりやすくなります。使わせるAIモデルを会社で選べるサービスなら、方針と実際の設定をそろえられます。
- AI資産目録の記録主な行が1つにまとまり、学習利用の設定やログの有無を1か所で記録できます。
- LLMソリューションの監視と応答利用者・日時・使ったモデルの記録が1か所に集まり、事故のときに確かめる場所が決まります。
- 研修の中身教える画面と手順が1つになり、許される使い方と許されない使い方を具体的に示せます。
- シャドーAIへの対処業務で使える入口を先に渡せるため、禁止だけに頼らずに未承認ツールを減らせます。
入口を1つにしても、入力してよい情報の線引き、出力を人が確かめる工程、規約や保険の見直しは、会社の側で決める必要が残ります。複数のAIを1つの環境でまとめて使う形の選び方は、マルチAIとはで比べることが出来ます。
最初の1か月で手を付ける6項目
判断表の◎から、少人数の兼務体制でも1か月で形にしやすい順に並べると次のようになります。
- 1週目 AIの利用状況を聞き取る社内で使われているAIツールを部署ごとに聞き取り、AI資産目録に書き出します。
- 1週目 最終責任者を決めるRACIの簡易版で、作業ごとにAを持つ人を1人ずつ決めます。
- 2週目 一覧表とポリシーを公開する使ってよいAIツールの一覧表と、入力してはいけない情報を決めて社内に公開します。
- 2〜3週目 提供元に質問を送る確認質問のひな形を使う予定のサービスに送り、回答を目録に残します。
- 3週目 既存の規程に書き足す情報セキュリティ規程・個人情報取扱規程・秘密保持契約に、AIの扱いを1〜2行ずつ足します。
- 4週目 全員向けの研修を行う線引きと一覧表を説明し、誤って入力したときの連絡先を伝えます。
事故対応の手引きへのAI絡みの攻撃の追加や、保険の見直しは、2か月目以降の見直しの機会に回しても構いません。チェックリストは一度で埋め切るものではなく、原文自身も全ての使用ケースを網羅するものではないと断っています。半年ごとに目録と一覧表を見直す日を、今のうちに予定表へ入れてみてください。
使うAIの入口を、会社で1つに
UPGEAR AIは、ChatGPT・Claude・Gemini・Perplexityを1画面で切り替えて使える法人向けのAI基盤です。全モデルで学習非利用を標準適用し、管理画面ではUPGEAR AI上の利用状況を利用者・日時・利用モデル単位まで把握でき、CSVでの書き出しにも対応します。特定のAIモデルの利用禁止や、管理者のみの利用への制限も可能です。会話履歴・利用ログ・アカウントの管理は国内サーバー(AWSの日本リージョン)で行います。料金は月額30,000円(税抜)から。どのプランも利用人数は無制限で、料金は利用量に応じたプラン設計です(人数の目安はライト1〜5名、スタンダード6〜20名、プレミアム21〜50名)。初期費用100,000円(税抜)が別途かかります。
UPGEAR AIの詳細を見るよくある質問
OWASPのLLMチェックリストの日本語版はどこで入手できますか?
LLMを自社開発しない会社でも、このチェックリストを使う意味はありますか?
OWASP Top 10 for LLMとチェックリストは何が違いますか?
規制の章が米国・カナダ向けですが、日本の会社はどう読めばよいですか?
専任の情シスがいない会社では、誰が担当すればよいですか?
まとめ
OWASPのLLM AI サイバーセキュリティとガバナンスのチェックリストは、LLMを使う・買う・作る組織向けに4章・13領域で論点を並べた資料で、公式ページで確認できる最新は1.1版になります。自社でLLMを開発しない会社は、ガバナンス・AI資産目録・研修・法務・ビジネスケースを自社の規程と台帳で満たし、モデル・カードやRAG、レッドチームなどの技術寄りの領域は提供元への質問で確かめる、という分担で読むことが出来ます。規制の章は米国・カナダ向けのため、日本の法令やガイドラインに置き換えて読む必要があります。まずは社内で使われているAIを目録に書き出すところから始めてみましょう。
会社が把握していないIT全般をどう見つけて減らすかは、シャドーITとは?シャドーAIとの違いと会社での見つけ方で整理しています。情報漏洩を防ぐために会社が確かめる条件は、AI・生成AIの情報漏洩対策にまとめています。導入の費用を抑えたい場合は、デジタル化・AI導入補助金の対象になるかも確かめておきましょう。
法人のAI活用に関するほかの記事は、AI活用コラム一覧にまとめています。
