MUFG、スクウェア・エニックスなどが進める“着実な”システム基盤刷新：クラウドシフトで見据える未来

IBM、Red Hatとの連携拡大でもたらされる効果

　イベント冒頭、HashiCorpで営業責任者を務める伊藤健志氏、Head of Japan SEを務める小原光弥氏が登壇し、同社のプロダクトの現在地を紹介した。現在、HashiCorpは7つの商用版プロダクトを提供している。インフラ分野では「HashiCorp Terraform」「HashiCorp Packer」「HashiCorp Nomad」「HashiCorp Waypoint」、サイバーセキュリティ分野では「HashiCorp Vault」「HashiCorp Boundary」「HashiCorp Consul」が提供されており、どれも広義のクラウド環境構築や運用業務を簡素化することで、ユーザーが本来の業務に集中できるようにすることをコンセプトにしたものだ。

　2025年上半期のテクニカルアップデートのなかで、特に注目すべき製品はVaultシリーズの「HCP Vault Radar」だという。これは、GitHubやJiraなどをスキャンし、コードや履歴に埋もれているシークレットを検出するレーダーの役割を果たす。過去に第一弾をリリースし、2025年4月にあらためて一般提供を開始した。

　また、IBMに買収されたことにより、同社は今年新たなスタートを切ることとなる。今後は、IBMやRed Hat製品との連携が広がっていくだろう。その動きは既に見受けられており、たとえば2025年5月にアメリカで開催されたイベント「IBM Think 2025」では、アプリケーションリソース管理ソリューション「IBM Turbonomic」とTerraformの連携が発表された。これにより、Terraformでの環境構築だけでなく、構築後の運用とリソース最適化にまで自動化を広げられる。

　加えて、HashiCorpの管理対象も広がることになる。HashiCorpプロダクトの管理対象は、オンプレミスのハイパーバイザーも含まれているものの、基本的にはクラウドだった。そんな中、2025年3月には「Terraform for Z」「Vault for Z」「Nomad for Z」、メインフレーム向けライセンスが発表され、IBM z/VMやRed Hat KVMベースのLinux仮想マシンでHashiCorpプロダクトを活用できるようになった。

　Red Hat関連では、「Ansible」とTerraform、「OpenShift」とVaultで連携が広がる。これまでもAnsibleとTerraformは場面ごとの使い分けがカギとなっていたが、連携が強化されたことで、Terraformがインフラを、Ansibleが設定レイヤーを司るといった形で使い分けが明確になった。実際のユースケースとしては、Amazon EC2をTerraformで構築し、立ち上がった後のOSレイヤー以降をAnsibleで管理するといった使い方ができる。

　HashiCorpは、「Tao of HashiCorp」と称される哲学を持っている。同社のビジョン、開発ロードマップ、プロダクトデザインの基礎となる哲学が8つのキーフレーズでまとめられており、そのなかでも小原氏は「Workflows, not technologies」というキーフレーズを紹介した。これは、プロダクトありきで考えるのではなく、顧客が業務をどう変えたいのかをもとに適切な機能を創造していくべきという概念だ。

　「HashiCorpはIBMの一員になったが、我々のプロダクトを中心にお客様に提供、提案することは変わらない」と伊藤氏。その後、イベントでは4社の導入事例が発表された。

MUFGが目指す「クラウドファースト」次世代基盤構築の裏側

　まず登壇したのは、三菱UFJフィナンシャル・グループ（以下、MUFG）でIT・デジタル戦略を牽引するグループ会社、三菱UFJインフォメーションテクノロジー（以下、MUIT）だ。MUITは、「クラウドファースト」「基盤強化」といったミッション実現の一環で、「Terraform Enterprise」の試験導入を実施。同社で次世代オンプレミス基盤を担当する寶田吉文氏は、クラウド活用の歩みとともに取り組みの過程を明かした。

　MUFGは2017年にクラウドファーストを宣言してから、クラウドセキュリティ統制強化、基盤CoE発足、人材育成、コンテナ活用などの取り組みを加速度的に進めてきた。2024年にはクラウド共通基盤（AWS）のアカウントが400を超えるまでに発展し、基盤強化を進めている。

　当初、クラウド共通基盤はシングルアカウントでスモールスタートし、徐々にマルチアカウントでスケールする仕組みを導入していった。セキュリティ対策の強化や人材育成などにも取り組み、継続的なレベルアップを図ってきた。

　クラウド化が進むにともない、基盤部門では提供リードタイムの短縮、マルチクラウド対応、CI/CD対応など、様々な負担が増大していたため、MUITは解決に向けて「Landing zone（ランディングゾーン）」という概念を掲げた。これは、クラウド環境を安全かつ効率的に使うための、空港の滑走路のような土台となる考え方だ。具体的には、Day0で要件を明確化し、Day1でブループリントをベースに素早くデプロイ、Day2以降でセルフサービス型のオペレーションを繰り返す。この概念は、クラウドだけでなくオンプレミスにも応用できる。

　このランディングゾーン構築に向けて、同社が着目したのがTerraform Enterpriseだった。寶田氏は、このランディングゾーンを構築するにあたり「共通基盤部門が抱える課題を突破するには、ボトムアップで自律的に解決していく流れが重要だ」と考えていたという。

　同氏は社内制度を活用して有志を募り、Terraformを活用してランディングゾーンの試行と評価をPoC環境で進めることにした。オンプレミスとクラウドのチームを横断し、Terraform Enterpriseの各機能を評価し合う方法が用いられたとのことだ。

　同社の共通基盤は7年ほどかけて開発・構築・運用されており、“質と量”にこだわった既存のシステムが多数存在している。それらの既存システムとTerraformをうまく融和させながら、スピードとセキュリティのバランスを保ったセルフサービス化を実現する狙いだ。

　この狙いを検討すべく、同社はDay2を「まず試す」ための施策を行ったという。Terraform Enterpriseを活用し、1ヵ月ほどでMVP環境（PoC）を構築して試用した。ここでは、利用者の認知負荷を下げることとスピード感を重視したとのことだ。

　実際に試行した結果、Terraform Enterpriseには大きく2つの評価ポイントがあったという。1点目は、社内にSaaS技術を丸ごと展開可能であると確認できたことだ。HCP Terraformの技術をセキュリティ要件が厳しい社内の閉域網（Air-Gapped環境）に持ちこみ、コンテナとしてTerraform Enterpriseのプロセスを起動させることができた。寶田氏は「この5GBのコンテナイメージの中には、『夢・ワクワク』が詰まっている」と語る。

　2点目の評価ポイントは、サポートの充実度だ。同社は、閉域網内でのRHEL9のPodman環境構築や証明書対応などに、Terraform Enterprise付属のサポート機能を活用した。「丁寧なサポートは有益だった。おかげさまでPoC環境を短期間で作り上げることができ、プロに相談できる価値を確認できた」と同氏。環境構築時にTerraformのエラーメッセージが開発者に寄り添っている部分も評価し、「コミュニティで鍛え上げられたツール」だとした。

　MUFGのTerraform活用は、まだ走り始めたばかり。寶田氏は「まずは社内の有志メンバーで小さく始めてみることを推奨する。小さなMVP環境を作り、自然と人が集まる取り組みにするのも重要だ」とメッセージを送った。

IIJが進めた機密情報管理システムの構築、“入れっぱなし”にならないための施策とは

　2つ目の事例企業として登壇したのは、国内初の「商用インターネット接続サービス」事業者であるインターネットイニシアティブ（以下、IIJ）だ。同社は「Vault Enterprise」を活用してEntra IDと連携したシークレット管理インフラを構築し、社内の活用普及を図った。

　IIJの社内クラウドには、閉域ネットワークやベアメタルサーバー、Kubernetesクラスタなどが設置されている。「Azure Kubernetes Service（AKS）」や「Amazon Elastic Kubernetes Service（EKS）」を利用するときのように、プロジェクトごとにサービス用のクラスタを作るのではなく、SRE（Site Reliability Engineering）チームが大きなクラスタを構築し、マルチテナント環境を整えている。ほかにもSREチームは、Kubernetesを使ううえで必要なサービス（ロードバランサ、オブジェクトストレージ、モニタリングシステム、コンテナレジストリなど）の開発や運用も担っている。

　Vaultを導入した背景課題としては、IIJで機密情報（シークレット）を格納する場所・方法が厳密に定められていなかったことが挙げられた。Atlassianのコラボレーションツール「Confluence」のプライベートページやプライベートリポジトリ、各自のExcelシートなどに情報が格納されており、セキュリティ面で懸念があった。この問題はオペレーション自動化の妨げにもつながっていたため、同社はシークレット管理システムの導入を検討。ネットワーク本部 SRE推進部 シニアエンジニアの鈴木高彦氏は、同社の文化について「ボトムアップな社風で新しい技術を試すことは得意だが、トップダウンで統制をとることは苦手だったため、手付かずの状態が続いていた」と話す。

　同社がシークレット管理システムに求めた要件は様々だった。まず、社内のシークレット管理インフラとして、部門やプロジェクトを問わず利用できること。次に、オンプレミス環境でも利用できること（管理対象がシークレットであり、クラウドサービスの採用には抵抗があったため）。加えて、DR（災害復旧）構成がとれることや、社員の異動・退職などにスムーズに対応できるよう、アカウントやグループ管理とEntra ID（旧Azure AD）が連携できること。ほかにも、Terraform、Ansible、GitHub、Kubernetesとの連携が容易であることが望ましかった。こうした技術的な要件をほぼすべて満たすソリューションが、Vault Enterpriseだったという。

　今回のVault Enterpriseのシステム構成は、地理的に分散した2つのデータセンターをまたぐ「DR Replication」の構成を採用。1サイトにつき3台のサーバーから成るVaultクラスターを構築した。また、全社的なシステムとするには人間が複数の部署やテナント（namespace）に同時に所属できるようにする必要があったため、Vault Enterprise内のroot namespaceにEntity（人間）を配置。同時に、Entra IDと連携する外部グループもroot namespaceに設置した。テナントには、root namespaceのグループをメンバーとするインターナルグループを配置した。

　技術的な導入の壁を突破した後に待ち構えていたのが、“社内での普及”という問題だ。先述のとおり、IIJはトップダウンで「今日から全員Vaultを使うように」と号令をかければ普及が進むような社風ではない。そのため、コスト負担と煩雑な移行作業が必要なので社内周知には取り組むものの、利用判断とタイミングは部署やプロジェクトに委ねる方針で進めたという。

　「当社にはスキルや意欲の高いエンジニアが多く在籍しているため、ドキュメントなどがあれば各自が自主的に読み込んで体得します。有用なツールだと評価されれば、それぞれが社内ブログなどを通じて自らの言葉で発信してくれます。そのため、ツール導入後は『Vault Enterpriseを活用してこんなにセキュアな環境になりました』と、エンジニア自身が自分の手柄として周囲に語れるような環境を作りたかったんです。そこで、Vaultに興味を持った人のやる気を妨げない環境づくりを意識しました」（鈴木氏）

　具体的には、社内勉強会や社内ブログ、社内事例の発信で周知に力を入れた。また、ドキュメント整備にも取り組み、ユーザーがVault Enterpriseへの興味を失う前に、一通りの操作を管理者への依頼なしで活用できる環境を作った。

　ただし、テナントの払い出しだけは管理者への申請が必要になる。そこで、テナント作成時にKVシークレットエンジンの有効化、グループ・ポリシーの作成、Entra IDとの紐付けなど、最低限の設定を自動で流し込むようにしたとのことだ。なお、「利用者の増加にともないテナント作成の負担が増加する」といった課題に対しては、YAMLで定義したテナント設定をTerraformで読み込み、自動で作成する仕組みを導入するというアプローチをとった。

　今では鈴木氏の狙い通り、先進的なユーザーをはじめ、着々とVaultの利用者が増えているという。直近では、IIJ自身がサイバー攻撃を受けたことでセキュリティ対策への社内の意識が高まり、利用申請も急速に増加した。利用者の急激な増加に対しても、ドキュメントや申請フローを整備していたため、特に大きな混乱もなく進んだそうだ。最後に鈴木氏は、「Vaultにはとっつきにくいところもあるが、よくできたプロダクトだ」と太鼓判を押した。

スクウェア・エニックスは、オンラインゲームのサブシステムをどう管理している？

　3社目の事例として登壇したのは、デジタルエンタテインメントのスクウェア・エニックスだ。同社は、ワークロードオーケストレーターである「Nomad」を社内システムに導入。オンラインゲームサブシステムとWebプラットフォームにおけるユースケースを2つ取り上げながら、社内での活用の様子を紹介した。

ユースケース 1. オンラインゲームのサブシステムが稼働するコンテナ管理

　同社内には、長年システムを運用するなかで構築されてきたDNS（Domain Name System）、メール、ログなどの細々としたサブシステムが多数存在する。これらは関係者のみアクセスが可能であるため小規模・低負荷ではあるものの、開発業務には必要不可欠だ。そのため、冗長性や可用性を確保する必要がある。また、オンプレミスで稼働させているためクラウドのように柔軟にスケールできず、「既存のリソースをいかに有効活用できるか」が課題となっていたと、情報システム部 オンラインサービス・インフラストラクチャー テクニカルスペシャリストの島田太郎氏は語る。

　Nomad導入前の運用環境については、物理サーバーからVMwareを経て、2024年からはコンテナで運用しているが、コンテナの配置や構成管理の労力が大きな課題となっていた。それを解決するためのコンテナ管理ツールには、以下のような要件が求められたという。

• 少人数で運用管理ができるシンプルなものであること
• 可用性を確保するために複数ノードへの自動的なコンテナ分散配置が可能であること
• 専任の作業員を必要としないようにコンテナ起動の設定ファイルが宣言的であること
• コンテナホスト障害時にはサービス自動復旧できるものであること

　一方で、オートスケーリングやRole-Based Access Control（RBAC）のような細かな権限管理については、前述のとおり低負荷なシステムだったため必要なかった。このような要件をすべて満たしたのが、Nomadだったというわけだ。導入時はリファレンスアーキテクチャに準拠し、Nomadサーバー3台、Nomadクライアント3台、Consulサーバー3台で構成した。

　導入効果としては、まず「運用効率の向上」が挙げられた。従来はサーバーに手動でログインしてから稼働状況を確認していたが、Nomad導入後はWeb UIで稼働ノードやコンテナを確認できるようになった。コンテナへのシェル接続もWeb UIから可能となり、ジョブファイルやDockerfileがGit管理されることで、設定確認も容易になったという。また、作業端末で本番相当の環境を再現できるようになり、事前確認が可能となった結果、設定変更作業時の精度が向上した。将来的には、サーバーログインが不要な運用体制を構築して、よりセキュアな環境の実現を目指すとしている。

　島田氏は、「Nomadは検証までのハードルが低い。ただし検証から本番運用までには、デフォルトの設定が非セキュアな部分もあるので注意が必要」と説明する。また、インターネット上には本運用に関する情報が少ないため、フルスクラッチで組み上げる必要があると指摘した。しかし、設定自体はシンプルであるため、公式ドキュメントを読めばほとんどの問題は解決できると補足した。

ユースケース 2. Webプラットフォームのコンテナ化にともなうNomadの導入

　続いて紹介されたのは、自社や親会社のWebサイト、各種ゲームのプロジェクトサイト、そしてこれらを更新する管理ツールなどをホスティングしているWebプラットフォームにNomadを導入したケースだ。この事例の裏側について、スクウェア・エニックス 情報システム部 オンラインサービス・インフラストラクチャー リードエンジニアの片柳勇人氏から詳細が語られた。

　このWebプラットフォームでは、サイト制作者がコンテンツをアップすると、インフラエンジニアがミドルウェアやOSでサイトごとの差異を吸収している。その際、サイトごとに投票や外部連携などの独自要件が発生するため、裏側で支えるエンジニアに負担がかかっていた。また、複数種類の仮想マシンをAnsibleで管理するレガシーな運用がなされていたほか、ミドルウェアやOSのアップデートでも労力がかかっており、効率化が求められていた。

　これらの課題に対し、「コンテナ化すればアップデートや管理・構築の課題が解決できる」と見込み、工数を減らすために軽量なオーケストレーションツールのNomadを導入することにしたという。

　構成のポイントは大きく3つに分けられる。1つ目は、CI/CD周辺の構成だ。コンテナのビルドからNomadへの展開をCI/CDでフロー化し、Nomad CLIをCI/CD Pipelineから実行、Nomad planのテストからデプロイまでの各種操作を実施している。NomadのデプロイはNomad Runで行い、基本的にはローリングアップデートを利用する。

　2つ目は、コンテナのオーケストレーションやサービスディスカバリーを実行するシステム構成について。サービスディスカバリーはHashiCorpのオープンソース「Consul」を利用し、KubernetesのPersistentVolume（永続ボリューム）に相当する機能はNomadで実装している。スケジューラー「Cron」の定期JobはNomadのスケジューラーに移植し、安定した稼働を実現しているとのことだ。

　3つ目のポイントは、インフラの構成だ。インフラに関しては、同社が従来活用していた既存のシステムを流用する形で運用されているという。

　「Nomad導入後は、運用や管理の工数は大幅に削減でき、CI/CDを整備することで、ビルド・テスト・デプロイを自動化できました。一方、NginxとApache連携やCI/CD連携の設計では苦労しました。『コンテナ化をスモールスタートで進めたい』などの要件にマッチすれば、Nomadは非常に軽量で便利です。シンプルゆえに運用しやすくトラブルも少なく、実際稼働してから半年経った現在、NomadとConsulで障害は発生していません」（片柳氏）

　将来的には、Nomadをステートレスな小規模ゲームサービスへの展開、大規模ゲームタイトルのサブシステム、オンプレミスとクラウドのハイブリッド化・マルチクラウド化などに活用することも検討しているそうだ。

セブン‐イレブン・ジャパンはオンプレミス開発からの脱却へ　ガバナンス強化で凝らした工夫

　全国にコンビニエンスストアを展開しているセブン‐イレブン・ジャパン（以下、SEJ）は、「HCP Terraform」「Vault Enterprise」「HCP Vault Radar」を導入し、課題解決や効率化を図っている。同社 システム本部 システム企画部 清水慶輔氏が、実際の導入過程での経験を中心に紹介した。

　従来SEJでは、オンプレミス中心のシステム開発が進められていたが、今はクラウド、疎結合、アジャイル、内製開発などへのシフトが推し進められている。Google Cloud上に構築しているデータ利活用基盤「セブンCENTRAL」は、今のSEJのシステム開発の動きを象徴するものだろう。直近は、システムごとにアジャイルに開発を進めてきた弊害で、品質や運用にばらつきが生じていたため、見直しが急務となっていた。

　そこで、同社では「Platform as a Product」として、プロセスやツールの共通化・標準化が進められている。個別最適と連携を重視した各種グローバルスタンダードなツールを選定し、生産性向上とガバナンスの両立を目指す。そのなかで、クラウド構成管理はHCP Terraform、機密情報管理はVault Enterpriseが選定された。

　HCP Terraformの活用目的は、ガバナンス強化とインフラ業務効率化だ。これまでは個別に構成情報が管理されていたが、SEJ管理下のHCP Terraformでインフラ情報を一元管理し、ガバナンスを効かせて効率的に統治していく。同時に、コードの再利用などで効率化や自動化も図っていく狙いだ。いまだ残っている手動での対応作業は今後の検討課題とするものの、必要に応じてデータを資産として保持していくという。

　クラウド開発領域におけるガバナンス強化に向けては、Terraformポリシーを適用する形で設定を進めている。ガバナンスの肝となる部分は、最も厳格な適用レベル（Hard mandatory）で制限し、SEJルールに反する構成は本番環境にリリースできないようにしている。

　Vault（Vault EnterpriseとHCP Vault Radar）の活用目的は、散在しているシークレット情報を集約して情報の自動更新や暗号化などによりセキュリティリスクを極小化すること、情報の一元化による管理業務の効率化や生産性向上などである。なかでも、HCP Vault Radarで約1万を越えるGitHubのリポジトリをスキャンし、不適切と検知したものは優先度が高いものから改善に向けて取り組んでいるとのことだ。

　同社がVault Enterpriseを採用した理由には、高カスタマイズ性（SEJの要件に合わせて設計できる点）、高可用性、接続性（Google Cloudとの直接接続が可能な点）が挙げられた。SEJには膨大な量のシステムがあり、すべてにVaultを適用するには大規模な作業が必要となる。まずはシークレット情報を洗い出し、優先順位をつけて段階的に実装を進めているとのことだ。なお、利用手順書やガイドラインなどは「Confluence」にて明示し、周知を図っている。

　現在は、既存システムで大規模なものからHashiCorp製品の導入を進めている。中規模・小規模なシステムに対しても順次導入を進め、2027年には全システムへの導入完了を目指すという。なお、新規開発システムではRFPにTerraformやVaultの導入を明記している。

　現在はHashiCorp製品の活用が進んでいる同社だが、導入当初は社内にTerraformの経験者こそいれど、Vaultに詳しい人材はほとんどいない状態だった。そのため、Vault推進チームの体制作りの一環でリスキリングも行ったという。

　まずは、ITのバックグラウンドがないメンバーでもVault推進ができるよう、再現性の高いリスキリングモデルを確立するところから始めた。現在は、TerraformとVault習熟エンジニア・中核人材を結集してプラットフォームチームを立ち上げ、持続可能なチームになるための土台づくりを進めているとのことだ。ここには社内のメンバーだけでなく、HashiCorpのレジデントサービスを活用した専門人材も常駐。今は導入の過渡期ではあるものの、導入を終えたシステムもあるため、推進と運用を分けた体制づくりへとシフトしつつある。

　現時点で創出できた効果を挙げると、HCP Terraformによって汎用性が高いモジュールの再利用が可能となったほか、GitHubとシームレスな連携が可能なため、CI/CDワークフローを容易に構築できるようになった。その結果、コスト最適化やガバナンス強化が進んでいる。Vaultに関しては、各システムの認証情報に対して順次一元管理が進み、HCP Vault Radarに関しては、ハードコーティングされた機密情報の検出と対応が進んでいる。

　「HashiCorp製品を導入して実現できている“Platform as a Product”と“見える化”は、今回紹介した事例の中で特に強調したい成果です。今後も、改善を進めながら開発や運用の効率化を高められるよう、プロジェクトを進めていく所存です」（清水氏）