お問い合わせをLINEで通知して、AIに返信の下書きを書かせています

Naru Officeのお問い合わせは、LINEとGoogle Apps Script（GAS）を連携させていて、お問い合わせが来た場合に早く気づけるよう、LINEに通知が来るようにしています。これは、その作り方と、実際に自分で作れるところまでを書きます。

まずGoogleフォームで始めた

最初にお問い合わせを受け付けていたのは、Googleフォームでした。フォームを作るだけならブラウザの中で完結しますし、送信されたデータの保存や不正送信の対策も、Google側の仕組みに任せられます。自分でサーバーを立てずに済む分、いちばん早く形にできる入口だったからです。

いまはこの入口は使っていません。2026年9月から、サイトに埋め込んだ自分のフォームから直接データを受け取る形に変えています。ただ、Googleフォームで始めたこと自体は間違いだったとは思っていません。この記事も、実際に自分がいま作るならこの順番で進める、という組み立てで書いています。まず、LINEに気づけるようにするところから始めます。

LINEで気づけるようにする

この章がいちばん長くなります。狙いは、お問い合わせが来た瞬間に気づけることでした。メールは開くまで気づかないことがありますが、LINEなら普段から見ている通知欄に届くので、気づくまでの時間を大きく縮められます。

LINEに通知を届けるには、まずLINE Developersで「プロバイダー」を作ります。プロバイダーは、自分が作るLINE公式アカウントや、あとで使うAPIをまとめておく入れ物のようなもので、名前は何でも構いません。

プロバイダーができたら、そこにLINE公式アカウントを作ります。ここで電話番号によるSMS認証が必要になるので、一言だけ触れておくと、本人確認の手間はあると思っておいてください。

公式アカウントができたら、LINE Official Account Manager（作ったLINE公式アカウントを管理する画面）から「Messaging API」を有効にします。これを有効にすると、GASのコードからLINEにメッセージを送るための「チャネルアクセストークン」を発行できるようになります。

トークンの発行や確認は、ここからさらにLINE Developers（さきほどプロバイダーを作った画面）に戻って行います。LINE Developersの［Messaging API設定］タブに、発行したチャネルアクセストークンが表示されます。このトークンは発行した後もこのタブでいつでも確認できますが、再発行すると、それまでのトークンは使えなくなります。GASの設定に使う値なので、確認のたびにコンソールを開かずに済むよう、パスワード管理ツールのような場所に控えておくと扱いやすくなります。

最後に、LINE Official Account Managerの応答設定の画面を開いて、あいさつメッセージと応答メッセージをオフにしておきます。この画面には「チャット」「あいさつメッセージ」「Webhook」「応答メッセージ」という切り替えが縦に並んでいて、それぞれの下に説明文が付いています。このうち「あいさつメッセージ」（友だち追加された時に自動的にメッセージを送信できる機能）と「応答メッセージ」（条件と一致するメッセージを受信した時に自動的にメッセージを送信できる機能）の2つをオフにしてください。オンのままにしておくと、GASから送った通知とは別に、LINE公式アカウント側の自動応答も返ってきてしまい、通知が二重に見えることになります。

これは変更前の画面です。同じ場所で両方をオフに切り替えます。

ここまでで、チャネルアクセストークンが手に入りました。あとは、送る先の「自分のLINEユーザーID」が必要です。これは、LINE Developersの同じチャネルの［チャネル基本設定］タブに「あなたのユーザーID」として表示されているので、そこから確認します（この項目はLINEアカウントとビジネスIDの連携が済んでいないと表示されないので、その場合は先に連携しておきます）。取得したトークンとユーザーIDは、コードに直接書かず、GASのスクリプトプロパティ（GASエディタの「プロジェクトの設定」から登録できる、コードの外に値を保存する場所）に保存して使います。こうしておくと、コードをコピーして人に見せる時にも、トークンやIDが一緒に見えてしまうことがありません。

返信の下書きをAIに書かせる

通知が届いたら、次はその内容に応じた返信文の下書きを作らせています。使っているのはGoogleのGemini API、その中でも軽量なgemini-3.5-flash-liteというモデルです。こちらも取得にはAPIキーの発行が必要で、Googleアカウントでの利用登録が要りますが、LINEほどの手間ではありません。

Geminiに投げるプロンプトには、5つの指示を必ず入れています。

• 個人サイトなので「弊社」「チーム一同」のような法人を装う表現は使わない
• 「実績多数」「豊富な経験」のような誇張表現は使わない
• 丁寧だが、個人らしい誠実なトーンで書く
• お問い合わせ内容を踏まえて、次のアクションを1つ提案する
• 最後に差出人名と連絡先を入れる

ただ、プロンプトで指示しただけでは、Geminiが実際にその通りに書いてくれる保証はありません。なので、生成された文章を送り出す前に、もう一度こちらのコード側で禁止表現が混ざっていないかをチェックしています。もし混ざっていたら、Geminiの文章は使わず、あらかじめ用意しておいた定型文に切り替えます。

定型文への切り替えは、Geminiの呼び出し自体が失敗した時（タイムアウトや、無料枠を使い切った時など）にも起こります。この時は、お問い合わせの内容に「見積もり」や「料金」が含まれていれば料金についての定型文、「相談」や「質問」が含まれていれば相談向けの定型文、それ以外なら一般的な受付の定型文、という形で、内容に応じて振り分けています。

どちらの場合も、できあがるのはGmailの下書きです。自動で送信はしません。内容を確認してから送るかどうかを決めるのは、こちらの役目のままにしています。

入口を、自前のフォームに変えた

2026年9月、お問い合わせの入口をGoogleフォームから、サイトに直接埋め込んだ自分のフォームに変えました。

この時、通知を送る部分と、下書きを作る部分のコードは、1行も書き直していません。GASのコードの中で、LINE通知を送る関数と、Gmail下書きを作る関数は、どちらも「お名前・メールアドレス・お問い合わせ内容」という3つの値だけを受け取る、独立した形で書いてあったからです。Googleフォームからの入口も、自分のフォームからの入口も、最終的にはこの2つの関数を同じように呼んでいるだけで、関数の中身は入口がどちらであるかを知りません。

最初からそう設計していたわけではなく、たまたまそう書いていた、というのが正直なところです。ただ、この分け方をしておくと、あとで入口の作り方を変えたくなった時に、通知や下書きの仕組みまで巻き込まずに済む、ということを今回身をもって確認しました。

いまの入口が持っている仕組み

いまの入口（自分のフォームからのお問い合わせを受け取る処理）には、いくつか小さな仕組みを入れています。

まず、フォームには本来の入力欄以外に、画面には見えない欄をこっそり1つ用意してあります。人が普通に使えばここは空のままですが、機械的に全部の欄を埋めて送ってくる相手はここも埋めてしまいます。値が入っていたら、通知も下書きも作らず、送信できたことにだけしておく、という形で静かに弾いています。

次に、名前や本文の文字数にも上限を設けています。極端に長い文章を送られると、AIへの呼び出しが重くなったり、通知が読みにくくなったりするからです。

送信の間隔にも制限があり、10秒以内に連続して送られた場合は、2件目以降を受け付けないようにしています。さらに、1日に受け付ける件数にも上限を設けていて、30件を超えて送られ続けた場合は、その日はそれ以上受け付けない形にしています。

この入口の宛先は、サイトのコードに書かれているので、誰が送ってくるかはこちらでは決められません。決められるのは、送られ続けた時にどこまで被害が広がるかだけです。だから、件数が増えすぎたら止まる、というところに力を入れています。件数が多すぎて止まったこと自体は、通知が来るので気づけます。気づけない形で止まってしまう方が怖い、というのがここでの考え方です。

まとめ

入口と中身を分けて作っておくと、入口の作り方をあとで変える時に、中身は書き直さずに済みます。今回、Googleフォームから自分のフォームに変えた時に、それを実際に確認できました。

この記事で書いたことについての連絡先は、お問い合わせのページにあります。

（この記事の文章の下書きはAIですが、人の観点からも見て修正し書いています。）