一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATIONCOMMUNICATION ENGINEERS
一般社団法人AND
電子情報通信学会

信学技報
IEICE Technical Report
KBSE2023-45,SC2023-28(2023-11)
信学技報

THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

IEICE Technical Report

LLM を活用したソフトウェアアップサイクルにおける素材抽出手法の検討
寺川 航平†

陳思楠†

佐伯 幸郎††

中村 匡秀†,†††† 神戸大学 〒657–8501 神戸市灘区六甲台町 1–1††† 理化学研究所・革新知能統合研究センター 〒103–0027 東京都中央区日本橋 1–4–1†† 高知工科大学 〒782–8502 高知県香美市土佐山田町宮ノ口 185
E-mail: †odajin@ws.cs.kobe-u.ac.jp, ††chensinan@gold.kobe-u.ac.jp, †††saiki.sachio@kochi-tech.ac.jp,††††masa-n@cmds.kobe-u.ac.jp
あらましソフトウェア開発の現場には，組織特有の知見や組織内でのみ運用されるソフトウェアが存在する．そうした過去の開発プロジェクトに蓄積された知識をアップサイクルすることで，開発効率の向上と既存知識の活用を目指すソフトウアアップサイクルという考え方がある．しかし，ソフトウェア開発の背景や技術知識を持たない人がアップサイクル素材を抽出することは困難である．そこで本研究では，LLM を活用して個人の能力・知識に依存しないアップサイクル素材の抽出手法を提案する．評価実験として，素材抽出手法の正確性・網羅性・アップサイクルの文脈に対する適切性を検証する．具体的には，3 つのソフトウェアアップサイクルにおけるユースケースを検討する．
それぞれについて提案手法を用いた素材抽出を行い，結果の考察を行う．
キーワード

ソフトウェア開発, 技術的負債, ソフトウェアアップサイクル, LLM

Study of Extracting Material in Software Upcycling with LLM
Kohei TERAKAWA† , Sinan CHEN† , Sachio SAIKI†† , and Masahide NAKAMURA†,†††† Kobe University, Rokkodai-cho 1–1, Nada-ku, Kobe, Hyogo, 657–8501 Japan††† Riken AIP, 1–4–1 Nihon-bashi, Chuo-ku, Tokyo, 103–0027 Japan†† Kochi University of Technology, 185 Tosayamadacho Miyanokuchi, Kami, Kochi, 782–8502 Japan
E-mail: †odajin@ws.cs.kobe-u.ac.jp, ††chensinan@gold.kobe-u.ac.jp, †††saiki.sachio@kochi-tech.ac.jp,††††masa-n@cmds.kobe-u.ac.jp
Abstract In the ﬁeld of software development, there exists domain-speciﬁc knowledge and software that is used only within
speciﬁc organizations. The concept of software upcycling aims to improve development eﬃciency and leverage existing knowledge by repurposing knowledge accumulated from such knowledge and software. However, extracting upcycling materials fromsuch softwares is diﬃcult for individuals who lack a background in software development and technical knowledge.Therefore,
this study proposes a method for extracting upcycling materials that is not dependent on individual abilities and knowledge
by utilizing Large Language Models (LLMs). As part of the evaluation experiment, the accuracy, comprehensiveness, andappropriateness of the upcycling material extraction method within the context of upcycling are examined. Speciﬁcally, weconsidered three software upcycling use cases. We applied the method to extract materials for each case.
Key words Software Development, Technical debt, Software Upcycle, LLM
トウェアの保守や管理，ドキュメント化といった作業に適切な

1. は じ め に人的資源を充てる必要がある．こうした保守・運用にリソース

近年の技術進歩に伴い，様々な組織・会社で新たなソフトウェが割かれない現場では，次第に技術的負債が蓄積してゆく [1]．

アの開発が進められている．ソフトウェアを取り巻く環境変化

こうしたソフトウェアの開発運用の課題を解決する考え方とに対応する形で，開発現場は新規開発や機能追加といった対応して，ソフトウェアアップサイクルがある [2]．ソフトウェアを迫られる．同時に，ソフトウェアの開発持続性を考慮しソフ

アップサイクルは，既存プロジェクトに隠された知的資産を新- 63 -This article is a technical report without peer review, and its polished and/or extended version may be published eleswhere.
This article is a technical report without peer review, and its polished and/or extended version may be publishedelsewhere.
Copyright©2023 by IEICE
Copyright ©2023 by IEICE

規のソフトウェア資産として転換することで，開発効率の向上よって新規の価値あるソフトウェア資産に転換することである．と既存知識の活用を目指す考え方である．ソフトウェアアップ

特に，アップサイクルを図る素材をソフトウェアアップサイク

サイクルは既存プロジェクトからのアップサイクル素材の抽出

ル素材と呼ぶ．具体的にはソフトウェアにまつわる一般的な知と抽出した素材を組み合わせる 2 つのステップが存在する [3]．

識・情報や特定の組織内でのみ運用される知識・情報を指す．

特に，素材抽出のステップではプログラミング言語やライブラ

ソフトウェアアップサイクルは，アップサイクル素材の抽出リといった技術に関する知識や，組織内特有の暗黙知やライブとアップサイクル素材の組み合わせの２つの工程に分かれてラリへの理解などが求められる．

いる．ソフトウェアアップサイクルにおける課題は，素材抽出

しかしながら，組織内でのソフトウェア開発背景や技術知識の成否が個人の能力・知識に依存することである．プログラムを持たない人がアップサイクル素材を抽出することは困難であ

コードを読み解き，適切な素材を選び取るには様々な知見がる．ソフトウェアが作られた経緯や意図，実装の詳細，管理方必要となる．具体的には，プログラミング言語やライブラリと法といった情報が明らかでない場合や，用いられる技術に対すいった技術に関する知識や，組織内特有の暗黙知やライブラリる知識を備えていなければ，ソースコードを理解するために多への理解などが挙げられる．

くのコストがかかる．ソフトウェアアップサイクルを促進する

2. 3 予備実験大規模言語モデル (LLM)

ためには，アップサイクルを行う人の知識や能力に依存するこ

大規模言語モデル (LLM) [4] は，大量のテキストデータでトとなく，既存ソフトウェアから適切にアップサイクル素材の抽レーニングされた自然言語処理モデルである．自然言語を用出を行うことが課題である．

いて様々な処理を行う事が可能であり，チャットボットや検本研究では，非公開情報やドメイン知識を伴う組織内ソフ索エンジン，翻訳といった幅広い領域で利用されている．ソトウェアからアップサイクル素材を抽出すること目的とする．

フトウェア開発の分野でも利用が広まっており，OpenAI 社とキーアイデアとして，近年普及が進んでいる大規模言語モデル

GitHub 社が共同で開発した Github Copilot というツールでは，（LLM）の一種である GPT モデルを利用する．具体的には，以コード補完や解説といった機能が提供されている [5]．

下の 2 つのリサーチクエスチョンを設定する．

一方で，LLM は非公開情報やドメイン知識を伴う出力の生成

RQ1 アップサイクル素材抽出プログラムを用いて，組織内に対してハルネーションを起こす傾向がある [6]．このような

LLM の学習データに存在しない知識に関する生成を行う手段

ソフトウェアにまつわる正確な情報取得は可能か？

RQ2 アップサイクル素材抽出プログラムを用いて，組織として，In-context Learning がある．In-context Learning では，内ソフトウェアからニーズに基づいた網羅的な素材抽出は可プロンプト内に出力生成の際に参照させる情報を併せて入力す

能か？

る．多くの LLM には入力できるプロンプト長に上限が存在す

評価実験として，神戸大学中村研究室内で管理・運用しているソフトウェアに対し提案手法を適用する．ソフトウェアアッるため，トークン上限の範囲内で事前知識をプロンプトに含める必要がある．

プサイクルに関する 3 つのユースケースを想定して，アップサ

3. 提 案 手 法

イクル素材の正確性や網羅性，ユースケースの文脈に対する適切性などを評価する．

2. 準

3. 1 目的とキーアイデア
本研究の目的は，プログラムの実行を通じて，組織内ソフト

備ウェアのソースファイルからソフトウェアアップサイクル素材

2. 1 技術的負債を抽出することである．キーアイデアは，LLM を活用したソフ

技術的負債とは，ソフトウェア開発運用を行う中で蓄積するトウェアアップサイクル素材の抽出である．本研究のアプロー

改修しなければならないプロダクトの全体，あるいはその一部

チは次のとおりである．

である．不具合（バグ）だけでなく，十分な作業時間が確保で（A1） アップサイクル素材の定義きなかった等の理由で，作成されたものの改善の余地が多分に（A2） アップサイクル素材の抽出を行うプロンプトの設計残るプロダクトも技術的負債に含まれる．

（A3） LLM を用いた素材抽出アルゴリズムの構築

ソフトウェア開発を行う組織内には，特有のドメイン情報や

3. 2 (A1) アップサイクル素材の定義非公開のソフトウェア等が存在する．本稿では外部への公開を

ソフトウェアアップサイクル素材とは，ソフトウェアに含ま想定しない，特定の組織内でのみ開発・運用を行うソフトウェれるコード・設計や実装のアイデアといった情報を指す．しかアを組織内ソフトウェアと呼ぶ．組織内ソフトウェアは組織特し，すべての人にとって価値を持つアップサイクル素材は存在有のコンテキストや非公開情報を含む場合が多く，仕様の文書しない．素材の有用性は，アップサイクルを行う人やコンテキ化や説明の不十分さが属人化を進行させる要因となる．こうしストに左右される．例えば，ある技術に関する周辺知識を持たた組織内ソフトウェアに関する仕様や実装の理解を得るためにない人にとっては，その技術を用いて作成されたソフトウェアは，多大なコストを掛けて解読する必要がある．

は技術の使用例として参照されうるため，再利用価値を持つこ

2. 2 ソフトウェアアップサイクル [2]とになる．

ソフトウェアアップサイクルとは，既存プロジェクトの一部

3. 3 (A2) アップサイクル素材抽出のためのプロンプト設計分であるコード・設計・文書といった素材を，アップサイクルにLLM を用いてアップサイクル素材抽出を行うためのプロン- 64 -—2—

プトを設定する．プロンプトは一般的に以下の要素で構成され#instruction䛣䜜䛛䜙䠈䝍䞊䝀䝑䝖䝋䝣䝖䜴䜵䜰䛻ྵ䜎䜜䜛䝋䞊䝇䝣䜯䜲䝹䜢#input䛸䛧䛶ᥦ౪䛧䜎䛩䚹୚䛘䜙䜜䛯#context䛻ᇶ䛵䛔䛶䚸䛣䜜䜙䛾䝋䞊䝇䝣䜯䜲䝹䛛䜙䝙䞊䝈䛻ᙺ❧䛴䛾䜏䜢ᢳฟ䛧䛶䛟䛰䛥䛔䚹
ᙺ❧䛴᝟ሗ䛜Ꮡᅾ䛧䛺䛔ሙྜ䛿"䛺䛧"䛸⾲♧䛧䛶䛟䛰䛥䛔䠊ᢳฟ䛧䛯᝟ሗ䛿䝸䝇䝖ᙧᘧ䛷♧䛧䛶䛟䛰䛥䛔䚹る [7] [8]．
•

命令: LLM に実行してほしい特定のタスクまたは命令•

文脈: 前提条件や背景情報を含む文章•

入力データ: 出力を得るために必要な入力や質問•

出力指示子: 出力のタイプや形式#context
㛤Ⓨ⪅䛿௨ୗ䛾䝙䞊䝈䜢ᣢ䛳䛶䛔䜎䛩䚹needs:{{upcycle_needs}}
䛣䜜䜙䛾䝙䞊䝈䜢‶䛯䛩䛯䜑䛻䚸䝍䞊䝀䝑䝖䝋䝣䝖䜴䜵䜰䛛䜙㛵㐃䛩䜛᝟ሗ䜢ᢳฟ䛧䛯䛔䛸⪃䛘䛶䛔䜎䛩䚹䜎䛯䠈௨ୗ䛾᝟ሗ䛿㛤Ⓨ⪅䛜▱䛳䛶䛔䜛▱㆑䛷䛩䠊ᢳฟ䛻ᙺ❧䛴ሙྜ䛿ཧ⪃䛻䛧䛶䛟䛰䛥䛔䠊
information:{{related_information}}

アップサイクル素材を抽出する状況に応じた命令・文脈・入力データの設定を行う．3. 2 で述べたように，アップサイクル素材はアップサイクルを行う状況やコンテキストに依存する．
アップサイクルを行う人が持つニーズや知識量に応じたプロン#input: """{{input}}"""

プトを作成できるように，プロンプトの雛形を図 1 のように定める．

#output:

文脈の設定として，context 部分でソフトウェアアップサイ

図 1: プロンプトの雛形

クルの経緯を表す．当事者の持つニーズ (upcycle_needs) とそれに関連する情報 (related_information) を当事者の把握する範67(3囲で記述する．命令の設定として，instruction 部分で定型文の指示を行う．文脈に基づき，関連する情報の抽出を指示する．

ϨϛζφϨ

文脈としては，アップサイクルを行う人が知りうる情報や経緯

ʞλʖηϓΟ΢ϩを記述する．入力データの設定は input 部分で行う．ここには，アップサイクル素材の抽出対象となるソースファイルが埋め込

67(3

まれる．出力指示子として，抽出した情報をリスト形式で出力αϱτΫηφபड़ࢨࣖ‫ؖ‬࿊৚ๅ^^λʖηϓΟ΢ϩ``するよう指示を与える．

3. 4 (A3)LLM を用いた素材抽出アルゴリズムの構築
素材抽出アルゴリズムは以下の要素で構成される．処理の流ϕϫϱϕφ͹ਿ‫ܙ‬

れを図 2 に示す．

67(3Step 1. リポジトリマイニング
Step 2. プロンプトの雛形の定義
Step 3. プロンプトの作成
Step 4. ソースファイルごとの LLM 実行λʖηϓΟ΢ϩ

Step1 では，対象となるソフトウェアのリポジトリに対してリポジトリマイニングを行う．Step2 では，LLM へ入力するプロਿ‫ܙ‬ϕϫϱϕφ67(3ンプトの雛形を作成する．3. 3 で検討した項目に基づき，アップサイクルの文脈に応じた内容を作成する．Step3 では，Step2 で//0作成したプロンプトの雛形にソースファイルを埋め込む．Step4
では，Step1 で取得したソースファイルに対応するすべてのプϕϫϱϕφ

ロンプトを LLM に入力する．

4. 実ોࡒபड़݃Վ

図 2: 素材抽出アルゴリズムの動作フロー

装リポジトリマイニングの対象は，神戸大学中村研究室で運チクエスチョンを確認することを目的とした評価実験を行った．

用されている Gitlab である．Pyhon から Gitlab API を用いてソースファイルを取得した．Step2, 3 については Python とRQ1 アップサイクル素材抽出プログラムを用いて，組織内ソフトウェアから正確かつ網羅的な素材抽出は可能か？

LangChain というライブラリを用いて実装した．LangChain [9]とは，LLM を利用して効率的にアプリケーション開発を行う

RQ2 アップサイクル素材抽出プログラムを用いて，組織内ソフトウェアからニーズに即した素材抽出は可能か？

ためのフレームワークである．プロンプトとソースファイル

4. 2 実 験 準 備の結合には，LangChain の提供する PromptTemplte 機能を利用評価実験で使用する組織内ソフトウェアとして，神戸大学した．LangChain の Models 機能を用いて，OpenAI が提供する中村研究室で開発された SensorBoxManageService を使用した．

GPT-3.5-turbo-16k をサンプリング温度 0.0 で使用した．

SensorBoxManageService とは，複数のセンサを箱に入れて IoT

4. 1 評 価 実 験として動作するようにした SensorBox [10] という物理デバイス

4. で構築した素材抽出アルゴリズムを用いて，以下のリサー- 65 -—3—の管理を行う Web サービスである．SensorBoxManageService-や SensorBox は神戸大学中村研究室の研究活動範囲内でのみ運用している．GPT-3.5 に対してこれらのサービスに対する情報の回答を生成させたところ，正確な情報が生成されなかったことを確認した．

SensorBox䛸䛿䠈」ᩘ䛾䝉䞁䝃䜢⟽䛻ධ䜜䛶IoT䛸䛧䛶ືస䛩䜛䜘䛖䛻䛧䛯䜒䛾- ྛ䝪䝑䜽䝇䛻䛿㆑ู䛾䛯䜑䛾ID䛜䛴䛔䛶䛔䜛(౛)sbox-phidget-446048- 䝪䝑䜽䝇䛜཰ᐜ䛩䜛䝉䞁䝃䛿䠈䝉䞁䝃䝪䝑䜽䝇ᐃ⩏䝣䜯䜲䝹䛷⮬⏤䛻ᐃ⩏䛩䜛

図 3: SensorBox に関する説明評価実験では，自然言語での説明記述の影響をなくすため

SensorBoxManageService のソースファイル内のコメントや仕様

表 1: ファイルごとの出力結果の概要書を削除する．4. で作成したプログラムを用いて，SensorBox-ユースケース

ManageService 内の計 22 件のソースファイルに対して処理を行った．評価方法については，著者がファイルごとに出力される生成結果に含まれるリスト要素の内容と，事前に作成した仕平均文字数 平均要素数

1130

42776

15371816

様書を照らし合わせることで RQ に関する分析を行う．

4. 3 ユースケース
リサーチクエスチョンを確認するため，SensorBoxManageSer-

20

vice を対象としたソフトウェアアップサイクルのユースケース15を検討した．ユースケースごとに素材抽出に使用するプロンプ
਼݇トを変更し，4. で作成したプログラムを実行する．各ユース

10

ケースにおけるプロンプトの変更箇所は，3. 3 で示したプロンプ
5トの雛形における upcycle_needs と related_information である．

4. 3. 1 使用技術の抽出

0ਜ਼֮੓

使用される技術要素を知ることは，組織内ソフトウェアに関する知見がない場合や，全体像を掴む場合の最初のステップとຮͪͤして有効である．使用技術の有無は明確に判断できるため，こ໤ད੓ຮͪ͠͵͏

図 4: 4. 3. 1 の評価結果のユースケースを通じて素材抽出の正確性や網羅的といった評価を行う．プロンプトの雛形への入力は以下のとおりである．

3 の情報をプロンプトに付加する．
•upcycle_needs: このソフトウェアに用いられている技術要素 (プ4. 4 実 験 結 果

ログラミング言語・ライブラリ・フレームワーク・API) を知りたい•

各ユースケースについて，各ファイルごとの出力結果の概要

related_information: なしを表 1 に示す．平均要素数とは，LLM からの出力に含まれるリスト要素をファイルごとに算出した際の平均値を表す．平均文

4. 3. 2 組織内ソフトウェアに関連する実装の抽出
SensorBoxManageService では，SensorBox という研究室独自のプロダクトを扱う特性上，さまざまな組織内ソフトウェアと連携する仕組みになっている．具体的には，SensorBox の管理者や配置場所といったプロパティ情報は Scallop4SC [11] というサービスから API 経由で呼び出しており，SensorBox の計測した時系列データの可視化には TimeSeriesViewer という webサービスを利用している．こうした組織内ソフトウェアの関連する実装についての情報抽出を試みる．

用モデル（gpt-3.5-turbo-16k）のトークン上限である 16k tokenの範囲内であり，すべての出力結果についてリストでの出力形式をとっていた．
図 4 は，出力結果について 4. 3. 1 の観点から内容正確性，網羅性の２つの特性から分析したものである．内容正確性とは，入力となるソースファイルの内容から判断して，虚偽の内容が出力に全て含まれているかを示す．
図 5, 6 の結果は，4. 3. 2, 4. 3. 3 の観点から出力結果について

upcycle_needs:どのようにセンサボックスに関する情報を管理しているか知りたい•に算出した際の平均値を表す．LLM への入出力はいずれも利含まれていないかを示す．網羅性とは，ニーズに関する情報がプロンプトの雛形への入力は以下の通りである．
•字数とは，LLM からの出力に含まれる文字数をファイルごと内容正確性，適切性の２つの特性から分析したものである．適

related_information: なし

切性とは，ニーズと文脈に即した出力であるかどうかを示す．
例えば，出力結果がソースファイルの内容を正しく説明してい4. 3. 3 事前知識を含めた組織内ソフトウェアに関連する実装の抽出るが，ニーズに即した情報でない場合は適切性を満たさないと判断する．

LLM は非公開情報やドメイン知識に関する出力を苦手とする．そこで，このユースケースでは SensorBoxManageService の管理対象となる SensorBox にまつわる情報を与える．具体的には，4. 3. 2 のプロンプトに加えて，related_information として図- 66 -—4—

一方で，4. 3. 2 に加えて組織内ソフトウェアの付加情報を与えた 4. 3. 3 については，図 6 から内容正確性が 64% であること20がわかる．付加情報に関連するソースファイルについてはより15

詳細に情報が抽出できたが，関連のないソースファイルに対し਼݇ては図 3 で示した付加情報がそのまま抽出結果に含まれる結果10となった．4. 3. 2, 4. 3. 3 における付加情報の有無が内容正確性5に与える影響について述べる．4. 3. 3 では，ソースファイルの内容とは無関係な出力内容が多く見られた．具体的には，単に0ਜ਼֮੓ຮͪͤన઀੓

プロンプト内の情報を鸚鵡返しするような内容であり，図 5 とຮͪ͠͵͏比較して内容正確性が 26% 低下している．
今回用いたプロンプトでは，一律にすべてのソースファイル

図 5: 4. 3. 2 の評価結果に付加情報とともに LLM へ入力を行っていた．本研究でのプロンプトを用いてソースファイルからの抽出を行う際は，コンテキストを補強する付加情報の内容が虚偽の出力を生む大きな20要因となる事がわかった．
15

਼݇

5. 2 RQ2: アップサイクル素材抽出プログラムを用いて，組織内ソフトウェアからニーズに即した情報は抽出可

10能か？
図 5, 6 について，適切性がそれぞれ 27%, 31% と低い結果と5なった．適切性を満たさないと判断した主な要因は，多くの出0ਜ਼֮੓ຮͪͤ

力内容が網羅的なソースファイルの説明となっていた点であన઀੓る．ソースファイル中にニーズに即した情報が存在しない場合

ຮͪ͠͵͏

については存在しない旨を出力するようにプロンプトを設計し
図 6: 4. 3. 3 の評価結果ていたが，これらの指示通りに出力をする例は数件しか見られなかった．

5. 考

4. 3. 2, 4. 3. 3 における付加情報の有無が適切性に与える影響

察について述べる．5. 1 では，ニーズへの関連性が薄いソース

5. 1 RQ1: アップサイクル素材抽出プログラムを用いて，組ファイルの出力がソースファイルへの網羅的な説明となる傾向

織内ソフトウェアから正確かつ網羅的な情報取得は可にあることを確認したが，付加情報によって出力内容が変化能か？

する例も見られた．図 7 は，4. 3. 2, 4. 3. 3 それぞれについての

図 4 は，4. 3. 1 での技術要素の抽出における内容正確性が 90%

SensorBoxManageService に含まれる getConﬁg2.cgi というソーとなったことを示す．実験で用いたデータには自然言語でのコスファイルへの出力結果である．4. 3. 2 では詳細に実装流れをメントなどは存在しないため，ソースファイル内で用いられて説明する内容であるのに対して，4. 3. 3 ではエンドポイントの管いる記法や構文などの情報から，幅広く技術要素の抽出が可能理という主題に関連のある内容に絞った情報を出力しているこであるとわかった．一方で，網羅性を満たさない例が 6 件存在とが分かる．プロンプトに付加情報を与える場合，ソースファした．これらはすべて Scallop4C といった組織内ソフトウェア

イルとの関連性が薄い場合は出力の正確性を下げる可能性があの利用を抽出できなかったことが要因である．これらの組織内る．一方で，ソースファイルの内容を補強する情報を付加した

ソフトウェアはソースファイル内で REST API の形式で利用さ場合は適切性を上げることがわかった．

れており，エンドポイントに含まれる文字列のみしかそういっ

6. ま と めたソフトウェアとの関連を示す情報が存在しなかった．このよ
うに，サービス名の文字列のみから組織内で用いられるライブ

本研究では，組織内ソフトウェアに対する，当事者の能力・ラリ・API であることやその働きを認識することは困難である．

知識に依存しないアップサイクル素材の抽出手法を提案した．

これらの結果から，組織内ソフトウェアに用いられる一般的なキーアイデアとして LLM を利用したソースファイルからの技術要素の抽出は可能であるが，他の組織内ソフトウェアとアップサイクル素材抽出に着目し，具体的な実装を与えて評価いった技術との関連を抽出することは困難である事がわかる．

実験を行った．実装では，LLM として gtp-3.5-turbo-16k を利用

図 5 は，4. 3. 2 での組織内ソフトウェアからの素材抽出におして筆者の所属する研究室で管理するソフトウェアに対する抽ける内容正確性は 90% であることを示す．いずれもソースコー出を行った．

ド内に記述された実装を正しく説明していた．正確性を満たさ結果として，技術要素の抽出や実装の詳細な説明の取得にはないと判断した 10% については内容に関連する単語の羅列の高い正確性が確認できた．また，プロンプトに付加情報を与えみが抽出されており，詳細な説明が省略される結果となった．

る場合，ソースファイルとの関連性が薄い場合は出力の正確性- 67 -—5—䞉ᑐ㇟䛾䝋䝣䝖䜴䜵䜰䛿Perl䝥䝻䜾䝷䝭䞁䜾ゝㄒ䜢౑⏝䛧䛶䛔䜎䛩䚹䞉䝋䝣䝖䜴䜵䜰䛿௨ୗ䛾䝰䝆䝳䞊䝹䜢䜲䞁䝫䞊䝖䛧䛶䛔䜎䛩:HTML::Template䚸LWP::Simple䚸XML::Simple䚸CGI䠈
Data::Dumper䚸Encode䚸JSON䚹䞉䝋䝣䝖䜴䜵䜰䛿ᐃᩘኚᩘ`$CONFDIR`䜢ᐃ⩏䛧䚸್䜢`'./conf’`䛻タᐃ䛧䜎䛩䚹䞉䝋䝣䝖䜴䜵䜰䛿`CGI`䝰䝆䝳䞊䝹䛾`new`䝯䝋䝑䝗䜢౑⏝䛧䛶CGI䜸䝤䝆䜵䜽䝖䜢సᡂ䛧䜎䛩䚹䞉䝋䝣䝖䜴䜵䜰䛿CGI䜸䝤䝆䜵䜽䝖䛛䜙䝟䝷䝯䞊䝍`‘id’`䛾್䜢ྲྀᚓ䛧䚸ኚᩘ`$id`䛻๭䜚ᙜ䛶䜎䛩䚹䞉䝟䝷䝯䞊䝍`'id'`䛜ᣦᐃ䛥䜜䛶䛔䛺䛔ሙྜ䚸䝋䝣䝖䜴䜵䜰䛿䝯䝑䝉䞊䝆䛂䝕䝞䜲䝇ID䜢ᣦᐃ䛩䜛ᚲせ䛜䛒䜚䜎䛩䚹䛃䛸ඹ䛻`error`䝃䝤䝹䞊䝏䞁䜢࿧䜃ฟ䛧䜎䛩䚹䞉䝋䝣䝖䜴䜵䜰䛿ᘬᩘ`$id`䜢౑⏝䛧䛶`getSensorBoxInfo`䝃䝤䝹䞊䝏䞁䜢࿧䜃ฟ䛧䚸⤖ᯝ䜢ኚᩘ`$info`䛻๭䜚ᙜ䛶䜎䛩䚹[7][8][9][10](a) 付加情報無し[11]䞉䛣䛾䝋䝣䝖䜴䜵䜰䛿䚸䜴䜵䝤䝃䞊䝡䝇䜢౑⏝䛧䛶䝉䞁䝃䞊䝪䝑䜽䝇䛻㛵䛩䜛᝟ሗ䜢ྲྀᚓ䛧䜎䛩䚹䞉䛣䛾䝋䝣䝖䜴䜵䜰䛻䛿䚸䝃䞊䝡䝇䜶䞁䝗䝫䜲䞁䝖䛾URL䛸ScallopAPI䛾URL䛜䛒䜚䜎䛩䚹䞉䛣䛾䝋䝣䝖䜴䜵䜰䛿䚸䝕䝞䜲䝇ID䛾䝟䝷䝯䞊䝍䜢ᮇᚅ䛧䛶䛔䜎䛩䚹䞉䛣䛾䝋䝣䝖䜴䜵䜰䛿䚸getSensorBoxInfo()㛵ᩘ䜢౑⏝䛧䛶䝉䞁䝃䞊䝪䝑䜽䝇䛾᝟ሗ䜢ྲྀᚓ䛧䜎䛩䚹䛣䛾㛵ᩘ䛿䜶䞁䝗䝫䜲䞁䝖䛻䜴䜵䝤䝃䞊䝡䝇䝁䞊䝹䜢⾜䛔䚸ᛂ⟅䜢JSON䝕䞊䝍䛸䛧䛶㏉䛧䜎䛩䚹䞉䛣䛾䝋䝣䝖䜴䜵䜰䛿䚸getLocationInfo()㛵ᩘ䜢౑⏝䛧䛶఩⨨᝟ሗ䜢ྲྀᚓ䛧䜎䛩䚹䛣䛾㛵ᩘ䛿Scallop API䛻䜴䜵䝤䝃䞊䝡䝇䝁䞊䝹䜢⾜䛔䚸఩⨨᝟ሗ䜢ᩥᏐิ䛸䛧䛶㏉䛧䜎䛩䚹䞉䛣䛾䝋䝣䝖䜴䜵䜰䛿䚸getUserInfo()㛵ᩘ䜢౑⏝䛧䛶䝴䞊䝄䞊᝟ሗ䜢ྲྀᚓ䛧䜎䛩䚹䛣䛾㛵ᩘ䛿Scallop API䛻䜴䜵䝤䝃䞊䝡䝇䝁䞊䝹䜢⾜䛔䚸䝴䞊䝄䞊᝟ሗ䜢ᩥᏐิ䛸䛧䛶㏉䛧䜎䛩䚹

generation,” ACM Comput. Surv., vol.55, no.12, pp.••–••, mar 2023.
https://doi.org/10.1145/3571730“Prompt engineering guide,” https://www.promptingguide.ai/. (Accessed on 10/21/2023).
“Best practices for prompt engineering with openai api,” https://help.openai.com/en/articles/6654000-best-practices-f
or-prompt-engineering-with-openai-api.
(Accessed on10/21/2023).
“Langchain,” https://docs.langchain.com/docs/. (Accessedon 10/21/2023).
S. Sakakibara, S. Saiki, M. Nakamura, and S. Matsumoto, “Implementing autonomous environmental sensing in smart city with IoTbased sensor box and cloud services,” Information Engineering Express (IEE), vol.4, no.1, pp.1–10, March 2018.
S. YAMAMOTO, S. MATSUMOTO, S. SAIKI, and M. NAKAMURA, “Using materialized view as a service of scallop4sc for smartcity application services,” Advances in Intelligent Systems and Computing, vol.271, pp.51–60, March 2014.

(b) 付加情報あり

図 7: getConﬁg.cgi に対する素材抽出結果の一部を下げる可能性があることを確認した．一方で，ソースファイルの内容を補強する情報を付加した場合は適切性を上げることが分かった．将来研究として，プロンプトの指示内容やニーズの具体性が抽出結果に及ぼす影響について検討したいと考えている．
謝辞 本研究の一部は JSPS 科研費 JP19H01138, JP20H05706,

JP20H04014, JP20K11059, JP22H03699, JP19K02973, 若手研究
23K17006 の助成を受けて行われている．
文

献[1] G. Digkas, M. Lungu, A. Chatzigeorgiou, and P. Avgeriou, “Theevolution of technical debt in the apache ecosystem,” Software Architecture, eds. by A. Lopes and R. deLemos, pp.51–66, Springer
International Publishing, Cham, 2017.
[2] T. Nakata, S. Chen, S. Saiki, and M. Nakamura, “Succeed: Sharing upcycling cases with context and evaluation for eﬃcient softwaredevelopment,” Information, vol.14, no.9: 518, pp.••–••, Sept. 2023.
[3] 中田匠哉，陳 思楠，佐伯幸郎，中村匡秀，“ソフトウェアアップサイクルのための事例共有シ ステムの開発と評価，” 電子情報通信学会技術研究報告，第 122 巻，pp.151–156，March 2023．沖縄，名護市産業支援センター．
[4] W.X. Zhao, K. Zhou, J. Li, T. Tang, X. Wang, Y. Hou, Y. Min, B.
Zhang, J. Zhang, Z. Dong, Y. Du, C. Yang, Y. Chen, Z. Chen, J. Jiang,
R. Ren, Y. Li, X. Tang, Z. Liu, P. Liu, J.-Y. Nie, and J.-R. Wen, “A
survey of large language models,” 2023.
[5] N. Nguyen and S. Nadi, “An empirical evaluation of github copilot’s code suggestions,” Proceedings of the 19th International Conference on Mining Software Repositories, p.1–5, MSR ’22, Association for Computing Machinery, New York, NY, USA, 2022.
https://doi.org/10.1145/3524842.3528470[6] Z. Ji, N. Lee, R. Frieske, T. Yu, D. Su, Y. Xu, E. Ishii, Y.J. Bang, A.
Madotto, and P. Fung, “Survey of hallucination in natural language- 68 -—6—