SHIFT AI Discord連携設計 まとめサイト
Project Summary

SHIFT AI の Discord参加導線を
「会員サイト主導」に再設計するための整理

現行の「Discord参加 → メールアドレス入力 → 翌日照合」方式から、 「会員サイトにログイン → Discord連携 → 参加 → 自動ロール付与」方式へ移行するための、 ここまでの壁打ち内容をカテゴリ別に整理したサイトです。

# 会員様向け導線 # 開発仕様の前提 # 運営変更点 # 懸念事項 # 確認事項 # テスト設計

現在の大枠結論

Overview

1. 全体概要

このプロジェクトで変わる本質は、「Discord参加手順」ではなく、会員認証の主導権が Discord / エルメ から 新会員サイト へ移ることです。

旧
現行方式
Discord参加 → メール送信 → 翌日照合 → ロール調整
新
新方式
会員サイト → Discord連携 → 参加 → 自動ロール付与
可
技術的に可能
OAuth2 / Discord ID保存 / 招待リンク発行 / ロール操作
要
運用設計
管理画面 / ステータス別処理 / テスト / CS更新

現時点でほぼ確定していること

  • 共通招待リンクは廃止できる。
  • 既存会員の Discord ID は基本そのまま移行する想定。
  • 退会・休会・決済失敗の扱いは分ける。
  • セットアップガイド・LP・Bot回答・CSテンプレは更新する。
  • テスト設計は必須。

この変更で減らしたい課題

  • メールアドレス入力ミス
  • アドレス不一致対応
  • 「送信前で止まる」離脱
  • New User滞留や謎アカウント対応
  • CS / Discordチームの手動確認工数
Member

2. 会員様向けの体験

理想は「会員様が会員サイトでボタンを押すだけ」に近づけることです。初回のみ Discord 認証が必要ですが、従来のメールアドレス送信作業は原則不要になります。

初回参加時の想定フロー

① 会員サイトにログイン
→
② 「Discordに参加する」を押す
→
③ 初回のみ Discord認証
→
④ 参加リンク表示 / 参加
→
⑤ 自動で会員ロール付与

会員様にとって楽になる点

  • Discord内でメールアドレスを送る必要がなくなる。
  • 翌日照合待ちの不安が減る。
  • 「会員情報確認中」のやり取りが大幅に減る。
  • 導線の主役が会員サイトになるので迷いにくい。

会員様に残る操作

  • 初回の Discord 認証
  • Discordへログインしていない場合のログイン
  • 必要に応じた再招待リンクの再取得

退会後の会員様の作業

基本的に会員様の追加作業は不要です。システム側で会員ステータスを検知し、会員ロール剥奪 → 追放（または場合によってはBAN）を実施する想定です。

共通招待リンクを廃止できる前提なので、通常退会者は将来的に 追放 で足りる可能性が高いです。規約違反や荒らしは別で BAN 管理にするのが安全です。
Developer

3. 開発者向けの技術前提

技術的にはかなり実現可能です。重要なのは、「招待リンクを踏んだら即ロール付与」ではなく、参加後に Discord ID を照合してから会員ロールを付けることです。

項目 技術可否 補足
Discord OAuth2でDiscord ID取得 可能 会員サイト側で連携済み
新会員サイトにDiscord ID保存 可能 会員情報との紐づけが中核
個別招待リンク自動発行 可能 1回限り・期限付きに寄せる
max_uses / max_age 制御 可能 max_uses=1, max_age指定で実装
Botによるロール付与・剥奪・追放・BAN 可能 権限とロール階層設計が必要
退会ステータス検知 可能 Webhook または 定期バッチ

安全なロール付与の考え方

  • 会員サイトで Discord OAuth2 連携
  • Discord ID を会員サイトDBへ保存
  • 1回限り・期限付き招待リンクを発行
  • 参加イベントで入ってきた Discord ID を取得
  • DBの Discord ID と一致したら会員ロール付与

やってはいけない設計

  • 招待リンクを踏んだだけで会員ロール付与
  • 誰でも Discord ID 連携解除できる
  • 規約違反BANと通常退会を同じ復帰フローにする
  • 管理ログを残さない
重要：「個別招待リンク」は厳密には本人専用ではなく、1回限り・期限付きリンクです。本人以外が先に使う可能性があるため、参加後Discord ID照合が必須です。
Admin

4. 会員サイト管理画面に持たせたいもの

ここがまだ未確定の大きな論点です。最優先は、CSとDiscordチームが問い合わせ対応で困らない最低限の検索・状態確認機能です。

最低限ほしい表示項目

  • 会員ID
  • 氏名
  • メールアドレス
  • Discord ID
  • Discordユーザー名
  • 会員ステータス

状態確認項目

  • Discord連携状態
  • Discord参加状態
  • 会員ロール付与状態
  • 最終連携日時
  • 最終参加日時
  • 最終処理ログ

検索できるべきキー

  • メールアドレス
  • 氏名
  • Discord ID
  • Discordユーザー名
  • 会員ID

段階的な実装のすすめ

Phase 1
検索 / 状態確認 / ログ表示
→
Phase 2
招待リンク再発行 / ロール再付与
→
Phase 3
連携解除 / 追放 / BAN / ロール同期
最初からフル機能にしなくてよいです。まずは「検索できる」「状態が見える」「何が起きたかわかる」があれば、マスターシート廃止に近づけます。
Operations

5. SHIFT AI運営内で変更が必要そうなこと

今回の変更は Discord チームだけで完結しません。入学式、LP、セットアップガイド、Q&A、CS、質問Botなど、会員導線まわり全体の修正が必要です。

オンボーディング・案内系

  • 入学式スライド
  • 入学式当日の説明台本
  • 3日前 / 1日前 / 当日リマインド
  • セットアップガイド
  • 旧LP / 案内ページ
  • オリエンテーション動画

問い合わせ・サポート系

  • 会員サイトQ&A
  • AIメンター / 質問系Botの回答
  • CS対応テンプレ
  • Discordチーム用の確認フロー
  • 障害時テンプレ

今後のKPI見直し候補

会員サイトログイン率 Discord連携開始率 Discord認証完了率 招待リンククリック率 Discord参加完了率 会員ロール付与成功率 誤連携問い合わせ数
Status Handling

6. ステータス別の推奨処理

退会・休会・決済失敗・規約違反を同じ扱いにすると事故ります。少なくとも通常退会、休会、決済失敗、規約違反は分けるべきです。

状態 推奨処理 理由 / 補足
通常退会 会員ロール剥奪 + 追放 共通招待リンク廃止前提ならBANまで不要な可能性が高い
休会 会員ロール剥奪、追放は要検討 復帰前提ならロールのみ外す案もあるが、SHIFT AI規模なら追放寄り
決済失敗 即追放は避ける。猶予期間 + 通知 + 段階制限 カード更新漏れや決済遅延による事故を避けるため
再入会 会員サイトから再参加 / 必要なら再連携 通常退会者と規約違反者は復帰フローを分ける
規約違反 / 荒らし / 不正利用 BAN 自動復帰不可
会員情報確認中 移行期の手動確認導線 新方式で縮小予定だが、完全移行までは残す可能性あり
Testing

7. テスト端末・テストケース

今回の導線は、技術的に動くか以上に「初心者が迷わないか」が重要です。特にスマホ、Discord未ログイン、誤アカウント状態を必ず試すべきです。

最低限テストしたい端末・環境

  • iPhone + Safari
  • iPhone + Discordアプリあり
  • iPhone + Discordアプリなし
  • Android + Chrome
  • Windows + Chrome
  • Mac + Safari / Chrome
  • Discordログイン済み / 未ログイン
  • 別Discordアカウントでログイン中

必須で見たいポイント

  • 会員サイトからDiscord認証まで迷わないか
  • 参加リンクから正常に参加できるか
  • 参加後にロールが付くか
  • 誤連携時に誤ロール付与されないか
  • 退会・再入会時の状態遷移が正しいか
No テストケース 確認ポイント
1新規会員が会員サイトからDiscord連携正常に Discord ID 保存 / 参加できるか
2Discord未ログイン状態で連携ログイン導線で迷わないか
3Discordアプリなしで参加Webでも完結できるか
4既にサーバー参加済み会員ロール再付与 / 状態整合が取れるか
5別アカウント誤連携誤ロール付与されないか / エラー導線があるか
6招待リンク期限切れ再発行導線が分かりやすいか
7退会後ロール剥奪 / 追放が正しいか
8再入会後スムーズに再参加できるか
9Bot障害時ロール未付与の検知 / 手動復旧ができるか
10会員サイト障害時代替案内 / 一時停止時の運営判断があるか
Risks

8. 懸念事項・盲点

技術的にできることと、運用として安定することは別です。今の時点で特に危ないポイントを整理しています。

既存会員データ移行の汚れ

  • Discord IDが空欄
  • 同じDiscord IDが複数会員に紐づく
  • 退会済みデータが混ざる
  • 会員情報確認中データの扱い

誤連携 / アカウント変更

  • 違うDiscordアカウントで連携
  • スマホとPCで別アカウント
  • 会員自身が自由変更できる設計の危険性

Bot / 会員サイト障害

  • 参加できたのにロールが付かない
  • 会員サイトが落ちたら導線が止まる
  • 復旧フローがないとCS問い合わせが爆発

ステータス運用の曖昧さ

  • 決済失敗を即追放すると事故る
  • 休会者をどう扱うか未定
  • 通常退会と規約違反BANを混ぜると危険
一番危ないのは「開発できそうだから進める」ことです。既存データの棚卸しと、例外時の運用フローを先に決めないと、リリース後にCSとDiscordチームが詰まります。
Questions

9. まだ詰めたい確認事項

現時点でまだ運営・開発・CSの間で決め切れていない、または整理したい論点です。

運営判断

  • 通常退会者は必ず追放するか
  • 休会者はサーバーに残すか
  • 決済失敗の猶予期間を何日にするか
  • 会員情報確認中ロールをいつまで残すか

データ・システム

  • 既存Discord IDデータの精度確認
  • 管理画面にどこまで機能を持たせるか
  • Webhookで行くか定期バッチで行くか
  • ログ保存範囲と権限設計

サポート・導線

  • 旧LP / 旧導線をどう閉じるか
  • 招待リンク期限切れ時の案内
  • 誤連携時のCS対応文言
  • 障害時の一次案内テンプレ
Next Action

10. 次アクションの優先順位

ここから先は、闇雲にHTMLや実装を増やすより、論点を順に潰した方が早いです。優先順は以下がおすすめです。

1
既存Discord IDデータの棚卸し
→
2
管理画面の最低限要件確定
→
3
退会 / 休会 / 決済失敗の運用定義
→
4
テストケース設計
→
5
ガイド / LP / Bot / CS文面更新

短期でやるべきこと

  • 既存会員データの異常値チェック
  • 管理画面の表示項目を先に決める
  • 通常退会 / 休会 / 決済失敗の処理を確定する

その後にやること

  • 端末別テスト実施
  • 会員向けセットアップガイド更新
  • CS / Bot回答 / FAQの更新
本HTMLは、ここまでの会話内容をもとに整理した壁打ち用サマリーです。今後の判断や実装状況に応じて更新前提のドラフトとして扱ってください。