本記事は 2026 年 10 月 15 日 に公開された「 Microsoft workloads on AWS: Your complete re:Invent 2026 guide 」を翻訳したものです。 AWS re:Invent 2026 では、AWS 上で Microsoft ワークロードを実行しているお客様向けに充実したセッションを用意しています。今年のコンテンツは、AWS Transform と Kiro によるエージェンティック AI を活用した .NET と SQL Server のモダナイゼーション、Windows と SQL Server のライセンスコストからの脱却、VMware からの移行戦略、そしてクラウド移行後に Microsoft ワークロードを高いレジリエンスを保ちながら運用する方法を中心に扱います。 本記事では、モダナイゼーション、移行、ライセンス最適化、レジリエンス、DBA の基礎まで、ハンズオンワークショップからお客様事例まで、ぜひ参加していただきたいセッションを紹介します。 アプリケーションのモダナイゼーションと .NET 98.8 万行の .NET を 2 日でモダナイズするための実践ガイド | MAM346 | レベル: 300 種別: ライトニングトーク 場所: 11 月 30 日 (月) 10:30 AM – 10:50 AM PST | Wynn/Encore TNS は決済プラットフォーム Altitude (274 プロジェクト、98.8 万行のコード) を .NET Framework から .NET 10 へ、当初見積もりの 6 か月ではなく 2 日で移行し、34 件のセキュリティ脆弱性も解消しました。その実践ガイドを紹介します。 AWS Transform による .NET と SQL Server スタック全体のモダナイズ | MAM417 | レベル: 400 種別: ワークショップ 場所: 12 月 2 日 (水) 12:00 PM – 2:00 PM PST | Caesars Palace AWS Transform で .NET と SQL Server をまとめてモダナイズします。.NET Framework をクロスプラットフォームの .NET に移植し、 Amazon Aurora PostgreSQL に移行して、 Amazon ECS または Amazon EKS にデプロイすることで、運用コストを最大 70% 削減できます。ノート PC と GitHub アカウントをご持参ください。 AWS Transform による .NET モダナイゼーションのベストプラクティス | MAM411 | レベル: 400 種別: Builders’ セッション 場所: 12 月 3 日 (木) 1:00 PM – 2:00 PM PST | Caesars Palace AWS Transform エージェントと協働しながら .NET Framework アプリケーションをモダナイズするベストプラクティスを学びます。プランのカスタマイズ、ステアリングドキュメント、チェックポイント、反復的な改善を取り上げます。ノート PC とご自身のユースケースをご持参ください。 AI を活用した移植で、.NET アプリを Windows ライセンスから解放 | MAM416 | レベル: 400 種別: ワークショップ 場所: 12 月 3 日 (木) 3:30 PM – 5:30 PM PST | Caesars Palace AWS Transform のインタラクティブモードで .NET Framework 4.8 の Web Forms アプリケーションを .NET 10 の Blazor に移植し、 Kiro で変換後のランタイムの問題を修正して、 AWS Fargate 上の Amazon ECS にデプロイします。 インフラストラクチャとデータベースの移行 オンプレミスから AWS への準備: 移行前に固めるべき基本方針 | MAM210 | レベル: 200 種別: チョークトーク 場所: 11 月 30 日 (月) 9:00 AM – 10:00 AM PST | Caesars Palace リピート: 12 月 1 日 (火) 12:00 PM – 1:00 PM PST | Caesars Palace VMware からの移行でも、その他のオンプレミス環境からの移行でも、ライセンス、運用モデル、アーキテクチャ、組織としての準備状況の選択が移行結果をどう左右するかを掘り下げ、よくある落とし穴を避けられる計画を立てます。 AWS Transform によるデータドリブンな移行計画の立案 | MAM306 | レベル: 300 種別: Builders’ セッション 場所: 11 月 30 日 (月) 10:00 AM – 11:00 AM PST | Caesars Palace リピート: 12 月 3 日 (木) 11:30 AM – 12:30 PM PST | Caesars Palace AWS Transform と Discovery Agent のデータを使って環境を評価し、コストを見積もってビジネスケースを構築します。データに基づくデータセンター撤退の提案を経営層に提示できる状態でセッションを終えられます。 自信を持って移行とモダナイズを進めるための環境評価方法 | MAM211 | レベル: 200 種別: チョークトーク 場所: 11 月 30 日 (月) 10:30 AM – 11:30 AM PST | Caesars Palace リピート: 12 月 1 日 (火) 11:30 AM – 12:30 PM PST | Caesars Palace AWS Transform のエージェンティックな評価、または AWS スペシャリストやパートナーの支援で環境を明確に把握し、そのデータをもとに十分な情報に基づいた意思決定を行い、重複するライセンスを削減します。 エージェンティック AI によるモノリシックなデータベースのマイクロサービスへの分解 | MAM403 | レベル: 400 種別: チョークトーク 場所: 11 月 30 日 (月) 11:30 AM – 12:30 PM PST | Caesars Palace リピート: 12 月 1 日 (火) 1:30 PM – 2:30 PM PST | Wynn/Encore データベース構造とランタイムパターンを組み合わせた 2 層の戦略で、マイクロサービスの境界を見つけ、ストアドプロシージャからビジネスロジックを抽出する方法を学びます。 AWS Transform と Kiro を使えば、数か月かかる分析を数時間に短縮できます。 Oracle と SQL Server を目的別データベースに分解する方法 | MAM317 | レベル: 300 種別: チョークトーク 場所: 11 月 30 日 (月) 12:00 PM – 1:00 PM PST | Caesars Palace リピート: 12 月 1 日 (火) 1:00 PM – 2:00 PM PST | MGM Grand モノリシックな商用データベースを目的別のレイヤーに分解する方法をホワイトボードで解説します。トランザクションには Amazon Aurora PostgreSQL 、生成 AI 検索には Aurora pgvector、分析には zero-ETL 経由の Amazon Redshift を使い、ライセンスコストと ETL パイプラインを削減します。 AI を活用した変換による SQL Server から Aurora PostgreSQL への移行 | MAM305 | レベル: 300 種別: ワークショップ 場所: 11 月 30 日 (月) 12:30 PM – 2:30 PM PST | Caesars Palace リピート: 12 月 1 日 (火) 12:30 PM – 2:30 PM PST | MGM Grand AWS Transform で SQL Server データベースを評価し、 Amazon Aurora PostgreSQL へのスキーマ変換を自動化して依存関係を解決します。その後、変換したオブジェクトを IDE 上でレビューしてデプロイすることで、数週間かかる作業を数時間に短縮できます。 AWS Transform による SQL Server から Aurora PostgreSQL へのライブ変換 | MAM337 | レベル: 300 種別: コードトーク 場所: 11 月 30 日 (月) 1:00 PM – 2:00 PM PST | Caesars Palace AWS Transform が SQL Server とその .NET アプリケーションを Amazon Aurora PostgreSQL にモダナイズする様子をライブでご覧ください。スキーマ変換、T-SQL から PL/pgSQL への変換、Entity Framework プロバイダーの更新、そして人間によるチェックポイントを挟んだウェーブ単位のオーケストレーションを扱います。 Amazon EVS 上での VMware 環境の設計と最適化 | MAM330 | レベル: 300 種別: チョークトーク 場所: 11 月 30 日 (月) 2:30 PM – 3:30 PM PST | Caesars Palace Amazon Elastic VMware Service (Amazon EVS) 上で VMware を運用する際のアーキテクチャの判断ポイントを、本番環境のお客様事例を交えて解説します。VCF 9 のサポート、Windows Server の使用権限、ネットワーク、ストレージ、バックアップ、ディザスタリカバリを取り上げます。 大規模な VMware 脱却 : 10,000 台超のサーバー移行を支えるウェーブエンジンの設計 | MAM415 | レベル: 400 種別: チョークトーク 場所: 11 月 30 日 (月) 2:30 PM – 3:30 PM PST | Caesars Palace VMware のライセンス負担に直面していませんか。 AWS Transform が TCO 評価やウェーブ計画から、カットオーバー、モダナイゼーションまで、体系的な撤退の各フェーズをどう進め、18 か月のスケジュールを 10 か月以内に短縮するかを紹介します。 実践ガイド: 散在するデータベースの AI 対応インフラへの変換 | MAM314 | レベル: 300 種別: ライトニングトーク 場所: 12 月 1 日 (火) 12:00 PM – 12:20 PM PST | Wynn/Encore Oracle、SQL Server、VMware や Nutanix 上のデータベースを AWS に移行するための実践ガイドを紹介します。 AWS Transform とエージェンティック AI を使い、ライセンスの課題、コスト最適化、モダナイゼーションの進め方を扱います。 厳しいスケジュールのなかでの移行準備 | MAM208 | レベル: 200 種別: ブレイクアウトセッション 場所: 12 月 1 日 (火) 4:00 PM – 5:00 PM PST | Caesars Palace ライセンス変更やコンプライアンス要件でスケジュールが圧迫されたとき、移行の準備を素早く整える方法を学びます。実際のプレッシャーのなか、重大な停止ゼロで数百のアプリケーションを移行した Vanguard の事例を紹介します。 Fanatics の AWS への道のり: 5 つのデータセンター、1,800 台のサーバー、48% のコスト削減 | MAM320 | レベル: 300 種別: ブレイクアウトセッション 場所: 12 月 2 日 (水) 2:30 PM – 3:30 PM PST | Caesars Palace Fanatics Commerce は 5 つのデータセンターに 1,800 台のサーバーを抱え、AWS で 48% のコスト削減を見込みました。ライセンスを明確化する OLA 、依存関係を把握する DAP、足並みを揃える EBA 、実行を担う MAP という一連の流れを紹介します。 エージェンティック AI による Windows から Linux、SQL から PostgreSQL へのモダナイズ | MAM406 | レベル: 400 種別: ワークショップ 場所: 12 月 3 日 (木) 12:30 PM – 2:30 PM PST | Caesars Palace オンプレミスの Windows Server ワークロードを、エージェントのインストール、レプリケーション、カットオーバーを経て Amazon EC2 に移行します。その後、SQL Server を PostgreSQL に移行し、エージェンティック AI で PHP を Amazon EKS に移行します。ノート PC が必要です。 ライセンスとコストの最適化 Windows と SQL Server のライセンス費用を削減する 4 つのラボ | MAM405 | レベル: 400 種別: Builders’ セッション 場所: 12 月 3 日 (木) 8:30 AM – 9:30 AM PST | Caesars Palace Amazon EC2 上の Windows と SQL Server の費用を削減する 4 つのラボです。 AWS Compute Optimizer による適正化、 CPU の最適化 、SQL Server HA のパッシブノードのライセンス費用の削減、SQL Server Enterprise から Standard エディションへのダウングレードを扱います。 AWS でエンタープライズライセンスを最適化する戦略 | MAM209 | レベル: 200 種別: ブレイクアウトセッション 場所: 12 月 3 日 (木) 1:00 PM – 2:00 PM PST | Caesars Palace Amazon EC2 と Amazon RDS をまたいで Microsoft などのエンタープライズライセンスを最適化する手立てを学びます。一度きりの AWS Optimization and Licensing Assessment を継続的な最適化の取り組みに発展させたお客様の事例も紹介します。 レジリエンスと運用 AWS に移行する Microsoft ワークロードのためのオブザーバビリティパターン | MAM329 | レベル: 300 種別: チョークトーク 場所: 11 月 30 日 (月) 3:00 PM – 4:00 PM PST | Caesars Palace リピート: 12 月 1 日 (火) 1:30 PM – 2:30 PM PST | MGM Grand .NET アプリケーション、SQL Server データベース、Windows サービスを AWS に移行する際にオブザーバビリティの死角を作らないよう、AWS ネイティブおよびオープンソースのツールで VM、コンテナ、サーバーレスをまたいでワークロードを監視する方法を紹介します。 AWS 上の Microsoft ワークロード向け HA/DR アーキテクチャの構築とテスト | MAM401 | レベル: 400 種別: Builders’ セッション 場所: 12 月 2 日 (水) 10:00 AM – 11:00 AM PST | Caesars Palace AWS Elastic Disaster Recovery と AWS Systems Manager を使い、Windows Server と SQL Server の HA/DR を疑似的な障害に対して構築・テストし、RTO と RPO をその場で測定します。 Amazon RDS 、 Amazon S3 、 AWS Elastic Beanstalk 、 AWS Managed Microsoft AD も取り上げます。 データベース管理者の基礎 なりゆきで担当することになった SQL Server データベース管理者のための AWS 入門 | MAM311 | レベル: 300 種別: チョークトーク 場所: 11 月 30 日 (月) 10:30 AM – 11:30 AM PST | Caesars Palace リピート: 12 月 1 日 (火) 11:30 AM – 12:30 PM PST | Caesars Palace SQL Server DBA の主要な業務を、ネットワーク、セキュリティ、高可用性、ディザスタリカバリ観点から、AWS ではどう行うかを整理します。あわせて、 Kiro と AWS Transform を活用して AWS へのキャッチアップを早める方法を紹介します。 re:Invent 2026 に向けて準備する Microsoft ワークロードを AWS に移行し、モダナイズを成功させてきた AWS のエキスパートやお客様から学べるこの機会をお見逃しなく。準備の進め方は次のとおりです。 AWS re:Invent 2026 に登録する re:Invent ポータル でこれらのセッションの席を予約する #reInvent を使ってソーシャルメディアでの会話に参加する AWS Events モバイルアプリをダウンロード してスケジュールを組む 関連リソース AWS Microsoft Workloads コンピテンシーパートナー AWS Microsoft Workloads ブログ AWS Transform for .NET ドキュメント AWS 上の Microsoft ワークロード つながりを保つ ソーシャルメディアで #reInvent と @AWSreInvent の会話に参加し、ほかの参加者とつながりましょう。 注: セッションのスケジュールと空き状況は変更される場合があります。最新情報は AWS re:Invent セッションカタログ でご確認ください。 著者について Yogi Barot Yogi Barot は、AWS で移行とモダナイゼーションの技術フィールドコミュニティを率いるワールドワイドのテクニカルリーダーです。その役割の一環として、技術的なイネーブルメントのコミュニティを牽引し、お客様の AWS への移行とモダナイズを支援しています。Yogi は Microsoft のさまざまなテクノロジーに 28 年間携わってきた経験を持ち、SQL Server をはじめとするデータベース技術を専門としています。AWS に関する深い知識と、AWS 上で Microsoft ワークロードを実行する専門性を備えています。 Hrushikesh Shah Hrushikesh Shah は、AWS のシニアソリューションアーキテクトで、移行とモダナイゼーションの戦略を専門としています。組織が AWS へ移行しモダナイズする計画の立案を支援するとともに、AWS のサービスチームと協力して新しい機能の構築にも取り組んでいます。ソリューションアーキテクトになる前は、ソフトウェア開発者として働き、AWS の講座も担当していました。 翻訳はソリューションアーキテクトの平良允俊が担当しました。

2026 年 10 月 26 日、アマゾン ウェブ サービス ジャパン麻布台オフィスにて、招待制セキュリティセミナー「ランサムウェアに備える『防御』『復旧』『説明責任』— AI エージェント時代に見直す対策と次の一歩」を開催しました。当日は 84 名のお客様にご参加いただきました。 本セミナーは、2026 年 5 月に開催した「 ランサムウェアに備える『防御』と『復旧』 」の続編です。前回の相談会とアンケートで多くいただいたのが、「万一のとき、経営や顧客、監督官庁に何を根拠に説明すればよいのか」というご質問でした。この声を受けて、今回は 「説明責任」を 3 つ目の軸として加えました 。3 つの軸は互いにつながっています。たとえば、ログから侵入の時期がわかれば、どの時点のバックアップに戻せばよいかを早く絞り込めます。 アジェンダ セッション 軸 スピーカー 基調講演「ランサムウェア対策の『変わること、変わらないこと』」 全体 中島 智広（シニアセキュリティソリューションアーキテクト） AWS セッション①「防御・検知から始めるランサムウェア対策」 防御・検知 須田 聡（シニアセキュリティソリューションアーキテクト） パートナーセッション①「ゼロトラストで断つ、ランサムウェアの侵入と拡散」 防御・検知 Zscaler 井上 智也 様 パートナーセッション②「最新のサイバーリスクに対抗するためのエンドポイントセキュリティ」 防御・検知 CrowdStrike 菅村 優哉 様 パートナーセッション③「日々の運用から見直すランサムへの備え」 説明責任 Cyber Security Cloud 西川 彰 様 パートナーセッション④「今何が起きているのか？ Splunk を活用した CloudSecurityOps」 説明責任 Splunk 吉田 裕貴 様 AWS セッション②「突破されたときの備え AWS Backup で実現する復旧力」 復旧 焼尾 徹（シニアストレージソリューションアーキテクト） パートナーセッション⑤「対ランサムウェア戦略 最後の砦はバックアップ」 復旧 Clumio 亀田 治伸 様 基調講演：変わらない原則と、見直したい「先送りしてきた対策」 シニアセキュリティソリューションアーキテクトの中島 智広より、ランサムウェアをめぐって「変わること」と「変わらないこと」を整理しました。 攻撃側も防御側も AI を使う時代になっても、変わらないのはセキュリティの原則、つまりこうすれば守れるという考え方です。これまで取り組んできた対策は、設計どおりに動きます。一方で「変わったこと」は、過去にシステムの重要度や運用負荷、コストを理由に「ここまでは後回しでいい」と判断してきた対策の位置づけです。AI によって脆弱性が短時間で大量に見つかるようになり、ソースコードが公開されている OSS では、修正前後の差分から攻撃コードまで作れてしまいます。その結果、かつて合理的だった水準をもう一段上げないと十分とは言えなくなりました。 MITRE ATT&CK の 14 のフェーズのうち、ランサムウェア固有のデータ暗号化は最後の段階にあたります。裏を返せば、暗号化に至るまでに止められる機会が 13 段階あるということです。だからこそ前段で「クイックにできること」が重要で、この整理が続くセッションの土台になりました。 復旧については、ディザスタリカバリ（DR）とサイバーリカバリの違いが改めて論点になりました。東京が被災したら大阪に切り替えるという DR は、既存の環境を信頼できることが前提です。侵害からの復旧では既存環境を信用できないため、新しい環境にクリーンに作り直す手順やプレイブックを用意しておく必要があります。 防御・検知：暗号化に至る前の段階で止める AWS：GuardDuty と Security Hub の有効化、組織からの離脱禁止から始める 続いて、シニアセキュリティソリューションアーキテクトの須田 聡が「防御・検知」の軸を担当しました。扱うのは最終段階より前の 13 フェーズ、つまりマルウェア全般に共通する対策です。 最もお伝えしたかったのは、「今すぐやれることがある」ということです。 Amazon GuardDuty と AWS Security Hub CSPM は、既存のシステムに影響を与えずに後から有効化できます。独自ルールを作る前に、重要度の高い検知から確実に対応する。体制が整ってからカバレッジを広げる。この順番です。検知結果の調査を AI で自動化する GuardDuty の AI-powered investigations も紹介しました。 組織単位でまず入れてほしい設定として挙がったのが、 AWS Organizations からのアカウント離脱の禁止 です。特権を取られたアカウントを組織から切り離して別の組織に移す手口があり、離脱を組織単位で禁止しておけばこれを防げます。最近はコンソールで新しく作成した組織には既定で入るようになったので、既存の組織は一度確認してみてください。あわせて、IAM ユーザーを使わず IAM Identity Center に寄せること、ルートユーザーの一元管理も推奨されました。 アプリケーションの領域では、10 月に一般提供を開始した AWS Continuum for code vulnerabilities を紹介しました。自社コードの脆弱性の検証から修正の提案までを AI エージェントが担います。 Zscaler：攻撃対象を見つけさせず、横移動させない Zscaler 様のテーマはゼロトラストによる侵入・拡散対策です。攻撃者が弱点を探す工程に AI が使われるようになった、という現場の観察が共有されました。ファイアウォールと VPN で 30 年守ってきた境界型の構造的な課題は、VPN がグローバル IP として公開されていることです。公開されている限り攻撃対象として見つかります。そして一度認証を通れば内部のどこへでも行ける構成では、侵入後の横移動を止める手立てがありません。 対策の要点は 2 つ、公開された部分を見つからないようにすること、そして侵入後に横移動させないことです。アプリケーションをインターネットから隠蔽し、毎回検証してアプリケーション単位で接続させるゼロトラストに加え、即効性のある施策としておとりを配置するデセプションが紹介されました。AWS をデータセンター裏に専用線でつなぐ構成をやめ、本来のパブリッククラウドとしてインターネット経由で使う。そうすれば、全トラフィックがデータセンターに集中するボトルネックも解消します。 CrowdStrike：振る舞いで見る EDR と、人の目による脅威ハンティング CrowdStrike 様はエンドポイントと AWS 上のワークロードの保護を扱いました。EDR などの対策の導入が進んでいるのに被害が減らない要因として示されたのが、マルウェアを使わず OS 標準のツールを悪用する「マルウェアフリー攻撃」の主流化です。同社の観測ではその比率が 2020 年の 51% から 82% に上がっています。悪意あるファイルを見つける対策だけでは足りず、どのプロセスがどの順番で動いたかという振る舞いを見る検知が必要になる、という整理です。 保護は NGAV、EDR、そして人の目で見る脅威ハンティング（Falcon OverWatch）の「3 つの壁」で構成され、導入後の運用は調査から対処まで MDR サービスの Falcon Complete が担います。GuardDuty が VPC やフローログを見るのに対し、エージェントは内部のプロセス起動やファイル実行を即時に見て止められるという、AWS サービスとの使い分けの整理も示されました。 説明責任：侵入後に何が起きたかを、時間内に説明できるようにする 今回新たに置いた「説明責任」の軸は、2 社に分担していただきました。 Cyber Security Cloud 様が「正規の権限を奪われてもデータを消させず、戻せて、異変に気づける状態を普段の設定でつくる」側を、 Splunk 様が「ログを横断して使い、経路を再構成する」側です。 Cyber Security Cloud：消させない・戻せる・気づくの 3 層で備える Cyber Security Cloud 様は、AWS 環境を実際に構築して攻撃を仕掛け、どんな痕跡が残るかを検証している脅威インテリジェンスグループの立場から登壇されました。あえて「ランサムウェア」と言わず「ランサム」と呼ぶ理由は、クラウド環境の削除や暗号化はマルウェアなしで起きているからです。脅威の主体は人であり、使われるのは AWS の脆弱性ではなく正規の API です。逆に言えば、守る仕組みはすでに用意されていて、それを適切に使えるかどうかで差がつきます。 同社が対応してきたインシデントの多くは、壊せる権限を持ちながらデータの窃取で止まっています。ただし、同じ権限があれば削除まで進めます。窃取で止まっている今のうちに、削除された場合の備えを入れておいてほしい、という問題提起でした。 聴講者に投げかけられた 3 つの問いは、「復旧できますか」「保護していますか」「権限設定は適切ですか」。これに対応する備えが「消させない・戻せる・気づく」の 3 層です。 「消させない」では S3 Object Lock と RDS の削除保護 を入れたうえで、それらを外す操作を SCP で組織全体で拒否すること、「戻せる」では AWS Backup の Vault Lock と別アカウント・別リージョンへのコピーが挙がりました。説明責任の軸で特に重要なのが「気づく」です。 AWS CloudTrail は有効でも、S3 の データイベント や RDS の監査ログまでは取得していない企業が多いのではないか、という指摘がありました。大量削除や暗号化の兆候に早く気づくための土台なので、取得設定を確かめておきたいところです。攻撃者は削除の前に大量の読み取りを行うため、GuardDuty の S3 Protection で窃取の段階に気づける可能性も示されました。 Splunk：ログを横断して分析し、侵入の経路を組み立てる Splunk 様のテーマは「何かあったときの説明責任をどう果たすか」です。GuardDuty で Critical の Finding が上がり、マルウェア感染が疑われるとき、隔離や証跡保全といった対処は当然重要です。しかし「そもそもなぜこうなったのか」は対処とは別の軸で追わなければなりません。単一の Finding からは「どこから感染したのか」は分かりません。入口を特定して塞ぐことが、再発防止にも説明にもつながります。 ここで必要になるのがログの横断分析です。不審なリクエスト、不審なドメインへの問い合わせ、不審な宛先への通信は、1 つずつ見ても判断できませんが、横断的に見れば C2 サーバーとの通信という像が浮かび上がります。また基調講演の「13 段階」を引いて、途中で止まった攻撃の記録も次の備えの手がかりになる、という指摘がありました。 どのログを SIEM に入れるかは、AWS でよく言う Working Backwards の発想で、最終的にやりたいことから逆算して決めます。さらに SIEM（Splunk Enterprise Security）と SOAR を組み合わせれば、検知から調査、端末の隔離までを自動化し、SOC や CSIRT の運用を省力化できる、という紹介もありました。 復旧：消されないバックアップを持ち、戻せることを確かめておく AWS：Vault Lock、リストアテスト、IaC の 3 ステップ 「復旧」の軸は、シニアストレージソリューションアーキテクトの焼尾 徹が AWS Backup を中心に話しました。冒頭では、起きることを前提に「そのとき誰が何をするか」を社内で決めておき、防災訓練のように一度試しておきましょう、と呼びかけました。 現場に共通する 3 つの疑問が示されました。バックアップの保持期間は何日にすべきか、確実にイミュータブルにするにはどうするか、そして「いつの時点のデータなら安心して戻せるのか」。3 つ目については、攻撃者が侵入後すぐには動かず潜伏するため、ログのフォレンジックと組み合わせると「侵害前」の時点を判断しやすくなります。ここが、今回「説明責任」を復旧の前に置いた構成の意図でもあります。 設計指針として 3-2-1-1-0 ルールが示され、今日から取り組める 3 ステップにまとめられました。 1 つ目は AWS Backup の Vault Lock の有効化 です。コンプライアンスモードにしておけば、強い権限を奪われても保持期間中は誰も削除できません。 2 つ目は リストアテスト の実行です。データベースの件数照合のような独自の確認を組み込むこともできます。Amazon EC2・EBS・S3 は GuardDuty Malware Protection for AWS Backup でリストアせずにリカバリポイントがクリーンかどうかを確認できます。 3 つ目は IaC です。データに加えてアプリケーションも立ち上げられるよう、環境定義を AWS CloudFormation や Terraform で持ち、定義ファイルも Object Lock で守ります。小さな環境、少ないリソースからで構わない、というのが登壇者の勧めです。 Clumio：クラウドではまず「1-1-0」とリストア訓練から Clumio 様のテーマは、AWS 上のバックアップを確実に戻せる状態にしておくことです。亀田様は、バックアップからすぐ戻せる体制は、いまや平時に整えておくべき標準的な備えになりつつある、との見方を示しました。 復旧の現場を見てきた立場からの助言は、訓練していない組織が当日いきなりバックアップを戻すのは難しい、ということでした。推奨は、今週中にでもリストア訓練を実施すること。確認するのは「バックアップが取れているか」と「運用チームが戻せるか」の 2 点です。クラウドではまず 3-2-1-1-0 のうち「1-1-0」、つまりイミュータブル保存、管理者権限を切り離した別アカウントへのエアギャップ、戻せることの検証をしっかりやることがスタート地点です。 ランサムウェアの復旧で RTO が伸びる理由として、「いつに戻すか」を決められない問題が挙がりました。5 時間かけて戻してマルウェアを確認し、残っていれば 2 日前へ、それが無事なら 1 日前へ、とリストアを繰り返すことになります。Clumio は S3 をオブジェクト単位、EBS をファイル単位で任意の時点から取り出せるため、CloudTrail や GuardDuty のログで「どのオブジェクトが暴れたか」が分かっていれば、中身を確かめて混入時点を絞り込み、そのうえで一気に戻せます。ここでも、ログがあるかどうかが復旧時間を左右します。 おわりに：3 つの軸それぞれに「今日できること」がある 本記事では、2026 年 10 月 26 日に開催したセミナーをレポートしました。参加いただいたお客様からは「セキュリティ担当でなくても理解しやすかった。次回は担当以外のメンバーも誘って参加したい」という声もいただき、経営層や事業部門と一緒に聞いていただく価値があるテーマだと感じています。 参加者アンケートで「まず点検したいこと」の上位に挙がったのは、リストア手順と復旧検証、バックアップの保護・分離、GuardDuty と Security Hub の組織展開、侵害時に何が起きたかを説明できるログの保全・分析でした。多くの参加者が「復旧」から手を付けると答えたのは、当日の内容がそのまま次の一手になった結果だと受け止めています。 最後に、軸ごとにまず着手したいことと、AWS・パートナーそれぞれの選択肢をまとめます。 防御・検知: まず GuardDuty と Security Hub CSPM の有効化、Organizations からの離脱禁止。既存システムに影響なく今日できます。侵入経路や端末の対策を強めるなら、Zscaler のゼロトラスト、CrowdStrike の EDR と脅威ハンティングが選択肢になります 説明責任: まず CloudTrail のデータイベント（S3 のオブジェクト操作）を取っているか確認する。有効にしておけば、万一のときに「何が起きたか」を説明する根拠になります。データを消させず戻せる設定と運用は Cyber Security Cloud、ログの横断分析は Splunk が選択肢になります。 復旧: まず AWS Backup の Vault Lock を有効化し、リストアテストを 1 回実行して現状の復旧力を把握する。オブジェクト単位や任意の時点からの取り出しが必要なら、Clumio が選択肢になります 基調講演の言葉を借りれば、いま求められているのは「これまで合理的だった水準をもう一段上げること」です。セキュリティの責任者と実務担当者で、3 つの軸のうち自社でいちばん薄いところと、最初の一手を決めてみてください。ご相談は担当営業、ソリューションアーキテクト、または各パートナー様までお寄せください。ご参加いただいた皆様、ご登壇いただいたパートナー各社様、ありがとうございました。

本記事は 2026 年 10 月 22 日 に公開された「 Infrastructure Migrations: Your complete AWS re:Invent 2026 guide 」を翻訳したものです。 かつてオンプレミスインフラからの移行では、サーバーを 1 台移す前に、調査用のスプレッドシートや依存関係マッピングのワークショップ、手作業による移行ウェーブ計画に何カ月も費やす必要がありました。11 月 30 日から 12 月 4 日までラスベガスで開催される AWS re:Invent 2026 では、エージェント型 AI がこの状況をどのように変えているかを確認できます。 AWS Transform は専用の AI エージェントで、ディスカバリーやウェーブ計画からネットワーク変換、カットオーバーまでの移行ライフサイクル全体を自動化します。VMware やベアメタル、ハイブリッド環境のワークロードが対象です。同じエージェント型のアプローチは移行完了後も機能し続け、ポートフォリオ全体のモダナイゼーションと技術的負債の削減を支援します。 AWS への移行を計画中、またはすでに実行中の方にとって特に重要なセッションを厳選しました。経営層によるパネルディスカッションやお客様事例から、実際に自分で移行を体験できるハンズオンワークショップまで幅広く取り上げています。データセンター撤退のビジネスケースを作成中の方、ワークロードごとに移行パスを選んでいる方、すでに進行中のプログラムを拡大している方など、どのフェーズにいても役立つセッションが見つかります。また、AWS の規模を活かしながらも、チームがすでに使い慣れたツールやスキルで VMware を使い続けたいというお客様向けに、VMware Cloud Foundation をそのまま AWS 上で実行できる Amazon Elastic VMware Service (Amazon EVS) についても取り上げます。さらに、ワークロードを AWS に移行した後、モダナイゼーションへとどう進めるかについても紹介します。 Microsoft ワークロードのセッションをお探しですか? Windows Server、SQL Server、.NET に関するセッションは、関連記事「 Microsoft workloads on AWS: Your complete re:Invent 2026 guide 」で取り上げています。 移行戦略とお客様事例 移行で最も難しいのは、最初に何を移行するかを決めて経営層の合意を得ることと、移行を進めながら事業を止めずに運営することです。ここで紹介するセッションでは、実際に移行を成し遂げた企業の IT リーダーたちが、成功につながった計画段階での意思決定や移行の順序付けと得られた教訓を共有します。 How IT leaders actually pulled off their cloud migrations | MAM201 | レベル: 200 形式: ブレイクアウトセッション 日時 & 会場: 11 月 30 日(月)午前 8:30 (PST) | Caesars Palace Verisk Analytics、CI Financial、CoupangPay といったグローバル企業の移行リーダーが、VMware やその他の老朽化したインフラからのワークロードを含め、オンプレミス環境を AWS に移行した経験を共有します。実際の計画段階での意思決定、実行戦略、そこから得た教訓、そして次に目指すモダナイゼーションの方向性を聞くことができます。 Building migration readiness when the timeline is tight | MAM208 | レベル: 200 形式: ブレイクアウトセッション 日時 & 会場: 12 月 1 日(火)午後 4:00 (PST) | Caesars Palace ライセンス変更やコンプライアンス要件、ハードウェアコストの上昇により、移行のスケジュールが急に短縮されることがあります。環境を評価し、チームの能力を高め、各ワークロードに適切な移行パスを選ぶ方法を学びます。数百のアプリケーションを実際のプレッシャーの中で移行し、重大な障害を 1 件も起こさなかった Vanguard の事例も紹介します。 Booking.com’s playbook for cloud transformation at global scale | MAM203 | レベル: 200 形式: ブレイクアウトセッション 日時 & 会場: 11 月 30 日(月)午前 8:30 (PST) | Caesars Palace Booking.com は 43 の言語で 2,800 万件以上の掲載情報を提供し、数百万人の旅行者をつないでいます。そのクラウド変革もこの規模に見合うものでなければなりませんでした。組織の壁をどう取り払い、スケジュールをどう短縮し、AI を根本からどう組み込んだかを聞き、クラウド変革を持続的な競争優位につなげるためのプレイブックを手に入れましょう。 Fanatics path to AWS: 5 data centers, 1,800 servers, 48% savings | MAM320 | レベル: 300 形式: ブレイクアウトセッション 日時 & 会場: 12 月 2 日(水)午後 2:30 (PST) | Caesars Palace Fanatics Commerce は 5 つのデータセンターにわたる 1,800 台のサーバーを移行し、インフラコストを 48% 削減できると見込んでいます。同社のチームが、体系化された OLA から MAP への流れ、ドキュメント化されていなかった接続関係を洗い出した AI 支援の依存関係マッピング手法、そしてスケールする前にエンジニアリング側の信頼を得た段階的な AWS Transform 戦略について共有します。 Multicloud-to-AWS transformation: HealthEdge migrating 8,700 servers | MAM226 | レベル: 200 形式: ブレイクアウトセッション 日時 & 会場: 12 月 1 日(火)午後 1:30 (PST) | Caesars Palace HealthEdge は、Azure、GCP、4 つのデータセンターにまたがる 8,700 台のサーバー、1,600 のデータベース、数千のクラウドサービスを AWS Transform を使って AWS に統合しています。130 の健康保険プランを毎日サポートしながら進める 2 年間のロードマップをどう実行し、セキュリティ水準をどう高め、事業を中断させずに社内の AWS 専門知識をどう構築しているかを聞くことができます。 評価と計画: 移行のビジネスケースを構築する 成功する移行はどれも現在運用している環境の正確な把握から始まります。ここで紹介するセッションでは、AWS Transform のエージェント型アセスメント機能を活用したり、AWS のスペシャリストや AWS パートナーと連携したりしながら、ディスカバリーデータを適切なサイズの推奨事項、コストシナリオ、関係者の承認を得られるビジネスケースに落とし込む方法を紹介します。 On-premises to AWS readiness: foundational decisions before your migration | MAM210 | レベル: 200 形式: チョークトーク 日時 & 会場: 11 月 30 日(月)午前 9:00 (PST) | Caesars Palace 再演: 12 月 1 日(火)正午 (PST) | Caesars Palace 移行が成功するかどうかは、最初のワークロードを移す前の意思決定によって決まります。ライセンス、運用モデル、アーキテクチャ、組織としての準備状況に関する選択が結果にどう影響するかを確認し、依存関係を評価し、関係者の合意を取り、よくある失敗を避ける計画を立てる方法を学びます。 How to assess your environment to migrate & modernize with confidence | MAM211 | レベル: 200 形式: チョークトーク 日時 & 会場: 11 月 30 日(月)午前 10:30 (PST) | Caesars Palace 再演: 12 月 1 日(火)午前 11:30 (PST) | Caesars Palace 環境内で何が稼働しているかを明確に把握できていないと、チームは古い前提を引き継ぎ、技術的負債を抱え込んでしまいます。AWS Transform のエージェント型アセスメントを実際に試す方法、または AWS のスペシャリストやパートナーと協力する方法を学び、的確な意思決定を下し、環境を最適化し、冗長なライセンスを排除しましょう。 Build a data-driven migration plan with AWS Transform | MAM306 | レベル: 300 形式: ビルダーズセッション 日時 & 会場: 11 月 30 日(月)午前 10:00 (PST) | Caesars Palace 再演: 12 月 3 日(木)午前 11:30 (PST) | Caesars Palace データセンター撤退を計画するには、説得力のあるデータ、現実的なコスト見積もり、そして財務的に理にかなった提案が必要です。AWS Transform のエージェント型 AI と Discovery Agent のデータを使って環境を評価し、コスト見積もりを生成し、ビジネスケースを構築します。ディスカバリーから財務モデリングまでの一連のワークフローを通して進めます。 プロダクトディープダイブとハンズオンワークショップ: AWS Transform 移行のための AWS Transform の動きを実際に見て自分でも使ってみましょう。ここで紹介するセッションでは移行のライフサイクル全体を取り上げます。対象は AI 主導のディスカバリーとウェーブ計画、ランディングゾーンとネットワークの自動化、Amazon EC2 へのサーバーのリホスト、そしてコンテナ化とストレージ移行です。ワークショップとビルダーズセッションはハンズオン形式のため、ノート PC をご持参ください。 5 steps to faster data center exits with AWS Transform | MAM327 | レベル: 300 形式: ブレイクアウトセッション 日時 & 会場: 12 月 1 日(火)午前 11:30 (PST) | Caesars Palace AWS Transform はエージェント型 AI を使い、データセンター撤退の全体タイムラインを短縮します。何千台ものサーバーを適切なサイズに調整し、数日でビジネスケースを構築する AI 主導のディスカバリーから、自動化されたウェーブ計画、ランディングゾーンのデプロイ、ネットワーク変換、そして Amazon EC2 への大規模なリホストまでを含みます。あるお客様の計画から撤退完了までの実際のタイムラインをたどります。 What’s new with AWS Transform for migrations | MAM225 | レベル: 200 形式: ブレイクアウトセッション 日時 & 会場: 12 月 2 日(水)午後 2:30 (PST) | MGM Grand 移行のための AWS Transform の最新機能をいち早く確認できます。エージェント型 AI が移行ライフサイクル全体で機能することで、これまでチームの足を引っ張っていた作業が自動化されます。初めての移行を計画している方も、数百のワークロードにわたってスケールさせている方も、最新機能を実践に活かす方法を持ち帰ることができます。 Large-scale VMware exit: engineering a 10,000+ server migration wave engine | MAM415 | レベル: 400 形式: チョークトーク 日時 & 会場: 11 月 30 日(月)午後 2:30 (PST) | Caesars Palace 体系化された VMware 撤退は、アセスメント、動員、移行、モダナイゼーションの各フェーズにわたります。AWS Transform が各フェーズでどのように成果を生み出すか、TCO 削減を数値化するポートフォリオアセスメント、稼働率を守るウェーブ計画、自動化されたカットオーバーを、18 カ月かかっていたタイムラインを 10 カ月以下に短縮した実例とともに紹介します。 Drive multi-server migrations from discovery to cutover with AWS Transform | MAM308 | レベル: 300 形式: ワークショップ 日時 & 会場: 12 月 2 日(水)午前 8:00 (PST) | Caesars Palace 再演: 12 月 3 日(木)午後 12:30 (PST) | MGM Grand 多くのチームは、ワークロードを移行するよりも、移行の引き渡し作業の計画に多くの時間を費やしています。このワークショップでは、AWS Transform のエージェント型 AI がライフサイクル全体をどのように調整するかを体験します。的確なディスカバリー、AI 主導のウェーブ計画、自動化されたネットワーク変換、サーバーリホストを、専門化されたエージェントが連携しながら、あなた自身がコントロールを保ったまま進めます。 Best path forward: Rehost & replatform to containers with AWS Transform | MAM315 | レベル: 300 形式: ワークショップ 日時 & 会場: 11 月 30 日(月)午後 3:00 (PST) | Caesars Palace 再演: 12 月 1 日(火)午後 12:30 (PST) | MGM Grand どのアプリケーションをリホストし、どれをコンテナ化すべきかの判断で、チームは立ち止まってしまいがちです。AWS Transform を使ってポートフォリオ全体の複合的な移行を計画し、コンテナ化とリホストを組み合わせた移行を Amazon ECS または EKS に実行します。自分の環境にそのまま適用できる、現実的なマルチウェーブ計画を持ち帰ることができます。 Guide to deploying landing zones & modernized networks in hours | MAM331 | レベル: 300 形式: チョークトーク 日時 & 会場: 11 月 30 日(月)正午 (PST) | Caesars Palace 再演: 12 月 1 日(火)午後 1:30 (PST) | Wynn/Encore AWS Transform のエージェント型 AI が、ランディングゾーンの構築とネットワーク変換を数週間から数時間に短縮する様子を確認できます。移行インベントリから、検証済みのランディングゾーンとモダナイズされたネットワークまでを対象とし、Control Tower を通じて本番運用に対応したアカウント構成がデプロイされ、ファイアウォール設定が最適化された VPC、サブネット、セキュリティグループへと変換される様子を見ることができます。 Automate your landing zone and network migration with AWS Transform | MAM408 | レベル: 400 形式: ワークショップ 日時 & 会場: 12 月 2 日(水)午後 12:30 (PST) | Caesars Palace AWS Transform はランディングゾーンの設計とネットワーク変換を自動化します。ランディングゾーンエージェントが AWS Control Tower、OU、SCP、ワークロードアカウントをコードとしてのインフラ (Infrastructure as Code) としてデプロイし、続いてネットワークエージェントが VMware のネットワーキングやファイアウォール設定を CDK または Terraform で VPC、サブネット、セキュリティグループ、トランジットゲートウェイへと変換・デプロイする様子を確認できます。 Migrate and modernize infrastructure from your IDE with agentic AI | MAM313 | レベル: 300 形式: コードトーク 日時 & 会場: 11 月 30 日(月)午前 8:30 (PST) | MGM Grand 再演: 12 月 2 日(水)午前 10:00 (PST) | Caesars Palace IDE から移行のワークフロー全体を進めます。Kiro と AWS Transform がどのように連携するかを確認できます。マルチアカウントのランディングゾーンをコードとしてのインフラとして生成し、VMware の構成エクスポートをネットワークエージェントに渡して Terraform または CDK のネットワークトポロジーを作成し、最後にコンテナ化エージェントをリポジトリに向けて Amazon EKS にデプロイします。 Migrate on-premises storage to AWS with agentic AI | MAM312 | レベル: 300 形式: ライトニングトーク 日時 & 会場: 12 月 2 日(水)午後 1:30 (PST) | Wynn/Encore AWS Transform のエージェント型 AI は、自動化されたアセスメント、ビジネスケースの生成、ウェーブ計画、実行まで、ストレージ移行のライフサイクル全体を処理し、数週間かかっていた作業を数時間に短縮します。VMware 環境、エンタープライズデータベース、関連データからストレージを移行する方法を確認し、最初の Transform プロジェクトを始める方法を持ち帰ることができます。 The EBA cloud party: compete to build agentic migration solutions | MAM307 | レベル: 300 形式: ワークショップ 日時 & 会場: 12 月 3 日(木)午前 8:00 (PST) | Caesars Palace このゲーム形式の Experience-Based Acceleration (EBA) ワークショップでは、職能を超えたチームがリアルタイムで競い合い、移行ソリューションを設計し、大規模に自動化するエージェント型 AI ワークフローを構築し、AI 駆動のアプリケーションを AWS 上にデプロイします。実戦で磨かれたアーキテクチャ、自動化パターン、そしてチームがすぐに取り入れられるクラウドに強いマインドセットを持ち帰ることができます。 プロダクトディープダイブ: Amazon Elastic VMware Service (Amazon EVS) VMware の契約を更新した後にハードウェアの更改サイクルやキャパシティの限界、インフラコストの上昇に直面している場合は、Amazon EVS を使えばアーキテクチャを再設計せずに前に進めます。Amazon EVS では Amazon VPC 内の EC2 ベアメタルインスタンス上で VMware Cloud Foundation を実行できます。そのため、使い慣れたツールやプロセスをチームがそのまま使い続けながら、支出を設備投資から伸縮性のあるオンデマンドのインフラへ切り替えていけます。ここで紹介するセッションでは、AWS 上で VMware ワークロードを実行するためのデプロイやアーキテクチャ、ストレージのパターンを取り上げます。 Amazon EVS: How to deploy & operate your VMware stack in the cloud | MAM325 | レベル: 300 形式: ブレイクアウトセッション 日時 & 会場: 12 月 3 日(木)正午 (PST) | Caesars Palace Amazon EVS では、Amazon VPC 内の EC2 ベアメタルインスタンス上で最新の VMware Cloud Foundation ソフトウェアを実行できます。ネットワーキングやストレージからディザスタリカバリまで、VMware スタックの管理権限を保持できます。デプロイのワークフローと統合パターンを確認し、EVS で移行を加速させたお客様の事例を聞くことができます。 Architect and optimize your VMware environment on Amazon EVS | MAM330 | レベル: 300 形式: チョークトーク 日時 & 会場: 11 月 30 日(月)午後 2:30 (PST) | Caesars Palace Amazon EVS 上に構築する堅牢な VMware 環境を支えるアーキテクチャ上の意思決定を詳しく掘り下げます。VCF 9 のサポート、Windows Server のライセンス込みの特典、パフォーマンスとコストを両立させたネットワーキングとストレージの設計、そしてバックアップ、パッチ適用、DR の運用パターンまでを扱います。EVS で本番ワークロードを運用しているお客様の事例も紹介します。 Modernizing VMware workloads with Amazon FSx for NetApp ONTAP | STG363 | レベル: 300 形式: チョークトーク 日時 & 会場: 11 月 30 日(月)午前 8:30 (PST) | MGM Grand Amazon FSx for NetApp ONTAP は、マルチプロトコル対応、エンタープライズレベルのデータ管理、そして VMware 管理者がすでに使い慣れている ONTAP との互換性を備えた、VMware 移行向けのストレージ基盤です。実際の移行パターン、重複排除と圧縮によるコスト最適化、Multi-AZ とゼロ RPO による高可用性について紹介します。 プロダクトディープダイブ: AWS Outposts への移行 データ保存場所やデジタルソブリンティ、低レイテンシーといった要件から、オンプレミスに残す必要があるワークロードもあります。それでも、クラウドの運用モデルは取り入れたいところです。AWS Outposts を使えば AWS のインフラとサービスを自社のデータセンターで利用できます。ここで紹介するセッションでは Outposts への移行とモダナイゼーションの方法を取り上げ、新しい第 2 世代ハードウェアについても紹介します。 VMware migration to Amazon EC2 and AWS Outposts with AWS Transform | HMC308 | レベル: 300 形式: ワークショップ 日時 & 会場: 12 月 1 日(火)午後 12:30 (PST) | MGM Grand AWS Transform MGN を使って、Amazon EC2 と AWS Outposts への VMware 移行をエンドツーエンドで実行します。AI 主導のディスカバリー、依存関係マッピング、ウェーブ計画、ネットワーク変換、そしてオーケストレーションされた実行までを体験します。Trianz の Concierto プラットフォームが AWS Transform と統合し、AWS Outposts への移行をどのように効率化しているかも紹介します。 Real-world migrations: Lessons learned migrating to AWS Outposts | HMC304 | レベル: 300 形式: ブレイクアウトセッション 日時 & 会場: 11 月 30 日(月)午前 10:00 (PST) | MGM Grand データ保存場所やソブリンティの要件を持つ組織向けに、業界や戦略を超えて Outposts へお客様を移行してきた経験から得た教訓をまとめます。成果につながったプロセス、避けるべき失敗、適切なアプローチの選び方を紹介します。第 1 世代から第 2 世代ハードウェアへの移行についても取り上げます。 Migrate and modernize workloads with AWS Outposts | HMC319 | レベル: 300 形式: チョークトーク 日時 & 会場: 11 月 30 日(月)午後 1:30 (PST) | Caesars Palace AWS Outposts は、従来の仮想化プラットフォームから移行するワークロード向けに、クラウドの運用モデルをオンプレミスにもたらします。現在は第 2 世代のシングルラックおよびマルチラック構成として提供され、新しいインスタンスタイプ、Amazon EBS ストレージ、最大 40% のコストパフォーマンス向上、そして強化されたネットワーキングを備えています。移行とモダナイゼーションの戦略に加え、第 1 世代のお客様がどのようにアップグレードできるかも取り上げます。 AWS wherever you need it: From the cloud to the edge | HMC202 | レベル: 200 形式: ブレイクアウトセッション 日時 & 会場: 12 月 2 日(水)午後 3:00 (PST) | Caesars Palace 低レイテンシー、ローカルでの処理、データ保存場所といった理由から、オンプレミスやエッジに置き続けなければならないワークロードもあります。AWS Local Zones、Outposts、Dedicated Local Zones、AI Factories は、AWS のサービスをそうした場所まで拡張します。オンプレミスへの依存関係を持つ仮想化、コンテナ化、ベアメタルのワークロードの移行とモダナイゼーションをどう加速させるかを学びます。 移行からモダナイゼーションへ 移行は最初の一歩であり、終着点ではありません。ワークロードが AWS 上で稼働を始めたら、同じエージェント型のアプローチを使って、ポートフォリオ全体の技術的負債を減らし続けることができます。 What to do next after your cloud migration | MAM326 | レベル: 300 形式: ブレイクアウトセッション 日時 & 会場: 12 月 3 日(木)午後 2:30 (PST) | Caesars Palace リホストでワークロードは AWS に到達しますが、このセッションではカットオーバー後の最初の 90 日間を取り上げます。環境を安定させ、実際の利用率データに基づいたオブザーバビリティを構築し、自動スケーリングとライトサイジングを適用して ROI を加速させ、ワークロードがモダナイズする準備ができているのか、それともそのままにしておくべきかを見極める方法を紹介します。 Turn your cloud migration into a security transformation | MAM407 | レベル: 400 形式: ワークショップ 日時 & 会場: 11 月 30 日(月)午後 3:30 (PST) | MGM Grand 再演: 12 月 2 日(水)午前 8:30 (PST) | Caesars Palace 移行を活かして、セキュリティ体制を変革します。AWS に移行したばかりのワークロードをサンドボックスアカウントで保護し、ランタイムの脅威には Amazon GuardDuty、脆弱性には Amazon Inspector、検出結果の関連付けには AWS Security Hub を使い、その後自動化された修復パイプラインを構築します。繰り返し使える Day 1 セキュリティプレイブックを持ち帰ることができます。ノート PC が必要です。 From migration to continuous modernization: reduce tech debt at scale | MAM344 | レベル: 300 形式: ブレイクアウトセッション 日時 & 会場: 12 月 3 日(木)午前 9:00 (PST) | Caesars Palace エージェント型 AI がモダナイゼーションを単発のプロジェクトから常時稼働する取り組みへとどう変え、パイプラインを CI/CD から CI/CD/CM (継続的モダナイゼーション) へと進化させるかを紹介します。プロダクトリーダーの Neha Goswami による最新の取り組みとともに、コードベースを常に最新かつ AI 対応の状態に保ちながら、モダナイゼーションのタイムラインを数年から数カ月に短縮したチームの事例を聞くことができます。 AWS re:Invent 2026 に向けて準備する まもなく開催される AWS re:Invent 2026 には、AWS の専門家や、ワークロードの AWS への移行に成功したお客様の知見が詰まっています。準備のための決定版チェックリストは次のとおりです。 AWS re:Invent 2026 に登録する re:Invent イベントカタログ でワークショップ、チョークトーク、ビルダーズセッション、コードトークの席を確保する (このガイドで紹介したブレイクアウトセッションとライトニングトークは事前予約不要の先着順です) すべての Migration & Modernization (MAM) トラックのセッション を確認し、ご自身の計画に合うものをさらに探す ソーシャルメディアで #reInvent2026 のハッシュタグを使って参加する AWS Events モバイルアプリ をダウンロードしてスケジュールを組む さらに詳しく: インフラ移行に関するリソース 以下のリソースも参考にしてください。 AWS Transform プロダクトページ AWS Transform のドキュメント AWS Optimization and Licensing Assessment Amazon Elastic VMware Service (Amazon EVS) AWS Migration Acceleration Program AWS for VMware Experience based acceleration 最新情報を受け取る @AWSreInvent をフォローして、お使いのソーシャルメディアで #reInvent ハッシュタグをチェックしてください。イベント前から他の参加者とつながる絶好の方法です。 ヒント: セッションのスケジュールは変更される場合があります。最新の情報は必ず公式の AWS re:Invent セッションカタログ をご確認ください。 著者について Suhail Fouzan Suhail Fouzan は、Amazon Web Services (AWS) のスペシャリストソリューションアーキテクトで、IT 業界で 15 年以上の経験を持っています。Microsoft ワークロード、移行サービス、AWS Systems Manager による運用管理を専門とし、お客様がインフラを AWS へ無事に移行できるよう支援しています。仕事以外では、クリケットをしたり家族と過ごす時間を楽しんでいます。 Bianca Velasco Bianca Velasco は AWS のプロダクトマーケティングマネージャーで、AWS 上での VMware ベースのワークロードの移行と変革に取り組んでいます。マーケティングとテクノロジー分野で 7 年以上の経験を持ち、複雑なテクノロジーを意味のある、親しみやすいストーリーとして伝えることに情熱を注いでいます。仕事以外では、ボランティア活動、ダンス、ボルダリングを楽しんでいます。 Yusuf Sheikh Yusuf は AWS のソリューションアーキテクトで、クラウド移行プロジェクトを専門とし、データセンターインフラや運用エンジニアリングの経験を持っています。組織をクラウド移行の成功へと導くことに情熱を注いでいます。余暇には乗馬やサッカーを楽しんだり、自然豊かな景勝地を訪れたりしています。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本ブログは 2026 年 4 月 29 日に公開された AWS Blog “ Designing trust and safety into Amazon Bedrock powered applications ” を翻訳したものです。 生成 AI は有望なイノベーションをもたらし、カスタマーサービスからコンテンツ作成に至るまで、個人や組織によるさまざまな業務への取り組み方を変革しています。AI の機能が拡大し続ける中、組織は、AI アプリケーションの開発ライフサイクルに責任ある AI の概念をどのように組み込むかにますます注目しています。 アクセンチュアと Amazon Web Services (AWS) による調査 では、責任ある AI の実践が組織内部と組織外部のユーザーの双方にもたらすビジネス価値について、説得力のある根拠が示されています。責任ある AI に対する成熟したアプローチを明確に発信している組織では、AI の導入に対する従業員の信頼が 82% 向上しており、それがイノベーションの促進に直接つながっています。さらに、責任ある AI を活用した製品やサービスを提供している企業では、顧客ロイヤルティと顧客満足度が 25% 向上しています。 責任ある AI の主要な側面を理解する AWS は、責任ある AI の実装の基盤となる主要な側面として、次のものを挙げています。 安全性 は、有害なシステム出力と誤用の防止に重点を置いています。この側面では、ユーザーとシステムの安全性を優先するように AI システムを方向付けることを重視します。 制御可能性 は、AI システムの動作を監視して方向付ける仕組みに重点を置いています。この側面は、AI システムが特定のパラメータの範囲内で動作するように管理、誘導、制約する能力を指します。 公平性 は、AI がさまざまなユーザーグループに与える影響を考慮することに重点を置いています。 説明可能性 は、システム出力の理解と評価に重点を置いています。 セキュリティとプライバシー は、データとモデルを適切に取得、使用、保護することに重点を置いています。 正確性と堅牢性 は、予期しない入力や敵対的な入力があっても、正しいシステム出力を実現することに重点を置いています。 ガバナンス は、AI システムの開発、デプロイ、管理を倫理基準、法的要件、社会的価値観に沿ったものにすることに重点を置いています。 透明性 は、AI システムがどのように意思決定を行うのか、なぜ特定の結果を生成するのか、どのようなデータを使用しているのかを理解することに重点を置いています。 AI の実装では、これらすべての側面を確認して適用することがベストプラクティスです。詳細については、「 Amazon Bedrock アプリケーションで責任ある AI のコアディメンションに対応するための考慮事項 」を参照してください。 責任ある AI のライフサイクル AI システムを実装する際は、AWS の責任ある AI のライフサイクルのすべてのフェーズに安全性を組み込むべきです。責任ある AI のライフサイクルは次の 3 つのフェーズで構成されており、安全性の側面に関する責任を考える際の考慮事項はフェーズごとに異なります。 設計および開発フェーズ では、潜在的な安全性リスクを徹底的に評価します。AI アプリケーションに何をさせたいのか、何をさせたくないのか、どのような動作を防止したいのかを明確にします。システムには最初から安全性のガードレールを組み込み、開発チームが AI アプリケーションの機能と限界を理解していることを確認してください。 デプロイフェーズ では、理論が現実に試されます。このフェーズでは、ユーザー向けの包括的なトレーニングから、プロアクティブな監視やレビュープロセスまで、複数のレイヤーで堅牢な安全対策を実装すべきです。すべてのアプリケーション、製品、機能に、明確な安全プロトコルとユーザー向けガイドラインを含める必要があります。アプリケーションのリリースだけでなく、全体的な安全フレームワークをどのように立ち上げるかまで検討する必要があります。このフレームワークは、ブランド、ユーザー、ステークホルダーを保護するものでなければならず、レッドチームテストなどのステップを含めることもできます。 運用 フェーズ では、警戒を怠らないことが重要です。安全性は、セキュリティと同様に、一度設定したら放置してよいものではなく、継続的な監視と適応が必要です。潜在的な安全性の問題を早期に発見できるよう、リアルタイムのフィードバックの仕組みを実装し、定期的にパフォーマンスを評価できます。また、アプリケーションの使われ方の変化や、安全性を損なうおそれのある機能を継続的に監視することもできます。安全性に関する考慮事項やリスクはテクノロジーの進化とともに変化するため、継続的な調整が必要であることを理解しておくことが非常に重要です。 詳細については、「 Responsible use of AI guide 」を参照してください。 不正使用の検出 Amazon Bedrock の基盤モデルには、有害な出力を防ぐための安全メカニズムが本来備わっています。ただし、本番環境で入力に対する安全システムを追加で実装すれば、問題のあるコンテンツ、ユーザー、パターンを早期に検出するための重要な機能を実現できます。 注 : Amazon Bedrock では、 AWS 適正利用規約 (AUP) およびサービス条件 ( 責任ある AI ポリシー やサードパーティーのモデルプロバイダーの AUP を含む) への違反の可能性を特定するために、自動化された不正使用の検出メカニズムを実装している場合があります。 詳細については、 Amazon Bedrock の不正使用の検出に関するドキュメント を参照してください。 AI の不正使用を防止するためのツールと手法 AI サービスに対する信頼を維持するには、開発リソースを効率的に計画、管理しつつ、予防的な措置を講じることが重要です。開発の早い段階でオブザーバビリティと安全性のガードレールを導入することで、長期的なスケーラビリティを支えるとともに、ユーザーに影響が及ぶ前に潜在的な問題を特定しやすくなります。このプロセスを始めるにあたり、次のアクションを通じて AI のユースケースの範囲を徹底的に定義します。 ユーザーを理解する 起こり得る誤用シナリオを予測する リスク許容度を定義する この範囲定義は、期待されるパフォーマンスを維持しながら、AI の実装に固有のリスクに対処する精緻な安全フレームワークを開発する際の指針となります。この範囲定義に基づいて、Amazon Bedrock アプリケーションの監視と保護に特化して設計された AWS のツールを活用できます。 CloudWatch を使用して Amazon Bedrock を監視する Amazon CloudWatch は、AI システムの動作とパフォーマンスを把握するために不可欠な可視性を提供します。包括的なログ記録を設定すると、ユーザーセグメントやインタラクションの種類ごとに、次のような重要な情報を取得できます。 リクエスト量 レスポンスのレイテンシー 拒否率 コンテンツフィルタリングのトリガー この情報を使用すると、運用に影響が及ぶ前に、不正使用が疑われるパターンや予期しない動作を特定できます。CloudWatch ダッシュボードでは監視の優先度に応じてメトリクスを可視化でき、自動アラートによってしきい値を超えた際に迅速に通知を受け取れます。このインフラストラクチャにより、インタラクションデータを実用的なインサイトに変換し、安全性の継続的な改善につなげることができます。 注 : デフォルトでは、Amazon Bedrock のログ記録はオフになっています。アプリケーションでログ記録をオンにする必要があります。設定については、アカウントマネージャーにお問い合わせください。 訳注: モデル呼び出しのログ記録は、Amazon Bedrock コンソールまたは API を使用してお客様自身で有効化することもでき、ログの出力先には Amazon S3 または Amazon CloudWatch Logs を指定できます。参照: Amazon Bedrock ユーザーガイド Amazon Bedrock Guardrails を使用して保護措置をカスタマイズする Amazon Bedrock Guardrails は、特定のリスクプロファイルやコンテンツポリシーに合わせて設定できる保護メカニズムを提供します。Amazon Bedrock Guardrails は、次のようにアプリケーションの要件に合わせてカスタマイズできます。 ドメインに関連する望ましくないトピックを定義する 適切なコンテンツフィルタリングのしきい値を設定する データポリシーに沿った機密情報の検出と秘匿化のパラメータを設定する さらに、アプリケーションのニーズに応じて創造性の余地を残しつつ、精度を優先してハルシネーションを防ぐコントロールも設定できます。Amazon Bedrock Guardrails を慎重に設定することで、ユースケース固有の要件やリスク要因に応じて、パフォーマンスと安全性のバランスを取ることができます。 不正使用への対応プロセス AI の安全性に関する取り組みが進化し、新たなリスクが生じる中、安全メカニズムを実装していても不正使用が発生する可能性はあります。AWS Trust & Safety チームから 不正使用の報告 を受け取った場合は、問題に効果的に対処するために次の手順を実行してください。 受領した旨を連絡する : 24 時間以内に、不正使用の報告を受領したことを AWS に連絡します。チームが調査を継続中の場合は、その旨を AWS に伝え、調査完了までの見込み日数を知らせます。 問題を調査する : ログ (有効になっている場合) の確認、Amazon Bedrock への入力のレビュー、不正アクセスの有無の確認など、問題を徹底的に調査します。AWS の不正使用の報告には調査用のプロンプト ID のサンプルが少数含まれていますが、それだけでなく Amazon Bedrock アプリケーションの使用状況全体を調査してください。パターンを確認し、不正使用につながっている構造的な問題がないかを調べます。 適切な措置を講じる : 必要に応じて、修正の実装、保護措置の更新、違反行為を行ったユーザーへの対処、機能の再設計などの措置を講じます。不正使用を行った 1 人のエンドユーザーに対処するだけでなく、構造的な問題や根本原因に対処する修正が必要かどうかを検討してください。1 人のユーザーによる不正使用のインシデントが、継続的な不正使用につながりかねない安全メカニズムの脆弱性を示している可能性があります。 AWS Trust & Safety に報告する : 調査と修正の実装が完了したら、調査結果と実施した是正措置について AWS Trust & Safety に最新情報を報告します。何が起きたのか、どのように問題に対処したのかを透明性をもって説明してください。違反が発生していないと判断した場合は、その結論に至った経緯を説明してください。可能であれば、プロンプトの例とビジネスのユースケースも含めてください。 まとめ 安全性と責任ある AI の開発について詳しくは、 責任ある AI ポータル や 機械学習のベストプラクティスに関するドキュメント など、AWS のリソースをご覧ください。これらのリソースは、安全基準を維持しながらイノベーションを促進する、安全で効果的な AI システムを構築するための追加のツールやフレームワークを提供しています。 Victor Lungu Victor は、ダブリンを拠点とする AWS の Trust & Safety AI Abuse Specialist です。コンテンツの安全性や新たな AI リスクなど、AI の安全性に関する幅広い分野に携わっています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 5 月 20 日に公開された AWS Blog “ Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows ” を翻訳したものです。 エージェントには主体性 (agency) があります。状況に適応し、問題を解決するための複数の方法を見つけ出します。この自律性は、セキュリティ上の根本的な課題を生み出します。エージェントの中核にある大規模言語モデル (LLM) は非決定論的であり、その判断を事前に予測したり保証したりすることはできません。LLM はハルシネーションを起こし、有害なアクションを完全な確信を持って生成してしまうことがあります。また、プロンプトインジェクション攻撃に対して脆弱です。この攻撃では、攻撃者がツールの応答やユーザー入力を通じて悪意のあるコマンドを注入します。LLM はコマンドとデータを確実には区別できません。LLM にとっては、すべてが単なるトークンにすぎないからです。こうした理由から、多層防御を実現するには、セキュリティの観点から LLM を信頼できないアクターとして扱う必要があります。 ここで重要なのは、LLM が外部の世界に直接影響を与えることはできないという点です。LLM は、その出力に基づいてツールを呼び出すオーケストレーターを経由する必要があります。制御を適用すべきなのは、まさにこのポイントです。この境界で必要なのは認可、つまり各ツール呼び出しを許可すべきかどうか、またどのような条件で許可すべきかの判断です。オンライン小売業者のカスタマーサービスエージェントを例に考えてみましょう。適切な制御がなければ、このエージェントは認められた上限を超える返金を処理したり、除外すべき製品カテゴリに割引を適用したり、ある顧客のセッションを処理している最中に別の顧客のデータを参照したりする可能性があります。 エージェントのツールへのアクセスを制御すれば、エージェントが自由に動作できる安全境界 (safety envelope) を確立できます。これは、一般的ではあるものの十分とはいえない次の 2 つのアプローチとは異なります。 ハードコードされたワークフローを作成すると不確実性はなくなりますが、それだけでは、エージェントの頭脳として LLM を使用する意味がなくなります。LLM のインターフェイスを備えた従来型のアプリケーションを構築したことになるからです。さらに、このように制限したとしても、いずれかのステップで LLM の出力を使用すれば、同じリスクが生じる可能性があります。内容が十分に把握されているワークフローには有用な手法ですが、適応が求められるエージェントには十分ではありません。 ヒューマンインザループ (Human-in-the-loop) は重要な操作のセーフティネットとなり、今後も一定の役割を果たし続けます。しかし、これを主要な制御メカニズムとして頼ると、自律性が犠牲になり、承認疲れにつながる可能性があります。 必要なのは、安全かつ自律的なエージェントです。そのためには、エージェントとツールの外部に配置された、監査可能で決定論的な適用レイヤーが必要です。なぜ外部なのでしょうか？信頼できないのは LLM の計画そのものであり、LLM に自身の制約を適用する責任を負わせることはできないからです。システムプロンプトやトレーニング時のアライメントなど、LLM レイヤーでの制御は、プロンプトインジェクションやハルシネーションによって回避される可能性があります。エージェントやツールのコードにハードコードされたチェックはより堅牢ですが、大規模になると監査や管理が難しくなります。特に、セキュリティロジックが多数のツールやサービスに分散している場合はなおさらです。エージェントとツールの両方の外部で認可を一元化すれば、LLM が回避できない単一のチェックポイントを設けられます。このチェックポイントは監査可能であり、アプリケーションコードとは独立して検証できます。 そこで役立つのが AgentCore Policy です。 Amazon Bedrock AgentCore Gateway は、エージェントと、エージェントが呼び出すリモートツールとの間に配置されます。Policy を Gateway に関連付けると、デフォルトですべてがブロックされます。ポリシーは、どのツール呼び出しをどのような条件で許可するかを指定することで、この境界を選択的に開放します。このポリシーの適用対象は、Gateway を経由するすべてのツールトラフィックです。このアプローチをスケールさせるには、エージェントの動作について推論するよりも、ポリシーについて推論する方が容易である必要があります。 AgentCore で使用するポリシーは Cedar で記述します。Cedar は AWS が開発したオープンソースの認可ポリシー言語で、2025 年 12 月に Cloud Native Computing Foundation (CNCF) に参加しました 。Cedar は、まさにこうした特性を備えるように設計されています。認可に特化して構築されており、人間が読みやすく、自動推論を使用して機械で分析できます。これにより、企業はポリシーの定義と適用を AI エージェントにまで拡張できます。 Amazon Bedrock AgentCore における Cedar の活用方法 Amazon Bedrock AgentCore は、エージェントを大規模にデプロイおよび管理するためのインフラストラクチャを提供します。これには、エージェントをホストするための AgentCore Runtime 、Model Context Protocol (MCP) を使用してエージェントがツールに接続する方法を管理するための AgentCore Gateway 、そして AgentCore Policy が含まれます。Policy は、AgentCore Gateway を経由するすべてのエージェントトラフィックをインターセプトし、ツールへのアクセスを許可する前に、ポリシーエンジンで定義されたポリシーに照らして各リクエストを評価します。このポリシーレイヤーを支えているのが Cedar です。 AgentCore Policy は、AgentCore Gateway のワークフロー内の複数の段階で、Cedar とその数学的分析機能を使用します。Cedar 認可エンジンはポリシーの評価時に使用され、 Cedar Analysis はポリシーの作成時とコントロールプレーンで使用されます。 ポリシー作成 : 開発者は、Cedar ポリシーを直接記述することも、自然言語で記述して ニューロシンボリック AI のフィードバックループで Cedar に変換することもできます。ニューロシンボリック AI は、機械学習の柔軟性と、自動推論の証明可能な正しさを組み合わせたものです。LLM が自然言語からポリシーを生成し、Cedar Analysis がシンボリックかつ数学的な推論を使用してそれらを検証します。次の図は、このワークフローを示しています。 図 1: Cedar ポリシー生成のワークフロー 管理者は、エージェントがどの MCP ツールをどのような条件で呼び出せるかを自然言語で指定します。次に、ニューロシンボリックなフィードバックループがこの記述を Cedar ポリシーとして形式化します。仕組みは次のとおりです。まず、LLM が自然言語を Cedar ポリシーに変換します。次に、これらのポリシーに対して 2 段階の検証が実行されます。第 1 段階では、AgentCore Policy が Cedar の スキーマジェネレーター を使用します。このジェネレーターは MCP ツールの説明を受け取り、Cedar スキーマを生成します。Cedar はこのスキーマに照らしてポリシーを検証します。これにより、ポリシーが有効なツールとパラメータを参照していることを確認するとともに、さまざまな種類のランタイムエラーをまとめて排除できます。検証に合格すると、第 2 段階で Cedar Analysis が実行されます。Cedar Analysis は各ポリシーを数式としてエンコードし、すべてを許可または拒否するポリシーや、成立し得ない条件を含むポリシーなどの問題を検出します。こうした数学的証明によって、自然言語の記述から Cedar ポリシーへの変換プロセスで生じたエラーが特定され、修正の方向性が示されます。 ニューロシンボリックなフィードバックループにより、生成されるポリシーの精度が大幅に向上します。これは、ニューラルアプローチとシンボリックアプローチを組み合わせることの威力を示しています。LLM は自然言語からの創造的な変換を担い、自動推論は厳密な検証を担います。 コントロールプレーン : ポリシーを AgentCore Gateway にアタッチする際、Cedar Analysis はポリシーセット全体を包括的に分析します。ポリシーを個別に分析するのではなく、ポリシーどうしがどのように相互作用するか、またそれらを組み合わせた場合の効果を調べます。この分析により、競合するポリシーや冗長なポリシーなどの潜在的な論理エラーが特定され、ポリシーセットが意図しない認可結果を生み出すかどうかが検出されます。Cedar Analysis がこれらのエラーを検出すると、操作は失敗して問題の説明が返されるため、ポリシー作成者は修正して再試行できます。チェックの例については、「 ポリシー検証のための形式的分析 」セクションを参照してください。 MCP ツール呼び出しへのポリシー適用 : AgentCore Gateway に送信されるエージェントの各ツールリクエストは、Cedar ポリシーに照らして評価され、指定された引数による MCP ツール呼び出しを許可すべきかどうかが判断されます。これにより、安全境界を形成しつつ、エージェントが業務を遂行するために必要な経路を開放します。 MCP ツールのフィルタリング : Cedar は、ツール呼び出しが発生する前の段階で機能する追加の保護レイヤーも実現します。エージェントがツール一覧の取得コマンドを発行すると、AgentCore Gateway は Cedar の 部分評価 機能を使用して、現在のポリシーセットのもとで常に拒否されるアクションを判断します。それらのアクションは、ツール一覧のレスポンスから除外されます。エージェントとその基盤となる LLM がそれらのツールアクションを目にすることはないため、ある種類のリスクを完全に排除できます。エージェントと LLM は、存在を知らないツールを呼び出そうとすることができないからです。これは Cedar の部分評価がもたらす直接的なメリットです。実際のツール呼び出しの試行を待たなくても、特定のツールアクションに到達できないことをシステムが判断できます。 なぜ Cedar なのか: 分析可能性が大規模環境での安全性を実現する 自然言語は、セキュリティが重要なインフラストラクチャで使用するにはあいまいすぎます。一方、Python などの汎用プログラミング言語は非常に表現力が高いものの、分析が困難すぎます。意図しない副作用や停止性の問題が生じる可能性があり、理解するのも難しい場合があります。 Cedar は、ループやステートフルな操作を排除することでこれらの問題を回避しています。そのため、一般的なケースではポリシー評価が O(n) 時間で終了します。このように実行時間に上限があるため、エージェントはユーザーエクスペリエンスやワークフローの効率を損なうことなく認可の判断を行えます。 Cedar は読みやすい言語です。規制コンプライアンスやセキュリティ監査では、人間が理解して検証できるポリシーが求められます。Cedar ポリシーは構造化された自然言語のように読めるため、セキュリティチーム、コンプライアンス担当者、ビジネスステークホルダーにとっても理解しやすくなっています。 // Only allow bulk discounts for premium customers with sufficient quantity permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ApplyBulkDiscount", resource ) when { principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Platinum" && context.input.orderQuantity >= 50 } unless { context.input .productTypes .containsAny ( ["limited_edition", "seasonal_specials"] ) }; 技術的なバックグラウンドを持たない監査担当者でも、このポリシーは理解できます。「50 個以上注文するプラチナ顧客には大量購入割引を許可する。ただし、限定版または季節限定の特別製品は除く」という意味です。 unless 句によって例外が明確になります。これは、ビジネスルールを自然言語で表現する際の一般的な書き方と同じです。この 1 つのポリシーが、2 つの異なるデータソースを制約している点に注目してください。顧客ティアは JSON Web Token (JWT) のクレームから取得されるため、LLM によるハルシネーションや改ざんの影響を受けません。一方、注文数量や製品タイプなどのツール入力は、LLM のツール呼び出しに由来します。Cedar ポリシーはこれらの入力を許可された値のみに制約するため、LLM が予期しない引数を生成した場合でも、ポリシーの適用レイヤーによって決定論的に拒否されます。 Cedar が適切な選択肢である理由は、高速で、読みやすく、自動推論によって 分析可能 だからです。この分析可能性があるからこそ、Cedar ポリシーとして表現されたエージェントの安全境界について推論できるのです。エージェンティックシステムが成長するにつれて、ツールの数も増えていきます。適切な管理ツールがなければ、ポリシー管理は手に負えなくなります。ポリシーが競合したり、セキュリティ上のギャップが生じたり、意図しない認可結果が生まれたりする可能性があります。 このセクションの残りの部分では、Cedar の分析可能性が、決定論的かつ数学的に健全な分析によって、この課題にどのように直接対処するかを見ていきます。Cedar の分析は大規模なポリシーセット全体にわたって競合や論理エラーを確実に検出できるため、ニューロシンボリック AI によるスケーラブルなポリシー管理が可能になります。 ポリシー検証のための形式的分析 Cedar ポリシーは、 シンボリックエンコーダーを通じて 数式にエンコードし、自動推論の手法で分析できます。これにより、AgentCore Policy は、ポリシーの作成時をはじめとするさまざまな場面で、高度なポリシー検証機能を提供できます。AgentCore Policy はポリシーの作成時やアタッチ時にこの分析を使用して、競合するポリシーや冗長なポリシーなどの論理エラーの可能性を検出します。ポリシー比較を含むポリシー分析は、オープンソースの CLI ツール として利用できます。ここからは、これらのチェックの具体例をいくつか見ていきましょう。 ポリシーの論理エラーの検出 : Cedar Analysis は、ポリシーに含まれる論理エラーを検出できます。例えば、次のポリシーには矛盾する制約があるため、どのリクエストも許可できません。顧客ティアが同時にゴールドとプラチナの両方になることはあり得ないからです。本来は || を使う意図でしたが、誤って && が使われています。このような間違いは、ポリシーを作成する人間と AI システムのどちらにも起こり得ます。 // This policy cannot allow any requests due to logical errors permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Gold" && principal.getTag("customer_tier") == "Platinum" } unless { context.input.refundAmount > 1000 }; 同様に、Cedar Analysis は、特定のアクションを常に許可するポリシーも検出できます。このようなポリシーは、通常、許可範囲が広すぎることを示しています。例えば、次のポリシーはすべての ApplyBulkDiscount リクエストを許可します。どのような注文数量であっても、100 以上か 100 未満のいずれかに該当するからです。 // This policy allows all ApplyBulkDiscount requests permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ApplyBulkDiscount", resource ) when { context.input.orderQuantity >= 100 || context.input.orderQuantity < 100 || (principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Platinum") }; このような論理エラーを人間が見つけるのは容易ではなく、パターンマッチングで検出することもできません。数学的分析による形式的な厳密さが必要であり、それこそが Cedar Analysis の役割です。 ポリシーの競合の検出 : Cedar Analysis は、ポリシーセット全体を分析して、個々のポリシー間の不整合を検出することもできます。 // These policies conflict - Analysis will detect the subtle issue permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { principal.hasTag("customer_tier") && principal.getTag("customer_tier") == "Gold" && context.input.refundAmount < 100 }; forbid ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { principal.hasTag("customer_tier") && ["Gold", "Platinum"].contains(principal.getTag("customer_tier")) && context.input.refundAmount < 500 }; permit ポリシーはゴールド顧客に対して 100 USD 未満の返金処理を許可していますが、forbid ポリシーはゴールド顧客 (およびプラチナ顧客) による 500 USD 未満の返金処理をブロックしています。Cedar では forbid が permit より優先されるため、permit ポリシーがあるにもかかわらず、forbid ポリシーによってゴールド顧客の返金はすべてブロックされます。 ポリシー変更の比較 : ポリシーを更新する際、Cedar Analysis は変更による正確な影響を判断することもできます。unless 句に対する次の更新を考えてみましょう ( + の付いた行は追加された行、 - の付いた行は削除された行です)。更新後は、 ApplyBulkDiscount がブロックされるのは、数量が 200 を超え、 かつ 製品タイプが limited_edition の場合のみです。 permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ProcessRefund", resource ) when { context.input.refundAmount < 500 }; permit ( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ApplyBulkDiscount", resource ) when { context.input.orderQuantity >= 50 } unless { - context.input.productTypes.containsAny(["limited_edition"]) + context.input.productTypes.containsAny(["limited_edition"]) && + context.input.orderQuantity > 200 }; 一見すると、unless 句に条件を追加すれば、制限がより厳しくなるように思えるかもしれません。しかし、実際にはその逆です。unless が適用される範囲が狭まるため、permit が対象とするリクエストは増えることになります。例えば、 limited_edition 製品を 73 個注文した場合、更新前はブロックされていましたが、更新後は許可されます。Cedar Analysis はこれを自動的に検出し、元のポリシーセットと更新後のポリシーセットの許可範囲の違いを示す次の表を生成します。 プリンシパルタイプ アクション リソースタイプ ステータス OAuthUser ProcessRefund Gateway 同等 (Equivalent) OAuthUser ApplyBulkDiscount Gateway 許可範囲が拡大 (More permissive) この分析結果から、更新後のポリシーは ProcessRefund リクエストについては以前とまったく同じ範囲を許可する一方で、 ApplyBulkDiscount リクエストについてはより多くを許可することがわかります。 エージェントが自律的に動作し、現実世界に影響を与える可能性がある場合、このような形式的検証の機能は不可欠です。組織には、ポリシーが意図したとおりに動作するという数学的な確実性が必要です。 信頼性の高いガバナンスを実現する決定論的な動作 確率的な AI モデルとは異なり、エンタープライズセキュリティには決定論的な保証が必要です。Cedar ポリシーは、評価順序やシステムの状態にかかわらず、同一のリクエストに対して常に同じ認可の判断を下します。Cedar の 「デフォルトで拒否する」「forbid が優先される」「評価順序に依存しない」 というセマンティクスは、予測可能な動作の確保に役立ちます。 // Policy evaluation order does not affect the authorization decision permit( principal, action == AgentCore::Action::"ProcessRefund", resource ) when { context.input.refundAmount < 500 }; forbid( principal, action == AgentCore::Action::"ProcessRefund", resource ) when { context.input.orderDate.offset(duration("90d")) < context.system.now }; permit ポリシーと forbid ポリシーのどちらが先に評価されても、500 USD を超える返金リクエストは常に拒否され、注文日から 90 日を過ぎて行われる返金も拒否されます。この予測可能性があるからこそ、企業は安心してエージェントのガバナンスを行えます。 ポリシーから本番環境へ AgentCore Policy と Cedar を選択すれば、組織は、エージェントが正しく動作することをただ期待するのではなく、数学的に推論できるポリシーを備えた自律型エージェントをデプロイできます。Cedar は表現力、可読性、形式的検証を兼ね備えているため、動作に必要な柔軟性と、セキュリティチームが求める確実性の両方を備えたエージェントを設計できます。 自動推論 は、アクセスポリシーを検証する AWS IAM Access Analyzer から、 ネットワーク設定 の証明可能なセキュリティに至るまで、AWS 全体で既にその価値を実証しています。同じ手法をエージェンティック AI に適用するのは自然な流れです。エージェントが担う責任が大きくなるにつれて、数学的な根拠に基づく保証の必要性は高まる一方です。この記事で説明したニューロシンボリックなアプローチは、LLM の柔軟性と自動推論の厳密さを組み合わせたものです。このアプローチは、検証が自律性と歩調を合わせて進むことで、エージェントがより自律的であると同時に、より信頼できる存在になる未来を示しています。 詳細情報 Policy は現在、 Amazon Bedrock AgentCore Gateway の一部として利用できます。Cedar とその機能の詳細については、 Cedar ウェブサイト にアクセスするか、 Cedar プレイグラウンド をお試しください。また、Cedar コミュニティには Slack から参加できます。 Amazon Bedrock AgentCore Gateway の Policy の詳細については、 AWS ドキュメント を参照するか、 AgentCore Gateway コンソール をご確認ください。 Liana Hadarean Liana は AWS の Principal Applied Scientist です。Amazon Q の Java セキュリティディテクターを支えるコード分析ツールの開発に携わり、現在は Cedar ポリシー言語のコントリビューターを務めています。 Jean-Baptiste Tristan Jean-Baptiste は AWS Agentic AI の Senior Principal Applied Scientist で、ニューロシンボリック AI とエージェントの安全性に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

グローバルに製品を展開する企業にとって、利用者が普段使っている言語で製品の使い方に答えるサポートの提供は共通の課題です。対応する言語が増えるほど、すべての言語で問い合わせに応じる体制を整えることは難しくなります。 この課題を解決する手段の一つが、生成 AI を活用したサポートチャットです。利用者の質問に関連する情報をオンラインマニュアルから検索し、その内容を根拠に回答を生成することで、利用者の言語で製品の使い方を案内できます。 ただし、このようなサポートチャットでは、回答の正確さに加えて、回答までの速さも利用者の体験を大きく左右します。多言語のマニュアルを扱う場合、検索基盤の容量や運用負荷を抑えるために索引を特定の言語に絞ると、質問の翻訳や対象言語の本文取得といった処理が増え、待ち時間が伸びやすくなります。また、利用者の多くは製品を操作している途中で分からない点に直面し、その場で解決したいと考えてチャットを開きます。最初の質問に続けて利用環境などの条件を補足するやり取りも多く、1 回ごとの待ち時間が積み重なるほど、解決までの体験は損なわれます。 本記事では、30 以上の言語で製品のオンラインマニュアルを提供する国内の大手製造業のお客様と AWS が取り組んだ、製品サポートチャットの開発事例を紹介します。このサービスは既に提供を開始しており、オンラインマニュアルから質問に関連する情報を探し、その内容を根拠に回答します。 製品の使い方に答えるサポートチャット 今回のサポートチャットは、製品を使う方がオンラインマニュアルに基づく回答を得るための、提供開始済みのサービスです。利用者向けアプリケーションの機能として、事前に定義した Q&A に沿って進む固定シナリオと、利用者が自由に質問を入力する AI チャットを提供しています。 固定シナリオでは、あらかじめ用意した案内に沿って操作を進めます。一方で AI チャットでは、入力された質問から関連するマニュアルを検索し、その内容を根拠に回答を生成します。この 2 つの機能を組み合わせ、定型的な案内と、自由入力による問い合わせの両方に対応しています。 AI チャットの設計における主な要件は、次の 3 点です。 応答時間: 質問の翻訳、検索、文書取得、回答生成を含むアプリケーションの応答時間を 10 秒以内に収める要件がありました。新しい実行環境が必要な場合には、その起動も待ち時間に関わります。 会話文脈の保持: 利用者が最初に使い方を質問し、続けて利用環境などの条件を補足する場面もあります。同一セッション内のやり取りを保持し、追加された条件を前の質問と合わせて扱うことが、会話を継続するための要件です。 多言語対応: 30 以上の言語に対応しています。言語別のオンラインマニュアルを回答に使う一方、検索基盤の容量を考慮し、索引に取り込む文書は英語のマニュアルに絞っています。そのため、利用者の質問を検索できる形に変換し、見つかった文書から対象言語の本文を取得する処理が必要でした。 これらの要件を踏まえ、モデルの選択と検索処理の組み立てに加え、実行環境の準備と会話情報の扱いを含めて設計しました。 ソリューションの全体構成 図 1 に、 Amazon Bedrock AgentCore (以下 AgentCore) を使ったサポートチャットの主な構成を示します。 図 1. 製品利用者向けサポートチャットの主な構成。 図中の番号に沿って、問い合わせの受付から検索・回答までの役割を説明します。 ステップ 1: 利用者のアプリケーションからの問い合わせを、 Amazon CloudFront と Amazon API Gateway を経由して受け付けます。 ステップ 2: AWS Lambda で実装したチャットバックエンドが、事前定義のシナリオを使う固定 Q&A と、自由入力の AI チャットを振り分けます。自由入力の場合は AgentCore Runtime を呼び出します。 ステップ 3: 新しい実行環境が必要な場合は、 AgentCore Runtime V2 が初期化済み環境のスナップショットから復元し、セッション用の microVM を準備します。復元対象は実行環境であり、会話データではありません。 ステップ 4: AgentCore Runtime 内の microVM で動く Strands Agents が、マニュアルの検索と回答生成のワークフローを実行します。 英語の索引を用いた検索と対象言語の本文に基づく回答 ステップ 4 の処理を、日本語の質問を例に見ていきます。Strands Agents のワークフローは、 Amazon Translate で質問を英訳し、 Amazon Bedrock の検索用モデルを呼び出して検索キーワードを生成します。そのキーワードで、英語版マニュアルだけを取り込んだ索引を検索します。 検索結果から得るのは、英語版マニュアルの URL です。ワークフローは、その URL に含まれる言語部分を日本語へ切り替え、オンラインマニュアルから対応する日本語版の本文を取得します。図中のマニュアル検索は必要な文書を見つけるための検索基盤、オンラインマニュアルは対象言語の本文を取得する参照先という役割です。 取得した日本語の本文を根拠として、検索キーワードの生成とは別の Amazon Bedrock のモデルで回答を生成します。検索キーワード生成に Amazon Nova 2 Lite 、回答生成に Claude Haiku 4.5 を使用しました。検索用と回答用のモデルを使い分け、必要な文書を探す処理と、その文書を基に利用者へ説明を返す処理を分担させています。 Strands Agents がこの一連の処理をつなぐことで、英語の索引で文書を探し、利用者の言語の本文を根拠に回答するワークフローを実現しています。 Amazon Bedrock AgentCore の採用理由 PoC から本番運用へ進むには、エージェントロジックに加え、セッションごとの実行環境の分離や認証・認可、会話管理、回答品質の評価も検討する必要がありました。AgentCore は、実行基盤の AgentCore Runtime 、会話情報を扱う AgentCore Memory 、評価を行う AgentCore Evaluations などをマネージドで提供し、こうした開発・運用を支援します。 図 2. Amazon Bedrock AgentCore が提供する機能群。 共通機能を自前で一から実装せず、必要な機能から選んで組み合わせられることが、導入のハードルを下げました。AgentCore Runtime 上の Strands Agents で独自の検索・回答ワークフローを組み立て、基盤の共通機能を AgentCore に任せることで、AI チャットのエージェントロジックに注力できました。 今回の AI チャットでは、AgentCore Runtime を実行基盤に、AgentCore Memory を同一セッションの会話文脈の保持に利用しています。 Amazon Bedrock Guardrails の個人情報等のブロック・マスク機能も組み合わせています。 AgentCore Observability では、トレースとタイムラインを使い、コンテナの初期化とエージェントの処理を切り分け、レイテンシーの調査に活用しました。AgentCore Evaluations は、回答品質を確認する回帰テストに試験利用しました。 AgentCore Runtime V2 の導入と対話の待ち時間の設計 サポートチャットの提供開始に合わせて AgentCore Runtime V2 を導入しました。現時点では、利用者から 1 日あたり数百のリクエストがありますが、10 秒以内のエンドツーエンドのレイテンシーで応答する要件において、AgentCore Runtime V2 の基盤で一貫したレイテンシーを実現できています。 ここからは、応答を支える実行基盤として採用した AgentCore Runtime V2 の起動の仕組みを見ていきます。 図 3. Runtime V1・V2 の起動方式の概念比較。 図中の約 2 秒 (P75) は、モデルやツールを呼び出さない echo agent を用いた AWS ブログの測定例 であり、今回の AI チャットの実測値ではありません。 スナップショットを用いた初期化済み環境の復元 AgentCore Runtime V2 は、初期化済みの実行環境をスナップショットから復元することで、イメージサイズや同時実行数にかかわらず、コールドスタートを高速かつ一貫させることが可能です。リソースを作成または更新した時点で環境を一度のみ準備してスナップショットを取り、以降は新しい microVM ごとに環境を初期化するのではなく、そのスナップショットから復元しています。 スナップショットに含まれるのは、エージェントの初期化済みの状態です。コンテナイメージやコードの取得と配置、モジュールスコープの初期化が含まれます。 V2 では、実行環境のメモリ利用も見直されています。必要に応じてメモリを取り込み、 エージェントが解放した領域や、再び参照される可能性が低い領域を回収します 。ここでのメモリ回収は実行環境のリソース管理であり、AgentCore Memory に保持した会話情報の削除とは異なります。 AgentCore Runtime V1 から V2 への移行における最適化 V1 から V2 への移行では、スナップショットから初期化結果を再利用できるように、処理を実行するタイミングを見直します。依存関係やデプロイに含まれる静的設定の読み込み、再利用できるクライアントの構築などを、スナップショット取得前に済ませます。初回リクエストで行っていた処理のうち、各実行環境で共通して使えるものを初期化時へ移すことで、復元後に必要な準備を減らせます。 AgentCore SDK を使う場合は、こうした処理を app.run() より前のモジュールスコープに配置します。AgentCore Runtime は最初の正常な /ping 応答でスナップショットを取得するため、独自の HTTP サーバーを使う場合も、初期化が完了してから正常応答を返します。ただし、再デプロイせずに変更する設定はスナップショットに固定せず、変更を反映できるタイミングで読み込みます。 あわせて、V1 で起動時に生成していた値が、復元後もそのまま使えるかを確認します。現在時刻やリクエスト固有の識別子は、リクエストを処理する際に生成し、有効期限のある認証情報は期限切れ時に更新します。起動時の値をスナップショットに含めると、複数の復元先で同じ値が引き継がれるためです。初期化処理を前倒しする際は、再利用できる状態と、その都度更新すべき状態を分けます。 詳細は V2 向けの最適化 のドキュメントをご参照ください。 利用者の入力中のセッション準備プラクティス 対話型エージェントでは、環境をどのように起動するかに加え、いつ起動を始めるかも、利用者の待ち時間に関わります。AWS ブログでは、利用者がチャットを開いた時点など、 入力欄に文字を入力する前からセッションを開始する工夫 を紹介しています。チャットで挨拶を表示している間や、利用者が最初の質問を入力している間に環境を準備する warm-up の考え方です。   図 4. AgentCore Runtime V2 の起動方式と、入力前にセッションを準備する一般的な設計例。 図 4 のスナップショット取得は、AgentCore Runtime の作成・更新に伴う環境準備です。入力前のセッション開始は、アプリケーションが利用者の操作に合わせて準備を始める設計です。V2 が準備済みの環境を復元する仕組みと、その復元を入力中に進める工夫を組み合わせることで、質問送信後に起動完了を待つ時間を短くすることを狙えます。 会話文脈の保持、処理の観測、回答の評価 今回のサポートチャットでは、AgentCore Runtime 上の Strands Agents による検索・回答を中心に、AgentCore Memory による会話文脈の保持、AgentCore Observability による処理の観測、AgentCore Evaluations による回帰テストでの評価の試験利用を組み合わせています。これらの機能の関係を図 5 に示します。 図 5. AgentCore Runtime を中心に会話文脈の保持、処理の観測、回帰テストでの評価の試験利用を組み合わせるサポートチャットの AgentCore 機能。 AgentCore Memory は、同一セッション内の短期的な会話文脈の保持に使っています。使い方に関する質問の後で利用環境などの条件が補足されたとき、前のやり取りと合わせて入力を扱うためです。保持した会話情報のうち、どの情報を今回の質問に結び付けるかを決め、追加質問を解釈する処理はアプリケーションで設計しています。 AgentCore Observability のトレースとタイムラインは、導入後の処理確認に役立ちました。コンテナの初期化とエージェントの処理を切り分け、どこに時間がかかっているかを確認できました。翻訳、検索、文書取得、モデル呼び出しを含む総応答時間に加えて処理の内訳を見ることで、実行環境の起動と検索・回答側のどちらを調べるべきかを判断する手掛かりを得られます。 回答品質については、AgentCore Evaluations を回帰テストに試験利用しました。 AgentCore Evaluations は、エージェントやツールのタスク実行、例外的な入力への対応、出力の信頼性などを評価するサービスですが、今回紹介する活用範囲はこの試験利用です。 運用中の回答品質を継続的に確認する機能として、 オンライン評価 も利用できます。評価対象のログと評価器を設定すると、 Amazon CloudWatch に出力されるエージェントの実行トレースを基に自動で評価します。 評価結果 は Amazon CloudWatch に保存され、スコアの推移や個々の評価内容を確認できます。 図 5 の AgentCore Observability から AgentCore Evaluations への矢印には、このオンライン評価で使うトレースの流れを示しています。開発者は評価結果を確認し、コードやプロンプトを見直して再デプロイします。開発者から AgentCore Runtime への破線はこの改善の流れを表し、利用者への応答経路と分けて示しています。 同様の取り組みを始める際は、代表的な質問、回答に必要な参照情報、期待する回答を用意し、構成変更の前後で確かめる方法を提案します。点数だけでなく、マニュアルの内容に沿っているか、追加条件を踏まえているかを確認し、サービスの目的に合う評価基準を具体化していきます。結果を基に開発者がコードやプロンプトなどを見直し、再デプロイ後に同じ質問で確かめる流れを、開発・運用の改善として取り入れられます。 この改善サイクルをさらに発展させる手段として、 AgentCore Optimization の活用も考えられます。実行トレースと評価器を基に、システムプロンプトやツール説明の改善案を生成し、その候補をテスト用データセットで評価する流れを組めます。開発者が評価結果を確認して変更を採用することで、回答品質の確認から、改善案の検討と検証へと取り組みを広げられます。 プロジェクトの学びと、AgentCore Harness から始める実践 試作を通じた独自処理の明確化 本プロジェクトでは、 Amazon Bedrock Agents (Classic) で土台を作り、要件が具体化した段階で AgentCore Runtime 上の Strands Agents を使って処理を作り込みました。 Bedrock Agents でまず動くエージェントを作ることで、実際の動作を基に要件を考え、その後、独自のワークフローを実装できました。移行を通じて、Bedrock Agents が内部で行っていた推論を省く工夫などへの理解も深まり、設計の参考になりました。 この経験から得られたのは、まず動くエージェントで要件を確かめ、必要になった部分を独自実装へ広げていく進め方です。 Bedrock Agents (Classic) は 2026 年 7 月 30 日から新規のお客様への提供を終了 しており、既存のお客様向けに継続提供されています。これから同じように試作を始める際は、AWS が推奨する AgentCore Harness を入口として検討できます。 AgentCore Harness による試作とコードへの Export AgentCore Harness は、Strands Agents を基にしたマネージドなエージェントループを提供します。モデル、システムプロンプト、ツールなどを設定すると、AgentCore がループを実行します。ここからは、今回の AI チャットの採用構成とは区別して、試作の進め方を紹介します。 AgentCore Harness の標準構成と、必要に応じて追加する機能を図 6 に示します。 図 6. AgentCore Harness が標準で備える構成と追加設定。 AgentCore Runtime 内の Strands ベースのループが、 選択したモデル / プロバイダー を呼び出します。 セッションの実行環境 には分離された microVM と専用のファイルシステムがあり、Python / bash を備えています。 組み込みツール の shell と file_operations は標準で利用できます。 標準で用意される AgentCore Memory は短期イベントと長期記憶を扱い、 AgentCore Observability は呼び出しごとのトレース・ログ・メトリクスを自動生成します。Memory の自動作成・取得やトレースの閲覧に関する設定条件は、実践補足で説明します。 AgentCore Gateway 、外部 MCP サーバー、 AgentCore Browser 、 AgentCore Code Interpreter は、ツールの接続設定で追加する機能です。 Skills も必要に応じて設定します。 同様のチャットを試作する際は、対象言語の根拠本文に沿って答えられるか、同じセッションで追加された条件を踏まえられるかを確かめます。そのうえで、検索や本文取得などの独自処理を、どこまで自ら内製・運用する必要があるかを検討します。 AgentCore Harness の設定だけで要件を満たす場合は、そのまま利用を続けられます。より細かなワークフロー制御が必要になったら、 設定を Export し、編集可能なエージェントコードとして引き継ぐ方法があります。 AgentCore Harness 自体も Runtime 内で動く ため、これはマネージドなループから、開発者が管理するコードへ実装を引き継ぐ選択です。 AgentCore Harness の詳細やワークショップはそれぞれ以下の資料をご参照ください。 Amazon Bedrock AgentCore harness is now generally available: Go from idea to production-grade agent in minutes Getting Started with Amazon Bedrock AgentCore 今後の展開 今後は、この多言語サポートチャットの利用者数を増やしていくことを目指しています。検索基盤については、 Amazon Bedrock Managed Knowledge Base へ移す開発を進めています。 移行先では、取り込み・保存・索引化・検索の基盤を Amazon Bedrock が管理するほか、取り込む情報や検索方法を広げる機能を利用できます。 Advanced Indexing を有効にすると、文書内の図や画像なども取り込み対象にできます。 Agentic Retrieval では、質問に応じて検索計画を立て、複数回の検索や必要に応じた文書全体の取得を行う処理をサービス側に任せられます。 また、 AgentCore Gateway との連携 では、接続先と権限を設定することで、ナレッジベースの検索機能を MCP ツールとしてエージェントから利用できます。検索機能を独自にツール化する実装を減らせることも、エージェントとの連携を進めるうえでのメリットです。移行後も、取り込む文書を英語のマニュアルに絞る方針は継続する予定です。 まとめ 今回の AI チャットでは、実行環境や会話情報の保持に AgentCore の共通機能を利用し、AgentCore Runtime V2 上の Strands Agents で多言語の検索・回答を実装しました。英語の索引から対象言語の本文へたどり着き、その内容を根拠に答える流れは、マニュアルの持ち方に合わせて設計しています。共通基盤に任せる部分を定めることで、利用場面に応じた独自のロジックに注力できました。 AgentCore Memory で同一セッションの会話文脈を保持し、アプリケーション側で追加質問の解釈に利用しています。AgentCore Observability では、初期化とエージェント処理を切り分け、待ち時間の内訳を確認できました。AgentCore Evaluations は、構成変更後も回答品質が維持されているかを確認する回帰テストに試験利用しました。 これから同様のチャットを開発する際は、AgentCore Harness で試作し、代表的な質問や追加質問への回答を、期待する内容やマニュアル本文と照らして確認できます。応答時間も測りながら要件を具体化し、より細かな処理の制御が必要になったら、Strands Agents のコードへ Export して AgentCore Runtime 上で作り込む方法も選べます。 著者について 成本 海斗 / Kaito Narimoto AWS Japan の AI Specialist Solutions Architect として、日本における Amazon Bedrock AgentCore をリードしており、エージェント開発・設計、エージェント基盤、ハーネスエンジニアリングを中心にお客様のビジネス上の課題を技術面から支援しております。AWS 社内業務の効率化に向けたマルチエージェントの設計や開発に携わりました。 鯨田 連也 / Renya Kujirada AWS Japan の AI Specialist Solutions Architect として、日本における Amazon Bedrock AgentCore の技術支援をリードしており、業界を問わず様々なお客様とともに、Agent の開発、Agent 基盤の設計、LLM のファインチューニングに取り組んでいます。AWS 入社前は、データサイエンティストとして深層学習モデルの開発や Agent を活用したソリューションの構築に従事していました。2025年度に Japan AWS Top Engineer および AWS Community Builder に選出。 木村 直登 / Naoto Kimura AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本記事は 2026 年 11 月 9 日 に公開された「 Amazon Athena introduces system tables for query execution observability 」を翻訳したものです。 多くの方が Amazon Athena でデータレイク全体に SQL クエリを実行し、対話型の分析から定期実行のレポートパイプラインまで、幅広い処理に活用しています。ただし、ワークロードの状況を十分に把握できていないことも少なくありません。ユーザー、ワークグループ、クエリが増えて Athena の利用が広がるにつれ、どのクエリのコストが高いのか、誰が実行したのか、パフォーマンスが変化していないか、コストをどう配分するのかを知る必要が出てきます。 Athena でシステムテーブルが使えるようになりました。第一弾として本日提供を開始する query_executions は、利用状況のデータを自動で記録し、オブザーバビリティ、利用状況の分析、監査といったユースケースに使えます。システムテーブルを有効にすると、すべてのワークグループで、クエリの完了から数分以内に利用状況のデータを参照できるようになります。Athena は利用状況のデータを、 Amazon Simple Storage Service (Amazon S3) の機能である Amazon S3 Tables に Apache Iceberg テーブルとして保存します。保持期間は設定で変更できます。スキーマの定義、パーティショニング、コンパクション、スナップショットのメンテナンスを含むテーブルの管理は AWS が担うので、Athena から直接クエリするだけで済みます。テーブルを管理する運用の負担はかかりません。 Athena の利用状況のデータは、 GetQueryExecution などの API、 Amazon CloudWatch のメトリクス、 AWS CloudTrail のログから取得できます。今回のリリースで、利用状況のデータを S3 テーブルとしても使えるようになりました。独自のパイプラインを構築・保守しなくても、直接検索、フィルタリング、集計、結合ができます。プラットフォームチームは、独自の抽出、変換、ロード (ETL) パイプラインを用意しなくても、ワークグループ別、ユーザー別、テーブル別にスキャンしたデータ量を示すコスト配分のダッシュボードを構築できます。さらに、 AWS Agent Toolkit には、システムテーブルをクエリして利用パターンや最適化の提案を導き出すスキルが用意されています。Athena はデータをオープンな Apache Iceberg 形式で保存するため、 DuckDB 、 Amazon Redshift などの Iceberg 互換エンジンからもクエリできます。 本記事では、システムテーブルとは何か、どう始めるのか、そして何より、システムテーブルで何ができるのかを紹介します。 課題: 規模が拡大した Athena ワークロードの把握 これまで、規模の大きなクエリワークロードを把握するには、クエリそのものを実行するよりも多くの手間がかかっていました。よくある次のような疑問を考えてみてください。 コストの配分: 今月、最もコストの高いクエリを実行したのはどのチームか？ パフォーマンス分析: 遅くなっているクエリや、普段より多くのデータをスキャンしているクエリはないか？ 監査とコンプライアンス: 前四半期に特定のテーブルに対してクエリを実行したのは誰か？ 運用状況の把握: 本番ワークロードのエラー率はどのくらいか？ 利用パターン: 日ごとのクエリ数はどのくらいで、ピークの時間帯はいつか？ 以前は、どの疑問に答えるにも、Athena API、Amazon CloudWatch のメトリクス、AWS CloudTrail のログを自分でつなぎ合わせるか、クエリ履歴のスナップショットを取ってクエリできる形式で保存する独自のパイプラインを構築する必要がありました。つまり、分析パイプラインを分析するために、分析パイプラインを構築していたわけです。システムテーブルは、差別化につながらない重労働をなくします。 システムテーブルとは 最初のシステムテーブルである query_executions は、すべてのワークグループで完了した (成功したか、エラーで終了した) クエリ 1 件ごとに 1 行を記録します。記録する内容は次のとおりです。 クエリの識別情報: クエリ実行 ID、クエリ文字列、送信時刻。 コンテキスト: ワークグループ、カタログ、データベース、テーブル。 ユーザーアイデンティティ: クエリを送信したユーザー。 パフォーマンス: 合計実行時間、計画時間、キュー時間など。 リソースの消費量: スキャンしたバイト数、データ処理ユニット (DPU) 数。 結果: 実行状態 (成功、失敗、キャンセル)、エラーの詳細情報。 クエリに関する情報がすべて 1 か所にそろうと、Athena ワークロードの捉え方が変わります。コンソールや API でクエリを 1 件ずつ調べるのではなく、クエリ履歴全体を対象に問いを立てられます。ほかの分析用データセットと同じように、集計、フィルタリング、傾向の分析、結合ができます。ダッシュボードを構築したり、定期的なレポートを設定したり、状況を把握したいときにアドホッククエリを実行したりできます。 始め方 システムテーブルは、数ステップで有効にできます。 Athena コンソール を開きます。 左側のナビゲーションペインで、 Administration の下にある System tables を選択します。 Configure を選択し、 Enable system tables for all your current and future resources をオンにします。 (オプション) Data encryption を展開し、 AWS Key Management Service (AWS KMS) のキーを選択します。キーを選択しない場合、Athena は Amazon S3 マネージドキー (SSE-S3) を使います。 Save を選択します。Athena はアカウント内に、サービスが管理する Amazon S3 のテーブルバケットをプロビジョニングし、すべてのワークグループでクエリ実行の記録を始めます。 有効にすると、Athena は新しいクエリの実行を自動で記録します。システムテーブルには、ほかの Athena テーブルと同じように、コンソールのクエリエディタ、API や SDK、 JDBC ドライバーや ODBC ドライバーからアクセスできます。 AI エージェントでシステムテーブルからインサイトを得る 自然言語で質問して、システムテーブルを探索することもできます。システムテーブルは AWS Glue Data Catalog の標準的なテーブルなので、 Kiro や Claude Code など、 Model Context Protocol (MCP) に対応した AI エージェントから参照できます。接続先は AWS MCP Server です。AWS MCP Server はマネージド型の MCP サーバーで、既存の AWS Identity and Access Management (IAM) の認証情報を使って、エージェントから AWS にアクセスできます。 安定した結果を得るには、AWS が AWS Agent Toolkit で公開している、Athena システムテーブル向けのオープンソースの Agent Skill を使ってください。スキルは、エージェントが機能をうまく使えるように教える指示と検証済みの例をまとめたパッケージで、バージョン管理されています。Athena システムテーブル向けのスキルには、システムテーブルのスキーマとクエリ例のライブラリが含まれています。パーティション列で絞り込む、テーブルを読み取り専用として扱うといった、クエリを正しく、コスト効率よく保つための決まりごとも組み込まれています。スキルを読み込んだエージェントは、正しい列名で、パーティションプルーニングによってスキャン量を抑えた SQL を書きます。自由形式のプロンプトのように、結果が予測しにくくなることはありません。スキルはオープンソースで、今後追加される新しいシステムテーブルにも対応するよう設計されています。 エージェントは質問を SQL に変換して Athena で実行し、答えを返します。会話を続けて結果を絞り込んだり、傾向をグラフにしたりもできます。 コストの配分: 「先月スキャンしたデータ量が最も多かったワークグループはどれですか？先々月と比べてどうですか？」 監査とコンプライアンス: 「前四半期に customer_orders テーブルにアクセスしたクエリをすべて、実行したユーザーとあわせて一覧にしてください。」 運用状況の把握: 「ユーザーの構文エラーを除くと、今週の本番ワークグループのエラー率はどのくらいですか？」 エージェントが使う IAM の認証情報は、最小権限に絞ってください。Athena、AWS Glue、システムテーブルへの読み取り専用のアクセス権があれば十分です。質問するだけなら書き込み権限は必要ありません。AWS MCP Server は IAM ベースのアクセス制御を使い、すべての API 呼び出しを CloudTrail に記録するので、エージェントがユーザーに代わって実行した操作の監査証跡がすべて残ります。 システムテーブルでできること 以降のセクションでは、特によくあるユースケースを、それぞれの代表的なクエリとあわせて紹介します。ここで紹介するクエリは出発点です。すぐに実行できるクエリをさらに多く知りたい場合は、 Athena システムテーブル向けの Agent Skill のクエリ例を参照するか、スキルを使ってエージェントにクエリを書かせてください。 利用パターン: Athena の使われ方を把握する システムテーブルを使うと、組織全体で Athena がどう使われているかの全体像をつかめます。利用パターンは多くのチームが最初に調べる項目で、ワークロードを理解するうえでの基準になります。 日ごとのクエリ数 クエリ数の推移を追跡します (‘day’ を ‘hour’ に置き換えると、ピークの時間帯がわかります)。 SELECT DATE_TRUNC('day', submission_date_time) AS day, COUNT(*) AS query_count FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY GROUP BY 1 ORDER BY 1 ワークグループ別の利用状況の推移 SELECT DATE_TRUNC('week', submission_date_time) AS week, work_group_name, COUNT(*) AS query_count, COUNT(DISTINCT principal_arn) AS distinct_users FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '90' DAY GROUP BY 1, 2 ORDER BY 1, 2 クエリサイズの分布 SELECT CASE WHEN data_scanned_size = 0 THEN '0 bytes' WHEN data_scanned_size < 1048576 THEN '<1 MB' WHEN data_scanned_size < 10485760 THEN '1-10 MB' WHEN data_scanned_size < 104857600 THEN '10-100 MB' WHEN data_scanned_size < 1073741824 THEN '100 MB-1 GB' WHEN data_scanned_size < 10737418240 THEN '1-10 GB' WHEN data_scanned_size < 107374182400 THEN '10-100 GB' ELSE '>100 GB' END AS scan_bucket, COUNT(*) AS query_count, ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER (), 2) AS percent_of_query_count FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY AND state_enum = 'SUCCEEDED' GROUP BY 1 ORDER BY MIN(data_scanned_size) コストの配分: チームやユーザーごとに費用を割り当てる スキャンしたデータ量に応じて課金される Athena の料金モデルでは、スキャンしたバイト数をユーザーやワークグループに割り当てれば、そのままコストの配分になります。システムテーブルを使えば、独自の計測パイプラインを立ち上げなくても、チャージバックやショーバックのレポートを作成できます。コストを見積もるには、リージョンごとの 1 TB あたりの料金 を確認するか、 AWS Price List API で最新の料金をプログラムからダウンロードしてください。 請求期間中にユーザーがスキャンしたデータ量の合計 SELECT work_group_name, region_name, ROUND(SUM(data_scanned_size) / POWER(1024.0, 4), 3) AS total_tb_scanned, COUNT(*) AS query_count, ROUND(SUM(data_scanned_size) * 100.0 / SUM(SUM(data_scanned_size)) OVER (), 3) AS percent_of_total_tb_scanned FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY AND state_enum = 'SUCCEEDED' GROUP BY 1, 2 ORDER BY 1, 2 work_group_name を principal_arn に変えると、同じレポートをユーザー別に分けられます。 パフォーマンス分析: パフォーマンスの問題を見つけて解決する パフォーマンスの傾向を把握すれば、劣化を早期に捉え、最も重要なクエリを最適化できます。 過去 7 日間で最も遅いクエリを見つける SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, total_execution_duration / 1000.0 AS execution_seconds, data_scanned_size / POWER(1024, 3) AS data_scanned_gb, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY AND state_enum = 'SUCCEEDED' ORDER BY total_execution_duration DESC LIMIT 50 ワークロードのパフォーマンス問題を時系列で検出する ワークグループ内の実行時間の集計値を今週と先週で比べ、ユーザーが気づく問題になる前に傾向をつかみます。 WITH weekly_stats AS ( SELECT work_group_name, IF(submission_date_time >= DATE_TRUNC('week', CURRENT_DATE), 'this_week', 'last_week') AS period, COUNT(*) AS query_count, AVG(total_execution_duration) AS avg_exec_ms, APPROX_PERCENTILE(total_execution_duration, 0.95) AS p95_exec_ms, SUM(data_scanned_size) AS total_bytes_scanned FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= DATE_TRUNC('week', CURRENT_DATE) - INTERVAL '7' DAY AND state_enum = 'SUCCEEDED' GROUP BY 1, 2 ) SELECT tw.work_group_name, lw.query_count AS last_week_queries, tw.query_count AS this_week_queries, lw.avg_exec_ms / 1000.0 AS last_week_avg_sec, tw.avg_exec_ms / 1000.0 AS this_week_avg_sec, ROUND((tw.avg_exec_ms - lw.avg_exec_ms) * 100.0 / lw.avg_exec_ms, 1) AS avg_pct_change, lw.p95_exec_ms / 1000.0 AS last_week_p95_sec, tw.p95_exec_ms / 1000.0 AS this_week_p95_sec FROM weekly_stats tw JOIN weekly_stats lw ON tw.work_group_name = lw.work_group_name WHERE tw.period = 'this_week' AND lw.period = 'last_week' ORDER BY avg_pct_change DESC キュー時間を分析してキャパシティの逼迫度を把握する SELECT work_group_name, DATE(submission_date_time) AS query_date, COUNT(*) AS query_count, AVG(query_queue_time_duration) / 1000.0 AS avg_queue_sec, APPROX_PERCENTILE(query_queue_time_duration, 0.50) / 1000.0 AS median_queue_sec, APPROX_PERCENTILE(query_queue_time_duration, 0.95) / 1000.0 AS p95_queue_sec, MAX(query_queue_time_duration) / 1000.0 AS max_queue_sec FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '14' DAY GROUP BY work_group_name, DATE(submission_date_time) HAVING AVG(query_queue_time_duration) > 1000 ORDER BY avg_queue_sec DESC スキャンしたデータ量の多いクエリを見つける スキャンするデータ量が最も多いクエリを特定します。スキャン量の多いクエリはコストを押し上げる最大の要因で、最適化 (パーティショニング、述語のプッシュダウン、データ形式の変更) の最有力候補です。 SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, data_scanned_size / POWER(1024, 4) AS data_scanned_tb, total_execution_duration / 1000.0 AS execution_seconds, SUBSTR(query_string, 1, 300) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY AND state_enum = 'SUCCEEDED' ORDER BY data_scanned_size DESC LIMIT 50 ここで紹介したクエリを使えば、プラットフォームチームは Athena をひとつのサービスとして運用できます。サービスレベル目標 (SLO) を定め、傾向を可視化し、何かが変わったときには早めに気づけます。 監査とコンプライアンス: 誰が、いつ、何を実行したかを把握する 規制やセキュリティの要件がある組織では、システムテーブルを、構造化されたクエリ可能な監査証跡として使えます。 特定のユーザーが一定期間に実行したすべてのクエリ SELECT query_execution_id, work_group_name, submission_date_time, state_enum, total_execution_duration / 1000.0 AS execution_seconds, data_scanned_size / POWER(1024, 2) AS data_scanned_mb, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE principal_arn = 'arn:aws:iam::111122223333:user/example-user' -- Replace with target user AND submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY ORDER BY submission_date_time DESC 特定のテーブルにアクセスしたクエリ SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, state_enum, ROUND(data_scanned_size / POWER(1024.0, 3), 3) AS data_scanned_gb, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" CROSS JOIN UNNEST(tables_accessed) AS t(tbl) WHERE tbl.database_name = 'my_database' -- Replace with target database AND tbl.table_name = 'my_table' -- Replace with target table AND submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY ORDER BY submission_date_time DESC Athena はシステムテーブルを Iceberg のデータとしてお客様自身のアカウントに保存し、レコードを書き込めるのは Athena サービスだけです。そのため、システムテーブルは監査に使える信頼性の高いクエリアクティビティの記録になります。保持期間、アクセスポリシー、暗号化はお客様が管理します。 運用監視: エラー率とワークロードの健全性を追跡する システムテーブルを使うと、CloudWatch の集計メトリクスでわかる範囲を超えて、Athena ワークロードの運用状況を可視化できます。データはクエリ単位なので、ユーザーの構文エラーが急増しただけの問題のないケースと、対処が必要なシステムエラーの急増とを区別できます。集計メトリクスでは両者を見分けられません。 ワークグループ別のエラー率 WITH error_stats AS ( SELECT work_group_name, COUNT(*) AS total_queries, COUNT(*) FILTER (WHERE state_enum = 'FAILED' AND error_category_enum = 1) AS system_errors, COUNT(*) FILTER (WHERE state_enum = 'FAILED' AND error_category_enum = 2) AS user_errors FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY GROUP BY work_group_name ) SELECT work_group_name, total_queries, system_errors, ROUND(system_errors * 100.0 / SUM(system_errors) OVER (), 1) AS percent_of_all_system_errors, user_errors, ROUND(user_errors * 100.0 / SUM(user_errors) OVER (), 1) AS percent_of_all_user_errors FROM error_stats 急増の原因を調べるには、失敗したクエリを error_category_enum と error_message でグループ化し、どのエラーがどこに集中しているかを正確に確認します。 リソースを使い果たしたクエリを特定する リソースを使い果たしたクエリは最適化の有力候補です。パーティショニングの改善、クエリの書き換え、キャパシティの追加が効く可能性があります。 SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, error_message, ROUND(data_scanned_size / POWER(1024.0, 3)) AS data_scanned_gb, ROUND(total_execution_duration / 1000.0, 1) AS execution_seconds, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY AND state_enum = 'FAILED' AND error_message LIKE 'Query exhausted resources%' ORDER BY data_scanned_size DESC キャパシティ予約の最適化 キャパシティ予約 を使っている場合は、プロビジョニングしたキャパシティの使われ方をシステムテーブルで確認できます。Athena が dpu_count 列に値を入れるのは、キャパシティ予約で実行したクエリだけです。そのため、 dpu_count 列には 2 つの役割があり、予約済みのキャパシティで実行したクエリがどれかと、各クエリが消費した DPU 数の両方がわかります。予約が消費した DPU 時間の推移を追えば、予約のサイズが適切かどうかを確認できます。また、前述の実行時間とキュー時間のパターンから、オンデマンドのワークロードがキャパシティ予約に適しているかどうかも判断できます。 キャパシティ予約で実行したクエリが消費した週ごとの DPU 時間 SELECT DATE_TRUNC('week', submission_date_time) AS week, COUNT(*) AS reservation_queries, ROUND(SUM(dpu_count * total_execution_duration / 3600000.0), 1) AS dpu_hours FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '90' DAY AND state_enum = 'SUCCEEDED' AND dpu_count > 0 -- populated only for capacity-reservation queries GROUP BY 1 ORDER BY 1 アーキテクチャとデータモデル Athena のシステムテーブルは、特別な種類の S3 テーブルバケットを使います。通常の S3 テーブルバケットと同じように動作しますが、書き込めるのは AWS のサービスだけです。そのため、データを所有するメリットを得ながら、レコードの完全性も保てます。 お客様がデータを所有 – データはお客様のアカウント内にあり、お客様のキーで暗号化され、お客様のポリシーで管理されます。 不変のレコード – システムテーブルに書き込めるのは Athena だけです。お客様のアカウント内のどの IAM プリンシパルも、個々のレコードを変更・削除できません。 標準的な形式 – Athena、Amazon Redshift、 Amazon EMR 、 Apache Spark 、 Trino など、Iceberg 互換のエンジンであればどれでもデータを読み取れます。 自動メンテナンス – コンパクション、スナップショットの管理、設定した保持期間に基づくデータの有効期限切れの処理は S3 Tables が行います。 Athena は保持期間の既定値を設定しません。S3 Tables でレコードの有効期限を設定するまで、レコードは保持されます。期限は最短 1 日で、上限はありません。データは効率よくスキャンできるようにパーティション分割され、クエリの実行データはバッチで届きます。通常はクエリの完了から数分以内です。パーティション列を確認するには、 DESCRIBE ステートメントを使います。 まとめ Amazon Athena のシステムテーブルを使えば、独自のインフラストラクチャを用意しなくても、クエリワークロードの状況をクエリで可視化できます。チームへのコスト配分、パフォーマンス劣化の調査、コンプライアンスの証跡作成、Athena の使われ方の把握と、目的が何であっても、クエリ 1 本で答えが得られるようになりました。Athena はシステムテーブルを AWS Glue Data Catalog に登録し、オープンな Apache Iceberg 形式でお客様自身のアカウントに保存するため、 Amazon Quick Sight やビジネスインテリジェンス (BI) ツールから直接参照できます。これまでチームが保守してきた独自のパイプラインは不要になります。 まずは Athena コンソールからシステムテーブルを有効にしてください。詳しくは、Amazon Athena ユーザーガイドの「 System Tables 」を参照してください。 著者について Pathik Shah Pathik は、Amazon Web Services のシニアアナリティクスアーキテクトです。2015 年に AWS に入社して以来、ビッグデータ分析を専門とし、お客様が AWS の分析サービスを使ってスケーラブルで堅牢なソリューションを構築できるよう支援しています。 Theo Tolv Theo は、スウェーデンのストックホルムを拠点とするプリンシパルアナリティクスアーキテクトです。キャリアの大半を通じて規模の大小を問わずデータに携わり、2008 年から AWS 上で動くアプリケーションを構築してきました。余暇には電子工作をしたり、スペースオペラを読んだりして過ごしています。 Raza Hafeez Raza は、Amazon Redshift のシニアテクニカルプロダクトマネージャーです。エンタープライズデータウェアハウスの構築と最適化に 15 年以上携わってきました。あらゆる規模のお客様にとって、クラウドでの分析を手軽で費用対効果の高いものにすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

みなさん、こんにちは。ソリューションアーキテクトの水野です。11 月に入り、朝晩はぐっと冷え込むようになってきましたね。工場の現場でも、暖房や空調の切り替えなど冬支度が始まる頃ではないでしょうか。こちらの「 月刊 AWS 製造 」ブログでは、直近 1 カ月に発表された製造関連のブログ・サービスのアップデート・事例や、今後開催予定のイベントなどを毎月お届けしています。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 2025 年 11 月に私が創刊号を担当した本ブログは、今号でちょうど 1 周年を迎えました。日本の製造業のみなさまに、イベントや製造関連の情報を効率よくお届けしたいという思いから始まりましたが、毎月お読みいただいているみなさまのおかげで、1 号も欠かさず 12 号を重ねることができました。ありがとうございます。この 1 年は毎号ちがうソリューションアーキテクトが担当し、それぞれの専門分野の視点から製造業のいまをお伝えしてきました。今号では、まず 1 年間のピックアップトピックを振り返ってみましょう。 創刊 1 周年特集：ピックアップトピックで振り返るこの 1 年 号 ピックアップトピック 2025 年 11 月号（創刊号） re:Invent 2025 開催前の見どころと、日本メンバーが登壇する Chalk Talk 2025 年 12 月号 re:Invent 2025 速報：エージェント AI の強化と Physical AI 関連の展示 2026 年 1 月号 re:Invent 2025 特集：製造業関連のブレイクアウトセッション 2026 年 2 月号 フィジカル AI 2026 年 3 月号 Agentic AI × 製造業 2026 年 4 月号 サプライチェーン管理 2026 年 5 月号 HANNOVER MESSE 2026 と AWS Summit Japan 2026 の見どころ 2026 年 6 月号 AWS Summit Japan 2026：製造業向け展示の見どころ 2026 年 7 月号 AWS Summit Japan 2026：製造ブースの展示レポート 2026 年 8 月号 Amazon のロボティクスに学ぶ、現場で動く AI 2026 年 9 月号 エージェントに現場を任せるとき、境界線をどこに引くか 2026 年 10 月号 Amazon の独自チップ開発と EDA ツールベンダーとのコラボレーションに見る AI ネイティブ設計 並べてみると、この 1 年の流れがよく見えてきます。年明けにはフィジカル AI と Agentic AI が「これから来る潮流」として特集されていました。春から夏にかけては、HANNOVER MESSE や AWS Summit Japan の展示で、そうした技術が実機デモとして形になりました。そして秋には、「どこまで AI に任せるか」「AI を使って設計そのものをどう変えるか」という、現場に入れるための問いへと関心が移っています。今号のピックアップトピックも、この流れの延長線上にあります。 ピックアップトピック: AI エージェントを工程の”関所”として組み込む 10 月に公開された記事を並べてみると、共通点が見えてきます。AI エージェントを工程に「あとから足す補助役」としてではなく、開発やテスト、障害対応といった業務の流れの途中で可否を判断する”関所”として最初から組み込み、その判断を測る仕組みとセットで設計している点です。今月の記事は、実際に組み込んだ例（実装）、作り方の手引き（方法論）、効果の測り方（計測）の 3 つの面から、このテーマを示しています。 実装の面では、Infosys と Corellium による、車載コンピューター（ECU）のファームウェアを検証するパイプラインで、Amazon Bedrock Agents がテスト結果を評価し、PASS／BLOCK を判定する品質ゲートとしてパイプラインに組み込まれています。Daimler Truck の SRE 自動化でも、エージェントが原因分析と修正案の Pull Request 作成までを担い、本番反映の前には必ず人のレビューを挟む設計です。 方法論の面では、「6 つの柱によるウォークスルー」が、自動車工場の部品在庫エージェントを題材に、構築（Build）の次にテスト（Test）の柱を置き、リリース前に越えるべき 3 つのゲートを定義しています。 計測の面では、BMW Group の取り組みが参考になります。いきなり AI を追加で学習させるのではなく、まず AI の答えが合格かどうかを自動で採点する仕組みを作りました。そのうえで、指示の書き方の工夫だけでどこまでできるかを測り、追加学習でどれだけ良くなるかを数字で確かめています。 エージェントに現場の工程を任せるほど、「どこで止めるか」「何をもって合格とするか」を先に決めておくことが重要になります。今月の記事は、その設計図を異なる角度から示しています。 直近で開催予定のイベント 11/18 – 20 EdgeTech+ 2026 一般社団法人 組込みシステム技術協会の主催で、パシフィコ横浜で開催される組込み・エッジ技術の総合展示会です。今年も AWS のソリューションアーキテクトが 2 つの基調講演に登壇します。今月のピックアップトピックで取り上げた「AI エージェントを工程に組み込む」というテーマを、クルマのソフトウェア開発とモノづくりの現場という 2 つの角度から掘り下げる内容です。 11/18 14:05 – 14:50 「 SDVのライフサイクルをクラウド側から支えるAIエージェントと開発環境の最前線 」 クルマとクラウドがつながるのが当たり前になった今、自動車ソフトウェアには開発のスピードと、市場に出たあとも続くセキュリティや法規への対応の両立が求められています。開発・セキュリティ・運用のライフサイクル全体を、AI エージェントと開発環境がクラウド側からどう支えられるのかを整理し、今の開発を止めずに小さく始めるための入口も紹介します。今月ご紹介する ECU 検証パイプラインの記事とあわせて聞くと、より具体的なイメージがつかめるはずです。 11/19 10:15 – 11:00 「 Physical AI × Agentic AI で実現する次世代モノづくり 〜The AI-Powered Product Journey〜 」 製造業の AI 活用では、パイロットから本番へどう広げるかが課題になっています。周囲の環境を認識して自律的に動く「Physical AI」と、複雑なワークフローを自ら実行する「Agentic AI」を組み合わせ、設計から製造、検査、配送までを変えていく自律工場のアーキテクチャとアプローチを紹介します。工場内物流や現場での AI エージェント活用に取り組んでいる方におすすめです。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されており、今月ご紹介したエージェントの評価や本番運用に関するテーマも、Amazon Bedrock AgentCore 関連のセッションで多く扱われます。今年も現地から速報でお届けする「 AWS Black Belt Online Seminar 2026 年 AWS re:Invent 速報 」を 12/4 開催します。re:Invent 2026 の全体像を効率よくキャッチアップいただける内容になっております。また後日公開されるオンデマンドの「 Best of AWS re:Invent 」で主要な発表とセッションを視聴できます。 製造関連ブログのご紹介 10/12 Automating incident resolution with a multi-agent self-healing SRE solution on AWS Daimler Truck が AWS パートナーの CGI と構築した、アフターセールスポータルの障害対応を自動化した事例です。Amazon Bedrock AgentCore 上のエージェントが原因分析から修正案の Pull Request 作成までを行い、デプロイ前には必ず開発者が承認します。1 件あたり 2〜3 時間かかっていた対応が約 15 分になりました。多数のシステムの運用負荷を下げたい情報システム部門の方におすすめです。 10/13 From chaos to control: Transforming intralogistics using SYNAOS on AWS メーカーごとに管制システムが分かれた AGV・AMR を、SYNAOS の Intralogistics Platform で一元的に管制する仕組みを紹介しています。VDA 5050 で 80 社以上のロボットに対応し、MES・WMS・ERP からの搬送要求や、ゲート・信号などの設備もまとめて扱えます。複数メーカーのロボットを導入している生産技術・物流部門の方に役立つ内容です。 10/14 AWS で本番 AI エージェントを構築する: 6 つの柱によるウォークスルー 先月号で英語版をご紹介した記事の日本語訳です。自動車工場の部品在庫エージェントを題材に、エージェントを本番に出すまでの 6 つの柱（構築・テスト・実行・セキュリティ・観測・ガバナンス）を解説しています。日本語で社内に共有しやすくなりました。 10/26 AI-enabled ECU validation on AWS using Corellium Atlas virtual ECUs ECU（電子制御ユニット：ライトやブレーキなどを制御する車載コンピューター）の実機待ちで検証が滞る課題に対し、Infosys と Corellium が実機と同じファームウェアをクラウド上の仮想 ECU で動かすパイプラインを構築しました。最後の工程では Amazon Bedrock Agents が合否を判定し、不合格なら原因分析付きのチケットを自動で起票します。SDV 開発で検証の並列化を進めたい組み込みソフトウェアチームの参考になります。 10/29 How BMW builds toward Industry AI on Amazon SageMaker AI BMW Group が、社内のエンジニアリング業務に特化した AI を Amazon SageMaker AI 上で育てている事例です。用途ごとの LoRA アダプターを 1 つのエンドポイントで提供し、類似インシデントの照合では、プロンプトだけの場合の F1 スコア 47% に対し、ファインチューニング後は 70% に達しました。ドメイン特化モデルへの投資を判断する前に、何を測るべきかを考えるうえで参考になります。 フィジカル AI 関連 10/6 3D Gaussian Splatting in practice: Industry use cases 普通の写真や動画から本物そっくりの 3D データを作る技術「3D Gaussian Splatting」の業界別の使い方です。製造業では、試作品や部品を撮影して数分で 3D 化する例が挙がっています。仕組みはオープンソースで公開されています。 10/19 AWS Physical AI Toolchain を発表 ロボットの AI 開発に必要なデータ収集、シミュレーション、学習、現場への配備を 1 本につなぐ AWS のリファレンス構成です。NVIDIA の Isaac Sim や GR00T などを Terraform でまとめて構築できます。 10/28 Industrial Sensor Data to Operational Intelligence with Archetype AI on AWS 振動や温度などの設備センサーデータを、物理世界を理解する AI モデルで読み解く仕組みです。社名非公開の製造業のお客様は、種類の違うモーターのギア故障を少ないデータで 99% の精度で検知しました。 10/28 AWS &amp; RLWRLD: Building the Workforce of Tomorrow with Physical AI 器用な手作業をこなすロボット向けの基盤モデルを開発する RLWRLD の取り組みです。人手不足が深刻な日本と韓国を中心に、日本では倉庫の小物ピッキングで実証実験が進んでいます。 製造関連の主要なサービスアップデート 10/6 AWS Batch がジョブメトリクスを Amazon CloudWatch に公開 ジョブキューの状態、失敗率、実行時間などを CloudWatch で自動的に確認できるようになりました。解析ジョブやシミュレーションをバッチで流している場合に、待ち時間や失敗の傾向をつかみやすくなります。 10/22 コードの脆弱性に対応する AWS Continuum for code vulnerabilities が一般提供開始 コードの脆弱性を見つけ、実際に悪用できるかを隔離されたサンドボックスで確かめたうえで、ビジネスへの影響が大きい順に並べ、修正パッチを Pull Request として開発者に届けるサービスです。最初は修正案を提案する学習モードで動かし、精度に納得できたら、設定した範囲内で自律的に対応させることもできます。コネクテッド製品のバックエンドや工場とつながる業務システムなど、製造業でも守るべきソフトウェアは増えています。EU サイバーレジリエンス法（CRA）など、市場に出したあとも脆弱性への対応を続けることが求められる流れの中で、限られた人数でセキュリティ対応を回したいチームの助けになります。今月のピックアップトピックと同じく、AI に任せる範囲を段階的に広げる設計になっている点にも注目です。 最後まで読んでいただきありがとうございました。 2 年目の「 月刊 AWS 製造 」ブログも、製造業のみなさまのお役に立つ情報を毎月お届けしていきます。取り上げてほしいテーマなどがあれば、ぜひ担当営業やソリューションアーキテクトまでお寄せください。これから寒さが一段と厳しくなりますので、体調には十分お気をつけください。これからも「 月刊 AWS 製造 」ブログをよろしくお願いいたします。また来月もお会いしましょう！ 著者について 水野 貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは Amazon Connect Decisions (旧AWS Supply Chain) です。趣味は、ドラマや映画のエキストラに参加することです。 <!-- '"` -->

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。戦略プランニング、モデルカスタマイズ、モデル活用の 3 コースがあり、AWS クレジットや技術支援、勉強会、参加企業間のネットワーキングも用意されています。生成 AI の本番活用を検討されている方は、ぜひご確認ください。また、このプログラムの 1 コースである 「フィジカル AI 開発支援プログラム by AWS ジャパン」第 2 期 は、応募締め切りが 11 月 16 日（月）から 11 月 30 日（月）に延長されました。ロボット基盤モデルや VLM、世界モデルなどを AWS 上で開発している方は、この機会にぜひご応募ください。 もう 1 つ、AWS のセキュリティサービスを実際に操作する AWS セキュリティハンズオン を 11 月から毎週オンラインで開催しています。AWS Security Agent (now part of AWS Continuum) によるペネトレーションテスト、Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策、AI エージェントと進めるマイグレーション・モダナイゼーションなどがテーマで、11 月は 11 日、18 日、20 日、25 日、27 日に開催されます。座学とハンズオンの 2 部構成で、環境は AWS 側で用意するので、ブラウザがあれば参加できます。 それでは、11 月 2 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ニッセイ情報テクノロジー株式会社様、AI-DLC と内製 AI エージェントツールで個人保険基幹系システムの保守開発期間を半減へ ニッセイ情報テクノロジー様は、日本生命様の個人保険の販売・新契約から保険金・給付金の支払までを支える基幹系システムを保守・開発している企業です。金融機関の開発の大半は既存システムの保守開発で、ミスが許されない高い品質要求を守りながら、生成 AI を前提に開発プロセスを見直すことが課題でした。そこで、国内リージョンの Amazon Bedrock 経由で Claude を使う内製の AI エージェントツールを Claude Agent SDK で構築し、Excel などの業務ドキュメントを Markdown に整えて Amazon Bedrock Knowledge Bases から検索できるようにしました。2026 年 9 月の 3 日間のワークショップ AI-DLC Unicorn Gym では、この内製ツールの上で AI-DLC Workflows 2.0 を動かし、法人のお客様向け通知帳票の改修という実案件に、日本生命様の所管部門と開発部門が同じチームで取り組んで、7 つの Intent のうち 2 つを終えています。その結果、通常は 6 名で 6 か月ほどかかるこの案件を、4 名で 3 か月ほどで終えられると見込んでいます。現在はウォーターフォールと並走させて残りの Intent を完走できるかを検証する PoC を進めており、今後は企業保険や年金の事業部への展開も計画しているそうです。 ブログ記事「トヨタはいかにして BasisPilot を構築したか – AWS 上の AI アシスト型 SAP 運用プラットフォーム」を公開 Toyota Motor North America が、60 台以上の Amazon EC2 ホスト上で動く 20 の SAP システムを 1 つのダッシュボードで運用する社内プラットフォーム BasisPilot の紹介です。Amazon Bedrock のツール使用で 68 個の型付きツールを呼び出す AI アシスタントを組み込みつつ、RBAC、承認ゲート、許可リストのコマンドで実行はプラットフォーム側が統制し、生成されたテキストがシェルコマンドになることはない設計になっています。実装には Kiro も活用しており、パイロットでは SAP カーネルアップグレードにかかる時間を 1 システムあたり約 2.5 時間から 45 分に短縮しました。基幹システムの運用に AI を安全に組み込みたい方にとって、設計の参考になる記事です。 ブログ記事「Kiro の Auto がモデルカスケードで作業に合ったモデルを使い分ける仕組み」を公開 Kiro の Auto は、効率のよいモデルでセッションを始め、独立したチェックがバックグラウンドで作業を見守り、行き詰まりの兆しがあればより高性能なモデルに引き継ぐ「モデルカスケード」を使っています。DeepSWE v1.1 での社内評価では、カスケードの pass@1 は 69.37% で、高性能なモデル単独の 70.57% とほぼ同じでした。タスクの約 80% は引き継ぎなしで完了しており、Auto がクレジット倍率 1x のまま高い品質を保てる理由がわかります。 ブログ記事「Kiro Crew の Bot のご紹介」を公開 11 月 5 日に一般提供が始まった Kiro Crew の Bot の紹介です。Bot は名前とメモリ、続いていく 1 つのチャットを持つ長く動くエージェントで、ゴールに向けて自分でワーカーのセッションを並行して立ち上げ、結果をチャットに持ち帰ります。Bot ごとにツールや権限、モデル、スケジュールを設定でき、issue の受け付け、CI の監視、コードレビュー、リリース準備といった役割ごとに任せられます。エージェントのセッションを何本も追いかけることに疲れている方におすすめです。 ブログ記事「クレジットプーリングで Kiro のクレジットをチーム全体で共有する」を公開 Kiro Enterprise 向けに始まったクレジットプーリングの解説です。シートあたり月額 20 USD で 500 クレジットが組織の共有プールに追加され、パワーユーザーはライトユーザーが使わない分を使えます。追加クレジットは 1 クレジットあたり 0.04 USD で最長 12 か月繰り越せ、プロファイル、グループ、個人の 3 段階で利用上限を設定できます。請求は AWS アカウント経由なので、Kiro を全社展開する際の予算管理に悩む管理者の方は必読です。 ブログ記事「Kiro が自身のハーネスの性質を Lean で証明する」を公開 Kiro CLI が Amazon Bedrock の Claude Opus 5.5 を使い、Kiro 自身のハーネスにある 26 個の関数を Lean 4 でモデル化して、その性質を証明した取り組みです。96 件の性質のうち 70 件を証明し、18 件はモデル上の反例として見つかったバグを実際のコードで再現しました。モデルと実コードを約 10 万ケースの差分テストで照らし合わせる手順や、証明の限界も丁寧に書かれており、AI エージェントで形式検証を実務に取り入れたい方に読んでいただきたい内容です。 ブログ記事「【開催報告】フロンティア AI 時代のサイバー攻撃に備える ― 臨時開催 AWS セキュリティセミナー」を公開 10 月 23 日と 30 日に開催したセミナーの報告です。AI で脆弱性の発見が速くなり、公表から修正までの猶予が短くなっている状況を整理したうえで、AWS WAF による入り口の防御、Amazon Inspector による脆弱性の把握、Amazon Bedrock のフロンティアモデルや AWS Security Agent によるアプリケーションの脆弱性の発見、マネージドサービスの活用という 4 つの対策を紹介しています。何から手を付けるべきかを整理したいセキュリティ担当の方に役立ちます。 ブログ記事「AI ガードレールによるコンタクトセンターでの責任ある AI の実装」を公開 Amazon Connect Customer にネイティブに組み込まれた AI ガードレールを、AWS の責任ある AI の 8 つの側面に沿って解説しています。プロンプト攻撃の検出、コンテンツフィルター、拒否トピック、ワードフィルター、機密情報（PII）フィルター、コンテキストグラウンディングチェック、ブロック時メッセージの 7 つの機能と、コンソールでの設定手順まで紹介されています。コンタクトセンターに AI エージェントを導入する際のガバナンス設計の参考になります。 ブログ記事「re:Invent 2026 で AI 時代のオブザーバビリティを学ぶ」を公開 re:Invent 2026 の Monitoring and Observability トラックの 25 セッションを紹介しています。本番の AI エージェントの計装やトレース、評価駆動のオブザーバビリティ、Claude Code などのコーディングエージェントのテレメトリを Amazon CloudWatch の OTLP エンドポイントで集める方法、CloudWatch Omni によるマルチクラウドの根本原因分析など、AI エージェントの運用に関するセッションが並んでいます。現地に参加される方はスケジュール作りにご活用ください。 サービスアップデート Moonshot AI の Kimi K3.1 Pro (Highspeed) が Amazon Bedrock で利用可能に Moonshot AI のオープンウェイトモデル Kimi K3.1 Pro が Amazon Bedrock に加わりました。100 万トークンのコンテキストを持つネイティブなマルチモーダルのエージェント向けモデルで、Moonshot AI によると同社で最も高性能な 3 兆パラメータ級のモデルです。Highspeed 版は秒間の出力トークン数が多く、コーディングや文書処理といったエージェントのユースケースで素早く応答します。明示的なプロンプトキャッシュにも対応しており、クロスリージョン推論で Amazon Bedrock が使えるすべてのリージョンから利用できます。 Amazon Bedrock AgentCore の Web Answer が一般提供開始 自然言語の質問に対して、Web の最新情報をもとにまとめ、引用を付けた回答を 1 回のツール呼び出しで返すマネージドツールです。6 月に登場した Web Search を発展させたもので、検索、取得、要約、引用のパイプラインを自前で作る必要がなくなります。Web Answer 自身が検索を計画して並列に実行し、ドメインの許可・拒否リストや公開日のフィルターで調べる範囲を絞ることもできます。AgentCore Gateway のターゲットとして MCP で呼び出し、IAM で認証します。米国東部（バージニア北部）で利用でき、料金はツール呼び出し単位です。 コンソールの Amazon Q Developer が「AWS assistant」に名称変更 AWS マネジメントコンソールとコンソールモバイルアプリの Amazon Q Developer が、AWS assistant という名前になりました。アカウントの状況を踏まえたガイダンスやアクションはそのままで、何をする製品かが名前から伝わるようになります。AWS assistant は現在無料で提供されており、既存の Amazon Q Developer Pro の契約者は Pro Tier の機能を引き続き使えます。 Amazon Connect Customer のフローから MCP ツールを呼び出せるように Amazon Connect Customer のカスタマーエクスペリエンスフローに新しい「外部ツール」ブロックが加わり、Amazon Bedrock AgentCore Gateway 経由で MCP ツールを呼び出せるようになりました。カスタムの Lambda 関数を書かずに、AI エージェントで使っているツールをフローでも再利用して、CRM のケース履歴や取引の詳細などを取得できます。東京リージョンでも利用できます。 Amazon Textract が東京リージョンで利用可能に スキャンした文書からテキストや手書き文字、データを抽出する Amazon Textract が、アジアパシフィック（東京）と欧州（チューリッヒ）で使えるようになりました。国内リージョンで文書処理のパイプラインを組みたい方に嬉しいアップデートです。テキスト検出とドキュメント分析の API に対応しており、AnalyzeExpense、AnalyzeId、AnalyzeLending とカスタムクエリ（アダプター）は現時点では対象外です。 Amazon Textract のテキスト検出モデルが更新、日本語を含む 40 以上の言語に対応 DetectDocumentText と AnalyzeDocument の API で使われるテキスト検出モデルが更新され、日本語を含む 40 以上の言語に対応しました。長い単語や手書き文字の認識が向上し、結合セルや回転・ゆがんだ表を含む多言語の表抽出も高精度になっています。API のスキーマは変わらず、既存のアプリケーションにも自動で適用されます。 Amazon Quick が Quick Essentials プランを開始 Quick Essentials は、AI チャット、Research、Flows、Apps といった Amazon Quick の機能をまとめて使い始められるプランです。Quick Sight Reader ユーザーは追加のユーザー単位コストなしで Quick Essentials にアップグレードされ、ダッシュボードに自然言語で質問して深掘りしたり、回答をドキュメントやプレゼンテーションに変換したりできます。行レベル・列レベルのセキュリティは回答にも適用され、Quick AI 機能が使えるリージョンで段階的に有効になります。 デスクトップ版 Amazon Quick が Web 版と同じサインイン方法に対応 デスクトップ版 Amazon Quick に、Web 版で使っているサインイン方法でそのままサインインできるようになりました。管理者はコンソールでデスクトップコネクタを一度追加するだけでよく、ID プロバイダーへの OIDC アプリケーションの登録が要らなくなります。IAM Identity Center、IAM フェデレーション、ネイティブの Quick ユーザーで利用でき、デスクトップ版を社内に展開しやすくなりました。 WorkSpaces for AI agents が Linux と Windows 11 に対応 AI エージェントにクラウドデスクトップを使わせる WorkSpaces for AI agents で、Windows Server に加えて Linux と Windows 11 を選べるようになりました。Linux ではエージェントが root 権限でビルドやテスト、スクリプトを実行でき、Windows 11 では日々の業務アプリケーションを操作できます。ネットワーク分離や IAM ベースのアクセスといった制御は Windows Server と同じで、社員が使っている環境のままエージェントに仕事を任せられます。 AWS Transform for mainframe の Reimagine ワークフローが要件カバレッジレポートに対応 z/OS の COBOL や PL/I のモダナイゼーションで、同じデータフィールドに影響するものだけをまとめる、フィールドレベルの精度でビジネス機能を検出できるようになりました。新しい要件カバレッジレポートでは、ソースコードの全行がどう扱われたか、ビジネスルールが元のどの行に対応するか、要件がどのビジネスルールに裏付けられているかを確認できます。Kiro などの IDE でフォワードエンジニアリングに進む前に、要件の漏れを確かめられます。 AWS WAF の AI トラフィック収益化が Stripe での法定通貨の受け取りに対応 AI ボットやエージェントからのアクセスに課金できる AWS WAF の AI traffic monetization が Stripe と連携し、エージェントが支払ったステーブルコインを現地通貨で Stripe の残高に受け取れるようになりました。暗号資産のウォレットを管理しなくても、コンテンツや API へのエージェントのアクセスを収益化できます。Amazon CloudFront で AWS WAF を使っているお客様は追加料金なしで利用でき、標準の AWS WAF と Stripe の手数料がかかります。 AWS GovCloud (US) の Kiro で Claude Haiku 5.5 が利用可能に GovCloud (US) 向けの Kiro IDE と CLI で Claude Haiku 5.5 が使えるようになり、Claude 5.5 の 3 つのモデルがすべてそろいました。Haiku 5.5 は 100 万トークンのコンテキストを持つ Claude 5.5 ファミリーで最速のモデルで、クレジット倍率は 0.06 倍（10 万トークンを超えるリクエストは 0.3 倍）です。長いコンテキストの要約やリクエストのルーティング、レビュー用のサブエージェントなど、大量の処理を素早くこなしたい場面に向いています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

課題 先月、ヨハネスブルグの製造業企業の CIO と話をしました。彼は私の話を途中でさえぎり、こう言いました。「『AI トランスフォーメーション』という言葉はやめてください。今四半期だけで 40 回は聞きました。6 週間後の取締役会までに実際に導入できることを 1 つだけ教えてください。」 こうした声は彼だけではありません。私が話をするどの SAP リーダーも同じことを言います。「AI が業務を変革するはずだということは分かっている。しかし実際にどこから始めればよいのか、そして投資の正当性を問われる前にどうやって価値を示せばよいのか。」 CFO は測定可能な ROI を求めています。チームは、ブロックされた購買発注の夜間バックログ、キューで滞留している通関申告、タイムゾーンをまたいで積み上がるベンダーからの問い合わせに追われています。彼らに必要なのは戦略資料ではありません。数週間で実装でき、次の取締役会で提示できるユースケースが 1 つあればよいのです。 それこそが、このシリーズでお届けするものです。 各ユースケースには、ビジネス上の背景、測定可能な価値、アーキテクチャ、実装手順が含まれます。理論ではなく、AWS 上の SAP 環境に合わせて応用できる実践的なパターンです。 ご自身の課題に最も近いユースケースを選び、チームと共有して、最初に何を構築したいかをぜひお聞かせください。 本シリーズの内容 今後の投稿では、Agentic AI エージェントが SAP ワークフローを自律的に実行する 7 つのユースケースを紹介します。各投稿では 2 つのユースケースを取り上げ、まずビジネス上の背景と価値を説明し、その後に技術的な実装を詳しく解説します。 シリーズの構成は次のとおりです。 ●&nbsp; 本投稿（ブログ 1） : シリーズの紹介、共通アーキテクチャ、そして最初のユースケースである SAP Global Trade Services による貿易申告の自動化 ●&nbsp; ブログ 2 : サプライヤー納品のリアルタイム監視とサプライチェーン途絶の分析 ●&nbsp; &nbsp; ブログ 3 : GRC ユーザー権限付与の自動化と SAP 設定の調査 ●&nbsp; &nbsp; ブログ 4: ベンダー支払い問い合わせへの対応と基盤モデルによる需要予測 各投稿は、ビジネス上の背景、提供される価値、アーキテクチャ概要、実装ウォークスルーという同じ形式で構成されています。 SAP ワークフロー実行の現状 現在、多くの組織における SAP プロセスは次のような制約のもとで運用されています。 ●&nbsp; タイムゾーンへの依存: 購買発注には人によるレビューが必要で、レビュー担当者が不在の間は承認が滞留します。 ●&nbsp; データ整合性の課題: 各地域で手作業により入力されたベンダーマスターデータには、時間とともに不整合が蓄積します。 ●&nbsp; 反復作業におけるスケールの限界: 大量の請求書を手作業で照合すると、その量に比例してエラー率が高まります。 ●&nbsp; 例外処理の遅れ: 失敗した入庫やブロックされたトランザクションは、次に担当者がいる時間帯まで放置されます。 ●&nbsp; バッチ処理に依存した意思決定サイクル: 夜間バッチジョブに依存しているため、業務上の意思決定は数時間前のデータに基づいて行われます。 これらの制約は、各処理ステップに人の関与を必要とするアーキテクチャに本質的に備わったものです。Agentic AI を利用すれば、事前定義されたルールに従うのではなく、ライブの SAP データに基づいて推論する、異なる実行モデルを採用できます。 Agentic AI の動作の仕組み ルールベースの自動化は、事前に定義されたロジック（条件 X を満たしたらアクション Y を実行する）を実行します。この実行モデルは、予測可能で構造化されたシナリオには効果的です。しかし、データ形式が一定でない場合や、事前定義されたルールの範囲外にある状況に応じた判断には、別のアプローチが必要です。 Agentic AI を利用すると、SAP ワークフローに自律的な推論を組み込めます。エージェントは SAP からライブデータを読み取り、現在の状況に基づいて必要なアクションを判断します。そして、手動の承認を待たずにそれらのアクションを自律的に実行します。 エージェントが信頼度のしきい値を下回るシナリオに遭遇した場合は、人のレビュー担当者にエスカレーションします。エスカレーションには、分析したデータとエージェントが推奨するアクションといった完全なコンテキストが含まれます。 たとえば、調達を監視しているエージェントが午前 2 時にブロックされた購買発注を検出したとします。エージェントはベンダーの取引履歴を照会し、支払いブロックをベンダーマスターデータと照合して検証します。その結果に基づいて、ブロックを自動的に解除するか、人によるレビュー用に構造化されたサマリーを作成します。 SAP における Agentic AI のビジネス価値 SAP ランドスケープ全体に Agentic AI エージェントを導入すると、次の 5 つの測定可能なメリットが得られます。 ●&nbsp; 継続的な実行: エージェントは SAP と AWS サービスをまたいで 24 時間 365 日稼働し、プロセス実行からタイムゾーンへの依存をなくします。 ●&nbsp; 統合されたデータ処理: 構造化データ（SAP テーブル、ERP レコード）と非構造化データ（メール、PDF、契約書）の両方を単一のワークフロー内で扱えます。 ●&nbsp; 手作業による介入の削減: これまで人の作業が必要だった定型業務が自動的に実行され、チームの稼働をより複雑な業務に振り向けられます。 ●&nbsp; データ品質の向上: 定期的なレビューの時点ではなく、入力の時点で継続的な自動検証によりエラーを特定して対処します。 ●&nbsp; リアルタイムの意思決定支援: バッチ処理されたスナップショットではなくライブデータに基づいてアクションを実行するため、業務への迅速な対応を支援します。 共通アーキテクチャ 本シリーズのすべてのユースケースは、一貫したアーキテクチャパターンに従っています。この共通基盤により、後続の各ユースケースは既に理解しているコンポーネントの上に構築されます。 アーキテクチャは 4 つのレイヤーで構成されます。 取り込みレイヤー: &nbsp;ユースケースに応じて、複数のソースからワークフローにデータが入ります。Amazon S3 に保存されたドキュメント（PDF、メール）、SAP BTP からのイベント、またはユーザーからの直接のリクエストです。ドキュメント処理が必要な場合は、Amazon Bedrock または Amazon Textract によって構造化フィールドの抽出が行われます。 オーケストレーションレイヤー: エージェントは Amazon Bedrock AgentCore Runtime 上で実行され、Amazon Bedrock API を介してモデルにアクセスします。AgentCore Identity は、ユーザーがエージェントへのアクセス権を持つことを検証し、Okta、Entra ID、Ping などの ID プロバイダー（IdP）を通じてアウトバウンド認証を行います。AWS Lambda がオーケストレーションロジックを処理し、ナレッジベース（RAG）がドメイン固有の参照データを提供します。AgentCore Observability がエージェントワークフロー全体を監視します。 アクションレイヤー: エージェントは OData API を通じて SAP S/4HANA に接続し、双方向のデータアクセスを行います。検証のためにマスターデータを取得し、結果を SAP に書き戻します。通知は、コンテキストのサマリーと信頼度スコアとともに Amazon SNS 経由で配信されます。ヒューマンインザループのレビュー担当者は、SAP への変更を承認する前に、完全なコンテキスト、リスク評価、推奨アクションを受け取ります。 オブザーバビリティレイヤー: AgentCore Observability がエージェントワークフロー全体を監視します。アクティビティは Amazon CloudWatch に記録され、ログとアクティビティレコードは Amazon DynamoDB に保存されます。API レベルのアクティビティは AWS CloudTrail で追跡されます。 セキュリティアーキテクチャ このアーキテクチャでは、すべてのレイヤーにセキュリティ制御を実装しています。 ●&nbsp; &nbsp;通信の暗号化: エージェントと SAP 間の通信には HTTPS を使用します。SAP がサポートしている場合は相互 TLS を適用します。 ●&nbsp; &nbsp;最小権限のアクセス: 各エージェントは、固有のツールとアクションに限定された権限を持つ、専用のスコープ付き AWS Identity and Access Management (IAM) ロールで動作します。マルチエージェントワークフローにおいて、昇格された権限がエージェント間で受け渡されることはありません。 ●&nbsp; &nbsp;データの暗号化: 機密データ（ベンダーの支払い詳細、ユーザー権限レコード）は、保存時には AWS KMS、転送時には TLS を使用して暗号化されます。 ●&nbsp; &nbsp;ヒューマンインザループの制御: 財務記録、コンプライアンス関連データ、または SAP マスターデータを変更するアクションは、実行前に人による確認が必要です。 ●&nbsp; &nbsp;監査証跡: このワークフローにおけるエージェントのアクションは CloudWatch と DynamoDB に記録され、運用監視とコンプライアンスレポートの両方を支援します。 Amazon Bedrock は、お客様のデータを基盤モデルのトレーニングや改善に使用しません。 ユースケース 1: SAP Global Trade Services による貿易申告の自動化 共通アーキテクチャを確認したところで、このセクションでは最初のユースケースを通じてその実践例を紹介します。 ビジネス上の背景 SAP GTS での輸入申告には、サプライヤーのドキュメント（PDF、メール、Excel ファイル）からのデータが必要ですが、これらは形式がまちまちで、時間を問わず届きます。品目コードが欠落していたり、フィールドの内容が曖昧だったりすると、申告を進められません。その結果、次のような事態が発生します。 ●&nbsp; &nbsp;SAP GTS での申告エラーにより、手作業によるレビューサイクルが発生する ●&nbsp; &nbsp;修正が行われる間、貨物が税関で留め置かれる ●&nbsp; &nbsp; 貨物が保留状態にある時間ごとにコストが積み上がる ●&nbsp; &nbsp; 担当者の勤務時間外にドキュメントが届くと処理が遅れる 必要なデータはサプライヤーのドキュメント内に存在します。技術的な課題は、そのデータを抽出し、貿易規制や SAP マスターデータと照合して検証することです。そのうえでエージェントが、手作業なしで継続的に SAP GTS へ書き込みます。 ビジネス価値 貿易申告に Agentic AI エージェントを利用すると、次の 4 つの領域で価値が得られます。 ●&nbsp; 処理スピード: 時間帯に関係なく、サプライヤーのドキュメントが届いた時点で申告が処理されます。標準的な RISE with SAP 環境でのテストでは、処理時間が大幅に短縮されました。午前 2 時に受信したドキュメントも、夜間に人が介入することなく、通常は大幅に短い時間で処理できます。 ●&nbsp; データの正確性: エージェントは、このワークフローで抽出したフィールドを SAP マスターデータと貿易規制に照らして検証します。検証が完了してから SAP GTS に書き込むため、手入力によるエラーを排除できます。 ●&nbsp; コンプライアンスの確保: このワークフロー内のエージェントのすべてのアクションは完全な監査証跡とともに記録されるため、税関からの問い合わせに対して、使用したデータ、その出所、最終判断を下した人物を含む完全な記録で回答できます。 ●&nbsp; 業務の継続性: 貿易コンプライアンスの処理が、タイムゾーンをまたぐ担当者の稼働状況に依存しなくなります。エージェントが定型的な処理量を担い、チームは人の判断を必要とする複雑なケースに集中できます。 アーキテクチャ 次の図は、このユースケースのエンドツーエンドのアーキテクチャを示しています。お客様の AWS アカウントには、取り込み、オーケストレーション、オブザーバビリティのコンポーネントが含まれます。SAP の AWS アカウントには、RISE with SAP VPC 内の SAP S/4HANA が含まれます。 このアーキテクチャは 2 つの AWS アカウントにまたがっています。 お客様の AWS アカウント: ●&nbsp; 取り込み（1–2）: ドキュメントが Amazon S3 に格納され、Amazon Bedrock の LLM が構造化フィールドを抽出します。 ●&nbsp; オーケストレーション（3–6）: AgentCore Runtime が抽出されたデータを受け取ります。AgentCore Identity（4a）がアクセスを検証し、IdP（4b）を通じてアウトバウンド呼び出しを認証します。AgentCore Observability（5）がワークフローを監視します。AWS Lambda（6）がオーケストレーションロジックを管理します。 ●&nbsp; ナレッジと検証（7a–7b）: Lambda は、貿易規制と品目コードについては Amazon Bedrock Knowledge Bases（7a）へ、マスターデータの検証については SAP GTS OData API（7b）へ分岐します。 ●&nbsp; エージェントのアクション（8）: AgentCore Runtime 上の AI エージェントが SAP GTS OData API を呼び出し、貿易申告を作成または更新します。 ●&nbsp; ヒューマンインザループ（9–10）: 信頼度が不十分な場合、Amazon SNS が人のレビュー担当者に通知を送信します。 ●&nbsp; オブザーバビリティ（11）: Amazon CloudWatch、Amazon DynamoDB、AWS CloudTrail がアクション、監査証跡、API アクティビティを記録します。 SAP の AWS アカウント: ●&nbsp; &nbsp; SAP S/4HANA は、Lambda による検証ステップ（7b）と AI エージェントのアクションステップ（8）の両方から OData API 呼び出しを受け取ります。どちらの呼び出しも、RISE with SAP VPC 内のプライベートサブネットから発信されます。 技術的な実装 エージェントは、サプライヤーのドキュメント受信から SAP GTS の貿易申告完了までのワークフロー全体を自動化します。 ステップ 1: ドキュメントの取り込み。 サプライヤーのドキュメント（PDF、メール、Excel ファイル）は、届いた時点で Amazon S3 に保存されます。S3 はエントリーポイントとして機能し、下流のコンポーネントからアクセスできる耐久性の高いストレージを提供します。 ステップ 2: フィールドの抽出。 Amazon Bedrock が大規模言語モデルを使用してドキュメントを処理します。非構造化コンテンツから、品目コード、数量、出荷日、ベンダー情報といった構造化フィールドを抽出します。 ステップ 3: 貿易規制に基づく検証。 エージェントは、貿易規制と品目コードの参照情報を含む Amazon Bedrock Knowledge Bases を照会します。フィールドが不完全または曖昧な場合、エージェントはエスカレーションする前に検索拡張生成（RAG）を使用して解決を試みます。 ステップ 4: SAP マスターデータの検証。 エージェントは SAP GTS OData API を呼び出し、ベンダー ID、品目コード、その他のフィールドが SAP S/4HANA の既存レコードと一致することを確認します。 ステップ 5: 判断と実行。 ·&nbsp; &nbsp;信頼度が十分な場合、エージェントは人の介入なしに OData API を介して申告を SAP GTS に直接書き込みます。 ·&nbsp; &nbsp; 信頼度がしきい値を下回る場合、エージェントは人のレビュー担当者にエスカレーションします。コンテキストのサマリーと信頼度スコアを含む通知を Amazon SNS 経由で送信します。 ステップ 6: ログ記録と監査。 Amazon CloudWatch がアクションとレイテンシーのメトリクスを記録します。Amazon DynamoDB は申告ごとに改ざん不可能な監査証跡を保存し、判断内容、ツール呼び出し、検証結果を記録します。 主な成果 このエージェントは、次の 3 つの具体的な成果をもたらします。 ●&nbsp; &nbsp; 輸入申告における手作業のデータ入力ゼロ ●&nbsp; &nbsp; タイムゾーンをまたいだ 24 時間 365 日の処理により、夜間のバックログが発生しない ●&nbsp; &nbsp; &nbsp;通関期限前のプロアクティブな例外処理。人が対応できる時間的余裕があるうちに、エージェントが完全なコンテキストとともにエスカレーションします 次回の予定 次回の投稿では、次の 2 つのユースケースを取り上げる予定です。 1.&nbsp; インテリジェントな供給サービスモニター: サプライヤーの納品スケジュールをリアルタイムで検証し、各納品の SLA 違反リスクをスコアリングして、問題が倉庫の現場に到達する前に、付加価値を加えた情報を SAP に書き戻すエージェント。 2.&nbsp; サプライチェーン途絶分析エージェント: 外部シグナル（気象イベント、地政学的な変化、物流のボトルネック）を SAP 内の有効な購買発注やサプライヤーデータと関連付け、業務に影響が出る前に途絶リスクを特定するエージェント。 始め方とフィードバックのお願い Amazon Bedrock AgentCore を詳しく知り、SAP 環境向けのエージェント構築を始めるには、ドキュメントをご覧ください: https://docs.aws.amazon.com/bedrock/latest/userguide/agentcore.html エージェントの実装サンプルについては、GitHub リポジトリをご覧ください: https://github.com/aws-samples/agentic-ai-for-sap 次回の投稿では、供給監視と途絶分析を取り上げる予定です。どの SAP ワークフローの組み合わせがご自身の環境に最も関連があるか、コメントでお知らせください。 ●&nbsp; &nbsp; GRC アクセスの自動化 + SAP 設定の調査: 職務分掌チェックを伴うユーザー権限申請の自動化と、自然言語を使った SPRO 階層のナビゲーションおよびサポートされている設定変更の実行。 ●&nbsp; &nbsp; ベンダー支払い問い合わせ + 需要予測: ベンダーからの定型的な支払いに関する質問の自律的な解決と、ライブの SAP データに照らして結果を検証する Amazon Chronos による高度な予測。 お客様の業務にとってどのワークフローが最も重要か、ぜひお聞かせください。このページの「Contact us」リンクから、私たちのチームに直接ご連絡いただけます。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

2026 年 5 月、Amazon は自社のサプライチェーン機能が持つ信頼性、レジリエンス、利便性と、その背後にあるネットワークおよびテクノロジーを、1 つの物流システムと名称のもとに統合しました。それが Amazon Supply Chain Services (ASCS) です。最初は Amazon のために構築され、その後セラーに拡大され、今ではあらゆる企業と販売チャネルで利用できます。 Amazon Multi-Channel Fulfillment (MCF) は、このネットワークの主要な柱です。MCF を使うと、Amazon.com を支えるのと同じフルフィルメントネットワークを利用して、複数の販売チャネルからの注文のピッキング、梱包、出荷を行えます。自社 Web サイト、ソーシャルコマース、サードパーティのマーケットプレイスが対象で、いずれも単一の在庫プールから出荷されます。1 つのネットワークで、複数のチャネルに対応できるのです。Amazon Supply Chain Services – MCF のモットーは「私たちのネットワークは、あなたのネットワーク – インバウンドからラストワンマイルまで」です。SAP on AWS のお客様に対する Amazon の取り組みの次の章として、Amazon Multi-Channel Fulfillment (MCF) と SAP のためのアクセラレーターをご紹介できることを嬉しく思います。 Amazon では、すべての製品に関する意思決定はお客様から始まり、そこから逆算して進められます。2026 年初めには、 Amazon MCF and Buy with Prime Accelerators for SAP S/4HANA をリリースしました。&nbsp;そして今回、ネイティブの MCF 機能を、AWS 上で SAP ECC または SAP S/4 HANA を運用しているお客様にも拡大します。これらのアクセラレーターにより、Amazon の物流ネットワークを活用してビジネスを成長させ、お客様の体験を向上させ、サプライチェーンのレジリエンスを強化できます。 何千もの企業が、最もミッションクリティカルなビジネスプロセスのために SAP on AWS を利用しています。これらの SAP アクセラレーターにより、現在運用しているビジネスプロセスを中断することなく、Amazon のサプライチェーン機能をお客様の SAP 環境に直接取り込めます。 すでに次のようなお客様が取り組んでいます。 Adidas は ミッションクリティカルな SAP ERP を AWS 上で 運用し、Amazon の Buy with Prime を利用して、自社の D2C チャネルに Prime の特典を提供しています。特典には、迅速な無料配送、簡単な返品、24 時間 365 日の購入者サポートが含まれます。マーチャント全体で見ると、Buy with Prime は購入者あたりの収益を平均 16% 向上させており、購入者の 95% が再度利用したいと回答しています。 3M は SAP on AWS を利用して 重要な ERP ワークロードを AWS に 移行しました。また、 Amazon の貨物輸送サービス を利用して、製造拠点から世界中の物流センターへ製品を輸送しています。 SAP で Amazon MCF を活用する方法&nbsp; Amazon MCF と SAP の統合は、AWS 上の既存の SAP システムで動作します。アクセラレーターを使うと、SAP BTP と Amazon の MCF API を利用して、既存の受注管理を Amazon のフルフィルメントシステムに接続できます。ビジネスプロセスはそのままで、初期の実装もシンプルになり、Amazon のフルフィルメントネットワークがバックグラウンドで面倒な作業を担います。 次の概要図は、配送依頼が SAP から Amazon MCF へ流れ、また戻ってくる様子を示しています。 図 1 – Amazon MCF と SAP の統合 既存のワークフローや構成とそのまま連携する、幅広いフルフィルメントのユースケースを利用できます。注文はこれまでとまったく同じように SAP で作成されます。出荷の準備が整った時点で、アクセラレーターがそれを取得して Amazon MCF に送信します。出荷ステータスの変更や配送の更新といった Amazon MCF からのインバウンドイベントは、自動的に SAP に同期されます。この統合は Amazon Simple Queue Service (Amazon SQS) を含む複数の配信パターンをサポートしており、既存のアーキテクチャに合った接続を柔軟に構成できます。その結果、完全なクローズドループが実現します。アクセラレーター経由で送信された注文は Amazon のフルフィルメントネットワークに届き、ステータスの更新は自動的に SAP に戻ります。これにより、お客様の組織全体に次のようなメリットがもたらされます。 運用チーム は、日々のワークフローが SAP の中にとどまるという安心感を得られます。出荷の作成、追跡、完了の方法は何も変わりません IT チーム は、カスタムコードを作成・保守する必要がありません。アクセラレーターは SAP Integration Suite 上ですぐに構成できるパッケージとして提供されます。そのまま利用することも、拡張することも、リファレンス実装として利用することもできます ビジネスリーダーや経営層 は、価値実現までの時間の短縮、統合の総コストの削減、そして大規模な変革を伴わずに Amazon のマルチチャネルフルフィルメントネットワークを活用できる能力を得られます アクセラレーターには SAP Integration Suite が必要です。既存の SAP Integration Suite を利用するか、 AWS Marketplace の SAP Integration Suite をサブスクライブできます。 現在、次のモジュールが利用可能です。 表 1 – SAP と Amazon MCF の統合のためのモジュール 前提条件&nbsp; アクセラレーターをインストールする前に、次の前提条件を満たしていることを確認してください。 EC サイトで注文が行われた際に、EC サイトで生成された注文の詳細を取り込めるよう SAP システムが設定されていること Cloud Integration 機能を備えた SAP BTP Integration Suite をサブスクライブしていること SAP Cloud Connector を構成していること Amazon Selling Partner API の認証情報（クライアント ID、クライアントシークレット、リフレッシュトークン）を構成していること SAP のマスターデータの値を、Amazon Supply Chain カタログ内の対応する SKU と一致させていること 今後の展望: SAP と Amazon MCF をデータの優位性へ&nbsp; AWS for SAP は、さらに大きな可能性、つまり AI エージェントを通じたデータの活用への扉を開きます。サプライチェーンのリーダーが、次のような簡単な質問に答えるために、データをエクスポートしたり、スプレッドシートを作成したり、カスタムレポートを何日も待ったりする必要はないはずです。 注文はどこで滞っているか？ 在庫切れになりそうな SKU はどれか？ 今日は何を出荷したか？ 答えは、記録システムのデータに基づいて、質問 1 つで得られるべきです。次の概要図は、SAP と Amazon MCF のデータを、調査、ビジネスインサイト、自動化に活用する方法を示しています。 &nbsp; &nbsp;図 2 – Amazon Quick – SAP – Amazon MCF の統合 一元的な場所として、 Amazon Quick は専用の Model Context Protocol (MCP) サーバーを通じて各システムに接続します。カスタムのポイントツーポイント統合を構築・保守する代わりに、各システムは同じ標準化された方法で Amazon Quick に接続します。これを実現するのが次の 2 つの MCP コネクターです。 &nbsp;SAP : AWS for SAP MCP Server を通じて接続します。 Amazon Bedrock 上に構築されており、OData サービスを介して SAP データへのセキュアでプロトコルに基づくアクセスを提供します。 &nbsp; Amazon MCF : MCP for SP-API を通じて接続します。Amazon の Selling Partner API の開発者ツールをまとめた単一の npm パッケージです。 その結果、多数のシステムにまたがる 1 つのユーザーインターフェースが実現し、ビジネスインサイトを迅速に得られるようになります。データを移動させる代わりに、チームは自然な言葉で質問し、SAP と Amazon MCF にまたがるデータに基づいて 1 か所から行動できます。AWS for SAP MCP Server の利用を検討しているお客様は、 SAP の Third-Party MCP Access to SAP Solutions を確認してください。 今すぐ始めましょう&nbsp; Amazon Multi-channel Fulfillment と SAP ECC のためのアクセラレーターは、 GitHub からダウンロードできます。Amazon Multi-Channel Fulfillment and Buy with Prime Accelerators for SAP S/4HANA は、 GitHub または SAP Business Accelerator Hub から入手できます。 EC と受注フルフィルメントの機能のモダナイゼーションについて詳しくは、 Amazon Supply Chain Services のページ 、 Amazon の MCF のページ 、 Buy with Prime のページ をご覧ください。AWS と SAP がテクノロジープラットフォームによって AI、データ、アプリケーションの可能性を最大限に引き出す方法については、 SAP on AWS のページ をご覧ください。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

完成品を扱う小売企業は、今日のダイナミックな市場において、利益率を守りながら競争力のある価格を維持するという高まる圧力に直面しています。従来の価格モニタリング手法は、ベンダーごとに異なる製品識別方法や、デジタルプラットフォーム上に存在する膨大な量の価格データを扱う際には力不足です。 複数チャネルで完成品を販売する小売企業は、自社の価格モデルについて十分な情報に基づいた意思決定を行うために、競合の価格戦略を包括的に可視化する必要があります。こうした企業は一般に、時間がかかり、ミスが起きやすく、競争上のポジショニングに必要なリアルタイムのインサイトを提供できない手作業の価格モニタリングプロセスに苦労しています。 自動化された価格追跡機能がなければ、こうした組織は、市場の変化により迅速に対応できる競合にマーケットシェアを奪われるリスクを抱えます。 本ブログ記事では、SAP のマテリアルマスターデータ抽出と生成AIを組み合わせ、SAP 小売業のお客様向けに最適化されたスマートで自動化された価格モニタリングシステムを構築するソリューションをご紹介します。このシステムが SAP から製品情報を取得し、AI エージェントを送り出してオンラインマーケットプレイスの価格やお客様のセンチメントをスキャンし、その結果を SAP に戻してアクションにつなげる仕組みを、最小限の手作業でどのように実現するかをご覧いただけます。アーキテクチャを順を追って説明し、Amazon Bedrock Agents と AWS のサービスがどのようにエージェント型ワークフローを支えるかを解説するとともに、統合・コスト・実装に関する実践的な考慮事項を共有します。これにより、皆さまの組織でこのアプローチを評価できるようになります。 ビジネス価値: 本ソリューションは、価格インテリジェンスの向上と市場対応の迅速化を通じて、小売企業に具体的なメリットをもたらします。組織は一般に、リアルタイムの競合データによって実現される、より優れた価格意思決定を通じて利益率の改善を実感します。システムが自動化されていることで手作業のモニタリング負荷が軽減され、価格担当チームはデータ収集ではなく戦略的な分析に集中できるようになります。 さらに、価格トレンドや地域ごとの差異を特定できる本システムの能力により、小売業者はプロモーション戦略や在庫管理の意思決定を最適化でき、在庫回転率の向上と値下げの削減につながります。 アーキテクチャ: 主要コンポーネント&nbsp; SAP データと AWS の接続&nbsp; エージェントが SAP データを扱えるようにするには、まずそのデータを AWS へ、セキュアかつ SAP のライセンスおよびガバナンスのルールに沿った形で取り込む必要があります。そのための現代的な方法が SAP Business Data Cloud (SAP BDC) であり、SAP データをあちこちにコピーすることなく AWS と共有します。 SAP SAPPHIRE 2026 において、 SAP と AWS は SAP BDC Connect for Amazon Athena を発表しました 。これは SAP Business Data Cloud と Amazon Athena の間の双方向・ゼロコピー統合です。データを抽出して複製するのではなく、チームはセマンティックにリッチな SAP データ製品をその場で、ほぼリアルタイムにクエリできます。データは本来のビジネス上の意味を保持し、SAP のガバナンスに準拠したまま、エージェントがスキャンや分析を行えるように Amazon S3 バケットに配置することも可能です。 このフローは、SAP BDC のデータファブリックである SAP Datasphere を経由して実行されます。ここから、非SAPデータおよびSAPデータをライブで Amazon Athena にフェデレーション（コピーなし）したり、大規模データセットの下流処理のために保存されたコピーが必要な場合には Amazon S3 に書き込んだりできます。 その他の SAP データ抽出オプションとして、OData/CDS ビューを用いた AWS Glue、パートナーツール (BryteFlow、Theobald、Qlik)、SAP ネイティブの SLT/Data Services などがあり、SAP データの抽出が必要なシナリオで利用できます。AWS の SAP Data Integration Guidance および SAP BDC と AWS データソースの統合 をご参照ください。 エージェント型ワークフロー エージェント型ワークフローは、Amazon ECS Fargate を使用してコンテナ化された AI エージェントをデプロイし、Amazon Bedrock の基盤モデルを用いて複数のオンラインマーケットプレイス上の製品価格を自律的に分析します。 ワークフローはどのように動作するのでしょうか。 ステップ 1: BDC データ抽出 ステップ 2: EAN コードと説明を含む製品 CSV ファイルが SapLake S3 バケットにアップロードされ、価格モニタリングワークフローがトリガーされます。 ワークフローの起動 製品情報を含む CSV ファイルが Amazon S3 にアップロードされると、Amazon EventBridge が AWS Step Functions ワークフローをトリガーします。Step Functions のステートマシンが、データ抽出から結果集約まで、価格モニタリングプロセス全体をオーケストレーションします。S3 でのトリガー設定に関する追加情報はこちらをご参照ください。 タスクのディスパッチ ステップ 3: Lambda 関数 (search-and-dispatch.py) が CSV ファイルを処理し、各製品についてインターネット検索を実行し、マーケットプレイス分析のための ECS タスクをディスパッチします。 AWS Step Functions は Map ステート を使用して複数の製品を同時に処理します。マーケットプレイスのレート制限を尊重するため、同時実行数は3エージェントに制御されています。各製品は、対象マーケットプレイスの URL、製品 EAN コード、説明、実行トラッキング ID などの特定の環境変数を伴う個別の ECS Fargate タスクをトリガーします。 エージェントの実行 ステップ 4: ECS Fargate タスクは、Amazon Bedrock と MCP サーバーを使用してコンテナ化された Strands Agents を実行し、複数のオンラインマーケットプレイス上の製品価格を分析します。 各 ECS タスクは、最適なコストパフォーマンスを実現する ARM64 アーキテクチャ上で、2GB メモリと 1 vCPU で構成されたコンテナ化 AI エージェントを実行します。エージェントは Claude、Titan、Nova を含む Amazon Bedrock の基盤 モデルにアクセスでき、包括的なマーケットプレイス分析のために10分の実行タイムアウトが設定されています。 Amazon Strands SDK が AI の推論をオーケストレーションし、Model Context Protocol サーバーが Bedrock モデルと Playwright によるブラウザ自動化を橋渡しします。このアーキテクチャにより、エージェントは異なるマーケットプレイスのレイアウトにわたる複数ステップのナビゲーション戦略を計画し、動的なコンテンツやアンチボット対策に自動的に適応し、複雑なウェブ操作全体を通じてコンテキストを維持しながら AI モデルを用いて価格要素を特定できます。 ステップ 5: エージェントワークフローは、Strands のプランニングと Playwright 実行のための MCP ツールを組み合わせ、従来のウェブスクレイピングを、現代の e コマースプラットフォームの複雑さと変動性に対応できるインテリジェントで適応的な市場調査へと変革します。 ステップ 6: 各エージェントは、リアルタイムのトラッキングと中間処理ステータスの更新のために、価格分析結果を DynamoDB に保存します。 ステップ 7: Lambda 関数 (aggregate-results.py) が、DynamoDB からのすべてのエージェント結果を包括的な価格レポートに統合します。 ステップ 8: 集約された価格分析および市場インテリジェンスレポートは、さらなる分析と SAP 統合のために S3 に保存されます。 インテリジェントな分析プロセス AI エージェントは高度な分析を実行します。 ウェブナビゲーション: ブラウザ自動化が動的コンテンツを処理します 製品マッチング: Bedrock の基盤モデルが EAN コードと説明を用いて一致する製品を特定します 価格抽出: さまざまなマーケットプレイス形式から価格情報を抽出します センチメント分析: 基盤モデルがお客様のレビューや市場でのポジショニングを分析します 結果の保存: 構造化データが信頼度スコアとともに Amazon DynamoDB に書き込まれます エラー処理とレジリエンス このワークフローには、一時的な障害に対するエクスポネンシャルバックオフを伴う自動リトライロジックが含まれています。失敗したタスクは詳細なエラーコンテキストとともにログに記録され、部分的な結果は デバッグとリカバリのために DynamoDB に保持されます。 ステップ 9: さらなる分析のために、Cloud Connector を使用して SAP に統合し戻します。 Cloud Connector を用いた BTP Integration Suite この統合では、AWS サービスと SAP システムをセキュアに接続する主要な手段として、SAP Business Technology Platform (BTP) の Integration Suite を活用します。SAP Cloud Connector はセキュアなリバースプロキシとして機能し、オンプレミスまたはクラウドの SAP システムが、内部システムをインターネットに直接さらすことなく SAP BTP 上のクラウドアプリケーションと通信できるようにします。このアプローチにより、AWS と SAP 環境間のシームレスなデータフローを実現しつつ、セキュリティ境界を維持します。 価格分析が完了して結果が S3 に保存されると、BTP Integration Suite は事前構成された統合フローを通じてデータ取得プロセスをオーケストレーションします。これらのフローは、保存された認証情報を用いて AWS に認証し、S3 から価格分析データを取得し、SAP で利用できる適切な形式に変換します。続いて Integration Suite は、SAP システム内のマテリアルマスターレコード、価格条件、その他の関連するビジネスオブジェクトを更新し、リアルタイムの市場インテリジェンスに基づくデータドリブンな価格意思決定を可能にします。 Cloud Connector は、BTP とオンプレミス SAP システムの間に暗号化されたトンネルを確立することで、すべての通信のセキュリティを確保します。一方、Integration Suite は信頼性の高いデータ処理のための監視、エラー処理、リトライ機構を提供します。このアーキテクチャにより、組織は既存の SAP セキュリティポリシーを維持しながら、クラウドベースの AI 機能の恩恵を受けることができます。 代替アプローチとして、組織は EventBridge 通知と ABAP SDK for AWS を組み合わせた直接統合を実装できます。これは、よりシンプルなデプロイシナリオ向けに、SAP システム内でネイティブな AWS サービス統合を直接提供します。 ABAP SDK アプローチの主な利点: ネイティブ統合: カスタムの HTTP 処理や JSON パースライブラリが不要 自動認証: SDK が AWS Signature V4 認証を自動的に処理 エラー処理: 組み込みの AWS エラー処理とリトライ機構 コードの簡素化: カスタム HTTP 呼び出しと比較して統合コードを約70%削減 SAP サポート: SAP により公式にサポートされ、将来のリリースとの互換性を確保 更新されたアーキテクチャの利点 依存関係の削減: カスタム REST クライアントや JSON ライブラリが不要 パフォーマンスの向上: ネイティブ SDK による最適化された AWS API 呼び出し メンテナンスの容易化: 標準的な SAP 開発パターン セキュリティの強化: SDK が SAP のセキュアストアを通じて認証情報を管理 このアプローチは統合を標準的な ABAP 開発タスクへと変え、オブジェクト指向 ABAP プログラミングに精通した SAP 開発者であれば誰でも扱えるようにします。 実装のベストプラクティス&nbsp; エラー処理&nbsp; SAP 接続に対する堅牢なエラー処理を実装する ウェブサイトの構造変更を適切に処理する エージェントの障害を監視・ログ記録する パフォーマンス最適化 頻繁にアクセスするデータにはキャッシュを使用する エージェントの並列処理を実装する コンプライアンスと倫理 robots.txt とクローリングポリシーを尊重する リクエスト間に適切な遅延を設ける 公開されている情報のみを保存する 実装のベストプラクティス エラー処理 堅牢なエラー処理は、信頼性の高い価格モニタリングシステムの基盤を成すものであり、特に複数の外部システムを統合する際の複雑さを考えると重要です。SAP 接続エラーは、ネットワークタイムアウト、認証失敗、システムメンテナンスウィンドウなどにより発生する可能性があり、障害を防ぐためにバックオフリトライ機構やサーキットブレーカーパターンの実装が必要となります。ウェブサイトの構造変更もまた重要な課題です。e コマースプラットフォームは頻繁にレイアウトや HTML 構造を更新するため、従来のウェブスクレイピング手法が機能しなくなる可能性があります。本ソリューションは、固定的な CSS セレクターや XPath 式に依存するのではなく、コンテンツをセマンティックに理解することで構造変更に適応できる生成AIモデルを活用することで、この課題に対処します。エージェント障害の包括的なログ記録と監視により、問題の迅速な特定が可能になり、システム最適化のための貴重なインサイトが得られます。また、自動アラートにより、重大な障害が運用チームの迅速な対応を受けられるようにします。 パフォーマンス最適化&nbsp; 効果的なパフォーマンス最適化は、システムコストとユーザーエクスペリエンスの双方に直接影響するため、本番環境へのデプロイには不可欠です。製品カタログやマーケットプレイスのレイアウトなど、頻繁にアクセスするデータをキャッシュすることで、冗長な API 呼び出しを削減し、応答時間を改善するとともに、繰り返しのデータ取得操作に伴うコストを最小化できます。このアプローチは、変更頻度は低いものの価格分析ワークフロー中に繰り返しアクセスされる SAP マテリアルマスターデータにおいて特に有効です。エージェントの並列処理は、複数の製品を異なるマーケットプレイスにわたって同時に分析できるようにすることでスループットを最大化し、包括的な価格モニタリングサイクルに必要な総時間を大幅に短縮します。制御された同時実行アプローチは、対象ウェブサイトへの過負荷を防ぎつつリソース利用を最適化し、製品カタログの拡大に応じてシステムが効率的にスケールできるようにします。 コンプライアンスと倫理&nbsp; 倫理的なウェブスクレイピングの実践は、組織と対象ウェブサイトの双方を保護しつつ、持続可能な長期運用を確保します。robots.txt ファイルやクローリングポリシーを尊重することは、良好なデジタルシチズンシップを示すとともに、IP ブロックやマーケットプレイス運営者からの法的な問題のリスクを低減します。リクエスト間に適切な遅延を設けることで、対象サーバーへの過負荷を防ぎ、人間のブラウジングパターンを模倣することで、データ収集活動を妨げかねないアンチボット対策を発動させる可能性を減らします。公開されている情報のみを保存することで、データ保護規制へのコンプライアンスを確保し、倫理的な境界を維持するとともに、ストレージコストの削減とデータガバナンス要件の簡素化にもつながります。これらの実践は、マーケットプレイスパートナーとの信頼を築き、将来の API パートナーシップやデータ共有契約の基盤を形成します。 コストに関する考慮事項 この SAP 価格モニタリングソリューションを実装するには、次の主要なコスト要因を考慮する必要があります。 主なコスト要素: コンピューティング時間 (ECS Fargate の vCPU およびメモリ時間) 関数の呼び出し回数と実行時間 (Lambda の GB 秒) ワークフローの実行とステート遷移 (Step Functions) データストレージと API リクエスト (DynamoDB および S3) データ抽出と処理 (AWS Glue) システムアーキテクチャの前提: 月間1,000件の CSV ファイルアップロード (ワークフロー実行1回につき1件) マーケットプレイス分析用の10,000件の ECS Fargate タスク (各10分、1 vCPU、2GB ARM64) 2,000回の Lambda 関数呼び出し (ワークフローごとに search-and-dispatch + aggregate-results) 平均15回のステート遷移を伴う1,000件の Step Functions 実行 CSV ファイルを処理する1,000件の AWS Glue ETL ジョブ (各5分、1 DPU) 月間50,000件の DynamoDB 書き込みリクエストと25,000件の読み取りリクエスト 月間15,000件の API リクエストを伴う5GB の S3 ストレージ 月間11,000件の EventBridge カスタムイベント 詳細なコスト内訳 (無料利用枠なし): Amazon ECS Fargate の料金は こちら に記載されています。ARM64 アーキテクチャの場合: vCPU 時間あたり $0.03238、GB 時間あたり $0.00356。月間10,000件のタスク が各10分実行される場合: 1,666.67 vCPU 時間と 3,333.33 GB 時間 = 月額 $65.83。 AWS Lambda の料金は こちら に記載されています。月間2,000回の呼び出しと30,000 GB 秒 = 月額 $0.50。 AWS Step Functions の料金は こちら に記載されています。1,000回の実行 × 15回の遷移 = 15,000回の遷移 = 月額 $0.38。 Amazon DynamoDB の料金は こちら に記載されています。月間50,000件の書き込みと25,000件の読み取り = 月額 $0.07。 Amazon S3 の料金は こちら に記載されています。5GB のストレージと15,000件の API リクエスト (10,000 PUT、5,000 GET) = 月額 $0.12。 AWS Glue の料金は こちら に記載されています。各5分実行の1,000件の抽出ジョブ (月間83.33 DPU 時間) と仮定 = 月額 $36.67。 Amazon EventBridge の料金は こちら に記載されています。月間11,000件のイベント (1,000件のワークフロー + 10,000件のタスク完了) = 月額 $0.01。 月額総コストの見積もり 1,000件のワークフロー実行にわたって10,000件の URL を処理する場合: ECS Fargate (ARM64) = $65.83 Lambda 関数 = $0.50 Step Functions = $0.38 DynamoDB = $0.07 S3 ストレージ = $0.12 AWS Glue = $36.67 EventBridge = $0.01 推定月額総コスト = $103.58 コスト最適化のオプション Fargate Spot インスタンス: 最大70%の割引により、Fargate コストを約 $19.75 に削減 リザーブドキャパシティ: DynamoDB やその他のサービスでリザーブド料金を提供 S3 Intelligent-Tiering: アクセス頻度の低いデータの自動コスト最適化 Glue ジョブの最適化: DPU 割り当てとジョブ実行時間の適正化 Fargate Spot 料金を利用した場合: 月額合計 $57.50 まとめ 本システムは、複数のオンラインマーケットプレイスにわたる完成品の包括的な価格モニタリング、価格変動の自動トレンド分析、比較可能な製品のインテリジェントな特定を提供し、お客様のセンチメントデータと価格の有効性を相関付けることで、より深い市場インサイトを提供します。 このインテリジェンスにより、小売業界の SAP のお客様は、データドリブンな価格意思決定を行い、競争上の脅威に迅速に対応し、ますますダイナミックになる小売環境において市場でのポジションを維持できるようになります。 Strands Agents と AWS のサービスは、インテリジェントな価格モニタリングシステムを構築するための強力なプラットフォームを提供します。SAP データ抽出とエージェント型 AI 機能を組み合わせることで、組織は市場でのポジショニングや競争力のある価格戦略に関する貴重なインサイトを得ることができます。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

Arunkumar Malli（Rivian）、Sandeep Kodre（Rivian）との共著 Rivian は、Amazon Bedrock AgentCore 上に構築したインテリジェントな ERP AI エージェントを導入することで、急成長を支えるべく月次決算プロセスを最適化し、サイクルあたり 15 日を超える手作業を削減しました。財務チームが手作業の ERP ワークフロー、長期化する決算サイクル、あるいは事業成長に伴うスケーリングの課題に直面しているなら、Rivian の取り組みはビジネスプロセス変革のための実証済みの青写真となります。 本ブログでは、Rivian の SAP 財務オペレーションがどのように制約を超えてスケールしたか、Amazon Bedrock AgentCore と主要な LLM モデルを用いた技術アーキテクチャ、そして皆様の組織に適用できる測定可能な成果と得られた教訓を共有します。 課題: 新製品ローンチに向けた財務のスケーリング カリフォルニア州アーバインに本社を置く Rivian は、電気自動車イノベーションのリーダーであり、イリノイ州ノーマルで R2 SUV、R1T ピックアップ、R1S SUV、および電動デリバリーバン（EDV）を製造しています。約 15,000 名のグローバルチームを擁する同社は、R2 車種や電気自動車ソフトウェアを前進させるフォルクスワーゲンとの合弁事業を含む戦略的施策によってもたらされる指数関数的なオペレーション成長に対応しています。 Rivian は製造成長を支えるためにオペレーションを加速させる中で、機能的かつ堅牢でありながらも、財務システムをさらにスケールさせる機会に直面しました。Rivian は、月次・四半期の決算書類作成、リソース予測、サプライヤーオンボーディングといった手作業の要素を自動化しようとしました。これらの既存の SAP ERP オペレーションを最適化することで、Rivian はパフォーマンス分析を加速し、インサイトをより即座に計画サイクルへ取り込めるようにすることを目指しました。予測される車両需要による大幅な成長を支えるため、Rivian は生産性をさらに引き出しプロセスを効率化すべく、GenAI を積極的に採用しました。 GenAI が解決策となった理由 ハードコードされたスクリプトのような従来の自動化アプローチでは、Rivian の複雑な財務ワークフローを解決できませんでした。ビジネスロジックがあまりにも動的で文脈依存的だったためです。発注（PO）の会計計上には、金額のしきい値、PO の特性、納期、GAAP 要件に基づく条件付きルールを備えた詳細な標準作業手順書（SOP）を解釈することが求められました。これらの手順を従来のコードに落とし込むには、数千行にも及ぶ if-then-else ロジックが必要になり、脆弱化しやすく、ビジネスルールが変わるたびに開発者の介入が必要になっていたでしょう。 生成 AI エージェントは根本的に異なるアプローチを提供しました。自然言語で書かれた SOP を読み取って解釈し、それぞれの状況に応じた文脈認識型の意思決定を行い、再プログラミングなしに手順の変更へ適応する能力です。複雑な指示を理解し、適切なワークフロー経路を動的に判断するこのオーケストレーション能力こそが、Rivian が財務オペレーションをスケールさせるために必要としていた技術、すなわち GenAI でした。 Amazon Bedrock AgentCore の AI エージェントは、手作業のプロセスを自動化しモダナイゼーションできます。 Rivian のエージェンティック戦略の台頭 Rivian は改善候補となるいくつかのワークフローを携えて AWS に相談しました。その一例が、カスタム治工具購入に関する発注（PO）の会計計上でした。これは多数の有効な発注にわたって年間相当額に及ぶポートフォリオです。この労働集約的なプロセスには、ERP システムからのデータ抽出、複雑なスプレッドシートモデルの構築、発注担当者へのメールによる納期確認、そして GAAP 準拠を支えるための期間按分による会計計上額の算出が含まれていました。 ビジネス上の機会は多面的でした。スタンピング金型や射出成形金型といった自動車製造向けのカスタム治工具は、12〜24 か月に及ぶ開発期間を伴いますが、請求書は発注作成から 18 か月以上経ってから届くことがよくあります。GAAP のもとでは、費用は請求書到着時に一括で認識するのではなく、治工具の開発期間にわたって段階的に会計計上しなければなりません。つまり財務チームは、外部監査人向けに完全な監査証跡を維持しながら、数百件の発注を同時に追跡し、納期スケジュールを検証し、按分による会計計上額を算出し、SAP を更新する必要がありました。 この複雑さは 1 つのワークロードだけでなく、財務、サプライチェーン、リソース計画を含む複数のオペレーション領域に存在していました。加速された概念実証（PoC）は 5 週間で成功裏に完了しました。有望な結果を踏まえ、Rivian はソリューションを本番環境へと迅速に移行し、最小限の重複で他チームへ展開できる再利用可能な基盤の準備を開始しました。 生成 AI への戦略的転換 Rivian の財務・技術チームは AWS のスペシャリストと協働し、Amazon Bedrock AgentCore 上に構築した SAP 発注会計計上自動化システムを開発しました。このシステムはいくつかの中核原則を軸に設計されました。 SOP 主導のインテリジェンス ビジネスロジックをアプリケーションコードにハードコードするのではなく、チームはすべての会計計上処理手順を詳細な SOP として文書化し、Amazon Bedrock ナレッジベースに保存しました。AI エージェントはこれらの SOP を「操作マニュアル」として使用し、各発注の具体的な特性に基づいて関連する手順を取得します。このアプローチは、ビジネスの俊敏性（財務マネージャーはコード変更を依頼するのではなく、ドキュメントを編集して手順を更新する）、監査の透明性、ドメイン知識の取り込み、一貫した規制準拠を実現します。 重要性（マテリアリティ）ベースのワークフロー このシステムは、重要性のしきい値に基づく高度な意思決定ロジックを実装しています。重要性は、金額に応じて異なるレベルの精査を適用するという財務会計の基本的な概念です。AI エージェントは金額に基づいて発注を自動的に異なる検証ワークフローへとルーティングし、経験豊富な財務アナリストが労力を優先付けする方法を再現します。 自律型エージェントアーキテクチャ このシステムの中核をなすのは、主要な LLM モデルを搭載し、Amazon Bedrock AgentCore 上に構築された Strands Agent です。このエージェントは継続的に稼働し、高度なオーケストレーションパターンに従います。すなわち、SAP OData イベントによる例外の検出、DynamoDB とナレッジベースからのコンテキスト収集、インテリジェントなルーティング判断、Model Context Protocol（MCP）サーバー経由でのツール実行による SAP S/4HANA との連携とメール送信、定額法（straight-line）を用いた期間按分の会計計上額の算出、財務レビュー用の仮伝票（parked journal entry）の作成、そして承認ワークフローの管理です。エージェントは硬直的な経路をたどるのではなく、各発注の具体的な状況に応じてアプローチを適応させます。 MCP ベースのモジュール性により、メールプロバイダー、データベース、SAP コネクターといった個々のコンポーネントを、コアとなるエージェントロジックを変更せずに差し替えることができます。これにより、Rivian の技術スタックが進化してもソリューションは柔軟であり続けます。 ヒューマン・イン・ザ・ループの設計 自律的な能力を備えながらも、システムは重要な意思決定ポイントで人による監督を維持しています。財務マネージャーは、いかなる仕訳伝票も SAP に転記される前に最終承認権限を保持します。これは内部統制の要件と外部監査の期待の双方を満たしつつ、大幅な時間削減を実現します。また、継続的改善も可能にします。マネージャーがエージェントの作業をレビューすることで、手順の精緻化が必要なエッジケースを特定し、時間とともに精度を高めるフィードバックループを生み出します。 技術アーキテクチャ Rivian のシステムは、SAP HANA Enterprise Cloud（HEC）上で稼働する SAP S/4HANA システムと統合された包括的な AWS サービス群を活用しています。 Amazon Bedrock AgentCore — SOP の解釈やマルチエージェント検索のオーケストレーションのために、自然言語理解と複雑な意思決定能力を提供するインテリジェントな推論エンジン Amazon Bedrock Knowledge Bases — SOP と SAP API ドキュメントを保存し、検索拡張生成（RAG）を用いて文脈に応じた意思決定支援を提供 AWS Lambda — SAP の例外ポーリングや承認メールの処理を含むスケジュールタスクを処理し、インフラのオーバーヘッドなしに自動でスケール Amazon DynamoDB — 状態管理と、SOX 準拠を満たすタイムスタンプ付きの完全な監査証跡 Model Context Protocol（MCP）サーバー — SAP REST API コネクター、Amazon SES 経由のメール、ケース管理のためのカスタムツール Amazon SES — パーソナライズされたメールを送信し、自動化された返信の解析を処理 アイデンティティとセキュリティ — MCP サーバー向けの AgentCore Identity、ロールベースアクセスのための AWS IAM と Cognito、認証情報のための Secrets Manager、モニタリングのための CloudWatch、そして Infrastructure as Code のための AWS CDK このアーキテクチャは AWS Well-Architected Framework の原則に従っており、特にセキュリティと運用上の優秀性を重視しています。 ビジネス上の成果とインパクト この変革は複数の側面で測定可能なメリットをもたらしました。 時間削減: エージェントは年間で総額の大きい多数の発注を管理し、その結果 Rivian の経理チームの手作業を毎年大幅に削減しました。以前は業務時間の大部分を会計計上額の計算に費やしていた財務アナリストは、財務分析、差異調査、戦略的意思決定支援といったより付加価値の高い活動に集中できるようになりました。 &nbsp; R2 ローンチに向けたスケーラビリティ: R2 車種が無事にローンチされた今、Rivian は予測どおりカスタム治工具の発注の大幅な増加を経験しています。AI 主導のシステムはこの指数関数的な成長に対応でき、同社の収益化への道のりを直接的に支えています。 精度とコンプライアンス: 一貫した SOP の適用と DynamoDB 上の完全な監査証跡により、精度が向上し内部統制が強化されました。外部監査人は、従来のスプレッドシートベースの計算と比較して、AI 主導プロセスの透明性を高く評価しています。 決算の早期化: 月次決算のタイムラインが短縮されたことで、投資家や経営陣への報告がより迅速になりました。これは変化の速い業界で事業を展開する上場企業にとって特に価値があります。 コスト最適化: サーバーレスアーキテクチャと Amazon Bedrock AgentCore の従量課金により、運用コストが実際のワークロードと整合します。 この実装の成功により、Amazon Bedrock AgentCore はインテリジェントな自動化のための戦略的プラットフォームとして確立されました。Rivian の財務チームは、いずれも同じ SOP 主導かつヒューマン・イン・ザ・ループのパターンに従う追加のユースケースをすでに計画しています。 Yogesh Yadav – Senior Director, Global Finance Systems, Rivian: 「AWS とのパートナーシップ、そして発注の会計計上に向けた AI 主導の自動化の実装は、私たちが財務オペレーションに取り組む方法における根本的な転換を意味します。毎月数週間分の手作業を排除しただけでなく、R2 のスケールと生産拡大を続ける中で成長を支えるスケーラブルな基盤を構築しました。これはまさに、私たちの収益に直接的なインパクトを与える種類の生産性向上です。」 まとめ Rivian の AI 主導による財務自動化への取り組みは、同様の変革を検討している他の組織にとって重要なインサイトをもたらしました。SOP 主導の設計のために明確に定義されたプロセスから始めること、人による監督を維持すること、一貫したパターンを活用して「車輪の再発明」を避けること、そして必要に応じて専門家とパートナーを組むことです。 この成功は時間削減にとどまらず、エンタープライズソフトウェアの構築・保守のあり方における根本的な転換を意味します。ビジネスロジックをコードではなく自然言語の SOP に保存することで、Rivian は最新の AI 機能を活用しながら、ビジネスユーザーが自らのプロセスを所有し進化させられるようにしました。Rivian の AWS とのパートナーシップと Amazon Bedrock AgentCore の採用は、重要な財務オペレーションにインテリジェントな自動化を適用したときに何が可能になるかを示しています。AI エージェントは今日の課題を解決するだけでなく、ビジネスの成長に合わせてスケールし、競争の激しい市場で持続的な成長に不可欠な生産性向上をもたらします。 著者について Arunkumar Malli は 18 年以上のアーキテクチャ経験を Rivian での役割に活かし、高度にスケーラブルでクラウドネイティブな ERP エコシステムの構築を専門としています。従来の SAP Basis とセキュリティの枠を超え、AI エージェンティック自動化を活用した安全な次世代 ERP アーキテクチャを設計し、予測的で自律的な高度なプラットフォームを生み出しています。財務やサプライチェーン向けのインテリジェントなワークフローを設計することで、TCO を大幅に低減し運用の俊敏性を高める、レジリエントなソリューションを提供しています。 &nbsp; Sagar Tallapragada は AWS でエンタープライズのデジタルトランスフォーメーションを支援し、ビジネスプロセスの自動化と既存システムのモダナイゼーションを専門としています。お客様が AI を活用して移行・モダナイズ・自動化できるよう支援するツールやソリューションの開発を推進しています。仕事以外では、テクノロジーへの情熱と家族との大切な時間、そして F1 への深い愛情と、Sachin Tendulkar のクリケットのレガシーへの生涯にわたる愛を両立させています。 &nbsp; Ramkrishna Borhade は Amazon Web Services のシニアソリューションアーキテクトで、20 年近い SAP の専門知識を持ち、クラウド移行、S/4HANA コンバージョン、レガシー SAP ランドスケープをモダナイズするための生成 AI の適用を専門としています。エンタープライズの戦略的なクラウド導入を支援し、お客様がエージェンティック AI で SAP のビジネスプロセスを自動化できるよう導いています。仕事以外では、家族と過ごす時間やプレミアリーグの観戦、そしてマンチェスター・ユナイテッドの応援を楽しんでいます。 &nbsp; Matt Reed は AWS の自動車・製造業担当のシニアソリューションアーキテクトで、Rivian と直接協働しています。Matt はお客様が AWS サービス全体で本番運用可能なソリューションを設計・実装できるよう支援しています。太平洋岸北西部で熱心なスキーヤーかつマウンテンバイカーであり、家族やペットとできるだけ多くアウトドアに出かけています。 &nbsp; Sandeep Kodre は 20 年以上の SAP FICO の専門知識と 22 年にわたる財務・会計の経験を持つベテランです。複雑なビジネスプロセスを ERP システムにマッピングし、US GAAP と IFRS への堅牢な準拠を確保することを専門としています。エージェンティック、予測的、探索的な AI を通じてスケーラブルな自動化を推進し、業務効率を高めることに長けています。仕事以外では、熱心なロードサイクリストであり、サッカーとクリケットの熱心なファンです。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの大久保です。 週刊AWS をお届けします。 11 月 25 日 (水) に、オンラインの「 Amazon Inspector ハンズオン 」を開催します。AWS Japan が 11 月から週次で開催しているセキュリティハンズオンの 1 回で、座学で考え方を整理したあと、Amazon Inspector を使った OS やミドルウェアの脆弱性管理を実際に操作して学べます。ハンズオンの環境は AWS 側で用意します。ユーザー企業・団体の方が対象で、申込には AWS のイベントサイトへの無料の会員登録が必要です。今回ご紹介するアップデートにも、Inspector による AMI のスキャンや、Inspector の結果をもとにした AWS Security Hub の SBOM インベントリがありますので、脆弱性管理をこれから始めたい方や見直したい方はぜひご参加ください。ほかの回の日程は 案内ブログ にまとまっています。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年11月2日週の主要なアップデート 11/2(月) Amazon Textract のテキスト検出モデルを更新 Amazon Textract now available in Asia Pacific (Tokyo) and Europe (Zurich) Amazon Textract のテキスト検出モデルが新しくなり、日本語を含む 40 以上の言語に対応しました。DetectDocumentText と AnalyzeDocument にそのまま適用されるので、API を変える必要はありません。手書き文字の検出や、結合セル・傾いた表の読み取りも良くなっています。同じ日に東京リージョンでも使えるようになったので、日本語の書類を国内のリージョンで読み取れます。なお東京リージョンでは、AnalyzeExpense、AnalyzeID、AnalyzeLending と、クエリ機能のカスタマイズ (アダプター) は現時点では使えません。 Amazon Inspector で EC2 の AMI の脆弱性スキャンが可能に Amazon Inspector で、EC2 の AMI に含まれるソフトウェアの脆弱性をスキャンできるようになりました。インスタンスを起動したりソフトウェアを入れたりせずに調べられるので、AMI をフリートに配る前に問題を直せます。AMI カタログを継続的にスキャンする方法と、EC2 コンソールから 1 回だけスキャンする方法を選べます。 Amazon CloudFront が AWS Service Quotas でのセルフサービスのクォータ引き上げに対応 Amazon CloudFront で、ディストリビューション数や代替ドメイン名の数など 28 のクォータを、AWS Service Quotas から確認・引き上げ申請できるようになりました。ビジネスサポート以上を利用していれば、公開されているしきい値内の申請は自動で承認されます。一部のクォータは使用状況を Amazon CloudWatch に出すので、上限に達する前にアラームで気付けます。 AWS Lambda がセルフマネージド Kafka イベントソースで Apache Kafka のキューに対応 AWS Lambda のセルフマネージド Apache Kafka イベントソースマッピングで、Kafka のキュー (share group) を使えるようになりました。複数のイベントポーラーが同じパーティションから同時に読み取れるので、パーティションを増やさずに並列度を上げられます。順序は保持されないため順序を問わない処理向けで、Apache Kafka 4.2 以降など share group を有効にしたクラスターが必要です。 デスクトップ版 Amazon Quick で組織の既存の Amazon Quick のサインインを利用可能に Amazon Quick のデスクトップアプリで、Web 版と同じサインイン方法を使えるようになりました。ID プロバイダーに OIDC アプリケーションを登録する必要がなくなり、管理者が Quick コンソールでデスクトップコネクタを一度追加すれば利用を始められます。IAM Identity Center、IAM フェデレーション、Quick のネイティブユーザーのいずれでも使えます。 Amazon RDS がスナップショット単位の課金に対応 Amazon RDS で、スナップショットごとのコストを確認できるようになりました。これまで Cost Explorer などでは DB インスタンス単位でまとめて表示されていたスナップショットの料金を、コスト配分タグを使って個々のスナップショット単位で把握できます。すべてのスナップショットでデフォルトで有効になっており、追加料金はかかりません。 11/3(火) Amazon CloudWatch が OpenTelemetry トレースの API キーに対応 Amazon CloudWatch で、OpenTelemetry のトレースを API キー (bearer token) で送れるようになりました。AWS SDK や一時的な認証情報を使えない、オンプレミスや他のクラウドのアプリケーション、CI/CD パイプライン、サードパーティのツールからもトレースを送信できます。推奨の認証方法は引き続き SigV4 です。 11/4(水) Amazon S3 Tables でデータレイクのモダナイズをシンプルかつ低コストに Amazon S3 Tables で、Apache Hive テーブルから Apache Iceberg テーブルへのマネージド移行を利用できるようになりました。本番のワークロードを動かしたまま検証、変換、コピーを行い、移行元との同期やロールバックもできます。料金はコピーしたデータの分だけで、変換自体には料金はかかりません。東京リージョンを含む 10 のリージョンで利用できます。 11/5(木) AWS Systems Manager Parameter Store が組み込みのデータ型によるパラメータの整理と検証に対応 AWS Systems Manager Parameter Store で、13 種類のデータ型を使ってパラメータの値を自動で検証できるようになりました。IP アドレス、AWS アカウント ID、JSON などの形式に合わない値は、PutParameter の時点で拒否されます。データ型でパラメータを絞り込めるので、整理にも使えます。 AWS Lambda durable functions の実行と API のデフォルトクォータを引き上げ AWS Lambda durable functions のデフォルトクォータが引き上げられました。アカウントあたりの実行中の実行数は 100 万から 500 万に、実行を開始する呼び出しは毎秒 300 から 3,000 リクエストになるなど、引き上げを申請しなくても多くの実行を並列で動かせます。米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) リージョンでは、この 2 倍のクォータが適用されます。 コンソールの Amazon Q Developer が AWS assistant に AWS マネジメントコンソールとモバイルアプリの Amazon Q Developer が、AWS assistant という名前に変わりました。アカウントに合わせたガイダンスやアクションはこれまでどおり使え、現在は無料で提供されています。既存の Amazon Q Developer Pro のサブスクライバーは、引き続き Pro Tier の機能を使えます。 Amazon RDS for Oracle がセルフマネージド Active Directory での Kerberos 認証に対応 Amazon RDS for Oracle で、DB インスタンスをセルフマネージドの Microsoft Active Directory ドメインに直接参加させ、Kerberos 認証を使えるようになりました。これまで必要だった AWS Managed Microsoft AD のデプロイと信頼関係の設定が不要になります。追加料金はかかりません。 Amazon DynamoDB が bulk put items に対応 Amazon DynamoDB で、Amazon S3 のデータを既存のテーブルに一括で書き込む bulk put items の一般提供を開始しました。S3 の場所を指定するだけで、取り込み用のパイプラインやテーブルのキャパシティを自分で管理せずに書き込めます。項目ごとに条件式を指定でき、多くの処理に向く Standard と、完了を急ぐ処理向けの Accelerated の 2 つのティアから選べます。 Amazon Bedrock AgentCore の Web Answer を発表 Amazon Bedrock AgentCore で、Web Answer の一般提供を開始しました。自然言語の質問に対して、ウェブの情報に基づく引用付きの回答を 1 回のツール呼び出しで返すので、検索から要約、引用までの仕組みを自前で作らずに済みます。ドメインの許可リストや公開日のフィルターで検索範囲を絞れます。現時点では米国東部 (バージニア北部) リージョンで利用できます。 11/6(金) AWS Security Hub がコンピューティングリソースの SBOM インベントリを提供 AWS Security Hub で、コンピューティングリソースの SBOM (ソフトウェア部品表) のインベントリを確認できるようになりました。Amazon Inspector が EC2 インスタンス、Amazon ECR のコンテナイメージ、Lambda 関数について作る SBOM をもとに、組織全体でどのパッケージがどのリソースに入っているかを一覧できます。Security Hub Essentials に追加料金なしで含まれ、Inspector を有効にしていれば追加の設定は不要です。 最後に、今週のピックアップとして AWS Security Hub の SBOM インベントリ を Dive Deep します。CVE や「このパッケージのこのバージョンが不正」といった情報が公表されたとき、まず知りたいのは、どのリソースにそのバージョンが入っているかです。SBOM インベントリでこれをどこまで調べられるかを試しました。SBOM インベントリは、Amazon Inspector が EC2 インスタンス、コンテナイメージ、Lambda 関数をスキャンして作る SBOM をもとに、どのソフトウェアのどのバージョンがどのリソースに入っているかを、Security Hub の画面や API で一覧できる機能です。 検証には東京リージョンの検証用アカウントを使いました。EC2 インスタンス 2 台、Amazon ECR のコンテナイメージ 2 つ、AWS Lambda 関数 1 つに、古い openssl と、npm の古いバージョン (lodash 4.17.20 と、その推移的依存の minimist 1.2.5) を入れ、Security Hub と Inspector を有効にしています。今回の検証では、Inspector の CVE の検出はコンテナイメージと Lambda で数分後、EC2 で約 70 分後に出て、SBOM インベントリに出そろったのは有効化から約 4 時間後でした。 検証用アカウントにあったほかのイメージの openssl も、バージョンごとに並んでいます。 OS のパッケージとして入っている openssl だけでなく、/usr/local にソースからビルドした openssl 3.0.13 も一覧に出ました。npm では、node_modules を含まず package-lock.json だけを置いたイメージでも、推移的依存の minimist 1.2.5 まで拾われています。バージョンで探すのも簡単で、SBOM ページの検索欄で「ソフトウェア = lodash」と絞り込み、リソース数を選ぶと、そのパッケージを含むリソースが一覧されます。AWS SDK でも GetSoftwareV2 と GetSoftwareResourcesV2 を呼ぶだけで、同じ一覧を取れました (今回は最新の AWS SDK for Python を使っています)。 SBOM でパッケージからリソースを選ぶと、右のパネルで検出結果とインストール済みソフトウェアを切り替えて見られます。検出結果タブにはそのリソースの検出結果がすべて並ぶため、試した Lambda では lodash の CVE 4 件のほかに minimist の CVE と露出の検出結果も表示されました。 対象は EC2、コンテナイメージ、Lambda などのコンピューティングリソースで、VPN 機器やオンプレミスのアプライアンスは含まれません。今回、自分のアカウントにコピーした AMI も、インベントリには出ませんでした。また、SBOM インベントリは新しい Security Hub の機能で、従来の Security Hub CSPM とは別のものです。Inspector をすでに使っている方は、まず Security Hub の SBOM ページで、よく使うパッケージ名を絞り込んでみてはいかがでしょうか。 それでは、また来週お会いしましょう！ 著者について 大久保 裕太(Yuta Okubo) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっているソリューションアーキテクトで、IoT 領域を得意としています。好きな AWS サービスは AWS IoT Core です。 週末はバスケットボールをしています。

本ブログは東京製鐵株式会社様とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆しました。 こんにちは。AWS の犬塚と山澤です。国内最大手の電炉メーカーである 東京製鐵株式会社 （以下、東京製鐵）では、一人ひとりの生産性向上に向けて、AI コーディングツール「 Kiro 」を全社に導入し、現場の従業員が自らの手で業務システムを内製する取り組みを進めています。本ブログでは、東京製鐵の皆さまに、Kiro 導入の背景や具体的な活用、成果、今後の展望について伺いました。 東京製鐵について 東京製鐵は、鉄スクラップを電気炉で溶かして鋼材を製造する、国内最大手の電炉メーカーです。1934 年の創立以来、田原・岡山・九州・宇都宮の 4 工場で、ホットコイル、厚板や H 形鋼などを供給しています。従業員数は 1,161 名（2026 年 3 月 31 日現在）、売上高は約 3,267 億円で、電炉法による資源循環型のものづくりを通じて、脱炭素社会の実現にも貢献しています。 導入の背景 ― 分散する情報と、外部委託に頼る開発 東京製鐵は、「TSSF2030（Tokyo Steel Smart Factory 2030）」のもと、全社スマートファクトリー推進プロジェクトを、安全・環境・品質・カーボンニュートラルに続く 5 本目の柱に掲げています。中期的な目標は、2030 年の年間生産量 600 万トンを 2021 年の人員数で達成する体制をつくることです。そのために、一人ひとりの生産性をいかに高めるかが大きなテーマとなっていました。 一方で、事業の成長とともに業務システムやノウハウが工場・部門ごとに発展してきた結果、情報が分散し、横断的に把握するには手間がかかっていました。加えて、システム開発は外部委託が中心で費用も大きく、「作りたいもの」があっても、なかなか形にできない状況でした。 もともと東京製鐵では、生成 AI の活用に早くから取り組んでいました。社内向けには、 Amazon Bedrock を活用した生成 AI 基盤として、AWS がオープンソースで公開している「 Generative AI Use Cases（GenU） 」を運用しています。2025 年 11 月には、情報システムセンターのメンバーが、AI コーディングツール Kiro を使い始めました。これが、東京製鐵での Kiro 活用の始まりです。 最初の用途は、開発ではなく調査でした。工場の計算機は多くの機能がつながり合う大きな仕組みで、不具合が起きると、原因の箇所を絞り込むだけでも手間がかかっていました。そこで、関係する資料を Kiro に読み込ませ、調べる手がかりにしました。当初は半信半疑だったといいます。自分たちで正しさを確かめられる範囲に絞って修正を任せ、その結果を一つずつ検証しました。こうして Kiro に任せられる範囲を見極めながら、2026 年 4 月にかけて、情報システムセンターの中で使う人が少しずつ増えていきました。 全社への広がり ― 常務執行役員自らの手応えから 全社に広がるきっかけは、常務執行役員の國米 博之様ご自身の体験でした。國米様は、田原工場長として工場を率いるとともに、品質管理と情報システムの部門を管掌しています。ある金曜日の夕方、レポート作成に行き詰まっていた國米様は、管理部 制御システム課で Kiro を活用していた横山 拓海様から「今からでも Kiro を覚えて、Kiro でやった方が早い」と勧められました。使い方を教わりながら 2 時間ほどでレポートの作成方法を理解し、それ以来、國米様は Kiro を使い続けています。 AWS： その体験から、どのように全社へ広げていったのですか。 東京製鐵 常務執行役員 田原工場長 國米 博之様 國米様： ちょうど情報システムセンターから、Kiro を全社の情報システム係で活用していくための講習を開きたいという相談がありました。他社の AI の活用や社員教育のニュースを見て、自分はどうしたらいいかと悩んでいたところでした。チャット型の AI と Kiro の違いや、それぞれでできることを教えてもらえる講習だったので、情報システム担当者だけでなく、全社のスタッフに AI の教育として受けてもらおうと考えました。Kiro の使い方だけを聞くのではなく、チャット型との違いを学べば、使い分けができるようになると思ったからです。 こうして東京製鐵は 2026 年 6 月から、全社向けの概要説明会と、各拠点での体験会を開催しました。概要説明会には、全社から約 200 名の参加申し込みがありました。体験会では、情報システムセンターと各工場の情報システム係が利用者の登録や当日のフォローを担い、AWS も内容づくりと進行をお手伝いしました。 AWS： 数ある生成 AI ツールの中で、Kiro のどこに手応えを感じられましたか。 國米様： Kiro は、ワークスペースにステアリング（Kiro に守ってほしいルールを書いておく機能）が残るので、作業がしばらく途絶えても、そこから再開できます。言い方を変えると、ながら指示や隙間時間の活用が増えますが、一息入れる時間は減少して、脳疲労を起こしそうです。チャット型だと、レポートを作っている途中で、前に教えたことを忘れてしまう。プログラムを書いたことのない私たちのようなアマチュアこそ、こちらの方が絶対にいいと思います。 AWS： これだけ短い期間で、Kiro が全社に広がった理由は何だと思われますか。 國米様： 要因の一つは、「使いなさい」と強く求めたことです。AI で仕事を効率化できれば、一人あたりのこなせる仕事の量は大きく変わります。使える人は、使えない人の何倍もの仕事をこなすことになり、評価も変わってくる。だから、そのための環境は用意するから全員使いなさい、と伝えました。部長・課長には、まず自分たちが使いこなせるところまで行きなさい、と言っています。使いこなしていないと、部下の仕事を見て「ここは AI でアプリ、システム化できる」と助言できないからです。講習で教わった通り、上位の役職の者ほど Kiro 活用の量・質とも高くなる理由は、普段から戦略を立て、部下に業務指示をすることに長けているからです。AI は優秀な部下であるというのは、まったくその通りだと考えています。 國米様は職場を回りながら、Kiro に作業をさせている画面を見つけては声をかけ、良いものを作っている人を褒めて回ったといいます。作られたものが増えてきた 2026 年 7 月には、工場のスマートファクトリー推進委員会の場で作品発表会を開き、各部署から推薦された取り組みを発表しました。「私自身も、こんな使い方ができるんだと勉強になった」と國米様は振り返ります。この会が刺激となって活用はさらに加速し、今では、工場や部署を問わず、Kiro で作られた仕組みが次々と生まれています。 安心して使うための仕組み ― 利用者のスピードを止めずに 全社展開に向けて、利用のルールづくりと環境の整備を担ったのが、情報システムセンター 課長の大島 友嗣様と、同センターの関 勇輝様です。國米様からの「スピードを緩めるな」という指示を受け、お二人は約 1 週間で、利用者の勢いを損なわずに安全を確保する運用を整えました。 当初は、Kiro の「ステアリング」に全社共通のルールを書き込んで運用しました。その後、Kiro の権限設定が強化されて細かな設定ができるようになると、ステアリングと権限設定を組み合わせる形に移しています。各部署の事務所スタッフは安心して作ることに専念し、社内への公開や既存システムとの接続は情報システム担当者が支える。こうした役割分担で運用しています。 導入後の利用状況も、継続して確認しています。利用の記録を社内の組織情報と結び付けたダッシュボードを作り、拠点や部署、課長などの役職ごとに利用状況を見られるようにしました。大島様は、システムは導入して終わりにせず、どれだけ根付いたかを定期的に確かめることが大切だと話します。数字にも、定着の様子が表れています。情報システム部門を除いた集計でも、Kiro を使う人は 7 月の 149 人から 9 月の 192 人に増え、使用率は 63.9% から 82.4% に伸びました。 Kiro・GenU の利用状況をまとめたダッシュボードの一部。月ごとの使用者数や使用率を、拠点・部署・役職ごとに確かめられる 左から、東京製鐵 情報システムセンター 課長 大島 友嗣様、関 勇輝様 現場で生まれた成果 東京製鐵で Kiro を使っているのは、立場も経験もさまざまな方々です。プログラム開発の経験を持つ技術者は、Kiro によって開発の速さと規模を大きく広げています。一方で、プログラムを書いたことのない各部署の管理職や担当者も、自らの業務の困りごとを解決する仕組みを次々と形にしています。國米様は、その違いを次のように話します。 國米様： 僕らアマチュア（プログラム未経験者）は仕事の中で、それぞれが困っていることを単発でやる。プロ（開発経験者）は展開できる作業があって、エージェントを 3 人ぐらい雇ったように、いくつもの作業を並行して進めています。 開発の経験を生かしているのが、事例 ①のクレーンの自動化を手がけた、管理部 制御システム課 主任の伊藤 仁志様です。もう一人、制御システム課 情報システム係の横山様は、現場で作られた仕組みを社内に広げる仕上げを担っています（後述）。 一方、事例 ②〜④は、プログラムを書いた経験のない方々が作ったものです。事例 ④では、國米様ご自身が作った全社標準文書管理システムを紹介します。 事例 ①：溶けた鉄を運ぶクレーンの自動化 ― 60 日分の開発を 1 日で 伊藤様が取り組んでいるのは、溶けた鉄を入れた鍋（レードル）を運ぶクレーンの自動化です。さまざまな障害物がある中で、重く高温の荷を運ぶ操作には、オペレーターに高い緊張感が求められます。人の操作では、停止位置や移動時間にもばらつきが出ていました。 Kiro で作ったクレーンシミュレーター。行き先を選ぶと、経路と動きを画面上で確かめられる 伊藤様が作った仕組みでは、タッチパネルで行き先を選ぶだけで、クレーンが工場内のレイアウトや高さ制限を踏まえて経路を自動で選び、荷の振れを抑えながら走ります。鍋を載せる・下ろす瞬間など、人が担うべきところは人が操作し、それ以外の移動を自動にすることで、オペレーターの負担を減らすことを目指しています。安全に関わる設備のため、AI によるシミュレーションの結果を人が確かめたうえで、慎重に試運転を重ねています。計算した走行時間（約 182 秒）は、実際に走らせた結果とほぼ一致しました。 開発の進め方にも工夫があります。伊藤様は、Kiro に一度に多くを任せず、「ここだけを考えてください」と範囲を絞って課題を与えました。まず物理計算をさせ、それが成り立つなら制御プログラム（ラダー）を生成させ、PC 上でシミュレーションさせる。その結果を人がレビューしてから、実機に反映します。制御プログラムの決まった書き方は、サンプルを直してはフィードバックする形で、3 日ほどかけて Kiro に教え込みました。 その結果、通常は 1 つにつき 10 日ほどかかるプログラムの部品（モジュール）6 つを、Kiro は 1 日で書き上げました。60 日分の作業が 1 日になった計算です。動作の検証（デバッグ）も、1 か月近くかかる作業が 1 日ほどで済みました。ほかの工場でクレーンの自動化を検討した際には、外部に依頼する見積もりが 4,000〜5,000 万円でした。それだけの規模の仕組みを、自分たちで形にしたことになります。今は、ここで得た考え方を「ノウハウ台帳」として残し、電気炉の壁に耐火物を吹き付ける装置など、ほかの設備への展開も進めています。 事例 ②：設備保全の計画づくりと図面検索 ― 1,322 項目の計画をワンクリックで、20 分の図面探しを数秒に 生産部 製鋼設備課 課長の菅野 利光様の職場では、設備を健全に保つため、設備ごとに点検・交換・給油などのルールと周期が決められています。その数は製鋼工場だけで 1,322 項目。これまでは、人がその周期を一つずつカレンダーに割り振り、Excel に打ち込んで計画を作っていました。 菅野様は、社内で「過去の Word や Excel のデータを Kiro に読み込ませて分析した」という共有を見て、自分たちの台帳でもできるのではと考えました。既存のデータを Kiro に読ませ、「ワンクリックで計画を作りたい」と伝えたところから始まり、改善を重ねて今はバージョン 55 になっています。年間の生産計画を取り込むと、電気炉の稼働回数に応じた年間・月間の保全計画が自動でできあがり、実績を入れると次回の予定が計算されます。予備品の在庫も、同じ画面から探せるようになりました。 図面・部品の統合検索の画面。メーカーごとに図面を探せる 菅野様は、図面探しにも Kiro を使いました。設備メーカーから受け取った図面と社内で作った図面は、合わせて約 2 万 7,000 点にのぼります。ファイル名は英数字だけで、開いてみないと何の図面か分かりませんでした。人の手で名前を付けてきましたが、5 年かけても 3 分の 1 ほどしか進んでいませんでした。1 枚の図面を探すのに 20 分かかることもありました。 そこで菅野様は、図面の PDF に書かれた名称や部品表を Kiro に読み取らせ、データベースにしました。英語の名称を訳すだけでは直訳になってしまうため、社内の設備管理システムにある 1 万件以上の用語から部品名の辞書を Kiro で作り、照らし合わせています。今では、メーカーをまたいで図面を数秒で探せるようになり、役員や部長も自分で図面を確かめてくれるようになりました。 思わぬ発見もありました。図面がないと思い込み、現場で 1 週間かけてスケッチしていた設備の図面が、実はデータとして残っていたのです。次の世代が同じ苦労をしなくて済む、技術の伝承にもつながる仕組みです。 事例 ③：操業の切断指示 ― 人の手で書き足していた注意点を自動で 生産部 製鋼課 係長の野中 由寛様は、操業のたびに、鋼片をどの幅・長さで何本切るかという指示を現場に配っています。これまでは、届いた指示に、幅の切り替えや本数、成分の条件といった注意点を人が書き足し、毎週金曜の夜から週末の分を何枚も作っていました。人の手で作る以上、抜けやミスの心配がありました。 野中様が Kiro で作った仕組みでは、元のデータを読み込むと、これまでの指示をもとに注意点が自動で書き込まれます。現場はチェックを入れながら作業を進め、取り漏れを防げます。品質の検査票も計画から自動で作られ、予定外に操業が途切れたときも、切った鋼片が次の工程のどの注文に使えるかを提示してくれます。 事例 ④：國米様自らも作り手に ― 品質文書を管理する仕組み 國米様が Kiro で作った全社標準（品質）管理システム。文書どうしの参照関係や引用規格を一覧できる 國米様ご自身も、作り手の一人です。全社標準（品質）文書の制定・改廃まで管理できるシステムを探しても見当たらなかったため、Kiro で自ら作り上げました。文書の申請・承認の流れに加え、ある文書を改訂したときに影響を受ける文書や、引用している規格を一覧でき、表記ゆれの点検もできます。「一つの文書を改訂したときに、影響する文書がないかを確かめるのは、人ではなかなか難しい」と國米様。プログラムは 7 万 6,000 行に及びます。 プログラムを書いた経験がなくても、なぜ作れたのか プログラムを書いた経験のない方々が、ここまでの仕組みを作り上げられた背景には、いくつかの共通点があります。 一つ目は、作り手が、その業務の困りごとを一番よく知る本人であることです。國米様は、作り手を動かしているのは「めんどくさい」という思いだと話します。何に手間がかかり、どうなれば楽になるのかが分かっているからこそ、Kiro に頼むことがはっきりします。菅野様の保全計画も、Kiro が作った叩き台を自分たちの使い方に合わせて直し続け、今のかたちになりました。最初の一歩も、プログラムを書くことではありませんでした。保全計画も切断指示も、始まりは手元の Excel や Word を Kiro に読み込ませて分析することです。きっかけは、「手元のファイルを Kiro に読ませれば、分析までできる」という國米様からの一言でした。 二つ目は、Kiro と会話しながら作り進められることです。作りたいものを伝えると、Kiro はできることとできないことを答え、質問を返しながら作業を進めます。画面を切り取って貼り付け、「こんなミスがある」と伝えれば、同じようなミスを探して直します。 三つ目は、社内に広げる段階を支える担い手がいることです。各部署の方々が作った仕組みをほかの人も使えるようにするには、利用者の ID の発行や社内への公開、工場の計算機との接続が必要です。各部署は自分の業務の課題を形にすることに集中し、情報システム担当者が社内に広げる。この役割分担によって、一人の工夫が社内に広がっていきます。 ほかにも広がる活用 活用の場は、事例で紹介した業務の仕組みづくりにとどまらず、設備の検証や経営の判断、全社のデータ活用、既存システムの資産解析にまで広がっています。 技術の検証にも使われています。排ガスダクトの設備改造では、菅野様が図面と条件を Kiro に読み込ませ、ガスの流れをシミュレーションしました。結果をうのみにせず、根拠となった文献 22 点も示させて、裏付けを確かめています。 経営の判断にも生かされています。設備やシステムへの投資では、見積もりや契約の内容に自社にとって不利な点がないかを Kiro で確かめ、判断の根拠を揃えています。 全社が同じ数字を見て判断するための仕組みづくりも進んでいます。全社のデータ基盤では、生産計画を取り込むと、日々の生産実績や月末の見込み、原料在庫の推移を確認できます。入力の手間と情報のずれをなくすことが狙いです。 関様が Kiro Crew で作った資料の一部。Kiro が指揮役となり、解析を自動で回す流れをまとめている 既存システムの資産解析にも使われ始めています。対象は膨大な量のプログラム資産で、すべてを人の手で読み解くのは現実的ではありません。情報システムセンターの関様は、Kiro Crew のスケジュールや繰り返しの機能を使い、解析を自動で回す仕組みを作りました。解析が一区切りすると Kiro が結果を確かめ、資料の不足や誤りの指摘があれば、解析のプログラムを直して再び走らせます。解析の途中で出てくる大量の確認事項にも Kiro が一つずつ答えるため、人が付きっきりにならなくても、精度を高めながら解析が進みます。これまでなら外部に頼むしかなかった規模の作業を、自分たちの手で進めています。 今後の展望 ― 作ったものの価値を測り、全社で生かす 國米様が次に見据えているのは、作ったものの価値を測ることです。國米様が Kiro で作った評価のアプリをもとに、横山様が、社内のアプリを登録するカタログ「TokyoAppStore」に仕上げました。どんなものを作り、どれだけの時間を減らせたかを、同じ基準で評価して一覧にします。作っている途中のものも登録し、同じ仕組みを別々に作ることを防ぐ役割も持たせています。 國米様： 海外のニュースでは、すでに、株主が会社を評価するときに AI をどう活用しているかも見るようになっているようです。成果をお金や時間で表せるようにしておかないと、「AI を導入しました、活用しています」と言っても、企業活動としてどうなのか、ということになる。そこまでつなげたいと考えています。 評価とあわせて、作ったものを全社で生かす仕組みも整えています。完成した仕組みの置き場として、「ツールポータル」も用意しています。必要な人はほかの工場からも使うことができ、作った人に機能追加の要望を出すこともできます。一人ひとりの工夫を、全社の生産性向上につなげていく考えです。 情報システム担当者の役割も変わり始めています。「作ってほしい」という依頼より、「作ったものをどう共有すればいいか」という相談が増えました。今後は、各部署が作ったものを、確認後に自動で公開できる仕組みを整えていく考えです。 取材にご協力いただいた田原工場の皆さまと AWS 山澤（左から、國米様、横山様、山澤、伊藤様、野中様、菅野様。2026 年 10 月、田原工場にて） まとめ 東京製鐵は、AI コーディングツール Kiro を全社に導入し、外部委託が前提だった業務システムの開発を、各部署のスタッフが自らの手で担う文化へと転換しました。経営層が自ら使い、「まず使いこなす」ことを求め、情報システムセンターが安心して使える土台を整えたことで、プログラムの専門家ではない各部署の方々が、クレーンの自動化から設備保全、図面検索まで、自分たちの業務を変える仕組みを生み出しています。AWS は今後も、一人ひとりの生産性を高めていく東京製鐵の挑戦を支援してまいります。 著者について 犬塚 友実子 アマゾン ウェブ サービス ジャパン合同会社 営業部 広域事業部門。東京製鐵株式会社を担当するアカウントマネージャー。AWS のテクノロジーを通じて、お客様と一緒に課題の解決に取り組むことを大切にしています。 山澤 良介 AWS のソリューションアーキテクトとして、製造業を中心にエンタープライズ企業の支援をしています。その活動の傍ら、最近は生成 AI の国内展開に向けた技術支援やコンテンツ作成に取り組んでいます。

本ブログは 2025 年 8 月 18 日に公開された AWS Blog “ Securing hybrid workloads using Amazon Route 53 Resolver DNS Firewall ” を翻訳したものです。 2021 年のリリース以来、 Amazon Route 53 Resolver DNS Firewall により、 Amazon Web Services (AWS) のユーザーは、 Amazon Virtual Private Cloud (Amazon VPC) リソースから発信されるアウトバウンド DNS クエリのモニタリングと制御ができるようになりました。Route 53 Resolver DNS Firewall でドメインフィルタリングルールを設定すると、さまざまなセキュリティ脅威を軽減できます。例えば、DNS トンネリングによるデータ流出、フィッシングやマルウェア配布に使用される悪意のあるドメインへのアクセス、承認されていない宛先やコンプライアンスに準拠していない宛先への意図しない接続などです。さらに、 AWS Firewall Manager を使用すると、 AWS Organizations の組織内の複数の VPC とアカウントにわたって、Route 53 Resolver DNS Firewall ルールを一元的かつ大規模に設定、管理できます。では、ハイブリッド AWS 環境のオンプレミスワークロードにも DNS 保護の範囲を広げたい場合は、どうすればよいでしょうか？この記事では、AWS DNS Firewall による保護をオンプレミスワークロードに拡張し、ハイブリッド AWS 環境全体で統一的で一貫したセキュリティポリシーを実現する方法を紹介します。単一の統合された DNS フィルタリングソリューションによって、セキュリティポスチャを強化し、コンプライアンスを維持しながら、運用上のオーバーヘッドを削減する方法を説明します。 ハイブリッド AWS 環境向けに DNS 保護の範囲を拡張する Route 53 Resolver DNS Firewall を設定して AWS ワークロードを保護し、組織のセキュリティポリシーに基づいて DNS クエリをフィルタリングできるようになったら、この保護をハイブリッド AWS 環境に拡張できます。そのためには、オンプレミスの DNS サーバーを設定し、直接管理していないすべてのドメインに対する DNS クエリを Amazon Route 53 Resolver のインバウンドエンドポイントに転送する必要があります。DNS クエリの転送経路には、パブリックインターネットを経由する方法と、Route 53 Resolver インバウンドエンドポイントを含む VPC へのプライベートネットワーク接続を経由する方法があります。以下のセクションでは、これら 2 つの接続オプションについて詳しく説明します。 AWS Direct Connect または AWS Site-to-Site VPN を介したプライベート接続 オンプレミス環境と AWS の間でプライベート接続を利用できる場合は、プライベートネットワーク接続を介して DNS クエリを安全に転送するように設定できます。オンプレミスの DNS サーバーは、 AWS Direct Connect または AWS Site-to-Site VPN を介して、DNS クエリを Route 53 Resolver インバウンドエンドポイントに転送します。この通信チャネルのセキュリティをさらに強化するために、Direct Connect と Site-to-Site VPN を組み合わせたり、Direct Connect 接続で MAC Security を有効にしたりするなど、追加の対策を講じることもできます。 図 1: Site-to-Site VPN または Direct Connect を介した安全な DNS クエリ 図 1 は、Direct Connect または Site-to-Site VPN を介した安全な DNS クエリのフローを示しています。 企業のワークステーションが、データセンター内の社内 DNS サーバーに DNS クエリを送信します。 社内 DNS サーバーが、AWS の Route 53 Resolver インバウンドエンドポイントに DNS クエリを転送します。 DNS クエリは、Direct Connect または Site-to-Site VPN を介して、カスタマーゲートウェイと AWS の仮想プライベートゲートウェイを経由してルーティングされます。 必要な DNS プロトコル標準に準拠した Route 53 Resolver インバウンドエンドポイントが、DNS クエリを受信します。 Route 53 Resolver DNS Firewall のルールによって、DNS クエリを許可するかブロックするかが判断され、 疑わしいドメインへのクエリがログに記録されます 。 Route 53 Resolver DNS Firewall によってクエリがブロックされなかった場合は、Route 53 Resolver が DNS クエリを処理します。 Amazon Route 53 プライベートホストゾーン (PHZ) 内のドメインであれば、リゾルバーは設定済みの PHZ を使用してクエリを直接処理します。外部ドメインであれば、リゾルバーはクエリを外部のネームサーバーに転送して応答を取得します。その後、応答は同じ経路を逆にたどってクライアントに返されます。 インターネット向け AWS Network Load Balancer を介したパブリック接続 プライベート接続を利用できない場合は、インターネット向けの AWS Network Load Balancer (NLB) を介して、DNS クエリを Route 53 Resolver インバウンドエンドポイントにルーティングできます。NLB はオンプレミスの DNS サーバーからの DNS クエリをインバウンドエンドポイントに転送します。このとき、イングレストラフィックは NLB の セキュリティグループ による送信元 IP 制限で保護されます。NLB は、一般的な DDoS 攻撃に対する保護機能を標準で備えています。保護をさらに強化したい場合は、NLB リソースに対して AWS Shield Advanced を有効にできます。 図 2: パブリックインターネットを介した安全な DNS クエリ 図 2 は、インターネット向け NLB を介した安全な DNS クエリのフローを示しています。 企業のワークステーションが、データセンター内の社内 DNS サーバーに DNS クエリを送信します (プライベート接続のフローと同じ)。 社内 DNS サーバーが、インターネット向け NLB のパブリック IP アドレスに DNS クエリを転送します。 DNS クエリは、パブリックインターネットを介して、お客様側のルーターのネットワークアドレス変換 (NAT) IP アドレスとインターネットゲートウェイ (IGW) を経由してルーティングされます。 インターネット向け NLB は DNS クエリを受信し、Route 53 Resolver インバウンドエンドポイントの Elastic Network Interface (ENI) のいずれかにルーティングします。これらの ENI は、それぞれ異なる AWS アベイラビリティーゾーン (AZ) のプライベートサブネットに配置されており、NLB の ターゲットグループ内の IP ターゲット (UDP/TCP ポート 53) として設定されています。あるいは、 DNS over HTTPS (DoH) を使用するようにソリューションを設定し、ウェブベースのセキュリティコントロールを提供することもできます。 必要な DNS プロトコル標準に準拠した Route 53 Resolver インバウンドエンドポイントが、DNS クエリを受信します (プライベート接続のフローと同じ)。 Route 53 Resolver DNS Firewall のルールによって、DNS クエリを許可するかブロックするかが判断され、疑わしいドメインへのクエリがログに記録されます (プライベート接続のフローと同じ)。 Route 53 Resolver DNS Firewall によってクエリがブロックされなかった場合は、Route 53 Resolver が DNS クエリを解決し、同じ経路を逆にたどってクライアントに応答を返します (プライベート接続のフローと同じ)。 ハイブリッド DNS 保護ソリューションの設計上の考慮事項 ハイブリッド DNS 保護ソリューションを設計する際は、さまざまなアーキテクチャ上の判断に直面します。これらの判断では、設計の各側面で相反する優先事項のバランスを取る必要があります。 ソリューションは、DNS クエリの量に応じて効率的にスケールする必要があります。NLB は、1 秒あたり数千万件のリクエストを超低レイテンシーで処理できます。Route 53 Resolver エンドポイントには、 サービスクォータ に留意しつつ、オンプレミスの DNS クエリの量に応じて適切な数の ENI を設定する必要があります。また、DNS クエリのパフォーマンスは、クエリタイプ、応答サイズ、ターゲットネームサーバーの正常性、クエリ応答時間、ラウンドトリップレイテンシー、使用するプロトコルなどの要因によって変わります。 高可用性については、まずワークロードの要件を評価します。ミッションクリティカルなオンプレミスワークロードが外部依存関係の追加を許容できない場合は、ハイブリッド DNS 保護の対象をエンドユーザーデバイスに限定する必要が生じることもあります。NLB と Route 53 Resolver エンドポイントの ENI を複数の AZ に分散させるとともに、 Site-to-Site VPN または Direct Connect 接続を冗長化します。障害発生時の Route 53 Resolver DNS Firewall の動作は、障害モードによって決まります。デフォルトでは、クエリを評価できない場合にそのクエリをブロックします。可用性に関する具体的な要件とリスク評価の結果によっては、 この設定の調整が必要になる場合があります 。パブリック接続を選択する場合は、DDoS 保護を強化するために AWS Shield Advanced の有効化を検討してください。その際は、追加コストと可用性要件を比較して判断します。Route 53 Resolver エンドポイントの高可用性の詳細については、「 How to achieve DNS high availability with Route 53 Resolver endpoints 」を参照してください。 パフォーマンス要件は、ユーザーや拠点の地理的な分布に大きく左右されます。グローバルに分散したユーザーや遠隔地の拠点がある場合は、 AWS Global Accelerator を使用すると DNS 解決のパフォーマンスを向上できます (パブリック接続オプションについては、「 Use AWS Global Accelerator to improve application performance 」を参照してください)。また、 Site-to-Site VPN Accelerator は VPN 接続のレイテンシーの削減に役立ちます。NLB でセキュリティグループを使用する場合は、接続が自動的に追跡される点に注意してください (「 Amazon EC2 セキュリティグループの接続追跡 」)。接続追跡によって、IP アドレスごとの 1 秒あたりの最大クエリ数が減少する可能性があります (「 Route 53 Resolver エンドポイントのクォータ 」)。このパフォーマンスへの影響は、セキュリティ要件と照らし合わせて評価する必要があります。DNS プロトコルの選択 ( UDP 、 TCP 、または DoH ) も、クエリのパフォーマンスとスループットに影響します。オンプレミスの DNS サーバーでは、DNS キャッシュと TTL 値を調整し、クエリ応答時間とデータの鮮度のバランスを取ってください。 セキュリティ対策は、脅威モデルに基づいて実装します。NLB でセキュリティグループを使用すると、送信元 IP 制限によってイングレストラフィックを保護し、承認されたオンプレミス DNS サーバーからの DNS クエリのみを受け付けるようにできます。ただし、この構成では接続追跡が自動的に有効になり、DNS クエリのスループットに影響します。パフォーマンス要件を満たすためにより高いスループットが必要であり、かつリスク評価の結果から許容できると判断した場合は、緩和策の 1 つとして、セキュリティグループを使用せずに NLB を運用する方法があります。この場合は、サブネットレベルの補完的なコントロールとして VPC のネットワーク ACL (「 Amazon VPC – ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する 」) を実装し、送信元 IP アドレスを制限します。 DNS セキュリティコントロールにもトレードオフがあり、バランスを取る必要があります。パブリック DNS クエリを DNS スプーフィングから保護するために、運用上のオーバーヘッドも考慮したうえで、DNSSEC 検証の導入を検討するとよいでしょう (「 Amazon Route 53 での DNSSEC 検証の有効化 」)。 DNS プロトコルの選択も、セキュリティとパフォーマンスのトレードオフの 1 つです。選択肢は、基本的な機能を提供する UDP から、暗号化された DoH まであります。 さらに、可用性とセキュリティのどちらを優先するかという点では、Route 53 Resolver DNS Firewall の障害モード設定も重要な判断事項です。デフォルトのフェイルクローズ設定では、クエリを評価できない場合にそのクエリがブロックされます。これはセキュリティを重視した設定であるため、可用性要件とのバランスを考慮する必要があります。 これらのアーキテクチャ上の考慮事項を踏まえることで、ハイブリッド DNS 保護ソリューションの実装時に、スケーラビリティ、高可用性、パフォーマンス、セキュリティに関する固有の要件のバランスを取ることができます。 ハイブリッド DNS 保護を大規模に管理する 図 3 に示すように、 AWS Security Hub 、Firewall Manager、Route 53 Resolver DNS Firewall を使用すると、アカウントをまたいで複数の VPC が存在するマルチアカウント AWS 環境で、DNS クエリの保護を一元的かつ一貫した方法で大規模に管理、統制できます。このソリューションの主な特徴は次のとおりです。 必要なすべてのセキュリティポリシーを含む DNS Firewall ルールグループが、 Security Tooling/Audit アカウント で作成されます。 Firewall Manager のセキュリティポリシーにより、複数の AWS アカウントにわたる VPC 全体に DNS Firewall ルールグループを一元的に配布、適用できます。 Security Hub は、DNS Firewall ポリシーのコンプライアンスに関する Firewall Manager の検出結果など、さまざまなソースからの検出結果を統合し、セキュリティポスチャを一元的に可視化します。Firewall Manager ポリシーで定義されている DNS Firewall ルールグループが VPC に関連付けられていない場合、Security Hub はこれをセキュリティの検出結果として表示します。これにより、組織全体における DNS 保護の不備を一元的に把握できます。 ワークロード VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの AWS リソースからの DNS クエリは VPC+2 IP アドレスにルーティングされ、そこで Route 53 Resolver が、VPC に関連付けられている DNS Firewall ルールグループを適用します。 オンプレミスの DNS クエリは、NLB を使用するパブリックインターネット接続、または Direct Connect や Site-to-Site VPN を使用するプライベート接続を介して、ハイブリッド DNS 保護アカウントの VPC にあるインバウンドエンドポイントにルーティングされます。ここで Route 53 Resolver が同じ DNS Firewall ルールグループを適用します。 図 3: マルチアカウント環境におけるオンプレミスと VPC の DNS クエリの保護 まとめ この記事では、Amazon Route 53 Resolver DNS Firewall による保護を AWS 環境の外部へ拡張し、ハイブリッドインフラストラクチャ全体で統一された DNS セキュリティ戦略を構築する方法を紹介しました。プライベート接続 (AWS Direct Connect または AWS Site-to-Site VPN を使用) とパブリック接続 (AWS Network Load Balancer を使用) のどちらを選択しても、運用効率を維持しながら、ネットワーク全体で一貫した DNS フィルタリングポリシーを適用できます。 ここで紹介したアーキテクチャには、戦略的なメリットが複数あります。具体的には、AWS Firewall Manager による DNS Firewall の一元管理、AWS とオンプレミスのワークロード全体での一貫したポリシーの適用、柔軟な接続オプション、マルチアカウント AWS 環境に対応するエンタープライズグレードのスケーラビリティです。DNS ベースの脅威がますます巧妙化する中、このハイブリッド DNS 保護ソリューションは、DNS トンネリング、ドメイン生成アルゴリズム、その他の DNS ベースの攻撃に対する組織の防御力の強化に役立ちます。ここで説明したアーキテクチャ上の考慮事項に従うことで、可用性、パフォーマンス、セキュリティに関する固有の要件に沿った堅牢な DNS セキュリティフレームワークを構築し、ハイブリッドインフラストラクチャのセキュリティポスチャを強化できます。 ご質問がある場合は、 Amazon Route 53 Resolver DNS Firewall re:Post &nbsp;で新しいスレッドを作成するか、 AWS サポート にお問い合わせください。 著者について Yaniv Rozenboim Yaniv は AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャとセキュリティに関する豊富な経験を持っています。安全でスケーラブルかつ効率的なクラウドインフラストラクチャの設計と実装を専門としています。お客様と緊密に連携し、AWS のテクノロジーを活用したビジネス目標の達成を支援しています。 Yossi Cohen Yossi は、EMEA 地域の公共部門を担当する AWS のシニアセキュリティスペシャリストソリューションアーキテクトです。規制の厳しい環境におけるクラウドネイティブアーキテクチャの開発、設計、運用、技術的デューデリジェンス、ガバナンスについて 20 年以上の経験があります。AWS では、防衛、インテリジェンス、政府、公共部門の各分野のお客様と緊密に連携し、それぞれが直面する固有の脅威への対応を支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 27 日に公開された AWS Blog “ Introducing Route 53 Resolved IP Validation for AWS Network Firewall ” を翻訳したものです。 ワークロードはほとんどの宛先にドメイン名でアクセスしますが、ファイアウォールが判断に使えるのはトラフィック内で確認できる情報だけです。HTTP と HTTPS の場合、 AWS Network Firewall のドメインルールは、クライアントがリクエストに含めた名前を照合対象にしますが、その名前はクライアント側で決められます。SSH や SSH File Transfer Protocol (SFTP) などのプロトコルの接続には、ドメイン名が含まれません。クライアントは名前を DNS ルックアップにのみ使用し、DNS が返した IP アドレスに直接接続します。そのため、これらのプロトコルの Network Firewall ルールでは、時間の経過とともに変化する IP アドレスを使用してきました。また、ウェブトラフィックか非ウェブトラフィックかを問わず、Network Firewall は DNS リゾルバーが返した応答を把握できませんでした。DNS とファイアウォールの間で可視性を共有する仕組みがなかったためです。 AWS は 2026 年 10 月 21 日、 AWS Network Firewall 向け Route 53 Resolved IP Validation を追加料金なしでリリースしました。 Amazon Route 53 Resolver が各ドメイン名に対して返す IP アドレスを Network Firewall と共有するようになり、Network Firewall は新しいアウトバウンド接続ごとに、その IP アドレスと照合します。このリリースにより、非ウェブトラフィックをドメイン名でフィルタリングできるようになりました。また、 TLS インスペクション を有効にしなくても、TLS トラフィックにおける Server Name Indication (SNI) の改ざんを防止できます。 この記事では、この機能の仕組みと、アラートモードで有効化する方法を説明したうえで、一般的な 2 つのユースケースを紹介します。これらはあくまで一例であり、ドメイン名で制御するあらゆるアウトバウンドトラフィックに同じチェックが適用されます。 仕組み Amazon Route 53 Resolver は、Route 53 Resolver を使用するように設定された仮想プライベートクラウド (VPC) 内のリソースからの DNS クエリに応答します。Route 53 Resolver は、すべての VPC でデフォルトで利用できます。この機能では、Route 53 Resolver が各ドメイン名に対して返した IP アドレスを解決済み IP キャッシュ (resolved IP cache) に保持します。新しいアウトバウンド接続が開始されると、Network Firewall は宛先アドレスをそのキャッシュと照合します。 ワークロードが 10.0.0.2 の Route 53 Resolver に files.partner.example.com を問い合わせます。 最初に Amazon Route 53 Resolver DNS Firewall がクエリをチェックします。ドメインルールでクエリをブロックしたり、アラートを出したりできます。ルールグループが空の場合、クエリはそのまま通過します。 Route 53 Resolver は 203.0.113.10 を返し、その応答を解決済み IP キャッシュに記録します。 203.0.113.10 のポート 22 への SFTP 接続が、Network Firewall エンドポイントに到達します。 ポリシーが最初のパケットをチェックします。アドレスがキャッシュ内に存在するため、接続は続行されます。 Route 53 Resolver が files.partner.example.com に対してこのアドレスを返しているため、ステートフルルールは接続を通過させます。 接続は NAT ゲートウェイとインターネットゲートウェイを経由して外部に出ます。 フローログとアラートログに新しいフィールドが記録されます。 この機能は 3 つの要素で構成されています。 Amazon Route 53 Resolver DNS Firewall ルールグループ – 対象範囲を定義します。このルールグループに関連付けられたすべての VPC で Route 53 Resolver が返した応答が、解決済み IP キャッシュに格納されます。ルールグループは空でも構いません。ルールを追加すると、同じルールグループで DNS クエリ自体もフィルタリングできます。例えば、既知の脅威ドメインのルックアップをブロックできます。このように、DNS Firewall がルックアップを、Network Firewall がその後の接続をチェックすることで、両者が連携して機能します。 Network Firewall のポリシー設定 – Network Firewall は新しい接続ごとに、ステートフルルールが実行される前に最初のパケットをチェックし、Route 53 Resolver がその宛先アドレスをいずれかのドメイン名に対して返したかどうかを確認します。返していた場合、接続はステートフルルールの評価に進みます。返していない場合、Network Firewall は選択したアクション (アラート、ドロップ、または拒否) を適用します。 解決済みドメインルール (resolved-domain rule) – ステートフルルールグループ内のこれらのルールは、宛先アドレスがどのドメイン名に対して解決されたかに基づいて接続を照合するため、あらゆるプロトコルで機能します。ルールには、クライアントがルックアップする名前を使用してください。 次の図は、このアーキテクチャを示しています。 図 1. ユースケース 1 の SFTP 接続を、Route 53 Resolver が返した応答と Network Firewall が照合する仕組み ポリシー設定は、ウェブトラフィックに限らず、すべての接続をチェックします。ハードコードされたアドレスなど、どのクライアントも Route 53 Resolver 経由でルックアップしていない IP アドレスへの接続は、チェックに失敗します。IP アドレスに直接接続するワークロードがある場合は、適用 (エンフォース) する前に、それらのアドレスを [Bypass destination validation IP ranges] (宛先検証をバイパスする IP 範囲) に追加してください。ポリシーのチェックはルールより前に実行されるため、ステートフルなパスルールを作成しても、これらのアドレスをチェックの対象外にすることはできません。また、チェックはアドレス単位で行われます。関連付けられた VPC 内のいずれかのクライアントが名前をルックアップすると、同じアベイラビリティーゾーン内の対象範囲にあるすべてのクライアントについて、そのアドレスがチェックに合格するようになります。詳細については、AWS Network Firewall デベロッパーガイドの「 Resolved IP validation in AWS Network Firewall 」を参照してください。 前提条件 この記事の手順を実行するには、以下が必要です。 Amazon Route 53 Resolver を介した DNS – Network Firewall がチェックできるのは、Route 53 Resolver が返した応答のみです。Resolver エンドポイントまたは Resolver 転送ルールを経由して Route 53 Resolver に到達したクエリも対象になります。 Route 53 Resolver DNS Firewall ルールグループ – Network Firewall が接続の照合に DNS の応答を使用する VPC に関連付けておく必要があります。 解決済みドメインルールを追加する前に有効化したポリシー設定 – ドメインフィルタリング ( aws_route_53_resolved_domain キーワード) を使用するルールには、同じファイアウォールポリシーで Route 53 Resolved IP Validation を有効にしておく必要があります。まずアラートモードで設定を有効にしてから、ルールを追加してください。 サポートされているデプロイモデル – この機能は、クライアントが自身のアベイラビリティーゾーン内のファイアウォールエンドポイントに到達する分散型デプロイ (複数のファイアウォールエンドポイントを使用する構成を含む) と、ファイアウォールを AWS Transit Gateway にネイティブにアタッチした集中型デプロイに対応しています。ルーティングによってクライアントが別のアベイラビリティーゾーンのファイアウォールエンドポイントに送られる場合、そのクライアントの接続はチェックに失敗します。集中型デプロイをネイティブにアタッチされたファイアウォールに移行する方法については、「 Why and how to migrate to a Transit Gateway attached AWS Network Firewall 」を参照してください。 アラートモードで有効化する方法 クライアントは DNS の応答をキャッシュするため、まずアラートモードで開始します。Network Firewall が認識するのは、DNS Firewall ルールグループを VPC に関連付け、ポリシーで選択した後に Route 53 Resolver が返した応答のみです。以前にキャッシュした応答を使い続けているクライアントは、名前を再度ルックアップするまで (通常はキャッシュされたレコードの有効期限が切れるまで) チェックに失敗します。アラートモードなら、何もブロックせずにこの状況を確認できます。クライアントがキャッシュを更新できるよう、アラートモードで約 24 時間運用してください。 DNS Firewall ルールグループを作成し (空でも構いません)、Network Firewall が接続の照合に DNS の応答を使用する VPC に関連付けます。手順については、「 Creating a rule group and rules 」を参照してください。 既存の DNS Firewall ルールグループを使用する場合は、そのルールグループがこれらの VPC にのみ関連付けられていることを確認してください。関連付けられたいずれかの VPC で返された応答は、ファイアウォールがチェックするすべてのクライアントに対して有効になるためです。チェック対象のクライアントは、ステップ 6 の [Source IP ranges] (送信元 IP 範囲) で設定します。 Amazon Virtual Private Cloud (Amazon VPC) コンソールの [Network Firewall] で [ファイアウォールポリシー] を選択し、ファイアウォールが使用しているポリシーを選択します。 [トラフィック検査] タブの [Route 53 Resolved IP validation] セクションで [編集] を選択し、 [Enable Route 53 Resolved IP validation] (Route 53 解決済み IP 検証を有効にする) を選択します。 [アクション] で [アラート] を選択します。 [DNS Firewall rule group] (DNS Firewall ルールグループ) で、ステップ 1 または 2 のルールグループを選択します。 [DNS expiry exception policy] (DNS 有効期限切れ時の例外ポリシー) では、確立済みの接続について、そのエントリが解決済み IP キャッシュで期限切れになった場合の動作を選択します。 [Continue] (続行) では接続が維持され、 [Drop] (ドロップ) では TCP リセットを送信せずに接続が停止され、 [Reject] (拒否) では TCP リセットで接続が停止されます。ファイル転送など長時間実行されるセッションが途中で切断されないよう、 [Continue] をお勧めします。ただし、セキュリティ要件に合ったオプションを選択してください。 [Source IP ranges] で、チェック対象のクライアントを指定します。指定しない場合、Network Firewall はファイアウォールの VPC と、ファイアウォールにアタッチされた追加の VPC 内のクライアントをチェックします。トランジットゲートウェイにアタッチされたファイアウォールにトラフィックを送信するスポーク VPC など、クライアントが他の VPC にある場合は、その CIDR 範囲を入力してください。入力しないと、Network Firewall はそれらのクライアントの接続をチェックしません。IP アドレスで許可する宛先は [Bypass destination validation IP ranges] に追加します。最後に [保存] を選択します。 次のスクリーンショットは、これらの手順を示しています。 図 2. アラートモードで有効化された Route 53 Resolved IP Validation アラートモードでは、Network Firewall はチェックに失敗した接続をブロックせず、チェック自体のアラートも書き込みません。チェックの結果は、フローログ内の各接続の route53_resolved_ip フィールドに記録されます。値が true の場合は、Route 53 Resolver がその宛先アドレスをいずれかのドメイン名に対して返したことを意味します。値が false の場合は返していないことを意味し、適用時にはその接続がブロックされます。同じフィールドは、ルールまたはポリシーのデフォルトアクションがその接続に対して書き込むアラートログレコードにも含まれます。なお、パスルールは alert; キーワードがない限り、アラートログレコードを書き込みません。 Amazon CloudWatch の DnsUnresolvedFlows メトリクスはチェックに失敗した接続を、 DnsAzUnavailableFlows はこの機能をサポートしていないアベイラビリティーゾーンからの接続をカウントします。次のアラートログレコード (一部省略、値は例) は、Route 53 Resolver が返したアドレスへの接続について、アラートを出すデフォルトアクションが書き込んだものです。 { "firewall_name": "egress-firewall", "availability_zone": "us-east-1a", "event": { "event_type": "alert", "src_ip": "10.0.1.10", "dest_ip": "203.0.113.10", "dest_port": 123, "proto": "UDP", "app_proto": "ntp", "route53_resolved_ip": true, "verdict": { "action": "alert" }, "alert": { "action": "allowed", "signature_id": 3, "signature": "aws:alert_established action" } } } 次のレコードは、アラートモードで記録された TLS 接続のものです。この接続は許可されたドメイン名を提示しましたが、Route 53 Resolver がそのドメイン名に対して返していないアドレスに向かったため、ユースケース 2 のポリシーのデフォルトアクションによってブロックされました。 { "firewall_name": "egress-firewall", "availability_zone": "us-east-1a", "event": { "event_type": "alert", "src_ip": "10.0.1.10", "dest_ip": "198.51.100.7", "dest_port": 443, "proto": "TCP", "app_proto": "tls", "tls": { "sni": "api.partner.example.com" }, "route53_resolved_ip": false, "verdict": { "action": "drop" }, "alert": { "action": "blocked", "signature": "aws:alert_established_app_layer_to_server action" } } } [アクション] を [ドロップ] または [拒否] に切り替える前に、チェックに失敗している接続が想定どおりのものであること、IP アドレスで許可する宛先がバイパス範囲に含まれていることを確認してください。 [拒否] は TCP リセットを送信するため、ブロックされた TCP クライアントはタイムアウトを待たずに直ちに失敗します。適用後、ブロックされた接続はアラートログではなくフローログに記録され、 route53_resolved_ip の値は false になります。監視すべきメトリクスとログフィールドについては、「 Monitoring and troubleshooting resolved IP validation 」を参照してください。 ユースケース 1: ドメイン名で非ウェブトラフィックをフィルタリングする Route 53 Resolved IP Validation のリリース前は、SFTP などドメイン名を含まないプロトコルの Network Firewall ルールでは IP アドレスを使用していました。この機能により、これらのトラフィックをドメイン名で許可できるようになりました。この例では、ワークロードが TCP ポート 22 の SFTP で、files.partner.example.com のパートナーにファイルを送信します。パートナーは、この名前に対応するアドレスをいつでも変更できます。SSH、MySQL、その他の非ウェブプロトコルでも同じ方法を使用できます。このルールは標準ステートフルルールとして作成します。手順は次のとおりです。 [Network Firewall] で [Network Firewall ルールグループ] を選択し、 [ルールグループを作成] を選択します。 [ステートフルルールグループ] と [標準ステートフルルール] を選択し、ポリシーで使用しているルール評価順序を選択します。 [ルールを追加] を選択します。 [プロトコル] で [TCP] を選択します。 [送信先ポート] に 22 と入力します。 [ドメインフィルタリング] に files.partner.example.com と入力します。 [アクション] で [パス] を選択します。 ルールグループを作成し、ファイアウォールポリシーに追加します。 図 3. パートナーのドメイン名を対象とした、TCP ポート 22 の SFTP 用パスルール ルールをコードとして管理する場合、同等の Suricata ルールは次のとおりです。このルールでは、許可された接続をファイアウォールがログに記録するように、 alert; キーワードを追加しています。コンソールで作成したルールには、このキーワードは含まれません。 pass tcp any any -&gt; any 22 (alert; msg:"Allow TCP/22 to files.partner.example.com"; aws_route_53_resolved_domain:"files.partner.example.com"; sid:1;) パートナーがサーバーを新しいアドレスに移行すると、次回の DNS の応答で、そのアドレスが解決済み IP キャッシュに追加されます。IP リストを管理する必要はありません。なお、キャッシュは以前の応答を DNS の有効期間 (TTL) よりも長く保持するため、古いアドレスもしばらくはチェックに合格する場合があります。 ユースケース 2: TLS インスペクションを使わずに SNI スプーフィングを防止する SNI スプーフィングとは、クライアントが TLS リクエストで許可されたドメイン名を提示しながら、実際には別のサーバーに接続する手法です。これを防止するには、従来はトラフィックを復号する TLS インスペクション が必要でした。Route 53 Resolved IP Validation を使用すると、TLS インスペクションなしでこれを防止できます。この例では、ワークロードが HTTPS で api.partner.example.com のパートナー API を呼び出します。ポート 443 の TLS トラフィックは、Route 53 Resolver がその名前に対して返したアドレスにのみ到達するようにする必要があります。ユースケース 1 と同様に、標準ステートフルルールグループにパスルールを作成します。どのルールによっても通過が許可されないトラフィックは、ファイアウォールポリシーのデフォルトアクションによってすべてドロップされます。手順は次のとおりです。 [Network Firewall] で [Network Firewall ルールグループ] を選択し、 [ルールグループを作成] を選択します。 [ステートフルルールグループ] と [標準ステートフルルール] を選択し、 [厳密な順序] を選択します。 [ルールを追加] を選択します。 [プロトコル] で [TLS] を選択します。 [送信先ポート] に 443 と入力します。 [ドメインフィルタリング] に api.partner.example.com と入力します。 [アクション] で [パス] を選択します。 ルールグループを作成し、ファイアウォールポリシーに追加します。 ファイアウォールポリシーでは、厳密なルール順序を使用します。ステートフルデフォルトアクションには、 [Application drop established (server-directed only)] (確立済み接続をアプリケーション層でドロップ、サーバー方向のみ) と [Application alert established (server-directed only)] (確立済み接続をアプリケーション層でアラート、サーバー方向のみ) を選択します。アラートアクションにより、ドロップアクションがブロックした内容がログに記録されます。これらのデフォルトアクションをお勧めする理由については、 AWS Security Services Best Practices ガイドの「Firewall policy configuration」 を参照してください。 図 4. パートナーのドメイン名を対象とした、ポート 443 の TLS 用パスルール ルールをコードとして管理する場合、同等の Suricata ルールは次のとおりです。 pass tls any any -&gt; any 443 (aws_route_53_resolved_domain:"api.partner.example.com"; sid:2;) パスルールが照合するのは、TLS リクエスト内の名前ではなく宛先アドレスです。ポート 443 の TLS トラフィックが通過するのは、Route 53 Resolver が api.partner.example.com に対してその宛先アドレスを返した場合のみです。コンテンツ配信ネットワーク (CDN) の背後にあるなど、パートナーのアドレスが他のドメイン名にも使われている場合は、それらのドメイン名宛てのトラフィックも通過します。TLS リクエストにパートナーの名前が含まれていることも条件にするには、同じルールに SNI の完全一致条件として tls.sni; content:"api.partner.example.com"; startswith; endswith; nocase; を追加します。 startswith と endswith を指定しない場合、content による照合では、その名前を含むあらゆる SNI が受け入れられます。 パートナーの名前を提示しながら別のアドレスに向かう接続は、パスルールに一致しません。Route 53 Resolver がそのアドレスを一度も返していない場合は、ルールが実行される前に、ポリシー設定の適用アクションによって接続がブロックされます。アラートモードでは、ポリシー設定は接続をブロックせずにルールの評価へ進めますが、パスルールに一致しないため、ステートフルデフォルトアクションによって接続がドロップされます。そのアラートログレコードでは、前述の 2 番目の例のように、 route53_resolved_ip が false になります。一方、Route 53 Resolver が別のドメイン名に対してそのアドレスを返していた場合、接続はポリシーのチェックに合格します。ただし、パスルールに一致しないため、その後ステートフルデフォルトアクションによって接続がドロップされ、そのレコードでは route53_resolved_ip が true になります。 ベストプラクティス 次のベストプラクティスに従うことをお勧めします。 DNS を Route 53 Resolver に限定する – クライアントがチェックを回避できないように、Network Firewall で、他のリゾルバーへのアウトバウンドの DNS (UDP および TCP ポート 53) に加え、DNS over HTTPS (DoH) や DNS over TLS (DoT) もブロックします。Route 53 Resolved IP Validation だけでは、このブロックは行われません。いずれかのクライアントが dns.google などのパブリックリゾルバーの名前をルックアップすると、そのリゾルバーのアドレスはチェックに合格してしまいます。 これらの VPC で DNS Firewall ルールを維持する – Route 53 Resolved IP Validation がチェックするのは、DNS ルックアップの後に続く接続であり、DNS クエリ自体ではありません。DNS Firewall は AWS マネージドドメインリストを使用して既知の脅威ドメインのルックアップをブロックできます。また、その高度なルールグループでは、DNS トンネリングなど、DNS クエリを介したデータの流出を検出できます。 小規模から始める – ドメインフィルタリングは一度に少数のルールに追加し、結果に問題がないことを確認してから対象を広げます。ドメイン許可リストのパターンについては、「 Allow rules and domain allowlisting 」を参照してください。 フローログ、アラートログ、詳細モニタリングを有効にする – 解決済み IP のチェックに失敗した接続は、アラートログではなく、フローログ ( route53_resolved_ip: false ) と DnsUnresolvedFlows メトリクスに表示されます。また、 alert; キーワードのないパスルールは、アラートログレコードを書き込みません。 料金と提供状況 Route 53 Resolved IP Validation は現在、AWS Network Firewall と Amazon Route 53 Resolver DNS Firewall を利用できるすべての商用 AWS リージョン (AWS GovCloud (米国) リージョンと中国リージョンを除くリージョン) で、追加料金なしでご利用いただけます。リージョンの一覧については、「 AWS Capabilities by Region 」を参照してください。ルールのない DNS Firewall ルールグループには、DNS Firewall の料金は発生しません。ルールを追加すると、DNS Firewall の標準料金が適用されます。詳細については、「 AWS Network Firewall の料金 」と「 Amazon Route 53 の料金 」を参照してください。 まとめ この記事では、Route 53 Resolved IP Validation の仕組みと、アラートモードで有効化する方法を紹介しました。Network Firewall は、各接続の宛先を、Amazon Route 53 Resolver が DNS クエリに対して返した IP アドレスと照合するようになりました。この照合によって可能になる代表的な例として、SFTP、SSH、データベースなどの非ウェブトラフィックをドメイン名でフィルタリングすることと、TLS インスペクションを使わずに SNI スプーフィングを防止することの 2 つがあります。まずはアラートモードで機能を有効にし、結果を確認してから適用してください。詳しい手順については、「 Getting started with resolved IP validation 」を参照してください。 詳細については、 AWS Network Firewall 製品ページ と 機能のドキュメント をご覧ください。 この記事に関するご質問は、 AWS サポート までお問い合わせください。 Lawton Pittenger Lawton は、ニューヨーク市を拠点とする AWS の Worldwide Security Specialist Solutions Architect です。お客様が効果的なネットワークセキュリティコントロールを設計、実装できるよう支援することを専門としています。AWS では多くのお客様と協力するとともに、サービスチームと緊密に連携し、お客様のニーズとフィードバックに基づいてセキュリティサービスの継続的な改善を推進しています。趣味は、スケートボード、スノーボード、自然の中で過ごすことです。 Amish Shah Amish は、ネットワーク、セキュリティ、クラウドのユースケース向けに、革新的でスケーラブルなソリューションの開発に 15 年以上携わってきた経験豊富なプロダクトリーダーです。現在は AWS Network Firewall サービスを率い、AWS のワークロードを保護するセキュリティソリューションの開発に取り組んでいます。仕事以外では、クリケットやサッカーを楽しんでいます。旅行が大好きで、最近はニッチな香水の収集を始めました。 Amit Gaur Amit は AWS の Cloud Infrastructure Architect です。テクノロジーと知識共有への情熱を持って、ネットワーキングコミュニティに貢献しています。ネットワークアーキテクチャ設計を専門とし、お客様が AWS 上で高いスケーラビリティと回復力を備えた環境を構築できるよう支援しています。技術的なガイダンスとアーキテクチャの専門知識を通じて、お客様のシステムのスケーラビリティと信頼性を確保しつつ、クラウド導入の加速を後押ししています。 Jesse Lepich Jesse は、ミズーリ州レイクセントルイスを拠点とする AWS の Senior Security Solutions Architect です。お客様が AWS ネイティブのセキュリティサービスを導入できるよう支援することに注力しています。クラウドセキュリティ以外の趣味は、家族とのんびり過ごすこと、ベアフット水上スキー、スノーボード、スキー、サーフィン、ボート、登山です。 Preetkumar Shah Preetkumar は、ジョージア州アトランタを拠点とする AWS の Technical Account Manager です。お客様がクラウドで安全かつスケーラブルなネットワークアーキテクチャを設計、運用できるよう支援することを専門としています。AWS では中堅・中小企業 (SMB) のお客様を担当し、サービスチームと緊密に連携して複雑な課題をプロアクティブに解決することで、お客様が AWS 環境を最大限に活用できるよう支援しています。仕事以外では、家族と過ごすことやトレイルを歩くことを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 11 月 6 日に Kiro ブログで公開された「 How Kiro Auto uses model cascading to match the model to the work 」を翻訳したものです。 TL;DR： Auto は裏側でモデルカスケードを使っています。どのセッションも効率のよい最初のモデルで始まり、独立したチェックがバックグラウンドで作業を確かめ、必要になったときに Auto はセッションをより高性能なモデルに引き継ぎます。DeepSWE v1.1 を使った社内の評価では、カスケードは高性能なモデル単独とほぼ同じ成績を出し、タスクの約 5 件に 4 件は引き継ぎなしで完了しました。 Kiro では、ほとんどの方に Auto での作業をおすすめしています。 モデルのドキュメント にあるとおり、Auto がユーザーに代わってモデルを選び、高い品質の基準を保ちます。有料プランでは、その基準は Claude Opus クラスの品質です。この記事では、Auto がその基準を満たすための方法の 1 つである、モデルカスケードという手法を紹介します。 難しさはセッションが進むにつれて見えてくる Kiro に、不安定な日付パーサーの修正を頼んだとします。最初の手順は決まりきった作業です。ファイルを読み、関数を見つけ、不具合を再現する、失敗するテストを書きます。ところがそのテストで、ほかの 3 つのモジュールにまたがるタイムゾーンの前提が見つかり、小さな修正がリファクタリングに変わります。逆のことも起きます。大きく見えたタスクが、2 行の変更で済むこともあります。 モデルの性能が上がるにつれて、より大きな仕事を任せるようになり、Kiro のセッションは長くなっています。手順の多い長いセッションは、ファイルを読み、コードを編集し、テストを実行し、やり直すといった多くの手順を踏みます。その難しさは、始まった時点では決まっていません。セッションの難しさには形があり、その形は進めてみて初めて見えてきます。図 1 では、同じセッションを 3 通りのやり方で進めています。 図 1: 難しさはセッションが進むにつれて現れるため、最初に 1 回だけ選んだモデルでは、簡単な区間で性能が余るか、難しい区間で力が足りなくなります。カスケードは進めながら調整します（イメージ図）。1 枚目は途中で難しくなるセッション、2 枚目は簡単なままのセッションです。画像の右上のボタンは原文のインタラクティブな図のもので、この記事では 2 つの状態を 2 枚の画像に分けて載せています。 作業を始める前にモデルを選ぶとき、判断の手がかりは依頼の内容しかありません。高性能なモデルを選べば、効率のよいモデルでも同じようにこなせた決まりきった手順も含めて、すべての手順をそのモデルが担います。効率のよいモデルを選べば、決まりきった手順はうまくこなせますが、作業が難しくなると、行ったり来たりを始めたり、すでに終えた作業をやり直したりすることがあります。次に、図 1 の 2 枚目の、簡単なままのセッションを見てください。依頼が同じなので、最初に選ぶモデルは変わりません。カスケードは最後まで最初のモデルのままです。セッションが、そのモデルで扱える以上に難しくならないからです。 Auto のモデルカスケードのしくみ モデルカスケードは、1 回のモデルの選択を、エージェントのセッション全体を通して行う一連の判断に変えます。 効率のよいモデルで始める。 どのセッションも最初のモデルで始まります。最初のモデルは、日常的な幅広い作業をうまくこなす効率のよいモデルです。多くのセッションでは、このモデルが適切な選択で、作業のすべてをこなします。 バックグラウンドで作業を確かめる。 独立したモデルが、セッションの軌跡、つまりここまでに行われた作業を確かめます。チェックは非同期に動くので、セッションがチェックを待つことはありません。また、作業しているモデルが自分の進み具合を採点することもありません。 そのまま続けるか、引き継ぐ。 セッションが着実に進んでいるあいだは、何も変わりません。セッションが効率よく進まなくなった兆し（同じコードを繰り返し調べる、すでに終えた作業をやり直す、など）をチェックが見つけると、Auto はセッションをより高性能なモデルに引き継ぎます。引き継ぎではここまでの作業の要点が受け渡されるので、より高性能なモデルは最初からやり直すのではなく、今の状態のセッションをそのまま引き継ぎます。 必要に応じて繰り返す。 引き継ぎは、セッションが最も高性能なモデルで動くようになるまで繰り返し起こりえます。現時点では、引き継ぎは上の方向にだけ行われます。セッションを効率のよいモデルへ戻すことは、今後のアップデートで検討します。 モデルへのアクセスを管理しているチームでは、引き継ぎ先も Auto が使えるモデルの中から選ばれるので、引き継ぎにも Auto と同じガバナンスの設定が適用されます。管理者がモデルへのアクセスをどう制御するかは、 モデルのガバナンス をご覧ください。 図 2: Auto のモデルカスケードでは、最初のモデルがセッションを始め、独立したチェックがバックグラウンドで作業を確かめます。より高性能なモデルがセッションを引き継ぐのは、その必要がある兆しをチェックが見つけたときだけです。これは考え方を示したイラストで、実際のチェックの動き方を表したものではありません。 担当のエンジニアがチケットに取り組み、その肩越しにレビュアーが作業を見ている場面を考えてみてください。エンジニアは作業を続け、手を止めて自分の進み具合を採点することはありません。それはレビュアーの仕事です。作業が前に進んでいるあいだ、レビュアーは何も言いません。作業が同じところを回り始めたとレビュアーが気づいた時点で、チケットはより腕の立つエンジニアに渡り、そのエンジニアが今の状態から引き継ぎます。 カスケードを既定で動かしても安全なのは、このしくみがあるからです。作業しているモデルは自分の進み具合を採点せず、引き継ぎは最初からやり直すのではなく、すでに終えた作業の上に積み上げます。より高い性能が必要なセッションは途中でその性能を得られ、必要のないセッションは最初のモデルのまま進みます。 測定したこと カスケードを、Datacurve による、手順の多い長いタスクを扱うソフトウェアエンジニアリングのベンチマークである DeepSWE v1.1 で評価しました。タスクはこのベンチマークのために新しく作られたもので、オープンソースのリポジトリを題材にし、人が書いた、動作を確かめるテストで採点されます。そのため、難しさが途中で変わりうる、何段階にもわたるセッションが必要になります。Kiro のエージェントエンジンで 3 つの構成を動かし、それぞれの構成でベンチマーク全体を 3 回ずつ、独立に実行しました。 最初のモデルのみ。 すべてのタスクを、効率のよい最初のモデルで最初から最後まで実行します。 高性能なモデルのみ。 すべてのタスクを、より高性能なモデルで最初から最後まで実行します。 カスケード。 すべてのタスクを最初のモデルで始め、より高性能なモデルへ引き継げる状態にしておきます。 3 つの構成とも、推論（reasoning）の設定は同じです。違いは、どのモデルが作業を担うかだけです。結果は pass@1（1 回の試行で解けたタスクの割合）を、3 回の実行の平均 ± 1 標準偏差で示します。 高性能なモデル単独とほぼ同じ品質 図 3 は 3 つの構成の pass@1 を比べたもので、その下の表に同じ値を載せています。 図 3: DeepSWE v1.1 で、カスケードの pass@1 は 69.37% でした。高性能なモデル単独（70.57%）とほぼ同じで、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。エラーバーは 3 回の実行の ± 1 標準偏差を示します。 構成 pass@1（3 回の実行の平均 ± 1 標準偏差） 最初のモデルのみ 63.96% ± 2.70 高性能なモデルのみ 70.57% ± 2.08 カスケード（最初のモデルで始め、より高性能なモデルを使える） 69.37% ± 1.56 カスケードはタスクの 69.37% を解きました。高性能なモデル単独（70.57%）とほぼ同じで、その差は実行ごとのばらつきの範囲内です。また、最初のモデル単独（63.96%）より 5.40 ポイント高い値です。3 つの構成のうち、実行ごとのばらつきが最も小さかったのもカスケードでした。つまり、すべてのタスクを最初のモデルで始めても、それが品質の足かせにはなりませんでした。 約 5 件に 4 件は引き継ぎなしで完了 図 4 は、カスケードのタスクがどのモデルで終わったかを示しています。 図 4: DeepSWE v1.1 の 3 回の実行を通して、タスクの 80.48% は最初のモデルだけで完了し、19.52%（約 5 件に 1 件）はより高性能なモデルに引き継がれました。 すべての実行を通して、タスクの 80.48% は最初のモデルで完了しました。残りの 19.52%、約 5 件に 1 件は、途中でより高性能なモデルに引き継がれました。 今回の DeepSWE の実行では、引き継がれたタスクには共通点がありました。最初から最後まで正しく仕上げるのが難しい変更だったことです。たとえば、型や API から CLI や設定まで、多くの層に同時に触れる機能や、保存された状態やキャッシュ、処理の順序に左右される振る舞いです。小さく局所的な変更で引き継ぎが必要になることはまれでしたが、大きな変更が必ず引き継ぎを必要としたわけでもありません。分かれ目になったのは、注意深い設計や、コードの複数の部分のあいだで整合性を保つことが、作業のどれだけを占めていたかでした。 引き継ぎが起きたタイミングにも、同じくらいはっきりした傾向がありました。これらのタスクでは、最初のモデルはほぼ必ず、序盤の手順を自力でこなしていました。コードを書き、多くの場合はビルドとテストを通すところまで進めています。引き継ぎは、そのあとの検証と統合の段階で起きる傾向がありました。最初のモデルが、変更したコード全体ですべての要件が満たされていることを示そうとしている段階で、セッションが効率よく進まなくなった兆しをチェックが見つけたのです。こうしたことは、どれも依頼の内容からは分かりませんでした。チェックが見守り続け、セッションが必要とするどの時点でも引き継ぎが起こりうるので、カスケードは作業がいつ難しくなるかを前もって知る必要がありません。 Auto がクレジット倍率 1x のまま複雑な作業を高い品質でこなせるのは、これが理由の 1 つです。ほとんどのセッションは最初のモデルで完了し、より高性能なモデルが引き継ぐのは作業上必要なときだけです。 ベンチマークの数値についての注意 これらの数値は、社内の評価用ベンチマークの、ある特定の実行で得られたものです。本番環境での見込みではなく、お客様ごとの実際のワークロードでの結果は異なります。 引き継ぎの割合はタスク全体の平均です。セッションがどれくらいの頻度で引き継がれるかは作業によるので、個々のセッションでは異なります。引き継ぎはユーザーには見えません。引き継ぎが起きていることを意識しなくても、品質の面での効果を得られます。 DeepSWE の数値は社内のベンチマーク用の実行環境（ハーネス）で測ったもので、公開されている DeepSWE のリーダーボードの公式の設定と同じではありません。そのため、割合を公開のリーダーボードの数値と比べることはできません。 試してみる モデルカスケードは Auto のしくみの一部で、効率の面での利点はすべての Kiro のお客様が利用できます。次にセッションを始めるときは、 Kiro で Auto を選んでください。Auto とモデルの選択のしくみについては、ドキュメントの モデルの概要 をご覧ください。 原文の著者 Vijay Lingam（Applied Science）、Mayank Gupta（Applied Science）、Sudipto Nandi（Engineering）、Neil Kulkarni（Engineering）、Jack Wang（Engineering）、Sai Srinivas Somarouthu（Engineering） 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

本記事は 2024 年 2 月 16 日に公開された” Enhance your AWS cloud infrastructure security with AWS Managed Services (AMS) “を翻訳したものです。 はじめに セキュリティやデータ損失インシデントは、金銭的損失と社会的信用の失墜につながる可能性があります。セキュリティとコンプライアンスは、AWS とお客様の間における責任共有により維持されます。この責任共有では、AWS は「クラウドのセキュリティ」に責任を持ち、お客様は「クラウドにおけるセキュリティ」に責任を持ちます。しかし、クラウドにおけるセキュリティは、特にクラウドインフラおよびオペレーティングシステム(OS)レベルにおいて、より広い範囲に及びます。クラウドにおいて、セキュアでコンプライアンスに準拠した監視環境を大規模に構築するには、高度な自動化、人的リソース、およびスキルが必要です。 このブログでは、「クラウドにおけるセキュリティ」を向上させるために AWS サービスを組み合わせて活用する方法を紹介します。多くの組織にとって、スキル不足やビジネスにおける優先順位により、セキュリティのベストプラクティスを大規模に順守し、導入することは容易ではありません。 AWS Managed Services （AMS）が大規模にお客様の AWS インフラのセキュリティおよびコンプライアンス体制を強化してきたベストプラクティスをご紹介します。AMS は、モニタリング、インシデント管理、セキュリティ、パッチ適用、バックアップ、コスト最適化にわたって AWS クラウドでの運用上の優秀性を達成するための能動的・予防的・検出的な機能を提供します。これにより、お客様はイノベーションに集中できます。 例えば、Coinhako が AMS を運用パートナーとして AWS に移行した際、CTO の Gerry Eng 氏は次のように述べています。「AMS に標準搭載されている数多くのセキュリティ機能は、我々が独自に適切に展開するには数ヶ月、場合によっては数年かかっていたでしょう。」詳細は ケーススタディ をご覧ください。 AWS におけるクラウドセキュリティ管理 予防（Prevention） 「予防は治療に勝る」と言われています。セキュリティ体制を改善し、問題を予防するための領域には、アイデンティティとアクセス管理（ IAM ）、受信 （Ingress）と送信 （Egress）トラフィックの保護、バックアップおよび災害復旧、そして脆弱性への対処があります。 AWS は AWS IAM とサービスコントロールポリシー（ SCPs ）を組み合わせてクラウドリソースへのきめ細かいアクセス制御を提供しています。AWS は IAM サービスのセキュリティベストプラクティス を公開しています。しかし、お客様がその最適な利用状況を長期にわたって監視・統制することは容易ではなく、結果として不正なアクセスや不要なアクセスを招いてしまうことが少なくありません。AMS を活用することで、IAM の変更が AWS のベストプラクティスや AMS の技術基準に適合しているかを継続的に検証することが可能です。また、AMS はカスタム AWS Config ルールを使用して IAM のガバナンスコントロールのベストプラクティスを実装し、異常または逸脱を積極的に検出・修正します。 受信 （Ingress）と送信 （Egress）トラフィックの観点から、エッジネットワークで AWS WAF （Web アプリケーションファイアウォールサービス）を使用して、Web アプリケーションリソースへ届く HTTP/HTTPS リクエストを検査することができます。AWS WAF は Amazon CloudFront 、 Application Load Balancer （ALB）、 Amazon API Gateway などほとんどの AWS 外部向けサービスとネイティブに統合されています。ネットワーク層では、 AWS Network Firewall を使用してファイアウォールルールを定義し、すべての受信 （Ingress）と送信 （Egress）ネットワークトラフィックをきめ細かく制御できます。Network Firewall は AWS Firewall Manager と連携して、複数の VPC およびアカウントにわたってポリシーを一元的に適用します。AMS は AWS ベストプラクティスを使用して、これらのサービスを継続的にセットアップおよび運用するサポートを提供します。 さらに、定期的なパッチ適用は脆弱性に対する最も効果的な予防策の一つです。 Ponemon Institute の調査によると、「侵害被害者の 60% は、パッチが未適用の既知の脆弱性を悪用されて侵害された」と述べています。OS レベルでは、最新の脆弱性から保護するための完全なパッチ管理のために AWS Systems Manager の Patch Manager サービスを活用できます。継続的な脆弱性管理には、 Amazon Inspector サービスで、OS の脆弱性のスキャン・特定ができます。しかし、パッチスケジュールの設定、パッチコンプライアンスのレポート、および大規模なパッチ失敗への対応は、困難ではあるもののビジネス上の差別化に繋がらないタスクとみなされることがあります。AMS は自動化とベストプラクティスを駆使し、大規模環境においても、これら一連の作業をお客様に代わって実行します。AMS は Inspector またはお客様のツールによって報告された高リスクまたはゼロデイ脆弱性に対処するための臨時パッチ適用も実行できます。また、AMS を活用して Security Technical Implementation Guide （ STIG ）ベンチマークに準拠したセキュリティが強化された OS の Amazon Machine Images（AMI）を構築し、安全な EC2 インスタンスをデフォルトで保護することもできます。 最後に、インシデント時のデータ損失に対して、堅牢なバックアップおよび災害復旧戦略が不可欠です。 AWS Backup と AWS Elastic Disaster Recovery を組み合わせて AWS クラウドのデータを保護できます。大規模な環境において、バックアップ計画の設定とバックアップコンプライアンスの継続的な監視は複雑になることがあります。AMS は継続的なバックアップの監視・管理を支援するだけでなく、ランサムウェア保護プランを含むデータ復旧のビジネスユースケースに対応した複数のバックアップ計画を提供します。定期的なバックアップのテスト・復元は、予期せぬ問題発生時のビジネスサービスのダウンタイムを最小化するための重要な実践です。AMS はインシデント時の平均復旧時間（MTTR）を短縮するためのサービス復旧に関する SLA を提供します。AMS はお客様のチームとともに、侵害インスタンスやランサムウェアイベントなどのシナリオをシミュレートするセキュリティおよび運用重視のゲームデー（模擬訓練）を実施します。 検出（Detection） クラウド環境を継続的に監視して異常や潜在的な悪意ある活動を積極的に検出・封じ込め・修正することは非常に重要です。AWS は、ログやイベントの処理、およびモニタリングを通じて、監査、自動分析、アラーム通知を可能にするさまざまな検知統制を実装するためのサービスを提供しています。例えば、 Amazon GuardDuty は機械学習（ML）ベースの脅威検出サービスで、アクセス関連アクティビティと不正な動作を継続的に監視して AWS アカウントのワークロードを保護します。GuardDuty は Amazon Macie と組み合わせることができます。Macie はデータセキュリティサービスで、ML とパターンマッチングを使用して AWS アカウント内の機密データの検出・保護を行います。 AWS Security Hub CSPM はクラウドセキュリティ体制管理（CSPM）サービスで、セキュリティのベストプラクティスチェックを実行し、AWS およびサードパーティサービスからのアラートを集約し、修復手順を提案します。しかし、多数の AWS アカウントにわたってこれらのアラートを処理し、修復を実施することは、運用上すぐに困難な状況になることがあります。 AMS は Amazon GuardDuty を活用して、お客様が契約しているすべての AWS アカウントの脅威を監視し、そこから生成されるすべてのアラートを 24 時間 365 日体制でレビューします。AMS は GuardDuty アラートを分析する自動化技術を駆使し、誤検知を減らして、初期トリアージ（優先度判定）を行い、インシデント通知の一環として実用的な対応策を提供します。重大な問題については、AMS は積極的にお客様と連携して共同セキュリティ調査を実施し、修復に必要な承認を取得します。AMS は Amazon Macie の検出結果を監視し、お客様に代わって必要な修復を実施することもできます。 モニタリングとインシデント対応（Monitoring and Incident Response） Amazon CloudWatch はオブザーバビリティのための AWS ネイティブの基盤サービスで、インフラ、アプリケーション、およびエンドユーザーモニタリングにわたる機能を提供します。Systems Manager の OpsCenter により、オペレーションスタッフは CloudWatch や AWS Config などのサービスによって特定された運用上の問題を表示・調査・修復できます。Systems Manager の Incident Manager 機能は、自動化された対応計画を使用して重要なアプリケーション問題をより迅速に解決するのに役立ちます。OpsCenter と Incident Manager は、Atlassian Jira や ServiceNow などの ITSM およびチケットシステムと統合して、お好みのツールでインシデントの包括的なビューを提供します。Incident Manager は Amazon Q Developer in chat applications とも連携しており、Slack、Microsoft Teams のようなコラボレーションツールを使用して、インシデントの調査や修復対応を行うことができます。(※1) AMS は、世界各地の複数のサイトに配置されたエンジニアによる 24 時間 365 日のセキュリティ監視とインシデント対応を通じて、クラウドでの運用上の優秀性の達成を支援します。アラートとイベントは AWS Config、Amazon GuardDuty、Amazon Macie、Amazon CloudWatch、 AWS CloudTrail などのネイティブサービスから監視されます。セキュリティインシデント対応（ SIR ）については、AMS は事前定義された National Institute of Standards and Technology （NIST）準拠のランブック（対応手順書）に従い、セキュリティアラートに対して、特定・分析・封じ込め・根絶・復旧の対応を行います。AMS は Systems Manager の OpsCenter を使用してすべての運用項目をログに記録し、AWS サポートケースを通じて通知し、お客様のチームと連携して解決します。Security Incident and Event Management （SIEM）や Endpoint Detection and Response （EDR）などサードパーティまたは自社開発のセキュリティツールを使用している場合、AMS はそれらによって報告された OS および AWS インフラ関連の検出結果を修復する支援も行うことができます。また、 AWS Service Management Connector を ServiceNow や Atlassian Jira などの ITSM ツールと統合して、AMS とのシームレスなインシデント・チケット対応を実現することもできます。(※2) コンプライアンス（Compliance） AWS の責任共有モデルの下、お客様はゲスト OS、アプリケーションソフトウェア、および AWS アカウント内の AWS サービスの設定と選択に関して、セキュリティとコンプライアンスの責任を負います。さらに、ビジネスニーズに応じて幅広いローカル・グローバルのコンプライアンスフレームワークに準拠する必要があり、それらのフレームワークを AWS セキュリティコントロールにマッピングすることは困難な場合があります。 AMS を使用することで、AWS における全体的なセキュリティ体制を強化するだけでなく、必要なコンプライアンスレベルへの到達を加速できます。まず、AMS というサービス自体が、 HIPAA 、 SOC 、 ISO27001 、 FedRAMP 、 IRAP 、 NIST 、 PCI-DSS 、 GDPR など、多くのグローバルなコンプライアンスフレームワーク、規制、セキュリティ基準に適合し、準拠しています（詳細は AWS コンプライアンスセンター を参照）。そのため、AMS によって管理されるクラウド環境は、特定のコンプライアンス要件や規制要件が求められるアプリケーションをホストするのに適しています。 次に、AMS では利用開始初日から、AWS Config を活用することで、CIS、NIST、PCI、HIPAA という、極めて厳格かつ多岐にわたる 4 つのグローバル・セキュリティ・フレームワークに対するお客様のセキュリティ体制を完全に可視化できます。AMS は、厳選された AWS Config Rules をデプロイし、お客様のアカウント内のリソース状態を継続的に監視することで、これらのコンプライアンス基準やフレームワークの要件への準拠を維持します。これらのルールは、ビジネスのニーズに応じて、自動修復を行うか、インシデントやレポートとして通知を行うかのいずれかに設定することが可能です。例えば、AMS では、AMS アカウント内で AWS CloudTrail によるログ記録がデフォルトで有効化されており、これが必要なときにいつでも行えるレポート作成、アラート通知、および監査に利用されます。この設定だけでも、セキュリティ基準である NIST SP 800-53 の監査と責任（AU）コントロールファミリーにおける AU-06/07（a-c, 1-4） や、ISO 27001 のコントロール A.12.4.1-3 といった複数の管理策を満たす上で有効です。 さらに、AMS はコンプライアンス要件を強化するために、OS レベルと AWS アカウントレベルの両方において、中央集権型のログ記録および監査コントロールを実装しています。AWS アカウント内で行われたユーザーアクセスや変更に関する監査レポートは、 Amazon Athena コンソール経由で、AMS が事前構築した厳選されたクエリを使用して簡単に抽出することができます。 レポートとガバナンス（Reporting &amp; Governance） AWS クラウド環境全体におけるセキュリティ体制や潜在的なリスクを測定・追跡するためには、強固なレポート機能とガバナンスの実践が不可欠です。Key-Value のペアを使ってメタデータを作成する AWS Resource Tagging は、監査、自動化、およびコスト配分を通じて、運用上の優秀性を達成するために極めて重要な役割を果たします。例えば、AWS のメタデータやタグの値は任意の AWS ストレージサービスにエクスポートすることができます。これにより、 AWS Glue 、 Amazon Athena 、 Amazon Quick Sight といったサービスを活用して、パッチ適用状況やセキュリティコンプライアンスのカバー率に関するレポート、あるいはその他のダッシュボードを構築できます。 AMS は、OS のパッチ適用レベル、バックアップのカバー率、および高緊急度のインシデントに関するレポートを、毎週・毎月セルフサービスで提供します。また、お客様専任の AMS Cloud Service Delivery Manager（CSDM）と Cloud Architect（CA）が信頼できるアドバイザーとして、月次ビジネスレビューを主導します。このレビューでは、管理されているすべての AWS アカウントを横断した中央集中型の追加レポートが提供されます。月次ビジネスレビューには、 AWS Well Architected Framework の各柱にわたる主要なクラウド運用リスクへの洞察と高緊急度のアラートに対処するための将来的な計画が含まれています。 AMS のタグまたはお客様独自のカスタムタグを強制適用するために、AMS 管理下にある AWS リソースでは、AMS が提供する Resource Tagger ツールを活用できます。監査やレポート作成に加えて、AMS 固有のタグを使用することで、アクセス制御、監視、パッチ適用、バックアップ、および自動修復にわたる自動化アクションが可能になります。この AMS Resource Tagger とお客様のカスタムタグを組み合わせることで、クラウドガバナンスのための強固なタグ付け戦略を構築できます。 セキュリティオンデマンド（Security On-Demand） AMS は、 Operations on Demand （OOD）サービスを通じて、必要なときに拡張セキュリティサポートを提供しています。AMS OOD を活用することで、AWS サービスに関する変更を行い、AWS クラウドにおけるセキュリティ体制をさらに向上させることができます。このサービスには、既知の、あるいは未対策のセキュリティ脅威から保護するためのセキュリティ関連サービスカタログが含まれており、AWS Network Firewall の運用や、サポート終了が迫っているレガシー OS のアップグレードなどに対応しています。 おわりに 本記事では、AWS クラウドにおけるセキュリティ体制を強化するために実装できる、予防・検出・対応の管理を含む、多くの不可欠なセキュリティベストプラクティスを検討しました。また、お客様の AWS クラウド環境を管理することで、求められる「クラウドにおけるセキュリティ」を実装する信頼できるパートナーとして、どのように AMS を活用できるかを説明しました。AMS は、AWS のベストプラクティスを用いた複数のガードレールの実装に加え、24 時間 365 日のセキュリティインシデント対応および復旧を行うことで、クラウドのセキュリティ体制を強化します。さらに、AMS は初日からお客様の AWS アカウントにログ記録、監査、監視に関する多くの必要なセキュリティ統制とベストプラクティスの導入を支援し、コンプライアンスへの取り組みを加速させます。 セキュリティ特有の機能にとどまらず、AMS はインフラや OS の能動的な監視、アラートの自動復旧、コスト最適化、そして継続的なガバナンスの組み合わせにより、大規模なお客様の AWS クラウド環境における運用上の優秀性の達成を支援します。詳細については、 AWS Managed Services の製品ページをご覧ください。 ※1 2025 年 11 月 7 日に AWS Systems Manager Incident Manager は新規のお客様への提供を終了しました。AWS は引き続き Incident Manager のセキュリティと可用性への投資を継続し、既存の Incident Manager のお客様は、すでに Incident Manager が有効化されているアカウントにおいて、これまで通りサービスを引き続きご利用いただけます。 ※2 2026 年 3 月 31 日に AWS Service Management Connector は新規のお客様への提供を終了しました。既存のお客様は、2027 年 3 月 31 日までサービスを引き続きご利用いただけます。2027 年 3 月 31 日以降、AWS Service Management Connector の機能にアクセスすることはできなくなります。AWS パートナーソリューションへの移行、または直接的な SDK 統合の構築をお勧めいたします。 翻訳はシニアオペレーションズマネージャーの木村が担当しました。 原文はこちら です。 Nitin Verma Nitin は、クラウドオペレーション、自動化、セキュリティにおいて 10 年以上の専門知識を持つプリンシパルソリューションアーキテクトです。お客様が運用上の優秀性を達成し、AWS 上でのクラウドジャーニーを加速できるよう支援することを専門としています。Nitin の重点分野には、クラウドアーキテクチャ、IaC（Infrastructure as Code）、DevSecOps、AIOps などの新興テクノロジーが含まれます。 LinkedIn でフォローできます。 Amit Gupta Amit は、インフラストラクチャセキュリティオペレーションおよび AWS Managed Services（AMS）を専門とするシニアセキュリティエンジニアです。サイバーセキュリティにおいて 10 年以上の経験を持っています。セキュリティインシデント対応やセキュリティリスク管理のバックグラウンドを有しています。適切な戦略と設計により、お客様のサイバーセキュリティリスクを最小限に抑えることを支援することに注力しています。 TAGS: AWS Managed Services (AMS) , Cloud Operations , Management and Governance , Security

本稿は、株式会社両備システムズ ガバメントクラウド推進室 岩倉 竜太 氏による寄稿です。 ※本記事でご紹介する効果は、両備システムズの環境における実績であり、すべてのお客様で同等の効果を保証するものではありません。 はじめに みなさん、こんにちは。株式会社両備システムズでガバメントクラウドの構築・運用を担当している岩倉と申します。私たちは、岡山県を基盤に全国の地方自治体の情報システムを支援しており、現在はデジタル庁が提供するガバメントクラウド上で、複数の地方公共団体の業務システムを運用しています。 図表１：株式会社両備システムズ事業紹介 当社は、行政、医療、ヘルスケアなど、地域社会を支える幅広い分野でシステムを提供しています。 私たちがご支援している地方自治体のシステムは、ガバメントクラウドの「共同利用方式」のうち「ネットワーク分離方式」を採用しています。これは、1つのAWSアカウント（LinkedID）を複数の団体で共同利用し、団体ごとにVPC（Virtual Private Cloud）を分離して構成する方式です（図表2）。各団体のリソースはコスト配分タグ（以下、タグ）で識別し、利用状況に応じて費用を按分しています。現在、複数の地方公共団体のシステムを本方式で運用しています。 図表２：ガバメントクラウド共同利用（ネットワーク分離方式）のアーキテクチャ ※本図は考え方を示す概念図であり、実際のシステム構成を示すものではありません。 ガバメントクラウドへの移行が進むにつれ、多くの自治体にとってクラウド利用料の最適化が共通の課題となっています。中でも Amazon EC2 や Amazon RDS といったコンピューティング・データベースの利用割合は大きく、ここに「長期継続割引」（Savings Plans および Reserved Instance）を適切に適用できるかどうかが、コスト最適化の成否を大きく左右します。 一方で、「ネットワーク分離方式では長期継続割引を適用できないのではないか」という声を耳にすることがあります。単独利用方式やアカウント分離方式にはない課題があるなど、適用にあたり検討する要素が多いことは事実です。しかし、AWSの仕様を正しく理解し、利用状況や将来計画を踏まえて長期継続割引を適切に活用することで、ネットワーク分離方式においてもクラウド利用料の削減が期待できます。本記事では、私たちがどのようにこの課題と向き合い、実践してきたのかをご紹介します。 コスト最適化の取組みの経緯 私たちがコスト最適化に本格的に取り組み始めたのは、ガバメントクラウドでの運用を開始し、システム運用が安定した時期からです。移行の初期は、まず安定稼働を最優先に環境を構築し、運用が軌道に乗った段階で、クラウド利用料の最適化の取組みを本格化しました。具体的には、2025年度を検討・準備の期間と位置づけ、2026年度は4月1日から長期継続割引を適用できるよう準備を進めてきました。 自治体情報システムの標準化においては、移行後の運用経費を含めたコストの適正化が重要なテーマとなっています。当社においても、この趣旨を踏まえ、クラウド利用料の継続的な最適化に取り組みました。当社が運用する環境には、原則として24時間365日のサービス提供を前提とする業務システムがあるため、稼働時間の調整だけでなく、長期継続割引の活用も必要と考えました。コスト最適化に向け、Cost Explorerを中心としたコストの可視化・分析、インスタンス等のAWS環境の見直し、そして本記事の主題である長期継続割引の適用に、段階的に取り組んできました。2026年度からは、AWS Cost and Usage Report（CUR）等の利用データを基に、各団体の利用状況を確認しています。また、割引適用後の費用については、契約条件および当社が定める算定方法に基づき、各団体への説明可能性を確保しながら取り扱っています。AWSの各種分析・推奨情報も参考にしながら、アプリケーションの性能要件や運用条件、検証結果を総合的に確認し、最適化方針を判断しています。 長期継続割引適用に向けた課題と解決方策 ネットワーク分離方式ならではの課題 長期継続割引（Savings Plans / Reserved Instance）は、1年または3年の期間にわたり、一定の時間当たり利用額または対象リソースの利用をコミットすることで、オンデマンド料金より低い料金が適用される料金モデルです。ガバメントクラウドでは、デジタル庁のガイドラインに基づき、Amazon EC2についてはCompute Savings Plansを、Amazon RDSについてはReserved InstanceまたはDatabase Savings Plansを、いずれも前払いなし（No Upfront）で利用できます。（購入可能なプランや期間などの詳細は、デジタル庁のGCASガイドに掲載されています。参考として本記事にも一覧を掲載します。） （出典）内閣官房「国・地方デジタル共通基盤推進連絡協議会ワーキングチーム（第10回）」 図表３：ガバメントクラウドにおける長期継続割引の適用方針 ネットワーク分離方式には、単独利用方式やアカウント分離方式とは決定的に異なる難しさがあります。それは、長期継続割引が「アカウント単位」で適用されるという AWS の仕様です。 具体的には、次のとおりです。 ・&nbsp;&nbsp;&nbsp; 長期継続割引は、AWS 側のロジックに基づき、購入条件に合致する利用へ自動的に適用されます。タグを付けて購入した場合でも、タグ単位で割引の適用先を指定することはできません。 ・&nbsp;&nbsp;&nbsp; Savings Plans の使用率（Utilization）レポートやカバレッジ（Coverage）レポートも、アカウントやリージョン、インスタンスファミリー単位での表示となり、タグ単位（＝団体単位）での内訳は確認できません。 ・&nbsp;&nbsp;&nbsp; 単独利用方式やアカウント分離方式では、AWSアカウント が団体ごとに分かれているため、割引はその団体のアカウントに正確に反映されます。 しかしネットワーク分離方式では、1つの AWSアカウント を複数団体で共有しているため、「この団体に、この割引を」とタグ単位で割り当てることが仕組み上できないのです。 私たちはこの点を正しく理解したうえで、「だから適用できない」と諦めるのではなく、「どうすれば使いこなせるか」という視点で戦略を組み立てました。 長期継続割引適用に向けた戦略と実行 私たちは、長期継続割引の購入を次の検討ステップに沿って進めています。各ステップで、ネットワーク分離方式ならではの難所をどう乗り越えたかをご紹介します。長期継続割引の適用方針は、まず当社で取りまとめたうえで各自治体に説明し、合意を得たうえで進めています。 STEP0：コミット前の最適化 長期継続割引の購入前に、まず不要なリソースの削除やインスタンス構成の見直しなどを実施し、環境の最適化を十分に行います。最適化しないままコミットすると、過大な利用量を前提とした契約となり、無駄なコストを長期間固定化してしまうためです。 また、RDSについては、現行構成をそのまま長期継続割引の対象とするのではなく、費用対効果、性能要件、動作条件および今後の構成変更の可能性を確認しました。そのうえで、本番稼働前の環境については、検証結果を踏まえて第7世代のDBインスタンスファミリーへ変更しています。 このように、長期継続割引の購入を検討する前に、継続利用するリソースと今後変更する可能性があるリソースを整理しました。これにより、最適化後も安定的に利用することが見込まれる範囲を見極め、必要以上のコミットを行わないようにしています。 STEP1：購入量（ベースライン）の決定 次に、どれだけの利用量をコミットするかを決めます。私たちは、Cost Explorerのデータをもとに、毎時の最小利用量であるベースラインを見極め、コミット額を算定しています。具体的には、1時間当たりの利用実績を把握したうえで、ガバメントクラウドの料金体系やGCASガイド等を参照し、購入量を検討しました。 Compute Savings Plansについては、稼働中のインスタンスをタイプ別に把握し、24時間連続して稼働する利用量を基準として、Savings Plans適用後の時間単価を積み上げています。ただし、現在の利用量のすべてを対象とするのではなく、構成変更や利用量の変動があった場合にも継続して利用することが見込まれる範囲をベースラインとしています。 RDSについては、Reserved DB Instanceの購入条件と、共同利用アカウント全体における継続的な利用量を確認しました。本番環境については、DBエンジン、DBインスタンスクラス、リージョン、配置方式および数量等を確認し、第6世代のDBインスタンスファミリーを使用し、継続的に稼働する本番環境の利用量を基に、条件に合致するReserved DB Instanceを購入しています。 Reserved DB Instanceの割引は、特定の団体や特定のDBインスタンスを指定して適用するものではなく、共同利用アカウント内で購入条件に合致する利用へ自動的に適用されます。このため、個別の団体やリソースを基準とするのではなく、共同利用アカウント全体で継続的に利用することが見込まれる本番利用量を基に購入量を決定しました。 なお、本番稼働前の環境は、STEP0で記載した構成の最適化を行うとともに、今後も構成を変更する可能性があります。変更後を含めた継続的な利用量を現時点で確定することが難しいため、RDSに対するDatabase Savings Plansは2026年度の購入対象としていません。 STEP2：長期継続割引の購入オプションの選択 デジタル庁のGCASガイドに従い、Amazon EC2 については Compute Savings Plans を利用します。Compute Savings Plans はインスタンスファミリーやリージョン、OS、対象サービスを跨いで柔軟に適用されるため、将来のモダン化にも対応しやすいという利点があります。RDS についてはReserved Instanceを選択しています。期間は1年を基本とし、前払いなし（No Upfront）で購入しています。期間を1年としているのは、デジタル庁のGCASガイドに沿った判断です。多くの環境では3年先までの運用状況を見通すことが難しいため、まずは1年での購入を基本としています。 STEP3：年に一度の購入オペレーション ガバメントクラウドでは、長期継続割引の利用期間がガバメントクラウド利用権付与兼債務引受契約の期間を超えないようにする必要があります。当社の2026年度の購入においては、GCASで示された購入条件およびAWS上の基準時刻を確認し、4月1日午前9時から9時59分までの日本時間内に購入処理を完了する手順としました。Compute Savings Plansは、将来の開始日時を指定した予約購入（キューイング）が可能であるため、事前に予約内容を登録し、開始日時に購入が処理されるようにしています。一方、Amazon RDSのReserved DB Instanceは予約購入に対応していないため、上記の時間帯に担当者がAWSマネジメントコンソールから購入します。限られた時間内で誤りなく購入できるよう、購入内容の事前確認と当日の実施手順をあらかじめ整理しています。 STEP4：購入後のモニタリングと是正 購入後は、使用率（コミットをどれだけ使い切れているか）とカバレッジ（割引対象の利用のうちどれだけを割引でカバーできているか）を継続的に監視します。先に述べたとおり、これらのレポートはアカウント単位で確認するため、長期継続割引が全体として方針どおりの成果を上げているかをチェックしています。また、AWS Cost and Usage Report（CUR）等を用いて各団体の利用状況を確認し、契約条件および当社が定める算定方法に基づいて、割引適用後の費用を取り扱っています。これにより、各団体への説明可能性と透明性の確保に努めています。 取組みの効果 これらの取組みの結果、私たちは長期継続割引をネットワーク分離方式のもとでも有効に活用し、クラウド利用料の削減を実現しています。これらの取組みにより、対象となるAWS利用料について、長期継続割引適用前の料金との比較で最大20％の削減効果を確認しています。なお、削減効果は利用サービス、稼働状況、構成および為替等の条件により異なります。 また、各団体の利用状況と費用の関係を説明できるようにすることで、コストの透明性向上に取り組んでいます。 持続可能なFinOpsの推進に向けて ガバメントクラウドにおけるコスト最適化は、一度行えば終わりというものではありません。団体の増減、業務システムの更改、AWS の新しいサービスやインスタンスの登場に合わせて、継続的に見直しを続けることが欠かせません。私たちはこれを、FinOps（財務とクラウド運用を密に連携させ、継続的にコストを最適化する取組み）の実践と捉えています。 私たちが最もお伝えしたいのは、ネットワーク分離方式であっても、AWS の仕様を正しく理解すれば長期継続割引は十分に使いこなせる、ということです。「適用できない」という誤解から最適化を諦めてしまうのは、自治体にとっても事業者にとっても大きな機会損失です。 そして、持続可能なコスト最適化を実現するには、自治体と運用管理補助者である事業者が、それぞれの役割を共有し、コスト、安定運用、継続的な改善のバランスを取ることが重要です。こうした協力関係を通じて、説明可能性の高い、持続可能なガバメントクラウド運用を目指します。 本記事が、同じようにガバメントクラウドの共同利用方式でコスト最適化に取り組む事業者や自治体の皆さまにとって、最初の一歩を踏み出すきっかけになれば幸いです。 著者について 岩倉　竜太（株式会社両備システムズ ガバメントクラウド推進室 次長） 2000年入社。自治体向け健康管理システム「健康かるて」シリーズの導入・保守エンジニアとして、特別区、中核市、市町村を担当。ガバメントクラウド先行事業への参画を経て、ガバメントクラウド推進室の立ち上げからAWSを活用したガバメントクラウド環境の構築・運用を担当。現在は自治体のガバメントクラウド移行や運用最適化の推進に取り組んでいる。