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

Fresh AI updates

エージェント基盤は非同期運用へ - AIダイジェスト 20260708

Gemini APIのManaged Agents拡張、AgentCore実装例、Foundry Managed Computeを中心に、エージェント運用の非同期化・権限・監視の確認点を整理します。

(更新日:)21分で読めます
AI Digestgemini-apimanaged-agentsremote-mcpasync-executionagentic-infrahugging-facemicrosoft-foundry
エージェント基盤は非同期運用へ - AIダイジェスト 20260708

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

今日の実務テーマは、エージェントを「モデル呼び出し」ではなく「長く走るワーカー」として扱う準備です。GoogleはManaged Agentsに非同期実行やremote MCPを追加し、AWSとMicrosoftはMemory、Gateway、監視、管理GPU基盤を前提にした運用例を出しています。AX/AI担当は、PoCの精度比較だけでなく、誰が権限を持ち、どこに履歴が残り、失敗時にどう戻すかを早めに確認したい日です。

実行ループと責任境界の全体像はAI Agentの技術ガイド、外部接続の仕組みはMCPの技術ガイドで確認できます。

読者別の見方

  • 管理者: エージェント活用の論点は、導入可否よりも運用責任、コスト、監査、データ境界の設計に移っています。
  • AX担当: 次に確認したいのは、候補サービスごとの非同期実行、Memory保持期間、MCP接続、承認フロー、監査ログの差分です。
  • エンジニア: 実装では、同期API前提のタイムアウト、tool callの冪等性、認証更新、観測性、サンドボックス権限を切り分けて検証したいところです。

今日の未確認事項

  • 各Managed Agent基盤の実行時間上限、再試行仕様、料金単位は本番見積もりに足りる粒度で公開されているか。
  • Memoryやログに残る会話・ファイル・ツール結果の保持期間と削除方法を、社内のデータ分類に合わせられるか。
  • remote MCPやGateway経由のツール呼び出しで、監査ログと権限境界をどのシステムがsource of truthとして持つか。

今朝の要点

今日の流れ

本日は、エージェントを同期HTTPの延長で動かす段階から、非同期実行、MCP接続、Memory、Gateway、監査を含む運用基盤として扱う流れがはっきり出ました。Gemini APIのManaged Agents拡張を軸に、Bedrock AgentCore、Microsoft Foundry、NVIDIA Veraまで、実装チームが確認すべき境界はモデル性能よりも実行環境、権限、観測性に寄っています。

今日の主要論点

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

Expanding Managed Agents in Gemini API: background tasks, remote MCP and more

何が変わったか: エージェント実行を同期リクエストではなく、サーバ側で継続する非同期ワーカーとして扱いやすくなった。

GoogleはGemini APIのManaged Agentsに、background execution、remote MCP server integration、custom function calling、credential refreshを追加した。Managed AgentsはGemini Interactions API上で、推論、コード実行、パッケージ導入、ファイル管理、Web情報取得を隔離されたクラウドサンドボックス内で扱う。長時間処理はHTTP接続を握り続けず、IDを受け取ってポーリング、進捗ストリーミング、再接続できる設計になる。remote MCPとcustom functionは、サーバ側サンドボックスとローカル業務ロジックの責任境界を明示して設計する必要がある。

実装・運用観点: 既存のチャットUIや業務自動化APIが同期完了を前提にしている場合、タイムアウト、再接続、ジョブ状態のsource of truthを見直す判断材料になります。remote MCPを使うなら、社内DBや内部APIへの到達範囲、監査ログ、認証更新の責任分界を先に確認したいところです。

確認論点:

  • background実行のジョブID、状態保存、再接続時のsource of truthを決める
  • remote MCPの権限境界、監査ログ、ネットワーク到達範囲を確認する
  • custom functionがrequires_actionになった場合のリトライと冪等性を設計する

未確認事項:

  • 実行時間上限、同時実行数、料金、リージョン提供範囲の詳細は運用見積もりに足りるか。
  • サンドボックス内のファイル、インストール済みパッケージ、クローン済みリポジトリの保持と削除をどこまで制御できるか。
  • remote MCP呼び出しの失敗時に、モデル側の再試行とクライアント側の再試行がどう重なるか。

あわせて見る動き

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

Hugging Face Models on Foundry Managed Compute

何が変わったか: open-weightモデル運用の一部が、自前コンテナ構築から、管理GPU基盤と curated runtime に寄せられる選択肢になった。

Hugging FaceとMicrosoftは、Hugging Faceのopen-weightモデルをMicrosoft Foundry Managed Compute上で運用するプレビューを説明した。モデルはFoundry Model Catalogに入り、重みはAzureに事前配置され、vLLM、SGLang、TensorRT-LLM、NIM、TEI、llama.cppなどのランタイムをMicrosoftがビルド、スキャン、更新する。単一エンドポイント、同じSDK、同じ認証、Azure Monitorの観測性、課金タグを共有する点が実装上の差分になる。

実装・運用観点: モデル選定では精度だけでなく、ライセンス確認、CVE対応、ランタイム更新、Private Network内デプロイの責任境界を比較しやすくなります。Managed Agentsのような実行基盤と組み合わせる場合、どのモデルをどの運用面で統一できるかが確認点です。

確認論点:

  • 対象モデルのライセンス、Safetensors化、trustremotecode排除の扱いを確認する
  • 自動ランタイム更新時の互換性テストとロールバック方法を確認する
  • A100、H100、MI300XなどのSKU、リージョン、Data Zone要件を見積もる

未確認事項:

  • プレビュー時点のモデル一覧、リージョン、料金が本番候補に十分か。
  • Bring Your Own Weightsの提供時期と、社内fine-tunedモデルの審査条件はどうなるか。
  • 自動CVEパッチ適用で推論結果やレイテンシが変わった場合の検知方法は明確か。

NVIDIA Vera CPU Boosts AI Factory Throughput to Accelerate Agentic Workloads

何が変わったか: エージェント基盤の容量設計で、GPU枚数だけでなくCPUの単一スレッド性能とloaded latencyを確認する必要が強くなった。

NVIDIAはVera CPUについて、agentic workloadsではGPUだけでなくCPU側のツール実行、コード実行、検索、KV-cache調整が律速になると説明した。記事では、1.8倍の sustained per-core performance、40%低いloaded latency、3倍超のper-core memory bandwidthなどの効果を主張している。RLの環境ロールアウトや多段ツール呼び出しでは、CPU側の待ち時間がGPU効率と応答レイテンシに直結するという整理です。

実装・運用観点: Managed AgentsやAgentCoreのようにツール呼び出しを多用する構成では、モデル推論以外の待ち時間がSLAを崩すことがあります。ハードウェア選定やクラウドSKU比較では、GPU使用率だけでなくtool call、sandbox、検索、データ処理の待機時間を測るべきです。

確認論点:

  • 自社ワークロードでtool call、コード実行、検索がどの程度CPU待ちになるか測る
  • 満載時のtail latencyとKV-cache再計算の発生率を確認する
  • ベンダーベンチマークを自社の同時実行数とデータサイズで再現する

未確認事項:

  • 独立したベンチマークとクラウド提供SKUで同じ傾向が出るか。
  • Vera採用時のラック電力、冷却、既存運用ツールの対応はどうなるか。
  • CPU改善分がアプリケーション全体のコスト削減にどこまで転換されるか。

A developer's guide to publishing agents in Gemini Enterprise and Google Cloud Marketplace

何が変わったか: エージェントの提供形態が、個別UIへの埋め込みだけでなく、企業向けカタログやMarketplace配布まで広がった。

Google Cloudは、Gemini EnterpriseとGoogle Cloud Marketplaceにエージェントを公開する開発者向けガイドを出した。単体アプリとして作るだけでなく、企業内配布やMarketplace経由の提供を意識したライフサイクルが前面に出ている。Managed Agentsの実行面と合わせて見ると、エージェントの実行、配布、更新、サポートの境界が分かれ始めている。

実装・運用観点: AX担当は、誰が作ったエージェントを誰に配布し、更新時にどの承認を通すかを確認しやすくなります。エンジニアは、バージョニング、権限スコープ、テナント分離、ロールバックを配布設計に含める必要があります。

確認論点:

  • Marketplace公開と社内限定公開で必要な審査、契約、サポート範囲を確認する
  • エージェント更新時のバージョン固定、段階展開、ロールバック手順を設計する
  • 利用者テナントごとの権限、データ到達範囲、ログ閲覧権限を分ける

未確認事項:

  • 公開審査の具体的な要件と所要時間はどこまで明文化されているか。
  • 課金、サポート、SLAの責任は開発者とGoogle Cloudのどこで分かれるか。
  • 外部MCPや社内APIを使うエージェントの審査基準はどう扱われるか。

20 questions for the Agentic Enterprise (and how Agent Platform can help)

何が変わったか: エージェント導入の確認事項が、モデル選定から、作成者、実行経路、Memory、Gateway、監査、脅威検知へ広がった。

Google Cloudは、Agentic Enterpriseに向けた20の確認事項として、誰が作るか、誰が使うか、Memory、Gateway、Model Armor、Threat Detection、Agents CLIなどを整理した。Agent Platformは、Agent Studio、Managed Agents API、ADK、Agent Memory Bank、Agent Gatewayを含む統合先として説明されている。ベンダー色は強いものの、AX/AI担当が社内ヒアリングで使える論点表になっている。

実装・運用観点: 管理者が見るべき論点は、どの部署が作ったエージェントにどのデータを読ませるか、違反時にどこで止めるかです。Managed Agents拡張と合わせると、実行基盤だけでなく統制基盤の設計も同時に必要になります。

確認論点:

  • Agent Gatewayで遮断できる通信、記録される監査ログ、保存先を確認する
  • Agent Memory BankやADK memoryの保持範囲と削除手順を確認する
  • Model ArmorやThreat Detectionの検知結果を既存SOC運用へ流せるか確認する

未確認事項:

  • Google Cloud外のエージェントや既存RPAを同じ統制面に載せられるか。
  • Agent Platform各機能の提供リージョン、エディション、料金差はどうなるか。
  • 脅威検知や異常検知の誤検知時に業務影響をどう抑えるか。

Build a serverless image editing agent with Amazon Bedrock AgentCore harness

何が変わったか: 単純なtool-calling型エージェントでは、独自のオーケストレーションループを書かずに設定中心で構築する選択肢が具体化した。

AWSは、Amazon Bedrock AgentCore harnessでサーバレス画像編集エージェントを作る実装例を公開した。AgentCore harnessは設定でエージェントを定義し、statefulな隔離microVM、Memory、Gateway、MCPツール、Observabilityを扱う。記事の例では、AgentCore Memoryが会話履歴を30日保持し、Lambda-backed MCP toolsとStability AIモデルを使い、InvokeAgentRuntimeCommandでウォーターマーク処理をmicroVM上で実行している。

実装・運用観点: Google Managed Agentsと同じく、管理された実行環境にどこまで任せるかが設計論点になります。独自分岐や前後処理が多い場合はAgentCore Runtimeを選ぶなど、harnessとRuntimeの境界を早めに切り分けると実装の迷いが減ります。

確認論点:

  • AgentCore Memoryの30日保持が扱う画像、プロンプト、個人情報に合うか確認する
  • Lambda proxyを認証境界として置き、許可するsystem promptとtoolを制限する
  • timeoutSeconds、maxIterations、後処理コマンドの失敗時挙動をテストする

未確認事項:

  • AgentCore harnessがプレビューの場合、CDKネイティブ対応やGA時のAPI互換性はどうなるか。
  • microVM上で追加パッケージを導入する場合の再現性と起動時間はどれくらいか。
  • Gateway toolの再試行、部分失敗、二重実行の仕様はアプリ側でどこまで補う必要があるか。

Build an AI-powered AWS support companion with Amazon Bedrock AgentCore

何が変わったか: 本番向けエージェント例で、認証、WAF、Guardrails、監査ログ、token refresh、Memory timeoutの実装パターンが具体化した。

AWSは、Amazon Bedrock AgentCore RuntimeでAWS Support Companionを作る実装例を公開した。構成にはStrands Agents、Amazon Nova Pro、AWS Documentation MCP、AWS Support MCP、AWS API MCP、AgentCore Gateway、AgentCore Memory、Cognito、API Gateway、WAF、Guardrails、CloudWatch、CloudTrailが含まれる。記事は、MCP初期化の並列化、Memory取得の2秒タイムアウト、Gateway token refresh、PII redaction、90日ログ保持など、運用上の細部を示している。

実装・運用観点: エージェントを問い合わせ対応に使う場合、回答品質だけでなく、どのAPIを呼べるか、サポートケース作成を誰が承認するか、失敗時に人へ渡せるかが重要です。実装チームは、MCP接続の初期化失敗やMemory遅延を通常系として扱う設計を確認したいところです。

確認論点:

  • AWS Support MCP利用に必要なSupport planとIAM権限を確認する
  • Guardrails、PII redaction、CloudTrail、CloudWatch retentionを社内監査要件に合わせる
  • Gateway token refreshとMCP初期化失敗時のフォールバックをテストする

未確認事項:

  • サンプル構成をマルチアカウントや閉域ネットワークへ広げる際の追加設計はどこまで必要か。
  • AWS Support APIを使う操作で人の承認をどう挟むか。
  • AgentCore tracingと既存のObservability基盤をどう統合するか。

短く追う更新

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

Report: 83% of organizations need to upgrade their infrastructure to support agentic AI

google-cloud-blog | Business | 管理者 / AX担当

Google Cloudは、1,400人超のシニアITリーダーを対象にしたState of AI Infrastructure reportの概要を公開した。83%がproduction-grade agentic AIにインフラ更新が必要と回答し、inference tax、agent sprawl、統制、データ層、hybrid multicloud、edge、電力が論点として挙げられている。ベンダー調査なので数値はそのまま一般化せず、社内確認リストとして使うのが現実的です。

変化: agentic AIの投資判断で、モデル費用だけでなく、データ、ネットワーク、統制、edge、電力まで含むインフラ計画が前提になった。 確認: 現在のAI/ML基盤で、推論費、データ転送、ストレージ、遊休GPUのどれが主なコストか確認する

Build a unified semantic layer across datasets with multi-dataset Topics in Amazon Quick

aws-ml-blog | Products | AX担当 / エンジニア

AWSはAmazon Quick Sightのmulti-dataset Topicsについて、public previewで最大12 datasetsを1つのTopicに追加し、関係を定義できると説明した。Quick chat agentは定義済みの関係を辿り、自然言語の質問に対して必要なSQL JOINを生成する。SPICEとDirect Queryの混在は現時点で不可とされ、row-level securityとcolumn-level securityはdataset単位で維持される。

変化: 自然言語BI用のセマンティック層を、単一の非正規化テーブルではなく、正規化された複数データセットの関係として扱えるようになった。 確認: join key、cardinality、循環参照、many-to-many関係を棚卸しする

From Hugging Face to Amazon SageMaker Studio in one click

huggingface-blog | Products | AX担当 / エンジニア

Hugging FaceとAmazonは、Hugging Faceの対応モデルページからAmazon SageMaker Studioのcustomizationまたはdeployment workflowへ直接遷移できるdeep-link integrationを発表した。選択したモデルはStudio側に事前ロードされ、新しいStudio環境では権限が事前設定される。GPU quota availabilityもinstance selection内に表示され、必要ならService Quotasへ誘導される。

変化: モデル発見からSageMaker Studioでのfine-tuningやendpoint deploymentまでの初期設定手順が短縮された。 確認: 対象モデルがSageMaker連携に対応しているか確認する

python/v1.46.0

strands-agents-releases | OpenSource | エンジニア

Strands Agents harness-sdkのpython/v1.46.0が公開された。release notesでは、MCP output schemasの保持、MCP servers from JSON、local memory store、memory manager telemetry、middlewareのresult handlingやmodel-state isolationが含まれる。fixにはcontext-offloaderのpath confinement、multiagent graph resume、tool_trace、ContextWindowOverflowException、Bedrock guardContent qualifierの扱いなどが並ぶ。

変化: Strands系のエージェント実行で、MCP設定、Memory、Telemetry、multi-agent状態管理に関わる依存更新が入った。 確認: MCP servers from JSONで既存設定が同じschemaとして解釈されるか確認する

Anthropic is launching Claude Cowork on mobile and web

theverge-ai | Products | 管理者 / AX担当 / エンジニア

The Vergeは、AnthropicのClaude Coworkがmobileとwebに広がり、Max subscribersから順次展開されると報じた。記事内のAnthropic公式案内（claude.com）によると、Cowork sessionsはcloudで動くため、端末を閉じてもbackground tasksやscheduled tasksを継続できる。一方で、local file accessなどのfull experienceはdesktop app側に残るとされる。

変化: Claude Coworkの利用形態が、ローカルデスクトップ中心から、クラウド継続実行とモバイル確認を含むワークフローへ広がった。 確認: cloud processingとlocal processingで扱えるデータ、ファイルアクセス、ログの違いを確認する

Meta’s new Muse Image model can pull other Instagram users into AI photos

theverge-ai | Products | 管理者 / AX担当

The Vergeは、Metaの公式発表（about.fb.com）を参照し、Muse ImageがMeta AI app、Instagram、WhatsAppの画像生成機能を支えると報じた。Instagram accountを@ mentionすると、public photosを使ってAI画像に他ユーザーのlikenessを取り込めるとされる。Meta側は、ユーザーがAI reuseを制御できると説明しているが、実際の同意、通知、地域差は確認が必要です。

変化: 消費者向け画像生成で、公開写真と人物のlikeness再利用がプロダクト機能として前面に出た。 確認: public photosがAI画像生成に使われる条件とopt-outまたはcontrolの導線を確認する

Discord admits AI moderation bug wrongfully banned users over harmless images

techcrunch-ai | Policy | 管理者 / AX担当 / エンジニア

TechCrunchは、DiscordのAI moderation systemのbugにより、過去2か月で8,000人超が無害な画像を理由に誤BANされたと報じた。記事はDiscord SupportのXスレッドを参照し、類似性マッチングのfalse positiveがあり、人間レビュー前に即時BANしてしまうbugがあったと説明している。Discordは影響を受けたアカウントを復旧中としている。

変化: AI moderationの誤検知が、単なる分類精度の問題ではなく、アカウント停止という業務継続リスクとして表面化した。 確認: AI moderationのconfidence thresholdと即時制裁条件を確認する

Monitoring discriminative ML models using Amazon SageMaker AI with MLflow

aws-ml-blog | Infra | AX担当 / エンジニア

AWSは、Amazon SageMaker AI、MLflow、Evidentlyを使ってdiscriminative ML modelsのdata driftとmodel qualityを監視する実装例を公開した。baseline datasetをS3に保存し、training metricsやmonitoring reportsをMLflowに記録する構成です。記事は、Evidentlyがmodel driftを直接計算しないため、training時の指標との差分計算はcustom codeで補う必要があると明記している。

変化: SageMaker AI上で、managed monitoringだけでなくMLflowとEvidentlyを組み合わせたカスタム監視パターンが整理された。 確認: baseline datasetとground truth labelを継続的に取得できるか確認する

ひとこと更新

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

Written by

柿添貴士(TakashiKakizoe) profile photo

柿添貴士(TakashiKakizoe)

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

Fukuoka, Japan

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

NEXT SIGNAL

前後のAI Digest