会社でクラウド型AIを使う危険性・メリット・デメリット
「うちの会社、ChatGPTを使わせていいのか?」——この問いに答えるための調査記事です。2026年の公的統計と一次情報だけを使い、何が本当に危ないのか、何がメリットなのかを切り分けます。最終章には、そのまま叩き台にできる生成AI利用規程の草案(全22条)を、自己責任でご利用いただく前提で掲載します。
📋 この記事の内容
社内で生成AIの話をすると、だいたい2つの意見がぶつかります。「情報漏えいが怖いから禁止すべきだ」と「使わないと他社に置いていかれる」。どちらも正しいのですが、この対立が解けないのは、「クラウド型AI」という言葉が、まったく性質の違う3つのものをまとめて指してしまっているからです。
この記事では、まずその3つを切り分けます。そのうえで、2026年に公表された調査データ——IPAの脅威ランキング、IBMの侵害コスト調査、Verizonのデータ侵害レポート——を使って、実際に何が起きているのかを確認していきます。結論を先に言うと、危ないのはAIそのものではなく、会社が把握していないところで社員が個人アカウントを使っている状態です。
本記事は2026年8月時点で公開されている一次情報をもとにした調査記事です。法令解釈や契約条件は変わります。実際に社内ルールを定める際は、必ず自社の法務・情報システム部門、必要に応じて弁護士の確認を受けてください。最終章の規程草案も、そのまま使えることを保証するものではありません。
まず整理:クラウド型AIは3種類ある
ここを混ぜたまま議論すると、必ず判断を誤ります
「クラウド型AI」と一口に言っても、会社にとっての意味はまったく違います。次の3つに分けてください。この分類だけで、この記事の議論の8割が整理できます。
| 区分 | 例 | 入力の学習利用 | 会社から見える? | 主なリスク源 |
|---|---|---|---|---|
| ① 個人向けプラン 無料・個人課金 |
ChatGPT Free / Plus / Pro、無料のAIサイト全般 | 既定でON (自分で切る必要あり) |
見えない | 社員の無断利用、規約の一方的変更、訴訟時のログ保全 |
| ② 法人プラン 会社が契約 |
ChatGPT Business / Enterprise、Microsoft 365 Copilot、Gemini for Workspace | 既定でOFF | 見える (管理者機能・監査ログ) |
権限設計のミス、プロンプトインジェクション、社内データの横断露出 |
| ③ API・AI基盤 自社システムに組込 |
OpenAI API、Azure OpenAI Service、Amazon Bedrock、Vertex AI | 既定でOFF ZDR契約なら保存もしない |
見える (自社で全ログ管理) |
自社実装の脆弱性、APIキー管理、AIエージェントの過剰権限 |
※ ZDR=Zero Data Retention(入力も出力も保存しない契約形態)。プラン名・仕様は変更されるため、導入前に必ず提供事業者の最新のドキュメントを確認してください。
「クラウドだから危ない」は正確ではない
②と③は、契約で入力データの扱いが定められ、管理者が利用状況を見られます。むしろ危険なのは①——それも「会社が知らないうちに使われている①」です。つまりリスクの大きさを決めているのは、クラウドかどうかではなく、契約形態と可視性だということになります。
🔍 図:入力した情報はどこへ行くのか(3類型の比較)
この図の一番の要点は、右端の列です。①だけが「会社の管理外に情報が残り続ける」構造になっています。第5章で詳しく見ますが、この差が実際の裁判で意味を持った事例が、すでに存在します。
第1章 おわり — 次は第2章
メリット:数字で確認できること
期待値ではなく、調査で確認されている範囲だけを見る
まずメリットから見ていきます。ここで大事なのは、「AIで生産性が上がる」という一般論と、実際の調査結果は少しずれているということです。誇張せず、確認できている範囲だけを並べます。
導入の実態:目的は明確、効果はまだ測れていない
| 調査項目 | 数値 | 出典 |
|---|---|---|
| 業務効率化・生産性向上を目的に取り組む企業 | 94.1% | DirectCloud調査 |
| 「明確な効果はまだ不明」と回答した企業 | 52.9% | DirectCloud調査 |
| 就業者の業務での生成AI利用率 | 32.4%(週4日以上のヘビーユーザーは11.7%) | パーソル総合研究所 |
| 企業規模別の活用率 | 大企業 46.5% / 中小企業 32.4% / 小規模企業 28.0% | パーソル総合研究所 |
| 日本企業の国際的な位置づけ | 推進度は平均的だが、効果創出の水準が低い | PwC Japan(5カ国比較) |
これは「AIに効果がない」という意味ではありません。導入したが効果を測る仕組みを作っていない企業が半数、と読むのが正確です。裏を返せば、稟議を通すときに「何をもって成功とするか」を先に決めておけば、それだけで上位半分に入れるということでもあります。導入前に指標(作業時間、問い合わせ一次回答率、ドキュメント作成本数など)を1つ決めてください。
クラウド型「ならでは」の利点
| メリット | 中身 | 自社構築(ローカルLLM)との違い |
|---|---|---|
| 初期投資がほぼゼロ | アカウントを作れば当日から使える | GPUサーバー調達で数百万円規模の初期費用が発生する |
| モデル陳腐化のリスクをベンダーが負う | 新モデルが出れば自動的に使える | 1年で世代交代すると、買ったGPUが重荷になる |
| 統制機能が最初から付く | 監査ログ、SSO/SCIM、DLP連携、保持期間設定 | 自社で全部作る必要がある |
| 第三者認証を説明資料に使える | ISO/IEC 42001(AIマネジメントシステム)を主要ベンダーが取得済み | 自社で認証を取るのは相当な負担 |
| 防御側でも効く | AI・自動化を防御に使う組織は、侵害あたり平均193万ドルのコスト削減 | —(クラウド/自社構築を問わない一般的な効果) |
意外な効用:法人契約そのものがセキュリティ対策になる
法人プランには管理者コンソール、監査ログ、シングルサインオン連携が付いてきます。つまり「会社として1つ契約して全員に配る」こと自体が、次章で扱うシャドーAI対策の本体になります。禁止するより契約するほうが、結果的に安全になるという逆転現象が起きています。
なお、ISO/IEC 42001は2023年12月に発行された、AIマネジメントシステムに関する初の国際規格です。ISO 27001が「情報セキュリティを管理していること」を証明するのに対し、42001は「AIのリスク・影響・挙動をライフサイクル全体で管理していること」を証明します。Anthropicは2025年1月13日に認証取得を公表しており、OpenAI、Google Cloud、AWSなども取得を公表しています。取引先から「AIの管理体制を説明してほしい」と言われたとき、この認証は使える材料になります。
第2章 おわり — 次は第3章
デメリット:危険性とは別の不利
セキュリティの話をする前に、経営上のコストを直視する
「デメリット」と「危険性」は分けて考えたほうが判断しやすくなります。ここでは事故が起きなくても発生する不利を並べます。次章以降が「事故の話」です。
| デメリット | 中身 | 緩和策 |
|---|---|---|
| ランニングコストが読みにくい | 従量課金。利用が伸びるほど費用も伸びる | 部門別に上限を設定。定型・大量処理はローカルLLMへ寄せる |
| ベンダーロックイン | プロンプト資産・独自GPT・エージェント定義が特定ベンダー依存になる | プロンプトを社内文書として管理し、モデル依存の記述を減らす |
| 仕様・規約の一方的変更 | モデル廃止、価格改定、機能変更に自社の都合は通らない | 基幹業務への組み込みは慎重に。代替手段を用意しておく |
| 可用性が他人任せ | 大規模障害が起きれば業務が止まる | 止まったときの手作業手順を残す。単一ベンダー依存を避ける |
| 効果が出ない | 前章のとおり52.9%が「効果不明」 | 導入前に測定指標を1つ決める。使い方の社内共有会を回す |
| 閉域網・オフラインで使えない | 工場、研究所、機微情報を扱う部門では構造的に採用できない | 該当部門だけローカルLLMを別途用意する |
コストの分岐点をどう見るか
一般に、月あたりのAPI費用が10万円を超える規模になると、オンプレミス(自社GPU)のほうが1〜2年で投資を回収できるという試算が出ています。GPUサーバーの導入費用は規模により50〜500万円程度、構築支援が100〜300万円程度が目安とされます。ただしこれは「用途が定型で、処理量が読める」場合の話です。用途が定まっていない段階では、まずクラウドで試すほうが合理的です。
ローカルLLMという選択肢も知っておく
「そもそもクラウドに出せない情報がある」という部門には、手元のPCで動くローカルLLMという選択肢があります。当サイトでは導入手順とセキュリティ上の注意点をまとめています。クラウドとの使い分けを検討する材料にどうぞ。
LM Studioの安全な使い方とOllamaとの使い分け →第3章 おわり — 次は第4章
危険性① シャドーAI=最大の実害
数字が突出しているのは、ここです
シャドーAIとは、会社の承認を得ないまま業務で使われている生成AIサービスのことです。「情シスが把握していないAI利用」と言い換えてもかまいません。2026年の各種調査で、この項目だけが突出した数字を出しています。
| 調査結果 | 数値 | 出典 |
|---|---|---|
| 社用端末で日常的にAIを使う従業員 | 45%(前年15%) | Verizon DBIR 2026 |
| そのうち、会社が管理できない個人アカウント経由 | 67% | Verizon DBIR 2026 |
| 外部AIへ最も多く送信されたデータ種別 | ソースコード(次いで構造化データ、画像、技術文書) | Verizon DBIR 2026(85万件超のDLPイベント分析) |
| 日本の知識労働者の無断利用率 | 78%(米国は63%) | Microsoft調査 |
| AI関連の侵害を経験した組織のうち、AIアクセス制御を欠いていた割合 | 92% | IBM Cost of a Data Breach 2026 |
| 侵害を受けた組織のうちAI利用方針を持っていた割合 | 32%(前年37%から低下) | IBM Cost of a Data Breach 2026 |
| AIガバナンスとセキュリティ部門が連携している組織 | 19% | IBM Cost of a Data Breach 2026 |
2025年版のIBM調査ではもう少し踏み込んだ数字が出ており、シャドーAIが深く関与した侵害は、平均で67万ドル(約1億円)の追加コストを生んでいました。侵害を受けた組織の20%がシャドーAI経由で、そのうち63%はAIガバナンス方針をまったく持っていませんでした。
2023年3月、韓国の大手電機メーカーで、生成AIの社内利用を認めてからわずか20日で3件の情報漏えいが確認されました。内訳は次のとおりです。
① 半導体設備の計測データベースのエラーを解消するため、ソースコードを入力して解決策を質問した
② 歩留まりや不良設備を把握するプログラムのソースコードを入力して最適化を依頼した
③ 社内会議の録音データを文字に起こし、議事録を作らせた
3件とも、悪意はありません。むしろ真面目に業務を効率化しようとした結果です。同社はその後、生成AIツールの社内利用を禁止する通知を出しました。「AIに共有したデータが事業者のサーバーに保存され、容易にアクセスも削除もできなくなる」ことを懸念したためと報じられています。
なぜ「禁止」では解決しないのか
この事例を見て「やはり禁止すべきだ」と考えるのは自然です。しかし、禁止したときに何が起きるかを先ほどの数字が示しています。社用端末でAIを使う従業員の67%が、すでに個人アカウントを使っているのです。つまり——
禁止すると、リスクは消えずに「見えなくなる」だけ
会社が承認したツールを用意しないまま禁止すると、社員は自分のスマートフォンや個人アカウントで同じことをします。入力される情報の中身は変わらず、会社の可視性だけがゼロになる——これが最悪の状態です。IPAも、AIリスクは技術そのものより「利用方法や理解不足」に起因する側面が大きいと整理しており、対策としてルール整備・利用状況の把握・教育という組織的な対応を挙げています。
シャドーAI対策として本当に効くこと(優先度順)
- 法人プランを1つ契約し、全社員が使える状態にする(これが本体。禁止だけでは必ず個人アカウントに逃げる)
- 個人アカウントでの業務利用を、規程で明文的に禁止する
- 入力してはいけない情報を1枚の表にして、全員が見られる場所に貼る
- プロキシ・CASB・DLPで、どのAIサービスに何が送られているかを可視化する
- 「うっかり入れてしまった」ときに、罰せずに報告できる窓口を作る
シャドーAIをもう少し詳しく
「見えないデータ流出」がどう起きるのか、従業員側の視点も含めて解説した記事があります。社内研修の材料としてもお使いいただけます。
シャドーAI:見えないデータ流出リスク →第4章 おわり — 次は第5章
危険性② 入力した情報はどこへ行くのか
「学習されない」と「保存されない」は別の話です
法人プランやAPIでは、入力した情報がAIの学習に使われません。これは事実です。ただし、ここで多くの人が読み違えるポイントがあります。「学習に使わない」=「保存しない」ではないということです。
通常、対話の履歴はサービス提供事業者のサーバーに一定期間保存されます。管理者が保持期間を設定できるプランもありますが、既定では残ります。そして——ここからが本題です——保存されている以上、事業者が所在する国の司法手続きの対象になり得ます。
実例:裁判所が「全チャットログを消すな」と命じた
2023年末、米国のある新聞社がOpenAIを著作権侵害で提訴しました。この訴訟の過程で、2025年5月、裁判所はOpenAIに対し「削除済みのものを含め、すべてのチャットログを保全せよ」と命じます。OpenAIはこれを「行き過ぎであり、利用者のプライバシーを危険にさらす」として争いました。
ここで注目すべきなのは、この命令の対象範囲です。
| プラン | 保全命令の対象 | 意味 |
|---|---|---|
| ChatGPT Free / Plus / Pro / Team | 対象になった | 削除したはずの会話も保持され続けた |
| ChatGPT Enterprise / Edu | 明示的に除外 | 管理者が保持期間を制御。削除した会話は30日以内に削除 |
| ZDR契約のAPI | そもそも対象外 | 保存していないため、保全のしようがない |
この無期限保持の義務は2025年9月26日に終了しましたが、訴訟自体は継続しており、その後2,000万件の匿名化されたログの提出が命じられています。
事業者のプライバシーポリシーに何が書かれていようと、海外の司法手続きは、その方針を上書きできます。そして今回、その線引きは「法人契約かどうか」で引かれました。
つまり、社員が個人アカウントで業務情報を入力している状態は、「自社と何の関係もない他国の訴訟によって、その情報が保全対象になる」可能性を抱えているということです。これ1点だけでも、会社として個人向けプランの業務利用を認める理由はありません。
法律上、もっと重い帰結:営業秘密でなくなる
情報漏えいそのものより深刻になり得るのが、こちらです。日本の不正競争防止法で「営業秘密」として保護されるには、次の3要件を満たす必要があります。
| 要件 | 内容 | 生成AIへの入力で何が起きるか |
|---|---|---|
| 秘密管理性 | 秘密として管理されていること | ここが崩れる可能性がある。外部サービスへ入力し、学習データとして再利用された場合など |
| 有用性 | 事業活動に有用な技術上・営業上の情報であること | 通常は影響しない |
| 非公知性 | 公然と知られていないこと | 出力を通じて外部に出れば、これも崩れ得る |
秘密管理性が否定されると、その情報は営業秘密として法的な保護を受けられなくなります。仮に競合他社に持ち出されても、不正競争防止法で戦えなくなるということです。「漏れた」だけでなく「取り返す手段を失う」——これがソースコードや設計情報の入力が特に危険な理由です。
個人情報の場合
個人情報保護委員会は2023年6月2日付で、生成AIサービスの利用に関する注意喚起を出しています。要点は次の2つです。
個人情報保護委員会の注意喚起(要旨)
① 個人情報を含むプロンプトを入力する場合は、特定した利用目的の達成に必要な範囲内であることを十分に確認すること。
② あらかじめ本人の同意を得ずに個人データを含むプロンプトを入力し、当該個人データが応答結果の出力以外の目的で取り扱われる場合、個人情報保護法違反となる可能性があること。
実務的には、顧客名や連絡先を含んだメール文面をそのまま貼り付けて「返信を書いて」と頼む——という日常的な使い方が、まさにこの論点に触れます。氏名を伏せ字にする、固有名詞を「A社」に置き換えるといった一手間で回避できることがほとんどです。
第5章 おわり — 次は第6章
危険性③ 入力しなくても漏れる経路
「機密を入力しない」教育だけでは防げない領域があります
ここまでは「社員が何を入力するか」の話でした。しかし2025年以降、社員が何も入力しなくても情報が出ていく経路が実証されています。社内データに接続したAIアシスタントを導入している会社は、この章が最も重要です。
プロンプトインジェクションとは
大規模言語モデル(LLM)は、「命令」と「処理すべきデータ」を同じ経路で受け取ります。人間なら「これは読むべき資料で、これは指示だ」と区別できますが、AIにはその区別が構造的に難しい。この性質を突き、データの中に命令を紛れ込ませる攻撃がプロンプトインジェクションです。
OWASPが公開している「Top 10 for LLM Applications 2025」では、この攻撃が2版連続で第1位、第2位が「機微情報の漏えい」(前版の6位から急上昇)となっています。
| 順位 | 項目 | 会社での利用に引き直すと |
|---|---|---|
| 1 | プロンプトインジェクション | 外部メール・添付ファイル・Webページに仕込まれた命令にAIが従う |
| 2 | 機微情報の漏えい | AIが社内文書の内容を、意図しない相手・経路に出す |
| 3 | サプライチェーン | 使っているモデル・プラグイン・拡張機能そのものが汚染されている |
| 4 | データ・モデルの汚染 | 参照させている社内ナレッジに、攻撃者が仕込みを入れる |
| 5 | 不適切な出力処理 | AIの出力をそのままシステムに流し込んで、別の脆弱性を踏む |
| 6 | 過剰な代理権(Excessive Agency) | AIエージェントに与えた権限が広すぎる |
| 7 | システムプロンプトの漏えい | 社内向けの指示文が外部に露出する |
| 8 | ベクトル・埋め込みの弱点 | 社内文書検索(RAG)の仕組みを通じた情報の混線 |
| 9 | 誤情報 | ハルシネーションを検証せずに使い、誤った意思決定をする |
| 10 | 無制限な消費 | コストの暴走、サービス妨害 |
実証された事例:メール1通で社内文書が流出し得た
2025年6月に公表された、Microsoft 365 Copilotの脆弱性です。攻撃の流れは次のとおりでした。
① 攻撃者が、一見なんの変哲もないメールを1通送る。本文にはHTMLコメントや「白背景に白文字」でAIへの命令が隠されている。
② 受信者は何もしなくてよい(開く必要すらない、いわゆるゼロクリック)。
③ Copilotがそのメールを処理する過程で、隠された命令を「指示」として解釈する。
④ Copilotが自分のアクセス権の範囲——OneDrive、SharePoint、Teamsのメッセージ、社内文書——を読み取り、攻撃者のサーバーへ送信する。
Microsoftはサーバー側で修正済みで、実環境での悪用は確認されていません。しかしこれは「本番稼働しているAIシステムで、プロンプトインジェクションによる具体的なデータ持ち出しが実証された初のケース」と位置づけられています。
この事例の教訓は明快です。「社員が機密を入力しないようにする」という対策では、この経路は1ミリも防げません。防ぐべきは、AIに与えたアクセス権の広さのほうです。
社内データにAIを繋ぐ前にやること
- SharePoint・OneDrive・共有フォルダの過剰な共有設定を棚卸しする(AI導入で一気に顕在化する)
- AIが参照できる範囲を、利用者本人のアクセス権の範囲内に限定する
- 外部から届いた文書を自動処理させる仕組みは、出力先と外部通信を制限する
- 「AIが読める場所」に置いてよい情報の基準を決める
AIエージェントの過剰権限
2026年に入って新しく大きくなっているのが、AIエージェント——AIが自分で判断して、メールを送る・データを更新する・システムを操作する仕組み——のリスクです。
事故の大きさを決めるのは「自律性」ではなく「権限」
AIがどれだけ賢いか・自律的かではなく、そのAIに何を実行させる権限を与えたかが被害の規模を決めます。2026年初頭には、認証設定を欠いたまま公開状態にあったAIエージェント基盤が900件以上発見され、APIキー・OAuthトークン・会話履歴が平文で読める状態だったと報告されました。OWASPのエージェント向け脅威リストでも「エージェントの目標乗っ取り」が第1位に挙げられています。
対策の原則は、従来のシステム設計と変わりません。最小権限と重要な行為の前に人が承認する仕組み(human-in-the-loop)です。総務省・経済産業省の「AI事業者ガイドライン(第1.2版)」も、自律的なAI・AIエージェントの普及に伴うリスクに言及し、ガードレールの実装を求めています。
サービスの所在国という論点
もう1つ、クラウド型AI固有の判断軸があります。データがどこの国に保存され、その国の法律が何を要求するかです。
2025年2月6日、デジタル庁は特定の生成AIサービスについて全府省へ注意喚起を行い、機微情報・個人情報・機密業務情報を入力しないよう要請しました。理由は技術的な欠陥ではなく、法制度にあります。中国の国家情報法(2017年)第7条や、データセキュリティ法(2021年)により、同国の事業者は当局からのデータ提供要求を法的に拒否できない構造になっている、というものです。
これは「どの国の企業だから悪い」という話ではありません。AIサービスを選ぶとき、性能と価格だけでなく「保存先の国とその法制度」まで確認する必要があるという、手順の話です。同じ観点は、米国のCLOUD Actなど他国の制度にも当てはまります。自社が扱う情報の機微性に応じて、保存リージョンを指定できる契約を選ぶ、といった対応が現実解になります。
「危ないAIモデル」を見抜く訓練ができます
配布元の情報を調べて、危険なAIモデルを見抜くシミュレーターを公開しています。実在の脆弱性事例をもとにした全10事件。サプライチェーンのリスクが体感的に理解できます。
AIモデル鑑定士に挑戦する →第6章 おわり — 次は第7章
法規制とガイドライン早見表
2026年は「やった方がいい」から「やっていないと説明できない」へ
社内で稟議を通すとき、最も効くのは公的機関の資料です。2026年8月時点の状況を整理します。
| 制度・資料 | いつ/どこ | 会社への影響 |
|---|---|---|
| IPA「情報セキュリティ10大脅威 2026」 | 2026年1月29日公表 | 「AIの利用をめぐるサイバーリスク」が初選出で組織編3位(1位ランサム攻撃、2位サプライチェーン)。社内説明の根拠として最も使いやすい |
| AI事業者ガイドライン 第1.2版 | 総務省・経済産業省 2026年3月31日 |
法的拘束力のないソフトローだが、「AI利用者」としての遵守が事実上の標準。随時更新される Living Document |
| AI推進法 人工知能関連技術の研究開発及び活用の推進に関する法律 |
2025年5月28日成立 2025年9月1日全面施行 |
EU型の「禁止列挙」ではなく事業者の自主的な取組を尊重する推進法。罰則より説明責任が問われる |
| 個人情報保護法/PPC注意喚起 | 2023年6月2日付 | 本人同意なく個人データを含むプロンプトを入力し、応答生成以外の目的で扱われれば法違反の可能性 |
| 不正競争防止法 | — | 入力により秘密管理性が失われ、営業秘密として保護されなくなるリスク(第5章参照) |
| EU AI Act | 2024年8月発効 2025年2月:禁止規定 2025年8月:汎用AI義務 |
EU向けに事業があれば対象。制裁金は最大3,500万ユーロまたは全世界売上の7%。高リスク分野の規制は延期の方向で議論が進んでおり、最終的な適用時期は要確認 |
稟議で使うなら、この2つ
① IPAの10大脅威2026——公的機関が「AI利用のリスク」を組織向け脅威の3位に置いたという事実は、それ自体が説得材料になります。② AI事業者ガイドライン第1.2版——「国のガイドラインに沿った体制を整える」という言い方は、社内でも取引先に対しても通りやすい。この2つを添えるだけで、稟議の通りやすさは変わります。
第7章 おわり — 次は最終章
【草案】生成AI利用規程(自己責任でご利用ください)
ここまでの調査結果を、そのまま社内規程の形に落としたものです
以下はあくまで「草案」であり、一つの案です。次の点を了承いただいたうえで、自己責任でご利用ください。
① そのまま使えることを保証するものではありません。業種、規模、扱う情報の種類、既存の規程体系によって、必要な条文は変わります。
② 制定前に必ず自社の法務・人事労務部門の確認を受けてください。特に第17条(利用状況の把握)は、従業員のモニタリングに関わるため、事前の周知など実務上の手続きが必要です。
③ 本草案の利用によって生じたいかなる損害についても、当サイトは責任を負いません。
④ 法令・ガイドラインは変わります。〔 〕の箇所は自社の実情に合わせて記入・削除してください。
この草案は「禁止するための規程」ではなく、安全に使える手段を用意したうえで、危ない使い方だけを止めるという設計思想で書いています。第4章で見たとおり、禁止だけの規程はシャドーAIを生むからです。
文書番号 〔例:ISMS-R-021〕 / 制定日 〔 年 月 日〕 / 所管 〔情報システム部〕
第1章 総則
第1条(目的)
本規程は、〔会社名〕(以下「当社」という)の役職員等が業務において生成AIサービスを利用するにあたり遵守すべき事項を定め、次の各号を実現することを目的とする。
- 当社および取引先の機密情報、個人情報ならびに営業秘密の保護
- 法令、契約上の義務および社会的規範の遵守
- 生成AIの積極的な活用による生産性の向上
第2条(適用範囲)
本規程は、当社の役員、正社員、契約社員、嘱託社員、パートタイマー、アルバイトおよび派遣受入者(以下「役職員等」という)に適用する。当社の業務に関して生成AIサービスを利用するすべての場合に適用し、利用端末が会社貸与端末か私物端末かを問わない。委託先・協力会社には、契約により同等の措置を求める。
第3条(定義)
本規程における用語の意義は次のとおりとする。
- 生成AIサービス:入力に応じて文章・画像・音声・動画・プログラムコード等を生成するAIを利用したサービスの総称。対話型サービス、API、業務アプリに組み込まれた機能を含む。
- 法人向けサービス:当社が法人契約を締結し、当社が管理者権限を有する生成AIサービス。
- 個人向けサービス:個人単位で契約または登録して利用する生成AIサービス(無料プランを含む)。
- AIエージェント:生成AIが自律的に判断し、外部システムの操作、データの取得・更新、メッセージの送信等を実行する仕組み。
- シャドーAI:第5条の承認を得ずに業務で利用される生成AIサービス。
第2章 管理体制
第4条(AI利用管理責任者)
当社は、生成AIの利用を統括するAI利用管理責任者を置き、〔情報システム部長〕をもって充てる。AI利用管理責任者は次の業務を行う。
- 生成AIサービスの利用申請の審査および承認
- 利用中のサービスを記録した管理台帳の整備および年1回以上の見直し
- 本規程の遵守状況の確認、および教育の企画・実施
- インシデント発生時の初動指揮
- 本規程の見直しの発議
第3章 利用できる生成AIサービス
第5条(利用の承認)
- 役職員等は、AI利用管理責任者が承認し、別表2「承認済み生成AIサービス一覧」に掲載されたサービスのみを業務に利用することができる。
- 掲載のないサービスを業務に利用しようとする者は、事前に利用申請を行い、承認を得なければならない。
- 役職員等は、業務において個人向けサービスを利用してはならない。私物アカウントによる業務利用も、これに含まれるものとして禁止する。
第6条(サービス選定基準)
AI利用管理責任者は、承認にあたり少なくとも次を確認しなければならない。
- 入力情報がモデルの学習に利用されない設定であること、またはその旨が契約上担保されていること
- データの保存場所および適用される法域が特定でき、当社の情報管理方針上許容できること
- 監査ログの取得、シングルサインオン連携、利用者管理の各機能が備わっていること
- 提供事業者の情報セキュリティ体制が第三者認証等により客観的に確認できること
- 契約上、当社が求める水準の秘密保持義務が課されていること
第4章 入力してはならない情報
第7条(入力情報の区分)
役職員等は、別表1「情報区分と入力可否」に従わなければならない。判断に迷う場合は入力せず、AI利用管理責任者に照会しなければならない。
第8条(入力を禁止する情報)
役職員等は、次の情報を生成AIサービスに入力してはならない。ただし、AI利用管理責任者が個別に承認した場合を除く。
- 個人情報および個人データ(顧客、取引先、従業員、採用応募者に関するものを含む)
- 要配慮個人情報(健康、病歴、犯罪歴、信条等に関する情報)
- 当社の営業秘密(技術情報、ソースコード、設計情報、原価、顧客名簿、事業計画等)
- 第三者から秘密保持義務を負って開示を受けた情報
- 未公表の財務情報、人事情報、組織再編に関する情報その他のインサイダー情報
- 認証情報(ID、パスワード、APIキー、秘密鍵、アクセストークン等)
- 当社のシステム構成、ネットワーク構成、脆弱性に関する情報
- 法令または契約により国外移転が制限されている情報
第9条(匿名化・加工による入力)
前条の情報であっても、個人および組織が特定できないよう十分に加工したうえでの入力は妨げない。加工にあたっては氏名の削除のみでは足りず、他の情報と照合することにより特定が可能となる記述等の削除を含むものとする。加工の十分性に迷う場合は入力してはならない。
第5章 出力情報の取扱い
第10条(検証義務)
- 役職員等は、生成AIの出力をそのまま業務上の成果物として用いてはならず、内容の正確性を自ら検証する責任を負う。
- 次の場合は、根拠を一次情報により確認しなければならない。
・数値、統計、金額、日付を含む場合/・法令、規格、判例、技術仕様に言及する場合/・社外に提出・公開する文書に用いる場合/・意思決定の根拠として用いる場合 - 出力に起因して生じた誤りの責任は、当該出力を利用した役職員等および所属部門が負う。
第11条(権利侵害の防止)
役職員等は、出力が第三者の著作権、商標権、意匠権その他の権利を侵害していないことを確認しなければならない。特定の作家・デザイナー・企業のスタイルを模倣することを目的としたプロンプトを用いてはならない。既存の著作物と類似する表現が含まれる可能性がある場合は〔法務部門〕に相談する。
第12条(プログラムコードの取扱い)
生成AIが出力したコードを本番環境で用いる場合は、他の外部コードと同様にレビューおよびセキュリティ検査を経なければならない。ライセンス上の制約についても確認する。当社のソースコードを入力する場合は、第5条により承認された法人向けサービスに限る。
第6章 社内データ連携およびAIエージェント
第13条(社内データ連携)
- 生成AIサービスを当社の社内システム、ファイルサーバー、メール、チャット等に連携させる場合は、AI利用管理責任者の承認を要する。
- 連携にあたっては、利用者本人がアクセス権限を有する範囲を超えて情報が参照されないよう設定しなければならない。
- 連携の実施前に、対象データ領域の共有範囲を棚卸しし、過剰な共有設定を是正しなければならない。
第14条(プロンプトインジェクション対策)
外部から受領した文書、メール、Webページ等を生成AIに処理させる場合、当該コンテンツにAIに対する不正な指示が埋め込まれている可能性を前提として運用しなければならない。外部コンテンツを自動的に処理する仕組みを構築する場合は、事前に承認を得るとともに、出力先および外部通信の制限を実装しなければならない。
第15条(AIエージェントの権限)
- AIエージェントを業務に導入する場合は、事前にAI利用管理責任者の承認を得る。
- 付与する権限は、業務遂行に必要な最小限とする。
- 次の行為を実行させる場合は、実行前に人による承認を要する仕組みを設けなければならない。
・社外への情報の送信(メール送信、投稿、ファイル共有を含む)/・データの削除または不可逆な変更/・金銭の支払いまたは契約の締結/・本番環境の設定変更 - 実行履歴は記録し、追跡可能な状態で保管する。
- AIエージェントに用いる認証情報およびAPIキーは〔シークレット管理の仕組み〕により管理し、平文でファイルまたはリポジトリに保存してはならない。
第7章 教育
第16条(教育)
AI利用管理責任者は、役職員等に対し年1回以上、生成AIの利用に関する教育を実施する。教育には少なくとも、本規程の内容(特に第8条)、出力の検証の必要性、プロンプトインジェクションの仕組み、過去のインシデント事例を含める。新たに採用された者には、業務での利用開始前に実施する。
第8章 監査およびモニタリング
第17条(利用状況の把握)
当社は、情報漏えいの防止を目的として、会社貸与端末およびネットワークにおける通信ログの取得、法人向けサービスの管理者機能による利用ログの確認、データ損失防止(DLP)の仕組みによる送信内容の検査を行うことがある。実施にあたっては、あらかじめ役職員等に対しその旨を周知する。取得した情報は当該目的の範囲内でのみ利用する。
第9章 インシデント対応
第18条(報告義務)
役職員等は、次のいずれかを認識した場合、直ちにAI利用管理責任者に報告しなければならない。
- 第8条の情報を入力した、または入力したおそれがある場合
- 承認外の生成AIサービスを業務に利用した場合
- 出力に、当社が入力していないはずの他社・他者の機密情報が含まれていた場合
- 生成AIまたはAIエージェントが意図しない動作をした場合
- 提供事業者からセキュリティに関する通知を受けた場合
第19条(報告者の取扱い)
前条の報告を行った者に対し、報告したことを理由として不利益な取扱いをしてはならない。速やかな報告は被害の拡大防止に不可欠であり、当社はこれを積極的に評価する。
第20条(対応手順)
AI利用管理責任者は、報告を受けた場合、次の手順により対応する。
- 事実確認および影響範囲の特定(入力内容、入力先サービス、契約上の学習・保存条件)
- 当該サービスにおける会話履歴の削除およびデータ削除請求の要否判断
- 個人データが含まれる場合、個人情報保護委員会への報告および本人通知の要否判断
- 第三者の情報が含まれる場合、当該第三者への通知の要否判断
- 再発防止策の策定
第10章 雑則
第21条(違反時の措置)
本規程に違反した役職員等に対しては、就業規則に基づき懲戒処分を行うことがある。ただし、第18条による自主的な報告があった場合は、その事情を考慮する。
第22条(改廃)
本規程の改廃は〔承認機関〕の承認を経て行う。AI利用管理責任者は、関係法令・ガイドラインの改正があった場合、新たな類型のAIサービスを導入する場合、重大なインシデントが発生した場合、または前回の見直しから1年を経過した場合に、見直しを発議する。
附則
本規程は〔 年 月 日〕から施行する。
別表1 情報区分と入力可否
この表は、規程本体よりも実用的です。1枚に印刷して、全員が見える場所に貼ってください。
| 区分 | 情報の例 | 承認済み法人サービス | 個人向けサービス |
|---|---|---|---|
| 公開情報 | 自社サイト掲載内容、プレスリリース、公開済み製品仕様、一般的な技術知識 | ○ 可 | △ 業務利用は禁止 |
| 社内一般情報 | 社内向け手順書、一般的な業務メールの文案、機密性の低い企画のたたき台 | ○ 可 | × 禁止 |
| 顧客・個人に関する情報 | 氏名、連絡先、契約内容、問い合わせ履歴、従業員情報、採用応募者情報 | × 禁止 (十分な匿名化後は可) | × 禁止 |
| 営業秘密 | ソースコード、設計書、原価情報、顧客名簿、事業計画、研究データ | × 禁止 (個別承認が必要) | × 禁止 |
| 第三者の秘密情報 | NDAに基づき受領した資料、取引先の非公開情報 | × 禁止 | × 禁止 |
| 認証情報・システム情報 | ID/パスワード、APIキー、秘密鍵、ネットワーク構成、脆弱性情報 | × 禁止 | × 禁止 |
| 未公表の重要情報 | 決算、組織再編、M&A、人事異動 | × 禁止 | × 禁止 |
別表2 承認済み生成AIサービス一覧(記入用)
第5条・第6条で使う台帳です。ここに載っていないサービスは業務利用不可、という運用にします。空欄を埋めるだけで台帳になります。
| No. | サービス名 | 契約形態 | 利用可能部門 | 学習利用 | 保存地域 | 社内データ連携 | 次回見直し |
|---|---|---|---|---|---|---|---|
| 1 | 〔例:ChatGPT Business〕 | 法人契約 | 全社 | なし | 〔 〕 | なし | 〔 〕 |
| 2 | 〔例:Microsoft 365 Copilot〕 | 法人契約 | 〔 〕 | なし | 〔 〕 | あり(SharePoint/OneDrive/Teams) | 〔 〕 |
| 3 | 〔例:Azure OpenAI Service〕 | API | 開発部門 | なし | 〔リージョン〕 | あり(〔 〕) | 〔 〕 |
※ 記入例です。実際の契約条件(特に「学習利用」「保存地域」)は、必ず提供事業者の最新のドキュメントとデータ処理契約(DPA)で確認してから記入してください。
付録 社員向け「5つのルール」(配布用)
規程は読まれません。実際に配るのはこちらです。
生成AIを使うときの5つのルール
- 会社が用意したサービスだけを使う。個人アカウント(無料版を含む)での業務利用は禁止。使いたいものがあれば申請してください
- 入れてはいけない情報がある。お客様の情報・個人情報・ソースコード・取引先から預かった情報・パスワードやAPIキーは入力しない。迷ったら入れずに聞く
- AIの答えは必ず自分で確かめる。数字・法令・日付・社外に出す文章は一次情報で裏を取る。責任を負うのはAIではなく使った人です
- 外から来た文書をAIに読ませるときは要注意。人には見えない形でAIへの命令が仕込まれている攻撃が実在します
- やらかしたら、すぐ言う。報告したことで不利益な扱いはしません。隠されて時間が経つことが、会社にとって最悪の結果です
① 法人プランを最低1つ契約し、全社員が使える状態にする(禁止だけでは必ず個人アカウントに逃げるため、これが最優先)
② 別表1を記入し、全社に掲示する
③ 相談窓口(チャットチャンネル等)を用意して周知する
④ 人事労務部門と第17条(モニタリング)の周知方法を確定する
⑤ 3か月以内に、利用実態の可視化とSharePoint等の過剰共有の棚卸しを行う
ガイドラインの雛形をもっと詳しく
本記事の規程草案は「調査結果を条文化したもの」です。中小企業向けに、より導入手順に寄せたガイドライン雛形(全12条+作り方)を別記事で公開しています。あわせてご覧ください。
企業のAI利用ガイドライン雛形|全12条+作り方 →最終章 おわり — 次はFAQ
よくある質問
社内で実際に出てくる疑問に答えます
結局、クラウド型AIは使っていいのですか?
一般業務(文書作成、要約、翻訳、調査)であれば、法人プランを契約したうえで使うのが最も合理的です。禁止するとシャドーAIに化けて、同じリスクを可視性ゼロで負うことになります。閉域網が必須の部門や、恒常的に営業秘密を扱う部門だけ、ローカルLLMなどの別手段を用意してください。
無料プランでも「学習させない設定」にすれば大丈夫では?
学習利用は止められますが、会社が利用状況を把握できない点は変わりません。また第5章で見たとおり、司法手続きにおける保全命令の対象範囲は「法人契約かどうか」で線引きされた実例があります。設定ではなく契約形態が問題なので、無料プランの業務利用は避けてください。
社員が「うっかり入力してしまった」ときは?
まず叱らないことです。そのうえで、①入力した内容と入力先サービスを特定 ②会話履歴の削除とデータ削除請求の要否を判断 ③個人データが含まれるなら個人情報保護委員会への報告・本人通知の要否を判断 ④第三者の情報なら当該第三者への通知の要否を判断——という順で対応します。草案の第20条がこの手順です。
中小企業でも規程は必要ですか?
必要ですが、22条すべては要りません。最低限、①使ってよいサービスの指定 ②入力禁止情報の一覧 ③困ったときの相談先——の3つを1枚にまとめれば、それで規程として機能します。むしろ大部の規程を作って誰も読まない状態のほうが危険です。
Microsoft 365 Copilotのような「社内データに繋がるAI」は危険ですか?
危険というより、「既存の権限設定の甘さが一気に表面化する」と考えてください。これまで「探しにくいから実質的に見られなかった」情報が、AIによって簡単に検索・要約されるようになります。導入前にSharePointや共有フォルダの共有範囲を棚卸しすることが、最も効果の高い対策です。
AIの出力に他社の機密情報が混ざることはありますか?
法人プランやAPIでは入力が学習に使われないため、他社の入力がそのまま自社の出力に出る可能性は低いと考えられます。ただし、AIが学習した公開情報の中に本来非公開だった情報が含まれていた、という可能性は否定できません。不審な出力を見つけたら、使わずに報告するルールにしておくのが安全です(草案の第18条第3号)。
① 「クラウド型AI」は3種類ある。個人向け/法人/APIで、リスクの性質がまったく違う
② 最大の実害はシャドーAI。社用端末でAIを使う従業員の45%、うち67%が個人アカウント
③ 「学習されない」と「保存されない」は別。保存されている以上、他国の司法手続きの対象になり得る
④ 営業秘密は「漏れる」だけでなく「法的保護を失う」。これが最も重い帰結
⑤ 社員が入力しなくても漏れる経路がある(EchoLeak)。防ぐべきはAIに与えた権限の広さ
⑥ 禁止ではなく「安全な手段を用意したうえで危ない使い方を止める」。これがすべての土台
📋 出典・参考文献(2026年8月6日時点)
- IPA「情報セキュリティ10大脅威 2026」(2026年1月29日公表) — ipa.go.jp
- 総務省・経済産業省「AI事業者ガイドライン(第1.2版)」(2026年3月31日) — meti.go.jp
- 内閣府「人工知能関連技術の研究開発及び活用の推進に関する法律(AI推進法)」 — cao.go.jp
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」(2023年6月2日) — ppc.go.jp
- OWASP「Top 10 for LLM Applications 2025」 — genai.owasp.org
- IBM「Cost of a Data Breach Report 2026」(2026年7月29日発表) — newsroom.ibm.com
- Verizon「2026 Data Breach Investigations Report」 — verizon.com
- CVE-2025-32711(EchoLeak/Microsoft 365 Copilot、CVSS 9.3、2025年6月公表・修正済み) — thehackernews.com
- OpenAI「How we’re responding to The New York Times’ data demands in order to protect user privacy」 — openai.com
- Anthropic「Anthropic achieves ISO 42001 certification for responsible AI」(2025年1月13日) — anthropic.com
- パーソル総合研究所「生成AIとはたらき方に関する実態調査」 — persol-group.co.jp
- PwC Japanグループ「生成AIに関する実態調査 2025春 5カ国比較」 — pwc.com
- トレンドマイクロ「DeepSeekとは?注目される理由と使用前に考慮したいセキュリティリスクを解説」 — trendmicro.com
- STORIA法律事務所「生成AIと秘密情報の入力」 — storialaw.jp
※ 各サービスのプラン名・データ取扱条件は変更されます。導入判断の際は、必ず提供事業者の最新の利用規約・データ処理契約(DPA)をご確認ください。
※ 見直し目安:2027年2月(IPA10大脅威の年次更新、AI事業者ガイドラインの改訂、EU AI Actの適用時期確定に合わせて)




コメント