小規模なインディースタジオでは全員が何役もこなします。アーリーアクセスのタイトルが伸びると、Discordのサポートチケットが真っ先に破綻します。この構成では、既知の不具合と定型質問を確実に処理し、確信が持てないものは人間にエスカレーションする——ハルシネーションを起こさないサポート層を組み立てます。
サポートの悪夢
プレイヤーはFAQを読みません。Discordに飛び込んで「ゲーム壊れた、直して」と書くか、既知の問題への回答を即座に求めます。必要なのは、苛立たせるだけのチャットボットではなく、実際に機能するトリアージシステムです。
1. トリアージ・アーキテクチャ
OpenClawをHetzner VPS（月額約10ドル）にデプロイし、公式インテグレーション経由でDiscordサーバーに直接接続します。あわせて、社内のJiraボードと非公開のNotion Wikiへの読み取り権限を与えます。
2. AI ツールキット
この構成の具体的なセットアップは次のとおりです：
- ハードウェア: Hetzner ARM64 VPS (8GB RAM, 4コア)。ここでOllama経由で量子化されたLlama-3-8Bをローカル実行しています。
- 検索拡張生成 (RAG): OpenClaw は12時間ごとに社内の Notion Wiki をインデックス化します。ゲームの仕組みについて文字通りすべてを知っています。
- Jira API スキル: OpenClaw が未解決のバグチケットを読み取り、プレイヤーの報告に基づいて新しいチケットを自律的に作成できるようにするカスタムPythonスクリプト。
3. ハルシネーションを飼いならす
サポートボットにとって最悪の挙動は、答えをでっち上げることです。「取得したコンテキストにのみ忠実であること」を強制する厳格なシステムプロンプトを使います。答えがRAGデータベースにも現在のJiraチケットにも無い場合は、回答を止めて人間の開発者にメンションするよう明示的に指示します。
4. 実際のワークフロー
プレイヤーが #support チャンネルに投稿すると、OpenClaw がそれを読みます。まず、その問題が Jira の既知のバグと一致するかどうかを確認します。一致する場合、チケットへのリンクと修正予定時期をプレイヤーに返信します。ゲームの遊び方に関する質問であれば、Notion Wiki から引き出して答えます。
結果
このパターンが引き受けられるのは、定型質問と重複したバグ報告です。新規の不具合、返金、アカウントに関する問い合わせは意図的に人間へ回します。エスカレーションの閾値をどこに置くかが、この構成で最も重要な設計判断になります。