営業リスト作成を自動化する｜Places APIとスプレッドシートで毎週更新、営業が使うリストにする合意の取り方まで

営業リストを作る作業は、営業の仕事の中で最も評価されにくく、最も時間を食う仕事です。地図で探し、Excelに写し、公式サイトで確かめる。その繰り返しを週に1回、機械が肩代わりする仕組みを、設計図から現場の合意の取り方まで順に説明します。

手順だけなら半日で動きます。難しいのはその先で、機械が作ったリストを営業が「自分のリスト」として使うかどうかは、ツールの性能ではなく導入の進め方で決まります。この記事は、そこに分量を割いています。

ムダの現状：リスト作りに営業の時間が消えている

新規開拓を任された営業担当者が、最初にやる仕事は「相手を探すこと」です。地図アプリで業種と地域を検索し、店名と電話番号をExcelに写し、公式サイトを開いて問い合わせ先を確認する。1件あたり3分としても、100件で5時間です。週に1回これをやれば、月に20時間が「電話をかける前の準備」に消えます。

問題は時間だけではありません。担当者ごとに書式が違い、同じ会社が別々のリストに重複して載り、断られた相手に別の担当者がまた電話をかける。リストが人に紐づいているため、担当者が辞めるとリストも消えます。上司から見ると「営業リストはあるはず」なのに、実態は個人のExcelが散らばっているだけ、という状態が珍しくありません。

この作業のどこが「機械に渡せる部分」か

リスト作りは、3つの作業に分解できます。

自動化するのは上の2つだけです。3つ目まで機械に任せると、営業は「自分の判断で動いていない」と感じ、リストを使わなくなります。この線引きが、後述する合意形成の土台になります。

スキームの全体図

仕組みは単純です。スプレッドシートに「地域」と「業種」を書いておくと、週に1回Apps Scriptが動き、Places APIに問い合わせて候補を取り、重複を除いてシートに追記します。営業は毎週月曜の朝に、新しい候補が並んだシートを開くだけです。

図の中で最も重要なのは4番の重複チェックです。ここを省くと「先週断られた店がまた載っている」という状態になり、営業はリストを信用しなくなります。Place ID（Googleが各地点に付ける固有の識別子）で照合すれば、店名の表記ゆれに左右されずに同一店舗を判定できます。

必要なツールと費用（2026年9月7日時点）

使うのは3つです。いずれも新しい契約は不要で、Googleアカウントがあれば始められます。

Places APIの料金は「どの項目を取るか」で決まる

ここが最初のつまずきどころです。Places APIは、1回の問い合わせで要求した項目のうち最も高いランクの項目に応じて課金区分（SKU）が決まります。公式の料金表（2026年9月1日更新）では、Text Searchの区分と無料枠は次のとおりです。

営業リストには公式サイトのURLが欲しいので、実務ではEnterprise区分になります。無料枠は月1,000リクエスト。1リクエストで最大20件、1つの検索条件で最大60件（3ページ）まで取れるので、たとえば30地域×3業種＝90条件を毎週回すと、270リクエスト/週、月に約1,100リクエストです。無料枠を100ほど超え、超過分は約3.5ドルです。日本円で数百円の世界なので、費用で止まる話ではありません。

ただし、無料枠を使うだけでもGoogle Cloudの請求先アカウント（クレジットカード登録）が必須です。経理に「カードを登録するが、月の上限を設定するので請求はほぼ発生しない」と先に説明しておくと、後で揉めません。上限の設定方法は手順の中で触れます。

導入手順：半日で動く状態にする

所要時間の目安は、Google Cloudの設定に1時間、シートとスクリプトに2時間、テストと調整に1時間です。エンジニアでなくても進められる粒度で書きます。

手順1：Google CloudでPlaces APIを有効にする（約1時間）

1. Google Cloud Consoleにログインし、新しいプロジェクトを作る。名前は「sales-list」など用途が分かるものにする
2. 左メニュー「お支払い」で請求先アカウントを紐づける。ここでカード登録が必要になる
3. 「APIとサービス」→「ライブラリ」で「Places API (New)」を検索し、有効にする。旧版の「Places API」と別物なので、必ず「(New)」を選ぶ
4. 「認証情報」→「認証情報を作成」→「APIキー」。作成したキーは「APIの制限」でPlaces API (New)のみに限定する。制限をかけないキーが漏れると、他のAPIまで使われて請求が跳ねる
5. 「お支払い」→「予算とアラート」で、月額の予算を例えば1,000円に設定し、50％・90％・100％でメール通知を受けるようにする。これが経理への説明材料になる

手順2：スプレッドシートを2枚のシートで作る（約30分）

1つのスプレッドシートに「条件」と「候補」の2シートを作ります。

ポイントは、機械が書く列（A〜F）と人が書く列（G〜I）を分けることです。スクリプトはA〜Fしか触らないので、営業が書いたメモが上書きされる事故が起きません。

手順3：Apps Scriptを書く（約1時間30分）

スプレッドシートの「拡張機能」→「Apps Script」を開き、次のコードを貼ります。APIキーは「プロジェクトの設定」→「スクリプト プロパティ」に PLACES_API_KEY という名前で保存し、コードに直接書かないでください。

function updateSalesList() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var condSheet = ss.getSheetByName('条件');
  var listSheet = ss.getSheetByName('候補');
  var apiKey = PropertiesService.getScriptProperties().getProperty('PLACES_API_KEY');
  var known = {};
  var ids = listSheet.getRange(2, 1, Math.max(listSheet.getLastRow() - 1, 1), 1).getValues();
  ids.forEach(function(r) { if (r[0]) { known[r[0]] = true; } });
  var conds = condSheet.getRange(2, 1, Math.max(condSheet.getLastRow() - 1, 1), 3).getValues();
  var today = Utilities.formatDate(new Date(), 'Asia/Tokyo', 'yyyy-MM-dd');
  var rows = [];
  conds.forEach(function(c) {
    if (!c[0] || !c[1] || c[2] !== true) { return; }
    var pageToken = '';
    for (var page = 0; page < 3; page++) {
      var body = { textQuery: c[0] + ' ' + c[1], languageCode: 'ja', regionCode: 'JP', pageSize: 20 };
      if (pageToken) { body.pageToken = pageToken; }
      var res = UrlFetchApp.fetch('https://places.googleapis.com/v1/places:searchText', {
        method: 'post', contentType: 'application/json', payload: JSON.stringify(body),
        headers: { 'X-Goog-Api-Key': apiKey,
          'X-Goog-FieldMask': 'places.id,places.displayName,places.formattedAddress,places.websiteUri,places.businessStatus,nextPageToken' },
        muteHttpExceptions: true });
      if (res.getResponseCode() !== 200) { Logger.log(res.getContentText()); break; }
      var data = JSON.parse(res.getContentText());
      (data.places || []).forEach(function(p) {
        if (known[p.id]) { return; }
        known[p.id] = true;
        rows.push([p.id, today, p.displayName ? p.displayName.text : '', p.formattedAddress || '',
          p.websiteUri || '', p.businessStatus || '', '', '未確認', '']);
      });
      pageToken = data.nextPageToken || '';
      if (!pageToken) { break; }
      Utilities.sleep(1500);
    }
  });
  if (rows.length) { listSheet.getRange(listSheet.getLastRow() + 1, 1, rows.length, 9).setValues(rows); }
  Logger.log(rows.length + ' 件を追加');
}

コードで押さえるべき点は3つです。

• FieldMaskで項目を絞る。ここに rating や reviews を足すと課金区分が上がる。営業リストに必要なのは店名・住所・公式サイト・営業状態まで
• 既存のPlace IDは飛ばす。これが重複チェックの本体。Hのステータスが「対象外」でも行を消さずに残しておけば、二度と追記されない
• ページ送りの間に待つ。nextPageToken は発行直後だと有効にならないことがあるため、1.5秒待ってから次を取る

手順4：テストしてから、毎週のトリガーを設定する（約1時間）

1. 条件シートに1行だけ書き、エディタ上で updateSalesList を手動実行する。初回は権限の承認画面が出るので許可する
2. 候補シートに20〜60件が入ることを確認する。0件なら、実行ログにAPIのエラー本文が出ているので、キーの制限とAPIの有効化を見直す
3. Google Cloudの「APIとサービス」→「Places API (New)」→「指標」で、リクエスト数とSKUの内訳が想定どおりか確認する
4. 問題なければ、エディタ左の時計アイコン「トリガー」から、updateSalesList を「時間主導型 / 週ベース / 月曜 / 午前5時〜6時」で登録する

これで、営業が月曜の朝にシートを開くと、その週の新規候補が「未確認」で並んでいる状態になります。

任意：AIで「話しかける口実」を下書きさせる

候補の公式サイトURLがあるなら、生成AIに「このサイトを読んで、当社の商材と接点がありそうな点を1行で」と書かせ、I列のメモに入れておく方法があります。Apps Scriptから生成AIのAPIを呼び、公式サイトの本文を渡して要約させる構成で、1件あたり数円で済みます。営業が電話の前にサイトを開いて読む時間が、1件2〜3分から30秒程度に縮みます。

ただし、この機能は最初から入れないでください。営業の合意が取れて、候補出しだけの運用が1か月回ってから足すのが順序です。技術的には簡単でも、入れる順番を間違えると受け取られ方が変わります。理由は次の章で説明します。

現場の合意の取り方：営業が使うリストにする

仕組みが動いても、営業が使わなければ成果はゼロです。営業リストの自動化で反対が出る場面は、だいたい決まっています。

反対が出る3つの場面と、その理由

3つとも、ツールの性能で解決する話ではありません。設計と進め方で解決します。

合意を取る5つの手順

1. 最初に「優先順位づけは自動化しない」と宣言する。機械がやるのは候補出しと重複除去まで。どこから当たるか、何を話すかは営業が決める。これを最初に言葉にしておくと、「目利きの価値が下がる」という懸念が消えます。

2. 営業のExcelを先に取り込む。運用を始める前に、各担当者が持っている既存リストを候補シートに移し、ステータスを付けてもらいます。店名しかない行は、Places APIで店名検索してPlace IDを付けます。これをやらずに始めると、1週目に「もう当たった店」が必ず混ざります。手間はかかりますが、ここを省いた自動化は信用を失って終わります。

3. 条件シートの編集権を営業に渡す。地域と業種を決めるのは営業です。管理側が条件を決めて流すと「やらされるリスト」になります。営業が自分で「来週は杉並区の歯科」と書き、月曜にそれが並ぶ。この体験が「自分で作った感覚」を生みます。

4. 件数を評価に使わないと決めて、文書に残す。候補件数は機械が出す数字であって、営業の成果ではありません。評価に使うのは「架電済」から先のステータスの動きだけ。これを管理職が明文化しないと、1か月目の反発が起きます。

5. 1チーム・1か月で試し、営業に報告させる。全社導入ではなく、乗り気な担当者1〜2人から始めます。1か月後、その担当者に「準備時間がどれだけ減ったか」を営業会議で話してもらう。管理側が数字を発表するより、同僚の言葉のほうが何倍も効きます。

AIの下書きを後回しにする理由

先ほどの「話しかける口実をAIに書かせる」機能を最初から入れると、営業は「自分の言葉で話す余地がない」と感じます。トークの入口まで機械に決められた、と受け取られるからです。まず候補出しだけで信頼を作り、営業側から「サイトを読むのが面倒だ」という声が出てから足す。同じ機能でも、「押し付けられた下書き」と「頼んで付けてもらった補助」では受け取られ方がまったく違います。

足すときも、AIの文章をそのまま話させるのではなく「参考メモ」として扱う位置づけを明確にしてください。営業が自分の言葉に直す前提であれば、抵抗はほとんど出ません。逆に、メモの文面が管理職のチェック対象になった瞬間に、営業は書き換えをやめて機械の文章を読み上げるようになります。それは合意の失敗です。

失敗パターンと限界：規約・法律・データの鮮度

ここは省略せずに読んでください。仕組みが動いても、次の3点を外すと会社が損をします。

1. Places APIの取得データは、原則として長期保存できない

Googleのポリシーでは、Places APIで取得した内容を事前取得・キャッシュ・保存することは、認められた例外を除いて禁止されています。例外として明記されているのがPlace IDで、これは無期限に保存できます。つまり、店名や電話番号を溜め込んで自社データベースにする使い方は、規約上グレーではなく黒に近い。

この記事の設計でPlace IDを主キーにしているのは、重複チェックのためだけではありません。長期に持ち続けてよい情報はPlace IDだけで、店名や公式サイトは「営業が当たるときに確認する一時的な情報」と位置づけているからです。運用としては、ステータスが「架電済」以降になった行は、営業が公式サイトや電話で確認した情報をG〜I列に自分の言葉で書き、A〜F列の取得値には依存しない形にします。保存期間の細かい条件は利用規約（Service Specific Terms）に定めがあるので、導入前に法務か担当者が原文を確認してください。

2. リストを「メール送信」に使うなら特定電子メール法が関わる

取ったリストに一斉メールを送る発想は自然ですが、日本では特定電子メール法の規制対象です。法律の条文（第三条第一項）では、広告宣伝メールを送ってよい相手は、あらかじめ同意した者、取引関係にある者、そして「自己の電子メールアドレスを公表している団体又は個人（個人にあっては、営業を営む者に限る）」などに限られています。公式サイトにアドレスを載せている事業者への送信はこの例外に当たりうる一方、省令で除外条件（受信を拒む旨の表示があるアドレスなど）が定められており、同法第三条第三項により、相手から「送らないでほしい」と通知を受けたあとの送信は禁止です。

さらに第四条の表示義務として、送信者の氏名または名称、受信拒否の通知先などをメール本文に正しく表示しなければなりません。送信者情報を偽った場合は、第三十四条で1年以下の拘禁刑または100万円以下の罰金です。営業リストの自動化は「探す作業」を減らすものであって、「一斉送信の免罪符」ではありません。メールに使うなら、法務の確認を挟んでください。

3. 「営業状態」は当日の真実ではない

Places APIが返す営業状態（businessStatus）は、閉業していれば CLOSED_PERMANENTLY のように返りますが、更新には時間差があります。取得日から1か月たった行は、営業が当たる前に公式サイトで再確認する。これを候補シートの運用ルールに書いておくと、「電話したら潰れていた」という無駄が減ります。

この仕組みが向かないケース

• 相手が地図に載っていない業種。BtoBの製造業や、店舗を持たない士業・コンサルは、地図検索で拾いきれない。この場合は業界団体名簿や求人情報など、別の入口が要る
• 月に数十件しか当たらない営業。候補が足りていないのではなく、商談化率の問題であることが多い。自動化より先に、断られた理由の記録を整えたほうが効く
• 担当者が1人しかいない会社。重複も属人化も起きないので、月1回の手作業で十分。半日の設定と月次の管理のほうが高くつく

効果の測り方

見る数字は3つで足ります。導入前の1か月分を先に記録しておくと、比較ができます。

商談化率や受注はここでは見ません。それは営業の腕とオファーの問題で、リスト作成の自動化が直接動かす数字ではないからです。効果を測る範囲を「準備の手間」に限定しておくと、うまくいかなかったときに「自動化のせい」にも「営業のせい」にもならず、次の手が打てます。

まとめ

• 営業リスト作りは「候補の抽出」「情報の確認」「優先順位づけ」に分かれ、機械に渡すのは前の2つまで
• Places API（Text Search）＋スプレッドシート＋Apps Scriptで、毎週月曜に候補が並ぶ仕組みが半日で作れる。費用は月1,000リクエストまで無料、超えても数百円台
• Place IDを主キーにして重複を除く。これが現場の信頼を決め、規約上も長期保存してよい唯一の項目になる
• 合意は「優先順位づけを自動化しない宣言」「既存Excelの先行取り込み」「条件の編集権を営業へ」「件数を評価に使わない明文化」「1チーム1か月の試行」の5手順で取る
• 取得データの保存とメール送信には規約と法律の制約がある。導入前に確認する

よくある質問

Places APIではなく、地図サイトを直接コピーしてはいけませんか

Googleマップの画面から手作業や自動化ツールで情報を取る行為は、利用規約で禁止されているスクレイピングに当たる可能性があります。API経由であれば、料金と条件のもとで正規に取得できます。手間は同じ程度なので、APIを使ってください。

電話番号も取りたいのですが

FieldMaskに places.nationalPhoneNumber を足せば取れます。区分はEnterpriseのままなので費用は変わりません。ただし保存の制約は店名と同じです。架電時に使い、長期保存はしない運用にしてください。

1条件で60件までしか取れないのは少なくないですか

地域を細かく割ってください。「東京都 歯科医院」ではなく「世田谷区 歯科医院」「杉並区 歯科医院」のように条件を増やせば、条件数×60件まで広がります。条件シートに行を足すだけで、コードの変更は不要です。

Excelしか使っていない会社でも同じことができますか

Power AutomateやVBAで同じ構成が組めますが、週次の自動実行と共有のしやすさはGoogleスプレッドシートのほうが簡単です。営業リストだけGoogleに寄せる形でも運用上の問題は出にくいです。

営業から「機械のリストは使わない」と言われました

その担当者の既存リストを先に取り込んでいるか、条件を本人が書けるようになっているか、件数が評価に使われないと伝えているか、の3点を確認してください。3つとも済んでいて拒否されるなら、その担当者は試行チームから外し、乗り気な人の結果を先に出すほうが早いです。

費用が急に増えることはありますか

FieldMaskに評価やレビューを足すと区分が上がります。また、条件シートに大量の行を足せばリクエスト数が増えます。Google Cloudの予算アラートを必ず設定し、月の途中で通知が来たら条件の行を減らしてください。