本記事は 2025 年 9 月 8 日に公開された “ Introducing an Interactive Code Review Experience with Amazon Q Developer in GitHub ” を翻訳したものです。 コードレビューはソフトウェア開発において最も価値ある工程の一つです。品質の確保、一貫性の維持、エンジニアとしての成長促進に役立ちます。しかし同時に、ソフトウェア開発ライフサイクルの中で最も時間を要する工程でもあります。 よく目の当たりにする事例として、開発者がプルリクエスト (PR) を開き、自動出力されたコメントや同僚からのコメントを確認した後、変更が提案された理由を理解するためだけに、ドキュメントや Slack のスレッド、過去のコードを検索しなければならないというものがあります。この不足しているコンテキストを探す作業は摩擦を生み、チームの開発速度を低下させ、やり取りの回数を増やし、優れた製品を構築するという重要な目的の障壁となります。 Amazon Q Developer for GitHub の初期プレビュー では、開発者は新機能開発や、自動化されたコードレビュー、一般的なモダナイゼーションタスクにおいて、 Amazon Q Developer を GitHub の Issue と PR にまたがって利用していました。これにより作業は GitHub 内で完結し、作業工数が削減されました。新規または再オープンされた PR に対する自動レビューは迅速に検出事項を提示しましたが、開発者は依然としてより多くのコンテキストと PR 内での緊密な連携を求めていました。 本日、PR 向けの対話型コードレビュー機能を導入します。 /q コマンドで Amazon Q Developer に検出結果に関する質問ができ、スレッド化された検出結果の簡潔な要約を確認し、GitHub を離れることなく提案された変更を適用できます。Amazon Q Developer によるコードレビューは以前より迅速に完了するため、待ち時間が短縮されレビューサイクルが短縮され、チームはより早くマージして開発に集中できます。 新機能とその意義 プルリクエスト内でのインタラクティブな会話 : /q でコメントするとインラインで回答を得られます。また、 Amazon Q Developer にコード変更を提案させ、PR 内で変更を適用できます。 コメント例: /q explain this finding or /q propose a change that replaces class toggles with a data attribute for state. ※訳者注: /q この変更検出の内容を説明 または /q 状態を示すクラスをデータ属性に切り替える変更を提案 スレッド化された検出結果付きコードレビュー要約 : 各コードレビューは簡潔な要約で始まり、変更の検出結果がスレッド形式で表示されます。これにより更新箇所の追跡が容易になり、作業の煩わしさが削減されます。 通知の明確化による高速化： Amazon Q Developer の分析が高速化されただけでなく、通知を整理して見やすくします。これにより待機時間が短縮され、レビューサイクルが短縮されます。新しい PR を作成する際、 Amazon Q Developer コンソール上で GitHub コードレビュー機能が有効になっている場合、自動的にコードレビューが開始されます。以降のコミットでは自動レビューはトリガーされません。新しい分析を実行するには、PR に対して /q review とコメントします。 Amazon Q Developer for GitHub の開始方法 Amazon Q Developer for GitHub を開始するには、GitHub の Organization、もしくはリポジトリに Amazon Q Developer for GitHub アプリをインストールします。このアプリは GitHub Marketplace から入手可能で、プレビュー期間中は AWS アカウントなしで利用できます。インストール時に GitHub の Organization 内のすべてのリポジトリへのアクセスを許可するか、選択したリポジトリのみに制限するかを選択します。Amazon Q Developer コンソールでアプリのインストールを登録すると、無料利用枠を増やすことができます。 インストール、権限、設定オプションの詳細については、 Amazon Q Developer for GitHub のドキュメント を参照してください。アプリのインストールが完了すると、自動的にAmazon Q Developer を使用して PR をレビューできるようになります。 プルリクエストにおけるAmazon Q Developer利用の流れ Amazon Q Developer で構築したシンプルなカードゲームを題材として、新しいインタラクティブなコードレビュー体験の流れをご紹介します。 PR の新規作成 : この例では、最初にフィーチャーブランチを作成し「demo」と命名しました。次に、JavaScript と HTML で構成されるカードゲームアプリに tailwind.css ファイルを追加し、ブランチをプッシュした後、レビュー用の PR を作成します。 Amazon Q Developerによるコードの自動レビュー : Amazon Q Developer がコードの品質、潜在的な問題、ベストプラクティスへの準拠状況を分析します。分析結果として簡潔な要約が最上部に表示され、変更の検知箇所が下部にスレッド形式で表示されました。これにより、全体像と詳細を 1 か所で把握できます。 要約と検知箇所を元にコードレビューを実施 : Amazon Q Developer が出力した要約と関連する調査結果を確認し、どの変更のレビューに最初に取り組むか判断します。変更の根拠と具体的な対象行が示されるため、ファイルをくまなく探す必要なく、対処すべき箇所が明確になっています。 /q で説明を求める : 変更の検知箇所の一つについて、カードゲームにおけるカードの状態を保持するために、プロパティを使用することが提案されました。そこで Amazon Q Developer に詳細を確認しました。具体的な文脈と指針を迅速に提供してくれたため、やり取りが削減され、レビューの質が向上しました。 (必要に応じて) 対話を続ける : Amazon Q Developer からの提案に対して、別のアプローチを希望すると返信したところ、Amazon Q Developer はすぐにこの PR に対して適用できる実装を応答してくれます。 修正を適用 : 実装提案を確認した後、「Commit suggestion」をクリックし、PR ブランチに新しいコミットを作成しました。この際、作成者のユーザー名は私になります。 レビューの再実行 : 今回は必要ありませんでしたが、追加の変更をプッシュした場合、新しいトップレベルコメントとして /q review を投稿することで、Amazon Q Developer によるレビューを再実行できます。Amazon Q Developer がレビューを実行し、新たに検出した変更内容をポストします。 最終的にコードレビューが完了し、問題ないことを確認したため、PR をマージしました。新しい対話型コードレビュー体験により、変更提案の背景にある「理由」が明確になり、待ち時間とレビューサイクルが短縮されました。 まとめ Amazon Q Developer for GitHub は現在プレビュー版として利用可能です。個人開発者でも大規模エンジニアリングチームの一員でも、このアップデートにより、少ないサイクルでクリーンなコードをデリバリできるようになり、コードレビューが面倒なものではなく楽しい工程になります。 ぜひ、次の PR で試してみてください。 /q と入力し、質問を投げかけ、 対話型のレビュー がワークフローをいかにスマートに変えるかを確認してみてください。 翻訳はソリューションアーキテクトの富永が担当しました。

本記事は、2025 年 8 月 8 日に公開された The Amazon SageMaker lakehouse architecture now automates optimization configuration of Apache Iceberg tables on Amazon S3 を翻訳したものです。翻訳は Solutions Architect の 松岡勝也 が担当しました。 組織が Amazon Web Services (AWS) 上のデータレイクアーキテクチャに Apache Iceberg テーブルを採用するようになるにつれ、これらのテーブルのメンテナンスが長期的な成功の鍵となります。適切なメンテナンスがないと、Iceberg テーブルはクエリパフォーマンスの低下、削除すべき古いデータの不要な保持、ストレージコスト効率の低下など、いくつかの課題に直面する可能性があります。これらの問題は、データレイクの効果とコスト効率に大きな影響を与える可能性があります。定期的なテーブルメンテナンス作業により、本番ワークロードの Iceberg テーブルの高いパフォーマンス、データ保持ポリシーの遵守、コスト効率を確保することができます。Iceberg テーブルを大規模に管理できるよう、 AWS Glue では以下の Iceberg テーブルメンテナンス作業を自動化しました： sort や z-order での コンパクション 、そして スナップショットの有効期限設定と孤立データの管理 です。この機能のリリース後、多くのお客様が運用負荷を軽減するために AWS Glue Data Catalog を通じて自動テーブル最適化を有効にしています。 Amazon SageMaker lakehouse アーキテクチャでは、カタログレベルの設定により、Amazon S3 に保存された Iceberg テーブルの最適化 が自動化されるようになり、Iceberg テーブルのストレージを最適化してクエリのパフォーマンスを向上させます。これまでは、AWS Glue Data Catalog の Iceberg テーブルを最適化するには、各テーブルの設定を個別に更新する必要がありました。現在は、Data Catalog の一度の設定で新しい Iceberg テーブルの自動最適化を有効にできます。有効化すると、新規テーブルまたは更新されたテーブルに対して、Data Catalog は小さなファイルの圧縮、スナップショットの削除、不要な参照されていないファイルの削除を行い、継続的にテーブルを最適化します。 このポストでは、カタログレベルのテーブル最適化設定を有効にするための一連のフローをご紹介します。 前提条件 新しいカタログレベルのテーブル最適化を使用するには、以下の前提条件が必要です: アクティブな AWS アカウント。 カタログレベルでテーブル最適化を設定するデータレイク管理者。データレイク管理者を作成するには、 AWS Lake Formation のセットアップ を参照してください。 Iceberg テーブルにアクセスするためのテーブル最適化用の AWS Identity and Access Management (IAM) ロール。手順については、 カタログレベルのテーブル最適化の前提条件 を参照してください。 カタログレベルでのテーブル最適化の有効化 データレイク管理者は、 AWS Lake Formation コンソールでカタログレベルのテーブル最適化を有効にできます。以下の手順を実行してください： AWS Lake Formation コンソールで、ナビゲーションペインの Catalogs を選択します。 カタログレベルのテーブル最適化を有効にするカタログを選択します。 次のスクリーンショットのように、 Table optimizations タブを選択し、 Table optimizations の Edit を選択します。 Optimization options で、次のスクリーンショットに示すように、 Compaction 、 Snapshot retention 、 Orphan file deletion を選択します。 IAM ロールを選択します。権限については テーブル最適化の前提条件 を参照してください。 Grant required permissions  を選択します。 I acknowledge that expired data will be deleted as part of the optimizers を選択します。 カタログレベルでテーブルの最適化を有効にすると、次のスクリーンショットのように、AWS Lake Formation コンソールに設定が表示されます。 カタログに登録された Iceberg テーブルを選択すると、次のスクリーンショットに示すように、 Configuration source に catalog と表示されることから、テーブルの最適化設定がテーブルビューから継承されていることを確認できます。 テーブルの最適化履歴は、テーブルビューに表示されます。 以下の結果は、テーブルの最適化によるコンパクション処理の 1 つを示しています。 すべてのデータベースと Iceberg テーブルに対するカタログレベルのテーブル最適化が有効になりました。 カタログレベルとテーブルレベルでのテーブル最適化設定のカスタマイズ カタログレベルの最適化は、カタログ内のすべてのデータベースと Iceberg テーブルに共通の設定を適用しますが、特定の Iceberg テーブルに対して異なる戦略を適用したい場合があります。 AWS Glue Data Catalog を使用して、特定のテーブルの特性とアクセスパターンに基づいて、カタログレベルとテーブルレベルの両方の最適化を有効にできます。 例えば、汎用的な Iceberg テーブル向けに binpack 戦略を使用したカタログレベルのコンパクション設定に加えて、タイムスタンプカラムに対する範囲クエリが頻繁に実行されるテーブルには、テーブルレベルでソート戦略を適用できます。 このセクションでは、実践的なシナリオを通じて、カタログレベルとテーブル固有の最適化の設定方法を説明します。 頻繁な書き込み操作が行われるリアルタイム分析テーブルを想像してください。このテーブルでは、メタデータの更新が頻繁に行われるため、より多くの孤立ファイルが生成されます。 また、ユーザーは特定のカラムをフィルタリングして一部のデータを対象とするクエリを実行するため、sort 戦略が望ましいものとなります。 以下のステップを実行してください： AWS Lake Formation コンソールでテーブルレベルの最適化を設定するために、先ほどと同じカタログ内の別の Iceberg テーブルを選択します。なお、このテーブルにはカタログレベルのテーブル最適化が設定されています。 次のスクリーンショットに示すように、 Optimization configuration で Edit を選択します。 Optimization options で、 Compaction 、 Snapshot retention 、 Orphan file deletion を選択します。 Optimization configuration で、 Customize settings を選択します。 同じ IAM ロールを選択します。 Compaction configuration で、次のスクリーンショットのように Sort を選択します。また、 Minimum input files に 80 ファイルを設定します。これはコンパクションをトリガーするファイル数の閾値です。 Sort を設定するには、Iceberg テーブルでソート順を定義する必要があります。ソート順は ALTER TABLE db.tbl WRITE ORDERED BY のような Spark SQL で定義できます。 Snapshot retention configuration と Snapshot deletion run rate で、 Specify a custom value in hours を選択します。次のスクリーンショットに示すように、2 つの削除ジョブの実行間隔を 12 時間に設定します。 Orphan file deletion configuration で、 Files under the provided Table Location with a creation time older than this number of days will be deleted if they are no longer referenced by the Apache Iceberg Table metadata を 1 日に設定します。これにより、作成日数がこの値より古いファイルが Apache Iceberg Tableのメタデータで参照されなくなると削除されます。 Grant required permissions を選択します。 I acknowledge that expired data will be deleted as part of the optimizers を選択します。 Save を選択します。 AWS Lake Formation コンソールの Table optimization タブに、テーブルオプティマイザーのカスタム設定が表示されます。 Compaction では、 Compaction strategy が sort に設定され、 Minimum input files は 80 files に設定されています。 Snapshot retention と Snapshot deletion run rate が 12 hours に設定されています。  Orphan file deletion では Orphan files will be deleted after が 1 days に設定されています。これらは以下のスクリーンショットに示されています。 以下のスクリーンショットに示すように、カタログレベルの戦略が binpack に設定されていても、コンパクション履歴ではテーブルレベルのコンパクション戦略として sort が表示されます。 このシナリオでは、カタログレベルの最適化と共にテーブルレベルの最適化が設定されています。 テーブルレベルとカタログレベルの最適化を組み合わせることで、Iceberg テーブルのデータ削除とコンパクション処理をより柔軟に管理できます。 まとめ この投稿では、AWS Glue Data Catalog のカタログレベルのテーブル最適化機能を使用して、Amazon SageMaker Lakehouse アーキテクチャで Iceberg テーブルを有効化し管理する方法を説明しました。 この機能強化により、単一の設定ですべてのテーブルに対して自動メンテナンス操作を有効にできるため、Iceberg テーブルの管理が大幅に簡素化されます。 個々のテーブルごとに最適化設定を構成する代わりに、データレイク全体をより効率的に維持できるようになり、運用オーバーヘッドを削減しながら一貫した最適化ポリシーを確保できます。 カタログレベルのテーブル最適化を有効にすることで、チームがデータの価値を最大限に活用することに集中できるようになり、整理された、高性能で費用対効果の高いデータレイクの維持を支援することをお勧めします。 この機能をお客様のユースケースで試していただき、コメントでフィードバックや質問をお寄せください。 AWS Glue Data Catalog テーブルオプティマイザーの詳細については、 Iceberg テーブルの最適化 をご覧ください。 謝辞：A special thanks to everyone who contributed to the development and launch of catalog level optimization: Siddharth Padmanabhan Ramanarayanan, Dhrithi Chidananda, Noella Jiang, Sangeet Lohariwala, Shyam Rathi, Anuj Jigneshkumar Vakil, and Jeremy Song. 著者について Tomohiro Tanaka  is a Senior Cloud Support Engineer at Amazon Web Services (AWS). He’s passionate about helping customers use Apache Iceberg for their data lakes on AWS. In his free time, he enjoys a coffee break with his colleagues and making coffee at home. Noritaka Sekiyama is a Principal Big Data Architect with AWS Analytics services. He’s responsible for building software artifacts to help customers. In his spare time, he enjoys cycling on his road bike. Sandeep Adwankar is a Senior Product Manager at Amazon Web Services (AWS). Based in the California Bay Area, he works with customers around the globe to translate business and technical requirements into products customers can use to improve how they manage, secure, and access data. Siddharth Padmanabhan Ramanarayanan is a Senior Software Engineer on the AWS Glue and AWS Lake Formation team, where he focuses on building scalable distributed systems for data analytics workloads. He is passionate about helping customers optimize their cloud infrastructure for performance and cost efficiency.

3 週間前、 ニュージーランドの新しい AWS リージョン (ap-southeast-6) に関する記事を公開したところ、これがニュージーランドを訪問するというすばらしい機会につながりました。ニュージーランドでは、熱意あふれるビルダーたちに会い、 Serverless and Platform Engineering Meetup 、 AWS Tools and Programming Meetup 、 AWS Cloud Clubs in Auckland 、 AWS Community Day New Zealand などのイベントでプレゼンテーションを行いました。 これらのプレゼンテーションのコンテンツを作成する過程で見つけたのが、 tangent mode と呼ばれる Amazon Q CLI の新機能です。この機能は、会話のメインスレッドを見失わずに関連する別のトピックを掘り下げることを可能にする会話チェックポイントを作成することで、私が集中し続ける方法を大きく変えてくれました。 この機能は実験モードになっており、 q settings chat.enableTangentMode true を使用して有効化できます。皆さんの役に立つかどうか、ぜひ試してみてください。 9 月 15 日週のリリース 次に、私が注目したリリースをいくつかご紹介します。 Amazon Bedrock の新しい基盤モデル – 一般提供が開始された Qwen モデルファミリー 、 DeepSeek-V3.1 、 Stability AI イメージサービス で Amazon Bedrock のモデルオプションが拡大されました。この拡大により、開発者はテキスト生成、コード生成、画像作成、複雑な問題解決といったタスクのための強力なマルチリンガルモデルと高度な画像生成機能にアクセスできるようになります。 Amazon VPC Reachability Analyzer が 7 つの新リージョンに拡大 – Network Access Analyzer 機能がさらに多くのリージョンで利用可能になりました。お客様は、より優れたグローバルカバレッジを活用して VPC インフラストラクチャ全体のネットワーク接続問題の分析とトラブルシューティングを行えるようになります。 Amazon Q Developer がリモート MCP サーバーをサポート – Amazon Q Developer がリモートモデルコンテキストプロトコル (MCP) サーバーに統合され、開発者はカスタムツールやデータソースを用いて AI アシスタント機能を拡張し、開発ワークフローを強化できるようになりました。 AWS Step Functions が新しいデータソースオプションで分散マップを強化 – 分散マップ向けの追加のデータソースオプションと改善されたオブザーバビリティ機能が Step Functions に導入され、より優れた監視機能とデバッグ機能で大規模な並列ワークロードの処理がさらに容易になりました。 Amazon Corretto 25 の一般提供開始 – Amazon が提供する無料の OpenJDK 25 マルチプラットフォームディストリビューションの一般提供が開始されました。Amazon Corretto 25 は、モダンアプリケーションを構築するための長期的なサポート、パフォーマンス強化、セキュリティ更新を Java 開発者に提供します。 Amazon SageMaker HyperPod が自動スケーリング機能を導入 – SageMaker HyperPod が自動スケーリング機能のサポートを開始しました。この機能により、機械学習チームはワークロードの要求に基づいてコンピューティングリソースを動的に調整して、分散トレーニングジョブのパフォーマンスとコストの両方を最適化できます。 その他のアップデート Gartner が 2025 年 Magic Quadrant で AWS を AI Code Assistants 部門のリーダーとして選出 – AWS が Gartner Magic Quadrant、AI Code Assistants 部門のリーダーとして選出されました。これは、AI 駆動の提案でより速く、よりセキュアにコードを記述するための開発者の支援における Amazon Q Developer の能力を明らかにしています。 AWS Cloud Club Captain 募集中  – 締め切りまで残り数日になりました! AWS Cloud Club Captain になって、ますます広がる学生クラウド愛好家ネットワークの一員になりましょう。 Captain になると、リーダーシップスキルを磨きながら、イベントを企画したり、クラウドコミュニティを構築したりできます。応募受付期間は 2025 年 9 月 1 日から 28 日までです。 近日開催予定の AWS イベント カレンダーをチェックして、近日開催予定の AWS イベント、 AWS re:Invent 、 AWS Summits にサインアップしましょう。 AWS AI Agent Global Hackathon – AWS の強力な生成 AI スタックを掘り下げて、目を見張るようなすばらしいソリューションを創り出すチャンスです。9 月 8 日から 10 月 20 日までの期間、AWS の AI サービススイートを使用して AI エージェントを作成し、45,000 USD を超える賞金と独占的な市場参入機会を賭けて競い合いましょう。 AWS Gen AI Loft – Loft 限定のセッションで AWS の AI 製品とサービスについて学び、業界をリードするエキスパートと交流して、投資家や同業者との貴重なネットワーキング機会を得ることができます。最寄りの都市でご登録ください。日程は、 メキシコシティ (9 月 30 日～10 月 2 日)、 パリ (10 月 7 日～21 日)、 ロンドン (10 月 13 日～21 日)、 テルアビブ (11 月 11 日～19 日) です。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 南アフリカ (9 月 20 日)、 ボリビア (9 月 20 日)、 ポルトガル (9 月 27 日)、 マニラ (10 月 4～5 日) です。 こちらで 今後開催されるすべての AWS イベント と AWS スタートアップイベント をご覧いただけます。 9 月 22 日週のニュースは以上です。9 月 29 日週の Weekly Roundup もお楽しみに! ハッピービルディング! – Donnie 原文は こちら です。

はじめに このブログでは、Amazon Bedrock AgentsをSAPインスタンスの管理支援に使用する方法を実演します。SAPControlが提供するWebサービスを呼び出すエージェントの機能を活用することで、ユーザーはSAP環境を効率的に管理できます。 SAPControl は、主にSAPプロセスの停止、開始、監視に使用されるSOAP Webサービスインターフェースです。しかし、これらの一般的な使用例を超えて、このサービスは管理シナリオで非常に価値のある幅広い機能を提供します。 このブログの前提条件： ユーザーは、SAPControlの使用とSAPシステムの管理に精通した経験豊富なSAP管理者または技術アーキテクトである。 sapstartsrvプロセスが実行されている、正常で稼働中のAWSホスト型SAPインスタンスへのアクセス。 AWS CLIがSAPサーバーにインストールされ、設定されている。 SAPサーバーのEC2セキュリティグループが、ポート5<nn>13へのアクセスを許可している（<nn>はSAPインスタンスのインスタンス番号）。 EC2インスタンスロールがS3バケットへのアクセス権を持っている。 Amazon Bedrockサービスと大規模言語モデル（例：Claude Haiku）へのアクセス。 AWS Lambdaサービスに関する知識とアクセス。 動作するPython開発環境。 Python開発スキル、仮想環境の使用、レイヤーなど。 プロセスフロー AWS Lambda関数（以下「Lambda」と呼ぶ）を作成して、SAPサーバー上のSAPControl SOAP Webサービスインターフェースを呼び出すWebプロキシとして機能させます。Lambda関数は<sid>admユーザーとそのパスワードを使用して認証します。セキュリティを強化するため、パスワードは関数にハードコードするのではなく、AWS Systems Managerの暗号化されたパラメータストアから取得します。 このブログで提供されるサンプル関数では、以下のタスクが可能になります： SAPパラメータの値を確認 指定されたS3バケットにログファイルを送信 SAPインスタンスを停止 SAPインスタンスを開始 SAPインスタンスのプロセス状態を確認 その後、Lambda関数は選択した大規模言語モデル（以下「LLM」と呼ぶ）によって駆動されるAmazon Bedrock Agentと統合されます。これにより、SAP管理者は自然言語を使用してSAPシステムと対話し、操作できるようになります。 図01 – ソリューションのアーキテクチャ概要 概要レベルステップ Lambda関数が使用するライブラリを含むPythonのLambdaレイヤーを作成 Webプロキシとして機能するLambda関数を作成 Bedrock Agentを作成し、作成したLambda関数を割り当て Systems Managerで<sid>admパスワードとインスタンス番号を保存する新しいパラメータを作成 このブログで紹介するソリューションでは、SAPインスタンスの状態を変更できることにご注意ください。ビジネスクリティカルなSAPシステムでこれを試行する前に、本番環境以外のサンドボックス環境で練習することを強く推奨します。このブログで説明されている手順に従ってミッションクリティカルなSAPシステムに影響が生じた場合、当方では責任を負いかねます。 詳細ステップ Lambdaレイヤーの作成 既存のPython開発環境で、 requirements.txt ファイルに基づいて必要なパッケージをインストールします。このブログでは、Python 3.11と互換性のあるパッケージを使用しました。正確なセットアップとバージョンによっては、requirements.txtファイルを変更する必要がある場合があることにご注意ください。パッケージがインストールされたら、/python/lib/python3.11/site-packagesのサブディレクトリと内容を含む、pythonディレクトリ全体をzipします。これがLambda関数のzipレイヤーファイルになります。レイヤーを作成するために、pyenvと仮想環境を使用して必要なパッケージをインストールすることを強く推奨します。 requirements.txtファイルを使用したパッケージのインストール方法や、Pythonレイヤーの操作方法について詳細が必要な場合は、このブログの最後にある付録をご確認ください。組織内のPython開発者に支援を求めることもできます。このブログはAmazon BedrockとSAP関連のステップに焦点を当てているため、Pythonの詳細ガイドは範囲外です。 レイヤーzipファイルが作成されたら、AWSアカウントにログインしてLambdaに移動し、レイヤーをロードします（図02参照）。 図02 – Lambdaレイヤーのロード zipレイヤーファイルには、zeepとboto3に必要なPythonライブラリが含まれています。この例では、レイヤーファイルは「sapcontrollayer311.zip」と呼ばれ、x86_64プロセッサアーキテクチャを使用しました。正確なセットアップでは異なる場合があるため、正確なセットアップに合わせて以下のスクリーンショットから若干逸脱する可能性があります（図03参照）。 図03 – Lambdaレイヤー設定 レイヤーが正常に追加されました。次に、Lambda関数のIAMロールを更新して、必要な権限を追加する必要があります。 Bedrock Agentの作成 次に、Amazon Bedrockサービスに移動し、新しいエージェントを作成します。 「Claude 3 Haiku」モデル（または前のステップで有効にしたモデル）を使用します。LLMの使用はトークンと呼ばれるものに基づいて計算される料金が発生することにご注意ください。料金の詳細については、以下の AWS公式ページ をご覧ください。 このブログの最後にある例のシナリオでは、Claude Haiku 3 LLMを使用した場合、合計で約$0.12のコストがかかります。実行する正確なリージョンと、入力および出力として使用する単語（トークン）の量によって、多少の変動がある可能性があります。 エージェントへの指示として以下のテキストを入力します。 「あなたは、プロファイルパラメータの確認、SAPシステムの停止と開始、SAPシステムログファイルのS3バケットへのロード、SAPシステムのプロセスリストと状態の確認など、様々なタスクでSAPシステム管理者を支援できる有用なエージェントです」 このプロンプトは非常に重要です。なぜなら、このテキストがAmazon Bedrockに特定のタスクでエージェントを使用すべきかどうかを指示するからです。 新しいアクショングループの追加 新しいアクショングループを追加するには、「追加」をクリックし、アクショングループを「ag-sapcontrolagent」と呼びます。 図17 – 新しいアクショングループの追加 「アクショングループの呼び出し」セクションで、「既存のLambda関数を選択」ラジオボタンをクリックし、先ほど作成したLambda関数の名前を選択します。 図18 – Lambda関数をアクショングループに関連付け アクショングループ関数の作成 「get-parameter-value」という最初の関数を作成します。 Lambdaコードの内容と一致する必要があるため、関数とパラメータの正確な名前を使用してください。 図19 – 関数get-parameter-valueの追加 詳細を手動で入力する代わりに、標準のテーブルビューから「JSONエディタ」ビューに切り替えた後（画面右上）、 get-parameter-value JSONをコピー＆ペーストするだけでも構いません。 次に、「アクショングループ関数を追加」ボタンをクリックして、さらに関数を追加します： 次のアクショングループ関数を「load-logfiles-to-s3」と名付けます： 図20 – 関数load-logfiles-to-s3の追加 再度、JSONエディタビューに切り替えた後、 load-logfiles-to-s3 JSONをコピー＆ペーストするだけでも構いません。 「stopinstance」という、インスタンスを停止する別の関数を作成しましょう。 図21 – 関数stopinstanceの追加 または、 stopinstance JSONをコピー＆ペーストしてください。 次に、「startinstance」という開始関数を作成します。 図22 – 関数startinstanceの追加 より簡単であれば、 startinstance JSONをここからコピー＆ペーストできます。 最後に、「get-process-status」関数を追加して、インスタンスの状態を確認できるようにします。 図23 – 関数get-process-statusの追加 get-process-status 関数のJSON形式も利用可能です。 次に「作成」をクリックします。「エージェントへの指示」フィールドが消去された場合は、再度入力してください（時々発生します）。その後、「保存して終了」をクリックします。 「準備」ボタンをクリックして、エージェントのテストバージョンを準備します。 図24 – エージェントの準備 この同じ画面で、エージェントARNをメモしてください。すぐに必要になります。 Lambda権限の修正 Lambda関数に戻ります。「設定」タブの「権限」ペインで、以下の「リソースベースポリシーステートメント」を追加します（「権限を追加」ボタンをクリック）。 図25 – Lambda権限の修正 Amazon Bedrock AgentがLambda関数を呼び出せるように追加します。 図26 – Amazon Bedrock AgentがLambda関数を呼び出せるように追加 「AWSサービス」を選択 サービス：「その他」 ステートメントID：自由テキスト（例：「sapcontrolbedrockagent」） プリンシパル：「bedrock.amazonaws.com」 ソースARN：Amazon Bedrock AgentのARNを確認できます（上記の数画面を参照） アクション：「lambda:InvokeFunction」 このポリシーにより、Amazon Bedrock AgentがLambda関数を呼び出すことができます。 Systems Manager Parameter Storeの維持 最後に維持すべきは、コードが<sid>admパスワードとインスタンス番号を検索するための情報です。パスワードをコードにハードコードするのは良い慣行ではありません。このため、AWS Systems Manager → Parameter Store内に以下の2つのエントリを作成します。 図27 – AWS Systems ManagerのParameter Store <sid>admのパスワードを保存するSecureStringパラメータを追加します。以下の例では、SAP SIDがMLDのため「mldadm」エントリになります。 図28 – SecureStringパラメータの追加 <sid>noパターンを使用してインスタンス番号パラメータも追加します。MLDシステムの場合、エントリは「mldno」になります – これは透過的なStringタイプにできます。 図29 – SAPシステム番号パラメータエントリ 必要な人とサービスのみがParameter Storeにアクセスできるようにしてください。 エージェントのテスト ついにエージェントとの会話をテストする時が来ました。Bedrock Agentサービスに戻り、新しく作成したエージェントを選択し、プロンプト領域を使用して以下のテストを実行します（図30は黄色でプロンプト領域を示しています）。 図30 – エージェントとの対話 エージェントにパラメータ値を尋ねる エージェントに以下を尋ねます： 「ホスト192.168.0.12上のMLD SAPシステムのSAPDBHOSTパラメータ値は何ですか？」 Bedrock Agentからの回答： 「ホスト192.168.0.12上のMLD SAPシステムのSAPDBHOSTパラメータ値は’sapvhana’です。」 図31 – エージェントとの会話例 同じプロンプトでより多くのパラメータ値を尋ねる 質問： 「ホスト192.168.0.12上のMLD SAPシステムのrdisp/wp_no_diaとSAPLOCALHOSTのパラメータ値は何ですか？」 回答： 「ホスト192.168.0.12上のMLD SAPシステムのパラメータ値は：– rdisp/wp_no_dia = 10 – SAPLOCALHOST = sapmldpas」 エージェントが2つの別々のパラメータの値を尋ねていることを理解し、関数を2回呼び出すことに注目してください。 SAPインスタンスの状態を確認する 以下を尋ねます： 「ホスト192.168.0.12上のSAPシステムMLDの状態は何ですか？」 SAPインスタンスの状態を確認する 以下を尋ねます： 「ホスト192.168.0.12上のSAPシステムMLDの状態は何ですか？」 回答は以下のようになるはずです： 「ホスト192.168.0.12上のSAPシステムMLDの状態は、ディスパッチャー、IGSウォッチドッグ、ゲートウェイ、ICMなどのすべての主要プロセスが実行されており、正常な状態です。」 図32 – エージェントとの会話のもう一つの例 インスタンスを停止する 次の例は実際にSAPインスタンスをシャットダウンすることにご注意ください。ビジネスへの影響なしに安全にシャットダウンできるシステムでのみ、この手順に従ってください！ 入力： 「ホスト192.168.0.12上のSAPシステムMLDを停止してください」 出力： 「ホスト192.168.0.12上のSAPシステムMLDが正常に停止されました。」 状態を再度確認する 図33の以下のプロンプトを参照して、状態を再度確認してください。 図33 – エージェントによって検出された停止システムの状態 システムを再度開始する エージェントにホスト情報を提供する必要がもうないことにご注意ください。エージェントは以前の会話からホストの詳細（192.168.0.12）を記憶しています（図34参照）。 入力プロンプト： 「SAPシステムMLDを開始してください」 図34 – エージェントによるSAPシステムの開始 状態を確認する SAPインスタンスの開始を可能にするために数分待った後、エージェントに状態について尋ねます。以下の図35を参照してください。 図35 – SAPインスタンスの状態確認 Amazon Bedrock Knowledge Baseの使用 この次の例では、Amazon Bedrock Knowledge Baseを使用してログファイルを保存し、ログ内のエラーを検索します。一時的な空のS3バケットを作成しましょう。この例では、バケット名「bedrockdemosaplogs」を使用しますが、まだ使用されていない限り任意のバケット名を作成できます（または、この目的のために既存のバケットがある場合は、それを単純に使用してください）。エージェントにログファイルをこのバケットにアップロードさせ、それをAmazon Bedrock Knowledge Base（以下「KB」と呼ぶ）として使用します。EC2インスタンスロールがS3バケットにアクセスするために必要な権限を持っていることを確認してください。 KBの力をより良く実演し、実際の状況をシミュレートするために、ログファイルにいくつかのエラーが発生するように、意図的にエラーを発生させます。 この例では、アプリケーションサーバーをシャットダウンせずに、その背後にあるクラスターを停止することで、メッセージサーバーをシャットダウンします。 図36 – エラーのテストケースを発生させる 次に、エージェントにログファイルをバケットにロードするよう指示します（s3://<bucketname>/形式を使用してください）。以下の図37を参照してください。 図37 – エージェントにログファイルをバケットにロードするよう指示 ログファイルが実際にバケットに表示されています。以下の図38を参照してください。 図38 – ログファイルがバケットに表示される 次に、Amazon Bedrock → Knowledge bases → Create knowledge baseに移動します。 図39 – Knowledge Baseの作成 名前を付けて、データのソースとしてS3を選択します。 図40 – データソースとしてS3を追加 S3バケットURI情報を提供します。 図41 – S3 URIの提供 ベクターストア用に「Titan Text Embeddings v2」モデルを選択します。 図42 – ベクターストアの選択 最後のサマリー画面で「ナレッジベースを作成」ボタンをクリックします。KBが作成されます。 KBが作成されたら、同期ジョブを実行します。 図43 – Knowledge Base同期 同期プロセスを監視します。 図44 – 同期プロセスは長時間かかる場合があります 同期プロセスは、ログの量によって長時間かかる場合があります。 次に、エージェントに戻り、設定を編集します。作成して同期したKBを追加します。 図45 – エージェントにKBを追加 エージェントに追加するKnowledge Baseを選択します。 エージェントへの指示は以下のようにしてください： 「ログファイル内のエラーを検索してください。.oldファイルは無視してください。同じ種類の最新のエラーメッセージを見つけるようにしてください。」（以下の図46を参照） 図46 – KBの選択 エージェントを保存し、再度準備します（準備を忘れないでください。そうしないとナレッジベースの追加が反映されません）。 Knowledge Baseを使用したエージェントのテスト エージェントにログからエラーを検出するかどうか尋ねます。図47の以下にプロンプト例があります。 図47 – エージェントがKnowledge Base内のログを分析 エージェントは、ログファイルで見つかったエラーメッセージを報告するはずです。 自分で試してみる Bedrockエージェントのトレースを分析し、会話をアクションにどのように分解するかを理解してみてください。 上記のサンプルコードにまだ含まれていないSAPcontrolの機能を取り上げて、実装してみてください（Lambdaにコードを追加し、アクショングループを作成するなど）。多くのコーディングスキルは必要ありません。関連するセクションをコピー＆ペーストして、新しい機能に合わせて修正してください。追加のタスクでエージェントの説明を更新することを忘れないでください。 Systems Manager Parameter Storeに情報を保持する代わりに、ランドスケープ情報全体をCSVファイルとしてS3バケットにロードし、ナレッジベースとしてエージェントに追加することを試してください。 パラメータチェックとSAP EarlyWatch Alertレポート（ナレッジベースとして追加）のクロスチェックを組み合わせて、特定のパラメータ値が推奨値から逸脱しているかどうかを判断します。 Systems Manager Parameter Storeに情報を保持する代わりに、ランドスケープ情報全体をCSVファイルとしてS3バケットにロードし、ナレッジベースとしてエージェントに追加することを試してください パラメータチェックとSAP EarlyWatch Alertレポート（ナレッジベースとして追加）のクロスチェックを組み合わせて、特定のパラメータ値が推奨値から逸脱しているかどうかを判断します。 コスト 既存のSAPシステムは、EC2、ストレージなどのコストが発生します – これは正確なSAPシステムによって変動します。 LLM料金はトークン（入力プロンプトと出力テキストの両方を含む）に基づいています。したがって、これも変動します。最新の料金については AWS公式ページ をご確認ください。 まとめ このブログ投稿では、Amazon Bedrock Agentsを活用してSAPインスタンスの開始と停止、ヘルス状態とパラメータ値の確認などの基本的なSAP運用タスクの実行を支援する使用例を実演しました。また、Knowledge Baseを利用して、膨大な量のログファイル内で関連するログエントリを見つける支援も行いました。 これらの例は、同様のアプローチを使用して実装できる潜在的な使用例のサンプルに過ぎません。同じ類推で探索・実装できる追加の使用例が数多くあります。 詳細を学ぶ Amazon Bedrockサービスについて詳しく読むには、この ページ をご覧ください。 PythonでLambda関数を構築する方法について詳しく学ぶには、この サイト をご確認ください。 この AWSドキュメント では、Pythonでレイヤーを操作する方法についてより多くのガイダンスを見つけることができます。 こちら と こちら にも有用なヒントがあります。 本ブログはパートナー SA 松本が翻訳しました。原文は こちら です。

この投稿は Anthropic の Gareth Jones と共同で執筆されています。 Anthropic の Claude 4 Sonnet モデルが Amazon Bedrock でローンチされ、基盤モデルの機能において大幅な進歩を遂げました。これに伴い、Anthropic の Claude 3.5 Sonnet (v1 および v2) の廃止スケジュールが発表されました。この進化により、本番 AI アプリケーションにとって二つの重要な考慮事項が発生しています。強化されたパフォーマンスを活用する機会と、廃止前に移行するという運用上の必要性です。組織は、モデル移行を AI 推論戦略の中核要素として扱う必要があります。なぜなら、実行が不適切だとサービス中断、パフォーマンス低下、コスト超過を招く可能性があるからです。 この投稿では、Amazon Bedrock で Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet &nbsp;に移行するための体系的なアプローチを提供します。主要なモデルの違いを検証し、重要な移行の考慮事項を強調し、この必要な移行を組織にとって測定可能な価値をもたらす戦略的優位性に変える実証済みのベストプラクティスを提供します。 モデルの違いの概要 モデルバージョン間の具体的な変更を理解することは、成功する移行を計画する最初のステップです。Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet への移行では、活用できる機能と動作の変化が取り入れられています。 コンテキストウィンドウの拡大 – Anthropic の Claude 4 Sonnet は、コンテキストウィンドウを 200 K トークンから 1 M トークン (ベータ版) に拡張します。これにより、アプリケーションは単一のプロンプトでコードベース、財務レポート、または長い法的文書を処理し、推論することができ、複雑なワークフローを簡素化します。 ネイティブ推論メカニズム – Anthropic の Claude 3.5 Sonnet モデルが思考の連鎖 (chain-of-thought、CoT) プロンプト技術に依存するのに対し、Claude 4 モデルは 拡張思考 や インターリーブ思考 などの組み込み で API 対応の推論機能を導入します。これらにより、モデルは回答前に思考するための専用の計算時間を得て、複雑な問題でのパフォーマンスを劇的に向上させます。 高度なツール使用 – Anthropic の Claude 4 Sonnet モデルは、ツール呼び出し機能を大幅にアップグレードします。 複数のツールを並列実行 し、ツール呼び出し間で拡張思考を使用できるため、古いモデルの順次ツール使用と比較して、より洗練された効率的なエージェントワークフローが可能になります。 モデルの違いについて詳しく知るには、 完全なモデル比較ガイド を参照してください。 移行を成功させるためには、いくつかの重要で技術的・戦略的な考慮事項が鍵となります。これらについては以下のセクションで説明します。これらの点を積極的に対処することで、リスクを最小化し、本番環境への道のりを加速できます。 前提条件 Anthropic の Claude 4 Sonnet モデルの使用を開始する前に、Amazon Bedrock でこれらのモデルへのアクセスを有効にする必要があります。手順については、 Amazon Bedrock 基盤モデルへのアクセスをリクエストする を参照してください。モデルアクセスリクエストを進める前に、モデルのエンドユーザーライセンス契約 (EULA) を確認し、同意することを確認してください。Claude 4 Sonnet が意図した AWS リージョンで利用可能であることを最初に確認することが重要です。なぜなら、モデルサポートは場所によって異なる可能性があるからです。サポートされているリージョンの最新リストについては、 Amazon Bedrock でのリージョン別モデルサポート を参照してください。さらに、モデル推論を実行する際に推論プロファイルを指定することで クロスリージョン推論 (CRIS) を使用でき、これによりスループットの向上とリソース可用性の最大化に役立ちます。サポートされているクロスリージョン推論プロファイルのリストについては、 推論プロファイルでサポートされているリージョンとモデル を参照してください。 API の変更とコードの更新 Amazon Bedrock においてモデルを移行する際は、モデル固有の InvokeModel API または統一された Converse API のいずれかを使用できます。 InvokeModel API を使用する場合、移行は簡単です。Anthropic の Messages API のリクエストボディ構造はバージョン間で一貫しているため、コード内の modelId を更新するだけで済みます： 旧モデル ID – 'anthropic.claude-3-5-sonnet-20240620-v1:0' または 'anthropic.claude-3-5-sonnet-20241022-v2:0' 新モデル ID – 'anthropic.claude-4-sonnet-20240514-v1:0' モデルに CRIS プロファイル を使用する場合は、ソースリージョンの 中から&nbsp; 正しい推論プロファイル ID 1 つを指定してください。例： 'us.anthropic.claude-sonnet-4-20250514-v1:0' この移行は、Converse API に切り替える絶好の機会です。Amazon Bedrock の言語モデルに対して標準化されたリクエスト/レスポンス形式を提供し、将来の異なるモデルやプロバイダーへの移行をはるかに簡単にします。以下のコードを参照してください： import boto3 bedrock_runtime = boto3.client(service_name='bedrock-runtime') # モデルを切り替えるためには、単にモデル ID を変更 response = bedrock_runtime.converse( modelId='us.anthropic.claude-sonnet-4-20250514-v1:0', messages=[{'role': 'user', 'content': [{'text': "Your prompt here"}]}], inferenceConfig={'maxTokens': 1024} ) print(response['output']['message']['content'][0]['text']) 以下はいくつかの重要な変更点です: 更新されたテキストエディタツール – エージェントワークフローで Anthropic の組み込みテキストエディタツールを使用している開発者は、ツール定義が更新されていることを認識する必要があります。ツールタイプは現在 text_editor_20250124 で、ツール名は現在 str_replace_based_edit_tool です。テキストエディタツールは Anthropic の Claude 4 で一般提供されているため、 anthropic_beta ヘッダーの computer-use-2024-10-22 は削除できます。このツールを使用するコードは、これらの変更を反映するように更新する必要があります。詳細については、 Anthropic 定義ツール を参照してください。 削除された undo_edit コマンド – undo_edit コマンドは Anthropic の Claude 4 Sonnet でサポートされなくなりました。このコマンドを使用するコードは削除する必要があります。 新しい refusal 停止理由 – モデルは現在 新しい拒否停止理由 を導入しています。この理由は、モデルが安全ポリシーによりコンテンツ生成を拒否した場合に返されます。モデルレスポンスを処理するアプリケーションロジックは、この新しい停止理由を認識し、管理するように更新して、予期しない動作やエラーを防ぐ必要があります。例えば、マルチターンインタラクションで refusal 停止理由を受け取った場合、拒否されたターンを削除または更新することで会話コンテキストをリセットする必要があります。 プロンプトエンジニアリングと動作の変化 既存のプロンプトが新しいモデルで完璧に動作すると仮定してはいけません。モデル固有のベストプラクティスの遵守が重要です。 最適な結果を得るために、Anthropic がリリースした Claude 4 プロンプトエンジニアリングベストプラクティス を参照してください。例えば、Anthropic の Claude モデルは、入力の異なる部分を明確に分離するために XML タグ (例： &lt;document&gt; 、 &lt;/document&gt; ) で構造化されたプロンプトで最高のパフォーマンスを発揮します。 Anthropic の Claude 4 Sonnet は、指示により正確に従うように設計されています。これは大きな利点ですが、明示的にプロンプトされない限り、Claude 3.5 Sonnet よりも冗長性や詳細性が低い可能性があります。AI のペルソナを定義するシステムプロンプトは調整が必要かもしれません。 新しい思考推論機能 Anthropic の Claude 4 Sonnet モデルに組み込まれている 拡張思考 は強力な機能です。新しいモデルの深い推論機能を解放するために、開発者は API 呼び出しに thinking キーワード引数を含めることで拡張思考を有効にできます。ただし、戦略的に使用することを確認してください。拡張思考は追加コストが発生します。なぜなら、推論トークンは標準モデル料金で出力トークンとして課金されるからです。 (表示される要約だけでなく) 完全な思考プロセスに対して課金され、設定した思考予算に応じてコストが拡大する可能性があります。 精度が最重要である深い多段階分析を必要とするタスク (例：複雑な科学的問題や高度なコーディングチャレンジ) では、拡張思考を有効にすることをお勧めします。 単純なクエリや遅延に敏感なアプリケーションでは、拡張思考を無効にすることをお勧めします。この機能はコスト (推論トークンが課金される) と応答時間の両方を増加させます。多くのタスクでは、適切に作成された CoT プロンプトが依然として最も効率的な選択です。 拡張思考を使用するには、 thinking 設定で additionalModelRequestFields パラメータを追加して Converse API 呼び出しを更新するだけです。 budget_tokens の値を設定することで、モデルが使用できる最大思考トークン数を指定できます。拡張思考では、 maxTokens は budget_tokens より大きくする必要があることに注意してください。以下のコードを参照してください： import boto3 bedrock_runtime = boto3.client(service_name='bedrock-runtime') # 拡張思考を有効にするために設定を追加 response = bedrock_runtime.converse( modelId='us.anthropic.claude-sonnet-4-20250514-v1:0', messages=[{'role': 'user', 'content': [{'text': "Your prompt here"}]}], inferenceConfig={'maxTokens': 2048}, additionalModelRequestFields={"thinking":{"type": "enabled", "budget_tokens": 1024}} ) reasoning_text = response['output']['message']['content'][0]['reasoningContent']['reasoningText']['text'] assistant_response = response['output']['message']['content'][1]['text'] 以下の表は、拡張思考の例とそれがどのように応答精度を向上させるかを示しています。Anthropic の Claude 3.5 Sonnet v2 と Claude 4 Sonnet (拡張思考有効) にサンプルのプロンプトを与えます： Alan、Bob、Colin、Dave、Emily が円形に立っています。Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。Alan の真右にいるのは誰ですか？ 表は 2 つのモデルからの応答を示しています。拡張思考により、モデルは問題を慎重に推論し、正しい答えに到達できます。 モデル 拡張思考 出力 正解/不正解 Claude 3.5 Sonnet v2 N/A (参考訳) 段階的に解決してみましょう。まず、わかっていることを理解しましょう：Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。任意の人から始めて、順番に配置してみましょう：Dave が Emily の真左にいる場合、Emily は Dave の真右にいます。Colin が Dave の真左にいる場合、Dave は Colin の真右にいます。Bob が Colin の真左にいる場合、Colin は Bob の真右にいます。Alan が Bob の真左にいる場合、Bob は Alan の真右にいます。つまり、時計回りの順序は：Alan → Bob → Colin → Dave → Emily です。円形なので、Emily は円を完成させるために Alan の隣にいる必要があります。したがって、Emily は Alan の真右にいます。 答えは Emily です。 不正解 Claude 4 Sonnet (参考訳) 段階的に取り組んでみましょう。 円形に立っている 5 人がいます：Alan、Bob、Colin、Dave、Emily。 与えられた情報を追跡してみましょう： Alan は Bob の真左にいます Bob は Colin の真左にいます Colin は Dave の真左にいます Dave は Emily の真左にいます 円形なので、順序を把握する必要があります。1 人から始めて周りを回ってみましょう。 Alan が Bob の真左にいる場合、時計回りに：Alan、次に Bob。 Bob が Colin の真左にいる場合、時計回りに：Bob、次に Colin。 Colin が Dave の真左にいる場合、時計回りに：Colin、次に Dave。 Dave が Emily の真左にいる場合、時計回りに：Dave、次に Emily。 つまり、円の時計回りは：Alan → Bob → Colin → Dave → Emily しかし、円なので、Emily は誰かに接続する必要があります。Alan → Bob → Colin → Dave → Emily があり、これは 5 人の完全な円なので、Emily の次は Alan でなければなりません。 つまり、完全な時計回りの円は：Alan → Bob → Colin → Dave → Emily → Alan これは Emily が Alan の真左にいることを意味し、したがって Alan の真右は…慎重に考えてみましょう。 時計回りに行くと：Alan → Bob → Colin → Dave → Emily → (Alan に戻る) つまり、Alan の真右 (Alan から時計回りに) は Bob です。そして Alan の真左 (Alan から反時計回りに) は Emily です。 与えられた条件を再確認してみましょう： Alan は Bob の真左にいます ✓ (Alan は時計回りで Bob の直前に来ます) Bob は Colin の真左にいます ✓ (Bob は時計回りで Colin の直前に来ます) Colin は Dave の真左にいます ✓ (Colin は時計回りで Dave の直前に来ます) Dave は Emily の真左にいます ✓ (Dave は時計回りで Emily の直前に来ます) 円形配置で Bob が Alan の真右に座っていることを確認します。 (参考訳) 段階的に見てみましょう：与えられた情報：Alan は Bob の真左にいます。Bob は Colin の真左にいます。Colin は Dave の真左にいます。Dave は Emily の真左にいます。円の時計回りの順序を追跡してみましょう：Alan → Bob (Alan が Bob の真左にいるため)。Bob → Colin (Bob が Colin の真左にいるため)。Colin → Dave (Colin が Dave の真左にいるため)。Dave → Emily (Dave が Emily の真左にいるため)。円形に立っているので、Emily は円を完成させるために接続する必要があります：Emily → Alan。つまり、完全な時計回りの順序は：Alan → Bob → Colin → Dave → Emily → Alan。したがって、 Bob が Alan の真右にいます 。 正解 拡張思考が有効な場合、API はデフォルトで、誤用を防ぐための保護措置として設計された、完全な推論チェーンではなく モデルの完全な思考プロセスの要約を返し ます。これにより、完全なインテリジェンス利益を提供しながらも、ストリーミング応答でチャンクまたは遅延パターンが生じる可能性があり、開発者はアプリケーションのユーザーエクスペリエンスでこれを考慮する必要があります。 Anthropic の Claude 4 モデルは、ツールで拡張思考を使用する際の インターリーブ思考 機能を備えており、モデルがツール呼び出し間で中間推論を実行し、受け取ったツール結果に基づいてより微妙な分析結論を開発できます。ツール呼び出しで インターリーブ思考を有効にする には、Converse API リクエストの additionalModelRequestFields に追加パラメータ "anthropic_beta": ["interleaved-thinking-2025-05-14"] を追加します。 拡張思考の使用について詳しくは、 拡張思考 を参照してください。 堅牢な評価の必要性 新しいモデルが特定のタスクで古いモデルと同等以上のパフォーマンスを発揮することを検証する必要があります。本番トラフィックを高度に代表する、厳選されたプロンプトと期待される出力のセットを作成してください。このカスタムベンチマークは、報告されたベンチマークスコアよりもはるかに価値があります。 このデータセットを自動評価パイプラインに統合してください。このパイプラインは、継続的インテグレーションおよび継続的デリバリー (CI/CD) プロセスの一部となり、将来のモデルやプロンプトの変更に対する永続的な回帰スイートとして機能する必要があります。ツールについては、チームは Amazon Bedrock の評価 などの組み込みソリューションや、 RAGAS や DeepEval などのオープンソース評価フレームワークを使用できます。 統合された安全性とガバナンスの管理 モデルの安全プロファイルは各バージョンで変化します。これは統合システムの一部としてテストする必要があります。新しいモデルを単独でテストしてはいけません。移行テスト計画は、本番環境で使用するのと全く同じガードレール設定 (例： Amazon Bedrock ガードレール ) で新しいモデルを評価する場合にのみ有効です。新しいモデルの会話スタイルが既存のガードレールを予期しない方法でトリガーし、ブロックされた応答の急増につながる可能性があります。 安全なデプロイメント戦略の実装 Anthropic の Claude 4 Sonnet を本番環境にデプロイする際は、リスクを最小化するために段階的ロールアウト戦略を実装してください。ユーザーに影響を与えることなく、ミラーリングされたトラフィックを使用してモデルパフォーマンスを比較するシャドウテストを検討し、その後ビジネス KPI への影響を測定するための A/B テストを実施してください。実際のロールアウトでは、少数のユーザーを新しいモデルに段階的に公開するカナリアリリースアプローチ、または即座にロールバック機能を持つ並列環境を維持するブルー/グリーンデプロイメント戦略のいずれかを使用してください。この構造化されたアプローチにより、ビジネス継続性を維持しながら新しいモデルのパフォーマンスを安全に検証できます。 まとめ Anthropic の Claude 3.5 Sonnet (v1 および v2) から Claude 4 Sonnet への移行を構造化されたエンジニアリングプロジェクトとして扱うことで、移行プロセスのリスクを軽減し、大きな利益を得ることができます。主要なモデルの違いを理解し、プロンプトと API 呼び出しを適応させ、堅牢で自動化された評価戦略を実装することが、成功するアップグレードの柱です。 この移行は、ビジネス継続性を維持し、次世代機能でアプリケーションを強化する機会です。今日から分析とテストを開始することをお勧めします。 詳細については、 Claude 4 への移行 と Amazon Bedrock における Anthropic の Claude を参照し、移行固有のお問い合わせについてはお気軽にお問い合わせください。 このブログはソリューションアーキテクトの福本が翻訳しました。原文は こちら です。 About the authors Melanie Li 博士は、オーストラリアのシドニーを拠点とする AWS のシニア生成 AI スペシャリストソリューションアーキテクトで、最先端の AI/ML ツールを使用したソリューション構築でお客様と協力することに焦点を当てています。彼女は APJ 全体で複数の生成 AI イニシアチブに積極的に関与し、LLM の力を活用しています。AWS に参加する前、Li 博士は金融および小売業界でデータサイエンスの役割を担っていました。 Deepak Dalakoti 博士は、オーストラリアのシドニーにある生成 AI イノベーションセンターのディープラーニングアーキテクトです。AI の専門知識を持つ彼は、クライアントと協力してカスタマイズされた革新的なソリューションを通じて生成 AI の採用を加速しています。AI の世界以外では、新しい活動や体験を探求することを楽しんでいます。 Mahsa Paknezhad 博士は、AWS 生成 AI イノベーションセンターのディープラーニングアーキテクトです。スケーラビリティと本番準備に焦点を当て、Mahsa は多様な業界の組織が高度な生成 AI モデルを活用して意味のあるビジネス成果を達成することを支援しています。Mahsa は、特に鉱業および医療セクターでプロジェクトを成功裏に提供した実績があります。 Nicholas Moore は AWS のソリューションアーキテクトで、スタートアップやあらゆる規模の企業がアイデアを現実に変えることを支援しています。彼は AI、分析、モダンアプリケーション開発に焦点を当てたクラウドソリューションを専門としています。 Derrick Choo は、クラウド採用、AI/ML、生成 AI ソリューションを通じて企業のデジタル変革を加速する AWS のシニアソリューションアーキテクトです。彼はフルスタック開発と ML を専門とし、フロントエンドインターフェース、IoT アプリケーション、データ統合、ML モデルにまたがるエンドツーエンドソリューションを設計し、特にコンピュータビジョンとマルチモーダルシステムに焦点を当てています。 Sovik Kumar Nath は、AWS の AI/ML および生成 AI シニアソリューションアーキテクトです。彼は、金融、運用、マーケティング、医療、サプライチェーン管理、IoT におけるエンドツーエンドの ML およびビジネス分析ソリューションの設計において豊富な経験を持っています。彼は南フロリダ大学とスイスのフリブール大学で修士号を、インド工科大学カラグプール校で学士号を取得しています。仕事以外では、Sovik は旅行、フェリーライド、映画鑑賞を楽しんでいます。 Saurabh Trikande は、Amazon Bedrock と Amazon SageMaker Inference のシニアプロダクトマネージャーです。彼は顧客やパートナーとの協力に情熱を持ち、AI の民主化という目標に動機づけられています。彼は、複雑な AI アプリケーションのデプロイ、マルチテナントモデルでの推論、コスト最適化、生成 AI モデルのデプロイをより身近にすることに関連するコアチャレンジに焦点を当てています。余暇には、Saurabh はハイキング、革新的技術について学ぶこと、TechCrunch をフォローすること、家族と時間を過ごすことを楽しんでいます。 Gareth Jones は、Claude API に焦点を当てた Anthropic のプロダクトマネージャーです。彼の仕事には、Claude を開発者に広くアクセス可能にするための Amazon Bedrock での AWS との協力が含まれます。 <!-- '"` -->

本記事は Securing Vehicle Identification Number (VIN) with Reference ID in connected vehicle platforms with AWS IoT を翻訳したものです。 2025 年末までに 4 億 7000 万台以上のコネクテッドカーが予想されるなか、製造メーカーにとって車両認識番号 (VIN) などの機密車両データを保護することが極めて重要になっています。 VIN は製造から整備に至るまでの自動車プロセスにおいて、固有の識別子として使われており、 サイバー犯罪者の標的 にされがちです。 本記事では、AWS IoT を利用してコネクテッドカー・プラットフォームにおける VIN の保護方法を紹介し、データ保護とシステムの機能性を両立することができます。 このソリューションでは、実際の VIN を公開することなく、セキュリティで保護された車両データの連携を可能にするために、VIN の仮名として Reference ID を導入しています。AWS IoT サービスを活用して、この分野のアーキテクチャがメーカーに対し、機能性は維持しつつ車両のユースケース全体で機密データを保護する方法を示します。 概要 このソリューションは Reference ID システムを使用しています。Reference ID システムでは、各車両にプロビジョニング時に一意の識別子が付与されます。この識別子がプラットフォームとのすべてのやり取りで VIN の代理として機能します。 車両レジストリデータベースには、ハッシュ化された VIN と暗号化された VIN の両方が格納されており、Reference ID にマッピングされています。 クライアントが VIN を提示すると、システムはその VIN をハッシュ化して対応する Reference ID を取得します。これにより、既存のプロセスと安全に統合できます。 暗号化された車両識別番号 (VIN) は、セキュアな AWS Key Management Service (AWS KMS) を使って、プロビジョニング中に暗号化されてフェイルセーフ対策として追加されます。 プレーンテキストの VIN を取得する必要がある場合は、この値を復号化することで可能です。 これにより、絶対に必要な場合に限り実際の VIN にアクセスできますが、強力なセキュリティ対策が維持されます。 VIN (車両識別番号) には重要な車両情報 (メーカー、モデル、年式) が含まれており、個人データとリンクされています。クラウド環境で保護されていない VIN は、ID の盗難、車の盗難、保険金詐欺、プライバシー侵害、規制 (GDPR、CCPA) 違反のリスクがあります。 クラウドベースのコネクティッドカープラットフォームで VIN (車体識別番号) の保護にReference ID システムを実装することで、自動車メーカーは現代の自動車運用に必要な機能と効率を維持しつつ、データセキュリティを向上させることができます： VIN のプロキシとして機能し、セキュリティとデータの最小化を強化します データ保護規制への準拠をサポートします 柔軟なアクセス制御と監査性の向上を提供します 大規模な車両フリートのスケーラビリティとシステム間の相互運用性を容易にします 基盤となる VIN を変更せずに失効させることができます VIN のアクセスと変換の詳細な監査とログを可能にし、Reference ID と VIN 間の変換を許可される主体と変換内容の可視化を提供します アーキテクチャの概要 1. Reference ID Reference ID は、車両プロビジョニング時に生成される UUID で、車両のライフサイクルを通して VIN の代理として機能し、機密性の高い VIN データを保護する抽象化層を作成します。 2. 車両登録データベース 車両登録データベースは、プラットフォームのライフタイム全体にわたり車両情報の集中リポジトリとして機能します。主な機能は次のとおりです。 Reference ID からハッシュ化された VIN へのマッピング 暗号化された VIN ストレージ 車両のプロビジョニングと状態変更の追跡 デバイスの変更履歴 車両の属性と構成 VIN のハッシュ化により、実際の値を暴露することなく安全な検証が可能になります。この集中管理されたアプローチにより、単一の情報源を提供すると同時に、安全なリモート診断と OTA のアップデートを可能にします。 車両登録 DB referenceId – パーティションキー deviceId – グローバルセカンダリインデックス hashedVin – グローバルセカンダリインデックス tenantId encryptedVin 注： deviceId と hashedVin をグローバルセカンダリインデックスにすると、いずれかのフィールドで車両詳細を問い合わせることができます。 3. 車両の設定 車両プロビジョニングでは、データの検証、安全な保管、AWS IoT との統合を通じて、セキュアな車両管理を確立し、Reference ID システムを実装します。 車両情報を保護しながら、シームレスな接続性と管理を可能にするプロセスの主要ステップを見ていきましょう： 3.1 データの検証： プロビジョニングのインフラストラクチャは、VIN をハッシュ化し、車両レジストリ DB に問い合わせて、初めてのプロビジョニングかどうかをチェックします。 新車の場合、DEVICE ID は TCU メーカーが提供する既存のデータと照合できます。 また、車両レジストリ DB に DEVICE ID で問い合わせることで、そのデバイスが別の車両に割り当てられていないかチェックします。 3.2 Reference ID 生成 ハッシュ化された VIN を使用して、車両登録 DB に対してクエリを実行し、車両がすでに登録されているかどうかを検証します。 車両がまだ登録されていない場合は、新しい UUID がReference ID として生成されます。 Reference ID、ハッシュ化された VIN、暗号化された VIN (KMS 経由) が、他の車両情報とともに車両登録 DB に保存されます。UUID の衝突が稀にある場合は、リクエストを再試行して新しい UUID をReference ID として生成することができます。 Reference ID で車両登録 DB に対して最終的なクエリが実行され、ユニークであることを確認します。UUID の衝突が検出された場合、新しい UUID が生成されます。 以前に登録されている車両の場合、受信したペイロードは単に登録 DB の項目に対して検証されます。 3.3 証明書の生成 証明書は、Common Name = Reference ID で ACM PCA を使用して生成されます。 3.4 AWS IoT との統合 AWS IoT Thing は、Thing name = Reference ID で作成されます。 AWS IoT FleetWise の車両は、Vehicle Name = Reference ID で作成されます。 3.5 レスポンスペイロードの構築 プロビジョニングが成功すると、車両に証明書とReference ID が発行されます。 車両は、発行された証明書と ClientId = Reference ID を使って、AWS IoT FleetWise に接続できます。 このプロセスは、Reference ID を使用して機密の VIN 情報を保護しつつ、車両の安全な供給を確実にするのに役立ちます。 車両は、証明書署名リクエスト (CSR) を提供できます。この供給インフラストラクチャは、CSR を使用して証明書を生成します。堅牢なアイデンティティおよびアクセス管理のための AWS サービスを活用しています。 4. データの収集と保存 データの収集と保管は必須の構成要素であり、Reference ID により車両データのライフサイクル全体 (送信から保存、取得まで) で安全な取り扱いが保証されます。このシステムにより、VIN 情報を保護しつつ、効率的なデータ操作が可能となります。 4.1 車両から AWS IoT FleetWise へ： 車両は、Reference ID をクライアント ID として使用して、AWS IoT FleetWise に接続します。 車両から送信されるすべてのデータは、AWS IoT FleetWise での車両名 = Reference ID として、Reference ID に関連付けられます。 4.2 AWS IoT FleetWise からデータプラットフォームへ： AWS IoT FleetWise から流れるデータには、車両名 (Reference ID) が付与されます。 4.3 データの保存と取得： データプラットフォームのデータは、Reference ID を識別子として保存されます。 モバイルアプリは、Reference ID を使って API プラットフォームを経由してデータプラットフォームにアクセし、車両データを取得します。 匿名化されたReference ID には車両固有の情報は含まれず、 AWS IoT Core 、 AWS IoT FleetWise 、および関連するデータストア全体での主要な識別子として機能します。 この情報中立的なアプローチにより、VIN の保護が確保されると同時に、プラットフォーム全体でのシームレスなデータ操作が可能になります。 5. クライアントアプリケーションの相互作用 顧客関係管理 (CRM) システムや、ユーザへの VIN マッピングを管理するプラットフォームなどのクライアントアプリケーションは、通常、プレーンテキストの VIN 番号を扱います。このシステムのセキュリティ上の利点を維持しつつ、これらのアプリケーションに対応するために、接続された車両プラットフォームとのクライアントの対話のためのストリームラインプロセスが実装されています。 5.1 VIN からReference ID への変換 クライアントアプリケーションは、車両の所有権を確認した後、ハッシュ化された車両識別番号とReference ID の相互変換のため、プラットフォームに API 呼び出しを行います。 API は車両レジストリデータベースに問い合わせを行い、対応するReference ID を取得します。 その後、Reference ID がクライアントアプリケーションに返されます。 セキュリティに関する考慮事項： この変換 API へのアクセスは、堅牢な認証と認可によって厳重に制御される必要があります。 監査目的で、すべての変換リクエストがログ記録され、不審なパターンを検出する必要があります。 実装には、DoS/DDoS 攻撃や、不正な大量変換試行から防御するためのレート制限やその他のセキュリティ対策を含める必要があります。 この API は車両データの再識別を可能にするため、アクセスは正当なビジネス上の必要性がある認可済みアプリケーションに制限する必要があります。 5.2 VIN に対応する Reference ID を取得したら、クライアントアプリケーションは以下を実行可能： Reference ID を使用してデータプラットフォームからデータを取得します。 リモートコマンドなどのように、Reference ID を渡すことで、直接車両に操作を実行します。 この方法は、API 呼び出しでの VIN 使用を排除し、VIN とReference ID の分離を維持することで、プラットフォームのセキュリティ強化に役立ちます。 このシステムは、クラウドベースの車両管理のための堅牢なフレームワークを提供しながら、セキュアなクライアントアプリケーション間の対話を可能にします。 6. テレマティクスコントロールユニットの変更 Telematics Control Unit（TCU）の変更フローは、接続された車両プラットフォームにおいて重要なプロセスです。 車両の TCU を更新または交換する必要がある場合に対処します。 これは、車両が製造施設を出る前、または所有者に引き渡された後に TCU に問題が発見され、サービスセンターで交換が必要になった場合のいずれかで発生します。 TCU Change フローは、次の 2 つの関数のいずれかを使って API 呼び出しとして利用できます： 車両レジストリデータベース内の DEVICE ID を新しい DEVICE ID に更新します。 車両のデータベースエントリから DEVICE ID を単に削除します。つまり、NULL としてマークします。 6.1 TCU の更新： 入力： ハッシュ化された VIN (または Reference ID)、既存の DEVICE ID、新しい DEVICE ID。 この API は以下を行います。 ハッシュ化された VIN が存在し、レジストリデータベース内の既存の DEVICE ID と一致することを確認する 新しい DEVICE ID が別の車両に関連付けられていないことを確認する レジストリデータベース内の DEVICE ID を更新する 秘密鍵が TCU ハードウェア自体内に格納されているため、置換え TCU には新しい証明書が必要になるので、車両の既存の証明書 (プロビジョニング時に発行され、AWS IoT Core に登録されたもの) を失効し削除する 新しい TCU がクラウドへの接続プロセスを通る。 6.2 TCU の削除： 入力： ハッシュ化された VIN (またはReference ID)、既存の DEVICE ID。 この API は以下のことを行います： ハッシュ化された VIN が登録データベースに存在し、DEVICE ID が一致することを検証します。 登録データベースからエントリの DEVICE ID を削除します。 車両の既存の証明書 (プロビジョニング中に発行され、AWS IoT Core に登録されている) を失効および削除します。 注： 車両を特定するためには、ハッシュ化された VIN またはReference ID のどちらを使っても構いません。SHA256 のハッシュ関数の衝突確率が極めて低いため、ハッシュ化された VIN を使用しても問題ありません。 両方のフローは、TCU 変更の履歴をレジストリデータベースが各車両に対して維持することで、セキュリティが確保され追跡可能な TCU 変更プロセスを保証します。 このアプローチにより、システムの整合性を維持しつつ、車両フリートで必要なハードウェアのアップデートに対応できます。 セキュリティ、パフォーマンス、スケーラビリティに関する考慮事項 Reference ID システムは、日々の業務での VIN の露出を最小限に抑けることで、VIN の保護を強化します。 車両レジストリデータベースは、ハッシュ化および暗号化された VIN のみを格納し、Reference ID はプラットフォームとのすべての相互作用を処理します。 AWS KMS による暗号化と厳格なアクセス制御ポリシーにより、セキュリティがさらに強化されています。 最適なパフォーマンスとスケーラビリティを実現するために、このシステムは効率的な UUID 生成と DynamoDB のグローバルセカンダリインデックスを使用して高速なクエリを実現しています。 将来的には、この VIN 管理システムは、ブロックチェーンや分散型レジストリ技術などの新しいテクノロジーと統合して、改ざん防止の VIN レコードを実現する可能性があり、セキュリティと追跡性をさらに強化できます。 自動車メーカーがこのシステムから収集できるデータの豊富さは、高度な分析や機械学習アプリケーションの可能性も開き、車両の性能、メンテナンス要件、ユーザーの行動パターンに関する洞察を得られる可能性があります。 GDPR や CCPA などのデータ保護規制に継続して準拠していくためには、最新のハッシュとデータ暗号化アルゴリズムを導入し、詳細なアクセス制御を実装し、データ取り扱い手順を定期的に監査することをお勧めします。 この包括的なアプローチは、VIN データを保護するだけでなく、コネクテッドカー管理における将来のイノベーションの基盤ともなります。 まとめ この投稿では、Reference ID がどのように自動車メーカーの AWS 上の接続車両プラットフォームにおける VIN のセキュリティを強化できるかを示しました。 この設計は、自動車の使用事例全体で完全な機能を維持しつつ、機密の車両データを保護します。AWS IoT Core や Amazon DynamoDB などの AWS サービスを活用することで、この解決策は大規模な車両フリートに対して効率的にスケーリングできます。 接続された車両の台数が増えるにつれ、自動車メーカーにとってセキュリティ対策が重要になります。このReference ID システムは、自動車メーカーに VIN の保護を支援するだけでなく、データ保護規制のコンプライアンス標準を満たすのに役立ちます。 TCU 変更などのシナリオを含め、車両のライフサイクル全体で車両識別を管理するための柔軟なフレームワークを提供します。 このアプローチをあなたのコネクティッドビークルソリューションにどのように適用できるか、探索することをお勧めします。AWS IoT サービスとコネクティッドビークルのベストプラクティスの詳細は、 AWS IoT FleetWise のドキュメント と 関連するブログ記事 を参照してください。 著者について Paritosh Mehta Paritosh Mehta は、AWS プロフェッショナルサービスのデリバリーコンサルタントとして、アジア太平洋地域全体でコネクテッドビークルおよび産業IoTの実装をリードしています。ProServe India の IoT テクニカルリードとして、自動車 OEM および製造業者向けの変革的なソリューションを設計し、車両テレマティクス、リアルタイムデータプラットフォーム、製造システム統合を専門としています。 Ankur Pannase Ankur は、AWS プロフェッショナルサービスのセキュリティアーキテクトです。お客様と密接に連携し、技術的、規制的、ビジネス要件に合わせたクラウドセキュリティソリューションの設計と実装を行っています。Ankur は、組織がクラウド上で安全でスケーラブル、かつコンプライアンスに準拠した環境を構築することを専門としています。 Jay Chung Jay は、AWS プロフェッショナルサービスのシニアデリバリーコンサルタントとして、お客様の変革的なクラウドソリューションのアーキテクチャ設計と実装を支援しています。Jay は自動車業界の愛好家で、自動車テストツール業界でプロダクトマネージャーおよびソフトウェアエンジニアとして10年以上の経験を持っています。 Robin Francis Robin は AWS のプロフェッショナルサービスチーム内でクラウドアプリケーションアーキテクトとして働き、世界最大級の企業がクラウド上で効率的で革新的なソリューションを構築することを支援しています。独学者、博学者、多言語話者である彼は、常に芸術と科学の異なる分野に挑戦しています。仕事以外では、音楽制作、外国語学習、料理、サーフィン、旅行を楽しんでいます。

本記事は SBI生命保険株式会社 狩野泰隆氏から寄稿いただきました。 SBI生命保険は昨今の委託先による大規模情報漏洩事件とデジタルトランスフォーメーション (DX) 時代の帳票システム再構築という課題に取り組んできました。 ■サプライチェーンリスクと BCP を乗り越える内製化戦略 DX が必須となる今日、機密性の高い帳票作成業務には気付きにくいリスクが潜んでいました。このことは、外部委託先で起きた大規模な個人情報流出事故によって明らかになりました。 特に深刻だったのは、委託先から数百万件件以上の個人情報が流出し、インターネットのダークウェブで公開された事件です。流出した情報には、個人の氏名や住所だけでなく、確定拠出年金の内容、ローンの残高、納税額といった非常に重要な個人情報も含まれていました。 この事件は、幸いにも SBI生命保険の委託先での事故ではありませんでしたが、保険業務の一部について情報処理業務を外部ベンダーに「丸投げ」する従来の運用体制が、いかに根本的な脆弱性を抱えるかを示しました。委託先のセキュリティインシデントは、直接自社の顧客情報流出、ブランドイメージの失墜、事業継続の危機に直結します。特に大量の個人情報を扱う帳票業務を外部に委託する場合、そのサプライチェーンリスクは計り知れず、委託先が機能不全に陥れば、自社の基幹業務停止という BCP 上の大きな脅威となることを再認識しました。 ■リスクを自社内に取り込む戦略 SBI生命保険では、この大規模情報漏洩インシデントを「DX 推進の奇貨」と捉え、従来の外部依存型を根本から覆す「帳票エンジン」の内製化を企画しました。 新しい帳票作成システムでは、Amazon QuickSight をレイアウト作成と情報抽出のエンジンとして採用しています。 QuickSight のダッシュボードでレイアウトを設計し、各種情報をオーバーレイさせることで契約書などの複雑なフォーマットにも対応可能です。ユーザーはパラメーター設定でデータベースから必要な情報を抽出し、適切な情報が埋め込まれた帳票を自社内で迅速に生成できます。これによってデータ処理から帳票生成・出力までを全て自社内で完結できるようになりました。 この新システムには、3 つの重要な特長があります。まず、帳票エンジンを内製化することで、外部ベンダーへの機密データ提供を最小限に抑え、情報漏洩リスクを低減できると考えています。次に、自社内でデータ処理を完結させることにより、情報管理の透明性と統制を強化し、QuickSight のアクセス権限管理機能を活用することで高いセキュリティと使いやすさを両立しています。第三に、帳票生成における外部依存を解消し、クラウドを活用した可用性の高いアーキテクチャを採用したことで、以前よりも高い事業継続性を確保しています。 新システムを活用することで、従来約 2 ヶ月かかっていた帳票作成期間を約 1 週間に短縮し、業務の迅速な対応力を向上させると同時に、情報システム部門にとっては保守性の向上と運用負荷の大幅な軽減を実現するという成果を得ることができました。 ■未来を見据えた戦略的投資として 大規模情報漏洩事件では、データガバナンス、運用、外部ベンダー依存といった従来の帳票システム課題が、経営課題であることを浮き彫りになりました。 SBI生命保険の QuickSight を活用した「帳票エンジン」は、これらの課題を着実に解消し、セキュリティ強化、開発コスト・期間の最適化、業務の柔軟性とスピード向上を実現します。これは単なる IT システム導入ではなく、データガバナンスを経営戦略の中核に据え、サプライチェーンリスクを管理し、事業継続性を高めるための、未来を見据えた戦略的投資と考えています。 同様の課題を抱える企業にとって、本事例が少しでも参考となり、帳票業務の見直しや改善のきっかけとなれば幸いです。 ■今後 社内外で運用されている帳票を体系的に整理し、順次、当該サービスに組み込んでいく予定です。これにより、社内全体での活用範囲の拡大が進み帳票管理の一元化とさらなる業務効率化を見込んでいます。 ■システム構成の概要と構成図 今回開発した帳票作成システムは、QuickSight をデータ可視化ツールとしてではなく、帳票レイアウト作成・抽出エンジンとして活用することで、柔軟で効率的な帳票作成を実現しています。 QuickSight のダッシュボード機能を使用して帳票のレイアウトを設計し、帳票レイヤー機能を活用して契約書などの複雑なフォーマットにも対応しています。データソースとしては Amazon Aurora などのデータベースに接続しており、SQL で必要な情報を抽出しています。 図1: システム構成図 QuickSight ダッシュボードのパラメーターで設定した値を元に、「帳票作成」ボタンをクリックすると、あらかじめ指定された SQL 文がデータベースに対して実行されます。この際実行される SQL 文はあらかじめ AWS Systems Manager Parameter Store に保存してあります。ユーザーは QuickSight からパラメーターを設定するだけで、帳票作成に必要な情報を取得し、適切な情報が埋め込まれた帳票を取得することができます。 QuickSight ユーザーのアクセス権限管理を利用し、ユーザーごとにアクセスできる帳票テンプレートを制限することで、セキュリティを確保しながらユーザビリティを向上させています。帳票の生成は、「帳票作成」ボタンに URL を埋め込み、Amazon API Gateway 経由で API を実行する仕組みを構築しています。 図2: システム画面のスクリーン（イメージ） 執筆者 狩野 泰隆（かのう やすたか） SBI生命保険株式会社 情報システム部 部長 25 年以上にわたり、システム開発領域を牽引。大手 SIer での豊富な経験を経て、2018年に SBI生命保険株式会社へ転身。金融・流通・産業分野を中心に、業務システムの設計・構築に幅広く携わる。近年は、AWS を活用したクラウドネイティブなアーキテクチャ設計や、内製化による DX 推進に注力。最新技術への深い理解と現場視点を融合させた実践的なアプローチに定評があり、書籍執筆にも取り組むなど、知見を広く共有している。

本記事は SBI生命保険株式会社 狩野泰隆氏から寄稿いただきました。 SBI生命保険は昨今の委託先による大規模情報漏洩事件とデジタルトランスフォーメーション (DX) 時代の帳票システム再構築という課題に取り組んできました。 ■サプライチェーンリスクと BCP を乗り越える内製化戦略 DX が必須となる今日、機密性の高い帳票作成業務には気付きにくいリスクが潜んでいました。このことは、外部委託先で起きた大規模な個人情報流出事故によって明らかになりました。 特に深刻だったのは、委託先から数百万件件以上の個人情報が流出し、インターネットのダークウェブで公開された事件です。流出した情報には、個人の氏名や住所だけでなく、確定拠出年金の内容、ローンの残高、納税額といった非常に重要な個人情報も含まれていました。 この事件は、幸いにも SBI生命保険の委託先での事故ではありませんでしたが、保険業務の一部について情報処理業務を外部ベンダーに「丸投げ」する従来の運用体制が、いかに根本的な脆弱性を抱えるかを示しました。委託先のセキュリティインシデントは、直接自社の顧客情報流出、ブランドイメージの失墜、事業継続の危機に直結します。特に大量の個人情報を扱う帳票業務を外部に委託する場合、そのサプライチェーンリスクは計り知れず、委託先が機能不全に陥れば、自社の基幹業務停止という BCP 上の大きな脅威となることを再認識しました。 ■リスクを自社内に取り込む戦略 SBI生命保険では、この大規模情報漏洩インシデントを「DX 推進の奇貨」と捉え、従来の外部依存型を根本から覆す「帳票エンジン」の内製化を企画しました。 新しい帳票作成システムでは、Amazon QuickSight をレイアウト作成と情報抽出のエンジンとして採用しています。 QuickSight のダッシュボードでレイアウトを設計し、各種情報をオーバーレイさせることで契約書などの複雑なフォーマットにも対応可能です。ユーザーはパラメーター設定でデータベースから必要な情報を抽出し、適切な情報が埋め込まれた帳票を自社内で迅速に生成できます。これによってデータ処理から帳票生成・出力までを全て自社内で完結できるようになりました。 この新システムには、3 つの重要な特長があります。まず、帳票エンジンを内製化することで、外部ベンダーへの機密データ提供を最小限に抑え、情報漏洩リスクを低減できると考えています。次に、自社内でデータ処理を完結させることにより、情報管理の透明性と統制を強化し、QuickSight のアクセス権限管理機能を活用することで高いセキュリティと使いやすさを両立しています。第三に、帳票生成における外部依存を解消し、クラウドを活用した可用性の高いアーキテクチャを採用したことで、以前よりも高い事業継続性を確保しています。 新システムを活用することで、従来約 2 ヶ月かかっていた帳票作成期間を約 1 週間に短縮し、業務の迅速な対応力を向上させると同時に、情報システム部門にとっては保守性の向上と運用負荷の大幅な軽減を実現するという成果を得ることができました。 ■未来を見据えた戦略的投資として 大規模情報漏洩事件では、データガバナンス、運用、外部ベンダー依存といった従来の帳票システム課題が、経営課題であることを浮き彫りになりました。 SBI生命保険の QuickSight を活用した「帳票エンジン」は、これらの課題を着実に解消し、セキュリティ強化、開発コスト・期間の最適化、業務の柔軟性とスピード向上を実現します。これは単なる IT システム導入ではなく、データガバナンスを経営戦略の中核に据え、サプライチェーンリスクを管理し、事業継続性を高めるための、未来を見据えた戦略的投資と考えています。 同様の課題を抱える企業にとって、本事例が少しでも参考となり、帳票業務の見直しや改善のきっかけとなれば幸いです。 ■今後 社内外で運用されている帳票を体系的に整理し、順次、当該サービスに組み込んでいく予定です。これにより、社内全体での活用範囲の拡大が進み帳票管理の一元化とさらなる業務効率化を見込んでいます。 ■システム構成の概要と構成図 今回開発した帳票作成システムは、QuickSight をデータ可視化ツールとしてではなく、帳票レイアウト作成・抽出エンジンとして活用することで、柔軟で効率的な帳票作成を実現しています。 QuickSight のダッシュボード機能を使用して帳票のレイアウトを設計し、帳票レイヤー機能を活用して契約書などの複雑なフォーマットにも対応しています。データソースとしては Amazon Aurora などのデータベースに接続しており、SQL で必要な情報を抽出しています。 図1: システム構成図 QuickSight ダッシュボードのパラメーターで設定した値を元に、「帳票作成」ボタンをクリックすると、あらかじめ指定された SQL 文がデータベースに対して実行されます。この際実行される SQL 文はあらかじめ AWS Systems Manager Parameter Store に保存してあります。ユーザーは QuickSight からパラメーターを設定するだけで、帳票作成に必要な情報を取得し、適切な情報が埋め込まれた帳票を取得することができます。 QuickSight ユーザーのアクセス権限管理を利用し、ユーザーごとにアクセスできる帳票テンプレートを制限することで、セキュリティを確保しながらユーザビリティを向上させています。帳票の生成は、「帳票作成」ボタンに URL を埋め込み、Amazon API Gateway 経由で API を実行する仕組みを構築しています。 図2: システム画面のスクリーン（イメージ） 執筆者 狩野 泰隆（かのう やすたか） SBI生命保険株式会社 情報システム部 部長 25 年以上にわたり、システム開発領域を牽引。大手 SIer での豊富な経験を経て、2018年に SBI生命保険株式会社へ転身。金融・流通・産業分野を中心に、業務システムの設計・構築に幅広く携わる。近年は、AWS を活用したクラウドネイティブなアーキテクチャ設計や、内製化による DX 推進に注力。最新技術への深い理解と現場視点を融合させた実践的なアプローチに定評があり、書籍執筆にも取り組むなど、知見を広く共有している。

本投稿は、 Sameer Malik 、Anvesh Koganti、Shubham Singhによる記事「 Implement network connectivity patterns for Oracle Database@AWS 」を翻訳したものです。 Oracle Database@AWS （ODB@AWS）は、 Amazon Web Services（AWS） データセンター内に配置されたOracle Cloud Infrastructure（OCI）が管理するOracle Exadataインフラストラクチャへのアクセスに使用できるサービスです。ODB @AWS を使用すると、オンプレミスのOracle Exadataデプロイメントと同じパフォーマンスと機能を維持しながら、Oracle ExadataワークロードをAWSに移行できます。Oracle ExadataとAWS上で稼働しているアプリケーションとの間に低レイテンシーの接続を確立することで、アプリケーションのレイテンシーが短縮されるというメリットがあります。さらに、Oracle Database @AWS を他の AWS サービスと統合して、Oracle Databaseアプリケーションの可用性とスケーラビリティを向上させることができます。 この投稿では、ODBネットワークとAWSにデプロイされている他のリソースとオンプレミスネットワークとの接続に、さまざまなIPルーティングベースのネットワーク接続パターンを実装する方法を示します。このパターンは、IPアドレス空間が重複しておらず、従来のレイヤー3接続が必要な場合に適しています。 この記事で取り上げる接続パターンは次のとおりです。 アプリケーション用の仮想プライベートクラウド（VPC）とODBネットワーク間の1対1の接続 AWS Transit Gateway を使用した、マルチVPCまたはオンプレミスのインフラストラクチャとODBネットワーク間のスケーラブルな単一リージョン接続 AWS Cloud WAN を使用して、マルチVPCまたはオンプレミスのインフラストラクチャとODBネットワーク間のスケーラブルなグローバル接続 本投稿の理解を深めるために、 Amazon Virtual Private Cloud（Amazon VPC） 、 AWS Direct Connect 、 Amazon Route 53 Resolver endpoints 、Transit Gateway、AWS Cloud WANなどのAWSサービスを理解しておくことをお勧めします。 基本の理解 以下は、ネットワーク接続に不可欠な ODB @AWS のコアコンポーネントの概要です。詳細については、 Oracle Database @AWS ユーザーガイド を参照してください。 ODBネットワーク — ODBネットワークは、AWSアベイラビリティーゾーン内のOracleインフラストラクチャをホストするプライベートで独立したネットワークです。標準のVPCとは異なり、ODBネットワークはインターネット接続がなく、ODB @AWS リソースのみをサポートします。 ODBピアリング — ODBピアリングは、ODBネットワークとAmazon VPC間のプライベートネットワーク接続を確立し、アプリケーションが同じネットワーク上にあるかのようにOracle Databaseと通信できるようにします。ODBピアリングはAWS環境とOracle環境をつなぎ、ピアリングされたVPCに接続された特定のAWSネットワークサービスを使用してトラフィックがODBネットワークに到達できるようにするルーティング機能をサポートします。次の図は、ピアリングされたVPCとODBネットワークのピアリング関係を示しています。 ピアリングCIDRによるアクセス制御 — ピアリングCIDRは、ネットワークレベルのアクセス制御リスト（ACL）として機能する設定です。ODBネットワーク内のOracle Databaseリソースに到達できるIP CIDR範囲を指定して管理できます。ピアリングされたCIDRを設定すると、Oracle OCI側で自動化が開始され、特定のプロトコルとポート上の特定のCIDRとの間のトラフィックを許可するリソースが存在するOracle Virtual Cloud Network（Amazon VPCと同等のもの）にリンクされたルートルールとセキュリティルールが設定されます。VPC範囲全体ではなく、特定のサブネットCIDRを含めることで、きめ細かなセキュリティ管理が可能になります。ピアリングCIDRとOCI自動化の詳細については、この記事の後半にある考慮事項のセクションを参照してください。 ピアリングされたVPCの使用パターン — ピアリングされたVPCは複数の目的を果たすことができます。ダイレクトアプリケーションVPCとして機能し、専用のOracleワークロードに最もシンプルなネットワークパスを提供します。あるいは、トランジティブルーティングを使用するトランジットVPCとして機能して、Transit GatewayまたはAWS Cloud WANベースのハブアンドスポークアーキテクチャを介して複数のVPCやオンプレミスネットワークからODBネットワークにアクセスできるようにすることもできます。ピアリングされたVPCは、ワークロードをホストするアプリケーションVPCとしても、他のネットワークをODBネットワークに接続するTransit VPCとしても、両方の役割を同時に果たすことができます。 DNSの構成 ODB@AWS は ODB ネットワーク内で DNS を管理し、仮想マシン (VM) クラスターの完全修飾ドメイン名 (FQDN) を作成します。デフォルトでは、これらは *.oraclevcn.com のドメインパターンを使用します（ myhost.oraclevcn.com など、 oraclevcn.com に追加されるプレフィックスをここで指定できます）。別の方法として、独自の完全なドメイン（ myhost.myodb.com など）を使用してカスタムドメイン名を設定することもできます。どちらのドメイン構成を選択したとしても、これらのドメイン名を解決するには、VPCからのDNSクエリをODBネットワークのDNSインフラストラクチャに転送する必要があります。 DNSアーキテクチャは次のコンポーネントで構成されています。 Route 53リゾルバーのアウトバウンドエンドポイント — DNSクエリをVPCからODBネットワークのDNSインフラストラクチャに転送します。ODBネットワークが作成されると、アウトバウンドエンドポイントがネットワークに接続する必要のあるDNSリスナーIPアドレスが提供されます。 転送ルール — アウトバウンドエンドポイントを使用して、Oracleドメイン（ client.xxxxx.oraclevcn.com など）のクエリをODBネットワークのDNSリスナーIPに直接送信します。ルールは正確なドメインとそのサブドメインの両方に一致します（たとえば、ルールが example.com の場合、 example.com と sub.example.com の両方に一致します）。これらのルールは、&nbsp; AWS Resource Access Manager&nbsp;（AWS RAM） を使用してAWSアカウント間で共有し、Oracleドメイン名を解決する必要のあるVPCに関連付けることができます。ドメインマッチングの詳細については、「 Resolver がクエリ内のドメイン名とルールの一致を判断する際の動作 」を参照してください。 次の図では、設定を簡素化し、ピアリングされたODBネットワークに直接接続するために、アウトバウンドエンドポイントがアプリケーションVPC内にデプロイされています。代替の導入オプションと一元化されたDNS管理設計については、この記事の後半で説明します。DNS 設定の詳細な手順については、「 Configuring DNS for Oracle Database@AWS 」を参照してください。 ネットワーク接続パターン このセクションでは、単純な直接接続からスケーラブルなマルチリージョンアーキテクチャまで、ODB @AWS の3つの一般的なネットワーク接続パターンについて説明します。それぞれのパターンは、さまざまなビジネスニーズとスケーリング要件に対応しています。分かりやすくするために、この図にはアカウントレベルのリソース配置は示されていません。各パターンのアカウント配置に関する考慮事項については、次のセクションで詳しく説明します。 接続パターン1：アプリケーションVPCとODBネットワーク間の直接ピアリング このパターンでは、ピアリングされたVPCをアプリケーションVPCとして使用し、ODBネットワークにピアリングされたVPC内でデータベースアプリケーションを直接ホストします。このアプローチは、アプリケーションとデータベース間の最もシンプルなネットワークパスを提供します。 このパターンは、Oracle Databaseが主に単一のVPC内のアプリケーションにサービスを提供する場合に適しています。次の図に示すように、ODBネットワークは単一のアベイラビリティーゾーン（ODBネットワークの作成時に定義される）にバインドされますが、アプリケーションVPCとそのリソースは複数のアベイラビリティーゾーンにまたがることができます。マルチVPCまたはハイブリッドアーキテクチャの場合は、以降のセクションでODBトランジットVPCパターンを検討してください。 ワークフローは次のコンポーネントで構成されています。 アプリケーションVPCの Amazon Elastic Compute Cloud（Amazon EC2） インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。 VPCルートテーブルは、ODBピアリング接続を介してトラフィックをODBネットワークに転送します。 VPC CIDRはピアリングCIDRリストに含まれているので、Oracle OCI側にはこのトラフィックを許可するための設定がされています。応答トラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。 接続パターン2：Transit Gatewayを使用した単一地域のスケーラブル接続 このパターンでは、単一AWSリージョンの大規模なODBネットワークへのネットワーク接続を検討します。2025年9月時点で、ODBネットワークは1つのVPCとのダイレクトピアリングのみをサポートしています。ODBネットワークと複数のVPC間の1対多のピアリング接続はサポートされていません。Transit Gatewayは、複数のVPCとオンプレミスネットワークの相互接続ポイントとして機能する集中型のネットワークコンポーネントです。2025年9月時点では、ODBネットワーク用の組み込みTransit Gatewayアタッチメントはサポートされていません。ただし、次の図に示すように、ODBネットワークを単一のトランジットVPCにピアリングし、そのトランジットVPCをTransit Gatewayに接続することはできます。 このパターンでは、ピアリングされたVPCは（この記事の前半で説明したように）ODBトランジットVPCとしてのみ機能します。ただし、ピアリングされたVPCの使用パターンで強調されているように、ピアリングされたVPCは必要に応じてワークロードを同時にホストできます。 トランジット VPC へのTransit Gatewayアタッチメントは、単一のアベイラビリティーゾーンのみ、具体的には ODB ネットワークが作成されるのと同じアベイラビリティーゾーンで作成する必要があります。これを強調するために、前の図では、アプリケーションVPCの複数のアベイラビリティーゾーンにまたがるワークロードを示しましたが、トランジットVPCのアベイラビリティーゾーン1にはTransit Gatewayしかアタッチされていません。詳細な設定手順については、「 Configuring Amazon VPC Transit Gateways for Oracle Database@AWS 」を参照してください。 ワークフローは次のコンポーネントで構成されています。 アプリケーションVPCのEC2インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。VPCサブネットのルートテーブルが検索され、パケットはTransit Gatewayアタッチメントを使用してTransit Gatewayに転送されます。 関連するTransit Gatewayのルートテーブルには、宛先をトランジットVPCアタッチメントとするODBネットワークCIDRの静的ルートがあります。 トランジットVPCからのトラフィックは、VPCサブネットルートテーブルのODBピアリングルートを使用し、ODBネットワークに転送されます。 VPC CIDRはピアリングCIDRリストに含まれているので、Oracle OCI側にはこのトラフィックを許可するための設定があります。応答トラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。 接続パターン 3: AWS Cloud WANを使用したマルチリージョンのスケーラブルな接続 このパターンでは、複数の地域やオンプレミスネットワークからODBへのネットワーク接続を検討します。AWS Cloud WANは、動的なルート伝播によりマルチリージョン接続を簡素化します。これを使用して、複数の地域のデータセンター・支社・VPCを1つの統合ネットワークに接続することにより、単一のグローバルネットワークポリシーで制御できます。AWS Cloud WANは組み込みのセグメンテーションをサポートしています。つまり、リージョンやオンプレミスの場所全体でネットワークの分離を簡単に管理できます。ネットワークセグメントを使用すると、グローバルネットワークを別々のネットワークに分割できます。詳細については、 AWS Cloud WANユーザーガイド を参照してください。 2025年9月時点では、ODBネットワーク用の組み込みアタッチメントはAWS Cloud WANではサポートされていません。ODBネットワークをトランジットVPCにピアリングし、そのトランジットVPCをAWS Cloud WANコアネットワークに接続することで、AWS Cloud WANを使用して、ODBネットワークと他の複数のVPC間のネットワークトラフィックをリージョンやオンプレミスの場所にルーティングできます。このパターンでは、ピアリングされたVPCは、ピアリングされたVPCの使用パターンに基づいてトランジットVPCとして機能します。AWS Cloud WANコアネットワークへのトランジットVPCアタッチメントが、ODBネットワークと同じ1つのアベイラビリティーゾーンのみで作成されていることを確認する必要があります。 わかりやすくするために、次の図に示すように、ODBネットワークにアクセスする必要があるすべてのアプリケーションVPCをODBアプリケーションVPCセグメントに関連付け、 Direct Connectゲートウェイ をハイブリッドセグメントに関連付け、両方のセグメント間でセグメント共有を有効にすることを示しました。詳細な設定手順については、「 Configuring AWS Cloud WAN for Oracle Database@AWS 」を参照してください。 ワークフローは次のコンポーネントで構成されています。 アプリケーションVPCのEC2インスタンスは、データベースのホスト名を解決してIPアドレスを取得し、このIPを使用してデータベース接続を開始します。VPCサブネットのルートテーブル検索が行われ、パケットはAWS Cloud WAN VPCアタッチメントを使用してAWS Cloud WANコアネットワークに転送されます。 アプリケーションVPC 1は、関連するアタッチメントCIDRが動的に伝達されるODBアプリケーションVPCセグメントに関連付けられています。ODBネットワークへの組み込み接続は現在、AWS Cloud WANではサポートされていないため、トランジットVPC接続を指す静的ルートを作成します。 トランジットVPCからのトラフィックは、サブネットルートテーブルのODBピアリングルートを使用し、ODBネットワークに転送されます。 前のセクションで強調したように、アプリケーションVPCとオンプレミスネットワークに必要なCIDRは、ODBネットワークのピアリングCIDRリストに追加されます。レスポンストラフィックは、元のEC2インスタンスに戻る逆の経路をたどります。 考慮事項 ODB @AWS ネットワーク接続を実装するときは、アーキテクチャの計画と導入を成功させるために役立つ、技術的および設計上の重要な考慮事項に留意が必要です。 ODBネットワークを構築するときは、接続されたネットワークと重複しないCIDRや、使用できない予約済みのIP範囲など、 IPアドレス空間の要件 を考慮してください。これらのCIDR範囲は、ODBネットワークの作成後は変更できません。 ODBピアリングを設定しても、ODBネットワークCIDR（クライアントCIDRまたはバックアップCIDR）のルートは、ピアリングされたVPCルートテーブルに自動的に追加されません。これらのルートをVPCルートテーブルに追加するには、必要に応じて aws ec2 create-route コマンドを手動で実行する必要があります。具体的な AWSコマンドラインインターフェイス（AWS CLI） コマンドについては、「 Configuring VPC route tables for ODB peering 」を参照してください。 VPCとのODBピアリングを設定すると、プライマリVPC CIDRがピアリングされたCIDRリストに自動的に追加されます。ピアリングされたVPCのセカンダリCIDRは手動で追加する必要があります。2025年9月時点では、自動的に追加されたプライマリCIDRを編集して、このVPCの特定のサブネットCIDRに制限することはできません。ACLとして機能するピアリングされたCIDRリストに、データベースとの通信に必要なすべてのソースCIDR範囲を含めてください。 ピアリングされたCIDRリストにエントリが追加されると、接続を容易にするためにOCI側の自動化が行われます。エントリとして追加されたCIDR範囲へのトラフィックを容易にするために、Virtual Cloud Network（Amazon VPCと同等のもの）に関連するルートルール（同等のVPCルートテーブル）に新しい静的ルートが追加されます。さらに、ICMPトラフィック（MTUパス検出とping用）、ポート22のTCPトラフィック（SSH用）、およびデータベーストラフィックに必要なその他のTCPポートを許可するために、Virtual Cloud Networkに関連するセキュリティルール（AWSセキュリティグループおよび同等のネットワークACL）にエントリが追加されます。 Route 53 Resolverのアウトバウンドエンドポイントは、ピアリングされたVPCにデプロイすることも、ネットワーキングチームが管理する別のVPCにデプロイすることもできます。ハイブリッドDNS解決を容易にするためにアウトバウンドエンドポイントがすでに設定されている場合は、それらも使用できます。いずれの場合も、エンドポイントを含むVPC CIDRがODBのピアリングCIDRリストに追加され、エンドポイントVPCとピアリングされたVPCの間に（Transit GatewayまたはAWS Cloud WANを介して）ネットワーク接続が存在することを確認してください。 Route 53プロファイル を使用すると、AWS RAMを使用して個々のルールを直接共有する代わりに、AWSアカウント間で リゾルバールを共有 できます。 2025年9月時点で、Transit GatewayアタッチメントとTransit VPC用のAWS Cloud WANアタッチメントは、1つのアベイラビリティーゾーン、つまり接続用のODBネットワークと同じアベイラビリティーゾーンでのみ作成する必要があります。 マルチリージョン接続は、クラウドWANの代わりにTransit Gatewayのリージョン間ピアリングを使用して実現することもできます。このアプローチでは、ピアリングされたTransit Gateway間の静的ルーティング設定が必要です。 トランジットVPCは、Transit GatewayとAWS Cloud WANの両方、あるいは複数のTransit GatewayやクラウドWANコアネットワークに同時に接続することはできません。接続するには、1つのトランジットサービスを選択する必要があります。 パターン1のアカウント配置では、ODBネットワークは購入者のアカウントにプロビジョニングされ、AWS RAMを使用して複数のアカウントで共有できます。ただし、2025年9月時点では、ODBネットワークに確立できるピアリング接続は1つだけです。つまり、AWS RAMを使用してODBネットワークを別のアカウントと共有し、その共有アカウントのアプリケーションVPCとのODBピアリング接続を作成できるため、アカウント間のアプリケーションを柔軟にデプロイできます。詳細については、「 Resource sharing in Oracle Database@AWS 」を参照してください。 パターン2と3のアカウント配置では、Transit GatewayとAWS Cloud WAN接続を実装する場合、トランジットVPCとODBネットワークの両方が同じAWSアカウント、特にODBネットワークがプロビジョニングされている購入者アカウントに存在する必要があります。ただし、Transit GatewayとAWS Cloud WANは別のアカウント（中央ネットワークアカウントなど）にあり、必要な接続を確立するためにAWS RAMを使用して購入者のアカウントと共有することができます。 こちらの考慮事項で記載している制限は、2025年9月時点のもので、将来変更される可能性があります。 結論 この記事では、Oracle Database@AWS のネットワーク統合機能について説明しました。これは、企業が AWS クラウドで Oracle Exadata データベースの機能をシームレスに拡張するための、堅牢で用途の広いソリューションを提供します。 Oracle Database @AWS は、組織に Oracle Databaseのデプロイメントをより広範な AWS インフラストラクチャやハイブリッド環境に統合するための柔軟なオプションを提供します。ODBネットワークを単一のVPCと直接ピアリングするか、Transit Gatewayを使用して複数のVPCを接続するか、AWS Cloud WANの一元接続を使用するかを選択することで、特定の要件に最適なネットワーク構成を選択できます。 IP に依存しない接続、重複する IP アドレス空間のサポート、または Zero-ETL や Amazon Simple Storage Service（Amazon S3）アクセスなどの特殊な統合を必要とする場合は、「 Amazon VPC Latticeを使った Oracle Database@AWS ネットワーク接続 」を参照してください。 本投稿へのご意見はコメント欄にお願いします。 翻訳はソリューションアーキテクトの 矢木 覚 が担当しました。原文は こちら です。

9 月 18 日、Alibaba の Qwen モデル が Amazon Bedrock に追加されました。今回のリリースにより、Amazon Bedrock は、フルマネージドかつサーバーレスな態様で Qwen3 オープンウェイトの 基盤モデル (FM) へのアクセスを追加することで、 モデルの選択肢を拡大 し続けます。このリリースには、 Qwen3-Coder-480B-A35B-Instruct 、 Qwen3-Coder-30B-A3B-Instruct 、 Qwen3-235B-A22B-Instruct-2507 、 Qwen3-32B (Dense) の 4 つのモデルが含まれています。一体的に、これらのモデルは Mixture-of-Experts (MoE) と高密度アーキテクチャの両方を特徴としており、さまざまなアプリケーション要件に柔軟に対応できます。 Amazon Bedrock は、インフラストラクチャ管理を必要とせずに、統合 API を通じて業界をリードする FM へのアクセスを提供します。複数のモデルプロバイダーのモデルにアクセスし、モデルをアプリケーションに統合して、ワークロード要件に基づいて使用量をスケールできます。Amazon Bedrock では、基盤となるモデルのトレーニングにお客様のデータが利用されることは決してありません。Qwen3 モデルが追加されたことで、Amazon Bedrock は次のようなユースケース向けにさらに多くのオプションを提供します: 拡張コンテキスト理解によるコード生成とリポジトリ分析 ビジネスオートメーションのための複数のツールと API をオーケストレートするエージェンティックワークフローの構築 適応型推論のためのハイブリッド思考モードを使用した、AI のコストとパフォーマンスのバランスの実現 Amazon Bedrock の Qwen3 モデル Amazon Bedrock では現在、次の 4 つの Qwen3 モデルが利用可能です。それぞれ異なるパフォーマンスとコスト要件に合わせて最適化されています: Qwen3-Coder-480B-A35B-Instruct – これは、合計 480B のパラメータと 35B のアクティブパラメータを備えた Mixture-of-Experts (MoE) モデルです。コーディングとエージェンティックタスク向けに最適化されており、エージェンティックコーディング、ブラウザ使用、ツール使用などのベンチマークで優れた結果を達成しています。これらの機能があるため、リポジトリ規模のコード解析やマルチステップワークフローオートメーションに適しています。 Qwen3-Coder-30B-A3B-Instruct – これは、合計 30B のパラメータと 3B のアクティブパラメータを備えた MoE モデルです。コーディングタスクと Instruction Following のシナリオに特化して最適化されたこのモデルは、複数のプログラミング言語にわたるコード生成、解析、デバッグにおいて優れたパフォーマンスを発揮します。 Qwen3-235B-A22B-Instruct-2507 – これは、合計 235B のパラメータと 22B のアクティブパラメータを備えた、Instruction Tuning された MoE モデルです。コーディング、数学、一般的な推論タスク全体で競争力のあるパフォーマンスを提供し、機能と効率のバランスをとっています。 Qwen3-32B (Dense) – これは、32B のパラメータを備えた Dense モデルです。モバイルデバイスやエッジコンピューティングのデプロイなど、一貫したパフォーマンスが重要なリアルタイム環境やリソース制約のある環境に適しています。 Qwen3 のアーキテクチャおよび機能面の特徴 Qwen3 モデルには、アーキテクチャおよび機能面で、いくつかの特徴が導入されています。 MoE と Dense アーキテクチャの比較 – Qwen3-Coder-480B-A35B、Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507 などの MoE モデルは、リクエストごとにパラメータの一部のみをアクティブ化することで、効率的な推論で高いパフォーマンスを実現します。Dense Qwen3-32B はすべてのパラメータをアクティブ化することで、より一貫性があり予測可能なパフォーマンスを実現します。 エージェンティック機能 –&nbsp; Qwen3 モデルは、1 回のモデル呼び出しでマルチステップの推論と構造化プランニングを処理できます。エージェントフレームワークに統合すると、外部ツールや API を呼び出す出力を生成できます。また、これらのモデルは、長時間のセッションにわたって拡張コンテキストを維持します。さらに、外部環境との標準化された通信を可能にするために、ツール呼び出しをサポートしています。 ハイブリッド思考モード – Qwen3 は、思考モードと非思考モードという 2 つのモードをサポートするハイブリッドな問題解決アプローチを導入しています。思考モードでは、ステップバイステップの推論を適用して、最終的な答えを出します。これは、より深い思考を必要とする複雑な問題に最適です。一方、非思考モードでは、深さよりもスピードが重視される、それほど複雑ではないタスクについて、迅速かつほぼ瞬時の応答を提供します。これは、デベロッパーがパフォーマンスとコストのトレードオフをより効果的に管理するのに役立ちます。 ロングコンテキスト処理 – Qwen3-Coder モデルは、ネイティブに最大 256K トークン、外挿法を使用する場合には最大 100 万トークンの拡張コンテキストウィンドウをサポートしています。これにより、モデルはリポジトリ全体、大規模な技術ドキュメント、または長い会話履歴を単一のタスク内で処理できます。 各モデルを使用すべき場合 4 つの Qwen3 モデルは、それぞれ異なるユースケースに対応します。Qwen3-Coder-480B-A35B-Instruct は、複雑なソフトウェアエンジニアリングシナリオ向けに設計されています。高度なコード生成、リポジトリレベルの分析などのロングコンテキスト処理、外部ツールとの統合に適しています。Qwen3-Coder-30B-A3B-Instruct は、コード補完、リファクタリング、プログラミング関連のクエリへの回答などのタスクに特に効果的です。複数のドメインにわたる汎用的なパフォーマンスが必要な場合は、Qwen3-235B-A22B-Instruct-2507 が適しています。MoE アーキテクチャの効率性の利点を活用しながら、強力な汎用推論機能と Instruction Following 機能を提供します。Qwen3-32B (Dense) は、一貫したパフォーマンス、低レイテンシー、コスト最適化が重要なシナリオに適しています。 Amazon Bedrock での Qwen モデルの開始方法 Qwen モデルの使用を開始するには、 Amazon Bedrock コンソール で、ナビゲーションペインの [設定と学習] セクション から [モデルアクセス] を選択します。その後、Qwen モデルに移動してアクセスをリクエストします。ナビゲーションペインの [チャット/テキストプレイグラウンド] セクションでは、プロンプトを使用して新しい Qwen モデルを迅速にテストできます。 Qwen3 モデルをアプリケーションに統合するために、任意の AWS SDK を使用できます。AWS SDK には、Amazon Bedrock の InvokeModel および Converse API へのアクセスが含まれています。また、これらのモデルは、Amazon Bedrock をサポートする任意のエージェンティックフレームワークで使用でき、 Amazon Bedrock AgentCore を利用してエージェントをデプロイできます。例えば、 Strands Agents を使用して構築された、ツールアクセスを備えたシンプルなエージェントの Python コードを次に示します: from strands import Agent from strands_tools import calculator agent = Agent( model="qwen.qwen3-coder-480b-instruct-v1:0", tools=[calculator] ) agent("Tell me the square root of 42 ^ 9") with open("function.py", 'r') as f: my_function_code = f.read() agent(f"Help me optimize this Python function for better performance:\n\n{my_function_code}") 今すぐご利用いただけます Qwen モデルは現在、次の AWS リージョン でご利用いただけます: Qwen3-Coder-480B-A35B-Instruct は、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、東京)、および欧州 (ロンドン、ストックホルム) リージョンでご利用いただけます。 Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507、and Qwen3-32B は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、東京)、欧州 (アイルランド、ロンドン、ミラノ、ストックホルム)、南米 (サンパウロ) の各リージョンでご利用いただけます。 今後のアップデートについては、 詳細なリージョンリスト をご確認ください。インフラストラクチャのセットアップやキャパシティプランニングは不要で、すぐにテストと構築を開始できます。詳細については、 Amazon Bedrock の製品ページ の Qwen と Amazon Bedrock の料金 ページにアクセスしてください。 今すぐ Amazon Bedrock コンソール で Qwen モデルをお試しいただき、 AWS re:Post for Amazon Bedrock または通常の AWS サポートチャネルを通じてフィードバックをお寄せください。 – Danilo 原文は こちら です。

3 月、 Amazon Web Services (AWS) は、 Amazon Bedrock でフルマネージド型の一般提供モデルとして DeepSeek-R1 をリリースし、サーバーレスで DeepSeek-R1 を提供する初のクラウドサービスプロバイダー となりました。それ以来、お客様は Amazon Bedrock を通じて DeepSeek-R1 の機能を活用して、 生成 AI アプリケーションを構築し、Bedrock の堅牢なガードレールと安全な AI デプロイのための包括的なツールの恩恵を受けてきました。 9 月 18 日、 DeepSeek-V3.1 が Amazon Bedrock でフルマネージド基盤モデルとして利用可能になったことをお知らせいたします。DeepSeek-V3.1 は、詳細なステップバイステップの分析のための思考モード (思考連鎖推論) と、より迅速な応答のための非思考モード (直接回答) を切り替えるハイブリッドオープンウェイトモデルです。 DeepSeek によると、DeepSeek-V3.1 の思考モードは、DeepSeek-R1-0528 と比較して、同等の回答品質と優れた結果、複雑な検索タスクのためのより強力なマルチステップ推論、思考効率の大幅な向上を実現します。 ベンチマーク DeepSeek-V3.1 DeepSeek-R1-0528 Browsecomp 30.0 8.9 Browsecomp_zh 49.2 35.7 HLE 29.8 24.8 xbench-DeepSearch 71.2 55.0 Frames 83.7 82.0 SimpleQA 93.4 92.3 Seal0 42.6 29.7 SWE-bench Verified 66.0 44.6 SWE-bench Multilingual 54.5 30.5 Terminal-Bench 31.3 5.7 (c) https://api-docs.deepseek.com/news/news250821 DeepSeek-V3.1 モデルは、ツール使用とエージェントタスクにおいて、トレーニング後の最適化を通じて、以前の DeepSeek モデルと比較してパフォーマンスが大幅に改善されました。DeepSeek-V3.1 は、100 超の言語をサポートし、ほぼネイティブの流暢さを備えており、大規模な単一言語または並列コーパスが不足している、リソースの少ない言語における機能が大幅に改善されています。意思決定プロセスの可視性を維持しながら、以前の DeepSeek モデルと比較して高い精度を提供し、ハルシネーションが軽減されたグローバルアプリケーションを構築できます。 このモデルを使用する主なユースケースを次に示します: コード生成 – DeepSeek-V3.1 は、ソフトウェアエンジニアリングのベンチマークとコードエージェント機能の改善により、コーディングタスクで優れたパフォーマンスを発揮します。そのため、自動コード生成、デバッグ、ソフトウェアエンジニアリングワークフローに最適です。コーディングベンチマークで優れたパフォーマンスを発揮すると同時に、質の高い結果を効率的に提供します。 エージェンティック AI ツール – このモデルは、トレーニング後の最適化を通じてツール呼び出し機能が強化されており、ツール使用とエージェンティックワークフローで優れたパフォーマンスを発揮します。構造化されたツール呼び出し、コードエージェント、検索エージェントをサポートしており、自律型 AI システムの構築に最適な選択肢となっています。 エンタープライズアプリケーション – DeepSeek モデルは、さまざまなチャットプラットフォームや生産性向上ツールに統合されており、ユーザーインタラクションを強化し、カスタマーサービスのワークフローをサポートします。このモデルは、多言語機能と文化面での配慮を備えているため、グローバルなエンタープライズアプリケーションに適しています。 前回の記事 で言及したように、公開されているモデルを実装する場合は、本番環境で実装する際にデータプライバシー要件を慎重に考慮し、出力のバイアスがないか確認して、データセキュリティ、 責任ある AI 、 モデル評価 の観点から結果をモニタリングしてください。 Amazon Bedrock の エンタープライズグレードのセキュリティ機能 にアクセスし、 Amazon Bedrock のガードレール を使用して、アプリケーション要件と責任ある AI ポリシーに合わせてカスタマイズされた安全策を実装できます。また、 Amazon Bedrock モデル評価ツール を使用してモデルを評価および比較し、ユースケースに最適なモデルを特定することもできます。 Amazon Bedrock で DeepSeek-V3.1 モデルの使用を開始する DeepSeek-V3.1 モデルを初めて使用する場合、 Amazon Bedrock コンソール に移動し、左側のナビゲーションペインの [Bedrock の設定] で [モデルアクセス] を選択します。フルマネージド DeepSeek-V3.1 モデルにアクセスするには、 [DeepSeek] セクションで [DeepSeek-V3.1] へのアクセスをリクエストしてください。Amazon Bedrock でモデルにアクセスできるようになります。 次に、Amazon Bedrock で DeepSeek-V3.1 モデルをテストするために、左側のメニューペインの [プレイグラウンド] で [チャット/テキスト] を選択します。その後、左上の [モデルを選択] を選択し、カテゴリとして [DeepSeek] を、モデルとして [DeepSeek-V3.1] を選択します。そして、 [適用] を選択します。 選択した DeepSeek-V3.1 モデルを使用して、技術アーキテクチャの意思決定に関する次のプロンプト例を実行します。 Outline the high-level architecture for a scalable URL shortener service like bit.ly.Discuss key components like API design, database choice (SQL vs.NoSQL), how the redirect mechanism works, and how you would generate unique short codes. [モデル推論] モードを切り替えることで、思考のオン/オフを切り替えて、最終的な結論に至る前に応答の思考連鎖を生成できます。 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK を使用して、モデルにアクセスすることもできます。このモデルは、 InvokeModel と Converse API の両方をサポートします。複数のユースケースとさまざまなプログラミング言語に対応した 幅広いコード例 をご覧いただけます。 詳細については、AWS ドキュメントの「 DeepSeek model inference parameters and responses 」にアクセスしてください。 今すぐご利用いただけます DeepSeek-V3.1 は現在、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (ムンバイ)、欧州 (ロンドン)、欧州 (ストックホルム) の AWS リージョンでご利用いただけます。今後のアップデートについては、 詳細なリージョンリスト をご確認ください。詳細については、 Amazon Bedrock の製品ページの DeepSeek と Amazon Bedrock の料金ページ をご覧ください。 Amazon Bedrock コンソール で DeepSeek-V3.1 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。朝晩の暑さが和らいで秋が近づいてきているのをひしひしと感じていますが、生成 AI 系のアップデートは多数のモデル追加や現場課題に特化したワークショップ開催などアツい話題が盛りだくさんです。 また、来る9/24 には「AWS Amazon Nova Ignite」 が開催されます（ 申し込みはこちら ）。多彩な目的に利用可能な Amazon Nova の実際のお客様活用事例やデモンストレーションが予定されておりますので、ぜひご参加ください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、9 月 15 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 【開催報告】店舗業務にフォーカス！小売業界向け AI エージェント活⽤ワークショップ 」を公開 小売業界の現場課題に特化したAIエージェント活用ワークショップが開催されました。本ワークショップでは、在庫管理の自動化、顧客対応チャットボットの構築、売上予測システムの実装など、店舗運営に直結する実践的なユースケースが紹介されました。参加いただいたお客様からは「店長エージェントの実装を検討する中で、自社ソリューションの組み合わせなど、試したいアイデアが出ました」、「他社の方の事例を聞いたり、小売業界ならではの共通した課題への気づきを得られてかなり勉強になりました」といったお声をいただきました。また、小売業界特有のデータプライバシー要件やリアルタイム処理の必要性についても詳しく解説されており、業界特化型AI導入の実践的なガイドとして価値の高い内容となっています。 ブログ記事「 SAP 対応エージェンティック AI アシスタントを AWS の生成 AI サービスで実現 」を公開 SAPシステムと連携するエージェンティックAIアシスタントの構築方法について解説した記事です。Amazon Bedrock、Amazon Q Business、AWS Lambdaを組み合わせて、SAP内のデータを自然言語で照会・操作できるエージェンティックAIアシスタントの構築方法を詳細に解説しています。従来のSAP操作では専門知識が必要でしたが、このソリューションにより「今月の売上を教えて」「在庫が少ない商品をリストアップして」といった自然な会話でSAPデータにアクセスできるようになります。セキュリティ面では、SAP側の権限管理と連携したアクセス制御も実装されており、企業の機密情報を適切に保護しながらAIの恩恵を受けられる設計となっています。 ブログ記事「 新しい料金プランと新エージェント「Auto」の発表 」を公開 Kiro に新しい料金プランと新エージェント「Auto」が発表されました。この記事では、より柔軟な料金体系と、自動化されたコード生成機能を提供する新しいエージェント機能について詳しく解説しています。各タスクにおいて性能・効率・出力品質を最適化することで、開発者の生産性向上に貢献する機能です。 サービスアップデート Amazon Q Developer が リモート MCP サーバーをサポート Amazon Q Developer がリモート Model Context Protocol (MCP) サーバーをサポートするようになりました。これにより一元化されたサーバーへの移行でコンピューティングリソースの使用量削減とアクセス・セキュリティの適切な管理が可能になります。HTTP対応で、OAuth認証をサポートするAtlassianやGitHubなどのMCPサーバーとの統合も実現しました。 Amazon Lex で生成AI による自然言語処理が8言語で利用可能に Amazon Lex の生成AI機能が日本語を含む8つの言語で新たに利用できるようになりました。多言語対応により、グローバルなチャットボットやボイスアシスタントの構築がより容易になります。この機能はAmazon Connectが利用可能な10のAWSリージョン（欧州、米国、アジアパシフィック、カナダ）で提供されています。 AWS SiteWise で MCP サーバーモデリング機能を提供開始 AWS SiteWise に Model Context Protocol (MCP) サーバーモデリング機能が追加されました。このサーバーは組み込みのドメイン検証機能と自動モデリング機能を備え、APIの詳細知識なしで産業データモデリングを簡素化します。既存のAWS IoT SiteWise機能をサポートしながら、新しい会話型インターフェースも追加しています。産業知識とベストプラクティスが組み込まれており、適切な単位、データタイプ、品質指標が自動適用されるため、産業モデルが最初から生産準備が整い、時間とリソースを節約できます。異常検出や資産オンボーディングの合理化などの高度な機能も容易に実装可能です。 AWS Labs MCPオープンソースリポジトリ からダウンロードできます。 Amazon Bedrock で OpenAI のオープンウェイトモデルが新しいリージョンで利用可能に OpenAI のオープンウェイトモデルを8つの新リージョンに拡張しました。従来の米国西部(オレゴン)に加え、米国東部(バージニア北部)、アジアパシフィック(東京・ムンバイ)、欧州(ストックホルム・アイルランド・ロンドン・ミラノ)、南米(サンパウロ)で利用可能になりました。この拡張により、世界中の顧客はAIモデルへのアクセス性が向上し、レイテンシー短縮とパフォーマンス向上が実現します。 Amazon Bedrock で Qwen3 モデルがフルマネージドサービスとして利用可能に Alibaba Cloud の Qwen3 モデルファミリーが Amazon Bedrock でフルマネージドサービスとして提供開始されました。新モデルには、Qwen3-Coder-480B-A35B-Instruct、Qwen3-Coder-30B-A3B-Instruct、Qwen3-235B-A22B-Instruct-2507、Qwen3-32Bが含まれます。これらは高密度アーキテクチャと専門家混合アーキテクチャを特徴とし、インフラ管理不要で高度なAIアプリケーション構築が可能です。Coderモデルはエージェントコーディングや複雑なソフトウェアエンジニアリングに優れ、235Bモデルは一般的推論に効率的、32Bモデルは幅広い計算タスクに適しています。これらのモデルは米国、アジアパシフィック（東京含む）、欧州、南米の複数のAWSリージョンで利用可能です。 Amazon Bedrock で DeepSeek v3.1 モデルがフルマネージドサービスとして利用可能に DeepSeek v3.1 モデルが Amazon Bedrock で利用できるようになりました。このオープンウェイトモデルは、詳細な思考モードと迅速な非思考モードの切り替え機能を備え、多言語サポートにより精度向上と幻覚軽減を実現しています。 Amazon Bedrock で Stability AI Image Services が一般提供開始 Stability AI Image Services が Amazon Bedrock で一般提供開始されました。このサービスは9つの専用画像編集ツールを含み、アイデアから完成品まで正確かつ柔軟に実現できます。編集ツール（背景削除、オブジェクト消去、検索と置換、色変更）とコントロールツール（構造、スケッチ、スタイルガイド、スタイル転送）の2種類の機能があり、画像の特定部分の編集や既存画像に基づくバリエーション生成が可能です。このサービスは米国西部（オレゴン）、米国東部（バージニア北部、オハイオ）で利用できます。 Meta Llama モデルのオンデマンドデプロイメントが Amazon Bedrock で利用可能に カスタム Meta Llama モデルのオンデマンドデプロイメント機能が追加されました。これにより、特定の用途に最適化されたモデルを事前にコンピューティングリソースをプロビジョニングする必要がなく、使用分のみの支払いでリアルタイム処理が可能となり、コスト削減につながります。 Amazon OpenSearch Serverless でディスク最適化ベクトル機能を提供開始 Amazon OpenSearch Serverless にディスク最適化ベクトル機能が追加されました。この機能により、精度やリコール率を維持しながら、ベクター検索の費用対効果の高いソリューションが提供できるようになります。ユーザーはメモリ最適化とディスク最適化のベクターストレージから選択できるようになり、ディスク最適化オプションでは若干のレイテンシー増加と引き換えに低コストで高品質な検索が可能です。これはミリ秒未満の応答時間が重要でないセマンティック検索やレコメンデーションシステムなどに最適です。 AWS Neuron 2.26 を発表 AWS Neuron の最新バージョン 2.26 がリリースされました。Inferentia および Trainium チップでの機械学習推論とトレーニングの性能がさらに向上しています。新バージョンでは、Flux.1-dev画像生成モデルやLlama 4のバリアントをTrainium2インスタンスにデプロイ可能になり、エキスパート並列処理サポート（ベータ）も導入されました。 Amazon SageMaker HyperPod でオートスケーリング機能を提供開始 Amazon SageMaker HyperPod にKarpenter を利用したオートスケーリング機能が追加されました。機械学習ワークロードの需要に応じて自動的にリソースを調整することで、コスト効率と性能の最適化が実現されます。 Amazon SageMaker HyperPod で Slurm 対応のヘルスモニタリングエージェントを提供開始 Slurmクラスターのジョブ自動再開機能と連携し、障害発生時も最後のチェックポイントから処理を継続できるため、大規模モデルのトレーニングを中断なく何週間も実行可能です。このハンズフリーリカバリー機能により、障害による時間とコストのロスを防ぎます。SageMaker HyperPod を利用可能なすべてのリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近感動したものは帯広の豚丼です。

本記事は 2025年9月4日に公開された Amazon CloudFront now supports IPv6 origins for end-to-end IPv6 を翻訳したものです。 組織が IPv4 アドレス空間の制限を超えるにつれて、IPv6 の採用は世界中で加速し続けています。Amazon Web Services (AWS) では、長い間、エンドユーザーから Amazon CloudFront ネットワークまでについては IPv6 をサポートしてきました。これにより、エンドユーザーがレイテンシーを削減し、パフォーマンスを向上させ、最新のモバイルネットワークにアクセスできるよう支援してきました。今、私たちはそれをさらに一歩進めることができることを嬉しく思います。本日より、CloudFront はエッジからオリジンまで IPv6 接続をサポートするようになり、真のエンドツーエンドの IPv6 配信パスを実現できるようになりました。これにより、エンドユーザーは CloudFront をウェブアプリケーションの IPv6 と IPv4 のデュアルスタックインターネットゲートウェイとして使用し、コンテンツアクセラレーションを実現できます。 なぜこれが重要か？ IPv6 は、最近のほとんどのモバイルネットワークの基盤となるトランスポートプロトコルであり、ブロードバンドトラフィックに占める割合は増加の一途をたどっています。IPv6 をオリジンまで有効化することで、配信チェーン全体でプロトコルの一貫性を維持し、デュアルスタックの複雑さによる運用上のオーバーヘッドを軽減し、より確定的で、オブザーバビリティに優れた、パフォーマンスの高いトラフィックフローを実現できます。CloudFront のエンドユーザーにとって、これらの利点は、ページロードの高速化、ストリーミングの安定化、IPv4 リソースの代替として引き続き機能する配信アーキテクチャにつながります。 CloudFront アプリケーションにおける IPv6 のメリット CloudFront は IPv6 経由のオリジンをサポートするようになったため、エンドユーザーからオリジンサーバーに至るまで、エンドツーエンドの IPv6 接続を実現できます。これにより、従来の IPv4 ベースの配信に比べて、技術面および運用面でさまざまなメリットが得られます。 1. NAT のオーバーヘッドを排除し、パフォーマンスを向上させます IPv4 ネットワークは、ネットワークアドレス変換 (Network Address Translation: NAT)、特に ISP や携帯電話事業者が使用するキャリアグレードの NAT に大きく依存しています。これらの NAT 層は、接続設定の遅延を招き、ポートの可用性を制限し、パケットドロップの原因となる可能性があります。IPv6 では NAT が不要になり、エンドユーザー、CloudFront、オリジン間の直接のエンドツーエンド接続が可能になります。その結果、特に IPv6 の採用が最も多いモバイルファーストの市場では、レイテンシーが減り、ページの読み込みが速くなり、ユーザーエクスペリエンスが向上します。 2. より効率的なパケット処理 IPv6 では、オプションの制御情報として、簡略化された固定長のヘッダーと拡張ヘッダーが導入されています。これにより、ルーター、ファイアウォール、ロードバランサー、CloudFront ノードのパケット解析と転送がより効率的になります。IPv6 は、特にディープパケットインスペクションやトラフィックシェーピングを実行するシステムにおいて、パケットごとの処理オーバーヘッドを削減し、パケット転送や検査中のあいまいさを解消します。ルーターによる経路内でのフラグメンテーションが可能な IPv4 とは異なり、IPv6 はフラグメンテーションの責任をすべてソースホストに委任します。このアーキテクチャ上の制約により、再送信回数が減り、転送パス全体で最適なセグメントサイズが維持されるため、転送パフォーマンスが向上します。その結果、IPv6 では、特に CloudFront とオリジンの間の長距離または高レイテンシーのリンクで、より安定してパフォーマンスの TCP 接続が可能になります。これは、再送信を減らし、トランスポートパス全体で最適なセグメントサイズを維持することによって実現されます。 3. 予測可能な伝送と輻輳制御 IPv6 ではエンドツーエンドのパス MTU 検出 (PMTUD) が実行され、フラグメンテーションの責任はすべてソースホストに委任されます。このアーキテクチャ上の制約により、伝送の予測性が向上し、MTU の不一致によるパケットのドロップやフラグメント化のリスクが最小限に抑えられます。IPv6 は 特に CloudFront と AWS 以外のオリジン間の長距離または高レイテンシーのパスでは、TCP の安定性とスループットを向上させます。これは、再送信を最小限に抑え、エンドツーエンドで最適なセグメントサイズを維持することによって実現されます。AWS オリジンについても、現在、ジャンボフレームサポートなどの AWS バックボーンネットワークを通じて同様の成果が得られています。AWS エッジロケーションと AWS リージョンのアプリケーションエンドポイントの間でジャンボフレームを有効にすると、CloudFront は各パケットでより大きなペイロードを送受信できるようになります。ジャンボフレームのサポートにより、エンドユーザーとアプリケーション間のデータ転送に必要な合計時間が短縮されます。 4. 接続スケーラビリティの向上 IPv4 では、NAT によってオリジン IP アドレスごとに使用できるソースポートの数が減るため、CloudFront ノードがオリジンと同時に確立できる接続の数が制限されます。この制約は、何千もの同時リクエストを効率的に処理しなければならないトラフィックの多い環境では問題になる可能性があります。この機能は、HTTP/2 などのプロトコルを使用する場合に特に役立ちます。このようなプロトコルでは、1 つの接続で複数のストリームを多重化し、接続を再利用することが、パフォーマンスを最大化し、レイテンシーを最小限に抑えるために不可欠です。 開始方法 この度、CloudFront ディストリビューションに関連付けるオリジンとして IPv6 を使用するように設定できるようになりました。この新機能では、IPv4 (デフォルト)、IPv6 、またはデュアルスタック ( IPv4 と IPv6 ) のいずれかを選択できます。既存のオリジンについては、CloudFront は引き続き IPv4 を使用します。デュアルスタックを使用する場合、CloudFront は IPv4 と IPv6 の IP アドレスを自動的に選択して、トラフィックが両方のオリジンで均等に分散されるようにします。 CloudFront コンソールまたは CloudFront API を使用して CloudFront ディストリビューションを作成または更新し、オリジンへの IPv6 接続を設定できます。この投稿では、IPv6 をサポートするオリジンの作成方法を説明し、既存のオリジンで IPv6 を安全に有効化するためのベストプラクティスを探ります。始める前に、オリジンが IPv6 またはデュアルスタック接続をサポートしていることを確認してください。オリジンは、カスタムオリジンでも、 Elastic Load Balancers 、 Amazon API Gateway 、 AWS Lambda の関数 URL などの IPv6 をサポートする AWS サービスでもかまいません。 IPv6 オリジンを使用した新規 CloudFront ディストリビューションの作成 CloudFront コンソールで、CloudFront ディストリビューションの作成を選択します。 Step 1: Get started ディストリビューション名を入力し、その他のオプションパラメータを入力してから、 [Next] を選択してステップ 2 に進みます。 Step 2: Specify origin オリジンのタイプを選択し、オリジン情報を入力します。IPv6 を設定するには、 Setting パネルで [customize origin settings] を選択します。 オリジン IP アドレスタイプ設定に IPv6 または Dualstack を選択し、 [Next] を選択します。 Step 3: Enable security AWS WAF を有効にしてアプリケーションを保護し、 [Next] を選択します。 Step 4: Review and create 設定内容を確認したのち、 [Create distribution] ボタンを選択し、ディストリビューションを作成します。 既存の CloudFront ディストリビューションに新規の IPv6 オリジンを追加する 既存の CloudFront ディストリビューションに新しい IPv6 オリジンを追加するには、ディストリビューションを選択してディストリビューション設定を開き、 [Origins] タブを選択して [Create Origin] を選択します。 [Additional settings] を展開し、Origin IP address type で [IPv6] または [Dualstack] オプションを選択して、オリジンへの IPv6 接続を有効にします。オリジンを作成したら、新しいオリジンを指すようにビヘイビアを追加または更新します。 既存のオリジンで IPv6 を有効化する CloudFront 継続的デプロイ を使用すると、変更をオリジン設定に安全に移行できます。CloudFront 継続的デプロイでは、デプロイポリシーを使用してリクエストをステージングディストリビューションにルーティングし、変更を検証してプロモートすることで、変更を安全にテストできます。このアプローチの詳細については、CloudFront の ドキュメント を参照してください。 オリジンへの IPv6 接続の検証 メトリクスまたはアプリケーションログを使用して、オリジンでの IPv6 トラフィックを検証します。このケースでは、オリジンとして Application Load Balancer (ALB) を使用し、IPv6 Requests メトリクスを使って検証しました。 まとめ モバイルネットワークやグローバルネットワークで IPv6 の採用が拡大するにつれて、エンドユーザーから Amazon CloudFront、そしてオリジンに至るまで、エンドツーエンドの IPv6 を有効にすることで、IPv4 では対応できないパフォーマンスとアーキテクチャ上の利点が得られます。NAT のオーバーヘッドがなくなり、ルーティングとフローの可視性が向上し、固定ヘッダーと信頼性の高い パス MTU 検出によってパケット処理が合理化されます。CloudFront は IPv4 と IPv6 の両方に最適化されていますが、IPv6 の利点は配信のファーストマイル、 ラストマイルで最も顕著になります。IPv6 をエンドツーエンドで採用することで、スケーラブルで高性能で、将来を見据えたコンテンツ配信の基盤が築かれます。 Amazon CloudFront で IPv6 をエンドツーエンドで有効にすることはもはやオプションではありません。これは、レイテンシーの低減、耐障害性の向上、将来を見据えたスケーラビリティを実現するための基本的なステップです。まだ CloudFront ディストリビューションの IPv6 サポート を有効にしていない場合は、今すぐ IPv6 サポートを有効にしてください。 翻訳は Solutions Architect の山本 大貴が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 つい先週、趣味のパデルで、右手を骨折してしまいました。スポーツや仕事がしにくく、こういう時は大人しく過ごそうということで、最近出版された「 AWS 生成 AI アプリ構築実践ガイド 」を購入して読み始めました。Amazon Bedrock Agents／Amazon Bedrock AgentCore についても記載され、内容も充実しており、参考になる一冊です。読書の秋にじっくり AWS を学んでみるのはいかがでしょうか。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年9月15日週の主要なアップデート 9/15(月) AWS Organizations がメンバーアカウントのアカウント状態情報を提供開始 AWS Organizations で新しい State フィールドが追加され、メンバーアカウントの状態をより詳細に把握できるようになりました。従来の Status フィールドでは分からなかった「AWS による強制停止 (SUSPENDED)」「クローズ処理中 (PENDING_CLOSURE)」「クローズ済み (CLOSED)」などの細かい状態が確認可能です。複数のアカウントを管理する組織では、各アカウントの正確な状況を把握することで適切な対応が取れるようになります。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock でカスタム Meta Llama モデルのオンデマンドデプロイメントを発表 Amazon Bedrock で、カスタマイズした Meta Llama 3.3 モデルのオンデマンドデプロイメントが可能になりました。従来は常時稼働するサーバーが必要でしたが、今回のアップデートにより使用時のみリソースを起動し、利用分だけの支払いでコストを大幅削減できます。AI チャットボットや文書生成システムなど、利用頻度が不定期なアプリケーションに最適です。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker HyperPod が Slurm クラスターのヘルスモニタリングエージェントサポートを発表 Amazon SageMaker HyperPod の Slurm クラスターでヘルスモニタリングエージェント機能が利用可能になりました。この機能は GPU や Trainium ノードの状態を常時監視し、ハードウェア障害を検出すると自動的にノードを交換します。従来は訓練中に障害が発生すると手動対応が必要でしたが、今回のアップデートにより自動レジューム機能と連携してチェックポイントから訓練を継続できるようになりました。大規模言語モデルなど数週間かかる訓練でも中断リスクを大幅に軽減し、コストと時間のロスを削減できます。詳細は こちらのドキュメントをご参照ください。 9/16(火) Amazon OpenSearch Service が Star-Tree Index を発表 Amazon OpenSearch Service で Star-Tree Index という新機能が利用開始となりました。この機能により、大量データの集計処理が大幅に高速化され、従来時間がかかっていた複雑な分析クエリもサブ秒で応答できるようになります。データを事前に集計して保存するため、リアルタイムダッシュボードや監視システム、パーソナライゼーション機能などで威力を発揮します。詳細は こちらのドキュメントをご参照ください。 Amazon S3 が汎用バケットで条件付き削除をサポート開始 Amazon S3 の汎用バケットで条件付き削除機能が追加されました。HTTP if-match ヘッダーと ETag を使用し、オブジェクトが変更されていない場合のみ削除を実行できます。複数のユーザーが同時にファイルを操作する環境で、誤ってファイルを削除してしまうリスクを大幅に軽減できます。従来は削除前にオブジェクトの状態を確認する仕組みがなく、競合状態での誤削除が課題でした。全リージョンで追加コストなしで利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Lex が 8 つの新しい言語で生成 AI ベースの強化された自然言語理解を提供 Amazon Lex が大規模言語モデル (LLM) を活用した自然言語理解機能を日本語を含む 8 つの新言語で提供開始しました。これまでチャットボットが理解しにくかった複雑な発話や、スペルミスがある入力でも正確に処理できるようになります。例えば「妻と子供 2 人と私でフライト予約したい」と話すと、4 人分の予約として正しく理解してくれます。東京リージョンなど 10 の商用リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 9/17(水) AWS Network Firewall がコンソール、モニタリング、セキュリティ機能を強化 AWS Network Firewall で監視機能とセキュリティ機能が強化されました。監視ダッシュボードでは Amazon S3 や DynamoDB などの AWS サービスへのトラフィック状況を詳細に可視化でき、IP アドレス別やプロトコル別の分析も可能になります。また新しい TLS Inspection のセッションホールディング機能により、悪意のある接続先への通信をより確実にブロックできるようになりました。詳細は こちらのドキュメントをご参照ください。 AWS Budgets でカスタム期間がサポートされるようになりました AWS Budgets でカスタム期間の予算設定が可能になりました。従来の月次や四半期などの固定期間ではなく、任意の開始日と終了日を指定できます。月の途中から始まる 3 ヶ月プロジェクトなども一つの予算で管理でき、複数月に分けて計算する手間が不要になりました。詳細は こちらのドキュメントをご参照ください。 9/18(木) Qwen3 モデルが Amazon Bedrock で完全マネージド型として利用可能になりました Amazon Bedrock に Qwen3 モデル 4 種類が追加されました。コーディング特化の Coder モデルや汎用推論用モデルなど、用途に応じて選択できます。インフラ管理が不要なフルマネージドサービスとして提供されるため、AI アプリケーション開発に集中できます。東京リージョンを含む複数リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 OpenAI オープンウェイトモデルが AWS Bedrock で新しいリージョンに拡張 AWS Bedrock で OpenAI のオープンウェイトモデルが 8 つの新リージョンに拡大しました。東京、ロンドン、ムンバイなど世界各地で利用可能となり、これまでオレゴンリージョンのみだった制限が解消されます。ユーザーに近いリージョンでの実行により、レイテンシが大幅に改善され、AI アプリケーションの応答速度が向上します。また、データ所在地の要件に対応でき、コンプライアンスを重視する企業でも安心して活用できます。詳細は こちらの Blog 記事をご参照ください。 DeepSeek-V3.1 モデルが Amazon Bedrock でフルマネージドサービスとして利用可能に Amazon Bedrock で DeepSeek-V3.1 モデルが利用可能になりました。このモデルは詳細分析用の thinking モードと高速応答用の non-thinking モードを切り替えできるのが特徴です。従来モデルと比較してハルシネーション (誤った情報生成) が減少し、精度が向上しています。ソフトウェア開発や数学的推論、データ分析などの業務で活用でき、 AI エージェント構築やプロセス自動化にも最適です。オレゴン、東京、ムンバイ、ロンドン、ストックホルムリージョンで提供開始されています。詳細は こちらの Blog 記事をご参照ください。 Stability AI Image Services が Amazon Bedrock で利用可能に Amazon Bedrock で Stability AI Image Services が利用開始となりました。背景除去やオブジェクト消去など 9 つの画像編集ツールが使えるようになり、API 経由で高度な画像加工が可能です。従来は専用ソフトが必要だった画像編集作業を、クラウドサービスで簡単に自動化できるため、EC サイトの商品画像作成やマーケティング素材の制作が効率化されます。オレゴン、バージニア北部、オハイオリージョンで提供中です。 Amazon Q Developer CLI がリモート MCP サーバーのサポートを発表 Amazon Q Developer CLI がリモート MCP サーバーのサポートを開始しました。従来はローカルでの MCP サーバー利用が中心でしたが、今回のアップデートによりリモートサーバーを活用できるようになり、計算リソースの削減とセキュリティ管理が向上します。Atlassian や GitHub などの外部サービスとの統合も可能で、OAuth 認証による安全な接続を実現します。詳細は こちらのドキュメントをご参照ください。 9/19(金) AWS が簡素化されたモデリングのための SiteWise MCP Server を発表 AWS が AWS IoT SiteWise 向けの MCP (Model Context Protocol) サーバーをオープンソースで公開しました。このサーバーは産業データのモデリング作業を大幅に簡素化し、従来必要だった複雑な API 知識がなくても会話型インターフェースで直感的に操作できるようになります。産業分野の専門知識が内蔵されており、適切な単位やデータ型を自動で適用するため、手作業での調整や修正作業が不要になり開発時間を大幅に短縮できます。詳細は こちらの GitHub リポジトリをご参照ください。 AWS Neuron SDK 2.26.0 の発表 AWS Neuron SDK 2.26.0 が一般提供開始となりました。この SDK は Inferentia や Trainium インスタンスで機械学習モデルを効率的に実行するためのツールです。今回のアップデートでは PyTorch 2.8 や JAX 0.6.2 といった最新フレームワークに対応し、画像生成モデル FLUX.1-dev や大規模言語モデル Llama 4 の新バリアントを Trn2 インスタンス上で実行できるようになりました。特に注目すべきは Expert parallelism サポート (beta) により、複雑な MoE モデルを複数の NeuronCore に分散して効率的に処理できる点です。詳細は こちらのドキュメントをご参照ください。 最後にイベントのお知らせです。2025年10月9日（木）19:00-「10 周年を迎えた AWS IoT Core – 過去を振り返り、未来を見据えて」というテーマで、目黒セントラルスクエア現地のみのイベントを開催いたします。詳細、お申し込みは こちら 。AWS が 2015 年の re:Invent で IoT 向けのサービスを発表してから 10 年が経ちました。この記念すべき節目を迎え、IoT を取り巻く環境の劇的な変化を振り返るとともに、未来への展望を共有する特別なイベントとなります。お客様セッションやネットワーキングもご用意がございます。私も参加いたしますので、ぜひお声掛けください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料食品やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

この記事は 2025 年 8 月 27 日公開の韓国語記事 래빗 워크의 제작 혁신 を翻訳したものです。 Rabbit Walks Inc.（以下ラビット ウォークス）は、2010 年に設立された特殊映像専門会社で、世界初の立体テレビコンテンツ制作を皮切りに業界をリードしてきました。サムスン電子、LG、現代自動車などグローバルブランドとコラボレーションし、高画質デモコンテンツやインタラクティブ展示コンテンツなどを制作してきており、CES、IFA、ISE、Infocomm などの世界的な展示会でも技術力を認められている韓国の代表的な VFX 産業基盤の会社です。 約 75 人のメンバーで構成されたラビット ウォークスは、企画、演出、デザイン、作曲などコンテンツ制作の全行程を自社内で遂行できる「オールインワン」の組織構造を備えています。これらの「ワンストップソリューション」の能力は、迅速な意思決定と創造的なアイデアの即時実装を可能にしますが、同時にプロジェクトが集中すると、コンピューティングリソース、特にレンダリングパワーの需要が爆発的に増加する要因にもなります。 特にリアルタイムゲームエンジンベースのレンダリングのない CG コンテンツ制作技術をもとに、ライブ放送とストリーミング環境に最適化された VFX ワークフローを運営しており、最近では AI 技術を活用した高画質広告コンテンツやデジタルヒューマン制作まで商用化に成功しました。このように最先端技術を積極的に導入する過程で、AI モデルの学習や高解像度の最終結果出力など、既存のリアルタイムワークフローを補完する大規模なプリレンダリング作業の必要性が出てきました。 次世代製品の開発段階から、お客様と協力してインターフェースや視覚化コンテンツを共に開発する「先行開発コンテンツ」分野でも強みを見せ、AR ガラス、透明 OLED、ホログラムディスプレイ、モジュラーディスプレイなど未来型デバイスに最適化されたコンテンツを継続的に披露しています。 2025 年には欧州進出を本格化し、イタリアのミラノに法人を設立し、今後はパリおよびミラノオリンピック関連プロジェクトの実施を準備中です。 このようなグローバル展開と超大型 / 超高画質プロジェクトは予測不可能な規模のレンダリング需要を生み出し、既存の固定オンプレミスインフラだけでは対応し難い課題をもたらします。 超大型 / 超高画質サイネージ、空間演出、ホログラムコンテンツなど、次世代インタラクティブメディア領域においても継続的な技術投資と研究開発を続けています。 Deadline Cloud レンダーファームプロジェクトの背景 ラビット ウォークスは、最先端の技術力と芸術性を組み合わせてメディア業界の新しい基準を提示してきました。特に AI 技術の融合、18K 以上の超高解像度コンテンツ制作、グローバルプロジェクトの遂行など、ビジネスの成功拡大は、既存のオンプレミスインフラに新たな課題をもたらしました。これらの背景の中で、ラビット ウォークスは将来の成長を支える柔軟で強力なレンダリング環境を構築するためクラウド導入を決定し、そのコアソリューションとして AWS Deadline Cloud を選択しました。 この過程で、レンダーファームの技術と多様なコンピテンシー能力を保有している AWS のパートナーである Megazone Cloud は、AWS Deadline Cloud の設計から技術サポートまで、全方位的なパートナーシップを提供し、ラビット ウォークスがより安定的で柔軟なコンテンツ制作環境を確保する上で重要な役割を果たしました。 当初の課題 現在、ラビット ウォークスは約 50 台規模の高性能 GPU（RTX 3080Ti 以上）で構成された社内レンダーファームを運用しています。これは十分に強力な設備ですが、ビジネスの爆発的な成長の中で、次のような「成長痛」を経験していました。 リソースの非効率的な割り当て: レンダリング作業中に複数の GPU リソ​​ースが 4 または 10 単位の固定グループに割り当てられる構造のため、30 人を超えるアーティストが同時に作業を進行するときに余剰リソースが発生するにもかかわらず、特定のワークグループでボトルネックが発生する問題がありました。これはアーティストの待ち時間を増やし、全体的な生産性を低下させる主な原因でした。 予測不可能な需要に対する対応が困難： 最近 4K を超えて 8K、18K 以上の超大型プロジェクトの受注が増加し、レンダリングに必要なコンピューティングパワーが指数関数的に増加しました。特定のプロジェクトの締切が差し迫ったとき、瞬間的に通常の数倍に達するレンダリングリソースが必要でしたが、物理的に限られたオンプレミスファームではこれらのピーク需要にすぐに対応できませんでした。 膨大な増設費用と将来の不確実性： これらの問題を解決するためにレンダーファームの増設を検討しましたが、GPU 端末 1 台に数千万ウォンに達する膨大な初期投資費用が負担となりました。さらに重要な問題は、将来のプロジェクト規模と必要な GPU 仕様を予測するのが難しいということでした。今すぐ巨額を投資して増設しても、1～2 年後にはより高性能な GPU が必要になるか、逆にプロジェクトがない期間には高価な機器の余剰が発生する可能性がありました。 レンダーファーム増設の難しさ これらの問題に対処するためにレンダーファームの増設を検討しましたが、1 台の機器を増設するには少なくとも 4000 万ウォン以上の費用がかかります。これは短期的な解決策には適しているかもしれませんが、会社の継続的な成長と従業員の増加に比例したレンダーファームの確保には根本的な限界があります。 既存の選択肢の限界と新しい基準の必要性 ラビット ウォークスは、オンプレミスの増設に加えて、他の代替案も慎重に検討しました。 短期での機器のレンタル： 外部機器を借りる方法は作業に比べて費用対効果が低く、機器の設置や撤退の過程に別々の管理人員と時間が投入される運営上の負荷が高い。 オンラインレンダーファームサービス： 従来の商用オンラインレンダーファームサービスは、間欠的なエラーが発生した場合、即時の技術サポートが困難であり、特に大規模なプロジェクトを長期的に進める場合、予測するのが難しいコスト構造のために実質的な代替策になり得なかった。 このように、既存の代替案の明確な限界は、ラビット ウォークスがレンダリングインフラストラクチャの新しい基準を確立することになったきっかけになりました。必要なのは単により多くのコンピューティングパワーではありませんでした。 必要に応じてすぐに使用できる「弾力性」 使用した分だけ費用を支払う「経済性」 複雑な設定なしでアーティストが創作に集中できるようにする「シンプルさ」 信頼できる技術サポートが保証される「信頼性」 この 4 つの基準が次世代レンダリング環境には重要な要件でした。 レンダリング環境改善の取り組みにおける選択 これまでの社内のレンダリング設備には限界があり、外部への代替え案も効率的とは言えない状況です。一方で、制作プロジェクトは増加の一途をたどり、作品の品質要求も高度化しています。この状況に対応するためには、安定性と拡張性を備えた新しいレンダリング環境が必要です。そこで私たちは、効率的なリソース管理が可能で、将来の需要増加にも柔軟に対応できるAWS Deadline Cloudの導入を決定しました。 クラウドレンダーファーム導入過程と当初の技術的課題 AWS Deadline Cloud 導入戦略の策定 ラビット ウォークスの既存のオンプレミス環境と要件を分析した結果、AWS Deadline Cloud が最適なソリューションと判断されました。しかし、既存のワークフローとの互換性、アーティストの学習曲線、そして多様なレンダリングエンジンのサポートなど解決しなければならない課題がありました。 そのため、Magazone Cloud とともに段階的導入戦略を策定し、リスクを最小限に抑えながら実質的な成果を確認できるロードマップを設計しました。 導入ステップ 1：SMF (Service Managed Fleet) 環境の構築と初期テスト 期間：2024 年 10 月 20 日～ 2024 年 11 月 13 日 目標：AWS Deadline Cloud の基本機能の検証と既存のワークフローとの互換性を確認 構成環境： レンダリングソフトウェア： Houdini 19.5 レンダリングエンジン: Mantra 制限事項： Cinema4D および Redshift の UBL (Usage-Based Licensing) 未サポート (2024年当時の状況。現在はサポート済み) 主な成果： AWS Deadline Cloud の基本アーキテクチャとジョブ送信プロセスの理解 クラウド環境におけるレンダリングパフォーマンスベースラインの確保 ネットワーク帯域幅とファイル転送最適化方式の導出 当初の技術的課題： ライセンス管理の複雑さ &nbsp;既存のオンプレミスライセンスとクラウド環境間の互換性の問題 UBL 方式のライセンス未サポートによるソフトウェア制約 ネットワーク最適化の必要性 大容量 3D アセットファイルのアップロード/ダウンロード時間の問題 社内ネットワーク帯域幅制約の特定 ワークフローの標準化 既存のパイプラインとクラウド環境間の統合方式が必要 導入ステップ 2：パフォーマンスの最適化と GPU タイプの選択 期間：2025 年 3 月 ～ 2025 年 4 月 目標：Cinema4D ワークロードに最適化された GPU インスタンスタイプの選択 テスト方法論： 実稼働プロジェクトと同じ条件でベンチマーク操作を実行 さまざまな EC2 GPU インスタンスタイプによるパフォーマンスとコスト効率の比較分析 レンダリングの複雑さに応じた最適なインスタンス構成の導出 性能テスト結果： インスタンスタイプによるパフォーマンス比較： G4dn.xlarge：基本的なパフォーマンスベースライン G5.2xlarge：約 40％ の性能向上 G6.12xlarge：約 75％ の性能向上 (最終選定) コスト効率分析： 純粋なレンダリング時間に対して約 60％ のコスト削減 プロジェクトターンアラウンド時間 90％ 以上短縮 技術的な洞察： NVIDIA RTX A10G ベースの G5 インスタンスが Cinema4D + Redshift の組み合わせで最適なパフォーマンスを発揮 メモリ集約型タスクでは、G6インスタンスの優れたGPUメモリ効率の確認 Spot インスタンスを活用した場合の追加で 30% コスト削減の可能性の確認 導入ステップ3 ： CMF (Customer Managed Fleet) の移行と本格的な運用 期間：2025 年 5 月 15 日～現在 目標：完全な実稼働環境の構築とスケーラブルなワークフローの完成 主な改善点： オペレーティングシステムの最適化 &nbsp;Linux ベースのレンダリング環境に切り替える コンテナベースのワークフロー導入により環境一貫性を確保 ライセンス管理の改善 Cinema4D と Redshift のクラウド互換ライセンスを取得 動的ライセンス割り当てシステムの構築 自動化と監視 &nbsp;CloudWatch によるリアルタイムレンダリングジョブの監視 自動スケーリングポリシーの最適化 運営上の課題と解決策： 課題 1：アーティストの教育と適応 解決策：段階的教育プログラムの運営 既存のワークフローと同様の UI/UX を提供 専門技術支援チームの運営 課題 2：ハイブリッド環境管理 解決策：オンプレミスとクラウド間の作業優先度、自動判断ロジックの実装 統合ダッシュボードによる完全なリソースの可視性の確保 課題 3：コスト最適化 解決策： 作業パターン分析に基づく予測スケーリング Reserved Instance と Spot Instance の混合での活用 リアルタイムコスト監視と通知システムの構築 導入の過程で得た主な教訓 段階的な移行の重要性 段階的導入をすることでリスク最小化と学習効果を最大化 各段階的なパフォーマンス測定による継続的な改善 技術パートナーシップの価値 パートナー Megazone Cloud の専門性が導入期間の短縮と安定性確保に決定的に貢献 24 時間 365 日の技術支援による運用安定性の確保 柔軟な管理の重要性 アーティスト中心でユーザー体験を設計 十分な教育と段階的な移行で現場のストレスを最小限に抑える 以上の体系的な導入プロセスにより、ラビット ウォークスは本番環境に AWS Deadline Cloud を統合することができました。 テスト環境とワークロード &lt;Deadline Cloud Rendering Architecture&gt; レンダリング内容 解像度：8880 x 1890 (Ultra-wide 4K) レンダリングフレーム数：91 フレーム 事前予想コスト：ハイパフォーマンスレンダリングに ＄880 以上と予測 テストインフラストラクチャの構成 オンプレミス環境 (ローカルPC) GPU：NVIDIA RTX 3080 Ti 4 台構成 1 フレームのレンダリング時間：約 32 分 総レンダリング時間：約 12 時間 8 分 AWS Deadline Cloud 環境 インスタンスタイプ：G6.12xlarge (GPU 最適化タイプインスタンス) テスト構成：1 回目、2 回目、3 回目スケーリングテスト &lt;Deadline Cloud Monitoring Dashboard&gt; 性能比較結果 レンダリング時間の最適化 AWS Deadline Cloud のスケーリング効果がはっきりと現れました。 構成 1 フレーム レンダリング 時間 総 レンダリング 時間 パフォーマンス の向上 ローカルPC (RTX 3080 Ti x4) 32 分 12 時間 8 分 基準 Deadline Cloud 1 回目 15 分 30 秒 47 分 50 秒 93％ 短縮 Deadline Cloud 2 回目 8 分 9 秒 39 分 23 秒 95％ 短縮 Deadline Cloud 3 回目 16 分 1 時間 4 分 91％ 短縮 コアパフォーマンス 劇的なパフォーマンス向上 最適構成（2 回目テスト）で総レンダリング時間を 12 時間から 39 分に 95％ 短縮 シングルフレームレンダリング時間を 32 分から 8 分 9 秒に 75% 改善 弾力的な拡張性 ワークロードに応じた動的なリソース割り当てによるコスト効率の最大化 ピークタイムゾーンの自動スケーリングによるボトルネックの除去 ネットワーク伝送の最適化 ファイル転送性能 アップロード：レンダーファーム→Dropbox 約 7-8 分（テスト自動化環境） ダウンロード：Dropbox →ローカル 約 40 分 ネットワーク最適化: 社内帯域幅の制約が主なボトルネックとして特定 技術的な洞察 ワークロード分散の効率性 AWS Deadline Cloud の自動分散機能により、91 フレームを複数インスタンスに最適に配分して処理時間を大幅に短縮しました。 GPU リソースの活用 G6.12xlarge インスタンスの高性能な GPU は、複雑な 3D レンダリングにおいてオンプレミス環境と比べて優れたパフォーマンスを示しました。 費用対効果 初期予想コスト $ 880 と比較して、実際のクラウドレンダリングのコスト効率と時間短縮による運用コスト削減が証明されました。 結論 ラビット ウォークスとのコラボレーションにより、AWS Deadline Cloud は既存のオンプレミスレンダーファームと比較して次の重要な価値を提供することを確認しました。 パフォーマンス：最大 95％ のレンダリング時間を短縮 スケーラビリティ：プロジェクトの規模に応じた柔軟なリソース拡張 コスト効率：使用した分だけ支払うモデルで運用コストを最適化 管理の利便性：インフラ管理負担の除去 今回のテスト結果は、3D レンダリングスタジオがクラウド移行を通じて得られる実用的なビジネス価値を明確に示すとともに、AWS Deadline Cloud が現代のメディア制作ワークフローにおけるコアソリューションであることを実証しました。 Deadline Cloud 以外で今回追加した実装部分について ラビット ウォークスは、アーティストのリモート作業環境をサポートするために、 Amazon Elastic Compute Cloud (Amazon EC2) &nbsp;と Amazon DCV を活用したワークステーションの設定も行いました。一方で、アーティストは AWS コンソールを介した EC2 サーバーの管理に精通していなかったため、 Amazon Cognito 、 Amazon CloudFront 、 Amzazon Simple Storage Service (Amazon S3) 、 Amazon API Gateway を組み合わせてサーバーレスベースのリモートサーバー管理ページを個別に構築しました。これにより、アーティストは簡単に EC2 のクラウドワークステーションを管理できるようになり、リモートサーバーを使用して社内ネットワークから AWS Deadline Cloud へのアップロード速度も大幅に向上しました。また、必要に応じて高性能なサーバーに簡単に切り替えができ、作業効率を高めるとともに、運営およびメンテナンスへの負担も軽減できる環境を整えました。 &lt;Rabbitwalks Renderfarm Process Architecture&gt; 作業結果のパフォーマンスについて 今回のプロジェクトでは AWS Deadline Cloud を導入したことで、オンプレミス環境では締切までの完成が難しかったスケジュールをこなすことできました。 特に、当日午前に要求された修正を反映した映像を同日午後までに提供できることは、従来の環境ではほぼ不可能なことでしたが、AWS Deadline Cloud を活用することで、厳しい作業スケジュールにも安定した映像の提供ができるようになりました。 従来のオンプレミス環境では、1 フレームのレンダリングに約 32 分かかりましたが、AWS Deadline Cloud レンダーファームを利用した結果、15～16 分に大幅に短縮できました。 &lt;Rabbitwalks Renderfarm Architecture&gt; Deadline Cloud導入後のプラン ラビット ウォークスは AWS Deadline Cloud を活用し、高速かつコスト効率の高いレンダリング環境を実現しました。これにより、プロジェクトごとに必要なリソースを柔軟に活用できる体制を整えています。 今後は、ワークロードのクラウド移行を進めることで、災害対策 (DR) の強化、映像データの迅速な運用、そして GenAI を用いた企画・制作プロセスの効率化を目指しています。こうした取り組みによって、最終成果物の完成までのスピードを加速させ、新しい映像制作のスタイルをいち早く実現し、ビジネスの成長につなげていきます。 パク・チャンモク、ラビット ウォークス 3D チームリーダー パク・チャンモクは現在、ラビット ウォークスでチームリーダーとして、様々なプロジェクトを率いています。R&amp;D 部門で新しい技術とワークフローを実験する役割として、Houdini、Cinema 4D、Unreal Engine、Redshift などのツールを活用したコンテンツ制作に集中しています。最近では、クラウドベースのレンダリング環境を構築し、生成 AI と機械学習技術を視覚芸術分野に融合する研究を通じて、新しい表現方式と制作方式を模索しています。 キム・ユンスク、Megazone Cloud メディアスペシャルチーム キム・ユンスク Megazone Cloud メディアユニットクラウドテック担当者は、メディア・VFX 顧客のクラウド基盤制作環境の構築を支援しており、プレセールスエンジニアとして顧客カスタマイズ型アーキテクチャ設計及びコンサルティングを通じて実質的な技術転換を導いています。 アンテヨン、Megazone Cloud メディアユニットクラウドセールス アンテヨン Megazone Cloud メディアユニットクラウドセールス担当者は、 メディア・VFX 業界のお客様が AWS クラウドをベースに制作効率と技術競争力を確保できるように、インフラストラクチャの提案とクラウド移行を支援しています。 チョウ・ボラエ チョウ・ボラエは AWS のシニアソリューションズアーキテクトで、ビジュアルコンピューティングの分野を担当しています。スタジオ制作プロセスの技術に対する豊富な経験に基づき、生成 AI とエージェント AI の分野で革新的な作業を進めています。 ソ・ダンヒ ソ・ダンヒ (AWS Cloud Sales Rep) は、AWS カスタマーのデジタルイノベーションとビジネス成長のための信頼できるパートナーになることを目指しています。具体的には、お客様が AWS クラウドを効果的に活用してビジネス目標を達成できるように、統合的なクラウド旅行をサポートしています。 <!-- '"` --> カン・スンウク カン・スンウク Solutions Architect は、長年のバックエンド開発経験に基づいて、スタートアップからエンタープライズまで、さまざまな顧客の AWS ベースのワークロード実装をサポートしています。現在、CSC チームで迅速なイノベーションを推進する企業に、スケーラブルな技術ソリューションとアーキテクチャガイダンスを提供し、顧客のデジタル転換とクラウドの旅を加速する役割を担っています。 本記事は、 2025 年 8 月 27 日公開の韓国語記事 래빗 워크의 제작 혁신 を翻訳したものです。 翻訳は Sir. Visual Compute Specialist Solutions Architect の森が担当しました。 参考リンク AWS Media Services AWS Media &amp; Entertainment Blog (日本語) AWS Media &amp; Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

本記事は米国時間 2025 年 9 月 15 日に公開された Announcing new pricing plans and Auto, our new agent を翻訳したものです。 Kiro は 9 月 30 日まで引き続き無料でご利用いただけます。10 月 1 日以降は、選択したプランに応じて課金されます。 この 1 か月間、皆さまから Kiro に関する素晴らしいフィードバックをいただきました。そのフィードバックや日常の開発作業における利用状況を踏まえ、Kiro の新しい料金体系を発表いたします。 統一された利用上限 : これまでの vibe タスクと spec タスクで別々だった上限をやめ、すべてのリクエストが 単一のクレジットプール から消費されるようになります。これにより、柔軟にコントロールしながら Kiro をご利用いただけます。新しい統一上限は以下の通りです。 &nbsp; Free Pro Pro+ Power $0 $20 / 月 $40 / 月 $200 / 月 50 クレジット 1,000 クレジット 2,000 クレジット 10,000 クレジット 従量課金 ($0.04 / クレジット) 従量課金 ($0.04 / クレジット) 従量課金 ($0.04 / クレジット) クレジットの細分化課金 : クレジットはプロンプトの複雑さに応じて小数点単位で消費されます。簡単な編集やプロンプトであれば 1 クレジット未満の消費となり、0.01 クレジット単位で課金されるため、クレジットを最大限に活用できます。 無料トライアル : 初めて Kiro にアクセスした際には、14 日間有効な 500 クレジットのボーナスを付与します。詳細は FAQ をご覧ください。 タスクは複雑さに応じて異なる速度でクレジットを消費します。クレジットの仕組みの詳細については、FAQ をご覧ください。また、月次使用ダッシュボードでクレジット消費が可視化されるよう改善しました。今後数週間のうちに、Kiro は通知バーに消費したクレジット数を表示するようになり、月間制限に対する進捗状況を簡単に確認できるようになります。 Auto の紹介 Kiro の利用方法から学んだ重要なことの一つは、プロンプトの複雑さや出力要件が大きく異なるという点です。Kiro の目標は「最高の結果を最適な価格で」提供することです。そのために構築したのが Auto という新しいエージェントです。Auto は Sonnet 4 のようなフロンティアモデルと、特定のタスクに特化したモデルを組み合わせ、インテント検出やキャッシングなどの最適化技術を活用します。 Auto は常に性能・効率・出力品質を最適化します。例えば、あるタスクを Auto で実行すると X クレジット消費する場合、Sonnet 4 で実行すると 1.3 Xクレジット消費します。このコスト効率と Sonnet 4 レベルの品質を両立するため、Auto をチャット画面のデフォルトオプションに設定しました。もちろん、Sonnet 4 を指定して利用することも可能ですが、その場合はプランの上限が早く尽きてしまいます。 現在の Auto はまだ始まりに過ぎません。今後はニューロシンボリック AI（ニューラルネットワークと形式的推論の組み合わせ）を導入し、要件作成や改善、実装の検証といったタスクでさらに高品質な出力を目指しています。Auto が日常のリクエストを高性能かつコスト効率よく処理する様子をぜひ体感いただけると思います。 価格改定の実施 10 月 1 日までに、有料ユーザー向けにクレジットの単一プールと新たな制限を適用した更新プランを段階的に導入します。移行後、制限が新しい月額プランの制限値にリセットされることをご確認ください。Kiro は 9 月 30 日まで引き続き無料でご利用いただけます。10 月 1 日より、ご利用中のプランの課金が発生します。 有料プランをご利用の場合、超過料金の利用も可能です。超過料金も 9 月 30 日まで無料となります。10 月 1 日までは超過料金の上限を 1,000 クレジットとし、 10 月 1 日までに返金いたします。 10 月 1 日までに新規で Kiro にご加入いただいた場合、ご利用分は 10 月 1 日までに返金され、月額制限をフルにご利用いただけます。例えば 9 月 20 日にPro+ プランを購入された場合、9 月 30 日まで月額 2,000 クレジットを無料で全額ご利用いただけます。 FAQ Kiro の料金体系はどうなっていますか？ Kiro は開発者の利用方法に合わせた柔軟な料金体系を提供しています。Free プラン（50 クレジット）から始められ、Pro（$20/月）、Pro+（$40/月）、Power（$200/月）にアップグレード可能です。すべての有料プランで超過利用に対する従量課金（$0.04/クレジット）を利用できます。料金には消費税等は含まれません。日本の請求先住所を持つ場合、日本の消費税が適用されます。 クレジットとは何ですか？ クレジットはユーザーのプロンプトに対する作業単位です。簡単なプロンプトは 1 クレジット未満、spec タスクなどの複雑なプロンプトは 1 クレジット以上を消費します。モデルごとに消費量も異なり、Sonnet 4 では Auto より 1.3 倍多く消費します。クレジットは小数点第 2 位まで計測され、最小消費は 0.01 クレジットです。 クレジットは何に使えますか？ vibe モードや spec モードでのプロンプト実行、spec の洗練、タスク実行、エージェントフックの実行に消費されます。 クレジット使用量はどうやって確認できますか？ Kiro IDE のサブスクリプションダッシュボードでは、ご契約プランの月間クレジット上限、使用済みクレジット数、残りのクレジットを確認できます。使用量は 5 分以内に更新されます。 追加クレジットは購入できますか？ はい。有料プランでは利用超過機能を有効化すれば、月間上限を超えて利用可能です。追加分は $0.04/クレジットで月末に精算されます。例えば Pro プラン（1,000 クレジット）で 1,100 クレジット使用した場合、翌月の請求に $4 が加算されます。超過料金はデフォルトで無効化されており、適用するには設定で有効にする必要があります。超過料金を有効にした後は、有料プランを利用している限り有効な状態が維持されます。Kiro Free プランにダウングレードすると超過料金は無効化され、有料プランに戻った際に再度有効にする必要があります。 料金展開はどのように行われますか？ 10 月 1 日までに順次新プランへ移行します。移行後は新しい月間上限が適用されます。超過料金も 9 月 30 日までは無料で、上限 1,000 クレジットまで利用可能です。新規ユーザーも 9 月 30 日までは利用料が返金されます。 無料トライアルはどうなっていますか？ 10 月 1 日以降、Kiro に初めてアクセスした場合（ウェイティングリストから解除された場合）、ご登録プラン（Kiro Free を含む）に関わらず、14 日間有効な 500 ボーナスクレジットが付与されます。 チームでサブスクリプションを共有できますか？ いいえ。利用制限はユーザー単位で計算されます。&nbsp;組織向けの課金・管理機能は今後提供予定です。 未使用クレジットは翌月に繰り越せますか？ 利用制限は各請求月の初日にリセットされます。未使用のクレジットは翌月に繰り越せません。 Kiro はどのモデルを利用していますか？ デフォルトでは Auto エージェントによって処理されます。このエージェントは、Sonnet 4 などの複数のフロンティアモデルと、特定のタスク、意図検出、キャッシュ、その他の技術に特化した専門モデルを組み合わせて使用し、品質、レイテンシー、コストのバランスを最適化します。 支払い方法は？ 主要なクレジットカードをご利用いただけます。 有料プランに対応している国は？ 現在、オーストラリア、ブラジル、カナダ、中国、フランス、ドイツ、香港特別行政区、インド、インドネシア、イスラエル、イタリア、日本、韓国、メキシコ、オランダ、ポーランド、ルーマニア、シンガポール、スペイン、タイ、イギリス、アメリカ、ベトナムの請求先住所でご利用いただけます。今後さらに国や地域が追加される予定です。

本記事は米国時間 8 月 29 日に公開された “ Implementing usage and security reporting for Amazon ECR ” を翻訳したものです。 コンテナワークロードを管理する際、コンテナレジストリの一元的なオブザーバビリティを維持することはセキュリティと効率的なリソース利用のために不可欠です。 Amazon Elastic Container Registry (ECR) は、イメージレベルとリポジトリレベルの両方でメトリクスを提供し、統合されたオブザーバビリティを構築する上で重要な役割を果たします。本記事では、これらのメトリクスをコスト内訳、利用状況メトリクス、セキュリティスキャン結果、および全リポジトリにわたるコンプライアンスステータスを含む、基本的で包括的なレポートに一元化する手順をご案内します。統合されたオブザーバビリティにより、利用パターンをより深く理解し、セキュリティリスクを特定し、セキュリティ要件と最適化のベストプラクティスに準拠させる必要があるリソースに優先順位を付けることが出来ます。 本記事では、 サンプルコード を利用して 2 種類のレポートを生成します。1) リポジトリサマリーレポート – レジストリ内の全ての Amazon ECR リポジトリを一覧表示し、コスト、利用状況、 Amazon ECR イメージスキャン で検出された OS 脆弱性の追跡と最適化に必要な属性を提供します。2) イメージレベルレポート – 特定のリポジトリ内の全てのイメージを含み、最初のレポートで発見された内容を詳しく調査するために利用可能な属性を提供します。 これらのレポートは、コスト削減のために未使用のリポジトリとイメージの特定に役立ち、最も多くまたは最も重いイメージを持つリポジトリとライフサイクルポリシーが欠けているリポジトリを強調するのに役立ちます。これらは、ストレージ利用状況、セキュリティスキャン状態、リポジトリ全体にわたる重要なセキュリティ発見事項に関する洞察を提供し、それによってより良いコスト管理、ポリシー実装、優先順位付けされたセキュリティ修復を可能にします。 ソリューション概要 このセクションでは、Amazon ECR リポジトリに関する詳細なレポートを生成する サンプルコード を実行する方法を示す実践的な例を提供します。2 種類のレポートは次のように説明されます。 リポジトリサマリー : レジストリ内のリポジトリのサマリーで、次の属性を提供します: 名前 説明 repositoryName リポジトリ名 createdAt リポジトリが作成された日付 scanOnPush リポジトリにプッシュされた後にイメージがスキャンされるかどうか totalImages リポジトリ内のイメージ / アーティファクトの総数 totalSize(MB) リポジトリ内のイメージ / アーティファクトの総サイズ (MB) hasBeenPulled リポジトリ内のいずれかのイメージが少なくとも 1 回プルされたか lastRecordedPullTime リポジトリ内のイメージが最後にプルされた日付 daysSinceLastPull リポジトリが最後のイメージプルを記録してからの日数 lifecyclePolicyText リポジトリのライフサイクルポリシーテキスト この情報は、どのリポジトリが最も多くのイメージを持っているか、どれが最も重いか (イメージ / アーティファクトの総サイズについて) 、どれがライフサイクルポリシーを欠いているかを特定するのに役立ちます。これらの要因は、リポジトリの維持コストに大きく影響します。最後に、このレポートでは、イメージがリポジトリにプッシュされた後にスキャンされるかどうかを確認できます。コンテナスキャンを有効にすることで、組織はセキュリティリスクを大幅に削減し、コンテナ化された環境で強力なセキュリティ態勢を維持できます。 totalSize (MB) フィールドは、Amazon ECR における総ストレージコストを見積もるために利用すべきではありません。なぜなら、これにはリポジトリ内で共通のイメージレイヤーを共有する Amazon ECR の最適化の利点が含まれていないからです。このフィールドは、より多くのストレージを消費しているリポジトリに関する洞察を提供し、それゆえ最適化の候補となり得る可能性があります。 イメージレベル : リポジトリ内の全てのイメージ / アーティファクトの主要な属性を提供します。 名前 説明 repositoryName リポジトリ名 imageTags イメージのタグ imagePushedAt イメージがプッシュされた日時 imageSize(MB) イメージサイズ (MB) imageScanStatus イメージのセキュリティスキャン状態 imageScanCompletedAt イメージが最後にスキャンされた日時 findingSeverityCounts イメージ内のセキュリティ検出結果の重要度別カウント lastRecordedPullTime イメージが最後にプルされた日時 daysSinceLastPull イメージが最後にプルされてから経過した日数 この情報はイメージとストレージ利用量を詳細に分析するのに役立ち、コスト削減のために削減可能な未使用イメージを特定するのに役立ちます。また、この内容はより効果的なライフサイクルポリシーを実施するための知見も提供します。例えば、1/ タグ付けされていないイメージをクリーンアップする、2/ リポジトリごとに一定数のイメージを残す、または 3/ 古いイメージを削除することです。 さらに、本レポートでは Amazon ECR 基本スキャンを利用しているユーザー向けに統合されたセキュリティ検出結果データを提供し、是正措置の優先順位付けを支援します。Amazon ECR 拡張スキャンを利用しているユーザーには、 Amazon Inspector を通じて利用可能なセキュリティ機能と検出結果の利用をおすすめします。 前提条件 このウォークスルーを進めるには、以下の前提条件を満たしている必要があります 環境にインストールされた Finch (またはその他のコンテナビルドツール) 環境にインストールされた AWS Command Line Interface (AWS CLI) このポリシー を持つ AWS Identity and Access Management (IAM) プリンシパル (ユーザーまたはロール) 環境にインストールされた Git ウォークスルー 以下の手順でこのソリューションを実行します。 コンテナイメージを設定する リポジトリをクローンし、コンテナをビルドします。 git clone https://github.com/aws-samples/amazon-ecr-cost-vulnerability-and-usage-reporting.git cd amazon-ecr-cost-vulnerability-and-usage-reporting finch build -t ecr-reporter:v0.1.0 . このコマンドは以下のパラメータでイメージをビルドします: -t ecr-reporter:v0.1.0 : イメージに名前 ecr-reporter とタグ v0.1.0 を付与します。名前とタグは任意の値に置き換え可能です。 . : カレントディレクトリにある Dockerfile をビルドコンテキストとして利用します。 Docker を利用する場合、コマンド内の finch を docker に置き換え、その他のパラメータはすべて同じままにします。 リポジトリーサマリーレポートを実行する 以下のコマンドを実行してリポジトリサマリーレポートを生成する finch run \ -e AWS_ACCESS_KEY_ID=$(aws --profile aws-samples configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws --profile aws-samples configure get aws_secret_access_key) \ -e AWS_DEFAULT_REGION=us-east-1 \ -e AWS_SESSION_TOKEN=$(aws --profile aws-samples configure get aws_session_token) \ -v /Path:/data \ ecr-reporter:v0.1.0 このコマンドでは、 aws-samples と言う名前のプロファイルを利用し、 AWS リージョン は us-east-1 に設定されています。また、コンテナが停止した後もレポートをローカル環境 (この場合は /Path ) に永続化するためにボリュームを設定しています。コンテナには設定可能なパラメータがさらにあります。 LOG_VERBOSITY : DEBUG 、 INFO 、 WARNING 、または ERROR を設定 (デフォルト: INFO ) DECIMAL_SEPARATOR : CSV 数値フォーマットのために . または , を設定 (デフォルト: .) EXPORT_FORMAT : レポート生成に利用する区切り形式。csv、json、または parquet を設定 (デフォルト: csv) コンテナを実行するための全パラメーターは、 GitHub リポジトリ で確認できます。 Docker を利用する際は、コマンド内の finch を docker に置き換え、その他のパラメーターは全て同じにしてください。 リポジトリサマリーレポートを確認する 指定された出力ディレクトリに、1 つの CSV ファイルが作成されます。レポートは以下のようになります: 図 1: サンプルコンテンツ付きのリポジトリサマリーレポート イメージレベルレポートを実行する リポジトリ foobar のイメージレベルレポートを生成するには次のコマンドを実行する finch run \ -e AWS_ACCESS_KEY_ID=$(aws --profile aws-samples configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws --profile aws-samples configure get aws_secret_access_key) \ -e AWS_DEFAULT_REGION=us-east-1 \ -e AWS_SESSION_TOKEN=$(aws --profile aws-samples configure get aws_session_token) \ -e REPORT=foobar -v /Path:/data \ ecr-reporter:v0.1.0 イメージレベルレポートを生成するには、環境変数 REPORT にリポジトリ名を設定します。コンテナを実行するための全パラメーターは GitHub リポジトリ で確認できます。 Docker を利用する際は、コマンド内の finch を docker に置き換え、その他のパラメーターは全て同じにしてください。 イメージレベルレポートを確認する 指定した出力ディレクトリに、このレポートを含む 1 つの CSV ファイルが作成されます。レポートは次のようになります。 図 2: サンプルコンテンツ付きのイメージレベルレポート 更なる取り組み (任意) 以下のステップは任意です。 レポート生成をスケジュールする このコードは、AWS コンテナサービスにおいて 1) Amazon Elastic Kubernetes Service (Amazon EKS) における cron ジョブ ( 手順 を参考に設定可能)、または 2) Amazon Elastic Container Service (Amazon ECS) でスケジュールされたタスクとして定期的に実行できます。 レポートを分析するために Amazon Athena を利用する レポートを Amazon S3 に保存することもでき、 Amazon Athena を利用してクエリを実行できます。これを行うには、特定のバケットにオブジェクトをアップロードする権限を付与する ポリシー を IAM プリンシパルに設定する必要があります (ポリシー作成時にバケット名を指定してください) 。ポリシーをアタッチしたら、環境変数 AMAZON_S3_BUCKET にバケット名を設定することで各レポートを生成できます。 finch run \ -e AWS_ACCESS_KEY_ID=$(aws --profile aws-samples configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws --profile aws-samples configure get aws_secret_access_key) \ -e AWS_DEFAULT_REGION=us-east-1 \ -e AWS_SESSION_TOKEN=$(aws --profile aws-samples configure get aws_session_token)] \ -e AMAZON_S3_BUCKET=&lt;s3 bucket name&gt; \ -e EXPORT_FORMAT=csv \ ecr-reporter:v0.1.0 Docker を利用する際は、コマンド内の finch を docker に置き換え、その他のパラメーターは全て同じにしてください。 レポート生成後、Athena を利用してその内容を分析できます。この例では、事前に Athena の設定が完了していることを前提としています。もし設定が完了していない場合は、この はじめに ガイドに従って設定を完了し、その後戻ってきて続きを進めることができます。 リポジトリ概要レポート用スキーマを格納するデータベース ecr_repository_summary を作成します。Athena クエリエディタで次のクエリを実行する CREATE DATABASE IF NOT EXISTS ecr_repository_summary; リポジトリサマリーレポートのテーブルスキーマを作成する リポジトリサマリーレポートの詳細を表示するには、Amazon S3 に保存されているレポートのスキーマを保持するテーブルをこのデータベース内に作成する必要があります。これを実行するには Athena クエリエディタで次のクエリを実行できます。 CREATE EXTERNAL TABLE IF NOT EXISTS `repo_summary` ( `repositoryname` string COMMENT '', `createdat` string COMMENT '', `scanonpush` boolean COMMENT '', `totalimages` bigint COMMENT '', `totalsize(mb)` double COMMENT '', `hasbeenpulled` boolean COMMENT '', `lastrecordedpulltime` string COMMENT '', `dayssincelastpull` bigint COMMENT '') ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3://&lt;s3 bucket name&gt;/' TBLPROPERTIES ``( 'areColumnsQuoted'='false', 'classification'='csv', 'columnsOrdered'='true', 'compressionType'='none', 'delimiter'=',', 'skip.header.line.count'='1', 'typeOfData'='file' &lt;s3 bucket name&gt; は、生成されたレポートを保存するために作成したバケット名に置き換えることを覚えておいてください。 このクエリを実行後、 repo_summary という名前の新しいテーブルが作成されます。このテーブルをクエリすることで、生成してバケットに保存したリポジトリサマリーサポート CSV におけるデータのレコードを取得できます。 新しいテーブルをクエリしてデータを確認する SELECT * FROM "ecr_repository_summary"."repo_summary" limit 100; この出力は以下のようになります。 図 3: Amazon Athena を利用して SQL でリポジトリサマリーレポートを操作する インサイトを収集し、分析する データをクエリする容易な方法ができたため、これを使用してコスト最適化、健全性、Amazon ECR リポジトリのメンテナンスに関する情報に基づいた意思決定に役立つ関連性のある洞察を得ることができます。例えば、以下のクエリを利用すると、ストレージ利用料が最も多いリポジトリを素早く特定できます。 SELECT * FROM "ecr_repository_summary"."repo_summary" ORDER BY "totalsize(mb)" DESC limit 10; あるいは、一度もプルされたことのないイメージを持つものを見つけることもできます。 SELECT * FROM "ecr_repository_summary"."repo_summary" WHERE hasbeenpulled = false limit 10; あるいは、1 年以上取得されていないものを探して、古いリソースを削除することもできます。 SELECT * FROM "ecr_repository_summary"."repo_summary" WHERE dayssincelastpull &gt; 365 ORDER BY dayssincelastpull DESC limit 10; 言い換えれば、このデータで好きなだけ創造性を発揮できるということです！この手順では、CSV 出力形式を利用しました。Parquet や JSON の利用も同様ですが、若干の変更が必要になる場合があります (本記事の範囲外です)。 クリーンアップ レポートを Amazon S3 に保存し、Amazon Athena を利用して分析する場合、AWS アカウントに課金されます。もし、あなたが不要な課金が発生しないようにクリーンアップすることを決めたなら、このデプロイ中に作成された全ての AWS リソースを削除してください。 Amazon S3 バケットとコンテンツを削除する aws s3 rb s3://&lt;bucket name&gt; --force Athena リソースをクリーンアップする # Delete Athena table using AWS CLI aws athena start-query-execution \ --query-string "DROP TABLE IF EXISTS \`ecr_repository_summary\`.\`repo_summary\`;" \ --result-configuration OutputLocation= s3://&lt;s3 bucket name&gt;/ # Delete Athena database using AWS CLI aws athena start-query-execution \ --query-string "DROP DATABASE IF EXISTS \`ecr_repository_summary\`;" \ --result-configuration OutputLocation= s3://&lt;s3 bucket name&gt;/ IAM ユーザーやロールにアタッチされた IAM ポリシーをデタッチする aws iam detach-user-policy --user-name &lt;user name&gt; --policy-arn &lt;policy ARN&gt; aws iam detach-role-policy --role-name &lt;role name&gt; --policy-arn &lt;policy ARN&gt; おわりに パフォーマンスとイノベーションを維持しながら AWS コストを最適化することは、効果的なオブザーバビリティによって実現可能です。Amazon ECR に関するインサイトを活用することで、組織はコンテナ運用を強化するデータドリブンな意思決定を行うことができます。リポジトリに関する詳細な可視性 (コスト内訳、利用状況メトリクス、セキュリティスキャン結果、コンプライアンス状況など) により、チームはイノベーションを加速させながらコンテナインフラストラクチャを合理化する準備が整います。 本記事で提供されているサンプルコードを利用することで、Amazon ECR リポジトリに関するインサイトを提供するだけでなく、それぞれのイメージの詳細まで深く掘り下げることができる包括的なレポートを生成できます。これらのレポートにより、コスト効率性、効率的なリソース利用、セキュリティの強化を目的として Amazon ECR の利用状況を積極的にレビューし、最適化することが可能になります。ぜひ、サンプルコードをお試しいただき、フィードバックをお寄せください。皆様のご意見は、AWS コンテナコミュニティにより良いサービスを提供するための改善と強化に役立ちます。 ご質問、機能リクエスト、プロジェクトの貢献については GitHub リポジトリをご覧ください 。

本記事は、2025 年 9 月 4 日に実施した、ファッション、アパレル、コンビニエンスストアといった事業を展開されている小売企業のお客様を対象とした、AI エージェント活用ワークショップの内容をご報告するものです。本ワークショップでは、これらの業界の共通項である、店舗運営に焦点を当てて、店舗業務における課題を 生成 AI や AI エージェントを活用することでどのように解決できるかについてみんなで考え、アイデア出しから実装までの流れを体験いただくことを目的としています。 ワークショップの概要 ワークショップには、15 社 30 名の方にご参加いただきました。IT / DX 部門のみならず、企画、事業開発、AI 推進、元店長など、多種多様な所属部門、経歴のお客様にご参加いただきました。 主なアジェンダは、下記の通りです。 生成 AI の今　- 汎用的→特定業務を支援するエージェント – ハンズオン　- 店舗向け AI エージェントを体験してみよう – ハッカソン　- 店舗業務を効率化しよう – 生成 AI の今　- 汎用的→特定業務を支援するエージェント – [ 資料 ] アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 平井 健治 2025 年の今、企業における生成 AI の活用は汎用的なチャットツールから、特定業務を支援する AI エージェントの活用へと進化している段階にあります。 PwC 社のレポート によると、生成 AI の活用において、米国と比較し日本は期待を下回るケースが多く見られます。その要因として知識やスキル不足による具体的なユースケース検討の停滞が挙げられる一方で、期待以上の成果が出たケースとして日米間で共通している要因は「ユースケース設定」にあることが明らかになっています。 AWS は、多くの汎用ユースケースに対応可能な生成 AI サンプルソリューション「 Generative AI Use Cases （略称 GenU ）」をオープンソースで公開しており、ユーザーはユースケースビルダー機能を利用することで、ノーコードで独自のユースケースも構築できることをご紹介しました。データ活用のユースケースにおいては、自然言語でデータ分析や新たなダッシュボード生成を行う Amazon Q in QuickSight や、追加学習なしに高精度な時系列予測を実現する基盤モデル Chronos-Bolt について、デモを通じてご紹介しました。 そして店舗業務に目を向けると、これらのユースケース以外にも、発注、検品、シフト作成など様々なタスクがあり、ここに AI エージェントの活用を検討しましょう、と参加者に投げかけました。注意すべき点として、エージェント 1 つに多数の役割を持たせると、ハルシネーションの発生確率を高めたり、後からの機能追加が困難になるため、エージェントを役割で分けて、複数の業務特化エージェントが連動するマルチエージェント構成の必要性について説明しました。 ハンズオン　- 店舗向け AI エージェントを体験してみよう – [ 資料 ] アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 喜多 望 ハンズオンでは、店舗業務で重要な在庫管理と売上分析する AI エージェントの構築を体験いただきました。AI エージェントは独自の在庫管理 DB や売上分析システムと連携した処理を行うことができます。参加者は、ノーコードで AI エージェントを開発できる Amazon Bedrock Agents を利用し、在庫確認を行うエージェントと売上分析を行うエージェントを作り、そして、これらのエージェントと連携し取りまとめる Supervisor エージェントを構築しました。さらに、GenU から Supervisor エージェントを呼び出せるように設定することで、 Web アプリケーションから自然言語で店頭在庫の確認や売上分析を行えるチャット環境を短時間で構築いただきました。AI エージェントがユーザーからのリクエストを理解してタスクを細分化し、業務特化のエージェントと連携して、複合的な処理を完結できるということを体験いただきました。 ハッカソン　-店舗業務を効率化しよう – [ 資料 ] アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 濱上 和也 「ユースケースの解像度が高ければ、実用的な AI アプリは作れる」ということを体験いただくため、店舗業務を効率化する AI エージェントを具体化するハッカソンを行いました。現実世界の業務には、単純なワークフローもあれば、複雑な処理の分岐や判断を必要とするケースなど多岐に渡り、それぞれの業務フローに対して AI はどのように機能できるか、人間との役割分担はどうあるべきか、について問いかけました。AI から人間に判断を求めるユースケースの具体例として、FAQ ページを更新する AI エージェントのデモをお見せし、これを実現する AWS アーキテクチャの概要と、 実は Amazon Q Developer がほぼ全て開発したことについて触れ、ユースケースの解像度が高ければ、開発自体のハードルは今はかなり低いということを説明しました。 ハッカソンでは、今回のテーマである店舗業務の課題の具体例を示しながら、誰のどんな業務を解決するのか、グループ内で話し合い、ユースケースを 1 点に絞り込んでいただきました。そのユースケースで活用できる AI エージェントアプリケーションを利用者視点で 5W1H を定義し、必要となるデータやツール、連携方式について整理いただきました。 このワークでは、先ほどのハンズオンで作成した GenU の各種機能も活用し、要件の解像度を高める手法も実践しました。例えば、 議事録生成 を使い、ディスカッション中の音声から 利用者視点の 5W1H を自動整理させたり、 ダイアグラム生成 でシステム関連図の作成や、 画像生成 で利用シーンをビジュアル化、 チャット でシステム要件定義を行うなど、生成 AI の力を借りることで議論から効率良く解像度を上げていきました。 そして、これらの情報をインプットに、 Amazon Q Developer を使って画面プロトタイプの開発にも挑戦いただきました。全てのグループが画面プロトタイプを作成し、実用的な AI アプリケーションのアイデアを全体で発表いただきました。限られた時間でしたが、参加いただいたお客様は店舗業務における具体的な AI 活用のユースケースを特定し、その検討過程においても AI を活用しながら、アイデアからアプリケーション実装への実践的な流れを体験いただきました。 お客様の声 アンケートでは、CSAT 4.58 ととても高い評価をいただくことができました。「業務効率化を図れるような機能を体験することができ、過去実店舗に在籍していた身としても、非常に興味深く、店舗に実装されたらどれだけのことができるだろうかと、思い描くのが楽しい時間でした」、「ハッカソンで出ていた様々な案はいずれも実際の業務に活用できそうだと思いました」、「店長エージェントの実装を検討する中で、自社ソリューションの組み合わせなど、試したいアイデアが出ました」、「他社の方の事例を聞いたり、小売業界ならではの共通した課題への気づきを得られてかなり勉強になりました」、「 AI エージェントを活用するために今日から行動を起こしてみます」など多数のポジティブなコメントと、次回開催に対する期待の声をいただくことができました。 まとめ ワークショップを通じて、各グループ計 6 つの具体的なユースケースを特定することができました。ユースケースの内訳として、店長視点のものが 3 つ（売れ筋商品の補充発注、シフト変更調整、週報の作成）、店舗スタッフ視点のものが 3 つ（店舗コンシェルジュ、商品ポップ作成、滞留在庫商品の広告作成）でした。偶然にもグループ間でテーマの被りがなく、何よりどのグループも議論と実装で盛り上がり、もっと時間が欲しかったというコメントをたくさんいただきました。これは、テーマを店舗業務に絞ったことの効果と AI ツールの活用、そして企業をまたぐお客様同士のコミュニケーションによって、お客様の気づきと満足度に大きく寄与したものと考えています。お客様の声に耳を傾けて、今後も期待に応える企画を考えてご提供していきます。 著者 / ワークショップ提供コアメンバーについて 平井 健治（Kenji Hirai） 流通・小売のお客様を担当するソリューションアーキテクトです。Amazon Redshift などアナリティクス関連の技術支援も行っています。 喜多 望（Nozomi Kita） 流通・小売のお客様を担当するソリューションアーキテクトです。好きな AWS サービスは Amazon GuardDuty で、業界問わず、Security 分野の技術⽀援も行っています。趣味はゲームとお笑いライブの鑑賞です 西村 忠巳（Tadami Nishimura） 流通・小売のお客様を担当するソリューションアーキテクトです。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。 濱上 和也（Kazuya Hamagami） 流通・小売のお客様を担当するソリューションアーキテクトです。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。最近は、Amazon Nova Canvas でバーチャル試着を楽しんでいます。

8 月、 Amazon Web Services (AWS) は 2025年 Gartner Magic Quadrant において、戦略的クラウドプラットフォームサービス (SCPS) 部門でリーダー として認められました。ガートナーは、15 年連続で AWS をリーダーとして位置付けました。 2024 年度は、 Gartner の AIコードアシスタント 、 クラウドネイティブアプリケーションプラットフォーム 、 クラウドデータベース管理システム 、 コンテナ管理 、 データ統合ツール 、 Desktop as a Service (DaaS) 、 データサイエンスおよび機械学習プラットフォーム の Magic Quadrant、および SCPS において、AWSがリーダーとして選定されました。2025年度には、Gartner の Magic Quadrant のサービスとしての Contact Center as a Service (CCaaS 、 Desktop as a Service 、 データサイエンスおよび機械学習 (DSML) プラットフォームでもリーダーとして選定されました。AWS がお客様に最も幅広く、かつ最も奥深いサービスを提供していることを意味すると、弊社は強く信じています。 9 月 15 日、最新の Magic Quadrant レポートにて、AWS がより多くのクラウドテクノロジー市場、具体的にはクラウドネイティブアプリケーションプラットフォーム (別名：クラウドアプリケーションプラットフォーム) とコンテナ管理でリーダーに選出されたことをご報告できることを嬉しく思います。 2025年 Gartner Magic Quadrant のクラウドネイティブアプリケーションプラットフォーム部門 AWS は Gartner Magic Quadrant のクラウドネイティブアプリケーションプラットフォーム部門で、 2 年連続でリーダーに選出されました。AWS は「実行能力（Ability to Execute）」において、最も高い位置に付けられました。Gartner はクラウドネイティブアプリケーションプラットフォームを、アプリケーション向けのマネージドアプリケーションランタイム環境と、クラウド環境におけるアプリケーションやアプリケーションコンポーネントのライフサイクルを管理するための統合機能を提供するプラットフォームと定義しています。 次の画像は、2025 年版クラウドネイティブアプリケーションプラットフォームの Magic Quadrant の図です。 弊社の包括的なクラウドネイティブアプリケーションポートフォリオ ( AWS Lambda 、 AWS App Runner 、 AWS Amplify 、 AWS Elastic Beanstalk ) は、継続的なイノベーションと広範な AWS サービスポートフォリオ全体にわたる緊密な統合によって実証されているように、強力な AI 機能を備えた最新のアプリケーションを構築するための柔軟な選択肢を提供します。 AWS ソリューションライブラリ で利用できる包括的なドキュメント、リファレンスアーキテクチャ、規範的なガイダンス、および特定の要件に基づく Amazon Q による AI を活用したコンテキスト応じた推奨事項を通じて、サービスの選択を簡素化できます。AWS Lambda は、可能な限り最高のサーバーレス体験を提供するために AWS 向けに最適化されていますが、サーバーレスコンピューティングの業界標準に準拠しており、一般的なプログラミング言語やフレームワークをサポートしています。AI/ML、エッジコンピューティング、エンタープライズ統合などの高度な特徴量を含む、必要なすべての特徴量を AWS 内で見つけることができます。 Amazon Bedrock によるサーバーレス推論や、 Amazon SageMaker による 人工知能および機械学習 (AI/ML) のトレーニングと管理用に、これらのコンピューティングサービスを統合することで、 生成 AI のエージェントやアプリケーションを構築、デプロイ、およびスケールすることができます。 詳細については、 2025 年 Gartner Magic Quadrant のクラウドネイティブアプリケーションプラットフォーム部門 の完全版レポートをご覧ください。 2025年 Gartner Magic Quadrant のコンテナ管理部門 2025 年 Gartner Magic Quadrant のコンテナ管理部門において、AWS は 3年連続でリーダーに選出され、「ビジョンの完全性」が最も上位に位置付けられました。Gartner は、コンテナ管理をコンテナ化されたワークロードのデプロイと運用をサポートするサービスと定義しています。このプロセスには、デプロイ、スケーリング、運用を含むコンテナのライフサイクル全体をオーケストレーションおよび監視して、異なる環境で効率的かつ一貫したパフォーマンスを確保することが含まれます。 次の画像は、2025年のコンテナ管理に関する Magic Quadrant の視覚的な表現です。 AWS コンテナサービス は、AWS ネイティブソリューションとオープンソース技術を活用したフルマネージドコンテナオーケストレーションを提供し、Kubernetes からネイティブオーケストレーターまで、幅広いデプロイオプションに対応しています。 Amazon Elastic Container Service (Amazon ECS) および Amazon Elastic Kubernetes Service (Amazon EKS) を利用できます。どちらも AWS Fargate でサーバーレスコンテナのデプロイに使用できます。さらに、EKS Auto Mode は、インフラストラクチャのプロビジョニング、最適なコンピューティングインスタンスの選定、コンテナ化されたアプリケーションのリソースの動的なスケーリングを自動的に行うことで、Kubernetes の管理を簡素化します。 EKS Hybrid Nodes と ECS Anywhere を使用して、オンプレミスとエッジのインフラストラクチャを AWS コンテナサービスに接続できます。また、 EKS Anywhere を使えば、AWS によってサポートされる、完全に切り離された Kubernetes 環境を利用することもできます。柔軟なコンピューティングとデプロイのオプションにより、運用負荷を軽減し、イノベーションに集中して、より迅速にビジネス価値を高めることができます。 詳細については、 2025 年 Gartner Magic Quadrant のコンテナ管理部門 の完全版レポートをご覧ください。 – Channy 原文は こちら です。 Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価または他の認定を受けたベンダーのみを選定するようテクノロジーユーザーに助言するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本調査に関して、明示または黙示を問わず、商品性または特定目的適合性に関する保証を含め、一切の保証を放棄します。 GARTNER は Gartner の登録商標およびサービスマークであり、Magic Quadrant は Gartner, Inc. および/またはその米国および他国の関連会社の登録商標であり、許可を得て使用されています。All rights reserved.

9 月 8 日週、エージェンティック AI SDK の AWS オープンソースである Strands Agents は、 2025 年 5 月のプレビュー版リリース からわずか 4 か月足らずで、ダウンロード数 100 万回を突破し、3,000 個以上の GitHub スターを獲得しました。Strands Agents を使用すると、数行のコードで本番環境に対応したマルチエージェント AI システムを構築できます。 私たちは、マルチエージェントパターン、A2A プロトコル、Amazon Bedrock AgentCore のサポートなど、特徴量を継続的に改善してきました。Strands Agents を使用してインテリジェントエージェントの構築を開始する際に役立つ サンプル実装のコレクション を使用できます。私たちは、バグレポート、新特徴量、修正、追加ドキュメントなど、プロジェクトへの 貢献やフィードバック をいつでも歓迎します。 ここでご紹介するのは、 エージェンティック AI の未来と、科学者が問い続ける疑問 (エージェント間のコミュニケーション、コンテキストの理解、常識的な推論など) に関する Amazon Science の最新の研究記事です。エージェンティック AI の技術的なトピックについては、身近な例 (ドアを開けたままにするか閉めたままにするか、鍵をかけたままにするか開けたままにするかといった個人的な行動) を用いると理解することができます。 9 月 8 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon EC2 M4 および M4 Pro Mac インスタンス – 新しい M4 Mac インスタンスは M2 Mac インスタンスと比較して最大 20% 優れたアプリケーションビルドパフォーマンスを提供し、M4 Pro Mac インスタンスは M2 Pro Mac インスタンスと比較して最大 15% 優れたアプリケーションビルドパフォーマンスを提供します。これらのインスタンスは、iOS、macOS、iPadOS、tvOS、watchOS、VisionOS、Safari などの Apple プラットフォーム向けのアプリケーションの構築とテストに最適です。 Visual Studio Code (VS Code) での LocalStack 統合 – LocalStack を使用すると、ツールを切り替えたり、複雑なセットアップを管理したりすることなく、使い慣れた VS Code インターフェイスを使用してサーバーレスアプリケーションをローカルでエミュレートおよびテストできるため、ローカルサーバーレス開発プロセスが簡素化されます。 AWS Cloud Development Kit (AWS CDK) リファクタリング (プレビュー) – デプロイされたリソースの状態を維持したまま、コンストラクトの名前を変更したり、スタック間でリソースを移動したり、CDK アプリケーションを再編成したりできます。CDK リファクタリングは、 AWS CloudFormation のリファクタリング機能 と自動マッピング計算を使用することで、コードの再構築中に意図しないリソース置換が発生するリスクを排除します。 AWS CloudTrail MCP サーバー – 新しい AWS CloudTrail MCP サーバーにより、AI アシスタントは、自然言語による対話を通じて、API コールの分析、ユーザーアクティビティの追跡、および AWS 環境全体の高度なセキュリティ分析を行うことができます。AWS サービスリソースを使用するための AWS MCP サーバー は他にもあります。 Amazon CloudFront の IPv6 オリジンのサポート – アプリケーションは IPv6 トラフィックをオリジンまで送信できるため、IPv6 導入に関するアーキテクチャ要件や規制要件を満たすことができます。エンドツーエンドの IPv6 サポートにより、IPv6 ネットワーク経由で接続するエンドユーザーのネットワークパフォーマンスが向上し、オリジンインフラストラクチャの IPv4 アドレス枯渇の懸念も解消されます。 AWS のお知らせに関する詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 手のひらに収まる都市 – AWS Trainium チップの設計者が都市計画者さながらに思考し、ナノメートル単位で最適化を重ねた結果、光速に近い速度でデータを移動させる仕組みを実現した経緯を解説するインタラクティブ特徴量をご利用ください。 ソフトウェア開発ツールとプラクティスの有効性の測定 – Amazon 開発者が AI ツールを採用する前に具体的な課題を特定し、当社のソフトウェアサービスコストフレームワーク (CTS-SW) を使用して前年比で 15.9% のコスト削減を実現した経緯についてお読みいただけます。適切な問題に最初に焦点を合わせて、デプロイ頻度を増やし、手動による介入を 30.4% 削減しました。 AWS Cloud Club Captain 会員募集中 – AWS Cloud Club Captain の一員になって、拡大中の学生クラウド愛好家のネットワークにご参加ください。 Captain の一員になると、リーダーシップスキルを磨きながら、イベントの企画やクラウドコミュニティの構築を行うことができます。応募受付期間は 2025 年 9 月 1 日から 28 日までです。 近日開催予定の AWS イベント カレンダーをチェックして、近日開催予定の AWS イベント、 AWS re:Invent 、 AWS Summits にぜひサインアップしてください。 AWS AI Agent Global Hackathon – 弊社の強力な生成 AI スタックを深く掘り下げて、真に素晴らしいものを創り出すチャンスです。9 月 8 日から 10 月 20 日までの期間、AWS の AI サービススイートを使用して AI エージェントを作成する機会が与えられ、45,000 USD を超える賞金と独占的な市場参入のチャンスを賭けて競い合っていただきます。 AWS Gen AI Lofts – 限定セッションで AWS AI 製品とサービスについて学び、業界をリードするエキスパートと交流し、投資家や同業者との貴重なネットワーキングの機会を得ることができます。日程は、 メキシコシティ (9 月 30 日～10 月 2 日)、 パリ (10 月 7 日～21 日)、 ロンドン (10 月 13 日～21 日)、 テルアビブ (11 月 11 日～19 日) です。最寄りの都市で登録してください。 AWS Community Days – 世界各地のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 アオテアロア と ポーランド (9 月 18 日)、 南アフリカ (9 月 20 日)、 ボリビア (9 月 20 日)、 ポルトガル (9 月 27 日)、 ドイツ (10 月 7 日)、 ハンガリー (10 月 16 日) です。 今後開催される AWS イベント と AWS スタートアップイベント をすべて閲覧できます。 9 月 15 日週のニュースは以上です。9 月 22 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。