# macOSのフルディスクアクセスに追加制御を予告

> AppleがmacOSのフルディスクアクセスに追加制御を予告した。PydanticAIの同時実行枠の解放漏れと、OpenAI Agents Python・Microsoft Agent Frameworkの再開時の承認変更も確認。音声モデル移行、GboardのTEE連合学習、推論最適化の条件も整理する。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261003
Published: 2026-10-03T06:30:00+09:00
Category: ai-digest
Tags: ai-agent, governance, safety, model-ops, evaluation, infrastructure, llm-inference, nvidia, pytorch, openai, open-source, cloudflare

Appleは、macOSのフルディスクアクセス付与に、明示的なユーザー操作を求める追加制御を導入すると発表した。対象版と導入時期は未公表で、AIエージェントを含むアプリの権限設計を点検したい。（[Appleの発表](https://developer.apple.com/news/?id=p6zjojqw)）

エージェントの実装では、PydanticAIの処理枠が解放されない不具合と、OpenAI Agents Python・Microsoft Agent Frameworkの実行再開時の承認変更を確認する。各更新は独立した変更だ。利用中の制限器、呼び出し先、セッションの対応を点検し、音声モデルの移行やGboardのプライバシー保証も対象を分けて読む。対象は2026年10月2日06:30から10月3日06:30までのJSTの更新だ。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp) / [出典2](https://github.com/openai/openai-agents-python/releases/tag/v0.23.0) / [出典3](https://github.com/microsoft/agent-framework/releases/tag/python-1.20.0) / [出典4](https://docs.x.ai/developers/release-notes#grok-voice-transcribe-10-end-of-life) / [出典5](https://research.google/blog/toward-provably-private-learning-from-federated-data/)）

## AppleがmacOSのフルディスクアクセス付与に追加制御を予告

Appleは、macOSでアプリにフルディスクアクセスを付与する際、明示的なユーザー操作を必須とする追加制御を導入すると発表した。（[出典1](https://developer.apple.com/news/?id=p6zjojqw)）

Appleは、フルディスクアクセスがバックアップアプリを機能させるために私的データの保護制御を大幅に迂回する権限だと説明した。一部の利用では、ファイル、メール、メッセージ、閲覧履歴などが、利用者の十分な理解なしに露出する恐れがある。通信相手のプライバシーにも影響し、AIエージェントの能力と自律性が高まるほどリスクが増すとしている。（[Apple Developer](https://developer.apple.com/news/?id=p6zjojqw)）

> [!CAUTION] 導入時期と対象範囲は未公表
> 発表には対象macOS版、導入日、具体的な許可操作、既存アプリやMDM設定への影響が記載されていない。現時点で適用済みの制限として扱わない。（[Apple Developer](https://developer.apple.com/news/?id=p6zjojqw)）

**EastBraverの見立て:** [AIエージェント](/guides/ai-agent)が利用するアプリについて、フルディスクアクセスが必要な処理と、利用者が許可した対象を整理しておきたい。[認可と委任の境界](/guides/ai-identity-authorization)を明示しておけば、今後の操作手順や管理設定の発表と照合しやすい。

- 出典: [Apple Developer](https://developer.apple.com/news/?id=p6zjojqw)（公式発表、2026-10-02。[TechCrunchの報道](https://techcrunch.com/2026/10/02/apple-says-its-tightening-macos-full-disk-access-controls-due-to-new-risks-from-ai-agents/)は2026-10-03 03:11 JST）

## PydanticAI 2.53.0がストリーム終了後の同時実行枠の解放漏れを修正

PydanticAI 2.53.0は、モデル側の同時実行制限で、ストリーム終了後も枠が残る不具合を修正した。公式アドバイザリGHSA-6fqq-452j-qhrpの深刻度はHighで、対象は`pydantic-ai`と`pydantic-ai-slim`の2.10.0以上2.53.0未満である。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp)）

`ConcurrencyLimitedModel`や`limit_model_concurrency`を使うストリームで、枠を取得したタスクと別のタスクから解放すると枠が残り得る。中断やキャンセルだけでなく、既定のデバウンス設定を使う`stream_text()`を正常に読み切る場合も対象だ。長く共有する制限器では、繰り返す要求で枠が消費され、後続の要求が進まなくなる。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp)）

**比較表: 同時実行制限を置く場所で異なる影響**

モデル側のストリーム制限と、エージェント側の制限は影響範囲が異なる。更新をすぐに適用できない場合は、エージェント側の制限へ切り替えるか、モデル側の制限器を通すストリーミングを避けることが公式の緩和策となる。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp)）

| 観点 | モデル側の制限 | エージェント側の制限 |
| --- | --- | --- |
| 対象 | `ConcurrencyLimitedModel`などを通すストリーム。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp)） | エージェントの`max_concurrency`。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp)） |
| 今回の影響 | 正常完了後も枠が残り得る。非ストリーミング要求は対象外。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp)） | この不具合の影響を受けない。（[出典1](https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-6fqq-452j-qhrp)） |

修正版では、要求元エージェントや外側のモデルラッパーと制限器を共有すると`UserError`になる。独自の`AbstractConcurrencyLimiter`は、別タスクからの`release()`を許容する必要がある。（[出典2](https://github.com/pydantic/pydantic-ai/releases/tag/v2.53.0)）

**EastBraverの見立て:** [Agent評価](/guides/ai-agent-evaluation)の回帰試験では、途中で切断する要求と正常に読み切る要求の両方で枠が戻るかを確かめたい。独自の制限器を使う構成では、版の更新と合わせて別タスクでの解放と共有条件を点検する。

- 出典: [Pydantic AI](https://github.com/pydantic/pydantic-ai/releases/tag/v2.53.0)（公式リリース、2026-10-02 11:52 JST。影響範囲は同日公開の公式アドバイザリで確認）

## OpenAI Agents Python 0.23系が再開時の宛先と承認範囲を修正

OpenAI Agents Python 0.23.0は、再開したMCP呼び出しを元の宛先へ結び付ける修正と、サンドボックスのパッチ適用ツールで承認範囲を確認する修正を含む。既定のトレース出力から推論内容を省く変更も入った。（[出典1](https://github.com/openai/openai-agents-python/releases/tag/v0.23.0)）

MCPの一覧取得ページ数を設定可能にし、暗号化履歴の走査量には任意の上限を追加した。後続の0.23.1は公開準備とテスト関連の修正で、0.23.0に対するSDK実行コードの差は版番号のみだ。0.22.3から0.23.1へ移る場合は、0.23.0の挙動変更も含まれる。（[出典1](https://github.com/openai/openai-agents-python/releases/tag/v0.23.0) / [出典2](https://github.com/openai/openai-agents-python/releases/tag/v0.23.1)）

> [!CAUTION] 版番号と配布確認を分ける
> 公式の公開前レビューは、strictツールの引数の明示、古い承認の取り直し、暗号化履歴の移行、リソース上限などを移行時の確認事項に挙げている。また、ソースの評価はPyPIへの公開成功を証明するものではないとしている。利用する配布元の版を確認してから更新したい。（[出典2](https://github.com/openai/openai-agents-python/releases/tag/v0.23.1)）

**EastBraverの見立て:** [MCP](/guides/mcp)を使う実行を中断・再開する試験で、呼び出し先と承認範囲が一致するかを確認したい。[認可と委任の境界](/guides/ai-identity-authorization)を扱う変更と、0.23.1の公開準備の修正を分けて読むことが更新判断につながる。

- 出典: [OpenAI Agents Python](https://github.com/openai/openai-agents-python/releases/tag/v0.23.1)（公式GitHubリリース、2026-10-03 00:19 JST。0.23.0は2026-10-02 10:08 JST）

## Microsoft Agent FrameworkがFoundryホスティングとローカル承認を変更

Microsoft Agent Framework Python 1.20.0は、Foundryホスティングの再設計を互換性を壊す変更として明記した。要求ごとのエージェント生成、サンドボックスで分離した永続セッション、永続的なInvocations実行を中心に構成が変わる。（[出典1](https://github.com/microsoft/agent-framework/releases/tag/python-1.20.0)）

ローカル承認の応答は、セッションに記録された要求へ結び付けられるようになる。既定では、承認を要求する実行と承認後に再開する実行へ、同じ`AgentSession`を渡す必要がある。対応を解決できない承認では実行を許可しない。（[出典1](https://github.com/microsoft/agent-framework/releases/tag/python-1.20.0) / [出典2](https://github.com/microsoft/agent-framework/pull/8750)）

**比較表: 承認変更が影響する処理と対象外の処理**

影響するのは、セッションなしでローカル承認を再開していた構成である。完了済みの会話の再生やホスト側の承認まで、一律に同じ変更を要するわけではない。（[出典2](https://github.com/microsoft/agent-framework/pull/8750)）

| 観点 | ローカル承認の再開 | 完了済みの会話の再生・ホスト側の承認 |
| --- | --- | --- |
| セッションなしの構成 | 既定では同じ`AgentSession`を渡す変更が必要。（[出典2](https://github.com/microsoft/agent-framework/pull/8750)） | この承認変更の対象外。（[出典2](https://github.com/microsoft/agent-framework/pull/8750)） |

**EastBraverの見立て:** Foundryを利用するアプリでは、[Sandbox](/guides/sandbox)とセッションの管理をパッケージ更新と同時に見直したい。ローカル承認を使う実装では、同じセッションで再開できることと、対応しない承認が処理を進めないことを移行試験の項目にする。

- 出典: [Microsoft Agent Framework](https://github.com/microsoft/agent-framework/releases/tag/python-1.20.0)（公式リリース、2026-10-02 23:40 JST。承認の範囲は公式PRで確認）

## grok-voice-transcribe-1.0が提供終了し2.0へ自動転送

`grok-voice-transcribe-1.0`は非推奨となり、2026年10月2日に提供終了を迎えた。ただし、同スラッグ宛ての全リクエストは`grok-voice-transcribe-2.0`へ転送されるため、発表上は同日からリクエストが失敗する変更ではない。（[出典1](https://docs.x.ai/developers/release-notes)）

9月17日の更新時点では1.0と2.0の両方を指定でき、既定モデルは2.0だった。提供終了後は、1.0を指定したリクエストも2.0へ転送される。（[出典1](https://docs.x.ai/developers/release-notes)）

xAIによると、転送先の`grok-voice-transcribe-2.0`は1.0と同じ料金で、精度が向上している。現在の公式資料は、RESTのフォームとWebSocketのクエリパラメーターの`model`で後継モデルを指定でき、旧名も転送対象として受け付けると説明している。（[リリースノート](https://docs.x.ai/developers/release-notes) / [Speech to Textの公式資料](https://docs.x.ai/developers/model-capabilities/audio/speech-to-text)）

> [!CAUTION] 転送期限と出力の互換性
> 旧モデル名からの転送をいつ終了するかは発表に記載されていない。転送されることだけから、文字起こし結果や既存の後処理まで同じ挙動と判断しない。（[リリースノート](https://docs.x.ai/developers/release-notes#grok-voice-transcribe-10-end-of-life)）

**EastBraverの見立て:** [LLM API](/guides/llm-api)の移行では、旧スラッグの応答だけでなく、後継モデルで自社の音声、言語、出力処理が期待どおり動くかを確認したい。1.0を指定し続けても、処理先は2.0となる。

- 出典: [xAI](https://docs.x.ai/developers/release-notes#grok-voice-transcribe-10-end-of-life)（公式リリースノート、2026-10-02。時刻の記載なし）

## GoogleがGboardのTEE連合学習と監査可能性を解説

Google Researchは、Gboardの英語・日本語の次単語予測モデルで採用済みのTEEベース連合学習を解説した。今回の更新は公式ブログによる仕組みと運用の説明で、関連論文は9月に公開されている。サーバー側処理を第三者が検証できるようにする一方、個人のプライバシーを守るソフトウェア全体の完全な正当性証明は将来の課題と位置付けている。（[Google Research](https://research.google/blog/toward-provably-private-learning-from-federated-data/) / [関連論文](https://arxiv.org/abs/2609.31494)）

端末は訓練例をローカルで暗号化し、処理を許可するTEE計算を定めたアクセスポリシーとともにアップロードする。TEE群で構成するKMSは、ポリシーに一致するサーバー側TEEワークロードだけへ復号鍵を渡す。データは指定されたPython訓練プログラムを動かすTEE内で、アップロード後の限定期間だけ復号・処理でき、運用者が見られるのは指標と差分プライバシーを適用したモデル重みだけである。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)）

アクセスポリシーは公開透明性ログRekorに掲載され、外部監査者は端末データへアクセスし得るサーバー側ワークロード一式を追跡できる。KMSとデータ処理バイナリは公開コードから再現可能にビルドでき、実行中のコードはリモートアテステーションで検証できる。ただし、機密性と完全性の保証は現行世代TEEの制約を受ける。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)）

動的ロード処理を悪意あるサーバー側攻撃からさらに守るためのサイドチャネル観測対策と、差分プライバシー実装などの完全な正当性証明は今後の課題である。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)）

関連論文はプライバシー会計条件も示している。英語モデルの5,000ラウンド比較では、TEE方式の目標zCDPは0.232、必要なノイズ乗数は5.16だった。同じzCDPを従来方式で満たすには9.54が必要だったと報告している。実サービスのA/B試験では各群350万台を用い、最良のTEE群はzCDPが0.215、比較対象は同じ会計方式に調整して0.641だった。入力速度と修正率は中立を維持しており、この試験を精度全般の向上と読み替えない。（[関連論文の評価条件](https://arxiv.org/html/2609.31494v4#S5)）

> [!CAUTION] 保証と評価の限界
> zCDPの値をそのままεと同一視しない。復号鍵の有効期間制限はKMSによるベストエフォートの実施と説明されている。また、上記のA/B試験は英語モデルの結果で、日本語モデルの同等の定量結果を示すものではない。（[関連論文](https://arxiv.org/html/2609.31494v4#S4)）

**比較表: 従来方式とTEEベース方式で変わる訓練上の制約**

比較で示されたのは、端末側の可用性や計算資源に左右される訓練から、サーバー側TEE資源と参加スケジュールが主要条件となる訓練への移行である。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)）

| 観点 | 従来の連合学習 | 新TEEベースシステム |
| --- | --- | --- |
| 訓練のボトルネック | 端末の可用性、端末上の計算、複数ワークロードによる端末資源の競合に制約され、モデルごとに1～2か月かかる場合があった。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)） | 処理のボトルネックをサーバーへ移して並列化し、大幅に高速化したが、現在はTEE資源の可用性が制約となる。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)） |
| 比較試験での位置付け | 英語モデルを5,000ラウンド、各6,500台の端末からなるコホートで訓練する比較対象となった。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)） | 同じ比較で、参加スケジュールの最適化により、より強い保証または小さいノイズ乗数が可能になる曲線を得た。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)） |

**EastBraverの見立て:** 採用判断では、「外部から検証可能」を完全な証明と同一視せず、公開ポリシーと再現可能なコードによって第三者が検査できる範囲を、今回の保証の中心として読むべきだ。（[出典1](https://research.google/blog/toward-provably-private-learning-from-federated-data/)）

- 出典: [Google Research](https://research.google/blog/toward-provably-private-learning-from-federated-data/)（公式情報、2026-10-02 23:57 JST）

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

モデルの選定、推論基盤、開発ツールと企業導入では、次の更新も確認しておきたい。

- **OpenAIがGPT-6の選定と本番運用のガイドを公開**: Astraを難しい推論、Solをコード開発や調査、Lunaを目的の明確な反復処理へ使い分け、推論設定も含めた成功率、レイテンシ、成功タスク当たりの費用を測るよう勧める。キャッシュとコンテキスト圧縮も扱う資料で、新モデルのリリースではない。[Agent評価](/guides/ai-agent-evaluation)ではモデル名と推論設定を合わせて比較したい。（[出典1](https://openai.com/index/practical-guide-building-gpt-6/)、公式ガイド、2026-10-02）
- **Helion版vLLMはH100の一部ワークロードで10％超向上と報告**: 著者らがH100 80GB HBM3、Qwen3系列、ShareGPTで評価した結果で、最大同時シーケンス数32、テンソル並列数1、プレフィックスキャッシュ無効という条件がある。実装は著者らのvLLMフォークで、`FP8_Dynamic`、`W8A8_INT8`、`Block_FP8`を対象に、小さい形状をCUDA Graph下のHelionへ送る。事前チューニングと初回コンパイルの負担も含め、自社の条件で再現できるか確認したい。Blackwellは初期的なGEMM評価にとどまる。（[出典1](https://pytorch.org/blog/building-a-high-performance-and-portable-vllm-linear-backend-with-helion/)、PyTorchブログ、2026-10-03 04:55 JST）
- **Ai2が引用付きレポートを生成するAstaBrief 8Bを公開**: Qwen3-8Bを基にSFTとDPOで調整したモデルと訓練データを公開した。モデルはApache 2.0ライセンス。Ai2による約3.5倍の高速化は、Fast modeの平均51.1秒とClaudeを使うThinking modeの178.5秒というAsta全体の比較で、評価の大半は2025年に行われた。[RAG](/guides/rag)へ適用する際は、引用の有無に加えて原典の主張の範囲が保たれるか確認したい。（[出典1](https://huggingface.co/blog/allenai/astabrief) / [出典2](https://huggingface.co/allenai/AstaBrief_8B)、公式発表・モデルカード、2026-10-02）
- **Claude Code v2.1.288が許可チェックとMCP呼び出しを修正**: `BASHPID`の算術評価を伴う代入の確認、シェル内の危険な`rm`の確認、フック照合失敗時にツール呼び出しを止める処理を修正した。大きすぎる結果や解析不能な結果によってMCPツールを二度呼び出す問題も修正された。既存の許可ルールとフックを使う環境では、更新後の動作を確認したい。（[出典1](https://github.com/anthropics/claude-code/releases/tag/v2.1.288)、2026-10-03 05:19 JST）
- **Cloudflare Agents 0.26.0がPi関連依存を1.0系へ更新**: `pi-durable`と`pi-ai`を`^1.0.0`へ更新した。Pi harnessを利用する実装では、依存更新後も既存のエージェント処理が期待どおり動くか確認したい。（[出典1](https://github.com/cloudflare/agents/releases/tag/agents%400.26.0)、2026-10-03 02:54 JST）
- **GitHub Copilotが4モデルを廃止しレビューAPIを追加**: Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code、Claude Opus 4.7をCopilot全体で廃止した。推奨移行先は順にGemini 3.8 Flash、Gemini 3.8 Flash、Kimi K3、Claude Opus 5.5で、Enterprise管理者は代替モデルのポリシー許可を確認したい。別の告知では、REST・GraphQLからのコードレビュー要求と要求ごとのreview effort指定を一般提供した。Balancedへの既定値変更は9月28日適用済みで、今回からの変更と混同しない。（[出典1](https://github.blog/changelog/2026-10-02-selected-models-in-github-copilot-deprecated/) / [出典2](https://github.blog/changelog/2026-10-02-copilot-code-review-api-support-and-new-default-effort-level/)、いずれも公式告知は2026-10-02。時刻の記載なし）
- **AnthropicがClaude Frontier Academyを開始**: 1億ドルの投資方針を掲げ、2027年末までに企業の実装を担うFrontier Deployed Engineerを10,000人育成する目標を示した。参加は組織からの推薦による。複数日にわたる対面研修と実技評価を経て12週間の実案件研修へ進む仕組みで、一般向けの自由参加講座として扱わない。（[出典1](https://www.anthropic.com/news/claude-frontier-academy)、2026-10-02）