homulaAIエージェントを「どこで、どう安全に動かすか」という問いは、この一年、企業の統制設計の中心にありました。homula もエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の導入を「PoCから本番・全社へ」一気通貫で支援する中で、この**実行境界（どこで走らせ、何に触れさせ、どう記録するか）**を繰り返し扱ってきました。
2026年10月21日、ドイツで開かれた NVIDIA GTC Berlin 2026 は、その議論を一段先へ進めました。NVIDIA が発表した OpenShell 参照アーキテクチャ（Reference Architecture） は、これまでソフトウェアで作り込んできた「エージェントの隔離」を、チップ（シリコン）のレベルまで下ろし、業界共通の設計図として標準化する試みです（StorageNewsletter、NetworkWorld）。本稿で扱うのは製品紹介ではありません。隔離が「参照アーキテクチャ」になった今、それでも企業が自前で持ち続けるべき統制層はどこか——この実務の問いです。
OpenShell 参照アーキテクチャとは——「エージェントを信頼しない」を設計に落とす
OpenShell は、エージェントを最初から信頼できない存在（untrusted）として扱い、隔離・ポリシー・監視で囲い込むための仕組みです。中核のランタイム（OpenShell runtime）は Apache 2.0 ライセンスのオープンソースとして GitHub で公開され、その周りを NVIDIA のハードウェア（Vera CPU、Vera Rubin、BlueField-4 DPU）が固める構成になっています（NVIDIA 開発者ブログ、NVIDIA OpenShell）。
ランタイムは、役割の異なる4つの部品に分かれます。
| 部品 | 役割 |
|---|---|
| Gateway | 制御プレーン。エージェントの入口を束ねる |
| Supervisor | エージェントの外向き要求をポリシーと照合し、認証情報へのアクセスを仲介する。サンドボックスとは完全に分離して動く |
| Sandbox | ワークロードを隔離する実行箱。自分では一切ポリシー判断をせず、「エージェントが何をしようとしているか」を Supervisor に報告するだけ |
| Policy Prover | ポリシーの許可範囲を形式検証する |
設計思想は一貫しています。判断（ポリシー）を、信頼できないエージェントと同じ箱の中に置かない。Sandbox はエージェントと境界を共有するため、意図的に「決める権限」を持たせず、判断は隔離された Supervisor 側に寄せています。
さらに NVIDIA は、BlueField-4 DPU 上で動く独立監視層 Sentry を用意しました。Sentry はエージェントが到達も改変もできない隔離された領域で脅威検知・要求/応答の検査・封じ込めを行い、ポリシー違反を検知するとミリ秒単位でエージェントを隔離できるとされます（NVIDIA 公表）。「監視する主体を、監視される主体の手が届かない場所に置く」——証跡の信頼性を、ソフトの約束ではなくハードの分離で担保する発想です。
監査の面でも示唆的です。Supervisor のログと Sentry の記録を突き合わせると、「モデルが何を意図し／エージェントが何を試み／実際に何をしたか」を、エージェント自身が触れられない情報源から一本のタイムラインに再構成できる、と説明されています。NVIDIA は参照アーキテクチャを「提供開始済み」としており、Anthropic との提携（Claude を OpenShell 上で動かす）も合わせて示されています。
新しさは『隔離』そのものではなく、『参照アーキテクチャになったこと』
エージェントをサンドボックスに閉じ込める発想自体は、新しくありません。homula でも、評価用モデルが隔離環境を自力で脱出した事件や、「頭脳はクラウド・実行は自社」という責任分界点、「どこで動かすか」という実行レイヤーの分離を論じてきました。隔離が重要だという結論は、すでに共有されています。
OpenShell で注視すべきなのは、そこではありません。その隔離が「各社が自前で作り込むもの」から「業界共通の参照アーキテクチャ」へと格上げされ、しかもチップにまで下りたという点です。
- 標準化: 「信頼しない前提・判断と実行の分離・触れられない監視・相関監査」という原則が、特定製品の工夫ではなく参照設計図として提示された。
- シリコンへの降下: 隔離と監視を CPU・DPU というハードの境界で担保する。ソフトのバグや設定ミスで崩れにくくなる方向です。
- エコシステムの形成: 周辺を他社が埋め始めました。VAST Data はゼロコピー・クローンと「全ツール呼び出しの記録」を備えたサンドボックス基盤を、Cisco は後述の DefenseClaw を OpenShell と連携させています。
一言でいえば、「エージェントの檻」が一社の製品機能から、業界の“参照設計”へと一般化した。企業にとっての意味は、「自社でゼロから隔離基盤を作るか否か」ではなく、**「どんなスタックを採用するにせよ、この参照設計が示す原則を“調達要件”として持ち込めるか」**に変わった、ということです。
Cisco DefenseClaw——「隔離」の上に『誰の権限で・何をしたか』を重ねる
OpenShell が受け持つのは、隔離・監視という技術的な下半分です。その上に、組織の統制という上半分を重ねるのが、Cisco が同じ 10月21日に打ち出した DefenseClaw です（Cisco Blogs）。DefenseClaw はオープンソースで公開され（GitHub）、Claude Code・Codex・Copilot・Cursor など複数のコーディングエージェントに対応します。
DefenseClaw が OpenShell のサンドボックスの上に足すのは、次の層です。
- アイデンティティ連動ポリシー: OSのサインインID とグループポリシーに基づき、「このエージェントはサンドボックスの中でしか動かせない」を強制できる。「サインインした人物に追随する1つのポリシー」——つまり、どの端末でも“その人として動くエージェント”に同じ統制が付いて回る設計です。
- ガードレール: すべてのプロンプト・ツール呼び出し・ツール結果を、DefenseClaw のルールと Cisco AI Defense が検査・観測する。
- 宛先制御と変更レビュー: ホスト名単位の Web 宛先制御、セッション中の変更レビュー。
- 統一された監査証跡: 隔離境界の上に、「誰の・どのエージェントが・いつ・何を」を束ねた一本の記録を重ねる。
OpenShell が「隔離と、信頼できる記録の土台」を作り、DefenseClaw が「その上での判断・ポリシー・記録」を担う。ランタイムでエージェントを守る AIDR という新カテゴリの流れと同様に、防御が“実行する瞬間”へ寄り、識別情報（誰の操作か）と結びつく方向がここでも鮮明です。
参照アーキテクチャが解く問題と、企業になお残る宿題
OpenShell＋DefenseClaw は、これまで各社バラバラだった論点に共通の設計図を与えました。ただし、この設計図が解くのは“技術的な隔離と監視”であって、“組織としての統制”そのものではありません。企業にはなお宿題が残ります。
- 「どの操作に・誰の承認が要るか」はベンダーが決められない。サンドボックスは「外部送信・購買・削除」を隔離できますが、どれを自動で通し、どれに人手承認を挟むかは業務とリスク許容度に依存する企業固有の判断です。
- 監査線がスタック内に閉じがち。この参照設計の証跡は強力ですが、主に「NVIDIA のハードで動くコーディングエージェント」の世界の記録です。実際の企業環境は、SaaS 組込みエージェント・業務自動化基盤・各社クラウドが入り混じる多ベンダー構成で、横串の監査線はそのままでは引けません。
- エージェントIDを“業務上の権限”に結び直すのは企業側。OSサインインIDへの追随は出発点にすぎません。エージェント一体ごとに固有のID・最小権限・短命の資格情報を与える設計と、それを職務・ロールへ対応づける作業は企業の責任範囲に残ります。
- 大半の日本企業は Vera Rubin ラックを自前では回さない。だからこそ重要なのは、参照設計が示した原則——信頼しない前提での隔離／触れられない独立監視／相関した監査／ID連動のポリシー——を、採用するスタックへの“要件”として持ち込むことです。ハードを買えるかではなく、原則を要求できるかが分かれ目になります。
homula の観点——参照アーキテクチャの『原則』を、企業の実環境へ持ち込む
homula は、エージェント導入を「便利な機能を許すか否か」ではなく、「誰が・何者として・どの権限で動き・何をしたかを辿れるようにする」立場で支援しています。OpenShell が示した原則は、まさにこの考え方のハード側からの裏づけです。問題は、その原則を多ベンダーが入り混じる企業の実環境へどう適用するかにあります。実装の順序はこう整理できます。
- 接続層（Agens）: Agens は MCP を活用し、200以上のツールと構築ゼロで接続します。エージェントがどのSaaS・社内システムに触れられるかを組織として承認済みの経路に集約する——「何に触れさせるか」を絞る、参照設計でいう境界側の土台です。
- ID・最小権限層: エージェントを社員個人のアカウント越しに動かさない。業務で使う主体には固有のIDと、リソース単位の最小権限、短命の資格情報を割り当て、「人の操作」と「エージェントの操作」を最初から分離する。
- 実行時の統制層（Agens Control）: 隔離の“上半分”をベンダー横断で担う層です。Agens Control は承認フロー・DLP・RBAC・5年分の監査ログを提供します。低リスクの参照系は止めずに走らせ、外部送信・購買・署名・削除のような不可逆な操作にだけ人手承認を挟み、「どのエージェントが・いつ・何をしたか」をベンダーをまたいで一本の証跡に束ねる——OpenShell が1つのスタック内で実現したことを、企業の実環境全体へ広げる役回りです。
適所適ツール（n8n / Dify / LangGraph）で強弱のある権限設計を作り分ければ、参照アーキテクチャの恩恵——信頼しない前提での隔離と、触れられない監査——を、自社の現実の構成の上で取りにいけます。どこから手をつけるかは、業務棚卸しからROI試算までを3〜5日で完結する AIエージェント・ブートキャンプ で、「どの業務をサンドボックスに委ね、どの操作に組織の承認と監査を置くか」を先に見極めるのが近道です。
まとめ
NVIDIA OpenShell は、「エージェントは信頼できない前提で隔離する」という原則を、ソフトの作り込みから業界共通の参照アーキテクチャへ、さらにシリコンへと押し下げました。判断と実行の分離、触れられない独立監視、相関した監査——どれも、企業が実行境界に求めてきたものの“標準形”です。Cisco DefenseClaw は、その隔離の上に「誰の権限で・何をしたか」を重ねます。
ただし、参照設計が解くのは技術的な隔離までです。どの操作に誰の承認を挟むか、監査線をどう全ベンダーに横串で通すか、エージェントIDをどう業務権限へ結び直すか——ここは企業が自前で持ち続ける統制層として残ります。日本企業がいま準備すべきは、特定のハードを買うことではなく、参照アーキテクチャが示した原則を“調達と運用の要件”に翻訳し、自社の実環境へ持ち込むことです。その順序があって初めて、強力な「檻」は、全社で安心して使える実行基盤へと変わります。
参照アーキテクチャの原則を、自社の多ベンダー環境での「接続・ID・承認・監査」の設計へ——その翻訳から実装まで、homula が業務棚卸しからROI試算まで一気通貫で伴走します。