【要約】
こちらの記事は『三菱電機が開発に「RAG」を使う理由とは？ 生成AIプロジェクトの舞台裏』の要約です。三菱電機は2024年、組み込みソフトウェア開発の効率化を目指し、生成AIの活用を開始しました。当初は「ソースコードの自動生成」を目指していましたが、現場の課題を分析し、「何を生成AIに置き換えるか」という視点でユースケースを検討する発想の転換を行いました。
背景と課題
ソフトウェア開発規模の拡大
- IoTの普及などにより、製造業のソフトウェア開発規模が拡大。
- 開発現場では以下の課題が顕在化していました：
- 人材不足：スキルを備えた開発者が不足。
- 属人化：長期間使用されたレガシーシステムに依存。
従来の改善活動
- 2000年代から以下の改善活動を実施：
- **SPL（ソフトウェアプロダクトライン）**での効率化。
- CI/CDの導入によるテスト自動化。
- 課題：製作所ごとに改善進度が異なり、統一的な改善が進まない状況。
生成AI導入の契機
- 生成AIの台頭を受けて、全社的に開発スキルを底上げできる可能性に着目。
- 情報漏洩のリスクが懸念されたが、本社がセキュリティ確保済みの実験環境を提供。
- 製作所側からも生成AI活用への積極的な要望が寄せられる。
プロジェクトの進め方
発想の転換
- 当初の考え方：「生成AIで何ができるか」を模索。
- AWSの助言：「生成AIに置き換え可能な部分はどこか」を特定するアプローチに転換。
- 現場ヒアリング：作業時間や手戻り状況を可視化し、効率化の優先順位を整理。
AWSとの連携
- Amazon Bedrockを活用。
- ユースケースごとに最適なLLMを選定・切り替え可能。
- 生成AI専門家の支援を受けられる点が決め手。
ユースケース選定
- 作業プロセスの可視化を実施。
- 以下の観点から優先順位を検討：
- 効率化のインパクト。
- 実現可能性。
- 最終的に「ソフトウェア改修の影響範囲特定」をユースケースとして採用。
具体的な取り組み内容
従来のプロセス
- ソフトウェア改修依頼を受けた際、人手で以下を実施：
- 仕様書の確認。
- 修正対象ソフトウェアの列挙。
- ソースコードの確認。
- 改修の影響範囲特定。
生成AIを用いた改善
- 開発者が変更要求を入力すると、以下を自動化：
- 影響のある設計書と該当箇所をリストアップ。
- 使用技術：
- LLM：Anthropicの「Claude 2.1」。
- RAG：設計書のテキストデータを検索し、LLMの知識を補強。
効果
- 作業時間を大幅短縮。
- 作業手戻りを削減。
三菱電機は生成AIの可能性を積極的に模索し、効率化とセキュリティの両立を図る新しいアプローチを実現しています。
更に詳しい記事を読みたい方はこちら
