チャンネルへのメール送信：ボットなしで、あらゆるサービスがチームチャットに投稿する方法 — アドレスがボットトークンより優れている理由

チームが日中に目にする情報の多くは、同僚が入力したものではなく、機械が生み出したものです。遅いエンドポイントを検知した稼働監視、請求書を受け取った決済処理、チケットを起票したヘルプデスク、失敗した CI パイプラインなどがそれにあたります。こうしたメッセージを、チームが実際に話す場所へ届けることを「連携」と呼びます。多くのチャットツールでは、これはボットを意味します。ボットを作成し、トークンを取得して保管し、送信側を書くか設定し、トークンを有効に保ち続けなければなりません。

InterMIND はもっと短い道を取ります。すべてのチャンネルに専用のメールアドレスがあります。 メールを送れるものなら何でもチャンネルに投稿でき、ほとんどのものはメールを送れます。InterMIND 側でアドレス以外に作るものはなく、インストールするものも、保管するトークンもありません。この記事では、この方法の仕組みを詳しく説明します。あわせて、ボットによる配信と、実務で重要な4点（セットアップ、秘密情報、配信の保証、誰が止められるか）を率直に比較します。

セットアップ自体は Email to Channel の機能ページ に、リファレンスは ドキュメント にあります。

仕組み

1. アドレス

チャンネルのホストが、チャンネルの表示設定（チャットヘッダーの歯車アイコン）を開き、Email to channel を選んで Create address をクリックします。すると <token>@in.intermind.com という形式のプライベートなアドレスが発行されます。このアドレスを確認し、ローテーション（New address）し、削除できるのはホストだけです。ローテーションも削除も即座に反映され、新しいアドレスが作られた時点で古いアドレスは使えなくなります。

あなた個人の Inbox にも同じ種類のアドレスがあり、あなただけが確認できます。チャンネルのアドレスはチームに見せたい内容のため、Inbox のアドレスはあなただけが見たい内容のためのものです。

2. 送信側

ツールが通知用のメールアドレスを求めてきたら、そこにアドレスを貼り付けます。その欄が連携そのものです。稼働監視のアラートチャンネル、エラートラッカーのアラートルール、ヘルプデスクの「新規チケット時に通知」、課金システムの領収書、CI サーバーのビルド通知、フォームビルダーの送信内容、ニュースレターの購読など、どれにもその欄があり、InterMIND が何であるかを知っている必要はありません。

3. チャンネルに届くもの

メールは通常のチャンネルメッセージとして届きます。

• 送信者の名義で表示されます。 メッセージにはホストではなく送信者の名前とアドレスが付き、他の外部メッセージと同様に、読む人それぞれの言語に翻訳されます。
• 件名が先頭に来ます。 件名がメッセージの1行目になります。
• 定型文ではなく本文だけを表示します。 プレーンテキスト部分が使われ、HTML のみのメールはテキストに変換されます。署名や引用された返信の末尾は取り除かれるため、転送されたスレッドでも、履歴全体ではなく新しい内容だけが表示されます。本文は100,000文字までです。
• 添付ファイルも残ります。 各添付ファイルはファイルメッセージになり、1ファイルあたり25 MBまで対応します。

4. 読まれる場所

チャンネルを開いているメンバーには、Web とデスクトップでメッセージがライブで届きます。見ていないメンバーには、モバイルでプッシュ通知が届きます。それぞれが自分の言語で読み、メッセージは他の内容と同様にチャンネルの履歴に残ります。フローは一方向で、チャンネルで返信しても送信者にメールは返りません。

制限事項

• 添付ファイルはチームのストレージ容量に含まれます。ストレージが満杯の場合、テキストは届きますが添付ファイルはスキップされ、その旨がメッセージに記載されます。
• 1アドレスにつき1時間あたり30通までです。同じ時間内にそれを超えた分は破棄されます。
• 存在しないアドレス宛てのメールは、バウンスも返信もなく、そのまま破棄されます。推測されたアドレスには何の反応も返りません。
• すべてのプランで利用できます。

ボットで同じことをする場合

ボットによる連携は難しくありません。ただ手順が長く、その一つひとつが後から壊れる可能性があります。ここでは Telegram 版を紹介します。私たち自身が今週まで、監視アラートのために Telegram ボットを運用していたためです。もう一つは Slack 版で、多くのチームが基準として知っているからです。

Telegram。 ボットは BotFather を通じて作成され、BotFather がトークンを発行します。すべてのメッセージは、そのトークンと送信先チャットの数値 ID を指定した Bot API への HTTP 呼び出しで、トークンは BotFather を通じて失効・再発行できます（Telegram Bot API ドキュメント、Bots: From Beginner to Advanced、2026年9月確認）。つまり、送信側にはトークンとチャット ID が必要で、送信する場所ごとに両方が要ります。

Slack。 Incoming Webhooks は、アプリにチャンネルごとの一意の URL を与えます。その URL が秘密情報であり、Slack 自身のドキュメントも、そのように扱い、公開リポジトリには置かないよう指示しています（Slack — Sending messages using incoming webhooks、2026年9月確認）。URL はアプリごと、チャンネルごとに1つで、すべての送信側に保存することになります。

切り替える前の私たちのアラート構成では、次の5つが存在し、正しい状態を保つ必要がありました。監視ベンダーの変数にあるボットトークン、ホスティングプラットフォーム上の2つのシークレット、Webhook の署名シークレット、エラートラッカーの Webhook ハンドラー内の送信処理、デプロイ後の監視スクリプト内の送信ステップです。同じ構成のメール版は、アドレスが1つだけで、各ベンダーの「通知メール」欄に入力するだけです。InterMIND 側で必要な変更はゼロです。

アドレスとトークン：4つの特性

最後の2行が、インシデントの分かれ目になります。ボット API は、単一ベンダーのネットワーク上にある単一ベンダーのエンドポイントです。呼び出しが失敗すれば、送信側が再送ロジックを書いていない限りメッセージは失われ、あなたのいる場所からプラットフォームに到達できなければ連携も止まります。メールは逆の方向で設計されました。送信サーバーがメッセージを保持して再試行し、送信者と受信者の間に単一の事業者は入りません。

ローテーションも同じ考え方です。ボットトークンを失効させるには、それを持つすべての送信側を更新する必要があります。チャンネルのアドレスのローテーションでも更新する送信側は同じですが、そのアドレスは最初から自社のコードやインフラには保存されていません。存在するのはベンダーの通知欄だけで、他のどこにもありません。

用途

分かりやすい用途は機械が生成するメッセージで、アラート、領収書、チケット、ビルド結果などです。あまり知られていない用途は、人とのやり取りです。何もインストールしないクライアントには「このアドレスに送ってください」と伝えるだけで、チーム全員がそのスレッドを添付ファイルごと、それぞれの言語でチャンネルで読めます。取引先の週次レポート、規制当局からの通知、パートナーの契約書ドラフトなど、すべてが作業がすでに行われている場所に届き、誰かに何かへの参加を求める必要はありません。

これが、会議ではなく持続するスペースであることの意味です。届いたものは残り、各メンバーが読む言語で保たれます。メール受信は、同じ部屋へのもう一つの入口です。Telegram もその一つで、その方法は Telegram のチャットを InterMIND に取り込む方法 で説明しています。

試してみる

• チームチャットでメッセージを転送・選択・一括削除する方法 — アドレスから届いた内容の整理について。
• Email to Channel の機能ページを読む — 仕組みを1画面にまとめ、デモ付きで紹介しています。
• ドキュメントを開く — アドレスの作成とローテーション、Inbox のアドレス、制限事項。
• ライブデモを試す — AI 参加者のいるミーティング。サインアップは不要です。

FAQ

どのサービスがメールでチャンネルに投稿できますか？ 指定したアドレスにメールを送れるサービスなら何でも可能です。稼働監視やエラー監視、チケット管理やヘルプデスクのシステム、CRM、請求・課金、CI パイプライン、フォームビルダー、ニュースレターなどです。ツールに通知メールの欄があれば、その欄が連携のすべてです。

チャンネルのメールアドレスは誰が見られますか？ チャンネルのホストだけです。ホストは、チャンネルの表示設定からアドレスを作成、ローテーション、削除できます。メンバーに見えるのはメッセージであり、アドレスは見えません。

アドレスが漏れた場合はどうなりますか？ アドレスを知っていれば誰でもチャンネルに投稿できるため、パスワードと同じように扱ってください。同じダイアログから新しいアドレスを発行すると、古いものは直ちに使えなくなります。未知のアドレス宛てのメールはバウンスなしで破棄されるため、推測されたアドレスからは何も分かりません。

添付ファイルも届きますか？ はい。ファイルメッセージとして、1ファイルあたり25 MBまで届きます。チームのストレージ容量に含まれ、ストレージが満杯の場合、テキストは届きますが添付ファイルはメモ付きでスキップされます。

受信したメールは翻訳されますか？ はい。メッセージは外部の送信者の名義で表示され、チャンネル内の他の外部メッセージと同様に、読む人それぞれの言語に翻訳されます。

メンバーはチャンネルから送信者に返信できますか？ いいえ。フローは一方向で、メールからチャンネルへのみです。チャンネルでの返信は、チャンネル内にとどまります。

メール受信は無料プランでも使えますか？ はい。Email to channel はすべてのプランで利用できます。プランによって異なるのは、添付ファイルが消費するストレージ容量だけです。

Telegram や Slack にボットを追加すればよいのでは？ 接続したいツールが対応していれば、可能です。違いは、その後に何を維持管理するかです。ボットでは、トークンまたは Webhook URL をすべての送信側に保存してプラットフォーム上で管理する必要があり、配信は1回の HTTP 呼び出しで、そのプラットフォームに到達できることが前提になります。アドレスなら、こちら側に保存するものは何もなく、配信に失敗しても送信側のメールサーバーが再試行し、止められる単一の事業者もいません。

出典：Telegram Bot API および Bots: From Beginner to Advanced（トークンは BotFather が発行、sendMessage はチャット ID を取る、トークンの失効）、Slack — Sending messages using incoming webhooks（Webhook URL はチャンネルごと・アプリごとに1つ、URL は秘密情報）、RFC 5321 §4.5.4.1 — Sending Strategy（キューに入ったメールは、配信されるか断念されるまで再試行される）。2026年9月確認。