編者注
前回の序文では、コンピューティングアーキテクチャの進化に見られる歴史的なパターンについて考えました。本稿はその連載の第1回です。ここでは視点を現在に戻し、いまの大規模言語モデル（LLM）や自律型エージェント（AI Agents）が、かつてのパーソナルコンピュータと同じように、どのように基盤アーキテクチャ上のボトルネックを乗り越えつつあるのかを見ていきます。
パーソナルコンピューティングの初期を振り返ると、DOS 時代は非常に強い技術的な印象を残しました。DOS の中核的な特徴を挙げると、次のようになります。
- 単一タスク実行：基本的には、一度に動かせるプログラムは一つだけでした（TSR など限定的な常駐拡張はありましたが）。
- 厳しいメモリ制約：有名な「640KB の壁」は、当時のプログラマにとって大きな課題でした。
- ハードウェアへの直接アクセス：プログラムは下層のハードウェアを直接操作できたため、野良ポインタやメモリ書き込みの異常ひとつで、システム全体が落ちることもありました。
アーキテクチャの進化という観点から見ると、初期の基盤系大規模言語モデル（LLM）の動き方は、この DOS システムとかなりよく似ています。
2、3年前まで、初期の生成AIができることは、ほぼ単線的なテキスト入出力に限られていました。当時のコンテキストウィンドウ（Context Window）は通常 2000 から 4000 Token 程度しかなく、そうした制約の中で複雑なタスクを処理するには、開発者が大量の状態管理やテキスト切り詰め、コンテキストの剪定を行わなければなりませんでした。
入力情報がコンテキストの上限を超えると、システムは「メモリオーバーフロー」に似た状態を起こしやすくなります。AI の文脈では、それはモデルのハルシネーション、指示忘れ、あるいは異常な出力として表れます。
80386 アーキテクチャと「保護モード」の革命
コンピュータの歴史における大きな転換点のひとつは、Intel 80386 プロセッサと保護モード（Protected Mode）の普及でした。もっとも、その前の 80286 でもすでに「保護モード」は導入されていました。ただ、設計上の制約が多く、大量の DOS 資産を抱えた現実の環境では十分に力を発揮できなかった。本当の意味で状況を塗り替えたのは、1985 年に登場した 80386 だったと言っていいと思います。
80386 がもたらしたのは、32 ビットのアドレス空間やフラットなメモリモデルだけではありません。より重要だったのは、ハードウェア需要ページング（Demand Paging）や、より完成度の高い保護メモリ機構が整ったことです。「仮想 8086 モード」（Virtual 8086 Mode）は、その中でも重要な互換性維持のための仕組みでした。
初期のリアルモードでは、メモリ管理に十分な分離がなく、プログラム同士が簡単に干渉し合っていました。386 アーキテクチャは、プリエンプティブなマルチタスクと仮想メモリ機構を通じて、プログラムごとの実行環境をハードウェアレベルで切り分けました。つまり、ハードウェアレベルで複数の仮想マシンを作り、独立した DOS プログラムを並行して走らせ、それぞれに独立した仮想コンピューティング環境を与えられるようになったわけです。
この分離機構によって、ひとつのプログラムのクラッシュがそのままシステム全体の停止や、ほかのプログラムのメモリ破壊につながることは少なくなりました。こうした下層の分離とメモリ管理こそが、その後の Windows 3.0 の成功を支え、さらに現代的な GUI の発展を後押しする土台になりました。
大規模言語モデルは新しい「OS」になりつつある
では、いまの時代に戻ってみます。私たちはいま、AI 自身のアーキテクチャが跳躍する場面を目の前で見ています。AI は単なる「テキスト生成器」から、新しい意味での「大規模言語モデル OS（LLM OS）」へと姿を変えつつあります。
先端の AI 研究者である Andrej Karpathy が示した比喩は、とても示唆的です。これからのコンピューティングアーキテクチャでは、大規模言語モデルそのものが中央処理装置（CPU）の役割を担い、論理推論、意図の解析、タスクのオーケストレーションを引き受ける。一方で、いまや数百万 Token にまで広がった巨大なコンテキストウィンドウは、このシステムにおける主記憶装置（RAM）にあたります。
386 のアドレッシング能力が広がったことで、頻繁なディスクスワップが減ったのと同じように、巨大なコンテキストウィンドウは、推論の途中でモデルが何度も文脈を圧縮したり切り捨てたりする必要を小さくしました。その結果、複雑な推論の安定性は大きく上がっています。
この「AI オペレーティングシステム」の中では、検索拡張生成（RAG）に使われるベクトルデータベースが永続的なファイルシステム、つまりハードディスクに相当し、API や外部ツールの呼び出しは OS におけるシステムコール（System Calls）にあたります。だからこそ AI は、現代のコンピュータのように、同じワークスペースの中で大量の指示、中間変数、複数ステップの実行履歴を並行して抱え込めるようになってきたのです。
エージェントサンドボックス（Agent Sandboxing）：AI時代の「保護モード」
もし生成AIの領域で本当の意味での「386 の瞬間」が訪れるとすれば、その決定的な兆しは、自律型AIエージェント（AI Agents）が隔離環境の中で安全にマルチタスク実行できるようになることだと思います。
AI エージェントには、いま急速に大きな権限が与えられつつあります。対話するだけではなく、自分で手順を立て、その場で未検証のコードを生成し、システムレベルのコマンドを実行しようとする。しかし、AI が生成するコードは本質的に確率的で不確実です。つまり、最初から「信頼できるコード」とは見なせません。
そうしたコードをホストサーバーや通常の本番環境でそのまま裸で走らせれば、セキュリティ上のリスクは壊滅的になりえます。DOS 時代には、たった一つの誤ったコードでマシン全体が落ちることがありましたが、それにかなり近い話です。
そのため業界では、386 の保護モードに相当するインフラとして、エージェントのサンドボックス化（Agentic Sandboxing）が急速に導入されつつあります。現代のエージェントフレームワークでは、エージェントのワークフローを、厳格に隔離された非永続的な実行環境で動かすことが前提になりつつあります。たとえば最先端の Kubernetes サンドボックスコントローラは、gVisor や Kata Containers などを使い、アプリケーションとクラスタノード OS のあいだに安全な隔離層を作ります。Vercel のようなプラットフォームでも、AI エージェント向けにミリ秒単位で起動する安全な一時実行環境を提供する、専用の分離型コンピューティングモデルが導入されています。
こうしたサンドボックス分離によって、AI エージェントは生成したコードを安全に実行し、コンパイラから返ってきたエラーを取り込み、自律的に反復デバッグできるようになります。その一方で、下層のホスト基盤には脅威を及ぼしません。このシステムレベルの安全境界は、ちょうど Windows 3.0 が 386 の機構を利用してアプリケーションレベルの分離を実現したのと同じように、AI が単一の対話ボットから、並行性と信頼性を備えたエンタープライズ向け自動化プラットフォームへ移っていくための中核的な土台になります。
結語
現在の生成AIは、初期の「DOS 段階」から、メモリ管理、ツール呼び出し、サンドボックスによる保護モードを備えた「現代的な OS」の段階へと進みつつあります。
とはいえ、この移行はまだ途中です。モデルのハルシネーションは根本的には解決していませんし、エンタープライズ用途で求められる決定性と、大規模モデルの確率的な性質とのあいだには依然として緊張があります。サンドボックスは安全性を高める一方で、システムの複雑さや性能コストも増やします。
抽象化レイヤーと安全境界が整ってくると、次に主要なボトルネックになるのはコンピューティング資源です。もっと言えば、仮にその問題が緩和されたとしても、レガシーシステムの移行、チームのスキル転換、組織の慣性といった要因によって、この変化のスピードは期待より遅くなるかもしれません。
次回は、より下層の物理レイヤーにあるコンピューティングアーキテクチャの進化を扱います。ハードウェアはいかにして「メモリの壁」を越えようとしているのか。さらに、端末側の小型モデル（SLM）が個人向けコンピューティング機器にどのような影響を与えるのかを見ていきます。
Comments