harapeko-relay 中継パターン：直接送れない制約をどうつないだか
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
ツール工房.ai では、子ども向けイベントの週次通知をはじめ、いくつかの通知を定期的に送っています。送信元はクラウド上で動く自動化の処理なのですが、ここで一つ大きな制約にぶつかりました。
クラウドの自動化から、自分で用意した送信用の入口へ、直接データを送れない場合がある、ということです。設定やサービス側の制約の関係で、想定していた入口にどうしても届きませんでした。正直、細かい仕組みを完全に理解できているわけではありませんが、とにかく「そのままでは届かない」という状況でした。
この壁をなんとかするために組んだのが、「中継の置き場（GitHub 上の通知専用リポジトリ、内部で harapeko-relay と呼んでいます）を挟むやり方」です。この記事では、エピソードよりも中身の考え方、つまり「何を中継ファイルに書くか」「経由が増えることの代償をどう受け止めるか」「失敗をどう追えるようにするか」を中心に書いてみます。
なお、そもそもなぜ通知用の置き場を別に切り出したのか、という背景はGitHub リポジトリを用途で分けた話で書いたので、ここでは繰り返しません。また、中継した先で実際に通知を送る入口そのものの作り方は、メール送信と定時実行で通知を作る仕組みに切り出してあります。この記事はあくまで「直接送れない経路を、中継でどうつなぐか」という一点に絞ります。
中継の全体像
流れ自体はわりと単純です。
- 自動化の処理が、通知のもとになるファイルを作る
- そのファイルを専用の GitHub リポジトリに送る
- ファイルが送られたことを、GitHub 側の自動処理が検知して読み込む
- 読み込んだ内容から通知を組み立てて、自分で用意した送信用の入口に渡す
- 送信用の入口が、メールなどの形で通知する
肝は、3〜4 が「最初の自動化処理の外」で起きている点だと思っています。自動化の処理そのものは送信用の入口に届かなくても、GitHub へファイルを置くことはできる。なので「届く相手（GitHub）」と「届けたい相手（送信用の入口）」のあいだに、両方に手が届く中継役を一つだけ置く、という発想です。
中継ファイルに何を書くか
このやり方で一番考えたのは、中継ファイルの中身でした。送る側（自動化）と、それを拾う側（GitHub 側の自動処理）が、このファイルを頼りにやり取りするので、ここに過不足があると詰まってしまいます。
実際にやってみると、中継ファイルの中身は通知の種類で二通りになりました。
ひとつは、件名と本文を入れておいて、ほぼそのまま送ってもらう形です。記事の公開見張りなど、単発のお知らせはこちらで、拾う側は受け取った件名と本文を送信用の入口へ渡すだけです。宛先は書いていません。送り先は送信用の入口の側に固定してあるので、ファイルに書く必要がないのです（誰でもファイルを書き換えれば宛先を変えられる、という形にしたくなかったのもあります）。
もうひとつが、はらぺこ週次のような**「集めた情報」を入れておいて、通知文はGitHub側で組み立てる形です。イベント情報の一覧をファイルに置くと、GitHub 側の自動処理が前回の状態と見比べて、増えたぶん・変わったぶんを計算し、その差分から通知文を組み立てて**送信用の入口へ渡します。前回の状態も送信側に覚えさせてあり、送ったあとに更新されます。
最初は「拾う側ができるだけ判断しなくて済むように」と考えていたのですが、差分の計算のように**「前回と今回の両方を知っている場所」でしかできない仕事**があり、それは中継役の側に置くのが自然でした。作る側で全部確定させる形と、中継役に組み立てまで任せる形。通知の性格で使い分けています。
ファイルは種類ごとに一つ、履歴は Git に任せる
ファイルの持ち方は、通知の種類ごとに決まった名前のファイルを一つにして、同じ種類の通知ではそのファイルを更新し続ける形にしています。イベント通知はイベント情報のファイル、公開見張りは見張り用のファイル、という具合です。
実行のたびに別名のファイルが増えていく形にはしていません。それでも過去の内容を見返せるのは、置き場が GitHub だからです。ファイルは常に最新の一枚、過去のぶんは変更履歴（コミット）として残る。履歴の管理を自分で作り込まなくても、Git が勝手にやってくれている格好です。
経由が増えることの代償
中継を挟むと、当然うれしくない面も出てきます。素直に直接送るのに比べて、構造が一段ややこしくなるからです。
- 遅れが増える：自動化 → 置く → 検知 → 転送 → 送信、と段が多いぶん、即時とは言えません。ファイルを置いてから実際に届くまでに、見張る仕組みが動き出すまでの待ち時間が乗ります。
- 記録の履歴が増える：通知のたびに置き場へ変更履歴が積まれていきます。
ここは割り切りどころでした。私の用途は「自分宛に少量の通知を届ける」もので、秒単位の即時性は要りません。週次のイベント更新が少し遅れて届いても困らない。むしろ後で書くように、履歴が積み上がることを活かす方向に振りました。即時性が必要な用途なら、そもそも中継を挟まない経路を探したほうがいい、という線引きだと思っています。
失敗をどこで追えるようにするか
中継のやり方で一番気を使ったのが、ここでした。経路が長いと、届かなかったときに「どこで止まったのか」が分からなくなります。自動化がそもそもファイルを送っていないのか、GitHub 側の処理が動かなかったのか、送信用の入口で落ちたのか。区別がつかないと、調べるたびに全経路を端から疑うことになってしまいます。
私が実際に見ているのは、この三点です。
- GitHub に変更が届いたか（コミットが増えているか）
- GitHub 側の自動処理が成功したか（実行ログが残っているか）
- 実際にメールや LINE が届いたか（最後は着信そのもの）
たとえば「コミットはあるのに自動処理のログが失敗している」なら組み立て側、「自動処理は成功に見えるのに着信がない」なら送信の先、と当たりがつきます。中継ファイルの変更履歴が最初の通過点のログを兼ねてくれているのは、このやり方の地味な利点だと思っています。
なお、送信用の入口そのものには「いつ受信したか」の記録を残していません。ここは経路の中で唯一、跡が残らない区間です。だからこそ最後は「実際に届いたか」を見るようにしています。
どこまで使い回せるか
この構成は、通知の中身に縛られにくいのが強みです。「直接送れないものを、GitHub を挟んで届ける」という骨格さえ同じなら、流すデータを差し替えるだけで別の通知にも使えます。実際、子ども向けイベント通知で整えたあと、いくつかの用途に当てはめています。
- 記事がちゃんと公開されたかの見張り通知
- 料金データに変化があったときの通知
- 特定サービスの値上げなど、変化を知らせる通知
どれも「自動化が送信用の入口へ直接届かない」という同じ制約を、同じ中継の形で扱っています。新しい通知を足したいときは、中継ファイルを作る処理を一つ用意すればよいので、追加のハードルがかなり下がりました。骨格を一度固めておくと、後がずいぶん楽になるタイプの仕組みらしいな、と感じています。
制約から、別のよさも見えてきた
直接送れないと最初に気づいたときは、正直めんどうだなと思いました。けれど中継を挟む形にしてみると、「いつ、何を送ろうとしたか」が GitHub の履歴に残るという、思っていなかった副産物がありました。
注意したいのは、これが「送ろうとした記録」であって「届いた記録」ではないことです。実際、履歴上は変更が届いているのに、その先の自動処理が止まっていて通知が届かなかった、ということも一度ありました。履歴は出発点の記録として使い、届いたかどうかは着信で確かめる。その分担で運用しています。
個人開発では「直接できないから諦める」を最後の手段にしておくと、こういう別のつなぎ方が見つかることもあるのかもしれない、と今は思っています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ