Media > AI活用ユースケース > 研究開発 > 試験と観察で撮った写真から、所見の下書きと撮り直しが要る写真を出す

試験と観察で撮った写真から、所見の下書きと撮り直しが要る写真を出す

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

試験や観察で撮った写真を読み、見えているものを所見の型に沿って下書きし、撮り直しが要る写真を示します。研究員の作業は、1枚ずつ見て文章を起こすことから、下書きを直して判断を書き足すことに変わります。

サマリー
利用ツール
ChatGPT/Claude/Gemini/Make/n8n/Power Automate
対象業界
その他/医療/建設/教育/製造
対象部門
研究開発
対象業務
書類作成/記録・議事録作成
主な課題
属人化している/書類作成に時間がかかる/確認ミスが多い
AIで行う処理
画像認識
主な効果
品質標準化/工数削減/教育コスト削減
導入難易度
★★★★☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
40h/月
AI導入後
12h/月
想定削減
70%
年間削減
336h
モデル条件による試算値です。実在企業の実績ではありません。

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

導入前(Before)
  1. 試験を行い、途中と終了後に写真を撮る(1件15枚前後)
  2. 撮った写真を共有フォルダへ移す
  3. ファイル名を試料名と条件に書き換える
  4. 報告書に載せる写真を選ぶ
  5. 選んだ写真を見て、所見を文章で書く
  6. 写真を報告書へ貼り、倍率とスケールを添える
  7. 上司がレビューし、表現をそろえる
  8. 修正して報告書を仕上げる
導入後(After)
  1. 試験を行い、写真を撮る(撮影の条件を記録する様式に沿って)
  2. 自動写真を共有フォルダへ移した時点で処理が始まる
  3. 自動撮影の不備を検出する(ピント、露出、スケールの有無、札の有無)
  4. 自動試験の情報(試料名、条件、部位、倍率)を写真に紐づける
  5. 自動所見の型に沿って、見えているものを下書きする
  6. 自動同じ試料の前回・前々回の写真と並べ、違いを示す
  7. 自動報告書に載せる候補を、観察の項目ごとに提示する
  8. 人研究員が下書きを確かめ、判断を書き足す
  9. 人載せる写真を決める
  10. 自動決まった写真をファイル名を整えて報告書の様式へ配置する
  11. 人上司がレビューする
各工程の詳しい説明を読む
  1. 試験を行い、途中と終了後に写真を撮る(1件15枚前後)
  2. 撮った写真を共有フォルダへ移す
  3. ファイル名を試料名と条件に書き換える
  4. 報告書に載せる写真を選ぶ
  5. 選んだ写真を見て、所見を文章で書く
  6. 写真を報告書へ貼り、倍率とスケールを添える
  7. 上司がレビューし、表現をそろえる
  8. 修正して報告書を仕上げる

問題は7つあります。

(a)ファイル名の書き換えに時間がかかる。 「IMG_0412.jpg」を「SUS304_塩水噴霧240h_断面_×200.jpg」に直します。1件15枚で10分以上かかります。

(b)所見の書き方が人によって違う。 同じ状態を見ても、使う語彙が違います。報告書全体で表現がそろっていないと、読み手が比較できません。

(c)新人が所見を書けない。 何を見るのか、どの順で書くのかが暗黙知です。先輩の過去の報告書を探して真似るところから始まります。

(d)撮影の不備に後から気づく。 スケールの写し忘れ、試料名の札の不在、ピントのずれ。報告書を書く段階で気づいても、試料がすでにないことがあります。

(e)写真の選別に迷う。 15枚のうちどれを載せるかを、毎回考えています。似た写真が複数あり、どれが代表的かの判断に時間がかかります。

(f)レビューで表現を直す作業が上司に集中する。 5名分の報告書の表現をそろえる作業が、1名に集まっています。

(g)過去の試験との比較がしにくい。 「前回より腐食が進んでいるか」を見るには、過去の写真を探す必要があります。ファイル名がそろっていないと探せません。

  1. 試験を行い、写真を撮る(撮影の条件を記録する様式に沿って)
  2. 【自動】 写真を共有フォルダへ移した時点で処理が始まる
  3. 【自動】 撮影の不備を検出する(ピント、露出、スケールの有無、札の有無)
  4. 【自動】 試験の情報(試料名、条件、部位、倍率)を写真に紐づける
  5. 【自動】 所見の型に沿って、見えているものを下書きする
  6. 【自動】 同じ試料の前回・前々回の写真と並べ、違いを示す
  7. 【自動】 報告書に載せる候補を、観察の項目ごとに提示する
  8. 【人】 研究員が下書きを確かめ、判断を書き足す
  9. 【人】 載せる写真を決める
  10. 【自動】 決まった写真をファイル名を整えて報告書の様式へ配置する
  11. 【人】 上司がレビューする

自動化されるのは「不備の検出」「紐づけ」「所見の下書き」「前回との比較」「候補の提示」「配置」の6つです。残るのは、所見の確認と判断の記述です。

合否も原因も判定しません。 「不合格」「めっきの密着不良が原因」といった判断は研究員が行います。この構成が書くのは、見えている状態の記述までです。

数値の測定もさせません。 膜厚、ピットの深さ、腐食面積率は測定装置と画像解析のソフトで測ります。「膜厚は約12マイクロメートル」といった数値を生成AIに出させないでください。

撮影の不備の検出が、実は最も価値のある部分です。 撮った直後に「スケールが写っていません」と分かれば、その場で撮り直せます。報告書を書く段階で気づくのとは、影響がまったく違います。

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

構成図
撮影(実体顕微鏡 / マイクロスコープ / 一眼レフ)
   │
   ▼ 共有フォルダへ移す(試験ごとのフォルダ)
   │
   ▼【トリガー】フォルダへの保存を検知
Power Automate
   │
   ├──▶ 試験の情報を取得(電子実験ノート)
   │      ・試料名 / 試験条件 / 撮影の部位 / 倍率
   ├──▶ 同じ試料の過去の写真を取得
   ├──▶ 所見の型(観察の項目と語彙の一覧)を読み込む
   │
   ▼
Claude API(画像入力)
   │  ・撮影の不備の検出
   │  ・見えている状態の記述(所見の型に沿って)
   │  ・前回の写真との違い
   │  ・報告書に載せる候補の提示
   │  ・structured outputs でスキーマどおりのJSONを返させる
   │
   ├──▶ Files API に画像をアップロードして file_id で参照
   │
   ▼
所見シート(Word / SharePoint)
   │  ・写真 / 所見の下書き / 不備 / 前回との違い
   │
   ▼
研究員が確認 ──【人】所見を直し、判断を書き足す
   │
   ▼
載せる写真を決める ──【人】
   │
   ▼
報告書の様式へ配置 ──【自動】ファイル名も整える
   │
   ▼
上司のレビュー ──【人】
役割想定する製品代替候補
生成AIClaude API(画像入力)Gemini API、OpenAI API
連携Power AutomateMake、n8n
保管SharePointBox、Google ドライブ
電子実験ノート既存の電子実験ノート各社の製品
画像解析既存の画像解析ソフト顕微鏡の付属ソフト

顕微鏡の付属ソフトに自動判定の機能があるなら、まずそちらを確認してください。 膜厚の測定、粒子のカウント、面積率の算出は、画像解析のソフトのほうが正確です。自前で組む価値があるのは、数値では表せない状態を言葉にする部分です。

数値の測定と、状態の記述を分けてください。 この構成は後者だけを扱います。両方を1つの仕組みでやろうとすると、どちらも中途半端になります。

Claude API に画像を渡す方法は3つあります。リクエストの本文に埋め込む base64、公開されている画像のURL、Files API にアップロードして返る file_id です。

この構成では Files API を使ってください。 前回・前々回の写真と並べて比較する場面では、同じ画像を何度も送ることになります。base64 で埋め込むと、やり取りのたびに画像のバイト列がすべて送られ、リクエストが大きくなります。 file_id で参照すれば、枚数が増えてもリクエストは小さいままです。

複数の写真を1回のリクエストで渡せます。 比較や、書類の複数ページのような連続した画像を扱うのに向きます。渡すときは、それぞれの前に「Image 1:」「Image 2:」のような短いラベルを置いてください。 プロンプトの中でどの画像のことかを指せるようになります。

枚数と寸法の上限に注意が要ります。 1リクエストあたりの上限は、20万トークンの文脈長のモデルで100枚、それ以外で600枚です。1枚あたりの最大の寸法は8000×8000ピクセルです。ただし、1リクエストに20枚を超える画像を含めると、そのリクエストのすべての画像に、より厳しい寸法の上限が適用されます。 全プラットフォームで上限に収めるには、各画像のどちらの辺も2000ピクセル以下にするか、画像と文書のブロックを20以下に抑えてください。

1枚あたりのサイズの上限は、Claude API を直接使う場合で10MB(base64換算)です。 対応する形式は JPEG、PNG、GIF、WebP です。アニメーションには対応しておらず、最初のフレームだけが使われます。

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

Step1

処理の起点を決める

共有フォルダに写真が保存されたときを起点にします。

撮影の直後に処理が走ることが、この構成の要です。 不備の検出は、その場で撮り直せる時点で伝えなければ意味がありません。顕微鏡のPCから自動で同期されるフォルダを使ってください。

理想は、撮影から5分以内に結果が返ることです。 研究員がまだ試料を手元に持っている間に「スケールが写っていません」と伝われば、撮り直せます。

もう1つの起点として、試験の終了時があります。 その試験で撮った写真をまとめて処理し、報告書に載せる候補を提示します。 ここは急ぎません。夜間の処理で構いません。

再処理の入口も用意してください。 所見の型を更新したときに、過去の写真を処理し直せる形にしてください。

過去の写真の一括処理は、最初に1回だけ行います。 直近1年分を処理して、比較の土台を作ります。枚数が多いため、費用を見積もってから実行してください。

Step2

入力データを集める

データ中身取得元
写真試験片の外観、断面、表面、摩耗痕など顕微鏡・カメラ
撮影の情報倍率、照明、撮影の部位、撮影日時撮影の記録様式/機器のメタデータ
試験の情報試料名、材質、処理条件、試験条件、経過時間電子実験ノート
所見の型観察の項目、見る順序、使う語彙、書き方の例研究開発部の文書
撮影の基準スケールの入れ方、札の位置、推奨の倍率研究開発部の文書
過去の写真同じ試料・同じ部位の前回・前々回共有フォルダ
過去の所見過去の報告書の所見の文報告書
Step3

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

所見の型が、この構成の質を決めます。 自由に書かせると、人による違いがそのまま残ります。次の形で持ってください。

列例
観察の項目表面の変色
見る順序3(全体の外観 → 欠陥の有無 → 変色 → 付着物 の順)
使う語彙変色なし/わずかな変色/部分的な変色/全面の変色
程度の目安「部分的」は観察面の3割未満、「全面」は7割以上
書き方の例「観察面の左下約2割に、褐色の変色が認められる」
書いてはいけないこと原因の推定(「腐食による」と書かない)、合否の判断

「使う語彙」の列が、表現をそろえます。 4〜5段階の決まった語から選ばせることで、人による違いがなくなります。「微細な」「わずかな」「軽微な」が混在する状態を解消できます。

「程度の目安」を数値で書いてください。 「部分的」がどれくらいかを人によって違う感覚で判断されると、語彙をそろえた意味がありません。

「書いてはいけないこと」の列が、この構成では特に重要です。 所見は観察の記述であって、原因の推定ではありません。「腐食による変色」と書くと、それがそのまま報告書の結論になってしまいます。

撮影の基準も、次の形で整理してください。

撮影の種類必須確認すること
外観(全体)試料名の札、スケール試料の全体が入っているか
断面スケールバー、倍率の記載ピントが合っているか、樹脂の気泡がないか
表面(拡大)スケールバー、倍率照明のむらがないか
摩耗痕スケールバー、基準の方向痕の全長が入っているか

「確認すること」が、不備の検出の基準になります。 これを書かないと、何を不備とするかが決まりません。

過去の写真: 同じ試料・同じ部位のものを紐づけます。ファイル名の規則がそろっていないと紐づきません。 この構成を入れる前に、命名の規則を決めてください。

過去の所見: 表現をそろえる材料になります。直近1年の報告書から、所見の文を100件ほど抜き出してください。 良い例として渡します。

Step4

AIへ渡す前に整形する

  1. 画像の形式の確認 … JPEG、PNG、GIF、WebP のいずれかにします。顕微鏡のソフトが独自形式で出す場合は変換が要ります
  2. 寸法の調整 … 1リクエストに20枚を超える画像を含めるなら、各辺を2000ピクセル以下に縮小します。 縮小するとスケールバーの目盛りが読めなくなることがあるため、縮小前に読み取るか、20枚以下に分けるかを選びます
  3. Files API へのアップロード … 比較に使う画像は、アップロードして file_id で参照します
  4. 試験の情報の紐づけ … ファイル名か、撮影の記録様式から試料名と条件を取ります
  5. 過去の写真の取得 … 同じ試料・同じ部位の直近2回分を取ります
  6. ラベルの付与 … 複数枚を渡すとき、それぞれの前に「Image 1: 今回の断面」のような短いラベルを置きます

2の寸法の調整には、この構成に特有の悩みがあります。 縮小すると、スケールバーの目盛りや微細な欠陥が見えなくなります。一方、縮小しないと20枚を超えるリクエストで上限に触れます。

対処は2つです。 1つは、1回のリクエストに渡す画像を、今回1枚と過去2枚の計3枚に絞ること。 もう1つは、細部を見る用に切り出した部分画像を別に渡すこと。 前者を基本にしてください。

Claude は画像を28×28ピクセルの区画(視覚トークン)で見ます。 画像のコストは ⌈幅/28⌉ × ⌈高さ/28⌉ の視覚トークンになります。モデルごとに最大の解像度が決まっており、それを超える画像は処理前に縮小されます。 縮小されると文字が読みにくくなるため、あらかじめ適切な大きさに調整しておくほうが確実です。

Step5

AIに処理させる

2つの工程に分けます。

(1)撮影の不備の検出

判定内容
ピント主要な部分がぼけていないか
露出白飛び・黒つぶれがないか
スケールスケールバーまたは倍率の記載があるか
札試料名の札が写っているか
構図対象の全体が入っているか
照明むらや強い反射がないか

(2)所見の下書き

処理内容
観察の項目ごとの記述所見の型の項目と語彙に沿って
位置の記述「観察面の左下約2割」のように
前回との違い同じ部位の過去の写真と並べて
載せる候補の提示観察の項目ごとに代表的な1枚
判断できない点の明示写真からは分からないこと

合否も原因も判定させません。 「不合格」「密着不良が原因」といった記述を禁じてください。

数値も出させません。 「膜厚は約12マイクロメートル」「ピットの深さは0.3ミリメートル」といった値を生成AIに出させないでください。測定は測定装置と画像解析のソフトで行います。

個数も数えさせないでください。 公式の説明でも、物体の個数について「おおよその数は示せるが、常に正確とは限らない。特に小さな物体が多数ある場合は精度が落ちる」とされています。ピットの個数を数えさせる使い方は避けてください。

Step6

指示内容を固定する

あなたは材料の試験・観察の記録を支援する担当者です。
写真に見えている状態を、所見の型に沿って記述することが役割です。

【厳守事項】
- 合否を判定しないでください。
  「合格」「不合格」「基準を満たす」と書かないでください。
- 原因を推定しないでください。
  「腐食による」「密着不良が原因」「熱処理の不足と考えられる」と書かないでください。
  見えている状態だけを書いてください。
- 数値を出さないでください。
  膜厚、深さ、面積、粒径などの値を書かないでください。
  測定は測定装置で行います。
- 個数を数えないでください。
  「ピットが12個」と書かないでください。
  「複数のピットが認められる」までにとどめてください。
- 下の「所見の型」の語彙だけを使ってください。
  型にない表現で書かないでください。
- 位置は、観察面を基準に書いてください。
  「左下約2割」「中央付近」のように、割合か位置で示してください。
- 写真から判断できないことは「この写真からは判断できない」と書いてください。
  推測で補わないでください。
- 撮影の不備は、下の「撮影の基準」に照らして判定してください。
  一般的な写真の良し悪しで判定しないでください。
- 前回の写真と比べるときは、撮影の条件(倍率・照明・角度)が
  同じかどうかを先に確かめてください。
  条件が違う場合、違いが状態の変化によるものか撮影によるものかは
  判断できないと明記してください。
- 人物が写っている場合、その人が誰かを述べないでください。

【試験の情報(試料名 / 材質 / 処理条件 / 試験条件 / 経過時間)】
{test_info}

【撮影の情報(種類 / 倍率 / 照明 / 部位)】
{shot_info}

【所見の型(観察の項目 / 見る順序 / 使う語彙 / 程度の目安 / 書き方の例 / 書いてはいけないこと)】
{observation_template}

【撮影の基準(種類 / 必須 / 確認すること)】
{shooting_standard}

【過去の所見の例(良い書き方の見本)】
{past_observations}

Image 1: 今回の写真
Image 2: 前回の同じ部位(撮影日 {prev_date})
Image 3: 前々回の同じ部位(撮影日 {prev2_date})

「原因を推定しない」の指示が、この構成でもっとも重要です。 所見に原因が書かれると、それが報告書の考察へそのまま流れます。考察は研究員が、他の測定結果と合わせて行うものです。

「数値を出さない」も妥協できません。 生成AIが出した「約12マイクロメートル」が報告書に載ると、測定していない数値が測定結果として扱われます。

「個数を数えない」の指示は、公式の説明に基づくものです。 個数の推定は正確とは限らず、小さな物体が多数あるときは特に外れます。 ピットや介在物の数は、画像解析のソフトで数えてください。

「撮影の条件が同じかを先に確かめる」の指示は、比較の場面で効きます。 倍率が違う写真を並べて「進行している」と書かれると、誤った結論になります。

「人物が誰かを述べない」の指示も入れてください。 公式の説明で、画像に写った人物の名前を挙げることには対応しておらず、求められても応じないとされています。試験の写真に手元が写ることがあるため、明記しておくほうが安全です。

Step7

出力形式を固定する

{
  "photo_id": "",
  "file_name": "",
  "test_id": "",
  "sample_name": "",
  "shot_type": "appearance | cross_section | surface | wear_track",
  "magnification": "",
  "defects_in_shot": [
    { "type": "focus | exposure | scale_missing | label_missing | framing | lighting", "detail": "", "severity": "high | low" }
  ],
  "retake_required": false,
  "observations": [
    {
      "item": "",
      "term": "",
      "location": "",
      "sentence": "",
      "confidence": "high | medium | low",
      "not_determinable": false
    }
  ],
  "comparison": {
    "conditions_match": true,
    "condition_note": "",
    "changes": [ { "item": "", "direction": "increased | decreased | unchanged | undeterminable", "sentence": "" } ]
  },
  "recommended_for_report": false,
  "recommendation_reason": "",
  "notes_for_researcher": []
}

Claude API で出力をスキーマに沿わせるには、output_config の format に json_schema を指定します。 古い output_format は非推奨です。

スキーマには制約があります。 required と additionalProperties: false は使えますが、minimum / maximum / minLength / maxLength といった数値・文字列の制約は使えません。 enum は文字列・数値・真偽値・null に限られます。再帰的なスキーマにも対応していません。

最初にスキーマを使うときは、文法のコンパイルに時間がかかります。 結果は24時間キャッシュされますが、スキーマの構造やツールの構成を変えるとキャッシュが無効になります。 所見の型を頻繁に変える運用では、この待ち時間が出ることを踏まえてください。

retake_required が、この構成でいちばん早く効くフィールドです。 撮り直しが要ると分かれば、その場で撮り直せます。

confidence を所見ごとに持たせている点が実務では重要です。 「変色が認められる」の確からしさと、「微細な割れが認められる」の確からしさは違います。低い所見は研究員が必ず確かめます。

conditions_match を比較の中に置いている理由があります。 撮影の条件が違えば、比較の結論は出せません。false のときは changes を undeterminable にして、条件の違いを condition_note に書きます。

not_determinable のフラグも要ります。 「断面の樹脂に気泡があって、その部分は判断できない」という状態を表せます。

Step8

システムへ連携する

報告書への自動反映は行いません。

出力先内容
Word(SharePoint)所見シート。写真・下書き・不備・前回との違い
Teamsretake_required が true の写真の通知(撮影直後)
電子実験ノート研究員が確認してから記録
共有フォルダファイル名を整えた写真

撮り直しの通知だけは、急いで届けてください。 撮影から時間が経つと、試料が処分されたり状態が変わったりします。Teams への通知は、この1点に限って即時にしてください。

所見の自動記録はしません。 研究員が確認して、電子実験ノートへ記録します。AIが書いた文がそのまま記録に残ると、確認されないまま報告書へ流れます。

ファイル名の整形は自動で構いません。 試料名・条件・部位・倍率の規則に沿って付け直します。ここは判断が要らない機械的な処理です。

画像は処理後に残りません。 公式の説明では、アップロードした画像はリクエストの処理の間だけ保持され、処理後に自動的に削除されるとされています。自社の記録としては、共有フォルダの原本を保管してください。

Step9

人が確認する

研究員の確認は必ず残します。

状態確認
retake_required が true直ちに確認して撮り直す
confidence が low の所見写真を見て自分で判断する
not_determinable の項目判断できない理由が妥当か
conditions_match が false比較の結論を出さない
recommended_for_report が true載せるかを決める
すべて high の所見通し読みして直す

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

  • 写真と所見の下書きを並べて表示する
  • confidence が低い所見に印を付ける
  • 前回・前々回の写真を並べて表示する
  • 所見の型の語彙を選択肢として出す(直すときに使う)
  • 直した内容を記録する

4つ目が効きます。 研究員が所見を直すとき、自由入力だと型から外れた表現に戻ります。語彙を選択肢で出せば、直しても表現がそろいます。

5つ目は、この構成を育てる材料になります。 どの項目で、どう直されているかが分かれば、所見の型か指示を直せます。

「判断」の記述は、研究員が書き足します。 所見が「観察面の左下約2割に褐色の変色が認められる」なら、その意味(試験条件との関係、次に何を見るか)は研究員が書きます。 この構成は、そこへ至る前の整理までです。

Step10

例外に対処する

起きること対応
画像が独自形式で読めないJPEG・PNG・GIF・WebP へ変換する
アニメーションGIFを渡した最初のフレームだけが使われる。静止画にする
1リクエストに20枚を超える各辺2000ピクセル以下にするか、20枚以下に分ける
縮小でスケールバーが読めなくなる渡す枚数を3枚に絞って縮小しない
画像が8000×8000ピクセルを超える上限内に収める
1枚が10MBを超える圧縮するか解像度を下げる
200ピクセル未満の小さな画像誤りが出やすい。 拡大して撮り直す
回転した画像誤りが出やすい。 向きを直してから渡す
圧縮を繰り返した画像劣化で文字が読めなくなる。元データから作り直す
AIが原因を推定した指示で禁止する。テストで確認する
AIが数値を出した禁止する。測定は測定装置で
AIが個数を数えた禁止する。個数の推定は正確とは限らない
撮影の条件が違う写真を比較したconditions_match を false にして結論を出さない
人物の手元が写っている人物の特定はしない。この構成では問題にならない
所見の型を更新した過去の写真を処理し直せる入口を用意する
医療や検査の判定に使われるこの構成の対象外。 資格や認定が要る判定には使わない

最後の項目は、明確に線を引いてください。 公式の説明でも、一般的な医療画像の分析はできるが、CTやMRIのような複雑な診断画像の解釈を想定した設計ではなく、出力を専門的な医療上の助言や診断の代わりとみなすべきではないとされています。非破壊検査の合否判定など、資格や認定に基づく判断にも使わないでください。

Step11

記録を残す

この記録は、所見の型と撮影の基準を育てる材料になります。

  • 処理した写真と、そのときの試験の情報
  • 検出した撮影の不備と、撮り直しの有無
  • 所見の下書きと、研究員が直した後の文
  • confidence と、直された頻度の関係
  • 比較の結果と、撮影の条件の一致・不一致
  • 報告書に載せる候補と、実際に載った写真
  • 所見の型に足した語彙

「下書きと直した後の文」を必ず両方残してください。 どこが直されているかが、この構成の改善点そのものです。特定の観察の項目で毎回直されているなら、その項目の語彙か目安に問題があります。

「confidence と直された頻度の関係」も見てください。 high なのに毎回直されているなら、確からしさの判定が当てになりません。その場合は、すべての所見を人が見る扱いに変えてください。

試験の写真には、未公開の技術情報が含まれます。 試料の形状、処理の条件、内部の構造。外部のAIサービスへ渡してよいかを、知財部と確認してください。

保存期間は、試験記録の保存期間に合わせてください。 顧客へ提出した試験結果の根拠となる写真は、長期の保存が求められることがあります。

04実装レベルの3段階

最小構成:写真をチャット画面に貼り、所見と不備を出させる / 記述と検出
半自動化:フォルダへの保存をトリガーに、不備の検出・所見の下書き・所見シートの作成まで / 撮影後の処理
本格構成:上記+前回との比較+載せる候補の提示+ファイル名の整形+直しの記録 / 報告書の手前まで

半自動化の時点で、4分が2分程度になります。 所見を白紙から書く作業が消えるためです。本格構成では1.2分になりますが、減るのは選別と整理の手間です。 撮り直しの通知だけは、最小構成の次にすぐ作ってください。 順番としては、「不備の検出と即時通知」→「所見の下書き」→「比較」の順が効きます。不備の検出は所見より実装が軽く、効果がはっきりしています。 本格構成の「直しの記録」が、この構成を育てます。 どの項目でどう直されているかが分かれば、所見の型を直せます。半年で、直される頻度が半分になることを目指してください。 「前回との比較」は、本格構成でも慎重に扱ってください。 撮影の条件がそろっていない写真が多いと、比較の価値が出ません。先に撮影の条件をそろえる運用を固めてから、比較の機能を足すほうが確実です。

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

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

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

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

AI活用について相談する

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

向いている
  1. 試験や観察で月に300枚以上の写真を撮り、そこから所見を書いている企業。所見の書き方が研究員によって違い、報告書の体裁をそろえるのに時間がかかっている場合。撮影の不備(ピントのずれ、スケールの写し忘れ、試料名の写り込みなし)に後から気づくことがある場合。試験のやり直しが撮影の不備で発生している場合。
向いていない
  1. 写真が月に数十枚の組織。観察の対象が自動測定装置で数値として取れる場合。写真の判定に法令上の資格や認定が求められる場合(医療診断、非破壊検査の判定など)。写真の撮影条件が定まっておらず、毎回違う条件で撮っている場合。

07最小構成で試す方法

  1. 撮影の種類を1つ選ぶ(件数の多い「断面」など)
  2. その種類の写真を30枚用意する(不備のあるものを5枚混ぜる)
  3. 所見の型を、その種類について作る(観察の項目5つ、語彙付き)
  4. 撮影の基準を書く(必須のもの、確認すること)
  5. 生成AIのチャット画面に、型と写真を貼り付けて所見を出させる
  6. 実際の報告書の所見と突き合わせる

見るのは次の5点です。

見る点判断
仕込んだ不備5件の検出5件中5件。 外すなら基準の書き方を見直す
所見が型の語彙に収まっているか型にない表現が出ていないか
実際の所見と内容が一致するか7割以上。外れる項目を特定する
原因の推定・数値・個数が混ざっていないか1件でも混ざったら指示を直す。妥協しない
confidence が低い所見が実際に外れているか当てになるかを確かめる

1つ目を最優先で確かめてください。 不備の検出が、この構成でいちばん早く効く機能です。スケールの写し忘れ、札の不在、ピントのずれを意図的に作った写真を用意してください。

4つ目は妥協しないでください。 数値が1件でも出たら、それは報告書へ流れる危険があります。指示を直して、再度30枚で確かめてください。

次に、比較の機能を試してください。 同じ試料の前回・今回の写真を並べて渡し、撮影の条件が違う組み合わせも混ぜます。 条件が違うのに「進行している」と書かれたら、指示を直してください。

枚数の上限も、この段階で確かめてください。 今回1枚+過去2枚の3枚を渡す形が基本ですが、20枚をまとめて渡す運用を考えているなら、寸法の上限に触れないかを試してください。

★4にしている理由が、ここに表れます。 所見の型を作る作業、撮影の基準を書く作業、数値や原因を書かせない指示の調整。どれも研究開発部の中でしかできず、時間がかかります。

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

問題対策
AIが原因を推定する禁止する。テストで必ず確認する
AIが数値を出す禁止する。測定は測定装置で
AIが個数を数える禁止する。推定は正確とは限らない
所見の型がなく表現がばらつく語彙と程度の目安を書く。ここが本体
20枚超のリクエストで寸法の上限に触れる3枚に絞るか、各辺2000ピクセル以下に
縮小でスケールバーが読めない渡す枚数を絞って縮小しない
撮り直しの通知が遅い撮影直後に届ける。遅いと意味がない
撮影の条件が違う写真を比較するconditions_match を判定させる
200ピクセル未満や回転した画像誤りが出やすい。前処理で弾く
圧縮を繰り返した画像を使う元データから作り直す
アニメーションGIFを渡す最初のフレームだけ。静止画にする
ファイル名の規則がそろっていない先に決める。過去分もそろえる
所見が自動で記録される研究員の確認を挟む
医療や検査の判定に使う対象外。 資格や認定が要る判断には使わない
直しの記録を残していない残す。改善の材料が失われる

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

この構成で扱うデータ: 試料の形状と内部構造、処理の条件、試験の条件と結果。未公開の技術情報そのものです。

  1. 知財部の確認 … 試験の写真には、出願前の発明につながる情報が含まれることがあります。外部のAIサービスへ送る前に、知財部の確認を経てください。 新規性は公然と知られていないことが要件なので、事業者との契約で秘密が保たれる形かを確かめてください
  2. 顧客からの受託試験 … 顧客の試料を試験している場合、秘密保持契約の対象になります。 第三者への開示に当たらないかを、契約に照らして確認してください。契約次第では、この構成を使えません
  3. 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます。技術情報を扱う以上、必須条件です
  4. 画像の保持 … アップロードした画像はリクエストの処理の間だけ保持され、処理後に自動的に削除されます。 自社の記録としては、共有フォルダの原本を保管してください
  5. アクセス権限 … 所見シートには、試験の条件と結果が集まります。閲覧を研究開発部に限定してください
  6. 合否の判断との分離 … この構成は合否を判定しません。 判定は所定の基準に照らして人が行います。所見シートにその旨を明記してください
  7. 数値の扱い … 生成AIが出した数値を測定値として扱わないでください。 測定は測定装置と校正された手順で行います。数値を出させない指示を、必ずテストで確認してください
  8. 医療・検査への適用の制限 … 公式の説明で、複雑な診断画像の解釈を想定した設計ではなく、出力を専門的な医療上の助言や診断の代わりとみなすべきではないとされています。非破壊検査の合否判定など、資格や認定に基づく判断にも使わないでください
  9. 人物の識別 … 画像に写った人物の名前を挙げることには対応しておらず、求められても応じません。 試験の写真に手元が写る場合も、識別の目的に使わないでください
  10. 試験記録としての位置づけ … 所見の下書きは記録ではありません。研究員が確認して記録したものが試験記録です。 顧客へ提出する試験結果の根拠として、下書きをそのまま使わないでください
  11. 自動実行してよい範囲 … 不備の検出、所見の下書き、比較、候補の提示、ファイル名の整形までです。所見の確定、記録への反映、合否の判断、報告書の作成は人が行います

誤りが起きた場合のリスクは、誤った所見が確認されないまま報告書へ流れること、逆にAIが出した数値や原因が測定結果・結論として扱われることです。後者のほうが重大です。 数値・原因・個数を書かせない設計を、テストで必ず確認してください。また、所見の確認を省かない運用を守ってください。

10まず何から始めるか

1週目:撮影の基準を書く

撮影の種類ごとに、必須のもの(スケール、札、倍率の記載)と確認することを書きます。1日で書けます。 これだけで、不備の検出が始められます。

2週目:不備の検出を30枚で試す

不備のある写真を5枚混ぜた30枚で試します。5件中5件検出できるかを確かめてください。 ここが動けば、この構成のいちばん早く効く部分が確保できます。

3週目:所見の型を1種類だけ作る

件数の多い撮影の種類を1つ選び、観察の項目5つと語彙、程度の目安を書きます。ベテラン研究員に「この写真で何を見ているか」を1件ずつ聞いてください。 この作業がこの構成の本体で、いちばん時間がかかります。

4週目:所見の下書きを30枚で試す

実際の報告書の所見と突き合わせます。数値・原因・個数が混ざっていないかを、1件ずつ確かめてください。 混ざっていたら指示を直して、再度確かめます。

2か月目: 半自動化を1種類で回します。撮り直しの通知を撮影直後に届ける仕組みを、最初から入れてください。 これが遅いと、この構成の価値の半分が失われます。

3か月目以降: 撮影の種類を増やし、前回との比較を足します。同時に、下書きと直した後の文を必ず記録してください。 どこが直されているかが、所見の型の改善点です。

半年後: 直される頻度が減っているかを見てください。減っていれば、所見の型が実態に合ってきたということです。 同時に、撮影の不備が原因のやり直しが何件減ったかを数えてください。 時間の削減より、こちらのほうが研究所にとっての価値は大きいはずです。

1年後には、所見の型そのものが資産になります。 何を見て、どう書くかが文書になっていれば、新人の教育にそのまま使えます。 この構成を作る過程で、暗黙知が言葉になることが、いちばん長く残る成果です。


11関連ユースケース

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

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

技術仕様確認日:2026-09-25/最終更新:2026-09-25
確認した内容情報源確認日
Claude API に画像を渡す方法が base64・URL・Files API の file_id の3種類であること。複数の画像を1リクエストで渡して一緒に分析でき、各画像の前に「Image 1:」のような短いラベルを置くとよいこと。1リクエストあたりの上限が20万トークンの文脈長のモデルで100枚、それ以外で600枚であること。1枚の最大の寸法が8000×8000ピクセルで、1リクエストに20枚を超える画像を含めるとすべての画像により厳しい寸法の上限が適用されること(各辺2000ピクセル以下にするか、画像と文書のブロックを20以下に抑える)。1枚の最大サイズが Claude API 直接利用で10MB(base64換算)であること。対応形式が JPEG・PNG・GIF・WebP で、アニメーションは非対応で最初のフレームだけが使われること。画像を28×28ピクセルの区画(視覚トークン)で見て、コストが ⌈幅/28⌉ × ⌈高さ/28⌉ になること。制限事項として、画像中の人物の名前を挙げることには対応せず応じないこと、低品質・回転・200ピクセル未満の非常に小さい画像では誤りが出やすいこと、物体の個数はおおよその数しか示せず特に小さな物体が多数あるときは正確とは限らないこと、複雑な診断画像(CT・MRI)の解釈を想定した設計ではなく専門的な医療上の助言や診断の代わりとみなすべきでないこと。アップロードした画像はリクエストの処理の間だけ保持され処理後に自動的に削除されることAnthropic Docs: Vision2026-09-25
Claude API で出力をスキーマに沿わせる際、output_config の format に json_schema を指定すること(output_format は非推奨)。required と additionalProperties: false は使えるが、minimum / maximum / minLength / maxLength は使えず、enum は文字列・数値・真偽値・null に限られ、再帰的なスキーマには対応しないこと。最初の使用時に文法のコンパイルの待ち時間があり、結果は24時間キャッシュされるが、スキーマの構造やツールの構成を変えると無効になることAnthropic Docs: Structured outputs2026-09-25
Gemini API がテキスト・画像・動画・音声の入力を扱え、system_instruction でモデルの振る舞いを設定できること(代替候補として確認)Gemini API Docs: Text generation2026-09-25

観察の項目、所見の語彙、撮影の基準、試験記録の保存期間は、組織と試験の種類によって異なります。この部分は自社の研究開発部門の定めに応じた個別対応が必要です。 試験の合否の判定、測定値の取得は、所定の基準と校正された装置・手順によって行ってください。この記事は試験の判定や測定の結果を示すものではありません。医療上の診断、および資格や認定に基づく検査の判定には使用しないでください。未公開の技術情報や顧客の試料の情報を外部のAIサービスへ渡してよいかは、自社の知財部門と、顧客との秘密保持契約の確認が必要です。

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

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

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

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