【授業レポート】システム開発入門 第23週目：API連携アプリの発表と信頼性改善

システム開発入門の第23週目では、前週に学んだHTTPとJSONの基礎を土台に、外部APIを使ったミニプロジェクトを発表し、改善しました。

API連携とは、アプリが外部サービスへリクエストを送り、返ってきたデータや機能を自分の処理に組み込むことです。

天気や名言、翻訳を扱うアプリを実際に動かし、「取得できたとき」だけでなく、通信待ちや認証エラー、想定外の応答が起きたときの振る舞いまで見直しました。

外部サービスとつながるときの責任

田中先生は「外のサービスとつながると、アプリの価値はぐっと上がります。けれど、接続エラーや想定外のデータにも備える必要がある。今日は『動く』だけでなく『堅牢にする』ことを意識しましょう」と授業の狙いを示しました。

ここでいう堅牢性は、通信やデータに問題が起きても、アプリ全体が突然止まらず、利用者が次の行動を判断できる状態を保つことです。

API連携では自分のコードだけでなく、ネットワークや接続先の稼働状況、利用条件にも結果が左右されるため、失敗時の設計が必要になります。

3チームの発表と改善点

各チームは完成した機能だけでなく、使う人が迷いやすい場面と、その場面に対する工夫を説明しました。

天気ミニアプリの「読み込み中」は、非同期処理そのものの説明ではなく、通信を待っている状態を利用者に伝えるための表示です。

処理方式と画面上の案内を分けて考えると、何を改善したのかが明確になります。

API連携を安定させる4つの考え方

タイムアウトと例外処理

タイムアウトは、外部サービスから応答がない状態で待ち続けることを避けるための設定です。

例外処理は、通信失敗や不正な応答など、通常どおり処理できない事態が起きたときの動作をあらかじめ決めることです。

授業で扱ったPythonのrequestsを使う例は、次のように「通信」「HTTPの成否」「JSONの読み取り」「必要な値の有無」を順番に確認できます。

import os
import requests

API_URL = "https://api.example.com/weather"
API_KEY = os.getenv("API_KEY")  # 秘密情報は環境変数で管理

try:
    response = requests.get(
        API_URL,
        params={"q": "Tokyo", "appid": API_KEY},
        timeout=5,
    )
    response.raise_for_status()
    data = response.json()

    temperature = data.get("main", {}).get("temp")
    if temperature is None:
        print("温度情報を取得できませんでした。")
    else:
        print(f"温度情報：{temperature}")
except requests.exceptions.Timeout:
    print("通信がタイムアウトしました。時間を置いて再度お試しください。")
except ValueError:
    print("応答データを読み取れませんでした。")
except requests.exceptions.RequestException as error:
    print(f"通信エラーが発生しました：{error}")

この例では、timeoutで通信待ちを制限し、raise_for_status()でHTTPエラーを検出してからJSONを読み取ります。

取得先によってデータの構造や温度の単位は異なるため、値の表示方法は利用するAPIの仕様に合わせて決めます。

フォールバック

フォールバックは、本来使う機能やデータを利用できないときに、あらかじめ用意した代替手段へ切り替える設計です。

名言アプリでは、APIから取得できない場合にローカルの名言リストを表示しました。

代替データを見せるときは、最新の取得結果と誤解されないよう、切り替わったことを画面で伝える必要があります。

レート制限とキャッシュ

レート制限は、一定時間内に送信できるリクエスト数について、API提供側が設ける制約です。

キャッシュは、一度取得した結果を一時的に保存し、同じ問い合わせに再利用する仕組みです。

授業では、同じ問い合わせを短時間に繰り返さないよう、メモリ上の辞書を使って結果を一定時間保持する方法を取り入れたチームがありました。

キャッシュを使う場合は、保存期間を決め、古い情報をいつ取得し直すかも設計に含めます。

APIキーと応答データの確認

APIキーはソースコードに直接書かず、サンプルのように環境変数から読み込む形にしました。

応答がJSONであっても、必要なキーが必ず含まれるとは限らないため、data.get("main", {}).get("temp")のように値の欠落を確認してから表示します。

利用者に伝わるエラー表示

技術的な失敗を処理できても、画面に「エラー」とだけ出すと、利用者は待つべきか、入力を直すべきかを判断できません。

授業では、次の3点を意識して表示文を改善しました。

• 何を取得できなかったのかを、利用者が分かる言葉で示す
• 再試行、入力の修正、時間を置くなど、次に取れる行動を示す
• JSON全体ではなく、判断に必要な情報だけを画面に出す

たとえば「エラーが出ました」ではなく、「天気情報を取得できませんでした。都市名を確認するか、時間を置いて再度お試しください」と書けば、原因の候補と次の行動を同時に伝えられます。

待ち時間には「読み込み中」と表示し、処理が続いていることを明確にします。

発表後に確認したチェック項目

改善後のアプリは、成功例だけでなく、条件を変えたときの振る舞いも確認しました。

• 正しい入力で必要な情報を表示できるか
• 通信中であることが画面から分かるか
• 存在しない都市名や長すぎる入力を扱えるか
• タイムアウトや認証エラー時に処理が止まらないか
• 応答に必要なデータがない場合に案内できるか
• フォールバックへ切り替わったことが利用者に伝わるか
• 同じ問い合わせを必要以上に繰り返していないか

田中先生は、今回の学びを「堅牢性としての例外処理」「案内やフォールバックによる使いやすさ」「APIキーやレート制限など利用ルールへの配慮」の3点に整理しました。

次回に向けた準備

授業では次回に向けて、生成AIの基礎概念、利用時の倫理、一般的なREST APIとモデルを呼び出すAPIの違いを整理し、簡単なプロンプト設計を練習する予定が共有されました。

第23週目で学んだのは、API連携の完成条件が「一度動いたこと」だけではなく、通信待ち、失敗、制約、想定外のデータを扱い、利用者へ状況を伝えられることまで含むという点です。