コンテナを使用して AI ワークロードにソフトウェア・エンジニアリングの厳密性をもたらす

AI ワークロードが実験的なプロトタイプから本番環境へと移行するにつれ、企業は常々直面している課題に再び直面しています。それは、従来のソフトウェアアプリケーションと同じ厳格さで、これらの新しいコンポーネントをどのように保護、管理、ガバナンスすべきかということです。この課題を解決する鍵となるのは、おそらく貴社でもすでに広く活用されている「コンテナ」、具体的には Open Container Initiative（OCI）コンテナにあります。

Open Container Initiative とは

Open Container Initiative は、イメージ形式、コンテナランタイム、および配布に関するオープンな仕様を定義し、組織がベンダーロックインを回避できるように支援します。  OCI コンテナは、ソフトウェア・アプリケーションをパッケージ化するための業界標準の形式であるため、さまざまな環境、コンテナエンジン (Docker や Podman など)、およびクラウドプラットフォーム間で一貫して実行できます。

OCI アーティファクトはコンテナに似ていますが、実行可能イメージではなく、ファイルやディレクトリなどの他のコンテンツを保存します。  OCI 互換のアーティファクト・リポジトリ (Quay、 Artifactory、Docker Hub、主要なクラウドプロバイダーのレジストリなど) は、OCI コンテナとアーティファクトを保存し、そのバージョン管理を実行できます。

OCI は、ソフトウェアをパッケージ化して配布するための、標準化されたポータブルな方法を提供します。OCI コンテナを使用して AI モデル、Model Context Protocol (MCP) サーバー、および AI エージェントをパッケージ化することで、既存のソフトウェアサプライチェーンのセキュリティプロセス、CI/CD パイプライン、およびコンテナ・オーケストレーション・インフラストラクチャを使用できます。このアプローチは、アプリケーションのワークロードにすでに適用しているものと同じガバナンスと監査可能性を AI スタックにもたらします。

ModelCar による AI モデルのコンテナ化

大規模言語モデル (LLM) やその他の AI モデルには、独自のパッケージングの課題があります。これらには、大きなバイナリファイル、設定メタデータ、および特定のファイル構造の要件が含まれます。これまで、組織はモデルを配布するために S3 互換のオブジェクトストレージに依存してきましたが、このアプローチは既存のコンテナベースのワークフローやセキュリティプロセスとの摩擦を生じさせます。ここで、私たちは ModelCar と呼ばれる特定のファイル構造を使用して、AI モデルを OCI コンテナにビルドすることをお勧めします。

ModelCar コンテナとは

ModelCar コンテナ はシンプルです。AI モデルファイルはコンテナ内の `/models` フォルダに配置されます。追加のパッケージやランタイムコンポーネントは必要ありません。コンテナは単に OCI 準拠の形式でモデルアーティファクトを保持するだけです。

このアプローチには大きな利点があります。モデルをコンテナとしてパッケージ化すると、アプリケーションコンテナにすでに使用しているものと同じソフトウェアサプライチェーンのセキュリティプロセスを使用して管理できます。CI/CD パイプラインのタスクとして、コンテナのソフトウェア部品表 (SBOM) および AI 部品表 (AI-BOM) も生成できます。また、コンテナへの署名と検証、信頼できるビルドシステムによってコンテナが構築されたことを示す出所証明の生成、内部 OCI アーティファクトリポジトリへのコンテナの保存、および承認済みリポジトリからのみコンテナをプルするようにデプロイポリシーを設定することも可能です。

Red Hat Trusted Artifact Signer を使用すると、モデルに署名し、Sigstore と Rekor を使用してモデルの真正性と透明性を検証できます。 

Red Hat OpenShift AI 2.14 以降のバージョンは、KServe を使用して ModelCar コンテナからモデルを直接提供することをサポートしており、S3 互換ストレージへの依存を完全に排除します。これによりデプロイが単純化され、とくにコンテナがノードにキャッシュされている場合の推論サーバーの起動時間が短縮され、組織全体でアーティファクト管理に対する統一されたアプローチが提供されます。

サンプル ModelCar コンテナのカタログは GitHub リポジトリで入手でき、さまざまなモデルタイプをパッケージ化するためのテンプレートとベストプラクティスが提供されています。

モデルサイズに関する考慮事項

OCI 仕様ではイメージサイズに厳格な制限が設けられていませんが、実用上の制約は存在します。コンテナレジストリは通常、数 GB から数十 GB のイメージをサポートしており、ほとんどのエンタープライズレジストリは 15 - 20 GB までのイメージを問題なく処理します。これらの実用的な制限を超える非常に大規模なモデルの場合は、ファイルサイズを縮小するためにモデルの量子化手法を検討するか、または別の配布方法を検討する必要があるかもしれません。しかし、実運用モデルの大部分、とくに 8 ビット浮動小数点 (FP8) や 4 ビット整数 (INT4) などの量子化のバリエーションについては、ModelCar によるコンテナ化が実用的であり、推奨されています。

モデル向けの OCI アーティファクト

ModelCar は、OCI アーティファクトを完全にはサポートしていないレガシーシステムとの互換性を最大化するために OCI コンテナを使用しますが、モデルの保管については、 OCI アーティファクトの方が間違いなく優れており、効率的な選択肢です。 

ビルドエンジニアは、モデルをコンテナではなく OCI アーティファクトにパッケージ化して、OCI アーティファクトリポジトリに保存できます。デプロイ時には、Kubernetes イメージボリュームを使用して、OCI アーティファクトをモデル提供 Pod にストレージとして直接マウントできます。OCI アーティファクトのマウント機能は、現在、最新バージョンの `podman` と `CRI-O` コンテナランタイムに実装されており、`Containerd` を含む他のランタイム向けにも開発が進められています。

エンタープライズ規模のデプロイに向けた MCP サーバーのコンテナ化

MCP は、AI アシスタントやエージェントを外部ツール、データソース、API に接続するための標準的な方法として定着しています。MCP サーバーは AI システムと企業リソースの間の橋渡し役として機能するため、そのセキュリティとガバナンスが極めて重要になります。

チーム間で共有する、または本番環境にデプロイする MCP サーバーについては、他のアプリケーションに使用するのと同じビルドツールとプロセスを使用して、コンテナ内に構築することをお勧めします。このアプローチにより、これらのコンポーネントの管理、デプロイ、保護方法に一貫性がもたらされます。このプロセスは、アプリケーションをコンテナ化したことがある方ならお馴染みのものでしょう。コンテナファイルを作成し、イメージをビルドしてレジストリにプッシュし、Red Hat OpenShift、Kubernetes、Podman、または Docker を使用してデプロイします。  一般的なビルドツールを使用して、MCP サーバーの署名と検証、SBOM の生成、OCI アーティファクトリポジトリへの保存などを行うことができます。

どのソフトウェアでも同様ですが、悪意のあるコードが MCP サーバーに混入する可能性があります。Red Hat Trusted Profile Analyzer を使用して MCP サーバーを分析し、継続的に検証して、脆弱性、悪意のある依存関係、ポリシー違反を特定してください。

コンテナ化された MCP サーバーのメリット

コンテナ化された MCP サーバーは、水平方向に拡張して負荷の増加に対処でき、標準の可観測性ツールを使用して監視し、既存のセキュリティポリシーによって管理できます。

OpenShift Kubernetes MCP サーバーはこのパターンを実証しています。これは、開発のためにローカルで実行することも、チームアクセス用に Streamable HTTP トランスポートを使用してクラスタ内にデプロイすることもできます。サーバーは、設定可能なアクセスモード (読み取り専用、非破壊的、またはフルアクセス) をサポートし、認証のために Kubernetes のロールベースアクセス制御 (RBAC) と統合されています。

コンテナ化された MCP サーバーを中心として、エコシステムがすでに形成されつつあります。たとえば、MCP ライフサイクル Operator は、コンテナ化された MCP サーバーのデプロイと、Kubernetes ネイティブの設定を介したエージェントへの接続を容易にします。Kuadrant MCP Gateway は、高度なエンタープライズ向けのセキュリティ機能を提供します。Docker などのその他の一般的なツールも、コンテナ内の MCP サーバーと連携可能です。

MCP サーバーをコンテナ化すべきではない場合

すべての MCP サーバーがコンテナ化のメリットを享受できるわけではありません。MCP 仕様は、stdio (標準入出力) と HTTP ベースのトランスポート (Streamable HTTP およびレガシー Server-Sent Events (SSE) トランスポートを含む) という 2 つの主要な転送メカニズムをサポートしています。この違いは、デプロイメントの決定において重要です。

Stdio ベースの MCP サーバーはプロセスストリームを介して通信し、AI クライアントはサーバーを子プロセスとして起動します。このモデルは、開発者のコーディングアシスタント、ローカルの生産性向上ツール、個人用の自動化スクリプトなど、単一ユーザーのシナリオに適しています。このような場合、MCP サーバーはユーザーのノートパソコン上で実行され、ローカルファイルやリソースにアクセスし、不要になった時点で終了します。stdio ベースの MCP サーバーをコンテナ化することは、これらのシングルユーザーによるローカルユースケースにおいては大きなメリットがなく、複雑さが増すだけです。

対照的に、HTTP ベースの MCP サーバーは、複数のクライアント接続を同時に処理できる独立したプロセスとして実行されます。これらはネットワークエンドポイントを公開し、従来の Web サービスのように動作します。これらのサーバーはコンテナ化の最適な候補であり、一元化されたデプロイ、スケーリング、および管理のメリットを享受できます。

決定の指針は、以下のようになります。 

• 共有環境および本番環境の場合：MCP サーバーをチーム間で共有する場合、ネットワーク経由でアクセスする場合、またはサーバー環境にデプロイする場合は、コンテナ化してください。
• コンテナ化されたエージェントの場合： エージェントがコンテナで実行されている場合、stdio ベースの MCP サーバーはエージェントと同じコンテナで実行し、HTTP ベースの MCP サーバーは別のコンテナで実行する必要があります。
• 単一ユーザーによるローカル使用の場合：MCP サーバーが stdio トランスポートを使用して単一の開発者のマシンでローカルに実行される場合、コンテナ化は任意ですが、不要なオーバーヘッドが生じる可能性があります。 

エージェントスキルのコンテナ化

エージェントスキルは、MCP サーバーを補完する代替手段として登場しました。これらは「エージェントがより正確かつ効率的にタスクを実行するために、検出および利用できる指示、スクリプト、リソースのフォルダー」です。スキルの仕様では、これらは zipファイルとしてパッケージ化されます。 

ビルドシステムを拡張して、モデルや MCP サーバーと同様に、OCI コンテナまたはアーティファクトにスキルをパッケージ化できます。これにより、スキルへの署名と検証、SBOM の生成、OCI アーティファクトリポジトリへの保存、ダウンロード、およびモデルと同様の Pod へのアタッチが可能になります。スキルにはプラットフォーム固有のスクリプトが含まれる場合があるため、OCI にはプラットフォームごとに異なるファイルセットを提供する機能もあります。スキル対応アプリケーションがまだ OCI コンテナやアーティファクトに対応していない場合は、ORAS コマンドラインユーティリティを使用してスキルを正しいディレクトリに抽出できます。 

あるいは、他のプログラミング言語の共有ライブラリと同様に、将来的にパッケージマネージャーを使用してスキルを管理することも可能になるでしょう。この場合、スキルはコンテナ内でインポートして使用されますが、必ずしもスキル自体をコンテナとして配布する必要はありません。 

これは新しいテクノロジーであるため、今後の進展に注目してください。 

AI エージェントのコンテナ化

AI エージェント（AI モデルやその他のツールを使用して多段階のタスクを計画および実行できる自律型システム）は、AI アプリケーションの次の進化形と言えます。エージェントがプロトタイプから本番環境へと移行するにつれ、企業にはそれらを構築、デプロイ、管理するための構造化されたアプローチが必要になります。

Kagenti プロジェクトは、まさにこの目的のために Kubernetes ネイティブのフレームワークを提供します。Kagenti は、あらゆるエージェントフレームワークや SDK と連携し、本番環境へのデプロイ用のモジュール式コンポーネントを提供します。その中核として、Kagenti はエージェントを、Kubernetes カスタムリソースを使用して宣言的に定義できるコンテナ化されたワークロードとして扱います。

Kagenti は Shipwright と Buildah を使用して、エージェントをコンテナにビルドします。組織で CI/CD に Tekton または Jenkins を使用している場合は、既存のパイプラインに同様の Buildah タスクを追加できます。AI モデルや MCP サーバーと同様に、一般的なビルドツールを使用して、エージェントコンテナへの署名と検証、SBOM の生成、OCI アーティファクトリポジトリへの保存などを行うことができます。

MCP サーバーと同様に、コンテナ化されたエージェントを水平方向にスケーリングして増加する負荷を処理し、標準の可観測性ツールを使用して監視し、既存のセキュリティポリシーを通じて管理できます。  また、Red Hat Trusted Profile Analyzer を使用してエージェントを分析し、継続的に検証して、脆弱性、悪意のある依存関係、およびポリシー違反を特定することもできます。

シングルユーザーエージェントとサブエージェント

MCP サーバーと同様に、すべてのエージェントにコンテナ化が必要なわけではありません。コーディングアシスタントが起動するサブエージェントやパーソナル自動化エージェントなど、単一ユーザーのノートパソコン上でローカルに実行されるエージェントには、コンテナのパッケージングや Kubernetes デプロイのオーバーヘッドが必要ない場合があります。これらの軽量エージェントは多くの場合、親アプリケーションの子プロセスとして実行され、そのアプリケーションのセキュリティコンテキストを共有します。

このようなシングルユーザーのシナリオでは、すべてのサブコンポーネントをコンテナ化するのではなく、親アプリケーション (IDE、コーディング・アシスタント、または自動化ツール) が適切に保護されていることを確認することに重点を置く必要があります。これらのローカルエージェントのエンタープライズレベルでの管理は進化を続けており、組織はエージェントのフレームワークとツールの開発を監視する必要があります。

サンドボックス用のコンテナ

コードを作成して実行するエージェント、MCP サーバー、およびモデルは新しい脆弱性をもたらすため、システムへのアクセスを制限して、それらが引き起こす可能性のある損害を封じ込めることがベストプラクティスです。これは「エージェントサンドボックス」または「コードサンドボックス」と呼ばれることもあります。 

コンテナ化されたソフトウェアは、ポートの開放やブロックから、特定の Web サイトやサービスの許可リスト登録まで、外部サービスとの通信を制限するネットワークポリシーとともにデプロイできます。Kubernetes RBAC およびサービスメッシュ機能により、アクセスに対するきめ細かな制御が可能になります。OpenShift コンテナは通常 root 権限なしで実行され、データやコンピュートリソースへのアクセスを制限します。  

コンテナには、CPU やメモリの使用量にも制限があります。開発者のワークステーションでは、Podman はデフォルトで root 権限なしでコンテナを実行し、ネットワークやファイルシステムへのコンテナのアクセスも制限します。OpenShift は長年コンテナの分離機能を提供しており、Red Hat build of Podman Desktop により開発者のワークステーション上でもコンテナの分離が可能になります。

もう 1 つの懸念事項は、エージェントによる制御不能な処理がサービス拒否攻撃につながることです。OpenShift を使用すると、クラスター管理者は namespace ごとにリソースクォータを設定し、1 つのプロジェクトが消費できる GPU、CPU、メモリ、およびストレージリソースを制限できます。適切なリソースクォータが設定されていれば、制御無能になったエージェントがクラスタリソースを占有して他のワークロードのリソースが奪うことはありません。

個人のノートパソコンで実行することも可能ですが、コーディング・アシスタントやパーソナルエージェントをコンテナで実行する方が、多くの場合、その手間をかける価値があることがわかっています。エージェントがサンドボックス化されたコンテナで実行されている場合、ノートパソコン上の重要なドキュメントを損傷したり、意図しないデータにアクセスしたりすることはありません。つまり、ファイルの読み書きなどの一般的なアクションを事前に承認した上で、少ない監視でエージェントを実行させ、割り当てられたタスクの最終結果をレビューするだけで済みます。

また、複数のエージェントを同時に起動して、互いに干渉することなく並行して作業させることもできます。長時間実行されるエージェントを OpenShift の個人用 namespace にデプロイすれば、ノートパソコンを閉じて帰宅している間も、エージェントに作業を継続させることができます。エージェントのコンテナを保存して状態を保持し、後で再開することも可能です。この分野の先進的なプロジェクトは 2 つあります。コーディング・エージェント用の paude と OpenClaw 用の openclaw-installer です。

AI ワークロードをコンテナ化するメリット

AI コンポーネント (モデル、MCP サーバー、エージェント) をコンテナ化すると、組織全体で相乗効果のある大きなメリットがもたらされます。

ソフトウェアサプライチェーンのセキュリティ

コンテナのデプロイ前に、コンテナに対する署名、証明、検証を実行できます。すべての AI コンポーネントが、信頼できる CI/CD システムによって構築され、脆弱性がスキャンされ、承認されたレジストリに保存されるようにすることも可能です。来歴証明書は、各アーティファクトがどのように作成されたかを正確に示す監査証跡を提供します。

バージョン管理とロールバック

コンテナイメージはイミュータブルで、タグが付けられています。特定のバージョンをデプロイし、問題が発生した場合は直前のバージョンにロールバックして、何がいつデプロイされたかという明確な履歴を維持することができます。

一貫したデプロイ

同じコンテナイメージが開発環境、ステージング環境、本番環境のすべてで同じように実行されるため、環境間でファイルが正しくコピーされないというリスクが軽減されます。

可観測性

コンテナ化されたワークロードは、既存の監視およびロギング・インフラストラクチャと統合されます。たとえば、Kagenti は OpenTelemetry (OTEL) トレースを標準でサポートしており、標準の可観測性スタックを使用してエージェントの動作を監視できます。

分離とアクセス制御

最後に、コンテナはサンドボックス用の豊富な機能を提供しており、問題の影響範囲の制御に役立ちます。

今後の展望：ワークロード ID とゼロトラスト

コンテナ化は、より高度なセキュリティパターンの基盤を築きます。Kagenti プロジェクトでは、エージェントと MCP サーバーのワークロード ID およびゼロトラストアーキテクチャを実現するために SPIFFE/SPIRE との統合を検討しています。これらの機能はまだ発展途上ですが、AI コンポーネントをコンテナ化して Kubernetes 上で実行することで、これらの機能が成熟したときにこれらのセキュリティ機能の導入は大幅に容易になります。

ワークロード ID により、各エージェントまたは MCP サーバーに暗号的に検証可能な ID があることを確認し、共有シークレットを使用しない安全なサービス間通信を可能にできます。AI コンポーネントがコンテナ化され、既存の ID およびアクセス管理インフラストラクチャと統合できる場合、ゼロトラストの原則 (決して信頼せず、常に検証する) を実用的に導入することができます。

終わりに

OCI コンテナは、ソフトウェアをパッケージ化し、配布するための実績のある標準化されたアプローチを提供し、このアプローチは AI ワークロードに自然に拡張できます。AI モデル、MCP サーバー、エージェントをコンテナ化することで、アプリケーションにすでに適用されているものと同じガバナンス、セキュリティ、運用の成熟度が AI スタックにもたらされます。

コンテナ化が価値をもたらすタイミングを認識することで、重要な洞察が得られます。コンテナは、ネットワーク化された共有の本番環境デプロイメントに不可欠です。シングルユーザーがローカルで使用する場合、コンテナの使用は任意ですが、サンドボックスとデバイス間での可搬性 (一度構築すればどこでも実行できる) という利点があります。この実用的なアプローチにより、不要な複雑性を回避しながら、各コンポーネントに適切なレベルのガバナンスを適用することができます。

Red Hat OpenShift AI、Red Hat Trusted Artifact Signer、Red Hat Trusted Profile Analyzer、および Red Hat build of Podman は、プロトタイプから本番環境に至るまで AI ワークロードを管理するための強固な基盤を提供します。Red Hat は、活発なコミュニティを持つオープンソースツールにエンタープライズサポートを追加し、AI における最新の開発に遅れずについていくことができるよう支援します。