</>
パチスロ設定最適化システム
技術レビュー資料
pachislot-settings — SE確認用
2026.03.29 | AI経営共創パートナーズ株式会社
AGENDA 2
確認いただきたいポイント
1 システム概要 構成・規模・技術スタック 2 アーキテクチャ 3層構成・API・DB設計 3 ビジネスロジック 最適化・AI連携 4 認証・認可 JWT・RBAC・マルチテナント 5 セキュリティ 入力検証・レート制限 6 テスト・品質 カバレッジ・テスト構成 7 デプロイ・インフラ Docker・Railway・環境変数 8 運用・保守体制 Claude Codeベース ? 抜け漏れ確認 ご指摘をお願いします
SYSTEM OVERVIEW 3
小規模・フルスタック構成で運用中
1,412
Frontend (TypeScript行)
~2,500
Backend (Python行)
2,610
テストコード (行)
~75%
テストカバレッジ
レイヤー技術バージョン用途
FrontendReact + TypeScript + TailwindReact 19 / Vite 8SPA(3画面)
BackendFastAPI + PythonPython 3.12 / FastAPI 0.115REST API(6ルーター)
DBPostgreSQL / SQLitepsycopg2マルチテナントデータ
AIAnthropic Claude APISonnet 4設定最適化・対話調整
InfraRailway (PaaS)Docker 2段ビルド本番ホスティング
ARCHITECTURE 4
3層アーキテクチャ + AI連携
Frontend React 19 + Zustand + Axios + TanStack Table LoginPage Optimizer AdminPage REST API Backend (FastAPI) auth optimization admin decisions data-import core: scoring allocator smart_optim ai_analyzer csv_loader SQL Database PostgreSQL (本番) / SQLite (開発) users stores raw_data decisions tokens companies Claude Sonnet 4 Anthropic API プロファイル選択 + 対話調整 Railway (PaaS) Docker + PostgreSQL + HTTPS
API ENDPOINTS 5
6ルーター・17エンドポイント
ルーターMethodエンドポイント認可概要
/authPOST/loginなしJWT発行(レート制限: 5回/5分)
POST/refreshなしトークン更新
POST/logoutBearerリフレッシュトークン失効
GET/meBearerユーザー情報取得
/optimizationPOST/runBearer+店舗CSV+目標利益 → 設定最適化
POST/ai-adjustBearerAI対話で設定調整
POST/apply-changesBearer手動変更の利益再計算
/adminGET/POST/companiessystem_admin会社CRUD
GET/POST/storesadmin系店舗CRUD
GET/POST/DEL/usersadmin系ユーザーCRUD
/decisionsPOST/Bearer意思決定記録の保存
GET/{store_id}/{date}Bearer日別記録取得
GET/summariesBearer日次集計(30日)
/data-importPOST/GET/upload, /summaryadmin系CSV取込・サマリ表示
/healthzGET/healthzなしDB接続確認
DATABASE SCHEMA 6
7テーブル・マルチテナント設計
companies id, name, created_at PK: id stores id, company_id, name FK: company_id UQ: (company_id, name) users id, username, password_hash role, company_id, store_id role: system/company/store raw_data store_id, date, machine_no in/out/diff_medals, sales bonus_count, utilization UQ: (store_id, date, machine_no) decisions ai_setting, final_setting target/expected/actual_profit prediction_error Phase C: 学習用データ蓄積 daily_summary 日次集計(利益・設定・台数) refresh_tokens user_id, token_hash expires_at, revoked_at FK: user_id テナント分離 全データテーブルは store_id で分離 API層でユーザーの所属店舗を検証
BUSINESS LOGIC 7
CSV → 統計 → スコア → 4プロファイル最適化 → AI調整
最適化パイプラインの処理フロー
1 CSV取込 9列必須 カラム変換 2 統計計算 30日ローリング 稼働率/トレンド 3 スコア算出 5因子加重平均 台別順位 4 4プロファイル balanced showcase recovery stable 5 AI選択 Claude Sonnet 4 最適プロファイル スコア算出式: 稼働率x0.30 + トレンドx0.25 + 機種人気x0.15 + 個体偏差x0.15 + ボーナス率x0.15 高スコア台 = 低設定(利益回収) / 低スコア台 = 高設定(集客) 利益予測: Profit = IN枚数 x (1 - 出玉率/100) x 稼働率/100 x メダル単価(20円) レンジ: 10th/90thパーセンタイルで楽観・悲観シナリオを算出
AUTHENTICATION & SECURITY 8
JWT + bcrypt + 3層RBAC

認証フロー

  • ログイン: bcrypt検証 → JWT(HS256)発行
  • Access Token: 有効期限30分
  • Refresh Token: 有効期限7日(DBハッシュ保存)
  • 自動更新: Axios interceptorで透過的
  • ログアウト: revoked_atを更新
  • ロックアウト: 5回失敗で5分間ロック

認可モデル (RBAC)

ロールスコープ権限
system_admin全社全CRUD
company_admin自社店舗・ユーザー管理
store_user自店舗最適化・閲覧
店舗アクセス制御: APIリクエスト毎にstore_id所属チェック
セキュリティ項目実装状況備考
パスワードハッシュbcrypt 10rounds定数時間比較
SQLインジェクションパラメータクエリ全クエリ対応済み
入力検証PydanticFastAPI自動バリデーション
CORSホワイトリスト許可オリジン設定済み
レート制限インメモリ再起動でリセット
JWT署名HS256RS256推奨
TESTING & QUALITY 9
テストコード2,610行・カバレッジ約75%
カテゴリ行数カバレッジ
API テスト6件~800~80%
auth, optimization, admin, decisions, data-import, health
Core テスト8件~1,600~85%
scoring, allocator, profit, optimization, config, csv, decision, models
Unit テスト2件~200~70%
auth_service, middleware

テスト環境

  • フレームワーク: pytest + pytest-asyncio
  • HTTP: httpx (TestClient)
  • DB: SQLite in-memory
  • AI: モック(実API呼出なし)
  • Lint: ruff (Python)

不足しているテスト

  • フロントエンドE2Eテスト
  • 負荷テスト(同時接続)
  • PostgreSQL統合テスト
  • AI応答の結合テスト
DEPLOYMENT 10
Docker 2段ビルド → Railway PaaS
Dockerfile (2-stage) Stage 1: Frontend Build FROM node:20-alpine npm ci && npm run build output: /frontend/dist/ Stage 2: Backend + SPA FROM python:3.12-slim pip install + COPY backend COPY --from=stage1 ./static Railway PostgreSQL (マネージド) HTTPS自動 + ドメイン 障害時自動再起動(max10)
環境変数用途備考
DATABASE_URLDB接続文字列Railway PostgreSQLが自動設定
SECRET_KEYJWT署名鍵ランダム文字列を設定
ADMIN_PASSWORD初期管理者PW初回シード用
ANTHROPIC_API_KEYClaude APIAI機能に必須
OPERATIONS & MAINTENANCE 11
Claude Codeベースの保守体制

運用体制

  • 開発・改修: Claude Codeで対応
  • デプロイ: railway up (CLI 1コマンド)
  • 監視: Railway ダッシュボード + ログ
  • DB: Railway PostgreSQL(自動バックアップ)
  • SE引き継ぎ: 不要(現状規模)

規模感

  • FE 1,400行 + BE 2,500行 = 全体把握可能
  • 横展開・API連携もClaude Codeで対応可
  • PaaS利用のためインフラ管理不要
  • テスト自動化済みでデグレ防止
運用項目方式頻度担当
機能追加・バグ修正Claude Code + git push随時高木
デプロイrailway up --detach変更時高木
DB バックアップRailway自動日次自動
ログ確認Railway Dashboard随時高木
SSL証明書Railway自動更新自動自動
config.yaml更新機種追加・出玉率変更月1程度高木
REVIEW REQUEST 12
本システムはAI(Claude Code)で設計・実装しました
SEの視点で「本番稼働してよいか」をご判断ください
お願いしたいこと
設計・実装・テスト・デプロイの全工程をAI(Claude Code)が担当しました。
人間のエンジニアによるレビューを経ていないため、プロのSEの目で検証いただき、
「この状態で本番稼働してよいか」のGo/NoGo判断
をお願いします。

運用前提

  • 利用者: キクヤ(パチスロホール)1店舗・3〜5名
  • 利用頻度: 1日1回、朝の設定変更時に使用
  • データ量: 1日あたり数十台 x 1レコード
  • 可用性: 業務時間中に使えればよい(24/365不要)
  • 保守: Claude Codeで開発者が直接対応
  • 機密性: 店舗の営業データ(売上・稼働率)を扱う

ご回答いただきたい形式

  • Stop: 本番稼働すべきでない致命的問題
  • Fix before launch: 稼働前に直すべき問題
  • Nice to have: 将来的に改善すべき点
  • Go: この状態で稼働してよい
資料に記載のアーキテクチャ・API・DB・認証・
セキュリティ・テストの各項目について、
上記4段階でご評価ください。