Codexに本番データを渡す前に決めること

3行まとめ

Classify

分類。

Minimize

最小化。

Share

共有。

Retain

保持。

本番データは、便利さより先に分類と最小化を決めます。

• Codexに本番データを渡す前に、public、internal、confidential、PII、secretを分類し、渡してよい情報と渡さない情報を分けます。
• 顧客ログやスクリーンショットは、そのまま貼らず、sample data、synthetic data、aggregation、redactionで必要最小限にします。
• ChatGPT BusinessやEnterpriseのデータ扱いは公式情報と契約で確認しつつ、作業ごとの共有範囲、retention、承認者をdata packetへ残します。

Codexに原因調査や修正を頼む時、本番データを見せたくなる場面があります。顧客ログ、support ticket、決済エラー、管理画面のスクリーンショット、API response、DBの一部。実際のデータがあるほど、再現や原因調査は進みやすくなります。

ただし、本番データは便利な材料である前に、扱いを決めるべき情報です。個人情報、契約情報、secret、内部URL、非公開の顧客名、決済情報、障害情報が混ざることがあります。急いでいる時ほど、「このまま貼れば早い」となりがちです。

この記事では、Codexに本番データやPIIを含む可能性がある情報を渡す前に、何を確認し、どう削り、どの形で依頼へ入れるかを整理します。ログ調査のpacketは、公開済み記事のCodexにログ調査を頼む前に決めることで扱いました。ここでは、より手前のdata handlingに絞ります。

この記事でわかること

PII

個人。

Secret

秘密。

Owner

承認。

Packet

型。

Codexへ渡してよい情報と渡さない情報を、作業ごとに明示します。

• Business dataと個人利用の違いを確認する観点
• public、internal、confidential、PII、secretの分類
• sample data、synthetic data、aggregation、redactionの使い分け
• 共有リンク、user history、admin visibility、usage analyticsを分ける理由
• retention、artifact、削除要求を確認する方法
• Codexへ渡すdata packetの型
• 顧客ログ、スクリーンショット、support ticketをそのまま貼らない考え方
• よくある失敗と回避策

これは法務判断の代わりではありません。実際の運用では、契約、社内規程、セキュリティ方針、顧客との約束を確認してください。この記事は、開発現場で依頼を出す前の整理表です。

前提知識

項目	内容	見方
Business		workspace。
Enterprise		privacy。
Training		学習。
Admin		可視性。

公式のデータ扱いと社内ルールを両方確認します。

OpenAIのEnterprise privacyページでは、Business、Enterprise、Edu、Healthcare、API Platformなどのbusiness dataについて、入力と出力の所有と管理、学習利用、保持、アクセス制御などの考え方が説明されています。ChatGPT BusinessのHelp Centerでは、Business workspace dataはデフォルトで学習対象から除外され、Business workspaceでCodexを使う場合も同じprivacy commitmentsが適用されると説明されています。

また、ChatGPT Businessでは各ユーザーが自分のchat historyとCodex historyを持ち、他のmemberが自動でそれらを閲覧できるわけではないこと、shared linksやusage analyticsの見え方は別に扱うことが説明されています。

Business dataと個人利用を分ける

最初に分けるのは、個人利用なのか、Business/Enterprise workspaceなのかです。

同じCodexでも、workspace、plan、契約、data controls、共有設定、管理者権限で扱いが変わります。社内利用では、個人アカウントへ本番データを貼る運用を避け、承認されたworkspaceと設定を使います。

data handlingは社内ルールも見る

公式のデータ扱いだけでなく、社内ルールも見ます。

顧客データをAIに渡してよいか。ログのredaction基準は何か。スクリーンショットを保存してよい期間はどれくらいか。削除要求が来た時にどこを消すのか。これはツールの機能だけでは決まりません。

データを5分類する

項目	内容	見方
Public		公開。
Internal		社内。
Conf		機密。
PII		個人。
Secret		鍵。

分類がないまま作業依頼へ混ぜると、redactionの基準がぶれます。

Codexへ渡す前に、データを分類します。

分類がないと、redactionの基準が毎回ぶれます。

public

publicは、公開済み情報です。

公開docs、公開issue、公開リリースノート、公開API仕様、公開サイトのHTMLなどです。publicでも、著作権や利用規約、引用範囲は守ります。

internal

internalは、社内向け情報です。

内部docs、非公開PR、設計メモ、社内の会議メモ、開発環境URLなどです。外部に出せないが、社内の承認済みworkspaceなら扱える場合があります。

confidential

confidentialは、機密性が高い情報です。

事業計画、未公開機能、契約条件、顧客名、障害詳細、security finding、財務情報などです。Codexに渡す場合は、目的、範囲、承認者を明確にします。

pii

PIIは、個人を識別できる情報です。

氏名、メールアドレス、電話番号、住所、ユーザーID、IP address、自由記述、画像内の個人情報などが含まれます。PIIは、必要がない限り渡さない。必要なら匿名化、集計、合成データへ置き換えます。

secret

secretは、渡さない情報です。

API key、token、cookie、password、private key、署名付きURL、認証header、session ID、database credentialなどです。secretはredactionしても、一部だけ残す運用は避けます。

Codexへ渡す前に最小化する

1. 1Sample

   抜粋。

2. 2Synthetic

   合成。

3. 3Aggregate

   集計。

4. 4Redact

   伏せる。

必要な関係性だけ残し、生データはなるべく渡さない形にします。

本番データを扱う時は、まず最小化します。

必要な原因調査に、全件のログや全顧客データが必要とは限りません。

sample data

sample dataは、必要な行だけを抜き出したものです。

たとえば、失敗したrequestの前後数行、同じerror codeの数件、特定fieldだけを残したJSONなどです。sampleには、どの条件で抜き出したかを書きます。

synthetic data

synthetic dataは、実在しないデータです。

構造や制約だけを再現し、名前、メール、ID、金額、住所などは架空にします。再現に本物が不要なら、synthetic dataを使います。

aggregation

aggregationは、集計値です。

件数、割合、分布、error rate、durationのp95、segment別の傾向などです。個別データを渡さずに、原因候補を絞れることがあります。

redaction

redactionは、必要な関係性を残して伏せる作業です。

同じユーザーらしき値を USER_A に置き換える。同じorganizationを ORG_1 に置き換える。tokenは完全に TOKEN_REDACTED にする。こうすると、相関は残しながら中身を隠せます。

共有範囲と可視性を決める

項目	内容	見方
User		本人。
Link		共有。
Admin		管理。
Usage		利用。

共有リンク、管理者可視性、使用量分析は同じものではありません。

データを渡す時は、誰に見えるかも決めます。

会話に貼る、共有リンクを作る、artifactに残す、PRへ貼る、CI logへ出す。場所ごとに可視性が変わります。

user history

ChatGPT BusinessのHelp Centerでは、workspace内でも各ユーザーが自分のchat historyとCodex historyを持ち、他のmemberが自動的に閲覧できるわけではないと説明されています。

ただし、これは「何でも貼ってよい」という意味ではありません。履歴に残ること、検索や共有の扱い、社内ルールを見ます。

shared links

shared linksは、特定の会話をteam memberへ共有する仕組みです。

本番データを含む会話では、shared linkを作る前に中身を確認します。共有先が増えるほど、情報管理の責任も増えます。

admin visibility

admin visibilityは、管理者が何を見られるかです。

Help Centerでは、workspace-level spending controlsがusageやcreditsのようなoperational metricsを表示する場合がある一方、private chat historyへの完全なアクセスを自動的に与えるわけではないと説明されています。

ただし、組織の設定や監査要件は確認が必要です。

usage analytics

usage analyticsは、利用状況を見るための指標です。

使用量やcreditは、内容そのものとは別です。内容の共有、履歴の可視性、利用量の可視性を混同しないようにします。

retentionと削除要求を見る

項目	内容	見方
Workspace		設定。
Artifact		保存物。
Logs		ログ。
Delete		削除。

会話だけでなく、artifactやログに残る情報も確認します。

データは、貼った瞬間だけでなく、どこに残るかを見ます。

会話、artifact、CI log、PR comment、shared link、screenshot、local file。残る場所が増えるほど、削除や監査が難しくなります。

workspace policy

workspace policyは、組織の設定と契約です。

Enterprise privacyページでは、ChatGPT Enterprise、Healthcare、Eduなどでdata retentionを管理できることが説明されています。BusinessやAPI Platformの扱いも、契約や公式ページで確認します。

artifact retention

artifact retentionは、生成物やログの保存期間です。

CI artifact、browser trace、screenshot、debug log、export fileは、会話とは別に残ります。保存期間、削除方法、アクセス権を決めます。

deletion

削除要求がある場合、どこを消すかを把握しておきます。

会話だけでなく、PR、issue、artifact、ticket、local file、shared linkに情報が残ることがあります。Codexへ渡す前に、残る場所を減らすほうが安全です。

Codexへ渡すdata packet

項目	内容	見方
Purpose		目的。
Allowed		許可。
Forbidden		禁止。
Owner		承認。

data packetがあると、依頼文へ混ぜてよい情報が明確になります。

Codexへ本番データに近い情報を渡す場合、data packetを作ります。

これは、依頼文の前に置く短い取り扱いメモです。

purpose

purposeには、なぜこのデータが必要かを書きます。

例: 「決済失敗の再現条件を絞る」「CSV importのfield欠落を確認する」「support ticketから再現手順を作る」。

目的が曖昧なら、データを渡す必要があるかも曖昧です。

allowed data

allowed dataには、渡してよい情報を書きます。

例: redacted log、synthetic JSON、集計値、匿名化したerror code、公開URL、非本番のsample DB dump。

forbidden data

forbidden dataには、渡さない情報を書きます。

secret、cookie、token、顧客名、メール、住所、決済情報、内部URL、契約条件、未公開security findingなどです。

review owner

review ownerには、確認者を書きます。

security owner、data protection owner、product owner、support ownerなどです。曖昧な場合は、Codexに渡す前に人間確認へ戻します。

ログとスクリーンショットの扱い

Log

行。

Shot

画像。

Ticket

報告。

Mask

除外。

ログやスクリーンショットは証拠ですが、そのまま渡す前に削ります。

ログとスクリーンショットは、特に混入しやすい情報です。

証拠としては便利ですが、そのまま貼る前に削ります。

customer log

customer logには、個人情報、契約情報、内部ID、IP address、tokenに近い値が入ることがあります。

Codexへ渡すなら、必要な行だけにし、識別子を置き換え、secretを完全に削除します。

screenshot

screenshotには、画面上の顧客名、メール、住所、金額、内部URL、admin menu、browser extension、通知などが写ります。

画像はテキストよりredaction漏れが起きやすいです。必要なら、文字を隠した画像ではなく、再現用のmock画面や説明文へ置き換えます。

support ticket

support ticketには、顧客の自由記述があります。

自由記述は、個人情報や感情的な表現、契約情報、障害影響が混ざります。Codexへ渡す時は、issue、steps、expected、actual、impactへ要約してから渡します。

そのまま貼らない

「急いでいるからそのまま貼る」は避けます。

急いでいる時ほど、何を貼ったかを後から追いにくくなります。短いredaction checklistを作り、貼る前に確認します。

よくある失敗

Raw dump

丸貼り。

Link share

共有。

Long keep

保存過多。

No owner

承認なし。

本番データの事故は、悪意よりも便利さの勢いで起きます。

よくある失敗は、本番データを「開発に必要な情報」として一括りにすることです。

1つ目は、ログ全文を貼ることです。必要なのは、原因調査に関係する行と相関情報です。

2つ目は、スクリーンショットをそのまま貼ることです。画像の隅に個人情報や内部URLが残ります。

3つ目は、shared linkを作った後に中身を確認することです。共有前に確認します。

4つ目は、artifactやPR commentに残ることを忘れることです。会話以外にも情報は残ります。

FAQ

項目	内容	見方
渡せる?		分類。
学習?		契約。
見える?		共有。
消せる?		保持。

迷ったら、誰が見て、どこに残り、いつ消えるかを確認します。

Business workspaceなら本番データを貼ってよいですか

自動的に「何でもよい」にはなりません。

Business workspaceのprivacy commitmentsや学習利用の扱いは公式情報で確認しつつ、社内ルール、契約、顧客との約束、データ分類に従います。

Codexを使うと学習ポリシーは変わりますか

OpenAI Help Centerでは、ChatGPT BusinessのworkspaceがCodexやその他のusage-based featuresを使う場合も、同じprivacy commitmentsが適用されると説明されています。

ただし、利用中のworkspace、plan、契約、設定は導入時に確認してください。

redactionすればPIIを渡してよいですか

redactionの品質次第です。

再識別できる情報が残っていないか、自由記述や画像内に漏れがないか、同じ識別子をどう置き換えたかを確認します。不安がある場合は、synthetic dataへ置き換えます。

どこまで記録を残すべきですか

目的に必要な期間だけ残します。

PR reviewに必要な証拠、監査に必要な記録、削除できる一時artifactを分けます。長く残すほど、管理責任も増えます。

参照した主な情報源

• ChatGPT Business におけるデータ管理、共有、プライバシー | OpenAI Help Center
• Managing data, sharing, and privacy in ChatGPT Business | OpenAI Help Center
• Enterprise privacy at OpenAI | OpenAI
• Business data privacy, security, and compliance | OpenAI
• Codex | OpenAI

次に読むなら

更新履歴

1. 2026.05.31

   初版。

データ扱いの条件は変わるため、導入時に公式情報と契約を確認します。

• 2026.05.31 初版公開。