情報セキュリティと情報漏洩リスク

執筆中です．内容・URLともに変更の可能性があります．

概要

AI利用にあたっては，責任あるAI利用 で述べたような一般的な注意の他に，日々遭遇する実践的な問題として，「非公開の情報などをどこまでAIに入力してよいか」という問題があります．これは情報の内容に加えて，利用方法，サービスの運用形態，クラウドサービスであればそのサービスの契約内容，によっても答えが大きく異なるもので，倫理的，社会規範上の問題よりも，リスクと有用性のバランスをどう取るかという，技術的な性格の強い問題です．そして，（他の問題と同様）明確な線引きは困難であり規則，ガイドラインに従うと曖昧さなく答えが導かれるというものではありません．

本節ではそれを踏まえ

• 入力した情報がどこまで送信され，どこに保存されるかという，リスクを考える上での基本的な見方
• 契約内容，利用方法，実装形態ごとに，それが実際にどうなるか
• 本学における情報の取り扱いの基本原則
• それらを踏まえた，場面ごとに取りうる適切な方法（目安）

について説明します．

簡略版： 詳細・ニュアンスを省略した目安

まずはじめに，良く使うチャットサービス（Google GeminiやMicrosoft Copilot Chat）に文書を読ませてよいか，というよくある問いに対する，大雑把な目安を示します．

機密度	典型例	無料サービス	有償サービス
低	公開済み論文，大学Webサイト，一般的な質問	○	○
中	学内向け会議資料，部局内業務文書，研究メモ草稿	✕	○
高	作成中の入試問題，NDA下で受領した機密情報，特許出願前の発明	✕	後述

ただしこの表はあくまで近似です．「無料サービス」「有償サービス」の区別は本来は意味がなく，本来意味があるのは各サービスのデータ取り扱い規則，プライバシー規約などですが，ここでは詳細を省略します．さしあたり本学で契約している Google Gemini や Microsoft Copilot Chat などを 東大のGoogle アカウント (g.ecc) や UTokyo Account (utac) で利用している場合は上記の表の「有償サービス」にあたると思ってよいです．

また，機密度の区別（低・中・高）自体，厳密な線引きは困難で，本来の決め方は各情報の責任者が決めるというものです（本学における情報の取り扱いの規則を参照）．上記の表はあくまで，本学における標準として共有するものです．

そのうえで，目安は以下の通りです．

• 無料サービスに送ってよいのは公開済みの情報や，組織と無関係な一般的な情報だけです．そもそも無料サービスを仕事で使わなくてはいけない機会が少ないはずなので基本は避けるようにして下さい．
• 有償サービスに送ること自体は，クラウド（Microsoft OneDrive や Google Drive）にアップロードするのと同じようなものと思えば良く，非公開情報を一切送ってはいけないということではありません．中程度までの機密性の情報であれば，会話履歴を間違った設定で共有しない，アカウントをきちんと保護する（多要素認証）などに気をつけ，送ってOKです
• 機密性の高い情報については，リスクと必要性のバランスを正しく理解すること，その情報の保護に責任を持つ人を決めてその人の責任のもとに行うことが重要で，後述します
  • 「AIに情報を送ること」が何を意味するかがわかっていない，という場合は勝手にやらないのが基本です

詳細解説編

日常業務の多くの場面では上掲の表を守ればよいですが，以下では

• 一口に「AIに情報を入力する」といっても様々な意味があり，その情報がどこまでたどり着き，どこに保存されるかが重要であること
• その理解を元にした，形態ごとのリスクの評価
• 本学のセキュリティポリシーと，それに基づいた，入力可否を決める正しいプロセス

について解説し，それらを元にして，高機密情報の入力可否に関する考え方を述べます．

「AIに情報を入力する」と何が起きるか：送信と保存

まず，通常AIと対話している時にどこに何が送られ，保存されているかのイメージ図を示します．

利用者が入力した会話は，ユーザインタフェース（ブラウザで目にしているインタフェース）を担当するサーバに送られます．過去の会話の履歴が保存されているのもこのサーバです．そこから，これまでの会話の履歴（文脈）とともに実際のAIモデルを実行しているサーバに送られます．多くの利用形態では両方のサーバとも，Google, MicrosoftなどのAI事業者の管理するデータセンター内にあります．

このように，「AIに情報を入力する」と言っても，実際に起きることは送信と保存という別々の事柄です．リスクを考えるときは，この2つを分けて問うことが重要です．

• 入力はどこまで「送信」されるか
• 会話履歴（入力と出力）はどこに「保存」されるか

そして，それぞれの答えは次の3つの場所のいずれかになります．

場所	主に考慮すべきリスク
手元のPC	一般的には安全だが，盗難，置き忘れ，ウィルス感染などの可能性がある
自分（や部局）が管理するサーバ	サーバへのアクセスを厳重に管理する必要がある．属人的に長期運用することは避けるのが望ましい
AI事業者のクラウド	事業者のセキュリティ体制，データセンターの所在地（準拠法が異なる場合がある），情報漏洩事故のリスク，行政機関による開示命令への対応ポリシーなどが関わる

どれが一番安全かは一概には言えません．手元のPCに留まっていれば情報漏洩のリスクは低いと言えますが，PCの紛失や盗難という別のリスクを負います．

保存については，場所以前に期間も重要です．

• セッションを越えて一切データを保存しないことで安全性が高まります．
• 保存する場合も「不要になったらすぐに消す」ことが肝心です（例えば試験問題の間違いをチェックさせるなら，一通りの作業を終えた後すぐに消す）．
• 簡単に，確実に消せることも安全性を高める要素です．その意味では会話履歴が手元のPCにしか保存されない形態は安心感が高いでしょう．

さらに，送信先がAI事業者のクラウドである場合に限って，もう一つの問いが加わります．

• 送信した入力が，AIモデルの「学習」に使われるか

一部のクラウド型サービス，特に無料サービスでは，ユーザの入力をAIモデルの学習に使用するという利用規約になっているものが多くあります．このような契約においては，ユーザの入力に含まれる情報がモデルに学習され，結果として他のユーザへの出力に反映される，すなわち間接的に情報が流れることが，原理的にはありえます．

補足：エージェント型AI・ワークスペース統合

ここまでは，利用者が明示的に入力したものが「入力」である，という前提で述べてきました．しかしMicrosoft 365 CopilotやGoogle Gemini for Workspaceのように，メール・カレンダー・ドキュメントなどの業務データに横断的にアクセスするAI機能が普及しています．

このような「エージェント型」のAIでは，ユーザが明示的に入力した情報だけでなく，ワークスペース上に存在するデータが自動的にAIの処理対象となります．つまり「入力」の範囲そのものが暗黙のうちに広がるため，意図せず機微情報がAIに渡るリスクが生じます．送信範囲と保存場所を考える前に，そもそも何が入力になっているのか，なりうるのかを確認する必要があります．

契約内容，利用方法，実装形態による違い

AI（ここではさしあたりChatGPTのような言語やファイルを与えて質問への回答やタスクを実行させるものを考えます）の典型的な契約内容，利用方法，実装形態として以下のような形態があります．以下では各形態について，前節の2つの問い（どこまで送信されるか，どこに保存されるか）の答えを最初に示します．

1. 「入力を学習に使う」とする契約（≒ 無料サービス）
2. 「入力を学習に使わない」としている・またはそうできる契約（≒ 主に有償サービス）
3. 「プライベートモード」（主に有償サービスで可能な利用方法）
4. 「API利用」（プログラムから呼び出す）
5. 「UI部分のセルフホスト」（UI部分を自分で管理する計算機上で動かす）
6. 「モデルのセルフホスト」（AIモデル自身を自分で管理するサーバ上で動かす）
7. 「ローカルLLM」（モデルまで自分のラップトップなどで動かす）

1. 「入力を学習に使う」とする契約（≒ 無料サービス）

送信：AI事業者のクラウド　／　保存：AI事業者のクラウド　／　学習利用：される

多くの無料サービスが該当し，あるユーザの入力がモデルの学習を通じて他のユーザへ間接的に流れることがあり得ます．例えて言うならばこのリスクは，ファイルを誰でも見られる場所に公開するのと同じで，公開可能な情報以外の入力は避けるべきです．

本学ではCopilot, Geminiの組織契約をしており，あえて無料サービスを使わないといけない状況は多くはありませんので，基本は避けて下さい．あえて活用する場面は，色々なサービスの色々なモデルを無料で試したい場合でしょう．

2. 「入力を学習に使わない」としている・またはそうできる契約（≒ 主に有償サービス）

送信：AI事業者のクラウド　／　保存：AI事業者のクラウド　／　学習利用：されない

多くのクラウド型有料サービスでは，利用規約中に，データを学習利用しない こと，より広くデータ保護方針，プライバシー方針（データが他のユーザに漏れないことなど）が明記されています．本来はその方針をきちんと読んで確認すべき事項ではありますが，基本的にはそのような契約の場合，入力した内容が直接あるいは間接（AIモデルの学習を通じて）他のユーザに流れるようなことはありません．詳しくは以下をご覧下さい．

• Microsoft Copilot Chat
• Google Gemini

例えて言うならばこのリスクは，クラウド上にファイルを置くときのリスクと似ています．つまり，デフォルトの状態ではAIへの入力はあなたにしか見られず，漏洩することはありません．あなたが間違って意図しない人と共有して漏洩させるとか，あなたのアカウントが侵入を受ける，サービス自身が侵入を受けたり情報を漏洩させる，などが考慮すべきリスクになります．

残るリスクは，会話履歴が事業者のクラウドに長期にわたって保存される点にあります．過去の会話履歴は同一ユーザとの将来の会話に反映されることがあり，その会話の内容をユーザの不注意によって漏洩させれば（意図しない範囲の人と共有する，Zoomの画面に出すなど），情報が漏洩することがありえます．

ブラウザ経由で利用するようなAIを契約した場合がこれにあたり，本学でのAI利用もこのパターンが多いと思われます．サービスにアクセスするためのアカウントをしっかりと守る，会話の内容を共有する際に間違いがないか，などに気をつけて下さい．

3. 「プライベートモード」（主に有償サービスで可能な利用方法）

送信：AI事業者のクラウド　／　保存：長期には保存されない　／　学習利用：されない

一部の有償サービスでは，会話履歴の保存を無効にする「プライベートモード」（または「履歴をオフにする」設定）が提供されています．このモードでは，会話終了後に入力・出力が保存されないとされており，履歴が他の会話に反映されたり，サーバに長期間残ったりするリスクをなくせます．良い例えが浮かびませんが，このリスクは，ファイルをクラウドにアップロードしてすぐに消す，というようなものに近いです．

つまり前節の2つの問いのうち，保存の問題は解消するが，送信の問題は残るというのがこの形態の位置づけです．データが自ら管理する区域を出てはいけない，大学を出てはいけない，国境を出てはいけない，などの守るべき方針があればそれに照らして利用可否を判断すべきものです．

なお履歴が残らないということは，後からその会話を見返したり，検索したりすることもできないということです（プライベートモード）．

4. 「API利用」（プログラムから呼び出す）

送信：AI事業者のクラウド　／　保存：APIを呼び出すプログラムが動いている場所（手元のPC，または自分が管理するサーバ）　／　学習利用：されない

OpenAI API, Anthropic APIなど，プログラムから呼び出す形態です．多くのAPI利用規約では，デフォルトで入力データを学習に使用しないことが明記されています（サービスにより異なるため確認が必要）．

この形態の要点は，会話履歴を事業者側が持たないことです．会話履歴はAIを呼び出すプログラムが管理して毎回サーバに送信することが想定されていることがほとんどであり，サーバは，少なくとも長期的には保存していないと考えられます（それを実際に検証するのは困難ですが）．したがって履歴の保存場所は，そのプログラムをどこで動かすかによって決まります．手元のPCで動かすなら手元のPCに，自分が管理するサーバで動かすならそのサーバに保存されます．

ただしデータがサーバに送信されることは変わらないため，機密性の高い情報の扱いには引き続き注意が必要です．研究グループで開発したシステムにAPIを組み込む場合は，そのシステムの利用者がどのような情報を入力しうるかも考慮した設計が求められます．

APIは通常の（ブラウザ経由で使うサービスのサブスクリプションの）有償契約には含まれておらず別途契約する必要があることが多いです．本学ではOpenAI社のモデル中心ですが，UTokyo Azure経由で各種AIモデルのAPIを利用可能です．

5. 「UI部分のセルフホスト」（UI部分を自分で管理する計算機上で動かす）

送信：AI事業者のクラウド　／　保存：UIを動かしている場所（自分が管理するサーバ，または手元のPC）　／　学習利用：されない

送信・保存の観点では，この形態は前項のAPI利用と同じです．違うのは，プログラムを自分で書く代わりに，会話を入力する画面とその履歴の管理を担うUIソフトウェアを自分で動かす，という点です．履歴は自分の管理下に置かれ，AI事業者のサーバに蓄積されることはなくなります．一方でAIモデル自体は事業者のものを利用するため，個々の質問とそれまでの文脈は，都度APIを通じて事業者のサーバに送信されます．

「UIをセルフホストする」と言っても，それをどこで動かすかで保存場所もリスクも変わります．

5a. サーバで動かす場合

本学ではmdxやUTokyo Azureに仮想マシンを起動し，そこにUIソフトウェア（Open WebUI など）を導入することで利用可能です．履歴はそのサーバに保存されるので，サーバの管理が重要になります．セキュリティアップデート対応などの運用コストは発生しますし，長期運用するのであればそれがおろそかになって侵入リスクが増加する可能性もあります．属人的な運用にならないようにすることが重要です．いい加減な運用をするくらいならAIサービスをそのまま使うほうが安全ということもあるでしょう．目的限定で短期間運用するようなケースは実践的と言えるでしょう．

5b. 手元のPCで動かす場合

同じUIソフトウェアを自分のラップトップで動かすこともできます．このために強力なGPUなどは不要です．履歴は手元のPCの中だけに保存されるので，サーバを運用する手間はかかりませんが，PCの紛失・盗難がそのまま履歴の漏洩につながります．

またこのパターンでよく使われるソフトとしては，Claude Code, Codex CLI, Open Code のようなコーディング用AI用の UI があります．

6. 「モデルのセルフホスト」（AIモデル自身を自分で管理するサーバ上で動かす）

送信：自分が管理するサーバ　／　保存：自分が管理するサーバ　／　学習利用：該当しない

公開されているモデルを自分で管理しているサーバに展開する形態です．これによって，入力が送信される範囲も自分の管理下に収まります．入力データがサービス事業者に送信されることはなく，情報の流れや保存場所を明確に制御できます．そのため，機微情報・非公開研究データを扱う場合のリスクを管理，明確化しやすいです．

本学ではmdxやUTokyo AzureにGPUを備えた仮想マシンを起動し，そこにモデルを導入することで利用可能です．

7. 「ローカルLLM」（モデルまで自分のラップトップなどで動かす）

送信：手元のPC　／　保存：手元のPC　／　学習利用：該当しない

手元のPC・ノートPCでモデルを実行する形態です．入力・出力がすべてローカルで完結し，ネットワーク経由で外部に情報が送出されることはありません．情報漏洩リスクという観点では最も安全な形態です．ただし，利用できるモデルのサイズ・性能はハードウェアに依存し（特にメモリ容量），大規模モデルを高品質に動かすためには相応のスペックが必要です．

形態ごとの送信範囲と保存場所（一覧）

形態	入力の送信範囲	会話履歴の保存場所	学習利用
1. 無料サービス	AI事業者のクラウド	AI事業者のクラウド	される
2. 有償サービス	AI事業者のクラウド	AI事業者のクラウド	されない
3. プライベートモード	AI事業者のクラウド	長期には保存されない	されない
4. API利用（手元のPCから）	AI事業者のクラウド	手元のPC	されない
4. API利用（自分のサーバから）	AI事業者のクラウド	自分が管理するサーバ	されない
5a. UIセルフホスト（サーバ）	AI事業者のクラウド	自分が管理するサーバ	されない
5b. UIセルフホスト（手元のPC）	AI事業者のクラウド	手元のPC	されない
6. モデルセルフホスト	自分が管理するサーバ	自分が管理するサーバ	該当しない
7. ローカルLLM	手元のPC	手元のPC	該当しない

4と5は送信範囲も保存場所も同じで，違いはプログラムから使うか，ブラウザのUIから使うかという使い勝手の差です．また4と5は，動かす場所によって保存場所が変わります．

条件に応じた形態

守りたい条件が決まっていれば，上の表から可能な利用形態を導くことができます．

• 手元のPCからデータを一切出したくない → 7（ローカルLLM）
• 自分（や部局）が管理する範囲から出したくない → 6（モデルのセルフホスト）．サーバのセキュリティを確保できること，属人的な長期運用にならないことが前提
• 事業者に送るのは許容するが，履歴を事業者側に残したくない → 3（プライベートモード），4（API利用），5（UIのセルフホスト）
• 事業者に送るのは許容する，履歴は自分のPCの外に残したくない → 同上，ただしAPIを発行するプログラムやUIを自分のPCで動かす

選択にあたっての実務的な注意

• 仕事のためにAIを使う場合，「入力を学習に使う」とする契約（≒ 無料サービス）をあえて使う場面は，ほとんどありません．

• 多くの場合，「入力を学習に使わない」としている・またはできる契約（≒ 主に有償サービス）は機能性（データの読み取り，画像などの各種メディア処理），モデル性能（高度な推論機能），高速性を兼ね備えていますので，使い勝手を重んじる際には良い選択肢となります．大学で契約している Google Gemini, Microsoft Copilot Chat などがこれに相当します．

• 「プライベートモード」を用いれば，情報保持はそのセッション内に限られるため，情報漏洩リスクはかなり軽減されます．会話履歴がその場で消えてよければ手軽かつ安全性の高い方法と言えます．

• モデルのセルフホストやローカルLLMはデータの送信範囲を制限できる安全性の高い方法ですが，使えるAIモデルが公開（オープンウェイト（†））のものに限定される，使える計算機の性能によっても制限される（特にローカルLLMは自分のラップトップの性能に制限される），という制限があります．機密性が非常に高い情報に対して，比較的定型的な処理（翻訳）を行う場合に適していると言えるでしょう．

• API利用やUIのセルフホストでは，履歴が保存される範囲を制限したうえで，使えるモデルを柔軟に選べるため，機密性の高い情報を先端的なモデルに与えたい場合（事業者への送信自体は許容できる場合）の良い方法になります．ただし有償サービスには，事業者独自のシステムプロンプト（※）や，ウェブ検索・ファイルの解析・コード実行といったツールの組み込み，裏側での多段処理など，回答の質を上げるための作り込みがあり，それらは自分で用意する必要があるため，同等の使い勝手を得るには手間がかかります．

（†）オープンウェイト: AIの学習結果を公開しており，ダウンロードすれば任意の計算機で動かせるようなAIモデル．多くのクラウド型AIベンダーの主要モデルはオープンウェイトではない．

（※）システムプロンプト： AIの回答の傾向を制御する全体的な指示．

本学における情報の取り扱いの規則

以上，AIの実装形態によって情報漏洩リスクの違いがあることを理解したところで，ある情報を生成AIに入力してよいか否かを決める手順について述べます．

重要なことは，

• 情報の取り扱い（誰にこの情報を渡してよいか）に関する原則について正しく理解すること

• その上で，AIの実装形態によるリスクと必要性のトレードオフを適切に判断すること

です．短い言葉で表現できる絶対の公式はありません．

本学の「情報セキュリティポリシー・情報分類・管理編」では情報管理の一般的な枠組みを定めています．そこでは

• それぞれの情報について「情報責任者」を定める

• 情報責任者が「情報の分類及び管理」を行う

こととされています．情報の分類には，機密性，完全性，可用性がありますが，ここで生成AIに入力してよいかどうかを決めるのは機密性です．同文書では機密性の分類として機密性1, 2, 3という3つのレベルを定めていますが，レベルよりも大事なことは「この情報を共有して良い範囲」を明示することです（会議参加者限り，部局執行部限り，教職員限り，など）．生成AIに入力してよいかどうかもその一部であると考えるべきものです．

ポリシーで定めていることは「その情報をAIに入力してよいか，をきちんとその情報の責任者が決めて下さい」ということです．では責任者とは誰でしょうか? 特に断りがなければその情報の作成者とされていますが，引き継ぐこともできますし，組織内の仕事で作る場合は当該者間で協議の上，情報責任者を定めることもできます．

以上から導かれる，機密性の高い情報のAIへの入力可否を決める正しい考え方は以下のとおりです．

• 情報の責任者をはっきりさせる
• 情報の責任者がその情報をどの範囲（AIであればどのAIサービス）に送信許可するかを決める
• その際，必要性と，ここで述べたリスクとの兼ね合いを考慮して，どのAIになら送信許可するかを決める（「AIに入力可・不可」という二択ではないことに注意）
• その際，リスクの評価が難しいようであれば，正しく評価できる人，所属部局のCISO，全学のCISOなどに相談する

まとめ

上述の通り，ある情報をどのような形態のAIに入力してよいかは，リスクと必要性のバランスを考慮して情報責任者（もしくは組織）が定めるべきものですが，ここでは実践的アドバイスとして情報の性質に応じて，多くの場合許容されると考えられる範囲を示します．

機密度	典型例	無料サービス¹	有償サービス¹	プライベートモード	API利用	UIセルフホスト	モデルセルフホスト	ローカルLLM
低	公開済み論文，大学Webサイト，一般的な質問	○	○	○	○	○	○	○
中	学内向け会議資料，部局内業務文書，研究メモ草稿	✕	○	○	○	○	○	○
高	作成中の入試問題，NDA下で受領した機密情報，特許出願前の発明	✕	△²	※	※	※	※	※

• 凡例：○ 多くの場合許容される　／　△ 内容，必要性など場合による　／　✕ 原則として避けるべき
• ¹ 本来は「無料サービス」「有償サービス」という線引きに意味はなく，サービスのデータ保護契約（データ利用規約，プライバシー方針）に基づいて決めるべきものですが，わかりやすさを優先したこと，および世の中の有償サービスは多くの場合，常識的なデータ保護規則（自分の入力が直接，またはモデルの学習を通じて漏洩することはない）を持っていることから，このような書き方をしています
• ² 履歴が長期保存されるため，上記「会話履歴の保存」で述べたリスクを防ぐため，原則は避けるべき．

※ これらについては，実装形態・管理形態のバリエーションが大きく，○✕△で断定することが適切ではありません．機密性の高い情報については，まず「その情報をどこまで送信してよいか」「履歴をどこに，どれだけの期間保存してよいか」を情報責任者が定め，そのうえで「形態ごとの送信範囲と保存場所（一覧）」と「条件に応じた形態」を参照して形態を選んでください．同じ「UIセルフホスト」でもサーバで動かすか手元のPCで動かすかで保存場所が変わるように，形態の名前だけでは決まらないことにご注意ください．

個人情報（氏名・メールアドレス・成績・健康情報等）は上記の機密度とは別に，個人情報保護法上の制約があるため注意が必要です．連絡先程度であれば機密度としては「中」相当ですが，可能な範囲で個人情報を削除して入力することが推奨されます．成績・健康情報・評価などに関わる個人情報は機密度「高」に準じて扱ってください．

判断に迷う場合は当該情報の情報責任者，部局CISO，本学CISOにご相談ください．

関連ページ

プライベートモード