AWS Organizationsでアカウントの統制を実現し
AWSガイドラインの策定で運用ポリシーを標準化

資生堂のパーソナルケア事業が独立し、2021年7月に事業開始した株式会社ファイントゥデイ。事業開始当初からクラウドをベースにIT基盤を構築してきた同社ですが、AWS上で運用するシステムが増えていく中、AWSの統制や運用ルールの整備が課題として浮上しました。解決に向けて同社は、AWS Control TowerとAWS Organizationsによるマルチアカウント管理基盤の構築と、AWS利用ガイドラインの策定を決断し、技術支援パートナーにクラスメソッドを採用しました。プロジェクトについて、IT本部 BITA1部の小室さん、吉田さんにお話をうかがいました。

AWS上で運用するシステムの増加でガバナンスやセキュリティ課題が顕在化

「世界中の誰もが、素晴らしい一日を紡ぎ、いつまでも美しく、豊かな人生を送れるようにする」をパーパスに掲げ、「TSUBAKI」「SENKA」「uno」をはじめとしたヘアケア製品やスキンケア製品のブランドを展開するファイントゥデイ。日本のほか、中国・APACを含む11の国と地域で事業を展開し、「アジアNo.1のパーソナルケアカンパニー」になることを目標としています。

同社は事業開始当初からクラウドファーストを方針に掲げ、運用するシステムに応じて最適なクラウドサービスを選択しています。国内の事業部門・サービス部門が利用するシステムや、基幹系の周辺システム、データ連携基盤、日本固有のシステムなどでAWSを採用しています。

「柔軟性や迅速性が求められる業務システムやサービスシステムには、技術の進化スピードが速いクラウドサービスが必要です。そこで、世の中にエンジニアが多く、ナレッジやユースケースが豊富に揃っているAWSを利用しています」（小室さん）

一方、事業開始から4年を迎えた2025年になるとAWS上で運用するシステムの数が増え、AWSアカウントの統制やセキュリティの課題が見えてきました。

「設立初期の頃はシステム構築を最優先事項としていたこともあり、複数のシステムを1つのAWSアカウントに集約していました。そのため、結果としてコストやトレーサビリティの管理が難しくなっていました。加えてセキュリティポリシーの整備も遅れており、現状の環境で運用を続けるのは限界があると考えました」（小室さん）

マルチアカウント管理基盤の構築とAWSガイドラインの策定に着手

こうした中、AWSアカウントを新たに追加してシステムを開発する案件が発生したことを契機に、AWS Control TowerとAWS Organizationsによるマルチアカウント管理基盤の構築と、全社的なAWSガイドラインの策定に取り組むことにしました。

同社はまずRFP（提案依頼書）を作成し、複数のベンダーにプレゼンテーションを依頼。検討した中からクラスメソッドを技術パートナーに採用しました。「決め手は高いエンジニアリング力にあった」と小室さんは語ります。

「AWSの統制環境を整備するためには、ガイドラインのテンプレートやベストプラクティスの知見が必要です。構築後の運用は私たち自身で対応していく必要があり、そうなると事例やナレッジなどの基礎的な技術をベースに、私たちと議論しながら実環境に落とし込んでいく応用力が求められます。提案の段階で私たちの要件を深く理解し、最善の対応策を提示いただけたのがクラスメソッドでした」（小室さん）

提案内容のわかりやすさも評価のポイントになりました。同社では、AWSの利用を開始した2021年当初から、クラスメソッドの請求代行サービスを利用しています。その中で、クラスメソッドメンバーズの「組織管理プラン」を用いたマルチアカウント管理から、コスト最適化、セキュリティ強化、人材活用まで、幅広い対応策を営業担当者に相談し、議論してきた経緯があります。

「今回の案件でも、クラスメソッドの担当者は当社の環境を理解し、課題解決の方法を的確に提案内容に反映させてくれました。クラスメソッドから提供されるAWSガイドラインのテンプレート（Classmethod Cloud Guidebook）もわかりやすく、これなら自分たちでも理解できると感じました」（吉田さん）

OUとSCPの設計・構築は導入後の運用に即した構成を議論

プロジェクトは2025年8月にスタート。マルチアカウント管理基盤の構築とAWS利用ガイドラインの策定は、ほぼ並行する形で進めました。プロジェクトは小室さんと吉田さんの2人が担当し、クラスメソッドからは2名のエンジニアがサポートに入りました。プロジェクトチームが最初に行ったのは、マルチアカウント管理基盤を構築するうえで必須となる命名規則の定義やアカウント管理などのガイドラインの策定です。

「形式的にガイドラインを作成するのではなく、クラスメソッドの担当者と議論しながら、優先順位を明確にすることを意識して進めました」（小室さん）

その後は、マルチアカウント管理基盤の設計状況を見ながら、テンプレートをベースに、項目単位でガイドラインの策定作業を進めました。

「クラスメソッドの担当者にガイドラインのドラフト版を作成いただき、それを週1回の定例会でレビューしながら実運用に即した形に修正していきました。定例会の前に私たちの確認事項を宿題として提示していただけたこともあり、あらかじめ社内の運用を確認したり、セキュリティ規程を確認したりすることができ、スムーズに進みました」（吉田さん）

AWS Control Towerの有効化とAWS OrganizationsによるOU（組織単位）とSCP（Service Control Policy）の設計・構築フェーズでは、AWSのベストプラクティスに則りながらも、導入後の運用に即した構成を議論し、同社に見合ったルールを決定していきました。

例えば、OUの構成を事業部門単位で分けるのか、本番、検証、開発などの環境単位で分けるのかは企業の運用ポリシーによって異なります。同社のケースではシステムの環境を第一階層とし、その下に事業部門を配置する構成としています。

「今後の拡張性を考慮した結果、当社の場合はシステム環境の下で各事業部のアカウントを集中管理するのがベストと判断し、環境単位で分ける構成を採用しました」（小室さん）

自社運用を見据えて自分たちで理解することを重視

もう1つ、今回のプロジェクトで同社が重視したのは、自社にナレッジやノウハウを蓄積することです。そのため、打ち合わせではAWSの基礎からクラスメソッドの担当者に質問しながら議論を重ねていきました。

「最終的に運用するのは自分たちですが、なぜこの設定をしているのか、どういった考え方で機能が実装されているのかを理解していなければ間違った判断につながり、事業部門に安全で安定した環境を提供することができません。そのため、得られるものはすべてを習得する思いでプロジェクトに臨みました」（小室さん）

「私はAWSによる本格的なインフラ構築のプロジェクトは初めての経験で、AWS Control TowerやAWS Organizationsも名前だけは知っている程度でした。クラスメソッドの担当者から教えていただいたことをその場で調べながら学ぶ形になりましたが、専門的な内容も私のレベルに合わせて噛み砕いて説明していただけたこともあり、自力で対処することができました」（吉田さん）

当初、2025年12月の終了を目標としていたプロジェクトは、想定以上にスムーズに進み、11月には予定の作業を終えました。結果として、工数に余裕が生まれたことから、余剰工数を活用して当初はスコープ外としていた既存AWSアカウントのセキュリティサービス（Amazon GuardDuty、AWS Security Hub等）を今回構築したマルチアカウント管理基盤に集約する設定と、それとは別にIPアドレス管理（IPAM）の仕組みを設定する支援を依頼してプロジェクトを終えました。

「今後の運用を踏まえて、既存アカウントのセキュリティ設定やIPAMまでカバーできたことは大きな収穫でした」（小室さん）

AWS利用が拡大しても統制を維持したままサービスを拡張することが可能に

プロジェクト完了後、新たにAWS上に構築するシステムは、すべてAWS Control TowerとAWS Organizations配下のアカウントで運用する仕組みが整いました。2026年3月時点で、すでに7つの新規アカウントをマルチアカウント管理基盤上で運用しています。

また、AWS利用ガイドラインの策定により、アカウント払い出しの手順や運用ルールも明確になりました。従来は業務部門が独自にAWS環境を払い出していましたが、現在は申請用のフォームやカタログを提供し、申請を受け付けています。

「キックオフ前に既存環境の運用を継続した場合のセキュリティリスクや対応する工数を試算したところ、アカウントが増えるほど管理工数が大きくなるということがわかっていました。今回のプロジェクトで、AWS利用が拡大しても大きなコストをかけることなく統制を維持したままサービスを拡張することが可能になり、当初の目的は達成されました。併せて自社にナレッジとノウハウが蓄積され、次の戦略に役立てることも可能になりました」（小室さん）

管理レベルを底上げしながらユースケースの拡大へ

今後は新たな基盤を活用しながら、サービス管理のレベルを底上げするとともに、ユースケースを拡大することを目標に掲げています。