第 8 課：自己進化：エージェントが自分自身を改造する

一言でいうと：DSH には明示的に有効化が必要な「自己参照 Cordis ツール」のセットがあり、エージェントが自分のライブランタイムを検査し、実行中に自分自身へプラグインをマウント・アンマウントできます。さらに Code Mode（run_code ツール + 生成される SDK）を組み合わせると、エージェントは自分でコードを書き、自分でインストールし、うまく動かなければ自分で取り外すことさえできます。それでも自壊しないのは、土台に Cordis の時空間合成可能性があるからです。マウントしたものは取り外せ、取り外せば痕跡も残りません。

1. ユーザーストーリー：ツールが足りないことに気づいたエージェント

深夜、古いプロジェクトの整理を任されたエージェントが作業をしています。今日もう 4 回目になる同じ作業です。設定ファイルを見つけ、その形式をパースし、重要なフィールドを集計表に書き込む。そのとき、エージェントはふと気づきます。「ツールが足りない。設定を構造化データにパースするツールが。」

フォーラムで助けを求めることも、人間のエンジニアが助けに来るのを待つこともせず、かつて人間のエンジニアしかしなかったことをします。自分自身を改造するのです。

1. 検査：まず cordis_inspect で現在どのプラグインがインストールされ、どのツールが登録されているかを確認し、「設定パース」が確かに誰からも提供されていないことを確認する。
2. 生成：設定パースのロジックを実装する JavaScript を自分で書く。
3. マウント：cordis_mount でそのコードをプラグインとしてマウントし、その場で新しいツールを手に入れる。
4. フィードバック：続く数回のタスクでそのツールを使って作業する。ところが、あるフィールドのパースロジックにバグがあり、頻繁にエラーになることが判明する。
5. アンマウント：cordis_unmount でこの一時プラグインを取り外し、コードを修正して、新しいバージョンを再マウントする。

この一連の過程で、DSH は一度も再起動されず、セッションも中断されず、他のプラグインも無傷のままです。これが本課のタイトル、自己進化：エージェントが自分自身を改造するです。下の図がこのループを示しています。

🎁 たとえるなら、外科医が自分自身を手術するようなものです。まず鏡を見て（ランタイムを検査し）、自分に臓器を移植し（プラグインをマウントし）、拒絶反応が出たら取り外す（プラグインをアンマウントする）。SF のように聞こえますか？ DSH はこれを、現実的で操作可能、しかも安全網付きの機能に変えました。

2. 自己参照 Cordis ツール：検査・マウント・アンマウント

DSH はこの能力をモデル向けの 3 つのツールとして実装しており、総称して自己参照 Cordis ツール（self-referential Cordis toolset）と呼びます。「自己参照」とは、これらのツールが操作するのが外部システムではなく、エージェント自身が存在するランタイムであるという意味です。リポジトリ直下の README には、最も簡潔な公式のまとめがあります。

Self-referential Cordis tools are opt-in. They let the agent inspect its live runtime and mount or unmount plugins while it runs. —— 出典：リポジトリ直下の README.md（DeepSeek Harness）

3 つのツールは役割分担が明確で、3 本の「メス」のようなものです。

⚠️ 最後の行の境界に注意してください。cordis_unmount は cordis_mount でマウントした一時プラグインしか取り外せません。正式にインストールされたプラグインには手を出せません。自己参照の力はありますが、境界は明確に引かれています。

一時プラグインの一生

では「一時プラグイン」とは一体どんな存在なのでしょうか。公式 README はそのライフサイクルを明確に書いています（出典：packages/extensions/tool-cordis/README.zh.md）。

一時プラグインは共有 DSH プロセスのメモリ内にのみ存在します。後続のラウンドをまたいでアクティブであり続けることも、同一プロセス内の他のセッションに影響を与えることもありますが、cordis_unmount、ツールセットのアンロード、DSH の再起動後には消滅します。プラグインファイルを作成せず、パッケージをインストールせず、cordis.yml や個人／プロジェクトの設定を変更せず、再起動をまたいで存続せず、正式なプラグインに自動昇格することもありません。

3 つに分解して見ましょう。

• メモリの中で生きる：ディスクに書き込まず、パッケージをインストールせず、設定も一切変更しない。ファイルシステムは寸分も動かない。
• いつでも消えうる：アンマウント、ツールセットのアンロード、DSH の再起動で消滅し、システムが自動で復元することは決してない。
• 正式昇格はできない：実験の成果を残したい？ ならエージェントは通常の開発プロセスをたどり、正式なローカル・プロジェクト・リポジトリのプラグインとして実装する必要がある。

つまりエージェントにとって、このツールセットは「草稿用紙での実験」のように振る舞います。自由に書き、自由に直し、自由に捨てられる。本題（正式なプラグイン）は常に正規のプロセスを通ります。

3. Code Mode：エージェントに「ツール呼び出しを一つずつ発行」ではなく「プログラムを書かせる」

自己参照ツールは「装着／取り外し」を解決しましたが、もう半分が残っています。エージェントが書いたコードは、どうやって実行されるのか？ 答えは Code Mode です。モデルにツール呼び出しを一つずつ発行させるのではなく、プログラムを書かせるのです。

まずネイティブモード（native）の痛点を見ましょう。DSH はデフォルトで各ツールを JSON Schema の関数定義としてモデルに通知し、モデルは各ステップで 1 つのツール呼び出しを発行します。そしてすべての中間 tool-result が次のリクエスト時にモデルのコンテキストに再び入ります。ある作業に 5 回のツール呼び出しが必要なら、モデルは 5 往復しなければならず、毎回それまでの中間結果をすべて引きずります。トークンコストは大きく、しかもモデルはツールを合成できません。結果セットの走査、中間値による分岐、ファンアウト、後処理。これらは「1 ステップ 1 呼び出し」のモードではできません。

Code Mode は別の発想を取ります。その根拠は非常に素朴な観察です。LLM はツール呼び出しを発行するよりもコードを書くほうが得意である。数百万行の実際のコードを見てきているのに対し、人為的に構築されたツール呼び出し列は比較的ずっと少ないからです。

公式の説明（出典：packages/core/tools/README.zh.md）：

code または both モードでは、レジストリは現在のスコープに対して、予約された run_code トランスポートと、ロードされたランタイムの言語に従って生成される決定論的な SDK を公開します……プログラムの最外層のログと戻り値だけがモデルのコンテキストに再び入ります。

モデルの目の前に落とし込むと、こうなります。

• run_code ツール：{ code, description } という 2 つのパラメータを受け取り、プログラムをコードランタイムに渡して実行させる、予約されたツールの入口。
• 生成される SDK：DSH は現在見えているツールセットに基づいて TypeScript 宣言（デフォルト言語。Python もサポート）を生成する。すべてのツールがプログラム内で呼び出し可能な、正確な型付きの関数になる。
• モデルがプログラムを書く：プログラム内で await tools.xxx(args) としてツールを呼び出し、ループ、分岐、並行（Promise.all）はすべてプログラム内部で完結する。中間結果は実行スコープ内にのみ存在する。
• 最外層のログと戻り値だけがモデルのコンテキストに再び入る：モデルが見るのは、自分で print したり return したりした部分だけ。コンテキストは中間結果に埋もれなくなる。

💡 たとえるなら、ネイティブモードは「1 歩ごとに 1 問」です。1 歩進むたびにモデルに伺いを立てる。Code Mode は「小さなプログラムを一度に書く」です。一連の作業をプログラム自身にオーケストレーションさせ、結果だけが報告されて戻ってきます。

2 つを組み合わせて見ると、ループが完成します。Code Mode が「自分で書く」を担当し、自己参照ツールが「自分で装着し、自分で取り外す」を担当する。書いたプログラムは run_code で実行され、実験で生まれたツールは cordis_mount でマウントされます。ツール不足 → ツールを書く → ツールを装着 → ツールを使う → 使いにくい → ツールを取り外す。これこそが、本課第 1 節のストーリーの背後にある完全なメカニズムです。

4. なぜ自壊しないのか：時空間合成可能性という安全網

ここまで読むと、理性的な疑問が必然的に湧いてきます。エージェントに自由に自分を改造させて、自壊しないのか？ モデルが書くコードには誤りがありうる。壊れたプラグインをマウントしたらどうなるのか？

答えは 2 層あります。

第 1 層、そして最も根本的なもの：すべての自己変更は、本質的には「動的合成」の一回であり、動的合成の安全性こそが、第 2 章で精読した Cordis 論文の中心的な貢献です。 あの「時空間合成可能性」を覚えていますか？ ここで一つずつ約束が果たされます。

• マウントしたものは取り外せる（時間的合成可能性）：Cordis のすべてのエフェクトには逆関数が備わっており、アンマウント時に LIFO 順で完全に復元されます。自己参照ツールに当てはめると、cordis_unmount はプラグインのすべての effect が完全に停止するまで待ってから返ります。取り外しは徹底的にきれいで、コンテキストに残滓を残しません。
• 取り外せば痕跡なし（空間的合成可能性）：一時プラグインはファイルを作成せず、パッケージをインストールせず、設定も変更しません。永続化されたセッションを復元しても、会話履歴だけが再構築され、一時プラグインは決して再構築されません。システムのどこにも「前回の自己変更」の痕跡は残りません。

つまり「自壊」というリスクは構造的に解消されています。マウントしたものは必ず取り外せ、取り外した後はマウントしていなかったのと同じです。壊れたプラグインをマウントした場合の最悪の結末は、それをアンマウントすることだけ。プロセスの再起動は不要で、「システムを回復するためのプロセス」そのものが壊れることもありません（第 2 章で述べたのを覚えていますか。時間的合成可能性が欠けていると、欠陥のある自己変更は「命綱」まで燃やしてしまうことがある、と）。

第 2 層は、重要な正直な声明です。これはあくまで開発者向けのツールであり、セキュリティ境界ではありません。 公式は、サンドボックスは「誠実なコードを制約する」だけで、信頼レベルは bash と同等だと明言しています。マウントされたプラグインは Node に到達でき、実際のファイルシステムとネットワークにアクセスできます。だからこそ明示的な有効化が必要であり、デプロイする側は bash ツールを付与するのと同じ慎重さで有効化すべきです。

最後に、視点を少し遠くへ引きましょう。論文の結論が指し示す未来はこうです。

自己進化するエージェントフレームワーク——AI エージェントが人間の監督をほとんど受けずに、自分のフレームワークコンポーネントを継続的に生成し置き換えていく。

DSH のこのメカニズムは、その方向の雛形です。そして**現実で最初に実現した形態は「モデルが合成した再利用可能なツール」**です。第 2 章で述べたように、これは「コンポーネントレベルの自己変更」の、より範囲の狭い先行形態です。今日、エージェントが書いたツールは通常の開発プロセスを通じて正式なプラグインや skill として蓄積され、将来のタスクで再利用されます。明日、自己参照ツールと Code Mode の閉ループが十分に成熟すれば、エージェントはランタイムで継続的に自分を改装できるようになるでしょう。そしてその日の礎は、やはりこの章全体で繰り返し現れるこの言葉です。マウントしたものは取り外せ、取り外せば痕跡なし。

要点の振り返り

この課は第 3 章の締めくくりです。次の 5 つを覚えておけば十分です。

1. 自己参照 Cordis ツール = 明示的な有効化が必要な 3 点セット——cordis_inspect（ライブランタイムの検査：プラグイン、サービス、ツール）、cordis_mount（メモリ内の一時プラグインのマウント）、cordis_unmount（effect が完全に停止するまで一時プラグインを取り外す）。
2. 一時プラグインはプロセスメモリ内にのみ生きる——ファイルを作成せず、パッケージをインストールせず、cordis.yml を変更しない。アンマウント、ツールセットのアンロード、DSH の再起動で消滅し、自動昇格もしない。実験成果を残すには通常の開発プロセスをたどる。
3. Code Mode = run_code + 生成される SDK——モデルがプログラムを書いてツール呼び出しをオーケストレーションし、ループ、分岐、並行はプログラム内部で完結する。プログラムの最外層のログと戻り値だけがモデルのコンテキストに再び入り、中間結果は逆流しない。
4. 自壊しない根本原因は時空間合成可能性——マウントしたものは取り外せる（逆関数 + LIFO による完全復元）、取り外せば痕跡なし（ファイルなし、設定なし、セッション復元でも一時プラグインは再構築されない）。すべての自己変更はロールバック可能な動的合成である。
5. 展望——論文の結論は無人監督の「自己進化するエージェントフレームワーク」を指し示し、DSH のメカニズムはその雛形。現実で最初に現れたのは「モデルが合成した再利用可能なツール」。

🎓 第 3 章をここまで学んだあなたは、次の質問に答えられるはずです。「DSH はどのように起動し、なぜセッションをいつでも復元・fork・リプレイできるのか？」「エージェントループはどう動き、ツールはどう定義・実行・制約されるのか？」「サンドボックスと承認は『触れられる』と『触れられない』の境界をどう引くのか？」「エージェントはどう世界を知覚し、目標と協調を管理するのか？」そして本課の核心、「なぜ安全に自分自身を改造できるのか？」。すべて答えられたなら、おめでとうございます。あなたは DSH のすべての核心概念を手に入れました。次章「プラグイン開発の実践」では、いよいよ自分の手でプラグインを書きます。そのとき気づくでしょう。今日学んだ「動的合成」は抽象的な概念ではなく、あなたが毎日使う日常なのだと。