# llm-d 1.0、遅延許容処理は余剰容量へ

> llm-d 1.0の分散推論と段階別の更新管理を最初に読む。TorchTPUの公開、AWS Agent Registryの探索と認証、Museの共有停止を取り上げる。Geminiの隔離環境内検索とOctave Relianceの実装も確認し、計算基盤、データの配置、実行権限をそれぞれ見直す。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261021
Published: 2026-10-21T06:30:00+09:00
Category: ai-digest
Tags: infrastructure, llm-inference, open-source, pytorch, aws, agentic-infra, ai-agent, gemini, enterprise-ai, local-inference

llm-d 1.0は、分散推論の段階別スケールと更新管理を扱う。TorchTPUでは、既存PyTorchをTPUへ移す際の開発手順と制約を確認する。AWS Agent Registryの探索と認証、Museの共有停止、Geminiの隔離環境内検索、Octave Relianceの実装は、それぞれデータと権限の境界を見直す材料になる。短報では、カナダからのBedrock利用、x86 CPU向けPyTorch最適化の統合計画、ChatGPTの会話ロックも追う。

判断したいのは、自社のAI運用で計算基盤、データの配置、共有範囲、実行権限のどこを見直すか。各記事は独立した更新・事例だ。llm-dとTorchTPUは計算基盤の選択、Registryは探索と認証の分担、Museは共有リンクの扱い、GeminiとOctave Relianceはデータと権限の境界を検討する材料として並べた。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/) / [出典2](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/) / [出典3](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/) / [出典4](https://www.theverge.com/tech/1014627/meta-muse-ai-sharing-ai-chats) / [出典5](https://cloud.google.com/blog/topics/hybrid-cloud/managed-rag-search-inside-the-sovereign-perimeter-gemini-on-gdc-enterprise-search/) / [出典6](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)）

## llm-d 1.0、TPU・GPUの分散推論と段階別スケールを管理

Googleは、分散[LLM](/guides/llm)推論向けのオープンソースでKubernetesネイティブなスタック、llm-d 1.0をリリースした。llm-dはvLLMやSGLangなどのモデルサーバーの上で、要求の振り分けや実行基盤の管理を担う。自社でモデルを配信するチーム向けに、Google CloudのTPU・GPUプールを共通のエンドポイントにまとめ、キャッシュ済みの文脈を持つレプリカへ要求を振り分ける構成を支える。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/) / [出典2](https://github.com/llm-d/llm-d)）

入力を処理する計算負荷の高いprefillと、出力トークンを生成するメモリ制約の大きいdecodeを別プールに分け、画像などを処理するマルチモーダルのencodeも独立して実行する。大規模な混合エキスパートモデルはノード間に分散できる。1.0の`DisaggregatedSet`はLeaderWorkerSet上に構築され、各段階を個別にスケールさせながら、ローリング更新ではprefillとdecodeのバージョンをそろえて管理する。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/)）

文脈を再利用するための計算結果を保持するKVキャッシュは、アクセラレータのメモリが埋まった際にホストメモリへ、さらにSSDやGoogle Cloud Managed Lustreへ退避する構成を支える。これにはvLLMのOffloadingConnector、Mooncake、SGLangのHiCacheなどを使い、TPUとGPUの混在構成も対象に含む。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/)）

遅延を許容できる処理には、1.0で導入されたllm-d-async-processorを使う。Pub/SubやRedisなどのキューから要求を取り込み、利用可能な容量、優先順位、クォータを確認してリアルタイム要求と共存させる。バックグラウンド処理は余剰容量で実行する設計だ。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/)）

導入は全コンポーネントの一括採用を前提とせず、既存のエンジン、モデル、クラスターに必要な部分だけを組み込める。Google Cloud向け構成では、検証済みHelmチャートでTPU・GPUプールを展開する。プロジェクトはベンチマーク済みの構成例も提供するが、ガイドは随時更新されるため、チャートとコンポーネントのリリース詳細はリリースノートを参照するよう案内している。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/) / [出典2](https://github.com/llm-d/llm-d)）

> [!CAUTION] 分離推論は構成ごとの要件を照合
> 公式の分離推論ガイドは、アクセラレータと推論エンジンごとに検証済み構成とコミュニティ管理構成を区別している。prefillとdecode間ではKVキャッシュの転送が必要で、本番向けにはRDMAネットワークを強く推奨する。機種、転送方式、LeaderWorkerSetの要件を、採用するリリースの構成に合わせて確認したい。（[公式構成ガイド](https://llm-d.ai/docs/well-lit-paths/foundations/pd-disaggregation)）

**EastBraverの見立て:** 採用判断の軸は、既存の配信基盤にどの運用機能を足すかにある。段階別の容量調整と、prefill・decodeの整合した更新を両立させたいチームには、DisaggregatedSetが具体的な検討対象になる。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/)）

- 出典: [Google Cloud](https://cloud.google.com/blog/topics/ai-infrastructure/llm-d-1-0-an-open-source-stack-for-distributed-inference/)（公式情報、ページ公開メタデータは2026-10-21 03:30 JST）

## TorchTPUをオープンソース公開、既存PyTorchをTPUへ

Googleは、MetaのPyTorchチームと共同開発したTPU向けネイティブPyTorchスタック「TorchTPU」をGitHubでオープンソース公開した。PyTorchの実行先として、GPUやCPUに加えてTPUをネイティブに選べるようにする。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/)）

Googleによると、既存のPyTorchワークロードは、使い慣れたAPIと最小限のコード変更でTPUへ移せる。開発時は演算を逐次実行するeagerモードでデバッグし、その後`torch.compile`でTPU利用率とメモリ使用を最適化する流れを想定している。ただし、PyTorchの技術解説は、単純な実行先の変更だけではTPUの最高性能を引き出せず、テンソルの形状、分割方法、演算の調整が必要になり得ると説明する。（[Google Cloudの発表](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/) / [PyTorchの技術解説](https://pytorch.org/blog/introducing-torchtpu/)）

ライブラリ側にも具体的な対応がある。Googleによると、Transformers v5では`device_map="tpu"`でTPUへの配置を指定できる。DiffusersはTPU上でネイティブに動作し、eagerモード、`torch.compile`、複数のアクセラレーターに処理を分散するテンソル並列をサポートする。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/)）

推論配信では、TorchTPU向けvLLMバックエンドが連続バッチ処理、量子化、複数チップでの並列処理に対応する。Googleは、上流のワーカー、スケジューラー、APIサーバーを維持するため、既存の推論スタックを変更せずに利用できると説明している。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/)）

学習側では、GoogleはTorchTitanにTorchTPUを統合し、`torch.compile`、SimpleFSDP、専用Pallasカーネル、グラフ単位の最適化を組み合わせた分散学習に対応すると説明している。一方、VeRL連携はプレビューだ。既存コードを維持できるという説明も、数学推論データセット向けGRPO参照レシピにおける、ハードウェア非依存のコードについてのものだ。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/)）

> [!CAUTION] 動的形状と分散初期化には制約
> PyTorchの技術解説によると、上限を定めた動的形状への対応は開発中で、`torch.compile`では一時的な制約として`dynamic=False`が設定される。分散実行にはTPUのトポロジーと接続先の設定も必要になる。既存コードが動くことと、GPU向けの形状・分散設定をそのまま最適に使えることは別だ。（[PyTorchの技術解説](https://pytorch.org/blog/introducing-torchtpu/)）

**EastBraverの見立て:** 移行価値を判断する軸は、TPUで動くことに加え、既存の開発・配信手順をどこまで維持できるかにある。使い慣れたAPIとvLLMの運用構成を引き継げるという説明は、移行時の変更範囲を見積もる手掛かりになる。（[出典1](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/)）

- 出典: [Google Cloud](https://cloud.google.com/blog/topics/ai-infrastructure/torchtpu-is-now-open-source-run-native-pytorch-on-tpus/)（公式情報、ページ公開メタデータは2026-10-21 03:30 JST） / [PyTorch](https://pytorch.org/blog/introducing-torchtpu/)（公式技術解説、2026-10-20）

## AWS Agent Registry、承認済みの機能を実行時に探索、呼び出し認証は別途

AWSは、AWS Agent Registryを使い、承認済みの機能を実行時に探して呼び出す実装例を公開した。Registry自体は8月に正式提供済みで、今回がサービスの初公開ではない。[MCP](/guides/mcp)サーバー、エージェント、エージェントスキルなどを登録するマネージドサービスであり、検索結果の接続先と記述子からクライアントを構築できる。ただし、呼び出し用の認証情報や認証方式は返さず、アプリケーションが別の信頼できる設定経路から取得・適用する必要がある。（[AWSの実装解説](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)）

公開者は、検索可能な説明とプロトコル固有の記述子を登録する。登録には`recordType`が必須で、記事のサンプルではMCPサーバーに`MCP`、エージェント間通信のA2Aに対応したエージェントに`AGENT`を指定する。`descriptors`内の`mcpServer`にはサーバーメタデータとツール定義を、`a2aAgentCard`にはエージェントカードを格納し、探索後の接続に必要な情報を持たせる。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)）

自動承認を無効にした構成では、新規レコードを`DRAFT`から`PENDING_APPROVAL`、`APPROVED`へ移す必要がある。承認申請と状態更新はIAMによる認可を受け、公開者と承認者の権限を分離できる。探索用データプレーンが返すのは承認済みレコードだけであり、登録しただけでは探索対象にならない。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)）

探索用データプレーンは、キーワード検索と意味検索を組み合わせたハイブリッド検索を提供する。記事のサンプルでは、検索結果の記述子からMCPまたはA2Aクライアントを生成し、そのリクエストで見つかった機能だけを持つ内部エージェントを構築する。探索結果が、その処理で利用する機能の構成につながる。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)）

> [!CAUTION] 探索の認可と呼び出し先の認証を混同しない
> 公式IAM資料は、承認済みレコードの検索に`agent-registry:SearchDiscoverableRegistryRecords`を示している。RegistryのMCPエンドポイントを使う場合は`agent-registry:InvokeRegistryMcp`も必要になる。これらはRegistryを利用する権限であり、検索で見つかったツールやエージェントを呼び出す認証情報ではない。（[公式IAM資料](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-iam-permissions.html)）

**比較表: 記事のサンプルにおける接続先と呼び出し認証**

MCPとA2Aでは接続先も認証方法も異なる。いずれもRegistryの探索結果だけでは呼び出し認証は完結しない。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)）

| 観点 | MCP | A2A |
| --- | --- | --- |
| 記述子が示す接続先 | Amazon Bedrock AgentCore Gatewayの接続先を示す。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)） | エージェントカードのURLがAgentCore runtimeの接続先を示す。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)） |
| 呼び出し時の認証 | 別途取得したCognito OAuthアクセストークンを使い、Gatewayへの着信をCognito JWTで認可する。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)） | ラッパーがBoto3のデータプレーンクライアントを使い、呼び出し元のAWS認証情報で署名する。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)） |

**EastBraverの見立て:** 探索対象への承認と、接続先を呼び出すための[認証・認可](/guides/ai-identity-authorization)は別の判断になる。Registryで公開者と承認者を分離しても、実行時の認証情報を渡す経路はアプリケーション側の設計として残る。（[出典1](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)）

- 出典: [AWS](https://aws.amazon.com/blogs/machine-learning/discover-tools-at-runtime-with-aws-agent-registry/)（公式情報、2026-10-21 01:22 JST）

## Meta、Museの会話共有を一時停止、公開DNS記録からリンク発見

MetaはMuseのリンク共有機能を一時停止した。The Vergeが掲載したMeta広報担当者の声明によると、特定の成果物を共有すると、リンクを持つ人がアクセスできるページが作られる。報告を精査し、リンクの発見方法の変更を検討する間、この機能を停止したという。（[出典1](https://www.theverge.com/tech/1014627/meta-muse-ai-sharing-ai-chats)）

Clarocが10月18日に公表した調査では、パッシブDNSの記録から6,800件超のMuse共有ホスト名が見つかった。Clarocによると、共有URLは会話を説明するタイトルとランダムなIDで構成され、DNS記録で得たホスト名からリンクを再構成できた。ホスト名自体からページ内容を推測できる場合もあった。今回の新たな動きは、この調査を受けたMetaの共有停止である。（[Clarocの調査と10月20日更新](https://blog.claroc.io/ghostshares-muse-passive-dns/) / [Metaの声明を伝えたThe Verge](https://www.theverge.com/tech/1014627/meta-muse-ai-sharing-ai-chats)）

The Vergeによると、Clarocが閲覧できた会話には、マーケティング会社の売上レビュー、小規模事業者の融資申請、職場の年間スタッフ予定表などが含まれていた。（[出典1](https://www.theverge.com/tech/1014627/meta-muse-ai-sharing-ai-chats)）

> [!CAUTION] 40件の再確認は全リンクの失効を保証しない
> Clarocは10月20日の更新で、以前は未ログインで開けた40件を再確認し、いずれも開けず、コンテンツ配信先のホスト名がエラーを返したと報告した。一方、タイトルを含むホスト名はパッシブDNSの履歴に残る。この結果を全共有ページの失効や、既に外部へ渡った情報の回収と読み替えない。（[Clarocの更新](https://blog.claroc.io/ghostshares-muse-passive-dns/)）

**EastBraverの見立て:** この事案では、リンクを持つ人が閲覧できるという共有条件と、そのリンクを第三者が発見できる経路を分けて捉える必要がある。ランダムなIDがあっても、DNS記録からリンクを再構成できる設計では、発見しにくさを共有範囲の根拠にはできない。（[出典1](https://www.theverge.com/tech/1014627/meta-muse-ai-sharing-ai-chats)）

- 出典: [The Verge](https://www.theverge.com/tech/1014627/meta-muse-ai-sharing-ai-chats)（Metaの声明を含む二次報道、2026-10-21 03:07 JST） / [Claroc](https://blog.claroc.io/ghostshares-muse-passive-dns/)（調査原文は2026-10-18、共有停止後の再確認は10月20日更新）

## Geminiの企業内検索、GDC air-gapped内で検索と生成を完結

Google Cloudは、Google Distributed Cloudの物理的な隔離環境であるGDC air-gapped上で、Geminiによる企業内検索をプレビューで発表した。フルマネージドの[RAG検索](/guides/rag)として提供し、物理的なセキュリティ境界内だけで動作する。公開インターネットやGoogle Cloudのグローバル基盤には接続しないとしている。（[出典1](https://cloud.google.com/blog/topics/hybrid-cloud/managed-rag-search-inside-the-sovereign-perimeter-gemini-on-gdc-enterprise-search/)）

アップロードしたファイルはローカルのオブジェクトストレージに保存され、分割と埋め込み処理を経て、同じGDC環境内のPostgreSQLにベクトルとして格納される。質問は会話の文脈を使って書き直され、埋め込み処理後にベクトル検索へ進む。検索で一致したデータ、質問、会話履歴を同じ環境内のGeminiエンドポイントに送り、参照ファイルの引用付きで回答を返す。Google Cloudによると、文書、埋め込み、質問、回答はいずれも組織の隔離ネットワークから出ない。（[出典1](https://cloud.google.com/blog/topics/hybrid-cloud/managed-rag-search-inside-the-sovereign-perimeter-gemini-on-gdc-enterprise-search/)）

アクセスには組織のIDプロバイダーを使う。管理者が利用者ロールに対応付けたグループのメンバーだけがアプリケーションを利用でき、各利用者のチャットとアップロードファイルは、その利用者専用となる。（[出典1](https://cloud.google.com/blog/topics/hybrid-cloud/managed-rag-search-inside-the-sovereign-perimeter-gemini-on-gdc-enterprise-search/)）

> [!CAUTION] 確認できていない点
> プレビューの利用対象と申込条件は発表では示されていない。料金は発表では示されていない。提供地域は発表では示されていない。

**EastBraverの見立て:** 導入評価では、組織の隔離境界内で検索と生成を完結できる点と、資料の利用範囲が利用者ごとに閉じる点を分けて捉える必要がある。企業内検索という名称でも、今回示された利用形態は各利用者がアップロードした資料を扱うものだ。（[出典1](https://cloud.google.com/blog/topics/hybrid-cloud/managed-rag-search-inside-the-sovereign-perimeter-gemini-on-gdc-enterprise-search/)）

- 出典: [Google Cloud](https://cloud.google.com/blog/topics/hybrid-cloud/managed-rag-search-inside-the-sovereign-perimeter-gemini-on-gdc-enterprise-search/)（公式情報、ページ公開メタデータは2026-10-21 02:00 JST）

## Octave Reliance、Bedrock上でデータ境界と実行権限を多層に分離

AWSブログのOctave事例記事によると、Octave Relianceは顧客ごとにテナントを分け、ベクトルストア、検索処理、生成コンテキストを各テナントに限定する設計を採用した。埋め込み済み文書をAmazon OpenSearch Serviceのテナント別ベクトルストアに格納し、検索から生成に渡す情報まで顧客単位の境界を設けている。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)）

同記事によると、実行時の分離はアプリケーション層より下のAgentCore Runtimeが担う。ユーザーセッションごとに専用のCPU、メモリ、ファイルシステムを持つmicroVMを割り当て、終了時に停止して残存データを消去する。[利用者のIDと権限](/guides/ai-identity-authorization)は実行チェーン全体で引き継ぎ、ユーザー別OAuthトークン保管庫を使って本人の代理として動作させる。認証情報はエージェントごとに範囲を限定してセッション中だけ有効とし、AgentCore Gatewayがツール、操作、パラメータの各レベルで認可する。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)）

苦情処理では、ApplyGuardrail APIによる検査を情報の受け渡しに配置した。添付ファイルの抽出テキストは埋め込み前に、検索文書とツール出力はエージェントのコンテキストに入る前に、生成要約は担当者への提示前に検査する。添付由来の内容には指示ではなくデータとしてタグ付けし、入力時に個人識別情報をマスキングする。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)）

検査に加えて、AgentCore Gatewayが呼び出せるツールを制限する。文書抽出はAgentCore Code Interpreterの[サンドボックス](/guides/sandbox)で実行し、外向きネットワーク通信を許可せず、セッションを超えてデータを永続化しない。この通信・永続化の制限は、文書抽出用サンドボックスについての構成である。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)）

データ所在地も構成の前提になっている。同事例では、顧客データを推論時も含めて所在するAWSリージョンから出さないことを要件とし、埋め込みモデルを同じリージョン内で利用できることを選定条件にした。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)）

**EastBraverの見立て:** この事例の要点は、テナント単位の情報境界、セッション単位の実行分離、ユーザー単位の権限を組み合わせている点にある。構成を評価する際も、microVMの分離だけで判断せず、検索・生成コンテキストと認可の境界を併せて捉える必要がある。（[出典1](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)）

- 出典: [AWS](https://aws.amazon.com/blogs/machine-learning/how-octave-built-a-secure-multi-tenant-ai-foundation-on-amazon-bedrock/)（公式情報、2026-10-21 02:34 JST）

## ほかの確認済みの更新

本文と同じ方法で根拠を確認した更新を、要点だけ短くまとめる。

- **BedrockのOpenAI GPTがカナダから利用可能に、処理先はプロファイルで変わる**：Amazon Bedrockのクロスリージョン推論により、Canada (Central)とCanada West (Calgary)からOpenAI GPTを利用できるようになった。対象はGPT-5.6のSol・Terra・Luna、GPT-6のAstra・Sol・Luna、GPT-6.1 Sol。`us.`プロファイルはカナダと米国、`global.`は対応する商用リージョンへ処理を振り分ける。呼び出し元がカナダでも国内処理の保証にはならず、導入前に有効なプロファイルと処理先を確認したい。（[AWSの発表](https://aws.amazon.com/blogs/machine-learning/access-openai-gpt-models-on-amazon-bedrock-from-canada-with-cross-region-inference/)）
- **AMDとIntelがPyTorchのx86最適化をoneDNNへ統合する計画**：両社は、x86 CPU向けの既定のオープンソース最適化ライブラリとしてoneDNNを使う方針を発表した。AMDはZenDNNの最適化をoneDNNへ統合中で、UXL Foundationの運営メンバーにも加わった。これは共通のソフトウェア経路へ寄せる計画であり、すべてのCPU構成で移行や高速化が完了したという発表ではない。（[AMDの共同発表](https://newsroom.amd.com/news/amd-intel-collaborate-simplify-ai-development-on-x86-cpus-pytorch/)、2026-10-21 00:52 JST）
- **ChatGPTが会話ロックを段階提供、保存・学習設定は変わらない**：OpenAIはFree・Go・Plus・Pro向けに、選んだ会話を通常の履歴、固定表示、検索から隠すLocked chatsの段階提供を発表した。4桁のアカウントPINか対応する端末認証で開く。画面を他人に見せる際の制御であり、会話の保存期間やモデル改善への利用設定は変わらない。（[OpenAIの10月20日リリースノート](https://help.openai.com/en/articles/6825453-chatgpt-release-notes)）