過去の試作データから次に試す実験条件を絞り込んで試作回数を減らす

処理の起点を決める

測定結果が登録されたことを起点にします。1回の試作が終わり、強度と透明度の値が入力された時点で、次の候補を出す処理を動かします。

ただし、候補を出す頻度は試作の回し方に合わせてください。 1回ずつ提案を受ける進め方と、1週間分をまとめて提案してもらう進め方があります。装置を1日単位で押さえる現場なら、まとめて提案するほうが合います。

入力データを集める

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

過去の試作履歴： これが最も手のかかる部分です。人ごと、テーマごとに分かれたExcelを1つの形に揃えます。紙の実験ノートしかない場合は、この構成の前に記録を電子化する作業が必要です。 手書き記録の読み取りについては別のユースケース（UC-0034）で扱っています。

条件の範囲： 各項目について、下限と上限、動かせる刻みを決めます。Optunaでは、連続した数値は suggest_float(名前, 下限, 上限) で指定し、step を渡すと刻みを指定できます。0.1刻みでしか計量できない、といった現場の事情はここで表します。材料の銘柄のように選択肢が決まっているものは、カテゴリとして扱います。

試行データの保管： Optunaは試行の履歴をデータベースに保存できます。SQLiteのファイル1つでも動き、PostgreSQLやMySQLも使えます。create_study(study_name=..., storage=..., load_if_exists=True) と書くことで、前回の続きから再開できます。 テーマごとに1つのstudyを作る形にすると、担当が変わっても履歴が引き継がれます。

AIへ渡す前に整形する

1. 単位の統一 … 「80度」と「353K」、「0.5％」と「5000ppm」が混ざります。1つに揃えます。ここがずれると、提案そのものが意味を持ちません
2. 同条件の繰り返しの扱い … 同じ条件で複数回試している場合があります。平均を1件として扱うか、個別に扱うかを決めます。測定のばらつきが大きい場合は、この判断が結果を左右します
3. 失敗した試作の扱い … 装置が止まった、材料が足りなかった、といった理由で測定できなかった試行は、結果が悪かったのとは意味が違います。Optunaでは study.tell(trial, state=optuna.trial.TrialState.FAIL) のように状態を伝えられます
4. 範囲外の記録の除外 … 過去のデータに、今回設定した範囲の外にある条件が含まれることがあります。どう扱うかを決めてから取り込みます

AIに処理させる

役割を明確に分けます。ここがこの構成で最も大事な点です。

最適化ライブラリにさせること： 次に試す条件を決めること。過去の条件と結果から、まだ試していない領域のうち良い結果が期待できるところを探します。OptunaのGPSamplerはガウス過程を当てはめ、獲得関数を最適化して次の条件を提案します。カーネルには2回微分可能なMaternカーネル（nu=2.5）が使われ、各項目の効き方の違いを扱えるようになっています。

生成AIにさせること：

生成AIに数値を予測させないでください。 「この条件なら強度は45程度になると思われます」という文章を生成AIに書かせると、根拠のない数値が現場に流れます。説明文には、過去のどの試行と比べてどの方向へ動かした提案なのかだけを書かせます。

指示内容を固定する

あなたは材料開発の研究員を支援する担当者です。
最適化ライブラリが提案した次の試作条件について、
過去の試行と比べて何が違うのかを説明する文章を作ってください。

【厳守事項】
- 測定結果の予測値を書かないでください。
  「強度は45程度になる」のような数値の予測は絶対に書かないでください。
- 提案された条件の数値を書き換えないでください。
  そのまま引用してください。
- 説明には、過去のどの試行番号と比べているのかを必ず入れてください。
  比較対象のない説明を書かないでください。
- 下に示す実施上の制約に触れる可能性がある場合は、
  cautions にその内容を書いてください。制約は書き換えないでください。
- 化学的・物理的な理由を推測で書かないでください。
  「温度を上げると結晶化が進むため」のような説明は、
  過去の試行データから読み取れる場合を除いて書かないでください。

【提案された条件】
{suggested_params}

【過去の試行（条件と結果）】
{past_trials}

【実施上の制約】
{constraints}

最後の1行が効きます。 生成AIは理由を求められると、もっともらしい化学の説明を書きます。それが正しいかどうかは、この仕組みでは確かめられません。データから言えることだけを書かせてください。

出力形式を固定する

{
  "trial_number": 0,
  "params": {
    "ratio_a": 0.0,
    "ratio_b": 0.0,
    "ratio_c": 0.0,
    "temperature_c": 0,
    "duration_min": 0,
    "stirring_rpm": 0
  },
  "compared_with": [],
  "difference_summary": "",
  "cautions": [],
  "feasible": "yes | no | unknown",
  "needs_review": []
}

params は最適化ライブラリが出した値をそのまま入れます。生成AIの出力で上書きしないでください。 feasible は研究員が判断する欄として空のまま渡し、人が埋めます。

システムへ連携する

提案の受け取りと結果の戻しには、Optunaの Ask-and-Tell インターフェースを使います。これは、目的関数をプログラムの中で完結させずに、外で評価した結果を戻す使い方のために用意されています。

# 次に試す条件をまとめて受け取る
trial_numbers, candidates = [], []
for _ in range(batch_size):
    trial = study.ask()
    trial_numbers.append(trial.number)
    candidates.append({
        "temperature_c": trial.suggest_float("temperature_c", 60, 140, step=5),
        "duration_min": trial.suggest_float("duration_min", 10, 120, step=5),
    })

# ここで試作と測定を行う（数日かかる）

# 結果を戻す
for n, value in zip(trial_numbers, measured_values):
    study.tell(n, value)

まとめて提案を受け取れる点が、実験の現場に合っています。 装置を1日押さえて5条件を並行して試す、といった進め方ができます。study.tell() には試行番号を渡せるので、試作が数日かかっても、その間プログラムを動かし続ける必要はありません。

測る項目が複数ある場合（強度と透明度）は、多目的の最適化として扱います。GPSamplerは多目的の最適化にも対応しており、「どちらも満たす条件の集まり」を探します。また、constraints_func を渡すと、満たすべき条件（不等式の制約）を扱えます。

試作指示書の作成は、この仕組みの外で行ってください。人が選んだ条件だけが指示書になるという流れを崩さないようにします。

人が確認する

全件、人が確認します。運用が安定しても自動化しません。

理由は2つあります。1つは、提案された条件が物理的・化学的に危ない場合があるためです。最適化ライブラリは過去のデータの範囲で探索するだけで、材料の分解温度も、装置の耐圧も知りません。もう1つは、条件には数値に表れないコストがあるためです。ある材料だけ納期が3か月かかる、といった事情は人しか知りません。

確認を速くするための設計が重要です。

• 提案された条件を、過去の試行と同じ表の中に並べて表示する
• 各項目について、過去に試した範囲のどこに位置するかを示す
• 制約に触れる可能性がある候補に印を付ける
• 「この候補は実施しない」を選んだとき、その理由を1行で記録する

最後の1つを記録しておくと、次から同じ候補が出たときに判断が速くなります。 繰り返し却下される領域が見えたら、条件の範囲そのものを狭める合図です。

例外に対処する

記録を残す

• 試作ごとの条件と結果（失敗した試行も、失敗として）
• 条件の範囲と制約の設定内容、変更した日
• 提案された候補の全件（実施しなかったものも含む）
• 実施しなかった候補と、その理由
• 生成AIが作った説明文と、研究員が直した内容

実施しなかった候補の記録が資産になります。 「提案された20件のうち16件を実施しなかった」という状態が続くなら、条件の範囲か制約の設定が現場と合っていません。これは提案の精度の問題ではなく、設定の問題です。