うちのスマホ修理店（2店舗）には、長いこと「会員証」と呼べるものがなかったんですよね。
紙のポイントカードとか、そういうのはやりたくなかった。お客さんも財布に入れんし、スタッフも「あ、お持ちですか？」って聞くのが面倒くさい。かといって既製のアプリを月額で入れるほどの規模でもない。で、ずっと放置していたわけです。
ある日ふと「LINEの中で完結する会員証、自分で作れるんじゃね？」と思って、実際に作りました。LIFF（LINE Front-end Framework）とGoogle Apps Script（GAS）とWordPressの固定ページ。この3つで、会員登録・修理履歴管理・スタッフ用入力画面まで全部動いています。費用はゼロ。
今回はその構築手順を、やった順番どおりに書き残しておきます。同じようなことを考えている小規模店舗のオーナーさん、あるいは「LIFFって何ができるの？」と気になっているエンジニアの方に、なにかしら参考になれば。
ちなみに、制作に5時間かかりました。
全体像——何を、どう組み合わせているか
先に完成形の構造を書いておきます。
お客さんがLINEでリンクをタップすると、LINE内ブラウザでWordPressの固定ページが開きます。そのページにはLIFF SDKが仕込んであって、開いた瞬間にLINEのUser IDを取得。そのIDをGAS（Googleスプレッドシートと連携したサーバーレスAPI）に投げて、「この人はスタッフか？ 登録済み顧客か？ 未登録か？」を判定する。判定結果に応じて画面が切り替わる——スタッフなら修理履歴の入力フォーム、登録済み顧客なら会員証と履歴、未登録なら会員登録フォーム。
要するに、LIFFが「LINEとWebをつなぐ窓口」、GASが「データの保存と判定をやるバックエンド」、WordPressが「画面を置く場所」です。それぞれ無料で使えて、既存の資産（LINE公式アカウント、WordPress）をそのまま活かせる。この「あるもので組む」感じが気に入っています。
いわゆる、枯れた技術の水平展開っていうやつですね。
手順1：LINE Developersの登録とプロバイダー作成
まず最初にやるのが、LINE Developersへの開発者登録です。普段使っているLINEアカウントでログインして、名前とメールアドレスを登録するだけ。ここで「プロバイダー」を1つ作ります。名前は店舗名でもなんでもいい。これが開発環境の「箱」になります。
プロバイダーができたら、その中に「LINEログイン」チャネルを作成。チャネル名はお客さんの目に触れるので「〇〇会員証」みたいにしておくと親切です。アプリタイプは「Webアプリ」にチェック。
次に、そのチャネル内で「LIFF」タブからLIFFアプリを追加します。サイズはFull（全画面）、Scopeはprofile（ユーザーIDを取るのに必要）にチェック。エンドポイントURLはこの時点では仮で構いません。https://example.com とか入れておいて、あとで実際のページURLに差し替えます。
ここで発行される「LIFF URL」（https://liff.line.me/xxxxx-xxxxx の形式）を控えておいてください。これが最終的にお客さんがタップするリンクになります。
手順2：Googleスプレッドシートの準備
データの置き場所として、Googleスプレッドシートを1つ作ります。シートは2枚。
1枚目は customers（顧客情報）。列構成は「LINE User ID／会員番号／氏名／電話番号／初回来店日」。2枚目は repair_history（修理履歴）。「LINE User ID／修理日／機種名／修理内容1／料金1／修理内容2／料金2／修理内容3／料金3／値引き額／合計料金／担当者」。
1回の来店で複数箇所を修理することがあるので、修理内容と料金は3セットまで持たせています。値引きも入る。このあたりは自分の店の実務に合わせて決めた構成です。
手順3：GAS（Google Apps Script）でバックエンドを作る
スプレッドシートのメニューから「拡張機能 → Apps Script」を開いて、コードを書いていきます。GASはWebアプリとしてデプロイすると、外部からGETやPOSTでアクセスできるAPIになる。これを使います。
最初はシンプルに、doGet でスタッフ判定だけを返す形からスタートしました。スタッフかどうかの判定は、コード内に定義したLINE User IDのリストとの突合です。セキュリティ的に、この判定はWordPress側（ブラウザ）ではなくGAS側（サーバー）でやるのがミソ。ブラウザ側のコードは誰でも見られるので、そこにスタッフIDを書いたら意味がないですからね。
ここで大事なのが、GASはコードを保存しただけでは外部に反映されないということ。「デプロイ → デプロイを管理 → 新バージョンで更新」をやらないと、古いコードのまま動き続けます。最初これに気づかなくて30分くらい「なんで動かんと？」ってなりました。
会員番号の自動採番ロジック
会員番号は6桁にしました。先頭2桁が店舗コード（西新:10、博多:20）、3桁目は固定で1、下3桁が連番。たとえば西新店の最初のお客さんは「101001」、次は「101002」。博多店なら「201001」から。
採番はGAS側で、スプレッドシートの既存データから最大値を取って+1する方式。同時アクセスで番号が被る可能性は——まあ、うちの規模なら無視していいでしょう。1日に何百人も登録するような店じゃないので。
修理履歴の書き込み
スタッフが入力フォームから送信したデータは、POSTリクエストでGASに飛びます。GAS側で会員番号からLINE User IDを逆引きして、repair_history シートに1行追記。合計金額もサーバー側で計算して書き込みます。
手順4：WordPressに固定ページを作る
WordPressの管理画面で固定ページを1つ作成。タイトルは「会員証」、スラッグは member-card あたりで。本文にはカスタムHTMLブロックで、LIFF SDKの読み込みと画面表示のコードをまるっと貼り付けます。
このページのURL（https://yoursite.com/member-card/）を、LINE DevelopersのLIFFエンドポイントURLに設定すれば、LINEからこのページが開くようになります。
画面の出し分け
HTMLとJavaScriptで、3つの画面を用意しています。
未登録の人には「会員登録フォーム」——店舗選択、氏名（任意）、電話番号（任意）を入力して登録ボタンを押すと、GASに飛んで会員番号が自動発行される。登録後は自動的に会員証画面に切り替わります。
登録済みの人には「マイ会員証」——黒いカード風のデザインで会員番号と名前と登録日が表示される。その下に過去の修理履歴が新しい順で並ぶ。お客さんは自分の修理履歴をいつでもLINEから確認できるわけです。
スタッフには「修理履歴登録フォーム」——会員番号、修理日、機種名、修理内容（最大3つ）、値引き、担当者を入力して書き込む。合計金額はリアルタイムで自動計算されます。
手順5：料金表との連動（ドリルダウン化）
最後にやったのが、スタッフ入力画面の「機種名」「修理内容」をプルダウンにして、料金を自動入力させる仕組みです。
うちのサイトには、もともと料金表のデータをJavaScriptのオブジェクトとして書き出したファイル（repair-prices_autogen.js）があったんですよね。機種名をキーにして、修理内容と料金がぶら下がっている構造。これをWordPressの固定ページで読み込んで、機種を選んだら修理内容の選択肢が動的に生成され、修理内容を選んだら料金が自動で入る——いわゆるドリルダウンです。
もちろん料金は手動で上書きもできます。イレギュラーな割引とか、部品の在庫状況で値段が変わるとか、現場ではよくある話なので。あくまで「初期値を自動で入れてくれる」くらいの位置づけです。
運用してみてどうか
実際に動かしてみて数週間。正直、めちゃくちゃ快適です。
お客さんの反応は「え、これLINEで見れるんですか」くらいの軽い驚き。紙を渡さなくていいし、「前回いつ来たっけ？」「あのとき何修理したっけ？」がお客さん側で確認できるのは地味に便利。スタッフも、修理が終わったらスマホでフォームに入力するだけ。紙の伝票を書いてあとからExcelに転記……みたいな二度手間がなくなりました。
費用はゼロ。LIFFもGASもGoogleスプレッドシートも無料枠で余裕で収まる規模。WordPressはもともと動いているし。外部サービスに月額を払わず、自分の手元にデータがある安心感は大きいです。
ハマったところ・注意点
いくつか詰まったポイントも書いておきます。
まず、GASのデプロイ更新忘れ。これは前述のとおり。コードを直してもデプロイを「新バージョン」にしないと反映されません。毎回やるのが面倒なんですけど、忘れると「コードは正しいのに動かない」という一番厄介なバグになる。
次に、LIFFのScope設定。profile にチェックを入れ忘れると、User IDが取れません。当然スタッフ判定もできない。「あれ、ログインはできるのに画面が切り替わらん……」ってなったらここを確認。
あと、GASのWebアプリは「アクセスできるユーザー」を「全員」にしておかないと外部から叩けません。初回デプロイのときに設定するんですけど、これを「自分のみ」にしたまま外部からアクセスしようとして403を食らう人、たぶん多いと思います。
それから、料金表JSのグローバル変数名。外部JSファイルで const repair_prices = {...} と定義しているなら、WordPress側のコードで window.repair_prices を参照する形にしないと読めません。変数名がズレると機種プルダウンが空っぽになります。ここは環境に合わせて調整が必要なところ。
素人がここまで組める時代
私はもともとネットワークエンジニアであって、フロントエンドのプロではありません。JavaScriptはまあ読めるし書けるけど、ReactだのVueだのをバリバリ使いこなすタイプではない。GASも「必要に駆られて覚えた」レベルです。
でも、この程度のシステムなら組めてしまう。LIFFのSDKは公式ドキュメントが整っているし、GASは「スプレッドシートにデータを読み書きするAPI」としてはかなり手軽。WordPressの固定ページにHTMLを貼るだけでフロントが完成する。
もちろん、大規模にスケールさせるとか、セキュリティを万全にするとかいう話になると話は別です。でも「2店舗・スタッフ数名・会員数百人」くらいの規模なら、これで十分に実用になる。月額課金のSaaSを入れるかどうか迷っている小規模店舗のオーナーさんには、「自分で組む」という選択肢もあるよ、と言いたいところです。
まあ、途中で何回か「もう既製品入れようかな……」と思ったのは内緒ですけどね。でも動いたときの「よっしゃ」は、既製品では味わえんやつです。よかよか。
