過去の技術報告書から類似の検討結果を根拠付きで探して開発の重複をなくす

処理の起点を決める

技術者が質問を入力したときを起点にします。テーマ登録を検知して自動で類似の過去検討を出す構成も考えられますが、テーマ名だけでは材料・条件・目的のどれで似ているのかが決まらないため、最初は作りません。もう1つの起点は、新しい報告書が文書管理システムに登録されたときで、これを索引の更新に使います。

入力データを集める

4番目の社内用語辞書が、この構成の要になります。 既存のシステムのどこにも存在せず、必ず新規に作る必要があります。

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

報告書の取り込み： テキストを持つPDFとWordはそのまま、スキャン画像のPDFはOCRにかけます。Azure AI Document Intelligence の Read モデルは、PDFとスキャン画像から印刷文字と手書き文字を抽出し、段落・行・単語・言語を返します。v4.0には、テキストを持たないPDFをテキスト付きのPDFに変換する機能もあります。古い報告書ほど画像のままで、ここが取り込みの山場です。

分割（チャンク）の考え方： 1冊を丸ごと1件にすると、当たっても「この80ページのどこか」としか言えません。技術報告書は「目的・条件・結果・考察」の節で切ります。 章立てが揃っているのがこの文書種別の利点です。各断片には前後の見出しと報告書名を付けます。

メタデータの付与： 報告書番号・年度・担当者・部署・ページ・公開区分・契約区分・結論区分を付けます。結論区分（採用／不採用／中断／判断できない）は本文から機械的に取れないことが多く、台帳に持たせるか人が付けます。

AIへ渡す前に整形する

1. スキャンPDFのテキスト化 … 表の数値は取れても、図に描き込まれた条件値は取れないことがあります。この部分は利用環境に応じた個別確認が必要です。 取れなかった断片には「図表あり・要原典確認」の印を付けます
2. 節単位への分割 … 目的・条件・結果・考察の見出しを単位に切ります
3. 表の扱い … 実験条件は表にまとまっています。行と列の構造として取り出せるモデル（Document Intelligence の Layout モデルなど）で、セルの対応を保ったままテキスト化します
4. 社内用語辞書の作成 … 辞書は技術者の言葉で作ります。 質問文の展開と、断片への別名併記の両方に使います
5. 公開区分・契約区分の付与 … 社外秘の度合い、共同開発の成果物か、出願前の発明を含むかを付けます。付けられない文書は既定で検索対象外にします
6. ベクトル化 … 各断片を埋め込みモデルでベクトルにし、索引へ登録します

AIに処理させる

検索と生成で役割を分けます。

検索基盤にさせること： OpenSearch のハイブリッド検索は、キーワード検索と意味による検索を組み合わせる仕組みです。統合には2方式あり、正規化プロセッサは各クエリのスコアを共通の尺度に変換してから合成し、スコアランカープロセッサは各クエリの結果内での順位をもとに合成します（Reciprocal Rank Fusion）。BM25と近傍検索はスコアの尺度が違うため、そのままでは足せません。 正規化プロセッサは min_max・L2・z-score と、算術平均・幾何平均・調和平均に対応します。OpenSearch 2.10で導入された機能です。

両方が要る理由は、質問の中で2種類が混ざるからです。 開発コード名や型番のような文字列が効く問いはキーワード検索が、「反りが出た」のような言い換えの多い問いはベクトル検索が拾います。あわせて、質問者が見られない文書を検索の段階で外します（§13）。

生成AIにさせること：

「どの条件が最適か」は答えさせません。 過去の検討は、当時の設備・材料・要求仕様のもとでのものです。

指示内容を固定する

あなたは研究開発の調べものを手伝う担当者です。
検索で見つかった報告書の断片だけを使って、質問に答えてください。

【厳守事項】
- 断片に書かれていないことを書かず、材料や工法の一般的な知識で
  補わないでください。
- 「この条件が最適です」「〜をお勧めします」といった結論や推奨を
  書かないでください。何が試され、どうなったかだけを書いてください。
- 各文の末尾に、根拠となった断片の番号を [1][2] の形で付けてください。
  根拠を付けられない文は書かないでください。
- 温度、時間、配合比、寸法などの数値は原文のまま引用してください。
  丸めない、単位を換算しないでください。
- 目標に届かなかった検討、中断した検討も、採用された検討と同じ重みで
  挙げてください。省略しないでください。
- 結論が出ていない場合は「結論の記載なし」と書いてください。
- 社内の略号や開発コード名を別の名称へ言い換えないでください。
- 該当する断片がない場合は「見つかりませんでした」と答えてください。

【質問】{question}
【展開した社内用語】{expanded_terms}
【検索で見つかった断片】{retrieved_chunks}

「結論や推奨を書かない」の1行が、この構成でもっとも重要です。 並んだ3件を見て、AIは「したがって温度は240度が適切です」と書きたがります。しかしその3件は、たまたま索引に入っていた3件にすぎません。入っていない検討のほうが多い前提で設計します。

「届かなかった検討も同じ重みで挙げる」も同様です。要約は成果のあった話を残す方向に働きますが、この業務では逆です。

出力形式を固定する

{
  "found": true,
  "reports": [
    { "ref": 1,
      "report_title": "", "report_no": "", "fiscal_year": "",
      "author": "", "department": "", "page": "",
      "purpose": "", "conditions": "", "result": "",
      "conclusion_type": "採用 | 不採用 | 中断 | 結論の記載なし",
      "quote": "" }
  ],
  "not_found_hint": "",
  "figure_only_warning": false
}

found を必ず持たせます。「見つからなかった」を明示的に返せない設計にすると、AIは関連の薄い報告書を無理に結びつけます。

出典の付け方は2通りです。1つはClaude APIの検索結果ブロックで、source（URLまたは社内の識別子）と title を付けて本文を渡すと、回答に付く出典がその値を引き継ぎ、引用される文字列も渡した本文から切り出されたものになります。もう1つは上のJSONスキーマで返させ、ref を渡した断片と突合する方法です。この2つは同時に使えません。 Claude APIでは、引用機能と構造化出力を同時に指定するとエラーになります。

存在しない報告書番号を返していないかを機械的に確かめる工程がないと、この構成は成立しません。

システムへ連携する

索引の更新が、この仕組みが続くかどうかを決めます。 取り込みを一度きりにすると、半年後には「最近の検討は出てこない」道具になり、また人に聞く運用へ戻ります。登録時のトリガーに週次の差分バッチを併用してください。

人が確認する

回答をそのまま設計判断に使わせません。出典を開くことを前提にした運用にします。

条件値が数字として回答文に出ると、そこで確認が止まります。 数字は原典へのリンクとセットでしか表示しないでください。導入初月はリーダーが回答ログを週次で確認し、出典の誤りが1件でもあれば原因を特定してから次へ進みます。

例外に対処する

記録を残す

• 質問文と、辞書で展開した後の検索語
• 返した断片と順位・スコア、生成した回答と出典
• 技術者が原典を開いたかどうか
• found: false の質問の一覧と、権限で除外された件数

3番目が評価指標になります。 回答は出たが毎回原典を開いて別の箇所を読んでいるなら、検索の精度が足りていません。利用回数ではなく、この一致率で評価してください。