サービス会員ログイン

最終更新: 2026年7月3日

服屋のショッピングモールサイトを運営していると考えてみてください。お客さまが自分で会員登録をして、会員だけがレビューを書いたりランク別の特典を受けられるようにしたいときがあります。そのためには「お客さまが自分で登録してログインする会員システム」が必要です。この会員システムを自分のサイトに組み込んでくれる Space の機能が ServiceLogin(自分のサービスにお客さまが直接登録して使うログイン設定)です。

ServiceLogin を有効にすると、お客さまは Google などのソーシャルアカウントで誰でも自分で登録できます。登録したお客さま一人ひとりが ServiceUser(自分のサービスに登録した会員)になります。ログインの手続きとログイン状態の維持は WEEGLOO が代わりに処理するため、パスワードを自分で保管したり、ソーシャルログインを一から作ったりする必要はありません。

このページでは ServiceLogin が何であり、運営チームのアカウントとどう違うのかをまず見たうえで、服屋の Space で ServiceLogin を実際に有効にして設定してみます。

会員は運営チームとは違います

WEEGLOO にはログインする人が二種類います。混同しやすいので、まず境界を引いておきます。

  • 運営チーム/スタッフは商品を登録し、サイトを管理する人です。お客さまのように ServiceLogin で登録するのではなく、WEEGLOO アカウントでこの Space のメンバーになって(すでに中にいる人からの招待とロールの付与によって)入ります。運営チームの権限はロールと権限で扱います。
  • ServiceUser はそのサイトを使うお客さま/会員です。自分が運営する服屋サイトでソーシャルアカウントを使って直接登録した人です。運営チームとはまったく別のログインです。

ひとことで言えば、運営チームは「お店を切り盛りする人」、ServiceUser は「お店に訪れたお客さま」です。ServiceLogin は、このお客さまたちが出入りする入口を作る作業です。

一緒に動く三つのもの

会員システムは三つのものがかみ合って動きます。

  • ServiceLogin: ログイン設定そのものです。どのソーシャルログインを使うか、登録した会員にどの権限を初期値として与えるかといったことをここで決めます。
  • ServiceUserRole: 会員に与える権限のまとまりです。会員が何を見られて何を書けるかを定めておきます。
  • ServiceUser: 登録した会員一人ひとりです。お客さまが登録するたびに一つずつ作られます。

このページは入口を開ける ServiceLogin の設定に集中します。会員が実際に何を見て使えるか(権限)を定める ServiceUserRole は会員のロールと権限で別途扱います。下の設定で選ぶ Default Role が、まさにそのページで作るロールです。

ServiceLogin を有効にする

服屋の Space で会員ログインを有効にしてみます。

会員ログインの設定は 1 つの Space に 1 つだけあります。複数を新しく作るのではなく、この 1 つを有効にしておき、必要なときに直しながら使います。

ServiceLogin は最初は無効になっています。設定画面を開くと「ServiceLogin is disabled」という案内とともに Activate ボタンが表示されます。案内には「Activate ServiceLogin to enable social login (Google, etc.) on your site. Weegloo handles OAuth and sessions for you.」と書かれています。

  1. 左メニューで サービス を開き、ServiceLogin を押してください。
  2. 基本情報 画面で Activate ボタンを押してください。

ServiceLogin がまだ有効になっていない状態。「ServiceLogin is disabled」という案内と Activate ボタンが表示されています

Activate を押すと設定フォームが開きます。このフォームでソーシャルログインを一つ以上有効にして 保存 しなければ、会員ログインは実際には動作しません。

設定フォームを埋める

設定フォームは基本情報とソーシャルログイン設定に分かれています。まず基本情報を埋めます。

項目何を書くか
Service nameログインするときにお客さまに表示されるサービス名です。服屋なら店名を書きます。
Contact emailログインに問題が起きたとき(例: 登録できる人数がいっぱいになったとき)にお客さまに見せる連絡先です。
Callback URIお客さまがログインを終えたあとに戻る、自分のサイトのアドレスです。
Default Role新しく登録したお客さまに自動的に与えられる権限のまとまりです。隣の Manage Roles を押すと、権限を作る画面に移ります。
  1. Service name に、お客さまに見せる名前を入力してください。服屋なら ぬくもりクローゼット のように店名を書きます。
  2. Contact email に、問い合わせを受けるアドレスを入力してください。例: help@nukumori-closet.com。
  3. Callback URI に、ログイン後にお客さまが戻る自分のサイトのアドレスを入力してください。例: https://nukumori-closet.com/auth/callback。
  4. Default Role で、新しい会員に与える権限を選んでください。まだ作った権限がなければ、隣の Manage Roles で先に作ってから戻ってきてください。

Default Role に何を選べばよいか、会員にどの権限を与えるかは会員のロールと権限で扱います。

登録を受け付ける前に運営チームが一度確認したい場合は、新規サインアップに admin の承認を必須にする を有効にしておくことができます。このオプションを有効にすると、新しく登録したお客さまはすぐにはログインできず、運営チームが承認するまで待ちます。すでに登録している会員には影響しません。

  1. 登録するとすぐ誰でもログインできるようにするには、新規サインアップに admin の承認を必須にする を無効にしておいてください。登録を一件ずつ確認したい場合は有効にしておいてください。

有効化後に開く ServiceLogin の設定フォーム。Service name・Contact email・Callback URI・Default Role とソーシャルログインの一覧が表示されています

ソーシャルログインを有効にする

お客さまがどのアカウントで登録するかは Login Providers で決めます。Google、GitHub、Facebook、GitLab、LINE、Kakao、Naver をそれぞれ有効にできます。

ソーシャルログインは二つの場所をつなぐ作業です。その提供元側(Google なら Google Cloud Console)に自分のサイトを登録し、そこで受け取った値を WEEGLOO に入力します。Google を有効にすると、画面がこの二つの手順をそのまま案内します。

  1. Google を有効にしてください。二つの手順の案内が表示されます。
  2. Step 1 に表示される Authorized redirect URI をコピーして、Google Cloud Console の OAuth クライアントに登録してください。このアドレスは、ログイン結果をどこへ返すかを Google に知らせます。
  3. Google Cloud Console で発行された値を、Step 2 の Client ID と Client Secret の欄に入力してください。
  4. ほかのソーシャルログインも使う場合は、GitHub や Facebook も同じやり方で有効にして値を入力したあと、保存 を押してください。

Google を有効にすると表示される認証情報の案内。Step 1 の承認されたリダイレクト URI と、Step 2 の Client ID・Client Secret の入力欄が表示されています

有効にしたソーシャルログインが一覧に有効な状態で表示され、保存 まで終えると、お客さまがそのアカウントでログインできるようになります。

provider ごとに違うもの: スコープとメール

連携の手順は、どの provider でも上と同じです。リダイレクトアドレスを登録する欄の名前は provider ごとに少しずつ違います(承認済みのリダイレクト URI、コールバック URL、Redirect URI など)。名前が違っても、値は provider を有効にしたときに出る案内の Step 1 に表示されるアドレスをそのまま貼り付ければよいです。

下の表のスコープ(ログイン時にお客さまへ求める情報の範囲)は、WEEGLOO がログインの時点で provider にリクエストする値です。Google・GitHub・Facebook はコンソールであらかじめ指定するものがなく、お客さまがログインするときに同意すればよいです。それ以外の provider はコンソールであらかじめ有効にしておくものがあるので、表で確認してください。

WEEGLOO は登録した会員をメールアドレスで区別します。そのため、provider がメールアドレスを渡してくれないと、そのアカウントではログインできません。OAuth アプリを作る詳しい手順は、各 provider の公式ドキュメントに従います。

providerWEEGLOO がリクエストするスコープprovider のコンソールで事前に有効にするもの公式ドキュメント
Googleemail, profileなしGoogle ドキュメント
GitHubread:user, user:emailなしGitHub ドキュメント
Facebookemail, public_profileなしFacebook ドキュメント
GitLabread_userアプリを作るときにスコープで read_user にチェックを入れますGitLab ドキュメント
Kakaoprofile_nickname, profile_image, account_emailビジネスアプリに切り替えたうえで、メールの同意項目の使用承認が必要ですKakao ドキュメント
Naveremail, profile, nicknameアプリを登録するときに、提供情報にメールアドレスを含める必要がありますNaver ドキュメント
LINEprofile, emailチャネルでメールの権限を申請して承認を受ける必要がありますLINE ドキュメント

登録した会員を見る

お客さまが登録すると、その会員は サービス の ServiceLogin 下の Users で確認できます。ここで登録した会員の一覧を見て管理します。

先ほど 新規サインアップに admin の承認を必須にする を有効にしておいた場合、新しく登録した会員はこの画面で承認を待ちます。会員を有効にしてあげると、そのときからログインできるようになります。

サイトが複数あるときの会員ログイン

一人の人が、まったく別のサービスをいくつも運営することもあります。服屋のぬくもりクローゼットを運営しながら、業種のまったく違う街角のパン屋まちかどベーカリーのサイトも一緒に切り盛りすると考えてみてください。二つのサイトは、訪れるお客さまも扱う内容も違います。服屋に登録したお客さまがパン屋の会員である理由はありません。

会員ログインは Space 1 つに 1 つずつ置きます。ですから、このように別々のサイトはそれぞれ Space を作り、その Space で会員ログインを別々に設定します。会員名簿も Space ごとに分かれ、服屋の会員とパン屋の会員は別々の会員として管理されます。

ある Space の会員ログインは、その Space で運営するサイトで使われます。1 つの会員ログインを複数のサイトに組み込んで一度に通す方式ではありません。会員に一度のログインで一緒に使ってほしい画面があるなら、その画面を 1 つのサイトにまとめてください。

次にやること

  • 会員のロールと権限: 登録した会員が何を見て使えるかを定める ServiceUserRole を作り、上で選んだ Default Role につなげます。
  • API リファレンス: 登録した会員のログインを自分のサイトのコードに組み込むには、公式のクライアント SDK やリクエスト形式といった技術仕様が必要です。会員が見て使うコンテンツをプログラムから直接扱うときの仕様もここで扱います。