スタッフ — リギア申請の確認 + 承認 / 却下

メンバーは #Request Regear でリギアを申請し、その結果がすべてこの #Review Requests に届き、スタッフが仕分けます。このページでは確認キューを端から端まで案内します。

権限

このチャンネルを表示して申請に対してアクションするには、Approve Regear Requests 権限(ロール編集 → 権限 の Regear セクション)が必要です。ほとんどのギルドはこれを Regear Staff / Regear Manager / Manager のプリセットに付与しています。完全な一覧は 権限リファレンス を参照してください。

確認キュー

サイドバーの REGEAR TEAM セクションから #Review Requests を開きます。

ページ上部:

• タブ — Pending / Approved / Rejected。Pending が作業キュー、他2つは監査用ビューです。
• ツールバー(Pendingタブ):
  • Select all チェックボックス — 複数選択での一括アクション用。
  • Type フィルター — All / Deaths / Overcharge。
  • War Role フィルター — 特定のウォーロールの申請に絞り込み(CTAで特定のロールが多いときに便利)。
  • Search — 被害者の名前 または #event_id（9桁の Albion イベント ID に # を付けたもの、例：#475568182）を受け付けます。イベント ID は Albion のデスフィードとイベントリンク URL が使う番号と同じです。メンバーが Discord でキルリンクを送って「これ通った？」と聞いてきたとき、末尾の数字をコピーして # を付けて貼り付ければ、キューがその行だけに絞り込まれます。同じ #event_id 検索は #Cut-off Tasks でも使えるため、レビューキューからパッカー側まで一件の死亡を追跡できます。

キュー上の各カードは1件の申請です。

• 上部行 — メンバー名 + キャラクター + ウォーロールバッジ(スクリーンショットの Outcomers / FreezDawnera / Riderr)。
• 中央 — 死亡イベントリンク(eventID)と、失ったアイテムをスロットごとの検証バッジ付きで表示する3×4装備グリッド:
  • 🟢 OK — スロットはロールのロードアウトと期待ティアで一致。
  • 🟡 ティア不足 — アイテムのティアがロールの要求より低い。
  • 🔵 ティア超過 — アイテムのティアが高い。
  • 🔴 無効 — アイテムがロールのロードアウトに含まれない。
• 下部行 — アクションボタン + メタデータ(UTC死亡タイムスタンプ + フェイム)。

申請ごとの3つのアクション

✅ 承認

申請を承認します。次に何が起こるかはギルドの リギアモード によります。

• アイテムモード — 申請は approved 状態に移行し、緑色ボタンのラベルは カットオフタスクを作成(単件 + 一括)になります。クリックすると #Cut-off Tasks の梱包タスクに束ねられます。アイテムモード — カットオフ + ロッカー を参照。
• silverモード — 申請は approved 状態に移行し、緑色ボタンのラベルは 支払い(単件 + 一括)になります。クリックするとメンバーのsilverバンクウォレットにsilverが入金されます。silverモード — silverバンクからの支払い を参照。

承認アクションは同じですが、ギルドの設定によって第2ステップのボタンが変わります。承認と実際のお金/アイテムの動きの間に意図的な隙間があります — 下の 2段階ライフサイクル を参照してください。

❌ 却下

申請をきっぱり却下します。理由のプロンプトが開くので、理由を入力(例:「ウォーロール違い — このCTAに割り当てられていない」)して確定します。メンバーは却下と理由を #My Requests で確認します。

却下されると、申請は終端状態です — キューには戻ってきません。メンバーが異議を唱える場合は、正しい情報で新規申請ができます。

📁 アーカイブ

申請を承認も却下もせずに Pending キューから取り除き、Archived ビューに移動します。重複申請、もはや対処不能な古い申請、決断せずに隠したい申請があるときに使います。

検証ポリシーのゲート

ティア不足 / ティア超過 / 無効の問題に対してバリデーターが何をするかは、ギルドの リギアポリシー(設定 → リギアポリシー)が決めます。3つのポリシースロットがあり、それぞれ独立して次のいずれかに設定します。

• 自動却下 — 申請は送信時に却下され、このキューに届きません。
• 許可 — 問題は記録されますが、Submitボタンがメンバーをブロックすることはありません。
• スタッフ判断(デフォルト) — 申請がキューに届き、スタッフが問題を見て申請ごとに判断します。

ギルドが無効スロットに「スタッフ判断」を使っている場合、🔴 バッジが付いた申請でも依然として判断を求められます。スロットごとの情報は、承認(許す)/ 却下(拒む)/ 承認時の上書き(装備に合った別のウォーロールを選ぶ)のどれにするかを決めるのに役立ちます。

承認時のウォーロール上書き

申請カード上部のウォーロールバッジをクリックすると、その申請のウォーロールを変更できます。新しいロールのロードアウトに対して検証が再実行されます — 次の場合に便利です。

• メンバーが申請時にウォーロールを選び間違えた。
• 失った装備が実際には別のロールのロードアウトに一致する(例:ホーリーヒーラーがライフカースを担当)。
• 別のsilver上限を適用したい(ウォーロール — 実額キャップ モードでは、選んだロールの上限が支払い時に適用されます)。

上書きは監査ログに記録され、透明性が保たれます。

複数選択の一括アクション

Select all チェックボックス(またはカードごとのチェックボックス)にチェックを入れると、ツールバーに一括の 承認 / 却下 / アーカイブ ボタンが表示されます。

• 一括承認 — N件の申請を1回で承認します。各申請は引き続きモード別ロジックを通ります — アイテムモードでは申請ごとに1つのカットオフタスクが作成され(束ねられません)、silverモードでは1件ずつ次々に支払いがされますが、1回のバッチアクションとして扱われます。
• 一括却下 — 理由のプロンプトが開き、同じ理由が選択行すべてに適用されます。明白な違反(「これら全部がウォーロールチェックで失敗」)に使います。
• 一括アーカイブ — 選択した行をすべてPendingから移動させます。プロンプトなし。

2段階ライフサイクル

承認と配送が別々のクリックである理由:

• silverは実通貨である。 承認 = 「はい、これは正当な請求です」。支払い = 「はい、silverを動かします」。Stripe / 給与計算 / PayPal はいずれもこの2つを分離しています。
• 取消の余裕。 承認と支払いの間に誤りに気づけば、お金が動く前にその行を却下できます。差額調整の元帳エントリは不要です。
• 給料日のバッチング。 スタッフは1週間分の承認済みを溜め、給料日に一括で支払えます — 1件の監査ログエントリ、1件のDiscord通知で済みます。
• モード非依存のPending。 Pending申請はギルドの現在のモードを気にしません。ギルドがモードを切り替えても(アイテム → silver)、Pending申請は移行不要 — 承認時に新しいモードに従います。

アイテムモードでは束ねるステップがさらに明確です:承認 → 申請が待機 → カットオフタスクに束ねる → 梱包担当が作業。カットオフタスクが実際の受け渡しで、承認は単なる青信号です。

メンバーに見えること

申請に対してアクションすると、メンバーは #My Requests(個人のトラッカー)で更新を見ます。

• 承認済み → 進行ストリップが5段階中2段階目に進む。
• 却下 → 行が赤くなり、理由が表示される。
• アーカイブ → メンバーのPendingビューから行が消える。

その後、進行ストリップはカットオフタスク / 支払いフローの進行に応じて続きます。メンバー側の詳細は メンバー — リギアを申請する を参照。

関連ページ

• リギアパイプライン概要 — モード + 分岐の説明
• メンバー — リギアを申請する — 上流の申請フロー
• アイテムモード — カットオフ + ロッカー — アイテムモードの承認後の流れ
• silverモード — silverバンクからの支払い — silverモードの承認後の流れ
• 設定 — リギアポリシー — 検証ポリシー + モード選択
• メンバーリギアレポート — メンバーごとの監査ビュー