OpenClaw エディション：Red Hat AI で「Bring Your Own Agent」を運用化

AI エージェントの世界は複雑です。各チームは、LangChain、LlamaIndex、CrewAI、AutoGen を検討したり、独自のカスタムソリューションをゼロから構築したりしています。確かに、開発フェーズではこのような取り組みが見られることでしょう。しかし、エージェントが開発者のノートパソコンから離れ、本番データと通信したり、外部の API を呼び出したり、共有インフラストラクチャで実行したりするようになると、ガードレールのない自由は「特長」から「リスク」へと変わります。

私たちは、業界が変遷を幾度も遂げてきたのを観察してきました。モデル API (チャット補完など)、エージェント型 API (アシスタントや 後の OpenAI 応答 API など)、フレームワークの時代、そして現在はハーネスおよびコーディングエージェントの時代です。最上位のレイヤーは変化し続けており、それは代替可能になりつつあります。絶えまない変化の中で変わらないのは、「ノートパソコンで動作する」状態から「監査証跡を残しつつ、大規模かつ安全に本番環境で稼働できる」状態に到るまでにギャップが存在するという点です。

当社の AgentOps 戦略は、Bring Your Own Agent (BYOA) の基本原則に基づいています。プラットフォームは、特定のフレームワークに依存しません。重要なのは、エージェントに識別情報があり、最小権限の原則に基づいて動作し、監視でき、安全チェックを通過しなければならない設定となっており、事後的な監査が可能であるという点です。このプラットフォームは、セキュリティ、ガバナンス、可観測性、ライフサイクル管理の機能を提供し、エージェントはお客様の管理下に置かれます。

Red Hat AI が提供する機能

このシリーズでは、BYOA が実際にどのように機能するかを示すプレビューを提供し、現在利用可能な機能と今後構築する機能について説明します。

当社では OpenClaw を採用しています。これは、中央の WebSocket Gateway を介してチャネル (WhatsApp、Telegram、Slack、Discord など) 間でのエージェントの対話をルーティングするパーソナル AI アシスタントであり、Red Hat AI 上で運用します。当社はこれをプロプライエタリーなフレームワークに含めるのではなく、プラットフォームのインフラストラクチャに組み入れます。このアプローチはどのエージェントランタイムでも機能し、OpenClaw はその一例に過ぎません。

OpenClaw は、デフォルトではサンドボックス化をほとんど行いません。また、ロールベースのアクセス制御 (RBAC) の実施や、ツール呼び出しのトレース、外部サービスへのアクセスを制限しません。Red Hat AI は、Red Hat OpenShift と Red Hat OpenShift AI のネイティブ機能を使用して、エージェントのコードを修正することなく、これらの各レイヤーを追加します。この記事では、これらの各レイヤーについて説明します。

クラウドネイティブからエージェントネイティブへの転用

エージェントのインフラストラクチャは、ゼロから構築するわけではありません。OpenShiftがすでに備えているツールやデプロイメントパターンを転用し、Red Hat AIでそれらをエージェント型ワークロード用に拡張します。

エージェントには分離が必要： OpenShift Sandboxed Containers (Kata Containers プロジェクト、および GA (一般提供) 段階にあるレイヤー化された製品に基づく) と今後のエージェント・サンドボックス統合により、エージェントのセッションごとにカーネルレベルで分離された実行環境が提供されます。ホストと他のエージェントのデータは、侵害されたエージェントから保護されます。

エージェントには識別情報が必要：スコープ付きのサービスアカウントトークン、および暗号処理ワークロードの識別情報として SPIFFE/SPIRE を使用します。ハードコーディングされたキーはありません。その代わりに、プラットフォームは、エージェントを検証し、有効期間が短く、スコープが限定されたサービスアカウントのトークンをプラットフォームレベルで注入します。これは、Red Hat AI の一部として、エージェントのライフサイクル管理のための Kagenti の統合機能と共に利用可能にすることが予定されています。 

エージェントにはマルチテナンシーが必要：namespace の分離、NetworkPolicy、ResourceQuota、および敵対的なテスト下での境界の有効性の検証が行われます。

エージェントには複数のレイヤーでポリシーの防護機能が必要： Kubernetes レベルの OPA/Gatekeeper および Kyverno ポリシー、ツールレベルの認可用のモデルコンテキストプロトコル (MCP) Gateway、モデル推論の境界における Guardrails Orchestrator と NeMo Guardrail (これについては次のセクションで詳しく説明します) が使用されます。

エージェントの安全性を高め、本番環境への導入準備を整える

多くの企業のチームにとって、安全性がエージェントやモデルの本番環境への移行における主要な障害となりつつあります。パフォーマンスやコストではなく、信頼できるかどうかが課題となります。企業は、AI が規制に準拠した状態を維持し、とくに外部ユーザーが使用する場合は、ブランドの評判や法的リスクから保護できるという確信を得る必要があります。

Red Hat AI は、本番環境への移行前の検知、テスト、リスク軽減を含むライフサイクル全体を網羅する安全対策のポートフォリオを提供し、実行時に発生する脅威からシステムを保護します。

エージェントの稼働前： Garak (Red Hat AI の一部として利用可能になることが予定されている) は、モデルレベルでのジェイルブレイク (Jailbreak)、プロンプトインジェクション、その他の攻撃ベクトルに対する敵対的脆弱性スキャン機能を提供します。統合は TrustyAI Operator を通じて行われ、EvalHub (評価コントロールプレーン)、Kubeflow Pipelines を介して利用可能になる予定です。これにより、プロモーション前に CI/CD の敵対的スキャンを実行できるようになります。

実行時 (推論境界のガードレール)：TrustyAI Guardrails Orchestrator (OpenShift AI 3.0 として一般提供) は、モデルの入出力をスクリーニングします。 NeMo Guardrails (テクノロジープレビュー)はプログラム可能な対話制御機能を追加します。これらはどちらも推論の境界で動作し、個々の大規模言語モデル (LLM) の呼び出しをインターセプトして、応答がエージェントに到達する前に安全性を確保します。モデルカタログに用意されたモデルリスクビューでは、これらの安全性シグナルがモデルのメタデータと共に表示されるため、チームはモデルを選択する前にユースケースのリスクを考慮できます。

可観測性、トレース、および評価

エージェントは確率的です。実行トレースのない状態では、本番環境でそれらをデバッグしたり信頼したりすることはできません。

Red Hat AI は、エージェントの可観測性の基盤を提供します。その第一歩として、現在開発者プレビューの段階にある MLflow に対する公式サポートを開始し、今後のリリースで一般提供を開始する予定です。 

MLflow トレースは、プロンプト、推論ステップ、ツール呼び出し、LLM API リクエスト、およびトークンコストを記録します。すべてのトレースは OpenTelemetry と互換性があるため、OTEL 互換のシンクはいずれも統合できます。トレースだけでなく、スコアリングと評価のために MLflow 機能を使用してエージェントの品質を経時的に評価することができます。これらのワークフローは OpenShift AI の一部である評価コントロールプレーンの Eval Hub を通じて呼び出し、実行できる予定です。  

大規模なツール呼び出しの管理

エージェントはツールを呼び出します。この呼び出しをどのように管理するかは重要なポイントになります。

MCP ゲートウェイ (Envoy ベースの OpenShift ネットワークチームにより構築されたゲートウェイ) は、現在開発者プレビューとして提供されており、すべての MCP サーバーの前に単一のセキュアなエンドポイントとして配置されます。これには、エージェントで認可されたツールのみを表示できるようにする ID ベースのツールフィルタリング機能、バックエンドごとのアクセス範囲を限定するための OAuth2 トークン交換機能、および機密性の高いツール呼び出しが適切な認証を経由するようにする認証情報管理機能が追加されています。プラットフォームでは、アクセス制御が適用されます。アプリケーションが認証情報を管理するため、サーバー間の情報漏洩は発生しません。

認証は、Kuadrant の AuthPolicy を介して実施されます。これは、JSON Web Token (JWT) の検証用の Authorino と Gateway API レベルのルール評価用の Open Policy Agent (OPA) を統合します。

OpenClaw の場合、これはエージェントが 1 つの MCP_URL 環境変数を設定し、集約されたツールカタログにアクセスすることを意味します。どのツールを実際に呼び出すかは、プロンプトではなく、トークンのクレームによって決まります。エージェントを騙して許可されていないツールを呼び出させようとするプロンプトインジェクションは、ゲートウェイがプロンプトの内容を完全に無視するため、インフラストラクチャ層で阻止されます。さらに、トークンのクレームの検証も行われます。

本番環境向けエージェントの API インターフェースの選択

多くのチームがチャットから開始し、チャット補完や OpenAI API に移行し、次にフレームワーク、そして今ではエージェントハーネスへと移行しています。エージェントが使用する API は統合されつつあります。エージェント型ワークロード向けの主要な API の 1 つは Responses API であり、OpenAI は OpenResponses 仕様 を通してこの方向性を開拓しました。

Red Hat AI は、OpenResponses 仕様に完全に準拠した実装を提供します。これにより、チームはすべてのプロンプト、ツールの呼び出し、推論アーティファクトをサードパーティのサービス経由でルーティングするのではなく、セルフホスト型またはハイブリッドモデルのインフラストラクチャでエージェントのワークロードを実行できます。

セルフマネージド環境やハイブリッド環境向けの OpenResponses 互換ランタイムは依然として限られています。Red Hat AI は、このギャップを埋めることに焦点を当てた仕様の中でも最も成熟した実装の 1 つを提供します。これは、OpenAI が制御するインフラストラクチャに実行を移行しながら、OpenAI 応答 API 指向のエージェント動作を維持したい OpenClaw ユーザーにとって、実用的な選択肢となります。

Responses API オーケストレーション層を介さないセルフホスト環境を希望するチーム向けに、Red Hat AI の一部である vLLM は、OpenClaw が直接利用可能な OpenAI 互換の /v1/chat/completions エンドポイントを提供します。

Kagenti を使用したエージェントのライフサイクル管理

多くのチームが、エージェントをラップトップから本番環境へと移行する際に行き詰まりを経験します。 OpenShift AI の一部として予定されている Kagenti は、このギャップを解消します。kagenti-operator　は、A2A ベースの AgentCard CRD を介してエージェントを自動検出し、AgentRuntime コンストラクトを通じて、エージェントのコードを変更することなく、識別情報 (SPIFFE/SPIRE)、トレース、およびツールガバナンス (MCP Gateway) を注入します。検出から実行時のガバナンスに至るまで、ライフサイクル全体がこのプラットフォームによって管理されます。エージェントのカタログとレジストリは、ツールサーバー用の MCP カタログとともに、OpenShift AI UI のロードマップに含まれています。

このブログシリーズについて

このブログシリーズでは、OpenClaw をエージェントランタイムの例として取り上げ、これらのレイヤーについて詳しく説明しています。各記事は独立した内容となっています。順番に読んでいただくことも、現在抱えておられる課題に関連する内容から読み進んでいただくこともできます。

これらのすべての記事に共通しているのは、BYOA の原則です。エージェントの書き換えを求めることは決してありません。エージェントにエンタープライズレベルの厳格さを適用するのはあくまでも当社です。

AI アプリケーションの安全性の構築、評価、実施のための Red Hat AI 製品スタックの詳細については、公式の製品ドキュメント、および Red Hat AI AgentOps の展開において鍵となる以下のアップストリームプロジェクトをご確認ください。

• vLLM
• MCP Gateway
• Open Responses/Llama Stack
• Authorino
• Garak
• TrustyAI Service Operator
• NeMo Guardrails
• Kagenti
• Kagenti Operator