研究報告書の参考文献の一覧を、社内の書式の規定と本文の引用番号に突き合わせて校正し、引用漏れ・番号の飛び・書式の不統一を審査の前に拾う

処理の起点を決める

審査依頼のフォームの送信を起点にします。 フォームの回答を受けるスプレッドシートに、インストール型の「フォーム送信時」のトリガーを付けます。送信のたびに1本ずつ動かし、まとめて夜に回すことはしません。 審査の日程は依頼の数日後に決まるので、指摘が早く返るほど著者が直す時間を取れます。

イベントの namedValues から、原稿のURLと依頼者を取ります。 namedValues は設問の名前と値の組なので、フォームの設問の並びを変えても壊れません。values（シートの並び順の値）で取ると、設問を1つ足しただけで別の欄を原稿のURLとして読みます。

インストール型のトリガーは作った人のアカウントで動きます。 原稿を開くにはそのアカウントに閲覧の権限が要るので、事務局の共有アカウントで作り、フォームの説明に「原稿をこのアカウントと共有してから送ってください」と書きます。 共有されていない原稿は、例外処理で依頼者に戻します。

直した原稿の再送も同じフォームから受けます。 フォームに「初回／再提出」の設問を置き、再提出のときは前回の指摘一覧と並べて、直ったもの・直っていないもの・新しく出たものに分けます。

入力データを集める

質を決めるのは、書式の規定の表の記入例です。 「著者名．論文名．誌名．発行年，巻（号），始ページ-終ページ．」と項目の並びだけを書くより、正しく書かれた1件の例を種類ごとに付けたほうが、AIの校正がそろいます。 例は社内の過去の報告書から、規定どおりのものを選びます。

社内報告書の番号の一覧を持つのは、社内の文献だけは実在を確かめられるからです。 「TR-2024-118」のような番号が保管庫に無ければ、番号の打ち間違いか、まだ登録されていない報告書です。 社外の論文の実在はこの構成では確かめません。

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

1. フォームの回答から原稿のURLを取り、DocumentApp.openByUrl() で開く
2. getBody().getParagraphs() で段落を順に読み、見出しのスタイルで「参考文献」の段落を探す
3. その段落より前を本文、後ろを参考文献の一覧として分ける
4. 本文の段落から、正規表現で角括弧の引用番号を拾う
5. 一覧の段落を、先頭の番号（[1]、1.、(1) など）で1件ずつに分ける

2番目で、見出しの文字列だけでなくスタイルも見ます。 本文の中に「参考文献[3]によれば」のような書き方があると、文字列だけで探すとそこを一覧の始まりと取り違えます。 見出しのスタイルが付いた段落を優先し、無ければ文字列で探して、どちらで見つけたかを指摘一覧に残します。

4番目の正規表現は、角括弧の中に数字・カンマ・ハイフン・空白だけが並ぶものに限ります。 「[mm]」「[注1]」のような単位や注記まで拾うと、存在しない番号が「一覧に無い引用」として出ます。拾った文字列は指摘一覧に残し、どの書き方を引用として読んだかを後から確かめられるようにします。

原稿の本文はAIに渡しません。 AIに渡すのは5番目で分けた参考文献の一覧と、書式の規定の表だけです。番号の対応は Apps Script の中で数え終わっているので、本文を外に出す理由がありません。

AIへ渡す前に整形する

1. 引用番号の範囲を展開する … [5-7] は 5, 6, 7 に、[2, 9] は 2 と 9 にする。全角のハイフンや波ダッシュもそろえる
2. 最初に引用された順を記録する … 番号ごとに、本文で初めて出た段落の位置を残す
3. 一覧の番号を数値にそろえる … [1]、1.、(1)、全角の数字を同じ数値として読む
4. 番号の対応を数える … 一覧に無い引用、引用されていない文献、番号の飛び、同じ番号の重なり、引用順との違い
5. 同じ文献の重複の候補を拾う … 一覧のうち、文字列がほとんど同じ2件を候補にする（決めるのは人）
6. 社内報告書の番号を照合する … 一覧の中の社内報告書の番号を、登録済みの番号の一覧と突き合わせる

1番目を間違えると、正しい原稿に大量の指摘が出ます。 範囲の展開を忘れると、[5-7] の6番が「引用されていない」になります。最初の数本の原稿で、Apps Script が拾った番号と、人が拾った番号を並べて確かめてください。

4番目の結果は、AIの校正とは別の欄に書きます。 番号の対応は式で出した事実で、AIの指摘と同じ欄に混ぜると、どちらが式でどちらがAIの判断なのかが見分けられなくなります。

AIに処理させる

させるのは、参考文献1件ずつについて、種類を見分け、社内の規定の型と比べて違うところを挙げ、直し方の案を書くことです。

最後の行は、1件ずつでは分からず、一覧全体を見て初めて分かるものです。 そのため、AIには一覧を1件ずつではなくまとめて渡し、文献ごとの指摘と一覧全体の指摘を分けて返させます。

2行目が、この構成でいちばん大事な線引きです。 欠けている巻・号を「おそらく 12(3)」と埋める案を出すと、著者がそのまま採ることがあります。直し方の案には、項目の場所を空欄で示すだけにします。

指示内容を固定する

あなたは研究所の審査事務局で、研究報告書の参考文献の書き方を校正する担当です。
渡された参考文献の一覧を、社内の書式の規定の表に照らして校正してください。

【すること】
1. 文献1件ごとに、種類を次から1つ選ぶ:
   journal（雑誌論文）／book（図書）／patent（特許）／standard（規格）／
   internal（社内報告書）／web（Webのページ）／unknown（見分けられない）
2. その種類の規定の型と比べ、違うところを issues に挙げる:
   missing_field（必須の項目が無い）／order（項目の順番が違う）／
   punctuation（区切りの記号が違う）／author（著者名の書き方が違う）
3. 違うところごとに、直し方の案を suggestion に書く
4. 一覧全体を見て、書き方がそろっていないもの（同じ誌名の略称と正式名の混在など）を
   list_issues に挙げる

【厳守事項】
- 番号の対応（引用されているか、番号が飛んでいないか）は判断しないでください。
- 欠けている項目の値を推測で埋めないでください。巻・号・ページ・発行年・DOI・URL・
  閲覧日が書かれていなければ、suggestion では「（巻）」のように空欄で示してください。
- 文献が実在するか、内容が正しいかを判断しないでください。
- 規定の表に無い基準で指摘しないでください。好みの書き方を勧めないでください。
- 種類が見分けられない文献は unknown とし、issues は空にしてください。
- 違うところが無い文献は issues を空にしてください。指摘を作り出さないでください。
- original には、渡された文字列をそのまま写してください。

【書式の規定の表】
{style_rules}

【参考文献の一覧】（番号と文字列）
{references}

「欠けている項目を推測で埋めない」を、項目の名前を並べて書きます。 「推測しない」とだけ書くと、よく知られた論文の巻やページを、記憶から埋めた案を出すことがあります。 それが合っていても、書誌を確かめたのは著者ではなくなります。

「指摘を作り出さない」も明記します。 校正の役割を与えると、規定どおりの文献にも何か直すところを探します。指摘が無いことも答えの1つだと書いておきます。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは output_config.format に渡し、オブジェクトにはすべて additionalProperties: false を付けます。

{
  "references": [
    {
      "ref_no": 12,
      "type": "journal | book | patent | standard | internal | web | unknown",
      "original": "",
      "issues": [
        { "kind": "missing_field | order | punctuation | author",
          "detail": "ページ範囲が無い", "suggestion": "…，12(3)，（始ページ）-（終ページ）．" }
      ]
    }
  ],
  "list_issues": [
    { "ref_nos": [3, 17], "detail": "同じ誌名が略称と正式名で書かれている" }
  ]
}

JSONで受ける1つ目の理由は、指摘一覧のシートに1行1指摘で並べられることです。 ref_no で番号の対応の結果と同じ行にまとめ、事務局が文献ごとに「番号の問題」「書き方の問題」を横に並べて見られます。

2つ目は、kind で指摘の種類を数えられることです。 毎月の指摘を kind ごとに数えると、どの規定が守られにくいかが分かります。missing_field の閲覧日ばかりなら、規定の書き方より、研究員への周知が先です。

Apps Script は、番号の対応の結果を次の形でシートに書きます。

「出どころ」の列は必ず持ちます。 式で出した指摘は外す理由がほとんど無く、AIの指摘は外すことがあります。同じ確かめ方をしないためです。

システムへ連携する

原稿には書き込みません。 コメントを自動で付けることもできますが、事務局が外した指摘まで原稿に残ってしまいます。 確定した指摘だけをメールで伝え、直すのは著者です。

メールは下書きまでにします。 送るのは事務局の担当です。審査の前の指摘は、研究員にとっては差し戻しと同じ重さがあります。 誤った指摘を自動で送ると、事務局への信頼が下がります。

人が確認する

1. 番号の対応の指摘を確かめる … 出どころが script のものです。uncited は、図や表の説明の中で引用されていることがあるので、原稿で確かめます
2. AIの書き方の指摘を確かめる … 規定の表に照らして当たっているかを見ます。外したものは「外す」とし、理由を一言残します
3. unknown の文献を見る … 種類が見分けられなかったものは、規定のどの型に寄せるかを事務局が決めます
4. 重複の候補を見る … 同じ文献が2つの番号で載っていないかを確かめます
5. メールの下書きを確かめて送る

1番目の注意は、本文の読み方の限界から来ています。 Apps Script が読むのは本文の段落で、図や表のキャプションに書かれた引用は、原稿の作り方によっては拾えません。 その場合は uncited が出ます。

再提出の原稿では、見る範囲を絞ります。 前回の指摘のうち「直っていない」と出たものと、新しく出た指摘だけを見ます。直ったと出たものは、一覧で件数を確かめるだけにします。 番号がずれた原稿でも、比べるのは文献の文字列なので、前回の指摘と今回の指摘は対応が付きます。

目標は、1本15分です。 指摘一覧を上から見て、判断の列を埋め、下書きを直して送るまでです。15分で終わらない原稿は、たいてい unknown が多いか、一覧の切り出しに失敗しています。

例外に対処する

上の2行は、運用の最初の月に集中して出ます。 原稿の書き方が研究員ごとに違い、見出しの付け方と共有の手順がそろうまでは、事務局に回る件数が多くなります。 2か月目からは減ります。

記録を残す

• 依頼ごとに、原稿のURL、依頼者、初回か再提出か、読んだ時点の原稿の版の日時
• Apps Script が拾った引用番号と、切り出した参考文献の一覧
• 番号の対応の結果と、Claude API の返したJSONの全文
• 事務局が外した指摘と、その理由
• 送ったメールの日時と、再提出の後の「直った／直っていない」の結果
• kind ごとの月の件数

4つ目が、規定の表を直す材料になります。 同じ種類の指摘が毎月外されているなら、規定の表の書き方が実際の運用とずれています。 表を直すと、AIの指摘も同時にそろいます。

原稿の版の日時を残すのは、Google ドキュメントが送信の後も書き換えられるからです。 指摘と原稿の対応を後から確かめるには、どの時点の原稿を読んだかが要ります。