Messaging APIでFlex Messageを送る方法｜JSON作成から本番配信まで解説

マーケティング担当者から「LINE公式アカウントでアプリUIのようなデザイン性に富んだメッセージを配信したい」と急に企画書を渡され、何から手をつければいいか焦っていませんか。いざ実装しようと公式ドキュメントを開くと、複雑なJSONオブジェクトの階層構造が並んでおり、目の前が暗くなったエンジニアの方も少なくないはずです。

本番環境のユーザーへ直接届くプッシュ配信だからこそ、表示崩れやシステムのエラーは避けたいところです。しかし、断片的な技術ブログを繋ぎ合わせて手動コーディングを繰り返す進め方では、不具合の温床になりかねません。LINE開発全体の流れから整理したい場合は、先にLINE開発の流れをまとめた記事も確認しておくと、Messaging APIとFlex Messageの位置づけを把握しやすくなります。

結論から申し上げますと、複雑な仕様をすべて暗記する必要はありません。公式ツールである「Flex Message Simulator」を起点にし、生成されたJSONをMessaging APIの送信処理へつなげるワークフローを導入すれば、表示崩れや送信エラー（400 Bad Request）のリスクを抑えながら実装を進められます。本記事では、仕様の沼にハマることなく、安全かつ効率的に本番配信を成功させるための実践的なロードマップを、シニア・LINEソリューションアーキテクトの知見を交えて解説します。

著者プロフィール
【氏名】三島 健太（みしま けんた）
【肩書き】シニア・エンタープライズLINEソリューションアーキテクト
【専門領域】LINE Messaging APIを用いた大規模配信システムの設計、CRM連携、Flexboxレイアウト最適化
【主な実績】大手ECおよび次世代SaaSプロダクトにおいて、月間1000万通規模のFlex Message配信基盤の構築をリード。エンジニア向けにLINE APIのトラブルシューティング記事を多数執筆。
仕様の難解さに悩む現場エンジニアの痛みに共感しつつ、実務で使いやすい実装ステップとバグ回避の急所をロジカルに伝えます。

技術的正確性に関するお知らせ
本記事は、2026年5月時点でLINEヤフー株式会社が公開している公式開発者ドキュメント（LINE Developers）を確認し、主要な仕様・制限・用語をできる限り公式情報に沿って整理しています。管理画面の名称や仕様は変更される可能性があるため、実装前には必ず公式ドキュメントもあわせて確認してください。

---

なぜFlex Messageの実装は挫折しやすいのか？エンジニアがハマる「3つの罠」

LINEのFlex Messageは、一見するとCSSに似ていますが、実態はJSONで定義する独自のメッセージレイアウトです。私もかつて、1つのメッセージを組むために手動で数百行のJSONを書き、原因不明の400エラーで徹夜をしました。だからこそ、最初から手動で全構造を書き切る進め方はおすすめしません。最短への道は、公式シミュレーターを正しく使うことから始まります。

現場のエンジニアが公式ドキュメントを愚直に読み込もうとした結果、開発の現場で高確率で直面する「3つの罠」を紐解いていきましょう。

罠1：数百行のJSONを手動記述してブラケット迷子になる罠

Flex Messageは、外枠となるコンテナの中に複数の要素が幾重にも重なる「入れ子構造（ネスト）」を持っています。これを使い慣れたコードエディタで1からタイピングしていくと、中括弧（{}）や角括弧（[]）の対応関係がすぐに破綻します。構文エラーのチェックだけに時間を奪われ、本来のロジック構築に集中できなくなるのが典型的な最初の挫折ポイントです。

罠2：PCのプレビューだけを信じて実機での文字切れで爆死する罠

PCのブラウザ上で動く開発ツールの画面では完璧に表示されていたとしても、画面幅の狭いスマートフォン実機（iPhoneやAndroid）に配信した途端、テキストが途中で切れたり、ボタンがはみ出したりするレイアウト崩れが発生することがあります。これは、メッセージのレンダリングが受信者の端末環境、OS、LINEアプリのバージョン、画面解像度、言語設定、フォントなどの影響を受けるためです。固定値だけで組まず、実機確認を前提にした設計が必要です。

罠3：型指定のケアレスミスで原因不明の「400 Bad Request」の沼にハマる罠

プログラム側からAPIサーバーへリクエストを投げた際、最も多くの開発者を苦しめるのが「400 Bad Request」です。LINEのAPIサーバーは、データ型に対して厳格です。「余白を設定するプロパティだから数値型（10）で渡せばいいだろう」と思い込んで送信すると、仕様が定める文字列型（”10px” や “md”）ではないという理由で、リクエストが拒否される可能性があります。

---

レイアウトの基本はCSS Flexbox！Boxコンポーネントの配置原則

難解に見えるFlex Messageの構造ですが、公式ドキュメントではCSS Flexible Box（CSS Flexbox）の仕様を基に自由にレイアウトをカスタマイズできると説明されています。つまり、普段からWebフロントエンドの開発で馴染みのあるFlexboxの概念を応用すれば、構造理解のブレイクスルーを起こすことができます。

すべてのデザインの土台となるのが「box（ボックス）コンポーネント」です。このボックスコンポーネントの内部に、テキストや画像といった子要素を配置していきます。配置の方向を決定づけるのが layout 属性です。layout 属性には、主に以下の3つのコア値が存在します。

• horizontal（横並び）: 子要素を左から右へと水平方向に並べます。
• vertical（縦並び）: 子要素を上から下へと垂直方向に並べます。
• baseline（文字の基準線合わせ）: テキストコンポーネントなど、高さの異なる文字の底辺（ベースライン）を一直線に揃えて横並びにします。

どんなに複雑に見えるアプリUIライクなメッセージであっても、Flex Messageのレイアウトの本質は「縦並びボックスの中に、横並びボックスを入れる」という入れ子構造の繰り返しです。Flex Messageの前にMessaging APIの初期設定が不安な場合は、Messaging API設定の基本手順を先に済ませておくと、この後の実装がスムーズになります。

---

実務最高効率：Simulatorから本番コードへ最短で繋ぐ「4ステップ」

実務で今日からトレースできるよう、エラーが少なく開発スピードを上げやすい具体的なワークフローを4つのステップに分けて解説します。

Step 1：雛形の選定

まずは、LINE公式が提供している「Flex Message Simulator」へアクセスします。画面左上のメニューにある「Showcase（ショーケース）」をクリックすると、レストランの予約確認、領収書、電報風など、実務でよく使われる既製テンプレートが用意されています。マーケティング担当者から渡された企画書のデザインに最も近いものを1つ選び、ベースの雛形として読み込みます。

Step 2：GUI上でのデザイン調整

シミュレーターの画面右側には、コンポーネントのツリー構造がグラフィカルに表示されます。コードを1文字も書くことなく、要素の追加や削除、フォントサイズ（size）やカラーコード（color）、要素間の余白（spacing）をマウス操作とプロパティの入力だけで調整できます。この段階で、マーケティング側の要望を満たすデザインのモックアップをGUI上で仕上げます。

Step 3：JSONエクスポート

デザインが完成したら、シミュレーター画面の右上にある「View JSON」ボタンをクリックします。すると、現在のデザインを再現するためのJSON Payload（データ構造）が表示されます。ここに出力されるJSONデータは、公式ツール上で生成された構造のため、手動で最初から書くよりも構文ミスを減らしやすい点が大きなメリットです。表示されたJSONを丸ごとクリップボードにコピーします。

Step 4：動的プログラム化

コピーしたJSON Payloadを、自社システムの配信プログラムへ組み込みます。ユーザーごとに動的に変更する必要がある部分（例：「〇〇様」というユーザー名、個別トークン付きの決済URL、動的な画像URLなど）を、あらかじめプレースホルダー（例：{{userName}} や {{targetUrl}}）に変えておきます。

APIを叩く直前に、プログラムの文字列置換処理を用いてこれらのプレースホルダーを実際の変数データに置き換え、LINEの公式ライブラリ（LINE Bot SDK / @line/bot-sdk）などのメッセージオブジェクトへ流し込みます。TypeScriptで型を見ながら実装したい場合は、LINE BotのTypeScript実装手順もあわせて確認すると、SDKとMessaging APIの関係を整理しやすくなります。

シミュレーターからエクスポートしたJSONをベースに文字列置換を行う手法を採用すると、複雑なクラスオブジェクトをプログラム側で毎回インスタンス化して組み立てる必要が減ります。ただし、ユーザー入力をそのままJSON文字列へ埋め込む場合は、改行・引用符・特殊文字のエスケープ処理に注意してください。テンプレート化の利便性と、入力値の安全な処理をセットで考えることが重要です。

---

【トラブルシューティング】実機での表示崩れと「400 Bad Request」の防ぎ方

実装の最終フェーズや、本番配信直前のテスト配信において、エンジニアを襲いがちな致命的バグの発生メカニズムと、それを未然に防ぐための防衛策を提示します。Webhook URLやアクセストークンの設定が未整理な場合は、Messaging API Webhookの設定方法も確認しておくと、通信面の切り分けがしやすくなります。

1. 実機での表示崩れ（文字切れ）の防ぎ方

PCのシミュレーター画面は解像度が高いため文字が綺麗に収まりますが、画面幅の狭いスマートフォン実機では、長いテキストが枠外へはみ出して消えてしまうバグが発生することがあります。実機での文字切れを防ぐには、Textコンポーネントの wrap プロパティを true に指定してください。wrap: true を設定すると、端末の画面幅に応じてテキストが自動的に改行（折り返し）され、表示崩れを抑えやすくなります。

あわせて、固定幅の多用も避けましょう。公式ドキュメントでは、バブルの幅は端末画面に依存するため、全体レイアウトの調整にピクセル指定の width を使うと予期しない表示になる可能性があると説明されています。できるだけ flex プロパティや折り返しを活用し、複数端末で確認してください。

2. データ型チェックの厳格化による「400 Bad Request」の回避

前述の通り、プロパティへ渡す値のデータ型ミスは400エラーの大きな原因です。特に、要素のサイズを指定する際、CSSの感覚で数値をそのまま入力しないよう注意が必要です。以下の比較表を参考に、データ型の正確性を常に意識してください。

📊 比較表
表タイトル: 400エラーを防ぐJSON記述のOK/NGパターン対比

プロパティ名	400エラーになるNGコード例	正常に送信できるOKコード例	原因と仕様ルールの解説
margin（余白）	“margin”: 10（数値型）	“margin”: “10px”（文字列型）	単位を含む値、または仕様で定義されたキーワード文字列での指定が必要です。
size（文字サイズ）	“size”: 14（数値型）	“size”: “14px” または “md”（文字列型）	Textコンポーネントの size は、ピクセル値またはキーワードを文字列で指定します。
altText	Flex Messageで altText を未指定	“altText”: “予約内容を確認してください”	Flex Messageでは、通知や未対応環境向けに代替テキストが必要です。

3. ペイロードサイズ制限（30KBの壁）の意識

表現力を豊かにしようとするあまり、1つのメッセージの中に大量のBoxを詰め込んだり、複数のカードを横に並べる「カルーセル構造」で最大数（12個）のバブルを連結したりすると、データサイズの上限に近づきます。LINE公式の過去アナウンスでは、Flex Messageのバブルを定義するJSONデータの最大サイズが30KBに変更されたと案内されています。カルーセルの最大バブル数も12個とされていますが、上限いっぱいに詰め込むほど実機の視認性やデータサイズの面で不利になります。

不要なデフォルトプロパティ（初期値と同じ設定値）はシミュレーターからエクスポートした後に削除し、画像URLを短く保つなど、データの軽量化を心がけてください。本番公開前のサーバー構成や環境変数管理まで確認したい場合は、LINE開発のデプロイ手順も参考になります。

✍ “専門家の経験からの一言アドバイス”
【結論】: 本番配信のシステムを組む際は、APIの送信処理の直前に、生成されたJSON文字列のバイトサイズを計測してログに出力するコードを仕込んでおいてください。
なぜなら、この点は多くの人が見落としがちだからです。テスト環境では少ないデータ量で動いていたシステムが、本番環境で長いテキストや画像URLを流し込んだ瞬間にサイズ上限へ近づき、本番環境でのみ配信失敗を起こすことがあります。事前にサイズを監視しておく考え方が、実務での安定運用を支えます。この知見が、あなたの成功の助けになれば幸いです。

---

もう複雑なレイアウトに怯えない：スマートな実装でマーケの期待に応えよう

LINE公式アカウントの可能性を大きく広げるFlex Messageですが、実装において難解な公式リファレンスと正面から戦い続ける必要はありません。

1. 手動でのコーディングを最小限にし、「Flex Message Simulator」をデザインとJSON生成の起点として活用すること。
2. 配置のルールは「CSS Flexbox」の地続きであると理解し、縦並び（vertical）と横並び（horizontal）のネストを整理すること。
3. 実機での文字切れを防ぐ wrap: true の確認と、厳格なデータ型チェックによって 400 Bad Request を未然に防ぐこと。

このロードマップを押さえておけば、仕様の沼にハマって徹夜をするリスクを減らせます。マーケティング担当者からの高度なデザイン要求に対しても、エンジニアとして冷静に要件を分解し、スマートに本番環境への配信を進めていきましょう。

Messaging API Flex Messageに関するよくある質問 (FAQ)

Flex Messageの実装でつまずきやすいポイントを、Q&A形式でまとめました。本番配信前の最終確認にも活用してください。