FiveMサーバーをIaCで構築する【txAdminと接続確認まで】

// 1. サーバーゲーム設計図の定義

今後検討するサーバー設計として、以下の独自ルールを想定します。本記事では、その前段階として既存フレームワークであるQBCoreを導入し、FiveMサーバーとしての基本構成、データベース連携、クライアント接続までを検証します。

• サバイバル要素の転換: 飲食による餓死ペナルティを廃止し、一時的な最大HP向上などの「事前のバフ」として再定義します。
• 経済の3層構造: 安全な「ホワイト」、相場変動のある「グレー」、NPC警察との戦闘が伴う高リスクな「ブラックマーケット」へ分類します。
• ソロ用役割分担システム: ハッカー等の専門職NPCを雇用可能とし、ソロプレイヤーでも大型ミッションを完遂できる環境を整備します。
• エンドコンテンツの拡充: 労働から「経営」へシフトするための店舗買収、投資システム、実車モデルのレストア（Barn Find）を実装対象として検討します。

// 1. 環境変数 HOME の解決エラーと冪等性の確保

Playbookの初回実行時、データ永続化用ディレクトリが意図したパスに作成されない事象が発生しました。原因を追跡した結果、Ansibleのタスク内で become: yes を使用したことにより、環境変数 {{ ansible_env.HOME }} が一般ユーザーではなく /root を参照していることが判明しました。

環境変数の動的解決による構成ドリフトを防ぐため、ディレクトリパスを絶対パスでのハードコーディングへ修正し、冪等性を確保しました。

- name: FiveM用データディレクトリの作成と権限設定
  ansible.builtin.file:
    path: "{{ item }}"
    state: directory
    owner: haruuu
    group: wheel
    mode: '0755'
  loop:
    - "/home/haruuu/fivem-data/server"
    - "/home/haruuu/fivem-data/txData"

// 2. イメージ名のタイポとコンテナ構成の修正

続く docker-compose.yml.j2 のテンプレート展開において、Dockerイメージ名を sprits/fivem と誤記していたため、Pull処理が失敗しました。これを正しいリポジトリ名である spritsail/fivem:latest へ修正しました。

また、FiveMの管理UI（txAdmin）のセットアッププロセスを正常に実行するため、コンテナ構成に stdin_open: true と tty: true を明記し、コンテナのデプロイを完了しました。

// 1. PIN認証とCfx Portalのキー登録

ポート 40120 へアクセスし、txAdminのブラウザUIを展開しました。認証を通過するため、docker logs コマンドからコンテナの標準出力を監視し、発行された4桁のPINコードを入力しました。その後、Cfx Portalにて「Haruuu Server」用のライセンスキーを発行し、システムへ登録しました。

// 2. MariaDBの名前解決による連携

QBCoreフレームワークのデプロイウィザードにて、永続化レイヤー（データベース）への接続設定を実施します。FiveMコンテナとMariaDBコンテナを同一のDockerネットワーク内で稼働させているため、ホストのIPアドレスではなく、コンテナ名（mariadb）をDatabase Hostとして指定し、内部通信による紐付けを完了しました。

// 1. Enhanced版の拒絶とLegacy版ディレクトリの指定

最新の「GTA V Enhanced版」ではFiveMクライアントが動作せず、旧来の「Legacy版」バイナリの存在を要求する警告が出力されました。

Cfx.reの仕様により、有効なLegacy版インストールフォルダの再指定を要求される

解決策として、Steamライブラリ上の該当ディレクトリを明示的に指定しました。これに伴い、サーバー側との互換性を確保するため約518MBのデータパッチのダウンロードが実行されました。

ローカルゲームデータに対する518MBのアップデート適用

// 2. Cfx.reアカウント連携とUI更新通知

パッチ適用後、オーナー権限の確実な認識とサーバーリストへの登録のため、FiveMクライアントとCfx.reアカウントの紐付け（Link your account）を完了させます。

権限管理等に必要なアカウント連携の要求画面

連携の過程において、FiveMクライアント側のUI（カラーウェイやサーバーリストのハイライト仕様）に関するアップデート通知が提示されたため、これを承諾し進行しました。

クライアントUIの仕様変更に関するインフォメーション

// 3. ビルドバージョンの自動切り替え

FiveMには「ゲームビルド」の概念が存在します。構築した「Haruuu Server」側の要求に適合させるため、クライアント側のビルドが自動的にダウングレード（3258から3095へスイッチ）されました。この自律的な再起動プロセスを経て、ハンドシェイクが確立しました。

サーバー側の設定に合わせ、ビルド3095へ自動的に切り替わる警告

// 1. セッション初期化とキャラクター登録

コンソール上に各DLCやスクリプトの初期化（INIT_SESSION）ログが出力され、アセットのストリーミングが進行します。

Loading game (87%)。サーバー内のインスタンス生成が最終局面に達する

初回ログインに伴い、QBCoreフレームワークの機能によりキャラクター作成UIがコールされます。氏名や国籍を定義し、MariaDBへレコードを記録しました。

データベースと連動した詳細なキャラクター登録フォーム

// 2. ロスサントスへのスポーンとリソース負荷

登録プロセスの完了後、ロスサントスの指定座標（病院前）へのスポーンに成功しました。これにより、サーバーインフラとQBCoreフレームワークの正常稼働を確認しました。

エラー対応を完了し、無事にサーバー内へ入国した状態

同一PC上でサーバー（WSL2）とクライアントプロセスを共存させた際のシステムリソースを観測しました。VmmemWSL が約2.4GB、FiveMクライアントが約1GB弱で推移しており、ローカル・フルスタック環境として十分な運用性があることを確認しました。

メモリ32GBのホスト環境において、システムリソースに十分な余裕を残したまま安定したプロセス稼働を観測

// 1. ミラーモードの恩恵とファイアウォール設定

本来、NATモードで動作するWSL2へ外部からアクセスさせるには、ホストOS側で netsh interface portproxy 等を用いたポートフォワーディング処理が必須となります。しかし、本環境では .wslconfig において networkingMode=mirrored（ミラーモード）が有効化されていました。

これにより、WSL2がWindowsホストのIPアドレスを動的に共有するアーキテクチャとなっているため、Windows側のファイアウォールで該当ポートの受信を許可するのみで経路の確保が可能となりました。

# FiveM用のTCP/UDPポート 30120 を許可する規則を追加
New-NetFirewallRule -DisplayName "FiveM Server" -Direction Inbound -LocalPort 30120 -Protocol TCP -Action Allow
New-NetFirewallRule -DisplayName "FiveM Server" -Direction Inbound -LocalPort 30120 -Protocol UDP -Action Allow

# txAdmin管理画面用のポート 40120 を許可
New-NetFirewallRule -DisplayName "FiveM txAdmin" -Direction Inbound -LocalPort 40120 -Protocol TCP -Action Allow

// 2. 別PCからのセッション合流

規則の追加後、別PCのクライアントコンソールより connect [ホストPCのIPアドレス] を発行し、セッションへの参加を試みました。結果として、通信のタイムアウトや同期ズレを発生させることなく、2名のプレイヤーによるマルチプレイ環境の開通に成功しました。

なお、この時点のIPアドレス指定はローカル検証用の暫定運用です。今後、継続運用する場合は固定IP、ホスト名、またはDNS等を利用し、接続先の管理方法を整理する予定です。

サーバー内のロスサントスにおいて、別PCのプレイヤーとセッションが同期した状態

召喚した車両（Adder）を背景に。通信パケットの遅延もなく正常に動作