なぜLINEプラットフォーム特集を書いたのか — 高齢者や主婦層にもAIが「届く」入口の話

昨日、全7章の「LINEプラットフォーム」特集を公開しました。特集は解説ページの集まりなので、なぜこれを書いたのかという話は入れていません。この記事では、その動機を私の言葉で書いておきます。

1. 「うちのお客さんは、そんなの使いませんよ」

出発点は、事業者の方にAIチャットボットの話をしたときに返ってくる、この一言です。特集の第5章にも書きましたが、私はこの反応を否定しません。ブラウザを開き、URLを打つか二次元コードを読み、アカウントを作り、入力欄に文章を打つ。この一連の動作を、店の常連である60代、70代のお客さんが自分から始めるとは、私も思えないからです。

ただ、この言葉には主語のすり替えが隠れています。使えないのは「お客さん」ではなく、「ブラウザで開くAI」という入口の方です。入口を変えれば答えも変わるはずで、それを7章かけて確かめたのが今回の特集です。

2. 入口は、もうホーム画面にある

LINEヤフーは2026年1月、LINEの国内月間利用者数が2025年12月末時点で1億を超えたと発表しました。総務省が2026年6月に公表した「情報通信メディアの利用時間と情報行動に関する調査」（令和7年度、13〜79歳が対象）でも、LINEの利用率は全年代で92.9%です。年代別に見ても60代で92.0%、70代で77.8%が使っています。70代まで含めた調査で9割を超える道具は、ほかに見当たりません。

数字より大事なのは使われ方です。家族との連絡、学校や地域の連絡、店からの予約確認。生活の連絡がすでにLINEで回っている人にとって、「店にLINEで聞く」は新しい行為ではありません。一方で「AIに質問する」は新しい行為です。同じチャットボットでも、どちらの顔で出すかで、使ってもらえるかどうかが決まります。

新しいアプリを入れてもらうことの難しさも、無視できません。専用アプリを作るなら、ストアに並べ、ダウンロードしてもらい、会員登録をしてもらい、通知を許可してもらう手順が続きます。その一つ一つで人が離れていきます。LINEの中で動くミニアプリなら、この手順が友だち追加ひとつに縮みます。第2章で仕組みを書いたLIFFは、そのための道具です。

私自身、先生向けの「センセイメモ」というサービスをLINE公式アカウントとして出しています。児童の観察メモをLINEに送りためておき、学期末に通知表の所見の下書きを生成する道具です。アプリのインストールもクレジットカードの登録も要らず、友だち追加だけで始められる形にしました。このサービスで組んだ仕組みは、特集の第5章「AIチャットボットをLINEに持たせる」で書いた内容と多くの部分で重なります。第5章を特集の核心と位置づけた背景には、この経験があります。

3. 高齢者と主婦層を「ターゲット」にするということ

特集では、ブラウザと縁遠い人を、切り捨てる対象ではなく主役として扱いました。理由は二つあります。

一つは、地域の飲食店や美容室、クリニックの売上を支えているのが、まさにその層だからです。若い人向けの派手なアプリを作っても、常連の予約は電話のままで、その電話を取るのは店のスタッフです。入口を「すでに使っている道具」に置けば、来店前の問い合わせも予約の確認も、店側の負担ごと減らせます。

主婦層についても同じことが言えます。平日の昼間に美容室やクリニックへ電話をかける時間を作るのは、簡単ではありません。家事や送り迎えの合間に、いつものLINEで予約や問い合わせが済むなら、それがいちばん負担の少ない入口です。店にとっても、電話が鳴らない分だけ目の前の接客に集中できます。どちらの側にも、新しい操作を覚えてもらう必要がない。ここが、専用アプリやホームページの問い合わせフォームとの一番の違いです。

もう一つは、私の職歴です。2000年代に、Webアクセシビリティを事業の柱にしていた会社で、企業サイトの構築とアクセシビリティのコンサルティングに関わりました。アクセシビリティの仕事は、「誰が使えないか」から設計を考える仕事です。文字が打てない人には、押すだけの選択肢を用意する。特集の第5章でリッチメニューを大きく扱ったのは、その延長にあります。トーク画面の下に常に表示されるタップ式のメニューがあれば、テキスト入力が苦手な人でも、営業時間や予約の案内にたどり着けます。

「AI」という言葉を画面に出さなくてよい、というのも設計上の大きな自由です。利用者にとっては「お店のLINEに聞いたら返事が来た」で十分で、裏でどのモデルが動いているかを知る必要はありません。

4. 7章に分けた理由と、読む順番

特集は次の構成です。

• 第1章「なぜLINEなのか」。友だち追加した人にそのまま配信できる「配信既存」という性質を、他のプラットフォームと比べて整理しました。
• 第2章「ミニアプリの正体」。LINEの中でWebアプリを動かす仕組みであるLIFF（LINE Front-end Framework）を、HTMLとJavaScriptだけで作れる範囲まで含めて解説しました。
• 第3章「予約システム」。LIFFとAPI Gateway、Lambda、DynamoDBで組む構成です。画面から送られたユーザーIDを信用せず、IDトークンをサーバー側で検証する点と、条件付き書き込みでダブルブッキングを防ぐ点は、実装で必ず詰まるので先に書きました。
• 第4章「会員証・スタンプカード」。スクリーンショットの使い回しを防ぐ、ワンタイムトークンの考え方です。
• 第5章「AIチャットボット」。Messaging APIのWebhookで受けたメッセージにBedrockで応答を作って返す流れと、AIに任せない領域をスタッフへ引き継ぐフォールバックの設計です。
• 第6章「AI接客」。Amazon Bedrockを東京リージョンで使い、顧客とのやり取りをAWSの外に出さない構成です。
• 第7章「ビジネス視点のまとめ」。自社アプリ開発、予約サイト型のSaaS、LINEミニアプリの費用を並べました。

店舗の方や経営者の方は、第1章、第5章、第7章の順で読めば判断材料がそろいます。エンジニアの方は第2章から第3章、第5章へ進むと、実装の勘所を続けて読めます。

第6章を独立させたのは、私が医療系のシステムを厚生労働省のガイドラインに沿って作ってきた経験と関係しています。顧客の氏名や予約内容がどこへ送られるかを、規約ではなく構成で説明できないAIを、私は商品として勧めません。Bedrockを選んだ理由はこの点を構成で担保できるからで、詳しい根拠は先日の記事「個人情報をAIでぶん回したい」に書いています。

5. 書きながら留保したこと

良いことばかりを並べた特集にはしていません。

LINEは自社の土地ではありません。規約やAPIの仕様、料金体系はLINE側の都合で変わります。だから特集の構成では、予約履歴や会員情報を自社のDynamoDBに置き、プラットフォームの条件が変わっても顧客との記録が手元に残る形にしています。予約サイトに月額を払いながら顧客データを持ち出せない状態と、ここが決定的に違います。

LINE公式アカウントの無料プラン（コミュニケーションプラン）には、月200通という配信の上限があります。小さな店なら足りることが多いものの、友だちが増えて一斉配信を増やすなら、月5,000通のライトプラン以上を検討することになります。第7章の費用試算も一般的な目安で、店舗ごとの来店数や問い合わせの量で変わります。

急ぐ人ほど先に動いてほしい手順もあります。LINE公式アカウントを認証済みアカウントにするなら、申請から承認まで1〜2週間を見ておく必要があります。第5章の導入スケジュールで、この申請を最初の段階に置いたのはそのためです。開発が終わってから申請すると、その分だけ公開が遅れます。

AIチャットボットは万能ではありません。クレームや緊急の相談、医療機関での症状の判断は、AIに答えさせない設計にしています。「困っている」「人と話したい」といった言葉を拾ってスタッフへ渡す仕組みを、第5章では省いてはいけない部品として書きました。

6. 最後に

「うちのお客さんは使わない」という言葉を、私はもう一度聞いてみたいと思っています。入口をLINEに置き換えたうえで、それでも使われなかったなら、その時は設計が間違っていたと素直に認めます。逆に、いつものLINEに話しかけるだけで予約や問い合わせが済むようになったなら、その店のお客さんは最初から「使える人」だったということです。

特集は全7章で、特集TOPからどの章にも入れます。読んで気になった点があれば、この記事の下の無料相談からご連絡ください。特集で書いた構成を、店の業態に合わせてどう組むかを一緒に考えます。