コンテナの限界を超える：AIエージェント向けOSレベル権限管理の設計思想と実装トレードオフ

AIエージェント実行環境における「権限」の再定義：なぜコンテナだけでは不十分なのか

従来のインフラ設計では、「コンテナで分離すれば十分」という前提が広く共有されてきた。しかし、AIエージェントをホスト上で実行する場合、この前提は根本から崩れる。

静的なスクリプトやバッチジョブと異なり、AIエージェントは実行中に必要なツールや依存関係を動的に要求する。例えば、エージェントがホスト上でffmpegのインストールを実行すると、パッケージデータベースの変更や監査していない依存関係の取得など、予期せぬ永続的なシステム状態変化を引き起こす可能性がある（ShrekOSの設計背景参照）。

ここで問題になるのは、コンテナの分離機能が「プロセスの可視性」や「ネットワークの断絶」には有効でも、ホストOSレベルでの永続的な状態変化を完全に遮断できない点である。パッケージマネージャーがホストのデータベースに書き込みを行う瞬間、コンテナの境界はすでに意味を失っている。

AIエージェントに有用性を持たせるために全マシンへの信頼を委ねることは危険であり、権限の決定はモデルやフレームワークではなくOSの下部層で行われるべきである（ShrekOSの設計背景参照）。この設計判断の核心は、「誰が権限を決定するか」のレイヤーを、上層のアプリケーションから下層のOSに移すことにある。

観点	コンテナベース設計	OSレベル権限管理
動的な依存関係解決	イメージビルド時に固定	ランタイムで制御可能
ホストへの影響範囲	境界突破時に不明確	OS層で遮断・監査
権限決定の主体	イメージ作成者（静的）	OSカーネル（動的）
永続的変更の制御	コンテナ外では対象外	不変性で物理的に防止

この比較から明らかなのは、コンテナは「静的な実行環境の分離」には有効だが、「動的に権限を要求する主体の制御」には構造的に不適合であるという点である。次のセクションでは、このギャップが既存の分離技術においてどのように表れるかを詳しく見る。

既存の分離技術が抱える「実行時モデル」のギャップ

コンテナやnamespacesはセキュリティの一部を解決するが、実行時に必要な能力を動的に要求するワークロードに対する一貫した運用モデルは提供していない（ShrekOSの設計背景参照）。この一文が、既存技術の限界を最も端的に表している。

権限付与のタイミングが「事前」に固定されている

従来のコンテナ設計では、権限の付与は基本的に2つのタイミングで行われる。1つはイメージビルド時のDockerfileやComposeファイルによる設定、もう1つはコンテナ起動時のフラグや設定ファイルである。どちらも「実行前に確定する」前提で設計されている。

しかし、AIエージェントの動作は本質的にランタイムで分岐する。あるタスクではネットワークアクセスが必要で、次のタスクではローカルファイルへの書き込みが必要になる。この「状況依存的な要求」に対して、既存のコンテナランタイムには即座に許容・拒否を判断するメカニズムが存在しない。

ランタイム制御の欠如がもたらす運用上の問題

具体的には、以下のような問題が連鎖する。第一に、エージェントが実行中に権限不足で失敗した場合、コンテナを停止して設定を変更し、再起動するという手作業が発生する。第二に、権限を「最初から広く与えておく」という運用に逃げると、エージェントが想定外の操作を実行してもOSレベルで止められない。第三に、どの権限がどのタスクに対して付与されたかの監査が、設定ファイルの差分追跡に頼らざるを得ない。

これらの問題の根本原因は、プロセス間通信やシステムコールレベルでの動的制御が、既存のコンテナランタイムの設計に組み込まれていないことにある。namespacesは「何を可視化するか」を制御するが、「何を実行させるか」をランタイムで動的に判断するフレームワークではない。このギャップを埋めるには、OSの下部層に制御点を用意する必要がある。

ShrekOSのアプローチ：ゼロからカーネル開発ではなく、既存メカニズムの統合

ShrekOSはゼロからカーネルを開発するものではなく、既存のメカニズムを組み合わせて、エージェントが能力を随時要求できる一貫した運用モデルを実現しようとする試みである（ShrekOSの設計背景参照）。

「新規開発 vs 既存技術の再構成」の判断基準

この設計選択の背景には、3つのトレードオフがある。第一に安定性。新規カーネルはLinuxコミュニティの数十年にわたるバグフィックスと性能最適化を自前で再現する必要があり、実運用で耐えられる品質に到達するまでのコストが膨大になる。第二にエコシステム互換性。既存のLinuxカーネル上で動作するデバイスドライバやユーザーランドツールとの互換性を、新規カーネルで維持するのは現実的ではない。第三に維持コスト。カーネルのアップストリーム追従、セキュリティパッチの適用、新ハードウェアのサポートといった継続的な作業が、プロジェクトの規模を大きく制限する。

一方、既存のLinuxカーネル機能（AppArmor、namespaces、cgroups等）を統合するアプローチでは、これらのコストを大幅に抑えつつ、OSレベルでの権限制御を実現できる。各メカニズムは個別には成熟しているが、AIエージェントの「動的な能力要求」というワークロードに統合して適用した例がほとんどない。ShrekOSの独自性は、この「統合の設計」にある。

既存メカニズムの統合アーキテクチャ

ShrekOSのアーキテクチャでは、エージェントの能力要求がOS層に到達した際、既存のセキュリティフレームワークが協調して制御を行う。AppArmorがファイルアクセスの境界を定義し、namespacesが可視性を分離し、cgroupsがリソースの上限を管理する。これらを単独で使うのではなく、「エージェントが能力を要求する」という一貫した運用モデルの下で統括的に適用する点に設計の核心がある。

flowchart TD
    A["AIエージェント"] --> B["能力要求"]
    B --> C{"OS制御層"}
    C --> D["AppArmor（パスベースのアクセス制御）"]
    C --> E["namespaces（可視性の分離）"]
    C --> F["cgroups（リソース上限）"]
    D --> G["許可 / 拒否の判定"]
    E --> G
    F --> G
    G --> H["実行結果の返却"]

この統合アーキテクチャの利点は、各メカニズムの既存の成熟度をそのまま活かせる点にある。AppArmorのポリシーファイルは人間が読みやすく、namespacesはカーネルに組み込まれた標準機能である。新規開発に比べて、セキュリティ監査や障害時の切り分けが容易になる。一方で、各メカニズムのポリシーが相互に矛盾しないように整合性を保つ設計が、統合層の最大の難所となる。

不変性（Immutability）と原子性アップデート：ベースOSの設計指針

統合層の設計が定まった後、次に検討すべきは「その統合層が乗る基盤自体をいかに変えないか」という問題である。AIエージェントが権限を要求し、OS制御層が許可・拒否を判定する仕組みを構築しても、エージェントが何らかの経路でベースOS自体を書き換えることが可能であれば、すべてのセキュリティ保証は無意味になる。この問題を根本から断つのが、不変性（Immutability）の設計指針である。

密封されたイメージとDebianの採用

ShrekOSのベースOSにはDebianが採用されている。Debianが選ばれる理由として、パッケージ管理体系の成熟度やコミュニティの安定性といった一般的な利点に加えて、今回の文脈では「イメージ全体の整合性を検証しやすい」点が重要になる。密封された不変なイメージとして構築されることで、ホストOSがランタイム中にカジュアルに変更されることを物理的に防ぐ。エージェントがファイルシステムに対して書き込みを試みても、ベースイメージは読み取り専用としてマウントされるため、変更は構造的に不可能である。

ここで設計判断が分かれるのは、不変性を「読み取り専用マウント」で実現するか、それとも「overlayfsによる上書き層」で実現するかである。前者は最もシンプルで、書き込み試行が即座にエラーとして返るため、エージェント側のデバッグも明確になる。後者は、エージェントが一時ファイルの作成を許容しつつ、ベースには影響を及ぼさないという柔軟性を提供する。ShrekOSのアプローチでは、エージェントが実際に動作するための最小限の書き込み領域（ワークディレクトリや一時領域）をoverlayで提供しつつ、システムディレクトリ自体は不変に保つ、という中間的な設計が考えられる。

原子性アップデートとロールバック

不変なイメージを採用した場合、セキュリティパッチの適用や依存関係のバージョンアップは「イメージ全体の交換」に帰着する。ここで実務上の課題が2つ生じる。1つは、交換中のダウンタイムである。エージェントが稼働中にベースOSを差し替えると、実行中のプロセスが中断される。もう1つは、更新後のイメージに不具合がある場合の復旧コストである。

原子性アップデート（ロールバック可能）の採用は、この2つの課題を同時に解決する。具体的には、新しいイメージを現在のイメージと並列で用意し、起動時にどちらを読み込むかを決定する方式である。更新後のイメージで異常が検出された場合、次回起動時に前のイメージへ自動的にロールバックされる。これにより、パッチ適用の失敗が運用停止に直結するリスクを排除できる。

なお、Fedoraの検証済み起動（Verified Boot）の仕組みは、ShrekOSのプロジェクトにおいて参考画像としてVM上で研究されるにとどまり、主要なベースOSとして採用されているわけではない。ただし、起動チェーンの各段階で整合性を検証するという思想自体は、不変性設計と親和性が高く、イメージ交換時の整合性チェックにその考え方が活かされている。

権限制御の実装：AppArmorによるパスベースのモデルとポリシー管理

ベースOSの不変性が「変えてはいけない領域」を構造的に保証する一方で、エージェントが実際にアクセスできるファイルを細粒度で制御するのが、AppArmorによるパスベースのアクセス制御である。AppArmorはLinuxカーネルに組み込まれたマンドラート型（path-based）のセキュリティモジュールであり、プロセスが特定のパスに対して読み書き・実行のいずれの操作を許容するかを、人間が読みやすいテキストファイルで定義する。

エージェントが自身の権限を決定できない設計

AppArmorのポリシーファイルは、エージェントが自身の実行コンテキストから参照・変更できない領域に配置される。これは「エージェントが自身の権限制限を決定しない」ことを保証する設計の核心である。たとえエージェントが内部的にsudoやchmodを実行しようとしても、カーネルレベルでAppArmorが介入し、ポリシーで許可されていないパスへのアクセスを拒否する可能性がある。エージェントの意思決定プロセスの複雑さや、プロンプトインジェクションによる権限昇格のリスクを考慮すると、権限の最終判定をモデル層ではなくOS層で行うことが一般的に推奨される。

以下は、AppArmorプロファイルの構造を示す概念例である（実環境のパス・バイナリ名は異なる）。

# 概念例：エージェントプロセスのAppArmorプロファイル
# 実際のパス・バイナリ名は環境に応じて異なる
profile agent-exec {
  # 実行バイナリの読み込み
  /usr/bin/agent-exec r,

  # 許可されたワークディレクトリへの読み書き
  /var/lib/agent/work/** rw,

  # システム設定への書き込みを明示的に拒否
  deny /etc/** rw,
  deny /usr/lib/** w,
  deny /usr/bin/** w,
}

この形式の利点は、ポリシーの意図がファイル1つで把握できる点にある。セキュリティ監査の際に「このエージェントは何にアクセスできるのか」を、コードレビューと同様にテキストの差分として確認できる。カーネル内部のビットフラグやコンテキストラベルを解析する必要がないため、インフラチームとアプリケーションチームの間に生じる認知のギャップが小さくなる可能性がある。

パスベースモデルの限界と補完メカニズム

一方で、パスベースのモデルには構造的な限界がある。ネットワーク接続の許可・拒否（特定のポートへの接続制限）、デバイスノードへのアクセス、プロセス間通信（IPC）の制御などは、ファイルパスでは表現できない。これらの権限については、Linux Capabilitiesやiptables/nftables、seccomp-bpfなどの別メカニズムを併用する必要がある。AppArmor自体もネットワークルールをサポートしているが、実運用ではどのメカニズムにどの権限を割り当てるかの境界設計が重要になる。

手法	権限モデル	可読性・監査性	表現可能な権限の種類
AppArmor	パスベース（マンドラート型）	高。テキストファイルで人間が直接読める	ファイルアクセス、一部ネットワーク
SELinux	ラベルベース（MAC型）	中。ラベルとポリシーの関係が複雑	ファイル・プロセス・ネットワーク・IPC
Linux Capabilities	能力フラグ（root権限の分割）	中。フラグ名は直感的だが組み合わせが膨大	ネットワークバインド、デバイス操作、マウント等

ShrekOSのアプローチでは、AppArmorを第一の制御軸とし、Capabilitiesやseccomp-bpfを必要に応じて補完するレイヤード構成がとられている。各層が何を担当するかを明確に分離することで、ポリシーの矛盾や重複による意図しない権限の拡大を防ぐ。

動的な能力要求への対応：ランタイムでの権限付与メカニズム

ここまでの設計では、「何にアクセスできるか」を静的に定義してきた。しかしAIエージェントの本質的な問題は、実行時に必要なツールや依存関係が事前に確定しない点にある。エージェントがタスクを処理する過程で「ffmpegで動画のフレームを抽出する必要がある」と判断し、ffmpegがまだインストールされていない環境で動作している場合、従来のコンテナモデルではイメージの再ビルドか、ホストへの直接インストールのいずれかを迫られる。

ホスト上でffmpegをインストールした場合、パッケージデータベースの変更や、監査していない依存関係の取得など、予期せぬ永続的なシステム変更が発生する。これは不変なベースOSの設計思想と根本的に矛盾する。ShrekOSが解決しようとしているのは、まさにこの「動的な能力要求」と「不変なベースOS」の間のギャップである。

能力サービスによる間接アクセス

ShrekOSのアプローチでは、エージェントは直接パッケージマネージャーを実行できない。代わりに、OS側が提供する「能力サービス」を通じてのみ、ツールの利用を要求する。エージェントが「ffmpegを使いたい」というリクエストを送信すると、OS制御層が以下の一連の処理を行う。

リクエストの検証：要求されたツールがポリシーで許可されているか確認する。
一時的な環境の構築：許可された場合、overlayfsやnamespacesを用いて、ベースOSとは分離された一時的な実行環境を生成する。
依存関係の解決：その一時的な環境内でのみ、必要なパッケージやライブラリを展開する。
実行と破棄：エージェントが処理を完了すると、一時的な環境は破棄され、ベースOSには何の変化も残らない。

この設計により、パッケージデータベースの変更や依存関係の取得は、OS側で管理された一時的な環境内に限られ、ホストへの永続的な影響を構造的に回避する。エージェントの自律性（必要なツールを随時要求できる）とシステムの安定性（ベースOSは不変）が、この抽象化レイヤーを介して両立する。

sequenceDiagram
    participant A as AIエージェント
    participant B as OS制御層（能力サービス）
    participant C as 一時的な実行環境
    participant D as 不変なベースOS

    A->>B: 能力リクエスト（ffmpegが必要）
    B->>B: ポリシー検証
    B->>C: 一時的な環境を生成
    C->>C: 依存関係を一時的な環境内に展開
    B->>A: 能力トークン（環境ID）を返却
    A->>C: ffmpegを実行
    C-->>A: 処理結果を返却
    A->>B: 処理完了通知
    B->>C: 一時的な環境を破棄
    Note over D: ベースOSに変更なし

このシーケンスの設計上の要点は、エージェントがベースOSに直接接触する経路が一切存在しない点である。能力トークンは一時的な環境へのアクセス権限のみを含み、ベースOSのファイルシステムやパッケージデータベースに対する書き込み権限は含まれない。トークンの有効期限やスコープをOS側で管理することで、エージェントの異常終了後も一時的な環境が残留するリスクを低減できる。

この設計は、エージェントの自律性とシステムの安定性の両立において重要な分岐点となる。エージェントに「自分で環境を構築する」権限を与えるほど自律性が高まるが、その分だけベースOSへの影響範囲が拡大する。能力サービスという間接層を介すことで、自律性を保ちつつ影響範囲を一時的な環境内に封じ込めるというトレードオフの最適点を見つけるのが、この設計の核心である。

トレードオフの分析：セキュリティ vs 開発者体験（DX）

OSレベルで厳格な権限管理を導入すると、エージェントの実行時に「想定外のエラー」が発生する頻度が上昇する。具体的には、エージェントがファイルの読み書きやネットワーク接続を試行した際に、AppArmorのポリシーに抵触してシステムコールが拒否されるケースである。従来のコンテナ環境では、イメージビルド時に必要な権限をまとめて付与するため、実行時の権限エラーは稀であった。しかし、動的な能力要求を前提とする設計では、エージェントの行動パターンがポリシーの境界を越えることが日常的に起こり得る。

このデバッグコストを低減するための設計判断が、ShrekOSの著者がAppArmorのポリシーファイルを採用した理由である。SELinuxのようなラベルベースのモデルは表現力が高い反面、ポリシーの可読性が低く、違反が発生した際に「どのラベルのどの関係で拒否されたのか」を特定するコストが高い。一方、パスベースのポリシーファイルは、拒否されたパスと許可されたパスの差分を直接確認できるため、原因の切り分けが直感的に行える。この可読性の差は、エージェントの動作をデバッグする頻度が高くなるAIエージェント運用において、実務上のコスト差として顕在化する。

不変なベースOSの採用も、DXへの影響を伴う。Debianベースの密封イメージと原子性アップデートにより、ホストがカジュアルに変更されないことを保証する設計は、環境の再現性を高める。これにより「開発環境では動くが本番では動かない」という問題が構造的に解消される可能性がある。一方で、ベースOSにカスタムライブラリや特殊なカーネルモジュールを追加する柔軟性は失われる。エージェントが特定のハードウェアアクセラレータやプロプライエタリなドライバを必要とする場合、ベースOSを再ビルドするか、一時的な環境内にそれらを収容する設計に落とし込む必要がある。

設計要素	セキュリティ上の利点	DXへの影響
不変なベースOS	永続的な不正変更の遮断	カスタムライブラリの追加が困難
パスベースのポリシー	最小権限の強制適用	ポリシー作成の初期コスト
能力サービス経由のアクセス	影響範囲の一時的環境内封じ込め	エージェント側の実装複雑度増
原子性アップデート	更新失敗時の即時ロールバック	アップデート頻度の制約

トレードオフの最適点は、エージェントの用途に依存する。読み取り中心のデータ分析エージェントであれば、不変性による制約はほぼ無視できる。一方、ビルドやパッケージインストールを頻繁に行うエージェントでは、一時的な環境の作成・破棄のオーバーヘッドが累積し、実効スループットに影響し得る。設計段階で「どの程度の頻度で、どのスコープの能力要求が発生するか」を推定し、能力サービスのレスポンスタイムとポリシーの粒度を調整する必要がある。

実装パターン：エージェントとOS間での「能力」の抽象化

エージェント側からは「ffmpegを使いたい」という高レベルな意図として表現され、OS側ではそれが「一時的なファイルシステムマウント」「ネットワーク制限付きのユーザー空間」「特定パスへの読み書き権限」という具体的なリソースの組み合わせに翻訳される。この翻訳を行うのが抽象化レイヤーであり、エージェントはOSのセキュリティモデルの詳細を知らなくても、必要な機能を利用できる。

実装の形式としては、gRPCやREST APIを通じてエージェントが「能力リクエスト」を送信し、OS側が「能力トークン」または「一時的な環境設定」を返すパターンが考えられる。能力リクエストには、要求するツールの名前、必要なファイルパス、ネットワーク接続の範囲、有効期限などのメタデータが含まれる。OS側はこれらのメタデータを検証し、既存のポリシーと矛盾しない範囲で能力トークンを発行する。トークンは一時的な環境へのアクセス権限のみを含み、ベースOSのファイルシステムやパッケージデータベースに対する書き込み権限は含まれない。

このパターンは、マイクロサービス間における通信制限や、クラウド上のサーバーレス関数の権限管理と構造的に類似している。サーバーレス関数では、IAMロールやリソースポリシーを通じて「この関数はこのS3バケットのこのプレフィックスのみ読み書き可能」という制約を課す。能力サービスも同様に、エージェントごとにスコープされた権限を発行し、有効期限の経過やタスク完了時に自動的に回収する。この類似性は、既存のクラウドネイティブな権限管理の知見をAIエージェントのOSレベル設計に転用できることを意味する。

flowchart TD
    A["AIエージェント"] -->|"能力リクエスト (ツール名, パス, 有効期限)"| B["抽象化レイヤー (gRPC/REST)"]
    B --> C["ポリシー検証"]
    C -->|"承認"| D["能力トークン発行"]
    C -->|"拒否"| E["エラー応答"]
    D --> F["一時的な環境の作成"]
    F --> G["エージェントが環境内で実行"]
    G --> H["環境の破棄"]

この抽象化レイヤーの設計で重要なのは、リクエストの粒度である。リクエストが粗すぎると（例:「ネットワークにアクセスしたい」）、OS側が適切なスコープを決定できず、過剰な権限が付与される可能性がある。逆に細かすぎると（例:「このIPアドレスへのこのポートへのTCP接続」）、エージェント側の実装が複雑になり、エージェントの自律性が損なわれる。実務的には、ツール単位（「ffmpegを使用」）をリクエストの単位とし、ツールが内部的に必要とする具体的なリソースはOS側で決定する、という分割がバランスを取りやすい。

運用における監視と監査：何が、いつ、どのように実行されたか

OSレベルでの権限管理を導入した場合、従来の「アプリケーションログの集約」だけでは不十分になる可能性がある。監視すべき対象は主に三層に分類される。第一に、能力リクエストの履歴である。エージェントがいつ、どのような能力を要求し、承認されたか拒否されたかを記録する。第二に、システムコールレベルの監視である。AppArmorなどのセキュリティモジュールによるポリシー違反試行は、エージェントが意図せぬ動作を試みている兆候となり得る。第三に、一時的な環境のライフサイクルである。環境の作成から破棄までの時間、環境内で実行されたプロセス、生成されたファイルの量などを記録する。

能力リクエストのパターン分析は、異常検知とポリシー最適化の両方に活用できる可能性がある。例えば、あるエージェントが特定の能力を短時間に繰り返し要求している場合、それはタスクの設計に問題があるか、エージェントの挙動が異常であるかのいずれかを示唆する。前者であれば能力リクエストの粒度を調整し、後者であればエージェントの実行を中断する判断材料になる。また、頻繁に拒否される能力リクエストのパターンを分析することで、ポリシーの粒度が不適切であることが判明し、ポリシーの更新サイクルをデータドリブンで回せる場合もある。

不変なベースOSの運用では、ログの永続化戦略が設計段階で決定的になる。ベースOSが書き込み不可であれば、ローカルディスクにログを蓄積できないため、ログは揮発性メモリに一時保持し、外部の集約サーバー（Syslogサーバーやログ集約プラットフォーム）に転送する構成になることが多い。この構成では、集約サーバーへの転送が失敗した場合のログ損失リスクを考慮する必要がある。揮発性メモリに保持するログの量と転送頻度のバランス、転送失敗時のリトライ戦略、最悪の場合のログ損失許容範囲を事前に定義しておくことが重要である。

AppArmorのポリシーファイルの変更履歴をバージョン管理システムで管理することも、監査の観点から重要である。ポリシーファイルはエージェントの動作を直接制約するもののため、変更の意図と内容を追跡可能にしておくことで、セキュリティインシデント発生時の原因特定が迅速になる可能性がある。ポリシーの変更と、エージェントのバージョンアップやタスクの変更を関連づけて記録しておくことで、「このポリシー変更が導入された後に、このエージェントの動作が変化した」という因果関係を立証できる場合がある。

まとめ：コンテナを超えた、AIエージェントのための信頼基盤

AIエージェントの普及に伴い、従来のコンテナベースのセキュリティモデルでは対応しきれない課題が顕在化している。エージェントは静的なスクリプトと異なり、実行時に必要なツールや依存関係を動的に要求し、その要求に応える過程でベースOSに永続的な変更が生じる可能性がある。コンテナやnamespacesはセキュリティの一部を解決するが、実行時に必要な能力を動的に要求するワークロードに対する一貫した運用モデルを提供していない場合がある。

ShrekOSの事例から学べる設計指針は、以下に整理できる。第一に、ゼロからのカーネル開発ではなく、既存のLinuxセキュリティ機能（AppArmor、namespaces等）を統合するアプローチが、安定性とエコシステム互換性を保ちつつ、動的な能力要求への対応を実現できる可能性がある。第二に、不変なベースOSと原子性アップデートにより、エージェントの動作がホストOSに永続的な影響を与えないことを構造的に保証する。第三に、エージェントが自身の権限制限を決定しない設計により、権限の境界をOSの下部層で固定する。これらの要素が組み合わさることで、エージェントの自律性とシステムの安定性の両立が可能になる。

今後の課題として、より細粒度な権限管理の仕組み（例: ファイル単位の読み書き制御、ネットワークトラフィックの深層パケット検査との連携）や、AIモデル自体のセキュリティ評価との連携が浮上してくると考えられる。エージェントの「意図」を評価対象とし、意図と実際のシステムコールの乖離を検知する仕組みが実現されれば、現在の「ポリシー違反の事後検知」から「意図の事前検証」への進化が期待できる。OSレベルの信頼基盤は、AIエージェントの安全性を担保するための基盤技術として、継続的な進化が必要である。

参考

本記事は海外の技術トレンド「Why I'm Building ShrekOS When Containers Already Exist」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。