# OSS化プロジェクト

**URL:** <http://discourse.kroko.jp/t/topic/229>\
**Category:** @パーティⅡ\
**Created:** [2026 年 8 月 22 日午前 7:44 UTC](http://discourse.kroko.jp/t/topic/229 "2026-08-22T07:44:59Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![kroko](http://discourse.kroko.jp/user_avatar/discourse.kroko.jp/kroko/32/3_2.png) [@kroko](http://discourse.kroko.jp/u/kroko)\
**Post date:** [2026 年 8 月 22 日午前 7:44 UTC](http://discourse.kroko.jp/t/topic/229/1 "2026-08-22T07:44:59Z")

</div>

OSS化します。何か質問があればコメントください。

- コードは完全リファクタリングしてMITかApacheかAGPLv3
- 画像は全て再作成してCC等に
- demoサイトはある程度形になったら用意
- Issue, PR, 画像生成等は歓迎

> **[GitHub - witchcraze/party2re: Party2 を新しい実装として再構築し、OSSとして継続的に発展させるためのプロジェクト](https://github.com/witchcraze/party2re)**
>
> Party2 を新しい実装として再構築し、OSSとして継続的に発展させるためのプロジェクト

---

<div class="post-metadata">

**Author:** ![kroko](http://discourse.kroko.jp/user_avatar/discourse.kroko.jp/kroko/32/3_2.png) [@kroko](http://discourse.kroko.jp/u/kroko)\
**Post date:** [2026 年 9 月 19 日午前 2:39 UTC](http://discourse.kroko.jp/t/topic/229/2 "2026-09-19T02:39:11Z")

</div>

1月たったので現状レポート

* * *

# プロジェクト『party2re』ステータスおよびアーキテクチャ評価レポート

本レポートは、レガシーCGIゲーム『@パーティⅡ』のモダンバックエンド再構築プロジェクト「party2re」について、開発開始から約1ヶ月時点の進行状況、アーキテクチャの多角的評価、および今後の課題とリスク分析をまとめたものです。

## 1. プロジェクトの現状と開発進捗

現在、プロジェクトは「Version 1.0 Reconstruction / Refactoring (Phase 5+)」の終盤に位置しており、バックエンドの基盤構築およびオリジナル仕様の再現（Parity対応）がほぼ完了しています。

- **APIおよび機能モジュールの完成:** 39の機能モジュール（戦闘、経済、生産、ギルド、カジノ等のミニゲーム）が実装済みであり、OpenAPI 3.1に準拠した275パス / 297オペレーションのHTTP JSON APIが稼働しています。

- **レガシー仕様の完全再現（1:1 Parity）:** 初期開発においてAIエージェントが推測で実装した架空機能（オークション、配達クエスト、Eloレーティング制PvPなど）は、データベースマイグレーション（068番台以降）によって徹底的に削除・修正され、原作の素朴な仕様へと引き戻すリファクタリングが完了しています。

- **技術スタックの選定完了:** Go言語によるモジュラーモノリスアーキテクチャを採用し、永続化層にMariaDB、一時状態（Transient State）の管理にValkey（Redis）を用いる構成が確立されています。

## 2. 多角的なアーキテクチャ評価

### 2.1. ソフトウェア設計と保守性（高評価）

- **厳格な境界を持つモジュラーモノリス:** `internal/` 配下のパッケージがドメイン（`battle`, `economy`, `guild`, `shop`など）ごとに明確に分離されています。マイクロサービスの複雑さを避けつつ、依存関係のスパゲッティ化を防ぐ現実的かつスケーラブルな設計です。

- **Valkeyへの状態オフロード:** カジノのルーム状態、PvPのマッチング、パーティのロビーなど、短命で更新頻度の高い状態をRDBからValkeyへオフロードすることで、データベースの負荷を極小化する設計がなされています。

### 2.2. 並行性制御とトランザクション管理（極めて高評価）

- **決定論的行ロック階層（Deterministic Row-Lock Hierarchy）:** MMORPG特有の複雑なトレードや戦闘処理において、データベースの行ロック取得順序に明確な階層（Rank 0〜8）が設けられています。

- **AST解析による自動検証:** 上記のロック順序ルールが守られているかを、Goの抽象構文木（AST）を解析するLinter（`lock_hierarchy_lint_test.go`）によってCIで自動検証しています。これにより、ヒューマンエラーやAIの生成コードによるデッドロックの発生を未然に防ぐ堅牢な防御壁が構築されています。

### 2.3. AI支援開発（Agentic Workflow）との親和性（高評価）

- **細分化されたルールモジュール:** `.agents/rules/` ディレクトリに、マイグレーション制約、アーキテクチャ方針、セキュリティガイドラインなどを分割配置しています。LLMのコンテキストウィンドウを圧迫せず、タスクに必要なルールのみを選択的に読み込めるため、ハルシネーションを抑制しコード品質を安定させる高度な運用が行われています。

## 3. 今後の課題・懸念と現在のアプローチ

現在オープンとなっているIssue情報から、プロジェクトは「APIサーバーの完成」から「フロントエンドとの結合および本番運用」へとフォーカスを移しています。

- **課題 1: APIからの表示ロジック・アセットの分離とテーマ対応**

- **課題 2: 無効なリクエストによるバックエンド負荷とUIロジックの重複**

- **課題 3: UI非依存のゲームループ検証の欠如**

- **課題 4: 本番インフラの堅牢性不足**

## 4. 現時点で対策が明確でない潜在的リスク（盲点）

提示されたロードマップやIssueの範囲外で、将来的に重大なブロッカーとなる可能性が高い課題を指摘します。

- **潜在リスク 1: 分散システムにおけるデータの不整合（MariaDBとValkey間）**

- **潜在リスク 2: API化によるBOT・マクロの脅威とゲーム内経済の崩壊**

- **潜在リスク 3: フロントエンドとバックエンドのステート同期（通信遅延時のUX）**

- **潜在リスク 4: 認証フローとアカウントのリカバリ手法**

---

<div class="post-metadata">

**Author:** ![kroko](http://discourse.kroko.jp/user_avatar/discourse.kroko.jp/kroko/32/3_2.png) [@kroko](http://discourse.kroko.jp/u/kroko)\
**Post date:** [2026 年 9 月 19 日午前 7:38 UTC](http://discourse.kroko.jp/t/topic/229/3 "2026-09-19T07:38:58Z")

</div>

今の作り方だと、おそらくこういうこともできる。

* * *

# 提案書: Chat-UI Client (Discord/Slack) と AIエージェントの共闘エコシステム構想

## 1. 概要 (Concept)

`party2re` の堅牢なJSON API（Issue #629）を活用し、公式のWeb GUI（React）とは別軸のクライアントとして、「Discord / Slack 統合型チャットクライアント」を開発する構想です。

単にゲームをチャットツールに移植するのではなく、TRPG（テーブルトークRPG）のように「全プレイヤーの行動ログが1つのチャンネルで共有される熱狂」と、「人間と自律型AIエージェントが同じチャンネルで会話し、共闘する体験」を創出します。

## 2. コア体験 (Key Experiences)

### A. 共有される物語（Shared Narrative Log）

個人の画面内で完結するWeb UIとは異なり、行動の結果がすべてテキストとしてチャンネルにブロードキャストされます。

- **実況効果:** `[ログ] @kau は宿屋に泊まり、HPが全回復した！` `[ログ] @kau はドラゴンに敗北した...` など、他人のプレイ状況がタイムラインに流れ、自然なコミュニケーションや共闘のきっかけが生まれます。

### B. HATEOAS駆動の「ゼロ・タイピングUI」

チャットクライアントであっても、プレイヤーに `/attack` のようなコマンドを手打ちさせることはしません。

- API（`GET /context`）から返却される `available_actions` のリストを、Discord/Slackの「インタラクティブ・ボタン（Message Components）」に直接マッピングします。

- プレイヤーはチャット上に提示されたボタン（例: `[攻撃する]` `[回復薬を使う]`）をタップするだけで、裏側でBotが適切なAPIエンドポイント（`POST /api/v1/...`）を叩き、ゲームを進行させます。

### C. 「AIプレイヤー」のシームレスな参加

APIから見れば、人間（が押したBotのボタン）もAIエージェントも全く同じリクエストです。

- **自律行動:** AIエージェント（LLM）は定期的にAPIをポーリングし、自分のステータスに応じて行動を決定します。

- **ロールプレイ発言:** APIを実行するのと同時に、チャンネルに対して「HPが減ったので一度街に戻りますね」「ドラゴン討伐、私も加勢します！」といったテキストを送信させます。

- これにより、人間と見分けがつかない（あるいは個性的な性格を持った）AIの仲間が、日常的にチャンネルに常駐する空間が完成します。

## 3. アーキテクチャと技術的実現性 (Feasibility)

この構想は、現在のバックエンド設計を変更することなく、 **完全に独立した外部プロジェクト（別リポジトリ）として並行開発が可能** です。

1. **Backend (`party2re`):**

2. **Web Client (モノレポ内 `web/`):**

3. **Chat Bot (新規: `party2re-chat-bot`):**

## 4. 段階的導入フェーズ (Roadmap)

- **Phase 1: Read-Only 通知Bot (Observer)**

- **Phase 2: インタラクティブBot (Player)**

- **Phase 3: AIコンパニオン (Agent)**

## 5. 戦略的価値 (Strategic Value)

このアプローチは、ゲームへの **参加ハードルを劇的に下げる** 効果があります。わざわざWebブラウザでゲーム画面を開きっぱなしにしなくても、普段使っているDiscordコミュニティの片隅で、仕事や雑談の合間にボタンをポチポチ押すだけで@パーティの世界に干渉できるようになります。

APIの設計が洗練されていると、こういった「遊び方の拡張」が後からいくらでも、しかもバックエンドを汚すことなく追加できるのが最大の強みです。

---

<div class="post-metadata">

**Author:** ![file](http://discourse.kroko.jp/user_avatar/discourse.kroko.jp/file/32/788_2.png) [@file](http://discourse.kroko.jp/u/file)\
**Post date:** [2026 年 9 月 24 日午後 12:57 UTC](http://discourse.kroko.jp/t/topic/229/4 "2026-09-24T12:57:20Z")

</div>

裏でいろいろコード見てましたが、Go ~~と英語~~ をあまり触れたことないのもあり  
手探り状態で見ている箇所が多く、お手数をおかけしますがいくつかご確認できればと思います

#### 1. 本パーティIIはVer1.0になってからWeb上で遊べる形になる認識でよいでしょうか？

裏でREADME.mdに従いコンテナ立ち上げたりしたのですが、  
Web上でアクセスして現CGIパーティIIのようにある程度形になったゲームを遊ぶ方法が少しわかりませんでした。

docoker-composeやgit log見る限りではAPIやDBサーバ作成のところが主に進んでおり、  
まだWebサーバを立ち上げ遊べるところまではまだ組みあがってはないのかと推察してます

ドキュメントやIssueが全部英語になっており、  
~~英語がお世辞にも超苦手な~~ 自分ではぱっと全部を読み切ることはできず…

#### 2. 本プロジェクトで使用しているLLMは何でしょうか？

昨今いろいろLLM(Github copilotやclaude codeなど)が出ていますが、  
何を使用してコード作っているのかを知りたかった次第です

実はまだ個人としてはLLMの契約をしておらず、  
いろいろ何が良いかなとまだ探っている状況でして、もしおすすめなどがあればと思っております

---

<div class="post-metadata">

**Author:** ![kroko](http://discourse.kroko.jp/user_avatar/discourse.kroko.jp/kroko/32/3_2.png) [@kroko](http://discourse.kroko.jp/u/kroko)\
**Post date:** [2026 年 9 月 24 日午後 1:51 UTC](http://discourse.kroko.jp/t/topic/229/5 "2026-09-24T13:51:01Z")

</div>

> [@file](#):
>
> #### 1. 本パーティIIはVer1.0になってからWeb上で遊べる形になる認識でよいでしょうか？

はい、そうなります。  
現時点では各機能をhttp経由で呼び出す機能は繋がっていないと思います。

Ver1.0は既存機能を一通り作ることが目的ですが、まだ着地点を明確にしているわけではないです。当面は不足機能の実装と不具合修正、リファクタリングが続くと思います。

> [@file](#):
>
> #### 2. 本プロジェクトで使用しているLLMは何でしょうか？

メインはGemini 3.x flashです。  
理由は安いのと、最初の1回だけ300ドル分のクレジットも利用できるからです。

> **[僕がGoogle AI Proプランに加入したわけ｜witchcraze](https://note.com/witchcraze/n/n73f82da382f1)**
>
> 以前はGemini CLiの無償枠が非常に大きかった。1日1000リクエスト。 これがAntigravity CLIへの移行で非常に制限された。 使えないわけではないけど、厳しい。今まで通りの使い方は全くできない。 そうこうしている間にCodexやCopilotも無償枠ができて、1月単位でのレートリミットでそれなりに使えるようになってきた。しかし何だか肌に合わない。普段使いや開発作業で問題は出ないけど、なんだか今いち。というかシンギュラリティはパフェの味の執筆がうまくいかない。 ...

300ドル分のクレジットがなくなったし、OpenAIとAnthropicが低価格モデルを出してきたので、そのうち乗り換えるかもしれません。

特定のモデルに依存しない設計になっているので、もうちょっと進めたら、誰でも参加できるようにドキュメントなども整備すると思います。