「JavaScriptで何ができるの？」シリーズ第4弾は「通信」です。「通信」って言われても具体的なところがさっぱりわからないので、さっそくAI先生に教えてもらいます😅
ちなみにProgateのJavaScript進捗具合ですが、JavaScript Ⅵ（配列メソッド編）まで行きました。相変わらず例題をなぞって、「ふ〜ん、こういうのものがあるんだね」レベルですが、少しづつでも進んで行ければなと思っています🐢🐢🐢
これまでの振り返り
- 【済】インタラクション：メニュー開閉、タブ切り替え、モーダル表示
- 【済】入力チェック：必須チェック、文字数・メール形式の検証
- 【済】動的表示：時計、カウントダウン、スライドショー
- 【済】データ操作：計算、条件分岐、繰り返し処理
- 【済】保存：ブラウザにメモ（
localStorage） - 通信：サーバーやAPIからデータ取得
- 描画：Canvasで図形・グラフ
前回は保存のところを教えてもらったけど、今度は“外の世界”とつながるのかな？
そうです。JavaScriptは“通信”もできるんですよ。つまり、サーバーやAPIからデータを取ってくることができるんです！
サーバーはなんとなくわかるんだけど、APIってなに？
APIはよく聞く単語だけど、自分もあんまり細かいことがわかってないなぁ。いい機会だから教えてよ。
APIは Application Programming Interface（アプリケーション・プログラミング・インターフェース） の略です。APIというのは、“アプリとアプリをつなぐための窓口”のようなものです。
たとえば、天気アプリが気象庁のデータを取ってくるとき、このAPIというルールに従って情報を受け取っています。つまり、外部のサービスとやり取りするための共通の言葉なんですよ。
窓口であり共通の言葉なんだー。登山で例えるとどういうものにあたるの？
登山で言うと、山小屋の受付みたいなものです。登山者（アプリ）が「天気情報を教えてください」とか「宿泊したいです」とお願いすると、山小屋（サーバー）が【決まった手順（＝APIのルール）】で情報やサービスを返してくれる。
つまり、勝手に山小屋の裏口から入るのではなく、ちゃんと受付を通してやり取りする仕組みがAPIなんです。
なるほど！ 山小屋の受付か〜。例えが山だとわかりやすいね👍
受付重要だもんね。山小屋になくてはならないものだし、APIが大切なものってことはわかったよ。
そうなんです。受付があることで、登山者も安心して利用できるし、山小屋側も安全に管理できます。APIも同じで、ルールを通じてやり取りするからこそ、安全で正確にデータを受け渡しできる仕組みになっているんですよ。では具体例を実際に見ていきましょう。
通信とは？（ブラウザとサーバーの関係）
まず“通信”とは、ブラウザ（あなたのPCやスマホ）がサーバーと情報をやり取りすることです。
ふむふむ、たとえばニュースサイトを開いたら、サーバーから最新記事を送ってくれてる感じ？
その通りです。JavaScriptでは、その“やり取り”をプログラムで実行できるようになります。
ニュースサイトとか身近ものからJavaScriptって使われているんだね。ひょっとしてほとんどのサイトで「通信」はしているの？
そうなんです。いま見ている多くのサイト——ニュース、天気、ショッピング、SNSなど——のほとんどがJavaScriptで通信しています。画面を更新せずに情報が変わるのも、その通信のおかげなんですよ。
fetch関数でデータを取ってみよう！
JavaScriptでの“通信”では、fetch()関数を使ってデータを取得していきます。
フェッチ？ なんか走る犬の遊びみたいな名前！
たしかに😅 でも実際は“情報を取りに行く”関数なんです。
情報を取りに行く関数って、けっこう関数の役割も細かく別れているんだね。
そうですね。JavaScriptでは、ひとつの大きな処理をいくつもの関数に分けて作るのが基本です。fetchは“情報を取りに行く専用の関数”で、役割を分けることでコードが読みやすく、トラブルにも強くなるんですよ。さっそく実例を見てみましょうか。
基本の書き方
fetch("https://api.example.com/data")
.then(response => response.json())
.then(data => {
console.log(data);
})
.catch(error => {
console.error("通信エラー:", error);
});
英語ばっかりであたまクラクラしてきたよ・・・
細かいところはともかく、これでAPIにアクセスして、結果をデータとして使えるわけだね。
そうなんです！ fetchは“データを取りに行く”部分を担当していて、そのあとにある.then()は“受け取ったデータをどう使うか”を決めるところです。英語っぽく見えても、流れをつかめば意外とシンプルなんですよ。
中身を分解すると、少しわかってきたような気がする。具体的にどんな感じなのか教えてよ。
具体例 天気予報APIで今日の天気を表示！
初心者でも簡単に試せるのが“天気API”です。無料で使えるAPIを呼び出して、結果を画面に出してみましょう
シンプルバージョン
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>現在の天気</title>
</head>
<body>
<h1>東京の現在の天気</h1>
<p>読み込み中です...</p>
<script>
fetch("https://api.open-meteo.com/v1/forecast?latitude=35.68&longitude=139.76¤t_weather=true")
.then(res => res.json())
.then(data => {
const weather = data.current_weather;
document.body.innerHTML = `
<h1>東京の現在の天気</h1>
<h2>現在の気温：${weather.temperature}℃</h2>
<p>風速：${weather.windspeed} m/s</p>
<p>観測時刻：${weather.time}</p>
`;
})
.catch(err => {
document.body.innerHTML = `<p style="color:red;">データの取得に失敗しました。</p>`;
console.error(err);
});
</script>
</body>
</html>
わー！ 本当に今の気温が出た！
これがサーバーからもってきた情報か〜。天気APIってなんで無料で使えるの？
とても良い質問です🌤️ 「APIを無料で使える」って、たしかに不思議ですよね。
実は、天気APIが無料で提供されているのには ちゃんとした理由 がいくつかあります👇
💡 理由①：データを広く使ってもらいたい（宣伝・普及目的）
多くのAPI提供元（例：Open-Meteo、WeatherAPI、OpenWeatherなど）は、
「まず無料で使ってもらって知ってもらう」ことを目的にしています。
- 無料版 → テスト・学習・小規模サイト用
- 有料版 → 商用アプリ・大量アクセス用
つまり、“試してもらってファンを増やす”ためのマーケティングなんです。
（いわば「お試しサンプル」のようなものですね）
💡 理由②：公共データを活用している
多くの天気APIは、日本だと気象庁（Japan Meteorological Agency）、海外だとNOAA（アメリカ海洋大気庁）などの公的機関のオープンデータを利用しています。
→ 公的データは無料で使えるので、
それを整理・加工してAPI化することで「無料でも提供しやすい」わけです。
💡 理由③：無料でもアクセス上限がある（制限付き）
天気APIは“完全無料”ではなく、だいたい次のような制限つき無料プランになっています👇
| 制限内容 | 例 |
|---|---|
| 1時間あたりのアクセス数 | 60回まで（1分に1回程度） |
| データの種類 | 現在の天気のみ（詳細な予報は有料） |
| 商用利用 | 禁止または要申請 |
| APIキー登録 | 利用者を管理するために必須 |
これによって、
・悪用を防ぎ
・サーバー負荷を抑え
・本気で使いたいユーザーを有料プランへ誘導
という仕組みになっています。
💡 理由④：開発者コミュニティや教育目的
APIを無料で公開することで、世界中の開発者や学生が学びやすくなります。「まず触ってもらうことで技術者人口を増やす」という目的もあるんです。
つまり、“無料API”は学習者の味方でもあるわけです。
たしかに！ 無料で天気データをもらえるってありがたいね☀️
✅ 無料の理由一覧
| ポイント | 内容 |
|---|---|
| 宣伝・普及目的 | 有料プランへの導線を作るため |
| 公開データ利用 | 公的な気象データを活用している |
| 利用制限あり | アクセス数・機能に上限 |
| 教育・学習向け | 開発者を増やす目的も |
ちなみに元データを提供している団体とAPI提供元は同じなの？
すごく良い視点です👏✨ 答えを先に言うと──
❌ ほとんどの場合、「元データ提供元」と「API提供元」は別です。
つまり、「気象庁のような公的機関がデータを出していて」→ 「民間や個人がそれを整形してAPI化している」という役割分担になっているんです。
☁️ たとえば天気APIの場合
| 役割 | 具体例 | していること |
|---|---|---|
| 元データ提供元（公的機関） | 日本：気象庁（JMA） アメリカ：NOAA（米国海洋大気庁） ヨーロッパ：ECMWFなど | 観測・解析データを公開（CSVやXMLなど） |
| API提供元（開発者・企業） | Open-Meteo, OpenWeather, WeatherAPI など | 公開データを取得・整理して、APIとして使いやすく提供 |
⚙️ それぞれの立場の目的
| 立場 | 目的 |
|---|---|
| 公的機関 | 気象情報を公益目的で公開（オープンデータ政策） |
| API提供者 | 公開データを使いやすく整備して、利用者を増やす |
| 開発者 | Webサービスや学習教材に活用する |
💡 具体例で見てみよう
◾ Open-Meteo（今回のブログでも使ってるやつ）
- 元データ：
ヨーロッパ中期予報センター（ECMWF）や米NOAAのオープンデータ - API提供元：
ドイツの個人開発者が運営するプロジェクト（非営利） - 仕組み：
公的データを毎日更新 → 加工してAPIとして配信 - 無料の理由：
データ自体がオープン（無料）だから
◾ OpenWeather（有名なAPI）
- 元データ：
世界各国の気象機関・衛星・民間観測網など - API提供元：
民間企業（OpenWeather Ltd） - 仕組み：
公的データ＋独自観測を統合し、商用利用もOKな形で提供 - 無料プランもあるけど、有料の商用契約がメイン
🧭 関係性を図で表すとこうなります
[ 気象庁・NOAA・ECMWFなど ] → （生データ公開）
↓
[ API提供元（Open-Meteoなど） ] → （整形してAPI化）
↓
[ 開発者・学習者（あなた） ] → （fetchでデータ取得）なるほど、「データを作る人」と「使いやすくする人」が分かれてるんだね！
API提供元って、いわば「翻訳してくれる人」みたいな感じだ！
まさにその通りです。APIは“難しい生データを、誰でも使える形にした窓口”なんですよ。
まとめ
今回はJavaScriptの「通信」について、いろいろ聞いてみました😀
APIを使った表現や提供側と利用者側の立場など、いろいろ勉強になることも多かったです。普通のプログラムを学ぶのに加えて、こういう脱線話をこれからも楽しんでいきたいものですね。
ではでは。
