【授業レポート】システム開発（3年） 第48週目
〜生成AIの評価と改善サイクル：ログから“賢さ”を育てる〜
第48週目は、前回実装した生成AI機能を対象に、
出力を評価し、改善サイクルを回す実践演習を行いました。
テーマは、
「AIは完成しない。調整し続けるもの」
生成AIを“組み込む”段階から、“育てる”段階へ進む重要な回となりました。
■ 先生の導入：「AIは精度100%にはならない」
田中先生：「生成AIは確率的な仕組みです。
だから“完璧”を目指すのではなく、“改善し続ける仕組み”を作ることが重要です。」
先生は黒板に次のサイクルを書きました。
ログ収集
↓
評価
↓
問題特定
↓
プロンプト・検証改善
↓
再評価
■ 今日のゴール
- 生成AIの出力をログで記録する
- 良い出力／悪い出力を分類する
- 問題の原因を分析する
- プロンプトや検証ロジックを改善する
■ 実習①：AI出力ログの記録強化
まずはログ設計の見直し。
追加したログ項目
- 入力テキスト（必要部分のみ）
- 使用プロンプト
- AI出力全文
- 出力文字数
- 検証エラーの有無
- フォールバック発動の有無
生徒A：「ログがないと、何が悪いのか分からない」
先生は
「AI改善の材料は“ログ”しかない」
と強調しました。
■ 実習②：出力を評価する
次に、実際に複数回AIを動かし、
出力を分類しました。
評価観点
- 指示どおりの長さか
- 事実追加していないか
- 意味が通る文章か
- 禁止ワードが含まれていないか
- ユーザーに誤解を与えないか
班ごとに
- 良い出力例
- 問題のある出力例
を整理。
生徒B：「同じ入力でも毎回微妙に違う！」
■ 実習③：問題の原因分析
出力が悪かったケースを分析。
代表的な原因
- プロンプトが曖昧
- 制約が弱い
- 出力形式を指定していない
- 検証ロジックが甘い
例：
×「短く要約してください」
○「100字以内で、事実のみを1文で要約してください」
生徒C：「プロンプトが“設計書”って本当だ…」
■ 実習④：プロンプト改善と再テスト
実際にプロンプトを改善し、再度テスト。
改善例
- 役割指定を明確化
- 禁止事項を箇条書き化
- 出力形式をJSON指定に変更
例（概念）：
出力は次のJSON形式で返してください：
{
"summary": "ここに要約"
}
改善後は、
- 長さのブレが減少
- 余計な説明が減少
- 検証しやすくなった
生徒D：「形式指定すると安定する！」
■ 実習⑤：検証ロジックの強化
プロンプトだけに頼らず、
コード側でも検証強化。
追加例：
- JSONパース確認
- 正規表現チェック
- 文字数再検査
- 禁止ワード辞書拡張
先生：「AI任せにしない。最後の責任はコード。」
■ クラス全体の気づき
- AIは“改善対象”
- ログなしでは改善できない
- プロンプトと検証は両輪
- 評価基準を明確にすると改善しやすい
■ 先生のまとめのひとこと
「生成AI開発は、
“実装して終わり”ではありません。
ログを見て、
原因を考え、
改善し、
また検証する。
これは従来のソフトウェア開発と同じです。
違うのは、“出力が確率的”という点だけ。
今日学んだ改善サイクルは、
AI時代のエンジニアに必須のスキルです。」
■ 宿題（次週に向けて）
- AIログの改善レポートを提出
- 問題例2つ
- 原因
- 改善策
- 改善前／改善後の出力比較をまとめる
- 次に改善したい点を1つ挙げる
■ 来週の予告：安全性・倫理・責任設計
次週は、
生成AI利用における
安全性・倫理・情報管理・責任の所在
について扱います。
技術だけでなく、
“使う責任”を学ぶ回になります。
第48週目は、
生成AIを「使う」から「育てる」段階へ進んだ重要な授業でした。
生徒たちは、
AIを魔法の箱ではなく、
改善対象のシステム部品として扱う姿勢を確実に身につけています。