研究所の電子実験ノートを横断して、条件・試薬・結果の記述から過去の近い実験を探し、再現の手がかりと失敗の記録を根拠付きで返す

処理の起点を決める

研究員が、いまの実験のノート番号と症状の一言を検索画面で送ったときに動かします。 症状は「結晶が出ない」「原料が残る」「不純物Bが増えた」のような短い言葉で十分です。ノート番号だけで症状が無いときは、「似た条件の実験」を探す検索として扱います。

もう1つの起点は、ノートの署名です。 実験ノートは、研究員が書き終えて署名し、確認者が確認の署名をした時点で取り込みます。毎晩、前日に署名されたノートを書き出して索引に入れます。 書きかけのノートは入れません。後から観察や結果が足されるからです。

署名の後に訂正が入ったノートは、版を上げて入れ直します。 同じノート番号の古い版を消してから入れます。古い版が残ると、同じ実験が別の結果で2件並びます。

入力データを集める

質を決めるのは、3行目の試薬の行です。 試薬の名前だけの索引なら、言葉の検索と大差がありません。CAS 番号とロットが行ごとに入っているから、「同じ試薬の別のロットで止まった実験」が探せます。

4行目の中止の理由も、必ず持たせます。 中止したノートには、「反応液が黒変したため中止」「原料が溶けず中止」のように、次の人がいちばん知りたいことが1行で書かれていることがあります。 理由が書かれていなければ「記載なし」とし、推測で埋めません。

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

検索の形は、次のようになります。

POST /eln-experiments/_search?search_pipeline=eln-hybrid
{
  "size": 20,
  "query": {
    "hybrid": {
      "filter": { "term": { "reaction_type": "amide_coupling" } },
      "queries": [
        { "match": { "observation": "結晶が出ない 油状 析出しない" } },
        { "nested": {
            "path": "reagents",
            "query": { "term": { "reagents.cas": "148893-10-1" } },
            "inner_hits": {}
        } },
        { "knn": { "observation_vec": { "vector": [0.012, -0.031], "k": 50 } } }
      ]
    }
  }
}

ベクトルの値は省略して書いています。filter で反応の種類を先に絞り、3つの問い合わせの点数を検索パイプラインで合わせます。 検索パイプラインは次のように作ります。

PUT /_search/pipeline/eln-hybrid
{
  "phase_results_processors": [
    { "normalization-processor": {
        "normalization": { "technique": "min_max" },
        "combination": {
          "technique": "arithmetic_mean",
          "parameters": { "weights": [0.3, 0.3, 0.4] }
        }
    } }
  ]
}

重みは合計が1.0になるように付けます。 最初は意味の近さを少し重くし、研究員が「当たっていた」と答えた候補の順位を見て調整します。算術平均では、片方の問い合わせにしか当たらなかった文書の点数は下がります。 試薬だけ一致して観察が違う実験が下に行くのは、意図どおりです。

実験の索引の1件は、次のような形にします。

{
  "notebook_id": "ELN-2021-PD-03417",
  "version": 1,
  "project": "PJ-118",
  "chemist": "研究員の社員番号",
  "date": "2021-11-09",
  "reaction_type": "amide_coupling",
  "reagents": [
    { "name": "HATU", "cas": "148893-10-1", "lot": "L2108A", "equiv": 1.2, "order": 2 },
    { "name": "DIPEA", "cas": "7087-68-5", "lot": "L2105C", "equiv": 3.0, "order": 3 }
  ],
  "solvent": "DMF",
  "temp_c": 25,
  "time_h": 16,
  "observation": "反応後、水を加えても析出せず油状。冷却しても固化せず。",
  "result_class": "aborted",
  "abort_reason": "単離できず中止。次回は溶媒を変える予定と記載",
  "yield_pct": null,
  "access_group": "PJ-118"
}

AIへ渡す前に整形する

1. ノートの書き出し … 署名済みのノートを、本文と試薬の表と結果の欄に分けて書き出します
2. 条件と結果の取り出し … Claude API にノートを渡し、試薬の行・溶媒・温度・時間・観察・結果の区分・中止の理由を構造化出力で取り出します。原文の文字列も残します
3. 単位の換算 … 「mmol」「g」「mL」で書かれた量から当量を出す計算は、プログラムで行います
4. CAS 番号の確認 … CAS 番号の末尾の確認用の数字を計算で照らし、合わないものは確認の待ち行列へ回します
5. 試薬の名前のそろえ … 商品名・略号・正式名を、試薬の在庫の管理システムの CAS 番号で1つにまとめます
6. 観察の文のベクトル化 … 観察と手順の本文を節ごとに分け、Titan Text Embeddings V2 でベクトルにします

3番目と4番目をAIに任せないのは、構造化出力の制約のためでもあります。 Claude API の構造化出力は、JSON スキーマの minimum・maximum のような数値の制約に対応しておらず、使うと 400 のエラーになります。 スキーマで範囲を縛れないので、範囲と番号の確認は取り込みの処理で行います。

5番目の名前のそろえを省くと、nested の検索が効きません。 「HATU」と書いた人と正式名で書いた人の実験は、CAS 番号でそろえない限り別の試薬になります。

AIに処理させる

させるのは3つです。ノートから条件と結果を取り出すこと、いまの実験から条件と症状を取り出すこと、検索の結果を候補ごとの説明にすることです。

2行目がいちばん起きやすい失敗です。 中止の理由が「単離できず中止」としか書かれていないノートを渡すと、AIは親切に「溶媒の極性が高すぎたためと考えられる」と続けます。その原因は誰も確かめていません。 書かれている理由だけを写させます。

条件の照合は、次の規則でプログラムが行います。

しきい値は研究所で決めます。 上の値は始めるときの目安です。

指示内容を固定する

あなたは医薬品の合成研究所で、研究員が過去の実験ノートを探すのを手伝う立場です。
検索で見つかった過去の実験を、候補ごとに読みやすく説明してください。
次に何を試すか、失敗の原因が何かを決めないでください。決めるのは研究員です。

【やること】
1. 条件の照合で付いた印（lot_diff など）を、意味の分かる文にしてください。
   違いの値は渡された diff の値をそのまま使ってください。
2. 観察と結果の要点を、ノートの言葉を使って1〜2文で書いてください。
3. 結果の区分が不成功・中止なら、中止の理由をノートから写してください。
4. 説明ごとに、根拠のノート番号と版を付けてください。

【厳守事項】
- ノートに書かれていない失敗の原因を書かないでください。
  「〜のためと考えられる」「〜が原因の可能性がある」と書かないでください。
- 中止の理由が書かれていなければ「記載なし」としてください。
- 当量・量・温度を自分で計算・換算しないでください。
- 印が付いていない条件について、違いがあると推測しないでください。
- 検索結果に無いノート番号・化合物の番号を書かないでください。
- 「この条件で試すとよい」のような提案を書かないでください。

【いまの実験の条件と症状】{current}
【候補（系列ごとの代表と系列内の実験）】{candidates}
【条件の照合の結果】{condition_flags}

「原因を書かない」を2つの言い回しで書いているのは、1つだと残るからです。 「原因は書かない」とだけ伝えると、「〜の可能性がある」という形で書きます。推量の言い回しそのものを禁じます。

違いの値を渡しているのも同じ理由です。 温度や当量の差は、検索のあとにプログラムが出して diff に入れます。AIが差を計算すると、mmol と当量のように単位の違う値どうしを引くことがあります。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "candidates": [
    {
      "notebook_id": "",
      "version": 0,
      "result_class": "success | partial | failed | aborted",
      "flags": [
        { "flag": "", "current": "", "past": "", "diff": "", "explanation": "" }
      ],
      "observation_summary": "",
      "abort_reason": "",
      "same_series": []
    }
  ],
  "failure_records": [],
  "no_similar_found": false,
  "check_with": []
}

1つ目の理由は、notebook_id と version を照らせることです。 出てきた番号が検索結果に含まれているかを、プログラムで確かめます。 含まれていない候補は表示しません。

2つ目は、成功と失敗を分けて並べられることです。 result_class が failed と aborted の候補は、failure_records にも入れて別の段に表示します。「同じ症状で止めた人がいる」ことが、成功の候補より先に目に入るようにします。

3つ目は、flags の current と past を並べて見られることです。 画面では違いのある項目だけを色で示し、研究員がノートを開く前に、どこが違うかを読めるようにします。 flags の中身はプログラムが入れ、AIは explanation だけを書きます。

システムへ連携する

人が確認する

1. 条件と症状を確かめる … 検索の前に、取り出された試薬・当量・溶媒・温度を見ます。CAS 番号が違っていれば直してから検索します
2. 上位のノートを開く … 少なくとも上位3件と、failure_records の全件はノートを開いて読みます
3. ロットの違いを確かめる … lot_diff が付いた候補は、在庫の管理システムでロットの検査の記録を見ます
4. 結果を記録する … 役に立ったノート番号と、次に変えた条件をいまのノートに書きます

2番目を省かないでください。 説明は要約です。観察の細かい書き方、反応式の図、分析のチャートは、ノートを開かないと見えません。

4番目が、索引を育てます。 「ELN-2021-PD-03417 を参照し溶媒を変更」とノートに書けば、次に同じ症状で探した人に、つながった2件のノートが出てきます。

目標は、160件をならして1件12分です。 条件の確認に2分、上位のノートを読むのに8分、ノートへの記録に2分という見込みです。

例外に対処する

記録を残す

• いまの実験の条件と症状、取り出した値と、研究員が直した値
• 検索の条件（絞り込み、問い合わせごとの重み）と、上位の実験と点数
• 条件の照合の結果と、そのとき使った規則としきい値の版
• Claude API の出力と、使った指示の版
• 表示しなかった候補と理由
• 研究員が役に立ったと答えたノート番号

最後の行が、重みを直す材料になります。 役に立った候補が言葉の一致で上がったのか、意味の近さで上がったのかを数えると、問い合わせごとの重みをどちらに寄せるべきかが分かります。