ドワンゴ Advent Calendar 2025

自作マルチプレイゲームを Web サービスとして公開する

Last updated at 2025-12-01Posted at 2025-12-01

概要

ドワンゴ Advent Calendar 2025 2日目の記事です。
自作マルチプレイゲームを独自の Web サービスとして公開し、誰でも遊べるようにします。

周辺技術をご存知の方向けにお伝えしてしまうと、Node.js + Express サーバ構成の akashic serve で動かすマルチプレイゲームを、さくらの VPS で配信する、というものです。

マルチプレイゲームは、ネットワーク上に構築したプレイ空間を複数のプレイヤーが共有することで実現できます。実現できるのですが、Steam や Unity のマルチプレイプラットフォームを利用してもなお実現には敷居が高く、自作ゲームクリエイターにとっては手を出しづらいのが実情です。¹

ここでは、マルチプレイ機能が強力なゲームエンジン Akashic Engine のコンテンツを、同梱のマルチプレイデバッグツール akashic serve を流用しつつ「ちょっとコーヒー10杯入れるか」程度の労力とコストで Web 上でマルチプレイを遊ばせる方法を紹介します。

実際のところ、本記事はこちらの発表に端を発するものであり、影響を受けるマルチプレイゲーム作者の方へ向けて、せめてご自身で作られたゲームを公開するための一助となればと作成したものです。

この文書は、筆者個人の「自作ゲームクリエイターを応援したい意図」で執筆したものであり、筆者が所属する企業、組織、サービスに関する意向を代表するものではありません。

本記事で扱う範囲

要素	定義	例	実現手段	本記事の実装
マルチプレイゲーム	「複数人が同じ空間やリソースを共有して遊べる」ゲームのこと。	ニコ生ゲーム	ゲーム制作	Akashic Engine
マルチプレイゲームの Web サービス	「ブラウザを使ってスマホや PC で遊べるマルチプレイゲーム」を提供するサービスのこと。	ニコニコ生放送の放送ネタ	Web アプリケーション開発	Akashic Engine の akashic serve ツール
			Web 配信インフラ構築・契約	さくら VPS

対象読者

本記事は以下に示す方の一助となるよう作成しました。

自作ゲームクリエイターの方
ニコ生ゲーム投稿者の方
ニコ生ゲーム界隈で、 ニコニコ生放送の外でもマルチプレイゲームを遊びたい！　Web サービスだって自作してやらぁ！ という方
ゲームは作れるけど、「Web サービスとか公開とか何？」という方
指先がチリチリする方
口の中がカラカラな方
北斗七星には一つだけ「添え星」があるように、天と地いずれかの空席を埋める「運命」を持つ者。

記事の内容では、Linux で基本的なコマンドライン操作が使えることを前提としています。

1. 事前準備

マルチプレイゲームを用意する

ここでは Akashic Engine 製のマルチプレイゲームを用意します。

Akashic Engine は JavaScript/TypeScript で記述できるオープンなマルチプレイゲームエンジンです。ニコ生ゲームのプラットフォームでもあり、複雑なプログラミングをせずにランキングゲームやマルチプレイゲームが実現できる特徴があります。

自作のマルチプレイゲームはないが動かしてみたいという方は、この記事で使うゲームのリポジトリも用意しています。内容は公式のマルチプレイゲームテンプレートで生成したものと同等のものです。よろしければご利用ください。

また、公式のニコ生ゲームサンプルとして「ニコニコスネーク」があります。動作環境はニコニコ生放送を想定しており、放送者による募集、プレイヤー名の入力などの要素を持ちます。完成度が高いゲームなのでおすすめです。

さくらの VPS を使えるようにする

ここでは汎用的なホスティングサービスとして、さくらの VPS を使います。

現代的なクラウドサービスでは、ゼロコンフィグで即時 Web 公開可能、無料プランも備えている Vercel, CloudFlare, Firebase などがあります。反面、これらは静的ページのホスティングやシンプルなクラウドコンピューティングの実行に最適化されており、それなりに複雑な akashic serve を動かすのは骨が折れる仕事です。静的ページと API でルーティングを仕分けして、それぞれのサービスと連携するエントリポイントを設けるなどの作業が必要になるでしょう。また、マルチプレイゲームではクライアント・サーバ間で頻繁に双方向通信を行うため、コンピューティングリソースの消費もネックです。既製品をそのまま使えず改造を迫られる上に、料金もそれなりにかかってしまうわけです。

筆者もこれを機に様々なサービスを試しましたが、最終的に ¥1,000/月 程度の月次料金と、1 時間ほどの作業で過不足なく実現できる VPS（仮想的な OS と Network が使えるもの）が最適 という結論になりました。GCP でも AWS でも実現はできるはずですが、昨今の世情やら空気感を加味してさくらの VPS を選んだという経緯となります。皆様のお好きなクラウドサービスで読み換えて頂いて構いません。

サーバスペックは、「下から 2 番目の構成」で試しています。最安プランは厳しい印象があったこと、コーヒー三杯分くらいのキリのいい料金であったことから、直感でこうなりました。さくらの VPS は無料のお試し期間があるため、「ゲームができるかちょっとだけ試してみたい」という方にもおすすめです。ただし、Linux サーバをコンソールで操作するという少しばかりの助走が必要になることにはご注意ください。

OS は特にこだわりがないので、ホビー用途でも使われる Ubuntu を選びました。

OS: Ubuntu 24.04 amd64
Plan: 1G 月額 935円

ここではさくらの VPS について詳しく述べませんが、ガイドや初心者向けの講座が公開されているので、まずは契約の前に関連文書を一読し、実現できることとそのリスクを把握することをお勧めします。だいたいコーヒーを 4 杯も飲むうちに読み終わるはずです。

2. マルチプレイゲームを動かす

さくらの VPS 契約が済み、Web UI から電源を入れると、サーバに ssh でアクセスしてコンソールが使えるようになります。ガイドに従い、必要に応じて ssh やユーザ作成などの初期設定を行いましょう。特にサーバ作成直後に設定しておく初期セキュリティ設定は重要です。

ここからは契約したリモートサーバにログインし、マルチプレイゲームをインストールして動かしてみます。

初めての方はコンソールやテキストエディタの操作に戸惑いがちですが、ご安心ください。これは誰もが通る道です。

先述のガイドをはじめ、ほとんどのマニュアルには打つべきコマンドがそのまま書いてあります。「逆引き Linux コマンド」「逆引き vi」などを検索すれば、日本語の文献にあたることも容易です。最近の Windows は WSL が使えますから、先にお手持ちの端末に Linux を入れて、マルチプレイゲームを動かしてみるのも良い方法でしょう。サーバの初期設定からインストールまでの手順は、ローカルとリモートとで大きな違いはありません。

インストールから実行まで

Linux コマンドやテキストエディタの操作に一通り慣れたら、次は必要なものをインストールします。リポジトリを操作する Git, Akashic Engine の実行に必要な Node.js をインストールします。akashic serve は Docker による実行もサポートしていますが、ここではデバッグできるようホストに直接インストールしましょう。

# Git
sudo apt install git

# Node.js (LTS: v24)
# https://nodejs.org/ja/download
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
\. "$HOME/.nvm/nvm.sh"
nvm install 24

# pnpm
# https://pnpm.io/ja/installation
curl -fsSL https://get.pnpm.io/install.sh | sh -

無事インストールが終わったら、まずは最もシンプルなマルチプレイゲームのテンプレートを動かしてみます。先に紹介したリポジトリは akashic serve が依存関係に含まれているため、そのままビルドして実行することができるはずです。

git clone https://github.com/shunsuke-tanaka/multiplay-game-x1.git
cd multiplay-game-x1
pnpm i --frozen-lockfile
pnpm run start:multi

エラーが出なければ、無事 akashic serve でマルチプレイゲームが動作しています。

ブラウザによるマルチプレイゲームの操作まで

さて、サーバのコンソール上で動いたのは良いのですが、この状態では手元のブラウザでリモートサーバのホストにアクセスしても動作しません。デフォルトの設定では ssh 通信しか許可しないため、akashic serve が動作するポートにアクセスできないのです。ポート解放は後述しますが、一般的にはグローバルなインターネットに向けて易々と公開できるものではありません。この状態でどのようにデバッグすればいいでしょうか。

ここでは、ssh ポートフォワーディングで localhost から画面にアクセスしてみましょう。ポートフォワーディングのやり方はここでは解説しませんが、要は ssh を通してリモートサーバの任意のポートにアクセスできるということです。akashic serve はデフォルトで 3300 port を使用するため、これを http://localhost:3300 としてブラウザからアクセスできるようにします。

たとえば手元の macOS 端末から ssh 経由でリモートサーバの localhost:3300 に繋ぐ場合、以下のようなコマンドで実現できます。

ssh -N -L 3300:localhost:3300 ubuntu@リモートサーバのホスト名

このコマンドを実行している間は、手元のブラウザで http://localhost:3300 にアクセスすることができます。やり方は OS や ssh クライアントによって異なりますので、それぞれのポートフォワーディング設定をお試しください。

おめでとうございます！　これであなたのゲームを実行することができました。
せっかくなのでブラウザのタブをたくさん開いて参加人数を水増しし、マルチプレイ気分を味わいましょう。このゲームはサンプルなのでこれ以上のことは起きませんが、動くものが手元にあると気分が良いものです。

3. マルチプレイゲームを公開する

ここまでの作業で、マルチプレイゲームを遊ぶことができるようになりました。一足飛びで準備を進めていよいよ Web サービスを公開する段階となりましたが、その前にコーヒーでも飲んで一考してみる頃合いです。

「個人が無策でサービスを公開する」という行為は、その責務やリスクを知る人からすれば思い切りが良すぎる行為です。あなたのゲームがワールドワイドに公開されることで与える影響、サービスの目的、リスク対策が明確に定まっている状態でしょうか。もしそのような準備ができていなければ、 まずは公開範囲を一部に限定する ことをお勧めします。

アクセス元を限定して公開する

akashic serve はデフォルトでは localhost での実行となります。そこで、コマンドライン引数の --hostname にホスト名を入力しましょう。さくらの VPS のホストはグローバル IP が振られており、ホスト名はそのままインターネットから解決できる名前となっています。

pnpm run start:multi --hostname リモートサーバのホスト名

次に、サーバのパケットフィルター設定を見直します。
先に述べた通り、akashic serve のデフォルトは 3300 port を使います。ここでポート通信を許可すれば良いのですが、ここでは送信元 IP アドレスを指定したものに限定して公開することにします。

「許可する送信元 IP アドレス」に、お手持ちの端末のパブリックな IP アドレスを設定してください。環境によっては動的に IP アドレスが設定されることもあるため、その場合は取りうる範囲を CIDR で指定します。
以下はパブリック IP アドレスを調べる AWS のサービスです。

許可する IP アドレスは信頼できるアクセス元に限定してください。

設定を保存したら、許可した IP アドレスの端末からブラウザで http://リモートサーバのホスト名:3300 にアクセスしてみましょう。無事に表示ができたでしょうか？　もし表示できない場合は、OS のファイアウォール設定でフィルタされている可能性があります。パケットフィルターのQ&A を見て原因を切り分けつつ、設定を行ってください。

先ほどのゲームと同じ要領で、公式のニコニコスネークを動かしてみました。以下は複数人でマルチプレイを遊ぶ様子を移したものです。やりましたね！

ところで、akashic serve はデバッグツールであり、デバッグのための UI を持っています。akashic serve でゲームを公開するということは、デバッグ機能も漏れなくついてくるということです。

これまでのスクリーンショットでは意図的に省いていましたが、実際には以下のようなデバッグメニュー付きの画面が表示されているはずです。

当然のことながら、ユーザが遊ぶときはデバッグ機能を有効にしたくはありませんね。2025 年 11 月現在の akashic serve ではこれらのメニューを非表示にする仕組みはありません。正式なサービスとして公開するためには、少しばかり改造が必要になることでしょう。
幸いにして、akashic serve はオープンソースです。MIT License に従い、ユーザが必要な機能を追加することができます。デバッグ機能や UI を非表示にする程度であればそれほど大きな改造ではないので、ぜひチャレンジしてみてください。

また、見た目以外の「akashic serve を使うことによる制限」については、次章で紹介しています。

Web サービスとして公開する

無事サービスとしての目的が定まり、公開の意思と覚悟、リスク対策が決まったら、いよいよ Web サービスとして公開しましょう。残すところは、　「公開するドメインを用意し、SSL に対応する」「Web サイトのセキュリティ対策をする」 といったところです。いくつか必要な作業をピックアップして箇条書きにします。詳しくは VPS 講座や各種 Web 開発の書籍を参考にしてください。

公開ドメインを調達する
- さくらのドメインなどで新規ドメインを調達します。
- さくらの VPS では無料枠のネームサーバーがあり、ドメインとサーバの紐付けを行います。
Web サイトを SSL 化する
- Let’s Encrypt で SSL 証明書を発行します。
- SSL 証明書を akashic serve に設定します。コマンドライン引数の --ssl-cert, --ssl-key にファイルパスを指定して起動してください
https でアクセスする
- akashic serve へ https でアクセスできるようにします。コマンドライン引数の --port 443 を指定して起動してください。
- サーバのパケットフィルター設定で、443 port を許可するようにします。必要に応じて Firewall 設定も許可してください。
Web サイトのセキュリティ対策をする
- 口にするとこれだけですが、リスクとコストを見極め、効果的に実践するには大変な労力が必要です。多くの関連書籍や解説記事があるため、ここではそのうちのいくつかを紹介するにとどめます。
- IPA 安全なウェブサイトの作り方
- みんなで使おうサイバーセキュリティポータルサイト

4. 持続可能な Web サービスへ

ここまでの手順でマルチプレイゲームを公開し遊ぶことができました。しかし、あくまで「遊ぶことができた」というだけで、単一ホストと akashic serve プロセスでは「持続可能な Web サービス」として展開するには程遠い構成です。

シンプルなゲームの公開はコーヒーを 10 杯入れる程度の労力で済みましたが、たとえばこれを商用アプリとして展開することを想像してみてください。さらに大規模なゲームを、回線が弱い環境でも安定して遊べる必要があるとします。何を検討しどう対処すべきでしょうか。本格的なコーヒー豆の供給が必要でしょうか。今のやり方では、クリエイターやユーザが満足する以前に行き詰まることは想像に難くありません。ビジネスとして成立させるならば尚のことです。

ここからは本格的なサービス展開に伴う課題と、その対策について紹介していきます。

akashic serve の限界

akashic serve は、前述したとおりマルチプレイゲームのデバッグ用途に公開されているツールです。本記事ではこれをそのまま流用してマルチプレイゲームのホスティングを行いましたが、当然ながらその能力には限界があります。

akashic serve は、以下のクライアント・サーバ部で構成されています。

部位	役割	実装
クライアント	ゲーム画面・UI を表示し入力を送信	JavaScript フロントエンド
サーバ	クライアントイベントを受信・集約し、ゲームフレームを配信	Node.js + Express

クライアント・サーバ間は Socket.IO による双方向通信が行われます。
サーバは全てのクライアントからのイベントを集約し、作用の結果となるゲームフレームを生成したのち、クライアントへ配信します。

クライアント・サーバではいずれもゲームスクリプトおよびエンジンを実行しており、規定された入力信号による作用が全てのインスタンスで同じ出力となるよう設計されています。

さて、ざっくりとした構造を紹介したところで触れておきたい点があります。
「akashic serve を使った Web サービスでどこまでスケールできるのか？」 という点です。

このモデルではクライアントの同時接続数、入力信号の多さに比例して、強力な計算能力を持つサーバが必要になることが自明です。実質は単一サーバのスケールアップに頼ることとなり、それ以上のスケールが困難になることが伺えます。

ゲームの実行時間も問題です。30 FPS のゲームを 24 時間 365 日遊べるステージとして公開するケースを考えてみましょう。プレイヤーの 1 分間の入力信号が 100 KiB と仮定して、それらのゲームフレーム情報（Tick と呼びます）の蓄積量は、1 プレイヤーあたり 100 KiB * 3600 * 365 = 100 GiB 強となります。実行時間を区切る、データ自体を最適化するなどの工夫が必要となります。

たとえば、「同じ空間で遊べるのは最大数名のみ」「1 プレイ 30 分まで」などとゲームルールやサービス上の制約を設けたらどうでしょうか。インスタンスごとの同時接続数が数名程度で短時間であれば、サーバの負荷は大幅に減り、複数台のサーバにスケールアウトすることも可能になります。もし思ったほどの性能が出ずとも、「入力信号を最適化し通信量を減らす」「ゲームの計算量を減らす」といった一般的な工夫の範疇で改善できることでしょう。

しかし、数百、数千あるいはそれ以上のプレイヤーを同じ空間で遊ばせたい という要求を実現したいケースはどうでしょう。このような条件で akashic serve を使うことは現実的な選択ではありません。少なくとも、律速となるサーバインスタンスと通信部を独立させ、適切に負荷分散できるよう設計し直す必要があります。いかに akashic serve がオープンソースであるとはいえ、マルチプレイのデバッグ用途のツールを大規模サービスに耐えられるよう改造するのは筋が悪いように思えます。

まとめます。数名程度のプレイヤーが同じ空間で遊ぶゲームであれば、akashic serve を動かすサーバをスケールアウトすることで十分に実用的なサービスとなります。しかし、それ以上の規模のゲームであれば、別の方策を検討する必要があるでしょう。 ²

ユーザ管理

今回は Web サイトにアクセスしたユーザが自由に名前を振り、自由に操作ができるシステムでした。大規模なサービスとなると、以下のようなユーザ管理システムが必要になることでしょう。

ユーザ名、パスワードなどで認証する仕組
一般ユーザ、課金ユーザなどのロールと権限の仕組
ユーザごとにキャラクタやアイテムデータ、アクセス履歴、課金情報を記録する仕組

ユーザ認証や認可などは、手早く構築できるクラウドサービスがあります。
重要なのはデータストアなど「状態を保存するもの」の導入です。Web サーバに DB が加われば、もはや立派なフロントエンド・バックエンド構成のシステムです。必然として、このあたりから本格的な Web サービス構築を検討することになるはずです。

プレイ管理

今回は Web サイトに常時プレイできる状態としました。たとえば PvP で、1 セッションに最大 4 人まで参加できるゲームを想像してみましょう。さまざまなプレイ状態が考えられます。これらをリアルタイムに管理するプレイ管理システムが必要となります。

上限プレイ人数に達したときの振る舞い・達せず時間経過したときの振る舞い
プレイヤーマッチング・抽選・フィルタ（同レベル帯だけ一緒に遊べるなど）
プレイヤーの途中参加・離脱

これらの複雑な状態を解決するサーバインスタンスが必要になります。
マルチプレイをどのように実現するかのゲームルールを定め、それを効率よく使えるよう抽象化した API 、セッションを設計していく必要があります。
Akashic Engine に限って言えば、マルチプレイゲームのインスタンス間を協調させる Playlog、およびそのインタフェースである AMFlow という仕組みがあるため、これらの通信機構、ストア・キャッシュ機構が必要になります。

不正対策・負荷対策

オンラインのマルチプレイゲームの歴史とは不正対策の歴史でもあります。大規模なゲームスコアを競い合うゲームで、ランキングボードがありえない値（9999999 pt など）で埋め尽くされると、多くのプレイヤーは冷めて離脱してしまうことでしょう。
現在はクライアントからサーバへ{ "ユーザ": "A", "操作": "ユーザ B を攻撃する" }というメッセージを送っています。これは、他のユーザが「ユーザ A を詐称して B を攻撃させることができる」ということを表します。極端な例では、{ "ユーザ": "A", "スコア": 9999999 } などと送ることができるということです。

また、30 FPS のゲームで入力信号が溢れるような負荷の対策も必要です。あなたのゲームが大ヒットし、世界中でスコアアタックを競い合う事態を考えてみましょう。突如として現れた小学生がゲーム拳必殺五十連打で攻略しようとしたり、超高性能AIが学習のためにあらゆる信号を毎フレーム送信して観察可能な全パターンを得ようとするかもしれません。クライアントからの入力信号を間引いたり、入場や入力を制限する仕組みが必要になるでしょう。「私はロボットではありません」と問いかける必要も、時にはあるかもしれません。

もちろん、BOT や明確な攻撃意思を持つユーザがサービスに攻撃をする可能性も忘れてはなりません。Web サービスとして規約違反や迷惑行為をするクライアントをブロックしたり、ペナルティを与えるなどの仕組みも必要となります。

これらを防ぐには、一つの方法、一つの層で防御するということは不可能です。WAF, Firewall, CDN, LB, アプリケーションそしてミドルウェアなど、影響を受けるルートに多層的な防御策が必要となるでしょう。具体的な対策は専門書籍や記事に譲りますが、この辺りが必要になってくるということは、企業や組織的なゲームクリエイションが必要になってくるという節目であるかもしれません。

「それが必要ならできる人に頼めばいいのだ」という至言があります。日進月歩なクラウドサービスや、優秀な AI によるサポートも期待できる時代です。リスクを正しく認知し、正しく恐れて、その上であなたのゲームを公開してみてください。

おわりに

1 ~ 3 までの手順で、自作マルチプレイゲームを Web サービスとして公開することができました。話を進めるために解説を端折ったところも目立ちますが、「作ったゲームを動かして遊んでもらう」要求に対する実現の一例になれば幸いです。

また、4. では「持続可能なサービスを実現する」ために何を対応せねばならないか、その指針を紹介しました。ゲーム制作に直接関係しない話ではありますが、より踏み込んだ展開をするときに思い出していただければ作者冥利に尽きます。

平成から令和と時代は移り変わり、自作ゲーム勢とその作品を取り巻く環境も、さまざまな変遷がありました。コンピュータサイエンスの進歩、ネットワークの進歩、栄枯盛衰、悲喜交々の世界において、私はというと、いつの世も変わらず抱き続ける憎悪と怨嗟と顕示欲、それらがないまぜになったどうしようもない怒りが、「新たなゲームを生み出す力」の原動力であったように思います。冒頭で触れた件について考えを巡らせるなか、ふと、そのような情動の再燃を感じました。たとえ軛に繋がれようと、自分が面白いと信じたものを形にしたいし、そういう人を応援したい。

ここまでお読みいただきありがとうございました。この記事が自作ゲーム勢のお役に立てることを願いつつ、筆を置くことにします。皆様、どうぞ良いお年を。

絵素材利用

PvP に限れば Steam で簡単に実現できますとコメントをいただきました。本文ではマルチプレイと一括りにしていますが、作るゲームのターゲット = マルチプレイに要求するレベルによって現実的な選択肢を絞れるはずです。次回があれば機能レベルの詳細な比較表を作りたいところです。（参考: 個人開発でオンライン対戦ゲームを成立させるための「現実解」と設計指針まとめ） ↩
akashic serve の限界について長々と述べましたが、これに代わる実現手段はないのでしょうか？　ここで Akashic Engine は弊社「ニコニコ生放送」で実績のあるゲームエンジンであることを思い出してください。すなわち、 「ニコニコ生放送で使用している Akashic バックエンドシステムこそ、大規模サービスに耐えられる akashic serve の代替品である」 ということです。現在において Akashic のバックエンドシステムは公開されておりませんが、個人的にはオープン化を希望しており、公式の運営に向けてあれこれ要望を送っていたりしています（その節はご迷惑をおかけしております）。もし将来的にこれらが公開された暁には、公式の告知として適切な誰かが適切な説明をしてくれることでしょう。似たような興味をお持ちの方は、ニコ生ゲーム公式 X, Discord の告知をチェックしてみてください。³ ↩
まるで中の人の発言のようですが、本文書は一社員の個人的な記事であることをお断りしておきます。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up