robocopyの最適な/MT値は環境で変わる。45回の実測で分かった家庭用NASのボトルネックを検証（2026年7月20日更新）

2026.02.15

※旧タイトル「robocopy高速バックアップ設定方法4TBNASを安全かつ最速で同期する実測手順」（2026年2月15日）

本記事は「最強の設定」を紹介することが目的ではありません。実際に取得した45回分のデータをもとに、家庭用NASにおけるrobocopyの/MTにおける最適な値を考察する検証記事です。

Windowsで大量のファイルをコピーするなら、robocopy（Robust File Copy）を使う人がほとんどだと思います。もちろん私もです。

以前、新しいNASへ約4TBのデータを移行した際、思っていた以上に時間がかかり、「もっと速くならなるかな」と感じました。

robocopyには多くのオプションがありますが、その中でもコピーの速さに大きく影響するといわれているのが、マルチスレッド転送に関わる/MTオプションです。

robocopyで転送速度を速くするために何をしたらよいか、ネットで調べてみると色々な意見がありました。しかし、まとめると次の三つに収束します。

  • /MT:32が最速
  • /MTは数値が大きいほど速い
  • /MT:128までいける

しかし、記事には「速い」と「推奨値」がばらばらで、どんな環境でなぜその値を選択したのか説明をしているものは多くありませんでした。

そこで本記事では、自分の環境で実際に測定することで、一般家庭における/MTの最適な値を実際に測定してみることにしました。

検証内容はシンプルにしました。

約1MBのダミーファイルを1,000個、10,000個、100,000個用意し、/MT:8と/MT:16/とMT:32の3種類でコピーをしました。また偶然の結果とならないように各条件を5回ずつ測定しました。3種類 x 3パターン x 5回 = 合計45回の試行回数です。

先ほども触れましたが、本記事は全ての環境において「この設定が絶対に最速」というものではありません。

45回の試行により、得られたものはどこにボトルネックがあり、それがMTにどう影響していたのかが分かりました。そしてそれら試行回数から得られた数値からはrobocopyのMTの値は環境に依存する、という当たり前の結果でした。

もし現在次のようなことで悩んでいる方がいたら参考になればいいと思います。

  • robocopyが思ったよりも遅い
  • /MTの値は結局いくつがいいのかわからない
  • 写真やドキュメントなど小さいサイズのファイルを大量にコピーしたい

そんな方がいれば、本記事の検証結果が一つのデータとなるかもしれません。

私の環境ではこうでしたが、「自分の環境でも一度測定してみよう」と思っていただけたらと思います。

検証環境

本記事で紹介する結果は、実際に私が使っている環境とSteam用PCで測定したものです。robocopyの転送速度は、PCだけでなくNASやネットワーク構成、ストレージ性能にも大きく左右されます。そのため、まずは検証に使用した環境を公開します。

検証したPCの構成

コピー先となるWindows PCの構成です。Intel入ってる感じのJRPG向けのPC構成です。

項目構成
CPUIntel Core i5-14600
メモリDDR5 32GB
OSWindows 11
コピー先ストレージNVMe SSD（約3,000MB/s級）

今回の検証では、CPU使用率やSSDの負荷をモニターしながら実施しましたが、コピー中もPC側には十分な余力がある状態でした。

NAS構成

コピー元には家庭向けの2ベイを使用しています。

項目構成
構成RAID 0
記録媒体3.5インチHDD ×2
用途写真・動画・バックアップ保存

NASはSSDではなくHDDで構成されているため、ランダムアクセス性能やCPU性能が転送速度へ影響する可能性があります。

ネットワーク構成

ネットワークは2.5GbEを意識した構成です。

項目構成
有線LAN2.5GbE
無線LANWi-Fi 7
ルーターBuffalo AirStation WXR9300BE6P

今回のrobocopy検証は、少しでも外部からの影響を防ぐため、有線LAN（2.5GbE）で実施しています。

理論上は約312MB/s程度まで通信できるはずなので、1GbE環境よりもネットワーク自体がボトルネックとなりにくい構成だと思います。

使用したソフトウェア

今回の検証で仕様したソフトウェアは次の通りです。

ソフトウェア用途
Windows標準 robocopyファイルコピー
PowerShell検証実行・ログ取得
OpenOffice Calc測定結果の集計
Mery気が付いたことのメモ代わり

robocopyはWindows標準搭載のため、追加ソフトをインストールすることなく同じ検証を行えます。

この環境でわかること

今回の環境からわかることは次のことです。

  • コピー先PCのSSDは十分速さが出る
  • PC自体のCPU使用率にも余裕がある
  • ネットワーク帯域にも余裕がある
  • コピー元のNASのCPUがデータをさばききれるかどうか

このような条件で検証を行いました。やはりNASのCPUの性能が非公開であったため、ボトルネックとなりそうな感じは否めません。ここが/MTの値に影響を与えるかもしれません。

家庭によってはCPU性能が高くオールSSDでNVMeキャッシュ搭載NAS、10GbEネットワークを導入しているかもしれません。そういった環境では、今回とは異なる結果になるでしょう。

そのため、本記事では「この設定が最速」と言い切ることはできず、「この環境でどのような結果になったのか」を実測データとして紹介し、理由を考察します。

検証条件と測定方法

今回の検証では、/MTオプションによる違いだけを比較できるよう、コピー元、コピー先、ネットワーク構成などの条件を公開し、その環境下で測定を行いました。できるだけデータを取得することを目的としています。

なぜ45回も測定したのか

robocopyのコピー速度は、HDDのキャッシュやNAS内部の処理状況、Windowsのキャッシュなどによって、毎回わずかに変動します。

もし1回だけ測定するとした場合、その時だけ偶然「とても速かった」、「たまたま遅かった」という結果になる可能性があります。

そこで今回は、偶然性をできるだけ丸めるために、各条件を5回ずつ測定しました。表にすると次の通りです。

ファイル数/MT:8/MT:16/MT:32
1,000ファイル5回5回5回
10,000ファイル5回5回5回
100,000ファイル5回5回5回

3種類のファイル数 x 3種類の/MT:値 x 5回 = 45回のコピーを実施しています。

コピー条件

測定条件をできるだけ揃えるため、毎回同じ方法でコピーを実施しました。

項目内容
コピー元NAS
コピー先NVMe SSD
コピーするデータランダムバイト、ファイルサイズ約1MB
ネットワーク2.5GbE有線LAN
コピー方法毎回フルコピー
コピー先測定ごとに削除
使用コマンドrobocopy

最も重要なことは、毎回コピー先フォルダを完全削除してから測定したことです。

データが残っていると差分コピーになりWindowsまたはrobocopyにより最適化が働いてしまうため、純粋なコピー性能を比較できないからです。

消した時のコマンドは以下のものです。

Remove-Item "コピー先のフォルダ" -Recurse -Force -ErrorAction SilentlyContinue

45回すべてをフルコピーで実施しました。

使用したコマンド（オプション）

また環境を同じ条件にしたことから、使うコマンドも/MT:の値とログ名以外は変更せずに行いました。

robocopy "コピー元フォルダ" "コピー先フォルダ" /E /MT:〇〇 /R:1 /W:1 /NP /NFL /NDL /LOG:""D:\dummy\logs\mt8_1000などログ名.log""

比較した/MTの値は次の3種類です。

オプション概要
/MT:88スレッドで並列コピー
/MT:1616スレッドで並列コピー
/MT:3232スレッドで並列コピー

一般的にはスレッド数を増やせば高速になると言われています。ですが、ボトルネックになる場所があれば、結果はおおいに変わってくることでしょう。

ログの取得方法

各測定ではrobocopyが出力したログを保存し、次の情報を主に集計しました。

  • コピー時間
  • 転送速度（Byte/s）
  • 転送速度（MB/分）
  • コピー成功件数
  • エラーの有無

各条件を記録して成形したのち、次の統計値を出しました。ただし45回しかしていないため、参考程度のデータと思っていただけたらと思います。

  • 平均コピー時間
  • 平均転送速度
  • 最短時間
  • 最長時間
  • 標準偏差

これらは速度ではなく、安定して速いかどうかを評価するものです。

実験 1：1,000ファイル（約1GB）の検証結果

まずは約1GB（1000ファイル）のコピー検証を開始しました。一般的な写真やOffice関係ファイル、小規模なバックアップを想定したデータ量です。ファイル数が少ないため、ストレージ性能よりもファイル管理や通信状態が現れやすい条件と言えます。

使用したrobocopyコマンド

前述していますが使った基本コマンドは次のものです。

robocopy "Z:\dummy\1000" "D:\dummy\1000" /E /MT:8 /R:1 /W:1 /NP /NFL /NDL /LOG:""D:\dummy\logs\mt8_1000.log""

検証中に変更した個所は/MTの値を8と16と32に変えたこと。後から分かりやすいようにログの名前をmt8_1000.logとmt16_1000.logとmt32_1000.logに変えました。

1,000個のファイルの平均測定結果

まずは1,000個のファイルを/MT:8、/MT:16、/MT:32で5回行った際の平均値を求めました。

項目/MT:8/MT:16/MT:32
試行回数5回5回5回
平均コピー時間1分13秒2分14秒4分22秒
平均時間（秒）72.8134.4262.0
最短時間1分08秒2分03秒4分02秒
最長時間1分18秒2分31秒4分46秒
標準偏差4.32秒13.45秒20.40秒
平均速度（MB/分）8,228.617,975.217,654.76
速度の標準偏差510.44769.26573.74
平均転送速度（Byte/s）143,805,384139,376,847133,776,630

私の環境下では特殊なことが起こりました。予想では一番遅いと思っていた/MT:8が一番速く処理を終えていました。「/MTは大きいほど速い」というイメージとは逆の結果がでました。

平均コピー時間だけ見ると差がよく分かります。

  • /MT:8 … 約1分13秒
  • /MT:16 … 約2分14秒
  • /MT:32 … 約4分22秒

つまり、平均コピー時間だけを見れば、/MT:32は/MT:8のおよそ3.5倍以上の時間がかかっていることがわかります。

一応、所要時間の倍率についても調べてみました

所要時間倍率

/MT:8を基準に1.00倍として比較してみました。

/MT平均時間所要時間倍率
/MT:81分13秒1.00倍
/MT:162分14秒1.85倍
/MT:324分22秒3.60倍

転送速度だけでなく所要時間についても同じ傾向でした。最も高速だったのは私の環境では/MT:8でした。

/MT:32よりも/MT:8の方が速いのか？

この時点で原因を求めることは拙速です。1,000個程度のファイル数であれば小規模の

ここでさらなる予想として、私の環境下ではNASのCPUがネックとなり/MT:8の速度がでやすいのではないかと思いました。

1,000個のファイルのコピーで読み取れること

今回の検証では、スレッド数を増やしても速度は向上しない、ということがわかりました。

むしろ、コピー時間は長くなり、転送速度も低下し、標準偏差（測定結果のばらつき）も大きくなるという傾向が見られました。

一般の言説と異なる結果が出たということが重要です。では条件を変えて細かいファイルをもっと増やした場合どうなるか、そちらの方がマルチスレッド的には良い結果がでるのではないかと思います。

そこで次は、ファイル数を10倍に増やした10,000ファイルでも同じ条件で検証を行い、この傾向が偶然なのか、それとも再現性のある結果なのかを確認します。

実験 2：10,000ファイル（約10GB）の検証結果

引き続き、ファイル数を10倍に増やしました。その数10,000個（約10GB）。これらのファイルのコピーを検証しました。

この規模になると、RAWデータを含む写真のライブラリ全体やローカル保存の音楽ライブラリ、家族の動画など、ごくごく一般的な家庭でも十分に想定できるバックアップする際の現実的なサイズになります。1,000ファイルでは「たまたまそうなった」という可能性は十分にありました。ここでは再現性に重きを置き検証します。

10,000個のファイルの平均測定結果

前回の1,000回に比べて特段遅くなったという感覚はありませんでした。むしろ10,000個のダミーファイルを作る時間の方がひどく時間がかかりました。

項目/MT:8/MT:16/MT:32
試行回数5回5回5回
平均コピー時間13分29秒26分12秒50分35秒
平均時間（秒）808.81571.83034.8
最短時間13分17秒25分37秒49分48秒
最長時間13分54秒26分51秒51分42秒
標準偏差15.02秒26.73秒44.83秒
平均速度（MB/分）7,438.866,819.146,649.58
速度の標準偏差130.06117.0095.83
平均転送速度（Byte/s）130,003,501119,173,140116,209,771

ファイルの個数が10倍になったため全体的にそのような感じに見えます。ついでに所要時間倍率も見てみます。

所要時間倍率

1,000ファイルと同様に、/MT:8を基準に1.00倍として比較をしました。

/MT平均時間所要時間倍率
/MT:813分29秒1.00倍
/MT:1626分12秒1.94倍
/MT:3250分35秒3.75倍

1,000個のファイルでは/MT:8とくらべて約3.6倍だった/MT:32との時間差は、10,000個のファイルでは約3.75倍とほぼ同じような数字になりました。再現性があるのかな、と思えてきたところです。

1,000個のファイルと同じ傾向が再現された

今回最も重要だったのは、1,000個のファイルで見られた傾向が偶然ではなかったことにあります。一般的な言説が私の環境では全く異なる結果となったのも興味深いです。

「ファイル数が増えれば並列処理の効果が現れて、/MTの値が大きいほど恩恵が受けられる」

そう期待していたのですが、実際の測定の結果、予想とは逆の結果となってしまいました。

結局1,000個のときと同様、/MT:8が最も高速、/MT:16は2倍の時間がかかり、/MT:32は4倍近い時間がかかりました。依然として/MT:8が安定して一番速いという傾向はかわりませんでした。

ファイル数を増やしても、私の環境ではスレッド数を増やすメリットは確認できませんでした。

10,000個のファイルの転送速度の違い

コピー時間にばかり目が行きがちですが、10.000個のファイルの平均の転送速度にも今回は大きな違いがみられました。

/MT平均速度（MB/分）
/MT:87,438.86
/MT:166,819.14
/MT:326,649.58

今更注目するまでもありませんが、スレッド数を/MT:8の4倍に増やしても速度向上にはならず、むしろ低下している点です。

単純に、仕様としても、32本のスレッドでコピーした方が高速になりそうですが、実際にはなりませんでした。

10,000ファイルをコピーした結果からの予想

ここまではっきりと理論値と現実の値が乖離してしまうと、もう仮説を立てるまでもないのですが次のことが考えられます。

まず排除する事項としては、NVMe SSD、2.5GbEのネットワーク構成、CPUも及第点だと思います。

問題はコピー元であるNAS側が先に限界に達している可能性が色濃くあります。

もしそうならば、HDDアクセス待ち、CPU処理待ちなどが発生して全体の効率を著しく低下させているように思えます。

つまり、「並列化すれば速くなる」という認識は改めて「処理能力を超えた並列化は、逆に効率を悪くさせる」という仮説を立てることができます。

100,000個のファイル（約100GB）の検証結果

最後にダメ押しの、100,000個のファイルのコピーを検証しました。この規模になると長年撮りためたGB単位の写真ライブラリやいくつか10年分くらいの家族旅行ビデオなどが想定されます。ここまでくるとストレージ性能ではなく、NASのCPUの処理能力が大きく影響するものと想像できます。

蛇足ですが、100,000個のダミーファイルを生成するのに24時間オーバーしました。

100,000個のファイルの平均測定結果

仮説のNASのCPUでデータが渋滞を引き起こしているのならば、/MT:8が最速になるはずです。では測定結果を公表します。

項目/MT:8/MT:16/MT:32
試行回数5回5回5回
平均コピー時間2時間15分23秒4時間02分39秒8時間11分10秒
平均時間（秒）8,122.814,558.829,470.4
最短時間2時間11分03秒3時間58分21秒8時間05分30秒
最長時間2時間21分53秒4時間14分24秒8時間16分06秒
標準偏差338.34秒398.15秒272.53秒
平均速度（MB/分）7,411.767,347.886,833.14
速度の標準偏差308.00192.5062.90
平均転送速度（Byte/s）129,529,924128,413,559119,417,730

また、今回も/MT:8を基準の1.00倍として比較しました。

/MT平均時間所要時間倍率
/MT:82時間15分23秒1.00倍
/MT:164時間02分39秒1.79倍
/MT:328時間11分10秒3.63倍

表のとおり、1,000個、10,000個、100,000個のファイルのいずれにおいても、私の環境では/MT:8が最も短時間でコピーを完了することがわかりました。

45回の検証で見えてきたこと

いままで1,000個、10,000個、100,000個のファイルを/MTの値を変えながら、計45回のコピーを繰り返してきました。

当初の予想は「/MT:32が最も高速になるだろう」でした。

しかし実際の結果は全く逆であり、全ての検証で「/MT:8が安定して最も高速だった」という結果になりました。また、同じく速さの順番も/MT:8 → /MT:16 → /MT:32と変わりませんでした。

つまり、この結果は偶然ではなく、きちんと法則性のある環境に依存した再現性のある現象だと言い切ることができます。

ボトルネックの存在

検証環境からコピー先のNVMe SSD、2.5GbE環境のcat6aの有線ネットワーク、CPUの稼働率からは/MT:32が遅くなる理由を見つけることはできませんでした。

コピー先やネットワークがボトルネックならば、/MTを変更した場合ここまで一貫した結果にはならなかったのではないかと推察はできます。

一方、謎につつまれたCPUを積む家庭用NASです。

家庭用の安いNASは消費電力や性能を価格でバランスを取っているため、確かに2.5GbEに対応しているけれどもCPUがしょぼくて情報を処理しきれないということがあります。

そんなしょぼいCPUに/MT:32で大量のコピー要求が送られてきた場合でうなるか。

自明の理ですねHDDアクセス待ちとCPU処理待ちで大渋滞します。

一方それなりの速度が出ていた/MT:8はNASが無理なく処理できる範囲に収まっていたため、データの流れが詰まらず、意外にも最も高いスループットを維持できたのでしょう。

もちろん、このデータや「/MT:8速い説」はこのNASに限った考察です。

値段が張りますがCPU性能が高いNASやSSD搭載NAS、あるいは工事したりして10GbE環境では、異なる結果になることと思います。

この検証で得られた一番の収穫

今回、検証を始めるにあたり、「/MT:32でどれくらい速くできるのか」という考えがありました。予想では「データからやはり/MT:32が一番速い」や「robocopyの最適な設定を見つけた」という平凡なものでした。

しかし一番大きな収穫は「自分の環境では、どこがボトルネックになっているのか」ということでした。

ボトルネックがNASのCPUである限り、/MTの値をいくら増やしても128にしても変わりません。つまり、/MTの値を増やしても速度が向上しない理由は、robocopyではなく、ハードウェア全体のバランスにありました。

  • robocopyの設定
  • NASのCPU性能
  • ストレージ性能
  • ネットワーク環境

これらが組み合わさって初めて速度が決まります。設定を真似しても自宅の環境が同じでなければ、「何が一番！」という同じ結果になるとはかぎりません。

全件省結果まとめ（1,000個、10,000個、100,000個のファイル比較）

ここまで1,000個、10,000個、100,000個のファイルの3パターンについて、それぞれ/MT:8、/MT:16、/MT:32を5回ずつ、合計45回のコピーを実施しました。それら全ての結果を一覧で比較し、今回の検証から見えてきた傾向を整理します。

検証結果一覧

ファイル数/MT:8/MT:16/MT:32最速
1,0001分13秒2分14秒4分22秒 /MT:8
10,00013分29秒26分12秒50分35秒 /MT:8
100,0002時間15分23秒4時間02分39秒8時間11分10秒 /MT:8

所要時間の倍率比較

ファイル数/MT:8/MT:16/MT:32
1,0001.00倍1.85倍3.60倍
10,0001.00倍1.94倍3.75倍
100,0001.00倍1.79倍3.63倍

私の環境ではファイル数が100倍になっても、倍率はほぼ一緒でした。

おそらくですが、私のNASは/MT:8に対して、/MT:16なら約2倍の時間、/MT:32なら約3.5～4倍の時間がかかるという傾向が一貫してみることができました。

平均転送速度比較

ファイル数/MT:8/MT:16/MT:32
1,0008,228.61 MB/分7,975.21 MB/分7,654.76 MB/分
10,0007,438.86 MB/分6,819.14 MB/分6,649.58 MB/分
100,0007,411.76 MB/分7,347.88 MB/分6,833.14 MB/分

転送速度についても同じ傾向が見られました。

/MTの値を増やしても速度は向上せず、常に/MT:8が最も高いスループットを維持しています。特に100,000個のファイルでは/MT:8と/MT:18の差は少なくなっていますが、それでもコピー時間では2時間くらい差が出ています。

この記事は「/MT:8が最速」というものではありません、「私の環境で最適な値は/MT:8だった」ということになります。

よくある質問（FAQ）

Q
/MTの値は大きいほど速くなりますか？
A

いいえ。必ずしも速くなるわけではありません。Microsoft公式でも/MTは並列スレッド数を指定するオプションとは説明されていますが、「数値が大きいほど高速になる」とは書かれていません。

Q
家庭用NASなら/MT:8を使えば大丈夫ですか？
A

いいえ。絶対そうだということはできません。どこにボトルネックがあるか、ボトルネックでも性能が高ければ/MT:16や/MT:32の方が高速になることも大いにあると思います。

Q
別件ですが/MIRは使わないほうがいいですか？
A

/MIRの仕組みを理解できてから利用するべきだと思います。/MIRはコピー先をコピー元と完全に同期します。そのため、コピー元で削除したり存在しないファイルはコピー先からも削除されます。誤った操作をするとバックアップを削除される可能性もあります。

Q
/Zを付けない方が速いのですか？
A

今回の検証では/Zは使用していません。/Zは途中から再開できる定番オプションですが、その分チェックポイントを書き込む処理が増えます。企業など安全性を求める環境では有用です。家庭用NASでは必要ないと思います。

Q
私のPCでもこの記事と同じ結果になりますか？
A

同じになるとは限りません。今回の検証結果は、あくまでも私の環境で得られたものです。公開してあるハードウェアの環境で同じ条件が揃えられなければ、/MTの値も変わります。この記事を参考に、ご自身の環境でベストな値を見つけてください。

まとめ

robocopyについてネットで調べると、「/MT:32が速い」「/MT:128までいける」といった設定例を見かけます。しかし、それらはその人の環境で得られた結果であり、すべての環境に当てはまるわけではありません。

今回、私は1,000個、10,000個、100,000個のファイルという3つの条件で、それぞれ/MT:8、/MT:16、/MT:32を5回ずつ、合計45回の検証を実施しました。

その結果、私の環境ではすべての条件で/MT:8が最も高速という、当初の予想とは全く異なる結果になりました。

この検証から分かったのは、コピー先のNVMe SSDや2.5GbEネットワークではなく、コピー元のNASがボトルネックになっていたということです。並列数を増やせば速くなるわけではなく、ハードウェアが処理できる能力を超えてしまうと、かえって待ち時間やオーバーヘッドが増え、全体の転送速度が低下することが分かりました。

だからといって、「家庭用NASなら/MT:8が正解」という結論ではありません。

私がこの記事で一番伝えたいのは、「最適なrobocopy /MTの値はネットの情報ではなく、自分の環境で決まる」ということです。

もしコピー速度に不満を感じているなら、ぜひ検証をしてボトルネックがどこにあり、/MTの値がいくつが適切なのかログをみて条件を変えながら測定してみてください。

うまくはまれば何年も使い続けるバックアップ環境を最適化できるかもしれません。

リファレンス

Microsoft Learn「Robocopy」
https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/robocopy

Microsoft Learn「Windows Server Storage」
https://learn.microsoft.com/ja-jp/windows-server/storage/

※この記事に掲載したベンチマーク結果は、筆者環境で45回実施した検証結果です。同一結果を保証するものではありません。

関連記事

・NASが遅い原因は配線とSMB署名だった – 38MB/s→215MB/sに改善した話
　https://lonely1.jp/2026/02/20/ls720d0802-nas-speed/

・Raspberry Pi 5でNAS転送を高速化（SMB署名ありでLS720Dを2.5GbE並みに動かす）
　https://lonely1.jp/2026/04/05/raspi5-nas/

更新履歴

  • 2026年7月20日
  • 2026年2月15日
P
P

【この記事を書いた人】

黒瓜 勉（Lonely Lab運営）：

PC-9821時代からのインターネット老人。英文学博士課程前期で培った英文一次ソースの解読を武器に、PC-98からWindows 3.1、そして現代のRaspberry Piまで、世代を超えた実機検証を行っている。

「今あるものを、もっと長く楽しむ」をテーマに、技術の流行り廃りに左右されない公式仕様に基づいた堅牢な環境構築を追求。実機検証による第一に安全性、第二に可能性、第三に再現性を担保した技術情報を発信中。

※ 本記事は実機環境で検証した内容をもとに執筆しています。動作環境やソフトウェアのバージョンが異なる場合は結果が変わる可能性があります。

詳しいプロフィール・運営方針はこちら
https://lonely1.jp/helloworld/

コメント