本記事は 2026/04/15 に公開された “ Accelerating physical AI with AWS and NVIDIA: building production-ready applications with simulation and real-world learning ” を翻訳したものです。 フィジカル AI をデジタルインテリジェンスを超えて定義する フィジカル AI は純粋な計算システムを超えて、物理世界を直接知覚、推論、相互作用する知的エージェントへと進化しています。チャットボットやレコメンデーションエンジンなどのデジタル領域で情報を処理する従来の AI システムとは異なり、フィジカル AI はセンサーとアクチュエータを備えたシステムにインテリジェンスを組み込み、実世界の環境で意味のある、適応的な、自律的な行動を取ることを可能にします。 ロボティクスはフィジカル AI の最も高度な応用例で、機械が複雑な操作、ナビゲーション、組立作業を行います。しかし、フィジカル AI は自律車両が動的な交通状況をナビゲートする、ドローンがインフラ点検を行う、スマート製造資産（パッケージの詰まりを防ぐために速度を自律的に調整するコンベアなど）など、多様な領域に拡がります。各アプリケーションは環境条件を感知し、リアルタイムで物理データを処理する能力を共有します。また、適応的な応答を実行する能力も共通の要件です。 この新興分野は、Morgan Stanley が 2050 年までに $5 兆ドル に達すると予測する市場機会を表しています。この成長は、AI ヒューマノイドのゼロショット製造能力によって推進されています。これらのヒューマノイドは人間のように自律的かつ直感的に働き、世界の労働コストのうち 30-40% を自動化する可能性があります。しかし、これらのヒューマノイドが自己バランスなどの基本的な能力を訓練されたとしても、特定の実世界のアプリケーションにはフィジカル AI のチューニングが必要です。ロボットアームやヒューマノイドを製造業務に導入する組織は、フィジカル AI を使用して実際のビジネス問題を解決するための実用的な方法を必要としています。 開発から導入への課題 DHL Supply Chain の 最近の研究 は、倉庫にロボティクスを統合する際の実装と管理の課題を強調しています。44% の組織がすでにロボティクスを導入していますが、サプライチェーン幹部の 34% のみが、自社の技術導入が適切に機能していると考えています。これは、フィジカル AI モデルの実世界でのデプロイメント、モニタリング、配布、ガバナンスが成功したパフォーマンスとビジネス成果に不可欠であることを強化しています。 Amazon Web Services (AWS) は、Amazon の倉庫やサプライチェーン全体でフィジカル AI を備えたロボティクスを広範に導入することで、これらの分野で実証された能力を示しています。 従来のフィジカル AI 開発には、自律システムの構築に多額の資本投資が必要でした。また、試行錯誤の学習中には安全上の懸念が生じ、反復速度が制限されるという重大な障壁がありました。このプロセスは、物理学と環境ベースのシミュレーションに置き換えることができます。これにより、並列で幅広いシナリオに対してトレーニングを行うことができます。しかし、シミュレーションだけでは、摩擦の変化、材料の変形、センサーノイズ、環境の予測不可能性など、実世界の物理の完全な複雑さを捉えることはできません。 このブログでは、シミュレーションから現実へのギャップを埋める包括的なリファレンスアーキテクチャを提示します。シミュレーションベースのトレーニングの速度と安全性、および実世界の学習の忠実性を組み合わせています。AWS インフラストラクチャと NVIDIA Isaac （オープンなロボティクス開発プラットフォーム）に基づいて構築されたこのアプローチにより、組織はフィジカル AI アプリケーションの開発、デプロイメント、継続的な改善を大規模に促進することができます。 シミュレーションと実世界学習を組み合わせた二段階アプローチ シミュレーションはスケールで迅速かつ安全な実験を可能にします。しかし、実世界のデプロイメントでは、予測不可能な物理条件を処理できるシステムが必要です。NVIDIA Isaac は、組織が物理的に正確な仮想環境でロボットポリシーを訓練およびテストし、エッジデプロイメントの成功に向けて準備することを可能にします。 NVIDIA Isaac は、 NVIDIA Isaac Sim や NVIDIA Isaac Lab などのオープンモデル、ライブラリ、オープンソースフレームワークで構成されています。Isaac Sim は NVIDIA Omniverse ライブラリに基づいて構築されたオープンソースのロボティクスシミュレーションリファレンスフレームワークであり、AI 駆動ロボットのための物理的に正確な、GPU アクセラレーション対応の仮想環境を提供し、設計、テスト、合成トレーニングデータの生成を行います。NVIDIA Isaac Lab は Isaac Sim に基づいて構築されたオープンソースの統合ロボット学習フレームワークであり、強化学習や模倣学習方法を使用して高度なロボットポリシーを訓練します。 Isaac Sim は物理的に正確なシミュレーション環境を提供し、Isaac Lab はその環境を数千の並列トレーニングシナリオにスケールします。これらが一緒になって、実世界のデプロイメントの前に迅速なポリシー開発を可能にします。 シミュレーションベースのトレーニングの力 シミュレーションはフィジカル AI 開発の効率的な出発点を提供します。Isaac Sim を使用することで、チームはロボットシステムと運用環境の デジタルツイン を作成できます。これにより、複数の物理プロトタイプを構築するコストと時間を省き、迅速な実験が可能になります。AWS インフラストラクチャ上で Isaac Sim を実行することで、フィジカル AI 開発者にいくつかの重要な利点がもたらされます： 迅速な反復とコスト効率： エンジニアは高価なハードウェアを危険にさらすことなく、何千ものシナリオを並列でテストできます。複数の物理プロトタイプを構築する代わりに、チームは仮想的に設計の代替案を評価します。壊れやすい物体を把持することを学ぶロボットアームは、シミュレーションで追加コストなしで何度も失敗できます。 物理シミュレーションによる学習の拡大： シミュレーションは初期のポリシー学習に十分な物理理解を提供します。膨大な並列トレーニングが可能になり、何百もの仮想環境を同時に実行することで、物理ロボットの学習時間を数週間から数時間に圧縮します。物理パラメータがトレーニング中に体系的に変化するドメインランダム化などの技術は、モデルが実世界の条件に一般化するのを助けます。 実世界の検証の必要性 シミュレーションの利点にもかかわらず、生産準備が整ったフィジカル AI アプリケーションには実世界のデプロイメントが不可欠です。sim-to-real のギャップは、シミュレートされた物理と実際の物理の違いを表し、パフォーマンス、安全性、信頼性、運用効果に大きな影響を与える可能性があります。 物理の忠実度と環境の複雑さ： 実際のセンサーは、シミュレーションでは近似しきれない微妙な違いを捉えます。表面のテクスチャの変化、照明条件、材料のコンプライアンス、動的な環境要因などが含まれます。また、生産環境では予測不可能なシナリオが発生します。 継続的な改善： システムが生産で動作するにつれて、モデルの改良に情報を提供する新しい状況に遭遇します。運用データは、モデルの改善を導くエッジケースとパフォーマンスギャップを明らかにします。包括的なセンサーフィードバック（力センサー、ジョイントエンコーダ、カメラ、加速度計）を備えた実世界のテストは、モデルの有効性を検証します。ミリ秒のデータストリーミングにより、継続的なパフォーマンスモニタリングが可能になります。 エンドツーエンドアーキテクチャの概要 以下のアーキテクチャガイダンスは、シミュレーションベースと実世界の強化学習の 2 つの補完的な経路を通じて、フィジカル AI ロボティクスアプリケーションの開発を可能にします。このソリューションは、NVIDIA Isaac または力、視覚、位置、動作センサーなどの実世界のインテリジェントセンサーデータを通じて物理を管理します。シミュレーションパスでは、実世界の実装前に仮想環境でモデルをトレーニングします。一方、実世界パスでは、センサーデータを通じて実際の物理的相互作用をキャプチャします。トレーニングされたモデルは、エッジデバイスにデプロイされ、推論ベースの制御ポリシーを実装し、反復学習のためにリアルタイムのセンサーデータを摂取します。これにより、人間のような知性を模倣し、指定されたタスクを自律的に実行するシステムが可能になります。 この リファレンスアーキテクチャ には、並行して動作する 2 つの補完的な学習ループが実装されています。 図 1: このガイダンスアーキテクチャは、AWS 上で高度な AI 機能を物理ロボティクスシステムと統合する方法を示しており、実世界の環境で自律的な操作を可能にします シミュレーショントレーニングループ – 構築と学習 GPU 搭載の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上でコンテナで実行される Isaac Sim から始まります。エンジニアはシステムの運動学をモデル化し、物理制約を定義し、運用シナリオを表す仮想環境を作成します。Isaac Lab は、物理パラメータ、環境条件、タスクの複雑さのバリエーションをテストしながら、トレーニングを複数の並列シナリオにわたってスケールします。 AWS Batch はシミュレーションワークロードを調整し、 Amazon EC2 自動スケーリング グループで GPU コンピューティングリソースを動的にプロビジョニングします。トレーニングの需要が変動するにつれて、インフラストラクチャは自動的にスケールし、集中的なフェーズでは追加のインスタンスを起動し、アイドル期間中はスケールダウンして、コスト効率を最適化します。トレーニングされたモデルと関連するポリシーは、 Amazon Simple Storage Service (Amazon S3) に保存されます。Amazon S3 は耐久性のあるバージョン管理されたストレージを提供します。 Amazon Elastic Container Registry (Amazon ECR) は、環境間での一貫したデプロイメントのためにコンテナイメージを管理します。 実世界の学習ループ – デプロイと監視 シミュレーショントレーニングで候補モデルが生成されると、エンジニアはそれを AWS IoT Greengrass が実行されているエッジインフラストラクチャにデプロイします。 NVIDIA Jetson Thor などの物理ロボットコントローラーでリアルタイムの推論を行います。これらのエッジデバイスは二重の目的を果たし、リアルタイム制御のための ML 推論を実行し、包括的なセンサーデータを収集します。 AWS IoT Greengrass コンポーネントは複数のセンサータイプからのリアルタイムフィードバックを処理します。 マルチモーダルデータは 2 つの経路で処理されます。時系列テレメトリを含む MQTT メッセージ形式の構造化センサーデータは、 AWS IoT Core と Amazon Data Firehose を経由して Amazon S3 データレイクに送られます。カメラからのビデオストリームは&nbsp; Amazon Kinesis Video Streams を介してキャプチャされます。 AWS Glue クローラーは運用データをカタログ化し、 Amazon Athena を通じてクエリ可能にし、 AWS Lake Formation を介して管理可能にします。 Amazon SageMaker AI は、実世界の運用データのバッチを処理してモデルを再トレーニングおよび最適化し、sim-to-real へのギャップを明示的に埋めます。 洗練されたモデルは AWS IoT Greengrass を介してエッジデバイスにデプロイされ、動作が改善されます。モニタリングレイヤーはパフォーマンスメトリクスを継続的に追跡し、モデルドリフトを検出します。パフォーマンスが低下すると、再トレーニングワークフローがトリガーされます。これにより、システムが運用データを生成し、モデルが実世界のパフォーマンスに基づいて洗練され、改善されたモデルが再デプロイされ、サイクルが繰り返される継続的な改善が実現します。 組み立て製造における実世界のアプリケーション 電子機器製造、自動車組立、精密工学で必要とされる、歯車部品を厳密な公差で挿入するような接触が豊富な操作タスクを含む一般的な産業の課題を考えてみましょう。これらのタスクには、リアルタイムで接触力に応答する高度な制御戦略が必要です。 Universal Robots (UR) は、Isaac ライブラリの統合を通じてこの機能を示しています。彼らのロボットアームは、適応的な力フィードバックと制御戦略を使用して、穴にペグをミクロンレベルの精度で挿入します。 シミュレーションフェーズ: シミュレーションフェーズでは、エンジニアは Isaac Sim で UR ロボットアーム、ワークピースの形状、組立フィクスチャをモデル化します。また、材料特性、摩擦係数、接触力学を含む物理パラメータを定義します。Isaac Lab で強化学習を使用して、システムはドメインランダム化、挿入角度、初期位置、摩擦パラメータ、部品公差の変化を含む何千ものシナリオでトレーニングします。これにより、力制御挿入の初期ポリシーが開発され、ロボットが接触を感知し、アプローチ角度を調整し、適切な力を適用するように教えます。 導入と改良: 導入と改良では、トレーニングされたポリシーモデルは、ロボットコントローラー上の AWS IoT Greengrass を介してデプロイされます。生産テスト中、力センサー、ジョイントエンコーダ、位置センサーは AWS にリアルタイムデータをストリームします。これにより、sim-to-real へのギャップが明らかになります。例えば、実際の摩擦がシミュレーション値を超えたり、実際の部品公差がモデル化された値よりも大きく変化したりします。 Amazon SageMaker は運用データを処理します。そして、実世界の物理を考慮したモデルを再トレーニングします。エンジニアは挿入の失敗が特定の力プロファイルと相関していることを発見し、ターゲットを絞った改善を可能にします。洗練されたモデルはエッジに再デプロイされ、成功率を向上させます。この反復プロセスは、ロボットが新しいバリエーションに遭遇するにつれて継続します。モニタリングシステムは主要なパフォーマンス指標を追跡し、メトリクスが許容範囲外にドリフトしたときに再トレーニングをトリガーします。 図 2: ロボットアームギアアセンブリ デュアルパスアーキテクチャは多様なフィジカル AI アプリケーションに適用されます。組織は医薬品取り扱いのための器用な操作システム、動的な倉庫ナビゲーションのためのモバイルロボット、物流施設の人型ロボットの開発時にこれらの原則を適用できます。 成功のためのベストプラクティス 堅牢なシミュレーションから始める: &nbsp;実際のプロトタイプに基づいた物理モデルの定義に投資することが重要です。ユーザーは、強化学習のための適切な報酬関数を開発します。シミュレーションループ内で物理パラメータを反復的に調整し、プロトタイプで精度を検証することで、最良の結果が得られます。実世界へのデプロイメントの前にドメインランダム化を適用することも、堅牢なトレーニング結果をサポートする別の方法です。複数のシミュレーション反復は、物理テストよりもはるかに安価です。 段階的にデプロイする: 完全な生産の前に、制御された環境で実世界のテストを開始します。初期データでシミュレーションの仮定を検証し、重要なギャップを特定します。 包括的に計装する: 多様なセンサーをデプロイしてマルチモーダルデータをキャプチャし、物理的な検証を行います。より豊かな実世界のフィードバックにより、より効果的なモデル改良と自動再トレーニングトリガーによる継続的なモニタリングが可能になります。 シミュレーション-リアルのパリティを維持する: 実世界のデータが物理の洞察を明らかにするにつれて、シミュレーションモデルを更新して将来のトレーニングを改善します。これにより、各ドメインが他方を情報提供する美徳のサイクルを生成します。 フィジカル AI の実務への展開 ロボティクスやその他の自律システムにおける物理 AI は、研究環境から生産使用に移行しました。このリファレンスアーキテクチャは、組織が製造、物流、ヘルスケアなどを超えて実際のビジネス問題を解決する自律システムを開発するための実用的でスケーラブルな道筋を提供します。 シミュレーションベースのトレーニングの速度と安全性を実世界の学習の忠実度と組み合わせることで、組織は開発サイクルを加速し、コストを削減できます。また、運用経験を通じて継続的に改善するシステムをデプロイできます。シミュレーション優先と実世界優先の両アプローチに対応するアーキテクチャの柔軟性は、多様なユースケースと組織の準備レベルに対応します。 フィジカル AI の採用が加速するにつれて、シミュレーションと現実を効果的に橋渡しし、それぞれの強みを使用してアプリケーションを構築する組織が成功するでしょう。AWS のスケーラブルなインフラストラクチャと NVIDIA の物理シミュレーションプラットフォームにより、その未来は今日利用可能です。 始める準備はできましたか？ AWS Guidance for Physical AI for Robotics でリファレンスアーキテクチャにアクセスしてください。追加リソースについては、以下をご覧ください。物理ベースの仮想環境でのシミュレーション、テスト、合成データ生成のための NVIDIA Isaac Sim ドキュメント、エッジデプロイメントのための AWS IoT Greengrass ドキュメント、モデル開発と継続的な改良のための Amazon SageMaker AI ドキュメント、および GPU アクセラレーテッドコンピュートのための AWS Batch ドキュメントがあります。 <!-- '"` --> Srinivas Nidamarthi Dr. Srinivas Nidamarthi は、AWS の自動車および製造業ビジネスユニットにおけるフィジカル AI、ロボティクス、およびソフトウェア定義ファクトリーの GTM 製品のグローバルヘッドおよび技術ビジネス開発リードです。彼は顧客の製造業の課題を解決することに焦点を当てた製品開発をリードしています。以前、Srinivas は ABB ロボティックシステムズの CTO を務め、多様な顧客と地域にわたって高度な製造自動化ソリューションを構築しました。彼は英国ケンブリッジ大学で博士号を取得しており、デジタルファクトリーの課題に取り組むため、彼の研究と専門知識を応用しています。 Alex Mevec Alex Mevec は NVIDIA のクラウドサービスプロバイダーチームのソリューションアーキテクトであり、顧客が ML および AI ソリューションを採用するのを支援しています。彼はロボティクスとフィジカル AI を専門としています。 Ali Shahrokni Ali Shahrokni は NVIDIA のシニア開発者リレーションズマネージャーで、Amazon および AWS チームとの戦略的技術コラボレーションをリードし、高度なロボティクス、AI、およびコンピュータビジョンソリューションを構築しています。彼はスイス EPFL でコンピュータビジョンの博士号を取得しています。Amazon、eBay、Magic Leap、およびオックスフォード大学で AI、3D 再構築、シーン理解、および拡張現実のイニシアチブを推進し、最先端の研究をスケーラブルな産業アプリケーションにもたらす重要なリーダーシップおよび技術的役割を担ってきました。 Brian Kreitzer Brian Kreitzer は Amazon Web Services (AWS) のパートナーソリューションアーキテクトです。彼はパートナーと協力して、AWS 顧客向けのアクセラレータとソリューションを作成し、技術的な共同販売機会にも取り組んでいます。 Raja GT Raja GT は Amazon Web Services (AWS) のワールドワイドシニアソリューションアーキテクトです。彼は製造パートナーや顧客と緊密に協力し、技術戦略を提供し、戦略的パートナーが AWS 顧客向けの業界ソリューションを構築およびスケールアップできるようにしています。彼は AWS 製造技術フィールドコミュニティのコアメンバーであり、製造クラウド採用に関する技術ガイダンスとソートリーダーシップを提供しています。彼は航空宇宙、自動車、ヘルスケア、エネルギー産業で 20 年以上の経験があり、クラウド上の製品ライフサイクル管理、サプライチェーン、スマート製造、産業データ/AI アプリケーションを専門としています。

2026 年4 月 14 日、 AWS Interconnect – マルチクラウド の一般提供についてお知らせします。これは、 Amazon Virtual Private Cloud (Amazon VPC) を他のクラウドプロバイダーの VPC に直接接続するマネージドプライベート接続サービスです。また、 AWS Interconnect – ラストマイル もご紹介します。これは、既存のネットワークプロバイダーを通じて、ブランチオフィス、データセンター、遠隔地から AWS への高速でプライベートな接続を簡単に確立できる新機能です。 専門サービスの利用、データレジデンシーの要件への対応、さまざまなプロバイダーで標準化されたチームのサポートなど、複数のクラウドプロバイダー全体でワークロードを実行する大企業が増えています。これまで、これらの環境を確実かつ安全に接続するには、VPN トンネルの管理、コロケーション施設との連携、サードパーティのネットワークファブリックの設定など、大幅な調整が必要でした。その結果、ネットワーキングチームは、ビジネスにとって重要なアプリケーションに集中するのではなく、差別化されていない面倒な作業に時間を費やすことになります。 AWS Interconnect はこれらの課題に対する答えです。これは、AWS への接続を簡素化するマネージド接続サービスです。Interconnect を使用すると、ハイブリッドおよびマルチクラウド環境全体で、専用帯域幅を使用して AWS との間でプライベートな高速ネットワーク接続を確立できます。場所、パートナー、またはクラウドプロバイダー、優先リージョン、および帯域幅要件を選択することで、AWS コンソールを通じて数回クリックするだけで、回復力のあるエンドツーエンドの接続を簡単に設定できます。これにより、パートナーを見つける手間が省け、手動でネットワークを設定する複雑さがなくなります。 2 つの機能を備えています。1 つは AWS と他のクラウドプロバイダー間のマルチクラウド接続、もう 1 つは AWS とオンプレミスのプライベートネットワーク間のラストマイル接続です。どちらの機能も同じ原則に基づいて構築されています。つまり、チームからインフラストラクチャの複雑さを排除する、完全に管理されたターンキーエクスペリエンスです。 AWS Interconnect – マルチクラウド AWS Interconnect – マルチクラウドを使用すると、お客様の AWS 環境と他のクラウドプロバイダーとの間で、プライベートでマネージド型のレイヤー 3 接続が可能になります。最初は Google Cloud からで、Microsoft Azure は 2026 年後半にリリースされる予定です。トラフィックはすべて AWS グローバルバックボーンとパートナークラウドのプライベートネットワーク上をフローするため、パブリックインターネットを経由することはありません。つまり、物理インフラストラクチャを自分で管理しなくても、予測可能なレイテンシー、一貫したスループット、およびインターネット輻輳からの隔離が可能になります。 セキュリティはデフォルトで組み込まれています。すべての接続では、相互接続施設にある AWS ルーターとパートナークラウドプロバイダーのルーター間の物理リンク上で IEEE 802.1AE MACsec 暗号化が使用されます。これらを個別に設定する必要はありません。各クラウドプロバイダーは独自のバックボーンで個別に暗号化を管理しているため、特定のデプロイの暗号化ドキュメントをレビューして、コンプライアンス要件を満たしていることを確認する必要があることに注意してください。耐障害性も組み込まれています。各接続は、少なくとも 2 つの物理施設に分散された複数の論理リンクにまたがっているため、1 つのデバイスまたは建物に障害が発生しても接続が中断されることはありません。 モニタリングについては、AWS Interconnect – マルチクラウドは Amazon CloudWatch と統合されています。各接続には Network Synthetic Monitor が付属しており、ラウンドトリップの遅延やパケットロスを追跡したり、キャパシティプランニングをサポートする帯域幅使用率メトリクスを追跡したりできます。 AWS は基礎となる仕様を Apache 2.0 ライセンスの下で GitHub に公開しており 、あらゆるクラウドサービスプロバイダーにAWS Interconnect – マルチクラウドとのコラボレーションの機会を提供しています。AWS Interconnect パートナーになるには、クラウドプロバイダーは技術仕様を実装し、耐障害性基準、サポートコミットメント、サービスレベル契約などの AWS 運用要件を満たしている必要があります。 仕組み 接続のプロビジョニングには数分かかります。私は、AWS Direct Connect コンソールから接続を作成します。私は、AWS Interconnect セクションから始めて、プロバイダーとして Google Cloud を選択します。私は、私のソースリージョンと送信先リージョンを選択します。私は、帯域幅を指定し、私の Google Cloud プロジェクト ID を指定します。AWS はアクティベーションキーを生成し、私はこれを Google Cloud 側で使用して接続を完了します。ルートは両方向に自動的に伝達され、私のワークロードはすぐにデータの交換を開始できます。 このデモでは、私は単一の VPC から始めて、それを Google クラウド VPC に接続します。私は、Direct Connect ゲートウェイを使用します。これは最もシンプルな方法です。1 つの接続、1 つのアタッチメントであり、両側のワークロードが数分で相互に通信を開始できます。 ステップ 1: AWS マネジメントコンソール で相互接続をリクエストします。 私は、 AWS Direct Connect 、 AWS Interconnect に移動し、[ 作成 ] を選択します。私はまず、接続したいクラウドプロバイダーを選択します。この例では、Google Cloud です。 私は、次に AWS リージョン ( eu-central-1 ) と Google Cloud リージョン ( europe-west3 ) を選択します。 ステップ 3 で、私は「 説明 」を入力し、 帯域幅 、アタッチする Direct Connect ゲートウェイ 、 Google Cloud プロジェクト の ID を選択します。 リクエストをレビューして確認すると、コンソールからアクティベーションキーが渡されます。私は、そのキーを使用して、Google クラウド側でリクエストを検証します。 ステップ 2: Google Cloud Platform (GCP) アカウントでトランスポートリソースと VPC ピアリングリソースを作成します。 私にはアクティベーションキーがあり、GCP 側でプロセスを続けることに注意してください。この記事の執筆時点では、ウェブベースのコンソールは使用できませんでした。代わりに GCP コマンドライン (CLI) を使用することを選択しました。私は、 europe-west3 リージョンの GCP VPC サブネットの CIDR 範囲に注目します。次に、私はターミナルを開いて、次のように入力します。 gcloud network-connectivity transports create aws-news-blog \ --region=europe-west3 \ --activation-key=${ACTIVATION_KEY} \ --network=default \ --advertised-routes=10.156.0.0/20 Create request issued for: [aws-news-blog] ... peeringNetwork: projects/oxxxp-tp/global/networks/transport-9xxxf-vpc ... state: PENDING_CONFIG updateTime: '2026-03-19T09:30:51.103979219Z' コマンドが完了するまでに数分かかります。コマンドが返されたら、私は GCP VPC と作成した新しいトランスポートとの間にピアリングを作成します。私は、これを GCP コンソールまたは gcloud コマンドラインで実行できます。前のコマンドではターミナルを使用していたので、そのコマンドラインを続行しました: gcloud compute networks peerings create aws-news-blog \ --network=default \ --peer-network=projects/oxxxp-tp/global/networks/transport-9xxxf-vpc \ --import-custom-routes \ --export-custom-routes ネットワーク名は私の GCP VPC の名前です。ピアネットワークは前のコマンドの出力に表示されます。 完了したら、私は GCP コンソールでピアリングを確認できます。 AWS Interconnect コンソールで、私はステータスが 利用可能 であることを確認します。 AWS Direct Connect コンソールの [ Direct Connect ゲートウェイ ] に、新しいインターコネクトへのアタッチメントが表示されます。 ステップ 3: 新しいゲートウェイを AWS 側で関連付ける 私は、[ ゲートウェイの関連付け ] と [ ゲートウェイを関連付ける ] を選択して、このデモを開始する前に作成した仮想プライベートゲートウェイ (VGW) をアタッチします (インターコネクトと同じ AWS リージョンの VGW を使用する場合は注意してください)。 GCP 側でネットワークルーティングを設定する必要はありません。AWS では、最後のステップがあります。VPC ルートテーブル でルートエントリを追加して、すべてのトラフィックを Virtual Gateway 経由で GCP IP アドレス範囲に送信します。 ネットワークのセットアップが完了したら。私は、2 つのコンピューティングインスタンスを起動します。1 つは AWS 上で、もう 1 つは GCP 上です。 AWS 上で、私はセキュリティグループが TCP:8080 で受信トラフィックを受け入れることを確認しました。私は、マシンに接続し、最小限のウェブサーバーを起動します: python3 -c \ "from http.server import HTTPServer, BaseHTTPRequestHandler class H(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200);self.end_headers() self.wfile.write(b'Hello AWS World!\n\n') HTTPServer(('',8080),H).serve_forever()" GCP 側で、私はマシンへの SSH セッションを開き、プライベート IP アドレスで AWS ウェブサーバーを呼び出します。 Et voilà! 私には 2 つのネットワーク間にプライベートネットワークルートがあり、すべてが 2 つのクラウドサービスプロバイダーによって管理されています。 知っておくべきこと 覚えておくべき設定オプションがいくつかあります: ネットワークを接続するときは、両側の IP アドレス範囲に注意してください。GCP と AWS VPC の範囲は重複できません。このデモでは、AWS 上のデフォルト範囲は 172.31.0.0/16 で、GCP 上のデフォルトは 10.156.0.0/20 でした。私は、これらのデフォルト値で続行できました。 IPV4、IPV6、またはその両方を両側に設定できます。両側で同じオプションを選択する必要があります。 最大転送単位 (MTU) は両方の VPC で同じである必要があります。AWS VPC と GCP VPC のデフォルト値はそうではありません。MTU は、ネットワークインターフェイスがフラグメンテーションなしで送信できる最大パケットサイズ (バイト単位) です。ピアリングされている VPC 間の MTU サイズが一致しないと、パケットのドロップやフラグメンテーションが発生し、サイレントデータ損失、スループットの低下、インターコネクト全体での接続切断につながります。 詳細については、 GCP Partner Cross Cloud Interconnect と、 AWS Interconnect ユーザーガイド を参照してください。 参照アーキテクチャ デプロイが拡大し、1 つのリージョンに複数の VPC がある場合、AWS Transit Gateway は、1 つのインターコネクトアタッチメントを通じてそれらすべてを接続する一元的なルーティングハブを提供します。クラウドの境界を越えるものを検査する必要がある場合は、環境間でトラフィックをセグメント化し、一貫したルーティングポリシーを適用し、AWS Network Firewall を統合できます。 また、複数の AWS リージョンと複数の Google Cloud 環境全体で分散しているワークロードを使用し、グローバル規模で運用している場合、AWS Cloud WAN は同じモデルを世界中に拡張します。一元化されたポリシー管理と、運用しているすべての場所で一貫して適用されるセグメントベースのルーティングにより、ネットワーク内のどのリージョンでも世界中のあらゆる Interconnect アタッチメントにアクセスできます。 私の同僚の Alexandra と Santiago は、これらの参照アーキテクチャをブログ投稿で文書化しています:「 AWS Interconnect – マルチクラウドで回復力がありスケーラブルなマルチクラウド接続アーキテクチャを構築する 」。 AWS Interconnect – ラストマイル AWS Interconnect – ラストマイルは、AWS Interconnect – マルチクラウドと同じアーキテクチャと設計に基づいており、参加しているネットワークプロバイダーのラストマイルインフラストラクチャを通じて、 AWS マネジメントコンソール から直接、オンプレミスまたはリモートロケーションを AWS に接続できます。 オンボーディングプロセスは AWS Interconnect – マルチクラウドを反映しています。プロバイダーを選択し、認証し、接続エンドポイントと帯域幅を指定します。AWS は、お客様がプロバイダーコンソールで提供するアクティベーションキーを生成して、設定を完了します。AWS Interconnect – ラストマイルでは、2 つの物理的な場所全体で 4 つの冗長接続が自動的にプロビジョニングされ、BGP ルーティングが設定され、MACsec 暗号化と Jumbo Frames がデフォルトでアクティブ化されます。その結果、ネットワーキングコンポーネントを手動で設定しなくても、ベストプラクティスに沿った AWS への回復力のあるプライベート接続が実現します。 AWS Interconnect – ラストマイルは 1 Gbps から 100 Gbps までの帯域幅をサポートし、再プロビジョニングせずにコンソールから帯域幅を調整できます。このサービスには、Direct Connect ポートの最大 99.99% の可用性 SLA が含まれており、接続状態を監視するための CloudWatch Network Synthetic Monitor がバンドルされています。AWS Interconnect – マルチクラウドと同様に、AWS Interconnect – ラストマイルは Direct Connect ゲートウェイにアタッチされ、仮想プライベートゲートウェイ、トランジットゲートウェイ、またはAWS Cloud WAN デプロイに接続されます。詳細については、 AWS Interconnect ユーザーガイド を参照してください。 Lumen Technologies の SVP Product である、Scott Yow 氏は次のように書いています: AWS Interconnect – ラストマイルを Lumen ファイバーネットワークおよび Cloud Interconnect と組み合わせることで、クラウドの採用を遅らせることが多いラストマイルの複雑さを簡素化し、お客様にとってより迅速で回復力のある AWS へのパスを実現します。 料金と利用可能なリージョン AWS Interconnect – マルチクラウドと AWS Interconnect – ラストマイルの料金は、お客様がリクエストしたキャパシティの定額時間料金に基づいており、時間単位で請求されます。ワークロードのニーズに合った帯域幅階層を選択できます。 AWS Interconnect – マルチクラウドの料金はリージョンのペアによって異なります。米国東部 (バージニア北部) と Google Cloud 北バージニア間の接続は、米国東部 (バージニア北部) とより遠いリージョン間の接続とは料金が異なります。AWS Cloud WAN を使用する場合、グローバルな Any-to-Any ルーティングモデルでは、トラフィックが複数のリージョンを通過できるため、デプロイの総コストに影響します。接続のサイズを決定する前に、 AWS Interconnect の料金ページ でリージョンペア別およびキャパシティ階層別のフルレートカードを確認することをお勧めします。 AWS Interconnect – マルチクラウドは現在、米国東部 (バージニア北部) から Google Cloud 北バージニア、米国西部 (北カリフォルニア) から Google Cloud ロサンゼルス、米国西部 (オレゴン) から Google Cloud オレゴン、欧州 (ロンドン) から Google Cloud ロンドン、欧州 (フランクフルト) から Google Cloud フランクフルトの 5 つのリージョンペアでご利用いただけます。Microsoft Azure のサポートは 2026 年後半に開始される予定です。 AWS Interconnect – ラストマイルが米国東部 (バージニア北部) でリリースされ、Lumen が最初のパートナーとなります。AT&amp;T や Megaport など、その他のパートナーも進行中で、リージョンも追加される予定です。 AWS Interconnect の使用を開始するには、 AWS Direct Connect コンソール にアクセスし、ナビゲーションメニューから AWS Interconnect を選択します。 お客様の環境で AWS Interconnect がどのように使用されているかをぜひお聞かせください。以下にコメントを残すか、 AWS re:Post コミュニティ を通じてお問い合わせください。 – seb 原文は こちら です。

本稿は、SBI ネオバンキングシステム株式会社による AWS EKS Auto Modeの活用について、主導されたSBI ネオバンキングシステム株式会社 新藤様より寄稿いただきました。 はじめに SBI ネオバンキングシステム株式会社（以下、弊社）は、地方銀行向けのインターネットバンキングサービスをマルチテナント型 SaaS として開発・運用しています。サービス基盤には Amazon Elastic Kubernetes Service（以下、Amazon EKS）を採用しており、従来は AWS Fargate（以下、Fargate）上でワークロードを実行していました。 本記事では、2024 年 12 月の AWS re:Invent で一般提供が開始された Amazon EKS Auto Mode（以下、EKS Auto Mode）を 2025 年 9 月に導入し、AWS Fargate からの移行によって実現した運用負荷の軽減効果についてご紹介します。 SBI ネオバンキングシステムについて 弊社は、地方銀行のお客様が残高照会や振込といった銀行取引をスマートフォンやブラウザから行えるインターネットバンキングサービスを開発・運用しています。マルチテナント型の SaaS として構築しており、2026 年 3 月時点で4行の地方銀行向けにサービスを提供しています。 提供先の銀行が増えるにつれ、リリース頻度や運用イベント（バージョンアップ、パッチ適用、監視対応など）も増加するため、少人数でも安定した運用を実現できるアーキテクチャが求められていました。 システムの規模としては、3 つのアベイラビリティゾーン（AZ）を活用し、東京リージョンをプライマリ、大阪リージョンを DR（災害対策）環境とするマルチリージョン構成を採用しています。本番環境に加えて 3 つの開発環境を運用しており、合計 8 クラスターを管理しています。本番環境のクラスターでは約 60 の Pod が稼働しています。 EKS Auto Mode 導入の背景 Fargate を中心とした従来の運用には、以下の 3 つの課題がありました。 課題 1: EKS バージョンアップの運用負荷 Amazon EKS のバージョンアップでは、コントロールプレーン、アドオン、データプレーンをそれぞれ更新する必要があります。弊社の環境では、東京リージョンでは Fargate、大阪リージョンでは当時の構成上マネージドノードグループを利用していたため、コントロールプレーンとアドオンに加えてマネージドノード側の更新も含めた複数箇所を手動で操作する必要がありました。アップデート中には他の本番適用作業を並行で進めますが、手動操作のために作業が中断されてしまうことがストレスに感じていました。また、金融サービスとして安全にアップデートを実施できる仕組みの確保も重要な要件でした。 課題 2: EKS アドオンの自前管理負荷 AWS Load Balancer Controller、CoreDNS、kube-proxy といったアドオンを自前で管理していました。Amazon EKS のバージョンアップのたびにアドオンの互換性を確認し、適切なバージョンを選定・更新する作業が発生していました。 課題 3: Fargate 固有の運用負荷 Fargate 環境では、以下の運用負荷が発生していました。 Datadog サイドカーコンテナの管理 : Fargate では DaemonSet が利用できないため、各 Pod に Datadog Agent をサイドカーとして配置する必要があり、マニフェストの記述量が増加するだけでなく、サービスに直接関係しない Datadog Agent の記述が混在することでマニフェストの見通しが悪化 Fargate 組み込みログルーターの設定 : Fargate の組み込みログルーター（Fluent Bit ベース）経由で Amazon CloudWatch Logs へ転送する構成のため、Pod ごとにロググループの管理が必要 イメージキャッシュが利用不可 : Fargate ではコンテナイメージのキャッシュが効かず、Pod 起動のたびにイメージを Pull する必要があり、起動が遅延 これらの課題を踏まえ、AWS にインフラ管理をより広く委ねることで運用負荷を大幅に軽減することを目指し、EKS Auto Mode の導入を決定しました。 アーキテクチャ概要 本節では、EKS Auto Mode 導入に伴うアーキテクチャの変化を説明します。 図: 移行後のアーキテクチャ（EKS Auto Mode 構成） EKS Auto Mode で変わったこと コンピュート: Fargate から EC2（Auto Mode 管理）へ EKS Auto Mode の導入により、データプレーンが Fargate から EKS Auto Mode が管理する Amazon EC2 インスタンスへ移行しました。ノードのプロビジョニング、スケーリング、パッチ適用は AWS が自動的に管理します。EKS Auto Mode はノードのプロビジョニングにオープンソースの Kubernetes ノードオートスケーラーである Karpenter を内部で利用しており、NodePool でインスタンスタイプや有効期限などのノード仕様を定義します。弊社の環境では、ビルトインの NodePool が提供するインスタンスタイプが要件に合わなかったため、カスタム NodePool を作成してインスタンスタイプを指定しています。ノードの更新サイクル（ expireAfter ）はデフォルトの 336h （14 日）です。また、EC2 ノードではコンテナイメージのキャッシュが有効になるため、Fargate で課題だった Pod 起動の遅延も改善します。 アドオン: 自前管理からビルトインへ EKS Auto Mode では、CoreDNS、Amazon VPC CNI、Amazon EBS CSI driver が AMI に内蔵された systemd サービスとして提供され、AWS Load Balancer Controller や kube-proxy も AWS によって管理されます。これにより、アドオンのバージョン管理や Amazon EKS バージョンとの互換性確認から解放されました。 バージョンアップ: 複数箇所の手動操作からワンクリックへ 従来はコントロールプレーン、アドオン、マネージドノードの各箇所を個別に操作する必要がありました。安全なアップデートの実現手段として、ブルー/グリーンデプロイメントによるクラスター切り替えも検討しましたが、2 つのクラスターの並行運用やエンドポイント切り替えに伴う運用負荷の増加に対し、EKS Auto Mode が提供するコントロールプレーンの自動ロールバックとノードの自動更新により、インプレースでも十分な安全性を確保できると判断しました。コンソールでのワンクリックで開始した後は自動で進行し、おおむね 30 分で完了します。コントロールプレーンのアップデートに失敗した場合は自動でロールバックされ、ノードも自動で更新されます。失敗時は旧ノードが継続稼働するため、サービスへの影響を最小限に抑えられます。 監視: Datadog サイドカーから DaemonSet Agent へ Fargate では各 Pod にサイドカーとして Datadog Agent を配置していましたが、EC2 ノード上では DaemonSet として Datadog Agent を配置し、ノードの IP アドレス（ hostIP ）経由で各 Pod と通信する構成に変更しました。これにより、Fargate の組み込みログルーターも不要になりました。 同時に行ったアーキテクチャ改善 EKS Auto Mode への移行にあたっては新規クラスターを作成し、旧クラスターからブルー/グリーン方式で切り替えました。日常のバージョンアップとは異なり、Fargate からの移行に加えて NLB から ALB への集約なども含む大規模な構成変更であったため、移行時に限りブルー/グリーン方式を採用しています。従来の構成には NLB ではゼロダウンタイムのローリングアップデートが実現できない点や、Amazon API Gateway に AWS Shield Advanced を適用できず DDoS 自動緩和機能が利用できない点といった課題があったため、クラスターを新規に構築するこのタイミングに合わせて、以下のアーキテクチャ改善も実施しました。 NLB から ALB への集約 従来は Amazon API Gateway と Network Load Balancer（NLB）をテナント数分用意する構成でしたが、Application Load Balancer（ALB）1 台に集約しました。Kubernetes の Ingress リソースと ALB のグルーピング機能を活用し、1 つの ALB に複数テナントを収容しています。これにより、AWS WAF の一元管理と AWS Shield Advanced による DDoS 自動緩和の適用も可能になりました。 IaC 管理の改善 ExternalDNS をマニフェスト管理から Terraform の Helm 管理へ移行し、Datadog Agent も同様に Terraform の Helm 管理に統合しました。変更内容の見通しと再現性が向上しています。 Before / After 比較 項目 Before(Fargate) After(Auto Mode) コンピュート AWS Fargate(東京)/ マネージドノード(大阪) EKS Auto Mode(EC2) ノード管理 不要(Fargate)/ マネージドノード(大阪) AWS 自動管理(パッチ適用・スケーリング) アドオン管理 自前管理(AWS Load Balancer Controller、CoreDNS 等) AWS 管理(AMI 内蔵 systemd) バージョンアップ 複数箇所の手動操作 ワンクリックで開始 → 約 30 分で自動完了 監視エージェント Datadog サイドカー(各 Pod) Datadog Agent DaemonSet ログ転送 Fargate 組み込みログルーター → CloudWatch Datadog Agent 直接転送 LB 構成 API Gateway + NLB × テナント数 ALB × 1 導入時に直面した課題と解決策 EKS Auto Mode の導入にあたり、いくつかの課題に直面しました。以下に事象、原因、対処をまとめます。 1. セキュリティグループの追加設定 事象 : Fargate から EC2 ノードへの移行に伴い、ネットワーク通信の設定変更が必要でした。 原因 : Fargate では各 Pod に専用の ENI（Elastic Network Interface）が割り当てられるため、弊社の構成ではセキュリティグループの明示的な設定は不要でした。EC2 ノードでは複数の Pod が同一ノードの ENI を共有するため、ノードレベルでの通信許可が必要になります。 対処 : EC2 ノードのセキュリティグループに以下の許可ルールを追加しました。 データベースへの接続許可 ノード間の Pod 通信の許可 2. ASCP の Pod Identity タイムアウト 事象 : AWS Secrets Manager のシークレットを Kubernetes の Secret として Pod に注入する ASCP（AWS Secrets and Configuration Provider）で、EKS Pod Identity を使用した際に認証がタイムアウトする問題が発生しました。 原因 : EKS Pod Identity のタイムアウト値（100ms）が短すぎるという既知の問題でした。 対処 : Pod に AWS IAM の権限を付与するもう 1 つの方式である IAM Roles for Service Accounts（IRSA）に切り替えることで回避しました。 3. ALB サブネットの自動検出 事象 : EKS Auto Mode の AWS Load Balancer Controller がサブネットを自動検出できず、ALB の作成に失敗しました。 原因 : VPC サブネットに EKS クラスター識別用のタグが設定されていませんでした。 対処 : サブネットに必要なタグを追加することで、自動検出が正常に動作するようになりました。 導入効果 運用負荷の大幅な軽減 EKS Auto Mode 導入による最大の効果は、運用負荷の大幅な軽減です。構成のシンプル化と合わせ、体感としては 50 ％程度の負荷軽減を実現できたと感じています。 EKS バージョンアップの簡素化 : 以前はクラスター、アドオン、マネージドノードを含む複数箇所の操作が必要でしたが、ワンクリックで開始した後は約 30 分で自動完了するようになりました。本記事の執筆にあたり実際にバージョンアップを実施しましたが、アップデート中に何度も戻る必要がないので他の本番適用作業を中断されることなく、集中して進められました。 EKS アドオンの管理不要 : AWS Load Balancer Controller、CoreDNS、kube-proxy 等が AWS 管理となり、バージョン管理や互換性確認の作業から解放されました。 ノード管理不要 : マネージドノードを運用していた大阪リージョンについては、パッチ適用やスケーリングが自動化され、ノードの運用管理が不要になりました。これは弊社固有の事情ですが、東京リージョンと大阪リージョンの構成が同じ EKS Auto Mode 構成になったことで、リージョンを問わず同一の運用手順で対応できるようになった点も嬉しいです。 構成のシンプル化 Datadog サイドカーの廃止 : 各 Pod からサイドカーコンテナを削除し、DaemonSet に集約したことで、マニフェストの記述量が削減され、Pod 構成がシンプルになりました。 Fargate ログルーターの廃止 : Fargate の組み込みログルーターと Pod ごとの CloudWatch ロググループが不要になり、ログ転送設定が簡略化されました。 Pod 起動の高速化 EC2 ノードのコンテナイメージのキャッシュを活用できるようになり、Pod の起動時間が短縮し、スケールアウト時の応答性向上にも寄与しています。 Pod 更新・ノードパッチ適用におけるゼロダウンタイムの実現 NLB から ALB への集約と合わせてローリングアップデート時のパラメータ調整（PreStop フック、登録解除遅延など）を実施し、ゼロダウンタイムでの Pod 更新を実現しました。また、ノードへの自動パッチ適用にあたってもエラーやレスポンスの遅延が発生することなく、安定して運用できています。 コスト削減（副次的な効果） 本取り組みの主目的は運用負荷の軽減でしたが、副次的な効果としてコスト最適化にも寄与しました。 課金単位が Pod 単位（Fargate）から EC2 インスタンス単位に変化し、ノードに複数 Pod を集約できるためリソース利用効率が向上 CloudWatch Logs への転送が不要になり、ログ関連コストが削減 NLB をテナント数分用意する構成から ALB 1 台への集約により、ロードバランサーのコストが削減 今後の展望 提供先の銀行が増加していく中で、マルチテナント基盤のさらなる拡充を進めていきます。EKS Auto Mode の機能拡張にも期待しており、AWS が提供するマネージドな領域が広がることで、弊社はアプリケーション開発とサービス品質の向上により集中できると考えています。 また、ローリングアップデートの安全性向上や、ノード・スケールの最適化（状況に応じたスポットインスタンスの活用検討を含む）にも継続して取り組んでいきます。 まとめ AWS Fargate から EKS Auto Mode への移行により、少人数の体制でも、金融 SaaS としての厳格な要件を満たしながら運用負荷を大幅に軽減できました。 EKS Auto Mode は、Kubernetes のメリットを活かしつつ、クラスター運用に伴う作業負荷を AWS に委ねたい場合に有力な選択肢となります。同様の課題を抱える方々にとって、本記事が参考になれば幸いです。 著者について 新藤 泰斗 SBI ネオバンキングシステム 株式会社 プラットフォーム・エンジニアリング部 SREグループ長 地方銀行向けインターネットバンキングサービスのインフラ基盤の設計・運用を担当し、Amazon EKS を中心としたマルチテナント基盤の信頼性と運用効率の向上に取り組んでいる。

2026 年 3 月 27 日、Chat Agent や Flows をはじめとする Amazon Quick の AI Agent 機能の東京リージョンローンチを記念したイベント「Amazon Quick Event」が開催されました。本イベントでは、Amazon Quick の製品紹介や Amazon 社内での活用事例に加え、AWS パートナー企業やお客様による具体的な導入事例が共有されました。会場には多くのお客様にお越しいただき、オンラインでも多数の方にご参加いただきました。本記事では、イベントの模様をレポートします。 オープニングご挨拶 イベント冒頭では、 AWS Japan Data &amp; AI 事業統括本部 の井形健太郎がオープニングの挨拶を行いました。 本イベントの趣旨として、Amazon Quick&nbsp;が東京リージョンで利用可能になったことを紹介し、参加者の皆様への感謝を述べました。 Amazon Quick&nbsp;のご紹介と&nbsp;Amazon&nbsp;内部での活用紹介 AWS Head of GTM, APJ-C, AI &amp; Agents&nbsp;のMichael Armentano&nbsp;は、ハーバードビジネススクールの&nbsp;Karim Lakhani&nbsp;教授の言葉「AI&nbsp;を活用する人間が、AI&nbsp;を活用しない人間を置き換える」を引用し、Amazon Quick&nbsp;が目指す世界観を示しました。生成&nbsp;AI&nbsp;がチャットボットから単一エージェント、そして複数エージェンティックシステムへと進化してきた流れを解説し、Amazon Quick&nbsp;が提供する&nbsp;4&nbsp;つのチームメイト（インサイトアシスタント、データアナリスト、PhD&nbsp;リサーチャー、オートメーションエキスパート）を紹介しました。Amazon Quick&nbsp;は&nbsp;AWS&nbsp;コンソールだけでなく、Word、Outlook、Slack&nbsp;などのプラグインからもアクセス可能です。 続いて AWS Sr. WW Specialist, Amazon Quick, WWSO Generative AIの Jihwan Ko が、Amazon 社内で 20 万人以上が Amazon Quick を利用し、30 万以上のワークフロー自動化を実現している実績を紹介しました。導入にあたっては、ステップバイステップの展開、ユーザー理解に基づくユースケース選定、チェンジマネジメントの徹底、社内ユースケースライブラリの構築という 4 つの戦略を実行しました。具体的な事例として、Amazon カナダの税務チームが Amazon Quick を使い、複数システムに散在していた税務データを統合ダッシュボードに集約し、コードを書かずに情報の可視化と分析を実現した事例を紹介しました。 Chat Agent&nbsp;から始める&nbsp;Amazon Quick&nbsp;におけるデータの活用 AWS Japan&nbsp;技術支援本部&nbsp;テクニカルアカウントマネージャー&nbsp;の服部&nbsp;洋明&nbsp;は、EC&nbsp;サイトを題材にした&nbsp;3&nbsp;つのデモを通じて、チャットエージェントの活用を実演しました。デモ&nbsp;1&nbsp;の売り上げ分析では、ダッシュボードの概要把握から時間帯別・日次の特徴分析、さらに分析手法の提案まで、チャットエージェントとの対話で段階的に深掘りしていく様子を示しました。Amazon Quick&nbsp;リサーチを用いて本格的な分析レポートを自動生成する流れも紹介しました。 デモ&nbsp;2&nbsp;のサポートデスク対応では、カスタムエージェントを使い、注文ステータスの確認からマニュアル参照、Slack&nbsp;への通知、顧客への一報作成、Salesforce&nbsp;へのケース登録までを&nbsp;Amazon Quick&nbsp;の中で一気通貫で完結する内容を紹介しました。 デモ&nbsp;3&nbsp;のシステム運用では、アラートの一次調査や&nbsp;AWS&nbsp;コスト分析をチャットエージェントで効率化する様子を紹介しました。服部は「Amazon Quick&nbsp;の中で完結できていることが重要」と強調し、Amazon&nbsp;Aurora、Amazon&nbsp;CloudWatch、Google&nbsp;Drive、Salesforce、Slack&nbsp;など多様なコネクターとの連携を紹介しました。 Flows&nbsp;と&nbsp;Automate&nbsp;でデータ活用を自動化し効率アップ AWS Japan&nbsp;技術統括本部&nbsp;Sr. Solutions Architect&nbsp;加藤&nbsp;菜々美は、Amazon Quick&nbsp;の&nbsp;Flows&nbsp;と&nbsp;Automate&nbsp;を使ったデータ活用の自動化をデモで紹介しました。 Flows&nbsp;のデモでは、商品の売り上げ分析を題材に、Amazon&nbsp;S3&nbsp;や&nbsp;SharePoint&nbsp;上の散在データを専門エージェントが横断的に活用し、週次売り上げの分析からリスク判定、Notion&nbsp;への自動アラート通知、Amazon Quick&nbsp;リサーチによる深い分析レポート生成までを、ノーコードで一つのフローとして構成する様子を示しました。 Automate&nbsp;のデモでは、受注時の顧客与信リスク判定を題材に、REST API&nbsp;による基幹システム連携、AI&nbsp;エージェントによる名寄せとリスク評価、構造化アウトプットによる正確なデータ引き継ぎ、そしてリスクレベルに応じた並列処理（ローリスクは自動承認、ハイリスクはヒューマン・イン・ザ・ループで人間が介入）を実演しました。加藤は「まず&nbsp;Flows&nbsp;で小さく始めて、Automate&nbsp;で本格的な自動化にチャレンジしてほしい」とまとめました。 AWS&nbsp;の&nbsp;AI&nbsp;エージェントと一緒にチャレンジする車両保全&nbsp;DX 東急電鉄株式会社の清水 想太 氏からは、鉄道車両保全業務における Amazon Quick 活用事例を紹介いただきました。東急電鉄様は 2024 年 3 月 25 日に公表した 2024 年度 ～ 2026 年度中期事業戦略において、データ活用による DX（CX・EX・CEX）推進を掲げています。車両部では、これまで取得してきたデータの分析による故障予防と、ベテラン社員の暗黙知の形式知化を目指し、車両の走行データや故障履歴データの活用に 2023 年からチャレンジをしています。一方でデータ分析には業務経験やシステム知識、 BI ツール習得、データ集計等の負荷が伴い、高いハードルが存在しました。今回 Quick を活用し、簡単なデータクレンジングやグラフ化、仮説検証を自然言語を用いて簡単に自動化することで複数のユースケースを試みています。以下はご紹介内容の抜粋です。 （１）故障履歴のテキストデータから AI が装置名を推定・補完し、機器分類表を根拠に正しくカテゴリー分け。これまではベテラン作業員が時間をかけていた作業を約 5 分で完了し、故障による遅延防止や安全性を考慮した保全優先度の算出をサポート （２）別の AI ツールも組み合わせながら、車両のコンプレッサーデータ 378 万行を分析し、蓄圧時間の乖離から故障兆候を把握する検証 清水氏は「Amazon&nbsp;Quick&nbsp;を使うことで分析のゴールイメージが早期に見え、それが学習意欲の向上につながる」と述べられ、今後は&nbsp;AI&nbsp;とベテランの経験を組み合わせた「共存型のデータ駆動保全」の実現を目指されています。 業務改革を実現する&nbsp;Amazon Quick&nbsp;戦略&nbsp;〜個人の知見を組織知へ〜 株式会社ポーラ・オルビスホールディングスの佐々木&nbsp;哲哉&nbsp;氏からは、Amazon Quick&nbsp;を組織変革の武器として選択した戦略についてご紹介いただきました。佐々木&nbsp;氏は、AI&nbsp;活用において「個人の生産性向上」にとどまることの危険性を指摘され、RPA&nbsp;導入時の経験も踏まえ、組織の生産性に貢献できるツールとして&nbsp;Amazon Quick&nbsp;を選択いただきました。 また、Amazon Quick を選択いただいた理由を4つ挙げていただきました。第一に、ほぼすべてのシステムが AWS 環境にあるため Amazon Quick から直接データに接続できるシームレスなデータ連携が可能ということ。第二に、Amazon QuickSight の統合により「観測→解釈→実行→記録→再学習」のサイクルを回し、個人の学びを組織知へ変換できる点。第三に、お客様データへのアクセスを厳格に制御する AWS のセキュリティ設計。第四に、最適なモデル選択による将来のコスト最適化の可能性です。 2026 年度はまず 500 名に教育とセットで展開し、2027 年には本社従業員への展開を目指されています。KPI を起点に部門の枠を超えた業務プロセスの一気通貫の変革を目標とされています。 Amazon Quick&nbsp;で実現する”脱管理”と&nbsp;CRM&nbsp;の未来 ソフトブレーン株式会社の富岡 大裕 氏は、国内シェア上位の CRM/SFA 製品 eセールスマネージャーに Amazon Quick を組み込んで顧客に提供する立場からの発表をされました。同社は 2019 年から Amazon QuickSight の SaaS 埋め込み機能を活用し、ギャップ分析や行動マネジメントなどの営業データ可視化基盤として組み込みを行っており、現在は月間 15 万回以上利用されていると話されました。 ユーザーからは&nbsp;Amazon Quick&nbsp;を使っていると意識されないレベルでシームレスに統合されているとフィードバックがあるとのこと。また、SaaS&nbsp;に&nbsp;Amazon Quick&nbsp;を組み込めるレベルで豊富なインターフェースが用意されているため、企業が&nbsp;Amazon Quick&nbsp;を単純利用する際にも将来的な拡張に対応できる安心感があると強調されました。 同社では「オートインプット・ジャストアウトプット（AI-JO）」をコンセプトに、AI&nbsp;議事録からの商談情報自動反映や見積書のドラッグ＆ドロップによるデータ展開など、入力の自動化と分析の即時活用を実現されています。 富岡氏は、Amazon Quick&nbsp;のチャットエージェントで「今期の予実を出して」と話しかけるだけでグラフが自動生成される世界を示し、SFA&nbsp;が「脱管理」のツールへと進化すると展望されました。 複数社パートナー企業による&nbsp;Amazon Quick&nbsp;に関する支援内容のご紹介 後半のパートナーセッションでは、5社のパートナー企業がライトニングトーク形式で&nbsp;Amazon Quickの活用支援サービスを紹介しました。なお、本イベントでご紹介できなかったパートナー企業の&nbsp;Amazon Quick&nbsp;活用支援サービスについては、本記事末尾にリンクを掲載しておりますので、そちらもぜひご覧ください。 KDDIアイレット株式会社: Amazon Quick&nbsp;で加速させる現場の&nbsp;DX（北野涼平氏） KDDI&nbsp;グループの一員として、Amazon Quick&nbsp;の標準機能と独自のサーバーレス構成を組み合わせたデータ利活用アプローチを紹介。現場のワークフローまで見据えた設計を強みとしています。長崎ブルーエコノミー様のブリ養殖&nbsp;DX&nbsp;基盤では、IoT&nbsp;センサーデータの可視化、Bedrock&nbsp;連携による養殖場状況の言語化、画像のセキュアな組み込みを実現した事例が共有されました。 株式会社サーバーワークス:&nbsp;痒いところに手が届くサーバーワークスの&nbsp;Amazon Quick&nbsp;活用支援（村上博哉氏） Amazon Quick&nbsp;の多彩な機能から顧客のやりたいことに最適な組み合わせを提案し、すぐに使える実践的なユースケースによるジャンプスタート支援を紹介。建設業・製造業向けの入札情報の自動チェック・優先度付けや、請求書などの書類チェック業務の自動化などのユースケースに加え、初期費用無償の伴走支援キャンペーンも案内されました。 株式会社電通デジタル:&nbsp;可視化の先へ&nbsp;— Amazon Quick&nbsp;が変えるデータ分析の深さ（田中淳朗氏） 電通グループの総合デジタルファームとして、デジタルマーケティング領域で散在するデータの統合・分析を&nbsp;Amazon Quick&nbsp;で実現する支援を紹介。観光情報サイトの多言語チャットボット分析で&nbsp;Amazon Quick&nbsp;リサーチにより数十分で示唆を導出した事例を共有し、ライト・ミドル・フルコンサルの&nbsp;3&nbsp;段階の支援プランを案内されました。 株式会社&nbsp;TOKAI&nbsp;コミュニケーションズ:&nbsp;ハイブリッドクラウド活用術（山本祐也氏） 自社の専用接続回線「ブロードライン」を活用したハイブリッドクラウド構成で、オンプレミスのデータを&nbsp;FSx&nbsp;for NetApp ONTAP&nbsp;の&nbsp;S3&nbsp;アクセスポイント経由で&nbsp;Amazon Quick&nbsp;に連携するアーキテクチャを紹介。静岡・東京・大阪・名古屋・岡山の営業拠点を活かした伴走型サポートと、接続回線から運用までワンストップで対応するパッケージも案内されました。 富士ソフト株式会社: AI&nbsp;カメラと&nbsp;Amazon Quick&nbsp;で実現する新たな価値（吉田祐史氏） AI&nbsp;カメラソリューション「ビジョン&nbsp;AI&nbsp;ナビ」と&nbsp;Amazon Quick&nbsp;の連携を紹介。カメラや&nbsp;IoT&nbsp;センサーで人・設備の動きを検知し、異常検知からチャットエージェントによる対処提案、レポート自動生成、Automate/Flows&nbsp;によるフロー管理、ナレッジベースによるトラブル対応の標準化まで、検知のその先の自動化を実現する構成が示されました。 クロージング 最後に、&nbsp;AWS Japan&nbsp;Data&amp;AI&nbsp;事業統括本部&nbsp;の井形&nbsp;健太郎がクロージングを行い、東京リージョン&nbsp;GA&nbsp;の技術的意義を補足しました。 今回の&nbsp;GA&nbsp;により、Amazon Quick&nbsp;の推論処理通信が国内に閉じるようになり、企業データを生成&nbsp;AI&nbsp;で活用する際のセキュリティ・コンプライアンスが大きく向上しました。 ただし、インターネット検索機能のみ海外リージョンで処理されるため、必要に応じて機能をオフにすることが可能です。日本語サポートについては UI・チャット入力・対象データいずれも対応済みで、実用上快適にご利用いただけるレベルであると説明しました。また、生成 AI 実用化推進プログラムとして、お客様の生成 AI の利活用を加速させるための支援プログラムとして、モデルカスタマイズコースとモデル活用コースの 2 つを紹介しました。 パートナー Expo 今回ライトニングトークに参加いただいたパートナー企業5社による、それぞれの強みを活かしたAmazon Quickの活用のデモンストレーションを行いました。 アイレット：デザインからインフラまでワンストップ、現場のワークフローを見据えた一気通貫の支援 サーバーワークス：痒いところに手が届く実践的なユースケース提供と伴走支援 電通デジタル：最大規模のデジタルファームとして、データを「動かす」ための段階的支援 TOKAIコミュニケーションズ：ハイブリッドクラウドと地方企業への伴走型支援 富士ソフト：エッジとクラウドの両面から AI カメラ × Amazon Quick で現場 DX を実現 おわりに 本イベントでは、 Chat Agent や Flows をはじめとする Amazon Quick の AI Agent 機能の東京リージョンローンチ という節目に、製品の全体像から社内活用事例、お客様による実践的な導入事例、そしてパートナー企業による支援サービスまで、幅広い内容が共有されました。鉄道車両の保全 DX、化粧品企業の組織変革、CRM/SFA への組み込みなど、業種を超えた多様なユースケースが紹介され、Amazon Quick がビジネスの現場で具体的な価値を生み出しつつあることが実感できるイベントとなりました。 AWS&nbsp;ジャパンは、今後も&nbsp;Amazon Quick&nbsp;をはじめとする生成&nbsp;AI&nbsp;サービスの活用支援を通じて、お客様のビジネス変革を後押ししてまいります。 本ブログは、テクニカルアカウントマネージャーの服部洋明が担当しました。

本ブログは 株式会社スギ薬局様 とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの吉田です。 「生成 AI を業務に活用したいが、一過性の PoC で終わってしまう」「成果を組織全体に広げるにはどうすればいいか」——こうしたご相談をいただく機会が増えています。 今回ご紹介するのは、株式会社スギ薬局様の事例です。現場の業務課題と技術を組織として結びつけながら、 Amazon Bedrock を活用した年末調整 QA ボットと調剤医薬品在庫確認エージェントを構築されました。これらの成果が次の AI 活用を呼ぶサイクルが回り始め、AI 利活用が組織に根付いていく過程をご紹介いたします。 企業概要とデジタル変革への取り組み 株式会社スギ薬局様は、ドラッグストアと調剤薬局を全国に展開する企業です。近年、ドラッグストア・調剤薬局業界では、薬剤師不足や調剤・介護領域への事業拡張を背景に、経営統合や M&amp;A による規模拡大が進んでいます。スギ薬局様もグループ再編により調剤薬局が合流し、店舗数・従業員数がさらに拡大しました。 こうした事業環境の変化に対応するため、スギ薬局様は DX を積極的に推進しています。各務 CDO は、DX の方針・ビジョンについて次のように語ります。 「会社の OS をアップデートし、2030年までに AI DX を外部に提供できる武器へ進化させる」ことです。デジタル技術で効率化し、創出した「可処分時間」を人間らしい接客に再投資できるようにします。組織横断の「サービス型チーム」を核に、自律的に人が成長し続ける場作りを目指しています。 組織体制：OneSUGI PJ × CTO as a Service このビジョンを実現するため、スギ薬局様では DX・AI 推進本部のもと、業務課題の把握から技術的な解決までを組織的に推進する体制を構築しています。 OneSUGI PJ ：現場の業務課題を集約・精査し、ソリューションのリリースまでを主導します。 CTO as a Service ：技術アドバイザーとして、課題に対する最適なソリューションの方向性を提案します。 AI 推進部 ：CTO as a Service の技術方針をもとに実装・運用を担い、OneSUGI PJ にサービスを提供します。 この体制により、現場のニーズと技術的な実現性を両輪で回せる仕組みが確立されています。 図：スギ薬局様の AI 活用推進体制 以降でご紹介する年末調整 QA ボットと調剤医薬品在庫確認エージェントは、この組織体制から生まれた具体的な AI 利活用の取り組みです。 取り組み①：年末調整 QA ボット 課題 スギ薬局様では毎年、年末調整期間中に派遣社員6〜7名をローテーションで雇用し、人事部と合わせて約10名体制で年末調整に対する社内電話問い合わせ対応を行っていました。昨今のグループ再編により対象者が約4,000人増加し、問い合わせ件数のさらなる増大が見込まれていました。 こうした状況の中、人事部から「AI による問い合わせ対応業務の効率化を、年末調整が始まるタイミングに間に合わせたい」という要請があり、約1ヶ月後までに RAG チャットボットを用意する必要がありました。まず世間で評判の高いツールを評価しましたが、既存のデータソースに対応しておらず、別の手段を検討することになりました。 解決策：Bedrock Chat による迅速な構築 既存データソースを用いた RAG を実現したいという明確な目的と、人事部側である程度ボットを管理したいというニーズがありました。そこで採用したのが、 Bedrock Chat です。 Bedrock Chat は、Amazon Bedrock を基盤とした AWS のサンプルチャットアプリケーションです。 ワンクリックで AWS 上にデプロイ でき、Web UI から RAG 用のナレッジ追加やボットのカスタマイズが可能です。人事部側でファイルの追加やボットの編集ができるため、運用負荷を最小限に抑えられる点が決め手となりました。 RAG のデータソースには年末調整 FAQ リストを使用し、社員1人が2日で環境を構築、人事部と連携して数日でリリースを実現しました。この際、スギ薬局様の運用要件に合わせたカスタマイズは、AI コーディングアシスタントの Kiro を活用して実施しました。 図:実際の年末調整 QA ボットの利用イメージ。従業員が年末調整に関する質問を入力すると、FAQ を検索する様子。 成果 年末調整 QA ボットは年末調整の期間中、約40日間の稼働で以下の成果を上げました。 定量的な成果： 指標 結果 問い合わせ処理件数 期間を通して約2万件 人事工数の削減 1件10分換算で3,000時間以上 入電率の変化 1.21% → 1.08%（対象者が約4,000人増加したにもかかわらず低下） 電話対応体制 昨年と同じ約10名体制で問題なく対応 コスト SaaS 製品では1,200万円かかる想定だったところを、AWS のマネージドサービスを活用して社員1人が2日で構築し運用費は約10万円程度に収まった 定性的な成果： 年末調整 QA ボットは現場から好評を得ました。ボットのクローズ後には、人事全般の問い合わせサポートツールとしての利活用検討が開始されたほか、他部門からも問い合わせ対応に AI エージェントを活用したいという要望が上がるようになりました。 また、年末調整シーズンの終了後には本ボットのリソースを削除しています。必要な時に立ち上げ、不要になれば停止できるクラウドの従量課金モデルを活かし、迅速かつコストを最小限に抑えた運用を実現しました。4万人を超える従業員が利用対象となる一方、一人あたりの利用頻度は限定的です。こうした利用パターンには、ユーザ単位で課金される完成型のサービスよりも、Amazon Bedrock のトークン単位の課金をはじめとする AWS の従量課金モデルがマッチしていました。 今回構築した環境は役目を終えましたが、「AI でここまでできる」という体験が社内に広まり、次の取り組みを加速させることになります。 取り組み②：調剤医薬品在庫確認エージェント 課題 年末調整 QA ボットの好評も追い風に、OneSUGI PJ への次の AI 活用案件として調剤医薬品在庫確認エージェントが舞い込みました。 調剤薬局のグループ統合直後、在庫管理システムは会社間で統合されておらず、調剤薬局の薬剤師が近くのスギ薬局店舗に電話をかけて在庫を確認していました。電話がつながれば数分で済む作業ですが、実際には「相手が忙しくて対応できない」「忙しいだろうから遠慮して電話しづらい」という心理的な課題を抱えていました。 薬剤には使用期限があるため過剰に在庫を置くことはできず、普段の消費ペースにない薬剤は欠品になりやすい状況です。患者様に必要なお薬をお渡しできなければ、他の薬局に足を運んでいただくことになり、患者様への負担は大きくなります。 解決策：基幹システムデータを活用した AI エージェント まず年末調整 QA ボット同様 Amazon Bedrock による RAG を検討しましたが、構造化された在庫データに対しては毎回結果が異なり、期待する回答を得られなかったため、別のアプローチを模索しました。 最終的に採用したのは、Text2SQL のアプローチです。エージェントフレームワークには Amazon Bedrock Agents を選びました。フルマネージドで運用負荷が低く、モデル呼び出しと Lambda の実行費用のみで済むため、限られた時間の中でツール開発という本質的な価値提供にフォーカスできる点が決め手となりました。自然言語の問い合わせを SQL に変換し、データウェアハウスである Amazon Redshift に集約された在庫データを検索する構成としました。 図：調剤医薬品在庫確認エージェントのシステム構成 この構成の肝は、基幹システムに蓄積されたエンタープライズデータ（在庫データ・店舗マスタ・医療薬品マスタ）を AI エージェントから直接活用できることです。AWS 上にデータ基盤と AI 基盤が共存しているからこそ、お客様ご自身で迅速かつ手軽にデータ活用を実現することができました。なお、データへのアクセス制御については、全店舗共通で参照可能なカラムのみを対象とし、Lambda 関数の中でアクセス範囲を制限する設計としています。 Text2SQL の精度は、LLM の性能だけでは決まりません。既存のデータマートスキーマの正確な理解、業務用語のプロンプトでの伝え方、生成された SQL の評価方法——これらを短いサイクルで試行錯誤しながら求める回答精度へとチューニングしていくことが重要でした。また、短期間で評価・改善を繰り返すために、近隣店舗の検索には Amazon Location Service を活用し、フロントエンドには年末調整 QA ボットでも利用した Bedrock Chat の Agent 連携機能 を用いて迅速に構築しています。 図：実際の在庫確認エージェントの利用イメージ。薬剤師が店舗名と薬品名を入力すると、対象店舗および近隣店舗の在庫数と位置関係が返されます。 成果 約1ヶ月で構築し、200店舗に公開。2026年4月初旬から本番展開を開始しています。 現場では AI エージェントに対する抵抗感はなく、年配の方もスムーズに問い合わせができています。 最も大きな変化は、業務フローそのものの転換です。 Before After 在庫確認の方法 近くの店舗に電話 AI エージェントに問い合わせ 心理的な障壁 「忙しいだろうから遠慮して電話しづらい」 自分のタイミングで気兼ねなく検索 情報の範囲 電話した1店舗の情報のみ 近隣店舗の在庫と距離を一覧で把握 お客様の声 各務様コメント（取締役 / DX・AI推進本部長 兼 CDO）： 今後も AI の本質を理解し、そこに対応をできる組織力が勝負になると考えています。何故ならばその組織力は1日ではできないためです。AI がその組織力強化にも一役買ってくれると考えており、その視点で使い倒していく予定です。 有路様コメント（DX・AI推進本部 AI推進部 課長）： 技術選定では、世の中の事例にある製品を実際に利用して比較しました。その結果、AWS が最も精度が高く、導入とランニングコストが一番安いと判断しました。日々アップデートがある中で安定して業務に利用するには苦労もありますが、評価の結果安定していると判断したら導入メリットは高いので、今後も積極的に試行錯誤して業務改善へと活用していきたいと思っています。 高階様コメント（DX・AI推進本部 OneSUGI PJ リーダー）： AI を特別なものではなく、店舗や本部の日常業務に溶け込む当たり前のツールとして浸透させることを重視しています。現場起点での活用と小さな成功体験の積み重ねを通じて、主体的に AI を使いこなす文化の醸成を進めています。今後も現場に寄り添いながら、変革を着実に推進していきます。 今後の展望 スギ薬局様では、在庫確認エージェントを調剤薬局の全店舗に展開し、現場からのフィードバックをもとに改善を進めていく予定です。 また、数年後には数百の AI エージェントを本部メンバが自ら構築できるようになることをゴールとしています。その基盤として Amazon Bedrock AgentCore の活用も検討いただいています。 まとめ 今回は、スギ薬局様が組織横断のチームで現場業務課題と技術を結びつけ、Amazon Bedrock を活用して年末調整 QA ボットと調剤医薬品在庫確認エージェントを構築した事例をご紹介しました。 特に注目すべきは、以下のサイクルが組織として回っている点です。 組織体制の確立 ：業務課題と技術をつなぐ体制を整備する 現場課題の集約 ：OneSUGI PJ が現場の声を拾い上げる 技術による迅速な解決 ：CTO as a Service が最適なソリューションを短期間で選定する 成果が次の取り組みを加速 ：成功体験が社内に広まり、新たな AI 活用の要望につながる AI 活用を成功させるには、技術だけでなく、業務課題と技術をつなぐ組織体制が鍵です。スギ薬局様の取り組みは、AI を組織に根付かせたいと考えている多くの企業にとって、参考になる事例ではないでしょうか。 AI 活用推進の体制づくりを含め、生成 AI の業務利用や、業務データを活用した AI エージェントの構築にご興味・ご関心のあるお客様は、ぜひ AWS までお気軽にご相談ください。 著者 吉田 英史 は、東海地方を中心に小売・消費財業界のお客様を支援しているアマゾンウェブサービスのソリューションアーキテクトです。身の回りの生活に欠かせない様々なビジネスをクラウドで加速するお手伝いができることを、何より嬉しく感じています。

本記事は「 Planview saves 40+ hours per audit cycle by automating SOC 2 compliance with Kiro CLI 」を翻訳したものです。 コンプライアンス管理は、時に圧倒的な負担に感じることがあります。多くのエンジニアリングチームにとって、継続的に大きな注意を払い続ける必要がある業務です。チームは年間サイクルごとに 40 時間以上をかけてエビデンスを収集し、クラウドプロバイダーのコンソールを操作し、監査期限が迫る中でスプレッドシートを作成しています。 戦略的ポートフォリオ管理のリーダーとして世界中で 3,000 社以上の顧客にサービスを提供する Planview も、同じ課題に直面していました。マルチサービスの AWS インフラストラクチャ全体で SOC 2 コンプライアンスを維持するために、顧客向けの機能開発に充てるべきエンジニアリング時間が消費されていたのです。ここでは、Planview が Kiro CLI を使ってコンプライアンスワークフローをどのように変革し、コンプライアンスサイクルあたり 40 時間以上を削減したかをご紹介します。 コンプライアンスは大変 Kiro 導入前の Planview のコンプライアンス管理は、以下のような状況でした。 エンジニアが手動でエビデンスを収集 — 20 以上のクラウドサービスにまたがり、コンソールや API からデータを取得していました。 チームがスプレッドシートの発掘作業を実施 — セキュリティコントロール、タイムスタンプ、監査証跡を追跡していました。 監査準備サイクルに 40 時間以上を消費 — エンジニアをプロダクト開発から引き離していました。 複数のチームメンバーにまたがる調整オーバーヘッド — クラウドプロバイダーと SOC 2 要件の両方に精通した専門知識が必要でした。 クラウドコンプライアンスを管理する多くのエンジニアリングチームが、同様の課題に直面しています。監査に費やす時間、コンテキストスイッチ、手動エラーの可能性、四半期サイクルの計画が、コストを複合的に増大させています。 コンプライアンスへの新しいアプローチ Planview は、また別のコンプライアンスダッシュボードを構築するのではなく、異なるアプローチを選びました。Kiro CLI を使って、コンプライアンスの自動化を開発ワークフローに直接組み込んだのです。 当初、Planview の SOC 2 コンプライアンスプロセスは完全に手動で、セキュリティチームとエンジニアリングチームに多大な時間とリソースを要していました。コンプライアンスワークストリームの効率化のため、チームは 2025 年第 1 四半期に商用の継続的コンプライアンスプラットフォームを評価しました。Planview は長期的には継続的コンプライアンス機能の導入を計画していますが、フル商用プラットフォームのオーバーヘッドなしに迅速に価値を提供できる暫定的なソリューションが必要でした。このニーズに Kiro は最適でした。Kiro は Planview の既存ワークフローに直接統合され、フルコンプライアンスプラットフォームへの移行の道を閉ざすことなく、すぐに自動化のメリットを提供しました。 Kiro CLI でカスタムコンプライアンスエージェントを作成する Planview は、Kiro CLI の組み込み aws ツールとカスタムエージェント機能を使用して、クラウドサービスへのきめ細かな読み取りアクセスを設定しました。Kiro のカスタムエージェントを使うと、ユースケースに合わせた特定のコンテキストとツール権限を持つ、目的特化型の AI アシスタントを作成できます。Planview の場合、SOC 2 コンプライアンスワークフローに関連する技術的エビデンスを取得するために、クラウドサービスへの事前承認済みの読み取り専用アクセスを持つエージェントを作成しました。事前承認とは、エージェントが各読み取り操作に対して手動の承認を必要としないことを意味します。これにより、監査サイクルやエビデンス収集タスクごとに手動で権限を付与する必要がなくなり、以前は 40 時間以上かかっていた手動プロセスが自動化されたワークフローに変わりました。この統合は読み取り専用の非侵襲的なアクセスで動作するため、インフラストラクチャのセキュリティは確保され、変更されることはありません。これはコンプライアンスに限った話ではありません。例えば、CloudWatch メトリクス、S3 バケット設定、Lambda 関数ログをクエリするインフラストラクチャ監視用のカスタムエージェントを作成し、AWS サービスへの事前承認済み読み取りアクセスを付与して、運用ヘルスレポートを自動生成することもできます。 カスタムエージェントの作成方法 と 設定例 をご覧ください。 以下の例は、 ~/.kiro/agents/soc2-compliance.json に保存するカスタム soc2-compliance エージェント JSON の参考例です。これを SOC 2 コンプライアンスプロセスを支援するアシスタントとして活用でき、CLI で kiro-cli --agent soc2-compliance （またはカスタムエージェント名）を使って起動できます。 { "name": "soc2-compliance", "description": "セキュリティコントロール、監査準備、ポリシー適用のための SOC 2 コンプライアンスアシスタント", "prompt": "file://./prompts/soc2-expert.md", "tools": [ "read", "write", "aws" ], "allowedTools": [ "read" ], "toolsSettings": { "write": { "allowedPaths": [ "docs/compliance/**", "policies/**", "audit/**", "security/**" ] }, "aws": { "allowedServices": [ "iam", "cloudtrail", "config", "guardduty", "securityhub", "inspector", "kms", "s3" ], "autoAllowReadonly": true } }, "resources": [ "file://policies/**/*.md", "file://docs/compliance/**/*.md", "file://audit/**/*.json", "file://security/controls/**/*.yaml" ] } この JSON は、セキュリティコントロール、監査準備、ポリシー適用を支援するために設計された特化型エージェント設定を定義しています。各セクションの意味は以下の通りです。 name — エージェントの識別子/名前 description — エージェントの目的を説明する人間が読める説明文（SOC 2 コンプライアンス業務） prompt — エージェントのシステム指示/動作を含むマークダウンファイルへのパス（ ./prompts/soc2-expert.md ） tools — エージェントがアクセスできるツール: read（組み込みツール）— ファイル/ディレクトリの読み取り write（組み込みツール）— ファイルの作成/変更 aws（組み込みツール）— AWS CLI 呼び出し allowedTools — ユーザー承認を必要としないツール（ここでは read のみ自動承認。write と aws は確認が必要） toolsSettings — 各ツールのきめ細かな権限設定: write.allowedPaths — エージェントが書き込みできるディレクトリを限定（コンプライアンスドキュメント、ポリシー、監査ファイル、セキュリティファイル） aws.allowedServices — エージェントが操作できる AWS サービスを限定（IAM、CloudTrail、Config、GuardDuty、SecurityHub、Inspector、KMS、S3 — すべてセキュリティ/コンプライアンス関連） aws.autoAllowReadonly — 読み取り専用の AWS 操作（describe-*、list-*、get-* など）は承認不要 resources — エージェント起動時に自動的にコンテキストに読み込まれるファイル: ポリシーのマークダウンファイル コンプライアンスドキュメント 監査 JSON ファイル セキュリティコントロール YAML ファイル あるいは、エージェント設定 JSON を手動で作成する代わりに、Kiro CLI の /help エージェントを使用できます。これは、自然言語の説明からスマートなエージェント設定の推奨を生成する組み込みアシスタントです。Kiro CLI 内で /help Help me create a custom agent for soc-2 compliance を実行すると、Kiro が SOC 2 コンプライアンスを支援するための初期ドラフトを自動的に生成します。 /help Help me create a custom agent for soc-2 compliance を実行すると、以下のことが起こります。 Kiro は組み込みの /help エージェントに切り替わります。これは Kiro CLI に関する質問に答え、設定を生成するために特化されたエージェントです。 /help エージェントは Kiro の内部ドキュメントを参照して正しいエージェント設定スキーマを検索し、生成される設定が有効なフィールドを使用し、ベストプラクティスに従っていることを確認します。 /help エージェントは、ツール、権限、リソースパターン、カスタマイズされたシステムプロンプトを含む推奨設定を、手動の JSON 作成なしに生成します。必要に応じてこれを調整できます。 Kiro CLI でカスタムエージェントを使用する 開発者がターミナルで kiro-cli --tui --agent soc2-compliance を使ってこのカスタムエージェントを起動すると、チャットセッション開始時に「aws」ツールの allowedServices、resources、allowed paths のコンテキストと権限が読み込まれます。 --tui フラグを使用すると、Kiro CLI の新しい UX が読み込まれます。通常の kiro-cli ターミナル体験を使用したい場合は、 kiro-cli --classic --agent soc2-compliance を使用するか、Kiro ターミナル内で /agent soc2-compliance を使用できます。 プロンプト例: 「すべての S3 バケットの暗号化ステータス、パブリックアクセス設定、アクセスログ設定を示す SOC 2 CC6.1 コンプライアンスレポートを生成してください。」 Kiro の機能を活用して、Planview は SOC 2 および ISO エビデンスのタイムスタンプ収集を簡素化しました。システムがタイムスタンプ付きの情報を取得できるようになり、Kiro は以下を自動的に実行できるようになりました。 すべてのリージョンにわたる S3 設定のクエリ、または同じ結果を生成するクエリの実行を支援するスクリプトの作成 暗号化設定とキー管理の確認 アクセスコントロールリストとバケットポリシーの検証 タイムスタンプ付きのフォーマットされたコンプライアンスエビデンスの生成 エージェントが複雑さを処理し、チームは必要なエビデンスを取得できます。 注意: AI が生成するコンプライアンス出力は、エージェントに提供されるプロンプトの具体性と範囲に大きく依存します。これは監査プロセスを加速するためのツールであり、決定論的なコンプライアンスツールの代替となるものではありません。AI が生成したすべての推奨事項、ポリシーテキスト、監査エビデンスは、本番環境での使用や監査人への提出前に、資格のあるコンプライアンス専門家によるレビューと検証を受ける必要があります。 成果 以前は手動でのデータ収集が必要だった作業が、自動的に行われるようになりました。Kiro はタイムスタンプ付きのコンプライアンスエビデンスを取得し、上記の AWS 許可サービスを使用してセキュリティスキャンを実施し、特定の SOC 2 および ISO コントロール要件に沿ったアーティファクトを整理します。 このワークフローは、開発環境の変更を必要とせずに Planview の既存プロセスに統合されます。以前は手動だったエビデンス収集が、Kiro CLI の組み込みツールを通じて実行され、フィードバック用の対話型インターフェースが提供されます。Planview チームは、すぐに大きく測定可能な効果を実感しました。 コンプライアンスサイクルあたり 40 時間以上を削減 — 節約された時間は、エビデンス収集ではなく顧客価値の構築に活用されています。 自動化による全体的な効率 60% 向上 — チームは監査リクエストに 3〜4 倍速く対応できるようになりました。 チームメンバーあたり 1〜1.5 SDE スプリント分の時間を節約 — 機能開発や改善に振り向けられています。 オンデマンドのエビデンス収集 — 特定の時間を確保するのではなく、年間を通じて監査に備えることができます。 しかし、本当の成果は、エンジニアリングリソースが本来あるべき場所に戻ったことです。スプレッドシートの作成ではなく、プロダクトの構築に集中できるようになりました。 まとめ Planview のアプローチは、コンプライアンス業務が負担である必要はないことを示しています。コンプライアンス要件を仕様として提供し、AI を開発ワークフローに直接組み込むことができます。 カスタムエージェント のような機能は、セキュリティ基準を維持しながら、チームが顧客への価値提供に集中できるよう支援します。 Planview は、コンプライアンス管理以外のユースケースにも Kiro CLI のカスタムエージェントの活用を拡大しています。これにより、組織全体のより多くの開発者が再現可能なワークフローを使用し、効率化の効果を倍増させることができます。 Kiro CLI を 今すぐ 始めましょう。

前回の Week in Review に、2026 年、お客様との AI-Driven Development Lifecycle (AI-DLC) ワークショップに多くの時間を費やしたことを書きました。これらのセッションに共通するテーマは、コストの可視性を高める必要があるということです。チームは AI の導入を急速に進めていますが、実験段階から本番環境に移行するにつれ、財務部門と経営陣は、誰がどのリソースをどの程度のコストで使用しているかを把握する必要があります。だからこそ 2026 年 4 月 13 日週、 Amazon Bedrock による IAM ユーザーとロール別のコスト配分のサポートの開始 を知って、とてもワクワクしました。これにより、IAM プリンシパルにチームやコストセンターなどの属性をタグ付けし、それらのタグを請求およびコスト管理コンソールでアクティブにすることができます。結果のコストデータは AWS Cost Explorer と詳細なコストと使用状況レポートに送信されるため、モデル推論の支出を明確に把握できます。チーム間でエージェントをスケールする場合でも、部門ごとに基盤モデルの使用状況を追跡する場合でも、 Claude Code on Amazon Bedrock のようなツールを実行する場合でも、この新機能は AI 投資の追跡と管理に大きな変革をもたらします。この設定に関する詳細は、 IAM プリンシパルコスト配分ドキュメント に記載されています。 それでは、2026 年 4 月 13 日週の AWS ニュースを見ていきましょう。 ヘッドライン Amazon Bedrock が Claude Mythos Preview の提供を開始 これまでで最も洗練された Anthropic の AI モデルを、Project Glasswing を通じてゲート付きリサーチプレビューとして Amazon Bedrock で利用できるようになりました。Claude Mythos は、サイバーセキュリティに焦点を当てた新しいモデルクラスを提供します。これにより、ソフトウェアの高度なセキュリティ脆弱性を特定し、大規模なコードベースを分析して、サイバーセキュリティ、コーディング、複雑な推論タスク全体で最先端のパフォーマンスを実現できます。セキュリティチームはこれを利用して、脅威が出現する前に重要なソフトウェアの脆弱性を発見して対処することが可能になります。現在、アクセスは許可リストに登録されている組織に限定されており、Anthropic と AWS はインターネットクリティカルな企業やオープンソースのメンテナーを優先しています。 エージェントの検出とガバナンスを一元化するための AWS Agent Registry (現在プレビュー中) AWS は Amazon Bedrock AgentCore を通じて Agent Registry を立ち上げました。AI エージェント、ツール、スキル、MCP サーバー、カスタムリソースを発見して管理するためのプライベートカタログを組織に提供しています。レジストリは、セマンティック検索、キーワード検索、承認ワークフロー、CloudTrail 監査証跡により、チームが既存の機能を重複することなく見つけるのを支援します。AgentCore Console、AWS CLI、SDK からアクセスできます。また、IDE からクエリ可能な MCP サーバーとしてアクセスすることも可能です。 2026 年 4 月 6 日週のリリース 2026 年 4 月 6 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 S3 バケットをファイルシステムとしてアクセス可能にする Amazon S3 Files の発表 – Amazon S3 Files は S3 バケットを、任意の AWS コンピューティングリソースと S3 データを直接接続する共有ファイルシステムに変換します。Amazon EFS テクノロジーに基づいて構築されているため、低レイテンシーのパフォーマンスで完全なファイルシステムセマンティクスを提供し、使用頻度の高いデータをキャッシュして、1 秒あたり数テラバイトの総読み取りスループットを実現します。アプリケーションは、コードを変更したりデータを移行したりすることなく、ファイルシステムと S3 API の両方から同時に S3 データにアクセスできます。 Amazon OpenSearch Service が Managed Prometheus とエージェントトレースのサポートを開始 – Amazon OpenSearch Service は、メトリクス、ログ、トレース、AI エージェントトレースを 1 つのインターフェイスに統合した、統合型オブザーバビリティプラットフォームの提供を開始しました。このアップデートには、Prometheus のネイティブ統合と PromQLクエリの直接サポート、RED メトリクスのモニタリング、LLM 実行の可視化を実現する OpenTelemetry GenAI セマンティック規約サポートが含まれています。運用チームはツールを切り替えることなく、スロートレースをログに関連付け、ダッシュボードに Prometheus メトリクスをオーバーレイすることができます。 Amazon WorkSpaces Advisor が AI を活用したトラブルシューティングで利用可能に – AWS は Amazon WorkSpaces Advisor を立ち上げました。これは、生成 AI を使用して IT 管理者が Amazon WorkSpaces パーソナルデプロイのトラブルシューティングを行うのに役立つ、AI を活用した管理ツールです。WorkSpace の設定を分析し、問題を自動的に検出して、サービスの復旧とパフォーマンスの最適化に役立つ推奨事項を提示します。 Amazon Braket が Rigetti の 108 量子ビット Cepheus QPU のサポートを追加 – AmazonBraket は、プラットフォーム上の最初の 100 量子ビット以上の超伝導量子プロセッサである Rigetti の Cepheus-1-108Q デバイスへのアクセス提供を開始しました。モジュラー設計は、位相誤差に対する耐性が強化された CZ ゲートを備えた、12 個の 9 量子ビットチップレットを備えています。Braket SDK、Qiskit、CUDA-Q、Pennylane などの複数のフレームワークをサポートしており、研究者向けのパルスレベル制御も可能です。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS のニュース こちらは、皆さんが関心を持つと思われる追加の記事とリソースです。 Amazo S3を使用した自動 AWS リージョン可用性チェックの構築 – Amazon S3をコアインフラストラクチャとして使用し、AWS リージョン全体でサービスの可用性を監視する自動化システムの実装に関するストレージブログ記事です。 Amazon Bedrock モデルのライフサイクルの理解 – 機械学習のブログ記事では、Bedrock の基盤モデルが入手可能になったり廃止されたりするまでの段階について説明しています。これは、チームがモデルのアップデートを計画したり、本番環境でのバージョン依存関係を管理したりするのに役立ちます。 AWS Lambda Managed Instances を使用したメモリ集約型アプリの構築 – コンピューティングのブログ記事では、Lambda マネージドインスタンスがプラットフォームを軽量ワークロード以上に拡張し、サーバーレスのメリットを維持しながらメモリを大量に消費するアプリケーションをサポートする方法について説明しています。 OpenClaw を AWS でデプロイ: お客様の AI ワークロードに適したオプションを選択 – Builder Center ガイドでは、OpenClaw の 4 つの AWS デプロイオプションを比較しています。4 つのオプションとは、個々のデベロッパー向けの Amazon Lightsail、より深い AWS 統合を必要とするスタートアップ向けの Amazon EC2、サーバーレスのマルチユーザーシナリオ向けの Amazon Bedrock AgentCore、VM レベルの分離と高度なオーケストレーションを必要とするエンタープライズ向けの Amazon EKS です。 Kiro スタートアップクレジットプログラム復活のお知らせ – Kiro はスタートアップクレジットの取り組みを再開します。対象となる初期段階の企業は、Kiro Pro+ を最大 1 年間無料で利用できるようになります。3 段階のプログラム (Starter、Growth、Scale) は、チームの規模に応じて 2〜30人のユーザーを対象としています。また、ローリングアプリケーションは世界中で受け付けています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS の次のイベント (4 月 28 日、バーチャル) 午前 9 時 (太平洋標準時) に配信されるこのライブストリームに参加して、エージェンティック AI がビジネスの運営方法をどのように変えているかについて率直に議論しましょう。AWS CEO の Matt Garman、SVP の Colleen Aubrey、OpenAI のリーダーが、新しいエージェント機能、Amazon 社内での経験、新しいエージェンティックソリューションとプラットフォーム機能について語ります。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026 年 4 月 13 日週のニュースは以上です。2026 年 4 月 27 日週にお届けする次回の Weekly Roundup もお楽しみに! – Micah 原文は こちら です。

AI の業務活用が広がる中、多くの企業が次の課題に向き合っています。個別の AI 活用は始まっているものの、組織全体として推進する仕組みが追いついていない。「何から手をつけるべきか」が見えにくい ― そんな声は少なくありません。 パナソニック エレクトリックワークス株式会社 （以下、同社）も、こうした課題意識のもとで動き出した企業の一つです。同社は、電気設備を起点に、Well-Being や Energy Management などの新たな価値を創出し、持続可能な豊かな社会づくりに挑戦しています。その中で、ソフトウェア開発領域での AI 活用も積極的に推進してきました。 2026 年 4 月、同社はAI・クラウド開発センター（以下、AICDC ）を新設しました。AICDC は「AI 技術活用によるソフトウェア開発に変革を起こし、ソリューション事業を加速する」をミッションに掲げ、活動を開始しています。本記事では、AICDC の立ち上げに向けて同社が取り組んだ AI 駆動開発ライフサイクルの実践 ( AI-DLC Unicorn Gym ) と AI 成熟度診断 ( AI Foundation Pack ) について、その内容と得られた気づきをご紹介します。 AI 駆動開発ライフサイクルの実践 ― AI-DLC Unicorn Gym AICDC の立ち上げに向けて、同社は新組織に必要な準備を多面的に進めました。その一つとして、2026 年 1 月に AWS と連携して、 AI 駆動開発ライフサイクル（以下、 AI-DLC ）を組織的に実践するワークショップ型プログラム「AI-DLC Unicorn Gym」を実施しました。AI-DLC は、AI を開発プロセスの中心に据え、企画から実装までをチーム全員で協働しながら高速に進める開発手法です。同社の企画と開発から計35 名が参加し、4 つのチームが実際のプロダクトや新規サービスに関する課題をテーマに取り組みました。実質 2.5 日という限られた時間の中で、全チームが動作するシステムの初期版を完成させています。 参加した企画部門と開発部門の組織責任者からは、こんな声が聞かれました。 「古来から企画と設計は異なる人種で何かと衝突が起こり、折り合いがつかない場面を数多く目の当たりにしてきました。しかしこの 3 日間で、それが解消する第一歩になったと感じています」 「エンジニアが高度なレベルを要求されることを体感し、仕事の基本に立ち返れたのではないでしょうか。今日が始まりだと思って引き続きやっていきましょう」 AI-DLC の実践を通じて見えてきたのは、AI が開発の中心になることでエンジニアにはより高い技術的判断が求められるようになること、そして企画と開発が一体となってチーム全体で価値を生み出す働き方が可能になるということです。同社にとって、AI 活用がもたらす開発プロセスの変化を実感する機会となりました。 Unicorn Gymの様子　（AI-DLC の詳細については、 こちらの Blog をご参照ください。） AI 成熟度診断の実践 – AI Foundation Pack もう一つの取り組みとして、同社は 2026 年 3 月に AI Foundation Pack を実施しました。これは、AWS Cloud Adoption Framework for AI（以下、CAF-AI）に基づく成熟度アセスメントを中心とした AWS の Professional Services が提供するプログラムで、今回が日本で初めての実施となりました。同社が、ビジネス目標の一つとして掲げる顧客新価値創造の達成に向けて、ソフトウェア開発領域に焦点を当てて実施しています。 CAF-AI は、プラットフォーム、セキュリティ、オペレーションといった技術面に加え、ビジネス、ピープル、ガバナンスといった非技術面も含む 6 つのパースペクティブから、AI 活用に必要な組織能力を体系的に評価するフレームワークです。 CAF-AIの概念図（CAF-AI の詳細については、 こちらの Blog をご参照ください。） AI Foundation Pack は 2 日間のプログラムとして実施されました。当日の議論を円滑に進めるため、AICDC の部課長等が 6 つのパースペクティブに沿ったアセスメントシートに事前回答しています。 Day 1 では、新組織である AICDC のセンター長、各部長、課長クラスのメンバーや、関連する部門である R&amp;D 、IT の部門メンバーなどのステークホルダーが一同に会し、ワークショップ形式でアセスメントを実施しました。普段は個別に業務を進めている関係者が、AI 活用の現状と課題、目指す姿について同じテーブルで対話することが、新組織の土台となる目線合わせの場となりました。 Day 2 では、アセスメント結果をもとに AWS から施策の方向性とロードマップ案を提示し、参加者全員で優先度を議論しました。 アセスメントで見えたこと Day1 のアセスメントの結果、同組織の AI 活用は初期段階にあることが確認されました。ただし、これは同組織に限った話ではありません。AWS がグローバルで約 100 社に実施してきたアセスメントにおいても、多くの企業が同様の段階からスタートしています。重要なのはスコアそのものではなく、現在地を把握した上で目指す姿とのギャップを特定し、取り組みの優先順位付けに活用していくことです。また、定期的にアセスメントを実施することで、取り組みの進捗を定量的に把握し、必要に応じて施策の見直しに活かすこともできます。 アセスメントを通じて、同組織の現状が 6 つのパースペクティブで構造的に整理されました。パナソニックグループとして AI に関する規定や方針は示されており、今後の取り組みの方向性を支える土台となっています。一方で、AI 活用における戦略や推進体制、現場で運用できる粒度のガイドライン、人材の役割定義など、組織横断で取り組むべき領域が明確になりました。 優先実施事項を議論する Day 2 のワークショップでは、アセスメント結果をもとに参加者全員で優先度マッピングワークを実施しました。ビジネス目標への貢献度と実現性の 2 軸で各テーマをマッピングし、「最初の 3〜6 ヶ月で何に取り組むべきか」を議論しました。 この議論の中で、特に優先度が高いテーマとして位置づけられたのが、AI 活用戦略の策定と推進体制の構築でした。まず戦略を定め、それを推進する体制を整えることが、他の施策を進める上での土台になるという認識が共有されました。加えて、人材育成において既存の組織体制の中に AI スキルを組み込んでいく方向性や、AI 活用に伴うガバナンスやセキュリティの整備も重要な論点となりました。 AWS からは他社の事例も紹介され、AI CoE の立ち上げからユースケース展開までの時間軸や、共通する進め方のパターンが共有されました。自社だけでは見えにくい課題の優先度や取り組みの時間軸の目安を得られたことで、より現実的な計画策定に繋がります。 この 2 日間を通じて、まず AI 活用戦略の策定から着手し推進体制を構築していくことが、次のアクションとして明確になりました。 これからの AI・クラウド開発センター ― 益子部長インタビュー 2026 年 4 月に新設された AICDC で、クラウドソリューション開発と AI 活用推進を担当する益子部長にお話を伺いました。 ― AI Foundation Pack では、ステークホルダーが一同に会してアセスメントと優先度の議論を行いました。この 2 日間を通じて、特に価値を感じた点はどこでしたか？ 価値を感じたのは、AI 活用の目指す姿とレベル感を関係者全員で共有できたことです。 もし AI Foundation Pack がなかったら、AI 駆動開発の標準化と育成しかやっていなかったかもしれません。中期計画に書かれた項目を、各自が重要だと思うものから個別に進めるだけの状態が続いていたと思います。今回、CAF-AI のフレームワークを使うことで、AI 活用に必要な能力や体制、目指す姿、活用レベルを関係者全員で認識合わせできました。また、プログラムの事前準備を通じて、新組織が担うべきミッションの範囲を社内関係者とすり合わせられたことも良かったです。Day 2 では優先度を議論し、まず小さく PoC から始めて標準化へと進むステップを合意できました。自分たちのレベルに合った進め方を、センター長を含めた全員で議論して決められたことに、大きな意味があったと思っています。 ― AICDC が始動しました。今後の取り組みへの思いと、AWS への期待をお聞かせください。 AI やデータをしっかりと使いこなせる組織にしていきたいです。そのために、AWS には引き続き伴走していただきたいと思っています。アカウントチームや Professional Services のメンバーに伴走していただくことで、課題や取り組みに対する支援はもちろん、第三者視点でのレビューや助言をいただけることが大きなメリットだと感じています。アカウントチームとの接点を多く持てており、当社への理解が深まっていると感じているからこそ、今後も当社のビジネスの背景や課題、AICDC のミッションを理解した上での提案を期待しています。 また、グローバルで活動されている AWS だからこそ知っている最先端の知見を共有いただき、私たちもキャッチアップしていきたいです。サービス面でも、業務がより楽に、より安全に進められるものをこれからもどんどん出していってほしいと思っています。 後列 左から2人目より… AICDC 益子氏、向井氏、川本氏 まとめ AI 活用をビジネス成果に繋げていくためには、個別のツール導入や PoC だけでは十分ではありません。AI 活用における戦略と目標を策定し、経営陣を含めた関係者間で合意して進めていくこと。そのためにまず、自社の現在地を客観的に把握し、「何から始めるか」を議論することが重要なステップになります。同社の取り組みが、同じ課題に向き合う企業の皆様にとって何かの参考になれば幸いです。 AICDC（AI・クラウド開発センター）の挑戦はまだ始まったばかりです。AWS は、AI-DLC による開発プロセスの変革支援、AI Foundation Pack による成熟度アセスメントと戦略策定の伴走、そして様々な Coding Agent の活用支援を通じて、パナソニック エレクトリックワークス社の AI ネイティブなエンジニア組織への変革をこれからも共に歩んでまいります。 パナソニック エレクトリックワークス株式会社の企業ページは こちら 著者について &nbsp; 佐山 朝葉 (Sayama Asaha) ソリューションアーキテクト 製造業のお客様をご支援しています

本記事は「 Kiro CLI 2.0: a new look and feel, headless CI/CD pipelines, and Windows support 」を翻訳したものです。 ターミナルで作業する開発者にとって、ワークフローに合ったツールが必要です。その逆ではありません。だからこそ私たちは Kiro CLI を開発しました。Kiro CLI は、そのまま使えるエージェント型ターミナルで、高品質なコードをより速くリリースできます。ローンチ以来、皆さんから素晴らしい反響をいただきました。気に入った点、改善が必要な点、そして足りない機能について教えていただきました。 私たちはその声に耳を傾け、本日、皆さんからリクエストの多かった 3 つの大きな機能をリリースしました。 ヘッドレスモード : CI/CD パイプラインなどで Kiro CLI をプログラム的に実行し、リリースをより速く行えます。 Windows サポート : お気に入りの Kiro エージェントを、Windows でネイティブに使用できます。 UX リフレッシュ、GA として正式リリース : 摩擦を減らし、より多くのコントロールを提供します。 ヘッドレスモードでデプロイメントをエンドツーエンドで自動化 開発者にはコーディング時の柔軟性が必要です。ターミナルで Kiro CLI を実行するのは簡単で、 kiro-cli と入力するだけです。しかし、自分がいない場所でリモート実行したい場合はどうでしょうか？ ヘッドレスモードがそれを変えます。API キーを生成し、環境変数として設定するだけで、Kiro CLI をプログラム的に実行できます。入力をパイプで渡し、出力をスクリプト化し、Kiro を CI/CD パイプライン、ビルドスクリプト、またはあらゆる自動化ワークフローに直接統合できます。インタラクティブセッションで利用できるすべてのツール、エージェント、機能に、プログラムからアクセスできます。プルリクエストの生成と公開や、トラブルシューティングワークフローの実行など、ローカルでのユーザー入力なしにプロンプトを実行でき、真の自動化を実現します。これにより、デプロイメントを継続的に監視するのではなく、イノベーションに集中できます。 ヘッドレス CLI の具体的な使用例を紹介するブログ記事 もご覧ください。 Windows サポート：あなたの作業環境に合わせて これは個人的にも思い入れがあります。Windows ユーザーとして、ネイティブサポートがなく WSL などの回避策を使わなければならないフラストレーションを理解しています。しかし、もうその必要はありません。Kiro CLI のネイティブ Windows インストーラーが利用可能になったことを、とても嬉しく思います。これにより、Kiro CLI へのアクセスが大きく広がります。 Windows Terminal アプリ内で Kiro エージェントを使用して、複雑なコードベースで機能を構築し、ワークフローを数秒で自動化し、エラーの分析やバグの追跡を正確に行えます。 CLI をインストール して始めましょう： macOS、Linux、または Windows でインストール curl -fsSL https://cli.kiro.dev/install | bash UX リフレッシュ：摩擦を減らし、コントロールを強化 3 月に新しい TUI を実験的にローンチして以来、多くの素晴らしいフィードバックをいただきました。当時はクラシック UX の機能をすべてカバーできていませんでしたが、早期のフィードバックを求めたところ、皆さんが応えてくれました。気に入った点、足りない点、さらに見たい機能を指摘していただきました。それ以降、新しいサブエージェント体験とその進捗を監視する方法、そして新しいタスクリスト（todo リストの強化・更新版）をリリースし、エージェントの動作を簡単に追跡できるようにしました。また、多くの細かい問題も修正しました。 新しいサブエージェント体験とタスクリストの実際の動作を見てみましょう。この例では、サブエージェントを使ってスネークゲームを構築しています。サブエージェントは、親エージェントのコンテキストを保護しながら作業を並列化するためによく使用されます。 サブエージェントのアクティビティを監視するには、 ctrl+g を使用します。各サブエージェントの完全なトレースを確認しながら、すべてのサブエージェントのステータスも確認できます。この場合、デザイナー → 実装者 → レビュアーのフローを順番に実行しているのがわかります。以下はデザイナーが作業中の様子です。 そして、こちらはレビュアーが権限の昇格を要求している様子です。権限の承認は、エージェントモニター（黄色でハイライト表示）とメインオーケストレーター画面の両方で確認できます。 エージェントが作業を進めると、各ステップが完了するたびにタスクリストがリアルタイムで更新されます。この例では明示的にタスクリストの使用を指示しましたが、エージェントは大きなタスクではデフォルトでタスクリストを使用します。 以上のように、Kiro は新しいサブエージェント体験と新しいタスクリスト体験の両方を使ってスネークゲームを構築しました。ぜひ試してみて、サブエージェントとタスクリストがどのように機能するか確認してください。ユースケースが複雑になるほど、タスクリストの価値を実感できるでしょう。Kiro が何を達成したかをすぐに把握できます。 おわりに CLI 2.0 と TUI がデフォルトの体験になりました。何か違和感があれば、 /feedback でお知らせください。皆さんのフィードバックが上記のすべてを形作り、次に来るものも形作ります。また、以前の体験に戻したい場合は、 kiro-cli --classic を実行するだけです。詳細については、 ドキュメント をご確認いただき、 Discord の Kiro コミュニティ に参加して、他のビルダーとつながり、ベストプラクティスを共有し、テクニカルサポートを受け、最新機能の情報を入手してください。コミュニティが皆さんの成功をサポートします。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2026年 2 月号 はお読みいただけましたでしょうか。皆さんのお役に立つ内容があれば幸いです！ はじめに、Amazon Connect について改めてご紹介します。Amazon Connect は、AI を中核に据えたコンタクトセンターソリューションです。音声・チャット・メール・タスクなど複数のチャネルを一つのプラットフォームに統合し、顧客とエージェントの双方にシームレスな体験を提供します。規模を問わず導入でき、Amazon のサービス体験を支える基盤技術を活用できます。 今月は 以下の内容でアップデート情報をお届けします。 2026 年 3 月のアップデート一覧 AWS Contact Center Blog のご紹介 今月のアップデートに関するよくある質問 1. 2026 年 3 月のアップデート一覧 Amazon Connect のクイックレスポンスをルーティングプロファイルごとに制御できる？タグベースアクセス制御の新機能 – 2026/03/28 Amazon Connect のクイックレスポンスで、ルーティングプロファイルの割り当てにタグベースアクセス制御（TBAC）が適用されるようになりました。これまでは、管理者がタグベースアクセス制御を設定してクイックレスポンスを構成しても、ルーティングプロファイルのタグに関係なく、すべてのエージェントがクイックレスポンスを利用できる状態でした。今回のアップデートにより、管理者は TBAC の権限に基づいて、特定のルーティングプロファイルにクイックレスポンスを割り当てることが可能になり、他の Amazon Connect リソースと同じレベルのアクセス制御を適用できます。TBAC を使用して Amazon Connect リソースへのアクセスを管理している組織は、同じアクセス制御をクイックレスポンスの割り当てにも適用できるようになりました。例えば、コンプライアンスチームが管轄地域ごとにルーティングプロファイルにタグを付け、地域固有の開示テンプレートなどの規制関連クイックレスポンスを対応するプロファイルに割り当てることで、エージェントが自分の役割に最も関連性の高いコンテンツのみを参照できるようになります。 管理者ガイド Amazon Connect のクイックレスポンス タグベースのアクセス制御 Amazon Connect の音声 AI エージェントがロンドンリージョンで使える？新ボイス3種も追加 – 2026/03/18 Amazon Connect のエージェント型 Speech-to-Speech 音声体験が、新たに欧州（ロンドン）リージョンで利用可能になりました。また、米国スペイン語と英国英語の新しい Speech-to-Speech ボイスが3種追加されました: Pedro（es-US）、Amy（en-GB）、Brian（en-GB）。 Amazon Connect のエージェント型セルフサービス機能は、AI エージェントが音声およびメッセージングチャネル全体で顧客の意図を理解し、推論し、アクションを実行することで、日常的なタスクから複雑なカスタマーサービス業務までを自動化します。Speech-to-Speech 音声 AI エージェントは、顧客が「何を言ったか」だけでなく「どのように言ったか」も理解し、顧客のトーンや感情に合わせて音声応答を適応させながら、自然な会話のペースを維持します。今回のアップデートにより、新しいリージョンでより幅広いボイスの選択肢を使って、エージェント型 Speech-to-Speech 音声体験を顧客に提供できるようになりました。 管理者ガイド Amazon Connect のサポートリージョン Amazon Connect の音声 AI エージェントは何言語に対応している？新たに13言語が追加で合計40言語に – 2026/03/18 Amazon Connect の音声 AI エージェントが新たに13言語をサポートし、対応言語は合計40のロケールになりました。新しく追加された言語は以下の通りです: アラビア語（サウジアラビア）、チェコ語、デンマーク語、オランダ語（ベルギー）、英語（アイルランド）、英語（ニュージーランド）、英語（ウェールズ）、ドイツ語（スイス）、アイスランド語、ルーマニア語、スペイン語（メキシコ）、トルコ語、ウェールズ語。 Amazon Connect のエージェント型セルフサービス機能は、AI エージェントが音声およびデジタルチャネル全体で顧客の意図を理解し、推論し、アクションを実行することで、複数の言語にわたって日常的なタスクから複雑なカスタマーサービス業務までを自動化します。 管理者ガイド Amazon Connect のサポート言語 Amazon Connect の生成 AI テキスト読み上げボイスはどのリージョンで使える？新リージョン3つと新ボイス9種が追加 – 2026/03/18 Amazon Connect の生成 AI テキスト読み上げ（Generative Text-to-Speech）ボイスが、新たに3つの AWS リージョンで利用可能になりました: 欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シドニー）。また、米国英語、英国英語、欧州フランス語、ドイツ語、イタリア語にわたる9つの新しい生成 AI テキスト読み上げボイスが追加されました: Tiffany（en-US）、Amy（en-GB）、Brian（en-GB）、Ambre（fr-FR）、Florian（fr-FR）、Tina（de-DE）、Lennart（de-DE）、Beatrice（it-IT）、Lorenzo（it-IT）。 管理者ガイド Amazon Connect のサポートリージョン Amazon Connect のサポート言語 Amazon Connect のエージェントはメールを外部アドレスに転送できる？エージェントワークスペースからの直接転送が可能に – 2026/03/17 Amazon Connect のエージェントが、エージェントワークスペースおよびコンタクトコントロールパネル(CCP)から、メールコンタクトを外部メールアドレスや配信リストに直接転送できるようになりました。メールを転送した後も、エージェントは元のコンタクトの所有権と完全なコミュニケーション履歴を保持します。これにより、エージェントはバックオフィスチーム、専門家（SME）、パートナー、その他の関係者をシームレスに巻き込みながら、顧客にとって一貫した単一の窓口であり続けることができます。 管理者ガイド Amazon Connect のメール機能 メールチャネルのコンタクトを外部 E メールアドレスに転送する Amazon Connect でマネージャーがエージェントをコーチングできる？統合ワークフローが新登場 – 2026/03/12 Amazon Connect に、コンタクトセンターのマネージャーがエージェントに対してタイムリーかつ的確なフィードバックを Connect の UI 上で直接提供できる、統合エージェントコーチングワークフローが追加されました。マネージャーは評価スコアカードを通じて改善の機会を特定した際、具体的な顧客対応の事例を含むコーチングプランをその場で作成できます。例えば、問題解決には優れているものの顧客への共感をもう少し示すべきエージェントに対して、該当する対応事例と今後使える共感的な表現の例を共有することができます。コーチングセッション後、エージェントはフィードバックを確認し、期待事項や次のステップについての理解を示すメモを追加します。マネージャーとエージェントの双方が、すべてのコーチング履歴を単一のページで確認でき、体系的な進捗管理とコーチング効果の向上が可能になります。この統合アプローチにより、コーチングの遅延が解消され、エージェント育成プロセス全体を通じたアカウンタビリティが確立されることで、コンタクトセンター運営全体のパフォーマンス改善が加速します。 管理者ガイド Amazon Connect のエージェントコーチング Amazon Connect でメール送信時に差出人アドレスを選べる？キューごとの複数アドレス設定が可能に – 2026/03/12 Amazon Connect で、受信メールへの返信や新規アウトバウンドメッセージの送信時に「差出人（From）」メールアドレスを選択できるようになりました。これにより、コンタクトセンターはすべての顧客対応で正しいブランドやビジネスのアイデンティティを使用できます。管理者はキューごとに複数の送信元アドレスを設定でき、エージェントは担当しているキューに基づいて適切なメールアドレスを検索・選択できます。この機能は、単一の Amazon Connect インスタンスから複数のブランドやビジネスラインをサポートしているコンタクトセンターに特に有用です。 管理者ガイド Amazon Connect のメール機能 メール送信時の送信元アドレスの選択 Amazon Connect のケースデータを分析データレイクで活用できる？Athena や Quick でのレポート作成が容易に – 2026/03/12 Amazon Connect の分析データレイクでケースデータが利用可能になり、レポートやインサイトの生成がより簡単になりました。ケースデータが他の Amazon Connect 分析データと並んで利用できるようになったことで、Amazon Athena や Amazon Quick を使用して、複雑なデータパイプラインを構築・維持することなく、カスタムレポートの作成やトレンド分析が可能です。例えば、タイプ別のケース件数、エージェントシフトをまたいだケース処理状況、ケース全体のコンタクトセンチメントなどを分析できます。 管理者ガイド Amazon Connect Cases Amazon Connect 分析データレイク 分析データレイクにおけるケースデータテーブル Amazon Connect の AI 予測インサイトはどこまで進化した？商品カタログ8倍・精度14%向上の強化アップデート – 2026/03/11 Amazon Connect の AI を活用した予測インサイトの機能強化が発表されました。この強化により、企業はプロアクティブでパーソナライズされた顧客体験を大規模に提供しやすくなります。re:Invent 2025 で発表された5つのレコメンデーションアルゴリズムをベースに、AI 予測インサイトは最大4,000万件の商品カタログアイテムをサポートするようになり（従来の8倍）、トリガーベースキャンペーンのメッセージテンプレートでも利用可能になったほか、モデル精度が最大14%向上しました。これらの強化により、企業は適切なメッセージを適切なタイミングで自動的に顧客に届けることができ、AI パーソナライゼーションの展開に必要な時間も短縮されます。企業はトリガーベースキャンペーンを活用して、顧客の行動や予測シグナルに基づいたパーソナライズされたアウトリーチを開始できるようになりました。例えば、顧客がカートを放棄した際に商品レコメンデーションを送信したり、購入後に補完的なサービスを提案したりすることが可能です。また、予測された嗜好や行動に基づいて、特定の顧客コホートに対するターゲットキャンペーンも配信できます。モデル精度の向上とトレーニング時間の短縮により、企業はパーソナライズされた体験をより迅速に、かつ顧客に提供するレコメンデーションへの信頼性を高めた状態で展開できます。 管理者ガイド Amazon Connect Customer Profiles AI 予測インサイト Amazon Connect のメールでも会話分析ができる？自動分類・PII リダクション・要約生成に対応 – 2026/03/11 Amazon Connect のメールコンタクトで会話分析（Conversational Analytics）がサポートされるようになりました。コンタクトセンターのマネージャーは、メールの自動分類、個人識別情報（PII）の墨消し、コンタクト要約の自動生成が可能になります。これにより、新たなトレンドの迅速な特定、機密情報の保護によるコンプライアンスの維持、エージェントのパフォーマンスレビューにかかる時間の短縮が実現します。例えば、顧客がアカウントの問題についてメールを送信すると、Amazon Connect が自動的にメールを分類し、機密情報を墨消しし、スーパーバイザーのレビュー用に要約を生成します。この機能を有効にするには、コンタクトフローに「記録分析と処理動作を設定」ブロックを追加し、「チャネルを選択」で「E メール」を指定した設定を行います。メールチャネルの会話分析を活用して、カテゴリの割り当て、タスクの作成、ケースの更新などのアクションを自動的にトリガーするルールを迅速に作成できます。 管理者ガイド Amazon Connect の会話分析 Amazon Connect E メールの会話分析 PII リダクションの設定方法 Amazon Connect のマネージャー向け AI アシスタントとは？自然言語で150以上のメトリクスを即座に分析 （プレビュー） – 2026/03/10 Amazon Connect から、コンタクトセンターのマネージャーが自然言語を使って運用に関する質問に即座に回答を得られる AI アシスタントのプレビューが発表されました。エージェントのスケジューリング、セルフサービス体験、パフォーマンス評価を含む 150 以上の Amazon Connect メトリクスに対して、すべての履歴データを使ったクエリが可能で、結果は数秒で返されます。これにより、手動でのデータ収集に費やしていた数時間が不要になります。さらに、このアシスタントはサービスレベル目標を達成できないリスクのあるキューの特定や、具体的なリカバリーアクションの推奨など、根本的な問題の診断も行えます。この機能はプレビューとして提供されています。 2. AWS Contact Center Blog のご紹介 Amazon Connect と Amazon Lex によるセルフサービス導入と継続改善：JBR コンタクトセンターの業務効率化の取り組み Amazon Connect と Amazon Lex でコンタクトセンターのセルフサービス化はどこまでできる？ 年間約32万件の生活救急対応を行う JBR（ジャパンベストレスキューシステム）が、パートナー店からの業務連絡窓口に音声ボットを導入した事例です。約16,000件の会話データを分析・改善し続けた結果、5ヶ月でエラー率を46%から18%に削減、ボット完結率は目標の75%を達成しました。さらに Amazon Bedrock による会話要約をエージェント画面に表示することで、後処理時間の短縮にもつなげています。 Kiro で Amazon Connect AI エージェント開発を加速 (日本語翻訳) Amazon Connect の AI エージェント開発を短期間で実現するには？ Kiro を活用し、15 のバックエンド API を統合する AI エージェントを通常 2〜3 週間かかるところ、わずか 3 日間で構築した事例です。仕様駆動設計によりアーキテクチャ設計を 1〜2 時間に短縮し、15 の Lambda 関数を一貫したパターンで自動生成。CloudWatch Logs の自動分析で、デプロイからデバッグ・修正までのイテレーションサイクルを 10〜20 分で回すことで、高速な開発を実現しています。 Managing Amazon Connect flows as Code with AWS CDK (英語記事) Amazon Connect のコンタクトフローを IaC で管理するには？ Amazon のカスタマーサービスチームが AWS CDK を使い、数百のコンタクトフローをコードとして管理する方法を紹介しています。従来の JSON 定義に代わり、型安全な TypeScript のビルダーパターンで可読性と保守性を大幅に向上。ビルド時のバリデーション、再利用可能なコンポーネント、複数インスタンスへの自動デプロイにより、デプロイ・メンテナンス時間を数日から数分に短縮した事例です。 Build Unified Voice, Video and Chat Communications with Amazon Connect (英語記事) Amazon Connect で音声通話中にチャットやファイル共有もできる？ 音声・ビデオ通話とチャットを同一エージェントとの1つのやり取りに統合するソリューションの構築方法を紹介しています。例えば、ローン申請の電話中にエージェントが書類を送信し、顧客がその場で署名して返送するといった体験が実現できます。StartWebRTCContact API と DescribeContact API を組み合わせ、通話中のエージェント ID をチャットのルーティングに渡すことで、チャネルをまたいでも同じエージェントが対応し続ける仕組みです。 3. 今月のアップデートに関するよくある質問 Q. Amazon Connect とは何ですか？ A. Amazon Connect は、AI を中核に据えたクラウドコンタクトセンターソリューションです。音声・チャット・メール・タスクなど複数のチャネルを一つのプラットフォームに統合し、あらゆる規模の企業で利用できます。( Amazon Connect について ) Q. Amazon Connect で AI 機能を使うと料金が高くなりませんか？ A. Amazon Connect では Unlimited AI という料金プランが選択可能です。このプランでは、会話分析、パフォーマンス評価、画面録画、エージェントスケジューリング、Amazon Lex や Connect AI エージェントによる AI 音声・チャット対応、生成 AI テキスト読み上げなど、すべての AI 最適化機能がチャネル料金に含まれる包括的な価格体系になっています。AI 機能ごとに個別課金される アラカルトによるプランも選択でき、インスタンスごとにプランを変更することも可能です。いずれのプランも初期費用や長期契約は不要で、使った分だけの従量課金です。（ Amazon Connect の料金 ） Q. Amazon Connect のタグベースアクセス制御（TBAC）とは何ですか？ A. タグベースアクセス制御（TBAC）は、Amazon Connect のリソースにタグ（キーと値のペア）を付与し、そのタグに基づいてアクセス権限を管理する仕組みです。例えば、部門や地域ごとにタグを設定することで、管理者が担当範囲のリソースのみを操作できるように制御できます。今月のアップデートでは、クイックレスポンスのルーティングプロファイル割り当てにも TBAC が適用されるようになりました。（ タグベースのアクセス制御 ） Q. Amazon Connect の会話分析（Conversational Analytics）ではどのようなことができますか？ A. 会話分析は、コンタクトの内容を自動的に分類し、個人識別情報（PII）の墨消し、コンタクト要約の自動生成を行う機能です。音声やチャットに加え、今月のアップデートでメールチャネルにも対応しました。分析結果をもとに、カテゴリの割り当てやタスクの作成などのアクションを自動トリガーするルールも作成できます。（ Amazon Connect の会話分析 ） Q. Amazon Connect の分析データレイクとは何ですか？ A. 分析データレイクは、Amazon Connect のコンタクトデータを一元的に蓄積し、Amazon Athena や Amazon Quick で直接クエリ・分析できる機能です。複雑なデータパイプラインを構築することなく、カスタムレポートの作成やトレンド分析が可能になります。今月のアップデートでケースデータも分析データレイクに追加されました。（ Amazon Connect 分析データレイク ） 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。Amazon Connect の最新情報は毎月このブログでお届けしていますので、来月号もお楽しみに。 著者プロフィール &nbsp; 梅田　裕義（Hiroyoshi Umeda） アマゾンウェブサービスジャパン合同会社 シニア Amazon Connect ソリューションアーキテクト 2020年12月入社。コンタクトセンター領域を専門に、Amazon Connect を活用した顧客体験の向上や業務効率化の技術支援を行っています。AI によるセルフサービスの導入、オムニチャネル対応、分析基盤の構築など、企業のコンタクトセンターが抱える課題解決に幅広く取り組んでいます。

Spec-Driven Presentation Maker は、「何を伝えるか」を先に設計し、スライドの構築を AI に委ねるオープンソースのサンプル実装です。本記事では、仕様駆動アプローチの考え方と、AWS 環境への導入方法をご紹介します。 プレゼン資料、「伝えたいこと」から作れていますか 多くの組織で、プレゼンテーション資料の作成は日常的な業務です。提案書、社内報告、技術共有、経営会議の資料 — いずれも、限られた時間の中で「伝わる資料」を作る必要があります。 しかし実際には、白紙のスライドを開いてから完成するまでの時間の多くが、レイアウトの調整、フォントや色の選定、図表の配置といった「見た目の作業」に費やされています。本来最も重要な「何を、どの順序で、なぜ伝えるのか」というメッセージの設計は、作業の合間に考えることになりがちです。 その結果、見た目は整っているものの、核心のメッセージが伝わりにくい資料ができあがることがあります。あるいは、構成が定まらないまま作り始めたために、途中で大幅な手戻りが発生することもあります。 この課題は、資料作成のプロセスそのものに起因しています。 AI に「作って」と言うだけでは解決しない理由 近年、生成 AI を活用したスライド作成ツールが登場しています。「プレゼン資料を作って」と指示すれば、AI がスライドを生成してくれる — 一見すると、前述の課題を解決できるように思えます。 しかし、AI に漠然とした指示を出した場合、生成される資料は「それらしい見た目」にはなるものの、伝えたいメッセージの論理構造や、聞き手に合わせた情報の取捨選択が不十分になりがちです。これは、AI が「何を伝えるべきか」の判断を十分に行えないまま、「どう見せるか」の作業に進んでしまうためです。 つまり、従来の手作業でも AI 任せでも、「設計なき資料作成」という根本的な課題は変わりません。必要なのは、メッセージの設計と、スライドの構築を明確に分離するアプローチです。 仕様駆動プレゼンテーションという考え方 Spec-Driven Presentation Maker は、ソフトウェア開発で広く実践されている「先に設計してから作る」という考え方を、プレゼンテーション資料の作成に応用しています。 ソフトウェア開発では、コードを書き始める前に要件定義や設計書を作成します。同様に、仕様駆動プレゼンテーションでは、スライドを作り始める前に「何を伝えるか」の設計書（仕様）を先に作成します。 ただし、設計書を一人で書き上げる必要はありません。AI との対話を通じて、聞き手の分析、論理構造の検討、メッセージの精緻化を一緒に進めていきます。AI がたたき台を提示し、利用者がフィードバックを返すことで、設計書の質を高めていくプロセスです。 具体的には、以下の 3 つのフェーズで資料を設計します。 仕様駆動プレゼンテーションの 3 フェーズ。「何を伝えるか」を段階的に設計してから、AI がスライドを生成します 1. ブリーフィング — 聞き手は誰か、何を伝えたいか、聞き手にどうなってほしいかを定義します 2. アウトライン — 1 スライド 1 メッセージの原則で、各スライドが答えるべき疑問と、その答えを定義します 3. アートディレクション — 色使い、フォント、ビジュアルの方向性を定義します この設計書が完成した後に、AI がテンプレートに準拠してスライドを生成します。設計と構築が分離されているため、メッセージの質を保ちながら、構築のスピードを大幅に向上できます。 従来の資料作成 仕様駆動プレゼンテーション 起点 白紙のスライド ソース資料と要件 設計 作りながら考える 先に論理構造を設計書として定義 構築 手作業でレイアウト AI がテンプレートに準拠して生成 品質 属人的 設計書に基づくレビュー可能なプロセス 資料ができるまでの流れ Spec-Driven Presentation Maker では、AI エージェントが対話を通じて設計書を作成し、スライドを構築します。利用者が行うのは、チャットでの対話と、設計内容の確認です。 Web UI の画面。デッキ一覧から資料を選択し、右側のチャットで AI と対話しながら設計・構築を進めます 1. 対話による設計 — AI が聞き手や目的についてヒアリングし、ブリーフィングを作成します。続いて、1 スライド 1 メッセージの原則でアウトラインを設計し、ビジュアルの方向性を決定します アウトラインの設計画面。各スライドのメッセージ、根拠（Evidence）、ビジュアル指示が構造化されて表示されます 2. スライドの自動構築 — 設計書に基づいて、AI がテンプレートのレイアウトやカラーに準拠しながらスライドを構築します 3. プレビューとレビュー — 生成されたスライドの PNG プレビューを確認し、AI との対話で修正を指示できます 生成されたスライドのプレビュー。グリッド表示で全体の流れを確認でき、チャットから画像配置などの修正指示も可能です 設計書（ブリーフィング、アウトライン、アートディレクション）はすべて保存されるため、後から設計意図を振り返ることができます。また、設計書をレビューすることで、スライドを作る前の段階で内容の妥当性を確認できます。 自社のテンプレートとブランドをそのまま活用 Spec-Driven Presentation Maker の特徴の一つは、既存の PowerPoint テンプレートをそのまま利用できることです。 Spec-Driven Presentation Maker で生成されたスライドの例。データビジュアライゼーション、引用、アジェンダなど多様なレイアウトが自動で選択されます お使いの企業テンプレート（.pptx ファイル）をアップロードするだけで、テンプレートに定義されたレイアウト、カラーテーマ、フォント設定が反映されます。AI は、テンプレートのデザインシステムに準拠してスライドを生成するため、企業のブランドガイドラインに沿った資料が作成されます。 同じ内容でも、テンプレートを変えるだけでデザインが変わります。左がダークテンプレート、右がライトテンプレート また、 AWS Architecture Icons や Material Symbols などのアイコンセットにも対応しており、アーキテクチャ図やフロー図を含むスライドも作成できます。独自のアイコンセットを追加することも可能です。 画像を渡すだけでスライドに Spec-Driven Presentation Maker は、画像の内容を理解してスライドに変換する機能も備えています。写真やイラストを渡すと、AI が画像の内容を分析し、それに合ったレイアウト・テキスト・スタイルを自動で選択してスライドを生成します。 画像を渡すだけで、内容を理解した上でスライドを自動生成。テンプレートのスタイルに合わせてレイアウトやフォントも自動選択されます 2 つの使い方 — ブラウザから、または普段の AI ツールから Spec-Driven Presentation Maker は、利用者のスキルや好みに応じて 2 つの方法で利用できます。 ブラウザから使う Web UI を使えば、ブラウザ上のチャットインターフェースから資料を作成できます。特別なツールのインストールは不要です。チャットで AI と対話しながら、同じ画面でスライドのプレビューを確認し、PPTX ファイルをダウンロードできます。 Web UI のダッシュボード。作成した資料の一覧がカード形式で表示されます。お気に入り、共有、組織内公開などのフィルタリングも可能です チームメンバーとの共有機能も備えており、作成した資料を他のメンバーに公開したり、共同編集者として招待したりできます。 普段の AI ツールから使う 開発者やパワーユーザーは、普段お使いの AI コーディングエージェント（ Kiro 、Claude Desktop、VS Code など）から直接資料を作成することもできます。MCP（Model Context Protocol）を通じて AI コーディングエージェントにサーバーを追加するだけで、チャットの中で資料作成の指示を出せます。 社内の AI チャット基盤に組み込む Spec-Driven Presentation Maker はリモート MCP サーバーとして独立して動作するため、MCP に対応した社内の AI チャット基盤にも組み込むことができます。たとえば、 Generative AI Use Cases（GenU） の AgentBuilder 機能を利用すれば、GenU のチャット画面からプレゼンテーション資料を作成できるようになります。既存の AI 基盤に「資料作成」という新しいケイパビリティを追加する形で導入できる点も、このアセットの特徴です。 この柔軟性により、組織内のさまざまな役割の方が、それぞれに合った方法で利用を開始できます。 アーキテクチャ — 必要なレイヤーだけ使う Spec-Driven Presentation Maker は 4 層アーキテクチャで構成されています。各レイヤーは前のレイヤーの薄いラッパーであり、必要なレイヤーだけを選んで利用できます。 ユースケース レイヤー AWS Kiro CLI で個人利用 Layer 1: skill/ 不要 ローカル MCP（Claude Desktop、VS Code、Kiro） Layer 2: skill/ + mcp-local/ 不要 チームデプロイ Layer 3: + mcp-server/ + infra/ 必要 フルスタック（Web UI + チャット） Layer 4: + agent/ + api/ + web-ui/ 必要 Layer 1・2 は AWS アカウント不要で、ローカル環境だけで動作します。個人利用から始めて、チームでの利用が決まった段階で Layer 3・4 に拡張するという段階的な導入が可能です。 始め方 — CloudShell から数ステップでデプロイ Spec-Driven Presentation Maker は、AWS CloudShell から数ステップでデプロイできます。ローカル環境に AWS CDK や Docker をインストールする必要はありません。 git clone https://github.com/aws-samples/sample-spec-driven-presentation-maker.git cd sample-spec-driven-presentation-maker ./scripts/deploy.sh --region us-east-1 デプロイが完了すると、Amazon CloudFront の URL が発行されます。ブラウザでアクセスし、Amazon Cognito のユーザーを作成すれば、すぐにチームで資料作成を始められます。 すべてのリソースはご自身の AWS アカウント内にデプロイされます。資料のデータ（スライド、テンプレート、プレビュー画像）は Amazon S3 と Amazon DynamoDB に保存され、AWS 外部のサードパーティサービスにデータが送信されることはありません。認証には Amazon Cognito を使用し、リソースレベルのアクセス制御により、資料ごとに閲覧・編集権限を管理できます。 個人利用やローカル環境での利用方法については、 リポジトリのドキュメント をご参照ください。 まとめ Spec-Driven Presentation Maker は、「何を伝えるか」の設計と「どう見せるか」の構築を分離することで、プレゼンテーション資料の質とスピードを両立するオープンソースのサンプル実装です。 仕様駆動アプローチにより、メッセージの論理構造を先に設計し、AI がテンプレートに準拠してスライドを生成します 既存の企業テンプレートをそのまま活用でき、ブランドガイドラインに沿った資料を作成できます ブラウザ、AI コーディングエージェント、社内 AI 基盤など、多様なインターフェースから利用できます 4 層アーキテクチャにより、個人利用からチームデプロイまで段階的に導入できます ご自身の AWS アカウント内にデプロイされるため、データの管理はお客様自身の手の中にあります 次のプレゼン資料を作成する機会に、ぜひお試しください。 リンク集 GitHub リポジトリ アーキテクチャドキュメント CloudShell デプロイガイド カスタムテンプレートとアセット エージェント接続ガイド 著者/開発者紹介 片岡 翔太郎 (Shotaro Kataoka) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 本アセットの設計・開発を担当。 AI/ML関連で博士号取得後 2025 年に入社した SA。最近初めての娘が生まれ、家では常に抱っこをしている。業務効率化ツールの開発が趣味で、Kiro CLI を片手にいつも何かを作っている。 吉川 直仁 (Naohito Yoshikawa) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 本アセットの設計・開発を担当。 大学で AI/ML の研究を行い、昨年（2025/04）SA として新卒入社。Kiro CLI で仕事を効率的にしようとするも、何かを作り続けているので結局忙しい。 岡本 晋太朗 (Shintaro Okamoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 本アセットの設計・開発を担当。 育休から復帰後、生成 AI の進化をキャッチアップ中。今年の目標は家事を技術で楽にすること。Kiro はかわいいので IDE 推しだったが、最近は CLI も愛用。

こんにちは。ソリューションアーキテクトの水野です。AWS のプロフェッショナルサービスでは、ブラザー工業株式会社 プリンティング＆ソリューションズ事業にてアジャイル導入をご支援しています。今回、同事業のエンジニアの方々に AI-DLC を用いた新しい働き方を体験していただくため 2026 年 2 月と 3 月にそれぞれ 3 日間にわたって「AI-DLC 体験会」を開催しました。本ブログでは、私が聞き手となり、体験会に参加された八十嶋様、宇野様、前田様、梅本様にインタビューした内容をまとめました。 AI-DLC（AI-Driven Development Life Cycle）は、ソフトウェア開発ライフサイクルに AI を全面的に組み込んだ新しい開発手法です。コーディング支援にとどまらず、要件定義や仕様検討といった上流工程から、実装、テスト、デプロイまで、開発の全フェーズで AI を活用します。また、ダイナミックなチームコラボレーションが特徴で開発サイドとビジネスサイドが短期間に集中して一緒に作業を行い素早くアウトプットを作り上げます。詳しくは AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 をご覧ください。 想像を超えた可能性 水野（AWS）: AI-DLC 体験会 への参加のきっかけと、参加前後での印象の変化を教えてください。 前田: 上司との面談で話を聞きました。最初は普段使っている AI コーディング支援程度のものかと思っていましたが、実際に受けてみると全く違いました。目先の細かいアシストレベルではなく、もっと先を見据えた、将来的にスタンダードになるであろう開発手法を学べたと感じています。 宇野: 当初はコーディング支援やペアプログラミング程度のものかと想像していました。しかし、実際には上流工程から AI を活用し、エージェントを使ってペルソナ作成やユースケース作成、モックアップ作成まで行うことができました。過去に企画業務を 3-4 年経験していましたが、その頃やっていたことを AI にやらせるという新しい体験に驚きました。 梅本: 参加前から関連記事を読んでいたので、とても楽しみにしていました。記事では具体的にどう要件定義工程から進めるのかイメージできなかったので、実際に手を動かして体験できることに期待していました。社内のアジャイル開発において、アンテナを高く持って情報収集していた中でのワークショップだったので、非常に興味深かったです。 八十嶋: AWS から体験談や効果を直接聞いていたので、自分のチームで試せることに対して懐疑的な気持ちは全くなく、純粋に楽しみでした。AI のうまい使い方が見つからない中で、ようやく見つけることができたという気持ちでした。 2026 年 2 月開催時の様子 開発プロセスの変化と実践での工夫 水野（AWS）: 従来の開発プロセスと比較して、大きく変わったと感じる点は何ですか？ 梅本: 要件定義や仕様検討といった上流工程から AI を混ぜて議論していくところが大きく変わりました。実装段階では比較的 AI に渡しやすい部分もありますが、リファインメントで行っていた濃密な議論にどう AI を混ぜるのか、自分だけではイメージできませんでした。AI-DLC を取り入れた時にチームのプロセスとして変わる部分だと感じています。 八十嶋: プロダクトオーナーとデベロッパーの距離が縮まり、お互いが補完して理解し合う関係になると感じました。 宇野: 既存システムに対して AI を活用する際、ドメイン知識が必要だと痛感しました。事前情報として「既存ではこういうことをやっているので、これを前提にユースケースを考えてください」という指示をしないと、的外れな回答が出てきてしまいます。AI への問いかけ方が重要だと感じました。AI の回答は思ったより的確でしたが、どう問いかけるか次第で結果が大きく変わるので、問いかけ方の重要性を感じました。 水野（AWS）: 体験会で直面した困難について教えてください。 前田: 既存システムのデータベースから直接データを引っ張ってくる部分が最大の困難でした。データベースのスキーマのドキュメントがない状況で、どうやってデータを取得するか悩みました。最終的には、データベース定義の DDL 文とソースコードをまるごと解析して、「データをどうやって取ってくるか調べてください」と AI にお願いする戦略を取りました。やらせてみたらできてしまい、繋がった時には感動がありました。 宇野: 既存システムにどう適用するかが最大の困難でした。プロンプトで指示を出してもなかなか伝わらない部分がありました。協力会社が作った 500 ページぐらいの PDF ファイルがあったので、それをまるごと AI に渡してみることにしました。今回は時間の制約があったため、最初のコンテキスト作りに 1 日目の半分ぐらいしか時間をかけられませんでしたが、本格的にやるならもう少し時間をかけるべきだと思いました。 梅本: 集中力の維持が大変でした。私はインセプション（開始フェーズ）が一番集中力を維持するのが大変でしたが、プロダクトオーナーの方はコンストラクション（構築フェーズ）が一番疲れたと仰っていました。既存のポジションによって、集中力が途切れやすいフェーズが違うと気づきました。解決策として、1 時間に 1 回休憩を取るというアクションと自分が得意なフェーズでドライバーをやるということを実施しました。私はコンストラクションでドライバーを担当し、インセプションでは手を貸す側に回りました。普段慣れている情報に触れる方が楽に感じやすいと思います。 必要なスキルと人材育成 水野（AWS）: AI-DLC のように AI を中心とした開発の場合、エンジニアに必要なスキルセットは何だと思いますか？ 前田: 一般的なプログラミングはすべて AI がやってくれる世界になりつつある中で、複雑なシステムになればなるほど、ドメイン知識の重要性が非常に大きくなっていくと感じています。それを持っているか持っていないかで大きく変わります。組織としてドメイン知識を教えていくような体制が整っていれば、活躍できる場はあると思います。 宇野: 問いかける力が非常に重要だと思います。特に既存システムに関しては制約があるので、それを見越した上で論理立てて話さないといけません。AI はパッと見それっぽい答えを出してきますが、よくよくコードを見てみると全く使い物にならないこともあります。エンジニアは普段集中してプログラミングしているとコミュニケーションをしませんが、どう問いかけるかというのが新しいスキルセットだと感じました。 水野（AWS）: ジュニアエンジニアの育成についてはどう考えていますか？ 八十嶋: 今回ジュニアエンジニアの方は大変そうでした。スクラムの時は手を動かしながら教えてもらえる時間がありましたが、AI がアウトプットを出す中で、ジュニアエンジニアがキャッチアップする間がないまま進んでいきます。ジュニアエンジニアの方がキャパオーバーを起こしていたので、そこをケアする開発サイクルを考えないと課題になると感じました。プログラミング経験が少ないメンバーは、一見活躍できるように見えても成長していない可能性があるので、成長機会の提供が必要だと考えます。 梅本: 実務では AI が書いてしまうため、技術的なところを学ぶのが難しくなってきています。社内でも、データベースなどの領域で代表的なハマりどころを経験して、それを自力で解決するという体験をする機会を設けた方がいいという意見がありました。コードを自力で書き直す経験が実務だと取りづらいので、そういう研修が必要だと感じます。 　　　 2026 年 3 月開催時の様子 組織展開に向けて 水野（AWS）: AI-DLC を組織に展開する際、どのようなプロジェクトが向いていると思いますか？ 梅本: コンテキストが少ないプロジェクト、つまり新規プロジェクトの方が比較的 AI-DLC を取り入れやすいと感じました。 宇野: 私は既存プロジェクトでも可能性はあると思います。ドキュメントがある程度しっかり作られていれば、それをコンテキストとしてインプットすることで、AI を簡単にオンボーディングできます。逆に新規プロジェクトだと、まだ関係者間での合意形成や目的・ビジョンが見えていない場合があります。既存プロジェクトであれば、合意形成やコミュニケーション範囲がある程度決まっているので、そういう意味では既存プロジェクトでも十分実施可能だと思います。 水野（AWS）: 組織展開における最大の課題は何だと考えますか？ 八十嶋: 品質管理やセキュリティの方々は、これまで門番的に振る舞うことが是とされてきました。AI-DLC ではこれらのゲート型のプロセスがボトルネックになりそうです。 水野（AWS）: 具体的にどのような展開戦略が有効だと思いますか？ 八十嶋: 内部向けサービスで使いながらプロセスを作り、その後外部向けシステムでも使えるようにしていきたいです。他部門への AI-DLC の価値説明としては、企画の人が言語化できれば、シニアエンジニア 1 人いれば 1 日か 2 日ですぐ試せる状態になる、つまりスクラップアンドビルドが非常にしやすくなったという点を強調したいと思います。 まとめ 今回の AI-DLC 体験会 を通じて見えてきたのは、AI-DLC が単なる効率化ツールではなく、ソフトウェア開発の在り方そのものを変革する可能性を秘めているということです。参加者の皆様が口を揃えて語ったのは、「想像していたものと全く違った」という驚きでした。コーディング支援という枠を超え、企画段階から AI が開発パートナーとして機能する世界を体験できたようです。 一方で、この変革には新たな課題も伴います。AI が高速でアウトプットを生成する中で、人間はどこまで検証すべきか。ジュニアエンジニアはどう成長機会を得るのか。品質管理やセキュリティ部門とどう協調するのか。これらの問いに対する答えは、まだ完全には見えていません。しかし、参加者の皆様が実践を通じて得られた知見は、これから導入を検討される組織にとって貴重な道標となるでしょう。 特に印象的だったのは、「ドメイン知識」「問いかける力」「言語化能力」という、一見古典的とも思えるスキルの重要性が、AI 時代においてむしろ高まっているという指摘です。AI が技術的な実装を担う時代だからこそ、人間は「何を作るべきか」「なぜそれが必要か」を明確に定義し、AI に的確に伝える能力が求められます。これは、エンジニアリングとビジネスの境界が曖昧になり、全員がプロダクトの本質に向き合う必要がある、新しい開発文化の萌芽と言えるかもしれません。 インタビューさせていただいたブラザー工業 P&amp;S 事業 SC 開発部のエンジニアの皆様 左から 八十嶋 瑞穂（チーム・マネージャー） 梅本 匠 前田 康佑 宇野 大　（敬称略） 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。

本ブログは、荏原製作所 情報通信統括部様 と Amazon Web Services Japan が共同で執筆しました。 こんにちは、AWS ソリューションアーキテクトの野間です。 2026年3月25日（水）、荏原製作所様と Amazon Web Services Japan が共同で「Ebara Cloud Day」を開催しました。 本ブログではその取り組みと成果についてご紹介します。企業内でクラウドを浸透させることに苦労されているIT担当者の方も多いかと思います。このブログの内容が皆様の活動の参考になれば幸いです。 1. 取り組みの背景 荏原製作所は、ポンプや半導体製造装置をはじめとし、コンプレッサ・タービン、冷熱機械、送風機、廃棄物処理施設の設計・建設・運営管理などを展開する、産業機械メーカです。国内外に多数の拠点を展開し、経営・事業・ITが三位一体となった事業変革を推進しています。 CIO配下の体制では、ITによるグローバルな業務標準化と経営インフラの高度化を推進しており、クラウド基盤を土台とした「持続可能な成長を実現するDXの加速」が重要なテーマとなっています。 当社IT部門では、AWSをはじめとするクラウドサービスの利用が年々拡大しています。しかし、CIO配下のIT関連部門や国内外グループ会社のIT部門を見渡すと、クラウドに対する理解度や活用スキルにはまだ大きなばらつきがあり、「クラウドは難しそう」「社内のクラウド活用方法が知りたい」という心理的障壁を感じているメンバーも少なくありませんでした。 また、各部門がそれぞれの判断でクラウドを活用するケースが増える一方、組織としての共通知識やベストプラクティスの共有が不十分であり、中央管理が難しくなったという課題もありました。このような状況を踏まえ、「クラウドを身近に感じてもらい、まず一歩踏み出すきっかけを作りたい」という思いから、AWSと共同で社内向けクラウドイベントを企画することとなりました。 IT部門がイベントを主導することで、社内における「クラウド利活用の旗振り役」としての役割を果たすとともに、参加者が自ら学ぶ意欲を持ち、日々の業務にクラウドを取り入れていく文化を醸成することを目指しました。 2. Ebara Cloud Day の概要 イベント名： Ebara Cloud Day 開催日時： 2026年3月25日（水）13:00〜16:00（3時間） 開催形式： オンライン（事務局および一部スピーカーはオフライン集合） 対象者： IT関連部門・研究開発（CIO配下の組織） 技術レベル： 初級〜中級 参加者数： 41名（オンライン） 主催： 荏原製作所 / Amazon Web Services Japan イベント全体の目的： ① クラウドに対する理解の壁の排除：オンプレミス中心の文化からクラウドへの心理的・技術的障壁を取り除き、クラウド活用への抵抗感を軽減する ② AWSを知る：クラウドサービスの基礎とAWSの主要機能を理解し、業務における活用可能性を認識する ③ 技術興味への第一歩：社内事例やセッションを通じて、参加者のクラウド技術への興味を喚起し、自発的な学習意欲を促進する ④ 荏原製作所のデジタル変革の加速：クラウドファーストの文化醸成により、研究開発や業務効率化におけるイノベーションを推進する 3. セッション内容 当日はAWSによるセッションおよび荏原製作所社内メンバーによるLT（ライトニングトーク）が行われました。 (1)AWSセッション 「あらためて学ぶクラウドのキホン」 クラウドの基本概念（IaaS/PaaS/SaaS）から始まり、AWSが提供する主要サービスの全体像をわかりやすく解説しました。「オンプレミスとの違いが初めてイメージできた」「ブロックのように必要な機能を組み合わせて使えると知った」など、クラウド入門者に向けた内容に参加者から多くの反響がありました。 (2)LTセッション（社内事例発表） 荏原製作所社内エンジニアによるLTセッションでは、日々の業務の中でAWSを活用した実体験が発表されました。外部の事例ではなく「自社の仲間が実際にやっていること」として参加者に届けられたことで、クラウドへの親近感と「自分にもできる」という前向きな意識が広がりました。 LT①：「新入社員研修の事例(AWSサーバ構築)」 情報部門に配属される新入社員向けに「AWSでサーバを構築する」という研修を行っているので紹介しました。ITインフラについて理解を深めてもらうことを目的として、3時間程度で実際にEC2の「新規作成」→「設定変更」→「削除」を行い、サーバのライフサイクルを体験するという実習です。実際にAWSコンソールを見せながら説明したことで、EC2のイメージができたこと、オンプレと比べて簡単にサーバ作成ができることを理解してもらったのではないかと考えています。 LT②：「EC2提供の運用」 本発表では、弊社IT部門が提供し、管理するEC2インスタンス運用プロセスについて共有しました。Datadogを利用した監視運用、AMI自動バックアップ取得と仕組みをはじめ、セキュリティグループで各EC2インスタンスの社内外接続制限等について荏原製作所でのやり方を展開しました。また、EC2だからこそ最小限のスペックで構成開始し、状況にあわせて徐々に拡張するメリットを共有し、コスト最適化をアプローチしました。 参加者から、次回もより運用にフォーカスした内容が聞きたい、AWSサービスを有効活用してコスト最適化を実現したいとの声をいただきました。 LT③：「中国におけるAWS利用について」 中国のAWSはグローバル環境から独立しており、現地パートナー企業によって運営されています。アカウント開設には現地当局の審査が必要という制約がありますが、当社は特定の業務要件を満たすために中国リージョンの導入を決定しました。社内発表でこの独自の導入プロセスを共有し、今後の展望としてOrganizationを活用したグループ会社ごとのコスト管理の簡易化を提示したところ、参加者からも深い納得感を得ることができました。 LT④：「WrikeAPIと連携したタスク表示ツール」 タスクスケジュールの管理にWrikeを利用しておりますが、標準UIでは日常的なタスク管理のやり辛さに課題を持っていました。そこでPythonとAPIを活用した独自のGUIツールをKiroを活用して作成する発表を行いました。 KiroというAWSのエージェント型IDEで何ができるのか、既存のAIツールを利用した際との正確性の違いについて多くの方に興味を持っていただけました。 LT⑤：「リモート接続サーバー自動停止の実践事例」 本発表では、在宅勤務時に利用するリモート接続サーバーの運用見直しによるコスト削減事例を紹介しました。業務時間外も24時間稼働していたEC2を、利用実態に合わせて夜間停止・朝起動の自動化を実施しました。EventBridgeとLambda、タグ制御によりシンプルに実現し、コスト半減を達成しました。 イベント当日は、普段は個別のプロジェクトや部門に閉じて業務を行っているメンバーが、オンライン上で一堂に会し、クラウドという共通テーマのもとに活発な意見交換が行われました。 チャット欄には「これは知らなかった」「うちの部門でも使えそう」といったコメントが次々と投稿され、参加者が受け身ではなく積極的に学ぼうとする姿勢が随所に見られました。またLTでは普段はなかなか共有されない社内の生の声が届けられたことで、参加者の共感を呼び、質問が途切れないほどの盛況ぶりとなりました。 3時間という限られた時間でしたが、参加者からは「もっと長くても良かった」「次回は1時間程度の定期開催にしてほしい」といった声も届くなど、継続的な学習機会への需要の高さが実感できるイベントとなりました。 4. 実施結果 全体満足度：4.27 / 5.0 次回参加意向：100% 興味のあるテーマ：第1位：AI・生成AI、第2位：コスト最適化 IT部門として、今回のイベントを通じて以下のような効果が得られたと感じています。 クラウドへの心理的障壁の低下 イベント前は「クラウドは専門家のもの」という意識が強かったメンバーも、AWSの丁寧な入門セッションや社内事例の LTを通じて、「自分たちにも使いこなせるかもしれない」という感覚を持ち始めてくれました。アンケートでも「スモールスタートで始められると知った」「まず試してみようと思った」という声が多く、行動変容のきっかけとなったことが確認できました。 社内のクラウド活用事例の可視化と横展開 普段は部門内に留まりがちなクラウド活用事例を、LTという形で全社に向けて発信できたことは大きな収穫でした。 「EC2を使っているとは聞いていたが、具体的な取り組みを初めて知った」という声も多く、情報共有の場としての価値が高いことが確認できました。今後は LT登壇者を増やし、他部門の事例の横展開も加速させたいと考えています。 IT部門が「クラウドの窓口」として認知される機会に イベントの主催者として IT部門が前面に立ったことで、「クラウドのことは IT部門に相談すれば良い」という認識が社内に広まりました。イベント後、複数の部門から「AWS活用について相談したい」という問い合わせが寄せられており、IT部門のプレゼンス向上という観点でも大きな効果があったと感じています。 継続的な学習コミュニティの素地の形成 参加者全員が「次回も参加したい」と回答し、1名は LT登壇の意向まで示してくれました。また、「他部門のクラウド活用事例も知りたい」、「他社のAWS活用事例も取り上げてほしい」との意見もいただきました。今回のイベントが一過性のものではなく、定期的な学習機会の出発点となり得ることを実感しました。クラウドに興味を持つ仲間が社内にいることを参加者が知ったことで、非公式な情報共有や自発的な勉強会につながる可能性も感じています。 5. 参加者の声 「本日は貴重な機会をありがとうございました。クラウドに関して、これまで曖昧に理解していた部分を体系的にご説明いただき、非常に勉強になりました。特に、具体的な事例を交えた解説があったおかげで、実際の利用シーンをイメージすることができました。」 「AWSは機能が多く学習のハードルが高いイメージがありましたが、スモールスタートできて必要な機能をブロックのように増やせることを知り、まずは必要な機能に絞って触ってみようと思いました。」 「昨年担当システムをオンプレミスからAWS EC2にリフトアップしましたが、今回のイベントでAWSのサービスを有効活用すればするほどコスト的にメリットがありそうだと感じました。今後もAWSのサービスや利用方法について定期的に情報提供いただけると助かります。」 6. まとめ・今後の展望 今回の「Ebara Cloud Day」は、41名の参加者とともに盛況のうちに終了しました。全参加者が「次回も参加したい」と回答し、クラウドへの関心と学習意欲の高まりが感じられるイベントとなりました。 今回のイベントを通じて、社内のクラウドに対する意識が大きく変わり始めたことを実感しています。目標KPIとして掲げていた「満足度4.0以上」「次回参加意向80%以上」をいずれも大幅に上回る結果となり、IT部門として非常に手応えを感じています。 今後は、今回の開催で得た知見を活かしつつ、定期的なイベント開催を通じて社内クラウドコミュニティの形成を目指します。特に参加者から関心が高かったAI・生成AI活用や、コスト最適化をテーマに次回以降のセッションを企画していく予定です。社内のクラウド活用をより一層加速させ、荏原製作所のDX推進に貢献していきたいと考えています。 最後に、本イベントの企画・運営にご尽力いただいた荏原製作所の皆様、そして熱意を持って参加いただいた参加者の皆様に心より感謝申し上げます。今後も荏原製作所様のDX推進を全力でご支援してまいります。 執筆者 株式会社荏原製作所 情報通信統括部 ITアーキテクト部 福島 康平 情報通信統括部 ITアーキテクト部 竹之内 遼 情報通信統括部 ITアーキテクト部 Shwe Yee Myat Mon (シュエ イｰ ミャッ モン) Amazon Web Services Japan シニアソリューションアーキテクト 野間愛一郎

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今週のトップニュースは AWS Agent Registry と Claude Mythos の Amazon Bedrock 上での Gated Research Preview でしょう。AWS の CISO である Amy が、AWSのセキュリティアプローチがどのように Anthropic のようなパートナーとお客様のイノベーションを加速しているのかを解説しているブログも今週号で取り上げていますので、ぜひご一読ください。 また今週&nbsp; 4 月 15 日には「 AI-DLC 体験勉強会 」が開催されます。AWS Summit Japan 2026 では AI-DLC のハッカソンも予定されているので、ぜひこれを機にキャッチアップしてみてはいかがでしょうか？ それでは、4 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 大豊建設株式会社様、生成 AI アシスタント「大豊 AI」で業務の様々な場面を効率化 大豊建設様は、土木・建築工事を中心とした総合建設会社です。社内の情報へのアクセスのしにくさ、文書作成の負担、中堅社員不足による知識共有の難しさといった課題を抱えていました。そこで、AWS を基盤として生成 AI を活用した「大豊 AI」を構築し、フリートーク、社内規程検索、ファイルチャット、全文検索、ユースケース別検索などの機能を社内に展開しました。2025 年 6 月の全社展開から約 8 ヶ月で 307 名の社員が利用し、累計 32,709 回以上の利用回数を記録しています。規程検索だけでも約 250 時間の業務時間削減を実現しました。今後は、施工計画書の作成支援や社内資料作成支援といった、Amazon Bedrock AgentCore のエージェント技術を活用した業務効率化も目指しています。 AWS生成AI国内事例ブログ: 丸紅グループが描く生成AI活用の全貌 〜内製開発・AIエージェント活用で変わる総合商社の姿〜 丸紅グループの生成 AI 活用の続編記事です。 前回 紹介した社内生成 AI プラットフォーム「Marubeni Chatbot」は登録ユーザー数が 7,500 人以上から 10,000 人以上へと拡大しました。今回は、Amazon Bedrock AgentCore&nbsp;を活用した AI エージェント機能の搭載、競合分析システムの構築、水道管路 AI 劣化予測診断サービス（分析作業を約 99% 削減）、そして AI DLC Unicorn Gym の開催という 4 つの新たな取り組みを紹介しています。丸紅グループが生成 AI をどのように業務や開発の現場に根付かせてきたか、ぜひご覧ください。 ブログ記事「 AI を活用した大規模なセキュリティ防御の構築 — 脅威が出現する前に 」を公開 AWS CISO の Amy のブログの翻訳です。Anthropic が発表した Project Glasswing と、これまでで最も高度な AI モデルである Claude Mythos Preview について紹介しています。Claude Mythos Preview はサイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクで高いパフォーマンスを発揮する新しいモデルクラスです。AWS では継続的な AI セキュリティレビューが行われている重要なコードベースに Claude Mythos Preview をすでに適用しており、セキュリティの検出結果を洗い出す際に従来のモデルよりも高い生産性を発揮しています。 ブログ記事「 AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 」を公開 AWS Security Agent は、自律型ペネトレーションテストを提供するフロンティアエージェントです。手動のペネトレーションテストの数分の一のコストで、24 時間 365 日稼働します。SAST、DAST、ペネトレーションテストの機能を単一のコンテキスト認識型エージェントに統合し、マルチクラウドに対応しています。HENNGE 様は「一般的なテスト期間を 90% 以上短縮できます」と述べています。 ブログ記事「 AWS DevOps Agent によるエージェンティック AI を活用した自律的インシデント対応 」を公開 AWS DevOps Agent は、Amazon Bedrock AgentCore 上に構築された常に利用可能な運用チームメンバー Agent です。インシデントの解決とプロアクティブな予防を行い、AWS、マルチクラウド、オンプレミス環境にわたる SRE タスクを処理します。本記事では、URL 短縮サービスの例を通じて、DevOps Agent を次世代の完全な運用チームメンバーたらしめる 6 つの主要な能力「6 つの C」を解説しています。 ブログ記事「 Amazon Bedrock Guardrails では、一元化された制御と管理により、クロスアカウント保護がサポートされています 」を公開 Amazon Bedrock Guardrails でクロスアカウントセーフガードが一般提供されました。組織の管理アカウント内でガードレールを指定し、すべてのメンバーエンティティ全体で自動的に実施できるようになりました。個々のアカウントやアプリケーションを監視する管理上の負担を大幅に軽減しながら、企業の責任ある AI 要件の一貫した遵守をサポートします。 ブログ記事「 コパイロットからコワーカーへ – AAAI : エージェント研究と実用化のギャップ 」を公開 AAAI 2026 のパネルディスカッションで、Microsoft、Mistral、シンガポール国立大学、LinkedIn、AWS の研究者と実務者が、コーディングエージェントを本番環境に投入する際の課題について議論しました。研究は能力の最適化に注力する一方、本番環境では信頼性、コスト、レイテンシー、信頼、組織への適合性を同時に最適化する必要があるという議論が展開されています。今後の研究の方向性についても言及されており、エージェント開発に携わる方にとって示唆に富む内容です。 ブログ記事「 Kiro Students プランのご紹介 」を公開 AI コーディングツール&nbsp;Kiro&nbsp;の学生向けプランが発表されました。対象の大学生は、月 1,000 クレジット付きの Kiro を 1 年間無料で利用できます。まず 11 の大学からスタートし、今後さらに多くの大学への拡大を予定しています。 ブログ記事「 Kiro スタートアップクレジットプログラムが復活します 」を公開 アーリーステージから Series A までのスタートアップを対象に、最大 1 年分の Kiro Pro+ を無料で申請できるプログラムが復活しました。チーム規模に応じて 3 つのティア（最大 2、10、30 ユーザー）が用意されています。 ブログ記事「 Kiro CLI の新しいデザイン 」を公開 Kiro CLI の刷新された UX が実験的モードとして公開されました。ライブ統合ステータス、常時表示の入力エリア、スラッシュコマンドと @ コンテキスト、コンテキストオーバーレイなどの新機能が追加されています。 kiro-cli --tui&nbsp; で試すことができます。 ブログ記事「 Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：新規ベクトルデータの投入が不安定、または失敗する場合 」を公開 ブログ記事「 Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：検索レイテンシの増加が問題になっている場合 」を公開 Amazon OpenSearch Service の FAISS エンジンを使用したベクトル検索のトラブルシューティングに関する 2 本の記事が公開されました。RAG などでベクトル検索を活用している方にとって、データ投入の不安定さや検索レイテンシの増加に対する原因調査と対処法の考え方が体系的にまとめられています。 サービスアップデート Amazon Bedrock で Claude Mythos Preview が限定リサーチプレビューとして利用可能に Anthropic のこれまでで最も高度な AI モデルである Claude Mythos Preview が、Amazon Bedrock で限定リサーチプレビューとして利用可能になりました。Claude Mythos Preview は、サイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクにおいて最先端の能力を持つ根本的に新しいモデルクラスです。Project Glasswing の一環として、インターネットの重要インフラ企業やオープンソースのメンテナーが優先的にアクセスできます。現在、米国東部（バージニア北部）リージョンで利用可能です。 AWS Agent Registry が集中型エージェント検出・ガバナンスのためにプレビュー提供開始 Amazon Bedrock AgentCore を通じて利用可能な AWS Agent Registry がプレビューで提供開始されました。組織内のエージェント、ツール、スキル、MCP サーバー、カスタムリソースのプライベートなカタログおよび検出レイヤーです。セマンティック検索とキーワード検索の両方に対応し、承認ワークフローや AWS CloudTrail による監査証跡も提供します。米国西部（オレゴン）、アジアパシフィック（東京）を含む 5 リージョンで利用可能です。 Amazon Bedrock AgentCore Browser に OS レベルの操作機能を追加 Amazon Bedrock AgentCore Browser に、Chrome DevTools Protocol (CDP) だけでは対応できないブラウザワークフローの自動化を可能にする OS レベルの操作機能が追加されました。マウス操作、キーボード操作、フルデスクトップスクリーンショットなどが利用可能です。AI エージェント開発者やテスト自動化エンジニアにとって有用なアップデートです。アジアパシフィック（東京）を含む 14 リージョンで利用可能です。 Amazon Bedrock が IAM ユーザーおよびロールによるコスト配分をサポート Amazon Bedrock が、IAM ユーザーおよび IAM ロールによるコスト配分を AWS Cost and Usage Report 2.0 (CUR 2.0) と Cost Explorer でサポートするようになりました。IAM ユーザーやロールにチーム、プロジェクト、コストセンターなどのタグを付与し、コスト配分タグとして有効化することで、Bedrock のモデル推論コストをユーザー、チーム、プロジェクト、アプリケーション別に把握できるようになります。Bedrock が利用可能なすべての商用リージョンで利用可能です。 AWS Cost Explorer が Amazon Q を活用した自然言語クエリ機能を提供開始 AWS Cost Explorer に Amazon Q Developer の生成 AI 機能が統合され、自然言語でコストと使用状況データについて質問できるようになりました。「今月の上位支出サービスを表示して」といった質問に対して、Amazon Q が詳細なインサイトを提供すると同時に、Cost Explorer が対応するビジュアライゼーションを自動更新します。すべての商用 AWS リージョンで追加料金なしで利用可能です。 SageMaker HyperPod が分散トレーニングワークロード向けギャングスケジューリングをサポート Amazon SageMaker HyperPod のタスクガバナンスにギャングスケジューリングが追加されました。分散トレーニングジョブに必要なすべての Pod が準備完了してからトレーニングを開始することで、部分的なジョブ実行による無駄なコンピューティングやデッドロックを防止します。アジアパシフィック（東京）を含む複数のリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 AWS 初学者向けイベント「 AWS JumpStart 2026 」が今年も開催されます。事前学習用動画と 2 日間のオンラインワークショップを通じて、AWS の基礎から実践的なアーキテクチャ設計までを集中的に学べるプログラムです。全 4 回開催で、初回は 5 月 11 日（月）〜 12 日（火）です。参加費無料で、参加登録は こちら からお申し込みいただけます。AWS をこれから学びたい方やチームの新メンバーにぜひご紹介ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年4月6日週の主要なアップデート 4/6(月) Amazon S3 が新規および既存バケットに対してデフォルトでSSE-C を無効化する新しいセキュリティ設定の展開を開始 Amazon S3 で、顧客提供キーによる暗号化 (SSE-C) がデフォルトで無効化される新しいセキュリティ設定の展開が開始されました。新規作成される汎用バケットでは、顧客提供キーによる暗号化 (SSE-C) がデフォルトで無効化されます。SSE-C 暗号化オブジェクトが存在しない AWS アカウントでは、既存バケットについても SSE-C が無効化されます。一方、SSE-C を既に使用している AWS アカウントでは、既存バケットの暗号化設定は変更されません。この変更により、セキュリティリスクの軽減と管理の簡素化が期待できます。詳細は こちらの S3 ユーザーガイドをご参照ください。 Smithy-Java クライアントフレームワークの一般提供開始を発表 Smithy-Java クライアントフレームワークの一般提供を開始しました。Smithy モデルから型安全な Java クライアントコードを自動生成できるフレームワークで、シリアライゼーションやプロトコル処理などのボイラープレートコードを手書きする必要がなくなります。プロトコルに依存しない設計で、AWS JSON や REST-JSON、Smithy RPCv2 CBOR などを実行時に切り替え可能です。Java 21 の仮想スレッドを基盤に構築されており、複雑な非同期処理を書かずにシンプルなブロッキング API で高パフォーマンスなアプリケーションを構築できます。詳細は こちらの Blog 記事をご参照ください。 Amazon WorkSpaces Personal が PrivateLink の一意な DNS 名をサポート Amazon WorkSpaces Personal で PrivateLink の各 VPC エンドポイントに個別の DNS 名が付与されるようになりました。従来は共通の DNS 名を使用していたため、複数の AWS アカウントや VPC で WorkSpaces を利用する際に DNS 名の衝突が発生し、同時利用が困難でした。今回のアップデートにより、各エンドポイントが独自の DNS 名を持つため、企業の複数アカウント環境でも安全に WorkSpaces を分離して運用できます。DNS 名は AWS が自動管理するため Route 53 の追加設定は不要です。詳細は こちらのドキュメントをご参照ください。 4/7(火) AWS Transfer Family がコネクタと Web アプリで IPv6 をサポート AWS Transfer Family で IPv6 サポートが開始されました。SFTP コネクタ、AS2 コネクタ、ウェブアプリで IPv6 対応の取引先やサーバーへの接続が可能になり、これまで IPv4 しか対応していなかった環境でも柔軟にファイル転送できます。また IPv6 ネイティブネットワークからウェブアプリへのアクセスも可能です。デュアルスタック対応により IPv4 と IPv6 の両方で通信でき、段階的な移行が実現できます。詳細は こちらのドキュメントをご参照ください。 Amazon S3 Files の発表、S3 バケットをファイルシステムとしてアクセス可能に Amazon S3 Files の一般提供を開始しました。これまで S3 に保存されたデータをファイルベースのアプリケーションで直接扱うことができず、データの重複や複雑な同期処理が必要でした。S3 Files は Amazon EFS を基盤に構築された共有ファイルシステムで、S3 バケットをNFS v4.1+ 互換のファイルシステムとして直接マウントでき、既存のファイルベースのアプリケーションやツールからコード変更なしで S3 データを扱えます。AI エージェントのパイプライン間での状態共有や ML チームのデータ前処理などのユースケースにも適しています。34 のリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock で Claude Mythos Preview (限定研究プレビュー) の提供を開始 Amazon Bedrock で Claude Mythos Preview（限定研究プレビュー）の提供が開始されました。Anthropic 社のサイバーセキュリティイニシアチブ「Project Glasswing」の一環として提供される最先端 AI モデルで、サイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクにおいて高い能力を持ちます。従来のモデルより少ない手動ガイダンスでセキュリティ上の脆弱性を発見でき、防御的サイバーセキュリティ作業を加速できます。現在は限定的なプレビューとして、事前承認された組織のみがバージニア北部リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 4/8(水) Amazon Bedrock AgentCore Browser が OS レベルのインタラクション機能を追加 Amazon Bedrock AgentCore Browser で OS レベルの操作機能が追加されました。従来の CDP に加え、マウス操作やキーボード操作、デスクトップスクリーンショットが可能になりました。システムダイアログ処理や複雑な UI 操作の自動化が実現し、AI エージェント開発やテスト自動化でより高度なワークフローを構築できます。詳細は こちらのドキュメントをご参照ください。 Amazon EKS マネージドノードグループが EC2 Auto Scaling ウォームプールをサポート Amazon EKS managed node groups で EC2 Auto Scaling warm pools がサポートされました。これまでスケールアウト時にはインスタンスの初期化に時間がかかっていましたが、事前に初期化済みのインスタンスをプールしておくことで、急激なトラフィック増加時のスケールアウトにかかる時間を大幅に短縮できます。インスタンスを Stopped (低コスト) または Running (高コスト・高速) で待機させることが可能で、突発的なワークロードや起動時間の長いアプリケーションに特に効果的です。北京リージョンと寧夏リージョンを除く全リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 4/9(木) Amazon EC2 Capacity Manager でタグベースディメンションがサポート開始 Amazon EC2 Capacity Manager でタグベースの分析機能が利用可能になりました。これまでリージョンやインスタンスタイプでしか分類できなかったキャパシティデータを、環境やチーム、コストセンターなどの独自タグで整理・フィルタリングできます。最大 5 つのカスタムタグキーを設定でき、組織全体でのリソース管理が格段に効率化されます。詳細は こちらのドキュメントをご参照ください。 エージェントの一元的な発見とガバナンスのための AWS Agent Registry がプレビューで利用可能に AWS Agent Registry がプレビュー開始しました。Amazon Bedrock AgentCore を通じて、組織内の AI エージェントやツールを一元管理・発見できるサービスです。これまで各チームが個別に開発していたエージェントを検索・再利用できるため、重複開発を避けてコストと時間を削減できます。自然言語での検索も可能で、用途を説明するだけで適切なエージェントを発見できます。承認ワークフローによるガバナンス機能も搭載し、組織の AI 資産を統制管理できます。現在、オレゴン、東京、シドニー、アイルランド、バージニア北部リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock が IAM ユーザーとロールによるコスト配分をサポート Amazon Bedrock で IAM ユーザーやロール単位でのコスト配分がサポートされました。IAM プリンシパルにチームやプロジェクト、コストセンターなどのタグを設定してコスト配分タグとして有効化することで、Bedrock のモデル推論コストを組織構造に沿って追跡・分析できます。CUR 2.0 では呼び出し元の IAM プリンシパル ARN が自動的に記録され、Cost Explorer でもタグによるグルーピングやフィルタリングが可能です。詳細は こちらのドキュメントをご参照ください。 4/10(金) Amazon RDS が Microsoft SQL Server の最新 CU および GDR アップデートをサポート Amazon RDS for SQL Server で Microsoft SQL Server の最新セキュリティアップデートが利用可能になりました。SQL Server 2016 から 2019 では CU+GDR、SQL Server 2022 では CU24 に対応しています。GDR アップデートではセキュリティ脆弱性 CVE-2026-21262 と CVE-2026-26115 が修正されます。RDS コンソールや AWS SDK、CLI からアップグレード可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

みなさん、こんにちは。AWS のソリューションアーキテクトの伊藤ジャッジです。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 過去の月刊製造ブログはこちらです 。未読の方はあわせてご覧ください。 さて、AWS は創立二十周年を迎えました! AWS のサービスもお客様と共に成長してきました。その軌跡を こちらの二十周年記念記事 でご覧ください。これからも皆様からのフィードバックを元に、サービス改善を続けていきます。 AWS の節目の時期となりましたが、4 月は多くの企業も年度始まりですね。フレッシュな区切りの時期ですが、一方で先月末の棚卸しという重要なタスクもあったと思います。今回は、在庫管理、需要予測またサプライチェーン管理に役立つ情報をピックアップコンテンツとして特集をします。 ピックアップトピック：サプライチェーン管理 製造業において在庫管理は、経営効率の中枢を担う機能の一つです。在庫不足は生産ラインの停滞や顧客納期の遅延を招きますし、過剰在庫は保管コストやキャッシュフローを圧迫します。多品種少量生産や受注変動が常態化する現代では、単に在庫を管理するだけでなく、需要変動を先読みし供給網全体を最適化する仕組み作りが不可欠になっています。 ここで鍵を握るのが、需要予測とサプライチェーンマネジメントの活用です。販売実績や市場動向、季節要因、経済指標など多様なデータを AI で解析し、過去の傾向をつかみ将来の需要を精度高く予測し、必要量を前もって準備できます。これにより「作りすぎ」「作らなさすぎ」のムダを減らし、生産・調達・物流を連動させた全体最適が実現します。 こうしたデータドリブンな仕組みを飛躍させるのがクラウド技術です。工場や倉庫、販売拠点から収集されるさまざまな記録をクラウドに統合し、データの可視化と分析を可能にします。さらにエージェントAI を活用することにより、全体を俯瞰しながらボトルネックや需給ギャップを自律的に発見し、複数拠点をまたいだ調整のアクションまで実行できます。AI による「データ駆動の意思決定サイクル」を回しやすいのがサプライチェーンの領域といえます。 お客様事例 3 月には、サプライチェーン関連のお客様事例として、OPLOG 社 の AWS の AI サービスの活用の事例が発表されています。 1. Learn how technology-driven fulfillment company OPLOG accelerated decision-making using Amazon Bedrock AgentCore 倉庫管理企業の OPLOG 社が、AIエージェント × ロボティクスで倉庫オペレーションを変革した事例です。 Amazon Bedrock AgentCore を使って複数のAIエージェントがリアルタイムに数千の判断を下す基盤を構築しました。その結果、意思決定時間、稼働率、コスト全ての効率が上がりました。生成 AI エージェントを本番投入したい方が、構想→PoC →スケーラビリティのイメージをつかむための良い事例ですので、ぜひ元記事でご確認ください。 2. Amazon Multi-Channel Fulfillment and Buy with Prime Accelerators for SAP S/4HANA が利用可能に こちらは 1 月の発表とはなりますが、 SAP S/4HANA から Amazon MCF と Buy with Prime を直接アクセスできるようにすることで、在庫一元管理と出荷を自動化し、欠品・過剰在庫の抑制や在庫管理のコスト削減といった効果が期待できる、という機能の発表がありました。 こちらは既存 SAP への変更を最小限に抑えつつ、Prime 配送や簡単返品などの購入体験を自社 EC にも拡張できる機能となります。詳細の仕組みについては、ぜひリンク先本文をお読みください。 Amazon 社との協業 Amazon is investing AU$750 million in a robotics fulfillment center in Australia Amazon 社の倉庫におけるロボティクス技術活用がまた進化したニュースが 3 月に発表されました。オーストラリアに新しいロボット駆動のフルフィルメントセンターを建設します。ここでは人とロボットが協働し、ロボットが重量物や反復作業を担うことで、従業員は判断が必要な業務に集中できるように設計されています。安全性と効率性を両立した職場づくりの取り組みや倉庫業務を行う、ワクワクする最新ロボットの詳細につきましては、リンク先をご覧ください。 AWS が提供する ワークショップ コンテンツ AWS からはセルフペースで手を動かしながらサンプルを構築し、サービスについて学べるワークショップが提供されています。3 月には、サプライチェーンの課題にフォーカスした下記のワークショップが新しくリリースされました。 Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 このハンズオンワークショップでは、 Amazon Bedrock AgentCore の機能を使用して既存のサプライチェーンシステムを強化する方法を学びます。 Strands Agents SDK とインタラクティブな Jupyter ノートブックを使用して、紛争や天災によるサプライチェーンの混乱を分析し、在庫配分を最適化し、緩和戦略を自律的に実行できるサプライチェーン管理システムを構築できます。 Amazon Bedrock AgentCore で実現する Chronos-2 を用いた時系列予測エージェント 時系列予測は在庫管理の分野で活用されてきましたが、このワークショップで体験できる Chronos は、AWS が開発した時系列基盤モデルです。事前に膨大な時系列データでトレーニングされた時系列予測モデルで、大規模言語モデルで利用されている Transformer を応用することで、予測対象の実績データをトレーニングすることなく、さまざまなケースで高い精度の予測を実現します。Chronos-2 はその最新モデルで、多変量予測においても、新しいデータセットに対して追加学習なしで、即座に高精度な予測が可能になっています。AWSのソリューションアーキテクトが執筆した 紹介ブログ もあります。 上記のワークショップにご興味をもたれましたか？ぜひ貴社の技術支援担当の者か、 技術支援窓口 にお問い合わせください。 なお、 AWSからはサプライチェーン系ワークロードを AWS 上で設計・運用する際のベストプラクティスと設計指針を体系的に示す Supply Chain Lens – AWS Well-Architected Framework が提供されていますので、あわせてご参照ください。 企業競争力の源泉は、もはや製造スピードだけではなく、データに基づく俊敏なサプライチェーン運営にあります。クラウドと AI を活用した在庫・需要・供給そして AI によるアクションの統一管理が、製造業の持続的な成長を支える次のステージとなるでしょう。今回のピックアップトピックが、皆さまのより良いサプライチェーン運営のきっかけになれば幸いです。 以上、4 月のピックアップコンテンツでした。 直近で開催予定のイベント・セミナー CAE in the Cloud 2026　〜 自動車・製造業向けCAEセミナー 〜 本年 2 月（東京リージョンは 3 月）に一般提供開始した Hpc8a インスタンス をはじめとしたAWS の最新ソリューションの情報をお届けするイベントです。4 月 20 日の週に東京・大阪・名古屋 3 か所で開催します。 Hannover Messe 先月号 でも紹介しましたが、2026 年 4 月 20 日（月）～ 4 月 24 日（金）に製造業の国際展示会がドイツのハノーヴァーで開催されます。 詳細はブログ記事、「 Hannover Messe 2026 で知る AWS による産業 AI の大規模展開 」もご参照ください。AWS もブース展示しますので、ホール 15、ブース D76 の AWS ブースにご来訪ください。 AWS JumpStart 2026 「AWS を使ってみたいけれど、学習方法がわからない」という初学者を対象に、AWS JumpStart 2026 が開催されます。直近では、2026年 5 月 11 日 (月) ~ 5 月 12 日 (火)（各回 2 日間：9 – 18 時）のオンライン開催となっています。製造業に限らず、高度な専門分野の技術に長けた専門家の皆様で、今までクラウドには触れてこなかった方は多くいらっしゃると思います。１モジュールから参加できますので、この機会に触れてみてください。 AWS Summit Japan 2026 今年も日本最大の “AWS を学ぶイベント” AWS Summit Japan が 6 月 25 日（水）、26 日（木）の二日間で開催されます！ベストプラクティスの共有や情報交換のこのチャンスにぜひご来場ください。[ 動画 ] フィジカル AI、シミュレーション、サプライチェーンなどの、去年よりパワーアップした製造業向け展示もあります！ 過去 の イベント の 見逃し配信 や 動画 JAWS-Days AWS 利用者コミュニティ、JAWS のイベントが 3 月 7 日に行われました。皆様はご参加されましたか？あいにく行けなかった！という方にもアーカイブ動画が出ています。SAP、セキュリティといった製造業の皆様にも役にたつ動画が満載のアーカイブです。ぜひご覧ください。 CES 2026 – Physical AI for Adaptive Automotive Manufacturing | AWS Events 1 月に開催された CES の動画が AWS の公式チャンネルで公開されました。 AWS のデモでは、フィジカル AI が工場現場をどのように変革するかを紹介しました。こちらの動画では AWSの 5 つの要素（データ、トレーニング、シミュレーション、Sim 2 Real、Agentic なオーケストレーション）を柱に、物理の工場のモダン化から未来の工場設計まで、次世代の自動車生産を実現するデモのサマリをご覧いただけます。 製造関連の アップデート Auto &amp; Manufacturing – Kiro for Business Users AWS が提供する AI コーディングアシスタント「 Kiro 」を活用して流体シミュレーションの構築から 3D モデリングを試行できるワークショップが3月に公開されています。製造業の設計部門の方々のご活用をお待ちしています。AWS のソリューションアーキテクトが執筆した日本語の 紹介ブログもあります 。 AWS IoT Greengrass v1 サポート終了 半年後の 2026 年 10 月 7 日に、Greengrass v1 のサポートが終了します。製造業の皆様は工場などクローズな環境や、スマートプロダクトに使っているかもしれません。まだの場合は早急な AWS IoT Greengrass v2 への移行をお願いします。 製造関連の Blackbelt Online Seminar アップデート 【AWS Black Belt Online Seminar】AWS IoT Greengrass コンポーネント開発編 エッジデバイス上でアプリケーション（コンポーネント）を動かし、クラウド側から一括デプロイ・更新・管理できる AWS IoT Greengrass の「コンポーネント開発編」の解説動画が 3 月にリリースされました。 製造業のお客様のAWS活用事例 下記は、3月に発表された製造業のお客様事例となります。製造業の皆様のもつ課題やゴールと似たお話があるかもしれません。ぜひ本文をご覧ください。 How Amazon Devices Eliminated Credential Risk to Scale AI across Engineering Tools Amazon 社には自社で開発・販売しているハードウェア製品 を取り扱う Amazon Devices という組織があります。この組織でハードウェア開発を加速するため、Creo、 Parametric、SOLIDWORKS、ANSYS など 60 以上のエンジニアリングツールに直接 AI を統合する必要がありました。10,000 人以上のエンジニアが使用しているこれらのツールは、ローカルのワークステーション上で動作しているため、セキュリティを維持しながらクラウド上の AI を活用できる仕組みが求められていました。このブログでは、Amazon Devices のエンジニアが、クレデンシャル配布をせずに認証して、ローカルの設計ツールから Amazon Bedrock にセキュアに接続した方法を寄稿しています。 The Evolution of BMW Group’s 3D Streaming Experience BMW 社は、オンプレミスで稼働していたディーラー向けの 3D 車両ストリーミングを、 AWS 上の Linux GPU（g4dn.2xlarge）でグローバル提供できる 3D ストリーミング基盤に移行しました。製造業の R&amp;D 部門の皆様は 3D データを配信する場面があると思います。ぜひご参考にしてください。 Driving Intelligent Quality in the Software-Defined Vehicle Era Upstream 社の PQD (Proactive Quality Detection) が Ocean AI エンジンを使用して「モビリティ特化のインテリジェンス層」を AWS のスケーラブルなインフラ・ストレージ・セキュリティ・AI 基盤上で提供しています。SDV 時代の品質管理を、実環境のデータベースの継続的な予測型プロセスに変革することに成功した事例をご覧ください。 AI 時代に組織はどう変わるか — Jeff Barr が語る開発チームの未来と、三菱電機の挑戦 三菱電機はデジタル基盤「 Serendie 」による DX を進め、モノの販売中心からデジタルサービスのコト売りへ事業転換中です。この過程で、AI 時代の開発組織についてのインサイト、生産性向上事例と KPI の変化、人材育成、コミュニティと組織変革について、イベントのため来日した、AWS の Chief Evangelist である Jeff Barr との対話しました。 三菱電機が挑む製造業の商談変革 – AWS で実現した商談支援サービス「Memory Tec h」 三菱電機名古屋製作所は、製造業の商談で起きがちな「口頭コミュニケーションの認識齟齬」を解消するため、AI商談支援サービス「 Memory Tech 」をAWS上で新規開発しました。 AWS のサーバーレス構成により、ブラウザやスマホだけで商談録音から 2 分以内の議事録自動生成を実現し、少人数でスモールスタートとスケーラブルな運用を両立しました。詳細は本文をご覧ください。 電通総研、大規模 GPU 環境を約 1 ヶ月で構築 〜リアルタイム 3DCG ソリューション「UNVEIL」の戦略的アプローチ 〜 電通総研はリアルタイム 3DCG メタバース「UNVEIL」の大規模イベント利用に向け、1,000 名同時接続で低レイテンシーを満たす GPU 環境を AWS 上に約 1カ月で構築しました。東京リージョンで Amazon EC2 g4dn/g5 や Amazon EKS などを活用し、段階的な負荷試験と複数回の事前テストでボトルネックを洗い出しつつ、イベント駆動型ワークロードに適した、スケーラブルかつコスト効率の高いアーキテクチャを設計しました。どのように実装したのでしょう。ぜひ本文をチェックしてください。 キヤノン株式会社イメージング事業本部様にて生成 AI ハッカソンを開催！生成 AI をフル活用し社内課題を解決する 5 つのシステムを開発 キヤノン 株式会社 イメージング 事業本部と AWS が協力し、社内業務課題を生成 AI で解決することをテーマに約 6 カ月のハッカソンを実施した事例です。 約 20 名のエンジニアが 5 チームに分かれ、AWS の生成 AI サービスの勉強会、アイデアソン、プロトタイピングを通じて、実用レベルの 5 つのプロトタイプを開発し、いくつかのプロトタイプでは実業務での活用検討が進んでいます。 最後まで読んでいただきありがとうございました。今月は サプライチェーン管理に役立つ情報をピックアップしてお届けしました。このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。 月刊 AWS 製造ブログ を今後ともよろしくお願いします。それでは、また来月お会いしましょう！ &nbsp; 伊藤ジャッジ向子 (Ito, Judge Sakiko) 米国での開発者経験を経て、AWSのサポートに入社し、異動しエンタープライズ事業本部でソリューションアーキテクトとして製造業のお客様をご支援しています。趣味は山登り、クラッシックバレエと愛犬のお世話です。

本記事は 2026 年 4 月 7 日 に公開された「 Launching S3 Files, making S3 buckets accessible as file systems 」を翻訳したものです。 Amazon S3 Files の提供開始をお知らせします。S3 Files は、あらゆる AWS コンピューティングリソースと Amazon Simple Storage Service (Amazon S3) をつなぐ新しいファイルシステムです。 10 年以上前、私がAWS トレーナーだった頃、オブジェクトストレージとファイルシステムの基本的な違いを説明するのに多くの時間を費やしました。よく使ったたとえ話は、S3 オブジェクトを図書館の本に見立てるものでした (1 ページだけ編集することはできず、本ごと差し替える必要がある)。一方、コンピュータ上のファイルはページ単位で変更できます。図を描き、比喩を考え、ワークロードごとに異なるストレージタイプが必要な理由をお客様に説明してきました。そして今日、オブジェクトストレージとファイルシステムの境界がより柔軟になります。 S3 Files により、Amazon S3 はクラウドオブジェクトストアとして唯一、高性能なファイルシステムアクセスを提供します。バケットをファイルシステムとしてアクセスでき、ファイルシステム上のデータ変更は自動的に S3 バケットに反映されます。同期もきめ細かく制御できます。S3 Files は複数のコンピューティングリソースにアタッチでき、データを複製せずにクラスター間で共有できます。 これまでは、Amazon S3 のコスト効率、耐久性、S3 からネイティブにデータを利用できるサービス群と、ファイルシステムの対話的な操作性のどちらかを選ぶ必要がありました。S3 Files でこのトレードオフは不要になります。S3 が組織のデータ基盤となり、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、関数など、あらゆる AWS コンピューティングリソースから直接アクセスできます。本番アプリケーションの実行、ML モデルのトレーニング、エージェント型 AI システムの構築など、用途を問いません。 汎用バケットを、EC2 インスタンス、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) 上のコンテナ、 AWS Lambda 関数からネイティブファイルシステムとしてアクセスできます。ファイルシステムは S3 オブジェクトをファイルやディレクトリとして表示し、 Network File System (NFS) v4.1 以降のすべての操作 (ファイルの作成、読み取り、更新、削除) をサポートします。 ファイルシステムで特定のファイルやディレクトリを操作すると、関連するメタデータとコンテンツが高性能ストレージに配置されます。デフォルトでは、低レイテンシーアクセスの恩恵を受けるファイルは高性能ストレージに保存され、そこから提供されます。大規模なシーケンシャル読み取りが必要なファイルなど、高性能ストレージに保存されていないファイルについては、S3 Files がスループットを最大化するため Amazon S3 から直接提供します。バイト範囲読み取りでは、要求されたバイトのみが転送されるため、データ移動とコストを最小限に抑えられます。 データアクセスパターンを予測する的確なプリフェッチにも対応しています。高性能ストレージに保存する内容もきめ細かく制御でき、ファイルデータ全体を読み込むか、メタデータのみを読み込むかを選択して、アクセスパターンに応じた最適化が可能です。 仕組みとしては、S3 Files は Amazon Elastic File System (Amazon EFS) を基盤とし、アクティブなデータに対して約 1 ミリ秒のレイテンシーを実現します。NFS の close-to-open 整合性で複数のコンピューティングリソースからの同時アクセスをサポートするため、データを変更する対話的な共有ワークロードに最適です。ファイルベースのツールで連携する AI エージェントや、データセットを処理する ML トレーニングパイプラインなどが該当します。 使い方を紹介します 初めての Amazon S3 ファイルシステムの作成、マウント、EC2 インスタンスからの利用は簡単です。 EC2 インスタンスと汎用バケットを用意しています。以下のデモでは、S3 ファイルシステムを設定し、通常のファイルシステムコマンドで EC2 インスタンスからバケットにアクセスします。 デモでは AWS マネジメントコンソール を使用します。 AWS Command Line Interface (AWS CLI) や Infrastructure as Code (IaC) も利用できます。 デモのアーキテクチャ図は以下のとおりです。 ステップ 1: S3 ファイルシステムを作成します。 コンソールの Amazon S3 セクションで File systems を選択し、 Create file system を選択します。 ファイルシステムとして公開するバケット名を入力し、 Create file system を選択します。 ステップ 2: マウントターゲットを確認します。 マウントターゲットは、仮想プライベートクラウド (VPC) 内に配置されるネットワークエンドポイントです。EC2 インスタンスから S3 ファイルシステムにアクセスするために使用します。 コンソールではマウントターゲットが自動的に作成されます。 Mount targets タブで Mount target ID を確認します。 CLI を使用する場合は、ファイルシステムとマウントターゲットの作成に 2 つのコマンドが必要です。まず create-file-system で S3 ファイルシステムを作成し、次に create-mount target でマウントターゲットを作成します。 ステップ 3: EC2 インスタンスにファイルシステムをマウントします。 EC2 インスタンスに接続し、以下のコマンドを実行します。 sudo mkdir /home/ec2-user/s3files sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files ~/s3files にマウントされたファイルシステムで、標準的なファイル操作を使って S3 データを直接操作できます。 ファイルシステム上でファイルを更新すると、S3 が自動的にすべての更新を管理し、数分以内に S3 バケット内の新しいオブジェクトまたは既存オブジェクトの新しいバージョンとしてエクスポートします。 S3 バケット上のオブジェクトに加えた変更は、数秒以内にファイルシステムに反映されますが、1 分以上かかる場合もあります。 # Create a file on the EC2 file system echo "Hello S3 Files" &gt; s3files/hello.txt # and verify it's here ls -al s3files/hello.txt -rw-r--r--. 1 ec2-user ec2-user 15 Oct 22 13:03 s3files/hello.txt # See? the file is also on S3 aws s3 ls s3://s3files-aws-news-blog/hello.txt 2025-10-22 13:04:04 15 hello.txt # And the content is identical! aws s3 cp s3://s3files-aws-news-blog/hello.txt . &amp;&amp; cat hello.txt Hello S3 Files 知っておくべきこと 技術的な詳細をいくつか紹介します。 S3 Files は AWS Identity and Access Management (IAM) と統合されており、アクセス制御と暗号化に対応しています。 ID ベースのポリシーとリソースポリシーで、ファイルシステムレベルとオブジェクトレベルの両方で権限を管理 できます。 データは TLS 1.3 による転送中の暗号化と、Amazon S3 マネージドキー (SSE-S3) または AWS Key Management Service (AWS KMS) のカスタマーマネージドキーによる保管時の暗号化で常に保護されます。 S3 Files は POSIX パーミッションを使用し、S3 バケットにオブジェクトメタデータとして保存されたファイルパーミッションに対してユーザー ID (UID) とグループ ID (GID) を照合します。 S3 Files の監視には、ドライブのパフォーマンスと更新に関する Amazon CloudWatch メトリクスと、管理イベントのログ記録に AWS CloudTrail を使用できます。 EC2 インスタンスに最新バージョンの EFS ドライバー ( amazon-efs-utils パッケージ ) がインストールされていることを確認してください。AWS が提供する Amazon Machine Image (AMI) にはプリインストールされています。執筆時点では、最新バージョンに更新できます。 本記事では EC2 インスタンスからの S3 Files の使用方法を紹介しました。ECS や EKS のコンテナ ( AWS Fargate の有無を問わず)、Lambda 関数からも S3 バケットをファイルシステムとしてマウントできます。 お客様からよく聞かれるのが、ワークロードに適したファイルサービスの選び方です。AWS のサービスは一見重複しているように見え、アーキテクチャレビュー会議でクラウドアーキテクトを悩ませることもあります。ファイルサービスの使い分けを整理しましょう。 S3 Files は、Amazon S3 に保存されたデータに高性能なファイルシステムインターフェースで対話的に共有アクセスする必要がある場合に最適です。本番アプリケーション、Python ライブラリや CLI ツールを使用する AI エージェント、ML トレーニングパイプラインなど、複数のコンピューティングリソースがデータを読み書きし、共同で変更するワークロードに適しています。データを複製せずにコンピューティングクラスター間で共有アクセスでき、サブミリ秒のレイテンシーと S3 バケットとの自動同期を実現します。 オンプレミスの NAS 環境から移行するワークロードには、 Amazon FSx が使い慣れた機能と互換性を提供します。Amazon FSx は、 Amazon FSx for Lustre によるハイパフォーマンスコンピューティング (HPC) や GPU クラスターストレージにも最適です。 Amazon FSx for NetApp ONTAP 、 Amazon FSx for OpenZFS 、 Amazon FSx for Windows File Server など、特定のファイルシステム機能が必要なアプリケーションに特に有効です。 料金と利用可能リージョン S3 Files は、すべての商用 AWS リージョン で利用できます。 S3 ファイルシステムに保存されたデータの容量、小さなファイルの読み取りとすべての書き込み操作、ファイルシステムと S3 バケット間のデータ同期時の S3 リクエストに対して課金されます。 Amazon S3 の料金ページに詳細 があります。 お客様との対話を通じて、S3 Files はデータサイロ、同期の複雑さ、オブジェクトとファイル間の手動データ移動を排除し、クラウドアーキテクチャの簡素化に役立つと考えています。ファイルシステムで動作する本番ツールの実行、ファイルベースの Python ライブラリやシェルスクリプトに依存するエージェント型 AI システムの構築、ML トレーニング用データセットの準備など、S3 Files を使えば Amazon S3 の耐久性とコストメリットを犠牲にすることなく、対話的な共有ワークロードから S3 データに直接アクセスできます。Amazon S3 を組織のデータ保管場所として使用でき、あらゆる AWS コンピューティングインスタンス、コンテナ、関数からデータに直接アクセスできます。 詳細と使い方については、 S3 Files のドキュメント をご覧ください。 S3 Files をどのように活用されるか、ぜひお聞かせください。フィードバックをお待ちしています。 — seb 著者について Sébastien Stormacq 80 年代半ばに Commodore 64 に触れて以来コードを書き続けている。情熱、好奇心、創造性を武器に、AWS クラウドの価値を引き出すビルダーを支援している。ソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティングに関心がある。Bluesky、X、Mastodon などで @sebsto をフォローできる。 この記事はVisual Compute Specialist Solutions Architect の森が翻訳を担当しました。

本ブログは 【寄稿】AI民主化に向けた丸紅の取組 （丸紅株式会社）の続編です。 みなさん、こんにちは。総合商社を担当しているソリューションアーキテクトの林です。 前回のブログでは、 丸紅株式会社 デジタル・イノベーション部が内製で開発した社内生成 AI プラットフォーム「Marubeni Chatbot」の誕生から、7,500 人以上への展開、そして業務時間 25〜65% 削減という成果をご紹介しました。 あれから約1年半。丸紅グループの生成AI活用は、さらに大きく進化しています。前回のブログに引き続き、デジタル・イノベーション部 芹川 武尊 氏からお話を伺いました。 今回は、Marubeni Chatbot のその後の進化に加え、新たに立ち上がった 3 つの取り組みをご紹介します。丸紅グループが生成 AI をどのように業務や開発の現場に根付かせてきたか、ぜひご覧ください。 Digital Experts 株式会社について 丸紅グループの生成 AI 活用を語る上で欠かせない存在が、 Digital Experts 株式会社 です。丸紅グループ各社の新たな取り組みに対し、高いエンジニアリング力で実証から実装・運用まで一気通貫で支援する会社です。 Digital Experts の最大の特徴は、 全社員がコーディングエージェントを用いて日常の開発業務を行っている 点です。 社内プレゼン作成ツールをはじめ、業務に必要なシステムを自分たちで開発・活用するなど、生成 AI を日常の開発業務に深く組み込んでいます。本ブログで紹介する取り組みの多くは、丸紅 デジタル・イノベーション部と Digital Experts の緊密な連携によって実現したものです。 取り組み1：Marubeni Chatbot — エージェント AI への進化 前回ブログでご紹介した Marubeni Chatbot は、登録ユーザー数が 7,500 人以上から 10,000 人以上 へと拡大し、丸紅グループ全社の日常業務に欠かせないプラットフォームへと成長しました。 AI エージェントの搭載 基本的な対話 UI に加え、LLM が自律的に試行錯誤を行い複雑なタスクをこなすエージェント機能の搭載を進めています。 このエージェント機能の中核を担うのが、 Amazon Bedrock AgentCore です。AgentCore Runtime を活用することで、従来のサーバーレス構成では課題となっていた長時間実行のタイムアウト問題を解消し、複雑なエージェントタスクを安定して実行できる環境を実現しています。 Marubeni Chatbotのアーキテクチャ図 今までの機能に加え、新たに以下のような機能も追加されています。 PowerPoint 自動生成ツール ：高品質なプレゼンテーションを半自動で生成。社内プレゼン作成の工数を大幅に削減 データ分析・ドキュメント生成システム ：社内情報を参照した上で、データ分析からドキュメント生成までを一気通貫で実行 Marubeni Chatbotの画面イメージ 取り組み2：競合分析システム — 対話形式で市場を読み解く 総合商社において、市場や競合の動向を迅速に把握することは、事業判断の精度を左右する重要な要素です。丸紅は、外部データソースや Web 上の情報を AIと組み合わせることで、競合分析を支援するシステムを構築しました。 本システムでは、財務データベース、Web データ、ユーザーがアップロードした PDFなど、複数のデータソースを横断的に蓄積・参照できる基盤を整備しています。LLM が Tool useを通じて必要なデータへ動的にアクセスすることで、競合企業の候補を AI が列挙し、各社の事業概要や財務状況の要約、 比較分析からレポート作成までを対話形式で AIが支援 します。 競合分析システムの画面イメージ 競合分析業務では、多数の企業情報の収集・整理に加え、財務指標の横断分析や市場ポジションの評価など、長時間かつ複雑な処理が求められます。こうした要件に対応するため、AI エージェントの実行基盤として Amazon Bedrock AgentCore を採用しました。これにより、 AWS Lambda の実行時間制約を超える長時間の自律的な情報収集・分析を実現しています。 さらに、Web 上の公開情報に加え、信頼性の高い外部データソースの定量データを組み合わせることで、実務の意思決定に活用できる分析品質を確保しています。 ユーザーは、「このセクターの競合他社の財務状況を比較して」「最新のニュースを踏まえてリスクを整理して」といった自然言語での問いかけを行うだけで、AIがリアルタイムに関連データを参照しながら回答を生成します。 競合分析システムのアーキテクチャ図 取り組み3：水道管路 AI 劣化予測診断サービス — 作業時間を 99% 削減 丸紅株式会社の旧環境インフラプロジェクト部と Digital Experts 株式会社が共同で開発した、水道管路の AI 劣化予測診断サービスです。日本全国の自治体が抱える水道インフラの老朽化問題に対し、人手不足・技術継承の困難・予算制約という課題を AI で解決することを目指しました。 自治体から管路データを受領し、データの前処理・AI での分析・レポーティングまでの業務全体の作業時間を 5 ヵ月から 1.5 ヵ月へ大幅に削減 。さらに、AI を活用したデータサイエンス業務の自動化により、 分析作業を約 99% 削減 することに成功しました。 AI による分析結果を GIS（地理情報システム）上に反映することで、更新が必要な管路を視覚的に把握できるようになり、自治体の意思決定を大きく支援しています。スモールスタートから始め、ビジネスの成長に合わせて柔軟にスケールできる構成を採用しており、 AWS Control Tower と AWS IAM を活用したマルチアカウント構成により、異なるアクセスレベルのメンバーへの適切な権限分離を実現。機密保護と効率的な共同開発を両立しています。 水道管路 AI 劣化予測診断サービス アーキテクチャ図 取り組み4：AI DLC Unicorn Gym — 「AI と共に開発する」文化の醸成 Marubeni Chatbot の展開や競合分析・水道管路診断といった取り組みを通じて、丸紅グループ内で生成 AI の活用が着実に広がっていました。こうした流れを受け、AWS から「開発プロセスそのものに AI を組み込む」次のステップとして提案・実施したのが、AI DLC Unicorn Gym です。 2026 年 2 月、丸紅株式会社と Digital Experts 株式会社、 丸紅I-DIGIOホールディングス株式会社 の合計 23 名が参加した 3 日間の AI DLC Unicorn Gym を開催しました。 AI DLC Unicorn Gym とは AI-DLC とは、AI をソフトウェア開発の中心的な協働者として位置づけ、開発ライフサイクル全体に AI の能力を組み込む新しい開発手法です。AI が計画を立案・実行し、人間が重要な意思決定を担うという役割分担のもと、Inception（要件定義）・Construction（設計・実装）・Operations（デプロイ・運用）の 3 フェーズで開発を進めます。 Kiro といったコーディングエージェントを活用することで、開発速度を大幅に向上させることができます。AI DLC Unicorn Gym は、この手法を実際のプロダクト開発を通じて体験する AWS のプログラムです。 実業務テーマで挑む 3 日間：開発から成果発表まで 「社内ユーザー用のサンドボックスアプリ基盤」「牛体重推定アプリ」「Marubeni Chatbot 内でのSkills 共有プラットフォーム」「稼働管理ツール」「議事録作成システムの高度化」と、領域・規模感の異なる 5 テーマに取り組みました。途中で方向修正が発生したチームもありましたが、生成 AI を活用することで修正コストを大幅に抑え、 全チームが 3 日間で成果物を完成 させました。最終発表では AWS にデプロイした環境を用いたデモを実施するチームもいました。非エンジニアはAIに要件を伝えるとともにビジネス上の意思決定を行い、エンジニアはAIが生成した成果物をレビューし、要件が正しく反映されていることを確認することで、「AI を使えば自分たちでも作れる」という実感を得る場となりました。「AI-DLC がいかに強力なツールであるかは、ワークショップを体験してみないとなかなか伝わりづらい」というアンケートコメントが象徴するように、実際に手を動かすことで初めて実感できる体験となりました。 最終発表会の様子 議事録作成システム（成果物デモ画面） おわりに Marubeni Chatbot はエージェント機能を搭載し 10,000 人超の日常業務を支えるプラットフォームへと進化。競合分析システムや水道管路 AI 劣化予測診断サービスでは、AI が業務の中核を担い、定量的な成果を生み出しています。そして AI DLC Unicorn Gym では、エンジニア・非エンジニアが共同するAIネイティブなソフトウェア開発プロセスを体感できました。 AWS は今後も、丸紅グループの生成 AI 活用がさらに広がり深まるよう、技術・知見の両面から支援を続けてまいります。本ブログが、皆さまの生成 AI 活用の参考になれば幸いです。 著者プロフィール 芹川 武尊 (Takeru Serikawa) 丸紅株式会社 デジタル・イノベーション部 2022年 東京大学大学院情報理工学系研究科修士課程修了。情報理工学修士（数理最適化に関する研究）。大学院修了後、丸紅株式会社に入社。入社後は、物流関連最適化システムの開発や、生成AIを活用したグループ会社向けChatbotアプリの開発など丸紅グループを横断したプロジェクトに参画。 林 隆太郎 (Ryutaro Hayashi) アマゾンウェブサービスジャパン 総合商社・エネルギー業界担当 ソリューションアーキテクト 大手ガス会社にてガススマートメーター・電力トレーディングのシステム開発を経験した後、総合商社にて全社の IT/DX 推進と国内外のエネルギー領域での事業投資・新規事業開発を担当。現在は AWS 総合商社・エネルギー業界のソリューションアーキテクトとして、業界知識を活かした AWS 活用に携わる。

2026 年 3 月 30 日週、私はチームと一緒に AWS 香港ユーザーグループ を訪問しました。香港には小さいながらも強力なコミュニティがあり、彼らにはすばらしいエネルギーと情熱があります。彼らは最近、新しい AI ユーザーグループを立ち上げたので、私たちはさらに多くの人が参加することを願っています。すばらしい料理と会話を通して、コミュニティとの絆を強めることもできました。 2026 年 4 月 6 日週は、まずいくつかの主要な発表について詳しく見ていきます。 AWS DevOps エージェントおよびセキュリティエージェント GA 前回の re:Invent では、複数のステップにわたって自律的に作業して成果を達成し、仕事が完了するまで継続的に活動する フロンティアエージェントの概念 を紹介しました。最初の 2 つ ( AWS DevOps エージェントと AWS セキュリティエージェント ) は、プレビュー後に一般提供されるようになりました。 AWS DevOps エージェント は、インシデントの調査、解決までの時間の短縮、問題の発生前の防止など、クラウド運用の実行に役立ちます。ユナイテッド航空、ウエスタンガバナーズ大学 (WGU)、T-モバイルなどのお客様は既に DevOps エージェントを使用してインシデント対応を加速し、大規模な運用を簡素化しています。WGU では、解決にかかる時間が数時間から数分に短縮され、プレビュー版では MTTR が最大 75% 短縮され、解決が 3～5 倍早くなったという報告が顧客から寄せられています。詳細については、 Sébastien のプレビューブログ投稿 と GA の発表 をご覧ください。 AWS セキュリティエージェント は、開発ライフサイクルに継続的かつ状況に応じたペネトレーションテストを行います。このエージェントは人間のペネトレーションテスターのように動作します。LG CNS、HENNGE、Wayspring などのお客様は好調な業績を上げています。LG CNS では、誤検出が大幅に減り、テストにかかる時間が 50% 以上短縮され、コストも最大 30% 削減されるという結果が出ています。詳細については、 Esra のプレビューブログ投稿 と GA の発表をご覧ください。 どちらも AWS クラウド、マルチクラウド、オンプレミス環境で機能するように設計されています。面倒な作業を処理できるチームメイトをいつでも確保できるので、最も重要なことに集中できます。 AWS サービス可用性アップデート AWS のサービスまたは機能の可用性が変化した場合、私たちは運用の中断を最小限に抑えるために、利用可能な代替案について AWS 製品ライフサイクル の変更に関するガイダンスをお客様に提供し、移行をサポートします。次のライフサイクル変更は、2026 年 3 月 31 日に更新されました。 メンテナンス中のサービスの可用性変更ガイド AWS App Runner AWS Audit Manager AWS CloudTrail – Lake AWS Glue – Ray のジョブ AWS IoT FleetWise Amazon Application Recovery Controller (ARC) – 準備状況チェック Amazon Comprehend – トピックモデリング、イベント検出、および迅速な安全分類 Amazon Rekognition – ストリーミングイベント と バッチイメージコンテンツモデレーション Amazon Simple Notification Service (Amazon SNS) – メッセージデータ保護 (MDP) 日没時のサービスの可用性変更ガイド: AWS Service Management Connector Amazon RDS Custom for Oracle Amazon WorkMail Amazon WorkSpaces – シンクライアント 日没時のサービスリーチ: Amazon Chime SDK – プロキシセッション 私たちは、可用性の変化がお客様の業務に影響を与える可能性があることを理解しています。具体的なガイダンスについては、関連するサービスドキュメントを参照するか、AWS サポートにお問い合わせください。 2026 年 3 月 30 日週のリリース 2026 年 3 月 30 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon ECS が ECS マネージドインスタンス用のマネージドデーモンを発表 新しい AWS サステナビリティコンソール: スコープ 1～3 のレポートを 1 か所に Amazon Bedrock AgentCore Evaluations が一般提供されました AWS Transform カスタムが自動コードベース分析の一般提供を発表 Amazon CloudWatch が OpenTelemetry Container Insights for Amazon EKS を発表 (プレビュー) 最大 72 個の vCPU を搭載した Amazon Lightsail 用の新しいコンピューティング最適化インスタンスバンドル Amazon CloudFront が署名付き URL と署名付きクッキーの SHA-256 をサポートするようになりました AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 AWS 上のエージェンティック AI 開発のためのアーキテクチャ AWS Network Load Balancer を使用する際のデータ転送コストの最適化 AWS World Sports Innovation Cup の発表 – お客様のアイデアはゲームチェンジャーになるでしょうか? 本番環境での AI エージェントハルシネーションを阻止する 5 つのテクニック 3D インタラクティブグローブを通じてグローバルな AWS コミュニティを探索する AWS ブログ投稿の全リストについては、必ず AWS ブログ ページをご覧ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、それらに参加してください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 4 月 6 日週のニュースは以上です。2026 年 4 月 13 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

2026 年4 月 3 日、 Amazon Bedrock Guardrails でクロスアカウントセーフガードが一般提供されたことを発表しました。これは、組織内の複数の AWS アカウント全体での安全管理の一元的な実施と管理を可能にする新機能です。 この新機能により、組織の管理アカウント内の新しい Amazon Bedrock ポリシー 内でガードレールを指定できます。これにより、Amazon Bedrock でモデルを呼び出すたびに、設定されたセーフガードがすべてのメンバーエンティティ全体で自動的に実施されます。この組織全体での実装では、一元的な制御と管理により、すべてのアカウントと生成 AI アプリケーションでの統一された保護がサポートされています。この機能により、組織的なセーフガードに加えて、ユースケース要件に応じて、アカウントレベルおよびアプリケーション固有の制御を柔軟に適用できます。 組織レベルの実施 では、ポリシー設定を通じて、組織の管理アカウントから組織内のすべてのエンティティまで、単一のガードレールが適用されます。このガードレールでは、すべての Amazon Bedrock モデルの呼び出しに対して、組織単位 (OU) や個人アカウントを含むすべてのメンバーエンティティ全体に自動的にフィルターが適用されます。 アカウントレベルの実施 により、AWS アカウント内のすべての Amazon Bedrock モデルの呼び出し全体で、設定されたセーフガードの実施を自動的に有効にします。アカウントレベルのガードレール内の設定されたセーフガードは、すべての推論 API コールに適用されます。 単一の統一されたアプローチを通じて、信頼できる包括的な保護を確立し、一元管理できるようになりました。これにより、個々のアカウントやアプリケーションを監視する管理上の負担を大幅に軽減しながら、企業の 責任ある AI 要件の一貫した遵守がサポートされています。セキュリティチームが各アカウントの設定やコンプライアンスを個別に監視および検証する必要はもうありません。 Amazon Bedrock Guardrails での一元的な実行を開始する Amazon Bedrock Guardrails コンソールで、アカウントレベルおよび組織レベルの実施の設定を開始できます。実施の設定の前に、ガードレール設定をサポートする特定のバージョンでガードレールを作成する必要があります。これは不変のままになり、メンバーアカウントによって変更されることはありません。また、 ガードレール用のリソースベースのポリシー など、新しい機能を使用するための 前提条件 を満たす必要があります。 アカウントレベルの実施を有効にするには、 アカウントレベルの実施の設定 のセクションで [ 作成 ] を選択します。 このリージョンのこのアカウントからのすべての Bedrock 推論呼び出しに自動的に適用されるガードレールとバージョンを選択できます。一般提供に伴い、[ 含める ] または [ 除外する ] のいずれかの動作で、どのモデルが実施の影響を受けるかを定義する新機能が導入されました。 また、[ 包括的 ] または [ 選択的 ] のいずれかを使用して、システムプロンプトとユーザープロンプトの選択的コンテンツ保護制御を設定することもできます。 発信者が何をタグ付けしたかに関係なく、すべてでガードレールを実施したい場合は、[ 包括的 ] を使用します。発信者が機密コンテンツを正しく識別することを信頼できない場合は、これがより安全なデフォルトです。 発信者が適切なコンテンツへのタグ付けすることを信頼し、不要なガードレール処理を減らしたい場合は、[ 選択的 ] を使用してください。これは、発信者が混在した事前検証済みのコンテンツとユーザー生成コンテンツを処理し、特定の部分に適用されるガードレールのみが必要な場合に便利です。 実施を作成したら、アカウント内のロールを使用する実施をテストおよび検証できます。アカウントで実施されるガードレールは、プロンプトと出力の両方に自動的に適用される必要があります。 ガードレールの評価情報について応答を確認してください。ガードレールの応答には、実施したガードレール情報が含まれます。 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、または ConverseStream API を使用する Bedrock 推論呼び出しを作成してテストすることもできます。 組織レベルの実施を有効にするには、 AWS Organizations コンソール に移動して、[ ポリシー ] メニューを選択します。&nbsp;コンソールで Bedrock ポリシー を有効にできます。 ガードレールを指定する Bedrock ポリシーを作成し、それをターゲットアカウントまたは OU にアタッチできます。有効にした [ Bedrockポリシー ] と [ ポリシーを作成 ] を選択します。ガードレール ARN とバージョンを指定し、AWS Organizations の入力タグ設定を設定します。詳細については、「 AWS Organizations の Amazon Bedrock ポリシー 」と「 Amazon Bedrock ポリシーの構文と例 」をご覧ください。 ポリシーを作成したら、[ ターゲット ] タブで目的の組織単位、アカウント、ルートにポリシーをアタッチできます。 ポリシーをアタッチする組織のルート、OU、または個人アカウントを検索して選択し、[ ポリシーをアタッチ ] を選択します。 メンバーアカウントでガードレールが実施されていることをテストして、どのガードレールが実施されているかを確認できます。アタッチされているメンバーアカウントから、[組織レベルの実施の設定] セクションに、組織が実施したガードレールが表示されている必要があります。 その後、指定されたガードレール内の基本的なセーフガードが、すべてのメンバーエンティティ全体のモデル推論リクエストごとに自動的に実施され、一貫した安全管理が確保されます。個々のチームやアプリケーションのさまざまな要件に対応するために、関連付けられたガードレールを備えたさまざまなポリシーを組織内のさまざまなメンバーエンティティにアタッチできます。 知っておくべきこと 以下は、GA 機能に関する重要な考慮事項です: Bedrock に特定のモデルを推論のために含めるか除外するかを選択できるようになり、これにより、モデルの呼び出しの一元的な実施を有効にできます。また、システムプロンプトと入力プロンプトの一部または全部を保護するように選択することもできます。詳細については、「 Amazon Bedrock Guardrails の実施によるクロスアカウントセーフガードの適用 」を参照してください。 ポリシーで正確なガードレールの Amazon リソースネーム (ARN) を指定していることを確認してください。不正確または無効な ARN を指定すると、ポリシー違反となり、セーフガードが実施されず、Amazon Bedrock のモデルを推論に使用できなくなります。詳細については、「 Amazon Bedrock ポリシーを使用するためのベストプラクティス 」をご覧ください。 自動推論チェックは、この機能ではサポートされていません。 今すぐご利用いただけます Amazon Bedrock Guardrails のクロスアカウントセーフガードは、現在 Bedrock Guardrails が利用可能なすべての AWS 商用リージョンと GovCloud リージョンで一般提供されています。リージョンごとの利用可否と今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。それぞれの実施されたガードレールには、設定されたガードレールに従って料金がかかります。個々のガードレールの料金の詳細については、 Amazon Bedrockの料金ページ をご覧ください。 Amazon Bedrock コンソール でこの機能ををお試しいただき、 AWS re:Post for Amazon Bedrock Guardrails に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。