生徒が提出した作文・小論文を読み取り、評価の観点ごとに添削コメントの下書きを付けて返却を早める

処理の起点を決める

10分おきに動く定時の処理を起点にします。 Google Apps Script のインストール型トリガーには、指定した間隔でスクリプトを動かす時間主導型のトリガーがあります。公式の一覧に、ドライブのフォルダにファイルが追加されたことを起点にするトリガーは挙がっていません。そのため、提出フォルダを定期的に見に行く形にします。

1回の実行で見るのは、台帳にまだ登録されていないファイルだけです。 ファイルの ID を台帳の列に持ち、登録済みなら飛ばします。処理が途中で止まっても、次の回に同じファイルが拾い直されます。

締切日の前後は提出が集中するので、1回の実行で扱う本数に上限を置き、残りは次の回に回します。 1本ごとに台帳へ書き込み、書き込んだものだけを「処理済み」にします。

インストール型トリガーは、作った人のアカウントで動きます。 個人のアカウントで作ると、その人が異動したときに止まります。添削センターの共用アカウントで作ります。

入力データを集める

質を決めるのは、基準表と前回の講評です。 基準表が「論理的に書けているか」のような一文だけだと、所見も同じくらい曖昧になります。「主張が冒頭か末尾にあり、理由が2つ以上ある」のように、本文を見て確かめられる形の基準になっているほど、所見に根拠の文番号が付けやすくなります。

受講生の名前はAIへ渡しません。 受講生の番号と学年だけで足ります。講評の宛名は、台帳に書き込むときに Google Apps Script が付けます。

表記の方針を渡すのは、指摘の範囲をそろえるためです。 中学1年の作文で常用漢字外の字をひらがなで書いたものまで指摘すると、赤ばかりの添削になります。学年ごとに、指摘する範囲を手引で決めて渡します。

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

前回の講評は、全文ではなく「直す点」だけを渡します。 全文を渡すと、今回の講評が前回の言い回しに引きずられます。渡すのは、今回それができているかを確かめるための材料だけです。

画像は、アプリから届いたものをそのまま渡します。 縮小や圧縮をかけると、細い線の字がつぶれます。

AIへ渡す前に整形する

1. ファイルの形式の確認 … 画像（PNG・JPEG・WEBP・HEIC・HEIF）かPDFか、入力された文章かを見分けます
2. 向きの確認 … 公式の案内でも、ページを正しい向きにしてから渡すことが推奨されています。横向きに撮られた原稿用紙は回転してから渡します
3. 枚数の確認 … 複数枚の原稿用紙は、提出時のページ順で1回の依頼にまとめます
4. サイズの確認 … リクエスト全体が20MBを超えるときは、Files API で先に上げます
5. 手書きの文字起こし … 手書きのものだけ、Gemini に書かれたとおりの文字起こしをさせます（プロンプトは次々項）
6. 文番号を振る … 起こした文章、または入力された文章を句点で区切り、S1、S2…と番号を振ります
7. 字数を数える … 字数は Google Apps Script で数え、指定字数との差を台帳に書きます。AIには数えさせません

5番目を、所見を作る依頼と分けるのが要点です。 1回の依頼で「読んで、直して、講評して」とまとめると、AIは読み取りの段階で誤字を正しい字に直したうえで講評を書きます。生徒の誤字が、指摘される前に消えます。 文字起こしだけを先に独立させ、「書かれたとおりに写す、誤字も直さない」と指示します。

6番目の文番号は、指摘の場所を示す共通の番地です。 原稿用紙のマス目の位置をAIに答えさせるより、文番号と引用で示したほうが、添削者が原本の中で見つけやすくなります。

AIに処理させる

させるのは、表記の誤りの指摘、4つの観点ごとの所見、講評の下書きの3つです。

表記の指摘には reading の欄を付けます。 手書きの文字起こしのときに、字の形がはっきりしていたか（clear）、崩れていて自信がないか（uncertain）を、文字起こしの段階で印を付けさせておき、指摘に引き継ぎます。uncertain の字にかかる指摘は、添削者が原本で必ず見るという順番を画面の側で作ります。

最後の行が、添削の品質とは別の意味で大事です。 作文には、書き手の悩みや家庭のことが書かれることがあります。そこに講評の下書きを自動で付けると、指導の言葉で返してはいけない内容に、指導の言葉を返すことになります。 印の付いた提出は、添削者ではなく添削センターの責任者に回し、社内で決めた手順で扱います。

1行目がいちばん起きやすい失敗です。 スキーマに評価の欄を置いておくと、AIは所見と一緒に評価を埋めます。評価の欄はスキーマに置かず、台帳の側で添削者が入力する列にします。

指示内容を固定する

文字起こし（手書きのものだけ）：

あなたは原稿用紙の手書きの文字を、書かれたとおりに文字へ起こす担当です。
添削はしません。

【厳守事項】
- 書かれたとおりに写してください。誤字、送り仮名の誤り、句読点の抜けも、
  直さずにそのまま写してください。正しい字に置き換えないでください。
- 読めない字は、1字ごとに〓と書いてください。文脈から推測して埋めないでください。
- 字の形が崩れていて自信のない字は、uncertain_chars に、その字と前後の数文字を書いてください。
- 消しゴムで消した跡や、二重線で消した字は写さないでください。
- 段落の始まり（1マス空け）は、改行で表してください。
- 原稿用紙の枠外の書き込み（名前、メモ）は写さないでください。

表記の指摘と観点ごとの所見：

あなたは通信教育の添削センターで、添削者のための下書きを作る担当です。
評価は付けません。評価は添削者が決めます。

【渡すもの】
課題文：{task_text}
学年：{grade}
評価の観点と基準：{rubric}
表記の方針（この学年で指摘する範囲）：{style_policy}
前回までの「直す点」：{previous_points}
本文（文番号つき）：{numbered_text}
自信のない字の一覧：{uncertain_chars}

【表記の指摘】
- 誤字、送り仮名、句読点、文末の不統一、主語と述語のねじれを指摘してください。
- 表記の方針にない種類の指摘はしないでください。
- 1件ごとに、文番号と、本文からそのまま写した引用を付けてください。
- 〓を含む箇所は指摘しないでください。
- 自信のない字の一覧に含まれる字にかかる指摘は、reading を uncertain にしてください。

【観点ごとの所見】
- 4つの観点それぞれについて、基準の文に照らして、本文に何が書かれているかを書いてください。
- 根拠にした文番号を必ず付けてください。根拠が見つからなければ
  「該当する記述なし」とし、推測で所見を書かないでください。
- A・B・C などの評価は書かないでください。
- 前回までの「直す点」が今回できているかを、できている／できていない／判断できない
  のどれかで書き、根拠の文番号を付けてください。

【講評の下書き】
- よかった点を1つ以上、直す点を2つまで、次の課題で意識する点を1つ書いてください。
- {grade}の生徒が読んで分かる言葉で書いてください。
- 本文を書き直した模範の文章は書かないでください。
- 生徒の人柄や家庭について推測して書かないでください。

【気がかりな記述】
- 悩み、いじめ、体調、家庭の事情など、文章の指導とは別の対応が要る記述があれば、
  concern を true にし、講評の下書きは空にしてください。

「直さずにそのまま写す」を、文字起こしの側で2回書いているのは意図してのことです。 一度だけだと、明らかな誤字（「以外」と「意外」など）は正しい字にして写します。AIにとっては親切のつもりの補正が、添削では見つけるべき誤りを消す操作になります。

「評価は書かない」も、冒頭と観点の節の2か所に書きます。 基準表にA・B・Cの文が並んでいるので、何も言わなければ所見の末尾に「Bに相当」と書き足します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "submission_id": "",
  "source": "handwritten | typed",
  "transcription": {
    "status": "ok | partial | failed",
    "unreadable_count": 0
  },
  "corrections": [
    { "sentence_id": "S3", "quote": "", "type": "誤字 | 送り仮名 | 句読点 | 文末 | ねじれ",
      "suggestion": "", "reading": "clear | uncertain" }
  ],
  "rubric_notes": [
    { "criterion": "課題への応答 | 構成 | 根拠と具体例 | 表記と語法",
      "observation": "", "evidence": ["S1", "S7"] }
  ],
  "previous_points": [
    { "point": "", "status": "improved | not_yet | unknown", "evidence": ["S5"] }
  ],
  "comment_draft": { "good": [""], "fix": [""], "next": "" },
  "concern": false
}

1つ目の理由は、指摘を後から機械で確かめられることです。 sentence_id と quote の組が本文に実在するかを Google Apps Script で照合し、実在しない引用を持つ指摘は台帳に書き込む前に落とします。 Gemini のスキーマは JSON の形を守らせますが、中身が本文と合っているかまでは保証しません。

2つ目は、評価の欄がないことです。 rubric_notes には所見と根拠しかありません。評価は台帳の側の列で、添削者だけが入力できます。 スキーマに欄がなければ、AIが評価を書く場所もありません。

3つ目は、reading と transcription.status で確認の順番を決められることです。 台帳の画面では、uncertain の指摘を先頭に並べ、partial の提出には「原本を通読すること」と表示します。failed の提出には下書きを付けず、そのまま添削者に回します。

concern が true のものは、台帳に書き込む段階で担当の添削者から外し、責任者の確認待ちの列に入れます。 講評の下書きは空で届くので、誤って返却される経路がありません。

システムへ連携する

返却はこの構成から行いません。 下書きを台帳に書き込むところまでで止め、返却は添削者が確定の操作をしたものだけが既存の経路で出ます。 自動で返却する経路をつなぐと、確認の終わっていない下書きがそのまま受講生に届く失敗が、一度で起きます。

台帳の「評価」の列は、Google Apps Script から書き込みません。 列ごとに、スクリプトが書く列と人が書く列を分け、人が書く列にスクリプトが触らないようにします。

人が確認する

添削者は全件を見ます。 この構成は、確認を減らすものではなく、赤入れと講評を書く時間を減らすものです。

1. uncertain の指摘を原本で見る … 画面の左に原本の画像、右に下書きを並べ、該当の文を原本で探します。読み取りの誤りなら指摘を消します
2. clear の指摘を流し見る … 表記の方針の範囲に入っているかを見ます
3. 観点ごとの所見を読み、評価を付ける … 根拠の文番号を本文で確かめ、基準表に照らして自分で評価を決めます
4. 講評を直す … 自分の言葉に直し、所見と評価が食い違っていないかを見ます
5. 確定する … 確定の操作をしたものだけが返却されます

3番目で、所見の根拠を本文で確かめることを省かないでください。 所見は本文の要約に近いので、読んだ気になれる文章です。根拠の文番号を開いて初めて、その所見が本文に基づいているかが分かります。

目標は、1本12分です。 通読は残りますが、赤入れを書く時間と講評の文を組み立てる時間が減ります。12分を大きく超える提出が続くときは、手書きの読み取りが崩れているか、基準表の文が曖昧すぎて所見が使えていないかのどちらかです。

例外に対処する

上から2行目までが、手書きの提出の大半の例外です。 暗い場所で撮った画像、影の入った画像、斜めから撮った画像です。AIの精度を上げるより、提出時の撮影の手引を直すほうが効きます。

記録を残す

• 提出物の原本（画像または文章）と、提出日時
• 文字起こしの結果と、uncertain_chars の一覧
• AIへ渡した入力（課題文、基準表の版、前回の「直す点」）と、返ってきたJSONの全文
• 添削者が下書きから変えた箇所 … 消した指摘、足した指摘、直した所見と講評
• 添削者が付けた評価と、確定した日時
• 引用が本文になかったために落とした指摘の件数
• concern が付いた提出と、その後の扱い

4つ目が、この構成の改善の材料になります。 どの種類の指摘がよく消されているか、どの観点の所見がよく書き直されているかを月に一度集計すると、プロンプトと基準表のどちらを直せばよいかが分かります。

3つ目で基準表の版を残すのは、基準が学期の途中で変わるためです。 受講生から「先月と言われることが違う」と問い合わせが来たとき、当時どの基準で下書きを作ったかが残っていないと答えられません。