LINE受発注の仕組み｜3方式と法令要件を解説

◆監修・編集責任者　小園 将隆　2026年8月29日

B2B EC-COLUMN

LINE受発注とは｜仕組みを一言で説明する

LINE受発注とは、LINEアプリのトーク画面を入口として、取引先が商品と数量を選んで発注データを送信する仕組みです。受注側は、そのデータを自社の受発注システムや基幹システムで受け取ります。トークに文章で注文を書き込む運用とは異なり、発注内容が項目ごとに構造化されたデータとして届く点が要件になります^*1。

取引先にスマートフォンが広く普及していることも、LINEを受発注の入口に選ぶ企業が増えている背景です。総務省の令和7年通信利用動向調査によれば、世帯のスマートフォン保有割合は91.8%に達しています。また、インターネット利用者の利用目的・用途では「SNS（無料通話機能を含む）の利用」が82.3%と最も高く、LINEもこのSNSに含まれます^*10。

受発注のデジタル化は、業界全体の流れとしても進んでいます。経済産業省の調査によれば、2024年の国内BtoB-EC市場規模は514兆4,069億円（前年比10.6%増）に達し^*11、卸売業のEC化率も40.3%まで上昇しました^*12。

LINE受発注とは発注データが構造化されて届く仕組み

前段で述べたとおり、LINE受発注は「入口」「発注画面」「連携」「受注処理」の4つが噛み合って初めて成立します。基盤となるのは、LINEヤフー株式会社が提供するMessaging API（LINE公式アカウントとプログラムを連携させるための公式インターフェース）です。この上に、発注データを自社サーバーへ届ける経路が組まれている状態を指します^*6。

仕組みは「入口・発注画面・連携・受注処理」の4層でできている

入口はLINE公式アカウントのリッチメニュー（トークルーム内に常設される操作メニュー）です^*7。発注画面はLINEミニアプリと呼ばれるLIFF（LINE Front-end Framework。LINE上でWebアプリを動かす仕組み）上のフォームで、ユーザーはアプリをインストールしなくても利用できます^*8。

連携はMessaging APIのWebhook（特定の操作が起きた際に自社サーバーへ自動でデータを送る仕組み）が担います。受注処理は、自社の受発注システムや基幹システムでの在庫引当・受注確定です^*6。この4層のうちどれか1つでも欠けると、次章で述べる「方式A」の状態にとどまります。

「トークで注文を受けている状態」はLINE受発注ではない

取引先からのメッセージを担当者が読み、手作業で自社システムに転記している状態は、仕組みとしてのLINE受発注ではありません。データが構造化されずにトーク履歴の中に残るため、検索機能の確保や改ざん防止措置といった保存要件^*1を満たしにくく、属人化のリスクも抱えたままになります。

LINE受発注の仕組みを4つの構成要素に分解する

ここからは、前章で示した4層をそれぞれ技術的な裏づけとともに見ていきます。

①入口：LINE公式アカウントとリッチメニュー

リッチメニューは、LINE公式アカウントを友だち追加した全ユーザーに表示される操作パネルです。LINE Developersの公式ドキュメントによれば、Messaging APIを使うことでユーザーごとに異なるリッチメニューをリンクすることもできます^*7。取引先ごとに発注メニューを出し分ける設計も、この機能を前提にしています。

②発注画面：LINEミニアプリ（LIFF上で動くWebアプリ／インストール不要）

発注フォームの実体は、LIFF上で動くWebアプリであるLINEミニアプリです^*8。リッチメニューのボタンからミニアプリへのリンクを開く形にすれば、取引先はLINEアプリの外に出ることなく商品選択・数量入力・納品希望日の指定まで完結できます。

③連携：Messaging APIとWebhook（発注データが自社サーバーへ届く経路）

Messaging APIは、LINE公式アカウントとプログラムをつなぐための機能です。応答メッセージの送信、任意タイミングでのメッセージ送信、複数のメッセージタイプの送受信に対応します^*6。ミニアプリで確定した発注内容はWebhookを通じて自社サーバーへ送られ、ここで初めて「発注データ」として扱える形になります。

④受注処理：基幹・販売管理システムへの取り込みと在庫引当

自社サーバーに届いたデータは、受発注システムや基幹システムに取り込まれ、在庫引当と受注確定の処理を経て取引先への通知に進みます。この受注処理の部分をLINE側の機能だけで完結させることはできず、別途システムを用意する必要があります。

LINE受発注の実現方式は3つ

4層構造を、実際にどう組むかで実現方式は3つに分かれます。方式によって、電子帳簿保存法・取適法への対応しやすさが変わるため、比較の軸として整理します。なお本記事では、方式の比較にとどめ、個別サービス名を挙げた製品比較は行いません。

方式A：トークに手入力で送る（＝仕組み化されていない状態）

取引先が文章でトークに注文内容を書き込み、担当者が読んで転記する運用です。導入コストはかかりませんが、発注データが構造化されないため、前章で触れた保存要件や4条明示の実行が難しくなります。

方式B：LINE公式アカウント＋LINEミニアプリで発注フォームを持つ

リッチメニューからミニアプリの発注フォームを開き、選択式・入力式で発注データを構造化する方式です。LINEの機能だけで完結させやすい一方、商品マスタや取引先別価格をミニアプリ側にも保持・同期する設計が必要になります。

方式C：既存のBtoB EC・受発注システムをLINEから開く（LINEは入口に徹する）

リッチメニューやミニアプリはLINEアプリを開く「入口」に徹し、発注データの構造化・商品マスタ・取引先別価格・与信管理は既存の受発注システム側に持たせる方式です。基幹システムとの連携や法令対応をシステム側に集約できるため、取引条件が複雑なBtoB取引ほど選ばれやすい構成になります。

自社の数字でどの方式が現実的かを確かめるには、無料相談で要件を整理するのが近道です。

発注から受注までの流れを7ステップで追う

方式B・方式Cを前提に、発注から受注確定までの流れを実際の操作順で見ていきます。

1. 取引先がLINE公式アカウントを友だち追加します。
2. リッチメニューから発注画面（ミニアプリ）を開きます^*7・*8。
3. 商品を選び、数量・納品希望日を入力します。
4. 発注内容を確認画面で確定します。
5. 発注データがWebhookで受注側システムへ届きます^*6。
6. 受注側が受注確定と在庫引当を行います。
7. 取引先へ受注確定通知を返します。ここが取適法4条明示の実行点です^*3。

最後の「受注確定通知」が単なる完了報告で終わっていると、4条明示に必要な事項が欠けたままになりやすい工程です。明示事項12項目^*3を通知のテンプレートに組み込んでおくことが、法令対応と業務効率化を両立させる分かれ目になります。

LINE受発注が満たすべき2つの法令要件

LINEでの受発注は、電子帳簿保存法上「電子取引」に該当し、電磁的記録の保存義務が生じます^*1。加えて2026年1月1日に施行された中小受託取引適正化法（取適法。下請代金支払遅延等防止法を改称・改正した法律）が、発注内容の明示義務に新しい選択肢を与えています^*4。取適法は委託事業者に4つの義務を課しており、発注内容等の明示義務（第4条）はそのうちの1つです^*5。この2つの法令を切り分けずに考えると、要件を見落としやすくなります。

電子帳簿保存法：LINEでの受発注は「電子取引」に当たり、データ保存が義務になる

国税庁の電子帳簿保存法一問一答（令和8年7月版）は、「電子取引」を「取引情報の授受を電磁的方式により行う取引」と定義したうえで、その具体例として「いわゆるEDI取引、インターネット等による取引、電子メールにより取引情報を授受する取引（添付ファイルによる場合を含みます。）……インターネット上にサイトを設け、当該サイトを通じて取引情報を授受する取引等」を挙げています^*1。LINEミニアプリを通じた発注データの授受も、この定義に照らして電子取引に当たると考えられます。電子取引に該当する取引情報は、電磁的記録として保存しなければなりません^*1。

保存要件は4項目、改ざん防止措置は4つのうちいずれか1つ

電子取引データの保存要件は、電子計算機処理システムの概要書の備付け・見読可能装置の備付け・検索機能の確保・改ざん防止措置の4項目です^*1。このうち改ざん防止措置は、タイムスタンプの付与や訂正削除の記録が残るシステムの利用など、4つの措置のいずれかを満たせば足ります^*1。なお、基準期間（通常2年前）の売上高が5,000万円以下であれば、取扱いが変わります。税務職員からのダウンロードの求めに応じられる場合は、検索機能の確保が不要になります^*2。

取適法（2026年1月1日施行）：4条明示は書面でも電磁的方法でもよいが、明示事項は12項目

取適法第4条は、委託事業者に対し、中小受託事業者への発注時に「書面の交付、又は……電磁的記録の電磁的方法による提供」により明示事項を示す義務を課しています^*3。明示事項は、名称・委託した日・給付の内容・受領期日・代金の額など12項目です。LINEでの受発注であっても、書面と同等の内容を電磁的方法で示せば要件を満たせると解されます^*3。

電磁的方法で明示しても、書面交付を求められたら遅滞なく交付する必要がある

取適法第4条第2項は、委託事業者が明示事項を電磁的方法で示した場合の規定です。中小受託事業者から書面交付を求められたときは、原則として遅滞なく書面を交付しなければならないと定めています。ただし、中小受託事業者があらかじめ電磁的方法による提供を希望する旨を申し出ている場合など、明示規則で定める場合は例外とされています^*3。LINEでの受発注を仕組み化する際は、この書面交付請求への対応フローも合わせて用意しておく必要があります。個別の取引が電子取引・4条明示のいずれの要件に当たるかの最終判断は、所轄税務署や公正取引委員会・専門家への確認をおすすめします。

「仕組み」として成立させる4つの設計ポイント

法令要件を満たしたうえで、実務として回る仕組みにするための設計ポイントを4点整理します。

誤送信を運用ではなく仕組みで防ぐ

宛先固定・確認画面の設置・送信後の訂正フローをあらかじめ組み込んでおけば、誤送信は運用ルールだけに頼らずに減らせます。とくに取引先ごとにトークルームと発注フォームを分ける設計にしておくと、宛先の取り違えそのものが起こりにくくなります。

従業員の個人アカウント運用から離れる

担当者個人のLINEアカウントで受発注をしていると、担当者交代の際にやり取りの履歴が途切れる問題が起こります。LINE公式アカウントを窓口にし、履歴を組織の資産として残す設計が前提になります。担当者が交代しても取引履歴をそのまま引き継げる状態にしておくことが、属人化を解消する最短の手段になります。

商品マスタ・取引先別価格をどこで保持するか

方式B・方式Cのいずれでも、商品マスタと取引先別価格をどこに置くかは最初に決める設計事項です。取引先別価格を扱う場合は、価格の決定ロジックを受発注システム側に一本化し、ミニアプリには表示だけを担わせる構成にすると、二重管理を避けられます。

発注データの保存場所を最初に決める（LINE側には残らない前提で設計する）

LINE側のトーク履歴は、電子帳簿保存法が求める検索機能・改ざん防止措置を満たす保存先として設計されているわけではありません^*1。発注データは自社サーバーや受発注システム側に保存する前提で設計しておくことが、法令対応の土台になります。

導入前に確認する費用は月額0〜15,000円と周辺コスト

LINE公式アカウントの料金プラン

LINE公式アカウントの料金プランは3段階です。無料のコミュニケーションプランは月額0円で、無料メッセージは200通です^*9。有料プランには、月額5,000円（税別）のライトプラン（同5,000通）と、月額15,000円（税別）のスタンダードプラン（同30,000通）があります^*9。

メッセージ通数で費用が動く構造（受注確定通知を全件返すと通数が伸びる）

無料メッセージ通数を超えた分の追加メッセージを配信できるのは、スタンダードプランのみです。単価は1通あたり3円（税別）が上限で、配信通数が多いほど段階的に安くなる従量制です^*9。コミュニケーションプランとライトプランでは、無料通数を超えた配信はできません^*9。受注確定通知や在庫切れ連絡を取引先全件に返す設計にすると、月間の通数が想定より早く上限に達する場合があります。通知の要否をあらかじめ整理しておくことが、費用試算の精度を左右します。

見落としがちなコスト（商品マスタ整備・取引先への切替案内・並行運用期間）

LINE公式アカウントの月額費用だけでなく、商品マスタの整備、取引先への切替案内、電話・FAXとの並行運用期間にかかる工数も費用として見込む必要があります。これらは導入時に一度だけ発生するものと、並行運用の期間中だけ発生するものに分けて見積もると、試算の精度が上がります。

要件整理を必要な作業に絞り込むには、無料相談で自社の要件を整理することをおすすめします。

まとめ：LINE受発注を仕組み化する3つの判断軸

本稿では、LINE受発注の仕組みと実現方式、法令要件を整理しました。要点は3つに集約できます。第一に、LINE受発注は入口・発注画面・連携・受注処理の4層で構成され、いずれか1層でも欠けると仕組みとして成立しません。第二に、実現方式は3つあり、自社の商習慣が複雑になるほど既存システムをLINEの奥に置く方式Cが選ばれやすくなります。第三に、電子帳簿保存法の保存義務と取適法4条明示は、方式を選ぶ段階から織り込んでおく必要があります^*1・*3。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

個人のLINEアカウントで受発注をしても問題ありませんか。

法令上は個人アカウントを直接禁じる規定はありませんが、実務上は避けることをおすすめします。担当者交代で履歴が途切れる、電子帳簿保存法の保存要件^*1を満たす仕組みが用意しにくいといった課題が残るためです。

LINEでやりとりした注文の記録は、どのくらい保存する必要がありますか。

LINEでの受発注が電子帳簿保存法上の電子取引に該当する場合、法人税法・所得税法上の帳簿書類の保存期間に準じて電磁的記録を保存する必要があります^*1。保存期間の具体的な取扱いは、事業形態によって異なるため、所轄税務署にご確認ください。

売上高が小さい事業者でも、検索機能の確保は必要ですか。

基準期間（通常2年前）の売上高が5,000万円以下であれば、取扱いが変わります^*2。税務職員からのダウンロードの求めに応じられるようにしている場合は、検索機能の確保が不要になります。該当するかどうかは自社の基準期間の売上高を確認したうえで判断します。

LINEで発注書を送れば、取適法の4条明示を満たしますか。

明示事項12項目をすべて含んだ内容を電磁的方法で示していれば、4条明示の要件を満たすと考えられます^*3。ただし中小受託事業者から書面交付を求められた場合は、原則として遅滞なく書面を交付する義務が別途あります。中小受託事業者があらかじめ電磁的方法による提供を希望する旨を申し出ている場合など、明示規則で定める場合は例外とされます^*3。

LINE受発注は、既存の基幹システムと連携できますか。

Messaging APIのWebhookを使えば、発注データを自社サーバーに送り、そこから基幹システムへ取り込む連携は技術的に可能です^*6。連携の設計は既存システムの仕様に依存するため、自社の要件を整理したうえで検討することをおすすめします。

1. *1　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和8年7月）https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/pdf/0026007-006_05.pdf
2. *2　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」問19（令和8年7月）https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/pdf/0026007-006_05.pdf
3. *3　出典：公正取引委員会・中小企業庁「中小受託取引適正化法テキスト」（令和7年11月）https://www.jftc.go.jp/toriteki/r7text.pdf
4. *4　出典：中小企業庁（ミラサポplus）「【2026年1月1日施行】受注者を守る法！手形払い禁止など『取適法』がもたらす変化」https://mirasapo-plus.go.jp/infomation/30416/
5. *5　出典：公正取引委員会「委託事業者の義務」https://www.jftc.go.jp/toriteki/toritekigaiyo/oyagimu.html
6. *6　出典：LINEヤフー株式会社 LINE Developers「Messaging APIの概要」https://developers.line.biz/ja/docs/messaging-api/overview/
7. *7　出典：LINEヤフー株式会社 LINE Developers「リッチメニューを使う」https://developers.line.biz/ja/docs/messaging-api/using-rich-menus/
8. *8　出典：LINEヤフー株式会社 LINE Developers「LINEミニアプリについて」https://developers.line.biz/ja/docs/line-mini-app/discover/introduction/
9. *9　出典：LINEヤフー株式会社「LINE公式アカウント 料金プラン」https://www.lycbiz.com/jp/service/line-official-account/plan/
10. *10　出典：総務省「令和7年通信利用動向調査 ポイント」（令和8年5月29日公表）https://www.soumu.go.jp/main_content/001074767.pdf
11. *11　出典：経済産業省「令和6年度 電子商取引に関する市場調査」（2025年8月26日公表）https://www.meti.go.jp/press/2025/08/20250826005/20250826005.html
12. *12　出典：経済産業省「令和6年度 電子商取引に関する市場調査」報告書 p.94「⑤卸売」https://www.meti.go.jp/policy/it_policy/statistics/outlook/250826_houkokusho.pdf