宮崎翼 
まずは「現場でどれだけ書いているか」を見てください
弊社代表・宮崎の GitHub コントリビューションです。直近1年で 895 コミット。とくに 2026年3月以降は、ほぼ毎日コミットが積まれているのが見て取れます。
実は、ここまでの開発スタイルの大半は ブラウザ完結型のノーコード／ローコードでした。Bubble や FlutterFlow をメインに据えていた頃は、開発の重い処理はすべてクラウド側で走るため、手元のマシンスペックや容量は最小限で十分でした。社内でも「コーディング用PC＝そこそこのノートで足りる」が共通認識だったのです。
ところが、ここ数ヶ月で潮目が完全に変わりました。Claude Code や Cursor を主軸にした ローカルでの本格的なコーディング が増えてきて、画面の中で動いているプロセスの構成がガラッと変わったのです。AI エージェントが裏で走り続け、ローカルでビルドとテストが回り、Tauri のような重いランタイムを立ち上げる ―― この瞬間から、一定以上のマシンスペックがないと業務が回らないという現実に直面しました。
これは弊社だけの話ではありません。海外の AI 開発者コミュニティでも同じ結論に収束しつつあります。
「Cursor を複数の大きなファイルとエージェントセッションで動かすだけで、4〜8GB のメモリを消費する。これは 16GB ではなく 32GB を最低ラインとすべき本当の理由だ ―― ML コードのためではなく、開発環境そのものが要求している。」
―― The Honest Guide to Picking a Laptop for AI and ML Development（Medium）
「ChatGPT、Claude、Google Doc、スプレッドシート、Zoom を同時に開いているだけで、AI を本気で使う1日には 11〜21GB のメモリが必要になる。」
―― Best Laptops for Building AI Agents in 2026（David’s Blueprint）
「Docker コンテナと LLM を一緒に動かすつもりなら、32GB 未満のマシンは絶対に買うな。RAM こそが、AI エージェントを『集中状態』から『ストレスの源』に変える唯一のボトルネックだ。」
―― Best Laptop for AI Development: Powering Local LLMs in 2026
つまり「AI と対話しながらコードを書く時代」に必要なPCは、従来のコーディング用PCとは別物として再設計する必要があります。本稿はそのリアルな線引きを、弊社の実体験と海外の最新ガイドラインを突き合わせながら整理するものです。
はじめに
Claude Code、Cursor、GitHub Copilot、Codex CLI。生成AIに「対話しながらコードを書かせる」スタイル ―― いわゆる バイブコーディング (Vibe Coding) が、もはや一部のエンジニアの遊びではなく、業務の主戦場になりつつあります。
このとき多くの人が後回しにしがちなのが、手元のPCのスペックです。「IDE が動けば十分」「うちの会社支給ノートで足りるでしょ」と思っていると、いざ Claude Code に大規模な書き換えを任せた瞬間にメモリが枯渇してフリーズ、ARM 機でビルドが通らずに半日溶ける、ということが現実に起こります。
本稿では、自社プロダクト MarkShot（Tauri 製のスクリーンショットツール）を Windows ARM 機で動かそうとして詰まった実例を交えながら、バイブコーディングを業務でやるなら、PCをどう選ぶべきかを整理します。
結論を先に書きます。
- RAM は 32GB 以上（16GB は事実上アウト）
- Windows なら Intel/AMD（x64）を選ぶ。ARM Windows は現時点では避けるか、WSL 利用を前提に
- Mac は最も無難。Apple Silicon の単一アーキ＋Rosetta の出来が良い。ただし業務システム連携は別途検討
1. なぜ今「PCスペック」を考え直すか
ひと昔前なら「コーディング用PC = IDE が動く程度」で済みました。今は事情が違います。バイブコーディング中、あなたのPCの中では同時にこれだけ動いています。
- AI エージェント（Claude Code / Cursor）の常駐プロセス
- ローカルでビルド・テスト・型チェック
- ブラウザで複数タブ（ドキュメント・プレビュー・LLM のチャット）
- IDE（VS Code 等）＋拡張機能群
- ターミナル複数、Docker、ローカル DB
- 場合によってはローカル LLM（Ollama、LM Studio）
AI に指示を投げて待っている間、裏でリアルタイムにファイル読み込み・差分計算・LSP 解析が走るため、「重い処理が常駐し続ける」のがバイブコーディングの特徴です。従来の「人間がキーボードを叩いている瞬間だけ重い」モデルとは性質が違います。
2. 量販店の 16GB 機が「バイブコーディングに足りない」理由
家電量販店で並んでいるノートPCの主流は、いまだに メモリ 16GB です。これがバイブコーディングではほぼ確実に足りません。
実測ベースで、よくある内訳：
| 用途 | 使用メモリ |
|---|---|
| Windows + 常駐サービス | 3〜5GB |
| ブラウザ（タブ20個前後） | 4〜6GB |
| VS Code + 拡張 | 2〜3GB |
| Claude Code / Cursor のエージェント | 1〜2GB |
| ローカルビルド・テスト | 2〜4GB（ピーク時） |
合計で 12〜20GB。16GB マシンは常時 90% 超で、スワップが発生し始めます。AI に「このリポジトリ全体をリファクタしてくれ」と頼んだ瞬間、ファイル走査でメモリが跳ね上がり、エディタが固まる ―― という事故が起きます。
さらに困るのが「会議中」と「コミュニケーションツール常駐」
このあたりで追加で困るのが、Zoom や Google Meet でオンライン会議をしている最中に、AI エージェントを回すと落ちる現象です。会議の映像エンコード／デコードだけで 1〜2GB、加えて画面共有や Web カメラの処理が乗ると、すでに 16GB のマシンは余力ゼロ。そこに Claude Code の大規模リファクタを投げると、エージェント自体が OOM で強制終了するか、Zoom 側がカクついて相手に映像が届かなくなります。
同様に、Slack と Discord の同時立ち上げもかなり厳しい領域になってきました。両方とも Electron 製で、それぞれ 500MB〜1GB を恒常的に消費します。「商談は Zoom、社内は Slack、コミュニティは Discord、開発は Claude Code」という今どきの一人マルチタスクは、16GB ではもう成立しません。
実際、海外の開発者ガイドラインでも「ChatGPT、Claude、Google Doc、スプレッドシート、Zoom を同時に開くだけで 11〜21GB」と明記されており、これに加えて IDE と AI エージェントが乗ると、32GB ですら「ちょうどいい」レベルです。
バイブコーディング常用なら 32GB が最低ライン。本格的にローカル LLM も併用するなら 64GB を狙ったほうが幸せです。
3. 【実例】MarkShot を ARM Windows で動かそうとして詰まった話
ここからは弊社の自社ツール MarkShot（Tauri 2 製のスクリーンショット＆注釈ツール）を題材に、ARM Windows の落とし穴を具体的に共有します。
起きたこと
ARM 版 Windows 機に、用意していた x64 版インストーラ（MarkShot_2.0.8_x64-setup.exe）を入れたところ：
- インストール自体は成功（Windows on ARM の x64 エミュレーションが効く）
- しかし 編集画面の矢印（注釈ツール）が描画されない
- 「保存先パスをコピー」ボタンを押しても クリップボードに何もコピーされない
「動くけど、要所で壊れる」という最も厄介なパターンです。インストールが通るので Mac の Rosetta 的に「だいたい動くだろう」と判断してしまい、ユーザー側もアプリ開発者側も気づくのが遅れる。
原因と対応
原因を切り分けると、以下の複合要因でした。
- ARM 上の x64 エミュレーション環境では、Konva (Canvas 描画) のポインタ座標が取得できないタイミングがある →
stageRefベースのフォールバックを追加して回避 - Tauri 2 のクリップボード権限がデフォルトで空（セキュリティのため明示的に有効化が必要）→
capabilities/default.jsonにclipboard-manager:allow-write-textを追加 - 本来は ARM64 ネイティブビルドを別途配布すべき。Visual Studio Build Tools に「MSVC v143 ARM64 build tools」が必要。x64 機からクロスビルドする場合、これが入っていないと
libcmt.libが解決できずリンクエラー
教訓
- Windows アプリは x64 と ARM64 で別バイナリが必要（Tauri / Electron / 多くのネイティブアプリ共通）
- エミュレーションは「動く」が「正しく動くとは限らない」。Canvas / WebView / クリップボードといった低レイヤ依存部分で必ず落ちる
- 自分で作るときも、配布するときも、両アーキの実機検証を覚悟するか、ARM 機を切り捨てる判断が必要
これが「ARM Windows でのバイブコーディング」を勧めない第一の理由です。AI に書かせたコードがビルドは通っても、自分の手元で動作確認できない可能性がある。
4. Mac は「100%ではないが」優秀
ここまでの問題の多くを、Mac は構造的に回避しています。
- Apple Silicon (M1〜M4) で単一アーキに統一済み。x64 と ARM の二重ビルド地獄がない
- Rosetta 2 の出来が良い。Intel Mac 時代のアプリも実用速度で動く
- メモリ 16GB モデルでもユニファイドメモリの効率で、Windows 16GB より体感的に粘る（とはいえバイブコーディングなら 24GB / 32GB を推奨）
- 開発者ツール（brew、Docker、各種SDK）が ARM ネイティブで揃っている
ただし、100% の解決策ではありません：
- 業務システム（勤怠、会計、社内ポータル）が Windows 前提のケース
- Excel / PowerPoint のマクロ重視の運用
- 自社で配布する Windows アプリの動作確認 ―― 結局 Windows 機が別途必要
「個人として最も無難な選択肢」「ただし業務環境次第で Windows を捨てられないケースは多い」というのが現実的な評価です。
5. ARM Windows ユーザーの現実解 — WSL を使う
すでに ARM Windows 機を持っている人、これから Surface / Snapdragon X 系を買う予定の人は、WSL (Windows Subsystem for Linux) を主戦場にすることを強く勧めます。
理由：
- WSL 内は ARM64 ネイティブの Linux として動くため、エミュレーションのトラブルから解放される
- Claude Code、Cursor、Node.js、Python、Docker などのツール群は WSL 上で素直に動く
- VS Code の Remote-WSL 拡張で、ホスト側の VS Code から WSL 内のプロジェクトを編集できる
- 万一 Windows ネイティブ機能（クリップボード、ファイル選択ダイアログなど）が必要になっても、WSL ⇔ Windows の橋渡しは整っている
逆に、Windows ネイティブ側でバイブコーディングしようとすると：
- VS Code が x64 ビルドだとエミュレーション、ARM64 ビルドだと拡張機能の一部が動かない、というハマりが発生
- npm の native binding が x64 / arm64 の解決を間違える事故
- 弊社の MarkShot 開発で踏んだような、Canvas / クリップボード周りの不可解な挙動
「ARM Windows 機を買うな」とまでは言いませんが、買うなら WSL 前提でというのが安全な指針です。
6. 結論：バイブコーディング用 PC の推奨スペック
ここまでをまとめて、現時点（2026年5月）でバイブコーディングを業務でやる方への推奨スペックを示します。
Windows を選ぶ場合
| 項目 | 推奨 | 理由 |
|---|---|---|
| CPU | Intel Core Ultra 7 以上 / AMD Ryzen 7 以上（x64） | ARM は避ける。アプリ互換性のため |
| メモリ | 32GB 以上（できれば 64GB） | バイブコーディング常駐ワークセット 16GB 超 |
| ストレージ | NVMe SSD 1TB 以上 | リポジトリ＋node_modules / target で膨らむ |
| GPU | 統合GPU で可。ローカル LLM 常用なら RTX 4060 以上 | 通常用途では不要 |
Mac を選ぶ場合
| 項目 | 推奨 |
|---|---|
| モデル | MacBook Pro M4 Pro / Mac Studio M4 |
| メモリ | 32GB 以上（ユニファイドメモリの恩恵で 24GB でも可） |
| ストレージ | 1TB 以上 |
具体的なモデル例（2026年5月時点）
「で、結局どれを買えばいいの？」という方向けに、ここまでの基準を満たす市販モデルを 性格別 に挙げます。価格は時期で変動するため目安です。（2026/5時点）
【コスパ重視・GPU も欲しい】HP OMEN シリーズ
ゲーミング由来ですが、開発機としても非常に優秀。Ryzen AI 9 365 / 32GB / RTX 5070 構成が比較的手の届く価格（実勢 25〜30 万円台）で出ており、ローカル LLM（Ollama、LM Studio）を回したい人には GPU の恩恵が大きいです。冷却もしっかりしているので、Claude Code に長時間ぶん回しても安定。重量と電源依存があるので「持ち歩かない据え置き派」向け。
【携帯性とバランス】ASUS ZenBook シリーズ
ZenBook S 16 / ZenBook 14 OLED など、Intel Core Ultra 7 + 32GB の薄型ラップトップ。1.4〜1.5kg 前後で持ち歩け、OLED の発色とビルドクオリティで日々の作業満足度が高い。GPU は内蔵止まりなのでローカル LLM 用途には弱いですが、Claude Code / Cursor 中心の運用なら必要十分。客先を回るフリーランスや、家とカフェで開発する人にバランスが良い選択です。
【NPU は魅力／ただし ARM がネック】Surface Laptop（Snapdragon X Elite）
Snapdragon X Elite は 45 TOPS の NPU を搭載し、Copilot+ PC 統合は確かに魅力です。バッテリー持ちも飛び抜けています。ただし本記事の主旨どおり、ARM Windows ゆえに開発機としては地雷を踏みやすい点に注意。VS Code 拡張、npm の native binding、Tauri/Electron 系アプリの動作確認 ―― いずれも追加コストが発生します。さらに 同等メモリの x64 ノートと比べて割高感も否めません。「NPU を使うアプリを業務で開発する」「Copilot+ 機能を前提に提案する」など明確な理由がない限り、ファーストチョイスにはしづらいのが正直なところ。買うなら WSL 前提＋業務システムが ARM 互換であることを必ず確認してから。
【王道・無難】MacBook Pro M4 Pro / MacBook Air M4
迷ったらこれ。Apple Silicon 単一アーキ、Rosetta、開発者向けエコシステムが最も整っています。MacBook Pro M4 Pro 32GB 構成で 30 万円〜と決して安くはありませんが、二重ビルド地獄に縁がなく長く使えるのが最大の価値。MacBook Air M4 24GB なら 20 万円台前半に収まり、軽作業＋外回りメインなら十分。
【ビジネス寄り】Lenovo ThinkPad X1 Carbon / Dell XPS 15
社内 IT 部門のサポートや法人保守を重視するなら、この 2 系統が定番。x64 Intel/AMD で 32GB 構成が確実に選べること、キーボードの打鍵感、修理ネットワークの厚さで評価が安定しています。「上司に説明しやすい」枠としても優秀。
| シリーズ | 向いている人 | 注意点 |
|---|---|---|
| HP OMEN | ローカル LLM・据え置き重視 | 重い／電源必須 |
| ASUS ZenBook | 持ち歩き＋AI コーディング中心 | GPU 内蔵のみ |
| Surface Laptop（Snapdragon） | NPU 用途が明確な人のみ | ARM Windows／割高 |
| MacBook Pro M4 Pro | 長期投資・無難に強い人 | 業務システム要件次第 |
| ThinkPad X1 / Dell XPS | 法人サポート重視 | 尖りには欠ける |
ARM Windows をすでに持っている人
- まず WSL2 をセットアップして、開発作業はすべて WSL 内で完結させる
- ARM ネイティブの Windows アプリ開発をする場合だけ、ホスト側で作業
- VS Code は Windows 側にインストールし、Remote-WSL で接続
まとめ
- バイブコーディングは「常時複数の重い処理が同居する」新しい開発スタイル
- 16GB は結構きつい、32GB が実質ライン
- Windows は Intel/AMD (x64) を選ぶ。ARM は WSL 経由で
- Mac は構造的に無難。ただし業務環境の制約は別問題
- アプリ開発側にも責任あり ―― x64 / ARM64 を両方ビルドして配布する覚悟が必要
弊社では Tauri 製のスクリーンショットツール MarkShot をはじめ、自社ツールを ARM / x64 両対応で開発をがんばっていきます！
