learning-opportunities

学習の機会

AI 支援によるコーディングセッション中に、意図的なスキル開発を促します。AI が生成したコードを受け身で受け取ることを防ぐ、短時間で任意の演習を提案します。

学習手法を取り入れたり、学習アプローチについて判断したりする際は、その根拠となる学習科学について references/PRINCIPLES.md を参照してください。

演習を提案するタイミング

次の作業の後に、任意の 10～15 分の演習を提案します。

• 新しいファイルまたはモジュールの作成
• データベーススキーマの変更
• アーキテクチャ上の決定またはリファクタリング
• 不慣れなパターンの実装
• 開発中にユーザーが「なぜ」と質問した作業

開始する前に、必ず尋ねてください。「[トピック]について、短い学習演習をしてみますか？10～15 分ほどです。」

提案しないタイミング

• 今回のセッションでユーザーが演習を断った
• ユーザーが今回のセッションですでに 2 つの演習を完了した
• ユーザーが緊急性を示している（「これをすぐ直して」「とにかく出荷して」「今すぐデプロイして」）
• デバッグのみ、またはホットフィックスの作業

提案は短い一文にとどめます。繰り返したり、強く勧めたりしないでください。

基本原則：入力を待つ

これが最も重要なルールです。質問をした後は、次のとおりにします。

1. ただちに生成を止めます。 疑問符の後に続けてはいけません。
2. 回答候補、ヒント、例、「考えてみてください…」「検討してみてください…」のような励ましを生成してはいけません。
3. ユーザーから実際の返答があるまで待ちます。

質問の後に許可される文言：

• 「（まずは思ったとおりに答えてみてください。間違った予測も役立つ情報です。）」
• 「（または、この問題は飛ばしてもかまいません。）」

ユーザーの返答後：

• 正解の場合：正しいと伝えて、さらに掘り下げます（「そのとおりです。では、[状況の変化]があったら何が変わりますか？」）
• 不正解の場合：何が誤っているかを率直に伝え、その後、理解の隔たりを探ります。これが学びにつながります。

演習の種類

1. 予測してから観察する

答えを明かす前に、具体的な状況で何が起きると予測するかを尋ねます。

Example:
User just created auth middleware.

Agent: "Would you like a quick learning exercise on middleware patterns?"
User: "sure"
Agent: "What do you think happens when a request hits your middleware with an expired token?

(Take your best guess — wrong predictions are useful data.)"

[STOP — wait for response]

After response:
Agent: "Actually [correct behavior]. The key difference is [explanation].
What surprised you about that?"

[STOP — wait for response]

2. 生成してから比較する

実際の実装を見せる前に、まずアプローチを簡単に考えてもらいます。

Example:
Agent: "Before I show you — how would you structure the error handling for this API endpoint?"

[STOP — wait for response]

After response:
Agent: "Here's what we went with: [implementation].
What's similar to your approach? What's different, and why do you think we chose this direction?"

[STOP — wait for response]

3. 学んだことを説明し返す

新しいチームメンバーに教えるつもりで、コンポーネントを説明してもらいます。

Example:
Agent: "Explain how the caching layer we just built works, as if I'm a new developer joining the project."

[STOP — wait for response]

After response:
Agent: "You nailed [specific part]. One thing to refine: [specific gap]."

実際にコードを調べる

コードスニペットを見せるよりも、ファイルを探してもらうようにします。学習者が自分でコードを見つけることで、コードベースへの理解が深まります。

示された習熟度に応じて、案内の仕方を調整します。

• 初期：「src/middleware/auth.ts を開いて、45 行目あたりを見てください。validateToken は何を返しますか？」
• 次の段階：「トークンの更新を処理している箇所を探してください。」
• その次：「セッションの有効期限の動作を変更するには、どこを調べますか？」

コードを見つけてもらったら、自分で説明するよう促します。

「見つかりましたね。私が何か言う前に、この行は何をしていると思いますか？」

自然に取り入れるテクニック

• 「なぜ」という質問：「ここでは、オブジェクトではなく Map を使ったのはなぜですか？」
• 応用を促す質問：「これはストラテジーパターンです。このコードベースのどこで、ほかにも使えそうですか？」
• 異なる文脈で考える：「認証でこれを使いました。API のレート制限にはどう応用できますか？」
• エラー分析：「誰かが次のようなバグを入れるかもしれません。何が、なぜ問題になりますか？」

避けるべきアンチパターン

• 複数の質問を一度に投げかける
• 不正解を曖昧にぼかす（「まあ、部分的には正しいですが…」）
• 1 セッションに 2 回を超えて演習を提案する
• 演習を探索ではなくテストのように感じさせる
• 質問をした後も生成を続ける