ジャスティン・シュローダー / Justin Schroeder · 02:27 「エージェントとは、 何らかの目的を追って、 モデルが生む非決定的な結果を飼いならす決定論的なソフトウェアだ」
導入は産業革命との対比から始まる。 産業革命の触媒は 「機械でエネルギーを飼いならしたこと」 だった。 いま起きているのは 「エージェントで知能を飼いならすこと」 で、 エージェントは 「かつての機械」 にあたる —— 知能を実際に使う道具だ、 と Justin は置く。 ところが、 誰もが 「エージェント」 の例は挙げられるのに、 定義はすぐ出てこない。 そこで彼は冒頭の定義を提示する。 併せて、 harness エージェントの実行を支える 「土台」 のソフトウェア。 Justin は harness と agent の区別を 「衒学的で役に立たない」 とし、 この講演では両者を同一視して進める と agent の区別は衒学的だから同一視してよい、 と割り切る。
問題設定はこうだ。 街角の不動産屋も、 独立系の保険ブローカーも、 Fortune 500 も、 誰もが自前のカスタムエージェントを作ろうとしている。 動機は integration (統合) 自社のデータを AI に適切に取り込むこと。 Justin は、 企業がカスタムエージェントを作る根本動機はここにあり、 それが最初に見つかる手段だから皆が作る、 と整理する —— 自社データを AI に取り込めば大きな成果が出ると信じているから。 だがエージェントは難しい。 agentic loop モデル呼び出し → ツール実行 → 結果の評価 → 次の行動、 を繰り返すエージェントの制御ループ。 適切なオーケストレーション、 provider 抽象、 障害復帰 (durable execution)、 検証・停止条件などが要る の丁寧なオーケストレーション、 provider 抽象、 障害復帰、 検証と停止条件。 多くはデモとしては動くが、 それ以上にはならない。 移植もできず (「自分のマシンでは動く」)、 使い回し (composable) もできない。
逃げ場として人々は 「MCP をやる」 に向かう。 MCP Model Context Protocol。 自社の情報や道具を Claude や ChatGPT のような大きな汎用エージェントに渡すためのプロトコル。 Justin は、 MCP クライアントで完全に埋まっている機能列は tools だけで、 事実上 MCP は 「ツール配布の仕組み」 になっている、 と指摘する は確かに動くが、 公式サイトのクライアント対応表で埋まっているのは tools の列だけ —— MCP は事実上 「ツール配布の仕組み」 になった。 だが 「一人に大量の道具を渡しても、 人類は月には行けなかった」。 では skills か。 skills は結局 markdown のドキュメントで、 「たくさん積むとエージェントはかえって悪くなる」 という研究もある。 道具も文書も、 根本問題ではない。
着眼点
スタックはほぼ全部 context —— 積み増しは 「継承」 で、 いずれ壊れる (09:56 - 13:07)
基本のスタックを積むと、 model → system prompt → tools → skills → MCP → messages となる。 ここで Justin が指す核心は、 「そのほとんどが context だ」 という点。 system prompt も tools も skills も、 全部エージェントの文脈に流し込まれる。 出張用の MCP、 Figma、 Playwright、 Gmail、 Google Sheets、 React の linter、 そして 「Matt の grill me skill」 —— こうして人は context 層をふくらませていく。
これを工学の言葉で 継承 (inheritance) 1 つのオブジェクトに属性を足していって能力を増やす設計。 Justin は、 大きな汎用エージェントに skills / MCP を積み増す現在の作法がこれにあたるとし、 動くが規模を増すと逓減して壊れる、 と論じる と呼ぶ、 と彼は言う。 1 つのオブジェクトに属性を足して能力を増やす。 いま皆がエージェントにしているのはまさにこれで、 追加の層を足すほどできることが増える。 継承は動く —— だから世に出回っている。 だが 「継承より合成 (composition over inheritance)」 という古い格言があり、 これは 「時代と同じくらい古い真理」 だ。 5 個の skills なら快適でも、 100 個、 1,000 個になれば、 文脈を足すほど得られる効用は逓減する。 誰もが暗黙に分かっているこの飽和が、 積み増し設計の限界を示す。
継承から合成へ —— 小さな完全エージェントを coordinator が束ね、 通信は 「ただの英語」 (13:07 - 16:18)
合成はこう見える。 Figma を担わせたいなら、 system prompt が 「Figma 専用」 に書かれた小さなエージェントを 1 つ作る。 それは Figma の API も、 押すべき場所も全部知っていて、 その動作に必要なちょうどの tools だけを持ち、 メッセージ履歴も Figma の分だけ。 Gmail も出張も Google Sheets も、 それぞれ独立した 「完全なエージェント」 にする —— tools を載せた小さなサーバーではなく、 自前の system prompt・メッセージ履歴・agentic loop を持つ本物のエージェントだ。 その上に coordinator (調整役) 複数のドメイン特化エージェントを束ねる上位エージェント。 下位の小さなエージェントとは 「ただの英語」 で会話し、 必要な仕事を割り振る。 multi-agent orchestration の中核 を置く。
小さなエージェントと上位エージェントの通信手段は、 なんと 「ただの英語」。 人間同士のように話す。 主エージェントが 「旅行の予定を確認するためメールを見よう」 と考えれば、 Gmail エージェントに旅行関連の新着を尋ね、 返ってきた 「今週末ロサンゼルスへの出張がある」 を受けて、 旅行エージェントに予約を頼む。 これが動くと分かるのは、 「人類が月へ行ったやり方そのもの」 だからだ。 それぞれ違う専門とスキルを持つ専門家チーム。 Justin は Apollo 11 の管制室の写真を指して 「ここにエージェントがいる」 と言う —— その脳が LLM、 ダッシュボードの計器が tools、 口が messages。 全ての道具を持つのではなく、 その道具だけを持ち、 それが抜群に上手い。 「エージェント世界の biomimicry (生体模倣) のようなもの」。 これを彼は ドメイン特化エージェント (domain-specific agent) 特定の領域だけに狙いを絞った小さな完全エージェント。 汎用の巨大エージェントに全部を積むのではなく、 領域ごとに分割し coordinator で束ねる。 Justin が本講演で提唱する中心概念 (本人は 「自分が最初に言った言葉ではない」 と断る) と呼ぶ。
ドメイン特化エージェントの 5 つの利点、 そして 「知能コストは 2026 に反転した」 (16:18 - 24:05)
Standard Agents で作り込んできた実感として、 利点は 5 つ。 第一に token efficiency (トークン効率) タスク遂行に要するトークン量の少なさ。 Justin は、 ドメイン特化エージェントでは 1 タスクあたり 80% を超えるトークン効率を日常的に見ると述べる。 各エージェントが会話全体ではなく最小限の文脈しか持たないため —— 会話全体の文脈を持たず、 「デビーからの最後のメールを取って」 という system message・tools・その 1 通だけで動くので、 1 タスクあたり 80% を超えるトークン効率が出る。 第二に移植性 —— Gmail エージェントを圧縮して他人に送れば、 皆が同じ skill を作り直さずに済む生態系になる。
第三に、 小さなモデルとの相性。 コスト差は桁違いで、 DeepSeek V4 Flash 小型で安価なモデルの例として引かれる。 Justin の試算では 1 タスクあたり Fable 5 の 137 分の 1 のコスト は Fable 5 より 1 タスクあたり 137 倍安い。 同じ用事に 137 倍払う感覚を思い浮かべれば、 その差は明白だ。 全部を高価なモデルにやらせる必要はなく、 専用に選ばれた小さな仕事だけを最小の文脈で忠実にこなせばよい。 第四に能力の厳格な制限 —— いまは誰もが permissions を左右にバイパスして 「太陽に近づきすぎて飛んでいる」 (大きなモデルは何でもできるので何でもやらせてしまう)。 小さなドメイン特化エージェントは、 明示的に許可された仕事しかできない。 「IT 部門の Doug に説明すれば、 その違いに彼は胸をなでおろす」。 第五にスケール —— 各エージェントが独立した小さな実行環境なので、 巨大な VPC 無しで並列化でき、 世界中の地域で何千インスタンスも同時に走らせられる。
唯一の難点は 「まだ (公には) 存在しない」 こと。 だが変わる、 と Justin は公開予測を置く。 2026 年後半にかけてドメイン特化エージェントとその framework の話が急増し、 2027 年は 「multi-agent orchestration の年」 になる。 Vercel が Eve (Vercel) Vercel が公開したエージェント構築 framework。 「company brain / personal assistant / domain-specific agent を作る」 と掲げ、 Justin が発信し続けた domain-specific agent という語が返ってきた例として挙げられる を出したのは、 彼が発信し続けた語が返ってきた最初の兆しだった。 背景には知能コストの反転がある。 多くの人は 「知能のコストは下がり続ける」 と信じているが、 Standard Agents の計測では 2026 年にこの傾向が反転した。 IQ 補正後でも今年 (半年で) トークン単価は約 30% 上昇、 補正しなければ 76% 上昇。 メモリ需給の逼迫もある。 だからこそ、 同じ仕事に 137 倍を払わずに済むドメイン特化エージェントが、 特に大企業と顧客対応で効いてくる。
動画の構成
- (00:00) ドメイン特化エージェントの予告、 自己紹介 (dmux / ArrowJS / Standard Agents)
- (00:56) 産業革命の対比 —— 機械でエネルギー、 エージェントで知能を飼いならす
- (02:10) エージェントの定義が未収束、 Justin の定義 (非決定的な結果を飼いならす決定論的ソフト)
- (02:39) agent と harness の区別は衒学的、 同一視して進める
- (03:57) 誰もがカスタムエージェントを作る、 動機は integration
- (05:15) エージェントは難しい —— loop / provider 抽象 / durable execution / 移植・合成の不可
- (07:35) 逃げ場としての MCP、 対応表で埋まるのは tools 列だけ = ツール配布機構
- (09:04) 「一人に道具を大量に渡しても月には行けない」、 skills はドキュメント
- (09:56) スタックはほぼ全部 context、 integration を context / model で解こうとする
- (11:25) 出張 MCP・Figma・Gmail・Matt の grill me skill で context をふくらませる
- (12:46) それは 「継承 (inheritance)」、 動くが 100・1,000 skills で逓減し壊れる
- (13:34) 合成 (composition) —— Figma 専用の小さな完全エージェント
- (14:38) coordinator が束ね、 通信は 「ただの英語」
- (15:32) 月着陸の専門家チーム、 Apollo 管制室に 「エージェントがいる」、 biomimicry
- (16:18) 「ドメイン特化エージェント」 命名、 Standard Agents の内側から
- (16:52) 利点1 トークン効率 80%+、 利点2 移植性と生態系
- (18:11) 利点3 小さなモデル、 DeepSeek V4 Flash は Fable 5 の 137 分の 1
- (19:31) 利点4 能力の厳格制限、 「太陽に近づきすぎ」、 Doug in IT の安心
- (20:29) 利点5 スケール、 並列・多リージョン・巨大 VPC 不要
- (20:56) 難点 = まだ存在しない、 2026 後半に急増・2027 は multi-agent orchestration の年
- (22:37) 知能コストの反転、 トークンは IQ 補正後 +30% / 未補正 +76% (今年半年)
- (23:57) 顧客の前に高価なモデルは置けない、 効率と実効性の両立
- (24:05) 理想のエージェント解剖 —— tools (functions / prompts / sub-agent)、 hooks、 agent rules
- (27:00) 全エージェントに file system と sandbox コード実行を primitive として
- (28:01) 再帰的サブエージェント、 coordinator → Salesforce → Google Workspace / 資産生成 / 法務 → GDPR・OSHA
- (30:06) 最小の文脈を保ったまま多数の小エージェントが協働する、 standardagents.ai
関連リソース
- The Future Is Domain-Specific Agents — AI Engineer 公式 (講演動画)
- Standard Agents (standardagents.ai、 early access 受付中)
- ArrowJS — 「エージェント時代の UI フレームワーク」
- FormKit (Justin の代表 OSS)
- 関連: Bret Taylor 「エンタープライズソフトの未来は垂直エージェント」 (同じ領域特化の思想)
- 関連: Rachel Lee Nabors 「フロンティアモデルへの課金をやめる」 (小さなモデルの right-sizing)
用語集
- ドメイン特化エージェント (domain-specific agent)
- 特定の領域だけに狙いを絞った小さな完全エージェント。 自前の system prompt・tools・メッセージ履歴・agentic loop を持つ。 汎用の巨大エージェントに全部を積むのではなく、 領域ごとに分割し coordinator で束ねる。 本講演の中心概念で、 Justin は 「自分が最初に言った言葉ではない」 と断る。
- 継承 (inheritance) と合成 (composition)
- 継承は 1 つのオブジェクトに属性 (skills / MCP / tools) を足して能力を増やす設計。 動くが、 skills が 100・1,000 と増えると文脈が飽和して逓減する。 合成はその代替で、 小さな独立エージェントを組み合わせる。 「composition over inheritance」 という古い工学格言を AI 設計に持ち込む。
- agent の定義 (Justin 版)
- 「何らかの目的を追って、 モデルが生む非決定的な結果を飼いならす決定論的なソフトウェア」。 Justin は agent と harness の区別を衒学的として同一視する。
- MCP (ツール配布機構としての)
- Model Context Protocol。 自社の道具を Claude や ChatGPT のような汎用エージェントに渡す。 クライアント対応表で完全に埋まっているのは tools 列だけで、 事実上 「ツール配布の仕組み」 になっている、 と Justin は指摘する。 「道具だけでは足りない」。
- context の膨張
- system prompt・tools・skills・MCP・messages がすべてエージェントの文脈に積み上がること。 integration を 「context か model」 で解こうとする現在の作法の症状。 積むほど効用が逓減する。
- coordinator (調整役)
- 複数のドメイン特化エージェントを束ねる上位エージェント。 下位の小さなエージェントとは 「ただの英語」 で会話し、 必要な仕事を割り振る。 multi-agent orchestration の中核で、 月着陸の管制のような役割。
- 再帰的サブエージェント (recursive sub-agent)
- あるエージェントの tool として、 別の完全なドメイン特化エージェントを置ける設計。 coordinator → Salesforce → Google Workspace / 資産生成 / 法務 → GDPR・OSHA、 のように多層に連なる。 各層は最小の文脈だけを保つ。
- hooks / agent rules
- 理想のエージェントの構成要素。 hooks は副作用や書き換え (例: 「今何時か」 を人工的なメッセージとして文脈に注入)。 agent rules は 1 ターンの最大ステップ数や、 ツール呼び出し時の検証要否など、 エージェント固有の規則。
- 知能コストの反転 (2026)
- 「知能のコストは下がり続ける」 という通念に対し、 Standard Agents の計測では 2026 年にトークン単価が上昇に転じた。 IQ 補正後で今年 (半年で) 約 30%、 未補正で 76% の上昇。 メモリ需給の逼迫が一因。 だからこそコスト効率の高い設計が要る、 という論拠。
- token efficiency (トークン効率)
- タスク遂行に要するトークン量の少なさ。 各ドメイン特化エージェントが会話全体ではなく最小限の文脈しか持たないため、 Justin は 1 タスクあたり 80% を超える効率を日常的に見ると述べる。 小さなモデルでも実務が回る土台。