Flex Message実務入門。ボタン付き配信の設計・制作・受入確認

Flex Messageは、LINEのトークへ画像、説明文、ボタンを組み合わせたカードを届ける仕組みです。商品を比較する、予約内容を確認する、手続きの入口を選ぶといった場面で使えます。発注時には、見た目と同時に**「ボタンを押した後、何が成立するか」**を決めると、制作範囲が明確になります。

本記事は2026年9月8日の公式仕様を確認したうえで、業務で使うカードの設計と受入条件を整理します。掲載する構成・例は設計案であり、実際の配信結果や改善実績ではありません。

カードで完結することと、別画面へ渡すこと

Flex MessageはJSONでレイアウトを指定するメッセージです。カード単体のバブルや、複数カードを並べるカルーセルを組み立てられます。ただし、カードを送っただけで予約DBや決済処理ができるわけではありません。Flex Messageの公式ガイド

やりたいこと	カードの役割	別途必要な処理
予約日時を知らせる	日時、場所、確認先を短く示す	予約DBから正しい内容を取得する
商品候補を比較してもらう	違いを同じ順序で並べる	最新価格・在庫は遷移先で再確認する
問い合わせを振り分ける	選択肢と有人窓口を示す	選択結果の受信と担当者への引き継ぎ
複雑な申込情報を入力する	入力画面を開く入口にする	LIFFやWebフォーム、認証、入力検証

入力項目が多いのにボタンを増やし続けると、トークを何往復もすることになります。カードで「次に何をするか」を選び、複雑な入力は画面でまとめる分担が実務的です。

ボタンの種類を、業務上の意味に合わせる

LINEのアクションには、URLを開くURIアクション、文字を送るメッセージアクション、サーバーへデータを送るポストバックアクションなどがあります。選択できるアクションは配置する要素の仕様にも従います。アクションの公式仕様

表示する文言	適した動作の例	設計時の注意
詳細を見る	URIで詳細ページを開く	最新情報のあるページに遷移させる
配送について質問する	メッセージを送る	同じ文字を手入力した場合も扱えるようにする
この候補を選ぶ	ポストバックを受け付ける	選択時点で有効な候補かサーバーで確認する
予約を変更する	認証付きの変更画面を開く	URLの予約番号だけで本人と判断しない

「予約する」というラベルで候補の選択しか行わないと、利用者は確定したと思ってしまいます。確定前は「この日時で申し込む」、確定後は「予約内容を確認」のように、実際の状態に合わせた言葉を使います。

制作前に情報の優先順位を決める

最初に用意するのは、完成画像ではなく一枚分の原稿です。見出し、判断に必要な項目、主なボタン、補助的な案内の順で書きます。予約なら日時と店舗、商品なら商品名と選択に必要な違いが優先されます。

カード内へ利用規約や長い注意事項をすべて詰め込むと、主要な情報が埋もれます。申込前に読む必要のある条件は短く示し、詳細ページへ進めるようにします。ただし、取消料の発生など判断を変える条件を、リンク先だけに隠す設計は避けます。

Flex Messageには代替テキストの altText も用意します。カードが見えない場面でも用件が分かる文にし、「新着メッセージ」だけで済ませないことをおすすめします。表示はOS、LINEのバージョン、画面サイズやフォント等で変わるため、Simulatorのプレビューだけでは受入完了にしません。表示差の公式説明

Simulatorから運用可能なテンプレートにする

制作の流れは、原稿の合意、Simulatorでの試作、JSONの管理、検証環境での確認、運用担当者による承認の順に組み立てられます。実配信を伴う検証は、対象と実施日を別途決めて行います。

更新担当者が毎回JSONを直接編集するなら、括弧の欠落やURLの混入が起きる可能性があります。繰り返し使うカードは、見出し、画像、日時、リンク先などの編集欄を限定した管理画面や入力シートから生成する設計も選べます。

管理するもの	決めておく項目
文言	最大の長さ、改行、必須項目、承認者
画像	掲載権限、公開範囲、差し替え手順、保管場所
URL	許可するドメイン、期限切れ時の遷移先
ボタンのデータ	対象ID、テンプレートの版、有効期限
配信履歴	誰がどの版を誰向けに承認したか

画像URLへアクセスできることと、顧客だけに画像を見せられることは別です。商品写真のような公開素材と、個人の契約書や予約明細を同じ置き場にしません。顧客ごとの詳細は、認証した画面で確認する設計が適しています。

実務例：受付日時のカードを、変更後も誤作動させない

架空のレンタルスペースで、9月15日10時の予約案内を送るケースを考えます。カードには日時、会場、予約内容を確認するボタンを配置します。後日11時へ変更したあとも、トーク履歴には10時のカードが残ります。

そこで、古いカードの「確認」から開いた画面では、DBにある最新の11時を表示し、変更済みであることを伝えます。「取り消す」操作も、現在の状態と操作権限を確認してから受け付けます。過去のカード本文を現在の予約状態として扱わない設計です。

同じボタンを連続して押しても、予約を二件作らないことも受入条件です。これはカードのデザインだけでは解決できないため、予約受付の設計と合わせて見積範囲に入れます。

配信前の受入確認表

確認する場面	合格の判断
長い商品名・大きい文字設定	主要な項目とボタンが読め、操作できる
iOSとAndroidで表示	情報の欠落や押せない領域がない
画像の取得失敗	テキストと次の操作で用件が分かる
altText を読む	何のお知らせか判断できる
古いカードから操作	最新状態を確認し、無効な操作を止める
連打・同一イベントの再処理	同じ業務処理を重複して成立させない
会員以外が詳細URLを開く	他人の予約や契約内容を見せない
更新担当者が文言を変更	禁止URLや項目欠落を検出できる

効果測定では、クリックだけでなく、リンク先の手続き完了も分けて見ます。インプレッションには表示条件があり、縦に長いカードやリッチメニューとの重なりで計測に影響する場合があります。数値だけで「全員が読んだ」とは判断できません。インプレッション計測の公式説明

Flex Messageという形式自体で一律の追加通数が発生するのではなく、返信・Pushなど送信方式による通数ルールを確認します。開発費、画像制作費、配信費は別項目で見積もると運用後の負担を把握できます。Messaging APIの料金

よくある質問

Flex Messageだけで予約システムを作れますか？

カードは案内や選択の入口になりますが、予約の空き確認、確定、変更、取消にはサーバーや予約DBなどの処理が必要です。ボタンを押しただけで予約が確定する設計にはしません。

Simulatorで見えれば公開できますか？

プレビューは試作に使えますが、実際のLINEでは端末や文字設定によって表示が変わります。リンク、長い文字、画像取得失敗、古いカードの操作も含めて受入確認を行います。

配信後に予約内容が変わった場合はどうしますか？

過去のカードが現在の状態を保証しない前提で、確認先の画面が予約DBの最新情報を表示するようにします。変更・取消の操作も現在の状態と本人の権限を確認して受け付けます。

カードにするとクリック率は上がりますか？

一律には判断できません。用件が分かるか、押した先で手続きを完了できるかを仮説にして、同等の対象・条件で確認します。クリック数と手続き完了数は別に記録します。

この記事に関連するサービス

予約案内や商品紹介のカードを、送信後の操作・更新担当者の作業まで含めて設計したい方は、LINEアプリ開発のサービスをご覧ください。

LINEアプリ開発のサービス・相談窓口を見る