第 13 課：考察、関連研究、そしてまとめ

一言でいうと：論文は形式モデルと実装の解説を終えた後、あと三つの締めくくりを行います——第 5 章「考察」ではパラダイムを実際のエンジニアリングへと推し進め（サービスプロキシ、サンドボックス、言語独立性、コンポーネント粒度、バージョン管理）、第 6 章「関連研究」ではそれを学術の地図の上に置き、Effekt、AOP、DSU といった近隣の研究との境界を一つずつ明確にし、第 7 章「結論」では「二つの次元、一つの実装、一つの未来」で全体を締めくくります——このレッスンを読み終えれば、あなたは Cordis の論文をすべて読み終えたことになります。

1. エンジニアリング上の拡張：「動く」から「使いやすい」へ

前のレッスンまでで、パラダイムが成立することは証明されました（第 3 章の形式モデル + 第 4 章の Cordis 実装）。第 5 章はそこからもう一歩先へ進みます。このパラダイムは実際のエンジニアリングでどう使われるのか、どんな問題に直面するのか？五つのトピックを順に見ていきましょう。

1.1 サービス多重化：一つのインターフェース、複数の実装

コンポーネントプラットフォーム（OSGi など）は「サービス」を合成の基本単位と見なします。プロバイダーがあるインターフェースでサービスを公開し、コンシューマーがそれにバインドします。Cordis におけるサービスとは「あるキーの背後にあるインターフェース」です。同じインターフェースには複数の実装が存在することがよくありますが、これをどう管理するのでしょうか？方法は二つあります。

なぜプロキシは撹乱を吸収できるのでしょうか？ コンシューマーが依存しているのは「プロキシ」という固定の入口だけだからです。バックエンドが入れ替わっても入口は変わらず、依存関係も当然変わりません。この小さな設計が、三つのインフラストラクチャレベルの能力を直接支えています。

1. 負荷分散——複数のプロバイダーが共存し、プロキシはラウンドロビン、最少負荷、レイテンシ重み付けなどの戦略でリクエストをディスパッチします。スケールアウト／スケールインしたければ、プロバイダーを追加・削除するだけです。注意点：各プロバイダーは可逆エフェクトを通じてプロキシに登録されるため、アンロード時には登録が自動的に取り消され、プロキシのルーティングテーブルから自動的に一エントリ消え、汚れたデータは残りません。
2. ローリングアップデート——実行時にサービスをアップグレードすることは、制御された「プロバイダー移行」の一形態です。まず新しいプロバイダーをロードしてプロキシに登録し、Active 状態に入るのを待ってから、トラフィックを旧プロバイダーから新しいプロバイダーへ段階的に移します（たとえば重みを調整する）。旧プロバイダーが処理中のリクエストを一切抱えなくなってからアンロードします。これは「ブルーグリーンデプロイメント」や「コンテナオーケストレーション」といったインフラストラクチャ層の作業を、アプリケーション層の一つの合成パターンに変えてしまうことに等しいのです。
3. プロセス間呼び出し——プロキシはプロセスをまたいでも機能します。各プロセスは独自の Cordis コンテキストとローカルプロバイダーを持ち、調整役のコンポーネントがそれらをつなぎ合わせ、各プロセスをリモートプロバイダーとして扱います。分散化はコンシューマーに対して透過的です。⚠️ ただしプロセス間呼び出しにはレイテンシがあり、途中で失敗する可能性もあるため、インターフェースは非同期契約に基づいて設計する必要があります。さもなければ同期呼び出しが呼び出し側をブロックしてしまいます。

1.2 アクセス制御とサンドボックス：読み込めても、制御できなければならない

独立したコンポーネントを組み合わせて作られたアプリケーションでは、セキュリティを二手に分けて確保する必要があります。① コンポーネントがアクセスできる依存関係を制限すること。② 信頼できないコードをホスト環境から隔離すること。

一手目：依存宣言こそがケーパビリティ要求である。 覚えていますか？コンポーネントは自分が「宣言した」依存関係にしかアクセスできず、未宣言のものにアクセスするとエラーになります。これは構造的に「ケーパビリティベースセキュリティ」（capability-based security）そのものです。権限は参照を保持していることから生じるのであって、「この環境の一員である」ことから生じるのではありません。inject 宣言 = ケーパビリティ要求、コンテキストプロキシ = ケーパビリティの仲介者です。しかもこれらの要求は静的に宣言されているため、オーケストレーターはロード時に審査・承認でき、アクセスが実際に発生してから一つずつ違反を発見する必要はありません。

インターセプションによってきめ細かなポリシーを実現できる。 コンテキストはアクセス制御のメタデータを保持でき、プロバイダーは呼び出しのたびにメタデータを参照して許可するかどうかを判断します（たとえばファイルシステムの依存には「このコンポーネントが読み書きできるパスはどこか」というメタデータが付く）。重要なのは、インターセプションがコンテキストに掛けられており、どちらか一方のコードに常駐していないことです——そのためオーケストレーターはプロバイダーのコードを一切変更せずに、特定のコンポーネントだけを個別に制約できます（たとえば：コミュニティコンポーネントはデータベースへの読み取り専用アクセス、コアコンポーネントはフルアクセス）。さらにインターセプションは「呼び出し方」にのみ影響し、「依存が満たされるかどうか」には影響しないため、実行時にインターセプターをインストール・調整・削除してもリロードはトリガーされません。

二手目：信頼できないコードは、隔離境界の外に放り出さなければならない。 言語レベルのチェックでは悪意あるコードを抑えられません——ホストランタイムに触れられる限り、低レイヤーのオブジェクトを直接操作できてしまい、チェックは形骸化します。真の隔離には言語レイヤーの外側にある実行境界が必要です。ソフトウェア障害隔離（SFI）、隔離された言語ランタイム、サンドボックス化されたプロセス、仮想化コンテナなどです。信頼できないコンポーネントは独自の隔離コンテキスト内で動作し、「ブリッジ」を通じてホストが提供する依存関係にアクセスします。これは実は 5.1 節のプロセス間呼び出しの一般化です——同じ透過性の議論により、ブリッジ越しのアクセスとローカルインジェクションは区別がつきません。ホスト側から見れば、ブリッジは単なる普通のファイバーであり、そのケーパビリティの範囲は上記のアクセス制御でさらに絞り込めます。

1.3 言語独立性：どんな言語でもこのパラダイムを実装できるか？

Cordis は TypeScript で実装されていますが、パラダイム自体は言語に依存しません——「時空間的コンポーザビリティ」は二つの次元だけで定義されます。各次元にはそれぞれどんな能力が必要なのでしょうか？

時間次元（分解しても元に戻せる）には二つのものが必要です。

• クロージャ——可逆エフェクトは操作とその逆操作をペアにします。逆操作と復元すべき状態は「値として捕捉」されていなければ、分解時に再実行できません。これが最低要件です。
• 実行時にコードをロード・アンロードする能力——言語の実行モデルに依存します。マネージドランタイムではプログラム可能なモジュールレジストリに依存します（たとえば Node.js の require.cache。モジュールは追い出され、参照されなくなれば回収されます）。ネイティブコードでは明示的な動的リンクとアンリンクに依存します（Unix の dlopen / dlclose、Windows の LoadLibrary / FreeLibrary）。WebAssembly はエンベッダーがどちらの道を採るかによります。いずれにせよ、可逆エフェクトは「ロード」をコンテキストに適用されるエフェクトとして扱い、その逆操作はモジュールが導入したシンボル・型・ハンドラー登録を取り消します。

空間次元（依存の自動調整）は本質的に「依存性注入（DI）」の問題であり、言語によって異なる二つのレベルで展開されます。

より手軽な方法はメタプログラミングです。アノテーションやデコレーターでメタデータを宣言に付与し、プロセッサーがそれを仲介を担当するアクセサーに展開します。コンパイル時メタプログラミング（Rust の手続きマクロ、Scala のマクロ、Zig の comptime）を使えば、依存ごとに型付きの宣言とアクセサーを生成することさえでき、汎用のインターセプションプリミティブすら不要になります。

1.4 コンポーネント粒度：依存サイクルをどう断ち切るか

リアクティブコーエフェクトモデルでは、依存サイクル（A は B の提供するキーを必要とし、B は A の提供するキーを必要とする）は双方を永久に非アクティブ状態にとどめます——満足述語が永遠に真にならないからです。デッドロックとの違いに注意してください。デッドロックはランタイムエラーですが、依存サイクルは静的に予測可能（依存宣言を見るだけで分かる）で、ランタイムエラーを発生させず、ただ「静かに起動しない」だけです。

どう断ち切るのでしょうか？一見相互依存している関係のほとんどは、より細かいコンポーネントに分解することでサイクルを解消できます。 論文の例：サーバー（ネットワークインターフェースを提供）とアクセスコントローラー（認可ポリシーを実施）が双方向に相互作用します——アクセスコントローラーはサーバーに届くリクエストを仲介し、サーバーはポリシーを変更するエンドポイントを公開します。モノリシックな設計では必然的に相互依存になります。分解すると四つのコンポーネントが得られます。

• server-core（ネットワークインターフェースを提供）
• access-control-core（認可ポリシーを実施）
• request-mediation（両方のコアに依存し、入力リクエストにアクセス制御を適用）
• policy-management（両方のコアに依存し、サーバー経由でポリシー変更機能を公開）

二つのコアコンポーネントは互いに依存せず、「統合コンポーネント」だけが両方に依存します——サイクルは消えました。

コストは何でしょうか？一般に、相互に作用するコンポーネントが n 個ある場合、統合コンポーネントの数は n に対して二乗で増える可能性があります（双方向の相互作用の各ペアに、方向ごとに一つのコンポーネントが必要になるかもしれない）。幸いコンポーネントは軽量で、正確性や性能には影響しません。むしろ細かい粒度は利点すらもたらします。ユーザーは自分が必要とする統合バインディングだけをロードできるからです。本当に影響を受けるのは開発者体験です——設定が増え、命名が増え、認知的オーバーヘッドが高まります。緩和策はいずれもエンジニアリング上の手段です。パッケージバンドル（関連する細粒度コンポーネントを一つのインストール可能ユニットにまとめる）、規約ベースのアセンブリ（名前や型があるパターンに合致するコンポーネントを自動で接続する）、スキャフォールディングツール（宣言的な仕様から定型の統合コンポーネントを生成する）。

1.5 依存の型とバージョン管理：キーの衝突とインターフェースドリフト

形式モデルでは、依存リンクは完全に「キー同一性」によって確立されます。キー k を提供するコンポーネントは、k を宣言するどのコンポーネントも満たします。型族 𝒱ₖ は単一のコンパイル単位内部での型の一貫性を保証できます——しかしコンポーネントがそれぞれ独立に開発・ビルドされる場合（エコシステムの常態）、この保証は失効し、二つの問題が生じます。

二つの問題は同じ欠陥を指しています。コーエフェクトモデルは名義的リンク（キー名による）しか提供せず、バージョン付きリンクや構造的リンクは提供しません。論文は三つの補完方法を示しています（「インフラストラクチャとの結合度が高い順」）。

三つの方法はそれぞれ一面をカバーしており、これらを一つの依存モデルに統一する方法は、依然として未解決の問題です。

2. 関連研究の位置づけ：Cordis は地図のどこに立っているか

第 6 章では Cordis を近隣の研究分野と一つずつ対比します。核心はこの一言です。多くのシステムは「部分的な動的合成」を解決してきたが、Cordis は「可逆 + リアクティブ」を同時にランタイム機構として実現した唯一のシステムである。 以下は「だれがだれか」の早見表です。

🎁 早覚え：隣人たちは「コンパイル時にしか管理しない」（グレード付き型、Effekt）か、「インストールは管理するがアンインストールは管理しない」（OSGi コールバック、DSU）か、「分解の範囲が固定されている」（STM、RAII）かのいずれかです。Cordis の独占領域は：ランタイムの、任意スコープの、きれいにインストールもアンインストールもできる動的合成です。

3. 結論の振り返り：二つの次元、一つのパラダイム

第 7 章は論文全体を四つの文に凝縮しています。

1. 可逆エフェクトが時間次元を解決する——すべてのコンテキスト変換に明示的な逆を備え、エフェクト追跡が合成演算を保存することを証明し、それによって「コンポーネント除去時に状態を完全に復元する」ことを保証する。
2. リアクティブコーエフェクトが空間次元を解決する——型付き依存コンテキストを形式化し、満足性ベースの通知、コーエフェクトの分離、インターセプションを備えることで、「依存が揃って初めて起動し、依存がなくなれば自動で停止する」を開発者の自律ではなく構造的な保証にする。
3. ライフサイクルモデルが両者を縫い合わせる——複数の制御フローに適応する直交拡張として、二つの機構の相互作用に操作的意味論を与え、統一コンテキスト型を導出し、エフェクトコンテキストとコーエフェクトコンテキストを一つの一貫したプログラミングパラダイムに統合する。
4. 実装と検証——Cordis メタフレームワーク：コアライブラリがエフェクト追跡とコーエフェクト解決を担い、宣言的コンポーネントローダーが設定の調整とホットモジュールリプレースメントを担う。Koishi のケーススタディが、4000 を超えるコミュニティプラグインを抱える本番システムで設計を検証した。

そして未来の方向について、論文はとても SF 的な場所を指しています。自己進化するエージェントフレームワーク——ほとんど人間の監督を受けず、自分のフレームワークコンポーネントを継続的に生成し置き換えていく AI エージェントです。Cordis をこのような環境で使うことは、まさに二つの次元の究極の約束を検証することになります。コンポーネントの高速な置き換えにおける時間的保証（完全な復元）、そしてトポロジーが頻繁に変化する中での空間的保証（依存の調整）です。回復可能、調整可能、そして持続的に自己進化可能——これがこのパラダイムが目指す「自律システムの土台」です。

4. 要点の振り返り

1. サービスプロキシは排他バインドに勝る：プロキシは固定の入口として撹乱を吸収し、負荷分散・ローリングアップデート・プロセス間呼び出しの三点セットをもたらす。
2. セキュリティ二点セット：依存宣言はケーパビリティ要求（インターセプションと組み合わせてきめ細かなポリシーを実現）。信頼できないコードには外部の隔離境界が必要。
3. 言語独立性：時間次元には「クロージャ + モジュールレジストリ（あるいは dlopen のような機構）」が必要。空間次元には「DI + 型レイヤー + アクセス仲介」が必要。
4. 依存サイクルは分解できる：双方向の相互作用を「コアコンポーネント + 統合コンポーネント」に分解する。コストはコンポーネント数が二乗で増え得ることで、パッケージバンドルなどのエンジニアリング手段で緩和できる。
5. バージョン管理の三つの手：キーの名前空間化（衝突防止）、ピア依存（Cordis の現状）、構造的互換性（理想だが難しい）。

🎓 最後に：第二章（Cordis 論文の精読）を終えたあなたは、次の問いに答えられるはずです——「動的合成の二つの次元とは何か？なぜコンポーネントの分解には『時間』と『空間』の両方を語る必要があるのか？」「可逆エフェクトとリアクティブコーエフェクトはそれぞれ何を解決し、何を根拠に成立しているのか？」「コンポーネントの一生（ライフサイクル）はどう管理され、アンロードはなぜクリーンであることが保証されるのか？」「Cordis はどうやって論文を動くコードに変え、Koishi で検証されたのか？」「Effekt、AOP、DSU といった隣人たちとの違いはどこにあるのか？」すべてに答えられたなら——おめでとうございます、あなたはもう「論文を読んだ人」です。次のステップは、第一章に戻って、DSH がこれらすべてをどう現実のエージェントフレームワークに変えていくかを見ることです。