研究所の分析担当から出る「この試料はどの条件で測ったか」「この分析に使えるメソッドはあるか」の質問に、過去の分析メソッド・装置の条件表・分析報告書を根拠に答え、該当が無いものを分析の責任者へ回す

処理の起点を決める

起点は、研究員か分析担当が窓口のチャットで質問を送ったことです。 画面は社内の ID でログインした研究所の人だけが使います。送信の前に、質問の種類を「過去の測定」「これからの測定」の2つから選ばせます。

過去の測定では、依頼番号か試料番号を入れる欄を置きます。 分からなければ空でもよく、その場合は試料の呼び名と時期を書いてもらいます。番号が入っていれば、検索の前に受付台帳で依頼を特定でき、聞き返しが要りません。 これからの測定では、測りたい物質、試料の形態、おおよその濃度の範囲を書く欄を置きます。

別の試料の話に移ったら、新しいセッションで始めます。 前の試料の条件が答えに混ざるからです。

索引の更新は別に動かします。 分析報告書が承認されてファイルサーバーに置かれたとき、メソッドの改訂や廃止が文書管理の仕組みで承認されたときに、その文書だけを入れ直します。メソッドの廃止は、検索に反映されるまでの間に古い版が「有効」として返る心配があるので、承認と同時に入れ直します。

入力データを集める

質を決めるのは、報告書の「使ったメソッドの番号と版」の欄です。 この欄が空の報告書は、どの版で測ったかが分からず、当時の条件を答えられません。古い報告書でこの欄が無いものは、測定日と、その日に有効だった版を照らして補う表を別に作ります。

装置の条件表は、メソッドの本文と分けて持ちます。 メソッドの本文には「カラム温度 40℃」と書かれていても、装置ごとの条件表には実際のカラムの品番や温度のプログラムが書かれています。同じメソッドでも装置が違えば設定が違うので、答えには装置の番号を必ず添えます。

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

報告書とメソッドは、文書ごとにメタデータを付けて Cloud Storage に置きます。 公式のドキュメントでは、メタデータは JSON Lines の形で1行1文書とし、id、structData（項目と値）、content（mimeType と Cloud Storage の uri）を書きます。1ファイルの上限は200MBで、1回に10万ファイルまで取り込めます。

method_status などの絞り込みに使う項目は、データストアのスキーマで索引可能にしておきます。 公式のドキュメントでは、絞り込みに使うメタデータの項目は索引可能にする必要があり、ANY() で文字の値の一致、比較の演算子で数値と日付、AND／OR と NOT で組み合わせができます。日付は ISO 8601 の文字列で比べられます。

過去の測定では、報告書を先に引き、そこに書かれた版で2回目の検索をします。 1回目で報告書を特定し、中継プログラムが報告書のメタデータから method_id と method_version を読み、2回目でその版のメソッドと装置の条件表に絞ります。生成AIに「この報告書の版を探して」と頼まず、版の指定はプログラムが行います。

AIへ渡す前に整形する

1. レイアウトパーサーで読む … 報告書・メソッド・条件表を、表と見出しを検出するパーサーで取り込みます
2. 見出しを分割に付ける … メソッドの途中の段落にも、メソッドの番号と見出しが付くようにします
3. 分割の大きさを決める … 条件の表が途中で切れない大きさにします
4. 古い報告書の版を補う … 版の欄が無い報告書は、測定日とその日に有効だった版の表から補い、補ったことをメタデータに残します
5. 呼び名をそろえる … 試料の呼び名と試料番号の対応を受付台帳から作り、質問の呼び名を番号に置き換えて探します
6. スキャンの報告書を確かめる … 古い紙の報告書のスキャンは、数値が読めているかを20件ほど抜き出して確かめます

1番目と2番目は、データストアを作る前に決めます。 公式のドキュメントでは、レイアウトパーサーは PDF・HTML・DOCX・PPTX・XLSX・XLSM を扱い、段落・表・見出しなどを検出します。分割の大きさは100〜500トークン（既定は500）で、includeAncestorHeadings は既定で無効、分割の設定はデータストアを作った後に切り替えられません。 パーサーを後から変えても、すでに取り込んだ文書は読み直されません。メソッドの途中の条件の段落にメソッドの番号が付いていないと、どのメソッドの条件か分からない引用が返ります。 includeAncestorHeadings は必ず有効にします。

AIに処理させる

検索と回答の作成は、answer メソッドに任せます。 中継プログラムが渡すのは、質問の文、絞り込み、前のセッション、指示の前置き（preamble）です。

関連の薄い結果しか無いとき、answer は答えの代わりに理由を返します。 公式のドキュメントでは、ignoreLowRelevantContent を有効にすると関連の薄いときに NO_RELEVANT_CONTENT、FILTERING_LEVEL_HIGH の基準に届かないときに LOW_GROUNDED_CONTENT が answerSkippedReasons に入ります。この2つは「当てはまる記録が無い」として、分析の責任者へ回す合図にします。

生成AIにさせることは、3つに限ります。

1行目と4行目が、いちばん起きやすい失敗です。 適用範囲が「0.1〜10%」のメソッドについて「0.01%を測れるか」と聞くと、生成AIは「感度を上げれば測れる可能性があります」と書きがちです。それは新しいメソッドの検討で、分析の責任者が決めることです。

指示内容を固定する

answer メソッドの promptSpec の preamble に、次の指示を入れます。

あなたは研究所の分析センターで、過去の分析の記録と分析メソッドを
研究員に案内する立場です。
検索結果（分析報告書、分析メソッド、装置の条件表）に書かれていることだけを
根拠にしてください。

【答え方】
1. 最初に、根拠にした文書を書いてください。
   報告書なら依頼番号と試料番号、メソッドなら番号と版、条件表なら装置の番号。
2. 条件は、検索結果に書かれている数値と単位をそのまま書いてください。
   丸めたり、単位を換算したり、範囲をまとめたりしないでください。
3. 「これから測れるか」の質問では、メソッドの適用範囲の記載を示し、
   質問の物質と濃度がその範囲に入るかだけを書いてください。

【厳守事項】
- 検索結果に無い条件を書かないでください。書かれていなければ
  「記載なし」としてください。
- 新しい条件や、メソッドを変えれば測れるといった提案をしないでください。
- 適用範囲の外のものを「測れる可能性がある」と書かないでください。
  範囲の外なら「適用範囲の外」とだけ書いてください。
- 複数の版のメソッドが見つかっても、版を混ぜて答えないでください。
- 別の試料や別の依頼の条件を、この質問の答えに使わないでください。
- 研究テーマの内容や、試料の組成について推測しないでください。

「単位を換算しない」を明記しないと、mL/min を µL/min に直したり、℃の範囲を中央の値にまとめたりします。 どれも正しい計算でも、原文と見比べたときに一致しなくなり、確かめる時間が増えます。

出力形式を固定する

answer の応答から、中継プログラムが次の形に組み立ててチャットへ返します。 公式のドキュメントでは、応答の citations に答えの中の位置（startIndex・endIndex）と出典の参照が入り、references に分割の本文（chunkInfo の content）と文書のメタデータ（uri・title）が入ります。位置は文字ではなく UTF-8 のバイトで数えられるので、日本語の答えを切り出すときはバイト列で扱います。

{
  "question_id": "",
  "question_type": "past_measurement | new_measurement",
  "answer_text": "",
  "sources": [
    {
      "doc_type": "report | method | instrument_sheet",
      "doc_id": "",
      "method_id": "",
      "method_version": "",
      "method_status": "effective | retired | superseded",
      "instrument_id": "",
      "quoted_text": ""
    }
  ],
  "number_check": "passed | failed",
  "route": "answered | escalate",
  "escalate_reason": "no_record | low_grounding | number_mismatch | out_of_range | retired_only"
}

1つ目の理由は、number_check を答えの外に持てることです。 中継プログラムは、answer_text に出てくる数値と単位の組を取り出し、quoted_text（引用した分割の本文）に同じ組があるかを照らします。1つでも無ければ failed にし、答えを返さずに escalate にします。

2つ目は、method_status を答えに見せられることです。 過去の測定の答えに廃止した版が出てくるのは正しいことですが、読む人が「いまも使える」と取らないよう、版の状態を答えの横に出します。

3つ目は、escalate_reason で責任者の待ち行列を仕分けられることです。 記録が無いのか、範囲の外なのか、数値が合わないのかで、責任者がすることが違います。

システムへ連携する

answer の呼び出しは、質問した人の権限で行います。 公式のドキュメントでは、アクセス制御を使うときは利用者のグループに discoveryengine.servingConfigs.answer などの権限を持つカスタムのロールを付けることが勧められ、社外の ID 基盤（Microsoft Entra ID など）は Workforce Identity Federation でつなぎます。中継プログラムの権限で代わりに呼ぶと、質問した人が見られない報告書が答えに出ます。

人が確認する

1. 引用の確認（研究員） … 答えの引用から原文を開き、依頼番号・版・装置の番号を確かめてから条件を使います
2. 回ってきた質問への回答（分析の責任者） … 記録が無いもの、範囲の外のもの、数値が合わなかったものに答えます
3. 新しい測定の受付（分析の責任者） … 既存のメソッドで測れないものは、分析の依頼として受けます
4. 答えの当たり外れ（研究員） … 答えが役に立ったかを、チャットのボタンで残します

目安は、300件をならして1件6分です。 研究員が引用を開いて確かめる時間と、責任者が回ってきた質問に答える時間を合わせた平均です。回る質問は2割前後という想定で、それより多い月は、メタデータの版の欄が足りていないか、適用範囲の書き方がそろっていません。

人が条件を使う前に原文を開くことは、省かないでください。 数値の照合はプログラムで行っていますが、照合できるのは「引用した箇所にその数値があるか」までで、その箇所が質問の試料の記録かどうかは人が見ます。

例外に対処する

7行目が、この構成でいちばん大事な止め方です。 グループが引けないときに中継プログラムの権限で探すと、その1回だけ、未公開のテーマの報告書が別の研究グループに届きます。 引けなければ止めます。

記録を残す

• 受け取った質問、質問の種類、質問した人、取り出した番号
• 渡した絞り込みと前置き、answer の応答の全文（答え、引用、根拠のスコア、answerSkippedReasons）
• 数値の照合の結果と、合わなかった数値
• 返した答えか、回した理由
• 研究員が付けた当たり外れと、責任者が答えた内容

2行目で応答の全文を残すのは、答えの誤りを後から確かめるためです。 誤った条件で測った試料が後で見つかったとき、どの文書のどの箇所を根拠に答えたかが分からないと、同じ誤りが他にも出ていないかを確かめられません。