官公庁・自治体の入札公告を毎週巡回して、自社が応札できる案件と締切を洗い出す

処理の起点を決める

毎日早朝の定期実行を起点にします。週1回では遅すぎます。公告から入札まで2〜3週間しかない案件があるためです。

一方、担当者に通知するのは週1回にまとめます。 毎日通知すると読まれなくなります。ただし、締切まで10日を切った新着だけは即時に通知します。

入力データを集める

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

公開API： 中小企業庁が提供する官公需情報ポータルサイトの検索APIを使います。官公需に関する入札情報を取得できるAPIで、提供形式はREST、レスポンスのデータ形式はXMLです。利用条件と取得できる項目の詳細は、公開されているAPIガイドで確認してください。

APIで取れない機関： 指定したページを巡回します。このとき、次を必ず守ってください。

この点をあいまいにしたまま作らないでください。 公的機関のサイトに過度な負荷をかければ、業務妨害になりかねません。「情報が公開されている」ことと「自動で取ってよい」ことは別です。

生成AI側の検索機能を使う方法もあります。 Claude APIのweb search toolは、回答に引用付きで結果を返し、allowed_domains で検索対象のドメインを限定できます。 検索回数は max_uses で上限を決められます。ただし、網羅性は保証されません。 見落としが致命的なこの業務では、APIと巡回を主にし、検索機能は補助に使ってください。

自社の入札参加資格： 機関ごとの等級と有効期限を表にして持ちます。等級が合わなければ、どんなに良い案件でも応札できません。 ここが最初のふるいになります。

AIへ渡す前に整形する

1. 新着の判定 … 案件番号と公告日で、前回取得分と突き合わせます。内容が更新された公告（訂正・期限延長）も新着として扱います
2. 重複の統合 … 同じ案件が複数の経路で取れることがあります。案件番号で1件にまとめます
3. 業種区分での絞り込み … 自社が登録している区分と合わないものを外します
4. 地域での絞り込み … 履行場所が対応できる範囲かを見ます。「全国」と書かれている場合は残します
5. 金額帯での絞り込み … 予定価格が公表されている場合、下限を下回るものを外します
6. 締切での分類 … 締切までの日数で、即時通知の対象かを分けます

3から5までで、500件が60件程度になります。 AIに渡すのはここからです。

AIに処理させる

2段階に分けます。

1段目（抽出）： 公告と仕様書のPDFから、要件を抜き出します。

2段目（照合）： 抽出した要件と、自社の資格・実績・体制を突き合わせ、仕分けます。

LLMに落札の見込みを予想させません。 出させるのは「要件を満たすか」までです。勝てるかどうかは、価格と競合の状況で決まる別の話です。

構造化出力を使い、判定の形式を固定します。制約付きデコードによってスキーマに沿ったJSONの生成が保証されるため、仕分けの値が想定外の文字列で返ることを防げます。

指示内容を固定する

あなたは、入札公告を読んで応札の可否を仕分ける担当者です。

【厳守事項】
- 公告と仕様書に書かれていないことを補わないでください。
  読み取れない要件は unreadable に列挙してください。
- 落札の見込みや、勝てるかどうかを書かないでください。
  要件を満たすかどうかだけを判定してください。
- 予定価格や入札価格を推測しないでください。
- 判定した項目には、公告本文からの引用を必ず添えてください。
- 要件を満たさないと判定する場合も、引用を添えてください。
- 「おそらく問題ない」という表現を使わないでください。
  満たす / 満たさない / 読み取れない の3つで答えてください。

【自社の条件】
入札参加資格: {our_qualifications}
過去の実績: {our_track_record}
配置できる体制: {our_capacity}
対応できる地域: {our_regions}

【公告・仕様書】
{tender_document}

「落札の見込みを書かない」の1行が重要です。 AIが「受注の可能性が高い」と書くと、担当者がそれを前提に動きます。価格の判断は、この構成の外にあります。

出力形式を固定する

{
  "tender_id": "",
  "agency": "",
  "title": "",
  "publish_date": "",
  "deadlines": [
    { "type": "participation | question | bid | opening", "date": "" }
  ],
  "requirements": [
    {
      "type": "grade | experience | staffing | region | period | other",
      "text": "",
      "quote": "",
      "our_status": "met | not_met | unreadable",
      "reason": ""
    }
  ],
  "verdict": "eligible | conditional | not_eligible",
  "blocking_requirement": "",
  "unreadable": [],
  "source_url": ""
}

verdict が conditional になるのは、「体制を確保できれば満たせる」「協力会社と組めば満たせる」といった場合です。ここを not_eligible に寄せると、取れる案件を落とします。

システムへ連携する

期限のカレンダー登録を省かないでください。 この業務でいちばん痛い失敗は、見つけたのに期限を過ぎることです。

人が確認する

全件、人が確認します。応札の意思表示を自動で行いません。

自動化するのは、候補を絞るところまでです。参加表明書の提出、質問の提出、入札書の提出は、すべて人が行います。

確認を速くするための設計が重要です。

• 候補一覧を 締切が近い順に並べる
• verdict ごとに分け、conditional の理由を見せる
• 要件ごとの引用を、公告の該当ページへリンクする
• unreadable が多い案件は、人が原本を読む列に出す
• 前週に「見送り」とした案件を再掲しない

例外に対処する

記録を残す

• 取得した公告の原本と、取得日時・取得元
• 機械的な絞り込みで外した件数（多すぎないかを見る）
• AIの抽出結果と、引用箇所
• 仕分けの結果と、担当者の判断
• 見送った案件と、その理由
• 応札した案件の結果（落札・失注・落札価格）

5番目を必ず残してください。 「なぜこの案件を見送ったか」が残っていないと、あとで検証できません。

6番目は、絞り込みの条件を直す材料になります。 「自動で not_eligible にした案件を、他社が落札していた」と分かれば、条件が厳しすぎます。