発注者に出す施工計画書を、特記仕様書・共通仕様書と発注者の要求事項に照らして、記載の漏れと仕様との食い違いを提出前に点検する

処理の起点を決める

起点は2つあります。 1つ目は受注時に工事のフォルダへ設計図書が置かれたとき、2つ目は現場代理人が施工計画書の草案を「点検待ち」に置いたときです。

1つ目は工事ごとに1回です。特記仕様書から要求事項の一覧を作り、工務部の担当が確定するまでを行います。質問回答書や設計変更で設計図書が差し替わったときも、同じ起点で一覧を作り直します。

2つ目は提出のたびに動きます。着工前の施工計画書、変更施工計画書、監督職員から求められた詳細施工計画書のいずれも、同じ「点検待ち」に置きます。要求事項の一覧が確定していない工事では、草案が置かれても点検を始めず、工務部の担当に知らせます。

入力データを集める

質を決めるのは、共通仕様書の記載事項の一覧です。 令和8年3月の土木工事共通仕様書では、施工計画書に記載すべき事項として、工事概要、計画工程表、現場組織表、指定機械、主要船舶・機械、主要資材、施工方法、施工管理計画、安全管理、緊急時の体制及び対応、交通管理、環境対策、現場作業環境の整備、再生資源の利用の促進と建設副産物の適正処理方法、法定休日・所定休日（週休二日の導入）、その他、が並んでいます。発注者ごとの版でこの一覧を持っておかないと、第3章の（b）が見つかりません。

前回の点検結果は、変更施工計画書のために使います。 前回 ok だった項目が変更で崩れていないか、前回 missing だった項目が直っているかを、同じ物差しで比べられます。

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

設計図書と草案は、Power Automate が工事のフォルダから取り出して Claude API に渡します。ページ数の多い特記仕様書は、Files API に上げて file_id で参照すると、リクエストを小さく保てるとされています。

要求事項の取り出しでは、引用の page_location を一覧にそのまま残します。 工務部の担当が一覧を確定するとき、根拠のページを開いて確かめられることが、確定を数十分で終わらせる条件です。

草案の判定では、草案のどのページに書かれていたかを必ず返させます。 現場代理人が点検の一覧を受け取ったとき、ページが分かれば、直す場所を探さずに済みます。

AIへ渡す前に整形する

1. 版の確認 … 草案の版の番号と、要求事項の一覧を作った設計図書の版が合っているかを確かめます
2. PDF の確認 … パスワード付きや暗号化された PDF は使えないので、解除してから置いてもらいます
3. 大きさの確認 … 1回のリクエストの上限を超える文書は、章ごとに分けます。文字の小さいページや複雑な表が多い PDF は、ページ数の上限より先にコンテキストを使い切ることがあるとされています
4. 共通仕様書の版の選択 … 発注者と年度から、記載事項の一覧のどの版を使うかを決めます
5. 要求事項の一覧の読み込み … 確定した一覧を、1項目ずつの判定の単位に分けます
6. 数値の正規化の準備 … 「N/mm²」と「N/mm2」、全角と半角の数字のように、照合のときに表記の違いを吸収する規則を用意します
7. 前回の点検結果の取得 … 変更施工計画書の場合は、前回の一覧を引きます

1番目を軽く見ないでください。 質問回答書で条件が変わったのに、要求事項の一覧が古いままだと、正しく直した草案に conflict が並びます。 設計図書が差し替わったら、一覧を作り直すまで点検を止めます。

AIに処理させる

させるのは2段です。1段目は特記仕様書などから要求事項を取り出すこと、2段目は草案での記載を1項目ずつ判定することです。

右端の列の found_elsewhere と deferred が、この構成でいちばん大事な区別です。 どちらも「想定した場所には無い」ものですが、missing とは違います。found_elsewhere は書いてあるので直さなくてよく、deferred は送り先の書類で確かめる必要があります。 これを missing に混ぜると、点検の一覧が誤った指摘で埋まります。

conflict は、草案が間違っているという意味ではありません。 特記仕様書と草案の値が違うという事実だけです。監督職員と協議して変えた値かもしれないので、どちらが正しいかは人が決めます。

3行目がいちばん起きやすい失敗です。 生成AIは、特記仕様書と共通仕様書で値が違うと「特記仕様書が優先されるので問題ない」と結論を書きがちです。優先の扱い自体は共通仕様書に書かれていますが、その工事でどちらを採るかを決めるのは人です。

指示内容を固定する

1段目（要求事項の取り出し、引用あり）：

あなたは建設会社の工務部で、受注した工事の設計図書を読む立場です。
渡す特記仕様書・現場説明書・質問回答書・工事数量総括表から、次の2種類を取り出してください。

A. 施工計画書に記載することを求めている事項
   （「施工計画書に記載」「施工計画書に明記」「施工計画書に含める」などの指定）
B. 施工の条件として、数値または条件が指定されている事項
   （作業時間帯、休日、使用機械の指定、材料の規格、試験の頻度、交通規制の条件など）

【厳守事項】
- 取り出した事項ごとに、根拠になった文を引用してください。引用の無い事項は書かないでください。
- 数値と単位は、文書に書かれているとおりに書き写してください。換算しないでください。
- 同じ事項について文書どうしで値が違う場合は、両方を取り出し、食い違いとして示してください。
  どちらが正しいかを書かないでください。
- 一般的に施工計画書に書くべきと考えられる事項でも、文書に指定が無いものは書かないでください。

2段目（草案の判定、構造化出力）：

あなたは施工計画書の提出前の点検を手伝う立場です。
確定した要求事項の一覧の1項目ずつについて、施工計画書の草案に記載があるかを判定してください。

【status の選び方】
- ok ............... 草案に記載があり、数値・条件も一覧と同じ
- missing .......... 草案のどこにも記載が無い
- found_elsewhere .. 想定と違う章に記載がある（その章とページを書く）
- deferred ......... 「詳細施工計画書にて提出」などで、別の書類に送っている
- conflict ......... 記載はあるが、数値・条件が一覧と違う
- unclear .......... 記載はあるが、あいまいで一覧と同じか決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 草案のすべてのページを探してから missing を選んでください。章の名前で判断しないでください。
- found_elsewhere、conflict、unclear には、草案のページと、該当する文をそのまま書き写してください。
- 数値は草案に書かれているとおりに書き写してください。換算・丸めをしないでください。
- 草案の書き方を直す案を書かないでください。
- 施工方法が技術的に適切かを書かないでください。
- 特記仕様書と共通仕様書のどちらを優先すべきかを書かないでください。

【要求事項の一覧】{requirements}
【共通仕様書の記載事項（{spec_version}）】{common_items}
【施工計画書の草案】（PDF）

1段目の「指定が無いものは書かない」を明記しないと、一般論が混ざります。 生成AIは施工計画書に書くべき内容をよく知っているので、文書に無い事項まで「要求事項」として並べます。一覧が物差しである以上、出どころの無い目盛りを入れないことが先です。

2段目の「すべてのページを探してから missing を選ぶ」は、found_elsewhere を拾うための一文です。 章の名前だけで判断すると、施工方法の章に書かれた品質管理の記載を見落として missing にします。

出力形式を固定する

2段目の判定は、次の形のJSONで受け取ります。

{
  "project_id": "",
  "plan_version": "",
  "spec_version": "",
  "checks": [
    { "req_id": "R-012", "source": "special_spec | common_spec | owner_guide",
      "requirement": "", "required_value": "",
      "status": "ok | missing | found_elsewhere | deferred | conflict | unclear",
      "plan_page": 0, "plan_text": "", "plan_value": "", "deferred_to": "" }
  ]
}

要求事項の一覧（1段目の結果を人が確定したもの）は、req_id ごとに根拠のページを持ちます。

1つ目の理由は、根拠のページが両側に付くことです。 要求事項の側には設計図書のページ、判定の側には草案のページが付きます。工務部の担当は、両方を開いて見比べるだけで確認が終わります。 第4章の①と③が短くなるのは、ここです。

2つ目は、status を人が直す欄と分けられることです。 AIの判定はそのまま残し、工務部の担当が覆したときは別の欄に記録します。どの種類の判定が覆されやすいかを、あとで数えられます。

3つ目は、plan_value と required_value を Python で照合できることです。 単位の表記ゆれを正規化してから比べ、AIが ok と言ったのに値が違うものを機械的に拾います。AIの判定を、もう一段の機械の照合で裏打ちします。

構造化出力は、出力を JSON スキーマに沿わせ、型と必須の項目を守らせる仕組みです。拒否の応答や max_tokens に達した場合はスキーマに合わない出力になりうるとされているので、stop_reason を見てから一覧に流します。

システムへ連携する

草案には書き込みません。 点検の一覧を別のファイルとして返し、直すのは現場代理人です。 草案に自動で赤を入れると、どこまでが現場代理人の記載で、どこからが機械の書き込みかが分からなくなります。

監督職員へは、この構成から何も送りません。 設計図書どうしの食い違いも、確認事項の一覧として工務部の担当に渡すところまでです。

人が確認する

人の確認は2か所です。 工事ごとに1回の要求事項の一覧の確定と、提出のたびの点検の一覧の確認です。

1. 要求事項の一覧を確定する（工事ごとに1回） … 引用のページを開き、取り出しの漏れと読み違いを確かめます。ここでの1時間が、その工事のすべての点検の質を決めます
2. missing と conflict を先に見る … 草案のページと根拠のページを並べて確かめます
3. found_elsewhere と deferred を流し見る … 書いてある場所と送り先が妥当かを見ます
4. spec_inconsistency を整理する … 監督職員に確認する事項として、現場代理人と共有します
5. 直す点を現場代理人へ戻す … 一覧から選んで返します
6. 判定を覆したら記録する … どの項目を、なぜ覆したかを残します

1番目は省けません。 特記仕様書の読み取りに漏れがあれば、その工事の点検は最後まで漏れたままです。一覧の確定を受注直後の作業として決めておきます。

目標は、40件をならして1件45分です。 要求事項の一覧の確定にかかる時間を件数でならした分と、点検の一覧の確認の時間を合わせた想定です。45分を大きく超える月は、unclear が多いか、設計図書の差し替えが続いています。

例外に対処する

上から2行目までが一番効きます。 どちらも、物差しが無いか古い状態で点検しないための止め方です。 誤った物差しで出た一覧は、出ないより悪い結果になります。

記録を残す

• 要求事項の一覧と、その元になった設計図書の版、確定した担当者と日時
• 1段目で返った引用（page_location と cited_text）の全文
• 草案の版ごとの点検の一覧と、そのとき使った共通仕様書の記載事項の版
• 工務部の担当が覆した判定とその理由
• 監督職員への確認事項として整理したものと、その回答
• 工事・発注者・工種ごとの missing と conflict の件数

4つ目で覆した理由を残すのは、指示と記載事項の一覧を直すためです。 found_elsewhere を missing と誤った件数が多ければ、2段目の指示の書き方が足りていません。

最後の行は、ひな形の見直しの材料になります。 同じ工種で同じ項目が毎回 missing になるなら、ひな形の側にその項目がありません。