コンテンツにスキップ

社内AIエージェント基盤（Company Brain / AI Operating System for Companies）比較レポート

作成日: 2026-08-19 出典 / きっかけ: 一次情報（GitHub README/SECURITY.md、公式エンジニアリングブログ、脅威モデル文書、学術論文）に基づく横断アーキテクチャ比較。規制業種（ヘルスケア・プライム上場）での全社AIエージェント基盤設計を念頭に置いた調査 関連: cloudflare_os_アーキテクチャ_整理（Cloudflare OS の5観点詳細）ai_agent_identity_標準化2026 llm_agent_sandbox_隔離技術 ai_agent_9社_本番運用アーキテクチャ 社内mcp共通基盤_認証認可ログ_整理 法務経理ai_改善ループとガードレール_事例込み資料 エアークローゼット_agentic_graph_rag_と社内mcp基盤_整理 layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理（日本の実装知見・LiteLLM 予算ゲート）意味層_enforced_cube_dbt_looker_整理 意味層_vs_text_to_sql_2026ベンチマーク_dbt_整理 業務のAI化データ基盤 手を動かした写経: ~/ai-engineering-study/lectures/cloudflare_os_basics/（Cloudflare OS の Gatekeeper 承認ゲートを TypeScript で最小再現・ex01〜ex08）

一次情報（GitHub README/SECURITY.md、公式エンジニアリングブログ、脅威モデル文書、学術論文）に基づくアーキテクチャ比較 — エンジニア/アーキテクト向け

エグゼクティブサマリ

規制業種（ヘルスケア・プライム上場）で全社AIエージェント基盤を設計するなら、最重要の設計判断は「資格情報をエージェントに渡すか、分離するか」であり、結論として資格情報分離型（Cloudflare OS の Gatekeeper、Anthropic Managed Agents の brain/hands 分離、Executor.sh のホスト側注入）を中核に据えるべきである。 次いで重要なのが「取得後のデータ伝播をどこまで制御するか（information flow control）」で、ここは Cloudflare OS の参照履歴ベースの伝播制御が現時点で最も先進的な実装事例である。

公開情報を横断すると、設計思想は5類型に分類できる。

  1. 資格情報分離型（Gatekeeper / capability 型） — Cloudflare OS、Anthropic Managed Agents、Executor.sh。資格情報をエージェント（およびモデルコンテキスト・サンドボックスヒープ）から完全に分離し、ゲートウェイ／プロキシが OAuth と実際の API コールを保持・仲介する。エージェントには型付きの「ケーパビリティ（能力）」のみを渡す。規制業種にとって最も参考になる中核パターン。
  2. materialize＋監査型 — YC QM（Quartermaster）、Shopify River/Aquifer（credentials proxy は分離だがサンドボックス内で使用中は平文）。エージェントは「その人として振る舞い」、資格情報をサンドボックスに materialize（実体化）して使用中は平文で存在するが、全操作を監査ログに残す。ローカルコーディングエージェント（OpenCode/Codex/Claude Code）の延長線上。
  3. メモリ層のみ型 — GBrain（Garry Tan）、Agno Scout。source of truth としての知識層／Company Brain を提供するが、認可は実質存在しない（GBrain）か、ランタイム側の JWT RBAC に委ねる（Scout/AgentOS）。
  4. ローカル個人型 — Block Goose、OpenClaw、Hermes Agent、Claude Cowork。個人のマシン／VM で動作し、ツール承認モードとサンドボックス（VM/コンテナ）で封じ込める。企業展開にはガバナンス層の追加が前提。
  5. エンタープライズ ID・ゲートウェイ専業型 — Microsoft Entra Agent ID / Agent 365、MCP ゲートウェイ群、OpenAI ChatGPT Enterprise/Workspace Agents。エージェントにファーストクラスのアイデンティティを付与し、既存 IdP・ガバナンスの延長で統制する。

materialize 型（QM）は透明性が高く監査に強い反面、SECURITY.md が自認するとおり「使用中の資格情報は平文」であり、規制データ（PHI 等）を扱うサンドボックスには構造的に不向きである。

類型の関係図

分類の分岐は「資格情報をエージェントに渡すか」から始まる。

flowchart TB
    Q1{"資格情報を<br>エージェントに渡すか"}
    Q1 -->|"渡さない<br>ゲートウェイが保持"| T1["① 資格情報分離型<br>Cloudflare OS<br>Anthropic Managed Agents<br>Executor.sh"]
    Q1 -->|"渡す<br>監査で担保"| Q2{"実行主体は"}
    Q1 -->|"そもそも外部接続を<br>担当しない"| Q3{"役割は"}

    Q2 -->|"組織スコープ"| T2["② materialize＋監査型<br>YC QM<br>Shopify Aquifer/River"]
    Q2 -->|"個人マシン"| T4["④ ローカル個人型<br>Goose / OpenClaw<br>Hermes / Cowork"]

    Q3 -->|"知識層"| T3["③ メモリ層のみ型<br>GBrain / Agno Scout"]
    Q3 -->|"ID・統制層"| T5["⑤ エンタープライズID型<br>Entra Agent ID<br>OpenAI Workspace Agents"]

    style T1 fill:#a9dfbf
    style T2 fill:#f9e79f
    style T4 fill:#f5b7b1

プロジェクト横断比較表

プロジェクト 主体/ライセンス 認証(authn) 認可(authz)モデル 資格情報の扱い データ伝播制御 データゲートウェイ モデルゲートウェイ 実行分離 監査/HITL
Cloudflare OS Cloudflare / Apache 2.0 Cloudflare Access (ZTNA) capability型（ゼロ権限開始、型付きbinding） 完全分離（Gatekeeperが保持） あり（参照履歴/taint伝播） Gatekeeper Worker（フィールドマスキング・レート制限・承認） AI Gateway（コスト帰属・予算） V8 isolate（Dynamic Workers）+ Durable Object Facets あり／Gatekeeperで承認
YC QM Y Combinator / MIT 内部認証ユーザー1組織、署名ingress principal+scope、keychain grant（owner/audience/expiry/revocation、purpose非強制） サンドボックスにmaterialize（使用中平文） Auto postureで来歴ラベル付きデータをclassifier screening egressプロキシ（条件付き） ModelGateway（一部経路がbypass） Fly/AWS上のper-scope durable sandbox 全操作監査／3 posture (Strict/Auto/Dangerous)
Shopify Aquifer/River Shopify / 非公開（内部） 社内IdP、Slackネイティブ brain/hands分離、credentials proxy proxy経由（sandbox外） ゲートウェイで制御 Aquiferのgateway + credentials proxy 集中LLMプロキシ session cell（ephemeral process）+ 使い捨てsandbox 監査（durable event log）／公開デフォルト
Anthropic Managed Agents Anthropic / 商用 Claude Platform brain/hands/session分離 構造的分離（sandboxに到達しない、session-scoped token） proxyで検査 MCP proxy（session-scoped token） Claude Platform gVisor / VM / sandbox あり／auto mode classifier
GBrain Garry Tan / OSS なし（個人ローカル） 実質なし N/A なし なし なし ローカル（PGLite/Postgres） なし
Agno Scout/AgentOS Agno / Apache 2.0 AgentOS JWT JWT RBAC（scope: resource🆔action）、self-hosted .env/DB（read/write sub-agent分離） なし（provider単位のツール分離） ContextProvider（read/write分離、SQL書込ガード） 任意（BYO） コンテナ（Docker/クラウド） trace／human approval
Block Goose Block→Linux Foundation AAIF / Apache 2.0 ローカル（BYOK） ツール承認モード ローカル（環境変数） なし MCP経由 30+プロバイダBYOK ローカルマシン ツール承認／SOC2等なし
Executor.sh Rhys Sullivan / MIT ローカル/クラウド、per-connection auth per-tool policy（allowed/approval/blocked） ホスト側注入、sandbox heapに入らない なし 統合ゲートウェイ（MCP/OpenAPI/GraphQL統一） N/A（ツール側） QuickJS/Deno/dynamic worker isolate 全run監査／approval
MS Entra Agent ID / Agent 365 Microsoft / 商用 Entra Agent ID（agentごとの一意ID） Conditional Access、least-privilege、access package 外部（downstream OAuth/APIキーはスコープ外） N/A Secure Web/AI Gateway N/A N/A（統制レイヤ） Purview/Defender for Agents／access review
OpenClaw / Hermes OSS（Pi SDK系 / Nous Research）/ MIT ローカル ツール承認、コンテナ分離 ローカル なし 25+チャネルgateway / MCP BYO Dockerサンドボックス / namespace分離 コマンド承認

各プロジェクト詳細

1. Cloudflare OS

5観点（認証／認可／ゲートウェイ／実行分離／監査）の詳細・構成図は cloudflare_os_アーキテクチャ_整理 に分離。

概要：Cloudflare が社内向けに開発し、2026年8月に Apache 2.0 で OSS 化した「AI operating system for companies」。公式ブログ「Cloudflare OS: an open platform for agents, apps, and work」の逐語によれば「In May of this year, we gave every person at Cloudflare access to the first version of Cloudflare OS. Thousands of people across every function, many of them outside of engineering, use it every day」。姉妹ブログ（how-we-use-ai-with-cloudflare-os、CIO 執筆）は直近30日で「users have created over 4,000 apps and tools」、営業チームが「more than 10,000 hours」を節約したと明記。os.cloudflare.app で公開、GitHub は cloudflare/cloudflare-os（core）と cloudflare-os-starter（deployment 例）の2リポジトリ構成。実装パートナーは Presidio、Happy Cog。

認証：Cloudflare Access（ZTNA）が「誰が Cloudflare OS に入れるか」を制御。組織は自前の Access ポリシーを構成。

認可：capability 型。ブログの逐語表現で「Inside, every agent and app starts with access to nothing」（ゼロ権限開始）。エージェントは特定リソースへのアクセスを要求し、付与されると生成コードは型付き binding（env.PROJECT）として受け取る。「The credential remains completely isolated from the agent and any generated code」——資格情報はエージェントと生成コードから完全に分離される。

ゲートウェイ：Gatekeeper はサービス固有の Worker で、Cloudflare OS と外部サービスの間に位置。単一リポジトリへのアクセス制限、issue は読めるがソースは読めない、特定フィールドのマスキング、レート制限、PR マージ前の承認要求などが可能。Gatekeeper が OAuth を処理し資格情報を保持、ポリシーを強制、読み取り内容を記録。既存 MCP サーバーは MCP Server Portal 経由でサポート。

データ伝播制御（最重要の差別化点）：「Cloudflare OS records every resource agents observe」——エージェントが観測した全リソースを記録し、観測記録はエージェントとその成果物に付随する。別の人がワークスペースを開いたり成果物を見ようとすると、Gatekeeper がその人の観測済みリソースへのアクセス権を検証する。同じ観測ログが、エージェントの外部リクエスト可否のポリシーにも使われ、機密データを読むとそのエージェントの書き込み・新規コラボレーター招待・他エージェントへの引き継ぎ・外部リクエストを禁止できる。これは taint tracking 的な情報フロー制御の実装である。

モデルゲートウェイ：全推論コールは Cloudflare AI Gateway 経由。どのモデルを使えるか一元管理、各リクエストを人・チーム・ワークスペースに帰属、予算・レート制限を設定。付随機能「AI Spend」の異常検知は、CIO 誌が引用する Cloudflare PM（Ming Lu, Kenny Johnson, Ayush Kumar）のブログによれば「compares them against account history using a 95th percentile session cost over the previous 30 days」であり、アカウントの95パーセンタイルの2倍を超えると異常候補と判定する。

実行分離：サーバーコードはグローバルアウトバウンドネットワークを無効化した Dynamic Worker で実行。クライアントコードはブラウザのサンドボックス化フレームで実行。アプリは Dynamic Worker（軽量 V8 isolate）としてオンデマンドロード、Durable Object Facet としてインスタンス化（各アプリ独自の SQLite DB）。ブラウザ⇔サーバー通信は Cap'n Web（object-capability RPC）。

既知の限界：本ブログは脅威モデルの明示的限界列挙は少ないが、第1版で「MCP はどのツールを呼べるかは分かるが、エージェントがどの基礎リソースを観測したかは分からない」という課題を認識し、第2版で情報フロー制御を追加した経緯を記載。

2. YC QM（Quartermaster）

概要：Y Combinator が社内で経理・法務・イベント・エンジニアリングに使う「multiplayer agent harness」を2026年7月29日に MIT（一部）で OSS 化。3世代の進化（Ruby ループ→50+ Hermes エージェント運用→QM）。各従業員・各ルーム（Slack チャンネル/プロジェクト）に独立スコープ（memory/files/keychain/permissions/crons/apps/durable sandbox）を付与し、中央 core が identity/policy/audit/scheduler を担う。Postgres 永続化、harness は Pi/OpenCode/Codex/Claude Code を差し替え可能。Fly.io または AWS に org 所有デプロイ。

認証：SECURITY.md の逐語で「QM's interactive agent surfaces currently assume one organization of authenticated internal users」「QM is not a hardened public or multi-tenant service boundary」。署名 ingress と capability トークン。公開アプリの capability リンクは bearer 認可（限界#10「Published-app capability links are bearer authorization」——リンク保持者が到達可、QM プリンシパルは作らず、コピーされたリンクは失効不能）。

認可：ターンごとに principal と scope を解決。keychain grant は owner/audience/once-or-standing mode/expiry/revocation/audit を強制。重要な限界#4「Credential purposes are not enforced authorization」——purpose（用途）はモデルへの指示と監査フィールドとして資格情報に付随するが、後続コマンドがその用途内に留まるかを core は判定しない。「Once a credential is materialized into a sandbox, the purpose text does not confine how a compromised agent process can use it」。

資格情報の扱い（materialize 型の核心）：SECURITY.md 限界#3「Sandbox credentials are plaintext while in use」——環境変数やファイルとして materialize された資格情報・capability トークンはそのサンドボックス内プロセスから読める。「those controls do not stop a compromised agent process from spending or exfiltrating usable credentials」。脅威モデルでも「Encryption at rest protects stored secret material from direct storage reads, not plaintext credentials while a process is using them」。

セキュリティ posture（README 逐語）：組織が1つの posture を選び、狭いスコープは締める方向にのみ変更可。Strict（全 harness ツールコールが人間承認で一時停止、no-effect の2つの turn ender 除く）／Auto（デフォルト、classifier が来歴ラベル付き外部データ・ツール結果をモデル到達前に screening）／Dangerous（screening もツールコール間の一時停止もなし）。事前宣言コマンドポリシー（再帰削除・破壊的 SQL 等の承認ルール・ハード拒否）は全 posture（Dangerous 含む）で適用。ただし限界#1「Command policy is bypassable」——難読化・エンコード・スクリプト書込後実行で回避可能。「a speed bump against mistakes and injection, not a sandbox boundary」。限界#5「Security screening is incomplete and heuristic … Classifier approval is not authorization and cannot guarantee prompt-injection resistance」。

ゲートウェイ／egress：限界#7「Egress enforcement is conditional」——force-through egress はバックエンドのネットワーク強制に依存、デプロイランタイム egress 強制は未実装。限界#12——ambient Slack judge のモデルコールは ModelGateway を未経由、OpenCode アダプタはプロバイダキーを sidecar に供給。

監査・ガバナンス：限界#8「Admins can read sensitive content」——スコープ認可された管理者はトランスクリプト・キャプチャされたプロバイダリクエスト・ドキュメント・メモリ・keychain メタデータ等を直接読める。「The read is audited, not separately consent-gated」。運用前提でも「An org admin is a privileged content reader, not only a policy administrator … require no additional user approval」と明記。限界#13——standing-instruction 編集が org floor/人間承認で一律に制約されない、ガバナンス変更が一律にバージョン管理・revert 可能でない、プロバイダ側トークン失効・org kill switch が不完全、書込時 secret scanning 未実装。限界#9「Durable data can outlive user expectations」——request capture がデフォルト ON、file artifact に expiry なし。

3. Shopify Aquifer / River

概要：Shopify の社内 AI エージェント基盤。Shopify Engineering「Under the River」（2026年5月28日）が一次ソース。River は社内 Slack に常駐するエージェントで、直近30日で 59,918 セッション・5,170 チャンネル・7,000人超が利用、3,536件の River 共著 PR がマージ。「1 in 8」（8分の1）のマージ PR が River 共著。Aquifer がその下の基盤（session/harness/sandbox/gateway/durable event log/credentials proxy/observability pipeline）で、River はその上の1プロファイル。非公開の内部システムだがブログで設計を公開。

設計思想：「Decouple the brain from the hands」（Anthropic の2026年4月記事を引用）。harness（エージェントループ、モデル呼出）は sandbox の外に置く。3つの性質——安全性（エージェントループが rm -rf と同じ blast radius にない）、置換可能性（モデル/ランタイム/言語を sandbox 側に触れず交換）、可観測性（意思決定ストリーム全体が harness 側で一箇所可視）。

セッション永続化：「the session is the thing that must survive」。session cell（ホスト上の ephemeral プロセス、Go ランタイム＋harness）を実体化、アイドルで終了、次回は別ホストで新規 cell だが session アイデンティティは不変（作業は Postgres に存在）。cattle-not-pets。

認証・資格情報・モデルゲートウェイ：credentials proxy が sandbox 外で資格情報を仲介（brain/hands 分離の帰結）。集中 LLM プロキシは、Bessemer Venture Partners インタビューで VP・Head of Engineering の Farhan Thawar が説明する「centralized LLM proxy — an internal gateway that routes every AI request through one platform layer」であり、トークンのバルク購入とチーム/個人単位の使用分析を可能にする。

監査・ガバナンス：River は「公開デフォルト」で動作（DM なし、全会話が社内公開 Slack トランスクリプト）。durable event log（append-only、Postgres-backed）。

4. Anthropic Managed Agents / Claude containment

概要：Anthropic のホスト型長時間エージェントサービス（2026年4月公開）と Claude 製品群（claude.ai/Claude Code/Cowork）の封じ込めアーキテクチャ。エンジニアリングブログ「Scaling Managed Agents」「How we contain Claude across products」（2026年5月25日）で詳細公開。

brain/hands/session 分離：Session（durable append-only log、context window 外）／Harness（エージェントループ、使い捨て）／Sandbox（コード実行、使い捨て）。資格情報は sandbox に到達しない設計原則——Git トークンは init 時にローカル remote に配線されエージェントは触れない、MCP ツールは session-scoped トークンの dedicated proxy 経由、OAuth トークンは vault 保管。

封じ込め3パターン（How we contain Claude より）： - claude.ai：gVisor コンテナ、完全サーバーサイド、ephemeral ファイルシステム。 - Claude Code：ユーザーマシン上の HITL サンドボックス（macOS Seatbelt/Linux bubblewrap）、ネットワークはデフォルト拒否。公式逐語で「Our telemetry showed users approved roughly 93% of permission prompts」（承認疲れ）を自認し、OS レベルサンドボックス導入で「an 84% reduction in permission prompts」を達成、ランタイムを OSS 化。auto mode は「blocks ~0.4% of benign commands while missing ~17% of risky ones」とも自認。 - Cowork：ローカル VM（Apple Virtualization Framework/Windows HCS）。資格情報はホストの keychain に留まりゲストに入らない、VM には per-session スコープダウントークン。

脅威モデル上の自認された失敗： - 信頼ダイアログ前のコード実行：.claude/settings.json の hook が「Do you trust this folder?」プロンプト前に実行される脆弱性。修正はプロジェクトローカル設定の parse/実行を trust prompt 受諾後に遅延。 - ユーザーが注入ベクトル：フィッシングで Claude Code に悪意プロンプトを実行させ、~/.aws/credentials をエンコードして外部 POST。「Across 25 retries of that prompt, Claude completed the exfiltration 24 times」。「唯一有効な防御は環境層、すなわち egress 制御とファイルシステム境界」。 - 承認ドメイン経由の流出：Cowork の egress allowlist が api.anthropic.com を正しく通過させたが、攻撃者の API キーで攻撃者アカウントにファイルアップロード。allowlist を「destination filter」でなく「capability grant」として再概念化すべきと学習、VM 内 MITM proxy で修正。 - VM 分離が EDR も締め出す：可視性低下、pull-based OTLP export で緩和。

将来課題：永続メモリのポイズニング、multi-agent trust escalation、エージェントアイデンティティ（自身の principal か、ユーザーの拡張か）。

5. GBrain（Garry Tan）

概要：YC 社長 Garry Tan が2026年4月に OSS 化した個人向けメモリ層。Git 上の Markdown ファイルを source of truth とし、Postgres+pgvector でハイブリッド検索（vector+BM25+RRF）。自己配線ナレッジグラフ、夜間の「dream cycle」でエンティティページを充実・引用修正。30+（新版で74）の MCP ツールを Claude Code/Cursor/Windsurf 等に公開。OpenClaw/Hermes と統合。1週間で1万 Markdown ファイル・3千人物ページ・13年分カレンダーをインデックス。

認可：実質なし。「One user with one brain — solved. Many users with shared brains — not solved」——マルチテナンシー・アクセス制御・書込競合解決・チーム間コンセンサスは公開リポジトリで未対応。全社基盤としてはメモリ層のパターン（Company Brain の「知識の複利」思想）としてのみ参考で、認可・分離は自前実装が前提。

6. Agno Scout / AgentOS

概要：Agno の OSS「Open Source Company Brain」。単一の agno.Agent に複数の ContextProvider（Web/Workspace/Database=CRM/Wiki/Slack/GDrive/MCP）を接続。AgentOS（stateless FastAPI ランタイム、Apache 2.0）上で動作。navigation over search 思想（DatabaseContextProvider は query_crm/update_crm を別々の sub-agent に分離）。

認証・認可：本番は JWT RBAC 必須（RUNTIME_ENV=prd で有効化、JWT_VERIFICATION_KEY なしではトラフィックを拒否）。scope 文字列は resource:[id]:action 形式。service account（agno_pat_...）、multi-user/multi-tenant isolation。Agno 制御プレーン（os.agno.com）が JWT 発行・セッション管理・trace、Scout は検証のみ。データはユーザー所有 DB に留まる。商用は $150/月 Pro（1本番 AgentOS 接続）＋Enterprise（SSO/RBAC カスタム）。

データ伝播制御：明示的な IFC はなし。ただし DatabaseContextProvider の read/write sub-agent 分離、SQL engine の「public/ai スキーマへの書込を拒否するガード」あり。

7. Block Goose

概要：Block（Square/Cash App 親会社）が作り Rust で実装したローカルファーストの OSS エージェント。2025年12月に Linux Foundation の Agentic AI Foundation（AAIF）へ寄贈（MCP、OpenAI の AGENTS.md と共に創設プロジェクト。プラチナメンバーに AWS/Anthropic/Bloomberg/Cloudflare/Google/Microsoft/OpenAI）。Apache 2.0。ローカルマシンで CLI/デスクトップ/API、70+ MCP 拡張、30+ LLM プロバイダ BYOK。リポジトリは block/goose→aaif-goose/goose へリダイレクト。

認可・封じ込め：ツール承認モード、ローカル実行。第三者評価で「No SOC 2, HIPAA, or commercial compliance certifications exist, which is a hard constraint for regulated industries」——規制業種には認証欠如が制約。個人開発者・社内ツール構築の基盤として。

8. Executor.sh

概要：Rhys Sullivan（元 Vercel/Microsoft）が YC で2026年に創業した OSS「integration management layer for AI」＝MCP ゲートウェイ。MIT。MCP/OpenAPI/GraphQL を統一ツール形状（name/input schema/output schema）に正規化。ローカル/自己ホスト/Cloudflare Worker/クラウド。1つのカタログを全 MCP 互換エージェント（Claude Code/Codex/Cursor）で共有。

認可・資格情報：per-tool policy（always allowed/needs approval/blocked）、import したセマンティクスを保持（OpenAPI の GET vs DELETE、MCP の destructiveHint）。「Secrets are injected host-side at call time and never enter the sandbox heap, so the agent and model never see a raw token」——資格情報分離型。ツールコールは隔離 JavaScript サンドボックス（QuickJS/Deno subprocess/dynamic worker）で実行。全 run/ツールコール監査。コンテキスト効率化（公称：1,640 ツール≒278,800 トークン→1 ツール≒1,044 トークン）。

9. Microsoft Entra Agent ID / Agent 365

概要：Microsoft のエンタープライズエージェント統制。Entra Agent ID が各 AI エージェントに一意のエンタープライズアイデンティティを付与、Agent 365 が発見・インベントリ・統制の統合コントロールプレーン。Microsoft 365 E7 に含まれる／E5 等へのアドオン。

認可・ガバナンス：Conditional Access、least-privilege、identity governance（agent lifecycle workflow、access package、sponsor/owner、access review）、Privileged Identity Management（just-in-time）。Purview for Agents / Defender for Agents。ただし第三者（Oasis Security）の指摘：「Agent 365 governs who the agent is and how it signs in. What the agent carries and uses to actually do its work, the downstream OAuth grants, API keys, MCP tokens, connector credentials, and vault secrets, is still outside scope」——アイデンティティ層は解決するが downstream 資格情報・アクセスガバナンスは範囲外。

10. OpenClaw / Hermes Agent / Pi

概要：OSS エージェントハーネスのエコシステム。Pi（最小ターミナルコーディングハーネス、SDK）、OpenClaw（Pi SDK を埋込み25+メッセージングチャネル＋音声を追加）、Hermes Agent（Nous Research、独自ランタイム、自己改善スキルループ、200+モデル）。いずれも MIT。Microsoft Build で OpenClaw 上に Scout（常時稼働エンタープライズエージェント）が Windows 実行コンテナ内で稼働するデモ。

封じ込め：OpenClaw——サンドボックス実行、コマンド承認、Docker サンドボックス境界、Browser CDP エンドポイント検証。Hermes——コンテナハードニング（read-only root、dropped capabilities）、namespace 分離、環境変数の資格情報。第三者評価では「Hermes has zero reported agent-specific CVEs as of April 2026」。個人・SMB 向けで、企業展開には別途ガバナンス層が必要。

参考：OpenAI ChatGPT Enterprise / Workspace Agents

OpenAI は ChatGPT Enterprise 基盤上に Workspace Agents（RBAC でツールアクセス・許可アクション・Compliance API 経由監視）を提供。Enterprise ワークスペースではデフォルト OFF、admin が role-based で有効化。Enterprise Key Management（EKM）利用顧客は非対応。SCIM でディレクトリ同期。materialize/分離の技術詳細は非公開だが、既存 IdP・コンプライアンス統制の延長という点で類型5に属する。

認可の理論的枠組み（学術・業界動向）

  • Capability-based security / CaMeL：Google DeepMind の CaMeL（Capabilities for Machine Learning）は Simon Willison の Dual LLM パターンを拡張。Privileged LLM（ツール呼出可）と Quarantined LLM（ツール呼出不可）を分離し、custom interpreter で capability メタデータとデータフローポリシーを強制。原論文（arXiv:2503.18813）によれば AgentDojo で「solving 77% of tasks with provable security (compared to 84% with an undefended system)」。コストは全防御中最高で「requiring 2.82x more input tokens and 2.73× more output tokens than the baseline for the median task」、加えてユーザーがポリシーを明文化・維持する負担がある。Cloudflare OS の capability 型 binding はこの系譜。
  • Information Flow Control / taint tracking：Microsoft の FIDES（confidentiality/integrity ラベル、dynamic taint-tracking、selective hiding）、APPA（engine-managed context branching）、SafeFlow（multi-agent semantic IFC）等の研究が活発。Cloudflare OS の「参照履歴ベースの伝播制御」は実装事例。ただし NeuroTaint 論文が指摘するとおり、LLM の taint 伝播は「明示的な内容転送だけでなく意味的変換・因果的影響・セッション跨ぎ永続化」を含み、従来の taint 解析が根本的に通用しない難しさがある。
  • OAuth 2.1 / MCP authorization：MCP authorization 仕様は OAuth 2.1+PKCE ベース。ただし Solo.io 等が指摘するエンタープライズギャップ（ゲートウェイトークン伝播標準なし、マルチテナントパターンなし、SSO 統合パスなし、AS ディスカバリの断片化）。emergent なパターンは MCP ゲートウェイ（各 hop で狭い downstream トークンを再発行し confused deputy 問題に対処、RFC 8707 audience binding）。実装成熟度は低く、arXiv:2605.22333「A First Measurement Study on Authentication Security in Real-World Remote MCP Servers」（2026年5月）が検証済み7,973台の稼働リモート MCP サーバーを調査した結果、「40.55% (3,233) exposed tools with no authentication mechanism at all, 30.45% (2,428) used OAuth, and 29.00% (2,312) used static tokens or API keys」で、テスト可能な119台の OAuth サーバーのうち動的クライアント登録（DCR）の欠陥が96.6%に影響していた。
  • エージェントアイデンティティ（Workload Identity 的アプローチ）：Microsoft Entra Agent ID が最も進んだ商用実装。Anthropic も「エージェントが自身の principal を持つべきか、ユーザーの拡張として権限を継承すべきか」を未解決課題として提起（「the answer may be a blend of the two」）。NIST の「Software and AI Agent Identity and Authorization」プロジェクトが標準化を進行。

日本企業の公開事例

  • LayerX：プライム上場ではないがバクラク（経理）等で AI エージェントを積極展開。「AI Agent ブログリレー」で技術知見を55日連続公開。Temporal（Durable Execution 対応 Workflow Engine）を AI エージェント基盤として活用（ユーザー操作の待ち受け等、従来インフラでは対応困難な部分）。Azure 内で閉じる構成（Claude Agent SDK を subprocess で動かす + Microsoft Foundry Hosted Agent）でサンドボックスを検討する記事など、規制近接業種（フィンテック）の実装知見が豊富。データ検索基盤チーム、バックテスト基盤、Langfuse での評価管理など。依頼者（ヘルスケアテック・コーポレート部門への AI 展開）に最も直接応用可能な日本語一次情報源。
  • サイバーエージェント：独自日本語 LLM 開発、社内向け生成 AI ツール「Harmonica」（OpenAI/Gemini/Azure 等17モデル利用可）を社内開発。CIU（プライベートクラウド、NVIDIA H100 専有）で LLM 演算基盤を運用。全社リスキリングプログラム。ただし認証・認可・ゲートウェイの設計詳細は限定的。
  • メルカリ/リクルート：本調査の一次情報探索範囲では、認証・認可・ゲートウェイに踏み込んだ社内 AI エージェント基盤の技術公開は確認できなかった（人材育成・個別プロダクト事例が中心）。

規制業種（ヘルスケア・上場企業）で全社 AI 基盤を設計する場合の含意

借用すべきパターン

  1. 資格情報のエージェントからの完全分離（最優先）：Cloudflare OS の Gatekeeper、Anthropic Managed Agents の brain/hands 分離、Executor.sh のホスト側注入。規制データ（PHI 等）を扱う場合、資格情報がモデルコンテキストやサンドボックスヒープに入らない設計を必須要件とする。QM の materialize 型（使用中平文）はこの基準を満たさない。
  2. ゼロ権限開始＋型付きケーパビリティ：Cloudflare OS の「every agent starts with access to nothing」＋型付き binding。dbt Semantic Layer + BigQuery に対しては、Gatekeeper がフィールドマスキングとカラム/行レベルのポリシーを Semantic Layer 上で強制する構成が理想。
  3. 参照履歴ベースの情報フロー制御：Cloudflare OS の観測ログによる伝播制御。ヘルスケアでは「誰がどの PHI を観測したか」を成果物に付随させ、共有時に受け手のアクセス権を再検証する仕組みが、意図せぬ PHI 再共有を防ぐ。
  4. brain/hands/session の3層分離：Anthropic/Shopify の共通パターン。監査（session の append-only log）・置換可能性・blast radius 限定を同時に満たす。上場企業の SOX 的な監査証跡要件にも適合。
  5. モデルゲートウェイによるコスト帰属・予算統制・異常検知：Cloudflare AI Gateway、Shopify/Ramp の集中 LLM プロキシ。人・チーム単位の帰属、予算・レート制限、異常検知（Cloudflare「AI Spend」は過去30日の95パーセンタイルの2倍を異常候補と判定）。
  6. posture によるガバナンス：QM の Strict/Auto/Dangerous のような組織レベル posture（狭いスコープは締める方向にのみ変更可）。法務・人事・経理といったコーポレート部門ごとに posture を差別化。
  7. エージェントへのファーストクラス ID 付与：Microsoft Entra Agent ID 的アプローチ。既存 IdP・access review・lifecycle workflow の延長でエージェントを人と同様に統制。上場企業のアクセス統制監査に不可欠。ただし「ID 付与」と「downstream 資格情報ガバナンス」は別問題であり、後者は資格情報分離型で別途手当てする。
  8. egress を「capability grant」として設計：Anthropic の教訓——allowlist は「destination filter」でなく「capability grant」。承認ドメイン経由の流出（confused deputy）を防ぐため、承認ドメイン上の全機能を攻撃面として評価。

避けるべき落とし穴

  1. 資格情報のサンドボックスへの materialize：QM が自認するとおり「使用中は平文」で、侵害されたエージェントプロセスによる流出を止められない。規制データには不適。
  2. 承認疲れ（approval fatigue）への依存：Anthropic の「93% を承認」「84% 削減してようやく機能」の教訓。HITL のみを主防御にしない。環境層（サンドボックス・egress 制御）を第一防御とし、モデル層・承認は多層防御の一部と位置づける。
  3. 管理者の無制限コンテンツ閲覧：QM の限界#8「admins can read sensitive content」（監査されるが個別同意ゲートなし）。ヘルスケアでは管理者の PHI 閲覧に別途同意ゲート・最小権限・職掌分離が必要。
  4. メモリ層のみで認可を欠く構成：GBrain の「shared brains — not solved」。Company Brain（知識の複利）の思想は借用しつつ、マルチテナンシー・アクセス制御・書込競合解決を必ず自前実装。
  5. コンプライアンス認証を欠くローカル個人型の全社転用：Goose 等は「No SOC 2, HIPAA」。個人生産性ツールと規制対応全社基盤を混同しない。
  6. 単一ベンダーへのロックイン vs 自組織運用能力：Cloudflare OS は設計は最先端だが自組織の Cloudflare 依存を伴う。QM/Agno/Executor は自己ホスト可だが「platform engineer が最低1人」必要な運用負荷。FDE 的デプロイの人的リソースと天秤にかける。
  7. プロンプトインジェクションの過小評価：CaMeL/FIDES 等の IFC でも完全ではなく（NeuroTaint の指摘する LLM 特有の taint 伝播の困難、CaMeL でも provable security は77%）、classifier 承認は認可でない（QM の自認）。決定論的な環境層境界を最後の砦とする。
  8. 可観測性と VM 分離のトレードオフ：Anthropic の「VM 分離が EDR を締め出す」教訓。規制業種のエンドポイント可視性要件と封じ込めの両立を設計初期に検討（pull-based OTLP export 等）。

段階的推奨アクション

flowchart LR
    P1["フェーズ1: PoC<br>1部門・1可逆ワークフロー<br>資格情報分離型を検証"]
    P2["フェーズ2: 基盤化<br>brain/hands/session 分離<br>Semantic Layer 前に Gatekeeper"]
    P3["フェーズ3: 全社展開<br>部門別posture<br>モデルGW / 情報フロー制御<br>監査証跡をSIEMへ"]
    P1 --> P2 --> P3
  • フェーズ1（PoC）：法務・人事・経理のうち1部門・1可逆ワークフローで、資格情報分離型（Cloudflare OS starter または Executor.sh + Agno AgentOS）を検証。受入タスク完了率・レビュー工数・コスト・クロススコープインシデントを計測。
  • フェーズ2（基盤化）：brain/hands/session 分離を採用し、dbt Semantic Layer + BigQuery へのアクセスは Gatekeeper/ContextProvider 経由でフィールドマスキング・行レベルポリシーを強制。Entra Agent ID 的なエージェント ID を既存 IdP に統合。
  • フェーズ3（全社展開）：部門別 posture、モデルゲートウェイによるコスト統制、参照履歴ベースの情報フロー制御を本番化。監査証跡を SIEM へ。 判断を変える閾値（トリガー）
トリガー アクション
クロススコープの PHI 漏洩が1件でも発生 posture を Strict へ／materialize 型を即排除
承認率が90%超（承認疲れの兆候） 環境層（egress・サンドボックス）を強化し HITL 依存を下げる
モデルゲートウェイ未経由の推論経路を発見 即時遮断
エージェント数が platform engineer の運用キャパを超過 マネージド型（Cloudflare OS 管理版・Anthropic Managed Agents）への移行を再評価

出典（一次情報優先）

  • Cloudflare OS：blog.cloudflare.com/cloudflare-os、github.com/cloudflare/cloudflare-os、cloudflare-os-starter、CIO/Computerworld（AI Spend 詳細）
  • YC QM：github.com/yc-software/qm（README・SECURITY.md 全文）、qm.ycombinator.com
  • Shopify：shopify.engineering/under-the-river、shopify.engineering/quick、Bessemer インタビュー（LLM プロキシ）
  • Anthropic：anthropic.com/engineering/how-we-contain-claude、Scaling Managed Agents、anthropic.com/news/finance-agents
  • GBrain：github.com/garrytan/gbrain
  • Agno：github.com/agno-agi/scout（AGENTS.md）、docs.agno.com、deepwiki（AgentOS auth）
  • Goose：linuxfoundation.org（AAIF 発表）、goose-docs.ai
  • Executor：github.com/rhyssullivan/executor、executor.sh/docs、ycombinator.com/companies/executor
  • Microsoft：learn.microsoft.com（Entra Agent ID / Agent 365）、oasis.security（第三者分析）
  • OpenAI：openai.com（Workspace Agents、ChatGPT Enterprise、Compliance）
  • OpenClaw/Hermes：github.com/nousresearch/hermes-agent、thenewstack.io
  • 理論：arXiv:2503.18813（CaMeL）、2505.23643（FIDES）、2607.24625（APPA）、2604.23374（NeuroTaint）、2605.22333（MCP auth 実測）、solo.io、gitguardian
  • 日本：tech.layerx.co.jp、developers.cyberagent.co.jp

作成: 2026-08-19 ／ 最終更新: 2026-08-19