# @cloudflare/computerの責任境界 - AIダイジェスト 20260804

> @cloudflare/computerの共有ファイルシステムと実行方式を軸に、音声AIの経路分離、GPU隔離、EU透明性義務、エージェント評価と権限制御の確認点を整理します。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20260804
Published: 2026-08-04T06:30:00+09:00
Category: ai-digest
Tags: cloudflare, governance, open-source, amazon-bedrock, evaluation, agentcore

## 3分で読む AIダイジェスト

本日の中心は、AIエージェントへ「作業用コンピュータ」を渡すときの責任分界です。軽い処理とLinux依存処理の振り分け、永続ファイルの権限、ツール呼び出しの監査、失敗がモデルと周辺実装のどちらにあるかを、導入前に分けて検証できる設計が重要になります。

### 読者別の見方

- 管理者: エージェント導入費用はモデル料金だけでなく、隔離環境、監査ログ、人間の承認工程を含めて比較する必要があります。
- AX担当: 対象業務ごとに、書き込み可能なデータ、外部実行を許す条件、失敗時の責任者と停止手順を確認してください。
- エンジニア: isolateとコンテナの切替条件、永続状態の整合性、非同期処理の再試行、ツール権限、監査ログ、ロールバック経路を検証対象にしてください。

### 今日の未確認事項

- @cloudflare/computerの正式料金、SLA、API互換性は一般提供時にどう変わるか
- EU AI Act第50条の表示・マーキング要件は各サービス画面と生成経路のどこに適用されるか
- エージェント評価でモデル、harness、tool、memoryの失敗責任を再現可能に分類できるか

## 今朝の要点

- [Cloudflare、エージェント用実行環境を早期公開](https://blog.cloudflare.com/cloudflare-computer/)
- [GPT‑Liveは音声経路と非同期RPCを分離](https://openai.com/index/continuous-voice-interaction-with-gpt-live)
- [EU AI Act第50条の透明性義務が適用開始](https://www.theverge.com/ai-artificial-intelligence/974571/eu-ai-act-transparency-labels-rules-deepfakes)
- [Orchard、実環境でのrollout収集を共通化](https://www.microsoft.com/en-us/research/blog/orchard-an-open-framework-for-scalable-agentic-ai/)
- [Google、Agent Skillsの継続評価工程を公開](https://cloud.google.com/blog/topics/developers-practitioners/behind-the-scenes-how-we-build-test-and-scale-google-agent-skills/)

## 今日の流れ

エージェントにコードやファイルを扱わせる際、実行環境をどこまで軽量化し、どこからコンテナへ逃がすかが具体的な設計論点になりました。Cloudflareの新ライブラリに加え、音声処理の経路分離、GPUテナント分離、ツール権限と評価の研究から、実行方式だけでなく監査、失敗の切り分け、人間の承認点まで見ておきたい一日です。

## 今日の主要論点

今日のAI実装動向を読むうえで、最初に確認したい論点です。

### Your agent needs a computer, not a container — introducing @cloudflare/computer

- 情報源: Cloudflare (2026-08-03 22:15 JST)
- 出典種別: 公式情報
- URL: [https://blog.cloudflare.com/cloudflare-computer/](https://blog.cloudflare.com/cloudflare-computer/)
- 分類: Infra
- 関係する読者: 管理者 / AX担当 / エンジニア
- タグ: `cloudflare`

**何が変わったか:** エージェントの永続ファイル操作と軽量・コンテナ実行を、共通のツール面と監査対象として扱える早期プレビューが加わりました。

Cloudflareは、エージェント用実行環境をまとめるオープンソースライブラリ「@cloudflare/computer」を早期プレビューで公開しました。SQLite-backedの共有仮想ファイルシステムを使い、軽量処理はisolate、Linuxやネイティブバイナリを要する処理はContainerで実行します。read、write、edit、ls、execなどのAI SDK互換ツールを備え、ファイル操作と実行を権限管理、監査、観測の対象にします。料金、SLA、一般提供時期は未公表です。

**実装・運用観点:** 実行処理をすべてコンテナへ載せる設計と比べ、起動負荷を抑えながら必要時だけLinux互換環境を使う選択肢になります。試行前に、isolateとContainerの切替条件、永続ファイルの権限境界、失敗時の再実行とロールバック方法を決めておきたいところです。

**関連する技術ガイド:** [AI AgentのSandbox](/guides/sandbox) / [AIシステムのIdentityとAuthorization](/guides/ai-identity-authorization) / [AI AgentのObservabilityとTrace](/guides/observability-tracing)

**確認論点:**
- isolateとContainerへ処理を振り分ける条件を定義する
- 共有仮想ファイルシステムの所有権、容量、保持期間を確認する
- exec権限、ネットワーク到達先、監査ログの保存先を確認する

**未確認事項:**
- 早期プレビュー後のAPI互換性、料金、SLAはどうなるか
- Container障害時の再試行とファイル状態の整合性はどこまで保証されるか
- コンテナ利用を10%未満に抑える目標が実負荷で達成できるか

## あわせて見る動き

主要論点の背景、比較材料、運用上の影響を補う更新です。

### Europe’s AI labeling and transparency rules are now in effect

- 情報源: The Verge (2026-08-04 02:38 JST)
- 出典種別: 二次報道
- URL: [https://www.theverge.com/ai-artificial-intelligence/974571/eu-ai-act-transparency-labels-rules-deepfakes](https://www.theverge.com/ai-artificial-intelligence/974571/eu-ai-act-transparency-labels-rules-deepfakes)
- 分類: Policy
- 関係する読者: 管理者 / AX担当 / エンジニア
- タグ: `governance`

**何が変わったか:** EU向けAIサービスでは、対話通知と生成物マーキングを実装・運用フローへ組み込む法令上の確認が現時点の課題になりました。

対象時間帯内に公開されたThe Vergeの記事を入口に、すでに適用が始まった義務を確認します。[欧州委員会のFAQ](https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act)によると、EU AI Act第50条の透明性義務は2026年8月2日から適用されました。対話型AIとの接触通知、生成・操作コンテンツのmachine-readable marking、deepfakeなどの開示要件が示されています。2026年8月2日より前に市場投入された一部システムには、マーキングと検出義務について12月2日まで猶予があります。

**実装・運用観点:** 表示文言だけでなく、生成経路で機械可読な印を付け、再配布後も追跡できるかが実装論点です。エージェントが文章や画像を自動公開する場合は、誰がdeployerに当たるかも法務と切り分ける必要があります。

**確認論点:**
- EU利用者へAIとの対話を通知する画面とタイミングを特定する
- 生成・編集コンテンツへ機械可読な印を付ける経路を確認する
- 例外、既存システムの猶予、deployer責任を法務と確認する

**未確認事項:**
- 個別サービスへの例外と管轄当局の執行判断はどうなるか
- 二次配布や変換後もマーキングを維持する実装水準はどこまで求められるか

### How we built a realtime system for responsive voice AI in six months

- 情報源: OpenAI (2026-08-03 16:00 JST)
- 出典種別: 公式情報
- URL: [https://openai.com/index/continuous-voice-interaction-with-gpt-live](https://openai.com/index/continuous-voice-interaction-with-gpt-live)
- 分類: Infra
- 関係する読者: AX担当 / エンジニア

**何が変わったか:** 音声対話をターン単位で待つ構成から、メディア配信を遅いツール処理から分離するfull-duplex構成の実装例が示されました。

OpenAIはGPT‑Liveの本番アーキテクチャを公開しました。音声モデルが聞きながら話すfull-duplex方式を採用し、音声の高速経路と推論・ツール利用の非同期RPC経路を分離しています。読み取り専用のshadow pathで実トラフィックを段階投入し、地域別遅延、長時間接続、再接続、構成ドリフトを検証したと説明しています。GPT‑Live APIは今後提供予定ですが、公開時期、料金、正式仕様は本文に記載されていません。

**実装・運用観点:** リアルタイムエージェントでは、ツール呼び出しの遅延を音声停止へ波及させない責任分界が重要です。公開APIを待つ間も、メディア経路、非同期処理、再接続、重複実行の試験条件は先に整理できます。

**関連する技術ガイド:** [AI AgentのTool](/guides/tool)

**確認論点:**
- 音声配信とツール実行を別の遅延予算で設計する
- 再接続時のセッション状態とツール呼び出しの冪等性を確認する
- shadow trafficで個人情報を扱う場合の保持とアクセス制御を確認する

**未確認事項:**
- GPT‑Live APIの公開時期、料金、正式仕様はどうなるか
- 報告された性能が利用側ネットワークでも再現するか

### Orchard: An open framework for scalable agentic AI

- 情報源: microsoft.com (2026-08-04 01:00 JST)
- 出典種別: 公式情報
- URL: [https://www.microsoft.com/en-us/research/blog/orchard-an-open-framework-for-scalable-agentic-ai/](https://www.microsoft.com/en-us/research/blog/orchard-an-open-framework-for-scalable-agentic-ai/)
- 分類: OpenSource
- 関係する読者: AX担当 / エンジニア
- タグ: `open-source`

**何が変わったか:** 学習、評価、実際のagent harnessで共通利用できるKubernetes環境サービスとrollout記録基盤が公開されました。

Microsoft Researchは、エージェントの学習データ収集、強化学習rollout、評価に使えるオープンソースフレームワークOrchardを公開しました。KubernetesベースのOrchard Envを中核に、Codex、OpenClaw、ZeroClawなどの実際のharness内でrolloutを動かし、モデル呼び出しを記録します。約30億active parameterのOrchard-SWEについて、Microsoftの自己報告ではSWE-bench Verified 69.7%、reranking込み73.0%です。

**実装・運用観点:** モデル単体の評価では見えないharnessや環境依存の失敗を、同じ実行面で収集できる可能性があります。導入判断ではクラスタ費用、テナント隔離、外部harnessの互換性を先に確認したいところです。

**関連する技術ガイド:** [AI Agent評価](/guides/ai-agent-evaluation)

**確認論点:**
- rollout環境のネットワーク、資格情報、データ隔離を確認する
- 学習用記録から秘密情報と個人情報を除外できるか確認する
- 対象harnessごとに再現性と失敗時の後始末を検証する

**未確認事項:**
- SWE-benchの結果を独立環境で再現できるか
- クラスタ費用と大規模並列時の隔離強度はどの程度か

### How to Run Isolated Tenant Kubernetes Clusters on Shared GPU Infrastructure

- 情報源: NVIDIA Developer Blog (2026-08-04 01:00 JST)
- 出典種別: 公式情報
- URL: [https://developer.nvidia.com/blog/how-to-run-isolated-tenant-kubernetes-clusters-on-shared-gpu-infrastructure/](https://developer.nvidia.com/blog/how-to-run-isolated-tenant-kubernetes-clusters-on-shared-gpu-infrastructure/)
- 分類: Infra
- 関係する読者: 管理者 / AX担当 / エンジニア

**何が変わったか:** GPU quotaの動的割り当てと分離control planeを組み合わせた、共有GPUのテナント運用パターンが具体化しました。

NVIDIAはKAI SchedulerとvClusterを組み合わせ、共有GPU上にチーム別のKubernetesクラスタを構築する手順を公開しました。例では1基のNVIDIA L40Sを3チームへ各0.33 GPU保証で割り当て、空きがあれば最大1 GPUまでburstできます。shared-nodesは信頼された内部チーム向けで、信頼できないtenantにはprivate nodesを案内しています。

**実装・運用観点:** エージェント実行環境と同様、論理分離と物理分離を同じ安全水準として扱わないことが重要です。コスト効率を取るshared-nodesと、敵対的tenantを想定するprivate nodesの選択条件を明文化しておきたいところです。

**確認論点:**
- tenant間でnode、network、storageのどこまでを共有するか確認する
- 保証quota、burst、idle回収時の公平性を負荷試験する
- GPU障害時のjob再実行とcheckpoint復元を検証する

**未確認事項:**
- 大規模環境でも単一GPU例と同じ公平性を維持できるか
- shared-nodesで敵対的tenantを想定した隔離強度はどの程度か

### Behind the scenes: How we build, test, and scale Google Agent Skills

- 情報源: Google Cloud (2026-08-03 20:23 JST)
- 出典種別: 公式情報
- URL: [https://cloud.google.com/blog/topics/developers-practitioners/behind-the-scenes-how-we-build-test-and-scale-google-agent-skills/](https://cloud.google.com/blog/topics/developers-practitioners/behind-the-scenes-how-we-build-test-and-scale-google-agent-skills/)
- 分類: OpenSource
- 関係する読者: AX担当 / エンジニア
- タグ: `governance` `open-source`

**何が変わったか:** エージェント用skillを単発のプロンプト資産ではなく、静的検査、継続評価、公開制御を伴う保守対象として扱う運用例が示されました。

GoogleはAgent Skillsを内部で構築・評価し、公開可能な内容だけをGitHubへ自動exportする工程を説明しました。frontmatter、構成、命名、リンク、guardrailを自動検査し、提出時と毎週の継続evalを実行しています。skill有無による正確性と完了率に加え、token消費量と完了時間も複数frameworkで測定します。

**実装・運用観点:** 実行環境を整えてもskillの更新で品質や費用が変わるため、コードと同じ変更管理が必要です。社内情報を含むskillでは、公開版へのexport時に何を除去するかも確認したいところです。

**関連する技術ガイド:** [Guardrails](/guides/guardrails)

**確認論点:**
- skillの構造、リンク、権限制約をCIで検査する
- skill有無で品質、token量、完了時間を比較する
- 内部版から公開版へ除去する情報のルールを定義する

**未確認事項:**
- 内部評価suiteと個別skillの結果はどこまで公開されるか
- 複数framework間の評価条件を同一に保てるか

### Automated Reasoning policy refinement in Amazon Bedrock

- 情報源: AWS (2026-08-04 01:30 JST)
- 出典種別: 公式情報
- URL: [https://aws.amazon.com/blogs/machine-learning/automated-reasoning-policy-refinement-in-amazon-bedrock/](https://aws.amazon.com/blogs/machine-learning/automated-reasoning-policy-refinement-in-amazon-bedrock/)
- 分類: Products
- 関係する読者: AX担当 / エンジニア
- タグ: `amazon-bedrock`

**何が変わったか:** 検証失敗から論理policyの修正候補を生成し、人間の承認後に反映する非同期ワークフローが利用可能になりました。

AWSはAmazon Bedrock Automated Reasoning policyに、失敗testを診断して形式論理の変更案を生成する自動refinementを追加しました。ruleを直すIterative Refinementと、自然言語から変数への変換曖昧性を扱うAmbiguous Variable Refinementがあります。変更案は非同期で生成され、利用者が承認するまでDRAFT policyへ反映されません。

**実装・運用観点:** 自動修正を即時適用せず、diffとtestを人間が確認する責任分界は、エージェントの自動変更にも応用できる運用パターンです。提案が業務規則の意味を変えていないかを承認条件へ含める必要があります。

**関連する技術ガイド:** [Human-in-the-Loop](/guides/human-in-the-loop) / [Guardrails](/guides/guardrails)

**確認論点:**
- 提案前後の論理diffと回帰testを保存する
- DRAFTから本番policyへ昇格できる権限を限定する
- 非同期処理のtimeout、再試行、重複承認を確認する

**未確認事項:**
- 提案変更の完全性をどの水準まで自動評価できるか
- 大規模policyでの処理時間と費用はどの程度か

## 短く追う更新

優先度は少し下がりますが、流れを押さえるために確認しておきたい更新です。

### [Cortex Framework v7 is GA: Build agentic workflows without disrupting SAP operations](https://cloud.google.com/blog/products/sap-google-cloud/cortex-framework-v7-power-ai-agents-with-sap-data-faster/)

Google Cloud | 公式情報 | Products | 管理者 / AX担当 / エンジニア

Google CloudはCortex Framework v7を一般提供し、SAP ERPとSAP Business Data Cloud向けdata productをBigQueryへ展開し、Knowledge Catalogへ登録できるようにしました。Dataformによるversion control、依存解決、modular deploymentを採用し、必要なtableだけを処理します。自然言語からdata product構築を支援するskillも含まれます。

**変化:** SAPデータをエージェント向けdata productへ整備する処理に、版管理と部分展開を備えた一般提供基盤が加わりました。
**確認:** 対応するSAP source、table、更新方式を確認する

### [CAGE: Certified Authorization under Typed-Return Uncertainty for Tool-Using Agents](https://arxiv.org/abs/2607.29190)

arxiv.org | 原著論文（プレプリント） | Research | AX担当 / エンジニア

CAGEは、tool returnのsource binding誤りと限定的な数値driftが同時に存在してもactionの認可が維持されるかを検証する手法です。離散的な分岐と連続的な摂動をjointに検証し、実行可能policy向けのCAGE-Exactと、学習gate向けのCAGE-Lip、CAGE-RSを提案しています。arXiv preprintであり、実運用での拡張性は未確認です。

**変化:** ツールの戻り値を正しい型として受け取るだけでなく、由来の取り違えと数値変動をまたいでaction認可を検証する枠組みが提案されました。
**確認:** action認可に使うtool returnのsource bindingを記録する

### [Tool Specifications Matter: Uncovering and Mitigating Safety Risks in AI Agents](https://arxiv.org/abs/2607.29254)

arxiv.org | 原著論文（プレプリント） | Research | AX担当 / エンジニア

本論文はschema形式のtool specificationがモデル内部のrefusal signalを弱め、危険なツール実行に寄与すると報告しています。SafeKeepは安全判断時にflattened text形式を使い、実行時は元のschemaを維持します。著者評価では平均拒否率が23.8%から70.6%へ上昇し、observation-level prompt injectionの平均成功率が25.6%から2.5%へ低下しました。

**変化:** ツール仕様の表現形式自体を安全性評価の変数として扱い、判断用表現と実行用schemaを分離する手法が示されました。

**関連する技術ガイド:** [プロンプトインジェクション](/guides/prompt-injection) / [AI Agent](/guides/ai-agent)
**確認:** tool specification形式ごとに危険要求の拒否率を測る

### [Model or Harness? An Interaction-Centric Taxonomy for Localizing Agent Failures](https://arxiv.org/abs/2607.28802)

arxiv.org | 原著論文（プレプリント） | Research | AX担当 / エンジニア

本論文はagent failureをmodel、harness、user、tool、memory、environment間のinteractionへ割り当てるtaxonomyを提案しています。41のfailure modeをcomponent間のedgeと修復責任側で整理し、model学習、harness修正、environmentやgrader再設計のどこで直すかを示します。分類評価の最良judgeはhuman labelに対してCohen's κ=0.76でした。

**変化:** エージェント障害をモデルの失敗へ一括せず、相互作用と修復責任に基づいて分類する診断枠組みが提案されました。
**確認:** 障害記録にmodel、harness、tool、memory、environmentを分けて残す

### [Beyond Component Testing: Validating Agentic AI Systems](https://arxiv.org/abs/2607.29405)

arxiv.org | 原著論文（プレプリント） | Research | 管理者 / AX担当 / エンジニア

本surveyは257件の文献を分析し、agentic systemのvalidationをbehavioral、safety、temporal、regulatory、multi-agentの5次元で整理しました。時間経過に伴う妥当性、runtime evidenceの更新、規制上の説明可能性、open-ended multi-agent assuranceが未成熟だとしています。研究課題としてbounded-autonomy specification、runtime monitoring、audit-ready evidenceなどを挙げています。

**変化:** コンポーネント単体の精度評価から、時間変化、規制証跡、複数agentを含むシステム全体のvalidationへ評価範囲が整理されました。
**確認:** 評価をbehavioral、safety、temporal、regulatory、multi-agentに分ける

### [Safety, or Just Capability? A Validity Audit of Agent-Safety Benchmarks](https://arxiv.org/abs/2607.28685)

arxiv.org | 原著論文（プレプリント） | Research | 管理者 / AX担当 / エンジニア

本研究はR-Judge、InjecAgent、AgentHarm、AgentDojoを公式実装とscorerで再評価し、単一のagent safety scoreとして扱う妥当性を監査しました。R-Judgeでは常にpositiveを返すpolicyでもF1=0.690となり、識別を行う21モデル中5モデルを上回ったと報告しています。安全性を主張する際はbenchmark名、metric、対象behavior、model panelを明示すべきだと結論づけています。

**変化:** agent safetyの総合scoreだけでは安全能力と一般能力を区別できない場合があり、評価条件の明示が必要だと示されました。
**確認:** benchmark名、metric、対象behavior、model panelを記録する

### [From weeks to minutes: How Formula 1® uses agentic AI on AWS to accelerate data operations](https://aws.amazon.com/blogs/machine-learning/from-weeks-to-minutes-how-formula-1-uses-agentic-ai-on-aws-to-accelerate-data-operations/)

AWS | 公式情報 | Business | 管理者 / AX担当 / エンジニア

Formula 1とAWSはAmazon Bedrock AgentCoreを使うData Acceleratorを構築し、data source onboardingのcode生成を6〜8週間から約40分へ短縮したと報告しました。BRDから設定、GitHub pull request、Jira ticketを作り、承認後にGlue、DBT、governance policyのPRを生成します。schema変更検知、下流影響分析、CloudWatchのaction traceを組み込み、各段階に人間のreview gateを残しています。

**変化:** データ接続作業をPR生成まで自動化しつつ、変更承認とdeploymentを人間側へ残す実運用例が示されました。

**関連する技術ガイド:** [Human-in-the-Loop](/guides/human-in-the-loop) / [AI Agent](/guides/ai-agent)
**確認:** 生成PRに必須test、owner review、rollback手順を設定する

### [Real-world mainframe modernization with AI: A safe, scalable path from mainframe to cloud](https://cloud.google.com/blog/products/infrastructure-modernization/mainframe-migration-and-modernization-with-ai/)

Google Cloud | 公式情報 | Products | 管理者 / AX担当 / エンジニア

Google Cloudはmainframe modernizationをassessment、modernization、de-risking、data migrationの4段階で進める構成を説明しました。Mainframe Assessment Toolは依存関係やbusiness ruleを抽出し、MCP経由でagentic workflowへ渡します。Dual Runは実production trafficを旧環境と新環境の両方で処理し、protocol、message、dataの差分から機能同等性を検証します。

**変化:** メインフレーム分析結果をエージェントへ渡し、実トラフィックの並行実行で移行結果を検証する一連の構成が示されました。

**関連する技術ガイド:** [MCP](/guides/mcp)
**確認:** 機能同等性の比較項目、許容差、観測期間を定義する

## ひとこと更新

本文で詳しく扱うほどではないものの、周辺動向として確認しておきたい話題です。

- [GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model](https://engineering.fb.com/2026/08/03/ml-applications/training-gem-at-llm-scale-meta-ads-recommendation-foundation-model/)：広告推薦モデルの学習効率を倍増
- [NVIDIA Vera Storage Benchmarks: Faster Encryption, Compression, Integrity Checking, and Recovery for AI-Native Storage](https://developer.nvidia.com/blog/nvidia-vera-storage-benchmarks-faster-encryption-compression-integrity-checking-and-recovery-for-ai-native-storage/)：AIストレージ処理の性能値を公開
- [Alibaba、Qwen3.8-Maxを提供開始と報道](https://www.theverge.com/ai-artificial-intelligence/974342/alibaba-qwen-max-open-weight-ai)：The Vergeは提供開始とmodel weightsの翌週公開予定を報道。一次資料本文は未取得
- [Beyond Retrieval: Analytic Memory for Multimodal Agents](https://arxiv.org/abs/2607.29440)：分析可能なマルチモーダル記憶を提案
- [ThinkReset: Learnable Intermediate Interface Construction for Bounded-Context Long-Horizon Reasoning](https://arxiv.org/abs/2607.28642)：文脈リセット前の中間保存を学習
- [TencentCloud/TencentDB-Agent-Memory](https://github.com/TencentCloud/TencentDB-Agent-Memory)：共有可能な階層型agent記憶を公開
- [AgenticRepair: Multi-Faceted Program Context Engineering for Agentic Vulnerability Repair](https://arxiv.org/abs/2607.29422)：三種の文脈で脆弱性修正を支援