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など）の種類やトレンド、都市計画などの用途、活用に必要なプログラミング言語などの基礎知識をご紹介します。

本ブログは、KDDI株式会社 高山 伸也 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 位置情報データを活用した商圏分析は、小売・飲食・観光業界において出店計画や集客戦略の意思決定に広く活用されています。今回は、 KDDI株式会社 （以下、KDDI）が提供する位置情報ビッグデータ分析サービス「KDDI Location Analyzer（以下、KLA）」の新機能開発事例をご紹介します。特に Amazon Redshift Data Sharing 機能を活用することで、既存機能への影響を抑えながら新機能を追加するアーキテクチャを実現しています。 導入背景 KDDI Location Analyzer とは KDDI は au の携帯電話ネットワークから取得した GPS 位置情報データを活用した商圏分析サービス「 KDDI Location Analyzer 」を 2019 年 6 月にサービス開始しました。位置情報統計データ・GIS データを統合し、125m メッシュ単位・町丁目単位での高精度な商圏分析を実現しています。サービス開始から約7年間でのべ 1,000 以上の民間企業・自治体に利用されており、小売・飲食業界の店舗出店戦略から観光業界・地方公共団体まで幅広い分野で活用されています。インフラには、位置情報というセンシティブなデータを扱う上で KDDI 社内で利用が認定されたクラウド環境として AWS を採用しています。 新機能開発の背景 観光需要の回復と新たなニーズ 観光需要の回復を背景に、地域の魅力創出や商圏の最適化に向けたデータ活用の重要性が高まっています。行政や企業においては、定量的な人流データに基づく政策・戦略立案がこれまで以上に求められるようになりました。 特に、観光地や商業エリアでは、単なる来訪者数の把握にとどまらず、以下のようなニーズが顕在化していました。 来訪前後の行動パターンの把握・分析 宿泊エリアの分析 店舗間の回遊構造の可視化 携帯電話の GPS 位置情報は時系列でトレースできることが最大のメリットです。既存ユーザーからも「この強みをもっと活用した機能が欲しい」という要望が寄せられており、それが今回の新機能開発の直接的なきっかけとなりました。 新機能「観光動態・店舗間回遊の可視化機能」 これらのニーズに応えるため、KDDI は KLA の国内居住者版に以下の3つの新機能を追加しました。 （1）前後立ち寄り分析 都道府県・市区町村、またはジオフェンスで指定した施設に対し、「どこから来訪し、次にどこへ向かったのか」を可視化します。前後時間帯指定スライダー（最大前後 180 分）を動かすことで時系列の変遷を確認でき、スライダーの操作に応じてヒートマップや滞在者数グラフが即座に更新されます。 来訪者区分：全体 or 都道府県外 or 市区町村外（施設選択時） 集計期間： 1 日〜1 カ月、時間帯： 5 時〜29 時（30 分単位） 属性：性年代・居住者・勤務者・来街者 集計結果：周辺滞在者数グラフ（最大前後 180 分）、立ち寄り地滞在者数リスト（町丁目・市区町村・都道府県） 活用シーン：域内の観光ルート立案、店舗販促・品揃えやメニュー開発 「前後立ち寄り分析」操作画面 （2）宿泊地分析 指定した市区町村に来訪した旅行者の宿泊エリアを可視化します。 来訪者区分：旅行者 集計期間： 1 日〜 1 カ月、日にち区分：期間全体・日〜木・金・土・祝休前日 属性：性年代 集計結果：旅行者数グラフ（性年代×日にち区分、宿泊・日帰り）、宿泊施設タイプ別施設数・部屋数（市区町村別）、宿泊地ランキングリスト（市区町村×日にち区分） 活用シーン：地域の宿泊供給と旅行者ニーズを総合的に分析 「宿泊地分析」操作画面 （3）発地分析 特定期間に指定した目的地（都道府県・市区町村）へ来訪した人の出発地*を可視化します。 *：来訪前日の宿泊地または居住地（深夜滞在地） 来訪者区分：全体 or 旅行者 集計期間： 1 日〜 1 カ月、時間帯： 5 時〜 29 時（30 分単位）、日にち区分：期間全体・平日・祝休日 属性：性年代・居住者・勤務者・来街者 集計結果：発地別来訪者数グラフ（性年代・居住地別）、日にち区分別来訪者数グラフ（市区町村別）、発地別来訪者数リスト（都道府県・市区町村×日にち区分） 活用シーン：観光プロモーション施策の検討、経済圏としての強み弱みの把握とサービス改善 「発地分析」操作画面 システムアーキテクチャ 全体構成 KLA のインフラは AWS 上に構築されており、以下のような構成となっています。 KLAのアーキテクチャ ワークロードは既存機能と新機能で処理フローが異なります。 既存機能では、ユーザーのリクエストを Amazon ECS Fargate 上の Web サーバが受け取り、Amazon Redshift Serverless（既存機能の集計基盤）に直接クエリを発行して結果を返却するシンプルな同期処理です。 新機能の回遊分析は、複数地点間の時系列データを処理するため、クエリ1件あたりの実行時間が集計対象地域や集計条件によって数分程度に及ぶ重い処理です。RPU を上げることでクエリ実行時間を短縮できる可能性はありますが、KLA ではコストと UX のバランスを取った設定のもと、同期処理ではユーザーを長時間待たせてしまうため非同期処理を採用しています。Web サーバがリクエストを受け取ると Amazon SQS にメッセージを送信し、AWS Lambda がそれを受けて複数の AWS Fargate タスクを並列起動します。各タスクが Redshift にクエリを発行し、処理結果を Amazon Aurora に格納します。アプリケーションが定期的に Aurora を参照して結果をユーザーに返す非同期構成です。SQS でキューイングすることで、Fargate タスクの起動から結果の Aurora への格納までの一連の集計処理を統一的に管理しています。ユーザーには「集計中」ダイアログを表示することで処理中のタイムラグを意識させない UX を実現しています。 Amazon Redshift Data Sharing の活用 新機能の開発にあたり、2 つの課題がありました。 1 つ目はワークロード分離です。既存機能は同期処理で応答を返せるクエリである一方、新機能の回遊分析は前述の通り数分程度かかる重いクエリです。同一ワークグループで動かすと互いの処理が干渉するリスクがあるため、ワークグループを分離する必要がありました。なお、Amazon Redshift Serverless には AI 主導のスケーリングと最適化機能 があり、ワークロードパターンを機械学習で予測してクエリ実行前にコンピュートリソースを自動最適化することで、バースト的な高負荷クエリが他のクエリに影響を与えないよう対応できます。一方、ベースとなる RPU やサービス要件、クエリ特性、実行周期などが定常的に大きく異なるワークロードを扱う場合には、ワークグループを分離する構成も有効な選択肢となります。 2 つ目はテーブル設計です。新機能の回遊分析では、複数地点間の時系列データを効率的に処理するため、既存テーブルとは異なるソートキーを持つマートテーブルを新たに作成する必要がありました。まずマテリアライズドビュー（MV）の活用を検討しましたが、KLA が扱う位置情報データは約7年4か月分・数十 TB 規模で今後も増加し続けるため、初回作成に 1 日以上かかるという課題がありました。また、日次データ連携でデータが追加されるたびにリフレッシュが必要となる負荷に加え、ユーザーがエリア・期間・属性を自由に組み合わせて指定するサービス特性上、クエリパターンごとに MV を作り分けると管理が煩雑になることも懸念されました。今回の KLA のデータ規模とサービス特性には MV は適合しないと判断し、新機能のクエリパターンに最適化したソートキーを持つマートテーブルとして作成する方針を選択しました。 しかし、ワークグループを分離した上で新機能用ワークグループにもテーブルを持つ構成にすると、日次データ連携や VACUUM・ANALYZE などのテーブル管理を両方のワークグループで行う必要が生じます。この課題を解決する手段として Amazon Redshift Data Sharing を採用しました。 Data Sharing とは、データをコピーや移動することなく、異なるワークグループ・クラスター・AWS アカウント間でライブデータへの即時アクセスを可能にする機能です。データを保有する側をプロデューサー、参照する側をコンシューマーと呼び、プロデューサーが datashare（共有単位）を作成してデータベース・スキーマ・テーブル・ビューなどを公開します。コンシューマーはその datashare に接続することで、データの実体を持たずに直接クエリを実行できます。 KLA での具体的な構成は以下の通りです。プロデューサー側の既存機能ワークグループに、従来機能用と新機能用の2種類のテーブルを作成し、新機能用テーブルを Data Sharing でコンシューマー側に公開しています。コンシューマー側の新機能ワークグループはデータを持たずにこのテーブルをリアルタイムで参照するだけで済み、テーブル管理はプロデューサー側に集約されます。これにより、ワークロード分離とテーブルの一元管理を両立しています。 今後の展望 新機能のリリースに先立ち実施したユーザー向け説明会では、「前後立ち寄り機能はまさに欲しかった機能」「活用イメージが湧きやすい」といった声が寄せられ、特に民間企業からの期待が高まっています。 運用改善とさらなるパフォーマンス向上 現在も継続的な改善に取り組んでいます。 パフォーマンスの継続的な改善： 現在の構成では、プロデューサーワークグループ上でクエリ実行と VACUUM・ANALYZE などのメンテナンス処理が同時に行われるため、数十 TB 規模のデータを扱う KLA では両者が干渉するケースがあります。なお、VACUUM・ANALYZE は現在定期バッチで対応しており、Redshift のオートノミクス（自動実行）機能は利用していません。2026 年 2 月に Amazon Redshift のオートノミクス機能が強化され、 自動バキューム・自動分析などのメンテナンス処理に追加コンピューティングを割り当てることで、ユーザーワークロードへの影響を抑えながら自動実行できるようになりました 。VACUUM・ANALYZE の自動実行については、日次データ連携との実行タイミングの兼ね合いも考慮しながら、追加コンピューティング割り当て機能の活用も含めて引き続き検討を進めていく予定です。 メンテナンス作業の効率化： ⼤規模なデータ追加やテーブル変更など、Redshift に⼤きな変更が必要な場合では、サービス提供を止める時間を最小限に食い止めるため、短時間でメンテナンス作業を終わらせる必要があります。Redshift へのデータ投⼊所要時間を考慮すると、事前にスナップショットから新規 Redshift を復元して変更を加えておき、その短時間のサービス停止中に、Redshift を切り替えるという運⽤を現在取っていますが、この⽅法では、新規 namespace を作成するたびに datashare の参照先をコンシューマー側で、⼿動で変更し直す作業が発生します。2026 年 3 月、Amazon Redshift Serverless に スナップショットから同一 namespace にリストアした際に datashare のパーミッションが自動で維持される機能 が追加されました。新規 namespace への復元ではなく既存の namespace への上書きリストアに運用を切り替えることで、コンシューマー側の手動変更作業を解消できる可能性があり、今後検討を進めていく予定です。 まとめ KDDI による本取り組みは、位置情報ビッグデータ分析における Amazon Redshift Data Sharing の実用的な活用事例です。既存機能と新機能でワークロード特性が根本的に異なるという課題に対し、Data Sharing を活用してコンピューティングを分離することで、ワークグループ間のデータコピーなしに各機能に最適化したテーブル設計とリソース配分を実現しました。 従来の公的統計データでは把握できなかった「人の動き」を、GPS 位置情報データと AWS のスケーラブルな分析基盤を組み合わせることで可視化し、観光施策や商圏戦略の高度化に貢献しています。今後の展開と成果に注目していきたいと思います。 著者 高山 伸也 KDDI株式会社 パーソナル事業統括本部 システム開発本部 プラットフォームビジネス部 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト