AIエージェントが自律的に動くほど、実行環境の設計がボトルネックになります。Unicity Labsが公開したAstridは、Linuxがプロセスを扱うようにエージェントを扱うユーザ空間マイクロカーネルです。セキュリティ、監査性、オーケストレーションをカプセル単位で組み替えられる基盤として注目されています。
この記事では、Astridが解決する課題と、カプセルアーキテクチャによる拡張の仕組み、分解型セキュリティモデルの中身を整理します。
この記事でわかること
- Astridが「エージェント向けOS」と呼ばれる理由
- カプセル（capsule）でLLMやツールを差し替える仕組み
- 監査ログや承認ゲートなど、運用面の設計
- 最新リリースv0.8.0で追加された機能
https://github.com/unicity-astrid/astrid
エージェント基盤にOSが必要な理由
多くのエージェントフレームワークは、LLMプロバイダやオーケストレーションループ、ツール一覧をコードに直接埋め込みます。モデルを変えたい、承認フローを足したい、監査ログを残したい——こうした変更のたびに、フレームワーク本体をフォークして保守する必要が出てきます。
Unicity Labsは2026年6月25日の投稿で、エージェント向けOSが必要な理由を次の観点で列挙しています。セキュリティ、監査性（auditability）、オーケストレーション、LLMルーティング、アクションログ、オフライン動作、改善ループ、オープンソース、任意モデルの利用、カプセルの追加です。個別のライブラリではなく、実行基盤そのものを整える発想です。
Astridとは何か
AstridはRust製のユーザ空間マイクロカーネルで、AIエージェントをプロセスのように扱います。カーネルはブートシーケンス、コピーオンライトの仮想ファイルシステム、ed25519のケイパビリティトークン、IPCイベントバス、WASMによるプロセス分離、前エントリをハッシュする暗号学的監査トレイルを備えます。
カーネルは固定で、それ以外はすべてカプセルとして差し替えます。プロバイダ、オーケストレータ、ツール、フロントエンド、インターセプタはすべてカプセルです。Capsule.tomlマニフェストで宣言し、[imports]/[exports]テーブルで依存関係を定義します。カーネルはトポロジカルソートで依存を解決し、起動順を決めます。
ライセンスはMITまたはApache-2.0のデュアルライセンスです。macOS（x86_64・aarch64）とLinux（x86_64・aarch64）向けのバイナリがGitHub Releasesから入手できます。
カプセルがもたらす柔軟性
カプセルはWASM上で動く独立プロセスです。Extism/Wasmtimeのサンドボックス内で実行され、システムコールやファイルディスクリプタ、ホストメモリへの直接アクセスはありません。外部リソースへのアクセスはすべてケイパビリティチェック付きのホスト関数を経由します。ホストABIはファイルシステム、IPC、ストレージ、ネットワークなど49の関数で構成され、メモリ上限は64MB、ウォールクロックタイムアウトは5分です。
この設計により、次のような構成が可能です。
- 任意のLLMモデル：プロバイダカプセルをOllamaやvLLM向けに差し替えれば、オーケストレータ側の変更なしでオフライン運用ができます
- LLMルーティング：複数のプロバイダカプセルを同時に走らせ、ルーティングカプセルが複雑さ・コスト・レイテンシに応じて振り分けます
- 独自オーケストレーション：討論型、モンテカルロ木探索、検証チェーンなど、研究用途のループをカプセルとして実装できます
- コスト削減：キャッシュカプセルをミドルウェアとして挟み、同一プロンプトへの再呼び出しを避けられます
- 自律エージェント：テストを回し、エラーを読み、自己修正するワーカーカプセルに差し替えれば、チャットボットから自律エージェントへ昇格できます
カプセルはランタイムにインストールでき、エージェントがRustソースとテストを書いてastrid-buildでビルドし、capsule installで自分のOSを拡張する構想もREADMEに記載されています。
分解型セキュリティモデル
Astridのセキュリティは単一のゲートに集約されません。各領域で独立したメカニズムがfail-closedで動きます。
| 層 | 役割 |
|---|---|
| WASMサンドボックス | カプセルに環境権限を与えず、すべての効果をホスト呼び出しに限定 |
| マニフェストゲート | 宣言されたallowlist外のファイル・ネットワーク・プロセス操作を拒否 |
| IPC ACL | マニフェストの[publish]/[subscribe]キーでトピック単位の認可 |
| ケイパビリティトークン | ed25519署名付き、リソースパターン・有効期限・失効に対応 |
| 予算管理 | セッションとワークスペースの二重予算を原子的に強制 |
| 承認ゲート | 人間の承認を挟む。人間が不在でもサイレントにスキップしない |
| OSサンドボックス | ネイティブ子プロセスをbwrap/seatbeltで隔離 |
| 監査ログ | ハッシュチェーンとed25519署名で改ざん検知 |
運用モードはsafe（ワークスペース外の操作ごとに確認）、guided（読み取りは自動、書き込みは確認）、autonomous（ガードレール解除）、yolo（制限なし）の4段階です。ワークスペース設定はセキュリティを厳しくする方向にのみ変更でき、緩和はできません。
監査性とアクションログ
監査ログはチェーンリンク構造で、各エントリが前のエントリをハッシュし、ed25519で署名されます。SurrealKVをバックエンドに使い、プリンシパル（ユーザー識別子）ごとにチェーンを分割します。verify_principal_chain()でプリンシパル単位の整合性を検証できます。
各プリンシパルはカプセル、KVデータ、監査チェーン、ケイパビリティトークン、ログをhome/{principal}/以下で完全に分離します。IPCメッセージチェーンを通じてアクティブなプリンシパルが透過的に伝播するため、カプセル側でプリンシパルルーティングを意識する必要はありません。
最新リリースv0.8.0の要点
2026年6月11日にリリースされたv0.8.0は、v0.7.0から約50のPRを含む大型アップデートです。主な変更点は次の3つです。
HTTP管理ゲートウェイ：astrid-gatewayクレートがカーネルの管理・リクエストIPCをHTTPで公開します。プリンシパル、ケイパビリティ、クォータ、グループ、招待、監査SSE、OpenAPI仕様の出力、ネイティブTLS、Prometheusメトリクスに対応します。
ランタイム並行性の刷新：カプセル・トピック・プリンシパルごとのルーティングIPC、DRRフェアネス、非同期Wasmtime、動的インスタンスプール、CPU燃料とピークメモリのレジャーによるレート制限が追加されました。
ホストプロセスとイントロスペクション：子プロセス管理とランタイム可視化の面が拡充されています。
現時点のフロントエンドはCLI（astrid chat）のみで、追加のUIやマルチノードSurrealDB（TiKV/Raft）、WASM Component Modelへの移行は未完了とREADMEに明記されています。
類似ツールとの違い
LangChainやCrewAIなどのエージェントフレームワークは、チェーンやロール定義に特化したアプリケーションレイヤーです。一方Astridは、サンドボックス、IPC、ファイルシステム、監査、承認をカーネルが担うOSレイヤーに位置づけられます。フレームワークを置き換えるというより、その上に載せる実行基盤として設計されています。
MCP（Model Context Protocol）にも対応しており、MCPサーバーをカプセルとしてラップできます。v0.5.0以降、ツールとLLMプロバイダはカーネルが直接管理せず、IPCインターセプタによる純粋な規約として扱われます。
導入を検討する際のポイント
エージェントの自律性が上がるほど、「何を許可し、何を記録し、誰が承認するか」を基盤レベルで設計する必要があります。Astridはカプセルによる組み合わせと分解型セキュリティで、その課題に正面から向き合うOSSです。任意のモデルと任意のカプセルを載せられる点は、研究から本番運用まで幅を持たせる設計と言えます。興味があれば、GitHubリポジトリのREADMEとオペレータ向けドキュメントから試してみてください。