見出し画像

エクセル・ワードのコピペ地獄から脱却!AIで情報を自動抽出&リスト化するプロンプト術 | AIによる現場改革

こんにちは、Akira55です。


現場で品質管理や事務作業をしていると、Wordの報告書やExcelの自由記述欄から必要な情報を探し出し、別の管理表へ手作業で転記する……そんな作業に追われていませんか?


人によって書き方が違うため「表記ゆれ」が発生し、それを整えるための「コピペと修正の無限ループ」に陥る。これは、多くの現場エンジニアやバックオフィス担当者の貴重な時間を奪う、まさに「コピペ地獄」です。

AIという「理想」と、製造現場という「現実」。この両端で格闘しながら得た気づきや試行錯誤を言語化し、同じように最前線で踏ん張る方々と知見を共有したいと思い、今回はこの地獄から脱却するための「AIを活用した情報抽出&リスト化のプロンプト術」をご紹介します




 基本編:AIに情報を「抽出」させる


長文のテキストや非構造化データ(フォーマットが決まっていない文章)から、特定の情報だけを見つけ出すのは、実は生成AIが最も得意とする領域の一つです。

製造現場に例えるなら、「自動外観検査装置」のようなものです。人間の目で一つひとつウェーハのキズを探すのではなく、AIに「日付」「製品名」「起きた事象」といったターゲット(欠陥)の条件を与え、文章の中から一瞬で抜き出してもらいます。

【プロンプト例】

以下の作業日報から、「発生日時」「対象製品ロット」「トラブルの概要」を抽出し、表形式で出力してください。

これだけでも手作業で文章を読む手間は省けますが、QAエンジニアとしてはもう一歩踏み込んだ「品質管理」をAIに求めたいところです。

なぜなら、AIに自由記述で抽出させると、結局「A製品」「製品A」「Product-A」といった表記ゆれ(データの品質バラツキ)が発生し、後からピボットテーブルなどで集計できなくなってしまうからです。



応用編:ここが肝!「事前リスト」から最適な回答を選択させるテクニック


データの品質を担保し、後続の処理を自動化するための最大の肝。それは、AIに自由に答えさせるのではなく、「事前に定義したリストの中から、最も適切なものを選択させる」という制約をかけることです。

私たちQAエンジニアは、製造工程において「変数の制御」を何よりも重視します。

AIへのプロンプト設計も同じで、出力結果のブレ(変数)を極限まで減らすための「規格(スペック)」を設けるのです。

※ただし、AIが現場を理解できない最大の理由は「社内、専門用語」です。 AIが正確に判断できるよう、 NotebookLM に社内の技術文書や過去の報告書を読み込ませて 「社内専用・用語翻訳リスト」 を作成することをオススメします(具体的な方法はこちら)。 このような下準備をしておくことで、AIの選択精度は飛躍的に向上します。


この「選択式」にすることで、データは完全に標準化され、誰が書いた曖昧な報告書であっても、データベース上で一元管理できる美しい状態に変換されます。



具体例:不具合報告を標準エラーコードにマッピングする


では、実際の現場で使える具体的なプロンプトのケーススタディを見てみましょう。

例えば、顧客や現場から送られてくる「自由記述の不具合報告」を、社内の「標準エラーコード」に自動でマッピング(紐付け)させるシナリオです。

【プロンプト例】

あなたは品質保証部のデータアナリストです。

以下の【現場からの報告テキスト】を読み込み、内容を分析した上で、【社内標準エラーリスト】の中から最も当てはまるエラーコードを1つだけ選択して出力してください。

# 制約事項
・抽出結果は「エラーコード」と「その理由(50文字以内)」のみを簡潔に出力すること。
・リスト以外の独自の表現やコードは絶対に作成しないこと。

# 社内標準エラーリスト
・E-001:異物混入(パーティクル、ホコリ、毛髪など)
・E-002:寸法不良(サイズ違い、規格外など)
・E-003:外観異常(キズ、変色、打痕など)
・E-004:その他・分類不能

# 現場からの報告テキスト
「昨日午後、Aラインの洗浄工程を終えたロットにおいて、ウェーハ表面の中央付近に白く濁ったような跡が複数見られました。サイズは規定内ですが、拭き取っても落ちません。」

このように指示を出すことで、AIは文脈から「白く濁った跡=変色/外観異常」と判断し、ブレることなく「E-003」を返してくれます。人間の解釈による分類のバラツキも防げるため、まさに一石二鳥の品質管理術です。



さらに業務を効率化するために


ここまでのプロンプト術をマスターすれば、目の前のコピペ作業は劇的に楽になります。しかし、「攻めのQA」を目指すのであれば、これをさらにスケール(大規模化)させましょう。

数百、数千件のデータを処理したい場合は、このプロンプトのロジックを GAS(Google Apps Script) や Python と組み合わせて自動化ツールにしてしまうのが最適です。


「プログラミングなんて書けない……」と身構える必要はありません。Google環境(Gemini / スプレッドシート / Gmail)を組み合わせることで、プログラミング知識ゼロの私でも理想の仕組みを構築することができたように、AIを「編集パートナー」としてコードを書かせれば、「GASの壁」をGeminiで突破することは十分に可能です。

スプレッドシートに現場の報告が入力された瞬間、GASが裏側でGemini APIを叩き、標準エラーコードを自動で隣のセルに入力していく。そんな自動化ラインが完成すれば、あなたの時間は圧倒的に自由になります。




おわりに:余白の時間を「真因追及」に充てる


データの転記や表記ゆれの修正は、製品の品質を直接高める作業ではありません。

便利なツールに振り回されるのではなく、面倒なデータクレンジング(整理)をAIに任せ、私たち人間は「なぜその不良が起きたのか(真因分析)」「どうすれば再発を防げるか」という本質的な問いにリソースを集中させる。それこそが、テクノロジーを味方につけた「攻めのQA」の姿だと信じています。

皆さんのデスクには、まだ「コピペ地獄」が潜んでいませんか?


もし心当たりがあれば、まずは1件の報告書をAIに読み込ませて、抽出・選択させることから試してみてください。

皆さんの職場でも、AIを使った「ちょっとした業務改善」の成功体験はありますか? もしよろしければ、ぜひコメント欄で現場のリアルな声を教えていただけると嬉しいです。

本日も最後までお読みいただき、ありがとうございました。
それでは、また!


今回の記事のような「QAエンジニアの知見×生成AI」。理論だけでなく、実務で『本当に動く』活用事例を公開中です。



いいなと思ったら応援しよう!