はじめに
前編では、ChatGPTグループチャットのセキュリティ特性を評価し、実務的な利用判断基準を整理しました。
参考：Group chats in ChatGPT（公式発表）
後編では、より技術的な観点から以下を深掘りします：
- 通信層の暗号化（TLS 1.2/1.3の詳細）
- 保存時の暗号化（Envelope Encryptionの仕組み）
- 鍵管理（サーバサイド vs BYOK）
- 他サービスとの技術比較
- 今後の技術トレンド
前編を未読の方がおられましたら...
まず[前編]で、利用判断に必要な情報を確認することをお勧めします。
1. 通信の暗号化：TLS 1.2以上
1.1 公式の記載内容
OpenAIは複数のドキュメントで以下を明記しています：
"Data in transit is protected using TLS 1.2 or higher"
出典：
1.2 推定される構成
Cipher Suiteの詳細は非公開ですが、現代のクラウドサービスとして以下のような構成が想定されます：
| 要素 | 想定される実装 |
|---|---|
| プロトコル | TLS 1.2 / TLS 1.3 |
| 鍵交換 | ECDHE (X25519, P-256, P-384) |
| 共通鍵暗号 | AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305 |
| 署名アルゴリズム | RSA-PSS, ECDSA (P-256, P-384) |
TLS 1.3の利点（採用している場合）：
- 1-RTTハンドシェイク（高速化）
- 0-RTT再開（さらなる高速化）
- 前方秘匿性(Forward Secrecy)の強化
- 脆弱な暗号スイートの排除
1.3 TLS終端点の重要性
TLSは以下の区間で終端されます：
クライアント ←[TLS終端]→ OpenAI Gateway ←[別TLS]→ Backend
つまり、OpenAIのサーバ側ではTLS終端後の平文を扱っていることになります。これは：
- モデル推論の実行
- 監査ログの記録
- コンプライアンスチェック
といった処理のために必要な設計です。
2. 保存時の暗号化：AES-256 + Envelope Encryption
2.1 基本構成
OpenAIは全プラン共通で以下を実装しています：
"Data at rest is encrypted using AES-256"
出典：
2.2 Envelope Encryptionの詳細
一般的なクラウドサービスと同様に、以下のような二層暗号化が行われていると推測されます：
┌────────────────────────────────────────┐
│ 平文データ（会話履歴、メタデータ等） │
└────────────────────────────────────────┘
↓ AES-256-GCM
┌────────────────────────────────────────┐
│ 暗号化データ (encrypted with DEK) │
│ ※各データブロックごとに個別のDEK │
└────────────────────────────────────────┘
↓ DEK自体を暗号化
┌────────────────────────────────────────┐
│ 暗号化されたDEK (encrypted with KEK) │
│ ※DEKはメタデータとして保存 │
└────────────────────────────────────────┘
↓ KEKを保護
┌────────────────────────────────────────┐
│ KEK (Key Encryption Key) │
│ 保管場所: KMS/HSM │
│ ※絶対に平文でディスクに書かない │
└────────────────────────────────────────┘
用語解説：
| 用語 | 役割 | ライフサイクル |
|---|---|---|
| DEK (Data Encryption Key) | 実データの暗号化 | データごとに生成、使用後は暗号化保存 |
| KEK (Key Encryption Key) | DEKの暗号化 | 長期間使用、定期的にローテーション |
| KMS | KEKの管理 | HSMで保護、厳格なアクセス制御 |
この構成の利点：
- 鍵ローテーションの効率化：KEKを更新すれば、全DEKを再暗号化するだけで済む
- アクセス制御の集中管理：KMSで一元的に権限管理
- パフォーマンス：データ暗号化はAES-GCM（高速）、鍵暗号化のみKMS呼び出し
2.3 鍵管理の詳細（推測）
OpenAIは「監査済みのキー管理」「キーライフサイクル管理」を行っていると記載していますが、具体的には：
鍵の生成：
- HSM（Hardware Security Module）内で暗号学的に安全な乱数生成
- FIPS 140-2/140-3準拠の可能性
鍵の保管：
- KEKはKMS内で暗号化保存
- DEKは暗号化された状態でデータと共に保存
鍵のローテーション：
- KEKの定期的な自動ローテーション（推測：90日〜1年）
- DEKは必要に応じて再暗号化
鍵の廃棄：
- 安全な削除プロセス（暗号学的消去）
- 監査ログへの記録
3. 鍵の所有者：サーバサイド vs BYOK
3.1 通常プラン：OpenAI管理の鍵
Free / Plus / Business / 通常のEnterpriseプランでは：
鍵の所有者 = OpenAI（またはクラウドプロバイダ）
┌──────────────────────────────────────┐
│ OpenAIのインフラストラクチャ │
│ │
│ ┌────────────┐ ┌──────────────┐ │
│ │ Application│ ←→ │ OpenAI KMS │ │
│ │ (平文処理) │ │ (KEK管理) │ │
│ └────────────┘ └──────────────┘ │
│ ↓ │
│ ┌────────────┐ │
│ │ 暗号化 │ │
│ │ ストレージ │ │
│ └────────────┘ │
└──────────────────────────────────────┘
これが意味すること：
- OpenAIのサーバアプリケーションは平文データにアクセス可能
- 管理者による監査ログ取得が可能
- コンプライアンス対応（SOC 2, GDPR等）のためのデータアクセスが前提
3.2 Enterprise Key Management (EKM) の詳細
ChatGPT EnterpriseおよびAPI利用では、**EKM（Enterprise Key Management）**が利用可能です：
┌──────────────────────────────────────┐
│ OpenAIのインフラストラクチャ │
│ │
│ ┌────────────┐ │
│ │ Application│ │
│ │ (平文処理) │ │
│ └────────────┘ │
│ ↓ │
│ ┌────────────┐ Encrypt/Decrypt │
│ │ DEK管理 │ ←──────────────┐ │
│ └────────────┘ │ │
│ ↓ │ │
│ ┌────────────┐ │ │
│ │ 暗号化 │ │ │
│ │ ストレージ │ │ │
│ └────────────┘ │ │
└────────────────────────────────┼───┘
│
┌────────────┴────────────┐
│ 顧客管理のKMS │
│ │
│ ┌─────────────────────┐ │
│ │ KEK (Master Key) │ │
│ │ - 顧客が完全管理 │ │
│ │ - アクセス制御可能 │ │
│ └─────────────────────┘ │
│ │
│ 対応KMS: │
│ - AWS KMS │
│ - Azure Key Vault │
│ - GCP Cloud KMS │
└─────────────────────────┘
EKMの仕組み：
-
データ暗号化フロー
データ → DEKで暗号化 → 暗号化データ保存 DEK → 顧客KMSのKEKで暗号化 → 暗号化DEK保存 -
データ復号フロー
暗号化DEK取得 → 顧客KMSにDecrypt API呼び出し → DEK取得 DEKで復号 → 平文データ取得
EKMの利点：
- ✅ 鍵の所有権を顧客に移譲
- ✅ 顧客側でアクセス制御・監査が可能
- ✅ 鍵アクセスの取り消し（Revocation）が可能
EKMの限界：
- ❌ E2E暗号化ではない（OpenAIは依然として平文を扱える）
- ❌ OpenAI側でのDEK復号は阻止できない（API呼び出しは可能）
- ❌ 鍵を取り消すと、データアクセスができなくなる（運用上の考慮が必要）
出典：
3.3 EKMのユースケース
| シナリオ | EKM導入効果 | 推奨度 |
|---|---|---|
| 規制対応（GDPR等） | 鍵の所有権証明が可能 | ✅ 高 |
| 契約終了時のデータ削除 | 鍵取り消しで実質的に削除 | ✅ 高 |
| 内部不正対策 | 顧客側で異常アクセス検知 | △ 中 |
| E2E暗号化の実現 | 不可能（別の仕組みが必要） | ❌ 低 |
4. 他サービスとの技術比較
4.1 暗号化アーキテクチャの比較
| サービス | 通信 | 保存 | 鍵管理 | E2E | PQC | アーキテクチャ |
|---|---|---|---|---|---|---|
| ChatGPT | TLS 1.2+ | AES-256 | サーバ/BYOK | ❌ | ❌ | サーバ集中型 |
| Slack | TLS 1.2+ | AES-256 | サーバ/EKP | △ | ❌ | サーバ集中型 |
| Microsoft Teams | TLS 1.2+ | AES-256 | サーバ/BYOK | △ | ❌ | サーバ集中型 |
| Signal | TLS 1.3 | AES-256 | クライアント | ✅ | ✅ | E2E型 |
| TLS 1.3 | AES-256 | クライアント | ✅ | ❌ | E2E型 | |
| iMessage | TLS 1.3 | AES-256 | クライアント | ✅ | ✅ | E2E型 |
4.2 アーキテクチャ分類
サーバ集中型（ChatGPT, Slack, Teams）
┌─────────────────────────────────────┐
│ メリット: │
│ - 組織管理・監査が容易 │
│ - 検索・AI処理が可能 │
│ - マルチデバイス同期が簡単 │
│ │
│ デメリット: │
│ - サーバ侵害時のリスク │
│ - 法的要請での開示リスク │
│ - 事業者への信頼が前提 │
└─────────────────────────────────────┘
E2E型（Signal, WhatsApp, iMessage）
┌─────────────────────────────────────┐
│ メリット: │
│ - 最高レベルのプライバシー │
│ - サーバ侵害でも安全 │
│ - 法的要請でも開示不可 │
│ │
│ デメリット: │
│ - 組織管理が困難 │
│ - サーバ側での処理制約 │
│ - 鍵紛失時のリカバリ問題 │
└─────────────────────────────────────┘
5. 今後の技術トレンド
5.1 業界全体の動向
PQC（Post-Quantum Cryptography）移行のタイムライン：
| 期間 | 主要な動き |
|---|---|
| 2024年 | NIST標準化完了（ML-KEM, ML-DSA, SLH-DSA） |
| 2025年 | 主要ブラウザ・OSでのPQC実装開始 |
| 2026-2028年 | エンタープライズサービスのPQC対応本格化 |
| 2029-2030年 | PQC対応が業界標準に |
主要サービスのPQC対応状況：
- Google Chrome：X25519Kyber768実装済み（2024年）
- Signal：PQXDH実装済み（2023年）
- Apple iMessage：PQ3プロトコル導入（2024年）
- Cloudflare：PQC対応TLS提供開始（2024年）
5.2 OpenAIに期待される対応
短期的（2025-2026年）：
- TLS 1.3必須化
- ハイブリッドPQC（X25519Kyber768）の実験的導入
- EKMの機能拡張（より細かいアクセス制御）
中期的（2027-2028年）：
- PQC対応TLSの本格展開
- 保存データの暗号化アルゴリズム選択オプション
- データレジデンシーオプションの拡充
長期的（2029年以降）：
- PQC完全移行
- E2Eオプションの提供検討（Enterprise向け）
- Zero Knowledge Proof等の先進技術導入
5.3 監視すべき技術指標
ChatGPT利用企業が注視すべきポイント：
公式アナウンスメント：
- PQC対応ロードマップの公開
- TLS 1.3必須化のスケジュール
- EKM対応KMSの拡大
技術仕様：
- サポートするCipher Suiteの公開
- 鍵ローテーションポリシーの詳細化
- データ保持期間の細かい制御
コンプライアンス：
- PQC対応に関する認証取得
- 地域別データレジデンシーの拡充
- 監査ログの詳細化
6. まとめ
6.1 技術的特徴の総括
ChatGPT（グループチャット含む）の暗号化・保存・鍵管理は：
現在の実装：
- TLS 1.2+による通信保護（推測：TLS 1.3も対応）
- AES-256 + Envelope Encryptionによる保存時暗号化
- サーバサイドKMS（Enterprise向けにBYOK対応）
技術的制約：
- E2E暗号化ではない（サーバで平文処理）
- MLS等の先進的グループ暗号プロトコル非採用
- PQC対応は少なくとも明示されていない
6.2 ポジショニング
ChatGPTは 「エンタープライズ向けクラウドコラボレーションツール」 のセキュリティ標準に準拠しています：
- ✅ SOC 2 Type II認証取得
- ✅ GDPR準拠
- ✅ 業界標準の暗号化
- ✅ Enterprise向け高度な管理機能
一方で、「プライバシー重視のE2Eメッセージングサービス」とは異なる設計思想です。
6.3 実装推奨事項（エンジニア向け）
組織でChatGPTを導入する場合：
-
アーキテクチャ理解
- サーバ集中型であることを前提とした設計
- 機密情報は前処理（匿名化等）してから投入
-
鍵管理戦略
- 高機密環境ではEKM導入を検討
- 鍵アクセスログの定期的なレビュー
-
PQC対応計画
- OpenAIのロードマップを注視
- 2030年までの移行計画策定
-
代替手段の準備
- E2E必須の用途には別ツール利用
- ハイブリッド運用の設計
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。
お問合せ: https://gmo-connect.jp/contactus/
参考文献
OpenAI公式ドキュメント
- Group chats in ChatGPT
- Enterprise privacy
- Business data privacy, security, and compliance
- Introducing ChatGPT Enterprise
- アジアにおけるデータレジデンシーの導入
- ChatGPT Business
- Data controls in the OpenAI platform
- OpenAI Enterprise Key Management (EKM) Overview
- EKM 関連ドキュメント（日本語ポータル）
- Admin Controls, Security, and Compliance
関連技術標準
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 9420: The Messaging Layer Security (MLS) Protocol
- NIST FIPS 140-3: Security Requirements for Cryptographic Modules
- NIST Post-Quantum Cryptography Standardization (2024)