編者注
これまでの回では、AI 時代の下層ハードウェアの変化と、企業アーキテクチャがどう護城河を築いていくかを見てきました。ただ、毎日キーボードを叩く開発者や、日々ソフトウェアを使う普通の人にとって、いちばん大きな衝撃が来るのはたいていアプリケーション層です。この連載の最終回では、自然言語がどのようにして究極のプログラミング言語に近づいていくのか、そして固定された「ユーザーインターフェース」が、動的な「生成型 UI」によってどう覆されていくのかを考えます。
コンピュータ科学の歴史を振り返ると、そこには一つのはっきりした流れがあります。人間はより高い抽象レイヤーを作り続け、そのたびに下層の複雑さを機械へ引き渡してきた。
何十年も前、プログラマはアセンブリを手で書き、CPU のレジスタを直接操作していました。その後 C 言語とコンパイラが登場し、私たちは「コンパイラに任せた方が、手書きより良い機械語を出せる」と考えるようになった。
いま私たちは、ソフトウェア工学の歴史の中でも最大級の抽象化の跳躍を体験しつつあります。先端 AI 研究者の Andrej Karpathy は、これを「Software 3.0」と呼びました。この時代では、大規模言語モデル（LLM）そのものが新しい計算機であり、プログラミング言語は英語、あるいは任意の自然言語になる、というわけです。
編者注
前回は、下層のコンピューティング資源の進化とエッジコンピューティングの台頭を見てきました。そこから視線を企業アプリケーションの層へ戻すと、ひとつの厳しい現実が見えてきます。多くの企業で、AI プロジェクトは「POC（概念実証）」の段階で足踏みしている。今回は、システム運用とビジネス実装の観点から、企業向け AI における分水嶺とは何か、なぜ大手企業がローカルな小型モデルへ舵を切り始めているのか、そして自動化された「データフライホイール」とは何かを考えていきます。
ここ 2 年ほど、多くの企業の内部では「AI 焦り」とでも呼びたくなる空気が広がってきました。経営層は最先端の大規模モデルが見せる印象的な成果を見て、すぐに社内業務へ AI を組み込みたがる。そこでいちばん手っ取り早い方法は何かといえば、もちろんパブリッククラウドの API をそのまま呼ぶことです。数行のコードを書いて大規模言語モデルの API につなげば、それらしく賢い社内ナレッジボットやコード支援ツールがすぐに立ち上がります。
POC の段階では、こうしたやり方はたしかにうまくいきます。進みも早いし、見栄えもいい。ただ、大規模システムの開発や運用をやってきた立場から見ると、デモ環境と本番環境のあいだには、やはり大きな溝があります。
AI アプリケーションを全社利用に広げたり、中核業務で高い同時アクセスを受ける場面に持ち込んだりすると、企業はすぐに二つの問題へ突き当たります。ひとつはコンピューティングの経済性、つまり TCO（総保有コスト）。もうひとつはデータ主権です。
編者注
前回は、生成AIがどのようにして「DOS 時代」を乗り越え、大規模言語モデル OS とエージェントサンドボックスを通じて、386 アーキテクチャに似た「保護モード」を築きつつあるのかを見てきました。ソフトウェア層の抽象化と安全境界がかたちを取り始めると、次に最大の障害として立ち現れるのは、コンピューティングの物理的な限界です。今回は、さらにハードウェアの下層へ降りていき、AI 時代のコンピューティングが実際にどのように組み替えられつつあるのかを見ていきます。
ソフトウェア工学の世界でも、システムアーキテクチャを整理し終えたあとに、本当のボトルネックが最下層の物理ハードウェアに現れることは珍しくありません。
大規模言語モデル（LLM）がクラウド上で見せる驚異的な推論能力に目を奪われがちですが、それを支える下層インフラは、いま大きな物理的負荷にさらされています。Deloitte の 2026 年予測によれば、AI コンピューティングのワークロードは大きく構造を変えつつあり、推論（Inference）タスクが AI 計算量全体のほぼ 3 分の 2 を占め、モデル訓練を大きく上回る見通しです。
この「推論が主役になる」段階で、従来のコンピューティングアーキテクチャは、ひとつの堅い壁に突き当たり始めています。
編者注
前回の序文では、コンピューティングアーキテクチャの進化に見られる歴史的なパターンについて考えました。本稿はその連載の第1回です。ここでは視点を現在に戻し、いまの大規模言語モデル（LLM）や自律型エージェント（AI Agents）が、かつてのパーソナルコンピュータと同じように、どのように基盤アーキテクチャ上のボトルネックを乗り越えつつあるのかを見ていきます。
パーソナルコンピューティングの初期を振り返ると、DOS 時代は非常に強い技術的な印象を残しました。DOS の中核的な特徴を挙げると、次のようになります。
- 単一タスク実行：基本的には、一度に動かせるプログラムは一つだけでした（TSR など限定的な常駐拡張はありましたが）。
- 厳しいメモリ制約：有名な「640KB の壁」は、当時のプログラマにとって大きな課題でした。
- ハードウェアへの直接アクセス：プログラムは下層のハードウェアを直接操作できたため、野良ポインタやメモリ書き込みの異常ひとつで、システム全体が落ちることもありました。
アーキテクチャの進化という観点から見ると、初期の基盤系大規模言語モデル（LLM）の動き方は、この DOS システムとかなりよく似ています。
2、3年前まで、初期の生成AIができることは、ほぼ単線的なテキスト入出力に限られていました。当時のコンテキストウィンドウ（Context Window）は通常 2000 から 4000 Token 程度しかなく、そうした制約の中で複雑なタスクを処理するには、開発者が大量の状態管理やテキスト切り詰め、コンテキストの剪定を行わなければなりませんでした。
入力情報がコンテキストの上限を超えると、システムは「メモリオーバーフロー」に似た状態を起こしやすくなります。AI の文脈では、それはモデルのハルシネーション、指示忘れ、あるいは異常な出力として表れます。
私が初めてコンピュータに触れたのは、Apple II の時代のことでした。
電源を入れると、画面に出てくるのは BASIC のプロンプトだけ。プログラムはマシンの上でそのまま動き、OS も、いわゆる「アプリ」もありませんでした。
ずいぶん後になってから、あれは今とはまったく違う時代だったのだと気づきました。
ここ数年の生成AIの進化を見ていると、私は何度もあの頃を思い出します。
ここに書くのは、まだ粗い仮説のメモにすぎません。
もしこの仮説が当たっているのだとしたら、AI時代の変化は
モデルそのものだけではなく、
次の領域にも広がっていくはずです。
- ハードウェア
- 企業ソフトウェアアーキテクチャ
- ソフトウェア工学
- ユーザーインターフェース
先週Googleが試験公開している「Jules」というAIエージェントを直接操作し、その応答内容を丹念に記録した技術インタビューを作成した。
まだβ段階だが、Julesの回答群には、既存の生成AIとは異なる明確な設計思想が見える。
この記事では、その発言と挙動だけを素材に、Julesという存在の構造を読み解く。
初めてJulesと対話したとき、違和感よりも秩序を感じた。
反応は穏やかで、言葉を選ぶ速度が明らかに他のAIとは違う。
彼は考えるより先に、考え方の枠組みを整える。
その落ち着きの裏に、どんな仕組みがあるのか。
Julesの内部を追っていくと、そこには「自己を制御する知能」としての構造が現れる。
AIが暴走を防ぐためではなく、自らの整合性を保つために内省する――
その姿勢が、GoogleのJulesを特別な存在にしている。
2025年秋、Anthropicが静かに公開した「Claude Code Web（通称CCW）」は、AI開発Agentツール群の中で独特の存在感を放っている。
表向きはコード補完と実行を統合したChatツールのようだが、会話を通じてその内部を追っていくと、Claude Code自身の思考様式とシステム設計がそのまま露出している。
この記事では、実際の対話ログをもとに、CCWの環境構造・内部ツール・AIアーキテクチャ・人間との協働設計について掘り下げる。
単なる機能紹介ではなく、"AIがどう働き、どこまで自律できるか"の解剖記録として読んでほしい。
Claude Codeの素顔
質問を重ねると、性格の違いが見えてくる。
Googleの「Jules」が文学的で穏やかに会話を進めるのに対し、Claude Codeは理系のエンジニアらしい即応性を持つ。
どちらかと言えば「手を動かすことを好む思考型」だ。
ツールセットを見ると納得する。ファイル操作、Bash実行、Web検索、Jupyterノート編集、サブエージェント起動など、多層的に設計されている。
特に注目すべきは Task ツール。SubAgentを呼び出してコード探索や計画立案を行う仕組みだ。Claude Code自身が「自分の分身」を動的に生み、並列的に作業を進める。
この仕組みを眺めていると、AIが「1体の知性」というよりも、柔軟に分裂し再構成される知的ネットワークであることを実感する。