本記事は 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 固有の処理を含む同じパターンに従います。 API Gateway がリクエストを受信し、Primary Amazon Simple Queue Service (Amazon SQS) キューに追加します。 Primary Handler Lambda がチャネルを “line” と検出し、 send_line モジュールを呼び出します。 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 に到達しません。 Lambda 関数がメッセージのステータスを Amazon DynamoDB テーブルに記録します。 フォールバックが設定されている場合、Lambda 関数はメッセージをフォールバックキューにエンキューします。このエンキューは LINE API 呼び出しが成功 (HTTP 200) した場合でも失敗 (200 以外のレスポンス、タイムアウト、または例外) した場合でも実行されます。DynamoDB には成功時に delivered 、失敗時に failed としてメッセージステータスが記録されます。Secondary Handler は DynamoDB を確認し、ステータスが delivered でない場合にフォールバックチャネルで送信します。 Secondary Handler が DynamoDB のステータスを sent_fallback に更新します。 LINE と他チャネルの違い 項目 メール SMS WhatsApp LINE API Amazon SES SendEmail API AWS End User Messaging SendTextMessage API AWS End User Messaging Social SendWhatsAppMessage API LINE Messaging API Push Message API 認証 IAM ロール IAM ロール IAM ロール Secrets Manager 経由のチャネルアクセストークン 外部メッセージ ID のマッピング 不要。 SES は配信コールバックで同じメッセージ ID を返します。 不要。 SMS は配信コールバックで同じメッセージ ID を返します。 必要。 WhatsApp は配信 Webhook で異なるプラットフォームメッセージ ID を返すため、内部の AWS メッセージ ID へのマッピングが必要です。 不要。 配信コールバックがないため、メッセージ ID の紐付けは不要です。 認証情報の保存 IAM (自動) IAM (自動) IAM (自動) Secrets Manager (手動) 配信追跡 SES 配信イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) End User Messaging イベント経由の非同期処理 (SNS コールバックが DynamoDB を更新) なし。LINE API からの 200 レスポンス時に即時 delivered に設定。LINE Messaging API には配信 Webhook なし。 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 チャネルが必要です。手順は以下のとおりです。 LINE Developers Console にサインインします。アカウントをお持ちでない場合は 個人 LINE アカウント を作成し、対応する iOS/Android/PC アプリをダウンロードします。LINE メッセージの受信テストに必要です。 プロバイダーを作成します (会社名または組織名)。 そのプロバイダーの下に新しい Messaging API チャネルを作成します。 チャネル作成後、LINE Official Account Manager ページから Messaging API を有効化します。 チャネル設定から以下の情報を控えます。 チャネルアクセストークン (Messaging API タブで [Issue] を選択) チャネルシークレット ([Basic settings] タブ) 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 ドキュメント 著者について Rommel Sunga シンガポール拠点の AWS シニア Solutions Architect。AWS End User Messaging と Amazon Simple Email Service を専門とし、スケーラブルで信頼性の高いコミュニケーションソリューションの構築をお客様と共に取り組んでいます。クラウドベースのメッセージングアーキテクチャの専門知識を活かし、組織のカスタマーエンゲージメント向上を支援しています。 Katsuya Matsuoka 日本拠点の AWS Solutions Architect。メディア業界のお客様を担当しており、レイクハウスアーキテクチャを含むデータ分析を中心に取り組んでいます。 Pavlos Ioannou Katidis Amazon Simple Email Service (SES) と AWS End User Messaging を専門とする AWS シニアスペシャリスト Solutions Architect。スケーラブルで回復性の高いソリューションの設計を得意とし、大規模コミュニケーションシステムやオムニチャネルフレームワークの構築に注力しています。幅広く採用されている AWS ワークショップ、ブログ、技術ソリューションを執筆し、生成 AI を活用した社内ツールの開発でプロセス効率化と生産性向上に貢献しています。re:Invent では、耐障害性の高い通知システム、ワンタイムパスワードの実装、大量メッセージングのベストプラクティスをテーマに登壇。テニス、ウォーキング、個人のコーディングプロジェクトを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Katsuya Matsuoka がレビューしました。

はじめに こんにちは。開発本部でデリッシュキッチンの Android アプリ開発を担当している岡田です。 アプリを運用していると、リリースのたびに Crashlytics とにらめっこする時間が必ず発生します。クラッシュの一覧を眺めて、優先度を決めて、スタックトレースを読んで、該当コードを探して、原因を考えて、直す。やること自体は明確なのですが、ダッシュボードとエディタを行き来する手作業が地味に重く、件数が増えると後回しになりがちでした。 本記事では、公式の Firebase MCP サーバー が提供する Crashlytics ツールを Claude Code から使い、この一連の流れ（トリアージ → 原因分析 → 該当コード特定 → 修正 PR のドラフト作成）を半自動化した話を紹介します。特定の社内事例に依存しない、誰でも再現できる手順としてまとめました。Android / iOS で Crashlytics を使っていて、AI コーディングツールを業務に取り込みたい方の参考になればうれしいです。 目次 はじめに 背景：クラッシュ対応のどこが手間か Firebase Crashlytics MCP とは セットアップ 前提 Claude Code への MCP 登録 クラッシュ対応フロー：半自動化の中身 1. トリアージ：上位クラッシュを一覧する 2. 深掘り：スタックトレースと発生状況を取得 3. 突き合わせ：原因仮説と該当コードの特定 4. 修正と PR ドラフト作成 運用ノウハウ / つまづきポイント ツールは --only crashlytics で絞る CI / サービスアカウント認証では 404 に注意 プラットフォームによってツールが出ないことがある Experimental ゆえのバージョン固定 どこまで任せるか（“半” の線引き） まとめ 参考リンク 背景：クラッシュ対応のどこが手間か クラッシュ対応そのものは難しい作業ばかりではありません。むしろ「手間」の多くは、判断と判断のあいだにある移動コストでした。具体的には次のようなところです。 ツールの往復 ：Crashlytics（ブラウザ）でクラッシュを確認し、エディタに戻って該当箇所を探し、また Crashlytics に戻って影響範囲を見る、という往復が多い。 スタックトレースとコードの突き合わせ ：難読化されたスタックトレースから当たりをつけ、リポジトリの該当コードまで辿るのは、慣れていても地味に時間がかかる。 トリアージの属人性 ：「どのクラッシュから手を付けるか」の判断が、見る人によってブレる。影響端末・OS バージョン・発生数を毎回手で確認するのも面倒。 この「往復」と「突き合わせ」を AI に任せられれば、人間は 原因の判断と最終レビュー に集中できます。そこで MCP の出番です。 Firebase Crashlytics MCP とは MCP（Model Context Protocol） は、AI クライアントに外部ツールやデータソースを接続するための共通規格です。Firebase は公式に Firebase MCP サーバー を提供しており、その中に Crashlytics 用のツール群が含まれています。 このサーバーを AI クライアントに繋ぐと、ダッシュボードを開かなくても、AI との対話の中でクラッシュデータを取得・更新できるようになります。対応クライアントは Claude Code / Claude Desktop / Gemini CLI / Cursor / VS Code Copilot など幅広く、本記事では Claude Code を使います。 公式ドキュメント時点で提供されている主な Crashlytics ツールは以下のとおりです。 ツール名 役割 crashlytics_get_report 期間や条件を指定してクラッシュレポート（上位 issue など）を取得 crashlytics_get_issue 特定の issue の詳細を取得 crashlytics_list_events issue に紐づくイベント（スタックトレース等）を一覧取得 crashlytics_batch_get_events 複数イベントをまとめて取得 crashlytics_update_issue issue の状態（クローズ等）を更新 crashlytics_list_notes / crashlytics_create_note / crashlytics_delete_note issue へのメモの参照・追加・削除 加えて、 crashlytics:connect という対話的なガイド付きワークフローも用意されており、「どのクラッシュを優先すべきか」といった相談ベースの使い方もできます。Google I/O 2026 では、これらを束ねた Crashlytics の Agent Skills も発表され、IDE から離れずにデバッグ支援を受けられる方向に進んでいます。 ⚠ 注意 ：Crashlytics の MCP 機能は Experimental（実験的） です。SLA や非推奨ポリシーの対象外で、ツール名や挙動が変わる可能性があります。本記事の内容も執筆時点（2026 年 6 月）のものです。 セットアップ 前提 Node.js / npm（Firebase CLI のインストールに使用） Firebase CLI をインストールし、認証済みであること。Firebase MCP サーバーは Firebase CLI と同じ認証情報 を使います。未導入なら以下を実行します。 # Firebase CLI をインストール（未導入の場合） npm install -g firebase-tools # バージョン確認 firebase --version # ログイン（MCP サーバーはこの認証情報を使う） firebase login Claude Code への MCP 登録 インストール済みの Firebase CLI なら、MCP サーバーは次のコマンドで起動します。 firebase mcp --dir /path/to/your/project Claude Code には .mcp.json （プロジェクト直下）で登録するのが手軽です。クラッシュ対応用途であれば、後述の理由から --only crashlytics でツールを絞る のがおすすめです。 { "mcpServers": { "firebase": { "command": "firebase", "args": [ "mcp", "--only", "crashlytics", "--dir", "/path/to/your/project" ] } } } CLI から登録する場合は次の形でも同じことができます。 claude mcp add firebase -- firebase mcp --only crashlytics グローバルインストールを避けたい場合は、公式ドキュメントのとおり npx -y firebase-tools@latest mcp ... （ command を npx 、先頭の args に -y firebase-tools@latest ）でも起動できます。 登録後、Claude Code で /mcp を実行し、 firebase サーバーと crashlytics_* ツールが認識されていれば準備完了です。 クラッシュ対応フロー：半自動化の中身 ここからが本題です。Claude Code に自然言語で依頼するだけで、ツール呼び出し → 分析 → コード修正 → PR ドラフトまでを通しでやってもらいます。フロー全体は次のイメージです。 1. トリアージ：上位クラッシュを一覧する まずは「今いちばん効くクラッシュ」を洗い出します。 直近 7 日間で発生数が多いクラッシュを上位 5 件、影響ユーザー数と OS バージョン分布つきで一覧にして。優先度の高い順に並べて。 Claude は crashlytics_get_report を呼び、結果を表にまとめてくれます。発生数だけでなく影響ユーザー数や端末分布まで一度に並ぶので、「まず何から直すか」をその場で判断できます。 2. 深掘り：スタックトレースと発生状況を取得 優先度の高い issue を 1 件選び、詳細を取りに行きます。 1 件目の issue の詳細を取得して、代表的なスタックトレースと、発生している端末・OS・アプリバージョンの傾向を教えて。 ここでは crashlytics_get_issue と crashlytics_list_events （必要に応じて crashlytics_batch_get_events ）が呼ばれます。「特定 OS バージョンだけで起きている」「特定の画面遷移直後に多い」といった、原因の当たりをつけるための材料が揃います。 3. 突き合わせ：原因仮説と該当コードの特定 ここが手作業でいちばん面倒だった部分です。Claude Code はリポジトリのコードも読めるので、スタックトレースとソースを突き合わせてもらいます。 このスタックトレースに対応するコードをリポジトリから特定して、クラッシュの原因仮説を立てて。null 安全や lifecycle 周りの問題があれば指摘して。 スタックトレースの該当クラス・メソッドからソースの行まで辿り、「ここで nullable な値を !! で参照していて、特定条件で null になりうる」といった粒度で原因仮説を出してくれます。 4. 修正と PR ドラフト作成 原因に納得できたら、修正と PR まで一気に依頼します。 原因仮説に沿って修正案を作って。修正したらブランチを切って、変更内容と原因・対応を説明した PR をドラフトで作成して。 Claude Code がコードを修正し、 gh pr create --draft でドラフト PR まで作ってくれます。PR 本文には「どのクラッシュに対応したか」「原因」「修正内容」が整理された状態で入るので、レビュー依頼の手前まで一気に進みます。 運用ノウハウ / つまづきポイント 実際に動かすと、いくつか引っかかりやすい点があります。先に共有しておきます。 ツールは --only crashlytics で絞る Firebase MCP サーバーは Crashlytics 以外にも多くのツールを持っています。プロジェクトのデータ量が多いと、起動時のツール一覧取得（ tools/list ）でタイムアウトやメモリ不足が起きることが報告されています（ firebase-tools #9663 ）。クラッシュ対応に用途を絞るなら、最初から --only crashlytics を付けてツールを限定しておくのが安全です。動作も軽くなります。 CI / サービスアカウント認証では 404 に注意 ローカルの firebase login では問題なく動くのに、CI 環境でサービスアカウントや Workload Identity Federation（WIF）を使うと、 crashlytics_get_report が「HTTP 404, Method not found」で失敗するという報告があります（ #10310 / #10004 ）。同じ環境でも firebase login:ci で取得したトークンなら通る、という回避策が共有されています。CI に組み込む前提なら、認証方式の検証は早めにやっておくとよいです。 プラットフォームによってツールが出ないことがある 過去には iOS プロジェクトで Crashlytics ツールが認識されないケースも報告されています（ #9495 ）。ツールが見当たらないときは、 --dir で正しいプロジェクトを指していること、firebase-tools が最新であることをまず確認してください。 Experimental ゆえのバージョン固定 前述のとおり Crashlytics MCP は Experimental です。常に最新の firebase-tools を使っていると、ある日ツール名や引数が変わって手順が動かなくなる可能性があります。チームで共有するなら、 npm install -g firebase-tools@<version> のように firebase-tools のバージョンを固定して運用するほうが安定します。 どこまで任せるか（“半” の線引き） あくまで「半」自動化にとどめているのには理由があります。クラッシュの原因仮説は説得力があっても間違っていることがありますし、修正がほかの挙動に影響しないかの最終判断は人間の責任です。 今回の運用では、 Claude は提案者、人間は承認者 という役割分担を崩していません。PR をドラフトで作るところまでを AI に任せ、レビューとマージは必ず人が行います。トリアージと突き合わせという「重いけれど判断の少ない作業」を肩代わりしてもらい、人は判断に集中する——この線引きが、いまのところいちばん心地よく回っています。 まとめ 公式の Firebase MCP サーバーと Claude Code を組み合わせることで、クラッシュ対応のトリアージから原因分析、該当コードの特定、修正 PR ドラフト作成までを通しで半自動化できました。ダッシュボードとエディタの往復が減り、後回しにしがちだったクラッシュ対応の腰が軽くなったのが一番の効果です。 まだ Experimental な機能なので過信は禁物ですが、上位クラッシュの定期トリアージを仕組み化するなど、伸ばせる余地はまだまだありそうです。同じように Crashlytics 運用に手間を感じている方は、まず --only crashlytics で繋いでみるところから試してみてください。 最後まで読んでいただきありがとうございました！ 参考リンク firebase.google.com firebase.google.com firebase.blog firebase.blog modelcontextprotocol.io

はじめに：生成AIの登場とQAに投げかけられた問い生成AIが登場した際、多くの職種に対して似たような疑問が投げかけられました。「この仕事はAIに代替されるのか？」「反復的な業務は自動化されるのではない...