OpenAI「GPT-6 Luna」の推論が日本国内で可能に、企業の機密情報はどう扱われる？

OpenAIのAPIで、GPT-6 Lunaによる推論を日本国内で実行できるようになった。OpenAI JapanのTakehiro Ogino氏が2026年11月11日、自身の投稿で明らかにした。OpenAIは2025年5月から、対象となるAPI顧客に日本国内でのデータ保存を認めていたが、今回の対応によって、モデルが入力を処理し、回答を生成する場所も日本に指定できるようになった。データの国外移転や処理場所が導入上の障壁となっていた企業にとって、新たな選択肢となる。

ただし、日本国内での推論を利用するには、OpenAIの承認を受けたゼロデータ保持（Zero Data Retention、以下ZDR）を有効にする必要がある。ZDRは主に不正利用監視ログへの顧客コンテンツの保存を制限する仕組みだが、APIのすべての機能でデータが一切保持されなくなるわけではない。通常のResponses APIでは設定によって応答が保存され、会話履歴やアップロードファイルには別の保持条件が適用される。企業が機密情報を扱う場合は、推論を実行する地域だけでなく、各機能がデータをどのように保存するのかまで把握する必要がある。

国内保存に続き、GPT-6 Lunaの推論も日本で可能に

OpenAIは2025年5月7日の公式発表で、日本、インド、シンガポール、韓国におけるデータレジデンシーへの対応を発表した。対象となるAPI顧客は、プロジェクトの作成時に保存地域を選択し、APIの動作に必要な顧客コンテンツを指定した地域に保存できる。しかし、当時の対応は主に保存場所の指定であり、モデルによる推論処理まで国内で行われることを保証するものではなかった。

今回の対応では、この「保存地域」と「推論地域」の違いが重要になる。保存地域は、APIが顧客コンテンツを保持する必要がある場合に、その保存先を指定するものだ。一方、推論地域は、モデルが入力を処理して回答を生成する場所を指定する。OpenAIの地域別対応表では、日本は両方に対応する地域となった。ただし、国内保存に対応するAPI機能やモデルが、すべて国内推論にも対応しているわけではない。

2026年11月12日時点で、日本国内の推論に対応するモデルはGPT-6 Lunaに限られる。利用者は日本リージョンのプロジェクトから地域別エンドポイント jp.api.openai.com に接続し、ZDRを有効にした状態でモデルを呼び出す。対応するAPIはResponses APIとChat Completions APIで、テキストまたは画像を入力し、テキストを出力する構成を利用できる。

画像入力については、通常のZDRとは別に「enhanced ZDR」または「enhanced Modified Abuse Monitoring（MAM）」の承認も必要になる。日本国内での推論そのものには有効なZDRが必須であるため、画像入力に関する追加承認だけでは条件を満たさない。また、国内推論に対応するのは標準の従量課金方式であるStandardのみで、OpenAIが運用するホスト型ツールは対象外だ。地域別の保存機能が利用できても、File SearchやCode Interpreterなどを含めた処理全体を日本国内で実行できるとは限らない。

料金にも違いがある。OpenAIの公式仕様では、2026年3月5日以降に公開されたデータレジデンシー対応モデルについて、地域別エンドポイントの利用料金に10%が上乗せされる。さらに、日本を含む米国外のリージョンを利用するには、不正利用監視に関する設定の承認と、データ保持条件を変更する契約条項への合意が必要だ。なお、アカウント情報、利用統計、請求情報など、顧客コンテンツに該当しないシステムデータには地域指定が適用されず、国外で処理・保存される場合がある。

ゼロデータ保持でも、APIの機能によって保存期間は異なる

OpenAIは、顧客が明示的に同意しない限り、APIに送信されたデータをモデルの学習や改善に使用しないと定めている。ただし、学習に使用しないことと、データを保存しないことは別だ。OpenAIのデータ管理ガイドでは、APIで保存されるデータを「不正利用監視ログ」と「アプリケーション状態」の2種類に分けている。

不正利用監視ログは、利用ポリシーへの違反や悪用を検知するための記録で、入力されたプロンプトやモデルの応答、分類器による判定結果などが含まれる場合がある。通常の設定では最長30日間保持されるが、法令上の要請がある場合や、サービスや第三者への危害を防ぐために合理的に必要な場合は、期間が延長される可能性がある。ZDRまたはModified Abuse Monitoring（MAM）の承認を受けると、所定の例外を除き、こうしたログから顧客コンテンツを除外できる。

一方、アプリケーション状態は、APIの機能を動作させるために保存されるデータだ。例えば、以前の回答を再取得したり、会話の続きを生成したりするために保持される情報が該当する。通常のResponses APIでは、store パラメータを省略するか true にすると、応答データが少なくとも30日間保存される。store=false を指定すると通常の応答保存は行われないが、不正利用監視ログの保持条件は変わらない。

ZDRを有効にすると、この動作も一部変更される。Responses APIとChat Completions APIでは、リクエストで store=true を指定しても、強制的に false として処理される。ただし、この制御はすべてのAPIエンドポイントに適用されるわけではない。ConversationsやFilesなど、ZDRの対象外となる機能では、それぞれの保持条件に従ってデータが保存される。

OpenAIが2026年11月12日時点で公開している保持条件を整理すると、次のようになる。

API・設定	不正利用監視ログ	アプリケーション状態	ZDR対応
Responses（通常、store 省略または true）	既定で最長30日	応答データを少なくとも30日保存	対応、制限あり
Responses（通常、store=false）	既定で最長30日	通常の応答保存なし	対応、制限あり
Responses（ZDR有効）	顧客コンテンツを原則除外	store=false として処理	対応、制限あり
Chat Completions（ZDR有効）	顧客コンテンツを原則除外	原則保存なし。一部例外あり	対応、制限あり
Conversations	削除まで	削除まで	対象外
Files	既定で最長30日	削除まで。expires_after による期限指定が可能	対象外
Vector Stores	既定で最長30日	削除まで	対象外
Batch	既定で最長30日	削除まで	対象外

この表は、OpenAIのエンドポイント別保持仕様に基づく一般的な条件を示している。ZDRに対応する機能であっても、一部の処理では例外的な保存が発生する。また、表にあるすべてのAPIが日本国内での推論に対応しているわけではない。

例えば、Conversations APIでは、会話オブジェクトを作成することで、複数のリクエストにまたがって過去のやり取りを引き継げる。しかし、通常のResponses APIで store=false を指定しても、別途作成した会話オブジェクトが削除されるわけではない。Conversations APIに保存された情報は、削除されるまで保持される。

同様に、Files APIへアップロードしたファイルや、Vector Storesに保存した検索用インデックスにも独立した保持条件が適用される。Filesでは expires_after によって有効期限を指定できるが、原本ファイルと検索用インデックスは別のリソースであり、削除も個別に管理する必要がある。ZDRを有効にしただけでは、これらのデータが自動的に消去されることはない。

ZDRやMAMの設定は、OpenAIの承認後、組織単位またはプロジェクト単位で管理できる。プロジェクト側で default を選べば組織の設定を引き継ぎ、承認された保持設定を個別に指定することも可能だ。一方、None を選択したプロジェクトでは、これらの特別な保持制御が適用されない。MAMだけを有効にしたプロジェクトは、日本国内での推論には利用できない。

ZDRを有効にしても一時保存が発生する機能

ZDRの適用後も、APIが処理を完了するために一時的なデータ保存を必要とする場合がある。その代表例が、Responses APIのバックグラウンドモードだ。これは時間のかかる生成処理を非同期で実行し、クライアントが後から処理状況や結果を取得できるようにする機能である。

OpenAIのバックグラウンド処理ガイドによると、ZDRが有効なプロジェクトでは、バックグラウンド処理も store=false として実行される。ただし、処理結果を後から取得できるようにするため、応答データはディスク上に約10分間保存される。MAMを利用するプロジェクトでは、バックグラウンド処理の応答をこの一時保存期間より長く保持するには、store=true を明示する必要がある。これらはAPI全般の保持仕様であり、バックグラウンドモードが日本国内推論の対象として提供されることを示すものではない。

音声機能にも独自の保持条件がある。Responses APIとChat Completions APIでは、音声出力を伴う複数ターンの会話を処理するため、音声出力に関するアプリケーション状態が1時間保存される。また、Hosted ShellやCode Interpreterを使用すると、処理中にコンテナ内のファイルシステムへ一時データが書き込まれる場合がある。これらのファイルは、コンテナの有効期限が切れるか、明示的に削除されるまで残る。

もう一つ注意が必要なのが、プロンプトキャッシュだ。OpenAIは、過去のリクエストと共通する入力部分を再利用することで、推論に必要な計算を減らしている。この仕組みでは、元の文章そのものではなく、モデルが計算したKey-Value（KV）テンソルを暗号化し、GPU側のストレージに保存する場合がある。公式ガイドでは、このデータの保存期間の上限を24時間としている。

GPT-5.6以降のモデルでは、Responses APIの prompt_cache_options.ttl によって、キャッシュの最低保持時間を指定できる。標準設定は30分で、対応する構成では12時間も選択できる。ただし、この値はキャッシュを少なくとも維持する時間を指定するものであり、その時点で必ず削除する期限ではない。指定した時間を過ぎても、最大保持期間の範囲内でデータが残る可能性がある。

さらに、画像やファイルの入力には安全性確認に伴う例外がある。OpenAIは、APIに送信された画像やファイルを児童性的虐待コンテンツ（CSAM）の検知対象としており、疑わしい内容が検出された場合、ZDRやMAMを有効にしていても、人手による確認のために画像を保持することがある。このため、ZDRを「どのような条件でも、すべてのデータが直ちに消える仕組み」と理解するのは正確ではない。

安全性審査では暗号化したデータを顧客側に保存する仕組みも

OpenAIは2026年8月19日、ZDRと安全性監視を両立させる仕組みとして「Private Safety Processing（PSP）」を発表した。同年9月22日には、API顧客への段階的な提供開始も明らかにしている。PSPは、複数のやり取りにまたがる不正利用の兆候を調べる際にも、OpenAIの担当者が顧客のプロンプトや応答を直接閲覧できないようにすることを目的としている。

ZDRとPSPを組み合わせた方式では、安全性分類器によって審査対象と判定されたやり取りや、承認済みの抽出方式で選ばれたやり取りを暗号化し、顧客が管理するクラウドストレージに保存する。保存期間は30日間で、OpenAI側にはコンテンツのコピーではなく、保存先を参照するための情報と運用メタデータが残る。なお、審査対象として選ばれたこと自体が、利用ポリシー違反を意味するわけではない。

安全性審査では、ハードウェアによる真正性の検証を受けた専用の実行環境で、暗号化されたデータを復号して自動評価する。この環境は人間によるアクセスを無効にする設計となっており、平文で外部に出せるのは、あらかじめ定められた限定的な安全性シグナルと運用情報に限られる。詳細な評価結果は再び暗号化され、顧客側のストレージへ保存される。元の記録と同じ有効期限が適用されるため、安全性審査のために保持されるデータについても、顧客側の保存先と削除設定を確認する必要がある。

また、OpenAIは特定の顧客に対し、事前に書面で通知したうえで、一部のモデルをZDRやMAMの対象外とする場合がある。その際に適用される保持方式の一つが「Private Retention with PSP」だ。この方式では、顧客コンテンツをOpenAI管理の基盤に暗号化された不正利用監視ログとして保存するが、適用法令で求められる場合を除き、人手による審査からは除外する。

もう一つの「Safety Retention」は、重大なリスクを伴う行為の調査や防止に合理的に必要な場合に適用される。利用ポリシーや契約への違反が疑われる内容について、分類器の判定に基づきOpenAIがデータを保持し、人手で確認する可能性がある。それ以外の内容については、従来の保持条件が適用される。これらの方式は通常のZDRとは異なるため、企業は契約や通知内容を確認し、どの保持方針が実際に適用されているかを把握する必要がある。

社内文書を扱うアプリで国内推論をどう活用するか

今回の国内推論対応によって、企業は機密性の高い情報を扱うアプリケーションの構成を見直せるようになる。例えば、社内の問い合わせ内容を要約するだけであれば、アプリケーション側で必要な文章を選び、日本リージョンのResponses APIに送信する構成が考えられる。ZDRを有効にしたうえで、対応モデルとエンドポイントを利用すれば、モデルによる推論処理を国内で実行できる。

一方、社内文書を横断的に検索し、関連資料を参照しながら回答を生成するアプリでは、事情が異なる。こうしたシステムでは、質問を受ける前から文書の原本や検索用インデックスを保管し、必要に応じて過去の会話履歴も維持する。OpenAIのFile Searchなどのホスト型ツールまで利用する構成では、今回の国内推論対応だけで処理全体が日本国内に収まるとは限らない。

国内での処理を重視する場合は、文書の保存と検索を自社の管理環境で行い、検索によって見つかった必要最小限の抜粋だけをGPT-6 Lunaへ送信する構成が選択肢となる。過去の会話を参照する場合も、履歴を自社側に保存し、必要な部分だけをリクエストに含めれば、OpenAI側の会話保存機能に依存せずに文脈を維持できる。ただし、この構成でも、自社側に保存した文書やインデックス、アクセスログについては、保存地域、アクセス権限、削除期限を別途管理しなければならない。

OpenAIの国内推論対応は、モデルへの入力を国外で処理することが導入の障壁となっていた企業にとって重要な前進だ。ただし、国内で推論できることは、アプリケーション全体のデータ処理や保存が国内で完結することを意味しない。実際に重要なのは、文書の取得から検索、モデルへの送信、回答の生成、履歴の保存まで、データの流れを把握することだ。各段階で何が保存され、どの地域で処理され、誰が削除できるのかを明確にすることが、安全な企業向けAIシステムを構築するための基本となる。