各チェック項目に付与したガイドライン準拠レベル（Required / Recommended / Option）の
判断根拠を記載します。
ガイドライン作成者が自組織への適用可否を判断する際の参考資料として活用されたい。
判断の基本方針は次の通りです。
- Required: 欠落するとガイドラインとして機能しない、
または法令違反・重大リスクに直結する項目
- Recommended: ガイドラインの実効性を高める重要な項目。
除外する場合はその理由を説明できること
- Option: 記載があると望ましい項目。
組織の規模や業種に応じて検討する
なお、本チェックリストの主な対象は、専門のIT部門や技術者がいない小規模組織を想定しています。
ガイドライン準拠レベルの判断にはこの前提が反映されています。
| 項目 | レベル | 判断根拠 |
|---|
| 1.1.A. 最終責任者の明確化 | Required | ガバナンスの根幹。責任者不在ではインシデント時に判断が宙に浮く |
| 1.1.B. 担当部門・担当者の指定 | Required | 日常管理の起点。不在だと“野良AI“状態を招く |
| 1.1.C. 部門横断的な推進体制 | Recommended | 死角を防ぐ上で重要だが、小規模組織では外部専門家を含む体制構築が現実的に困難な場合がある |
| 1.1.D. 役割と責任の文書化 | Required | 責任の所在が曖昧だと機能不全に直結する。口頭合意は人事異動で失われる |
| 1.1.E. エスカレーションルート | Required | インシデント初動の遅れは被害拡大に直結する |
| 1.1.F. 多様な視点のチーム構成 | Option | 重要だが、小規模組織では人員構成上の制約が大きい。ベストプラクティスとしての位置づけ |
| 項目 | レベル | 判断根拠 |
|---|
| 1.2.A. 目的・方針の明記 | Required | 目的のないガイドラインは形骸化する。文書の根幹 |
| 1.2.B. 適用範囲の明確化 | Required | 範囲が曖昧だと「自分は対象外」の逃げ道が生まれ、ガイドラインが機能しない |
| 1.2.C. 既存ポリシーとの整合性 | Required | 矛盾があると現場が混乱し、既存の情報セキュリティ体制まで崩れる |
| 1.2.D. 関連法令への言及 | Required | 法令に触れていなければ、知らずに法令違反を犯すリスクに直結 |
| 1.2.E. 定期的な見直し・更新 | Recommended | AI技術・法規制の変化は速く重要だが、仕組みの欠落が直ちに法令違反にはならない |
| 1.2.F. リスク許容度の定義 | Recommended | 判断の一貫性に寄与するが、小規模組織では暗黙の合意で運用できる場合もある |
| 項目 | レベル | 判断根拠 |
|---|
| 1.3.A. 従業員向け研修の計画 | Required | 読まれないガイドラインは存在しないのと同じ。研修なしでは実効性がない |
| 1.3.B. ITリテラシーレベル別教育 | Recommended | 効果的だが、小規模組織では全員同一研修でも最低限は機能する |
| 1.3.C. 新規利用者のオンボーディング | Required | 1.3.A（研修）がRequiredである以上、新規入職者がその研修を通らずにAIを使える状態はRequiredの抜け穴になる |
| 1.3.D. 継続的な啓発活動 | Recommended | 形骸化防止に重要だが、欠落が直ちに重大リスクにはならない |
| 項目 | レベル | 判断根拠 |
|---|
| 1.4.A. 利用状況のモニタリング | Option | 本来は必要だが、現状の主要SaaS型AIサービス（Claude、ChatGPT等）は会話内容レベルの管理者向け監視機能を提供しておらず、実現手段が限られる。利用量の確認やセルフチェックが現実的な対応 |
| 1.4.B. 定期的な監査・レビュー | Option | 1.4.Aのモニタリングが Option である以上、それを補完する位置づけの監査も同レベル |
| 1.4.C. 違反時の対応プロセス | Required | 場当たり的な対応はルールの信頼性を崩壊させる。公正な運用の基盤 |
| 1.4.D. インベントリ管理 | Recommended | 管理対象の可視化は重要だが、小規模でツール数が少なければ暗黙的に把握可能 |
| 1.4.E. サービス提供終了・重大変更時の対応方針 | Recommended | 業務停止リスクはあるが直ちに法令違反にはならない。平時からの備えとして推奨 |
| 項目 | レベル | 判断根拠 |
|---|
| 2.1.A. 業務・ユースケースの特定 | Required | 利用対象が不明なままではリスク評価も効果測定もできない |
| 2.1.B. 期待効果の文書化 | Required | ユースケースの特定（A）とセットで導入の正当性を担保する |
| 2.1.C. 想定ユーザーと利用方法の定義 | Required | ユーザーにより入力データのリスクが異なる。リスク管理の前提 |
| 2.1.D. 使用すべきでない業務・場面の明記 | Required | 禁止ラインの明示がなければ重大リスク領域での誤用を防げない |
| 2.1.E. ビジネス価値・目的の定義 | Required | 「理事長がAIやろう」式の無計画導入を防ぐ。導入責任者は明確なビジネス価値を示すべき |
| 2.1.F. ミッション・目標との整合性確認 | Required | AI導入が組織の方向性と矛盾しないことの確認は基本要件 |
| 項目 | レベル | 判断根拠 |
|---|
| 2.2.A. 情報漏えいリスクの評価 | Required | 生成AI最大のリスク。何を投入してよいか評価・決定なしでの導入は論外 |
| 2.2.B. 著作権・知的財産権侵害リスクの評価 | Required | 法令違反に直結。文化庁見解でも依拠性推認の可能性あり |
| 2.2.C. ハルシネーションリスクの評価 | Required | 生成AIの構造的特性。評価なしでは誤情報の業務流入を防げない |
| 2.2.D. バイアス・公平性リスクの評価 | Recommended | 人事・評価での利用がなければ影響は限定的。利用形態に依存する |
| 2.2.E. プライバシーリスクの評価 | Required | 個人情報保護法に直結 |
| 2.2.F. セキュリティリスクの評価 | Required | AI固有の攻撃手法を理解しないまま導入するのは危険 |
| 2.2.G. 法的リスクの評価 | Required | 法令違反の認識欠如は免責にならない |
| 2.2.H. レピュテーションリスクの評価 | Recommended | 外部公開しない用途であれば影響は限定的 |
| 2.2.I. 業務依存リスクの評価 | Recommended | 重要だが、導入初期では影響が顕在化しにくい |
| 2.2.J. 環境負荷・サステナビリティの考慮 | Option | 望ましいが、小規模組織の利用量では実質的影響が小さい |
| 項目 | レベル | 判断根拠 |
|---|
| 2.3.A. AIサービス・ツールの選定基準 | Required | 基準なしでは部門ごとにバラバラなツールが乱立し、リスク管理が崩壊する |
| 2.3.B. 利用規約・プライバシーポリシーの確認プロセス | Required | 規約未確認での導入は「学習利用あり」等の重大条項を見落とすリスク |
| 2.3.C. データの取り扱い（学習利用の有無等）の確認 | Required | 情報漏えいリスク評価（2.2.A）の具体的実行手段。学習利用の確認は最低限必須 |
| 2.3.D. サービス停止・変更時の対応策 | Recommended | 1.4.Eと関連。事業継続上重要だが、直ちに法令違反にはならない |
| 2.3.E. サプライチェーン全体でのリスク管理 | Option | 基盤モデル提供者の把握は望ましいが、小規模組織が実効的に管理するのは現実的に困難 |
| 項目 | レベル | 判断根拠 |
|---|
| 3.1.A. 入力禁止情報のリスト化 | Required | 入力禁止リストはガイドラインの中核機能。これがなければ「何を入れてはいけないか」が不明で、ガイドラインとして機能しない |
| 3.1.B. 個人情報 | Required | 個人情報保護法に直結。違反は法的制裁の対象 |
| 3.1.C. 機密情報 | Required | 不正競争防止法上の保護喪失リスク。一度失われた秘密性は回復不能 |
| 3.1.D. 顧客情報 | Required | NDA・守秘義務違反に直結。顧客からの信頼喪失は事業継続に影響 |
| 3.1.E. 認証情報 | Required | セキュリティの基本中の基本。漏洩は即座に不正アクセスリスクとなる |
| 3.1.F. 財務情報 | Required | 未公開財務情報の漏洩はインサイダー取引規制・金融商品取引法上の問題に発展しうる。経営相談を扱う組織では漏洩リスクは重大 |
| 3.1.G. 人事情報 | Required | 健康情報は「要配慮個人情報」として法令上厳格な取扱いが求められる。漏洩時の精神的被害も大きい |
| 3.1.H. 法的に保護された情報 | Required | 弁護士との相談内容や訴訟戦略の漏洩は秘匿特権の喪失に直結。経営相談を行う組織では法的相談を扱う場面がある |
| 項目 | レベル | 判断根拠 |
|---|
| 3.2.A. 機密度分類に応じた利用可否基準 | Required | 一律禁止では業務活用不可、一律許可ではリスク管理不能。分類基準は実効的運用の前提 |
| 3.2.B. 匿名化・仮名化のガイダンス | Required | 3.1で「匿名化後は入力可」とする以上、具体的な匿名化手順がなければルールが実行不能 |
| 3.2.C. 第三者情報の取り扱いルール | Required | 経営相談を行う組織では第三者情報の取扱が業務の核心。NDA違反リスクに直結 |
| 3.2.D. 契約上の守秘義務との整合性 | Required | 既存契約・NDAとの矛盾を放置すると、善意のAI活用が契約違反に該当しうる。経営相談組織では確認が不可欠 |
| 項目 | レベル | 判断根拠 |
|---|
| 3.3.A. 個人データの入力ルール | Required | 個人情報保護法の第三者提供制限に直結。具体的ルールなしでは法令違反リスク |
| 3.3.B. 本人同意の要否・取得方法 | Required | 同意なき個人情報利用は法令違反。プライバシーポリシーとの整合確認は法的義務 |
| 3.3.C. 委託先提供の該当性判断基準 | Required | 委託先監督義務は個人情報保護法上の法定義務。判断基準の欠如は義務履行の前提を欠く |
| 3.3.D. 越境移転への対応 | Required | 大半の生成AIサービスは海外サーバーで処理される。越境移転規定は法的要件であり確認は不可欠 |
| 項目 | レベル | 判断根拠 |
|---|
| 4.1.A. ファクトチェックの義務付け | Required | ハルシネーションは生成AIの構造的特性。検証なしの利用は誤情報の業務流入を招く |
| 4.1.B. 専門家レビューの要否基準 | Required | 専門領域のAI出力を非専門家だけで検証するのは不十分。経営相談組織では法務・財務が不可欠 |
| 4.1.C. そのまま使用禁止の場面明示 | Required | 対外公式文書での無加工AI出力使用はガバナンスの欠如を示す |
| 4.1.D. 人間による最終確認・承認 | Required | ヒューマン・イン・ザ・ループの基本原則。AI出力の品質責任は人間が負う |
| 項目 | レベル | 判断根拠 |
|---|
| 4.2.A. 生成物の著作権帰属 | Required | 権利関係が不明なままの利用は法的リスク。組織としての方針整理が必要 |
| 4.2.B. 既存著作物との類似性チェック | Required | 著作権侵害リスクに直結。依拠性が推認される可能性あり |
| 4.2.C. 商用利用時の追加確認 | Recommended | 重要だが、基本の著作権確認（A・B）で主要リスクはカバーされる |
| 4.2.D. 画像・音声・動画生成時の注意 | Option | テキスト中心の組織では該当場面が少ない。利用する場合に検討すればよい |
| 項目 | レベル | 判断根拠 |
|---|
| 4.3.A. AI生成コンテンツの表示要否基準 | Required | 経営相談組織では透明性が信頼の基盤。加筆・修正後もAI利用の事実の開示基準が必要 |
| 4.3.B. 社外向け資料でのAI利用ルール | Required | 社外向け資料には組織としての品質保証が暗黙に求められる |
| 4.3.C. 顧客・取引先への説明責任 | Required | 経営相談組織では顧客の信頼が事業の根幹。AI利用の透明性は不可欠 |
| 4.3.D. ディープフェイク対応 | Option | 経営相談組織での発生頻度は低く、具体的な対策も限定的 |
| 項目 | レベル | 判断根拠 |
|---|
| 4.4.A. 重要度に応じた承認プロセス | Required | 効率と安全のバランスを取る運用基盤。4.1.Dの具体化 |
| 4.4.B. 出力の記録・保存 | Option | 全出力の記録は小規模組織では負荷が高い。対外提出物等の影響の大きい領域に限定して検討 |
| 4.4.C. 問題のある出力の報告 | Option | SaaS型AIをそのまま利用する小規模組織ではモデル改善につながらない。内部改善の範囲で検討 |
| 項目 | レベル | 判断根拠 |
|---|
| 5.1.A. ハルシネーションへの対処方法 | Required | 生成AIの構造的特性。対処方法なしでは誤情報リスクが管理できない |
| 5.1.B. 生成AIの限界・不得意分野の説明 | Required | AIの限界を知らなければ過信による事故が起きる。利用者教育の基盤 |
| 5.1.C. 出力の信頼度判断ガイダンス | Recommended | 有用だがA・Bで主要リスクはカバーされる。より高度な運用を目指す場合に有効 |
| 5.1.D. 継続的なテスト・検証の仕組み | Option | SaaS型AIを利用する小規模組織では継続的テストは現実的に困難 |
| 項目 | レベル | 判断根拠 |
|---|
| 5.2.A. 安全に関わる業務での利用制限 | Required | 誤りが実害につながる業務での制限はガイドラインの基本要件 |
| 5.2.B. 人間の最終判断を要する場面の特定 | Required | 判断の丸投げ防止と責任の所在明確化。経営相談では不可欠 |
| 5.2.C. 緊急停止・利用中止の基準と手順 | Recommended | SaaS利用では「利用停止」が実質的手段。基準があることは望ましいが必須とまでは言えない |
| 5.2.D. 残存リスクの文書化 | Option | 形式的なリスク文書化は小規模組織には負荷が大きい。主要リスクは他項目でカバーされる |
| 項目 | レベル | 判断根拠 |
|---|
| 5.3.A. 承認ツール・サービスのリスト | Required | シャドーIT防止の基盤。リストなしではセキュリティ管理が崩壊する |
| 5.3.B. 未承認ツールの利用禁止 | Required | 禁止の明示がなければ承認リスト（A）が形骸化する |
| 5.3.C. アカウント管理ルール | Required | セキュリティの基本。共有アカウントは責任追跡を不可能にする |
| 5.3.D. プロンプトインジェクション等の注意喚起 | Recommended | 利用者が知っておくべきだが、SaaS利用では防御の主体はプロバイダ側 |
| 5.3.E. API利用時のセキュリティ要件 | Option | 小規模組織ではAPI利用が少なく、該当する場合のみ検討 |
| 5.3.F. データポイズニングへの対策 | Option | SaaS利用者が制御できる範囲ではない。認識として有用だが対策は限定的 |
| 5.3.G. モデル抽出・メンバーシップ推論攻撃対策 | Option | SaaS利用者に直接的な防御手段がない。高度な脅威モデルとしての位置づけ |
| 項目 | レベル | 判断根拠 |
|---|
| 5.4.A. AI利用の記録・ログ保存 | Option | SaaS型ではログ管理手段が限定的。1.4.A・4.4.Bと同様の理由でOption |
| 5.4.B. 意思決定過程の説明責任 | Required | 経営相談では意思決定根拠の説明は不可欠。「AIが出した結論」では説明にならない |
| 5.4.C. ステークホルダーへの情報開示方針 | Recommended | 望ましいが小規模組織では開示先が限定的。方針の整理は有用 |
| 5.4.D. 学習データの出所の確認 | Option | SaaS利用者では確認手段が限られる。公表情報の把握にとどまる |
| 項目 | レベル | 判断根拠 |
|---|
| 5.5.A. AI出力の根拠説明を要する場面の特定 | Required | 経営相談では「なぜその結論か」の説明が必須。根拠なき助言は信頼を損なう |
| 5.5.B. 説明困難な場合の対応方針 | Recommended | 説明できない出力への対処方針は有用だがAで主要リスクはカバーされる |
| 5.5.C. 役割・知識レベルに応じた説明方法 | Option | 小規模組織では全員がほぼ同レベルの場合が多い |
| 項目 | レベル | 判断根拠 |
|---|
| 5.6.A. プライバシー影響評価の実施要否基準 | Recommended | 形式的PIAは負荷大だが判断基準自体は有用 |
| 5.6.B. データ最小化の原則 | Required | プライバシー保護の基本原則。必要最小限のデータ入力は法的要件の基盤 |
| 5.6.C. 個人の権利への対応方針 | Required | 個人情報保護法上の本人請求権への対応は法的義務 |
| 5.6.D. プライバシー強化技術（PETs）の活用 | Option | 高度な技術で小規模組織には実装が困難 |
| 項目 | レベル | 判断根拠 |
|---|
| 5.7.A. バイアスの種類と影響の説明 | Recommended | 2.2.D（バイアスリスク評価）がRecommendedであり整合を取る |
| 5.7.B. 人事・採用等でのAI利用の注意事項 | Recommended | 小規模組織ではAIを人事判断に使う場面が少ない。利用時の注意喚起として推奨 |
| 5.7.C. バイアス検出・軽減の方策 | Option | リスク評価がRecommendedなら具体策はOptionが妥当。SaaS利用者の対策手段も限定的 |
| 5.7.D. 多様性・公平性のレビュー体制 | Option | 小規模組織では形式的なレビュー体制の構築が困難 |
| 5.7.E. システム的/統計的/認知バイアスの区別 | Option | 詳細な分類は教育目的として有用だが必須ではない |
| 項目 | レベル | 判断根拠 |
|---|
| 6.1.A. インシデントの定義と報告すべき事象 | Required | 何がインシデントかの定義なしには対応が始まらない |
| 項目 | レベル | 判断根拠 |
|---|
| 6.2.A. 初動対応の手順 | Required | 初動の遅れは被害拡大に直結 |
| 6.2.B. 外部報告の基準 | Required | 個人情報漏えい時の個情委報告は法的義務。経営相談組織では顧客への誤情報訂正も不可欠 |
| 項目 | レベル | 判断根拠 |
|---|
| 6.3.A. インシデント記録・事後レビュー | Recommended | 重要だが4.4.B・5.4.AがOptionの整合性から必須とまでは言えない |
| 項目 | レベル | 判断根拠 |
|---|
| 7.1.A. 目次・構成の分かりやすさ | Required | ガイドラインの使いやすさの基盤。構成が不明瞭だと必要な情報にたどり着けず形骸化する |
| 7.1.B. 用語の定義 | Required | 主要用語の解釈がずれるとルール全体が空回りする |
| 7.1.C. 具体例・FAQ | Recommended | 実効性を高めるが、本体が明確であれば最低限は機能する |
| 7.1.D. 関連文書へのリンク | Recommended | 利便性に寄与するが欠落が直ちにリスクにはならない |
| 項目 | レベル | 判断根拠 |
|---|
| 7.2.A. 現場で使える具体性 | Required | 抽象的なガイドラインは読まれても実行されない。具体性は実効性の前提 |
| 7.2.B. 判断に迷う場面での指針 | Required | グレーゾーンの判断基準がないと現場が自己判断しルールが空文化する |
| 7.2.C. 問い合わせ先・相談窓口 | Required | 1.1.B（担当部門）の情報が文書上に明記されていなければアクセスできない |
| 7.2.D. 例外対応のプロセス | Recommended | 重要だが、小規模組織ではエスカレーションルート（1.1.E）で実質的に対応可能 |
| 項目 | レベル | 判断根拠 |
|---|
| 7.3.A. バージョン・改訂履歴 | Required | 版管理なしでは最新版の判断がつかず旧ルールに従い続けるリスクがある |
| 7.3.B. 制定日・施行日 | Required | いつから有効かが不明な規程は効力に疑義が生じる。文書管理の基本 |
| 7.3.C. 次回見直し予定 | Recommended | 1.2.E（定期見直し）がRecommendedであり整合を取る。見直しの意志表示として有効 |
| 7.3.D. 承認者・責任者 | Required | 誰が承認した文書かが不明では権威と拘束力が担保されない |