2026 年 7 月 27 日週、7 歳の息子と一緒に Amazon の「子供を仕事に連れて行く日」に参加できてよかったです。私たちはニューヨーク市にあるオフィスまで一緒に通勤しました。息子にとって、ラッシュ時に電車に乗ったのはこれが初めてでした。その日は一日かけて、Amazon が AI、機械学習、ロボティクスをどのように使用して世界中の顧客に荷物を届けるかを見て回りました。ロボットがフルフィルメントセンターをナビゲートしているのを見る息子の目が輝いていました、それを見て、私たちの多くがそもそもなぜテクノロジーに夢中になったのかを思い出しました。何か複雑なことが腑に落ちたときに感じるあの驚きに勝るものはありません。 今週のローンチにも、同じエネルギーが注入されました。AI 価格設定、オブザーバビリティ、マルチクラウドネットワーク、およびデータ管理に関する最新情報をお届けします。では、早速見ていきましょう! 見出し Amazon Bedrock、OpenAI GPT‑5.6 モデルの価格を最大80%引き下げることを発表 — Amazon Bedrock を通じて OpenAI の GPT‑5.6 ファミリーを使用している場合、コストが大幅に下がることになりました。7 月 30 日より、GPT‑5.6 Luna のオンデマンド推論価格は 80%、GPT‑5.6 Terra 料金は 20% 引き下げられます。Luna は現在、100 万個の入力トークンあたり 0.20 ドル、出力トークン 100 万個あたり 1.20 ドルで、入手可能な最も手頃なフロンティアクラスモデルの1つとなっています。これらの値下げは自動的に適用されるため、ユーザー側でのアクションは必要ありません。 もっと読む  7 月 27 日週のローンチ 7 月 27 日週のローンチのうち、私が注目したリリースをいくつかご紹介します: Amazon CloudWatch がマネージド Prometheus コレクターを発表 — Amazon CloudWatch は、フルマネージドコレクターを使用して、AWSインフラストラクチャから Prometheus メトリクスを収集できるようになりました。これにより、エージェントをデプロイまたは管理することなく、Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、および Amazon OpenSearch Service のワークロードをモニタリングできるようになりました。Prometheus スクレイピングインフラストラクチャを自社で管理している場合、これにより運用上の大きな負担が軽減されます。 もっと読む AWS Interconnect — Oracle Cloud Infrastructure によるマルチクラウド接続が一般に利用可能になりました 。AWS Interconnect は、この種のマルチクラウド接続を目的とした最初の製品であり、AWSと他のクラウドプロバイダー間で、回復力がありスケーラブルなプライベート接続を迅速にプロビジョニングできます。今回の Oracle Cloud Infrastructure（OCI）向けの GA ローンチにより、パブリックインターネットを経由せずにプライベート・クロスクラウド・ネットワーキングを確立できるようになり、ワークロードに必要なセキュリティとパフォーマンスを備えたマルチクラウドアーキテクチャを簡単に実行できます。 もっと読む AWS IAM Identity Center は、マルチリージョンのサポートを Identity Center ディレクトリにまで拡張しました 。Identity Center ディレクトリをアイデンティティソースとして使用すると、プライマリAWS リージョンから他のリージョンに IAM Identity Center をレプリケートできるようになりました。IAM Identity Center がプライマリリージョンの障害の影響を受けた場合でも、ユーザーは他のリージョンのプロビジョニングされたエンタイトルメントを使用して、AWS アカウントに引き続きアクセスできます。この機能は、以前は外部 ID プロバイダーに接続されたインスタンスでのみ使用できました。 もっと読む Amazon S3 Tables が Apache Iceberg V3 のバリアントデータ型をサポートするようになりました 。Amazon S3 Tables では、Apache Iceberg V3 テーブルフォーマット仕様で導入されたバリアントデータ型のサポートが追加されました。Variant は、JSON BLOB に頼ることなく、データレイク内の半構造化データ (IoT センサーデータ、アプリケーションログ、その他のスキーマフレキシブルペイロードなど) を管理するための高性能なネイティブソリューションを提供します。 もっと読む その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: 単一行のコマンドによる AWS CLI のインストールと更新 — 開発者ツールチームによる新しいブログ投稿では、1 行のコマンドでプラットフォーム間の AWS CLI のインストールと更新を簡単にしています。CLI バージョンをチーム間または CI パイプラインで管理する場合、これは使い勝手の向上としてうれしい変更です。 Amazon SageMaker HyperPod と   Amazon EKSに Kimi K3 をデプロイ — SageMaker HyperPod と Amazon EKS を使用して、Moonshot AI の Kimi K3 モデルを AWS インフラストラクチャにデプロイするためのステップバイステップガイド。大規模なモデルデプロイオプションを検討している場合、このチュートリアルでワークフロー全体を説明します。   Amazon MSK Express ブローカーを使用して Apache Kafka データを Apache Iceberg のストリーミングテーブルに配信 — Amazon MSK Express ブローカーを使用して Apache Kafka から Apache Iceberg テーブルにデータをストリーミングする方法を学びましょう。Amazon S3 Tables で Apache Iceberg に配信する際に最大 10 GB/s のスループットがサポートされています。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、そして最新のテクノロジーを探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有、および開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 8 月 3 日週のニュースは以上です。8月10日週に再びアクセスして、新たな 1 週間のまとめをぜひお読みください! 原文は こちら です。

みなさん、こんにちは。AWS Japan ソリューションアーキテクトの瀧澤ロナンです。 スマートファクトリーが進展し、製造現場でのOT とクラウドを連携する事例が最近増えています。こうしたアーキテクチャ変更は効率化を促進する一方、システム間の接続やデータ流通の拡大に伴い、考慮すべきセキュリティ境界も増えます。そのため、OT側とクラウド側のそれぞれについて、リスクに応じたセキュリティ要件を明確にすることが重要です。 この課題に対応する上で重要な標準が、 ISA/IEC 62443 です。ISA/IEC 62443は、製造、エネルギー、公共インフラなどで利用される産業用オートメーションおよび制御システム（IACS）のサイバーセキュリティに関する国際規格シリーズであり、製造現場のシステム全体にわたるリスク管理とセキュリティ対策の枠組みを提供しています。本記事では、製造業のお客様が OT をクラウドに接続する際に特に重要となるISA/IEC 62443 の様々な概念を、AWS サービスを使ってどのように実現するのかをご紹介します。お客様は、AWS サービスを活用した製造現場向けのクラウドアーキテクチャを構成することで、ISA/IEC 62443 に沿ったクラウド側のセキュリティ対策を実装できます。 なお、本記事では、ISA/IEC 62443 でのOT とクラウドの接続に関係するゾーンとコンジット、7つの基礎的要件（FR）、可用性を考慮した設計、および関係者間の責任分担を取り上げ、シリーズ全体を解説するものではありません。ISA/IEC 62443 でのリスク評価、セキュリティレベル、個別のシステム要件、セキュリティライフサイクルなどは本記事の対象外であり、詳細については同シリーズの各規格をご確認ください。 AWS における ISA/IEC 62443 のゾーンとコンジット ISA/IEC 62443 における重要な概念の一つが、ゾーンとコンジットです。ゾーンとコンジットとはISA/IEC 62443でのシステム全体をセキュリティ要件に基づいて分割する考え方です。こちらの図ではAWS上のゾーンとコンジットの設計例を表しています。 ISA/IEC 62443 に基づくシステム設計では、共通のセキュリティ要件を持つシステム部分をグループ化し、グループごとに必要なセキュリティ境界を定義します。このグループを「ゾーン（Zone）」と言い、ISA/IEC 62443は、システム部分を具体的にどのゾーンへ分割するかを固定的に規定しておらず、製造事業者はシステムの要件に応じてどのシステム部分を含めるかを決定します。AWSクラウドに繋いでいる製造現場ではPLC やセンサーを含む制御ゾーン、データヒストリアンや生産実行システム（ MES ）を含む製造運用ゾーン、AWS IoT Core によるクラウド側の取り込みゾーン、 Amazon S3 と Amazon Athena による分析・保存ゾーンに分けることができます。ここでいうクラウド側のゾーンは、必ずしも VPC やサブネットと一致するものではなく、共通のセキュリティ要件を持つ AWS リソースをまとめた論理的な境界です。 続いてゾーン間の制御された通信経路を「コンジット（Conduit）」と呼びます。 AWS Site-to-Site VPN や AWS Direct Connect などの通信経路そのものがコンジットになるのではなく、通信経路と、その経路に適用する認証、暗号化、アクセス制御などを合わせてコンジットとして扱います。AWSクラウドにコンジットを設計する際は、例えばAWS IoT Core が入るOT側とクラウド側の取り込みゾーンの間に制限のある通信経路設けることができます。具体的な制限としてAWS IoT Core にMQTT over TLSを使用して通信を暗号化、X.509証明書による相互認証、及びAWS IoTポリシーによるMQTTトピックへのPublish操作の制限などを組み合わせることによってクラウドに適切なコンジットが設計できます。また、インターネット経由のアウトバウンド接続を許容しないシステム要件や、帯域、遅延、可用性などの要件がある場合には、暗号化を利用したAWS Site-to-Site VPN や AWS Direct Connectをコンジットの伝送手段として選択できます。 AWS Network Firewall も複数のネットワークや VPC を横断する集中検査がセキュリティ要件で必要とされた場合にコンジット内に導入できます。 最後にOT とIT／クラウドの接続ではDemilitarized Zone(DMZ)という独立したゾーンを配置することも一般的に行われ、両者を直接接続せずに必要最小限の通信だけをコンジットとして中継するネットワーク領域を立てることができます。AWS では、 AWS IoT Greengrass を実行するエッジゲートウェイをDMZ に配置して、OTとクラウド間の境界ゲートウェイとして構成することができます。 AWS で ISA/IEC 62443 の7つの基礎的要件を充足する 7つの基礎的要件（FR：Foundational Requirement）も、ISA/IEC 62443 に欠かせない概念です。ISA/IEC 62443での7つの基礎的要件は、製造現場のシステムが満たすべき技術的特性をまとめたものです。次の表は、7つの基礎的要件と、それらを支援する代表的なAWS サービスを対応付ける一例です。これらのサービスは ISA/IEC 62443 との適合に必須ではなく、また利用するだけで ISA/IEC 62443への適合が達成されるわけでもありません。システムが該当する要件を満たしているかどうかを判断し、実証する責任は、製造事業者にあります。設計が基礎的要件を満たしているのかは、実際の製造現場システムを確認して評価する必要があります。 FR 要件の概要 FR を支援する代表的なAWSの機能 FR1 – 識別と認証管理 （Identification and Authentication Control） 利用者（人、ソフトウェアプロセス、機器）を正しく識別・認証する。 AWS IAM 、AWS IoT Core（デバイスごとの X.509 証明書）、 AWS Private CA 、 IAM Identity Center。 FR2 – 利用管理（Use Control） 利用者が許可された操作のみを実行するよう強制し、その実行を監視する（最小権限）。 AWS IoT Core の IoT ポリシーと MQTT トピック、IAM ポリシー／SCP、セッション制御、 AWS CloudTrail （監査）。 FR3 – システム整合性（System Integrity） 状態を意図した範囲内に保ち、改ざんや意図しない遷移を防ぐ。 AWS Systems Manager （構成・パッチの完全性）、 Amazon Inspector 、AWS IoT Device Defender、AWS Signer（エッジ／クラウドにデプロイするコードの署名）。 FR4 – データ機密性（Data Confidentiality） 通信中および保存時のデータの秘密性を保護する。 MQTTS（相互 TLS）など通信中の暗号化、 AWS KMS （鍵管理）、Amazon S3 のサーバー側暗号化。プライベート接続が必要な場合はAWS Site-to-Site VPN、または暗号化の構成を追加した AWS Direct Connect。 FR5 – データフロー制限（Restricted Data Flow） ゾーンとコンジットでセグメント化し、不要なトラフィックを防ぐ。 AWS IoT Core の IoT ポリシーと MQTT トピック。プライベート接続や集中検査が必要な場合は、 Amazon VPC 、セキュリティグループ、 AWS PrivateLink 、AWS Network Firewall。 FR6 – イベントへの適時対応（Timely Response to Events） 事象を検知・振り分け・トリアージし、証拠を保全して、対応を推進する（手順化、自動化）。 AWS IoT Device Defender、AWS IoT Core のログ、 Amazon GuardDuty （AWS 環境の脅威検知）、 AWS Security Hub （セキュリティ検出結果の管理）、 Amazon CloudWatch （監査）、保護されたログストレージと組み合わせた AWS CloudTrail（証拠保全）。完全な対応には、引き続き人による手順とオーナーシップが必要。 FR7 – 可用性（Resource Availability） 必須サービスの可用性を維持し、障害後の復旧を可能にする。 障害発生時の復旧に使用：AWS IoT Greengrass のローカル処理とバッファリング、AWS IoT Core や Amazon S3 などのマネージドサービス、必要に応じた接続経路の冗長化。 AWS Backup とAmazon S3 Object Lock は障害発生の回復時間に使用。 AWS における OT 可用性優先の設計 クラウドに接続した製造現場でISA/IEC 62443を実現する際、OTでの可用性優先も抑えておく必要があります。IT と OT は両方ともサイバーセキュリティの優先順位を整理するために、CIA三原則（機密性・完全性・可用性）の考え方を用いますが、それぞれの優先順位は異なります。IT では一般に機密性を最優先するのに対し、OT では可用性を最優先する場合が多く、その理由は制御の停止が、生産、安全、環境に影響を及ぼす可能性があるからです。OT では主に可用性を優先するため、クラウド接続が失われてもプラントは稼働を継続しなければならないという設計が多く見られます。 AWS Well-Architected の「 Modern Industrial Data Technology レンズ 」も、この可用性を重視した考え方に対応しています。「Modern Industrial Data Technology レンズ」のレジリエンスのベストプラクティス項目 MIDAREL02-BP01 では、クラウド接続が失われても重要な生産活動を継続できるよう、ローカル処理、データのバッファリング、自動復旧を求めています。 AWS IoT Greengrass は、この設計の実現に役立つサービスの一つであり、クラウドとの接続が失われた場合も、エッジでローカル処理を継続できます。データをローカルにバッファリングし、接続回復後に対応する AWSサービスへ転送するには、AWS IoT Greengrass の Stream Manager コンポーネントを使用し、ストレージ容量、保持期間、転送先などを要件に応じて構成します。 ISA/IEC 62443 と AWS における責任のマッピング 最後にISA/IEC 62443 における重要な概念はロールに基づく責任分担です。本規格シリーズでは、責任分担は役割により振り分けられ、各役割の責任と担当範囲はゾーンと違い固定的に定められています。ISA/IEC 62443 では、製造現場のセキュリティを扱う際の 4 つの役割として、資産保有者（Asset Owner）、構築サービスプロバイダー（Integration Service Provider）、保全サービスプロバイダー（Maintenance Service Provider）、製品サプライヤー（Product Supplier）を定めています。資産保有者はシステムを所有・運用し、主要な責任を担います。構築サービスプロバイダーはソリューションを設計・構築し、保全サービスプロバイダーは導入後の保守を担い、製品サプライヤーは機器や製品を提供します。これらの役割は製造現場の長期的サイバーセキュリティ維持全体に関わり、資産保有者が要件とリスクを評価し、構築サービスプロバイダーが実装し、保全サービスプロバイダーが運用・保守するという役割を果たします。 一方でISA/IEC 62443 の各役割と、AWS とお客様の間の AWS 責任共有モデル は、異なる責任分担を表しているため、1 対 1 で対応付けることはできません。AWS責任共有モデルは、セキュリティに関する責任を AWS とお客様の二者つの領域に分担するモデルです。AWSの責任領域は、AWS サービスを稼働させるインフラストラクチャを含む「クラウドのセキュリティ（security of the cloud）」に責任を負います。お客様の領域ではAWS上で使用するAWSサービスの選択と設定に加え、データ、アプリケーション、ID、アクセス権限などを管理する責任を負います。このように、ISA/IEC 62443の責任分担とAWS 責任共有モデルは異なるため、製造現場がAWSを利用する際にはどの領域が責任担当になるのは明確ではありません。この責任分担の明確化に役立つのが、先ほど紹介したAWS Well-Architected の「Modern Industrial Data Technology レンズ」です。このレンズでは、AWS 責任共有モデルを前提に、クラウド、IT、OT の各ステークホルダーの責務を分け、ワークロードに合わせた責任分担を定義することを推奨しています。このレンズを活用することで、AWS 責任共有モデルを土台としながら製造現場に応じてクラウド、IT、OT に関わる各責任者の担当範囲を具体的に定義することができ、責任分担を明確化することができます。 まとめ 本記事では、ISA/IEC 62443 の主要な概念を用いて、OT とクラウドを接続する際に保護すべき対象と必要となるセキュリティ対策を整理しました。そのうちクラウドに接続された領域における技術的対策と実装はAWSのサービスにより実現することができます。AWSサービスは、ゾーンとコンジットの設計に加え、7つの基礎的要件（FR1〜FR7）に関連するクラウド側の技術的対策や、可用性を重視した現場とクラウドの接続設計を支援します。ISA/IEC 62443 に基づいてAWS サービスを適切に活用することで、OTセキュリティ上のリスクを低減しながらクラウドを導入し、製造現場のデジタル変革を進めることができます。実際の検討を始める際は、まず対象システムの範囲、資産、データフローを可視化し、リスク評価に基づいてゾーン、コンジット、セキュリティ要件、および関係者間の責任分担を定義することをお勧めします。そのうえで、要件に適した AWS サービスと構成を選択し、設計した対策が期待どおりに機能することを検証すれば、OTセキュリティ上のリスクを管理しながら、製造現場におけるクラウド活用を進めることができます。 執筆者について 瀧澤ロナン / Ronan Takizawa 2026 年 4 月入社のソリューションアーキテクト ISA/IEC 62443 の全資格（Fundamentals, Risk Assessment, Design, Maintenance, Expert）を保有 お客様のOT セキュリティとクラウド活用の支援を目指している

はじめに こんにちは。medibaでコーポレートIT等を担当しているnagiです。 現代のコーポレートITにおいて、多くの組織や担当者が直面している課題のひとつが「オンプレミスActive Directory（以下、オンプレAD）無くせない問題」ではないでしょうか。 近年、多くの企業がクラウドをベースとしたIT環境へ移行して久しいと感じますが、その中でも例外的に、いにしえのオンプレADのドメインコントローラー（DC）だけが移行できない……。そんな課題を持っている方も多いかと思います。 オンプレADは古くから企業のID管理基盤として根付いており、積み重ねられた歴史があります。しかしその