まずOSの定義は一枚岩ではない。

その上で、繰り返し言及される“核”は次の3点です

Intermediary：OSはユーザ（／ユーザプログラム）とハードウェアの間に入る。

Resource allocator / Control program：資源を管理し、競合要求を裁き、誤用やエラーを防ぐ。

Kernel と境界：常時動く中核が kernel で、周辺のシステムプログラム等を含めた境界は揺れる。

OSの作業定義はこう書けます：

OS =（1）資源の抽象化／仮想化 +（2）多重化・保護・制御 +（3）それらを使うための安定したインタフェース

「LLMはOS」は “カーネルの置き換え” ではなく “新しい資源集合に対するOS層” だ

ここで言う「LLM」は単体モデルではなく、現実に使われる LLM＋ツール呼び出し＋メモリ（RAG/DB）＋ポリシー＋ログを含む実行基盤（ランタイム）です。

このランタイムが扱う“資源”は CPU ではなく、例えば：

検索、DB、リポジトリ、チケット、メール、カレンダー、各種SaaS、社内API、実行環境（コード／ワークフロー）

そして重要なのが、対話の文脈（context）とコスト（時間・回数・課金）

要するに、いま多くのユーザの実務における計算は「単一マシンのハードウェア上の資源」で行うより、「ネット越しの多数サービス＋情報＋手続き」を束ねる方が支配的になりつつあり、その上で “ユーザの意図→資源アクセス→結果統合” を成立させる層が必要になっている。

その層として LLM ランタイムは、OSの作業定義（抽象化／資源管理／インタフェース）をかなり満たしにいっている。

OSの要素対応

LLMランタイムを OS として見ると、対応がきれいに出ます：

シェル（ユーザインタフェース）：自然言語が“統一UI”になる

システムコール：ツール呼び出し（API呼び出し）が syscall 相当

ドライバ：個別SaaS／社内API へのコネクタ（仕様差の吸収）

プロセス：タスク（要約、調査、実装、レビュー、申請…）の実行単位

スケジューラ：手順分解、順序付け、リトライ、予算（時間/コスト）配分

メモリ階層：短期=コンテキスト、長期=外部メモリ（RAG/DB/ログ）

保護：ツール権限、データ境界、監査ログ、ポリシー

そして “資源を呼ぶ” という点は、LLM研究側でも明示的に扱われています。

たとえば ReAct は、推論と行動（外部情報源や環境へのアクセス）を交互に行う枠組みとして、LMが外部ソースにインタフェースすることを前提化しています。

Toolformer も、LMが いつ・どのAPIを・どんな引数で呼ぶかを学習し、結果を生成に取り込むという問題設定そのものが「LM＝資源オーケストレータ」であることを示しています。

「LLMはOS」という見方が有用なのは、今後OSがその発展過程で解いてきた問題設定がLLMを舞台に再出現するからです。

OSの語彙で問題が認識され、設計・研究課題が切れるはずです。

関連