1. はじめに 生成AIやAIエージェントの活用が広がる中で、ソフトウェア開発の現場でもAI活用が進んでいます。 これまでは、コーディング支援、テストコード生成、ドキュメント作成、コードレビュー補助など、開発工程の一部にAIを使うケースが多かったと思います。 一方で、AWS Summit Japan 2026の各セッションを見ても、最近は「AIでコードを書く」だけでなく、要件定義、設計、実装、テスト、デプロイ、運用まで含めて、開発ライフサイクル全体をAI前提で見直す流れとなっています。 その文脈で重要になるのが、AI-DLC（AI-Driven Development Lifecyc

こんにちは、ソリューションアーキテクトの宇佐美です。 2026年7月15日(水) に開催された「Neuron Community – 2026 Vol.1」の様子をレポートします。このイベントは、2025年3月に立ち上げられた「Neuron Community」の協力のもと開催しました。 今回は、 AWS Summit Japan 2026 開催後ということもあり、AWS Summit Japan の振り返りや、AWS Neuron のアップデート情報が多めの内容となっています。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニング：Neuron Community の成り立ちとカラクリ社での Trainium 取り組み紹介 中山 智文 氏（カラクリ株式会社 取締役 CPO) 資料：後日公開 オープニングセッションでは、カラクリ株式会社の中山氏より発表していただきました。カラクリ株式会社は、2023年より一貫して AWS Trainium を利用し続けており、Neuron Community の立ち上げにも大きな貢献をしていただいています。この発表では、Neuron Community の始まりについて紹介していただきました。また、カラクリ株式会社の AWS Trainium に関する2つの取り組みについても紹介していただきました。1つ目の取り組みは、Amazon EKS 上に構築された 「Neuron 分散学習プラットフォーム」 です。このプラットフォームを構築することで、インフラ関連の知識が十分ではないメンバーでも分散学習を実行できる環境の整備を進めているそうです。2つ目の取り組みは、AWS Trainium の NKI カーネル開発を促進するための 「カーネル開発エージェント」 です。この AI エージェントにより、NKI カーネル開発をエージェントが自律的に進められるようになるということです。最後に、今後の Neuron Community の活動について、よりオープンな場にしていきたいという発信をしていただきました。 AWS Summit Japan 振り返り① セッションダイジェスト「⼤規模学習から AI エージェントの推論まで ~ コスト効率と性能が両⽴する AWS Trainium の全貌 ~」 澤 亮太 (Amazon Web Services Japan G.K.) 資料： “AI エージェントの推論から⼤規模学習まで” コスト効率と性能が両⽴する AI インフラ ̶ AWS Trainium の全貌 Amazon Web Services Japan G.K. の澤からは、 AWS Summit Japan 2026 の振り返りとして、「”AI エージェントの推論から大規模学習まで” コスト効率と性能が両立する AI インフラ ー AWS Trainium の全貌」のセッションを、15 分のダイジェスト版で紹介しました。このダイジェストでは、AWS Trainium の典型的な使い方として、 “A. コードはそのままで学習コストを下げたい” 、 “B. 性能を最適化したい” 、 “C. 推論コストを固定化したい” の3点に注目して説明しました。 A. では、 Native PyTorch support（ベータ版） を使い、GPU向けPyTorchコードのデバイス指定を cuda から neuron に変更して、AWS Trainium 上で学習を実行する方法を紹介しました。デモでは、GPT-2 の学習スクリプトを実行しました。B. では、 NKI (Neuron Kernel Interface) により AWS Trainium のハードウェア命令セットに直接アクセスして AI カーネルの最適化が可能であることを紹介しました。また、性能最適化とデバッグのワークフローを支援する Neuron Explorer、NKI の開発を AI エージェントで加速するためのオープンソースツールキットの “Neuron Agentic Development” についても紹介し、Neuron Agentic Development のデモを見ていただきました。C. では vLLM on Trainium を使うことで、オープンウェイトモデルをAWS Trainium 上でサービングできます。ここでは、openai/gpt-oss-20b モデルを AWS Trainium 上でサービングするデモを見ていただきました。 AWS Summit Japan 振り返り② ブース展示紹介「⽣成 AI を⽀えるインフラ技術」 赤澤 Toshinobu (Amazon Web Services Japan G.K.) Amazon Web Services Japan G.K. の赤澤からは、 AWS Summit Japan 2026 の振り返りとして、ブース展示「生成AIを支えるインフラ技術」について紹介しました。この展示は、複数のマルチモーダルモデルを Amazon EC2 trn2.48xlarge でサービングする様子を見ていただくもので、マルチモーダルモデルで画像の編集を行います。音声で画像編集の指示をすると Whisper Large v3 で音声認識を行い、Qwen3-VL-8B-Instruct で元になる画像を編集するための指示を生成します。指示は Qwen-Image-Edit-2511 に渡され、画像が編集されます。編集された画像は、Qwen3-VL-8B-Instruct を使って指示通りに編集できているかを講評し、XTTSv2 で音声出力します。この発表では、３匹の子猫のイラストを、4匹に増やすという画像編集の様子を見ていただきました。 また、このデモを実現しているアーキテクチャについての説明も行いました。4つのモデルのtrn2.48xlarge の 64 論理コアへのアロケーションや、モデルのデプロイフローなども説明しています。 AWS Trainium / Inferentia / Neuron SDK 最新アップデート 常世 大史 (Amazon Web Services Japan G.K.) 資料： Neuron Communit 2026 Vol.1 AWS Trainium / Neuron 最新アップデート Amazon Web Services Japan G.K. の常世からは、ちょうどイベント前日にテレビ東京の WBS（ワールドビジネスサテライト）で AI 向けアマゾン独自の半導体開発が特集 されたことに触れ、自身が所属するアマゾン内のチップ開発部隊「アンナプルナラボ」について紹介しました。Anthropic との共同プロジェクト Project Rainier では、これまでに 140 万個超の Trainium 2 および Trainium 3 チップが稼働中であること（WBS 内の特集にて紹介）、 OpenAI が 2GW 規模での Trainium 採用を発表 したこと、また従来のチャットボット型 AI からエージェント型 AI へとシフトする中で、AI チップに加え AWS Graviton プロセッサの重要性が増している点を紹介しました。 Meta が数千万の Graviton コアで Agentic AI をスケールしている事例 にも触れました。 次に、澤のセッションでも紹介された AWS Trainium 向けの SDK「AWS Neuron」のアップデートとして、ライブラリのネイティブ化（Native PyTorch、Native vLLM）の最新状況を紹介しました。 また、7 月 7 日にリリースされた最新の Neuron 2.31 では、性能最適化の要である NKI（Neuron Kernel Interface）と NKI Library に大きなアップデートがあった点、さらに NKI カーネル開発用のエージェントコーディング機能 Neuron Agentic Development によるカーネル自動最適化ループへの注力を紹介し、セッションを締めくくりました。 ※ イベント開催後の 2026年7月20日(月) に vLLM Neuron Beta がパブリックリリースしました！ さいごに 通算3回目の Neuron Community は、カラクリ株式会社での AWS Trainium への取り組みの発表や、AWS Summit Japan 2026 の振り返り、AWS Neuron 関連の最新アップデート情報の紹介と、充実した内容となりました。AWS Summit Japan 2026 のセッション動画は、 AWS Summit Japan の Web ページ に登録いただくことでオンデマンド視聴が可能です。ご興味のある方は、ぜひ登録してみてください。 発表後には今後の Neuron Community についてのディスカッションも行われ、約 1 年ぶりの開催となったことを踏まえ、より高い頻度で開催していこうという声が挙がりました。AWS としても積極的に支援していきます。 今後の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。  

みなさん、こんにちは。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 セキュリティとクラウド活用の支援を目指している