NoCode はタダではうまく行かないなぁ

タダ＝無料という話。

最近、仕事とかのコミュニケーションは専ら Slack を使っているのだが、並行してメールも受信している。

このメールの受信と通知を Slack にできないかなぁと、調べたときの備忘録。

Slack 側の前提条件

少なくともプロ版以上の有料プランを設定する必要がある。
チャンネルにメッセージを直接突っ込むなどのAPI連携は、基本有料プランにする必要がある。

選定したのは、とりあえず以下。

いずれも有名なグローバルサービス会社であったのが選定の理由。
考え方は安直だけど、ビジネスの継続性とか発展性とか、それがまぁまぁ重要な理由でもある。

最初に試したのがこれ。

まぁこれは、Make 内に対処手順が動画やドキュメントが事細かくあるので、頑張って英語と戦って対処すれば何とかできる。

これが Make 利用を断念した最大の理由。
一応 Make には、文字コード変換するためのコンバーターがモジュールとして提供されてはいるのだが、ShiftJIS には対応してるものの ISO-2202-JP は非対応。

これを対策するには、別途 Webhook かなんかで ISO-2202-JP ⇒ UTF8 変換するサイトかなんかを作成して、それを通してから Slack に投げ込むしかない。

もしくは、ISO-2202-JP がこの世界から滅んで、全ての文字コードが UTF8 になれば良い。

それはさておき、この Webhoock を実装・設置するのを今すぐはできないので、ここで一時保留。

これも技術的には問題ないけど、やはり ISO-2202-JP 文字コードの問題が歓待に解決できないので、保留。
Make を使う以上は、この問題がずっと、つきまとう。

Google Workspace などを利用し、企業ドメインなどを GMail で受け取っている場合は、モジュールを接続するだけで連携することができる（みたい）

しかしながら、@gmail.com など（「一般消費者アカウント」と言うらしい、これ）を利用していて、これを外部連携やサードパーティアプリなどと連携する場合は、認証には OAuth が必要になる。

GMail を使う場合、おそらくこれが最も現実的な連携方法なのかも知れないが、この場合「安全性の低いアプリ」として当該アカウントの許可設定をする必要があり、それはそれで不安。

そもそも IMAP で繋ぐのであれば、自分の場合は GMail に拘る必要がないので、別のメールサービスを使って IMAP を使う。

ISO-2202-JP の問題は特に発生しない。特に文字コードの仕掛けは必要なく、普通に ISO-2202-JP のメールも文字化けなく Slack に配信可能。

というのも Zapier を無料で利用する場合はシングルステップのみ、しかも月間100タスクまでという制限がある。

指定メアドに着信したメールをすべて Slack に流して良いのであれば、以下のようなシングルステップとなる。

IMAP⇒ Slack

これであれば、月 100 タスクまでであれば問題ない。
（100 タスク ≒ 処理 100 回、まぁメール100通だけという訳ではないが、正直これはこれで心許ない。）

しかしながら「題名」や「送信者」など、特定条件のみのメールだけをフィルタリングしてメッセージを Slack に流す場合、別途「フィルタ」という処理が別途必要になる。つまり以下。

IMAP⇒ フィルタ ⇒ Slack

これだと処理的にはマルチステップと見做されるらしく、そしてマルチステップは Free プランで利用できない。Starter プラン以上の有料プランにする必要がある。（2022 年 11 月現在、およそ $20/mo …）

詰んだ。

Slack はプロ版以上だと、チャンネルに個別にメアドを取得することができるので、そこに直接放り込まれるような仕掛けにしたほうがいいのかも。

とはいえ機械的なメアドをそのまま送信者に案内するのも何なので、判りやすいメアドを別途取得して、以下のような感じにするのが良いかと思ってる。

メアド1
（判りやすいメアド）
↓
（転送）
↓
メアド２
（Slack チャンネルと連携している機械的なメアド）
↓
Slackチャンネル

多分コレが一番手間も余計なカネもかからない気がする。