測量会社の技術者が、公共測量の作業規程の準則と発注者の特記仕様から、作業ごとの精度・手順・成果の点検の根拠を引く

処理の起点を決める

起点は2つです。技術者が質問したときと、文書の取り込みです。

質問は、画面で案件を選び、作業の種類と工程を選んで質問を書き、「根拠を探す」を押したときに動きます。案件を選ばずに押すことはできない作りにします。 案件の無い一般の質問（研修での確認など）は、準則の版を選ぶ別の画面にします。

工程を入れるのは、同じ作業でも工程ごとに条文が分かれているからです。 準則は作業ごとに編と章を立て、その中で計画・観測・計算・点検を条で分けています。工程を書かずに探すと、観測の条と点検の条が混ざって出ます。

取り込みは、準則の新しい版、発注者の作業規程の改訂版、案件の特記仕様書と打合せ簿を Cloud Storage に置いたときに動きます。準則の前の版は消しません。 改正前の版で発注された案件が、まだ動いているからです。

入力データを集める

質を決めるのは、案件の台帳の「適用する版」の欄です。 契約の書類から、どの作業規程のどの版に基づくかを読み取って台帳に書きます。この欄が空の案件は、検索を始めません。 推測で最新の版を当てると、この構成の意味がなくなります。

国土地理院のページには、準則の全文と付録が別々のPDFで置かれています。 全文は約1.9MBで、付録の標準様式や公共測量標準図式は数MBあります。本文と付録を別の文書として取り込み、付録には doc_kind を appendix と付けます。

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

準則は条ごとに、付録は章ごとに分けて1文書にし、Cloud Storage に置きます（公式では1ファイル200MB、一度の取り込みで10万ファイルまで）。メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"jun-r7-art-xxx","structData":{"doc_kind":"standard",
 "rule_version":"R7","orderer":["all"],"project":["all"],
 "work":"水準測量","phase":"点検","article":"第◯条"},
 "content":{"mimeType":"application/pdf","uri":"gs://survey-rules/jun-r7-art-xxx.pdf"}}
{"id":"pref-a-rule-2024-ch3","structData":{"doc_kind":"orderer_rule",
 "rule_version":"R5","orderer":["pref-a"],"project":["all"],
 "work":"基準点測量","phase":"観測","article":"第3章"},
 "content":{"mimeType":"application/pdf","uri":"gs://survey-rules/pref-a-rule-2024-ch3.pdf"}}
{"id":"p2026-041-spec-05","structData":{"doc_kind":"special_spec",
 "rule_version":"R5","orderer":["pref-a"],"project":["p2026-041"],
 "work":"基準点測量","phase":"点検","article":"特記第5項"},
 "content":{"mimeType":"application/pdf","uri":"gs://survey-rules/p2026-041-spec-05.pdf"}}

この構成では、版を日付の範囲ではなく rule_version の値で持ちます。 どの版で作業するかは案件ごとに決まっているので、今日の日付と比べる必要がありません。公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、AND・OR と括弧で組み合わせられます。項目はスキーマで索引可能にしておかないと、絞り込みに使えません。

rule_version: ANY("R5")
AND orderer: ANY("all","pref-a")
AND project: ANY("all","p2026-041")
AND work: ANY("基準点測量")

4行とも、中継プログラムが案件の台帳から作ります。 技術者に版を選ばせると、いちばん新しい版を選びます。台帳の「適用する版」の欄が空なら、answer メソッドを呼ばずに「案件の適用版が未登録です。台帳を確認してください」と返します。

AIへ渡す前に整形する

1. 準則を条ごとに分ける … 編・章・条の番号と見出しを article に書き、作業の種類と工程を work と phase に入れます
2. 付録を章で分ける … 標準様式は様式ごと、計算式集は式の区分ごとに分けます
3. 発注者の作業規程の準用の関係を書く … 「準則を準用する」とある作業規程には、読み替えの条を別の文書として切り出し、orderer を付けます
4. 特記仕様書を項目ごとに分ける … 項目ごとに1文書にし、どの作業・工程の話かを付けます
5. 打合せ簿を足す … 協議で決まったことを特記仕様と同じ special_spec として足し、協議の日を本文の頭に書きます
6. 案件の台帳の適用版を埋める … 進行中の案件すべてについて、契約の書類から版を書きます

3番目を軽く見ないでください。 発注者の作業規程は、準則の条をそのまま使い、一部だけを読み替える形が多くあります。読み替えの条を切り出しておかないと、準則の元の条文だけが引かれ、読み替えが抜けます。

AIに処理させる

させるのは、その案件に当たる版の準則・作業規程・特記仕様書から、作業と工程に当たる条文を探し、引用して短くまとめることです。

3行目は法律の仕組みから来ています。 測量法第33条は、測量計画機関が公共測量を実施しようとするときは、観測機械の種類、観測法、計算法などを定めた作業規程を定めて国土交通大臣の承認を得ること、公共測量はその作業規程に基づいて実施しなければならないことを定めています。一般の知識で補った方法は、承認を得た作業規程の外にあります。

answer メソッドの設定は次のようにします。

filteringLevel を高くすると、根拠の弱い回答は生成されず、answerSkippedReasons に LOW_GROUNDED_CONTENT が返ります（関係の薄い内容で止まったときは NO_RELEVANT_CONTENT）。どちらのときも、画面には「この案件の規程で該当の条文が見つかりません。照査の担当に確認してください」と出し、 準則の目次と特記仕様書へのリンクを並べます。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次の指示を入れます。中継プログラムは、作業の種類と工程、準則の版を検索の文の先頭に付けます。

あなたは測量会社の技術部で、公共測量の案件の作業の根拠となる
条文を探す補助をする立場です。読むのは技術者と照査の担当です。

【前提】
検索の対象は、指定の案件に当たる版の作業規程の準則と付録、
その発注者の作業規程、その案件の特記仕様書と打合せ簿だけです。
検索の文の最初に、作業の種類、工程、準則の版が書かれています。

【答え方】
1. 特記仕様書・打合せ簿に同じ事項の定めがあれば、最初に書き、
   本文を引用する
2. 発注者の作業規程に読み替えや独自の定めがあれば、次に書く
3. 準則の条文を、条の番号と見出しを付けて引用する
4. 様式や計算式が要るものは、付録の章の名前を書く
5. 根拠を決めるのに技術者が確かめることがあれば、2つまで挙げる
6. 全体を250字程度に収める

【厳守事項】
- 許容範囲・点検の割合などの数値は、条文の本文の引用の中でだけ
  書いてください。引用の外で数値を書かないでください。
- 観測の結果が許容範囲に入るか、再測が要るかを書かないでください。
- 検索結果に無い作業の方法を、一般の測量の知識で補わないでください。
- 指定の版と違う版の条文を引用しないでください。
- 特記仕様書と準則で定めが違うときは、両方を引用し、
  どちらに従うかは書かないでください。
- 当たる条文が見つからないときは、
  「この案件の規程で該当の条文を確認できませんでした」とだけ書いてください。

「数値は引用の中でだけ書く」を明記しないと、AIは条文の数値を言い換えて書きます。 「mm」と「cm」、「√S」の付け忘れのような写し違いは、読んだだけでは気づきにくく、照査で見つかる前に計算に使われます。 引用の中の数値なら、元の条文とそのまま突き合わせられます。

「どちらに従うかは書かない」も大事です。 特記仕様と準則の定めが違うとき、どちらを優先するかは契約の書類の決まりと発注者との協議で決まります。AIがもっともらしく優先を決めると、協議が要る場面が見えなくなります。

出力形式を固定する

answer メソッドの返り値を、中継プログラムが次の形にまとめます。

{
  "query_id": "",
  "project_id": "",
  "orderer": "",
  "rule_version": "",
  "work": "",
  "phase": "plan | setup | observe | compute | check | deliver",
  "answer_text": "",
  "citations": [ { "doc_kind": "special_spec | orderer_rule | standard | appendix",
                   "article": "", "quote": "", "uri": "" } ],
  "conflict": false,
  "ask_engineer": [],
  "status": "answered | skipped | no_version",
  "skipped_reason": ""
}

1つ目の理由は、citations を文書の種類の順に並べ替えられることです。 中継プログラムが special_spec → orderer_rule → standard → appendix の順に並べ、画面ではこの順に色を分けて出します。特記仕様の上書きを、技術者が読み飛ばせない並びにします。

2つ目は、conflict で協議の要る場面を知らせられることです。 同じ工程について special_spec と standard の両方の引用があれば、中継プログラムが true にし、画面の上に「特記仕様と準則の両方に定めあり。照査の担当に確認」と出します。

3つ目は、rule_version を必ず画面に出せることです。 技術者と照査の担当が、同じ版の条文を見ていることを最初に確かめられます。

公式のドキュメントでは、引用の位置（startIndex／endIndex）は文字ではなく UTF-8 のバイト単位です。日本語の答えの文で引用の箇所に印を付けるときは、バイトの位置を文字の位置に直してから使います。

システムへ連携する

特記仕様書を引けるのは、その案件の担当と照査の担当だけにします。 中継プログラムが、案件の担当の表から選べる案件を決めます。準則と発注者の作業規程は、全員が引けます。

公式のドキュメントには、データストアの文書ごとに読める人を決めるアクセス制御がありますが、Preview の機能で、データストアを作るときにしか有効にできません。 この構成では、案件ごとの制御を中継プログラムの絞り込みで行い、Preview の機能には頼りません。

人が確認する

1. 案件と版を見る … 画面の上に、案件番号と発注者、準則の版が出ます。いま作業している案件と合っているかを最初に見ます
2. 引用の元の条文を開く … 数値を使う前に、元のPDFの条文と突き合わせます
3. conflict を照査に回す … 特記仕様と準則の両方に定めがあるものは、作業者だけで決めません
4. 外れを記録する … 違う条文が出た、見つからなかったときは「違う」を押して理由を書きます

2番目を省かないでください。 引用の数値は条文の写しですが、表の行や注記を取り違えて引用していることがあります。 元の条文の表で、行と列を確かめてから使います。

例外に対処する

6行目は、案件を始める前に片付けておく問題です。 作業規程に「準則を準用する」とだけあり、版が書かれていないことがあります。どの版を準用するかを発注者に確かめた記録を、台帳に残します。

記録を残す

• 質問ごとの、案件、作業の種類、工程、質問の文、技術者
• 絞り込みの条件の全文と、answer メソッドの返り値の全文（答えの文、引用、根拠の強さ、answerSkippedReasons）
• conflict が立った質問と、照査の担当がどう決めたか
• 技術者が「違う」を押した記録と理由
• 取り込んだ準則・作業規程・特記仕様書の版と取り込みの日

3つ目は、成果の検定や発注者の検査で根拠を問われたときに使います。 どの条文を根拠に、誰がどう決めたかを、案件ごとに示せます。