すべての開発者が一度は耳にしたことがあるはずです。それは、深夜2時に歯を食いしばりながら呟かれる、「自分のマシンでは動くんだ」という言葉です。ローカルでのビルドは通るのに、ステージング環境で崩壊するとき、私たちは本能的にフレームワークのバージョンや、環境変数の不足、あるいはDockerそのもののせいにしがちです。しかし、認めがたいことかもしれませんが、実際にはオペレーティングシステム（OS）こそが真の犯人であることが多いのです。ファイルパス、システムコール、パッケージマネージャー、そしてカーネルの挙動。これらすべてがコードの実行方法を決定づけます。適切なOSを選ぶということは、単にどの「派閥」に属するかということではありません。それは、あなたのノートPCと本番環境との間にある摩擦を取り除くことなのです。

Windows: ジェネラリスト

Windowsがデフォルトであり続けているのには、単純な理由があります。それは、ハードウェアがそのまま動くからです。周辺機器を接続すれば、おそらくドライバーが存在します。.NETエコシステムで働く開発者にとって、Visual Studioは今でもゴールドスタンダードです。IntelliSense、デバッグツール、プロジェクトのスカフォールディングは、このプラットフォーム向けに構築されているため、ネイティブであるかのように感じられます。

Windows Subsystem for Linux 2 (WSL2) の登場により、MicrosoftはWindowsとUnixベースのワークフローの間の隔たりを大きく埋めました。WSL2は軽量なユーティリティVM内で本物のLinuxカーネルを実行するため、デュアルブートすることなく、bashを呼び出し、aptを使用し、Ubuntuを実行できます。その統合は非常にスムーズで、多くの開発者が自分がネイティブなLinux環境にいないことさえ忘れてしまうほどです。

しかし、この抽象化には限界があります。Windows上のDocker Desktopは、エンジンとしてLinux VMに依存しており、Windows NTカーネルとLinuxコンテナ間のファイルシステムの変換によってレイテンシが発生します。巨大な node_modules ディレクトリのマウントや、ボリューム内でのコンパイルといったI/O負荷の高い操作は、ベアメタルLinuxに比べて明らかに遅くなります。また、Windows Updateは作業の途中でマシンを再起動してしまう傾向があり、デバッグ作業に没頭しているときには理想的ではありません。

Windowsは、学生、ゲーマー、そして.NETアプリケーションをリリースするエンジニアにとって輝かしい選択肢です。業務時間中はVisual Studioを使い、時間外にはSteamで遊べる一台が必要なら、これが現実的な選択です。

Linux: サーバーの標準

本番環境がLinuxで動いているなら、Linux上で開発することで予期せぬ事態を排除できます。このOSはサーバー向けに構築されており、その設計思想はクラウド環境が求めるものと一致しています。「すべてをファイルとして扱う」というUnixの哲学により、設定、ハードウェアデバイス、実行中のプロセスはすべてファイルシステムツリーのどこかに存在します。この一貫性により、自動化が容易になります。bashでデプロイをスクリプト化し、systemdでサービスを管理し、2つの異なるカーネルアーキテクチャ間での変換を意識することなくコンテナをオーケストレーションできます。

DockerはLinuxのプリミティブに基づいて構築されています。Namespacesやcgroupsはここではネイティブな機能であるため、コンテナの起動は速く、他のプラットフォームよりもベアメタルに近い速度で動作します。オーバーヘッドは最小限で、パッケージマネージャーは成熟しており、システムを必要なものだけに削ぎ落とすことも可能です。ヘッドレスなLinuxサーバーであれば、再起動なしで数年間稼働させることもできます。

トレードオフは、デスクトップとしての洗練さです。商用ソフトウェアのサポートは一歩遅れています。Adobe Creative Cloudのネイティブアプリは見つかりませんし、一部のプロプライエタリなIDEやコラボレーションツールには回避策が必要になることもあります。ハードウェアのセットアップには忍耐が必要な場合もあります。Wi-Fiカード、Bluetoothアダプター、ハイブリッドグラフィックスなどは、手動でのドライバーインストールやカーネルモジュールの調整を必要とすることがあります。NVIDIAのドライバーは大幅に改善されましたが、CUDAを正しく設定するには、依然としてターミナルの扱いに慣れていることを前提としたドキュメントを読み込む必要があります。

バックエンドエンジニア、DevOps担当者、そしてAIインフラを構築するすべての人にとって、Linuxはデフォルトとして扱うべきものです。本番環境がUbuntuやRHELで動作している場合、ローカルでそれをミラーリングしておくことで、デプロイ時のデバッグに費やす時間を大幅に節約できます。

macOS: 洗練されたUnix

macOSは、Linuxのように振る舞うターミナルと、コンシューマー製品のように振る舞うGUIの両方を求める開発者にとって、理想的な中間的な立ち位置にあります。内部的には認定されたUnixオペレーティングシステムであるため、bash、zsh、make、ssh、gitなどはすべて、サーバー上で期待される通りに動作します。Apple Siliconの登場により、その計算式は完全に変わりました。Mシリーズチップは、ノートPCのバッテリー駆動時間を10〜20時間という範囲に保ちながら、デスクトップクラスのパフォーマンスを提供します。ファンを回すことなく、プロジェクトをコンパイルし、ローカルスタックを実行し、ビデオ通話を行うことができます。

モバイル開発者にとって、macOSは譲れない選択肢です。XcodeとiOSシミュレータはApple製ハードウェアでしか動作しません。また、このエコシステムはクリエイティブなワークフローやフルスタックのワークフローにも適しています。トラックパッドとディスプレイは極めて優秀であり、スリープ/復帰の信頼性が高いため、蓋を開ければすぐに作業を再開できます。

デメリットはコストと柔軟性です。カスタムPCやThinkPadであれば容易に行えるメモリやストレージのアップグレードに対して、割高な料金を支払うことになります。ハードウェアのラインナップも限られています。ローカルでのモデル学習のために特定のGPUが必要だったり、実験機器のために特殊なポートが必要だったりする場合、Macでは外付けエンクロージャやドングルなしでは対応できない可能性があります。

ポータビリティを重視するフルスタック開発者、iOSエンジニア、スタートアップの創業者などは、しばしばこちらに惹かれます。高価な選択肢ではありますが、日々の摩擦を最小限に抑えられる選択肢でもあります。

AIにとってOSは重要か？

モデル自体はOSを問いません。Ollama、LM Studio、または vLLM を介して実行される大規模言語モデルは、カーネルが Microsoft、Linus Torvalds、または Apple によってコンパイルされたものであっても、同じトークンを生成します。重要なのはOSよりもツールです。AIエージェントを構築する際は、Python の依存関係管理、Node.js のランタイム、再現可能な環境のための Docker、API 連携、そしてコンテキストウィンドウのためのメモリ管理の習得に集中してください。

とはいえ、プロダクション環境のAIシステムは圧倒的に Linux 上で動作しています。NVIDIA のデータセンター向け GPU ドライバーや CUDA toolkit は、まず Linux 向けに開発・最適化されます。グラフィカルなデスクトップのオーバーヘッドが取り除かれることで、学習や推論により多くの VRAM と CPU サイクルを割り当てることができます。クラウドコンピューティングをレンタルしている場合、ほぼ間違いなく Linux インスタンスに SSH で接続しているはずです。ローカルでの実験においては、Apple Silicon を搭載した MacBook は静かで電力効率も高いですが、いざ...で学習を行うときには