手書きの実験・試作記録を読み取って条件と結果の台帳にする
手書きの実験記録用紙をスキャンした画像を入力に、実験番号、日付、担当者、原料と配合、温度・時間・圧力などの条件、測定値、判定を読み取り、台帳の列に割り当てた1行のデータとして受け取ります。測定機から出てくるCSVがある場合は、実験番号で突き合わせて同じ行にまとめます。
- 利用ツール
- AWS Textract/Azure AI/ChatGPT/Claude/Gemini/Google Apps Script/Google Document AI/Power Automate/Python
- 対象業界
- その他/医療/教育/製造
- 対象部門
- 品質管理/研究開発
- 対象業務
- データ入力・転記/台帳・マスタ管理
- 主な課題
- 入力作業が多い/属人化している/情報が見つからない
- AIで行う処理
- 読み取り(OCR)
- 主な効果
- 入力漏れ削減/属人化解消/工数削減/検索時間短縮
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 研究員が実験記録用紙に手書きで条件と測定値を書く
- 測定機から出力されたCSVを、実験番号を付けてファイルサーバーへ保存する
- 実験が終わった週に、用紙を見ながら共有の台帳(表計算ソフト)へ条件を打ち込む
- 測定CSVを開き、必要な値だけを台帳へコピーする
- 用紙をスキャンしてファイルサーバーへ保存し、原本はバインダーに綴じる
- 月末にグループ長が台帳を見て、抜けている実験がないかを確かめる
- 過去の条件を調べたいときは、台帳を検索し、足りなければバインダーを探す
- 研究員が実験記録用紙に手書きで記入する(ここは変えない)
- 実験が終わったその日に、複合機で用紙をスキャンして所定のフォルダへ入れる
- 自動OCRで用紙の全文を読み取り、手書き部分に印を付ける
- 自動読み取ったテキストを台帳の列(実験番号・日付・担当・条件・測定値・判定)へ割り当てる
- 自動単位を統一し、有効数字を原本の桁数のまま保つ
- 自動実験番号で測定機のCSVを探し、同じ行にまとめる
- 人研究員が確認画面で原本画像と読み取り結果を並べて見て、確定する
- 自動確定した行を台帳へ追加し、原本画像を検索できる形で保管する
各工程の詳しい説明を読む
- 研究員が実験記録用紙に手書きで条件と測定値を書く
- 測定機から出力されたCSVを、実験番号を付けてファイルサーバーへ保存する
- 実験が終わった週に、用紙を見ながら共有の台帳(表計算ソフト)へ条件を打ち込む
- 測定CSVを開き、必要な値だけを台帳へコピーする
- 用紙をスキャンしてファイルサーバーへ保存し、原本はバインダーに綴じる
- 月末にグループ長が台帳を見て、抜けている実験がないかを確かめる
- 過去の条件を調べたいときは、台帳を検索し、足りなければバインダーを探す
問題は4つあります。
(a)転記が後回しになる。 実験そのものが仕事なので、台帳への入力は週末や月末にまとめて行われます。まとめてやると、書いたときの文脈を思い出しながらの作業になり、1件あたりの時間が延びます。
(b)台帳に入らない実験が出る。 失敗した試作、途中で止めた条件出しは、台帳に載らないことがあります。載らなかった失敗は、半年後に同じ条件で繰り返されます。
(c)検索できない。 台帳の条件欄は自由記述で、「80℃」「80度」「353K」が混在します。過去の類似条件を探すときに引っかかりません。
(d)退職・異動で読めなくなる。 手書きのノートは、書いた本人には読めても、他人には略号の意味が分かりません。引き継ぎのたびに、ノートの読み方から教えることになります。
- 研究員が実験記録用紙に手書きで記入する(ここは変えない)
- 実験が終わったその日に、複合機で用紙をスキャンして所定のフォルダへ入れる
- 【自動】 OCRで用紙の全文を読み取り、手書き部分に印を付ける
- 【自動】 読み取ったテキストを台帳の列(実験番号・日付・担当・条件・測定値・判定)へ割り当てる
- 【自動】 単位を統一し、有効数字を原本の桁数のまま保つ
- 【自動】 実験番号で測定機のCSVを探し、同じ行にまとめる
- 【人】 研究員が確認画面で原本画像と読み取り結果を並べて見て、確定する
- 【自動】 確定した行を台帳へ追加し、原本画像を検索できる形で保管する
自動化されるのは「読む」「打ち込む」「探して突き合わせる」の3つです。残るのは「この数字で合っているか」の確認だけになります。
02今回想定するシステム構成
実験記録用紙(手書き) │ ▼ 複合機でスキャン(PDFまたはTIFF) 共有フォルダ / SharePoint の受領フォルダ │ ▼【トリガー】ファイルが作成されたとき Python の処理(スケジュール実行) │ ├──▶ Azure AI Document Intelligence(prebuilt-read) │ └─ 活字と手書きを抽出。isHandwritten と confidence を取得 │ ├──▶ Claude API ── 読み取ったテキストを台帳の列へ割り当てる │ 単位の統一・有効数字の保持 │ └──▶ 測定機CSV(実験番号で突合) │ ▼ 確認画面(原本画像と読み取り結果を左右に並べる)──【人が確定】 │ ▼ 実験台帳(データベース)+ 検索できる形で原本を保管
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 実行環境 | Python | Google Apps Script、Power Automate |
| OCR | Azure AI Document Intelligence(prebuilt-read) | Google Document AI、AWS Textract |
| 生成AI | Claude API | OpenAI API、Gemini API |
| 保管 | SharePoint | Box、ファイルサーバー |
| 台帳 | データベース | 表計算ソフトの共有ブック |
電子実験ノートの製品を先に検討してください。 記録の入力、版管理、検索、監査証跡までパッケージ化されています。この構成に価値があるのは、手書きで書く文化をそのまま残したい場合と、過去数年分の紙の記録を後から台帳に載せたい場合です。前者は現場の抵抗が強いときの現実解で、後者は製品を入れても解決しません。
03どうやって実装するのか
処理の起点を決める
スキャンした記録用紙が受領フォルダに保存されたことを起点にします。複合機のスキャン先を専用フォルダに設定し、そこを監視します。
1日1回のまとめ処理でも成立しますが、実験の当日に処理が走る形にしてください。 研究員の記憶が残っているうちに確認画面を出せるかどうかで、確認の速さが変わります。翌週にまとめて20件出されると、結局は思い出しながらの作業に戻ります。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 実験記録用紙のスキャン | 条件欄・測定欄・所見欄の手書き | 複合機→共有フォルダ |
| 記録用紙の様式定義 | どの欄に何を書くか、単位、取りうる範囲 | 様式管理の台帳 |
| 測定機の出力CSV | 引張強度、粘度、融点などの測定値 | 測定機の保存先 |
| 原料マスタ | 原料コード、正式名称、社内略号 | 開発部の管理表 |
| 過去の台帳 | 既存の実験行(重複と連番の確認用) | 台帳データベース |
データの取得方法を決める
OCR: Azure AI Document Intelligence の prebuilt-read モデルにスキャンPDFを渡します。このモデルは活字と手書きの両方を、PDFとスキャン画像から抽出します。単語ごとに confidence が返り、styles には行ごとに手書きかどうかを示す isHandwritten と信頼度が入ります。手書き部分だけを抜き出して重点確認する設計が、この情報で組めます。
手書き文字の抽出に対応する言語は限られており、v4.0では英語、日本語、簡体字中国語、韓国語、フランス語、ドイツ語、イタリア語、ポルトガル語、スペイン語、ロシア語、タイ語、アラビア語が挙げられています。日本語の手書きは対象に含まれます。
PDFとTIFFは2,000ページまで処理でき、ファイルサイズは有料(S0)で500MBまでです。記録用紙1枚を1ファイルとする限り、上限に当たることはありません。
測定機のCSV: ファイル名または1行目のヘッダに実験番号が入っている前提にします。入っていない場合は、測定機の設定で実験番号を記録項目に加えるのが先です。 保存時刻での推定は、同じ日に複数の実験を回した時点で崩れます。
様式定義: 記録用紙のどの欄に何を書くかを、列名・単位・取りうる範囲の表として持ちます。「硬化温度:単位℃、範囲40〜200」のように書いておくと、後段の範囲外検出に使えます。
AIへ渡す前に整形する
- 向きとゆがみの補正 … 用紙をスキャンすると上下逆や斜めになります。OCRサービス側で補正されるかを確かめ、されない範囲は前段で回転させます
- 複数枚の分割 … 1回の実験で用紙が2枚以上になることがあります。用紙の実験番号欄で同一実験のページをまとめます
- チェック欄と記入欄の区別 … 様式に印刷された項目名(活字)と、研究員が書いた値(手書き)を分けます。
isHandwrittenがこの区別に使えます - 重複スキャンの検出 … 同じ用紙を二度スキャンすることがあります。実験番号と日付で既存の台帳行を照合し、重複なら処理を止めます
- 記録用紙以外の除外 … 測定機の印字紙、メモ書き、他部署の書類が混ざります。様式の見出し文字列で判定して振り分けます
AIに処理させる
OCRと生成AIで役割を分けます。
OCR(Document Intelligence)にさせること: 文字と数字の読み取り、位置座標、手書きかどうかの判定、単語ごとの信頼度。ここは生成AIにさせません。 手書きの数字を画像から直接読ませると、読めなかった箇所が「もっともらしい数字」で埋まる危険があります。
生成AI(Claude API)にさせること:
| 処理 | 内容 |
|---|---|
| 列への割り当て | 読み取られたテキスト片を、様式定義のどの列の値かに対応づける |
| 単位の統一 | 「80℃」「80度」を同じ列の同じ表現にそろえる。摂氏と絶対温度の換算は行う |
| 原料名の名寄せ | 社内略号、旧品名、正式名称を原料マスタの1件に対応づける |
| 所見欄の整理 | 自由記述の所見から、判定(合格・不合格・保留)と理由を切り出す |
| 範囲外の指摘 | 様式定義の取りうる範囲から外れた値を指摘する |
させないこと: 読めなかった数字の補完、測定値の丸め、実験の成否の解釈、次の条件の提案。特に数値の丸めは禁止してください。 有効数字は実験の情報そのものです。
指示内容を固定する
あなたは研究開発部の実験記録を整理する担当者です。
OCRで読み取られた実験記録用紙のテキストを、台帳の列へ割り当ててください。
【厳守事項】
- 数値を書き換えないでください。OCRが読み取った文字列を
そのまま引き継いでください。桁を丸めないでください。
末尾のゼロも省かないでください(12.40 を 12.4 にしない)。
- 読み取れなかった箇所、判読できない箇所は value を null にし、
needs_review に列名を入れてください。推測値を入れないでください。
- 単位は様式定義の単位にそろえてください。
換算した場合は converted_from に元の表記を残してください。
- 原料名は原料マスタに存在する名称からのみ選んでください。
マスタにない名称は material_code を null にし、理由を書いてください。
- 所見欄から判定を切り出すときは、書かれた語をそのまま使ってください。
「良好」を「合格」に読み替えないでください。
- 実験の成否の解釈、次に試すべき条件の提案は書かないでください。
【様式定義(列名・単位・取りうる範囲)】
{form_schema}
【OCR抽出結果(手書き判定と信頼度つき)】
{ocr_result}
【原料マスタ】
{materials}
「末尾のゼロも省かない」の1行が要ります。 12.40 と 12.4 は測定の精度が違います。数値として扱うと消えるため、台帳には文字列としても保持し、後段で数値に変換する形にしてください。
出力形式を固定する
{
"experiment_no": "",
"date": "",
"operator": "",
"conditions": [
{
"column": "",
"value": null,
"value_text": "",
"unit": "",
"converted_from": null,
"is_handwritten": true,
"ocr_confidence": 0.0,
"out_of_range": false
}
],
"materials": [
{ "material_code": "", "name_as_written": "", "ratio_text": "" }
],
"measurements": [
{ "column": "", "value_text": "", "unit": "", "source": "手書き | 測定CSV" }
],
"judgement": { "text_as_written": "", "column": "" },
"csv_match": "matched | not_found | ambiguous",
"duplicate_check": "ok | duplicate",
"needs_review": []
}
value と value_text を両方持たせます。前者は計算用、後者は原本の表記そのものです。measurements に source を置き、手書きの値と測定CSVの値のどちらから来たかを残します。後から精度を検証するとき、この区別がないと手書きの読み取り精度が測れません。
構造化出力を使うと、この形を毎回そろえられます。Claude API では output_config.format に type: json_schema とスキーマを渡します。ただし数値の上下限(minimum maximum)は指定できないため、範囲外検出は受け取った後に自前で行います。
システムへ連携する
確定した行を台帳へ書き込みます。
| 方式 | 内容 |
|---|---|
| データベース | 実験台帳をデータベースで持つ場合、確定と同時に1行を挿入する |
| 表計算ソフト | 共有ブックの末尾に追記する。同時編集の衝突に注意する |
| 電子実験ノート | 製品にAPIがあれば登録する。提供状況は製品によって異なります |
原本画像の保管は、実験番号・日付・担当者・原料で検索できる形にします。台帳の行から原本画像を1クリックで開ける状態にしてください。確認作業がこのリンクの有無で速さが変わります。
測定機のCSVは、突合できたものを台帳の同じ行に紐付け、できなかったものは未突合のリストに残します。自動で近い時刻のCSVを当てにいく処理は入れないでください。違う実験の測定値が入るほうが、突合できていない状態より害が大きくなります。
人が確認する
全件、研究員が確認して確定します。
理由は、手書きの数字の読み違いが実験データそのものの誤りになるためです。7が1に、0が6に読まれることがあります。台帳に誤った条件が載れば、それを根拠に次の実験が組まれます。この構成で減らしているのは「打ち込む時間」であって、「合っているかを見る責任」ではありません。
確認を速くするための設計が重要です。
- 確認画面で、原本のスキャン画像と読み取り結果を左右に並べて表示する
- 読み取った箇所を、画像上でハイライトする
ocr_confidenceが低い項目、is_handwrittenが真の項目を色分けする- 範囲外の値、
needs_reviewに入った項目を上に集める - 測定CSVと突合できた値は、その旨を表示する(確認の負荷が下がる)
これらがないと、確認に15分かかり、削減効果が出ません。
例外に対処する
| 起きること | 対応 |
|---|---|
| 手書き文字が判読できない | 該当項目を null にし、needs_review に入れる。推測値を入れない |
| 数字の桁が読み違えられる | 範囲外検出で拾う。範囲内の誤りは人の確認で拾うしかない |
| 実験番号が書かれていない | 台帳に載せず、未整理フォルダへ回して担当者へ通知する |
| 測定CSVが見つからない | csv_match: not_found として、手書きの測定値だけで確定させる |
| 測定CSVの候補が複数ある | ambiguous として人に選ばせる。時刻で推定しない |
| 同じ用紙を二度スキャンした | 実験番号と日付で重複を検出し、処理を止める |
| 1実験で用紙が複数枚 | 実験番号でまとめてから処理する |
| 様式が改訂された | 様式定義に版を持たせ、用紙の版表記で切り替える |
| 記録用紙以外がスキャンされた | 様式の見出し判定で振り分け、別フォルダへ移す |
| 失敗した実験の記録 | 必ず台帳に載せる。 判定欄が不合格でも処理を止めない |
最後の1行は運用の話ですが、この構成の価値の半分がここにあります。失敗を台帳に残すために、失敗しても記録用紙を出す運用を先に決めてください。
記録を残す
- スキャンした記録用紙の原本画像(検索できる形で保管)
- OCRの抽出結果(生の状態。
confidenceとisHandwrittenを含む) - 生成AIが割り当てた列と値
- 測定CSVとの突合結果
- 研究員が修正した項目と、修正前後の値
- 確定した台帳行、確定者、確定日時
修正の記録は、精度の実測値になります。「温度と時間はほぼ通るが、原料の配合比は3割修正されている」と分かれば、記録用紙の配合欄の書式を改めるべきだと判断できます。
原本画像は消さないでください。台帳は原本の写しであって、原本の代わりではありません。 台帳の値に疑いが出たときに戻れる先が必要です。
04実装レベルの3段階
半自動化の時点で、15分が8分程度になります。 読んで打ち込む工程が消えるためです。本格構成にすると5分程度になりますが、下がり幅の多くは測定CSVの突合(5分)が消える分です。確認画面と原本の検索保管を作らないと、この5分は消えません。
05工数削減シミュレーション
導入後 240件 × 5分 ÷ 60 = 20 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 実験や試作の記録を手書きのノート・記録用紙で残していて、月100件以上たまる組織。記録する項目(条件・測定値・判定)がおおむね決まっていること。過去の実験条件を探し直す場面が実際に発生していること。測定機のデータをCSVなどで取り出せること。
- すでに電子実験ノートを導入して全員が入力している場合。記録の様式が担当者ごとにばらばらで、何を書くかも決まっていない場合(先に様式を決めるほうが効果が大きい)。月10件程度で、担当者が全部覚えている規模。規制対応のために記録の完全性が厳密に求められ、原本の電子化そのものに監査上の要件がかかる業務。
07最小構成で試す方法
- 直近の実験記録用紙を20枚用意する(書いた人がばらけるように選ぶ)
- 複合機でスキャンしてPDFにする
- Document Intelligence Studio(画面でファイルをアップロードして結果を見られる)に1枚ずつ投入する
- 手書きの数値が正しく読めているかを、原本と並べて1項目ずつ確認する
- 20枚のうち、数値項目が全て正しく取れたのが何枚かを数える
この検証だけは必ずやってください。 手書きOCRの精度は、書き手の字と用紙の様式に強く依存します。他社の事例の数字は当てになりません。
判断の目安は次のとおりです。
| 数値が全て正しかった枚数 | 判断 |
|---|---|
| 14枚以上(7割以上) | 自動化する価値がある。確認画面を作り込めば運用に乗る |
| 10〜13枚 | 記録用紙の様式を先に直す。枠線付きの記入欄にするだけで上がることがある |
| 9枚以下 | 手書きのまま進めない。入力側を電子化する検討に切り替える |
7割で十分と読める理由は、全件を人が確認する設計だからです。 残りの3割は確認画面で直せばよく、それでも最初から打ち込むより速くなります。
列への割り当ては、生成AIの画面にOCRの結果テキストと様式定義を貼るだけで試せます。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 手書きの数字を読み違える | 全件を人が確認する設計にする。confidence の低い項目を色分けする |
| 末尾のゼロが消える | value_text に原本の表記を文字列で保持する。数値型だけで持たない |
| 単位がそろわない | 様式定義に単位を持ち、換算元を converted_from に残す |
| 測定CSVが違う実験に紐づく | 実験番号での突合のみにする。時刻での推定を入れない |
| 原料の略号がマスタにない | material_code を null にして人へ回す。自動でマスタに追加しない |
| 失敗した実験が台帳に載らない | 判定欄が不合格でも処理を止めない。運用として用紙を必ず出す |
| 確認画面が使いにくく確認に時間がかかる | 原本画像と結果を左右に並べる。低信頼度を色分けする。ここを省くと効果が出ない |
| 様式が改訂されて読めなくなる | 様式定義に版を持たせ、用紙に版表記を印刷する |
| 過去の紙を一括で取り込もうとして止まる | 新しい記録から始める。過去分は必要になった範囲だけ後から入れる |
| 台帳と原本が食い違う | 原本画像を消さない。台帳の行から原本を開けるようにする |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 開発中の材料の配合、製造条件、測定結果。未公開の技術情報であり、多くの場合は営業秘密に当たります。
- 外部AIへの入力可否 … 配合と条件は、特許出願前であれば公知にしてはならない情報です。外部サービスへ送ることについて、知財部門と情報管理規程を確認してください。送れない場合は、OCRをオンプレミスまたは自社テナント内に閉じた構成にする検討が必要です
- 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます。開発情報は再利用されて困る情報の典型です
- アクセス権限 … 台帳と原本画像の閲覧を、開発部門と品質管理部門に限定します。プロジェクト単位で分ける必要がある場合は、台帳の設計時に分離の軸を決めておいてください
- 原本の保全 … 電子化しても原本の紙を破棄してよいかは、社内規程と、その記録が何の根拠になるかで変わります。規制対応や特許の先発明の証拠として扱う記録は、破棄の可否を先に確認してください
- 自動実行してよい範囲 … 台帳への登録は人の確定を経てから行います。読み取り結果をそのまま台帳に入れる構成にはしないでください
- 改ざんの防止 … 確定後の台帳行を後から編集した場合、誰がいつ何を変えたかを残します。実験データは後から都合よく直せてはいけません
誤りが起きた場合のリスクは、誤った条件を根拠にした次の実験、再現できない結果、そして過去データの信頼性の喪失です。確定者と確定日時のログを必ず残してください。
10まず何から始めるか
1週目:手書きOCRの精度を測る
直近の記録用紙20枚(書いた人がばらけるように選ぶ)を、OCRサービスの画面から読ませ、数値項目の精度を測ります。この結果で導入可否が決まります。 7割以上取れるなら進めます。
2週目:様式定義を作る
記録用紙の欄を、列名・単位・取りうる範囲の表に書き起こします。ここで「そもそも人によって書く場所が違う欄」が見つかります。その欄は、AIを入れる前に様式を直すほうが早く効きます。
3〜4週目:半自動化を作る
フォルダ監視からOCR、列への割り当て、中間シートへの出力までを作り、研究員2名が2週間使います。15分が何分になるかを実測します。測定CSVの突合はまだ作りません。
2か月目以降: 削減効果が確認できたら、確認画面と測定CSVの突合、台帳への登録を実装します。並行して、配合と条件を外部サービスへ送ってよいかを知財部門に確認し、必要なら構成を閉じた形へ変更してください。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Azure AI Document Intelligence の prebuilt-read が、PDF・スキャン画像から活字と手書きの両方を抽出すること。単語ごとに confidence を返し、styles に行が手書きかどうかを示す isHandwritten と信頼度を返すこと。PDF・TIFFは2,000ページまで、有料(S0)のファイルサイズ上限は500MB。パスワードロックされたPDFは事前解除が必要 | Microsoft Learn: Read model | 2026-09-11 |
| 手書きテキストの抽出に対応する言語が、v4.0で英語・日本語・簡体字中国語・韓国語・フランス語・ドイツ語・イタリア語・ポルトガル語・スペイン語・ロシア語・タイ語・アラビア語であること(日本語の手書きが対象に含まれること) | Microsoft Learn: Language support for Read and Layout | 2026-09-11 |
構造化出力が output_config.format に type: json_schema とスキーマを指定する形であること。minimum maximum 等の数値の制約は未対応で、範囲の検査は受け取り側で行う必要があること | Claude Docs: Structured outputs | 2026-09-11 |
| Claude API がPDFを直接受け取り、本文・図・表を読めること。リクエスト全体で32MBまで、1リクエストあたり600ページまで(コンテキストウィンドウが1Mトークン未満の場合は100ページまで) | Claude Docs: PDF support | 2026-09-11 |
電子実験ノート製品へのAPI連携の可否は製品によって異なります。この部分は利用環境に応じた個別確認が必要です。 記録の原本を紙で保存し続ける必要があるかどうかは、社内規程と、その記録が何の根拠になるかによって変わります。知財部門および品質保証部門に確認してください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0034)についてのご相談はこちらから。
