CCoEとは、Cloud Center of Excellenceの略で、クラウドの導入と運用を全社横断で推し進める専門組織のことです。部門ごとにばらばらにクラウドを使い始めると、費用もセキュリティも品質も統制が効きません。全社で同じ土台と同じルールの上でクラウドを使えるようにする司令塔がCCoEです。この記事では、CCoEの定義と担う役割、SCPとタグポリシーによるガードレールの実装、Advisory・Catalyst・Consolidationの3フェーズ、中央集権型と連邦型の選び方、立ち上げの判断基準と体制設計までを、実装者の視点で整理します。
まとめ：CCoEの役割・3フェーズと立ち上げ判断の要点
CCoEは、クラウドの使い方を各部門任せにせず、全社で共通の指針・ガードレール・技術標準を用意して、安全と速度を両立させるための組織です。担う役割は、ガバナンスの策定、アカウント発行やセキュリティのガードレール整備、再利用できる技術標準の提供、コストの統制、人材育成へと広がります。
組織を置いただけでは機能しません。AWSの規範ガイダンスは、CCoEをAdvisory（助言）・Catalyst（推進役）・Consolidation（集約）の3フェーズで整理し、AWS CAFのEnvision／Align・Launch・Scaleに対応づけています。日本語の解説では第3段階をIntegration（統合）と呼ぶ例が見られますが、公式表記はConsolidationです。全ての作業を抱え込む窓口になるのではなく、現場がセルフサービスで安全に使える仕組みを渡す側へ立ち位置を変えられるかが分かれ目になります。
どの規模で立ち上げ、どこまでを中央が握り、どう内製化へ着地させるかは、条件付きで言い切ります。担当が数名の段階で専任の大所帯を組むのは過剰です。まず痛みの大きい一つの統制課題から着手し、ガードレールをコードで固めながら段階的に広げる進め方を推奨します。
CCoEとは何か：クラウド導入と運用を全社で推進する専門組織
最初に言葉の範囲をそろえます。CCoEは特定の製品でも部署名でもなく、クラウドに関する意思決定と標準づくりを全社横断で担う機能の総称です。情報システム部門の一部に置かれることもあれば、事業部門や経営直下の横断チームとして編成されることもあります。
CCoE（Cloud Center of Excellence）の定義と担う範囲
CCoEは、方針の立案・標準の整備・現場の支援を継続的に回す専門チームです。個別案件を速く進めるための一時的な集まりではなく、全社のクラウド利用が広がっても品質とガバナンスを保てるよう、横串で統制と支援を担い続けます。狙いは、現場の自由を奪って中央が全てを握ることではありません。安全に使える土台をあらかじめ用意し、その上で各部門が自分でクラウドを扱えるようにして、組織全体の推進力を底上げすることにあります。
CCoEが必要になる背景と、分散したクラウド利用が生むガバナンス不全
CCoEが求められる原因は、クラウド導入の入り口の低さにあります。部門ごとにアカウントを作り、それぞれの流儀で構築を進められる手軽さは推進の源泉ですが、放置すると弊害が積み上がります。セキュリティ設定は部門ごとにばらつき、誰がどのアカウントを持つかも把握しづらく、費用の全体像も見えません。クラウドネイティブとは何かで解説されるコンテナやマネージドサービス中心の構成では、部品が細かく分かれるぶん設定箇所も増え、統制の抜け漏れが起きやすくなります。ばらばらの導入が全社の負債に変わる前に、共通の土台とルールを敷く役割としてCCoEが要ります。
CCoEとAWS CAF（クラウド導入フレームワーク）の6視点の対応関係
CCoEが何を整えるべきかを見取り図として示すのが、AWSのクラウド導入フレームワーク（AWS CAF）です。CAFは、クラウド変革に必要な能力をBusiness・People・Governance・Platform・Security・Operationsという6つの視点（パースペクティブ）で整理します。CCoEが受け持つ領域は、おおむねこの6視点に対応する範囲です。フレームワークの暗記が目的ではなく、自分たちのCCoEがどの視点をどこまで担うのか、抜けている視点はどれかを点検する物差しとして使います。
CCoEの機能スコープを技術6分野と事業5分野に切り分ける整理
視点の次に決めるのは、どの機能を自分たちのCCoEの範囲に入れるかです。AWSの規範ガイダンスはCCoEの機能をエンジニアリング系とビジネス系に分けて列挙しています。エンジニアリング系は、クラウドインフラ、アーキテクチャの整合、運用、セキュリティとリスクとコンプライアンス、技術的卓越性、費用と性能の見直しの6分野。ビジネス系は、営業サイクルの加速、マーケティング、デリバリー支援、財務管理、PMOの5分野です。
この11分野をいきなり全部抱えるのは無理筋です。立ち上げ時はクラウドインフラ・セキュリティ・費用の3つに絞るのが現実的な線で、残りは担い手が育つか痛みが出てから足します。範囲を書き出しておくと、後から「それはCCoEの仕事か」と揉めた時の判断が速くなります。
CCoEの主な役割：ガバナンス・ガードレール・技術標準・コスト・人材
CCoEの仕事は、指針を書いて終わりではありません。現場が安全に速く使える仕組みを、技術として実装するところまでが範囲です。担う役割を、実装者が何をつくるのかという観点で分解します。
ガバナンスとガードレールの設計・SCPと必須タグによる予防統制
CCoEの土台は、破ってはいけない一線を仕組みで守るガードレールです。人手のレビューや規約文書だけでは、利用が広がるほど抜けが出ます。そこでAWS Organizationsのサービスコントロールポリシー（SCP）で危険な操作をアカウント単位で封じ、必須タグを強制し、設定違反を検知するルールを常時働かせます。踏み外しやすいのが、SCPを許可の仕組みだと誤解することです。公式ドキュメントはSCPを粗い粒度のガードレールと位置づけ、SCP単体ではアクセスを付与しないと明記します。実効権限はSCPとアイデンティティベースのポリシーの論理積であり、拒否リスト方式ならFullAWSAccessのような許可ポリシーを併せて付ける必要があります。
ガードレールには、そもそも作らせない予防統制と、作られたものを見つける発見統制の二種類があり、費用や事故のインパクトが大きい操作ほど予防側で止めるのが定石です。自前で書く前に、AWS Control Towerのコントロールリファレンスにある既成のコントロールを当てはめられないか見ておくと、実装量を削れます。全ての利用を人が事前承認する運用は速度を殺すため、頻出の判断はガードレールへ落とし、例外だけを人が見る形に寄せます。
技術標準とベストプラクティスの整備・IaCによる再利用可能な基盤
二つ目の役割は、各部門が一から悩まずに済む共通部品を用意することです。標準的なネットワーク構成、アカウントの初期設定、ログ集約、認証の型を、ランディングゾーンとして組んでおきます。ここで効くのがIaC（Infrastructure as Code）とは何かの考え方で、標準構成をコード化して配れば、各部門は審査済みの土台を数分で複製でき、CCoEは一箇所の更新で全社へ改善を波及させられます。文書のベストプラクティスは読まれずに形骸化しがちです。コードとして渡した標準は、使うだけで守られる点が違います。増えていくアカウントやリソースは、CMDB（構成管理データベース）とは何かの考え方で台帳化します。
コスト統制・セキュリティ・人材育成におけるCCoEの役割分担
CCoEは費用とセキュリティ、人の育成まで見ますが、全てを自前の専門機能で抱える必要はありません。費用の側面は、FinOpsとは何かで扱うコスト運用のディシプリンをCCoEの一機能として取り込み、タグ設計と配賦、削減のサイクルを回します。運用プロセスの側面で軸になるのが、ITSM（ITサービスマネジメント）とは何かの変更管理・インシデント管理との接続です。人材育成では、ハンズオン環境の提供や社内勉強会で、現場が自分でクラウドを扱える底上げを図ります。CCoEは全てを実行する部隊ではなく、これらの機能を束ねて水準をそろえるハブだと捉えると役割が整理できます。
SCPとタグポリシーでCCoEのガードレールを実装する手順とコード例
ここからは手を動かす話です。ガードレールは概念ではなくJSONとコマンドで、CCoEの成果物として残ります。承認外のリージョンでの構築を止める、という最初の一手で、書き方と適用の順番を示します。
承認リージョン外の操作を拒否するSCPのJSONと段階展開の手順
リージョン制限は、費用と法令対応の両面で効くうえ、影響範囲が読みやすいので最初のガードレールに向きます。aws:RequestedRegionの条件キーで、承認したリージョン以外のリクエストを拒否する仕組みです。グローバルサービスのエンドポイントはus-east-1に置かれているため、NotActionで除外しておかないと想定外の失敗を招きます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOutsideApprovedRegions",
"Effect": "Deny",
"NotAction": [
"iam:*",
"organizations:*",
"sts:*",
"route53:*",
"cloudfront:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-northeast-1",
"us-east-1"
]
}
}
}
]
}除外するサービスは組織ごとに変わります。足し引きする前に、AWS公式のSCP例と、そこから案内されるaws-samplesのポリシー集で、既にある型を流用できないか見ておきます。
AWS CLIでSCPを作成しOUへ適用するコマンドと検証の型
作成と適用は管理アカウントで行う作業です。ここで効くのは適用の順番で、公式ドキュメントは、影響を検証できる別の組織またはOUで試し、確認できてから狭いOU、広いOUへと段階的に広げるよう推奨しています。いきなり組織ルートに付けると、全アカウントを同時に壊せます。
# 1. ポリシーを作成する（管理アカウントで実行）
aws organizations create-policy \
--name deny-outside-approved-regions \
--type SERVICE_CONTROL_POLICY \
--description "承認リージョン外の操作を拒否する" \
--content file://scp-region-deny.json
# 2. まず検証用のOUだけに適用する
aws organizations attach-policy \
--policy-id p-examplepolicyid \
--target-id ou-exam-examplerootid
# 3. 適用先を一覧で確認してから上位OUへ広げる
aws organizations list-targets-for-policy \
--policy-id p-examplepolicyidタグの統制も同じ流儀で進めます。AWS Organizationsのタグポリシーは、CostCenterのようなタグキーの表記ゆれを禁じ、enforced_forで指定したリソースタイプには違反する付与操作そのものを止められます。準拠状況の確認先はAWS Resource Groupsです。タグ設計は費用の配賦と直結するため、立ち上げ初期にキーの一覧を確定させると後戻りが減ります。クラウド基盤の設計と統制の初期整備は、AWS・Google Cloud・Azureのインフラ構築として当社でも請け負っている領域です。
CCoEの3フェーズ：Advisory・Catalyst・Consolidationの手順
AWSの規範ガイダンスは、CCoEの成熟をAdvisory・Catalyst・Consolidationの3フェーズで整理し、AWS CAFのEnvision・Align・Launch・Scaleという4つの変革フェーズに対応づけます。組織の立ち位置は固定ではなく、支援の仕方を段階で変えていく点が特徴です。各フェーズで実装者が何をつくるのかを順に見ていきます。
Advisoryフェーズ・少人数で認識合わせと初期ガードレールを整える段階
最初のAdvisoryは、CAFのEnvision・Alignに対応し、少人数の中央チームが認識をそろえる段階です。公式ガイダンスは、この段階の仕事を、クラウド案件の先行導入者として価値を示し、初期の障害を取り除き、必要な人員・スキル・物的リソースを洗い出すことだと説明します。人員は5〜10名程度の小さな編成で始め、事業側の狙いと技術側の制約をすり合わせます。完璧な標準を机上で作り込むより、先行事例から学んだ最小限のガードレールを先に置き、使いながら育てる姿勢が向いた段階です。
Catalystフェーズ・移行を加速する推進役として実装を後押しする段階
次のCatalystは、CAFのLaunchに対応し、CCoEがクラウド移行の推進役になる段階です。整えたランディングゾーンとテンプレートを武器に、各部門のシステム移行やモダナイゼーションを技術面で後押しします。ここで陥りやすいのは、自分たちが全ての構築を代行してしまい、依頼が集中して滞ることです。目指すのは代行ではなく、現場が標準部品を使って自力で進められる状態づくりで、ハンズオンや設計レビューを通じて能力を移します。移行の実績が積み上がるほど、CCoEの立ち位置は先頭で引く役から後ろで支える役へ移ります。
Consolidationフェーズ・標準を整えセルフサービスで自走させる段階
最後のConsolidationは、CAFのScaleに対応します。公式ガイダンスの定義では、傘下の各実践が自力でクラウド案件を届けられるようになり、CCoEが軸足を移す先は、全社標準やベストプラクティスの策定、教育教材の整備といった支援側です。同じページには、クラウドセキュリティや機械学習のような専門性を育てるなら、新サービスや新機能の学習と実験に時間の20%以上を割り当てることを検討せよ、という配分も書かれています。この段階では、CCoEの成果は自分たちの作業量ではなく、現場がどれだけ自走できているかで測られます。
成熟度を測る物差しも公式に用意済みです。CCoEの行動原則はREALMSという6つの頭文字、すなわちResearch・Evangelize・Apply・Lead・Mentor・Scaleで整理され、それぞれにKPIの例が添えられています。原則は元々AWSパートナー向けの記述ですが、社内CCoEでも、新しい標準部品をいくつ出したか、勉強会を何回開いたか、伴走したPoCが何本かという形に置き換えれば使えます。
CCoEのオペレーティングモデル：中央集権型と連邦型の使い分け
ここからは独自の観点で踏み込みます。CCoEをどう機能させるかは、どこまでを中央が握るかというオペレーティングモデルの選択にかかっている領域です。組織の規模と成熟度で答えは変わり、固定の正解はありませんが、選び方の軸は言い切れます。
中央集権型・連邦型・自走型のオペレーティングモデルと段階的移行
モデルは大きく三つに分かれます。中央集権型は、CCoEが標準もガードレールも構築判断も一手に握る形で、統制は効きますが依頼が集中して速度を落としがちです。連邦型は、中央が最低限の共通ルールとガードレールだけを定め、各部門に権限を委ねる形で、速度は出ますが標準の遵守にばらつきが出ます。自走型は、標準がコードとして行き渡り、現場がセルフサービスで安全に使える成熟した状態です。
Microsoftのクラウド導入フレームワークは、この違いを交差点にたとえます。CCoEが無い状態のITは中央で責任を持つ信号機、機能したCCoEのもとでのITは責任を委譲して流す環状交差点だという対比です。同フレームワークはCCoEを5つの役割の協働、すなわちクラウド導入・クラウド戦略・クラウドガバナンス・クラウドプラットフォーム・クラウド自動化として定義します。立ち上げ初期は中央寄りで始め、ガードレールが固まるにつれて権限を現場へ移す段階的な移行が現実的です。最初から連邦型で権限を配ると統制が追いつかず、いつまでも中央集権のままだとCCoEが渋滞の原因になります。
CCoEが管理部門化・ボトルネック化する失敗パターンと回避策
CCoEが機能不全に陥る典型は、統制を効かせようとして逆に現場の足かせになることです。全ての環境構築や変更をCCoEの承認待ちにすると、現場はクラウドの速さを享受できず、規則を回避する野良アカウントが生まれます。既存のIT部門から中央の統制を手放してもらう交渉が要るため、Microsoftのフレームワークは発足から6〜9か月の間、事業側のステークホルダーがIT部門の責任者とCCoEに毎月会うことを勧めています。CCoEの価値は、止める力ではなく、安全な近道をどれだけ用意できたかで測るべきです。承認の行列ができ始めたら、その判断はガードレールへ落とせないかをまず疑います。
CCoE立ち上げの判断基準と、内製化を定着させる体制設計の勘所
CCoEは、専任チームを置いただけでも、フレームワークをなぞっただけでも回りません。組織の規模に合わない体制を敷けば負担が上回り、目的を見失えば規約を配るだけの部門に堕ちます。立ち上げと定着の判断基準を具体的に示します。
CCoEをスモールスタートで立ち上げる場面と過剰な組織化の回避
着手の優先順位は、痛みの大きい統制課題からです。複数部門がクラウドを使い始めてセキュリティ設定がばらつく、費用の全体像が追えない、といった具体的な困りごとが一つでもあるなら、まずその一点をガードレールとルールで押さえる小さなチームから始めます。逆に、クラウドを使うのが一部門だけで規模も小さい段階なら、専任のCCoEを組成するのは過剰です。組織や標準を先に作り込んでも、守るべき現場が育っておらず、運用の手間だけが増えて空回りします。まず一つの統制課題を解き切り、効果を確かめてから対象を広げる判断が堅実です。
CCoEが形骸化する三つのアンチパターンと現場での具体的な回避策
CCoEが空回りする典型は三つあります。第一に、ガイドライン先行。規約や標準文書だけを整え、現場が使えるコード化された部品を渡さず、読まれない資料が積み上がる状態です。回避策は、文書ではなく複製できる標準テンプレートとガードレールで渡すことに尽きます。第二に、承認ゲート化。あらゆる構築をCCoEの事前承認で止め、現場の速度を奪って野良利用を誘発する状態です。頻出の判断はガードレールへ落とし、例外だけを人が見る形へ寄せます。第三に、作りっぱなし。ランディングゾーンや標準を一度組んで満足し、新サービスの評価や更新を止めると、半年で実態とずれます。共通するのは、現場を安全に速くするという原点を見失っている点です。
受託開発と伴走でCCoEの内製化を定着させる体制づくりの設計
CCoEは、標準を組んで終わりではなく、現場が自走するまで育て切って初めて回ります。クラウド基盤を設計・監視できる人材がいない、部門ごとのアカウントが増え続けているのに統制の型がない、といった場面では、ガードレールの設計もランディングゾーンの構築も内製だけでは進みません。一創ではクラウド基盤の保守運用と内製化支援において、ガードレールと標準テンプレートの初期整備、運用体制づくり、自社チームがCCoEを自走できるまでの技術移転を支援します。CCoEの成否は、最終的に現場がどれだけ自立してクラウドを扱えるかで決まります。
よくある質問
CCoEの理解と立ち上げでつまずきやすい点を、5つの質問に絞って整理します。
CCoEとは何の略ですか？
CCoEはCloud Center of Excellenceの略で、日本語ではクラウド推進の専門組織などと訳されます。クラウドの導入と運用を全社横断で推し進め、共通のガバナンス・ガードレール・技術標準を整えて、各部門が安全に速くクラウドを使える状態をつくる横串のチームです。読み方は「シーシーオーイー」で、クラウドCoEとも呼ばれます。
CCoEとFinOpsはどう違いますか？
CCoEがクラウド利用全体の方針・ガバナンス・技術標準・人材までを担う傘であるのに対し、FinOpsはそのうち費用の側面に特化した運用ディシプリンです。FinOps Foundationが公開するFinOps Frameworkも、原則・ドメイン・ケイパビリティという形で費用運用に範囲を絞っています。多くの組織ではCCoEの一機能としてFinOpsが含まれ、CCoEが定めた枠組みの下でFinOpsが費用の可視化と削減を実行する、という重なりで捉えると整理できます。
CCoEは何人で立ち上げればよいですか？
小さく始めるのが定石で、5〜10名程度の少人数編成が一般的です。最初から大きな専任組織を組むより、事業側と技術側の要となる人員で発足し、クラウドの利用が広がるにつれて役割を足していきます。担当が数名でクラウドを使うのも一部門だけという段階では、専任チームの組成自体が過剰なため、既存の情報システム部門が兼務で統制を回すところから始めるのが現実的です。
CCoEにはどんなメンバーが必要ですか？
技術一辺倒では回りません。Microsoftのクラウド導入フレームワークは、クラウド導入・クラウド戦略・クラウドガバナンス・クラウドプラットフォーム・クラウド自動化という5つの役割の協働としてCCoEを定義します。AWS CAFの6視点と同じで、技術・事業・統制の視点をそろえる必要があります。不足する視点は段階的に補えばよく、全ての専門家を最初から集めなくてかまいません。
CCoEとDX推進室やPMOは何が違いますか？
DX推進室が事業のデジタル化全般を、PMOがプロジェクトの管理を担うのに対し、CCoEはクラウドの技術基盤とガバナンスに焦点を絞る組織です。ただしAWSの規範ガイダンスはPMOをCCoEのビジネス機能の一つに数えており、線引きは組織によって変わります。CCoEがガードレールや技術標準といった実装に踏み込む点は共通の特徴で、DX推進室の下にCCoEが置かれる構成もあります。
関連記事
- FinOpsとは：CCoEが内包するクラウドコスト管理のディシプリン
- ITSMとは：CCoEの統制と接続するIT運用管理の枠組み
- CMDBとは：クラウド資産を台帳化する構成管理データベース
- IaCとは：ガードレールと標準構成をコード化する手法
- クラウドネイティブとは：CCoEが推進するクラウド前提の構成
