この一年で、「エージェント」という言葉の重心が変わった。

少し前まで、エージェントと言えば、だいたい次のようなものを指していた。大規模言語モデルに一度問い合わせる。その前後に検索、ファイル操作、コード実行、ブラウザ操作のような道具をつなぐ。モデルが「次に何をするか」を文章で決める。必要なら道具を呼ぶ。結果を見て、もう一度考える。

これはたしかに便利だった。単なるチャットより一段進んでいた。モデルが外の世界に触れるからだ。

しかし、この段階のエージェントは、まだ「一回の呼び出しを少し賢くしたもの」に近かった。壊れても、もう一度実行すればよい。途中の状態が失われても、利用者が説明し直せばよい。権限が少し粗くても、実験なら許される。動いている時間も短く、同時に走る数も少ない。

問題は、それを止めずに本番で動かそうとした瞬間に始まる。

エージェントが数分ではなく数時間走る。途中でファイルを読み、外部 API を呼び、ブラウザを開き、コードを書き、結果を保存する。昨日の判断を今日も覚えている必要がある。複数のエージェントが同時に動き、互いに依存する。あるエージェントの出力が、別のエージェントの入力になる。失敗したときには、どこまで戻すかを決めなければならない。ある道具は使わせたいが、ある操作は許したくない。ある記憶は共有したいが、ある記憶は隔離したい。

ここまで来ると、エージェントは「賢い関数呼び出し」ではなくなる。

それは、状態を持ち、資源を消費し、権限を持ち、失敗し、再開され、観測され、他の実行単位と協調する存在になる。つまり、プロセスになる。

そしてプロセスが増えると、必ず管理する層が要る。

誰がいつ走るのか。どの資源を使ってよいのか。どの記憶に触れてよいのか。外部の道具を呼ぶ権限はどこまであるのか。途中で落ちたとき、どの状態から再開するのか。複数の実行が同じデータを書き換えようとしたとき、どちらを優先するのか。利用者に見せるべきログと、内部だけで持つべきログをどう分けるのか。

これは新しい問題に見えるが、構造としては古い。

コンピュータが単一のプログラムを一つずつ動かしていた時代には、実行管理は単純だった。だが、複数のプログラムを同時に動かし、メモリを分け、ファイルを守り、デバイスを共有し、失敗から復帰しようとしたとき、オペレーティングシステムが必要になった。

いまエージェント基盤で起きていることは、それにかなり近い。

もちろん、エージェント基盤は従来の OS そのものではない。CPU の命令を直接スケジュールするわけではないし、メモリアドレスをページ単位で割り当てるわけでもない。だが、解いている問題の形は似ている。実行単位があり、資源があり、状態があり、権限があり、失敗があり、観測がある。その全体を、利用者や開発者が毎回手で面倒を見ることはできない。

だから、信頼でき、規模化でき、商業化できるエージェント基盤を本気で作ろうとすると、それは比喩ではなく、OS と同じような階層構造を持ちはじめる。

この連載は、その構造を下から読む。

なぜ OS なのか

単発のモデル呼び出しでは、管理すべきものは少ない。

入力を渡す。出力を受け取る。必要なら再試行する。失敗しても、利用者がもう一度投げれば済む。会話履歴はあるかもしれないが、それも基本的には「次の入力に添える文脈」でしかない。

ところが、エージェントが長く走りはじめると、事情が変わる。

たとえば、ある調査エージェントが朝から動いているとする。複数のサイトを巡回し、記事を読み、要約し、重要度を判定し、後で使うためにメモを残す。途中で API の制限に当たる。あるページは読み込みに失敗する。別のページはログインが必要になる。要約の途中でモデル呼び出しが失敗する。さらに、同じ時間帯に別のエージェントも同じデータベースへ書き込もうとしている。

このとき必要なのは、よいプロンプトだけではない。

どの作業が完了していて、どの作業が未完了なのか。失敗した処理は再試行してよいのか。再試行すると二重に書き込まないか。途中まで読んだ記事の状態はどこに保存するのか。どのエージェントがどの認証情報を使えるのか。外部サイトへのアクセス回数をどう制御するのか。処理全体のログをどう追跡するのか。

これらは、モデルの賢さとは別の問題である。

モデルがいくら賢くても、実行状態が消えれば続きはできない。モデルがいくら道具を使えても、権限境界がなければ危険になる。モデルがいくら推論できても、複数の作業が同じ資源を奪い合えば壊れる。モデルがいくら自然な文章を書けても、どこで失敗したか見えなければ運用できない。

だから、エージェントを本番で動かすには、モデルの外側に管理層が必要になる。

この管理層が受け持つ仕事は、従来の OS が担ってきた仕事と対応している。OS は CPU 時間を配る。メモリを分ける。プロセスを起動し、停止し、隔離する。ファイルやデバイスへのアクセスを制御する。システムコールという形で、プログラムが外界に触れる入口を決める。

エージェント基盤でも似たことが起きる。モデル呼び出し、道具呼び出し、メモリ参照、外部 API、ファイル、ブラウザ、コード実行を、誰にどこまで許すか決める必要がある。長く走る仕事を、どの単位で保存し、再開し、監視するか決める必要がある。複数のエージェントを、どう並べ、どう待たせ、どう止めるか決める必要がある。

ここで大事なのは、「OS っぽい」という雰囲気ではない。

問題の因果が OS を要求している、ということだ。

実行が長くなる。すると状態が必要になる。状態があると、保存と復帰が必要になる。複数の実行が並ぶ。するとスケジューリングが必要になる。道具を呼ぶ。すると権限が必要になる。外部世界を書き換える。すると監査が必要になる。失敗が起きる。すると再試行と巻き戻しが必要になる。

この連鎖の先に、自然に階層が生まれる。

下には計算資源がある。その上に推論サービスがある。その上にモデルがある。その上にエージェントの実行環境がある。さらに上に、複数エージェントの編成がある。安全はその横を貫く。評価と開発の仕組みが、全体を製品として成立させる。最後に、金融、教育、内容安全のような用途が乗る。

これが、この連載で言う Agentic OS 技術スタックである。

重心が上がった

以前の中心課題は、モデルそのものに近かった。

どうプロンプトを書くか。どのモデルを使うか。どの道具を渡すか。どの順番で考えさせるか。モデルに計画を立てさせるか、外側のコードで制御するか。これらは今でも重要だが、主戦場は少し上に移った。

いま問われているのは、「エージェントという実行単位をどう管理するか」である。

これは、アプリケーション開発で言えば、関数の中身だけを見ていた段階から、サービス運用を見る段階に移ったようなものだ。関数単体なら、入力と出力を見ればよい。しかしサービスは、リクエストを受け、状態を持ち、他サービスを呼び、障害に耐え、ログを出し、権限を守り、デプロイされ、監視される。中のロジックだけでは語れない。

エージェントも同じである。

一つのモデル呼び出しが正しい答えを出せるかどうかだけでは足りない。その答えが、長い作業のどの位置で出たのか。前提となる記憶は何か。どの道具を使って得た結果なのか。誰の権限で実行されたのか。失敗時に再実行しても安全なのか。別のエージェントと競合しないのか。最終的な成果物をどう評価するのか。

こうして、少なくとも三つの工学テーマが独立して立ち上がる。

一つ目は、運行時である。

ここで言う運行時とは、エージェントが実際に走る環境のことだ。モデルを呼び、道具を呼び、途中状態を保存し、必要なら再開する。短期の文脈と長期の記憶を分ける。コード実行やブラウザ操作を隔離する。外部世界に副作用を出す操作を管理する。

二つ目は、編成である。

一つのエージェントだけではなく、複数のエージェントをどう組み合わせるかという問題だ。調査するエージェント、検証するエージェント、実装するエージェント、レビューするエージェントがいるとする。それらは直列に動くのか、並列に動くのか。誰が結果を統合するのか。途中で矛盾したらどうするのか。資源が足りないとき、どれを待たせるのか。

三つ目は、安全である。

エージェントは、文章を出すだけならまだよい。だが、ファイルを書き換え、メールを送り、決済を起こし、社内データを読み、コードを実行するなら、話は変わる。誤作動だけでなく、外部からの誘導にも備えなければならない。ウェブページやメール本文の中に、エージェントをだます指示が混ざることがある。道具の出力に、次の行動を乗っ取る文章が含まれることもある。

安全は、最後にフィルタを置けば済む問題ではない。

どの層で、何を信じるのか。どの入力を命令として扱い、どの入力を単なるデータとして扱うのか。どの操作に人間の確認を挟むのか。どの記憶を共有してよいのか。どのログを監査できる形で残すのか。これらを設計しない限り、エージェントは本番の権限を持てない。

つまり、重心は「モデルをどう賢く使うか」から、「賢い実行単位をどう運用するか」へ移った。

この変化を見落とすと、エージェントをいつまでもデモの延長として扱ってしまう。デモでは動く。しかし、長く走らせると壊れる。人数を増やすと混線する。権限を与えると危なくなる。顧客に渡すと説明できなくなる。

エージェントがプロセスになるとは、そういうことである。

いまはまだ裸のマルチプロセス段階にいる

現在の多エージェントシステムの多くは、率直に言えば、まだ粗い。

複数のエージェントを立てる。それぞれに役割を与える。あるエージェントの出力を、別のエージェントの入力に渡す。プロンプトで「あなたはレビュー担当です」「あなたは実装担当です」と指示する。必要なら、会話履歴や中間結果を共有する。

これは動く。小さな例では、かなりうまく見える。

しかし OS の比喩で言えば、これは fork したプロセスを、手作業の IPC でつないでいる段階に近い。IPC とは、プロセス間通信のことだ。別々に動く実行単位が、メッセージ、共有メモリ、パイプ、ファイルなどを通じて情報を渡す仕組みである。現在の多エージェントでは、この通信の多くが自然言語のプロンプトに押し込まれている。

自然言語は柔軟だが、境界が曖昧である。

どこまでが命令で、どこからがデータなのか。どの情報が信頼済みで、どの情報が未検証なのか。あるエージェントの発言を、別のエージェントがどの権限で実行してよいのか。共有された文脈のうち、どれが現在も有効なのか。こうしたことが、明示的なシステム構造ではなく、プロンプトの書き方に依存している。

スケジューラもまだ弱い。

スケジューラとは、どの実行単位をいつ走らせるかを決める仕組みである。OS では、CPU は有限なので、プロセスを順番に走らせる必要がある。エージェントでも、モデル呼び出し、外部 API、ブラウザ、データベース、予算、人間の確認時間は有限である。すべてを同時に走らせれば、コストが跳ねる。順番を誤れば、必要な前提がそろう前に作業が進む。待たせすぎれば、全体の遅延が増える。

名前空間による隔離も未成熟である。

名前空間とは、ある実行単位から見える世界を限定する仕組みだ。OS では、コンテナごとに見えるファイルシステム、プロセス、ネットワークを分けられる。エージェントでも同じ発想が要る。調査エージェントには読み取り専用の資料だけを見せる。実装エージェントには特定のリポジトリだけを渡す。顧客 A の記憶と顧客 B の記憶を混ぜない。検証前の情報を、確定情報として別のエージェントに渡さない。

資源と権限の抽象もまだそろっていない。

ある道具は読み取りだけ許す。ある道具は書き込みも許す。ある操作は人間の承認後にだけ実行する。あるメモリは一時的に使い、あるメモリは長期保存する。あるモデルには低コストで下書きをさせ、あるモデルには高コストで最終判断をさせる。こうした設計を、エージェントごとのプロンプトと個別コードだけで管理するのは限界がある。

最近、エージェント群をネットワークとして扱う考え方、エージェントの実行基盤をクラスタ管理に近づける考え方、実行ツリーを可視化する仕組みが出てきている。これらは単なる新製品の流行として見るより、「業界がようやくプロセススケジューラ、資源隔離、名前空間を作りはじめた信号」と読んだほうがよい。

進化の線は、おそらくこうなる。

最初は、裸の fork である。エージェントをいくつも起動し、プロンプトでつなぐ。

次に、プロセスモデルが固まる。エージェントとは何か、タスクとは何か、状態とは何か、メモリとは何か、道具呼び出しとは何かが、明示的な単位として分かれる。

その次に、スケジューリング、隔離、通信の標準化が進む。どのエージェントがいつ走り、何を見られ、何を呼べて、どの形式で結果を渡すかが、個別実装ではなく基盤の責務になる。

最後に、カーネルのような層が見えてくる。

ここで言うカーネルとは、OS の中核という意味を借りた表現である。エージェント実行の最低限の権限、資源、状態、通信、監査を扱う層である。アプリケーションごとに毎回作るものではなく、その上にさまざまなエージェントアプリケーションが乗る共通基盤になる。

この連載は、その線を追う。

スタックの全景

Agentic OS 技術スタックは、一枚の図として見ると分かりやすい。

ただし、この図は製品カテゴリの一覧ではない。どの層にどの会社がいるかを並べたいわけでもない。ここで見たいのは、それぞれの層がどんな直感を鍛える場所なのかである。

下から順に見る。

層	名前	そこで鍛える直感
L0	算力の土台	クラスタ全体で計算をどう配り、壊れても続け、訓練と推論を一体で運用するか。
L1	推論サービス	一つのトークンが出るまでに、キャッシュ、並列性、待ち時間、コストがどう絡むか。
L2	モデル	モデルの構造、世界の持ち方、後訓練、端末側実行が、上の層の可能性をどう決めるか。
L3	運行時	エージェントを隔離し、状態を保存し、長期記憶と道具呼び出しをどう管理するか。
L4	編成	複数のエージェントをどう並べ、通信させ、観測し、全体として仕事を完了させるか。
L5	安全	入力、道具、記憶、権限、実行のすべてを横断して、どこで何を信じるかを設計する。
L6	研発体系	仕様、評価、テスト環境、開発 CLI を通じて、エージェントを納品可能なものにする。
L7	垂直応用	金融、教育、内容安全などの現場要求から、下の層に必要な能力を逆向きに定義する。

L0 は、算力の土台である。

ここで見るのは、GPU が何枚あるかだけではない。大量の計算資源を、どう割り当て、どう詰め込み、どう故障に耐えさせるかである。訓練と推論は別物に見えるが、実際には同じクラスタ、同じネットワーク、同じ運用上の制約を奪い合う。大きなモデルを作る力と、そのモデルを安く安定して配る力は、別々ではなくつながっている。

L1 は、推論サービスである。

モデルに入力を投げれば答えが返る、という見方では粗すぎる。推論では、過去のトークンから作った内部状態を再利用する。これが KV キャッシュである。KV は、モデルが注意機構で過去の文脈を参照するために持つキーと値の束だ。長い文脈を扱うほど、このキャッシュは大きくなる。キャッシュをどこに置き、どう再利用し、どう捨てるかが、待ち時間とコストを決める。

投機的推論もここに入る。これは、小さく速いモデルに先の候補トークンを走らせ、大きなモデルがそれをまとめて確認する考え方である。うまく当たれば、品質を大きく落とさずに出力を速くできる。つまり、推論サービスは単なる API ではない。トークンが入口から出口まで通る経路全体を調度する層である。

L2 は、モデルである。

ここでは、モデルを魔法の箱として扱わない。どのようなアーキテクチャが、どのような文脈長、推論速度、記憶の扱い、マルチモーダル性を可能にするのかを見る。世界モデルという言葉も、ここでは飾りではない。外界の状態変化を内部で予測し、行動の結果を見積もる力がどの程度あるか、という具体的な問題として扱う。

後訓練も重要である。事前学習済みのモデルに対して、人間の好み、タスクの成功、環境からの報酬を使って振る舞いを調整する。特に、複数の試行が同時に進み、後から報酬が返ってくるような非同期の強化学習は、エージェントの訓練と相性がよい。端末側のモデルもここで見る。すべてをクラウドに送るのではなく、遅延、プライバシー、コストの理由から、手元の端末で動くモデルが担う範囲が広がる。

L3 は、運行時である。

ここから、エージェントははっきりプロセスに近づく。実行環境を隔離する。コードを安全な箱の中で動かす。ブラウザ操作を記録する。道具呼び出しの結果を保存する。短期文脈と長期記憶を分ける。長期記憶とは、単に古い会話を全部詰め込むことではない。後で再利用できる形で、事実、判断、好み、成果物、失敗を整理し、検索できるようにすることである。

L4 は、編成である。

一体のエージェントでできることには限界がある。調査、計画、実行、検証、監査を一つの文脈に押し込むと、文脈は太り、責務は曖昧になり、失敗箇所が見えにくくなる。そこで、役割を分けた複数のエージェントを組む。しかし、分ければ自動的によくなるわけではない。通信の形式、責任境界、待ち合わせ、競合解決、実行ツリーの可観測性が必要になる。

L5 は、安全である。

これは L1 から L4 までを横断する。推論サービスでは、入力と出力の扱いが問題になる。モデルでは、有害な振る舞いやだまされやすさが問題になる。運行時では、道具と権限が問題になる。編成では、あるエージェントの汚染された出力が、別のエージェントを通じて広がる問題がある。

レッドチームとは、攻撃者や悪条件の立場から、システムを意図的に壊そうとする検証である。注入攻撃とは、外部データの中に命令めいた文章を混ぜ、エージェントの判断を乗っ取ろうとする攻撃である。エージェント基盤の安全は、これらを単発のフィルタで止めるのではなく、命令とデータの分離、権限の最小化、監査、人間確認、隔離を組み合わせて作る。

L6 は、研発体系である。

エージェントを作るとは、プロンプトを書くことだけではない。仕様を決める。期待する振る舞いをテスト可能な形に落とす。失敗例を集める。評価環境を作る。道具のモックを用意する。回帰テストを回す。納品後にログを見て改善する。Harness とは、このような評価と実行の枠組みである。単に「賢そうに答えたか」ではなく、指定された環境で、指定された制約のもと、仕事を完了できたかを測る。

ここには、コーディング CLI も入る。コードを書く主体が、人間だけではなくなるからだ。人間が仕様を渡し、エージェントが編集し、テストを走らせ、レビューを受け、また修正する。このとき重要なのは、誰が書いたかではなく、どの仕様に対して、どの差分が生まれ、どの検証を通ったかである。

L7 は、垂直応用である。

金融、教育、内容安全のような領域は、最後に皮をかぶせるだけのものではない。むしろ逆である。現場の要求が、下の層に必要な能力を決める。

金融では、説明可能性、監査、権限、データ境界が強く求められる。教育では、学習者ごとの長期記憶、誤り方の把握、介入のタイミングが重要になる。内容安全では、大量の入力を高速にさばきながら、境界事例を人間に戻す設計が必要になる。

つまり応用層は、単なる見た目ではない。下の層に対する要求仕様である。

最後に、Harness 能力モデルが全体をつなぐ。

あるエージェントが本当に使えるかどうかは、モデル単体の点数では決まらない。L0 の算力制約、L1 の推論コスト、L2 のモデル能力、L3 の実行環境、L4 の編成、L5 の安全、L6 の評価、L7 の現場要求が噛み合って初めて決まる。どこか一つだけが強くても、全体としては詰まる。

この連載では、その噛み合いを見る。

なぜ下から読むのか

エージェントの話は、上から始めたくなる。

どんな仕事を自動化できるか。どんな UI がよいか。どんな業務に入るか。どんなエージェントを何体並べるか。こういう話は分かりやすい。目に見える成果に近いからだ。

しかし、上からだけ読むと、肝心なところを見誤る。

上の層のコストは、下の層の物理的な制約で決まるからである。

たとえば、長期記憶をたくさん使えば賢くなる、という言い方がある。だが、記憶はただではない。検索するにも計算が要る。文脈に入れるにもトークンが要る。モデルが長い文脈を読むには KV キャッシュが膨らむ。キャッシュが膨らむと、メモリ帯域を食う。メモリ帯域が詰まると、並行数が落ちる。並行数が落ちると、待ち時間とコストが上がる。

つまり、「記憶を持たせる」という上の設計は、下の帯域とキャッシュの制約に直結している。

複数エージェントを並列に走らせる場合も同じである。並列にすれば速くなるように見える。しかし、各エージェントがモデルを呼び、道具を呼び、同じデータを読み書きするなら、どこかで資源を奪い合う。推論サーバのキューが伸びるかもしれない。外部 API の制限に当たるかもしれない。共有メモリの整合性が崩れるかもしれない。人間の確認待ちが詰まるかもしれない。

評価も同じである。よい評価を作るには、実行の途中を観測できなければならない。最終出力だけを見ても、なぜ成功したか、なぜ失敗したかは分からない。途中の道具呼び出し、参照した記憶、モデルの判断、再試行、権限確認が追えなければ、改善できない。つまり、評価の質は、運行時と編成層の可観測性に依存する。

だから、下から読む必要がある。

L0 と L1 を知らずに、エージェントのコストは語れない。L2 を知らずに、どこまでモデルに任せるべきかは判断できない。L3 を知らずに、長期記憶や道具利用は設計できない。L4 を知らずに、多エージェントの編成はただの会話劇になる。L5 を知らずに、本番の権限は渡せない。L6 を知らずに、納品できる品質にはならない。L7 を知らずに、何を最適化すべきか分からない。

中間から始めると、答えを先に見て、問題を後で知ることになる。

たとえば、「エージェントにはメモリが必要だ」と言うのは簡単である。しかし、どの記憶をどこに置くのか。検索で取るのか、文脈に常駐させるのか。ユーザーごとに分けるのか、組織で共有するのか。古くなった記憶をどう捨てるのか。注入された偽情報をどう隔離するのか。これらを考えるには、下の層の制約を知らなければならない。

「多エージェントで分担する」と言うのも簡単である。しかし、通信コスト、待ち時間、責任境界、失敗時の再実行、ログの結合、権限の伝播を考えなければ、分担は複雑さを増やすだけになる。

「評価が大事だ」と言うのも簡単である。しかし、評価対象の実行が再現できないなら、評価は安定しない。途中状態が取れないなら、改善点が分からない。現場の成功条件が仕様に落ちていないなら、点数が上がっても役に立たない。

だから、この連載は土台から登る。

まず計算資源と推論の制約を見る。次にモデルを見る。その上で、運行時、編成、安全、研発体系、垂直応用へ進む。上の層を軽視するためではない。上の層を正しく設計するために、下の層から読む。

この連載の歩き方

この連載では、一回につき一つの層を扱う。

表面の用語を紹介して終わりにはしない。各層で、何が制約になり、どの抽象が生まれ、上の層にどんな影響を与えるのかを追う。製品名や流行語を並べるのではなく、なぜその仕組みが必要になったのかを、できるだけ因果で説明する。

次回は L0 と L1 を扱う。

題は、「推論のコストは黒板で逆算できる」である。

推論コストは、料金表だけを見ても分からない。トークンを一つ出すまでに、どのメモリを読み、どのキャッシュを持ち、どれだけ並列に処理し、どこで待つのかを見なければならない。エージェントが長い文脈を持ち、複数走り、何度も道具を呼ぶなら、そのコストはさらに積み上がる。

ここを押さえると、上の設計の見え方が変わる。

長いコンテキストを使うべきか。メモリ検索で済ませるべきか。安いモデルと高いモデルをどう分けるか。複数エージェントを並列にする価値はあるか。評価をどの粒度で回すか。これらは、すべて推論の物理から逆算できる。

まずは、そこから始める。

5分でわかる結論

持ち帰るべきことは三つである。

一つ目。エージェントは、「呼び出し」から「スケジュール可能なプロセス」へ移った。

単発のモデル呼び出しに道具を足すだけなら、壊れてもやり直せる。しかし、長く走り、状態を持ち、権限を持ち、複数並ぶなら、それは管理されるべき実行単位になる。そこで必要になるのは、プロンプトの工夫だけではなく、状態、資源、権限、失敗、観測を扱う基盤である。

二つ目。OS 化の核心は、運行時、編成、安全、評価の四つにある。

運行時は、エージェントを隔離し、記憶を持たせ、道具を呼ばせ、再開可能にする。編成は、複数のエージェントを並べ、通信させ、全体として仕事を完了させる。安全は、入力、記憶、道具、権限を横断して、何を信じ、何を止めるかを決める。評価は、最終出力だけでなく、途中の実行を含めて、仕事として成立したかを測る。

三つ目。これから希少になるのは、プロンプトを打てる人ではない。

モデル、道具、文脈、記憶、権限、評価を、一つの生産システムにつなげられる人である。

プロンプトは重要だが、それだけでは本番のエージェントは動かない。どのモデルをいつ使うか。どの道具をどの権限で呼ぶか。どの文脈を渡し、どの記憶を保存するか。失敗時にどこへ戻すか。何をもって成功とするか。どのログを見れば改善できるか。これらを一つの流れとして設計できる人が必要になる。

エージェントは、もう単なるチャットの延長ではない。

それは、計算資源の上に推論サービスが乗り、モデルが乗り、実行環境が乗り、編成と安全と評価が乗り、最後に現場の仕事が乗る、階層を持ったシステムになりつつある。

この階層を下から読むことが、これからのエージェントを理解する一番堅い道になる。

この記事は、独立ブログ AIウォッチ（aiwatch-jp） の連載「Agentic OS 技術スタックを下から読む」第0回です（初出：aiwatch-jp.pages.dev）。算力から応用まで一段ずつ下へ降りる全63回＋取引で読み直す姉妹編11回。

あわせて読みたい（本連載より）

第1回：推論のコストは、黒板で逆算できる ―― まず一段目、いちばん下の算力から
第12回：エージェントの記憶 ―― 保存ではなく「なぜそうしたか」を残す ―― 「プロセス」になったエージェントは、何を覚えるのか
第34回：層を束ねる外殻 ―― モデルを、制御できるループに収める ―― この記事で言う「管理する層」、その正体
第14回：段を重ねるほど崩れる ―― 信頼性の崖と、編成の型 ―― 複数のエージェントを、どう束ねるか
第49回（最終回）：下から読み終えた人へ ―― 何を学び、何を練習するかの地図 ―― 全部を読み終えた、その先へ

連載全体と、動くマップはこちら。