若手教員が書いた学習指導案を学校の指導の重点と過去の助言に照らして点検し、教頭・指導教員が渡すコメントの下書きを作る

処理の起点を決める

「指導案の提出」フォームの送信を起点にします。 フォームには、指導案のドキュメントのURL、教科、学年、単元名、授業の予定日、指導教員を入れてもらいます。ドキュメントのURLを入れるだけで、ファイルそのものは添付しません。

ドキュメントの共有で起点を作らないのは、共有は何度も起きるからです。 書きかけを同僚に見せる、指導教員に先に一言相談する、といった共有のたびに点検が動くと、書きかけの指導案にコメントの下書きが作られます。 提出の意思表示をフォームに分けます。

処理は1件ずつ、送信のたびに動きます。 1回の実行は6分が上限です。1本の指導案の点検は Claude API の呼び出し1回で済むので、収まります。失敗したときは、処理の記録のシートに「未処理」を残し、1時間ごとに動く時間主導のトリガーが拾い直します。

入力データを集める

質を決めるのは、前回までの助言です。 「本時の目標が活動になっている（『〜を話し合う』で終わっている）」と記録されていれば、今回の指導案で同じ書き方が残っているかを、AIは具体的に確かめられます。 記録が無ければ、毎回が初めての点検になります。

前回までの助言には、生徒のことを書きません。 シートに残すのは、指導案の書き方と授業の設計についての要点だけです。「〇組の△△さんへの配慮が足りない」のような記録は、この構成では扱いません。

データの取得方法を決める

指導案を読めないことがあります。 若手教員がドキュメントを育成の担当のアカウントに共有し忘れていると、スクリプトは開けません。開けなかったら、その旨を本人にメールで返し、共有の手順を添えます。 指導案の置き場所を学校の共有ドライブの決まったフォルダにすると、この失敗はほとんど無くなります。

Claude API のキーは、スクリプトのプロパティに入れます。 スクリプトのプロパティは、プロジェクトの設定の画面から追加でき、そのスクリプトの利用者の全員で共有されます。 スクリプトを編集できる人を、育成の担当と情報担当に限ります。

AIへ渡す前に整形する

1. 個人の記述の確認 … 「さん」「くん」「君」の前に2〜4文字の名前らしい文字が続くもの、「出席番号」「番の生徒」、学級名と人名の組み合わせを、決まった文字の並びで探します
2. 配慮の欄の確認 … 「配慮を要する生徒」の欄に、個人を思わせる書き方（「Aさん」「1名」など）があれば止めます
3. 様式の欄の抜け … 様式の決まりにある欄の見出しが、すべてあって中身が空でないかを確かめます
4. 時間配分の合計 … 本時の展開の表の時間の列を足し、授業の時間（50分）と合うかを確かめます
5. 目標の一致 … 「本時の目標」の欄と、展開の表の中の目標の書き方が同じかを、文字列で比べます
6. 長さの確認 … 本文が長すぎる場合（単元全体の資料を貼り付けている等）は、本人に確かめます

1番目と2番目で見つかったら、AIに渡さずに止めます。 本人に「該当する箇所」を示して戻し、「Aさん」「生徒A」のような記号への置き換えではなく、個人を前提にしない書き方に直してもらいます。 記号に置き換えても、学級の中では誰のことかが分かるからです。

3番目から5番目は、AIに渡す前にスクリプトで済ませます。 時間の合計のような計算をAIにさせると、表の読み違いで合計を間違えます。結果だけをAIに渡し、コメントの下書きに含めてもらいます。

AIに処理させる

させるのは、観点ごとに点検して、根拠の箇所と、指導教員が使えるコメントの下書きを書くことだけです。

右端の列が、この構成でいちばん大事な決まりです。 「目標と評価がずれている」とだけ書いたコメントは、指導教員がもう一度指導案を読み直す必要があります。根拠の文がコメントに付いていれば、指導教員は確かめるだけで済みます。

2行目がいちばん起きやすい失敗です。 「展開の改善案」を求めると、AIは導入から振り返りまでの全文を書き直して返します。それを渡すと、若手教員は指導案を写すだけになります。 コメントは「どこを、なぜ見直すとよいか」までにします。

指示内容を固定する

あなたは中学校で、若手教員の学習指導案を読む指導教員の補助です。
あなたの出力は指導教員だけが読みます。若手教員に直接は渡りません。
【指導案】【学校の指導の重点】【様式の決まり】【前回までの助言】だけを使って点検してください。
書かれていないことを推測しないでください。

【点検する観点】
1. goal_link: 単元の目標と本時の目標のつながり
2. goal_eval: 本時の目標と評価規準・評価の方法の対応
3. flow_goal: 本時の展開の学習活動が本時の目標に向かっているか
4. school_focus: 学校の指導の重点が展開のどこに現れているか
5. prior_advice: 前回までの助言が反映されているか（助言ごとに）
6. wording: 誤字、用語の不統一、長すぎる文

【status の選び方】
- ok ........ 問題が見当たらない
- review .... 指導教員に見てほしい点がある
- not_found . 判断に必要な記述が指導案に見当たらない
迷ったときは review を選んでください。

【厳守事項】
- evidence には、指導案の文をそのまま写してください。要約しないでください。
- コメントは「どこを」「なぜ」見直すとよいかまでにしてください。
  展開や目標を書き換えた文、代わりの授業の案は書かないでください。
- 指導案の総合の評価、点数、良い・悪いの判定は書かないでください。
- 教科の内容が正しいかを断定しないでください。気になる点は「指導教員の確認が必要」と書いてください。
- 生徒の様子や学級の実態を推測して書かないでください。
- 若手教員の能力や姿勢について書かないでください。
- 各コメントは120字以内にしてください。
- 良い点も、根拠の文を付けて2つまで書いてください。
- 【スクリプトの点検結果】の内容は、そのまま format_checks に写してください。計算し直さないでください。

【指導案】{plan_text}
【本時の展開の表】{flow_table}
【学校の指導の重点】{school_focus}
【様式の決まり】{format_rules}
【前回までの助言】{prior_advice}
【スクリプトの点検結果】{format_checks}

「あなたの出力は指導教員だけが読みます」を最初に書くのは、言い回しのためです。 若手教員に向けた文だと思うと、AIは励ましの言葉で包んだ長い文を書きます。指導教員向けなら、確かめる場所が短く並びます。 伝え方を整えるのは、指導教員の仕事です。

「良い点も2つまで」を入れるのは、指摘だけの下書きにしないためです。 指導教員が所見を書くとき、良い点の根拠の文があると、若手の工夫を具体的に伝えられます。 上限を決めないと、良い点がコメントの半分を占めます。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。

{
  "plan_id": "",
  "checks": [
    { "aspect": "goal_link | goal_eval | flow_goal | school_focus | prior_advice | wording",
      "status": "ok | review | not_found",
      "evidence": "", "comment": "" }
  ],
  "prior_advice_followup": [
    { "advice": "", "reflected": "yes | partly | no | cannot_tell", "evidence": "" }
  ],
  "strengths": [ { "evidence": "", "comment": "" } ],
  "format_checks": [""],
  "needs_subject_expert": [""]
}

1つ目の理由は、観点ごとに status を並べられることです。 指導教員は、下書きのドキュメントの先頭で review の観点だけを見れば、どこから読めばよいかが分かります。

2つ目は、prior_advice_followup で前回の助言の反映を一覧にできることです。 助言ごとに yes／partly／no／cannot_tell が並ぶので、同じ指摘のくり返しかどうかが、指導教員にすぐ分かります。 「前回お伝えした点が直っています」と伝えられるのも、この一覧があるからです。

3つ目は、needs_subject_expert で教科の専門の確認を分けられることです。 AIが内容の正誤を断定しない代わりに、気になった箇所をここに並べます。

システムへ連携する

API の呼び出しでは、muteHttpExceptions を true にします。 既定では、失敗の応答で例外が投げられ、スクリプトがそこで止まります。true にすると応答がそのまま返るので、状態のコードを見て「未処理」として記録し、後で拾い直せます。

若手教員の指導案のドキュメントには書き込みません。 コメントを指導案の余白に直接付けると、指導教員が読む前に若手の目に入ります。 下書きは別のドキュメントにして、指導教員のフォルダにだけ置きます。

人が確認する

下書きはすべて、指導教員が読んで直してから若手に渡ります。 目標は、1本あたり24分です。

1. review の観点を根拠の文で確かめる … 指導案の該当の箇所を開いて、指摘が当たっているかを見ます
2. 残す指摘を選ぶ … 1回の助言で伝えるのは3つまで、のように数を絞ります
3. 自分の言葉に直す … 若手との関係や、授業の前の時期に合わせて伝え方を決めます
4. 教科の確認が必要な箇所を見る … needs_subject_expert の箇所は、教科の指導教員が判断します
5. 助言の要点を記録する … 実際に伝えたことを、助言の記録のシートに1〜3行で残します

2番目を省かないでください。 下書きの指摘をすべて伝えると、若手は直すことに追われ、何がいちばん大事だったかが残りません。 何を伝えるかを選ぶことが、指導教員の仕事の中心になります。

5番目は、次の点検のための記録です。 書かなければ、次回の prior_advice_followup は空になります。

例外に対処する

1行目がいちばん大事な例外です。 止める基準は、迷ったら止める側に倒します。止めすぎると若手の手間が増えますが、渡しすぎると児童生徒の情報が外部のサービスに出ます。

6行目は、学校の Google Workspace の版によって値が違います。 トリガーの実行時間の合計は、Workspace のアカウントで1日6時間とされています。学校向けの版での値は、情報担当が確かめてください。

記録を残す

• 提出の日時、指導案のドキュメントの ID と、そのときの版
• 個人の記述の確認の結果（止めた場合は、止めた理由の種類だけ）
• Claude API に渡した材料の範囲（指導の重点と前回の助言の版）と、返った JSON
• コメントの下書きのドキュメントの ID
• 指導教員が実際に伝えた助言の要点（助言の記録のシート）
• API のエラーと拾い直しの記録

2つ目で「理由の種類だけ」を残すのは、止めた箇所の文を記録に写さないためです。 個人を思わせる記述を記録のシートに写すと、止めた意味がなくなります。