予約の通知、メールだと「気づかれない」問題

予約サイトを運営していて、こんな経験はないでしょうか。予約が入るたびに通知メールは届いているはずなのに、気づくのが遅れて対応が後手に回る。あるいは、お客様に送ったリマインドメールが迷惑メールフォルダに入ってしまい、そのまま来店につながらない――。予約管理そのものはうまく回っていても、「通知が確実に届き、すぐ気づける」かどうかは、意外と見落とされがちなポイントです。

今回の開発事例レポートでは、WordPressの予約管理プラグイン「Amelia」を導入済みのお客様から、「予約の通知を、メールではなくLINEで受け取れるようにしたい」というご相談をいただいた案件を紹介します。実際にどう考え、どう実装したのか。エンジニアとしての判断や、つまずいた点まで含めて、裏側をお見せします。

ご相談の内容：Ameliaの通知をLINEに置き換えたい

お客様はすでにAmeliaで予約システムを構築されていましたが、予約完了やリマインドの通知がメールのみだったため、これをLINEで届けたい、というご要望でした。理由はシンプルで、メールより、普段使っているLINEのほうが確実に見てもらえるから。日本では、業務連絡でもLINEが日常的に使われているため、予約通知との相性が良いという判断です。

正直に言うと、「LINEにするかメールにするか」はお客様のご要望が出発点でした。私（矢部）の役割は、その「LINEで通知したい」を、Ameliaという既存の仕組みの上でどう現実的に実現するかを設計し、実装することです。ここからが、エンジニアの腕の見せどころになります。

大量のメールに埋もれて見落とす様子と、スマホに1件だけ届いてすぐ気づく通知の対比イメージ

提案：ゼロから作らず、「足りない部分だけ」自作する

この手の依頼で、私が最初に考えるのは「どこまでを既存のもので賄い、どこを自作するか」です。何でもフルスクラッチで作れば柔軟ですが、コストも納期も膨らみます。今回は、機能を2つに分けて考えました。

お客様とLINEを結びつける部分（LINEログイン／友だち登録）：ここは実績のある既存プラグインを活用する。
予約が入ったらLINEへ通知を送る部分：Amelia側に手を入れる必要があるため、専用の仕組みを自作する。

前者には、SNSログインの定番プラグイン「Gianism」を利用しました。よくできた既存プラグインがあるなら、そこは無理に自作しない。これは、お客様の費用を抑えるための大事な判断です。そして後者、Amelia本体との連携部分だけを、専用プラグインとして自作しました。この「使えるものは使い、足りない部分だけ作る」という切り分けが、コストと柔軟性のバランスを取る鍵になります。

実装の裏側：Amelia本体に、どう手を入れたか

今回いちばんの山場が、AmeliaにはLINE送信を差し込むための都合のよいフック（拡張ポイント）が用意されていなかったことです。通知を送る処理がプラグインの内部に組み込まれているため、外側からきれいに機能を足す、という王道の手が使えませんでした。

そこで、Amelia本体の通知メールを送信しているクラスのコードを解析し、実際にメールを送っている箇所を特定。そのメール送信処理の直前に、自作したLINE送信の処理を呼び出す数行を差し込む、という方法を取りました。イメージとしては次のような形です（実際のコードを簡略化したものです）。

// Ameliaがメールを送信している処理に、LINE送信を差し込むイメージ（簡略化）
public function send( $to, $subject, $body ) {
    // ▼ ここで、自作したLINE送信の処理を呼び出す
    my_send_line_message( $to, $subject, $body );

    // 以降は、必要に応じて従来どおりメール送信も行う…
}

// Ameliaがメールを送信している処理に、LINE送信を差し込むイメージ（簡略化）

public function send( $to, $subject, $body ) {

// ▼ ここで、自作したLINE送信の処理を呼び出す

my_send_line_message( $to, $subject, $body );

// 以降は、必要に応じて従来どおりメール送信も行う…

}

これで「予約通知が発生したらLINEにも飛ぶ」状態を実現できました。ただし、この方法には大きな弱点があります。

アップデートで消える問題と、その対策

Amelia本体のファイルに直接手を入れているため、Ameliaをバージョンアップすると、差し込んだLINE送信の処理が上書きされて消えてしまうのです。これは、コアファイルを改変する手法につきものの問題です。放置すれば、ある日更新した瞬間にLINE通知が止まってしまいます。

この対策として、2つの手を打ちました。

ワンクリックで再適用できる仕組みを自作：管理画面のボタンを押すだけで、消えてしまったLINE送信の処理を再びファイルに書き戻せる機能を、自作プラグイン側に用意しました。誤って押しても問題が起きないように設計しています。
Ameliaの自動更新はオフで運用：意図しないタイミングで更新が走らないようにし、更新するときは「更新→ワンクリックで再適用」をセットで行う運用にしました。

単に動くものを作るだけでなく、「この先、運用でどこが壊れるか」まで見越して手当てしておく。ここが、納品して終わりにしない開発との違いだと考えています。

既存プラグインと自作の部品を組み合わせ、予約システムからLINE通知へつなぐ構成イメージ

最後の詰まりは、意外にも「遷移先URL」ひとつ

正直にお伝えすると、この案件で最後まで残ったつまずきは、複雑なプログラムの部分ではありませんでした。LINEログイン後の「遷移先アドレス（リダイレクトURL）」の設定です。LINE連携では、ログインや友だち追加のあとにどのページへ戻すかをURLで指定しますが、この値が環境と一致していないと、認証がうまく通りません。

実際、お客様の環境でうまく通知が飛ばなかった原因も、最終的にはこの遷移先アドレスの入力に行き着きました。ここが揃った途端、別のアカウントでも問題なくLINE通知が届くようになりました。大きなシステムほど、最後の一歩は小さな設定値で決まる――LINEやAPI連携の開発では、本当によくあることです。

成果：お客様からいただいた声

今回はLINE通知の仕組みを構築するところまでが開発の範囲だったため、運用後の数値的な効果は追っていません。ただ、納品時点で「予約通知を確実にLINEで届けられる仕組み」は完成し、お客様にもご確認いただけました。最後にいただいたお言葉を、許可を得られる範囲で紹介します（内容は要約しています）。

「こちらが気づいていないところまで提案してくれて、細かいフォローや丁寧な資料にとても満足しています」
「お支払いした金額以上の価値を感じています」

設定手順をまとめた資料を丁寧に用意したこと、そして「言われたことをやる」だけでなく、運用で困らないところまで先回りして手を打ったこと。そうした部分を評価いただけたのは、エンジニアとして何よりうれしい点です。

まとめ：既存プラグインの限界は、独自実装で超えられる

Ameliaに限らず、「便利なプラグインを入れたけれど、あと一歩だけ思いどおりにならない」という場面は本当に多いです。今回のように、既存の仕組みを活かしつつ、足りない部分だけを自作でつなぐことで、多くの「あと一歩」は実現できます。しかも、アップデート対策まで含めて設計しておけば、長く安定して使えます。

私たちEdel Heartsは、予約・会員・通知・外部サービス連携（LINE / API）など、WordPressの「既存プラグインでは無理」を独自開発で解決することを得意としています。「こんなことできる？」というざっくりした相談段階からで大丈夫です。他社で「難しい」と言われた案件も、まずは一度ご相談ください。