Googleフォームの回答をSlackに通知する方法と、設定でつまずきやすい点

Googleフォームで問い合わせや申し込みを受け付けていると、「回答が届いたらSlackにすぐ知らせてほしい」と思う場面がありますよね。フォームの回答の画面を何度も開いて確かめるのは手間ですし、メールの通知はほかのメールに埋もれがちです。チームの連絡がSlackに集まっているなら、回答もSlackのチャンネルに流れてくるほうが、気づくのも、誰が対応するかを決めるのも早くなります。

ただ、Googleフォームには、回答をSlackへ直接送る設定は標準では用意されていません。そのため、メールの通知を転送する、Google Apps Script（Googleのサービスを動かす小さなプログラム）で送る、自動化ツールでつなぐ、のどれかの方法を組み合わせることになります。

この記事では、この3つの方法の手順と向き不向きを整理したうえで、設定でつまずきやすい点と、その確かめ方を解説します。説明は、GoogleとSlackの公式のヘルプや開発者向けの資料（2026年10月3日時点）に書かれている内容をもとにしています。

フォームの通知をSlackに集めたい人が増えている背景

小さな会社やフリーランスのチームでは、フォームの回答の確認が「誰かが気づいたら対応する」状態になりやすいものです。問い合わせのメールは代表のアドレスに届き、気づいた人が返信し、ほかの人はそれを知らない。そうして返信が二重になったり、逆に誰も返さなかったりします。

社内の連絡がSlackにまとまっている職場なら、フォームの回答も同じ場所に流れてくると、チャンネルを見ているメンバー全員が新しい回答に気づけます。スタンプやスレッドの返信で「対応します」と書けば、誰が受け持ったかも分かります。メールの受信箱を何人もが見に行く必要がなくなるので、確認の手間も減ります。

在宅や移動しながら働く人にとっても、通知の場所が1つに決まっているのは大事です。出先ではノートパソコンを開けないことも多く、スマートフォンのSlackのアプリに通知が来れば、カフェの行列に並んでいる間でも回答に気づけます。フォームの回答の画面を開きに行く必要がないので、場所を問わずに受付の状況を把握できます。

一方で、通知の仕組みを一度作ると、それが止まっていても気づきにくいという弱点があります。最初は動いていたのに、いつの間にか通知が来なくなっていて、回答が何件もたまっていた、ということが起こります。この記事の後半では、そうした「止まっていることに気づけない」問題への備えも取り上げます。

通知の設定の前にGoogleフォームで整えておくこと

Slackへの通知を作る前に、Googleフォームの側で整えておくと、あとの設定が楽になることがいくつかあります。

1つ目は、回答の保存先です。公式ヘルプによると、回答はフォームの中で確認できるほか、リンクしたGoogleスプレッドシートに保存することもできます。フォームの[回答]から[回答の送信先を選択]を選び、新しいスプレッドシートを作るか、既存のスプレッドシートを選びます。通知はSlackで受けても、回答の一覧はスプレッドシートで見たい、という使い方は多いので、先に保存先を決めておきます。

ここで1つ注意があります。同じヘルプには、新しい回答用のスプレッドシートを作ると、フォームの共同編集者は自動的にそのスプレッドシートにアクセスできるようになるが、その後にフォームの権限を変えても自動的には同期されない、と書かれています。フォームから編集者を外したときは、スプレッドシートの共有も別に見直す必要があります。

2つ目は、質問の名前です。Slackに流す通知では、質問の名前がそのまま見出しのように表示されます。「質問1」「無題の質問」のままだと、通知を見ても何の項目か分かりません。「お名前」「ご用件」「希望の連絡方法」のように、短く中身の分かる名前にしておきます。

3つ目は、必須の項目です。ご用件の欄が空の回答が届くと、通知を見ても対応の優先度を判断できません。対応を決めるのに必要な項目は必須にしておくと、通知だけで判断できる場面が増えます。

4つ目は、テスト用の回答の扱いです。設定の途中では何度もテストの回答を送ることになるので、テストの回答だと分かるように、ご用件の欄に「テスト」と書く、といった決まりを作っておきます。あとで削除するときに、本物の回答と取り違えずに済みます。

Googleフォームの回答をSlackに通知する3つの方法

方法は大きく分けて3つあります。それぞれの特徴を先に表で整理しておきます。

方法	手間	費用	向いている場面
メールの通知をSlackに転送する	少ない	無料の範囲もある	まず通知だけ届けばよい
Google Apps ScriptとIncoming Webhookで送る	中くらい	無料	回答の中身もSlackで見たい
自動化ツールでつなぐ	少ない	ツールの料金がかかることがある	プログラムを書きたくない

どの方法でも、「回答が届いたことがSlackに流れる」ところまではできます。違うのは、通知に回答の中身まで載せられるか、設定やメンテナンスの手間がどれだけかかるか、費用がかかるかです。順番に見ていきます。

方法1：メールの通知をSlackに転送する

いちばん手軽なのが、Googleフォームのメール通知を使い、そのメールをSlackに送る方法です。

手順1：Googleフォームのメール通知をオンにする

公式ヘルプによると、フォームを開き、上部の[回答]をクリックし、その他アイコンから[新しい回答についてのメール通知を受け取る]をクリックすると、回答が届くたびにメールで知らせてもらえます。

手順2：メールをSlackに送る

Slackのヘルプでは、Slackにメールを送る方法が3つ紹介されています。1つ目は、チャンネルまたはダイレクトメッセージ（DM）の専用のメールアドレスを作る方法で、これは有料プランの機能です。2つ目は、GmailやOutlookのアドオンを使って個別のメールをチャンネルやDMに送る方法、3つ目は、Slackbotの転送先アドレスを作ってメールを自分のDMに送る方法で、こちらは全プランで使えると案内されています。

有料プランを使っているなら、チャンネル用のメールアドレスを作り、Gmailの自動転送のルールで、フォームの通知のメールだけをそのアドレスに転送するのが分かりやすい形です。無料プランの場合は、Slackbotの転送先アドレスを使えば自分のDMに届けられますが、チャンネルのメンバー全員で共有する形にはなりません。

転送のルールは通知のメールだけに絞る

Gmailで自動転送のルールを作るときは、受信したメールをすべて転送するのではなく、フォームの通知のメールだけに絞ります。差出人や件名の条件でフィルタを作り、その条件に合うメールだけを転送するようにしておけば、私用や取引先のメールがSlackのチャンネルに流れ込む事故を防げます。ルールを作ったら、テストの回答を送り、通知のメールだけがSlackに届き、ほかのメールが届かないことを確かめておくと安心です。

この方法の注意点

この方法の弱点は、通知のメールに回答の中身がどこまで載るかを、自分で決められないことです。「回答が届いた」ことは分かっても、何の問い合わせかを見るには、結局フォームの回答の画面を開く必要があります。また、メールの転送のルールを作った人のアカウントに依存するので、その人が異動や退職でアカウントを使わなくなると、通知も止まります。

まずは通知が届けばよい、という段階では十分ですが、回答の中身をSlackで見て、その場で担当を決めたいなら、次の方法2が向いています。

方法2：Google Apps ScriptとIncoming Webhookで送る

回答の中身までSlackに流したい場合は、Google Apps Scriptを使う方法が定番です。費用はかからず、通知の文面も自由に決められます。プログラムといっても、数十行の短いもので済みます。

手順1：SlackでIncoming WebhookのURLを作る

Incoming Webhookは、外部からSlackにメッセージを投稿するための仕組みです。Slackの開発者向けの資料によると、Slackのアプリを作り、設定の画面で「Incoming Webhooks」をオンにし、「Add New Webhook to Workspace」から投稿先のチャンネルを選んで許可すると、そのチャンネル専用のWebhook URLが発行されます。このURLにメッセージの文章をJSONという形式で送ると、チャンネルに投稿されます。プライベートチャンネルに投稿したい場合は、先に自分がそのチャンネルに入っている必要があります。

同じ資料では、Webhook URLには秘密の情報が含まれるので、オンラインで共有しないこと、公開のリポジトリなどに載せないことが強く注意されています。漏れたURLは、Slackが見つけしだい無効にするとも書かれています。

手順2：フォームにスクリプトを作る

Googleフォームの編集画面で、その他のメニューからスクリプトエディタを開きます。フォームに結び付いたスクリプトが作られるので、次のような関数を書きます。

function notifySlackOnSubmit(e) {
  const url = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK_URL');
  const items = e.response.getItemResponses();
  let text = '新しいフォームの回答が届きました\n';
  items.forEach(function (item) {
    text += '・' + item.getItem().getTitle() + '：' + item.getResponse() + '\n';
  });
  UrlFetchApp.fetch(url, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: text }),
  });
}

この関数は、届いた回答の質問と答えを1行ずつ並べた文章を作り、Webhook URLに送ります。Webhook URLはプログラムの中に直接書かず、スクリプトのプロパティ（スクリプトごとに保存できる設定値）に「SLACK_WEBHOOK_URL」という名前で保存しておくと、コードを人に見せたり、別の人に引き継いだりするときにURLが漏れません。

手順3：フォーム送信のトリガーを作る

関数を書いただけでは動きません。「フォームが送信されたらこの関数を動かす」というきっかけ（トリガー）を設定します。スクリプトエディタのトリガーの画面から、実行する関数に先ほどの関数を選び、イベントの種類を「フォーム送信時」にして保存します。保存するときに、Googleアカウントでの承認を求められるので、内容を確かめて許可します。

Googleの開発者向けの資料によると、フォーム送信のトリガーには、Googleフォーム自体に付けるものと、回答を記録するスプレッドシートに付けるものの2種類があります。どちらでも動きますが、回答を受け取るときに使える情報が少し違います。上のコードはフォーム自体に付ける前提で書いています。

手順4：テストの回答で確かめる

設定を保存したら、自分でテストの回答を送り、Slackのチャンネルに通知が届くかを確かめます。届かない場合は、スクリプトエディタの実行の記録を開くと、エラーの内容を確かめられます。確かめ終わったら、テストの回答は削除しておきます。

方法3：自動化ツールでつなぐ

プログラムを書きたくない場合は、Zapierやn8nのような、サービス同士をつなぐ自動化ツールを使う方法もあります。多くの自動化ツールには、「Googleフォーム（またはスプレッドシート）に新しい行が増えたら、Slackにメッセージを送る」といった組み合わせを、画面の操作だけで作れる仕組みがあります。

この方法の利点は、設定が画面の操作で完結することと、通知の文面やチャンネルの選び方を後から変えやすいことです。一方で、無料の範囲で動かせる回数や、新しい回答を見に行く間隔に制限があるツールも多く、回答が多いフォームでは有料の契約が必要になることがあります。料金と無料の範囲は、それぞれのツールの公式の料金ページで、使う前に確かめてください。

また、自動化ツールにGoogleアカウントとSlackの両方の接続を許可することになるので、会社のアカウントで使う場合は、管理者の許可が必要かどうかも先に確かめておきます。

設定でつまずきやすい点

ここからは、特に方法2のGoogle Apps Scriptで、設定のときにつまずきやすい点を整理します。

トリガーは作った人のアカウントで動く

もっとも大事なのが、トリガーがどのアカウントで動くかです。Googleの開発者向けの資料には、次のように書かれています。

インストール可能なトリガーは、常に作成者のアカウントで実行されます。 出典: developers.google.com

つまり、通知の仕組みは、トリガーを作った人のアカウントに結び付いています。作った人が会社を辞めてアカウントが削除されたり、権限が外されたりすると、通知も止まります。チームで使う仕組みなら、個人ではなく、チームで管理している共用のアカウントでトリガーを作るか、作った人と作った日を記録しておき、担当が替わるときに作り直す手順を決めておきます。

同じ資料には、あるアカウントがほかのアカウントの作ったトリガーを見ることはできない、とも書かれています。複数の人が同じフォームにトリガーを作ると、通知が二重に届くのに、どこで設定されているのか分からない、という状態になりやすいので注意してください。

1日あたりの上限がある

Google Apps Scriptには、1日あたりの割り当て（上限）があります。公式の資料によると、Gmailなどの一般ユーザー向けアカウントでは、外部へのURL取得の呼び出しが1日20,000回、トリガーの合計の実行時間が1日90分です。Google Workspaceのアカウントでは、それぞれ1日100,000回、1日6時間です。割り当ては、最初のリクエストから24時間後にリセットされると案内されています。

フォームの回答をSlackに1件ずつ送るだけなら、1回の実行は短い時間で終わるので、普通の問い合わせフォームで上限に届くことはまずありません。ただし、同じアカウントでほかにも多くのスクリプトを動かしている場合は、合計で上限に近づくことがあるので、覚えておいてください。

プログラムから送った回答ではトリガーが動かない

テストのために、スクリプトから回答を送信して動作を確かめようとする人がいますが、公式の資料によると、スクリプトの実行やAPIのリクエストで新しい回答を送信しても、フォーム送信のトリガーは実行されません。動作の確認は、実際にフォームを開いて回答を送る方法で行います。

失敗しても画面には出ない

トリガーで動いた処理が失敗しても、画面にエラーのメッセージは表示されません。公式の資料によると、代わりにApps Scriptから失敗のまとめがメールで届きます。このメールの送り先は、トリガーを作った人です。作った人がこのメールを見落とすと、通知が止まっていることに誰も気づけません。失敗のメールをチームで見る場所に転送しておくと、気づくのが早くなります。

Webhook URLを作り直したら設定も直す

SlackのWebhook URLは、アプリを作り直したり、チャンネルを変えたりすると新しくなります。古いURLのまま送ると、通知は届きません。スクリプトのプロパティに保存しておけば、URLを差し替えるだけで済むので、コードの中を探して書き換える必要がありません。

通知の文面に個人の情報をどこまで載せるか

回答の中身をそのままSlackに流すと、氏名、メールアドレス、電話番号などもチャンネルに投稿されます。チャンネルに参加している人全員が見られるうえ、Slackの中に記録として残ります。問い合わせの用件だけを載せ、連絡先はフォームの回答の画面で見る、というように、通知に載せる項目を選んでおくと安心です。上のコードなら、特定の質問のときは文面に加えない、という条件を付け加えれば対応できます。

通知の文面を読みやすくする工夫

通知が届くようになったら、次は文面です。Slackの通知は、スマートフォンのロック画面やデスクトップの通知では、最初の1行か2行しか表示されません。その数行で「何の回答か」「急ぎかどうか」が分かるように作ると、通知を開かなくても対応の判断ができます。

1つ目の工夫は、最初の行にフォームの名前を入れることです。複数のフォームを同じチャンネルに流していると、「新しい回答が届きました」だけでは、問い合わせなのか、申し込みなのかが分かりません。「お問い合わせフォームに新しい回答」のように、1行目でフォームを区別できるようにします。

2つ目は、いちばん大事な項目を先頭に置くことです。問い合わせなら「ご用件」、申し込みなら「希望の日程」のように、対応を決めるのに必要な項目を最初に並べ、名前や連絡先は後ろに回すか、通知には載せない形にします。上のコードでは質問の順に並べていますが、特定の質問だけを先に取り出して文面を組み立てることもできます。

3つ目は、全員への通知を乱用しないことです。Slackには、チャンネルの全員に通知を送る書き方がありますが、回答のたびに全員へ通知が飛ぶと、通知そのものが無視されるようになります。普段は通常の投稿にしておき、急ぎの用件の選択肢が選ばれたときだけ担当者にメンションを付ける、というように、条件で分けるのが現実的です。

4つ目は、通知の数が多すぎないかを見直すことです。1日に数十件の回答が届くフォームでは、1件ずつの通知がチャンネルを埋め、ほかの連絡が流れてしまいます。その場合は、フォームの通知専用のチャンネルを作り、チームの会話のチャンネルと分けると、両方が見やすくなります。通知専用のチャンネルを作ったら、チャンネルの説明欄に「どのフォームの通知が流れるか」「対応したらスレッドに何と書くか」を書いておくと、あとから参加したメンバーにも使い方が伝わります。

場面別に見た方法の選び方

3つの方法のどれを選ぶかは、受付の件数と、通知のあとに何をするかで決まります。よくある場面ごとに整理しておきます。

ひとりで仕事をしていて、月に数件の問い合わせが届くだけなら、方法1のメール通知で十分です。Slackbotの転送先アドレスを使えば、無料プランでも自分のDMに届けられます。わざわざスクリプトを書いて管理する手間をかけるほどではありません。

数人のチームで問い合わせを分担しているなら、方法2が向いています。回答の中身がチャンネルに流れるので、誰が対応するかをその場で決められます。トリガーを作るアカウントと、失敗のメールの送り先を決めておくことを忘れないでください。

プログラムに触れる人がチームにいない場合は、方法3の自動化ツールが候補になります。料金がかかることがありますが、仕組みを画面の操作で確かめられるので、担当が替わっても引き継ぎやすいという利点があります。

申し込みやイベントの受付のように、回答のあとに返信や確認の作業が続く場合は、通知の仕組みだけでは足りなくなってきます。その場合の考え方は、後の節で触れます。

通知が止まっていないかを確かめる習慣

通知の仕組みは、動いているときには意識されず、止まったときにも気づかれにくいものです。次のような確かめ方を習慣にしておくと、回答がたまってから慌てることを防げます。

1つ目は、週に1回、フォームの回答の件数と、Slackに届いた通知の件数を見比べることです。数が合わなければ、どこかで通知が漏れています。

2つ目は、月に1回程度、テストの回答を送って通知が届くかを確かめることです。担当が替わったとき、Slackのアプリの設定を変えたとき、フォームの質問を大きく変えたときは、そのたびに確かめます。

3つ目は、仕組みの記録を残しておくことです。どのアカウントでトリガーを作ったか、Webhook URLはどのSlackのアプリで発行したか、通知先はどのチャンネルかを、チームで見られる場所に書いておくと、引き継ぎで仕組みが迷子になりません。

実際に起こりやすい失敗の例

ここで、Googleフォームの通知をSlackにつないだあとで、実際に起こりやすい失敗を3つ紹介します。どれも、設定の時点では気づきにくいものです。

フォームを複製したら通知が来なくなった

募集の回ごとにフォームを複製して使っていたところ、新しいフォームの回答だけSlackに届かなかった、という失敗です。トリガーは元のフォームに結び付いて作られているので、複製したフォームには、あらためてトリガーを作る必要があります。フォームを複製したときは、スクリプトとトリガーが新しいフォームにも設定されているかを、テストの回答で確かめる手順を決めておきます。

通知が二重に届くようになった

担当が替わったときに、新しい担当者が自分のアカウントでトリガーを作り直したところ、前の担当者のトリガーも残っていて、通知が2件ずつ届くようになった、という失敗です。前の節で書いたとおり、ほかのアカウントが作ったトリガーは見えないので、どこで二重になっているのかを探すのに時間がかかります。担当を引き継ぐときは、前の担当者に自分のトリガーを削除してもらってから、新しく作る順番にします。

質問を変えたら通知の文面が崩れた

フォームの質問を並べ替えたり、名前を変えたりしたところ、通知の文面で項目の順番が変わり、いちばん大事な「ご用件」が最後に回ってしまった、という失敗です。特定の質問を名前で探して先頭に並べるように書いていた場合は、質問の名前を変えると、その項目が通知から抜け落ちることもあります。フォームの質問を変えたときは、通知の文面も確かめる、という手順をセットにしておきます。

回答の通知のあとに必要になること

Slackへの通知ができると、回答に気づくのは早くなります。ただ、運用を続けると、次に「誰が対応しているか」「返信は済んだか」を管理したくなります。スレッドに「対応します」と書くだけでは、件数が増えると、どの回答が終わっていてどれが残っているかが分かりにくくなります。

よく見かけるのは、回答を記録するスプレッドシートに「担当」「状況」「返信日」の列を手で追加して管理する方法です。少ない件数なら十分ですが、通知はSlack、管理はスプレッドシート、返信はメール、と道具が3つに分かれるので、確認の手間はそれなりにかかります。

スプレッドシートで管理を続けるなら、いくつかの工夫で手間を減らせます。「状況」の列はプルダウンにして「未対応」「対応中」「返信済み」のように選択肢をそろえる、未対応の行に色が付くように条件付き書式を設定する、担当者が自分の行だけを見られるようにフィルタ表示を作る、といった工夫です。Slackのスレッドで「対応します」と書いたら、スプレッドシートの担当の列にも名前を入れる、という決まりにしておくと、2つの道具の内容がずれにくくなります。

それでも、件数が増えるほど、Slackとスプレッドシートとメールを行き来する時間は増えていきます。1件の対応にかかる時間のうち、道具を行き来している時間がどれくらいあるかを一度測ってみると、仕組みを見直す時期かどうかを判断しやすくなります。

Googleフォームでは手間が増えてきたときの候補

回答の通知から、担当と対応の状況の管理、返信までを1か所で扱いたい場合の候補の1つに、フォームの作成から回答の対応までを扱うクラウドサービスのHalict（ハリクト）があります。

公式の外部連携のページによると、Halictはフォームごとの通知の設定で送り先を選ぶだけで、新しい回答をSlackのチャンネルに流せます。Teams、Discord、Chatwork、Googleスプレッドシート、任意のURL（Webhook）にも送れると案内されており、プログラムを書く必要はありません。届いた回答には担当者と対応の段階（ステージ）を付けられ、回答の画面から個別のメールを送ることもできます。

料金は使うメンバーの人数で決まり、どのプランでもフォームの数と回答の数は無制限です。ただし、Slackなどのチャットへの通知は、公式の料金ページではメンバー10人までのチームプラン（月額7,800円、税抜）の機能として並んでいます。メンバー1人までのフリープラン（0円）では、ステージ管理、自動返信、CSVの書き出しが使え、Slackへの通知は含まれていません。通知だけが目的なら、この記事の方法2で十分です。対応の管理と返信までをまとめたくなったときに比べてみてください。

Halictは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

通知の仕組みづくりを仕事として見たときの考察

最後に、在宅ワークや業務委託の仲介を長く運営してきた立場から、こうした通知の仕組みづくりについて見えていることを書いておきます。

運営者として見てきた限りでは、フォームとチャットをつなぐような小さな自動化は、外部の人に頼まれることの多い仕事の1つです。数十行のスクリプトでも、依頼する側にとっては「回答の見落としがなくなる」という大きな価値があります。一方で、うまくいかない依頼に共通しているのは、作って納品したところで終わり、誰のアカウントで動いているのか、止まったら誰が直すのかが決まっていないことです。この記事で取り上げた「トリガーは作った人のアカウントで動く」という点は、外部の人に作ってもらうときこそ重要になります。

業務の流れを整理して、こうした自動化を提案する仕事は、AIコンサル・業務活用支援のお仕事で紹介しています。スクリプトやアプリの開発を伴う仕事は、アプリケーション開発のお仕事で扱っています。報酬の水準を知りたい場合は、ソフトウェア作成者の年収・単価相場で確認できます。

仲介の手数料が間に入らない直接の取引であれば、依頼する側は同じ予算でより丁寧な引き継ぎの資料まで頼め、受ける側は手取りが厚くなります。小さな自動化ほど、作った後の運用の約束まで含めて取り決めておくことが、長く使える仕組みにつながります。

よくある質問

Q. Googleフォームの回答をSlackに通知するのに費用はかかりますか？

Google Apps ScriptとSlackのIncoming Webhookを使う方法なら、追加の費用はかかりません。メールの通知を転送する方法は、Slackのチャンネル用メールアドレスが有料プランの機能ですが、Slackbotの転送先アドレスは全プランで使えます。自動化ツールを使う場合は、そのツールの無料の範囲と料金を公式で確かめてください。

Q. 通知が急に届かなくなったときは何を確かめればいいですか？

まず、トリガーを作った人のアカウントが使える状態かを確かめます。インストール可能なトリガーは作成者のアカウントで動くため、退職や権限の変更で止まることがあります。次に、Apps Scriptから失敗のまとめのメールが届いていないか、SlackのWebhook URLが作り直されていないかを確かめ、テストの回答で動作を確認します。

Q. Webhook URLはどこに保存すればいいですか？

Slackの開発者向けの資料では、Webhook URLには秘密の情報が含まれるので、オンラインで共有しないよう注意されています。スクリプトのコードに直接書かず、スクリプトのプロパティに保存しておくと、コードを人に見せたり引き継いだりするときに漏れにくくなります。URLを作り直したときも、プロパティを差し替えるだけで済みます。

Q. 回答の中身をすべてSlackに流しても大丈夫ですか？

氏名や連絡先までSlackに流すと、チャンネルに参加している全員が見られ、Slackの中に記録として残ります。問い合わせの用件だけを通知に載せ、連絡先はフォームの回答の画面で確かめる形にすると安心です。社内の決まりで扱いが決められている情報があれば、そちらを優先してください。