AWS オムニチャネルフォールバックソリューションへの LINE Messenger の追加

本記事は 2026 年 6 月 5 日 に公開された「Adding LINE Messenger to your AWS omnichannel fallback solution」を翻訳したものです。

本記事では、既存のオムニチャネルフォールバックソリューションに LINE Messenger を統合して拡張する方法を説明します。アーキテクチャの変更点、デプロイ手順、テスト手順についても取り上げます。元のソリューションは Amazon API Gateway、AWS Lambda、Amazon Simple Email Service (Amazon SES)、AWS End User Messaging で構築されており、SMS、WhatsApp、メールを横断して自動フォールバック機能付きでメッセージを配信します。

本記事が拡張対象とする元のオムニチャネルフォールバックソリューションについては、Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS を参照してください。

LINE Messenger を選ぶ理由

LINE は日本、台湾、タイで広く使われているメッセージングプラットフォームであり、主要市場での月間アクティブユーザー数は 1 億 8,100 万人、うち日本だけで 1 億人に達します (LY Corporation FY2025 Q3 業績データ)。DAU/MAU 比率は 84% (日本では 88%) と高く、毎日活発に利用されているため、医療分野の予約リマインダー、EC の注文・配送通知、小売のプロモーションキャンペーンなど、タイムリーなコミュニケーションに適したチャネルです。

APAC には KakaoTalk (韓国)、WeChat (中国)、Zalo (ベトナム)、Viber (フィリピン) といった各国で人気のメッセージングプラットフォームが存在しますが、LINE は日本・台湾・タイの 3 市場で同時に強い存在感を持っており、これらの国々を対象としたマルチチャネルメッセージング戦略に高い効果をもたらします。オムニチャネルフォールバックソリューションに LINE を追加することで、各市場のユーザーが好むチャネルでリーチできるようになります。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、他のチャネルで実装済みのフォールバック・ブロードキャストのパターンをそのまま活用できます。

費用について: LINE Messaging API の料金は国やプランによって異なります。各チャネルの詳細は LINE Messaging API、Amazon Simple Email Service (Amazon SES)、Amazon End User Messaging の料金ページをご覧ください。

アーキテクチャの概要

フォールバックソリューションに LINE を追加することで、単一の API エンドポイントから 4 つの主要メッセージングチャネルをカバーできます。既存の複雑さを増やさずにリーチを広げられる点が特長です。LINE の統合は既存チャネルと同じイベント駆動型のサーバーレスパターンに従います。次の図はアーキテクチャへの主な追加点を示しています。

図 1: LINE Messenger を追加した更新後のオムニチャネルアーキテクチャ (新規コンポーネントをハイライト表示)

既存のアーキテクチャに 2 つの要素を追加するだけで、LINE ユーザーにリーチできます。

LINE Messaging API の統合 – Primary Handler Lambda と Secondary Handler Lambda に send_line モジュールが追加され、Push Message エンドポイントを通じて LINE Messaging API でメッセージを配信します。

AWS Secrets Manager の統合 – LINE チャネルの認証情報 (アクセストークンとチャネルシークレット) は AWS Secrets Manager に安全に保存され、Lambda 関数がキャッシュを活用して取得します。

LINE 統合の仕組み

LINE Messenger の統合は既存のメッセージ処理パイプラインを拡張する形で実装されているため、メール、SMS、WhatsApp と同じ信頼性の高いフォールバック動作が LINE でも利用できます。以下のセクションでは、システムが LINE メッセージとフォールバックシナリオをどのように処理するかを説明します。

LINE メッセージの送信

LINE をプライマリまたはフォールバックチャネルとしてメッセージを送信する場合、LINE 固有の処理を含む同じパターンに従います。

1. API Gateway がリクエストを受信し、Primary Amazon Simple Queue Service (Amazon SQS) キューに追加します。
2. Primary Handler Lambda がチャネルを “line” と検出し、send_line モジュールを呼び出します。
3. send_line モジュールが Secrets Manager から LINE の認証情報をキャッシュ付きで取得し、LINE Messaging API の Push Message エンドポイントにリクエストを送信します。Push Message API はユーザーが先にメッセージを送ることなく LINE ユーザーへのメッセージ送信を可能にします。リクエストボディには受信者の LINE ユーザー ID (ユーザーが LINE 公式アカウントをフォローした際に割り当てられる一意の識別子) を含む to フィールドと、配信するメッセージオブジェクトを格納した messages 配列が含まれます。モジュールは LINE API を呼び出す前に、受信者の LINE ユーザー ID が期待されるフォーマット (大文字の ‘U’ に続く 32 文字の小文字 16 進数文字) と一致するか検証します。不正な受信者 ID のリクエストは早期に拒否され、外部 API に到達しません。
4. Lambda 関数がメッセージのステータスを Amazon DynamoDB テーブルに記録します。
5. フォールバックが設定されている場合、Lambda 関数はメッセージをフォールバックキューにエンキューします。このエンキューは LINE API 呼び出しが成功 (HTTP 200) した場合でも失敗 (200 以外のレスポンス、タイムアウト、または例外) した場合でも実行されます。DynamoDB には成功時に delivered、失敗時に failed としてメッセージステータスが記録されます。Secondary Handler は DynamoDB を確認し、ステータスが delivered でない場合にフォールバックチャネルで送信します。
6. Secondary Handler が DynamoDB のステータスを sent_fallback に更新します。

LINE と他チャネルの違い

LINE は AWS ネイティブの IAM 認証ではなく独自の認証を持つ外部 API を使用します。そのため、認証情報の管理には IAM ではなく AWS Secrets Manager を使用する必要があります。詳細は LINE Messaging API ドキュメントを参照してください。

LINE はビジネス向けに 2 種類のメッセージングプロダクトを提供しています。LINE Messaging API と LINE Official Notification です。

• LINE Messaging API は本ガイドの対象であり、双方向の会話型メッセージングをサポートし、モバイルオーダー、ロイヤルティプログラム、カスタマーエンゲージメントなど多くの業種で広く採用されています。LINE には LINE Official Notification (LINE 通知メッセージとも呼ばれる) という別サービスもあり、配送状況通知や予約リマインダーといった一方向のトランザクション通知向けに設計されていますが、ビジネス認証が必要です。
• LINE Official Notification はメッセージごとの配信完了イベントを提供しますが、LINE Messaging API にはその機能がありません。Messaging API では HTTP 200 レスポンスが LINE によるメッセージ受け付けを示しており、これが利用可能な最も詳細な配信シグナルです。

LINE Messaging API チャネルの作成

LINE 統合でメッセージを認証・送信するには LINE Messaging API チャネルが必要です。手順は以下のとおりです。

1. LINE Developers Console にサインインします。アカウントをお持ちでない場合は 個人 LINE アカウントを作成し、対応する iOS/Android/PC アプリをダウンロードします。LINE メッセージの受信テストに必要です。
2. プロバイダーを作成します (会社名または組織名)。
   
   
3. そのプロバイダーの下に新しい Messaging API チャネルを作成します。
   
   
4. チャネル作成後、LINE Official Account Manager ページから Messaging API を有効化します。
   
   
5. チャネル設定から以下の情報を控えます。
   1. チャネルアクセストークン (Messaging API タブで [Issue] を選択)
      
      
      
      
   2. チャネルシークレット ([Basic settings] タブ)
      
      
6. Messaging API 設定で Auto-reply と Greeting messages を無効にします。
   
   

デプロイとテスト

リポジトリには、CDK スタックのデプロイ、AWS Secrets Manager での LINE 認証情報の設定、個人の LINE ユーザー ID の取得、インテグレーションテストスイートの実行まで、手順を詳しく説明したデプロイガイドが含まれています。テストスイートは設定済みのチャネルを自動的に検出し、対応するテストを実行します。デプロイとテストの詳細については、リポジトリのデプロイガイドを参照してください。

セキュリティに関する考慮事項

本ソリューションを本番環境にデプロイする前に、以下の考慮事項をワークロードとコンプライアンス要件に照らして確認してください。

最小権限の IAM

サンプルの Lambda 実行ロールは、DynamoDB、Amazon SQS、AWS Secrets Manager のアクセス許可を特定のリソース ARN にスコープしています。Amazon SES (ses:SendEmail、ses:SendTemplatedEmail)、SMS (sms-voice:SendTextMessage)、WhatsApp (social-messaging:SendWhatsAppMessage) の送信アクションは、このサンプルでは特定の送信 ID、電話プール、WhatsApp ビジネスアカウントを設定可能な状態にするため、シンプルに resources: [“*”] で付与しています。本番環境では API がサポートする範囲でさらにスコープを絞ってください。SES は ID レベルの ARN (例: arn:aws:ses:region:account:identity/example.com) をサポートし、End User Messaging SMS はプールおよび電話番号 ARN をサポートします。このコードを適用する際は、サポートされているすべての項目にリソースレベルのスコープを維持し、本番デプロイ向けの AWS Well-Architected セキュリティの柱と Lambda 実行ロールのガイダンスを確認してください。

LINE 認証情報のローテーション

LINE チャネルアクセストークンは有効期限が長く、LINE Developers Console からの手動発行・ローテーションのみサポートされています。プログラムによるローテーション API はありません。組織のキーローテーションポリシー (例: 90 日ごと) に沿って定期的にトークンをローテーションし、Secrets Manager のシークレットを新しい値に更新してください。また、キャッシュされた認証情報が更新されるよう、Lambda のコールドスタートを強制してください (スタックの再デプロイまたは Lambda 環境変数の更新による)。

データ保護と個人情報の保持

本ソリューションは、LINE ユーザー ID、電話番号、メールアドレスなどのメッセージメタデータと受信者識別子を Amazon DynamoDB に保存します。DynamoDB は保存時の AWS マネージド暗号化を使用し、Secrets Manager は AWS Key Management Service (AWS KMS) を使用します。また、LINE API へのすべての送信呼び出しは HTTPS で行われます。メッセージテーブルでは Point-in-time recovery が有効です。

本サンプルでは DynamoDB の Time-to-Live (TTL) 属性を設定していないため、レコードは無期限に保持されます。本番環境では、保持ポリシーに合った TTL 属性 (例: expiresAt) を追加し、テーブルの RemovalPolicy.RETAIN 設定がお使いの環境に適切かどうかを確認してください。LINE ユーザー ID、電話番号、メールアドレスは、日本の個人情報保護法 (APPI)、EU の GDPR をはじめとする各種規制において個人情報に該当します。サービス提供地域ごとの保持義務、データレジデンシー要件、データ主体からのアクセスおよび削除リクエストへの対応プロセスを検討してください。

まとめ

オムニチャネルフォールバックソリューションに LINE Messenger を追加することで、メール、SMS、WhatsApp、LINE という重要な 4 つのメッセージングチャネルで顧客にリーチできるようになりました。統合は既存チャネルと同じサーバーレス・イベント駆動型のパターンに従っているため、デプロイと運用がシンプルです。LINE はプライマリチャネルとしてもフォールバックチャネルとしても利用でき、地域の好みに合わせたメッセージング戦略を柔軟に構築できます。次のステップとして、他の地域向けメッセージングサービスを追加してリーチをさらに拡大することを検討してください。また、リッチメッセージ、クイックリプライ、Flex Messages など LINE の高度な機能を活用することで、より魅力的なカスタマーインタラクションを実現できます。

リソース

• GitHub リポジトリ
• Enhancing Message Reach: An Omnichannel Approach Using WhatsApp, SMS, and Email with AWS
• LINE Developers ドキュメント
• AWS CDK ドキュメント

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Katsuya Matsuoka がレビューしました。