新しい試験を計画するときに、過去の実験報告書と試験データから条件の近い試験を探し、結果と失敗理由を根拠の報告書付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、文書管理システムでの報告書の承認を起点にします。 承認済みの報告書だけを取り込むのは、下書きの条件や、差し戻された考察を検索結果に出さないためです。 承認の通知を受けたら Lambda が動き、本文と試験データのCSVを取り出します。文書管理システムが通知を出せない場合は、承認日で絞った一覧を毎晩取りに行く形にします。

過去の約8,000冊は、別に一括で取り込みます。 このときは作成者の確認が取れないので、カードに「未確認」の印を付けます。検索結果では未確認のカードを区別して表示し、研究者が参照に選んだときに、その場で条件を確かめてもらいます。

検索は、研究者が検索画面で「探す」を押したときに動きます。 試験計画書の下書きを書いている途中で、何度でも条件を変えて探せるようにします。

入力データを集める

質を決めるのは、いちばん下の設定表です。 温度が5℃違えば別の試験になる材料もあれば、20℃違っても同じ傾向の材料もあります。「近い」の幅は材料系ごとに研究開発部門が決め、AIには決めさせません。

試験のカードの項目は、最初に固定します。 材料（系統とグレード）、温度、時間、湿度、荷重、試験片の形状、評価の規格番号、結果の区分（achieved／not_achieved／stopped／invalid）、失敗の区分（割れ、剥離、変色、寸法変化、測定不良、その他）です。項目が決まらないうちに取り込みを始めると、後から全件を作り直すことになります。

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

報告書の本文は、Word と文字の入った PDF から取り出します。スキャンした画像だけの古い報告書は、この構成の対象外にします。 取り出せなかった報告書は一覧にして、別に読み取りの作業を回します。

本文はページ番号を付けたまま持ちます。 検索結果で「報告書 TR-2019-044 の12ページ」と示せなければ、研究者は根拠を確かめられません。ページが失われる取り出し方は使いません。

検索時には、試験計画から2つの問い合わせを作ります。 1つは材料名・規格番号・失敗の区分の言葉の一致、もう1つは目的の文の埋め込みによる近さです。この2つをハイブリッドクエリのサブクエリにし、filter で材料の系統と公開範囲を絞ります。

AIへ渡す前に整形する

1. 単位の統一 … 温度は℃、時間は時間、湿度は％RHにそろえます。「85 ℃」「85℃」「85度」を同じ値にします
2. 条件の範囲の扱い … 「80〜90℃」のような範囲は下限と上限の2つの値で持ちます
3. 試験への分割 … 1冊の報告書を試験1件ずつに分け、それぞれにページの範囲を付けます
4. 埋め込みの対象を絞る … 目的、結果、失敗理由の文だけを埋め込みます。条件の数値は埋め込まず、数値の項目として持ちます
5. 長さの確認 … 埋め込みの入力は最大8,192トークンまたは50,000文字です。1件の試験の文がそれを超えることはまずありませんが、超えたものは段落で分けます
6. 重複の検知 … 同じ試験が中間報告と最終報告の両方に載っている場合は、最終報告を正とし、中間報告のカードに印を付けます

4番目を軽く見ないでください。 条件の数値を文章と一緒に埋め込むと、「85℃」と「25℃」の違いは文章の近さにほとんど表れません。 数値は数値の項目として持ち、第5章の7番目で計算して並べます。

条件の数値の近さは、ハイブリッドクエリの中では計算しません。 ドキュメントでは、ハイブリッドクエリを function_score や script_score などのクエリの中に入れることはできないとされています。候補を集めたあとで、Lambda で許容幅から近さを計算して並べ直します。

AIに処理させる

AIの仕事は2か所です。取り込み時のカードの取り出しと、検索結果のまとめです。

3行目がいちばん起きやすい失敗です。 報告書に失敗の理由が書かれていないとき、AIは状況から理由を補いたくなります。補われた理由は、次の研究者にとって「過去の報告書に書いてあったこと」になります。 書かれていなければ「記載なし」とします。

指示内容を固定する

取り込み時（カードの取り出し）：

あなたは研究開発部門で、承認済みの試験報告書から試験の記録を整理する担当です。
報告書の本文だけを根拠にしてください。推測で埋めないでください。

【やること】
報告書に含まれる試験を1件ずつ見つけ、それぞれについて次を取り出してください。
- 試験番号、材料の系統とグレード、試験片の形状
- 条件：温度（℃）、時間（h）、湿度（%RH）、荷重（MPa）、評価の規格番号
- 結果の区分：achieved / not_achieved / stopped / invalid
- 失敗の区分：割れ / 剥離 / 変色 / 寸法変化 / 測定不良 / その他 / なし
- 失敗理由：報告書に書かれた文をそのまま写す
- 根拠のページ

【厳守事項】
- 条件の値が書かれていなければ null にしてください。
  一般的な試験条件や、他の試験の値で埋めないでください。
- 条件の表と本文で値が違うときは、表の値を使い、conflict に両方を書いてください。
- 失敗理由は、報告書に書かれた文だけを写してください。
  書かれていなければ「記載なし」とし、理由を推測しないでください。
- 結果の区分は、報告書の結論の書き方に従ってください。
  「目標に届かなかった」は not_achieved です。読み替えないでください。
- 単位が書かれていない値は、値を入れたうえで unit_missing に項目名を書いてください。

検索時（結果のまとめ）：

あなたは研究者の試験計画を助ける担当です。
渡された検索結果だけを根拠に、試験計画と過去の試験を比べてください。

【試験計画】{plan}
【並べ直した過去の試験（上位10件）】検索結果として渡します

【書くこと】
1. 各試験について、試験計画との条件の差分（温度・時間・湿度・荷重）
2. 各試験の結果の区分と、失敗理由（報告書の記載どおり）
3. 試験計画の条件のうち、渡された試験のどれにも近いものがない条件

【厳守事項】
- 次に試す条件を提案しないでください。
- 検索結果にない試験や報告書に触れないでください。
- 失敗理由を言い換えたり、理由を付け足したりしないでください。
- 「未確認」の印のある試験は、その旨を必ず書いてください。
- 近い試験が1件もなければ、「条件の近い過去の試験は見つかりませんでした」と書いてください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の試験を1つの search_result にし、source に報告書番号とページ、title に試験番号、content にカードの中身を入れます。引用を有効にすると、回答の文ごとにどの検索結果を根拠にしたかが付きます。 研究者は、まとめの1文から報告書のページへそのままたどれます。

「次に試す条件を提案しない」を両方の指示に書かないと、最後に一言添えてきます。 「以上から、80℃での試験が有望です」という一文は、研究者の判断を先取りします。根拠の薄い推奨ほど、忙しいときに計画へそのまま入ります。

出力形式を固定する

取り込み時のカードは、次の形のJSONで受け取ります。

{
  "report_id": "TR-2019-044",
  "tests": [
    {
      "test_id": "",
      "material": { "family": "", "grade": "" },
      "specimen": "",
      "conditions": {
        "temp_c": { "min": null, "max": null },
        "time_h": null,
        "humidity_rh": null,
        "load_mpa": null,
        "standard": ""
      },
      "result": "achieved | not_achieved | stopped | invalid",
      "failure_mode": "割れ | 剥離 | 変色 | 寸法変化 | 測定不良 | その他 | なし",
      "failure_reason": "",
      "pages": [0],
      "conflict": [""],
      "unit_missing": [""]
    }
  ]
}

1つ目の理由は、条件を数値の項目として索引に入れられることです。 temp_c や time_h は OpenSearch の数値の項目にし、filter の範囲指定と、並べ直しの計算の両方に使います。 自由文で受け取ると、単位と範囲の書き方がそろわず、計算できません。

2つ目は、result と failure_mode を決まった値に限れることです。 研究者によって「未達」「NG」「不合格」と書き方が違っても、区分は4つと7つにそろいます。「過去に割れで失敗した試験だけ」という絞り込みが、ここで初めて可能になります。

3つ目は、conflict と unit_missing で、作成者の確認が速くなることです。 表と本文で値が違う箇所、単位のない値だけを確認画面で強調します。作成者は全項目を読み直さず、印の付いた箇所だけを見れば済みます。

検索結果の並べ直しは、次の考え方で計算します。

システムへ連携する

埋め込みは、OpenSearch の ML コネクタから Amazon Bedrock を呼ぶ形にします。 AWS のドキュメントでは、OpenSearch Service の ML コネクタで Amazon SageMaker AI と Amazon Bedrock に接続でき、接続には OpenSearch Service に権限を渡す IAM ロールが必要とされています。細かなアクセス制御を使う場合は、ml_full_access ロールのマッピングも要ります。

セマンティック検索に使うモデルの登録では、model_config を必ず指定します。 指定しないと、セマンティックの項目を持つ索引の作成が失敗するとされています。embedding_dimension はモデルの出力の次元に合わせます。 ドキュメントの例は1,536ですが、Titan Text Embeddings V2 の既定は1,024です。 例をそのまま写すと、索引の次元と合わなくなります。

文書管理システムと試験計画書には書き込みません。 参照欄への書き出しは、研究者が選んだ試験を下書きに写すところまでで、承認に回すのは研究者です。

人が確認する

確認は2か所です。取り込み時の作成者と、検索時の研究者です。

1. 作成者がカードを確定する … 承認の直後に、取り出された試験のカードを確かめます。conflict と unit_missing の付いた箇所を優先して見ます
2. 研究者が検索結果の根拠を開く … 参照に選ぶ試験は、引用の付いた報告書のページを必ず開いて確かめます
3. 未確認のカードを確かめる … 過去分の一括取り込みで作ったカードを参照に選ぶときは、その場で条件を報告書と照らします。確かめたら「確認済み」に変えます
4. 見つからなかった条件を計画に書く … 過去の試験が見つからない条件は、「調べて見つからなかった」として参照欄に残します

1件の試験計画あたり40分を目安にします。 検索結果の10件を読み、うち数件の報告書を開いて確かめ、参照欄を整える時間です。AIが出したまとめだけを読んで参照欄に書く運用にはしません。

4番目は、この構成で初めてできることです。 これまで参照欄の空欄は「調べていない」と区別できませんでした。検索した条件と、見つからなかった条件を残すことで、上長は何が調べられたかを読めます。

例外に対処する

上から3行目までが、取り込みの失敗の大半です。 どれもAIの問題ではなく、報告書の書き方の問題です。 conflict と unit_missing の件数を報告書の書式ごとに数えると、書式を直すべき箇所が見えてきます。

記録を残す

• 取り込んだ報告書の番号、承認日、取り込んだ日時
• Claude が返したカードのJSONと、作成者が確定した時に直した項目
• 検索のたびの試験計画の条件、ハイブリッド検索の候補、並べ直しの結果
• Claude に渡した検索結果と、返ってきたまとめと引用
• 研究者が参照に選んだ試験と、選ばなかった試験
• 「見つからなかった条件」の記録

2つ目で「直した項目」を残すのは、取り出しの精度を測るためです。 どの項目がどれくらい直されているかを見れば、指示を直すべきか、報告書の書式を直すべきかが分かります。

最後の行は、研究開発部門の空白の地図になります。 何度も「見つからなかった」と出る条件の組み合わせは、まだ誰も試していない領域です。 月に1回まとめて、テーマの検討の材料にします。