セキュリティ·2026年6月11日

ChatGPT・Claude のセキュリティ設定を 3 段階で整理する

AI サービスの安全対策は「設定で機械的に防げる / ユーザー運用でしか防げない / 法人契約でしか付与されない」の 3 区分で考える。学習 opt-out と保存期間、CLI・自律エージェントを止める 3 層、投入前 5 問チェックリストと客先情報 3 区分、ZDR・監査ログなど契約前の確認項目まで横断整理する実務ガイド。

AIセキュリティChatGPTClaudeオプトアウトZDR情報漏洩対策

この記事の要点

核心: AI サービスの安全対策は「設定で機械的に防げる」「毎回のユーザー運用でしか防げない」「法人契約でしか付与されない」の 3 区分に分かれます。この境界を先に知ることが、個別のトグル暗記より重要です — 設定だけで全部は防げません。
対象読者: 社内の AI 導入で安全確認を任された企業の実務担当(製造業 IT 部門など)が主役です。個人プランで ChatGPT / Claude を使う個人開発・副業の方にも「最初に確認する設定」として使えます。
得られる成果: 3 区分の境界マップ / 学習 opt-out と保存期間の考え方 / CLI・自律エージェント系を機械的に止める 3 層 / 投入前 5 問チェックリストと客先情報 3 区分(コピペ可)/ 法人契約でしか手に入らない保証の確認項目。
扱わないこと(専門家・公式情報、または別記事へ): 利用規約の契約面(学習・商用・補償 = AI サービスを使う前に読む利用規約)/ 各サービスの設定画面の網羅手順(UI は頻繁に変わるため考え方と確認先を示します)/ 個別組織のリスク評価や法務判断の代替。

Key Points (for international readers)

Core — Safety measures for AI services fall into three tiers: enforced by settings, only preventable by per-use discipline, and only granted by enterprise contracts. Knowing where these boundaries lie matters more than memorizing toggles — settings alone cannot prevent everything.
Who this is for — corporate practitioners tasked with vetting in-house AI adoption, and indie developers on personal plans who want the first settings to check.
Portable takeaway — the three-tier frame, the pre-input five-question checklist, and the client-data three-way split are jurisdiction-neutral. Regulatory drivers differ: this Japanese edition covers Japan's context; the English edition covers the US (FTC, state privacy laws) and the EU (GDPR, AI Act).
What's out of scope — the contractual side of Terms of Service (see the AI service terms post) / exhaustive UI walkthroughs (interfaces change fast) / a substitute for your organization's risk or legal review.

執筆時点: 2026-06 / 対象: 設定の考え方は法域に中立・制度の駆動力のみ日本国内向け / last_updated: 2026-06-11 更新履歴: 2026-06-11 初版公開

本記事は教材であり、特定組織の導入助言ではない

本記事は AI サービスのセキュリティ・プライバシー設定の考え方を整理するための一般的な解説であり、特定のシステム・組織に対する導入助言や監査・法務判断の代替ではありません。内容の正確性・完全性・最新性を保証するものではなく、各サービスの設定画面・プラン名・既定値・提供条件は頻繁に変わります(本文の記述は執筆時点のものです)。実際の選定・契約・設定の判断は、必ず社内のセキュリティ / 法務部門・専門家・各サービスの公式ドキュメントと最新のプラン説明にご確認ください。本記事の情報は「現状有姿(AS IS)」で提供され、これを利用または信頼した結果生じたいかなる損害・損失についても、執筆者および YATA-NODE は一切の責任を負いません。ご利用は自己責任でお願いします。

本記事の位置づけ: 仮想化とサンドボックス入門が「実行環境の隔離の仕組み」を扱ったのに対し、本記事は「各 AI サービスで実際に効かせる設定」を扱います。利用規約の契約面(入力が学習に使われるか・出力は誰のものか)は AI サービスの利用規約が対になります。

用語ミニ解説(はじめての方へ):

学習 opt-out: 自分の入力をモデルの訓練データに使わせない設定。サービス・プランによって既定値が違います。
retention(保存期間): 入力したデータが事業者側に何日残るか。「削除した」と「残っていない」は別の話です。
ZDR(Zero Data Retention): 入力・出力を事業者側の通常の保存から除外する契約形態。ただし全社一律ではなく、適用範囲は製品・モデル・API 単位で個別に定まり(通常のチャット UI は原則対象外のことが多い)、法令・不正利用対応などでの保持も残ります。通常は法人契約で別途申請が必要で、対象は各社ドキュメントの適用範囲表で確認します。
自律エージェント: 人の確認なしにコマンド実行・Web 操作・ファイル変更まで進められる AI(エージェントモードのチャット、CLI エージェント、ブラウザ操作系など)。
CLI(Command Line Interface): 画面のクリック操作(GUI)ではなく、コマンドを文字で打ち込んで操作する方式。Claude Code / Codex CLI などのエージェントがこの形です。
SSO(Single Sign-On)/ SCIM: 1 回のログインで複数サービスを使える仕組み(SSO)と、アカウントの発行・削除を自動連携する仕組み(SCIM)。退職者アカウントの放置を防ぎます。
SOX(Sarbanes-Oxley Act): 米国の企業改革法。上場企業に財務報告の内部統制と証跡(誰が何をしたかの記録)を求めます。対象業務では監査ログが要ります。

「AI に機密を入れるな」とはよく言われますが、では設定で防げる範囲はどこまでなのでしょうか。結論から言うと、AI サービスの安全対策は ①設定で機械的に防げる(opt-out / 拒否リスト / サンドボックス)②毎回のユーザー運用でしか防げない(そもそも入力しない判断)③法人契約でしか付与されない(ZDR / 監査ログ / BAA)の 3 区分に分かれ、この境界はサービスの種類でかなり違います。本記事は、①まず 3 区分の地図を描き ②全員に関わる「学習 opt-out と保存期間」を押さえ ③CLI・自律エージェント系を機械的に止める 3 層を整理し ④「この情報を今から入れていいか」の投入前判断をチェックリスト化し ⑤法人契約でしか手に入らない保証を確認項目にします。トグルの暗記ではなく「どの区分の話か」で、自分と組織の守りを設計できるようになりましょう。

「設定で防げる」には境界がある — 3 区分のフレーム

個別の設定に入る前に、全体の地図を 1 枚で描きます。

区分	内容	代表例
① 設定で機械的に防げる	モデル / システムの動作を制限する設定	学習 opt-out / サンドボックス / 機密ファイルの読み取り拒否 / 実行前承認 / 保存期間の短縮
② ユーザー運用でしか防げない	設定では止められない、毎回の判断	機密をそもそも入力しない判断 / 自律エージェントに触らせるサイト・データの取捨選択 / 生成物を二次配布する前の検証
③ 法人契約でしか付与されない	個人プランには存在しない保証	ZDR(非保存契約)/ 監査ログ / SSO / DLP 連携 / 規制対応の契約(BAA 等)

この地図の使い方は 2 つです。第一に、「①で防げると思っていたことが実は②だった」というズレが事故の典型だと知ること(機密の投入判断は、どんな設定をしても②のままです)。第二に、②と③の存在を先に宣言すること — 本記事で「設定で防げる」と書く範囲はあくまで①であり、その先は運用と契約の話になります。

まず全員: 学習 opt-out と保存期間(共通)

ここは個人プラン・法人問わず、最初に確認する区分①の代表です。

チャット系の個人プランは、入力が学習に使われる設定が既定で有効なものがあります。たとえば執筆時点で、ChatGPT と Claude.ai の個人プランは、いずれも入力が学習に使われるかどうかを設定画面で確認・変更でき、使わせたくない場合は手動でオフにします(既定値や項目名はプラン改定で変わりうるため、使い始めた日にデータ・プライバシー項目を必ず確認してください)。
API 系(両社)は、既定で入力が学習に使われない扱いが通例です。ただし「学習に使われない」と「保存されない」は別で、不正利用検知などの目的で一定期間は保存されることがあり、その日数や条件は事業者・モデル・契約で異なります(執筆時点でも両社で扱いが違います。確認先は出典欄の各社 retention ドキュメント)。
事業者側の通常の保存をなくしたい場合は ZDR(Zero Data Retention)という契約形態がありますが、適用は製品・モデル・API 単位で、通常のチャット UI は原則対象外のことが多く、対象範囲は各社ドキュメントの一覧で確認します(通常は法人契約で営業経由の申請。区分③)。

保存期間で見落とされがちな教訓を 1 つ。米国の著作権訴訟(The New York Times 対 OpenAI)では、裁判所の命令により、一部プランの利用データが訴訟証拠保全のため法的に保持された期間がありました(2025-05 発令、同年 9 月に新規分は解除)。つまり「削除ボタンを押した = 完全に消えた」とは限らない局面が、法的命令によって実際に起こりえます。機密は『削除すればいい』ではなく『最初から入れない』が原則 — これが区分②の話に接続します(データが事業者側でいつ消えるか・どの国の政府が見うるかは、AI・クラウドに預けたデータはいつ消え、誰が見ることができるかと米国企業にデータを預けるということで詳しく扱っています)。

CLI・自律エージェント系: 機械的に止める 3 層(個人開発者がまず確認)

ここは AI にコマンド実行やファイル操作をさせる使い方(Claude Code / Codex CLI などの CLI エージェント)での区分①です。この系統は「設定で機械的に防げる」範囲が最も広く、3 層で守るのが基本形です。

サンドボックス: 実行をファイルシステム・ネットワークの隔離環境に閉じ込める(仕組みは仮想化とサンドボックス入門で扱いました。有効化が必要な実装がある点も同記事のとおりです)。
実行前承認(approval): コマンドや外部接続の前に人間の確認を挟むモードを維持する。
拒否リスト(deny-list): 機密ファイル(.env、認証情報ディレクトリ)や危険コマンド(削除・外部送信)を設定として読めなく / 実行できなくする。

3 層に共通する最大の落とし穴は、「全部スキップする」系のオプションです。多くの CLI エージェントには承認やサンドボックスを無効化する実行フラグやモードが用意されていますが、これを常用すると区分①の守りがゼロになります。こうした無効化フラグ・モードは、便利さと引き換えに使わない、を原則にしてください。

一方、自律エージェント系(ブラウザを操作する・デスクトップを操作する・クラウドで自走するタイプ)は、設定で防げる領域が CLI 系より構造的に狭いことを知っておく必要があります。外部の Web ページやメールの中の指示でモデルが誤動作する prompt injection は、設定だけでは塞ぎきれません(区分②)。確認モード(操作を見守り、要所で人間が承認する)を維持する・機密サイトやログイン済みセッションに触らせない・本番システムや金融・医療業務に使わない、という運用側の線引きが主役になります。

入力してよいかの判断 — 投入前 5 問と客先情報の 3 区分(共通・最重要)

区分②の中核は「そもそも入力してよいか」の判断です。投入する直前に、次の 5 問に答えてください(コピーして使えます)。

text

【AI 投入前 5 問チェック(1 問でも不可側なら投入しない)】
□ その情報は NDA / 守秘義務契約 / 業務委託契約で外部送信が禁じられていないか
□ 客先・第三者の固有名と機密内容(顧客名簿 / 受注額 / バグ詳細)がセットになっていないか
□ 使うサービスは opt-out 設定済み / ZDR / 学習対象外の API 経路のいずれかか
□ 入力が履歴・メモリ・会話タイトルに保存される設計でないか(機密なら一時チャット等を使う)
□ 漏洩したとき自分や所属組織が法的責任を負う情報でないか(該当なら上長・法務へ)

客先・取引先の情報は、次の 3 区分で線を引くと判断が速くなります。

区分	例	可否
明示禁止	客先名 + 機密内容のセット(受注額 / バグ詳細 / 個人情報)/ 未公開仕様書の原文 / コード内の客先固有 API キー	原則入力しない(契約・法令違反が重なりうる。例外は法務・セキュリティ承認済みの処理ルートのみ)
要マスキング	客先名を除いた技術構成 / API キー除去 + 固有名置換済みのコード断片 / ID・IP をマスクしたエラーログ	マスキング後に、opt-out / ZDR / API 経路で可。マスキングは手作業 + 機械チェックの二重で
明示可	公開済み OSS コード / 公開済み API 仕様 / 一般的な技術質問 / 契約上の知財が自分にあるコード	可(opt-out は望ましい)

実際に起きた事例も、この枠で読むと教訓が立体的になります(いずれも当時の報道・公式発表に基づく実例です。一般化した教訓と区別して読んでください)。

機密の投入: 2023 年、Samsung の半導体部門で社内ソースコード等を ChatGPT に投入した事案が複数報じられ、同社は全社利用禁止に踏み切りました。教訓は「使うな」ではなく、「何は入れてよいか」の事前定義がないままツールだけが先に普及すると事故になる事例です(上の 5 問と 3 区分がその事前定義に当たります)。
生成物の事故: 2023 年、米国の弁護士が ChatGPT の生成した実在しない判例を裁判所に提出し制裁金を命じられました。2025 年には大手コンサルの公的報告書でも AI 起因の架空引用が発覚し一部返金に至っています。生成物を二次配布する前の人間の検証は、どんな設定でも代替できません(区分②)。
ベンダ側の障害: 2023 年、OpenAI 側のバグで他ユーザーの会話タイトルや支払情報の一部が一時露出した事故がありました(公式発表あり)。自分の設定が完璧でも、事業者側の事故はゼロにできない — 入れるデータを最初から絞ることが唯一の自衛です。

上位法人プラン・個別契約で確認する保証(企業実務担当向け)

社内導入の安全確認では、区分③ — 個人プランには無く、多くは上位法人プラン・個別契約・営業経由の申請で提供される保証 — を契約前に確認します。

ZDR(非保存契約): 入力・出力を通常の保存から除外する契約。適用は製品・モデル・API 単位で定まり(通常のチャット UI は原則対象外)、「例外なくゼロ」ではなく、対象外の製品・機能・モデルや、法令・不正利用対応での保持は残ります(適用範囲の表が各社ドキュメントにあります)。執筆時点では両社とも営業経由の個別申請が通例で、設定画面のトグルでは有効化できません。
監査ログ / コンプライアンス API: 「誰が・いつ・何をしたか」の記録。上位の法人プランで提供されるのが通例です。注意すべきは、エージェント系の新しい製品では監査ログが未提供のものがあること(執筆時点の各社ドキュメントでも、一部のエージェント製品は監査機能の対象外と明示されています)。規制対象の業務(医療・金融・SOX 対応)では、監査ログのない製品を使わない社内規程を先に作るのが安全です。
規制対応の契約: 米国の医療情報規制(HIPAA)対象の業務なら BAA(Business Associate Agreement)という契約が必要ですが、これはプランによって提供有無が分かれます。「法人プランなら大丈夫」ではなく、どのプランが対象かを契約前に必ず確認してください(執筆時点では、同じ事業者でも中位プランが対象外という構成が実在します)。なお BAA は米国 HIPAA の概念で、日本の医療・金融業務では個人情報保護法・委託契約・業界ガイドラインの確認が別途必要です(本記事の範囲外 = 法務に確認)。
SSO / SCIM / DLP 連携: アカウント管理の集中化と、機密データの送信検知。退職者アカウントの放置や、設定の個人任せを防ぐ基盤です。

まとめると、企業の確認軸は「この業務に必要な保証(非保存 / 監査 / 規制対応)は、検討中のプランに含まれているか」の一点です。機能比較より先に、この一点を営業・公式ドキュメントで確認することをおすすめします。

まとめ — 個人と企業の最低限チェック

AI サービスの安全対策は「設定で防げる(①)/ 運用でしか防げない(②)/ 法人契約でしか付与されない(③)」の 3 区分で考える、が本記事の地図でした。最後に、立場別の最低限チェックを置きます(コピーしてお使いください)。

text

【個人プランの最低限(個人開発・副業)】
□ チャット系の学習 opt-out を設定画面で確認・オフにしたか(既定で有効の場合がある)
□ API キーは .env 管理 + .gitignore(コードに直書きしない)
□ CLI エージェントは サンドボックス + 実行前承認 + 拒否リスト の 3 層を維持(全部スキップ系を常用しない)
□ 自律エージェントに機密サイト・ログイン済みセッション・本番システムを触らせない
□ 機密会話は一時チャット等(履歴・メモリに残りにくい設定)を使う(完全な非保存ではなく一定期間の保持・安全対応の例外あり。削除に頼らない)
□ 投入前 5 問チェック(本文)を習慣化する

【企業導入の最低限(社内 AI の安全確認)】
□ 規制業務(医療・金融等)の有無を先に確定し、必要な保証(BAA / 監査ログ)があるプランかを契約前に確認
□ ZDR が必要かを判定(顧客データ・PII を扱うなら検討)— 営業経由の申請が通例
□ 監査ログのないエージェント製品を規制業務に使わない規程を作る
□ 学習 opt-out の既定値をプラン別に確認(法人プランは既定オフが通例だが契約で確認)
□ 投入前 5 問チェックと客先情報 3 区分を社内チェックリストとして配布
□ 管理設定の中央配布(管理者がメンバーの拒否リスト等を統制できる仕組み)を使う

出典 / References

最終確認日: 2026-06-11 / 対象法域: 設定の考え方は法域に中立(米国・EU の規制ドライバーは英語版で扱う)。注意: 各サービスの設定・プラン・既定値は頻繁に変わるため、以下は「確認先」として利用し、判断時は必ず最新のページを参照してください。

データ利用・プライバシー(公式)

CLI・エージェントの設定(公式)

実例(出典種別を各項に明示)

(一次)OpenAI — March 20 ChatGPT incident(公式報告、2023-03-24)
(一次)OpenAI — The New York Times のデータ要求への回答(訴訟保全命令に関する公式声明)
(一次)NYT 対 OpenAI 保全命令の終了(継続的保持義務は 2025-09-26 付で終了、2025-10-09 の合意修正命令)— 裁判所命令 PDF
(一次)Mata v. Avianca 制裁命令(裁判所記録、CourtListener)
(二次)Samsung の ChatGPT 利用制限(Bloomberg / TechCrunch、2023-05 報道)— TechCrunch 2023-05-02
(二次)Deloitte 豪州の政府向け報告書での AI 生成の架空引用・一部返金 — Fortune 2025-10-07

各サービスの設定画面・プラン構成・既定値・提供条件は改定で変わります。本記事は確認の枠組み(3 区分 + チェックリスト)を提供するものであり、個別の設定値・プラン選定の判断時は上記の一次情報と最新の公式ページで確認してください。

この記事の 3 区分を、実際に何を設定するかまで落とした無料の記事を note で公開しています：AI を使う前に、最低限そろえたい設定 — 機械・運用・契約の3区分。関連する守りの連載はセキュリティマガジンにまとめています。

著者について

大手電機メーカーで制御工学から 20 年以上の電機・ソフトウェア開発、加えて個人開発約 10 年の実務経験を持ちます。ハードとソフト、企業と個人の両面で「知らないとリスクになる」基礎から発信し、いずれは AI の実践的な活用法なども扱っていく予定です。詳しくはこのブログについて。

セキュリティ2026年6月27日

保存データのセキュリティ入門 ― 暗号化・鍵管理・バックアップの地図

「ディスクを暗号化すれば安全」ではありません。保存データの守りを、どのレイヤ(アプリ / DB / ディスク)で暗号化するか・鍵をどこに置くか(環境変数 → KMS → エンベロープ)・バックアップと復元テスト・アクセス制御の 5 つの判断として、「どの脅威に何で備えるか」で一枚の地図に整理します。

個人情報保護暗号・鍵管理個人開発

コラム2026年6月20日