2026 年 8 月 21 日、 AWS Glue 6.0 の一般提供について発表しました。これにより、価格が以前の AWS Glue バージョンよりも 30% 低くなり、 Apache Iceberg v3 の機能が完全にサポートされるようになりました。AWS Glue 6.0 は、完全に近代化されたランタイム、Apache Spark 4.1、Python 3.12、および Scala 2.13 に基づいて構築されており、より高速なパフォーマンスを実現しています。 このリリースにより、AWS Glue は、完全にサーバーレスのマネージド型の Spark サービスで最も完全な Iceberg v3 実装を実現するとともに、ETL オーサリングを簡素化し、 PySpark のパフォーマンスを向上させ、1桁ミリ秒のレイテンシーでリアルタイムストリーミングを可能にする新機能も提供します。 AWS Glue 6.0 の新機能は何ですか AWS Glue 6.0 は、Iceberg 1.11.0 をベースに構築された完全なApache Iceberg v3仕様を提供します。主な特長は、シュレッダ処理をサポートする VARIANT データ型です。これにより、半構造化データ用の従来の文字列データ型の列と比較して、クエリの読み取りパフォーマンスが向上します。 VARIANT  のシュレッディングを使用すると、スキーマをフラット化しないで JSON、ログ、イベントデータを保存してクエリできます。これにより、スキーマが変更されたときに重複するデータコピーやカスタム解析コード、パイプラインが破損することがなくなります。この機能により、チームが半構造化データの大規模処理の方法が変わります。 Iceberg v3 のその他の機能には以下が含まれます。 幾何学と地理データタイプ : GIS分析、ロケーションインテリジェンス、および地理空間データパイプラインのネイティブ空間処理をマネージド Spark で直接有効にします。 ナノ秒精度のタイムスタンプ : 標準ミリ秒を超える精度を必要とする IoT センサーデータ、科学計算、および高頻度の金融ワークロードをサポートします。 未知の型処理 : パイプラインに障害が発生することなく、予期しないスキーマや、進化するスキーマを含むデータを処理できるため、上流のスキーマ変更に対する回復力が高まります。 AWS Glue 6.0 には、最新のランタイムエンジンである Spark 4.1 の最も重要なアップグレードも含まれています。 Spark 宣言型パイプライン : Spark 宣言型パイプラインでは、ETLオーサリングへのシンプルなアプローチが導入されています。データエンジニアは変換を宣言してデータをどのように表示するかを指定し、エンジンは実行順序と最適化を自動的に決定します。これにより、パイプライン開発の複雑さが軽減され、手動によるオーケストレーションのオーバーヘッドがなくなります。 アローネイティブ Python UDF と UDTF : AWS Glue 6.0 では、Python ユーザー定義関数 (UDF) とユーザー定義テーブル関数 (UDTF) の Arrow ネイティブ実行が導入されました。これにより、Python と JVM 間のシリアル化のオーバーヘッドがなくなり、複雑な変換での PySpark のパフォーマンスが向上します。 リアルタイムストリーミングモード : AWS Glue 6.0 では、ステートレスストリーミングのユースケース向けに、1桁ミリ秒のレイテンシーを実現するリアルタイムストリーミングモードが導入されています。Glue に最適化された実行機能を備えた Spark 4.1 のリアルタイムモードに基づいて構築されたこの機能は、リアルタイムのイベント処理、低遅延のデータ変換パイプライン、および時間に敏感なデータルーティングをサポートします。 AWS Glue 6.0 の開始方法 AWS Glue 6.0 を使用するのに、API を変更する必要はありません。 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS Glue Studio 、 Amazon SageMaker Unified Studio 、および優先する IDE から create-job または update-job API で既存の --glue-version パラメーターを使って、新しいバージョンを選択することができます。 AWS Glue 6.0 ジョブを AWS Glue Studio コンソール で開始するには、[AWS Glueジョブ] を開き、 ジョブ詳細 タブで、バージョン Glue 6.0 – Spark 4.1、Scala 2、Python 3 をサポート を選択します。AWS Glue 6.0で新しい AWS Glue ジョブを作成することで、改善によるメリットを受けること、および既存の AWS Glue ジョブを移行することもできます。 AWS Glue 6.0 を AWS Glue Studio ノートブックで使用したり、Jupyter Notebook を介してインタラクティブセッションを開始したりするには、 %glue_version マジックで 6.0 を設定してください。 また、AWS Glue Studio の Spark アップグレードエージェント を使用して既存のジョブを Glue 6.0 にアップグレードしたり、既存の Glue ジョブの自動アップグレード機能を使用して自動的に Glue 6.0 にアップグレードしたりすることもできます。 詳細については、AWS ドキュメントの 「AWS Glue 6.0 バージョンの詳細」 および 「AWS Glue for Spark ジョブの AWS Glue バージョン 6.0 への移行」 を参照してください。 今すぐご利用いただけます AWS Glue 6.0 は現在、AWS Glue が運用されているすべての AWS リージョンで一般的に利用可能です。リージョンごとの提供状況や今後のロードマップについては、 リージョン別の AWS 提供機能 にアクセスしてください。API を呼び出したり、ドキュメントを検索したり、リージョンごとの提供状況を確認したり、この新機能に関するトラブルシューティングを確認したりする場合は、お好みの AI ツールで AWS MCP Server と プラグイン を使用してみてください。 クローラー (データの検出) と抽出、変換、ロード (ETL) ジョブ (データの処理と読み込み) には、時間単位の料金を秒単位で請求します。AWS Glue データカタログの場合は、メタデータの保存とアクセスにシンプルな月額料金を支払う必要があります。最初の 100 万個のオブジェクトは無料で、最初の 100 万個のアクセスは無料です。詳細については、 AWS Glue 料金表ページ をご覧ください。 AWS Glue Studio コンソール でお試しいただいた後、 AWS re:Post for AWS Glue または通常の AWS サポート窓口までフィードバックをお寄せください。 – Channy 原文は こちら です。

2026年6月25日〜26日、幕張メッセで開催された AWS Summit Japan 2026 にて、AWSの鉄道ブースで業界向けに2つの展示を行いました。本ブログではその展示内容をご紹介します。 会場の「AWS for Railway/Logistics」展示エリアで、多くの来場者をお迎えしました。 今回は以下の2つの展示を行いました。 展示①：鉄道設備保全プラットフォーム — AIエージェントと地理情報システム（GIS）を統合した保全の仕組み 展示②：「クローズド」をクラウドで読み解く — 国土交通省ガイドライン第6版から考えるOT/IT設計アプローチ 展示① 鉄道設備保全プラットフォーム 本展示は、2025年11月の鉄道技術展2025（ ブログ ）で展示した鉄道保全ソリューションを、いただいたフィードバックを踏まえさらに発展させたものです。 鉄道保全の現場が直面する課題 鉄道設備の保全現場では、構造的な課題が深刻化しています。 保全の担い手の減少 — 生産年齢人口の減少に伴い、鉄道設備のメンテナンスに従事する技能労働者が減少しています。ベテランが退職していく中で、その現場ノウハウをどう残し、どう伝えるかが喫緊の課題です。 保全対象機器の増加 — 従来の鉄道機械に加え、ホームドアなどの旅客サービス向上のための新機器が増加しています。「省力化」のために導入した機械が、逆にメンテナンス対象を増やしていくというジレンマが生じています。 情報資産の複雑化 — 作業記録、設備マニュアル、保守履歴といった非構造化データが各所に散在し、個別最適を繰り返した結果、業務システムがサイロ化しています。 人が減り、保全対象は増え、情報は散らばる。この三重の課題に対し、AWSが提案するのは 「聞けば、必要な情報が集まり、やるべきことが分かる」 保全の仕組みです。 ソリューションの全体構成 以下が本ソリューションの全体像です。 駅設備群や変電所からセンサーデータを収集し、異常を検知すると通知を配信します。同時に保全AIエージェントが起動し、チャットを通じて原因調査から作業指示書の生成までを支援します。また、時系列基盤モデル Chronos-2 を応用した予兆検知を日次で実行し、故障の予兆を地図上に可視化します。保全担当者はこれらすべての情報に、地図・ダッシュボード・AIチャットのいずれからでもアクセスできます。 以降、この構成の中核となる2つの柱について詳しくご紹介します。 コンセプト：誰もが使える、鉄道設備保全プラットフォーム 今回の展示では、特定の担当者向けではなく、立場の異なる誰もが直感的に使えることを目指したデモソリューションをご紹介しました。2つの柱で構成されています。 各柱はブースで実際に手を動かして体験でき、来場者が自分の業務に置き換えてイメージできる構成にしました。 柱1：AIエージェントによる異常対応フロー 異常の発生から対応完了まで、AIエージェントが自律的に伴走します。入口は AIチャットひとつ です。やりたいことに応じて、地図UI・ダッシュボード・AIエージェントへ自然につながります。 以下が実際のデモ画面です。左側に地図UIと3Dビューア、右側にAIチャットとダッシュボードが統合されています。 柱1のデモ画面。異常を起点にAIエージェントが横断調査し、対応を提案します（表示内容はすべて架空のデータです） 保全AIエージェントは、問い合わせ内容に応じて最適な画面・機能へ自動的につなぎます。 異常対応の4ステップ ① 異常を検知 — 設備のセンサー値から異常をリアルタイムに検知します。 AWS IoT Core でデータを受信し、 AWS IoT SiteWise で328アセット・13モデルとして構造化された設備情報から異常を判定します。 ② AI調査を自動起動 — 異常検知と同時に地図画面が該当設備に自動フォーカスし、AIエージェントへの問い合わせが自動で開始します。担当者へのメール通知も並行して行われ、検知から調査開始までのタイムラグを最小化します。 ③ 原因と対応計画を提示 — AIエージェントが保守履歴・設備マニュアル・センサーの数値データを横断的に調査し、原因の手がかりと対応計画を生成します。ベテランが経験に基づいて「あのとき似たことがあった」と思い出すプロセスを、AIが瞬時に再現します。 ④ 作業指示書を出力 — 対話の内容を基に、作業指示書をExcel帳票として出力します。チャットで深掘りし、情報が揃った段階で「指示書にまとめて」と言えば完成します。 技術的構成 Amazon Bedrock AgentCore + Strands Agents — AIエージェントの実行基盤と、Amazonが開発したオープンソースのAIエージェントフレームワーク。エージェントが実行する個別機能を「Agent Skill」として実装 Amazon Bedrock Knowledge Bases — 設備マニュアル・保守履歴に対するRAG（検索拡張生成） Amazon Bedrock AgentCore Memory — 会話・作業履歴を保持し、文脈を踏まえた継続的な対話を実現 Amazon Location Service — 鉄道設備の位置と状態を地図上にリアルタイム表示 Grafana（ Amazon Elastic Container Service 上） — センサー値の時系列可視化。チャットからダッシュボードを呼び出す仕組みも実装 柱2：学習不要の予知保全 — Chronos-2の応用 従来の予知保全が抱えていた課題 予知保全は鉄道保全の効率化に大きな可能性を持ちますが、従来のアプローチには大きなハードルがありました。設備ごとにモデルを構築し、定期的に再学習する運用が必要で、新設備が増えるたびに追加のモデル開発コストが発生します。 保全の担い手が減っている中で、モデルの運用まで手が回らない。結果として、予知保全は「やりたいけど始められない」ものになりがちでした。 Chronos-2 が変えること 今回の展示では、 Amazon Scienceが開発したオープンソースの時系列基盤モデル Chronos-2 を活用した、学習不要（ゼロショット）の予知保全をご紹介しました。 鉄道保全での活用 国内鉄道事業者様にご提供いただいた変電所のセンサーデータを元に生成したデータを使用し、日次で自動予測を実行するデモを構築しました。 本デモでの予兆検出の仕組みは以下の通りです。毎日の始まりに、Chronos-2が最新のセンサーデータを基に将来の値を予測し、信頼区間とともに算出します。その後、実際のセンサーデータが取得されるたびに予測の信頼区間と比較し、実測値が信頼区間から逸脱した場合に予兆として警告を発出します。 毎日、最新データから翌日以降の値と信頼区間を予測 実測値が信頼区間から逸脱した場合に予兆として警告 予兆が検出された設備は地図上でステータスが変化し、予測グラフを重畳表示 柱2のデモ画面。Chronos-2を応用した予測を地図とグラフで可視化します（実データを元に生成した合成データを使用。表示内容は架空です） 設備ごとのモデル構築が不要なことで、予知保全を始めるハードルを大きく下げられる可能性があります。鉄道保全における時系列基盤モデルの活用は新しいアプローチであり、本展示ではその可能性を具体的なデモとしてお見せしました。 活用AWSサービス Amazon SageMaker AI — Chronos-2モデルの推論エンドポイント Amazon EventBridge + AWS Step Functions — 日次バッチでの予測実行オーケストレーション Amazon Simple Storage Service （Amazon S3） — 時系列データ・予測結果の格納 AWSの詳細構成図 最後に、ここまで紹介した仕組みを支えるAWSの詳細構成を示します。設備エミュレーターからのデータ取り込み、異常検知、目的別の通知パイプライン、保全AIエージェント、Chronos-2を応用した予兆検出までを1枚に集約したものです。通知パイプラインは目的別に複数存在し、それぞれ独立して動作します。 展示② 「クローズド」をクラウドで読み解く — 国土交通省ガイドライン第6版から考えるOT/IT設計アプローチ 鉄道の制御系システム（信号・CTC・ATS・連動装置など）は、重要インフラとして高い安全性が求められます。国土交通省「 鉄道分野における情報セキュリティ確保に係る安全ガイドライン 」第6版はその設計指針を示す重要な規範です。 本展示では、このガイドラインの要件をクラウド上で実現するための設計アプローチをパネルで紹介しました。 「クローズド ≠ 安全」という認識転換 物理的に隔離された環境であっても、USBメモリ等を介した侵入は起こり得ます（ 参考：IPA 制御システムのセキュリティリスク分析ガイド ）。重要なのは「切り離す」ことではなく、システム全体のリスクを継続的に管理することです。 また、「クラウド」＝「インターネット」ではありません。 AWS Direct Connect を使うことで、インターネットを経由せずに閉域網を介してクラウドサービスを利用できます。 ガイドラインが求めるセキュリティを、自前で維持し続ける難しさ ガイドライン第6版では、脅威環境の変化に追従する「継続的なリスク対処」が求められています。具体的には、脅威の検知、監査証跡の管理、脆弱性への対応を組織として継続的に運用する必要があります。 しかし、これらを自前のオンプレミス環境で維持し続けることは、鉄道事業者にとって大きな負荷となり得ます。セキュリティ人材の確保、監視基盤の構築・更新、脅威インテリジェンスの追従 — いずれも専門性が高く、継続的な投資を要する領域です。 AWSのセキュリティリソースを活用する意義 ここで有用だと考えているのが、 責任共有モデルに基づき責任範囲を明確にした上で、AWSが担う領域のセキュリティ運用をマネージドサービスに任せる というアプローチです。 Amazon GuardDuty — 脅威検知をマネージドで提供。自前で監視基盤を構築・運用する負荷を軽減 AWS CloudTrail — 監査証跡を自動で記録・保存。ガイドラインで求められる操作ログの管理を支援 AWS Security Hub — セキュリティ状況を一元的に可視化。継続的な改善サイクルの基盤に クローズドな閉域網接続（AWS Direct Connect）を前提とすることで、インターネットを介さずにこれらのセキュリティリソースを活用できます。もちろん、 Amazon Bedrock 等のAIリソースもクローズドな状態で利用可能ですが、ガイドライン準拠という観点で最も直接的なメリットは、 責任共有モデルのもと、AWSのマネージドサービスでセキュリティ運用の負荷を軽減できること にあると考えています。 設計の3原則 原則1：論理的境界も有効 ガイドラインは「クローズド環境構築」を求めますが、その手段を物理に限定していません。IEC 62443やNIST CSF 2.0の考え方に基づき、 Amazon Virtual Private Cloud （Amazon VPC）による論理的な境界の分離も有効な手段です。 原則2：境界の明確化と片方向通信 例えば、制御系（OT）と業務系（IT）を別のVPCに分離し、中継ストレージ（Amazon S3）で片方向通信を強制するといったパターンが考えられます。制御系VPCはクラウド内のインターネットからも隔離されたネットワーク上に構築し、データの逆流が起きない設計とします。 原則3：継続的なリスク対処をAWSでオフロード NIST CSF 2.0の「統治」機能を踏まえ、組織レベルで継続的な改善サイクルを構築します。前述のAWSセキュリティサービスを活用することで、脅威環境の変化への追従を自前で抱え込まずに実現できます。 鉄道ユースケースへの展開 このアーキテクチャパターンにより、セキュリティを確保しながら制御系データの利活用が可能になります。 データを活用した業務変革はIT領域に閉じるものではありません。制御系のセキュリティドメイン内にAI推論リソースを配置することで、制御系データをIT側に出すことなくOT領域内でAI活用を行うことも可能です。また、OTからITへの片方向データ連携により、運行ダッシュボードを構築できます。IT系では需要予測や遅延予測など、ドメインの境界を明確にした上でデータの価値を引き出す設計も可能です。 来場者の反応 展示ブースには2日間を通じて多くの方にお越しいただきました。 保全プラットフォームのデモでは、地図とAIチャットが連動して動く様子に多くの方が足を止めてくださいました。デモが具体的でイメージを持ちやすいとの反応をいただく一方で、「この仕組みを活かすためには、設備データをどう取得するかという長期的な戦略が前提になる」という本質的な指摘もありました。私たちにとっても、ソリューション単体ではなくデータ戦略とセットで提案していく必要性を再認識する機会となりました。 Chronos-2を応用した予知保全については、「学習不要」というコンセプトへの関心が想定以上に高く、鉄道に限らず幅広い業界の方から質問をいただきました。既に類似の取り組みを進めている方からも前向きな反応があり、実用化への期待の高さを感じています。 セキュリティ設計のパネル展示も、保全デモとは異なる層の来場者に関心を持っていただきました。AI関連の展示が多い中で、制御系ネットワークの設計という具体的なテーマが来場者の課題に合致したようです。 まとめ 鉄道は社会インフラの根幹を支える産業です。しかしその保全現場は、人手不足・設備増加・情報の散在という構造的課題に直面しています。 今回の展示を通じてお伝えしたかったのは、テクノロジーは人を置き換えるためではなく、人がやるべきことに集中できるようにするために使うものだということです。 ベテランの知見はAIが引き出す。人は判断と意思決定に集中する モデルの構築・運用に追われない。時系列基盤モデルにより予知保全を始める選択肢が広がる クローズド前提のシステムであっても、クラウドをセキュリティ運用・データ活用・AI活用に取り入れることで、人が本来注力すべき判断や改善に集中できると考えている AWSは、鉄道業界のデジタルトランスフォーメーションを支援し、安全で持続可能な鉄道サービスの実現に貢献してまいります。 展示内容にご興味をお持ちの方は、ぜひお気軽にお問い合わせください。 著者 堀 竜慈 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト 西部 信博 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアカスタマーソリューションマネージャー 稲田 崇志 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 矢形 拓也 アマゾンウェブサービスジャパン合同会社 技術統括本部　シニアソリューションアーキテクト 鈴木 真史 アマゾンウェブサービスジャパン合同会社 技術統括本部　シニアソリューションアーキテクト 宮﨑 知洋 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト  

社会インフラ業務で需要が増加しているGIS（地理情報システム）について解説します。代表的なツール（ArcGIS、QGISなど）の種類やトレンド、都市計画などの用途、活用に必要なプログラミング言語などの基礎知識をご紹介します。