現場から要望されるAIツールやBIM連携アプリの導入が進まず、事業部門が独自に外部クラウドを契約してガバナンスが形骸化する事態がゼネコン各社で頻発しています。鹿島建設は2014年に導入した単一アカウントのAWS環境を刷新し、2026年4月よりマルチアカウント基盤の本格運用を開始することで、全社的なセキュリティ統制と約30種類におよぶクラウドサービスの迅速な利用を両立させました。
鹿島建設が直面した「10年前のAWS」の制約と新基盤の構造
ゼネコンの生産性向上に向けた取り組みが高度化するにつれ、現場や事業部門が求めるITリソースは仮想サーバーの枠を大きく超えています。鹿島建設が直面していたレガシーインフラの課題と、それを解決したマルチアカウント基盤の構造を整理します。
仮想サーバー主体の「クラウドリフト」が引き起こした機能不全
鹿島建設が2014年ごろに構築したアマゾン ウェブ サービス（AWS）環境は、オンプレミス環境のサーバーをそのままクラウドへ移設した、いわゆる「クラウドリフト」型がベースとなっていました。利用可能なサービスは仮想マシンの「Amazon Elastic Compute Cloud（EC2）」とリレーショナルデータベースの「Amazon Relational Database Service（RDS）」にほぼ限定されており、外部ベンダーへの運用依存度も高い状態が続いていました。
施工現場や研究所でAIによる画像解析、IoTセンサーからのデータ集約、コンテナ技術やサーバレスアーキテクチャを活用した迅速なアプリケーション開発を行おうとしても、旧来の構成では即座に対応できませんでした。その結果、必要な最新技術をタイムリーに使えない事業部門が、個別に外部ベンダーと直接契約を結んで独自クラウドを立ち上げる「野良クラウド」の発生を招いていました。
単一アカウント運用の限界とコスト不可視化
従来のシステムは全社で「単一のAWSアカウント」を共有する形で運用されていました。この構成には、運用面とコスト管理面で以下の深刻な構造的欠陥が存在していました。
- 権限管理の肥大化と事故リスクの増大：全社システムが単一の領域に混在するため、ある部門のアクセス権限変更やリソース操作が他部門のシステムに影響を与える危険性があった
- 事業部門別コストの把握困難：利用明細が一括で請求されるため、土木・建築・開発などの各プロジェクトや事業部門ごとの正確なインフラ原価を算出できなかった
- コスト最適化施策の停滞：長期利用を前提とした割引制度（リザーブドインスタンスやSavings Plans）を適用しようにも、どの部門がどれだけ継続利用するかを判断できず、全社レベルでの調達コスト削減に踏み込めなかった
ガードレール思想とマルチアカウント統合管理
これらの課題を抜本的に解消するため、鹿島建設はAWSアカウントを用途や部門ごとに分割して運用する「マルチアカウント環境」への刷新を実施しました。基盤の中核には、アカウントの一括作成・管理を自動化する「AWS Control Tower」を採用しています。
新基盤のアーキテクチャでは、事業部門の自由な開発を許可しつつ、組織全体のセキュリティ基準を自動強制する「ガードレール」の設計思想が取り入れられました。
| 管理項目 | 刷新前（2014年設計の旧環境） | 刷新後（2026年4月運用の新基盤） |
|---|---|---|
| アカウント構成 | 全社単一アカウントで相乗り運用 | AWS Control Towerによるマルチアカウント分離 |
| 統制方式 | 個別のベンダー任せ・申請ベース | SCP／RCPによる機械的ガードレール制御 |
| 利用可能サービス | EC2、RDSの2種類に限定 | AI、コンテナ、サーバレスなど約30種類 |
| コスト管理 | 全社一括請求で部門別原価が不明瞭 | アカウント単位で利用料を可視化・最適化 |
| 外部データ連携 | 個別許可によるセキュリティリスク | ITソリューション部による一元管理運用 |
セキュリティの制御には、AWS Organizationsの「サービスコントロールポリシー（SCP）」および「リソースコントロールポリシー（RCP）」が組み込まれました。これにより、現場や開発者が誤ってデータをインターネット上へ公開する設定を行っても、基盤側で自動的に通信を遮断します。認証基盤には「AWS IAM Identity Center」、全アカウントの脅威検知・設定監査には「AWS Security Hub」を配置し、統合的な監視体制を構築しています。
参考記事: 施工管理アプリ（クラウド型）入門｜導入メリットと失敗しない選び方を徹底解説
施工現場のDX加速が全社クラウド基盤の刷新を求めた背景
ゼネコン各社において、クラウド基盤の近代化は単なる社内ITシステムの更新にとどまりません。現場オペレーションのデジタル化と法規制への適合を果たすための前提条件となっています。
現場で急増する大容量データと最新AIサービスの需要
建設DXの進展に伴い、作業所から生み出されるデータ量は従来の工事写真や日報のテキストデータから、ドローンによる高密度3次元点群データ、構造物のBIMモデル、重機や作業員の位置・稼働ログへと急拡大しています。
例えば、大規模土木工事における品質・出来形管理では、現場計測データを即座にクラウドへ集約し、3次元モデルと突き合わせる処理が求められています。
参考記事: 鹿島建設、三笠ぽんべつダムで誤差±5cmの自動測量を導入し盛土を3D管理
さらに、現場での写真撮影や配筋検査作業を省力化するため、画像認識AIを活用した検査ツールの現場導入も進んでいます。
参考記事: 鹿島建設、門型AI移動装置を導入し鉄筋籠の立会検査時間を7割削減
こうした現場直結の高度なシステムを稼働させるには、EC2上に手動で環境を立ち上げる従来の手法では工数がかかりすぎ、開発・運用のボトルネックとなっていました。画像処理パイプラインを自動化するサーバレス技術や、マネージドAIサービスの即時利用が不可欠となったことが、基盤刷新の直接的な要因です。
2024年4月上限規制施行後の工事消化能力維持
2024年4月1日より、建設業に対しても改正労働基準法に基づく時間外労働の上限規制（原則月45時間・年360時間、特別条項付きで年720時間等）が適用されました。現場監督や施工管理者の労働時間を圧縮しながら、増大するインフラ補修・都市再開発案件の工事消化能力を維持するには、バックオフィスと作業所間の業務分断をなくす必要があります。
事業部門ごとにバラバラの外部クラウドやオンプレミスサーバーにデータが保管されている状態では、設計から施工、維持管理に至るバリューチェーン全体でのデータ連携が阻害されます。ITガバナンスを確保した共通クラウド基盤の上でデータを一元化し、本社・支店から現場支援を行う遠隔管理体制を整えることが、全社的な経営命題となっていました。
刷新がもたらした開発スピード向上と原価管理の成果
2024年7月にITソリューション部主導で発足した「クラウド活用推進プロジェクト」は、パートナーとしてサーバーワークスの伴走型支援「クラウドシェルパ」を採用しました。新基盤が稼働したことで、定量的・定性的な効果が表れています。
利用可能サービス約30種への拡大と4案件の本稼働
刷新完了に伴い、事業部門が利用できるAWSサービスは従来の2種類から、コンテナ実行環境（Amazon ECS/EKS）、サーバレス（AWS Lambda）、機械学習基盤（Amazon SageMaker等）を含む約30種類へと拡大しました。
2026年9月時点で、新マルチアカウント基盤上ではすでに4案件のシステムが本番稼働しています。事業部門からはAIサービスを活用した新規システム開発や、既存のオンプレミス・独自環境からの移行に関する相談が毎月継続して寄せられており、社内開発のリードタイム短縮が実証されています。
アカウント別コスト可視化とリソース最適化の実現
マルチアカウント化により、AWSの利用費用が事業部門・プロジェクト単位で完全に分離して集計される体制が確立しました。
これまで単一アカウント運用のため踏み込めなかった「Savings Plans」や「リザーブドインスタンス」といった料金割引プランの適用が可能となり、全社的なインフラ調達コストの最適化が実現しています。各部門の責任者が自らダッシュボードで利用費用を確認できるようになったことで、遊休リソースの停止やスペックの適正化など、現場レベルでの原価意識の向上にも直結しています。
技術の内製化とCCoE機能の確立
本プロジェクトでは、システム構築を外部ベンダーへ丸投げするのではなく、鹿島建設のITソリューション部自らが設計思想を理解し運用を内製化する方針がとられました。
サーバーワークスとの定例会や技術資料を用いた社内勉強会が定期開催され、CCoE（Cloud Center of Excellence）機能の整備が進んでいます。自社エンジニアがマルチアカウントの制御やセキュリティ設計を習得したことで、事業部門からのシステム構築要望に対して外部ベンダーを介さず迅速に環境を提供できる体制が整いました。
ゼネコン・建設企業がクラウド基盤を再構築するための推進手順
大手ゼネコンだけでなく、中堅ゼネコンや広域展開を行う建設会社においても、クラウドインフラのレガシー化や野良クラウド問題は共通の課題です。統制と開発自由度を両立させるための具体的な移行手順を整理します。
ステップ1：セキュリティポリシーの策定とガードレール設計
インフラの構築に先立ち、社内の情報セキュリティ基準とクラウドの運用実態を照合した「クラウド利用ガイドライン」を策定します。
従来の日本型IT管理では「申請書類の提出と人間による承認審査」で統制を図ることが主流でしたが、これでは現場の開発スピードを削いでしまいます。新しい基盤設計では、以下のように機械的に制限をかけるガードレールを優先します。
- 外部公開の禁止：S3バケットやデータベースのパブリックアクセスをSCPで組織全体として一律遮断する
- 利用可能リージョンの制限：データ主権と遅延防止のため、利用リージョンを東京・大阪に限定する
- アカウント分割基準の決定：本番環境、検証環境、開発環境をアカウント単位で物理的に分離し、開発環境での実験が本番環境へ影響を与えない構造にする
ステップ2：マルチアカウント基盤の迅速な展開
アカウント管理基盤として「AWS Control Tower」等の自動化ツールを採用し、共通のガバナンスルールが最初から適用された状態で新規アカウントが払い出される仕組みを構築します。
| フェーズ | 主な実施内容 | 担当組織・役割 |
|---|---|---|
| 要件定義・規程策定 | クラウド利用ガイドライン策定、セキュリティ要件の整理 | IT部門、情報セキュリティ委員会 |
| 基盤構築・自動化 | Control Tower展開、SCP/RCP設定、ID統合基盤構築 | IT部門、クラウド導入支援パートナー |
| パイロット運用 | 新規開発案件数件の先行移行、運用課題の洗い出し | IT部門（CCoE）、先行事業部門 |
| 全社展開・内製化 | 社内勉強会の実施、アカウント払い出しプロセスの標準化 | CCoE、各事業部門エンジニア |
鹿島建設の事例では、2025年6月から9月にかけて利用ガイドラインの策定（ステップ1）を行い、同年8月から12月にかけてマルチアカウント環境の構築（ステップ2）を完了させました。当初は2026年3月の完成を予定していましたが、設計思想をガードレール型へ絞り込んだことで、3カ月の前倒し完了を実現しています。
ステップ3：伴走型パートナーの活用と技術資産の社内蓄積
クラウドのモダナイゼーションを成功させる鍵は、パートナー企業との契約形態にあります。従来の「仕様書に基づく一括請負開発」では、納品後の運用変更や新規サービスの追加が難しく、技術知見が社内に残りません。
鹿島建設が採用した伴走型の技術支援（クラウドシェルパ）のように、自社の技術者が主導権を持ち、専門家の知見を吸収しながら設計・構築を共に行うアプローチが有効です。これにより、完成後の運用保守費用を抑えられるだけでなく、将来的なAWS新サービスの追加や環境仕様の変更を自社の判断でスピーディーに行える組織能力が獲得できます。
社内インフラの棚卸しから始める次世代DXへの移行
建設企業の競争力は、施工現場で取得される多種多様なデータをどれだけ迅速に全社で共有し、AIや自動化技術を用いて現場へ還元できるかにかかっています。10年前のクラウドリフト型構成のまま運用を続けていては、現場のデジタルツール導入を支えきれず、野良クラウドによるセキュリティ事故のリスクも高まります。
クラウドインフラの再構築に向けて、まず自社で稼働しているサーバー環境の棚卸しと、現場・事業部門が個別契約しているSaaSやクラウドサービスの利用実態調査から着手してください。統制と自由度を両立させるマルチアカウント基盤の整備は、将来にわたる全社的なDX施策を支える確実な土台となります。
出典: TechTargetジャパン
出典: 株式会社サーバーワークス プレスリリース
出典: 株式会社サーバーワークス 導入事例
