公的研究費から支出する購入・出張・謝金の申請を、配分機関の使用ルールと機関の規程に照らして一次判定し、確認が要る点を経理へ返す

処理の起点を決める

定時の実行にします。1日に2回、昼と夕方です。 申請のたびに動かす方法もありますが、研究者は同じ日に申請を出し直したり、添付を足したりします。数時間ためてから見るほうが、出し直しの前の版を点検する無駄が減ります。

年度末の繁忙期だけ、回数を増やします。 補助金では納品が年度の3月31日までなので、2月から3月は申請から納品までの余裕が短くなります。 1日4回にして、問い合わせが早く研究者に届くようにします。

処理が終わった申請には、点検した日時と使ったルールセットの版を付けます。 出し直された申請は、版の付いていない新しい申請として扱います。

入力データを集める

質を決めるのは、研究課題の一覧とルール集です。 一覧に財源の区分が無ければ、正しいルールセットを選べません。ルール集が古い版のままなら、改正された条項で誤った判定になります。

過去の判断の記録は、機関の解釈を伝えるために持ちます。 「研究室で使う机」を機関として認めてきたのか、通常備えるべき物として差し戻してきたのか。使用ルールの文言だけでは決まらない部分を、機関の過去の判断で補います。 渡すのは、同じ条項の記録だけに絞ります。

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

財務会計システムから、前回の実行の後に申請・更新されたものを書き出します。 CSVの書き出しかAPIで取り出せるかは、使っているシステムで確かめます。取り出せない場合は、書き出したファイルを決まったフォルダに置く運用にします。

ルール集の表は、人が作ります。 使用ルールのPDFを条項ごとに切り、rule_set（例：kaken_hojo_2026 ／ kaken_kikin_2026）、条項番号、見出し、本文、適用する費目を列に持たせます。条項の番号は財源で違うので、番号ではなく rule_set と見出しの組で引きます。

AIへ渡す前に整形する

1. ルールセットの選択 … 研究課題の一覧の財源の区分と年度から rule_set を決めます。区分が空なら、AIに渡さずに review にします
2. 研究期間の判定 … 申請日と納品予定日・出張の期間が研究期間に入っているかを、日付で見ます
3. 年度を越える納品の判定 … 補助金のルールセットで、納品予定日が年度の3月31日を越えるものに印を付けます
4. 本人への謝金・人件費の判定 … 謝金・人件費の相手方を、研究代表者と分担者の名簿と突き合わせます。氏名の表記ゆれは職員番号で合わせます
5. 合算の有無の確認 … 財源が複数入っている申請に印を付けます
6. 添付の確認 … PDFが開けるか、パスワードが掛かっていないかを見ます。Claude API が扱えるのはパスワードや暗号化の無い標準のPDFです
7. 渡す条項の絞り込み … 費目に関係する条項だけをルール集から選びます。全条項を毎回渡しません

2番目から4番目の結果は、AIに渡す前に確定させます。 AIには「この申請は研究期間内で、謝金の相手は名簿に無い」と事実として渡し、同じことを推し量らせません。

AIに処理させる

させるのは、渡した条項の1つずつについて、この申請が当てはまるか、情報が足りないかを判定し、根拠にした文を写すことです。

suspect と needs_info の区別が、この構成の中心です。 suspect は書かれた内容から使えない経費に当たる疑いがあるということ、needs_info は判断に要る情報が書かれていないということです。前者は経理の確認、後者は研究者への問い合わせに回ります。

出張の4項目は、文部科学省のガイドラインから来ています。 研究機関における公的研究費の管理・監査のガイドラインは、出張計画の実行状況の把握に当たって、用務内容、訪問先、宿泊先、面談者等が確認できる報告書等の提出を求め、重複受給がないかも含めて確認するとしています。換金性の高い物品は、購入したことの明示と所在の記録で管理し、特にパソコンは適切に管理することが望ましいとされています。

2行目を外さないでください。 点検の結果は研究者の目にも触れます。情報が足りないだけの申請に「不正」の語が付けば、点検そのものが信頼を失います。

指示内容を固定する

あなたは研究機関の研究推進課で、公的研究費の支出申請を点検する担当者の補助です。
渡された申請・添付・条項だけを見て、条項ごとに判定してください。

【判定の対象】
渡された条項（rule_set と見出しで示します）の1つずつについて、この申請が
当てはまるか、判断に要る情報が足りないかを判定します。
渡されていない条項や、一般的な知識を根拠にしないでください。

【status の選び方】
- ok ............. 条項に照らして問題になる記載が無く、判断に要る情報もそろっている
- needs_info ..... 判断に要る情報が申請にも添付にも書かれていない
- suspect ........ 書かれた内容から、条項に当てはまる（使えない経費に当たる）疑いがある
- not_applicable . この申請の費目には関係しない条項
迷ったときに ok を選ばないでください。

【厳守事項】
- 書かれていない情報を推測で埋めないでください。用途、面談者、宿泊先などが
  書かれていなければ needs_info とし、missing_items に欠けている項目を書いてください。
- 情報が足りないことを、suspect の理由にしないでください。
- 「不正」「不適切」という語を使わないでください。
- 支出を認めるか、差し戻すべきかを書かないでください。
- 研究の必要性や研究の価値を評価しないでください。
- evidence には、根拠にした申請・添付・条項の文をそのまま写し、
  どこから写したか（application / attachment / rule）を書いてください。
- 前処理の結果（研究期間、年度を越える納品、本人への謝金）は確定した事実です。
  判定し直さないでください。
- 過去の判断の例は、同じ条項の解釈の参考にしてください。
  例と食い違う判定をするときは、その理由を reason に書いてください。
- 申請と添付で金額・数量・日付・品名が食い違えば、条項とは別に mismatches に書いてください。

【申請】{application}
【添付のPDF】（document として渡す）
【前処理の結果】{precheck}
【条項】{rules}
【過去の判断の例】{precedents}

「情報が足りないことを、suspect の理由にしない」が最も効く1文です。 これが無いと、研究課題との関係が書かれていないパソコンの購入を「通常備えるべき物に当たる疑い」と判定します。書いていないことと、使えないことは別です。

「渡されていない条項を根拠にしない」も外せません。 AIは研究費の一般的な知識を持っており、何も言わなければ他の配分機関のルールや古い版の記憶で判定します。根拠を、渡した表の版に閉じ込めます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。 output_config.format に type: "json_schema" とスキーマを指定すると、返答がスキーマに沿ったJSONになります。

{
  "application_id": "",
  "rule_set": "kaken_hojo_2026 | kaken_kikin_2026 | other",
  "checks": [
    { "rule_id": "", "rule_heading": "",
      "status": "ok | needs_info | suspect | not_applicable",
      "reason": "",
      "missing_items": [],
      "evidence": [ { "source": "application | attachment | rule", "text": "" } ] }
  ],
  "mismatches": [ { "field": "", "application_value": "", "attachment_value": "" } ],
  "asset_control_flag": false,
  "question_draft": ""
}

status を enum にして、4つ以外の値を返させません。 構造化出力のページでは、enum の大文字・小文字は保証されないとされているので、受け取った側で小文字にそろえてから比べます。 数値の範囲や文字数の制約はスキーマに書けないので、evidence が空でないかはプログラムで確かめます。

振り分けは、AIの出力を受けてプログラムが決めます。

review を先に判定するのが大事です。 suspect と needs_info が両方あるとき、研究者への問い合わせだけで終わらせず、必ず担当者が見る列に入れます。

asset_control_flag は振り分けに使いません。 換金性の高い物品は使えない経費ではなく、管理の手続きが要るだけなので、pass のものにも付けて、購入の後に管理の表示と所在の記録を案内します。

システムへ連携する

財務会計システムに書き込まないのは、承認の経路を変えないためです。 点検の結果は一覧に出し、支出の承認は今までどおりシステムの上で人が行います。

問い合わせの下書きは、needs_info と mismatches だけから作ります。 suspect の内容は研究者への文面に入れません。疑いを確かめるのは担当者で、研究者に何を聞くかは担当者が決めます。

人が確認する

担当者が開くのは review と ask_researcher です。 pass は一覧で件数・研究者・金額を流し見て経理課へ回します。

1. review を先に見る … suspect の根拠の条項と、写された文を読みます。添付の該当箇所を開いて確かめます
2. 過去の判断と比べる … 同じ条項で機関がどう判断してきたかを見ます。食い違うなら課長に相談します
3. ask_researcher の下書きを直して送る … 欠けた項目が本当に欠けているかを確かめてから送ります
4. 判断を記録する … 認めた・差し戻した・研究者に確かめたの別と理由を、条項ごとに残します。次の判定の「過去の判断の例」になります

4番目を省くと、この構成は育ちません。 機関の解釈は、使用ルールの文言ではなく、担当者の判断の積み重ねにあります。記録した判断が次の点検で例として渡り、担当者による違いが減っていきます。

pass の流し見でも、高額のものは開きます。 金額の線を機関で決め、それを超えるものは pass でも担当者が中身を見ます。

例外に対処する

上の2行が、運用の大半を占めます。 どちらもAIの問題ではなく、研究課題の一覧とルール集の手入れの問題です。 年度の初めに一覧を更新し、改正のたびにルール集を足す作業を、担当を決めて回します。

記録を残す

• 申請番号ごとに、点検に使った申請の項目と添付のファイル名
• 前処理の結果（研究期間・年度越え・本人への謝金・合算）
• 使ったルールセットの版と改正日、渡した条項の一覧
• AIが返したJSONの全文
• 振り分けの結果と、担当者の判断とその理由（条項ごと）
• 研究者への問い合わせと回答、出し直しの記録

3つ目が、後で説明するときの支えです。 監査で「なぜこの支出を認めたか」と聞かれたとき、その日にどの版のルールで点検したかが分からないと答えられません。 改正の前後で判定が変わった申請も、版が残っていれば追えます。

担当者の判断の記録は、条項ごとの差し戻しの率として月に1回集計します。 特定の条項で needs_info が多いなら、申請の画面の入力欄の作りか、研究者への案内に原因があります。