Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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]
    • 説明: 誰が承認した文書かが不明では、 規程としての権威と拘束力が担保されない。 「これ誰が決めたの？」と疑問を持たれた時点で正統性が揺らぐ。
    • 定義例: 「ガイドラインに承認者（最終責任者）の氏名・役職および 承認日を明記する。改訂時も同様に承認記録を更新する」