本チェックリストについて

これは何？

本文書は、組織が「生成AI利用ガイドライン」を策定・改訂する際に、 必要な項目が網羅されているかを確認するためのチェックリストです。 生成AIの利用ルールそのものではありません。

項目の選定にあたっては、米国国立標準技術研究所（NIST）が策定した AIリスク管理の国際的な基本枠組みであるAI RMF 1.0と、 その生成AI固有のリスクを扱う拡張文書AI 600-1を軸としています。 あわせて経済産業省・IPA・JDLA等の国内ガイドラインおよび EU AI Actを横断的に参照し、 必要とされる項目を体系的に整理しています。

想定読者

専門のIT部門を持たない中小規模の組織が、 生成AIの利用ガイドラインを自ら策定・点検する場面を 主に想定しています。

AIやリスク管理の専門知識がなくても 項目を順に確認できるよう、 各項目に説明と定義例を付しています。

このチェックリストを使う利点

生成AIの利用ガイドラインを策定する際、 何を書くべきかの全体像が見えないまま着手すると、 重要な項目の抜け漏れに気づけません。

本チェックリストを使うことで、 国際的な基準に照らして自組織のガイドラインの 過不足を客観的に把握できます。 準拠レベル（Required / Recommended / Option）により、 限られたリソースの中で何を優先すべきかも判断できます。

また、策定したガイドラインの網羅性や妥当性について 社内外から説明を求められた際にも、 NIST AI RMF等の国際基準に基づくチェックリストで 検証済みであることが客観的な根拠となります。

対象範囲と前提

本チェックリストは、ChatGPT・Claude・Gemini等の チャットベースのSaaS型生成AIサービスを 業務で利用する場面を対象としています（2026年1月時点）。 サービスの機能や利用条件は変更される可能性があるため、 最新の情報を確認してください。

自社でAIモデルを開発・訓練する場面や、 ソフトウェア開発におけるコード生成の用途は対象外です。

Excel版チェックリスト

本チェックリストのセルフチェック用Excelファイルを 用意しています。 ドロップダウンで対応状況（対応済・一部対応・未対応・該当なし） を記入でき、 サマリーシートで対応率が自動集計されます。

GitHubリポジトリの excel/genai-governance-checklist.xlsx からダウンロードできます。

チェックリストの構成

NIST AI RMFは、AIリスク管理に必要な活動を GOVERN（統治）・MAP（リスク特定）・MEASURE（測定）・ MANAGE（管理）の4機能で体系化した枠組みです。 本チェックリストはこの4機能に沿って構成することで、 ガイドラインに必要な領域の網羅性を確保しています。

チェック項目の読み方

各チェック項目は以下の形式で記述しています。

X.X.Y. [準拠レベル] チェック項目テキスト [参照タグ]
  説明: ...
  定義例: 「...」

準拠レベル

参照タグ

各項目の末尾に参照元ガイドラインを以下の略称で示しています。

免責事項

本文書は情報提供を目的としたものであり、 法的助言を構成するものではありません。

内容の正確性・完全性・最新性について保証するものではなく、 本文書の利用により生じたいかなる損害についても 作成者は責任を負いません。

本文書に記載された製品名・サービス名は 各社の商標または登録商標であり、 特定の製品・サービスを推奨するものではありません。

法令遵守や具体的な対応については、 必ず専門家にご相談ください。

本文書の作成には Claude Code （Anthropic社の開発支援ツール）を使用しています。 最終的な内容の確認・判断は人間が行っています。

1. ガバナンス体制 (GOVERN)

1.1 組織体制・責任

• 1.1.A. [Required] 生成AI利用に関する最終責任者（経営層）が明確に定められている [NIST: GOVERN 2.3] [METI]
  • 説明: AI関連の最終判断を下す責任者は必須。 責任者が不明確だと、インシデント発生時に判断が遅れ法的・社会的リスクを組織全体に 波及させる。名目上の責任者は意味がない。実務を担当者へ任せきりにし、 責任者自身がリスクや運用実態を把握していない体制は「責任者不在」と同義である。
  • 定義例: 「団体理事長をAI利用の最終責任者とし、利用方針の承認・リスク受容の判断・重大インシデント時の意思決定を自ら行う。定期的に運用状況の報告を受け、方針の妥当性を確認する」
• 1.1.B. [Required] AI利用に関する担当部門・担当者が指定されている [NIST: GOVERN 2.1] [JDLA]
  • 説明: 最終責任者の下で、日常のAI利用を実務面で管理する部門・担当者を明確にする。指定がないと、利用上の疑問やトラブルの相談先が不在となり、現場が自己判断で使い続ける“野良AI“状態を招く。
  • 定義例: 「総務部をAI利用の管理部門とし、担当者○○がツール選定・利用ルールの周知・問い合わせ対応・インシデント一次対応を担う」
• 1.1.C. [Recommended] 部門横断的な推進体制（法務、情報システム、事業部門等）が構築されている [NIST: GOVERN 3.1] [IPA]
  • 説明: AI利用は情報セキュリティ・法務・業務の各領域にまたがるため、単一部門だけでは死角が生まれる。「IT部門が技術面だけ見て法的リスクを見落とす」「事業部門が便利さだけ追求しセキュリティを無視する」といった事態が典型的な失敗パターンである。小規模組織であっても、外部の専門家（顧問弁護士等）を含めた連携体制を意識的に構築すべきである。
  • 定義例: 「AI利用に関する方針検討・リスク判断は、総務部（管理）・業務担当部門・外部顧問（法務・IT）が合同で行い、各視点からの確認を経て決定する」
• 1.1.D. [Required] 役割と責任の範囲が文書化されている [NIST: GOVERN 2.1] [METI]
  • 説明: 「誰が何をやるか」を文書化しておかないと、問題が起きたときに「それは私の担当ではない」と責任の押しつけ合いが始まる。口頭の合意だけでは人事異動や担当変更で引き継がれず、属人的な運用に逆戻りする。
  • 定義例: 「AI利用に関する役割分担表を作成し、最終責任者・管理担当者・各部 門の利用者それぞれの権限と義務を明記する。担当者変更時は必ず更新し、全関係者に 共有する」
• 1.1.E. [Required] インシデント発生時のエスカレーションルートが定められている [NIST: GOVERN 1.5] [IPA]
  • 説明 情報漏えいや誤出力の発生時に「誰に・どの順番で・何を報告するか」が決まっていなければ、初動の遅れにより被害が拡大する。現場で問題に気づいた人が報告先を探しているうちに、対応のゴールデンタイムを逃すのは典型的な失敗である。
  • 定義例: 「AIに関する問題を発見した場合、①まずAI管理担当者に口頭またはチャットで即時報告、②管理担当者が30分以内に最終責任者へ報告、③最終責任者が対応方針を判断し指示する。連絡先リストを全従業員に配布する」
• 1.1.F. [Option] 多様な視点を持つチーム構成が考慮されている [NIST: GOVERN 3.1]
  • 説明: AIのリスクは技術的な問題だけでなく、倫理・文化・利用者の多様性に関わる問題も含む。同質的なメンバーだけで意思決定すると、特定の立場からは明白なリスクが見過ごされやすい。性別・年齢・職種・専門分野など、多様な視点を意識的にチーム構成に取り入れることが重要である。
  • 定義例: 「AI利用ルールの策定・見直しにあたっては、管理部門だけでなく、異なる業務経験・年齢層・職種の職員を含むレビュー体制とし、偏った視点にならないよう配慮する」

1.2 ポリシー・規程

• 1.2.A. [Required] 生成AI利用の目的・方針が明記されている [NIST: GOVERN 1.2] [JDLA] [AIACT-JP]
  • 説明: 「なぜ生成AIを使うのか」「どういう方針で使うのか」が明文化されていないガイドラインは、単なるルール集にすぎず現場の納得感を得られない。目的なき規制は形骸化し、目的なき自由は暴走を招く。
  • 定義例: 「本ガイドラインは、業務効率の向上と創造性の支援を目的として生成AIを活用する際の基本方針を定める。AIはあくまで人間の判断を補助するツールとして位置づけ、最終的な意思決定は人間が行う」
• 1.2.B. [Required] ガイドラインの適用範囲（対象者、対象業務、対象ツール）が明確である [JDLA] [IPA]
  • 説明: 「誰が」「どの業務で」「どのツールについて」このガイドラインに従うのかが不明確だと、「自分は対象外」と解釈する余地が生まれ、ルールが空文化する。正規職員だけが対象なのか、委託先や実習生も含むのか——範囲の曖昧さはリスクの温床になる。
  • 定義例: 「本ガイドラインは、当団体のすべての役職員（常勤・非常勤・委託スタッフを含む）が、業務上利用するすべての生成AIサービス（ChatGPT、Copilot等、団体が承認したツール）に適用する」
• 1.2.C. [Required] 既存の情報セキュリティポリシー、個人情報保護方針との整合性が取れている [NIST: GOVERN 1.4] [METI]
  • 説明: 生成AIガイドラインが既存の情報セキュリティポリシーや個人情報保護方針と矛盾していると、現場は「どちらに従えばいいのか」と混乱する。既存ポリシーで「外部クラウドへの機密情報送信禁止」と定めているのに、AIガイドラインでその点に触れていなければ、現場が独自解釈で運用してしまう。
  • 定義例: 「本ガイドラインは既存の情報セキュリティポリシー及び個人情報保護方針との整合性を確認済みである。AI固有の事項については本ガイドラインが優先し、記載のない事項は既存ポリシーに従う」
• 1.2.D. [Required] 関連する法令・規制要件（個人情報保護法、著作権法等）への言及がある [NIST: GOVERN 1.1] [JDLA] [AIACT-JP]
  • 説明: 生成AI利用には個人情報保護法、著作権法、不正競争防止法など複数の法令が関わる。ガイドラインで法令に触れていないと、「法的リスクは考慮済み」と現場が誤解し、知らないうちに法令違反を犯すおそれがある。すべてを網羅する必要はないが、最低限の関連法令を明示し、判断に迷う場合の相談先を示すことが重要である。
  • 定義例: 「生成AIの利用にあたっては、 個人情報保護法・著作権法・不正競争防止法・ 人工知能関連技術の研究開発及び活用の推進に関する法律 （AI推進法）を遵守する。 業種固有の法規制（金融、医療、教育等）がある場合はそれも対象に含める。 法的判断に迷う場合は、AI管理担当者を通じて顧問弁護士に相談する」
• 1.2.E. [Recommended] ガイドラインの定期的な見直し・更新の仕組みが定められている [NIST: GOVERN 1.5] [METI] [AIACT-JP]
  • 説明: 生成AI技術と関連法規制は急速に変化するため、策定時点のガイドラインは半年もすれば陳腐化しうる。「一度つくって終わり」のガイドラインは変化に対応できず形骸化する。更新のタイミング・手順・責任者を予め決めておくことが、ガイドラインを“生きた文書“にする条件である。
  • 定義例: 「本ガイドラインは少なくとも年1回（毎年○月）に見直しを行う。AIに関する重大な法改正やインシデント発生時には臨時の見直しを実施する。見直しはAI管理担当者が起案し、最終責任者が承認する」
• 1.2.F. [Recommended] リスク許容度が組織として定義されている [NIST: MAP 1.5] [METI]
  • 説明: 「どの程度のリスクなら許容するか」を組織として決めていないと、担当者ごとに判断基準がバラつき、同じ案件でも人によって可否が分かれる。リスク許容度が明確であれば現場判断に一貫性が生まれ、個人の裁量に過度に依存する状態を防げる。
  • 定義例: 「公開情報の要約・翻訳支援など、情報漏えいリスクが低く出力誤りの影響も限定的な業務はAI利用を許可する。個人情報・機密情報を扱う業務、対外的な意思決定に関わる業務ではAI利用を制限または禁止する。判断が困難な場合はAI管理担当者の承認を得る」

1.3 教育・研修

• 1.3.A. [Required] 従業員向けの生成AI利用研修が計画されている [NIST: GOVERN 2.2] [JDLA] [EU-AIA] [AIACT-JP]
  • 説明: ガイドラインを策定しただけでは機能しない。 読まれない規程は存在しないのと同じである。 研修を通じてAIリテラシー（AIの能力・限界・リスクを 理解し適切に利用する能力）を身につけさせる必要がある。 EU AI Act第4条はAIシステムに関わるすべての人員に AIリテラシーの確保を義務付けており、 国際的にも重要性が高まっている概念である。 「なぜこのルールがあるのか」を理解させなければ、 現場はルールを面倒な制約としか捉えず、 形だけの遵守か無視が常態化する。
  • 定義例: 「生成AI利用開始前に全職員を対象とした 初回研修（90分）を実施する。 内容はガイドラインの要点、禁止事項、 入力してはいけない情報の具体例、 インシデント報告手順とする。 受講記録を管理し、未受講者にはAI利用権限を付与しない」
• 1.3.B. [Recommended] ITリテラシーレベルに応じた教育内容が用意されている [JDLA] [IPA] [AIACT-JP]
  • 説明: 全員に同じ研修を実施しても、ITに詳しい人には退屈で、不慣れな人には理解が追いつかない。結果として両者とも研修の効果を実感できず、「やった感」だけが残る。対象者のレベルに合わせた教育設計が、実効性ある研修の前提条件である。
  • 定義例: 「研修は2段階で実施する。基礎編（全職員対象）ではAIの概要・リスク・禁止事項を扱い、実践編（日常的にAIを使う職員対象）ではプロンプト設計・出力検証の方法・業務活用事例を扱う」
• 1.3.C. [Required] 新規利用者向けのオンボーディングプロセスがある [NIST: GOVERN 2.2] [AIACT-JP]
  • 説明: 新しく入った職員が、既存メンバーと同じ前提知識を持っているとは限らない。入職後に「AI使っていいですよ」とだけ言われ、ガイドラインの存在すら知らないまま使い始めるケースは十分ありうる。新規利用者が必ず通る導入プロセスを設けることで、知識のばらつきを防ぐ。
  • 定義例: 「新規入職者には、入職時オリエンテーションの一環としてAI利用ガイドラインの説明と基礎研修の受講を義務づける。研修完了後にAIツールのアカウントを発行する」
• 1.3.D. [Recommended] 継続的な啓発活動（事例共有、注意喚起等）の仕組みがある [NIST: GOVERN 4.3] [JDLA] [AIACT-JP]
  • 説明: 一度研修を受けても、日常業務に追われるうちルールの記憶は薄れる。他社のAI関連トラブル事例や、自組織での良い活用例を定期的に共有することで、ガイドラインの存在意義を繰り返し意識させる。啓発が途絶えると、ガイドラインは「入社時に読んだきりの文書」に退化する。
  • 定義例: 「四半期に1回、AI利用に関するミニ勉強会（30分）を実施し、最新のリスク事例・活用好事例・ガイドライン改訂内容を共有する。また、重大な外部事例が発生した場合は、速やかに全職員にメール等で注意喚起する」

1.4 監視・監査

• 1.4.A. [Option] 利用状況のモニタリング方法が定められている [NIST: GOVERN 1.5] [IPA]
  • 説明: 本来、ガイドラインの遵守状況を確認するには、 誰がどのツールで何を入力・生成したかを把握できるモニタリングが望ましい。 しかし、現状の主要SaaS型AIサービス（Claude Team/Enterprise、 ChatGPT Team/Enterprise等）は、管理者向けに利用量や利用者の統計は 提供するものの会話内容レベルのログ閲覧機能は提供していない。 そのため、内容面のガイドライン遵守は利用者の自己申告と啓発に頼らざるを得ない のが現状である。現時点でのベストプラクティスは、 ツールが提供する管理機能の範囲で利用状況を定期的に確認し、 異常な利用パターンの早期発見につなげることである。
  • 定義例: 「AI管理担当者は月1回、各AIツールの管理ダッシュボードで 利用者数・利用頻度を確認する。 急激な利用量の変化があった場合は利用者にヒアリングを行う。 内容面の遵守確認はセルフチェックシートにより四半期に1回実施する」
• 1.4.B. [Option] 定期的な監査・レビューの実施計画がある [NIST: GOVERN 1.5] [METI]
  • 説明: モニタリングが日常の健康管理だとすれば、監査は定期健診にあたる。日々の点検では見落とす構造的な問題——ルール自体の陳腐化や、組織全体の運用傾向——を発見するには、定期的に一歩引いた視点でレビューする場が必要である。
  • 定義例: 「年1回（○月）にAI利用に関する内部監査を実施する。ガイドライン遵守状況、リスク対応状況、利用効果を評価し、結果を最終責任者に報告する」
• 1.4.C. [Required] 違反時の対応プロセスが明記されている [JDLA] [IPA]
  • 説明: 違反が発覚したとき、対応が場当たり的だと「あの人は注意されたのに、この人はお咎めなし」と不公平感が生まれ、ルールの信頼性が崩壊する。軽微な違反と重大な違反を区別し、段階的な対応を予め定めておくことが公正な運用の基盤になる。
  • 定義例: 「違反を確認した場合、①軽微な違反（過失による禁止情報の入力等）は口頭注意と再研修、②重大な違反（意図的な機密情報の入力、悪用目的の利用等）はAI利用権限の停止と懲戒規定に基づき対応する。すべての違反対応を記録する」
• 1.4.D. [Recommended] AIシステムのインベントリ管理の仕組みがある [NIST: GOVERN 1.6]
  • 説明: 組織内で「誰が・何のAIツールを・どの業務で使っているか」を一覧で把握できていないと、未承認ツールの利用や、サービス終了への対応が後手に回る。管理対象を可視化することがガバナンスの出発点である。
  • 定義例: 「利用中のAIツール・サービスの一覧表を作成し、ツール名・提供元・利用部門・利用目的・契約状況・データ取扱条件を記載する。新規導入・廃止時に随時更新する」
• 1.4.E. [Recommended] AIサービスの提供終了・重大変更時の対応方針がある [NIST: GOVERN 1.7]
  • 説明: 利用中のAIサービスが提供者側の都合で突然終了・大幅変更される リスクは常にある。代替手段の検討やデータの退避を事前に想定しておかないと、 業務が突然停止し、蓄積したプロンプトテンプレートやワークフローが 一夜にして失われる。特定のサービスへの過度な依存を避け、 移行先の候補を平時から把握しておくことが重要である。
  • 定義例: 「利用中のAIサービスにおいてサービス終了または重大な仕様変更があった場合に 備え、①代替候補サービスのリストを維持する、 ②業務上重要なプロンプトテンプレート・ナレッジは サービス外にも保存する、③サービス提供者からの告知を 定期的に確認する体制をとる」

2. リスクの特定と評価 (MAP)

2.1 利用目的・文脈の明確化

• 2.1.A. [Required] 生成AIを利用する業務・ユースケースが特定されている [NIST: MAP 1.1] [JDLA] [AIACT-JP]
  • 説明: 「何にでも使っていい」は「何に使うか考えていない」と同義である。利 用する業務を特定しないまま導入すると、効果測定もリスク評価できず、問題が起き たとき「想定外の使い方だった」と言い訳するしかなくなる。
  • 定義例: 「生成AIの利用を認める業務として、①文書の草稿作成、②調査・情報収 集の補助、③翻訳・要約の支援、④アイデア出し・ブレインストーミングを指定する。そ れ以外の業務での利用はAI管理担当者の事前承認を要する」
• 2.1.B. [Required] 各ユースケースにおける期待される効果（便益）が文書化されている [NIST: MAP 3.1] [METI]
  • 説明: 「便利だから」だけでは導入の根拠にならない。期待する効果を具体的に 書き出しておくことで、導入後に「実際に役立っているか」を評価でき、効果が薄い用 途の見直しや、有効な用途の拡大につなげられる。
  • 定義例: 「各ユースケースについて、期待する効果（例：議事録作成の所要時間 を半減、定型文書の初稿作成を自動化）を記録し、半年後に実績と比較して効果を検証 する」
• 2.1.C. [Required] 想定ユーザーとその利用方法が定義されている [NIST: MAP 1.1] [METI]
  • 説明: 同じAIツールでも、使う人の知識レベルや業務内容によってリスクの大き さが変わる。経理担当者が財務データを入力するリスクと、広報担当者がプレスリリー スの草案を作るリスクは本質的に異なる。想定ユーザーを明確にすることで、リスクに 応じた対策が可能になる。
  • 定義例: 「主な利用者は事務職員（文書作成補助）および広報担当（コンテンツ 草案作成）とする。各利用者は、自身の業務範囲内でのみAIを利用し、他部門のデータ を扱う場合は当該部門の承認を得る」
• 2.1.D. [Required] AIを使用すべきでない業務・場面が明記されている [NIST: MAP 1.1] [JDLA]
  • 説明: 「使ってよい場面」を列挙するだけでは、グレーゾーンの判断に迷う。 「使ってはいけない場面」を明示することで、禁止ラインが明確になり、現場が安心し て判断できるようになる。ネガティブリストの欠如は、重大なリスクを見落とす原因に なる。
  • 定義例: 「以下の業務・場面ではAI利用を禁止する：①個人の評価・処遇に関す る判断、②法的効力を持つ文書の最終作成、③本人確認・認証に関わる業務、④外部への 正式な回答・声明の作成」
• 2.1.E. [Required] ビジネス価値・目的が明確に定義されている [NIST: MAP 1.4] [AIACT-JP]
  • 説明: AI導入が「流行に乗る」ための施策になっていないかを確認する視点であ る。組織にとっての具体的な価値——コスト削減、品質向上、業務時間の創出——が言語化 されていなければ、投資対効果の判断も撤退判断できない。
  • 定義例: 「生成AI導入のビジネス価値を、①定型業務の作業時間削減による本来 業務への集中、②文書品質の底上げによる手戻り削減と定義し、導入後に定量的に評価 する」
• 2.1.F. [Required] 組織のミッション・目標との整合性が確認されている [NIST: MAP 1.3] [AIACT-JP]
  • 説明: AI利用が組織の理念や目標と矛盾していないかを確認する。たとえば「人 に寄り添うサービス」を掲げる組織が、顧客対応を全面的にAIに置き換えるのは本末転 倒である。ツールの導入が組織の方向性を歪めないよう、上位の目標と照合する習慣が 必要である。
  • 定義例: 「生成AIの利用方針が当団体の事業計画・行動指針と整合していることを、年次の方針見直し時に確認する」

2.2 リスクの分類と評価

• 2.2.A. [Required] 情報漏えいリスクの評価がされている [JDLA] [IPA] [FUJITSU]
  • 説明: 生成AIに入力した情報は、サービス提供元のサーバーに送信される。「学 習に利用しない」設定だけでは不十分で、秘密保持義務のないサービスに機密情報を入 力すれば、実質的に情報が外部に渡ったのと同じである。どの情報がどの経路で漏えい しうるかを具体的に洗い出すことが出発点となる。
  • 定義例: 「生成AI利用における情報漏えいリスクを、情報種別（機密・社内限・ 公開）×漏えい経路（入力データの学習利用・履歴閲覧・サーバー保存）のマトリクス で評価し、対策を定める」
• 2.2.B. [Required] 著作権・知的財産権侵害リスクの評価がされている [JDLA] [FUJITSU] [METI]
  • 説明: 生成AIの出力は既存の著作物と類似する可能性がある。利用者が元の著作 物を知らなくても、AIが学習データに基づいて類似物を生成した場合、著作権侵害の 「依拠性あり」と推認されうる（文化庁見解）。「AIが出したから大丈夫」は通用しな い。
  • 定義例: 「生成AI出力物の著作権侵害リスクを評価する。特に画像・デザイン・ 文章の生成では、既存著作物との類似性を確認するプロセスを設け、疑わしい場合は利 用を控える」
• 2.2.C. [Required] ハルシネーション（誤情報生成）リスクの評価がされている [NIST-GAI] [JDLA] [FUJITSU]
  • 説明: 生成AIは「もっともらしい嘘」を自信満々に出力する。正誤判断を行わず 確率予測で文章を生成する仕組み上、不具合ではなく構造的な特性である。どの 業務で誤情報のリスクが高いか、誤情報が流通した場合の影響はどの程度かを予め評価 しておくことが重要である。
  • 定義例: 「ハルシネーションリスクを業務別に評価する。事実確認が容易な業務 （要約・翻訳）は低リスク、専門知識が必要な業務（法務・技術調査）は高リスクと分 類し、高リスク業務では必ず専門家によるファクトチェックを行う」
• 2.2.D. [Recommended] バイアス・公平性に関するリスクの評価がされている [NIST: MAP 5.1] [METI] [FUJITSU]
  • 説明: 学習データの偏りにより、AIは特定の属性（性別・人種・年齢等）に対し て不公平な出力をすることがある。「CEOの画像」を生成すると白人男性ばかり、「看 護師」を生成すると女性ばかりになるのは代表的な例である。人事・評価・顧客対応に AIを使う場合、バイアスは直接的な差別につながりうる。
  • 定義例: 「AI出力が特定の属性に不利益をもたらすバイアスを含んでいないか、 利用前に確認する。人に関する判断補助にAIを用いる場合は、バイアスリスクを『高』 と評価し、複数の視点からのレビューを義務づける」
• 2.2.E. [Required] プライバシーリスクの評価がされている [NIST: MAP 5.1] [METI]
  • 説明: 生成AIは、入力されたデータだけでなく、学習データに含まれる個人情報 を出力に反映することもある。意図せず他者のプライバシーを侵害する可能性があり、 入力側・出力側の両面でリスクを評価する必要がある。
  • 定義例: 「プライバシーリスクを入力面（個人情報を含むデータの入力有無）と 出力面（個人を特定しうる情報の生成有無）の2軸で評価し、リスクが高い業務では匿 名化または利用制限を適用する」
• 2.2.F. [Required] セキュリティリスク（プロンプトインジェクション等）の評価がされている [NIST-GAI] [IPA]
  • 説明: 生成AIには、悪意あるプロンプトでガードレールを回避させる「プロンプ トインジェクション」や、学習データを汚染する「データポイズニング」など、従来の ITとは異なるセキュリティ脅威がある。これらの攻撃手法を理解し、自組織の利用形態 で影響を受けうるかを評価しておく必要がある。
  • 定義例: 「生成AIに特有のセキュリティリスク（プロンプトインジェクション、 情報抽出攻撃等）を洗い出し、自組織の利用形態（社内利用のみ／顧客向けチャットボ ット等）に応じた影響度を評価する」
• 2.2.G. [Required] 法的リスク（契約違反、規制違反等）の評価がされている [NIST: GOVERN 1.1] [METI]
  • 説明: AI利用が契約上の守秘義務違反、著作権法違反、個人情報保護法違反、あ るいは業界固有の規制違反に該当する可能性がないかを事前に評価する。「法令違反の 認識がなかった」は免責事由にならない。
  • 定義例: 「AI利用に関連する法的リスクを、個人情報保護法・著作権法・不正競 争防止法・各業界規制の観点で評価し、リスクが高い領域を特定して対策を講じる」
• 2.2.H. [Recommended] レピュテーションリスクの評価がされている [NIST: MAP 5.1] [FUJITSU]
  • 説明: AIが不正確な情報や不適切なコンテンツを生成し、それが組織名で外部に 出た場合、信用の失墜は法的リスク以上に深刻な打撃を与えうる。検証せずにAIの回答 をそのまま社会に出すことは、顧客や社会からの「信頼」を損なう行為である。
  • 定義例: 「AI出力を外部に公開する業務（広報・顧客対応・公式文書等）につい て、誤情報・不適切表現によるレピュテーションリスクを評価し、必ず人間に よる公開前レビューを実施する」
• 2.2.I. [Recommended] 業務依存リスク（過度な依存、スキル低下）の評価がされている [NIST-GAI] [FUJITSU]
  • 説明: AIに頼りすぎると、人間自身の判断力や業務スキルが徐々に低下する。AI サービスが停止した場合に業務が止まる「依存リスク」と、長期的にスキルが衰退する 「能力喪失リスク」の両面から評価が必要である。
  • 定義例: 「AI利用が長期化した場合の業務依存度を評価する。AIなしでも最低限 の業務遂行が可能な体制を維持し、定期的にAIを使わない業務訓練や手動プロセスの確 認を行う」
• 2.2.J. [Option] 環境負荷・サステナビリティの考慮がされている [NIST: MEASURE 2.12] [METI]
  • 説明: 大規模言語モデルの学習・推論には膨大なエネルギーと水資源が消費され る。組織の環境方針やSDGs目標との整合性を確認し、必要以上に大きなモデルを不必要 に利用していないかを検討する視点も重要である。
  • 定義例: 「AI利用の環境負荷を認識し、業務に必要十分なモデル・サービスを選 択する。組織の環境方針がある場合は、AI利用方針との整合性を確認する」

2.3 サードパーティリスク

• 2.3.A. [Required] 利用するAIサービス・ツールの選定基準が定められている [NIST: GOVERN 6.1] [IPA]
  • 説明: 「無料だから」「話題だから」で選んだツールが、実は入力データを学習 に利用していたり、セキュリティ対策が不十分だったりするケースは多い。選定基準が なければ、部門ごとにバラバラなツールが乱立し、管理コストとリスクが膨らむ。
  • 定義例: 「AIツールの選定にあたっては、①データの取扱方針（学習利用の有 無）、②セキュリティ対策（通信暗号化・データ保存場所）、③利用規約の内容、④提供 元の信頼性を確認し、AI管理担当者が承認した上で利用を開始する」
• 2.3.B. [Required] ベンダーの利用規約・プライバシーポリシーの確認プロセスがある [NIST: MAP 4.1] [JDLA]
  • 説明: 利用規約を読まずに「同意する」をクリックするのは個人の自由だが、組 織の業務データを扱うサービスでは許されない。規約の中に「入力データを学習に利用 する」「生成物の権利はサービス提供者に帰属する」といった条項が含まれている可能 性がある。
  • 定義例: 「AIツール導入前に、AI管理担当者が利用規約・プライバシーポリシー を確認し、データの学習利用有無、生成物の権利帰属、サービス提供者のデータアクセ ス範囲を把握する。重大な懸念がある場合は顧問弁護士に相談する」
• 2.3.C. [Required] データの取り扱い（学習利用の有無等）の確認がされている [JDLA] [IPA]
  • 説明: 入力データが学習に使われる場合、自社の情報が他のユーザーへの応答に 反映される可能性がある。「学習に利用しない」オプションがあっても、デフォルト設 定で有効になっているとは限らない。設定画面まで確認してはじめて「確認済み」と言 える。
  • 定義例: 「利用する各AIサービスについて、入力データの学習利用有無、データ 保存期間、サーバー所在地を確認・記録する。学習利用のオプトアウト設定がある場合 は確実にオフに設定し、その設定状況を記録する」
• 2.3.D. [Recommended] サービス停止・変更時の対応策が検討されている [NIST: GOVERN 6.2]
  • 説明: 特定のAIサービスに業務を依存した状態でサービスが突然停止・仕様変更 されると、業務が止まる。クラウドサービスには永続の保証がない。代替手段や移行計 画を事前に考えておくことが、事業継続の観点から不可欠である。
  • 定義例: 「主要AIツールの停止・大幅変更に備え、①代替ツールの候補を予め把 握し、②重要業務についてはAIなしでも遂行できる手順を維持する。サービス停止時は AI管理担当者が48時間以内に代替策を提示する」
• 2.3.E. [Option] サプライチェーン全体でのリスク管理が考慮されている [NIST: MAP 4.2] [EU-AIA]
  • 説明: 自組織が利用するAIサービスの裏側には、基盤モデル提供者・クラウドイ ンフラ事業者・データ提供者が連なっている。自組織の直接の契約先だけでなく、その 先の構造的リスク——基盤モデルの脆弱性、学習データの品質問題——も影響しうることを 認識する必要がある。
  • 定義例: 「利用するAIサービスについて、基盤モデルの提供元・データ処理の所 在地・再委託先の有無を可能な範囲で把握し、サプライチェーン上のリスクをAI管理台 帳に記録する」

3. 入力データの管理

3.1 入力禁止情報

• 3.1.A. [Required] 入力してはいけない情報の種類が明確にリスト化されている [JDLA] [FUJITSU]
  • 説明: 「気をつけて使ってください」では何に気をつけるべきか分からない。入 力禁止情報を具体的にリスト化することで、現場が迷わず判断できる。抽象的な注意喚 起だけのガイドラインは、最も重要な場面で役に立たない。
  • 定義例: 「以下の情報は生成AIへの入力を禁止する。判断に迷う場合はAI管理担 当者に確認すること」（以下のサブカテゴリを列挙）
• 3.1.B. [Required] 個人情報（氏名、住所、電話番号、メールアドレス等）[JDLA] [FUJITSU] [AIACT-JP]
  • 説明: 個人を特定できる情報の入力は、個人情報保護法違反のリスクに直結す る。「名前だけなら大丈夫」と思いがちだが、複数の情報を組み合わせれば個人が特 定される。
  • 定義例: 「氏名・住所・電話番号・メールアドレス・生年月日・マイナンバー 等、個人を特定しうる情報は入力しない。匿名化（仮名への置き換え等）した上であ れば利用可とする」
• 3.1.C. [Required] 機密情報（営業秘密、未公開情報、戦略情報等）[JDLA] [FUJITSU]
  • 説明: 営業秘密や未公開の戦略情報がAIサービス経由で漏えいした場合、不正 競争防止法上の保護を失う可能性がある。一度失われた秘密性は取り戻せない。
  • 定義例: 「営業秘密、未公開の事業戦略・製品情報、非公開の研究データ等は入力しない」
• 3.1.D. [Required] 顧客情報（取引先情報、契約内容等）[JDLA] [FUJITSU]
  • 説明: 顧客から預かった情報は、自組織の情報以上に慎重に扱う必要がある。 顧客との契約で守秘義務が課されている場合、AI入力が契約違反に該当しうる。
  • 定義例: 「取引先名・契約条件・見積金額・顧客固有の業務情報等は入力しな い。顧客情報を参照する必要がある場合は、固有名を伏せた上で利用する」
• 3.1.E. [Required] 認証情報（パスワード、APIキー、アクセストークン等）[IPA]
  • 説明: 認証情報がAIの履歴やログに残れば、それ自体が重大なセキュリティ脆 弱性となる。「エラーが出たのでログをAIに貼って解析」する際にAPIキーを含めて しまう事故は実際に起きている。
  • 定義例: 「パスワード・APIキー・アクセストークン・秘密鍵等の認証情報は 絶対に入力しない。ソースコードを入力する際も、認証情報が含まれていないことを 事前に確認する」
• 3.1.F. [Required] 財務情報（未公開の決算情報、インサイダー情報等）[JDLA]
  • 説明: 未公開の財務情報の外部漏えいは、インサイダー取引規制や金融商品取 引法上の問題に発展しうる。特に上場企業やその関連組織では致命的なリスクとなる 。
  • 定義例: 「未公開の決算情報・予算情報・投資計画・M&A情報等は入力しない」
• 3.1.G. [Required] 人事情報（評価、給与、健康情報等）[JDLA]
  • 説明: 人事評価・給与・健康情報は、 漏えいした場合に当事者への精神的被害が特に大きい。 とりわけ健康情報・病歴・信条・犯罪歴・社会的身分等は 個人情報保護法上の「要配慮個人情報」に該当し、 通常の個人情報より厳格な取扱いが求められる （本人の同意なく取得すること自体が原則禁止）。 これらの情報がAI経由で漏えいした場合の影響は深刻であり、 入力禁止を明確にする必要がある。
  • 定義例: 「人事評価・給与・賞与・健康診断結果・ 休職情報等は入力しない。 特に要配慮個人情報（病歴・信条・犯罪歴・ 社会的身分・障害の有無等）は絶対に入力しない」
• 3.1.H. [Required] 法的に保護された情報（弁護士秘匿特権対象情報等）[JDLA]
  • 説明: 弁護士との相談内容や訴訟戦略など法的秘匿特権の対象となる情報は、 AIに入力することで秘匿特権を喪失するリスクがある。法的紛争において重大な不利 益を招く。
  • 定義例: 「弁護士との相談内容、訴訟関連文書、法的秘匿特権の対象となる情報は入力しない」

3.2 データ分類と取り扱い

• 3.2.A. [Required] 情報の機密度分類に応じた利用可否基準がある [IPA] [JDLA]
  • 説明: すべての情報を一律に「入力禁止」にすると業務でAIを活用できず、一律 に「入力可」にするとリスクが管理できない。情報を機密度でランク分けし、ランクご とに「可・条件付き可・不可」を定めることで、現場が実用的に判断できる基準をつく れる。
  • 定義例: 「情報を3段階（公開情報・社内限定・機密）に分類する。公開情報は AI入力可、社内限定情報は匿名化処理後に入力可、機密情報はAI入力不可とする」
• 3.2.B. [Required] 匿名化・仮名化のガイダンスが提供されている [METI] [JDLA]
  • 説明: 「匿名化すればAIに入力してよい」と言われても、何をどう匿名化すれば いいか分からなければ実行できない。「名前をイニシャルにする」だけでは不十分な場 合もある。具体的な手順と判断基準を示すことが、ルールの実効性を左右する。
  • 定義例: 「AI入力前の匿名化手順として、①個人名→仮名（A氏・B氏等）に置換、 ②組織名→一般名称（X社等）に置換、③住所・電話番号・メールアドレスを削除、④複数 情報の組合せで個人が特定されないことを確認する」
• 3.2.C. [Required] 第三者から受領した情報の取り扱いルールがある [JDLA]
  • 説明: 取引先や顧客から預かった情報には、NDA（秘密保持契約）で守秘義務が 課されていることが多い。AIに入力することが「第三者への開示」に該当するかは契約 内容によるが、安全側に倒して扱うべきである。「自社の情報なら自分で判断できるが 、他者の情報は勝手に使えない」が基本原則である。
  • 定義例: 「第三者から受領した情報は、原則としてAIに入力しない。やむを得ず 入力する場合は、当該情報に適用される守秘義務の範囲を確認し、必要に応じて情報提 供元の承諾を得る」
• 3.2.D. [Required] 契約上の守秘義務との整合性が確認されている [JDLA]
  • 説明: 既存の取引先契約やNDAに「外部サービスへの情報入力禁止」が含まれて いる場合、AI利用がそれに抵触する可能性がある。ガイドライン策定時に既存契約との 整合を確認しておかないと、善意のAI活用が契約違反になりかねない。
  • 定義例: 「主要な取引先との契約・NDAにおける守秘義務条項を確認し、AI入力 が守秘義務に抵触しないことを検証する。抵触のおそれがある場合は、当該取引先の情 報をAI入力禁止リストに追加する」

3.3 個人情報保護

• 3.3.A. [Required] 個人データの入力に関する具体的なルールがある [JDLA] [METI] [AIACT-JP]
  • 説明: 個人情報保護法は個人データの「第三者提供」を制限しているが、AIへの 入力が第三者提供に該当するかは利用形態による。原則禁止とした上で、匿名化による 例外を認めるなど、段階的なルールを設けることで現場の混乱を防ぐ。
  • 定義例: 「個人データ（特定の個人を識別できる情報）は原則としてAIに入力し ない。業務上やむを得ない場合は、①匿名化処理を行う、②匿名化が困難な場合はAI管理 担当者の承認を得る」
• 3.3.B. [Required] 本人同意の要否・取得方法が明記されている [METI] [JDLA] [AIACT-JP]
  • 説明: 個人情報をAIに入力する場合、利用目的の範囲内か、本人の同意が必要か を判断できなければならない。プライバシーポリシーに「AI利用」が含まれていなけれ ば、同意を得ていないのと同じである。
  • 定義例: 「個人情報をAIに入力する場合、既存のプライバシーポリシーでAI利用 が利用目的に含まれているかを確認する。含まれていない場合は、プライバシーポリシ ーを改定し本人に通知するか、個別に本人同意を取得する」
• 3.3.C. [Required] 委託先への提供に該当するかの判断基準がある [METI] [JDLA] [AIACT-JP]
  • 説明: AIサービスへのデータ入力が個人情報保護法上の「委託」に該当する場合 、委託先の監督義務が発生する。一方、サービス提供者側がデータにアクセスしない構 成であれば委託に該当しない場合もある。利用形態に応じた判断基準が必要である。
  • 定義例: 「AIサービスへの個人データ入力が個人情報保護法上の『委託』に該当 するかを、サービスの利用形態（データへのアクセス権限の有無等）に基づき判断する 。委託に該当する場合は、委託先の管理体制を確認し、必要な契約を締結する」
• 3.3.D. [Required] 越境移転（海外サーバー利用）への対応が検討されている [METI] [EU-AIA] [AIACT-JP]
  • 説明: 多くの生成AIサービスは海外（主に米国）のサーバーで処理される。個人 データを海外サーバーに送信することは「外国にある第三者への提供」に該当しうる。 個人情報保護法は越境移転に追加的な要件を課しており、利用するサービスのデータ処 理場所の確認は必須である。
  • 定義例: 「現在利用している生成AIサービスは海外サーバーで処理されるため、 個人データの入力は原則禁止とする。今後、国内サーバーで処理されるサービスを導入 した場合は、越境移転の該当性を再評価した上で取り扱いを見直す」

4. 出力の管理と利用

4.1 出力の検証義務

• 4.1.A. [Required] 出力内容の正確性確認（ファクトチェック）が義務付けられている [NIST: MEASURE 2.5] [JDLA] [FUJITSU]
  • 説明: 生成AIの出力は「もっともらしいが正しいとは限らない」。自然な文章で あるほど誤りに気づきにくく、検証せずに利用した結果、誤情報を社外に出してしまえ ば組織の信頼を失う。ファクトチェックは手間ではなく、AI活用の最低限の安全装置で ある。
  • 定義例: 「AI出力を業務に利用する場合、事実情報（数値・日付・法令名・人名 ・固有名詞等）は必ず一次情報源で裏取りを行う。裏取りが困難な情報は、AI出力であ る旨を付記して共有する」
• 4.1.B. [Required] 専門分野（法務、財務、技術等）における専門家レビューの要否基準がある [NIST: MEASURE 1.3] [JDLA]
  • 説明: 法律の解釈、財務上の判断、技術的な正確性は、一般的な知識では検証で きない。専門領域のAI出力を非専門家だけで「確認済み」とするのは、確認していない のと同じである。どの領域で専門家レビューが必要かを予め決めておくことが重要であ る。
  • 定義例: 「AI出力が以下の領域に関わる場合は、各分野の専門家（または外部顧 問）によるレビューを必須とする：①法的判断・契約内容、②財務・会計処理、③技術的 な安全性、④医療・健康に関する情報」
• 4.1.C. [Required] 出力をそのまま使用してはいけない場面が明記されている [JDLA] [FUJITSU]
  • 説明: 入力の禁止事項と同様に、出力の利用にも「ここでは使うな」という明確 な線引きが必要である。特に対外的な公式文書や法的効力を持つ文書で無加工のAI出力 を使うのは、組織としてのガバナンスの欠如を示すことになる。
  • 定義例: 「以下の場面ではAI出力をそのまま使用してはならない：①対外公式文 書（契約書・プレスリリース・公式声明）、②法的効力を持つ文書、③人事評価・処遇に 関する文書。これらの用途では草案としてのみ利用し、必ず人間が加筆・修正・承認を 行う」
• 4.1.D. [Required] 人間による最終確認・承認プロセスがある [NIST: MAP 3.5] [METI]
  • 説明: AIはあくまで「下書きをつくる道具」であり、最終的な品質と正確性に責 任を負うのは人間である。出力の重要度に応じて「誰が」「どのタイミングで」確認・ 承認するかを定めることで、ヒューマン・イン・ザ・ループの原則を実現する。
  • 定義例: 「AI出力を業務に利用する場合、①社内利用のみの場合は利用者自身が 確認、②対外利用の場合は上長の承認を必須とする。重大な意思決定に関わる場合はAI 管理担当者にも確認を依頼する」

4.2 著作権・知的財産

• 4.2.A. [Required] 生成物の著作権の帰属に関する考え方が示されている [JDLA] [METI] [AIACT-JP]
  • 説明: AIが生成した文章や画像に著作権が発生するかは、人間の「創作的寄与」 の程度による。プロンプト入力で著作権は発生しない可能性がある。一方、 人間が大幅に加筆・編集すれば著作物となりうる。この曖昧さを組織として整理してお く必要がある。
  • 定義例: 「AI生成物の著作権について、以下の方針を定める：①AI出力をそのま ま使用した場合は著作権が発生しない前提で取り扱う、②人間が実質的な加筆・編集を 行った場合は、編集者の著作物として扱う。利用するAIサービスの規約で生成物の権利 帰属がどう定められているかも確認する」
• 4.2.B. [Required] 既存著作物との類似性チェックの必要性が言及されている [JDLA] [FUJITSU] [AIACT-JP]
  • 説明: AIは学習データに含まれる既存著作物類似の出力をする可能性がある 。利用者が元の著作物を知らなくても、類似性と依拠性が認められれば著作権侵害とな りうる。特に画像やデザインでは、類似性の確認が不可欠である。
  • 定義例: 「AI生成物を対外利用する場合、既存著作物との類似性を可能な範囲で 確認する。画像はインターネット画像検索で類似画像がないか確認し、文章は特徴的な 表現が既存文献と一致しないか検証する」
• 4.2.C. [Recommended] 商用利用時の追加確認事項が定められている [JDLA] [AIACT-JP]
  • 説明: AI生成物を商用利用する場合、非商用利用よりも高い注意義務が求められ る。AIサービスの利用規約で商用利用が制限されている場合もあり、規約違反は契約上 の責任だけでなく、ライセンス取消しにつながるリスクもある。
  • 定義例: 「AI生成物を商用利用（顧客向け成果物、販売物、広告等）する場合は 、①利用するAIサービスの規約で商用利用が許可されていることを確認、②著作権侵害リ スクの追加チェックを実施、③商用利用であることをAI管理担当者に事前申告する」
• 4.2.D. [Option] 画像・音声・動画生成時の特別な注意事項がある [JDLA] [EU-AIA] [AIACT-JP]
  • 説明: テキスト生成に比べ、画像・音声・動画の生成は著作権侵害やディープフ ェイクのリスクが格段に高い。実在する人物の肖像に似た画像の生成、既存キャラクタ ーに酷似したデザインの生成は、肖像権・パブリシティ権・著作権の各侵害につながり うる。
  • 定義例: 「画像・音声・動画を生成する場合は、テキスト生成時の注意事項に加 え、①実在する人物の肖像に似た出力でないか確認、②既存のキャラクター・ブランドに 類似していないか確認、③プロンプトで特定の作家名・作品名を指定しない。生成した 画像等を社外で使用する場合は上長の承認を必須とする」

4.3 出力の表示・開示

• 4.3.A. [Required] AI生成コンテンツであることの表示要否の基準がある [EU-AIA] [METI]
  • 説明: EU AI Actでは一定のAI生成コンテンツに表示義務が課される。日本では 現時点で法的義務はないが、受け手がAI生成物と知らずに意思決定の根拠にした場合、 透明性の欠如が信頼を損なう。どの場面で「AI利用」を明示すべきか、組織として基準 を持つことが重要である。
  • *定義例**: 「以下の場合はAI生成物であることを明示する：①社外向けコンテンツ （広報・マーケティング資料等）、②顧客への提出物。社内利用のみの場合は表示を推 奨とする。明示の方法は、文書末尾への注記（例：『本文書の草案作成にAIを利用して います』）とする」
• 4.3.B. [Required] 社外向け資料でのAI利用に関するルールがある [JDLA]
  • 説明: 社外向け資料にAI出力をそのまま使う場合、誤情報や不適切表現が組織の 公式見解として受け取られるリスクがある。社内メモとは異なり、社外向け資料には組 織としての品質保証が暗黙に求められる。
  • 定義例: 「社外向け資料（提案書・報告書・プレスリリース・公開資料等）にAI 出力を利用する場合、①内容の正確性確認と人間による加筆・編集を必須とし、②上長の 承認を得てから提出・公開する」
• 4.3.C. [Required] 顧客・取引先への説明責任に関する指針がある [NIST: GOVERN 5.1] [METI]
  • 説明: 顧客が「専門家が作成した」と信頼して受け取ったレポートが実はAI出力 のコピペだった場合、信頼関係は深刻に損なわれる。AIを利用したこと自体が問題では なく、利用した事実を適切に伝えないことが問題になる。
  • 定義例: 「顧客・取引先への成果物にAIを活用した場合、求めに応じてAI利用の 事実を説明できるようにする。対面・電話での顧客対応にAIを活用する場合は、AI利用 の旨を事前に伝える」
• 4.3.D. [Option] ディープフェイク等の合成コンテンツへの対応がある [EU-AIA]
  • 説明: AI技術により実在の人物の映像・音声を偽造する「ディープフェイク」は 、詐欺・名誉毀損・情報操作に悪用される。自組織がディープフェイクを作成しないこ とはもちろん、外部から受け取った合成コンテンツへの対応も検討しておく必要がある 。
  • 定義例: 「実在する人物の顔・声を模倣した合成コンテンツの作成を禁止する。 外部から受領した映像・音声コンテンツの真正性に疑義がある場合は、 利用前に信頼できる情報源で確認する」

4.4 品質管理

• 4.4.A. [Required] 重要度に応じた承認プロセスが定められている [NIST: MANAGE 1.1] [JDLA]
  • 説明: すべてのAI出力に同じレベルの承認を求めるのは非効率だが、すべてを無 審査で使うのはリスクが高い。出力の利用場面の重要度に応じて承認レベルを段階的に 設けることで、効率と安全のバランスが取れる。
  • 定義例: 「AI出力の利用を3段階の承認で管理する：①低リスク（社内参考資料） ＝利用者自身の確認で可、②中リスク（社外向け資料の草案）＝上長の確認、③高リスク （公式文書・顧客提出物）＝上長承認＋専門家レビュー」
• 4.4.B. [Option] 出力の記録・保存に関するルールがある [NIST: GOVERN 4.2] [IPA]
  • 説明: AI出力を利用した業務で後日問題が発覚した場合、「どのプロンプトで何 が出力され、どう使ったか」を遡れなければ原因究明や再発防止ができない。ただし、 すべてのAI出力を記録するのは小規模組織では現実的でない。対外提出物や重要な意思 決定など、影響の大きい領域に限定して記録を残すのが実務的である。
  • 定義例: 「顧客向け成果物や重要な意思決定にAI出力を利用した場合に限り、 使用したプロンプトの要旨とAI出力の概要を記録し、少なくとも1年間保存する」
• 4.4.C. [Option] 問題のある出力を発見した場合の報告プロセスがある [NIST: MANAGE 4.3] [JDLA]
  • 説明: AIが差別的表現や明らかな誤情報を出力した場合、利用者がそれを報告で きる仕組みがあれば、同じ問題の繰り返しを防ぎやすい。ただし、SaaS型AIサービス をそのまま利用する小規模組織では、問題出力を報告してもモデル自体の改善にはつな がらないため、組織内のガイドライン改善に活かせる範囲での運用が現実的である。
  • 定義例: 「AI出力に重大な問題（明らかな誤情報、差別的表現、個人情報の生成 等）を発見した場合、AI管理担当者に報告する。管理担当者は事例を記録し、必要に応 じて利用ルールの見直しに反映する」

5. 信頼性の確保 (Trustworthiness)

5.1 正確性・信頼性 (Valid & Reliable)

• 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 安全性 (Safe)

• 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 セキュリティ・レジリエンス (Secure & Resilient)

• 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 透明性・説明責任 (Accountable & Transparent)

• 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 説明可能性 (Explainable & Interpretable)

• 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 プライバシー保護 (Privacy-Enhanced)

• 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 公平性・バイアス管理 (Fair – Harmful Bias Managed)

• 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]
  • 説明: バイアスには社会構造に起因するもの、 データの偏りに起因するもの、人間の認知傾向に起因するものがある。 区別の理解でより的確な対策が取れるが、 詳細な分類は教育目的としての位置づけ。
  • 定義例: 「研修等で以下のバイアスの違いを説明する： ①システム的バイアス（社会構造由来）、 ②統計的バイアス（データの偏り由来）、 ③認知バイアス（人間の思い込み由来）」

6. インシデント対応

6.1 報告体制

• 6.1.A. [Required] AIインシデントの定義と報告すべき事象が明確である [NIST: MANAGE 4.1] [IPA] [JDLA]
  • 説明: 「AIに関する問題」の範囲が曖昧だと、 報告すべき事態を見逃す一方、些細な出力ミスまで報告対象になり形骸化する。 具体例つきの定義があれば、現場で迷わず判断できる。
  • 定義例: 「以下の事象をAIインシデントと定義する。 発見次第エスカレーションルート（1.1.E参照）に従い報告する： ①機密情報・個人情報をAIに入力してしまった場合、 ②AI出力の誤情報を検証せず社外に提供してしまった場合」

6.2 対応プロセス

• 6.2.A. [Required] 初動対応の手順が定められている [NIST: MANAGE 2.3] [IPA]
  • 説明: インシデント発生時に「まず何をすべきか」が決まっていなければ、 現場は混乱し対応が遅れる。AI出力を社外へ提供済みであれば、 訂正・回収の遅れが被害拡大につながる。
  • 定義例: 「AIインシデント発生時は以下の手順で初動対応する。 ①当該AI出力の利用を即座に停止する、 ②社外に提供済みであれば提供先と内容を特定する、 ③AI管理担当者の指示に基づき必要な措置（訂正・回収等）を講じる」
• 6.2.B. [Required] 必要に応じた外部報告（当局、顧客等）の基準がある [METI] [EU-AIA]
  • 説明: 個人情報漏えい時の個人情報保護委員会への報告は法的義務であり、 基準なしでは対応が遅れる。経営相談組織では、 顧客へ提供した誤情報の訂正も信頼に直結する。
  • 定義例: 「以下の場合は外部へ報告・連絡する。 ①個人情報の漏えいが疑われる場合は個人情報保護委員会へ報告する、 ②顧客・取引先にAI出力の誤情報を提供した場合は速やかに訂正を連絡する、 ③利用規約違反の可能性がある場合はAIサービス提供者へ確認する」

6.3 記録と改善

• 6.3.A. [Recommended] インシデントの記録・保存と事後レビューの要件がある [NIST: MANAGE 4.2, 4.3] [IPA]
  • 説明: インシデントを口頭報告だけで済ませると、 同じミスが繰り返されても組織として気づけない。 簡易でも記録を残し定期的に振り返ることで、 ガイドラインの改善点が見えてくる。
  • 定義例: 「AIインシデント発生時は、 発生日時・事象の概要・対応内容を簡潔に記録する。 記録はガイドライン見直し（1.2.E参照）の際に振り返り、 再発傾向があれば運用ルールを改定する」

7. ガイドラインとしての完成度

本章の項目は生成AIに特化したものではなく、 組織がガイドライン文書を策定する際に一般的に求められる品質要件です。 生成AIガイドラインも「組織の規程文書」である以上、 これらの基本要件を満たしていなければ実効性を確保できません。

7.1 構成・可読性

• 7.1.A. [Required] 目次・構成が分かりやすい [JDLA]
  • 説明: ガイドラインは「必要なときに必要な情報をすぐ探せる」ことが生命線。 目次がない、構成が論理的でない文書は読まれず、 読まれないガイドラインは存在しないのと同じである。
  • 定義例: 「ガイドラインには目次を設け、 目的→適用範囲→ルール→例外対応→問い合わせ先の順に構成する。 各セクションに見出しを付け、必要な情報へ素早くたどり着けるようにする」
• 7.1.B. [Required] 用語の定義が明確である [NIST] [JDLA]
  • 説明: 「生成AI」「機密情報」「個人情報」などの主要用語の意味が 人によって異なると、同じルールでも解釈がばらつき運用に支障をきたす。 定義のない専門用語は「分からないので読み飛ばす」の原因になる。
  • 定義例: 「ガイドラインの冒頭に用語定義セクションを設け、 『生成AI』『個人情報』『機密情報』『ハルシネーション』等の 主要用語を平易な日本語で定義する」
• 7.1.C. [Recommended] 具体例・FAQが含まれている [JDLA]
  • 説明: ルールだけでは現場で「これはOKか」の判断に迷う場面が多い。 具体例やFAQがあると理解が深まり、研修の素材にもなる。 「抽象的すぎて使えない」は形骸化の典型的な入口である。
  • 定義例: 「主要ルールに対してOK例・NG例を少なくとも1つずつ記載する。 運用開始後に寄せられた質問をFAQとしてまとめ、 ガイドライン改訂時に追加・更新する」
• 7.1.D. [Recommended] 関連文書へのリンク・参照が整備されている [JDLA]
  • 説明: ガイドラインは情報セキュリティポリシーや個人情報保護方針と 連携して運用される。関連文書への参照がなければ、 利用者は文書間の関係を把握できず整合性が見えない。
  • 定義例: 「ガイドライン内で言及する関連文書 （情報セキュリティポリシー、個人情報保護方針、就業規則等）への リンクまたは参照先を明記する」

7.2 実効性

• 7.2.A. [Required] 現場で実際に使える具体性がある [JDLA]
  • 説明: 「個人情報に注意してください」だけでは何をすべきか分からない。 何をしてよいか・何をしてはいけないかが具体的に明示されていなければ、 ガイドラインは飾りになる。
  • 定義例: 「各ルールに対して具体的な行動指針 （入力してよい情報の例、禁止される操作の例等）を記載し、 現場担当者が判断に迷わない粒度で記述する」
• 7.2.B. [Required] 判断に迷う場面での指針が示されている [JDLA]
  • 説明: すべての場面をルールで網羅することは不可能。 グレーゾーンに直面したとき「どう考えるべきか」の指針がなければ、 現場が自己判断し、結果としてルールが形骸化する。
  • 定義例: 「ルールの適用に迷う場合は、 ①入力情報の機密度分類（3.2.A参照）に照らして判断する、 ②判断がつかない場合はAI管理担当者に相談する、の2段階で対応する」
• 7.2.C. [Required] 問い合わせ先・相談窓口が明記されている [JDLA]
  • 説明: ガイドラインを読んでも解決しない疑問は必ず発生する。 問い合わせ先が書かれていなければ「聞く先が分からないから自分で判断する」 ことになり、ルール逸脱の温床になる。
  • 定義例: 「ガイドラインの末尾に問い合わせ先を記載する。 AI利用に関する質問・相談はAI管理担当者○○ （内線XXX、メール: xxx@example.com）に連絡する」
• 7.2.D. [Recommended] 例外対応のプロセスが定められている [NIST: GOVERN 1.3]
  • 説明: 業務上やむを得ずルールの例外を認める必要がある場面は避けられない。 例外処理の手順が定められていないと「特別扱い」が黙認され、 ルール全体の信頼性を損なう。
  • 定義例: 「ガイドラインの適用が業務上困難な場合は、 AI管理担当者に申請し最終責任者の承認を得た上で例外対応とする。 例外の内容と理由は記録し、次回見直し時に恒久対応を検討する」

7.3 管理情報

• 7.3.A. [Required] 文書のバージョン・改訂履歴がある [JDLA]
  • 説明: ガイドラインは改訂されるものである。 版管理がなければ「今読んでいるのは最新版か」の判断がつかず、 旧版のルールに従い続けるリスクがある。
  • 定義例: 「ガイドライン表紙にバージョン番号を記載し、 末尾に改訂履歴（改訂日・改訂内容の概要）を付す。 改訂時は全職員に最新版の所在を通知する」
• 7.3.B. [Required] 制定日・施行日が明記されている [JDLA]
  • 説明: いつから有効な文書かが不明では効力の起点が曖昧になる。 「このルールは私が入職する前にできたものだから知らない」 という言い訳の余地を残してはならない。
  • 定義例: 「ガイドラインに制定日（初版公開日）および施行日を明記する。 改訂時は改訂日と改訂版の施行日を併記する」
• 7.3.C. [Recommended] 次回見直し予定が記載されている [NIST: GOVERN 1.5] [JDLA]
  • 説明: 見直し予定の記載は 「この文書は定期的に更新される」という組織の意志表示である。 記載がなければ策定して終わりの「一度きりの文書」と見なされやすい。
  • 定義例: 「ガイドライン末尾に『次回見直し予定: ○○年○月』と記載する。 見直し時期の到来後、AI管理担当者が改訂要否を検討し、 最終責任者に報告する」
• 7.3.D. [Required] 承認者・責任者が明記されている [JDLA]
  • 説明: 誰が承認した文書かが不明では、 規程としての権威と拘束力が担保されない。 「これ誰が決めたの？」と疑問を持たれた時点で正統性が揺らぐ。
  • 定義例: 「ガイドラインに承認者（最終責任者）の氏名・役職および 承認日を明記する。改訂時も同様に承認記録を更新する」

参考ガイドライン一覧

米国

EU・国際機関

日本（政府・公的機関）

日本（民間団体）

業界別参考資料

付録: ガイドライン準拠レベルの判断根拠

各チェック項目に付与したガイドライン準拠レベル（Required / Recommended / Option）の 判断根拠を記載します。 ガイドライン作成者が自組織への適用可否を判断する際の参考資料として活用されたい。

判断の基本方針は次の通りです。

• Required: 欠落するとガイドラインとして機能しない、 または法令違反・重大リスクに直結する項目
• Recommended: ガイドラインの実効性を高める重要な項目。 除外する場合はその理由を説明できること
• Option: 記載があると望ましい項目。 組織の規模や業種に応じて検討する

なお、本チェックリストの主な対象は、専門のIT部門や技術者がいない小規模組織を想定しています。 ガイドライン準拠レベルの判断にはこの前提が反映されています。

1. ガバナンス体制 (GOVERN)

1.1 組織体制・責任

1.2 ポリシー・規程

1.3 教育・研修

1.4 監視・監査

2. リスクの特定と評価 (MAP)

2.1 利用目的・文脈の明確化

2.2 リスクの分類と評価

2.3 サードパーティリスク

3. 入力データの管理

3.1 入力禁止情報

3.2 データ分類と取り扱い

3.3 個人情報保護

4. 出力の管理と利用

4.1 出力の検証義務

4.2 著作権・知的財産

4.3 出力の表示・開示

4.4 品質管理

5. 信頼性の確保 (Trustworthiness)

5.1 正確性・信頼性

5.2 安全性

5.3 セキュリティ・レジリエンス

5.4 透明性・説明責任

5.5 説明可能性

5.6 プライバシー保護

5.7 公平性・バイアス管理

6. インシデント対応

6.1 報告体制

6.2 対応プロセス

6.3 記録と改善

7. ガイドラインとしての完成度

7.1 構成・可読性

7.2 実効性

7.3 管理情報

用語集

本チェックリストで使用する 生成AI関連の主要な用語を解説します。

更新履歴

v1.0.0 (2026-02-02)

追加

• サンプルガイドライン: チェックリストのRequired/Recommended項目を満たす ガイドライン文書のサンプルを追加（docs/guideline-sample/）
  • 想定組織プロファイル（架空の中小企業経営支援センター）
  • ITリテラシーが低い読者向けに平易な日本語で記述
  • HTML版も同梱（pandocでビルド可能）

変更

• READMEにサンプルガイドラインの説明とGitHub Pagesへのリンクを追加