この記事は CyberAgent Developers Advent Calendar 2025 の 18 日目の記事です。
1. はじめに
こんにちは、サービスリライビリティグループ(SRG)に所属している石川雲(@ishikawa_kumo)です。普段は Ameba Platformの運用・改善に関わりながら、プロダクト横断でのセキュリティと信頼性向上に取り組んでいます。
本記事では、Ameba Platformがこれまで取り組んできたことを振り返りつつ、以下についてまとめています。
- Ameba PlatformでのPlatform Engineeringをどのように捉え直したのか
- Ameba Platformの現在地をどう整理しているのか
- そしてこの先に向けて、どのような方向を目指しているのか
特定の技術やツールの紹介というよりは、プラットフォームを長期的なプロダクトとしてどう育てていくかという視点での整理が中心です。
同じようにプラットフォームや基盤を扱っている方、あるいはPlatform Engineeringという言葉に関心を持っている方にとって、何かしらの参考になれば幸いです。
2.これまでの振り返り(2019~2025)
まずは、Ameba Platformが生まれる前後の状況を簡単に振り返ります。
国民的人気のコンテンツサービス群であるAmebaでは、長い期間をかけてシステムと組織の規模が拡大してきました。プロダクトごとに最適化された設計や技術選定が積み重なった結果、全体としては複雑性の高い構造になっていました。
当時の課題は、単に「技術が古い」「自動化されていない」といったものではありません。サービスを開発・運用するために必要な前提知識や責任構造そのものが、組織の変化に追従しづらくなっていたことにありました。具体的には、次のような状況が見られました。
-
複雑なシステム構造により、サービスごとにドメイン知識のインプットコストが大きく、新しく担当したサービスの開発を始めるまでに多くのリードタイムが発生していた
-
組織変更や異動が頻繁に起こる中で、運用の責任範囲が不明瞭なサービスが生まれ、担当者不在のまま放置されるケースも見られた
-
チームごとに異なる技術スタックが選定され、開発者・運用者の認知負荷が継続的に増大していた
こうした背景から、共通の基盤として支える仕組みを整える必要性が明確になっていきました。その中で生まれたのが、Ameba Platformという発想です。
2022年の AWS Summit Onlineでは、Ameba Platformの技術責任者による発表が行われ、AWSを活用したシステム刷新の流れの中で、このプラットフォームがどのように生まれ、育ってきたのかが紹介されました。
Platformのコンセプト
Ameba Platformでは、開発者が基盤技術の詳細を強く意識せずにサービス開発に集中できることをコンセプトとして掲げました。
当時のAmebaの実行環境は、オンプレミスVM、オンプレミスKubernetes、各種クラウドサービスなどが混在しており、プロダクトごとに異なる前提の上で開発・運用が行われていました。Ameba Platformでは、環境の違いを意識せずに扱える共通の土台を目指しつつ、以下の要素を整備してきました。
- 利用ユーザがKubernetesに熟知する必要がない環境の提供
- 管理された統合CI/CDの提供
- 統一されたログフローの提供
- 監視サービスの一元化
- 基本的なセキュリティの担保
各段階の取り組み
これまでのAmeba Platformの歩みを振り返ると、大きく次の2つのフェーズに分けて捉えることができます。
1.2019〜2021年 概念検証と基盤構築を中心としたフェーズ
この期間は、Platformとしての方向性を定めながら、基盤そのものを作り上げることに注力したフェーズです。技術選定や運用モデルの検証を進めつつ、最低限の共通基盤を整えていきました。コンセプトの実現に向けて、当時の状況や制約を踏まえながら技術選定を行い、以下の要素を土台としてPlatformの基本形を構築しました。
- 利用ユーザがKubernetesに熟知する必要がない環境の提供:Cloud Native領域で注目を集めていたKubeVelaを採用し、サービスに必要となるKubernetes 上の各種リソース定義を一元的に管理する仕組みに統一しました。
- 管理された統合CI/CDの提供: 複数の社内プロジェクトで利用実績のあったGitHub ActionsとArgo CDを基盤として採用しました。
- 統一されたログフローの提供: 基盤となるEKSのエコシステムとAWSの各種サービスを活用し、S3を中心としたログの管理および利用フローを整備しました。
- 監視サービスの一元化: Datadogを採用し、モニタリング、ダッシュボード、インシデント対応などを開発・運用のさまざまな活動に組み込みました。
- 基本的なセキュリティの担保: プラットフォームチームは社内のセキュリティチームと連携し、基盤内におけるセキュリティ施策を継続的に実施してきました。
2.2022〜2025年 既存サービスの移設と改善を中心としたフェーズ
このフェーズでは、既存サービスのプラットフォームへの移設が本格化しました。プラットフォームチームは移設作業をサポートしながら、実際に移設してきたサービスの開発者から継続的にフィードバックを収集し、利用者全体の負担を減らすための改善を進めてきました。
この段階では、以下の観点に重点を置くようになり、Platformとしての成熟度を高めていく段階へと進んでいます。
- 基盤のオブザーバビリティ、セキュリティと信頼性向上
モニタリング強化、より効率的なインシデント対応体制などの整備、マルチテナント設計の実施、セキュリティ施策 - 基盤のスケーラビリティとパフォーマンスの向上
CI/CDの高速化、マニフェスト変更プロセスの簡素化 - 基盤全体のコスト最適化
より安価で管理しやすいログ管理の再設計、リソース使用とスケジューリングの最適化ソリューション導入
ここまで、Ameba Platformが生まれた背景と、2019年以降の取り組みを振り返ってきました。共通基盤の整備や既存サービスの移設を通じて、Ameba PlatformはAmebaのサービス群を支える基盤としての役割を着実に広げてきたと言えます。
3. Platform Engineeringという言葉と向き合う
2024年からPlatform Engineering MeetupやSRE NEXT、Platform Engineering Kaigiなどの場で、Ameba Platformの取り組みを紹介する機会が増えました。
その中で、「AmebaにおけるPlatform Engineeringの実践」という表現を使ってきました。説明としては分かりやすい一方で、この言葉を使い続けるほど、自分の中で一つの問いが明確になっていきました。
「いま自分たちが取り組んでいることは、本当にPlatform Engineeringと呼べるのだろうか？」
先日、松浦隼人さんから書籍翻訳レビューの誘いをいただきまして、初めて『Platform Engineering』（Camille Fournier・Ian Nowland 著／松浦 隼人 訳）を拝読しました。それまでPlatform Engineeringという言葉は、自分たちの取り組みを説明するための便利なラベルとして使っていた部分もありましたが、この本を読み進める中で、頭の中にあった違和感の輪郭が、少しずつはっきりしてきました。
書籍全体を通して一貫しているのは、次のような考え方です。
- プラットフォームの価値は、アプリケーションエンジニアの生産性向上と組織全体の重複作業の削減という形で現れる
- プラットフォームは、単なる共通基盤ではなく、利用者（開発者）を顧客とするプロダクトとして扱われるべきである
- Platform Engineeringでは、組織全体に対してレバレッジを生み出しているかどうかが重要である
プラットフォームのアーキテクチャ(非完全カプセル化とシッククライアントも含む)
ここで改めて、Ameba Platformの現状に目を向けてみます。
現在、Ameba Platform上で動いているサービス群は、実行基盤やCI/CD、監視・ログ・ランタイムといった技術スタックのレベルでは一定の統一性を持っています。その意味では、「共通のプラットフォーム上にある」と言えます。
一方で、機能の観点で見ると、それぞれのサービスは完全に独立しており、互いに無関係なテナントとして存在しているのも事実です。サービス間で再利用されるソフトウェア機能や、プラットフォーム側が主体的に提供する機能の抽象化については、プラットフォーム構築初期に共通の Go パッケージを提供したり、開発環境整備の一環として専用 CLI を作成したりしました。しかし、数年後にはメンテナンスが属人化し、機能の増強がままならない状況に陥っています。
現在のAmeba Platformが提供している価値は、安定したインフラ環境と、共通の開発・運用ツールに集約されています。これはこれまでの課題に対して非常に重要な価値でしたし、「開発者が基盤の違いを意識せずに開発できる」という目的に対しては、十分に意味のあるものでした。
しかし、書籍で語られているPlatform Engineeringは、このレイヤーにとどまらず、ソフトウェアとしての抽象化をプラットフォーム側が主体的に設計・提供し、複数のプロダクトラインに対してより高いレバレッジを生み出すことを前提としています。
この点を踏まえると、現在のAmeba Platformは「ソフトウェアレイヤーで高度な共通と抽象性を提供するプラットフォーム」というより、高度に整備されたインフラ共通基盤に近いのではないかと考える余地が出てきました。
この認識が、「いま自分たちが取り組んでいることは、本当にPlatform Engineeringと呼べるのだろうか」という問いにつながっています。
Ameba Platformのアーキテクチャ
目的を振り返って見えてきた違和感の正体
よく思い出してみると、Ameba Platformは、最初からPlatform Engineeringを目指して始まった取り組みではありません。
当初の目的は一貫して、開発者の認知負荷を下げ、すべてを理解しきらなくても、ビジネス価値の創出に集中できる状態を作ることにありました。インフラや運用、基盤の詳細を常に把握し続けなくても、必要なときに必要な形で使える土台を用意する。その結果として、開発者がすべての時間を「基盤を理解すること」に費やさなくても済む状態を作る。これが、Ameba Platformの出発点でした。この点で見ると、近年進めているAI活用の取り組みも、同じ方向を向いています。手段は異なりますが、価値創出に集中できる余白を生み出すという目的は共通しています。
現在のAmeba Platformの取り組みを整理すると、開発者ポータルの整備や抽象化の提供、共通基盤の構築など、「Platform Engineeringの文脈で語られる要素を多く含んでいる」のも事実です。定義を少し広げて捉えれば、「Ameba PlatformはPlatform Engineeringを実践している」と言っても、大きな違和感はありません。
ただし、重要なのは順序です。
Ameba Platformにおいては、目的を実現する過程でPlatform Engineeringの考え方や仕組みを取り入れてきたという位置づけになります。これまで感じていた違和感は、「やっていることが間違っている」から生じたものでも、「定義に合っていない」ことへの不安から生じたものでもありません。むしろ、手段として用いてきたPlatform Engineeringを、いつの間にか目的そのものとして捉えかけていた瞬間があったことに起因していたと私は考えています。
4.目的から見たAmeba Platformの現在地
Ameba Platformにおいては、Platform Engineeringは目的ではなく、開発者（アプリケーションエンジニア、そしてプラットフォームチーム自身）の認知負荷を下げ、ビジネス価値の創出に集中できる状態を作るための手段として位置づけ直しました。Platform Engineeringを名乗るかどうかにはもはやこだわらず、そこで語られている考え方やアンチパターンを参考にしながら、Ameba Platformの現在地をいくつかの観点から整理し、今後どのようなロードマップで進めていくべきかを考えていきます。
レバレッジの現在地
『Platform Engineering』では、レバレッジがPlatform Engineeringの価値の中核にあると述べられています。
(レバレッジ)これは、プラットフォームチームに所属する少数のエンジニアの仕事が、組織全体の業務を削減できるという考え方です。プラットフォームがレバレッジを実現する方法は2つあります。1つめは、アプリケーションエンジニアがビジネス価値を創出する際の生産性を向上させることです。2つめは、アプリケーションエンジニアリングチーム間で重複する作業を排除することで、エンジニアリング組織全体の効率を高めることです。
–『Platform Engineering』（Camille Fournier・Ian Nowland 著／松浦 隼人 訳）
この観点から見ると、Ameba Platformは一定の成果を上げてきました。実行基盤やCI/CDの共通化により、サービスごとの差異や初期セットアップの負担は確実に減っています。ログや監視の統一によって、運用時に必要な前提知識や判断ポイントも整理されました。また、これまで手作業で行われていた一部の作業をPlatform側に吸収し、自動化できるようになった点も無視できません。これらの意味で、Ameba Platformは利用者の生産性向上とサービス間の重複作業の削減という二つの軸で、一定のレバレッジを生み出してきたと言えます。
一方で、そのレバレッジが
- それはビジネス価値を創出する際の生産性向上なのか
-
その作業削減によってエンジニアリング組織全体の効率をどの程度高めたのか
といった点まで含めて、定量・定性の両面で説明できているかというと、まだ十分とは言えません。
「以前より便利になった」という実感はあるものの、明確な言葉と指標で示す段階には至っていないのが現状です。
プロダクトとしての現在地
「プロダクトとしてプラットフォームを考える」という言葉は、誤解されやすい表現です。私自身も過去、この点を誤解していました。
ここで言う「プロダクトとして考える」とは、Ameba Platformを一つのビジネスプロダクトとして扱うことを意味しません。Ameba Platformはプロダクトではありませんし、そう呼ばれるべきものでもありません。
重要なのは、プロダクトマインドセットを用いてプラットフォームを設計・運営することです。それは、課題を構造的に捉え、優先順位をつけ、アンチパターンに早く気づくための思考様式です。
この観点から現在地を振り返ると、Ameba Platformはまだ整理が十分とは言えません。
整理のために、自己QAしてみました。
- Q: プラットフォームチームは、その顧客(利用者)に共感し、顧客関心の焦点を当ててるのか
- A: 定期的に困っていることを聞き込んでいるけど、顧客の関心はバラバラで、焦点がわかりません
- Q: Platformのミッションを達成する手段は、市場調査(技術選定)はベストエフォートな見積もりを行ったのか
- A: 技術者の興味関心や流行から選定していたケースもありました
- Q: Platformは中長期的な視点を持ったロードマップを持っているのか
- A: これまではミッションを目的として、場当たり的な対応になっていました
一方で、できていたこともあります。
開発者からの要望に対し、その場しのぎの判断ではなく、Platform側が目指している管理性やコスト構造に照らして説明し、合意を得るという姿勢は一貫していました。
たとえば、AWS Lambdaを使いたいという要望に対しても、「これはLambdaだからやりたくない、Kubernetesじゃないから嫌だ」と単なる好みで却下するのではなく、「すでにコンテナ化されており、目的がコストであれば、EKS上のCronJobを改善したのでこちらを使ってほしい」といった形で、明示的な判断軸をもとに対話できていた点は、プロダクトマインドセットが機能していた例だと考えています。
これは「技術選定が厳しい」という単純な話ではなく、プロダクトとしての「管理しやすいようにする」という焦点と「コンピューティングリソースの管理を集約し、管理コストを下げる」という優先に行っているマイルストーンを、明示的に持てているからです。
複雑さと抽象化の現在地
抽象化を進める中で、複雑さは消えたというより、扱う場所が変わっただけではないかという感覚もあります。
OpenApplicationModel、KubernetesとTerraform、開発者ポータルと共通開発ツールを前提とした抽象化によって、開発者が直接向き合う複雑さは確実に減りました。その一方で、設定や運用判断、それらをつなぎ合わせる“グルー”は、プラットフォームチームの側に集約されてきています。
プラットフォームチームの人員変動によって、抽象化のスキルが失われたり、プラットフォームチーム内の認知負荷と負債が増加する一方です。まさに冒頭で述べた2019年Amebaの課題点の再来です。
2. これまでの振り返り (2019~2025)
具体的には、次のような状況が発生していました。
– 複雑なシステム構造により、サービスごとにドメイン知識のインプットコストが大きく、新しく担当したサービスの開発を始めるまでに多くのリードタイムが発生していた
– 組織変更や異動が頻繁に起こる中で、運用の責任範囲が不明瞭なサービスが生まれ、担当者不在のまま放置されるケースも見られた
– チームごとに異なる技術スタックが選定され、開発者・運用者の認知負荷が継続的に増大していた
現時点では、OSS導入の保守的視点(我慢できなくなるまで導入しない)でプラットフォームチームの限界を先延ばし、既存の複雑さはチームの中でできれば複数のメンバーに吸収・管理してもらっていますが、メンバーが力尽きるまでに何かしらの打開策を検討しなければなりません。
その他の観点
CNCFのPlatform Engineering Maturity Modelには、プラットフォームの成熟度をInvestment/Adoption/Interfaces/Operations/Measurementの5つの観点で捉える枠組みがあります。また、同コミュニティはこの5軸を多肢選択のアセスメントで自己診断し、カテゴリごとのスコアをスパイダーチャート等で可視化する仕組みも提供しています。Ameba Platformのスコアを開示します(いずれも低いです)。
-
Investment: 2.50
取り組みは継続できており、投資も一定水準で回っている一方で、「人の頑張り」に寄った局面（負債・グルーの集約）が残っている状態です。投資量そのものより、投資先の“持続可能性”への寄せ方が次の論点になりそうです。
-
Adoption: 1.75
利用は進んでいますが、まだ「自然に増える（プル型）」というより「移設・支援で増やしている（プッシュ型）」が中心になっています。テナント増加に耐える前提整備（運用設計・分離・標準化）を強めるほど、採用の伸び方が変わります。
-
Interfaces: 2.50
実行基盤・CI/CD・ログ・監視などの“使い方”は揃ってきており、一定の統一されたインターフェースを提供できている状態です。ただし、ソフトウェア機能としての抽象化は限定的です。
-
Operations: 2.25
日々の運用は回っていますが、チーム側の負担が増えやすい部分がボトルネックになっている状態です。
-
Measurement: 1.00
一番の弱点。価値（レバレッジ）も、改善活動そのものも、「説明できる指標」に落ちきっていない現在地がそのまま出ています。
5.Ameba Platformのこの先
ここまで振り返ってきたように、Ameba Platformはいくつかのフェーズを経て、いまの形にたどり着きました。では、この先はどこに向かうのか、今の時点で考えている方向性をまとめてみます。
ここで描くのは、完成したロードマップではありません。これから数年にわたって判断を重ねていくうえで、何を大事にして進むのかというスタンスに近いものです。
継続可能なPlatformを作るために、まず自分たちの負債と向き合う
前述通り、これまでのAmeba Platformは、開発者の認知負荷を下げることを優先するあまり、その負担をプラットフォームチーム側が引き受けてきた側面があります。結果として、設定や運用判断、グルーコードがプラットフォームチームに集まり、人の頑張りでバランスを保っている状態が続いてきました。
特に、Terraformをはじめとしたインフラ管理の領域では、運用が次第に辛くなってきているのも事実です。専門性が高く、変更の影響範囲が大きい一方で、すべての開発者が気軽に扱える状態とは言えません。このまま結合度が高まり続ける前に、何かしらの「革新的なソリューション」が必要だと感じています。Terraformを中心としたインフラ管理については、これ以上に密な結合が進む前に、構造そのものを見直す、あるいはより革新的な使い方へ移行することを検討したいと考えています。
同様に、KubeVelaを中心とするKubernetesマニフェスト管理の領域でも、小さな抽象化を実現するだけでも修正箇所が非常に多くなり、多大な工夫が必要になっています。ツール自体の見直しや、抽象化のやり方そのものを再考するタイミングに来ていると感じています。
AIを前提にした運用と、Platform の安定性の両立
もう一つ、今後避けて通れないテーマがAIの活用です。サイバーエージェントではすでに、多くの開発・運用の現場でAIを用いたコード開発や調査支援が当たり前になっています。さらに最近では、運用のためのAI Agentが一気に現実味を帯びてきました。
今後、AI Agentによってインフラ運用の自動化は進んでいくと思います。しかし、本番環境でAIを活用する上で、セキュリティと再利用性など考慮するべきことは沢山あります。Ameba Platformでは、攻めと守りの二つの軸でAIと向き合っていきたいと考えています。
守りの軸
仮にプラットフォームチームがAIを導入しなかったとしても、いずれPlatformの利用者がAIを使ってPlatformを操作する日は来ます。
そのときに備えて、
- AIによる操作を前提とした権限制御
- リソース操作の可視化と請求の正当性検証
- 人間ユーザとAI Agentユーザの明確な分離
といったガードレールの整備が不可欠です。
IaC関連では、Gitフローは一定の防波堤になりますが、Kubernetesの権限をAIに直接渡した場合に何が起きるかは、容易に想像できます。AI Agentの操作には人間の承認ステップを挟むなど、防御ラインを前提にした設計を進めていきたいと考えています。
Ameba Platformにおける対AI Agent防衛ライン
攻めの軸
一方で、プラットフォームチームの業務の中には、AIに任せたほうが安全で、かつ人間より得意な領域もあります。これまで試してきた中で見えてきたのは、
プラットフォームチームの仕事は、暗黙知や文脈理解が必要な判断や、複数課題が絡み合う設計といった点では人間が強い一方で、
- 大量のコードやマニフェストを丁寧にチェックする
- 特定領域（例:セキュリティ）に関する調査やメトリクスを継続的に追う
といった作業は、現在のチームメンバーが苦手でAIが得意な分野です。特に忙しいプラットフォームチームにとっては、補助的なAgentとしてAIを使うことで、人間が本来集中すべき設計や判断に時間を割けるようにしたいと考えています。
より多くのテナントを支えるための「サービスの多様性」を前提とした基盤へ
Ameba Platformは、インフラクラウド化・データセンター縮小の流れの中で、長年運営されてきたサービスを移設するための、事実上の最後の砦でもあります。今後も、さらに多くのサービスやチームがPlatformを利用することを想定しています。その中で目指したいのは、より高度な抽象化ではなく、より高度なサービスの多様性を受け入れられるプラットフォームです。
古く運営されているサービスの現代的な刷新から、異なる技術スタックや実行環境の違いを吸収し、Ameba Platformへの移設までを一貫して支援していきます。それと同時に、テナントが増えても破綻しない基盤を作り、スケーラビリティ・可用性・セキュリティ・コスト最適化といった基盤としての基本性能を着実に強化していきます。
モニタリングを原点としたPlatform改善
Platform活動の難しさの一つは、その価値が評価されにくいことにあります。便利になった、助かった、という声は集まるものの、それがどの程度の効果を生んでいるのかを明確に示すのは簡単ではありません。
この先に向けて重視したいのは、モニタリングを原点としたPlatform改善です。
- Platformの複数レイヤーを横断して利用状況を測るメトリクス
- 開発や運用にかかる手間を可視化するメトリクス
- トラブルや手戻りを正確に捉えるメトリクス
こうしたデータ(まだ幻想的ではありますが)を通じて、ユーザの利用状況と改善活動そのものをトレースできる状態を目指します。
6.さいごに
Ameba Platformは、すでに6年の時間をかけてここまで歩いてきました。
アプリケーションエンジニアリングの大部分とプラットフォームエンジニアリングの重要な違いの一つは、プラットフォームプロジェクトは多くの場合、大幅に長いタイムラインを持つ点です。
–『Platform Engineering』（Camille Fournier・Ian Nowland 著／松浦 隼人 訳）
Platform Engineeringの文脈でも語られているように、プラットフォームは短期間で完成するものではありません。これから先も、試行錯誤を重ねながら、継続できる形で少しずつ前に進むことを大切にしたいと考えています。
Ameba Platformは、この先に向けて、Amebaのサービス群を支える持続可能な基盤を作り続けていきます。その過程では、開発者プラットフォームとしていくつかの大きな判断を迫られる場面が出てくるはずです。
たとえば、特定のクラウドに前提を置き続けるのか、すでに別のクラウドで運用されているサービスをどのように受け止めていくのか。あるいは、Kubernetesを中心に据え続けるのか、最初からKubernetesに適さないサービスとどのような距離感で向き合っていくのか。単一の技術に寄せきるのではなく、サービスごとの前提や制約を受け入れながら支えていくことも、プラットフォームを作る側の重要な役割だと考えています。
Ameba Platformは、これからの6年も、Amebaの開発者とサービス群にとって信頼される、長く使われる、愛されるプラットフォームであり続けることを目指します。