はじめに
現在弊社では古い端末の更新が進められており、私のメイン端末も最新のM5 Proプロセッサを搭載したMacBook Proに更新されました！メモリ容量は64GBと十分です。業務端末の性能は生産性に直結するので、弊社では端末の更新も適宜行っております。
一方で、同時期に発表されたA18 Proプロセッサを搭載したMacBook Neoが大変話題になりました。MacBook Neoは価格を抑えた入門機であり、2020年に発売されたM1プロセッサを搭載したMacBook AirをCPU性能で上回り搭載メモリは8GB固定という特徴があります。 日本円で税込99,800円（TouchID無し）と価格訴求力はあるのですが「2026年の端末としてメモリ容量8GBは本当に大丈夫なのか」という懸念が話題になりました。
そこで、 M1 MacBook Air 8GBメモリモデルを改めて実測で評価してみようと思い立ちました。M1 MacBook Airは今でも評価の高い名機ですが、現在の業務形態に照らしてみたとき最小構成である8GBメモリモデルがどこまで実用的なのか検証してみるのは大変面白そうです。
今回は、弊社の一部業務をイメージしたシナリオで3機種の評価を行いました。 対象はM1 MacBook Air 8GB、iMac Pro（2017）32GB、M5 Pro MacBook Pro 64GBです。世代の違いだけでなくメモリ容量の異なる3機種で比較しました。
比較した結果、M5 Pro MacBook Proのパフォーマンスの高さだけでなく、M1 MacBook Air 8GBが昨今の業務視点で実用的と言えるのか（すなわちMacBook Neoの擬似的な評価）も見えてきました。
今回の検証で見たかったこと
業務端末は単なるコストでなく日々の待ち時間やストレスを減らす投資でもあります。一方で標準構成（特にメモリ容量）をどう考えるべきかは一般的な企業ではよくある悩みですので、実測してみました。
今回確認したかったのは、次の2点です。
- M1 MacBook Air 8GBは、弊社の一部業務形態においていまも実用域にあるのか
- ひいてはMacBook Neo 8GBも同様に実用域にあると言えるのか
- その評価を、M5 Pro MacBook Pro 64GB と iMac Pro(2017) 32GB との比較でどこまで定量的に示せるのか
今回想定する「一部業務形態」は、ローカルでアプリケーションのビルドを行うとか、動画編集を行うといったヘビーなタスクを継続的に実行するケースではなく、一般的なナレッジワークに近いユースケース想定しています。
ただし、弊社の業務環境はゼロトラストアーキテクチャに基づき様々なソリューションを自社で運用しておりますので、バックグラウンドで様々なサービスが動作しております。
弊社の業務環境で動いているアプリケーションやサービスは以下の通りです。
- Microsoft Defender for Endpoint（Plan2）による端末セキュリティ対策
- Netskopeを利用した通信統制
- Okta VerifyによるTouch IDと連携した端末で完結する多要素認証
- Jamf ConnectによるOktaとのサインイン連携
- Jamf Self Service Plusによるアプリケーション展開
- Keeperによるパスワード管理
- Druvaによる定期的なローカルデータのバックアップ
- ただし今回のシナリオではバックアッププロセスは動作させず、クライアントの常駐のみ
- Slackデスクトップクライアントの利用
- Chromeブラウザで複数の業務クラウドサービス（Google Workspace、Miro、Notion、Asana、Boxなど）をタブで同時に開く
- PowerPoint資料を参照・編集する
- Zoom会議をしながら画面共有する
クラウドサービスを中心としたナレッジワークではひとつひとつの処理負荷は小さく、ユーザの操作待ちが圧倒的です。しかし、複数のクラウドサービスが常時バックグラウンドで積み上がることで端末への性能要求が高くなります。昨今のWebブラウザの負荷は非常に大きなものですので、今回の検証はブラウザのタブ数を調整して端末負荷の変化を観察しました。
検証シナリオ
事前のおことわり
よくあるベンチマーク記事のようなアプリケーションバージョン統一などの厳密性は追っていません。業務環境を模した簡便な負荷試験という想定です。（細かいツッコミはご勘弁を！）
また、OSが違えば前提が全く変わるためWindowsとの比較は全く想定していません。Windowsは30年近いアプリケーション互換性（Windows95時代のアプリが動く！）を保ちながら様々なハードウェア環境でも動作するよう作られており、過去に何度もアプリケーション互換性の切り捨てを行い固定ハードウェアを想定したmacOSとは設計思想が全く異なります。
なお、今回の記事に興味を持って検証を行われるのであれば自社の標準業務環境に基づきユースケースシナリオを作成していただくのがおすすめです。弊社と同じ環境を再現して検証する必要はないと考えていますのでご留意ください。
環境情報
いずれも厳密なバージョン統一はしておりません。
- OS
- macOS Tahoe 26.4.1
- M5 Pro MacBook Pro 64GB
- M1 MacBook Air 8GB
- macOS Sonoma 14.8.5
- iMac Pro(2017) 32GB
- macOS Tahoe 26.4.1
- ディスプレイ
- フルHD解像度のモバイルモニタをUSB-C接続しマルチモニタ状態で利用
- 検証目的なのでセカンダリモニタを統一してます
- 本体の解像度は「スペースを拡大」
- フルHD解像度のモバイルモニタをUSB-C接続しマルチモニタ状態で利用
- アプリケーション（厳密な統一はしておらず、計測時の最新リリース版）
- Netskope Client
- Druva in Sync
- Okta Verify
- Jamf Self Service Plus
- Jamf Connect
- Microsoft Defender for Endpoint
- Google Chrome
- メモリセーバー有効：バランス重視(推奨)
- ただし今回のシナリオではタブの非アクティブ化は発生しておらず、表面的には影響無し
- Microsoft 365 Apps（Word、Excel、PowerPoint、Outlook）
- Claude Code
- 今回は起動しておらず無関係
- Microsoft Edge
- 今回は起動しておらず無関係
- Chrome拡張機能
- Keeperパスワードマネージャー
- Okta Browser Plugin
- Zoom Chrome Extension
操作手順
各端末を再起動後、以下の操作を行いました。Slack + 複数タブのブラウザ + スライド編集 + Zoom で画面共有という現場でありがちな「日常業務で発生した会議場面」を再現しています。負荷計測のためブラウザベンチマークSpeedometer 3.1 を都度走らせています。
https://www.browserbench.org/Speedometer3.1/- ターミナルから負荷計測スクリプトを実行開始
- Slackを起動
- Chromeブラウザを起動しSpeedometer 3.1 を実行（1回目）し、業務用SaaS一式（Boxファイルプレビュー、Miro、Asanaプロジェクトボード表示、GMail、Google Calendar、Notionドキュメント表示）を開く
- 新規タブでSpeedometer 3.1 を実行（2回目）
- ローカルのPowerPoint 資料をPower Pointデスクトップアプリで開く
- Zoomを起動し、ローカルのPowerPoint資料を画面共有
- 新規タブでSpeedometer 3.1 を実行（3回目）
- ブラウザで業務用SaaS一式を開く（2セット目）
- 新規タブでSpeedometer 3.1 を実行（4回目）
- ブラウザで業務用SaaS一式を開く（3セット目）
- 新規タブでSpeedometer 3.1 を実行（5回目）
負荷ログの取得
今回の検証では、macOS 標準のコマンドから取得できる情報をもとにPythonスクリプトで 30 秒ごとに CSVファイルへ記録しました。標準で入っているアクティビティモニタアプリで取得できる情報と同等のものを収集しています。
実際に使ったスクリプトは次のとおりです。（作成はAIサービスにも手伝ってもらいました）
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import subprocess
import re
import datetime
import os
import csv
import socket
F_GB = 1.0 / (1024 ** 3)
def sh(cmd):
return subprocess.check_output(cmd).decode().strip()
def get_machine_tag():
try:
name = sh(["scutil", "--get", "ComputerName"])
except Exception:
name = socket.gethostname()
return re.sub(r"[^A-Za-z0-9_-]+", "_", name)
pagesize = int(sh(["pagesize"]))
vm_out = sh(["vm_stat"])
lines = vm_out.splitlines()
sep = re.compile(r":[ \\t]+")
vm = {}
for line in lines[1:]:
line = line.strip()
if not line:
continue
name, value = sep.split(line)
vm[name] = int(value.strip(".")) * pagesize
hw_memsize = int(sh(["sysctl", "-n", "hw.memsize"]))
swapusage = sh(["sysctl", "vm.swapusage"])
m_used = re.search(r"used = ([0-9.]+)M", swapusage)
m_total = re.search(r"total = ([0-9.]+)M", swapusage)
swap_used_mb = float(m_used.group(1)) if m_used else 0.0
swap_total_mb = float(m_total.group(1)) if m_total else 0.0
swap_used_gb = swap_used_mb / 1024.0
swap_total_gb = swap_total_mb / 1024.0
mp_out = sh(["memory_pressure"])
p1 = mp_out.find("tage:")
p2 = mp_out.find("%", p1)
if p1 != -1 and p2 != -1:
free_pct = int(mp_out[p1 + 6:p2])
memory_pressure_percent = 100 - free_pct
else:
memory_pressure_percent = -1
la_out = sh(["sysctl", "-n", "vm.loadavg"])
m_la = re.search(r"([\\d.]+)", la_out)
loadavg_1min = float(m_la.group(1)) if m_la else 0.0
app_memory = vm["Anonymous pages"] - vm["Pages purgeable"]
wired = vm["Pages wired down"]
compressed = vm["Pages occupied by compressor"]
cached_files = vm["File-backed pages"] + vm["Pages purgeable"]
active = vm["Pages active"]
inactive = vm["Pages inactive"]
free = vm["Pages free"]
memory_used = app_memory + wired + compressed
available = free + inactive + cached_files
total_gb = hw_memsize * F_GB
now = datetime.datetime.now()
row = {
"timestamp": now.isoformat(timespec="seconds"),
"physical_gb": round(total_gb, 3),
"used_gb": round(memory_used * F_GB, 3),
"available_gb": round(available * F_GB, 3),
"app_memory_gb": round(app_memory * F_GB, 3),
"wired_gb": round(wired * F_GB, 3),
"compressed_gb": round(compressed * F_GB, 3),
"cached_files_gb": round(cached_files * F_GB, 3),
"active_gb": round(active * F_GB, 3),
"inactive_gb": round(inactive * F_GB, 3),
"swap_used_gb": round(swap_used_gb, 3),
"swap_total_gb": round(swap_total_gb, 3),
"memory_pressure_percent": memory_pressure_percent,
"loadavg_1min": round(loadavg_1min, 3),
}
log_dir = os.path.expanduser("~/memlog")
os.makedirs(log_dir, exist_ok=True)
machine_tag = get_machine_tag()
csv_filename = f"memory_log_{machine_tag}.csv"
csv_path = os.path.join(log_dir, csv_filename)
file_exists = os.path.exists(csv_path)
with open(csv_path, "a", newline="") as f:
writer = csv.DictWriter(f, fieldnames=row.keys())
if not file_exists:
writer.writeheader()
writer.writerow(row)このスクリプトを 30 秒ごとに実行することで、端末ごとの時系列ログを蓄積しました。例えばターミナルから実行する場合は、次のようにループで回せます。
while true; do
python3 ./memory_log.py
sleep 30
doneなお、アクティビティモニタの表示項目と完全に同じ内部値を直接取得しているわけではなく、一部は公開している情報からの近似値となります。
各ログ項目の定義
収集した各項目は以下の定義となります。以下の公開文書をあわせて読むとわかりやすいと思います。
physical_gb
端末に搭載されている物理メモリ容量です。M1 MacBook Airは8GB、iMac Pro(2017) は32GB、M5 Pro MacBook Proは64GBです。アクティビティモニタでの「物理メモリ」と同等です。
used_gb
使用中メモリの近似値です。app_memory_gb + wired_gb + compressed_gb として算出しています。アクティビティモニタでの「使用済みメモリ」と同等です。
available_gb
新しいアプリやタブを開く余地の近似値です。free + inactive + cached_files をベースに計算しており、単純な空きメモリよりも、実際に使い回せる余力に近い指標として扱っています。
app_memory_gb
アプリが主に利用しているメモリの近似値です。ユーザーが開いているブラウザ、Slack、PowerPoint、Zoom などの利用量が主にここへ現れます。アクティビティモニタでの「アプリメモリ」と同等です。
wired_gb
OS やシステム動作に必要で、すぐには解放されないメモリです。アクティビティモニタでの「確保されているメモリ」と同等です。こちらは今回の記事では直接触れておりません。
compressed_gb
物理メモリが逼迫した際に、RAM 内で圧縮して保持しているメモリ量です。ここが大きいほど、OS がメモリを節約しながら耐えている状態と見なせます。アクティビティモニタでの「圧縮」と同等です。
cached_files_gb
ファイルキャッシュとして使われているメモリ量です。必要になれば解放しアプリに割り当てるため単純な「消費済み」とは異なります。アクティビティモニタでの「キャッシュされたファイル」と同等です。こちらは今回の記事では直接触れておりません。
active_gb / inactive_gb
最近使われているページと、直近ではあまり参照されていないページの量です。今回の記事では扱いませんでしたが、メモリの使われ方の補助情報として取得しています。
swap_used_gb
物理メモリに収まりきらずスワップ領域へ退避されたメモリ量です。ここが増えるほど、メモリ不足傾向が強くなります。アクティビティモニタでの「スワップ使用領域」と同等です。
swap_total_gb
OS が確保しているスワップ領域の総量です。一度確保したスワップ領域は通常は即時開放しないため、参考情報扱いです。 こちらも今回の記事では直接触れておりません。
memory_pressure_percent
memory_pressure コマンドの値（圧縮、スワップ、メモリ空き容量の総合指標）をもとにした、システム全体のメモリ逼迫度です。値が低いほど余裕があり、高いほど圧縮やスワップに頼っている状態を示します。アクティビティモニタでの「メモリプレッシャー」グラフに相当します。負荷が高まると緑〜黄色〜赤と変化します。
今回の比較では最も重要な指標です。
もう少し補足しますと、memory_pressure コマンドが返す system-wide memory free percentage というシステム全体でみた空きメモリ率を反転したものです。非公式な見解ではありますが、ほぼ一致している動きだったため採用しています。
https://apple.stackexchange.com/questions/423717/is-there-a-command-line-tool-that-accurately-describes-the-amount-of-used-memory
loadavg_1min
1 分平均の CPU load average です。CPU 使用率そのものではありませんが、短時間にどれだけ CPU 実行待ちが発生しているかを見る目安として利用しています。今回はメモリ起因の重さと CPU 起因の重さを切り分ける補助指標として参照しています
検証端末情報
M5 Pro MacBook Pro 64GB
まずはM5 Pro搭載MacBook Pro 64GBです。
ノートブックモデルとして非常に高性能であり今回のシナリオではスペック上かなり余裕のある構成です。
iMac Pro(2017) 32GB
続いてiMac Pro(2017) 32GB です。
2017年の超高性能機で、27インチ5Kディスプレイ（5120x2880）、10Gbitイーサネット、CPUにIntel Xeon W-2140B（8コア16スレッド）、GPUにRADEON Pro Vega 56、メモリ32GBという贅沢構成です。5KディスプレイはStudio Display、10GbitイーサネットはMac Studioにしかなく、現在でも特異点のような機種です。
M1 MacBook Air 8GB
最後にM1 MacBook Air 8GBです。
登場時には非常に高く評価されたM1プロセッサ搭載のMacBook Airです。今回のシナリオに対してどこまで実用的かを見極めます。
検証結果
端末起動後に操作手順に従って操作し、memory pressure、available memory、used memory、app memory、compressed memory、swap usedの変化について折れ線グラフでまとめました。
実は一つ大きなミスをしており検証操作作業の時間軸が全く揃っていません。イベントタイミングは以下の通りです（手記録なのでブレあり）。折れ線の変化の大きい部分がずれているのはそういった理由です。この点については見難い結果になっていてごめんなさい・・・。
| 操作 | M5 Pro MacBook Pro (64GB) | iMac Pro(2017) (32GB) | M1 MacBook Air (8GB) |
|---|---|---|---|
| ターミナルから負荷計測スクリプトを実行開始 | 0:00 | 0:00 | 0:00 |
| Slackを起動 | 2:00 | 2:00 | 1:00 |
| Chromeブラウザを起動しSpeedometer 3.1 を実行（1回目） 業務用SaaS一式を開く | 10:00 | 7:00 | 4:00 |
| 新規タブでSpeedometer 3.1 を実行（2回目） | 11:00 | 9:00 | 5:00 |
| ローカルのPowerPoint 資料をPower Pointデスクトップアプリで開く | 13:00 | 10:00 | 6:00 |
| Zoomを起動し、ローカルのPowerPoint資料を画面共有 | 16:00 | 13:00 | 10:00 |
| 新規タブでSpeedometer 3.1 を実行（3回目） | 17:00 | 15:00 | 13:00 |
| ブラウザで業務用SaaS一式を開く（2セット目） | 20:00 | 17:00 | 15:00 |
| 新規タブでSpeedometer 3.1 を実行（4回目） | 21:00 | 19:00 | 16:00 |
| ブラウザで業務用SaaS一式を開く（3セット目） | 23:00 | 23:00 | 19:00 |
| 新規タブでSpeedometer 3.1 を実行（5回目） | 25:00 | 26:00 | 22:00 |
| 完了 | 26:00 | 27:00 | 23:00 |
Memory Pressure（%）
| 端末 | 最低値（%） | 最高値（%） |
|---|---|---|
| M5 Pro MacBook Pro (64GB) | 5 | 9 |
| iMac Pro(2017) (32GB) | 9 | 15 |
| M1 MacBook Air (8GB) | 27 | 73 |
M1 MacBook Airは起動直後から27%とやや高い水準で、Chromeブラウザで業務SaaS一式を開いた直後に70%近い高負荷状態となり以降ずっと高止まりしています。スワップを駆使しながらなんとかやりくりしている状況です。比べて他の2機種は全く余裕です。
Available Memory（GB）
| 端末 | 最低値（GB） | 最高値（GB） |
|---|---|---|
| M5 Pro MacBook Pro (64GB) | 46.3 | 58.9 |
| iMac Pro(2017) (32GB) | 19.0 | 30.3 |
| M1 MacBook Air (8GB) | 1.7 | 5.4 |
起動直後で3〜5GB前後利用している状況です。そこから負荷をかけるごとに減少しますが、M1 MacBook AirはChromeブラウザで業務SaaS一式を開いた直後でもう物理メモリの余裕はなくファイルキャッシュを削りスワップを増やしメモリ圧縮を行いながら空きメモリを2GB程度確保しようとしています。他の2機種は余裕がある状態です。
Used Memory（GB）
| 端末 | 最低値（GB） | 最高値（GB） |
|---|---|---|
| M5 Pro MacBook Pro (64GB) | 9.0 | 34.4 |
| iMac Pro(2017) (32GB) | 8.5 | 26.7 |
| M1 MacBook Air (8GB) | 4.7 | 6.6 |
M5 Pro MacBook ProとiMac Pro(2017)は物理メモリに余裕があるためどんどんメモリを使っています。iMac Pro(2017)は最終盤で物理メモリを使い切りメモリ圧縮が発生しています（後述）。
M1 MacBook AirはChromeブラウザで業務SaaS一式を開いた直後からもう使える物理メモリがありませんので6.6GBで張り付いています。
App Memory（GB）
| 端末 | 最低値 | 最高値 |
|---|---|---|
| M5 Pro MacBook Pro (64GB) | 6.6 | 29.4 |
| iMac Pro(2017) (32GB) | 5.9 | 22.2 |
| M1 MacBook Air (8GB) | 1.3 | 2.8 |
M5 Pro MacBook ProとiMac Pro(2017)は物理メモリに余裕があるためどんどんメモリを使っています。iMac Pro(2017)は最終盤で物理メモリを使い切りメモリ圧縮が発生しているので22GBで上限となります。
一方でM1 MacBook AirはChromeブラウザで業務SaaS一式を開いた直後ですでに物理メモリを使い切ってスワップや圧縮などで対処し始めており、以降は1.5GB前後でずっと張り付いたままです。
Compressed Memory（GB）
| 端末 | 最低値 | 最高値 |
|---|---|---|
| M5 Pro MacBook Pro (64GB) | 0.0 | 0.0 |
| iMac Pro(2017) (32GB) | 0.0 | 1.5 |
| M1 MacBook Air (8GB) | 0.8 | 3.5 |
M5 Pro MacBook ProとiMac Pro(2017)は物理メモリに余裕があるためメモリ圧縮に頼るケースは限定的です。iMac Pro(2017)は2セット目の業務SaaSタブ追加で物理メモリを使い切りメモリ圧縮が発生しています。3セット目で1.5GB程度になりました。
一方でM1 MacBook Airは起動直後から圧縮が1GB程度発生しています。Chromeブラウザで業務SaaS一式を開いた直後で3.5GBに到達し、以降は変動しながら3−3.5Gを保っています。メモリ圧縮とスワップ退避を高頻度で行っていることがわかります。
Swap Used（GB）
| 端末 | 最低値 | 最高値 |
|---|---|---|
| M5 Pro MacBook Pro (64GB) | 0.0 | 0.0 |
| iMac Pro(2017) (32GB) | 0.0 | 0.0 |
| M1 MacBook Air (8GB) | 0.0 | 7.2 |
締めはスワップ容量です。M5 Pro MacBook ProとiMac Pro(2017)は物理メモリに余裕があるため最後まで0GBでした！
一方でM1 MacBook AirはChromeブラウザで業務SaaS一式を開いた直後でからスワップが発生し、以降は基本的に右肩上がりです。大きく跳ね上がるのはタブ一式の追加タイミングです。
SpeedoMeter 3.1
| 回数 | M5 Pro MacBook Pro (64GB) | iMac Pro(2017) (32GB) | M1 MacBook Air (8GB) |
|---|---|---|---|
| 1回目 | 45.9 | 13.2 | 26.3 |
| 2回目 | 41.5 | 12.2 | 22.2 |
| 3回目 | 37.8 | 10.8 | 15.6 |
| 4回目 | 29.2 | 10.6 | 13.3 |
| 5回目 | 26.7 | 9.64 | 10.8 |
こちらはCPU世代がものをいうこともあり、intelMacには厳しいようです。M1とM5 Proでのスコアの下落傾向は似ているのですが、M5 Pro(42%)よりM1(59%)のほうが下落率が高いです。これがメモリ容量差によるものかは正直判断できないと考えています。
loadavg_1min
| 端末 | 最低値 | 最高値 |
|---|---|---|
| M5 Pro MacBook Pro (64GB) | 1.2 | 12.3 |
| iMac Pro(2017) (32GB) | 2.8 | 30.4 |
| M1 MacBook Air (8GB) | 2.4 | 112.8 |
CPU実行待ちが多い＝CPU負荷が高い状況となりますが、起動直後については計測タイミングによるため無視しても良いです。CPUフル稼働しているようなシナリオでないことが裏付けられました。
CPU性能があるに越したことはないですが、今回のシナリオではM1で不足していることはなくA18 ProのMacBook Neoでも同様といえます。
検証結果まとめ
簡単に結論をまとめると、以下の通りです。
- M5 Pro MacBook Pro 64GB はさすがの余裕たっぷり
- iMac Pro(2017) 32GB は、最新世代ではないものの9年前のフラッグシップなだけありメモリ容量に余裕があり実用レベル
- M1 MacBook Air 8GB は動くがかなり限界に近い
今回想定している利用形態を前提にすると、8GBメモリは使い方で何とか誤魔化せる下限であり積極的に推奨できる構成ではないという結論です。
M1 MacBook Airは非常に評価の高い機種ですが、メモリ8GBですとタスクを絞れば一応使えるという評価です。しかし「まだ使える」と「余裕を持って業務できる」は違うのが他の機種と比較（特にiMac Pro(2017)）すると明白です。
結局どの指標見ればいいのか教えて？
たくさんの指標集めて結局わけがわからないってツッコミが聞こえてくるようです。当然ですね。結論言っちゃいますがこれはもうmemory_pressure_percent 一択です。
今回のようなスクリプトを実行せずともアクティビティモニタのメモリプレッシャーを観察していただき、日常的なワークロードで常時黄色(50%〜)になるのであれば物理メモリに余裕がない状態です。（これが言いたかった！）
結局メモリ8GB（MacBook Neo含む）は十分な容量なのか？
ここで冒頭のMacBook Neoに話を戻します。MacBook Neoはメモリ8GBで価格を抑えたエントリー機です。 ライトな用途ではM1 MacBook Airに近い使用感で実用的といわれることが多い一方、重いマルチタスクでは上位の MacBook AirやMacBook Proを選ぶべきという意見がよくみられます。
この文脈で今回のM1 MacBook Air 8GBの結果を見ると、業務利用でMacBook Neo＝メモリ8GBは十分かという見解は以下の通りとなります。
- ビデオ会議を利用しつつ、ブラウザ上の複数のSaaSを頻繁に切り替えながら業務する環境では8GBは十分な容量とは言えない。ブラウザ上での複数のSaaS同時利用はもうライトな用途ではない。
- 業務端末の標準構成として物理メモリ8GBは最低限レベルであり、今後数年利用する端末としては余裕が全く無い。
つまるところ「業務用途使えなくはないが、2026年の今勧められるものではない」ということになります。
どうしてこうなった？
Chromeブラウザの上で動くものが増えすぎたからです。
AsanaやNotion、GMailなどのリッチなWebアプリケーションは1タブ0.5GB〜とかなりのリソースを必要とします。メモリ8GBの機種ではタブを切り替える度にスワップ切り替えとメモリ圧縮が発生しますので、レスポンスの悪化も表面化します。
ブラウザでなくアプリ版を使えばいいのではという意見もありますが、アプリ版も内部はElectronやWebViewベースの実質ブラウザなので、多少は優位程度に留まります。
まとめ
M1 MacBook Air 8GBを「まだ使える」と言うことは全くその通りです。タスクを絞り、同時実行を抑え、ブラウザタブを管理し続ける前提であれば・・・・。しかし、業務端末としての標準を考えるなら、各ユーザーがタブやアプリの同時利用を気をつけながら工夫して使うことを期待するのはそろそろ厳しいです。
ナレッジワークはCPU性能よりもメモリ容量のほうが足枷になるため、MacBook Neoの8GBでは不足するでしょう。メモリ12GBのA19 Proを搭載した次世代機種が同じ価格だったら評価違うかもしれません。標準メモリ容量としては12GBか16GBは欲しくなりますが、今回はちょうどその容量の機種で検証できなかったのが残念です。
macOSであればアクティビティモニタの「メモリプレッシャー」に注視すれば十分です。今回は弊社のイメージする業務シナリオをもとに分析しましたが、それぞれの企業で標準アプリケーションや業務シナリオが異なります。実際に計測してみると標準端末の選定や更新で役にたつのではないでしょうか。
冒頭でも触れておりますが、弊社は従業員の働く場所や使用するネットワークやデバイスを指定せず従業員の生活に合わせてセキュアに仕事ができる環境を用意しています。興味あれば採用情報もご覧ください。
