LLM 社内ガイドラインとは、組織が生成 AI を安全かつ統制された形で活用するために定める利用規則・運用手順の体系です。

承認を得ないまま業務で生成 AI を使う「シャドー AI」は、機密情報や個人データの意図しない外部送信につながるリスクがあります。個人情報保護委員会は 2023 年 6 月に生成 AI サービス利用に関する注意喚起を公表しており、組織としての対応が急務となっています。

本記事では、情報システム担当者・DX 推進担当者を対象に、以下の内容を順を追って解説します。

結論: 承認されていない生成 AI ツールの業務利用が広がる今、ガイドラインのない組織は情報漏えいリスクに無防備なまま晒されている。

生成 AI の普及により、社員が個人判断で LLM を業務利用する「シャドーAI」が急増しています。次の H3 では、具体的なリスクの実態と、ガイドラインが必要な理由を掘り下げます。

「個人が勝手に使っているだけだから、大したリスクではない」と考えがちですが、実際にはシャドーAIこそが情報漏えいの最も見えにくい入口になっています。

シャドーAIとは、IT部門や経営層の承認を経ずに従業員が業務で利用するAIツールの総称です。典型的なのは、無料プランのLLMサービスに社内の顧客データや契約書の文面をそのまま貼り付けるケース、あるいは個人契約のクラウドAIに機密性の高い会議メモを入力するケースです。

漏えいの経路は大きく四つに分かれます。まず、社内資料をそのままプロンプトに貼り付けることで、サービス側のサーバーに平文データが送信されます。次に、無料・低価格プランではモデル改善のために入力データが利用される利用規約になっているサービスが存在します。さらに、個人アカウントで利用しているため退職後もアクセス権が残るリスクがあり、加えて誰が何を入力したか組織側で把握できないため、漏えい後の原因調査が困難になります。

個人情報保護委員会が2023年6月に公表した注意喚起でも、生成AIサービスへの個人情報入力が個人情報保護法上の第三者提供に該当しうる点が指摘されています。

問題の根深さは、被害が表面化しにくいことにあります。従業員は悪意なく利便性を求めてAIを使っており、漏えいが発覚するのは数か月後というケースも少なくありません。

ガイドラインが整備されていない状態で生成 AI の利用が広がると、組織は大きく 3 つのリスクにさらされます。

① 機密情報の意図せぬ外部送信 社員が業務上の機密データをそのままプロンプトに貼り付けてしまうケースが報告されています。クラウド型 LLM サービスの多くは入力データをモデル改善に利用する設定がデフォルトになっている場合があり、意図せず機密情報が外部に渡るリスクがあります。個人情報を含む入力であれば、GDPR や日本の個人情報保護委員会が 2023 年 6 月に公表した注意喚起が示すように、法的責任を問われる可能性があります。

② コンプライアンス違反と監査証跡の欠如 利用ツールや入力内容が記録されていない場合、インシデント発生後の原因追跡が困難になります。医療・金融・法務などの規制業種では、HIPAA や GDPR が定める記録保持義務を満たせず、監査指摘や罰則につながるリスクがあります。一方、規制が比較的緩い業種であっても、内部統制の観点から証跡の欠如は経営リスクとなります。

③ 生成結果への過信による意思決定ミス LLM は事実に見えるが誤った情報（ハルシネーション）を出力することがあります。ガイドラインがなければ、生成結果の検証手順が定まらず、誤情報をそのまま社外資料や意思決定に使用するリスクが高まります。

これら 3 つのリスクは独立して発生するものではなく、連鎖することで被害が拡大する傾向があります。

結論: ガイドライン策定は現状把握と推進体制の整備から始まる。土台なき策定は形骸化を招く。

策定に着手する前に、社内でどのような AI ツールがどの部門で使われているかを把握し、責任者・推進メンバーを明確にする必要があります。この準備段階を省略すると、実態と乖離したポリシーが生まれやすくなります。

棚卸しは、影の見えない在庫を数える作業に似ています。把握できていないツールはポリシーで管理できないため、まず「何が使われているか」を可視化することが出発点です。

棚卸しの主な調査手段

• ネットワークログの確認: プロキシやファイアウォールのログから、生成 AI サービスへのアクセス履歴を抽出する。ChatGPT・Copilot・Gemini 等の主要サービスのドメインを対象に絞ると効率的です
• アンケート調査: 部署単位で「業務に使っているAIツール名・用途・頻度」を回答してもらう。匿名形式にすることで、非公式利用の申告率が上がる傾向があります
• SaaS 管理ツールの活用: すでに SaaS 管理ソリューションを導入している場合は、アプリケーション一覧から AI カテゴリを抽出できます

棚卸し結果の整理方法

調査で収集した情報は、以下の項目で一覧化します。

棚卸しの結果、「正式に承認されていないが現場で広く使われているツール」が複数見つかるケースは少なくありません。

ガイドライン策定を「情報システム部門だけの仕事」と捉えがちですが、実際は法務・人事・事業部門を巻き込まないと形骸化しやすい傾向があります。責任範囲があいまいなまま進めると、ポリシーが完成しても現場への浸透が進まず、結果としてシャドーAI を抑制できないケースが多く報告されています。

体制づくりの第一歩は、関与すべきステークホルダーを役割ごとに明確化することです。一般的には以下の 4 つの役割が必要になります。

• オーナー（CISO または DX 推進責任者）: ポリシー全体の意思決定権と最終承認を持つ
• 法務・コンプライアンス担当: GDPR や個人情報保護法への適合性を審査する
• 情報システム担当: ツールの技術評価・ログ管理・アクセス制御を担当する
• 事業部門代表: 現場ニーズを反映し、実効性のあるルール設計を支援する

各役割には「誰が何を決め、何を実行し、何を報告するか」を RACI マトリクス（Responsible / Accountable / Consulted / Informed）で整理すると、後工程での認識齟齬を減らせます。

また、ガイドライン策定プロジェクトには期限と定例会議を設けることが重要です。「忙しくなったら後回し」が続くと、現場でのAI利用が先行し、ポリシーが追いつかない状態に陥ります。月 1 回程度のレビュー会議をカレンダーに固定し、進捗と課題を共有する仕組みを最初に整えておきましょう。

「どのAIツールなら使っていいのか」――この問いに現場が自分で答えられる状態を作ることが、ガイドライン策定の出発点になる。

ツールの可否と扱えるデータの範囲を同時に定義することで、現場の判断ブレを防ぐことができる。具体的には、社内で使われるAIツールを「承認済み・条件付き・禁止」の3段階に分類し、入力データの機密レベルと組み合わせてルールを明確化する。以降では、その分類基準と機密レベルの設定方法を詳しく見ていく。

「このツール、使っていいのか悪いのか、結局どこに聞けばいいんだろう」——現場担当者がこう感じた瞬間、ガイドラインへの信頼は失われます。曖昧な線引きがシャドーAIを生む最大の温床です。

そこで有効なのが、AIツールを 3段階 に分類して管理する方法です。

① 承認済みツール（Approved） 情報システム部門がセキュリティ評価を完了し、全社員が所定の手順で利用できるツールです。利用ログの取得やデータ処理地域の確認が済んでいることが条件となります。

② 条件付き利用（Conditional） 特定の部署・用途・データ種別に限り利用を認めるカテゴリです。たとえば「社外秘情報を入力しない」「個人情報を含まない業務テキストのみ」といった制約を明示します。利用前に上長承認を必要とするケースが多く、申請フォームとセットで運用します。

③ 禁止ツール（Prohibited） データが学習に使われる可能性がある、または処理地域が不明なツールは禁止区分に置きます。禁止理由を一覧で公開することで、「なぜ使えないのか」を現場が納得しやすくなります。

分類を機能させるには、以下の 3 点がポイントです。

データの機密レベル分類は、いわば「鍵のかかり具合を荷物の中身で決める」作業です。何でも同じ扱いにすると、重要情報が無防備に AI へ渡るリスクが生じます。

機密レベルは、以下の 3 段階で設定するのが現場での運用しやすさにつながります。

• レベル 1（公開情報）: 社外公開済みのマーケティング文章、製品仕様書など。外部クラウド型 LLM への入力を許可
• レベル 2（社内限定情報）: 社内マニュアル、会議議事録、未公開の財務データなど。承認済みの企業向けプランまたはオンプレミス環境のみ利用可
• レベル 3（機密・個人情報）: 顧客の個人情報、契約書、人事評価データなど。原則として AI への入力を禁止し、匿名化・マスキング処理を必須とする

個人情報保護委員会が 2023 年 6 月に公表した注意喚起でも、個人データを生成 AI サービスへ入力することへの慎重な対応が求められています。GDPR が適用される欧州との取引がある場合は、さらに厳格な制限が必要です。

取り扱いルールの設定では、次の点を明文化してください。

• 入力前に機密レベルを確認するチェック手順
• 匿名化・マスキングの具体的な方法（氏名→「〇〇様」への置換など）
• 出力結果の社外共有可否と保存期間

レベル分類は一度決めて終わりではなく、新たなデータ種別が生まれるたびに見直すことが重要です。次のステップである承認フロー設計と組み合わせることで、分類ルールが形骸化せず機能し続けます。

ツール分類が終わっても、申請から承認までの手順が曖昧なままでは、現場担当者は判断に迷い、結果として「とりあえず使ってみよう」というシャドーAI利用を招く。誰が・何を・どう申請するかを明文化した承認フローの設計が、次の課題となる。本セクションでは、リスク評価チェックシートと承認フローのテンプレートを順に解説する。

新規 AI ツールを組織に持ち込む前に、リスク評価のステップを踏むことで、後工程の承認フロー設計が格段にスムーズになります。

評価チェックシートには、以下の観点を最低限盛り込んでください。

データ取り扱い

• 入力データはサービス提供者のサーバーに送信されるか
• 学習データへの利用オプトアウトが可能か
• 個人情報・機密情報を入力する業務ユースケースに該当するか

セキュリティ・コンプライアンス

• SOC 2 Type II や ISO 27001 等の第三者認証を取得しているか
• GDPR や個人情報保護委員会が示す「生成 AI サービスの利用に関する注意喚起等（2023 年 6 月）」との適合性
• 契約上のデータ処理合意（DPA）が締結可能か

ベンダー信頼性

• 企業規模・サービス継続性のリスク
• インシデント発生時の通知義務・SLA の有無

業務適合性

• 既存の IT 資産・認証基盤（SSO 等）との統合可否
• 利用部門の規模と想定ユーザー数

ツールの導入目的が「個人の作業補助」にとどまる場合は簡易評価（上記チェックリストの確認のみ）で足りますが、顧客データや社外秘情報を扱う業務プロセスに組み込む場合は、情報システム部門と法務・コンプライアンス部門の合同レビューを必須とするのが妥当です。

チェックシートの結果は「承認」「条件付き承認（制限事項を明記）」「却下」の三択で記録し、判断根拠とともに台帳に残してください。

「承認申請を出したのに、誰が決裁者なのかわからず止まってしまった」という経験は、現場担当者なら一度は覚えがあるのではないでしょうか。承認フローは設計段階から決裁者・代理承認者・期限を明文化しておかないと、形骸化するリスクがあります。

テンプレートに含めるべき項目は以下の通りです。

• 申請者情報: 氏名・所属部署・利用開始予定日
• ツール概要: サービス名・提供事業者・利用目的・対象業務
• 入力データの機密レベル: 前セクションで定めた分類（公開／社内限定／機密）を記載
• リスク評価結果: チェックシートのスコアと判定区分
• 承認者: 一次承認（直属の管理職）→ 二次承認（情報システム部門またはセキュリティ担当）の 2 段階を基本とする

運用上の注意点は次の 3 点が特に重要です。

1. 承認期限を設ける: 申請から 5 営業日以内に一次承認、10 営業日以内に最終承認を完了するなど、期限を明示することで「承認待ちのまま現場が非公式利用を始める」事態を防げます。
2. 定期的な利用継続審査: 一度承認したツールも、半年〜1 年ごとに再評価を行い、サービス仕様変更やセキュリティインシデントの発生状況を確認します。
3. 緊急利用の抜け道を塞ぐ: 「試しに使ってみた」を防ぐため、正式承認前の試用を原則禁止とし、どうしても検証が必要な場合は情報システム部門管理下のサンドボックス環境に限定するルールを設けましょう。

結論: ガイドラインはインシデント発生時の初動手順とログ管理がセットで機能して初めて実効性を持つ。

AIに起因する情報漏えいが発生した際、対応手順が曖昧だと被害が拡大しやすいです。このセクションでは、初動対応フローの設計と監査ログの運用サイクルについて解説します。

インシデントが発生した直後、「まず原因を特定してから報告しよう」と考えがちですが、実際は封じ込めと並行した即時報告のほうが被害拡大を防ぐうえで効果的です。原因究明に時間をかけている間にも、漏えいした情報が外部に拡散するリスクは高まり続けます。

初動対応は、次の4ステップで進めることを推奨します。

• 検知・一次確認（0〜30分）: 不審な出力・送信ログ・アクセス異常を確認し、関係するAIツールへのアクセスを一時停止する。担当者が単独で判断せず、直属の上長とセキュリティ担当へ即座に連絡する
• 影響範囲の特定（30分〜2時間）: どのデータが・いつ・どのツールに入力されたかを記録する。個人情報保護委員会が公表している「生成AIサービスの利用に関する注意喚起等」（2023年6月）でも、個人データの入力状況の把握が推奨されている
• 封じ込め・証拠保全（2〜4時間）: 該当セッションのログを保全し、ツールのAPI連携やアカウントを無効化する。証拠となるログは削除・上書きされないよう別媒体に保存する
• 報告・通知（4時間以降）: 社内規定に従い、経営層・法務・必要に応じて監督官庁へ報告する。GDPRが適用される場合は72時間以内の当局通知が義務付けられている点にも注意が必要です

対応フローは事前に文書化し、担当者が変わっても同じ手順で動けるよう整備しておくことが重要です。インシデント対応訓練（テーブルトップ演習）を定期的に実施すると、実際の有事での判断速度が上がる傾向があります。

監査ログ設計は「何を・どこに・どれくらい保存するか」の三軸で考えると整理しやすいです。

取得すべきログの最低限の要素は以下の通りです。

• 操作ログ: ツール名・利用者 ID・利用日時・セッション ID
• 入力ログ: プロンプトのカテゴリ分類（機密レベルのタグ付き）
• 出力ログ: 生成テキストのハッシュ値または要約（フルテキスト保存はデータ量と照らして判断）
• 異常検知ログ: ポリシー違反フラグが立った操作の詳細

保存期間は、扱うデータの機密レベルによって判断軸が変わります。個人情報や営業秘密に関わる操作ログは最低 1 年以上の保存が推奨される一方、一般業務用途の操作ログは 3〜6 か月程度で十分なケースが多いです。GDPR や個人情報保護法が適用される場合は、保存期間の上限にも注意が必要です。

レビューサイクルは、定常レビュー（月次） と トリガー型レビュー（インシデント発生時） の二層構造が運用しやすいです。月次では異常検知フラグの件数推移を確認し、閾値超過があれば原因を特定します。インシデント発生時は 72 時間以内に該当セッションのログを保全・分析する手順をあらかじめ定めておくと、対応漏れを防げます。

ログ保管先についても、社内サーバーと外部クラウドのどちらに置くかでアクセス制御の設計が変わります。クラウド型 LLM サービスを利用している場合、ベンダー側のログ保持ポリシーを契約前に確認し、自社ポリシーとの整合性を取ることが不可欠です。

結論: ガイドラインは策定するだけでなく、全社員が理解し実践できる状態にして初めて機能する。

ツールの分類や承認フローを整備しても、現場の理解が伴わなければシャドーAI は再発しやすいです。役職・職種ごとに研修内容を設計し、定着度を継続的に測る仕組みが不可欠です。

全社員に同じ研修を一律で受けさせるアプローチは、医師全員に同じ手術トレーニングを課すようなもので、役割に合わない内容は定着しにくく、現場での活用にもつながりにくいです。研修設計は「誰が・何のために AI を使うか」を軸に分類するところから始めましょう。

役職・職種ごとに押さえるべき設計のポイントは以下のとおりです。

一般社員（エンドユーザー）向け

• ガイドラインの概要と禁止事項の周知（機密情報の入力禁止など）
• 承認済みツールの操作方法と、問題発生時の報告ルート
• 実際の業務シナリオを使ったロールプレイ形式が効果的

管理職・チームリーダー向け

• 部下の AI 利用状況を把握・監督するための観点
• ガイドライン違反を発見した際のエスカレーション手順
• リスク判断の基準（どこまで現場で判断し、どこから上申するか）

IT・情報セキュリティ担当者向け

• ツールの技術仕様評価、API 連携時のデータフロー確認
• ログ取得・監査対応の実務手順
• インシデント発生時の初動対応チェックリストの活用方法

経営層・意思決定者向け

• AI リスクの全社的な影響範囲と経営責任の所在
• NIST AI RMF 1.0 などの国際フレームワークに基づくガバナンス概要
• ガイドライン改定の承認プロセスにおける役割

研修の形式は、一般社員には短時間の e ラーニング（15〜20 分程度）、IT 担当者にはハンズオン形式のワークショップが適しています。

研修後の理解度テストは「合格率を上げること」が目的になりがちですが、実際に定着を測るには「行動変容を確認できる設問設計」のほうが効果的です。知識の暗記より、実務場面での判断力を問う構成に切り替えることが重要です。

理解度チェックを設計する際は、以下の3つの観点を軸にしてください。

• シナリオ型設問を中心にする: 「顧客の個人情報が含まれるメールの文面を AI に入力しようとした。どう対応するか」のように、実際の業務場面を想定した選択問題を用意する
• 役職・職種別に設問を変える: 管理職には承認フローの判断問題、一般社員には入力データの分類問題を出題するなど、担当業務に即した内容にする
• 不正解パターンを分析する: 特定の設問で誤答が集中している場合、そのテーマに関する説明が不足しているサインと捉え、研修コンテンツの改善につなげる

実施タイミングも重要です。研修直後だけでなく、3か月後に同じ設問で再テストを行うことで、知識の定着度を継続的に確認できます。スコアが下がっていれば、定期的なリマインド施策（メールやチームへの通知）が必要なサインです。

また、理解度チェックの結果は「個人の評価」に使わず、「ポリシーの改善指標」として活用することを社員に明示してください。評価に使われると感じると、社員が正直に回答しなくなる恐れがあります。

設問数は10問以内に絞り、回答時間は10分程度を目安にすると、現場の負担を抑えながら継続的に実施しやすくなります。

結論: ガイドライン策定でよく見られる失敗は「厳しすぎる制限」と「作りっぱなし」の2パターンに集約される。どちらも現場の逸脱行動を招くため、設計段階から回避策を組み込むことが重要だ。

詳細は各 H3 で解説する。

「ポリシーを厳しくすれば安全になる」と考えがちですが、現場の実態はむしろ逆に動くことがあります。

承認プロセスが煩雑すぎたり、業務に必要なツールが一律禁止されたりすると、社員は「公式の手続きを踏まずに使えばいい」という判断に至りがちです。これがシャドーAI——組織の管理外で使われる生成AIツール——の温床になります。

現場の担当者なら、「申請しても却下されるなら、こっそり使うほうが早い」と感じた経験があるのではないでしょうか。

厳格すぎるポリシーが逆効果になる典型パターンは以下の通りです。

• 全面禁止・例外なし: 代替手段が提示されないため、私用デバイスや個人アカウントでの利用が増える
• 申請リードタイムが長すぎる: 緊急業務に間に合わないため、承認を待たず使用される
• 禁止理由が不明確: 「なぜダメなのか」が伝わらないと、ルール自体への信頼が失われる

こうした状況では、管理されている公式ツールよりもリスクの高い無審査ツールが使われることになり、情報漏えいの可能性がかえって高まります。

対策として有効なのは、禁止一辺倒ではなく「安全な逃げ道」を用意するアプローチです。承認済みツールのラインナップを充実させ、申請フローを軽量化することで、社員が正規ルートを選びやすい環境を整えることが重要です。ポリシーの厳しさは、現場の利便性とのバランスで初めて機能します。

ガイドラインは、一度作成したら終わりではなく、生き物のように継続的に更新し続けるものです。法令や規制の改定、新しい AI ツールの登場、社内インシデントの発生など、環境は常に変化するためです。

ちょうど自動車の車検のように、一定期間ごとに「今の状態で安全に走れるか」を点検する仕組みが必要です。ガイドラインも同様に、定期的な見直しサイクルを制度として組み込むことが重要です。

改定サイクルの設計ポイントは以下のとおりです。

• 定期レビューのタイミングを決める: 最低でも年 1 回、理想的には半年ごとに見直しの機会を設ける。経済産業省・総務省が公表した「AI 事業者ガイドライン（第 1.0 版）」（2024 年 4 月）や NIST AI RMF 1.0 なども改定・更新されるため、最新動向の確認を定期レビューに組み込む
• トリガー型の臨時改定を設ける: インシデント発生時、新規ツールの全社展開時、法改正・規制変更時には、定期レビューを待たず即時改定を検討する
• 改定履歴を可視化する: バージョン番号と変更理由を記録し、全社員がいつでも差分を確認できる状態にする
• 現場フィードバックを収集する: 四半期ごとに現場担当者からの改善提案を受け付ける窓口を設け、ガイドラインの実効性を継続的に検証する

改定後は必ず周知研修を実施し、更新内容を社員が確実に把握できるようにすることも欠かせません。

Q1. 中小企業でもガイドラインは必要ですか？

従業員数が少なくても、生成 AI ツールを業務利用する以上はポリシーが必要です。規模が小さいほど情報漏えい発生時の影響が相対的に大きくなる傾向があります。まずは「使ってよいツール」「入力禁止データ」の 2 点だけを 1 ページにまとめるところから始めると、負担を抑えながら最低限のリスク管理が実現できます。

Q2. 既存の情報セキュリティポリシーとどう統合すればよいですか？

既存ポリシーに「AI 利用に関する附則」として追記する形が、審査・承認コストを最小化できます。データ分類基準や情報持ち出しルールはそのまま流用し、AI 固有の項目（プロンプト入力制限・出力の二次利用禁止など）を差分として加える方法が現場に受け入れられやすいです。

Q3. 無料の AI ツールを個人端末で使う場合はどう扱いますか？

個人端末・個人アカウントでの業務利用は「シャドー AI」の典型例です。ガイドラインには「業務データを個人所有のアカウントや未承認サービスに入力しない」と明記し、違反時の対応手順もあわせて規定することを推奨します。禁止だけを打ち出すと抜け道利用が増えるため、承認済みの代替ツールをセットで提示することが重要です。

本記事で解説してきた内容を振り返ると、ガイドライン策定とは「制限をかける作業」ではなく、現場が安心してAIを使い倒せる土台を整える作業だということがわかります。

現状把握と体制づくりから始まり、ツールの3段階分類、承認フローの設計、インシデント対応とログ管理、そしてAIリテラシー研修という5つのステップは、それぞれが独立した施策ではなく、一連の流れとして機能します。どれか一つが欠けると、たとえば分類だけ整備してもフローがなければ形骸化しますし、研修だけ実施してもインシデント対応が未整備なら有事に機能しません。

経済産業省・総務省が2024年4月に公表した「AI事業者ガイドライン（第1.0版）」や、NIST AI RMF 1.0 といった国際フレームワークも、リスク管理と活用推進のバランスを中心に据えています。自社のガイドラインを策定する際には、これらを参照軸に置きながら、自社の業種・規模・データの機密レベルに合わせて肉付けしていくことが現実的です。

そして、完成したガイドラインは「保管するもの」ではなく「育てるもの」です。生成AI技術の進化速度と規制動向の変化を考えれば、半年や一年ごとの見直しサイクルを最初から設計に組み込んでおくことが、長期的な運用の安定につながります。