2026年2月にNTTドコモおよびNECはAmazon Web Services（AWS）上に5Gコアネットワーク（以下、5GC）を構築し、国内初となるAWS上での5GC商用サービスを開始しました。 5GCとは、5G通信サービス全体を制御するコアネットワークを指します。加入者の認証・セッション管理からユーザーデータの転送制御に至るまで、通信事業者のサービス基盤として中枢的な役割を担うものとなります。 このAWS上の5GCを構築するにあたり、NTTドコモとNTTドコモビジネスはAI AgentとGitOpsを組み合わせた5GCの設計および構築の自動化を達成しました。 この取り組みについては3/2に ニュースリリース にて発表しておりますので、是非そちらもご参照ください。 本稿では、今回の取り組みのうち「AI Agentによる5GCの設計自動化」に焦点を当て、背景・課題・アーキテクチャを体系的にお伝えいたします。5GCに限らず、AI Agentを用いた既存設計業務の自動化をするためのノウハウ・具体的な構成の参考となれば幸いです。 背景 重厚長大な設計プロセス AI Agentを用いた解決 アーキテクチャ 統一的なインターフェースの作成 ナレッジベースを用いた既存ルールの参照 マルチエージェントによる柔軟性・拡張性の担保 MCPによるシステムとの統合 フロントエンド streamlit コンテナー AI Agentランタイム マルチエージェント実行基盤とエンドポイント管理 外部システム連携 可観測性とプロンプトチューニング チューニング システムプロンプトのチューニング ナレッジベースのチューニング 知見・ノウハウ フロントエンド AI Agent ランタイム チューニング まとめ 背景 本プロジェクトに先立ち、対象となる5GCの構築プロセスではCI/CDパイプラインの整備を実施していました。 このパイプラインではInfrastructure as Code（IaC）の原則に基づき、コードの変更を起点として、自動的にインフラの構築・アプリケーションのデプロイ・各種設定変更が実行されます。 また、すべてのインフラのコードや5GCアプリの設定、および5GCの設定値はGitリポジトリによって一元管理されており、いわゆるSingle Source of Truth（信頼できる唯一の情報源）を実現した状態にありました。 このように、5GCのシステムの状態はコードとして宣言的に記述されており、任意の時点における構成の再現・差分追跡が可能な状態となっていました。 その一方で、プロセス全体を効率化する上では、その起点となる「設計パラメータ」の正確な作成が前提条件となります。 今回の5GCのシステムでは、のべ数千にのぼるパラメータを設計する必要があり、これらは人手によって作成されていました。 加えて、デプロイ先のインフラはパブリッククラウド・プライベートクラウド・オンプレミスと多様であり、各インフラごとに異なる設計判断を要する状態でした。 この膨大かつ環境依存性の高いパラメータ設計が、プロセス全体の効率化をする上で主要なボトルネックとなっていました。 重厚長大な設計プロセス 一般的に複数チーム・複数ベンダーが協調する大規模なシステムの設計プロセスには、以下のような構造的課題が発生しえます。 設計に必要なドキュメントが多数存在し、それぞれ異なる記述方式・管理体制を持つため、設計全体の整合性を把握するためには相当の習熟を要する 各パラメータの設計ルールが別のファイルとして管理されており、仕様変更の際に関連箇所への反映漏れが生じやすい インフラ・ネットワーク・アプリケーションといった各レイヤーの設計が独立して行われており、レイヤー横断的な全体設計が困難である 長年の運用を通じて蓄積された経験則や判断基準が明文化されておらず、特定の担当者のみが知っている暗黙知が存在する 設計ドキュメントが組織やチームの境界によってサイロ化しており、担当領域外のエンジニアが必要な情報へアクセスすることが困難な場合がある 上記の課題が複合的に作用した結果、設計に時間を要し、待機時間が発生したり、レイヤー間の不整合に起因する手戻りが繰り返し生じることがあります。 さらに、システムは不定期なセキュリティのためのアップデートや機能追加があり、そのたびに設計プロセス自体の見直しと関係者間の調整が必要となるという構造になりえます。 今回取り組んだ5GCシステムにおいても例に漏れず、設計の開始から構築完了に至るまでには複数チームにわたる調整コストを含めて少なくない時間を要しており、これが新規システムやインフラの立ち上げ、構成変更を行う際の大きな制約となっていました。 AI Agentを用いた解決 これらの課題を解決するにあたり、以下の要件を満たすアプローチが必要だと考えました。 統一的なインターフェース：誰でも同じ方法で設計可能 不定期なアップデートへの耐性：ある程度システム仕様が変わっても追従できる柔軟性を保持 既存の設計ルールの保持：これまでのノウハウを捨てず活用可能 他レイヤーとの整合性：各レイヤー間の依存関係を加味した設計が可能 設計プロセスの自動化：人手によるパラメータ作成の削減 数千ものパラメータ設計プロセスを完全に自動化するシステムを1から開発することは容易ではありません。 しかし、全てを人手に頼り続けることにも限界があります。 そこで我々は「AI Agentによる自動設計」にチャレンジしました。 AI Agentで既存の設計プロセスを模擬させることができれば、自然言語で設計要件を受け取り、既存の設計ドキュメントを参照しながら、各レイヤーのパラメータを自律的に生成・調整することが期待できます。 また、設計範囲の異なる複数のAgentを組み合わせる仕組みを作ることで、レイヤーごとの設計ルールの変更や新レイヤーへの対応も柔軟に拡張できると考えました。 アーキテクチャ 上記の課題を解決するために、AI Agentを中心とした疎結合なマルチエージェントアーキテクチャを設計しました。 本アーキテクチャでは以下の構成要素にすることで課題解決を狙いました。 統一的なインターフェースの提供 ナレッジベースを用いた既存ルールの参照 マルチエージェントによる拡張性・追従性の担保 レイヤー間の整合性確認 MCPによるシステムとの統合 対象システムがAWS上に構築されていたことを踏まえ、今回はAWS上に構築された5GCの自動化から始めることとし、AI Agent実行基盤もAWS上に構築しました。 統一的なインターフェースの作成 設計者が統一されたインターフェースにて設計できるよう、Webインターフェースから自然言語で設計要件を入力できる仕組みを構築しました。 CLIの操作習熟や特定のパラメータフォーマットに関する事前知識を不要とすることで設計の敷居を引き下げることができると考えました。 ナレッジベースを用いた既存ルールの参照 既存の設計ルールを継承しながらパラメータを生成するため、これまでの手順書およびルールをナレッジベースに格納しています。 各Agentはナレッジベースを参照し、既存の設計ルールに準拠したパラメータを生成します。 新たな手順書やルールはナレッジベースのドキュメントとして追加するだけでAgentが即時に活用できるため、ナレッジの更新・管理コストも低く抑えられると考えました。 マルチエージェントによる柔軟性・拡張性の担保 不定期なアップデートへ追従可能な柔軟性と長期的な拡張性を確保するために、Agent-to-Agent（A2A）プロトコルを採用したマルチエージェントの構成にしました。 A2AとはAI Agent同士が相互に情報交換やタスク連携するための標準化されたインタフェースであり、各Agent間の直接的な依存関係を排除しつつ、疎結合な連携を可能とします。 これにより、複数のAgentが役割分担しながら協調動作するアーキテクチャを実現でき、高い拡張性および柔軟性を確保できます。 今回のアーキテクチャではインフラ層・アプリケーション層・コンフィギュレーション層といった各レイヤーに専用の設計Agentを配置し、それぞれが基本的に担当レイヤーのパラメータ設計を独立して実行しています。 特定レイヤーの対象が追加・削除された場合も、該当Agentを更新すれば対応可能であり、他Agentへの変更を最小化できる疎結合な設計となっています。 MCPによるシステムとの統合 各AgentがGitや外部システムと統一的かつ安全にやり取りするための通信基盤として、MCP（Model Context Protocol）を採用しました。 MCPはAI Agentが外部ツールおよびデータソースへアクセスするための標準化されたプロトコルであり、AI Agent とツールなどの間を疎結合にすることが可能となり、高い拡張性と再利用性を実現できます。 今回のプロジェクトではGitへのRead/Write操作や既存パラメータファイルの参照、ナレッジベースへのアクセスなどAgentがCI/CDと連携するための重要な基盤として機能しています。 各レイヤーのAgentは独立して動作しながらも、相互に通信してレイヤー間の整合性を確認しながら設計を進めます。 あるレイヤーの設計値を確定する際には、依存関係を持つ他レイヤーのAgentを協調させて動作させ、パラメータの矛盾が生じないよう調整されます。 設計済みのパラメータはGitOpsのワークフローに従ってリポジトリへ反映され、CI/CDパイプラインが自動的にデプロイを実行します。 これにより、「設計 → Gitへの反映 → 自動構築」というエンドツーエンドの自動化を実現しています。 次章では、フロントエンド、AI Agentランタイム、およびチューニングについて、具体的な内容を説明します。 フロントエンド AWS 上の Agent と人がやりとりを行う方法が必要になりますが、簡単にさまざまな人が使えるように今回は Web UI を提供することになりました。 今回、迅速に Web UI を構築し、再現性を担保するために以下の構成要素で構築しました。 Streamlit (GUI ライブラリ) コンテナー (GUI 提供サーバー) streamlit Streamlit は Agent とのやりとりをするための Web UI を簡単に構築できるようにしてくれる Python ライブラリです。 各種コンポーネントをブロックとして組み立てていくだけで簡単に Agent とやりとりするWeb UI を構築できます。 import streamlit as st # Web ページに以下の内容をレンダリング(内容は Markdown として解釈されます) # # My first app # Hello *World* st.write( """ # My first app Hello *world!* """ ) Streamlit は豊富な組み込みコンポーネントを供えているため、部品を追加・修正するだけで即座に反映を確認できます。 これによって迅速に開発を行えたため構築したいチャット Web UI をすぐに提供できました。 コンテナー Streamlit による Web UI はローカルにて開発をおこなっていました。 このアプリを AWS 上に展開していく際に AWS とローカルで環境が違うため差異を吸収する必要がありました。 その影響をなるべく少なくるすため環境差異を小さくできるコンテナー技術を採用しました。 今回は特に Docker Compose にすることでローカルでも AWS 上でも即座にアプリケーションのデプロイを行える環境を整えました。 AI Agentランタイム 本アーキテクチャにおけるAI Agentの実行基盤として、Amazon Bedrock AgentCoreを採用しました。 Amazon Bedrock AgentCoreとは、AWSが提供するフルマネージドなAI Agentを構築・実行・管理するためのランタイムおよび基盤機能を提供するサービスです。 各AgentはAmazon Bedrock AgentCore上のエンドポイントにデプロイされ、個別にバージョニング管理されています。 これにより、特定Agentのロジック変更やプロンプト改善をした場合でも、既存バージョンを維持したまま段階的な切り替えやロールバックが可能となっています。 マルチエージェント実行基盤とエンドポイント管理 Agent間の連携は、オーケストレーターAgentを中心とした制御構造を採用しています。 オーケストレーターAgentは、ユーザーからの入力を起点に、各レイヤー（インフラ・アプリケーション・コンフィギュレーション）に対応する設計Agentへタスクを分解・委譲し、各Agentからの結果を統合します。 この構成により、全体の制御フローを一元化しつつ、各Agentの独立性を維持しています。 A2AによるAgent間連携は、HTTPベースのエンドポイントにデプロイしています。 各AgentはAgentCore上に公開されたAPIエンドポイントを持ち、オーケストレーターAgentはこれらのエンドポイントに対してリクエストを送信することで、他Agentの機能を利用します。 リクエストには、以下のような情報を含める設計としています。 設計対象のコンテキスト（例：対象インフラや5GCの構成条件など） 他Agentから引き継がれた中間生成結果 実行対象タスクの種別（生成・検証・補正など） 各Agentはこれらの入力をもとに処理を行い、生成したパラメータおよびメタ情報をレスポンスとして返却します。 オーケストレーターAgentはこれらのレスポンスを統合し、必要に応じて再度別Agentへ問い合わせることで、レイヤー間の整合性を確保します。 また、Agent間通信においてはAmazon Bedrock AgentCoreのIdentity機能による認証・認可を適用し、呼び出し元Agentに応じたアクセス制御を実施しています。 これにより、意図しないAgent間の直接通信や不正な操作を防止しています。 外部システム連携 AI AgentからナレッジベースおよびGitLabなどの外部システムへアクセスする際には、Amazon Bedrock AgentCore Gatewayを経由し、AWS Lambdaを用いて処理を実行する構成としました。 これにより、Agentは外部システムの実装詳細を意識することなく、統一されたインタフェースで操作できます。 Lambda関数では主に以下の処理を担います。 ナレッジベースの検索・取得 GitLabリポジトリへのRead/Write操作、Merge requestの作成 AWS LambdaはVPCエンドポイントを介して他サービスと接続することで、外部システムとのセキュアな接続を実現しています。 可観測性とプロンプトチューニング 各Agentの実行ログおよび入出力（プロンプト・レスポンス）はAmazon CloudWatch Logsに集約され、システム全体の可観測性を担保しています。 これにより、以下のような運用が可能となります。 オーケストレーターAgentによる制御フローの追跡 各Agentの応答内容および生成結果の検証 エラー発生時の原因特定 特に後述するプロンプトチューニングにおいては、実際のログをもとに生成結果と期待値との差分を分析し、プロンプトおよびナレッジベースの改善を継続的に実施しました。 これにより、設計パラメータの生成精度と一貫性の向上を図っています。 以上のように、Amazon Bedrock AgentCoreを利用してエンドポイント管理機能やオーケストレーター中心の制御構造、A2Aによる協調実装ならびにセキュアな外部連携および可観測性基盤を統合することで、実運用に耐えうるマルチエージェント基盤として設計されています。 チューニング AI Agentが期待どおりの設計結果を出力するためには、チューニングの方針を定める必要があります。 前述のとおり、手順書やルールをドキュメントとしてナレッジベースに格納しています。 しかし、対象となるドキュメントは多種多様かつ更新頻度も高いため、闇雲に格納するだけでは期待どおりの出力は得られません。 そのため、AI Agentが適切な情報を参照できるよう、ナレッジベースの構成を整理する必要がありました。 一方で、ナレッジベースの整理だけでは AI Agent の振る舞いまでは制御できないため、これらはシステムプロンプトで制御する必要があります。 このように、「Agentに何を読ませるか」をナレッジベースで、「AI Agentにどう振る舞わせるか」をシステムプロンプトで、それぞれチューニングを行いました。 システムプロンプトのチューニング 各 AI Agent のシステムプロンプトは、汎用的な記述に留めています。 具体的には「あなたは○○レイヤーの設計を担当するAgentです」のように、担当範囲と役割を明示する程度としています。 その目的は、過度に詳細な指示を与えるのではなく、AI Agent が担当範囲内で自律的に判断・動作できる状態を実現するためです。 実際にプロンプトを汎用的な記述に留めることで、ある5GCの構成要素を複数設計するケースや異なる構成要素を新たに設計するケースなど、複数の設計パターンにシステムプロンプトの修正なしで対応できるようになりました。 ナレッジベースのチューニング ナレッジベースには、既存の設計ドキュメントに加え、これまで明文化されていなかった暗黙知もドキュメント化した上で格納しました。 ただし、暗黙知の全てをドキュメント化することは現実的とはいえませんでした。 実際の設計プロセスでは、複数のドキュメントを横断的に参照しながら必要なパラメータを選定する作業を繰り返す必要があり、ドキュメント間の表記揺れも存在したからです。 そこで、頻出する構築パターンに絞って暗黙知のドキュメント化を行い、表記揺れや横断的な参照を含むドキュメント群についてはLLMが柔軟に情報を抽出できるナレッジベースの特性を活かす構成としました。 また、ナレッジベースはレイヤーごとに分割し、各 AI Agent が自身の担当レイヤーに対応するドキュメントのみを参照する構成としています。 これにより、AI Agentが必要な情報のみを参照し、担当レイヤーに適した設計判断を行えるようになり、設計時間の短縮を達成しました。 なお、レイヤー間で依存関係を持つパラメータについては、前述のA2Aプロトコルを通じたAI Agent間の協調によって整合性を担保しています。 知見・ノウハウ フロントエンド Streamlit はコンポーネントを組み合わせればすぐに Web UI を開発できるところは非常に魅力的です。 一方、 Streamlit は以下のような特性をもつため複雑な Web UI を作っていこうとすると開発コストが増えていきます。 イベント毎に画面全体を再描画する仕組みであり、状態管理がセッションでしかおこなえない 各種コンポーネントを自由に組み合わせられず、正解となる組み合わせ方法は少なく、複雑なことができない そのため、 Proof of Concept として利用するのには非常に魅力的なライブラリでありつつ本番環境での利用には注意が必要です。 Streamlit を利用される際にはこの特性を考慮して適切な利用を心掛ける必要があります。 AI Agent ランタイム Amazon Bedrock AgentCoreを利用した知見として、AWSの各種サービス（AWS Lambda、Amazon IAM、Amazon Cloudwatchなど）とネイティブに統合されている点が挙げられます。 これにより、既存のAWS上のワークロードやアーキテクチャと親和性が高く、既存のリソースや運用設計を活かした形でAI Agentを組み込むことが可能でした。 結果として、セキュリティポリシーやネットワーク構成を維持しながらスムーズに導入できる点が、本構成における大きな利点となっています。 具体的には、外部システム連携はAWS Lambdaを通じて実装することで既存の処理ロジックやAPI連携資産をそのまま活用でき、Amazon IAMによる認証・認可を統一的に適用することでセキュリティポリシーの一貫性を維持できます。 また、ログおよび実行トレースはAmazon CloudWatch Logsに集約されるため、各Agentの挙動やプロンプト・レスポンスを一元的に可視化でき、トラブルシュートやプロンプト、ナレッジベースのチューニングを効率的に実施可能でした。 このように、Amazon Bedrock AgentCoreはAWSのエコシステムと密接に連携するようになっているため、既存環境への適用において変更適用負荷や設計変更を最小限に抑えることができました。 その結果、本プロジェクトにおいても、従来のCI/CDパイプラインやネットワーク設計、セキュリティ要件を維持したままAI Agentを組み込むことができ、スムーズかつ実用的な形での導入が実現できました。 チューニング プロンプトのチューニングにおいては、制約の強いプロンプトから段階的に汎用化していくアプローチが有効でした。 最初は汎用的なプロンプトでAI Agentに設計を進めさせていましたが、処理時間が想定以上にかかるケースがありました。 この原因がプロンプトにあるのかシステム構成にあるのかを切り分けるため、まず参照すべきドキュメントの順序や出力フォーマットを厳密に固定したプロンプトに切り替えました。 プロンプト側を固定することで、システム側のボトルネックを特定する狙いです。 その結果、Git上のパラメータファイル（約2,000行）の読み込みが処理時間増大の主要因だと分かりました。 これに対し、ファイルを固定部分と変更部分（約50行）に分離してAgentには変更部分のみを読み書きさせることで、処理時間を約15分から約5分へ短縮できました。 このように、プロンプトを固定化することは、ボトルネック早期解消に役立ちました。 汎用的なプロンプトに戻しても、処理時間が安定しました。 まとめ 本稿では、5GCの設計プロセスにおける課題に対し、AI Agentを組み合わせたアプローチにより、設計の自動化と効率化を実現したアーキテクチャについて紹介しました。 疎結合なマルチエージェント構成やナレッジベースの活用、AWSとの統合により、属人性の排除と再現性の高い設計プロセスを実現できることを示しました。 今後は、本アーキテクチャのさらなる高度化を進めるとともに、5GC以外のシステム設計や他領域への適用を視野に入れ、より汎用的かつ実用的なAI Agentの構築を実施する予定です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 週末の３連休は皆様いかがお過ごしでしたでしょうか？　リフレッシュされた状態で今週も技術のキャッチアップを進めていきましょう。 今週  3 月 26 日（木）には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください！ それでは、3 月 16 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 Amazon Bedrock AgentCore による、高度なネットワーク運用エージェントの構築 」を公開 深夜にネットワーク障害のアラートが届いたとき、複雑なクラウド環境のトラブルシューティングには膨大な時間がかかります。この記事では、Amazon Bedrock AgentCore の AI 機能を AWS のネットワーキングサービスと統合し、ネットワーク障害の診断と修復を自動化する高度なネットワーク運用エージェントの構築方法を解説しています。Interface & Integration、Security & Operations、Intelligence、Orchestration、Memory、Deployment、Evaluation の 7 つのビルディングブロックを組み合わせるモジュラーなアプローチが紹介されており、エージェンティック AI によるネットワーク運用の自動化に関心のある方におすすめの記事です。 サービスアップデート Amazon Bedrock がアジアパシフィック（ニュージーランド）リージョンで利用可能に Amazon Bedrock がアジアパシフィック（ニュージーランド）リージョンで利用可能になりました。Anthropic（Sonnet 4.5、Sonnet 4.6、Opus 4.5、Opus 4.6、Haiku 4.5）および Amazon（Nova 2 Lite）のモデルがクロスリージョン推論で利用できます。ニュージーランドのお客様にとって、より低レイテンシーで生成 AI アプリケーションを構築できるようになりました。 Amazon Bedrock にて Minimax M2.5 および GLM 5 モデルが利用可能に Amazon Bedrock のモデル選択肢が拡大し、GLM 5 と Minimax M2.5 が追加されました。GLM 5 は複雑なシステムエンジニアリングや長期的なエージェンティックタスクに最適化されたフロンティアクラスの汎用大規模言語モデルです。Minimax M2.5 はエージェントネイティブなフロンティアモデルで、効率的な推論とタスク分解に優れ、実世界の時間・コスト制約下で複雑なワークフローを完了するよう設計されています。エージェンティック AI のユースケースに取り組んでいる方にとって、新たな選択肢となります。 NVIDIA Nemotron 3 Super が Amazon Bedrock で利用可能に Amazon Bedrock にて NVIDIA Nemotron 3 Super が利用可能になりました。Mixture-of-Experts（MoE）アーキテクチャを採用したオープンモデルで、複雑なマルチエージェントアプリケーション向けに設計されています。長いマルチステップタスクにおいてもコンテキストを失わずに高速かつコスト効率の良い推論を実現します。重み、データセット、レシピが完全にオープンで、カスタマイズも容易です。 Amazon Bedrock AgentCore Runtime にて AG-UI プロトコルをサポート Amazon Bedrock AgentCore Runtime にて、Agent-User Interaction（AG-UI）プロトコルのサポートが追加されました。AG-UI は AI エージェントとユーザーインターフェース間の通信を標準化するオープンなイベントベースのプロトコルです。既存の MCP（ツール連携）や A2A（エージェント間通信）に加え、AG-UI によりエージェントをユーザー向けアプリケーションに統合できるようになります。テキストチャンクやツール結果のリアルタイムストリーミング、UI 要素の状態同期などが可能で、東京リージョン含む 14 リージョンで利用可能です。 Amazon Bedrock AgentCore Runtime にてシェルコマンド実行をサポート Amazon Bedrock AgentCore Runtime にて、実行中のセッション内でシェルコマンドを直接実行できる新しい API「InvokeAgentRuntimeCommand」が追加されました。テストの実行、依存関係のインストール、git コマンドの実行など、LLM による推論と並行して決定論的な操作を行う必要がある場面で、カスタムロジックを構築する必要がなくなります。東京リージョン含む 14 リージョンで利用可能です。 Amazon Bedrock AgentCore Runtime にて WebRTC による双方向リアルタイムストリーミングをサポート Amazon Bedrock AgentCore Runtime にて、WebRTC プロトコルのサポートが追加されました。既存の WebSocket に加え、UDP ベースのピアツーピア通信により低レイテンシーの音声・映像の双方向ストリーミングが可能になります。ブラウザやモバイルアプリケーションでの音声エージェント構築に最適で、Amazon Kinesis Video Streams のマネージド TURN やサードパーティ TURN など柔軟な構成が選択できます。東京リージョン含む 14 リージョンで利用可能です。 SageMaker HyperPod にてアイドルリソース共有による動的クラスター活用をサポート Amazon SageMaker HyperPod のタスクガバナンスにて、動的リソース共有機能が追加されました。チームが保証されたクォータを超えて未割り当てのコンピュートキャパシティをベストエフォートで借用できるようになります。管理者はアクセラレータ、vCPU、メモリなどのリソースタイプごとに借用上限を設定でき、高価な GPU インスタンスのアイドル状態を削減してクラスター全体の利用効率を最大化できます。東京リージョン含む複数のリージョンで利用可能です。 SageMaker Training Plans にて既存のキャパシティコミットメントの延長が可能に SageMaker Training Plans にて、AI ワークロードが予想より長くかかった場合にプランを延長できるようになりました。1 日単位で最大 14 日、または 7 日単位で最大 182 日（26 週間）の延長が可能で、API または SageMaker コンソールから実行できます。延長購入後はワークロードの再設定なしに中断なく実行を継続できます。 AWS にて NIXL と EFA の統合により大規模 LLM 推論を高速化 AWS にて NVIDIA Inference Xfer Library（NIXL）と Elastic Fabric Adapter（EFA）の統合がサポートされました。分離型 LLM 推論における KV キャッシュのスループット向上、トークン間レイテンシーの削減、KV キャッシュメモリ利用の最適化を実現します。NIXL は NVIDIA Dynamo、SGLang、vLLM などのフレームワークとネイティブに統合され、すべての EFA 対応 EC2 インスタンスタイプで追加コストなしで利用可能です。 AWS Neuron にて Amazon EKS の Dynamic Resource Allocation をサポート AWS Neuron の Dynamic Resource Allocation（DRA）ドライバーが Amazon EKS で利用可能になりました。Kubernetes ネイティブなハードウェア対応スケジューリングを AWS Trainium ベースのインスタンスに提供します。インフラチームが再利用可能な ResourceClaimTemplate を定義し、ML エンジニアはハードウェアの詳細を意識せずにテンプレートを参照するだけでデプロイできるようになります。分散トレーニングや分離型推論アーキテクチャのスケーリングが容易になります。 AWS Security Agent にてペネトレーションテストレポートのダウンロードをサポート AWS Security Agent にて、ペネトレーションテストレポートのダウンロード機能が追加されました。リスクレベル、信頼度、ステータスなどのフィルターに基づいてカスタマイズされたレポートを PDF 形式で作成できます。各レポートにはエグゼクティブサマリー、テスト範囲、手法の詳細、脆弱性情報とリスク評価が含まれます。ペネトレーションテストを数週間から数時間に短縮する AWS Security Agent の利便性がさらに向上しました。 AWS Partner Central にて AI エージェント機能を一般提供開始 AWS Partner Central にて、Amazon Bedrock AgentCore 上に構築された AI エージェント機能が一般提供開始されました。パートナーの営業チームに対してパイプラインインサイト、カスタマイズされた営業プレイ、次のステップの推奨をオンデマンドで提供します。会議のトランスクリプトやメモを共有するとエージェントが自動的にフィールドを入力し、案件を進めます。MCP を通じたプログラマティックなアクセスにも対応しており、CRM システムからの利用も可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

こんにちは、クラウドエース株式会社 技術本部 第三開発部の宮川です。 2026 年 3 月の「Agentic AI Summit '26 Spring」開催が目前に迫っています。今回のサミットが掲げるテーマは「生成から実行（Agentic）へ」。 AI が自律的に業務を完結させる時代の到来です。 3 月のサミットの前に、改めて 2025 年 秋に開催された「AI Agent Summit ’25 Fall」の内容を振り返ってみたいと思います。AI 活用は「生成」から、自律的に行動する「エージェント（Agentic）」へと進化を遂げようとしています。このような時代だからこそ、当時の大きなテ