GASでチャットボットを作る方法 LINE・Slack別の手順と制限・活用例を解説

「社内からの問い合わせに毎回同じ回答をしている」「在庫や進捗を聞かれるたびにスプレッドシートを開いている」。こうした繰り返しは、チャットボットで置き換えられます。

Google Apps Script（GAS）を使えば、サーバーを用意せずにチャットボットを作れます。GASをWebアプリとして公開し、LINEやSlackからの通知を受け取って応答するという仕組みです。GAS自体の利用料はかかりません。

ただし、向く用途と向かない用途があります。応答に数秒かかり、1回の実行は6分までという制限があるため、社内向けの小規模な用途が適所になります。

この記事では、仕組みの理解から、LINEとSlackそれぞれの作成手順、生成AIとの組み合わせ、そして知っておくべき制限とつまずきやすい点までを順に扱います。

確認したいポイント	結論	詳細
GASでチャットボットは作れる？	Webアプリとして公開すれば可能	GASをWebアプリとして公開し、チャットサービスからの通知を受け取る仕組みです。
費用はかかる？	GAS自体は無料で使える	サーバーの用意も不要です。外部のAI APIを使う場合は、その利用料が発生します。
何ができる？	定型応答からデータ照会まで	スプレッドシートを参照した在庫照会や、申請の受付といった業務用途に向きます。
向かない用途は？	即時性と大量アクセスが必要な場合	応答に数秒かかり、1回6分の実行時間制限もあります。社内向けの小規模用途が適所です。

この記事でわかること

• GASでチャットボットが動く仕組みと、doPostが果たす役割
• LINEボットを作るまでの5ステップと、必要な事前準備
• SlackとGoogle Chatの場合の違い、3秒以内に応答する必要への対処
• 生成AIと組み合わせる方法と、そのときの費用と注意点
• 実行時間や応答速度の制限、デプロイ設定でつまずく点への対処

業務自動化とAI活用の進め方をまとめた資料を無料で配布しています どの業務から自動化に着手すべきかの見極め方、社内に定着させる手順、費用の目安を1冊にまとめました。 検討段階の情報収集にご活用いただけます。 ＞ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

GASでチャットボットが作れる仕組み

まず全体像を押さえます。難しい仕組みではなく、3つの要素が連なっているだけです。

WebアプリとしてWebhookを受ける

GASには、作成したスクリプトをWebアプリとして公開する機能があります。公開するとURLが発行され、外部からそのURLにアクセスできるようになります。

一方、LINEやSlackには、メッセージを受け取ったときに指定したURLへ通知を送る仕組みがあります。これをWebhookと呼びます。

この2つを組み合わせるのが基本の構成です。利用者がボットに話しかけると、チャットサービスからGASのURLへ通知が届き、GASが処理して応答を返します。

doPostが入り口になる

GAS側で受け口になるのが、doPostという名前の関数です。この名前でなければ動きません。

function doPost(e) {

  // e.postData.contents に届いたデータが入っている

  const data = JSON.parse(e.postData.contents);

  // ここで内容を判定して応答を組み立てる

}

引数のeに、送られてきた情報がまとめて渡されます。中身を確認するには、いったんスプレッドシートに書き出すか、ログに出力するのが定石です。届くデータの形式はサービスごとに異なるため、まず実物を見ることから始めます。

なお、GETリクエストを受ける場合はdoGetという関数を使います。チャットボットではPOSTを使うため、doPostが中心になります。

サーバーが不要で無料

この構成の最大の利点は、サーバーを用意しなくてよいことです。GASはGoogleのインフラ上で動くため、契約も設定も要りません。

常時稼働のサーバーを借りれば、月額の費用が発生します。それが不要になるため、試作や社内向けの小規模な用途では圧倒的に手軽です。

さらに、スプレッドシート、Gmail、カレンダー、ドライブと標準で連携できます。社内のデータがGoogle Workspace上にあるなら、追加の設定なしで参照できます。

どんなチャットボットが作れるか

用途は大きく4つに分かれます。下に行くほど実装の難易度が上がります。

定型応答型

受け取ったメッセージに含まれるキーワードで判定し、決まった文章を返すタイプです。最も単純で、最初に作るべき形です。

社内の問い合わせ窓口として使えます。「経費精算」と送れば申請手順と期限を返す、「就業規則」と送ればリンクを返すといった使い方です。

回答内容をスプレッドシートで管理する構成にすると、プログラムを触らずに内容を更新できます。運用を他の人に任せられるようになります。

データ照会型

スプレッドシートやデータベースを参照して、その場の値を返すタイプです。「今の状態を知りたい」という問い合わせに向きます。

在庫数の確認、案件の進捗照会、担当者の確認、会議室の空き状況。こうした情報は、システムを開かずにチャットで聞けるほうが速くなります。

実装では、メッセージから検索キーを抽出し、シートを検索して結果を整形して返します。キーが見つからない場合の応答も必ず用意します。

受付・登録型

チャットで受け取った内容を、スプレッドシートに記録するタイプです。入力画面を作らずに済む点が利点になります。

日報の提出、備品の購入依頼、不具合の報告、作業の開始と終了の記録。スマートフォンから手軽に送れるため、現場での記録に向きます。

入力項目が多い場合は、対話形式で順に聞く構成にします。ただし状態の管理が必要になり、実装は一段難しくなります。項目が多いならフォームを使うほうが確実です。

生成AI連携型

受け取ったメッセージを外部のAIサービスに送り、返ってきた文章を応答として返すタイプです。定型の判定では対応できない自由な質問に答えられます。

社内規程や手順書の内容を踏まえて回答させる構成も組めます。詳しくは後の章で扱います。

注意点は、応答に時間がかかることと費用が発生することです。AIサービスの利用料は使用量に応じて課金されます。

LINEボットの作り方｜5ステップ

最も需要が多い組み合わせです。LINE公式アカウントを作り、GASと接続するという流れになります。

ステップ1｜LINE公式アカウントとチャネルを作る

LINE Developersにログインし、プロバイダーを作成してから、Messaging APIのチャネルを作成します。ログインにはビジネスIDと開発者アカウントが必要です。

利用するのはMessaging APIです。かつて通知用に使われていたLINE Notifyは、2025年3月31日にサービスが終了しました。LINE公式のお知らせでも、代替としてMessaging APIの利用が案内されています。

ネット上の記事にはLINE Notifyを使った手順が多く残っています。参照する記事の公開日を確認し、古い手順を追わないよう注意してください。

ステップ2｜アクセストークンを取得する

作成したチャネルの設定画面から、チャネルアクセストークンを発行します。これがGASからLINEへメッセージを送る際の認証情報になります。

あわせて、応答設定を確認します。自動応答メッセージが有効になっていると、ボットの応答と重複して2つのメッセージが届きます。Webhookを有効にし、自動応答をオフにします。

トークンはコードに直接書きません。GASのプロジェクト設定にあるスクリプトプロパティに保存し、コードからはキー名で参照します。

const TOKEN = PropertiesService

  .getScriptProperties()

  .getProperty(‘LINE_ACCESS_TOKEN’);

ステップ3｜GASでdoPostを書く

受け取ったメッセージに応答する最小限のコードです。返信にはリプライトークンを使います。

function doPost(e) {

  const event = JSON.parse(e.postData.contents).events[0];

  if (!event || event.type !== ‘message’) return;

  const replyToken = event.replyToken;

  const userText  = event.message.text;

  const replyText = buildReply(userText);

  UrlFetchApp.fetch(‘https://api.line.me/v2/bot/message/reply’, {

    method: ‘post’,

    contentType: ‘application/json’,

    headers: { Authorization: ‘Bearer ‘ + TOKEN },

    payload: JSON.stringify({

      replyToken: replyToken,

      messages: [{ type: ‘text’, text: replyText }]

    })

  });

}

リプライトークンは1回しか使えず、有効期限もあります。同じトークンで2回返信しようとするとエラーになります。複数のメッセージを送るなら、messagesの配列に並べます。

応答内容を組み立てるbuildReply関数は、別に用意します。キーワードで分岐させる、シートを検索する、AIに投げる。ここが作り込みの中心になります。

ステップ4｜Webアプリとしてデプロイする

エディタ右上のデプロイから、新しいデプロイを作成します。種類はウェブアプリを選びます。この設定を誤ると動きません。

• 次のユーザーとして実行：自分（スクリプトの所有者）
• アクセスできるユーザー：全員

2つ目の設定が重要です。LINEのサーバーは認証を持たない外部からのアクセスになるため、全員がアクセスできる状態にしないと通知が届きません。

発行されたウェブアプリのURLをコピーします。初回のデプロイ時には権限の承認画面が表示されるので、内容を確認して許可します。

ステップ5｜Webhook URLを登録する

LINE Developersのチャネル設定に戻り、Messaging API設定のWebhook URLに、先ほどのURLを登録します。Webhookの利用をオンにします。

登録後、検証ボタンで疎通を確認できます。成功と表示されれば接続は完了です。実際にボットを友だち追加して、メッセージを送ってみます。

応答がない場合は、GASの実行ログを確認します。エラーが記録されていれば原因が分かります。ログに何も出ていなければ、通知そのものが届いていないため、URLとデプロイ設定を見直します。

どの業務を自動化すべきかからご相談いただけます 作り方は分かっても、自社のどの業務に適用すれば効果が出るかは別の問題です。 業務の棚卸しからご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

SlackとGoogle Chatの場合

社内向けであれば、こちらのほうが実用的です。すでに業務で使っているツール上で動かせます。

Slackボットの流れ

Slack APIのサイトでアプリを作成し、権限とイベントを設定するという流れです。LINEと比べて設定項目が多くなります。

必要な作業は、アプリの作成、Bot Token Scopesの設定、Event Subscriptionsでのイベント登録、ワークスペースへのインストールです。発行されるBot User OAuth Tokenを、GASのスクリプトプロパティに保存します。

Event Subscriptionsで指定したURLに対して、Slackは最初に検証用のリクエストを送ります。リクエストに含まれるchallengeの値をそのまま返す処理を実装しないと、URLの登録が完了しません。

3秒以内に応答する必要への対処

Slackには、3秒以内に応答を返さないとタイムアウトとみなす仕様があります。GASの処理が遅いと、再送が繰り返され、同じ応答が複数回届きます。

対処は、先に空の応答を返してから処理を続けるという構成です。あるいは、doPost内で最小限の処理だけを行い、重い処理は別の仕組みに回します。

AIを呼び出す場合は特に問題になります。応答に数秒から十数秒かかるため、3秒以内には収まりません。いったん「確認中です」と返し、完了後に改めて投稿するという2段構えにします。

Google Chatの場合

Google Workspaceを使っているなら、最も相性が良い組み合わせです。同じGoogleのサービス同士であるため、認証周りの設定が少なく済みます。

Google Cloudのプロジェクトでチャットアプリを構成し、GASのデプロイURLを指定します。応答はJSONを返すだけで、外部APIを呼び出す必要がありません。

社内限定で公開できる点も利点です。組織内のユーザーだけが使える状態にできるため、社外に漏れるリスクを抑えられます。

生成AIと組み合わせる

定型の判定では対応できない質問に答えさせる構成です。近年、相談が増えている用途です。

外部APIを呼び出す仕組み

GASからAIサービスのAPIへリクエストを送り、返ってきた文章を応答に使います。UrlFetchAppで通信するという点は、LINEへの返信と同じです。

function askAI(userText) {

  const res = UrlFetchApp.fetch(API_ENDPOINT, {

    method: ‘post’,

    contentType: ‘application/json’,

    headers: { Authorization: ‘Bearer ‘ + AI_API_KEY },

    payload: JSON.stringify({ /* 各サービスの形式に合わせる */ }),

    muteHttpExceptions: true

  });

  return JSON.parse(res.getContentText());

}

muteHttpExceptionsを有効にしておくと、エラー時にも応答内容を取得できます。原因の切り分けが速くなるため、開発中は付けておくことをおすすめします。

社内データを参照させる

汎用的なAIの回答では、社内固有の質問に答えられません。規程や手順書の内容を、質問と一緒にAIへ渡すという構成にします。

簡易な方法は、参照させたい文書をスプレッドシートに格納し、質問に関連する部分を抽出して一緒に送ることです。量が少なければ、これでも実用に耐えます。

ただし渡せる文字数には上限があります。文書が多い場合は、検索の仕組みを別に用意する必要が出てきます。この段階になると、GASだけで組むのは無理が出てきます。

費用と注意点

AIのAPIは使用量に応じた課金です。社内数十人が日常的に使う程度なら月に数千円から数万円という水準が目安になりますが、使い方で大きく変わります。

利用が想定を超えたときの上限設定を、必ず確認します。制限をかけずに公開すると、予想外の請求につながる可能性があります。

情報の扱いにも注意が必要です。社内の機密情報を外部のAIサービスへ送ることが社内規程で許されているかを、事前に確認します。ツール選定の考え方はAIツール比較｜法人利用で見るべき7つの軸と主要ツールの違い、料金の目安も参考になります。

知っておくべき制限

制限を知らずに作ると、業務に載せてから止まります。以下はGoogleの公式ドキュメントGoogle サービスの割り当てに記載されている内容にもとづきます。

実行時間は1回6分まで

スクリプトの実行時間は1回あたり6分と定められています。これを超えると処理が途中で止まります。一般アカウントでもGoogle Workspaceアカウントでも同じです。

チャットボットの応答であれば、通常は数秒で終わるため問題になりません。問題になるのは、大量のデータを検索する場合やAIの応答を待つ場合です。

対策は、処理を軽くすることです。シート全体を1行ずつ走査するのではなく、まとめて取得して配列上で処理する書き方に変えると、実行時間は大幅に短縮されます。

1日あたりの割り当て

日単位でも上限があります。特に意識すべきは、外部への通信回数（URL Fetch）と、トリガー経由の合計実行時間です。

トリガー経由の実行時間は、一般アカウントで1日90分、Google Workspaceアカウントで1日6時間が目安です。定期実行を組み込む場合は、この枠内に収まるか確認します。

利用者が増えると、通信回数の上限に近づきます。想定利用者数から1日あたりの呼び出し回数を概算し、余裕があるかを確認しておきます。

応答速度の問題

GASのWebアプリは、起動に若干の時間がかかります。応答までに1秒から数秒を要するのが通常です。

社内向けの問い合わせ用途であれば、この遅延は許容範囲です。しかし、顧客向けに公開して即座の応答が求められる場面には向きません。

「業務で使えるが、サービス品質を約束する用途には向かない」という位置づけを理解しておくことが重要です。

同時アクセスへの弱さ

複数の利用者が同時にアクセスすると、処理が待たされることがあります。同時実行数にも制限があるためです。

数十人規模の社内利用であれば、実際に同時アクセスが集中する場面は限られます。ただし、全社一斉の案内と同時にボットを案内すると、アクセスが集中します。

利用者が数百人規模になるなら、GAS以外の手段を検討します。この判断を先延ばしにすると、作り直しの工数が発生します。

つまずきやすい点と対処

技術的な難しさより、設定と手順でつまずくことのほうが多くあります。

コードを変えても反映されない

初心者が最も高い確率でぶつかる問題です。コードを保存しただけでは、公開されているWebアプリには反映されません。

デプロイを管理する画面を開き、既存のデプロイを編集してバージョンを新しくする必要があります。あるいは新しいデプロイを作成しますが、その場合はURLが変わるため、Webhookの登録もやり直します。

「動かない」と思ったら、まずデプロイを更新したか確認してください。半日悩んだ原因がこれだったという話は、珍しくありません。

アクセス設定の誤り

デプロイ時の「アクセスできるユーザー」を自分だけにしていると、外部サービスからの通知が届きません。

全員がアクセスできる設定にする必要があります。セキュリティ上不安に感じるかもしれませんが、URLは推測できない文字列であり、doPost内で送信元を検証すれば対策できます。

送信元の検証は入れておくべきです。LINEであれば署名の検証、Slackであればトークンや署名の確認ができます。第三者が直接URLを叩いても処理されない状態にしておきます。

トークンをコードに書いてしまう

アクセストークンをソースコードに直接書くと、共有した相手やバージョン管理の履歴から漏れます。

スクリプトプロパティに保存し、コードからはキー名で参照します。この方法であれば、スクリプトを共有してもトークンは見えません。

漏えいが疑われる場合は、トークンを再発行します。発行元の管理画面から新しいトークンを作り、古いものを無効化します。

同じ応答が複数回届く

応答が遅れると、チャットサービス側が通知を再送します。その結果、同じ応答が2回、3回と届くという状態になります。

対処は、処理を速くすることと、先に応答コードを返すことです。Slackの3秒制約については前述しました。

重複を検知する仕組みを入れるという対策もあります。通知に含まれるイベントIDを記録し、処理済みなら無視するという構成です。

業務で使うための運用

動くものを作った後が本番です。継続して使われる状態にするための要点を整理します。

属人化を防ぐ

個人の工夫として作ったボットが、いつの間にか部門の業務に組み込まれているという状況はよく起こります。作った人しか中身を知らない状態が最大のリスクです。

対策は3つです。スクリプトを個人のドライブではなく共有ドライブに置くこと、処理内容と設定値を文書に残すこと、そして編集権限を複数人に付与することです。

特に、トークンの発行元アカウントが個人のものになっていないかを確認します。担当者の退職とともにボットが止まるという事態を防げます。

ログを残して改善する

受け取った質問と返した応答をスプレッドシートに記録しておきます。これが改善の材料になります。

「答えられなかった質問」が見えてくると、次に追加すべき回答が分かります。逆に、まったく使われていない機能も判明します。

個人が特定できる情報を記録する場合は、保存期間と閲覧範囲を決めておきます。記録すること自体を利用者に周知しておくのが望ましい運用です。

GASで作るべきか判断する

最後に、手段の選択についてです。GASが向くのは、社内向け、小規模、要件が明確な場合です。

利用者が数百人規模、即時の応答が必須、高度な対話が必要。こうした条件が出てきたら、専用のチャットボットサービスや別の構成を検討します。

まずGASで作って効果を確かめるという進め方には価値があります。使われるかどうかも分からない段階で高額なツールを導入すると、費用だけが残ります。自動化を広げる進め方は業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法、実装の支援はAI業務自動化・GAS開発で扱っています。

まとめ

GASでチャットボットを作る仕組みは、GASをWebアプリとして公開し、チャットサービスからのWebhookをdoPostで受け取るというものです。サーバーは不要で、GAS自体の費用もかかりません。

LINEの場合は、チャネル作成、トークン取得、doPostの実装、デプロイ、Webhook登録の5ステップです。LINE Notifyは2025年3月に終了しているため、Messaging APIを使います。

Slackでは3秒以内に応答を返す必要があり、AIを呼び出す構成では対処が必要になります。Google Workspaceを使っているならGoogle Chatが最も相性が良い選択です。

制限として押さえるべきは、実行時間が1回6分まで、応答に数秒かかる、同時アクセスに弱いという3点です。社内向けの小規模用途が適所という前提で計画します。

まずはキーワードに対して定型文を返すだけのボットを作り、動かしてみてください。1本動けば、次に何を自動化すべきかは自然と見えてきます。

自動化の設計から社内定着まで、無料で相談できます 作ったものを部門で使える形にしたい、担当者1人に依存している状態を解消したいといった段階のご相談も承っています。 営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎