Dockerにおけるコンテナ開発では，コンテナで利用するOSや提供するサービスのバージョンなど，様々な環境や利用形態に対応したコンテナが提供されている．構築するコンテナの要素が異なると，Dockerfile内に記述すべき内容も異なる．多くのコンテナ開発プロジェクトでは，Dockerfileプリプロセッサ（DPP）を各自で開発し，Dockerfileの差異を管理している．各プロジェクトで多種多様なDPPが実装される一方，どのような実装が存在し，どの程度Dockerコンテナの管理に役立つかなど，明らかになっていないことが多い．本研究では，DPPのパターン分類およびDPPファイルアーキテクチャの調査を行う．Docker Hubから60件のコンテナ開発リポジトリを抽出し，目視分類を行った．その結果，既存研究で明らかにされていないDPPパターンを観察した．また，定量的分析を実現するために，DPPの自動検出方法を検討および評価した．評価実験の結果，Dockerfileテンプレート名による抽出が最も精度が高かった．

近年，ソフトウェアの開発規模拡大に伴い，オープンソースソフトウェア（OSS）はますます普及し，様々なイノベーションを支えてきた．一方で，OSSは継続的な開発が保証されているわけではなく，その導入には，脆弱性やバグが放置されるリスクを負うことになる．したがって，OSSの開発がどの程度継続するかを推定することは非常に重要である．そこで本研究では，OSSの採用リスクを低減するために，OSSの開発が継続的に行われるかどうかを推定する上で有用な特徴量を提案する．まず，OSSの生存性について系統的レビューを実施し，次に，生存時間分析を用いたOSSの継続性の評価を行った．系統的レビューにより選別された6件の論文を調査した結果，OSSの生存性に関する論文で用いられる特徴量は，ほとんどがユニークであり，収集した特徴量の中で唯一，コミッターの数が2本の論文で用いられていた．また，本研究で収集した42,593件のOSSに関して，観察開始時点では，およそ58%のOSSが活動をしており，約80ヶ月を経ると，その割合は約20%にまで減少した．さらに，24,803件のOSSを分析した結果，ある時点で活動しているOSSの半数が活動を停止するまでにかかる時間は，およそ48ヶ月であることが分かった．最後に，22,437件のOSSを分析した結果，OSSの開発が継続的に行われるかどうかを推定する上で，OSS開発者のタイムゾーンの数とプロジェクトのトップレベルディレクトリの数が有用であることがわかった．

本稿では，あるソフトウェアを構成するソフトウェア部品に対して各部品の利用先の一致度に基づいて階層的クラスター分析を行う手法について，有効性を確認するための調査を行った結果を紹介する．調査では，本手法を用いて得られた部品群内の部品について，具体的にどのような点が類似点して確認できたか，類似点が共通で利用している部品と関係があるのかなどを紹介し，本手法の有効性や長所，短所（限界）などを考察する．さらに，分類対象のソフトウェアを300クラス程度のソフトウェアに大きくした場合に，具体的にどのような傾向が得られたかを紹介し，大規模なソフトウェアに対して適用した場合にどのような結果が得られそうかについて考察する．

ソフトウェアの進化に応じて変化し続けるソースコードの変更履歴から構文・意味情報を得るための経時解析には通常長い時間がかかる．あらかじめ解析結果をグラフ形式で保管した操作履歴グラフを利用することで，この解析を省略することができる．しかしながら，操作履歴グラフFOHGは，ソースコード行数が長くなると，極端に解析時間が長くなる問題があった．本論文では，FOHGのグラフ生成速度を高めるための実装の改善について述べる．評価実験では，極端に大規模なソースファイルでなければ十分な速度でグラフ構築可能であることを確認した．また，既存ツールとの比較では，1000行のソースファイルを用いた事例で約2000倍の速度でグラフ構築が可能であることを確認した．

近年，プログラミング学習に対するニーズの高まりに伴って，オンラインジャッジシステムのように自主学習に利用できるシステムが注目されている．一般にオンラインジャッジシステムでは，プログラムの正誤を自動判定するために多数のテストケースを必要とするが，多数のテストケースを人手で用意することは決して容易な作業ではない．そのため記号実行を用いた支援が研究されてきているが，その一方で計算コストの高さという課題点も残されている．そこで本論文では，記号実行とともにミューテーション技術を活用することで多様なテストケースを自動生成することを考え，高精度かつ効率的な正誤判定に向けた提案を行っている．そして，Codeforces に投稿された 20,890 個のプログラムを対象とした評価実験を行い，提案手法の有効性を確認している．

プログラミング初学者の支援を目的とした自動プログラム修正の研究が広く行われている.最近では，深層学習モデル を用いた手法の研究が盛んである.深層学習モデルの一種として，OpenAI から text-davinci-003(以下 GPT-3.5) が公開された.GPT-3.5 は，大規模で一般化された言語モデルであり，プログラム生成の一部も実現している.我々 は，GPT-3.5 を用いることで文法エラーを含むプログラムを修正できるのではないかと考えた.GPT-3.5 は，プ ロンプトとして文法エラーを含むプログラムが入力された際，改善された新しいプログラムを出力する.本研究で は，初学者支援ツールへの GPT-3.5 の適用に向けた初期評価として，GPT-3.5 のデバッグに関する性能調査を行 う.九州大学の学生のデータを用いて調査を行った結果，GPT-3.5 は既存の自動プログラム修正ツールよりも 10% 以上高い精度での修正を行うことがわかった.また，GPT-3.5 の修正はコンパイルエラーを含むプログラムを大き く変更するような修正を行なっていないこともわかった.

近年デバッグ作業のコスト削減のために自動バグ修正の研究が行われている．自動バグ修正を行う際にバグの箇所を特定するバグ限局を行う必要があるが，バグ限局は失敗するテストケースが必要となる．そのため，「テストケースの網羅率が低いことが原因でバグ限局が困難なバグ」に対して自動バグ修正を行うことは難しい．そこで，我々は，テストケースを必要としないバグ予測をバグ限局の代わりに用いた自動バグ修正により，この問題の解決を目指す．そのための最初のステップとして，本研究では，失敗するテストケースがないバグを含むデータセットを対象として，Transformerベースのラインに対するバグ予測を行った．本研究のアプローチは，Gitの差分で与えられる変更のかたまり（ハンク）に対してバグ予測を行い，バグと予測された場合，行レベルで予測を行う２段階のステップで構築されている．実験の結果，ハンクレベルの予測では，precisionは低いが，recallが高いモデルを構築できた．行レベルの予測では，Top-5 Accuracyが0.85，IFAの中央値が0と高い精度で予測することができた．

近年，開発者の不具合修正における負担を減らすために，自動プログラム修正（APR）技術に関する研究が盛んにおこなわれている．APR技術によって生成されたパッチの品質は，テストケースに合格することでそのパッチが正しいかどうかを検証しているが，パッチを適用した後のコーディング規約については考慮されていない可能性がある．そこで，本論文では，自動生成されたパッチがコーディング規約違反に与える影響についての分析をおこなう．3つのOSSプロジェクト(Lang, Math, Time)を対象に，APRツールが生成したパッチがコーディング規約違反に与える影響を分析した結果，開発者が作成したパッチはプロジェクト毎のコーディング規約に準拠する傾向があるのに対して，コーディング規約の種類によらずAPRツールが生成したパッチの約4割程度が規約違反を増加させることを明らかにした．また，APRツールが生成したパッチの規約違反は比較的軽微なものであるが，コードの可読性に影響のある規約に違反するものも約9〜10¥%程度含まれることを明らかにした．

ソフトウェア開発において，プロジェクトの計画立案，管理支援を目的として機械学習を用いた開発工数の見積もりが行われている．見積もりに用いられるプロジェクトデータにはしばしば見積もりに悪影響をもたらす値が含まれている．このような値が含まれるデータを用いた場合，高精度での工数の見積もりを期待することは難しい．しかし，このような値を含むプロジェクトを除外すると，今度はデータセット自体のサイズが小さくなり，やはり高精度での見積もりに支障をもたらす可能性がある．そこで本研究では欠損値補完手法を利用することで，データセットのサイズを維持したままでの質の向上を目指す．具体的には，データセットに人為的に欠損を作成し，その欠損に補完手法を適用することで補完値を得る．補完値と実測値を比較し，その乖離が大きい場合にはその値が見積もりに悪影響をもたらす値であると見なし，その値を補完値で置換することで，データセットのサイズを維持したまま，品質を向上させる手法を提案する．実験の結果，提案手法の適用によって見積もり精度が向上することが確認された．

本稿の目的は，企業横断的に収集されたソフトウェア保守のデータを分析し，保守の作業効率に影響する要因を明らかにすることである．分析では，企業横断的に収集されたデータを用いて，是正保守などの保守種別と，テストなどの各工程の比率に着目し，Web系システムなどのシステム構成の種別で層別しつつ，それらが作業効率にどの程度影響しているかを明らかした．

本稿では，JavaScriptにおけるclass構文がどの程度普及しているかを調査するために，近年にGitHub上に登録された小規模なJavaScriptプロジェクトを対象とした分析を行う．JavaScriptは元来，プロトタイプベースオブジェクト指向言語であるが，2015年より糖衣構文としてのclassが導入され，クラスベース風の書き方が可能となっている．調査の結果，class定義を行っているプロジェクトは25%あり，class構文がある程度普及していることが分かった．また，プログラム中で定義したclass以外のオブジェクト(関数，オブジェクトリテラル）のインスタンス生成を行っているプロジェクトは14.3%と少なく，プロトタイプベースよりもむしろクラスベースの記述の方が普及していることが示唆される．これらの結果より，今後，classをより使いやすくする言語仕様の拡張や，ライブラリをクラスとして提供することが望まれると考える．

自動プログラム修正において，テスト等の結果に基づいてバグの原因箇所を特定する``バグ限局'' は重要な役割を担っている．有用なバグ限局手法として，テストの実行トレース，即ちプログラムスペクトルを用いて各コード行におけるバグ潜在の疑惑値を算出する手法が知られているが，条件分岐のブロックが長くなるとブロック内のコード行の間で疑惑値の差別化を図れないという問題が知られている．そこで本論文では ``疑わしいコード行を適切に絞り込めているか'' を疑惑値の分布に基づいて予測し，十分に絞り込めていない場合にはコード行の新しさでもって疑惑値の重み付けを行うという手法を提案している．そして，Defects4J データセットの一部を用いた評価実験を通じて，提案手法の有効性を示している．

マイクロサービスアーキテクチャ(MSA) は複数のマイクロサービスを組み合わせてシステムを構築するアーキテクチャである．MSA を採用するシステムではサービス間の呼び出し関係が複雑となりやすく，サービス間が正しく連動して動作するかを検証するサービス連動テストを網羅的に行うことが難しい．本研究では，各サービスの API を検証するサービス単体テストにおける各サービスに対する入出力を基として，サービス連動テストのテスト網羅度測定を通じたテスト漏れ候補の検出方法を提案する．実際のシステムに適用し，ツールが検出したテスト漏れ候補の中から，システムの不具合を発生させうるサービス連動テストのテスト漏れが発見できたことを示す．

産業界におけるモデル検査の利活用を促進するため，これまでに我々はビジュアルプログラミングを利用したモデル生成支援環境の開発を行ってきた．この環境では，ノードグラフ形式のビジュアルプログラミング環境である Node-RED を拡張することで，モデル検査ツール nuXmv の入力モデルを自動的に生成できる．本論文では，モデル検査の初学者を対象とした比較実験を通して，開発した支援環境の有用性の評価を行い，その結果をもとにモデル作成を効率化するための機能拡張について検討する．

複数の開発者が参画するソフトウェア開発では．開発者は可読性，保守性の向上のために静的解析ツールを用いてコーディング規約に違反しているソースコードを検出し，修正に取り組む．しかし，静的解析ツールは規約違反の指摘漏れを抑えるため，大量の規約違反を出力し，その大半が開発者に修正されていない．従来研究では，規約違反を検証するプロジェクトの過去の修正履歴を学習したモデルを構築し，静的解析ツールの検出結果の中で優先的に修正すべき規約違反ソースコードを予測する手法を提案している．本研究では，従来研究において単一プロジェクトの学習によって十分に学習できない規約違反を，複数プロジェクトのデータによって学習する予測モデルを構築し，当該モデルが多様な規約違反を予測可能か否かを明らかにする．10件のOSSプロジェクトを対象に実験を行った結果，学習データサイズの小さいプロジェクトに対して本手法が有効であることを確認した．

近年，IT需要の拡大に伴って，開発効率向上のため，開発支援ツールを活用して開発が行われている． その中の一つとして，2022年にGitHubが公開したGitHub Copilotがある． GitHub Copilotは大規模言語モデルをベースとしたコード推薦ツールの一種であり， 仕様を記述したコメントや，記述中のプログラムをもとに開発者に対してコードやライブラリを推薦する． 一方，大規模な事前学習済み言語モデルは，入力によって出力が大きく異なることが知られている． そこで，本稿では，言語間の学習データ量の違いに着目し，入力言語の違いがCopilotの性能にどのような影響を与えるのか調査を行った． 調査の結果，入力言語の違いによってGitHub Copilotの性能に差が生じることが明らかになった． また，調査結果によって明らかとなった大規模言語モデルに対する問題点を示す．

同一の変数に対して数値と大小比較を行う連続した条件分岐に対して，必要のない条件記述，閾値や比較演算子の誤りの可能性を指摘するコーディングチェッカを提案する．ifの条件において変数の取りうる値の範囲を区間として表現し，真にならない区間やelseで暗黙に決まる区間を求める．コーディングチェッカを試作し，適切な条件分岐ではないソースコードを判定して，誤りの可能性の指摘や修正を促すフィードバックが得られることを確認した．

本稿では，システム構築のための顧客からの要求獲得について，生成系AIによる自動化もしくは非専門家の補助が可能となるかを調べるため，ChatGPTをSE役として顧客に対して質問させることで要求獲得を行わせる実験を行った．実験で題材としたシステムの全要求244件のうち，7件を初期要求としてChatGPTに与えて実験を行った結果，新たに獲得できた要求は平均35.7個であり，これは獲得可能な要求237件の15.1%に該当する．今後，初期要求としてより多くの情報をChatGPTに与えた上で質問させるといったプロトコルの改良が必要であると考えられる．

既存のサービスに別のサービスを追加する場合，サービス追加のニーズを持つ利害関係者に着目して要求獲得を行うと，他の利害関係者への影響について考慮が漏れる可能性がある．そこで，このような漏れが生じないように，要求分析手法CATWOE分析と安全分析手法STAMP/STPAを利用して，要求を獲得する方法を考案した．考案した方法を過去の事故事例に適用するケーススタディを行い，効果を確認した結果を示す．

コンテキストに応じて協調するマイクロサービス群としてIoTアプリケーションを構成する方法が一般的となってきている．このような背景のもと，IoTアプリケーションの設計に際して，コンテキスト指向，サービス指向，マイクロサービス群のマッシュアップを考慮したソフトウェアアーキテクチャの必要性が指摘されている．本研究の目的は，コンテキスト指向で設計されたIoTアプリケーションをサービス化し，並行処理記述を用いてサービス連携を実現するための枠組みを整理することである．すなわち，IoTアプリケーションのためのアーキテクチャを定義し，マイクロサービス連携のための記述方式について検討する．

In this research, a method is proposed to enhance the quality of source code comment generation． This method involves the extraction of terms from documents using ChatGPT, incorporating these extracted terms into the prompt, and subsequently generating source code comments with ChatGPT．

ChatGPT has the ability to generate comments from source code. However, to use ChatGPT correctly and generate appropriate comments requires the high model manipulation skill. We’ve proposed a method to enable to generate such comments using ChatGPT based on intentional source code extraction especially by the person who has the low model manipulation skill. As a result, we come to conclusion that source code extraction is effective.

本論文では Python ソフトウェアの開発・保守の過程において，テストコードの変更が複数のコミットにまたがって連続して起こることも珍しくないことに着目し，テストファイルの連続コミットとそれに伴うテストスメル数の変化について分析した結果を報告する．

変数名は単なる識別子というだけでなく，処理内容を適切に表現していることが望ましい．一般に変数名と処理内容の整合性評価にはコードレビューが必要であり，その過程で不適切な名前は変更される．しかし，変数名に絶対的な正解はなく，その評価を客観的かつ機械的に実施することは容易でない．本論文では変数名の評価にばらつきが生じやすいキャメルケースの変数に注目し，名前の適切さ判定の自動化に向けた判定基準について考察する．

本研究では，ソフトウェア変更時のコミットにおける変更差分コード片を利用することで，類似コードを検出するツールを検討した．類似コード検出手法にはいろいろな手法が提案されている．そこで類似コード検出手法を利用する際の呼び出し方法に合わせて，ソフトウェア変更時に類似コードを検出できるような方式として検討を行った．

プログラムの実行時にエラーが発生した際に，エラーメッセージに含む例外情報が障害原因を指し示さない場合がある．本研究ではPython を対象に，そのような場合に原因となる可能性のある箇所を特定する手法を提案する．特定の方法はエラーの種類により異なるので，提案手法では例外の種類ごとにあらかじめ特定方法をルール化する．

プログラムコードとコメントが整合していない場合，開発者のソースコード理解を妨げる．本研究では大規模言語モデルを用いてコメントから生成したプログラムコードと元のコードとの同一性を判断した結果を提示することによって，開発者がプログラムコードとコメントの整合性を確認することを支援する手法を提案する．

To reduce enterprise web applications development cost,we proposed the screen coding support method based on screen event relationship information similarity, and developed a tool based on the method. Applying the tool to the source codes of a web application based on an existing system, the tool is able to output the correct answer as a selection candidatein 83.3\% of the cases.

REST APIに対するテストケース自動生成にペアワイズ法を用いる手法が発表さているが，API仕様に配列が含まれる場合にペアワイズを生成できないという課題がある．本論文ではペアワイズ法を配列に対応させる拡張を提案し評価した結果，テストケース数の爆発的増加を抑えたテスト自動生成を実現した．

社会問題であるデジタルディバイドを解決する為, 新しい IT リテラシー教育カリキュラムモデルを提案する. はじめに本モデルの基本となる「ヒューマンリテラシーモデル」を作成した. これはアプリケーション層, メソッド層, コンセプト層の 3 層から構成される. 各層はそれぞれ操作, 習得, 一般化という特定のスキルによって特徴づけられる.我々の提案するリテラシー教育モデルは, この 3 層のヒューマンリテラシーモデルを基礎として構築されている. 魅力的な教育ツールとして市販のビデオゲームを活用し, 教材の自動生成に ChatGPT を活用している.

オープンソースソフトウェア（OSS）の開発が活発化しているものの，開発が停滞するOSSも多く存在する．しかし，利用してるOSSの開発が停滞したときに，代替のOSSを探すことは容易ではない．そこで，GitHubなどのプラットフォームで，あるプロジェクトのコピーを作成する機能であるフォークに着目し，フォークプロジェクトの中から活発なプロジェクトを探索するツールを提案する．コミット活動を元に活発度を判断し，候補を列挙する．

ソフトウェア開発に携わる者たちにとって，コードリーディングは欠かせない作業である.一方で学習者からは， コードリーディングは成果に直結せず，また，題材を見つけることも困難であるため，敬遠されがちである.そこ で，本論文では，コードリーディングを習慣化するための Web アプリケーション CodeLeader を提案する.ゲーミ フィケーションをはじめとした習慣化の仕組みを導入する.

ビジュアルプログラミング言語Scratchでは，ユーザが制作した作品をオンライン上に公開することができ，また公開された作品を検索することで，実装の参考にすることができる．Scratch上で使用できるブロックは限られるため，検索によって類似するプログラムを含む作品やオブジェクトの描く動作軌跡が類似する作品が多数出力される．一方で，プログラムは類似していてもオブジェクト動作が異なることもある．このようなプログラムの類似性とオブジェクト動作の類似性の乖離は，多様な実装方法を有する作品収集に有効であることもあるが，検索において期待しない作品が収集されることもある．本研究では,ケーススタディとして4,000件のScratch作品を対象に類似性の乖離する作品を分析した結果，プログラムが類似してオブジェクト動作軌跡が類似しない作品は全体の約1%，オブジェクト動作軌跡が類似してプログラムが類似しない作品は全体の約28%存在することを確認し，多様な実装方法を有する作品収集に有効であることが多いことを明らかにした．

一部の学習者にとって自力でソースコードを完成させることは困難であり，学習者ごとに適した支援が求められる．本研究では，学習者が自身でコードを考えて完成させる能力を養うために，編集中のソースコードに合わせた自動フィードバック方法を提案する．模範解答を構成する文の組み合わせを模範解答の状態として，それらが模範解答に至るまでを編集遷移グラフとして作成する．編集遷移グラフを用いて，コードの追加や編集の確認のためのフィードバックを提示する．

近年，高齢者の認知機能の維持向上を目的として，コンピュータゲームの利用が注目されている．本稿では，高齢者がどのようなゲームであれば興味を持って取り組むことができるのかについて4名の高齢者を対象に行った実験の結果について報告する．

本稿では，テストケース作成作業におけるChatGPT利用の効果を実験的に評価した結果について報告する．28名による被験者実験の結果, ChatGPTを用いることで，1)作成されたテストケースの数が増加した，2)C0カバレッジが上昇した，3)ChatGPTによるテストケースが誤っている割合は大きい，4)人力で作成されたテストケースが誤っている割合が低下した，などが分かった．

本稿では，大規模言語モデルBERTに基づくテキスト分類技術を用いて，バグの説明文を入力として，セキュリティバグとそれ以外のバグの判別を試みた．4つのオープンソースプロジェクトを対象とした判別実験の結果，適合率が42.9%，再現率が30.0%，F1スコアが35.3%となった．実験で用いたissue群に含まれるセキュリティバグの割合が3.98%であり，F1スコアの期待値が3.98%であることを考慮すると，高い精度が得られていると考える．

近年、脱出ゲームの教育での利用が注目されており、プログラミング教育における実践報告などが行われている．本研究では、SQLプログラミング学習への脱出ゲームの利用について，具体的な事例を検討することでその方法や問題点について考察する．提案する脱出ゲームでは，数段階に分けた各ステージで「謎」となっている目的の数値をSQLプログラミングを利用することで解決・抽出し，次のステージに進むという形式にする．抽出した番号を組み合わせることで、次のステージに進むためのパスコードを得ることができるという仕組みである．

ソフトウェアにおける障害対策として定期的にログレビューを行うことが望ましいとされる．しかしシステムが出力するログは膨大な量であるためログレビューには時間を要する．そこで，ログレビューの支援を目的としたログ分析ツールを開発した．開発したツールを４つのシステムに適用した結果，３つのシステムから障害のログを検出することができ，ログレビューを支援できる可能性を示唆することができた．

ライブラリ更新には後方互換性の損失を伴うことがあるが，ライブラリの利用者が後方互換性を正確に判断することは困難である．従来研究では，ライブラリの動作を検証するテストの変更有無に基づき後方互換性の損失を検出する手法が提案されているが，誤検出が多い．本研究では，テストの変更内容を考慮する後方互換性の損失の検出手法を提案し，その精度を検証した．

複数の開発者が参画するソフトウェア開発では．静的解析ツールを用いてコーディング規約に違反しているソースコードを検出し，修正に取り組む．しかし，静的解析ツールは大量の規約違反を出力し，その大半が開発者に修正されていない．本研究では，複数プロジェクトの開発履歴を用いて，複数プロジェクトにおける規約違反したソースコードの特徴に基づきクラスタリングすることによって規約違反を修正する特徴が類似するモデルを構築し，予測精度を分析する．ケーススタディとして，Python言語で記述されたオープンソースソフトウェア10プロジェクトを対象に予測モデルを構築し予測性能を評価した．

群ロボットを協調動作させるためのソフトウェアアーキテクチャを提案する．様々なサービスからなる複雑なロボットシステムは，個々のロボットに比較的単純なサービスを実装し，それらを組み合わせた群ロボットとして実現することができる．本稿では，提案するアーキテクチャを警備群ロボットシステムに適用することで，個々のロボットの開発が単 純になり，効率的に複雑なロボットシステムを開発できることを示す．

近年ではオープンソースソフトウェアを利用したシステム開発やサービスが数多く存在する．一方で，オープンソースソフトウェアは無償で開発されていることから，メンテナンスが継続的に行われない可能性がある．そこで，本論文ではGitHubのリポジトリヒストリを学習し，開発の継続性を予測する手法を提案する．提案手法を用いて実際のリポジトリに適用した結果，予測できることを示唆することができた．

バンディットアルゴリズム(BA)によりソフトウェア欠陥予測モデルを選択する方法が提案されている．通常のBAでは1つのアームの結果しか得られないため，アームの候補が増えると，最適な候補を選ぶまでの試行回数が増加する．これに対しBAによる欠陥予測モデルの選択では，テスト結果とそれぞれのモデルの予測結果の一致・不一致を比較するため， モデルの候補が増加しても，必ずしも試行回数が増加する（BAによる予測精度が低下する）とは限らない．ただし候補数が多い場合，BAによる予測精度が低下する可能性もある．そこで本研究では，BAによるモデル選択において，欠陥予測モデルの候補数が多い場合に，予測精度への影響を抑える方法について検討する．

異なるモデル検査ツール間では検証可能な観点（確率や時間など）や性質（線形時相論理や計算木論理など）が異なるため，複数の検査ツールを併用したい場合がある．しかし，検査モデルの記述言語はツール間で異なるために併用の敷居は高く，異なる複数の検査モデルを一つの記述から得る方法も確立されていない．そこで本研究では，異なる複数の検査モデルが得られる，一つの一貫したステートマシン図記法および変換方法を検討する．本稿では，その検討結果を報告する．

我々は過去に，ソフトウェアを柔軟に設計するメカニズムとして，アスペクト指向モデリングメカニズムの提案を行った．このメカニズムでは，関心事をアスペクトとしてモジュール化し，アスペクト間の関係をアスペクト関連ルールとして定義することで，ソフトウェアの柔軟な構成を可能にした．我々は，IoTのように様々な機器と接続するシステムの設計に本モデリングを適用することを検討しているが，その際にはアスペクト間でのデータのやり取りを表現できることが必要になる．しかし，現状のメカニズムでは，アスペクト間のデータのやり取りをルールによって表現する事は難しい．そこで本稿では，アスペクト関連ルールに対して拡張を行うことで，データのやり取りを表現する方法を提案する．