「置換」ではなく「要約」 住友ゴムが実践したレガシーコードマイグレーションの新しいカタチ：Generative AI Summit Tokyo '24 セッションレポート

Google Cloudが2024年3月7日に開催した「Generative AI Summit Tokyo '24」で、住友ゴム工業の角田昌也氏は、デジタル設計の工程に不可欠な「コンピュータシミュレーション」に関連したプログラムの生成やマイグレーションにおける生成AIの活用事例を紹介した。

[柴田克己，＠IT]

　製造業において、製品シミュレーションなどの「性能予測」の領域は、これまでも積極的にデジタル化の投資が進められてきた。この領域に、現在進化が著しい「生成AI」の技術が適用されると、どのような成果が期待できるのか。

　Google Cloudが2024年3月7日に開催した「Generative AI Summit Tokyo '24」では、住友ゴム工業の角田昌也氏（研究開発本部　研究第一部長）が「製造業における生成AIを使った業務効率化への取り組み」と題した講演で、同社における生成AI活用の取り組みを紹介した。

設計のデジタル化が進み重要性が増す「性能予測シミュレーション」

　住友ゴム工業は、1909年にダンロップの極東工場としてスタートした。1913年には自動車用タイヤ（以下、タイヤ）の生産をスタートし、現在に至るまで主力製品となっている。ただ、タイヤメーカーとはいえ、近年では車両メーカーの開発プロセスのデジタル化に追従する形で、設計のデジタル化が加速していると角田氏は語る。

住友ゴム工業の角田昌也氏

　「車両開発のデジタル化に伴って、タイヤのようなパーツについても試作する前にデジタルデータで仕様をやりとりするケースが増えてきた。設計のデジタル化と、コンピュータシミュレーションによる性能予測の重要性が非常に高まっている」

　言うまでもなく、自動車にとってタイヤは不可欠なパーツだ。数百キロから数トンに及ぶ車重を安全に支えるために高い性能が求められる。この「性能」の指標は多岐にわたり、転がり抵抗や摩耗量、動特性、耐久性、ぬれた路面での制動力に関係するハイドロ性能、空気抵抗などがある。タイヤの設計においては、こうした性能を事前にシミュレーションで「予測」することが重要になる。

　住友ゴム工業は、1990年ごろから製品設計にコンピュータでの性能予測を積極的に取り入れてきた。タイヤのバネ特性といった基本性能の解析をはじめ、静的（あるいは動的）な構造解析、流体構造連成解析、さらにはスポーツ用品であるゴルフボールの空力特性、ゴルフクラブの気候解析など、その適用領域はさまざまで、30年以上の歴史の中で多くのノウハウを蓄積している。

住友ゴム工業における“デジタル化”の歴史

　「シミュレーションはモデルを作成した後、さまざまな条件を設定してスーパーコンピュータなどで計算を実行して、その結果をグラフ化したり、色づけして分かりやすく可視化したりといった後処理を実施する流れで進む。各工程で、市販の汎用（はんよう）アプリケーション（以下、アプリ）や自作（内製開発）したアプリを利用するが、その種類と役割は多様で、現在利用されている内製アプリは150本を超えるという。それらを市販の汎用アプリと連携させる際には、市販アプリ側でプログラミング言語が指定されているケースが多く、非常に多くの言語に対応する必要がある」と角田氏は説明している。

　住友ゴム工業における性能予測業務用アプリケーションは歴史が古く、「Fortran」や「Perl」といった言語で書かれているものも現役で稼働している。また、技術計算を行う市販アプリについても「Java」「LISP」「Python」「MATLAB」など対応言語が異なっている状況だった。

シミュレーション手法開発部門が抱える「プログラミング」の課題

　角田氏は、同社でシミュレーション手法の研究開発を長く手掛けてきた。その中で、製造領域でのシミュレーション活用について、幾つかの課題を感じてきたという。その一つはプログラミングに関するものだ。

シミュレーション手法開発部門が抱える課題

　これは、自社でアプリケーションを開発する企業が避けて通れない、技術やノウハウの「継承」についての課題だ。内製開発で長く使われているアプリケーションは、開発言語が前世代のものが使われていることが多い。その言語を扱えるエンジニアが退職してしまった場合、保守が難しくなる。加えて、市販アプリを使っている場合は、必要に応じて各アプリ専用の言語を使い分けなければならない。新旧織り交ぜた多数の言語を、業務に合わせて自在に扱える高いスキルを持ったエンジニアは極めて限られてしまう。

　住友ゴム工業は、この課題の解決に「生成AI」で挑んでいる。生成AIによるプログラムコードの要約、自動生成、自動変換を活用し、コード資産やスキルの継承、複数言語の使い分けを効率化していくという取り組みだ。2023年10月から開始し、部門横断の調査チームを結成して、「Google Cloud」や「Duet AI」（現Gemini for Google Cloud）などの導入効果を検証している。

　検証に当たっては、自社が所有するコードやデータをクラウドに送ることになるため、ガバナンスやセキュリティについてのチェックも徹底したという。

　「Google Cloudは、顧客であるわれわれのデータを、基盤モデルのトレーニングには使用しないと明示している。また、アカウントごとのアクセス制御によって個人やプロジェクト単位でアクセスできるセキュアな環境を構築できるため、問題ないと判断した」（角田氏）

　検証のための開発環境は、同社で利用者が多いMicrosoftの「Visual Studio Code」（以下、VS Code）のプラグインを利用して構築した。

開発環境の画面イメージ

　生成AIは、VS Code下部のステータスバーからの呼び出す形だ。画面左のパネルで生成AIとチャット形式で対話ができるようにした。その他、コードエディタ上で「コメント文」としてプロンプトを記入することで、AIによって自動生成されたコードが表示される。例えばコード上の変数を選択した状態でチャットパネルに問い合わせれば、変数についての詳細情報が得られる。画面右のパネルには「Jupyter Notebook」の画面も表示でき、コードエディタ上でのキー操作に連動して、コード実行やグラフ表示などができる。複数のウィンドウを切り替えることなく、1枚の画面上で必要な作業が全て実施できるものになっているという。

「スクリプト言語同士の変換」は生成AIと好相性

　同社は、この開発環境を利用し、生成AIによる「コードの自動生成」「プログラミング言語の変換」の検証を進めた。

　例えばコードの自動生成については、チャットから「CSVデータを読み込み、3Dプロットを描画するプログラムをPythonで書いて」といったプロンプトを送る。この時点で、コードは自動生成されるが、そのままでは実行時にエラーが出たり、イメージしたものと出力結果が違っていたりといったことが起こる。その場合、最初に生成されたコードを維持した状態で「このようなエラーが出たので修正して」「プロットする点のサイズを、後から変更できるように書き換えて」といった指示（プロンプト）を出し、段階的に修正するといった対策をしている。

　自動生成されたコードが問題なく動いているように見える場合でも、本当にプロンプトで指示した通りの挙動になっているかどうかは、別の方法で確認する必要がある。この場合、角田氏は生成AIで単体テストのコードを作成し、確認しているという。

　プログラミング言語の変換については、「変換元と変換先の言語によって、得手不得手がある」と角田氏は話す。同氏によると、生成AIとの相性が良いのは「スクリプト言語同士の変換」で、PerlからPythonへの変換、MATLABで作成した信号処理プログラムのPythonへの変換などではおおむね良好な結果が得られたという。

スクリプト言語同士の変換

　一方で、「コンパイルを前提とした言語からスクリプト言語への変換」は、それほど簡単ではなかった。角田氏は「FortranからPythonへ直接変換させようとしたら生成AIから断られてしまった」と話す。

　ただし、この場合も“ちょっとした工夫”をすることで、全てを人手でやるよりも短時間かつ効率的に変換ができたケースはあったと角田氏は振り返る。まず、コンパイラ言語のコードを生成AIに渡した上で「このプログラムの内容を要約せよ」と指示を出す。次に、生成AIが出力した「要約」の内容を、人間側で整理、修正した上で「この内容をこの言語（Pythonなどのスクリプト言語）でコード化せよ」と指示するといった具合だ。

直接変換が難しい言語の変換

　「変換後のコードでエラーが出る場合は、コードの自動生成と同じように『修正を求めるプロンプトを使って、うまく直せるかどうか試してみる』『それでもうまくいかなければ、社内の有識者にレビューを依頼する』といった流れが妥当だと考えている。そうしたプロセスにすることで、有識者の対応負担はかなり軽減できる」（角田氏）

Google CloudとDockerで内製アプリを迅速に配布

　こうした検証を通じ、住友ゴム工業は「生成AIを活用したプログラミングの課題解決」を模索している。しかし、同社には別の課題も残されていた。それは「アプリの配布や保守」に関するものだ。

　特にスタンドアロンで動作するアプリの場合、「不具合修正や機能追加をしたが、ユーザーへの配布に手間がかかる」「Pythonで開発したプログラムを設計部門に使ってもらいたいが、それぞれのユーザー環境での設定が面倒」といった問題が起きがちだ。内製アプリをWeb化することである程度は解決できるが、それでも「『自分たちでWebサーバを運用管理したくない』といった問題が残る」と角田氏は指摘している。

　同社は、この課題にGoogle Cloudと「Docker」の組み合わせで対処した。手順としては、シミュレーション部門のエンジニアがVS Codeで書いたアプリを「Dockerイメージ」としてリリースしておき、他部門を含むユーザーがそれを「Cloud Run」で実行するという流れだ。

Webアプリ化の手順

　こうしておくことで、ユーザーが利用するアプリは、個々のクライアント環境にかかわらず、常に最新の状態で実行できる。Cloud Runはフルマネージドサービスのため、実行環境としてのWebサーバを自社で管理する手間もかからない。また、利用料金は従量課金制なため、アプリケーションの実行時に使われたリソース分だけを支払えばよいという利点もある。住友ゴム工業は、この環境で「3D-Plotアプリ」「報告書検索アプリ」「PDF文書要約アプリ」などを内製し、社内に展開しているという。

　「従来、こうした形で社内にアプリを配布したい場合、どうしてもシステム部門に頼る必要があった。ただ、LLMのような生成AIの技術はアップデートが早いため、そのメリットをいち早く享受するためにも、アジャイル的な内製開発に取り組んでいる。ここに挙げたアプリは、いずれもエンジニアが“あると便利だな”と思ったアプリケーションを1週間程度で作成し、すぐに社内に展開できている。その意味で、Google Cloudは本当にパワフルな環境だと感じている」

　角田氏は、設計のデジタル化が進む製造業での生成AI活用には「有識者、開発者の負担軽減」「アプリの開発コスト削減」「アプリの維持コスト削減」といった効果があることを改めて強調した。今後は、「Duet AI」「Gemini」といった生成AI、そしてインフラとしてのGoogle Cloudの活用レベルを高めながら、社内エンジニアのスキルの底上げ、既存アプリケーションの整理や統廃合、既存アプリケーションのWeb化などを進めていきたいとする。

　「検証の間にも、生成AIはバージョンアップするたびに、その能力が上がっていることを実感できた。特にプログラムコードの生成能力、修正能力については、進化のスピードが著しく、今後のさらなるパワーアップにも期待をしている」と締めくくった。