Super-agent 設計探索：より自律的な Agent システムへ

1. Super-agent

この一年、Coding Agent に代表される単一タスク Agent は、モデルがツールを使って複雑な問題を解けること、そして人間の継続的な監視と段階的な介入がますます不要になることを証明した。同時に、複数 Agent 間の協調能力も向上し、セッションをまたぐ組織化とディスパッチが現実味を帯びてきた。下層の実行における人間の関与が減るにつれ、人の役割はより高次の意思決定と受け入れへと移っていく。

こうしたモデル能力の向上は、新たな応用形態も生んだ。最近、Personal Agent が相次いで登場している。日常のメッセージ、スケジュール、メール、業務プラットフォームに直接接続し、情報の流れを絶えず観察して用務を処理する。この常時オンラインでイベント駆動の働き方は個人のシーンに限らず、Personal Assistant はその一類にすぎず、ソフトウェア開発などの商用シーンでも同じように価値がある。

しかし既存の主流 Agent 設計では、この働き方を多タスク・チーム協働の規模で支えられない。Agent の仕事は依然として単一 Session を基本単位とし、Session どうしは互いに独立している。ユーザーが複数の業務を並行すると、手動で切り替え、各 Session のコンテキストを記憶しなければならない——そして私たちの観察では、一人が同時に追えるのは 3〜5 のアクティブ Session が関の山だ。この設計では、単一タスクの上限はモデル能力、マルチタスクの上限は人の注意力で決まる。

既存のローカル単一セッション Agent を CLI、MCP、外部コネクタで単純に拡張しても、外部メッセージを受け取れるようにはなるが、単一セッションの同期ブロック、マルチタスクのコンテキスト混濁、端末オフラインで停止するといった問題は解けず、大量の手動維持を必要とする。

これらの制限を破るには、Agent を一回の手動セッションへの束縛から解き放ち、セッションをまたいでコンテキストを保ち、干渉せずに複数の複雑タスクを並行して進める連続的な存在にする必要がある。私たちはこの Agent の形態とそのシステムアーキテクチャを Super-agent と呼ぶ。

例えば、DeepSeek Harness 上で社内運用されている Super-agent インスタンスでは、一つの開発タスクが IM と GitHub の間で連続的に進む。このインスタンスは公開グループチャットのフィードバックも絶えず観察し、誰にも @ されなくても根本原因を特定して修正 Pull Request を提出する。

具体的に、Super-agent は次の四つの基礎特性を持つ：

• 連続：ユーザーは IM チャットや GitHub コメントなど慣れ親しんだ作業界面で直接やり取りでき、常に一つの Agent だけが存在するように感じる。「Session X のコンテキストに情報 Y はあったか」と考える必要はない。IM で案 A を提案し、その後 GitHub PR のコメントで案 B に変えても、理解して実行方向を調整できる。
• 高效：対話応答が速く、同時に複数の複雑タスクを並行して高品質に完遂できる。前のコマンドやタスクの完了を待たずに次の指示を受け取れる。
• 能動：ユーザーの命令を一件ずつ待つ必要がなく、環境イベントを絶えず観察して対処する価値のある事項を自ら進め、介入が不要なときは静かにしている。
• 持続：常時オンラインで、ユーザーの実際の作業環境に直接接続し、長期運用で異常が起きても自動回復する。

単一の ReAct Loop では四特性を同時に支えられず、下層に一つのアーキテクチャが要る。似た設計制約は似たアーキテクチャ選択を導く。個人向けアシスタントでも、ソフトウェア開発などの商用 Agent でも、常時オンラインで環境イベントに並行応答するシステムを目指すなら、下層のアーキテクチャは近いものになるだろう。また、ここで直面する問題の多くは古典的なコンピュータシステムが長年論じてきた問題と非常に似通っており、システム設計の古典的な知見がそのまま適用できる。

実装には変種がありうるが、四特性を支える基本骨格は五つのモジュールだと私たちは考える：二層アーキテクチャ（第 2 節）で連続な対話と高效な並行を両立し、イベント駆動（第 3 節）で能動的な応答を実現し、人間向けの対話（第 4 節）で対話自体を連続かつ高效にし、計算・状態・環境の分離（第 5 節）と Watchdog（第 6 節）でデバイスをまたぐ持続的なオンラインと自己回復を可能にする。

2. 二層アーキテクチャ

チャネルをまたぐ連続な対話とマルチタスクの高效な並行を同時に実現するには、下層のセッション組織において連続性とスループットの根源的なトレードオフに直面する。

すべてのイベントを同一 Session で処理すればコンテキストは最も連続するが、単一 ReAct Loop の逐次実行速度が上限となり、完了まで時間がかかりスループットは低く、複数タスクの中間詳細が混ざって品質を損なう。

逆に、すべてのイベントで独立 Session を新規作成すれば並行スループットは最大だが、タスクが完全に独立でない限り、大域コンテキストの欠如が各 Session の結果を互いに断片化し、複数 Session がそれぞれユーザーに応答すれば対話は混乱する。

両者を両立するため、「大域の連続性の維持」と「高並行実行」を二つの階層に分ける：常駐の Router 層（2.1）がすべての人間との対話と大域調整を受け持ち、コンテキスト分離された Worker 層（2.2）がタスクを並行実行する。

この二層構造により、システムは下層でコンテキスト管理と並行実行を引き受け、ユーザーの側では Session の存在を薄れさせ、ユーザーが向き合うのは常に一つの Super-agent にする。こう見ると、ユーザーに Session を手動管理させるのは、大きな程度で、基盤の LLM API から引き継がれた設計の惰性であり、Session はシステムの実装詳細であってユーザーの認知負担であるべきではない。

ここでの「二層」は論理的な責務分割であり、各層は実装上単一 Session に限定されず、独自の内部構造を持てる。以下、各層の設計を述べる。

2.1 Router 層

Router 層は常駐の大域ルーティング層であり、すべての入口の人間との対話を受け持つ。タスクをまたぐすべての情報と意思決定はここに集約され、Router は大域の順序点（Sequence Point）、調整点、記憶として機能する。この大域ノードがボトルネックにならないよう、Router 層は設計上タスクを直接実行せず、人間との対話とタスクの割り当てだけを行う。Bash ツールを装備しなくてもよい。

一つの中心ノードが複数の実行ノードに割り当てる構造は、表面的にはよくある Agent Team に似るが、重点が異なる。Agent Team は主に一つの複雑タスク内部の工程分解と役割協働に使われ、下位工程は密結合なため Team Lead はタスクの詳細を深く理解し、サブタスクを計画し、メンバーを高頻度で調整する必要があり、自ら重い推論負荷を負う。Super-agent では、Router 層はタスク間の高レベルな関連と割り当てだけを扱い、単一タスク内部の分解には立ち入らない。逆に、Agent Team の主セッションをプロンプトで「自ら実行せず、対外応対とメンバーへの割り当てのみ」と制約すれば、それもこの二層アーキテクチャと見なせる。実践では、Router 層のタスクは想像より複雑でないことが多く、軽量なモデルで速度と品質を両立できる。

内部実装でも Router 層は単一 Session に限定されず、一部のロジックは LLM を呼ぶ必要すらない。私たちは最も素直な「単一の常駐 LLM Session」を Router 層の中核とし、これが見た目ほどボトルネックになりにくいことを見出した。前回の推論中に到着した環境イベント（第 3 節の Trigger）は積み上がり、次のラウンドで一括処理される——バッチ処理（Batching）であり、統合処理の追加コストは小さい：

• 外部イベントの流れが穏やかなときは Trigger が一つずつ Router Session に入り、単発応答の遅延は低く保たれる。
• イベントが殺到して Router Session が渋滞し始めると、前回の推論中に積もった複数の Trigger が自動的に統合され、次の LLM 呼び出しで一括注入される。Router の各ステップは典型的に「長い入力・短い出力」であり、積んだ Trigger を一回の API 呼び出しに纏めると Prefill が並列計算されるため、単発リクエスト所要時間の増加はバッチサイズよりずっと遅い。一定の範囲内では、滞留が多いほど一決定あたりの推論時間は下がる。上限はコンテキスト長と、モデルが一回で正確に処理できる Trigger 数による。

7.2 節でこのバッチ処理の効果を定量的に示す。後述の購読・直通の仕組みと連鎖リコール（3.2、3.3）を加えれば、単一の常駐 Router Session は現在のチーム規模で十分である。

規模がさらに拡大し、単一セッションでは賄えなくなると、Router 層の内部は多段フィルタ構造にするか、水平分割（Sharding）で複数セッションにできる。そのとき Router 層の内部設計自体が連続性対スループットのトレードオフになる。分割を細かくするほど並行スループットは上がるが、分割間の記憶とコンテキストの連続性は下がる。大域記憶の問題が解決されるまで、このトレードオフは続く。

2.2 Worker 層

Worker 層は実行を担うセッション群で、各 Worker は互いにコンテキスト分離され、完全な実行ツールを搭載し、独立したコンテキストで単一タスクに集中する。Worker Session がタスクの結果とコード品質を直接決めるため、通常は最強のモデルを配置する。

Worker は人間と直接やり取りせず、その推論過程とツール呼び出しは外部チャネルに出力されない。Router 層に状態を報告し、Router がユーザーに統一的に返答する。これにより並行度と成果物の品質を保ちつつ、複数セッションがバラバラに応答する混乱を避ける。

マルチタスク並行時、各 Worker は独立して進み、同層 Worker 間で直接通信は通常不要である。衝突は多くの場合、同一 Pull Request などの共有作業環境で起きるが、双方が対応 Thread を購読していれば同一のイベント通知を受け取り（3.2）、自分たちで発見・解決できる。まれな横断タスクの調整は Router 層が中継する。

Router 同様、各 Worker Session も内部では単一セッションに限定されない：複雑なタスクでは内部に Subagent を作れるし、それ自体が Agent Team でもよく、それは上位 Router からは透過だ。この構造はコード協働（複数の独立した再現、PR レビュー、機能開発を互いにブロックせず並行）にも、Personal Assistant にも当てはまる：UI は単一チャットでも、同じダイアログで複数話題を扱うとき、フロントの単一チャット画面が対話の連続性を維持し、下層は話題ごとに Worker を割り当てて並行にタスクを進め、返答を起草できる。

3. イベント駆動

能動性を持たせるには、まず駆動方式を変える必要がある。Agent を駆動する主入力は、セッションで人間が打ち込むプロンプトではなく、環境の半構造化イベントになる。Super-agent では、グループチャットのメッセージ、メールやスケジュール通知、コードレビューコメント、CI 実行結果などの環境イベントを Trigger と呼ぶ。Trigger を監視して応答することで、Agent は単一 Session のように人間の命令ごとに一回受動実行する必要がなくなる。

イベントが到着してから処理されるまでのライフサイクルに沿って、四つの漸進的な問いを扱う：プログラムとモデルを組み合わせた二段戦略で大量のノイズを除去する方法（3.1）、購読と直通でイベントを Worker に届ける方法（3.2）、Inline & Spill と連鎖リコールで高密度に注入し必要時に呼び戻す方法（3.3）、そして投機的実行で環境シグナルに基づき裏で先行する方法（3.4）。

3.1 イベントフィルタ

現実のグループチャットとコード基盤に接続すると、イベントストリームは顕著に「高ノイズ・低トリガー率」である。日常メッセージの大多数は Agent の介入を要さない。全イベントを LLM で逐一判断すれば、遅延も計算コストも耐えられない。システム設計の Fast Path / Slow Path の考えを借りれば、LLM 推論は柔軟だが高コストな Slow Path であり、明確で安定な高頻度判断を決定的コードに固定すれば、低遅延・低コストの Fast Path になる。

そこでイベント流入の第一歩はフィルタである。モデルを呼ぶ前に決定的ポリシーでノイズを篩い、意味理解が必要な候補だけをモデルに渡す。プログラムと大モデルを組み合わせた二段フィルタを採る：

• プログラム層ポリシー（Fast Path）：イベントの出所、グループ範囲、ユーザー/ボットの許可リストなどの決定的条件をコードで素早く検査する。例えば出所ごとに「明示的な要求にのみ応答」「候補イベントとする」「無視」を設定し、モデル呼び出し前に無関係なメッセージの大部分を除去する。
• 意味層ポリシー（Slow Path）：プログラム層を通過した候補を LLM に渡し、プロンプトで書かれたポリシーと文脈から行動要否を判断させる。意味層は人間向けの自然言語拡張点でもあり、プロンプトのオンオフや追加でいつでも調整できる。

3.2 イベントルーティング

Router 層はチャネルをまたぐ連続性を保つが、割り当て済みタスクの後続イベントまでいちいち Router 経由だと、大域ノードが高負荷を背負い応答遅延が上がる。そこで Fast / Slow Path はルーティングにも適用される。Router 層は新規タスクのコールドスタートとタスク間調整のみを担い、帰属が確定した後続イベントはプログラムが対応 Worker セッションへ直接送る。

実際のワークフローでは、同一 GitHub Pull Request、同一 IM トピック、同一メールスレッド下の一連のイベントが一つのイベント流——Thread——を構成する。Router 層がある Thread の初期イベントから Worker Session を作成した後、その Worker は当該 Thread を直接購読し、ルーティングは二経路に分かれる：

• 購読済み（Fast Path）：同一 Thread の後続イベントはプログラムから購読 Worker へ直通し、Router の転送を要さない。新しいイベントが現在のタスクの範囲を超える場合は、Worker が購読を解除するか Router に戻して再割り当てできる。
• 未購読（Slow Path）：Router 層は大域把握のため全イベントを観測できるが、未購読の新規イベントの判断と割り当てのみを行う。

さらに Thread と Worker の購読は多対多である。一つの Worker は複数の関連 Thread を購読でき、一つの Thread を複数 Worker が購読してもよい。複数 Worker が同一の作業環境や議論で交差すると、その Thread の新イベントは購読者全員に同時直通され、点対点通信なしにお互いの操作を知り、衝突を自ら解消できる。出力側では、Worker は重要な結論を Router 層に報告し、Router がユーザーに統一的に返答し大域記憶を更新する。

3.3 コンテキスト組織

フィルタとルーティングを経てイベントが対象 Session に入った後の問いは、モデルのコンテキスト窓にどれだけ注入するかである。入力が限られた人間のプロンプトから、環境が絶えず生成する半構造化イベントへ変わったいま、ツール呼び出しとイベント注入の構造設計がより重要になる。注入しすぎれば窓を圧迫し注意を希釈し、少なすぎればツール呼び出しの往復でステップが増える。コンテキスト窓の無駄は、モデルの知性の無駄である。

そこで有限のコンテキスト窓をキャッシュとして管理する。コンパイラ最適化とシステムの概念を借りれば、注入設計は二つの基本操作に帰着する。Inline は近期に使いそうな情報を現在の窓に直接載せ、ツール呼び出しの往復を省く。Spill は窓の予算を超えるか低頻度の完全な情報を窓の外に置き、中には参照や要約だけを残して必要時に読ませる。

古典的な局所性（Locality）の考えと合わせ、Inline & Spill で注入とツール呼び出しを段階的に最適化する：

1. 最少情報から始める：最初は対象の ID と内容の要約だけ。
2. 局所性で関連情報を Inline：近く使いそうな情報から窓に入れる。密接に関連する対象の ID を先に付け、次に時空的に隣接する内容——本文の先頭 50 字、IM メッセージの前後と返信元、レビュー議論の隣接コメント——を添える。
3. 上限超過は Spill：すべてを Inline できない長文には小さな長さ上限を設け、超過分は窓の外に Spill する。単純な方法は超過分を切り詰め、続きを読む入口を残し、モデルが必要時にツールで読む。

さらに、大量の後続イベントが Worker に直通し、システムが長期運用で履歴タスクを積むと、Router 層は全タスクの全履歴を自分の窓に入れられないし、かといってユーザーがチャネルをまたいで旧タスクに言及したとき文脈を取り戻せなくてもならない。Inline & Spill を各種オブジェクトに一貫して適用すると、必要時に展開する多段検索の仕組み——連鎖リコール（Chain of Recall）——が得られる。これにより Router 層の長期にわたる情報喪失が緩和される。

具体的には、Trigger、Thread、Worker Session などのオブジェクトに一意 ID を与え、注入時に密接に関連する対象の ID を Inline し、下層で参照グラフを構成する。ツールで呼び戻したオブジェクト自体も Inline & Spill に従うため、その返却結果に次ホップの要約と ID が含まれ、モデルは現在のイベントから参照関係を辿って段階的に文脈を呼び戻せる。例えば現在のメッセージから所在 Thread を読み、Thread の Inline された ID から関連 Worker Session を追い、さらにその Worker が関連する別のコードレビュー Thread に到達する。

3.4 先行行動

システム設計の投機的実行（Speculative Execution）を借りれば、Agent は結果が採用されるか不確実なうちに、環境シグナルに基づいて裏で先行試行できる。余分な裏側計算で人間の待ちと介入のコストを減らす。価値があれば成果を渡し、なければ捨てる。

Personal Assistant では、会議招待や To-Do メッセージを受け取ると、裏でスケジュール衝突を確認し、背景資料を集め、返信の草案を用意する。ユーザーは一目確認して送るだけである。開発協働でも同様で、私たちは社内の DeepSeek Harness ユーザーグループに「黙って再現して修正」というポリシーを設定した：誰かが問題を報告したり変更案を議論したりすると、Agent は裏で再現と修正案の探索を先に始め、問題が確認され簡単な修正が見つかった場合にだけ結果を渡し、それ以外は最後まで静かにしている。

4. 人間向けの対話

第 2 節の二層アーキテクチャはコンテキスト面でチャネル間の連続を保証したが、実際の対話体験で連続と高效を同時に成すには、対話方式と経路の二点を解決する必要がある：一つは非同期 ReAct Loop で、裏で時間のかかる操作が前面対話をブロックするのをなくし、前のコマンドやタスクの完了を待たずに次の指示を受けられるようにすること（4.1）。もう一つは、ユーザーが慣れ親しんだ各作業チャネルで、出力方式をそのチャネルの帯域と人の習慣に合わせること（4.2）。

4.1 全二重対話

古典的 ReAct Loop では、同期の run() ツール呼び出しの後、ツールが完了して結果を返すまでループがブロックされ、その間セッションは新しい入力に応答できない。このブロックを除くには、一問一答の半二重から全二重へ転換する必要がある。

そこで時間のかかるコマンドとサブタスクのツール呼び出しを非同期の start() と stop() に改め、非同期 ReAct Loop を構成した。start() の呼び出しは直ちに「開始済み（Started）」を返し、ループはそのツールを待たない。裏でツールが完了すると、システムが最終結果を新しいイベントメッセージとしてセッションに届ける。また、モデルは文脈に応じて stop() を呼び、長時間実行されている裏コマンドを自ら終了できる。

これにより前面対話の応答と裏タスクの実行が分離され、Agent は長時間タスクを裏で動かしながら人間の入力に応答できる。新しい入力は現在の推論ステップの直後に処理され、裏ツールの完了を待たない。この非同期タスク機構は DeepSeek Harness に実装済みだが、デフォルトでは有効化されていない。

4.2 マルチチャネル対話

作業チャネルごとに情報密度と対話習慣が違い、出力はそれに合わせる必要がある。単一端末向けの対話をそのままグループチャットに持ち込み、冗長な推論過程と高密度のツール呼び出しを生で流せば、多人数協働で情報過負荷になりやすい。

Super-agent では、二層アーキテクチャがこの一部をすでに解決している：タスク内の冗長な推論と密集したツール呼び出しは Worker Session 内部に隔離され、外部チャネルには直接出力されず、Router 層が対外応対を統一的に担う。その上で、ユーザーの日常の各作業環境に接続し、プロンプトでチャネルごとの対話規範を定める：

• IM などの即時通信：低侵襲の軽量コミュニケーションを重視し、人間の同僚のように意思決定や受け入れのときだけ通知を送り、直接的な質問だけし、結論は短く。単純で効果的な硬い規則として、一回の返信は 100 語以内と検証済みである。
• GitHub、メール、ドキュメントなどの非同期チャネル：構造化された高密度の非同期成果を重視する。Pull Request の作成・更新ではプロジェクト規範に沿って問題背景、変更説明、検証結果を完全に書き、Personal Assistant では構造化されたメールやドキュメント要約を直接起草する。

5. 計算・状態・環境の分離

既存のローカル Agent は、Agent Loop を進める計算、永続化すべきセッション状態、そしてコードリポジトリやローカルツールチェーンなどの実行環境を、デフォルトで同一端末に束ねている。端末がスリープやオフラインになれば Agent は停止し、他端末の環境にもアクセスできない。Super-agent が持続オンラインで実際の作業環境に柔軟に接続するには、システム設計の存算分離（Compute-Storage Separation）の考えを借り、二段階でこの束縛を解く：第一段階でループの計算と永続化されたセッション状態を分離し、単一マシンのライフサイクル制約から解放してクラウド常駐を実現する（5.1）。第二段階でクラウドの Agent Loop と重い状態の実行環境を分離し、実際の作業環境は現地に残したままデバイス間アクセスを可能にする（5.2）。

5.1 計算と状態の分離

Agent Loop を進める計算はステートレスにでき、永続化すべきはセッション状態である。第一の分離は、ループの計算をクラウドのステートレスな弾性コンテナに置き、Session などの永続状態をデータベースに格納する。ステートレスなコンテナは水平拡張・再起動・入れ替え自在で、セッションとタスクの連続性は永続ストレージが保証し、Agent は単一ローカル端末のライフサイクルから解放されてクラウドで常時オンラインになる。

5.2 計算と実行環境の分離

ループと状態がクラウドに常駐した後の問題は、タスクに必要な実行環境へのアクセスである。モデルが必要とするコンテキストの多くは、リポジトリ、ローカルファイル、依存サービスなどの実行環境からツール呼び出しで得られる。この意味で、広義のコンテキストには実行環境そのものも含まれる。

よくある二案がある：一つはクラウドでサンドボックスを起動しコードを引き取り環境の再構築・同期を試みるが、実際の作業環境には未コミットの変更、秘密のクレデンシャル、社内ネットワーク依存、特定のハードウェアやツールチェーンが含まれることが多く、同期は高コストで情報漏れも起きやすい。もう一つはユーザーにローカル環境の放棄とクラウド移行を求めるが、多くのユーザーには移行コストが高すぎる。

複製・同期が難しいのは環境そのものなのだから、実行環境をクラウドに上げる必要はない。第二の分離では、Agent Loop はクラウドで動かし、重い状態の実行環境は現地に残し、端末側にはセッション状態を保持しない軽量 daemon を置く。daemon はコマンドの実行と結果の返却だけを担い、実行環境をクラウドの外に置いたまま Agent が必要に応じてそのコンテキストを読む。

この考えは Anthropic の「脳と手の分離」（Decoupling the brain from the hands）と一致する。harness をステートレスに保ち、セッションログを harness の外に置き、統一インターフェースで実行環境を必要に応じて接続する。違いはシーンである。先の記事はマネージドサービスを述べ、オンデマンドのサンドボックスや顧客 VPC 内のリソースを主に論じている。ここでまず接続するのは、ユーザーが日常使い、断続的にオンラインかもしれない個人機——未コミットの変更とローカルクレデンシャルを載せた——である。よってこの設計は BYOM（Bring Your Own Machine）、すなわち日常の開発機や個人 PC の接続も、クラウドのマネージド機やオンデマンド計算環境の接続も支える。

これにより Agent は一台のマシンに縛られず、タスクに応じて実行デバイスを切り替え、必要な環境でコマンドを実行しそのコンテキストを取得できる。断続的にオンラインする端末も支える。例えばユーザーの個人機が再オンラインした後、クラウド Agent が自動で発火し、その端末で実行が必要だったタスクを完了する。

6. Watchdog

持続オンラインには、存算分離に加え、長期運用で異常から自動回復できる仕組みが要る。常時オンラインの分散システムは、主システム内部のロジックだけでは長期の信頼性を保証しにくく、主システムの外に独立した制御ループ——Control Loop——を置く必要がある。

また Agent システムでは、従来のプロセス生存探知や監視スクリプトだけでは足りない。多くの異常はプロセス崩壊ではなく、モデルが無効なループに陥るか目標から外れることだからである。長期運用する Agent システムは、インフラの生存だけでなくタスク自体の進捗も監視しなければならない。

私たちは主システムの外に独立した Watchdog Session を置き、定時メッセージで駆動して外部 Control Loop を構成した。Watchdog は API エラーや状態復旧失敗などのインフラ障害を処理するほか、モデルに各 Worker が実質的な進捗にあるか、方向が全体目標から外れていないかを判断させる。異常を発見すれば速やかに介入・修復し、外部の一過性障害には回復するまで継続的に再検査する。Watchdog 自体も完全なツール能力を持つ Agent Session なので、保守者は自然言語で故障原因を尋ねたり、プロンプトの追加削除やトリガー規則の調整など、主システムの振る舞いをオンラインで修正させたりできる。

7. 初期実験

前文の中核的なスケジューリングとルーティング設計を評価するため、二層の実験を行った：まず端から端までの実験で二層アーキテクチャ・購読直通と単一 Session 案を比較し（7.1）、次に Router 層のバッチ処理を単独で試験した（7.2）。実験は合成負荷と簡略化された環境に基づいており、結果は初步的な参考にとどめる。

7.1 検証（アブレーション）実験

グループチャットと GitHub CI のメッセージ流で四つの案を同時に駆動した：一回の実験に約 300 件のメッセージが含まれ、うち約 20 件が作業リクエスト、残りは雑談、フォロー、中止、CI メッセージである。コーディング作業は時間だけを消費するツールに置き換えたため、実験が測るのはシステムのスケジューリングと協調能力であり、単一タスクの実行能力ではない。各案を 5 回繰り返した。

比較した四案は Super-agent、直通を除去した Super-agent、そして二種のプロンプト構成による単一 Session + Subagent ツールである。中立プロンプトは "Use a subagent for a piece of work when appropriate..."、委派優先プロンプトは "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..." と書く。

タスク完了時間では、Super-agent の p50 と p95 はそれぞれ 12.4 分と 15.7 分で、Subagent ツール付き単一 Session を明確に上回った。理由は、Subagent 付き単一 Session が実験シーンではプロンプトの影響を強く受け、主 Session がしばしば自分で実行することを選び、総完了時間が長く不安定になるためだ。中立プロンプトでは、モデルは 5 回の実行で一度も Subagent を呼ばず、すべての作業が主 Session で進められ新メッセージに中断され続け、p95 は 29.5 分に達した。委派優先に変えると 5 回中 4 回で委派し、完了時間は縮んだが全体では Super-agent より遅く、残る 1 回は作業を「小さい」と判断して自ら実行し、図の紫の長い裾を形成した。単一 Session でプロンプト工学とモデルの臨場判断に任せるより、二層アーキテクチャは Router が具体的作業を直接実行せず、Worker が購読 Thread のメッセージだけを受け取ることで、この問題をシステムの層で緩和する。

システム費用の面では、複数の独立セッションを維持するため、Super-agent の一回あたりのキャッシュ読み取りトークンは単一 Session より多く、より多くのトークンをより短く安定した完了時間と交換している。Super-agent 内部で直通を除去すると、完了時間は完全版とほぼ同じだが、Router が下す必要のある決定は約 30% 増え、総キャッシュ読み取りトークンは 2,323 万から 3,177 万に増加（約 +37%）した。この負荷では直通は完了品質と速度を高めないが、Router Session のためにかなりのトークンと推論費用を節約する。

7.2 Router 層のバッチ処理

2.1 節の単一常駐 Router Session のスループット上限とバッチ処理を検証するため、Router 層単独のストレステストを行った：Router は実モデル、Worker は Mock モデルとし、判断が必要な Trigger の到着レートを毎分約 1 件から約 40 件まで段階的に上げ、平均バッチサイズ、単発リクエスト所要時間、一決定あたりの推論時間を観察した。

到着レートが毎分約 1 件から約 40 件に上がると、平均バッチサイズは 1.0 から 2.8 に増え、一方で単発リクエスト所要時間は 2.5 秒から 3.9 秒にとどまり、増加はバッチサイズより遅い。その結果、一決定あたりの推論時間は 6.4 秒から 1.6 秒に低下した。外部イベントが急増しても、Router 層は滞留を自動統合して実効スループットを上げられることを意味する。7.1 で直通除去により Router のピーク負荷が増えても単一 Router のスループット上限に達しなかったこともこれで説明できる。したがって現在のチーム規模では、大域コンテキストの連続性を犠牲にしてまで Router 層を早期に水平分割する必要はない。

8. 未解決の問題

第 2〜6 節の五つのモジュールが Super-agent を支える基本アーキテクチャを構成し、第 7 節の実験はマルチタスク並行下での中核的スケジューリングとルーティングの効果を検証した。このシステムが低い複雑度で動いているのは、現段階で一連のエンジニアリングとシーンの簡略化を行ったからである。これらの適用範囲を超えると、二層アーキテクチャの拡張（8.1）、Session から離れた後の人機協働（8.2）、コンテキスト境界と A2A（8.3）、セキュリティとプライバシー（8.4）に、なお解決すべき問題が残る。

8.1 二層アーキテクチャの拡張

「単一常駐 Router Session + 購読直通 + Worker 間の直接通信なし」という簡略な組合せで、小さな工数で現在の大半の日常タスクを覆っている。しかしタスクの規模と結合度が増し単一 Router Session の許容を超えると、層内の具体的構造には定説がなく、Router 層をいつ水平分割するか、粒度をどう分けるか、Worker 間にいつ直接通信を導入し、どういう協調トポロジーを取るかは、より多くの場面での検証を待つ。同時に、システムとモデルの協同設計（Co-design）も探る価値があり、Router 層のイベント判別、一括割り当て、コンテキスト呼び戻しなどのタスク向けに特別訓練すれば、スループットと意思決定品質をさらに上げられる可能性がある。

また、常駐 Router 層と参照グラフに基づく連鎖リコールが主に解くのは、近期タスクとセッション履歴の必要時検索である。運用期間が月をまたいで長くなると、長期記憶が拡張性を制約する主要なボトルネックになる。

8.2 Session を離れた後の Agent との協働

二層アーキテクチャで下層のマルチセッション管理をユーザーから隠し、Session は製品設計の第一問題ではなくなった。しかし下層の実行セッションが UI 上の会話に直接対応しなくなると、タスクをどう呈示し、自然な対話とプロジェクト管理の形式をどう提供するかが新しい問題になる。チャットウィンドウ中心の対話は、一定程度、経路依存の産物だと私たちは考える。対話はもっと領域特化した画面で行われてもよく、例えば本稿の実例のように、Super-agent が GitHub の Issue と Pull Request で直接働く。Session は使用習慣のために UI に残してもよいが、ユーザーが見る一つの会話が下層で一つの Session だけに対応するとは限らない。

また本稿が主に論じたのは、タスクの開始と結果の受け入れにおける人間の関与である。モデル能力が急速に変わる過渡期には、多くのタスクが依然として途中の人間の参加を必要とし、重要な細部への段階的な介入と、裏側の自律推進の効率をどう両立させるか——実行の途中にいつでも入る、引き取る、Agent とリアルタイムで協働する——も探るに値する。総じて、ユーザーが必要とするプロジェクト管理と対話形式は業務領域と個人の流儀に強く依存し、最終形は高度にカスタマイズされる可能性が高い。DeepSeek Harness はオープンなアーキテクチャを採るため、この種のカスタマイズを支えやすい。

8.3 コンテキスト境界の割り方と A2A 協働

本稿で論じてきたのは常に単一の Super-agent インスタンス内部の設計であり、そのサービス範囲の情報はすべて同一の大域コンテキストに集約される前提だった。利用範囲が個人や小チームからより大きな組織に広がると、組織が Super-agent をどう配備するかを決めることは、実はコンテキスト共有と隔離の境界を引くことである。共有が必要な範囲は同一インスタンスを共用し、隔離が必要な範囲はそれぞれ独立に配備する。

さらに、組織内や組織間に互いに隔離された複数インスタンス——例えば各メンバーの Personal Assistant とチーム共用の Super-agent——が存在すると、境界を越える協働は Agent 間通信（A2A、特定プロトコルを指さない）になる。下層のコンテキストを共有せず、それぞれ異なる権限境界を代表する前提で、安全で信頼できる A2A 通信と協働をどう実現するかは、引き続き探求が必要である。

8.4 セキュリティとプライバシーの保障

第 3 節のイベント駆動設計は Agent をより広い環境から駆動できるようにする一方で、信頼できない入力への接触リスクも増やす。セキュリティとプライバシーの問題をうまく解決できなければ、Super-agent は小さく信頼できる範囲でしか働けない。

例えば第 5 節は Agent Loop をクラウドに置き、各実行端末に軽量 daemon をインストールするが、この設計はクラウドと端末が互いに信頼する前提に立っている。クラウドの Agent Loop が外部イベントを絶えず受け入れ、端末には私的なコード、機微データ、ローカルクレデンシャルが置かれているとき、このデバイスをまたぐ接続は顕著なセキュリティとプライバシーのリスクを持ち込む。クラウドのループがサーバー侵入やプロンプトインジェクションで破られれば、接続されたすべての端末が制御される潜在リスクに直面する。

さらに、クラウドが破られていなくても、端末側のクレデンシャルがモデルのコンテキストに入る限り、通常の実行過程でクレデンシャル漏洩のリスクはある。そのため、Agent がクレデンシャル自体に一切触れずにクレデンシャルを使える仕組みの設計が必要である。このアーキテクチャがより広く応用されるには、多様な環境からコンテキストを呼び戻せると同時に、上記のセキュリティとプライバシーの問題を解決しなければならない。

9. 結び

全体を振り返ると、私たちは新しい理論を提出したのではなく、コンピュータシステムの古典的な工学的知見を Agent システムの構築に応用した。具体的な実装は技術の進展とともに変わるが、その裏にあるシステム設計の考え方には、より長期的な参考価値があると考える。現在、この考え方と DeepSeek Harness に基づく社内 Super-agent インスタンスは継続運用されており、日常的に問題の再現と修正、コードレビューへの対応、DeepSeek Harness 自身の反復に参加している。

冒頭に述べたとおり、大モデルが単一タスクをこなすのに人手が要らなくなれば、生産性向上を制約する瓶首は人の注意力に移る。二層アーキテクチャ、イベント駆動、非同期マルチチャネル対話、存算分離、外部 Watchdog を通じて、システムは下層で煩雑なセッション管理とコンテキスト同期を引き受け、人間は具体的な実行の細部から、より高次の意思決定と受け入れへと上れる。

この形態において、Agent はもはや指示を待つだけの対話ウィンドウではなく、デジタル環境で常時オンラインの自律的協働者へと進む。個人には、デバイスをまたいで日常の用務を処理する Personal Assistant であり、チームには、開発ワークフローに溶け込み、具体的タスクを引き受けて進める存在である。モデル能力とシステムアーキテクチャがともに進化するにつれ、このより自律的な働き方が人機協働の常態になると私たちは信じる。

原文末尾の注記：本稿の一部の設計は dsh-superagent-prototype に実装されている（「原文を読む」で GitHub リポジトリへ）。同プラグインは技術路線の検証のためのプロトタイプであり、DeepSeek の正式製品ではない。作者と謝辞：本稿は DeepSeek Harness チームの共同実践に由来する。Yujia Qiao がシステム実装と本文執筆を担当し、Huanqi Cao、Zui Chen、Xieting Chu、Tianyi Cui、Shiyuan Feng、Yudong Han、Kexin Liu、Shichun Liu、Gesi Luo、Yifan Shi、Tongrui Xiong、Hanxiang Xu、C.C. Yu、Ziya Zhang、F. Zhou らが査読と議論に参加した。

出典

• DeepSeek 产品部（公式 WeChat）——『Super-agent 設計探索：より自律的な Agent システムへ』原文、2026-11-01
• deepseek-ai/dsh-superagent-prototype —— MIT ライセンスのプロトタイプ（README、docs 000–008）
• サイト内照合：英語全訳 · 中国語原文 · dsh-superagent 報道