Description
opened by noda at 2026-05-14T21:25:06; updated 2026-05-28T14:19:39
概要
仕様書
DB側更新
jolly/jrye-db#1418
目的:
・ 秘宝案採用者へのお礼対応を、既存スクリプト内の配布対象配列を更新して実行する運用に変更
・ 名誉配布も当プルリクに含める
本番環境での実行
1. 採用者へのメッセージ送信・紅玉リカバリ配布
Dry-run:
ENVIRONMENT=production PF=yamada php lib/exec/tool_area_item_request_reward.inc
実行:
ENVIRONMENT=production PF=yamada php lib/exec/tool_area_item_request_reward.inc --execute
処理内容:
sendmail に採用お礼メッセージを追加
S_SetUserPresentArray() で 紅玉リカバリ(item_no=1) を1個配布
同じユーザーの複数採用は、採用ごとにメッセージとプレゼントを1件ずつ作成
2. 採用者への名誉配布
Dry-run は debug_flg = 1 のまま実行します。
ENVIRONMENT=production PF=yamada php lib/exec/honor_area_item_present.inc```
実配布時のみ debug_flg = 0 に変更して実行
実行後は必ず debug_flg = 1 に戻す
### TODO
- [ ] デプロイ(秘宝データ追加含む)
- [ ] メッセージ送信・紅玉リカバリ配布
- [ ] 名誉配布
### メモ
秘宝選定基準について
名誉の追加により課金額が多いユーザーが選定されがちのため偏っており、既に最高ランクを獲得している人がいる
そのため、次回以降の選定基準は課金額を除いた
・アクティブ
・秘宝数の少ない地域
を優先する
Comment
#46021 by noda at 2026-05-15T09:09:34; updated 2026-05-15T09:09:34
Comment
#46029 by kouho at 2026-05-15T10:59:43; updated 2026-05-15T11:00:57
@noda
ローカルからトンネルを通して本番DB Slaveに接続できる方式は、
「本番で実行するコマンドやスクリプトは本番環境上でのみ実行する」
という保守運用の考え方に反しており、将来的な事故を誘発する可能性があると思います。
今回の実装では read-only 制限などチェックを多重に入れているため、
直ちに問題が起きる可能性は低い設計だとは理解しています。
ただ、コード側のチェックに安全性を依存させること自体に危険性があると思います。
今回の変更は 実質的には運用ルールの変更 にあたると考えています。
同じ流れでローカルから本番系DBへ到達できる経路を作ることを許容するため、
将来的に接続先や権限、実行SQLの前提が変わった場合、AIや自動化ツールが想定外のSQLを実行して本番データに影響を与える、といった事故につながる恐れがあります。
そのため、抽出SQLや集計ロジックはリポジトリ管理しつつ、
抽出スクリプト自体は本番にデプロイしたものを本番環境上で実行し、
実行結果だけをローカルに持ってくる形にする方が適切だと思います。
kouho add_label at 2026-05-15T10:59:49: 皇甫 LGTM
kouho delete_label at 2026-05-15T11:01:16: 皇甫 LGTM
kouho add_label at 2026-05-15T11:01:18: コメントあり
Comment
#46034 by kouho at 2026-05-15T11:56:58; updated 2026-05-15T11:56:58
@noda
【候補選出sqlについて】
user_area_item_request.adopted_item_no に選出済み秘宝のarea_item_noが入っている前提のsqlですが、本番のuser_area_item_request.adopted_item_no が全て0なので秘宝シートを元にデータの更新が必要に見えます
Comment
#46048 by kouho at 2026-05-15T14:37:45; updated 2026-05-15T14:37:45
@noda
shortlist CSV は機械的な優先順位であり、そのまま確定ではないと記載されていますが、
レビュー用マークダウンを出力し、Codexへの依頼テンプレートでは、shortlist の生成後に以下まで一括で作成する流れになっているように見えます。
- master_area_item 追加用INSERT SQL
- 採用者へのsendmail INSERT SQL
- $rewards 更新
- $reg_area_item 更新
- お知らせ掲載用HTML
これらは採用対象が確定した後に作るべき成果物だと思います。
shortlist CSV の出力結果を人間が確認し、採用対象・item_name・item_type・item_text を確定した後、その確定結果を元に以降の成果物を作成する流れに分けられないでしょうか。
Comment
#46142 by noda at 2026-05-22T10:27:55; updated 2026-05-22T10:27:55
kouho delete_label at 2026-05-22T16:59:19: コメントあり
kouho add_label at 2026-05-22T16:59:22: 皇甫 LGTM
Comment
#46164 by kouho at 2026-05-22T17:02:19; updated 2026-05-22T17:02:19
@noda
以下は、亀井さん的には問題とのことでしたので今後の運用ルール上問題なければ確認OKです。
> ローカルからトンネルを通して本番DB Slaveに接続できる方式は、
Comment
#46165 by wada at 2026-05-22T17:19:50; updated 2026-05-22T17:19:50
@noda
次回対応分はPRに含めないか、今回追加分だけのPRを作成してください。
> 次回対応時に更新します。
wada add_label at 2026-05-22T17:19:55: コメントあり
noda change_title at 2026-05-25T11:32:28: 【5/22】秘宝追加_codexで自動化
【5/22】秘宝追加_メッセ送信・お礼配布スクリプトと名誉配布
Comment
#46179 by noda at 2026-05-25T11:36:03; updated 2026-05-25T11:36:03
@wada
codexは更新から省きました。
・メッセ送信・お礼配布
・名誉配布
のみになっています。
再度レビューをお願いします。
Comment
#46198 by wada at 2026-05-25T14:52:27; updated 2026-05-25T14:52:27
wada delete_label at 2026-05-25T14:52:31: コメントあり
wada add_label at 2026-05-25T14:52:32: 和田 LGTM
noda merge at 2026-05-28T14:19:33: 【5/22】秘宝追加_メッセ送信・お礼配布スクリプトと名誉配布
noda close at 2026-05-28T14:19:33: Close
noda delete_branch at 2026-05-28T14:19:39: new_area_item_0528