製造業では、新機種や新製品のリリースに合わせて、検査工程で使うソフトウェアを改修・再作成することがあります。
特に、制御機器や産業機器の検査では、製品仕様、検査条件、判定ロジック、画面表示、帳票、ログ出力などが機種ごとに異なります。
そのたびに内製の検査用アプリケーションを修正していると、開発担当者の負担が大きくなり、仕様確認、実装、テスト、レビュー、手順書作成に多くの時間がかかります。
本記事では、C#で開発されたWindows向け検査用アプリケーションについて、AIを活用して開発工程を効率化するための導入検討事例を紹介します。
相談内容
相談企業では、製造ライン向けの機器を扱っており、検査工程では自社で内製した検査用アプリケーションを使用していました。
新機種がリリースされるたびに、既存の検査アプリをベースにしながら、仕様変更に合わせて画面、検査項目、判定条件、ログ出力、帳票などを修正していました。
しかし、新機種対応は年に複数回発生します。
そのたびに開発担当者が過去の仕様書、既存コード、テスト項目、検査手順書を確認し、差分を整理して改修する必要がありました。
主な課題は次のようなものでした。
- 新機種ごとに検査アプリの改修工数が大きい
- 仕様差分の確認に時間がかかる
- 既存コードの影響範囲を調べる作業が属人化している
- テストケースや検査手順書の作成に手間がかかる
- 過去の不具合や改修履歴を探しにくい
- AIを使いたいが、どの工程に入れるべきか分からない
- 検査工程に関わるため、品質責任を考えると完全自動化には不安がある
BizDXAIでは、この相談に対して、検査ソフトそのものをAIに丸投げするのではなく、開発工程を分解し、効果が出やすい部分からAIを組み込む方針を提案しました。
課題
この案件の本質は、「AIでアプリを作ること」ではありません。
本当の課題は、新機種対応のたびに発生する確認・調査・修正・テスト・ドキュメント作成の負担をどう減らすかです。
1. 仕様差分の整理に時間がかかる
検査用ソフトウェアでは、製品仕様の違いがそのまま検査ロジックに影響します。
検査項目、閾値、通信条件、画面表示、ログ形式、帳票項目などが少し変わるだけでも、修正箇所は複数に広がります。
そのため、新機種の仕様書を読み込み、旧機種との差分を整理する作業が毎回発生していました。
この作業は重要ですが、手作業で行うと時間がかかり、見落としのリスクもあります。
2. 既存コードの影響範囲調査が属人化している
C#で作られた内製アプリは、長く使われるほど機能が増え、構造が複雑になります。
どの画面がどの検査項目に関係しているのか。
どのクラスやメソッドを変更すると、どの機種に影響するのか。
こうした情報が一部の担当者の経験に依存していると、改修のたびに確認コストが高くなります。
3. テストケース作成とレビューの負担が大きい
検査用ソフトウェアは、製造品質に関わるため、単に動けばよいものではありません。
検査結果の正確性、異常系の処理、ログ出力、画面表示、再現性、トレーサビリティなどを確認する必要があります。
そのため、改修ごとにテストケースを作成し、レビューし、検査手順を整える作業が発生します。
4. AI活用の目的が曖昧になりやすい
AI活用を検討する企業でよくあるのが、「AIで何ができるか」を先に考えてしまうことです。
しかし、製造業の検査工程では、品質責任が重く、AIに判断を丸投げする設計は適していません。
重要なのは、AIに任せる部分と、人間が確認する部分を明確に分けることです。
提案した解決方針
BizDXAIでは、検査用ソフトウェア開発の工程を分解し、AIを次のような補助役として使う方針を提案しました。
AIは開発者を置き換えるものではありません。
開発者が行っている調査、比較、整理、下書き、レビュー観点の抽出を支援するものです。
Phase 1：開発工程を可視化する
最初に、現在の開発工程を整理します。
新機種対応時に、誰が、どの資料を見て、どの順番で作業しているかを確認します。
整理対象は次の通りです。
- 新機種の仕様書
- 旧機種の仕様書
- 既存のC#コード
- 検査項目一覧
- テストケース
- 検査手順書
- 過去の不具合履歴
- 改修履歴
- レビュー記録
- リリース判定資料
この段階では、いきなりAIツールを入れるのではなく、どこに時間がかかっているかを把握します。
Phase 2：仕様差分の抽出をAIで支援する
次に、新旧仕様書の比較をAIで支援します。
たとえば、旧機種と新機種の仕様書を比較し、変更点を一覧化します。
AIに任せる内容は、次のような作業です。
- 検査項目の追加・削除・変更の抽出
- 判定条件の変更点の整理
- 画面表示項目の差分確認
- 通信仕様やログ出力の変更点整理
- 影響がありそうな機能の候補出し
ただし、AIが出した差分は最終判断ではありません。
開発者や品質担当者が確認し、正式な変更点として確定する流れにします。
Phase 3：既存コードの影響範囲調査を支援する
C#アプリの既存コードを対象に、変更が必要になりそうな箇所を洗い出します。
AIに期待する役割は、コードを自動で書き換えることではなく、調査を早くすることです。
たとえば、次のような使い方ができます。
- 検査項目名に関連するクラスやメソッドを探す
- 特定の判定条件が使われている箇所を抽出する
- 画面項目と内部処理の対応を整理する
- 変更が影響しそうなテスト項目を洗い出す
- 過去に似た修正があった箇所を探す
これにより、担当者がコード全体を手作業で追う時間を減らせます。
Phase 4：テストケースとレビュー観点を作成する
検査ソフトの改修では、テスト設計が重要です。
AIを使って、仕様差分からテストケース案を作成します。
たとえば、以下のような支援ができます。
- 正常系テストケースの下書き作成
- 異常系テストケースの候補出し
- 境界値テストの観点整理
- ログ出力確認項目の整理
- 画面表示確認項目の整理
- 回帰テスト対象の候補出し
- レビュー時の確認リスト作成
ここでも、AIの出力は下書きです。
品質責任がある領域では、人間がレビューし、正式なテストケースとして採用する流れが必要です。
Phase 5：社内ナレッジ検索を整備する
過去の仕様書、不具合履歴、改修履歴、レビュー記録を探しやすくするため、社内ナレッジ検索の仕組みを整えます。
AIに質問すると、過去の資料をもとに回答し、参照元を示す構成です。
たとえば、開発担当者が次のように質問できます。
「過去に同じ検査項目を変更した機種はありますか」
「この判定条件に関連する不具合履歴を教えてください」
「前回の新機種対応でレビュー指摘が多かった箇所はどこですか」
「この機能を変更する場合に確認すべきテスト項目を教えてください」
これにより、ベテラン担当者の記憶に頼っていた情報を、チーム全体で活用しやすくなります。
技術構成の考え方
この案件では、AI開発ツール、社内ナレッジ検索、テスト支援、開発プロセス管理を組み合わせる構成を想定しました。
AI開発支援
C#コードの調査、修正案の作成、レビュー観点の整理にAIを活用します。
ただし、検査工程に関わるコードでは、AIによる自動反映は避け、開発者が確認して取り込む運用にします。
安全な運用としては、次のような形です。
- AIが修正候補を提示する
- 開発者が内容を確認する
- 必要な箇所だけ取り込む
- レビューを実施する
- テストを通してから反映する
RAGによる社内ナレッジ検索
仕様書、設計書、テストケース、不具合履歴、改修履歴などを検索対象にします。
RAGの仕組みを使うことで、AIが社内資料を参照しながら回答できます。
重要なのは、回答の根拠を確認できることです。
検査工程では、AIの回答だけを信じるのではなく、参照元資料を確認できる設計にする必要があります。
テスト支援
テストケースの作成、レビューリストの作成、回帰テスト対象の抽出にAIを活用します。
特に、新旧仕様の差分からテスト観点を作る工程は、AIと相性がよい領域です。
これにより、テスト担当者がゼロから考える負担を減らし、確認すべき観点の漏れを減らせます。
管理画面
AI活用を継続するには、管理者が利用状況を確認できることも重要です。
管理画面では、次のような情報を確認できるようにします。
- AI利用件数
- よく使われる質問
- 回答できなかった質問
- 参照された資料
- テストケース生成件数
- コードレビュー支援の利用状況
- 不具合履歴の参照状況
- 利用者フィードバック
- 改善が必要なナレッジ領域
AIは導入して終わりではなく、使いながら改善する仕組みが必要です。
導入で期待できる効果
このようなAI活用により、次の効果が期待できます。
- 新旧仕様書の差分整理を効率化できる
- 既存コードの影響範囲調査を短縮できる
- テストケース作成の下書きを早く作れる
- レビュー観点の抜け漏れを減らしやすくなる
- 過去の不具合や改修履歴を探しやすくなる
- ベテラン担当者への依存を減らせる
- 新機種対応時の開発プロセスを標準化しやすくなる
- AI活用の範囲を安全に広げられる
特に大きいのは、AIを「自動開発」ではなく「開発工程の補助」に位置づけることで、品質責任を守りながら効率化を進められる点です。
BizDXAIの考え方
BizDXAIでは、AI導入そのものを目的にしません。
目的は、開発工数を減らすこと、手戻りを減らすこと、属人化を減らすこと、品質を守りながら新機種対応を早くすることです。
検査用ソフトウェアは、製造品質に関わる重要なシステムです。
そのため、AIにすべてを任せるのではなく、仕様整理、コード調査、テスト設計、レビュー、ナレッジ検索といった工程に分けて、安全に活用することが重要です。
AIは、開発者の代わりに責任を取るものではありません。
開発者がより早く、より正確に判断するための補助者です。
まとめ
検査用ソフトウェア開発では、新機種リリースのたびに仕様確認、コード改修、テスト設計、レビュー、手順書作成が発生します。
この工程をすべて人手で進めていると、開発担当者の負担が大きくなり、属人化もしやすくなります。
BizDXAIでは、C#で内製された検査用アプリケーションを対象に、AIによる仕様差分整理、影響範囲調査、テストケース作成、レビュー観点整理、社内ナレッジ検索を組み合わせた開発工程改善を支援します。
AIで検査ソフトを丸ごと自動生成するのではなく、開発者が安全に判断できる材料を増やし、改修工数と手戻りを減らすことが重要です。
検査用ソフトウェアの改修工数が増えている、C#内製アプリの保守が属人化している、新機種対応を効率化したい場合は、まず現在の開発工程を整理することから始めるのが現実的です。
無料DX診断では、現在の開発工程、AI活用できる作業、初期PoCの範囲、開発効率化の優先順位を整理できます。
