設計資料探索の工数を約95%削減──現場課題に寄り添う「生成AI×アジャイル・プロトタイピング」で製造業のDXに伴走

レガシーが阻む設計開発──情報探索・暗黙知・移行の壁、3つの構造的課題

本事例のクライアントは、製造業大手の設計開発部門である。次期データ基盤への移行構想を進めていたが、足元の業務改善とどのように結びつけるかについて模索が続いていた。

現場には、3つの構造的な課題が絡み合っていた。

第一に、情報探索の摩擦と非効率である。設計に関わる様々な形式の資料が複数のアプリケーションに分散管理されており、設計変更が起きるたびに、複数システムを行き来しながら関連資料を手作業で探し出す必要があった。

第二に、設計意図の暗黙知化と品質リスクである。資料間の関連性を機械的に横断検索する仕組みが存在せず、ベテラン社員に確認するプロセスが発生し、属人的な業務負担が生じていた。

第三に、レガシーシステム移行の高い壁である。既存のシステムは他ツールとの連携が困難で、データを取り出して活用しようとしてもハードルが高い。結果として、次期データ基盤構想は描けていても、具体的な移行ステップの策定が難航していた。

これら3点が複合的に絡み合うことで、次期データ基盤への移行構想そのものを停滞させていた——これが現場の構造だった。

なぜ約95%削減を実現できたのか──5日×6スプリントで動かしたアジャイル・プロトタイピングの中身

以下、PoCの中身を、スコープ再設計・信頼関係構築・3層アーキテクチャという3つの観点から見ていく。

「提案より、現場の課題を優先する」発散ヒアリングによるスコープ再設計

前年12月時点の提案では、PoCのスコープは「資料の中身を生成AIに読み込ませやすくする」ことが主眼だった。しかし1月のキックオフ後、対象部署3〜4名のチームに対して集合形式のヒアリング（3〜4回×約1時間、トータル約4時間）を進めるうちに、本質課題の所在が見えてきた。

担当コンサルタントは、提案書の内容に限定せず、発散させて課題を抽出することを意識してヒアリングを設計した。その結果見えてきたのは、「資料の中身」だけでなく「資料自体を見つけること」にも相当の時間がかかっているという事実だった。

担当はクライアントとの合意のもと、PoCのスコープを「資料間の紐付け」まで拡大する意思決定を下す。現場ヒアリングを起点に、提案スコープを柔軟に再設計した。

ドメイン知識ゼロから始まる、信頼関係の積み上げ方

担当コンサルタントは、対象企業とのプロジェクト実績や、該当する業界特有のドメイン知識を持たない状態から本案件をスタートした。

そこで担当は、アウトプットを作るのと同等の時間を業界研究や自己研鑽のインプットに割くことで、クライアントの業務理解に努める姿勢を徹底した。

そうした姿勢はクライアントにも伝わり、変化が現れる。1月中旬の頃は、設計開発の細かい業務内容をどこまで伝えるべきか、伝える粒度の判断に迷いが見受けられたが、担当コンサルタントの業務理解が深まるにつれ、クライアント側から「試しにこれもお願いしてみよう」と積極的なご依頼をいただけるようになった。

また、スピード感も信頼構築の重要な要素となった。定例会議だけでなく、チャットを活用したこまめな進捗報告など、密なコミュニケーションとクイックなレスポンスの積み重ねが、伴走者としての信頼を得る鍵となった。

生成AI×Python×バイブコーディング──「あるべき姿」で設計した3層アーキテクチャ

システムは、App（直感的UI/UX）／Logic（高速検索とRAG・生成AI）／Data（生成AI×Pythonによる非構造化データの統合） の3層アーキテクチャで構築した。

担当が設計において重視したのは、シンプルな原則である。「生成AIは類推が必要なときに使い、ルールベースで紐付けられるものはPythonで処理する」という考え方に基づき、AIに任せるべき領域と、コードで確実に処理する領域を切り分けた。

具体的には、ドメイン特化型の生成AIアシスタント（RAG）を実装する一方で、レガシーシステムからメタデータを抽出することで、生成AIの類推に頼らない資料間の双方向の紐づけをPythonで構築した。

また、バイブコーディングによる高速実装も特徴的である。担当コンサルタント自身が生成AI（LLM）と自然言語で対話・壁打ちを繰り返しながら、直感的なアイデアを即座にコードへ変換する。これにより、5日×6スプリントの高速サイクル（毎週のレビュー → フィードバック → 次週解消）を実践することができた。

進め方については、あえてスコープを厳密に固定せず、「現場からのフィードバックを極力取り入れたい」という方針のもと、クライアントとも「PoCの期間内で解消できる範囲で進める」ことで合意し、現場の声を反映させながら開発を進めた。

最終的に実装したのは、シームレスな統合Viewer、トレーサビリティ可視化、多角的横断検索、ドメイン特化型生成AIアシスタント、継続的AI改善フィードバック、AI駆動の非構造化データ抽出、マスタDB自動構築という、7つの機能群である。

探索工数95%削減と、次期データ基盤への移行要件確立──PoCが実証した3つの成果

約3ヶ月のPoCは、当初の3つの構造的問題に対応する成果として結実した。

成果①は、設計資料探索工数の大幅削減である。探索の所要時間を約95%削減、クリック/コピペ数を最大75%削減した。複数システム横断の摩擦が解消され、資料の関連性を視覚的なツリーで可視化できるようになり、設計者は「探す時間」を「考える時間」にシフトできるようになった。

成果②は、実務に適合する仕様解説AIの実証である。ドメインルールによる厳密な推論制御を実装することで、複雑な実装背景についても設計者の意図に沿った回答が得られるようになった。設計業務そのものを高度化させると同時に、若手社員の自己解決力を高め、教育コストの低減にも寄与する。

成果③は、レガシーマイグレーションへの道筋の確立である。既存システムから非構造化データを安全に抽出するアプローチが確立されたことで、現行システム連携の開発コスト削減と、次期データ基盤構築への移行要件確立の双方を同時に実現した。

これら3つの成果から見据える事業価値の射程は広い。設計開発のコア業務への工数集中は、最終的に新機種開発のリードタイム短縮につながり、設計意図に対する自己解決の促進は、組織全体の技術力向上を意味する。さらにデータ移行リスクの極小化は、システム刷新費用の抑制とIT投資の最適化に寄与する。

PoC終了後には当該部門以外からも「早く運用フェーズに持っていきたい」との声が上がり、4月以降は対象を拡大した取り組みへと発展している。本PoCは、約3ヶ月で設計資料探索工数の約95%削減を実現するとともに、次期データ基盤への移行要件を確立した事例となった。

AI実装プロジェクトを「要件定義の壁」で止めないために──本事例からの示唆

多くのAI実装プロジェクトは、「要件定義の長期化」と「PoC止まり」という壁に直面しがちである。設計開発のDX文脈における次期データ基盤構想も例外ではない。

本事例が示した示唆は、3つに集約できる。第一に、現場ヒアリングを起点に、提案スコープを柔軟に再設計すること。第二に、少人数のコンサルタントが、ドメイン知識の習得と並行して、生成AIを活用した実装までスピーディに行うこと。第三に、生成AIによる類推と、Pythonによるルールベースを適材適所で使い分け、短期サイクルで形にすることである。

AI実装は手段であって、目的ではない。本事例の最終ゴールは、新機種開発のリードタイム短縮という事業プロセスの変革にある。これは、PSXセクターが掲げる「製品構想から顧客提供までを一つの価値の流れとして捉え直し、設計・製造・経営データをつなぐ」という志向の体現でもある。

生成AIの実装プロジェクトがPoCの段階で立ち止まってしまっている、あるいはこれから具体的な事業成果に繋げていきたいとお考えの企業様は、株式会社クオンティア PSXセクターまでお問い合わせください。