カルタグラフTRPG

Appearance

技術スタック ​

CarTaGraphFantasyの実装に使う技術スタックの方針を整理する。現状はVitePressによるこのドキュメントサイトのみで、アプリケーションの実装コードはまだ存在しない。ここでは今後の実装フェーズに向けた方針を決める。

開発フェーズの段階分け（決着） ​

grillingによる深掘りの結果、以下の通り決着した。

いきなりセッション管理システム（ドライバー・ナビゲーターの非同期プレイ、GM/PL操作）まで作るのではなく、段階的に進める。

  1. まず、カードモチーフでの閲覧体験を提供する公開閲覧サイトを作る。
  2. 実際にプレイできるセッション管理機能は、後続フェーズで追加する。

odyssageの「Player-Context MVP → Multi-Context Evolution」という段階展開が参考になる。CarTaGraphFantasyはまだ設計段階（プレイテストもこれから）で、いきなりセッション管理まで作るのはリスクが大きい。

実装言語（決着） ​

TypeScriptのみで統一する。類似コンセプトの別プロジェクト（tabifuda）はコアロジックをRustで実装しWASM化しているが、これは決定性（同じ入力から必ず同じ結果になること）を重視した選択。CarTaGraphFantasyは論点Mで決着した通り、厳密な決定性よりも「機械的な自動判定より人間の裁量を優先する」方針を選んでおり、Rustのような堅牢な型システムを追求する動機が薄い。開発スピードを優先する。

インフラ・ホスティング（決着） ​

  • クラウド — AWSを使い、CDK（TypeScript）でIaCする。類似コンセプトの別プロジェクト（odyssage・echo-500）はCloudflareを使っているが、CarTaGraphFantasyでは意図的にAWSを選ぶ。動機はAWSの習熟度を上げたいこと。
  • 閲覧サイトのホスティング — まずGitHub Pagesで構築し、バックエンドAPI（セッション管理機能）を作り始めるタイミングで、S3 + CloudFrontへまとめて移行する。それまでは無料のGitHub Pagesで運用し、二度手間を避ける。
  • バックエンドAPI・グラフDB（Neptune等）の具体的な構成 — 今回のフェーズ（閲覧サイト）では検討せず、セッション管理機能のフェーズに持ち越す。

パッケージマネージャ・モノレポ構成（決着） ​

  • パッケージマネージャ — 現状のpnpmを継続する。変更するメリットが薄い。
  • フォルダ構成 — 将来アプリケーションコードが増えたら、tabifuda・odyssageと同様のモノレポ構成にする。
text
├─ apps/       # 閲覧サイト等のアプリケーション
├─ packages/   # 共有ロジック・スキーマ等
├─ infra/      # CDKによるIaCコード
└─ docs/       # 設計仕様書（VitePress、このサイト）

データベース（決着） ​

  • RDB — Neon（サーバーレスPostgres）を使う。コスト比較の結果、無料枠が手厚く（ストレージ0.5GB、月100 CU時間、自動ゼロスケール、クレカ不要）、有料でも2025年12月以降は月額最低料金の縛りがない純粋な従量課金。対してAurora Serverless v2は最小0.5 ACUでも稼働中は時間$0.06（常時起動なら月$43〜45相当）で、Neonほどコストを抑えられない。「コストをなるべくかけない」という方針から、DBだけAWS外（Neon）を選ぶ。AWS学習という目的は、S3＋CloudFront・CDK・将来のLambda等の部分で引き続き満たせる。
  • 正史グラフ・PC発見グラフの表現方法 — 専用のグラフDB（Neptune等）は使わず、RDB上で（隣接リストテーブル＋再帰CTE等で）グラフ構造を表現する。現状のグラフ規模（シナリオ単位の正史グラフ、PC単位の発見グラフ）は専用グラフDBが要るほど巨大ではなさそうなため。データ規模・クエリパターンが具体化してから、必要なら再検討する。

閲覧サイトの実装方針（決着） ​

  • 既存のVitePress docsサイトとの関係 — 分離する。VitePress docsは開発者・企画側の仕様書として現状のまま維持し、カードモチーフの閲覧体験は別の新規フロントエンドとして構築する。odyssageもdocs/（Astro製ドキュメントサイト）とapps/frontend（React製アプリ）を分離しており、「仕様書」と「プロダクト」は性質・更新頻度・読者が異なるため分けた方が保守しやすい。
  • フロントエンドフレームワーク — React。類似コンセプトの別プロジェクト（odyssage・echo-500）と同じ選択で、ユーザー自身が最も習熟しているスタックであり学習コストも低い。

この章の設計原則 ​

  1. いきなり全部作らず、閲覧サイト→セッション管理システムの順で段階的に進める。
  2. 実装言語はTypeScriptで統一し、決定性より人間の裁量を優先するゲームデザインの方針と揃える。
  3. クラウドはAWS＋CDKを選び、学習目的とコスト最小化のバランスを取る（コストが嵩む部分は代替サービス〈Neon〉を使ってよい）。
  4. 設計仕様書（VitePress）とプロダクト（閲覧サイト・将来のアプリケーション）は分離する。
  5. グラフ構造は、必要性が具体化するまで専用グラフDBを導入せず、RDB上で表現する。

将来の拡張候補 ​

  • セッション管理システムのバックエンド構成（Lambda／ECS等）の具体的な選定
  • Neonの無料枠を超えた場合の代替・移行先の検討
  • 専用グラフDB（Neptune等）の要否の再検討（データ規模・クエリパターンが具体化した時点で）