なぜ動的コンポジションが必要なのか？

一言でいえば：ソフトウェアには「実行中にコンポーネントをインストール・削除・置き換える」ことがますます求められていますが、現在のソフトウェアの多くはそれができません——インストールしたら削除できないか、削除しようとするとプログラム全体を再起動してすべての状態を失うかのどちらかです。動的コンポジションとは、このことを安全に実現する能力であり、まさに DSH とあの Cordis 論文が解決しようとする中核的な問題です。

まず、あるプログラマーの一日の話をしましょう

李さんはチャットボットプラットフォームを運用していて、ユーザーは数十個のプラグイン（天気、翻訳、家計簿……）をインストールしています。

• 午後2時：ユーザーから「翻訳プラグインが遅くなった」と報告がありました。李さんは翻訳サービスを切り替えたいと考えます。
• 現実は：彼はボット全体を停止しなければなりません（すべてのプラグインが一緒にオフラインになる）、設定を変更し、再起動します。
• 再起動後：ユーザーは3分間使えません。以前キャッシュされていたホットデータはすべて消え、他の29個のプラグインも「道連れ」に再起動させられます。

李さんは心の中で思います：「一つのプラグインを交換したいだけなのに、なぜシステム全体をバラバラにしなければならないんだ？」

この問題こそが、「動的コンポジションの欠如」と呼ばれるものです。

シナリオ1：プラグインシステム（あなたは毎日使っているが、それに痛い目に遭わされてきた）

世界で最も人気のあるコードエディター VSCode を例に挙げましょう（論文にある実データです）：

VSCode はすべての拡張機能（プラグイン）を一つの共有プロセスで実行します。コードを含む拡張機能を一つアンインストールしたい？エディター全体を再起動するしかありません。インストール数上位100の拡張機能のうち、87個が実行可能なコードを含んでいます——つまり、よく使われる拡張機能の87%はアンインストール時に再起動が必要なのです。

なぜ削除できないのでしょうか？プラグインは「環境に手を加えた」からです：コマンドを登録し、イベントを監視し、設定を変更します。VSCode はこれらの変更をどう取り消すかを知らないので、「見ざる聞かざる」——再起動してすべてをゼロに戻すしかないのです。

🎁 第1章のキッチンのたとえを覚えていますか？シェフを替えるのに店を閉めて内装をやり直す——これが現状です。

シナリオ2：自己進化するエージェント（未来の常態）

前のセクションで話したように、未来のエージェントは自分でツールを書き、自分でインストールし、自分でアンインストールします。しかも実行中に、人間の監督がほとんどない状況で。

これは次のことを意味します：

• 変更のたびに再起動するわけにはいかない——エージェントは1分に1回変更するかもしれません。再起動 = 状態の喪失の繰り返し + ダウンタイムの繰り返し
• インストールを間違えたら壊滅、では困る——エージェントが問題のあるモジュールをインストールし、さらに自分自身の「回復メカニズム」まで壊してしまったら、本当に助けを呼ぶ術がありません
• こっそり他者を壊してはいけない——新しいコンポーネントが古いコンポーネントを置き換えるとき、それに依存する他のコンポーネントは自動的に適応しなければならず、静かにエラーを起こしてはいけません

自己進化はSFではなく、AI 発展の明確な方向性です。そしてそれが安全に実現できるかどうかは、完全に動的コンポジションが十分にうまくできているかどうかにかかっています。

問題の分解：二つの次元

論文は「動的コンポジション」を、互いに無関係な（直交する）二つの次元に分解しています：

次元一：時間的コンポーザビリティ（インストールできて、取り外せる）

コンポーネントを取り除くとき、それが以前に環境に加えたすべての変更が完全に取り消されなければなりません——プラグを抜いたら、回路が元通りになるように。

• 問題：コンポーネントは「インストール」時にたくさんのものを変更します（登録、リスナー、キャッシュ）。「取り外し」時に誰が元に戻す責任を負うのでしょうか？
• 現状：誰も責任を負わない → 再起動で帳尻を合わせるしかない
• 目標：インストール時に自動で記録し、取り外し時に自動で復元する

次元二：空間的コンポーザビリティ（必要なものを、システムが用意してくれる）

コンポーネント同士は依存関係を宣言し、自動的に協調できなければなりません——依存が揃って初めて起動し、依存がなくなれば自動的に停止します。

• 問題：翻訳プラグインには「翻訳サービス」と「データベース」が必要です。プラグインだけがインストールされてサービスがインストールされていなかったら、どうなるでしょうか？
• 現状：プラグインが自分でチェックし、見つからなければエラーを出してクラッシュするか、お互いを待ち続けてデッドロックします
• 目標：システムが依存関係の変化を監視し、コンポーネントを自動的にアクティブ化／非アクティブ化する。コンポーネント自身は何も管理しなくてよい

💡 一言で覚えるなら：時間次元は「取り外した後に環境がきれいかどうか」を扱い、空間次元は「コンポーネント同士がどう協調するか」を扱います。二つの次元は互いに独立しており、別々に研究できます。

既存の「力技」：再起動とコンテナ

「再起動すればいいじゃないか。今のクラウドサービスはみんなそうやっているだろう？」と言う人もいるでしょう。その通りですが、代償は大きいのです：

論文はこれを**粒度のミスマッチ（granularity mismatch）**と呼んでいます：

私たちは一つの「プラグイン」を交換したいだけなのに、プロセスの再起動は「鶏を殺すのに牛刀を使う」ようなもので、コンテナの再起動は「豚を殺す」ようなものです。現代のシステムはますますコンポーネントという細かい粒度で構成されるようになっています——コンポーネント自身と同じくらい細かい階層で、作用と依存関係を管理する必要があるのです。

動的コンポジションがあれば、李さんの一日はどうなる？

同じシナリオで、動的コンポジション（例えば DSH/Cordis）がある場合：

1. 李さんはコンソールで「翻訳プラグイン → プロバイダーを切り替え」をワンクリックします
2. システムが自動的に：古い翻訳プラグインをアンインストール（登録したコマンドやキャッシュがすべて復元されます）→ 新しい翻訳プラグインをインストール
3. 翻訳サービスに依存する他のプラグインは自動的に再起動して適応し、依存していないプラグインは微動だにしません
4. 全過程で再起動は一切なく、他のユーザーはまったく気づきません

これが論文（そして私たちのサイト）があなたと一緒に実現したい目標です。

要点の振り返り

• 動的コンポジション = 実行中に安全にコンポーネントをインストール／削除／置き換えること
• 二つの次元：時間（取り外したら復元できる）と空間（依存関係が自動的に協調する）
• 現状の力技（再起動、コンテナ）は粒度が粗すぎ、代償が大きすぎる
• 動的コンポジションはプラグインシステムと自己進化するエージェントの共通の切実な要求である

🚀 次の章（第2章・論文精読）では、いよいよ本格的にあの論文に入り、「インストールと取り外し」を「エラーが出ないことを祈る」から「構造的な保証」へと変える数学的ツールを見ていきます。「エフェクト／コエフェクト」という言葉にまだ触れていなくても——大丈夫です。第5課でゼロから解説します。