制御の受け渡しを教える

使える授業時間を選ぶ

授業の前に

1. 授業で実際に使うブラウザとネットワークで、ハンドブックとラボを開きます。
2. ライブデモ用には、失効できる低残高の専用キーを作ります。教師用キーを共有してはいけません。
3. 「保存してテスト」、ステップ1、注文3件のプレビュー、Eval完走を実行し、使用量と料金を提供元のダッシュボードと照合します。
4. スクリプト式のキーなし経路を用意し、ライブの事前確認が失敗したら切り替えます。

キーなしの経路も、正式な授業です

第1部はスクリプト式で、オフラインかつキー不要です。ラボのステップ2もローカルで動きます。残りのモデル出力は投影するか、準備済みの実行結果について話し合ってください。教室の前で私的な認証情報をトラブルシュートしないでください。

1回のクリックで使い得る量を伝える

以下は論理呼び出し回数と出力上限であり、料金の約束ではありません。ライブ費用はモデル、キャッシュ、時間帯、提供元の現在料金によって変わります。

Evalの並列数は4です。停止すると新しい処理を予定せず、実行中のリクエストも中止を試みますが、実行中のリクエストは課金される場合があります。送信済みで使用量が返らないリクエストの費用は、ゼロではなく不明です。

学習者用ワークシート

1. 現在のルールが扱えない言い回しと、それに必要な追加ルールを一つ書く。
2. Eval 1の前にスコアを予想し、理由を一つ書く。
3. 基準値、不合格ケース一つ、考えられる失敗原因を記録する。
4. 変更点を一つ挙げ、効果を予想してからEval 2を実行する。
5. 改善とリグレッションを一つずつ記録し、都合の悪いケースも隠さない。
6. よく知る分野へ移す。モデルの判断一つ、人間側に残す制御一つ、失敗入力一つ、不可逆な操作の前のゲート一つ。

プロジェクト用ルーブリック

各基準を、0（なし）、1（一部）、2（証拠あり）で採点します。証拠とトレードオフを説明できれば、異なる構成でも優れたものになり得ます。

• 問題の境界：目標、対象外、モデルの権限。
• 失敗入力：具体的、現実的、再現可能。
• 最小評価：ケース、期待する証拠、検査可能な採点規則。
• 不可逆な操作のゲート：実行前にコードまたは人が介入する。
• 信頼境界：提供元、ツール、機密情報、信頼できない入力。
• 振り返り：失敗、リグレッション、費用、トレードオフ、次のテスト。

唯一の正解ではなく、証拠を受け入れる

機密情報を含まないコンソール出力、小さなJSONまたはMarkdown結果、コードへのリンク、不合格ケース一つのトレース、ローカルのレポートカードは、いずれも有効な証拠になり得ます。特定のフレームワーク、提供元、プロンプトは要求しません。

試行授業の観察シートはローカルに保管してください。学習者のキー、プロンプト、提供元の生の本文、応答、個人を特定できる成果物を、本サイト、スクリーンショット、CIログへ入れてはいけません。