【授業レポート】システム開発入門 第25週｜生成AIの出力を検証し、プロンプトを改善する

システム開発入門の第25週では、前週に学んだ生成AIの仕組みとプロンプトの基礎を、実際の操作と検証につなげました。

プロンプトとは、生成AIに目的、条件、出力形式などを伝える指示文です。授業では、指示を書いて終わりにせず、出力を観察し、根拠と表現を確かめ、指示を直してもう一度試す流れを実践しました。

今回の授業で身につけること

今回の目標は、生成AIから答えを得ることだけではありません。出力を完成品として扱わず、人が確認して使える状態へ整えることを目指しました。

1. 学校のルールに沿った学習環境でプロンプトを実行する。
2. 出力の形式、事実性、偏り、表現の適切さを確認する。
3. 見つかった問題に合わせてプロンプトを修正し、再実行する。

出力を観察し、確認点を切り分ける

最初の実習では、各自が作成したプロンプトを実行し、出力をそのまま読んで問題点を探しました。形式が整っていても、内容まで正しいとは限りません。そこで、確認する対象を分けました。

授業で使ったプロンプト例

高校生向けに、東京都内で日帰りで行ける自然スポットを3つ、
電車での行き方（最寄り駅）と概算予算（往復）を含めて、
箇条書きで教えてください。

この例では、三つの候補が並んでいるだけでは確認を終えられません。最寄り駅の表記、交通費の目安、地名の表記ゆれまで読む必要があります。授業では、形式は整っていても、予算や交通時間が曖昧な出力があることに気づきました。

事実確認と偏りの検出

ファクトチェックとは、出力に含まれる事実を、根拠となる情報と照らし合わせる作業です。授業では、駅名や施設名をウェブや公式サイトで確認し、歴史や統計のように事実性が重い情報は複数の情報源で照合しました。

バイアスは、出力の見方や扱いに現れる偏りを指します。誤字や数値の誤りだけでなく、文化的、社会的な説明が一方へ寄っていないかも読みました。正しそうな文章を受け入れるのではなく、「何を根拠に判断できるか」を確かめる練習です。

田中先生は、生成結果を「考えの下書き」と捉え、最終的には人が責任を持って検証し、修正する必要があると説明しました。

問題点をプロンプトの改良へつなげる

検証で問題を見つけたら、その内容を次の指示へ反映します。班ごとに、出力形式を具体化する、推測を明示させる、個人情報を含めない制約を加えるといった方法を話し合い、改良版を再実行しました。

改良後も検証は必要です。詳しい条件を加えると出力を点検しやすくなりますが、指示が具体的であること自体は、事実の正しさを保証しないためです。授業では、再実行した出力を同じ観点で読み直し、期待に近づいたかを確認しました。

利用者へ注意点を伝える

出力を誰かに見せる場面では、内容を整えるだけでなく、確認が必要な範囲を利用者へ伝えます。授業では、交通費や所要時間を例に、目安であることと公式情報での確認が必要であることを注記しました。

※交通費と所要時間は目安です。利用前に公式サイトで最新情報をご確認ください。

注意書きは、誤りをなくす仕組みではありません。どの情報を利用者自身が確かめる必要があるかを、誤解のない言葉で示す役割を持ちます。

情報を安全に扱うためのルール

プロンプトと出力の内容だけでなく、入力する情報や認証情報の扱いも確認しました。

• 氏名、電話番号、メールアドレスなどの個人情報をプロンプトへ入力しない。
• APIキーやトークンを授業ノートや共有コードへ直接書き込まない。
• 差別や偏見につながる表現が出力に含まれていないかを確認する。

便利さを理由に確認を省かず、間違いが含まれる可能性を前提として扱うことが、授業全体に共通するルールでした。

生徒の振り返り

• 「実際に出力を見てから直すと、プロンプトの書き方が具体的に分かってきた」
• 「AIが『自信のない情報』を平然と出す場面を見て、必ず確認する必要があると実感した」
• 「注意書きを入れるだけで信頼感が変わるのが面白かった」

プロンプトの良し悪しを文章だけで判断するのではなく、出力を見て問題を特定し、次の指示へ反映する経験が、学びを具体的にしました。

宿題と次週へのつながり

1. 授業で使ったプロンプトの初版と改良版を、50〜100字の改良理由とともに提出する。
2. 改良版の出力から要確認事項を三点挙げ、確認に使う情報源を一つ以上示す。
3. 出力時の注意書きを自分のアプリ案へ一行加える。

次週は、今回の「実行、検証、改良」を土台に、入力の確認、出力の検証、利用者への表示をアプリの設計へ落とし込みます。続きは、第26週の生成AIをアプリに組み込む設計で扱います。