現場19年×AI/DX自主開発

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

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

### プロジェクト概要 このプロジェクトを考えたきっかけは、製造現場で設備や工程の問題が発生した際、**ベテラン作業者がいるかどうかによって対応に大きな差が生じる場面**を経験してきたことです。 過去にも発生したことのあるエラーであっても、その時の対応方法や判断理由が十分に共有・蓄積されていなければ、経験のある作業者が不在の際に過去の知見を活用できません。 その結果、 * 過去と同じようなエラーを繰り返す * 担当者によって対応方法が変わる * 一度解決した問題を再び一から調査する * 「なぜ以前その対応を選んだのか」が後から分からなくなる といった問題が起こります。 そこで、 **「現在発生している問題と似た過去事例を探し、その時にどのような対応を行い、どのような結果になったのかを提示できれば、経験の少ない作業者でも判断材料を得られるのではないか」** と考えました。 最終的には、過去のトラブル履歴、対応内容、判断理由、結果、会議ログやエビデンスなどを蓄積し、新しい問題が発生した際に、 **現在の問題 → 類似する過去事例 → 過去の対応 → その結果 → 今回確認すべき点** という形で必要な情報へたどり着ける仕組みを構想しています。 目的は、ベテラン作業者の判断をAIに置き換えることではありません。 **個人の経験や記憶の中だけに存在する知見を、他の作業者も利用できる組織の知識へ変え、人間の判断を支援すること**を目指しました。 その第一段階の技術検証として、相反する2つの意見についてローカルLLMに主張・反論・再反論を生成させ、複数の評価軸から比較する意思決定支援プロトタイプを開発しました。 AIには結論そのものを決めさせず、 * 異なる立場から論点を出す * リスクや影響を整理する * 追加で確認すべき事項を提示する * 次に検討すべき行動を整理する ところまでを担当させ、**最終的な判断と責任は人間に残す**ことを設計方針としました。 また、設備トラブルや製造条件、社内会議などの情報を扱う可能性を考え、外部の生成AI APIではなくローカルLLMを採用しました。 ### チーム情報 * **開発人数：** 1名 * **開発形態：** 個人開発 * **自身の役割：** 課題設定、企画、要件定義、画面設計、ローカルLLM選定、プロンプト設計、実装、テスト、評価 * **開発環境：** Windows / Python / Streamlit / Ollama / Git / GitHub * **実行環境：** Ryzen 9 7950X / NVIDIA GeForce RTX 3090 24GB / RAM 64GB 課題の整理からアプリ構成、モデル選定、UI実装、プロンプト設計、回答品質評価、処理時間・GPUメモリ使用量の確認、開発継続可否の判断まで一貫して自身で行いました。 ### 使用したローカルLLM Ollamaを利用し、以下のモデルを用途や検証条件に応じて切り替えながら比較しました。 * Llama 3.1 * Llama 3.2 * Qwen2.5 * Gemma 2 * Mixtral 単に「どのモデルが高性能か」を見るのではなく、 * 指示への追従性 * 議論の一貫性 * 回答の具体性 * 処理時間 * GPUメモリ使用量 を確認しました。 検証を通じて、小規模モデルは比較的軽量に動作する一方、複雑な議題では回答が表面的になりやすく、大規模モデルほど回答品質が向上する傾向があるものの、処理時間やGPUメモリ使用量が増えるというトレードオフを確認しました。 ### 開発・実装内容1：主張・反論・再反論の生成 #### 【どのような機能の開発・実装か】 相反する2つの意見を入力し、それぞれの立場から、 **主張 → 相手への反論 → 再反論** を段階的に生成する機能を実装しました。 一方の意見だけで結論を出すのではなく、複数の立場から同じ議題を検討できる構成としました。 #### 【課題・問題点】 * 一方の意見だけでは議論が特定の立場へ偏りやすい * LLMへ自由形式で生成させると、主張・反論・評価が混在しやすい * 複数回の生成処理で、それまでの議論を正確に引き継ぐ必要がある * 外部APIを利用すると、会議内容や社内情報を外部へ送信する可能性がある #### 【打ち手・使用した技術】 * **Python**：アプリケーション全体の処理、プロンプト生成、LLM応答制御 * **Ollama**：ローカルLLMの実行、モデル管理、モデル切り替え * **プロンプトエンジニアリング**：主張・反論・再反論ごとに役割、目的、出力条件を明示 * **JSON**：議題、各立場の主張、反論、評価結果を構造化して管理 一度に議論全体を生成させるのではなく、主張・反論・再反論を処理単位として分離しました。 また、前段階の出力を次のプロンプトへ引き継ぐことで、議論の流れを保持する構成としました。 #### 【成果】 * 相反する2つの意見について、主張・反論・再反論を段階的に生成 * 一方の立場だけでは見えにくい論点を比較できる構成を実現 * 外部生成AI APIへ情報を送信せず、ローカル環境で処理を完結 * 各段階の生成結果をJSONで構造化し、後続の評価処理へ連携 ### 開発・実装内容2：評価軸に基づく比較・論点整理 #### 【どのような機能の開発・実装か】 生成された双方の議論を、設定した評価軸から比較し、 * 採用案 * 評価理由 * 想定リスク * ステークホルダーへの影響 * 追加で確認すべき事項 * 次に取るべき行動 を整理する機能を実装しました。 #### 【課題・問題点】 LLMへ単純に「どちらが良いか」と尋ねるだけでは、何を基準に判断したのかが分かりにくくなります。 また、同じ議題でも、 * 実行可能性を重視する場合 * コストを重視する場合 * 安全性を重視する場合 * 社会や関係者への影響を重視する場合 では評価結果が変わります。 そのため、一つの「正解」をAIに決めさせるのではなく、**評価軸によって判断がどのように変わるのかを利用者自身が確認できること**が必要だと考えました。 #### 【打ち手・使用した技術】 * **プロンプトエンジニアリング**：評価項目、判定条件、出力形式を明示 * **JSON**：採用案、評価理由、リスク、影響、次の行動を構造化 * 利用者が評価軸を切り替え、同じ議題を異なる観点から比較できるよう設計 * 単純な勝敗だけでなく、懸念事項や追加確認事項も出力する構成を採用 #### 【成果】 * 同じ議題を複数の価値基準から比較できる機能を実装 * 採用案だけでなく、リスクや関係者への影響も確認できる構成を実現 * 評価結果を一定のJSON構造で管理し、画面表示や再利用を行いやすくした * AIの結論をそのまま採用せず、人間が判断するための材料として提示できる形とした ### 開発・実装内容3：操作画面と結果表示 #### 【どのような機能の開発・実装か】 議題と相反する2つの意見を入力し、主張・反論・再反論・評価結果までを一連の流れとして確認できる画面を実装しました。 #### 【課題・問題点】 * 主張、反論、再反論、評価結果を一度に表示すると内容を追いにくい * LLMの処理には時間がかかるため、利用者が処理状況を把握できる必要がある * 技術に詳しくない利用者でも議論の流れを理解できる画面構成が必要 #### 【打ち手・使用した技術】 * **Streamlit**：議題入力、実行操作、生成結果の表示UIを実装 * **Python**：画面入力とOllamaへの処理要求を連携 * **JSON**：生成結果を項目別に分離して表示 主張、反論、再反論、最終評価を段階別に表示し、採用案、リスク、関係者への影響、次の行動についても項目を分けて確認できる構成としました。 #### 【成果】 * 議題入力から議論生成、評価結果確認までを一つの画面で実行 * 各段階を分けて表示し、議論の流れを追いやすくした * ローカルLLMを利用した意思決定支援の一連の流れを、動作するプロトタイプとして実装 ### 開発・実装内容4：モデル比較と実用性検証 #### 【課題・問題点】 このアプリでは、一度回答を生成するだけではなく、 **主張 → 反論 → 再反論 → 評価** と複数回の推論を連続して行います。 そのため、モデルを大規模化すると回答品質が向上する一方、 * 処理時間が長くなる * GPUメモリ使用量が増える * 必要なハードウェアが高価になる という問題があります。 また、自然な文章を生成できても、利用者が「なぜその結論になったのか」を検証できなければ、業務上の意思決定支援としては不十分だと考えました。 #### 【打ち手・検証内容】 RTX 3090 24GBのローカル環境で複数モデルを切り替え、 * 回答の具体性 * 議論の一貫性 * 指示への追従性 * 処理時間 * GPUメモリ使用量 を比較しました。 また、 * 同一または類似した議題を複数回実行 * 評価軸を変更した際の結果の違いを確認 * 判定理由、リスク、影響、次の行動を人間が検証可能か確認 しました。 #### 【成果・判断】 ローカルLLMによる議論生成と比較評価が**技術的には実行可能**であることを確認しました。 一方で、 * 小規模モデルでは複雑な判断の回答品質に限界がある * 大規模モデルでは回答品質が上がる反面、処理時間とGPU負荷が増える * 複数回の推論を連続実行するため、単発チャットより処理負荷が高い * 出力結果の根拠提示や再現性にも課題が残る ことを確認しました。 そのため、**「技術的に動いたから完成」とせず、現在の性能・コスト・信頼性では実用化を進める段階ではない**と判断しました。 ### 設計方針の見直し 検討の途中では、相手の反論傾向や心理的な抵抗要因を分析し、提案を受け入れてもらいやすくする方向も考えました。 しかし、特定の結論へ誘導することを目的にすると、意思決定支援ではなく、利用者を操作する仕組みに近づく危険があると判断しました。 そこで設計方針を見直し、 * 相手の弱点を利用して結論へ誘導しない * 選択肢ごとのメリットとリスクを提示する * 根拠や過去事例を判断材料として示す * 全面導入だけでなく、小規模な試験導入なども選択肢として示す * **最終的な判断と責任は人間に残す** ことを重視しました。 AIに「人を動かしてもらう」のではなく、**人がより良い判断をするための材料を増やす**ことを目指しています。 ### 発展構想：過去のトラブル・会議ログ・エビデンスの活用 このプロジェクトで最終的に実現したいと考えたのは、製造現場で発生した問題や判断を組織の知識として蓄積し、次の問題解決へ活かす仕組みです。 例えば設備や工程でエラーが発生した際に、 * 現在の問題と似た過去事例を検索する * 過去にどのような対応を行ったか確認する * その対応によって問題が解決したか確認する * なぜその対応を選んだのか確認する * 現在の状況と過去事例の違いを提示する * 過去の会議・判断・エビデンスを参考情報として提示する * 全面対応だけでなく、試験的な対応も選択肢として示す といったことができれば、ベテラン作業者が不在の場合でも、過去の経験を判断材料として利用できるのではないかと考えています。 これにより、 **個人の記憶に依存した対応 → 組織として蓄積・再利用できる知識** へ変えることを目指しています。 ただし、会議ログやトラブル履歴の検索、RAG、過去の判断結果からの学習機能については**現在は未実装**です。 実装済み機能と将来構想を混同しないよう、発展構想として明確に分けています。 ### このプロジェクトで発揮したバリュー このプロジェクトでは、単にローカルLLMを動かすことではなく、 **「現場で同じ問題を何度も繰り返さないために、過去の経験や判断をどう組織の知識として残し、人間の判断へ活かせるか」** という問題から技術検証を始めました。 そのため、技術的に実装できるかだけではなく、 * 回答品質 * 処理速度 * GPUメモリ * 導入コスト * 情報管理 * 判定根拠 * 再現性 * 説明責任 * 利用者への不適切な誘導 まで検討しました。 また、プロトタイプが動いた後も機能を増やし続けるのではなく、実際に利用する人の立場から、 **「この状態で本当に現場へ導入してよいのか」** を考えました。 利用者がGPUやモデルサイズなど開発側の事情を意識しなければ使えない状態や、出力結果を十分に検証できない状態では、現時点での実用化は適切ではないと判断しました。 私がAIを現場へ導入する際に重視したいのは、AIを使うことそのものではありません。 **人が抱えている判断・調査・情報探索の負担を減らし、過去の知見を活用しながら、人間自身がより良い判断をできる状態をつくること**です。 この経験を通じて、 **現場課題の発見 → 問題の構造化 → AI活用方法の検討 → モデル・技術選定 → プロトタイプ実装 → 品質・性能・コスト検証 → リスク評価 → 開発継続可否の判断** までを一連の技術検証として行いました。 ### 現在の到達点と開発を凍結した理由 現在までに、 * 相反する2つの意見の入力 * 主張・反論・再反論の生成 * 複数評価軸による比較 * リスク・影響・追加確認事項の整理 * 次に取るべき行動の提示 * 複数ローカルLLMの比較 * 回答品質、処理負荷、GPUメモリ使用量の検証 まで実装・検証しました。 一方で、RTX 3090 24GB環境でも、複数回の推論を連続して行いながら、十分な回答品質、処理速度、安定性を両立することには課題があると判断しました。 また、 * 参照根拠の提示 * 出力の再現性 * 最終判断に対する説明責任 * 過去ログやエビデンスの安全な利用 * 利用者を特定の結論へ誘導しないための設計 にも課題が残っています。 そのため現在は追加開発を凍結し、 * より軽量で高精度なローカルLLMが利用可能になる * GPU導入コストが現実的な水準になる * 少ない計算資源で安定した推論が可能になる * 根拠提示と再現性を確保できる * 過去のトラブル履歴・会議ログ・エビデンスを安全に利用できる * 最終判断を人間に残す運用を確立できる などの条件が整った段階で、再検討したいと考えています。 **技術的に動作したことだけを完成条件とせず、「現場で本当に使えるのか」「利用者の負担を本当に減らせるのか」まで考えて、開発継続の可否を判断したプロジェクトです。**