DOC: EMW-WEB-03 / REV 2026-07-17 / STATUS: PUBLISHED
止められないシステムを、止めずに移し、動かし続けてきた実績です。A track record of moving — and keeping alive — systems that cannot stop.
1マス = 1日。当社が設計・構築し運用を担当する範囲での実績です（上記の注記と同一）。One tick = one day, within our scope of responsibility (same disclosure as above).
老朽化したホストマシン上で稼働する基幹系を刷新したいが、POSは営業時間中に止められない。切替の失敗は店舗の販売業務に直結するため、停止許容時間が極めて短い移行が求められました。The aging host had to be retired, but POS cannot stop during business hours. With store sales directly at stake, the migration had to fit an extremely narrow downtime window.
停止許容時間と切り戻し条件を最初に確定し、依存関係の棚卸しから段階移行計画を設計。Multi-AZ構成のAWS基盤を構築し、リハーサルを重ねたうえで本番切替を実施しました。変更申請・承認記録・作業証跡も監査に耐える形式で整備しています。We fixed the downtime budget and rollback criteria first, then designed a phased migration from a full dependency inventory. After building a Multi-AZ AWS foundation and repeated rehearsals, we executed the production cutover with audit-ready change records.
販売業務を止めずに段階移行を完了。移行後も当社が運用を担当し、重大障害0件を継続しています（2021–2025）。Phased migration completed without stopping sales operations. We continue to operate the platform with zero major incidents (2021–2025).
工場設備と連動するシステムは拠点に残す必要がある一方、サーバの老朽化とデータ活用・監視の分散が課題でした。工場の稼働に影響を与えずにクラウドの利点を取り込む構成が求められました。Systems tied to plant equipment had to stay on-site, but server aging and fragmented monitoring were growing risks. Cloud benefits had to be introduced without touching plant uptime.
工場側とクラウド側の運用境界を先に定義し、拠点とAWSをVPN接続するハイブリッド構成を設計。データ連携・ファイル連携を自動化し、監視をCloudWatchに一元化しました。既存の運用を活かしながら、段階的にクラウド側へ役割を移しています。We defined the on-site/cloud operational boundary first, connected plants to AWS over VPN, automated data and file integration, and unified monitoring on CloudWatch — shifting roles to the cloud in phases while preserving existing operations.
工場の稼働に影響を与えずクラウド活用を開始。分散していた監視と運用の窓口が一本化され、障害の一次切り分けが速くなりました。Cloud adoption began with zero impact on plant operations; unified monitoring accelerated first-line incident triage.
社会インフラを支えるシステムのため、可用性だけでなく「誰が・いつ・何を変更したか」を常に説明できる運用が必須。監査対応と日々の運用スピードを両立する必要がありました。As critical social infrastructure, the platform required not just availability but the ability to always answer who changed what, when — without slowing daily operations.
本番・検証・ログ集約をアカウント単位で分離するマルチアカウント構成を設計。CloudTrail・Configによる証跡の自動集約、承認者と実行者を分離した2段階承認、定期的な権限棚卸しを運用フローとして定着させました。We designed a multi-account structure separating production, staging, and log aggregation; automated evidence collection with CloudTrail and Config; and embedded two-step approvals and recurring access reviews into the daily workflow.
監査に提出できる証跡が日常運用の中で自動的に残る体制を実現。統制を強めながら、変更作業のリードタイムは維持しています。冗長構成とあわせて、継続稼働を支えています。Audit-ready evidence now accumulates automatically as part of daily operations — stronger governance without longer change lead times, supporting continuous service on a redundant foundation.
社内システムごとにID・パスワードが分かれ、利用者はパスワードの使い回し、情報システム部門は入退社のたびに複数システムのアカウント作成・削除に追われていました。特定ベンダーの認証製品へのロックインを避けたいという要件もありました。Every internal system had its own credentials — users recycled passwords while IT chased account provisioning across systems at every join and leave. Avoiding vendor lock-in was also a requirement.
OSSの認証基盤Keycloakを選定し、AWS上にMulti-AZの冗長構成で設計・構築。データストアはRDS（Multi-AZ）に置き、認証基盤自体が単一障害点にならない形にしました。既存の社内ディレクトリとはユーザーフェデレーションで連携し、各社内システムはSAML／OpenID Connectで順次SSO化。一斉切替ではなく、システムごとに段階接続する移行計画で進めました。We selected Keycloak (OSS) and built it in a Multi-AZ redundant topology on AWS with RDS Multi-AZ as its datastore — so the identity platform itself is no single point of failure. Federated with the existing corporate directory, internal systems were onboarded to SSO one by one via SAML / OpenID Connect.
社内システムへのログインが一本化され、利用者は1組の認証情報とMFAで安全にアクセス。入退社時のアカウント管理も一元化され、退職者アカウントの消し忘れリスクを構造的に排除しました。認証という「全システムの入口」を、止まらない構成で運用しています。One set of credentials plus MFA now opens every internal system. Joiner-leaver management is centralized, structurally eliminating orphaned accounts — and the front door to every system runs on a no-single-point-of-failure foundation.
大手SIerの二次請けとして、Storage Spaces Direct（S2D）によるHCI仮想化基盤をゼロから設計・構築する役目でした。ライブマイグレーションでノードを無停止に退避できることが要件。正直に言えば、これは一筋縄ではいきませんでした。S2Dはネットワーク（RDMA/RoCE、DCB/PFC）・クォーラム・移行用AD・ライブマイグレーションの認証まで、どれか一つ設計を誤ると本番で不安定になる、落とし穴の多い領域です。As a subcontractor to a major SIer, we designed and built a Storage Spaces Direct (S2D) HCI platform from scratch, with a hard requirement to evacuate nodes non-disruptively via live migration. Frankly, it was not straightforward: S2D is a field full of pitfalls — RDMA/RoCE with DCB/PFC, quorum, the migration AD, and live-migration authentication — where a single design mistake destabilizes production.
いちばん時間がかかったのは、実は手を動かす前でした。既存構成の事前調査、SIerや関係者との調整、そして設計を固める工程——ここを詰め切らないと後で必ず跳ね返ってきます。実際、最初はネットワーク周り（RDMAのDCB/PFC設定、SETスイッチ）で何度もつまずき、ストレージのレイテンシや切断の原因をスイッチ側のPFC・ジャンボフレームまで遡って潰しました。ライブマイグレーションが動かない問題は、既定のCredSSPでは要件を満たせず、移行用ADにSPNを登録しKerberos制約付き委任を構成して解決。クォーラム（ファイル共有ウィットネス）、CSV/ReFSのボリューム設計、CAUによる無停止更新まで、一つずつ検証を重ねて本番に載せました。The most time-consuming part was actually before touching hardware: surveying the existing setup, coordinating with the SIer and stakeholders, and nailing down the design — skip that and it bites back later. Early on we stumbled repeatedly on the network (RDMA DCB/PFC, SET switches), tracing storage latency and drops all the way back to switch-side PFC and jumbo frames. Live migration wouldn't work under the default CredSSP, so we registered SPNs in the migration AD and configured Kerberos constrained delegation. Quorum (file-share witness), CSV/ReFS volume design, and non-disruptive patching via CAU were each validated step by step into production.
難所を一つずつ潰し、ライブマイグレーションでノードを無停止に退避できるHCI基盤として本番稼働にこぎ着けました。そして——このとき散々つまずいた経験こそが、いまのEMWの財産です。S2D・Hyper-V・AD・Kerberosの勘所を「実際に失敗して覚えた」から、AWSへ移行する案件でも、オンプレ側で何が起きているかを正しく理解したうえで設計できます。We knocked down the hard spots one by one and brought the HCI platform into production with non-disruptive node evacuation via live migration. And that painful, stumble-filled experience is exactly what EMW is built on: because we learned the ins and outs of S2D, Hyper-V, AD, and Kerberos the hard way, we can design AWS migrations with a correct understanding of what is really happening on the on-prem side.
ここに掲載しているのは事例の一部です。遊技機メーカーの高負荷基盤運用、中小企業のスモールスタート構成など、規模・業種を問わず対応しています。 These are a selection of our cases. We also handle high-load platforms for amusement equipment makers and small-start architectures for SMBs.
現状の構成図や困りごとを共有いただければ、進め方を整理してご提案します。Share your current setup and pain points — we'll propose a practical path forward.
相談するStart a Conversation