# プロバイダーとチャネル管理のベストプラクティス

このページでは、プロバイダーとチャネル管理のベストプラクティスを紹介します。

# 登場人物

以下の仮想の組織、人物を例として説明します。

組織、人物 説明
飲料メーカーA コーヒー飲料「ブラウンコーヒー」と紅茶飲料「コニー紅茶」を提供する飲料メーカー。LINEプラットフォームを利用したサービス開発を開発会社Cと開発会社Dに委託している。
飲料メーカーB コーラ飲料「サリーコーラ」を提供する飲料メーカー。飲料メーカーAの米国法人。
開発会社C LINEプラットフォームを利用したサービス開発を飲料メーカーAから委託されている開発会社。コーヒー飲料「ブラウンコーヒー」のキャンペーンサイトをLINEログインを利用して開発している。
開発会社D LINEプラットフォームを利用したサービス開発を飲料メーカーAから委託されている開発会社。コーヒー飲料「ブラウンコーヒー」のLINEボットと紅茶飲料「コニー紅茶」のLINEボットをMessaging APIを利用して開発している。
ブラウン 飲料メーカーAの社員。
コニー 飲料メーカーAの社員。

また、飲料メーカーAは、プロバイダー「飲料メーカーA」とその配下のチャネルを管理しているものとします。プロバイダー「飲料メーカーA」配下のチャネルは以下のとおりです。

チャネルの種類 チャネル名 説明
LINEログイン ブラウンコーヒー コーヒー飲料「ブラウンコーヒー」のキャンペーンサイト用のチャネル。
Messaging API ブラウンコーヒー コーヒー飲料「ブラウンコーヒー」のLINEボット用のチャネル。
Messaging API コニー紅茶 紅茶飲料「コニー紅茶」のLINEボット用のチャネル。

# 各プロバイダーや各チャネルのAdmin権限を複数の開発者に付与する

dummy dummy
良い例 各プロバイダーや各チャネルのAdmin権限を複数の開発者に付与する。
悪い例 各プロバイダーや各チャネルのAdmin権限を1人の開発者だけに付与する。

プロバイダーやチャネルのAdmin権限を持つ唯一の開発者が、急な退職などにより不在になると、そのプロバイダーやチャネルにAdmin権限でアクセスできなくなります。その結果、プロバイダーやチャネルの運用を続けることが難しくなる可能性があります。このような不測の事態に備えるため、各プロバイダーや各チャネルのAdmin権限は複数の開発者に付与します。

たとえば、ブラウンとコニーがプロバイダー「飲料メーカーA」とLINEログインチャネル「ブラウンコーヒー」のAdmin権限を持っているとします。もしブラウンが急遽退職しても、コニーもAdmin権限を持っているため、プロバイダーやチャネルの運用を問題なく続けることができます。

なお、プロバイダーとチャネルの権限は独立しています。プロバイダーのAdmin権限を付与しても、そのプロバイダーの配下のチャネルのAdmin権限を付与したことにはならないため注意してください。

権限について詳しくは、「権限を管理する」を参照してください。

開発者をプロバイダーから削除する際の注意点

LINE Developersコンソールで開発者をプロバイダーから削除する際に、[選択した開発者をこのプロバイダーに紐づいているチャネルからも削除する。]をチェックし、[OK]をクリックすると、選択した開発者がプロバイダーの配下のチャネルからも削除されます。

ただし、選択した開発者がプロバイダーの配下のチャネルから削除された結果、そのチャネルのAdmin権限を持つ開発者が0人になる可能性があります。そのため、[選択した開発者をこのプロバイダーに紐づいているチャネルからも削除する。]をチェックする際は、チャネルのAdmin権限を持つ開発者が他にいることを確認してください。

# プロバイダーをサービス提供者ごとに作成する

dummy dummy
良い例 飲料メーカーAのプロバイダーと飲料メーカーBのプロバイダーをそれぞれ作成する。
悪い例 飲料メーカーAと飲料メーカーBで1つのプロバイダーを作成する。

サービス提供者(LINEミニアプリではサービス事業主)とは、サービスを提供し、ユーザーの情報を取得する開発者個人、企業、または団体のことです。LINE Developersコンソールでは、サービス提供者をプロバイダーとして登録します。そのため、プロバイダーはサービス提供者ごとに作成します。

たとえば、飲料メーカーAの米国法人である飲料メーカーBが「サリーコーラ」のLINEボットを開発したいとします。この場合、飲料メーカーBはプロバイダー「飲料メーカーA」の配下にMessaging APIチャネルを作成するのではなく、飲料メーカーBのプロバイダーを作成し、その配下にMessaging APIチャネルを作成します。

また、LINEプラットフォームを利用したサービス開発を他社に委託する場合は、サービス提供の主体となる委託元のプロバイダーを作成します。

たとえば、飲料メーカーAは、LINEプラットフォームを利用したサービス開発を開発会社Cと開発会社Dにそれぞれ委託しています。この場合、サービス提供の主体は委託元である飲料メーカーAです。そのため、開発会社Cや開発会社Dのプロバイダーではなく、飲料メーカーAのプロバイダーを作成し、その配下にチャネルを作成します。

# 連携したいチャネルを同じプロバイダーの配下に作成する

dummy dummy
良い例 連携したいチャネルを同じプロバイダーの配下に作成する。
悪い例 連携したいチャネルを別々のプロバイダーの配下に作成する。

複数のチャネルを連携するサービスを開発する場合は、連携したいチャネルを同じプロバイダーの配下に作成します。同じプロバイダーの配下に作成することで、各チャネルでは同じユーザーに対し、同じユーザーIDが割り当てられます。チャネルを後から別のプロバイダーに移動させることはできないため、連携したいチャネルを別々のプロバイダーの配下に作成しないよう注意してください。

たとえば、ユーザーが「ブラウンコーヒー」のキャンペーンサイトにLINEログインする際に、友だち追加オプションを利用して「コニー紅茶」のLINEボットの友だち追加を促したい場合は、「ブラウンコーヒー」のLINEログインチャネルと「コニー紅茶」のMessaging APIチャネルをプロバイダー「飲料メーカーA」配下に作成します。

なお、複数のサービスでLINEプラットフォームを利用する際に、各サービスで取得したLINEユーザー情報を紐づけるには、プロバイダーページを公開した上で、利用条件を満たす必要があります。詳しくは、『法人ユーザー向けオプションドキュメント』の「ユーザーID共通利用に関する注意事項」を参照してください。

# サービスを提供する地域ごとにチャネルを作成する

dummy dummy
良い例 サービスを提供する地域ごとにチャネルを作成する。
悪い例 1つのチャネルを使用して複数の地域にサービスを提供する。

複数の国・地域において同一ブランドのサービスを提供する場合は、1つのチャネルを共有するのではなく、地域ごとに個別のチャネルを作成します。

たとえば、飲料メーカーAが日本でコーヒー飲料「ブラウンコーヒー」のキャンペーンサイト運営していて、台湾とタイでも同商品のキャンペーンサイトを開設するとします。この場合は、プロバイダー「飲料メーカーA」配下に地域別にLINEログインチャネルを作成します。

# [チャネル基本設定]タブの[メールアドレス]にメーリングリストのメールアドレスを登録する

dummy dummy
良い例 チャネル基本設定]タブの[メールアドレス]にメーリングリストのメールアドレスを登録する。
悪い例 チャネル基本設定]タブの[メールアドレス]に個人のメールアドレスを登録する。

各チャネルの[チャネル基本設定]タブにある[メールアドレス]に登録されたメールアドレスには、チャネルに関する重要なお知らせが届きます。そのため、この[メールアドレス]には、個人のメールアドレスではなくメーリングリストのメールアドレスを登録します。

たとえば、LINEログインチャネル「ブラウンコーヒー」の[チャネル基本設定]タブの[メールアドレス]に、ブラウンとコニーが所属する部署のメーリングリストのメールアドレスを登録します。これにより、ブラウンやコニーが不在の場合でも、チャネルに関する重要なお知らせを受け取ることができます。

なお、チャネルに関する重要なお知らせは、チャネルの権限を持つ開発者のメールアドレスや通知センターでも受け取ることができます。詳しくは、「メールや通知センターでお知らせを受け取る」を参照してください。