boy in green shirt
Photo by CDC on Pexels.com

【授業レポート】システム開発(3年) 第44週目

〜API連携をユースケースに組み込む:外部データを“役立つ機能”へ〜

第44週目は、先週実装したAPI呼び出しを、自分たちのアプリの具体的なユースケースに組み込みました。
「呼べた」状態から一歩進み、ユーザーにとって意味のある機能として成立させることがテーマです。


■ 先生の導入:「APIは“素材”。料理して初めて価値になる」

田中先生:「APIから取れるデータは、そのままでは使いづらいことが多い。
今日は“いつ・どこで・どう使うか”を設計し、ユーザー体験に落とし込みます。」

先生は、API連携でよくある失敗として

  • データを表示するだけで終わる
  • 毎回APIを呼んで遅くなる
  • エラー時に画面が壊れる
    といった例を挙げ、設計の重要性を再確認しました。

■ 今日のゴール

  1. APIデータを既存ユースケースに自然に組み込む
  2. Service層で「加工・判断・キャッシュ」を行う
  3. API失敗時でもユースケースが成立するようにする
  4. ユーザーに分かりやすい表示・メッセージを設計する

■ 実習①:APIを使うユースケースを明確にする

まず各班で「どのユースケースでAPIを使うか」を明確化。

  • 図書館システム
    • 本を検索 → 天気API を使って「雨の日は返却期限の注意表示」
  • 学校イベント管理
    • イベント一覧 → 地図API で場所を表示
  • 学習支援アプリ
    • 英文入力 → 翻訳API で日本語補助表示

生徒A:「APIを“主役”にしない方が、アプリとして自然になる」


■ 実習②:Service層でAPIデータを“加工”する

APIレスポンスをそのままUIに渡さず、
Service層で必要な形に整形しました。

例:天気APIを使ったService(概念)

def get_weather_hint(self, city):
    weather = self.weather_api.fetch(city)

    if weather["condition"] == "Rain":
        return "今日は雨の予報です。返却期限にご注意ください。"
    else:
        return None

ポイント:

  • UIは「表示するかどうか」だけ判断
  • APIの仕様変更がUIに影響しない
  • ユースケースの文脈でデータを解釈する

生徒B:「APIの生データを“意味のあるメッセージ”に変えてる感じがする」


■ 実習③:キャッシュと呼び出し回数の工夫

APIは

  • 遅い
  • 回数制限がある
    という前提があるため、簡単なキャッシュを導入しました。

学習用イメージ

  • 同じ都市の天気は10分間再利用
  • Service層でキャッシュを管理
  • API呼び出し回数をログで確認

生徒C:「キャッシュを入れたら体感で速くなった!」

先生からは
「キャッシュは“正確さ”と“速さ”のトレードオフ」
という実務的な話もありました。


■ 実習④:API失敗時でもユースケースを止めない

次に、APIが使えない場合の挙動を設計。

実装方針

  • APIが失敗しても主要機能は継続
  • 補助情報(天気・翻訳など)だけ非表示
  • ユーザーには簡潔な案内を出す
try:
    hint = weather_service.get_weather_hint(city)
except Exception:
    hint = None

UI側表示例:

  • 「※現在、天気情報は取得できません」

生徒D:「“なくても困らない機能”としてAPIを使うのが安全なんだ」


■ 実習⑤:UIへの組み込みと表示調整

最後に、API由来の情報をUIに自然に組み込みました。

  • 目立ちすぎない補助表示
  • 色や位置で“重要度”を調整
  • エラー表示は控えめに

生徒E:「APIを使ってるけど、ユーザーは意識しなくていいのが理想だね」


■ 全体共有:うまくいった工夫

クラスで共有された工夫例:

  • API結果を文章化してUX向上
  • キャッシュ+フォールバックで安定動作
  • Service層にAPI判断を集中
  • ログでAPI失敗率を把握

■ 先生のまとめのひとこと

「API連携の目的は、
“APIを使うこと”ではなく
ユーザーの体験を良くすることです。

今日のように、

  • どこで使うか
  • 使えなかったらどうするか
    を考えられる設計は、実務そのものです。」

■ 宿題(次週に向けて)

  1. APIを組み込んだ**ユースケース説明書(1ページ)**を作成
  2. API成功時/失敗時の画面キャプチャを用意
  3. APIをもう1つ追加するとしたら、どこに入れるか案を考える

■ 来週の予告:複数API連携と非同期の考え方

次週は、
複数のAPIを同時に使う場合の設計と、
待ち時間・失敗をどう扱うかという
非同期処理の考え方を学びます。


第44週目は、
API連携が「技術デモ」から「実用機能」へ進化した週でした。
生徒たちは、外部サービスを“賢く、安全に使う設計”を着実に身につけています。

投稿者 greeden

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)