生成AI活用事例3選|職務経歴書の自動入力・サムネイル自動生成・お薬手帳OCRの実装プロジェクト
株式会社SPが手がけた生成AI導入プロジェクトのうち、人材サービス企業の職務経歴書の自動入力、EC事業者のサムネイル自動生成、メディカル企業のお薬手帳読み取りの3件を取り上げ、生成AIに何を任せ、どこを既存技術と人の確認で固めたかを実装レベルで解説します。
転記業務の工数が約半分以下になった事例や、認識精度92.5%を達成した医療分野の事例など、いずれもPoCで終わらず本番運用に乗ったプロジェクトを扱っています。
生成AIに「任せる範囲」をどう決めるかで結果が変わります
「自社の業務にどう使えばよいかわからない」「PoC止まりで本番に乗せられない」。生成AIへの関心が高まる中で、こういった声はまだ多く聞かれます。
SPがこれまで構築してきたシステムを振り返ると、本番運用まで到達したプロジェクトには共通点があります。生成AIを万能な処理エンジンとして扱わず、「人が読んで判断していた非構造データの解釈」だけを生成AIに任せ、その前後を既存技術と人の確認で固めているという点です。
ルールで書ける処理はプログラムに任せ、精度が業務要件に直結する箇所には必ず人の承認を残しています。
業種も課題の性質も異なる3つのプロジェクトについて、それぞれの背景・システム構成・成果を取り上げます。
3つの事例で生成AIが担っている役割
| 事例 | 業種 | これまでの状態 | 生成AIが担う判断 | 成果 |
|---|---|---|---|---|
| 01 職務経歴書の自動入力 | 人材サービス | フォーマットの異なる書類を手作業で転記 | 書式の異なる文章から経歴を構造化 | 入力工数が約半分以下、転記ミスがほぼゼロ |
| 02 サムネイル自動生成 | EC・アパレル | デザイナーが1枚ずつ手作業で制作 | 商品情報からの訴求コピー・デザイン案の生成 | 候補生成の工数を削減し、CTRで効果測定が可能に |
| 03 お薬手帳の読み取り | 医療(人間ドック) | 難読な薬剤名を受診者が手入力 | OCRテキストから薬剤名・容量を同定 | 認識精度92.5%を達成し、当日の補正作業が減少 |
事例 01|職務経歴書の手作業入力を自動化した人材会社の業務改善
分野:人材業界 / DXコンサルティング
クライアント:首都圏を拠点に転職支援・人材派遣を手がける人材サービス企業
生成AIの役割:フォーマットの異なる職務経歴書から、基本情報と職務経歴を構造化データとして抽出しています
背景・課題
人材紹介・派遣を手がける企業では、求職者から提出されるExcel・Word・PDF形式の職務経歴書を、独自の管理システムへ手作業で転記する業務が常態化していました。書類ごとにフォーマットが異なるうえ、担当者が入力内容を確認しながら一件ずつ登録するため、処理に多くの工数がかかっていました。
手作業による転記ミスも発生しやすく、入力後の確認・修正対応がさらなる工数を生んでいました。求職者数の増加にともなって作業量も増え続けており、人的コストと処理速度の両面で限界を感じていました。
加えて、生成AIに個人情報を渡さないというコンプライアンス要件があり、自動化の仕組みを構築する上でこの要件をどう満たすかも重要な課題でした。
職務経歴書の読み取りから管理システムへの登録まで、一気通貫で自動化
Pythonで各ファイル形式からテキストを抽出し、そのデータを生成AIで構造化した上で、管理システムのAPIを通じて登録するパイプラインを構築しました。処理の最後には担当者による確認・承認ステップを設け、AIが出力した内容を人間がチェックしてから登録が確定する設計にしています。

システム概要
PII情報への二重の対策でコンプライアンス要件を守る
個人情報を生成AIに渡さないために、プログラム側とインフラ側の2段階で対策を講じました。まずプログラム側で、氏名・年齢・住所などのPII(個人を特定できる情報)を生成AIへ送信する前にプレースホルダーへ置き換えてマスキングし、生成AIから返ってきた結果に対してプレースホルダーを元の情報へ復元する仕組みを実装しています。
さらに、プログラム側のマスキングで漏れが生じた場合の保険として、AWS BedrockのGuardrails(AIへの入出力を検査してポリシー違反を検知する機能)による検知を二重に設けました。どちらか一方ではなく両方を組み合わせることで、コンプライアンス要件に対して堅牢な構成にしています。
並列処理による高速化
氏名・年齢などの基本情報の抽出と職務経歴の抽出を、別々のAIリクエストとして並列実行する設計にしました。それぞれ独立した処理として同時に走らせることで、逐次処理に比べて全体の処理時間を大きく短縮しています。
長尺経歴書の分割処理モード
職歴の記載が25件を超えるような長い経歴書については、期間の区切りを手がかりにテキストを複数ブロックへ分割し、並列処理する分割処理モードへ自動で切り替わる仕組みを実装しました。経歴書の分量に応じて処理方式を動的に変える設計にすることで、件数の多い書類でも安定した抽出精度を維持しています。
管理システムへの登録前の事前チェック
AIが構造化した内容は、管理システムのAPIを通じて登録される前に担当者の確認画面を経由する設計にしました。抽出された職務経歴の内容・件数・フォーマットを人間が目視で確認した上で承認操作を行う運用にすることで、想定外の変換結果をシステムへ取り込む前に検知できるようにしています。
フォーマットが特殊な経歴書や、抽出結果に不整合が疑われる箇所については、確認画面上にアラートを表示し、担当者が重点的に確認できるようにしました。また、確認画面上で内容を直接編集・修正できる機能も設けており、修正を加えたい場合でも担当者が手動で正した上で登録できるようにしています。
成果
これまで担当者が手作業で行っていた転記・入力作業が自動化されました。処理後の確認・承認フローは残しながらも、入力にかかる工数は大きく削減され、導入先からは工数が約半分以下になったとの声をいただいています。
特に手作業による転記ミスはほぼゼロになり、入力後の確認・修正対応にかかっていた工数も大きく減っています。
技術スタック
Python・AWS Lambda・AWS Bedrock(Guardrails)・Amazon DynamoDB
事例 02|サムネイル自動生成システムの構築
分野:新規事業支援 / DXコンサルティング
クライアント:アパレル・生活雑貨など複数ブランドを自社ECで展開する企業
生成AIの役割:商品情報からキャッチコピーと訴求パターンの案を生成し、デザイン候補の方向性を決めています
背景・課題
ECサイト運営や広告クリエイティブ制作において、商品ごとのサムネイル画像を作成・更新する作業は継続的に発生します。デザイナーや担当者が毎回手動でレイアウトを調整し、複数パターンを試しながら選定するプロセスは、人手と時間を消費していました。
さらに課題だったのは、どのデザインが実際のクリック率につながるかが感覚に頼りがちで、改善の根拠が不明確なまま運用されていた点です。制作物は増え続けるものの、何が効いたのかが蓄積されない状態になっていました。
サムネイル候補を自動生成し、CTRデータと連動したクリエイティブ改善サイクルを実現
商品情報・キャッチコピー・画像を入力するだけでサムネイル候補を自動生成し、実際のクリック率データをもとに次の生成へ反映するフィードバックループを構築しました。感覚に頼っていたクリエイティブ選定を、データに基づいた継続改善へ変えています。

システム概要
生成AIが訴求の切り口を出し、画像処理がレイアウトを組む二層構成
商品情報とブランドのトーンをもとに、生成AIでキャッチコピーの候補と訴求パターン(機能訴求・価格訴求・季節訴求など)を出力し、その方向性に沿ってレイアウトを組み立てる構成にしました。文言や訴求軸の発想は生成AIが担い、文字位置・余白・トリミングといった再現性が求められる処理はPython・OpenCV・Pillow・NumPy・scikit-imageによる画像処理パイプラインが担う二層構成にすることで、ブランドのレギュレーションを外さないまま候補数を増やせるようにしています。
商品情報を入力するだけでサムネイル候補を10〜20枚自動生成
入力された画像・キャッチコピー・商品情報をもとに、サムネイル画像の候補を10〜20枚程度自動生成します。従来はデザイナーが1枚ずつ作っていた工程が、選ぶ工程へ置き換わりました。
担当者が最終調整しやすいUI設計
生成後の画像は明るさ・コントラスト・テキストレイアウトの調整が可能なUIも提供しており、担当者が仕上がりを確認しながら微調整を行いやすい設計にしています。完全自動化ではなく、最終判断は人が行う余地を残しています。
クリック率データを次の生成に活かすフィードバックループ
実際に利用されたサムネイル画像のパフォーマンスを、Google Analyticsのクリック率データと紐付けて評価する仕組みも導入しています。どのデザインパターンがCTRを高めるかを定量的に蓄積し、次回の生成パラメータやコピーの方向性の調整に活用しています。運用を重ねるほど判断材料が増えていく構造になっています。
成果
クリエイティブ候補の生成にかかるデザイン工数が削減され、クリック率ベースの定量的な効果測定ができるようになりました。「なんとなく良さそう」だったデザイン選定が、実績データを根拠に議論できる状態へ変わり、改善サイクルが動き始めています。
技術スタック
Python・OpenCV・Pillow・NumPy・scikit-image・OpenAI API・Google Analytics
事例 03|お薬手帳の画像から薬剤情報を読み取るシステム(医療分野)
分野:医療 / DXコンサルティング
クライアント:全国で会員制人間ドックを展開するメディカル企業
生成AIの役割:OCRで抽出した不揃いなテキストから、薬剤名と容量を識別・整形しています
背景・課題
受診者は来院前にWEBで事前問診を行い、服用中の薬剤情報を自分で入力します。紙のお薬手帳の写真やお薬手帳アプリのスクリーンショットを手元に持っていても、薬の名前は難読なものが多く、正確に手入力するのは手間がかかります。そのため入力ミスや入力漏れが生じやすく、薬剤情報を未入力のまま提出してしまう受診者も少なくありませんでした。
こうした不備があると、当日来院した際に現場スタッフが事前問診の内容を確認し、誤りがあれば補正するという対応が都度発生していました。この確認・補正作業は受診者ごとに繰り返し発生するため現場スタッフへの負荷が高く、業務改善が求められていました。
自動化による解決を検討するにあたり、実運用に耐えるために認識精度90%以上を達成することを導入の前提条件として定めました。

お薬手帳の写真をアップロードするだけで薬剤情報を自動入力
受診者がお薬手帳の写真をアップロードすると、OCRと生成AIの2段階処理で薬剤情報を自動抽出し、問診画面へ反映するシステムを構築しました。受診者の入力負担を減らすと同時に、スタッフによる補正・確認作業も減らすことができました。
システム概要
精度検証を経て、OCR+生成AIの2段階構成を採用
当初はマルチモーダルAI(画像とテキストをまとめて扱えるAI)に画像を直接入力して薬剤情報を抽出する構成を検討しました。しかし、お薬手帳の写真は撮影角度や照明環境のばらつき、ピントのわずかなぼけなど、画質に影響する条件が多く、その影響でテキスト認識精度が安定しないケースがありました。前提条件として定めた90%に届かなかったため、構成を見直しています。
OCRと生成AIを組み合わせた2段階処理で認識精度92.5%を達成
最終的に、Google Cloud Vision APIでテキストを先に抽出し、そのテキストデータをOpenAI APIで薬剤名と容量の識別・整形に使う2段階の処理構成を採用しました。文字を読む工程を専用のOCRに任せ、生成AIには「読み取れた文字列のうちどれが薬剤名でどれが容量か」を判断させる役割に絞ったことで、認識精度が92.5%まで向上し、目標を達成しています。
読み取り結果を受診者が確認・編集できる設計
抽出された薬剤情報は問診画面に自動で反映されますが、受診者が内容を確認した上で修正・追記できる編集UIを設けています。完全に自動入力で完結させるのではなく、受診者自身が最終確認を行う設計にすることで、読み取り精度に依存しすぎない運用にしています。
成果
受診者の入力負担が減り、薬剤情報の入力精度が上がりました。手入力の煩わしさから生じていた未入力の比率も下がり、問診情報の収集精度が向上しています。当日現場でのスタッフによる確認・補正作業も減っており、受診者・スタッフの双方にとって体験が改善されています。
技術スタック
Google Cloud Vision API(OCR)・OpenAI API・Next.js・AWS
3つのプロジェクトから見えた、生成AI活用がつまずくポイント
業種の異なる現場に共通して現れた、導入時に詰まりやすいポイントを挙げておきます。
入力データの品質を先に整える必要があります
生成AIに社内データを接続しても、データ自体の品質が低ければ精度は上がりません。職務経歴書のように提出フォーマットがばらついている場合や、お薬手帳のように撮影品質が受診者に依存する場合は、前処理でどこまで揃えられるかが精度を左右します。モデルの選定より先に、入力データの状態を確認することをおすすめしています。
PoC環境と本番環境のギャップを過小評価しないことが重要です
PoC段階で精度が出ても、本番データ・本番環境では異なる結果になるケースがあります。医療分野のOCRであれば手書きや低解像度画像への対応、画像生成であれば実際の商品数・ラインナップの多様性への対応など、本番特有の条件を早い段階でテストへ組み込んでおく必要があります。事例03のように、検証の結果として構成そのものを見直す判断も起こり得ます。
「完全自動化」を目指しすぎないことが運用定着につながります
最終確認・調整のポイントをどこに残すか、異常出力が発生したときの対処フローをどう設計するかを、初期段階で業務部門と合意しておくことが定着につながります。今回取り上げた3つの事例はいずれも、最後に人が確認する工程を意図的に残しています。生成AIはあくまでツールであり、業務を熟知した担当スタッフが最終確認を担う体制があって初めて、安全で安定した運用ができます。