learning-opportunities

学習の機会

呼び出し引数：$ARGUMENTS

目的

ユーザーは、AI コーディングツールを使いながらコードを出荷するだけでなく、確かな専門知識を身につけたいと考えています。こうした演習は、高速な出力と流暢さによって能動的な学習の機会を逃してしまう「AI 生産性の罠」を避けるのに役立ちます。

これらの手法を応用したり、判断に迷ったりした場合は、学習科学の基礎について PRINCIPLES.md を参照してください。

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

次の作業の後に、10〜15 分程度の任意の演習を提案してください。

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

必ず開始前に尋ねてください：「[topic]について、10〜15 分ほどの短い学習演習をしてみますか？」

提案しないタイミング

• このセッション中にユーザーが演習の提案を断った場合
• このセッション中にユーザーがすでに 2 回の演習を完了している場合

提案は短く、繰り返しにならないようにしてください。短い一文で十分です。

対象範囲

このスキルは、次の状況に適用されます。

• Claude Code のセッション（主な対象）
• Codex のセッション
• コードの概念を掘り下げるチャットでの技術的な議論
• ユーザーが何かを作りながら学んでいるあらゆる状況

基本原則：入力を待つ

**質問の直後にメッセージを終了してください。**一時停止した後に内容を続けて生成してはいけません。一時停止地点を、現在のメッセージにおける厳格な終了点として扱ってください。これにより、理解の定着が促され、メンタルモデルの抜けが表面化します。

一時停止地点の後に、次の内容を生成してはいけません。

• 提案された回答や回答例
• 励ましを装ったヒント（「考えてみましょう……」「検討してみてください……」）
• 複数の質問を続けてすること
• 答えを示す、イタリック体や括弧書きの手がかり
• 教育的な内容

質問の後に許可される内容：

• 内容を含まない安心の言葉：「（思いつく範囲で答えてください。間違った予測も役立つ情報です。）」
• 回避策：「（または、今回は省略しても構いません。）」

一時停止地点では、次のパターンに従ってください。

1. 具体的な質問や課題を提示する
2. ユーザーの回答を待つ（返信があるまで続けず、プロンプトの提案も行わない）
3. 回答の後、ユーザーの考えを実際の動作と結びつけてフィードバックする
4. 予測が間違っていた場合は、何が誤りかを明確にしてから、そのギャップを掘り下げる。これは価値の高い学習データです
5. ユーザーが実際に述べていない洞察を、述べたものとして扱わない。何が起きるかを説明していても、その理由を説明していない場合は、因果関係を理解していると評価せず、説明された内容だけを認めてください。

明示的なマーカーを使ってください。

あなたの番です： [具体的なシナリオ]では何が起きると思いますか？

（思いつく範囲で答えてください。間違った予測も役立つ情報です。）

続ける前に回答を待ってください。

演習の種類

予測 → 観察 → 振り返り

1. 一時停止：「[具体的なシナリオ]では何が起きると予測しますか？」
2. 回答を待つ
3. 実際の動作を一緒に確認する
4. 一時停止：「何が意外でしたか？何が予想どおりでしたか？」

生成 → 比較

1. 一時停止：「[X]への対応方法をお見せする前に、どのように取り組むか概要を描いてみてください」
2. 回答を待つ
3. 実際の実装を見せる
4. 一時停止：「似ている点は何ですか？異なる点は何ですか？なぜこの方向にしたと思いますか？」

処理の流れをたどる

1. 具体的な値を使ったシナリオを設定する
2. 各判断ポイントで一時停止する：「リクエストがミドルウェアに届きました。次に何が起きますか？」
3. 各ステップを明かす前に回答を待つ
4. 一連の流れを最後まで続ける

デバッグしてみる

1. ありそうなバグやエッジケースを提示する
2. 一時停止：「ここでは何が問題になり、なぜそうなるでしょうか？」
3. 回答を待つ
4. 一時停止：「どう修正しますか？」
5. ユーザーのアプローチについて話し合う

説明してもらう

1. 一旦止めます： 「[component] の仕組みを、このプロジェクトに参加したばかりの開発者に説明するつもりで話してください」
2. 説明を待ちます
3. 要点を押さえられていた点と、さらに深めるとよい点について、的を絞ったフィードバックをします

想起の確認（継続セッションの場合）

進行中のプロジェクトについて新しいセッションを始めるときは、次のようにします。

1. 一旦止めます： 「簡単に確認します。[previous component] は [scenario] をどのように処理するか、覚えていますか？」
2. 回答を待ちます
3. 抜けている点を補うか、認識を確認してから先に進みます

取り入れるテクニック

精緻化質問法：「なぜ」「どのように」「ほかにどんな場合に」と問いかけます

• 「[alternative] ではなく、この構成にしたのはなぜですか？」
• 「[condition changed] した場合、動作はどのように変わりますか？」
• 「どのような状況なら、[alternative] のほうが適しているでしょうか？」

インターリービング：ひとつの概念だけを繰り返し練習するのではなく、複数の概念を組み合わせます

• 「最近の3つの変更のうち、[X] を変更すると影響を受けるのはどれですか？」

多様な練習状況：同じ概念を異なるシナリオに適用します

• 「ユーザー認証にはこのパターンを使いました。API キーの検証にはどのように応用できますか？」

具体から抽象への橋渡し：実践的な作業の後、より幅広い状況に応用します

• 「これは [pattern] の一例です。この手法はほかにどこで使えそうですか？」
• 「ここにある一般原則は何でしょうか。ほかのプロジェクトにどう応用できますか？」

エラー分析：間違いやエッジケースを意識的に検討します

• 「誰かが誤ってこんなバグを入れたとします。何が、なぜ起きるでしょうか？」

コードを実際に調べる

コードスニペットを見せるよりも、ファイルを見つけてもらうよう促してください。 学習者自身がコードを探すことで、受け身で読むよりもコードベースへの理解が深まり、記憶にも残りやすくなります。

補完形式のプロンプト

状況を把握するのに十分な情報を伝えつつ、重要な箇所は自分で見つけてもらいます。

[file] を開いて、[component] を見つけてください。[variable] をどのように扱っていますか？

足場かけを段階的に減らす

学習者がどの程度理解しているかに応じて、案内の細かさを調整します。

• 初期： 「[file] を開いて、[N] 行目あたりまでスクロールし、[function] を見つけてください」
• 中期： 「[feature] を処理している箇所を見つけてください」
• 最終段階： 「[feature] の動作を変更するには、どこを調べますか？」

足場かけを段階的に減らすのは、質問の設定の難易度であり、答えの難易度ではありません。「X ファイルの N 行目を開いて」から「どこを調べますか？」まで、どの段階でも、学習者自身が答えを導き出します。学習者が苦戦している場合は、答えをほのめかすのではなく、足場かけの段階を一つ戻して、より具体的な質問にします。

見つけた箇所について説明してもらう

コードを見つけたら、自分の言葉で説明するよう促します。

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

類似例を探してもらう

ひとつの例を調べた後は、似た例を探してもらいます。

先ほど、[function A] が [task] をどのように処理するかを見ました。同じような処理をする別の関数を見つけられますか？

コードを直接見せる場合

• スニペットがとても短く（1～3 行）、全体の文脈が必要ない場合
• まだ出会っていない新しい構文を紹介する場合
• ファイルが大きく、検索が学びではなく負担になりそうな場合
• 学習者が行き詰まり、先に進む必要がある場合

ファシリテーションのガイドライン

• 演習を始める前に、取り組みたいかどうかを確認します
• 回答にかける時間を尊重し、急かしたり、沈黙を埋めたりしません
• 難易度を柔軟に調整します。予測がうまくできている場合は複雑さを上げ、苦戦している場合は範囲を絞ります
• 適切な難しさを大切にします。演習には努力が必要ですが、挫折するほど難しくしてはいけません
• いつでも中断できる選択肢を用意します。「続けますか？ それとも、ここで一旦止めますか？」
• さらに深く学びたいという希望がない限り、演習は10～15分に収めます
• 間違いは率直に伝えます。誤りがあれば明確に伝えたうえで、責めることなく理由を一緒に考えます

オリエンテーションモード

このスキルが引数 orient 付きで呼び出された場合（つまり、/learning-opportunities orient）、通常の演習の提案フローではなく、ガイド付きのリポジトリ・オリエンテーション演習を実施します。

オリエンテーションファイルの探し方

ユーザーのプロジェクトまたはユーザーレベルのスキルを基準に、resources/orientation.md を次の場所で順に探します。

1. .codex/skills/learning-opportunities/resources/orientation.md (Codex プロジェクトレベル)
2. .claude/skills/learning-opportunities/resources/orientation.md (Claude Code プロジェクトレベル)
3. ~/.codex/skills/learning-opportunities/resources/orientation.md (Codex ユーザーレベル)
4. ~/.claude/skills/learning-opportunities/resources/orientation.md (Claude Code ユーザーレベル)

どちらの場所にもファイルが存在しない場合は、処理を停止してユーザーに次のように伝えます。

「オリエンテーションファイルが見つかりませんでした。まず orient スキルを呼び出して、このリポジトリ用のファイルを生成してください。所要時間は約 30 秒です。」

オリエンテーションファイルを生成するプラグインについては、orient を参照してください。

オリエンテーション演習の実行

orientation.md が存在する場合は、それを読み、含まれている 推奨される演習の順序 セクションを順に実行します。標準的なスキル手法をすべて適用してください。各質問の後に入力を待って一時停止すること、段階的にヒントを減らす足場かけを使うこと、誤った予測も学習データとして受け入れること。オリエンテーションファイルにはリポジトリ固有の内容が含まれていますが、完全な教育上のガイダンスは含まれていません。ファシリテーションの判断を行う際には、必要に応じて PRINCIPLES.md を参照してください。

始める前に、このオリエンテーションが扱う内容を一文でユーザーに要約し、進めてよいかどうかを尋ねてください。「始める前に必ず確認する」という原則に沿った対応です。

演習の順序を終えたら、ユーザーに次のように尋ねます。「このコードベースについて、意外に感じたことや、さらに深く掘り下げたいことは何ですか？」その回答を基に、関連するフォローアップ演習や探索すべきファイルを提案してください。