生成AI利用ガイドラインの作り方（後編）｜生成AI活用のセキュリティ対策【テンプレート付き】

前回の記事では、生成AI利用ガイドラインを整備するうえで最初に揃えるべき3つの軸——「データを3つに分類する」「ツールごとのデータ取り扱いを整理する」「業務・部門ごとに判断軸を定める」を、比較表とテンプレートの章構成とともに整理しました。
経営層がルールより先にAIを使い始めている、という変化に対する「最初の一手」としての3軸です。

本記事では、AI特有のセキュリティリスクを「入力データ管理・出力物管理・インシデント対応」という3つの領域で整理し、「事前ルール・運用中の判断・有事の対応」という運用フローの視点を重ねます。

前回の3軸が「入力の入口で、何を・どのツールに渡してよいか」を決める整理だったのに対し、本記事の3領域は、その入口の先で——出力・契約・インシデントとして——リスクが姿を現す場所ごとに束ね直す枠組みです。

最終的に、生成AI利用ガイドラインテンプレートの第6章以降へそのまま転記できる「章立てと記載項目の地図」を、9マスの診断表とともにお渡しします。

▶生成AI利用ガイドラインのテンプレートをダウンロードする（無料）

AI活用のセキュリティ対策を「3領域」で整理する

AI特有のリスクは、どこで顕在化するかで束ねると、きれいに3つの領域に収まります。

第一の領域は入力データ管理。
何を渡してよく、何を渡してはいけないか。個人情報、NDA対象情報、未公開の経営情報の扱いが集まります。

第二の領域は出力物管理。
返ってきたものをそのまま使ってよいか。著作権、ハルシネーション、各サービスの利用ポリシーへの抵触が集まります。

第三の領域はインシデント対応。
何かが起きた、あるいは起きそうなときにどう動くか。誤入力・誤情報の社外提供・ポリシー違反・アカウント漏洩への初動と再発防止が集まります。

この3つの領域に、もう一段「時間の軸」を重ねます。
それぞれの領域について、事前にどうルール化するか／運用中にどう判断させるか／有事にどう対応するかを考えます。3つの領域と3つの時間軸を掛け合わせると9つのマスができ、これがそのままガイドラインの章立てと記載項目の骨格になります。使い方は後半で診断表としてお見せします。

ここで強調したいのは、禁止リストの限界です。
「これは入れてはいけない」という禁止リストは出発点としては有効ですが、構造的な弱点があります。それが守られているかを、誰も見ていないという点です。
禁止データを入力しても画面上は何事もなく要約が返ってくるため、違反は気づかれないまま時間だけが過ぎていきます。だからこそ禁止リストと同じ重さで「気づける状態」をつくる必要があり、それは一度整えれば終わる禁止リストとは違って、継続的に手間のかかる仕事です。

本記事の3領域が「運用中の判断」と「有事の対応」を必ず含むのは、この考え方を反映しています。

「入力データ管理」──ガイドライン第3章・第7章の設計

入力をめぐるリスクは、個人情報保護法との整合、NDA対象情報の扱い、未公開の経営情報・営業秘密の扱いの3論点に集約できます。
多くのガイドラインはここで「入れてはいけないデータの一覧」を作って終わりますが、実務で詰まるのは一覧そのものではなく、その手前にある法的な判断です。

NDA対象情報をAIに入れると「第三者開示」にあたるのか

NDAを結んで受け取った秘密情報をAIに入力するのは、AIサービス事業者という第三者への「開示」にあたり、NDA違反になるのではないか──。

STORIA法律事務所の解説によれば、この問いは3段階で検討すると整理しやすいとされています（出典: 生成AIへの秘密情報入力とNDA違反｜STORIA法律事務所）。
第一に入力が「開示」にあたるか、
第二に相手方の承諾（明示または黙示）があるか、
第三に違反があったとして現実に損害が生じるか、です。
原則は「AIへの秘密情報入力は『開示』にあたる」と考えるのが安全だとされています。

ただし重要な例外として同解説では、AIサービスが一定の条件を満たせば、セキュリティの担保されたクラウドストレージと実質的に変わらないものとして、黙示の承諾が認められる余地があるとしています。

判断要素として、機械学習目的での利用が禁止されていること、サービス提供者が契約上の守秘義務を負うこと、ISO/IEC 27001・27018・42001 などに適合すること、通信・保存時に暗号化されること、入出力データを保存しない仕様であること、などが挙げられています。

実務的な結論にすると、機密性の高い情報はそもそも入力対象から外す。新しくNDAを結ぶときは、AI利用を許容してもらえるか、特定プランやZDR設定を条件として契約に明記できるかをあらかじめ交渉しておく（参考: 生成AIへの個人情報・営業秘密・機密情報の入力｜Business & Law）。
この「契約段階での織り込み」こそ、ガイドライン第7章に書くべき内容です。

「出力物管理」──ガイドライン第6章の設計

ここからが、多くのガイドラインで手薄になる領域です。出力をめぐるリスクも、著作権・ハルシネーション・各社ポリシーの3論点に絞れます。

著作権：見えにくい「依拠性」というリスク

AI生成物を使うとき、著作権侵害が成立するには判例上ふたつの要件がそろう必要があります。
既存著作物と似ていること（類似性）と、その既存著作物をもとに作られたこと（依拠性）です（参考: AIと著作権について｜文化庁。文化庁は令和6年3月に「AIと著作権に関する考え方について」を取りまとめています）。

やっかいなのは依拠性です。利用者が元ネタを知らなくても、AIが学習データとしてその著作物を読み込んでいた場合、依拠性が認められるリスクがあるとされています。
「自分は何も参照していない」という主観だけでは安全とは言いきれません。社外に出して商用利用するロゴ・広告コピー・イラストなどは、生成後に既存の登録商標・登録意匠との類似性をWeb検索や画像検索で確かめる手順を、ガイドラインに組み込んでおくべきです。

ハルシネーション：そのまま外に出さない、を仕組みにする

AIは、もっともらしいが事実と異なる内容を生成することがあります。固有名詞・数値・日付・引用は特に誤りが紛れ込みやすい領域です。
象徴的なのが、2023年に米国で起きた弁護士の事案です。訴訟の準備書面をChatGPTで作成したところ実在しない判例が6件含まれており、裁判所は担当弁護士に制裁として5,000ドル（約72万円）の支払いを命じました（出典: ChatGPTで資料作成、実在しない判例引用｜日本経済新聞、ChatGPT生成の"存在しない判例"を使った米弁護士｜ITmedia NEWS）。
裁判所は「信頼できるAIツールを使うこと自体は不適切ではない」としつつ、出力の正確性を確かめる責任を放棄した点を問題にしました。

ここに出力物管理の本質があります。
AIに最終成果物を「実行」させるのではなく、あくまで「下書き」までを任せる、と役割を区切ることです。
下書きは人が一次情報で裏を取ってから外に出す。固有名詞・数値・日付・引用は原典で確認する。法律・医療・金融・税務などの専門領域では有資格者の確認を必須にし、重要な意思決定の根拠にするなら複数の情報源で検証する。
これらを努力目標ではなく手順として書き切ることが、第6章の役割です。

各社の利用ポリシー：自社ガイドラインのどこに落とすか

見落とされがちなのが、各AIサービスが独自に定める利用ポリシーへの抵触です。OpenAIは2025年10月29日に Usage Policies を改訂し、有資格者の適切な関与なしに、法律・医療・金融といったライセンスを要する個別アドバイスを提供することを禁止しました（参考: Usage policies｜OpenAI）。
一般的な仕組みの説明はできますが、特定の人への個別具体的なアドバイスをAIの出力だけで完結させることは認められません。

この種のポリシーを落とすためには、「OpenAIではこう書いてある」と転記しないことです。サービスごとのポリシーは頻繁に変わり、転記した瞬間から陳腐化が始まります。
そうではなく「専門領域のアドバイスはAI出力を唯一の根拠にしない。必ず有資格者の確認を経る」という判断軸として書く。判断軸の形にしておけば、どのサービスのポリシー改訂にも耐えられます。
これは後述の「四半期レビューに耐える設計」と直結します。

「インシデント対応」──ガイドライン第8章の設計

3つめの領域は、起きてしまったあとの話です。ここが薄いガイドラインは、有事に機能しません。

AI利用のインシデントは、4つの型に分けると整理しやすくなります。入力NGデータを入れた「入力誤り」、誤情報を社外に出した「出力誤り」、個人プランで業務データを扱っていた「ポリシー違反」、アカウント情報が漏れた可能性のある「アカウント漏洩」。
型ごとに初動が変わるので、「インシデントが起きたら報告」とひとくくりにするより、型を意識した設計のほうが現場で動けます。

「静かな事故」だからこそ、観測が要になる

ここで、2つ目の領域までとは違う難しさが顔を出します。そもそもインシデントが起きたことに気づけるのかという問題です。

AIの事故は煙も音も出しません。禁止データを入力しても、誤った出力を社外へ送っても、システムは淡々と動き続けます。有事の対応フローをどれだけ精緻に書いても、入口の「気づき」がなければ、フローは一度も起動しないまま終わります。

気づける状態をつくるのが観測（オブザーバビリティ）です。
観測は見る対象で3つに分けられます。AIが何を読みに行ったかのアクセスの記録、何を生成し生成しようとしたかの出力の記録、何を実行したかの実行の記録。

この3つは、奇しくも本記事の3領域（入力・出力・インシデント）と重なります。入力を観測するのがアクセスログ、出力を観測するのが出力ログ、と対応づけると、自社で何を記録すべきかが見えてきます。

正直にお伝えすると、観測そのものは事故を防ぎません。観測がしてくれるのは、事故が起きたときに「気づける状態」を保つことだけです。
けれども、その「気づける」がなければ被害は静かに広がります。完全な予防をあきらめ、すばやい発見と対応に価値を置く構えが、AIのインシデント対応には欠かせません。

専任のセキュリティ部隊を持たない企業であればなおさら、まずは管理コンソールの監査ログや利用履歴を「定期的に誰かが見る」という最小限の観測から始めるのが現実的です。

第一報窓口・報告事項・対応部門を設計する

観測で気づいたあと、誰がどう動くか。第一報の窓口は、情報システム部門と法務・コンプライアンス部門の両方を受け皿にしておくのがおすすめです。
技術的な被害の確認と法的リスクの評価は、片方だけでは完結しないからです。

報告内容は最低限この4点に絞ります。
インシデントの型、発生日時と発覚の経緯、入力または提供した内容の概要、使用したサービスとプラン。
この4点があれば初動の判断ができます
（参考: 生成AIインシデント発生時に法務が取るべき対応とは｜Legal AI Insight）。

そして最も大切なのは、空気のつくり方かもしれません。報告が処罰につながると社員が感じた瞬間に、第一報は上がってこなくなります。
隠れたインシデントは観測の網からも漏れ、被害を最大化させます。報告は被害の最小化と再発防止のためであって犯人探しではない、と明文化したうえで、上がってきたインシデントを原因分析し、ルールを改訂し、教育で周知し、次回レビューに反映する再発防止のループを回します。
インシデントの記録は、次に述べる四半期レビューの貴重な入力にもなります。

9マスで自社ガイドラインの「穴」を可視化する

3つの領域を3つの時間軸で並べると、9マスの診断表になります。これが、自社ガイドラインのどこに穴が空いているかを見つけるツールになります。

使い方は単純です。9つのマスそれぞれについて、「自社のガイドラインに、これに当たる記載があるか」を確認し、無ければ一つずつ埋めて行きましょう。

規約変化の速さに耐える「四半期レビュー設計」

前回の記事の最後でも、「四半期ごとのレビュー体制を骨子の段階から組み込む」ことに触れました。ここではそれを、設計のレベルまで具体化します。

OpenAIは2025年10月に Usage Policies を改訂し、Anthropicも2025年8月にコンシューマー向けプランのデータ学習の扱いを変更して、利用者が学習利用の可否を選ぶ形に切り替えました（参考: Claude のデータ学習とプライバシー設定｜Cloudpack）。
さらに EU AI Act が2026年8月に大部分の規定の適用を迎えるなど、規制の側も動いています（参考: EU AI Act 2025-2026｜aiactblog.nl）。
国内でも、経済産業省・総務省の「AI事業者ガイドライン」が2025年3月に第1.1版へ更新されました（参考: AI事業者ガイドライン｜経済産業省）。
各社の利用規約は四半期単位で動いています。

陳腐化に強いガイドラインの作り方は、実はシンプルです。変わるものと変わらないものを、構造で分けておくことです。具体的な設定値・サービス名・各社ポリシーの細部はすぐ古くなるので、本文に直書きせず別表や付録へ切り出します（承認ツール一覧、ツールごとの管理者設定、各社ポリシーへの参照など）。
一方で、データ3分類の考え方、NDAをめぐる判断のフレーム、インシデント対応の骨格、出力物を「下書き」として扱う原則といった判断軸は、サービスが変わっても生き続けます。これらは本体として、めったに書き換えない部分に置きます。

そのうえで本文に「四半期ごとにレビューする」という条項を入れ、見直す対象を別表に名指ししておきます。
テンプレートの第2章の承認ツール一覧、第5章の管理者設定、第6章の各社ポリシー参照、そして第三輪で蓄積したインシデント記録。
これらを定点観測の対象に固定しておけば、レビューは「全文を読み直す」苦行ではなく「決まった数枚の別表を確認する」作業になります。

おわりに──次の一歩

本記事の要点は一つに尽きます。AI活用のセキュリティは、禁止項目を足し算する「禁止リスト」ではなく、入力・出力・インシデントの3つの領域と、事前・運用中・有事の3つの時間軸を掛け合わせた「設計」として捉えるべきだ、ということです。そして、その設計が動き出すかどうかは、最終的に「気づける状態＝観測」を持てるかにかかっています。

次の一歩として、まずは9マスの診断表を手元に置き、自社の現行ガイドラインを当てはめてみてください。空白のマスが、これから書くべき第6章以降の見取り図になります。空白を一つずつ判断軸の形で埋めていけば、半年後の書き直しに怯えないガイドラインに近づいていきます。

ガイドラインテンプレートのご案内

前回の記事でご案内した「生成AI利用ガイドライン テンプレート（Word形式）」は、本記事で深掘りした第6章（出力物管理）・第7章（契約・取引先対応）・第8章（インシデント対応）まで、3輪フレームに沿った章立てと記載項目を一通り収めています。
前編で扱った前半（第1〜5章）と本記事の後半を、ひとつのテンプレートで通して設計できる構成です。
巻末の自社向けカスタマイズガイドを使って、自社の実情に合わせて書き換える出発点としてお使いください。