三菱電機が開発に「RAG」を使う理由とは？ 生成AIプロジェクトの舞台裏：組み込み開発における生成AI活用【前編】

三菱電機はソフトウェア開発の効率化を目指し、生成AIプロジェクトを始動した。ユースケース選定で重要だったことや、選んだ生成AIツールとは。PoC（概念実証）に至るまでの過程を解説する。

[梅本貴音，TechTargetジャパン]

　総合電機メーカーの三菱電機は2024年、組み込みソフトウェア開発における生成AI（人工知能）活用の取り組みを開始した。当初は漠然と「ソースコード自動生成をしたい」と考えていた同社だが、ユースケースの選定を経て「RAG」（検索拡張生成）システムの構築を決める。RAGとは、学習データ以外に外部のデータベースから情報を検索、取得し、LLMが事前学習していない情報も回答できるように補う手法だ。

　これによってどのような変化がもたらされるのか。三菱電機の生産システム本部でソフトウェアの改善活動を進める長峯 基氏に、生成AIプロジェクトが始動した背景から、PoC（概念実証）に至る過程までを聞いた。

三菱電機はなぜ開発に「RAG」を使うのか？

会員登録（無料）が必要です

続きを読む

併せて読みたいお薦め記事

システム開発の気になる話題

• 「非エンジニアが開発者になる」は生成AI時代の“幻想”でしかなかった？
• 「DevOpsはもう終わり」論が語られ始めた“本当の理由”

　モノのインターネット（IoT）の普及といった変化が影響し、製造業におけるソフトウェア開発規模は拡大傾向にある。一方の開発現場では、十分なスキルを備えた人材の不足や、長年使い続けてきたレガシーシステムの属人化といった課題が浮き彫りになっている。

三菱電機の長峯 基氏

　三菱電機はこうした状況を踏まえ、2000年代初頭からソフトウェア開発プロセスの改善に取り組んでいる。ソフトウェアプロダクトライン（SPL）の導入による開発の効率化や、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインの導入によるテスト自動化などを通して、開発者エクスペリエンスの向上と業務の高付加価値化を進めてきた。

　しかし課題もあった。改善活動は製作所ごとに進めていたため、進度に差があったのだ。本社側からトップダウンで改善を進める案も出たが、社内における有識者の数などリソースに限りがあり、現実的ではなかったという。

　こうした状況に変化をもたらしたのが生成AIの台頭だ。生成AIをうまく使えば、全社の開発スキルを底上げできる。そう考えた三菱電機は2024年初頭から、開発プロセスでの生成AI活用について検討を開始した。

　情報漏えいなどリスクへの懸念から、生成AIの使用をためらう企業は少なくない。例えば製造業では、設計書などの機密情報が、生成AIを介して流出する事態は避けなければならない。こうした心配はあったものの、「反発よりも後押しする声が社内では大きかった」と長峯氏は振り返る。

　三菱電機の社内規定では、設計書を扱う場合にさまざまな制約があり、上長承認が必須だったり、特定の条件下でしか使えなかったりする。そのため、製作所ごとに個別で生成AIプロジェクトを進めるのは困難だった。本社側でセキュリティを確保した実験環境を作り、その環境を各製作所に提供することで、各製作所から「生成AIを活用する流れに加わりたい」という声が続々と上がったという。

漠然としていたプロジェクト構想　鍵は“発想の転換”だった

　三菱電機の生成AIに関する取り組みにおいて、重要な役割を果たしたのがAmazon Web Services（AWS）だ。三菱電機がAWSを選んだ理由は大きく2つある。生成AIの専門家の支援を受けられることと、生成AIサービス「Amazon Bedrock」（以下、Bedrock）を使えることだ。「LLMはユースケースごとに最適なモデルを選ぶべきだ」というのが当時の通説であったため、LLMの切り替えが容易なBedrockは魅力的だったと長峯氏は言う。

　こうして三菱電機はAWSと連携し、生成AIの取り組みをスタートさせた。長峯氏は当初、“ユースケースの選定から始める必要がある”と考えていた。「世間で話題になっているソースコードの自動生成を組み込み開発でできたらいいな、といった漠然とした要望を当時は持っていました」（長峯氏）

　しかし、AWSからのアドバイスを受けて、まずは現状分析と課題特定を実施した。つまり「生成AIで何ができるか」ではなく「何を生成AIに置き換えるか」というように発想を転換したのだ。開発現場へのヒアリングを通して、作業ごとにかかる時間や手戻りの発生状況を可視化。生成AIに置き換え可能な部分を抽出し、インパクトの大きさや実現可能性といった観点から優先順位を検討した。「最初に現場との擦り合わせをしたことで、PoC段階での手戻りをかなり抑えることができました」と、長峯氏はその効果を振り返る。

　検討の結果、ユースケースの一つとして選んだのは「ソフトウェア改修の影響範囲の特定」だ。従来ソフトウェア開発部門は、製品開発部門から改修依頼を受領した際、仕様書の確認から修正対象のソフトウェアの列挙、ソースコードの確認、影響範囲の特定までを人手で進めていた。このプロセスを生成AIに置き換えることにした。

　目指したのは、開発者がソフトウェアの変更要求を入力すると、影響のある設計書と該当箇所を生成AIがリストアップしてくれるシステムだ。AIモデルにはAnthropicの「Claude 2.1」を使い、RAGによって設計書のテキストデータを検索させることにした。

---

　後編は、三菱電機がPoCで直面した課題と、その成果を紹介する。