研究者が実験の作業中に話した音声メモを文字にして、試料・条件・観察・時刻を実験記録の項目に分け、記録の抜けを当日中に本人へ返す

処理の起点を決める

アプリで音声が保存されたことを起点にします。 研究者は実験を始める前に、試料ラベルの二次元コードを読んで実験を選びます。選んだ実験IDと録音開始時刻が、すべての音声に付いて保存されます。 実験を選ばずに録音を始めることはできないようにします。

1回の実験で、音声は何本にもなります。 「仕込み終わり」「加熱開始」「色が変わった」と、気づいたたびに話すからです。音声は届いた順にその場で文字にし、実験IDごとに積み上げます。 まとめて夕方に処理すると、文字起こしの失敗に気づくのが遅れます。

もう1つのトリガーは、毎日17時の定時実行です。 その日に音声が届いた実験ごとに、下書きと抜けの一覧を作って本人へ送ります。実験が翌日に続く場合は、本人がアプリで「継続中」を選び、照合は実験が終わった日に回します。

入力データを集める

質を決めるのは、計画の「記録が必要な項目」です。 合成なら仕込み量・溶媒・反応温度・反応時間・滴下の時間・観察した変化、評価なら測定条件・試料の前処理・測定値の扱い、というように、グループごとに項目を決めてひな形に入れます。 ここが無いと、抜けの判定ができません。

表記の一覧は、書き方をそろえるために使います。 ただし、言い換えは下書きの横に候補として出すだけにし、記録の本文は話された言葉のまま残します。

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

文字起こしは、高速文字起こしのAPIに音声とその定義を送ります。

フレーズリストは、認識の直前に渡す語句の一覧で、モデルの学習は要りません。 公式の案内では2,000語句を超えないようにし、長いほど品質と待ち時間に影響するとされています。研究所の全試薬を渡さず、その実験の計画に出てくる語句だけを渡します。 似た名前の試薬が候補に並ぶと、取り違えの元になります。

POST https://{リソース名}.cognitiveservices.azure.com/speechtotext/transcriptions:transcribe?api-version=2025-10-15
audio      = 実験IDと連番を名前にした音声ファイル
definition = {
  "locales": ["ja-JP"],
  "profanityFilterMode": "None",
  "phraseList": { "phrases": ["THF", "テトラヒドロフラン", "トリエチルアミン",
                              "オイルバス", "TLC", "S-2410-07"] }
}

略号と正式名の両方を入れます。 「THF」と言う人と「テトラヒドロフラン」と言う人がいるからです。

時刻は、録音開始時刻に文の offsetMilliseconds を足して計算します。 1本の音声の中で「加熱開始」と「色が変わった」を続けて話せば、2つの文に別々の時刻が付きます。実験計画は、実験IDで計画のひな形から引きます。

AIへ渡す前に整形する

1. 音声の長さを確かめる … 3秒未満はボタンの押し間違いとして捨て、アプリに表示します。3分を超えるものは処理しつつ印を付けます
2. 端末の時刻を確かめる … 録音開始時刻が中継の処理の受信時刻と大きくずれていれば、印を付けます
3. 語句の一覧を作る … 計画の試薬名・略号・装置名と試料IDを合わせます
4. 聞き取れなかった文に印を付ける … confidence が研究所で決めたしきい値を下回る文を low_confidence にします
5. 文に時刻を付ける … 録音開始時刻＋offsetMilliseconds で、文ごとの時刻を計算します
6. その日の文を実験ごとに並べる … 届いた音声の文を、時刻の順に1本の流れにつなげます

4番目が、第1章の「聞き取れなかった」を作る場所です。 信頼度は文字起こしの結果に付いている値を使い、生成AIに付け直させません。 ドラフトチャンバーの排気音や超音波洗浄機の音が重なると、信頼度が下がります。

AIに処理させる

させるのは、文字起こしから記録の項目を取り出し、それぞれに根拠の文を付けることだけです。

計画との照合は、AIにさせません。 AIが返すのは「話に出た項目」だけです。計画の必要項目のうち話に出なかったものを not_mentioned にするのは、中継の処理の機械的な比較です。 照合までAIにさせると、計画の値で空欄を埋めてしまいます。

2行目がいちばん起きやすい失敗です。 「トリエチルアミンを15」とだけ話した文を渡すと、計画の書き方に合わせて「15 mL」と補います。単位は、本人に聞き直す項目として返します。

指示内容を固定する

あなたは化学の研究所で、研究者が実験中に話したメモから
実験記録の項目を取り出す立場です。
文字起こしに書かれていることだけを使ってください。推測で補わないでください。

【取り出す項目】
1. samples … 話に出た試料IDや試料名
2. operations … 行った操作。文の時刻の順に並べる
3. conditions … 温度・時間・量・速度などを parameter / value / unit に分ける
4. observations … 色、状態、におい、発熱、析出などの観察
5. stated_times … 本人が言葉で言った時刻（「10時5分に」など）
6. deviations … 本人が予定との違いとして話したこと

【厳守事項】
- 話に出てこない条件を書かないでください。計画の値で埋めないでください。
- 単位が話されていない数値は、unit を null にしてください。
  単位を補ったり、換算したりしないでください。
- 観察は、話された言葉のまま書いてください。言い換えないでください。
- 反応が進んだか、成功か失敗かといった解釈を書かないでください。
- 各項目に、根拠にした文の番号 sentence_id と、その文をそのまま evidence に写してください。
- low_confidence の印が付いた文から取り出した項目は、low_confidence を true にしてください。
- 実験IDと違う試料に触れている文は、other_sample を true にしてください。
- 時刻を推測しないでください。stated_times には言葉で言った時刻だけを書いてください。

【実験ID】{experiment_id}
【語句の一覧】{phrase_list}
【文字起こし（文番号・時刻・信頼度の印つき）】{sentences}

計画そのものを渡していないことに注意してください。 渡すのは語句の一覧だけです。計画の値を見せると、話に無い値を「計画どおり」として書きます。 語句の一覧は、試薬名の表記をそろえるためだけに使います。

「単位を補わない」を独立した行にしたのも同じ理由です。 数値だけの発話は実験室では珍しくなく、補われた単位は、読む人にとって確かな記録に見えてしまいます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力で、このスキーマに従わせます。

{
  "experiment_id": "",
  "samples": [{ "name": "", "other_sample": false, "sentence_id": 0, "evidence": "" }],
  "operations": [{ "action": "", "sentence_id": 0, "evidence": "", "low_confidence": false }],
  "conditions": [
    { "parameter": "", "value": "", "unit": null,
      "sentence_id": 0, "evidence": "", "low_confidence": false }
  ],
  "observations": [{ "text": "", "sentence_id": 0, "evidence": "", "low_confidence": false }],
  "stated_times": [{ "time": null, "sentence_id": 0, "evidence": "" }],
  "deviations": [{ "text": "", "sentence_id": 0, "evidence": "" }]
}

構造化出力では、すべての項目を必須にし、省略したいものは null との共用体型で表します。 オブジェクトには additionalProperties: false が必要です。unit と time を null にできる型にしておくのは、「話されなかった」を空文字ではなく null で表すためです。

時刻は、AIの出力ではなく中継の処理が付けます。 sentence_id から文の時刻を引き、録音の時刻として記録に入れます。stated_times は本人が言った時刻で、両方が10分以上ずれていれば unclear として本人に確かめます。

照合の結果は、中継の処理が計画の必要項目ごとに付けます。

not_mentioned と unclear を分けて返すのが、第1章の要点です。 前者は本人の記憶に聞くもの、後者は音声を聞けば埋まるものです。

システムへ連携する

電子実験ノートへは自動で書き込みません。 取り込みの方法（API、CSV、貼り付け）は製品によって違いますが、どの方法でも、取り込みの操作は本人が行います。 誰がいつ記録を確定したかを、ノートの側に残すためです。

人が確認する

確かめるのは、実験をした本人です。 夕方に届いた一覧の、not_mentioned と unclear の行から見ます。

1. not_mentioned を埋める … 記憶にあれば書き足し、無ければ「記録なし」と明記します。計画の値を写して埋めません
2. unclear を音声で確かめる … リンクから該当の文の音声を再生し、値と単位を直します
3. recorded を流し見る … 試料と操作の順番が合っているかを見ます
4. 電子実験ノートで確定する … 確定の操作は本人が行います

1番目の「記録なし」の明記を省かないでください。 空欄のまま確定すると、後で読む人は「書き忘れ」と「測っていない」を区別できません。記録が無いことも、記録として残します。

グループ長の週1回の確認は残します。 ただし見るのは、not_mentioned のまま「記録なし」で確定した項目の数です。同じ項目が毎回抜けるなら、話す習慣よりも計画のひな形を見直します。

例外に対処する

上から3行目は、運用の決め方が効きます。 聞き取れなかった文を「もう一度静かな所で話して」と返すと、作業が止まり、メモを話す習慣が続きません。聞き取れなかったものは、夕方に音声で確かめれば足ります。

記録を残す

• 元の音声ファイルと、実験ID・録音開始時刻・受信時刻
• 文字起こしの全文と、文ごとの時刻・信頼度
• 生成AIの出力のJSONと、そのとき使った語句の一覧
• 照合の結果（recorded ／ not_mentioned ／ unclear）と、そのときの計画の必要項目
• 本人が直した箇所の記録 … どの項目を、何から何に変えたか
• 項目ごとの not_mentioned の発生数と、「記録なし」で確定した数

音声を残すのは、記録の根拠をたどれるようにするためです。 後から「この温度は本当に話したか」を確かめたいとき、文字起こしだけでは聞き違いを否定できません。保存の期間は、研究所の記録の保存の規程に合わせます。

最後の行は、計画のひな形を直す材料になります。 特定の項目が毎回 not_mentioned なら、その項目は作業中に話しにくいか、そもそも必要でない可能性があります。