毎月作る確認テストの問題と解答を、配る前に誤字・設問番号のずれ・配点の合計・解答との食い違いで点検する

処理の起点を決める

10分ごとに動く時間主導型のトリガーを1本使います。 時間主導型のトリガーは毎分から月1回まで指定でき、実行時刻は少しばらつきます。講師がフォルダに入れてから10分ほどで結果が届けば、待たされる感じはありません。

フォルダに入った瞬間に動かさないのは、問題と解答が別々に入るからです。 問題だけが入った時点で動くと、解答が無いまま点検が始まります。名前の付け方で組を判定し、2つそろったものだけを処理します。 片方だけが2時間以上残っていたら、作った講師に「解答が入っていません」と知らせます。

名前の付け方は、中2_数学_標準_10月確認_問題 と 中2_数学_標準_10月確認_解答 のように、最後の「問題」「解答」だけが違う形にします。この決まりが、組を見つける唯一の手がかりです。

入力データを集める

表記の決まりの一覧が、誤字の指摘の質を決めます。 「答えなさい」と「答えよ」が混ざっていることを誤りとするかは、塾の決まりです。一覧が無いと、AIは自分の好みで直そうとします。

数えた結果もAIに渡します。 「問5が2回出てくる」と分かっていれば、AIはその周りを特に注意して読めます。ただし、数えた結果をAIに確かめ直させることはしません。 数えた結果は数えた結果として、そのまま点検結果に載せます。

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

段落ごとに読むのは、設問の切れ目を見つけるためです。 getText() で本文をまとめて取ると、改行の位置しか手がかりが残りません。段落ごとに読み、「問1」「(1)」「【1】」で始まる段落を設問の始まりとします。 塾の中で、設問番号の書き方を2〜3種類に決めておきます。

表は、解答欄と配点の表として扱います。 解答を「設問番号・解答・配点」の3列の表で作る決まりにすると、配点の合計は表の列を足すだけで出ます。 問題の側で「（各3点）」と書いている場合は、その設問の小問の数を掛けます。

AIへ渡す前に整形する

1. 設問に分ける … 段落の先頭の番号で設問を区切り、小問まで含めて番号の木を作ります
2. 配点を拾う … 「（5点）」「（各3点）」「配点：」などの書き方を決めた形だけ拾います。拾えない書き方のものは「配点不明」として点検結果に載せます
3. 数える … 設問番号が1から順に並んでいるか、重複や飛びが無いか。配点の合計が満点と一致するか。問題と解答で設問の数と番号が同じか
4. 図の位置に印を付ける … 本文の中の画像の位置に「【図】」と入れ、AIに図があることだけを伝えます
5. 長さを確かめる … 1組の本文が極端に長いもの（総合問題など）は、大問ごとに分けて呼びます

3番目は、AIを呼ぶ前に終わらせます。 数えた結果に誤りがあっても、AIの点検は続けます。ただし点検結果の先頭には、数えた誤りを載せます。 番号のずれと配点の合計の誤りは、印刷前に必ず直すものだからです。

4番目で図があることだけを伝えるのは、AIに図の中身を想像させないためです。 「図のように」と書かれた設問は、図を見ないと解答が正しいか分かりません。 AIには「図を見ていないので判断できない」と返させます。

AIに処理させる

させるのは、決めた種類の指摘に印を付け、根拠の文を書き出すことだけです。

3行目の answer_doubt は、確定ではなく疑いです。 AIが計算をやり直して違う値になった、というだけで、違っているのがAIの計算のほうである可能性も残ります。 そのため、この種類の指摘は必ず needs_teacher とし、点検担当が解き直す設問の一覧になります。全部の設問を解き直す代わりに、疑わしいものだけを解き直すのが、第4章の④を減らす仕組みです。

2行目がいちばん大事です。 AIに配点を足させると、多くの場合は正しい合計を返しますが、ときどき100点ではないものを100点と書きます。 合計を確かめたいのに確かめる手段が誤る、というのでは意味がありません。

指示内容を固定する

あなたは学習塾の教務部で、配る前の確認テストを点検する係です。
下の問題と解答だけを根拠にしてください。原稿を書き換えないでください。

【指摘する種類】
- typo: 誤字・脱字、【表記の決まり】から外れた書き方
- instruction_mismatch: 問題文の指示（記号で・〇つ・〇字以内・単位をつけて など）と
  解答の形が合わない
- answer_doubt: 解答が問題文の条件と合わない、または計算をやり直すと違う値になる
- choice_issue: 選択肢の記号の重複・飛び、解答の記号が選択肢に無い
- reference_issue: 「問〇の答えを使って」などの参照先が見つからない
- figure_not_checked: 【図】を見ないと解答の正しさを判断できない設問

【厳守事項】
- 指摘ごとに、該当する設問番号と、根拠にした文を原文のまま quote に写してください。
- 直し案は suggestion に書いてもよいですが、原稿の書き換えではなく案として書いてください。
- 配点の合計、設問の数、番号の並びは数えないでください。
  【数えた結果】に書かれているものを、そのまま正しいものとして扱ってください。
- answer_doubt のときは、あなたが計算した過程を reasoning に短く書いてください。
  自分の計算が誤っている可能性があるので、断定しないでください。
- 【図】を含む設問では、図の中身を想像しないでください。
  図を見ないと判断できない場合は figure_not_checked にしてください。
- 【表記の決まり】に無い書き方の違いは typo にせず、style_question にしてください。
- 問題の良し悪しや難易度については書かないでください。
- 指摘が無い場合は、findings を空の配列にしてください。

【テストの情報】{grade} {subject} {class} 満点{full_score}点
【表記の決まり】{style_rules}
【数えた結果】{count_result}
【問題】{question_text}
【解答】{answer_text}

「数えないでください」を明記するのは、AIが親切に数え直すからです。 数え直した結果が数える処理と違うと、どちらが正しいかを人が確かめることになります。数えるのは仕組みの仕事と決め、AIには触らせません。

answer_doubt で計算の過程を書かせるのは、点検担当の確認を速くするためです。 過程を読めば、AIがどこで問題文を読み違えたのか、本当に解答が違うのかを数十秒で判断できます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。 構造化出力では output_config.format に json_schema の型と JSON Schema を渡し、応答が決めた形に合うことが保証されます。 ただし、安全上の理由で応答を断った場合と、出力の上限に達した場合は形が合わないことがあるとされているので、停止の理由を確かめてから読みます。

{
  "test_id": "中2_数学_標準_10月確認",
  "findings": [
    {
      "type": "typo | instruction_mismatch | answer_doubt | choice_issue | reference_issue | figure_not_checked | style_question",
      "question_no": "問3(2)",
      "quote": "",
      "suggestion": "",
      "reasoning": "",
      "route": "author | needs_teacher"
    }
  ]
}

JSONで受け取る1つ目の理由は、点検結果のスプレッドシートに1指摘1行で並べられることです。 講師は自分のテストの行だけを見て、「直した」「直さない」を1列に書き込めます。

2つ目は、route で振り分けを決められることです。

3つ目は、数えた結果と並べて1枚にできることです。 点検結果の先頭の行には、数える処理が出した「問5が重複」「合計98点（満点100点）」を入れ、その下にAIの指摘を並べます。数えた誤りとAIの指摘を、出どころが分かる形で分けて見せます。

スクリプトの側では、quote が問題か解答の本文に実際に含まれているかを確かめます。含まれていない quote は、AIが作った文として指摘ごと「要確認」にします。

システムへ連携する

ドキュメントには書き込みません。 コメントや修正の提案を原稿に直接付ける形も考えられますが、原稿に触れるのは作った講師だけ、と決めておくほうが、どの版を印刷したかが追いやすくなります。 指摘はすべてスプレッドシートの側にあります。

Claude API の呼び出しは UrlFetchApp.fetch() で、method を post、contentType を application/json にし、ヘッダに APIキーと anthropic-version を入れます。 muteHttpExceptions を true にすると、失敗の応答でも例外を投げずに応答を返すので、応答コードを見て再試行するかを決められます。 APIキーはスクリプトのプロパティに置き、コードには書きません。

点検結果の列は、テストID、版（何回目の点検か）、指摘の出どころ（数えた／AI）、種類、設問番号、根拠の文、直し案、計算の過程、振り分け、講師の判断（直した／直さない／該当しない）、点検担当の確認、日時です。

人が確認する

1. 作った講師が、author の指摘を1件ずつ見る … 直すなら原稿を直し、直さないなら理由を一言書きます
2. 直したら、もう一度「点検待ち」に入れる … 直した周りのずれを、数える処理がもう一度見ます
3. 点検担当が、needs_teacher の設問を解き直し、図を見る … answer_doubt は計算の過程を読み、本当に違うかを確かめます
4. 点検担当が、指摘の無い組も含めて体裁を見る … 図の位置、改ページ、解答欄の大きさは、この構成では見ていません
5. 点検担当が、印刷してよいと点検結果に書く … この記入が無いテストは印刷に回しません

4番目を省かないでください。 AIの指摘が0件の組ほど、点検担当は安心して流しがちです。図の多い理科や社会では、0件は「見られる部分に誤りが無かった」というだけです。

目標は、1組8分です。 指摘を読み、疑わしい計算問題を解き直し、体裁を見るだけになります。最初から全部を読み直す必要はありません。

例外に対処する

上から4行目までは、原稿の作り方の決まりの問題です。 名前の付け方、ファイルの種類、設問番号の書き方。決まりが守られていないものを無理に読もうとせず、決まりに戻してもらいます。 2か月も回すと、講師の側の作り方がそろってきます。

記録を残す

• 点検したドキュメントのID、版、点検した日時
• 数える処理の結果（設問番号の並び、配点の合計、設問の数）
• 生成AIへ渡した本文と、返ってきたJSONの全文
• 講師の判断（直した／直さない／該当しない）と、その理由
• 点検担当の確認と、印刷してよいと決めた日時
• 配った後に見つかった誤りと、それが点検結果に載っていたかどうか

4つ目の「該当しない」は、指示を直す材料になります。 AIの指摘のうち講師が「該当しない」とした種類が偏っていれば、表記の決まりの一覧か、指示の書き方が足りていません。

最後の行は、この構成の効き目を測る唯一の記録です。 配った後の誤りが、点検結果に載っていたのに直されなかったのか、そもそも載っていなかったのかで、手を入れる場所が違います。