2025 年 6 月 25 日・26 日に開催された AWS Summit Japan 2025 において、鉄道業界向けの 2 つのソリューションを展示いたしました。本記事では、展示ブースの内容と来場者の皆様からいただいたご意見をご報告いたします。 展示概要 今回の展示では、鉄道業界が直面する課題に対応する 2 つのアプローチをご紹介しました。 展示内容 生成 AI エージェントによる鉄道業界の業務改善　〜鉄道 AI エージェント 〜 複数の AI エージェント連携による部門横断型の業務支援 AI エージェントと MCP を用いた業務効率支援　〜 Strands Agents と MCP を組み合わせた効率的なリサーチ業務 〜 鉄道運行制御システムのクラウド活用に向けたアプローチ IEC 61508 をはじめとした国際規格に準拠しながら、クラウドの特性を活かした実装方法の解説 鉄道連動装置を例にした具体的な実装手法のご紹介 ※ こちらの記事では Part1 のみご紹介し、 Part2 はこちらの記事 でご紹介します。 1. 生成 AI エージェントによる鉄道業界の業務改善 人工知能 (AI) エージェントは、環境と対話し、データを収集し、そのデータを使用して自己決定タスクを実行して、事前に決められた目標を達成するためのソフトウェアプログラムです。目標は人間が設定しますが、その目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択します。 質問応答だけを所掌とする RAG とは異なり、AI エージェントはシステム間の連携も活躍の範囲となります。( 日本語のWorkshop はこちらを ご覧下さい) こちらの展示では、深刻な担い手不足が進む鉄道業界への一助として、生成 AI エージェントを用いた業務改善のためのアプローチを示しました。 1-1. マルチエージェントによる部門横断型タスクの効率化 日本の鉄道は高度で多様な技術に支えられています。この技術を保つため、鉄道業界では、例えば電気部門、信号通信部門、運行管理部門のように、部門ごとに専門性を持たせる手法が取られています。 しかし、部門ごとの高度な専門性が分離されているため、部門間での情報共有や調整が難しいといった課題があります。実際に、部門横断的な全体最適を図る計画タスクや調整タスクが複雑で業務負担になっていると、複数の鉄道業界のお客様から伺ったことがございます。 そこで、今回の展示では、計画タスク、調整タスクといった、部門横断型の大変な作業の効率化を、生成 AI マルチエージェントを用いて解決するためのソリューションを紹介しました。本ソリューションは、生成 AI のマルチエージェントの仕組みを取り入れており、親エージェントとしての部門間連携エージェントが、子エージェントとしての専門部門エージェント (図の例だと、電気部門エージェント、信号通信部門エージェント、運行管理部門エージェント) との連携を担ってくれるようになっています。そのためユーザは、部門間連携エージェントへ依頼をするだけで、必要部門との調整と連携が行われた上で回答を得ることができます。 展示のデモでは、ユーザがチャットから「保線業務効率化に向けた提案をお願い！」と依頼を行うと、部門間連携役の親エージェントが各専門エージェント (画面の例だと、保線部門エージェント、財務部門エージェント、駅運営部門エージェント) にタスクを割り振り、各部門エージェントとの連携、調整を行なった上での「保線作業効率化計画」の提案を、親エージェントが返す過程などが見られるようになっていました。親エージェントから呼び出される専門エージェントは、ユーザの依頼内容によって柔軟に変わる仕組みとなっていました。 また、親エージェントの最終回答を、Amazon Bedrock (Claude 3.7 Sonnet) により変換させ、報告書形式の見た目にすることができることもお見せいたしました。 もしかすると「これは単体の AI エージェントでも実現できるのでは ? なんであえてマルチエージェントを用いたの ? 」と気になった方もおられるかもしれません。たしかに、 1 つの AI エージェントで実現する仕組みも可能ではあります。しかし、単体の AI エージェントに複雑なことを行わせようとすると、エージェントが誤ったツールを呼び出したり、逆にツールを呼び出せない、プロンプトやコードが煩雑化するといった、さまざまな課題が出てきます。今回は、鉄道業界の高度な技術知識、多様な部門の連携といった、明確に複雑性の高いユースケースとなるので、マルチエージェントを採用しました。 マルチエージェントの仕組みを AWS で実現するには、さまざまな方法があります。上記のソリューションアーキテクチャ例のように、Amazon Bedrock のマルチエージェントコラボレーション機能を用いるのは 1 つの有効な手です。マネージドにマルチエージェントの機能を実現できるので、ビジネス要求を素早く実証し、運用負荷を抑えたい場合におすすめです。他にも、オープンソース AI エージェント SDK である Strands Agents を用いるのも有効です。Strands Agents を用いて、マルチエージェントを実装し、より高度なエージェント機能を、効率的に実現したい場合におすすめです。プログラミング (Python) での実装が必要ですが、自由度の高いマルチエージェントの実現を目指して、独自開発したエージェントを扱うことも選択肢の 1 つとなるでしょう。 AWS には、豊富な LLM モデルを扱え、生成 AI を扱っていく上で役立つ豊富な機能を活用できる、Amazon Bedrock があります。Amazon Bedrock を用いることで、進化の激しい生成 AI の最先端技術をいち早く取り入れ、ビジネスの差別化に繋がらない機能開発は Amazon Bedrock の機能群にお任せし、高機能な生成 AI ソリューションを効率的に開発、運用していただければと思います。 1-2. AWS Lambda 上で Strands Agents と MCP を組み合わせたリサーチ業務の効率化 MCP (Model Context Protocol) とは MCP は、AI エージェントへデータを効率的に共有するための共通規格です。これにより、異なるシステム間でのデータ連携が大幅に簡素化されます。 MCP の利用イメージ 実は、AWS 社内でも同様の課題があります。AWS Blog や AWS YouTube など、日々更新される最新情報をまとめる業務において、従来は手作業で情報収集・整理を行っていました。 従来の課題 複数のソースからの情報収集に時間がかかる MCP ツールのインストールが必要で導入の敷居が高い 情報整理後の資料作成も別途必要 Strands Agents と MCP を組み合わせた解決策 Strands Agents は、MCP ツールのインストール不要でブラウザ上で直接利用できるソリューションです。これにより、導入の敷居を大幅に下げることができます。 リサーチデモの実演 展示では、実際のリサーチ業務を想定したデモを実演しました。 MCP × マルチ AI エージェント の効果 MCP Server を複数の AI エージェント に登録することで、複数のタスクで構成される業務にも適用できます。 たとえば 情報収集エージェント: 複数の AWS 情報源から最新情報を自動収集 資料作成エージェント: 分析結果を基にプレゼンテーション資料を自動生成 の2つの AI が共通する MCP Server を利用できるため、リサーチのみならず、データに基づいた資料作成も可能になります。 この マルチ AI エージェント の発展形として、AWS の最新情報を AWS Blog や AWS YouTube MCP をリサーチし、最新情報の資料を紹介する資料作成のデモ展示も行いました。 実際にこの統合アプローチで、従来多くの時間がかかっていた資料作成業務を短縮することが可能になっています。 来場者の皆様からの反応 鉄道事業者の皆様から A 社様 「大変感動した。今日帰ったらすぐに試してみます！」 B 社様 「AI エージェント 同士で部門間のすり合わせを行うアプローチは面白そう。ぜひやってみたい」 C 社様 展示内容全般に対して良好な反応をいただき、具体的な導入検討への関心を示されました。 他業界からの関心 人材サービス業 「資料を AI エージェント で作ってくれる機能は非常に魅力的。すぐにでも使ってみたい」 以上が Part1 の展示内容です。 このほかの展示内容については Part2 で ご紹介いたします。 是非 続編の Part2 も ご覧ください。

(この記事は、 TSMC certifies Siemens EDA tools on AWS for N2/N3 process node technology を翻訳したものです。) 半導体業界は急速な技術進歩を続けており、設計ワークフローもより良いパフォーマンス、効率性、スケーラビリティのために進化することが求められています。この進化における重要なマイルストーンが Taiwan Semiconductor Manufacturing Company (TSMC) による AWS クラウド上での Siemens EDA ツールの認証です。これは世界中の半導体設計者やエンジニアに大きな利益をもたらします。この認証は世界で最も先進的な半導体ファウンドリの一つからの承認を示すだけでなく、柔軟性、パフォーマンス、イノベーションを提供するクラウド対応の Siemens EDA ワークフローへの移行を示すものでもあります。 “AWS は Siemens EDA および TSMC と協力し、TSMC の先進的な N2 および N3 プロセスノードの設計ソリューションをお客様向けに認証することができ、喜ばしく思います。このプロジェクトにより、お客様は EDA ワークロードを実行し、AWS 上のセキュアで信頼できる環境で TSMC とデータを共有し、協力することが可能になります。この共同の取り組みは、3 社間の緊密な協力関係とパートナーシップを証明するものです。TSMC の先進ノード認証は EDA にとって AWS へ移行する過程で重要なマイルストーンです。” -Ravi Poddar, Principal Advisor Hi-Tech and Semiconductor Industry, Amazon Web Services. このブログでは TSMC が Siemens EDA ツールを使用して N2/N3 プロセスノード技術を認証するために活用した、 AWS 上のセキュアにコラボレーションするためのチャンバーの技術概要を提供します。この取り組みは関係者間の技術シナジーと半導体業界におけるクラウドコンピューティングの重要性を示しています。 TSMC 認証プロジェクトのための Secure Cloud Chamber アーキテクチャ 図 1：AWS 上の TSMC 認証プロジェクトのための Secure Cloud Chamber アーキテクチャ 図 1 は AWS ソリューションの Scale-Out Computing on AWS (SOCA) を使用し、このプロジェクトに展開されたセキュアなクラウドアーキテクチャを示しています。このカスタムなアーキテクチャは、必要とされるインフラストラクチャに対応するスケーラブルな High Performance Computing (HPC) 環境や主要な資産とプロジェクトで用いる IP を保護するための厳格なセキュリティなど、TSMC の要件を満たすために開発されました 。このアーキテクチャには様々な実行待ちジョブを調整するスケジューラ、ユーザー認証と認可のためのディレクトリサービス (または LDAP) 、Siemens ツールライセンスを管理するライセンスサーバー、Auto Scaling コンピュートノード、ファイルシステムなど、いくつかの AWS サービスと HPC コンポーネントが含まれています。これらのコンポーネントは、TSMC Open Innovation Platform (OIP) Virtual Design Environment (VDE) に組み込まれています。VDE サブネットに加え、セキュアファイル転送サブネットは TSMC の担当者がオンプレミスサーバーから Process Design Kit (PDK) やその他のプロジェクトファイルを転送するためにチャンバーへアクセスすることを可能にします。DMZ (非武装地帯) サブネットは、Siemens の製品エンジニアが Virtual Private Network (VPN) を通じてチャンバーに接続し、作業することを可能にします。チャンバーがサポートする主要なデータフローと機能は以下の通りです： TSMC の担当者がオンプレミスサーバーから PDK、Graphic Data System (GDS)、およびその他のプロジェクトファイルを AWS 上の Amazon S3 バケットに転送するためのセキュアファイル転送サブネット。 スケジューラ、ディレクトリサービス (または LDAP) 、ライセンスサーバー、Auto Scaling コンピュートノード、ファイルシステムを含む VDE チャンバー。 Siemens の製品エンジニアが VPN を通じてチャンバーに接続し、作業するための DMZ サブネット。これには PDK と設計データへのアクセス、Siemens EDA ツールの試行、NICE DCV ディスプレイサーバーを使用したインタラクティブセッションが含まれます。 チャンバーに出入りするすべてのファイルは最初に S3 の一時バケットに保存され、自動スキャンによって検疫されます。マルウェア検出、フィッシング、その他の形式の脆弱性などのサイバーセキュリティ関連のチェックが実行されます。すべてのセキュリティチェックにパスしたのち、ファイルは S3 のクリーンバケットに移動し、チャンバー内で利用されます。 TSMC 認証プロジェクトのセキュリティ要件 AWS 上での認証プロジェクトに対する TSMC の主要なセキュリティ目標は 1) 監査ログとトレーサビリティ、2) 不正アクセスの防止、3) データセキュリティ、具体的には PDK の保護です。これらの目標を達成するため、いくつかの AWS サービスと機能を活用した一連のセキュリティコントロールを構築しました。チャンバーに実装された主要なセキュリティサービスとコントロールには以下が含まれます： ネットワークアクセスコントロールリスト (NACL) ： Amazon Virtual Private Cloud (VPC) の機能である NACL は VPC または VPC 内のサブネット内の IP および、プロトコルレベルでトラフィックを制御するために使用されます。実際には、NACL は AWS 上のネットワークファイアウォールとして機能します。デフォルトでは NACL によってすべての受信および送信トラフィックがブロックされ、TSMC が AWS 上のセキュアチャンバーへのアクセスを明示的に許可リストに登録したもののみが許可されます。 セキュリティグループ： ネットワークファイアウォールとして機能する NACL に加えて、セキュリティグループはインスタンスごとに AWS 上の受信および送信トラフィックを制御するための仮想ファイアウォールとして機能します。 VPC フローログ： VPC 内のネットワークインターフェイス間で送受信される IP トラフィックに関する情報をキャプチャします。フローログデータは分析のために Amazon CloudWatch Logs に保存されます。フローログはコンピュートインスタンスに到達するトラフィックを監視し、ネットワークインターフェイス間のトラフィックの方向も記録します。フローログデータはネットワークトラフィックパスの外部で収集されるため、ネットワークのスループットやレイテンシ（遅延）に影響を与えません。 オブザーバビリティとモニタリング： Amazon CloudWatch は、ログの記録とセキュリティの目標を満たすための統合されたモニタリングダッシュボードとして使用されます。VPC フローログ、 AWS CloudTrail 、 Amazon GuardDuty 、 Amazon S3 、アプリケーションログなど、プロジェクトで生成されるすべてのログは Amazon CloudWatch に統合され、不審なアクティビティがある場合にアラームとワークフローを起動できます。 AWS EventBridge はチャンバーにデプロイされたすべてのリソースを追跡し、リソースへの変更は通知機能で自動的に捕捉されます。 アクセス制御： 不正アクセスを防止するために Amazon Identity and Access Management (IAM) が使用されます。VPN はエンドデバイスからのユーザーアクセスを保護するために使用され、多要素認証はこれらのアカウントへの不正ユーザーのアクセスを防止するため、追加のセキュリティ層として機能します。Open LDAP ディレクトリサービスは、それぞれの資格情報と権限を持つユーザーを管理します。セキュリティグループと Web Application Firewall (WAF) は、IP、ポート、プロトコルレベルでネットワークおよびアプリケーションアクセス制御を実装するために使用されます。 データ保護： PDK の漏洩を防止するため、Amazon S3 や Elastic File Storage (EFS) を含むストレージレベルでの権限制御と暗号化を行います。標準的な AWS ネットワークおよびセキュリティコントロールに加え、チャンバーに出入りするすべてのファイルを自動的にスキャンして隔離するメカニズムを実装しました。これらのファイルはまず S3 の一時バケットに入り、すべてのセキュリティチェックが実行された後、チャンバー内で使用するために S3 のクリーンバケットに移動します。 テストと結果 プロジェクトの目標は TSMC の 7 つの Siemens EDA サインオフフローにおいて、TSMC の 2 nm および 3 nm 精度テストスイートから選択されたテストケースを TSMC の基準値と比較し、その結果を検証することでした。テストデータと基準値はクラウドのテスト環境に安全にアップロードされ、Siemens 内の技術チームがアクセスできるようしました。 テスト方法 精度テストの目的は、同じバージョンのツールと同じルールを用いた 2 つの同一条件の実行ランを比較することでした。2 つのランの唯一の違いはロケーションです。一方は TSMC のセキュアなオンプレミスチャンバー内で実行し、もう一方はセキュアな AWS 環境内で実行しました。テストケースデータ、セットアップファイル、設計ルールなどを含むテストパッケージの一部として基準値情報が転送されました。2 つの実行の比較結果のレポートファイルが生成され、TSMC によってレビューされました。 テスト戦略は様々でした。多数の小さなセルのテストパターンのテストだけでなく、完全なフルチップ設計のテストもされました。フルチップ設計に対しては、AWS クラウド環境内のホストマシンはプライマリホストと複数のリモートホスト間の通信を伴う分散モードで実行するように構成されました。個々のテストパターンやセルの場合、数千の個別ジョブがコンピュート環境に送信されました。テストの一環として、TSMC の基準値と比較し、自動的にテストレポートを作成して TSMC に提供しました。 クラウドの結果とオンプレミスの実行結果を比較して精度をテストし、複数のクラウドホストで並列ジョブを実行して精度を保証する並列性もテストしました。またトランジェント、 AC 、DC、RF、エージング解析のシミュレーションやモンテカルロ法を用いたマルチシミュレーションなど、様々なテストケースを実行しました。 結果 Calibre nmDRC、SmartFill、nmLVS、PERC、xACT、mPower では分散処理によるフルチップのテストを実行しました。個々のテストセルについては、複数のホストで複数のテストを並行して実行しました。これらのテストにおいては、クラウド上とオンプレミス上で一貫した同一の結果が得られました。 Solido TM Simulation Suite の一部である Solido TM SPICE と AFS の精度とスケーラビリティを、TSMC N2 プロセス技術の様々な回路でテストしました。テストケースには小規模から大規模の設計におけるスタンダードセル、アナログ回路、IO 回路 が含まれていました。シミュレーション解析には、TSMC が指定した設計の AC、DC、過渡解析、位相ノイズ、エージングが含まれていました。精度指標には各設計に適した帯域幅、位相マージン、DC ゲイン、周波数、電力、電流、位相ノイズ、遅延、スルーレート、リーク電流などが含まれます。スタンダードセルに対するモンテカルロトランジェントのマルチシミュレーションについても、スルーレートとセル遅延を精度指標として単一および複数のマシンで実行されました。すべての結果はクラウドとオンプレミスで一貫して同一の結果を示しました。 “Siemens EDA はこの 3 者間の協力により、AWS クラウドが TSMC のファウンドリおよび顧客データの保護に関する厳格なセキュリティ要件を満たしていることが示され、ファブレス半導体エコシステムが最も機密性の高いワークロードに AWS クラウドを使用する自信を持てるようになったことを嬉しく思います。また業界をリードする Calibre nmPlatform および Solido/AFS ワークロードを実行するため、高精度なコンピューティングキャパシティの追加に AWS クラウドを活用 できることの優れたデモンストレーションでもありました。”  – Michael White, Senior Director, Calibre Physical Verification. 結論 TSMC、Siemens EDA、AWS の共同プロジェクトは、クラウド環境とオンプレミス環境での結果が同等であることを実証したことに加え、スケーラビリティ、柔軟性、費用対効果との利点も確認されました。AWS 上での Siemens EDA のサインオフフローが認証されたことで、クラウドの高い信頼性が確認され、半導体業界での幅広い採用への道が開かれました。 このプロジェクトの過程は、半導体業界の絶えず増大する計算需要に応えるためのコラボレーションとイノベーションの重要性を示しています。クラウドコンピューティングは進化を続ける中で、半導体の設計と製造の未来を形作る上で極めて重要な役割を果たすことが期待されています。 “AWS と Siemens とのコラボレーションはクラウドにおける半導体設計ワークフローの大きな進歩を示し、TSMC の最先端プロセス技術を使用した次世代チップ設計を可能にするとともに、設計者に効率性と柔軟性の向上をもたらします。TSMC は引き続き EDA およびクラウドパートナーと緊密に協力して半導体設計の障壁を下げ、世界中の設計者によるチップでのイノベーションの迅速な立ち上げを支援していきます。” – Dan Kochpatcharin, Head of the Ecosystem and Alliance Management Division at TSMC 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。

(この記事は、 Accelerate chip-design verification process by running Siemens EDA Calibre on AWS を翻訳したものです。) Amazon はチップを設計するファブレス半導体企業でもあります。毎年複数のテープアウトを完了し、Kindle、FireTV、Echo などの製品を生み出しています。一方、Amazon Web Services (AWS) は Annapurna Labs の社内チームを通じてデータセンター運用向けの半導体設計を行っています。ARM ベースの CPU である AWS Graviton や、高性能 AI/ML 処理に使用される AWS Trainium および AWS Inferentia チップは、Annapurna を通じて発表された主力製品ラインの一部です 。 AWS と Siemens EDA は 2023 年 7 月に戦略的協業契約 (SCA) を締結し、EDA ワークロードの AWS への移行を加速させています。この提携を通じて両社は「Cloud Flight Plans」と呼ばれる一連のベストプラクティス、Infrastructure as Code スクリプト、本ドキュメントを含む Best-Known Method (BKM) を開発し、半導体業界のお客様が AWS 上で EDA ワークロードを迅速かつ効率的に展開・実行できるよう支援しています。 Siemens EDA は AWS と協力し Annapurna の製品の設計データに対し、nmDRC や nmLVS を含む複数の Calibre フローをベンチマーク検証しました。本稿ではこれらの検証結果、結論、推奨事項、およびクラウド上で Calibre を使い最良の結果を得るための一般的な BKM セットを紹介します。CAD、DevOps、IT エンジニアにとって、これらの調査は価値あるものとなるでしょう。 “Annapurna との proof-of-concept (POC) を通じて、AWS 上で Calibre を実行することで大幅なパフォーマンス向上を実現できることを検証しました。この POC から得られた結果と、AWS 上で Calibre フローを迅速に展開・実行するための実証済みの手法は Siemens Cloud Flight Plans を介してお客様にご覧いただけます。事実上無尽蔵な AWS の処理能力により、お客様は最適なコア数へシームレスに拡張でき、データセンター内のコンピューティングインフラの制約を克服できます。これにより、お客様はより高品質な設計のための分析を増やし、テープアウトスケジュールのリスクを軽減して、製品をより早く市場に投入することができます。” – Michael White, Senior Director Siemens EDA. 環境のセットアップ Reference Environment Toolkit は Virtual Private Cloud (VPC) を用いた AWS 上のセキュアチャンバー内で Calibre を管理および起動するために使用されます。AWS ParallelCluster を使用し、Amazon Elastic Compute Cloud (EC2) インスタンス、Amazon Elastic File System (EFS) 、FSx ファイルシステム、およびチャンバーで使用されるその他の AWS サービスをデプロイします。チャンバーが完全にデプロイされたのち、ユーザーはヘッドノードで入力するキューマネージャーコマンドを通じてジョブを送信します。SLURM スケジューラーがジョブの処理要件を満たすためにコンピュートノードのスケールアップとスケールダウンを管理します。 以下の表は Annapurna のフルチップ設計の仕様を示しています： 以下の表は本稿の検証で使用された EC2 インスタンスの仕様を示しています： ベンチマーク結果 Calibre nmDRC / 5nm 設計 図 A：リモートコア数の増加に伴う Calibre nmDRC 実行時間 図 B：リモートコア数の増加に伴う Calibre nmDRC のピークリモートメモリ使用量 図 A と図 B は N5 設計における Calibre nmDRC テスト結果を示しています。X 軸にはリモートコア数の増加に伴う実行時間 (図 A) と GB 単位のリモートメモリーの最大使用量 (図 B) を示しています。すべての実行で MTflex (Calibre の分散処理モードの一つ) を使用しました。これらの実行では、プライマリとリモートノードに同じマシンタイプ (r6i.32xlarge インスタンス) を使用する均質なクラスターを使用しました。 Y 軸はリモートコア数を示し、実行を重ねるごとに 2 倍ずつ増加させています。各実行では一貫して 64 コアのプライマリマシンを使用しました。 青色の線はベースラインを示し、Calibre 2021.1 (本番環境で Annapurna がこれらの設計に使用したバージョン) と TSMC のストックルールを使用しました。 緑色の線は Calibre プロダクトエンジニアが最適化したルールを使用した、より新しいバージョンの Calibre (2023.1) を示しています。これらの実行では OASIS ファイルからデータを読み込む代わりに、再利用可能な階層データベース (RHDB) から設計データを復元しました。これにより、実行ごとに約 20 分の時間が節約されました。点線はこれら 2 つの実行セット間における所用時間の削減割合を示しています。 オレンジ色の線は Calibre nmDRC Recon の結果を示し、ファウンドリルールのサブセットを自動的に選択して実行します。Siemens EDA は完全な Calibre の実行を行う前に、初期のラフな設計に対して Calibre nmDRC Recon を実行することを常に推奨しています。これにより、設計の大きなエラーを迅速に発見し、短いサイクルタイムで排除することができます。 ピークメモリのグラフは物理メモリに十分な余裕があったことを示しています。各リモートノードは 1TB の RAM を搭載しています。 Calibre nmLVS / 5nm 設計 図 C：マルチプロセッサコア数の増加に伴う Calibre nmLVS 実行時間 図 D：リモートコア数の増加に伴う Calibre nmLVS のピークメモリ使用量 これらの Calibre nmLVS の実行は -turbo オプション (マルチスレッド) を使用して単一の r6i.32xlarge マシン上で行われました。ホストマシンは 1TB のメモリを搭載していましたが、必要量をはるかに超えていたため、このジョブには c6i.32xlarge マシンで十分だったと考えられます。 これらは完全なルールセット (緑色の線) と Calibre nmLVS Recon (オレンジ色の線) の結果です。この結果は、テストに使用されたコア数全体にわたって良好なスケーラビリティを示しています。この場合の最適なオプショ ンは c6i.32xlarge ホスト (64 物理コア、256GB メモリ) で専用ジョブとして実行することです。 ベンチマークに基づくその他の調査結果と推奨事項 このセクションでは、Annapurna のベンチマークから得られた具体的な調査結果と、これらの観察に基づく推奨事項について説明します。 Calibre nmDRC Recon Calibre nmDRC Recon は完全なルールセットを短時間と低費用で実行し、設計の初期段階で大きなエラーの迅速な発見に役立ちます。Calibre nmDRC の Recon 機能は、設計の初期段階で最も適用可能な設計ルールのサブセットを自動的に選択します。これにより問題を早期に発見でき、設計チームは迅速にデバッグし将来検証作業に必要な時間と検証の実行総数を減らすことができます。 一般的にメモリ容量が仮想マシンの選択を決定する メモリは通常、クラウドで Calibre を実行するために必要なマシンの種類を決める重要な要素です。一般的に、プライマリマシンはリモートマシンよりも多くのメモリを使用します。メモリの推奨事項はテクノロジーノードによって変化します。より高度なテクノロジーノードではより多くのメモリが必要です。Siemens EDA は 7nm や 5nm において、Calibre nmDRC 実行にコアあたり 16 GB のメモリ量を推奨しています。r6i インスタンスはこの点で完璧です。r6i.32xlarge インスタンスには 64 物理コアと 1TB のメモリ (64 x 16 = 1024) を搭載しています。Annapurna の設計に対するすべての DRC テストでは、推奨メモリ量の半分未満でピークに達しました。 最新バージョンの Calibre を使用する 本稿で説明したベンチマークの実行に際しては、利用可能な最新リリースである Calibre バージョン 2023.4 を使用しました。以前のリリースと比較し、新バージョンでは全体的なパフォーマンスと多数のコアに対するスケーラビリティを向上させています。 再利用可能な階層データベース Calibre nmDRC 実行の最初のステップでは、OASIS または GDS 設計ファイルを読み込み、階層データベース (HDB) を作成します。この HDB は Calibre nmDRC ソフトウェアが特定のルールデッキと設計を効率的に実行するために不可欠です。Calibre での検証では、再利用可能な階層データベース (RHDB) が導入されており、これをディスクに保存して後続の実行の基礎として使用できます。RHDB を使用する利点は OASIS または GDS ファイルと比較してファイルの読み込み時間が大幅に短縮されることです。RHDB の構築には少ない CPU コア数が必要ですが、一般的に Calibre フローの中で最もメモリを集中的に使用するステップです。 ルールデッキを分割する Siemens EDA はファウンドリパートナーと緊密に協力して Calibre ルールデッキのバランスを取り、多数のコアにわたって適切にスケールし、Calibre の顧客が 1 日に複数の設計を完了できるようにしています。ただし、 3nm 以降では一部のルールチェックは他のルールよりも多くのコア数にスケールします。このため、ファウンドリは DRC 用の分割ルールデッキを提供し始めています。例えば、ファウンドリは DRC チェックの完全なセットを、電圧依存ルール用のファイル、静電気放電 (ESD) ルールとラッチアップチェック用の別のファイル、および残りのコアな DRC チェック用の三種のファイルに分割することがあります。これらの各ルールセットは他のものと独立して並行して実行できます。 ジョブに適したコア数を選択する ベンチマークは、500 から 1000 のリモート物理コア間でのパフォーマンススケーリング曲線の最適なポイントを示しています。このポイントはパフォーマンス (スループット) とコンピューティングコストの間の最良のバランスを表しています。この数値は設計データとプロセスに依存します。実際には、Calibre の顧客はフルチップの先端ノード DRC 検証に少なくとも 500 のリモートコアを使用することが予想されます。 結論 クラウドは EDA ワークロード向けに調整されたマシンへの無制限のアクセスを提供します。これにより、高度な EDA ツールのユーザーは望み通りに作業し、いつでもジョブを起動し、仕事を完了するために必要なリソースを自由に使用できます。本番やテープアウトの状況でも同様です。リソースの制約がないため、例えば、DRC 実行が終了してリソースを解放するのを待ってから LVS 実行を開始する必要はありません。複数のジョブを複数のフローで並行して実行することは、設計サイクルを加速し、直列に実行する場合と同じコストであるために有利です。 クラウドコンピューティングは初期コンセプト (IC) 設計から NPI (新製品導入) までの期間を短縮します。コンピューティング需要が増加する先端テクノロジーノードにおいては、より効果的です。ファブレス半導体企業として Annapurna Labs は高度な SoC を構築するための拡張性と弾力性のあるコンピューティングパワーを AWS クラウドに完全に依存しています。“IC 物理検証プロセスで Siemens EDA Calibre ツールを使用することで、特にバースト時に、AWS の分散クラウドインフラストラクチャとサービスを活用して DRC を効率的に実行する能力が劇的に向上しました” と Annapurna Labs のエンジニアリング担当副社長 Shahar Even Zur 氏は述べています。 詳細については、AWS の営業担当者にお問い合わせいただくか、 Siemens Calibre nmDRC  および AWS EDA ワークロード をご覧ください。 Siemens EDA について Siemens EDA は Siemens Digital Industries Software の一部門であり、EDA のソフトウェアとハードウェアにおけるテクノロジーリーダーです。Siemens EDA は設計とシステムレベルのスケーリングの課題に対応する実績のあるソフトウェアツールと業界をリードするテクノロジーを提供し、次のテクノロジーノードへの移行時により予測可能な結果をもたらします。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。

本記事は、2025 年 6 月 2 日に公開された Best practices for upgrading Amazon MWAA V1.x to V2.x を翻訳したものです。翻訳はプロフェッショナルサービスの佐藤が担当しました。 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、データ駆動型の意思決定をする組織にとって重要な基盤となっています。複雑なデータパイプラインを管理するためのスケーラブルなソリューションとして、Amazon MWAA は AWS サービスとオンプレミスのシステム間でシームレスなオーケストレーションを実現します。AWS がインフラストラクチャを管理していますが、お客様は責任共有モデルに従って Amazon MWAA 環境の更新を慎重に計画し実行する必要があります。最新の Amazon MWAA バージョンへのアップグレードにより、重要なセキュリティパッチを通じたセキュリティの強化や、DAG の解析の高速化とデータベース負荷軽減による性能の向上など、大きなメリットが得られます。また、エコシステムの互換性を維持しながら高度な機能を使用でき、AWS からの優先的なサポートを受けることができます。アップグレードを成功させるカギは、適切なソリューションを選択し、体系的な実装アプローチに従うことにあります。 この記事では、Amazon MWAA 環境のアップグレードのベストプラクティスを紹介し、最新バージョンへのシームレスな移行のためのステップバイステップガイドを提供します。 ソリューションの概要 Amazon MWAA は 2 つの主要なアップグレードソリューションを提供します。 インプレースアップグレード – この方法は、計画的なシステム停止時間が認められる場合に最適です。既存のインフラストラクチャに直接新しいバージョンをデプロイします。Amazon MWAA では、Apache Airflow バージョン 2.x 以降を実行している環境でインプレースアップグレードがサポートされています。バージョン 1.10.z 以前を実行している場合、これらのバージョンではインプレースアップグレードをサポートしていないため、新しい環境を作成してリソースを移行する必要があります。 カットオーバーアップグレード – この方法は、稼働中のシステムへの影響を最小限に抑えるのに役立ちます。対象のバージョンで新しい Amazon MWAA 環境を作成し、古い環境から新しい環境に移行します。 各ソリューションは、データの整合性とシステムの信頼性を維持しながらアップグレードを支援する、異なるアプローチを提供します。 インプレースアップグレード インプレースアップグレードは、アップグレードプロセスのためのメンテナンスウィンドウをスケジュールできる環境に適しています。このウィンドウ中、Amazon MWAA はワークフローの履歴を保持します。この方法は、計画的なシステム停止時間が認められる場合に最適です。これにより、履歴データが維持され、わかりやすいアップグレードプロセスが提供されます。また、この方法には、プロビジョニング中に問題が発生した場合のロールバック機能も含まれています。また、新しい環境を作成する必要がないため、リソースの使用も少なくて済みます。 AWS マネージメントコンソール で、1 回の操作でインプレースアップグレードを実行できます。このプロセスでは、多くのアップグレード手順を代わりに実行してくれるため、運用の手間を削減できます。 アップグレードプロセス中は、新しいタスクのスケジュールや実行はできません。Amazon MWAA はアップグレードプロセスを自動的に制御し、安全性を確保するための仕組みを組み込んでいます。プロビジョニングフェーズで問題が発生した場合、サービスは以前の安定バージョンへの復元を試みます。 インプレースアップグレードを開始する前に、DAG の互換性の問題がアップグレードプロセスに影響を与える可能性があるため、ターゲットバージョンとの DAG の互換性をテストすることをお勧めします。アップグレードを開始する前に、 Amazon MWAA ローカルランナー (注) を使用して DAG の互換性をテストできます。アップグレードは、コンソールで 新しいバージョンを指定 するか、 AWS Command Line Interface (AWS CLI) を使用して開始できます。以下は、AWS CLI を使用した Amazon MWAA アップグレードコマンドの例です： aws mwaa update-environment --name <value> --airflow-version <value> 注: Apache Airflow バージョン 2.9 以降では、Amazon MWAA の本番環境で使用されている Docker イメージがオープンソース化されています。MWAAと同一の環境でテストを行う場合は、 aws-mwaa-docker-images の使用を推奨します。ただし、MWAA ローカルランナーも引き続き、 MWAA でサポートされているすべての Apache Airflow バージョンでテストやパッケージング要件の確認に使用することができます。 次の図は、Amazon MWAA のインプレースアップグレードのワークフローと状態を示しています。 詳細については、 Amazon MWAA でのインプレースバージョンアップグレードの紹介 をご参照ください。 カットオーバーアップグレード カットオーバーアップグレードは、ダウンタイムを最小限に抑える必要がある場合の代替ソリューションを提供しますが、より多くの手動ステップと運用計画が必要です。このアプローチでは、新しい Amazon MWAA 環境を作成し、メタデータを移行し、環境間の移行を管理します。この方法は、アップグレードプロセスをより柔軟に管理できますが、インプレースアップグレードと比較して、より多くの計画と実行の労力が必要になります。 この方法は、複雑なワークフローを持つ環境で効果的に機能します。特にバージョンアップグレードと共に大きな変更を計画している場合に適しています。このアプローチにはいくつかの利点があります。本番環境のダウンタイムを最小限に抑え、環境を切り替える前に包括的なテストを実施し、必要に応じて元の環境に戻すことができます。また、移行中に設定を確認して更新することもできます。 カットオーバーアプローチについて、以下の点を考慮してください。2 つの環境を同時に実行する場合、両方の環境の料金が発生します。各 Amazon MWAA 環境の料金は、以下の要素に依存します： 環境の稼働時間 (秒単位の精度で 1 時間ごとに課金) 環境サイズ ワーカーの自動スケーリング容量 スケジューラー容量 AWS は、自動スケーリングされた追加のワーカーのコストを個別に計算します。 AWS Pricing Calculator を使用して、特定の構成のコストを見積もることができます。 既存環境と新しい環境を並行して稼働させる際のデータの重複や破損を防ぐため、べき等な DAG の実装を推奨します。Airflow スケジューラは、新しい環境で一部のメタデータテーブル (dag、dag_tag、dag_code) を自動的に設定します。ただし、以下の追加のメタデータコンポーネントの移行を計画する必要があります： DAG 実行履歴 Variables (変数) Slot pool の設定 SLA 違反の記録 XCom データ ジョブ記録 ログテーブル ダウンタイムを最小限に抑えることを優先し、追加の運用上の複雑性に対応できる場合は、このアプローチを選択できます。 カットオーバーアップグレードプロセスは、新しい環境の作成、新しい環境への移行、アップグレードの実行という 3 つの主要なステップで構成されています。以下の図は、全体のワークフローを示しています。 以下のセクションでは、カットオーバーアップグレードを実行するための主要なステップについて説明します。 前提条件 アップグレードプロセスを開始する前に、以下の手順を実行してください： Airflow のリリースノート と Amazon Managed Workflows for Apache Airflow の Apache Airflow バージョン を確認してください。 現在の環境設定とメタデータをバックアップしてください。 mwaa-dr PyPI パッケージを使用して、メタデータを Amazon Simple Storage Service (Amazon S3) バケットに保存するバックアップ DAG を作成し実行できます。詳細については、 Amazon MWAA での DAG の操作 をご覧ください。 DAG の互換性をテストしてください。 Amazon MWAA ローカルランナー 、または オープンソースイメージリポジトリ を使用して、DAG、requirements、プラグインを検証できます。 互換性テスト用のテスト環境を作成してください。ガイダンスについては、 Python 依存関係を管理するための Amazon MWAA のベストプラクティス をご覧ください。 新しい環境の作成 新しい環境を作成するには、以下の手順を実行してください。 AWS CLI を使用して、新しい環境設定のテンプレートを生成します： aws mwaa create-environment --generate-cli-skeleton > <new-env-name>.json 生成された JSON ファイルを変更します： バックアップファイル <env-name>.json から <new-env-name>.json に設定をコピーします。 環境名を更新します。 既存の環境から AirflowVersion パラメータの値を維持します。 必要に応じて他の設定パラメータを確認し更新します。 新しい環境を作成します: aws mwaa create-environment --cli-input-json <content of new-env-name.json> 新しい環境への移行 元の環境を新しい環境に移行するには、以下の手順を実行してください： mwaa-dr PyPI パッケージを使用して、リストア DAG を作成し実行します。 このプロセスでは、S3 バックアップバケットからメタデータを新しい環境にコピーします。 新しい環境に、元の環境から期待されるメタデータが含まれていることを確認します。 アップグレードの実行 バージョンアップグレードを実行するには、以下の手順を実施してください。 環境をアップグレードします: aws mwaa update-environment --name <new-env-name> --airflow-version <target-version> アップグレードのモニタリングをします: コンソールで環境のステータスを追跡します。 エラーメッセージや警告がないかモニタリングします。 環境が AVAILABLE に到達することを確認します。 移行のタイミングは慎重に計画してください。アップグレードの最中に元の環境でワークフローを動かし続けると、新旧の環境でワークフローの情報 (メタデータ) が食い違ってしまう恐れがあります。 クリーンアップ モニタリングを通じてアップグレードされた環境の安定性を確認した後、クリーンアップ作業を開始できます: AWS CLI コマンドを使用して、元の Amazon MWAA 環境を削除します: aws mwaa delete-environment --name <old-env-name> S3 バケットから未使用のバックアップデータを削除し、アップグレード用に作成した一時的な AWS Identity and Access Management (IAM) ロールとポリシーを削除し、DNS やルーティング設定を更新することで、関連リソースをクリーンアップします。 リソースを削除する前に、組織のバックアップ保持ポリシーに従い、コンプライアンス要件に必要なバックアップデータを維持し、アップグレード中に行った設定変更をドキュメント化してください。 このアプローチにより、テストの機会を確保しながら、必要に応じて元の環境に戻ることができる、制御されたアップグレードを実行できます。 モニタリングと検証 Amazon CloudWatch メトリクスを使用して、DAG 処理メトリクスとスケジューラーのハートビートに焦点を当てながら、アップグレードの進行状況を追跡できます。環境は、アップグレードプロセス中に UPDATING や CREATING などのいくつかの状態に移行します。環境が AVAILABLE 状態になったら、検証を開始できます。システムのアクセス性の確認、重要なワークフローの操作のテスト、外部接続の検証を行うことをお勧めします。詳細なモニタリングのガイドについては、 Amazon Managed Workflows for Apache Airflow のモニタリングとメトリクス をご参照ください。 主な考慮事項 インフラストラクチャ・アズ・コード (IaC) のプラクティスを活用して、環境管理の一貫性と再現可能なデプロイメントをサポートすることを検討してください。データを保護するため、 mwaa-dr を使用してアクティビティの少ない時間帯にメタデータのバックアップをスケジュールしてください。ワークフローを設計する際は、潜在的な中断に対処するためにべき等性のあるパイプラインを実装し、設定と依存関係のドキュメントを維持してください。 まとめ Amazon MWAA の効果的なアップグレードは、運用要件に合ったアプローチを選択することから始まります。インプレースアップグレードまたはカットオーバーアップグレードのいずれを選択する場合でも、入念な準備とテストにより、制御された移行を実現できます。利用可能なツール、モニタリング機能、推奨プラクティスを活用することで、ワークフローの運用を維持しながら、最新の Amazon MWAA 機能へのアップグレードを実現できます。 Amazon MWAA の詳細とコード例については、 Amazon MWAA ユーザーガイド と Amazon MWAA サンプルの GitHub リポジトリ を参照してください。 Apache、Apache Airflow、および Airflow は、米国および/またはその他の国における Apache Software Foundation の登録商標または商標です。 著者について Anurag Srivastava は、Amazon Web Services (AWS) のシニアビッグデータクラウドエンジニアとして、Amazon MWAA を専門に担当しています。 AWS 上でスケーラブルなデータパイプラインとワークフロー自動化ソリューションの構築に関して、お客様を支援することに熱心に取り組んでいます。 Sriharsh Adari は、Amazon Web Services (AWS) のシニアソリューションアーキテクトとして、ビジネス成果を起点として、AWS 上で革新的なソリューションを開発するお客様を支援しています。 長年にわたり、様々な業界のお客様のデータプラットフォーム変革を支援してきました。 テクノロジー戦略、データ分析、データサイエンスが主な専門分野です。 余暇にはスポーツを楽しみ、テレビ番組を一気見したり、タブラを演奏したりしています。 Venu Thangalapally は、シカゴを拠点とする AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャ、データとアナリティクス、コンテナ、アプリケーションのモダナイゼーションに関する深い専門知識を持っています。 金融サービス業界のお客様と協力して、ビジネス目標を、測定可能な価値を提供する安全でスケーラブルかつコンプライアンスに準拠したクラウドソリューションに変換しています。 Venu は、テクノロジーを活用してイノベーションと運用効率の向上を推進することに情熱を注いでいます。 仕事以外では、家族と過ごすこと、読書、長距離散歩を楽しんでいます。 Chandan Rupakheti は AWS のシニアソリューションアーキテクトです。 AWS では、アナリティクス、サーバーレス、AdTech サービスが重なり合う領域を主な専門としています。 情熱的な技術リーダー、研究者、メンターとして、クラウドにおける革新的なソリューションの構築に長けています。 プライベートでは、家族や友人と過ごすことや、音楽を聴いたり演奏したりすることを楽しんでいます。

正直に言うと、私はまだ ニューヨークの AWS Summit からから立ち直れておらず、 Amazon Bedrock AgentCore (プレビュー) や Amazon Simple Storage Service (S3) Vectors などのリリースでレベルアップするために最善を尽くしています。学ぶべき新しいことがたくさんあります！ 一方、信頼性とオブザーバビリティに焦点を当てた AWS ビルダーにとっては、エキサイティングな週でした。最も注目すべき発表は、マルチテナントアーキテクチャにおける最も根深い課題の 1 つである「ノイジーネイバー」問題に取り組む Amazon SQS フェアキューでした。あるテナントのメッセージ処理が共有インフラストラクチャを圧迫し、他のテナントに影響を与えた経験があるなら、この機能によってアプリケーション間でよりバランスの取れたメッセージ分散が可能になることをご理解いただけるでしょう。 AI の面でも、AWS は Amazon CloudWatch 生成 AI オブザーバビリティのプレビューリリースにより、オブザーバビリティ機能を引き続き強化しています。これにより、AI を活用した分析情報が監視ワークフローに直接取り込まれ、インフラストラクチャとアプリケーションのパフォーマンスパターンを新しい方法で理解できるようになります。また、 Amazon Connect の環境を管理している人にとっては、メッセージテンプレートの添付用に AWS CloudFormation を追加することで、さまざまな環境にわたって E メールキャンペーンのアセットをプログラム的にデプロイして管理することが容易になります。 7 月 21 日週のリリース Amazon SQS フェアキュー — AWS は、マルチテナントシステムにおける「ノイジーネイバー」問題を軽減し、共有インフラストラクチャ全体でよりバランスの取れたメッセージ処理とアプリケーションの耐障害性の向上を実現するために、Amazon SQS フェアキューを導入しました。 Amazon CloudWatch 生成 AI オブザーバビリティ (プレビュー) — AWS は、Amazon CloudWatch 生成 AI オブザーバビリティのプレビューを開始しました。これにより、ユーザーは高度なモニタリングと分析機能を通じて、クラウドインフラストラクチャとアプリケーションのパフォーマンスについて AI を活用した洞察を得ることができます。 Amazon Connect CloudFormation のメッセージテンプレート添付ファイルのサポート — AWS は、Outbound Campaign のメッセージテンプレート添付ファイル用の AWS CloudFormation のサポートを導入することで Amazon Connect の機能を拡張し、顧客がさまざまな環境にわたって E メールキャンペーンの添付ファイルをプログラムで管理および展開できるようにしました。 Amazon Connect 予測編集 — Amazon Connect では、新しい予測編集 UI が導入されました。これにより、コンタクトセンターのプランナーは、特定の日付範囲、キュー、チャネルにわたる予測をパーセンテージまたは正確な値で迅速に調整できるため、より迅速な人員計画が可能になります。 Amazon ElastiCache のブルームフィルタ — Amazon ElastiCache は、Valkey のバージョン 8.1 でブルームフィルタをサポートするようになりました。これにより、従来のセットと比較して 98% 以上のメモリ効率で、アイテムがセット内にあるかどうかをすばやく確認できるスペース効率の高い方法が提供されます。 Amazon EC2 Skip OS Shutdown Option — AWS は、インスタンスを停止または終了するときにオペレーティングシステムの正常なシャットダウンをスキップできる Amazon EC2 の新しいオプションを導入しました。これにより、アプリケーションの回復とインスタンスの状態遷移が高速化されます。 AWS Healthomics Git リポジトリ統合 — AWS Healthomics では、ワークフロー作成のための Git リポジトリの直接統合がサポートされるようになりました。これにより、研究者は、バージョン管理と再現性を実現しながら、GitHub、GitLab、Bitbucket のリポジトリからワークフロー定義をシームレスに取得できるようになりました。 AWS Organizations Tag Policies Wildcard Support — AWS Organizations は、タグポリシーでワイルドカードステートメント (ALL_SUPPORTED) をサポートできるようになりました。これにより、ユーザーは、特定の AWS サービスでサポートされているすべてのリソースタイプに 1 行でタグ付けルールを適用できるようになり、ポリシーの作成が簡素化され、複雑さが軽減されます。 注目のブログ IAM アクセスキーを超えて: 最新の認証アプローチ — AWS では、従来の IAM アクセスキーからより安全な認証方法に移行することを推奨しています。これにより、ID 管理への最新のより堅牢なアプローチを活用することで、認証情報の漏洩や不正アクセスのリスクを軽減できます。 近日開催予定の AWS イベント AWS re:Invent 2025 (2025 年 12 月 1 日〜 5 日、Las Vegas) — AWS の主力年次カンファレンスでは、ピアツーピア学習、専門家主導のディスカッション、貴重なネットワーキングの機会を通じて、共同イノベーションを提供します。 AWS Summits – クラウドコンピューティングコミュニティが集まり、交流し、協力し、AWS について学ぶことができる無料のオンラインイベントと対面イベントに参加しましょう。最寄りの都市、 メキシコシティ (8 月 6 日) および ジャカルタ (8 月 7 日) で開催されるイベントにご登録ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 シンガポール (8 月 2 日)、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18日) です。 原文は こちら です。

はじめに IoT カメラの活用は、監視、防犯、産業機器のモニタリング、スマートシティ、リテール分析など、さまざまな分野で急速に広がっています。それに伴い、カメラ映像をクラウドや AI と連携させるための接続方式や構成も多様化しており、用途に応じた最適なアーキテクチャの選定がますます重要になっています。 近年、クラウドコンピューティングの進化やエッジ AI の普及により、映像データの処理方法にも変化が見られます。従来は、すべての映像をクラウドに送って解析するのが一般的でしたが、最近ではエッジデバイス側でリアルタイムに処理し、必要な結果だけをクラウドに送信する方式も徐々に広がりつつあります。これにより、リアルタイム性の向上、ネットワーク帯域の節約、ストレージコストの削減といったメリットが期待できます。 こうした処理方式の多様化により、カメラの接続方式やデータ処理の設計においては、単なる映像の記録・送信にとどまらず、リアルタイム性、スケーラビリティ、コスト効率、セキュリティといった複数の要素を総合的に考慮することが求められます。システム全体の価値を最大化するためには、これらの要素のバランスをとったアーキテクチャ設計が重要です。 IoT カメラと AWS IoT の接続パターン IoT カメラのAWS IoTとの連携方法は、主に以下の図の4つのパターンが考えられます。 図1: IoT カメラと AWS IoT 連携の接続パターン ①は複数のカメラをエッジゲートウェイなどで集約する従来からの方法、②はカメラから Amazon Kinesis Video Streams へプロデューサーライブラリを使って直接接続する方法、③は①のゲートウェイをクラウドでホストし、VPNを使ってカメラに接続する方法、④はカメラでの推論結果を AWS IoT Core へ送信する方法です。ここで②と④はゲートウェイなどの中継装置を使わず、カメラ単体で実現可能なことからスモールスタートしやすく、オンサイトでのメンテナンス性が高く、コスト効率もよい方法といえます。一方で、Amazon Kinesis Video Streams プロデューサーライブラリのインストール機能やエッジ推論機能などカメラ側に高度な機能が必要になります。 i-PRO moducaと KVS Connect i-PRO 株式会社が提供するモジュールカメラ moduca は、豊富な選択肢があるハードウェア・モジュールを自由に組み合わせ、目的や用途に応じてBTO（Build To Order）ができるカメラです。moduca ではi-PRO 株式会社が提供する AI アプリケーションやユーザが作成した任意のカスタムアプリケーションを moduca の UNIX ベースの OS 上で動作させることができます。 図2: i-PRO モジュールカメラ（moduca） KVS Connect は富士ソフト株式会社が開発している moduca のカスタムアプリケーションで、 Amazon Kinesis Video Streams プロデューサーライブラリ を含めて moduca 向けにビルドされています。KVS Connect を使うとmoduca から Amazon Kinesis Video Streams へのビデオ送信を簡単に始めることができます 。 ここからは moduca と KVS Connect を例に、最近広まりつつある IoT カメラと AWS IoT をゲートウェイを介さずに直接接続するパターンについて説明します。 IoT カメラから Amazon Kinesis Video Streams への直接接続 ②の接続構成では AWS 上で Amazon Kinesis Video Streams の ストリームを作成し 、moduca に KVS Connect をインストールして設定します。さらに AWS IoT Core の 認証情報プロバイダー を設定することで、KVS Connect は AWS IoT Core またはユーザーの管理する認証局が発行する X.509 クライアント証明書 を使用して Amazon Kinesis Video Streams への接続を認証・認可することができます。 ユーザーは富士ソフト株式会社より KVS Connect を入手し、moduca の Web 画面 からインストール・設定を行います。 図3：moduca カスタムアプリケーションの設定画面 図4：KVS Connect の設定画面 IoT カメラでのエッジ推論と推論結果の AWS IoT Core への送信 ④の接続構成は moduca のカスタムアプリケーションを作成することで実現することができます。ユーザーは i-PRO 社の Development Partner Portal からダウンロードした i-PRO SDK を活用して任意のカメラアプリケーションを構築することができます。例えば Yolo8 を使った物体検知 と AWS IoT Device SDK を使った MQTT による AWS IoT Core との連携により AWS IoT と連携したエッジ推論と通知を行うアプリケーションを構築することができます。 クラウド録画とエッジ AI のアーキテクチャ例 ここまで見てきた内容を考慮して、クラウド録画とエッジAIを実現するシステム全体のアーキテクチャ例を紹介します。IoT カメラ、カメラアプリケーション、AWS のマネージドサービスを組み合わせることで 、IoT カメラから直接 Amazon Kinesis Video Streams へのクラウド録画を行いながら、カメラアプリでの動体検知に基づくリアルタイムアラートや検知イベントの検索など、ユースケースに合わせたシンプルな IoT カメラソリューションを End-to-End に構築することが可能になります。さらにクラウド上で画像を Amazon Bedrock の生成 AI モデルに解析させて、画像のコンテキストを分析させるなど、高度な推論を行うアプリケーションへ発展させることも可能です。 図5：クラウド録画とエッジ AI のアーキテクチャ例 まとめ 本記事では、カメラのクラウド接続パターンの中から、特にカメラ単体で実現できる方法を2つ紹介しました。1つ目は、Amazon Kinesis Video Stream プロデューサーライブラリを利用したクラウド録画、2つ目は、カメラでの推論結果を AWS IoT Core へ送信する方法で、いずれも moduca とKVS Connect を活用した具体例をもとに解説しました。 カメラの高度な機能と AWS のマネージドサービスを活用することで、カメラの接続をシンプルに実現でき、ユーザーは映像データを活用した AI 分析や高度なソリューション開発により多くの時間を割くことが可能になります。用途に応じた最適なアーキテクチャを選択し、AWS とカメラの活用をさらに広げていく参考になればと思います。 著者紹介 高橋 秀明　 i-PRO株式会社　シニアバイスプレジデント AI/IoTカメラとソフトウェアを「産業のビルディングブロック」として提供し、各業界のチェンジリーダーが生産性向上に挑戦できる環境を構築しています。柔軟なシステム設計を可能にするソリューションを通じて、社会と産業の進化に貢献します。 福嶋 征己　 富士ソフト株式会社 カメラソリューション担当として、カメラ×AIシステムの提案、開発・構築を行っています。最近では、Amazon Bedrock Agentsを活用したサービスの構想を進めており、生成AIをどのように活用できるかを検討しています。週末は一眼レフカメラを片手に、風景や子供の写真を撮影して過ごしています。 井上 昌幸　 アマゾンウェブサービスジャパン合同会社　IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。あなたのとっておきのアイデアを AWS と一緒にカタチにしましょう。

はじめに 6月25日～26日に開催されたAWS Summit Japan 2025において、「生成AIエージェントハッカソン」を実施いたしました。本ハッカソンは、AI時代における人と技術の新しい関係性を探求する画期的なイベントとなりました。多くの参加者の皆様、審査員の皆様、そして関係者の皆様のご協力により、素晴らしいイベントを開催することができました。本ブログでは、その詳細な開催報告をお届けします。 ハッカソンの主旨とテーマ テーマ：「使いたおして『○○』を実現するAIエージェント爆誕祭」 今回のハッカソンは、従来の「AIをどう活用するか」という問いから一歩進んで、「AIエージェントを限界まで使い倒すことで、人は何を実現したいのか」という本質的な問いに向き合うことをテーマとしました。 背景と狙い 生成AIが私たちの仕事や生活に欠かせないものとなる中、AIエージェントの進化により「人は何をすべきか」という問いがより切実になってきています。本ハッカソンは、参加者がAIエージェントを徹底的に活用することで、それでも残る人間固有の価値や目的を明確にすることを狙いとしました。 参加者の皆様には「○○」の部分に、AIエージェントを使い倒すことで実現したい目的を設定していただき、その実現に向けたソリューションの開発に挑戦していただきました。 より詳しいテーマと背景については こちら から ハッカソン開催ステップ 1. 募集〜参加確定〜予選まで 5月1日：QuizKnock伊沢拓司氏 / 鶴崎修功氏をゲストにお招きした「 ユースケース開発ワークショップ 」をオンライン開催　（ワークショップの動画は こちら から） 5月16日：採択1４チーム確定  （採択チーム一覧はこちらから 5月20日〜6月20日：採択チーム向けメンタリング実施 2. 予選（6月25日@ホテルニューオータニ幕張） 8分間のプレゼンテーション AWS審査員による審査により6チームが決勝進出 予選 3. 決勝（6月26日 @AWS Summit Japan Expoステージ会場） 7分間のプレゼンテーション 審査員による最終審査 表彰式 審査について 本ハッカソンでは、以下の観点で審査を実施しました： 有用性 ユースケースの明確さ（対応する機会） アプリケーションの品質 創造性 AI エージェントにより ○○ が実現できるか / AI エージェントが使いたおされることで○○が持続的に実現されるか プレゼンテーション（決勝のみ） なお、本ハッカソンの決勝では、多様な専門性を持つ2名の外部審査員を含む以下4名の審査員によって審査が行われました。 [審査員] 鶴崎修功氏（QuizKnock） 安野貴博氏（AIエンジニア/参議院議員） 山口能迪（AWS Developer Advocate） 松本鋼治（AWS シニア事業開発マネジャー） 予選について 予選では、全国から多数のエントリーをいただきました。各チームには事前にユースケースを提出していただき、それを判断材料として厳正な審査を行い、14チームを決勝進出チームとして採択いたしました。 予選は決勝の前日にあたるAWS Summit Japan初日の6月25日に、ホテルニューオータニ幕張で開催されました。採択された14チーム全てが8分間のプレゼンテーションを行い、6名のAWSの審査員による厳正な審査が実施されました。 予選会場では、各チームが開発期間中に磨き上げた作品を熱心に発表し、質疑応答では審査員から技術的な詳細や実装の工夫、今後の展開可能性について鋭い質問が投げかけられました。ここでの評価を経て、最終的に6チームが翌日の決勝戦への切符を手にしました。 参加チームが設定した「○○」は実に多様で、日常生活の課題解決から専門的な業務支援、新しいコミュニケーションの形まで、参加者の豊富な発想力と問題意識が反映されていました。フリマ販売の自動化、創作活動の支援、農業ビジネスのアシスト、家電と人、家電同士の対話、プロジェクトの円滑な引継ぎ、k8s技術学習の促進、引っ越し後の生活シミュレーション、思考の構造化、金融リテラシー向上、育児支援、組織エンゲージメント向上、ペット飼育サポート、レシピ動画を活用した映える献立作成など、AIエージェントを活用して実現したい目的の幅広さが印象的でした。 各チームのプレゼンテーション動画は こちら から 決勝について 決勝戦は、AWS Summit Japan 2025の会場である幕張メッセのAWS Summit Japan Expoステージで公開形式で実施されました。予選は非公開で行われましたが、決勝では多くのAWS Summit来場者の皆様に決勝進出6チームの発表をご覧いただくことができました。 決勝のナビゲーターには、QuizKnockの伊沢拓司氏とフリーキャスターの吉﨑智宏氏が登場し、巧みな進行で会場の熱気を最高潮に導いてくれました。両氏の絶妙な掛け合いと各チームへの的確なコメントにより、見どころもわかりやすく伝えられ、会場全体が一体となって各チームの発表を応援する雰囲気が醸成されました。 QuizKnock 伊沢氏、鶴崎氏、AIエンジニア安野氏が登場する決勝の動画は こちら から 各チームとも「使いたおして『○○』を実現するAIエージェント」というテーマを体現した、素晴らしい作品を発表しました。全てのチームに共通して言えることは、ユースケースやアーキテクチャーの素晴らしさもさることながら、洗練されたUIを兼ね備えていたということです。 AIエージェント時代の可能性について考える貴重な機会となりました。各チームの発表後には審査員との質疑応答も行われ、技術的な詳細や今後の展開について活発な議論が交わされました。 vvvv 審査員を務めるQuizKnock 鶴崎氏（左）、安野氏（右） 決勝の会場のようす ナビゲーターのQuizKnock 伊沢氏（右）、フリーキャスターの吉﨑氏（左） 審査員からの総評 各審査員から入賞チームに対して以下のようなコメントをいただきました。 最優秀賞：WhiteBoxお酒同好会「KanpAI」への評価 AWS松本氏：「『交流』ということにユースケースをフォーカスし、そこに紐づく打ち手を徹底してAI Agentを駆使して作りこんだ点が優勝へとつながった。コネクトを利用した電話かけにトライし、今後の改善についても触れていた点も加点要素。更に開発までAIで取り組んだということも加点要素となった」 AWS山口：「本物の製品のようで驚いた。飲み会以外に旅行などユースケースの広がりもある。継続性もユーザーに対するフィードバック設計が良い」 安野氏：「完成度が高い！！１ヶ月で作ったと思えないUIの完成度。」 鶴崎氏：「『これもやってくれるんだ！』ということの連続で個人的には1位です。使い倒している感じがありますね。」 優勝チーム WhiteBox お酒同好会 準優勝：チームぶち上げ「プロジェクト引継ぎAI」への評価 安野氏：「課題の選定と解決策がうまくマッチしていた。引継ぎでいつも苦労するので将来性高い。」 鶴崎氏：「プロジェクトを俯瞰できている人がいなくなるということが引継ぎの難しさだと思うので、AIが俯瞰役を担ってくれるのは非常にいいですね。」 準優勝チーム　チームぶち上げ 第3位：かっぱときゅうりと味噌「おそとびより」への評価 AWS山口：「子供がいる家庭向けにはかなりうれしい。似た手法で様々なユースケースに対応できそう。今後の展望も継続性が見られる」 安野氏：「子育て世代の悩みの解像度が高そう。プロトタイプを触ってもらいながら改善を重ねられていたのもGood.」 鶴崎氏：「子育てという、AIが技術の入りづらそうな分野へアプローチが良いですね。より直感的、誰でもすぐに使えるようになれば相当いいと思います。」 三位チーム かっぱときゅうりと味噌 その他注目チームへの評価 電通デジタル アドバンストクリエイティブ＆AIチーム「Clip Ninja」 　鶴崎氏：「『練習できる』のが魅力的に思えました。プレゼン資料がやや見づらいなと思ったので、プレゼン資料も助けてくれるといいと思いました。」 デストロイヤーズ　「KOPR」 鶴崎氏：「Kubernetes素人、ゲーム好きの私としてはぜひ遊んでみたいです。公開をお待ちしております！」 BAE-RECIPE 　鶴崎氏：「アプリ画面が非常に使いやすそうで、ユーザーフレンドリーでいいと思います。確かにYouTubeとかのレシピ、作ったことがないですね。」 審査員の皆様からは、技術的な完成度だけでなく、ユースケースの明確さ、継続利用の設計、プレゼンテーションの質など、多角的な観点から詳細なフィードバックをいただきました。 まとめ 今回の「AWS Summit Japan 2025 生成AIエージェントハッカソン」は、１ヶ月弱の短い期間にも関わらず、高い完成度をもつ作品が多数登場しました。この完成度の高さのもたらした大きな要因は生成AIにあると言ってもよいでしょう。 技術的な評価と成果 参加者の皆様が創り出したソリューションは、AIエージェントの技術的な可能性を大きく押し広げるものでした。特に今回のハッカソンで特筆すべきは、採択チームにアンケートを実施したところ、ほぼ全てのチームが開発にCoding Agentを使用していたという事実です。 この結果、これまでのハッカソンでは考えられないほどの完成度の高さを全作品で実現することができました。特にUIについては、ハッカソンのような短期間では実装し切れないことが多いにも関わらず、非常に洗練されたUIが各チームで実現されていました。これは、AIを活用した開発がもたらす生産性向上の具体的な証左と言えるでしょう。 技術的な評価ポイントとしては以下が挙げられます： マルチモーダルAIの活用：テキスト、音声、画像を組み合わせた自然な対話インターフェースの実現 外部システム連携：API連携やWeb scraping、データベース活用による実用的なソリューション構築 継続学習とフィードバック機能：ユーザーの使用パターンから学習し、継続的に改善されるシステム設計 AWS各種サービスの効果的な活用：Claude、Lambda、Connect、RDS等のAWSサービスを適材適所で組み合わせた実装 商用レベルのUI/UX：Coding Agentの支援により、短期間で実用レベルの直感的で使いやすいインターフェースを実現 特に最優秀賞のWhiteBoxお酒同好会チームが1ヶ月という短期間で商用レベルのUIと機能を実現したことは、Coding Agentをはじめとする現在のAI開発支援ツールの威力を示す象徴的な事例となりました。このような**「AIがAIを作る」時代の到来**を明確に示したハッカソンとなったことも、大きな意義の一つです。 今後への期待 今回のハッカソンで示されたのは、AIエージェントが単なる効率化ツールではなく、人間の可能性を拡張し、より豊かな生活を実現するパートナーとしての役割です。参加者の皆様が描いた未来像は、技術と人間が協働して創り出す、より創造的で充実した社会の姿を表しています。 さらに、本ハッカソン後の7月には、新たなAI コーディング環境「Kiro」が発表されました。これにより、AIを活用したアプリ開発がより身近に、より便利になっています。今回のハッカソンでCoding エージェントが示した可能性は、Kiroのような新しいツールによってさらに拡張され、より多くの方々がAIアプリケーション開発に参加できる環境が整いつつあります。 私たちは、今回のハッカソン参加者の皆様をはじめ、すべてのデベロッパーの皆様に、ぜひこれからもAWSを活用して、これまでできなかった何かを実現するアプリを作って欲しいと心から願っています。AIの力を借りることで、アイデアから実装までの距離は確実に短くなっており、誰もが自分の想像力を形にできる時代が到来しています。 AWSは今後も、お客様が最も大切にしていることの実現を支援するため、技術革新と価値創造の両面から取り組みを続けてまいります。今回のハッカソンで生まれたアイデアや議論が、より充実したAI時代の仕事・生活の実現につながることを期待しています。 最後に、本ハッカソンにご参加いただいた全ての皆様、審査員としてご協力いただいたQuizKnock鶴崎修功氏、安野貴博氏、ナビゲーターとしてご登壇いただいたQuizKnock 伊沢拓司氏、吉﨑智宏氏、そして開催にご協力いただいた関係者の皆様に心より感謝申し上げます。

本ブログは、株式会社 IMAGICA Lab. と Amazon Web Services Japan が共同で執筆しました。 データ転送サービスの現状 近年、大容量データをクラウドに移行するニーズが急速に高まっています。一方で、回線の帯域やセキュリティ、人員不足などの課題からスムーズな移行が難しいケースも少なくありません。IMAGICA Lab. では、こうしたお客様の課題解決を支援するソリューションとして、「IMAGICA Cloud Connect」の活用を提案しています。 「IMAGICA Cloud Connect」とは IMAGICA Cloud Connect は、データのアップロードを代行するサービスです。専用ネットワーク回線を活用し、特に AWS へのデータ移行においては、 AWS Direct Connect によるセキュアな通信環境を構築しています。これにより、1 週間で約 40TB 〜 50TB のデータ移行が可能です。 また、データ移行に使用する「可搬用デバイス」のレンタルサービスも提供しています。最小 1TB 〜 最大  57 TB の SSD、NAS を取り揃え、利用時期の 3 か月前から予約が可能です。輸送時には暗号化や物理的なセキュリティ対策も徹底し、安全性を最大限に確保しています。 サービス詳細やご利用料金等は 公式サイト よりご確認いただけます。 IMAGICA Cloud Connect のワークフロー STEP1．現在の環境から可搬用デバイスのコピー（お客様にて実施） 可搬用デバイスにお客様ご自身で AWS にアップロードしたいデータを格納いただきます。 IMAGICA Lab. では可搬用デバイスのレンタルサービスも提供しており、ラインアップは 1TB 〜 57TB の SSD・NAS があり、利用時期の 3 か月前から予約が可能です。 STEP2．可搬用デバイスの輸送 データ格納後の可搬用デバイスは、セキュリティを担保した特輸便を利用し、IMAGICA Cloud Connect 拠点まで安全に輸送されます。 セキュリティ面ではほかにも、デバイスの暗号化 / パスワードロック、鍵付きのハードケースの使用、開封防止シールの使用など、ソフトウェアとハードウェアの両面で安全性を追及しています。 STEP3．IMAGICA Lab.   にてアップロードを実行 IMAGICA Cloud Connect 拠点に到着した可搬用デバイスは、セキュリティカードを持った関係者のみが入室できるスペースで保管、アップロードを実施します。 データ転送の起点となる IMAGICA Cloud Connect 拠点と Direct Connect Location の間は、インターネットとは繋がらない閉域網で接続しています。AWS 環境には、IMAGICA Lab. が所有する AWS Direct Connect を用いて専用線で接続しています。 STEP4．データ確認、作業終了 データが正しく移行されていることをお客様にて確認いただき、作業は完了です。 デバイスレンタルサービスをご利用いただいている場合、デバイス内のデータ消去を行います。 なお、消去方式に関しては研究所レベルの復元ツールでも復元不可能とされている「Purge レベル」での処理を行います。お客様のご要望によっては物理破壊も対応可能です。 アーキテクチャ ■   インフラの検討 IMAGICA Cloud Connect に対しては、オンプレミス上で管理している自社データを Amazon S3 などに移行したいお客様からのご依頼機会が多数あります。 お客様のデータは個人情報や企業の機密情報など、極めて重要度が高く、また秘匿性も高いものが多い傾向にあります。 そのため、そのようなデータを移行するには、でき得る限り外部との接点を持たないような環境にする必要がありました。 そこで、お客様の重要なデータを安全に、かつ安心して Amazon S3 などに格納するために、もっとも重要な要素のひとつであるネットワークインフラの整備を行いました。 ■   データの経路 このネットワークインフラを通るデータの経路もそのひとつです。 パブリック接続経由で Amazon S3 にアップロードする場合にも、通信経路としては AWS のグローバルネットワーク内に閉じますが、さらなるセキュリティ向上を図るため、プライベート接続で AWS PrivateLink のエンドポイントを経由し、お客様の Amazon S3 バケットに到達する経路を構築しました。 ■   データ転送には   AWS DataSync これらのセキュリティを担保したネットワークインフラとデータ経路を基盤とし、お客様の重要なデータを IMAGICA Cloud Connect 拠点からお客様の Amazon S3 に対して高速に、安全に、かつ確実な転送を実現してくれる AWS DataSync を採用しております。 AWS DataSync は、データのコピー前とコピー後のチェックサムを照合し、データの転送が確実に行われていることがわかる証跡レポートを残し、データ転送を行います。 このように IMAGICA Cloud Connect は、お客様の重要なデータを安全、安心、確実に、短期間で Amazon S3 に転送するために、お客様に代わってデータアップロードを代行するサービスです。今後、さまざまなお客様にご利用いただけるようサービス拡充して参ります。 今後の展望 ・回線帯域の増強 ・ Amazon EFS などへのデータアップロード ・ AWS Data Transfer Terminal との協業 まとめ 本ブログでは、株式会社IMAGICA Lab. で提供しているデータ転送サービスの紹介と、その中でどのように AWS サービスを活用しているのかを紹介しました。Direct Connect、PrivateLink、DataSync を組み合わせることで、安心してデータをアップロードいただけます。本ブログがデータの転送方法を検討されている皆様の参考になりましたら幸いです。 著者について 橋本　秀三（Hashimoto Shuzo） 株式会社IMAGICA Lab. CM制作部 テクニカルグループ 映像業界に入りインターネット動画配信の黎明期や、デジタルシネマ普及初期を経験。映像のトランスコード、各種配信サービスローンチの技術サポート、システム開発案件の支援など映像/IT技術サービスに永く携わる。 伊藤　純子（Ito Junko） 株式会社IMAGICA Lab. CM 営業部 テクニカルプロデュースグループ 2013年、前身の株式会社IMAGICAに入社。クラウドを利用した映像データ管理サービスの販売や、スケジュール管理サービスの開発要件定義・企画などを担当。過去メディアのデータ化・マイグレーション作業のコーディネートも行う。 濵野 栞（Hamano Shiori） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト コンテンツプロダクション分野を得意とし、メディア・エンターテインメント業界のお客様に技術的な支援を行う。

本ブログは株式会社 BTM 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの伊勢田 氷琴です。 昨今、多くのお客様から生成 AI を活用した業務効率化についてご相談いただくようになりました。特に、複数のシステムを管理する企業様においては、システム調査や障害対応における関係者間のコミュニケーションコストが大きな課題となっています。 DX 推進事業や IT エンジニアリングサービスを展開する 株式会社 BTM 様 は、自社構築システム調査に対する頻繁な問い合わせ対応と、これに伴って関係者間で発生するコミュニケーションコストの課題を解決するため、 Amazon Bedrock を活用した AI エージェントシステムを構築されました。本記事では、生成 AI と MCP（Model Context Protocol）を組み合わせた革新的なシステム調査自動化の取り組みについてご紹介します。 お客様の状況と課題 株式会社 BTM 様は、従業員数 196 名（2025 年 2 月末時点）の企業として、DX 推進事業と IT エンジニアリングサービスを中核事業とされています。IT エンジニアリングサービスでは、ソフトウェアやシステムの開発に関するサービスを提供し、経験豊富なエンジニアが技術力をもとにお客様の課題解決を行っています。また、DX ソリューションサービスでは、コンサルティングからシステムやIT インフラの設計・構築・運用まで一気通貫でご支援されています。 多数のシステムを管理するシステム運用者として、BTM 様は深刻な課題に直面していました。システム調査を行う際、営業チーム、アプリチーム、インフラチーム、業務部門など多くの関係者とのやり取りが発生し、多大なコミュニケーションコストが生じるというものです。 具体的には、同じ説明を繰り返す必要がある、人によって回答が食い違う、情報が集約されない、必要な情報が揃わない、違うチームへ情報を渡す際に整理が必要になるといった問題が現場では日常的に発生していました。結果的にラウンドが異なる関係者間の情報連携に多大な工数がかかり、迅速な調査を実施しづらい状況でした。 さらに、システム管理者や担当エンジニアが複数のプロジェクトやシステムを担当する場合もあり、限られた時間の中でシステム調査に多くの工数を割きづらいという制約もありました。従来のシステム調査では 1 時間から半日を要しており、1 日に 5 件程度発生する調査依頼に対して、営業担当から詳細をやり取りし、結果を書面で返答するという手間のかかるプロセスが必要でした。 解決策の検討 これらの課題を解決するため、BTM 様は生成 AI を活用したシステム調査の自動化に着目されました。特に、非エンジニアからの問い合わせを生成 AI と MCP を使って自動で調査する仕組みの構築を検討されました。 AWS サービス、特に Amazon Bedrock の採用を決定された理由は、その高い性能と日本語対応の充実にあります。また、オープンソース AI エージェント SDK である Strands Agents を活用することで、わずか数行のコードで AI エージェントを構築・実行できる点も大きな魅力でした。 Strands Agents は、シンプルなエージェントのユースケースから複雑なものまで、そしてローカル開発から本番環境でのデプロイまで対応することができ、実際に AWS の複数チームでも既に Amazon Q Developer 、 AWS Glue 、VPC Reachability Analyzer などの本番環境で AI エージェント基盤として利用されている実績があります。 実装の詳細 BTM 様は、Strands Agents を MCP サーバーと LLM を結びつける基盤として活用されました。MCP とは、生成 AI がツールと連携する方法を標準化したプロトコルであり、MCP サーバーはそのツールに接続するためのサーバーです。MCP サーバーを使用することで生成 AI がツールとしてデータベースへのアクセス API を利用したり、インターネット検索 API を利用できるようになります。 システム構成は以下のようになっています。ユーザーインターフェースとして Slack を活用し、バックエンドには Amazon API Gateway 、 AWS Lambda を使用しました。AI エージェントには Strands Agents を採用し、AWS Lambda に strands モジュールを実装されました。 将来的には、非同期の呼び出しに対応するために、Amazon SQS と Amazon SNS を利用してキューイングすることも検討されています。 AI エージェントの具体的な実装方法については、次のようにしました。まずエラーや障害データ、ログ等が格納されている Amazon Aurora および Amazon DynamoDB 、 Amazon CloudWatch に対してアクセスを可能にする MCP サーバーをコンテナとして Amazon ECS on Fargate でホストします。そして、これらの MCP サーバーを Strands Agents にツールとして渡しました。このようにすることで、AI エージェントは自分が持つツールとその役割を認識し、ユーザーからのリクエストに応じてツールを使い分けながら必要な情報を集め、ユーザーにフィードバックすることが可能となります。 実際のアプリケーションログでは、ユーザからのリクエスト内容を踏まえて、エージェントがどのデータベースにどのようなクエリを発行し、データをクエリした結果を元に回答内容を生成する様子が確認できます。また、日本語に対応した Amazon Bedrock Guardrails を利用して、関係のない問い合わせをブロックする機能も導入されました。 使用している 基盤モデル は Claude 4.0 Sonnet で、高い精度での日本語対応と複雑な推論能力を活用されています。 導入効果 このシステムの導入により、BTM 様は劇的な効果を実現されました。最も顕著な成果は、従来半日を要していたシステム調査時間を最短で10分ほどに短縮したことです。これにより、エンジニアはより本質的な開発業務に集中できるようになりました。さらに、関係者間で必要になる冗長なコミュニケーションが不要となることで、PM のトラブルシュート工数を95%削減しました。 定性的な改善としては、日本語対応した Guardrails を利用し、無関係な問い合わせを効果的にブロックできるようになりました。さらに、開発 AI エージェントの OSS である Cline とそのバックエンドに Amazon Bedrock を使うことで、プロジェクト開始時の開発工数の見積もり40時間に対して、実開発時間を5時間に短縮し、全体で90%の工数を削減することに成功しました。 今後の展開 BTM 様は、今回構築したシステムを同じ悩みを抱えている企業様へ展開していきたいと考えられています。システム調査の自動化という共通課題を持つ企業に対して、この革新的なソリューションを提供することで、業界全体の効率化に貢献したいという意欲を示されています。 お客様の声 株式会社 BTM クラウドインフラ事業部 部長補佐 瀬﨑 優太朗 様からは、以下のようなコメントをいただいています。 「Amazon BedrockでAIエージェントを構築する事で、半日かかっていたシステム調査時間を10分に削減。システム運用保守業務上、ユーザーへの問い合わせ対応が迅速化しました。」 まとめ BTM 様の取り組みは、生成 AI と MCP を組み合わせた革新的なシステム調査自動化の事例として、多くの企業にとって参考になるものです。Amazon Bedrock と Strands Agents を活用することで、従来の手作業による調査プロセスを大幅に効率化し、エンジニアがより価値の高い業務に集中できる環境を実現されました。 このような生成 AI エージェントを活用した業務効率化の取り組みは、今後ますます重要になってくると考えられます。BTM 様の成功事例が、同様の課題を抱える企業様の参考となれば幸いです。 株式会社BTM：瀬崎 優太朗様（右） Amazon Web Services Japan : アカウントマネージャー 浜崎佳子（左）、ソリューションアーキテクト 伊勢田 氷琴（中央）

自動車業界は、車両がメカ主体のシステムから高度なコンピューティングプラットフォームへと進化する中で、大きな変革期を迎えています。この進化の中心にあるのが、SDV (ソフトウェア定義車両) であり、ソフトウェア機能が業界のイノベーションと差別化を牽引し続けています。現代の車両には、安全システムからドライバー支援、インフォテインメント機能まで、複数の電子制御ユニット（ ECU ）にわたって1億行ものコードが含まれています。 自動車システムにおけるハードウェアとソフトウェアの関係性の管理は、特に安全性、セキュリティ、および AUTOSAR （AUTomotive Open System ARchitecture: 車載ソフトウェア開発の国際標準規格 ）などの業界標準への適合性を確保する際に課題となります。 AUTOSAR は 車載組込みソフトウェア の標準化の基盤として機能し、ソフトウェアアーキテクチャ、通信プロトコル、開発手法を包括的なフレームワークとして提供しています。自動車メーカーは AUTOSAR 標準に準拠することで、厳格な機能安全要件を満たしながら、システムの相互運用性と拡張性を確保することができます。 これらの課題に対応するため、 Amazon Q Developer は、一般的な統合開発環境（ IDE ）および Amazon Web Services, Inc. (AWS) Management Console と連携する AI 駆動の専門的なコーディング支援ツールを提供しています。このツールは、コードスニペットの生成と説明、文脈に応じたドキュメンテーションの提供、コードの提案、リファクタリングと最適化の支援、デバッグとトラブルシューティングのサポート、そして C 、 C++ 、 Python を含む様々なプログラミング言語のサポートを通じて、自動車ソフトウェア開発者を支援します。顧客からは、 初期開発が 25% 速く なり、 開発者の生産性が最大 40% 向上 したとの報告があります。 このブログでは、自動車ソフトウェア開発者が Amazon Q Developer を使用して AUTOSAR classic の C/C++ コードを生成する方法について、実践的な例を示します。さらに、 AUTOSAR ソフトウェアコンポーネントを定義する XML （ eXtensible Markup Language ：拡張可能なマークアップ言語）モデルの作成を効率化するための Python の活用方法を探り、業界標準を維持しながら自動車ソフトウェア開発のワークフローを加速する方法をご紹介します。 前提条件： このブログで説明されているデモを自身の IDE で実行するには、以下を確認してください： インストールガイドに従って、お好みの IDE に Amazon Q Developer プラグインをインストールする。 個人のコンピュータに Python と C のプログラミング環境をセットアップする。 **Amazon Q Developer は AWS アカウントがなくても利用可能で、無料利用枠に含まれています。 Amazon Q Developer ライセンスのアップグレードに関心のあるお客様は、 こちら で詳細をご確認いただけます。 重要な注意点として、 Amazon Q Developer のコード生成は、ユーザー定義の標準への準拠を保証するものではなく、開発者は生成されたコードを確認し検証する必要があります。また、生成 AI の非決定論的な性質により、 Amazon Q Developer は以下の例で示すものとは異なる結果を生成する可能性があります。なお、以下のコード例は本番環境での使用を想定したものではありませんのでご注意ください。 AUTOSAR classic ソフトウェア開発の加速化 – ソリューション概要 Amazon Q Developer が開発者をどのように支援できるかを示すため、以下の3つの簡単な例を説明します： ユースケース 1 – AUTOSAR の C/C++ を使った、 LED の点滅とユニットテストの生成 ユースケース 2 – AUTOSAR の C/C++ を使った、ECU から CAN メッセージの送信 ユースケース 3 – AUTOSAR の Python を使ったパッケージコンポーネントを定義 これらの例は、 AUTOSAR の開発における一般的かつ初心者にも分かりやすいユースケースを示しています。学習目的で簡略化されていますが、実際の自動車アプリケーションに直接対応しています。例えば、 LED の制御は、周囲光センサーに基づく自動ヘッドライト点灯などの量産車の照明システムで見られる論理パターンと類似しています。 CAN メッセージングの例は、トランスミッション ECU からメーター表示への速度情報の送信など、車両データの伝送方法を示しています。 ユースケース 1 – AUTOSAR の C/C++ で LED の点滅とテストケースおよびユニットテストの生成 まず、 Amazon Q Developer のインラインコード補完と推奨機能が、機能的なコードと対応するユニットテストを自動的に生成することで、ソフトウェア開発者の AUTOSAR 開発をどのように効率化できるかを実証します。基本的な LED 点滅アプリケーションを例として使用し、このツールが AUTOSAR タスクを作成し、機能を検証するためのユニットテストを生成する方法を示します。 始めるには、「前提条件」セクションで説明したように、 Amazon Q Developer プラグイン をインストールしたIDEを開きます。 Amazon Q Developer で認証 した後、プロジェクトで「 examplec1.c 」という新しい C ファイルを作成し、以下のサンプルコードをコピーします。このコードには、 AUTOSAR 基盤の LED 点滅アプリケーションに必要なヘッダーと LED ピン設定が含まれており、 Amazon Q Developer に生成すべきコードの種類とユースケースのコンテキストを提供します。 サンプルコードの開始： #include "Dio.h" /* AUTOSAR DIO (Digital Input/Output) module header */ #include "Os.h" /* AUTOSAR OS (Operating System) module header */ /* AUTOSAR RTE (Runtime Environment) generated headers */ #include "Rte_Main.h" /* LED pin configuration */ #define LED_PIN 0x01U これで基本的な LED ピン設定のセットアップができたので、 Amazon Q Developer を使用して LED を点滅させる AUTOSAR タスクを作成しましょう。 IDE で、前のステップで example1.c ファイルにコピーしたサンプルコードの下の新しい行に以下のコメントをコピーしてください（図 1 に示すとおり）。 サンプルコメント： /* Create an AUTOSAR task for a LED blinking */ カーソルをこのコメントの末尾に置いて Enter キーを押してください。 Amazon Q Developer はこのコメントを解釈し、 LED 点滅タスクに適した AUTOSAR 準拠のコードを生成します。 **注意 ： Amazon Q Developer は非決定論的であり、以下に示す推奨コードと同じものが生成されるという保証はありません** 図 1 ： Amazon Q Developer を使用して LED 点滅タスクの生成を支援 コード推奨を受け入れるには、 Tab キーを使用します。すると、ファイルは以下のコードのようになります： 更新されたサンプルコード： #include "Dio.h" /* AUTOSAR DIO (Digital Input/Output) module header */ #include "Os.h" /* AUTOSAR OS (Operating System) module header */ /* AUTOSAR RTE (Runtime Environment) generated headers */ #include "Rte_Main.h" /* LED pin configuration */ #define LED_PIN 0x01U /* Create an AUTOSAR task for a LED blinking*/ TASK(LedBlinkTask) { static boolean led_state = FALSE; /* Toggle LED state */ led_state = !led_state; /* Set LED pin state */ Dio_WriteChannel(LED_PIN, led_state); } これで AUTOSAR タスクが定義できましたので、次に必要なモジュールを初期化し、 LED 点滅タスクの周期実行をセットアップするメイン関数を作成する必要があります。適切なコードの生成のため、以下のコメントを Amazon Q Developer に入力してください： サンプルコメント： /* Create the AUTOSAR main function */ 上記と同様に、コメントの末尾にカーソルを置いて Enter キーを押すことで、 Amazon Q Developer のインラインコード補完を起動します。 図 2 ：メイン関数の開発 図 2 に示されているように、 Amazon Q Developer は開発者のレビュー用に必要な AUTOSAR の初期化とスケジューリングコードを正常に生成しました。メイン関数には、 AUTOSAR を初期化するための StartOS() 、 LEDBlinkTask との統合、そして LED 点滅用の 500ms タイマーの設定が含まれています。 更新されたサンプルコード： #include "Dio.h" /* AUTOSAR DIO (Digital Input/Output) module header */ #include "Os.h" /* AUTOSAR OS (Operating System) module header */ /* AUTOSAR RTE (Runtime Environment) generated headers */ #include "Rte_Main.h" /* LED pin configuration */ #define LED_PIN 0x01U /* Create an AUTOSAR task for a LED blinking*/ TASK(LedBlinkTask) { static boolean led_state = FALSE; /* Toggle LED state */ led_state = !led_state; /* Set LED pin state */ Dio_WriteChannel(LED_PIN, led_state); } /* Create the AUTOSAR main function */ MAIN(void) { /* Initialize AUTOSAR modules */ StartOS(MainOsInstConst); /* Create periodic task for LED blinking */ GetTaskID(&LedBlinkTaskId); SetRelAlarm(LedBlinkTaskId, 500, 500); /* 500ms period */ return 0; } わずか数分で、シンプルなインラインコメントを使用して、 Amazon Q Developer で LED 点滅タスクの AUTOSAR コードを生成することができました。この例は、 Amazon Q Developer がワークスペースのコンテキストに基づいてタスクを自動化することで、自動車ソフトウェア開発を加速できることを示しています。現代のソフトウェア定義車両（ SDV ）には、ハザードライトからダッシュボードインジケーターまで、数多くの LED が搭載されています。それぞれが特定のタイミングとパターンを必要とし、自動車メーカーが満たさなければならない厳格な安全基準に準拠する必要があります。 Amazon Q Developer は、コードを生成することで自動車メーカーのソフトウェア開発を加速し、反復的なタスクを削減しながら迅速なプロトタイピングを可能にし、 AUTOSAR 標準を維持することを支援します。 テストケースの作成 Amazon Q Developer のもう一つの価値ある機能は、ユニットテストを生成する能力です。これにより、ソフトウェア開発者はコードが必要な仕様を満たし、エッジケースを効果的に処理することを確認できます。この機能を実証するために、先ほど生成した LED 点滅コードを基に、包括的なユニットテストを作成します。このプロセスでは、 LEDBlinkTask とメイン関数の両方をカバーします。この機能を活用するために、 Amazon Q Developer のチャット機能 を使用します。これにより、より対話的でコンテキストを意識したコード生成が可能になります。既存のコードとテスト要件を Amazon Q Developer に提供することで、様々なシナリオやエッジケースをカバーする関連性の高いユニットテストを迅速に生成することができます。 Amazon Q Developer のチャット機能を使用するには、前のステップで生成したコードを選択して右クリックします。ドロップダウンメニューから、図 3 に示すように Amazon Q → Send to prompt を選択します。 図 3 ： Amazon Q Developer チャットへのコード送信 チャットで以下のプロンプトを入力して Enter を押します： Create unit test cases for the functions in this file 図 4 ： Amazon Q Developer チャットで生成されたテストケース Amazon Q Developer は、 LedBlinkTask とメイン関数のテストケースを生成することができます。以下は、 Amazon Q Developer が生成したメイン関数のテストケースとユニットテストの更新されたコードです： Generate AUTOSAR classic code which will make the ECU send a CAN message with the 4th bit set to 1 when the voltage on pin 1 drops ユースケース 2 – ECU から CAN メッセージの送信 この例では、 Amazon Q Developer を使用して、現代の車両で電気部品の健全性を監視するために一般的に必要とされる電圧監視システムを作成します。具体的には、定期的にピンの電圧を確認し、レベルが閾値を下回った場合に Controller Area Network （ CAN ）メッセージを送信する AUTOSAR C コードを生成します。この種の機能は、電気部品の健全性を監視し、潜在的な問題を検出するために自動車システムで一般的に使用されています。 新しい Amazon Q Developer チャットウィンドウを開き、以下のプロンプトを入力してください（別の方法として、 AWS Command Line Interface (CLI) を使用することもできます）： 図 5 ：新しいチャットウィンドウを開き、 Amazon Q にプロンプト入力 シンプルなプロンプトを使用するだけで、 Amazon Q Develope rは電圧監視のための完全な AUTOSAR classic アプリケーションを生成します。サンプルコードは必要ありません。生成されたコードは、ピンの監視から CAN メッセージの送信まですべてを処理し、 Amazon Q Developer の AUTOSAR アーキテクチャと自動車システムに関する深い理解を示しています。以下のコード構造をご覧ください： 図 6 ： Amazon Q Developer チャットで生成されたコード 新しい C ファイルを作成し、コードを コピー・ペースト してください： /* Include necessary AUTOSAR headers */ #include "Std_Types.h" #include "Can.h" #include "CanIf.h" #include "Com.h" #include "Dio.h" #include "Adc.h" /* Define constants */ #define PIN_1_ADC_CHANNEL 0 #define VOLTAGE_THRESHOLD 2000 // Assuming 2V threshold, adjust as needed #define CAN_MESSAGE_ID 0x100 #define CAN_MESSAGE_DLC 1 /* Global variables */ static uint8 g_canMessageData = 0x00; static boolean g_voltageDropDetected = FALSE; /* Function prototypes */ void InitializeModules(void); void CheckVoltage(void); void SendCanMessage(void); /* Main function */ void MainFunction(void) { InitializeModules(); while(1) { CheckVoltage(); if (g_voltageDropDetected) { SendCanMessage(); } } } /* Initialize required modules */ void InitializeModules(void) { /* Initialize ADC */ Adc_Init(NULL); /* Initialize CAN */ Can_Init(NULL); CanIf_Init(NULL); Com_Init(NULL); } /* Check voltage on pin 1 */ void CheckVoltage(void) { Adc_ValueGroupType adcResult; /* Start ADC conversion */ Adc_StartGroupConversion(PIN_1_ADC_CHANNEL); /* Wait for conversion to complete */ while (Adc_GetGroupStatus(PIN_1_ADC_CHANNEL) == ADC_BUSY) {} /* Read ADC result */ Adc_ReadGroup(PIN_1_ADC_CHANNEL, &adcResult); /* Check if voltage has dropped below threshold */ if (adcResult < VOLTAGE_THRESHOLD) { g_voltageDropDetected = TRUE; } else { g_voltageDropDetected = FALSE; } } /* Send CAN message with 4th bit set to 1 */ void SendCanMessage(void) { PduInfoType pduInfo; /* Set the 4th bit (index 3) to 1 */ g_canMessageData |= (1 << 3); /* Prepare PDU info */ pduInfo.SduDataPtr = &g_canMessageData; pduInfo.SduLength = CAN_MESSAGE_DLC; /* Send CAN message */ Com_SendSignal(CAN_MESSAGE_ID, &pduInfo); } Amazon Q Developer が生成したコードを確認すると、変数定義、メイン関数、電圧確認と CAN メッセージ送信のための専用関数を含む包括的な構造が見られます。この例は、 Amazon Q Developer がコード推奨を提供することで、自動車ソフトウェア開発者のイノベーションを促進できることを示しています。このコードは本番環境での使用準備が整っているわけではなく、ユニットテスト、不正な応答のチェックなど、開発者による調整が必要ですが、開発者に強固な起点を提供します。これにより、初期開発時間を大幅に削減し、自動車ソフトウェア開発チームが特定の車両要件に合わせたカスタマイズと最適化に集中できるよう支援します。 ユースケース 3 – AUTOSAR の Python でのパッケージコンポーネント定義 最後のユースケースでは、 Python を使用した AUTOSAR XML ファイルの作成における Amazon Q Developer の活用を探ります。これらの XML ファイルは、 AUTOSAR Classic コンポーネントの構成要素を定義するため重要です。 ‘os’ と ‘autosar.xml’ ライブラリをインポートする簡単な Python スクリプトから始めて、 Amazon Q Developer が AUTOSAR コンポーネントの設定という煩雑なプロセスの自動化をどのように支援できるかを実証します。サンプルコードには “ AUTOSAR” リポジトリ を使用します。 Amazon Q Developer をインストールした IDE で新しい Python ファイルを開きます。必要な Python ライブラリをインポートすることから始めましょう： サンプルコード： import os import autosar.xml 次に、以下のサンプルコメントを使用して、 AUTOSAR ワークスペースとパッケージを作成することでコードのエントリーポイントを作成できます。 サンプルコメント： # Create workspace and packages 前のユースケースと同様に、上記のコメントをコピーして Enter を押し、 Amazon Q Developer のコード提案を確認します。 Tab を押して、提案されたコードを採用してください。 図 7 ： uint8 基本型定義のためのコメント部分を Amazon Q が補完 更新されたサンプルコード： import os import autosar.xml # Create workspace and packages ws = autosar.xml.Workspace() ワークスペースのセットアップが完了したので、コードを以下のように更新します： import os import autosar.xml # Create workspace and packages ws = autosar.xml.Workspace() # Create a package map with parameters base types and implementation data types ws.create_package_map({"BaseTypes": "DataTypes/BaseTypes", "ImplementationDataTypes": "DataTypes/ImplementationDataTypes"}) print(ws.get_package("BaseTypes").name) このコードにより、基本型と実装データ型のパッケージマップを作成しました。残りの機能の開発を加速するため、基本型を出力表示しています。これにより Amazon Q Developer が既存コードのパターンを学習し、実装データ型の新しい出力文を自動補完できるようになります。 図 8 ： Amazon Q Developer が前のコードから学習し、 uint8 基本型定義のコメント部分を補完することで、反復的なタスクとプロセスを加速化 更新されたサンプルコード： import os import autosar.xml # Create workspace and packages ws = autosar.xml.Workspace() # Create a package map with parameters base types and implementation data types ws.create_package_map({"BaseTypes": "DataTypes/BaseTypes", "ImplementationDataTypes": "DataTypes/ImplementationDataTypes"}) print(ws.get_package("BaseTypes").name) print(ws.get_package("ImplementationDataTypes").name) この例は、デモンストレーション目的で簡略化されていますが、 Amazon Q Developer が Python での AUTOSAR XML ファイル作成を自動車ソフトウェア開発者にとってどのように効率化できるかを示しています。特に注目すべきは、 Amazon Q Developer のパターン認識能力です。既存のコードから学習することで、 Amazon Q Developer は類似の操作に対して適切な提案を行い、開発時間を大幅に削減できます。本番環境での使用にはさらなる拡張が必要ですが、 Amazon Q Developer が AUTOSAR コンポーネント設定という複雑なプロセスの効率化をどのように支援できるかを示しています。 クリーンアップ Amazon Q Developer には、毎月最大 50 回までの IDE 操作が可能な無料利用枠があります。このデモンストレーションは無料枠の制限内ですが、今回作成したものをクリーンアップする場合は、以下の手順に従ってください： お使いの IDE で作成したファイルを削除 お使いの IDE の手順に従って Amazon Q Developer 拡張機能をアンインストール 結論 このブログ記事では、 Amazon Q Developer が AI 駆動のコード推奨機能を通じて、自動車メーカーのソフトウェア開発プロセスをどのように加速できるかを探りました。実践的な例として、3 つの主要アプローチを実証しました： (a) インラインコメントを使用した AUTOSAR コードの生成支援、 (b) Amazon Q チャットを使用した包括的なユニットテストの作成、 (c) Python での AUTOSAR パッケージコンポーネントの定義です。これらの例は Amazon Q Developer の開発時間削減における強力な機能を示していますが、生成されたコードは本番環境での使用前に徹底的なレビューとカスタマイズが必要であることを忘れないことが重要です。 Amazon Q Developer は開発サイクルを加速し、反復的なコーディング作業を削減する知的なアシスタントとして機能しますが、専門的なソフトウェア開発者の判断と自動車業界のベストプラクティスを補完するものであり、置き換えるものではありません。 Amazon Q Developer の詳細については、 Amazon Q Developer 入門ページ をご覧いただくか、 AWS チームまで お問い合わ せください。 このブログの翻訳はソリューションアーキテクトのショーン・セーヒーが担当しました。原文は「 Helping Accelerate AUTOSAR development for Software Defined Vehicles with Amazon Q Developer 」です。

はじめに 本ブログは、株式会社丸千代山岡家と Amazon Web Services Japan が共同で執筆しました。 みなさま、こんにちは。AWS ソリューションアーキテクトの本田・大久保です。 株式会社丸千代山岡家 様(以下、山岡家) では、 券売機から注文情報が自動的に厨房のタブレットに連携され調理が開始できるタイマーアプリとして「ゆで麺タイマー」を 2019 年より開発し、従業員の早期戦力化や体験向上といった課題解決にアプローチしています。 2025 年 6 月 25 日 ~ 6 月 26 日に幕張メッセで開催された AWS Summit Japan 2025 では、ラーメン山岡家様のブースにて、経営企画室 副室長 テクニカルエンジニアの田中様より、実際の店舗運用で活用されているゆで麺タイマーの仕組みをご紹介いただきました。会場では、来場者が直接ゆで麺タイマーの操作を体験できるデモも実施され、多くの方々から高い評価をいただきました。 本記事は、AWS Summit Japan 2025 での山岡家様ブース展示内容をもとに再構成したものとなります。 図1 : AWS Summit Japan 2025 での展示の様子 ラーメン山岡家とは 株式会社丸千代山岡家は、北海道を本社とするラーメン専門店「ラーメン山岡家」を運営する企業です。山岡家では、 好みに応じてラーメンをカスタマイズできるサービスと、豊富なサイドメニューが人気を博し、 東日本の主要幹線道路沿いを中心に 150 店鋪以上を展開しています。 山岡家における「麺あげオペレーション」の課題 麺の調理を担当する「麺あげ」は、調理の中でも重要なオペレーションです。山岡家では、顧客好みの固さにオーダーすることができ、調理の際にはメニューごとに麺の種類を使い分けています。従来の「麺あげ」オペレーションでは、厨房機器メーカー製の業務用タイマー装置を各店舗に設置して運用していました。しかし、このタイマーは実際の麺の位置と画面上のタイマーの表示位置が一致しておらず、視認性に課題がありました。また、熟練した職人の技術に依存する部分も多く、スタッフの育成やオペレーションの標準化に時間がかかっていました。こうした機器は店舗ごとの設置環境の差異も大きく、保守や管理の負荷が高いだけでなく、新しい機能の迅速な追加やシステムのアップデートが困難でした。その結果、繁忙時間帯の最適な注文対応や業務効率化にも限界がありました。 これらの課題を解決するため、クラウドベースのソリューションとして AWS を採用しました。AWS のサーバーレスサービスを活用することで、現場ごとの機器管理やインフラ運用の負担を大幅に軽減しつつ、高い可用性や柔軟なスケーリングを実現できます。また、AWS の各種サービスを組み合わせてシステムを構築することで、機能の追加や変更を段階的かつ迅速に行えるようになりました。例えば、まずは基本的なタイマー機能からスタートし、後から調理順序の自動最適化やデータ分析など、現場のニーズに応じて柔軟に機能拡張していくことができます。 AWS アーキテクチャ概要 図2 : ゆで麺タイマーのアーキテクチャ 受付処理（ AWS Fargate for Amazon ECS ） : AWS のサーバレスサービスである AWS Fargate を中核とし、コンテナ化されたアプリケーションが構築されています。券売機からの注文リクエストを受信し、Amazon ElastiCache Serverless へ保存します。 データ保存と転送（ Amazon ElastiCache Serverless for Redis ） : 注文データをインメモリで高速に保存し、Redis Stream を通じて最適化処理へとデータを転送します。Redis を採用した理由としては、厨房の業務のスピード感に対応できる高速なレスポンス性能が求められていたことと、麺を茹でるまでの約 10 分間だけデータを保持できれば要件を満たせることが挙げられます。また、 クラスターモード の利用によって単一障害点が軽減されることも採用の理由の一つです。加えて、Redis が OSS（オープンソースソフトウェア）であり、豊富な技術情報やコミュニティサポートを利用できるため、開発・運用面での情報収集が容易に行える環境が整っていることもメリットと感じています。 Snowflake は、トランザクションログの格納とマスタ管理の 2 つの用途で利用しています。オーダー履歴、調理履歴、障害発生の有無といった券売機の状態を Snowflake に格納しています。調理履歴を分析・モデル化することで業務最適化を目指しています。また、全店舗の調理基準を本部で一元管理できるよう、Snowflake をマスタデータの管理にも利用しています。本部の担当者は、店舗やメニュー、麺の情報を Salesforce でメンテナンスしており、Salesforce 上のデータは Datacloud 経由で Snowflake に取り込まれています。さらに、このデータは定期的に Redis にも同期して運用しています。 最適化処理（AWS Fargate for Amazon ECS + Amazon Bedrock ） : 最適化処理用の Fargate コンテナが Amazon Bedrock の生成 AI モデルに問い合わせ、店舗の状況や注文内容に基づいた調理順序を決定します。 タブレットアプリ（AWS Fargate for Amazon ECS） : UI は React で構築され、 Amazon CloudFront にデプロイされています。複数台のタブレットを利用することがあるので、注文情報・調理状態・最適化済み調理順序など、全ての状態をバックエンドで保持し、変更が検知されると、リアルタイムで対象店舗の全てのタブレットアプリに送信されます。 サーバーレスサービスを最大限活用することで、コストを抑えつつスモールスタートできる柔軟性を評価して開発をスタートしました。さらに、AWS Fargate や Amazon ElastiCache Serverless といったサーバレスサービスを多く採用することによってインフラ管理の負担を大幅に軽減しながら、高い可用性とスケーラビリティを実現しています。これにより、ビジネスロジックやユーザー体験の向上に集中して開発に取り組むことが可能になりました。また、Amazon Bedrock の活用により生成 AI を使った調理順序の最適化にも取り組んでいます。 ゆで麺タイマー導入による効果 ゆで麺タイマーの導入により、以下のような効果が得られました： 従業員の早期戦力化 : 前述したように、従来システムでは視認性の問題や熟練職人への依存といった課題により、スタッフの育成やオペレーションの標準化に時間がかかっていました。しかし、ゆで麺タイマーの導入したことで、直感的な UI/UX により、新人スタッフでも短期間で「麺あげ」業務を習得できるようになりました。従来は約 500 日かかっていたスキルの習得期間が 350 日程度に短縮され、スタッフの早期戦力化に大きく貢献しています。 図3 : キッチン業務習得までの所要日数 オペレーション効率の向上: 券売機からの注文情報が自動的にタイマーアプリに連携されることで、手作業による入力ミスが削減されました。調理の正確性が向上し、顧客がオーダーする好みの固さでの提供する精度向上にも寄与しています。 また、ゆで麺タイマーは店舗内のオペレーション体制の最適化において重要な役割を果たしています。山岡家の店舗あたりの来客数は年々増加傾向にあり、2025 年には 1 店舗あたり月間 15,000 人を突破しました。このような状況下でも店舗側のオペレーションがボトルネックとなり、顧客対応が滞る事態を未然に防ぐ役割を果たしています。ゆで麺タイマーの導入により、1 杯のラーメンあたりの提供時間が平均 30 秒削減され、来客数の増加に対しても顧客満足度を維持しながら安定したサービスを提供できています。 図4 : 店舗あたりの月間来客数 紙ベース運用からデジタル化によるコスト削減へ： 現在、券売機から受けた注文内容は、厨房のキッチンプリンタに連携され自動で印刷される仕組みとなっています。しかし、これは厨房で調理する順序通りになっておらず、ホールで受けた麺の茹で加減のオーダーも含まれていないこともあって、積極的には活用されていませんでした。これからは直接注文情報がキッチンのゆで麺タイマーに連携され、調理順に沿って並び替えられて表示されます。キッチンプリンタの廃止によって、ロール紙コスト 600 万/年の削減が実現される見込みです。 成功のポイントと今後の展望 図5 : ゆで麺タイマー開発プロジェクトの時系列 ゆで麺タイマープロジェクトの成功には、いくつかの要因がありました。最も重要だったのは現場主導の開発アプローチです。プロトタイプとして試作したシステムを現場のスタッフに試験的に使用してもらい、「本州と北海道では、同じ麺でもゆで時間が異なる」「キッチンスタッフが利用する上で、操作しやすく遠くからの視認性が高い UI/UX が良い」といったフィードバックを反映させながら機能改善することで、現場のニーズに即したシステムを構築できました。開発期間中は、システムをリリースして現場の意見をもらい、そのフィードバックを反映させた改良版を約 2 週間ごとにリリースするというサイクルを何度も繰り返しました。このような定期的なフィードバックループを通して継続的に改善を重ねることで、使いやすさと実用性を両立することができました。 技術面では、AWS のサーバレスサービスの採用が大きな成功要因となりました。AWS Fargate や Amazon ElastiCache Serverless などを活用することで、インフラ管理の負担を軽減し、開発リソースをビジネス価値の創出に集中させることができました。 今後の展望として、調理順序最適化機能のさらなる改良も進めています。現在、Amazon Bedrock を活用した生成 AI による調理順序最適化を試験的に導入しており、従来のアルゴリズム開発と比較して実装のハードルが大幅に低減されました。この生成 AI アプローチにより、熟練スタッフの経験や知識をシステムに組み込むことができ、全店舗で均一かつ高品質なサービスを提供できるようになりました。将来的には「お子様ラーメンは早めに提供する」「ラーメンと餃子のセットなど、複数のメニューを一緒に提供する」といった指示を自然言語で行える柔軟な拡張も計画しています。 おわりに 山岡家のゆで麺タイマーは、AWS のサーバレスサービスを活用することで、従来の課題を解決し、従業員の早期戦力化と顧客満足度の向上を実現しました。外食産業におけるデジタルトランスフォーメーションは、単なる業務効率化だけでなく、従業員体験と顧客体験の両方を向上させる重要な取り組みです。今後も山岡家では、AWS の最新技術を活用しながら、さらなるデジタル化を推進し、従業員と顧客の双方にとって価値のあるサービスを提供していきます。 著者について 田中 陽里 株式会社丸千代山岡家 経営企画室 副室長 2023 年より現職。外食産業における DX を推進し、ゆで麺タイマーの企画から開発、導入までを主導。 好きな AWS サービスは Amazon Elastic Container Service です。 大久保 裕太 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっています。IoT 領域が得意で、好きな AWS サービスは AWS IoT Core。 本田 光来 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっています。サーバーレス領域が得意で、好きな AWS サービスは AWS Lambda です。

本ブログは株式会社トライト様と Amazon Web Services Japan 合同会社が共同で執筆しました。 みなさん、こんにちは。Amazon Web Services（以下 AWS）アカウントマネージャーの竹中です 。 株式会社トライト（以下 トライト）様において、顧客体験を起点としたサービス企画・開発の強化とイノベーション創出・意思決定の迅速化を目指す取り組みの一環として、AWS 主催の「体験版 Working Backwards セッション」を東京・大阪の2拠点で計4回開催しました。保育士、看護師、介護職、歯科衛生士向けキャリア支援サービスを担当する約55名の多様な職種の皆様にご参加いただき、顧客中心の発想やチームビルディング、実践的なアイデア創出を体験していただきました。ワークショップの満足度は94.5%と高く、今後のサービス開発・改善活動に向けた大きな一歩となりました。 この記事では、トライト様にご参加いただいたセッションの模様についてご紹介させていただきます。 トライト様について トライト様は、医療福祉を中心とした、社会的ニーズの高い専門職向けの人材サービスとデジタルソリューションを展開し、求職者と事業者をつなぐ重要な役割を担っています。また、近年では医療福祉現場の業務効率化や生産性向上を目的に、ソフトウェアやデジタルツールの提供、AI・DX 推進支援などを行っています。このような事業の成長とともに、サービスやプロダクトの企画・開発において、より一層「お客様体験」を起点とした価値創出が求められるようになりました。 本セッションを開催するにあたり、トライト様からは以下のような課題とご期待を頂戴しました。 顧客視点の価値の明確化への課題感 ：サービス設計において事業成果を優先しがちになり、顧客視点での価値の創出が十分に注力しきれていない課題。本セッションを通じ、お客様の本質的な課題から逆算して考えるプロセスを体験し、顧客中心の発想を組織に根付かせたいという強いご要望がありました。 多職種間のコミュニケーションと相互理解の促進 ：サービスに関わる多様な役割間でのコミュニケーションや相互理解が不足しているという課題。ワークショップを通じて、実際のサービスデザインさながらのチームビルディングを実現したいという期待が寄せられていました。 イノベーション創出と意思決定スピードの向上 ：変化の激しいビジネス環境において、新規サービスの企画や既存サービスの改善にスピード感やイノベーションが不足している課題。普段の業務を離れ、フラットな場で本質的に価値あるアイデアをスピーディーに議論・具体化する実践的な方法論を体験したい思いがありました。 体験版 Working Backwards セッションについて Amazonの「Working Backwards」とは、「お客様は誰ですか？」 から始まる5つの質問を通じて、本当に必要なサービスを企画・開発していく手法です。具体的には、最初にプレスリリース（以下 PR）を書くことで、これからつくるプロダクトやサービスを明確にします。この PR 文章と FAQ （よくある質問）を通じ、顧客起点のサービス価値について深く考えます。 今回実施した「体験版 Working Backwards セッション」は、お客様を中心とした創造的課題解決アプローチのエッセンスを簡易に体験いただくワークショップです。個人ワークを中心とした約2.5時間のマイクロ版と、個人ワーク・グループワークの両方を行う約4時間のミニ版セッションがありますが、今回は前述のチームビルディングの課題に取り組むため、グループワークを含むミニ版をご選択いただきました。 セッションは具体的には以下の流れで進行しました。 セッションテーマの設定。今回は事前に「インターネット上で、転職活動を行う特定業界の求職者様のストレスフリーな転職体験の向上」と合意 「お客様は誰か」「どんな課題をどう解決するか」を個人で考え、グループで議論しつつ定義 初期のアイデアを深掘りし、解決策を考え、それらを盛り込んだ PR 文案を作成 グループ間で PR 文をレビューし、アイデアを更に発展させるためのディスカッション このプロセスを通じて、参加者はお客様中心のサービスデザインや、課題から考える逆算思考を体感し、実際の業務への応用イメージを膨らませることができました。 体験版 Working Backwards セッションのワーク内容 実施効果と参加者の声 体験セッションを東京会場と大阪会場で各2回ずつ、計55名のトライト社員様にご参加いただきました。参加者の職種はビジネスエキスパート、CRM、デザイン、マーケティング、開発、企画など多岐にわたり、管理職の方も含まれました。また、東京第2回セッションでは、AWS のプレミアティアサービスパートナーである株式会社サーバーワークス様に開催のご協力をいただきましたこと、この場を借りて御礼申し上げます。 ワークショップ中議論の模様 全4回のワークショップ終了後のアンケート（1 ~ 5の5段階で満足度を評価）では、参加者の94.5%が「4」または「5」と高い満足度を示しました。以下にセッションご参加者様の声の一部をご紹介します。 「お客様に対する解像度を上げることがより良いサービスを作れることにつながる」ということを実感しました。4時間があっという間に経ちました（開発）  複数の職種のメンバーが介してサービスについて検討するという機会は多くないので、とても新鮮でしたし必要な事だと強く感じました（マーケティング）  ペルソナから課題、解決サービスまでをかなり作り込んだつもりでしたが、第三者の視点では指摘箇所が沢山あると気付きました。改めて顧客視点で考える大切さと、その密度の重要性を感じました（マーケティング） 業務では数日間煮詰めて考えるようなことを短時間でスピード感もって出来たので、プロトタイプ作成などで活かせそうです（開発） ご紹介した意見以外にも、顧客を中心とした課題から逆算することの意義や、多様なフィードバックを取り入れつつアジャイルにアイデアを改善するプロセスに関心を持ったといったお声を多数頂戴しました。 また、ワークの途中で生成 AI を取り入れたことにより、文章作成効率を向上して更に深い議論に発展できたことや、生成 AI の利用方法そのものを理解できたといった副次的なメリットも感じていただけました。 全4回のセッションを通じ、トライト事務局の通地 浩樹氏からは「弊社 UXD 本部開発部の部門重点目標である『組織横断的な協働による顧客への価値提供』の実現を目的とし、ワーキングバックワーズを実施いたしました。本取り組みではサービス全体を見据え、多様な役割の方々との協働による思考の機会を得ることができ、各部署からも好評を得る有意義なワークショップとなりました。ご参加・ご支援賜りました皆様に、心より御礼申し上げます。」とコメントを頂戴しています。 今後も AWS は、トライト様のビジネス成長とイノベーション推進に貢献できるよう、パートナー企業様と連携しながらご支援を続けてまいります。 本記事公開時点では、体験版Working Backwardsセッションは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください。    

みなさん、こんにちは。製造業のお客様を中心に技術支援をしているソリューションアーキテクトの塚井です。 2025 年 6 月 25 日・26 日に開催された AWS Summit Japan にご来場いただいた皆さま、誠に有難うございました。 本ブログでは、当日会場にお越しいただけなかった方に向けて、AWS Village の Industry Zone 内にある製造ブース「産業データファブリック (IDF) 」でご紹介した内容をお届けします。 製造エリア全体の見どころを紹介した Blog は こちら で紹介されていますので、ご参照ください。 産業データの活用はなぜ難しいのか？ 産業データの活用が難しい理由はさまざまですが、私たちがお客様からよく伺う主な理由をご紹介します。例えば、データが各工場の機器ごとに分散しており、十分に共有されていないことがあります。また、アクセスできたとしてもデータの統合が困難であったり、分析を行うためのドメイン知識を持つデータサイエンティストが不足していたりする場合もあります。 産業データファブリック(IDF)の活用はなぜ難しいのか？ 産業データファブリック (IDF) のソリューションフレームワークは、各種デバイスやアプリケーション、製造システムからのデータの収集・保存・コンテキスト化・活用に関わる作業を軽減し、費用対効果の高いユースケース開発に集中できるよう支援します。こうしたフレームワークを活用することで、以下のような効果が期待できます。 散在するデータを集約し、価値を引き出すことができる 価値のあるユースケースの実現までの時間を短縮できる データへのアクセスが簡素化される セキュリティやガバナンスを標準化できる コンテキスト化については、後ほど具体例で紹介します。 産業データファブリック (IDF) の構造 基盤構築だけにフォーカスするのではなく、価値のあるユースケースから逆算して考えることが重要です。データの収集や統合はソリューションによって簡易化できますが、その活動に意味を持たせるのはユースケースの存在です。 そのため、最初のユースケースを開発する段階でスモールスタートができ、将来的な横展開にも対応できるアーキテクチャを選定することが大切です。このアーキテクチャを支えるのが、AWS やパートナーのソリューションと活用しやすいデータフォーマットです。パートナーでは、日立製作所が国内で初めて IDF のパートナーに認定されました。 産業データのコンテキスト化の構造例 産業データ活用の進め方 最後に進め方についてですが、まず ROI (投資対効果) の高いユースケースを選定し、初期段階ではデータの収集と統合から着手します。 その後、段階的にライン単位から工場全体、さらに組織全体へと展開していきます。 デモ内容のご紹介 こうした IDF のコンセプトやどのような価値をもたらすのかをイメージしていただくために、デモを展示しました。 ① 工場生産ラインの可視化 e-Bike の生産ラインをイメージとした仮装工場からデータを生成して、IDF のフレームワークに沿ってデータを収集〜保存〜コンテキスト化〜活用しています。 データソースとしては、注文を管理する ERP、実行する MES、生産設備の各機材を実現しています。 ② Amazon QuickSight で製造データを分析 製造のデータを分析しやすい標準的なフォーマットに加工して、 Amazon Q in QuickSight によってチャットから自然言語で分析を行うことにより、Amazon Q in QuickSight によってチャットから自然言語で分析を行うことにより、データ活用を加速します。 ③ Amazon DataZone でデータを共有 生データ、または加工されたデータをカタログとして Amazon DataZone で共有できます。他部門がそのデータに SUBSCRIBE することで、簡単に分析や ML の開発に活用できます。 まとめ 最後にここまで紹介した内容をまとめます。 産業データファブリック (IDF) は製造業のお客様のデータ活用を促進するためのフレームワークです。 データ活用はスモールスタートで始めますが、最終系を描いておく必要があります。 最初のユースケースが大事で、ROI を考慮した選定が必要です。 IDF は AWS のサービスやパートナーソリューションを組み合わせてお客様の要件を実現します。 会期中は、両日合わせて本ブースに多くのお客様にお越しいただきました。ご来場頂いたお客様からは、製造データの活用に取り組む中でさまざまな課題を抱えていることを実感しました。 産業データファブリック (IDF) が、そうした課題解決の一助となれば幸いです。 著者紹介 塚井 知之 (Tomoyuki Tsukai) アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 外資系のハードウェアベンダー、ソフトウェアベンダーを経て、2019 年に AWS Japan に入社。現在はエンタープライズ技術本部でソリュー ションアーキテクトとして活動中。製造業のお客様を担当し、AWS に纏わるさまざまな技術支援を行っています。趣味は車中泊と DIY です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 ところで、AWS Builders Online というイベントがまもなく開催されるのですが、参加されたことはありますでしょうか。最新の生成 AI サービスから実践的なデータ分析手法まで、ビジネスですぐに活用できる知識を得られるところや、実務で直面する課題に対する具体的な解決策を学べるようになっており、初学者の方にはおすすめのイベントとなっています。イベント登録は こちら から可能となっています。オンラインで参加可能ですので、熱い夏は自宅で AWS 学習に時間を費やしてみるのもよいかもしれませんね。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年7月21日週の主要なアップデート   7/21(月) Amazon Braket が IQM の新しい 54 量子ビット量子プロセッサを追加 Amazon Braket で IQM の新しい 54 量子ビット量子プロセッサ「Emerald」が利用可能になりました。Emerald は超伝導技術を使った最新の量子コンピューティングデバイスで、従来より高い精度で量子アルゴリズムの研究・実験が可能です。Braket SDK や Qiskit などの人気フレームワークで量子プログラムを構築でき、量子機械学習や最適化問題の解決に活用できます。ストックホルムリージョンから利用でき、研究機関向けには AWS クレジットプログラムも提供されています。詳細は こちらの Blog 記事をご参照ください。 Amazon Connect が外部音声コネクタの日単位料金を発表 Amazon Connect の外部音声コネクタが 1 日 100 ドルの日次課金になりました。従来は、1コネクタあたり月額 3,100 ドルだったところが、細かい単位での課金が可能になり、コスト管理がしやすくなります。このコネクタには 2 種類あり、転送コネクタは既存の音声システムと Amazon Connect を連携させ、分析コネクタは他システムの音声データを Contact Lens で分析できます。既存のコールセンターシステムを活用しながら Amazon Connect の AI 機能を利用したい企業にとって便利な機能です。詳細は こちらのドキュメントをご参照ください。 Amazon SQS がマルチテナントワークロード向けのフェアキューを導入 Amazon SQS で fair queues (フェアキュー) 機能が提供開始されました。従来、マルチテナント環境で一つのテナントが大量メッセージを送信すると他のテナントの処理が遅延する問題がありましたが、この機能により各テナントの処理時間を公平に保てます。メッセージ送信時にメッセージグループ ID を指定するだけで利用でき、既存システムへの影響なく導入可能です。SaaS アプリや複数リソースのイベント処理に特に有効で、全商用リージョンで利用できます。詳細は こちらの Blog 記事をご参照ください。 7/22(火) Amazon MQ が RabbitMQ 向けに Graviton3 ベースの M7g インスタンスをサポート開始 Amazon MQ の RabbitMQ で新しい Graviton3 ベースの M7g インスタンスが利用可能になりました。従来の M5 インスタンスと比較して最大 50% のワークロード容量向上と最大 85% のスループット改善を実現します。M7g.medium から M7g.16xlarge まで幅広いサイズを選択でき、評価用途から本格的な本番環境まで対応可能です。また既存の M5 ブローカーからのインプレースアップグレードにも対応しており、ダウンタイムを最小限に抑えて性能向上を図れる点が魅力です。詳細は こちらのドキュメントをご参照ください。 AWS Audit Manager がコンプライアンスインサイト向上のためエビデンス収集を強化 AWS Audit Manager が 14 の標準フレームワークを更新し、エビデンス収集機能を強化しました。SOC 2 や PCI DSS v4.0 などの主要フレームワークでエビデンスの関連性が向上し、コンプライアンス検証がより効率的になります。多くの顧客で検出結果の数が最適化され、関連コストの削減も期待できます。6 月 6 日以降に作成したアセスメントは自動的に更新版が適用されますが、それ以前のものは新規作成が必要です。詳細は こちらのドキュメントをご参照ください。 Amazon Timestream for InfluxDB が 24xlarge メモリ最適化インスタンスをサポート開始 Amazon Timestream for InfluxDB で 24xlarge メモリ最適化インスタンスが利用可能になりました。96 vCPU、768 GiB のメモリ、最大 40 Gbps のネットワーク帯域幅を提供し、大規模な時系列データベースワークロードに対応できます。産業用テレメトリー、IoT 分析、金融取引プラットフォームなど、高速な応答時間が求められる用途に最適です。東京リージョンを含む複数のリージョンで利用でき、コンソール、CLI、SDK、CloudFormation から簡単にプロビジョニングできます。 7/23(水) Amazon RDS for PostgreSQL と Amazon Redshift のゼロ ETL 統合が一般提供開始 Amazon RDS for PostgreSQL と Amazon Redshift の zero-ETL 統合が一般提供開始されました。従来は複雑なデータパイプラインを構築する必要がありましたが、この機能により PostgreSQL のデータがほぼリアルタイムで Redshift に自動レプリケーションされ、すぐに分析できるようになります。複数の統合作成やデータフィルタリング、CloudFormation での自動化も可能で、データ分析の効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle と Amazon Redshift のゼロ ETL 統合 Amazon RDS for Oracle と Amazon Redshift の zero-ETL 統合機能が提供開始されました。従来は複雑な ETL パイプラインを構築する必要がありましたが、この機能により Oracle データベースに書き込まれたデータが数秒で Redshift に自動レプリケーションされます。これにより、ペタバイト規模のトランザクションデータをリアルタイムに近い形で分析や機械学習に活用できるようになります。特定のテーブルやデータベースを選択してレプリケーションでき、Oracle Database 19c で利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS IoT SiteWise Query API が高度な SQL サポートと ODBC ドライバを追加 AWS IoT SiteWise Query API が大幅に強化され、高度な SQL 機能と ODBC ドライバーが追加されました。これまで複雑だった工業データの分析が簡単になり、文字列操作や集約関数、日時計算などの高度な SQL 操作が可能です。さらに ODBC ドライバーにより Tableau や Power BI、Excel との直接連携も実現し、カスタム開発なしでデータ可視化やレポート作成ができます。東京リージョンを含む 9 つのリージョンで利用可能で、工業データから迅速にビジネス洞察を得られるようになりました。詳細は こちらのドキュメントをご参照ください。 7/24(木) Amazon CloudWatch が IPv6 サポートを追加 Amazon CloudWatch が IPv6 サポートを開始しました。これまで IPv4 のみだったメトリクス取得やアラーム、ダッシュボード機能が IPv6 でも利用可能になります。IPv4 と IPv6 両方に対応するデュアルスタック環境で CloudWatch を運用でき、アドレス枯渇の心配がなく、IPv6 ネイティブなアプリケーションのモニタリングが簡単になります。詳細は こちらのドキュメントをご参照ください。 AWS Glue が Microsoft Dynamics 365 をデータソースとしてサポート開始 AWS Glue で Microsoft Dynamics 365 のネイティブコネクターが利用可能になりました。これまで複雑だった ERP や CRM システムからのデータ抽出が簡単になり、ETL ジョブの構築時間を大幅に短縮できます。企業の販売データや顧客情報を AWS のデータ分析基盤に効率的に統合でき、より包括的なビジネス分析が可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon ElastiCache での Bloom フィルターサポートの発表 Amazon ElastiCache で Bloom filter が利用可能になりました。これまでキャッシュ内のアイテム存在確認には Set データ型を使用していましたが、Bloom filter を使うことで 98% 以上のメモリ効率化を実現できます。確率的データ構造により高速な存在チェックが可能で、大量データの重複判定やキャッシュ効率向上に効果的です。全リージョンで追加コストなしで利用できます。詳細は こちらのドキュメントをご参照ください。 7/25(金) AWS HealthOmics がワークフロー作成のためのサードパーティ Git リポジトリサポートを導入 AWS HealthOmics で Git リポジトリ連携機能が追加されました。GitHub、GitLab、Bitbucket からワークフロー定義を直接取得でき、従来必要だった手動ステージングが不要になります。バージョン管理と再現性が向上し、既存の開発プロセスを維持しながら効率的に活用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が メッセージテンプレート添付ファイル向けの AWS CloudFormation をサポート開始 Amazon Connect の Outbound Campaign で利用するメッセージテンプレートの添付ファイル (画像やドキュメント) が AWS CloudFormation で管理できるようになりました。これまで手動で作成・管理していた添付ファイルを、コードで自動化して複数環境 (本番・テスト・ステージング) に一貫してデプロイできます。メール配信キャンペーンでの画像添付などがより効率的になり、インフラ管理の負担軽減とヒューマンエラー削減が期待できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が予測編集 UI を開始 Amazon Connect で予測編集 UI が新登場し、コールセンターのプランナーが予測調整を簡単に行えるようになりました。従来は複雑だった予測値の変更が、新しい UI で直感的に操作可能になります。マーケティングキャンペーン期間中に火曜・水曜の 12 時から 14 時の予測を 15% 増加させるなど、具体的な日時・キュー・チャネルを指定した調整ができます。需要変動への迅速な対応と計画精度の向上を実現し、エージェントスケジューリング機能が利用可能な全リージョンで提供開始されました。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

双方向コミュニケーションは強固な関係構築の礎となります。リアクティブなカスタマーサポートもあらゆる種類の組織にとって重要ですが、プロアクティブな顧客へのアプローチによってカスタマーエクスペリエンスをさらに向上させることができます。しかし、組織は適切なメッセージを、適切な人に、適切なタイミングで送信する必要があります。 Amazon Connect のイノベーション により、組織は個々の顧客ニーズに合わせたターゲット型コミュニケーションを開始できます。 Amazon Connect Customer Profiles からのデータを活用することで、企業は今や顧客、オーディエンスをセグメント化し、 Amazon Connect Outbound Campaigns によりパーソナライズされたメッセージを作成して、事前に顧客とコミュニケーションを取り、信頼とロイヤルティを育み、大切な顧客との永続的な絆を築くことができます。 プロアクティブなコミュニケーションにおける従来の課題 今日、効果的なプロアクティブコミュニケーション戦略の実装を目指す企業は、数多くの課題に直面しています。組織は多くの場合、複数のシステムからのデータを組み合わせてターゲットとなる顧客セグメントを作成し、そのプロセスは IT や保守運用チームに依存しています。このプロセスは時間がかかるだけでなく、古いデータを生成する可能性があり、アウトバウンドコミュニケーションのルールやキャンペーンを頻繁に変更する必要を生じさせます。運用のスケーリングは困難になり、最新の顧客情報へのアクセスも限られているため、パーソナライゼーションの質が損なわれます。 Amazon Connect による動的でパーソナライズされた顧客エンゲージメント Amazon Connect を使えば、企業は、プロアクティブなパーソナライズされたコミュニケーションの提供、そして売上成長の促進やカスタマーサービスへの問い合わせを未然に防ぐことができます。組織は、 Amazon Connect Customer Profiles で、生成 AI を活用して、さまざまなデータソースから顧客データを簡単に集約、統合された顧客レコードを作成できます。70 種類以上のデータソースから顧客データをリアルタイムにプロファイルに組み合わせることもできます。 Amazon Connect Outbound Campaigns の機能と組み合わせ、組織は Amazon Connect Customer Profiles の属性をアウトバウンドキャンペーンのセグメントで使用でき、これらは動的に最新の状態に保たれます。 顧客セグメント、チャネル、スケジュールを定義すれば、Amazon Connect の管理コンソールから直接、チャネルをまたいだキャンペーンをすばやく作成および起動できます。これにはメッセージングのテンプレート管理が含まれます。セグメンテーションに使用されるのと同じ動的属性を使用して、 アウトバウンドキャンペーン のメッセージ自体をパーソナライズすることもでき、 Amazon Connect Customer Profiles は、組織全体の顧客ライフサイクルを支援する最新の顧客情報の拡張可能な情報源となります。 さらに、企業は継続的に顧客データと洞察を確認し、改善したいと考えているでしょう。 Amazon Connect Outbound Campaigns は、キャンペーンのパフォーマンスをリアルタイムで表示します。これには、キャンペーンの配信状況、応答率、または通話の結果（例：本人応答、留守番電話、話中・ビジー、目的完了）が含まれます。以前は、顧客はエンドツーエンドのパフォーマンスメトリクスを取得するために、データを組み合わせてカスタムダッシュボードを構築するための技術リソースが必要でした。現在は、これらのメトリクスを 1 か所で利用可能です。 様々なユースケースでの活用 これらの機能により、ビジネスユーザーは技術的な担当者に依存したり、複数のツール間でカスタム統合を構築・設定することなく、コミュニケーションを調整できるようになります。これらの機能はすべて Amazon Connect の Web コンソール内で利用でき、組織がターゲットを絞ったタイムリーなアウトバウンドコミュニケーションを提供するのに役立ちます。 サービスの予約確認、支払いの督促、またはカスタマージャーニーにおけるタッチポイントなどのユースケースで Amazon Connect は組織が一貫したコミュニケーションを維持し、価値ある関係を育成することを支援します。組織は今や、スケールできるパーソナライズされたオムニチャネルキャンペーンを簡単に作成できます。このようなコミュニケーションにより、特別オファーの案内やかご落ち・カート離脱のリマインドなど、マーケティング機会にも発展させることができます。 Amazon Connect Outbound Campaigns の料金は、アウトバウンドコミュニケーションの数と使用されるチャネルに基づいています。Customer Profiles と Outbound Campaigns を使用することで、企業は適切なタイミングで顧客にエンゲージし、プロアクティブでパーソナライズされたアウトリーチを通じて、より深く意味のある関係を育むことができます。 Amazon Connect でのプロアクティブコミュニケーションに関する技術ブログ で、開始方法について詳しく学びましょう。 Amazon Connect Outbound Campaigns と Customer Profiles を使用して、適切なタイミングで複数のチャネルを通じて適切な顧客と動的にエンゲージしましょう。詳細については、 お問い合わせ ください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 先日は AWS Summit New York 2025 で 多くの AI エージェント関連サービスやプログラムが発表 されましたね。お客様から期待の声を多くいただいたのと同時に、私自身も非常にワクワクしました。 7/30（水）に 「 Amazon Q CLI でゲームを作ろうキャンペーンの報告と最新情報 update & Kiro のご紹介 」というイベントが予定されています。AI エージェントの最新情報が聞けるイベントとなってますのでご興味のある方はぜひご参加ください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、7 月 21 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。ニュースが中心の週となっています。 さまざまなニュース AWS Summit New York関連のニュース ブログ記事「AWS、AWS Summit New York 2025 にて AI エージェント構築に向けた新たなイノベーションを発表」を公開 AWS Summit New York 2025 にて AI エージェント関連の新しいサービスやプログラムがいくつか発表されました。本ブログでは、Amazon Bedrock AgentCore、AWS Marketplace の新カテゴリー、生成AIイノベーションセンターへの追加投資、Amazon Nova の新しいカスタマイズ機能など、Summit で発表された代表的な内容をまとめて紹介しています。 ブログ記事「Amazon Bedrock AgentCore のご紹介: AI エージェントをあらゆる規模で安全にデプロイおよび運用する (プレビュー)」を公開 Amazon Bedrock AgentCore（プレビュー）が発表されました。Amazon Bedrock AgentCore は、AI エージェントをあらゆる規模で安全にデプロイおよび運用するためのプラットフォームです。本ブログでは、AgentCore Runtime、Memory、Observability、Identity、Gateway、Browser、Code Interpreter の7つのコンポーネントの詳細と、Strands Agents を使用したカスタマーサポートアシスタントの実装例を解説しています。各機能の理解に向けては AgentCore サンプル GitHub リポジトリ  での体験がおすすめです！ ブログ記事「Amazon SageMaker AI での Amazon Nova のカスタマイズの発表」を公開 Amazon SageMaker AI で Amazon Nova のカスタマイズ機能が発表されました。Amazon Nova Micro、Nova Lite、Nova Pro を継続事前学習、教師ありファインチューニング、アライメントなどの手法を使ってカスタマイズできます。本ブログでは、各カスタマイズ手法の概要や、 Amazon SageMaker Studio 上で直接選好最適化を用いて Nova Micro モデルをカスタマイズする例について説明しています。 ブログ記事「TwelveLabs の動画理解モデルが Amazon Bedrock で利用可能に」を公開 TwelveLabs の動画理解モデル Marengo（動画埋め込みモデル）と Pegasus（動画言語モデル）が Amazon Bedrock で利用可能になりました。「試合の最初のタッチダウンを見せて」のような自然言語による動画検索や、タイトル、要約、章、ハイライトなどの説明テキスト生成が可能になります。本ブログでは、これらのモデルの機能とAmazon Bedrock での TwelveLabs モデルの開始方法ついて紹介しています。 ブログ記事「AWS AI League: 新しい究極の AI 対決で学習し、イノベーションを起こし、競い合う」を公開 AWS AI League という競い合いながら学ぶ、新しい生成 AI 学習プログラムが開始されました。組織がプライベートトーナメントを開催し、チームが協力して実際のビジネス課題を解決する AI ソリューションを構築します。本ブログでは、プログラムの構成や申し込み方法について説明しています。 ブログ記事「Amazon S3 Vectors と Amazon OpenSearch Service によるベクトル検索の最適化」を公開 本ブログでは、Amazon S3 Vectors と Amazon OpenSearch Service の統合機能（プレビュー）について解説しています。大規模なベクトル埋め込みを保存・検索する際のレイテンシー、コスト、精度のトレードオフという課題を解決するために、頻繁にクエリされないベクトルをS3 Vectorsに保持し、ハイブリッド検索や集計などの高度な検索機能にはOpenSearchを使用する最適化手法について説明しています。既存のベクトル検索システムの最適化を検討している方は是非ご覧ください。 その他のニュース ブログ記事「AWS Price List が自然言語でアップグレードされました：AWS Pricing MCP サーバーの紹介」を公開 AWS Price List が自然言語でアップグレードされ、AWS Pricing MCP サーバーがオープンソースツールとしてリリースされました。Model Context Protocol（MCP）を通じて、「us-west-2 で 3 つの m5.large インスタンスを実行するコストは？」のような自然言語による料金問い合わせが可能になりました。本ブログでは、240 を超える AWS サービスの複雑な料金情報を AI アシスタントとの会話で簡単に取得できる方法について説明しています。 ブログ記事「AWS Transform での Export for vCenter の使用」を公開 Export for vCenter という新しい AWS オープンソース Python プロジェクトが発表されました。AWS Transform for VMware で利用するために vCenter からインベントリデータをエクスポートするツールです。RVTools の代替手段として開発され、AWS Transform が必要とするデータのみを取得します。本ブログでは、セットアップ手順と実行手順ついて解説しています。 ブログ記事「AWS Serverless MCP Server の紹介：AI を活用してモダンアプリケーションを開発する」を公開 AWS Serverless MCP Server は、サーバーレス開発に特化したコンテキストガイダンスを提供し、開発者がアーキテクチャ、実装、デプロイに関する情報に基づいた決定を行えるよう支援するソリューションです。本ブログでは、Serverless MCP Server の概要と設定方法、サーバーレスアプリケーションの作成をテーマにした実際の動作イメージについて説明しています。 ブログ記事「JWT を使用した Amazon Bedrock と Amazon OpenSearch Service による SaaS 向けマルチテナント RAG 実装」を公開 本ブログでは、JWT と Fine-Grained Access Control（FGAC）を使用した Amazon Bedrock と Amazon OpenSearch Service による SaaS 向けマルチテナント RAG の実装方法について解説しています。厳密なテナントデータアクセス分離が必要なケースにおいては、ぜひ本文にあるアーキテクチャを参考にしてみてください。 ブログ記事「AWS Summit Japan 2025 で次世代のフードマネジメントに挑戦！ AI と IoT で実現する スマート廃棄物管理」を公開 本ブログでは、AWS Summit Japan 2025 の Builders Fair で展示された、AI と IoT を活用したスマート廃棄物管理システムについて報告しています。ゴミ箱に何がどれくらい廃棄されたのかを可視化する展示内容となっており、展示期間中の約 9 時間で 162件、149kgの廃棄物を処理し、認識精度88.4%を達成しました。Amazon Bedrock、AWS IoT Core、Amazon Timestream for LiveAnalytics などを使ったアーキテクチャが記載されています。 ブログ記事「AWS Cloud Quest に無料でプレイ可能な「生成 AI プラクティショナー」ロール追加 ＆ 全ロールが日本語化されました」を公開 AWS Cloud Quest に「生成 AI プラクティショナー」ロールが追加され、全ロールが日本語化されました。既存の「Cloud Practitioner」ロールに加えて合計20チャレンジ分の実際のAWSアカウントを使用した演習環境が無料で利用できるようになりました。ぜひ「 AWS Skill Builder 」に登録しお試しください。 ブログ記事「【開催報告】Neuron Community – Vol.2」を公開 本ブログでは、2025 年 7 月 15 日に開催された「Neuron Community – Vol.2」の様子をレポートしています。オープニングでは Discord上のNeuron Community の成長について、ライトニングトークでは国立情報学研究所様による「LLM-jp Chatbot Arena」での Amazon EC2 Trn1 インスタンス活用事例について発表された様子が紹介されています。 サービスアップデート Amazon EC2 P6-B200 インスタンスが米国東部 (バージニア北部) で利用可能になりました Amazon EC2 で新しい P6-B200 インスタンスが米国東部 (バージニア北部) リージョンで利用開始されました。NVIDIA Blackwell GPU を 8 基搭載し、従来の P5en インスタンスと比較して最大 2 倍の性能を実現します。AI モデルの学習や推論処理において、より高速で効率的な処理が可能になり、大規模な機械学習プロジェクトでの計算時間の短縮が期待できます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

7 月 21 日、ホーチミン市からシンガポールに戻る途中に記事を書いています。すばらしい一週間だったと思っていたところなので、少し振り返ってみたいと思います。7 月 21 日週、私は初めて Corne キーボードを試し、水準を確実に引き上げている講演者たちと一緒に AWS Summit Jakarta のリハーサルを終えてから、ベトナムに移動して AWS Community Day Vietnam にテクニカル基調講演の講演者として参加しました。このエネルギッシュな会合では、複数のテクニカルトラックとネットワーキングセッションを通じて、何百人ものクラウドプラクティショナーと AWS 愛好家が知識を共有しました。 私が行ったのは、「Reinvent perspective as modern developers」というタイトルの基調講演で、 サーバーレス や コンテナ の他、 Amazon Q Developer と Kiro を使用して知識習得時間を短縮し、生産性を高める方法についてお話ししました。数人の AWS コミュニティビルダーやコミュニティ開発者と話し合う機会もあり、Amazon Q Developer を実際に使用してアプリケーション構築の課題にどのように対処したのかを共有してくれました。クラウド開発ジャーニーにおける大幅な生産性向上と知識習得の円滑化を強調した人も幾人かいました。 シンガポールに戻るにあたり、私はおいしい cà phê sữa đá (アイスミルクコーヒー) の思い出だけでなく、この活気に満ちたクラウドイノベーターのコミュニティから得た新鮮な視点やインスピレーションも持ち返っています。 Kiro の紹介 先週のハイライトの 1 つは、何と言っても Kiro です。Kiro は、AI エージェントと連携するための簡素化された開発者エクスペリエンスを通じて、コンセプトから本番環境の実現を支援する AI IDE です。Kiro は、適切な計画と明瞭性を用いてプロトタイプを本番環境システムに移行させるために役立つ spec (スペック) や hook (フック) といった機能で「バイブコーディング」のさらに先を進みます。 ウェイティングリストに登録 して、提供開始時に通知を受け取りましょう。 7 月 14 日週の AWS リリース その他のニュースには、ニューヨークで開催された AWS Summit があり、ここでいくつかのサービスがリリースされました。こちらは、私が注目したいくつかのリリースです。 AWS Lambda のコンソールと IDE の統合機能やリモートデバッグ機能でサーバーレス開発を簡素化 – AWS Lambda で、ブラウザから Visual Studio Code への開発者ワークフローを合理化する、コンソールと IDE の統合機能とリモートデバッグ機能の提供が開始されました。これらの機能強化により、時間のかかるコンテキストの切り替えが不要になるとともに、開発者が好みの IDE 環境で Lambda 関数を直接デバッグできるようになります。 Amazon ECS の新しい組み込みブルー/グリーンデプロイで安全なソフトウェアリリースを迅速化 – Amazon ECS で、コンテナ化されたアプリケーションデプロイの安全性と一貫性を向上させる、組み込みブルー/グリーンデプロイの提供が開始されました。この機能により、カスタムデプロイツールを構築する必要がなくなると同時に、ロールバック機能やデプロイライフサイクルフックを使用することで、自信を持ってソフトウェアアップデートをリリースできます。 Amazon Bedrock AgentCore の紹介: AI エージェントをあらゆる規模でセキュアにデプロイして運用 – Amazon Bedrock AgentCore は包括的な一連のエンタープライズグレードサービスで、開発者が任意のフレームワークとモデルを使用して AI エージェントの大規模なデプロイをすばやく安全に行えるようにします。AgentCore Runtime、Memory、Observability、Identity、Gateway、Browser、および Code Interpreter の各サービスが含まれており、これらが連携してインフラストラクチャの複雑性を解消します。 AWS 無料利用枠の更新: 新規のお客様は最大 200 USD のクレジットで AWS の使用を開始し、検証できます – AWS 無料利用枠で、新規のお客様に最大 200 USD の AWS クレジットを付与する強化特典が提供されるようになりました。サインアップ時に 100 USD を受け取り、EC2、RDS、Lambda、Bedrock、AWS Budgets を使ったアクティビティを完了すると、さらに 100 USD を獲得できるため、コストを発生させずに AWS サービスを簡単に検証できるようになります。 Amazon EventBridge の新しいログ記録でイベントドリブンのアプリケーションを監視してデバッグ – Amazon EventBridge で、強化されたログ記録機能の提供が開始されました。この機能は、成功、失敗、ステータスコードに関する詳細情報を伴う包括的なイベントライフサイクル追跡を実現します。この新しいオブザーバビリティ機能は、イベントジャーニーの全体を可視化することで、マイクロサービスとイベントドリブンアーキテクチャの監視における課題に対処します。 Amazon S3 Vectors の紹介: 大規模なネイティブベクトルサポートを備えた初のクラウドストレージ – Amazon S3 Vectors は、耐久性を備えた専用ベクトルストレージソリューションで、ベクトルのアップロード、保存、クエリにかかるコストの総額を最大 90% 削減できます。Amazon S3 Vectors は、大規模なベクトルデータセットを保存し、AI アプリケーションに 1 秒未満のクエリパフォーマンスを提供するためのネイティブサポートを備えた初のクラウドオブジェクトストアです。 Amazon EKS が、クラスターあたり 10 万個のノードをサポートする超大規模な AI/ML ワークロードを実現 – Amazon EKS が、単一のクラスター内で最大 10 万個のワーカーノードをサポートするようになりました。このため、お客様は最大 160 万個の AWS Trainium アクセラレーターまたは 80 万個の NVIDIA GPU にスケールアップできます。この業界トップクラスのスケール機能により、お客様は Kubernetes 適合性と使い慣れた開発者エクスペリエンスを維持しながら、1 兆パラメータモデルをトレーニングし、AGI 開発を進展させることができます。 AWS Builder Center より もしまだご存知なければ、AWS は先日 AWS Builder Center と統合された community.aws をローンチしました。こちらは、私のおすすめ記事です。 How I Optimized My AWS Bill by Deleting My Account (Corey Quinn 著) – AWS コスト最適化戦略と、請求金額を削減するために検討することもあり得る強硬手段に関する、ユーモアとインサイトにあふれた見解です。 How to setup MCP with UV in Python the right way (Du’An Lightfoot 著) – 最適な開発ワークフローのために、Python で UV パッケージマネージャーを使用して Model Context Protocol (MCP) をセットアップする実践ガイドです。 Extending My Blog with Translations by Amazon Nova (Jimmy Dahlqvist 著) – ブログ記事に翻訳機能を追加する Amazon Nova の機能を利用して、世界中の読者にリーチする方法を学びましょう。 How I used Amazon Q CLI to fix Amazon Q CLI error “Amazon Q is having trouble responding right now” (Matias Kreder 著) – Amazon Q CLI を使用して Amazon Q 独自のエラーを解決する方法を実証する実践的なトラブルシューティングガイドで、AI 支援のデバッグの力を明らかにします。 近日開催される AWS イベント カレンダーを確認して、今後の AWS や AWS コミュニティのイベントにサインアップしましょう。 AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルならば、 All Builders Welcome Grant プログラム に申し込むこともできます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。台北 (7 月 29 日)、 メキシコシティ (8 月 6 日)、 ジャカルタ (6 月 26～27 日) など、最寄りの都市で開催されるイベントにご登録ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 シンガポール (8 月 2 日)、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18日) です。 今後開催されるすべての AWS 主導の対面イベント と 開発者向けの仮想イベント をご覧いただけます。 7 月 21 日週のニュースは以上です。7 月 28 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Donnie この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ビルダー ID に参加: builder.aws.com で AWS Builder ジャーニーを始めましょう 原文は こちら です。

7 月 16 日、 ニューヨーク市で開催された AWS Summit で、エージェンティック AI 担当 AWS VP の Swami Sivasubramanian が、本番環境ですぐに使える AI エージェントをお客様が大規模に提供できるようにする方法について、基調講演を行いました。イベントでの主な発表を以下のとおりご紹介します。 Amazon Bedrock AgentCore のご紹介: あらゆる規模の AI エージェントを安全にデプロイして運用 (プレビュー) Amazon Bedrock AgentCore を使用すると、エンタープライズグレードのセキュリティを備えた AI エージェントの迅速なデプロイとスケーリングが可能になります。メモリ管理、ID 制御、ツール統合が提供されているため、オープンソースのフレームワークや基盤モデルを使用しながら、開発を効率化できます。 Amazon SageMaker AI での Amazon Nova カスタマイズの発表 AWS では、モデルトレーニングのすべての段階で SageMaker AI を使用して、Amazon Nova 基盤モデルを広範囲にカスタマイズできるようになりました。すぐに使える SageMaker レシピとして利用できるこれらの機能により、お客様はトレーニング前とトレーニング後の両方で Nova 理解モデルを適応させることができます。これには、業界全体のビジネス固有の要件により適切に対応するための微調整レシピや調整レシピも含まれます。 AWS 無料利用枠の更新: 新規のお客様は最大 200 USD のクレジットを使用した AWS の利用開始が可能に AWS は無料利用枠プログラムを強化し、新規ユーザー向けに最大 200 ドルのクレジットを用意しています。サインアップ時に 100 USD、Amazon EC2、Amazon Bedrock、AWS Budgets などのサービスでアクティビティを完了すると、さらに 100 ドルを獲得できます。 TwelveLabs の動画理解モデルが Amazon Bedrock で利用可能に TwelveLabs の動画理解モデルを Amazon Bedrock で利用できるようになりました。これにより、お客様は動画の検索、シーンの分類、コンテンツの要約、インサイトの抽出を、正確かつ確実に行うことができます。 Amazon S3 メタデータがすべての S3 オブジェクトのメタデータのサポートを開始 Amazon S3 Metadata では、ライブインベントリテーブルとジャーナルテーブルを通じて S3 バケット内のすべてのオブジェクトを包括的に可視化できるようになりました。これにより、変更から 1 時間以内の自動更新を使用して、既存のオブジェクトと新しいオブジェクトの両方を SQL ベースで分析できるようになりました。 Amazon S3 Vectors のご紹介: 大規模なネイティブベクトルサポートを備えた初のクラウドストレージ (プレビュー) Amazon S3 Vectors は、大規模なベクトルの保存とクエリをネイティブサポートする新しいクラウドオブジェクトストアです。従来のアプローチと比較して最大 90% のコスト削減を実現すると同時に、Amazon Bedrock ナレッジベース、SageMaker、AI アプリケーション用 OpenSearch とシームレスに統合できます。 Amazon SageMaker の新機能で、データからインサイトへのパスを合理化 Amazon SageMaker は、ダッシュボードの作成、ガバナンス、共有のための Amazon QuickSight 統合、ドキュメントとメディアファイルをカタログ化するための Amazon S3 非構造化データ統合、Lakehouse からの自動データオンボーディングという 3 つの新機能を導入しました。これらの機能は、構造化データと非構造化データの管理、視覚化、ガバナンスを単一のエクスペリエンスに統合することで、データサイロを排除します。 新しい Amazon EventBridge ログ記録で、イベントドリブンのアプリケーションをモニタリングおよびデバッグ Amazon EventBridge では、包括的なイベントライフサイクル追跡を提供する強化されたログ記録機能が提供されるようになりました。これにより、イベントが公開されたとき、ルールと照合されたとき、サブスクライバーに配信されたとき、または障害が発生したときを示す詳細なログを使用して、ユーザーがイベントドリブンのアプリケーションを監視およびトラブルシューティングできるようになります。 Amazon EKS がクラスターあたり 10 万ノードをサポートし、超大規模な AI/ML ワークロードを実現 Amazon EKS は現在、クラスターあたり 100,000 ノードまで拡張可能で、最大 160 万台の AWS Trainium アクセラレーターまたは 80 万個の NVIDIA GPU を使用して大規模な AI/ML ワークロードを実現しています。これにより、組織は Kubernetes との互換性と既存のツール統合を維持しながら、大規模な AI モデルのトレーニングと実行を効率的に行うことができます。 原文は こちら です。

本記事は米国時間 7 月 16 日に公開された「 AWS announces new innovations for building AI agents at AWS Summit New York 2025 」の日本語抄訳版です。 Amazon Bedrock AgentCore に加え、AWS Marketplace の新たなカテゴリーとAgentic AI開発の後押しに向けた1億米ドルの投資を発表 主なポイント： Amazon Bedrock AgentCore により、企業・組織は AgentCore の7つのコアサービスを活用し、安全な AI エージェントをエンタープライズ規模で導入・運用することが可能に AWS Marketplace の新カテゴリー追加により、企業・組織は有力プロバイダーによる AI エージェントやツールを簡単に見つけ、調達し、導入することが可能に 生成AIイノベーションセンター に 1 億米ドルを追加投資し、Agentic AI の開発・展開のさらなる加速を支援 Amazon Nova の新たなカスタマゼーション機能により、企業・組織のニーズにあった精度と柔軟性を実現 アマゾン ウェブ サービス（AWS）はこれまで、クラウドコンピューティングにおけるセキュリティ、信頼性、データプライバシーの基準を築いてきました。AWS は今回、AI エージェントの構築を支援する新たな機能とツールの発表により、同じ原則を Agentic AI にも適用します。お客様はこれにより、AWS の堅牢なテクノロジー基盤の上に AI エージェントを構築できるようになります。なかでも、Amazon Bedrock AgentCore は、お客様による高機能な AI エージェントのセキュアかつスケーラブルな導入・運用を支援するものです。 AWSで Agentic AI を統括するバイスプレジデントであるスワミ・シバスブラニアン（Swami Sivasubramanian） は AWS Summit New York の基調講演に登壇し、 AWS における Agentic AI 戦略 の要点を説明しました。AI エージェントは AI を活用して推論・計画・適応し、タスクを完了する自律的なソフトウェアシステムであり、あらゆる業界でイノベーションを加速させ、生産性を大きく向上させると述べました。 シバスブラニアンは次のように述べています。「これは複数の点で地殻変動のような大きな変化です。ソフトウェアの構築方法が根本から変わり、その展開・運用においても多くの新しい課題が浮上してきています。そして最も大きな影響として、ソフトウェアと世界との関わり方、そして私たちとソフトウェアの関係そのものが変わります」 Amazon Bedrock AgentCore で AI エージェントを大規模に展開・運用 AgentCore は高性能な AI エージェントを導入・運用するための、包括的なサービス群です。あらゆるAIフレームワークやモデルをご利用いただけます。 AI エージェントの導入を進めるなか、企業・組織は重要な課題に直面しています。それは、セキュリティ、信頼性、ガバナンスといったエンタープライズレベルの基準を満たしながら、デジタルの境界を越えて自律的に動作するシステムを構築することです。 AgentCore は、AI エージェントにおける概念実証（PoC）から本番運用に至るまでの重要なギャップを開発者が乗り越えるのを支援します。プロトタイプから、数百万ものエンドユーザーに対応できる拡張性の高いアプリケーションへと移行するための、多様な組み合わせが可能なソリューション群を提供します。Itaú Unibanco、Innovaccer、Boomi、Epsilon、Box といった AWS のお客様がすでに AgentCore を使った開発を始めています。 Amazon Bedrock AgentCore の主なサービス： AgentCore Runtime — エージェントには安全性を確保しつつ、変動するワークロードにも対応できる柔軟な実行環境が必要です。AgentCore Runtime は、低遅延でインタラクティブなエクスペリエンスと、業界最長となる最大8時間の複雑な非同期ワークロードの処理をサポートします。また、すべてのセッションを完全に分離可能な、唯一のフレームワーク非依存のサービスです。 AgentCore Memory — 人間が短期記憶と長期記憶の両方を活用するように、エージェントも効率的に動作するためには複雑なメモリ基盤が必要です。AgentCore Memory は、業界トップクラスの精度で短期記憶と長期記憶を提供し、開発者がコンテキストを理解するエージェントをより簡単に構築できるようにします。 AgentCore Identity — エージェントがユーザーのリクエストを実行するには、適切な認証を通じてツールやリソースへ安全にアクセスできる必要があります。AgentCore Identity は、Amazon Cognito、Microsoft Entra ID、Okta などユーザー認証とアクセスコントロールを一元管理を支援する、既存の アイデンティティ（ID） プロバイダーと連携し、シームレスかつ安全なエージェント認証を実現します。 AgentCore Gateway — AI エージェントが実世界のタスクを実行するには、多様なツールへのアクセスが欠かせません。AgentCore Gateway は、API、Lambda 関数、既存のサービスをエージェント対応のツールへ簡単に変換できる仕組みに加え、エージェントがツールを安全に発見・利用できる手段を提供します。 AgentCore Code Interpreter — AI エージェントが複雑な計算を実行、推論を検証し、データを処理し、ビジュアルを生成するためには、サンドボックス環境でコードを安全に記述・実行できる必要があります。AgentCore Code Interpreter を使えば、開発者は特定のインスタンスタイプやセッション設定を指定して、安全なコード実行環境を用意し、セキュリティ要件に対応することが可能です。 AgentCore Browser Tool — AgentCore Browser Tool は、モデルに依存しない高速かつ安全なクラウドベースのブラウザで、AI エージェントがフォーム入力やウェブサイトの操作といったタスクを大規模に実行できるようにします。 AgentCore Observability — 本番環境でのパフォーマンスを確保するには、エージェントのあらゆる動作を追跡・記録できることが重要です。AgentCore Observability は Amazon CloudWatch を基盤とし、主要なメトリクスに関するテレメトリーや組み込みダッシュボードを通じて、開発者にリアルタイムの可視性を提供します。また、既存のオブザーバビリティツールとも統合可能です。 企業のAIエージェント活用をよりシンプルにするAWS Marketplace 新カテゴリー シバスブラニアンは AWS Summit New Yorkで、 AWS Marketplace の新カテゴリー「AIエージェントとツール」の追加を発表しました。これにより、お客様は有力プロバイダーが提供する AI エージェントやツールを簡単に見つけ、調達し、導入・管理できるようになります。 AWS Marketplace の「AIエージェントとツール」カテゴリーを使えば、お客様は AI エージェントソリューションやツールをワンストップで検索・購入でき、AI 活用の取り組みを迅速に進めることができます。このカテゴリーを活用することで、すぐに統合できるツールを使って開発を加速できるだけでなく、エージェントの構築・運用・スケーリングを専門とする AWS プロフェッショナルサービスと連携しながら、AI 戦略を前進させることも可能です。 AWS 生成AIイノベーションセンターへの追加投資を発表 お客様による自律的な Agentic AI システムの開発を加速するため、AWS は 生成 AI イノベーションセンター に 2 回目となる 1 億米ドルの追加投資を行うことを 発表 しました。これは、過去 2 年間にわたって世界中の数千社に及ぶお客様を支援し、生産性の向上や顧客体験の変革を後押ししてきた実績を踏まえたものです。 例えば、 Warner Bros. Discovery Sports Europe は、Amazon Bedrock、Anthropic の Claude 3.5、その他の AWS サービスを活用し、自転車レースの実況担当者が素早く過去の記録などを調べることができる AI ソリューションを開発しました。また BMW は、2,300 万台以上に達するコネクテッドカーに対するネットワーク障害の診断方法を一新する AI ソリューションを AWS 上に構築しました。Syngenta や AstraZeneca といった企業も、Agentic AI によって業務に大きな変化をもたらしています。 AWS 生成AIイノベーションセンターには、AI サイエンティスト、ストラテジスト、エンジニアからなるグローバルチームが在籍しており、企業をはじめとするお客様やパートナーと直接連携しながら、AI 実装における最も複雑な課題の解決に取り組んでいます。 AWS Summit New York のその他の発表 Amazon Nova の新しいカスタマイズ機能：より高精度で柔軟なモデルの構築が可能に Amazon SageMaker AI 上で動作する Amazon Nova に 新たなカスタマイズ機能 が追加され、SageMaker HyperPod のサポートも加わりました。これにより、お客様は Nova を自社のニーズにさらに合わせて最適化できるようになります。また、 Nova Act SDK の 強化 を通じて、精度向上に加え、セキュリティやアクセス制御が拡張されました。これにより、開発者はウェブブラウザ上で確実に動作するエージェントを構築できるようになります。 Amazon S3 Vectors を発表 Amazon S3 Vectors は、AI ワークロードをサポートする初のクラウドオブジェクトストレージです。Amazon S3 Vectors により、お客様は従来の方法と比較し、ベクトルの保存とクエリのコストを最大 90% 削減できます。大規模なベクトルデータセットを保存・活用して AI を強化したり、S3 データのセマンティック検索において、コストパフォーマンスの高いソリューションを提供します。Amazon Bedrock Knowledge Bases や OpenSearch Service と連携し、検索拡張生成（RAG）やベクトル検索の運用を効率化・低コスト化します。 Kiro：プロトタイプからプロダクションまでを橋渡し Kiro は、AI エージェントを活用したソフトウェア開発に取り組む開発者向けの新しい IDE（統合開発環境）です。開発体験をシンプルにし、AI エージェントとのコラボレーションをより身近なものにします。Kiro を使えば、vibe coding だけでなく、Kiroスペックや Kiroフック といった機能を活用して、エージェントと一緒に詳細な設計を進めたり、テストの実行やドキュメント生成などのタスクを自動で実行するワークフローを起動したりできます。 Agentic な世界での構築を後押しする新たな MCP リソース Model Context Protocol（MCP） は、エージェントがデータソースやツール、メモリバンクなどに接続するための新たな標準仕様です。今回発表した ローカル AWS API MCP サーバー は、AWS の API 全体に関する知識を完全に備えており、開発者が AWS と連携しながら vibe coding を行えるようにします。これにより、あらゆるソフトウェアアシスタントが AWS に精通することがより簡単になります。さらに、2つ目のリソースとして提供される AWS Knowledge MCP サーバー は、AWS のドキュメントに関する包括的な知識を常に最新の状態で保持した MCP で、完全にマネージドかつ継続的に更新され、任意の MCP クライアントからリモートで利用可能です。 TwelveLabs の AI モデルが Amazon Bedrock で利用可能に TwelveLabsの AIモデル は、映像・音声・テキストを同時に処理することで、動画ライブラリを検索可能で活用しやすい資産へと変換します。お客様は自然言語のプロンプトを使って、目的のコンテンツを瞬時に見つけ、アクションをとることができるようになります。これらすべてが、AWS のセキュリティ、プライバシー、パフォーマンスのもとで提供されます。AWS は TwelveLabs のモデルを提供する初のクラウドプロバイダーです。 AWS と Meta がスタートアップ支援で連携 AWS と Meta は、Metaの基盤モデルである Llama を活用したAI アプリケーション構築を支援 するため、米国のスタートアップ 30 社を対象に、1 社あたり最大 20 万ドル分の AWS クレジットと、Meta および AWS の専門家による技術サポートを提供します。この 6 か月間のプログラムへの参加応募は、2025年8月8日までです。Llama モデルを使った最先端の AI アプリケーション開発を後押しすることで、AI イノベーションを加速させます。 Strands 1.0 により、AI エージェント同士の連携がより簡単に AWS は、オープンソース SDK Strands Agents のアップデートも発表しました。これは、複数の AI エージェントが連携して複雑な課題を解決するシステムを、これまでにないほど簡単に構築できる開発者向けツールです。従来は数か月かかっていた複雑な技術作業を、わずか数時間のプロセスに短縮できるため、企業はカスタマーサービス、データ分析、その他の高度なタスクを担う協調型 AI アシスタントのグループを構築しやすくなります。 ゲーミフィケーションで AI スキルを習得できる「AWS AI League」 AWS は、開発者が 生成AI を使って実世界の課題に挑戦しながら、組織内でのイノベーションに不可欠なスキルを習得できる「 AWS AI League 」を開始しました。このプログラムでは、開発者がファインチューニング、モデルのカスタマイズ、プロンプトエンジニアリングなどを実践的に学ぶため、最大 200 万ドル分の AWS クレジットを提供します。上位入賞者には、AWS re:Invent への全額負担の招待旅行や賞金が贈られます。 AWS、AI 時代のキャリアに備える若手人材育成に 300 万米ドルを投資 AWS は、6,600 以上の AWS Academy 加盟校の学生に対し、AWS Skill Builder の有料トレーニングコンテンツと AWS 認定試験の受験バウチャーを無償で提供し、AI 時代に求められるスキルの習得を支援します。また、Academy に属さない学生や新卒者も、将来有望なキャリア分野に関する調査レポートや、それにもとづくAWS Skill Builder 上の無料学習プランを活用してキャリア形成に活かすことができます。AWSは、初年度にグローバルで270万人の学生及び新卒者の参画を目標としています。

合併と買収 (M&A) は、事業を拡大し、製品ラインを多様化し、新しい市場を開拓する機会を組織にもたらします。ただし、旧来の IT システムの統合、厳しい規制への準拠、事業継続性の維持など、そこにはさまざまな課題が伴います。リソースの重複を排除し、プロセスを最適化して運用の一貫性を実現するのと同時に、コストを管理および最適化することは、合併を完了したり M&A 活動を行ったりした後にビジネス価値を最大化する上で、極めて重要な役割を果たします。 このブログ記事では、AWS Organizations を利用したM&A 後の AWS リソースとコストの最適化と管理に関するベストプラクティスと考慮事項について説明します。また、 Amazon S3 Storage Lens 、 AWS Compute Optimizer 、 AWS Cost Optimization Hub (コスト最適化ハブ) など、AWS Organizations が統合しているさまざまなコスト最適化サービスや分析サービスを紹介し、活用します。 前提条件 AWS Organizations 、 AWS Control Tower 、および AWS でのマルチアカウント設定 を理解していること その M&A に関連する買収元企業と買収先企業の両方について、AWS Organizations で設定されている organization (※訳注：一般的な意味での “組織” と区別するために本記事では “organization” と表記します) の構造を理解していること 合併元 organization からメイン organization へのアカウントの移行が完了していること ベストプラクティスと推奨事項 合併後の organization で適用可能なタグを評価し、リソースをグループ化してコストの一元管理を行う 合併後は、新たに合併されたビジネス内でタグを調整する戦略を立て、 Resource Groups を利用してプロジェクトや環境、コストセンターなどの特定の基準に基づいてAWS リソースの論理的なコレクションを作成する必要があります。それにより、アップデートの適用、アプリケーションのアップグレード、ネットワーク設定の調整などの一括アクションを実行でき、それと同時にリソース全体のコストを容易に追跡・管理することができます。また、コスト要因の特定、予算の設定、リソース使用の最適化も行えるため、最終的に AWS における潜在的なコスト削減につながる可能性もあります。 包括的な可視性を得るには、AWS Organizations を使用して一元化された”請求とコスト管理” のフレームワークを確立してください。AWS 上で実行されているアプリケーションがあり、リソースが EC2 インスタンス、RDS データベース、S3 バケットなどの複数のサービスに分散している場合を想定してみましょう。このアプリケーション用のリソースグループを作成し、すべてのリソースをグループ化することができます。これにより、グループ内のすべてのリソースの合計コストを確認できるようになり、 コストの集中箇所の特定 や、使用パターンの分析、実際の需要に基づいたリソースのサイズ適正化などを行うことが容易になります。また、利用できていないリソースや過剰な支出を削減することもできます。 例えば、リザーブドインスタンスやスポットインスタンスなどのコスト最適化戦略を グループ全体に適用して、コスト削減を最大化 することができます。AWS Resource Groups を使用して、リソースグループと呼ばれるキャパシティ予約の論理的なコレクションを作成できます。また、属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が異なるキャパシティ予約を 1 つのリソースグループに含めることもできます。キャパシティ予約のリソースグループを作成すると、個々のキャパシティ予約ではなく、キャパシティ予約のグループにインスタンスを割り当てることができます。キャパシティ予約のグループをターゲットとするインスタンスは、グループ内の任意のキャパシティ予約のうち属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が一致し、かつ他のインスタンスに割り当てられておらず利用可能なものとマッチングされます。 費用を正確に追跡するために、コストセンターを設けて、すべての AWS リソースに 一貫したコスト配分タグを実装 してください。例として、A 社と B 社が合併した後、「Project Alpha」と「Project Bravo」というワークロードが重複している各社のプロジェクトについて、コストの可視化を維持しながら AWS 環境を統合する必要がある場合を考えてみましょう。 コスト配分タグは以下のシナリオで役に立ちます: ”Project“, ”Environment“, ”CostCenter“, ”Application“, ”Department“ などの統一されたタグ構造を定義します。 リソースを移行し、統一された構造に従ってタグ付けをし直します。例えば、“Project Alpha” リソースには “Project=Alpha”, “Environment=Production”, “CostCenter=IT” のようにタグ付けし、“Project Bravo” リソースには “Project=Bravo”, “Environment=Live”, “Department=Engineering” のようにタグ付けします。 重複しているワークロードを識別し、両方のプロジェクト名でタグ付けします。例えば、共有データベースリソースには “Project=Alpha”, “Project=Bravo”, “Environment=Production”, “CostCenter=IT”, “Department=Engineering” のようにタグ付けします。 AWS Cost Explorer を使用して、さまざまなタグの組み合わせに基づいてコストレポートを生成します。これにより、共有コストを含め、各プロジェクト、環境、コストセンター、または部門に関連するコストを可視化できます。 共有リソースへの比例配分を含め、それぞれのプロジェクト、コストセンター、または部門に正確にコストを帰属させるコスト配分モデルまたはチャージバックモデルを実装します。 合併後の organization におけるリソースの重複を特定および削減する organization が合併する際、クラウド環境間で重複が発生し、無駄な支出につながることがよくあります。包括的なレビューを行うことで、リソースの余剰を明らかにし、最適な統合を実現することができます。 まず AWS Organizations で有効にした AWS Cost Optimization Hub (コスト最適化ハブ) を活用して、合併後の事業体全体の AWS コスト最適化推奨事項の特定、フィルタリング、集計から始めることをお勧めします。それにより、リソースのサイズ適正化、アイドル状態のリソースの削除、Savings Plans、およびリザーブドインスタンスに関する推奨事項が得られます。図 1 に示すように、Cost Optimization Hub を使用することで、合併後の organization 全体で推奨されるコスト最適化と統合された調査結果を 1 つのダッシュボードで確認することができます。そこで推定される節約額は、AWS アカウント、AWS リージョン、リソースタイプなどでフィルタリングして集計することができます。 自動化された推奨事項がニーズに合わず、コスト最適化分析を自分で行いたい場合は、AWS Organizations と統合された AWS Cost Explorer を利用することで organization 全体の推奨事項を可視化することができます。 図 1: Cost Optimization Hub (コスト最適化ハブ) で毎月の節約額を見積もる エンタープライズサポート のお客様の場合、 AWS Trusted Advisor からの最適化に関する更なる推奨事項も確認いただけます。Trusted Advisor は、図 2 に示すように、十分に活用されていないリソース、アイドル状態のロードバランサー、その他のコスト削減の可能性がある領域を特定するのに役立ちます。 organization 全体で AWS Trusted Advisor を有効 にし、 推奨事項を含むレポートを作成する ことをお勧めします。より規範的なガイダンスやベストプラクティスについては、ブログ記事「 AWS Trusted Advisor による運用上の優秀性の継続的な最適化 」をご覧ください。 図 2: AWS Trusted Advisor はコスト最適化のチェックの特定に有用 AWS Config は、AWS アカウント内のリソースの設定と関係性を評価、監査、確認することができます。このサービスは コスト最適化にも使用 できます。特定の Amazon Relational Database Service (Amazon RDS) インスタンスがアカウントにデプロイされた場合にアラートを受け取ることができるシナリオを考えてみましょう。必要以上に大きなインスタンスタイプを使用されている場合、特定のアカウントに予期せぬコストが発生する可能性があります。これに対処するには、AWS Config にカスタムルールを実装し、データベースインスタンスを監視してアラートを提供することでコストを最適化できます。 合併後のビジネスニーズに合わせてコンピューティングコストを最適化する AWS Compute Optimizer は、AWS Organizations を通じて管理されている複数のアカウントにわたって EC2 インスタンスを適切なサイズにするための推奨事項を提供することで、M&A 後のコストを最適化するのに役立ちます。ワークロードパターンを分析し、パフォーマンス要件を満たしながらコストを削減できるインスタンスタイプを提案します。Organizations でアカウントを統合し、Compute Optimizer の推奨事項を活用することで、十分に活用されていないインスタンスやサイズが大きすぎるインスタンスを特定して排除し、統合後の組織のコンピューティングリソース全体でコスト削減につなげることができます。 図 3: AWS Compute Optimizer – 動作の仕組み Compute Optimizer コンソールから Compute Optimizer を AWS Organizations と統合します。これにより、Compute Optimizer はサービスに必要なリソースの作成などの必要な設定を実行できるようになります。 AWS Compute Optimizer の使用を開始するには、Compute Optimizer コンソールを使用して メンバーアカウントを Compute Optimizer の委任管理者として指定 します。委任管理者アカウントを使用して、organization 内のすべてのアカウントのリソース最適化の機会を特定するように Compute Optimizer を設定します。詳細については、「 AWS Compute Optimizer の開始方法 」を参照してください。コンテナワークロードを扱う場合は、 organization 内の複数アカウント間での分割コスト配分データ (SCAD) を活用することができます。 ワークロードとインフラストラクチャが増えるにつれて、リザーブドインスタンスを利用してコストを削減したり、使用量に応じた階層型料金によるメリットを活用したりできる機会が増えます。適切なリザーブドインスタンス (RI) の構成を決定するには、使用パターンを分析することが重要です。両方の organization の既存の RI コミットメントを評価し、M&A 後の環境への適用可能性を評価します。使用パターンやインフラストラクチャの要件の変更に合わせて RI を必要に応じて変更または移管することで、RI の使用率を高め、コストを削減できます。 統合的なデータアーカイブとストレージの戦略を策定する M&A のトランザクションが終わったら、両 organization のストレージ使用状況を見直し、コスト削減の機会を見極めましょう。統合プロセス中または統合プロセス後のデータ保持とコンプライアンス要件を管理するためのデータアーカイブおよびストレージ戦略を策定します。 Amazon S3 Storage Lens は、オブジェクトストレージの使用状況やアクティビティの傾向を organization 全体で可視化し、コストを最適化してデータ保護のベストプラクティスを適用するための実行可能な推奨事項を提示します。S3 Storage Lens は、組織内の数百、数千ものアカウントにわたるオブジェクトストレージの使用状況とアクティビティを単一のビューで提供し、ドリルダウンして複数の集計レベルでインサイトを得ることができる初めてのクラウドストレージ分析ソリューションです。S3 Storage Lens を使用すると、そのバケット内のオブジェクトへのアクセスが頻繁ではない “コールド S3 バケット” を識別できます。図 4 に示すように、アカウント、リージョン、バケット、またはプレフィックスに基づいてフィルターを追加することで、詳細なインサイトを可視化できます。 Amazon S3 Glacier や Amazon S3 オブジェクトライフサイクルポリシー などの AWS ストレージサービスを活用することで、データアーカイブとライフサイクル管理を自動化し、時間の経過とともにストレージコストを削減することができます。 図 4: Amazon S3 Storage Lens では、organization 内のすべての S3 バケットにわたるオブジェクトストレージの使用状況とアクティビティを一元的に確認可能 バックアップポリシーとデータ保持の効率的かつ一元的なデータ管理を行うには、 AWS Backup の AWS Organizations との統合を有効化 してください 。これは、合併後の organization の複数の AWS アカウントとサービスにわたるバックアップとデータ保護を一元管理するための、費用対効果の高いソリューションを提供するものです。詳細については、「 AWS Backup のコストを最適化する 」を参照してください。 ネットワークインフラストラクチャの重複箇所を特定し解消する M&A では、しばしば異なる IT インフラストラクチャを統合する必要がある場合があり、それによって重複や非効率性が生じる可能性があります。これらのトランザクションには通常、ハイブリッドネットワークが含まれます。M&A の後に AWS でのデータ転送やネットワークのコストの最適化を怠ると、多額の不要な支出が発生する可能性があります。データ転送とネットワークの最適化の手法を活用することで、最終的には M&A による財務上のメリットと相乗効果を最大限に引き出すことができます。 M&A において、新規アカウントを既存の AWS Organizations 構造に統合する際には、IT インフラストラクチャの統合と、データ転送やネットワークなどの関連コストの最適化が重要となります。主なステップには、リージョン別のデータ転送パターンの特定および統合、データ転送料金を削減するための AWS PrivateLink や Resource Access Manager の活用、一元的な VPC 接続管理のための AWS Transit Gateway の利用などがあります。 AWS Data Exports と Amazon QuickSight による一元的なコストモニタリングにより、統合された請求データの可視化が可能になります。AWS Organizations 内で サービスコントロールポリシー (SCP) を実装することで、統合されたアカウント全体にコスト最適化プラクティスを強制的に適用できる一方、 AWS コスト配分タグ を使用することで、特定のビジネスユニットやプロジェクトにコストを分類し配分することが可能です。 統合フェーズでのネットワーク最適化の推奨事項の詳細については、 AWS ネットワーク最適化のブログ投稿 を参照してください。 サポートおよびライセンスにかかるコストを管理する 適切なサポート計画を立てることで、コストの削減、リスクの軽減、事業継続性の確保、合併後の事業体のより円滑な管理の促進が可能になります。そのために エンタープライズサポートプラン へアップグレードをお勧めします。このプランでは、AWS コスト最適化の専門家によるサポートを受けることができるようになります。そこでは AWS のアーキテクチャや使用パターンのレビューを通して、リソースの最適化やインスタンスのサイズ適正化、リザーブドインスタンスの活用、費用対効果の高いサービスやアーキテクチャの採用などについて、カスタマイズされた推奨事項が提供されます。 エンタープライズサポートの大きな利点は、organization 全体を対象としていることです。organization 全体でエンタープライズサポートプランを契約すると、追加または招待したすべてのアカウントに自動的に同じレベルのサポートが継承されます。これによりプロセスが合理化され、合併時に各アカウントに個別のサポートプランを付与する必要がなくなります。ただし、この機能は現在一部のリージョンのお客様のみが利用可能であり、お客様のエンタープライズ契約にはそのための必要な条項が含まれている必要があります。この機能を有効にする資格や、サポートプランに関する追加情報についてはテクニカルアカウントマネージャーにお問い合わせください。 AWS License Manager を使用することで、ソフトウェアライセンスの管理やライセンスコストの調整が可能になります。AWS Organizations と AWS License Manager を統合することで、organization 全体のライセンスを可視化できます。合併後の事業体全体のソフトウェアライセンスを一元的に可視化できるため、M&A の際のライセンスコストの最適化に役立ちます。図 5 は AWS License Manager がどのようにライセンスの追跡、プール化、再配布を可能にするかを示しており、これによりコンプライアンスを確保しながら重複購入を回避して、大幅なコスト削減につなげることができます。 図 5: AWS License Manager ダッシュボードは AWS およびオンプレミス環境全体にわたる Microsoft、SAP、Oracle、IBM などのベンダーからのソフトウェアライセンスの概要を提供 ソフトウェア調達を効率化し、重複するライセンスを排除し、合併後の事業体全体で統合された可視性を確保するために、organization 全体で AWS Private Marketplace を有効にすることをお勧めします。これにより、中央集権的なガバナンス、コスト管理、および効率的なソフトウェア配布が可能になり、M&A の際にスムーズな移行を可能としつつ、コスト削減を実現することができます。 M&A 成功後に継続的にコストを監視し最適化する M&A 後は、自組織の環境内のコストを継続的に監視することが極めて重要です。これは通常、当組織が最大限の最適化のためのスコープと機会を持ち、環境内での効率性を向上させる立場にあるためです。プロアクティブなコスト監視と最適化のプラクティスを確立し、進化するビジネスニーズとコスト要因に基づいてリソースの使用量を継続的にレビューして調整します。定期的にコスト最適化レビューを実施して、不要または十分に活用されていないリソースを特定して排除するように計画してください。これには、インスタンスのサイズ適正化、未使用リソースの削除、費用対効果の高い価格モデル (リザーブドインスタンス、スポットインスタンスなど) の活用などが含まれます。 合併後の organization の複数のアカウントで Amazon CloudWatch メトリクスをモニタリングすることで、CPU/メモリの使用量が低く、ダウンサイジングや終了が可能な、十分に活用されていないリソースを確認できます。使用パターンに基づいてリソースを起動および停止することで、アイドル状態のリソースのコストを削減できます。 AWS Budgets と AWS Cost Anomaly Detection をセットアップして、データ転送やネットワーキングに関連する潜在的なコスト急増や異常が発生したときにアラートや通知を受け取るようにしてください。AWS Lambda 関数を使用してアイドル状態のリソースを自動的に停止または終了する自動最適化を実装してください。また、需要に基づいてリソース容量を動的に調整する AWS Auto Scaling の使用も検討してください。 コスト管理プロセスと手順を文書化する M&A を通じて得たコスト管理のプロセス、手順、および得られた教訓を文書化して、組織の知識を把握し、統合後の組織への知識移転を促進してください。統合後のコストを効果的に管理できるように、コスト管理のベストプラクティス、ツール、プロセスについてステークホルダーにトレーニングとサポートを提供してください。これにより、コスト意識の文化が育まれ、M&A 移行期間中の効果的なコラボレーションが可能になります。 社内に知識共有プラットフォームがある場合は、そこにプロセスを文書化してください。また、エンタープライズサポートプランに加入している場合は、フルマネージド型の安全なプライベート空間である AWS re:Post Private を活用して、組織固有のクラウドコミュニティを構築し、独自の知識リソースへのアクセスを提供することもできます。 AWS re:Post Private は、信頼できる AWS 技術コンテンツを一元化し、プライベートな議論の場を提供します。これにより、チームが社内チーム間および AWS と連携する方法を改善して、技術的な障壁を取り除いたり、イノベーションを加速させたり、クラウドでのより効率的なスケーリングを実現したりできるようになります。 サービスを AWS Organizations と統合してボリュームディスカウントを利用する このブログ記事で説明されているサービスは、サービスのコンソールまたは API 操作 / CLI コマンドなどを使用して AWS Organizations 上で有効化することができます。これにより、必要なリソースの作成など、organization に必要なすべての初期化ステップを AWS サービスが実行できるようになります。 合併する organization のアカウントを合併後の organization に統合したら、organization 内のすべてのアカウントの使用量を合算することで、 ボリュームディスカウント 、リザーブドインスタンス割引、および Savings Plans を共有できます。請求の観点からは、AWS は organization 内のすべてのアカウントをあたかも 1 つのアカウントのように扱います。 Amazon Simple Storage Service (Amazon S3) などの一部のサービスには、特定の使用量に応じたボリューム料金階層があり、サービスの使用量が増えるほど料金が低くなります。一括請求により、AWS はすべてのアカウントの使用量を合算して適用するボリューム料金階層を判定し、可能な限り全体的な料金を低く抑えます。その後、AWS は各アカウントの使用量に基づいて全体のボリュームディスカウントの一部を各メンバーアカウントに割り当てます。 たとえば、Bob の一括請求には、Bob 自身のアカウントと Susan のアカウントの両方が含まれているとします。Bob のアカウントは管理アカウントなので、Bob は自分自身と Susan の両方の料金を支払います。Bob はその月に 8 TB のデータを転送し、Susan は 4 TB のデータを転送します。 この例では、AWS は最初の 10 TB のデータ転送に対して GB あたり $0.17、次の 40 TB に対して GB あたり $0.13 を請求します。これは、TB あたりに換算すると最初の 10 TB については $174.08 (= 0.17 × 1,024)、次の 40 TB については $133.12 (= 0.13 × 1,024) に相当します。なお、1 TB = 1,024 GB である点に注意してください。 Bob と Susan が使用した 12 TB については、Bob の管理アカウントに ($174.08 × 10 TB) + ($133.12 × 2 TB) = $1,740.80 + $266.24 = $2,007.04 が請求されます。 一括請求を階層化することのメリットがなければ、AWS は Bob と Susan の使用量に対してそれぞれ TB あたり $174.08 を請求することになり 、合計で $2,088.96 となっていたはずです。 3 つの AWS アカウントがあり、S3 ストレージとしてアカウント A は 10 TB、アカウント B は 15 TB、アカウント C は 20 TB を使用しているものとします。個別のアカウントの場合、それぞれのストレージ階層に基づいて個別に請求されます。これらのアカウントを AWS Organizations を使用している organization に統合すると、45 TB (10 TB + 15 TB + 20 TB) のストレージ使用量の合計が organization レベルで集計されます。この 45 TB の使用量は上位のストレージ階層に該当する可能性が高く、その場合個別アカウントの料金階層と比較して GB あたりの料金が低くなります。 AWS Organizations を通じてこのボリュームディスカウントを利用することで、特に organization 内の複数の AWS アカウントに大量のストレージ要件が分散している場合に、S3 ストレージ全体のコストを大幅に削減することができます。 まとめ このブログ記事で紹介したベストプラクティスを導入することで、組織はリソース利用を最適化し、コストを効果的に管理し、財務リスクを最小限に抑え、合併・買収 (M&A) の活動に関わるすべての関係者にとって統合を成功させることができます。ワーナーブラザーズ・ディスカバリーが AWS Organizations サービスやその他の統合サービスをどのように活用して買収を成功させたかを理解するには「 Improving Mergers and Acquisitions Using AWS Organizations with Warner Bros. Discovery 」をご覧ください。 AWS コストのレビュー、可視化、最適化に対して AWS の推奨事項と支援を最大限に活用するには、このブログ記事で取り上げているコスト最適化ハブ、S3 Storage Lens、Compute Optimizer などのサービスを AWS Organizations と統合してください。分散化された柔軟な管理を実現するために、AWS Organizations と統合されたサービスの委任管理者としてメンバーアカウントを指定することを検討してください。AWS Organizations と統合可能なサービスのリストを確認するには、 AWS Organizations で使用できる AWS サービス をご覧ください。 M&A を進めている中で organization の統合に関するベストプラクティスのガイダンスをお探しの場合は「 AWS Organizations のアカウント評価 」と、 アカウントの効果的な移行に関する 3 部構成のブログ投稿シリーズ を参照してください。さらに詳細な情報については「 Choosing an AWS cost management strategy 」と「 Starting your Cloud Financial Management journey: Cost savings 」をご覧ください。 著者について Nikhil Anand Nikhil Anandは、ロンドンを拠点とする AWS のシニアソリューションアーキテクトです。主にUKI (英国・アイルランド) 地域の中小規模 (SMB) および金融サービス機関 (FSI) のお客様を担当しており、セキュリティ、コンプライアンス、移行の分野でのバックグラウンドを持っています。また、お客様の移行プロセスにおける M&A トランザクションのアドバイザーとしても活動し、お客様の AWS クラウドでの構築とモダナイズを支援しています。仕事を離れると、スポーツに情熱を注ぎ、日々のトレーニングを欠かさず続けることを信条としています。 Nivedita Tripathi Nivedita Tripathi は AWS Organizations の GTM 担当シニアプロダクトマネージャーです。セキュリティとガバナンスのベストプラクティスを活用しながら、複数のアカウントにわたるクラウドインフラストラクチャの構築とスケーリングにおいてお客様を支援することに注力しています。テクノロジーへの深い情熱の一方で、 音楽を楽しみ、世界各地を旅し、家族と大切な時間を過ごすことを何よりの喜びとしています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。