社内の研究テーマの申請書を評価の基準に照らして読み、審査会の前に論点と記載の不足のコメントを作る

処理の起点を決める

申請書のライブラリにファイルが作成されたときに動かします。 「ファイルの作成時 (プロパティのみ)」のトリガーを使い、ライブラリの列に持たせたテーマ番号、申請の種類（新規・継続）、申請者、審査会の開催月を受け取ります。これらの列は、申請者がファイルを置くときに入力する決まりにします。

PDFだけを対象にします。 Wordのファイルが置かれたら処理せず、「PDFにして置き直してください」と申請者へ返します。Wordのままだと変更履歴やコメントが残っていることがあり、 どれが申請の本文か分からなくなるためです。PDFにする時点で、申請者が最終の版を決めることになります。

同じテーマ番号で2つ目のファイルが置かれたら、差し替えとして扱います。 前のファイルの判定は残したまま、新しいファイルで判定し直し、一覧には新しい版の結果を出して、前の版との差を補足の依頼の確認に使います。

審査会の10日前を、置く期限にします。 期限を過ぎたファイルも処理しますが、一覧に「期限後」の印を付けます。事前の読み込みに使える日数が短いことを、担当者が一目で分かるようにするためです。

入力データを集める

質を決めるのは、評価の基準の観点の書き方です。 「新しさがあること」のような書き方では、何が書かれていれば足りるかが決まりません。「先行技術または社内の過去のテーマを1つ以上挙げ、それとの違いを述べていること」のように、記載の有無で判定できる文に直します。 この書き直しが、導入でいちばん時間のかかる作業です。

前回の議事録は、テーマ番号で該当部分だけを切り出して渡します。 審査会1回分の議事録をすべて渡すと、他のテーマへの指摘を、このテーマへの指摘と取り違えるおそれがあります。

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

前回の議事録は、審査会のあとに事務局がテーマ番号ごとの行にしておきます。 議事録の文書から毎回切り出すより、審査会の直後に「テーマ番号・指摘・条件」の行で残すほうが、引き当てが確実です。 この行づくり自体も、議事録からの下書きをAIに作らせて事務局が確かめる形にできます。

PDFは、文書のブロックとしてそのまま渡します。 公式の案内は、リクエストの中でPDFを文章より前に置くことを勧めています。指示の文は、申請書のPDFのあとに置きます。

AIへ渡す前に整形する

1. 形式の確認 … PDFであること、パスワードや暗号化が無いことを確かめます
2. 大きさの確認 … 32MBとページの上限に収まるかを確かめます。添付の資料が大きいものは、本文と添付を分けて置いてもらいます
3. 様式の確認 … 様式の章の見出しがそろっているかを確かめます。古い様式で書かれた申請書は、様式の更新を申請者に頼みます
4. 申請の種類の確認 … 継続なのに前回の議事録の行が無い場合は、事務局に知らせます
5. 評価の基準の版の固定 … どの版の基準で判定したかを記録するため、基準の文書の版を控えます
6. 単価の表の版の固定 … 同じく、検算に使った単価の版を控えます

3番目を軽く見ないでください。 様式の古い申請書では、「事業への効き方」の章が無く、背景の章に混ざって書かれていることがあります。AIは混ざった記載も拾えますが、根拠のページがばらけ、担当者の確認が遅くなります。 様式をそろえてもらうほうが早く済みます。

5番目と6番目は、後から判定をたどるためです。 評価の基準は年に1〜2回見直されます。見直しの前後で同じ申請書の判定が変わったとき、どちらの基準で判定したかが残っていないと説明できません。

AIに処理させる

させるのは、観点ごとに記載を4つの区分に分け、根拠のページと文を書き出し、数字を取り出すことです。

missing と inconsistent の区別が、この構成でいちばん大事です。 前者は申請者に「書いてください」と頼むもの、後者は審査会で「どちらが正しいですか」と確かめるものです。混ぜると、書いてあるのに「書いてください」と返され、申請者が事務局を信用しなくなります。

4つの基準で、AIが見る観点の例は次のとおりです。

4行目がいちばん起きやすい失敗です。 背景の章に「既存の手法では耐熱性が不足する」と1文あれば、AIは先行技術との違いが述べられていると読みがちです。どの先行技術と比べたのかが無ければ、観点には答えていません。 指示で、観点の文を1語ずつ満たしているかで判定するよう求めます。

指示内容を固定する

（申請書のPDFを先に置く）

あなたは研究テーマの審査会の事務局として、申請書を事前に確認します。
テーマの良し悪しを評価する役目ではありません。
評価の基準の観点ごとに、それに答える記載が申請書にあるかを判定してください。

【評価の基準と観点】{criteria}
【申請の種類】{new_or_continuation}
【前回の審査会での指摘（継続のみ）】{previous_findings}

【status の選び方】
- sufficient ..... 観点の文が求めることすべてに答える記載がある
- partial ........ 記載はあるが、観点の一部にしか答えていない
- missing ........ 観点に答える記載が見当たらない
- inconsistent ... 記載はあるが、別の章の記載と食い違う
迷ったときに sufficient を選ばないでください。

【厳守事項】
- 観点の文を1語ずつ満たしているかで判定してください。
  関係のありそうな記載があるだけで sufficient にしないでください。
- evidence には、根拠にしたページ番号と、申請書の文をそのまま写してください。
  要約や言い換えをしないでください。missing のときは空にしてください。
- inconsistent のときは、食い違う2か所の evidence を両方入れてください。
- 予算・人員・期間の数字は、書かれているとおりに figures に取り出してください。
  計算や合計をしないでください。
- テーマの採否、点数、優先順位を書かないでください。
- 本当に新しいか、事業の見込みが妥当かは判断しないでください。
- 申請者や研究員の能力について書かないでください。
- 継続の申請では、前回の指摘ごとに、回答する記載があるかを判定してください。
- discussion_points には、審査会で確かめるべき問いを、問いの形で書いてください。

「迷ったときに sufficient を選ばない」を明記しないと、AIは関係のありそうな記載を好意的に読みます。この確認の目的は、審査会の前に足りないものを見つけることで、申請書を褒めることではありません。

「数字の計算をしない」も同じ理由です。 AIに人件費の合計を出させると、書かれていない端数を補って「合っている」と書くことがあります。取り出すのは書かれた数字だけにし、計算はフローで行います。

出力形式を固定する

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

{
  "theme_no": "",
  "application_type": "new | continuation",
  "criteria_version": "",
  "checks": [
    {
      "criterion": "novelty | business_impact | feasibility | resources",
      "viewpoint_id": "",
      "status": "sufficient | partial | missing | inconsistent",
      "evidence": [ { "page": 0, "quote": "" } ],
      "note": ""
    }
  ],
  "previous_findings_check": [
    { "finding_id": "", "status": "answered | partially_answered | not_answered",
      "evidence": [ { "page": 0, "quote": "" } ] }
  ],
  "figures": {
    "members": [ { "grade": "", "count": "", "months": "" } ],
    "personnel_cost": "",
    "equipment_cost": "",
    "total_budget": "",
    "period_months": ""
  },
  "discussion_points": [""]
}

1つ目の理由は、status を観点ごとに enum で持てることです。 一覧で missing だけを集めれば補足の依頼に、partial と inconsistent を集めれば論点のメモになります。下書きを作る2回目の呼び出しには、この区分だけを渡します。

2つ目は、evidence にページと原文を持たせることです。 担当者は一覧からページ番号で申請書を開き、AIの判定が原文のどこに基づいているかを数十秒で確かめられます。 フローは quote が申請書の文字に実在するかを照らし、実在しないものには印を付けます。

3つ目は、figures を文字列で受けることです。 構造化出力では数値の最小・最大の制約が使えないため、数字の妥当性はスキーマでは守れません。 書かれたままの文字列で受け取り、フローの側で数値に直して検算します。

差が1割を超えたら、inconsistent として論点のメモに足します。 1割の幅を持たせるのは、単価の表と申請者の見積りの細かな違いまで拾うと、論点が数字の端数で埋まるためです。

システムへ連携する

申請者への補足の依頼は、自動では送りません。 下書きは一覧に置き、担当者が確かめて加筆してから送ります。 研究員にとって、審査の事務局からの指摘は重いものです。誤った missing が1件混ざった依頼が届くと、以後の依頼が読まれなくなります。

審査委員への論点のメモも、担当者が確かめてから渡します。 論点のメモは審査会の議論の出発点になります。AIの問いがそのまま議論の筋を決めることのないよう、担当者が並べ替えと削除を行います。

人が確認する

研究企画室の担当者は、次の順で一覧を見ます。

1. missing の根拠を確かめる … 本当に書かれていないかを、申請書の該当しそうな章で確かめます。ここが補足の依頼になるので、最も慎重に見ます
2. inconsistent と検算の差を確かめる … 2か所の原文を並べて読みます
3. 継続のテーマの not_answered を確かめる … 前回の指摘を議事録の原文で読み直します
4. 中身を読む … 記載がそろった観点について、技術と事業の筋を担当者の目で読み、所見を足します
5. 下書きを直して送る … 補足の依頼は申請者へ、論点のメモは審査委員へ

4番目が、この構成で担当者の時間を移したい先です。 これまで①の記載探しに使っていた時間を、記載の中身を読む時間に回します。 AIの判定は、その前の下ごしらえです。

目標は、30件をならして1件50分です。 そのうち40分が判定の確認と中身の読み込み、10分が下書きの仕上げという想定です。新規のテーマは継続より長く、記載の不足が多い申請書は60分を超えます。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの問題ではなく、申請書の置き方と様式の問題です。 申請の手引きに「PDFで、最新の様式で、本文と添付を分けて」と書くほうが、判定の精度を上げるより効きます。

6行目の扱いが大事です。 原文に無い文を根拠にした判定は、捨てるのではなく partial に下げて人に回します。判定そのものが誤りとは限らず、引用の写し方だけがずれていることがあるからです。

記録を残す

• 申請書のPDF（版ごと）と、置かれた日時
• 判定に使った評価の基準と単価の表の版
• Claude API の応答のJSONと、引用の照合と検算の結果
• 補足の依頼と論点のメモの、下書きと送った版
• 担当者が判定を覆した記録（どの観点を、どの区分に変えたか）
• 審査会の結果（採択・条件付き・持ち越し）と、論点のメモの問いが議論に使われたか

最後の行は、この構成を育てる材料になります。 審査会で使われなかった問いが多いなら、論点の出し方を直します。審査会の場で新たに見つかった記載の不足は、AIが見落とした観点として、評価の基準の観点の書き方を見直す材料にします。