mcpField
K
k12-lesson-planning

k12-lesson-planning

github.com/anthropics生産性600114 回インストール2 週間前に更新
リポジトリ

k12-lesson-planning について

K-12 教師向けの授業計画スキルで、スタンダードに沿った授業案、生徒用教材、教師用観察テンプレートを編集可能な Word 文書として作成します。教科別の指針に振り分け、Learning Commons Knowledge Graph の有無に応じて進められ、草案を先に確認する方法もあります。

主な機能

  1. 01教科別の指針へ振り分け
  2. 02スタンダードとカリキュラムを踏まえた計画
  3. 03確認用の草案を提示
  4. 04授業案、生徒用教材、観察テンプレートを作成
  5. 05編集可能な Word 文書を出力

活用シーン

  1. 01学年と教科に合わせた授業計画
  2. 02生徒向けの授業課題の準備
  3. 03授業観察テンプレートの作成
  4. 04草案への意見を反映した内容の修正

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/anthropics/k12-teacher-skills --skill k12-lesson-planning

インストール後、Claude Code で/k12-lesson-planningを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
references/
ela.md
example_lesson.json
learning-commons-kg.md
math.md
NOTICE
output.md
science.md
social_studies.md
scripts/
lesson_common.py
render_all.sh
render_documents.py
render_lesson_docx.py
render_lesson_html.py
theme.css

詳細

K-12 の授業計画

教師がすぐに使える、標準に準拠した授業計画に、生徒向け教材と教師用観察テンプレートを加えたものを、編集可能な Word ドキュメントとして、1 回の出力で作成します。バンドルされたスクリプトを使い、1 つの素材ソース JSON から生成します。教科ごとに独自の教育法と出力マッピングがあり、それぞれ教科別の参照ファイルに記載されています。このスキルは、適切な参照ファイルを選びます。Learning Commons Knowledge Graph の有無にかかわらず動作します。

このスキルでいう「教師」とは、会話相手であるユーザー本人を指し、第三者を指すことはありません。「教師向け」はドキュメントの対象読者を示し、生徒ではなく、そのユーザーを指します。


教師への進捗共有

教師の進め方が決まったら(下書きの提案への回答後)、これから行うことを 1〜2 文で伝えます(例:「基準を調べ、カリキュラムの授業から参考になるアイデアを取り入れて、授業計画、生徒用教材、観察テンプレートを作成します。」)。

タスクリストまたは ToDo ツールが利用できる場合は、このスキルの手順もそこで説明し、教師が進捗を確認できるようにします。この会話にそのようなツールがない場合に限り、省略できます。

教師向けの表現のみを使います。教師が受け取るものを示し、ツール名、ファイル名、「JSON」、「レンダリング」には言及しません。


ステップ 0 — 振り分け(何よりも先に、無言で行う)

  1. 教科。 プロンプトとそれまでの会話から、依頼された授業の教科を判断します。

    • math — 算術、分数、幾何、代数、微積分、統計、CCSS-M コード、IM(Illustrative Mathematics)
    • ela — 読解、作文、フォニックス、文学、読解力、語彙、CCSS-ELA コード(RL/RI/RF/W/L)
    • science — 現象、NGSS Performance Expectations、生物学/化学/物理学/地球科学、OpenSciEd
    • social_studies — 歴史、公民、地理、経済学、C3 inquiry arc、州の社会科基準

    次に、該当する参照ファイルをすぐに読みます。

    • math → references/math.md
    • ELA → references/ela.md
    • science → references/science.md
    • social studies → references/social_studies.md

    該当する参照ファイルを読み込むことは必須です。 教科の参照ファイルを読む前に授業案を作成することは、重大な失敗です。参照ファイルには、その教科に固有の指示がすべて記載されています。優先事項の確認、カリキュラムの分岐、学年帯の構成、セクションの構成、必須事項、lesson.json のマッピングなどです。読み込んだ参照ファイルを、このターンにおける完全なスキル指示として扱ってください。教科が本当に曖昧な場合や、プロンプトが複数の教科にまたがる場合は、ステップ 1 で質問します。

  2. カリキュラム。 教師がカリキュラム(Illustrative Mathematics、OpenSciEd など)を明示または示唆している場合は、教科ファイルにあるカリキュラム分岐に従います。各教科ファイルには、そのカリキュラムの構成や用語が記載されています(カリキュラムと教科は 1 対 1 に対応:IM→math、OpenSciEd→science)。教科ファイルが対象としていないカリキュラムを使う場合は、「カリキュラムの指定なし」の手順に従い、特定のカリキュラムに固有の用語をでっち上げないでください。

  3. コネクター。 Learning Commons Knowledge Graph のツール(例:find_standard_statement)がこの会話で利用可能か確認します。これにより、ステップ 2 でどの手順を取るかが決まります。このスキルは、コネクターがなくても完全に機能します。


ステップ 1 — 確認

まず教科ファイルを読みます。確認事項のセクションで、優先事項と既定値が定められています。教科ファイルの優先順位に従って、確認質問は最大 2 つまでにし、それ以外は既定値を黙って適用します。

確認質問と下書きの提案(ステップ 4)は、構造化された質問の 1 回のやり取りでまとめて行います。提案自体が独立した質問であり、2 つの質問には数えません。確認が不要な場合は、提案だけを質問します。2 回目のやり取りを行うのは、回答を得ても授業で何を教えるのかがまだ明らかでない場合に限ります。


ステップ 2 — 標準に基づく

LC ナレッジグラフに接続されている場合: references/learning-commons-kg.md にある該当科目のセクションに従ってください。下書きの前に呼び出してください。接続されているのに呼び出さないことは、重大な不備です。各呼び出しで指定された内容のみを抽出し、そのままステップ 3 に進んでください。調査結果をチャットで要約しないでください。

接続されていない場合: 既知の最善の知識に基づいて下書きを作成し、授業計画に次の注記を追加してください。 「Learning Commons ナレッジグラフを使用せずに生成されました。標準と誤解に関する内容は、一般的なベストプラクティスに基づいています。」 KG の引用を捏造したり、目にしていないカリキュラム教材に内容を帰属させたりしないでください。


ステップ 3 — 授業を作成する

科目ファイルの作成セクションに従ってください。カリキュラムの分岐、学年帯の構成、セクションの構成、必須事項を守ってください。以下の著作権ガードレールを遵守し、カリキュラムの学習者向けテキストをそのまま複製しないでください。


著作権ガードレール

必ず独自の内容を作成してください。KG のカリキュラム教材は、構成、範囲、テキストの選定、現象の選定、問題の文脈、授業の展開設計にのみ参考として使用します。KG のカリキュラム教材に含まれる学習者向けテキスト、教師用メモ、読解問題、探究のプロンプト、ディスカッションの質問、活動の説明、問題の文脈を、そのまま複製してはいけません。

読み込まれたリファレンスに出典のカリキュラム(例:数学の IM、科学の OpenSciEd)が記載されていて、教師がそのカリキュラムの使用を確認していない場合は、出力内にも、成果物を提示するメッセージを含むチャット内にも、そのカリキュラム名を記載してはいけません。見出し、脚注、根拠を説明するセクション、進行メモにも記載しないでください。KG データは引用せずに設計の参考とします。


ステップ 4 — ドラフトの提案

教師は、作成前に簡易ドラフトを確認するかどうかを選べます。この提案はステップ 1 と同じターンで行います(利用できる場合は構造化質問ツールを使い、それ以外の場合はチャットで行います)。選択肢は常に、完全版パケットとドラフトの 2 つです。以下の文言は質問そのものに含まれるため、教師は周囲のチャット文を読まずに選択できます。

  • 質問:授業計画と生徒用教材を編集可能な Word ドキュメントにした、教室ですぐに使える完全版パケットを作成しますか?それとも、先に簡易ドラフトを確認しますか?
  • 選択肢:そのまま作成する · 先に簡易ドラフトを確認する — 授業の概要をチャットで確認

完全版パケットがデフォルトです。 ドラフトを選択する返信、またはドラフトを見たいという依頼があればドラフトを作成します。それ以外の返信の場合は、ステップ 2〜3 を実行して、ステップ 5 に進みます。

ドラフトは(希望された場合も)ステップ 2〜3 に基づいて作成し、それらの代わりにはしません。 ステップ 2 を省略せずに実行します — KG の呼び出しをすべて、記載どおり正確に行います — その後、スケッチを始める前にステップ 3 を実行します。ステップ 2 の根拠づけなしでドラフトをスケッチするのは重大な失敗であり、完全版の作成で KG を省略する場合と同じです。その後、授業をチャットに提示します。ドラフトはチャットのテキストのみで、教師の承認後、ステップ 5 でレンダリングします。次の内容を示します。

  • 学年、トピック、授業の基盤となる標準を示す 1 行(コードと、10 語以内の要旨);
  • 最大 3 文の概要(生徒が何をするか、またそれがこのクラスに適している理由);
  • フェーズごとに 1 つの箇条書きで示す流れ(名称、所要時間、内容の説明を 1 行);
  • 生徒の課題の概要 — 生徒が実際に取り組む課題を示し、教師が目を通して内容を判断できる十分な情報を含めます;
  • 授業で前提とする生徒の既習事項 — 該当する前提スキルや重要語彙を示し、クラスの実情との食い違いに教師が気づけるようにします;
  • 退出チケット

ドラフトの名称は、プレビューするドキュメントの名称に合わせます。フェーズ、課題、レベル、セクションには、授業計画で使う名称を使用します。

その後、次にどうするかを簡潔なチャットで尋ねます。選択肢を選ぶだけでは伝えられない変更内容も、テキストで返信すれば指定できます。"何か変更したい点はありますか?ここに入力してください。あるいは、作成を進めるようお知らせください。授業計画、生徒用教材、授業観察テンプレートを編集可能な Word ドキュメントとして作成します。"

変更の要望をチャット内のドラフトに反映し、再提示します。この段階での変更はすぐに行えます。教師が進行を許可したターンでステップ 5 を実行します。


ステップ 5 — 出力(1ターン)

教師が完全なパケットを選んだ場合、または下書きが承認されたターンに、ただちに実行します。

成果物は、同梱のスクリプトによって、1つの教材ソースである lesson.json から生成されます。JSON には、1回だけ登録するコンテンツを格納する shared ブロックと、各ドキュメントを自由形式の sections として作成する documents[] 配列があります。セクションの heading は、そのブロックのすぐ上に大きなタイトルとして表示されます。ブロックの label は、そのブロック自体の太字の導入文として表示されます。ラベルがセクションの見出しと同じ場合、同じ文言が続けて2回表示されます。ラベルには見出しにない情報を含めてください(タスクの名前は、どちらか一方にだけ記載します)。授業計画、生徒用教材、観察テンプレートなど、授業に必要なすべてのページ(例:資料パケット)は、documents[] に直接作成します。複数のページに登場する内容は、任意のキーを付けて shared に1回だけ登録し、各ドキュメントで {"type": "from_shared", "key": …} を使って取り込みます。これにより、ページ間で内容に食い違いが生じなくなります。

レイアウトコードを書いたり、授業の内容を別の形式に再入力したり、生成済みのドキュメントを直接編集したりしないでください。変更はすべて lesson.json に加え、再生成します(再生成はすぐに完了します)。レンダラーのスクリプトを開いたり、cat、head、grep で表示したりしないでください。その動作は §5a–5e に記載されたコマンドと出力パスで完全に定義されており、references/example_lesson.json は内容が入力済みの実例です。スクリプトのソースを読んでも、ここに記載されている以上のことは分かりません。

教師には平易な言葉で伝えてください。 上記の仕組みは教師には見えません。教師向けのメッセージでは、JSON、HTML、スキーマ、スクリプト、生成処理、ファイル名(lesson.json)、コードについて決して触れないでください。また、レンダリングコマンドが書き出す .html ファイルへのリンクを張ったり、名前を挙げたりしないでください。「lesson.json をレンダリングしました」ではなく、「授業計画ができました。生徒用教材と観察テンプレートもまもなくお届けします」と伝えます。文章中で形式を表す語句は「Word ドキュメント」だけです。これは、成果物の提示、満足度の確認、修正内容の要約、エラーメッセージなど、すべてのターンに適用されます(生成に失敗した場合は、スクリプトや JSON の失敗ではなく、ドキュメントを作成できなかったと伝えます)。

lesson.json を作成する前に、references/output.md を最後まで読んでください。すべてのドキュメントに対する必須要件(内容の充実度、一貫性、読解レベル、整合性)と、lesson.json のスキーマおよびブロックのガイド全体(§5a と §5e の内容を含む)が記載されています。

5b. すべての Word ドキュメントを生成する — 1つのコマンドを同じターンで実行
bash scripts/render_all.sh lesson.json "$OUTPUT_DIR"

documents[] の各項目について、id をファイル名とする編集可能な .docx を1つずつ書き出します(例:$OUTPUT_DIR/lesson_plan.docx、student_materials.docx、observation_template.docx、source_packet.docx)。さらに、作業用ファイルとして .html と lesson.json も書き出します。$OUTPUT_DIR に直接生成し、スクリプトが書き出したファイルはすべてそのまま残してください。教師に渡すのは Word ドキュメントだけですが、後の修正ターンでは作業用ファイルから再生成します。次に $OUTPUT_DIR の内容を一覧表示し、各ドキュメントの .docx と .html が両方存在することを確認してください。どちらかが欠けている場合や、ファイルサイズが極端に小さい場合は、スクリプトを再実行します。Word ドキュメントはまとめて教師に渡し、授業計画を最後に添付してください。チャット画面では新しい添付ファイルが先頭に表示されるためです。student_materials ドキュメントがない場合は、そのことを明確に伝えます(「この授業は口頭で進めるため、生徒用プリントはありません。生徒は……を使って学習します」など)。スクリプトでエラーが発生した場合は、lesson.json を修正して(ほとんどの場合、JSON の形式が正しくありません)、再実行してください。ファイル生成に完全に失敗した場合は、そのことを明確に伝えてください。チャットだけでの提供に黙って切り替えてはいけません。

5c. 満足度の確認と反復オプション(出力の各ターン)

各ターンの最後には、次の3つをこの順番で含む締めくくりのメッセージを1つだけ記載します。

  1. 教材に、教室にある備品で紙版の代わりに使えるものが挙げられている場合は、印刷用を作成する提案を太字で最初に伝えます。 「この授業では10のブロックを使います。足りない場合に備えて、印刷用セットを作りましょうか?」 この授業で作成したもの(単語カード、資料の抜粋、この授業のカテゴリーを記載した分類マットなど)は、すでにパッケージに含まれています。
  2. 教師が作成されたすべての成果物に満足しているか、変更を希望するかを尋ねます。例:「授業計画、生徒用教材、観察テンプレートをご確認ください。調整したい箇所はありますか?」 この問いかけは省略しないでください。
  3. 教科とトピックに合わせた、効果の高い具体的な反復オプションを3~4つ提示します。「変更をご希望の場合はお知らせください」とは書かないでください。これは具体的な提案ではありません。たとえば、小学3~5年生向けのELA読解レッスンなら、次のようにします。「(1)英語学習者向けの足場かけを増やす、(2)習熟度別に調整する、(3)お住まいの州の基準に合わせて内容を調整する、のいずれかをご希望ですか?」
5d. 修正 — 1か所を編集し、すべての成果物を同期させる

lesson.json を対象を絞って編集し、その後、すべてのドキュメントを再レンダリングします(即時反映)。成果物間の整合性を保つため、以下のルールに従います。

  • 変更が shared に登録された内容(問題、資料、退出チケット、語彙、注目ポイント、現象/文脈/数値)に関わる場合は、shared 内で編集します。そのキーを読み込むすべてのドキュメントが自動的に更新されます。
  • 文脈/数値/課題を変更した後は、整合性を総点検します。 shared を編集した後、すべての documents[] エントリーにある文章ブロックを読み直し、古い文脈、名前、数値に言及している文をすべて更新します。完了時には、どのドキュメントにも置き換え前の内容が残っていないようにしてください。古い記述の残存は、最もよくある整合性の不備です。
  • 1つのドキュメントだけを対象にする変更(例:「ワークシートの記入スペースを増やす」「観察用グリッドに列を追加する」)は、そのドキュメントの sections に記述します。shared のキーを複製して2種類に分けることはしないでください。
  • スタイル:theme フィールド(primary、title_size、body_size)はすべての成果物に適用されます。成果物は白黒印刷でもきれいに印刷できるよう、色を最小限に抑えます。セクションごと、またはフェーズごとに色を設定しないでください。

コメント