【4/23】GW特別キャンペーン #4616

概要

仕様書

クエスト処理をslot_campaign_questとして新規実装
交換所はガチャ交換所（limited_trade_shop）を使用
使用するにあたってカード以外の交換対応、交換制限を追加

各種ガイドライン

• doc/codex/codex-implementation-guidelines.md
• doc/slot_campaign_quest/ai-guidelines.md
• doc/slot_campaign_quest/review-guide.md

テーブル更新クエリ

• database/migrate/2026033002_add_slot_campaign_quest_tables.sql
• database/migrate/2026041401_add_user_limited_trade_shop_lineup_exchange_count.sql
• database/migrate/2026042702_create_log_slot_campaign_quest_logs.sql

関連PR

【4/23】GW特別キャンペーン jolly/jrye-db#1391
【4/23】期間限定名誉 #4613
【4/23】GW特別キャンペーンカード・アイテム #4615

テスト方法、確認した内容

テスト

①関連PR(web,db)をマージ
②テーブル更新クエリを実行
③db更新内容をローカルに反映
④php tests/slot_campaign_quest/run.phpを実行

確認

仕様書「チェックリスト」シートを確認

TODO

• [x] キャンペーンページのデザイン調整
• [x] 交換所ページの画像
• [x] バナーの設置
• [x] クエストの難易度調整
• [x] 告知作成
• [ ] ~~名誉ランキング配布~~ 別PRで対応
• [x] 関連PRのTODO
• [x] PVログ実装
• [x] 砂時計ゲージの説明モーダル実装

リリースTODO

• [x] 告知画像PRデプロイ
• [x] NEWカード・アイテムPRデプロイ
• [x] 期間限定名誉PRデプロイ
• [x] 日付の確認
• [x] masterマージ（web,db）
• [x] js圧縮
• [x] migrationファイル実行
• [x] dbデプロイ
• [x] webデプロイ
• [x] バナー設定
• [x] 告知確認
• [x] 戦闘デモ確認

@wada

報酬ptが加算されず、テストも落ちている

報酬ptの計算が仕様・テストと合っていません。

現在のテストでは、難易度2のクエストを週末に達成した場合、週末倍率3倍で 60pt 加算されることを期待しています。しかし実装は difficulty ではなく master_slot_campaign_quest.reward_point だけを見ており、テストデータでは reward_point が 0 のため、実際には 0pt のままです。

そのため `php tests/slot_campaign_quest/run.php` は `expected=60 actual=0` で失敗しています。reward_point を正とするのか、difficulty から算出するのか、仕様を揃えた上で実装とテストを修正してください。

報酬受取を連打・同時実行するとptが二重に入る

報酬受取処理で、同じ報酬を二重に受け取れる可能性があります。

send_reward は、スロットが「報酬受取待ち」か確認した後、先にptを加算し、その後でスロットをクールタイム状態に更新しています。更新時に「まだ報酬受取待ちであること」を条件にしていないため、同じ報酬受取リクエストがほぼ同時に2回届くと、両方が受取可能と判断してptを2回加算できます。

報酬加算前に、`status = STATUS_REWARD` を条件にして1件だけ状態更新できた場合のみpt加算する形にしてください。

時短ストックを同時に使うと、片方の消費がなかったことになる

時短ストックの消費処理で、同時実行時に消費量がずれる可能性があります。

現在は stock_time を読み出して、使用後の残り時間を計算し、その残り時間をそのまま保存しています。例えば stock_time が2時間ある状態で、同時に1時間短縮を2回実行すると、どちらも「2時間ある」と見て「残り1時間」と保存します。その結果、本来は0時間になるべきところが1時間残り、1回分の消費が消えてしまいます。

`stock_time = stock_time - 使用量` のような減算更新にし、かつ `stock_time >= 使用量` を条件にして、更新成功時だけ短縮成功とする必要があります。

交換所の複数個交換で、素材数以上に交換できる可能性がある

LimitedTradeShop の複数個交換で、同時実行時に交換素材を不足状態まで使えてしまう可能性があります。

処理は、現在の素材数を読んで足りるか確認した後、交換上限を更新し、最後に素材数を減らしています。ただし素材を減らす更新に「まだ必要数以上残っていること」という条件がありません。

例えば素材が10個、1回の交換に10個必要な状態で、同時に2リクエスト来ると、両方が「10個ある」と判断して交換処理に進めます。結果として報酬付与や交換回数更新が2回進む可能性があります。

素材減算も `item_count >= need_price` を条件にした更新にし、更新成功件数で交換可否を判定してください。

ランキング表示用のindexが足りない

ランキング用のindexが不足しています。

ランキング取得では、campaign_no で絞り込み、total_point の降順、user_no の昇順で並べています。しかし migration では PRIMARY KEY が campaign_no,user_no のみで、total_point 順に取得するためのindexがありません。

参加者が増えると、ランキング一覧や自分の順位計算で campaign 内のデータを広く走査し、filesort が発生しやすくなります。`campaign_no, total_point, user_no` に沿ったindexを追加してください。

枠4/5で「同じ難易度を連続しない」条件が破られる

枠4/5のクエスト再抽選で、「直前と同じ難易度を避ける」条件が完全には守られていません。

実装では、直前と同じ difficulty のクエストを候補から除外していますが、除外後の候補が0件になると、元の候補リストに戻しています。そのため、公開中の候補が同じ difficulty しかない場合、枠4/5でも同じ難易度が連続して設定されます。

review-guide の「枠4,5は直前と同難易度を連続設定しない」を厳密に満たすなら、候補なしとして扱うか、master データ不足として検出する必要があります。

テストの商品IDが現行実装とずれている

ModelTest の課金枠商品IDが、現行実装と一致していません。

現在の実装では、課金枠解放の商品IDは 1枠目が 10383/10385、2枠目が 10384/10386 です。一方、ModelTest は 10377/10380 などを期待しています。

現時点では報酬ptのテスト失敗で途中停止しているため、この不整合はまだ表に出ていません。しかし報酬ptの問題を直すと、次にこの商品ID不一致でテストが失敗します。テスト側の期待値を現行の商品IDに合わせる必要があります。

@wada
確認OKです

@kouho
以下追加で対応しました。

web

• configのCP名を修正
• 未使用のアイテム画像（337.jpg）削除
• 交換所ポイント画像を角丸
• CPページの右上告知リンク修正

db

• 交換所終了日をCP終了日+2日に更新
• 交換所に転生の書追加
• 交換所必要ポイントを調整

@wada
確認OKです

@wada
実ファイル名とajax側の記載と一致していませんでした。Rの大文字小文字 slotCampaignQuest_RefreshSlot.inc

@wada
$user_infoはglobal変数定義していないように見えます。
$user_info['user_no']　→　$this->_user_no　が正かと

@wada
今回ミッションの中には青玉関係は含まれないように見えますが、仕様変更の中での名残でしょうか。仕込みとして残しておきますか？