初心者向けに体感型のクラウドを使うゲームを考えてみた②（Google Cloud版）

この記事の位置づけ

これは「初心者向けに体感型のクラウドを使うゲームを考えてみた①（Google Cloud版）」の続編です。前編では、アカウント配布や課題カタログ、自動採点の基本構成について解説しました。
この後編では、参加者の体験を向上させるためのUI/UXの工夫と、安全なイベント運営に不可欠な環境分離のアーキテク- テクチャに焦点を当てます。

1. 設問の見せ方の工夫：没入感を高めるノベルゲーム風UI

前編で紹介した課題は、クラウドコンソールと向き合う実践的なものでした。しかし、特に初心者向けイベントでは、参加者を惹きつけ、物語に没入してもらうための「ガワ（UI）」も重要です。

そこで、設問自体をノベルゲーム風に提示するアイデアを検討します。
例えば、登場人物（先輩エンジニアやオペレーター猫）から「困っているんだ、この設定を見てくれないか？」とチャットで話しかけられるように依頼が飛んでくる形式です。これにより、参加者は単なる作業者ではなく、物語の主人公として課題に取り組むことができ、エンゲージメントの向上が期待できます。

このUIは、Cloud Storageの静的ウェブサイトホスティング機能を使って、サーバーレスかつ低コストに実現できます。

2. 静的ホスティングによるゲーム画面の実現方法

Cloud Storageの静的ホスティングは、HTML/CSS/JavaScriptで構成されたファイルを配信する機能です。サーバーレスで運用が簡単なため、ゲームのフロントエンド基盤として最適です。
実装方法は、開発の手間や求めるカスタマイズ性に応じていくつかの選択肢があります。

実装方法の比較

方法	メリット	デメリット	こんな場合に最適
ゲームエンジン/ライブラリ	- プログラミング不要 - シナリオ制作に集中できる - 豊富な機能（セーブ/ロード等）	- 表現の自由度がツールに依存 - 細かいUIの作り込みは苦手	最速でリッチなノベルゲームUIを実装したい場合
モダンフロントエンドFW	- UIの自由度が非常に高い - React等のエコシステムを活用可能 - 高度な状態管理や演出も実装可	- JavaScript/フレームワークの知識が必要 - 開発工数がかかる	UIにこだわりたい、独自のゲームシステムを組み込みたい場合
素のJS/HTML/CSS	- 依存関係がなくシンプル - 仕組みを理解しながら作れる	- 機能が増えるとコードが複雑化 - 車輪の再発明になりがち	ごく単純な紙芝居形式で良い、学習目的で実装したい場合

具体的なツールと参考URL

選択肢1：ゲームエンジン/ライブラリを利用する（推奨）

プログラミングの手間を最小限に抑え、シナリオや演出に集中したい場合に最適な方法です。

ティラノビルダー: https://tyranobuilder.com/
- GUIを操作するだけでノベルゲームを制作できる非常に強力なツールです。キャラクターの配置、セリフ、シナリオ分岐などを直感的に作成できます。
- 完成したゲームは**「HTML5形式」で書き出す**ことができ、生成されたファイル一式をそのままCloud Storageにアップロードするだけで公開が完了します。
- 公開手順の参考: ティラノビルダー作品をブラウザで簡単公開！ (サーバーへのアップロード部分をGCSに読み替えてください)

選択肢2：モダンなフロントエンドフレームワークを利用する

より柔軟なカスタマイズやモダンな開発体験を求めるなら、Next.jsのようなフレームワークを利用するのも良い選択です。

Next.js (Reactフレームワーク): https://nextjs.org/
- Next.jsの**静的エクスポート (output: 'export')**機能を使えば、アプリケーション全体を完全に静的なHTML/CSS/JSファイル群としてビルドできます。
- ビルド後に生成される out ディレクトリの中身をCloud Storageにアップロードするだけで、Reactで構築した高機能なUIを静的サイトとして配信できます。
- 静的エクスポートの参考: Next.jsの静的エクスポートで完全に静的なサイトをデプロイする

9. 安全なゲーム画面へのアクセス制御

ゲーム画面は参加者だけに限定公開し、Cloud Storageバケット自体は非公開に保つのがセキュリティの基本です。VPNやCloud Interconnectのような専用線を使わずにこれを実現する方法は、いくつか優れた選択肢があります。

アクセス制御方法の比較

方法	キーワード	メリット	デメリット	こんな場合に最適
Identity-Aware Proxy (IAP)	Googleアカウント認証	- 最も安全かつ管理が容易 - Googleの堅牢な認証基盤 - VPN不要でどこからでもアクセス可	- 参加者はGoogleアカウント必須 - 外部HTTPS LBの費用がかかる	参加者をGoogleアカウントで管理できる場合（イチオシ）
Cloud CDN 署名付きCookie	ログイン処理を自作	- 認証方法を自由に設計可能 - Googleアカウントに依存しない	- ログインアプリの別途開発が必要 - 構成がやや複雑になる	独自のアカウント基盤で認証させたい場合
Cloud Armor IPアドレス制限	IPアドレスで制限	- 設定がシンプルで分かりやすい - 意図しないNWからのアクセスを遮断	- 参加者のIPアドレスが固定である必要 - 動的IPの参加者には不向き	オフィスや学校など、特定の固定IPからのみ参加する場合

推奨アーキテクチャ：Identity-Aware Proxy (IAP) の活用

バランスが良さそうなIAPを利用した構成図は以下の通りです。

ポイント:
1. 参加者はロードバランサの公開IPにアクセスします。
2. IAPがリクエストを遮断し、Googleアカウントでのログインを要求します。
3. IAMでアクセスを許可されたアカウントであれば、リクエストがバックエンドの非公開GCSバケットに転送されます。バケット自体はインターネットに一切公開されません。
費用:
- IAP自体の利用は無料です。
- 主なコストは外部HTTPSロードバランサの利用料（転送ルールとデータ転送量）となり、小規模イベントであれば月額数ドル〜十数ドル程度に収まる見込みです。
公式ドキュメント: バックエンドにCloud Storageを指定してIAPを有効にする

10. ゲーム運営環境とチャレンジ環境の分離

課題として「参加者にロードバランサを操作させる」といった設問を用意する場合、ゲーム画面を配信しているロードバランサを直接触らせるのは非常に危険です。誤操作でゲーム全体が停止してしまうリスクがあります。

この対策として、環境を明確に分離することが不可欠です。

推奨構成：プロジェクトレベルでの分離

最も安全な方法は、Google Cloudのプロジェクト自体を分離することです。

運営用プロジェクト:
- ゲームのフロントエンド（GCS）、採点システム（Cloud Run）、スコアボードなど、絶対に触られたくないコアコンポーネントを配置します。
- 参加者には、このプロジェクトへのIAM権限を一切付与しないか、限定的な閲覧権限のみを与えます。
チャレンジ用プロジェクト:
- 参加者が実際に操作するリソース（VM, LB, Cloud SQL, FWルールなど）をすべてこちらに配置します。
- IAM権限は、このプロジェクトに対してのみ付与します。これにより、万が一意図しない操作が発生しても、影響範囲をチャレンジ用プロジェクト内に完全に封じ込めることができます。

この「環境分離」の考え方は、CTF運営だけでなく実務においても非常に重要なセキュリティプラクティスです。

まとめ

今回は、イベントの体験を向上させるUI/UXのアイデアと、それを支える安全なアーキテクチャについて考えてみました。

UI/UX: Cloud Storageの静的ホスティングを使い、ノベルゲーム風UIで参加者の没入感を高める。
アクセス制御: IAPを活用し、バケットを非公開に保ったまま安全に参加者を認証する。
環境分離: 運営用とチャレンジ用のプロジェクトを分離し、参加者の操作範囲を明確に限定することで、安全なイベント運営を実現する。