第13回（Bコース） APIによる情報収集（気象庁API）

Webサービス(WS)は、「Web2.0」と呼ばれる近年のWebの核心技術である。それ以前のWeb(1.0?)が、人間のユーザにブラウザ経由でWebページの情報を提供するだけだったのに対し、アプリからのリクエスト（要求）に応じてさまざまな情報を提供する^※1。

1　これと似た技術として、人間向けのWebページからアプリが情報を自動的に取得する「スクレイピング」がある。目的も手段も似通っているが、別モノだから混同しないように。

人間ではないアプリが相手だから、Webサービスを利用するには一定の形式（フォーマット）と通信手順（プロトコル）に従わなければならない。これらを併せてAPI(Application Program Interface)という。
APIを介してWebサービス（の情報）を利用するには、プログラミングのスキルが必須だ。複雑なアプリではないが、これからもWebやクラウドを活用しようとするためには、何か一つプログラム言語を習得しておこう。この「プログラミング入門」の目的もそこにある。
WebサービスとそのAPIは多様であり、利用の難易度にも差があるが、今回は一番簡単な「気象庁API」を利用して、Colabノートブックから天気予報を取得・表示する。

「気象庁API」の利用

今回利用する「気象庁API（仮）」は、正式なサービスではなく、気象庁の中の人が試験提供しているに過ぎない。ドキュメントも存在しないので、外の人々が試行錯誤しながらネット上で情報交換している現状だ^※2。

2　後で述べる「注意」でも触れるが、正直、こうした相手次第でいつ変わるともしれないモノをテーマに授業を設計し、講義資料を作成するのはあまり気が進まない。だから今回（第13回）の授業は、もう1つのテーマ（Aコース：正規表現）といつでも差し替え可能になっている。

気象庁が提供する特定地方の気象予報データを取得し、整形表示したのがリスト13b-1である。このAPIは、WSのAPIとしてもっとも単純な形式で、明示的なリクエストを必要としない。エリアコードをURIの一部（JSONファイル名）に含めるだけで、JSON形式^※3のテキストデータを返す。WS側が、あたかも各エリアコード毎にJSONファイルを事前に（静的に）作成しているかに見えるが、おそらくはURIへのアクセスという暗黙のリクエストに応じて動的に生成しているのだろう。ただし、それを外部から確かめる手段はない。

3　JavaScript Object Notation。Javascript言語に由来するデータ交換フォーマット。軽量で、人間も読みやすく、プログラムにとってもパース（解析）や生成が容易な形式である。

リスト13b-1: 気象庁APIからの取得データを整形表示する(weather.ipynb)

APIが返すJSONテキストは、以下の形式をしている（全文へのリンク）。「これのどこが『人間も読みやすい』のさっ？」という声が聞こえそうだが、慣れれば簡単に読み解ける。それに、すべてのデータを利用することはほぼなく、必要な部分を取捨選択すればよいのだ。残念ながら、この辺のコード生成はまだ生成AI(Gemini)に任せられない（GeminiはAPIの仕様や、「どのデータが必要か」を知らないからである）。


[{"publishingOffice":"気象庁","reportDatetime":"2025-03-28T05:00:00+09:00","timeSeries":[{"timeDefines":["2025-03-28T05:00:00+09:00","2025-03-29T00:00:00+09:00"],"areas":[{"area":{"name":"東京地方","code":"130010"},"weatherCodes":["313","302"],"weathers":["雨　昼前　から　くもり　所により　朝　雷を伴い　激しく　降る","雨　時々　くもり"],"winds":["南の風　はじめ　やや強く　２３区西部　では　はじめ　南の風　強く","北の風　後　北東の風　２３区西部　では　はじめ　北の風　やや強く"],"waves":["１．５メートル　後　１メートル","１メートル　後　０．５メートル"]},{"area":{"name":"伊豆諸島北部",
                ：
                ：
{"area":{"name":"八丈島","code":"44263"},"min":"28.1","max":"59.7"},{"area":{"name":"父島","code":"44301"},"min":"4.7","max":"23.9"}]}}]

JSONデータ中で

:はキーと値の対を表す
{　}は集合を表す。キーと値の対の集合とは、つまりディクショナリである
[　]はリストを示す

というように、各要素データはPythonの基本データ構造と同じ構造で組織されている。だから「request.get(jma_url).json()」は、データ全体をリストとディクショナリからなる構造体に格納し、変数jma_jsonに代入する。
後はJSONテキストを読み解きながら、必要なデータにアクセスするだけだ。2つめのコードセルでは、jma_jsonからつぎのデータを取り出し、それぞれを変数に代入している。

date：日付と時刻
area：地方名
weather：天候
wind：風の予報
waves：波の予報

最後のコードセルで、得られたデータに適当な書式を与えて表示する。ここに挙げた「気象庁API」は、URI中にリクエストを追記するもっとも簡単な方法だが、リクエストをJSON形式やXML形式のテキストデータとしてサーバに送信しなければならないWebサービス(API)もある。

APIを利用する際の注意

さまざまなAPIを利用して情報を取得できれば、プログラミングの活用範囲と効用は一挙に広がる。だが注意点もいくつかあるので、列挙する。前半（1～3）はWebサービスの特徴や利用のコツ。後半（4～6）は「生成AI(Gemini)を使ったプログラム」にも通じる、メディアリテラシー上の注意点である。

自分の利用目的（どんなデータが欲しいか）をはっきりさせ、それに関係するWSとAPIのみ利用する。API全体の仕様はかなりボリューミーなことが多いから、全貌を理解しようとするのは労力の無駄である
今回扱ったJSONも、同様に多く利用されるXMLやyamlも、アプリで取得した後はリストや辞書の複合体になる。元のテキストデータを読み解けないと、データ全体から必要な部分を取り出せない
テストのために、繰り返しAPIを叩くのに、Colabフォーム^※4が大変便利である。たとえばリスト13b-1の変数「エリアコード」など
4　Colabフォームについては、「第13回（Aコース）正規表現」に使用例がある。
APIの利用も、スクレイピングも、「相手先がいる話」であることを意識する。つまりAPIの仕様はいつ変更されないとも限らない。そのときはアプリも修正しなくてはならないが、無料でデータを利用している立場では文句も言えない。最悪のケースは、相手の都合でAPIが廃止されることで、書いたプログラムが無駄になるか、同様のデータを提供している別のAPIを探すことになる
生成AIと同様、「外のどこかからもってきた情報」を利用しているのだという意識をもつべきである。当然、そこには嘘や誇張が含まれているかもしれないし、著作権のある情報かもしれない
有料のWebサービスもある。たとえばChatGPTなど、生成AIの多くは有料だ（むしろColab付きのGemini君が例外的存在）^※5。それらの利用に際しては、「どのくらい利用すればいくら課金されるか」を把握していないと、思わぬ高額請求に慌てる羽目になる
5　それらを利用する場合はサービス提供先にクレジットカード情報などを提供した上で「APIキー」とか、それに類したIDを発行してもらい、利用の都度リクエストにその情報を含めるのが一般的である。利用料が「○○万トークンあたり××ドル」といった見慣れない単位で掲げられていることも多いので、ときどきそれまでの利用量（と利用料）をチェックする習慣をつけよう