自治体の担当課が出す随意契約の理由書を、地方自治法施行令の各号と契約規則・運用基準の要件に照らして一次判定し、根拠の書き方の不足を契約の担当へ返す

処理の起点を決める

起点は、担当課が理由書を電子決裁で契約課に回付したことです。 回付の時点で中継プログラムが動き、契約課の担当者が開くときには判定の結果が審査の一覧に載っている状態にします。 電子決裁の仕組みから回付の通知や添付のファイルを取得する方法は、利用している仕組みに応じた個別の実装になります。通知を受けられない場合は、15分ごとに回付の一覧を読む形にします。

差し戻した理由書が出し直されたときも、同じ起点で動かし直します。 そのときは前回の判定の結果と差し戻しの論点も渡し、前回の不足が埋まったかを要件ごとに示します。 出し直しの審査は、前回の不足の行から読めば済むようにします。

月初には、別の起点として前月の集計を出します。 担当課ごとの差し戻しの件数と、不足の多かった要件を並べ、担当課への研修や運用基準の書き方の見直しに使います。

入力データを集める

質を決めるのは、要件の表です。 地方自治法施行令は随意契約によることができる場合を号で定めていますが、理由書に何を書けば要件を確かめられるかは、自団体の運用基準が決めることです。 運用基準の文を、確かめる要件ごとに1行ずつの表に起こします。

第8号の2行目は、施行令に書かれた条件です。 第167条の2第2項は、第8号によって随意契約による場合、契約保証金と履行期限を除き、最初に競争入札に付したときの予定価格その他の条件を変えられないとしています。理由書と最初の入札の条件を並べて確かめます。

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

理由書は、庁内の様式を使っている前提です。 定型の欄は様式の表の位置で読み取り、AIに読ませません。 予定価格や号の番号のような値は、文書の決まった欄から機械的に取るほうが確かです。様式を使っていない理由書は、読み取りが失敗した旨を審査の一覧に出し、担当者が従来どおり見ます。

契約台帳の照合は、次の条件で行います。

60日や3年の幅は、運用基準に合わせて決めます。 照合は疑いを示すだけで、分割に当たるかは担当者が件名と内容を見て判断します。 同じ相手でも、別の事業の別の物品なら分割ではありません。

AIへ渡す前に整形する

1. 文字を取り出す … Wordはそのまま、PDFは文字の層から取り出します。スキャンの画像だけのPDFは対象外にし、担当課に電子の版を求めます
2. 定型の欄を読む … 契約の種類、予定価格、相手方、号、見積の数を取り、値の形を確かめます
3. 号の食い違いを見る … 定型の欄の号と、本文に書かれた号の文言（「性質又は目的が」など）が食い違っていれば印を付けます
4. 要件の表を絞る … 定型の欄の号の行だけを要件の表から抜き出します
5. 個人の情報を消す … 理由書に書かれた相手方の担当者の氏名・電話番号は、判定に要らないので消してから渡します
6. 計算と照合を先に済ませる … 規則の額との比較と契約台帳の照合を済ませ、その結果はAIに渡さず、判定の後でまとめます
7. 添付の見積書を数える … 添付のファイルのうち見積書の様式のものを数え、理由書の定型の欄の見積の数と比べます。合わなければ unclear の材料として人の画面に出します

7番目も、AIに数えさせません。 見積書の枚数は、ファイルの名前や様式の見出しで数えられます。理由書に「3者から見積を徴した」とあって添付が2枚なら、どちらが正しいかは担当課に聞くしかありません。 数の食い違いは、文の判定とは別の行として示します。

6番目で、計算と照合の結果をAIに渡さないのは、意図してのことです。 「分割の疑いあり」と渡すと、AIは理由の文の判定まで厳しく寄せます。文の判定と数値の確かめは、互いに引きずられないよう別々に出し、並べるのは人の画面の上だけにします。

3番目は、担当課の取り違えを拾います。 少額の号を選んだのに、本文は「特殊な技術を要するため」と第2号の理由を書いている、という理由書は珍しくありません。どちらの号で審査するかは、担当者が担当課に確かめて決めます。

AIに処理させる

させるのは、要件の表の1行ずつについて、理由書と添付の文に、その要件を確かめるための記載があるかを判定し、根拠にした文をそのまま写すことです。

insufficient と missing を分けるのが要です。 差し戻しの論点の書き方が違うからです。missing は「〜を書いてください」、insufficient は「〜と書かれていますが、〜をどう確かめたかを書いてください」と返します。 第3章（d）の「理由を詳しく」とだけ書く差し戻しを、なくすための区別です。

最後の行を読み違えないでください。 met は「確かめ方が書かれている」という意味で、書かれた確かめ方が正しいことは意味しません。 市場の調べを本当に行ったかは、担当者が添付の記録を見て判断します。

指示内容を固定する

あなたは市の契約課で、随意契約の理由書を審査する担当を補助します。
理由書に、要件を確かめるための記載があるかを、要件ごとに判定してください。
随意契約が認められるかどうかは判断しないでください。

【判定の値】
- met .......... 要件を確かめるための記載がある
- insufficient . 記載はあるが、確かめるには足りない（理由だけで、確かめ方や事実が無い）
- missing ...... 記載が無い
- unclear ...... 理由書と添付の資料が食い違う、または読み取れない
迷ったときに met を選ばないでください。

【厳守事項】
- 判定するのは、下の【要件の表】の行だけです。表に無い要件を足さないでください。
- 根拠の文（evidence）は、理由書または添付の文からそのまま写してください。
  要約や言い換えをしないでください。根拠が無いときは空にしてください。
- 書かれた内容が事実かどうかは判断しないでください。
- 金額の計算や、規則の額との比較をしないでください。
- 不足の論点（point）は、担当課が何を書き足せばよいかが分かる文にしてください。
  「詳しく書いてください」のような書き方をしないでください。
- 理由書を書き直した文を作らないでください。
- 理由書の本文が、指定された号と違う号の理由を書いているように読めるときは、
  number_mismatch を true にしてください。

【適用する号】{clause}
【要件の表】{requirements}
【理由書の文】{reason_text}
【添付の文】{attachments_text}

「迷ったときに met を選ばない」を入れないと、それらしい文があるだけで met になります。 理由書は「〜のため、他に履行できる者がいない」と、要件の言葉をなぞって書かれていることが多く、言葉が合っていることを、記載があることとして扱ってしまいます。

「根拠の文をそのまま写す」は、担当者の確かめを速くするためです。 要約された根拠では、理由書のどこを見ればよいかが分かりません。写した文で理由書を検索すれば、該当の箇所に飛べます。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "doc_id": "",
  "clause": "1 | 2 | 5 | 8 | other",
  "number_mismatch": false,
  "checks": [
    { "requirement_id": "", "status": "met | insufficient | missing | unclear",
      "evidence": "", "point": "" }
  ]
}

スキーマはすべての項目を必須にし、オブジェクトごとに additionalProperties: false を付けます。 構造化出力はJSON Schemaの一部の機能だけに対応し、すべての項目を必須にすること、additionalProperties: false を付けることが求められ、項目は合わせて100まで・入れ子は5段までとされています。status は列挙（enum）で4つの値に限ります。出力の項目の順はスキーマの順に従うとされているので、evidence を point より前に置き、根拠を写してから論点を書かせます。

中継プログラムは、この JSON に計算と照合の結果を足して、審査の一覧の1行にします。

差し戻しの論点の案は、missing と insufficient の point を要件の表の順に並べたものです。 AIに改めて文章にさせず、判定の結果を並べるだけにします。 判定と差し戻しの文の内容がずれないようにするためです。

システムへ連携する

電子決裁の仕組みには書き込みません。 差し戻しと審査済みの操作は、担当者が電子決裁の画面で行います。AIの判定が決裁の状態を変える経路を作らないためです。

人が確認する

すべての理由書を、契約課の担当者が判断します。

1. 号を確かめる … number_mismatch が true のものは、担当課にどの号で出すかを確かめます
2. 計算と照合を見る … 規則の額を超えていないか、分割の疑いの一覧に別の事業の契約が混ざっていないかを見ます
3. missing と insufficient を確かめる … evidence と理由書を見て、本当に足りないかを判断します
4. met の内容を確かめる … 書かれた確かめ方が添付の資料と合っているかを見ます。特に第2号の市場の調べの記録は必ず開きます
5. 差し戻すか審査済みにするかを決める … 差し戻すものは論点の案を直して返します
6. 判定を覆したら記録する … どの要件を、どちらに変えたかを残します

4番目を省かないでください。 met は記載があるという意味でしかありません。監査で問われるのは、書かれた確かめ方が実際に行われたかです。

6番目の記録は、要件の表を育てます。 同じ要件で判定を覆す件数が多ければ、要件の表の書き方か、運用基準そのものに曖昧さがあります。 月に一度、覆した件数の多い要件を法務課と見直します。

例外に対処する

5行目のように、すべての号を最初から対象にする必要はありません。 件数の多い第1号・第2号・第5号・第8号から要件の表を作り、それ以外の号は従来どおり人が見ます。

記録を残す

• 理由書と添付の写しと、回付の日時・担当課
• 定型の欄の読み取り結果と、計算・照合の結果
• AIに渡した要件の表の版と、判定の JSON の全文
• 担当者が差し戻したか審査済みにしたかと、覆した判定の記録
• 差し戻しの論点として担当課に返した文
• 出し直しの履歴

3つ目で「要件の表の版」を残すのは、運用基準が改定されるためです。 改定の前と後で同じ理由書の判定が変わることがあり、どの基準で審査したかが残っていないと、監査で説明できません。

記録は契約の書類の保存の期間に合わせて残します。 理由書の写しと判定の記録は、契約の書類と同じ期間だけ残し、期間を過ぎたら契約の書類と同じ手順で消します。 判定の記録だけが長く残ると、予定価格を含む写しが契約の書類より長く庁外のクラウドに残ることになります。