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

信学技報
IEICE Technical Report

Java への所有権システム移植による Rust 学習支援竹重拓輝†

柗本 真佑†

楠本 真二†† 大阪大学大学院情報科学研究科
E-mail: †{h-takesg,shinsuke,kusumoto}@ist.osaka-u.ac.jp
あらまし

メモリ安全かつ処理が高速なソフトウェアを実現するプログラミング言語として Rust が注目されている．Rust はコンパイラがメモリの参照を検査し安全性を保証し，また適切なタイミングでメモリ解放処理を挿入しメモリ使用を効率化している．これら安全性と高効率性は言語設計に所有権という概念を取り入れ実現されており，所有権の理解は Rust の特長を利用する上で重要である．一方で所有権は多くのプログラミング言語には存在せず，Rust 学習者にとってその習得を妨げる大きな要因となっている．本研究では他言語既習者の Rust 学習支援を目的とし，他言語に所有権概念を移植し所有権概念の学習環境を提供する．所有権概念の学習を Rust の文法や開発環境の学習と切り離し，既習言語で習得できるようにし，学習効率の向上を目指す．
キーワード

1.

Rust，学習支援，機能移植，所有権，ライフタイム

はじめに対して所有権を考慮したプログラミングが必要な環境を提供
し，所有権に対する理解を深めさせる．この環境では，Java で近年高パフォーマンスかつ高信頼性を実現するプログラミは問題ないコードに対しても Rust における所有権に関連する

ング言語として Rust が注目されている．Rust はコンパイラがエラーと同様のエラーが発生する．このエラー修正を通じてプログラム内のメモリ操作の安全性を保証するという特徴を所有権に対する理解を深めさせる．また，そのエラーメッセー

持つ．この特徴によりガベージコレクションを不要とし，高ジでは提案環境で得られた知見を Rust で活かしやすいよう，

速な処理を実現している．パフォーマンスを犠牲にせずとも

Rust のエラーと対応づけ，Java から Rust への知識の転用を促

安全なソフトウェアを開発できる点が評価され，発表から 10進する。

年程度という比較的新しい言語ながら大規模プロジェクトで移植による再現度を確かめるため，Java のコードに対するも採用されつつあり，Linux カーネルの開発においても C 言語

適用実験を実施した．その結果 8 件中 3 件で再現ができておに加え第 2 の言語として導入されている1．

り，残りのコードに対しても実装の進展により対応可能だと一方で Rust 普及を妨げる要因として，言語習得の難しさが挙げられている [1]．コンパイラによる厳格な検査によりメモリ操作の安全性を保証しており，その検査において重要となる

考える．

2.

準

備

所有権とライフタイムという要素の理解習得が難しいとされコンパイラがメモリ操作の安全性を検証するため，Rust でている [2]．このため，パフォーマンスや信頼性の高さといっは所有権という概念が採用されている．ソースコード中で操た利点があるにもかかわらず，開発言語として採用されにく作する各データに対して所有権を持つただ一つの変数をそれいと考えられる．

ぞれ設定し，この変数またはこの変数から貸し出された参照

本研究の目的は Rust の言語移行における学習支援である．

を通じてのみデータへのアクセスを許可する．このアクセス

既になんらかの言語を習得している開発者が効率的に Rust に制限により，解放後メモリの参照やデータ競合を防いでいる．

移行できるようにする．本研究では文法と所有権の学習の分

所有権を持つ変数は，他の変数に対し所有権を譲渡できる．

離により Rust の学習を支援する．新たにプログラミング言語

このとき，所有権を渡した変数はその時点で無効となり，以降を習得するには，まずその言語の文法を理解する必要がある

データにはアクセスできなくなる．所有権を受け取った変数

が，Rust の場合はさらに所有権といった独自の概念も学ぶ必が以降の処理においてデータと紐づけられる．

要がある．これらを同時に学ぶことは容易ではないため，既所有権を持つ変数から貸し出される参照には存在条件が設に文法を習得している言語を利用して所有権の概念を学習で定されている．参照には可変参照と不変参照の 2 種類が存在

きるようにする．それぞれの要素を個別に学ぶことで、学習する．可変参照は参照先のデータの書き換えが可能な参照，不の複雑さを低減し，より効率的な言語移行を可能とする．

変参照は不可能な読み取り専用の参照である．1 つのデータに

この実現のため，所有権を Java に移植する．Java 既習者に対し可変参照は高々 1 つまで，可変参照と不変参照は同時存在禁止といった制限がある．この制限により，不意なデータ（注 1）：https://www.kernel.org/doc/html/next/rust/index.htmlの書き換えを防いでいる．

This article is a technical report without peer review, and its polished and/or extended version may be published eleswhere.
Copyright ©2024 by IEICE

1

fn validateId (id: String ) {1

2/* some process */

2

3

}

4

fn registerUser (id: String ) {56/* some process */

7
8

}

4

void registerUser ( @Owner String id) {5/* some process */}7
fn main () {let userId = String :: from(" ist2024 ");

9
10

8

void main () {9

@Owner String userId = " ist2024 ";10

11validateId ( userId );11

12

registerUser ( userId ); // error!

12

13/* some process */

3

6

}

void validateId ( @Owner String id) {13}

error[E0382]: use of moved value: `userId`

図 1 エラーを含む Rust のコード例

validateId ( userId );registerUser ( userId ); // error !
}error[E0382]: use of moved value
Since the variable has lost ownership, the memory area
referenced by the variable may have already been freed.

図 2 エラーを含む Rust のコードを Java で再現した例

また，ガベージコレクションを用いずに安全なメモリ操作を実現するためライフタイムという概念を採用している．Rust
において所有権を持つ変数や参照を格納する変数にはそれぞれライフタイムが設定される．このライフタイムは多くの場は高いと言える．

3.

提案手法

3. 1

概

合変数のスコープに対応する．ライフタイムによって参照の貸し出しは制限されており，所有権を持つ変数より長く生きる
変数には参照を貸し出せない．ライフタイムが終了した，すなわち変数のスコープが終了すると，所有権を持つ変数ならその変数のデータを格納していたメモリ領域が解放され，参照を格納する変数であればその参照が消滅し，参照の存在条
件の判定から除外される．参照の貸し出し制限により解放後メモリに対する参照を経由したアクセスを防げ，また，ライフタイムを用いたメモリ解放タイミングの管理により不要となったメモリを即時解放できる．
例えば 図 1 のコードでは所有権を失った変数の再利用としてエラーが起こる．このコードでは 9 行目で変数 userId を宣言している．"ist2024"という文字列データの所有権は userIdが持つ．11 行目で userId は関数 validateId() の呼び出しに使用される．このとき，validateId() はその引数 id に所有権を要求する．よって 11 行目の実行時に userId が持っていた所有権は関数 validateId() の id に譲渡される．その後，
12 行目で関数 registerUser() の呼び出しに userId を使用す
ると，所有権を失った変数の使用としてエラーが発生する．この制限により，所有権を失いライフタイムがメモリの解放と紐づかなくなった変数を通したメモリアクセスを禁止し，不正なメモリ領域へのアクセスを防いでいる．
Rust は高いパフォーマンスと安全性を実現する一方で，開発言語として採用する際の問題点として急な学習曲線が挙げられている [1]．その大きな原因として所有権とライフタイム
が挙げられている [2]．所有権は他のメジャーな言語では導入されておらず，多くの開発者にとって馴染みのない概念である．よって Rust 習得には通常の言語習得プロセスと並行して所有権概念の習得が必要であり，他の言語と比べて習得難度

要提案手法では Java 経験者を対象として Rust 言語の習得を支援する．一般に既に何らかの言語を習得しているプログラミ
ング経験者は，新たな言語の学習において既習概念を基にした類推によって効率的に言語を学習する．例えば言語によらない共通の概念として繰り返しのような構造や，パターンマッ
チングなどがある．これらの概念について既に習得済みの開発者は学習中の言語のにおいてそれら概念がどのように記述されるかのみに集中して学べる．
Rust 学習者に既習言語が存在する場合，先にその言語で所有権概念のみ習得できれば，通常の言語移行と同様に，既習概念を基にした類推によって学習を促進できる．よって所有権
概念の他言語への移植により，当該言語既習者が所有権概念のみを習得できる環境を作成する．
提案手法を導入した Java コードを 図 2 に示す．このコードは 図 1 の Rust コードを Java で再現したコードである．Annotation によって変数の役割を示しており，@Owner は所有権を持つ変数である．このコードをコンパイルすると，13 行目において所有権を失った変数を使用しているとしてエラーが発生する．
エラーは 15,16 行目の内容である．15 行目では Rust と同様のエラーメッセージを表示し，Rust のエラーと対応づけている．16 行目ではエラー内容の説明として，なぜそれが禁止されているのか説明している．このコードにおいては，userIdが所有権を失っているため，参照先のメモリが解放されている可能性がある旨を説明している．
上記エラーから，開発者は所有権を考慮したコード作成方法を学ぶ．エラー発生箇所の確認により，所有権により制限さ—2—

れる操作や，その操作がソースコード上のどこで起こりやす

類似した処理と考えられる．よって，型検査の拡張により所

いのか理解を深められる．また，エラーに付与される説明か

有権による操作制限を再現する．

ら所有権による操作制限の意図を理解し，より容易にエラー解消するようソースコードを修正できる．
このコードの場合，まずメソッド呼び出しに対してエラー型検査の拡張にあたり，ソースコード中の変数に対し開発者に標準の型に加えて追加の型の宣言を求める．追加の型は 3 種
類あり，所有権を持つ変数 Owner，可変参照である MutBorrow，が発生していることからメソッド呼び出しでは所有権を意

不変参照である Borrow である．開発者は変数に対していずれ識しなければならないことがわかる．また，エラーの原因がかの型を追加で宣言する．宣言がない変数がソースコード中

所有権を失った変数の再利用であることから所有権を保持すで使用された場合は警告を発生させる．エラーではなく警告るように書き換える必要があることがわかる．以上の理解かとした理由は，所有権を考慮した型検査の適用範囲を段階的にら，このメソッド呼び出し時点において所有権を保持するた広げていくような導入を可能とするためである．これにより，めに，所有権の譲渡が発生する箇所を探す．このコードでは

開発者はソースコードの一部分のみを対象として学習を始め

12 行目 validateId() の呼び出しが該当する．よって，このられ，その理解に応じて対象とする範囲を広げられる．最終

validateId() が引数の所有権を奪わないよう，引数の型宣言

的には警告も発生させないよう，ソースコード全体の変数にを@Borrow に変更する．この修正によりエラーは解消される．

対し追加の型を宣言し，かつ所有権に係るエラーも発生させ

この経験から開発者はメソッド呼び出しにおける所有権操作ないことを目指す．

の注意点や引数宣言の重要性を学べる．この知見は Rust の学
習においても活用でき，その習得を効率化できる．
提案手法は 3 つの要素から構成される．所有権の再現にあたり簡易化し定義された操作制限，所有権に係る操作の Java内での記述方法，所有権を再現する検査である．以降ではこ追加の型が宣言された変数同士の代入処理において，ムーブや借用を表現する．例えば Owner 同士の代入であればムーブと解釈し，Borrow に対して Owner を代入する場合，不変参照の借用とする．
また，メソッド呼び出しにおいても実引数が仮引数に代入されらの要素について説明する．

れていると捉えムーブや借用を処理する．仮引数に対する追所有権による操作制限

加の型はメソッド宣言時の仮引数の型宣言と併せて記述する．

3. 2

Rust 所有権の再現にあたり，まず Rust において所有権によっ

3. 4

検

査

て制限される操作を整理する．所有権はソースコード中での検査においては 3 つのテーブルを使用する．各変数のライ操作に制限を加え，メモリ安全性を高める機構である．開発

フタイムを記録するテーブル，データ毎の参照の存在状況を者がこの制限を誤って理解していたとき，コンパイラエラー

記録するテーブル，開発者以外が作成したメソッドに対するが多発し Rust の習得を妨げる．よってこの制限を再現する．

追加の型宣言テーブルである．

ただし，厳密に Rust コンパイラによる検査と同等の処理を変数が宣言された際，その変数のスコープをその変数のラ実装するには多大な開発コストが必要である．よって，制限

イフタイムとしてテーブルに記録する．Rust のライフタイムを実現する簡易的な制限を定義し Java に実装する．

は厳密には変数のスコープと一致しない場合があるが，実装

Rust において所有権によって次のような制約が存在する．
• 参照の存在条件の簡易化のためスコープで代用する．
参照の存在状況を管理するテーブルは検査を進めながら構•

ライフタイム制約

成する．参照の作成時点で参照先のデータと参照を格納する•

不変参照から破壊的メソッドの呼び出しの禁止

変数を記録する．テーブルでは各データについて参照を持た•所有権を持たず参照でもない変数の使用禁止

ない，不変参照を持つ，または可変参照を持つという状態のい参照の存在条件とライフタイム制約は 2. 章で説明したとおずれであるか記録する．また，参照を格納する変数のライフりである．不変参照から破壊的メソッド呼び出しの禁止は不タイムが終了していればその参照を削除できるようにする．

変参照のアクセス権限による制約である．不変参照は参照先

追加の型宣言テーブルは著者らが事前に作成する．メソッの変数に対して変更を加える権限を持たない．よって変数にドの引数がいずれの追加の型を要求するかはメソッド宣言時

付帯する破壊的メソッドへの不変参照を経由したアクセスはに記述する．よって，標準ライブラリなどの開発者以外が作成禁止される．また，Rust において所有権を持たず参照でもな

したメソッドには追加の型は付与されていない．これらのメ

い変数の使用は禁止されている．変数が持つ所有権は他の変ソッドに対しても所有権を意識した操作を強制するため，追数への譲渡が可能である．この処理を Rust においてはムーブ

加の型を著者らが事前に定義する．定義にあたってはそのメと呼ぶ．ムーブによって所有権を失った変数は以降の処理にソッドの処理内容を鑑み，適切であると著者らが考える型を付おいて使用が禁止される．

与する．例えば，引数として受け取った変数を書き換える破3. 3

所有権操作の記述方法

所有権によってソースコード中の操作が制限される箇所は

壊的メソッドに対しては，書き換えられる引数に MutBorrowを付与する．

参照の作成や，メソッド呼び出しによる引数の受け渡しであ提案手法によって検査が必要な箇所は変数の使用箇所である．提案手法では参照の作成を代入文で行うこととする．こる．使用とはデータへのアクセスまたは所有権の移動，参照ののとき，所有権による制限は型検査による変数の使用制限と作成処理を指す．よってこれらの操作が行われる代入文，お—3—

よびメソッドの呼び出し文を検査対象とする．
代入文では右辺から左辺へ所有権のムーブまたは参照の貸

1// Returns the n-th largest element in a slice

2

fn find_nth <T: Ord + Clone >( elems : &[T], n:

し出しを行う．メソッドの呼び出し文ではインスタンスと各

usize ) -> T {引数について，実引数から仮引数への代入と見て，それぞれ代

3

elems .sort ();入と同様に処理する．

4

let t = & elems [n];処理内容は制約違反の検出とテーブルの更新である．制約5

違反の検出には前述の各テーブルを使用する．例えば，所有権6// error!

return t. clone ();}を失った変数を使用した場合，各変数の役割を記録するテー
ブルの情報からこれを検出する．また，ムーブや参照の貸し

error[E0596]: cannot borrow `*elems` as mutable,
as it is behind a `&` reference

出しに応じて参照の存在状況テーブルを更新する．
また，ムーブにより所有権を失った変数は追加の型 Unusable

図 3 Ownership Inventory の ﬁnd_nth

で表現する．Owner 同士の代入によってムーブが発生したとき，代入元の変数の型 Owner を削除し，Unusable に付け替え

4. 1

る．以降，Unusable が付与された変数が使用された場合，エ対象とするソースコードは Crichton らが作成した Ownership

題材

ラーを発生させる．

Inventory [3] を元に作成する．Ownership Inventory は所有権を実学ぶ際に発生しやすい誤解を明らかにするために作成された

3. 5

装

本研究では移植対象の言語として Java を用いる．Java を対Rust のソースコード集である．各ソースコードは所有権に対象とする理由は 3 つある．広く利用されている言語であるた

する誤解を原因としたエラーを含んでおり，このエラーに対

め，Rust が得意とするシステム開発で使用されており移行ユー

する対処を開発者に問うことで開発者の理解度を測るためにザーが見込めるため，メモリ管理機構が大幅に異なるためで使用された．

ある．

例えば，Ownership Inventory に含まれる 図 3 のコードは 3 行

特にメモリ管理については Rust と Java は大きく異なると考目においてエラーが発生する．仮引数の elems は配列の不変

える．Java はメモリ管理の手法としてガベージコレクション

参照として受け取られる．3 行目では elems から sort() を呼を採用している．よって，Java 開発者は基本的にメモリの確び出している．このとき，sort() は呼び出し元のインスタン

保や解放を意識的には操作していない．このためメモリ管理

スについて可変参照を要求する．これは sort() はその実行にに対する考え方が Rust 開発者とは大幅に異なり，Rust の習得

おいて元のインスタンスに対して変更を加える破壊的メソッ

にあたり所有権によるメモリ管理に躓きやすいと考えられる．

ドであるためである．よって不変参照からは sort() は実行で故に，提案手法による所有権学習のメリットが大きいと考えきないためエラーが発生する．

られる．

本研究では Ownership Inventory を所有権に起因する代表的Java ソースコード中において所有権操作の記述には Annota-

な Rust のコンパイラエラーと捉え，そのエラーをどれだけ再tion を使う．Annotation はソースコード中に記述できる，Java

現できるか検証する．Ownership Inventory は所有権に対する誤コンパイラに対する追加処理の指示である．Java 標準機能で解を基に設計されている．よってそのコードとエラーを Javaあり，例えば @Override はメソッドのオーバーライドを必須上で再現できれば，Java 上でも所有権について理解を深めらとする指示として広く使用されている．

れると考える．

Annotation を使う理由は Java 標準機能であるためである．提

4. 2

適

用

案手法において独自の記法を導入すると，開発者は所有権概

Ownership Inventory のコードを対象として，提案手法が Java

念を学ぶためにその記法を習得しなければならない．これは上でエラーを再現できるか検証した．その結果，8 件のソース

記法の習得と所有権の習得を分離し，所有権のみを学ばせる

コードのうち，3 件でエラーを再現できた． 表 1 にソースコーという目的を達成できない．よって標準機能であり，一般のドの特徴と再現の可否をまとめる．

開発においても使用されている Annotation によって記述させることで記法の習得を容易にする．

例えば 図 4 は 図 3 のコードを Java で再現したコードである．このコードをコンパイルすると 3 行目において，不正なメ実装には The Checker Framework（CF）を使う．CF は Anno-

ソッド呼び出しだとしてエラーが発生する．このメソッド呼び

tation を用いて型システムを拡張し，代入やメソッド呼び出し

出しは引数として渡された不変参照の elems を引数として呼において追加の検査を実行するフレームワークである．このび出されている．しかし，Arrays#sort() は破壊的メソッド

検査部分で所有権による制限を再現する．

であり，その引数に不変参照は使用できない．このような Rust

4.

適用実験

の制約に沿わない変数の使用に対してエラーを発生させる．
一方で残りの 5 件ではエラーを再現できなかった．主な原提案手法が Java においてどの程度 Rust の制限を再現できる

因はメソッド呼び出しによる参照作成やライフタイム宣言なか検証するため，Java ソースコードを提案手法によって検査どの機能の未実装である． 図 5 は再現できなかったコードの

する．
—4—

表 1 適用実験結果
タイトル

処理内容

エラー原因

再現可否

再現できない理由

make_separator

引数が空文字列であればセパ

ローカル変数の参照の返却

O

N/A

O

N/A

O

N/A
メソッド呼び出しによって生成レーターを，そうでなければ引数をそのまま返す
get_or_default

引数の Option が値を持っていれ 不変参照から破壊的メソッドのばその値を，そうでなければ空呼び出し

文字列を返す引数の配列から昇順で n 番目のﬁnd_nth不変参照から破壊的メソッドの

値を返す

呼び出し

remove_zeros

引数の配列から 0 を取り除く

参照の存在ルール違反

X

get_curve

値が指定されていれば配列にそ

1 つの構造体にフィールドを通X

this の所有権を管理できないの値を加算し，指定されていな

して不変参照と可変参照を作る
X

メソッド引数での参照作成が未される参照は管理できない

ければ何もしない
reverseconcat_all

与えられた配列の逆順の配列を同じ配列に対して複数の参照を返す

生成している

イテレータで与えられた配列の返り値のライフタイムが解析不

各文字列に指定の別の文字列を能なため指定が必要

実装
X

ライフタイムの宣言が未実装

X

ライフタイムの宣言が未実装

追記する
add_displayable 値をヒープに格納し，ポインタ
を配列に格納する

1

タイムが不明@Owner String findNth ( @Owner String @Borrow []2

このとき，remove() はインスタンスに対して可変参照を要求

elems , @Owner int n) {する．よって 5 行目において不変参照と可変参照が同時に存

Arrays .sort(elems ); // error!

在するため，エラーが発生する．

3@Borrow String t = elems [n];4return t;

5

ヒープに格納する変数のライフ

このコードではメソッドを用い，イテレータとして不変参照を作成している．メソッドを用いた参照の作成には現段階}の実装では対応していない．よってエラーの再現ができていない．しかし，メソッド呼び出しにおける検査処理の追加に

error[E0596]: cannot borrow `elems` as mutable
Arrays#sort() is a destructive method,
requiring @MutBorrow, whereas elems is immutable
as it is @Borrow, and thus cannot be modified.

よりこの点は対応可能であり，提案手法の妥当性には影響はないと考える．

5.

議

論

5. 1

手法の制約

図 4 Java で再現した Ownership Inventory の ﬁnd_nth

1/// Removes all the zeros in -place from avector of integers .

2

fn remove_zeros (v: &mut Vec <i32 >) {for (i, t) in v.iter (). enumerate ().rev () {35v. remove (i);68// error!

}

7

このトレイトの使用により，ライフタイムや借用の挙動が変化する場合がある．この機能は Java には存在しないため，提案手法においてはその影響は考慮していない．提案手法は既

if *t == 0 {4

制限の定義において，簡易化するために考慮しなかった Rustの機能がある．例えば Rust の機能としてトレイトが存在する．

習言語上での学習環境の提供であるため，このように既習言語に存在しない Rust 機能の再現には一定の制約がある．

}

また，開発者以外が定義したメソッドを含むコードに対する}検査には強い制約がある．ソースコード全体に対して所有権

error[E0502]: cannot borrow `*v` as mutablebecause it is also borrowed as immutableを再現した検査を実行するには，事前に使用される全てのメ
ソッドについて追加の型定義を用意しなければならない．このため，多くのライブラリが使用されうる，実アプリケーショ

図5

Ownership Inventory の remove_zeros

ンに対する検査において完全な所有権の再現は難しい．
しかし，これらの制約によって提案手法の有効性が完全に失1 つである．このコードでは 3 行目において iter() を用い，われることは無いと考える．提案手法の目的は Rust への言語

イテレータとして v の不変参照を作成している．その後，5 行

移行における習得難度の易化である．よって提案手法によっ

目で v から要素を削除するため remove() を呼び出している．

て所有権の学習全てを担う必要も無く，所有権の操作において—5—

躓きやすい内容の理解支援であってもその目的は果たせるとソースコード中における所有権の状況把握として素直なアプ

考える．また，任意のライブラリに対応する必要は無く，練習

ローチであり，所有権操作の理解に貢献すると考えられる．提的な実装において使用されやすい Java 標準 API などのメソッ

案手法のエラーメッセージ中に，この手法による可視化を取ドが用意されていれば十分であると言える．

り入れられるとより理解しやすいエラーメッセージを出力で5. 2

効果的なエラーメッセージ

きる可能性がある．

エラーメッセージの内容はエラー修正において重要である．

Coblenz らは Rust に対してガベージコレクションに相当す

Barik らの報告 [4] によると，エラー修正において開発者はエる機能を導入し，Rust を簡単に利用できるようにした [6]．参ラーメッセージを情報源として活用しており，また，その読み

照の存在条件の緩和などメモリ管理の難度が大幅に緩和され，にくさはエラー修正の難しさに影響するとしている．

初学者にとって Rust を活用する難易度を下げた．一方で所有提案手法ではエラー修正を支援するため，簡潔かつ原因の解権の習得には寄与しておらず，純粋な Rust の利用には更に学消に役立つようなエラーメッセージを出力する．エラーメッ

習が必要である．我々の提案手法はあくまで純粋な Rust の習

セージにおいてそのエラーの発生原因となる制限とともに，な得支援を目指す．

ぜその制限が存在するかを説明する．ソースコード中の操作に対する制限は当該言語における安全性などの理念に基づいて設計されており，その理念の理解が早期の制限の理解に役立つと考える．

おわりに

7.

Rust の学習支援を目的とし，Rust 文法の習得と所有権概念の習得を分離するため，所有権を Java に移植した環境を作成

また，提案手法によって得られた知見を Rust で活かせるよ

した．この環境において開発者はソースコードを作成し，発う，提案手法が出力する各エラーメッセージを Rust コンパイラ

生したエラーを修正する経験を通して所有権への理解を深め，のエラーと対応づける．エラーメッセージにおいて Rust におRust での学習を効率化する．

けるエラーコードを記し，いずれの Rust コンパイラのエラー適用実験では題材としてコード 8 件中 3 件のコードで Rustと対応するか明示する．さらに，エラー内容の表記についてもコンパイラのエラーを再現できた．再現できていないコード

Rust コンパイラが出力するメッセージと極力同等のメッセーについても実装の発展により再現可能であると考えている．

ジを出力するようにし，エラー解消の経験を Rust コンパイラ

実際に Rust 学習において提案手法が効果を発揮するか評価のエラーと紐付ける．これにより，Rust の使用開始後にコン
パイラエラーが発生した際，それは提案手法において得た知見を活かせるのか，どのような修正が有効だったかを容易にするため，被験者実験を実施予定である．
謝辞

文

判断できる．
5. 3

有効性の評価[1]

提案手法の有効性を評価するには被験者実験が必要である．
現状で評価している内容はあくまで再現度である．提案手法が目的とする学習支援に対する効果を評価するには，被験者[2]に実際に提案手法を使用させ Rust の習得への貢献を測定する必要がある．
提案手法が前提とする文法などの概念と所有権の分離及び[3]分離による所有権習得の容易化が達成できるか評価する．実
際に Java 使用経験のある開発者に提案手法によって所有権を学習させ，その後 Rust 習得までの過程を調査する．提案手法[4]を導入した Java 環境において文法を気にせず所有権のみを学習できたか，Java において得た知見を Rust 習得過程において活用できたかを評価する．

6.

[5]

関連研究

Rust の習得難易度を改善しようとする研究が存在する．
Crichton らは所有権学習における誤解を整理し，正しく理解するためのコンセプトモデルを作成，コンセプトモデルに基づ

本 研 究 の 一 部 は ，JSPS 科 研 費（JP21H04877，

JP20H04166，JP21K18302，JP21K11829）による助成を受けた．

[6]

献K.R. Fulton, A. Chan, D. Votipka, M. Hicks, and M.L. Mazurek, “Beneﬁts and drawbacks of adopting a secure programming language: Rustas a case study,” In Proceedings of Symposium on Usable Privacy andSecurity, pp.597–616, 2021.
S. Zhu, Z. Zhang, B. Qin, A. Xiong, and L. Song, “Learning and programming challenges of Rust: A mixed-methods study,” In Proceedings of International Conference on Software Engineering, pp.1269–
1281, 2022.
W. Crichton, G. Gray, and S. Krishnamurthi, “A grounded conceptual model for ownership types in Rust,” Journal on Proceedings of
the ACM on Programming Languages, vol.7, no.OOPSLA2, pp.1224–
1252, 2023.
T. Barik, J. Smith, K. Lubick, E. Holmes, J. Feng, E. Murphy-Hill,
and C. Parnin, “Do developers read compiler error messages?,” In
Proceedings of International Conference on Software Engineering,
pp.575–585, 2017.
M. Almeida, G. Cole, K. Du, G. Luo, S. Pan, Y. Pan, K. Qiu, V. Reddy,
H. Zhang, Y. Zhu, et al., “Rustviz: Interactively visualizing ownershipand borrowing,” In Proceedings of Symposium on Visual Languages
and Human-Centric Computing, pp.1–10, 2022.
M. Coblenz, M.L. Mazurek, and M. Hicks, “Garbage collection makes
Rust easier to use: A randomized controlled trial of the Bronze garbage
collector,” In Proceedings of International Conference on Software Engineering, pp.1021–1032, 2022.

いた教育法を提案した [3]．所有権学習過程において初学者が何を誤りやすいのかを明確化し，具体的な解決手法を提案した点で大きな貢献である．
Almeida らは静的解析によって Rust ソースコード中における所有権の移動や参照の状態を可視化する手法を考案した [5]．
—6—