エンジニアとして LINEミニアプリからネイティブアプリへの移行プロジェクトに関わる際、事前に把握しておくべき LINE の仕様制約が3点あります。これらは移行後のシステム設計に直接影響するもので、実装フェーズに入ってから発覚すると手戻りが大きくなります。
事業者視点での解説は LINEミニアプリをやめてネイティブアプリに移った会社が後悔した3つの理由（amanity.co.jp） にまとめています。本記事はその技術的な裏付けをエンジニア向けに整理したものです。
制約1: Messaging API で取得できる識別子は UID のみ、かつプロバイダー固有
仕様の概要
LINE Login および Messaging API で取得できるユーザー識別子は プロバイダー固有の UID（User ID）のみです（公式: ユーザー管理）。
取得できないフィールド:
- メールアドレス（LINE Profile+ のオプション機能を契約した場合のみ取得可能。通常プランでは不可）
- 電話番号（同上）
- LINE ID（@アカウント名）
UID のスコープ制約
重要なのは、UID は 同一プロバイダー内でのみ一意 な点です。
User A が Provider X のチャネルにログイン → uid: Uxxxxxxxxxxxxxxxx
User A が Provider Y のチャネルにログイン → uid: Uyyyyyyyyyyyyyyyy ← 別の値
つまり、同一の実ユーザーであっても、異なるプロバイダー（チャネルグループ）でログインさせると UID が変わります。マルチサービス構成や CRM との横断突合には使えません。
データフロー
移行設計への影響
ネイティブアプリへ移行する際、LINEミニアプリ側で蓄積した UID は ネイティブアプリの自前 DB にそのまま引き継げない ケースがほとんどです。
- ネイティブアプリの認証基盤を LINE Login で構築する場合: 新プロバイダーに紐づくチャネルの UID を新たに発行し直すことになる
- 既存の LINE 公式アカウントと同プロバイダーにまとめる設計にすれば UID を維持できるが、チャネル構成の見直しが必要
避けるべき構成:
LINEミニアプリ → Provider A
ネイティブアプリ → Provider B（別UID発行）
望ましい構成:
LINEミニアプリ → Provider A
ネイティブアプリ → Provider A の別チャネル（UID維持）
制約2: チャネルを別プロバイダーへ移動する手段がない
仕様の概要
LINE Developers の公式仕様上、既存チャネルを別プロバイダーに移動させる機能は提供されていません（公式: チャネルの管理）。
影響するシナリオ
移行プロジェクトでよく発生するケース:
- 旧体制で複数の代理店がそれぞれプロバイダーを作成し、チャネルが分散している
- 会社の組織再編に伴い、LINE アカウントの管理主体が変わる
- LINEミニアプリを別法人（グループ会社）に移管したい
いずれも「チャネルを移す」という手段は取れないため、新規チャネル作成 + ユーザーの再獲得 が実質的な対応になります。
実装上の代替手段
チャネル移動ができない前提で、ユーザー継続性を維持するには以下が考えられます。
- LINEミニアプリ廃止前に、ネイティブアプリへの誘導バナーを設置して期間を設ける
- 移行期間中はLINEミニアプリとネイティブアプリを並行稼働し、メールアドレスや電話番号を自社 DB に蓄積する
- 蓄積した連絡先を使い、ネイティブアプリのプッシュ通知でリエンゲージメントを図る
制約3: 友だちリストを一括エクスポートする手段がない
仕様の概要
LINE 公式アカウントの友だちリスト（UID 一覧）を管理画面から CSV 等でエクスポートする機能は、標準では提供されていません。
Messaging API でのユーザー情報取得は 1ユーザーずつ個別に GET /v2/profile/{userId} を呼び出す形式であり、全UID を一括で列挙するエンドポイントは存在しません（公式: ユーザーのプロフィール情報を取得する）。
# UID が既知の場合のみ取得可能
curl -X GET "https://api.line.me/v2/profile/{userId}" \
-H "Authorization: Bearer {channel_access_token}"
UID を事前に保持していない場合、一括移行のためのデータ取得手段がありません。
設計上の教訓
UID 管理は LINEミニアプリ運用開始時から自社 DB で行うべきです。友だち追加・メッセージ送信等の Webhook イベントに UID が含まれるため、Webhook 受信時点で自社 DB に記録する実装を入れておくことが重要です。
// Webhook イベントから UID を記録する実装例
app.post('/webhook', (req, res) => {
const events = req.body.events;
for (const event of events) {
const uid = event.source.userId;
if (uid) {
// 自社 DB に uid を upsert
await db.upsert('line_users', { uid, updatedAt: new Date() });
}
}
res.sendStatus(200);
});
Webhook ベースで記録することで、UID 一覧を常に自社側で保持でき、移行時の「リストがない」問題を回避できます。
まとめ: 移行設計のチェックポイント
| チェック項目 | 対処 |
|---|---|
| 同一プロバイダーにチャネルを集約しているか | 移行先のネイティブアプリ向けチャネルを同プロバイダーで作成する |
| UID を自社 DB で管理しているか | Webhook 受信時に記録する実装を初期から入れる |
| メールアドレス・電話番号を自社 DB に蓄積しているか | LINEミニアプリ内でオプトイン取得のフローを設ける |
| 移行期間の並行稼働期間を設けているか | 廃止タイミングと並行稼働期間を開発スケジュールに組み込む |
これらの制約はいずれも LINE の公式仕様として明示されており、設計前に把握しておけば移行後の手戻りを防げます。
元記事
LINEミニアプリをやめてネイティブアプリに移った会社が後悔した3つの理由 — amanity.co.jp
事業者・経営者向けのビジネス視点での整理は元記事をご覧ください。