Microsoft Fabric Lakehouseによるデータ統合・AI活用基盤の構築 本プロジェクトでは、複数の内部・外部データをMicrosoft Fabric Lakehouseへ統合し、リアルタイム処理とAI活用に適したデータ基盤を構築しました。プロジェクト規模は20人月、開発期間は5カ月で、テキスト・画像・音声・動画などの多様なデータ形式に対応しました。 プロジェクト概要 構築対象 データ統合・AI活用基盤 プロジェクト規模 20人月 開発期間 5カ月 対応データ形式 テキスト・画像・音声・動画 従来の課題 01．データの分散 データが複数の場所に分散していたため、必要なデータの収集に多くの時間と労力を要していました。 02．意思決定基盤の整備 データ活用に必要な最新型DWHの整備が急務となっていました。 ソリューション 01．データの一元化 内部・外部の構造化データと非構造化データをLakehouseへ集約しました。 02．リアルタイム処理 Delta Tableを活用し、最新データの処理を支援する基盤を構築しました。 03．AI活用基盤 データ分析とAI活用に適したLakehouseアーキテクチャを構築しました。 データ活用の仕組み 01．データ統合：内部・外部のさまざまなデータをLakehouseへ集約しました。 02．データ処理：集約したデータをETLで変換・整理し、Delta Tableで管理しました。 03．分析・AI活用：処理したデータをPower BIとAzure AI Foundryへ展開しました。 使用技術 Python｜pandas｜PyTorch｜Microsoft Fabric｜Azure AI Foundry｜Azure AI・データ活用について相談する AIソリューション実績集をダウンロードする
物流プラットフォームをAWSマイクロサービスへ刷新 本プロジェクトでは、米国物流企業の配送・アカウント・追跡・返品業務を支えるモノリス型の物流プラットフォームを、AWS上のマイクロサービスへ刷新しました。プロジェクト規模は241.45 MMで、システムの拡張性・可用性とデータ活用基盤を強化しました。 プロジェクト概要 対象システム 物流プラットフォーム 対象業務 配送・アカウント・追跡・返品 プロジェクト規模 241.45 MM 使用技術 PHP、PHP 8.1、AWS システム移行の概要 既存の物流プラットフォームはモノリス型で、システム稼働率は85％にとどまり、拡張性と耐障害性に課題がありました。本プロジェクトでは、既存システムをマイクロサービス化し、GCP上のワークロードをAWSへ移行しました。 Services Account、Shipment、Tracking、Return Shipment、Worker Application PHP 8.1、Laravel Platform Docker、Amazon ECS Data RDS MySQL、DynamoDB、ElastiCache NTQの担当範囲・進め方 01．業務・構成設計 物流業務と将来計画を踏まえ、ビジネスドメインを反映したマイクロサービス構成を設計しました。 02．アプリケーション再構築 既存アプリケーションをリファクタリングし、各サービス向けのAPIを開発することで、システムを5つのサービスに分割しました。 03．クラウド基盤移行 AWS基盤を再設計し、GCP上で稼働していたワークロードをAWSへ移行することで、システム基盤をAWSへ統合しました。 04．品質・運用強化 セキュリティテストと監視環境を整備し、監視とセキュリティを強化することで、安定運用を支援しました。 導入効果 01．システム稼働率の向上 障害分離とプロアクティブな監視により、システムの可用性を大幅に向上し、稼働率を85％から99.9％へ改善しました。 02．拡張性・耐障害性の強化 サービス単位で拡張できる構成により、ピーク負荷への対応と障害影響の局所化を実現しました。 03．データ活用基盤の整備 DWHとデータアクセスAPIを整備し、複数のデータソースを対象としたデータ分析を可能にしました。 マイグレーションについて相談する 実績集をダウンロードする
IBM i／AS400物流管理システムをJava・AWSへ刷新 本プロジェクトでは、全国400拠点を展開する大手総合物流企業の倉庫・配送・受発注・料金業務を支える物流管理システムを、IBM i／AS400からJava・AWSのマイクロサービス基盤へ刷新しました。プロジェクト規模は200～300人月で、システムを6つのコアドメインに分割して再構築しました。 プロジェクト概要 対象システム 物流管理システム 対象業務 倉庫・配送・受発注・料金業務 対象拠点 全国400拠点 プロジェクト規模 200～300人月 再構築単位 6コアドメイン 現行システムの問題 現行システムでは、COBOL、RPG、CL、Shift-JIS、DB2 for i、IBM iを使用していました。5年間で取扱量が2.3倍に増加したことで、システム容量が逼迫していました。 ・5年間で取扱量が2.3倍に増加し、システム容量が逼迫 ・夜間バッチの長期化と、EDI連携に数カ月を要する状況 ・紙中心の運用とデータレイクの未整備 移行先システム構成 Backend／Platform Java 17、Spring Boot 3、JPA、AWS EKS Architecture 6コアドメイン、Kafka（MSK）、マイクロサービス Data Platform Aurora、DynamoDB、S3＋Athena DevOps Jenkins、GitLab CI、Prometheus／Grafana NTQの担当範囲・進め方 01．6コアドメインへの分割 ドメイン駆動で業務境界を明確化し、システムを6つのコアドメインに分割しました。各ドメインをSpring Boot 3とAWS EKSで再構築し、サービスの独立性と拡張性を強化しました。 02．Kafkaによるイベント駆動連携 Kafka（MSK）による非同期・疎結合連携とAPI化を行い、リアルタイム連携を実現しました。これにより、システム負荷を平準化し、EDI接続を迅速化しました。 03．用途別データ多層化 Aurora、DynamoDB、S3＋Athenaを用途別に配置し、参照・分析・履歴データを分離しました。これにより、データコストを最適化しました。 04．OR-Toolsによる配車最適化 OR-Toolsの最適化アルゴリズムを導入し、再配車計算と進捗管理を効率化しました。その結果、再配車計算にかかる時間を10分の1に短縮しました。 導入効果 01．可用性・拡張性の向上 サービスの独立性を高め、取扱量の増加に柔軟に対応できるシステムを実現しました。 02．リアルタイム連携の実現 夜間バッチの負荷を平準化し、EDI接続のリードタイムを短縮しました。 03．データ活用基盤の確立 データレイクを整備し、AI／BIによるデータ活用を促進しました。…