毎朝おなじサイトを開いて、価格や在庫や投稿の数を目で追い、スプレッドシートに書き写す。地味なわりに時間を取られる作業です。この記事では、そうしたデータ収集を自動化したいときに、つまずきにくい順番で進める考え方と、公開APIからデータを取得する最小サンプルを、コードを書いたことがない前提でも追えるように整理します。答えを先に言うと、いきなりサイトを自動で読みに行くのではなく、まず公式の窓口(API)があるかを探す、というのが遠回りしにくい進め方です。

その手作業、そもそも自動化していいのか

自動化を考える前に、1つ確認しておきたいことがあります。それは「相手のデータを、どういう立場で・どういうルールのもとで受け取るのか」という点です。

同じ「情報収集の自動化」でも、通る道によって話がまるで変わります。相手が正式に公開した窓口を通り、その利用条件を守って使うのと、WebページのHTMLをプログラムで取得・解析するのとでは、確認すべき規約や権利、技術上の注意点が異なります。ここは深追いせず結論だけ置くと、危ない取り方を避けて、条件を確認できる道を選ぶのが最初の分かれ道です。危険性・違法性のくわしい話はスクレイピングは危険？違法？AIで自作する前に知っておく注意点にまとめてあるので、自作の前に一度目を通しておくことをおすすめします。

ムチオ

情報を集めるのに、道が何種類もあるってどういうこと？

ルミナ

同じ数字を手に入れるのでも、相手が用意した窓口から条件つきで受け取るか、表のページを機械で読みにいくかで、守るべきルールがまるで違うんです。まずは正式な窓口があるか探すところから始めましょう。

取りにいく前の確認フロー(この順番で見る)

自動でデータを集めたくなったら、コードを書き始める前に、次の順番で確認します。上から順に、確認しやすく安全な選択肢が残っているかを見ていくイメージです。

提供元とデータの権利を確認する。そのデータは誰が持っていて、そもそも外部の人が機械で取得・再利用してよいものか。個人情報や、有料で売られているデータではないか。ここが土台です。
利用規約・ライセンス・料金・制限を確認する。相手のサイトに「API」「開発者向け」「デベロッパー」といったページがあれば、それが正式な受け渡し口です。その規約に、商用で使ってよいか、データを保存・再配布してよいか、1分間に何回までか、帰属表示(出典の明記)が要るか、といった条件が書かれています。この記事の本題はここです。
APIが無い場合は、規約・許諾・法的論点を個別に確認する。表向きのページから取りにいくしかないときは、そのサイトの利用規約で自動取得が禁止されていないか、必要なら相手に許諾を取れないか、著作権や個人情報の扱いはどうかを、その都度きちんと確認します。判断に迷うなら、無理に進めないのが安全です。

補足として、サイトには robots.txt という、クローラ(自動で巡回するプログラム)に対して「ここは見に来ないでほしい」という意向を伝えるための貼り紙のようなファイルがあります。ただしこれはあくまで意向表明の一つで、取得や二次利用の許可を与えるものではありません。仕様上も「アクセスを許可する仕組みではない」と明記されています(RFC 9309)。つまり「robots.txtで禁止されていない＝取ってよい・使ってよい」とは読めません。判断の中心になるのは、提供元・対象データの権利関係と利用規約です。APIがない場合は、それに加えて取得方法や利用方法についても個別に確認する必要があります。

大事なのは、上に進めるほど条件が明文化されていて確認しやすい、ということです。正式なAPIが見つかれば、何を守ればよいかが規約に書いてあるので、判断がぐっと楽になります。だからこそ、まずAPIを探す。この記事では、その最も確認しやすい道である公開APIの使い方に絞って進めます。

ムチオ

robots.txtって、あれば取っていいっていう許可証じゃないんだ…？

ルミナ

はい、そこは勘違いしやすいところです。robots.txtは「見に来ないでほしい」という相手の意向を書いた貼り紙で、取っていい・使っていいの許可を出すものではないんです。取ってよいかは、あくまでデータの権利と利用規約で判断します。

なぜまず公式APIを探すのか

この記事で扱う「公式API」は、サービスやデータの提供元が、外部の利用者のために正式に公開しているデータ取得用の窓口です。世の中には、提供元が公式に案内していない非公式なAPIや、サービス内部だけで使われているAPIもありますが、ここでは扱いません。公式APIなら、表向きのページを機械で解析するのではなく、データそのものを、相手が想定した作法で・明文化された条件のもとで受け取れます。

公式APIを先に探す理由は3つです。

利用条件が明文化されていて、何をしてよいか・いけないかを確認しやすい。
JSONなど、機械で扱いやすい形でデータをもらえる。
「1分間に何回まで」といった使い方のルールが決まっていて、相手のサーバーに過度な負担をかけにくい。

ただし、APIだから無条件に自由、というわけではありません。APIを使う場合でも、次のような点は自分で確認・対応する必要があります。

利用規約(何のために使ってよいか)と、商用利用が認められているか
取得したデータを保存してよいか、再配布してよいか、保存できる期間に制限はあるか
レート制限(呼び出せる回数の上限)
帰属表示(出典・提供元の明記)が求められていないか
個人情報が含まれる場合の取り扱い
APIキーの管理(鍵が要るAPIの場合)
将来、有料化されたり提供が終了したりしたときにどうするか

APIは「相手が用意した、確認しやすい窓口」であって、「何をしても許される道」ではありません。ここを押さえておくと、後で条件を見落として困ることが減ります。APIそのものの仕組みをもう少し知りたい方はAPIとはを、実際にデータを受け取るときによく出てくる形式についてはREST APIとはをあわせて読むと、このあとのサンプルが読みやすくなります。

最小サンプル：公開APIで取得してスプレッドシートに保存する

ここでは、無料で始められて自分のパソコンに何も入れなくてよいGAS(Google Apps Script)で、公開APIからデータを取得し、スプレッドシートに1行ずつ記録する最小の形を見てみます。GASはGoogleのサーバー上で動く小さなプログラムで、スプレッドシートと相性がよいのが利点です。

やることは3ステップです。

記録用のGoogleスプレッドシートを新しく作る。
上のメニューから拡張機能 → Apps Script を開く。
表示されたエディタに次のコードを貼り付けて保存し、実行する。

ここで使うのは、為替情報を提供している第三者のAPI(ExchangeRate-API の無料エンドポイント)です。あなたが毎日見に行っているサイト自身の公式窓口ではなく、あくまで「公開されている為替APIの一例」として使います。このAPIはキー不要で使える代わりに、利用条件として提供元(exchangerate-api.com)への帰属表示が求められ、取得したデータの再配布は認められていません(規約上、取得したデータを自分の用途のために保存・再利用することは認められていますが、そのまま他者へ配ることはできません)。こうした条件は変更される可能性があるため、実際に使うときは、記録するページに出典を添えるとともに、必ず最新の公式ドキュメント・利用規約を確認してください。ここは、この記事の冒頭で挙げた「商用利用は? 保存は? 再配布は? 帰属表示は?」という確認を、実際のAPIで一度なぞる練習にもなります。

なお、下のサンプルは「APIが正常に応答し、期待どおりのデータが返ってくる」ことを前提にした最小のデモです。実運用ではこれだけでは足りない部分があるので、コードのあとに補足します。

function saveRate() {
  // 為替情報を提供する第三者APIの窓口(ExchangeRate-API の無料エンドポイント)
  // ※対象サイト自身の公式APIではなく、公開されている為替APIの一例
  const url = "https://open.er-api.com/v6/latest/USD";

  // 404や500などのHTTPエラーが返っても、すぐ例外で止めず応答を受け取る
  const response = UrlFetchApp.fetch(url, { muteHttpExceptions: true });

  // まずHTTPステータスを確認する(200なら正常に返っている)
  const status = response.getResponseCode();
  if (status !== 200) {
    throw new Error("APIの応答が正常ではありません。ステータス: " + status);
  }

  const data = JSON.parse(response.getContentText());

  // 中身のエラー確認と、必要な項目があるかの確認
  if (data.result !== "success" || !data.rates || data.rates.JPY == null) {
    throw new Error("必要なデータが取得できませんでした。");
  }

  // 受け取ったデータから、必要な数字だけ取り出す
  const jpy = data.rates.JPY;

  // 記録先のシートを名前で明示して、一番下に1行追記する
  // (getActiveSheet は「いま画面で開いているシート」を指すため、
  //  後述の毎朝の自動実行=人が開いていない状況では対象がぶれる。名前指定が堅い)
  const sheet = SpreadsheetApp
    .getActiveSpreadsheet()
    .getSheetByName("シート1");
  sheet.appendRow([new Date(), "USD/JPY", jpy]);
}

このコードがやっているのは、次のことです。まず UrlFetchApp.fetch でAPIの窓口にアクセスします。このとき muteHttpExceptions: true を指定して、404や500などのHTTPエラーが返ってきた場合でも、すぐには例外で止めず、まず応答を受け取れるようにします。そのうえで、返ってきた応答の「HTTPステータス」を自分で確認します。200(正常)でなければ、そこで処理を止めます。次に、返ってきた中身が期待どおりか(成功を表す値が入っているか、必要な数字が入っているか)を確認します。ここまで通れば安心なので、必要な数字(円レート)だけを取り出し、appendRow でスプレッドシートの最終行に「日時・種類・値」を1行足す、という流れです。取得のたびに表が縦に伸びていき、時間ごとの記録がたまっていきます。

ムチオ

サイトを開いて数字を書き写してたのが、これだと1回ボタンを押すだけになるんだね。

ルミナ

そうなんです。しかも相手が用意した窓口を通っていて、条件も確認できます。ここまでできたら、あとは「毎朝自動で動かす」設定を足すだけです。

この最小サンプルで足りないこと(実運用との差)

上のコードは、取得の成功・失敗を1つ確認するところまで入れましたが、それでも「正常に動く前提のデモ」に近い状態です。実際に毎日ためていくデータ収集にするなら、最低限これくらいは考えることになります。今回すべてを実装する必要はありませんが、限界を知っておくと安心です。

HTTPステータスの確認：応答が200(正常)かを見る。今回は入れました。
返ってきた中身のエラー確認：ステータスは正常でも、中身がエラーや空のことがある。今回は簡単に入れました。
必要な項目が無い場合の処理：期待した数字が入っていないときに、どう扱うか(記録しない、目印を残す等)。
タイムアウト・一時障害への再試行：相手が一時的に応答しないことがある。少し待って数回だけやり直す、といった備え。
重複記録の防止：同じ時刻のデータを二重に書き込まないよう、すでに記録済みかを確認する。

今回のサンプルは、あくまで「まず動かして感触をつかむ」ための最小の形です。日々の業務で頼りにするなら、上のような不足を少しずつ埋めていく、という順番で育てていくのが現実的です。

毎朝など、定期的に自動で動かす

手で実行するだけでも十分ですが、決まった時刻に自動で走らせることもできます。GASのエディタ左側にある時計のアイコン(トリガー)を開き、新しいトリガーを追加します。実行する関数に saveRate を選び、時間主導型で「日付ベースのタイマー」を「午前8時〜9時」のように指定すれば、毎朝その時間帯に自動で1行ずつ記録がたまっていきます。なお、これは「8:00ちょうど」に動くという意味ではなく、指定した時間帯の中のどこかでGoogleが実行します。

これで、毎朝サイトを開いて書き写す作業が、放っておいても表に積み上がる形に変わります。まずは1つのデータで動かしてみて、慣れてきたら取得する項目を増やしていくのがおすすめです。

つまずきポイント：APIキーと取得しすぎ

ここで2つ、先回りで注意しておきたい点があります。

1つめは、APIキーの扱いです。今回の例はキー不要のAPIでしたが、多くのAPIは「あなた専用の鍵(APIキー)」を発行して使わせる形をとっています。この鍵を人目に触れる場所に置くと、他人に使われて思わぬ請求につながることがあります。鍵をどこに置くべきかはAPIキーをクライアント側に書いてはいけない理由にまとめてあるので、キーが要るAPIを使う前に読んでおくと安心です。

2つめは、取得のしすぎです。自動で動くと、つい細かく何度も取りにいきたくなりますが、APIには使える回数の上限があることが多く、上限を超えると一時的に使えなくなったり規約に触れたりします。まずは「1日に数回」「必要な項目だけ」から始めて、本当に必要になってから頻度を上げる、という順番が安全です。

次の一歩

まずは、あなたが毎日見に行っているサイトに公式APIがないか、あるなら利用規約でどんな条件がついているかを確認するところから始めてみてください。窓口ごとに作法(認証のしかた、送るヘッダー、取得できる件数の区切り、日付の書き方、回数の上限、返ってくるデータの形)が違うので、今回のサンプルのURLや項目を差し替えるだけでは動かないことも多い、という前提でいると、つまずきにくくなります。

危険性・違法性をきちんと理解してから作りたい人はスクレイピングは危険？違法？AIで自作する前に知っておく注意点。
APIそのものの仕組みからつかみたい人はAPIとは、返ってくるデータの形を知りたい人はREST APIとは。
キーが要るAPIを使う前にはAPIキーをクライアント側に書いてはいけない理由。

まとめ

情報収集を自動化したくなったら、いきなりサイトを機械で読みにいかず、まず公式APIがあるかを探す。
確認の順番は「①提供元とデータの権利 → ②利用規約・ライセンス・料金・制限 → ③(APIが無ければ)規約・許諾・法的論点を個別に」の順。robots.txtは意向表明の一つで、取ってよい・使ってよいの許可ではない。
公式APIは条件を確認しやすい窓口だが、無条件に自由ではない。商用可否・保存や再配布・レート制限・帰属表示・個人情報・キー管理などは自分で確認する。
GASを使えば、パソコンに何も入れずに公開APIからデータを取得し、スプレッドシートへ1行ずつ記録できる。ただし今回のサンプルは最小のデモで、実運用にはエラー確認や再試行、重複防止などが要る。
窓口ごとに作法が違うため、URLや項目を差し替えるだけでは動かないことも多い。

毎日サイトを見に行く手作業を減らしたい ── まず正式な窓口(API)を探してデータ収集を自作する