LINEのLIFF開発｜標準機能では届かない部分

LIFFは、LINEアプリの中でWebの画面を開くための、LINEヤフーが公式に提供している仕組みです。外部サイトへのリンクと決定的に違うのは、ブラウザに出ないことと、開いている人が「どの友だちか」を取得できることの2点です。 この2点があるので、予約・会員証・マイページのように「その人に合わせて見せる」ものが、LINEの中で成立します。標準のフォームが入力を受けるための道具なら、LIFFは見せる・つなぐための道具です。 この章は、LIFFで何ができるかを公式の仕様の範囲で整理し、要件を3つの数（画面・データ・つなぐ先）で決め、10項目すべてが○になるまで作り始めないための章です。そして、LIFFにしないほうがよい場合を先に潰します。

この章で分かること

• LIFFの仕組みと、LINEミニアプリとの違い（公式ドキュメントの範囲で）
• 要件の決め方（画面の数・扱うデータ・つなぐ先）と、作る前に決めておく4つのこと
• LIFFにしないほうがよい7つの場合と、10項目すべてが必須の着手前チェック

LIFFとは何か

LIFF（LINE Front-end Framework）は、自分で用意したWebページを、LINEアプリの中で開くための仕組みです。技術的な詳細は LINE Developers のLIFFドキュメントにあります。ここでは、要件を決めるために知っておくべきことだけを書きます。

要素	内容
何を用意するか	HTTPSで公開されたWebページ（自社でサーバーかホスティングを用意する）
どこに登録するか	LINE Developers のコンソールで、LINEログインチャネルにLIFFアプリを登録する。LIFF IDが発行される
どうやって開くか	発行されたLIFF URLを、リッチメニュー・配信・トークのリンクから開く
どこで開くか	LINEアプリの中（LIFFブラウザ）。外部ブラウザでも開けるが、使える機能に違いがある
画面の大きさ	登録時に、Compact / Tall / Full の3種類から選ぶ

サーバーが要るという点が、標準のフォームとの最大の実務上の違いです。作って終わりではなく、動かし続ける費用と責任が残ります。

LIFFのSDKでできること

LIFFのSDKを読み込むと、Webページの中からLINEの情報を扱えます。代表的なものは次のとおりです。機能ごとに、利用者の同意（スコープ）や、開いた場所による条件があります。 最新の条件は必ず公式ドキュメントで確認してください。

できること	何に使うか
ユーザーID・表示名・プロフィール画像の取得	開いている人がどの友だちかを特定する（この章の中心）
IDトークン／アクセストークンの取得	サーバー側で本人を確かめる（後述）
開いているトークにメッセージを送る	申込の完了を、その場でトークに残す
送り先を選んでメッセージを共有する	紹介・シェアの導線
画面を閉じる	完了後にトークへ戻す
LINE公式アカウントを友だち追加しているかの判定	未追加の人に追加を促す
QRコードの読み取り	来店時の受付など（利用できる条件があるため要確認）

「どの友だちか」を結びつけるために、最初に決める設定

ここは作り始める前に決めないと後から面倒になるところです。LINEのユーザーIDは、プロバイダー（チャネルをまとめる単位）ごとに発行されます。 同じプロバイダーの下にあるMessaging APIチャネル（LINE公式アカウント）とLINEログインチャネル（LIFF）では、同じ人に同じユーザーIDが付きます。

つまり、LIFFで操作している人と、友だちリストの中のその人を結びつけたいなら、両方を同じプロバイダーの下に置く必要があります。 別のプロバイダーに作ってしまうと、同じ人でも別のIDになり、結びつきません。

もう1つ。画面（ブラウザ側）から送られてきたユーザーIDを、そのまま信用してはいけません。 公式ドキュメントでも、サーバー側でアクセストークンまたはIDトークンを検証する形が案内されています。ここは開発側の責任範囲ですが、発注する側も「そういう工程がある」ことは知っておいてください。 見積もりに入っているかどうかの確認になります。

LIFFで何が増えるか

1章の3段階の表を、LIFFの列だけ詳しく開くと次のようになります。

できるようになること	具体的に何が起きるか
友だちの識別	開いた人が誰か分かるので、名前や氏名を聞かずに済む。申込内容をその友だちのタグ・情報に書き戻せる
今の値を見せる	空き状況・在庫・残数・ポイントのように、開くたびに変わるものを出せる
その人だけの内容を見せる	過去の履歴・書類・契約内容・会員証
複数画面のやり取り	入力→確認→完了、条件で分岐する申込、絞り込みながら選ぶ予約
社内システムとの往復	情報を取りに行く／書き込む。kintoneや既存システムに申込がそのまま入る
完了をLINEに残す	完了通知やリマインドをメッセージで送り、トークに履歴が残る

外部の予約サイトに飛ばす場合との差は、8章で見たとおりです。ブラウザに出ない、氏名を打ち直さない、誰が申し込んだか分かる、その後の配信を変えられる。この4つが、LIFFにする実質的な理由です。

LIFFとLINEミニアプリの違い

混同されやすいので、決めるために必要な範囲で整理します。

	LIFF	LINEミニアプリ
位置づけ	自社のLINE公式アカウントの中で動く画面	審査を通してLINEアプリ内の枠に載せるもの
公開までの手続き	自社でチャネルに登録して公開できる	審査が必要。要件と手間が変わる
主な導線	リッチメニュー・配信・トークのリンク	上記に加え、LINEアプリ側からの導線がある
向いているもの	まず効果を確かめたいとき	広く、継続的に使われる前提のサービス

多くの場合、まずLIFFで作って効果を確かめる順番をおすすめしています。 作ったものが使われるかどうかは、出す前には分かりません。審査の要件は変わることがあるので、LINE Developers のドキュメントで最新の条件を確認してください。

点検リストの10番は「ミニアプリにするかを判断した」です。判断すればよく、ミニアプリにする必要はありません。 判断していない状態で進むことだけを止めています。

標準で足りなくなる5つの兆候

8章の結論をここに持ってきます。1つも当てはまらないなら、この章を読み終えた後、8章に戻ってください。

#	兆候	標準フォームで止まる理由
1	入力した内容によって、次に出す画面を変えたい	分岐した先の画面そのものを作れない
2	空き状況・在庫・残数を見せたい	外部の最新情報を画面に出せない
3	その人の過去の履歴・書類を見せたい	個人ごとの内容を呼び出して表示できない
4	会員証・ポイントのように、開くたびに変わるものを出したい	静的な画像しか置けない
5	社内システムの情報をその場で確認させたい	外部システムと対話できない

要件は「3つの数」で決まる

見積もりが動く要因は、機能の名前ではありません。次の3つの数です。発注する前に、この3つを紙に書いてください。書けていれば、相談は30分で終わります。

① 画面の数

1画面で終わるか、3画面か、5画面以上か。 費用はここに最も強く比例します。

画面の数	中身の例
1画面	会員証の表示、ポイントの確認、今日の空き枠の一覧
2〜3画面	入力 → 確認 → 完了。条件で選択肢が変わる申込
5画面以上	マイページ（履歴・書類・変更・キャンセル・設定）

最初から5画面を作らないでください。 1画面か、多くて3画面で出して、使われている場所を見てから足す。これが、作り直しの費用を最も減らす進め方です。

② 扱うデータ

種類	何をするか	難しさの目安
入力して終わる	受け取って保存するだけ	低い（ただし、これだけなら標準フォームで足りる可能性が高い）
読んで見せる	空き状況・履歴・在庫を表示する	中。見せる元のデータが存在しているかが前提
書き戻す	予約を確定する、在庫を減らす、タグを付ける	高い。二重登録や競合の考慮が必要

「読んで見せる」で見落とされるのが、元のデータが今どこにあるかです。担当者の頭の中や紙の台帳にしかないなら、LIFFの前にそのデータを置く場所を作る話（10章）が先に来ます。

③ つなぐ先

0件・1件・2件以上。 つなぐ先が増えるほど、費用も、壊れたときの調査も増えます。

つなぐ先ごとに、次の2つを書いてください。

• 取りに行く情報（空き枠、会員情報、履歴）
• 書き込む情報（予約、申込、ステータスの変更）

つなぐ先に外から出入りする口（API等）があるかは、必ず先に確認してください。口が無いシステムには、つなげません。ここが×だと、要件そのものが成立しません。

作る前に決める4つ

1. 個人情報の持ち方

決めること	基本の形
何を持つか	必要最小限。LINEの友だち識別子と、氏名・連絡先は分けて持つ
どこに置くか	正本は業務システム側（kintone等）。LIFF側は表示のために呼び出すだけ、が望ましい
いつまで置くか	保存期間と、削除の手順・担当を決める

「とりあえず全部保存しておく」は、作るときは楽ですが、後で最も高く付きます。 持った情報は、守る責任と、消す手間と、聞かれたときに答える義務が付いてきます。

2. 失敗したときの動き

これを決めていない見積もりは、安く見えているだけです。必ず起きるのは、次の3つです。

失敗	決めておく表示・動き
つなぎ先のシステムが落ちている	「ただいま確認できません。お電話でご予約ください」＋電話番号。白い画面で止めない
通信が切れた・途中で閉じた	入力の途中が消えるのか、残るのか。送信が二重になったらどうするか
同じ枠に同時に申し込まれた	先着をどう決めるか。後の人に何を見せるか

3つ目は、空き枠を見せる予約では必ず起きます。「起きない前提」で作ると、必ずトラブルの電話が来ます。

3. 公開後に誰が直すか

LIFFは作ったら終わりではありません。文言、項目、選択肢は必ず変わります。

• 文言や選択肢のように、直しやすいところは管理画面から変えられるようにする（当社はこの形にします）
• コードの変更が必要な部分は誰がやるかを決める。自社で引き継ぐなら、ソースと手順を受け取る

「直せない画面」は、半年で使われなくなります。 内容が古くなった瞬間に、誰も開かなくなるからです。

4. サーバー費用を誰が払うか

LIFFは自社のWebページなので、動かし続けるための費用が毎月かかります（規模によります）。誰の予算から出るのかを、作る前に決めてください。構築費だけで稟議を通して、運用費が出てこないのが最も多い詰まり方です。

費用の考え方

当社の場合は次のとおりです（/services/liff）。

項目	費用
初回相談（30分）	無料
要件の整理（画面の数・必要なデータ・つなぐ先を決める）	無料
LIFF開発	お見積り
運用・改善	お見積り

要件の整理まで無料にしているのは、ここで「作らなくてよい」と分かることが多いからです。 相談の30分で、LIFFが要るかどうかから判断します。8章で標準機能に戻る結論になっても、それが正しい結論です。

お見積りは、画面の数・つなぐ先の有無・認証の要否で変わります。LINE公式アカウントやLステップ・エルメの月額料金は御社のご契約で、当社の見積もりには含みません。サーバー費用が必要な場合は別途お伝えします。

見積もりを比べるときは、次の3つが入っているかを見てください。 入っていない見積もりは安く見えます。

1. 失敗したときの動き（つなぎ先が落ちたとき・二重送信・同時申込）
2. 公開後に自社で直せる範囲（管理画面から変えられるのはどこまでか）
3. サーバー費用と、その負担の所在

LIFFにしないほうがよい場合

この章で最も大事な節です。 次のどれかに当たるなら、作らないでください。

#	当てはまる状況	代わりにすること
1	8章の5つの兆候が1つも当たらない	標準のフォームで受ける。作らない
2	出口がまだ1つに決まっていない／出口の件数を数えていない	2章と11章に戻る。何を増やすのかが決まっていない状態で画面を作らない
3	外部の予約サイトに飛ばしているが、離脱を測っていない	8章の測り方でタップ数と完了数を1ヶ月並べる。問題が実在するか確かめてから
4	つなぎたいシステムに、外から出入りする口が無い	先に業務システム側を整える（10章）。LIFFだけ作っても情報が取れない
5	公開後に直す人がいない（予算も担当も無い）	作らない。半年で使われなくなり、サーバー費用だけが残る
6	個人情報の保存場所・保存期間・削除の手順を決められない	決まるまで作らない。預かる責任だけが先に発生する
7	一度きりのキャンペーンで、終われば使わない	標準フォームか外部サービス。作る費用とサーバーが後に残る

さらに、そもそもLIFFという選択自体が合っていない場合が3つあります。

• LINEを使っていない人にも同じことをさせたい。 LIFFはLINEの中で開くものです。全員に届けたいなら、普通のWebサイトで作って、LINEからはそこへ案内するほうが正しい形です
• 長い入力、長い文章、PCでの作業が中心。 スマホのLINEの中で開く画面です。何十項目もの申請や、じっくり読む資料には向きません
• 決済や本人確認が主役。 その場合の主題は決済事業者との契約と審査であって、LIFFは入口にすぎません。順番を間違えると、画面だけ先にできます

当社はLIFFを作る会社ですが、上のどれかに当たるお客様には作りません。 作って使われなかったものは、こちらの実績にもなりません。

よくある誤解を3つだけ

「LIFFを作れば離脱がなくなる」 ——減るのは、ブラウザに飛ぶこと・ログインを求められること・氏名を打ち直すことが原因の離脱だけです。そもそも申し込む理由がない、価格が合わない、空き枠が希望と違う、という離脱は画面では解決しません。離脱の中身を先に見てください。 8章のタップ数と完了数を並べただけでは、どこで止まっているかまでは分かりません。分からないなら、まず外部サイトのまま原因を1つ特定するほうが早いです。

「LIFFにすれば、Lステップやエルメは要らなくなる」 ——別の道具です。LIFFは画面を作る仕組みで、配信の設計・タグ・ステップ配信・セグメントはツール側の役割です。当社も併用を前提に設計します。LIFFで受けた内容をタグや友だち情報に書き戻し、その後の配信をツール側で変える、という形が最も素直です。

「まず小さく作って、後から全部つなげばいい」 ——小さく作るのは正しいですが、つなぐ先だけは最初に決めてください。 画面を先に作ってから「やっぱり基幹ともつなぎたい」となると、データの持ち方から作り直しになります。画面は減らしてよく、つなぐ先は減らさない。 これが費用を抑える正しい縮め方です。

この章の出口

この章を終えたとき、手元に残っているべきものは次の3つです。

1. 3つの数（画面の数・扱うデータの種類・つなぐ先の件数）が紙に書いてある
2. 点検リスト10項目が、すべて○（1つでも空なら、そこを埋めるまで着手しない）
3. 「作らない」という結論も含めた判断が1行（作らない場合は、7つのどれに当たったか）

この章の成功は、LIFFを作ることではありません。 作るべきものだけを、作るべき大きさで作り始められる状態になっていることです。 点検リストの3番（つなぐ先）が埋まらなかった人が最も多いはずです。その場合、足りていないのはLIFFではなく、つなぐ相手側の整備です。次の章で扱います。

初回相談と要件の整理は無料です。10項目のうち埋まらないところがある状態でも構いません。LIFF開発からご相談ください。要らないと判断した場合は、その理由をお伝えします。

次の章へ：10章 LINEとkintoneを連携する｜予約・顧客情報