Fortniteで会話NPCを作る実装ガイド（Creative・UEFN・Verse）

対象読者と前提（Fortnite AI 会話 NPC のやり方）

想定読者はUEFNの基本操作ができる中級クリエイターです。Verseやデバイスの基礎知識があると読みやすい内容にしています。初心者向けの補足も加えますが、サンプルは中級者を想定しています。

想定スキルレベル

各レベルで期待する前提知識を示します。

• 初心者: Creativeの基本操作、Epicアカウント取得、簡単なデバイス配置ができる。
• 中級者（主なターゲット）: UEFNの起動・Content Browser操作、デバイスのDetailsパネル確認、基本的なVerseの概念を理解している。
• 上級者: サーバ権限・永続化・負荷試験の経験があり、外部サービス連携や運用設計が可能。

検証環境の前提

検証用の最小環境を明示します。

• Epic Games Launcher と Epicアカウントを用意すること。
• Launcherから「Unreal Editor for Fortnite（UEFN）」をインストールすること。
• UEFN起動後は Content Browser → Devices → UI → Conversation Device を確認する。
• テストは編集権限のあるCreative島で行い、プレビューと実機で挙動を検証する。

準備とバージョン管理（UEFN/Creative）

UEFNエディタ版とFortniteクライアントの対応は頻繁に変わります。作業前に使用するUEFNバージョンと運用ルールを決めることが重要です。

必要環境とインストール手順

最低限のセットアップ手順を示します。

1. Epic Games Launcher をインストールしてログインする。
2. LauncherのLibraryまたはDiscoverから Unreal Editor for Fortnite（UEFN）を導入する。
3. UEFNを起動し、Content BrowserでDevicesを確認する（Content Browser → Devices → UI → Conversation Device）。
4. FortniteのCreativeで検証用島を作成し、編集権限を確認する。
5. ソース管理クライアント（Git+Git LFS または Perforce）を用意する。

バージョン互換とソース管理の実務

バージョンの運用方針とファイル分離の指針を示します。

• エディタとクライアントの対応表を作り、検証済み組み合わせを明示してください。
• 小規模はGit＋Git LFSが運用コストが低いです。アセットが多ければPerforceを検討します。
• Verseスクリプトはテキストファイルとして管理し、バイナリアセット（.uasset/.umap/.ogg等）はLFSまたはPerforceで扱います。
• 定期的にプロジェクトのバックアップ（ZIP/Steam depot/Perforce snapshot）を取得してください。

Creativeだけでの最小実装（AI会話NPC：商人の手順）

Creativeデバイスだけで短時間に動く商人NPCの最小実装を説明します。ここでは同期や高可用性は考慮せず、まずはローカルで動くことを優先します。

デバイス配置とConversation Deviceの基本プロパティ

Conversation Deviceを配置するときに確認すべき代表的プロパティの例と確認方法を示します。

• デバイス選択後は Details パネルを確認してください。プロパティ名はバージョンで変わります。
• 代表的に見る項目例（エディタによって表記が異なる場合があります）: Conversation Asset / Start Node / Activation Type（Proximity/Interaction/Auto） / Trigger Distance / Enabled / Team Filter / Play Voice Locally / Audio Asset。
• 実際のプロパティは選択したConversation DeviceのDetailsに表示されます。必ずDetailsで名称と動作を確認してください。

商人NPCの具体手順

手順は実務的にこう進めます。

1. UEFNまたはCreativeで島を開く。
2. NPC用のキャラクターまたはNPCスポナーを配置する（外観を設定）。
3. Content BrowserでConversation Asset（会話アセット）を新規作成し、台詞ノードと選択肢を入力する。
4. Conversation Deviceを配置し、Conversation Assetを紐付ける。Activation TypeやTrigger Distanceを設定する。
5. 会話で「購入」選択肢を配置し、その出力をアイテム付与系デバイス（Item Grant / Item Spawner 等）へ接続する。デバイス名はバージョンで異なるためDetailsで確認する。
6. 音声を使う場合はContent Browserへ音声アセットを追加し、Conversationノードに紐付ける。音声はプレイヤー個別再生か全体再生かを選ぶ設定を確認する。
7. プレビューで動作確認し、複数クライアントで同期が必要な箇所はマルチプレイで検証する。

テストとトラブルシュート

よくある不具合と切り分け手順を示します。

• 台詞が出ない: Conversation DeviceのEnabled、Activation Type、Trigger Distance、Team Filterを確認する。
• 音声が鳴らない: 音声アセットの参照、サンプルレート、ボリューム、プレイモード（ローカル／グローバル）を確認する。
• アイテム付与が競合する: 先にサーバ権限で在庫をチェックする設計にすること。Creative単体では同期限界があるため注意する。

会話設計とローカライズ（フロー・状態管理）

会話のUX設計と多言語運用はユーザー体験に直結します。設計段階でフォールバックやファイル構成を決めておくと運用が楽になります。

会話ツリー設計とデータ構造

会話はノードと遷移で管理します。下記は運用しやすいデータ構成の一例です。

• 台詞はキー管理（例: merchant.greeting）にして翻訳テーブルで運用します。
• データ例（JSON推奨）: ノードID、textKey、audioKey、options:[{textKey,nextId,conditions}]。
• この構造により、UEFN側ではtextKeyをConversation Assetへ差し替えるだけで多言語を管理できます。

状態遷移と同期方針

プレイヤーごとの状態とグローバル状態の分離が重要です。

• プレイヤー固有の進行はPlayerStateへ保存し、NPCの共通在庫はサーバ権限で管理します。
• 在庫操作や報酬付与は原子操作で行う設計にします。楽観的ロック（バージョン番号）か悲観的ロック（アイテム単位の処理キュー）を採用してください。
• 競合対策としては、比較して更新するCAS方式や、トランザクションキューを使用した直列化が実務的です。

ローカライズと音声運用の具体例

運用時の命名規約とフォールバックを決めます。

• 命名例（推奨）: Audio/Merchant/en-US/greeting.opus、Audio/Merchant/ja-JP/greeting.opus。ファイル名にロケールを入れて管理します。
• ロケール選択はプレイヤーの設定→サーバ設定の順で決め、該当ファイルが無ければサーバのデフォルト言語にフォールバックします。
• 音声は容量が増えやすいので、頻出台詞のみを音声化します。フォーマットは圧縮率の高いOpus（OGGコンテナ）を推奨します。サンプルレートや具体値はEpicの公式オーディオ仕様を参照してください。

UEFN＋Verseでの拡張実装（同期・トランザクション）

Verseを用いると同期や永続化、複雑な分岐が実装できます。ただしVerseの構文やAPIは変わるため、下記は設計指針と概念例です。実装時は必ずVerse公式ドキュメントを参照してください。

推奨アーキテクチャとファイル構成

拡張実装での責務分割と例を示します。

• DialogueManager: 会話ツリーの解決と条件判定を担います。
• NPCController: インタラクト受付、アニメーション同期、視線制御を行います。
• PlayerState: 各プレイヤーの進行とフラグを保持します。
• AudioManager: 音声の個別／全体再生切替とキャッシュを管理します。
• Persistence: 永続化連携（サーバ側ストレージや外部DB）を抽象化します。
• ファイル例: /Verse/Dialogues/DialogueManager.verse、/Data/merchant_inventory.json、/Audio/Merchant/...

擬似コードテンプレート（注意：概念例）

下は概念説明用の擬似コードです。実際のVerseシンタックスやAPI名とは異なる可能性があります。必ず公式ドキュメントでシグネチャを確認してください。

トランザクションと競合回避の実務例

競合時の回避手法と数値目安を示します。

• 悲観的ロック: アイテム単位の処理キューで直列化する。ロックタイムアウトは通常1〜3秒程度に設定する。
• 楽観的ロック: 在庫にバージョン番号を持たせ、更新時にバージョン一致を要求する。競合時は再試行（最大3回）とバックオフ（100〜300ms）を行う。
• 冪等性: 購入リクエストにはidempotency tokenを付与して二重実行を防ぐ。
• 外部DB連携: 2フェーズコミットは複雑なため、可能ならサーバ内で原子更新を完結させる。

同期とパフォーマンス目標（定量的ガイドライン）

運用で目安になる数値と負荷試験案を示します。

• 1プレイヤー当たりの近接で同時に有効なNPC数: 8〜12体を目安にする。これはクライアント描画とネットワーク負荷のバランスを考慮した値です。
• クライアント当たり許容同時音声ストリーム: 2〜3本。多数は帯域とCPUを圧迫します。
• 音声アセットの目安: モノラルOpusで1ファイルあたり0.2〜2MB程度（台詞長に依存）。プロジェクト全体の音声メモリは200MB前後を目標に抑える運用が現実的です。
• サーバのトランザクション遅延目標: 平常時 p95 < 200ms を目安にする。500ms超はUXに影響します。
• 負荷試験ケース例:
• 小規模: 32プレイヤー、NPCアクティブ8体、同時購入リクエスト 10 req/s。
• 中規模: 64プレイヤー、NPCアクティブ10体、同時購入リクエスト 50 req/s。
• 大規模: 128プレイヤー、NPCアクティブ12体、同時購入リクエスト 200 req/s。
• 監視指標: トランザクションレイテンシ p50/p95、エラー率、競合発生率、サーバCPU/メモリ、ネットワーク帯域。

テスト・運用・法務とまとめ（公開・監視・法務チェックと要点まとめ）

公開運用にはテスト自動化と法務対応が不可欠です。運用監視とリスク管理を組み合わせてリリースを行ってください。

自動テストとCI運用の実務

CIで取り入れるべき自動テストの種類と運用手順を示します。

• 単体テスト: DialogueManager等の純粋ロジックをユニットテスト化する。
• 統合テスト: NPCとアイテム付与の結合フローをテストする。疑似プレイヤーを使った自動化が有効です。
• E2Eテスト: マルチクライアント環境での同期検証を自動化する。ヘッドレスクライアントやボットで負荷試験を行います。
• CIパイプライン例: コードlint → ユニットテスト → ビルド（パッケージ化）→ テスト環境へデプロイ → 自動E2E → 成果物保存。

ログ形式・監視指標・アラート閾値

実務で有用なログ設計とアラート条件を提示します。

• ログは構造化（JSON）で出力する。主要フィールド例: timestamp, serverId, npcId, action, playerHash, result, latencyMs, errorCode。
• 監視指標: トランザクションp95, エラー率, 競合率, サーバCPU/メモリ使用率, ネットワーク帯域。
• 推奨アラート閾値: トランザクションp95 > 250ms、エラー率 > 1%、競合率 > 0.5%、サーバメモリ使用率 > 80%。閾値はプロジェクト特性で調整してください。
• ログ保持: 運用ログは30〜90日、監査ログは規制に従い長期保存。PIIは最小化して暗号化保存すること。

法務・個人情報の具体的対策

外部APIや音声を扱う際の実務的リスクと対策を示します。

• 明示的同意: プレイヤーから個人情報や音声を外部に送る場合は明示的な同意を取得する。年少者は保護規定に注意する。
• 最小送信: 外部APIへ送るデータは最小化する。プレイヤーIDはハッシュ化やトークン化する。
• 暗号化: 送信はTLS 1.2以上を使用し、保存は暗号化（at-rest）を必須にする。
• ログと保持: 音声の文字起こしや通信ログは保管ポリシーを定め、削除要求に対応できるようにする。
• 第三者送信: 外部プロバイダを使う場合はDPA（データ処理契約）を締結し、データ所在地と再委託の可否を明確にする。
• 外部AI利用: リアルタイム生成AIに生データを送る前に、利用規約とEpicのポリシーを必ず確認する。TTSや生成音声の利用は事前に許諾を取得すること。

公開フローと運用チェック

公開前に必ず行うべきチェックと運用手順を示します。

• 非公開ビルドでクローズドテストを実施し、ログと同期を確認する。
• 規約遵守チェック: Epicのコミュニティガイドライン、利用規約に抵触しないか確認する。
• リリース手順: ステージング→段階的公開（ロールアウト）→運用監視→問題発生時は迅速にロールバックできる手順を設ける。
• 運用体制: ログ監視・アラート受信者・対応フローを明確にする。

公式ドキュメントと参考（公式/非公式の区別）

確認すべき公式リソースと参考記事をまとめます。公式情報を最優先で参照してください。

• 公式（必読）: Conversation Device（UEFN）公式解説
  https://dev.epicgames.com/documentation/fortnite/using-the-conversation-device-in-unreal-editor-for-fortnite?lang=ja

• 公式（参照）: Epicの開発者向けドキュメント（UEFN/Verseのトップ）
  https://dev.epicgames.com/documentation/fortnite?lang=ja

• 非公式（動向参考）: Persona Device 等に関する記事（非公式情報として参考にすること）
  https://innovatopia.jp/tech-entertainment/tech-entertainment-news/56585/

• 注意: Persona Deviceや新機能はEpic公式のリリースノートを優先して確認してください。

まとめ（実務上の要点）

要点を短く整理します。

• CreativeのConversation Deviceで短時間の最小実装が可能です。
• UEFN＋Verseは同期・トランザクション・永続化で運用性を高めます。
• 音声は圧縮と個別再生設計で帯域とメモリを節約します。
• 外部API利用や音声送信は同意・最小化・暗号化・DPAを必須にしてください。
• 実運用では負荷試験と監視指標を定め、p95レイテンシとエラー率の閾値を設定して運用してください。