ID:84353さん

# プロジェクト概要 工場などの騒音環境において、口頭指示を正確に聞き取ることが難しいという課題を解決するため、音声をリアルタイムで文字化し、最大4言語へ同時翻訳するデスクトップアプリを個人開発しました。 製造現場では、指示を聞き取れず何度も確認することに対して、聞く側には「何度も聞き返しづらい」、伝える側には「何度同じことを言えばよいのか」という心理的な負担が発生します。 また、聞き取れたつもりで誤った作業を行うと、不良品の発生や安全上のリスク、「言った・言わない」による認識の食い違いにつながる可能性があります。外国人作業者への指示伝達では、騒音だけでなく言語の違いも課題になります。 そこで、音声による指示をリアルタイムで文字として表示し、後から内容を確認できる機能と、認識結果を複数言語へ翻訳して同時表示する機能を実装しました。 製造現場で扱う情報を外部サービスへ送信しないことを重視し、音声認識、翻訳、画面表示までをローカル環境で完結する構成としています。 # チーム情報 * 開発人数：1名 * 開発形態：個人開発 * 担当範囲：課題設定、企画、要件定義、技術選定、設計、実装、テスト、性能評価 * 開発環境：Windows、NVIDIA GeForce RTX 3090、CUDA 製造現場で感じた課題の整理から、AIモデルの選定、ローカル実行環境の構築、GUI開発、性能測定までを一貫して担当しました。 # 開発・実装内容1：リアルタイム音声認識 ## 概要 マイクから取得した音声を発話単位で処理し、音声認識結果をリアルタイムでGUI上に表示する機能を実装しました。 ## 課題・問題点 * 工場の環境音が音声認識精度に影響する * 長い音声をまとめて処理すると、表示までの待ち時間が長くなる * 無音部分まで処理すると不要な推論処理が増える * 音声認識中にGUIが停止すると、利用者が処理状況を把握しにくい ## 打ち手・使用した技術 * **Python**：音声処理、AIモデルの推論制御、GUIを含むアプリケーション全体の実装 * **faster-whisper**：入力された音声の文字起こし * **PyTorch**：音声認識モデルおよび翻訳モデルの実行 * **CUDA**：NVIDIA製GPUを利用した推論処理の高速化 * **WebRTC VAD**：発話区間と無音区間を判定し、発話部分のみを処理 * **noisereduce**：入力音声に対するノイズ低減 * **FFmpeg**：AIモデルへ入力するための音声形式の変換 * **Tkinter**：認識結果と翻訳結果をリアルタイムで表示するGUIの構築 * **multiprocessing**：音声取得、音声認識、翻訳、GUI表示の処理を分離 音声認識処理の開始時刻と終了時刻を計測し、発話時間、認識処理時間、画面表示までの全体時間を確認しながら処理条件を調整しました。 ## 成果 * 音声データを外部へ送信せず、ローカル環境で音声認識を実行 * 音声入力から認識・翻訳結果の表示まで、約0.93秒から2.30秒の範囲で動作することを確認 * 無音区間を除外することで不要な推論処理を削減 * 聞き逃した指示を文字で再確認できる仕組みを実装 * 音声認識処理とGUI表示を分離し、処理中も画面を操作できる構成を実現 # 開発・実装内容2：最大4言語への同時翻訳 ## 概要 音声認識されたテキストを最大4言語へ翻訳し、原文と翻訳結果を同じ画面上に表示する機能を実装しました。 ## 課題・問題点 * 翻訳する言語数が増えるほど、画面表示までの待ち時間が長くなる * クラウド翻訳APIを使用すると、製造現場の情報を外部へ送信する必要がある * 音声認識と複数言語への翻訳を同一処理内で実行すると、GUIが停止しやすい * 音声認識と翻訳のどちらが遅延の原因か、体感だけでは特定しにくい ## 打ち手・使用した技術 * **M2M100**：音声認識されたテキストを複数言語へ翻訳 * **PyTorch／CUDA**：翻訳モデルをローカルGPU上で実行 * **multiprocessing**：音声認識、翻訳、GUI表示を別処理として実行 * 音声認識時間、言語ごとの翻訳時間、全体レイテンシを計測 * 計測結果をCSVへ記録し、処理時間を比較 * 言語数や処理条件を変更し、リアルタイム性とのバランスを検証 ## 成果 * 外部の翻訳APIを利用せず、ローカル環境だけで翻訳処理を完結 * 最大4言語の翻訳結果を同一画面に表示 * 音声認識時間と翻訳時間を分けて計測できる仕組みを構築 * 計測結果から、複数言語への翻訳処理が主なボトルネックであることを特定 * 処理条件を調整し、リアルタイム性と複数言語対応の両立を検証 # 開発・実装内容3：話者分離 ## 概要 複数人が会話する状況を想定し、音声データを話者ごとに分離する機能を検証・実装しました。 ## 課題・問題点 * 複数人が発言する環境では、文字起こし結果だけでは誰の発言か判別しにくい * 発言者が切り替わった箇所を、人が後から手作業で整理する必要がある * 話者分離処理を追加すると、全体の処理負荷が増加する ## 打ち手・使用した技術 * **pyannote.audio**：音声データに対する話者分離 * **PyTorch／CUDA**：話者分離モデルの実行 * 話者ごとの発話区間を抽出し、音声認識結果と対応付ける構成を検討 * 話者分離を有効にした場合と無効にした場合の処理負荷を比較 ## 成果 * 複数人の発話を話者単位で分離する機能を実装 * 音声認識結果に話者情報を付与するための基礎機能を構築 * 話者分離による利便性と、処理時間増加のトレードオフを確認 # 開発・実装内容4：性能計測とボトルネック分析 ## 概要 体感だけで性能を判断せず、音声認識、翻訳、全体処理の時間を個別に計測し、改善箇所を特定する仕組みを実装しました。 ## 課題・問題点 * 画面表示が遅い場合に、どの処理が原因なのか判断しにくい * AIモデルの追加により、GPUメモリの使用量が増加する * 音声認識精度とリアルタイム性のどちらを優先するか、数値を基に判断する必要がある ## 打ち手・使用した技術 * **Python**：各処理の開始時刻、終了時刻、処理時間の計測 * **CSV**：発話時間、音声認識時間、翻訳時間、全体レイテンシの記録 * GPUメモリ使用量を確認しながらモデル構成と処理条件を調整 * 音声認識モデル、翻訳言語数、発話区間などの条件を変えて性能を比較 * **Git／GitHub**：ソースコードと変更履歴の管理 ## 成果 * 音声認識、翻訳、全体処理を個別に計測できる仕組みを構築 * 翻訳処理が全体レイテンシへ与える影響を数値で確認 * 処理時間を可視化し、改善対象を数値に基づいて判断できるようにした * AIモデルの選定から実装、検証、性能評価まで一連の工程を経験 # このプロジェクトで発揮したバリュー 製造現場での約19年間の経験をもとに、単にAI技術を試すのではなく、「騒音」「多言語化」「情報セキュリティ」「指示の聞き間違い」という現場固有の課題を機能要件へ落とし込みました。 また、既存のクラウドサービスをそのまま利用するのではなく、製造現場で扱う情報を外部へ送信しないという条件から、音声認識・翻訳・GUI表示をローカル環境で完結する構成を選択しました。 機能を実装するだけでなく、音声認識時間、翻訳時間、GPUメモリ使用量、全体レイテンシを計測し、ボトルネックを特定して処理条件を調整しました。 この経験を通じて、現場課題の発見、要件定義、技術選定、試作、実装、性能評価までを一貫して進める力を身につけました。 # 現在の到達点と今後の課題 本プロジェクトは、個人で企画・開発した技術検証用のプロトタイプです。 ローカル環境でのリアルタイム音声認識、最大4言語への翻訳、話者分離、処理時間の計測まで実装しましたが、実際の製造現場への正式導入には至っていません。 実用化に向けては、以下の対応が必要だと考えています。 * 実際の工場騒音を含む音声データを使用した継続的な精度検証 * 現場環境に適したマイク、GPU搭載端末、表示機器の選定 * 作業者が手袋を着用した状態でも利用しやすい画面・操作方法の改善 * 認識結果や翻訳結果をどのように確認・保存するかという運用ルールの策定 * 誤認識や誤翻訳が発生した場合の確認手順の整備 * 社内の情報セキュリティおよびシステム導入手続きへの対応 * 長時間の連続稼働を想定した安定性の検証

# プロジェクト概要 製造業で行われるQC活動の発表資料について、改善内容や数値データを順番に入力することで、QCストーリーに沿ったPowerPoint資料の初稿と発表者ノートを自動生成するWebアプリを個人開発しました。 QC活動では、現場の困りごとに対してQC七つ道具などを用い、課題の整理、原因分析、対策、効果確認までを資料にまとめて発表します。 しかし、資料作成を担当するのは、日常的にPowerPointを使用しない製造現場の作業者であることも多く、文章の整理、テキストボックスや図形の配置、グラフ作成などに多くの時間がかかります。通常業務の終了後に残業で資料を作成するケースもあり、作業者の負担になっていました。 そこで、利用者が改善活動の内容をフォームへ入力するだけで、QCストーリー13ステップに沿ったスライドと発表者ノートを自動生成する仕組みを設計しました。 資料の体裁を整える作業をアプリへ任せることで、作業者がデータ整理、原因分析、対策の検討など、本来時間を使うべき改善活動に集中できる状態を目指しました。 # チーム情報 * 開発人数：1名 * 開発形態：個人開発 * 担当範囲：課題設定、企画、要件定義、画面設計、データ設計、実装、テスト、性能評価 * 開発環境：Windows、Visual Studio Code、Git、GitHub 製造現場でのQC活動経験をもとに、必要な入力項目の整理、QCストーリーの構造化、画面設計、フロントエンド・バックエンド開発、PowerPoint生成、動作検証までを一貫して担当しました。 # 開発・実装内容1：QCストーリー入力フォーム ## 概要 利用者がQC活動の内容を順番に入力できるWebフォームを実装しました。 QCストーリー13ステップに沿って、テーマ、現状把握、目標設定、要因解析、対策、効果確認、標準化などの情報を入力できる構成としています。 ## 課題・問題点 * QC活動に不慣れな利用者は、何をどの順番で整理すればよいか分かりにくい * 入力項目が多いため、1画面に集約すると操作性が低下する * 入力途中で画面を移動した際に、入力内容を保持する必要がある * フロントエンドとバックエンド間で、複雑な入力データを正確に受け渡す必要がある ## 打ち手・使用した技術 * **React**：入力フォーム、画面遷移、プレビュー画面の実装 * **TypeScript**：入力データ、画面状態、APIレスポンスの型定義 * **Zustand**：複数画面にまたがる入力状態の一元管理 * **Vite**：フロントエンドの開発環境とビルド環境の構築 * **JSON**：QC活動の入力内容を構造化して管理 * **npm**：フロントエンドのパッケージ管理 * QCストーリーの工程ごとに入力画面を分割し、利用者が順番に入力できるUIを設計 * 入力データの型を定義し、画面とPowerPoint生成処理で同じデータ構造を利用 ## 成果 * QCストーリー13ステップに沿った入力画面を実装 * 複数画面にまたがる入力内容を保持できる構成を実現 * 入力内容をJSON形式で一元管理し、PowerPoint生成処理へ受け渡せるようにした * PowerPoint操作に不慣れな利用者でも、改善内容の入力に集中できる画面構成を実装 # 開発・実装内容2：PowerPoint資料と発表者ノートの自動生成 ## 概要 Webフォームへ入力された内容をもとに、QC発表用のPowerPoint資料と、スライドごとの発表者ノートを自動生成する機能を実装しました。 ## 課題・問題点 * 入力内容によって文章量やデータ数が異なり、固定配置では文字や図表が収まらない * QCストーリーの工程ごとに、必要なスライド構成や表示内容が異なる * スライドだけでなく、発表時に利用する説明原稿も作成する必要がある * PowerPoint上の図形、テキスト、表、グラフを一定のレイアウトで出力する必要がある ## 打ち手・使用した技術 * **Python**：PowerPoint生成ロジック、データ加工、条件分岐の実装 * **python-pptx**：スライド、テキストボックス、図形、表、グラフ、発表者ノートの生成 * **FastAPI**：フロントエンドから入力データを受け取り、PowerPointファイルを返すAPIの実装 * **REST API**：フロントエンドとバックエンド間のデータ連携 * **Uvicorn**：FastAPIアプリケーションの実行 * **JSON**：入力データとスライド生成条件の受け渡し * **PowerPoint**：生成結果の確認とテンプレート調整 * QCストーリーの工程ごとにスライド生成処理を分割 * 入力値の有無やデータ数に応じて、表示内容やレイアウトを切り替える条件分岐を実装 * スライドごとの入力内容から、発表時に説明すべき内容を発表者ノートとして生成 * 文字数やデータ量に応じて、フォントサイズや配置を調整する処理を実装 ## 成果 * 入力内容からPowerPoint資料の初稿を自動生成 * QCストーリー13ステップに沿ったスライド構成を実現 * スライド本文に加えて、発表者ノートも同時に生成 * フロントエンドから入力し、バックエンドでPowerPointを生成・出力する一連の処理を実装 * 資料の形式を統一し、作成者ごとのレイアウトや記載内容のばらつきを抑える仕組みを構築 # 開発・実装内容3：QC図表の自動生成 ## 概要 QC活動で利用されるパレート図、特性要因図、系統図などを、入力データから自動生成する機能を実装しました。 ## 課題・問題点 * QC図表は種類ごとに構造や表現方法が異なる * 利用者がPowerPoint上で図形を一つずつ配置すると、多くの時間がかかる * 要因数や階層数によって、図形の大きさや配置を動的に変更する必要がある * 入力データが少ない場合と多い場合の両方で、可読性を維持する必要がある ## 打ち手・使用した技術 * **python-pptx**：PowerPoint上への図形、線、テキスト、グラフの配置 * **Python**：入力データ数に応じた座標、サイズ、間隔の計算 * **JSON**：図表の項目、要因、階層関係の管理 * パレート図について、項目名、件数、累積比率からグラフを生成 * 特性要因図について、要因をカテゴリごとに整理し、魚骨図として配置 * 系統図について、階層構造に応じて図形と接続線を動的に配置 * 入力件数に応じて、フォントサイズや図形間隔を変更する処理を実装 ## 成果 * パレート図、特性要因図、系統図の自動生成に対応 * PowerPoint上で図形を手作業する工程を削減 * 入力されたデータに応じて、図表を動的に生成できる構成を実現 * QC活動に不慣れな利用者でも、一般的なQC図表を資料へ組み込める仕組みを構築 # 開発・実装内容4：生成方式と安定運用の設計 ## 概要 現場での安定した利用と出力内容の再現性を重視し、LLMを使用せず、テンプレート、条件分岐、JSON辞書を組み合わせた生成方式を採用しました。 ## 課題・問題点 * LLMを使用すると、同じ入力でも出力文章や構成が変化する可能性がある * 誤った情報や、入力内容にない情報が生成されるリスクがある * 外部APIを利用する場合、通信環境、利用料金、情報管理上の課題が発生する * 製造現場の一般的なPCでも、短時間で安定して動作させる必要がある ## 打ち手・使用した技術 * **Python**：入力条件に応じた文章生成とスライド構成の条件分岐 * **JSON辞書**：QCストーリーごとの定型文、説明文、生成条件の管理 * **python-pptx**：決められたテンプレートに基づく再現性の高い資料生成 * 入力された情報だけを利用して資料と発表者ノートを生成 * 同じ入力に対して同じ結果を出力できる決定論的な構成を採用 * 外部AIサービスへの通信を必要としない構成を選択 ## 成果 * LLMによる出力のばらつきや、入力内容にない情報が生成されるリスクを回避 * 外部APIの利用料金や通信環境に依存しない構成を実現 * 同じ入力から同じ資料を生成できる再現性を確保 * 一般的なPC環境でも高速に動作する構成を実現 # 開発・実装内容5：作成時間の計測と効果検証 ## 概要 実際のQC発表資料を想定した入力と資料生成を行い、従来の手作業と比較して、初稿作成に要する時間をどの程度削減できるか検証しました。 ## 課題・問題点 * 機能を実装しただけでは、現場業務に対する効果を判断できない * 資料生成時間だけでなく、入力に要する時間も含めて評価する必要がある * 時間削減による業務上の価値を定量的に示す必要がある * 初稿作成後の確認や修正時間と、初稿が完成するまでの時間を分けて評価する必要がある ## 打ち手・検証方法 * 実際のQC発表を想定した内容をフォームへ入力 * 入力開始からPowerPoint初稿の完成までの時間を計測 * 従来の手作業による初稿作成時間と比較 * 作成時間の削減率を算出 * 生成されたスライドと発表者ノートを確認し、発表資料としての利用可能性を検証 ## 成果 * 従来は、早い作成者でも約12時間を要していたPowerPoint初稿の作成を、実測約16分まで短縮 * 12時間から16分への短縮により、初稿作成時間を約97.8％削減 * スライドと発表者ノートを同時に生成し、資料作成から発表準備までの負担を軽減 * 削減した時間を、データ分析、原因究明、改善案の検討など、本来のQC活動へ振り向けられる可能性を示した # このプロジェクトで発揮したバリュー 製造現場での約19年間の経験と、実際にQC活動へ参加してきた経験をもとに、単にPowerPointを自動生成するのではなく、現場作業者がどこで時間を使い、何に困っているのかを整理して機能要件へ落とし込みました。 特に、PowerPoint操作の習熟度にかかわらず利用できること、QCストーリーに沿って入力できること、出力結果にばらつきが生じにくいことを重視しました。 また、フロントエンド、バックエンド、PowerPoint生成処理を分けた構成とし、React、TypeScript、FastAPI、python-pptxを利用して、一連のWebアプリケーションとして実装しました。 開発だけで終わらせず、実際の資料作成を想定して時間を計測し、約12時間から約16分、約97.8％の削減効果を数値で確認しました。 この経験を通じて、現場課題の発見、要件定義、UI設計、Webアプリ開発、ファイル生成、効果検証までを一貫して進める力を身につけました。 # 現在の到達点と今後の課題 本プロジェクトは、個人で企画・開発した技術検証用のプロトタイプです。 QCストーリーに沿った入力、PowerPoint資料、発表者ノート、QC図表の自動生成、および作成時間の効果検証まで実施しました。 実際の組織で継続的に運用するためには、以下の対応が必要だと考えています。 * 複数のQCテーマや異なる部門の資料を用いた検証 * 企業ごとに異なるPowerPointテンプレートへの対応 * 入力内容の保存、再編集、複製機能の追加 * 複数利用者を想定したユーザー管理とアクセス権限の実装 * ExcelやCSVからのデータ取り込み機能の追加 * グラフや図表のレイアウト調整機能の拡充 * 長文入力や大量データを使用した場合の安定性検証 * 実際の利用者からのフィードバックをもとにしたUI改善