数日かかったゲーム監視を、わずか数秒で：CTWがGrafana Cloudで実現したフルスタック・オブザーバビリティ

Lea Nagashima

•

2026-06-30•1 min

Grafana Cloudを導入した今では、G123プラットフォーム上で新しいゲームがリリースされる際、その安定稼働を担うエンジニアたちが監視環境をゼロから構築することはありません。ログパイプラインを繋ぎ込んだり、ダッシュボードを立ち上げたり、アラート機能を一つずつ手作業で設定したりする必要はないのです。ボタンをワンクリックするだけで、データソース、フォルダ、ダッシュボード、アラート機能を含むオブザーバビリティスタックのすべてがわずか数秒で自動生成されます。少し前まで、これと同じ作業に何日もかかっていました。

CTW株式会社は、日本の人気アニメIPを活用した世界最大級のHTML5ブラウザゲームプラットフォーム「G123」を運営しています。プレイヤーはアプリをダウンロードやインストールをすることなく、40以上の魅力的なタイトルにいつでもすぐにアクセスできます。サービス開始以来、プラットフォームの累計ユーザー数は約10億人に達し、課金プレイヤーは世界191カ国に広がっています。この巨大なサービスを支えているのは、東京と上海、そして新たに開設されたニューヨークオフィスに分散する、わずか10人ほどの少数精鋭のインフラ・クラウドチームです。彼らは、基盤となるマルチクラウドインフラから、パートナーの開発スタジオがゲームをデプロイするために使用するPaaS（Platform-as-a-Service）レイヤーまで、あらゆる領域の管理を一手に引き受けています。

この「ワンクリックでの立ち上げ」は、より大きな変革の入り口にすぎませんでした。Datadog、セルフホストされたElasticsearch-Logstash-Kibana（ELK）スタック、そして3つのクラウドコンソールの「パッチワーク」を、Grafana Cloudへ一本化し、単一の集約されたオブザーバビリティプラットフォームとして運用を始めたことは、単なるツールの統合以上の効果をもたらしました。それはCTWの働き方を根本から刷新し、エンジニアがオブザーバビリティの価値を自社の壁を越えて外部へと拡張する原動力となったのです。かつては一握りのSREだけが手作業で担っていた運用は、現在では84人のエンジニアが毎日利用する共通の仕組みへと進化しました。さらにCTWは、この仕組みをプラットフォーム上で開発を行う何十ものゲームスタジオへ直接提供しています。そのスタジオの多くは、それまで本格的なオブザーバビリティを運用した経験がありませんでした。

「私たちの目標は、安全で拡張性の高いクラウドサービスを提供することです」と同社のインフラ責任者であるYin Yannan氏は語ります。「Grafana Cloudが導入されたことで、まさに今、それを高い次元で実現できています。」

5つのツールやコンソールに分断されていた「かつての状態」

当初、CTWのオブザーバビリティ環境はバラバラに分散していました。Datadogは主にプラットフォーム自体の内製サービス向けにメトリクスやAPM（アプリケーションパフォーマンスモニタリング）を処理していました。一方で、ログの管理にはセルフマネージドなELKスタックを使用していました。当時、CTWが抱える膨大なログボリュームを商用のSaaSツールにそのまま転送することは、コスト面から現実的ではなかったためです。さらに、メトリクスやシステムのステータス確認は、AWS、Alibaba Cloud、GCPの各管理コンソールに依存していました。3つのクラウドにまたがるインフラを運用していたため、何か障害の調査を行う際には、5つの異なる場所をすべてチェックし、そのうちのどこかに答えがあることを祈るような状態だったのです。

この環境の乱立は、2つの深刻な問題を引き起こしていました。1つ目は、コストと運用負荷です。ELKを社内で自社運用するということは、ストレージの管理、スケール対応、アップデート、パフォーマンスチューニング、そして信頼性の担保にいたるすべての作業をチーム自身が抱え込むことを意味していました。これは、Infrastructure as Code（IaC）による少数精鋭のインフラ運用に誇りを持っていたチームにとって、非常に重い負担でした。「ログボリュームが拡大するにつれ、システム全体のメンテナンスを自分たちで行わなければなりませんでした。」とYin Yannan氏は振り返ります。「ELKスタックの維持には、本当に多くのエネルギーを消費していました。」

2つ目は、監視の網羅性の課題です。多くのゲームは仮想マシン（VM）型のデプロイ形式で稼働しており、ログはそれぞれのゲームサーバー内にローカル保存されたまま、CTW側へ転送されていませんでした。「ゲーム側にログがあっても、私たちはそこで何が起きているのか全容を把握できなかったのです。」とYin Yannan氏は当時を振り返ります。何か不具合が発生した際、チームは確認できる限りのメトリクスを監視し、スクリーンショットを撮影して、チャットや運用報告書を通じて手作業でゲームスタジオに共有していました。また、コストの急増を抑えるためにデータを間引きせざるを得ないこともあり、結果として「本当にシステムの中身を見たい瞬間」に盲目になってしまうリスクを抱えていました。「時には、プラットフォーム側はゲーム側の問題だと考え、ゲームスタジオ側はプラットフォーム側の不具合だと考えるような、責任の擦り合いが起きることもありました。非常に混沌としており、お世辞にも効率的とは言えませんでした。」

1つのオープンプラットフォームへの統合

CTWは、自社システムを統合的に可視化する場所として、すでに2022年11月にGrafana Cloudを採用していましたが、そこからさらに監視環境を完全に一元化することを決断した背景には、いくつかの明確な理由がありました。

第1にコストパフォーマンスです。CTWが扱うような大規模なデータボリュームにおいて、Grafana Cloudは他社製品と比較してはるかに合理的な価格設定でした。第2に、CTWのエコシステム内にいる多くのエンジニアが、日常業務でダッシュボード機能を頻繁に使用していたため、すでにGrafanaに対する基礎知識や親しみを持っていた点です。そして最後に、モニタリング能力の大幅な拡張性です。チームはブラウザ側で動作するゲームクライアントの挙動を追跡し、より深いアプリケーションレベルのインサイトを得る必要性を感じていたため、Frontend Observabilityと分散トレース（Distributed tracing）の導入に踏み切りました。

現在、CTWはELKスタックとDatadogの双方からの移行を完了しています。

日々の業務において最もインパクトのあった変化は、CTW最大の課題を直接解消したGrafana Cloud Logsの導入でした。セルフマネージドなELKスタックは、少数のSREがストレージ、スケーリング、アップデート、信頼性管理に追われる一方で、重要なログの監視漏れを生み出すなど、少数精鋭のチームにとって大きな運用上の重荷となっていました。ELKをGrafana Cloud Logsに置き換えたことで、CTWはKubernetes、仮想マシン（VM）、パブリッククラウドを含むすべてのログソースを、フルマネージドな単一のプラットフォームへ集約。導入初日から、インシデント発生時のトラブルシューティングを劇的に高速化させました。

この新しいロギングプラットフォームの構築と並行して、CTWはメトリクス監視をDatadogからGrafana Cloud Metricsへと移行し、さらにGrafana Cloud Tracesを通じて、念願だった分散トレース環境をチームへ提供することに成功しました。極めて重要なポイントとして、VMサーバー上にGrafana Alloyエージェントをデプロイしたことで、かつては各サーバー内に孤立して埋もれていたゲーム側のテレメトリをリアルタイムに収集できるようになりました。

この統合は、単にデータを1つにまとめただけでなく、チームの働き方そのものをシンプルにしました。「最大の変化は、私たちのワークスタイルそのものです」とYin Yannan氏は強調します。「以前はログもメトリクスもあらゆる場所に散らばっていましたが、今は統合されたプラットフォームがあります。私たちの仕事の進め方は完全に変わりました」 5つの場所を確認していた手間は、全員で共有する1つの画面へと変わり、かつてのような管理コンソール間を駆け回るスクランブル対応は、予測可能で洗練された単一のワークフローへと生まれ変わったのです。

しかし、CTWとGrafana Labsとの絆が深まった理由は、Grafana Cloudがもたらした技術的な成果だけにとどまりません。

Yin Yannan氏にとって、企業同士のパートナーシップとしての関係性も同じくらい重要でした。「Grafana Labsは、ビジネスパートナーというよりも、まるで『古くからの友人』のようです。」と彼は言います。「私たちはGrafanaの担当者と率直に話し合い、一緒に課題を解決しています。自分たちのプロダクトを心から愛している人たちと仕事ができるのは、本当に素晴らしいことです。」また、Grafanaが掲げるオープンソースの哲学は、CTW自身のアイデンティティとも深く共鳴しています。「私たちは、さまざまなゲームスタジオを相手にするプラットフォームです。それはまるでチョコレートの箱を開けるようなもので、次にどんな形のスタジオやゲームがやってくるかは誰にも分かりません。だからこそ、私たちは常に新しいものを受け入れ、変化に対して非常にオープンでありたいと考えています。」

Yin Yannan氏は、この強固な関係性を次のように説明します。

「私たちはオープンなカルチャーを愛しています。Grafanaが提供するオープンでエージェント型オブザーバビリティプラットフォームと、オープンで親身なGrafanaチームとの協力を通じて、まさに私たちが求めていた理想の環境を手に入れることができたのです。」

ワンクリックでプロビジョニングされる「Observability as Code」

日々の業務成果を劇的に変えたのは、オブザーバビリティをコードとして扱う「Observability as Code」の実践でした。CTWのSREチームは、監視のベストプラクティスや可視化の基準を再利用可能なテンプレートとしてコード化し、開発スタジオがゲームのデプロイや運用に利用する社内PaaS「Publisher」へ組み込みました。Grafana Cloud APIを連携させたことで、オブザーバビリティのプロビジョニングは、開発ワークフローにおける自動化された標準ステップの1つとなったのです。「すべてがワンクリックでセットアップされます」とYin Yannan氏は言います。「データベース、サーバー、CDNにいたるまで、Grafanaの環境一式がすべて揃うのです」ゲームのリリースやクローズ（運用終了）に合わせて、フルスタックのオブザーバビリティ環境が自動的に生成・破棄されるため、かつてチームが手作業で行っていた、エラーの起きやすい手動運用の苦労は完全に解消されました。これこそが、CTWが1ゲームあたりの構築時間を「数日から数秒へ」と短縮できた本質的な理由です。

マルチテナント（データの分離）は、フロントエンドではなくサーバー側で厳格に制御されています。ゲームごとに個別の読み取りトークンが発行され、Grafana Cloudのアクセスポリシーによって、すべてのクエリが該当するゲームのラベルだけにスコープ制限されます。これにより、各開発スタジオは自社のデータしか閲覧できない仕組みになっています。ゲームごとのデータソース分割、フォルダレベルの権限管理、そしてCTW内部の組織・アイデンティティ管理システム（ID基盤）との連携によって強固な隔離環境が補完されており、外部の業務委託メンバーがプロジェクトを離れた際にも、アクセス権限は自動的に削除されます。

この投資の成果が最も顕著に現れるのが、インシデント発生時です。かつては散らばった複数のシステムからスクリーンショットを集めていたチームが、今では全員で1つの画面（ダッシュボード）を共有して調査を進めています。「プラットフォーム側としては、根本原因の特定が劇的に早くなり、わずか数分で完了するようになりました」とYin Yannan氏は語ります。そのメリットは開発スタジオ側にも及んでいます。以前は原因分析のためにログファイルを自分のノートPCにわざわざダウンロードしていたパートナー企業のエンジニアたちが、今ではリアルタイムのダッシュボードを直接確認できるようになりました。「彼らは今、当たり前のようにGrafanaを使っています。彼らの働き方は完全に変わりました」とYin Yannan氏は話します。

コスト急増を、管理可能な運用へ

新しいゲームが登場するたびにテレメトリが掛け算で増えていくプラットフォームにおいて、コスト規律の維持は必要不可欠です。CTW側から各スタジオが生成するログやメトリクスの量を強制的に制限することはできないため、利用量は一晩で2倍、3倍、あるいは4倍へと急増するリスクを常に孕んでいます。利用料をコントロールするために、CTWはAdaptive MetricsやAdaptive Logsの機能を活用しています。実際に使われているデータを分析し、不要なデータは間引きやサンプリング処理を行う一方で、エラーレベルの重要なログは確実に維持する運用を徹底しています。

2026年5月、CTWはAdaptive Metricsの活用と、データ送信元における大規模なコレクションのクリーンアップを組み合わせ、システムの可視性を一切損なうことなく、アクティブなメトリクスのシリーズを約40%削減することに成功しました。この運用上のゆとりが生まれたことで、単にコストを削減するだけでなく、新たな技術投資へリソースを再配分できるようになりました。チームは現在、エージェント群の拡大に伴い、Grafana Alloyエージェントを一元的にオーケストレーションするためのFleet Managementのパイロット運用を進めているほか、開発スタジオとのコミュニケーションの質も向上させています。

「スタジオの中には、自分たちが何を送信しているのかすら把握しておらず、ただ『念のためすべてのデータを取っておきたい』と考えているところもあります」とYin Yannan氏は言います。「今では、彼らにとって本当に必要なデータが何であるかを、私たちがデータに基づいて明確に提示できるようになりました。」

すべての開発スタジオに「Observability as a Service」を提供

何十もの開発スタジオをホストするプラットフォームにおいて、最大のビジネスチャンスは、オブザーバビリティを「スイッチをONにするだけで使える標準機能」にすることです。CTWは現在、Frontend Observabilityを含む高度な監視機能を、設定済みのワンクリックオプションとして社内PaaS「Publisher」内で提供しています。開発スタジオはダッシュボード上でオプトインするだけで、すぐにテレメトリの収集を開始できます。

このアプローチは非常に重要です。なぜなら、ほとんどのゲームエンジニアはオブザーバビリティの専門家ではないからです。「ゲーム開発において、フロントエンドのオブザーバビリティは十分に重視されていない傾向があります。」とYin Yannan氏は指摘します。「スタジオの一部のエンジニアは、ユーザーのブラウザ側で実際に何が起きているのかを正確に把握できていないのが実態です。」

そのためCTWの計画は、未加工のデータをそのまま渡すのではなく、明確な「答え」を提供することです。フロントエンドのシグナルを処理し、解釈が必要なダッシュボードをもう1つ増やす代わりに、結論や「具体的にどこに対処すべきか」を表面化させます。これは、これまでオブザーバビリティを意識したことのなかったチームに対する「監視の民主化」です。かつてノートPC上でログファイルと格闘していたスタジオが、自社にオブザーバビリティ専門のエンジニアを抱えることなく、すぐに実戦で使える高度なインサイト（知見）を得られる環境が整いつつあります。

CTWにとって、これは強力なビジネス上の競争優位性優位性もあります。

オブザーバビリティは、今やプラットフォームの大きなセールスポイントとなっているのです。「私たちのプラットフォームにゲームをデプロイすれば、専任のSREチームも、DevOpsチームも必要ありません」とYin Yannan氏は結びます。「必要な環境は、私たちがすべて提供します。」ローカライズ、プロモーション、ホスティングに加え、技術サポートとフルスタックのオブザーバビリティ環境を「付加価値」としてパッケージ提供することで、CTWはゲームスタジオとのパートナーシップをさらに深め、開発スタジオが「自分たちで構築すべきシステム」をまた1つ減らすことに成功しています。

次なる展望：AIによるフィードバックループの確立

CTWが今後1年で最も注力するのはAIの活用、特にオブザーバビリティをソフトウェアライフサイクルのあらゆるフェーズとシームレスに紐づけることです。同社のエンジニアは、すでにClaude CodeやCursorといったAIコーディングツールを日常的に業務へ取り入れており、Grafana AssistantやGrafana MCPサーバーの導入によってその開発スタイルは劇的な変化を遂げています。「私たちはMCPサーバーを自社のAIエージェントに組み込んでいますが、文字通り何でも、本当にあらゆることをこなしてくれます」とYin Yannan氏は言います。「ログやメトリクスの分析はもちろん、ソースコードの中身まで踏み込んで、不具合の原因と思われる箇所を修正することまで行ってくれるのです。」

チームが目指しているゴールは、AIが人間の調査を単に「手助けする」レベルから、エンジニアが結果をレビューして承認するだけで、AIが「調査・診断・修復（自動復旧）」にいたるサイクル全体を自律的に回す世界へとシフトすることです。

Yin Yannan氏の視点では、これが実現可能なのは、後から無理やり継ぎ足したようなアシスタントではなく、ベースにあるオープンな設計思想（openness）のおかげです。彼は、他のツールのAIが直面しがちな「限界」をGrafana Assistantが軽々と超え、圧倒的に高精度である点を高く評価しています。一般的なツールでは、ログやメトリクスの分析まではできても、そこで処理がストップしてしまいます。「それらのAIは、私たちのソースコードにアクセスできないからです」とYin Yannan氏は指摘します。「だからこそ、このMCPサーバーこそが、サイクルを完全に完結させる最後のピースだったのです」 Grafana MCPサーバーを導入したことで、CTWは自分たちが選んだ任意のAIモデル（LLM）やAIエージェントを、オブザーバビリティデータとソースコードの双方に直接接続できるようになりました。結果として、ダッシュボードとコーディングツールを行ったり来たりすることなく、システムに現れた「予兆・症状」から「根本原因の特定」、そして「修正コードの提案」にいたる一連の調査ワークフローをシームレスに完結させています。

この圧倒的な透明性と柔軟性こそが、チームが最も重視しているポイントです。CTWのチームは、最も精度の高い回答が得られる場面ではGrafana Assistantを頼り、それ以外の場面では自分たちが好む任意のAIモデルにMCPサーバーを繋ぎ込むなど、特定のベンダーのAIにロックインされることなく、主導権を自分たちで握ることができます。「次に参入してくる開発スタジオがどんな技術スタックを持ち込んできてもすべて吸収する」というビジネスを営むプラットフォームにとって、開発ツールの選択肢だけでなく、利用するAIの選択肢にまで柔軟に寄り添ってくれるオブザーバビリティレイヤーは、まさにこれ以上ない自然な選択だったのです。

Grafana Cloud導入前

監視の分断: 5つのツールが乱立し、根本原因の特定が困難かつ断片化。
高い運用負荷: 自社運用ELKスタックの維持管理に多大なリソースを浪費。
可視性の欠如: ゲームサーバー上のログが未収集で、全体像が不明瞭。
構築の遅延: 手作業による監視環境構築に数日を要していた。
データ制限: コスト抑制のためデータを間引き、可視性が低下。

Grafana Cloud導入後

迅速な原因究明: 単一プラットフォームへの統合により、迅速な原因究明を実現。
運用の効率化: 保守作業に費やす時間が削減され、本来の開発業務へ注力。
フルスタック可視化: Grafana Alloy活用により、全環境のテレメトリ収集を実現。
即時プロビジョニング: ワンクリックで監視環境を数秒で自動構築。
コスト最適化: 可視性を維持しつつ、アクティブなメトリクスを約40%削減。