私が初めてコンピュータに触れたのは、Apple II の時代のことでした。
電源を入れると、画面に出てくるのは BASIC のプロンプトだけ。プログラムはマシンの上でそのまま動き、OS も、いわゆる「アプリ」もありませんでした。
ずいぶん後になってから、あれは今とはまったく違う時代だったのだと気づきました。
ここ数年の生成AIの進化を見ていると、私は何度もあの頃を思い出します。
ここに書くのは、まだ粗い仮説のメモにすぎません。
もしこの仮説が当たっているのだとしたら、AI時代の変化は
モデルそのものだけではなく、
次の領域にも広がっていくはずです。
- ハードウェア
- 企業ソフトウェアアーキテクチャ
- ソフトウェア工学
- ユーザーインターフェース
第1回：歴史の比喩として見る、AIの「386の瞬間」
私は比較的早い時期にコンピュータに触れました。最初は Apple II です。電源を入れると BASIC のプロンプトが現れ、プログラムはマシンの上でそのまま動く。そんな世界でした。
その後の DOS 時代になると、そうした特徴はさらにくっきりしてきます。シングルタスクで、メモリ制約は厳しく、プログラムがハードウェアを直接扱う。そういう構造でした。
これは初期の大規模言語モデルによく似ています。テキストの入出力しかできず、コンテキストウィンドウは短い。状態管理は開発者任せで、少し気を抜くと「メモリオーバーフロー」、つまりハルシネーションが起きる。
大きな転換点になったのは、386 プロセッサと保護モードの普及でした。386 の「保護モード」と「仮想 8086 モード」は、マルチタスクやメモリ管理を実現しただけではありません。もっと重要だったのは、プログラムごとの実行環境をハードウェアレベルで分離したことです。これによって、1つのプログラムが落ちても OS 全体まで巻き込まれにくくなりました。
AI の「OS」と「保護モード」
最近は、大規模モデルを語るときに、こんな比喩をよく耳にするようになりました。
LLM は新しい OS のようなものだ。
この比喩で言えば：
- モデル本体は CPU
- コンテキストウィンドウは RAM
- ツール呼び出し（tool use）はシステムコール
さらに重要なのは、自律型AIエージェント（Agent）が、自分でコードを書き、それを実行する場面が増えていることです。これをホスト環境で無防備に動かせば、セキュリティ上の危険はかなり大きい。
そこで業界では、かつての 386 における「保護モード」にあたるものとして、「エージェントのサンドボックス化（Agentic Sandboxing）」が進みつつあります。たとえば先進的な Kubernetes サンドボックスコントローラでは、gVisor などを使って、信頼できないコードを実行するAIエージェント向けに厳密に隔離されたコンテナ環境を用意できます。
これは、当時の Windows 3.0 がハードウェアページングと特権リングによってアプリの分離を実現したのと同じように、AIがマルチタスク並行処理のプラットフォームへ進んでいくための土台になります。
第2回：コンピューティング基盤の組み替えとエッジの台頭、「メモリの壁」を越える小型モデルの時代
私たちはクラウドで LLM の便利さを享受していますが、その裏側にあるインフラは、いま大きな物理的ボトルネックに直面しています。
「メモリの壁」を破る新しいアーキテクチャ
従来型の GPU クラスタは高い性能を持っていますが、大規模推論になると、時間と電力の大半が巨大な重みデータを外部 VRAM から演算コアへ運ぶ処理に費やされます。いわゆる「メモリの壁」です。
この限界を越えるために、半導体業界では従来の実装路線から外れた新しいアーキテクチャが登場しています。たとえば Cerebras Systems のウェハスケールエンジン（WSE-3）です。
これはウェハを小さなチップに分割せず、1枚のシリコン上に 4 兆個のトランジスタと最大 44GB のオンチップ SRAM を集積し、毎秒 21 ペタバイト（PB/s）という圧倒的なメモリ帯域を実現したものです。
モデル重みをオンチップに常駐できれば、
推論時のデータ移動は大きく減り、
遅延もかなり下げられるはずです。
NPU と端末側小型モデル（SLM）の広がり
個人向けで次に来るのは、クラウド上の超巨大モデルをむやみに呼び出すことではなく、「賢く小さくする」方向だと思います。数十億パラメータ以下の小型言語モデル（SLM）でも、日常的な推論タスクの 70-90% は十分こなせますし、PC やモバイル端末で直接動かせます。
背景にあるのは、AI PC における NPU（ニューラルネットワーク処理装置）の普及です。NPU は低消費電力で AI の処理を効率よく回せます。
ローカルで動かせば、応答はほぼ「ゼロ遅延」に近づきますし、データ主権の面でも有利です。プライバシーデータを端末の外に出さずに済むからです。
第3回：企業AIの分水嶺、コンピューティングの経済学と自動化の「データフライホイール」
エンタープライズ用途では、技術選定は単に機能が派手かどうかでは決まりません。ROI（投資対効果）、TCO（総保有コスト）、そして機密情報の安全性にそのまま跳ね返ってくるからです。
なぜクラウド API だけでは足りないのか
公開クラウドの汎用 LLM API に依存すると、予測しにくい継続課金コストと、深刻なデータ漏えいリスクを抱えることになります。企業の中核業務は、最終的には自前のインフラの上に置かざるをえません。
自動化された「データフライホイール」
企業向けAIアーキテクチャが成熟していく方向は、ローカル小型モデルを中心に据えた「データフライホイール」の構築です。社内文書、顧客チケット、私有コードを自動で取り込み、ローカルの SLM を継続的に微調整（Fine-tuning）していく。要するに、使えば使うほど社内データで賢くなっていく仕組みです。
この戦略の事業インパクトはかなり大きい。たとえば NVIDIA 社内の従業員支援AIエージェントでは、データフライホイールの手法で 1B から 8B 規模の私有小型モデルを微調整し、社内業務ルーティングで 94% から 96% の精度を達成しました。700 億パラメータ級の汎用モデルに十分対抗できる水準です。
しかもこの方式では、推論コストを 98% 削減し、遅延を 70 倍改善できたとされています。データをローカルに残し、私有データで専用モデルを育て続けることこそ、企業にとっての本当の競争優位になります。
第4回：ソフトウェア工学とインタラクションの行き先、AIコンパイラと生成型UI
ここまでの回では、アーキテクチャ、ハードウェア、企業導入を見てきました。最後に見るのは、開発者とユーザーに最も近い二つの層です。コードはどう作られるのか。UI はどう立ち上がるのか。
自然言語が最上位のプログラミング言語になる
従来のコンパイラは厳密な文法に従って、人間が書いたコードを機械語に変換します。ところが今は、自然言語が最上位のプログラミング言語になりつつあり、大規模モデルは「確率的なコンパイラ」のように振る舞い始めています。
先端のAIコーディングエージェント（Devin など）は、ただの補完ツールではありません。サンドボックス内で自律的に構成を考え、コードを書き、コンパイラのエラーログを読みながら、自分で修正まで行います。
大規模言語モデルと厳密なコンパイラフィードバックが強く結びつくことで、「プロンプトで書く開発」は、より実務的で大規模なソフトウェア開発へ近づいていきます。
UI から User Intent へ
生成AIの成熟は、人と機械のインタラクションを根本から変えつつあります。2025年のトレンドを見ると、設計思想は User Interface（UI）から User Intent（ユーザー意図）へと移り始めています。
これからの UI は、デザイナーがあらかじめ固定で作っておく静的なビューではありません。システムが AI で意図をくみ取り、その場で画面上にインタラクティブなコンポーネント（Generative UI）を立ち上げていく方向です。
実際、Google などのチームは、ユーザーのプロンプトから HTML、CSS、動的チャートを含む完全なアプリ体験を瞬時に生成する実験を進めています。さらに、視覚的な Web UI と、環境を理解した音声インタラクションの統合も進んでいます。
目的を自然に伝えるだけで、ソフトウェア側がその場で最適な UI を組み立てる。そんな体験が、少しずつ現実になりつつあります。
結語
80286 から 80386 へ。ローカルの単体マシンから、マルチタスク並行処理のクラウドコンピューティングへ。技術の本当のパラダイムシフトは、いつだってアーキテクチャの変化から始まります。
物理ボトルネックを打ち破ろうとするウェハスケールチップ、ローカルの安全なサンドボックスで動くエージェント、動的かつマルチモーダルな生成型 UI、そして企業向けの自動化データフライホイール。そうしたものが重なり合って、次世代のコンピューティング基盤の輪郭が見え始めています。
いまを DOS にたとえるのは、Windows 3.0 や 1995年のインターネット、2007年の iPhone と比べると、まだ「能力は見えているのに、かたちは定まっていない」段階だからです。
現状が DOS 的だと言える理由は、主に次の4点です。
- 機能はまだ粗い：驚くほど強力な能力はある一方で、不安定さが残り、境界条件では崩れやすい。
- インターフェースはまだ原始的：プロンプトとワークフローは「コマンドライン的な操作感」に寄っていて、誰でも自然に使える形にはまだ距離がある。
- ツールチェーンはまだ混沌としている：モデル、フレームワーク、評価、デプロイ標準は高速に動いているものの、安定した産業ベースラインはまだない。
- アプリの生態系は立ち上がり段階にある：ヒット事例は出始めているが、大規模で持続可能かつ再現可能なエコシステムはこれからだ。
言い換えると、私たちは新時代の輪郭をすでに見ているものの、「プラットフォームが成熟し、生態系が一気に広がる段階」にはまだ達していません。
何十年か後に振り返ったとき、
今日の生成AIは、
あの時代にとっての
DOS
だったと言われるのかもしれません。
参考資料と追加読書
本文で触れたデータや技術的な示唆は、以下の業界実践と調査レポートに基づいています。
- 80386 の仮想 8086 モードとサンドボックス分離：分離型マルチタスクの古典的なアーキテクチャ史と、Kubernetes で gVisor などを使った最新のエージェント分離の実践。
- 大規模言語モデルの「OS」メタファー：Andrej Karpathy による、LLM を新しい OS と捉え、コンテキストウィンドウを主記憶に見立てる議論。
- 「メモリの壁」の突破と Cerebras アーキテクチャ：WSE-3 ウェハスケールチップによる、従来の GPU 帯域ボトルネックを突破する技術解説。
- NPU と端末側小型モデル（SLM）：NPU がエッジ環境でのローカル推論効率を大きく高めることについての議論。
- 企業AIとデータフライホイールの経済学：継続的微調整ループ（Data Flywheel）の概念と、NVIDIA 社内で 98% のコスト削減と 70 倍の遅延改善を実現した実例。
- 生成型 UI（Generative UI）とユーザー意図：従来の UI から User Intent への移行トレンドと、Google チームによる即時生成型インタラクティブ UI の研究。
引用文献
1. What is Cerebras? - Pangea, https://pangea.app/glossary/cerebras
2. Cerebras CS-3: the world's fastest and most scalable AI accelerator, https://www.cerebras.ai/blog/cerebras-cs3
3. NPU vs GPU: Key Differences for AI PCs - HP Tech Takes, https://www.hp.com/us-en/shop/tech-takes/npu-vs-gpu-ai-pcs
4. Devin | The AI Software Engineer, https://devin.ai/
5. 2025 UX Trends - The Evolution from UI (User Interface) to UI (User Intent): A New Era in Human-Agent Interaction - Prof. MING WEN, https://donwen.medium.com/2025-ux-trends-the-evolution-from-ui-user-interface-to-ui-user-intent-a-new-era-in-a0ac085f0d2b
6. Generative UI: A rich, custom, visual interactive user experience for ..., https://research.google/blog/generative-ui-a-rich-custom-visual-interactive-user-experience-for-any-prompt/
7. Generative UI Guide 2025: 15 Best Practices & Examples - Mockplus, https://www.mockplus.com/blog/post/gui-guide
8. What are the "virtual machines" that were running on 80386 and later x86 CPUs before full hardware virtualization? - Retrocomputing Stack Exchange, https://retrocomputing.stackexchange.com/questions/23617/what-are-the-virtual-machines-that-were-running-on-80386-and-later-x86-cpus-be
Comments