第7課：目標・計画・協調：単独から軍団へ

ひとこと版：一人では片付けきれない大きなタスクは、「エージェント軍団」に任せましょう——**目標（goal）**は「なぜやるのか」を永続的に記録し、**計画（plan）**は照合可能な協調状態として形になり、**バックグラウンドタスク（tasks）とToDo（todo）**が進捗を追跡し、**サブエージェント（subagent）がそれぞれのサブタスクを引き受け、さらにワークフロー（workflow）**スクリプトが全員を秩序あるパイプラインに編成します。単独作戦から、軍団の協調へ。

1. ユーザーストーリー：大きなタスクを軍団にどう分担するか

あなたが DSH の利用者として、大きなタスクを依頼すると想像してください。「会社のコードベースを旧フレームワークから新フレームワークに移行する」というタスクです。このタスクは大きすぎて、1つのエージェントが一気にやり切ると混乱します——まず分解し、次に分担し、やりながら照合する必要があります。全体の流れは6つのステップに分けられます。

1. 目標を立てる（goal）：まず「移行を完了させる」という全体目標を明確にし、永続的に保存します——セッションが中断・再起動されても、エージェントは自分がどこへ向かうべきかを知っています。
2. 計画を立てる（plan）：Plan Mode で大きなタスクをフェーズに分解します。現状調査 → 移行案の設計 → 一括書き換え → レビューと回帰確認。各ステップは協調状態に書き込まれ、人とエージェントはいつでも「今どのステップまで進んでいるか」を照合できます。
3. ToDo を並べる（todo）：各フェーズをさらにチェック可能なリスト項目に分解します。たとえば「旧 API を使っているファイルをすべて洗い出す」「各ファイルの移行変更を生成する」などです。
4. バックグラウンドタスクを投げる（tasks）：時間のかかる仕事（全コードベースのスキャンや一括コンパイルなど）はバックグラウンドで実行させ、メインエージェントは待ちぼうけになりません。いつでも進捗を観察したり、タスクをキャンセルしたり、完了通知を待ったりできます。
5. サブエージェントに委譲する（subagent）：「現状調査」は調査担当に、「一括書き換え」はプログラマーに、「結果のレビュー」はレビュアーに——各サブエージェントが1つのサブタスクを引き受け、それぞれ自分の仕事を進めます。
6. ワークフロー（workflow）で編成する：上記のサブエージェントたちをパイプラインに直列化するスクリプトを書きます。まず調査、次にコーディング、最後にレビュー。各フェーズは並列に進められ、結果は一括してオーケストレーターに集約されます。

下図はこの「軍団作戦」の鳥瞰図です。オーケストレーター（メインエージェントまたは workflow）が下へ委譲し、目標・計画・タスク・ToDo が全体を貫く一本の軌道のように走り、サブエージェントはそれぞれの役割を果たし、最後に結果が集約されて戻ってきます。

以下では、この6つの能力ファミリーを1つずつ見ていきましょう——どれも DSH ソースコード内の実在するパッケージ（package）由来のもので、それぞれ明確な責務とマウントポイントを持っています。

2. 目標と計画：「何をすべきか」を根拠づけ、再開可能にする

2.1 goal：永続化された同一セッションの目標

ソースリポジトリの packages/goal/README.zh.md にある定義はたった1段落ですが、非常に重要です。

エージェントセッションの永続的な目標状態であり、それを消費するモデル向けツールや継続ポリシーからは独立している。goal 状態は所属するセッションログの一部であり、消費側は dsh-goal に依存し、具体的なエージェントループには決して依存しない。

分解して見ると、3つの要点があります。

• 永続化：goal は「セッションの永続的な目標状態」であり、モデルが頭の中で一時的に覚えている一文ではありません。それはセッションログの一部です——第1章の「実行は再構築可能」を覚えていますか？ ログこそが真実であり、目標もログの一部として、同様に復元・再生できます。
• 消費側からの独立：goal 状態と「それをどう使うか」は分離されています。消費する側は、モデル向けツール（tool-goal。モデルが目標を読み取り・更新できる）、ユーザー向けコマンド（command-goal。コマンドラインや画面で目標を確認できる）、そして継続ポリシー（goal-round-driver。「同一セッションの目標継続」を担当）が考えられます。
• 具体的なループに依存しない：消費側は dsh-goal という能力インターフェースにのみ依存し、特定のエージェントループ実装には決して結びつきません——これこそ第2章で扱った「シーム」です。能力定義・プロバイダー・コンシューマーの三者が分離され、どの端も単独で置き換えられます。

goal ファミリーは4つのパッケージで構成されています。

goal と「再開」の関係：なぜ目標を永続化する必要があるのでしょうか？ エージェントが長時間タスクを実行していると、セッションが中断されたり、復元されたり、fork されたりすることがあるからです。「何を達成すべきか」がログの一部として永続的に存在する限り、どのチェックポイントからセッションを再構築しても、エージェントは自分がなぜここにいるのか、次にどこへ進むべきかを知っています——これが「再開」の土台です。

2.2 plan：ログに落ちる協調状態

packages/plan/README.zh.md も、同じく一文で本質を突いています。

Plan mode はエージェント単位で記録される協調状態であり、汎用のモードレジストリや能力シームではない。

• エージェント単位で記録される：plan 状態は特定のエージェントに紐づき、「このエージェントが現在何を計画していて、どのステップまで進んでいるか」を記録します——グローバルなモードスイッチではなく、エージェントに付いて回るものです。
• 汎用のモードレジストリではない：グローバルなモードを切り替えるためのレジストリでも、置き換え可能な能力シームでもありません。それは純粋な協調状態です。オーケストレーター（またはユーザー）とエージェントが、これを通じて「次に何をするか、境界はどこか」を揃えます。
• ログに落ちる：plan の各ステップ（ステップ境界を含む）はセッションログに書き込まれるため、計画の変遷も同様に根拠づけられ、レビュー・復元・fork が可能です。

役割分担を一文で覚えましょう。goal は「なぜやるのか」に答え、plan は「どうやるか、どこまでやったか」に答えます。

3. バックグラウンドタスクと ToDo：進捗はどこから来るのか

3.1 jobs：長時間実行ツールのためのバックグラウンドプロトコル

packages/jobs/README.zh.md はこのファミリーをこう説明しています。

本ファミリーは、長時間実行されるツールに対して、観察・キャンセル・待機・完了通知のための、所有者ごとに隔離されたバックグラウンドタスクプロトコルを提供する。

• 長時間実行されるツール：全コードベースのスキャン、一括コンパイル、リモートリクエスト……こうした時間のかかるツール呼び出しはエージェントのメインループを塞ぐわけにはいかないため、バックグラウンドに回されます。
• 所有者ごとに隔離：各タスクはそれを作成したエージェントに属し、他のエージェントが勝手に干渉することはできません——これが「各自が自分の仕事に責任を持つ」という規律の保証です。
• 4つの能力：観察（進捗やスナップショットを見る）、キャンセル（不要になったら止める）、待機（タスク終了までブロックしてから続行）、完了通知（終わったら能動的に知らせる）。

ファミリー構成：jobs/ がタスクレジストリとライフサイクル規約（ctx.jobs）を定義し、jobs-local/ がプロセスローカルなレジストリ実装を提供し、tool-jobs/ がタスク制御と完了通知をモデルに公開します（ctx.tools に登録）。

注目すべき点として、tool-jobs はタスク種別に依存しない（kind-agnostic）バックグラウンドジョブコントローラーです。バックグラウンドの bash コマンド、ターミナルの terminal_send、バックグラウンドのサブエージェント——これらすべてが、同じ job_output / job_list / job_kill の3つのツールで読み取り・列挙・終了されます。生産側はそれぞれ JobKindMap を拡張して独自の id 名前空間を宣言しますが、モデル側から見えるのは常に同一のインターフェースです（出典：docs/tool-catalog.zh.md）。

3.2 todo：セッション自身の ToDo リスト

packages/todo/README.zh.md はその位置づけをこう述べています。

モデル向けの todo 能力。1つのエージェントセッションがこのリストを所有するため、単一のプロダクトパッケージである。置き換え可能なプロバイダー規約は存在しない。

• 1つのセッションが1つのリストを所有する：todo はグローバルに共有されるものではなく、まさに現在のこのエージェントセッションのチェックリストです。
• モデル向け：モデルはこれらの項目を読み取り、追加し、チェックし、クリーンアップできます。
• plan との役割分担：plan は「ロードマップ」（どう進むか）、todo は「チェックリスト」（今どこまでできていて、何が残っているか）です。plan を見て全体のリズムを把握しながら、todo にチェックを入れて各ステップの完了を確認できます。

4. 委譲：「一人でやる」から「一つの軍団」へ

4.1 3つの委譲スタイル：spawn、fork、外部プロバイダー

packages/subagent/README.zh.md は冒頭でこう述べています。

本ファミリーは、1つのエージェントが仕事をサブエージェントに委譲できるようにする。複数の名前付きプロバイダーが同一コンテキスト内で共存できる。

このファミリーの主要なパッケージは次のとおりです。

3つのスタイルの覚え方：

• spawn：全く新しいインスタンス。サブエージェントはゼロから始まり、親セッションで何が起きたかを知りません。自己完結したプロンプトを渡せば動き始めます。完全に独立したサブタスク（たとえば「あるディレクトリにどんなファイルがあるか調査する」）に向いています。
• fork：プレフィックスを継承。サブエージェントは親エージェントの完了済み履歴から起動するため、最初からコンテキストを持っています。「会話の続き」を必要とする継続的なタスク（たとえば「上記の分析を踏まえて、実装を書き進める」）に向いています。
• 外部委譲：プロセス外のエージェント。ACP プロトコル、Codex、Claude Code、DSH SDK を通じて「正真正銘・他所のエージェント」を起動し、仕事を外注して、結果を受け取ります。

4.2 委譲の後：通信と制御

委譲は「放り出して放置」ではありません。一式の制御ツールが付随します。

• tool-subagent/：委譲操作（委譲の発起）をモデルに公開します。
• tool-subagent-control/：子へのメッセージ送信と列挙操作（子に新しい仕事を割り振る、現在どんな子がいるか確認する）をモデルに公開します。
• tool-subagent-report/：子から親へのレポートチャネル（子が仕事を終えた後、どうやって結果を渡すか）を提供します。

さらにサブエージェントはバックグラウンド実行をサポートしています。サブエージェントにバックグラウンドでゆっくり働かせ、その間に自分の作業を続け、後でメッセージチャネルを通じて追加の仕事を投げることができます——これがソースドキュメントに書かれている「再開可能なバックグラウンドサブエージェント」です。

5. workflow：スクリプト駆動のマルチエージェントオーケストレーション

5.1 モデルが書くオーケストレーションワークフロー

packages/workflow/README.zh.md は一文でこう要約しています。

本ファミリーは、subagent を通じてモデルが書いたオーケストレーションワークフローを実行し、汎用ツールと固定ポリシーツールをモデルに公開する。

分解すると3つのキーワードがあります。

• モデルが書く：オーケストレーションスクリプトは人間が書き込んだ固定フローではなく、モデル（またはあなた）が書く一段のオーケストレーションロジックです——「最初に何をし、次に何をし、何を並列にできるか」をシステムに伝えます。
• subagent を通じて実行：スクリプト内の「働き手」はすべてサブエージェントです。スクリプトはフェーズ（たとえば「調査」「コーディング」「レビュー」）を定義でき、同じフェーズ内では複数のサブエージェントが並列に進み、互いをブロックしません。これこそ「軍団」の形です。
• 汎用ツールと固定ポリシーツール：スクリプトは汎用のオーケストレーション能力（エージェントの起動、タスク群のパイプライン処理、複数の並列タスクの結果集約など）に加えて、固定ポリシーのツールも使えます——たとえば tool-ralph/：毎回全く新しいエージェントで固定フローを実行する Ralph ワークフローで、「毎ラウンド、古い記憶を持ち込まず、共有ワークスペースだけに頼る」反復型タスクに適しています。

技術的な補足：ワークフロースクリプトは独立した worker thread で実行され、ホストのイベントループから隔離されます。ただしリポジトリのドキュメントが明確に強調している通り、これはセキュリティ境界を構成しません——あくまで実行方式上の隔離であり、セキュリティ境界は引き続きサンドボックスと承認が担います（第4課を参照）。

ファミリー構成：workflow/ がワークフロー実行とライフサイクルイベント（ctx.workflowEngine）を定義し、workflow-worker-thread/ がスレッド内でスクリプトを実行し、tool-workflow/ が汎用ワークフロー実行をモデルに公開し、tool-ralph/ が固定の Ralph ワークフローを公開します。

5.2 subagent と workflow の役割分担

• subagent = 単一の「手足」：1つのサブタスクを引き受け、終わったら成果を納品します。1対1の委譲に向いています。
• workflow = 全体の「プロジェクト管理スクリプト」：多くの手足をパイプラインに並べ、順序と並列を決める役割です。1対多、多段階のオーケストレーションに向いています。
• 実際には両者はしばしば重ねて使われます。workflow スクリプト内でサブエージェントを起動する呼び出しは、内部では subagent のプロバイダーを通っています——workflow が総指揮官で、subagent が兵士です。

6. 前の2章との関係：2つの線をつなぐ

• 第1章（DSH 入門）：エージェントフレームワークの基本思想の課で「マルチエージェントオーケストレーション」を扱いました——1つのタスクを複数のエージェントに分け、1つは調査、1つはコードを書き、1つはレビューを担当し、フレームワークがそれらを編成するという話です。本課はその思想を、DSH に実在する6つの能力ファミリー——goal、plan、tasks、todo、subagent、workflow——として具体化するものです。第1章が「ビジョン」なら、本課は「部品リスト」です。
• 第2章（論文精読）：Cordis 論文の核心は「コンポーネント」と時空間的な合成可能性——システムのすべてが合成可能・置き換え可能なコンポーネントであるということです。本課の各能力ファミリーはまさにコンポーネントであり、ctx コンテキストの各キーに登録され、「能力定義 / プロバイダー / コンシューマー」のシーム構造に従います。最も典型的な例が subagent です。複数の名前付きプロバイダー（spawn、fork、ACP、Codex、Claude Code、dsh-sdk）が同じ ctx.subagents キーの下で共存し、委譲方式を変えたければプロバイダーを変えるだけ——これこそ「ソケットを差し替える」式の置き換え可能性です。

キーポイントの振り返り

この課は情報量が少なくありませんが、次の5文を覚えれば十分です。

1. 目標 goal：永続化された同一セッションの目標で、セッションログの一部——これがあるからこそ「再開」が可能になり、消費側は具体的なエージェントループに依存しません。
2. 計画 plan：エージェント単位で記録される協調状態であり、グローバルなモードスイッチではありません。各ステップがログに落ち、照合・復元が可能です。
3. バックグラウンドタスク tasks + ToDo todo：tasks は長時間実行ツールに所有者ごとに隔離されたプロトコル（観察、キャンセル、待機、完了通知）を提供し、todo はセッション自身が所有するチェック可能なリストです。
4. 委譲 subagent：spawn は全く新しいインスタンス、fork は親セッション履歴を継承、外部プロバイダー（ACP、Codex、Claude Code、dsh-sdk）はプロセス外のエージェントに仕事を外注します。委譲後には制御ツールとレポートチャネルもあります。
5. ワークフロー workflow：モデルが書くオーケストレーションスクリプトで、subagent を通じてフェーズごとに並列実行され、固定ポリシーツール（Ralph）も付属します——これらはすべて ctx に登録された置き換え可能なコンポーネントです。

🚀 次の課（第8課）では「自己進化：エージェントが自分を改造する」を扱います。本課の「シーム型コンポーネント + 置き換え可能なプロバイダー」があるからこそ、エージェントは実行中に自分の能力を検査・マウント・アンマウントできるのだと分かるでしょう——軍団の指揮から、自らの装備の改造へ。