自治体の担当課が業務委託を発注する前に、過去の仕様書と事業の要綱から委託仕様書の下書きを作り、競争性を損なう記載と抜けやすい項目を契約の担当へ挙げる

処理の起点を決める

担当課の職員が、作成の依頼の画面から依頼を送ったときに動かします。 事業名、要綱、予算の説明、委託の種類（施設管理／窓口／調査・計画／イベント運営／システム保守 など）を選び、今回の期間・場所・数量・回数を入力します。入力が無い値は空のまま送れるようにし、下書きでは【担当課記入】になります。

担当課が下書きを直した後に、候補の点検だけをもう一度動かせるようにします。 担当課が書き足した部分に、新たに特定の製品名などが入ることがあるためです。決裁に回す前に一度、点検だけを動かすのを手順にします。

契約課への回付をきっかけには動かしません。 契約課が見るのは、担当課が直して候補に答えた後の版です。契約課の手元で初めて候補が出る形にすると、往復が減りません。

入力データを集める

質を決めるのは、下の2つです。 ひな形が古いと、下書きも古い書き方になります。点検の観点が無いと、生成AIは何を挙げればよいかが分かりません。契約課が、差し戻しの実績から観点の表を作ります。

予定価格や積算の内訳は渡しません。 仕様書の下書きには要らず、渡すと下書きや候補の文に金額が混ざるおそれがあります。 予算額は「あり／なし」だけを持たせます。

点検の観点の区分は、たとえば次のように作ります。

4行目と6行目は、公正取引委員会の調査報告書が取り上げた論点に近いものです。 報告書は、官公庁が仕様書を作る際にその仕様が特定の事業者の技術又は製品に依存している場合、ベンダーロックインにつながりかねないとして、市場で容易に取得できるオープンな標準的技術又は製品を用いることなどを挙げています。報告書は情報システムの調達を対象にしていますが、現行の受託者だけが知っている情報に寄りかかった仕様は、ほかの業務委託でも同じ形で起きます。

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

過去の仕様書は、事業名と委託の種類で選びます。 言葉の近さで探すと、名前は似ているが中身の違う事業の仕様書が混ざります。同じ事業の直近1件と、同じ委託の種類の他の課の2件までに絞り、どれを使ったかを記録します。

文書管理の仕組みからの取り出し方は、導入している製品によって違います。 仕様書がPDFで登録されている場合は文字として取り出せるかを確かめ、スキャンした画像だけのものは対象から外します。この部分は個別の実装が必要です。

AIへ渡す前に整形する

1. 過去の仕様書の章分け … 過去の仕様書を、庁内のひな形の章に対応させて分けます。対応する章が無い記載は「その他」に寄せ、下書きで扱いを決めます
2. 固有の名前の伏せ … 過去の仕様書に書かれた前回の受託者の名前、担当者の氏名・連絡先を伏せます。伏せた箇所は「前回の受託者名」のような印にします
3. 日付・金額の印 … 過去の仕様書の日付・期間・金額・数量に印を付けます。生成AIはこれらを今回の値として写さず、今回の依頼の値か【担当課記入】にします
4. 要綱の条の番号付け … 要綱を条ごとに分け、下書きの根拠として番号で示せるようにします
5. ひな形の必須項目の一覧化 … 必須項目を番号付きで持ち、後の照合に使います

2番目は、点検とも関わります。 前回の受託者の名前を伏せても、その事業者の製品名やサービス名が業務の内容に残っていれば、点検の候補になります。 伏せるのは人や会社の名前で、製品名は伏せずに点検に回します。

AIに処理させる

させることは2つに分けます。 1つ目は仕様書の下書き、2つ目は競争性を損なうおそれのある記載の候補の一覧です。別々の呼び出しにして、下書きを書いた同じ流れで自分の下書きを点検させることはしません。

いちばん起きやすいのは、「させないこと」の表の4行目の失敗です。 過去の仕様書に「年4回」と書いてあると、生成AIはそれを今回の回数として写します。今回の予算で年4回できるかは担当課にしか分かりません。 日付・金額・数量に印を付ける前処理と、空欄にする指示の両方で防ぎます。

点検を別の呼び出しにする理由は、自分で書いた文を甘く見ないためです。 下書きの流れの中で点検させると、自分が書いた記載を問題なしとする傾向があります。点検の呼び出しには、下書きと過去の仕様書と観点の表だけを渡し、下書きを書いた経緯は渡しません。

指示内容を固定する

下書きの指示：

あなたは市の担当課の職員を手伝い、業務委託の仕様書の下書きを作ります。
下の材料だけを使い、庁内のひな形の章立てに沿って書いてください。

【書き方】
- 章ごとに、要綱・予算の説明・過去の仕様書から今回の事業に当てはまる記載を書いてください。
- 章ごとに、根拠にした要綱の条番号と、過去の仕様書の番号・章を sources に入れてください。
- 期間・場所・数量・回数・人数・金額は、「今回の条件」に書かれた値だけを使ってください。
  書かれていなければ【担当課記入】としてください。過去の仕様書の値を写さないでください。
- 過去の仕様書にあって、要綱にも今回の条件にも根拠の無い記載は、
  本文に残したうえで only_in_past を true にしてください。
- 伏せ字（【前回の受託者名】など）はそのまま残してください。
- 要綱に無い業務を足さないでください。
- 契約の方法、入札の参加資格の結論を書かないでください。

【ひな形の章立てと必須の記載】{template}
【要綱（条ごと）】{guideline}
【予算の説明】{budget_note}
【過去の仕様書（章ごと）】{past_specs}
【今回の条件】{conditions}

点検の指示：

あなたは市の契約の担当を手伝い、仕様書の下書きを点検します。
下の「点検の観点」に当てはまるおそれのある記載を、もれなく挙げてください。

【挙げ方】
- 当てはまるおそれのある文を、下書きから一字一句そのまま quote に写してください。
- category は観点の区分から1つ選んでください。
- reason には、なぜその区分に当たるおそれがあるかを1文で書いてください。
- question には、担当課に確かめたいことを問いの形で書いてください。
- 問題があると断定しないでください。「〜のおそれ」「〜か確認」で書いてください。
- 書き換えた文を提案しないでください。
- 迷ったものも挙げてください。挙げすぎは担当課の回答で整理します。

【点検の観点（区分と例）】{checkpoints}
【仕様書の下書き】{draft}
【過去の仕様書（参考）】{past_specs}

「迷ったものも挙げる」と書くのは、点検の側では見落としのほうが重いからです。 挙げすぎた候補は、担当課が「業務上必要」と1行書けば済みます。見落とした記載は、入札の後に参加できなかった事業者からの問い合わせで初めて分かります。

「書き換えた文を提案しない」のは、提案の文がそのまま仕様書に入るのを避けるためです。 生成AIの言い換えは、業務の実際を知らずに書かれます。担当課が問いに答え、その答えで自分の言葉で直します。

出力形式を固定する

下書きと点検で、それぞれ次の形のJSONを構造化出力で受け取ります。

{
  "request_id": "",
  "template_version": "",
  "sections": [
    {
      "section_code": "",
      "text": "",
      "sources": [""],
      "only_in_past": false,
      "placeholders": 0
    }
  ]
}

{
  "request_id": "",
  "findings": [
    {
      "section_code": "",
      "category": "product_spec | experience | region_license | incumbent_info | lead_time | compatibility | other",
      "quote": "",
      "reason": "",
      "question": ""
    }
  ]
}

1つ目の理由は、ひな形の必須項目と照合できることです。 section_code の一覧を必須項目の一覧と突き合わせ、足りない章があれば、担当課の画面の先頭に「抜けている項目」として出します。 第3章の（b）を、生成AIの書きぶりに頼らず機械で止めます。

2つ目は、quote が下書きの中に本当にあるかを確かめられることです。 候補の文が下書きの文字列に含まれていなければ、その候補は捨てます。生成AIが言い換えて写した候補は、担当課がどこを直せばよいか分からなくなるためです。

3つ目は、category で集計できることです。 区分ごとの候補の数と、担当課が「直した」「業務上必要」と答えた数を数えると、どの観点で差し戻しが多いかが分かり、ひな形と観点の表を直す材料になります。公式のページでは、出力の項目の順はスキーマの順に従うとされているので、項目は担当課の画面に出す順に並べておきます。

システムへ連携する

下書きは、文書作成ソフトの形式に書き出して担当課に渡します。 章の見出しと【担当課記入】の箇所を目立つ書式にし、候補の文には該当の箇所に印を付けます。 担当課は、ふだん仕様書を作るのと同じ道具で直せます。

人が確認する

担当課と契約課の両方が確かめます。 自動で決裁や公告に進む経路は作りません。

1. 担当課：【担当課記入】を埋める … 期間・数量・回数を、今回の予算と事業の計画で決めます
2. 担当課：「前回の仕様書のみ」の記載を見直す … 前回だけの事情で書かれた記載は、残すか消すかを決めます
3. 担当課：候補に答える … 候補ごとに「直した」か「業務上必要（理由）」を書きます。理由の無い「業務上必要」は回付できないようにします
4. 契約課：候補と回答を先に読む … 理由に納得できない候補から、仕様書の該当箇所を読みます
5. 契約課：抜けている項目が埋まったかを確かめる

3番目の理由の欄が、往復を減らす中心です。 契約課が差し戻していたのは、記載の是非よりも「なぜこう書いたのかが分からない」ことが多かったはずです。理由が先に書かれていれば、契約課は差し戻さずに判断できます。

目標は、40件をならして1件90分です。 担当課が【担当課記入】を埋めて候補に答える時間と、契約課が確認する時間を合わせたものです。

契約課が「業務上必要」の理由に納得できないときは、差し戻す前に担当課と短く話します。 文書で往復すると、理由の書き直しがまた1往復になります。話した結果は、回答の欄に契約課が追記し、記録として残します。 同じ種類の業務で同じ理由が続けば、点検の観点の例から外すか、ひな形に書き方を示すかを、契約課が年に一度決めます。

例外に対処する

1行目の新しい事業では、点検の役割が大きくなります。 前例が無いぶん、担当課は相談した事業者の資料を参考にしがちで、その事業者の言葉が仕様書に入りやすくなります。 新規の事業の印が付いた案件は、契約課が候補をすべて読むことにします。

記録を残す

• 作成の依頼の内容と、使った過去の仕様書・要綱の条・ひな形と観点の版の番号
• 下書きのJSONと、担当課が直した後の版
• 点検の候補、捨てた候補の数、担当課の回答と理由
• 契約課の確認の結果と、差し戻した場合の理由
• 決裁に回した版と、公告した版

3つ目の担当課の回答は、後から説明を求められたときの記録になります。 入札に参加できなかった事業者から仕様の理由を問われたとき、「業務上必要」とした理由が残っていれば、その場で答えられます。

区分ごとの候補と回答の数は、年に一度ひな形と観点の表を見直す材料にします。 いつも「業務上必要」と答えられる区分は観点の例が広すぎ、いつも「直した」となる区分は、ひな形の側に最初から書き方を示したほうが早いということです。