- 5.1.A. [Required] ハルシネーションへの対処方法が具体的に示されている [NIST-GAI] [JDLA] [FUJITSU]
- 説明: 生成AIは事実に基づかない情報をもっともらしく出力する
（ハルシネーション）。この特性を利用者が知らなければ、
誤情報をそのまま業務に使ってしまう。
「AIが言ったから正しい」は最も危険な思い込みである。
- 定義例: 「生成AIはもっともらしい誤情報を出力することがある
（ハルシネーション）。AI出力は必ず事実確認し、
確認できない情報は『未検証』と明示する」
- 5.1.B. [Required] 生成AIの限界・不得意分野が説明されている [NIST: MAP 2.2] [FUJITSU]
- 説明: 生成AIは万能ではなく、最新情報の取得、正確な数値計算、
専門的な法的判断などに弱い。限界を知らない利用者はAIに不適切なタスクを任せ、
誤った結果を信頼してしまう。
- 定義例: 「生成AIは以下の領域で誤りやすい：
①最新の情報（学習データの時点以降）、②正確な数値計算、
③専門的な法的・医学的判断、④ローカルな固有情報。
これらの領域ではAI出力を参考程度にとどめる」
- 5.1.C. [Recommended] 出力の信頼度を判断するためのガイダンスがある [NIST: MEASURE 2.5]
- 説明: AI出力の信頼度は問いの種類で大きく異なる。
一般知識の要約と専門的判断では確からしさが違う。
利用者が信頼度を大まかに判断できる指針があると、
過信と過度な不信の両方を防げる。
- 定義例: 「AI出力の信頼度の目安：
①一般知識の要約・翻訳＝比較的信頼できるが確認は必要、
②専門分野の判断・最新情報＝信頼度が低く必ず専門家や一次情報で確認、
③数値・固有名詞＝誤りが多いため必ず裏取りする」
- 5.1.D. [Option] 継続的なテスト・検証の仕組みがある [NIST: MEASURE 2.4]
- 説明: AIサービスはプロバイダー側のモデル更新により、
同じプロンプトでも出力品質が変わりうる。
定期的に出力品質を確認することで劣化や変化へ早期に気づけるが、
小規模組織では体系的なテストは負荷が大きい。
- 定義例: 「主要な業務用途（文書要約・翻訳等）について、
半年に1回程度、同一のサンプルプロンプトでAI出力の品質を確認し、
著しい変化がないか検証する」
- 5.2.A. [Required] 安全に関わる業務での利用制限が明記されている [NIST: MEASURE 2.6] [METI]
- 説明: 法的判断、財務判断、健康に関する助言など、
誤りが重大な実害につながる業務でAI出力をそのまま使うと危険である。
制限の明示がなければ「AIが言ったから」で済ませる運用が常態化する。
- 定義例: 「法的判断、財務判断、健康に関する助言など、
誤りが重大な実害につながる業務では、
生成AIの出力を最終判断の唯一の根拠として使用してはならない」
- 5.2.B. [Required] 人間の最終判断を要する場面が特定されている [NIST: MAP 3.5] [METI]
- 説明: AI出力を鵜呑みにせず人間が最終判断すべき場面を
あらかじめ特定する。場面が未定義だと判断の丸投げが起き、
責任の所在も曖昧になる。
- 定義例: 「以下の場面ではAI出力にかかわらず人間が最終判断する：
①顧客への助言・提案、②契約・法的文書の作成、
③人事評価、④対外公表物の内容確定」
- 5.2.C. [Recommended] 緊急停止・利用中止の基準と手順がある [NIST: MANAGE 2.4]
- 説明: AIサービスに重大な問題（情報漏えい発覚、
規約の大幅変更等）が発生した際の停止基準と手順が必要。
基準がないと「様子を見よう」で対応が遅れる。
- 定義例: 「以下の場合はAI利用を即座に停止し責任者へ報告する：
①情報漏えいの疑い、②サービス規約の重大変更、
③継続的な誤出力の発生。停止判断は管理部門が行う」
- 5.2.D. [Option] 残存リスクの文書化がされている [NIST: MANAGE 1.4]
- 説明: ガイドラインを整備してもゼロリスクにはならない。
受容している残存リスクを文書化しておくと
インシデント発生時の対応判断の基盤となる。
ただし形式的な文書化は小規模組織では負荷が大きい。
- 定義例: 「ガイドライン適用後も残るリスク
（ハルシネーションの完全排除不可等）を一覧化し、
各リスクへの対処方針（受容・軽減・回避）を年1回見直す」
- 5.3.A. [Required] 承認されたツール・サービスのリストがある [IPA] [JDLA]
- 説明: 組織が利用を認めるAIツール・サービスを一覧化する。
リストがなければ各自が見つけたツールを勝手に使い始め、
セキュリティ管理が不可能になる。
特に生成AIは無料で手軽に利用できるサービスが多く、
従業員が組織の承認なく業務で利用する
「シャドーAI」のリスクが高い。
シャドーAIは情報漏えいやコンプライアンス違反の
温床となるため、承認済みリストの整備と周知が不可欠である。
- 定義例: 「利用を承認するAIサービスは以下の通り：
①○○（テキスト生成）。
新たなサービスの追加は管理部門の承認を経ること」
- 5.3.B. [Required] 未承認ツールの利用禁止が明記されている [IPA] [JDLA]
- 説明: 承認リスト（5.3.A）があっても禁止が明記されていなければ
「リストにないだけで禁止ではない」と解釈される。
明示的な禁止規定がルールの実効性を担保する。
- 定義例: 「承認リストに記載のないAIツール・サービスの
業務利用は禁止する。
個人契約のAIサービスを業務データで使用することも禁止する」
- 5.3.C. [Required] アカウント管理（共有禁止、MFA等）のルールがある [IPA]
- 説明: AIサービスのアカウント共有は、
誰がいつ何を入力したか追跡できなくなる。
インシデント発生時の原因特定が不可能になる。
- 定義例: 「AIサービスのアカウントは1人1つとし共有を禁止する。
パスワードは組織のポリシーに従い、
多要素認証が利用可能な場合は必ず有効にする」
- 5.3.D. [Recommended] プロンプトインジェクション等の攻撃への注意喚起がある [NIST-GAI] [IPA]
- 説明: 悪意あるプロンプトによりAIが意図しない情報を出力する
攻撃がある。SaaS利用では防御の主体はプロバイダ側だが、
利用者も手口を知ることで被害を軽減できる。
- 定義例: 「外部から取得したテキスト（Webページ、メール等）を
AIへ入力する際は、悪意ある指示が埋め込まれている
可能性に注意する。不審な出力があれば利用を中止し報告する」
- 5.3.E. [Option] API利用時のセキュリティ要件が定められている [IPA]
- 説明: APIでAIを利用する場合、APIキーの管理、
通信の暗号化、入出力のログ管理等の要件が必要。
小規模組織ではWeb UI利用が主でAPI利用は限定的。
- 定義例: 「AIサービスのAPIを利用する場合は、
APIキーを環境変数で管理しコードへ直接記載しない。
通信はHTTPSを使用しAPIキーは定期的にローテーションする」
- 5.3.F. [Option] データポイズニングへの対策が考慮されている [NIST-GAI]
- 説明: 学習データへ悪意あるデータを混入させ
モデルの出力を操作する攻撃。
SaaS利用者が直接防御する手段はないが、
出力の不自然な偏りに気づく意識は持つべきである。
- 定義例: 「AIの出力に不自然な偏りや繰り返しパターンが
見られた場合はデータポイズニングの可能性を考慮し、
管理部門へ報告のうえ当該出力を業務に使用しない」
- 5.3.G. [Option] モデル抽出・メンバーシップ推論攻撃への対策がある [NIST-GAI]
- 説明: モデルの挙動から学習データを推測する攻撃手法。
SaaS利用者に直接的な防御手段はないが、
入力データが学習に使われるリスクの認識は必要。
- 定義例: 「AIサービスのデータ学習利用ポリシーを確認し、
入力データがモデル学習に利用されない設定を選択する。
設定不可の場合は機密情報の入力を避ける」
- 5.4.A. [Option] AI利用の記録・ログ保存の要件がある [NIST: GOVERN 4.2] [METI] [EU-AIA] [AIACT-JP]
- 説明: AI利用の記録はインシデント時の追跡や改善に役立つ。
ただしSaaS型サービスでは会話内容レベルのログ管理機能が
限定的で、小規模組織では体系的な記録保存は負荷が大きい。
- 定義例: 「重要な業務判断にAIを利用した場合は、
利用日時・目的・主な出力内容を簡易に記録する。
全会話の保存は求めない」
- 5.4.B. [Required] 意思決定過程の説明責任に関する指針がある [NIST: MEASURE 2.8] [METI] [AIACT-JP]
- 説明: AIを使った意思決定の過程を説明できなければ、
結果への責任を果たせない。
「AIが出した結論です」は説明にならない。
AI推進法第3条第4項は「過程の透明性の確保」を
基本理念として明記しており、
AI利用の意思決定過程を説明できる体制は法的にも求められている。
- 定義例: 「AIを活用した意思決定では、
AI出力をどう参考にし最終判断へ至ったかを
関係者へ説明できるようにする」
- 5.4.C. [Recommended] ステークホルダーへの情報開示方針がある [NIST: GOVERN 5.1] [METI] [AIACT-JP]
- 説明: AI利用に関する情報をどの範囲で開示するかの方針。
方針がないと外部からの問い合わせへの対応が場当たり的になる。
- 定義例: 「組織のAI利用方針は、要請があった場合に
顧客・取引先へ概要を説明できるよう整理しておく。
利用サービス名や入力データの取扱方針を含む」
- 5.4.D. [Option] 学習データの出所（プロベナンス）の確認がある [NIST-GAI]
- 説明: AIモデルがどのようなデータで学習されたかの確認。
SaaS利用者がプロバイダの学習データを直接確認する手段は
限られるが、公表情報の把握は有用。
- 定義例: 「利用するAIサービスについて、
プロバイダが公表する学習データの概要・方針を確認し、
著作権や倫理上の懸念がないか把握する」
- 5.5.A. [Required] AI出力の根拠について説明を要する場面が特定されている [NIST: MEASURE 2.9] [METI]
- 説明: 顧客への助言や報告書作成など、
AI出力の根拠を問われる場面では
「AIがそう言った」では説明にならない。
説明が必要な場面を事前に特定しておく。
- 定義例: 「以下の場面ではAI出力の根拠を説明できること：
①顧客への助言・提案、②報告書・提出物の作成、
③組織の意思決定に関わる分析」
- 5.5.B. [Recommended] 説明が困難な場合の対応方針がある [NIST: MEASURE 2.9]
- 説明: 生成AIの内部動作は利用者からは不透明であり、
出力の根拠を完全に説明できない場合がある。
対処方針がないと利用可否の判断が曖昧になる。
- 定義例: 「AI出力の根拠を十分に説明できない場合は、
当該出力を意思決定の主要根拠としない。
補助的な参考にとどめ別の情報源で裏付ける」
- 5.5.C. [Option] 利用者の役割・知識レベルに応じた説明方法がある [NIST]
- 説明: 管理者と現場担当者ではAIリスクの理解度が異なり、
説明の粒度を変える必要がある。
ただし小規模組織では全員がほぼ同レベルの場合が多い。
- 定義例: 「AI出力の説明は相手の役割に応じて
技術的な詳細度を調整する。
顧客には平易な言葉で結論と根拠を説明する」
- 5.6.A. [Recommended] プライバシー影響評価の実施要否基準がある [NIST: MEASURE 2.10] [METI]
- 説明: 新たなAI活用場面でプライバシーへの影響を
事前に評価すべきかの判断基準。
基準がないと評価の要否が場当たり的になる。
形式的なPIAは小規模組織には重いが判断基準は持つべき。
- 定義例: 「個人情報を含む可能性のあるデータをAIへ入力する場合、
または新たなAI活用場面を導入する場合は、
プライバシーへの影響を事前に確認する」
- 5.6.B. [Required] データ最小化の原則が示されている [NIST] [METI]
- 説明: AIへの入力は業務目的に必要な最小限のデータにとどめる。
不要なデータを入力すれば漏洩リスクが不必要に拡大する。
「念のため全部入れておこう」は最悪のアンチパターン。
- 定義例: 「生成AIへの入力は業務目的の達成に
必要最小限の情報にとどめる。
不要な個人情報や機密情報を含めてはならない」
- 5.6.C. [Required] 個人の権利（アクセス、削除等）への対応方針がある [METI] [EU-AIA]
- 説明: 個人情報保護法は本人からの開示・訂正・削除請求への
対応を義務付けている。AI利用で新たな個人データ処理が
生じた場合の対応方針がないと法的義務を果たせない。
- 定義例: 「AI利用に関して本人から開示・削除等の請求があった場合は
個人情報保護方針に従い対応する。AIサービスへ入力した
個人データの削除はサービス提供者の方針も確認する」
- 5.6.D. [Option] プライバシー強化技術（PETs）の活用が検討されている [NIST]
- 説明: 差分プライバシーや合成データ生成など、
プライバシーを技術的に保護する手法の総称。
有効だが小規模組織での導入は技術的ハードルが高い。
- 定義例: 「AIへの入力データの匿名化手法について
技術動向を把握し、実用的な手法が利用可能になった場合は
導入を検討する」
- 5.7.A. [Recommended] バイアスの種類と影響が説明されている [NIST] [METI] [FUJITSU]
- 説明: 生成AIは学習データに含まれるバイアスを反映して
出力する。性別・人種・地域等の偏りが含まれうることを
利用者が認識していないと偏った情報を無批判に受け入れてしまう。
- 定義例: 「生成AIの出力には学習データに由来するバイアス
（性別・人種・地域等の偏り）が含まれうる。
AI出力を評価や判断に用いる際はバイアスの可能性を意識する」
- 5.7.B. [Recommended] 人事・採用等の判断でのAI利用に関する注意事項がある [EU-AIA] [METI]
- 説明: 人事・採用は個人の権利に直接影響する領域であり、
AIバイアスの影響が最も深刻な分野の1つ。
小規模組織でAIを人事判断に使う場面は少ないが、
利用する場合の注意喚起は必要。
- 定義例: 「人事評価、採用選考、昇進判断等にAIを利用する場合は
バイアスによる差別が生じないよう特に注意し、
AI出力を唯一の判断基準としない」
- 5.7.C. [Option] バイアスを検出・軽減するための方策が示されている [NIST: MEASURE 2.11] [METI]
- 説明: バイアスの検出・軽減は技術的に高度で、
SaaS利用者が直接モデルを調整する手段はない。
出力の偏りに気づいた場合の対処を定めておくことが現実的。
- 定義例: 「AI出力に偏りやステレオタイプ的表現を発見した場合は
当該出力を使用せず、異なる表現でプロンプトを再作成するか
人間が修正する」
- 5.7.D. [Option] 多様性・公平性の観点からのレビュー体制がある [NIST: GOVERN 3.1]
- 説明: AI出力を多様性・公平性の観点から確認する体制。
大規模組織では専門チームが担うが、
小規模組織では日常的なレビュー体制の構築は困難。
- 定義例: 「対外公表物にAI出力を使用する場合は
多様性・公平性の観点から内容を確認する。
不適切な表現や偏りがないか複数人でチェックする」
- 5.7.E. [Option] システム的バイアス、統計的バイアス、認知バイアスの区別がある [NIST]
- 説明: バイアスには社会構造に起因するもの、
データの偏りに起因するもの、人間の認知傾向に起因するものがある。
区別の理解でより的確な対策が取れるが、
詳細な分類は教育目的としての位置づけ。
- 定義例: 「研修等で以下のバイアスの違いを説明する：
①システム的バイアス（社会構造由来）、
②統計的バイアス（データの偏り由来）、
③認知バイアス（人間の思い込み由来）」