# GPT-6とIntelligent UIがChatGPTへ、WorkとCodexは変更なし

> GPT-6とIntelligent UIのChatGPT向け段階提供を軸に、Work・Codexとの変更範囲の違いを整理。MicrosoftのAgent実行隔離、RAGのACLと本人認証の分担、Azureの文書処理選定、Claude Haiku 5.5のAWS提供条件、LiquidAI d1の実行条件を確認する。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261008
Published: 2026-10-08T06:30:00+09:00
Category: ai-digest
Tags: ai-agent, open-source, infrastructure, model-ops, safety, evaluation, amazon-bedrock, aws, enterprise-ai, governance

OpenAIが、GPT-6とIntelligent UIをChatGPTのChatタブへ段階的に提供する。対話中に図やフォームを組み立てる更新であり、WorkやCodexのモデル変更とは別だ。続いて、Microsoft Execution Containersの一般提供、Amazon QuickとBedrockのRAG権限確認、Azureの文書処理の選定基準を取り上げる。Claude Haiku 5.5のAWS提供とLiquidAI d1のオープンウェイト公開は、それぞれクラウドと端末でのモデル選択を広げる。

今日の判断軸は、変更される製品の範囲、操作を制限する実行環境、参照データの権限、利用先の条件を分けて確認することだ。各更新は独立している。ChatGPTの提供拡大を自社APIの変更と取り違えず、Agentには外側からの実行制御を、RAGには利用者の本人認証と文書権限の確認を組み合わせたい。（[出典1](https://openai.com/index/gpt-6-for-everyone/) / [出典2](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) / [出典3](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.md)）

## GPT-6とIntelligent UI、ChatGPTのChatタブへ段階提供

OpenAIは10月7日、GPT-6とIntelligent UIをChatGPTへ段階的に提供すると発表した。Plus、Pro、Business、Enterpriseは発表当日から、FreeとGoは翌日から展開する予定で、Enterpriseの利用可否は職場の管理者設定に依存する。すべての利用者への提供完了を示す発表ではない。（[出典1](https://openai.com/index/gpt-6-for-everyone/)）

Intelligent UIでは、回答にテキストだけでなく図、ボタン、フォーム、グラフ、対話型の体験を組み込める。OpenAIは、モデルが生成する途中から画面を表示できるコンポーネントライブラリとコンパイラーを構築したと説明する。必要に応じて、会話の中に計算ツールなどを作る用途も示している。（[出典1](https://openai.com/index/gpt-6-for-everyone/)）

ChatGPTでは、Plus、Pro、Business、EnterpriseにGPT-6 Sol、FreeとGoにGPT-6 Lunaを用い、どちらも日常の対話向けに調整する。この更新の対象はChatの体験であり、WorkとCodexを動かすモデルは変更しない。APIの新モデル提供や既存システムの自動移行を、この発表から読み取るべきではない。（[出典1](https://openai.com/index/gpt-6-for-everyone/)）

**比較表: 今回の提供範囲とモデル**

利用プランによってモデルと展開開始日が異なる。WorkとCodexは、この更新に含まれない。（[出典1](https://openai.com/index/gpt-6-for-everyone/)）

| 観点 | Plus・Pro・Business・Enterprise | Free・Go |
| --- | --- | --- |
| Chatのモデル | 日常の対話向けに調整したGPT-6 Sol。（[出典1](https://openai.com/index/gpt-6-for-everyone/)） | 日常の対話向けに調整したGPT-6 Luna。（[出典1](https://openai.com/index/gpt-6-for-everyone/)） |
| 展開開始 | 発表当日から段階提供。Enterpriseは管理者設定に依存する。（[出典1](https://openai.com/index/gpt-6-for-everyone/)） | 発表翌日から段階提供する予定。（[出典1](https://openai.com/index/gpt-6-for-everyone/)） |

**EastBraverの見立て:** 今回の評価対象は、会話中に提示されるUIの分かりやすさと業務での利用可否だ。[LLMの選定](/guides/llm)では、ChatGPTの体験更新とAPI・Work・Codexの実行条件を分けて判断したい。新しいUIが表示されることだけで、既存Agentのモデルや権限が変わったとは扱わない。（[出典1](https://openai.com/index/gpt-6-for-everyone/)）

- 出典: [OpenAI](https://openai.com/index/gpt-6-for-everyone/)（公式情報、2026-10-07 09:00 JST）

## Microsoft Execution Containers、Agentの実行隔離を一般提供

Microsoftは、Microsoft Execution Containers（MXC）とWindows 365でのMXC対応が一般提供に入ったと発表した。MXCは、信頼できないコードや動的に生成された処理を、開発者や組織が定めたポリシーの範囲で実行する基盤である。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)）

ファイル、ネットワーク、デスクトップなどの利用条件はAgent自身の外側に置く。統一されたJSON設定とSDKで必要なリソースを宣言し、各OSの隔離機構へ対応付けるため、モデルや生成コードが自分で権限を追加する構成にはしない。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)）

| 実行方式 | 対応環境 | 主な境界 |
| --- | --- | --- |
| Process container | Windows 11、macOS、Linux | AppContainer、Seatbelt、Bubblewrapなど、OSに応じたプロセス隔離を使う。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)） |
| Session container | Windows 11のみ | 別のアカウントとセッションで動かし、デスクトップ、クリップボード、UI、入力を利用者から分離する。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)） |
| WSL container | Windows 11のみ | Linux向けのツールチェーンをWSL環境で動かす。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)） |
| MicroVM | Windows 11とLinux、実験段階 | ハードウェアに支えられた仮想化でLinuxの処理を隔離する。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)） |

WindowsのProcess containerでは、許可していないアクセスを遮断して記録するLearningモードと、アクセスを許可して記録するPermissiveモードを使ってポリシーを調整できる。Learningは制限を維持するが、PermissiveはMXCのポリシーによる遮断を行わない。Microsoft EntraとAgent 365によるAgentの識別、Intuneによる管理は今後の対応であり、一般提供済みの機能とは分ける必要がある。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)）

**EastBraverの見立て:** [Sandboxの選定](/guides/sandbox)では、対応OSと必要な操作を先に決め、実行方式ごとの隔離範囲を確認したい。Agentに「触らないよう指示する」ことと、OS側でアクセスを制限することは別だ。一般提供という製品全体の状態だけで、実験段階のMicroVMや今後の管理機能まで利用可能とは扱わない。（[出典1](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)）

- 出典: [Microsoft](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)（公式情報、2026-10-08 03:00 JST）

## Amazon QuickとBedrockのRAG権限確認をAWSが解説

AWSは、Amazon QuickとAmazon Bedrock Knowledge Basesで、文書単位のアクセス権を二段階で確認する仕組みを解説した。索引に保存したアクセス制御リスト（ACL）で検索候補を絞り、対応するデータソースでは、候補文書への権限を問い合わせ時に元のサービスで再確認する。今回の解説は、すべてのKnowledge Baseや接続先への一律適用、または機能の初回提供日を示すものではない。（[出典1](https://aws.amazon.com/blogs/machine-learning/rethinking-access-control-for-rag-with-amazon-quick-and-amazon-bedrock/) / [出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.md)）

Amazon Quickの管理者設定によるGoogle Drive接続の例では、サービスアカウントを使って利用者として代理実行するためのトークンを発行し、Google Drive APIで候補文書へのアクセスを確認する。権限のない文書を除外し、確認済みの文書の該当箇所をLLMへ渡す。これは取得した文書を絞る仕組みであり、モデルの回答が持つあらゆる情報を限定する保証ではない。（[出典1](https://aws.amazon.com/blogs/machine-learning/rethinking-access-control-for-rag-with-amazon-quick-and-amazon-bedrock/)）

Bedrock Managed Knowledge Baseの公式資料は、ACLに基づく検索結果の絞り込みを、本人認証や独立した認可境界とは区別している。アプリ側で利用者を認証し、データソースと一致する検証済みのメールアドレスを`userContext`として渡す必要がある。ACLを有効にしていないデータソースの文書は、このフィルターでは制限されない。（[出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.md) / [出典3](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve-acl.md)）

Bedrockのリアルタイム確認はSharePoint、OneDrive、Google Drive、Confluenceなどの対応コネクターに限られ、S3とCustomでは行われない。また、外部の認証基盤の認証情報を最長1時間キャッシュし、権限変更の反映には結果整合性による遅延がある。問い合わせ時の再確認を、変更が即時かつ一律に反映される保証とは扱えない。（[出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.md) / [出典3](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve-acl.md)）

**EastBraverの見立て:** [RAGの設計](/guides/rag)では検索精度だけでなく、[利用者の本人認証](/guides/ai-identity-authorization)と文書権限のフィルターを別の層として確認したい。ACL確認に失敗すると対象文書が返らない挙動や、権限変更・認証情報キャッシュの反映遅延も運用条件になる。（[出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.md) / [出典3](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve-acl.md)）

- 出典: [AWS](https://aws.amazon.com/blogs/machine-learning/rethinking-access-control-for-rag-with-amazon-quick-and-amazon-bedrock/)（公式解説、2026-10-08 03:34 JST）

## ADIとACU、抽出処理と配備条件で選ぶ

Microsoftは、Azure Document Intelligence（ADI）とAzure Content Understanding（ACU）の選定ガイドを公開した。既存のADI処理が本番要件を満たすなら、一律に移行する必要はない。文書カテゴリだけで決めず、必要項目と運用制約を定め、同じ代表文書群で比較するという指針だ。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)）

新規のクラウドOCR・レイアウト解析では、ACUの`prebuilt-read`と`prebuilt-layout`から評価を始めるよう推奨している。両解析器は専用のOCR・レイアウトモデルを使い、言語モデルや埋め込みモデルを必要としない。生成モデルによる抽出という説明は、サービス全体ではなくフィールド抽出の方式を指す。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)）

| 観点 | ADI | ACU |
| --- | --- | --- |
| フィールド抽出 | 特化型文書モデルで、視覚的・二次元的な関係を学習する。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)） | 生成モデルとフィールドスキーマに基づいて抽出する。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)） |
| 評価の起点 | 構造のばらつきが限定的で、必要な値が明記され、代表的なラベル付きサンプルがある処理。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)） | 構造や言語のばらつきが大きい文書、文書内の複数箇所を照合する項目、ラベルなしで始める処理。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)） |
| 配備 | コンテナーで実行できる。接続型はAzureへの課金通信を必要とし、エアギャップには切断型の承認、コミットメントプラン、ライセンスファイルが必要となる。（[出典2](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/containers/disconnected?view=doc-intel-4.0.0)） | クラウドで文書、画像、音声、動画、RAG向け前処理を扱う。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)） |

複雑な反復推論にはACUの`agentic mode`があるが、プレビュー段階であり、初期版は1リクエストにつき1入力ファイルに制限される。単純なフィールド抽出の既定にする機能ではない。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/) / [出典3](https://learn.microsoft.com/en-us/azure/ai-services/content-understanding/concepts/agentic-mode)）

**EastBraverの見立て:** 表は厳密な二分境界ではなく、評価候補を絞るための起点である。Microsoftの推奨は内部ベンチマークに基づくため、[RAG向けの文書処理](/guides/rag)でも、実際の入力と業務の成功条件で精度、遅延、費用、配備制約を照合したい。（[出典1](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)）

- 出典: [Microsoft Foundry Blog](https://devblogs.microsoft.com/foundry/choosing-azure-document-intelligence-and-content-understanding/)（公式の選定ガイド、2026-10-08 03:45 JST）

## Claude Haiku 5.5、AWSの提供経路と料金条件を確認

Claude Haiku 5.5が、Amazon BedrockとClaude Platform on AWSで提供開始された。AWSは、コーディング、ツール利用、コンピューター利用、Agentによる処理でHaiku系列中もっとも高性能で、思考量を調整する`effort`設定を備えた初のHaikuモデルだと説明する。Haiku 4.5より大半のタスクで約75％低コストという説明はAnthropicによるものであり、全リクエストの料金が一律75％下がるという意味ではない。（[出典1](https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/)）

`effort`は`low`、`medium`、`high`、`xhigh`、`max`の5段階で、既定値は`medium`である。思考は既定で有効となり、無効にした場合の`effort`は`high`までに制限される。思考トークンは出力トークンとして課金され、設定ごとに固定のトークン数や割引率が保証されるわけではない。（[出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-haiku-5-5.html) / [出典3](https://platform.claude.com/docs/en/build-with-claude/thinking-steering-and-cost)）

Amazon Bedrockの`bedrock-runtime`では、US、EU、AU、JPのGeo CRISとGlobal CRISを利用できる。JPの`jp.anthropic.claude-haiku-5-5`は東京・大阪から利用でき、処理先も東京・大阪である。GlobalはGeoとは別の分類であり、地域内に処理先を固定する経路として扱ってはいけない。（[出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-haiku-5-5.html)）

以下はレビュー時点の公開料金から確認した、東京リージョンでのBedrock標準料金の例である。金額は1,000,000トークン当たりの米ドルで、キャッシュの料金は含めない。入力長の区分はAnthropicの公開仕様に基づき、GlobalとJP Geoの料金を分けている。（[Bedrock料金](https://aws.amazon.com/bedrock/pricing/) / [入力長による料金区分](https://platform.claude.com/docs/en/about-claude/pricing)）

| 推論経路 | 入力長 | 入力料金 | 出力料金 |
| --- | --- | ---: | ---: |
| Global CRIS | 100,000トークン以下 | 0.10 | 0.50 |
| Global CRIS | 100,000トークン超 | 0.50 | 2.50 |
| JP Geo CRIS | 100,000トークン以下 | 0.11 | 0.55 |
| JP Geo CRIS | 100,000トークン超 | 0.55 | 2.75 |

GovCloudでは、`bedrock-runtime`がEast・WestのGeoに対応する一方、`bedrock-mantle`のIn-Region対応はWestに限られる。掲載された開始手順は、BedrockへアクセスできるAWSアカウントと、モデル呼び出し・ストリーミング呼び出しのIAM権限を前提とする。（[出典1](https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/) / [出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-haiku-5-5.html)）

Claude Platform on AWSについては、AWSの発表が北米での提供と案内している。同サービスのワークスペースやエンドポイントの地域を、Haikuの実際の処理拠点と同一視しないことも必要だ。（[出典1](https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/) / [プラットフォームの地域・認証条件](https://platform.claude.com/docs/en/build-with-claude/claude-platform-on-aws)）

**EastBraverの見立て:** 対応リージョン、料金、`effort`設定は公開済みであり、「不明」として扱うべき条件ではない。[AIシステムの本人認証と認可](/guides/ai-identity-authorization)を設計する際は、GeoとGlobalの処理範囲、入力長による価格差、GovCloudの東西差、利用アカウントのアクセス条件を分けて確認したい。（[出典2](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-haiku-5-5.html)）

- 出典: [AWS](https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/)（公式情報、2026-10-08 03:52 JST）

## Liquid AI、分類・判定向けd1の2モデルを公開

Liquid AIは、オープンウェイトの`d1-3B`と実験的な`d1-omni-600M`を公開した。両モデルは自由文を生成するチャットモデルではなく、1回の順伝播計算で真偽判定、選択肢、スコアなどの型付き判定を返す。（[出典1](https://huggingface.co/blog/LiquidAI/open-d1) / [d1-3Bモデルカード](https://huggingface.co/LiquidAI/d1-3B) / [d1-omni-600Mモデルカード](https://huggingface.co/LiquidAI/d1-omni-600M)）

`d1-3B`はLFM2.5-VL-3Bを基盤にテキストと画像を扱う。`d1-omni-600M`は350Mの双方向エンコーダー系基盤に視覚・音声エンコーダーを加えた初期研究リリースで、画像と音声を同時には入力できない。音声は英語話者と助手のリクエストで学習しており、最大30秒に切り詰められる。（[出典1](https://huggingface.co/blog/LiquidAI/open-d1) / [音声の条件](https://huggingface.co/LiquidAI/d1-omni-600M)）

発表ブログの7つの公開テキストデータセット評価と、`d1-3B`モデルカードの画像評価を分けて示す。いずれもLiquid AIの報告値であり、独立追試の結果ではない。モデルカードにある別の8データセット評価と、ブログの7データセット平均を混ぜない。（[出典1](https://huggingface.co/blog/LiquidAI/open-d1) / [d1-3Bの評価](https://huggingface.co/LiquidAI/d1-3B)）

| Liquid AIの評価 | d1-3B | d1-omni-600M | Decider 2B |
| --- | ---: | ---: | ---: |
| 発表ブログの7テキストデータセット平均 | 82.9 | 78.4 | 77.1 |
| d1-3Bカードの11公開画像ベンチマーク平均 | 74.1 | 当該比較には未掲載 | 当該比較には未掲載 |

両モデルのベース重みは`safetensors`形式で公開されている。公式GGUFには`d1-3B`の`Q4_K_M`・`Q8_0`と、`d1-omni-600M`の`Q8_0`があり、画像や音声には対応するメディア処理用のprojectorも必要となる。配布ファイルのサイズを、そのまま必要RAM・VRAMとは扱えない。（[d1-3B配布](https://huggingface.co/LiquidAI/d1-3B/tree/main) / [d1-omni-600M配布](https://huggingface.co/LiquidAI/d1-omni-600M/tree/main) / [d1-3B GGUF](https://huggingface.co/LiquidAI/d1-3B-GGUF/tree/main) / [d1-omni-600M GGUF](https://huggingface.co/LiquidAI/d1-omni-600M-GGUF/tree/main)）

ライセンスはLFM Open License v1.0で、年商1,000万米ドルの閾値に基づく商用利用制限がある。再配布時にはライセンスの添付や改変表示などの条件もあるため、オープンウェイト公開を無制限の商用利用許可と読み替えない。（[d1-3Bライセンス](https://huggingface.co/LiquidAI/d1-3B/resolve/main/LICENSE) / [d1-omni-600Mライセンス](https://huggingface.co/LiquidAI/d1-omni-600M/resolve/main/LICENSE)）

Transformersでの実行要件は、`d1-3B`が`transformers>=5.14`、`d1-omni-600M`が`transformers>=5.15`となる。両方の例で`AutoModel.from_pretrained`に`trust_remote_code=True`を指定し、リポジトリ独自のコードを読み込む。omniはGPUで`float16`、CPUで`float32`を推奨し、判定が変わる例がある`bfloat16`は避けるよう案内している。（[d1-3Bの実行条件](https://huggingface.co/LiquidAI/d1-3B) / [d1-omni-600Mの実行条件](https://huggingface.co/LiquidAI/d1-omni-600M)）

> [!CAUTION] 速度値と実機要件の境界
> d1-3Bの端末・GPU評価はウォームアップ後のモデル処理時間であり、端末別のピークRAM・VRAMやエンドツーエンド遅延の保証ではない。今回確認した発表とモデルカードには、d1-omni-600Mの速度値と音声ベンチマーク値が示されていない。（[出典1](https://huggingface.co/blog/LiquidAI/open-d1) / [d1-3B](https://huggingface.co/LiquidAI/d1-3B) / [d1-omni-600M](https://huggingface.co/LiquidAI/d1-omni-600M)）

**EastBraverの見立て:** 型付き判定を返す方式は、[Agentの分類・ルーティングや検査](/guides/ai-agent)の候補となる。端末選定では量子化形式、projector、入力長、実メモリーを確認し、音声用途ではomniの英語学習と30秒制限を判断条件に含めたい。日本語音声の実用品質まで確認済みとは扱わない。（[d1-3B](https://huggingface.co/LiquidAI/d1-3B) / [d1-omni-600M](https://huggingface.co/LiquidAI/d1-omni-600M)）

- 出典: [Liquid AI（Hugging Face）](https://huggingface.co/blog/LiquidAI/open-d1)（公式情報、2026-10-08 01:54 JST）

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

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

- **ChatGPT for TeensにCommon Sense Mediaが「許容できないリスク」評価**：同団体は保護者通知などの保護策が約束を満たさないと評価した。OpenAIは通知機能の有効化時期を踏まえた試験方法に異議を示し、CSMは必要とされる時間を過ぎたアカウントでも通知が届かなかったと反論した。評価結果と双方の応答を区別して読む必要がある。（[出典1](https://institute.commonsensemedia.org/risk-assessments/chatgpt-teens) / [出典2](https://www.theverge.com/ai-artificial-intelligence/1006355/openai-chatgpt-for-teens-common-sense-media)）
- **SynthID Detectorを世界の一般利用者へ提供**：Googleは、対応するAIで作られた画像、動画、音声のSynthID透かしを確認するツールを、英語で世界向けに公開した。GoogleのほかOpenAI、NVIDIA、Kakaoなどの対応製品が対象で、Apple対応は今後の予定である。（[出典1](https://blog.google/innovation-and-ai/models-and-research/google-deepmind/synth-id-ai-content/)）
- **Cloudflare Agents 0.27.0、Channelsのimport先を変更**：`agents/channels`は削除され、`agents/experimental/channels`へ置き換わった。Slack、Telegram、Email連携を利用する場合はimport先の移行が必要であり、新しいAPIは実験段階として扱う。（[出典1](https://github.com/cloudflare/agents/releases/tag/agents%400.27.0)）
- **NVIDIA DGX Station for Windowsをプレビュー**：NVIDIAは、GB300 Grace Blackwell Ultraを使うWindows向けのDGX Stationを紹介した。同じ発表で扱われたRTX Spark端末の販売予定とは区別し、DGX Stationは一般提供開始ではなくプレビューとして読む必要がある。（[出典1](https://blogs.nvidia.com/blog/local-ai-rtx-spark-microsoft-windows-event/)）