LINEの問い合わせをTeamsのチャネルで受けて返す｜ワークフローとボットの分かれ目

LINE公式アカウントに届いた問い合わせを Microsoft Teams のチャネルに出すだけなら、LINE の Webhook を受ける受け口から、Teams のワークフローで作った［Teams Webhook 要求を受信したとき］の URL にカードを送れば足ります。Microsoft 365 のライセンスに含まれる Power Automate の範囲で作れます。Teams で書いた返信をお客様の LINE に戻すところまで作ると、返信を受け口に戻す口が別に要り、それは Teams アプリのボットか、Premium のライセンスのフローになります。

当社は Microsoft 365 の導入と運用設計を手伝い、LINE公式アカウントの運用と、LINE とほかのシステムとの連携も支援しています。Teams と LINE の両方の側にかかわる立場から見ると、LINE とチャットツールをつなぐ手順は Slack を例にしたものが多くあります。一方、Teams の側は、以前の受信 Webhook（Office 365 コネクタ）の廃止で作り方が変わり、返信の戻り方も Slack とは違います。そこで、この記事は Teams の側に絞ります。LINE の側の受け口（署名の検証、すぐ200を返す作り、再送と重複の除去）は Slack の場合と同じなので「LINE と Slack の連携の記事」に譲ります。LINE の通知を社内に送る向きは「LINE社内通知・ワークフロー自動化ガイド」、AI に一次対応を任せる話は「LINEの問い合わせをAIに任せる3つの段階」を見てください。

例は1つに決めて通します。架空の会社「みどり設計」の LINE公式アカウントに、お客様の井上さんが「配送先を変更したい」と送り、Teams の「LINE問い合わせ」チャネルで担当の山本さんが返す、という流れです。名前は、記事の途中に置いた当社のデモと同じ架空のものです。

Teams の受け口は3つで、Office 365 コネクタの受信 Webhook はもう使わない

Teams の側で、外から来たものを受ける口は3つあります。ワークフロー（Power Automate）の Webhook、Teams アプリのボット、送信 Webhook です。どれを選ぶかは、転送だけでよいか、Teams から返すまで作るか、Azure の資源と開発を用意できるか、で決まります。

以前は、チャネルに「受信 Webhook」のコネクタを追加して URL を発行する作り方が使われていました。Microsoft Learn の受信 Webhook の作成のページは、Microsoft 365 コネクタ（以前の Office 365 コネクタ）が非推奨に近づいていると書き、日程は Microsoft 365 の開発者ブログのお知らせに案内しています。そのお知らせ（2026年4月14日の更新）は、Office 365 コネクタを2026年5月18日から22日にかけて順に無効にし、その後は動かなくなるとしています。期限はそれまでに何度も延ばされてきましたが、この更新で、延長を重ねたうえで廃止を進めるとして、無効化の開始日（5月18日）と完了日（5月22日）が示されました（Retirement of Office 365 connectors within Microsoft Teams）。Learn の受信 Webhook のページの例では、この形の URL は webhook.office.com を含んでいます。古い手順で作った連携は、ワークフローの Webhook に作り直します。

Webhook とコネクタの概要のページは、コネクタはメッセージを更新したり既存のメッセージに返信したりできない、とも書いています（Webhook とコネクタを作成する）。お客様1人のやり取りを1つのスレッドにまとめる使い方は、もともと受信 Webhook では作れませんでした。

転送だけなら、ワークフローの［Teams Webhook 要求を受信したとき］で作る

井上さんの「配送先を変更したい」は、まず LINE の受け口に届きます。受け口は署名を確かめて保存し、すぐ200を返し、そのあとで Teams 向けのカードを作って、ワークフローの Webhook の URL に送ります。ここから先が Teams の側です。

作り始めは、Teams のテンプレートが早道です。Teams で投稿先のチャネルを開き、チャネルの横の［その他のオプション（…）］から［ワークフロー］を選び、［Webhook アラートをチャネルに送信する］などのテンプレートを選んで、パラメーターを設定して［保存］します。テンプレートによって認証の種類が違います（次の「1 だれがトリガーできるか」で書きます）。できあがったら Webhook のリンクをコピーし、受け口からその URL に POST します（受信 Webhook を作成する）。Microsoft のサポート記事は、これらのテンプレートと Teams Webhook トリガーを使うのにプレミアム ライセンスは要らない、と書いています（受信 Webhook を使用して Teams でメッセージを送信する）。トリガーの名前は、Learn のページによって［Teams Webhook 要求が受信されたとき］とも訳されています。

1 だれがトリガーできるか（認証の種類）

トリガーには、［すべてのユーザー］［テナント内の任意のユーザー］［テナント内の特定のユーザー］の3つの設定があります。［すべてのユーザー］では要求に認証トークンを付けず、公式も、この設定のときは認証トークンのヘッダーを渡さないよう書いています。あとの2つでは、要求に Microsoft Entra の認証トークンを付ける必要があります（Microsoft Teams – Connectors）。トークンに求められる項目は、対象者（aud、パブリック クラウドでは https://service.flow.microsoft.com/）、発行者、テナント ID、特定のユーザーに絞るならオブジェクト ID で、サービス プリンシパルのオブジェクト ID を許可するユーザーに入れることもできます（HTTP リクエストトリガーに OAuth 認証を追加する）。

認証の種類は、テンプレートを選ぶところで決まります。Microsoft のサポート記事は、各テンプレートの認証の種類は異なると書き、チャネル向けには［Webhook アラートをチャネルに送信する］［特定のユーザーからチャネルに Webhook アラートを送信する］［組織内のユーザーからチャネルに Webhook アラートを送信する］の3つを挙げています（受信 Webhook を使用して Teams でメッセージを送信する）。受け口だけに絞るなら［特定のユーザーからチャネルに Webhook アラートを送信する］から作り、許可するユーザーに受け口のサービス プリンシパルを入れます。注意が1つあります。［テナント内の特定のユーザー］を選んで許可するユーザーの欄を空のままにすると、認証の範囲はテナントになり、テナント内のすべてのユーザーがトリガーできる、と OAuth のページは書いています。

同じページは、HTTP 要求のトリガーの認証の無い設定（任意のユーザー）について、URL と JSON の形を知っていれば誰でもワークフローを動かせると説明しています。Teams Webhook のトリガーの［すべてのユーザー］も、トークンを付けずに動かす設定です。受け口が Microsoft Entra のアプリとしてトークンを取れるなら、上のとおりそのサービス プリンシパルだけに絞ります。［すべてのユーザー］のまま使うなら、URL はパスワードと同じに扱い、受け口の設定の中だけに置きます。認証を選んだのにトークンが無い、または対象者の値が末尾のスラッシュまで一致しないと、POST が失敗し、チャネルには何も出ません。

2 送る本文の形

トリガーは、アダプティブ カードのコレクション用とメッセージ カード用の2つの本文の形を受け付けます。アダプティブ カードの場合は、次の項目を入れます（Microsoft Teams – Connectors「要求本文スキーマ」）。

値を間違えたときにどう失敗するかは、公式のページには書かれておらず、当社でも確かめていません。検証用のチャネルに送って、カードが出るかを見てから受け口につないでください。公式に書かれている失敗は大きさで、投稿が約28KBを超えると「要求エンティティが大きすぎます」で失敗します（Microsoft Teams – Connectors）。

カードに載せるものは、受け口が振った問い合わせ番号、お客様の表示名、本文、受け付けた時刻にとどめ、LINE のユーザー ID は受け口の対応表に置くことをお勧めします。チャネルのメンバー全員が読めるカードに ID を出す理由が無く、LINE のユーザーデータポリシーには、ユーザーの情報の公開範囲を LINE の中と同じか、それより限定するという条項があるからです。条項の整理と、転送にどう当てはめるかは「LINE と Slack の連携の記事」の最後の節にあります。

3 LINE の Webhook URL に、ワークフローの URL を直接入れない

受け口を挟まず、LINE Developers コンソールの Webhook URL にワークフローの URL を入れる形も考えられますが、この記事では勧めません。トリガーが受け付ける本文の形（type と attachments）は LINE の Webhook の本文とは違い、LINE の署名（x-line-signature）をフローのどこでどう確かめるかも、Microsoft の資料からは分からないからです。LINE の Webhook URL に設定できるボットサーバーのエンドポイントは1つだけなので（ボットを作成する）、受け口を1つ置いて、そこから Teams に送る形にします。

4 Teams の側の制限

ワークフローの Webhook で受けると、投稿は Flow ボットの名前で出ます。Microsoft のお知らせは、Webhook 経由の投稿ではボットのアイコンと表示名を変えられないとしています（Retirement of Office 365 connectors）。そのほかの制限を、問い合わせの転送で当たりやすい順に並べました。

出典：Teams コネクタの「調整制限」「アクションに関する既知の問題と制限事項」「一般的な既知の問題と制限事項」（Microsoft Teams – Connectors）、受信 Webhook を作成するの「限界事項」、Power Automate のライセンスに関するよくあるご質問、Microsoft 365 Developer Blog のお知らせ。所有者が組織を離れたときの扱いは「所有者が組織を離れたときに孤立したフローを管理する」にあります。窓口の業務用のアカウントを所有者にし、共同所有者を足しておくと、担当の異動でフローが止まりません。

Teams で書いた返信は、そのままでは受け口に届かない

Slack では、チャンネルのスレッドに書いた返信が Events API で受け口に届きます（LINE と Slack の連携の記事）。Teams では、返信を受け口に届ける口を選ばないと、山本さんがカードのスレッドに書いた返信はどこにも送られません。Microsoft Learn の記述を、受け方ごとに並べました。

出典：Microsoft Teams – Connectorsの「トリガーに関する既知の問題と制限事項」と［アダプティブ カードをポストして応答を待つ］、自動化フロー、スケジュールされたフロー、インスタント フローの制限事項、エージェントのチャネルとグループ チャットの会話、エージェントがすべてのチャット メッセージを受信できるようにする、Teams SDK でのアダプティブ カード アクション、送信 Webhook を作成する（応答の期限は、作成の手順のページでは5秒、概要のページでは10秒と書かれています）。

この表からの当社の判断は、返信をカードの入力欄とボタンで受ける作りにすることです。@メンションに頼ると、付け忘れた返信は受け口に届かず、山本さんは返したつもりでも井上さんには何も届きません。RSC ですべてのメッセージを受ける形は、担当どうしの相談の書き込みまで受け口に届くので、どれを LINE に送るかの決まりが別に要ります。カードの入力欄なら、［LINE に送る］を押したものだけが送られます。

転送だけにする場合、返信は LINE Official Account Manager のチャットで行います。チャットには担当者の設定と「要対応」の絞り込みがあり、担当者が決まっていないチャットでは、最初にチャットを送信したメンバーが担当者になります（チャット）。LINE チャットの送受信は、料金プランの通数に数えられません（料金プラン）。Teams は通知の場所、返信は LINE の画面、と分ける形です。

担当を決めてから LINE に返す：ボットで組む流れ

ボットで組む場合、受け口とボットは同じ対応表を使います。ボットは、チームにインストールしてあれば、自分からチャネルに新しいスレッドを立てて投稿でき、スレッドに返信するときは会話 ID とルートのメッセージの ID を使います（プロアクティブ メッセージ）。担当の割り当てと返信は、カードのボタンと入力欄で受けます。

カードのボタンは Action.Execute にします。押されると、入力欄の値とカードに持たせたデータ（問い合わせ番号など）が card.action としてボットに届きます（Teams SDK でのアダプティブ カード アクション）。「エージェントとの会話」のページのアクティビティの例では、送信者（from）に Microsoft Entra のオブジェクト ID（aadObjectId）が入っています（エージェントとの会話）。押した人は、この送信者の項目で見分ける作りになります。ボットは自分が送ったメッセージをあとから更新できるので、［担当する］が押されたらカードを「担当：山本」に書き換え、返信欄を出します。ボットはユーザーが書いたメッセージは更新も削除もできないので、状態はボットのカードの側で持ちます（エージェントとの会話「エージェントから送信されたメッセージを更新および削除する」）。Microsoft はカードのユニバーサル アクションの説明で、割り当てられた人にだけ［解決］ボタンを見せるユーザー固有のビューを例に挙げています（カードのユニバーサル アクション – 概要）。担当者にだけ返信欄を見せる作りも、この仕組みで組めます。

「担当を決めてから返す」動きは、架空の会社・データで作った当社のデモで確かめられます。チャンネルの画面は、社内のチームチャット（Slack 等）の一般的な形で、Teams の画面ではありません。Teams のチャネルとボットのカードに置き換えて見てください。

ボットで当たる制限

ボットの API には受信の側のレート制限があり、超えると HTTP 429 が返ります。1つの会話に送る操作は、1秒に7回、2秒に8回、30秒に60回が目安で、3600秒に1800回の制限は、1人のユーザーに複数のメッセージを送る場合にだけ当たるとされています。また、1つのテナントの1つのアプリには毎秒50要求の上限があります。値は変わることがあるとされ、429 は指数バックオフで再試行し、412・502・504 も再試行するよう書かれています（エージェントのレート制限）。ボットはプライベート チャネルの会話にはメッセージもカードも投稿できないので、「LINE問い合わせ」は標準チャネルにします（エージェントのチャネルとグループ チャットの会話）。

ボットのアプリは、組織の中だけで使うカスタム アプリとして配ります。Teams 管理者などが Teams 管理センターでアップロードすれば承認なしで組織全体に出せ、ユーザーが申請した場合は管理者の承認のあとで使えます（カスタム アプリのポリシーと設定を管理する）。誰がアップロードを許可できるかを、作り始める前に確かめておきます。

Premium のフローで組む場合

ボットを作らずに Power Automate で返す形もあります。［アダプティブ カードをポストして応答を待つ］は、カードをチャネルに投稿し、任意のユーザーが応答するまでフローを止めます（Microsoft Teams – Connectors）。カードに担当者の選択欄と返信の入力欄を置き、応答を受けたら受け口に送る、という形です。ただ、受け口や LINE の API を呼ぶ HTTP は、Microsoft Learn のトレーニングで「プレミアム接続」とされ、Microsoft 365 のライセンスで使えるのは標準コネクタだけです。自動化したフローでは、Premium のライセンスが要るのは所有者です（Power Automate の HTTP コネクタの概要・Power Automate のライセンスに関するよくあるご質問）。応答を待つあいだもフローの実行は続き、実行は30日で保留のステップがタイムアウトします（自動化フローの制限事項）。担当の選択と返信を別々に受けるなら、カードを2回投稿する作りになります。

この形で確かめる点が1つあります。公式の説明は「任意のユーザーからの応答を待機」までで、担当者以外の応答を止める設定は、Teams コネクタのページには見当たりません。応答のあとに、応答した人が担当者かをフローの中で確かめられるかは、出力が「状況に応じて変わる」とだけ書かれているので、検証用のチャネルで出力の中身を見て確かめます。アクションの投稿先はチャットかチャネルを選べるので、返信欄のある2回目のカードを担当者とのチャットに投稿する作りも、あわせて試す候補になります。ボットの道のように担当者にだけ返信欄を見せる仕組みは、このアクションの説明には出てきません。

カードの［LINE に送る］が2回届いたとき

Teams から返す返信は、人が書く以上、応答トークンの期限（受信から1分以内）に間に合う保証が無いので、ユーザー ID を宛先にしたプッシュメッセージで送ります。理由と通数の数え方は「LINE と Slack の連携の記事」の「応答メッセージかプッシュメッセージか」の節にあります。Teams の側で気をつけるのは、カードの［LINE に送る］が通信の都合で2回ボットに届いたときです。問い合わせ番号と返信ごとに決まった手順で X-Line-Retry-Key を作っておけば、2回目は同じキーの送り直しになり、最初のリクエストから24時間以内なら LINE は409を返して重複して送りません（失敗したAPIリクエストを再試行する）。カードを「対応済み」に更新するのは、LINE の API が受け付けを返してからにします。

誰が、どの画面で何を設定・許可するか

Teams の側は、チームのメンバーだけでは済まない設定が混ざります。ボットまで作る場合は、Teams 管理者と Azure の担当が加わります。

最初に、古い受信 Webhook の URL と、ワークフロー アプリの許可を見る

作り始める前に、2つを確かめてください。1つは、今の LINE の受け口や連携ツールの設定に、webhook.office.com を含む URL（Office 365 コネクタの受信 Webhook）が残っていないかです。残っていれば、Microsoft のお知らせの日程のとおりなら、もうチャネルには投稿されていません。もう1つは、Teams 管理センターでワークフロー アプリが「許可」になっているか、カスタム アプリのアップロードを誰が許可できるかです。

Teams の受け口をワークフローとボットのどちらにするか、LINE の受け口と対応表の設計は、当社のLINE運用・伴走支援でご相談いただけます。

仕様と画面の名前は、2026年10月14日に Microsoft Learn（Teams のコネクタ、Teams の開発者向けドキュメント、Power Automate、Power Platform のライセンス）、Microsoft サポート、Microsoft 365 Developer Blog、LINE Developers を開いて確かめたものです。当社の環境で操作して確かめたものではありません。返信を受け口が受け取れるかの表は、Teams コネクタのトリガーとアクションの説明、ボットのチャネルの会話・すべてのメッセージの受信・カードのアクションのページ、送信 Webhook の作成のページの記述を突き合わせて作りました。