新しい試作の依頼が来たときに、過去の配合表・試作記録・官能評価から狙いと原料の近い配合を探し、当時の配合と評価と失敗の理由を根拠付きで返す

処理の起点を決める

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

取り込みは、毎晩の定時で行います。 配合表は試作のたびに版が増えますが、検索の対象にするのは「確定」の印が付いた版だけです。作成途中の配合を取り込むと、まだ試作していない配合が「過去の配合」として返ります。

評価の記録は、配合より後から増えます。 官能評価は試作の数日後、安定性試験は数週間から数か月後に結果が出ます。毎晩の取り込みで、配合番号で結べる新しい評価を付け足します。 配合の文書は作り直さず、評価の項目だけを更新します。

検索は、処方開発の担当が試作の依頼を受けて画面で始めたときに動きます。 依頼書から原料と割合の範囲を読み取るのは担当です。依頼書の文から自動で条件を作ることはしません。 「〇〇エキスを訴求」が何％の配合を意味するかは、担当が顧客と話して決めます。

入力データを集める

質を決めるのは、試作記録の「結論」と「不採用の理由」が書かれているかです。 結論が空の配合は、うまくいったのか止まったのかが分からず、失敗の理由を返すというこの構成の価値が出ません。 取り込みで結論の空を数え、研究開発の会議で埋めてもらいます。

原料のコードは、社内の原料コードにそろえます。 同じ原料でも供給元が違えば別のコードになっていることがあり、どちらで探しても当たるように、原料の一覧に「同等品」の対応を持たせます。

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

配合表は表計算のファイルで、1ファイルが1つの配合の1版です。Lambda で確定版のファイルを読み、原料の行を配列にして登録します。 試作記録と評価の記録は、それぞれの一覧から毎晩書き出してもらい、配合番号と試作番号で結びます。

索引の項目は、次のように持たせます。

割合は、％の数値（float）で持たせます。 配合表によっては ppm や「適量」で書かれた行があります。ppm は％に直し、「適量」は割合を空にして印を付けます。 割合の範囲で検索するとき、空の行は当たりません。

AIへ渡す前に整形する

1. 確定版だけを選ぶ … 配合表のファイルのうち、確定の印が付いた版だけを取り込みます
2. 割合の単位をそろえる … ppm を％に直し、「適量」「微量」は割合を空にして印を付けます
3. 合計を確かめる … 原料の行の割合の合計が100％から外れる配合は、取り込みで印を付けて担当に戻します
4. 原料のコードをそろえる … 同等品の対応で、旧コードや別の供給元のコードを社内の原料コードにそろえます
5. 機能の区分を付ける … 原料の一覧から、保湿剤・増粘剤・乳化剤などの区分を行ごとに付けます
6. 評価を結ぶ … 試作番号から配合番号をたどり、官能評価・安定性試験・結論を付けます
7. 顧客の区分を付ける … 自社品か、どの顧客の受託品かを付けます

3番目を軽く見ないでください。 合計が100％にならない配合表は、行の書き漏れか、割合の打ち間違いです。そのまま取り込むと、割合の範囲の検索で、本当は当たるべき配合が外れたり、当たるべきでない配合が出たりします。

7番目は、検索の画面で絞るのではなく、索引の側で持たせます。 画面で絞る作りにすると、画面を通さない検索では別の顧客の処方が見えます。 見られる範囲は、検索基盤の役割で決めます。

AIに処理させる

AIの仕事は、検索で出た配合を、決まった項目で引用付きで並べることだけです。 配合を絞るのも、当たった原料の行を取り出すのも検索基盤で行います。

2行目が、いちばん外せない線です。 「40℃で2週間後に分離」という記録に対して、AIは「増粘剤の割合が低かったことが原因と考えられます」と書きがちです。その推測が試作の計画書に入ると、記録に無い原因が次の担当に引き継がれます。 失敗の理由は、記録に書かれたものだけを引用させます。

3行目も同じくらい大事です。 過去に製品になった配合でも、原料の使用の制限や表示の決まりは、その後に変わっていることがあります。 適合の確認は、検索の結果とは別に、品質保証と薬事の担当の手順で行います。

指示内容を固定する

あなたは化粧品メーカーの研究開発部で、新しい試作の参考になる過去の配合を整理する係です。
渡された検索結果だけを根拠にしてください。処方の一般的な知識で補わないでください。

【今回の試作の条件】
品目の区分：{category}
使いたい原料と割合の範囲：{ingredient_ranges}
避けたい原料：{excluded_codes}
狙い：{aim_words}

【検索結果】
配合ごとに、狙いの文、条件に当たった原料の行（inner_hits）、
官能評価、安定性試験、結論、不採用の理由、試作の所見が渡されます。

【配合ごとに書くこと】
1. 配合番号・版、品目の区分、結論（採用／不採用／中止／記録なし）
2. 当時の狙い（引用）
3. 条件に当たった原料の行（原料コード、機能、割合％を値のまま）
4. 官能評価（項目と点数を値のまま）と、安定性試験（条件と結果）
5. 不採用・中止の理由と、試作の所見（引用。無ければ「記録なし」）
6. 確かめるべき点（結論が空、割合が「適量」、古い原料コードなど）

【厳守事項】
- 新しい配合や割合を提案しないでください。
- 失敗の原因を推測しないでください。記録に書かれた理由だけを引用してください。
- 安全性や法規への適合について書かないでください。
- 評価の点数を言葉に言い換えないでください。値のまま書いてください。
- 割合は検索結果の値のまま書き、丸めたり単位を変えたりしないでください。
- 結論や不採用の理由が無い配合は、「記録なし」と書いてください。空欄にしないでください。

「原因を推測しない」と「理由だけを引用する」を両方書いているのは、片方だけでは抜け道ができるためです。 推測を禁じるだけだと、AIは「記録からは〇〇がうかがえます」と言い方を変えて書きます。引用だけを許すことで、記録に無い文が出る余地を閉じます。

検索結果は、Claude の検索結果ブロックで渡します。 配合1件を1つの search_result にし、source に配合番号と版、title に品目の区分と結論、content に狙い・当たった原料の行・評価・所見を別々のテキストブロックで入れます。 公式の説明では、引用付きの答えが返り、Amazon Bedrock でも使えます。 引用が試作記録のどの文から来たかを、計画書の画面で辿れます。

出力形式を固定する

検索の要求は、次のように組みます。

GET /formulas/_search
{
  "query": {
    "bool": {
      "filter": [
        { "term": { "category": "cream" } },
        { "nested": { "path": "ingredients",
            "query": { "bool": { "filter": [
              { "term": { "ingredients.code": "RM-0412" } },
              { "range": { "ingredients.pct": { "gte": 3, "lte": 5 } } }
            ] } },
            "inner_hits": { "name": "hit_moist", "size": 3 } } }
      ],
      "must_not": [
        { "nested": { "path": "ingredients",
            "query": { "term": { "ingredients.code": "RM-0950" } } } }
      ],
      "should": [
        { "match": { "aim_text": "べたつかない しっとり" } },
        { "match": { "findings_text": "べたつき 分離" } }
      ]
    }
  }
}

原料のコードと割合の範囲を、同じ nested の中に書くのが要点です。 2つを別の nested に分けると、「原料Aを含む」と「どれかの行が3〜5％」を別々に満たす配合が当たります。原料が複数あるときは、原料ごとに nested を1つずつ並べ、inner_hits の name を分けます。

計画書の画面に返す形は、次のJSONです。

{
  "request": { "category": "cream", "ranges": [ { "code": "RM-0412", "pct": "3-5" } ],
               "excluded": ["RM-0950"] },
  "formulas": [
    { "formula_id": "F-2022-1187", "version": "4", "outcome": "rejected",
      "aim": "", "matched_rows": [ { "code": "RM-0412", "function": "保湿剤", "pct": 4.0 } ],
      "sensory": { "べたつき": 2.1, "しっとり": 4.0 },
      "stability": [ { "condition": "40℃・4週", "result": "分離" } ],
      "reason": "", "trial_ids": ["T-2022-0533"],
      "to_check": ["RM-0412 は旧コードからの読み替え"] }
  ],
  "hidden_by_scope": true
}

1つ目の理由は、matched_rows で近さの理由を固定できることです。 inner_hits の値をそのまま入れるので、AIの文章を読まなくても、どの原料がどの割合で当たったかが分かります。

2つ目は、outcome と reason を分けられることです。 不採用の配合を画面で色分けし、失敗の理由を先に読む使い方ができます。

3つ目は、hidden_by_scope で、見られる範囲の外に当たる配合があったかだけを示せることです。 中身は出さず、「範囲の外にもある」ことだけを出します。必要なら、担当は上長を通じて、その顧客の担当チームに相談します。

システムへ連携する

hidden_by_scope は、範囲の外の配合を数える検索を別の役割で動かして作ります。 担当の役割では範囲の外は見えないので、件数の有無だけを返す専用の処理を Lambda に置きます。

人が確認する

この構成の確認は、必須です。 並んだ配合は過去の記録で、次の配合は担当が決めます。

1. 当たった原料の行を確かめる … 割合の範囲と相が、今回の試作に合うかを見ます
2. 失敗の理由を原本で読む … 不採用・中止の配合は、試作記録の原本を開き、引用の前後を読みます
3. 確かめるべき点を見る … 結論が空の配合は、当時の担当がいれば聞きます。古い原料コードは、いまの原料と同じかを確かめます
4. 上長が試作の計画を確かめる … 参考にした配合番号を計画書に残し、上長が見ます

2番目で原本を開くのは、所見が短く書かれていることが多いためです。 「分離」の一言でも、どの条件で、何日目に、どの相が分かれたかは原本の表にしかありません。

1件あたり30分を目安にします。 配合が5〜8件並べば、当たった行と結論を流し読みし、不採用の2〜3件の原本を開く時間です。

例外に対処する

1行目で範囲を自動で広げないのは、広げた結果を担当が「近い配合」と読むためです。 3〜5％を1〜7％にすれば配合は出ますが、使用感の違う配合が混ざります。 広げるかは担当が決めます。

記録を残す

• 毎晩の取り込みの件数と、合計の外れ・コードの不明で止めた配合
• 検索の条件（原料と割合の範囲、避けたい原料、狙いの言葉）と、返した配合番号
• Claude に渡した検索結果と、返ってきた答えと引用
• 担当が参考にした配合と、参考にしなかった配合
• 範囲の外に当たったことを示した検索
• 結論が空の配合の一覧と、埋まった日

最後の行は、記録の運用を直す材料です。 結論が空の配合が減っていけば、失敗の理由を返すというこの構成の価値が、月を追って大きくなります。