ヤナセは従来、DC事業者にインフラ運用を委託し、5年ごとにサーバを更改してきた。しかし、セキュリティ要件が高度化する中、2025年末のDC契約満了を機に従来型の運用を見直した。

　同社は、5年周期のハードウェア更改から脱却し、ソフトウェアのライフサイクルに合わせて柔軟にインフラを変更できる環境を目指してクラウド移行を決断した。Oracle Databaseのライセンス対応や市場シェアなどを考慮し、AWSを採用。移行や運用の支援先にはサーバーワークスを選んだ。

　AWS環境では、アカウント管理サービス「AWS Organizations」を使った統合管理基盤を構築し、「AWS Direct Connect」でオンプレミス環境と接続した。アプリケーション基盤はElastic Load Balancingのサービス「Application Load Balancer」（ALB）、「Amazon Elastic Compute Cloud」（Amazon EC2）、「Amazon Relational Database Service」（Amazon RDS）による3層構造とし、インターネット接続部分には「AWS Web Application Firewall」（AWS WAF）を適用した。

　ただし、AWS上に新しい環境を構築するだけでは移行は完了しない。既存環境では複数のアプリケーションが密接に連携しており、それぞれがどのシステムと、どのような通信をしているのかを把握する必要があった。

ログを解析し「必要な通信だけ」を許可

　ヤナセは約70台のサーバを移行するに当たり、ログ解析などを実施してシステム間の通信要件を洗い出した。その上で、必要な通信だけを許可するようルールを細かく定義していった。

　その背景には、ヤナセの親会社である伊藤忠グループが定める高度な情報セキュリティ基準への対応があった。ヤナセはクラウド移行を、単なるインフラ更改ではなく、既存環境のセキュリティレベルを引き上げる機会と位置付けた。

　一方、通信を厳しく制限すると、これまで明示的に把握されていなかった通信が問題になる。

　ヤナセ 情報システム部 運用統括二課の林 智彦氏によると、通信制限を厳しくしたことで、開発・テスト工程では実際の利用状況に合わせて通信ルールを追加、見直すケースが多数発生したという。

　つまり、既存環境で「問題なく動いている」ことと、システム間の通信関係を情シスが完全に把握できていることは同じではない。この経緯からは、クラウド移行に当たり、既存システムの通信関係を改めて把握する必要が生じたことが分かる。

全システムを一斉に移行しなかった理由

　通信要件だけでなく、システムを「いつ移すか」も課題だった。ヤナセではブランドや拠点によって営業日が異なり、全社的にシステムを停止できるタイミングが限られていた。そのため、2025年10月からアプリケーションを段階的に移行した。

　まず、疎結合のシステムから先行して切り替えた。その上で、最後まで停止できなかったシステムについては、全社的な停止が可能な年始の休暇期間を使って移行した。

　約70台を一度に切り替えるのではなく、システムの依存関係や業務への影響を見ながら移行順序を決めた。

AWS移行を「既存環境を見直す機会」に

　AWS移行後、ヤナセでは従来のオンプレミス環境では把握しにくかった情報も可視化できるようになった。今後はパフォーマンス分析や障害解析についても、自社内で迅速に進められるようになると見込む。

　ヤナセの事例から見えてくるのは、クラウド移行では「何台のサーバを移すか」だけを考えても十分ではないということだ。長年運用してきたシステムほど、通信経路や依存関係が複雑になり、その全体像を把握できていないケースもある。

　クラウド移行は、そうした既存環境の通信や依存関係を洗い出し、「本当に必要な通信は何か」を改めて整理する機会にもなる。セキュリティを強化しながら移行を成功させるためには、サーバ移設そのものより、その前段にある通信要件の可視化が重要になりそうだ。

本稿は、サーバーワークスが2026年8月25日に公開したサーバーワークス、株式会社ヤナセにおける約70台のサーバーのAWSの移行を支援する導入事例を公開およびAWSの先進的なサービスとサーバーワークスの支援により実現、柔軟なインフラ構成と高度なセキュリティ、インフラの運用効率化とコストの最適化を基に作成しました。