実験・試験の計画をAIとの対話で詰めて、条件の抜けと安全の確認を済ませる

処理の起点を決める

研究員が Teams でエージェントに計画書の下書きを渡したときを起点にします。

レビュー依頼の前に置くことが、この構成の要です。 リーダーへ出した後に使うと、リーダーの作業は減りません。「レビュー依頼の前に必ず通す」を運用のルールにしてください。

ルールにするだけでは定着しません。リーダー側で「エージェントを通していない計画書は受け付けない」とするのが確実です。強制に見えますが、研究員にとっても差し戻しが減るため、数回使えば納得されます。

窓口は Teams にしてください。 電子実験ノートの中に組み込めればそれが理想ですが、製品によっては難しくなります。研究員がすでに使っている場所に置くことのほうが、統合の美しさより重要です。

もう1つの起点として、計画書が承認された後に、その計画で実際に指摘された項目を記録へ蓄積する処理を置きます。「この種の実験では繰り返し数が抜けやすい」という傾向が、ここからたまります。

入力データを集める

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

必須項目のチェックリスト： ここがこの構成の質を決めます。14項目それぞれについて、次の形で持ってください。

「曖昧とみなす表現」の列が、この構成でもっとも効きます。 「乾燥」とだけ書かれていることを検出できるかどうかで、価値が変わります。各項目に3〜5個ずつ挙げてください。

「記入例」も必ず書いてください。 対話で聞き出すとき、例を示せると研究員が答えやすくなります。新人にとっては、これがそのまま教育の材料になります。

試薬・材料の情報： 安全データシート（SDS）の情報を、社内の一覧として持ちます。全文は要りません。 「危険性の区分」「必要な保護具」「廃棄の区分」の3つがあれば足ります。

装置の情報： 装置ごとに設定すべき項目が違います。「測定装置A では、走査速度とステップ幅の指定が必要」といった情報を持たせると、抜けの検出が具体的になります。

過去の計画と指摘： 運用を始めてからたまります。最初は空で構いません。 3か月もあれば、実験の種類ごとに抜けやすい項目が見えてきます。

実験の種類の分類は、細かくしすぎないでください。 合成／評価／分析／耐久試験の4つ程度で十分です。種類を10に分けると、それぞれの必須項目を整える作業が5倍になります。 種類ごとの違いが小さいなら、1つにまとめてください。

装置台帳を新たに作る必要はありません。 すでに研究所で管理している一覧があるはずです。そこに「この装置を使う計画で書かれているべき設定項目」の列を1つ足すだけです。装置が50台あっても、頻繁に使うのは10台程度のはずなので、そこから始めてください。

研究員の情報を使うかどうかは、慎重に決めてください。 「この研究員は繰り返し数を書き忘れやすい」という情報は、対話を個別に最適化するのに使えます。しかし、同じ情報が人事評価に流れる懸念を生みます。 使うなら、目的を「対話の質を上げること」に限定し、その旨を研究員に明示してください。懸念が残るなら、使わない選択も十分にあります。 研究員の情報がなくても、この構成の効果はほとんど変わりません。

AIへ渡す前に整形する

1. 実験の種類の判定 … 計画書の目的欄から、合成／評価／分析／耐久試験のどれかを判定します。種類によって必須項目が変わるため、最初に決めます
2. 必須項目の対応づけ … 計画書の欄と、チェックリストの14項目を対応づけます。研究員が様式を崩している場合があるため、欄の名前だけでなく内容からも対応づけます
3. 試薬名の抽出と照合 … 計画書に出てくる試薬名を抜き出し、社内のSDS一覧と照合します。一覧にない試薬は、その旨を確認の対象にします
4. 装置名の抽出と照合 … 同様に装置台帳と照合します
5. 個人情報・未公開情報の確認 … 顧客との共同開発の内容が含まれる計画は、対象から外すか、該当部分を伏せます

AIに処理させる

2つの工程に分けます。

抜けと曖昧さを見つける工程：

対話で聞き出す工程：

条件の提案、実験の妥当性の判断はさせません。 「この温度では反応が進まないと思われます」といった記述を書かせないでください。それはリーダーが見るべきことです。

安全性の判断もさせません。 「この組み合わせは危険です」という判断は、SDSと現場の設備を見て人が行います。AIができるのは、「この試薬について保護具の記載がありません」と指摘するところまでです。

指示内容を固定する

対話の方針は system_instruction に書きます。

【system_instruction】
あなたは研究開発部の実験計画のレビューを支援する担当者です。
研究員が書いた計画の下書きについて、書かれていない条件を聞き出し、
レビューに回せる状態に整えることが役割です。

【厳守事項】
- 実験の条件を提案しないでください。
  「温度は120℃が適切です」「繰り返しは3回が一般的です」と書かないでください。
  **何を試すかは研究員が決めることです。**
- 実験の妥当性を評価しないでください。
  「この仮説では検証できません」「この条件では結果が出ません」と書かないでください。
  評価はグループリーダーが行います。
- 安全性を判断しないでください。
  「この組み合わせは危険です」と書かないでください。
  「この試薬について、必要な保護具の記載がありません」という指摘までにとどめてください。
- 質問は1つずつしてください。抜けが5つあっても、一度に5つ聞かないでください。
  1つ答えてもらってから次を聞いてください。
- 質問には必ず記入例を添えてください。
  「前処理の条件を教えてください」ではなく、
  「前処理の条件を教えてください。たとえば『110℃の乾燥器で12時間、大気中』のように、
   温度・時間・雰囲気が分かる形でお願いします」と聞いてください。
- 同じ項目を3回聞いても具体的な答えが出ない場合、それ以上聞かずに
  「この項目は未確定としてレビューに回します」と伝えて次へ進んでください。
  **しつこく聞くと、次から使ってもらえなくなります。**
- 研究員の回答を評価しないでください。「良い設計ですね」と言わないでください。
- 計画を承認しないでください。「これで問題ありません」と言わないでください。
  最後に「グループリーダーのレビューへお進みください」と伝えてください。

抜けを見つける側の指示は次のようになります。

下の実験計画の下書きについて、必須項目の記載の有無と曖昧さを判定してください。

【厳守事項】
- 判定は、下の「必須項目のチェックリスト」に照らして行ってください。
  一般的な実験計画の書き方で補わないでください。
- 記載があるかどうかと、書くべき粒度に達しているかを分けて判定してください。
  「乾燥」とだけ書かれている場合、present は true、sufficient は false です。
- 曖昧と判定した場合、チェックリストの「曖昧とみなす表現」のどれに当たるかを示してください。
  当たるものがない場合は、なぜ粒度に達していないかを書いてください。
- 実験の種類（合成／評価／分析／耐久試験）によって必須かどうかが変わる項目は、
  下の判定された種類に従ってください。
- 計画に書かれていない条件を推測で補わないでください。
- 条件の妥当性、実験の設計の良し悪しを書かないでください。

【実験の種類】
{experiment_type}

【計画の下書き】
{plan_draft}

【必須項目のチェックリスト（項目名 / 定義 / 書くべき粒度 / 曖昧とみなす表現 / 記入例 / 種類による要否）】
{checklist}

【使う試薬と、社内SDS一覧の照合結果】
{reagents}

【使う装置と、必要な設定項目】
{instruments}

【この種の実験で過去によく指摘された項目（上位5件）】
{frequent_findings}

「一度に5つ聞かない」の指示が、この構成でもっとも重要です。 抜けを一覧で突きつけられると、研究員は圧倒されます。1つずつ答えるほうが、結果として早く終わります。

「3回で切り上げる」も必須です。 本人がまだ決めていない条件があります。「装置が空くまで温度を決められない」という状態は正常です。 そこをしつこく聞くと、次から使われなくなります。未確定のままレビューに回し、リーダーが判断すればよいことです。

「条件を提案しない」の指示は、研究の独立性を守るためのものです。 AIが「120℃が適切」と言えば、研究員はそれに引きずられます。実験の設計は研究員の仕事であり、そこをAIに任せると、何を検証しているのかが曖昧になります。

この禁止は、テストで必ず確かめてください。 わざと「温度は何度がいいですか」と聞いてみます。「それは研究員の方が決めることです。決まった温度を教えてください」と返るのが正しい挙動です。 ここで具体的な温度を答えるなら、プロンプトを直す必要があります。

「評価しない」の指示も必要です。 「良い設計ですね」「しっかり書けています」といった返答は、一見無害ですが、AIが計画の質を判断しているという印象を与えます。 研究員が「AIのお墨付きをもらった」と受け取ると、リーダーのレビューが形骸化します。

指示の量が多いことに、不安を感じるかもしれません。 しかし、この構成の禁止事項はどれも「やらないこと」を定めるものです。やることはシンプル——抜けを聞いて、埋めて、整形する——なので、禁止事項が多くても対話は破綻しません。 むしろ、禁止を書かないと、モデルは親切のつもりで提案や評価を始めます。

出力形式を固定する

{
  "plan_id": "",
  "experiment_type": "合成 | 評価 | 分析 | 耐久試験",
  "items": [
    {
      "item_name": "",
      "required": true,
      "present": false,
      "sufficient": false,
      "original_text": "",
      "vague_expression": "",
      "reason": "",
      "filled_by_dialogue": "",
      "status": "ok | filled | undetermined | not_required"
    }
  ],
  "reagent_checks": [
    { "reagent": "", "in_sds_list": true, "hazard_noted": false, "ppe_noted": false, "disposal_noted": false }
  ],
  "instrument_checks": [
    { "instrument": "", "missing_settings": [] }
  ],
  "dialogue_turns": 0,
  "undetermined_items": [],
  "formatted_plan": "",
  "ready_for_review": true
}

Gemini API でJSONを返させる場合、response_format にオブジェクト型を指定して mime_type を application/json にし、schema にスキーマを渡します。

present と sufficient を分けていることが、この構成の核です。 「前処理：乾燥」は present: true かつ sufficient: false です。この2つを1つにすると、「書いてあるから問題なし」として通ってしまいます。

undetermined_items は、対話でも埋まらなかった項目です。 これがあること自体は問題ではありません。リーダーが「この項目が未確定のままでよいか」を判断します。

formatted_plan は、埋まった内容を社内様式に整えたものです。 研究員はこれをコピーして計画書を更新します。自動で計画書を書き換えないでください。 研究員が内容を確認してから反映します。

システムへ連携する

対話の結果は、研究員へ返すだけです。 計画書への自動反映はしません。

理由は、研究員が内容を確認する機会を残すためです。 対話の中で答えた内容が、意図どおりに整形されているとは限りません。コピーして貼るという一手間が、確認の機会になります。

記録は、Microsoft Lists へ1件1行で残します。

「レビューでの追加指摘」の列が、この構成を育てます。 AIが見つけられなかった抜けが、ここに記録されます。同じ指摘が繰り返されるなら、チェックリストにその項目を追加します。

電子実験ノートへの書き戻しは行いません。 計画書の更新は研究員が行います。

人が確認する

グループリーダーのレビューは、必ず残します。

この構成が減らすのは「抜けの指摘」であって、「内容の評価」ではありません。AIとの対話を通ったことは、計画が妥当であることを意味しません。

リーダーが見るべきものが変わります。

確認を速くするための設計が効きます。

• undetermined_items を計画書の先頭に表示する
• dialogue_turns が多い計画に印を付ける（下書きの完成度が低かった）
• 試薬がSDS一覧にない場合、目立つ形で示す
• 同じ研究員の過去の undetermined_items を併記する

2つ目が効きます。 対話の往復が20回を超えた計画は、下書きの段階でほとんど書かれていなかったということです。その研究員には、書き方そのものを教える必要があります。

例外に対処する

「リーダーが承認を省く」が、いちばん警戒すべき事態です。 抜けが埋まった計画書は、一見よくできて見えます。「AIが確認済みなら大丈夫だろう」と流されると、この構成は逆効果になります。 導入の説明のときに、リーダー全員へ明確に伝えてください。この構成が減らすのは形式の確認であって、中身の評価ではありません。

記録を残す

この記録は、計画書の書き方を改善する材料になります。

• 対話の全文（何を聞き、どう答えたか）
• 抜けていた項目と、曖昧だった表現
• 未確定のまま残った項目
• 対話の往復数
• レビューでリーダーが追加で指摘した内容
• 実験後に「条件の抜けでやり直した」事例と、その項目

最後の項目が、この構成の効果を測る指標になります。 再実験の原因になった項目が、AIとの対話で聞かれていたかを振り返ってください。聞かれていなかったなら、チェックリストにその項目を追加します。

対話の全文には、未公開の技術情報が含まれます。 保管場所を研究開発部に限定し、閲覧範囲も絞ってください。人事評価に使わないことも、運用として明示します。 「抜けが多い」ことが評価に響くと、対話を通さずにレビューへ出すようになります。