メインコンテンツへスキップ
EastBraver Labs

Fresh AI updates

@cloudflare/computerの責任境界

Cloudflareがエージェント用の実行環境@cloudflare/computerを早期公開し、軽量処理とコンテナ処理の責任分界が論点になりました。GPT-Liveの音声経路分離、GPUテナント隔離、EU AI Act第50条の表示義務も確認したい更新です。

(更新日:)22分で読めます
AI Digestcloudflaregovernanceopen-sourceamazon-bedrockevaluationagentcore
@cloudflare/computerの責任境界

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

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

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

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

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

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

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

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

関連する技術ガイド: AI AgentのSandbox / AIシステムのIdentityとAuthorization / AI AgentのObservabilityとTrace

確認論点:

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

未確認事項:

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

あわせて見る動き

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

  • 掲載件数: 6件
  • 対象分野: Policy（1件） / Infra（2件） / OpenSource（2件） / Products（1件）
  • 関係する読者: 管理者 / AX担当 / エンジニア

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

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

対象時間帯内に公開されたThe Vergeの記事を入口に、すでに適用が始まった義務を確認します。欧州委員会のFAQによると、EU AI Act第50条の透明性義務は2026年8月2日から適用されました。対話型AIとの接触通知、生成・操作コンテンツの機械可読な表示、ディープフェイクなどの開示要件が示されています。2026年8月2日より前に市場投入された一部システムには、表示と検出義務について12月2日まで猶予があります。

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

確認論点:

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

未確認事項:

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

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

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

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

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

関連する技術ガイド: AI AgentのTool

確認論点:

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

未確認事項:

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

Orchard: An open framework for scalable agentic AI

何が変わったか: 学習、評価、実際のエージェント実行基盤で共通利用できるKubernetes環境サービスと試行記録基盤が公開されました。

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

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

関連する技術ガイド: AI Agent評価

確認論点:

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

未確認事項:

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

How to Run Isolated Tenant Kubernetes Clusters on Shared GPU Infrastructure

何が変わったか: 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障害時のジョブ再実行とチェックポイント復元を検証する

未確認事項:

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

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

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

GoogleはAgent Skillsを内部で構築・評価し、公開可能な内容だけをGitHubへ自動出力する工程を説明しました。フロントマター、構成、命名、リンク、安全制御を自動検査し、提出時と毎週の継続評価を実行しています。スキルの有無による正確性と完了率に加え、トークン消費量と完了時間も複数のフレームワークで測定します。

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

関連する技術ガイド: Guardrails

確認論点:

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

未確認事項:

  • 内部評価suiteと個別skillの結果はどこまで公開されるか
  • 複数framework間の評価条件を同一に保てるか

Automated Reasoning policy refinement in Amazon Bedrock

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

AWSはAmazon Bedrock Automated Reasoningのポリシーに、失敗したテストを診断して形式論理の変更案を生成する自動改善機能を追加しました。規則を直すIterative Refinementと、自然言語から変数への変換曖昧性を扱うAmbiguous Variable Refinementがあります。変更案は非同期で生成され、利用者が承認するまで下書きポリシーへ反映されません。

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

関連する技術ガイド: Human-in-the-Loop / Guardrails

確認論点:

  • 提案前後の論理差分と回帰テストを保存する
  • DRAFTから本番policyへ昇格できる権限を限定する
  • 非同期処理のtimeout、再試行、重複承認を確認する

未確認事項:

  • 提案変更の完全性をどの水準まで自動評価できるか
  • 大規模policyでの処理時間と費用はどの程度か

短く追う更新

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

  • 掲載件数: 8件
  • 対象分野: Products（2件） / Research（5件） / Business（1件）
  • 関係する読者: 管理者 / AX担当 / エンジニア

Cortex Framework v7 is GA: Build agentic workflows without disrupting SAP operations

  • 情報源: Google Cloud
  • 出典種別: 公式情報
  • 分類: Products
  • 関係する読者: 管理者 / AX担当 / エンジニア

Google CloudはCortex Framework v7を一般提供し、SAP ERPとSAP Business Data Cloud向けのデータプロダクトをBigQueryへ展開し、Knowledge Catalogへ登録できるようにしました。Dataformによるバージョン管理、依存解決、モジュール単位のデプロイを採用し、必要なテーブルだけを処理します。自然言語からデータプロダクト構築を支援するスキルも含まれます。

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

CAGE: Certified Authorization under Typed-Return Uncertainty for Tool-Using Agents

  • 情報源: arxiv.org
  • 出典種別: 原著論文（プレプリント）
  • 分類: Research
  • 関係する読者: AX担当 / エンジニア

CAGEは、ツール応答と情報源の対応付けに誤りがあり、限定的な数値のずれも同時に存在する場合に、操作の認可が維持されるかを検証する手法です。離散的な分岐と連続的な摂動を組み合わせて検証し、実行可能なポリシー向けのCAGE-Exactと、学習済みゲート向けのCAGE-Lip、CAGE-RSを提案しています。arXivのプレプリントであり、実運用での拡張性は未確認です。

変化: ツールの戻り値を正しい型として受け取るだけでなく、由来の取り違えと数値変動をまたいでaction認可を検証する枠組みが提案されました。 確認: 操作の認可に使うツール応答と情報源の対応付けを記録する

Tool Specifications Matter: Uncovering and Mitigating Safety Risks in AI Agents

  • 情報源: arxiv.org
  • 出典種別: 原著論文（プレプリント）
  • 分類: Research
  • 関係する読者: AX担当 / エンジニア

本論文は、スキーマ形式のツール仕様がモデル内部の拒否信号を弱め、危険なツール実行に寄与すると報告しています。SafeKeepは安全判断時に平文化したテキスト形式を使い、実行時は元のスキーマを維持します。著者評価では平均拒否率が23.8%から70.6%へ上昇し、観測データを介したプロンプトインジェクションの平均成功率が25.6%から2.5%へ低下しました。

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

関連する技術ガイド: プロンプトインジェクション / AI Agent 確認: ツール仕様の形式ごとに危険要求の拒否率を測る

Model or Harness? An Interaction-Centric Taxonomy for Localizing Agent Failures

  • 情報源: arxiv.org
  • 出典種別: 原著論文（プレプリント）
  • 分類: Research
  • 関係する読者: AX担当 / エンジニア

本論文は、エージェントの失敗をモデル、実行基盤、利用者、ツール、メモリ、環境の相互作用へ割り当てる分類体系を提案しています。41の失敗モードを構成要素間の関係と修復責任で整理し、モデル学習、実行基盤の修正、環境や採点器の再設計のどこで直すかを示します。最良の自動分類器は、人間が付けた分類との一致度がCohen's κ=0.76でした。

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

Beyond Component Testing: Validating Agentic AI Systems

  • 情報源: arxiv.org
  • 出典種別: 原著論文（プレプリント）
  • 分類: Research
  • 関係する読者: 管理者 / AX担当 / エンジニア

本調査は257件の文献を分析し、AIエージェントシステムの検証を挙動、安全性、時間変化、規制対応、複数エージェントの5次元で整理しました。時間経過に伴う妥当性、実行時証拠の更新、規制上の説明可能性、終端を限定しない複数エージェントの保証が未成熟だとしています。研究課題として、自律範囲を限定する仕様、実行時監視、監査に使える証拠などを挙げています。

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

Safety, or Just Capability? A Validity Audit of Agent-Safety Benchmarks

  • 情報源: 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

  • 情報源: AWS
  • 出典種別: 公式情報
  • 分類: Business
  • 関係する読者: 管理者 / AX担当 / エンジニア

Formula 1とAWSはAmazon Bedrock AgentCoreを使うData Acceleratorを構築し、データソース受け入れ用コードの生成を6〜8週間から約40分へ短縮したと報告しました。BRDから設定、GitHubのプルリクエスト、Jiraのチケットを作り、承認後にGlue、DBT、ガバナンスポリシーのPRを生成します。スキーマ変更検知、下流影響分析、CloudWatchの操作トレースを組み込み、各段階に人間によるレビューを残しています。

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

関連する技術ガイド: Human-in-the-Loop / AI Agent 確認: 生成PRに必須テスト、担当者レビュー、ロールバック手順を設定する

Real-world mainframe modernization with AI: A safe, scalable path from mainframe to cloud

  • 情報源: Google Cloud
  • 出典種別: 公式情報
  • 分類: Products
  • 関係する読者: 管理者 / AX担当 / エンジニア

Google Cloudはメインフレーム刷新を、評価、刷新、リスク低減、データ移行の4段階で進める構成を説明しました。Mainframe Assessment Toolは依存関係や業務規則を抽出し、MCP経由でAIエージェントのワークフローへ渡します。Dual Runは実際の本番トラフィックを旧環境と新環境の両方で処理し、プロトコル、メッセージ、データの差分から機能同等性を検証します。

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

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

ひとこと更新

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

Written by

柿添貴士(TakashiKakizoe) profile photo

柿添貴士(TakashiKakizoe)

Webエンジニア／テックリード

Fukuoka, Japan

  • PHP
  • Laravel
  • Next.js
  • AWS
  • Cloudflare
  • AI Agent
GitHubXZennQiitaWantedly

NEXT SIGNAL

関連するAI Digest