Surface Pro 11 の SSD は256MB書き込みだけ妙に遅かった

Surface Pro 11 の内蔵 SSD、SDDPTQD-1T00-1124-WD は、64MB 書き込みで348MB/s、256MB 書き込みで197MB/sだった。

サイズを大きくしたのに書き込みだけ遅くなり、読み込みは64MBで682MB/s、256MBで1073MB/sまで上がっているので、大きい連続アクセスのほうが速くなる、という素朴な見方には合う（読みと書きで顔が分かれた）。ところが書き込みは逆に落ちてしまった（ここで一度スクリプトを疑った）。

測った瞬間はスクリプトのバグを疑ったが、runs_ms を見ると256MB書き込みだけが3回とも1秒台に乗っていた。計測対象は Microsoft Surface Pro, 11th Edition。Snapdragon X 12-core X1E80100 @ 3.40GHz、メモリ32GB、Windows 11 Pro 10.0.26200 ARM64 の環境で動かしている。測定を回したのは2026年6月6日の20時17分で、2026-06-06のこの回だけを使った。外付けではなく内蔵SSDに対して測っている。

fsync まで待つ重めの書き方

今回の数字は、カタログスペックの数GB/sを見るための測定とは別物で、書き込みは buffering=0 で開き、書いたあとに os.fsync() を呼んで毎回フラッシュしている。OSやドライブ側のキャッシュに気持ちよく積ませる測り方ではなく、かなり実務寄りに待たせる形だ（ここを忘れると、197MB/sだけがひとり歩きする）。

スクリプトの骨格はこういうものだった。

with open(path, "wb", buffering=0) as f:
    f.write(data)
    os.fsync(f.fileno())

with open(path, "rb", buffering=0) as f:
    f.read()

64MB と256MB はそれぞれ3回ずつ。小さいファイルは512バイトのファイルを2000個作り、同じ流れで消している。回数は少ない。3回だけでは安定したベンチマークとは呼びにくいので、ここでは「手元でこう見えたログ」として読むのが安全だろう（再現性を見るなら回数を増やす必要がある）。

連続読み書きと小ファイルを並べる

中央値だけを眺めると整って見えるので、全反復値も残しておく。単位は runs_ms と median_ms がミリ秒、MB/s はJSONに入っていた算出値だ。

ケース	操作	runs_ms 全回	median_ms	算出 MB/s
64MB	write	260.43 / 152.37 / 183.87	183.87	348
64MB	read	93.86 / 67.71 / 106.63	93.86	682
256MB	write	1452.99 / 1250.54 / 1300.30	1300.30	197
256MB	read	223.91 / 238.50 / 245.65	238.50	1073

ケース	内容	runs_ms 全回	median_ms	files/s	1ファイルあたり
small_files	512バイトを2000個作成削除	1673.41 / 1259.13 / 1206.87	1259.13	1588	約0.63ms

64MBの書き込みは中央値183.87ms、256MBの書き込みは1300.30ms。データ量は4倍なのに、時間は約7.1倍に伸びている。ここから出るMB/sが348から197へ落ちるのは自然な計算だ。逆に読み込みは93.86msから238.50msで、データ量4倍に対して時間は約2.5倍に収まった。だから682MB/sから1073MB/sへ伸びる。

256MB write だけ鈍い

一番おいしい異常値は、256MBの書き込みだけ鈍いこと。64MBでは3回のうち最速が152.37ms、最遅が260.43msで、最遅は最速の約1.7倍。256MB書き込みは1250.54msから1452.99msなので、比は約1.2倍に縮む。ばらつきというより、遅い帯域に入ったまま安定しているように見える。

理由は断定せず、buffering=0 と os.fsync() で毎回待っているので、256MBの連続書き込みでキャッシュや内部の書き込み処理が飽和した可能性はある、という範囲に留める（内部カウンターは見ていない）。ただしSMARTや温度やコントローラ内部の状態までは見ていない状態だった。ここで「キャッシュ切れ」と言い切ると、測っていない数字まで書いたことになってしまう。

読み込み側の動きは対照的だった。256MBのreadは223.91ms、238.50ms、245.65msでかなりまとまっている。最速と最遅の比は約1.1倍。連続読み込みでは、サイズを大きくしたほうがドライブにもOSにも都合がよかったのかもしれない。ここも推測に留める。

小さいファイルは別の競技

512バイトのファイルを2000個作って消すテストは、中央値1259.13msで1588files/sだった。1ファイルあたりに直すと約0.63ms。数字だけ見ると速いが、扱っているデータ量は512バイトずつなので、64MBや256MBの連続読み書きとは競技が違う。

実際に node_modules や .git が遅く感じる理由は、この0.63msの積み上がりに近い。ファイル本文は小さくても、作成、ディレクトリエントリ更新、削除、同期待ちが1個ずつ発生する。2000個なら1.26秒前後で済むが、数が増えれば待ち時間が目立つ。大きな1本のファイルを読む682MB/sや1073MB/sとは、同じSSDでも体感がつながりにくい。

この差は個人的には納得感があった。ARM64だから遅い、NVMeだから速い、という単純な話ではなく、アクセスの形が変わると、Surface Pro 11 の内蔵SSDでも見える顔が変わる（この切り替わりが今回の面白いところ）。

SSD が遅い、とはまだ言わない

今回いちばん危なかった勘違いは、256MB書き込みの197MB/sを見て「SSDが遅い」と言いそうになったこと。実際には、フラッシュを強制する測り方で出た数字であり、普段のコピーやアプリ起動をそのまま表す値とは別扱いにする。この条件を混ぜると記事全体が間違える（測っている待ち時間の種類が違う）。

反復回数も3回だけ。最大最小の比を見ると、64MB read は約1.6倍、64MB write は約1.7倍、small_files は約1.4倍まで動いている。256MB read は約1.1倍、256MB write は約1.2倍で比較的落ち着いたが、これだけで傾向を固定するには足りない状態だ。

次に測るなら、64MBと256MBの間を増やしてみる。128MBを挟めば、書き込みがどこで落ち始めるのか少し見えるのではないだろうか。fsyncありとなしを分ける測定も必要だろう。今回はあえて重い条件を残した。node_modulesや.gitで感じる待ち時間に近づけたかったからだ。

開発作業の物差しにする

この結果を見て、巨大な連続ファイルのコピー速度だけでSSDを判断するのはやめた。Surface Pro 11 の内蔵SSDは、読み込みの連続アクセスでは256MBで1073MB/sまで出る。一方、フラッシュつき書き込みでは256MBが197MB/sまで落ちた。どちらも同じドライブの姿だ。

開発作業で効くのは、小さいファイルのほうかもしれない。パッケージ展開、Gitのチェックアウト、キャッシュの作成削除。そういう処理は512バイトや数KBの世界を大量に触る。今回の2000個で1259.13msという数字は、その待ち時間を思い出すための物差しになる。

結論を急ぐなら、読み込みは大きいほうが伸び、フラッシュつき書き込みは大きいほうが落ち、小ファイルは1個約0.63msで連続MB/sとは別腹だった。もう少し回数を増やさないと断定はできないが、少なくとも「NVMeなら全部速い」という雑な期待は外れた。