Media > AI活用ユースケース > 品質管理 > 手書きの実験・試作記録を読み取って条件と結果の台帳にする

手書きの実験・試作記録を読み取って条件と結果の台帳にする

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

手書きの実験記録用紙をスキャンした画像を入力に、実験番号、日付、担当者、原料と配合、温度・時間・圧力などの条件、測定値、判定を読み取り、台帳の列に割り当てた1行のデータとして受け取ります。測定機から出てくるCSVがある場合は、実験番号で突き合わせて同じ行にまとめます。

サマリー
利用ツール
AWS Textract/Azure AI/ChatGPT/Claude/Gemini/Google Apps Script/Google Document AI/Power Automate/Python
対象業界
その他/医療/教育/製造
対象部門
品質管理/研究開発
対象業務
データ入力・転記/台帳・マスタ管理
主な課題
入力作業が多い/属人化している/情報が見つからない
AIで行う処理
読み取り(OCR)
主な効果
入力漏れ削減/属人化解消/工数削減/検索時間短縮
導入難易度
★★★☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
必須
現在工数
60h/月
AI導入後
20h/月
想定削減
67%
年間削減
480h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 研究員が実験記録用紙に手書きで条件と測定値を書く
  2. 測定機から出力されたCSVを、実験番号を付けてファイルサーバーへ保存する
  3. 実験が終わった週に、用紙を見ながら共有の台帳(表計算ソフト)へ条件を打ち込む
  4. 測定CSVを開き、必要な値だけを台帳へコピーする
  5. 用紙をスキャンしてファイルサーバーへ保存し、原本はバインダーに綴じる
  6. 月末にグループ長が台帳を見て、抜けている実験がないかを確かめる
  7. 過去の条件を調べたいときは、台帳を検索し、足りなければバインダーを探す
導入後(After)
  1. 研究員が実験記録用紙に手書きで記入する(ここは変えない)
  2. 実験が終わったその日に、複合機で用紙をスキャンして所定のフォルダへ入れる
  3. 自動OCRで用紙の全文を読み取り、手書き部分に印を付ける
  4. 自動読み取ったテキストを台帳の列(実験番号・日付・担当・条件・測定値・判定)へ割り当てる
  5. 自動単位を統一し、有効数字を原本の桁数のまま保つ
  6. 自動実験番号で測定機のCSVを探し、同じ行にまとめる
  7. 研究員が確認画面で原本画像と読み取り結果を並べて見て、確定する
  8. 自動確定した行を台帳へ追加し、原本画像を検索できる形で保管する
各工程の詳しい説明を読む
  1. 研究員が実験記録用紙に手書きで条件と測定値を書く
  2. 測定機から出力されたCSVを、実験番号を付けてファイルサーバーへ保存する
  3. 実験が終わった週に、用紙を見ながら共有の台帳(表計算ソフト)へ条件を打ち込む
  4. 測定CSVを開き、必要な値だけを台帳へコピーする
  5. 用紙をスキャンしてファイルサーバーへ保存し、原本はバインダーに綴じる
  6. 月末にグループ長が台帳を見て、抜けている実験がないかを確かめる
  7. 過去の条件を調べたいときは、台帳を検索し、足りなければバインダーを探す

問題は4つあります。

(a)転記が後回しになる。 実験そのものが仕事なので、台帳への入力は週末や月末にまとめて行われます。まとめてやると、書いたときの文脈を思い出しながらの作業になり、1件あたりの時間が延びます。

(b)台帳に入らない実験が出る。 失敗した試作、途中で止めた条件出しは、台帳に載らないことがあります。載らなかった失敗は、半年後に同じ条件で繰り返されます。

(c)検索できない。 台帳の条件欄は自由記述で、「80℃」「80度」「353K」が混在します。過去の類似条件を探すときに引っかかりません。

(d)退職・異動で読めなくなる。 手書きのノートは、書いた本人には読めても、他人には略号の意味が分かりません。引き継ぎのたびに、ノートの読み方から教えることになります。

  1. 研究員が実験記録用紙に手書きで記入する(ここは変えない)
  2. 実験が終わったその日に、複合機で用紙をスキャンして所定のフォルダへ入れる
  3. 【自動】 OCRで用紙の全文を読み取り、手書き部分に印を付ける
  4. 【自動】 読み取ったテキストを台帳の列(実験番号・日付・担当・条件・測定値・判定)へ割り当てる
  5. 【自動】 単位を統一し、有効数字を原本の桁数のまま保つ
  6. 【自動】 実験番号で測定機のCSVを探し、同じ行にまとめる
  7. 【人】 研究員が確認画面で原本画像と読み取り結果を並べて見て、確定する
  8. 【自動】 確定した行を台帳へ追加し、原本画像を検索できる形で保管する

自動化されるのは「読む」「打ち込む」「探して突き合わせる」の3つです。残るのは「この数字で合っているか」の確認だけになります。

02今回想定するシステム構成

構成図
実験記録用紙(手書き)
   │
   ▼ 複合機でスキャン(PDFまたはTIFF)
共有フォルダ / SharePoint の受領フォルダ
   │
   ▼【トリガー】ファイルが作成されたとき
Python の処理(スケジュール実行)
   │
   ├──▶ Azure AI Document Intelligence(prebuilt-read)
   │       └─ 活字と手書きを抽出。isHandwritten と confidence を取得
   │
   ├──▶ Claude API ── 読み取ったテキストを台帳の列へ割り当てる
   │                    単位の統一・有効数字の保持
   │
   └──▶ 測定機CSV(実験番号で突合)
   │
   ▼
確認画面(原本画像と読み取り結果を左右に並べる)──【人が確定】
   │
   ▼
実験台帳(データベース)+ 検索できる形で原本を保管
役割想定する製品代替候補
実行環境PythonGoogle Apps Script、Power Automate
OCRAzure AI Document Intelligence(prebuilt-read)Google Document AI、AWS Textract
生成AIClaude APIOpenAI API、Gemini API
保管SharePointBox、ファイルサーバー
台帳データベース表計算ソフトの共有ブック

電子実験ノートの製品を先に検討してください。 記録の入力、版管理、検索、監査証跡までパッケージ化されています。この構成に価値があるのは、手書きで書く文化をそのまま残したい場合と、過去数年分の紙の記録を後から台帳に載せたい場合です。前者は現場の抵抗が強いときの現実解で、後者は製品を入れても解決しません。

03どうやって実装するのか

Step1

処理の起点を決める

スキャンした記録用紙が受領フォルダに保存されたことを起点にします。複合機のスキャン先を専用フォルダに設定し、そこを監視します。

1日1回のまとめ処理でも成立しますが、実験の当日に処理が走る形にしてください。 研究員の記憶が残っているうちに確認画面を出せるかどうかで、確認の速さが変わります。翌週にまとめて20件出されると、結局は思い出しながらの作業に戻ります。

Step2

入力データを集める

データ中身取得元
実験記録用紙のスキャン条件欄・測定欄・所見欄の手書き複合機→共有フォルダ
記録用紙の様式定義どの欄に何を書くか、単位、取りうる範囲様式管理の台帳
測定機の出力CSV引張強度、粘度、融点などの測定値測定機の保存先
原料マスタ原料コード、正式名称、社内略号開発部の管理表
過去の台帳既存の実験行(重複と連番の確認用)台帳データベース
Step3

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

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」のように書いておくと、後段の範囲外検出に使えます。

Step4

AIへ渡す前に整形する

  1. 向きとゆがみの補正 … 用紙をスキャンすると上下逆や斜めになります。OCRサービス側で補正されるかを確かめ、されない範囲は前段で回転させます
  2. 複数枚の分割 … 1回の実験で用紙が2枚以上になることがあります。用紙の実験番号欄で同一実験のページをまとめます
  3. チェック欄と記入欄の区別 … 様式に印刷された項目名(活字)と、研究員が書いた値(手書き)を分けます。isHandwritten がこの区別に使えます
  4. 重複スキャンの検出 … 同じ用紙を二度スキャンすることがあります。実験番号と日付で既存の台帳行を照合し、重複なら処理を止めます
  5. 記録用紙以外の除外 … 測定機の印字紙、メモ書き、他部署の書類が混ざります。様式の見出し文字列で判定して振り分けます
Step5

AIに処理させる

OCRと生成AIで役割を分けます。

OCR(Document Intelligence)にさせること: 文字と数字の読み取り、位置座標、手書きかどうかの判定、単語ごとの信頼度。ここは生成AIにさせません。 手書きの数字を画像から直接読ませると、読めなかった箇所が「もっともらしい数字」で埋まる危険があります。

生成AI(Claude API)にさせること:

処理内容
列への割り当て読み取られたテキスト片を、様式定義のどの列の値かに対応づける
単位の統一「80℃」「80度」を同じ列の同じ表現にそろえる。摂氏と絶対温度の換算は行う
原料名の名寄せ社内略号、旧品名、正式名称を原料マスタの1件に対応づける
所見欄の整理自由記述の所見から、判定(合格・不合格・保留)と理由を切り出す
範囲外の指摘様式定義の取りうる範囲から外れた値を指摘する

させないこと: 読めなかった数字の補完、測定値の丸め、実験の成否の解釈、次の条件の提案。特に数値の丸めは禁止してください。 有効数字は実験の情報そのものです。

Step6

指示内容を固定する

あなたは研究開発部の実験記録を整理する担当者です。
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 は測定の精度が違います。数値として扱うと消えるため、台帳には文字列としても保持し、後段で数値に変換する形にしてください。

Step7

出力形式を固定する

{
  "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": []
}

valuevalue_text を両方持たせます。前者は計算用、後者は原本の表記そのものです。measurementssource を置き、手書きの値と測定CSVの値のどちらから来たかを残します。後から精度を検証するとき、この区別がないと手書きの読み取り精度が測れません。

構造化出力を使うと、この形を毎回そろえられます。Claude API では output_config.formattype: json_schema とスキーマを渡します。ただし数値の上下限(minimum maximum)は指定できないため、範囲外検出は受け取った後に自前で行います。

Step8

システムへ連携する

確定した行を台帳へ書き込みます。

方式内容
データベース実験台帳をデータベースで持つ場合、確定と同時に1行を挿入する
表計算ソフト共有ブックの末尾に追記する。同時編集の衝突に注意する
電子実験ノート製品にAPIがあれば登録する。提供状況は製品によって異なります

原本画像の保管は、実験番号・日付・担当者・原料で検索できる形にします。台帳の行から原本画像を1クリックで開ける状態にしてください。確認作業がこのリンクの有無で速さが変わります。

測定機のCSVは、突合できたものを台帳の同じ行に紐付け、できなかったものは未突合のリストに残します。自動で近い時刻のCSVを当てにいく処理は入れないでください。違う実験の測定値が入るほうが、突合できていない状態より害が大きくなります。

Step9

人が確認する

全件、研究員が確認して確定します。

理由は、手書きの数字の読み違いが実験データそのものの誤りになるためです。7が1に、0が6に読まれることがあります。台帳に誤った条件が載れば、それを根拠に次の実験が組まれます。この構成で減らしているのは「打ち込む時間」であって、「合っているかを見る責任」ではありません。

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

  • 確認画面で、原本のスキャン画像と読み取り結果を左右に並べて表示する
  • 読み取った箇所を、画像上でハイライトする
  • ocr_confidence が低い項目、is_handwritten が真の項目を色分けする
  • 範囲外の値、needs_review に入った項目を上に集める
  • 測定CSVと突合できた値は、その旨を表示する(確認の負荷が下がる)

これらがないと、確認に15分かかり、削減効果が出ません。

Step10

例外に対処する

起きること対応
手書き文字が判読できない該当項目を null にし、needs_review に入れる。推測値を入れない
数字の桁が読み違えられる範囲外検出で拾う。範囲内の誤りは人の確認で拾うしかない
実験番号が書かれていない台帳に載せず、未整理フォルダへ回して担当者へ通知する
測定CSVが見つからないcsv_match: not_found として、手書きの測定値だけで確定させる
測定CSVの候補が複数あるambiguous として人に選ばせる。時刻で推定しない
同じ用紙を二度スキャンした実験番号と日付で重複を検出し、処理を止める
1実験で用紙が複数枚実験番号でまとめてから処理する
様式が改訂された様式定義に版を持たせ、用紙の版表記で切り替える
記録用紙以外がスキャンされた様式の見出し判定で振り分け、別フォルダへ移す
失敗した実験の記録必ず台帳に載せる。 判定欄が不合格でも処理を止めない

最後の1行は運用の話ですが、この構成の価値の半分がここにあります。失敗を台帳に残すために、失敗しても記録用紙を出す運用を先に決めてください。

Step11

記録を残す

  • スキャンした記録用紙の原本画像(検索できる形で保管)
  • OCRの抽出結果(生の状態。confidenceisHandwritten を含む)
  • 生成AIが割り当てた列と値
  • 測定CSVとの突合結果
  • 研究員が修正した項目と、修正前後の値
  • 確定した台帳行、確定者、確定日時

修正の記録は、精度の実測値になります。「温度と時間はほぼ通るが、原料の配合比は3割修正されている」と分かれば、記録用紙の配合欄の書式を改めるべきだと判断できます。

原本画像は消さないでください。台帳は原本の写しであって、原本の代わりではありません。 台帳の値に疑いが出たときに戻れる先が必要です。

04実装レベルの3段階

最小構成:OCRサービスの画面に1枚ずつ投入し、結果を台帳へ写す / 読み取りのみ
半自動化:フォルダ監視 → OCR → 列への割り当て → 中間シートへ出力 → 人が台帳へ取り込む / 読み取りと転記
本格構成:上記+測定CSVの突合+確認画面+台帳への登録+原本の検索保管 / 確認以外のすべて

半自動化の時点で、15分が8分程度になります。 読んで打ち込む工程が消えるためです。本格構成にすると5分程度になりますが、下がり幅の多くは測定CSVの突合(5分)が消える分です。確認画面と原本の検索保管を作らないと、この5分は消えません。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
12 名
月間件数
240 件
1件あたり現在時間
15 分
1件あたり導入後時間
5 分
現在  240件 × 15分 ÷ 60 = 60 時間/月
導入後 240件 × 5分 ÷ 60 = 20 時間/月
月間削減時間
40h
削減率
67%
年間削減時間
480h
年間金額換算(時間単価4,000円)
192万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 実験や試作の記録を手書きのノート・記録用紙で残していて、月100件以上たまる組織。記録する項目(条件・測定値・判定)がおおむね決まっていること。過去の実験条件を探し直す場面が実際に発生していること。測定機のデータをCSVなどで取り出せること。
向いていない
  1. すでに電子実験ノートを導入して全員が入力している場合。記録の様式が担当者ごとにばらばらで、何を書くかも決まっていない場合(先に様式を決めるほうが効果が大きい)。月10件程度で、担当者が全部覚えている規模。規制対応のために記録の完全性が厳密に求められ、原本の電子化そのものに監査上の要件がかかる業務。

07最小構成で試す方法

  1. 直近の実験記録用紙を20枚用意する(書いた人がばらけるように選ぶ)
  2. 複合機でスキャンしてPDFにする
  3. Document Intelligence Studio(画面でファイルをアップロードして結果を見られる)に1枚ずつ投入する
  4. 手書きの数値が正しく読めているかを、原本と並べて1項目ずつ確認する
  5. 20枚のうち、数値項目が全て正しく取れたのが何枚かを数える

この検証だけは必ずやってください。 手書きOCRの精度は、書き手の字と用紙の様式に強く依存します。他社の事例の数字は当てになりません。

判断の目安は次のとおりです。

数値が全て正しかった枚数判断
14枚以上(7割以上)自動化する価値がある。確認画面を作り込めば運用に乗る
10〜13枚記録用紙の様式を先に直す。枠線付きの記入欄にするだけで上がることがある
9枚以下手書きのまま進めない。入力側を電子化する検討に切り替える

7割で十分と読める理由は、全件を人が確認する設計だからです。 残りの3割は確認画面で直せばよく、それでも最初から打ち込むより速くなります。

列への割り当ては、生成AIの画面にOCRの結果テキストと様式定義を貼るだけで試せます。

08実装時につまずきやすいポイント

問題対策
手書きの数字を読み違える全件を人が確認する設計にする。confidence の低い項目を色分けする
末尾のゼロが消えるvalue_text に原本の表記を文字列で保持する。数値型だけで持たない
単位がそろわない様式定義に単位を持ち、換算元を converted_from に残す
測定CSVが違う実験に紐づく実験番号での突合のみにする。時刻での推定を入れない
原料の略号がマスタにないmaterial_code を null にして人へ回す。自動でマスタに追加しない
失敗した実験が台帳に載らない判定欄が不合格でも処理を止めない。運用として用紙を必ず出す
確認画面が使いにくく確認に時間がかかる原本画像と結果を左右に並べる。低信頼度を色分けする。ここを省くと効果が出ない
様式が改訂されて読めなくなる様式定義に版を持たせ、用紙に版表記を印刷する
過去の紙を一括で取り込もうとして止まる新しい記録から始める。過去分は必要になった範囲だけ後から入れる
台帳と原本が食い違う原本画像を消さない。台帳の行から原本を開けるようにする

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 開発中の材料の配合、製造条件、測定結果。未公開の技術情報であり、多くの場合は営業秘密に当たります。

  1. 外部AIへの入力可否 … 配合と条件は、特許出願前であれば公知にしてはならない情報です。外部サービスへ送ることについて、知財部門と情報管理規程を確認してください。送れない場合は、OCRをオンプレミスまたは自社テナント内に閉じた構成にする検討が必要です
  2. 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます。開発情報は再利用されて困る情報の典型です
  3. アクセス権限 … 台帳と原本画像の閲覧を、開発部門と品質管理部門に限定します。プロジェクト単位で分ける必要がある場合は、台帳の設計時に分離の軸を決めておいてください
  4. 原本の保全 … 電子化しても原本の紙を破棄してよいかは、社内規程と、その記録が何の根拠になるかで変わります。規制対応や特許の先発明の証拠として扱う記録は、破棄の可否を先に確認してください
  5. 自動実行してよい範囲 … 台帳への登録は人の確定を経てから行います。読み取り結果をそのまま台帳に入れる構成にはしないでください
  6. 改ざんの防止 … 確定後の台帳行を後から編集した場合、誰がいつ何を変えたかを残します。実験データは後から都合よく直せてはいけません

誤りが起きた場合のリスクは、誤った条件を根拠にした次の実験、再現できない結果、そして過去データの信頼性の喪失です。確定者と確定日時のログを必ず残してください。

10まず何から始めるか

1週目:手書きOCRの精度を測る

直近の記録用紙20枚(書いた人がばらけるように選ぶ)を、OCRサービスの画面から読ませ、数値項目の精度を測ります。この結果で導入可否が決まります。 7割以上取れるなら進めます。

2週目:様式定義を作る

記録用紙の欄を、列名・単位・取りうる範囲の表に書き起こします。ここで「そもそも人によって書く場所が違う欄」が見つかります。その欄は、AIを入れる前に様式を直すほうが早く効きます。

3〜4週目:半自動化を作る

フォルダ監視からOCR、列への割り当て、中間シートへの出力までを作り、研究員2名が2週間使います。15分が何分になるかを実測します。測定CSVの突合はまだ作りません。

2か月目以降: 削減効果が確認できたら、確認画面と測定CSVの突合、台帳への登録を実装します。並行して、配合と条件を外部サービスへ送ってよいかを知財部門に確認し、必要なら構成を閉じた形へ変更してください。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-11/最終更新:2026-09-11
確認した内容情報源確認日
Azure AI Document Intelligence の prebuilt-read が、PDF・スキャン画像から活字と手書きの両方を抽出すること。単語ごとに confidence を返し、styles に行が手書きかどうかを示す isHandwritten と信頼度を返すこと。PDF・TIFFは2,000ページまで、有料(S0)のファイルサイズ上限は500MB。パスワードロックされたPDFは事前解除が必要Microsoft Learn: Read model2026-09-11
手書きテキストの抽出に対応する言語が、v4.0で英語・日本語・簡体字中国語・韓国語・フランス語・ドイツ語・イタリア語・ポルトガル語・スペイン語・ロシア語・タイ語・アラビア語であること(日本語の手書きが対象に含まれること)Microsoft Learn: Language support for Read and Layout2026-09-11
構造化出力が output_config.formattype: json_schema とスキーマを指定する形であること。minimum maximum 等の数値の制約は未対応で、範囲の検査は受け取り側で行う必要があることClaude Docs: Structured outputs2026-09-11
Claude API がPDFを直接受け取り、本文・図・表を読めること。リクエスト全体で32MBまで、1リクエストあたり600ページまで(コンテキストウィンドウが1Mトークン未満の場合は100ページまで)Claude Docs: PDF support2026-09-11

電子実験ノート製品へのAPI連携の可否は製品によって異なります。この部分は利用環境に応じた個別確認が必要です。 記録の原本を紙で保存し続ける必要があるかどうかは、社内規程と、その記録が何の根拠になるかによって変わります。知財部門および品質保証部門に確認してください。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0034)についてのご相談はこちらから。

AI活用について相談する
目次