GPTは業務で使っても大丈夫？：GPTなどの汎用AIのデータの流れとセキュリティリスクを解説

汎用AIサービスの基本アーキテクチャ

汎用AIサービス（ChatGPT、Claude、Geminiなど）は、基本的にクラウドベースのアーキテクチャで動作します。ユーザーの入力データは必ずインターネットを経由してサービス提供者のサーバーに送信され、そこで処理されます。

基本的なデータフロー

1. ユーザーがテキストを入力
2. データがHTTPS通信で暗号化されサービス提供者のサーバーへ送信
3. サーバー上のAIモデルがデータを処理
4. 生成された応答がユーザーに返却
5. 入力データと応答データがサーバー上に記録

この一連の流れの中で、ユーザーのデータは常にサービス提供者の管理下に置かれます。

チャットアプリ利用時のデータフロー詳細

ChatGPT、Claude、Geminiなどをブラウザやアプリで直接利用する場合のデータフローを詳しく見ていきます。

データ送信のシーケンス

ステップ1：ユーザー入力

• ユーザーがブラウザまたはアプリでメッセージを入力
• 入力内容は一時的にブラウザのメモリに保存

ステップ2：データ送信

• 送信ボタンをクリックすると、HTTPS（TLS 1.3）で暗号化
• OpenAI、Anthropic、Googleのサーバーへデータ送信
• 送信先はアメリカまたはサービス提供者が選択したリージョン

ステップ3：サーバー側処理

• サーバー側でデータを受信・復号化
• ユーザーの過去の会話履歴と組み合わせて処理
• AIモデルが応答を生成
• 入力データと応答データをログとして保存

ステップ4：応答返却

• 生成された応答をHTTPSで暗号化して返却
• ブラウザで表示
• 会話履歴として保存

ステップ5：データ保存

• 会話内容はサービス提供者のデータベースに保存
• 保存期間はサービスの利用規約に依存
• データはサービス改善や監視目的で利用される可能性

各サービスのデータ保存ポリシー

ChatGPT（OpenAI）

• デフォルトでは会話履歴を30日間保存
• 履歴をオフにした場合も30日間は不正利用監視のため保存
• API利用時は30日後に自動削除（ゼロデータリテンション設定可能）
• エンタープライズプランでは独自のデータ保持ポリシー設定可能

Claude（Anthropic）

• 会話履歴は保存されるがモデル訓練には使用しないと明言
• API利用時は明示的に削除しない限り保存
• エンタープライズプランでは独自の保持期間設定可能

Gemini（Google）

• 会話履歴を保存しサービス改善に利用
• Google Workspace連携時は組織のデータポリシーに従う
• 保存期間は最長18ヶ月

API経由でソフトウェアに組み込んだ場合のデータフロー

自社開発のアプリケーションにOpenAI API、Anthropic API、Google AI APIを組み込んだ場合、データフローはより複雑になります。

API統合時のアーキテクチャ

標準的な統合パターン

1. ユーザー → 自社アプリケーション
   • ユーザーが自社アプリで入力
   • 自社サーバーまたはクライアントアプリで受信
2. 自社アプリケーション → API呼び出し
   • 自社アプリケーションが入力データを整形
   • APIキーを付与してHTTPSリクエスト送信
   • OpenAI/Anthropic/Google APIエンドポイントへ送信
3. API処理
   • サービス提供者のサーバーでデータ受信
   • モデルが推論を実行
   • ログとして記録（期間はサービスにより異なる）
4. レスポンス返却
   • 生成結果を自社アプリケーションへ返却
   • 自社アプリケーションでレスポンスを加工・表示
5. 自社でのデータ保存
   • 入力と出力を自社データベースに保存（任意）
   • 監査ログとして記録（任意）

API利用時のデータ保持期間

OpenAI API

• デフォルト：30日間保存後削除
• ゼロデータリテンション：即時削除（エンタープライズプランで利用可能）
• 不正利用監視のため一部データは30日間保持される可能性

Anthropic API

• 明示的に短期間のキャッシュのみと説明
• モデル訓練には使用しない
• 具体的な保存期間は公開されていない

Google AI API

• データ保存期間はサービスレベルにより異なる
• Vertex AI使用時は顧客データとして扱われ保存期間を制御可能

API統合のセキュリティリスク

1. APIキーの漏洩リスク

• APIキーがハードコードされるリスク
• GitHub等へのコミットによる露出
• クライアントサイドでの露出

2. データ傍受リスク

• 通信経路上での傍受（HTTPS必須）
• プロキシ経由での内容確認

3. データ保存リスク

• サービス提供者のサーバーに一定期間保存
• データ削除のタイミングが不透明
• 法的要請による開示の可能性

サプライチェーンセキュリティ評価制度における外部サービス連携

2026年4月から施行される経済産業省のサプライチェーンセキュリティ評価制度では、外部サービスとの連携に関する評価項目が設けられています。

第15条：外部サービスの利用管理

評価基準の概要

サプライチェーンセキュリティ評価制度の第15条では、以下の点が評価されます：

1. 外部サービスの選定基準
   • セキュリティ要件の明確化
   • サービス提供者の信頼性評価
   • データ保存場所と管理体制の確認
2. 契約内容の適切性
   • データ保持期間の明記
   • データ削除手続きの確認
   • インシデント時の責任範囲
   • データの第三者提供に関する制限
3. 技術的対策
   • 通信の暗号化
   • アクセス制御の実装
   • ログ管理と監視
4. データ分類と取扱い
   • 機密度に応じた外部サービスの選定
   • 機密情報を外部サービスに送信しない仕組み
   • データマスキングや匿名化の実施

汎用AIサービスへの適用

ChatGPTなどの汎用AIサービスを業務で利用する場合、以下の点が評価対象となります：

評価項目1：データの保存場所

• サービス提供者のデータセンターの所在地
• データ処理が行われる国・地域
• 日本の法律が適用されるか

評価基準：

• A評価：国内データセンターで処理・保存
• B評価：信頼できる国でのデータ処理（米国、EU等）
• C評価：データ処理場所が不明確

評価項目2：データ保持期間

• 入力データの保存期間
• 削除手続きの明確性
• 完全削除の保証

評価基準：

• A評価：即時削除または30日以内の削除保証
• B評価：90日以内の削除
• C評価：削除期間が不明確または長期保存

評価項目3：データ利用目的

• モデル訓練への利用有無
• サービス改善目的での利用範囲
• 第三者への提供有無

評価基準：

• A評価：モデル訓練に使用しない明言あり
• B評価：限定的な利用のみ
• C評価：広範な利用が規約に明記

評価項目4：アクセス制御

• APIキーの管理方法
• 多要素認証の実装
• アクセスログの記録

評価制度への対応方法

対応レベル1：基本的な対策

• 利用規約の精査と理解
• 機密情報を入力しないルールの策定
• 従業員への教育実施

対応レベル2：技術的対策

• プロキシ経由でのアクセス制御
• 入力内容の自動フィルタリング
• 利用ログの記録と監視

対応レベル3：ハイブリッド構成

• 機密情報はローカルLLMで処理
• 一般情報のみクラウドAI利用
• 情報分類の自動化

業務利用におけるセキュリティリスク

汎用AIサービスを業務で利用する際の具体的なリスクを整理します。

リスク1：機密情報の漏洩

発生シナリオ

• 従業員が顧客情報をChatGPTに入力して要約作成
• 社内の機密プロジェクト資料を貼り付けて分析依頼
• ソースコードを貼り付けてバグ修正を依頼

リスクの詳細

• 入力した情報がサービス提供者のサーバーに保存
• サービス障害時にデータが漏洩する可能性
• 法的要請により第三者に開示される可能性
• 従業員が誤って機密情報を共有する設定にしてしまう

影響度

• 高：顧客情報、営業秘密、個人情報の場合
• 中：社内限定情報、プロジェクト情報の場合
• 低：公開情報、一般的な業務情報の場合

リスク2：データ残留リスク

発生シナリオ

• 一度入力したデータは完全に削除できない
• 会話履歴を削除してもバックアップに残る可能性
• サービス提供者のログに長期間保存

リスクの詳細

• データ削除の確証が得られない
• サービス終了時のデータ取扱いが不明
• バックアップからのデータ復元リスク

影響度

• 高：GDPR、個人情報保護法の対象データ
• 中：企業機密情報
• 低：公開可能な情報

リスク3：コンプライアンス違反

発生シナリオ

• 個人情報保護法違反（第三者提供の同意なし）
• 秘密保持契約違反（顧客情報の外部送信）
• 輸出管理規制違反（技術情報の国外送信）

リスクの詳細

• 顧客との契約で禁止されている可能性
• 業界規制により外部サービス利用が制限される場合
• データの国外移転が問題となる場合

影響度

• 高：法令違反、契約違反の場合
• 中：社内ポリシー違反の場合
• 低：明確な違反がない場合

リスク4：サービス依存リスク

発生シナリオ

• サービスの突然の仕様変更
• 価格改定により継続利用が困難
• サービス停止や終了

リスクの詳細

• 業務プロセスがサービスに依存
• データのエクスポートが困難
• 代替サービスへの移行コスト

リスク5：モデルの不確実性

発生シナリオ

• 生成された内容が誤っている（ハルシネーション）
• 不適切な内容が生成される
• 一貫性のない応答

リスクの詳細

• 誤った情報に基づく業務判断
• 顧客への誤情報提供
• ブランドイメージの毀損

ローカルLLMとのハイブリッド構成による安全な活用

機密情報漏洩リスクを最小化しながらAIの利便性を享受するには、ローカルLLMと汎用AIサービスのハイブリッド構成が有効です。

ハイブリッド構成の基本概念

データの機密度に応じた使い分け

情報を機密度で分類し、適切なAIサービスを選択します：

機密度レベル1：公開情報

• 内容：一般公開されている情報、マーケティング資料
• 利用AI：ChatGPT、Claude、Gemini等の汎用AIサービス
• 理由：情報漏洩のリスクが低い

機密度レベル2：社内限定情報

• 内容：社内マニュアル、一般的な業務文書
• 利用AI：条件付きで汎用AIサービス、またはローカルLLM
• 理由：マスキング処理により利用可能

機密度レベル3：機密情報

• 内容：顧客情報、契約書、財務情報
• 利用AI：ローカルLLMのみ
• 理由：外部送信は絶対に避けるべき

機密度レベル4：極秘情報

• 内容：営業秘密、未発表の新製品情報
• 利用AI：ローカルLLMのみ（ログも最小限）
• 理由：最高レベルのセキュリティ必要

ハイブリッド構成のアーキテクチャパターン

パターン1：ゲートウェイ型

社内にAIゲートウェイを設置し、リクエスト内容を自動判定して適切なAIサービスにルーティングします。

ユーザー
  ↓
AIゲートウェイ（社内）
  ├→ 機密情報検出 → ローカルLLM（社内）
  └→ 一般情報 → 汎用AIサービス（クラウド）

仕組み

1. ユーザーが統一インターフェースで入力
2. ゲートウェイが入力内容を分析
3. 個人情報、機密キーワードを検出
4. 検出された場合はローカルLLMへルーティング
5. 検出されない場合は汎用AIサービスへルーティング

メリット

• ユーザーは使い分けを意識する必要がない
• 自動的にセキュリティポリシーを適用
• 一元的なログ管理

デメリット

• ゲートウェイの開発・運用コスト
• 誤検出のリスク
• 処理の遅延

パターン2：マルチインターフェース型

用途に応じて異なるインターフェースを提供します。

一般業務用チャット → 汎用AIサービス
機密業務用チャット → ローカルLLM
API統合 → 開発者が選択

仕組み

1. 一般業務用と機密業務用の2つのインターフェースを用意
2. ユーザーが用途に応じて選択
3. それぞれ異なるバックエンドに接続

メリット

• シンプルな実装
• ユーザーの意識的な選択によりセキュリティ向上
• 低コスト

デメリット

• ユーザーの判断に依存
• 誤った選択のリスク
• ユーザー教育が必要

パターン3：RAG型ハイブリッド

RAG（Retrieval Augmented Generation）を活用し、社内データはローカルで検索、推論のみ汎用AIを利用します。

ユーザー
  ↓
社内RAGシステム
  ├→ 社内DB検索（ローカル）
  ↓
検索結果 + 質問
  ↓
汎用AIサービス（推論のみ）

仕組み

1. ユーザーの質問を受付
2. 社内データベースから関連情報を検索（ローカル処理）
3. 検索結果を要約・匿名化
4. 匿名化したデータと質問を汎用AIに送信
5. 汎用AIが推論を実行
6. 結果を社内情報と組み合わせて提示

メリット

• 社内データは外部送信しない
• 汎用AIの高度な推論能力を活用
• コストバランスが良い

デメリット

• RAGシステムの構築が必要
• 匿名化処理の品質に依存
• 推論精度が下がる可能性

実装例：情報分類の自動化

機密情報検出の実装

ゲートウェイ型を実装する場合の機密情報検出ロジックの例：

検出対象

• 個人情報：メールアドレス、電話番号、住所のパターン
• 企業機密：「社外秘」「機密」「confidential」などのキーワード
• 技術情報：ソースコード、API キー、パスワードのパターン
• 契約情報：契約書番号、取引先コードのパターン

検出方法

1. 正規表現によるパターンマッチング
2. キーワード辞書によるチェック
3. 機械学習による分類（文書分類モデル）
4. 名前付きエンティティ認識（NER）による個人情報検出

判定ロジック

IF 個人情報検出 OR 機密キーワード検出 OR 技術情報検出 THEN
  → ローカルLLMへルーティング
ELSE
  → 汎用AIサービスへルーティング
END IF

誤検出への対応

• ホワイトリスト方式：安全と判断された表現は除外
• ユーザーによるオーバーライド：確認の上、利用を許可
• ログ記録：判定結果を記録し定期的に見直し

運用上の考慮事項

1. ユーザー教育

ハイブリッド構成を効果的に運用するには、ユーザー教育が不可欠です：

• 機密情報の定義と分類基準の明確化
• 各AIサービスの特性と使い分けルール
• 誤って機密情報を入力した場合の対処方法
• 定期的なセキュリティ研修の実施

2. ポリシーの策定

明確な利用ポリシーを策定します：

• 禁止事項の明確化（個人情報、営業秘密の入力禁止等）
• 利用可能な情報の範囲
• 違反時の対処方法
• 定期的なポリシー見直し

3. ログ管理と監査

利用状況を適切に管理します：

• すべてのAI利用をログに記録
• 定期的な監査の実施
• 異常な利用パターンの検出
• インシデント発生時の追跡可能性確保

4. 継続的な改善

運用しながら改善を続けます：

• 誤検出・検出漏れの分析
• ユーザーフィードバックの収集
• 検出ルールの改善
• 新しいリスクへの対応

ローカルLLM導入のメリット

ハイブリッド構成の中核となるローカルLLMには、以下のメリットがあります。

セキュリティ面のメリット

1. データの外部流出ゼロ

• すべての処理が社内で完結
• インターネット接続不要での運用可能
• データが社外に出ることがない

2. 完全なデータコントロール

• データの保存期間を自由に設定
• 削除の完全性を保証
• ログの管理を完全にコントロール

3. コンプライアンス対応

• 個人情報保護法への確実な対応
• 秘密保持契約違反のリスクゼロ
• 業界規制への適合が容易

4. サプライチェーンセキュリティ評価制度への対応

• 外部サービス連携の評価項目で高評価
• データの国外移転問題の回避
• 独自のセキュリティ要件を実装可能

運用面のメリット

1. カスタマイズ性

• 業界特化型のモデル調整が可能
• 社内用語や専門用語への対応
• ファインチューニングによる精度向上

2. コスト予測可能性

• 従量課金ではなく固定費
• 使用量が増えてもコスト増なし
• 長期的にはコスト削減

3. サービス依存性の排除

• サービス停止の影響を受けない
• 価格改定の影響を受けない
• 永続的な利用が可能

4. レスポンス速度

• ネットワーク遅延がない
• 社内ネットワークの速度で動作
• バッチ処理にも適している

実践的な導入ステップ

ハイブリッド構成を実際に導入する際のステップを示します。

フェーズ1：現状分析と計画

1. 業務の棚卸し

• AI活用が有効な業務を特定
• 各業務で扱う情報の機密度を評価
• 現在のAI利用状況を把握

2. セキュリティ要件の定義

• 企業のセキュリティポリシー確認
• コンプライアンス要件の整理
• サプライチェーンセキュリティ評価制度への対応方針決定

3. アーキテクチャの選定

• ゲートウェイ型、マルチインターフェース型、RAG型から選択
• 予算と要件のバランスを考慮
• 段階的な導入計画の策定

フェーズ2：ローカルLLM環境の構築

1. ハードウェアの準備

• GPU搭載サーバーまたはワークステーション
• 必要なスペックの見積もり
• オンプレミスまたはプライベートクラウドの選択

2. ソフトウェアの選定

• Llama、Mistral、日本語特化モデル等から選択
• 推論フレームワークの選定（vLLM、TGI等）
• 管理ツールの選定

3. 初期設定とテスト

• モデルのデプロイ
• パフォーマンステスト
• 精度評価

フェーズ3：ゲートウェイの実装

1. 機密情報検出機能

• 正規表現ルールの実装
• キーワード辞書の整備
• 検出精度のテスト

2. ルーティング機能

• ローカルLLMとの接続実装
• 汎用AIサービスとの接続実装
• 負荷分散の実装

3. ログ管理機能

• すべてのリクエスト/レスポンスを記録
• ルーティング判定結果を記録
• 監査用レポート機能

フェーズ4：ユーザーインターフェースの整備

1. Webインターフェース

• チャットUIの実装
• ユーザー認証の実装
• 使いやすさの追求

2. API提供

• 社内アプリケーションからの呼び出し用API
• APIドキュメントの整備
• SDKの提供

フェーズ5：試験運用と改善

1. パイロット運用

• 限定的なユーザーで試験運用
• フィードバック収集
• 問題点の洗い出し

2. 改善と調整

• 検出精度の向上
• パフォーマンスチューニング
• ユーザーインターフェースの改善

3. 本格展開

• 全社展開
• 継続的なモニタリング
• 定期的な見直し

まとめ：安全なAI活用のために

ChatGPTなどの汎用AIサービスは強力なツールですが、業務利用には慎重な検討が必要です。

重要なポイント

1. データは必ず外部サーバーに送信される

チャットアプリでもAPI統合でも、汎用AIサービスを利用する限り、入力データは必ずサービス提供者のサーバーに送信され、一定期間保存されます。

2. 機密情報は絶対に入力しない

個人情報、顧客情報、営業秘密など、外部に漏れてはいけない情報は、汎用AIサービスに入力してはいけません。

3. サプライチェーンセキュリティ評価制度への対応が必要

2026年4月から施行される評価制度では、外部サービス利用が評価対象となります。適切な対策を講じる必要があります。

4. ハイブリッド構成が理想的な解決策

機密情報はローカルLLMで処理し、一般情報のみ汎用AIサービスを利用するハイブリッド構成により、セキュリティと利便性を両立できます。

5. 継続的な改善が重要

技術の進化やリスクの変化に応じて、継続的にセキュリティ対策を見直し、改善していく必要があります。