【授業レポート】システム開発（3年） 第47週目
〜生成AI実装ハンズオン：安全に呼び出し、安全に表示する〜
第47週目は、前回学んだ設計をもとに、生成AI APIを実際に呼び出すハンズオン実装を行いました。
テーマは明確です。
「呼び出せる」ではなく、「安全に使える」状態まで作る。
便利さだけで終わらせない、制御されたAI連携の第一歩となりました。
■ 先生の導入：「AIは出力して終わり、ではない」
田中先生：「今日のゴールは“AIが返す文章をそのまま出すこと”ではありません。
“検証し、整形し、責任を持てる形にすること”です。」
先生は、次の3段階を黒板に書きました。
- 入力を整える（プロンプト設計）
- 出力を検証する（フォーマット・内容チェック）
- 表示を制御する（UI配慮・フォールバック）
■ 今日のゴール
- 生成AI API をコードから呼び出す
- プロンプトを Service 層で組み立てる
- 出力形式を制限する
- 想定外出力に対するフォールバックを実装する
■ 実習①：安全なプロンプト設計
まずは、AIに渡す前の入力制御から。
実施した工夫
- ユーザー入力の長さ制限
- 危険ワードの簡易チェック
- 出力形式の明示
- 「事実の追加禁止」などの制約文追加
例（概念）
あなたは図書館システムの補助AIです。
以下の文章を100字以内で要約してください。
事実を追加しないでください。
出力は1文のみ。
生徒A：「指示を具体的にすると、ブレが減る！」
■ 実習②：AI呼び出しをService層に実装
前回設計した構造に沿って、
AI Clientクラスを作成し、Service層から呼び出しました。
UI
↓
SummaryService
↓
AiClient
↓
生成AI API
学習用イメージ（簡略）
def summarize(self, text):
prompt = self.build_prompt(text)
result = self.ai_client.generate(prompt)
return self.validate_output(result)
ポイント：
- UIはAIの存在を直接知らない
- AI呼び出しは必ずService経由
- 出力検証はServiceで行う
生徒B：「AIも“外部APIの一種”として扱える」
■ 実習③：出力検証（Validation）を入れる
ここが今日の最重要ポイント。
チェックした項目
- 文字数制限を超えていないか
- 空文字でないか
- 禁止ワードが含まれていないか
- 形式が1文になっているか
if len(result) > 120:
raise ValueError("出力が長すぎます")
検証に失敗した場合は：
- 固定文に置き換える
- 「現在要約を生成できません」と表示
- ログへ詳細記録
生徒C：「AIの出力を“信じない設計”が大事なんだ」
■ 実習④：フォールバック設計
AIが失敗した場合の代替動作を実装。
例
- 固定テンプレートを返す
- 元の文章の冒頭をそのまま表示
- AI機能を無効化して通常モードへ戻す
try:
summary = service.summarize(text)
except Exception:
summary = "現在要約を生成できません。"
生徒D：「“なくても困らない設計”にする安心感」
■ 実習⑤：UIへの表示配慮
最後に、AI生成であることを明示する表示を追加。
例：
- 「※AIによる自動生成」
- 小さく補助的に表示
- 誤りの可能性を明記
先生：「透明性は信頼につながります。」
■ クラス全体の気づき
- 生成AIは“便利な補助機能”として使う
- Service層の責任が非常に重い
- 出力をそのまま出さないことが最重要
- ログ設計がより重要になる
■ 先生のまとめのひとこと
「生成AI連携は、
“技術力”より“設計力”が問われます。
AIを使うことは簡単です。
でも、
安全に使い続けられる設計を作ることが本当の力です。」
■ 宿題（次週に向けて）
- 今日実装したAIユースケースの 安全設計図（入力→AI→検証→表示） を作成
- 出力検証ルールを3つ追加する
- AIが誤った内容を返した場合のユーザー通知文を考える
■ 来週の予告：生成AIの評価と改善サイクル
次週は、
生成AIの出力をログで評価し、
**改善サイクル（プロンプト調整・検証強化）**を回す回です。
第47週目は、
生成AIを“制御された形で組み込む”実践的な一歩となりました。
生徒たちは、AIに振り回されるのではなく、
AIを設計の中に収める力を確実に身につけ始めています。