本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第5弾として、OS選定について解説する記事です。
サーバーOSは選定のやり直しが最も効かない領域で、アプリ・ミドルウェア・運用スクリプト・監視ツール・人材の全てがOSに紐づいています。10年先まで背負う相手を選ぶ覚悟が要る決定です。本記事ではLinux／Windows Server／商用UNIXの3系統、ディストリビューション選定、EOL管理、CPUアーキテクチャ（x86/ARM）まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『Linuxのしくみ 増補改訂版』・『ゼロからのOS自作入門』も参考にしてみてください。
この記事の結論
- 新規LinuxはUbuntu LTS / Amazon Linux / RHEL系の3択
- Windows ServerはMicrosoft基盤との統合時のみ
- ARM64（Graviton等）の検討を必須にする（コスト20〜40%減）
- EOLが運用期間+2年以上あるバージョンを選び、パッチ適用を自動化する
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもOS選定とは何か
OS選定とは、ざっくり言えば「サーバーの土台となる基本ソフトをどれにするか決めること」です。
家の基礎工事を想像してください。木造（Linux）・鉄骨（Windows Server）・鉄筋コンクリート（商用UNIX）で建て方も使える工具も全く違います。基礎を打った後に「やっぱり鉄骨にしたい」と思っても、一度建てた家を壊して作り直すしかありません。サーバーOSも同じで、一度選ぶと10年単位で付き合うことになります。
なぜOS選定が重要なのか
もしOS選定を軽く考えたらどうなるか。コード・運用スクリプト・監視ツールが特定OS向けに書かれた後では、別OSへの移行は実質作り直しです。「とりあえず使い慣れたもので」という決め方をすると、10年後にチーム全員がそのOSから動けなくなり、技術選定の柔軟性を失います。
現在の新規プロジェクトで本当に迷うのはLinuxディストリビューションの選び方とARMを入れるかどうかの2点にほぼ絞られます。OSは後から変えられない土台であり、プロジェクト計画時に決め切るのが鉄則です。
主な選択肢
サーバーOSの主要選択肢は以下の3系統です。新規案件の大多数はLinux、Windows Serverは特定用途、商用UNIXは既存保守のみ、というのが2026年の実情です。
| OS | 主な用途 | 現在の位置づけ |
|---|---|---|
| Linux | Webサーバー・アプリサーバー・コンテナ基盤 | 圧倒的多数 |
| Windows Server | Active Directory・.NET・Office連携 | 特定用途で残る |
| UNIX（AIX / Solaris等） | 金融・基幹の旧来大規模システム | 新規ではほぼ消滅 |
Linux ― 迷ったらここから
LinuxはオープンソースのUNIX互換OSで、クラウドの仮想マシン・コンテナ・スーパーコンピューターの基盤として圧倒的なシェアを握っています。無償で軽量、コンテナ・クラウドとの親和性が極めて高く、「迷ったらLinux」が現代の鉄板です。
配布形態であるディストリビューションの主役は3つです。開発者フレンドリーで情報量最大のUbuntu LTS（5年サポート、スタートアップ・自社開発の本命）、AWS上で使うならAmazon Linux 2023、エンタープライズで商用サポートが必要ならRHEL（年間数十万円〜のサブスク費で障害時にRed Hatへ問い合わせできる安心を買う）。RHEL相当を無償で使いたい場合はRocky Linux / AlmaLinuxが後継の定番です。ほかにコンテナ用超軽量のAlpine、SAP基盤のSUSEもありますが、該当する用途が出てから検討すれば十分です。
なお本格的にKubernetesを運用するなら、SSHを許さずAPIだけで管理するコンテナ特化OS（AWSのBottlerocket、Talos Linux等）も選択肢に入ります。
Windows Server ― Microsoft基盤統合が必須な場面だけ
Windows Serverは、Active Directory（Microsoftの統合認証基盤）・既存の.NET業務アプリ・Office / SharePoint連携を中心に構築する企業では依然として第一候補です。GUI運用が容易でMicrosoft製品との互換性は完璧ですが、ライセンス費が高額で、コンテナエコシステムもLinuxに劣ります。新規のクラウドネイティブWebアプリで「なんとなく」選ぶと、ライセンス費が積み上がるだけの筋の悪い選択になります。
商用UNIX ― 既存保守の継続のみ
商用UNIX（IBMのAIX、HP-UX、Solaris）は、数年間ノンストップ稼働の実績を持つ高信頼OSですが、専用ハードウェア前提で保守費が年間億単位になることもあり、スキル人材も高齢化・減少しています。新規案件で選ばれることはほぼなく、大半は「既存の基幹システムを保守しながら、徐々にLinuxへ移行する」フェーズに入っています。
CPUアーキテクチャ ― ARM64の検討は必須
OSと並行して重要なのがCPUアーキテクチャの選定です。従来はx86_64が圧倒的でしたが、AWS Graviton（ARM64）は同等性能のx86インスタンスと比較して20〜40%安価で動きます。Webサーバー・Javaアプリ・各種マネージドサービス（RDS・ElastiCache等）がGraviton対応しており、新規構築でARMを検討しないのは機会損失です。ただしx86からの移行は、JVM・ネイティブモジュール・DockerイメージのARM対応状況が個々に違うため、結合テスト・本番相当負荷での確認が必須です。
どう選べばいいのか ― 規模別の3シナリオ
個人開発・スタートアップなら ― Ubuntu LTS+ARM64
Ubuntu LTS（またはAmazon Linux）+ARM64の組み合わせが本命だと思います。学習教材とAIの生成精度で情報量が最大のディストリを選んで、Gravitonでクラウドコストを2〜4割下げる形です。ライセンス費はゼロで済みますし、サポートはコミュニティと情報量でカバーできてしまいます。
中小SaaSなら ― 同じ3択+パッチ自動化
OSの選択自体はスタートアップと同じ3択ですが、この規模で効いてくるのは運用です。毎月のCVEパッチ適用をAWS Systems Manager Patch Manager等で自動化し、CriticalなCVEは72時間以内の適用をルール化します。コンテナ中心ならホストOSをBottlerocket等に寄せて、攻撃面そのものを減らす選択も有効です。
大企業なら ― 商用サポートと既存資産で決まる
金融・官公庁・大企業の基幹系はRHELの商用サポートが定番です。Active Directory中心の認証基盤や.NET資産があるならWindows Serverを併用し、既存の商用UNIXは保守継続しながら段階的なLinux移行を計画します。OSの種類が増えるほど運用・監査コストが積み上がるため、「標準OSを社内で3つ以内に絞る」ような統制も効きます。
AI判断軸 ― 学習データ量とコマンドの標準性
AI駆動開発が前提になると、OS選定における「エンジニアの慣れ」の重要性が下がり、代わりに「AIの学習データ量」と「コマンドの標準性」が中心になります。
Ubuntu / Amazon LinuxはAIの生成精度が高い
AIにシェルスクリプトやsystemdのユニットファイルを書かせた場合、Ubuntu LTSやAmazon Linux 2023をターゲットにすると精度が高くなります。apt/dnfのパッケージ名、設定ファイルのパス、サービスの起動方法が学習データに大量に含まれているためです。逆にRHEL系のマイナーバージョン差異（SELinuxポリシー、firewalldのゾーン設計）や商用UNIXのコマンド体系は学習データが薄く、AIが一般的なLinux知識で推測した結果、動かないコードを生成するケースがあります。
GUI運用かコード運用かがAI活用の可否を分ける
Windows ServerをGUIで管理する運用は、設定変更が画面操作として記録されないため、AIによる構成レビューや自動化の対象外になります。同じWindows ServerでもPowerShell DSCやAnsibleで構成管理していればコードとしてAIが読み書きできます。OSの種類そのものより、「構成がコードで表現されているか」がAI時代の分水嶺です。
EOL管理 ― 選んで終わりではなく10年間の運用が本番
EOL（End of Life）とは、OS開発元がセキュリティパッチの提供を終了するタイミングです。EOL後のOSは脆弱性が修正されず、継続利用は重大なセキュリティリスクになります。目安として、RHEL 9は2032年、Ubuntu 24.04 LTSは2029年（Pro延長で2036年）、Amazon Linux 2023は2028年までサポートされます。プロジェクトの運用期間+2年以上の余裕があるバージョンを選ぶのが鉄則です。
※ 2026年4月時点の情報です。
| フェーズ | 何をやるか |
|---|---|
| 選定（計画時） | EOLが運用期間+2年以上あるか確認する |
| パッチ運用（〜EOL 2年前） | 月次のCVEパッチ適用を自動化、Criticalは72時間以内 |
| 移行検討（EOL 2年前） | 次期LTSの検証環境を立てる |
| 本番移行（EOL 1年前） | Blue-Greenで移行、3〜6ヶ月の並行稼働 |
| 旧OS停止（EOL到達時） | 確実に停止し、脆弱性サーバーを残さない |
EOL後のOSをそのまま使い続けるのは、Equifax 2017年の事件（Apache Strutsの既知脆弱性を放置し1.47億人の個人情報が流出）と同じ構造の地雷です。セキュリティパッチは「機能追加しない更新」だからこそ、自動化して継続適用します。
やってはいけないこと
OS運用で事故が集中するポイントを6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| パッチを本番で一気に適用 | カーネルパッチの副作用でミドルウェアが起動しない事故が定番 → Blue-Green・Canaryで段階適用する |
| EOL直前・ロードマップ不安なOSを採用 | CentOS 8のように発表1つで移行を迫られる → EOLと後ろ盾の信頼性を確認する |
本番で apt upgrade を対話実行 | バージョン固定なし・ロールバック手順なしでは戻せない事故になる → 構成管理ツール経由で更新する |
| x86→ARM移行を単体テストだけで判断 | JVM・ネイティブモジュールのARM対応状況が個々に違う → 結合テスト+本番相当負荷で確認する |
| OS更新を年1回まとめて実施 | 差分が大きすぎて問題の切り分けが不能になる → 月次・四半期で刻む |
| 「なんとなく」でWindows Serverを選ぶ | ライセンス費が積み上がる → Microsoft基盤統合が必須な場面に限定する |
筆者メモ ― CentOS 8の一件
CentOS 8を採用して開発を進めていたところ、2020年12月に突然「2021年末でサポート終了」と発表され、当初2029年まで使えるはずのプロジェクトが約1年で移行を迫られた──国内でも大量に発生した事例です。あるSIerでは、既に数十サイトに展開したCentOS 8を全てRocky Linuxに差し替えるためだけに、数カ月の計画外作業と数千万円規模のコストが乗ったといいます。
教訓はシンプルで、「OSSだからといってロードマップの信頼性まで同じではない」ということです。無償ディストリでも「後ろ盾は誰か」「過去にEOLを動かした前科はあるか」を確認してから選ぶ、という防衛線を敷いておくべきです。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- OS種別（Linux / Windows / UNIX）
- ディストリビューション（RHEL系 / Debian系 / その他）
- バージョンとEOL年月
- CPUアーキテクチャ（x86_64 / ARM64）
- ライセンス契約（無償 / 有償サブスク / 商用）
- パッチ適用方針（手動 / 自動 / Blue-Green）
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はOS選定について、Linux/Windows/UNIXの比較、ディストリビューション、EOL管理、ARMアーキテクチャまで解説しました。如何だったでしょうか。
新規LinuxはUbuntu LTS / Amazon Linux / RHEL系の3択。Windows ServerはMicrosoft基盤統合時のみ。商用UNIXは既存保守継続のみ。CPUはARM64の検討が必須。これが2026年の現実解です。
次回は「データストア」（システムアーキテクチャレベルでのデータ配置の全体方針）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は The Linux Foundation も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（16/95）