【授業レポート】システム開発入門 第26週目 〜生成AIをアプリに組み込む設計（上級編）〜
第26週目は、先週までのプロンプト作成とハンズオンの学びを踏まえ、生成AIを自分のアプリに安全に組み込む設計を深掘りしました。ユーザー体験を損なわずに信頼性と安全性を確保するための実務的な設計パターンと実装の考え方が中心の授業です。
■ 先生の導入：「AIは機能の一部。設計で安全に組み込もう」
田中先生：「生成AIは強力ですが、単独で『正しい』とは限りません。設計段階で『入力の検査』『出力の検証』『失敗時の振る舞い』を決めておくことが重要です。」
■ 今日の学びの柱（要点）
- 入力フィルタリング（前処理）：個人情報や不適切な語を除く。意図せぬ情報漏洩を防ぐ。
- 出力検証（後処理／ファクトチェック）：生成文の妥当性・禁止語チェック・形式チェックを自動化。
- フォールバック設計：AI応答が使えないときはローカルロジックやテンプレート応答へ切替。
- ユーザーへの透明性：AIを使っている旨、信頼度や注意書きを明示する。
- 運用面（監査ログ・レート制限・キャッシュ）：APIコスト管理・再現性の担保・不正利用検出。
- 倫理と法的配慮：著作権・プライバシー・偏見への配慮を仕様に落とす。
■ 実習①：入力のサニタイズと許可ルール
まずは、ユーザー入力がそのままAPIに渡らないよう、前処理パイプラインを設計・実装しました。
- 禁止語フィルタ（ブラックリスト）
- 個人情報パターン検出（メール・電話番号・住所など）→ 削除またはマスク
- 長さ・文字種類の制限（必要な場合は切り詰めて要約を促す）
例（擬似コード）
def sanitize_input(text):
# 1) 個人情報をマスク
text = mask_personal_info(text)
# 2) 禁止語を検出（見つかったら入力を拒否or要修正を促す）
if contains_prohibited(text):
raise ValueError("入力に不適切な語句が含まれています。内容を修正してください。")
# 3) 長さ制限
return truncate_if_needed(text, max_chars=1000)
生徒の反応：「個人情報をうっかり入れそうになったとき、自動的に止めてくれるの安心！」
■ 実習②：出力の検証ワークフロー
生成結果をそのまま表示せず、以下のチェックを通す設計にしました。
- 形式チェック（箇条書き／JSON／文字数など）
- 禁止語チェック（差別表現・個人情報など）
- 事実確認のための外部参照フラグ（重要な事実が入っている場合は‘要確認’ラベル）
- 信頼度メタデータの付与（確信度はモデル出力だけで決められないが、簡易ルールでラベル付け）
例（擬似コード）
def validate_output(output):
if contains_prohibited(output):
return ("fallback", "不適切な内容が含まれていたため代替案を表示します。")
if not matches_expected_format(output):
return ("retry", "出力が想定形式と異なります。再度生成します。")
if needs_fact_check(output):
return ("confirm", "一部情報は要確認です。確認済みの情報のみ表示します。")
return ("ok", output)
生徒のコメント：「AIの答えが怪しいときに自動で『要確認』になるのは助かる！」
■ 実習③：フォールバック・キャッシュ・レート管理
- フォールバック：API失敗時は事前用意のテンプレートやローカルデータで応答。
- キャッシュ：同一プロンプトに対して短時間はキャッシュしてAPI呼び出しを減らす（コストとレート対策）。
- レート監視：一定時間内の呼び出し数を記録し、閾値近くでリミッタを入れる実装を紹介。
例（擬似コード）
def get_response(prompt):
key = cache_key(prompt)
if cache.exists(key):
return cache.get(key)
try:
resp = call_model_api(prompt, timeout=5)
cache.set(key, resp, ttl=300) # 5分キャッシュ
return resp
except TimeoutError:
return local_fallback(prompt)
生徒の反応：「キャッシュすると速くなるし、APIの使いすぎも防げるんだ！」
■ 実習④：UI上での透明性とユーザー制御
ユーザーがAIの振る舞いを理解できるUI設計を議論・作成。
- 「AIが生成」ことを明示（例：「AIが生成した案です」ラベル）
- 「出典を見る」「再生成する」「人間に確認を依頼する」ボタンを用意
- 生成結果の信頼度や注意書きを目立つ場所に表示
生徒の感想：「AI任せにしないUIは信頼感が違うね！」
■ 実務的な注意：ログと監査、データ保持方針
授業では運用面の設計も扱いました。
- 監査ログ：すべてのAPI呼び出し（入力・応答・ステータス）を追跡できるようにする。
- データ保持：ユーザーデータ・ログの保存期間や匿名化ポリシーを定める。
- アクセス制御：誰がログにアクセスできるかを限定する。
田中先生：「教育の場でもログは重要。ただしプライバシーに配慮して取り扱うこと。」
■ 倫理ワーク：ケーススタディと議論
授業後半は短いケーススタディを使い、倫理的判断を班で議論。
- AIが有害な出力をしたら誰の責任か？
- ユーザーがAI出力をそのまま使って損害を受けたら？
- 教材で学んだ『出典表示』や『注意書き』でどこまで責任を軽減できるか？
生徒の発言：「結局は設計で予防することと、使い手に注意を促すことが両方大事だね。」
■ 先生のひとこと
「設計は“安全に使うための約束”を作ること。技術的な対策と、ユーザーに対する開示・教育、この両輪で初めて安心して使えるアプリが生まれます。」
■ 宿題（実践設計課題）
- 自分のミニアプリに生成AIを組み込む場合の**設計図（フローチャート）**を作る（入力→検査→API呼び出し→検証→フォールバック→表示）。
- 入力サニタイズのルールを3つ以上列挙して、それがなぜ必要かを30〜80字で説明する。
- 出力検証で行うチェック項目を3つ書き、各チェックで失敗したときのフォールバック動作を一行で示す。
■ 来週の予告：実装ハンズオン（設計をコードにする）
来週は今回作った設計を基に実際にコードで組み立てるハンズオンを行います。モデル呼び出し部分は学校指定の安全環境を使い、前処理・後処理・キャッシュ・フォールバックまで一通り実装して動かしてみます。
設計段階で「安全性」と「使いやすさ」を両立させる学びを深めた26週目。生徒たちは、生成AIを単に“便利な道具”としてだけでなく、“責任ある機能”として組み込むための視点を身につけました。