みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年8月25日（月）19:00より、 AWS Startup Loft Tokyo にて「 AWS Database 開発チーム Meet-up 2025 」を開催いたします。Amazon Aurora DSQL、Aurora Limitless Database、DynamoDBの各開発チームよりサービスの特徴や最新のアップデート、そしてチーム構成などを直接対話しながらご説明します。通常のプレゼンテーション形式とは異なり、各セッションでは質疑応答の時間を十分に設け、参加者の皆様が開発チームと技術的な議論や意見交換ができる形式となっています。データベース技術に関心をお持ちの方、AWSデータベースサービスの詳細について知りたい方は、ぜひこの機会にご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年7月28日週の主要なアップデート 7/28(月) Amazon Connect Contact Control Panel (CCP) がリフレッシュされたデザインと操作感を提供開始 Amazon Connect の Contact Control Panel (CCP) が Cloudscape Design System を採用した新しいデザインに更新されました。コールセンターのオペレーターが使う画面の色やボタンのデザインが統一され、より直感的で使いやすくなりました。従来と同じ操作感を保ちながら視覚的に改善されているため、追加のトレーニングは最小限に抑えたうえでオペレーターの作業効率向上が期待できます。全ての AWS リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS IoT SiteWise が多変量異常検知を導入 AWS IoT SiteWise で多変量異常検知機能が一般提供開始となりました。従来は機械学習の専門知識が必要だった産業機器の異常検知が、コードを書くことなく自動化できます。タービンやコンプレッサーなどの複数のセンサーデータを同時に監視し、故障リスクを早期発見できるため、予防保全による効率化とダウンタイム削減に貢献します。バージニア北部、アイルランド、シドニーリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Connect の UI ビルダーが改良された UX/UI をリリース Amazon Connect の UI builder で新しいユーザーインターフェースが提供開始されました。Step-by-Step Guide の各ステップを作成する際の複雑さが軽減され、より直感的にワークフローを構築できるようになりました。これまでより簡単に動的データの受け渡しや、ユーザーが入力したデータの保存が可能です。カスタム変数を定義して複数のフィールドやコンポーネント間で共有できるため、管理者がエージェントや顧客向けに柔軟で強力な体験を作成しやすくなります。東京リージョンを含む 11 のリージョンで利用可能です。 7/29(火) パーティション GPU を搭載した Amazon EC2 G6f インスタンスの一般提供開始のお知らせ Amazon EC2 で G6f インスタンスが一般提供されました。NVIDIA L4 Tensor Core GPU を使った初の GPU パーティショニング機能を備えたインスタンスで、GPU を 1/8 まで分割して利用できます。従来の G6 インスタンスと比べて大幅なコスト削減が可能になり、リモートワークステーションや ML 研究、ゲームストリーミングなどの用途に最適です。東京リージョンをはじめ複数リージョンで利用開始できます。 AWS Backup が Aurora DSQL マルチリージョン復元ワークフローを改善 AWS Backup で Amazon Aurora DSQL のマルチリージョンクラスターのリストアワークフローが改善されました。従来は複数リージョンでのリストア作業が複雑でしたが、今回のアップデートにより単一リージョンからリストアを開始するだけで AWS Backup が全リージョンの処理を自動管理します。リストアの時間短縮と信頼性向上により、障害時のビジネス継続性が大幅に改善されます。詳細は こちらの Blog 記事をご参照ください。 Amazon EC2 Auto Scaling がライフサイクルフックの通知ターゲットとして AWS Lambda 関数を追加 Amazon EC2 Auto Scaling のライフサイクルフックで、AWS Lambda 関数を直接通知先として指定できるようになりました。従来は EventBridge や SNS などの中間サービスが必要でしたが、Lambda 関数を直接呼び出せるためインフラ構成がシンプルになります。例えば、スケールイン時にインスタンス終了前にログをダウンロードしたり、データベース接続を適切にクローズするなどのカスタム処理を実行できます。詳細は こちらのドキュメントをご参照ください。 7/30(水) Amazon CloudFront が新しいオリジンレスポンスタイムアウト制御を導入 Amazon CloudFront で新しいオリジンレスポンスタイムアウト制御機能が提供開始されました。従来は最初のパケットや後続パケットの待機時間のみ設定可能でしたが、今回のアップデートで全パケットとリトライを含む完全なレスポンス完了タイムアウトが設定できるようになりました。また Amazon S3 オリジンでは 30 秒のデフォルトから任意の値にカスタマイズ可能です。メディアストリーミングや API 呼び出しなどレイテンシが重要なワークロードでより細かい制御ができ、ユーザー体験の向上が期待できます。詳細は こちらの Developer Guide をご参照ください。 Database Insights が Aurora Limitless データベースのフリート監視をサポート CloudWatch Database Insights が Aurora Limitless PostgreSQL データベースのフリート監視に対応しました。これまではインスタンスレベルでの監視のみでしたが、今回のアップデートでフリート全体の健全性を統合ダッシュボードから確認できるようになりました。Aurora クラスター、RDS インスタンス、Aurora Limitless PostgreSQL データベースを１つの画面で一元管理でき、運用効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora MySQL 3.10 (MySQL 8.0.42 互換) が一般提供開始 Amazon Aurora MySQL 3.10 が一般提供開始となりました。MySQL 8.0.42 互換ではセキュリティ強化やパフォーマンス改善が行われています。最大の変更点は、ストレージ容量の上限が従来の 128 TiB から 256 TiB に倍増したことです。これにより大規模なデータベースワークロードを単一クラスター内で管理できるようになりました。また、メモリ内リレーログ最適化により、バイナリログレプリケーションの性能が向上し、コミット遅延が削減されています。全ての Aurora MySQL 対応リージョンで利用可能です。7/30(水) 7/31(木) Amazon Q Developer CLI がカスタムエージェントを発表 Amazon Q Developer CLI でカスタムエージェント機能が提供開始されました。従来は一般的な質問対応のみでしたが、今回のアップデートでコードレビューやトラブルシューティングなど専門的なタスクに特化したエージェントを作成できるようになります。設定ファイルで使用ツールや動作を定義し、プロジェクト固有の設定やチーム間での共有も可能です。開発作業の効率化とコンテキスト切り替えの削減が期待できます。詳細は こちらの Blog 記事をご参照ください。 AWS Lambda レスポンスストリーミングが 200 MB のレスポンスペイロードをサポート AWS Lambda response streaming のレスポンスペイロード上限が従来の 20 MB から 200 MB に拡大されました。これにより、リアルタイム AI チャットや Web アプリケーションで、大容量データを直接 Lambda 内で処理できるようになります。以前は大きなファイルを扱う際に S3 を経由する必要がありましたが、画像豊富な PDF や音楽ファイルなども直接ストリーミング処理が可能です。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB Serverless が一般提供開始 Amazon DocumentDB Serverless が正式リリースされました。これは MongoDB 互換のドキュメントデータベースで、アプリケーションの需要に応じて自動でキャパシティをスケールする仕組みです。従来はピーク時の利用量を想定してキャパシティを事前設定する必要がありましたが、今回のアップデートでリソース状況に応じた柔軟な課金となり、最大 90 % のコスト削減が可能になります。特に利用量が変動するアプリケーションや、数千のデータベースを管理する SaaS 事業者に最適です。詳細は こちらの Blog 記事をご参照ください。 Amazon Q Developer が多言語サポートを拡張 Amazon Q Developer が多言語サポートを拡張し、日本語を含む 8 つの言語に対応しました。マネージメントコンソール 上で日本語を使って AWS リソースの監視や運用、トラブルシューティングができるようになります。これまで英語での対応のみであったため、言日本語と英語訳の作業が必要でしたが、今回の日本語対応において、Amazon Q Developer を効率的に運用活用できるのが大きなメリットです。詳細は こちらをご参照ください。 8/1(金) Amazon CloudWatch が OpenSearch PPL と SQL の自然言語クエリ生成機能を開始 Amazon CloudWatch Logs Insights で、自然言語を使った OpenSearch PPL と SQL のクエリ生成機能が開始されました。これまでクエリ言語の知識が必要だったログ分析が、「1時間あたりのエラー数を教えて」といった日常的な英語で簡単に実行できるようになります。生成 AI がクエリを自動作成するため、専門知識がなくてもログから素早く洞察を得られます。東京リージョンなど 10 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 で EC2 インスタンスの強制終了がサポートされました Amazon EC2 で、停止処理中にフリーズしたインスタンスを強制終了できる force terminate 機能が追加されました。これまで OS の凍結やハードウェア問題で shutting-down 状態から動かなくなったインスタンスは AWS サポートに依頼する必要がありましたが、この機能により自分で強制終了できるようになります。まず通常のシャットダウンを試み、失敗した場合に強制終了を実行します。これにより vCPU クォータや Elastic IP アドレスなどのリソースをすぐに回収でき、開発作業の継続性が向上します。 AWS Directory Service が Managed Microsoft AD 向け Hybrid Edition を開始 AWS Directory Service で Managed Microsoft AD の Hybrid Edition が提供開始されました。これまでオンプレミスの Active Directory を AWS に移行するには複雑な作業が必要でしたが、新機能により既存の AD ドメインを AWS クラウドに簡単に拡張できるようになります。レプリケーションやメンテナンスは AWS が自動処理し、既存のアクセス制御やグループポリシーもそのまま利用可能です。EC2 や FSx、RDS などの AWS サービスとの統合も容易で、運用負荷を大幅に削減しながらクラウド移行を進められます。詳細は こちらの Blog 記事をご参照ください。 本当に暑い日が続いておりますので、水分補給を適宜行い、体調に気をつけてお過ごしください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。8月に入り、生成AI分野の進化がますます加速する日々が続いています。特に気になっているのは、AWSが本番環境での安全かつ柔軟なエージェント運用を実現する Amazon Bedrock AgentCore や、従来難しかった大規模ベクトルデータの長期保存( S3 )とリアルタイム検索( OpenSearch )を低コストで両立する Amazon S3 Vectors × OpenSearch Service の連携強化、AWS のAIエージェントSDK「Strands Agents」などです。生成AI活用に不可欠な基盤技術や開発環境の進化も続き、国内外のユーザーやパートナーによる導入事例もどんどん増えてきており2025年後半も「責任あるAI」「安心して使える生成AI」の実現に向けて、AWSがどのような取り組みや進化を続けているのか。生成AIの最新トレンドを、今号でもぜひキャッチアップしてください。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース ブログ記事「AWS サーバレスサービスで実現するラーメン山岡家のキッチンオペレーション効率化」 株式会社丸千代山岡家様が AWS Summit Japan 2025 での展示内容をもとに、従来の厨房タイマー装置が抱えていた視認性の問題や熟練職人への依存といった課題を、AWS Fargate 、 Amazon ElastiCache Serverless 、Amazon Bedrock などのサーバレスサービスを活用してどのように解決したかを詳しく解説しています。記事では、導入によりスタッフのスキル習得期間が 500 日から 350 日に短縮され、提供時間も平均 30 秒削減されるなど、具体的な成果を示しながら、外食産業におけるデジタルトランスフォーメーションの実践例として紹介しました。さらに、Amazon Bedrock を活用した生成AI による調理順序の最適化など、より高度な機能の開発も進められています。 ブログ記事「SDV (ソフトウェア定義車両)向け AUTOSAR 開発を Amazon Q Developer で加速」 このブログでは、Amazon Q Developer が AUTOSAR (AUTomotive Open System ARchitecture: 車載ソフトウェア開発の国際標準規格) 開発をどのように効率化できるかについて説明しています。SDV (ソフトウェア定義車両) 向けの開発において、Amazon Q Developer を開発者のコーディング作業を支援する強力なAIツールとして紹介しています。具体的には、LED制御やCANメッセージ送信などの一般的な車載ソフトウェア開発のユースケースで、コードの自動生成やユニットテストの作成を効率化できます。開発者の報告によると、初期開発が25%速くなり、生産性が最大40%向上したとのことです。 ブログ記事「株式会社 BTM 様の AWS 生成 AI 活用事例：Amazon Bedrock と Strands Agents を活用したシステム調査の自動化により、調査時間を大幅短縮し運用業務の効率化を実現」 株式会社BTM様が Amazon Bedrock とオープンソース AI エージェント SDK である Strands Agents を活用してシステム調査を自動化し、業務効率を大幅に改善した事例を紹介します。複数システムの管理における調査業務や関係者間のコミュニケーションに課題を抱えていたBTM様は、生成AIと MCP（Model Context Protocol）を組み合わせたAIエージェントシステムを構築しました。このシステムでは、Slackをユーザーインターフェースとして活用し、Amazon Bedrock の Claude 4.0 Sonnet を基盤モデルとして採用し、その結果、従来半日かかっていたシステム調査時間を最短10分に短縮し、PMのトラブルシュート工数を95%削減することに成功しました。さらに、開発工数も90%削減するなど、業務効率化を実現しています。 ブログ記事「[開催報告]AWS Summit Japan 2025 生成AIエージェントハッカソン」 6月25日～26日に開催された AWS Summit Japan 2025 において「使いたおして『○○』を実現するAIエージェント爆誕祭」をテーマに、AIエージェントを徹底的に活用することで人間固有の価値や目的を明確にすることを目指したハッカソンが開催されました。全国から14チームが予選に参加し、最終的に6チームが決勝に進出しました。ほぼ全てのチームが開発に Coding Agent を活用し、短期間にも関わらず商用レベルの完成度の高いソリューションを実現していました。最優秀賞を受賞したWhiteBoxお酒同好会の「KanpAI」をはじめ、各チームが Bedrock、Lambda、Connect、RDS 等のAWSサービスを効果的に組み合わせた実装を行い、AIエージェント時代の新しい可能性を示しました。このハッカソンは、AIが開発を支援する「AIがAIを作る」時代の到来を明確に示す重要なイベントとなりました。 サービスアップデート Amazon Bedrock Data AutomationがDOC/DOCXとH.265ファイルをサポート Amazon Bedrock Data Automation (BDA) の機能が大幅に拡張され、DOC/DOCXファイルとH.265形式の動画ファイルの処理に対応するようになりました。これまではWordファイルを処理する際、一旦PDFに変換する必要がありましたが、DOC/DOCX対応により直接処理が可能となり、テキスト抽出や分析のワークフローが効率化されます。また、高圧縮・高画質なH.265形式の動画ファイルへの対応により、より効率的な動画分析が実現可能になりました。これらの新機能は、フランクフルト、ロンドン、アイルランド、ムンバイ、シドニー、米国西部（オレゴン）、米国東部（バージニア北部）の7つのリージョンで利用できます。 Amazon Bedrock が米国西部 (北カリフォルニア) リージョンで利用可能に Amazon Bedrock が、米国西部 (北カリフォルニア) リージョンで利用可能となりました。Amazon Bedrockは、1つのAPIで主要なAI企業が提供する高性能な大規模言語モデルなどを利用できる、フルマネージドサービスです。セキュリティ、プライバシー保護、責任あるAIの概念が組み込まれており、生成AIアプリケーション開発に必要な機能を幅広く提供します。 Fractional GPU搭載のAmazon EC2 G6fインスタンスが一般提供開始 NVIDIA L4 Tensor Core GPUを採用した新しいGPUインスタンス「G6f」を発表しました。最大の特徴は、GPU partitioning によりGPUリソースを8分の1単位で細かく分割して利用できる点です。これにより、フルGPUの性能が不要で余分な費用が発生していた機械学習やグラフィックス処理において、必要な分だけのリソースを確保でき、コストを最適化できます。北米、ヨーロッパ、アジアパシフィックなど、東京を含めた主要なリージョンで利用可能となっています。 Amazon Q Developer CLIがカスタムエージェントを発表 Amazon Q Developer CLIに新たにカスタムエージェント機能が追加されました。この機能により、コードレビューやトラブルシューティングなどの特定のタスクに特化したCLIエージェントをカスタマイズすることが可能になりました。開発者は設定ファイルを通じて、エージェントが使用できるツールやプロンプト、必要なコンテキストを定義できます。さらに、ファイルシステムへのアクセス権限の細かな制御や、静的・動的なコンテキストの指定も可能です。このカスタムエージェントはプロジェクト固有で設定でき、チームメンバー間で共有することも、個人の開発タスク全般で使用することも可能です。 Amazon Q Developerが多言語対応を拡大 Amazon Q Developerの言語対応を大幅に拡充しました。AWS マネジメントコンソール、AWS Console モバイルアプリ、さらにTeamsやSlackといった主要なチャットツールで、フランス語、ドイツ語、イタリア語、日本語、韓国語、中国語、スペイン語、ポルトガル語など、多数の言語に対応するようになりました。使い方は簡単で、ユーザーが希望する言語で Q Developer に問い合わせるだけでシステムが自動的に使用言語を認識し、同じ言語で応答します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、麻辣醤にハマっています。

本記事は米国時間 8 月 1 日に公開された「 Kiro Pricing Update + Waitlist Invites Coming Soon 」を翻訳したものです。Kiro の最新情報は、 https://kiro.dev/  をご覧ください。 Kiro への素晴らしい関心に感謝いたします！コミュニティからのフィードバックは素晴らしく、一つのことが明確になりました。皆さんはもっと多くを望んでいます。ウェイトリストに登録しながらも待機している方々は自分自身で Kiro をテストする機会を望み、すでに Kiro を使用している方々はアクセス量をコントロールする方法をもっと求めています。そこで、この核心に迫る 2 つの更新をコミュニティに向けてお知らせします。 ウェイトリストへの招待を開始します ：来週 (8/4) から、ウェイトリストに登録された開発者の方々をオンボーディングし、より多くの方々に Kiro を直接体験する機会を提供します。 新料金プランが登場します ：初期プレビューユーザーのワークフローとニーズから学んだことに基づき、今月後半に 料金プラン を導入し、追加容量にお支払いいただくか、Kiro を無料で引き続き使用するかの選択肢を提供します。 ウェイトリストの最新情報 お待たせいたしました。間もなく招待の送信を開始いたします！来週 (8/4) から、ウェイトリストに登録された方々にサインアップコードをメールで送信します。これらのコードを使用してオンボーディングし、Kiro が提供するすべてを体験できます。今月後半に料金プランが開始されると、自動的に 2 週間の無料トライアルにアクセスでき、料金プランを決定する前に、Kiro が開発ワークフローにどのように適合するかを十分に探索する時間があります。ウェイトリストはかなり迅速に進む予定です。 料金の最新情報 プレビュー期間は、実際の使用パターンをより理解するのに役立ち、Kiro のコアアクションである Spec と Vibe に関する開発者のニーズに合わせて料金体系を構築することになりました。開発者が Spec で素晴らしいことを達成するのを見てきました。 開発者は、通常多くの Vibe 対話を必要とするタスクを効率的に完了できるようになりました。これは Kiro の重要な価値 – 開発者が要件と設計仕様を生成し、それらをタスクごとに実行して本番環境対応のコードを作成する、仕様駆動型の開発アプローチ – を示します。開発者が Kiro で構築する 2 つ目の方法は Vibe を通じてです。これは、AI エージェントとの構築に馴染みのある会話型アプローチを好む方々のためのエージェント型チャット体験です。 私たちの料金プランは、Kiro との旅のあらゆる段階で開発者とチームをサポートするように設計されています。AI の開発を始めたばかりの方も、複雑なアプリケーションを構築する大規模チームをリードしている方も、私たちの料金モデルは無料トライアルからエンタープライズレベルの使用まで、あなたの成長をサポートするように設計されています。この新しい構造は、開発者の働き方を観察することで形作られ、成長するコミュニティにとってより直感的な体験を創出しています。 主なポイントは以下の通りです。 2 週間の無料トライアル ：すべての新規ユーザーは、Vibe（50リクエスト）と Spec（100リクエスト）の両方にアクセスできる 2 週間のトライアルを受けられ、誰もが Kiro の完全な機能セットを体験できます。 新しい階層構造 ：Free、Pro（月額 20 ドル）、Pro+（月額 40 ドル）、Power（月額 200 ドル）プランを含む、より柔軟な階層システムを導入し、開発者がニーズに最も適した階層を選択できるようにします。 Vibe と Spec リクエストの個別割り当て ：開発者が Kiro の Vibe と Spec 機能を使用する異なる方法を認識し、有料プランでそれぞれに個別の割り当てを提供します。 恒久的な無料ティア ：月間 50 回の Vibe リクエストにアクセスできる無料プランを維持し、開発者がコスト障壁なしで Kiro の機能を引き続き探索できるようにします。 柔軟な超過使用への対応 ：すべての有料プランで、Vibe リクエスト 1 回あたり 0.04 ドル、Spec リクエスト 1 回あたり 0.20 ドルの追加使用が可能で、Kiro が最も必要なときに壁にぶつからないことを保証します。 Vibe リクエストには、コードの説明やバグ修正などのチャットベースの対話が含まれ、Specリクエストには、Kiro の構造化された開発ワークフロー内でのタスクの実行が含まれます。使用パターンを継続的に評価し、コミュニティにより良いサービスを提供するために制限を調整する場合がありますが、常にユーザーのニーズを優先します。 既存プレビューユーザーの皆様へ ローンチ以来、Kiro の無料プレビューに参加してくださった皆様に感謝します。GitHub や Discord でのフィードバックは、料金モデルだけでなく、Kiro の体験全体を形作る上で非常に貴重でした。この数週間、Kiro でのビルディングを楽しんでいただけたことを願っています。 今後数週間は引き続きKiroを無料で使用できます。今月後半に容量を増やすために有料プランを選択するか、無料プランを継続するかを選択する必要があります。これらのプランは、コミュニティから見られた使用パターンとフィードバックに直接基づいて設計されているため、あなたの作業方法に合った選択肢があると確信しています。 今後の展望 ウェイトリスト からユーザーのオンボーディングを開始するにあたり、すべての人にとってスムーズな移行を約束します。今後数日間で、Kiro から最大限の価値を引き出すためのオフィスアワーを開催します。(訳註 : 日本での開催は未定です) 正式リリース日の詳細については続報をお待ちください。移行に関する質問については、 料金情報と FAQ を確認するか、 Discord でコミュニティディスカッションに参加してください。皆さんが何を構築するのか楽しみにしています！

7 月 31 日、Amazon DocumentDB サーバーレスの一般提供についてお知らせします。これは Amazon DocumentDB (MongoDB 互換) の新しい設定であり、アプリケーションの需要に基づいてコンピューティングとメモリを自動的にスケールします。Amazon DocumentDB サーバーレスは、事前の契約や追加コストなしでデータベース管理を簡素化し、ピークキャパシティのプロビジョニングと比較して最大 90% のコスト削減を実現します。 Amazon DocumentDB サーバーレスでは、リードレプリカ、 パフォーマンスインサイト 、I/O 最適化、およびその他の Amazon Web Services (AWS) のサービスとの統合など、Amazon DocumentDB と同じ MongoDB 互換 API および機能を使用できます。 Amazon DocumentDB サーバーレスでは、約 2 ギビバイト (GiB) のメモリ、対応する CPU、およびネットワークの組み合わせである DocumentDB キャパシティユニット (DCU) で測定される新しいデータベース設定が導入されました。アプリケーションで実行されるデータベース操作から発生する CPU、メモリ、ネットワークなどのリソースの使用状況を継続的に追跡します。 Amazon DocumentDB サーバーレスは、データベースの可用性を損なうことなく、需要に応じて DCU を自動的にスケールアップまたはスケールダウンします。既存のクラスターでのプロビジョニンドインスタンスからサーバーレスへの切り替えは、インスタンスタイプを追加または変更するのと同じくらい簡単です。この変更にはデータの移行は必要ありません。詳細については、「 Amazon DocumentDB サーバーレスの仕組み 」を参照してください。 Amazon DocumentDB サーバーレスの主なユースケースと利点には次のものがあります。 変動するワークロード – Amazon DocumentDB サーバーレスでは、定期的なプロモーションイベント、開発およびテスト環境、使用量が急速に増加する可能性がある新しいアプリケーションなど、突然のトラフィックの急増に対応できます。また、 Amazon DocumentDB の組み込みベクトル検索 および動的に呼び出されるエージェンティック AI ワークフローを処理するためのサーバーレス適応性の恩恵を受ける エージェンティック AI アプリケーションを構築することもできます。 マルチテナントワークロード – Amazon DocumentDB サーバーレスを使用して、データベースフリート全体で個々のデータベースキャパシティを管理できます。エンタープライズアプリケーションや Software as a Service (SaaS) ベンダーのマルチテナント環境で、数百または数千のデータベースを管理する必要はありません。 多目的ワークロード – オンライントランザクション処理 (OLTP) アプリケーションなど、クエリトラフィックが定期的に急増するワークロードでは、読み取りキャパシティと書き込みキャパシティのバランスを取ることができます。クラスター内の Amazon DocumentDB サーバーレスインスタンスのプロモーション階層を指定することで、リーダーインスタンスがライターインスタンスとは独立してスケールして追加の負荷を処理できるようにクラスターを設定できます。 安定したワークロードには、Amazon DocumentDB プロビジョンドインスタンスの方が適しています。事前定義された量のメモリ、CPU パワー、および I/O 帯域幅を提供するインスタンスクラスを選択できます。プロビジョンドインスタンスを使用するときにワークロードが変化した場合は、ライターとリーダーのインスタンスクラスを手動で変更する必要があります。オプションで、サーバーレスインスタンスを既存のプロビジョンド Amazon DocumentDB クラスターにいつでも追加できます。 Amazon DocumentDB サーバーレスの動作 Amazon DocumentDB サーバーレスの使用を開始するには、 Amazon DocumentDB コンソール にアクセスしてください。左のナビゲーションペインで、[ クラスター ] と [ 作成 ] を選択します。 「 Amazon DocumentDB クラスターの作成 」ページで、「 インスタンスベースのクラスタータイプ 」を選択し、「 サーバーレス インスタンス設定」を選択します。最小キャパシティと最大キャパシティの DCU を選択できます。Amazon DocumentDB サーバーレスは Amazon DocumentDB 5.0.0 以降でサポートされており、キャパシティ範囲は 0.5～256 DCU です。 監査やパフォーマンスインサイトなどの特徴量を使用する場合は、特徴量ごとに DCU を追加することを検討してください。詳細については、 Amazon DocumentDB サーバーレススケーリング設定 をご覧ください。 サーバーレスインスタンスを既存のプロビジョンドクラスターに追加するには、プロビジョンドクラスターを選択するときに [ アクション ] メニューの [ インスタンスの追加 ] を選択します。3.6 や 4.0 などの以前のバージョンのクラスターを使用する場合は、まずクラスターをサポートされているエンジンバージョン (5.0) にアップグレードする必要があります。 [ インスタンスの追加 ] ページの [ DB インスタンスクラス ] セクションで、作成する新しいサーバーレスインスタンスごとに [ サーバーレス ] を選択します。別のインスタンスを追加するには、[ インスタンスの追加 ] を選択し、必要な新しいインスタンス数に達するまでインスタンスを追加し続けます。[ 作成 ] を選択します。 フェイルオーバー操作 を実行して、DocumentDB サーバーレスインスタンスをクラスターライターにすることができます。また、 インスタンスのクラスを変更 するか、 Amazon DocumentDB インスタンスを削除 してそれらをクラスターから削除することで、残りのプロビジョンド Amazon DocumentDB インスタンスを DocumentDB サーバーレスインスタンスに変換できます。 これで、 AWS CloudShell を使用して Amazon DocumentDB クラスターに接続できるようになりました。[ クラスターに接続 ] を選択すると、AWS CloudShell ランコマンド 画面が表示されます。[ 新しい環境名 ] に一意の名前を入力し、[ 作成して実行 ] を選択します。 プロンプトが表示されたら、Amazon DocumentDB クラスターのパスワードを入力します。Amazon DocumentDB クラスターに正常に接続されました。いくつかのクエリを実行してドキュメントデータベースの使用に慣れることができます。 詳細については、AWS ドキュメントの「 Amazon DocumentDB サーバーレスを使用するクラスターの作成 」および「 Amazon DocumentDB サーバーレスの管理 」を参照してください。 今すぐご利用いただけます Amazon DocumentDB サーバーレス は、Amazon DocumentDB 5.0 以降で、新しいクラスターと既存のクラスターの両方で利用できるようになりました。DCU 使用量の 1 秒あたりの定額料金のみをお支払いいただきます。料金の詳細とリージョンでの可用性の詳細については、 Amazon DocumentDB の料金表ページ をご覧ください。 Amazon DocumentDB コンソール でこれらの新特徴量をお試しいただき、フィードバックを AWS re:Post for Amazon DocumentDB に送信するか、通常の AWS サポート担当者を通じて送信してください。 – Channy 原文は こちら です。

※ Part1 は こちらの記事 を御覧ください 2025 年 6 月 25 日・26 日に開催された AWS Summit Japan 2025 において、鉄道業界向けの 2 つのソリューションを展示いたしました。本記事では、展示ブースの内容と来場者の皆様からいただいたご意見をご報告いたします。 展示概要 今回の展示では、鉄道業界が直面する課題に対応する 2 つのアプローチをご紹介しました。 展示内容 生成 AI エージェントによる鉄道業界の業務改善　〜鉄道 AI エージェント 〜 複数の AI エージェント連携による部門横断型の業務支援 AI エージェントと MCP を用いた業務効率支援　〜 Strands Agents と MCP を組み合わせた効率的なリサーチ業務 〜 鉄道運行制御システムのクラウド活用に向けたアプローチ IEC 61508 をはじめとした国際規格に準拠しながら、クラウドの特性を活かした実装方法の解説 鉄道連動装置を例にした具体的な実装手法のご紹介 ※ Part1 は こちらの記事 を御覧ください、この記事では Part2 からご紹介します。 2. 鉄道運行制御システムのクラウド活用アプローチ 今年の AWS Summit Japan では、社会インフラの安全性確保とクラウド活用の両立というテーマについて、鉄道連動装置を例にした具体的な実装アプローチをご紹介させていただきました。鉄道関係者の皆様はもちろん、車両/重機製造業や通信事業者、公共研究機関のお客様など多くの方々にご来訪いただき、機能安全システムのクラウド実装への高い関心を実感いたしました。   本展示では、まず鉄道業界をはじめとする社会インフラ事業者が直面している課題について議論を行いました。設備の老朽化に伴う維持管理負担の増大、人口減少下での安全性維持、そして安全維持ノウハウの暗黙知化といった課題が、多くの事業者様に共通する喫緊の課題として浮かび上がっています。   これらの課題に対する解決策として、私たちは AWS クラウドを活用した新しいアプローチを提案いたしました。その中核となるのが、IEC 61508 をはじめとした国際規格で定められている安全性を電子装置で確保する「機能安全」の考え方を取り込み、これらの国際規格に準拠しながら、クラウドの特性を活かした実装方法について解説させていただきました。 鉄道の信号制御システムである連動装置での実装例では、3 つの重要な技術要素を組み合わせた構成をご紹介しました。第一に、異なるアベイラビリティゾーンへの論理処理機能の分散配置による空間的な冗長性の確保です。第二に、Intel、AMD、Graviton といった異なる CPU アーキテクチャの活用による設計の多様性の実現です。そして第三に、3 重系による論理演算と多数決処理による安全性確保の仕組みです。   また、IEC 61508 で要求される 16 フェーズの安全ライフサイクルについても、AWS サービスを活用した効率的な管理方法をご紹介しました。AWS Config による要件適合性の自動検証、Infrastructure as Code による構成管理の厳密化、AWS Fault Injection Simulator を用いた継続的な安全性検証など、具体的な実装方法について解説させていただきました。 機能安全分野での AWS クラウド実績としては、 Swift Navigation様による事例 を取り上げ、ISO 26262 認証取得において AWS クラウドを活用した具体的な成功例をお示ししました。同社は、AWS の複数のアベイラビリティゾーンを活用したフォールトトレランス設計により安全性要求に応えることに成功しています。   本展示を通じて、AWS クラウド活用による運用コストの最適化、保守業務の効率化、安全技術ノウハウの体系化といった具体的なメリットをご理解いただけたのではないかと考えています。特に、従来はオンプレミス環境でしか実現できないと考えられていた高い安全性要件に対して、クラウドでも適切な設計とアプローチにより対応しうることをご説明いたしました。 私たちは、今回ご紹介した知見が他の産業分野にも波及し、社会インフラ全体のデジタルトランスフォーメーションの加速に貢献できると考えており、この分野における業界関係者の皆様からの忌憚ないご意見をいただければと考えております。 当日来訪いただいた方はもちろん、この記事でご興味を持っていただいた皆様と検討の機会がありましたら、いつでもご遠慮なく連絡いただけますと幸いです。 まとめ AWS Summit Japan 2025 での鉄道展示ブースには、2 日間で多くの皆様にご来場いただきました。マルチ AI システムは実用性の高いソリューションとして評価をいただき、鉄道運行制御システムのクラウド活用アプローチは体系的なアプローチとして関心をお寄せいただきました。 今回の展示を通じて、鉄道業界のデジタル変革に向けた具体的な道筋を示すことができました。今後も皆様のご意見を参考に、より実用的で安全性の高いソリューションの開発を進めてまいります。

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 を使用して、適切なタイミングで複数のチャネルを通じて適切な顧客と動的にエンゲージしましょう。詳細については、 お問い合わせ ください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。